AI 生码率飙升，端到端交付却没有变快；通用 Agent 提效办公生产力，整体业务效能却未同步提升。当企业把 AI 工具推向业务流程，“局部更快、整体不快”的现象值得审视。某智能集团副总裁、CIO 蒋林泉复盘了三年 AI 实践，从问题中找到了答案，也对 AI Native 有了清晰的认识。

AI Native，越热越难说清

AI Native 已是企业讨论 AI 变革使用的热词。

围绕 AI Native 的，还有一长串概念——AI 生码率、Token Maxxing、编程智能体、通用智能体、一人公司、10 倍效率、全自动编程、数字员工、Agentic Workflow。

一个词用多了，似乎就容易“腐败”：含义被稀释，都在说，却谁也说不清。这是蒋林泉对概念泛化的提醒。

他的追问是：Token 用得越多，就越 AI Native 吗？用上了 Vibe Coding，就算 AI Native 的产研组织吗？用上了通用智能体，就是 AI Native 的业务团队吗？

这些指向同一个问题：工具的使用量，并不能直接证明组织形态发生了变化。 AI Native 其实是组织层面的问题——什么样的组织，才算得上 AI Native？

他把对 AI Native 的定义与过去三年的实践放在一起讨论：从 CIO 线自身的产研组织变革，到支撑业务团队，再到把内部能力变成对外交付的产品。

过程中，AI Native 必须同时发生在系统与组织两侧，CIO 与 CPO 的联动也由此成为关键。工具定义能力边界，组织决定这些能力能否进入真实工作、形成有效协作，并最终创造业务价值。

当下，他的回答方式，是复盘自己团队三年来真实走过的路。

产研组织重塑：从“生码率”到“交付效率”

AI 生码率飙升，换不来 E2E 交付效能

从 2024 年底，蒋林泉的团队已经全员用上 AI 编码工具，那时生码率就很快上到 30% 多。

但是，当时有个现象让他警觉：端到端交付一个需求所消耗的人力，没有变化。后来与业界很多产研团队交流，大家都发现了同样的问题—— AI 生码率和代码量持续增长，真实业务项目的 E2E 耗时几乎没有缩短。

团队把一个需求从提出到上线的全过程拆开来看：需求设计、评审和修改约占 20%；交互视觉设计、评审和修改约 10%；技术方案设计和评审约 15%；编码开发约 20%；前后端联调和集成约 15%；测试和 Bugfix 约 20%。

真正写代码的时间，只占 20% 左右。

再把这 20% 拆开，其结构更说明问题。那些要在存量核心系统里修改、要和老系统融合、要保证上线后稳定安全运行的核心代码和关键非功能性代码，代码量不大，却吃掉了 65% 以上的编码时间——而这恰恰是 AI 帮助最有限的部分。反过来，增删改查、前端 UI、测试代码、胶水代码这类常规代码，占据了大部分代码量，却只消耗了不到 35% 的编码时间。

蒋林泉算了一笔账：20% 乘以 35%，约等于 7%。 也就是说，即便 AI 把这部分代码的耗时压缩到零、其他环节都不变，端到端能节省的时间上限也只有 7% 左右——这还只是理论的上限。 业界交流中，有团队说端到端提效 3%，有的说 5%，做得不错的大约在 5% 左右，与这个推算大致吻合。

结论很清楚：AI 最容易生成的代码，原本就没花多少时间；真正花时间的地方，AI 帮的没那么多。

用了 AI，整体效率可能“不升反降”

如果只是提效不明显，问题还不算严重。蒋林泉观察到的另一个现象更值得警惕—— 有些团队的效率在下降。

很多 CIO 和产研负责人向他描述过同一种状况：用了 AI 之后，骨干反而成了更大的瓶颈，“像被 DDoS 了一样”。

可以理解为，一个同学用 AI 很快写出一大堆代码，要上线，就得有人 Review、有人为线上结果负责，而真正能负责的往往只是少数几位“老司机”。这些人被“打爆”，自己的事情干不了，全链路就卡在他们那里。可如果绕过 Review 直接上线，这些代码大概率会变成技术负债。

他把这一轮 生成式 AI 的悖论，概括为一句话：唯一可以确定的是，每个人都可以驾驶 AI，快速、规模化地生产无价值的“负债”。而且这些结果还很像模像样，导致比过去更难识别。

