夜雨聆风
前面写了一篇《企业级 AI 平台选型》，聊的是一个企业级 AI 平台该具备哪些能力。这一篇接着往下走，聊一个更具体、也更容易吵起来的问题：平台搭好了，到底该交到谁手里？说得再直白点：它的使用者，该是 IT 的开发者，还是业务侧的人？
两种说法都有道理。说该交给 IT 的，理由很硬：Agent 是会动手的系统，接数据、调接口、改主数据，一旦出错，是真的去做了不该做的事，这种活儿当然得专业的人来建。说该交给业务的也有道理：真正知道哪个环节最折磨人、哪个痛点值钱的，是天天泡在业务里的人。
我自己也做 AI 产品，这个问题每天都摆在面前。我现在的看法是：这个问题，问法本身就有点窄。它默认一个平台只能有一类主人，可真实情况是，一个企业级 AI Agent 平台天然要服务好几类人，他们之间有分层、有主从。
所以与其问"该交给 IT 还是业务"，不如换一个问法：谁坐驾驶位，谁管底盘、交规和运营？
一、先给一个不和稀泥的结论
我不想用"都重要"糊弄过去。如果一定要指出谁坐驾驶位，我的答案很明确：
建 Agent、产生业务价值的主力，应该是业务骨干；IT 要从"主要构建者"，退成底座、治理、深水区和运营推广的托底者。驾驶位交给业务，但底盘和交规，永远是 IT 的。
下面把这件事一层层拆开。
二、为什么坐驾驶位的，是业务骨干
先说为什么驾驶位该给业务。这一点，我这两年在客户那边、在公司内部，已经被印证过好几轮。
第一，价值靠一线试，不靠交付。 我在《选人与赋能》里写过一个观察：公司内部办过几场 AI 大赛，跑出价值的，多是既肯花时间折腾、又真正懂业务的人；写代码最快的资深开发、号称"AI 原生"的年轻人，反倒没几个走在前面。Agent 的难点从来不在调工具，工具的上手成本已经被压得很低了。难点落在三件事上：判断该让它做什么、判断它产出对不对、想清楚差的一截怎么补。这三件事全靠业务密度，IT 替不了。
第二，外部的权威研究，给的是同一句话的英文版。 MIT 的 Project NANDA 在 2025 年的《GenAI Divide》报告里，把成功的组织画了一条线：decentralize implementation authority but retain accountability。意思是把实施权下放到一线、交给离业务最近的人，同时把问责权牢牢收在手里。翻译成八个字：业务去建，IT 去管。同一份报告里还有一组对比：从专业厂商采购并建立合作的项目，落地成功率约 67%，纯内部自建只有它的一半。
第三，行业的组织答案，也没有押给任何单一一类人。 Gartner 的数据是 84% 的公司已经组了 fusion team（融合团队）：业务伙伴、开发者、AI 专家一起把一个试点从头带到尾；领跑的公司在试 tiny team（微型团队），小到一个业务加一个技术。这个信号值得注意：答案落在业务跟技术的配对上。而在这一对里，出场景、判对错、补缺口的主导权，在业务这一侧。
讲到这儿，我想把"业务"这个词拧细一点，因为它太容易被笼统地理解。
我说的驾驶位主力，是业务骨干，也就是在某个领域干了好几年、对业务有深度、又肯折腾新工具的一批人。请注意，业务骨干不等于"技术型业务人员"。判断一个人能不能当构建者，看的是他懂不懂业务、肯不肯折腾，技术功底在今天已经不是门槛了。
为什么敢这么说？因为业务骨干这个群体本身，跟几年前已经不一样了。他们的 IT 基础、对 AI 的认知，普遍都不差。很多业务骨干自己就在用各种 AI 工具处理日常工作，对"AI 能干什么、不能干什么"的体感，有时候比 IT 还准。
至于 ITBP（IT 业务伙伴）和业务里几个技术型骨干，他们的位置，是第一批点火的人、是加速器，别把他们当成闸门。先让他们做出几个看得见的东西，再用这几个例子去点燃更多人。我在《选人与赋能》里说过，五个人凑在一起就能互相点火，孤军奋战大概两三个月热情就烧光了。说到底，构建者和消费者之间并没有一道固定的墙，更像一条连续的谱：一个原本只会用 Agent 的人，用着用着，某天发现自己也能搭一个，他就从消费者变成了构建者。一个好平台要做的，就是不停地把人往这条谱的上游"拉"。
但这里有个绕不开的前提。业务骨干能不能真的自己建起来，真正的决定因素是平台把门槛降到了哪里，跟他聪不聪明关系不大。这就要说到下一个问题。这也是我憋了很久、必须说清楚的一件事。
三、一个前提：平台得让业务"配意图"，别逼他们配 Workflow
为什么过去这么多年，喊了无数遍"让业务自己建"，真正建得起来的还是少数？
我的判断是：不能怪业务，要怪平台。过去号称"好上手"的平台，绝大多数是 Workflow（工作流）配置式的。它确实把门槛从"写代码"降了下来，但降到哪儿了呢？降到了"定义变量、拖拽节点、连线走流程"。
这只是把编排的负担，从 IT 的肩上原封不动挪到了业务的肩上，门槛并没有真降。一个业务同事想做一个订单异常处理的 Agent，看着流程不复杂，真动手就卡住了：先判断订单状态、配条件分支，再查库存、查物流、查支付，每个接口返回的结构都不一样，任何一步出错还得想清楚是重试、跳过还是通知谁。这哪是"拖拽"能解决的，是系统设计思维的事。
我在《Workflow 还是 Agentic》里把这件事说得更重：让业务大量去配 Workflow，本身是一种回退，甚至是路线上的自相矛盾。做 Agent 的初心，本来就是让 AI 替我们去判断、去执行、去适应变化；结果却要业务自己配一堆确定性的流程去兜底，Agent 的意义就被抽空了一半。
门槛到底该降到哪儿？降到业务只需要描述"意图和边界"。我想让它干什么、不能碰什么、什么情况要找人，把这几件事讲清楚，剩下的编排交给模型，具体每一步怎么做交给平台封装好的工具和技能（Skills）。这才是真 Agentic（智能体驱动）的样子，也是门槛真正落到业务够得着的地方。
这不是空想。我们多半都在 Claude Code、Codex 这类工具上见过这种范式：不用拖流程、不用配节点，把想做的事用人话讲清楚，剩下的让它自己拆解、自己执行。它们今天主要面向开发者，可"描述意图、机器去编排"这套路子，正是企业级 Agent 平台该带给业务骨干的东西。门槛降到"说人话"这一层，业务骨干才真的接得住。
落到选型上，这里有一个特别实用的判据，我在上一篇也提过：判断一个平台到底有没有真把驾驶位交给业务，就看它是真 Agentic，还是"披着 Workflow 外壳的 Agentic"。如果产品里还堆着大量"定义变量、拖拽流程"的配置项，就要多留个心眼。它短期看着好学，长期是平台的包袱，也是业务的负担。
四、IT 让出驾驶位，但有四件事一件都不能让
说到这儿，可能有人会觉得：照这么说，IT 不就被架空了吗？
恰恰相反。驾驶位让出去，不等于 IT 退场，IT 的活反而更重了，而且更硬。我把它归成四件事，一件都不能让。
第一件，底座。 原子能力层、AI 网关、统一入口。没有这一层，所谓"业务自建"很快会变成影子 IT 的升级版。我在《影子 IT》里写过一个真实案例：一家制造业客户，供应链的一位员工用 AI 工具做了个系统，调了公司核心的供应链数据，部署到公共云上还没做鉴权，结果友商通过流转的链接看到了一堆采购价格和库存。最让我警惕的，倒不是他做错了什么。他觉得自己在提效，意图也没问题。真正可怕的是，整个流程里没有任何一个环节能拦住他。底座要做的，就是让业务在一条铺好的、安全的路上走，少去各自开荒。
第二件，治理，而且必须是差异化的治理。 这一条有个很新的权威信号值得记下来。Gartner 在 2026 年 5 月专门发了一篇判断：对所有 AI Agent 套用一套统一的治理，会直接导致企业级 AI Agent 失败；并预测到 2027 年，40% 的企业会因为治理缺口（往往是上线之后才暴露）而把 Agent 降级或下线。这句话的分量在于：治理不是"管得越严越好"，而是要按 Agent 的风险分级、按层给不同的强度。一个业务搭的内部周报助手，和一个能改主数据、能往外发邮件的 Agent，绝不能用同一套规矩去卡。
第三件，深水区。 不是所有需求都能靠业务配几个 Agent 解决。企业里总有一类应用是复杂的、要长期维护的、对确定性要求极高的，这类东西得真正"开发"出来。我一直主张的节奏是：先用 Agent 在业务一线探，把稳定的逻辑探出来；再用 AI Coding（AI 编程）把这部分逻辑写成代码，落到确定性的引擎上，并且全程以 spec（规格）沉淀意图、留门禁、可追溯。这一层是 IT 的主场，业务帮不上，也不该让业务扛。
第四件，也是我特别想补的一件：推广和运营。
前面三件，讲的都是"把台搭好、把风险兜住"。但只做这三件，其实对 IT 不公平。
我见过不少 IT 团队，吭哧吭哧把底座搭好、把治理立起来，结果呢？业务用得好，功劳是业务的；出了事，板子是 IT 的。搭台的人只承担风险，不显价值，这事儿怎么想都不对劲。
所以 IT 必须把第四件事捡起来：主动推广，加上持续运营。
推广，是 IT 主动去点火。内部培训、Workshop、把"肯折腾 + 懂业务"的 KOL（关键用户）一个个发掘出来。这套动作，其实就是我在《选人与赋能》里说的"识别、激发、再赋能"。这里有个反直觉的经验：别一上来就组织大课培训。这种人是自己玩出来的，给他们一份五分钟能跑通的样例，比讲两小时的课管用得多。国外把这套东西沉淀成了 AI Center of Excellence（AI 卓越中心），里面 early champions、role-based training、playbook 这些，本质都是同一件事：有人专门负责"让平台被用起来"。
运营，是让价值变得看得见。运营跟推广、治理相辅相成：治理负责看清"谁在用、用了多少、花了多少"，运营在这个基础上，进一步回答"值不值、产生了多少业务价值"。平台工程领域有一条成熟的共识：把内部平台当成一个产品来做，把使用者当成客户，用采纳率、满意度这些指标来衡量它做得好不好。AI 平台也该这么干。
运营这件事，真正的价值有三层，缺一层都不行。它让工具软件的价值显性化：这套平台到底帮公司挣了多少、省了多少；让业务的价值显性化：哪个场景真的提效了，哪个只是热闹；最后，也让 IT 自身的价值显性化。最后这一层最容易被忽略，但对 IT 最重要。在 AI 时代，IT 想跟老板把自己的价值说清楚，光靠"我维护了多少系统"是说不动的；能说动的，是"我搭的这套平台，业务自建了多少、管住了多少、产生了多少可量化的价值"。这笔账，只有靠运营才能算出来。
我在《AI Agent 运营治理》里讲过一个细节：有企业把模型消耗的账单按部门拆出来之后，业务主管自己就主动下线了一批低频 Agent，理由很朴素："这点用量不值这笔钱。"钱一算清楚，治理自己就发生了。运营做到位，治理就从 IT 一家的事，慢慢变成全公司共同的事。
五、把它落成一张图
把上面四层拧到一起，大致是这么一张分工图：
横向贯穿这三层的，是一套运营体系：推广、使用度量、价值归属。
这张图有两点要特别说明。一是它是动态的：真 Agentic 的平台会不停地把人从下面一层往上一层"拉"，今天还只是用 Agent 的人，明天可能就成了建 Agent 的人。二是价值层的"怎么建"这一栏，写的是"配意图"，拖流程从来不在这一栏里，这是整套分工能成立的根。
六、两个极端，都会死
为了不让"交给业务"被误读成"放手不管"，我把两个极端都点一下，这两条路我都见过有人走，结局都不好。
一个极端，是把所有 Agent 都塞回 IT 排期，或者用 Workflow 配置去兜底。前者是 developer-first（开发者优先）这一派容易掉进去的：LangChain 这类框架、"agents are software"（智能体即软件）的主张，本身没错，它们对的是底座和深水区，错在把"业务的 Agent 也得 IT 来写"。后者是伪 Agentic 的平台干的，表面让业务自建，实际还是把编排塞回给人。两条路殊途同归：门槛没真降，业务还是只能提需求、等 IT 排期，又回到了老路。
另一个极端，是纯放任，没治理、没运营。业务在一个没有底座的平台上各搭各的，结果就是僵尸 Agent 越积越多、安全漏洞防不胜防、影子 IT 改头换面又回来了。更糟的是，没人算价值的账，搭台的 IT 到头来只剩下背锅。Gartner 说"统一治理会死"，这话还有另一面：零治理死得更快。
活下来的，永远是中间这条路：业务在驾驶位，IT 在底盘、交规和运营台。
写在最后
绕了一圈，回到开头的问题：企业级 AI Agent 平台，到底该交到谁手里？
我的答案是：别再纠结"选 IT 还是选业务"，要问"谁坐驾驶位，谁管底盘、交规和运营"。驾驶位给业务骨干，底盘、交规和运营台，留给 IT。
这跟我一直说的"IT 搭台、业务唱戏"是一个意思，只是我想把它拧得更细三处。第一，唱戏的主角是业务骨干这一大批人，而这个群体正在被真 Agentic 的平台持续地、一年比一年更多地拉上台。第二，让他们唱得起来的前提，是平台把建 Agent 降到"配意图"这一层，Workflow 配置只会把他们重新挡在门外。第三，IT 搭的"台"，不止底座加交规，还包括把戏推出去、把票房和口碑算清楚的这套运营。否则搭台的人只担风险、不显价值，这台戏唱不长。
这件事不分甲乙方，也不分谁资深、谁年轻。我们这一代做技术、做数字化的人，都是头一回面对"工具的门槛被压到业务自己就能上手"的局面。考验我们的，其实不是会不会用 Agent，而是能不能想明白：平台该交到谁手里、每个人该站在哪一层、价值又该怎么算清楚。想明白了，再一起把它做出来。
我是徐翔轩，做了18年企业软件。后续会持续聊聊数字化、企业AI、产品商业化和to B经营方面的观察和思考。如果你也在推动数字化，希望这些内容对你有用。
