当 AI agent 开始进入真实工作流，问题就不再只是“模型够不够聪明”。模型能力当然重要，但真正决定它是否可靠的，往往是模型之外的东西：它能使用哪些工具，能看到哪些信息，什么时候需要请求确认，怎样验证结果，错误如何被发现，权限如何被限制，执行过程能不能被追踪。围绕这些条件建立起来的工程实践，可以称为 harness engineering。1
这个词的关键不在于发明一个新名词，而在于指出一个正在发生的转移：AI 工程的重心正在从“单独优化模型输出”转向“设计模型运行环境”。过去，人们容易把 AI 的表现理解为模型本身的能力。提示词写得好，模型就答得好；模型参数更强，系统就更可靠。但在 agent 场景里，这种理解不够。一个 agent 不只是回答问题，它会读取文件、调用工具、修改代码、发送请求、生成计划，甚至在多个步骤中连续行动。此时，可靠性不能只靠模型的内部判断，而必须由外部系统共同承担。
Harness engineering 关心的正是这个外部系统。它不是简单的提示词技巧，也不是给模型加一层包装界面。它包括工具接口、权限边界、记忆机制、验证流程、观察日志、回滚机制、任务分解、人工确认点，以及对失败情况的处理方式。换句话说，它设计的不是某一次回答，而是模型行动的条件。
这也是它不同于许多传统软件工程问题之处。传统软件工程并不是没有不确定性；并发、外部服务、用户行为和硬件故障都可能造成变化。但它通常把这些不确定性收束进明确的接口、状态机、重试策略和失败路径。AI agent 的不确定性更直接地存在于行动者本身：同一个目标，它可能选择不同路径；同一段上下文，它可能产生不同解释。于是工程问题从“如何写出一套完全确定的规则”变成“如何让一个不完全确定的行动者在可控环境中完成任务”。这不是降低工程要求，而是改变工程对象。
一个好的 harness 不会盲目相信模型，也不会把模型绑死。它要在能力和约束之间取得平衡。如果约束太少，agent 可能误读任务、滥用工具、扩大错误后果；如果约束太多，系统又会变得僵硬，模型无法发挥推理、适应和探索能力。真正的难点不是“让 AI 自由行动”或“让 AI 完全受控”，而是决定哪些地方应当开放，哪些地方必须收紧。
例如，在代码生成场景中，agent 可以自主阅读仓库、提出修改、运行测试，但不能直接部署生产环境；它可以编辑文件，但关键变更需要 diff 审查；它可以调用搜索工具，但必须记录依据；它可以生成解决方案，但要经过测试、静态检查或人工确认。这些安排并不直接提升模型智力，却显著改变模型行动的后果。模型仍然是模型，但它被放进了一个更可靠的执行结构中。
从这个角度看，harness engineering 的核心不是控制模型说什么，而是规定模型在什么条件下可以执行任务：依据什么信息，能调用哪些工具，做到哪里必须停下来，失败后如何被发现和恢复。它把“智能”从一个单点能力变成一个系统能力。一个普通模型放在良好的 harness 中，可能比一个强模型放在混乱环境中更可用，因为真实工作需要的不只是生成答案，还需要证据、边界和责任链。
更深一层，harness 也是权力结构。它决定 agent 能接触什么信息，哪些来源被视为可信，哪些操作被允许，哪些风险被优先防止。它不只是技术基础设施，也是在定义模型所能看见和行动的世界。一个设计粗糙的 harness 会把偏见、盲区和组织惯性写进系统；一个设计清楚的 harness 则应当让这些选择变得可见：信息来源可追溯，权限边界可审查，失败过程可追踪，异常结果可纠正。
因此，harness engineering 不应被理解为“让 AI 自动化一切”的工具。它更像是一种责任分配机制：哪些任务交给模型，哪些判断留给人，哪些步骤由程序验证，哪些失败必须中断流程。它承认模型有能力，也承认模型会犯错；它利用模型的不确定性带来的创造力，同时限制这种不确定性可能造成的损害。
未来的 AI 系统竞争，很可能不只发生在模型层面，也会发生在 harness 层面。谁能设计出更好的工具环境、权限结构、反馈回路和验证机制，谁就能更稳定地把模型能力转化为真实生产力。模型回答得好只是开始；模型能否在复杂系统中安全、连续、可审计地行动，才是更深的工程问题。
Harness engineering 的意义正在这里：它把 AI 从“会说话的模型”推向“能工作但受约束的系统”。它提醒我们，可靠的智能不是单独生成出来的，而是在合适的结构中运行出来的。
Footnotes
-
Harness engineering 暂无稳定通行的中文译名。这里保留英文，指围绕 AI agent 建立工具、权限、验证、记忆、观察和反馈机制的系统工程实践。harness 原意有“马具、束带、控制装置”之意，在这里更接近“运行支架”或“约束性执行环境”。 ↩