从 Workflow 到 Harness：生产级 Agent 编排需要什么

Agent 编排的核心，不是把更多节点和角色连接起来，而是让模型的动态决策能够被约束、验证、恢复和审计。

过去一段时间，许多团队开始搭建可视化流程、串联工具调用、配置多角色协作，并希望由此得到一个能够稳定交付结果的“智能员工”。

但系统一旦进入真实业务，问题往往随之出现：流程越长，失败点越多；工具接入越多，误调用和重复调用越难避免；角色数量增加后，责任边界反而变得模糊；任务看似执行完成，结果却未必符合业务要求。

这些问题并不意味着 Agent 编排没有价值，而是说明一个重要事实：

Agent 编排不是把大模型放进工作流，也不是把流程图变得更复杂，而是围绕模型建立一套可运行、可约束、可恢复的任务执行机制。

本文讨论的不是模型训练，也不是某个具体框架，而是企业级 Agent 在工具调用、长任务执行和高风险操作中的运行机制。更准确地说，生产级 Agent 通常是三种能力的组合：

• 工作流负责确定性步骤、审批、分支和补偿；
• Agent负责根据目标和中间结果进行部分动态决策；
• Harness负责管理 Agent 的状态、工具、权限、验证、恢复和观测。

真正成熟的系统，往往不是三者择一，而是用确定性机制包住关键边界，把动态决策限制在适合模型发挥作用的局部环节。

一、工作流、Agent 与 Harness 的边界

工作流与 Agent 的差异，不宜简单概括为“确定性”和“不确定性”。现实中的工作流同样可以包含条件分支、重试、人工审批、异步暂停和恢复。真正的区别，在于任务路径主要由谁决定，以及结果如何被确认。

维度	工作流	Agent 式系统
路径来源	主要由设计者预先定义	部分路径由模型根据上下文决定
决策方式	规则、条件和固定分支	模型判断、工具反馈和动态规划
异常处理	预定义重试、补偿或人工分支	根据失败原因选择重试、替代工具、澄清或转人工
任务完成	流程节点按预期执行	最终结果达到明确的业务标准
风险控制	节点级权限和审批	工具级、数据级、动作级权限与审批

例如，将 Markdown 转换为排版 HTML，可以设计成固定流程：读取内容、套用模板、生成 HTML、输出文件。这类任务的路径明确，工作流就足够有效。

但如果要求系统根据文章主题选择版式，处理不符合规范的内容，检查编辑器兼容性，并在校验失败后重新处理，任务就不再只是格式转换。系统需要根据中间结果决定下一步行动，也需要判断什么时候算完成。这时，Agent 式决策才有发挥空间。

安全辅助任务则更加典型。“发现一个系统中的风险”无法被简单拆成一组永远固定的步骤。信息收集之后，下一步取决于目标暴露面、已经获得的线索、工具返回的结果和权限边界。漏洞发现、验证、利用条件判断和报告组织之间，都存在需要动态判断的环节。

因此，判断一个系统是否具备 Agent 式特征，不能只看它是否使用了大模型或工具调用。更合理的标准是：

如果系统只能按照固定节点顺序执行，它更接近工作流；如果系统能够根据中间结果选择行动、调整路径，或决定是否继续执行，它具备 Agent 式决策特征。

但这只是“具备 Agent 特征”，并不等于“达到生产级”。生产级能力还取决于系统是否能够记录状态、约束权限、验证结果，并在失败后恢复或转交人工。

二、Harness 是什么：围绕模型建立的运行时控制层

Harness 不是某个单独的组件，也不是一个必须采用的框架名称。本文所说的 Harness，指的是围绕模型建立的运行时控制层，负责处理以下问题：

• 模型能够看到哪些任务信息；
• 模型可以调用哪些工具；
• 工具调用失败后如何处理；
• 任务状态如何保存和恢复；
• 哪些动作需要审批；
• 什么条件下任务才算完成；
• 如何记录、评估和复盘执行过程。

模型决定系统能够“想出什么”，Harness 决定系统能否“在边界内做成什么”。

一套生产级 Harness，至少需要覆盖六类能力。

任务边界与停止条件

