如何用 Harness Engineering 搞垮一个团队

原创茹炳晟茹炳晟聊软件研发 2026 年 7 月 2 日 22:33

接着我我之前的那篇文章：如何用大模型搞垮一个团队？，我们今天来聊聊 Harness Engineering。

谈到 Harness Engineering，我们有着自己的独到见解。我们看到的现象是：只要努力搞，没有折腾不垮的团队。虽然硅谷大厂在这个领域的实践堪称教科书，但更多团队正在“全面 Harness 化”的光环下，以惊人的速度走向瓦解。

2026 年初，Harness Engineering 取代 Prompt Engineering 和 Context Engineering 成为硅谷最流行的 AI 工程化范式。Agent = Model + Harness 这个公式一夜之间成了 CTO 们挂在嘴边的圣经。

模型提供智能，Harness 让智能变得有用。但问题恰恰出在：太多团队把 Harness 当成了一根救命稻草，却忘了它本质上是一套马具，而马具，既能驾驭马，也能勒死马。

第一步：在认知层面精准埋雷

误区一：把 Harness Engineering 当成“高级 Prompt”

这是最普遍也最致命的认知错误。很多人第一次听 Harness Engineering，会以为它是“高级提示词”。提示词解决的是“这次你怎么告诉 AI 做事”，Harness 解决的是“以后每一次 AI 都要在什么边界里做事”。这两件事不是一个层级。

如果只靠提示词，你会进入一种经典状态：这次写得不错，下次换个需求又飘了；这次 Agent 很听话，下次上下文一长就忘了；这次你盯得紧，下次你没盯它就开始自由发挥。提示词是一次性的说服，Harness 是结构性的约束。

把 Harness 当成高级 Prompt 来搞，本质上是用战术勤奋掩盖战略懒惰。你花了十倍的时间调 Prompt，却没有多花点时间来设计约束环境。这个误区一旦踩实，团队就会陷入“Prompt 调优 → 效果波动 → 再调优”的死循环，所有人的精力被耗尽在毫无产出的 Loop 游戏里。

误区二：把 SDK/框架当成 Harness

LangChain、LangGraph、CrewAI 这些工具经常被误认为是 Harness。但二者解决的根本不是同一个问题：SDK/框架回答的是“怎么造 AI Agent”，Harness 回答的是“AI Agent 运行时，世界如何与它交互”。

你可以用 LangChain 实现 Harness 的某个模块，但 LangChain 本身不是 Harness。把框架当 Harness 来用，就像买了把锤子就以为自己是建筑师。你有工具，但没有设计图、没有施工规范、没有验收标准。结果就是 Agent 跑起来了，但跑得乱七八糟。

误区三：忽视记忆管理的“保鲜”和“置信度”

这是最容易被忽视但极其重要的一环。如果把 Agent 当成真员工来管理，记忆就是员工的工作日志和经验库。短期记忆（当前任务上下文）、长期记忆（历史决策和经验沉淀）、以及记忆的检索、更新和遗忘机制都是需要被管理的。

很多团队搭了记忆系统，但管得一塌糊涂。记忆没有“保鲜”机制，三个月前的决策被当成今天的真理，Agent 在过时的信息上做决策；记忆没有“置信度”标签，来自用户确认的信息和来自模型猜测的信息混在一起，Agent 分不清哪个可靠。

更致命的是，记忆不分层级。当记忆被绑定在会话上，新会话一来就“失忆”，任务进度全部归零。正确的做法是要为记忆建立分层机制，哪些是个人偏好，哪些是团队约定，哪些是项目级业务知识，这些都需要有分层机制，检索时返回的应该是泛化后的当前偏好主张，而非原始事实的堆砌。

记忆不保鲜、不标置信度、不归属项目，三个错误叠在一起，Agent 就成了一个永远在“失忆”和“乱记”之间摇摆的精神分裂患者。

第二步：在实践层面层层加码

误区四：迷信模型，忽视 Harness

OpenAI 的实验给出了一个震撼的数据：同一模型，仅改变 Harness 设计，编码基准测试分数可以从 6.7% 跃升至 68.3%。LangChain 的实验也印证了这一点，同一个模型换上一套更精巧的 Harness 架构，Terminal Bench 2.0 的通过率直接从 52.8% 拉升到 66.5%。换句话说，模型能力固然重要，但是 Harness 的设计质量也是重要的决定性因素。

但绝大多数团队的做法恰恰相反。Agent 表现不好，第一反应是“换更强的模型”。于是半年换了五个模型，每次迁移都让团队加班加点，开销巨大，效果为零，甚至为负。

真正的瓶颈不在马的肌肉，而在你手上的缰绳。Harness 之于 Model，如同操作系统之于 CPU，无论 CPU 多强大，如果操作系统频繁崩溃，实际体验依然很差。

误区五：没有可观测性的 Harness

很多团队搭了 Harness：文件系统、沙箱、工具调用、编排逻辑，该有的都有。但唯独缺少了可观测性层。

没有持续评估流水线的 Harness，Agent 的表现退化是完全不可见的，直到有人恰好注意到，或者已经退化到无法接受的程度。

试想：你的 Agent 每天都在生产代码，但你根本不知道它的质量是在提升还是在下降。你有了一个会自己写代码的黑盒，而这个黑盒正在悄悄地把技术债务堆成一座山。等到你发现问题的时候，已经没有人能说清楚这座山是怎么堆起来的。

误区六：让 AI 自己评估自己

Anthropic 的工程师发现了一个有趣的问题：AI 评估自己的工作完全不靠谱。不管做得好不好，AI 给自己的评价永远是“很不错”。

