AI智能体编排怎么做：协作模式、人工审批与成本控制

AI智能体编排要做好，首先得明确下一步由谁负责，再考虑增加智能体。从需求受理、资料研究到起草和审批，主要决策可以归入 4 种模式：主智能体带领工作智能体、专家之间交接、带检查点的图，以及包裹智能体的持久化工作流。发送消息、支出费用或修改记录的权限，都应由模型之外的机制掌控。

文中所引用的文档与基础设施价格已于 2026 年 10 月 13 日核实。 业务示例均为设计方案，不代表已落地的项目，也不是性能基准测试。

什么是 AI智能体编排？

编排要决定：下一个由哪个智能体工作、它能获得哪些信息，以及结果转化为实际操作之前必须满足什么条件。 智能体由模型、指令和工具组成。编排器负责协调这些智能体，管理任务归属、共享状态、允许的流转路径和停止条件。

负责受理的智能体，可能已经能把杂乱的需求整理成清晰的任务说明。但增加研究和写作智能体之后，新的问题就来了：证据相互矛盾，谁来判断？审批人看到的是哪一版草稿？邮件服务超时，邮件到底发出去了没有？这些都需要在流程设计中解决。

选择模式时，先看需要明确哪种责任边界：

这些模式可以嵌套使用。一个管理业务事项的持久化工作流可以调用图；图中的节点，也就是一个步骤，又可以让主智能体分派研究任务。每一层都应承担明确的职责。没有独立职责却增加一层，只会多一个需要排查问题的地方。

从单智能体走向多智能体，关键变化在于责任如何落实。 运营负责人需要看到一个事项队列，清楚每件事由谁负责、下一步做什么；工程负责人需要可保存的状态和可恢复的执行机制；采购方则要弄清楚，所选服务负责运营其中哪些能力，哪些仍需自己承担。

主智能体带领工作智能体：始终明确一个负责人

如果任务需要不同专长的协作，但最终必须形成一份统一的答复，就适合采用主智能体加工作智能体的模式。 可以把它理解为方案负责人请同事收集证据，再由自己整合成方案。同事提供材料，不各自向客户作出承诺。

例如，处理销售运营需求时，主智能体可以分别安排客户研究和内部产品适配评估，再把结果整合为起草说明。

1. 1

   明确主智能体的目标与权限边界

   目标是一份有证据支撑的方案草稿。允许开展的工作是研究和起草。发送方案、承诺折扣和更新客户记录，仍是独立的操作。

2. 2

   分派范围清楚的研究任务

   给每个工作智能体提供相关资料、可用工具、预期输出和停止规则。彼此独立的研究可以并行；确实依赖另一项任务结果的工作，则应等待。

3. 3

   先交回证据，再整合结论

   要求返回来源引用、研究发现和尚未解决的问题。主智能体处理矛盾并生成草稿。缺失的来源仍然是缺失的，不能经过一次总结，就变成语气笃定的结论。

4. 4

   将产出提交审批

   客户负责人审核拟发送的消息、收件人和承诺内容。发送步骤由应用控制，只能执行已经批准的内容。

Claude Agent SDK 是 Anthropic 提供的可编程智能体运行时，通过子智能体实现这一模式：每个子智能体都是独立实例，拥有自己的指令、上下文和工具访问权限。通过 agents 选项定义子智能体，主智能体再通过 Agent 工具调用。普通的非 fork 子智能体不会收到父智能体的对话历史，因此任务提示中必须提供它所需的上下文。父智能体收到的是子智能体的最终报告。Claude 子智能体文档。

这里值得明确的是证据交付要求。研究智能体可以同时返回建议和支撑建议的原文段落。**需要注意：**上下文隔离也可能让关键的客户限制条件被遗漏。应显式传入这些条件，并保留支撑材料供审核。

CrewAI 是一个围绕角色与任务组织智能体的框架，提供使用 manager_llm 或 manager_agent 的分层流程。管理者负责规划、分派和审核任务输出。顺序流程则依照任务列表执行，并将前序结果作为上下文。CrewAI 流程文档。

