AI 走进生产，考验的是组织能否接住新工作方式

图由 AI 生成

文 | 崔牛会

SaaS 公司做 AI，已经走过了最初的兴奋期。

员工开始使用 AI 工具，产品接入大模型，内部也搭出了不同用途的 Agent。Demo 能跑起来，局部效率也在提高。

可当 Agent 真正接手工作，一批更难的问题随之出现：

谁给 Agent 分配任务？

它可以读取和修改哪些数据？

结果由谁验收？

一旦出错，谁来兜底？

当 AI 接走大量执行工作，原来的岗位怎么调整？

客户最终为软件付费，还是为完成的任务和结果付费？

这些问题靠换一个更强的模型解决不了。

Agent 开始承担工作后，SaaS 公司原来围绕 " 人 " 和 " 软件 " 建立的组织、产研与交付规则，都需要重新调整。

01

Agent 上岗了

管理机制还只为人设计

大部分公司的管理机制，默认工作由人完成。岗位属于人，权限授予人，绩效考核人。任务出了问题，也可以找到具体负责人。

Agent 进入公司后，管理对象变了，原有机制却没有自动跟上。

有些团队已经在用 Agent 完成报告、写代码、整理需求，但这些实践常常依赖少数员工自发推动。Agent 能做什么、不能做什么，没有统一边界；生成结果能不能直接使用，也缺少稳定的验收标准。

组织要接住 Agent，至少需要回答四个问题：

第一，哪些任务可以交给 Agent；

第二，Agent 可以获得哪些系统和数据权限；

第三，谁来评价它的工作质量；

第四，Agent 出错后，由谁负责处理和兜底。

Agent 数量增加后，管理者的工作也会发生变化。

Neuters

以前，项目经理主要安排人的分工、进度和协作。现在，他还要管理 Agent 的任务、权限、上下文和输出质量。部门经验也不能继续散落在个人脑袋里，需要被沉淀为可持续调用的 Skill、Context 和工作规则。

明略的 AI Native 改造已经覆盖职能、分析师、研发等不同类型的团队。

内部形成 4300 多个工作单元，其中 AI 智能体数量超过人类。效率变化也在真实发生。财务报表的处理时间从 3 天缩短到 10 分钟，分析报告生产实现了高度自动化。

数字之外，一个更现实的问题浮现出来：当 AI 接走大量执行工作，原来的员工、管理者和业务负责人分别做什么？

前段时间，牛透社对明略科技创始人、CEO 兼 CTO 吴明辉的访谈中，他提到过：老业务 AI 化，最大的问题是改组织。

新业务可以从头设计岗位和流程，老业务却已经形成稳定的分工、考核和协作关系。Agent 进入之后，会触及原来的工作边界。技术跑起来了，组织未必立刻接得住。

对于 SaaS 公司来说，衡量 AI 组织化程度，不能只看员工使用率和 Agent 数量。更重要的是，公司有没有围绕 Agent 重新定义任务、权限、验收和责任。

02

很多公司急着做 Agent

却没补完前面三层能力

Agent 很热，不少 SaaS 公司希望一步进入 Agent 阶段。

现实中，一套 Agent 进入生产，经常卡在模型之外：企业知识还散落在文档、聊天记录和个人经验里；业务流程没有被拆清楚，大量异常依靠员工临场处理；AI 拿不到完整的上下文，也无法调用关键系统；输出质量缺少评测，出错后没有回滚和接管机制。

Agent 看起来足够聪明，进入真实业务后却跑不稳。

从 Chatbot 到 Agent，中间并非一次简单的模型升级。AI 每往前走一步，都要获得更多上下文、流程位置和执行权限。

Chatbot 解决 " 问得到 "。员工可以查询知识、生成内容，但结果仍然依赖个人提问。

Copilot 解决 " 做得快 "。AI 开始进入产品、研发、分析等岗位，帮助员工完成文档、代码、分析等单点任务。个人效率提高了，经验却未必能被团队复用。

