我们如何在 Transgenia 治理一支十二个 AI 智能代理的团队

九项运营实践，让你的智能代理团队不至于沦为魔法师学徒手中的那把扫帚。

1797 年，歌德发表了一首短歌谣，题为《魔法师的弟子》（Der Zauberlehrling）。师父外出。学徒不愿再一桶桶地提水，于是教会一把扫帚替他去做。扫帚服从了。扫帚服从得太过尽职。作坊最终被水淹没。2026 年，AI 智能代理这一行业每天都在上演同一幕，只是换了不同的办公室，换了不同牌子的扫帚。

本文并非对模型的批评。今天的模型完全胜任。它是一份诚实的记述，讲述我们在 Centrum Transgenia 为运营一支十二个内部智能代理的团队所采纳的九项实践——不必每周关停它，也不必淹没作坊。

开始之前先说明一点。本文中你不会看到取整的营收数字，不会看到 ROI 百分比，也不会看到客户名称。原因就在第八项实践里：零虚构。只有可验证的机制。

问题所在。服从得太过尽职的扫帚

智能代理团队从演示走向运营时会失败，原因在每个行业都反复出现。它们并非因模型孱弱而失败。它们失败于能力过剩却无治理。

一份简短、克制、不加修饰的清单：

1. 无可追溯的自主。一个智能代理执行了某项动作；却无人能还原它为何这么做。
2. 自信的幻觉。模型生成一个不存在的数据，其节奏与它生成一个正确数据时别无二致。
3. 沉默的记忆。每次会话都从零开始。周二学到的教训到周四已然失落。
4. 脆弱的治理。规则寄居在提示词里；下一次重新生成便将其抹去。
5. 不透明的成本。没人知道哪个智能代理消耗了多少。账单到月底才送达。
6. 借来的身份。两个智能代理以同一个身份说话；遥测无从分辨。
7. 意外继承的工具。一个智能代理获得了本不属于它的权限。
8. 没有边界的写入。提议与执行之间不存在结构性的区别。

任何手握一个能跑的演示的决策者，都可以略过这份清单。任何有两个月真实运营经验的决策者，都会耐心地读完它，因为他认得出这些场景。

论点。一张揣得进口袋的卡片

经过十二个月的运营，这一论点可以浓缩为四个各有强制主语的动词：

AI 提议，人类批准，系统记录，企业学习。

这不是一条建议。这是一套层级。每个动词都有各自的主语，彼此不可互换。

一个智能代理可以起草一封邮件、一张会计凭证、一份媒体推介、一整篇文章。但它不能发送这封邮件、不能过账这张凭证、不能发出这份推介、也不能发表这篇文章——除非有一句格式精确的人类批准语。与此同时，系统会保存草稿、提示词、来源、模型、时间戳与签名。当下一个类似的决策出现时，企业查阅这份记录，便闭合了整个循环。

概括这一切的词是 draft-first（先出草稿）。每个智能代理都先交出一份草稿。没有哪个智能代理未经许可就发布。它需要付出摩擦的代价；回报则是可审计的运营。

九项在业内并不常见的实践

我用同一种结构来呈现每一项：它是什么，为何不常见，如何在你的团队里复现。没有哪一项依赖我们的技术栈；它们都可以搭建在开源项目之上。

1. 治理落在写入的边界，而非能力

是什么。我们不限制智能代理能读什么。我们限制它能写什么。一个智能代理可以查询 ERP、邮件、CFDI、各类仪表盘，甚至与其他智能代理对话。但没有哪个智能代理能修改一条运营记录、发送一封邮件、取消一张发票或发表一篇文章，而不穿过一道三重锁：环境标志、运行时确认、格式固定的人类批准语。

为何不常见。演示展示的自主越多，看起来就越漂亮。一道写入锁会减少智能代理无需干预就完成的任务数量，而这在平台推介里会被解读为一种软弱。可在真实运营中，它决定了你是否敢把 CRM 交给它。

