最近，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开云体育官网