这种现象并不只存在于代码。开会时，一批人拿着 AI 生成的材料，另一批人用 AI 去总结、消化这些材料，彼此之间“用大模型 DDoS”。但风险最终总要有人扛，真正有效信息的上限，也只有骨干才能顶上去。

蒋林泉把它归结为两类风险：

价值风险：加速上线低价值的应用和功能，消耗组织和客户稀缺的注意力；
质量风险：加速产出低质量代码，增加系统复杂度和返工风险，影响稳定性，抬高长期维护成本。

背后的原理在于：一个组织里，注意力是稀缺的，真正能把控有效性、有品味的人是稀缺的。产出越多，这些稀缺的人就越被逼到极限。如果组织本身不做改变，测试、Review、线上检验这些本来就是瓶颈的环节，只会变得更堵。

回到《人月神话》：AI 改变了哪些协作前提

蒋林泉做了二十多年软件工程，也有 IBM 从业经历。他重新回到 Brooks 基于 IBM System/360 和 OS/360 项目经验写下的《人月神话》：在已经延期的项目中继续加人，往往只会增加沟通和磨合成本，让项目更慢。

在他看来，AI 提供了改变协作前提的机会，体现在两个维度：

第一，提升单节点的效率，而不增加人际协作链路。

在项目里加入 Agent，能够增强原有节点的执行能力，并沿用人的任务上下文，不必再通过带新人来增加节点。在任务与上下文清晰的条件下，这为局部提效创造了机会；但正如前面的数据所示，E2E 收益仍受其他环节的瓶颈限制。

第二，也是更有意思的：降低跨技能门槛，减少协作节点。

AI 让一个人跨岗位获取新技能的门槛，似乎下降到原来的十分之一甚至百分之一。移动互联网时代形成的前端、后端、设计、测试的精细分工，是那个时代的生产力决定的——专业供给稀缺，一个人的带宽处理不了那么多技术复杂度，只能以岗位为中心组织、把专业能力池化。今天，无论是做设计、写前端，还是上手一门新技术、新语言，门槛都在剧烈下降。

这意味着，原来必须凑齐多种技能的人才能完成的事，现在有机会由一个人带着 Agent 跨技能完成，从而减少那些“因为技能必须分岗位而被迫产生”的交接与等待。协作节点减少，沟通链路就会呈几何级下降，上下文密度也更高。

从“提升一个人的效率”，到“减少人与人之间的交接” ——这是蒋林泉团队在 2024 年底确认的方向。《人月神话》讲了几十年“加人会更延期”，而现在，组织有机会不加人，甚至把多岗位协同变成少岗位协同。

两个“左移”，能有效控制复杂度

《No Silver Bullet》曾提出，软件开发的困难很大程度上源于复杂性，其中包括 偶然复杂性 与 本质复杂性。偶然复杂性来自编程语言、技术框架和工程工具等实现环节，可以通过自动化测试、CI/CD 等工程体系持续降低；本质复杂性则根植于业务问题本身，难以仅靠工具化解。

沿着这一思路，蒋林泉从两个层面的复杂度，推进变革。

第一：测试和观测左移，减少偶然复杂性。

核心的复杂代码，AI 未必擅长；但写测试、做日志和 Tracing，恰是它的强项。就分析覆盖度、补全缺失 Case 这类具体任务而言，效率可提升十倍甚至百倍。过去一轮轮“提升测试覆盖度”的运动，最后都不了了之，不是研发懒惰，是反馈链路太长：写的测试拦住了 Bug，往往是别人跑出来的，写的人拿不到反馈。于是测试扔给测试团队，Tracing 扔给运维，可处在右侧兜底的测试，并不是最懂业务的人。

有了 AI，这笔账变了。

研发自己做测试和观测，成本很低，最懂业务的人带着最精准的上下文去做，又准又快。 2024 年底，蒋林泉把测试团队整体拆进各研发团队，运维职责也并入研发，上线出了问题由研发自己扛。验证更早、成本更低、返工更少。

第二：用 Live Demo 确认需求，应对本质复杂性。

本质复杂性有两个来源，一是业务原生的复杂度，二是对这种复杂度的误解导致的复杂度——需求准不准、有没有价值。