当任务分配需要判断时，可以选择分层流程。如果研究必须始终先于起草，明确的顺序更容易检查。**需要注意：**管理者的审核仍然是自动化判断。CrewAI 的 human_input 任务选项会请求人工审核最终答案；研究和起草任务应只具备读取能力，避免人工审核尚未发生，就已经完成了有实际影响的写入。CrewAI 任务文档。

智能体交接：让专家接管下一步决策

如果后续回复或某条工作分支应由另一位专家负责，就使用交接。 这类似于把客服事项连同记录转给账单团队。它不同于向账单团队咨询一个问题，然后仍由自己负责整个事项。

OpenAI Agents SDK 是用于构建智能体应用的库，它明确区分了这两种责任关系：交接会把控制权转给专家智能体；将智能体作为工具调用，则仍由管理者负责回复。JavaScript 中的 agent.asTool() 支持后者。交接时可以附带结构化元数据或筛选后的对话历史。OpenAI 编排文档。

以客户运营收件箱为例，可以按以下顺序处理：

1. 受理智能体识别出账单争议，收集相关账户和发票引用。
2. 它将事项交给账单专家，同时附上客户诉求、已核实的事实、待解决的问题，以及允许采取的后续操作。
3. 账单专家调查并起草处理方案。后续回复由它负责，而不是向受理智能体交回一份研究备忘录。
4. 任何拟议的退款或账户变更，都必须先由人工批准，相关工具才能执行。

**需要注意：**交接转移的是控制权，不是业务授权。智能体不能仅因受理智能体把事项转了过来，就自动获得退款权限。操作规则应在退款工具的执行环节强制落实。

还要决定专家能否把事项转回。可以允许附带原因的明确升级处理，同时限制重复转交的次数。否则，一个含糊的请求可能在专家之间来回打转，不断消耗模型调用，却毫无进展。

该 SDK 的审批生命周期会返回中断信息和可恢复状态，供应用审核。对于延后作出的决定，应持久化保存状态，并恢复同一次运行。输入护栏作用于首个智能体，输出护栏作用于生成最终输出的智能体；敏感工具周围仍需设置检查，不能假定外围护栏会检查每一次内部操作。OpenAI 人工审核文档。

带检查点的图：把下一步路径写清楚

如果允许走哪些路径，比让哪个智能体临场规划更重要，就使用图。 图是一组由规则连接起来的步骤。检查点则是保存下来的进度记录，让流程能够暂停，并在之后继续。

LangGraph 是面向有状态智能体工作流的框架，支持明确的流程路径，包括分支和并行任务。其检查点保存器为线程保存图状态，interrupt() 机制则可暂停执行，等待外部输入。使用 Command(resume=...) 恢复被中断的线程。LangGraph 工作流模式、中断文档。

以采购团队准备供应商推荐方案为例：

1. 1

   用结构化状态保存事项

   将需求、证据引用、缺失信息、草稿位置和审核状态分别存入明确命名的字段。可以附上对话记录，但当前状态不能只藏在对话里。

2. 2

   画出允许的流转路径

   必填字段齐全后，事项从受理进入研究；信息缺失则退回请求方。研究结果进入起草环节；证据检查也可以将事项退回，开展有针对性的补充研究。

3. 3

   保存检查点，暂停等待审核

   保存拟议的推荐方案，并在需要审批的工作开始之前中断。采购负责人审核的应是确切的产出版本、支撑证据和所申请的操作。

4. 4

   沿获准的分支恢复执行

   批准后才能提交。若要求修改，则返回起草环节，原审批随之失效。若被拒绝，则记录原因并关闭事项。

**需要注意：**恢复 LangGraph 中断时，包含中断的节点会从头重新执行。中断之前的代码会再次运行。应把有实际影响的写入放在单独受控的步骤中，并让可重复执行的操作具备幂等性：重复同一个逻辑请求，不应产生额外效果。LangGraph 中断规则。

