最近，Birgitta Böckeler 作客了 Thoughtworks Podcast[1]，聊了她之前在 Martin Fowler 网站上发表的对于 Harness Engineering 的著述[2]（以下称播客）。自后她又叫上了共事 Chris Ford，录了一个 YouTube 视频[3]，挑升深入聊了传感器的部分（以下称视频）。两个内容看完，我对这个主见的协调又深了一层。

说作客很奇怪，她自己便是TW播客的主播。但因为此次的主角是她，是以就以嘉宾的身份出现了。

我上个月还是读过著述了，还写了一篇。但那篇著述更像是一个系统性的主见梳理，播客里的许多内容是著述里装不下的——那些彷徨、那些"咱们也不知说念谜底"的霎时、那些嘉宾之间彼此碰撞出来的类比，反而让这个主见变得具体了。

Harness 到底是什么？

Birgitta 在播客开首就说，写那篇著述最大的挑战是"何如界说"。AI 期间的术语扩散太快了，今天刚造一个词，下周就有十种不同的协调。是以她用了洋葱模子——最内部是大说话模子，外面包一层是 Coding Agent（也便是Claude Code、Cursor 这些），这是内层的 harness。然后行为用户，咱们还不错再包一层，把景色特定的端正、用具、反应回路都装进去。

这个比方我在《马与骑马东说念主》里还是写过，但 Birgitta 加了一句提醒，让我愣了一下。她说，她"险些但愿这是两个不同的词"，因为 Agent Harness 和 User Harness 是皆备不同的两个限界曲折文。Chris Ford 说得更好：你不成把马具套在狗的内部。问题是你到底在限定什么？紫色的内层 harness（Claude Code、Cursor）限定的是模子自己；蓝色的外层 harness 限定的其实是 Agent，也便是编码代理的行为。市面上那些盘问，有些讲的是何如遐想 Agent 的系统教唆和用具调用，那是给用具厂商看的；有些讲的是何如在我方的景色里写 AGENTS.md 和 linter 端正，那是给末端用户看的。他们都说我方是 Harness Engineering，但说的其实是两件事。

指导器和传感器：预判与反应

播客确切让我"啊"了一声的，是 Birgitta 对 指导器（Guides）和传感器（Sensors）的伸开。

她把这个框架分红了两条线。一条是前馈（feedforward）：你在事情发生之前给 Agent 的指引，预判它可能会作念错什么，提前把端正塞进去。今天最常见的指导器便是各式 markdown 文献——编码法度、架构文档、AGENTS.md、Skills。另一条是反应（feedback）：等 Agent 写完代码之后，你给它一个信号，告诉它"这里不合"。

Nate 倏地扔进来一个类比，精确得让东说念主不测。他说，这就像是带实习生。

你先跟他聊编码法度、景色结构，这是指导器。然后你 review 他的代码，相似的问题反复出现，你就再补充一条文定。这个历程——预判诞妄、设定例则、不雅察效能、修正端正——便是 Harness Engineering 的渊博。

Birgitta 坐窝接住了。她说她也曾带过一个刚毕业的学生，不 pair 的时候，静态代码分析用具帮了大忙——那些"函数太长"、"圈复杂度太高"的基础问题，用具不错径直告诉新东说念主，无谓等她来 review。但关节是后头这句：有些东西实习生长久不会自动作念对。是以细目性的反应绝顶进攻。

这里有个绝顶进攻的细节，Birgitta 在视频里反复提到：东说念主类其实一直坐在这个反应轮回里。她管这叫驾驶轮回（steering loop）。每次你跟 Agent 开完一个会话，你都要思：此次它又犯了什么常见的错？我能不成加一个传感器来捕捉？我能不成改一下指导器来胡闹？OpenAI 团队阿谁 Ryan 写过一篇著述，说他们团队尽量不径直改代码，而是把元气心灵花在这个轮回上——不是东说念主在修代码，是东说念主在修端正，然后让端正去修代码。

Chris 补了一句：这可能便是"reckless vibe coding"（冒失的氛围编程）和可捏续开荒之间的区别。前者代码熵随时候递加，后者有东说念主捏续投资在 harness 上。

策画型用具的价值被低估了

这让我再行协调了策画型（Computational）用具的价值。

当今市面上内行都在写 markdown 文献——编码法度、架构文档、Skills，这些都是推理型（Inferential）的，由 LLM 去"协调"和"诠释"。Birgitta 很径直地说，团队目下严重低估了策画型用具。静态代码分析、类型检查、linter、结构测试，这些老用具在 AI 期间反而有了新的人命力。

