企业私有化 AI 多 Agent 协作怎么设计？角色、编排、交接、共享状态、权限、循环、故障与审计清单

企业把一个复杂任务拆给多个 AI Agent 后，问题很快从“谁更聪明”变成“谁负责、交给谁、带哪些数据、用什么权限、失败后停在哪里”。多个 Agent 可以缩小单个角色的提示词和工具范围，也会引入路由错误、上下文泄漏、循环调用和级联故障。下面这份清单面向私有化部署，帮助团队设计并验收角色、编排、交接、共享状态和审计边界。

先确认是否真的需要多个 Agent

单个 Agent 加少量工具已经能完成的任务，不必为“架构完整”再拆角色。每增加一个 Agent，就会增加提示词、模型调用、交接契约、权限和日志。只有当任务需要明显不同的专业知识、工具边界、数据权限或独立审核时，多 Agent 才可能带来净收益。

用业务责任划分角色

角色名称应对应可验证的职责，例如线索分类、报价规则核对、合同条款检查或资料汇总。不要设置“万能助手”“超级协调员”这类边界模糊的角色。每个 Agent 都要写明输入、输出、允许动作、禁止动作、负责人和退出条件。

每个角色只保留必要工具

研究 Agent 需要检索资料，通常不需要发送邮件；审核 Agent 需要读取草稿，不需要直接改订单。工具列表按角色单独配置，不能让所有 Agent 继承一套高权限工具。具体权限、参数与确认控制可结合AI Agent 工具调用验收清单执行。

定义用户可见的责任主体

用户应知道当前系统在处理什么、是否已转交专家、哪个动作需要确认。内部 Agent 名称可以隐藏，责任状态不能隐藏。发生错误时，系统要能说明由哪个组件提出建议、哪个执行器完成动作、哪个用户批准。

选定唯一的任务所有者

一个任务在任意时刻都应有明确 owner。管理 Agent、当前专家 Agent 或代码状态机可以承担这个角色。若两个 Agent 都认为对方会继续，任务会静默停滞；若两个都认为自己负责，又可能重复执行。

分清管理模式与交接模式

管理模式下，主 Agent 保持对话所有权，把专家作为工具调用并汇总结果。交接模式下，专家接管当前回合和后续响应。OpenAI Agents SDK 的Agent 编排说明列出了这两种模式。团队应按任务所有权选择，不能只看示例代码长短。

管理模式适合统一出口

当一个 Agent 需要整合多个专家意见、控制统一语气或集中执行护栏时，可以保留管理者。专家只返回结构化结果，不直接面对用户。管理者也不能拥有无限权限，它的主要职责是拆解、调用、合并和决定是否需要人工。

交接模式适合专业接管

退款、法务、人事等专业流程可能需要专家持续与用户对话。路由 Agent 判断场景后，把会话交给专家，专家成为当前 owner。交接应记录原因、目标、上下文版本和可返回路径，不能仅在提示词里写一句“请继续处理”。

确定性流程优先由代码编排

固定审批顺序、必做校验和资金动作不宜由模型自由决定。代码状态机可以先执行身份核验，再调用分类 Agent，最后根据结构化结果选择已批准路径。模型负责不确定判断，代码负责不可省略的边界，速度、成本和行为更容易预测。

混合编排要标清决定者

同一工作流可以由代码决定大阶段，让 Agent 选择阶段内的专家或工具。设计文档要逐个节点注明决定来自模型、规则、人工还是下游系统。否则出现错误时，团队只看到“Agent 选错了”，却不知道应修改提示词还是路由代码。

建立允许的转移图

列出每个 Agent 可以转给谁、能否返回、最大深度和禁用边。销售资料 Agent 不应直接跳到财务付款 Agent。用有向图或状态表表达转移关系，比自然语言约定更容易审查。运行时也要按图校验。

禁止任意 Agent 名称跳转