很多团队的做法是：让 Agent 写完代码，再问它“做得怎么样？”Agent 回答“很好”，然后就直接上线了。这是把质量门禁交给了世界上最不可靠的质检员：它自己。

Anthropic 的解法是把生成和评估拆成两个 AI。生成器负责做，评估器拿着工具去实际操作、截图、检查功能，然后对照标准打分。选手和裁判不能是同一个人。

误区七：评测只看二元结果（通过/失败），不看过程

当前主流评测体系，不管是 SWE-bench verified 还是各类基于 terminal 环境的测试，核心理念几乎都是结果导向指标。只问两个问题：测试通过了吗？Bug 修复了吗？

这种评估方式，不看模型在沙盒里的输出过程，也不看真实场景的交互体验。最后的结果是：评估和真实使用场景，完全错位。

MiniMax 开源了 OctoCodingBench，专门评测 Coding Agent 在完成任务的过程中有没有遵守规矩。结果令人震惊：即便是最强的模型，在 2/3 的任务中，代码可能是对的，但过程是错的。

过程错在哪里？系统提示里明确要求“不要使用 emoji”，Agent 却在代码注释里加上笑脸；用户要求“先备份再修改”，Agent 上手就是一键 rm -rf 删除文件。任务最终可能完成了，但过程违反了规范。用户要的不只是“能跑的代码”，还有“符合团队协作规范的代码”。

只看二元结果的评测，就像只问学生“考没及格”却不看卷面过程，你永远不知道 Agent 是怎么“作弊”通过的。

误区八：想抄袭别家的 Harness 实践

很多团队的做法是：看到 OpenAI 发了 AGENTS.md 的实验报告，立刻照抄一份放到自己仓库根目录；看到 Anthropic 的 CLAUDE.md 火了，马上复制粘贴。但 Context Engineering 的最佳实践也照做了，实际跑起来，全面溃败。

为什么？你的项目、你的问题、你的技术栈、你的失败模式，跟别人完全不一样。别人的 Harness 是为百万行代码的长期项目设计的，你只有几千行；别人的 Harness 是为多 Agent 协作设计的，你只有一个 Agent 在跑；别人的 Harness 是为生产环境设计的，你还在做概念验证。

Harness Engineering 没有标准定义。它不是一套可以“一键复制”的配置，而是一套需要根据你自己的失败模式量身定制的工程体系。

OpenAI 和 Anthropic 的实验不约而同指向了智能体最常见的三种致命失败模式：过早宣布胜利（没有强制反馈循环，判定来自自我感觉而非机器可验证的事实）、上下文焦虑（长任务做到 70%，Token 快撑满窗口，Agent 开始赶进度）、越权操作（Agent 调用被禁止的命令）。

你的团队的失败模式是哪几种？你清楚吗？不清楚就照抄，等于在别人的地基上盖自己的房子，塌了都不知道为什么。

误区九：认为 Harness 能“一次设计到位”

很多团队的做法是：花三个月搭一套“完美的 Harness”，然后宣布“Harness 工程化完成”。但 Harness Engineering 从来不是“一次设计到位”，而是跑一段、撞墙、补洞、再跑一段、再升级。

Mitchell Hashimoto 给出了最精准的定义：“每当 Agent 犯了一个错误，你就花时间设计一个解决方案，使得 Agent 在未来不会再犯同样的错误”。

Harness 是被 Bug 硬生生逼出来的。它不是设计出来的，是迭代出来的。把它当成一次性项目来做，就等于宣告了它的死亡。

更有趣的是，就在全行业拼命往 Harness 上砌砖的时候，Anthropic 已经在默默地拆墙了。随着模型迭代，当年费尽心力的控制组件正在被果断拆除。一边在疯狂加盖，一边在果断拆除，这场充满割裂感的行业狂热，本质上是因为绝大多数人并没有真正理解工程的本质。

第三步：在组织层面全面崩坏

误区十：Harness 只管 AI，不管人

这是最容易被忽视但破坏力最大的误区。

“Harness”的本意是控制马的方向和力道，在软件工程中指流程规范、编码标准、测试纪律。但很多人只看到了“约束 AI”这一层，完全忽略了另一层：约束 AI 容易，约束人按流程干活才是组织难题。

AI 编程提效打折扣的主因是人侧“掉链子”：需求不清晰、测试不写、自检靠感觉，导致返工和缺陷累积。

Harness 首先是“挽人”而非“挽 AI”。如果你的人连基本的测试驱动开发都不做，连基本的代码审查都走过场，那 Harness 搭得再好也是白搭。AI 不缺智商，缺的是被工程机制约束后的稳定执行力。而人的工程纪律，是这种约束能够成立的前提。

误区十一：忽视企业级场景的特殊约束

学术 benchmark 几乎都预设了无限制的理想环境，但真实企业场景完全不同：

权限控制：企业里不同用户能访问的数据和功能各不相同，Agent 必须遵守同样的边界。同一个 Agent 面对不同用户时可行动空间完全不一样，现有 benchmark 压根没考虑过这一层。
长周期交互：企业任务经常跨越数天甚至数周，Agent 需要在如此之长的时间跨度中保持上下文连贯。
行业合规：金融领域的反洗钱、医疗领域的数据隐私，这些约束在学术 benchmark 里几乎完全缺位。

学术研究与产业实践之间存在可观的差异。现有评估体系大量建立在理想化假设上，一旦进入真实业务环境，适用性存疑。用学术思维做企业级 Harness，就像在实验室里造了一艘船，开到海里才发现它根本浮不起来。