# AI Workflow Owner：企业正在如何把 AI 变成组织能力

这组文章写到第五篇时，结论已经越来越清晰了。

AI 可以让人更快做出过去做不到的东西，但产出增加不代表人真正变强。即使个人确实借助 AI 扩大了能力，团队也不会自动获得同样的提升。个人工作流只有进入代表真实目标的业务流程，结果能够被验证，也能够被其他人继续使用，才会逐渐成为组织能力。

前面几篇文章里，我把负责这件事的人称为 **AI Workflow Owner**。

这个名字最初主要来自逻辑推演。模型能力越来越强，编码门槛也在快速下降，但业务问题不会因此自动变得清晰，数据口径、权限边界、结果验证和异常恢复也不会凭空消失。这些复杂性既不可能全部交给模型，也没有必要平均分给每一位普通员工，组织里必然需要一部分人集中承担。

最近业界发生的一些事情，让这个判断开始从推演变成可以观察到的组织实践。OpenAI、TCS、NTT DATA、GitHub 和 Cadence 使用了不同的名称，也处在产业链的不同位置，但它们正在解决同一个问题：**由少数人深入理解业务和系统，把 AI 的不确定能力放进可以运行、验证和持续改进的工作流，再把成熟能力交给更多普通用户。**

它们未必会使用 AI Workflow Owner 这个名字，但这份工作已经真实出现了。

## 模型越强，企业越需要有人进入现场

AI 早期有一种很有吸引力的想象：模型能力足够强以后，企业实施和软件服务会逐渐消失。客户只需要把需求告诉 AI，系统就能理解业务、连接数据、生成应用，并自行处理后续变化。过去需要顾问、产品经理和工程师共同完成的工作，似乎都可以被压缩成一次自然语言交互。

最近企业的实际动作，却在走向另一个方向。

OpenAI 成立了独立的 Deployment Company，从大约一百五十名 Forward Deployed Engineer 和部署专家起步，并投入超过四十亿美元扩大这项业务。它公开描述的典型项目，不是先把一个通用 Agent 交给客户，而是由 FDE 进入企业，找到少量最值得投入的工作流，再把模型接入客户的数据、工具、控制机制和业务流程。[1]

几乎同时，印度最大的 IT 服务公司 TCS 宣布，计划让大约百分之一到百分之一点五的员工成为 FDE。按照现有员工规模计算，大约是五千九百到八千九百人。TCS 对这类角色的解释很直接：他们需要进入客户环境，理解原有系统和数据流，再把 AI 能力真正接进去。[2]

OpenAI 拥有前沿模型，TCS 拥有庞大的企业交付体系。两家公司处在产业链的不同位置，最后却都把大量资源投向了类似角色。**模型能力增强以后，企业没有发现最后一公里自然消失，反而发现最后一公里正在成为主要工作。**

原因并不复杂。模型可以读懂一份流程说明，却不知道组织真正愿意为什么结果承担责任；它可以连接数据库，却不知道几个部门为什么对同一个指标使用了不同口径；它也可以迅速生成一条自动化流程，却不知道某个看似重复的人工确认，实际上承担着风险分摊和权力制衡的作用。

过去企业实施的重点可能是写代码、配置系统和迁移数据。AI 降低了这部分实现成本，却把另一组问题推到了前面：哪个回路值得关闭，哪些信息可以进入模型，结果怎样验收，什么时候必须让人接管，系统运行一段时间以后又该如何继续修正。

**AI 没有消灭工程，只是让工程的主要对象从代码实现逐渐转向了业务流程。**

## 真正进入生产环境的 Agent，从一项具体工作开始

OpenAI 最近发布的 Presence，更直接地展示了这种变化。

Presence 仍然被称为企业 Agent 产品，可以用于客服、销售和内部服务，但它的实际部署方式并不是为企业创造一个能够自由行动的数字员工。每次部署都从一项具体工作开始，例如处理账单问题、协助保险理赔或者解决员工 IT 请求。系统只向 Agent 开放完成这项工作所需的知识和业务系统，企业则要提前确定哪些动作可以自动执行，什么时候需要审批，出现什么情况以后必须转交人工。

在这套产品里，Agent 外面还有 SOP、政策规则、动作权限、模拟评测、生产监控和人工接管。Codex 可以根据真实会话和升级案例提出修改，但这些修改要先经过测试和批准，才能进入生产环境。复杂场景仍然由 OpenAI 的 FDE 和系统集成商参与落地，Presence 目前也没有成为普通企业可以自行配置的自助式产品。[3]

这和“每个人拥有一个 AI 同事”的想象相距很远。

在那种想象里，组织把人的岗位复制一遍，再放入一个能够自主理解任务的 Agent。它可以叫 AI 客服、AI 销售、AI 分析师或者 AI 产品经理，管理者只需要给它一个目标，然后等待结果。

Presence 更接近一套生产系统。AI 只负责其中需要语言理解和动态判断的部分，外部系统负责限制权限、检查结果和管理变化。**它不是被放进组织图里的另一个人，而是被放进业务流程里的一个智能节点。**

