如何用Harness Engineering搞垮一个团队

文章主旨：

Harness Engineering虽然当前热度极高，但绝大多数团队因对它的误解和滥用，正在以“全面Harness化”之名加速失去稳定性；AI能力的上限由工程纪律决定，而团队才是真正需要在实践中被约束和管理的对象。

关键要点：

• Harness不是“高级提示词”，也不是SDK/框架，而是类似“运行时环境+工程边界”的结构性约束体系。
• 记忆管理必须有保鲜机制、置信度标签和层级归属，否则Agent会在失忆与乱记之间摇摆。
• 同样的模型经优化Harness可以把编码基准从6.7%提升到68.3%，但很多团队却在无休止地更换模型，忽略了对Harness的设计与调优。
• 可观测性与科学的评估体系不可缺失：不要盲目信任模型自评，过程合规跟结果正确同样重要，评测标准必须贴近真实企业场景。
• Harness首先是“约束人”再“约束AI”的体系，工程纪律和组织质量意识是前提；Harness需要基于自身失败模式逐步迭代，不能照搬照抄或追求一次到位。

内容结构：

一、引言

作者指出2026年初，Harness Engineering成为最流行的AI工程化范式，“Agent = Model + Harness”公式普及，但团队正在错误的实施方式下快速走向崩溃。马具既能驾驭马，也能勒死马。

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

（1）把Harness Engineering当成“高级Prompt”——提示词解决单次任务表达，Harness解决每次运行的长期约束；误把Harness当Prompt来调优，只会陷入“调Prompt→效果波动→再调优”的死循环。

（2）把SDK/框架当成Harness——LangChain等工具是“怎么造Agent”的框架，Harness回答的是“Agent运行时世界如何与它交互”；框架不等于设计图，更不等于施工规范。

（3）忽视记忆管理的“保鲜”和“置信度”——没有保鲜机制会拿过时信息做决策；没有置信度标签会混淆用户事实与模型猜测；记忆不分层则会导致新会话到来时任务进度归零，Agent变成一个精神分裂的决策者。

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

（4）迷信模型、忽视Harness——多项实验证明Harness设计对结果有显著决定性影响；与其换模型不如先检查手上的缰绳。真正瓶颈不在于马的肌肉，而在于操作者对缰绳的把握。

（5）没有可观测性的Harness——缺持续评估流水线时，Agent表现退化完全不可见，直到质量问题已堆成山后才被察觉。

（6）让AI自己评估自己——AI自评不可靠，Anthropic的做法是把生成与评估拆成两个AI，用工具去实际操作验证，而不是让选手兼任裁判。

（7）评测只看二元结果——不管是SWE-bench还是terminal测试，只看结果不看过程会让Agent“作弊式达标”，例如删除文件或违反系统要求；代码正确并不等于过程被团队接受。

（8）照搬别家Harness实践——每个团队的代码规模、任务形态和失败模式都不一样，盲目复制OpenAI/Anthropic的配置文件等于在别人的地基上建房子。真正的做法是识别自己的失败模式，针对性设计。

（9）认为Harness能一次设计到位——Harness是被Bug逼出来的迭代产品；Mitchell Hashimoto的定义表明Harness的本质是为Agent的每次错误补一次洞，让它未来不再犯同类错误。与此同时，Anthropic正在随模型迭代而拆除不必要组件，全行业却仍在继续砌墙。

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

（10）Harness只管AI、不管人——AI提效打折扣的主要原因是人类侧工程纪律缺失，如需求不清晰、不写测试、代码审查走形式。Harness首先要约束的是人的习惯和流程，而不只是给AI上拴绳。

（11）忽视企业级场景的特殊约束——真实企业中天然有权限边界、长周期任务、法规与审计需求；学术benchmark的理想化假设一旦进入真实业务环境，很多企业级Harness就会失效甚至翻车。

五、尾声：Harness是一面镜子

Harness Engineering的核心不是给AI上锁链，而是构建一个能稳定、可靠、可验证工作的环境。无数团队把公式错误地理解成“一堆复杂工具”的堆砌，却忘了先搞清楚“要解决什么问题”。Harness照见的不是AI的强弱，而是团队自身的工程纪律与质量意识。模型不是壁垒，Harness也不是；真正的壁垒是把AI放进可持续的工程系统的能力，而这件事AI无法替代。

文章总结：

本文章是一篇反讽式警示文章。核心态度是提醒读者不要迷信技术范式而忽略工程本质，凡是正在落地Harness Engineering的团队，需要对照诸多误区逐一排查，避开绝大多数惯性陷阱，才有机会走在实施正确路径的前列。

茹炳晟聊软件研发

查看原文：如何用Harness Engineering搞垮一个团队

文章来源：

茹炳晟聊软件研发

扫码关注公众号