AgentConnect：开源多智能体协作平台，让 Claude Code、Codex 与团队在 Slack 和 GitHub 里并肩工作

它要解决的问题

AgentConnect 是一个以 Apache-2.0 协议开源的平台，目标是让团队成员和多个 AI 智能体在同一批对话与工作流中协作。项目 README 开篇就自称「Claude Tag 的开源多智能体替代品」，口号是「@ 任何智能体」：无论工作发生在哪里，智能体都与团队以及彼此并肩工作，并在过程中持续学习。

这个定位对应一个越来越明显的痛点。今天的编码智能体大多仍是个人工具，只活在某一个人的终端里。队友看不到它在做什么，无法接手它的会话，无法审阅它的输出，它积累下来的上下文也只留在一台笔记本上。于是每个团队都在重复编写同样的胶水：消息渠道、定时任务、凭证处理、上下文拼接。AgentConnect 的思路，是把这层胶水变成一个平台，而不是让每个团队各写一遍。

核心架构：三个组件，两个平面

根据项目 README 中的架构说明，系统由三个组件组成。 第一个是 Daemon。它负责在守护进程自己持有的 ACP（Agent Client Protocol）连接上运行被分配的智能体，管理工作区与会话状态，维持与各聊天平台的直连和本地定时任务，并且让模型服务商的流量直接从 Daemon 发出，不经过中心服务。 第二个是 Relay，属于可选组件。它接收基于回调的入口流量和网页聊天，代理集中管理的 MCP 与 OpenConnector 访问，并把消息入口直接转发给对应的 Daemon，自身不做持久化存储。 第三个是 Control Plane 加 Web UI。它负责认证、配置、智能体放置、权限、元数据与可观测性。对于经过明确批准的组织知识和技能修订版本，它会存储下来；其余情况下，它按需代理对 Daemon 的有限读取。

这套划分的关键，是把「数据面」和「控制面」拆开。实时的平台消息和 ACP 更新流只在 Daemon 与 Relay 组成的数据面里流动。除了被明确批准的组织知识和有大小限制的技能包之外，控制面保存的只是协调用的元数据，不保存消息正文、附件字节、待处理的 Dream 提案，也不保存 ACP 会话流。README 还明确写道：如果控制面暂时不可用，已建立的会话和 Daemon 本地的定时任务会继续运行，只是新的分配和配置变更要等重新连接后才生效。这是一个很务实的故障模型。

技术要点：运行时无关与 ACP

AgentConnect 的第一个技术选择，是不绑定任何一种智能体运行时。Claude Code、Codex、Grok Build、DeepSeek、Pi，以及任何兼容 ACP 的运行时，可以并排运行。每个智能体的运行时、模型、工作区、工具和所在机器都能单独配置。README 的说法是：更换其中一个，不需要围绕它重建整个工作流。

ACP 在这里起到「统一插座」的作用。Daemon 通过它与不同的编码智能体对话，因此上层的路由、权限和记忆逻辑不必为每个运行时各写一套。对已经同时使用多个编码智能体的团队来说，这比为每个工具单独接入聊天机器人更容易维护。

技术要点：Decisions 与 Jev 路由

第二个值得注意的机制是可复用的 Decisions，由 Jev（TypeSafe）驱动。它用来决定三件事：智能体何时应该响应，新的会话该交给哪位专家智能体，以及每个新会话应该选用哪个运行时和哪个模型。README 举了两个典型场景。一是客服分流：新的支持对话由 Jev 路由给合适的专家，人和智能体在同一个线程里排查，修复与验证过程全程可见。二是定制化代码审查：由 Jev 为每个新的 GitHub Pull Request 选择审查者，并为每次审查会话选择运行时和模型，通用、架构、安全等不同审查者可以拥有各自的指令、仓库权限、工具与沙箱策略。

这相当于在「谁来做」和「用什么做」之间加了一层可配置的策略层，而不是把规则写死在某个机器人脚本里。

记忆、知识与权限

AgentConnect 给每个智能体独立的记忆与技能，并支持发布经过审阅的 Knowledge，供所有智能体按需检索。部署指南中还提到可选的 Mem0 配置。

README 同时强调边界控制：可以决定谁能看到每个智能体和会话，它能使用哪些仓库与工具，以及它可以调用哪些其他智能体。工作可以从一条消息、一个 Issue、一个 Pull Request、一个 Webhook 或一个定时计划开始。

部署方式

项目提供两条自托管路径。最快的是 Docker：克隆仓库后执行 docker compose up -d --pull always，会启动 Web 控制台、Control Plane、Relay 和 PostgreSQL。打开 localhost:3000，在控制台添加 Daemon，运行它生成的命令，再创建第一个智能体。默认栈只监听 127.0.0.1，并使用本地免认证模式，仅供评估。

生产环境可使用每次发布同步推出的官方 Helm Chart，地址为 oci://ghcr.io/agentconnect-md/charts/agentconnect，版本号与发布版本一致。另有仅在回环地址 8091 端口运行的 Setup Server，用来配置基于 Logto 的浏览器认证，以及 GitHub、Slack、Google、飞书等应用。仓库里还附带一个安装技能，让 Claude Code、Codex 等工具按交互式教程带你完成部署。开发需要 Node 24.12.0 或更高版本和 pnpm 11。

生态影响

对开发者而言，最直接的价值是把智能体从「个人终端」搬到「团队共享空间」。同一个 Slack 线程里，人可以接手、审阅、纠正智能体的工作。

对企业而言，Apache-2.0 加自托管意味着智能体执行和工作区可以留在自己运营的环境里，这对合规敏感的团队很重要。多运行时并存也降低了对单一模型厂商的依赖。

局限与需要观察的地方

需要诚实地说明：README 没有给出任何基准测试、延迟或成本数据，所以本文不对性能做断言。以下是读者评估时值得关注的几点。

第一，项目自身也在 README 中提示，默认栈用的是免认证评估模式，上生产前必须配置认证、公网地址和 Linux 沙箱要求。第二，多智能体互相调用会放大成本与失控风险，权限边界和调用图需要团队认真设计。第三，Decisions 依赖 Jev 这一外部组件，其成熟度与可替代性需要单独评估。第四，「Claude Tag」这一对标对象本身的细节，在该 README 中没有展开，读者应以官方文档为准。

展望

如果多智能体协作成为常态，瓶颈将不再是单个智能体的能力，而是路由、权限、记忆和可观测性这些「组织层」问题。AgentConnect 把赌注押在这一层，并且选择开源、可自托管、运行时中立。

它能否成为事实标准，取决于 ACP 生态的扩展速度，以及社区能否在安全与成本控制上给出成熟的最佳实践。目前它已经是一个值得团队试用并认真评估的参考实现。