给公司做一套 Agent Swarm 平台：底座选型、分层设计与路线图

结论先说

底座选 CopilotKit 的 OpenBot，但把它当"控制面骨架"，不是当产品直接用。

理由只有一条：你要的东西里，60% 的难点不是 Agent，而是治理——多人、SSO、最小授权、审计、隔离、审批、可回滚。三个候选里，只有它把这 60% 做成了代码。

另外两个不是白看：nightly 的队列/车位/steer/能力协商、Orkas 的上下文压缩预算与执行计划，都是可以直接照抄的设计，只是别抄代码。

一、先纠正一个前提：这不是"一个 Swarm"

产品、研发、测试、运维、BI、数仓、管理层、驾驶舱——这八块的风险等级差 10 倍。把它们塞进一个"Swarm"里，是这类项目最常见的死法。

正确的形状是：一个控制面 + 多个执行面 + 四种执行模式。

四种执行模式，按成本从低到高，能用低的就别升级

规矩：上一级失败两次，才允许升级到下一级。多 Agent 的典型失败是"三个 Agent 互相确认同一个错误"，而不是"不够聪明"。

二、平台分层

接入层   Web / 桌面 / IM(飞书·Teams·Slack) / API / 定时
   │
控制面   Identity(SSO·SCIM) → 任务编排 → 策略网关 → 审计 → 注册中心(Agent/Skill/Tool 版本)
   │
执行面   Agent Runtime(AG-UI endpoint)  │  Sandbox(容器+浏览器+Shell+代码)  │  Connector(MCP/内部 API)
   │
数据面   Postgres(元数据·审计·任务) │ 对象存储(工件) │ 向量库 │ 语义层/只读副本 │ 事件总线
   │
治理面   评测集 · 配额 · 成本 · 告警 · 合规导出

五个必须先定死的东西（定错一个，后面全返工）

1. 身份：三个身份绝不能混

每次工具调用必须同时携带 agent_id + on_behalf_of + initiator。

CopilotKit 的 initiator_kind 字段值得直接照搬，再扩一维：它能回答"我不在的时候，谁用我的名义动了东西"——这是审计和合规唯一真正关心的问题。

2. 网关：所有副作用只有一个入口

不要给 Agent 长期凭证。所有写操作、外部调用、数据库查询都走网关：

解析目标 → 策略求值 → 写审计行 → 才执行 → 失败再写一行

策略用 CEL 或 OPA，默认拒绝、deny 先于 allow、规则写坏也拒绝。策略存 Git，走 code review，和代码同版本发布。

效果分级，审批按级路由：

3. 状态：Agent 不拥有状态

这是 Orkas 和 nightly 都在做的事，照抄即可：任务板是唯一事实源，Agent 只读写任务行。

一条任务必须有：目标、验收条件、输入工件、预算（token/时长/工具调用次数/金额）、权限范围、截止时间。Agent 结束就销毁，状态留在库里。

交接不要用自由文本，用结构化信封：

task:
  goal: "把 checkout 服务的 p99 从 800ms 降到 400ms"
  acceptance:
    - "压测报告显示 p99 < 400ms @ 500rps"
    - "无新增 5xx"
  inputs: [artifact:profile-20261101, repo:checkout@main]
  outputs_expected: [patch, benchmark-report]
  authority: { agent: perf-agent, on_behalf_of: u_1024, scopes: [repo:write, staging:deploy] }
  budget: { tokens: 2M, minutes: 90, tool_calls: 200 }

自由文本交接是 Agent 团队退化成"聊天室"的根本原因。

4. 预算与并发：没有这两个，平台第二天就会失控

• 每任务硬预算，超了直接停，不是告警。
• 每团队月度配额 + 按团队计费。
• 资源租约：一个仓库分支、一张表、一个环境同时只允许一个 Agent 写。nightly 的"车位/租约"就是这个思路。

5. 评测：没有 eval 的 Agent 不许上线

