数字员工怎么理解业务流程——用 SDD 规约驱动开发核心论点数字员工不是按字面意思执行的机器人而是需要用结构化规约SDD定义业务流程。规约是人机之间的合同确保双方对流程的理解一致。痛点场景用户联系数字员工要退款一件已签收的商品。数字员工先问订单号是多少“用户给了。又问退货原因是什么”用户说了尺寸不合适。再问商品有使用过吗“用户说没有”。又问能提供几张照片吗“用户拍了照。折腾五轮对话后数字员工说抱歉该商品已超过退货期限签收后 7 天内无法办理退货”。用户很困惑——既然一开始就能查签收时间为什么不先检查再让我填一堆信息这个案例暴露了流程建模的核心矛盾数字员工需要明确的流程指引才能正确执行步骤。下面我们拆解常见的三种失败模式失败模式❌ 用自然语言描述流程很多企业用自然语言描述业务流程# 退货流程 1. 用户提出退货申请 2. 查询订单信息 3. 检查是否在退货期限内 4. 如果在期限内询问退货原因 5. 如果超期拒绝退货问题理解偏差数字员工对自然语言的理解可能与人类不同步骤不明确查询订单信息具体查什么缺少错误处理查询失败怎么办无法验证无法自动验证流程是否正确执行自然语言描述太模糊那把流程直接写进代码里行不行❌ 硬编码流程有些企业直接在代码中硬编码业务流程用代码硬编码流程业务人员无法阅读理解变更需改代码部署。硬编码太僵化自然语言又太模糊。即使选对了方式还有一个容易被忽视的问题流程中的异常处理。❌ 流程无异常处理遇到问题不知道怎么办有些企业定义了流程但没有定义异常处理流程只写了正常路径——查询订单成功→检查退货期限→收集退货信息→提交申请。问题流程中断查询订单失败时不知道怎么处理用户困惑数字员工突然卡住或给出奇怪回复无法恢复异常后无法回到正常流程继续执行解法框架SDD 结构化规约从三种失败模式中我们总结出一个核心思路数字员工不能靠自然语言理解业务流程而是需要结构化的规约定义。基于此提出了 SDDStructured Design Document结构化规约# 退货流程 SDD --- name: return-refund description: 处理退货退款业务 steps: 1. 查询订单信息 - 输入: order_id - 输出: order_info (包含签收时间、商品信息) - 验证: 订单号格式正确 2. 检查退货期限 - 输入: order_info.delivery_time - 条件: 当前时间 - delivery_time 7天 - 失败: 返回已超过退货期限 3. 收集退货信息 - 输入: user_id, order_id - 动作: 询问退货原因、商品状态、照片 4. 提交退货申请 - 输入: user_id, order_id, reason, photos - 输出: return_result注意第 2 步检查退货期限排在第 3 步收集退货信息之前——这正是痛点场景中缺少的。SDD 通过显式定义步骤顺序强制数字员工先做前置判断避免让用户白费功夫。核心设计原则规约是人机之间的合同——人类定义流程数字员工按流程执行。SDD 之所以有效是因为它包含了三个核心要素确保流程定义的完整性SDD 三大要素步骤定义——明确每个步骤的输入、输出和验证规则确保数字员工知道做什么。条件分支——定义条件判断和分支逻辑确保数字员工知道什么时候走哪条路。异常处理——定义异常情况的处理方式确保数字员工遇到问题时知道如何应对。要素说明示例步骤定义每个步骤的输入、输出、验证规则查询订单信息输入订单号输出签收时间条件分支条件判断和分支逻辑是否在退货期限内异常处理异常情况的处理方式查询失败、已超退货期限异常处理设计原则在 SDD 中异常处理需要区分业务异常和技术异常两者的处理方式截然不同类型是否写入 SDD处理方式示例业务异常必须写入作为流程分支定义决定流程走向订单未签收→不可退货、超过7天→已过时效、商品已下架→无法退货技术异常不应写入由 Agent 框架统一处理API 超时、网络错误、服务不可用业务异常属于业务规则的一部分数字员工无法自行推断必须在 SDD 中显式定义。例如订单未签收时不能退货是业务规则不是技术问题必须写入 SDD。技术异常属于基础设施层面的问题应由框架层统一处理重试、降级、转人工避免 SDD 过度膨胀。shop-agent 项目中已实现四层异常处理预防层参数校验、权限检查→检测层超时控制、异常捕获→恢复层指数退避重试上限 2 次→降级层替代方案或转人工。包含业务异常处理的 SDD 示例# 退货流程 SDD完整版 --- name: return-refund description: 处理退货退款业务 steps: 1. 查询订单信息 - 输入: order_id - 输出: order_info (包含签收时间、商品信息、订单状态) - 验证: 订单号格式正确 - 异常: 查询失败 → 提示订单号不存在请核对后重试流程终止 2. 检查订单状态 - 输入: order_info.status - 条件: status 已签收 - 异常: 订单未签收 → 提示商品尚未签收签收后才能申请退货流程终止 3. 检查退货期限 - 输入: order_info.delivery_time - 条件: 当前时间 - delivery_time 7天 - 异常: 已超退货期限 → 提示已超过退货期限签收后7天内无法办理退货流程终止 4. 检查商品状态 - 输入: order_info.product_status - 条件: product_status ! 已下架 - 异常: 商品已下架 → 提示该商品已下架无法办理退货请联系人工客服流程终止 5. 收集退货信息 - 输入: user_id, order_id - 动作: 询问退货原因、商品状态、照片 6. 提交退货申请 - 输入: user_id, order_id, reason, photos - 输出: return_result - 人在回路: 退款操作需要人工审批确认注意第 6 步的人在回路——这是电商场景中敏感操作的特殊异常处理方式。shop-agent 项目中通过_pending_approval机制实现提交退款申请后设置标志位等待管理员审批后再恢复执行有效防止误操作导致的资金损失。定义好 SDD 之后如何让数字员工实际使用它下面介绍集成方式SDD 与数字员工的集成SDD 是流程设计规范SKILL.md 是具体实现——每个 SKILL.md 文件对应一个 SDD 规约也是目前最被大众了解的YAML frontmatter 声明元信息Markdown 正文按 SDD 格式编写步骤。将 SKILL.md 从磁盘加载并注册到SkillRegistry运行时根据意图查找对应 Skill将其 Markdown 正文直接注入系统提示词末尾。因为 SOP 在系统角色中用户输入无法覆盖。找不到对应 Skill 时走默认 prompt。新增流程只需新建 SKILL.md不改代码。实战案例shop-agent 的 Skill SOP 机制在 shop-agent 项目中我们通过 Skill SOP 机制实现了流程建模SKILL.md 格式--- name: query-order description: 查询用户的订单列表 allowed-tools: query-order check-shipping tags: - 订单 - 查询 priority: 10 --- # 订单查询流程 ## 步骤 1. **理解用户需求** - 确定用户要查询的订单类型全部/待付款/待发货/已完成 - 如果用户没有指定默认查询全部订单 2. **调用订单查询工具** - 使用 query-order 工具查询订单列表 - 如果需要查询物流使用 check-shipping 工具 3. **整理结果** - 将订单信息按时间排序 - 只展示最近的 5 个订单 ## 注意事项 - 订单号格式GD 6-10 位数字 - 如果查询结果为空提示用户暂无订单加载机制服务启动SkillLoader.load()解析 SKILL.mdYAML frontmatter Markdown 正文存入 SkillRegistry缓存供运行时使用运行时注入用户请求意图识别查找对应 Skill注入 SDD 规约到系统提示词数字员工按规约执行性能对比SOP 注入使数字员工无需每次重新推理流程步骤直接按规约执行。实际效果取决于具体场景LLM 调用次数有 SOP 时仅需一次调用生成最终回答无 SOP 时可能需要多次调用逐步推理延迟SOP 注入减少了 LLM 的推理负担实际延迟取决于工具调用次数和网络状况成本SOP 注入减少了 Token 消耗具体节省比例取决于流程复杂度理解了 SDD 设计思路和实战实现后下面是落地时需要检查的事项落地检查清单[ ] 梳理所有业务流程订单查询、退款、物流查询等 [ ] 为每个流程创建 SKILL.md 文件 [ ] 定义流程步骤输入、输出、验证规则 [ ] 定义条件分支成功/失败路径 [ ] 定义业务异常处理订单状态不满足、已超时效、商品已下架等 [ ] 配置 allowed-tools流程中使用的工具 [ ] 测试流程执行是否按规约执行异常分支是否正确 [ ] 建立流程监控步骤执行时长、失败率、SOP 使用频率、异常触发次数 [ ] 建立 SOP 版本管理支持多版本 [ ] 准备流程优化根据监控数据调整流程