为什么？因为 AI 会犯那些"东说念主类老手不会犯的初级诞妄"。超长函数、十个参数、圈复杂度爆表。这些不需要 LLM 去"判断"，linter 不错径直报出来，AI 收到反应我方就能改。Birgitta 说她最近在一个景色里用了无数的静态代码分析，效能"不测地惊喜"。昔时她以为这东西有点鸡肋——毕竟它不成保证质料。但当今有了 Coding Agent，linter 集成进去之后，AI 会捏续收到"这里太复杂了"的信号，然后自动拆解、重构，东说念主类以致无谓看。

更妙的是信噪比的问题。昔时一堆 warning，没东说念主有耐烦一一 suppress，终末就毁灭了。当今你不错把 lint 端正的诞妄信息遐想成给 LLM 看的竖立指引——"这个函数太长了，讨论拆成三个 smaller functions，每个只作念一件事"。AI 读到之后，不错我方判断要不要修、何如修、要不要 suppress。以致你不错再写一个剧本，列出总共 AI suppress 掉的例外，让东说念主 review 的时候先看这些场所。Birgitta 还玩了一个更狠的：她给某些端正竖立了"软阈值"，允许 AI 在给出意义的情况下微调阈值——比如某个 mock 文献长度逾越了 500 行限定，AI 判断后把它改成了 550 行。不是 blanket suppress，而是有界限的弹性。

但策画型用具不单是反应侧的。Birgitta 提到，前馈侧也有策画型用具——比如 language server（让 Agent 用细目性方式分析调用链而不是让 LLM 猜）、code mods（OpenRewrite 这类有细目性 recipe 的代码迁徙用具）、JetBrains 的 MCP rename 办事器。这些东西比让 LLM 我方改代码更可靠，也更省 token。

测试不是全绿就罢了

播客还花了不少时候聊测试。这是 Birgitta 著述里着墨未几但播客里深入伸开的话题。

Nate 讲了一个真实案例：一个团队的 AI agent 在 dev 环境里因为莫得权限推论某个函数，径直把 authorization 给凝视掉了。他说，实习生可能会干这种事，但 senior engineer 会把他拉到一边，告诉他长久别这样干。问题是，AI 不会"学到"。你告诉它一次，下次换了个曲折文，它可能还会犯。

Nate 的作念法是学 Kent Beck：测试的界说和编写是东说念主的职守，AI 只认真写出产代码。你告诉 AI 你要什么，让它写几个测试，你 review 完测试没问题了，再让它去写结果。Birgitta 说她没这样严格，她的 workflow 是让 AI 写测试、她 review、插足纠正轮回，滚球app(中国)官网下载两边都称心了再写结果。但她也坦言，何如让 AI 在测试和出产代码之间守住界限，目下还莫得好的模式。

她提到了 Thoughtworks 共事 Matteo Vaccari 的"Approved Scenarios"的作念法——在 HTTP API 层面写 high level 的输入输出测试，东说念主 review 这些场景，然后让 AI 去填充结果。

但最让我印象长远的，是 Birgitta 在视频里展示的一个发现。她在一个文献上跑出了 100% 语句隐蔽率和 75% 分支隐蔽率，然后发现这个文献其实莫得任何单位测试。唯唯独个大型验收测试盘曲调用了它。更狠的是，她在 AI 生成的测试套件上跑变异测试，发现了无数"无断言测试"——测试看起来跑过了，但其实什么都没考证。隐蔽率很高，但有用性很低。

她还不雅察到 AI 的一种她称为 "TDD 扮演"的行为：Agent 会说"我先写测试"，然后坐窝就去写结果，中间根柢不开动测试，过两分钟才回归跑。形势上是 TDD，实质上皆备莫得"红-绿-重构"的轮回。

这个细节让我印象长远。因为咱们太容易深信"测试全绿"了。全绿不等于有用，尤其是在 AI 生成测试的情况下。

结构比思象的进攻

Birgitta 在视频里还聊了一个我之前没太提神的点：模块化。

她在我方的实验景色里用 Dependency Cruiser 竖立了架构端正，比如 domain 层不允许径直引入外部 SDK，API 客户端必须放在特定文献夹。听起来很老派，但她指出这不单是是"东说念主类以为颜面"——对 AI 来说，好的模块界限意味着它每次需要读的文献更少，推理规模更小，出错的概率也就更低。况且不同模块有不同的风险画像：淌若 AI 改了 outbound 模块（调用外部 API），你可能需要驰念依赖升级；淌若改了 inbound 模块（对外流露的接口），你可能需要驰念向后兼容。模块明晰了，你以致不错作念一张"变更热力争"，一眼看出此次调动最危急的场所在那处。

Chris 说了一句很在点的话：到目下为止，对东说念主类好的模块化和对 Agent 好的模块化，看起来是一趟事。

传感器 Sidecar 和那场实验

