我们为什么要做 AgentConnect
团队里每个人都在写同样的 Agent 胶水代码。所以我们把它做成了一个平台。
一切从写代码开始
和大多数团队一样，我们的起点很简单：每个人在自己的终端里运行 Claude Code 或 Codex，用它来写代码。
Agent 越来越强，我们开始给它们派别的活。线上报错了？让 Agent 先做第一轮分析。上游依赖发了新版本？让 Agent 升级我们的二进制。每日健康检查。新 PR 的初审。聊天里有客户提问？让 Agent 先起草回答。
不知从哪一刻起，我们的 Agent 越过了“编码工具”这条线，变成了更接近团队正式成员的存在。
Agent 不是“对模型的一次 API 调用”。模型可能运行在提供商那里 —— 但 Agent 本身是一个真实的进程，它会检出你的仓库、执行命令、持有你的凭据。
这个进程运行在哪里，谁能看到它，谁能指挥它 —— 真正的问题从这里开始。
“个人终端”模式在哪里失效
问题很快显现。我们的 Agent 在做团队的工作，却仍然像个人工具一样活着 —— 待在某一个人的终端里。队友看不到 Agent 在做什么，无法接管一个会话，无法审阅它的输出，而它积累起来的上下文全都留在一台笔记本上。
于是每个人都为自己的场景写了一堆临时胶水：消息频道、定时任务、凭据处理、上下文拼接。直到某天我们对比笔记 —— 大家写的代码几乎一模一样。
大多数使用 Agent 的团队迟早会走到这一步：Agent 的能力是现成的；缺的是把它接到团队真实工作方式上的那一层。而每个团队都在从零开始重造这一层。
三个我们不愿妥协的要求
我们认真研究了现有的工具 —— OpenClaw 这样的个人助手、Raft 这样的 Agent 工作区，以及 Claude Tag。它们各自都很擅长自己的目标。但我们始终绕不开三个要求，而没有一个工具能同时满足这三点：
于是我们做了 AgentConnect：一个让团队共同运行和管理 Agent 的开源平台。背后的原则是：我们不发明新的协作场所 —— 我们把 Agent 带到协作已经发生的地方。
实践中是什么样子
下面是这套方案能实现的一类工作流 —— 也是我们说“AI 团队”而不是“AI 工具”的原因：
#customers同一线程
AgentConnect 提供的是连接组织：身份、路由、权限、调度位置、触发器和投递。每个 Agent 都有稳定的、有名字的身份，由你选择的运行时支撑 —— Claude Code、Codex 或任意 ACP 兼容运行时。Agent 活在 Slack、Discord、Telegram 和飞书里；工作也可以由 GitHub 事件、通用 webhook 和定时任务发起。权限决定哪些成员 —— 以及哪些 Agent —— 能看到什么。启用记忆后，Agent 可以跨会话保留上下文。而通过开源的连接器网关 OpenConnector，Agent 可以操作第三方服务，而无需把提供商凭据放进 Agent 进程。
执行留在你的基础设施上
Agent 的执行和工作区留在你掌控的基础设施上。控制平面从不处在实时消息路径上，也从不存储消息内容；基于回调的入口流量可以经由一个可选的、不做持久化的中继。
接下来往哪走
我们相信，下一阶段是帮助团队在不抹平访问边界的前提下把上下文延续下去。一个获得授权的 Agent，可以从它被允许访问的频道、仓库和系统中保留并呈现相关决策，这样团队就不必每次都重建同样的上下文。这一层应该是开源且提供商中立的 —— 团队的上下文不应托付给任何单一供应商。
试一试
如果你的团队正处在“每个人都在写自己的 Agent 胶水”这个阶段 —— 我们把这些胶水做成了一个平台。Apache 2.0 开源，今天就能自托管。