模型倾向于扩展问题范围，但企业任务必须有明确边界。

Harness 首先要把模糊目标转化为可执行约束：

• 哪些任务可以自主完成；
• 哪些情况必须请求澄清；
• 哪些操作需要人工审批；
• 哪些数据和系统绝对不能访问；
• 什么条件满足后应当停止。

在企业即时通信场景中，“回答一条信息”“代表用户发送消息”“修改外部系统记录”，看起来都属于协作动作，但风险等级完全不同。系统不能使用同一套权限逻辑处理它们。

同样，在安全辅助场景中，目标范围、授权状态和允许使用的工具必须在任务开始前确定。模型可以帮助分析线索，但不能自行扩大测试范围，也不能把“发现可能存在风险”直接等同于“允许执行高风险动作”。

工具与行动接口

Agent 的能力来自工具，但工具数量不等于系统能力。

工具过多会扩大模型的选择空间，增加错误调用、重复调用和无效探索。更重要的是，工具接口本身决定了模型是否能够理解行动后果。

一个可控的工具至少应明确：

• 输入和输出 schema；
• 权限范围；
• 超时条件；
• 错误码和失败原因；
• 是否幂等；
• 是否可以重试；
• 是否提供真实执行回执；
• 是否需要人工确认。

工具不是功能菜单，而是模型的行动接口。输入含义模糊、返回结果不完整、失败原因不可解释的工具，都会把不确定性传递给上层 Agent。

在内容生产任务中，格式转换、主题应用和兼容性检查可以分别设计为职责清晰的工具。Agent 决定处理顺序或是否重新处理，但具体的结构检查和转换动作应尽量交给确定性程序完成。

在安全辅助任务中，信息收集、风险验证和报告生成也应保持清晰边界。尤其是涉及外部写操作或高风险测试的工具，需要单独的授权和审批路径。

上下文与任务状态

历史对话不等于完整记忆。企业 Agent 更需要的是可管理的上下文与状态。

至少应区分以下几类信息：

• 会话状态：当前任务进行到哪一步；
• 任务状态与执行历史：已经尝试过什么，哪些结果被验证或否定；
• 外部知识与业务数据：知识库、业务对象和实时查询结果；
• 用户偏好：经过授权并具有长期价值的偏好信息；
• 权限与策略上下文：当前身份、数据范围、动作限制和审批状态。

这些信息的生命周期和授权方式并不相同，不能简单地全部塞进模型上下文。

尤其需要明确：权限不能依赖模型的记忆来决定。 模型可以读取权限状态并据此规划，但最终的访问控制必须由独立的策略系统强制执行。

任务状态同样不能只保存在对话历史中。长任务需要知道已经完成了哪些步骤、哪些工具调用成功、哪些结果待验证，以及任务暂停后从哪里继续。没有这些信息，系统遇到失败时很容易重复试错，甚至重复执行具有副作用的动作。

验证、恢复与人工介入

模型输出不能直接等同于任务结果。

生产系统至少需要两类校验：

1. 确认工具动作是否真实执行成功；
2. 确认最终结果是否满足业务验收标准。

前者依赖工具回执、状态查询或执行日志，后者则依赖规则、解析器、测试器或结构化评审。

例如，内容生产任务可以验证 HTML 结构、必填字段、链接状态和编辑器兼容性。安全辅助任务则需要区分“待确认线索”“已经验证的结果”和“最终报告结论”，不能因为模型表达得确定，就把未经验证的内容当作事实。

一个实用原则是：

能用确定性程序验证的，不要只依赖模型自检。

验证失败后，系统还要有明确的处理路径：重试、替换工具、降低任务范围、请求澄清、转人工或终止任务。对于具有副作用的操作，还需要考虑幂等、回滚和重复执行风险。

权限、审批与审计

当 Agent 从回答问题进入执行动作，权限就成为系统核心能力。

系统必须能够回答：

• Agent 以谁的身份行动；
• 它可以访问哪些数据；
• 它可以调用哪些工具；
• 哪些动作需要人工确认；
• 审批依据是什么；
• 每一步由什么信息触发；
• 出现问题后能否还原决策和执行路径。

