很多 AI Agent 跑偏，不是因为模型突然变笨，而是上下文被塞乱了。系统提示词、用户刚说的话、知识库检索片段、工具返回结果、历史偏好，全部混在一起，模型当然会分不清哪些是规则、哪些是证据、哪些只是临时参考。
所以现在做 Agent，越来越绕不开一个词：上下文工程。它不是把提示词写长一点，而是决定不同信息应该放在哪里、保留多久、按什么优先级参与推理。前面讲 AI Agent 的记忆 时，我们已经区分过上下文、知识库和长期记忆；这篇再往执行层拆一步。
提示词负责定规则，不负责装资料
系统提示词最适合放稳定规则，比如角色边界、输出格式、工具使用原则、不能越过的安全要求。它不适合塞大量业务资料。资料一多，提示词会变得难维护，也容易和后续检索结果冲突。
一个更稳的做法是：提示词只写“遇到事实问题先查资料、找不到就说明缺口、引用来源再回答”。真正的产品文档、FAQ、会议纪要应该交给知识库检索，而不是长期写死在提示词里。
短期上下文只服务当前任务
短期上下文像工作台，负责保存这一轮任务里的用户目标、中间草稿、刚刚确认过的限制条件。它的重点是连续性，而不是永久保存。比如让 Agent 写一份销售跟进邮件，它需要记住客户行业、预算、上一次沟通结论，但不一定要把这些都变成长期记忆。
这和 任务规划 是连在一起的。计划器拆出步骤以后，每一步都应该知道自己需要哪些上下文，而不是把所有历史内容都带上。
工具返回要标明来源和时效
工具返回最容易被忽略。搜索结果、数据库查询、表格读取、知识库片段，都应该带来源、时间和用途。否则模型可能把旧资料当新资料，把搜索摘要当官方结论，或者把失败返回当成有效证据。
如果你看过 AI Agent 工具调用机制，会发现工具不是越多越好，关键是返回结果要能被模型正确理解。对事实型任务来说，来源比语气更重要。
长期记忆要少而准
长期记忆最怕什么都存。用户说过的一句随口偏好、某次临时项目要求、一次过期活动规则，如果都被记住，后面反而会污染回答。真正值得保存的，通常是长期稳定的偏好、身份、常用流程和反复出现的约束。
评估时也要看上下文是否可复盘。上一篇 AI Agent 评估指标 里提到，日志要能还原工具调用和关键输入。上下文工程做得好，复盘时就能看到问题到底来自规则、资料还是记忆。
总结
AI Agent 上下文工程的核心，不是把更多内容塞给模型，而是把信息分层：提示词定规则，短期上下文服务当前任务，知识库提供证据，工具返回保留来源，长期记忆只存稳定偏好。分清这些位置，Agent 才更容易稳定、可查、可优化。
