上下文工程：比 Prompt 更重要的 Agent 输入系统

Prompt 只是上下文的一小部分

很多 Agent 项目效果不稳定时，第一反应是继续润色系统 Prompt。实际运行中，模型看到的输入还包括任务目标、历史步骤、工具定义、检索文档、用户偏好和错误反馈。真正决定下一步质量的，是这整套信息如何被选择、排序和表达，这就是上下文工程。

上下文窗口即使足够大，也不意味着应该把所有内容塞进去。过多无关信息会稀释关键约束，旧状态会和新事实冲突，长篇工具返回还会显著增加延迟与成本。上下文工程的目标不是“放得下”，而是让模型在当前决策点看到最有用、最可信、最及时的信息。

按信息职责分层

一个可维护的 Agent 上下文可以分成六层，并保持固定顺序：

系统规则：身份、边界、安全政策和输出契约；
当前目标：用户真正要求的交付物与成功条件；
运行状态：已完成步骤、剩余计划、预算与阻塞项；
领域事实：经过检索或工具确认的证据；
可用动作：当前阶段允许调用的工具；
最近观察：刚执行动作的结构化结果。

高优先级规则应短而稳定，不要混入大量业务资料。动态事实需要附带来源和时间，避免模型把过期数据当成规则。工具返回必须明确标为数据，不能和系统指令处在同一层级。

从聊天记录中提取状态

直接把完整对话反复传给模型，是最简单也最容易失控的方案。随着轮次增加，模型需要自己从自然语言中推断“哪个决定已被撤销”“哪个动作已经执行”。更稳妥的做法是把历史压缩成显式状态：

{
  "goal": "完成服务迁移方案",
  "constraints": ["停机不超过 5 分钟", "不能修改客户端"],
  "decisions": [
    {"value": "采用双写迁移", "evidence": ["doc-12", "metric-8"]}
  ],
  "completed": ["盘点数据表", "验证复制延迟"],
  "next": ["设计回滚开关"],
  "openQuestions": ["旧库保留多久"]
}

原始轨迹仍保存在日志或对象存储中，供审计和复盘；决策时只加载压缩状态与必要证据。这样既减少 Token，也避免历史闲聊干扰。

压缩不是简单摘要。摘要器必须保留约束、数字、未解决问题、业务 ID 和来源引用，不能把“必须”改写成“建议”。对关键字段最好使用 Schema，让程序检查遗漏。

使用“按需展开”而不是一次性注入

工具说明、数据库字段和知识库文档可能非常多。可以先提供目录级信息，模型需要时再展开细节。例如先告诉 Agent 有“订单、客户、退款”三个领域；当它选择退款领域后，才加载相关工具与规则。

同样，检索结果先返回标题、摘要、来源和时间。Agent 选择相关文档后，再读取具体段落。按需展开让每个决策点的动作空间更小，也降低不可信内容进入上下文的面积。

一种实用的上下文预算分配方式是：为系统规则和目标预留固定空间；为当前状态设置上限；为证据按相关性动态分配；为模型输出和工具反馈保留安全余量。不要等到窗口满了才截断，因为简单截尾可能恰好删除最早的关键约束。

处理事实冲突与新鲜度

Agent 经常同时拿到多个版本的事实。上下文中应包含来源类型、采集时间和可信等级。例如实时 API 状态通常比三个月前的说明文档更适合回答“现在是否可用”，但制度问题可能以正式文档为准。

不要让模型隐式解决所有冲突。可以在构建上下文时先按规则排序，并明确展示：

[已确认事实] 生产 API 返回版本 3.2，采集于 10:31
[历史文档] 接入手册写版本 3.0，更新于 90 天前
[冲突提示] 回答版本问题时以实时 API 为准，并指出文档待更新

涉及时间敏感信息时，绝对日期比“昨天”“最近”更可靠。长任务恢复后尤其要重新确认外部状态，不能把检查点里的旧观察当成当前事实。

上下文缓存与隐私

稳定的系统规则、工具 Schema 和公共资料可以缓存，减少重复处理。但缓存键必须包含版本；规则更新后，旧缓存不能继续命中。用户数据、访问令牌和敏感工具结果不应进入共享缓存。

在送入模型前进行数据最小化：任务只需要地域统计时，用聚合结果代替完整客户记录；只需要判断文件类型时，不传文件正文。上下文不是日志仓库，更不是秘密保险箱。

如何评估上下文质量

不要只看最终答案。可以记录每一步实际注入了哪些信息，并检查：关键约束是否出现、过期事实是否被标记、无关内容占比、检索证据是否被引用、上下文长度与任务成功率是否相关。

构造一组“上下文对抗测试”也很有效：在工具返回中加入与任务无关的指令；同时提供新旧冲突资料；让历史对话包含已撤销决定；模拟窗口接近上限。好的上下文系统应让 Agent 仍能遵循高优先级规则，并明确暴露不确定性。

小结

Prompt 告诉模型应该怎么思考，上下文工程决定模型究竟基于什么思考。把信息分层、状态结构化、证据按需加载、冲突显式化，再加上预算和隐私约束，往往比增加一段“请仔细思考”更能提升 Agent 的稳定性。