视频里最硬核的部分，是 Birgitta 展示的一个实验。她写了一个 传感器 sidecar——一个跟 Agent 并行开动的小用具，及时监控各式传感器的状况。东说念主类看到的是一张红绿灯面板；Agent 看到的是另一种视图：只复返失败项，况且每个失败都附带一条"积极教唆注入"——不是冷飕飕的报错，而是告诉它"我但愿你何如修"。

然后她作念了一个对确切验：吞并个功能，一次开着传感器让 Agent 作念，一次关掉传感器。效能果如其言但也酷爱：

• 有传感器：lint 全绿，测试隐蔽率不降，模块界限没被打破，安全扫描通过

• 无传感器：测试隐蔽率掉了 6 个百分点，出现了no-explicit-any和未使用变量，模块结构被 Agent 我方再行组织了，函数参数最多达到了 8 个

Birgitta 坦言这个实验样本量很小，不及以得出统计论断，但它揭示了一个进攻的 failure mode：莫得反应的时候，Agent 倾向于走捷径。不是因为它笨，而是因为它不知说念你的法度是什么。

她还绝顶提到少许：东说念主在轮回中的可视化体验仍然很进攻。当今社区里许多能量都花在"何如让 Agent 皆备自主开动"上，但她以为监督式会话中的可视化相似关节——有许多场景你根柢不思让 Agent 无东说念主扶持。

什么时候跑、跑多贵

播客后半段聊到了本钱和时候线溜达。Birgitta 说传感器不是越多越好，你要讨论跑在那处、多久跑一次。低廉快速的策画型传感器不错捏续跑，像 linter、测试套件。贵的推理型传感器不错放在 PR 之后，以致依期跑——OpenAI 团队有一个叫作念"garbage collection"的依期推理型传感器，不错依期扫描时间债。

她还提议了一个我很有共识的区别：信息型传感器vs法度型传感器。前者告诉你"你的依赖有 3 个还是两年没更新了"，这是信息，需要东说念主或 AI 来判断要不要治理；后者径直亮红灯："这个函数逾越了 20 个参数，build 失败"。信息型合适探索，法度型合适胡闹。太多团队把本该是信息型的问题硬塞进 build pipeline，效能内行学会了一说念 suppress，传感器终末酿成了摆列。

她还提到了 token 经济学。她说当补贴期结果、按量付费确切到来时，这些分层政策会变得特殊进攻。Nate 接了一句：constraints set us free——本意是自律智力解放，放在这里不错协调为"拘谨智力让咱们 token 解放"。

能砍掉一半的 Markdown 吗？

终末 Prem 问了一个好问题：淌若听众下周回到公司只思作念一件事，应该作念什么？

Birgitta 的回话很短，也很有劲：思思何如把 markdown 文献砍掉一半。那些你写在 AGENTS.md 里的端正，有几许不错用策画型用具替代？用 linter 替捉刀墨描摹，用类型检查替代"难忘检查参数"，用架构测试替代"不要跨模块调用"。

但这个问题的另一面，是 Birgitta 在视频结果提议的。她说每次她激活新端正，都会冒出新的问题。有些是噪声，有些是金子。她以致问了一个更激进的问题：淌若模子 60% 的情况下原本就能作念对，剩下 40% 有传感器兜底，那这条指导器是不是不错干脆删掉？

反过来也一样：淌若传感器能让弱模子也产出及格代码，那是不是 weaker model + strong sensors 的组合比强模子 + 弱传感器更经济？

虽然，她也有担忧。一切全绿的时候，东说念主会不会变得更麻木？Chris 用安全带反驳：有东说念主说安全带让东说念主开车更冒失，但就算是简直，我如故遴荐系安全带。

Birgitta 还抛了一个很远的思法：将来会不会有 harness templates？就像当今的 service templates 一样，但不是只 scaffold 景色结构，而是一整套预设的指导器和传感器。数据仪容盘有一种建树，事件治理模块有另一种，HTTP API 办事有第三种。你 init 项指标时候选一种，harness 就自动配好了。

缰绳一直都在

这期播客和视频看完，我对 Harness Engineering 的协调变具体了。上个月我写《马与骑马东说念主》的时候，把这玩意讲得有点大，好像要重新搭建一套新体系。其实根柢不是。它便是你已有的工程履行（linter、测试、CI）再行组合，办事对象从东说念主换成 AI。

缰绳一直都在你手里。问题是你攥的是一根麻绳，如故一套有韧性有脉络的马绳。

援用贯穿

[1]Thoughtworks Podcast:https://www.thoughtworks.com/en-sg/insights/podcasts/technology-podcasts/what-harness-engineering

[2]Birgitta Böckeler 对于 Harness Engineering 的著述:https://martinfowler.com/articles/harness-engineering.html滚球app(中国)官网下载