Vibe Coding 做出来的东西常被批评“Demo 可以，一上线就废”，但拿到最左侧去确认需求，远比 PRD 有效。人天然不喜欢读文档，PRD 这类 Paper Work 很难传递完备、准确的信息，才经常有上线后业务方说“这不是我要的”。《人月神话》里讲，软件有一个根本的困难：它是不可见的、不具象的，直到写出来才能被感知。Live Demo 让各方在最左侧就进入真实体验，基于可操作原型得到的反馈，精准度远高于文档。

由此，团队立下两条规矩：所有需求评审都用 Live Demo 进行；所有测试和可观测都由研发在左侧完成。“左移”减少的是需求误解和验证滞后造成的返工，并非消除所有返工；业务取舍和概念治理，仍需要人来承担。

岗位不是设计出来的，是“长”出来的：PDFE 与 ABE

两个左移推行之后，组织结构开始自发变化。测试和运维职责由蒋林泉直接推动并入研发；设计、前端和产品的融合，则是在实践中先做起来的。

AI 写设计和前端代码的能力越来越强。到 Codex、Qoder 这一代工具出现，一份 Design MD 就能完成功能设计，团队的功能设计环节已不再保留独立的设计岗位。前端早先就被要求接体验工单，转型为“体验与前端团队”。于是有产品经理疑惑：“怎么前端也在拿着 Demo 跑客户、与客户确认需求，设计也在这么干，这合适吗？”但在蒋林泉看来，三个岗位本质上都在理解客户需求，技能相互渗透，组织便慢慢融合。

最终，产品、设计与前端工程师三个岗位逐步融合为 PDFE，面向客户对清需求并交付 Live Demo。

Demo 要落地，仍必须连接和改造存量系统。

这里有个问题：产品与研发之间总有分歧，这往往来自对系统约束和历史逻辑的掌握不同。团队因此把隐性约束显性化：后端将 API 和数据结构梳理成 Repo，PDFE 用匹配的 Mock API 和 Mock Data 制作 Demo；客户演示前先与 Mock API“握手”，迭代中对齐约束，落地前再做真实联调，由此形成一个契约。

上述说的是客户侧，同时还有工程侧。

蒋林泉认为后端最核心的架构职责，常常被挤压。在他看来，后端不仅要实现业务逻辑，还要对系统的可变更性、可测试性、稳定性、可靠性、高可用和扩展性负责。于是，团队将架构、后端、测试、运维合为 ABE，让质量责任回到研发源头。

最终，以往的六类岗位归并为 PDFE 与 ABE 两类，岗位类型降到原来的三分之一；两边以 API 契约、数据结构和接口规范做规则化交互，不再依赖人与人反复确认。

这也呼应了《软件设计的哲学》对复杂度的原理解释：复杂度源于依赖与模糊性——岗位收敛减少了交接依赖，契约化交互则让隐性约束变得清楚。

团队新的岗位结构称为 Half-Stack，相比业界追求的 Full-Stack，看起来更合乎现实。

复杂系统，需要统一的“概念字典”

岗位收敛之后，蒋林泉没有把它当作终点。回到《No Silver Bullet》：没有任何一种单一技术能让软件工程效率提升十倍，尤其是对存量的复杂系统，因为本质复杂性无法避免。

业务规则、数据结构、各国法规、各式各样的 Corner Case，是软件存在就必须处理的复杂度。Demo 和编码的成本越下降，业务落地存量系统中的语义冲突反而越快暴露。

同一个原生复杂的东西，在不同组织、不同组件中，很容易被建模成不同的概念。

对此，他举了一个几乎所有企业都有的例子—— “客户”。在销售系统里，客户是联系人；在财务系统里，客户是付款主体；在服务系统里，客户是使用者；在数据仓库里，客户是一个统计口径。系统割裂，概念不一，各自为真。老系统的复杂性大多来自这种腐化：概念不同、接口不同、分支定制不同，每个需求进来都要牵动多个组件、多个岗位，大家说的却不是同一种语言。

蒋林泉的判断是，业务本来已经足够复杂，却没有用一套自上向下的语言和结构去描述，也没有在跨团队之间建立一套结构化、确定性的“字典”——这是绝大部分效率折损的根源。

