Agent总在第十八步崩掉，问题可能不在模型

一条推文说，Andrej Karpathy 在 OpenAI 和 Tesla 待了 8 年，上周把学到的东西塞进一场免费两小时讲座，主题是 Agents、Harness、Loops、Graphs。推文还补了一句，有些 bootcamp 收 15000 美元，教得还没这多。视频被贴出来，评论区很快分成两拨。一拨收藏，说两小时顶一学期。另一拨追问：原链接呢，材料不是两年前的吗，别拿“上周”当钩子。有人直接骂 scam，说 8 年经验不可能压进两小时。

推文附的视频：

这些争执先放一边。Karpathy 的讲座我没法在素材里核对完整内容，但推文指向的另一份材料很具体：Lunar 写的《Harness Engineering: The Complete Guide to Building AI Agents That Don't Fall Apart》。这篇文章讲了一个被忽略的层。

多数人修 agent 的方式很固定。失败一次，改 prompt。再失败，加指令。还不行，换模型、加工具、扩上下文窗口。然后希望下一次运行乖一点。Lunar 的判断相反：很多 agent 失败发生在环境层，推理层未必有问题。agent 不知道哪些文件重要，工具用对但地方用错，上一轮的决定丢了，没跑检查就说完成，部分失败后重复动作，权限本该拦却没拦。模型未必有问题。模型外面的系统不完整。那个系统叫 harness。

harness 是什么。模型负责推理、生成、比较、选择。agent 还要理解任务、找上下文、用工具、保存状态、遵守权限、检查结果、从失败里恢复、证明工作完成。模型是 reasoning engine，harness 让推理变成可运行的工作。强模型放进弱 harness，还是弱 agent。单次回答可能漂亮，长任务、环境变化、部分失败一来，行为就不稳。harness 工程要做的，是把模型的不确定性关进一个能观察、验证、恢复的系统。消灭不确定性不现实。

Lunar 给了几个具体做法。任务开始前，把模糊意图变成任务契约：要什么结果，范围是什么，什么不能动，什么证据算完成，哪些动作要人批准。没有契约，agent 优化“看起来在干活”。有契约，它优化“可验证的完成”。上下文别一股脑灌进去。先给一张小地图，需要细节再检索。目标是每个 token 的最大信号。上下文越大越好，这个假设站不住。工具别堆二十个。每个工具要有清楚契约，隐藏无关工具，校验参数，限制路径和域名，加超时，让重试幂等，风险动作要确认，返回证据，别只返回 success。模型可以提议动作。工具网关决定动作是否足够合法。

还要把大脑、手、历史分开。推理、工具调用、文件、决定、错误、旧观察别全挤在一个越来越长的 transcript 里。模型需要当前状态，不需要每个原始事件。沙箱需要安全执行有边界的动作，不需要理解整个目标。会话日志需要保存上下文消失后发生了什么。长期 agent 因此更容易恢复、检查、修理。记忆也别只靠对话历史。对话历史是事件流。有用记忆要转成显式状态，至少保存决定、约束、未解决问题、证据。原始历史留着审计，持久状态拿来执行。

完成需要证据。agent 说 done 只是另一个模型输出。完成由环境里的可观察变化决定。先跑最便宜的确定性检查。编译器、schema、checksum、查询、测试能回答的，别叫另一个模型。模型处理歧义。代码处理管道。验证是尝试反证。第二意见不够。worker 想做出最强方案，evaluator 想找出应该被拒绝的理由。同一个 agent 在同一上下文里“再检查一遍”，常会保留制造错误的假设。验证阶段要有拒绝标准、产物、验收契约、独立工具或新上下文，还要有拒绝但不修复的权限。

策略要放在推理循环外面。后果越重，闸门越硬。自主需要边界。边界清楚，行动才自由。恢复也别只说“失败了，再试一次”。那是重复。先分类失败，再选下一步。重试至少改变一个相关条件，否则就是花钱复现同一个失败。循环要有预算：最大尝试次数、时间、花费、破坏范围、升级条件。可靠 agent 知道怎么继续，也知道什么时候继续不理性。

指令也有阶梯。规则反复重要，就往栈下面挪。prompt 解释判断，harness 执行不变量。观察运行，不只看最终答案。干净的最终产物可能藏着糟糕过程：访问错数据，忽略失败命令，外部动作重试两次，预算花十倍，答案对但理由错。trace 要能重建运行：状态转换、上下文来源、工具输入输出、环境变化、验证结果、重试原因、审批决定、成本和延迟。目标是局部修复，不做监控。第 18 步失败，从可信检查点重启，别重放整场。每次运行生成变更收据。变更收据只写系统能证明什么。给人类紧凑审查面，也给下一轮 agent 可信起点。最好的交接给状态、证据、未解决风险。只给对话不够。

每次失败应该升级 harness。弱团队修失败输出。强团队也修允许它发生的系统。把教训变成可复用改进。改一个答案帮一次运行。改一个 harness 帮未来每次运行。harness 也会衰退。模型变好，工具变好，任务变，旧保护会变成摩擦。昨天模型的 workaround 可能挡住今天模型的好策略。把 harness 组件当生产代码。量它是否还有提升。每个 router、evaluator、memory layer、retry rule 都问：它防哪种失败，这种失败还常发生吗，加了多少延迟和复杂度，现在能不能更简单达到同样结果，删掉会怎样。最好的 harness 往往最小，能可靠闭合意图和证据之间的差距。Build to delete.

最小可行 harness 不用先上平台。分层建。第一层，有边界的任务：目标、范围、约束、验收检查。第二层，可读环境：项目地图、命令、本地说明、已知依赖。第三层，受控动作：typed tools、参数校验、路径和权限边界、结构化结果。第四层，持久执行：显式运行状态、检查点、决定、教训。第五层，证据：确定性检查、对抗验证、变更收据。第六层，恢复和学习：失败分类、有界重试、升级、从反复失败更新 harness。从消除你实际有的失败的最小层开始。别因为一个 prompt 偶尔需要澄清就上多 agent 架构。复杂度要由观察到的失败挣来。

衡量系统别只看 token，也别只看尝试了多少任务。有用单位是 accepted work。看首次通过率、工具失败后恢复率、重复失败率、每任务人工介入次数、无证据完成声明、从请求到验证结果的时间、各组件 harness 开销。agent 可以看起来很忙，同时制造昂贵审查工作。目标落在每单位人类注意力产生的可信结果上。agent 活动多不多，不是核心。

并非每个模型调用都需要重 harness。任务短、输出容易检查、失败便宜、没有外部副作用、用户还在环里，简单 prompt 就够。工作跨多个工具或会话、环境会变、动作有真实后果、完成难人工判断、同一失败反复出现、人工审查成瓶颈，再加 harness。harness 的目的落在真实工作可靠。demo 显得复杂，没有意义。

推文里那句“收藏，别被信息流埋掉”没错。但收藏之前，先找原链接，先看时间线。两小时讲座值不值得看，是一件事。一条推文是否把两年前材料说成上周，是另一件事。Agent 也一样。模型值不值得换，和 harness 有没有把失败类别、证据、权限、恢复讲清楚，是两件事。先把环境搭对，再谈模型聪不聪明。