上下文工程设计的是 AI Agent 在做决定时能使用的一切:系统指令、用户意图、工具定义、检索记录、文件、消息历史、环境状态,以及之前任务留下的笔记。
它不是“往提示词里塞更多文档”。真正的问题是选择足够小、足够可信的状态,让 Agent 能正确行动;同时决定哪些信息要保留、哪些必须刷新、哪些绝不能越过权限边界。
信息核对截至 2026 年 10 月 13 日。 下文讨论的是架构方法,不是某个模型或厂商的固定能力。产品限制与上下文窗口会变化,实施时应重新核对官方文档。
为什么上下文越多,Agent 反而可能越差
长上下文仍然有限,而且信息价值并不均匀。旧计划会和新决定竞争,名字相似的记录容易串错,大量重叠工具会增加误选概率,外部资料还可能夹带与任务冲突的指令。
Anthropic 把上下文工程定义为:在模型约束下优化 token 的有效性,并建议用压缩、结构化笔记和多 Agent 架构支持长任务。其官方上下文工程指南还指出,人都说不清该用哪个工具时,不能期待 Agent 自己猜对。
目标不是最大召回,而是与当前决策相关的精确上下文。
Agent 上下文的六层结构
1. 策略与角色
写清 Agent 的职责、硬性限制、审批要求和规则优先级。它应该短、稳定、可测试。“保持有帮助”不是控制;“没有审批令牌不得发送外部消息”才是。
2. 任务状态
包含当前目标、成功标准、计划、已完成步骤、待解决问题和停止条件。它会随运行变化,应显式表示,不能让 Agent 从漫长对话中自行推断。
3. 工具契约
工具说明要包含用途、必要输入、副作用、使用谁的权限、常见失败,以及怎样才算成功。功能重叠的工具必须有明确选择规则。这是 Agent Harness的一部分,不是可有可无的背景说明。
4. 检索证据
检索应该返回当前决定需要的证据,而不是整库倾倒。每项资料都要带来源、时间、权限范围与相关性。事实源优先于非正式消息;冲突要展示,不能混成一条折中陈述。
5. 工作记忆
工作记忆保存中间计算、临时假设与近期工具结果。除非按规则升级,否则任务结束就应失效。把所有草稿都长期保存,只会制造未来噪声和隐私风险。
6. 长期记忆
长期记忆保存跨会话仍有价值的事实或偏好。它必须有所有者、出处、更新规则和删除路径。缺少这些属性的摘要不是记忆,而是一条迟早过期、又无法追责的说法。
检索与长期记忆为什么不同,可继续阅读 AI 为什么跨会话遗忘。
从“要做的决定”反推上下文
先选一个 Agent 必须完成的决定,例如“这张支持工单是否应该升级”。列出最小证据:严重级别规则、客户等级、近期事故、已尝试方法和当前服务状态。然后给每项证据指定来源和权限身份。
可以建立一张上下文清单:
| 字段 | 要回答的问题 |
|---|---|
| 决策 | Agent 最终要作出什么选择或动作? |
| 必要证据 | 哪些信息缺失时,结论就站不住? |
| 权威来源 | 记录冲突时以哪个系统为准? |
| 新鲜度 | 资料最多可以多旧? |
| 权限 | 以谁的身份检索? |
| 预算 | 该来源最多占多少上下文? |
| 失败行为 | 询问、放弃、重试还是升级? |
这样可以避免从“把所有系统都接上”开始,再期待相关性自己出现。
检索既是排序问题,也是安全边界
高质量检索先按实体、时间、权威性和权限过滤,再做语义相似度。主题相近的文档可能属于另一个客户,时间最新的消息也可能只是未经批准的意见。
把检索文字当数据,不当指令。标记来源,不允许它覆盖系统策略,并独立限制工具权限。能读取发票不代表有权付款。
知识密集型工作可以参考面向个人经营者的 LLM 知识库,了解资料结构如何影响检索。上下文工程再进一步决定:这一次运行究竟应该放入哪些来源。
压缩时不能丢掉承诺
长任务需要压缩,但一段散文式摘要很容易漏掉关键细节。压缩状态应拆成结构化字段:已确认决定和审批人、未完成承诺及截止日期、当前产物版本、未解决冲突、证据链接、已尝试动作及结果、明确要求不要重复的失败。
原始证据尽量保留在提示词之外,用稳定标识引用。摘要应该能够从来源重建,不能成为历史的唯一副本。
记忆需要升级规则和衰减规则
不要让 Agent 随意把自己的推断写入长期记忆。更安全的流程是:先提出候选记忆;标记来源与置信度;敏感或重要事实必须确认;设置过期或复核日期;修订时保留变化记录,而不是静默覆盖。
偏好可以保留到用户修改;项目状态应从事实源刷新;会议决定要链接已批准的记录;个人或机密数据若没有充分理由,应随任务过期或继续限制在原作用域。
不只评最终答案,也评上下文
一次答对可能只是运气。用固定测试集主动扰动输入:移除必要来源,看 Agent 会不会拒答;加入过期但相似的文档;制造记录冲突;在检索资料里放入不可信指令;用不同权限用户执行;压缩后恢复任务,检查承诺是否还在。
记录来源精确率、必要证据遗漏、越权检索、无依据陈述、工具误选、反馈后纠错,以及每个被接受任务的上下文成本。目标是在状态不完美时仍保持一致行为。
结构明确,上下文才可迁移
如果上下文表现为文件、记录、工具契约和版本化任务状态,而不是隐藏在对话历史里,更换模型会容易得多。这不能消除厂商差异,但能减少意外锁定,也让审计成为可能。
真正可积累的资产不是超长聊天记录,而是一套持续维护的上下文系统:命名清楚的来源、遵守权限的检索、明确决定、压缩状态和评估案例。
结论
上下文工程决定 Agent 看见什么、相信什么、可以做什么,以及任务结束后留下什么。从决策出发,检索最少但权威的证据,隔离不可信内容,把状态压缩成结构化记录,只在有出处和生命周期规则时升级为长期记忆。
更强的模型可以提升推理,却无法自动修复缺失证据、模糊工具、过期记忆和错误权限设计。
相关文章
Gemini Agent 是什么?Google 通用工作 Agent 详解
Gemini Agent 是 Google 面向企业工作的通用 Agent,支持持久执行、多 Agent 协作、多模型路由和业务工具连接。本文解释它与 Gemini App 的区别、核心能力、开放状态及现阶段限制。
AI Agent Connector 详解:MCP、OAuth 与权限边界
从实际工作流解释 AI Agent Connector 如何组合 MCP、OAuth、Scope、资源权限与人工审批,并提供选型、试运行、故障定位和安全核查方法。
Agent Harness 是什么?从执行循环到安全恢复
系统解释 Agent Harness 的架构:执行循环如何连接上下文、工具、沙箱、权限审批、可观测性与失败恢复,以及如何区别模型、Framework、Connector 和 Workspace。
https://floatboat.ai/zh/blog/context-engineering-for-ai-agents