《人月神话》给出类似“外科手术团队”的办法：对于涉及大结构和核心概念的修改，需要由“主刀医生”式的核心架构师负责，其他角色协助。放到大型软件里，关键不是让所有人共同定义，是由能统筹全局的人建立统一边界，避免协作越多、概念分叉越多。

蒋林泉认为，如果没有一套自上而下的共同语言，跨团队协作只会放大分歧。架构治理的核心因此是 “概念完整性”：定义领域边界、统一业务语义、裁决跨域取舍。

这些共同概念，还要通过 API 契约和数据结构表达出来。用他的话说，先做到“书同文、车同轨”，才谈得上让人和 AI 依据同一套“概念字典”工作。

从概念字典到 SDD：让 Spec 支撑跨组件协作

有了统一的概念字典，才谈得上 Spec-Driven Development（SDD，规范驱动开发）。

蒋林泉团队从 2024 年底就在做这件事，当时称为 Blueprint，还专门做了 Blueprint Studio，要求写码、生码之前先用 Blueprint 对焦，确保概念完备、一致。后来 AI 能力增强，自造的轮子不再需要，用 Qoder、Codex 加几份 MD 就够了，但核心没变：跨 Repo、跨组件，概念必须一致。

很多人以为“AI 来了，写个 Spec 就行”。 可如果每个组件、每个岗位各写各的 Spec，概念彼此不通，Spec 在组件内部有效，一跨组件就失效——而跨组件联调恰恰是最大的开销。 定义如果不能贯穿整个业务，Spec 最终仍会退化成各组件各自开发、再靠人联调的老路。这一部分 AI 解决不了：看到同一概念有两种说法，它会乱猜；两个都不完备时，它还可能编出第三个。

《人月神话》提倡由顶层架构师理清概念，现实中却很难做到：微服务和分布式开发不断派生出不同的东西，架构师不可能审阅每一行代码、每一次变更，结果，同一个概念在局部演化中分叉成不同的定义。

AI 带来了过去没有的治理机会。

以前还原大型软件中的概念与冲突，只能靠人读代码，成本极高；现在可以用 AI 从代码仓库、数据模型、对客文档、界面交互这些“产品事实”中逆向抽取概念，形成经人工确认、持续维护、可校验的共享 Spec，再正向用于产品设计、API 设计、研发测试和文档生成，并与实现同步校验。治理之后，还能通过跨 Repo、跨组件统一的 MD 做概念守护，探测新的分叉并设置门禁。

当然，AI 能帮架构师看清全局的概念复杂度，能提升效率，但不解决根本复杂度。 概念完整性涉及跨域治理和关键取舍，仍只能由具备关键能力和影响力的人类架构师主导。只要想跨岗位、跨组件联合生码，这件事就必须解决。

吞吐提升之后，瓶颈转向了价值本身

按蒋林泉对 CIO 线 AI 实践的回顾，从 2024 年 12 月到 2026 年 3 月，团队有效代码吞吐和端到端交付效率，大致达到原来的 2 到 3 倍。他的另一种表述是：同样一个需求，需要的“人月”降到原来的 二分之一到三分之一。

吞吐上来之后，新的瓶颈随即出现： 需求准不准、质量如何、交付出的软件最终有没有端到端的价值。

2025 年下半年，他就注意到这个问题——需求上得太快，端到端都能交付、都能落地，但做下去可能会出现一堆 DAU 很低的功能，客户痛点不明确，提升的吞吐最终被浪费。

他的应对，是在 PDFE 一侧增加产品评审机制：需求准入时，先在一页纸的 MD 上，按 PR/FAQ 的方式评审需求价值。

PR/FAQ 源自亚马逊的 Working Backwards 机制。产品进入开发前，团队先用一篇面向目标客户的新闻稿，写清要解决谁的什么问题、提供什么价值；再通过 FAQ 厘清关键场景、能力边界和落地条件。在蒋林泉看来，如果目标客户和痛点足够明确，PR 能把产品价值讲清，FAQ 也能回答客户落地时的关键问题，产品才大概率能“闭环到客户的真实使用”。

上线前，用 PR/FAQ 定义客户价值： 目标客户是谁，真实问题是什么，预期结果是什么。找不到真正的目标客户和痛点、说不清如何验证的，就不上。那段时间，大的需求蒋林泉都亲自带着 PDFE 团队逐个 Review，反复追问一句：“你这个最后的客户是谁？”

