真正拉开 Agent 差距的 Harness 工程：编排、护栏与模型选型

真正拉开 Agent 差距的 Harness 工程：编排、护栏与模型选型

摘要

同一个模型接入同一组工具，为什么一个 Agent 能稳定交付，另一个却循环调用、越权操作或过早宣布完成？差异往往来自 Harness：围绕模型构建的上下文、工具、约束、验证、纠正与可观测基础设施。本文给出一个五项能力分层，说明它是工程检查框架而非行业标准；随后用任务确定性、动作风险与反馈质量选择工作流、混合编排或有限自治，并把模型选型还原为能力、成本、延迟、安全和治理的多目标评估。

关键词

Harness 工程、Agent 编排、工作流、自主 Agent、护栏、模型选型、纵深防御、可观测性

CSDN 分类建议：人工智能 / 大模型应用

推荐标签：AI Agent、LLM、智能体、大模型、Agent Engineering

本文知识地图

本文先画 Harness 分层，再用自治决策矩阵做选型。核心顺序是：信息与动作使系统“能做”，约束与验证使动作“可控”，纠正使失败“可恢复”，可观测性使团队知道下一次应改哪里。
Harness 五项能力分层：

图 1：Harness 五项能力分层。来源：作者依据原书框架与官方 Agent 工程资料整理。

读图重点是纠正层回到上下文的箭头，以及横切所有层的日志、指标和追踪。由图可推出：静默吞掉错误不是恢复；只有错误被结构化记录、策略被调整、结果重新验证，闭环才真正完成。

Harness 到底是什么

Harness 原意是马具。在 Agent 工程里，它常被用来指模型之外、把模型能力接入真实环境的运行外壳。本文采用一个便于评审的展开：

Model + Harness = 模型 +（上下文 + 工具 + 约束 + 验证 + 纠正）

这仍然不是形式化定义。“五项能力”是本系列的工程分解法，用于检查可靠性缺口，不应伪装成行业标准。系统可以把验证嵌在工具内部，把纠正实现为工作流补偿，也可以由供应商 SDK 承担部分循环；只要职责清晰即可。

提示工程、上下文工程、Harness 工程也不是公认的线性历史阶段。更稳妥的理解是关注范围逐渐扩大：提示工程关注指令表达；上下文工程关注每次采样可见的全部 token；Harness 工程还关注模型之外的执行、状态、权限、验证与恢复。传统软件工程贯穿其中，从未被替代。

五项能力如何组成生产闭环

上下文：在决策点提供足够信息

上下文包括目标、约束、历史轨迹、环境状态、工具定义和检索证据。它的目标不是“尽量塞满窗口”，而是提高单位 token 的决策价值。工程上需要版本化系统指令、标记信息来源、控制动态状态新鲜度，并对长轨迹做检索或压缩。

工程经验：当 Agent 反复选错工具时，先检查工具描述、错误返回和业务状态是否可见，再考虑换模型。这个判断必须通过任务评估验证；某些任务确实会受益于更强模型。

工具：提供可理解、可约束的动作接口

工具设计要面向模型的选择与参数生成，同时面向执行器的认证、超时和幂等。Anthropic 的工具工程文章建议围绕高影响工作流设计少量清晰工具，并用评估迭代描述、参数和返回值。事实；Writing Tools for Agents

一个退款工具至少要声明金额单位、订单状态前置条件、是否可重复调用、错误码和副作用。只写refund(amount)会把歧义推给模型；把 200 个底层接口无差别暴露，又会增加选择成本和攻击面。

约束：在动作发生前限制能力

约束不应只是一句“请勿越权”。它包括身份认证、最小权限、租户隔离、参数范围、调用预算、网络出口、文件系统沙盒和人工确认。高风险规则应由代码或策略引擎执行，不能依赖同一个可能被提示注入影响的模型自我审查。

例如，Agent 可以提出“退款 500 元”，但策略层必须独立检查订单归属、可退余额、用户授权和频率限制。若需要人工确认，确认界面应显示即将发生的确切动作，而不是模糊问题“是否继续”。

验证：用环境证据判断对错

验证分为输入结构、业务语义和最终结果。工具调用 JSON 合法只是第一层；数据库状态是否变化、文件是否生成、测试是否通过才是环境证据。完成判据最好在执行前就定义，否则模型容易把“我已经处理好了”当成事实。

