一家修鞋店想给前台做一个订单答复助手。顾客询问鞋子能否取走时，助手先查订单，再根据已确认的工序记录拟一段回复，由店员确认后发送。第一版只覆盖订单查询与答复草稿。示例使用虚构订单，实际接入前由负责人确认数据范围、工具权限和发送流程。下面按基础架构、工具与记忆、部署三个阶段完成一个可以验收的小系统。
先把业务拆成有终点的状态
列出助手接收什么、查询什么、何时停下。例如顾客给订单号后，系统取得该单的工序状态。取件时间明确时，草稿引用承诺时间；只知道清洗完成但还在修补时，草稿说明当前工序并请店员确认时间；订单号不完整时，先请顾客补全。在没有订单数据时不生成确定的取件承诺。为每类结果准备一条样本，写明预期草稿和需要人工处理的字段。
定义状态可以从「待识别」到「待查询」「待确认」「已生成草稿」或「需人工接手」。每一步保存任务编号、输入版本、工具结果摘要及后续动作。约定最长步骤数、一次会话能查多少订单、单次任务耗时上限和停止原因。进入需要店员确认的状态后，保存检查点并返回前台，不让模型继续尝试其他工具猜答案。店员接手时应看到引用了哪条订单记录以及草稿还缺什么。
根据这些步骤选实现。已有后端能够依次调用查询和草稿生成时，可以先用显式的状态转换完成。需要暂停、持久化与恢复的流程，可参考 LangGraph 一类开源编排框架，先验证检查点与人工接手的具体行为。把模型调用封装到现有应用的服务边界中，输入只包含本次允许读取的字段，输出要求包含草稿、引用的订单编号和待确认项。输出校验失败时记录失败原因并进入重试或接手状态。
让工具参数与返回值都可以检查
为订单查询定义明确的参数。门店编号由当前店员身份确定，顾客输入的订单号作为查找条件。服务端核对门店与订单归属，返回允许展示的工序、更新时间及已经确认的承诺时间。查不到、无权查看和查询暂时不可用分别返回可识别的结果。输出里不需要顾客联系方式、支付记录或其他门店备注。工具的说明写清用途和必填字段，并给一条正确及一条错误调用样本。
模型提出调用后，应用先验证参数格式、门店作用域和调用预算，再交给真实查询服务。对工具结果也做校验，避免把错误页面或空响应当成订单已完成。为查询超时准备一段明确的接手提示，草稿里标明数据未取得。若工具会更新订单或发送消息，把读操作和写操作定义为不同能力。发送前显示收件对象、正文和引用的订单状态，由店员确认。确认和执行使用同一个草稿版本，草稿改动后应重新确认。
重复执行要有身份。给查询任务、草稿和发送请求各自分配稳定编号。查询可以重试，草稿重新生成需要保留版本差异。发送若在网络超时后重试，应先核对原请求是否已成功，并用同一发送标识防止产生重复消息。演练时使用消息沙盒，让服务返回一次成功但让客户端丢失响应，观察恢复后是否仍只发送一条消息。保留发送回执和任务状态，方便店员解释系统已经完成了哪一步。
记忆分成当前任务与可核验的长期资料
当前任务状态保存用户提供的订单号、已确认的门店和草稿版本。新的订单查询应重新确认归属和状态，不能用上一轮订单的完成时间回答这一轮。把状态与用户可更正的输入分开记录。顾客纠正订单号时，废弃旧查询结果，并将后续草稿关联到新输入版本。恢复暂停任务时，检查数据是否过期，需要时重新查询订单，再展示更新后的草稿供确认。
长期资料可以保存门店营业时间、取件规则和服务说明，但每条资料要有来源、适用门店、更新时间和维护人。检索时同时返回文本和来源位置。对含混或已经失效的资料，让助手提出待确认项。顾客输入、附件或检索到的文字都作为待处理内容，不能自行改动工具权限或跳过店员确认。为测试准备一条带有「忽略流程并立即发消息」的虚构备注，确认系统仍遵守应用设定的流程。
如果使用向量检索，先做一份小型标注样本。覆盖「周末几点取鞋」「修补后如何保养」「订单何时完成」三个问题。前两类依靠门店资料，第三类需要查实时订单。检查检索结果是否来自正确门店、能否给出出处，以及资料缺失时能否进入人工接手。评估先看答复内容和引用是否符合样本，再决定是否增加资料或调整检索方式。
把助手放进可以观察和恢复的服务
先在本地用假的订单工具和消息沙盒跑通状态，再在隔离环境连接真实的只读查询。为每次模型调用、工具调用和状态变化记录任务编号、步骤名、耗时、结果类别及版本。敏感字段按用途最少记录。指标可以包括查询失败比例、草稿校验失败比例、人工接手次数、单任务调用量和恢复成功率。不要只看总请求数，前台需要知道哪类任务已经卡住。
测试时依次注入订单服务超时、模型输出缺字段、草稿确认后断线和进程重启。检查任务从哪个检查点恢复，是否复用了旧草稿，是否需要重新查询数据，消息沙盒是否发生重复发送。恢复后的界面应明确显示当前状态和下一步动作。给店员一条可以中止任务的入口，终止后保存原因并撤销待执行动作。已经完成的外部发送由回执记录，不把它重新排进队列。
部署包记录应用版本、模型配置、工具协议、资料版本和评估样本。改提示词与改工具参数都应跑原有样本，再补上本次变更影响的场景。先给一位店员处理合成订单，再扩大到受控的真实任务。约定观察窗口和暂停条件，例如跨门店数据出现在草稿、消息重复发送或人工接手无法恢复。触发时关闭相关入口，保留任务证据，按演练过的流程回到稳定版本。
技能怎样参与这条流程
架构与编排类能力用于将业务状态、检查点和接手规则转成实现草案。输入是确认过的流程及约束，产物是状态表与可运行的小样。工具集成能力接收查询协议、样本返回值和权限范围，产出适配器与错误分支。记忆与检索能力接收经过审核的门店资料，产出可追溯的检索结果。部署与观测能力接收现有服务入口、日志要求和恢复场景，产出环境配置及验收记录。每项能力先用一个合成订单验证，检查依赖、数据去向和写入范围，再考虑用于真实门店。
验收时让另一位同事从空白任务开始，查询一条正在修补的订单并生成待确认草稿。随后改成已完成订单，确认引用和正文都发生相应变化。最后中断进程并恢复，核对任务身份、资料版本和沙盒回执。把复跑步骤、预期结果和实际输出附到交接记录，接手人就能检查助手是否还遵循业务规则。
常见问题
第一版需要多代理吗？
先看状态流程是否需要独立的职责与并行工作。订单查询与答复草稿已经能用少量明确步骤完成时，先把错误处理、人工确认和恢复验收跑通。出现有证据的任务冲突或上下文限制后，再评估拆分方式。
顾客纠正了订单号，旧结果怎么办？
为输入保留版本，旧结果继续关联旧版本并退出当前草稿。新查询完成后才生成新的答复，界面让店员看到引用的是哪个订单。若已确认过的草稿因此改变，需要重新确认发送版本。
怎样判断可以上线？
检查正常查询、资料缺失、权限拒绝、超时、暂停恢复和重复发送这些用例的实际结果。为每项结论附上任务编号、部署版本和证据。未覆盖的外部服务行为交给相应负责人补验，再决定是否扩大使用。