最近，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、参预转变轮回，博亚体育2026世界杯官方版(中国)官方入口两边都大肆了再写竣事。但她也坦言，怎样让 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官网下载