模型输出的目标名称只能从当前节点允许列表中选择。执行器不能按字符串动态加载任意 Agent 或服务。相似名称、别名和版本要使用稳定 ID 解析，未知目标立即拒绝并记录。

交接请求使用结构化契约

交接载荷可包含任务 ID、原因、优先级、目标、已完成步骤、待处理事项、相关对象和风险标记。字段要有类型、长度与枚举。OpenAI Agents SDK 的Handoffs 文档支持为交接参数定义 input type 并在本地校验，企业自建框架也应提供同等约束。

交接原因不能只写自然语言

“这个问题比较复杂”无法驱动稳定路由。建议使用受控原因码，例如 billing_dispute、identity_failed、policy_exception，再附简短说明。原因码进入报表和回归集，自然语言供接收者理解现场。

交接前检查目标是否可用

目标 Agent 可能停用、超载、版本灰度中或无权处理当前租户。路由器应在转移前查询能力和状态。不可用时选择预先批准的降级路径，例如进入人工队列，不能临时换到权限更大的 Agent。

交接必须有接收确认

发送交接事件不代表接收成功。目标 Agent 或工作队列应返回稳定确认，并绑定任务与交接 ID。超时后可以安全重试，但同一交接只能生效一次。未确认的任务仍归原 owner 管理。

同一时刻只允许一次有效交接

两个路由判断并发发生时，可能把同一任务转给不同专家。状态更新应使用版本号、条件写入或锁。冲突的一方重新读取当前 owner，再决定退出或生成新请求，不能覆盖已经生效的交接。

交接要保留返回路径

专家发现分类错误或缺少前置材料时，需要把任务退回路由者或转入人工。返回动作也属于受控转移，要携带失败原因和已完成步骤。禁止专家在目标不适合时自行猜测另一个任意 Agent。

不要默认转发完整会话

完整历史可能含与当前专家无关的隐私、密钥、内部指令和恶意内容。交接层应根据目标职责筛选消息、工具结果和附件。Handoffs 文档指出，接收 Agent 通常会看到此前会话，也提供 input filter 改变传入内容；企业应把筛选规则设为显式配置。

区分会话历史与应用状态

用户对话适合保留语言上下文，订单状态、身份、审批和任务进度必须来自可信存储。不要让接收 Agent 从摘要里推断当前金额或权限。交接载荷可引用业务对象 ID，接收者再向权威系统读取最新状态。

共享状态使用明确结构

任务状态可包含目标、owner、阶段、对象版本、已完成步骤、待办、错误、预算和批准记录。每个字段注明写入者和可见范围。把所有信息塞进一段“共享记忆”，很难做并发控制、权限检查和审计。

设置状态版本号

每次更新共享状态都递增版本。Agent 提交写入时带上读取到的版本，版本冲突就重新评估。这样可以阻止较慢 Agent 用旧结论覆盖新状态。冲突次数也应进入监控。

把临时推断与已确认事实分开

Agent 推测“客户可能要退款”不能直接写成业务事实。共享状态应标记数据来源、置信、确认人和有效期。只有来自权威系统或明确人工确认的字段，才能驱动高影响动作。

对共享记忆设置保留期限

长期记忆可能积累过期偏好、错误总结和敏感数据。每类信息规定用途、保存期、更新条件和删除方式。临时任务完成后清理工作记忆；需要长期保存的内容进入受控业务系统，不由 Agent 自行决定永久化。

防止记忆污染传播

恶意网页或错误工具结果写入共享记忆后，多个 Agent 都可能采信。写入前要校验来源和内容，读取时显示来源标签。OWASP 的Agentic Applications Top 10涵盖目标劫持、身份权限滥用、记忆与上下文污染、级联故障等风险，适合转成攻击测试集。

为每个 Agent 建立独立身份

日志和下游系统应区分研究 Agent、审核 Agent、执行器与编排服务。所有组件共用一个服务账号时，团队无法判断是谁调用，也无法单独吊销权限。身份应绑定具体工作负载和环境，不用人类个人账号替代。