每个 Agent Pack 一套 Golden Set，覆盖：正常、边界、拒绝、注入、越权。上线门禁 = eval 通过 + 安全用例通过 + 成本在预算内。

写操作的 Agent 先跑 影子模式：只产出建议和 diff，不执行；人工采纳率稳定后再开自动。

三、八个域的落地表

跨域 Swarm 只有两条值得做

1. 交付流水线：需求 → 设计 → 开发 → 测试 → 发布 → 观察。事件驱动，每步是人或 Agent，同一条任务线。
2. 事故响应：告警 → 分诊 → 定位 → 修复 → 复盘。运维主导，研发和质量按需加入。

其它"跨部门协作"先别做，收益低、协调成本高。

四、BI / 数仓 / 驾驶舱：这里最容易翻车

绝大多数企业 Agent 项目死在这一块，不是因为模型不行，是因为没有语义层。

四条铁律：

1. Agent 不许裸写 SQL 连生产库。 只能调语义层里注册过的指标和维度。
2. 每个数字必须带血缘：指标 → 模型 → 源表 → 快照时间。答不出血缘的答案一律不展示。
3. 驾驶舱不生成新数字，只解释已有数字。 它的价值是"为什么变了"，不是"再算一个"。
4. 口径变更要版本化，并写进 Agent 的上下文——否则同一问题下个月答案变了，管理层就不再信任它。

技术上：只读副本 + 行级权限 + 查询网关（带扫描量上限）+ 结果缓存。

五、路线图（别一次做完）

每个阶段必须能一键关掉。关不掉的功能不许上线。

六、团队与成本

• 平台组 3–5 人：控制面、网关、评测、SRE。这是长期编制，不是项目组。
• 每个职能配 1 名业务 Owner + 1 名工程师，负责该 Pack 的工具、eval、SLO——Agent 要像微服务一样有 owner。
• 成本三件套：模型路由（规划用强模型，执行用便宜模型）、缓存、批处理；按团队出账单。

粗估：fork CopilotKit + 硬化到内部可用，3–4 人约 3 个月；覆盖八个域，8–12 人 6–9 个月。自研控制面再加 3–6 个月。

七、CopilotKit 这个底座，改哪里

保留：Hono + Postgres 控制面、策略网关 + 审计、agent-computer 容器、supervisor、AG-UI 接入、审批与组件化回复、SSO/SCIM、Helm。

必须改：

1. 线程与记忆：把 Intelligence 抽到 ThreadStore / MemoryStore 接口后面。敏感的（运维、财务、驾驶舱）走自建 Postgres 实现；非敏感的先留 Intelligence。第一天就抽接口，不要等。
2. 容器扩型：现在只有 Chromium + shell。加三种：代码沙箱（devcontainer）、SQL 查询代理、K8s 只读客户端。
3. 组织模型：补部门/团队/项目层级，策略按组织树继承。
4. 评测与发布：它没有 Agent 上线门禁，这块要自建（Git 里的 golden set + CI）。
5. 上游策略：v0.2.0 是 beta。fork 成 vendor 分支，上游只 cherry-pick，别直接跟 main。

八、三个问题会改变上面的设计

1. 部署在哪？ 公有云 / 私有云 / 信创 / 完全离线——决定模型选型和容器运行时（gVisor、Kata、还是只能用 Job）。
2. 数据和会话能不能出内网？ 决定 Intelligence 用托管还是自建，也决定高危域能不能用云模型。
3. 写操作的边界在哪？ 能不能改生产、能不能动钱——决定审批层级和是否永久保留"人在环"。

这三点定了，上面的分层可以细化成可执行的架构文档 + 第一阶段的接口清单。

未做的：没做容量与成本测算（缺任务量和模型价格）；路线图周期是按 3–5 人平台组估的，不是承诺。风险提醒：CopilotKit 版仍是 beta 且自述"模板而非产品"，把它当加速器而不是成品；法务上务必先确认 nightly-labs 的 PolyForm 许可不能用，这是硬约束。