最近，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