如何复现。把你的工具划分成两份明确的清单，read_tools 与 write_tools。只有在 WRITES_ENABLED=true 时才放出后者。记录每一次失败的尝试；它们能帮你发现新的失效模式。

2. 多供应商的信任层级

是什么。没有任何一项运营决策依赖单一的模型供应商。我们按照任务所要求的信任等级，把工作分派给多家。内部的助记口诀带着几分亲昵：Mistral 提议，OpenAI 生产，Claude 裁定。一个经济型模型起草，一个中间型模型精修，一个更强推理的模型审查。

为何不常见。锁定很舒服。一个 SDK，一个计费面板，一份合同。等到价格变了、使用政策变了，或某个区域宕机时，账单才会到来。

如何复现。在你的路由器里定义三个层级（draft、refine、dispose），并按可逆性与成本为每个任务分派层级。把每个层级的 allowlist 记录在一个受版本管理的文件里。每季度重新评估一次。

3. 由设计保障的可观测性

是什么。没有一次执行不留下痕迹。Prometheus 负责指标，Grafana 负责面板，Langfuse 负责追踪与会话，OpenTelemetry 作为统一的发射层。在其之上，还有一个自建面板，让智能代理之间的委派变得可读：谁调用了谁，用了哪个 skill，激活了哪个 droid，查阅了哪段记忆，何时结束了会话。

看不见，就不可信。

为何不常见。最初的埋点在产生价值之前先被当成成本。可观测性的技术债悄然增长，直到某次事故让它显形；到那时，它已是结构性的了。

如何复现。在每一次推理中都发出 service.name、gen_ai.agent.name、gen_ai.model、gen_ai.tokens.input、gen_ai.tokens.output、gen_ai.tool.name。从第一天起就搭建委派面板。

4. 审计即契约，智能代理之间的对抗式复核

是什么。每一次干预都以一个带 ISO 日期的文件夹和一份 fix_log.md 收尾：来源、决策、前后状态、人类签名。在其之上，第二个角色不同的智能代理执行一次对抗式复核，并把它的 security_review.md 与 fix_log 并排发布。

没有 audit，就没有交付。

为何不常见。在以速度为中心的生产模式里，智能代理之间的复核会被视为瓶颈。而在以信任为中心的模式里，它是发现系统性错误模式的唯一途径。

如何复现。文件夹约定 audit/<YYYY-MM-DD>/<slug>/。fix_log 必填。第二个复核智能代理的角色须与第一个不同。

5. 能在自愈中幸存的持久护栏

是什么。关键规则寄居在可重新生成的区块之外。我们从受版本管理的文件（BRAIN.md、每个智能代理各自的本地 CLAUDE.md）加载 core，一个周期性的自愈过程会把它重新施加到十二个智能代理上。

为何不常见。用配置 GUI 来运营的团队，会把可见的状态误认为持久的状态。第一次重新生成就抹掉了规则，他们才迟迟发现：自己需要一个位于供应商容器之外的真相来源。

如何复现。找出那些绝不能丢失的规则，把它们迁移到供应商之外的受版本管理文件里，再写一个每日对账的脚本。

6. read-first 阶段，以及为每次作业声明的“性质”

是什么。每一项能力都诞生于只读。商业智能诞生于读取 CRM。公关智能诞生于读取获授权的渠道。写入是之后才开放的，当读取者证明了自己的稳定。此外，每个任务在触碰任何东西之前都要声明自己的“性质”：audit-only、protected-state-safe、remediation-with-VoBo、content-drafting-no-publish。

为何不常见。商业压力逼着人尽早展示价值。只读阶段并不产出看得见的交付物。跳过它的团队会迟迟发现：自己在了解失效模式之前就已经授予了写入权限。

如何复现。每一项新能力都默认 READ_ONLY=true。在开放任何 write 之前，至少两周的只读运营。一套封闭的作业性质分类法。

7. 每个智能代理各自隔离的身份

