要点一：角色分工与编排
MOA 的基本结构是一个编排者加若干角色，每个角色有职责、工具与输出格式。角色卡写得越具体，协同越稳定；只写你是某领域专家这类描述，模型只能自由发挥，结果无法复现也无法验收。为什么强调写细？因为这是最常见的返工原因。
要点二：共享状态与消息
角色之间靠消息与共享上下文协作，状态里放什么、放多少，直接决定成本与准确率。常见做法是只传结构化结论与必要原文，不要把全量对话历史塞进每一次调用，否则上下文很快失控。怎么传，要按角色真正需要的判断材料来定。
要点三：路由先确定性
谁来接下一步，可以用规则路由，也可以让模型判断。规则路由可预测、可测试，模型路由灵活但会引入新的失败点。如何取舍？先跑通固定路由，再考虑在少数分支上放开模型判断，而不是一开始就放开。
要点四：成本与延迟放大
多个角色意味着多次调用与更长的上下文，成本与延迟往往成倍上升。并行执行能压缩时延，但汇总环节仍然是串行的。如何估准？上线前要按任务量估算调用次数，否则预算很快会失控，响应变慢也会被业务方投诉。
要点五：适用边界
适合任务可拆成相对独立的子任务、且需要不同工具或不同知识的情况；不适合本来一句话就能答完的问题。拆得太细会带来协调开销，反而不如单 Agent 稳定，这一点在对比试点时最容易被忽略，边界要提前说清。
适用与不适用
适合谁
- 任务可拆分、子任务需要不同工具的企业
- 已有单 Agent 试点、准备扩展能力的团队
- 能接受更高调用成本换取覆盖面的业务
不适合谁
- 问题简单、单次调用即可完成的场景
- 对延迟极敏感、无法接受多轮调用的流程
典型场景
某咨询团队做行业资料汇总：检索角色负责找公开信息，分析角色按统一模板提炼要点，审校角色核对数字与出处，编排者合并成初稿交项目经理复核。四个角色各有输出格式，任何一步失败都会退回重跑，不会带着错误继续往下走。
可执行步骤
- 把任务拆成三到五个职责清晰、可以独立验收的子任务，并写明各自的产出
- 为每个角色写清输入字段、可用工具、输出格式，以及失败时怎么处理
- 先用固定路由把整条流程串起来，评测跑通之后再考虑局部动态分配
- 为共享上下文设体积上限，每个角色只接收结论摘要与必要的原文片段
- 按真实任务量估算调用次数与响应延迟，再判断这条路是否值得走下去
常见坑
- 为了显得先进而堆角色，最后没人说得清每个角色负责什么、产出什么，方案无法冻结与验收。
- 让模型自由决定下一步交给谁，流程每次运行的路径都不同，出了问题也无法复现与定位。
- 把全部对话历史原样传给每个角色，成本翻倍，关键信息反而被无关内容淹没，模型开始跑偏。
- 没有失败重试与终止条件，一个角色卡住后整条链路都会空转，直到额度耗尽才被发现并停机。
自检与验收清单
- 每个角色是否都有明确的输入字段与输出格式
- 路由是否可预测、可测试，并且能按任务回放
- 共享上下文是否设置了明确且可调整的体积上限
- 是否为每个环节设了重试、最大轮次与终止条件
- 调用成本与响应延迟是否都在上线之前估算过
常见问题
MOA 和单 Agent 怎么选？
先看任务能否拆成独立子任务。能拆且子任务需要不同工具或知识时，MOA 的收益才明显；否则单 Agent 加好工具与清晰流程，往往更稳、更便宜，也更容易维护，不必一步到位，等流程稳定后再拆角色。
MOA 一定比单 Agent 准吗？
不一定。多角色能互相校验，也会互相传递错误。关键在汇总规则与校验环节，如果没有明确的合并与冲突处理方式，角色多反而会放大偏差，让人误以为系统很忙，实际产出却没有提升。
MOA 与工作流引擎有什么区别？
工作流引擎按预设路径执行，MOA 让角色在路径内自主决定内容与部分步骤。实践中常把两者结合：用工作流确保主干可控，用 MOA 处理需要理解与判断的环节，边界清晰也便于排障。