Agent 上岗后，SaaS 公司的旧规则为何失效

当 AI Agent 从演示阶段走向真实业务流程，SaaS 公司原本围绕「人」与「软件」搭建的组织、产研与交付规则开始失灵。明略科技等先行者的 AI Native 实践，以及牛透社对行业核心问题的梳理，指向一次围绕 Agent 的系统性重写。

Agent 进入岗位，管理机制仍只为人设计

大多数公司的组织架构默认工作由人来完成：岗位归属人，权限授予人，绩效考核人，出了问题也能定位到具体负责人。Agent 进入后，工作主体发生了变化，但管理机制并未自动跟进。

现实情况是，一些团队已经在用 Agent 写报告、写代码、整理需求，但这些实践往往依赖少数员工的个人尝试，缺乏统一的 Agent 能力边界与输出验收标准。组织要真正接住 Agent，至少需要回答四个问题：哪些任务可以交给 Agent、Agent 可以获得哪些系统与数据权限、谁来评价其工作质量、出错后由谁兜底。

明略科技的 AI Native 改造已覆盖职能、分析师、研发等不同类型的团队。内部形成 4300 多个工作单元，其中 AI 智能体数量已超过人类；财务报表处理时间由 3 天缩短到 10 分钟，分析报告生产实现了高度自动化。

明略科技创始人、CEO 兼 CTO 吴明辉在牛透社访谈中指出，老业务 AI 化最大的难题在于改组织。新业务可以从零设计岗位与流程，老业务却已经形成稳定的分工、考核与协作关系；Agent 进入后会触及既有边界，技术跑得起来，组织未必接得住。衡量 SaaS 公司的 AI 组织化程度，不能只看员工使用率与 Agent 数量，更要看公司是否围绕 Agent 重新定义了任务、权限、验收与责任。

急于做 Agent，前三层能力尚未补齐

Agent 概念火热，不少 SaaS 公司希望一步跨入 Agent 阶段。但在生产环境中，Agent 经常卡在模型之外的环节：企业知识仍散落在文档、聊天记录与个人经验里；业务流程未被拆解，大量异常依赖员工临场处理；AI 拿不到完整上下文，也无法调用关键系统；输出缺少评测，出错后没有回滚与接管机制。

明略将 AI 进入企业划分为四层：

• Chatbot 解决「问得到」，员工可以查询知识、生成内容，但结果仍依赖个人提问；
• Copilot 解决「做得快」，AI 进入产品、研发、分析等岗位完成单点任务，个人效率提升但经验未必可复用；
• Workflow 解决「跑得通」，企业把工作拆成相对稳定的步骤让 AI 进入，流程可重复运行，遇到例外仍需人来判断；
• Agent 开始围绕目标推进任务，需要获取上下文、调用工具、与其他 Agent 协作，并在一定权限内采取行动。

每向前一层，企业都需要补上新的基础能力——知识如何形成 Context，流程如何沉淀为 Skill，Agent 如何获得工具与权限，人的判断又该保留在哪些节点。明略科技 AI Native 组织变革实验室主任、AINOL 负责人黄楠展示过一个真实案例：用户反馈 Bug 后，多个 Agent 参与需求处理、评审、设计、开发与测试，1 小时 49 分钟完成修复并上线。这一速度背后，是四层能力的长期积累。

客户为结果买单，交付还停在卖软件

传统 SaaS 按账号、模块或使用年限收费，产品上线后由客户自行使用。Agent 进入业务流程后，客户的关注点明显转向：这个 Agent 能替我完成什么工作？能节省多少时间与人力？结果不达标怎么办？最终由谁负责？

这要求 SaaS 公司重新回答三个问题：

• 卖什么——是软件工具、某项任务的完成，还是最终业务结果，不同答案对应不同的产品形态、价格与责任边界；
• 怎么验收——按功能上线与人天投入，还是按效率、质量与业务指标，Agent 出错时软件公司、客户、交付团队各承担什么责任；
• 怎么复用——项目经验如何沉淀为 Skill、Tool、数据与平台能力，避免数字劳动力沦为新一轮重定制。

FDE（Forward Deployed Engineer）的价值也应放在这一链路中理解：它不是换了名字的实施人员，而是深入客户现场、识别真实业务问题、再连接客户场景、AI 能力与交付结果的桥梁。吴明辉也强调，中国企业有自己的客户结构与交付环境，不能简单复制 Palantir 的 FDE 模式，SaaS 公司需要重新思考客户究竟愿意为什么付费、结果如何验收、人的经验如何沉淀为可复用能力、Agentic Services 如何控制定制化成本。