安全辅助场景尤其需要严格区分分析动作和高风险动作。模型可以在授权范围内整理信息、分析风险和生成报告，但涉及外部系统写入、敏感数据处理或高风险验证的动作，应当受到独立的权限控制和人工审批约束。

审计记录也不应只保存最终答案，而应尽可能记录任务目标、使用的工具、关键参数、工具回执、审批结果、验证结果和人工介入节点。只有这样，团队才能定位问题究竟来自模型判断、工具执行、权限策略，还是任务设计。

观测与评估

Agent 的错误不一定表现为接口报错。更常见的情况是：系统看起来完成了任务，实际上完成错了，或者以过高成本完成了任务。

因此，评估不能只关注模型的单轮回答质量，还应关注完整任务闭环：

• 任务完成率；
• 结果验收通过率；
• 工具调用成功率和误调用率；
• 无效循环比例；
• 平均人工介入率；
• 单任务模型与工具成本；
• 平均延迟；
• 长任务恢复成功率；
• 高风险动作拦截率；
• 失败原因的可归因比例。

不同场景的重点也不同。客服更关注延迟、回答质量和转人工率；内容生产更关注验收通过率、格式正确性和兼容性；安全任务则更关注权限、审计、误报和人工介入。

没有这些指标，团队就只能根据零散案例判断系统“好像还行”或“偶尔不稳定”，很难知道问题来自模型、提示词、检索、工具定义、权限规则，还是任务拆解方式。

三、多 Agent 的价值：稳定分工，而不是角色表演

多 Agent 容易被误解为给系统配置更多角色：规划者、执行者、审查者、总结者。这样的角色命名本身并不会带来能力提升。

如果多个角色共享相同的上下文、使用相同的工具、遵循相同的目标，也没有明确的交接协议，那么它们可能只是让同一个问题被重复处理几次。更多调用还会带来更高的延迟、成本和错误传播风险。

引入多 Agent，至少应满足以下条件：

• 存在稳定的专业能力边界；
• 存在独立的权限边界；
• 不同角色拥有不同的输入、工具或评价标准；
• 拆分后的收益足以覆盖额外调用和协调成本。

常见的合理分工包括：

专业能力分工

一个组件负责知识检索，一个组件负责外部系统操作，另一个组件负责结果验证。它们的工具、输入和验收标准不同。

风险隔离分工

规划与执行分离。规划组件可以提出行动方案，执行组件只有在权限和审批满足条件时才能执行高风险动作。

上下文隔离分工

复杂任务拆成相对独立的子任务，减少单一上下文的膨胀。但这并不意味着所有上下文隔离都需要多个 Agent，也可以通过子任务、独立会话或工具层实现。

质量控制分工

执行组件负责完成任务，评审组件依据明确标准检查结果。评审标准应尽量结构化、可验证，而不是让另一个模型凭感觉重新生成一遍答案。

判断是否需要多 Agent，可以先问：

单 Agent 的失败，究竟是能力不足，还是任务边界、工具接口和验证机制没有设计好？

如果问题主要出在系统设计，增加角色通常只会增加协调成本。只有当任务确实存在稳定分工，并且每个角色能够承担不同的责任时，多 Agent 才有必要。

四、编排系统的评价重点：从搭建流程到稳定运行

可视化编排仍然有价值。它可以帮助团队表达任务结构、配置节点、管理分支，并降低部分构建门槛。但当 Agent 进入生产环境后，企业真正关心的往往不再只是“能否搭建流程”，而是：

• 长任务能否暂停、恢复和续跑；
• 工具失败后能否识别原因并选择合适的处理方式；
• 多个任务共享状态时能否避免相互污染；
• 知识检索结果能否与实时工具结果正确结合；
• 输出能否通过程序化验收；
• 高风险操作能否被授权、审批和拦截；
• 失败后能否定位责任和复盘原因；
• 模型调用、工具调用和人工介入的成本是否可接受。

从这个角度看，Agent 编排系统的价值不应只由节点数量、角色数量或工具数量衡量，而应由任务运行质量衡量。

一个更完整的评价框架可以概括为：

能不能完成任务，能不能稳定完成，失败后能不能恢复，风险能不能控制，问题能不能解释。

