模型再聪明也没用，企业要补上下文这门课

Anthropic 的 Lamis Mukta 的演讲很有意思，做个笔记。内容是关于上下文工程与内存设计。

・只靠模型本身的智能，无法积累组织专属的成果
・无论新模型变得多聪明，开箱状态下它都不可能知道你自家代码库的运作方式、用户偏好，上下文就是用来填补这部分空白的

・反过来说，对上下文工程的投资和模型智能是正交关系，因此模型越聪明，这项投资就会变成乘数效应的资产
・回顾过去一年的发展，起点是和 Claude Code 一同推出的、类似 Claude.md 的 markdown 格式

・只要在会话开头注入这个文件，就能惊人地将智能体的行为引导到目标方向
・但随之而来会遇到一个朴素却无法避免的限制：文件变大后就会挤占上下文空间

・即便如此，markdown 这种人和智能体都能读写的简单形式本身，已经被证实极为有效
・接下来被尝试的方向是内存工具

・这个方向是把何时读、何时写、何时更新的决定权交给智能体本身
・因为这类读写发生在同一会话内，所以属于所谓的带内（in-band）内存管理

・第三个方向是技能
・这个方向适合处理流程固定的一系列工作流

・技能设计的巧妙之处在于渐进展示（progressive disclosure）：智能体会先只看前置内容，等到需要的时候再加载正文
・但技能留下了一个依赖人工的瓶颈：哪些内容需要技能化，必须由人来决定

·因此目前被认为是最佳实践的方案，是把内存系统直接建模为文件系统
・智能体已经能很好地使用 bash、grep 这类常规文件操作工具，所以不需要过度打造专用的读写工具

・整理下来，这套方案可以归纳为三点：格式用 markdown，读取端在允许文件肥大化的同时提供索引和搜索，写入端赋予智能体自主性
・只要实现到这一步，单个任务的表现就会稳步提升，你能切实感受到持续学习的效果

・但如果把这套方案放到生产环境，实际上会发生问题：比如多个智能体同时写入，或是错误内容被写入全组织上下文，进而扩散到所有智能体身上
・除此之外，内存还会过时，也存在被注入 prompt 写入恶意内容的风险

・针对这些问题，第一原则是版本控制
・除了支持回滚，还要做到可以追溯到更新是基于哪个会话、哪份转录文本、由谁完成的

・第二是并发控制
・采用的方案是写入前先取哈希，生成编辑方案，提交前再取一次哈希，如果不一致就让智能体重新获取内容再修改

・第三是权限控制
・按分层设置不同权限：比如全组织的策略是只读，单个智能体的临时草稿区可写

・第四是可移植性
・精心积累出来的内存，最好设计成可以通过干净的 API 跨多个产品使用

・这些基础准备就绪后，第二次执行相同任务时精度会提升，一次性就能完成的比例会增加，因此 token 消耗和延迟都会下降
・还有一个额外好处：智能体可以自主循环学习，开发者就能集中精力改进产品本身

・但即便如此，带内（in-band）内存仍然存在两个结构性限制
・第一个是资源分配的两难：要完成当前任务，还是要投资未来的自己

・第二个是视野限制：跨会话重复发生的同一种错误，还有像舰队一样并行运行的其他智能体犯下的错误，单个智能体都无法发现

・因此业界引入了名为 dreaming 的带外（out-of-band）内存整理流程，以批处理方式异步运行
・具体来说，它会把现有内存列表和一段时间内的转录文本作为输入，由编排器启动一组子智能体来进行分析

・分析对象不只是对话内容，还包括工具调用和元数据
・编排器只会把足够高频出现的模式作为修改候选方案提出来
・方案还会附上作为依据的转录文本示例和发生频率统计，方便人类判断是否采纳

・带内内存的特点是更新快，但资源会产生竞争
・dreaming 的特点是拥有全局视野和专属预算，但更新慢，因此两者是并行互补的关系

・有人可能会担心额外成本，但通过提升一次性完成任务的比例，整体的 token 消耗反而会下降。