Agent之间怎么通信？我们把AI Agent拉进了群聊-平芜编程栈

企业部署 AI Agent 的方式正在发生一个微妙的转向：从"给每个员工配一个专属助手"，逐渐过渡到"让 Agent 进入团队已有的协作空间"。这个变化看起来只是产品形态的调整，背后牵涉的却是 AI 能力在组织内部如何分发、如何被管理、如何产生集体价值的底层逻辑。我们在过去一段时间围绕这个方向做了大量实践，这篇文章把其中的思考过程和技术路径展开聊聊。

个人级 Agent 的天花板在哪里

过去两年，市场上涌现了大量个人 AI 助手产品，形态各异但核心模式高度一致：用户打开一个对话窗口，向 AI 提出需求，AI 返回结果。这个模式在个人效率提升层面已经证明了自身价值，文本生成、代码辅助、信息检索，这些场景的成熟度相当高。

当我们把视角从个人切换到组织，这套模式开始暴露结构性的不足。一个二十人的团队如果各自使用各自的 Agent，产出物散落在二十个独立会话里，团队成员之间看不到彼此的工作上下文，更谈不上协同；管理层无法获知 AI 在组织内的实际使用情况和产出质量；当一个 Agent 完成了某项工作、它的输出需要被另一个 Agent 接力处理时，两个独立会话之间没有任何原生的连接通道。

这些问题不是产品做得不够好就能解决的，它们源于一个架构层面的限制，个人 Agent 的信息边界就是那个用户的会话窗口，这个边界之外的所有上下文对它而言都是盲区。

即时通讯协议为什么天然适合 Agent 分发

回顾企业软件的演进路径，即时通讯平台在组织内部扮演的角色一直在扩展。最初它只是人与人之间的消息通道，后来演变为集成了审批、日程、项目管理的工作台，再到今天越来越多的业务流程开始嵌入 IM 环境。这个扩展趋势有一个内在逻辑，IM 本身就是组织内部信息流转密度最高的通道，几乎所有需要多人参与的工作最终都会在某个群聊里发生讨论和决策。

把 Agent 接入 IM 环境，本质上是在信息流转最密集的节点上插入了一个具备执行能力的参与者。这个参与者不需要每个员工单独安装和配置，不需要学习新的交互界面，不需要在多个系统之间切换上下文。员工在群聊里 @某个 Agent，就像 @一个同事一样自然，Agent 的响应对所有群成员可见，任何人都可以追问、补充、修正。

从技术实现角度看，IM 协议为 Agent 分发提供了几个天然的优势。消息的有序性保证了任务指令和执行结果的时序关系清晰可追溯；群组机制天然支持多 Agent 协作场景，一个群可以同时容纳人类成员和多个 Agent，每个 Agent 响应特定类型的任务；已读回执和消息状态机制为任务执行过程提供了可观测性。这些能力如果在独立 Agent 平台上从零构建，工程复杂度不低，而在 IM 协议层面它们是已经存在的基础设施。

组织级分发带来的能力聚合效应

当 Agent 不再是一个个孤岛，而是作为群组成员参与协作时，一些在个人级部署中难以实现的能力开始自然涌现。

任务分解与接力变得直观。产品经理在群里描述一个需求，规划 Agent 输出任务拆解方案，代码 Agent 接力生成初版实现，测试 Agent 再根据实现结果编写测试用例，整个过程的每一步都在同一个对话流中展开，所有参与者（包括人类和 Agent）都能看到完整的上下文链条。这个协作模式不需要复杂的编排引擎来驱动，IM 的消息流本身就是最自然的编排载体。

知识在组织内部的沉淀方式也随之改变。群聊记录天然构成了一个带有时间戳和参与者标注的知识库，Agent 在群内产出过的分析报告、数据洞察、方案建议，后续都可以被其他成员检索和引用。与个人 Agent 中那些阅后即焚式的会话记录相比，IM 环境中的信息具有更长的生命周期和更广的可见范围。

