本文整理自两张架构总览图：一张描述多人多 Super-agent 协作平台的总体分层，一张描述这套架构在企业内的落地形态——公司级中央大脑。它是一份面向工程实践的架构梳理，而非产品功能说明；文中出现的组件与协议，都是当前设计口径下的取舍，而非终态。
1. 问题的起点
单个 Agent 能不能把一件事做好，已经不是最容易卡住我们的问题。真正开始变难的是另一件事：当多个人和多个 Agent 同时在一个组织里干活时，协作本身的成本迅速上升。
谁是谁、谁能做什么、一个任务现在到了哪一步、该由谁推进、由谁验收——这些信息如果散落在聊天记录里，系统就没有任何可以依赖的确定性。把几个 Bot 拉进群里看着像协作，实际上是消息的堆积：重复接单、上下文互相污染、出了问题无法追溯。
所以我们认为，这类平台不应该被定义成「多个 Bot 加聊天」，而应该是让人、Agent、团队以统一身份、统一消息、统一状态机、按权限自主协作的事件驱动操作系统。这句话后面所有的分层，都是在为它提供服务。
2. 统一主体：人、Agent、团队对等
整个架构的地基只有一件事：把所有参与者都当作对等主体。图中列了八类实体——自然人、审批人、个人 Super-agent、团队级 Agent、专项安全 Agent、运维 Agent、可注册的技能 Worker、跨组织的外部 Agent——但它们共用同一套身份体系：每个主体都有一张 AgentCard / DID，身份、能力、权限的表述方式完全同构。
主体类型只分三种：person、agent、team，执行侧再按 worker 细分。这样一来，「人把任务派给 Agent」和「Agent 把任务派给另一个 Agent」，在协议层就是同一件事。
围绕身份，平台还提供了四个能力：
- 能力发现：按 capability、scope、SLA、价格检索可委托的对象，而不是靠人记住某个 Bot 叫什么。
- 最小权限：RBAC/ABAC 叠加临时凭据，敏感动作先授权、后执行。
- 签名代理：私钥不出 HSM，由代理为委派、回执、审批签发可验证的
ed25519签名，并配合nonce防重放。 - 凭据代理与审计溯源：上下文里只留引用、不留密钥明文；全链路
trace_id+ 签名 + 不可篡改日志。
由此得到一条贯穿全文的原则：主体身份决定「能做什么」，任务状态记录「做了什么」，签名证明「谁做的」。三者缺一，协作就无法被信任。
3. 六层主链路
图 1 是这套平台的总体分层：接入、身份、事件、编排、运行时、执行六层构成主链路，控制与兜底作为贯穿所有层的控制面存在。下面按层说明每一层在解决什么问题。
图 1 · 多人多 Super-agent 协作平台总体架构：六层主链路加控制面，右侧为贯穿各层的信任、触达与状态设施
3.1 接入层
人从熟悉的地方进入：IM、邮件、GitHub、工作台、Web，以及面向系统的 Webhook 与 API。接入层不承载业务逻辑，只负责把不同信道的事件规整成同一种输入，使得后续所有层不必关心「这条消息是从哪来的」。
3.2 身份层
身份层是第 2 节那套主体模型的落地：统一主体目录、能力发现、最小权限 IAM、签名代理、凭据代理、审计溯源。它回答的是「谁在请求、它能做什么、这次授权到什么范围、事后凭什么追责」。
3.3 事件层
事件层是整套系统的中枢。这里有一个明确的取舍：消息即唯一的协作事实源。Agent 的状态、进度、产物都不靠口头约定，而是靠事件总线上的消息来承载，支持 pub/sub、点对点、广播与持久化重放（物理实现可以是 NATS/Kafka，按 thread / task 分区）。
消息走统一信封：from/to/type/thread/task/ttl/sig，结构化而非自由文本。之所以强调结构化，是因为自由文本无法被程序稳定地路由、去重和审计。
事件进入系统后先过两道过滤，这一设计直接借自计算机系统的 Fast Path / Slow Path 思路：程序层作为 Fast Path，用确定性规则削掉大部分噪音；语义层作为 Slow Path，只把少量候选事件交给模型判断是否需要行动。订阅模型分四类：Thread、Task、Capability、Role。
在触达上，平台按主体状态分档：在线走 SSE/WebSocket，离线走持久化重放，需要人处理时按 IM 卡片、邮件、工作台分别适配，高优事件则逐级升级。
3.4 编排层
编排层维护全局任务注册表，也就是「任务实体 + 状态机 + 乐观锁」的组合：谁认领了哪个任务、什么时候心跳、超时如何释放，都由注册表统一裁决。委派与升级提供 delegate、reassign、help、escalate 四种动作，高风险的状态跃迁必须经过人工闸门；意见冲突走 peer review 加人工仲裁。
在跨域场景下，编排层采用本地 Router 联邦的方式：按 scope 跨域寻址，域间只交换 AgentCard、状态与摘要，不复制底层上下文。这条边界是后面 A2A 协议和数据隔离的前提。
3.5 运行时层
运行时层里，每个 Super-agent 都是平台上的一个「运行时租户」，复用同一套协议与状态机。Super-agent A 维护全局上下文、不亲自执行重任务；Super-agent B 负责跨域协作，边界隔离、产物只传引用；Worker 池按 code / review / test / data 拆分，上下文隔离、弹性并发。
3.6 执行层
执行层是真正碰到外部世界的地方，因此权限收敛得最紧：BYOM Daemon 跑在开发机或私有环境，只执行命令并返回结果、不保存会话；沙箱与 MCP 工具对接数据库、API、CI，遵循最小权限、网络出口可控；存算分离让执行 Loop 保持无状态，状态放进 Session DB，从而支持跨设备续跑；产物只存 artifacts 指针，交付物与上下文彼此分离。
3.7 控制面
控制面不参与主链路的功能，但决定了系统能不能被信任：Watchdog 联邦巡检进程、进展、跑偏、越权与提示注入；人工闸门为写操作、跨域、高信任动作提供可拦截、可签批的通道；可观测性负责 trace/metric/log 与行为评分；策略引擎把权限、限流、预算、SLA、隐私规则统一执行。
这一层的存在意味着一个前提：平台默认 Agent 会出错。与其假设模型永远正确，不如假设它可能跑偏，然后把发现与拦截做成基础设施。
4. 任务状态机：把协作语义固定下来
跨主体协作最容易失控的地方，是每个人对「进行到哪一步」的理解不一样。解法是把生命周期收敛成有限状态机（图示统计为 11 个生命周期状态，核心状态如下）：
PROPOSED提议任务，由 Router 转为正式入队；SUBMITTED正式入队，等待认领，支持幂等去重；CLAIMED已被主体认领，用乐观锁处理并发，冲突返回409；WORKING执行中，周期心跳续约，可转为等待补充；INPUT_REQUIRED等待人或 Agent 补充，触发 P1 推送与人工闸门；REVIEWING复核中，走 peer review 或人审批；COMPLETED完成，回写 artifacts 与评分；FAILED失败，按策略重试或终止；CANCELLED取消，但保留审计与 checkpoint。
状态机的价值不在于状态多，而在于它让所有主体对同一件事使用同一套词汇。人看到的是「等待审批」，Agent 看到的是 REVIEWING，审计看到的是完整的状态跃迁记录——三者指向同一段历史。
5. 推送 QoS：区分「人」和「Agent」的触达需求
把事件推给人，和把事件推给 Agent，是两种完全不同的工程问题。平台按优先级把消息分成四档：P0 阻断类走强提醒，P1 决策类要求即时，P2 进度类做聚合，P3 观察类按需拉取。
在这个分级之上，两类主体的策略必须分开设计：
- 人：需要防打扰窗口、聚合摘要、可逆操作，核心目标是避免消息轰炸；
- Agent：需要无打扰窗口、SSE 长连叠加 webhook 与背压，核心目标是保证吞吐与重试；
- 离线：事件持久化，重连后按
last_offset重放，语义为 at-least-once； - 升级：P0/P1 未确认时自动升级至值班人或上级 Agent。
at-least-once 意味着消费端必须幂等。这不是实现细节，而是把「重放」当成常态之后，协议层必须提前答应的条件。
6. A2A 扩展：只交换必要事实
当协作跨出单个 Super-agent 的边界，最危险的做法是把整个上下文一起搬过去。平台的 A2A 协议扩展只交换必要事实，字段被刻意限制得很窄：
from / to主体寻址，配合 AgentCard 校验与trust_tier；type消息语义：delegate / status / help / escalate / notify / question；task_id任务状态机键，幂等且全局唯一；thread_id连续上下文，作为订阅与召回依据；scope权限边界，越界一律拒绝；sig / nonce防伪造与重放，HSM 签名、短期有效；artifact_ref产物指针，不复制上下文，只传引用。
跨信任域时再叠加四层约束：用 OIDC/SAML 接入企业身份源做身份联邦，把外部主体映射为租户内的 AgentCard；跨域只暴露 capability/scope/SLA，不暴露内部实现与记忆；私钥驻留 HSM，由签名代理签发短时效委托凭证与回执；跨域消息默认不可信，低 trust_tier 走语义隔离与强过滤。敏感数据不出域，必要时走脱敏摘要或联邦任务。
7. 技能市场与结算：让生产力可交易
如果 Agent 的能力可以被发现、被委派，那么它自然也可以被定价。平台把这条链路拆成五个环节：注册（能力/价格/SLA）、发现（匹配与报价）、撮合（委托/签约）、执行（状态与验收）、结算（计量/分成/发票）。
平台在其中承担的是裁判角色：定价上支持固定价、按成功结果、按消耗分层，并允许试用与阶梯折扣；计量颗粒度细到模型 token、工具调用、工时、重试次数与外部资源；用 escrow 或预付额度做担保，失败按 SLA 退款或补偿；结算负责平台抽成、技能方分成、跨境支付与合规留痕；评价则把完成率、回滚率、升级率、SLA 达成率反哺回推荐。
这一步能不能做成，取决于前三层是否干净：身份不可伪造、事件可追溯、状态机没有歧义。否则计量的争议会淹没整个市场。
8. 落地顺序：先把协作跑通
这样一套架构不可能一次建成。我们倾向于按依赖关系推进五个阶段：
- 协议地基：统一信封 + AgentCard + 任务状态机 + 事件总线；
- 协作闭环：人↔Agent 委派、Worker 并发、SSE 推送、人工审批；
- 多 Agent 联邦：跨域寻址、能力发现、摘要交换、冲突仲裁；
- 安全控制：IAM、签名代理、Watchdog、审计与策略引擎；
- 市场结算：技能注册、撮合、计量、担保、分成与评价体系。
两条原则贯穿其中：先中心化 Coordinator，跑通协作再分片；先「能审计」，再谈「完全自治」。前者避免在协议还没稳定时就被分布式复杂度拖垮，后者避免自治能力先于可观测性上线。
9. 企业内落地：公司级中央大脑
图 2 是同一套思路在某个具体组织里的投影：一个对接全公司业务知识的中央大脑。它的核心原则是最小权限、零信任、部门数据隔离、全链路审计——换句话说，先回答「谁可以问什么」，再回答「能回答多好」。
图 2 · 公司级中央大脑整体架构：接入层 → 安全网关 → 中央 Router → 部门代理 → 知识中枢 → 执行环境，控制面贯穿全程
9.1 接入层与安全网关
入口有四个：Web 控制台、IM/飞书/企微、API/SDK、邮件/工单。全部请求统一汇聚，经过 TLS 加密、速率限制与 DDoS 防护后进入安全网关。安全网关是整套设计的重心，它包含三件事：统一身份认证（SSO / LDAP / OAuth2，人、Agent、服务统一身份，叠加 MFA 与会话令牌生命周期管理）、细粒度权限引擎（部门级、项目级、字段级，ABAC 与动态策略）、以及安全审查与审计（提示词防火墙、DLP、全链路留痕）。
通过校验之后，系统并不只是放行，而是把权限上下文和脱敏规则一起注入到后续链路。这一点很关键：权限必须随任务流动，而不是在入口检查一次就结束。
9.2 中央大脑：企业级 Super-agent Router
中央大脑承担的是第 3.4 节里 Router 的角色，但多了企业语境下的两件事：一是意图理解与任务规划，把自然语言解析成跨部门需求，再拆成子任务分配给具体执行主体；二是权限感知路由，根据请求者权限决定它可以访问哪些部门 Agent、哪些知识域和哪些工具。此外它还持有全局上下文、跨部门编排、批处理 Trigger 与安全策略执行等职责。
9.3 部门代理层
部门侧各自是一个独立部署的 Super-agent，拥有自己的 Router 与 Worker 池。研发关注代码库、CI/CD、技术文档，权限隔离落在代码层，部署前设审批闸门；HR 处理人事档案、考勤、绩效，严格字段级加密、仅 HR 与本人可访问、敏感操作人工确认；财务处理报销、预算、合同，金额权限分级、审批流强制介入、审计日志不可篡改；销售与客服处理 CRM、客户数据与工单，客户数据脱敏、沟通记录归档、合规话术检查。
它们之间不共享底层上下文，跨部门的信息交换只经过中央 Router，以脱敏摘要或引用指针的形式进行。
9.4 知识中枢
知识中枢由三部分组成：企业知识图谱（业务实体关系、组织架构、流程定义，带权限标注与版本管理）、带权限的 RAG 引擎（向量检索 + 权限过滤 + 语义重排，检索前过滤无权文档，检索后对结果脱敏，跨库检索需授权）、以及业务架构元数据（系统拓扑、接口定义、数据流图）。
把权限过滤放在检索之前而不是之后，是一个容易被忽略但必须坚持的顺序：先缩小可见范围，再排序相关性，否则「检索到了但没给你看」本身就是一次信息泄露。
9.5 执行环境与控制面
执行环境通过 MCP 连接四类系统：内部系统（HRMS、ERP、OA、审批流）、代码与 DevOps（GitLab、Jenkins、K8s、监控）、外部 SaaS（CRM、邮件、日历、会议）、数据平台（数据仓库、BI、分析引擎）。控制面则由三块组成：Watchdog 联邦负责进程存活、任务进展与越权行为检测，异常行为自动阻断、提示词漂移检测、安全事件实时告警；安全审计与合规负责全量日志、行为溯源与合规报告；成本与用量监控负责 Token 消耗、调用频次、部门分摊与配额管理。
9.6 安全设计要点
- 纵深防御：接入层（TLS）→ 身份层（IAM）→ 权限层（RBAC/ABAC）→ 内容层（注入检测/DLP）→ 审计层（全链路日志）；
- 权限传递：用户权限令牌随任务下发，每个部门 Agent 执行前二次校验，确保不越权；
- 数据隔离：部门间不共享底层上下文，仅通过中央 Router 交换脱敏摘要或引用指针；
- 人工闸门：涉及敏感操作（删库、发薪、合同签署）必须人工确认，Agent 没有最终执行权；
- 可观测性：所有 Agent 行为可审计、可追溯、可回滚，Watchdog 持续监控异常。
10. 结语
两张图其实在回答两个不同的问题。图 1 回答「多个主体怎么协作」：靠统一身份、事件总线、状态机和控制面，把协作从聊天记录里剥离出来，变成可验证的协议。图 2 回答「这套东西怎么在企业里活下来」：靠安全网关、权限感知路由、带权限的检索和部门隔离，把「能做事」约束在「被允许做的事」之内。
几张图之间反复出现的是同一组不变式：主体统一、消息是唯一事实源、状态机约束语义、最小权限、全程可审计。模型能力会继续变化，具体组件的选型也会换，但这几条不变式决定了系统在多主体规模下还能不能被信任。
我们更愿意把这套架构理解成一个方向而非一份定稿：先把协作跑通、把审计做实，再逐步放开自治的边界。真正限制生产力的，往往不是模型能不能做，而是组织是否敢于把权限交出去——而权限能交出去的前提，是每一步都留得下痕迹。
说明：本文由两张架构图整理而成，图 1 为「多人多 Super-agent 协作平台总体架构」，图 2 为「公司级中央大脑整体架构」。资料与规范口径截至 2026-10-31；代理签名的法律效力、跨境支付、税务与具体费率须按实际法域另行核验。
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 1056615746@qq.com
