上下文工程是怎么设计？

提示

题眼： 不是聊天记录，也不是记忆，是操作车间。重点
存放的内容，存放的方式，优化方案。

重要

参考答案：

上下文工程其实就是利用好上下文的空间，尽可能做好内容的编排，而不是说，什么东西都堆在一起，这样会拖累性能，效果也不好。

一般情况下，会先把整个上下文的空间分成几个模块，比如指令层，状态层，记忆层，工具层，每个层级根据它需要加载的内容会预先分配一些 Token，这样可以防止超长之后再压缩或阶段。

我做过的项目里，会在指令层存放最基本的指令输入，System 规定当前 Agent 的身份、边界和安全规则，Developeer 存放流程、协议这些，然后 user 存放用户输入的指令。这一块一般需要的 Token 不会很多，而且不怎么需要改变。只需要注意一下，后续的指令如果优先级比较低，不能直接覆盖，而是追加或者补充描述。

状态层，一般用来存放当前 Agent 的工作记录和状态。基本上就是我们平常做事儿的思路，按照优先级：要达成的目标，评判标准，边界和约束条件，当前的进度，Todolist, 卡点问题和中间产物这些。这样，Agent 进入新一轮的时候，不用从历史记录里重新评估当前进度，直接读取这一块内容就行了。

记忆层，存两块内容。最近几轮对话的语境和长期记忆里提取出来的稳定信息，比如风格，喜好，过去优秀的方案等等。但是这一块的话，会有一些问题，长期记忆并不一定准确，有可能用户会临时更改风格，那么这一块内容要跟着变。

最后的话是这个工具层。这一层就比较简单些，用来存放能够使用的 tools、RAG 召回内容或者 skills 信息，可能一开始不会加载所有信息，只加载 list，等到真正需要调用的时候再按需加载。

然后接下来比较麻烦一些，需要将这些内容进行编排并且做好安全隔离和预算分配。我了解过的，一般编排都是按照‘优先级’也就是规则>状态>数据的思路排序，再编排的时候，需要看下当前的任务里有没有一些安全隐患的操作，比如说删除文件，改数据库，发邮件这种操作，如果有的话，还需要明确这个任务的安全边界，比如说删除文件必须征得用户同意，改数据库要使用现有函数，不能自己构建 SQL 等。这种必须要写入到状态层的约束条件里，不能只是混在提示词里，直接使用。

最后就可以对每一层进行 Token 的预分配，按照一定比例分配，并且做好压缩配置，当超过阈值后进行压缩或者直接截断。实际上，在开发 Agent 的过程中，上下文工程我觉得是非常非常复杂的，每一个环节都不简单。就比如压缩上下文时，是否可逆，是否需要写入长期记忆这些，都需要注意。