上线后，验证价值落地： 一看使用渗透率——目标客户中实际使用核心能力的比例，如果宣称为某个角色解决痛点，上线后的 DAU 就应该来自这些人，如果没人用，这份 PR/FAQ 就是失败的；二做价值回访——渗透足够好，再抽样访谈客户，确认问题是否真被解决。

只有这样，才能解决“吞吐提升了，价值却没有提升”的问题。他的落点是：一个知识型组织，最终要对外交付价值，而非交付一堆只是能跑起来的软件。

技能通胀，品味通缩

这一阶段，蒋林泉提出了一个判断：技能通胀，品味通缩。

随着 AI 降低开发门槛，把软件做出来的能力不再稀缺——这是技能通胀。历史上因技能稀缺而形成的组织结构受到巨大冲击，组织不再以技能为中心。与之相对，判断做什么有价值、做成什么样客户最喜欢、什么是好与坏，越来越稀缺——这是品味通缩。

价值将越来越集中在三件事上：识别真问题 ——谁的什么问题值得解决，这要求理解目标客户的真实处境、识别高价值需求；做出好取舍 ——先做什么、哪些不做，按客户价值确定优先级，控制低价值功能的膨胀；把体验做好 ——让客户顺畅地获得结果，打通完整的使用路径，把功能变成可感知的价值。

为此，他在团队文化上鼓励每个角色的 Leader“左移”：面向真实的客户和场景，面向业界同领域的先进实践。不懂真实客户、不懂业务，就不可能有价值判断，也不可能有反馈闭环让人“长出品味”。这也是他三年前就要求前端岗位接体验工单，也是为了让写代码的人亲眼看到，客户怎样使用他们写出来的东西。

这里说的品味，能不能像技能一样被训练出来？ 蒋林泉给了一个观点：AI 会迅速降低技能门槛，但不会自动生成对客户、价值和取舍的判断。品味的上限很难通过统一方法训练出来，个体差异仍然存在；组织更现实的目标，是在每个人现有的基础上，“提高下限”。

提高下限的关键，是让大家更靠近客户，获得更完整的信息，并看到自己采取行动后的真实反馈。能够快速 A/B 测试、及时看到转化结果的业务，更容易像强化学习那样积累判断；如果一个决策三年后才显现结果，反馈就很难准确归因，只能更依赖少数人的经验和直觉。他判断，瓶颈最终一定会落在这里。

所以，当执行越来越便宜，判断什么值得执行，越来越昂贵。 只有补上这一层，增长的吞吐才能真正转化为客户价值。

业务系统开放：让通用智能体进入业务闭环

矛盾又现：个人办公生产力，带不动 E2E 业务效能

如果说产研变革回应的是 AI 编程能力的冲击，那第二段实践回应的，是 2026 年以“龙虾”为代表的通用智能体浪潮。

蒋林泉回忆，这一波来得太迅猛。一开始，处理文档、生成图片、生成报表、写周报、写 OKR，都变得非常简单。但定睛发现，整体业务效能并没有显著提升。这与产研侧的经历指向同一个问题：个人产出提速，并不能自动形成端到端的价值闭环。

原因在于，本地办公和业务系统是割裂的，个人产出没有接入业务作业的闭环。智能体要真正产生业务价值，必须进入业务闭环：读取业务系统里的数据，处理完再写回去，并与他人协同。

从生码到办公，规律相同：局部产出更快了，端到端却没有同步提效。

当智能体开始“轰击”为人设计的系统

对蒋林泉而言，很大压力来自另一件事：员工开始让通用智能体通过 Browser Use、Computer Use，自己去操作业务系统。

于是，问题来了。这些系统原本是为人设计的。智能体打开浏览器、开着机器，以类似爬虫的方式抓页面、填表单，失败就重试，重试又带来更多请求。

他总结了四个现象：

成功率低：智能体依赖抓取页面拿数据、做操作很难，任务反复失败，业务侧也抱怨其成功率和准确率特别低；
Token 消耗大：智能体在任务失败后不断推理和重试，大量 Token 被烧掉；
DDoS 式负载：多个智能体并发操作、反复重试，产生的请求量远高于人工点击，导致多个业务系统被打爆；
安全风险：外围数据被抓取并落到本地后，数据流向难以追踪，日志留存、授权边界和操作审计也难以统一治理。

