Harness engineering for coding agent users面向编码智能体用户的“约束工程”

Feedforward and Feedback

To harness a coding agent we both anticipate unwanted outputs and try to prevent them, and we put sensors in place to allow the agent to self-correct:为了约束编码智能体，我们既要预判不想要的输出并设法预防，也要部署传感器让智能体能够自我修正：

• Guides (feedforward controls) - anticipate the agent's behaviour and aim to steer it before it acts. Guides increase the probability that the agent creates good results in the first attempt引导（前馈控制）——预判智能体的行为并旨在其行动前进行引导。引导能提高智能体在第一次尝试时就产生良好结果的概率。
• Sensors (feedback controls) - observe after the agent acts and help it self-correct. Particularly powerful when they produce signals that are optimised for LLM consumption, e.g. custom linter messages that include instructions for the self-correction - a positive kind of prompt injection.传感器（反馈控制）——在智能体行动后进行观察并帮助其自我修正。当传感器产生针对 LLM 优化的信号时，效果尤为显著，例如包含自我修正指令的自定义 Lint 消息——这是一种正向的“提示词注入”。

Separately, you get either an agent that keeps repeating the same mistakes (feedback-only) or an agent that encodes rules but never finds out whether they worked (feed-forward-only).如果分开来看，你要么得到一个不断重复同样错误的智能体（仅有反馈），要么得到一个编码了规则但从不知道这些规则是否奏效的智能体（仅有前馈）。

Computational vs Inferential

There are two execution types of guides and sensors:引导和传感器有两种执行类型：

• Computational - deterministic and fast, run by the CPU. Tests, linters, type checkers, structural analysis. Run in milliseconds to seconds; results are reliable.计算型——确定性且快速，由 CPU 运行。包括测试、Lint 工具、类型检查器、结构分析等。在毫秒到秒级内运行；结果可靠。
• Inferential - Semantic analysis, AI code review, “LLM as judge”. Typically run by a GPU or NPU. Slower and more expensive; results are more non-deterministic.推理型——语义分析、“以 LLM 作为裁判”等。通常由 GPU 或 NPU 运行。速度较慢且成本较高；结果具有较强的非确定性。

Computational guides increase the probability of good results with deterministic tooling. Computational sensors are cheap and fast enough to run on every change, alongside the agent. Inferential controls are of course more expensive and non-deterministic, but allow us to both provide rich guidance, and add additional semantic judgment. In spite of their non-determinism, inferential sensors can particularly increase our trust when used with a strong model, or rather a model that is suitable to the task at hand.计算型引导通过确定性工具提高了获得良好结果的概率。计算型传感器价格低廉且速度足够快，可以随智能体一起在每次变更时运行。推理型控制虽然成本更高且具有非确定性，但能让我们既提供丰富的指导，又能增加额外的语义判断。尽管存在非确定性，但当推理型传感器与强大的模型（或者说适合当前任务的模型）配合使用时，能显著增强我们的信任度。

Examples示例

The steering loop

The human's job in this is to steer the agent by iterating on the harness. Whenever an issue happens multiple times, the feedforward and feedback controls should be improved to make the issue less probable to occur in the future, or even prevent it.人类在此项工作中的职责是通过迭代约束来引导智能体。每当出现重复性问题时，就应改进前馈和反馈控制，以降低该问题在未来发生的概率，甚至彻底预防它。

In the steering loop, we can of course also use AI to improve the harness. Coding agents now make it much cheaper to build more custom controls and more custom static analysis. Agents can help write structural tests, generate draft rules from observed patterns, scaffold custom linters, or create how-to guides from codebase archaeology.在转向循环中，我们当然也可以利用 AI 来改进约束。编码智能体现在使得构建更多自定义控制和静态分析变得更加廉价。智能体可以协助编写结构化测试、根据观察到的模式生成草案规则、构建自定义 Lint 工具，或从代码库考古中创建操作指南。

