Harness Engineering for Coding Agent Users
这篇文章给 coding agent 用户一个清晰模型：不要只买更强模型，要设计模型外面的工作环境、约束、工具和反馈回路，让 agent 能少犯错、能自我修正、能把人类注意力留给真正重要的判断。
读这篇文章，先抓住四个问题
不要把 harness 理解成单个工具。它是一组控制：行动前怎么引导，行动后怎么检测，检测结果如何反馈给 agent 和人。
为什么需要 harness？
LLM 非确定、缺上下文、按 token 工作。只靠 prompt 或人工 review，agent 会反复犯同类错误。harness 把团队经验显式化成可读取、可执行、可反馈的系统。
什么是 Guides？
Guides 是前馈控制：AGENTS.md、Skills、architecture.md、参考文档、脚手架脚本、codemod、LSP 信息。它们在 agent 动手前提高做对概率。
什么是 Sensors？
Sensors 是反馈控制：lint、typecheck、test、coverage、architecture rule、browser/log、AI review。它们在 agent 产出后给信号，促成自我修正。
人类做什么？
人类不是消失，而是调参：发现错误反复出现，就把它升级为新的 guide 或 sensor。好的 harness 把人类输入引导到最有价值的地方。
核心矩阵：方向 × 执行类型
文章最值得复用的是这张 2×2：前馈/反馈决定时机，计算性/推理性决定信号性质和成本。
三类要被规制的质量
Harness 不是泛泛地让 agent “更听话”，而是把你要维持的系统状态分成不同维度。
可维护性 Harness
用 lint、类型、复杂度、重复代码、覆盖率、结构测试、AI review 控制内部代码质量。这一类最容易起步。
架构适应度 Harness
把性能、可观测性、模块边界、依赖方向、部署约束做成 fitness functions，让 agent 知道架构不是随便改的。
行为 Harness
功能正确性仍是难点。AI 生成的测试不能直接等同于真实规格，需要 approved fixtures、人工验收和更强的场景证据。
Harnessability
不是所有代码库同样可驾驭。强类型、清晰边界、成熟框架、可启动环境、可读日志，都会提高 agent 成功率。
映射到我们的 coding agent 工作流
这篇文章对我们最直接的启发：不要只问“哪个模型更强”，要问“这个任务的 guides 和 sensors 是否足够”。
边看边追问
下面的问题适合读完原文后继续追问，也适合用来检查一个项目的 harness 是否够用。
原文、译文与阅读口径
本页是中文重组阅读版，不是全文转载。建议先看本页抓主线，再回到原文或译文逐段核对。
官方原文：Harness engineering for coding agent users，作者 Birgitta Böckeler（Thoughtworks），发布于 Martin Fowler 网站，日期 2026-04-02。
公开中文全译：编码智能体用户的 Harness Engineering。
相关阅读：Thoughtworks: Harness engineering and agent feedback，补充了 sensors 的实践视角。