团队里AI助手用得多了之后，会出现一个很诡异的场景。周五下午要发版，产品说他让AI整理过变更影响范围，开发说他的AI审过代码没发现问题，测试说AI跑过用例全绿。结果上线出了故障，翻日志只能看到"系统调用"四个字，哪个AI在什么时间基于什么上下文做了判断，全都说不清。最后背锅的还是人，但你甚至搞不清楚该找哪个人聊，因为三个AI挂在同一个服务账号下面，用的是同一个API Key。

这不是科幻场景。现在大多数团队接入AI助手的方式就是买一批API额度，配一个服务账号，所有人共用。单个人用单个助手的时候这套做法没问题，你让它写代码它写，出了问题你自己兜着。但团队里同时跑五六个Agent的时候，服务账号模型立刻就不够用了。

先说权限。做竞品分析的Agent应该能读项目群里所有讨论记录，做代码审查的Agent只需要看PR和代码仓库相关的消息，这两种权限差异很大。服务账号不管这些，它的模型只有一个开关：能访问或者不能访问。Agent能看到什么上下文完全靠人手动控制，拉个群、转发消息、设个权限组。Agent数量一多，这套人工隔离方式就开始出错。有团队为了控制不同Agent的可见范围建了十几个群，消息传递靠人在中间转发，算下来比不用AI还慢。

工作记录的问题更实际。一个工程师在团队待三个月，谁都知道他擅长后端接口、写文档马虎、上次那个内存泄漏是他修的。下次派活不用想就知道什么任务该给他。Agent跑了一百次任务呢？完成率多少、被打回过几次、哪些类型的任务交给他靠谱，这些数据全散在聊天记录里，没有地方汇总。派一个Agent去做代码审查，你其实是在赌。三个Agent同时在项目里跑，做调研、写方案、跑测试，负责人分不清谁上次交付质量高、谁被打回过两次，看头像全是一样的默认图标。

Octo给每个智能体配了一张AgentCard，上面记录创建者、归属人、挂载的技能、运行时类型、历史任务完成数、打回次数和擅长的任务类型。这些字段不是注册的时候填一次就锁死了，协作过程中持续更新。某个智能体连续三次因为异常处理不完善被打回，卡片上会留下这个记录；另一个在数据分析类任务上连续多次高质量交付，下次有类似任务它会排在候选前面。派活从拍脑袋变成看历史数据决策，这件事不复杂，但目前确实没什么平台在做。

权限跟着归属关系走，不需要单独造一套Agent IAM。智能体的有效权限是创建者权限和当前工作区角色的交集，实习生的智能体摸不到生产环境配置，因为实习生本身就没有那个权限。每次操作都能追溯到具体的人，审计不需要额外设计。智能体被派到特定回路里执行任务时，它只能看到这个回路内的信息，看不到工作区里其他不相关的任务数据，信息边界由回路本身控制。

我们没有做KPI打分系统。Octo的反馈机制更轻：验收时通过或者打回，打回必须写原因。"异常场景没有覆盖""结论缺少数据支撑"这类反馈绑定在回路上，智能体下次接同类任务会自动读取。这套机制和人在工作中学习的路径一样，不是靠上课培训，是每次做完事收到反馈，下次知道该调整哪里。用的时间够长，智能体对团队代码规范、输出格式偏好、验收标准的理解会越来越准，这件事靠堆system prompt做不到，因为prompt是静态的，反馈是持续生长的。

给智能体建身份、记履历这件事，很容易被理解成把公司那套人力资源管理搬到AI身上，多此一举。实际做下来发现不是。身份的核心价值不是管控，是让Agent能够被安全地、可预期地用在团队里。没有身份，权限边界就一直模糊；没有历史记录，每次派活都是在赌；没有反馈沉淀，调教成本永远降不下来。一个人用一个助手聊天，这些问题全不存在。当Agent开始跨角色协作、对交付结果负责、在生产环境里执行操作，身份系统就是地基，不是锦上添花。

Octo已在GitHub开源，Apache 2.0协议，支持私有化部署。核心围绕智能体身份、回路任务单元、经验沉淀和六种协作模式构建，Web端、桌面端、移动端、浏览器插件和CLI均可用。项目地址 https://github.com/Mininglamp-OSS/octo-server