我们遇到了什么问题如果你做过 AI 辅助分析工具，大概率踩过这两个坑：坑一：AI 结论忽好忽坏。任务流程一长，AI 就开始"飘"——用词精准、语气自信，但结论经不起推敲。更坑的是，你问它"你确定吗"，它会更加笃定地告诉你"是的，完全正确"。坑二：Token 越烧越多。上下文越堆越厚，每次启动都要把历史上下文全部重新喂给模型，Token 消耗线性增长，但分析质量不升反降。这正是我们团队在开发 CarPlay bug 分析工具时遇到的真实困境。AI 在多项目、长链路的 bug 分析中，分析报告质量严重不稳定；引入多 Agent 架构后，Token 消耗和运行时间又大幅增加。这两个问题，促使我们去找一套系统性的解决方案。一、Harness Engineering：给 AI 套上"缰绳"问题：不确定性是 Agent 的原罪大模型天生有随机性。在单轮对话里，这点随机性是创意的来源；但在长链路任务里，它是灾难的根源。一个典型的失控场景：你让 Agent 完成一个分 10 步的开发任务。前 7 步一切正常，第 8 步 Agent 稍微偏了一下，第 9 步继续往偏了的方向走，第 10 步你收到了一个看起来完整、实则驴唇不对马嘴的结果。你还没意识到问题，因为 Agent 写了一段很有说服力的总结。当 AI 开始连续执行时，如何监督并及时纠正，成了核心工程问题。方案：Agent = Model + Harness2026 年 2 月，Martin Fowler 团队（作者 Birgitta Böckeler）提出了Harness Engineering这个概念：Agent = Model（模型）+ Harness（约束框架）Harness是 Agent 里除了模型之外的一切东西——提示词、工具定义、规则约束、上下文管理、校验机制、反馈循环，全部统称为 Harness。这个定义乍看平淡，但背后有个重要的思维转变：要提升 Agent 的稳定性，不是换更好的模型，而是设计更好的 Harness。Harness 由两部分组成：Guides（前馈）：在 AI 行动前给它正确的输入——清晰的指令、相关的上下文、结构化的任务描述Sensors（反馈）：在 AI 行动后检验输出——独立的验证器、质量评估、异常检测LangChain 团队的实验很直观：在不换底层模型的情况下，仅靠 Harness Engineering，他们的 Agent 排名从 30 名以外提升到了前五名。解决：在问题到达人眼之前自动修正一句话概括 Harness Engineering 的目标：要让 AI Agent 在更少人工监督下工作，需要系统化地构建一套"外部控制框架"——Harness。它由前馈的 Guides 和反馈的 Sensors 组成，目标是在问题到达人眼之前就自动修正。二、单 Agent 的两个致命失败模式有了框架方向，我们来看单 Agent 具体会在哪里失控。Anthropic 在《Harness design for long-running application development》中识别了两类核心失败模式：失败模式一：上下文焦虑（Context Anxiety）任务太长，Agent 接近上下文窗口上限时会"焦虑"，开始草草收尾——把没完成的工作标记为完成，把模糊的分析写成确定的结论。这不是模型的 bug，是它在用"自信的收尾"来应对"不确定的延续"。解决方案：不是 Compact（压缩上下文），而是Context Reset——完全清空上下文，带结构化的交接文件启动新 Agent，让新 Agent 接棒继续工作。失败模式二：自我评估失灵让 Agent 评估自己的输出，它会"病态乐观"——即使结果很糟糕，它也会自我点赞，因为它的评估基于生成该结果时的同一套认知框架。就像让一个人同时做卷子又改自己的卷子，几乎必然高分。解决方案：引入独立的 Evaluator Agent，专门调教成"严格挑剔模式"，与 Generator Agent 完全隔离。这两个发现，直接引出了多 Agent 架构的第一个也是最核心的模式。三、多 Agent 架构：五种协作模式有些团队选模式时，依据的是听起来是否高深，而不是是否适合手头的问题。建议从可能奏效的最简单模式开始，观察它在哪里遇到困难，然后逐步演进。模式一：生成-验证（Generator-Validator）适合什么问题：输出质量至关重要，且评估标准能明确表述。工作原理：Generator 生成输出 → Validator 按明确标准评估 → 不通过则附带具体反馈退回 → 循环直到通过或达到最大迭代次数。Generator → 输出 → Validator ──通过──→ 完成 │ 不通过 + 反馈 │ └─→ Generator（下一轮）典型场景