这两种产品形态背后，是两套完全不同的组织观。把 AI 当作同事，组织会不断追问它能不能独立承担一个岗位；把 AI 当作系统，组织首先会判断哪一段流程值得改造，再决定人、模型和确定性程序分别应该站在哪里。

前几篇文章里，我一直倾向于后一种理解。AI 最有价值的位置未必是模拟一名人类员工，而是连接数字世界里的数据和流程，并在关键节点请求人类补充现实判断。Presence 的产品形态说明，即使最有能力推动通用 Agent 叙事的模型公司，真正进入企业生产以后，也开始采用更加克制的方式。

企业最终需要的不是一段看起来聪明的对话，而是一项能够长期运行，并且在条件变化以后仍然可以被管理的工作能力。

## 规模化不等于给更多人发账号

NTT DATA 最近公布的 Codex 案例，提供了另一个观察角度。

这家公司已经把 Codex 扩展到大约九千名技术与非技术员工。公开材料中最醒目的成功案例，是用 Codex 完成一项复杂系统事故分析，把原来五名资深工程师需要三天完成的工作缩短到三十分钟。这个数字来自 OpenAI 和客户共同选择的成功案例，当然不能代表九千名员工的平均提效水平。[4]

真正值得研究的是，NTT DATA 怎样把一次成功逐渐变成组织能力。

它没有把 Codex 账号发下去以后，就等待员工各自摸索。公司建立了内部 CoE，负责技术验证、使用场景、培训、知识资源和运行环境，同时规定哪些数据可以使用，能够连接哪些系统，网络怎样管理，应该采用什么沙箱模式，自动化可以推进到什么程度，又有哪些结果必须由人检查。

当某项自动化经过验证以后，它还会被包装成 Skills，让其他团队直接复用。

这正是前面所说的：

> **少数人建设轨道，多数人在轨道里使用。**

普通员工当然仍然可以探索 AI，也可以尝试制作小工具、分析 Excel 或整理文件。一线探索是发现新场景的重要来源，没有必要被完全取消。但是，一项能力一旦要进入团队和组织，就不能永远依赖某个人的提示词、个人电脑和临时经验。

它需要有人判断这个场景是否值得继续投入，把输入、输出和异常路径逐渐固定下来，决定数据和权限应该开放到什么程度，最后再把一次成功变成其他人可以稳定调用的流程。

CoE 是承载这些工作的组织结构，FDE 是更靠近一线的实施角色，AI Workflow Owner 描述的则是它们共同承担的核心责任：**把个人使用 AI 的偶然成功，转化成组织能够吸收的能力。**

## 专业 Agent 有效，是因为它继承了专业工程体系

如果只看 OpenAI 和 Codex，仍然容易把 AI Workflow Owner 理解成软件行业的新分工。Cadence 最近发布的 AuraStack，则提供了一个更接近传统专业工程的案例。

AuraStack 面向 PCB 和先进封装设计。工程师可以给出设计目标，系统再调用 Cadence 长期积累的规划、布局、可制造性和多物理场分析工具，协调电气、散热和机械约束，并把候选方案不断送回专业工具验证。[5]

它被命名为 AI Super Agent，但真正承载专业能力的并不是这个名称，也不只是背后的模型。

芯片和 PCB 设计早已有成熟的数据格式、设计规则、仿真工具和签核流程。一个方案是否满足信号完整性、功耗、散热和制造要求，最终要由这些外部系统确认。Agent 可以扩大搜索范围，也可以减少工程师操作工具的时间，但它很难把一个没有通过仿真和规则检查的结果，仅凭语言包装成已经完成的设计。

Coding Agent 之所以较早表现出稳定价值，也有类似原因。它继承了软件工程长期建设的代码仓库、测试、CI、Diff、Review 和回滚机制。AI 生成代码以后，外部世界仍然有一套方法检查它能否运行，是否破坏了原有系统。

Cadence 的案例说明，这条路径也会出现在其他行业。一个行业越早把工作对象、工具链和验证方式工程化，越有条件接住 AI。

因此，真正的分界并不在编程任务和非编程任务之间，而在于：

> **一项工作有没有被工程化到足以接住 AI。**

PPT 和自由数据分析的问题也出在这里。它们不是天然没有价值，而是很多场景缺少足够硬的验收标准。一份 PPT 看起来更加完整，并不能证明它推动了正确决策；一份数据报告给出了明确结论，也不能证明数据口径和分析方法没有问题。

没有外部验证，AI 只会让产物更快出现。结果只有进入一套能够发现错误的体系，Agent 才真正进入生产。

## AI 越普及，能力边界越需要集中治理

GitHub 最近的产品变化，展示了另一种看起来有些矛盾的趋势。

Copilot 正在进入桌面应用、命令行、IDE 和云端任务，开发者可以接入更多插件、MCP Server 和模型，个人能够调用的能力越来越强。与此同时，GitHub 也把这些入口纳入企业统一管理。管理员可以集中规定员工能够使用哪些插件和插件市场，是否可以绕过命令、文件和 URL 访问前的批准提示，以及是否默认采用自动模型选择。这些设置会覆盖员工本地配置，并在不同 Copilot 客户端中统一执行。[6]