是什么。每个智能代理都有各自的 projectPath、本地的 CLAUDE.md、不同的 service.name、在记忆中唯一的 slug。运营用的 core 通过 hardlink 或 junction 共享，而非拷贝。这一举解决三个问题：人格冲撞、遥测归属、记忆污染。

为何不常见。SaaS 平台为“单一面板”而优化，把整个团队当成一个容器里的一份清单。遥测与记忆最终都被归到一个集体标识符名下。

如何复现。每个智能代理一个根目录。本地的 CLAUDE.md，声明名称、角色、gates 与语气。OTEL_SERVICE_NAME 采用 equipo-<slug> 模式。运营用的 core 通过 hardlink 共享。

8. 一流的反虚构，配以来源层级

是什么。如果智能代理无法验证一个数据，它就声明其为未知。不做近似，不给那些听起来可信的取整数字。此外，每个领域都有自己的真相来源层级，封闭且成文：

• 在 SEO 领域，Google 是首要权威（Search Console、URL Inspection）。其他工具只是辅助。
• 在会计领域，顺序是 SAT（l10n_mx_edi_cfdi_sat_state）、CFDI 保险库、银行对账单、Odoo 记录。

为何不常见。生成式模型天生更倾向于把一段文本补完得看似合理，而不愿留下一个显眼的空缺。坚守这条政策，要求在每一个 system prompt 里重复它，并接受不完整的交付物——它胜过凭空捏造的交付物。

如何复现。把这条政策原文写进 system prompt：“若无法验证，便声明为未知”。公布每个领域的来源层级。把一个编造的数字当作严重事故来对待。

9. 共享的能力池，由设计而来的继承

是什么。每一项能力只开发一次，以两种形态存在：一个 skill（负责文档与操作）和一个 droid（带各自的上下文执行）。二者都存放在一个唯一的池子里，任何智能代理都可以调用。三个可组合的 droid（session-guard、vobo-gate、audit-logger）会作为每一次敏感执行的 preflight 与 post-flight 被激活。

编写一次，所有智能代理继承。

为何不常见。大多数平台迫使你在每个智能代理里重复实现同一项能力。每一次重复，都是未来的一次分岔。

如何复现。一个唯一的能力目录。用 hardlink 或 junction 链到每个智能代理。可组合的护栏，按约定在每一次触及外部系统的执行中被激活。

Playbook：给明天就起步的团队的八个步骤

1. 声明各自的职守。禁止“通用目的”。
2. 按角色、按读/写划分工具。
3. 从第一天起就用 OpenTelemetry 埋点。
4. 写下带来源层级的反虚构政策。
5. 建立带精确短语的批准 gate。
6. 创建审计约定：按日期分文件夹，并加对抗式复核。
7. 把护栏迁出供应商的配置 blob。
8. 引入一个带层级的多供应商路由器。

每一个步骤都可以搭建在开源项目之上：Prometheus、Grafana OSS、Langfuse、OpenTelemetry、Qdrant、MCP。起步并不需要签下一纸封闭平台的合同。

从学徒到师父

在歌德的这首歌谣里，学徒只有等师父归来才得救。师父并非喊叫着回来；他带着一句能破除魔咒的短语回来。然后他整理秩序。然后他记录。然后他传授，好让扫帚不再淹没作坊。

在 Centrum Transgenia，我们决定：那位师父不是魔法师。他是一套协议。那句短语是一道批准 gate。那份秩序是一份 fix_log。那份记录是一个带日期的文件夹。那份传授是一份 BRAIN.md。

没有人需要紧急赶来。没有东西被淹没。扫帚在干活。学徒在学习。作坊第二天依旧开门。

如果贵公司正在考虑组建一支智能代理团队，或者已经拥有一支、却发现扫帚已然失控，请写信给我们。对话从 [email protected] 开始。我们带来协议。你们带来作坊。

完整的白皮书（附录、术语表、各领域来源层级，以及 CC BY-SA 许可）可应索取，写信至 [email protected] 即可获取。