这两个月， Harness Engineering 这个词在开发者圈里冒头很快。 OpenAI 写了自己的实践， Anthropic 讲长时运行 agent 的 harness ， Martin Fowler 也单独拉出文章讨论， Red Hat 甚至把结构化工作流拆成了可执行模板。表面看，这像又一个新名词。可我越看越觉得，它不是包装词，它是在补一块一直缺着的地基。
因为今天很多团队遇到的麻烦，真不是模型不够聪明。恰恰相反，是它太能干了，能干到有点吓人。
短句说完了。够直白吧。
你让 agent 改一个注册流程的小 bug ，它能读代码、改实现、跑测试、提交 patch ，一套动作行云流水。问题在于，测试绿了，不代表方向对了。它可能顺手把登录逻辑也“优化”了，还调用了仓库里根本不存在的认证方式。最烦的是，这种错不炸。它安安静静躺在绿灯后面，等你线上翻车时才露头。说难听点，这比直接报错还坑。太坑了。
我身边做工程效率平台的人，过去半年提到最多的不是“模型能力不够”，而是三件事：做偏、漂移、失控。昨天同一个任务做得像样，今天只换了一个文件，方案就歪到姥姥家；你盯着日志看半天，知道它在执行，不知道它凭什么这么执行；你想刹车，也只有等它先把手上那套动作跑完。这种体验很差，甚至有点荒唐。
聪明不是护栏。
很多人把 agent 失灵理解成提示词问题，我不太认同。提示词当然重要，但把所有责任都甩给 prompt ，有点糊弄学，也有点自欺。更接近现实的说法是，模型能力已经越过了“能不能做”的门槛，工程系统却还停在“先让它试试”的原始阶段。认知负荷、权限边界、反馈闭环，这些原本属于工程治理的部分，被一股脑丢给了模型自己消化。那不出事才怪。
扯远半步。说回正题， Harness Engineering 讨论的，就是怎么给这种能力装上边界、环境和反馈，让它不只是会干活，还能稳定地干对活。
不是给模型加戏，而是给它装缰绳
如果非要用一句最朴素的话解释 harness ，我会说，它像是 AI agent 的工作制度。
这个比喻不高级，但够准。
一个新同事，技术很好，学习也快，你不会因为他聪明，就让他第一天直接碰生产库、改迁移、跳过 review 。你会告诉他项目怎么分层，哪些目录别乱碰，测试怎么跑，什么情况下必须停下来叫人。 AI agent 也一样。它的问题通常不是不会写，而是不知道什么不能写，不知道该参考谁，不知道写完怎样才算真的对。
所以框架和 harness 不是一回事。 LangChain 、 CrewAI 这类东西更像“给工具”； harness 更像“定规矩”。前者解决行动能力，后者解决行动质量。少了前者， agent 干不了活；少了后者， agent 早晚把活干成事故。
我其实有点烦一种说法，叫“让 agent 像人一样自主”。这话听着热血，落地时却很虚。真实工程现场没那么浪漫。你要的是可预测，不是玄学；要的是能复盘，不是每次开盲盒；要的是知道它下一步大概会去哪，不是看它在终端里神游。讲白了，团队买的不是一位数字艺术家，买的是一个可控的执行系统。
这里有个误区值得单独点出来。很多人以为 harness 是大团队、复杂平台、重治理场景才需要的东西。不是。个人开发者更该早做，因为你没有那么多 review 资源，也没有时间反复兜底。出了偏差，全是你自己接锅。惨。真的惨。
没有约束的智能，不叫效率。
真正有用的起点，往往只是一份 HARNESS.md
如果把 Harness Engineering 说得太复杂，这个概念很容易又被做成 PPT 词汇。可在我看来，最小可用的起点，真不复杂，一份 HARNESS.md 就够。
它本质上是项目给 agent 的入职手册。
在原始草稿里，那份示例已经很完整了，里面有技术栈、目录结构、编码规范、测试命令、禁止操作、数据库边界。别小看这种“土办法”。它粗粝，但有效。因为 agent 在读仓库时最怕的不是信息少，而是信息散。规则散在 README 、 issue 、口头约定、历史提交、某个老同事脑子里，模型只能猜。猜着猜着，就开始漂。
我见过最典型的情况，是 agent 改 service 时顺带动了 schema 。它不是故意作死——它只是没被明确告知这条线不能碰。你回头骂它“不理解业务”……其实有点冤。边界没写出来，系统默认就是可尝试。对机器来说，这很合理。对人来说，这很闹心。
HARNESS.md 的价值，正好卡在这里。它把原本隐性的团队默契——翻译成显性的约束文本。哪些目录该去，哪些不要去；哪些模式能复用，哪些改动必须谨慎；测试怎么跑，错误怎么收，提交前最少做哪些校验。你会发现，一旦这些内容收束成一份稳定文档， agent 的输出波动会立刻收窄。不是神迹，是输入条件被整理了。就这么简单。
还有个常被忽略的小好处：这份文件让“复盘”有抓手。 agent 做错了，你不用空骂一句“怎么又这样”，而是能具体追问，这个错误能不能通过补一条规则来避免。能，就加进去。下一次同类事故，概率就会下降。不是百分百——没有哪个系统敢拍胸脯说绝不会再犯——但趋势会变。
这里我想故意说一句不那么客气的话。现在市面上不少 agent 落地文章，拼命展示“一句话生成功能”的爽感，却很少认真谈约束设计。我不喜欢这种写法。它把最难、也最值钱的部分藏起来了，只留下一个看上去很酷的幻觉。酷是酷，落到团队里容易翻车。翻得难看。真的难看。
真正拉开差距的，不是提示词，而是结构化工作流
再往前走一步，只有 HARNESS.md 还不够。规则写清了，任务如果还是一句模糊需求， agent 依旧会靠猜。
Red Hat 在 2026 年 4 月 7 日那篇关于结构化工作流的文章里，给了一个我认为很务实的拆法：先画影响图，再下结构化任务。这个顺序很关键。
第一阶段叫 Repository Impact Map 。意思很简单，别急着让 agent 写代码，先让它扫描仓库，交一份“我打算动哪里、不动哪里”的影响图。比如后端改 src/services/sbom.service.ts 和 src/routes/sbom.routes.ts，前端改 src/components/SBOMList.tsx，数据库 schema 不碰，认证中间件复用。你先看这张图，对不对。要是它连边界都看歪了，那就地拦下，比等代码写完再返工，便宜太多。
这个动作看着像增加步骤，实际是在降成本。因为 agent 最昂贵的错误，从来不是语法错误，而是方向错误。方向一歪……后面每一步都在替错误加固。
然后才是第二阶段，用模板把任务钉死。目标仓库、要改的文件、参考实现、验证方式，全部写清楚。这样做的意义，不在于把 agent 变笨，而在于减少它无谓的自由度。工程里有些自由是创造力……有些自由是事故源。两者别混。
我想举个特别典型的对比。你说“给 SBOM 查询结果加 CSV 导出”，这是自然语言，读起来轻松，执行时却留下了大量含混空间。导出逻辑写哪层？前端按钮放哪？是不是复用已有 JSON 导出模式？权限怎么继承？测试覆盖哪条路径？这些空白，最后都要有人填。你不填， agent 就会填。填得对不对，就看运气了。
不夸张地说，很多团队嘴上在用 AI 编程，骨子里还是在买彩票。这话不好听，但没说错。
先校准理解，再放权执行。
这里我还想补一笔。结构化任务不是“把话说复杂”，而是把原本含混的人类表达转成机器可执行约束。这个转换过程，本身就是一种工程能力。说白了，会不会写 prompt 不是核心，能不能把任务拆成边界明确、验证明确、参考明确的工作单，才是。
工具层开始发力，但别把工具当答案
当任务越来越频繁，手工维护 harness 就会吃力，这时候工具层才真正有价值。原始草稿里提到的两个项目，我觉得正好对应两种不同阶段。
一个是 AgentBoardTT/openharness[1]。它的路子很直接，把规划、会话恢复、 diff 查看、权限模式这些东西打包进 CLI 。你可以 pip install harness-agent，再 harness init 生成项目配置。对个人开发者和小团队来说，这种方案吸引力很大，因为它把“先规划、后执行、再核对”这套节奏变成默认动作，而不是靠自觉。
另一个是微软在 2026 年 4 月 2 日开源的 microsoft/agent-governance-toolkit[2]。这个东西明显更偏生产治理。草稿里提到，它对齐了 OWASP 在 2025 年 12 月发布的 agent 应用十大风险，覆盖目标劫持、工具滥用、身份冒用、记忆投毒、级联故障这些问题。坦白讲，这类能力在 demo 阶段常被嫌“重”，可一旦 agent 开始碰真实数据、真实权限、真实业务链路，没它真不行。
我甚至愿意把话说重一点：如果你的 agent 已经在无人值守地执行关键动作，却还觉得权限隔离、审计日志、断路器这些东西“可以晚点再做”，那不是敏捷，是侥幸。侥幸能跑一阵子，跑不远。
这里有一段我故意写得杂一点。 Harness 这事，从工程治理看属于约束设计，从日常开发看又很接地气，说白了就是别瞎折腾；你要是只顾着让模型遥遥领先，忽略可追溯、可熔断、可审计这些硬杠杠，最后多半会被现实教育，属实有点上头，也确实不太靠谱。这个段子味儿重了点，但意思没偏。
不过我也不想把工具神化。 OpenHarness 不是装上就万事大吉， Governance Toolkit 也不是配完策略就天下太平。工具只能把好的方法固化，不能替你做判断。你的仓库结构乱，规范模糊，验证链条缺口一堆，工具只会更快地把混乱自动化。那就尴尬了。不对。不是尴尬，是危险。实打实的危险。
开源项目清单：这些工具现在就能用
我把文中提到的项目和几个值得关注的资源整理在这，方便收藏。
起步级（个人开发者 / 小团队）
| 项目 | 一句话 | 上手成本 |
|---|---|---|
| OpenHarness[3] | 开箱即用的 Agent Harness CLI + SDK ，任意模型切换，内置规划/执行/验证流程 | pip install 一行 |
| awesome-harness-engineering[4] | 精选资源汇总：文章、工具、 Benchmark 、学习课程 | 阅读 |
| learn-harness-engineering[5] | 项目制实战课程，边做边学 | 中等 |
生产级（团队 / 企业）
| 项目 | 一句话 | 上手成本 |
|---|---|---|
| Agent Governance Toolkit[6] | 微软开源，覆盖 OWASP 10 大 Agent 风险，策略引擎亚毫秒级拦截 | 中等 |
| Datadog Harness-First Agents[7] | 可观测性驱动的 Harness ，监控 Agent 行为 + 自动告警 | 需 Datadog |
方法论参考（不用装，读了就会）
| 来源 | 链接 | 核心价值 |
|---|---|---|
| OpenAI | Harness Engineering: Leveraging Codex[8] | 100 万行零人工代码的实践细节 |
| Anthropic | Effective Harnesses for Long-Running Agents[9] | 长时运行 Agent 的 harness 设计 |
| Martin Fowler | Harness Engineering for Coding Agent Users[10] | 前馈/反馈/迭代三件套 |
| Red Hat | Structured Workflows[11] | 两阶段工作法：影响图 + 结构化任务 |
| LangChain | Anatomy of an Agent Harness[12] | Harness 架构拆解 |
说实话，这份清单我自己也常翻——特别是 awesome-harness-engineering 那个仓库，更新很勤快，隔几天就有新东西加进去。
再往上一层， Harness Engineering 在改写工程师角色
读完 OpenAI 、 Anthropic 、 Martin Fowler 这几路材料后，我最强的感受，不是“agent 终于会写很多代码了”，而是工程师的主任务正在悄悄转移。
OpenAI 在那篇 Harness Engineering 文章里提到， Codex Agent 写出了超过一百万行代码，而且是零人工代码提交。这个数字很冲击人。可真正值得盯住的，不对，不只是规模，而是他们怎么做到的：把代码库整理成 agent 可读的结构，让验证状态可查，让职责边界清楚，让任务不是一句泛泛的指令，而是能被分解、被确认、被回放的执行链。
Anthropic 的思路也很有意思。他们在 InfoQ 报道里展示的三 agent harness ，把规划、生成、评审拆开，权限隔离。规划 agent 只规划，生成 agent 只落地，评审 agent 只挑刺。这样做最妙的一点，是把“自己给自己打分”的偏见拆开了。单 agent 既决策又执行时，天然会偏向自己的路径，这几乎是结构性问题，不是模型态度问题。
Martin Fowler 的总结则更朴素，也更耐用：前馈指南、反馈传感器、迭代优化。前馈指南解决“做之前怎么约束”，反馈传感器解决“做完后怎么知道对不对”，迭代优化解决“出过的错怎么别白出”。这三件事放在一起看，你会发现 Harness Engineering 根本不是某个框架的附属品，它更像 agent 时代的软件工程基本功。
我现在越来越相信，未来团队里最稀缺的人，不一定是写代码最快的人，而是最会设计 harness 的人。因为当生成能力继续提高，真正稀缺的会变成边界感、系统感、复盘能力，还有把模糊需求翻译成稳定执行机制的能力。这话听着有点冷。可我觉得八九不离十。
当然，这个判断也可能需要修正。行业还在变，很多方法还没完全沉淀，今天有效的 harness ，半年后未必还是最优形态。可有一点我基本确定：如果一个团队还把 agent 当作“更会补全代码的 IDE 插件”，那它会错过真正的变化。变化不只发生在编码层，变化发生在整个工程组织方式里。
我更愿意把 Harness Engineering 看成一句提醒：别急着造一个更自主的 agent ，先把它放进一个能被理解、被约束、被验证的系统里。系统先稳，智能才值钱。
至于下一个问题是什么？也许不是“agent 能不能继续变强”，而是我们这些做工程的人，能不能跟上这套新秩序的搭建速度。这个答案，我现在也不敢说满。就先写到这。
参考链接
[1] AgentBoardTT/openharness: github.com/AgentBoardT…
[2] microsoft/agent-governance-toolkit: github.com/microsoft/a…
[3] OpenHarness: github.com/AgentBoardT…
[4] awesome-harness-engineering: github.com/walkinglabs…
[5] learn-harness-engineering: github.com/walkinglabs…
[6] Agent Governance Toolkit: github.com/microsoft/a…
[7] Datadog Harness-First Agents: www.datadoghq.com/blog/ai/har…
[8] Harness Engineering: Leveraging Codex: openai.com/index/harne…
[9] Effective Harnesses for Long-Running Agents: www.anthropic.com/engineering…
[10] Harness Engineering for Coding Agent Users: martinfowler.com/articles/ha…
[11] Structured Workflows: developers.redhat.com/articles/20…
[12] Anatomy of an Agent Harness: blog.langchain.com/the-anatomy…