Timing: Keep quality left

Teams who are continuously integrating have always faced the challenge of spreading tests, checks and human reviews across the development timeline according to their cost, speed and criticality. When you aspire to continuously deliver, you ideally even want every commit state to be deployable. You want to have checks as far left in the path to production as possible, since the earlier you find issues, the cheaper they are to fix. Feedback sensors, including the new inferential ones, need to be distributed across the lifecycle accordingly.持续集成的团队一直面临着如何根据成本、速度和关键性在开发时间轴上分配测试、检查和人工审核的挑战。当你渴望持续交付时，理想情况下，你甚至希望每个提交状态都是可部署的。你希望在通往生产的路径上尽可能早地进行检查，因为发现问题越早，修复成本就越低。反馈传感器（包括新型的推理型传感器）需要相应地分布在整个生命周期中。

Feedforward and feedback in the change lifecycle变更生命周期中的前馈与反馈

• What is reasonably fast and should be run even before integration, or even before a commit is even created? (e.g. linters, fast test suites, basic code review agent)哪些检查速度足够快，应该在集成前，甚至在创建提交之前就运行？（例如：Lint 工具、快速测试套件、基础代码审查智能体）
• What is more expensive and should therefore only be run post-integration in the pipeline, in addition to a repetition of the fast controls? (e.g. mutation testing, a more broad code review that can take into account the bigger picture)哪些检查成本较高，因此除了重复执行快速控制外，只应在流水线的集成后运行？（例如：变异测试、能考虑全局的更广泛的代码审查）

Continuous drift and health sensors持续漂移与健康传感器

• What type of drift accumulates gradually and should be monitored by sensors running continuously against the codebase, outside the change lifecycle? (e.g. dead code detection, analysis of the quality of the test coverage, dependency scanners)哪些类型的漂移会逐渐积累，应该由在变更生命周期之外、针对代码库持续运行的传感器进行监控？（例如：死代码检测、测试覆盖率质量分析、依赖项扫描）
• What runtime feedback could agents be monitoring? (e.g. having them look for degrading SLOs to make suggestions how to improve them, or AI judges continuously sampling response quality and flagging log anomalies)智能体可以监控哪些运行时反馈？（例如：让它们寻找恶化的 SLO 以提出改进建议，或者让 AI 裁判持续抽样响应质量并标记日志异常）

Regulation categories监管类别

The agent harness acts like a cybernetic governor, combining feed-forward and feedback to regulate the codebase towards its desired state. It's useful to distinguish between multiple dimensions of that desired state, categorised by what the harness is supposed to regulate. Distinguishing between these categories helps because harnessability and complexity vary across them, and qualifying the word gives us more precise language for a term that is otherwise very generic.智能体约束就像一个控制论调节器，结合了前馈和反馈，将代码库调节至理想状态。区分这种理想状态的多个维度是有益的，可以根据约束旨在监管的内容进行分类。区分这些类别很有帮助，因为它们的可约束性和复杂性各不相同，而且对术语进行限定能让我们对原本非常通用的词汇有更精确的表达。

The following are three categories that seem useful to me as of now:以下是我目前认为有用的三个类别：

Harnessability

Not every codebase is equally amenable to harnessing. A codebase written in a strongly typed language naturally has type-checking as a sensor; clearly definable module boundaries afford architectural constraint rules; frameworks like Spring abstract away details the agent doesn't even have to worry about and therefore implicitly increase the agent's chances of success. Without those properties, those controls aren't available to build.并非每个代码库都同样适合进行约束。使用强类型语言编写的代码库自然拥有类型检查作为传感器；定义明确的模块边界允许实施架构约束规则；像 Spring 这样的框架抽象掉了智能体无需担心的细节，从而隐式地提高了智能体成功的机会。如果没有这些属性，就无法构建相应的控制手段。