这也解释了为什么生产级系统需要同时使用工作流和 Agent。确定性步骤、审批、权限和补偿逻辑适合由工作流或规则系统控制；目标理解、信息整理、工具选择和局部路径规划，则可以交给 Agent。两者的结合，通常比任何一方单独承担全部任务更稳妥。

五、企业落地：从一个可验收的任务闭环开始

最容易失败的起点，是构建一个什么都能做的通用助手。范围越大，工具越杂，权限越难定义，结果也越难评估。

更稳妥的做法，是先选择一个边界清楚、价值可衡量、结果可验证的任务。可以从以下问题筛选：

• 任务输入是否相对稳定；
• 工具数量是否可控；
• 结果是否存在明确验收标准；
• 失败后是否可以重试、回滚或转人工；
• 权限边界是否能够提前定义；
• 是否能获得上线前后的对比数据；
• 自动化收益是否足以覆盖模型、工具和人工介入成本。

内容生产是一个相对适合建立闭环的例子。任务可以限定为“从文章内容生成可发布版本”，由模型处理主题理解和版式选择，由工具完成格式转换，再由程序检查结构、链接和兼容性。验证失败时重新处理，仍无法通过时转交人工。

安全辅助则代表另一类高风险任务。系统可以限定在授权范围内完成信息收集、风险分析和报告输出，但需要对目标范围、工具权限、敏感数据和高风险动作进行独立控制。最终结论还应区分线索、验证结果与报告判断，并保留完整审计记录。

一个最小的生产闭环可以写成：

目标定义 → 工具调用 → 状态记录 → 结果验证 → 失败处理 → 人工接管 → 指标复盘

当一个闭环稳定运行后，团队积累的不只是一个应用，还包括可复用的工程能力：

• 工具接口规范；
• 权限和审批模型；
• 任务状态管理方式；
• 记忆与上下文策略；
• 结果验收规则；
• 异常处理路径；
• 人工介入机制；
• 任务级评估指标。

这些能力能够迁移到新的业务场景。相反，如果一开始就追求“全能”，系统往往会同时面对上下文混乱、工具泛化、权限失控和效果不可评估等问题。

结语：编排的目标是可控执行

Agent 的价值，不是让模型看起来更像人，而是让模型能够在真实系统中完成任务，并且满足可接受的成功率、成本、延迟和风险要求。

流程图可以描述步骤，但不能天然解决模型判断偏差、工具执行失败、长任务状态管理、权限边界和结果验收。生产级 Agent 需要的，是一套将这些问题纳入运行时控制的机制。

因此，Agent 编排不应被理解为“加了大模型的工作流”，也不应被理解为“增加更多角色和节点”。更准确的定义是：

以模型承担部分动态决策，以工作流控制确定性边界，以 Harness 提供状态、工具、验证、权限、恢复和观测能力的任务系统。

衡量这类系统是否成熟，关键不在于它能调用多少工具、配置多少角色，而在于它能否稳定完成任务，能否通过业务验收，能否在失败后恢复，能否拦截高风险动作，以及能否解释问题是如何发生的。

编排的终点不是更复杂的流程图，而是让不确定的模型行为进入一个可观测、可治理、可迭代的执行系统。

JOTO 企业落地观察

• 企业部署生产级 Agent 时，Harness 层的缺失会导致模型决策无法被约束和审计。这意味着团队必须在工具接口定义、权限策略建模和状态持久化上投入大量工程资源，而非聚焦于业务逻辑本身。
• 这类系统的取舍在于：是否将验证、恢复、审批等能力下沉为平台级能力，还是在每个 Agent 应用中重复实现。Harness 的成熟度直接决定多场景复用效率与跨团队协作成本。
• RAG 知识工程需与 Harness 协同——知识检索结果必须作为受控输入注入 Agent 上下文，而非自由拼接；其时效性、来源可信度和访问权限也需由 Harness 统一管理，否则将放大幻觉与越权风险。
• AI 安全治理的关键落点正从模型层前移至 Harness 层：任务边界设定、高风险动作拦截、审计日志完整性，均依赖 Harness 对执行全过程的可观测与强管控，而非仅靠模型微调或提示词约束。