Agent 进入主航道后，企业更该按工作流采购

本文目录

企业采购 AI 项目时，需求表容易围着产品名转：支持多少模型，有没有 Agent 框架，能接哪些知识库，是否提供低代码编排，能不能私有化部署。

这些问题都需要问，却不足以构成验收。平台可以正常运行，业务流程仍可能没有变；模型回答看起来不错，数据也可能没有正确写回 CRM、ERP 或工单系统；自动化比例提高了，人工返工反而被藏到流程后面。

Agent 成为产业主航道之后，企业更需要改变采购单位。不要只购买一组平台能力，先采购一条边界清楚、可以运行、可以验收、也可以移交的工作流。

WAIC 的系统化趋势，不等于企业要先买完整平台

先看厂商在推什么方向。

WAIC 2026 上公开的不同产品路线，都在强调模型之外的系统能力。

荣耀发布的 Agentic OS 技术框架以意图和任务为中心，把模型与智能体纳入系统资源管理。腾讯 Tairos 具身智能开放平台则把模型、智能体、硬件抽象层、连接与建图工具和机器人本体放在同一架构中。

这些是厂商发布的技术方向，不能单独证明客户效果。它们共同说明了一件事：Agent 能否完成任务，取决于上下文、工具、权限、运行环境和反馈能否协同。国家网信办发布的《智能体规范应用与创新发展实施意见》也要求明确决策权限、保障用户最终决策权，并完善异常干预、阻断、恢复和行为追溯。企业要买的结果，也不该缩成”接入一个更强模型”。

问题在于，平台功能越多，采购越容易失去业务边界。一套系统可以覆盖很多场景，却没有任何一条流程对最终结果负责。项目完成后，供应商证明功能已交付，业务部门仍无法回答节省了什么、哪些错误减少了、谁来处理例外。

一条工作流，才是能同时约束业务和技术的单位

为什么这样说？

工作流不是几张流程图，也不是平台里的一个编排页面。它应该从真实业务事件开始，到一个可核验的业务状态结束。

以客服工单为例，起点可以是新来信进入队列，终点并非”模型生成回复”，真正要到达的状态，是客服确认内容、回复发送成功、工单状态正确更新，并保留使用了哪些政策依据。中间可能涉及分类、订单查询、知识检索、草拟、人工确认和系统写回。

把这整段作为采购单位，企业才能同时讨论六个关键问题：

1. 业务结果是什么，去哪个系统核验；
2. 需要哪些数据、知识和接口；
3. AI 可以自主到什么程度，哪些动作必须由人确认；
4. 什么叫质量合格，严重错误如何定义；
5. 异常、超时和权限不足时怎样接管或回退；
6. 项目结束后，客户拿到什么材料才能自行维护。

模型、平台和部署方式都可以放进这六个问题里比较。反过来，只比较产品能力，很难推出流程是否真的能交付。

采购文件里先写业务完成，再写技术规格

一份更可执行的需求，可以按下面的顺序组织。

流程范围

先定义起点和终点，拒绝模糊的产品名。

写明从哪个事件开始，到哪个业务状态结束。不要用“智能客服”“智能运营”这样的产品名代替范围。它们可以拆成来信分流、回复准备、报表汇总、异常解释等不同流程，每条流程的风险和验收标准都不同。

现状基线

没有起点，无从比较改善。

记录当前每周处理量、平均耗时、积压、返工和常见例外。供应商需要知道要改善什么，企业也需要一条可以比较的起点。

输入与系统

列出数据源，同时标注禁区。

列出文档、表格、邮件、知识库以及 OA、CRM、ERP、工单等系统。进一步说明接口是否可用、数据能否脱敏、权限由谁审批、哪些字段禁止进入外部模型。

自主等级

每一步都标上：只读、草稿、确认后执行，还是自动。

把每一步标为只读、生成草稿、人工批准后执行或可自动执行。自主性不必一次开到最大。第一版保留人工确认，往往更容易收集真实修改并建立评测集。

验收方法

用真实样例替代主观印象。

准备一批脱敏真实样例，覆盖正常输入、缺字段、知识冲突和业务例外。验收既要看最终结果，也要看工具是否选对、系统是否写回、权限是否越界、失败时是否进入预定路径。

移交与维护

项目结束不是终点，能接手才算交付。

明确源码、配置、连接器、评测用例、部署文档和知识更新方法的交付范围。还要约定模型或接口升级后怎样回归，问题由谁响应，客户团队能否自行接手。

三种常见采购方式，分别缺了什么

按账号、按功能、按人天，各有盲区。

第一种是按账号或席位采购工具。它适合个人辅助，却很难保证多人共用的业务规则、系统写回和责任边界。第二种是按功能清单采购平台。功能可以验收，业务流程的完成度却容易无人负责。第三种是按人天采购开发。项目可能完成了定制功能，但没有稳定样例、验收阈值和长期维护机制。

按工作流采购并不排斥这些方式。企业仍可使用成熟工具、平台和开发服务，只是最终验收要回到同一条业务链：输入是否来自真实工作，结果是否进入真实系统，失败是否有人接住，成本是否可以持续。

供应商至少应交付四类可检查材料

一条进入生产的 AI 工作流，不应只留下一次演示和一个后台账号。

第一类是可运行系统，包括约定范围内的工作流、连接配置和部署方式。第二类是评测材料，包括样例、期望结果、严重错误和回归方法。第三类是治理材料，包括权限清单、人工确认点、运行日志和回退条件。第四类是移交材料，包括源码或约定的可维护配置、部署使用文档和知识更新说明。

这些交付物不会自动保证项目成功，但能让企业判断系统现在能做什么、出了问题去哪里查、供应商退出后由谁接手。

哪些企业适合现在进入实施

先看是否满足基本条件。

如果流程已经高频发生，主要输入已经数字化，业务负责人愿意提供真实样例，并且结果可以由人工复核或回退，就具备了进入实施的基本条件。客服工单、销售会后处理、经营报告、文档提取与初审、内部知识检索，通常都可以进一步收缩成清晰的第一版范围。

如果企业仍不知道先做哪一条流程，应先完成场景诊断；如果已经有可描述的流程和系统，就可以开始讨论工作流实施。默碟公开的实施范围包括企业知识与业务数据接入、OA/CRM/ERP/工单连接、人工确认、评测、权限审计和部署，并按约定交付源码、配置、评测用例与文档。具体边界可以在服务页查看。

Agent 平台会继续演进，模型也会不断替换。企业需要沉淀的是自己的流程定义、权限规则、真实样例和验收标准。以工作流作为采购单位，技术变化才不会每次都把业务项目推回起点。