例如，一个节点如果先提交供应商记录，再请求审批，就已经越过了权限边界。恢复时，它还可能再次提交。正确的顺序是先准备拟议变更，获得批准，再用稳定的操作标识执行已批准的变更。

生产环境应选择持久化的检查点存储。LangGraph 的内存保存器会在进程重启后丢失检查点。可持久保留的线程标识和数据库支持的状态存储，都是恢复设计的一部分。LangGraph 持久化文档。

持久化工作流：让事项不随智能体调用结束而中断

如果业务流程必须在智能体调用结束、工作进程重启，或外部响应延迟后继续存在，就需要持久化工作流。 它负责事项的整个生命周期：启动、等待、重试、恢复、完成或升级处理。智能体只是这个生命周期中的参与者。

Cloudflare Workflows 是提供持久化多步骤执行的服务，支持步骤持久化和可配置的重试。用 step.do 执行工作，用 step.waitForEvent 等待外部决定，再用 instance.sendEvent 将决定传给等待中的实例。Cloudflare Workflows、事件文档。

以运营团队处理定制服务请求为例：

1. 请求到达时，创建事项记录和稳定的工作流标识。
2. 调用研究智能体，将其证据材料持久化保存，再把材料交给起草智能体。
3. 保存拟发送的回复，等待运营负责人的审批事件。审批界面应同时标明事项和产出版本。
4. 验证审批决定，并在独立步骤中执行获批的发送或记录更新。
5. 保存外部回执并完成事项。如果无法确认是否完成，先与外部系统核对，再发起另一次写入。

**需要注意：**持久化执行不会自动让外部服务的操作变得可安全重复。Cloudflare 明确建议采用幂等 API 调用、细粒度步骤和确定性的步骤名称，并提醒不要在 step.do 之外产生副作用。如果服务已接受发送请求，但响应丢失，未做去重就重试，可能导致再次发送。Workflows 规则。

应为暂时性故障配置重试，也就是那些无需修改请求、稍后可能自行消失的故障。身份验证失败、审批被拒或业务指令无效，通常需要介入处理。Cloudflare 提供重试配置，也提供 NonRetryableError，用于标记应停止重试的错误。重试文档。

配置了持久化检查点的 LangGraph 应用，本身就具备恢复能力。只有当额外的工作流引擎负责跨服务、回调和智能体运行时的更完整生命周期时，引入它才有价值。应避免两层机制分别重试同一个付费操作或会产生副作用的操作。关于这条边界，可进一步阅读托管智能体的结果、webhook 与 Cloudflare 工作流。

人工审批应设在操作执行之前

有实际影响的操作，应在执行之前由人工批准其确切内容。 如果其他智能体之后还能更改收件人、金额或附件，仅仅审核一份流畅的草稿并不足够。

以方案为例，审核界面应展示收件人、最终消息、所附文档、商业承诺，以及不确定说法背后的证据。审批记录应把审核人的身份与该产出版本、该操作的参数绑定起来。

执行器应在采取操作之前，立即检查这条记录。如果草稿或目标地址在批准后发生变化，就将事项退回审核。应使用有权限人员作出的明确批准决定，并将评论、修改建议与批准决定分开记录。

CrewAI Flows 可以通过 @persist 持久化状态，通过 @human_feedback 暂停并等待反馈。涉及有实际影响的操作时，有一个细节必须留意：配置了 emit 结果后，反馈机制会使用语言模型，把自由文本反馈解读为某个结果。授权应依赖单独验证的审批字段，不能仅凭模型对评论的解读，就认定获得了操作许可。CrewAI Flows 文档。

流程中凡是可能产生新购买的地方，还应另设权限边界。连接失败后的重试，与智能体因不满意已完成的结果而再次付费购买输出，是两种不同的决定。后者需要事先明确的支出额度，或重新获得批准。这个更具体的故障模式，可参见AI 智能体重试的人工审批。

日志记什么，限制设在哪？

日志应足以还原整个事项，并在开始更多工作之前落实各项上限。 一份漂亮的最终答复，无法解释流程为什么发错了内容，或为何超出预算。

事项记录与执行事件应包含以下几组字段：

