—— 从经验教训到系统性工程的深度复盘
前言：为什么你的AI Agent总是不稳定？
你是否遇到过这样的情况：
- AI Agent一开始表现很好，但越用越"笨"
- 多个AI Agent协作时，各自为战，信息互相干扰
- Agent失败了只会说"重试"，却不知道为什么失败
- 任务做到一半，换了个会话，所有上下文都丢了
这些问题一度让我很困惑。经过无数次复盘、纠错，才发现：不是模型不够强，而是我们的"底盘"不扎实。
一、问题的根源：我们在用"装修队"的思维建"地基"
1.1 一个形象的比喻
文章把AI Agent比作"Model + Harness"：
- Model = 引擎，决定"跑多快"
- Harness = 底盘/悬挂，决定"能不能跑稳"
我们团队一开始的状态：天天比谁家屏幕大（哪个模型更强），没人关心底盘过弯会不会散架。
1.2 两类工程的本质区别
AI开发里有两类完全不同的工程。
| 类型 | 定义 | 例子 | 会不会过时？ |
|---|---|---|---|
| 补偿性工程 | 用代码弥补模型能力不足 | 模型窗口太小，写分块检索 | 会，模型变强就删掉 |
| 系统性工程 | 任何智能体在真实环境都必须面对的问题 | 上下文管理、错误恢复、反馈回路 | 永远不会过时 |
我们犯的错误：把大量精力放在"补偿性工程"上，今天调这个Prompt，明天换那个框架，却忽视了真正重要的"系统性工程"。
二、深度复盘：我们的AI Agent团队出了什么问题？
2.1 问题一：上下文污染（Context Pollution）
现象：
- Musk讨论的技术细节会干扰张小龙的专业判断
- 子Agent拿到任务时，上下文里塞满了不相关的信息
- 模型越来越"犯糊涂"，不是因为能力下降，而是信息过载
根因："上下文不是数据，上下文就是程序本身。"
当Agent的上下文被无关信息污染时，它的推理质量就会下降。这就像让你在嘈杂的菜市场做数学题，噪音不会让你变笨，但会严重影响你的发挥。
2.2 问题二：错误处理只会"重试"
现象：Agent失败了 → 重试3次 → 还失败 → 告诉用户"出错了"
根因："当Agent出错时，解决方案从来不是让它再试一次，而是去思考：模型缺了什么能力或信息？"
| 类型 | 原因 | 正确处理方式 |
|---|---|---|
| 环境故障 | 网络超时、API挂了、文件不存在 | 传统重试/降级 |
| 智能故障 | 模型误解、缺信息、缺能力 | 不重试，分析根因 |
关键转变：从"retry until success"到"analyze then act"。
2.3 问题三：任务结果"有去无回"
现象：任务完成了，Agent说"好了"，会话结束，上下文全部丢失，下次会话时所有信息要从头开始。
根因：没有建立"任务结果自动写入memory"的机制。
2.4 问题四：决策边界模糊
现象：Agent不确定什么能做、什么不能做，遇到问题就问，或者擅自做主。
根因：没有明确定义"可自主决策的边界"。
三、解决方案：从"经验主义"到"系统性工程"
3.1 解决方案一：上下文隔离规范
核心原则：子任务用独立session，防止上下文污染
三层机制：
- Layer 1 隔离：每个子任务有独立上下文，只传递必要信息
- Layer 2 按需注入：模型需要什么，在它需要的时候再给
- Layer 3 压缩：定期压缩上下文，保留关键信息
3.2 解决方案二：错误分类与处理体系
核心原则：先分类，再处理，不是所有错误都适合重试
处理流程：
Agent失败 → 环境故障？→ 网络超时→重试+配置
→ API 500→降级+记录
→ 智能故障？→ 误解意图→补充指令
→ 调错工具→优化描述
→ 幻觉→增加验证环节3.3 解决方案三：任务结果自动写入Memory
核心原则：每次任务完成，自动提取关键信息写入持久化存储
写入规范（L0/L1/L2分层）：
- L0: 一句话总结任务结果（不超过50字）
- L1: 核心要点（2-3条，每条不超过30字）
- L2: 详情（任务目标、关键产出、下一步）
触发机制：事件驱动，而非定时检查。
3.4 解决方案四：可自主决策边界定义
三类边界：
| 边界 | 可以自主 | 需要请示 | 禁止自主 |
|---|---|---|---|
| A | 信息检索、工具执行 | 外部系统变更、费用 | – |
| B | 错误处理、任务分解 | 多Agent协调、生产环境 | – |
| C | – | – | 删除操作、外部通信、凭据 |
核心原则：宁可多问，不可擅自行动。
四、实际成果：系统性工程带来的改变
| 指标 | 优化前 | 优化后 |
|---|---|---|
| 上下文污染 | 频繁发生 | 已建立隔离机制 |
| 错误处理 | 盲目重试 | 分类处理，智能故障分析根因 |
| 任务结果保存 | 依赖人工，容易遗忘 | 自动触发，写入memory |
| 决策边界 | 模糊不清 | A/B/C三类边界明确 |
Before："AI Agent不就是调Prompt吗？模型强就行了。"
After："AI Agent的核心竞争力不在于模型多强，而在于系统性工程多扎实。"
五、经验总结：为什么系统性工程更重要？
文章有一个精彩的比喻：
CPU的性能在过去几十年提升了几百万倍，但我们并没有因此不再需要操作系统、数据库、编译器。
原因：每一次底层能力的提升，都会淘汰一批"补偿性工程"，同时让"系统性工程"变得更更重要。
- 底层能力越强 → 你能构建的系统越复杂
- 系统越复杂 → 越需要精心的工程设计
5.2 对AI Agent团队的启示
| 认知 | 说明 |
|---|---|
| 模型是引擎，Harness是方向盘 | 模型决定上限，Harness决定能不能稳定交付 |
| 系统性工程不会过时 | 上下文管理、错误恢复、反馈回路 |
| 上下文就是程序本身 | 不是存储数据，而是决定模型的行为 |
| 错误不是bug，是概率系统的本性 | 接受它，管理它，而不是单纯retry |
5.3 行动清单
- 建立错误分类体系（环境故障 vs 智能故障）
- 强制子任务新建session，防止上下文污染
- 定义Agent的决策边界
- 实现上下文长度监控，超阈值自动压缩+保存
- 建立任务结果自动写入memory的机制
- 封装可复用的Skill，减少重复开发
结语
AI Agent的构建，就像造一辆车。Model决定了发动机有多强，但Harness决定了能不能安全、稳定、持续地跑下去。
不要只关注发动机，忽略了底盘。
当你花时间把"系统性工程"做好，会发现：
- Agent表现越来越稳定
- 协作效率越来越高
- 人工干预越来越少
这不是在弥补模型的不足，而是在构建真正可靠的生产系统。