AI Agent 上线之后，归谁管？

前段时间，我跟一个朋友吃饭。

他在一家大型公用事业公司做事。下个季度，他们要上线 200 个 AI Agent。大部分还不是 IT 部门做的，是市场部这样的业务部门，自己动手搞出来的。

我说，强！

真的强。业务部门不用等 IT 排期，自己就把智能体造出来了。这是很多公司盼了多少年的状态。

然后我随口问了一句：这 200 个 agent，上线之后，谁管？

他说，什么意思？

我说就是，模型升级了，谁负责跟进？公司政策变了，谁来改？写它那个人调岗了，算谁的？

他卡住了。

想了一会儿，没答上来。

我们都在忙着建。忙着让 agent 干活，忙着为「又上线一个」高兴。但很少有人停下来想一件事：

这些 agent，上线之后归谁？

「要不要建」，已经不用讨论了

先交代个背景。

今年 5 月，Kana 调研了 225 位美国大型企业的高管。70% 已经把定制 agent 用在真实的营销工作上。一个都没用的，只有 3%。

什么概念？

「要不要建 agent」这个问题的争论，已经结束了。你还在犹豫要不要上车，人家已经在车上放第二个行李箱了。

真正有意思的问题，是下一个：建完之后呢？

而这，恰恰是最含糊的一块。

同一批高管，问「营销智能体该归谁管」：大约 40% 说，该首席 AI 官管。AI 负责人里，这个比例是 52%。轮到营销高管，多数选自己部门，或者搞个共享模式。

你看明白了吗？

翻译一下就是：两拨都很能干的人，各自都觉得，这件事是对方在管。

于是很多公司现在的真实状态是：agent 在跑，数据在流，没人真正看着。

两边的话，都对一半

那到底该谁管？中央团队，还是业务团队？

两边的话我都听过，都有道理。

主张中央管的人说：agent 天天碰客户数据，处处连着合规风险，而且没有哪个部门，能放心让它自己监督自己的产出。

对吧？没错。

主张业务部门管的人说：中央团队的人，听不出 agent 的语气对不对，不知道它推的 offer 还在不在有效期，更不清楚它圈人的逻辑，还合不合现在这套打法。

也对吧？也没错。

两边都对，事情就麻烦了。

部门会互相以为对方在管，名字不会。

所以，拆。

把一个大问题拆成两个小问题：中央团队管访问权限、管数据、管模型层。营销团队管指令、管语气、管它现在说的话，还是不是真的。

这两份清单，都得落到具体的名字上。

注意，是有「名字」，不是有「部门」。

有名字，不等于真负责

说到名字，有个数据特别扎心。

今年 2、3 月，Ivanti 问了 1500 名 IT 专业人士。85% 说，我们每个 agent 都有具名负责人。只有 42% 说，负责人是谁、管什么，是清楚的。

85% 对 42%，中间差了 43 个点。

这 43 个点是什么？

是「有名字」和「真负责」之间的距离。名字躺在文档里，出了事没人知道找谁，这种「有」，约等于没有。

还有个习惯，值得你去自己的系统里查一查。

很多组织建 agent 的方式，是克隆一个真人用户的账号。省事，快。

代价呢？

你的活动 agent，可能正揣着当初建它那个人的 CRM 权限，在系统里到处走。那个人离职了、调岗了、权限本该回收了，agent 还带着这套权限满楼跑。

上线那天这么干，没问题。现在呢？

谁会发现？

顺带一个数字：65% 的组织会在 agent 上线前做评审。治理出现在发布那天，像剪彩。彩带一剪，agent 每天干活，人一个季度看一次。

软件行业，是挨过打的

讲到这，我给你讲段历史。

上世纪 40 年代到 60 年代，代码在大家眼里是一次性的东西。写完，验收，上架，完事。跟打一把椅子差不多。

后来，越来越多的关键系统开始 7 天 24 小时连轴转。这套「写完就放」的逻辑，崩了。

1968 年，西德小城加米施。北约开了场会，十几个国家的工程师坐到一起碰进度，结果发现，大家卡在同一个坑里：软件会过时。造出来那天是对的，半年后未必。

就是这场会，长出了今天教科书里的软件生命周期：需求、设计、构建、测试、部署……然后，维护、退役。

后两步不是谁设计出来的，是挨打之后补上去的。整个行业用真金白银学会了一件事：软件不会自己维护自己。

那，维护到底有多贵？

1980 年，Lientz 和 Swanson 两位学者研究了 487 个组织，发现维护吃掉了差不多一半的软件预算。

一半！

更值得琢磨的是细账。这些钱里，最大一块叫「完善性」：需求变了，得改。第二大块叫「适应性」：环境变了，得改。真正修缺陷的「纠正性」，反而是最小的一块。

什么意思？

大部分维护成本，花在「代码没错，但世界变了」上。

现在，把这段历史套在你的 agent 上

你的内容 agent，3 月上线，对着 3 月的 offer、3 月的话术写的。

你的 SDR agent，学的是调价之前的客户画像。

你的品牌语气护栏，绑在一个夏天就被官方停服的模型版本上。

这些是 bug 吗？

都不是。代码一行没坏。

但世界变了。offer 过期了，价格调了，模型退役了。按软件行业的说法，这就是维护。而维护，需要有人知道「什么变了」，以及「接下来怎么办」。

想象一下，你的 agent 走进周一的站会，做自我介绍：

「大家好，我是活动 agent。我出生在 3 月，对着一场 6 月就结束的促销。我现在，还在发。」

你笑不出来，对吧。

五个问题，问你自己

那就动手查。挑一个已经在生产环境里跑的 agent，问五个问题：

1. 它的指令，是谁写的？
2. 谁来改这些指令？多久改一次？
3. 谁盯着模型更新，并且能把「模型变了什么」翻译成你们团队能用的动作？
4. 谁盯着它的输出漂移？拿什么当基线？
5. 谁决定它什么时候退役？

我跟很多团队聊过。第一题基本都能秒答。问到第二题，会议室就开始安静。问完五题，彻底安静。

安静，就说明这些事现在没主。

怎么补？不用新增编制，把这五件事摊到本来就有的座位上。

指令和修订节奏，给市场运营。工作流本来就是他们管的。

输出漂移，给品牌。全公司只有他们说得出，这段话还像不像「我们」。

模型更新，给 AI 团队或者平台团队。他们本来就在盯版本发布，顺手的事。

退役呢？退役通常没人认领。给管预算的那个人。

为什么？

因为全公司只有他，会盯着这条预算线问：这笔钱，怎么还在花？

颗粒度你还可以自己选。小团队，三五个 agent，一人盯一个，清清楚楚。大组织，工作流铺满整个系统，就按平台分，漂移用抽样查。

工具也会来的。Salesforce 已经开始给这套东西起名字了：agent 开发生命周期，Agent Supervisor 这样的角色。别的厂商会跟上。

但你要分清楚：工具解决的是「怎么管」，组织解决的是「谁来管」。第二个问题，没有厂商能替你回答。

趁便宜，把习惯养了

好消息是，这件事现在做，最便宜。

8 个 agent 的时候养成的习惯，到 80 个 agent 的时候，就是肌肉记忆。反过来，等 80 个了再想管，那就得搞运动了。

软件行业是撞了一场危机，又花了十年，才学会「发布只是前半场」的。

咱们不用挨这一顿打。

agent 是养的，不是种的。

下周一，进会议室之前，带上两个问题：

你最老的那个 agent，归谁？

上一次有人认真看它在产出什么，是什么时候？

答不上来，也没关系。

今天下午就去看，还来得及。