同时保留用户委托身份

Agent 代表用户执行时，系统要记录发起用户、当前 Agent、执行服务和目标资源。用户权限不能在交接时丢失，也不能因进入高权限专家而扩大。每个下游请求都要重新做授权。

权限不会随交接自动继承

交接只是任务所有权变化，不等于授权转移。接收 Agent 根据自己的职责和用户委托范围重新申请必要权限。NIST 关于软件 Agent 身份与权限的概念材料明确关注识别、授权、审计和不可否认性，企业设计也应覆盖这些字段。

限制 Agent 之间的信任范围

接收 Agent 可以信任交接事件来自已认证服务，不能直接信任其中所有业务结论。对象状态、权限和高风险参数需要重新核对。发送者被提示注入后，接收者仍应有自己的策略边界。

服务令牌绑定目标受众

Agent A 调用编排服务的令牌不能原样交给 Agent B 或下游 API。MCP 的授权规范要求令牌绑定预期资源并禁止 token passthrough。每个服务应验证受众，访问上游时使用单独取得的凭据。

高权限 Agent 不直接面向任意输入

执行付款、删除或权限变更的 Agent 应只接受已验证、结构化且经过批准的任务。它不需要读取原始网页和长邮件，也不应拥有开放式检索工具。把非可信内容与高权限执行面隔开，可以缩小提示注入影响。

人工批准绑定具体动作

审批记录包含任务、执行 Agent、工具、对象、关键参数、有效期和一次性标识。交接到另一个 Agent 后，如果动作或参数变化，应重新批准。不能沿用一句“用户已同意继续”覆盖后续所有步骤。

为每条任务设置跳转上限

规定最大 Agent 数、交接次数、模型轮次和总耗时。超过上限时暂停并进入人工队列。只给模型一句“避免循环”无法形成可靠边界。预算耗尽要有明确状态，不能继续在后台消耗资源。

检测重复路径

记录最近的 Agent、原因码、对象和状态版本。若同一组合反复出现，编排器应判为循环。A 转 B、B 转 A 的双节点循环以及 A、B、C 的长循环都要覆盖。触发后保存轨迹，供路由规则修订。

评价 Agent 不能无限驳回

生成者与评价者反复修改的模式需要最大轮次和明确评分门槛。评价者指出可操作缺陷，生成者只修改相关内容。达到上限仍未通过时，保留最佳候选和失败原因，转交人工，不继续自我讨论。

并行任务必须真正独立

资料检索与格式检查可以并行，两个 Agent 同时修改同一订单则会冲突。并行前检查数据依赖、共享写入和预算。结果汇总时要等待哪些分支、允许哪些超时，也应由代码明确。

给并行分支设置取消传播

用户取消任务或关键分支失败后，其他分支应收到取消信号。已经开始的外部动作需要查询状态或补偿。仅停止主 Agent，后台专家仍可能继续调用工具。

合并结果时保留来源

管理 Agent 汇总多个专家结果时，应保留每项事实来自哪个 Agent、哪个工具和哪个时间。冲突不能通过语言润色悄悄消失。对关键差异，管理者应展示冲突或调用权威系统复核。

冲突解决使用预定规则

合规要求、业务政策和实时系统状态具有不同优先级。团队应提前规定权威来源和升级路径。让管理 Agent按“看起来更可信”选择，会让同一输入产生不可解释的结果。

工具副作用由单一执行器负责

多个 Agent 可以提出建议，真正写入订单、发送邮件或修改权限的入口应集中。执行器负责身份、授权、参数、幂等和审批检查。这样能避免两个专家分别对同一对象产生重复副作用。

每个写动作带幂等键

交接超时或队列重投可能重复触发执行。幂等键应绑定租户、任务、业务动作和对象。相同键、相同参数返回原结果；相同键、不同参数拒绝。事件重试与顺序控制可参考Webhook 与系统事件清单。