管理层获得了前所未有的可见性。哪些团队在高频使用 AI 能力，Agent 的响应质量如何，哪些业务流程最适合自动化，这些问题不再需要专门的调研和统计，IM 环境中的交互数据本身就能回答。这种可见性不是通过监控实现的，它是协作过程的自然副产品。

安全与权限在 IM 框架下的实现路径

组织级 Agent 分发绕不开的一个问题是权限管理。一个能够访问企业数据的 Agent 被部署在群聊中，它能看到什么、能做什么、输出结果可以被谁消费，这些都需要精细控制。

IM 框架在这方面有一个天然的优势，群组本身就是权限边界的自然载体。一个财务相关的 Agent 只被拉入财务部门的群聊，它的可见范围和执行权限就自动限定在了这个群的成员和上下文之内；一个跨部门的项目群可以同时配置项目专用的 Agent，这个 Agent 的上下文只包含该项目群内的讨论内容，不会泄露到其他业务线。这种基于群组结构的权限隔离比传统的 RBAC（基于角色的访问控制）更直觉化，也更贴近组织实际运作的方式。

在数据安全层面，端到端加密、消息留存策略、审计日志这些在 IM 领域已经成熟的能力可以直接复用到 Agent 的交互过程中，不需要为 Agent 单独构建一套安全基础设施。对于有合规要求的企业来说，这种复用意味着更低的合规成本和更高的安全可控性。

从 Scaling Up 到 Scaling Out 的组织映射

AI 行业过去几年讨论最多的话题之一是模型规模的扩展路径。Scaling Up 的思路是把单个模型做得越来越大、越来越强，这条路在一定范围内取得了显著成果。Scaling Out 提出了另一种可能性，让多个专精的小模型或小 Agent 通过网络连接协作完成复杂任务。

这个技术层面的路线分歧在组织应用场景中有一个非常直接的映射。Scaling Up 对应的组织形态是每个员工配备一个能力尽可能全面的通用 Agent，所有需求都在一个模型内闭环；Scaling Out 对应的组织形态是在 IM 群组中部署多个各有专长的 Agent，任务通过消息流在 Agent 之间自然流转。

后者的一个关键优势是灵活性。当一个新业务场景出现，只需要引入一个具备相应能力的 Agent 加入群聊，而不是要求现有 Agent 获得新的能力；当某个 Agent 的表现不满足预期，替换它对其他 Agent 和人类成员的影响最小化。这种插拔式的架构让整个组织的 AI 能力具备了持续演化的空间，而不是一次性部署后就固定不变。

实际落地中的工程考量

我们在围绕 Octo🐙做 Agent IM 分发的过程中，积累了一些工程层面的经验值得分享。

首先是消息格式的标准化问题。Agent 的响应不能只是纯文本，它需要支持结构化数据展示（表格、图表、代码块）、交互式组件（确认按钮、选择菜单）、以及长内容的折叠与展开。我们在 Octo 的 IM 层之上定义了一套 Agent 响应消息的标准格式，确保不同类型的 Agent 输出在群聊中有一致且可读的展示效果。

其次是并发与冲突处理。当群内多个成员同时向同一个 Agent 发出指令，或者多个 Agent 对同一条消息做出响应时，需要有明确的优先级和冲突消解策略。我们采用的方案是为每个 Agent 维护独立的任务队列，群内消息按照发送顺序入队，Agent 按照队列顺序依次处理并回复，遇到冲突指令时主动询问群内成员进行仲裁。

最后是上下文管理。IM 群聊的消息量可以非常大，把所有历史消息都塞进 Agent 的上下文窗口既不经济也不高效。我们设计了分层上下文机制，Agent 始终持有群组的结构化元信息（成员列表、角色标注、近期关键决策），对于历史消息则采用基于语义相关性的按需检索策略，确保 Agent 在需要引用历史上下文时能准确获取，同时控制 token 消耗在合理范围内。

这些工程细节看似琐碎，但它们直接决定了 Agent 在组织场景中的实际可用性。技术架构再漂亮，如果群里的 Agent 经常答非所问、响应冲突、或者上下文丢失，用户很快就会放弃使用。