This plays out differently for greenfield versus legacy. Greenfield teams can bake harnessability in from day one - technology decisions and architecture choices determine how governable the codebase will be. Legacy teams, especially with applications that have accrued a lot of technical debt, face the harder problem: the harness is most needed where it is hardest to build.这在“绿地项目”（新项目）与“遗留系统”中表现不同。绿地项目团队可以从第一天起就将“可约束性”融入其中——技术决策和架构选择决定了代码库的可治理性。遗留系统团队，特别是那些积累了大量技术债务的应用程序，面临着更严峻的问题：最需要约束的地方，往往也是最难构建约束的地方。

Harness templates

Most enterprises have a few common topologies of services that cover 80% of what they need - business services that exposes data via APIs; event processing services; data dashboards. In many mature engineering organizations these topologies are already codified in service templates. These might evolve into harness templates in the future: a bundle of guides and sensors that leash a coding agent to the structure, conventions and tech stack of a topology. Teams may start picking tech stacks and structures partly based on what harnesses are already available for them.大多数企业都有几种常见的服务拓扑结构，涵盖了其 80% 的需求——例如通过 API 公开数据的业务服务、事件处理服务、数据仪表板。在许多成熟的工程组织中，这些拓扑结构已经固化在服务模板中。未来，这些模板可能会演变为“约束模板”：即一套引导和传感器，将编码智能体束缚在特定拓扑结构的结构、规范和技术栈中。团队未来可能会根据现有的约束条件来选择技术栈和结构。

We would of course face similar challenges as with service templates. As soon as teams instantiate them, they start fall out of sync with upstream improvements. Harness templates would face the same versioning and contribution problems, maybe even worse with non-deterministic guides and sensors that are harder to test.我们当然会面临与服务模板类似的挑战。一旦团队实例化了它们，它们就会开始与上游的改进不同步。约束模板将面临同样的问题，如版本控制和贡献问题，对于那些难以测试的非确定性引导和传感器来说，情况可能更糟。

The role of the human

As human developers we bring our skills and experience as an implicit harness to every codebase. We absorbed conventions and good practices, we have felt the cognitive pain of complexity, and we know that our name is on the commit. We also carry organisational alignment - awareness of what the team is trying to achieve, which technical debt is tolerated for business reasons, and what “good” looks like in this specific context. We go in small steps and at our human pace, which creates the thinking space for that experience to get triggered and applied.作为人类开发者，我们为每个代码库带来了作为隐式约束的技能和经验。我们吸收了规范和良好实践，我们感受过复杂性带来的认知痛苦，而且我们知道提交记录上写着我们的名字。我们还承载着组织的一致性——了解团队试图实现的目标、业务上可容忍哪些技术债务，以及在这个特定语境下什么是“好”的。我们以人类的节奏小步快跑，这为触发和应用这些经验创造了思考空间。

A coding agent has none of this: no social accountability, no aesthetic disgust at a 300-line function, no intuition that “we don't do it that way here,” and no organisational memory. It doesn't know which convention is load-bearing and which is just habit, or whether the technically correct solution fits what the team is trying to do.编码智能体完全不具备这些：没有社会责任感，不会对 300 行的函数感到审美厌恶，没有“我们这里不这样做”的直觉，也没有组织记忆。它不知道哪个规范是承重墙，哪个只是习惯，也不知道技术上正确的解决方案是否符合团队的目标。

Harnesses are an attempt to externalise and make explicit what human developer experience brings to the table, but it can only go so far. Building a coherent system of guides and sensors and self-correction loops is expensive, so we have to prioritise with a clear goal in mind: A good harness should not necessarily aim to fully eliminate human input, but to direct it to where our input is most important.约束是试图将人类开发者的经验外化并明确化的尝试，但它有其局限性。构建一个连贯的引导、传感器和自我修正循环系统成本高昂，因此我们必须以明确的目标为导向进行优先级排序：一个好的约束不一定旨在完全消除人工输入，而是将人工输入引导至最关键的地方。

A starting point - and open questions