• **身份与父子关系：**事项 ID、工作流或运行 ID、父运行与子运行 ID、智能体角色、当前步骤和尝试次数。这些信息能把工作智能体的故障追溯到具体业务请求。
• **输入与配置：**输入材料的引用和版本、模型标识、提示词或配置版本，以及允许使用的工具集合。这些字段用于识别不同运行之间发生了什么变化。
• **决策与证据：**路由决定、选定目标、来源引用、验证发现和缺失信息。记录可观察的决策与简明理由，不依赖模型内部的推理过程。
• **审批：**审核人、决定、时间戳、产出内容摘要、操作参数和有效期。这里的摘要是已审核内容的数字指纹。
• **操作与恢复：**工具名称、经脱敏的参数、操作或幂等键、外部请求 ID、回执、故障类别和计划重试时间。结果未知时，应明确保留“未确定”状态。
• **用量与结果：**模型 token 分类、预估与核对后的支出、付费工具用量、耗时、等待审核的时长、最终状态，以及结果是否获人工接受。

应限制日志的读取权限。不记录密钥等秘密信息，尽量减少客户数据；如果复制完整内容会带来不必要的暴露风险，就改用指向受访问控制材料的引用。

OpenAI Agents SDK 的追踪功能会记录模型调用、工具调用、交接和护栏。应把这些技术追踪与事项记录关联起来；客户操作是否已获批准，不能只凭技术追踪来认定。OpenAI 追踪文档。

AI智能体编排工具需要真正执行上限

为整个事项的支出、智能体轮次、工具调用、并发工作智能体数量、委派深度、交接次数、重试次数和总历时设置限制。实际执行的截止时间与人工审核的截止时间应分开设置。具体数值取决于业务可接受的成本和延迟，没有通用的安全默认值。

派发并发任务前应先预留预算，每次调用结束后再核对。否则，每个工作智能体都可能看到同一笔剩余额度，并各自花掉它。恢复运行产生的费用，也应计入同一个事项的预算。

Claude Agent SDK 提供查询级支出控制，包括 TypeScript 中的 maxBudgetUsd 和 Python 中的 max_budget_usd，也提供子智能体深度与并发控制。应根据已安装的版本，核对子智能体文档中的要求。

统计口径需要分清：usage 字段不包含子智能体活动，modelUsage 或 model_usage 则包含。total_cost_usd 包含子智能体费用，但它是客户端估算值。一次查询的支出上限，只覆盖该次调用自身的支出，不包含从恢复会话中带回的历史支出。应维护事项级账本，并依据权威用量数据核对估算。Claude 成本追踪文档。

SDK 中设置了预算，也不等于最终账单一定会精确止于该上限：文档中的受限运行结果在结束时可能达到或超过阈值。应为已在执行的任务预留余量，在业务额度耗尽前停止派发新任务。

编排成本，要按整个事项来算

预算应覆盖一个业务结果从开始到完成的全部成本，包括失败的工作和审核。 增加智能体可以缩短彼此独立的研究所需时间，也可能导致上下文重复、增加汇总调用，并形成反复修改的循环。是否划算，要看最终获接受的结果，其提升能否抵消新增成本。

可以按以下月度模型计算：

流程成本 = 模型用量 + 付费工具 + 工作流基础设施 + 状态与日志存储 + 人工审核 + 运维。

再用总成本除以获批准的结果数量，而不是智能体运行次数。失败的事项和弃用的草稿，同样要计入分子。与现有流程比较时，应使用相同的验收标准和人力成本假设；缺少这些输入，就无法推导出可信的节省比例。

作为具体的基础设施价格参照，Cloudflare 公布了以下费用：

来源：Workers 定价与 Workflows 定价。账户最低费用属于基础设施费用，并非智能体的全包价格。请求、CPU 时间（处理器执行工作的时间）、模型调用及其他服务，仍需单独核算。计费公告说明，步骤与存储计费不早于 2026 年 8 月 10 日开始；公开措辞并不能确认某个具体账户是否已启用该计费。

