一个适合 Agent 试点的流程长什么样

先说结论。

适合 Agent 试点的流程，通常不是最重要、最复杂的流程，而是高频、输入相对明确、结果可审核、错误可以撤回，并且只跨少量系统的流程。试点的目标也不是证明 Agent “什么都能做”，而是确认它能否在一个受控边界里减少交接、补全信息或给出下一步建议。

这篇文章给出一套可直接用于场景会谈的评分方法。它不依赖某个 Agent 框架，换成普通工作流或规则引擎也能使用。

适合谁：正在从多个业务需求里挑第一轮试点的产品、工程和运营负责人。如果团队只有一个明确且低风险的自动化任务，直接画流程并做旁路验证即可，不必先组织一场复杂评审。

先把“试点成功”定义成可观察变化

很多团队把成功写成“上线一个智能体”。这个定义无法验收，因为上线只是状态，不是结果。

更实用的定义应该落到原流程：少了一次人工复制，缺失字段被提前发现，处理人更快拿到上下文，或者高风险任务能在执行前停下来。每个变化都要有对照对象：原来怎么做，试点后哪一步改变，谁确认结果。

例如，销售线索整理的试点可以定义为：收到表单后自动生成摘要和候选标签，由销售确认后写入 CRM。这里验证的是整理质量、人工确认成本和写回稳定性，不是让 Agent 独立完成销售判断。

高频但不紧急的流程更适合起步

流程频率决定试点能不能快速积累样本。一个季度只发生一次的流程，即使价值高，也很难在两周内得到稳定结论。

但高频不等于越紧急越好。付款审批、生产故障处置和重大客户承诺虽然频繁且重要，错误窗口太短，不适合作为第一轮自动执行场景。更好的候选是每天都会出现、允许人工复核、晚几分钟不会造成严重损失的任务。

判断时可以问三个问题：一周能产生多少真实样本；样本是否覆盖常见分支；团队是否有时间复核结果。回答不清，就先做旁路观察，不要直接接入主流程。

输入明确，比模型能力强更重要

Agent 不能替流程补齐从未定义的信息。输入只有一句“帮我跟进客户”，模型只能猜测客户阶段、沟通历史、产品范围和允许承诺的边界。

适合试点的输入至少包括：任务类型、必要字段、数据来源、缺失字段处理方式和敏感信息边界。结构化表单、固定格式邮件、工单字段和会议纪要，通常比零散聊天记录更容易起步。

判断标准不是输入是否完全结构化，而是缺什么信息时系统能否明确停下并询问。能识别“信息不足”，比勉强生成一段完整文字更可靠。

输出必须能被人快速审核

一个输出即使正确，如果审核它比重新做一遍还慢，试点也没有价值。

适合审核的输出通常具备三点：格式固定，证据可追溯，修改位置清楚。比如线索摘要可以附原始表单链接；合同风险提示要指出对应条款；知识库回答要带文档来源。审核人应该能在几十秒内判断“通过、修改或退回”，而不是重新查遍所有材料。

如果输出是开放式战略建议、品牌创意或跨部门资源分配，评价标准本身就不稳定。此类任务可以让 Agent 辅助准备材料，但不适合用作自动化试点的核心验收项。

错误要能被发现、撤回和归因

试点不是零错误环境，但错误必须可控。

可以撤回的动作包括生成草稿、打候选标签、建立待办和发送内部提醒。难以撤回的动作包括对外承诺价格、删除数据、修改权限、付款和公开发布。第一类可以在人工确认前自动准备，第二类必须保留明确审批。

还要能回答错误发生在哪一层：输入缺失、模型判断偏差、工具调用失败、系统权限不足，还是人工批准失误。没有这条错误链，团队只会得到一句“Agent 不稳定”，无法迭代。

系统边界越少，越容易看清问题

第一轮试点最好只连接一到两个业务系统。跨表单、邮箱、CRM、企业微信、ERP 和财务系统的完整流程，看起来价值更大，但任意一个接口、权限或字段映射出错，都会污染结论。

可以先采用“读多写少”：允许 Agent 读取表单和 CRM 历史，只把结果写到待审核队列。等字段、权限和失败处理稳定后，再增加写回动作。

这不是保守，而是为了区分模型问题和集成问题。试点阶段最怕把五类故障混在一起，最后谁也说不清失败原因。

用一张评分表筛选候选流程

给每项按 0、1、2 分评分：

| 维度 | 0 分 | 1 分 | 2 分 | | --- | --- | --- | --- | | 发生频率 | 每月不足一次 | 每周发生 | 每天都有样本 | | 输入清晰度 | 主要靠口头判断 | 部分字段固定 | 字段和来源明确 | | 审核难度 | 需专家重新完成 | 可对照材料复核 | 可快速通过或退回 | | 错误成本 | 不可逆或合规风险高 | 可补救但代价明显 | 可撤回、影响局部 | | 系统边界 | 跨 4 个以上系统 | 跨 2 至 3 个系统 | 单系统或只读连接 | | 价值信号 | 无法定义 | 有主观反馈 | 有流程指标可观察 |

总分高不代表一定要做，但低于 7 分通常不适合做第一轮。还要设置一票否决项：涉及付款、删除、权限变更、法律承诺或敏感数据外发时，不能让模型绕过人工批准。

常见失败原因是把难题当成亮点

第一种误区是专挑“以前没人解决”的问题。试点需要基线，原流程都不存在，就无法判断 Agent 改善了什么。

第二种误区是把对话体验当成业务价值。聊天流畅不代表字段正确、系统写回成功或责任人收到提醒。

第三种误区是一次覆盖所有分支。长尾异常会迅速拖垮设计。第一版只覆盖最常见的主路径，并明确把异常转给谁。

第四种误区是没有停止条件。连续出现哪类错误要暂停、成本超过什么范围要降级、系统不可用时如何回到人工，都应该在试点前写清楚。

两周试点可以按这份清单开始

最小开始是拿三个候选流程完成六维评分，只选择一个输出做旁路运行。第一周不接写权限，先验证输入、审核和失败归因是否成立。

1. 画出原流程，标出输入、判断、动作、审核和输出。
2. 收集一批去敏后的真实样本，不用演示数据替代。
3. 只选择一个可审核输出，例如摘要、标签或草稿。
4. 定义通过、修改、退回三种审核结果。
5. 记录输入、版本、工具调用、输出、人工修改和失败原因。
6. 先旁路运行，再小范围写回。
7. 每周复盘错误类型，而不是只看成功次数。

这套评分的优势是让团队用同一种语言讨论频率、风险和审核，限制是分数无法替代业务责任。替代方案包括普通流程图、风险矩阵，或对单一候选直接做影子运行；当规则完全确定时，脚本和传统自动化也应进入比较。

我的建议不是马上选框架。先拿三个候选流程完成评分，把一票否决项单独列出来。评分最高且边界最清楚的那个，才值得进入原型阶段。