由此，CIO 线选择通过 Headless MCP，让业务系统面向通用智能体开放。这项准备从 2025 年底开始：业务同学既可以自己使用系统，也可以让自己的通用智能体通过 Harness 来调用业务系统。

先统一业务概念，再规模化开放 MCP

很多企业在讨论“把系统开放给 Agent”时，关注的是接口。蒋林泉的第一原则却回到了产研部分反复强调的 概念一致性：如果系统之间的概念不一致，开放出去让智能体编排，只会制造更大的混乱。

这里，还是用“客户”的例子。

销售、财务、服务、数仓各有各的定义，是“多个局部真相”。直接通过 MCP 开放，跨系统调用是方便了，但 Agent 的组合调用也放大了影响——表述流畅，口径却不一。 后果有三重：错误规模化，一次错误被并行复制；信任被透支，高质量的形式掩盖了错误；反馈回路被污染，错误输出回写后又生成新的错数据。

他举了一个真实问题：公司内部曾反馈某个产品的商业化配置速度太慢，要两个月才能配好。但是，如果真的直接交给 Agent，可能永远也配不好，因为它会把混乱加剧。

正确的治理顺序，是从根上减少语义混乱，自下而上分四层： 主数据层，明确标识与关系；业务语义层，明确定义与口径；MCP 接口层，只暴露受治理的语义；Agent 层，依据语义去推理。前两层是治理基础，第三层是受控连接，第四层才是可信应用。

他的概括是：接口解决的是连接，治理解决的是业务语义。

完成左侧的归一和概念梳理之后，在前述原本需要两个月进行商业化配置的场景中，蒋林泉表示，做一个 Skill 大致半天到一天就能搞定。他据此判断，在这类事情上，60 倍提效也有可能。但这并不是组织整体的提效倍数，也不能脱离治理工作单独归因于 AI：有了提效目标，组织倒过来把基础治理做扎实，才是关键。

智能体代办，沿用员工原有权限

对于业务系统开放的原则，在上述概念治理之外，权限边界同样关键：员工直接操作系统界面，与员工委托智能体通过 MCP 访问系统，必须是同一套业务权限——可访问的数据范围一样，可执行的操作一样，必须履行的审批流程也一样。用他的话说，100% 能力开放，不等于突破员工自身的权限边界。

原因很现实：智能体比人可怕，它有能力把一个业务系统的数据全部“拖走”，这只是一瞬间的事。

所以，必须清楚调用者是谁、有没有授权、权限机制是否健全、能否审计。蒋林泉称之为 “开放平台的 4A”：账号（Account）、认证（Authentication）、授权（Authorization）、审计（Audit）。这意味着，智能体一定是被某个具体的人驾驭着访问系统的，它所做的事和犯的错，需要由这个员工来相应负责。

要做到这一点，老业务系统需要大量补课。团队做了大量改造，才让底座跨岗位、跨职能的权限和审计日志真正健全。

“不是有人说的直接把 MCP 开出来就可以了，现实世界里做不到。”在他看来，概念完备性和权限梳理都是脏活累活，需要花巨大的精力。

高频先行，4 个月调用量增长 1000 倍

从阿里云组织视角，希望每个业务团队都 AI Native 化，每个人都用通用智能体办公，包括用它来使用业务系统。于是，IT 部门接到的需求铺天盖地，若一上来要求全部开放，是做不成的。

CIO 线的节奏分三步： 先覆盖 80% 的高频场景，让业务尽快用起来；对事业部的高优先级专项，深入支持关键场景，补齐领域能力缺口；持续迈向 100% 业务系统能力开放。蒋林泉当时提出，希望在该财年前实现 100% 开放。

2026 年 5 月，阿里云的业务系统，正式向所有业务同学的通用智能体开放。

蒋林泉展示了云业务系统 API 调用量的三条趋势线：从 2026 年 5 月开放到当年 9 月的约 4 个月内，通用智能体调用量增长了 1000 倍，并超过人类通过 GUI 交互与一方 Agent 调用量的总和。 一方 Agent，是 CIO 为业务建设并已落地的智能体，这些通用智能体调用依然属于业务同学的 Copilot。当然，这一增长衡量的是调用量，不能等同于业务效能也增长 1000 倍。