The mental model I've laid out here describes techniques that are already happening in practice and helps frame discussions about what we still need to figure out. Its goal is to raise the conversation above the feature level - from skills and MCP servers to how we strategically design a system of controls that gives us genuine confidence in what agents produce.我在此提出的思维模型描述了实践中已经发生的各种技术，并有助于围绕我们仍需解决的问题展开讨论。其目标是将讨论提升到功能层面之上——从技能和 MCP 服务器，转变为我们如何战略性地设计一套控制系统，从而对智能体的产出产生真正的信任。

Here are some harness-related examples from the current discourse:以下是当前讨论中与约束相关的一些示例：

• An OpenAI team documented what their harness looks like: layered architecture enforced by custom linters and structural tests, and recurring “garbage collection” that scans for drift and has agents suggest fixes. Their conclusion: “Our most difficult challenges now center on designing environments, feedback loops, and control systems.”OpenAI 的一个团队记录了他们的约束方案：通过自定义 Lint 工具和结构化测试强制执行的分层架构，以及定期扫描漂移并让智能体建议修复方案的“垃圾回收”机制。他们的结论是：“我们目前最艰巨的挑战集中在设计环境、反馈循环和控制系统上。”
• Stripe's write-up about their minions describes things like pre-push hooks that run relevant linters based on a heuristic, they highlight how important “shift feedback left” is to them, and their “blueprints” show how they're integrating feedback sensors into the agent workflows.Stripe 关于其“小兵（minions）”的文章描述了诸如基于启发式算法运行相关 Lint 工具的预提交钩子（pre-push hooks），他们强调了“反馈左移”对他们的重要性，而他们的“蓝图（blueprints）”展示了他们如何将反馈传感器集成到智能体工作流中。
• Mutation and structural testing are examples of computational feedback sensors that have been underused in the past, but are now having a resurgence.变异测试和结构化测试是过去未被充分利用、但现在正在复兴的计算型反馈传感器示例。
• There is increased chatter among developers about the integration of LSPs and code intelligence in coding agents, examples of computational feedforward guides.开发者之间关于在编码智能体中集成 LSP 和代码智能的讨论日益增多，这些都是计算型前馈引导的示例。
• I hear stories from teams at Thoughtworks about tackling architecture drift with both computational and inferential sensors, e.g. increasing API quality with a mix of agents and custom linters, or increasing code quality with a “janitor army”.我从 Thoughtworks 的团队那里听到了一些关于利用计算型和推理型传感器解决架构漂移的故事，例如通过智能体和自定义 Lint 工具的组合来提高 API 质量，或者通过“清洁工大军（janitor army）”来提高代码质量。

There's plenty still to figure out, not just the already mentioned behavioural harness. How do we keep a harness coherent as it grows, with guides and sensors in sync, not contradicting each other? How far can we trust agents to make sensible trade-offs when instructions and feedback signals point in different directions? If sensors never fire, is that a sign of high quality or inadequate detection mechanisms? We need a way to evaluate harness coverage and quality similar to what code coverage and mutation testing do for tests. Feedforward and feedback controls are currently scattered across delivery steps, there's real potential for tooling that helps configure, sync, and reason about them as a system. Building this outer harness is emerging as an ongoing engineering practice, not a one-time configuration.还有很多问题有待解决，不仅仅是前面提到的行为约束。当约束不断增长时，如何保持其连贯性，使引导和传感器保持同步而不相互矛盾？当指令和反馈信号指向不同方向时，我们能在多大程度上信任智能体做出合理的权衡？如果传感器从未触发，这到底是高质量的标志，还是检测机制不足的标志？我们需要一种评估约束覆盖率和质量的方法，类似于代码覆盖率和变异测试对测试的作用。前馈和反馈控制目前分散在交付步骤中，确实存在能够帮助配置、同步并将其作为系统进行推理的工具潜力。构建这种外部约束正在成为一种持续的工程实践，而非一次性的配置。