多步骤任务使用持久状态机

长任务可能跨进程重启、人工审批和外部等待。状态机保存阶段、owner、已完成动作和恢复点。内存中的对话对象不应成为唯一进度依据。OpenAI Agents SDK 的运行说明也列出面向长等待、重试和重启的持久化编排集成。

故障要限制在当前分支

一个专家超时，不应自动拖垮全部任务。编排器根据分支是否关键决定重试、降级、跳过或停止。非关键的格式检查失败可以继续并标注，身份核验失败则必须阻断后续写入。

区分暂时故障与业务拒绝

网络超时、限流和服务不可用可以受控重试；无权限、审批拒绝、对象冲突和输入非法通常不能重试。Agent 不应从一段自然语言错误中猜类型，适配器应返回稳定错误码和可重试标志。

设置断路器

某个 Agent 或工具连续失败时，断路器停止继续分配任务。系统进入降级或人工模式，并通知负责人。半开恢复要用少量测试流量验证，不能一次放回全部任务。

准备补偿而非假设全局事务

跨 Agent、跨系统的动作通常无法放进一个数据库事务。流程需要注明哪些步骤可撤销、补偿调用由谁负责、失败后怎样人工处理。补偿也使用幂等键并进入完整审计。

紧急停止覆盖所有 Agent

停止开关应能按工作流、Agent、工具、租户和版本生效。执行器在每次副作用前重新检查开关，长任务和排队消息不能绕过。演练时确认停止后没有新写入，未完成任务进入可识别状态。

记录完整协作轨迹

一次任务的 trace 应包含路由决定、Agent 开始结束、交接、模型调用、工具、护栏、审批、错误和最终状态。OpenAI Agents SDK 的追踪文档把模型生成、函数调用、护栏和 handoff 作为 span 记录。每个事件还应有 trace ID、parent ID、Agent ID 和版本，最终答复无法替代这条执行证据。

日志包含决定依据的可审计字段

记录命中的路由规则、候选目标、选定目标、原因码、状态版本和权限结果。无需保存模型隐藏推理。敏感输入可以脱敏、哈希或只保留类别，但要能回答谁在何时做了哪次交接。

日志防止跨 Agent 断链

消息队列、异步任务和外部系统会打断默认调用链。发送方把关联 ID 写入消息，接收方继续使用。重试保留原事件 ID并生成新的尝试 ID。否则一次级联故障会散落成多条无关日志。

按 Agent 统计调用和失败

看板至少显示任务量、成功率、交接率、退回率、循环、超时、token、成本和人工接管。平均指标之外，按角色、版本、场景和租户拆分。某个专家的错误不能被总体成功率稀释。

监测路由分布漂移

新提示词或模型可能把更多任务交给某个 Agent。即使总成功率暂时没降，也会形成容量和权限风险。团队要比较路由比例、未知场景、二次交接和人工转移的变化。

记录共享状态冲突

版本冲突、重复 owner、过期写入和无权字段修改都应单独告警。冲突率上升通常说明并发假设或任务划分有问题。不能只靠自动重试把冲突藏起来。

为每个角色准备单元评测

先在固定输入和模拟工具下验证单个 Agent 的职责、结构输出、拒绝和错误处理。角色本身不稳定时，直接跑端到端多 Agent 评测很难定位问题。单元集应覆盖合法边界和越权请求。

为路由准备混淆样本

测试同时涉及退款与物流、法务与销售、多个语言和信息不足的请求。评分关注路由是否正确、是否需要澄清、有没有把敏感任务发给低权限角色。相似 Agent 名称也要进入测试。

为交接准备缺字段样本

删除原因码、对象 ID、状态版本或优先级，确认契约层拒绝。加入超长摘要、非法枚举和伪造 owner，检查执行器是否在接收前校验。模型能读懂错误载荷不能成为放行理由。

为上下文筛选准备泄漏样本