他的解读是：过去业务有需求，都要找 CIO 团队实现；现在，财务、风控、销售、运营这些不懂研发的同学，用自然语言就能编排 Agent 调用系统。积压已久的痛点和需求，在他们手上得到了集中释放。

他半开玩笑地套用了一句话：这是业务团队对美好生活的向往，与以往 CIO 落后的生产力之间的矛盾，在通用智能体这里得到了充分释放。

需求爆发背后，是一笔“历史欠债”

当需求释放，大量业务同学来找 CIO 线要 MCP：“我想要一个智能体功能，给我开放某某 MCP。”但与业务一起排查下来，蒋林泉的结论是：之前欠了那么多债。

他认为通用智能体有一个被低估的价值——它调动了业务团队自己去思考能用 AI 做些什么。业务同学自己动手时，想到的痛点往往比较准，与真实痛点是“握手”的。但有意思的是，痛点的解法最终未必是通用智能体。进入真实作业链路后，智能体接入受阻，暴露出的是几类历史的课要补：

流程缺口：关键作业仍在线下流转，业务系统无法形成连续的执行链路。过去，许多线下流程长期依赖人工完成，业务团队也已经习惯这种工作方式，很少将其作为系统需求提交给 CIO 线。AI 出现之后，业务团队开始意识到，这些环节或许可以通过 AI 解决；但要把局部尝试转化为可以正式上线、持续运行的业务能力，仍然需要接入现有系统。于是，那些过去没有被提出的系统需求，开始集中显现。
数据缺口：业务所需的数据虽然已有一部分实现线上化，却分散在不同系统和环节中，标识与口径也不一致，难以建立完整关联。完成一项业务任务往往需要将多处数据拼接起来，但数据彼此分散、标识无法对应，最终仍然无法串联成一条完整的信息链路。
规则缺口：许多审查和判断仍然依赖个人经验，缺少明确、可复用的标准。这些做法长期存在于少数人的线下操作和经验判断中，既没有沉淀到线上系统，也没有转化为可以被持续调用和复用的组织规则，因此还未成为真正的公司资产。

此外，还有 跨域协同的缺口。这些缺口并不是 AI 带来的，但 AI 让业务团队清楚地看到了效率的堵点，并把需求带到了 CIO 面前。 CIO 线的做法是分类补课：先补齐阻碍业务闭环的流程、数据与规则，再让智能体持续执行。

通用智能体探索长尾，一方 Agent 承接高频

随着系统开放，蒋林泉的前置判断是：随着通用智能体的探索，未被满足的长尾需求会集中爆发——把历史上积压已久的需求“炸”出来。

通过分析日志——业务用通用智能体调用 API 的 Pattern、调用最多的需求——他发现，有不少原本应由 CIO 线建设的智能体没有做，或供给不足；而各个领域、各个小部门各自搭建通用智能体，本身是重复建设。于是，要做的事：一旦发现某个需求是跨大部门、甚至全公司的，就把这个 Pattern 抓出来 “一方化”，由 CIO 做成稳定的 Auto-Pilot，以更低的成本、更稳定、更持续地提供服务。

这就形成了一条循环路径：通用智能体负责探索，承接长尾的自动化需求；CIO 线的开发者运营负责识别高频调用，验证哪些是真实有效的需求；再由一方 Agent 产品化，回归工程建设，做成稳定复用的 Auto-Pilot。剩余和新增的合理长尾，继续留在业务团队，由通用智能体承接；主体调用和公司级工作流，则在统一的上下文中稳定执行。

基于这条路径，他认为：通用智能体调用量的激增，很大程度上是压抑多年的痛点集中爆发；当高频痛点被收割一轮、“一方化”之后，这条曲线有可能回落。原因在于，真正维护一个智能体，要规模化服务、稳定运行、持续改进，仍然是复杂的软件工程，他不认为这应由业务团队承担。

长尾业务自主闭环，CIO 聚焦平台与复杂需求

开放之后，CIO 线与业务团队的分工发生了一场变化。

蒋林泉用了一个比喻：通用智能体相当于业务人员的新“坐骑”。过去是业务人员自己与系统交互，现在是业务人员委派智能体调用 MCP。业务目标和责任并没有消失，变化的是人与系统之间的执行方式。

过去，业务需求集中交给 CIO，排期、交接和执行带宽