验证器也会出错。关键任务应保存原始证据、验证器版本和判定理由，必要时采用确定性检查、独立模型评审与人工抽检的组合。

纠正：区分重试、换路、补偿和交人

超时可退避重试，参数错误应修正后重发，权限拒绝不应无限重试，部分成功可能需要补偿事务，不确定的高风险状态应交给人工。把所有异常都包在retry(3)里，会制造重复扣款、重复邮件和更难审计的中间态。

纠正的输出要成为新观测：错误类型、调用参数摘要、已发生副作用、建议动作与剩余预算。这样模型或工作流才能做出不同决策。

工作流、自主与混合编排

Anthropic 的官方工程分类将工作流描述为预定义代码路径，将 Agent 描述为由模型动态决定过程与工具使用。事实；Building Effective Agents 这一区分非常实用：可预定义并不等于“没有 AI”，动态决定也不等于“更先进”。

图 2：自治决策矩阵。来源：作者整理。

读图重点是三个问题：路径能否预定义，动作是否高风险或不可逆，环境反馈是否快速且可验证。工程结论是：开放式搜索、调研、代码修复适合有限自治；付款、删除、发布等动作即使由 Agent 规划，也应经过确定性闸门。

适合工作流的任务

身份核验→规则检查→付款→确认等顺序固定、审计要求高的流程，优先用代码控制节点和分支。LLM 可以在节点内做分类、信息抽取或生成，但不能跳过必需步骤。工作流的代价是未覆盖异常需要显式分支或人工处理。

适合有限自治的任务

研究、排障、Coding Agent 等任务的步骤难以穷举，环境又能提供搜索结果、测试或文件差异作为反馈，可以让模型选择下一步。但必须限制目录、网络、工具、轮次、时间和费用，并在每轮验证进展。

生产中更常见的混合模式

模型负责识别意图、提出计划和在低风险范围探索；工作流负责身份、交易、审批与补偿。例如机票 Agent 可以自主比较航班，却只能通过固定支付流程完成购买。作者推断：混合模式通常比“一切代码化”或“一切自主化”更容易形成清晰责任边界，但多一层切换也会增加状态同步和测试成本。

Agent 框架比较：按责任边界选，不按功能数量选

源稿列举的框架和产品会快速改版，因此这里把比较重写为稳定维度。轻量 SDK 适合团队自己掌控 Loop、消息和日志；图式工作流适合显式状态、检查点和人工节点；托管 Agent 平台减少运维，却把会话、工具执行和可观测性的一部分交给供应商；MCP 等协议解决能力接入，不替代编排、授权和验证。

选型时至少做四个最小原型：同一任务能否中断后恢复，工具副作用能否幂等重放，完整上下文能否导出审计，模型或供应商能否替换。再比较状态持久化、并发/取消、人工确认、追踪、部署边界和锁定成本。实践建议是先选择能暴露底层消息与状态的最小抽象；只有当图编排、托管伸缩或多租户治理确实减少自建成本时再加层。框架能“接入很多工具”不是可靠性证据，官方示例跑通也不是生产验收。

模型选型：不是品牌表，而是多目标评估

源稿按厂商和能力特点介绍模型，这类信息变化极快。生产选型应把模型视为可替换组件，在自己的任务分布上比较：

不要先问“哪个模型最强”，先定义最低成功率、最大预算、最大 P95 延迟和不可接受风险。然后找满足约束的 Pareto 前沿。高能力模型可能减少循环次数，反而降低总成本；小模型在固定分类节点可能更快更便宜。结论只能由端到端评估给出。

护栏：纵深防御，不是一个分类器

OpenAI 的官方 Agent 指南明确指出，护栏应采用多层、专门机制，并与认证授权、严格访问控制和传统软件安全措施结合；单层防护不足。事实；OpenAI Practical Guide

可以按位置组织：

• 输入侧：身份、速率限制、内容类型、来源可信度、恶意输入检测；
• 执行侧：工具风险评级、参数策略、沙盒、网络出口、密钥隔离、人工确认；
• 输出侧：结构验证、PII/秘密扫描、引用与事实检查、品牌或监管规则；
• 运行侧：最大轮次、费用、超时、异常频率、熔断与审计。

