上周一个做 Agent 集成的工程师来问我：「我的 Agent 前十步表现很好——读文档、列计划、写代码，都很干净。但到第 30 步左右就开始胡来：调错 API，覆盖自己刚改过的文件，甚至重复执行已经做完的操作。我是不是该换个更强的模型？」
我问他：每次都栽在同一个地方吗？他想了想说，不是，但跑得越远越不稳。
我说，那多半不是模型的问题。 它是走出了灯光照亮的地方。
无独有偶，今年 YC Startup School 上，主持人 Diana Hu 向 Jeff Dean 提了几乎一模一样的问题：「Agent 在前 10 步都很棒，到第 50 步就开始晃了。你觉得今天的瓶颈是什么？」Dean 的回答，是我见过对这个现象最准确的解释。
一、翻车的机制：不是变笨，是偏离了分布
Dean 的解释很直接：
模型是在一整套它见过的事情上训练的。一旦你稍微离开它知道怎么做的分布，就像大多数机器学习模型一样，它的性能会突然开始退化。离舒适区越远，越容易不工作。
注意「突然」这个词。这解释了一个很多人观察到的现象：Agent 的失败不是线性的——不是第 20 步错一点、第 40 步错更多，而是前 29 步一切正常，第 30 步突然开始连环错。
这里要回应一个常见的直觉：长程失败不是因为误差累积吗？每一步错一点，越积越多，最后崩了——听起来很合理。
但误差累积描述的是 斜坡：错误缓慢增加，你随时能发现、能修。Dean 描述的是 悬崖：只要任务还在模型的训练分布里，每一步都是高质量的；一旦跨出边界，性能不是缓慢下滑，而是陡然劣化——而劣化之后的每一步操作，又会把它推向更偏的地方。这就是为什么翻车看起来是「突然」的：你看到的不是第 30 步的错误，是第 29 步跨出边界之后的连锁反应。
区分这两者很重要，因为对策完全不同。误差累积靠「每步更仔细」解决；偏离分布靠「别走出光区」解决。
二、换更强的模型，只是把光的边界往外推了一点
「换个更强的模型」是最常见的对策，也是最容易让人失望的对策。
更强的模型意味着训练分布更宽——光的边界确实往外推了。但你的业务是你自己的：你们公司怎么走审批、这套老系统的历史包袱在哪、这个客户的特殊约定是什么——没有任何通用模型在这些事情上训练过。你的长程任务每往深处走一步，都在往通用模型没见过的区域走。边界推得再远，也追不上你业务的纵深。
这正是我在 AI 的竞争变了：未来是上下文的竞争 里那个判断的工程版本：私有上下文是访问权问题，不是能力问题。在长程任务上，它表现为：模型缺的不是智能，是你那条路上的灯。
三、把 Agent 留在光里的三件事
Dean 在对谈里给了三个解法。我把它们和我们自己的实践对照了一遍，发现每一条都有对应的工程落点。
第一，用 Skill 在路上铺灯。
Dean 的原话是：给模型配 Skill 和提示，让它留在「灯光照亮的路径」上。Google 内部就是这么干的——他们给 Agent 配了一整套 Skill，教它用内部专有的开发工具：代码评审、性能测量、拉日志。这些工具模型从没在训练里见过，但 Skill 定义得当，Agent 就能在陌生区域里照常工作。
这和我在 Jeff Dean 把最值钱的东西公开了：Skill 是组织知识的新载体 里讲的是同一件事的两面：对知识管理，Skill 是组织经验的载体；对长程任务，Skill 是模型分布外的路灯。你的任务每延伸进一段模型没见过的区域，就需要一段 Skill 去铺路。
第二，用 Harness 让每一步有后果。
光铺了路，还要知道 Agent 走没走对。Dean 说 Google 内部的做法是 Harness 加 Skill 配合——Harness 提供每一步的验证信号。
这是我们亲手验证过的。在 对 Coding Agent 最友好的，是端到端测试 Harness 里讲过那个案例：Agent 三轮迭代都汇报「测试通过」，实际上把登录按钮删了——因为它没有任何手段看见最终页面。Harness 的作用不是让 Agent 更聪明，是让它的每一步决策都有可验证的后果：对 Coding Agent 是构建、测试、截图；对长程分析任务是阶段性产出加检查点。
落到结构上，一个带 Harness 的长程循环大致是这样：
while not task.done():
step = agent.plan_next()
result = execute(step)
if not harness.verify(step, result): # 每步都要有后果
agent.rollback(step) # 错了就退回来
agent.replan(context=result) # 带着失败信息重新规划
checkpoint.save(agent.state()) # 里程碑存档 + 上报给人
# generated by hugo AI
没有 Harness 的长程任务，是闭着眼走夜路；有了它，Agent 在第 31 步走偏时，第 32 步就能知道——悬崖被拆成了可以折返的台阶。
第三，用多 Agent 搜索代替单 Agent 硬闯。
Dean 的第三个解法最容易被忽略：让多个 Agent 尝试不同的解法，再用另一个 Agent 评估哪条路更有希望，丢弃走偏的，沿着有希望的继续。他把这叫「推理时计算做搜索」。
这其实是把「探索」和「判断」拆成了两个角色。单个 Agent 硬闯长程任务，就像一个人举着手电筒在陌生森林里走——手电一偏就迷路。多个 Agent 加一个评估者，等于一支带着探照灯的小队：有人试错，有人纠偏，走偏的成本被限制在单条分支里，不会污染主路径。
四、设计长程任务前的三个问题
把上面三条收拢成一个设计清单。下次接到一个要跑几十步的 Agent 任务，先回答三个问题：
- 这个任务会延伸出模型「灯光区」多远？ 判断标准很简单：任务里有多少环节是「只有你们组织才知道怎么做」的。每多一段，就准备一段 Skill。
- 每一步的正确性怎么廉价地验证？ 有现成的验证手段（测试、健康检查、格式校验）就接上 Harness；没有就先造验证手段，再放 Agent 上路。造不出验证手段的环节，留给人。
- 翻车了谁能第一时间发现？ 这一半靠 Harness，另一半靠通信协议——Agent 要在里程碑和异常点主动上报，而不是等人类来问。这部分我在 Agent 跑了两小时，你一无所知：长程任务的人机通信协议 里拆过。对人类，检查点是里程碑；对 Agent，检查点是 Eval。
顺带说一句：Dean 在对谈里还提到，已经可以让 Agent 连续跑几天甚至几周，去完成「把整个软件翻译成另一门语言」这种量级的任务。长程不是未来的事，是已经发生的事——只是大多数人还没意识到，能跑几周的前提，恰恰是上面这三件事做对了。
写在最后
回到开头那位工程师的问题：该不该换更强的模型？
可以换，但别指望它解决问题。Agent 不是跑到第 30 步就抛锚的车，是走出灯光的人。管理者的工作不是给它换一台更大的发动机，而是把路照亮——Skill 铺灯，Harness 验路，多 Agent 探路。
灯亮到哪里，Agent 就能可靠地走到哪里。你的长程任务里，哪一段还没有灯？欢迎留言聊聊。