Context Engineering：一场草稿纸管理工程

人类工作时，经常会拿张草稿纸，记录想法、整理线索；写满了就换一张，需要时再翻翻旧笔记。

这和今天大量 Agent Context Engineering、Memory Engineering 所做的事情，实在是太像了。

早期，我们给模型一段 Prompt，再把对话历史不断追加进去。后来发现上下文窗口有限，于是开始截断、压缩、总结。再后来，又发明了长期记忆、分层记忆、向量检索、动态上下文加载，以及各种复杂的历史管理机制。

相当于我们从使用一张越来越长的草稿纸，进化到了分页、归档、编目录、贴便签，甚至建立了一整套自动化的草稿纸管理系统。

这些技术确实能让 Agent 更好地延续工作。但有一个问题似乎很少被放在讨论的中心：草稿纸上记录的东西，究竟有多少应该换种方式管理？

草稿纸 vs 系统

想象一个采购人员正在处理订单。

他可能在纸上记下几个临时问题：这个物料能不能替代？供应商的交期是否可靠？如果推迟三天，会影响哪些生产任务？这些是当前工作中的假设、待确认事项和中间判断，记在草稿纸上很自然。

但如果他确认了采购订单的交期发生变化，通常就应该直接打开系统，把对应订单的交期改掉。如果发现一个物料存在缺口，也应该更新相应的需求、采购任务或异常记录。

我们很难想象，一个企业会要求采购人员把所有业务变化都写进个人笔记，然后再开发一套复杂的笔记检索系统，让其他人通过阅读他的笔记来还原采购订单的当前状态。

然而，当我们讨论 Agent Memory 时，却很容易接受类似的设计。

Agent 在执行任务时不断积累历史、总结经验、维护任务进度，再依赖下一轮模型从这些记录里恢复环境状态。对于临时认知过程，这当然合理；但如果订单、项目、任务、对象关系和当前状态也主要通过这些文本传递，问题就已经超出了工作记忆的范畴。

草稿纸适合辅助工作，却不应该成为工作对象的唯一承载方式。

于是，很多 Agent 工程实践呈现出一种有趣的局面。

大量工作围绕 Context 和 Memory 展开：如何压缩、检索、归档和传递历史记录。

办公室没有 ERP，于是一直升级员工的草稿纸管理方法。还要研究哪些草稿纸应该是共享的，共享了又怎么拆权限。

更有趣的是，哪怕暂时没有 ERP，先建立一张有明确字段、对象标识和状态的 Excel 台账，都可能比继续堆积工作笔记更接近问题的解法。

Excel 当然也能写备注、保存说明和例外情况。它的价值恰恰在于，允许人们一边保留自然语言的灵活性，一边开始把对象、属性和状态从叙事中分离出来。

Context里经常混杂两类不同的信息。

一类属于主体自身的认知过程，例如当前假设、工作计划、中间推理、尚未验证的判断。这些信息会随着任务推进不断变化，需要工作记忆来承载。

另一类属于主体正在工作的环境，例如订单、设备、项目、资源、规则以及它们之间的关系和当前状态。这些信息通常需要由不同主体共同引用，并在现实发生变化时持续更新。

两者可以相互联系，却不应该被默认放进同一个文本历史里管理。

如果环境拥有稳定的表征，Agent 就可以在需要时查询相关对象和状态，完成判断后通过明确的接口执行动作，并将结果更新回环境。下一次工作时，无论是同一个 Agent，还是另一个 Agent 或人，都可以重新读取这些信息，而不必先翻阅某个主体的全部工作笔记。

这并不意味着 Context Engineering 没有价值。一个完善的业务系统也无法替我们完成所有思考；复杂任务仍然需要计划、假设、中间结果和经验积累。

但它意味着，Agent 需要维护多少工作记忆，不仅取决于任务有多复杂，也取决于环境已经替它承载了多少信息。

当大量本应属于环境的状态被留在主体内部，Harness 就不得不越来越复杂。它不仅需要管理模型调用和执行流程，还要负责保存、恢复和同步那些本来应该能够从环境中直接获得的信息。

相反，环境表征越成熟，Agent 就越有可能把注意力集中在真正需要理解、判断和行动的部分。

如何稳定地记录、组织和持续更新业务信息，并不是什么新问题。几十年的数字化实践，已经围绕这些问题进行了大量探索，形成了从 Excel 台账、数据库到各类业务系统的丰富解决方案。

Agent 的出现，当然会对这些基础设施提出新的要求。现有系统中的对象可能定义不清，关系分散在不同应用里，规则只存在于文档和人的经验中，许多状态甚至还没有被数字化承载。

这些问题指向的是环境如何被表征，而不只是模型如何管理上下文。

草稿纸管理得再先进，也不会自动长成一个数字世界。