更加完善准确的文章内容在我的公众号:破茧Plan,欢迎关注.

我把 Google 的 Agent 课程啃完后，才真正搞懂：Agent 不是“写提示词”，而是“做上下文工程”

先说明一下：这篇内容不是白皮书原文，是我把 Google / Kaggle 那套 Agent 课程里讲“Context Engineering”的部分读完、消化后，按我的理解整理出来的笔记和框架。

如果你也在做 Agent（客服/销售/数据助理/工作流自动化），很可能遇到过这种尴尬：
• Demo 很丝滑，上线就开始胡说八道
• 轮次一多就变慢、变贵、变不稳定
• 工具越接越多，反而越像“随机漫步”
• 你以为是模型不够强，结果换更强的也救不了

我后来发现，很多问题根本不在“模型能力”，而在你给模型的上下文。

同一个模型，有的人能做出生产级 Agent，有的人只能做玩具。差别往往就是：上下文有没有工程化。

---

1）为什么“提示词工程”救不了 Agent？

提示词（Prompt）更像一段“固定开场白”：告诉模型你是谁、要做什么、语气如何、有哪些边界。

但 Agent 不是一次性回答，它是一个持续运行的系统。每一步都要依赖：
• 用户是谁、偏好是什么（长期信息）
• 目前任务进行到哪一步（状态）
• 刚刚调用工具得到什么结果（证据）
• 过去几轮说过什么、哪些话是关键（历史）
• 还有你希望模型按什么方式推理、用哪些工具（规则）

这些东西不是一段静态 Prompt 能解决的，而是需要你在每一轮把“当下最重要的信息”拼装成一个资料包喂给模型。

这件事，我更愿意叫它：上下文工程（Context Engineering）。

一句话解释：

Prompt 是“怎么说”，上下文工程是“给它看什么”。

---

2）一个“能打的上下文”到底长什么样？

我把上下文粗暴分成三类，你可以对照你现在的 Agent 看看缺了哪块：

A. 规则层：告诉它“怎么做”
• 系统指令（角色、边界、输出格式）
• 工具说明（能调用哪些接口、参数是什么）
• 必要的示例（你希望它怎么思考、怎么写答案）

这层决定“方向”和“行为”。

B. 证据层：告诉它“事实是什么”
• 检索到的文档片段（RAG）
• 工具返回的数据（搜索、数据库、接口结果）
• 文件/图片/表格等外部材料

这层决定“靠谱不靠谱”。没有证据层，模型就会靠猜。

C. 当前态：告诉它“现在发生了什么”
• 用户本轮问题
• 任务状态（例如：已确认需求 / 待补充信息 / 已生成方案待审核）
• 必要的历史摘要（不是全量聊天记录）

这层决定“连贯”和“能不能推进任务”。

很多 Agent 做不稳，是因为把 B 和 C 当成了“堆聊天记录”。
聊天记录一长，就会出现“噪音越来越多、关键点越来越稀释”的问题：模型注意力被水掉了。

---

3）上下文为什么会越聊越崩：不是玄学，是结构问题

你一定见过两种崩法：

① 越聊越慢、越聊越贵

因为你把越来越长的历史塞进去了，Token 一路涨，成本和延迟自然就涨。

② 越聊越不聪明（甚至开始胡扯）

这就是我最在意的：信息变多不等于变强。
当上下文里废话、重复、冲突信息越来越多，模型更容易抓错重点，甚至被旧信息带偏。

所以“让它记住更多”并不是万能解，关键在于：

记住什么、忘掉什么、以什么形式记、什么时候取出来。

---

4）把会话拆开：Events 和 State（这一步很多人没做）

我建议你把“会话数据”拆成两种：

Events：发生过什么（不可变日志）
• 用户说了什么
• 模型回了什么
• 调过哪些工具、工具返回了什么

Events 是“记录”，适合追溯，也适合让模型从最近的过程里学习（比如照着你的示例风格输出）。

State：现在是什么状态（可变快照）
• 当前任务进度
• 关键参数（比如用户已确认的需求点）
• 中间变量（比如提取出来的字段、已选方案）

