Harness Engineering：让 Agent 从“能工作”走向“可交付”

当大模型的能力边界不断拓展，一个核心问题逐渐浮现：如何让AI Agent真正成为可信赖的生产力工具，而非仅仅是展示概念的Demo？一个聊天机器人可以优雅地生成回答，但一个Agent需要完成完整任务——读取资料、调用工具、修改文件、执行测试、处理失败，并在必要时向人类请求决策。这两者之间的差距，不仅在于模型是否足够聪明，更在于是否存在一套能够约束行动、验证结果、保存状态和记录过程的工程系统。

从提示工程到环境工程：技术演进的三阶段

Harness Engineering正是为解决这一问题而生。其核心公式简洁而深刻：Agent = Model + Harness。模型提供理解和推理能力，而Harness则决定模型可以访问什么、能够执行什么、失败后如何恢复、结果是否经过验证，以及整个过程能否被追踪和改进。如果将模型比作智能的“大脑”，那么Harness就是保障“大脑”能够稳定、可靠运作的“神经系统”和“安全护栏”。

Harness的六层架构

理解Harness Engineering的价值，需要回顾AI工程化的演进历程。2023至2024年间，工程重点主要集中在Prompt Engineering，通过调整措辞、示例和指令来优化模型在单轮交互中的输出质量。然而，Prompt能影响的仅是模型的思考方式，无法稳定限制权限和执行成本。进入2025年，Context Engineering成为重要方向，工程师开始关注模型在执行任务时能够看到哪些资料、工具、记忆和外部知识。但Context无法单独保证结果的正确性或动作的安全性。2026年以后，关注点进一步扩展到完整运行环境，即Harness Engineering。这三个阶段并非相互替代关系，生产级Agent仍然需要清晰的Prompt和高质量的Context，但它们必须被放入一个能够验证和约束执行过程的环境中。

Guides与Sensors：前馈与反馈的闭环

Harness被解构为六个层次，形成完整的运行控制面。Guides是Agent执行前的约束，可以表现为项目级配置文件、工作说明或行为准则。它们属于前馈控制，在错误发生之前影响Agent的行为。一个有效的Guide不应只是“写高质量代码”这类无法验证的要求，而应包含具体的构建命令、测试命令、目录边界、禁止操作和典型失败模式。Sensors则用于检查Agent的产出，是执行后的反馈控制。常见的计算型Sensor包括单元测试、类型检查、Lint和安全扫描。对于“邮件语气是否合适”这类难以完全形式化的问题，才适合使用LLM-as-judge作为推理型Sensor。值得注意的是，计算型Sensor通常更快、更便宜、可重复性更强，应优先建设。

Agentic Loop、Memory与Permissions：执行与安全的平衡

Agentic Loop是Harness的执行核心，它不应被理解为一次模型调用，而应被理解为一个有边界的循环：先规划，再执行；执行后验证；失败时修复或重试；重试耗尽或遇到不可恢复问题时升级给人。循环必须有明确边界，包括每个步骤的最大重试次数、单任务的运行时间上限、Token消耗上限和成本预算。Memory and State解决的是连续性问题。模型每次调用时只拥有当前上下文，不能天然记住上一个会话完成了什么。Harness需要通过显式状态恢复连续性，最简单的方式就是文件系统——plan.md保存计划，progress.json记录已完成步骤，decisions.jsonl保存重要决策。Permissions则是模型之外的安全边界。权限不应依赖模型“自觉遵守”，Harness必须成为主要的安全边界。最小权限原则要求系统只授予完成任务所需的最小范围，同时考虑Scope、Rate、Reversibility和Visibility四个维度。

如有侵权，请联系删除。