Workflow 解决 " 跑得通 "。企业把一项工作拆成相对稳定的步骤，让 AI 进入需求、审核、生成、测试等环节。流程可以重复运行，遇到例外仍需要人来判断。

Agent 开始围绕目标推进任务。它需要获取上下文、调用工具、与其他 Agent 协作，并在一定权限内采取行动。

到了这一层，企业必须建立新的生产规则：哪些任务允许自动执行，哪些节点必须人工审批；Agent 之间如何分工；输出如何评测；错误怎样发现、回滚和追责。

明略科技 AI Native 组织变革实验室主任、AINOL 负责人黄楠曾展示过一个真实案例：用户反馈 Bug 后，多个 Agent 参与需求处理、评审、设计、开发和测试，1 小时 49 分钟后完成修复上线。

这个案例容易被记住的是速度，真正支撑它的却是背后的长期积累。

简单总结来看，明略的 AI Native 实践经历了从 Chatbot、Copilot、Workflow 到 Agent 的推进过程。每向前走一层，企业都需要补上新的基础能力：知识如何形成 Context，流程如何沉淀为 Skill，Agent 如何获得工具和权限，人的判断又应该保留在哪些节点。

很多 Agent 项目跑不稳，问题未必出在最后一层。前面的知识、流程和协作机制没有补齐，再强的 Agent 也只能停留在演示阶段。

03

客户开始为结果买单

交付还停在卖软件

传统 SaaS 有一套相对清楚的交付方式。

软件公司按账号、模块或使用年限收费。产品完成上线，实施团队帮助客户配置系统，后续工作主要由客户自己完成。

Agent 进入业务流程后，客户的关注点正在变化。

客户会继续追问：这个 Agent 能替我完成什么工作？可以节省多少时间和人力？结果达不到要求怎么办？最终由谁负责？

AI 越接近实际工作，客户对结果的期待越高。

过去交付的是一套可用的软件，现在可能需要交付一项可以持续完成的任务，甚至是一支数字劳动力。

这条路至少要回答三个问题。

首先，卖什么。客户购买的是软件工具、某项任务的完成，还是最终业务结果？不同答案对应不同的产品形态、价格和责任边界。

其次，怎么验收。按照功能是否上线、投入了多少人天来验收，还是按照效率、质量和业务指标来验收？Agent 出现错误时，软件公司、客户和交付团队分别承担什么责任？

最后，怎么复用。如果每进入一个客户现场，都要重新梳理流程、开发工具、训练 Agent，数字劳动力很容易变成新一轮重定制。项目经验必须沉淀为 Skill、Tool、数据和平台能力，才能在下一次交付中复用。

FDE 的价值也应该放在这条链路里理解。

它不是换了名字的实施人员，而是深入客户现场，识别真实业务问题，再连接客户场景、AI 能力和交付结果。

吴明辉也谈到，中国企业有自己的客户结构和交付环境，不能简单复制 Palantir 的 FDE 模式。

SaaS 公司需要重新思考：客户究竟愿意为什么付费，结果怎样验收，人的经验怎样沉淀成可复用能力，Agentic Services 又如何控制定制化成本。

基于这些问题，崔牛会深度学习下一站，9 月 4 日将走进明略。

我们将沿着组织改造、四年 AI Native 推进路径和数字劳动力交付三条线，拆解 Agent 进入一家约 1500 人的 ToB 公司后，人怎么重新分工，AI 怎样从个人工具走进真实生产，软件与专业服务又如何走向数字劳动力交付。

即刻报名⬇️⬇️

●17+ 小时，深聊 19 位实践者之后：FDE 在中国的落地路径，正在变得清晰

●网易智企的 AI Native 转型：从个人会用，到组织能复用

●ToB AI 产研大会，8 月 26 日深圳见！

点击左下角 " 阅读原文 "，报名深度学习系列明略科技站