Thoughtworks 工程师谈 AI 智能体的 harness 工程

IEEE Computer Society 与 IEEE Software 杂志旗下播客 SE Radio 近期上线一期节目，邀请 Thoughtworks 杰出工程师 Birgitta Boeckeler，系统讲解「harness engineering」这一面向 AI 编码代理的工程化方法。节目由主持人 Priyanka Raghavan 主持，整体内容聚焦于如何让 AI agent 在真实软件开发环境中更稳定、可信赖地工作。

什么是 harness engineering

在节目中，Boeckeler 首先拆解了「harness」（意为缰绳、约束框架）一词的含义。她将 harness 视为包裹在 AI 编码代理外层的工程化结构，其作用是在模型能力之外提供额外的引导与约束，使 agent 的输出更贴近工程团队的质量与流程要求。她强调，harness 本身并不是模型的一部分，而是一层可随项目演进而持续维护的工程组件。

核心构建块：guides 与 sensors

Boeckeler 进一步把 harness 拆解为两个核心元素：

• Guides（引导）：通常以 .MD 文件等形式承载，提供给 agent 的项目背景、约定与最佳实践，相当于给模型一份「说明书」。
• Sensors（传感器）：对接 SonarQube、Semgrep 等静态分析与代码质量工具，把代码层面的客观信号回传给 agent，使其在执行过程中能够自我纠偏。

她指出，guides 决定了 agent 的行为方向，sensors 则提供了闭环反馈，二者结合可以让 agent 在不依赖人工逐条审查的情况下保持更稳定的输出质量。

与 CI/CD 流程的集成

节目讨论了 harness 在实际工程中的落地方式。Boeckeler 认为，harness 必须与团队现有的 CI/CD 流水线、Pull Request 流程深度耦合，而不是另起一套体系。例如，sensors 可以在 CI 阶段自动运行，将结果反馈给 agent；guides 则可以随仓库一同版本化管理，随项目演进持续更新。她特别提到，harness 的强弱直接决定了团队对 AI 生成代码的信任程度——一个设计良好的 harness 能显著降低人工复核成本。

维护成本与人机责任

Boeckeler 也提醒，harness 并非一劳永逸。随着底层基础模型不断升级，agent 的行为模式会发生变化，原本有效的 guides 和 sensors 可能失效，harness 需要随之迭代。她还就「AI 生成代码出问题由谁负责」展开讨论，认为责任最终仍应落在人类工程师与团队流程上，harness 只是让这一责任链更可控的工具，而非免责的挡箭牌。节目最后展望了 harness engineering 与 AI 辅助软件开发未来的演进方向。