在会话前段放入与目标专家无关的客户信息、内部提示和令牌样式文本。交接后检查接收 Agent 的实际输入，而非只看它有没有复述。需要隐藏的字段不应进入目标模型上下文。

为身份权限准备横向访问样本

让低权限 Agent 尝试请求高权限 Agent，使用 A 租户任务引用 B 租户对象，并重放旧交接令牌。预期在编排层和下游层都被拒绝。统一身份建设可参考企业统一身份与权限管理清单。

为循环和预算准备压力样本

构造互相退回、评价不通过、工具持续报错和无限澄清场景。确认跳转上限、费用上限和断路器按预期触发。停止后不得继续产生后台调用或写入。

为级联故障准备演练

同时让共享状态延迟、一个专家超时和消息重复投递，观察系统是否扩大故障。重点核对 owner 是否唯一、写动作是否重复、取消是否传播、人工工单是否包含完整上下文。

端到端评测关注业务结果

多 Agent 之间可以走不同合法路径，最终仍要满足业务状态、权限和成本门槛。评测方法可结合AI Agent 工作流评测清单，同时保留样本级轨迹和首个偏离点。

对交接单独评分

指标可以包括目标正确率、交接成功率、必要字段完整率、二次交接率、错误退回率和上下文泄漏事件。一次任务成功不代表所有交接设计合理，低效路径会增加成本和未来故障概率。

比较多 Agent 与单 Agent 基线

使用同一任务集比较成功率、延迟、费用、副作用和人工接管。多 Agent 版本只有在业务结果或风险边界有可验证改善时才值得采用。不能把角色数量、调用次数或轨迹长度当成能力证据。

上线前冻结协作图版本

记录角色定义、允许转移图、工具契约、策略、模型、状态结构和测试集版本。生产制品必须能对应这份记录。发布流程与回滚证据可参照企业官网发布流水线清单。

灰度先开放低风险任务

先让多 Agent 处理只读查询、内部草稿和测试对象，再逐步开放写动作。灰度看板关注路由变化、交接失败、共享状态冲突和成本。高影响执行器继续保留人工批准。

回滚要覆盖图与状态结构

回退模型版本还不够。新增 Agent、交接字段和状态迁移可能让旧代码无法读取在途任务。回滚方案要说明如何处理新旧任务、队列消息、owner 和未完成审批。模型服务回退可参考私有化 AI 模型服务上线清单。

协作日志按安全要求留存

确定日志范围、脱敏、访问权限、保存期限和销毁方式。执行账号不能删除自己的审计记录。详细字段和调查流程可结合企业官网安全日志管理清单。

用一张表完成架构评审

检查面	必须留存的证据	不通过示例
角色	职责、工具、禁止动作、负责人和版本	所有 Agent 共用高权限工具
编排	任务 owner、转移图、决定者和预算	模型可跳转任意目标
交接	结构载荷、原因码、接收确认和幂等键	交接后无人负责或重复接收
状态	权威来源、字段权限、版本和保留期	旧摘要覆盖最新业务状态
身份权限	用户、Agent、执行器、受众和授权记录	权限随交接自动扩大
故障审计	循环、取消、断路、补偿和完整 trace	主任务停止后分支继续写入

凯乐丰项目如何落地多 Agent 协作

凯乐丰的私有化 AI 方案可以从任务边界、角色权限和现有系统接口入手，判断单 Agent、管理模式或交接模式哪一种更合适。企业若还在规划官网、外贸独立站、SEO/GEO 与私有化 AI 的整体关系，可查看凯乐丰解决方案。需要按真实业务流程评估协作图，可通过凯乐丰联系页面提供场景与系统概况。

最终设计结论怎么写

架构结论应列出为何需要多个 Agent、每个角色的责任、任务 owner、允许转移图、共享状态权威来源、逐角色权限、预算和人工入口。还要注明尚未开放的动作、已验证场景和回滚条件。系统可以在限定任务中稳定协作，不能据此宣称它能自主处理所有业务。