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
