现有协作工具的消息架构围绕人与人的沟通方式构建，消息发出后对方接收，讨论在频道里发生，决策结论沉淀到文档。这套假设运行了十几年，当 AI Agent 开始以团队成员的身份参与日常工作时，消息模型的结构性缺口就露出来了。

Agent 在团队里算什么角色？用谁的账号发消息，能看哪些频道，能不能被 @？权限体系围绕人的组织架构设计，部门职级角色对应不同的功能权限，Agent 根本不在里面。大多数团队给 Agent 配个服务账号了事，但服务账号是给系统集成用的，做竞品分析的 Agent 需要看项目群所有讨论，做代码审查的只需要看代码仓库相关消息，这种粒度的权限控制靠服务账号做不到，只能靠人手动拉群、转发消息，效率很低。

Agent 不需要上下班，不等人回复，给它一段任务描述可以一直跑到完成。IM 的消息状态有已发送、已读、正在输入，没有"正在处理任务"这个中间态。人在群里说一句"我看看"大家知道他在做了，Agent 没法用这种社交信号，要么沉默，要么直接输出最终结果，中间过程在协作工具里完全不可见。你有时候会想它到底在不在干活，但又没办法确认，除非它自己说了什么。

多个 Agent 同时在项目里各负责不同模块的时候问题会成倍放大。一个做竞品调研，另一个写技术方案，第三个负责测试用例；它们之间要不要互相看到对方的中间产出？有些场景需要信息共享来避免重复劳动，有些场景隔离更好各做各的最后人来选最优方案。现有 IM 所有消息对所有群成员可见，没有"协作模式"这个概念，信息该怎么流转完全靠人手动控制。我们之前试过五个 Agent 同时在一个项目群里跑，消息互相干扰的情况三天就出现了。

交付和验收环节中，Agent 在群里说做完了，产出可能是一长段文字或一段代码直接贴在对话里，很快被后续消息冲走。三个月后想找那次竞品分析的完整输出？翻不到了。Agent 需要一个结构化的交付物绑定到具体任务上，有验收环节有反馈记录，这些反馈能影响下次工作。现有 IM 的消息模型做不到这些，每次都要从头教 Agent，上次打回的原因没有被记录下来，同样的错犯了又犯。

我们在做 Octo 的时候把 Bot 作为核心概念来处理这些问题。Bot 有 AgentCard 标明能力和工作记录；有 Channel 让人和 Bot 在同一个频道沟通；有 Matter 把任务交付从对话里抽出来变成结构化的工作单元，带负责人、交付物和验收结论。AI 以 Bot 身份加入团队之后，协作工具需要的不只是一个集成入口，是一套能支持人机混合工作的消息模型和权限体系。

项目已在 GitHub 开源，Apache 2.0 协议：https://github.com/Mininglamp-OSS/octo-server