当 AI agent 开始进入真实工作流，问题就不再只是“模型够不够聪明”。模型能力当然重要，但系统能否可靠工作，还取决于模型之外的一组条件：它能看到什么，能调用什么工具，哪些操作必须确认，结果怎样验证，失败以后谁来发现和恢复。围绕这些条件建立起来的工程实践，可以称为 harness engineering。1
这个词也反映了 AI 工程重心的一种变化：关注点从单次模型输出，扩展到模型运行的条件。过去，人们很容易把系统表现直接归因于模型：提示词写得好，回答就更好；模型更强，系统似乎也会更可靠。但 agent 不只是回答问题。它会读文件、调用工具、修改代码、发送请求，还可能连续执行很多步骤。到了这一步，仅靠模型自己的判断已经不够，外部运行环境还必须负责限制权限、记录状态并验证结果。
Harness engineering 关心的正是这个外部系统。它不是简单的提示词技巧，也不是给模型加一层包装界面。这项工程涉及工具接口、权限边界、记忆机制、验证流程、观察日志、回滚机制、任务分解、人工确认点，以及失败后的处理方式。换句话说，harness engineering 设计的不是某一次回答，而是模型行动的条件。
传统软件当然也有不确定性。并发、外部服务、用户行为和硬件故障都可能让执行结果偏离预期，软件工程早就用接口、状态机、重试和失败处理来应对这些问题。
Agent 系统还多了一类不确定性：行动路径本身可能由模型动态决定。同一个目标，模型可能选择不同步骤；面对同一段上下文，也可能形成不同判断。于是问题不再只是“怎样写出确定规则”，还包括“怎样让一个行为不完全可预先枚举的行动者，在明确边界内完成任务”。工程要求没有降低，只是需要约束的对象变了。
好的 harness 既不能放任模型，也不能把所有行为都预先写死。约束太少，agent 可能误读任务、误用工具，甚至把局部错误扩大成外部后果；约束太多，系统又会退化成固定流程，模型的探索和适应能力难以发挥。困难在于划清边界：哪些地方允许模型选择路径，哪些地方必须由程序规则、权限策略或人工确认来收口。
例如，在代码场景里，agent 可以自己读仓库、提出修改、运行测试，但不能因此直接获得生产部署权限。它可以编辑文件，关键变更却仍要经过 diff 审查。它可以调用搜索工具，但结论需要保留依据。它也可以生成解决方案，但结果仍要经过测试、静态检查或人工确认。
这些安排不会改变模型本身的能力，却会直接改变错误能够传播多远、哪些操作能够真正生效，以及失败后是否容易被发现和恢复。模型还是那个模型，但它所处的执行结构不同了。
从这个角度看，harness engineering 的核心不是控制模型说什么，而是规定模型在什么条件下行动。它依据什么信息？能调用哪些工具？做到哪里必须停下来？失败以后怎样被发现和恢复？
因此，评价 agent 系统不能只看模型本身。在需要持续工具调用、权限控制和结果验证的工作流里，一个能力稍弱但运行在良好 harness 中的模型，可能比更强却缺少约束和验证的模型更可用。真实工作需要的不只是答案，还需要证据、边界和清楚的责任归属。
Capability、Authority 与 Validation 是三件不同的事
当 agent 开始改变外部世界时，有三个问题很容易被混在一起：它能不能做、它现在可不可以做，以及做完以后我们凭什么接受结果。
Capability 回答“系统能够做什么”。如果系统向 agent 提供了读仓库、执行命令、发送邮件等工具，说明这些操作在技术上可达，但不代表当前任务中的每一次调用都被允许。
Authority 回答“当前主体是否有权执行这一次具体操作”。同一个 capability，会因为用户授权、目标资源、风险等级或任务上下文不同而得到不同答案。Policy 则是作出这类授权判断时采用的规则。Capability 描述可达能力，authority 描述具体行动的权限，两者不能混为一谈。
Validation 回答“操作完成以后，凭什么相信目标已经达成”。命令成功退出，不等于任务已经完成；部署接口返回成功，也不等于服务已经健康。测试、状态读回、交叉验证和人工审查都属于 validation。
把这三件事分开以后，harness 的责任也更清楚：模型可以提出行动，程序根据 policy 和 authority 决定是否执行；产生外部变化的操作需要明确权限；执行完成以后，还要用独立证据验证结果。可以把这条原则写成：
Models propose. Programs decide. Effects require authority.
这与 《Structured LLM Design：按生命周期组织 Agent Runtime》 中对 Effect 的区分是同一个边界的另一面。那篇文章讨论 computation 如何存在、通信和结束；这里讨论这些 computation 在什么权限、验证和风险条件下可以影响外部世界。
Harness 的设计也在分配决策权：agent 能接触什么信息，哪些来源被信任，哪些操作需要授权，哪些风险必须优先拦截，都由系统结构决定。因此，这些选择最好保持可见：信息来源可以追溯，权限边界可以审查，失败过程可以追踪，异常结果可以纠正。否则，组织中没有被明确讨论的假设、盲区和惯性，也可能随着工具和流程一起被固化下来。
从这个意义上说，harness engineering 不是“让 AI 自动化一切”的技术，而是一套责任分配机制：哪些任务交给模型，哪些判断留给人，哪些步骤必须由程序验证，哪些失败必须中断流程。它既利用模型的推理和探索能力，也限制错误能够扩散到多远。
模型能力和 harness 质量是两个可以独立变化的工程变量。更强的模型不会自动带来清楚的权限边界，也不会自动产生可靠的观察、验证和恢复机制；反过来，好的 harness 也不能替代模型能力。
Harness engineering 的意义正在于把关注点从“模型这一次答得怎么样”扩展到“模型在什么条件下行动”。模型提供生成、推理和选择能力，harness 则把这些能力放进可观察、可授权、可验证、可恢复的执行结构中。两者共同决定了 agent 在真实工作流里能够可靠做到什么。
Footnotes
-
Harness engineering 暂无稳定通行的中文译名。这里保留英文，用来指围绕 AI agent 设计工具、权限、状态、观察、验证和反馈机制的系统工程实践。本文借用 harness 的是“为行动提供支撑和约束”这一层含义，而不是把它当作一个严格的一一对应术语。 ↩