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

前几篇文章里，我把负责建设 AI 工作流的人称为 **AI Workflow Owner**。这个名字最初来自逻辑推演：模型可以完成越来越多具体任务，企业需要有人选择值得改造的业务环节，规定模型能够使用哪些数据和工具，并对运行结果负责。

我当时还有一个疑问，这会不会只是给几类已有工作换了一个名字。最近几家公司的投入，让这个角色有了越来越清楚的现实原型。

OpenAI 和 TCS 正在扩充直接进入客户现场的工程队伍。NTT DATA 建立内部 CoE，把经过验证的做法整理成 Skills。Cadence 将 Agent 放进成熟的专业工具链，GitHub开始统一管理模型、插件和执行权限。这些公司的位置和做法不同，处理的都是模型进入真实业务以后遇到的问题。

## FDE 正在成为模型与业务之间的接口

AI 早期有一种很有吸引力的设想：客户说清需求，模型完成应用建设，企业实施工作的规模会随着模型能力提高而缩小。但实际上最近几家公司的资源投入呈现出另一种趋势。模型公司和 IT 服务商都在扩大直接进入客户现场的工程队伍。

OpenAI 最近成立了独立的 Deployment Company，从约 150 名 Forward Deployed Engineer 和部署专家起步，并投入超过 40 亿美元扩大这项业务。它公开描述的典型项目，会先由 FDE 进入企业，和客户一起选出少量值得投入的流程，随后完成模型与现有数据和系统的连接。

印度最大的 IT 服务公司 TCS 计划让约 1%—1.5% 的员工成为 FDE。按照现有员工规模计算，大约是 5,900—8,900 人。TCS 对这类岗位的描述非常简明：工程师先了解客户原有的系统和业务流程，弄清数据怎样流动，再设计 AI 的接入方式。

两家公司站在产业链的不同位置，投入方向却非常接近。OpenAI 需要把前沿模型变成客户可以使用的系统，TCS 需要用 AI 改造已有的企业软件和服务。FDE 正好位于模型与业务之间，负责理解现场，再把模型能力组织成一段可以运行的流程。

企业流程很少被完整地写进文档。同一个指标在不同部门可能采用不同口径，看似多余的人工确认往往划定了责任边界，旧系统实际运行的数据流也可能和说明材料不同。FDE 要先弄清这些现实条件，然后决定模型读取哪些信息、调用哪些工具，以及哪些动作交给业务人员确认。

模型大幅降低了开发和配置的成本，企业由此可以把更多精力放在业务选择和流程设计上。哪一段工作值得改造，自动化推进到什么位置，结果怎样验收，出现例外以后任务交给谁处理，这些问题共同决定了一项 AI 能力能否长期运行。

过去，工程师主要把业务要求变成代码。现在，这项工作正在向前延伸：先把模糊的业务要求整理成模型可以参与、组织也可以管理的流程，再完成具体实现。

## Presence 揭示了客服 AI 的真实落地难度

OpenAI 最近发布的 Presence，值得深入研究。

客服是当前 AI 最擅长的企业场景之一。大量工作通过自然语言完成，历史对话和知识库可以成为模型的输入，任务结果也比较容易观察。按照很多人的直觉，这应该是企业最容易大规模使用 AI 的地方。

Presence 展示的却是一套相当复杂的部署方式。

它每次从一项边界清楚的工作开始，例如处理账单问题、协助保险理赔或解决员工 IT 请求。企业先确定这项工作的规则，再开放完成任务所需的知识和业务系统。普通问题由 Agent 处理，涉及审批或超出范围的任务转给人工。

上线前，系统需要在模拟环境中测试不同情况。上线后，团队继续分析真实会话，找到任务失败的位置，并研究哪些问题最终转给了人工。Codex 可以根据这些记录提出修改，新版本通过测试和审批后进入生产环境。

模型在这里只承担语言理解和动态判断。业务规则限定它的行动范围，权限系统控制真实操作，人工人员处理流程之外的情况。知识、系统、规则和审批方式都需要围绕一项具体工作重新组织。

Presence 体现了 OpenAI 对企业 Agent 很深刻的理解。客服 AI 的价值并不取决于模型能否回答一个问题，而取决于它能否识别用户真正遇到的情况，找到正确资料，调用合适的系统，并在权限范围内完成动作。任何一个环节没有处理好，系统都只能停留在对话演示阶段。

这也进一步证明了我在前文中的阐述，真实业务中的 AI 使用，和个人快速做出报告、网页或分析结论，是完全不同的体验。个人产出物很容易带来一种能力已经兑现的感觉，因为结果出现得很快，也足够完整。企业客服会立即暴露所有没有解决的问题：知识是否准确，系统能否连接，动作是否安全，错误由谁处理，结果又怎样进入下一步流程。

即使是在 AI 最擅长的客服领域，企业也要投入大量工作才能把模型变成一套可靠的服务。Presence 的价值就在于，它没有把复杂性藏在“数字员工”的想象里，而是逐项处理这些现实问题。

## NTT DATA 用 CoE 和 Skills 扩大复用

Presence 说明一项 AI 工作流怎样运行，NTT DATA 的案例展示了企业怎样把有效做法交给更多团队使用。

NTT DATA 已经把 Codex 扩展到约 9,000 名技术与非技术员工。公开材料中最醒目的案例，是用 Codex 完成一项复杂系统事故分析，把原来 5 名资深工程师需要 3 天完成的工作缩短到 30 分钟。

而更应该关注的是这项能力后面的组织方式。

NTT DATA 建立了内部 CoE，由这支团队筛选值得投入的场景，划定数据和网络范围，并确定自动化能够推进到什么程度。需要人工检查的位置会被提前写进流程。

