Multi-Agent Architecture 是让多个 AI Agent 朝一个共同目标工作而不互相冲突的结构。它主要是组织问题：谁做什么、每个 Agent 读什么、工作如何在 Agent 之间流动、人在哪里负责。把这四点决定清楚的团队能让工作保持对齐；跳过这些决定的团队会发现每个 Agent 各带一份对任务的不同理解。
Multi-Agent Architecture 成立的条件是：角色清楚、上下文共享、交接可见、有人对结果负责。
快速结论
Multi-Agent Architecture 是让多个 AI Agent 朝一个共同目标工作而不互相冲突的结构，由明确角色、共享上下文、可见交接和人工确认环节四部分组成。当多个 Agent 从同一目标出发工作、且缺少共享记录时工作会发生漂移，团队就需要它。一个协作工作空间可以承载这套架构的协作与验收层：共享上下文、可见交接、经审阅的交付物和人工确认环节。角色、目标和边界仍由团队自己设计。
Multi-Agent Architecture 是什么
Multi-Agent Architecture 是让多个 AI Agent 朝一个共同目标工作而不互相冲突的结构。它定义角色、共享上下文、工作如何在 Agent 之间流转，以及人在哪些节点做决定。架构是工作的组织方式，与团队实际使用的工具相互独立。
架构在开始时回答四个问题：有哪些角色？参与工作的 Agent 共享什么上下文？工作如何从一个 Agent 交给下一个？人在哪里介入？跳过这些问题的团队，最终会得到各自带着不同任务理解的 Agent。
Multi-Agent Architecture 的组成部分
可运行的架构通常由四个部分组成。
角色。 每个 Agent 有明确的职责范围和任务。研究 Agent 收集资料，起草 Agent 写作，审阅 Agent 检查。角色让产出可评估、让失败可定位：团队可以问清是哪个角色漏了什么。
共享上下文。 团队从同一份记录出发：目标、约束、决策、链接和交付物。这份记录让 Agent 不会各自漂移到对问题的不同理解。
交接。 工作通过可见的交接在 Agent 之间流转。任务更换负责人、状态变化、交付物向前推进。交接不可见时，工作会在衔接处丢失。
人工确认环节。 人在关键节点做决定：目标、边界，以及最终交付物的验收。需要人工确认的操作由 Agent 起草动作卡（Action Card）请求，再由有权限的人以本人身份确认并执行。
设计角色与边界
角色是第一个设计决策，好的角色来自工作本身，而不是模板。把交付物实际经过的步骤逐一命名，并为每一步指定负责人。一份研究简报会经过研究、起草和审阅；一条支持工单会经过分流、起草和策略检查。角色就是那些需要不同上下文或不同工具的步骤。
边界把角色限定在各自的范围内。频道成员资格和工具权限由团队配置：每个 Agent 只看到被邀请加入的频道，私有频道仅限成员访问。起草 Agent 不需要研究 Agent 的凭证，分流 Agent 不需要响应频道的写权限。边界是架构与治理交汇的地方：成员关系和权限由团队决定，动作卡为需要人工确认的操作提供确认与执行路径。
两个习惯让角色保持健康。第一，从完成工作所需的最少角色开始，因为每个角色都会增加协调成本。第二，把每个角色的职责范围写成一句话；需要一段话来描述的职责范围，是需要拆分的两个角色。
架构与框架的区别
这个区别值得讲清楚。框架是软件，是一组帮助团队构建和连接 Agent 的库与模式。架构是角色、上下文、交接和监督的组织方式。团队可以只拥有其中一个。
当真正的问题是组织层面的问题时，团队常常会去引入框架。两个一直基于过期上下文工作的 Agent，即使接上框架也仍然如此，因为框架改变的是构建工具，而产出能否复核，取决于架构。
产品选择也处在同一条线上。一个协作工作空间可以承载架构的协作与验收层：共享频道、任务板、交付物和动作卡，团队无需为这些能力自行组装框架。角色、目标和边界仍由团队设计。对于把 Agent 作为工作成员来运行、而不是作为工程项目来管理的团队，工作空间和框架服务于不同层次，可以共存。
常见的协作模式
同样的四个组成部分会组合成几种常见模式。给它们命名是有用的，因为团队能在这几种模式中认出自己的工作形态。
顺序交接。 工作沿一条线推进：研究到起草到审阅，每个阶段等待前一个阶段。这个模式适合阶段清晰、Agent 数量少的工作。共享上下文仍然重要，因为每个阶段都读同一份简报。
并行支线。 多个 Agent 同时处理各自的子任务，最后汇聚到一份交付物。研究和起草并行推进，然后由审阅者合并并检查。这个模式适合互相独立的工作线，用协调换取速度。
协调者角色。 一个 Agent 承担组织工作：拆分目标、派发任务、合并结果，其他 Agent 保持专业化。这个模式看起来像一个小型组织，适合两三个 Agent 无法自行组织的大规模工作。
这些模式都不需要框架。每一种都可以用频道承载共享上下文、任务板承载交接、审阅步骤帮助团队检查质量、发现问题。模式是关于组织的选择，把它放在可见的工作空间结构中运行，就能保持可观察。
实际运行中，团队经常采用混合形态。协调者把简报拆成多条支线，支线并行运行，最后的审阅阶段检查合并后的交付物。命名基础模式有帮助，工作空间的常规结构，即频道、任务板和审阅步骤，就能承载这种混合形态。
如何选择架构
在顺序、并行和协调者模式之间的选择取决于工作结构，三个条件可以定下来。
阶段相互依赖的工作应使用顺序交接，让每个阶段把产出交给下一个阶段。存在可以同时运行的支线的工作应使用并行支线，并在汇聚处设置合并与审阅步骤。需要有人拆分和派发工作的团队应使用协调者角色，并保持其他 Agent 专业化。
常见的错误是按雄心而不是按工作来选择。一个只有两条支线、没有派发需求的团队，从协调者那里得不到好处；阶段强耦合的团队，并行运行也得不到收益。能完成工作的最简架构通常是正确的选择，因为协调成本会随着每个新增的衔接点增长。
工作变化时重新评估选择。每周简报从两条支线增长到五条时，通常需要协调者或合并步骤；支持管线自动化了第一个阶段后，可以回退到更简的形态。架构是团队反复评估的决策，不是固定的设计。
架构在工作空间中如何运行
在工作空间中，架构运行在可见的结构上，而不是图里。团队负责人为目标创建频道，并加入所需的 Agent。团队可以把频道用作共享上下文，把任务板用作交接记录，把交付物用作可审阅的产出；每个任务都有负责人和状态。对于需要人工确认的操作，动作卡提供确认与执行路径。
每周简报是它的缩小版。研究 Agent 把来源资料收集到频道。起草 Agent 把笔记作为任务接手并产出草稿。审阅 Agent 对照简报检查草稿。负责人阅读最终交付物并接受或驳回。架构是整体形态；当团队把工作放在频道、任务板和交付物中运行时，它保持可见。
共享上下文与交接
共享上下文是架构中让 Agent 与共同基准保持一致的部分，交接则是架构最容易断裂的地方。两者都值得仔细看。
记录里放什么。 目标和验收标准、约束和决策、链接和来源、以及交付物。四样齐全的记录让任何 Agent 无需追问就能继续简报的工作。只有消息的记录会让 Agent 从对话中推断简报。
记录如何保持最新。 决策落在频道中，目标变化先更新记录，Agent 在开始前先读记录。团队的规则很简单：如果不在频道里，就不算发生在团队的上下文中。
交接携带什么。 工作本身、当前状态、下一个负责人需要知道什么、以及到目前为止检查了什么。点名这四样的交接消息，让衔接处更容易复核。不带上这四样就移动任务的交接，会把问题一起移动。
交接在哪里失败。 在角色之间的衔接处：前一个负责人认为移交已完成，下一个负责人还没有开始。修复方法是任务上可见的状态变化，以及任何时刻都有具名负责人。
Multi-Agent Architecture 在 Syfo 中如何运行
Syfo 与 Multi-Agent Architecture 的关系
Multi-Agent Architecture 是团队为 AI 工作所做的设计：角色、共享上下文、交接与人工确认环节。
Syfo 是让人和 Agent 共同工作的工作空间，承载团队选择的协作与验收层：频道保存共同简报与决策记录，任务板显示每件任务的负责人与状态，交付物供人打开复核；需要人工确认的操作，由 Agent 起草动作卡请求，由有权限的人以本人身份确认并执行该操作。
这让团队可以在同一工作空间中运行并核验自己的设计：谁做什么、什么被验收、由谁验收的。
Syfo 不是完整架构、编排框架或安全认证平台，也不设计角色、目标、权限、安全控制、运行时编排或业务决策；架构仍由团队设计，Syfo 承载其中的协作与验收层。
这一结构就是 Organizational Agent Harness 描述的协作层：人和 Agent 团队与既有记录系统并行地做共享的组织级工作。以这种形态运行顺序与并行模式的团队，可以自行查看 Syfo 案例页（供读者查阅，不构成效果证明）。
失败模式与可观测性
Multi-Agent Architecture 会在几个可预测的地方失败，每个失败都指向团队可以检查的结构。
上下文漂移。 Agent 从同一份记录出发，然后各自引入自己的来源，进行到一半时对目标产生分歧。修复方法是由团队保持记录最新、Agent 按工作流读取更新的共享频道。
不可见的交接。 工作在 Agent 之间传递，衔接处没有人负责移交。研究到起草之间丢了东西，到审阅时才暴露。修复方法是任务上的具名负责人，以及每个交接处可见的状态变化。
未被观察的失败。 并行 Agent 产生更多产出，更多产出意味着更多内容需要检查。如果审阅步骤跟不上，数量会压过质量。修复方法是增加审阅 Agent，并通过动作卡处理需要人工确认的操作。
非确定性。 同一目标在不同轮次可能产生不同结果。修复方法是记录谁做了什么、什么变了、由谁验收，让团队可以比较各轮结果。
信任与身份。 工作需要具名负责人和可见边界。带 @handle 的具名 Agent 把产出关联到具体负责人，频道成员关系控制每个 Agent 能看到什么，确认与执行记录显示谁确认并执行了哪些操作。没有身份和边界，失败找不到负责人，需要人工确认的操作也没有明确的处理路径。
可观测性让其他修复生效。具名 Agent、共享频道、任务板和确认与执行记录，把架构变成一个人一个月后还能检查的对象。团队让这些结构在工作空间中保持可见，这正是架构不必活在代码里的原因。
韧性设计
Multi-Agent Architecture 应当预期失败并控制失败成本，韧性有三个实践层。
快速失败。 Agent 无法完成自己那部分时，应该尽早说出来，而不是给出自信的猜测。审阅步骤能及时发现问题；尽早发现，比交付物离开团队后再发现成本更低。
重试与恢复。 失败的任务带着原因回到负责人手里，团队能在记录中看到重试。恢复是可见的：任务显示尝试、失败和修复。
有计划的降级。 团队人力不足时，架构应当收缩而不是断裂。团队可以把审阅角色并入一个 Agent、接受更小的范围，并记录更简的形态；团队决定降级形态仍能覆盖什么。提前规划降级形态的团队，能稳定度过繁忙的周期。
韧性既是过程的属性，也是记录的属性。留在记录里的失败会给下一轮提供可检查的依据，这让后续复核更有依据、更易检查。
可观测性实践
可观测性是能回答关于任何工作的四个问题的能力：目标是什么、谁做了什么、什么变了、由谁验收。当工作运行在可见的结构中时，团队可以用记录回答这些问题。
任务板显示每一步的负责人和状态。交付物显示产出了什么、由哪个 Agent 产出。确认与执行记录显示谁在什么时候确认并执行了哪些操作。频道历史显示工作背后的决策。要回答这四个问题，工作必须在可见的结构中进行。
习惯和结构同样重要。按工作的节奏查看任务板，就最近一份交付物问这四个问题，答案缺失时跟进。经常提问的团队能在问题还小的时候就发现它，并建立起问题所依赖的记录。
安全边界
Multi-Agent Architecture 中的安全主要取决于边界：Agent 是谁、能看到什么、能触达什么，以及哪些操作必须等待有权限的人确认。
身份优先。带 @handle 的具名 Agent 把每个动作关联到行为者：失败有负责人，交付物有产出者。频道成员关系随后控制可达范围：Agent 只看到被邀请加入的频道，私有频道仅限成员访问，规则与人类成员相同。工具权限控制 Agent 能触达什么；需要人工确认的操作通过动作卡发起确认，由有权限的人以本人身份确认并执行。
平台与团队的边界应当明确。工作空间提供机制：由团队配置的成员与可见性边界、动作卡流程和共享记录。团队在这些机制之上作出决定：哪些操作需要人工确认、由谁确认并执行，以及如何理解团队的风险偏好。工作空间不认证合规性，也不提供安全保证，团队应以此为准评估相关声明。
什么时候架构是过度设计
Multi-Agent Architecture 有协调成本，协调成本必须值得付出。
一个 Agent 加一个人就能完成的小工作，从这套结构里得不到收益，协调开销反而拖慢它。严格顺序、只有一条明显路径的工作，用单个 Agent 更简单。一个人的团队做实验时，可以从一个频道加一个 Agent 开始，工作成长时再让架构成长。
一个有用的测试：团队能否用一句话说出这个目标需要的角色？能说清，说明架构已经定义。角色模糊或只有单一工作线，就是缩小规模、在衔接处出现时再加结构的信号。
扩展架构
适合三个 Agent 的架构与适合二十个的架构形态相同，区别在于正式程度，而不是结构。角色从一句话的职责范围变成书面章程。交接从可见的状态变化变成约定的惯例。审阅从一个 Agent 变成带标准的审阅阶段。
增长的信号是具体的。交接失败超过一次，就把那个衔接处正式化。审阅 Agent 漏掉人能发现的问题，就加检查清单。新 Agent 无法从频道学到上下文，记录需要结构化。每个信号都是架构追上工作的过程。
让扩展保持廉价的原则与开始时的原则相同：目标、共享上下文、交接和人工确认环节在工作空间中保持可见。让四个部分可见的团队可以无重设计地成长，因为架构从未藏在代码里。
如何开始
- 选择一份周期性产生的交付物，在频道中写下目标和验收标准。
- 命名团队需要的角色，从能工作的最少数量开始。
- 逐个加入 Agent，每个都有明确的职责范围。
- 通过任务运行工作，让每次交接可见。
- 加入审阅 Agent；需要人工确认时，由 Agent 起草动作卡请求，再由有权限的人以本人身份确认并执行。
让架构从真实工作中显现。目标、共享上下文、交接和人工确认环节就是架构，它们应保持在团队使用的工作空间结构中可见，而不是锁在设计文档里。
第一周建立节奏。完整走完一份交付物的流程，观察工作在哪里停滞，修复衔接处后再添加下一个 Agent。一天结束时查看任务板并问四个问题：目标是什么、谁做了什么、什么变了、由谁验收，直到答案不费力就能得出。当团队能从记录里回答这些问题、而不是到处问人时，架构就在起作用。
FAQ
什么是 Multi-Agent Architecture？
Multi-Agent Architecture 是让多个 AI Agent 朝一个共同目标工作而不互相冲突的结构。它定义角色、共享上下文、交接，以及人在哪些节点做决定。
Multi-Agent Architecture 有哪些组成部分？
角色、共享上下文、可见交接和人工确认环节。角色让产出可评估，共享上下文让 Agent 保持对齐，交接让工作不丢失，人工确认环节提供问责。
需要多智能体框架吗？
框架是帮助团队构建和连接 Agent 的软件。这套架构的协作与验收层，即角色、上下文、交接和监督，可以由带频道、任务板和动作卡的协作工作空间承载。是否需要框架取决于团队的运行时编排与集成需求；协作工作空间不替代这些需求。
架构和编排有什么区别？
编排是协调工作的运行时流动：谁在何时运行、什么触发什么。架构是角色、上下文、交接和监督的更大范围的组织。编排可以是架构的一部分，架构也可以几乎不依赖编排。
常见的 Multi-Agent Architecture 模式有哪些？
常见模式有顺序交接（工作沿一条线经过各阶段）、并行支线（多个 Agent 并排工作后汇聚），以及协调者角色（一个 Agent 负责组织，其他 Agent 保持专业）。团队通常能在三者中认出自己的工作。
什么时候 Multi-Agent Architecture 是过度设计？
当工作规模小、严格顺序或由一个人负责时。从一个频道加一个 Agent 开始，等工作成长到需要时再添加角色、交接和确认环节。
如何选择 Multi-Agent Architecture？
让模式匹配工作。顺序阶段用顺序交接，独立支线用并行支线，大规模且需要派发的团队用协调者角色。能完成工作的最简架构通常是正确的选择。
什么让 Multi-Agent Architecture 有韧性？
失败可见且廉价：Agent 尽早报告问题，失败的任务带着原因回到负责人手中，团队在人力不足时能运行降级形态。记录保留这些尝试、失败和修复，供日后查看。
什么时候 Multi-Agent Architecture 值得投入
当角色清晰到可以逐一说明、共享上下文持续准确、交接经过多次运行仍保持完整时，Multi-Agent Architecture 才值得投入。从一份周期性交付物开始，运行能完成工作的最小 Agent 组合，让频道、任务板和动作卡承载结构。这样的 Multi-Agent Architecture 可以随团队一起成长：工作在日常使用的结构中保持可见，事后可以从记录中复核，始终有人对结果负责。