按公布费率换算：$0.80 除以 100,000，相当于每个额外步骤 $0.000008，尚未计入其他费用。这只是标价的单位换算，不是工作负载估算，也不是实测账单。公布的步骤费率。

等待不必依靠持续运行的模型循环。Cloudflare 表示，API 等待、休眠和空闲时间不计入 CPU 时间。状态存储和步骤计费仍需分别核算。应保存事项状态并等待事件，而不是反复询问智能体：审批人回复了没有。Workflows 定价。

AI智能体编排框架，应服务于业务流程

先确定协调与责任边界，再选择框架。 需要汇总结果时，保留一个负责人；下一位专家应独立处理时，转移负责权；允许的状态流转很重要时，使用图；工作必须超出单次调用的生命周期时，再加入持久化的生命周期控制。

逐个框架的选择，可以参考 AI 智能体框架对比。如果已经缩小到显式图状态与按角色组织的智能体团队之间，可以阅读 LangGraph 与 CrewAI 对比。

工程负责人应明确持久化方案、执行权限，以及谁负责恢复。运营负责人应明确验收标准、审批人、升级处理机制和可接受的支出。采购方则应追问：谁运营这些控制机制，记录存在哪里，以及故障后如何恢复暂停中的事项。

平台可以代为运营基础设施，但业务中什么算获批的退款、什么算有依据的方案主张，以及哪笔额外购买可以接受，仍须由业务方决定。

哪些期待被夸大了？

智能体更多，不代表结果就更好。 不同智能体应具备不同的来源、工具或职责。让功能雷同的智能体反复互相点评，可能只会消耗预算，却没有增加证据。

画出一张流程图，也不能证明系统具备持久运行能力。故障后能保住什么，取决于已保存的状态、持久化后端和重放行为。同样，在提示词里写“发送前先询问”，并不能强制执行发送规则；执行器必须检查权限。

最后，由模型自主规划的工作，应限制在边界清晰的任务内。可以让研究智能体决定接下来查看哪份相关资料，但是否暴露私有数据、批准费用或给客户发消息，必须受应用的访问与审批规则约束。

下一步，从一个流程开始

选一个流程，只补上它真正缺少的最小责任边界。 保留已经有效的智能体。写清它的输入、输出产物、工具、负责人、成功条件和停止条件，再补充缺失的研究或起草职责。

启用面向客户的写入之前，应使用有代表性且不含敏感信息的输入，演练故障场景：保存草稿后中断执行、重复投递同一批准决定、拒绝方案、更改已批准的产出、耗尽预算，以及模拟外部写入成功但响应丢失。确认每个事项都进入有记录的状态，并且下一步操作明确。

如果工作跨越不同专家的负责范围、需要等待审批，或需要可靠恢复，现在就应着手处理这些边界。如果当前的问题是源数据质量差或验收标准不清楚，则应暂缓增加智能体。一个可靠的单智能体流程，若不存在这些边界需求，可以继续保持现状。

流程负责人常问的问题

一个智能体已经够用，还需要 AI智能体编排平台吗？

只有现有应用缺少必要的协调或运维能力时，才需要考虑。先说清缺的是哪项职责：专家接管、保存进度、延后审批，还是故障恢复。具体需求决定了应增加一个库、一项工作流服务，还是少量应用代码。

同一个流程可以组合使用这些模式吗？

可以。持久化工作流负责整个事项，图控制审核路径，主智能体分派研究任务。每一层都要职责清晰，并避免对同一操作设置相互重叠的重试策略。

批准草稿，是否也等于批准再付费尝试一次？

只有审批明确包含这笔支出的范围时，才算。批准使用某份产出，与允许购买另一次尝试，应分别记录。草稿修改后，在执行有实际影响的操作之前，也必须重新审核。

审批人一直不回复，应该怎么办？

按既定规则将待审批决定标记为过期，通知责任人，并挂起或关闭事项。保留足够的上下文，供之后审核。没有回应，不能变成自动批准。

订阅通讯，获取用 AI 构建和运营业务工作流的实用指南。