5.3 真实案例——好的 Agent 与坏的 Agent
理论讲了很多，来看看真实世界的故事。三个案例——一个成功、一个失败、一个惊险。
案例一：Cursor Agent 的第一次实战 ✅
一位开发者用 Cursor Agent Mode 从零搭建一个广告公司门户网站。他记录了完整过程——包括好的、坏的、和戏剧性的时刻。
好的部分
Agent 在实现具体功能上表现出色：
- 路由配置、组件搭建、样式实现——这些「定义明确的任务」，Agent 几乎一遍过
- 对于「做一个导航栏」「加一个表单」这类需求，Agent 的速度是人工的 5-10 倍
坏的部分
Agent 在理解业务意图上频繁出错：
- 「让页面更有吸引力」→ Agent 加了花哨的动画，但不符合品牌调性
- 「优化用户体验」→ Agent 改了布局，但破坏了信息层次
戏剧性的部分
Agent 做到 80% 的时候，突然开始「越改越差」——每改一个地方就破坏另一个。开发者意识到 Agent 的上下文已经「疲劳」了——太多修改历史让它迷失了方向。
解决方案：开新对话，只给 Agent 最新的代码状态和具体的修改需求，跳过所有历史。
教训
| 教训 | 行动 |
|---|---|
| Agent 擅长「怎么做」，不擅长「为什么做」 | 业务决策由人做，Agent 负责实现 |
| 上下文会「疲劳」 | 长任务拆成短对话，每次给干净上下文 |
| 80% 分水岭 | 前 80% 让 Agent 做，后 20% 人工精修 |
案例二：4 美元的递归执念 ❌
一位开发者设计了一个代码审查 Agent，让它审查一个 Pull Request 的变更。
PR 只有 3 行变更——一个简单的变量重命名。但 Agent 的反应是：
步骤 1：读取 PR 变更 → 3 行改动
步骤 2：分析变更影响 → 需要检查是否有其他引用
步骤 3：搜索整个代码库中的旧变量名 → 找到 47 处引用
步骤 4：逐一检查每个引用 → 分析是否需要修改
步骤 5：发现一些引用在不同模块 → 需要分析模块依赖
步骤 6：分析模块依赖图 → 发现间接依赖
步骤 7：检查间接依赖是否受影响 → 更多文件需要分析
……结果：Agent 花了 4 美元来审查一个 3 行的变量重命名。它陷入了「递归执念」——每发现一个新线索就追下去，无法停止。
教训
"让 Agent 行动不难，难的是让它知道什么时候该停。"
这是 Agent 设计中最核心的问题之一——终止条件。
解决方案：
- 设步骤上限：超过 20 步自动停止
- 设成本上限：超过 $1 自动停止
- 定义「足够好」的标准：变量重命名只需检查直接引用，不需要追到间接依赖
- 用 Plan-Execute 模式：先规划审查范围，再执行，而不是边查边扩大范围
案例三：AutoGPT 2023 vs Claude Code 2025 🔄
同一个任务——为开源项目写贡献指南，用 2023 年的 AutoGPT 和 2025 年的 Claude Code 分别执行。
两年代价换来了什么？
- 执行边界：子代理有明确的任务范围，不会无限扩大
- 成本控制：fork 隔离减少了上下文膨胀
- 模式升级：从纯 ReAct（边想边干）到 Plan + Explore（先搜索再综合）
- 记忆管理：子代理只返回摘要，不把所有中间结果塞进主对话
三条通用经验
从三个案例中提炼出的通用经验：
经验一：定义「完成」比定义「开始」更重要
Agent 天然倾向于「再多做一点」。你必须在指令中明确：什么是「完成」的标准，什么时候该停。
经验二：上下文是消耗品，不是积累品
对话越长，Agent 的表现越差。长任务拆成短对话，每次给干净上下文，比一次长对话效果好得多。
经验三：人做判断，Agent 做实现
Agent 擅长「怎么做」，不擅长「为什么做」和「做得对不对」。业务决策、质量判断、安全审查必须由人来做。
本节核心要点
- Agent 擅长实现具体功能，不擅长理解业务意图
- 「递归执念」是 Agent 最常见的行为问题——设步骤上限和终止条件
- 2023 到 2025 的进步：执行边界、成本控制、模式升级、记忆管理
- 三条通用经验：定义完成标准、拆分上下文、人做判断 Agent 做实现
思考题：回想你使用 AI 编程工具最满意和最不满意的一次经历，它们分别对应了今天讲的哪条教训？
下一节预告：最后一站——练习与巩固。概念题、设计题、综合实战，把学到的知识变成真正的能力。