智能体不会仅仅因为上下文窗口能容纳更多 token 就变得可靠。改进来自在决策时刻提供恰当的证据、指令和状态。
上下文是智能体的工作状态
上下文包括系统指令、对话历史、工具定义、检索出的文档、工具结果和临时计划。Anthropic 将上下文工程定义为对这整套 token 内容进行筛选整理，而不只是润色提示词的措辞。目标是构建精简、高信噪比的状态，以支持下一步操作。
材料越多，可能引入的过时规则、重复证据和干扰性工具输出也越多。容量与相关性是不同的约束。团队应跟踪哪些内容进入上下文、为何进入，以及它们在多长时间内仍具有权威性。
按需检索信息
将持久信息存放在提示词之外，只在上下文中保留文件路径、文档 ID 或搜索查询等轻量引用。让智能体在需要时获取具体片段。这种模式可以减少重复传输，也更容易检查信息来源。
检索必须有边界：权限检查、版本元数据、来源排序，以及对不可信指令的限制。工具结果是数据，不会自动成为系统提示词的一部分。要区分供智能体分析的内容和它被允许遵循的命令。
压缩上下文时别抹去承诺
长时间运行的工作最终需要压缩上下文。有用的摘要会保留目标、已确认的决定、已完成的工作、尚未解决的障碍、产物位置和验证证据；重复对话和可重新获取的大段输出则可以舍弃。
让摘要结构化、可审查。如果某项承诺很重要，例如“未经批准不得发送”，就将其存为明确的状态，而不是寄希望于叙述式摘要碰巧保留它。为摘要关联原始材料，方便后续会话找回细节。
用子智能体隔离嘈杂的工作
专注于单项任务的子智能体可以在干净的上下文中搜索大型语料库或测试多种方法，然后返回精简结果。隔离可以防止探索过程中的杂项挤占协调者的决策上下文；任务真正独立时，也可以并行开展。
协调者仍然需要验收标准和验证。自信的摘要不能证明文件确实存在或操作已经成功。应根据任务要求提供路径、来源链接、测试输出或回读证据。
将上下文纳入系统指标
记录上下文大小、检索来源、压缩事件、工具返回内容大小，以及决策所用状态的新旧程度。抽样检查上下文无关或缺失导致的失败。成本和延迟固然重要，但系统是否依据过时事实行动同样重要。
好的上下文架构能让故障变得可辨：工程师能够判断智能体是缺少证据、忽略规则，还是在两者都具备的情况下仍做出错误选择。
如何付诸实践
先选取一个与“AI 智能体的上下文工程：更少上下文，更好决策”相关、边界清晰的工作流程。改动系统之前，用一页文档记录基线：目前的完成时间、质量检查项、常见失败类别、升级处理路径和结果负责人。选取有代表性的样本，而不是只挑最干净的案例。纳入普通案例、困难的边缘案例，以及至少一个正确做法是停止或请求更多信息的案例。
在允许候选方案取代现有流程前，先让两者并行运行。成功和失败的输出都要检查，因为错误率下降仍可能掩盖新的高影响失败。记录每次测试使用的准确配置，并保留足以让其他审核人员复现结果的材料。试点结束时，依据事先商定的阈值决定扩大应用、修改方案还是停止，而不是事后凭一次最出色的演示作判断。
向供应商或内部团队提出的问题
询问核心主张有哪些证据支撑、证据基于哪个系统版本和数据版本，以及排除了哪些条件。要求提供与你的部署场景相符的语言、输入类型和风险类别的测试结果。询问变更如何通知、回归问题如何发现，以及客户如何导出事故复盘所需的日志。
还要问清：当置信度低、依赖项故障或请求超出支持范围时，系统会如何处理。可靠的产品应有明确的失败状态，而不是仅仅给出更像样的回答。责任归属同样重要：明确谁能暂停流程、谁批准例外，以及重大错误流入生产环境后由谁通知受影响的用户。
实用检查清单
- 选择模型或工具前，先明确用户任务以及真正需要防范的失败。
- 维护一个来自真实工作的、小规模且有版本记录的测试集，纳入棘手案例和对抗性案例。
- 每次运行都记录模型、提示词、工具、检索设置、数据版本、延迟和成本。
- 不可逆、高影响或对外可见的操作必须经过人工确认。
- 按类别复盘失败，不要只看单一平均分，并将回归案例加入测试集。
Meydo Journal 延伸阅读
原始资料
- AI 智能体的有效上下文工程 — Anthropic
