Agent开始干活后，SaaS公司的三套旧规则失效了

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又如何控制定制化成本。

本文来自微信公众号“牛透社”（ID：Neuters），作者：崔牛会，36氪经授权发布。