夜雨聆风
2026 年 7 月，Uber CTO Praveen Neppalli Naga 公布了一组很难被企业管理者忽略的内部实验。
Uber 从公司里挑出约 30 名最熟练使用 AI 的工程师，把他们放进财务、法务、运营、市场、客服、人力资源和采购等业务职能。每名工程师与一位业务专家组成一个 Agentic Pod，只给两周时间：前两天跟岗，第 3 天选择机会，第 4—5 天共同搭建智能体，第 6—9 天让更多同岗位员工验证，第 10 天上线。
Uber 自报的结果很亮眼：覆盖 150 个城市的资本配置分析从 15 小时缩短到 30 分钟；财务节奏报告从 2 天缩短到 10 分钟；营销网站质量检查从 2 周缩短到 50 分钟；客服团队原先积累的 9,000 条人工工作流，开始转向自助自动化。
数字当然会吸引眼球，但这次实验最值得企业研究的，恰恰不是数字。
Uber 把过去发生在软件工程里的 Agent 经验，推入了真实业务。它由此验证了一个更大的判断：企业 AI 改造的最小单元，正在从一个工具、一个岗位、一个任务，转向一条完整的业务流程。
图1：Uber 公开披露的 Agentic Pods 阶段性结果（Uber 自报）
一、Uber 真正换掉的，是 AI 改造的“计量单位”
如果 AI 项目仍按工具数量立项，最终得到的往往是一堆入口；只有按业务流程计算价值，AI 才可能进入经营结果。
很多企业的 AI 项目是这样启动的：采购一个平台，开放一批账号，组织几场培训，再统计多少人登录、生成了多少段文字。工具利用率也许会上升，业务流程却几乎没变。员工用 AI 写完材料，仍要在多个系统搬运信息；AI 给出风险建议，后面还是靠人追审批；报告生成更快，数据核对与跨部门确认仍然占掉大部分时间。
一句话判断：AI 改造的计量单位
这类项目优化的是一个动作，不是业务结果。局部速度提高以后，瓶颈会移动到下一个节点。材料写快了，评审排队更久；数据提取快了，口径确认仍旧反复；客户回复快了，退款、补偿与责任认定仍在不同团队之间转手。
Uber 在公开复盘里说得很直接：最大的收益很少来自自动化某个任务，而是来自围绕 AI 重新思考整个工作流。工作流成为自动化的单位，单项任务不再是终点。
把这句话翻译成企业管理语言，就是：不要只问“这个动作能不能交给 AI”，要问“这条业务流程的结果，能不能被 AI 重新组织”。
二、两周 Agentic Pod，本质上是一场业务流程再造冲刺
Pod 不是一个新部门，它是一种把工程能力、业务经验和流程改造压进同一现场的工作机制。
Uber 的十天安排很值得拆开看。第 1—2 天没有急着做方案，工程师先坐到业务专家旁边，观察每一步实际动作：他打开哪些系统，复制哪些字段，遇到什么例外，会找谁确认，哪些判断没有写在制度里。第 3 天再按规模、重复性、业务影响与数据可得性选择机会。
图2：Uber Agentic Pod 的十天业务流程再造冲刺
第 4—5 天不是工程师关门开发，而是与真正做这项工作的人一起搭建。第 6—9 天也不是做一次漂亮演示，而是交给更多同类岗位验证：换一个人、换一批数据、出现异常时，它还能不能跑？到第 10 天，交付的不是汇报材料，而是一个可以进入真实工作的版本。
这套机制包含了流程再造的关键动作：观察现状、识别断点、筛选机会、设计新流程、共同验证、上线运行。AI 工程师提供快速构建能力，业务专家提供规则、例外与结果责任。两者共同面对的是同一条业务流程，而不是各自完成一份需求文档。
这也是很多企业 AI 中心最容易缺失的一环。中心团队看到的是需求列表，业务现场暴露的却是任务之间的缝隙。真正昂贵的浪费，常常藏在系统切换、重复确认、等待审批、返工补数和异常转派里。
三、“只看流程图无法自动化”，这句话只说对了一半
流程图没有失效；失效的是把流程图当成全部事实。
Uber 强调，复杂业务无法只靠阅读流程图或文档完成自动化，必须理解工作究竟怎样发生。这个提醒非常准确。制度写的是标准路径，员工每天处理的却包含大量例外：客户材料不完整怎么办，两个系统口径不一致听谁的，超过阈值找谁签字，月底来不及走完标准步骤如何处理。
图3：标准流程与真实路径叠加，差距才是 AI 机会
但这不等于流程图不重要。没有流程图，团队容易把某位熟练员工的个人习惯误当成组织流程；没有标准路径，也无法判断哪些动作应该删除、哪些控制点必须保留、哪些例外值得进入规则库。
真正有效的流程发现需要两张图叠在一起：一张是制度、系统和岗位共同规定的“标准流程”；另一张是跟岗、日志与案例揭示的“真实路径”。二者之间的差距，才是 AI 改造最有价值的空间。
流程团队在这里不应该退场，反而要更靠前。它要帮助 Pod 区分四类动作：可以直接删除的浪费、适合规则自动化的稳定动作、需要 AI 判断的复杂节点、必须由人承担责任的高风险决策。这样做出来的不是个人助手，而是一段可治理的组织能力。
四、先用四步自测：你的 AI 到底走进流程多深
不要用“有没有 Agent”判断成熟度，要看 AI 是否接走了一段有输入、有结果、有责任边界的业务流程。
第一步是“在流程旁边问 AI”。员工把材料复制进聊天框，让 AI 总结、润色、翻译或查找信息。它能节省个人时间，但不读取流程状态，也不触发后续动作。
图4：AI 进入业务流程的四个阶段
第二步是“让 AI 先处理一个节点”。系统收到合同后，AI 先抽取字段、识别风险、补全表单，人再决定是否提交。这个节点变快了，前后衔接仍主要靠人。
第三步是“让 AI 穿过多个节点”。AI 可以读取任务状态，调用被授权的系统能力，完成收集、判断、生成与通知，并在关键位置等待人工确认。此时它已经进入流程，但异常处理和运行评价可能还不稳定。
第四步是“形成可控闭环”。流程有明确触发条件、数据入口、业务规则、系统动作、人工确认点、异常退出、运行日志和效果指标。低风险情况自动处理，高风险情况交给责任人，事后可以回放它为何做出这次动作。
大多数企业真正需要跨越的，不是从“没有 AI”到“有 AI”，而是从第二步走向第三步：让单点能力接入流程上下文，开始承担一段连续工作。
五、把 Uber 的结果翻译成一条业务流程，会看到什么
一个时间数字只有落到输入、判断、动作与结果上，才可能成为可复制的流程能力。
以 Uber 公布的“覆盖 150 个城市的资本配置分析从 15 小时降到 30 分钟”为例，公开信息没有披露具体实现细节，因此不能替它编造技术方案。但从流程管理视角，我们至少可以提出一组必须回答的问题。
图5：把时间收益翻译成一条完整业务流程
这条流程由什么事件触发？需要汇总哪些城市的经营数据、预算状态和约束条件？过去是谁收数、谁核对口径、谁形成方案、谁批准调整？AI 能自动完成哪些稳定动作，哪些建议必须由财务与业务负责人确认？数据缺失、市场异常或规则冲突时，流程如何暂停并退回人工？最终输出是分析报告，还是能进入预算调整与经营决策的可执行建议？
这组问题决定了企业是在做“更快的报告生成”，还是在重构“资本配置业务流程”。前者的终点是一份材料，后者的终点是更快、更一致、可追踪的经营决策。
同样的逻辑也适用于合同评审、采购寻源、费用报销、客户投诉和营销投放。AI 只有同时看到流程对象、当前状态、业务规则和授权边界，才能从给建议走向接任务；只有结果被下一个节点正式接住，局部提效才不会被流程重新吃掉。
六、两周能做出东西，不代表两周能完成转型
速度可以证明机会存在，持续运行才证明组织真的获得了能力。
Uber 的公开结果来自两个月内的 16 个 Pod，足以证明这种机制有很强的发现与验证效率。但企业不能把两周冲刺误解为“两周完成规模化转型”。公开信息还没有回答长期维护成本、生产稳定性、跨团队复用率、持续 ROI 和普通员工接手后的效果。
图6：两周试点必须留下可接管的流程资产
这正是试点和组织能力之间的差别。一个优秀工程师与一位资深业务专家可以快速做出原型，规模化以后却会遇到版本变化、权限调整、业务规则更新、异常案例积累和责任人变动。如果每一次变化都要把原团队重新叫回来，Pod 只是高水平项目制，没有变成企业能力。
因此，每个 Pod 在上线之外还要交付一套可接管资产：流程边界、输入输出、规则与例外、系统入口、测试样例、人工确认点、运行指标、责任人和更新机制。能复用的判断沉淀成流程 Skill，能稳定执行的动作开放成系统能力，失败案例进入评测集。
Pod 的价值不是永远替业务跑，而是帮助业务第一次把隐性经验变成可以持续运行的流程资产。
七、AI 一旦进入业务流程，治理就不能留到最后
企业最需要控制的不是 AI 会说什么，而是它以谁的身份、在什么条件下、对哪个业务对象做了什么。
在业务流程里，生成一段错误文字和错误修改一笔预算，不是同一种风险。AI 能读取什么数据、能调用什么系统、能把任务委派到哪里、哪一步必须等待人工确认，都要在设计流程时确定。
图7：AI 进入业务流程后的六个治理问题
Uber Engineering 在智能体身份与访问控制的公开文章中，提出了可验证的智能体身份、完整委派链、动态访问控制、人工介入、统一策略执行、监控和审计。把这些技术原则翻译成管理动作，就是给每一条 AI 流程回答六个问题：谁发起，AI 代表谁行动；它能读什么、能写什么；哪些条件允许自动执行；哪些结果必须有人签字；出现异常如何暂停或撤回；事后能否回放全过程。
企业不必让所有节点都自动化。更稳妥的设计是让低风险、高频、规则相对清晰的动作先自动跑，把不可逆、高金额、对外承诺和责任重大的判断留给人。治理不是给 AI 降速，而是让企业敢于把更多真实工作交给它。
八、Agentic Pod 是启动器，业务流程能力才是终点
真正可规模化的成果，不是做过多少个 Pod，而是留下多少条可复用、可治理、能持续创造结果的业务流程。
Uber 的实验给企业管理者一个很具体的提醒：AI 转型不能只由技术部门在远处设计，也不能把压力全部推给业务员工自己摸索。最有效的起点，是让懂构建的人和承担业务结果的人进入同一现场，围绕一条真实流程共同工作。
但组织最终不能停在“派高手救火”。流程负责人要成为业务规则与流程边界的维护者，业务专家要从亲自处理每个动作，迁移到确认目标、处理异常和承担关键判断；技术团队则要把一次性原型转成稳定的系统入口、权限体系与运行底座。管理层的指标也要从账号数、调用量，换成流程周期、返工率、异常率、人工接管率和业务结果。
如果你准备复制 Uber 的做法，可以先挑一条低风险、重复度高、数据可获得、两周内能验证结果的业务流程。让一名 AI 构建者、一名业务专家和一名流程负责人组成最小 Pod。前两天只观察，不急着做；第三天选出真正值得改造的断点；接下来共同搭建、多人验证，并把权限、日志、人工确认和异常退出一并写进流程。
两周以后，不要只问“Agent 做出来没有”。去看员工是否少了一段重复搬运，流程是否少了一次无价值等待，责任人是否更早拿到可判断的信息，组织是否留下了一份下一次还能复用的流程能力。
AI 转型的分水岭，不是谁先拥有更多智能体，而是谁先把业务流程变成智能体能够安全接手的组织能力。
如果你正在规划企业 AI 试点，可以找我领取《两周业务流程 AI 改造冲刺表》。它会帮助你确定试点流程、Pod 角色、十天节奏、风险边界和验收指标。也欢迎把这篇文章转给正在讨论“AI 到底怎么落进业务”的同事。
