组织共享一个 agent，先别急着融合

周一早会前，同事在群里 @ 了一个内部 agent，让它同时看合同条款、查仓库 PR、估迁移成本。它给了三条建议。我第一反应不是惊艳，是后背发凉：一个 agent 被三方共用，上下文到底归谁？如果它刚才读到的合同条款，下一秒被研发问 PR 时带出来，这个泄漏算谁的？

Show HN 的 Concorde 想做组织级共享 agent。README 把 shared agent 定义成同时服务多方的 AI agent。版本也诚实，0.1.0，public API 没定，子路径会重命名，组件也会动。这个状态像早期 IR：东西有了，规则还没长住。

共享 agent，像把多个算子硬塞进一个 kernel

从工程上看，Concorde 这条路线和另一种路线正好相反。

一种是一个组织共享一个 agent。销售、法务、研发、财务都面对同一个入口，能力复用高，调度看起来简单。另一种是 Polynoia AgentHub、agentGroup、Agent-Staff 这类：每个团队、每个角色都有自己的 agent，或者至少各自有边界。前者像把多个算子融合进一个 kernel，省启动开销；后者像分块调度，局部干净，全局靠编排。

融合不是错。我在昇腾910B上跑过一阵子算子融合，确实能省掉中间 tensor 的反复读写。但前提是 shape、dtype、内存布局、寄存器压力都能算清楚。共享 agent 接的是自然语言、工具调用、组织权限、审计责任。这些东西不像 fp16 tensor 那样规整。

所以真正的瓶颈不是模型带宽，是状态带宽。一个 agent 同时服务多个 party，每个 party 都有数据、权限、历史对话、工具副作用。状态一乱，后面全是补丁。共享入口还带来另一个问题：模型可以共享，状态不能随便共享。很多团队会把 memory 当成缓存，把 history 当成日志，但组织 agent 里，history 可能已经是证据。说白了，你到底是融合了能力，还是只融合了入口。

能不能信，取决于有没有证据链

我前几天写过一篇智能体的每一步都要留证据。现在看 Concorde，还是那个判断：智能体可信度不取决于它多会回答，取决于能不能重放执行过程。

共享 agent 更麻烦。单人 agent 出错，顶多自己背锅。组织共享 agent 出错，可能把 A 部门的上下文带进 B 部门的结论，还可能触发 C 部门的工具。这个风险不能靠 prompt 里一句“请注意保密”解决。

A shared agent is an AI agent that serves several parties at once.

这句话漂亮，工程上很硬。Several parties 至少带来几个问题：

• 租户隔离：上下文是否命名空间隔离，还是共用 memory？
• 权限继承：agent 能不能代表用户调用工具，还是只能代表组织？
• 副作用控制：改配置、提 PR、发消息，有没有人工审批？
• 可审计性：执行链能不能重放，工具参数能不能留存？
• 成本归因：谁用了多少 token，能不能分账？

这些问题没解决之前，把它叫“组织共享 agent”更像产品命名，不是运行时定义。

0.1.0 不是问题，API 没定才是问题

很多人看到 0.1.0 会皱眉。版本低不是原罪。我们做编译器也常从一堆不稳定 pass 开始。真正麻烦的是 public API not settled。子路径会重命名，组件会动，意味着调用方现在接进去，下周可能全要改。

如果只做概念验证，这很合理。它让你快速试“一个 agent 服务多部门”是不是伪需求。但如果准备进生产，我会先停。生产系统需要边界，尤其是权限边界和状态边界。Concorde 现在更像给了你一组积木，还没给你验收清单。能不能落地，要看它把共享边界做成产品特性，还是留给用户自己补。

我这边更关心它有没有类似 IR 的东西。不是模型中间层，而是组织动作的中间表示：哪个用户、哪个租户、哪个工具、哪个资源、哪个审批状态、哪个证据快照。没有这个，共享 agent 就是一个带权限幻觉的聊天壳。有了这个，它才有机会变成可运行、可审计、可回放的组织执行体。

当然，也可能我理解偏了。素材里还有 Concord、Agent Mesh 这些类似名字，说明方向很热。热归热，落到公司里，大家最先问的还是：它能不能不越权。

共享 agent 的核心不是把模型接成一个，而是把组织权限和证据链编译进运行时。

---

📌 本文编译自 Hacker News，原文：https://github.com/shutter-network/concorde

版权归原作者所有，本文为基于公开报道的编译与独立分析。