场景背景
用户问，“为什么昨天收入下降？”
Agent 前几轮已经得到：
总收入下降 20%
媒体 B 降幅最大
请求量基本稳定
eCPM 下降 35%其实已经基本排除：
流量下降但后面又查了很多日志。
Context 里塞进大量 SQL 结果。
模型突然再次：
按请求量拆媒体重复调查已排除方向。
问题根因
当前 Context 只有：
Conversation
+
Raw Tool Results没有：
Current Focus
Working Memory所以模型只能从大量历史里重新推断。
而最关键的事实：
请求基本稳定已经被淹没。
改造
ContextBuilder 每轮加入：
Current Task：
定位 media_B eCPM 下降原因。
Relevant Memory：
- 总收入下降 20%
- media_B 是主要异常来源
- 请求量稳定，暂不优先调查流量同时 Tool Result 只保留最近 5 个关键结果。
新行为
模型自然更容易：
按广告位拆 media_B 的 eCPM而不是回头重查请求。
结果
Step 更少。
Token 更低。
分析路径更稳定。
复盘
这就是为什么我们后面马上会进入，Working Memory。
因为 Agent 不应该完全依赖 Conversation History 来维持“当前认知”。
ContextBuilder 需要一个更结构化的“当前任务摘要”。
常见误区
误解： Agent Prompt 就是一段很长的 System Prompt，把所有规则都写进去就行。
正解： 真实 Agent 的上下文来源很多，而且生命周期不同。System Prompt 适合稳定身份与原则，AGENTS.md 属于项目规则，Skills 按任务动态加载，Memory 保存可复用事实，Tool Results 属于当前运行反馈，Current Task 表示当前焦点。把所有内容永久堆在一个 System Prompt 里，会导致难维护、难裁剪、难更新，也无法按任务动态变化。
误解： Context 越多，模型知道得越多，Agent 一定越聪明。
正解： 过多上下文会产生噪声、重复、冲突和 Token 成本。尤其 Tool Result 很容易把真正重要的规则和当前任务淹没。Context Engineering 的核心不是“塞满”，而是选择最相关、最高优先级、最新且可信的信息。好的 ContextBuilder 更像筛选器，而不是搬运工。
误解： Conversation History 已经包含所有过去信息，所以不需要 Memory 和 Current Task。
正解： Conversation 是原始历史，随着 Agent 运行会越来越长。真正关键的信息可能埋在几十轮 Tool Result 里，模型每轮都重新推断既浪费 Token，也容易遗忘。Working Memory 和 Current Task 是对当前认知与焦点的结构化提炼，后续还可以跨 Session 使用 Long-term Memory。它们和 Conversation 的职责不同。
误解： Tool Result 是真实环境数据，所以优先级应该比 System Rule 更高。
正解： Tool Result 的“真实性”只代表它是环境反馈，不代表它能修改 Agent 的上层行为边界。文件内容、网页内容、数据库文本里都可能出现恶意或误导指令。它们属于数据层，不能覆盖 System / Safety / Agent Rules。这种上下文层级是抵御 Prompt Injection 和行为漂移的重要基础。
误解： ContextBuilder 就是一个 Prompt Template，把几个变量格式化成字符串。
正解： Template 只是格式化，而 ContextBuilder 还要处理来源收集、优先级、动态 Skill 选择、Memory 筛选、Tool Result 截断、Conversation 裁剪、冲突与预算。对于短 Demo 两者看起来差不多，但长期运行 Agent 中，ContextBuilder 是运行基础设施，而不是文案模板。
误解： 只要最终模型输出正确，就没必要记录 ContextBuilder 到底选了什么。
正解： Agent 行为高度依赖输入上下文。没有 Build Report，出现错误时只能猜模型为什么走偏。记录每轮加入哪些 Section、裁掉哪些内容、长度多少，可以快速定位 AGENTS.md 未加载、Memory 过期、Tool Result 太长等问题。Context 本身也应该成为 Tracing 的一部分。
请登录后查看评论内容