企业 AI Agent 落地前，先把业务流程边界画清楚

很多企业开始讨论数字员工、AI Agent、智能客服和流程助手时，第一反应是找工具。

工具当然重要，但生产落地的第一步不是选模型，也不是选平台，而是回答一个更基础的问题：这个 Agent 到底进入哪条业务流程。

如果流程边界没有定义清楚，Agent 很容易停留在 demo：看起来能回答问题，真进入业务以后却没人敢让它执行动作。

1. 先选流程，不要先选工具

适合做第一批试点的流程，一般有几个特征：

• 高频重复
• 规则相对稳定
• 数据来源明确
• 出错损失可控
• 结果容易验收
• 有明确负责人

例如，内部知识库问答、工单初筛、合同条款摘要、报表解释、会议纪要归档，都比直接让 Agent 修改订单、发送客户通知、审批付款更适合作为起点。

原因很简单：第一批试点不是为了证明 AI 很强，而是为了证明这套流程能被安全地自动化。

2. 把流程拆成读、判、写、审

企业流程里的动作可以粗略拆成四类：

读：查询资料、读取报表、检索客户状态
判：分类、总结、推荐下一步
写：创建任务、修改状态、生成草稿
审：人工确认、批准、驳回、追责

很多项目的问题，是把这四件事混在一起。只要 Agent 能接上一个内部系统，就默认它可以一路执行到底。

生产系统不能这么做。

更稳妥的方式是：

• 只读动作可以先放开
• 推荐和总结需要留下依据
• 写入动作需要权限分级
• 外发和审批必须有人类复核点

这样做不是降低效率，而是让自动化能逐步进入真实流程。

3. 读权限和写权限必须分开

一个常见误区是：既然 Agent 能访问某个系统，就让它同时查询和修改。

读权限和写权限应该分开管理。

举例来说：

• 能读客户状态，不代表能改客户状态
• 能读合同，不代表能生成最终合同版本
• 能查库存，不代表能创建采购单
• 能看工单，不代表能自动关闭工单
• 能总结会议，不代表能直接发给外部客户

权限分层至少要包括：

• 只读
• 低风险写入
• 中风险草稿
• 高风险待审批
• 禁止自动化

如果一开始没有这层设计，后面出了问题，很难判断责任到底在模型、工具、业务规则还是权限配置。

4. 人工确认点要写进流程

很多人把人工确认看成自动化的反面。其实在生产 Agent 里，人工确认是自动化能够被接受的前提。

高风险动作应该进入人工确认：

• 发给客户的消息
• 修改核心业务状态
• 触发付款或审批
• 删除或覆盖数据
• 影响合规记录的动作

Agent 可以做准备工作：读取上下文、生成草稿、给出建议、整理依据。最终执行权是否交给 Agent，要看风险等级。

一个可用的设计是：

低风险：自动执行
中风险：生成草稿，等待确认
高风险：提交审批，不直接执行

这比简单地说“让 AI 自动处理”更接近真实业务。

5. 每一步都要能被审计

数字员工一旦进入流程，日志不能只记录一句“调用成功”。

至少要记录：

• 用户请求
• 读取的数据范围
• 模型判断依据
• 调用的工具
• 写入的字段
• 是否触发人工确认
• 最终执行结果
• 异常和接管人

这些记录不是为了写更多日志，而是为了出问题时能复盘。

如果客户状态被改错，团队需要知道是数据读错、模型判断错、工具调用错，还是人工确认漏掉了。没有审计链路，所有问题都会变成一句“AI 出错了”。

6. 失败接管路径比成功演示更重要

demo 通常展示成功路径：用户提问，Agent 理解，工具调用，返回结果。

生产系统更要看失败路径：

• 工具超时怎么办
• 数据缺失怎么办
• 权限不足怎么办
• 结果冲突怎么办
• 用户拒绝建议怎么办
• 谁来接管未完成任务

如果失败后没有接管路径，自动化会变成新的积压队列。

一个基础接管路径可以是：

检测异常 -> 停止高风险动作 -> 保留上下文 -> 通知负责人 -> 人工处理 -> 复盘规则

这条路径越清楚，业务越敢把 Agent 放进流程。

7. 用验收指标决定是否扩张

不要一开始就把数字员工铺满所有部门。

先选一个流程，跑出指标，再决定是否扩张。常见指标包括：

• 处理时间是否下降
• 人工返工是否下降
• 错误是否可追踪
• 用户是否持续使用
• 异常是否能及时接管
• 负责人是否愿意扩大范围

如果这些指标没有改善，继续堆模型和工具意义不大。