80 个 Agent 之后，AI 团队终于不用自己写 Agent 了
Rakuten France 的 AI 团队只有 4 个人。
如果按常规打法，这 4 个人很快会变成全公司的自动化客服：产品团队要一个 backlog 巡检 Agent，客服团队要一个工单总结 Agent，运营团队要一个报告 Agent，财务团队要一个对账 Agent。需求越多，AI 团队越忙；大家越相信 AI，排队时间越长。
这听起来有点讽刺——AI 本来是来消灭重复劳动的，结果先制造了一个新的瓶颈。
Sidney Golstein（AI Lead）换了一个问题：如果 4 个人不可能帮全公司写完所有 Agent，那能不能让全公司自己写？
今天，Rakuten France 内部已经跑着 80 多个 Custom Agents。更关键的是，大多数并不是 AI 团队亲手做出来的。AI 团队没有变成更大的外包工厂，而是搭了一套让别人持续生产 Agent 的系统。
从工单模式到生产线
很多公司的 AI 落地会自然滑向一种工单模式：
业务团队发现重复工作 → 提交需求 → AI 团队评估、排期、写提示词、配置工具、上线自动化 → 流程变了再回来维护
这套流程的问题不在技术，而在组织结构：以前大家排队等 IT，现在排队等 AI 团队。入口换了，拥堵点还在。
Sidney 还发现另一个问题：很多自动化本身并不稳定。一个 no-code workflow 刚上线时很漂亮，三个月后负责人换了，字段改了，文档搬家了，没人知道它为什么还在跑，也没人敢随便停。
Rakuten France 内部有一个词：shikumika。大意是把一件事系统化，让结果不依赖某个具体的人。
放在 Agent 上，这句话很具体：一个人会写 Agent，不够。公司需要的是第 2 个、第 10 个、第 80 个 Agent 都能用同一套方法被创建、被记录、被维护、被改进。
Agent Builder：把创建 Agent 变成一段对话
Sidney 没有先去接更多需求。他先搭了一个 Notion Agents Playground。
员工想做一个 Agent，不需要从空白页开始写长提示词，也不用先理解所有配置项。他们会先进入内部 Playground，找 Rakuten Agent Builder 聊天。
Agent Builder 会继续追问：
- 触发条件是什么？
- 输入来自哪里？
- 输出写到哪里？
- 什么情况需要提醒人？
- 失败时怎么记录？
最后它会生成完整指令，自动带上公司统一的 SOP，再给出一步步设置指南。Sidney 说，一个新 Agent 通常 10 到 20 分钟就能上线。
这句话表面上是在讲速度，实际上讲的是权限的转移：
过去，业务团队只能描述问题，等待 AI 团队交付答案。现在，业务团队可以自己把问题变成 Agent。AI 团队仍然重要，但工作内容变了——他们不再站在每个需求前面当人工接口，而是把自己的经验做进 Agent Builder 里。
这个设计很像把「会做 Agent 的人」封装成了一个内部产品。
新员工第一次接触这套系统时，还有一个 Friendly Onboarder 负责引导。Sidney 还组织过 workshop，让各个团队现场做出自己的第一个 Agent。
推广 AI 最难的地方，经常不是模型能力，而是第一步太陌生。 Rakuten France 没有指望员工自己摸索，而是把「第一次上手」也做成了流程的一部分。
Shared Operating Procedures：别让每个 Agent 都有自己的脾气
让所有人都能创建 Agent，听起来很民主，也很危险。
如果每个人都按自己的习惯写指令、记日志、处理失败、调用工具，公司很快会得到一堆性格各异的小机器人。短期看很灵活，长期看很难维护。
Sidney 先做了一层地基：Shared Operating Procedures。这些 SOP 不负责某一个具体业务，而是规定所有 Agent 都该遵守的共同动作：
- 运行时怎么记录日志
- 数据从哪里读、写到哪里
- 失败时怎么暴露问题
- 哪些动作必须留给人确认
- 如何抓取信息
- 如何优化指令
- 如何把结果交付给业务团队
这听起来像公司文档里最无聊的部分，但在 Agent 系统里，它就是操作系统。
没有这层标准，Agent 多了以后会变成一堆私人脚本。每个都能跑，每个都没人敢碰。
有了 SOP，Agent Builder 每次生成新 Agent 时，都会把这些共同规则带进去。员工创建的是自己的业务 Agent，但底层行为方式是统一的。
这一步很像软件工程里的框架——成熟团队不会每个项目都重新发明日志、权限、错误处理和目录结构。Agent 进入组织之后，也需要同样的工程化。
Agent Registry：80 个 Agent 之后，最怕的是没人知道谁在干什么
当公司里只有 3 个 Agent，靠记忆还能管理。到了 80 个，就不行了。
谁负责这个 Agent？它读了哪些数据库？每天几点跑？有没有和别的团队重复？出了问题看哪里？新员工怎么知道公司已经有现成方案？
Rakuten France 做了一个 Agent Registry 数据库。每个新 Agent 都会自动登记进去。
这个数据库解决的不是展示问题，而是治理问题：
- 别人能搜到已有 Agent，就少做一遍重复工作
- 负责人清楚，出了问题就能找到人
- 运行范围透明，AI 团队才知道公司里到底有哪些自动化正在影响业务流程
Sidney 预判了一个趋势：Agent 越容易创建，越容易变成新一代影子 IT。
以前影子 IT 是 Excel 宏、个人脚本、Zapier workflow。下一代影子 IT 很可能是散落在各处、没人登记、没人审计、没人维护的 Agent。Rakuten France 提前把这件事制度化了。
Logs + Delicious Improver：让每次运行都变成下一次改进的材料
登记只能回答「有哪些 Agent」。真正让系统持续变好的，是日志。
Rakuten France 要求 Agent 每次运行后写一条结构化记录：
- 什么触发了这次任务
- 做了哪些动作
- 结果如何
- 哪里失败
- 是否需要人工处理
这些日志不会静静躺在数据库里。另一个 Custom Agent，Delicious Improver，会定期阅读日志，寻找重复出现的问题，提出修复建议，甚至建议更新 SOP。
关键点在于：它不会自己偷偷改系统。建议会交给 Agent owner 审核。人仍然在控制回路里。
经验总结
Rakuten France 的实践揭示了一个重要趋势：Agent 开发的民主化。
当 Agent 从项目变成产品，从工单变成 SOP，从个人技能变成组织能力，AI 团队的角色就从「执行者」变成了「赋能者」。
对于想扩大 Agent 覆盖面的团队，有几个关键点值得借鉴：
- 先搭系统，再接需求 — Agent Builder 是基础设施，不是可选项
- SOP 是地基 — 统一规范比灵活更重要，否则 Agent 越多债务越多
- Registry 是治理核心 — 没有可见性就没有可控性
- 日志即改进 — 让每次运行都成为下一次优化的素材
原文来自一飞开源，介绍创意、新奇、有趣、实用的开源/AI应用与系统。