Agent 已经开始干活了但在大多数协作工具里它依然没有自己的位置。它不是员工也不是系统只能顶着一个服务账号混在群里。它能发消息能接收指令偶尔还能在群里贴一段看起来像模像样的分析报告但没有人真的把它当成团队里的一员。在权限上做竞品分析的 Agent 需要看项目群里所有的讨论内容做代码审查的只需要看代码仓库相关消息这种区分在现有的服务账号体系里做不到。服务账号是给系统集成准备的它的权限模型只有能不能访问这个资源这一层没有这个账号替谁干活、能看到哪些上下文这种粒度。实际操作中团队只能靠手动拉群和转发消息来控制信息可见范围效率很低而且容易出错。比权限更麻烦的是Agent 几乎没有工作履历。人干了三个月活团队知道他擅长什么、哪些任务做得好、哪些地方踩过坑下次分配任务的时候有这些经验可以参考。Agent 跑了一百次任务反而什么都没留下。完成率多少、被打回几次、擅长处理什么类型的活这些信息散落在各个对话窗口的聊天记录里没有人整理也没有地方整理。下次需要选一个 Agent 干活的时候只能靠猜或者重新让它试一遍之前一百次任务积累下来的表现数据完全浪费了。这个问题在团队协作的语境下会更明显。假设一个项目里有三个 Agent 同时在跑一个负责调研、一个写方案、一个做测试项目负责人怎么知道哪个 Agent 上次交付质量高、哪个被打回过两次没有办法知道。所有 Agent 在协作工具里看起来都一样都是同一个服务账号头像没有任何差异化的信息可以帮助决策。明略科技在 Octo 里给每个 Bot 做了一个 AgentCard上面写着能力标签、历史工作记录和打回次数。这不是什么复杂的技术方案就是把本该被结构化保存的信息存下来让团队选 Bot 干活的时候有数据可以看。AgentCard 还记录了这个 Bot 是谁创建的、替谁干活、继承了哪些权限这些信息在协作过程中会持续更新而不是创建之后就再也不变了。很多 Agent 完成任务后只是在群里贴一段结果很快就被新的聊天记录淹没了。三个月之后想找那次竞品分析的完整输出根本翻不到。更常见的情况是交付被打回了但打回的原因只存在于某一段对话里Agent 自己不知道上次为什么被退回下次同样的错继续犯。上一次的反馈没有被记录下来也没有办法注入到下一次的任务描述里每次都要从头教一遍。Octo 用 Matter 来处理这个问题Matter 把每次任务交付从对话流里拎出来变成一个带有负责人、交付物和验收结论的结构化工作单元。交付物挂在 Matter 下面不会被消息冲走验收的时候打回或者通过都会留下记录反馈被记录下来之后会在下次任务中自动注入。一个 Matter 的完整生命周期包括 Brief、讨论过程、产出、人的反馈和最终验收结论所有这些东西都在一个地方不用去翻聊天记录。多个 Agent 之间怎么协作一个 Agent 做调研的时候需不需要看到另一个 Agent 正在写的方案有些场景需要信息共享来避免重复劳动有些场景隔离更好各做各的最后人来选最优方案。现有协作工具里所有消息对所有群成员可见没有协作模式这个概念信息该怎么流转完全靠人手动控制。Octo 设计了六种协作模式来定义 Bot 之间的信息可见性和流转方式从完全共享到完全隔离都覆盖了根据任务性质选择对应的模式。如果团队真的准备让 Agent 长期参与协作它至少应该像一个正式成员一样有身份、有工作记录也有明确的交付和验收流程。这不是什么高级需求是协作工具在 AI 时代应该具备的基本能力只是在现有产品的设计里被忽略了。Octo 已在 GitHub 开源Apache 2.0 协议https://github.com/Mininglamp-OSS/octo-server