步骤归类
每一步属于 Reasoning、Skill、Tool 还是 Workflow。
一句话理解：把人工流程的每一步分成四类——需要模型判断的交给 Reasoning，可复用的专业方法做成 Skill，与外部系统交互的做成 Tool，顺序固定、必须可靠的交给 Workflow；归类做对了，Agent 才会既灵活又可控。
拆解完人工流程后，你手里有一张十几步的记录。最常见的错误是把整张记录原样写进 System Prompt，让模型“按这个流程做”。这样做的后果是：稳定的规则被模型偶尔违反，需要判断的地方又被写死；Prompt 越来越长，改一处坏一片。
正确做法是 逐步归类：每一步都问一句“它本质上是什么”，然后放到最适合它的载体里。本课给出一套归类方法，并用「订单售后处理 Agent」完整演示。
四类载体与判断标准
| 类别 | 本质 | 适合放什么 | 典型载体 | 相关课程 |
|---|---|---|---|---|
| Reasoning | 需要结合上下文做判断、无法提前穷举 | 原因综合判断、下一步查什么、证据是否充分 | 模型本身 + Instructions | Agent Loop 详解 |
| Skill | 可复用的专业方法、SOP、判断框架 | “如何核对退款政策适用性”“如何读退货入仓与质检数据” | SKILL.md + 参考资料 + 脚本 | Skill 是什么 |
| Tool | 读取或改变外部系统的原子能力 | 查订单、查支付、提交分摊重算、发通知 | API / MCP Server 暴露的函数 | 工具设计原则 |
| Workflow | 顺序固定、规则明确、必须每次一致 | 审批流转、资金动作前校验、通知模板发送 | 确定性代码、流程引擎 | Workflow 与 Agent |
一个简单的判断顺序：
还要额外问两个问题：这一步出错的代价多大？ 代价越大，越应该向右移（程序校验、人工审批）；这一步的输入是否可信？ 输入来自网页、邮件、用户投诉留言等外部文本时，要考虑注入风险（详见「Prompt 注入」）。
电商案例：逐步归类
沿用上一课的流程记录：
| 步骤 | 动作 | 归类 | 理由与设计 |
|---|---|---|---|
| S1 | 查订单 | Tool（只读） | get_order(order_id)，返回精简字段 |
| S2 | 查退款卡点日志 | Tool（只读） | get_refund_blocks(order_id) |
| S3 | 查退货入仓与质检 | Tool（只读） | get_return_inspection(ticket_id) |
| S4 | 查退款政策与类目规则 | Tool（只读） | get_refund_policy(category_id) |
| S5 | 查优惠分摊 | Tool（只读） | list_promo_allocations(order_id) |
| S6 | 查支付流水与退款通道 | Tool（只读） | get_payment(order_id) |
| S3–S4 的核对方法 | 质检结果与类目退款条款、时效的比对规则 | Skill | “退款政策适用性核对”，包含判定标准、常见例外（活动商品、跨月优惠券）和示例 |
| S3 的解读方法 | 如何判断退货未入仓是仓库未扫描还是包裹真的未到 | Skill | “退货入仓判读”，附入仓与质检数据字段说明 |
| 先查什么、何时停止 | 根据已有结果决定下一步 | Reasoning | 目标：定位原因并给出证据；原则：优先查卡点日志，证据不足不下结论 |
| S7 | 综合判断主因与次因 | Reasoning + 输出契约 | 模型判断，但必须输出固定枚举 cause_type 与证据列表 |
| S8 | 优惠分摊重算 | Tool（写入）+ 程序校验 | 程序检查：两个子订单属于同一笔订单、同一用户，订单总额不变 |
| S9 | 发起退款金额调整 | Workflow + 人工审批 | Agent 只能生成审批单草稿；审批通过后由流程引擎执行 |
| S10 | 回写备注、通知用户 | Workflow | 固定模板，由程序发送并记录 message_id |
| 应退金额计算 | 核对扣减后应退金额 | 程序 | 计算必须由退款引擎完成，模型不做算术 |
把表中各步放进四个象限，可以一眼看出它们的分布：
把这张表画成架构，是一个典型的 混合架构：外层是 Agent Loop，负责判断与编排；写入和资金相关的部分被包进确定性 Workflow（详见「混合架构」）。
三个容易归错的地方
1. 把业务规则写进 Prompt。 “单笔退款超过 5,000 元必须审批”是硬规则，写在 Prompt 里模型大多数时候会遵守，但“大多数”不够。它应该放在程序层，Prompt 里只需要告诉模型“超额动作会进入审批”，让它的输出符合预期（详见「把业务规则翻译成指令」）。
2. 把方法论做成 Tool。 有人会做一个 check_policy_eligibility() 工具，把判断逻辑藏在接口里。如果判断标准确定，这没问题；但如果核对需要结合类目条款文本、质检备注与活动页规则做综合判断，它更像 Skill——给模型一套方法和例子，让它调用多个只读工具自己核对。
3. 把需要判断的步骤写成 Workflow。 例如把“先查政策再查支付再查分摊”写死成顺序调用。结果每笔订单都要把 6 个系统查一遍，成本高、延迟高，还会被无关信息干扰。查询顺序本身就是 Agent 该判断的东西。
归类的输出物
完成归类后，你应该得到四份清单，它们直接进入下一步的 PRD：
- 工具清单：名称、读/写、参数、返回、风险等级。
- Skill 清单：名称、触发描述、包含的方法和参考资料。
- Instructions 要点：目标、原则、何时停止、何时找人。
- Workflow 与规则清单：哪些动作必须经过程序校验、审批和固定流程。
常见误区
- “全部交给模型最灵活。” 灵活的代价是不可控。资金、主数据修改、对外通知这类步骤，稳定性比灵活性重要得多。
- “全部写成 Workflow 最安全。” 如果每一步都写死，你做的其实是 RPA 或传统自动化，遇到新型异常就会失败，也失去了做 Agent 的意义。
- “Skill 就是长一点的 Prompt。” Skill 的价值在于按需加载与复用：只有遇到政策适用性问题时才加载那套方法，其他任务不占上下文。
设计要点
- 每一步都能说出它属于哪一类，以及为什么。
- 所有写入动作都有对应的程序校验与风险等级。
- 所有计算、金额、日期比较都由程序完成。
- 每个 Skill 都对应专家的一种“经验方法”，并附带正反例。
- Reasoning 部分只保留真正需要判断的内容：选择下一步、综合证据、决定是否停止或升级。
- 画出混合架构图，确认 Agent Loop 与确定性层的边界。
练习
用上一课练习中你记录的流程（或本文的订单售后流程），花 30–45 分钟：
- 为每一步填写“归类 + 理由”，形成一张归类表。
- 至少找出一个你原本想写进 Prompt、但应该交给程序的规则。
- 画一张类似本文的混合架构 ASCII 图，标出审批点。
下一步
归类时你可能已经发现：有些领域天然就有“跑一下就知道对不对”的验证手段，有些则没有。下一课「办公 Agent 与 Coding Agent」会解释这为什么决定了 Agent 能做多强。