OpenAI Agents SDK 的官方文档提供输入、输出和工具护栏，并允许并行或阻塞式检查。事实；Guardrails 但 SDK 有机制不代表策略正确：如果输出护栏使用同一模型、读取同一被污染上下文，它可能共享失败模式。高风险验证应尽量依赖结构化业务数据和独立授权系统。

NIST AI RMF 以 Govern、Map、Measure、Manage 组织 AI 风险管理。事实；NIST AI RMF 它是自愿框架，不能替代具体行业法规，却提醒团队：风险不是上线前加一个过滤器，而要进入治理、场景映射、测量和持续管理。

能力、成本、延迟、安全如何一起权衡

自治每增加一轮，可能提升开放任务成功率，也增加一次模型延迟、token 成本、工具失败概率和攻击面。不能用单一指标做决定。一个实用方法是建立硬约束与软目标：

1. 硬约束：绝不越权、金额上限、数据地域、最大运行时间；
2. 软目标：成功率最大、成本最小、延迟可接受；
3. 分层预算：每任务轮次、每工具次数、每日费用和租户配额；
4. 降级路径：强模型超时后切换工作流、只读模式或人工；
5. 灰度策略：从低风险任务、少量流量逐步放开。

工程经验：先限制动作空间，再评估模型能在边界内做到什么，通常比先给全权限再补护栏容易。但若限制过严，Agent 会频繁交人或无法完成任务，仍需用数据调整。

常见误区与修正

误区一：Harness 就是 Agent 框架。修正：框架只是实现载体；业务策略、评估、权限、审计和恢复通常跨越多个服务。

误区二：五项能力是正式标准。修正：它是本系列检查表，可合并或拆分；职责与证据比命名重要。

误区三：模型越强，Harness 越薄。修正：强模型可减少某些提示与重试，也可能承担更长任务、获得更大权限，治理需求反而上升。

误区四：工作流不算 Agent，所以应追求自主。修正：名称不产生业务价值。路径稳定时，工作流更易审计；不确定局部再引入自治。

误区五：加一个安全分类器就有护栏。修正：模型分类器只是纵深防御一层，无法替代认证、授权、沙盒、硬预算和人工确认。

生产检查清单

• 为上下文、工具、约束、验证、纠正分别指定责任组件与负责人。
• 成功条件来自环境证据，不接受模型自称完成。
• 每个工具标注副作用、风险、幂等性、超时与补偿方式。
• 永久错误不盲目重试；部分成功有补偿或人工接管流程。
• 路径稳定部分使用工作流，高不确定局部才开放自治。
• 高风险动作经过独立策略引擎或人工确认。
• 模型选型使用自有任务集，报告成功率、总成本和 P95 延迟。
• 评估包含越权、提示注入、重复调用和不可逆误操作。
• 日志关联请求、模型版本、提示版本、调用 ID、策略判定与结果。
• 有费用、轮次、时间、速率和租户级硬预算及降级方案。

本文小结

Harness 的价值不是“给模型套更多提示词”，而是把不确定的候选决策接入确定性的权限、执行、验证和恢复机制。五项能力提供了一个可操作的评审视角；工作流、混合模式和有限自治则应由路径确定性、动作风险和反馈质量决定。模型选型最终是多目标约束问题，必须连同 Harness 做端到端评估。下一篇将进入最小运行单元：消息、工具调用轨迹与 Agent Loop 状态机。

延伸阅读与参考资料

官方工程资料

1. Building Effective Agents，Anthropic。（V1-R007）
2. A Practical Guide to Building AI Agents，OpenAI。（V1-R008）
3. Writing effective tools for AI agents，Anthropic。（V1-R012）
4. Guardrails — OpenAI Agents SDK，OpenAI。（V1-R013）

风险管理框架

1. NIST AI Risk Management Framework，NIST。（V1-R014）

系列导航

• 上一篇：Agent 不只是大模型：重新理解 LLM、上下文与工具
• 总目录：深入理解 AI Agent：从模型能力到生产级系统的完整路线图
• 下一篇：从一次 API 调用到完整 Agent Loop：上下文到底如何流动
  loop.md)