某项做法经过验证以后，团队会把它包装成 Skills，让其他员工直接调用。后来使用这项能力的人不必重新研究提示词，也不必自己处理系统连接和权限设置，只需要按照已经定义好的方式提交任务。

这种方式保留了一线探索的价值。员工可以从自己的工作中发现机会，CoE 负责判断哪些做法值得继续建设。个人经验经过整理和验证以后进入公共工具，其他团队便可以直接复用。

FDE 更靠近客户和具体项目，CoE 负责企业内部的筛选、治理与推广。它们共同完成了一项关键工作：把某个人偶然跑通的方法，改造成其他人能够稳定使用的流程。

这也解释了为什么企业 AI 的规模化很少只是增加账号数量。真正的扩展发生在经验被写进流程以后。输入方式、系统连接、权限范围、验收方法和异常处理逐渐固定下来，一项个人能力才会成为组织里的公共能力。

## Cadence 把行业经验写进 AI 工作流

Cadence 最近发布的 AuraStack，提供了一个很有代表性的专业工程案例。

AuraStack 面向 PCB 和先进封装设计。工程师给出设计目标以后，系统会调度 Cadence 已有的专业工具完成规划和布局，随后进行可制造性检查，并通过仿真确认信号完整性、功耗和散热是否符合要求。

Cadence 在这个领域积累多年的经验，才是 AuraStack 最重要的基础。这些经验既存在于工程师对问题的理解中，也已经被写进数据格式、设计规则、仿真工具和签核流程。模型获得的并不是一套通用的设计能力，而是调用和组织这些专业能力的新方式。

业务方长期形成的深刻洞察，是 AI 落地最重要的优势之一。很多行业知道什么问题值得解决，也知道怎样判断结果是否可靠，只是这些能力过去分散在专家经验和复杂工具中，使用成本很高，复用范围也受到限制。

AI 可以改变这种状态。工程师通过自然语言表达目标，Agent 再调用已有工具完成后续工作，原本只有少数专家熟练掌握的方法就有机会被更多人使用。专业经验没有被模型替代，而是通过新的交互方式得到更大范围的复用。

这种复用也扩大了原有优势的价值。Cadence 的设计规则和仿真工具过去主要帮助工程师完成单项设计，现在它们还可以成为 Agent 搜索和验证方案的基础。积累越深，工具越成熟，AI 能够组织和调用的专业能力就越丰富。

Coding Agent 较早进入生产，也依赖相似的工程基础。AI 生成的代码进入仓库后，需要通过测试和 Review，合并后的问题可以通过版本记录定位和回退。模型输出处在一套能够发现错误的机制中，它才能逐步承担更多任务。

一个行业对工作对象定义得越清楚，验证工具越成熟，长期积累的专业经验越有机会通过 AI 被放大。AI 在这里创造的价值，不只来自生成速度，也来自它把原本难以复制的行业能力变成了可以反复调用的工作流程。

## GitHub 把个人工具纳入企业治理

GitHub 最近的产品变化补充了另一个关键条件。

Copilot 已经进入桌面应用、命令行和 IDE，并能够在云端执行任务。企业管理员可以统一规定插件来源、高风险操作的审批方式和模型选择策略，这些规则会覆盖个人配置，并在不同客户端中保持一致。

当 Agent 只能生成一段文字时，风险主要集中在内容本身。当它开始修改文件、访问外部网络或操作业务系统，企业就需要清楚地规定它可以做什么，也要保留可以追溯的记录。

员工负责表达任务和判断结果，Workflow Owner 维护具体流程，平台团队管理公共运行环境。模型访问什么数据，能够执行哪些动作，由组织统一规定。这种分工让个人可以自然使用 AI，也让企业能够持续管理风险。

GitHub 的做法说明，个人入口和组织治理可以同时存在。员工不必理解底层模型怎样路由，也不必各自搭建插件和权限体系。他们在统一边界内使用工具，组织则继续建设可以共享的底层能力。

## AI Workflow Owner 正在成为企业 AI 的关键角色

这些案例里没有统一的职位名称。OpenAI 和 TCS 使用 FDE，NTT DATA 依靠 CoE，专业软件公司可能把相关职责交给领域架构师、产品团队或实施工程师。

具体岗位可以不同，工作内容已经相当清楚。有人要从业务目标中选择适合 AI 的任务，把任务写成可以执行和验收的流程，配置数据与工具权限，并根据运行中的失败不断修改系统。

我把承担这组工作的角色称为 **AI Workflow Owner**。

他负责的是一条工作流，而非某一个模型或某一条提示词。模型版本会变化，调用工具会增加，业务规则也会调整。Workflow Owner 要把这些变化纳入同一套流程，保证结果稳定，并为异常留下明确的处理方式。

企业 AI 转型也可以从这里开始。组织先寻找那些长期存在重复操作、等待和信息断点的业务环节，再选择其中适合模型参与的部分。试点完成以后，用结果质量、处理时间和业务成本判断是否扩大范围。

员工使用 AI 的人数和 Token 消耗可以反映探索范围。组织能力则体现在更具体的地方：任务拥有明确输入，系统获得必要权限，结果可以验收，出现问题时能够找到负责人，其他团队也能直接复用。

未来很多员工接触到的 AI，可能不会以拟人化数字同事的形式出现。他们会在日常系统中调用一项已经设计好的能力，得到结果后完成必要确认，然后继续后面的工作。模型藏在流程内部，复杂的权限和工具连接由专门团队维护。

AI 的普及最终会表现为越来越多工作流程具备理解语言和处理变化的能力。组织中少数人负责建设这些流程，更多人在自己的工作中自然使用它们。

这条路径已经出现在模型公司、IT 服务企业、专业软件和开发者平台的实际投入中。AI Workflow Owner 所描述的，正是这些投入正在形成的一类工作。