- 让一个 AI 包办所有事，就像让一名员工身兼五个岗位。一旦出了错，您根本找不到是哪里出的问题。
- 如果拆成多个 AI，就要有一个“主管”负责分派任务、汇总结果，还要有一张交接单，写清楚什么东西交给谁。不能让各个 AI 自己聊着把事情定下来。
- 衡量标准是工作有没有完整地交到客户手上，AI 的数量说明不了什么。如果拆分之后既没有更安全，也没有更容易检查，那就不必拆。
传统网站和应用做不到的地方
想象一名员工要同时接客户电话、做报价单、查库存、审核工作，还要批折扣。事情少的时候他也许应付得来，可一旦出了错，您很难查出是哪一步出了问题；也没人敢改他的工作方法，因为动一处就会牵动全部。一个 AI 包揽所有事务，遇到的问题一模一样。
一个包揽所有事务的 AI 智能体（AI Agent），提示词（Prompt）会变得很庞大，难以审查，能调用的工具也远超所需。可是拆成多个智能体却没有编排器（Orchestrator），又会产生重复的答案，结果也没人负责。
企业让一个智能体同时读文件、做计划、对接其他系统、检查质量、审批工作，上下文就会越来越长，权限越放越宽，结果出错时也很难找到原因。团队可能不断往提示词里加内容，直到谁也不敢再改，因为一条指令会影响好几项职能的表现。
多智能体平台（Multi-agent Platform）只在职责、工具、数据或评估方式确实不同的时候才拆分角色。每个智能体只接手有限的任务，按约定（Contract）把输出交给下一个智能体，就像一支由协调员、分析员、执行人员和审核人员组成的团队，最终结果仍然由人负责。
| 传统模式 | 新一代 AI 产品模式 |
|---|---|
| 一个聊天机器人回答所有部门的问题，或者几个机器人各自为政 | 主管智能体（Manager Agent）拆分工作，按职责把专家智能体当作工具调用，或者通过交接把工作转过去，然后汇总结果、检查护栏（Guardrail），并记录每一步的追踪信息（Trace） |
多个智能体之间要通过任务状态（Task State）和程序可以校验的约定相互衔接，随意来回发消息是行不通的。工具网关（Tool Gateway）检查每个角色的权限，统一的追踪记录则让团队看到每项输出经过了哪些智能体、用到了哪些数据。
企业可以用上的新能力
解决办法是像组建真正的团队一样安排 AI：有人做调研，有人做计划，有人调取数据，有人执行，有人审核，再由一位组长接下任务、分派工作、汇总结果。作为企业主，您应该在屏幕上看到：工作进行到哪里了，现在在谁手上，数据从哪里来，哪些地方在等您审批。只有一个聊天框、把一切都藏在背后的界面，这些都看不到。
项目形态
平台由编排器接收目标，拆成任务，再分给调研、规划、数据、运营或审核等专门的智能体。用户可以看到计划、状态、数据来源和待审批的环节，整个工作不应藏在一个对话界面后面。
主要功能
背后的技术
写给开发团队 · 系统架构
系统需要 Orchestration Layer、State Store、Event/Job Queue、Tool/API Gateway、Identity、Policy 和 Observability。各个 Agent 可以按任务使用不同的模型，但每项 Output 在传给下一步之前都必须通过 Schema 校验和 Evaluation。Agent 之间如果只靠没有 Contract 的零散消息沟通，系统就很难排查，也很难恢复。
好处与合适的时机
拆分角色便于限制权限、逐个部分测试，替换某一个智能体也不会牵动全局。这种做法适合需要不同知识或不同系统的多步骤工作；一条工作流就能搞定的简短任务并不适合，因为增加的复杂度、成本和交接时间可能超过收益。
- 专家智能体（Specialist Agent），知识和工具都限定在自己的角色范围内
- 主管式编排（Manager Orchestration），汇总结果并对最终答案负责
- 交接机制，在合适的时候让专家智能体接手对话
- 追踪与评测，查出哪个智能体在哪一步做错了决定
模拟案例
实际使用场景
最容易想象的例子，是那些现在要在好几个部门之间转一圈才能办完的工作，比如给大客户准备报价方案：要有人看需求，有人翻找以往的资料，有人算价格，还要有人在发出前检查。
一项新产品上市的需求，分给市场调研智能体、内容智能体和运营智能体去做，由主管智能体汇总计划、检查依赖关系，并把预算问题交给人审批。没有哪个智能体有权使用所有系统。
在一个准备投标文件的模拟案例中，接收智能体（Intake Agent）先整理需求，调研智能体只在经过批准的资料库里检索，方案智能体把需求和公司的能力对应起来，定价工具计算价格，审核智能体检查各项陈述和缺漏，最后再交给有审批权的人。
如果价格数据还没准备好，编排器只暂停这一条分支，其他部分照常进行。审核人员修改某项陈述时，系统会记下这项陈述出自哪个智能体、依据哪个来源、经由哪份约定传过来。团队因此可以直接修正出错的地方，不必猜问题出在模型上还是交接上。
能力最小化智能体（Least-capability Agent）
每个智能体只拿到完成本职工作所需的最少工具和数据。
比起放宽权限，这样出错时损失更小，评测结果也更清楚。
范围、风险与效果评估
最需要提醒的一点是：AI 数量多，本身算不上成绩。拆得越细，交接出错的地方就越多，系统也越慢、越贵。只需要问一个问题：工作有多大比例能一路走到客户手上？如果拆分之后这一点没有改善，就先别拆。
智能体的数量不能当作 KPI。应该衡量的是端到端完成率（End-to-end Completion）、交接失败、人工修正、工具出错、成本和恢复时间，并按最小权限原则限制权限。如果多个智能体只是互相传消息，状态却没人负责，系统的风险反而更高，调试起来也比单个智能体更难。
多智能体会增加延迟、成本和故障点。角色和权限确实不同时再用，别为了让架构看起来新潮而用。
写给开发团队 · 技术指标
应跟踪的指标：End-to-end Success、Handoff Error、Tool Rejection、Cost per Outcome 和 Trace Coverage
- Discover：跟进实际工作，收集常规情况和例外情况的样本
- Assist：让 AI 起草或给出建议，由人保持控制
- Act：测试集通过后，一次只开放一个工具
- Scale：监控、后备方案（Fallback）、成本和负责人都到位后，再扩大范围
如果交接失败率高、延迟越积越多，或者整体状态没人负责，就该减少智能体的数量。合并角色，或者把某些步骤改成结果固定的规则或工具，通常能让系统更好维护，也更可靠。
BUSINESS & PRODUCT READINESS
职责确实不同时才用多个智能体，想让系统显得复杂不算理由
再加一个 AI 之前，先做您招新员工之前会做的事：在纸上写清楚这个岗位负责什么工作、可以用哪些数据、把工作交给谁、由谁检查。写完如果发现两个岗位每一条都一样，说明您并不需要两个岗位。
列一张职责矩阵（Responsibility Matrix）：哪个智能体接收什么输入、使用哪个工具、交出什么样的输出、由谁检查、谁对最终结果负责。如果两个智能体用的数据、工具和标准都一样，也许就没必要分开。多智能体会增加成本和故障点，所以拆分需要有权限、专业分工或评估方面的理由。
设计交接约定（Handoff Contract），写明要传递哪些上下文、哪些内容要删掉、超时时间，以及出错时由谁负责。对每个智能体和端到端流程分别做追踪与评测，并限制并发量和成本。系统应当让人看得到计划，并能叫停影响重大的流程。
职责矩阵要为每个角色写明输入、输出、工具、数据、权限、评测方式和负责人。如果两个智能体用的数据、工具和标准相同，就该问一问是否应该合并成一个。拆分必须真正降低风险，或者让工作更容易检查。
从目前已经由多个角色的专家协作、交接也清楚的流程开始，先让智能体协助其中一两个阶段，配上共享的任务状态和人工审批。等追踪和恢复机制运转正常，再扩大并行程度或自主程度。不要一开始就在一个演示里摆出一大群智能体。
哪个智能体对最终结果负责？
为什么这个智能体需要单独拆出来？
最少需要开放哪些工具权限？
交接失败时由谁接手？
像组建员工团队一样组建智能体团队：职责、权限和负责人都要明确
DNA Maker 先和您开一场流程与职责工作坊，不急着画一堆智能体方框。我们根据谁应该掌控对话和结果，帮您在“主管调用专家工具”（Manager-as-tools）和交接这两种方式之间做选择，并为每个工具规定人工审批点和护栏。
我们会先做出流程原型，展示计划、工具调用、交接和错误，交给流程负责人审查。之后用评测集同时衡量各项子任务和整体结果，证明多个智能体确实比单个智能体做得更好。
DNA Maker 根据客户的真实流程，协助设计智能体的职责划分、交接约定和人工控制。我们会挑出哪些环节该用普通工作流，哪些适合 AI，哪些必须用结果确定的工具，同时设计状态、队列、权限和审计的架构，让一切都能回溯。
开发范围可以涵盖编排器、专家智能体、MCP/API 工具、任务控制台、评测和可观测性（Observability），先从一条业务线和双方商定的一组故障场景做起。如果您的组织有工作每周都要在几个团队之间传递，可以带上实际的工作文件和真实的等待环节来聊。我们会帮您判断适合用多智能体、工作流，还是两者结合。
写给开发团队 · 我们能做的范围
DNA Maker 可以开发 Agent Platform、Orchestrator、Specialist Agent、MCP/API Integration、Permission、Trace、Evaluation 和 Cost/Latency Monitoring，并提供管理后台（Admin），按工作需要开关各个 Tool 和 Agent。
如果您的流程涉及多个角色的专家，每次交接都会丢掉一些上下文，我们可以和您一起绘制智能体职责图（Agent Responsibility Map），并试行一条流程，最终结果仍由人负责。
SOFTWARE ENGINEERING GLOSSARY
软件工程术语表
这组术语讲的是多智能体系统里的协调者、交接、权限和追踪。可以用来检查每个角色是否真有明确的范围和通过标准，还是只是图上多出来的几个名字。
| 术语 | 是什么 | 通俗示例 | 高管应问开发团队的问题 |
|---|---|---|---|
| Orchestrator | 安排智能体工作顺序并汇总结果的控制者。编排器负责计划和整体状态，但不应自己握有全部权限，每个工具仍要针对各自的任务检查权限。 | 主管智能体调用各个专家智能体 | 最终结果由谁负责？ |
| Handoff | 把控制权转给另一个智能体。好的交接会一并传递事实、证据、已经尝试过的做法和转交的原因，让接手的一方能马上做决定。 | 把退款个案转给退款智能体（Refund Agent） | 传递哪些上下文，哪些必须删掉？ |
| Agent as Tool | 让智能体协助完成子任务，控制权仍在主管手里。做法是把专家智能体封装起来，像调用输入输出明确的工具那样调用，减少智能体之间失控的对话。 | 调研智能体把结果交给主管智能体 | 汇总之前，各部分结果怎样检查？ |
| Least Privilege | 只授予必要的最少权限。只开放这项任务、这段时间真正需要的权限，指令出错或数据超出范围使用时，影响就小得多。 | 内容智能体可以读取数据，但不能发邮件 | 角色变化时，会重新审查权限吗？ |
| Tracing | 记录系统一步步的推理顺序和工具调用。好的追踪记录会把输入、模型、提示词、工具、输出、耗时和成本串起来，让团队能查找原因，并编写回归测试（Regression Test）。 | 查看流程在哪一步失败 | 追踪数据怎样保证安全，保存多久？ |
延伸阅读（原始文档）：https://openai.github.io/openai-agents-js/guides/multi-agent/