拆解人工流程

一句话理解：Agent 的能力上限，取决于你把专家脑子里的流程、判断依据和“例外处理”挖出来多少；拆解人工流程不是画一张理想流程图，而是记录专家真实的每一次查询、判断与动作。

很多团队设计 Agent 的方式是：产品经理想象一个流程，工程师把它写进 System Prompt，再给模型配几个接口。结果 Agent 在演示用例上表现不错，一遇到真实工单就迷路——因为真实工作里充满了文档上没有写的东西：先看哪个系统、哪个字段不可信、什么情况要去问仓库同事、哪类问题其实不用管。

这些东西只存在于专家的日常操作里。拆解人工流程 就是把它们系统地挖出来，变成 Agent 的上下文、工具、Skill 和规则。它是 Agent 设计中投入产出比最高的一步。

为什么不能只看 SOP

公司通常有 SOP（标准作业程序），但 SOP 与真实流程之间至少有四种落差：

落差	SOP 上写的	专家实际做的
顺序	先查订单，再查支付流水	先看退款单的卡点日志，80% 的问题在那里就能定位
数据可信度	以订单系统状态为准	订单系统的“已签收”经常滞后，要以仓库入库扫描记录为准
隐性判断	“核对退款政策”	看下单时间与类目退款时效是否匹配；活动商品要额外查活动页规则
例外路径	无	优惠券跨月失效时，先等营销对账任务跑完再判断，否则会误判为金额不符

Agent 如果只学 SOP，就会重复新人犯的错误。你要找的正是右边这一列。

四种挖掘方法

方法	做法	能挖出什么	注意
跟岗观察	坐在专家旁边看他处理 5–10 单，边做边讲（Think-aloud）	真实顺序、系统切换、隐性判断	最有效，但要打断他追问“你为什么看这里”
屏幕录制与操作日志	录屏或导出系统访问日志	客观的查询顺序与耗时分布	看得到“做了什么”，看不到“为什么”
历史工单回放	抽 50–100 张已关闭工单，按结论分类	原因分布、长尾例外、处理结果	同时是后续评测集的原料
专家复盘访谈	拿一张疑难工单让专家复盘	决策树、经验规则、风险直觉	专家容易“美化”流程，需要与录屏对照

建议至少组合 跟岗观察 + 历史工单回放：前者给你过程，后者给你分布和评测样本。

流程记录模板：每一步记五件事

观察时不要只画方框箭头，每一步记录五个字段：

步骤编号 | 动作 | 信息来源（系统/字段） | 判断依据 | 产出/下一步

下面是一位售后专员处理“订单 SO20260912001 为什么还没退款？”的真实步骤记录（已脱敏简化）：

S1  打开订单系统查订单      | 订单系统：订单状态、下单时间、金额、商品类目 | 状态=已签收、售后=退款中     | 进入排查
S2  看退款单卡点日志         | 退款引擎：卡点记录                      | 有一条“待退货入仓”卡点       | 怀疑退货未签收
S3  查退货入仓与质检         | 售后仓：按退货单号查入仓与质检记录        | 包裹已入仓，质检备注“缺配件”  | 怀疑政策不符
S4  查退款政策与类目规则      | 政策库：类目退款时效、缺件扣减条款        | 该类目缺件需按比例扣减       | 确认政策不符
S5  查优惠分摊（顺手核对）    | 营销系统：优惠券与满减分摊、所属子订单     | 分摊金额挂在另一个子订单上    | 发现第二个问题
S6  查支付流水（排除支付问题）| 支付系统：支付状态、退款通道、可退额度     | 支付正常、额度充足           | 排除
S7  判断                    | 综合 S2–S6                            | 主因：政策不符；次因：分摊挂错 | 形成结论
S8  处理次因                 | 营销系统：申请优惠分摊重算               | 重算属于低风险数据修正       | 直接提交
S9  处理主因                 | 发起“退款金额调整”流程，通知用户          | 涉及退款金额与用户沟通       | 需主管审批
S10 回写备注并通知用户        | 工单系统 + 站内信                       | —                          | 结束

仅这一张记录，就已经告诉你：Agent 至少需要 7 个查询工具、2 个写入工具、1 个通知工具；需要“退款政策适用性核对”这类可复用的判断方法；需要至少一个审批点。

把这 10 步按“查询、判断、处理”三条泳道摊开，信息流向和风险点会更直观：

图 1 · 售后专员的 S1–S10：六次只读查询、一次综合判断、三次写入与通知

从记录到“专家决策树”

把 10–20 张单子的步骤记录叠在一起，就能提炼出专家真正依赖的决策结构：

图 2 · 专家决策树：叶子节点的颜色标出了风险与审批点

这棵树的用途不是直接写成 if-else，而是：

哪些分支是稳定规则——交给程序或 Workflow（详见「LLM 与确定性程序的分工」）；
哪些分支需要综合判断——交给 Agent 推理；
哪些分支是方法论——沉淀为 Skill，例如“退款政策适用性核对”；
哪些叶子节点有风险——标出审批点。

这四类归属正是下一课「步骤归类」要系统解决的问题。

同时记录三样“副产品”

拆解流程时顺手收集下面三样东西，后面会反复用到：

原因分布：100 张历史工单里，退货未签收 38%、政策不符 21%、流程卡单 19%、支付未到账 14%、其他 8%（数字为示例假设）。它决定了先做哪些分支，也决定了评测集的配比。
耗时分布：哪一步最耗时。如果 60% 的时间花在“在 6 个系统间切换查询”，Agent 的首要价值就是并行查询与汇总，而不是“更聪明的判断”。
错误与返工：专家自己也会犯错的地方，是 Agent 必须加验证的地方。

常见误区

“访谈一次就够了。” 专家描述的流程与他实际操作的流程往往不同。至少要看他真做几单，并与录屏或日志对照。
“只记录主流程。” 长尾例外（跨月失效的优惠券、活动商品的特殊退款规则）恰恰是 Agent 最容易出错、也最影响信任的地方。例外至少要记下来，即使第一版不处理，也要让 Agent 识别并转人工。
“把专家流程原样搬给 Agent。” 专家受限于人一次只能看一个系统；Agent 可以并行查询。拆解是为了理解判断逻辑，不是复刻点击顺序。

设计要点

至少观察 2 位不同水平的专家，每位不少于 5 单，并回放 50 张以上历史工单。
每一步记录：动作、信息来源、判断依据、产出。
标出所有“这里我会凭经验判断”的节点，这些是 Agent 推理与 Skill 的重点。
标出所有写入、通知、资金相关的动作，这些是权限与审批的重点。
标出专家用来确认“真的处理好了”的动作，这些是验证环节的原型。
把原因分布和典型工单保存下来，直接作为评测集的第一批样本（详见「构建评测集」）。

练习

选一件你自己或同事每周重复做的多步骤工作（例如月度销售下滑分析、SEO 流量异常排查），用 45–60 分钟：

真实做一遍，并用“步骤编号 | 动作 | 信息来源 | 判断依据 | 产出”的格式逐行记录。
标出其中的隐性判断（凭经验）和风险动作（写入/发送/资金）。
把记录整理成一棵决策树，并估算每个分支出现的比例。

下一步

有了流程记录与决策树，下一课「步骤归类」会教你把每一步分配给 Reasoning、Skill、Tool 或 Workflow。

拆解人工流程