**AI 越普及，治理反而越不可能分散给每个人。**

员工可以选择怎样表达任务，也可以在允许范围内选择工作方式，但插件来源、外部网络、危险动作和数据权限不能由每个人自由决定。否则，组织得到的不会是一套可以持续建设的 AI 能力，而是一批拥有不同模型、不同工具、不同记忆和不同安全边界的私人系统。

这也让“每个人配置一个 Agent，再让这些 Agent 彼此协作”的组织想象显得更加早期。真实企业正在做的恰好相反：用户入口越来越自然，底层能力却越来越集中管理。

普通成员不需要变成 Agent 管理员。他们需要知道自己能够调用哪些组织能力，结果应该怎样使用，又有哪些判断仍然必须由自己负责。Workflow Owner 设计和维护具体流程，平台团队统一提供模型、执行环境、权限和日志。**个人的自由主要存在于问题和判断上，而不是系统权限上。**

## AI Workflow Owner 是一组责任，不一定是一个新头衔

最近这些案例当然都有厂商宣传成分。OpenAI 希望销售 Presence 和 Codex，Cadence 希望证明自己的 Agent 平台领先，TCS 也需要向市场解释 AI 不会让传统 IT 服务失去价值。某个被挑选出来的成功案例，不能证明所有 Agent 项目都能获得相同回报。

但这些公司的真实投入方向仍然很有参考意义。它们正在建设 FDE、CoE、专业工作流和统一治理，而不是只发布一套提示词课程，要求所有员工自行寻找价值。

这说明 AI Workflow Owner 未必首先以一个统一职位名称出现。承担这份工作的人可能叫 Forward Deployed Engineer，也可能是 CoE 成员、业务流程负责人、领域架构师、AI 产品经理、平台工程师或者专业软件实施顾问。

名字并不重要。关键在于，有人持续承担这组责任：从业务目标出发，判断哪个问题值得由 AI 关闭；把自然语言里的目标翻译成输入、状态、规则和验收条件；决定哪些步骤应该由确定性程序完成，哪些步骤需要模型判断；管理数据范围、工具权限和人工审批；系统运行以后，再观察错误、返工和成本，把失败样本继续沉淀进流程。

**Workflow Owner 拥有的不是模型，也不是某一条提示词，而是一种能够持续产生结果的工作方式。**

这也是他与普通 AI 重度用户最本质的区别。普通用户关心这一轮生成得好不好，Workflow Owner 关心下一轮能不能继续成立；普通用户拥有一次产物，Workflow Owner 对整个回路负责。

## 组织真正需要的，不是更多 AI 用户

回过头看，这些企业实践恰好把前五篇文章里的几个判断连接了起来。

AI 可以让人快速做出过去做不到的东西，但企业不会因为产物更多就自动变强，所以它们开始建设评测、验证和生产监控。普通用户未必需要亲自管理一个通用 Agent，所以真正的企业产品开始从具体工作出发，把复杂性藏进 SOP、权限和升级路径。个人变强不会自然让团队变强，所以企业建立 CoE 和 Skills，把个人成功重新包装成团队可以吸收的流程。编码门槛降低以后，工程能力反而更加重要，所以 OpenAI 和 TCS 都在建设能够同时理解业务与系统的 FDE。

这些变化说明，AI Workflow Owner 并不是为了迎合 AI 热潮创造出来的新概念。它是模型能力进入真实组织以后，由那些无法被模型自动消灭的责任逐渐汇聚出来的角色。

这也让我更加确信，企业 AI 转型不应该从“让所有人多用 AI”开始。

员工多用 AI，可以帮助他们熟悉能力边界，也可能发现新的工作方式，但使用量本身不是组织目标。调用次数、活跃人数和 Token 消耗甚至可能鼓励员工生产更多不必要的中间产物，让局部的满足感进一步掩盖系统成本。

组织应该从自己的核心目标出发，找到那些长期存在高成本、等待、重复判断和信息断点的回路，再把最合适的部分交给 AI。这个过程需要探索，也需要逐渐扩大边界，但每一条真正进入生产的 Workflow，都应该拥有明确的负责人。

**未来的组织未必会为每位员工配备一个拟人化的数字同事，更可能拥有越来越多由 Workflow Owner 维护的智能生产环节。**

模型隐藏在这些流程内部，普通员工甚至不需要知道它调用了几个 Agent、消耗了多少 Token，又使用了哪一种 Harness。他只需要知道这项能力能否稳定解决问题，结果中的哪些部分需要自己判断，出现问题以后又由谁负责恢复。

AI 的普及最终可能不会表现为所有人都成为 AI 专家。它更可能表现为，组织里出现了足够多能把 AI 变成系统的人，然后其他人开始自然地使用这些系统。

这条路没有“人人拥有数字员工”那么浪漫，却更接近企业正在真实投入资源建设的未来。