State 是“控制面”，适合驱动流程。
重点：State 不会自动出现在对话里，需要你显式地注入给模型，比如一段结构化 JSON。

很多 Agent 失败就是因为：
• 只堆 Events（聊天记录越堆越乱）
• 没有 State（导致每一轮都像重开一局）

---

5）怎么解决“上下文变长变乱”？核心是“压缩”和“提纯”

这里不是让你粗暴截断，而是追求一件事：高信噪比。

常见做法我总结成三类：

① 截断（最简单）

只保留最近 N 轮，或者最近 M tokens。
适合短流程、对长期一致性要求不高的任务。

② 摘要（更通用）

定期把旧对话总结成“关键结论”，替换掉长段历史。
注意：摘要不是复述，而是“只保留会影响后续决策的点”。

③ 触发机制（工程化的关键）

不要每轮都总结，那样太贵。可以按这些条件触发：
• 达到轮数 / token 阈值
• 任务阶段完成（比如“需求确认结束”）
• 用户长时间不活跃（下一次进来时再做一次整理）

---

6）记忆（Memory）不是“多存点向量”这么简单

很多人做 Memory 的第一反应是：上向量库，把每轮对话都嵌入，然后相似度检索。

问题是：你会得到一堆碎片——重复的、过时的、互相冲突的。

我更认可的做法是把 Memory 当成一条“数据加工流水线”：

Step 1：抽取（Extraction）

从对话里提取“事实”和“偏好”，过滤寒暄和噪音。
比如：
• 用户是做跨境电商的
• 更喜欢要点式输出
• 目前在做一个客服 Agent

Step 2：整合（Consolidation）

新信息来了，要做判断：
• 更新（UPDATE）：用户偏好变了
• 删除（DELETE）：旧信息不再成立
• 忽略（IGNORE）：重复/无意义
• 新增（CREATE）：第一次出现的关键事实

这一步非常关键，不做整合，你的 Memory 会越用越乱。

Step 3：检索（Retrieval）

检索不应该只看“语义相似度”，还要看：
• 相关性（Relevance）
• 新近性（Recency）
• 重要性（Importance）

否则你会把“很像但不重要/过时”的东西也塞进上下文。

---

7）我自己做 Agent 时的一个小结：真正的难点是“上下文拼装”

把上面的东西落到工程上，其实就是每轮在做四件事：
1. 取信息：从会话、状态、记忆、知识库里取出可能相关的材料
2. 筛信息：按相关性/重要性/时效性排序，删掉噪音
3. 组信息：用固定模板把规则、证据、状态、问题拼成上下文
4. 写回去：把本轮的新事实抽取后写入记忆（最好异步，不阻塞用户）

做对这四步，模型不需要换最贵的，也能稳定很多。

---

8）给你一份“上下文工程自查清单”（强烈建议收藏）

如果你现在就想定位 Agent 为什么不稳，用这 10 个问题排雷：
1. 你的上下文里：规则/证据/状态有没有分区？还是一锅粥？
2. 你是“堆聊天记录”，还是“按任务动态拼装”？
3. 有明确 State 吗？还是每轮都让模型自己猜进度？
4. 工具返回结果有没有结构化放进上下文？还是散落在对话里？
5. 你如何控制 token？有截断/摘要机制吗？
6. 摘要是“复述”，还是“只保留影响后续决策的点”？
7. Memory 是否做新旧整合？还是只增不减？
8. 检索是否考虑时效性、重要性？
9. 上下文里是否存在冲突信息？谁来裁决？
10. 你能不能清楚说出：这一轮模型为什么会做出这个决定？（可解释性）

---

最后：如果你想把 Agent 做到“能上线”，上下文工程才是主战场

我写这篇不是为了抬概念，而是因为：
Agent 真的不是“提示词写得好看”就能搞定的东西。

你只要把上下文工程这件事做扎实，会明显感觉到：
• 回答更稳定
• 幻觉更少
• 任务推进更顺
• 成本也更可控

---

更加完善准确的文章内容在我的公众号:破茧Plan,欢迎关注.