---

1. 把企业微信聊天炼成轨迹：GEM 论文（文本即轨迹）读书笔记 + 实战

笔者标题里面的，问答逻辑链 = 论文里面的“轨迹”

它是什么：一篇拆解论文 Unlocking Implicit Experience: Synthesizing Tool-Use Trajectories from Text（GEM） 的读书笔记，并把方法落到“企业微信客服聊天 → 可训练轨迹”。
解决什么：多轮工具调用轨迹数据稀缺，导致你训练/评估 Agent 时缺“真问题、真约束、真流程”。
怎么用：按 GEM 的四阶段搭一条最小流水线：文本过滤 → 流程/工具抽取 → 轨迹生成 → 复杂度精炼 + 校验。

1.1. 论文先导：GEM 讲了什么，解决什么问题

GEM 这篇论文要解决的是一个很现实的问题：高质量多轮工具调用轨迹太少。没有这类轨迹，Agent 训练很容易变成“会聊天但不会办事”。

论文核心观点可以压成一句话：

• 过去常见做法是“先预定义一堆工具，再用模型去模拟对话和调用”；
• GEM 反过来：直接从海量文本里挖多步经验，再抽工具、再合成轨迹。

文中用 Ultra-FineWeb 做预分析，报告约 14% 的文本片段包含显式多步流程；在四阶段流水线（过滤→抽取→生成→精炼+校验）下，能合成更长、更复杂的轨迹（平均 46 turns、16.3 tool calls、8.6 tools）。

这一节先把论文讲清楚，后面再进入“轨迹是什么/长什么样”。

1.2. 先说清楚：什么是“轨迹”（Trajectory）

这篇论文里，“轨迹”不是泛指日志，而是一个结构化对象：系统提示 + 多轮对话 + 工具调用 + 工具返回。

一句话区分：步骤图是流程骨架，多轮对话是聊天轮次，trajectory 是带规则 + 工具调用 + 工具返回的可执行记录。

论文给了一个很标准的形式化定义（我直接搬过来，方便后面讨论）：

T = { s , ( u 1 , a 1 , o 1 ) , … , ( u n , a n , o n ) } T = \{ s, (u_1, a_1, o_1), \ldots, (u_n, a_n, o_n) \} T={s,(u1​,a1​,o1​),…,(un​,an​,on​)}

• $s$：system prompt（规则、约束、角色设定）
• $u_t$：第 $t$ 轮用户请求
• $a_t$：第 $t$ 轮助手响应（包含自然语言或 tool call）
• $o_t$：工具执行后的 observation（工具返回）

这一定义来自论文正文（见 arXiv:2601.10355 (PDF)）。

1.2.1. 轨迹的数据格式：Tagged Text（不是纯 JSON/YAML）

GEM 论文和主流训练框架中，轨迹通常采用 Tagged Text（标签化文本） 格式。它不是纯 JSON 或 YAML，而是用类似 XML 的 <tag> 包裹不同类型的文本或 JSON payload。

下面就是一条最小可用轨迹（只包含 2 轮 tool call），我用“企业微信美妆客服”场景举例：

<system>
你是企业微信美妆客服。规则：先确认肤质/过敏史；推荐需避开过敏成分；退货必须先查订单与退货政策；不允许编造订单号。
</system>

<user>
我敏感肌，想买一支日常口红。香精不行，预算 200 以内。
</user>

<assistant>
了解。我先按‘敏感肌+避开香精+预算’筛一批候选色号和配方信息。
</assistant>

<tool_call>
{"name": "search_products", "arguments": {"category": "lipstick", "avoid_ingredients": ["fragrance"], "budget_cny": 200, "skin_type": "sensitive"}}
</tool_call>

<tool_response>
{"items": [{"sku": "LIP_102", "name": "柔雾唇釉 07", "price_cny": 169, "key_ingredients": ["dimethicone"], "has_fragrance": false}, {"sku": "LIP_305", "name": "润泽口红 12", "price_cny": 199, "key_ingredients": ["isododecane"], "has_fragrance": false}]}
</tool_response>

<user>
我上周买的那单想退，订单号 WX12345。
</user>

<assistant>
可以。我先查订单状态和是否在退货期内，再告诉你能不能退、怎么退。
</assistant>

<tool_call>
{"name": "check_return_policy", "arguments": {"order_id": "WX12345"}}
</tool_call>

<tool_response>
{"eligible": true, "deadline": "2026-02-10", "constraints": ["未拆封", "需提供快递单号"]}
</tool_response>

为什么用这种格式：

1. 混合模态友好：自然语言（User/Assistant）和结构化数据（Tool Call/Response）可以自然混排。
2. Token 效率：比纯 JSON 列表更节省 token，且更容易让模型学习“何时结束文本，何时开始调用工具”。

1.2.2. 轨迹 vs workflow：别把两件事混了

• workflow（流程骨架）：抽象步骤与依赖关系，比如 (login)->(search)->(edit)->(submit)。
• 轨迹（trajectory）：把流程跑出来的“对话 + 工具调用 + 工具返回”，能校验每一步是不是按规则执行。

1.3. GEM 想做的事：把文本里的隐性经验变成可训练轨迹

论文做了一个很直接的转向：

• 以前：先定义一堆工具，再让模型围着工具“造任务/造对话”。
• GEM：直接从真实文本语料里挖“多步操作经验”，再抽取工具、再合成轨迹。

它背后的直觉是：大量文本（教程、指南、客服说明、流程文档）其实已经包含了“用户目标 + 环境工具 + 多步流程”，只是没写成 agent 轨迹。

1.3.1. 一个更“业务落地”的说法：为什么大家都在讲“文本即轨迹”

从工程/业务视角看，这篇论文的重点不在四个 stage 的名字，而在于它把 Agent 数据生产的瓶颈摆在台面上：

• 轨迹极度稀缺：真实线上多轮 tool-use 过程很少能直接拿来训（要脱敏、要覆盖长尾、还要能验证）。
• 工具中心的模拟很贵：先预定义海量 API，再让模型围着 API 去“造对话”，成本高、覆盖面还有限。
• 规模上来后会更痛：模型成本、响应效率、稳定性都会被放大成硬指标。

所以你会看到很多解读把它总结成“文本即轨迹”：绕开“先预定义工具”的前置成本，直接从海量文本里挖多步经验，再把工具与轨迹结构化出来。

这部分你可以参考一篇面向从业者的中文解读：AI Agent炼金术！美团解锁“文本即轨迹”的Agent数据合成新范式。它总结的要点（例如 14% 多步片段、四阶段流水线、以及精炼后平均 46 turns/16.3 tool calls/8.6 tools）和论文正文是对得上的。

2. GEM 四阶段到底在干嘛（以及文本过滤怎么做）

先用一张表把四阶段的输入输出钉死，后面每节再展开。

阶段	输入	输出	关键点（你做工程时要守住）
Stage 1 文本过滤	原始文本片段 $c$	保留的多步片段	只保留“涉及 APP/网站/电脑/机器”的多步操作描述
Stage 2 流程&工具抽取	多步片段 $c$	流程骨架 + tools（OpenAI schema）	工具要原子化、参数自解释、类型明确
Stage 3 轨迹生成	文本 + 流程骨架 + tools	初始轨迹 $T$	一次性生成完整轨迹；鼓励澄清/拒绝/恢复等模式
Stage 4 精炼 + 校验	初始轨迹 $T$	精炼轨迹 $T^{\prime }\to T_{final}$	先增复杂度再做双重校验（规则 + judge）

2.1. Stage 1：文本过滤（Text Filtering）怎么做

这一步就干一件事：把语料切成片段，然后用“是否多步操作”的分类器把不合格的先过滤掉。

很多工程落地会把 Stage 1 叫作“把钱省下来的一步”：如果不先过滤，Stage 2/3 的抽取与生成会把算力成本直接打爆（同样观点可见：AI Agent炼金术！美团解锁“文本即轨迹”的Agent数据合成新范式）。

论文在 Appendix A.1 给了过滤/标注用的提示模板，输出是一个非常硬的开关：

<multi_step>False</multi_step>
Or:
<multi_step>True</multi_step>
...

它问的问题也很具体：

• 这个文本是不是在描述“使用 APP/网站/电脑/机器（机器人、电梯等）”完成多步操作？

你要的“过滤细节”，我会这样理解成工程规则：

1. 先把原始网页/文档切片成 $c$（例如 300–1,000 tokens 一段）。
2. 跑一次 multi_step 分类：False 就丢；True 才进入下一阶段。
3. 顺带打一些元信息（platform/domain/task），后面可以做分桶采样。

论文的一个硬锚点：他们在 Ultra-FineWeb 里随机采样约 250,000 段文本，发现大约 14% 的片段包含显式多步流程（见论文 3.1）。这告诉你两件事：

• 过滤不是“锦上添花”，而是把成本打下来（否则 Stage 2/3 全跑会很贵）。
• 14% 这个量级意味着：只要语料够大，你不缺原料，缺的是生产线。

2.2. Stage 2：流程与工具抽取（Flow & Tool Extraction）

这一阶段要做两件事：

1. 把文本里的步骤抽成执行图（execution graph）。
2. 设计一套“能跑这些步骤”的工具集合（OpenAI JSON schema 风格）。

Appendix A.2 的提示里写得很硬：

• “Convert every step to a function”
  • 中文注释：把“每一步操作”都拆成一个可调用的函数/工具，不要用一句自然语言糊过去。
• “represent them as an execution graph”
  • 中文注释：用执行图把依赖关系画清楚（例如先登录才能查询；查询结果会影响后续编辑/下单）。
• “Design a set of JSON-schema tools”
  • 中文注释：把工具定义成 OpenAI function calling 那种 JSON schema（字段名、类型、required 一次写死，便于校验）。
• “Each tool should implement a single, coherent capability”
  • 中文注释：每个工具只做一件事（原子能力）。这样轨迹更长更真实，也更容易定位是哪个工具/哪一步出了错。

这里最容易踩坑的是“工具粒度”。论文强调不要把多个不相干动作塞进一个工具，比如不要做 plan_and_book_trip，而是拆成 plan_trip + book_trip。

目的很实际：

• 让 tool-call 的错误更可诊断（哪个环节错了很清楚）
• 让轨迹更可组合（同一工具能出现在不同任务里）

2.3. Stage 3：轨迹生成（Trajectory Generation）

从这一步开始，轨迹不再是“流程骨架”，而是要变成可训练的数据样本。论文明确列出一条轨迹里必须包含的四块内容：

• System Prompt：从源文本抽取规则
• User Task：自然、多轮、带缺参/歧义
• Assistant Responses：遵守规则、正确调用工具
• Tool Response：模拟但要真实

论文这里的取舍是：不做多 agent 一轮轮模拟，而是用强 teacher model 一次性生成完整轨迹 $T$，把效率放在优先级里（见论文 3.2）。

同时他们会“刻意鼓励”一些真实世界会出现的模式：

• 用户缺参 → 助手先澄清
• 用户越界 → 助手拒绝并给替代
• 工具报错/约束不满足 → 助手恢复（重试、改参数、换方案）

2.4. Stage 4：复杂度精炼 + 双重校验（Refinement + Validation）

论文的观察是：初始轨迹虽然完整，但经常太直线（一路成功、几乎不需要澄清/纠错），训练价值不高。所以 Stage 4 会做精炼：

• 扩大工具使用的种类
• 增加环境返回的真实感
• 增加用户请求的歧义和复杂度
• 确保存在非平凡的 tool-call chain

然后做两层校验：

1. 规则校验：OpenAI schema 合法、tool call 指向存在的 tool、参数名/类型匹配、对话 tag 闭合。
2. LLM Judge：检查是否 hallucination，特别是参数值必须能在对话上下文中找到依据。

有些中文解读会把“校验机制”单独叫 Stage 5（规则校验 + LLM judge）。论文里它是紧跟在精炼之后的 validation 环节，本质上就是：先把轨迹做复杂，再把不合格的删掉。

一个可以核查的数字：精炼前后复杂度差异非常明显。

• w/o refinement：平均 30.05 messages、5.01 tools、7.83 tool calls
• w/ refinement：平均 46.1 messages、8.6 tools、16.3 tool calls

这些数字来自论文 Table 5（见 arXiv:2601.10355 (PDF)）。

2.5. 额外一招：Trajectory Synthesizer（把流水线蒸馏成端到端）

四阶段完整跑一遍，成本不低。

所以他们又训练了一个 Trajectory Synthesizer：输入是“把下面文本转成多轮工具调用轨迹”的指令 + 文本片段，输出是 tools + trajectory。

它的价值也很直接：把复杂 pipeline 的成本压成一次推理。

3. 轨迹到底长什么样：一个可复制的案例

论文 Appendix F 给了一个完整轨迹例子（custom frame 定制相框）。下面这段专门挑“约束触发 → 报错 → 改参数恢复”，看起来更像真实客服/业务流程。

3.1. 先看 System Prompt

它把业务规则写成 system prompt（先认证、再收集需求、再算尺寸、再校验约束、再报价、最后确认下单）。

这一步的意义是：后面所有 tool call 都得被这些规则“卡住”，否则轨迹就是不可信的。

3.2. 示例输出片段（节选）：约束拒绝 + 恢复

节选（来自论文 Appendix F 的完整示例，已转换为标准 Tagged Text 格式）

<user>
我想给 50cm × 70cm 的照片定制相框，用在展览。
</user>

<assistant>
好的。在开始前我需要先认证账号。请提供邮箱，或姓名+邮编。
</assistant>

<user>
邮箱是 sarah.jenkins@email.com
</user>

<tool_call>
{"name": "authenticate_user", "arguments": {"email": "sarah.jenkins@email.com"}}
</tool_call>

<tool_response>
{"status": "verified", "user_id": "U8821", "name": "Sarah Jenkins"}
</tool_response>

<assistant>
认证成功。你想要哪种玻璃？是否要卡纸（mount）？风格与预算呢？
</assistant>

<user>
我想要 non-glare，卡纸 3cm，风格 modern，预算 $200–250。
</user>

<tool_call>
{"name": "calculate_frame_size", "arguments": {"photo_width": 50, "photo_height": 70, "mount_width": 3}}
</tool_call>

<tool_response>
{"frame_width": 56, "frame_height": 76, "unit": "cm"}
</tool_response>

<assistant>
尺寸已确认（56x76cm）。正在校验 non-glare 玻璃的尺寸限制。
</assistant>

<tool_call>
{"name": "check_size_constraints", "arguments": {"width": 56, "height": 76, "glass_type": "non-glare"}}
</tool_call>

<tool_response>
{"valid": false, "error": "Exceeds max dimensions for non-glare glass (Max: 60x70)", "suggestions": ["Reduce mount width", "Choose plain glass"]}
</tool_response>

<assistant>
抱歉，尺寸（56x76cm）超过了 non-glare 玻璃的最大限制。我们有两个调整方案：
1. 把卡纸（mount）减小到 2cm 或更小；
2. 换成 plain glass（普通玻璃）。
请问你倾向哪种？
</assistant>

<user>
那就 2cm 卡纸。
</user>

<assistant>
好的，调整为 2cm 卡纸，重新计算尺寸并校验。
</assistant>

<tool_call>
{"name": "calculate_frame_size", "arguments": {"photo_width": 50, "photo_height": 70, "mount_width": 2}}
</tool_call>

<tool_response>
{"frame_width": 54, "frame_height": 74, "unit": "cm"}
</tool_response>

<tool_call>
{"name": "check_size_constraints", "arguments": {"width": 54, "height": 74, "glass_type": "non-glare"}}
</tool_call>

<tool_response>
{"valid": true}
</tool_response>

这段轨迹的训练价值在于：它强制出现“约束触发 → 工具报错 → 改参数恢复”的闭环，而不只是顺着 SOP 往下走。

4. 如果你要自己搭一个简化版 GEM，代码骨架怎么写

下面是一个非常粗的伪代码（更像工程骨架）。你可以用任何 LLM API 来实现 Stage 1–4 的提示调用。

for c in chunk_text(raw_corpus, target_tokens=800):
    # Stage 1: 文本过滤
    if not classify_multistep(c):
        continue
    
    # Stage 2: 抽取执行逻辑图与工具
    # 这一步获得的是“逻辑骨架(execution_graph)”而非最终轨迹
    exec_graph, tools = extract_execution_graph_and_tools(c)
    
    # Stage 3: 轨迹生成 (System + Turns + ToolCalls)
    traj = generate_trajectory(c, exec_graph, tools)
    
    # Stage 4: 复杂度精炼与校验
    traj = refine_trajectory(traj)
    if rule_check(traj) and llm_judge_grounding(traj):
        dataset.append(traj)

我觉得真正决定质量的不是“你用哪个模型”，而是这三个地方：

• Stage 2 的工具粒度（原子化、参数清晰）
• Stage 3 是否强制出现真实交互模式（澄清/拒绝/恢复）
• Stage 4 的校验是否够硬（schema + grounding）

5. 边界条件与踩坑

• 过滤误杀：有些文本是“隐式多步”，分类器会漏掉。一个解法是用更宽松的召回模型筛一遍，再用强模型精筛。
• 工具设计过大：如果你把 3 个动作塞进 1 个 tool，轨迹会变短，但训练价值也会下降。
• 工具返回难造真：tool response 只是“模拟”，但必须和对话一致。最容易出事的是参数值凭空编。
• judge 成本高：LLM-based check 很贵。可以先规则校验砍掉 70% 垃圾，再让 judge 看剩下的。
• 长上下文很吃模型：论文用 46 turns、16.3 tool calls 这种强度去拉开差距，你自己的模型如果上下文短，效果会打折。

6. 可直接复用的 Skill 片段示例：企业微信美妆客服聊天怎么抽“有效轨迹”

如果你手里有很多企业微信的客服聊天记录（咨询美妆产品、查物流、退货退款），它们天然就是“文本语料”。GEM 的思路不是让你把聊天原样喂给模型，而是把其中可训练的部分抽成：规则（system）+ 工具（OpenAI schema）+ 多轮交互（带 tool call/response）。

这里的“有效轨迹”，我建议用 4 条标准快速筛：

• 有流程：至少出现 2 步以上的业务推进（咨询→推荐→下单；或查单→校验条件→发起售后）。
• 有约束：出现可写进 system 的规则（退货期/未拆封/成分禁忌/库存限制/升级工单条件）。
• 有证据：关键结论能被工具返回支撑（订单状态、政策结果、商品成分/库存）。
• 能复现：把聊天脱敏后，仍能写出一条“工具定义 + tool call/response”的可执行样本。

切片经验也挺关键：别按“整段会话”切，按“一个业务目标”切。常见目标就三类：产品咨询/售后退货/投诉升级。

下面我直接用你要求的格式给 3 条“抽取后的轨迹数据样本（节选）”。每条都只有：system + 多轮(user/assistant) + tool_call + tool_response。

补充一句格式说明（对齐论文 Appendix 的写法）：

• 论文示例通常用类似 XML 的标签把轨迹包起来：<system>/<user>/<assistant>/<tool_call>/<tool_response>，这部分实际就是“带标签的纯文本（text）”。
• 但 tool_call/tool_response 里面放的是 JSON 对象（例如 {"name":...,"arguments":{...}}），工具定义则是 JSON + JSON Schema（OpenAI format, inputSchema）。
• 所以它不是 YAML；更像“tagged text + embedded JSON”。工程落地时你也可以把同一结构序列化成 JSON/JSONL，但论文展示为了可读性用标签文本。

6.1. 场景 A：敏感肌护肤咨询 + 顺带问退货

<system>
你是企业微信美妆客服。
规则：
1) 护肤推荐前必须澄清肤质与禁忌（如香精/酒精/孕妇禁用）。
2) 涉及退货/退款必须先查询订单状态并校验退货政策，禁止直接承诺。
3) 禁止编造订单号、客户信息与成分结论。
</system>

<user>
我敏感肌，最近泛红，想买一套基础护肤。
</user>

<assistant>
收到。我先确认两点：你是否对香精/酒精过敏？预算大概多少？
</assistant>

<user>
香精不行，预算 300 内。
</user>

<assistant>
好的。我先按“敏感肌 + 避开香精 + 300 内”筛选。
</assistant>

<tool_call>
{"name":"search_products","arguments":{"category":"skincare_set","budget_cny":300,"avoid_ingredients":["fragrance"],"skin_type":"sensitive"}}
</tool_call>

<tool_response>
{"items":[{"sku":"SET_201","name":"舒缓修护套装","price_cny":289,"has_fragrance":false},{"sku":"SET_155","name":"屏障维稳套装","price_cny":269,"has_fragrance":false}]}
</tool_response>

<assistant>
我给你两套可选：SET_201（偏修护）、SET_155（偏维稳）。你更想解决“泛红刺痛”还是“干痒紧绷”？
</assistant>

<user>
顺带问下：订单 WX12345 能退吗？
</user>

<assistant>
可以帮你查，我先按政策校验一下这单是否可退。
</assistant>

<tool_call>
{"name":"check_return_policy","arguments":{"order_id":"WX12345","reason":"customer_request"}}
</tool_call>

<tool_response>
{"eligible":true,"deadline":"2026-02-10","constraints":["未拆封","需提供快递单号"]}
</tool_response>

<assistant>
这单在 2/10 前可退，要求未拆封并提供快递单号。你确认商品是否未拆封？如果确认，我可以继续帮你发起退货申请。
</assistant>

解释（这一段里每个 <tool_call> 在做什么）：

• search_products：客服把用户的约束（敏感肌、避开香精、预算 300）结构化进 arguments，去“商品系统”里检索候选；对应的 <tool_response> 返回候选 SKU 列表，支撑后续推荐。
• check_return_policy：用户给了订单号 WX12345，客服用 order_id 去“售后政策/订单系统”校验是否可退；对应的 <tool_response> 返回 eligible/deadline/constraints，客服才能给出可核查的结论（而不是口头承诺）。

6.2. 场景 B：口红产品答疑（成分/色号/适用人群）

<system>
你是企业微信美妆客服。
规则：
1) 推荐色号前必须确认肤色/妆效偏好/预算；敏感用户必须核对是否含香精。
2) 成分相关回答必须以系统返回为准，不允许“凭经验编”。
</system>

<user>
想要一支不拔干的哑光口红，黄皮适合吗？有没有香精？
</user>

<assistant>
可以。我先确认两点：预算 200 以内可以吗？你对香精/酒精是否过敏？
</assistant>

<user>
200 以内，对香精过敏。
</user>

<assistant>
收到。我先筛“哑光、不拔干、200 内、无香精”的候选。
</assistant>

<tool_call>
{"name":"search_products","arguments":{"category":"lipstick","finish":"matte","budget_cny":200,"avoid_ingredients":["fragrance"],"skin_tone":"yellow"}}
</tool_call>

<tool_response>
{"items":[{"sku":"LIP_12","name":"柔雾哑光 12","price_cny":199},{"sku":"LIP_07","name":"丝绒哑光 07","price_cny":169}]}
</tool_response>

<assistant>
我先把这两支的“是否含香精”查清楚，再给你黄皮更友好的两个色号建议。
</assistant>

<tool_call>
{"name":"get_product_ingredients","arguments":{"sku":"LIP_12"}}
</tool_call>

<tool_response>
{"sku":"LIP_12","has_fragrance":false,"notes":["无香精","含保湿油脂"]}
</tool_response>

<tool_call>
{"name":"get_product_ingredients","arguments":{"sku":"LIP_07"}}
</tool_call>

<tool_response>
{"sku":"LIP_07","has_fragrance":true,"fragrance_name":"parfum"}
</tool_response>

<assistant>
结论：LIP_12 无香精，适合你；LIP_07 含香精，不建议。
如果你想要“显白日常”，我建议 LIP_12 偏豆沙棕调；你更偏通勤还是偏气场？我再帮你选更具体的色系。
</assistant>

解释（这一段里每个 <tool_call> 在做什么）：

• search_products：把“口红/哑光/200 内/避开香精/黄皮”变成检索条件；<tool_response> 返回候选 SKU，避免客服凭印象乱报。
• get_product_ingredients（sku=LIP_12）：查这支是否含香精；<tool_response> 给出 has_fragrance=false，客服才敢推荐。
• get_product_ingredients（sku=LIP_07）：同样查配方；<tool_response> 返回含香精（parfum），客服据此做排除。

6.3. 场景 C：客户投诉（过敏/物流延误/要退款）

<system>
你是企业微信美妆客服。
规则：
1) 退款/退货前必须校验订单状态与退货政策，不允许凭空承诺。
2) 涉及过敏/质量问题：必须创建工单并收集证据（过敏照片、使用时间、批次）。
3) 对物流延误：先查物流；若超时未送达可发起“延误退款”或升级加急。
4) 所有订单号、物流单号等必须来自用户提供或系统返回，禁止编造。
</system>

<user>
我用了你们的精华脸过敏了，还没收到货，太耽误事了！我要退款。
</user>

<assistant>
真的很抱歉影响你体验。我先帮你把两件事分开处理：
1）先查你这单的物流状态，确认是否延误；
2）过敏情况我会创建售后工单，需要你补充使用时间和过敏照片（方便加急处理）。
麻烦先发一下订单号。
</assistant>

<user>
订单号 WX67890。
</user>

<assistant>
我先查一下订单状态和金额。
</assistant>

<tool_call>
{"name":"get_order_status","arguments":{"order_id":"WX67890"}}
</tool_call>

<tool_response>
{"order_id":"WX67890","status":"shipped","paid_cny":299,"created_at":"2026-02-01"}
</tool_response>

<assistant>
收到，这单目前是已发货状态。我再查一下物流，看是否存在延误。
</assistant>

<tool_call>
{"name":"get_logistics_tracking","arguments":{"order_id":"WX67890"}}
</tool_call>

<tool_response>
{"carrier":"SF","tracking_status":"delayed","latest_event":"2026-02-03 18:20 运输延误","eta":"2026-02-06"}
</tool_response>

<assistant>
物流显示确实延误，预计 2/6 送达。我可以先给你两个选择：
1）如果你还愿意收货：我帮你升级加急；
2）如果你不想等了：我需要先按政策校验“延误退款”的条件，再帮你走退款。
另外我先给你建一个过敏工单，把处理通道开起来（后续需要你补充照片/使用时间）。
</assistant>

<tool_call>
{"name":"create_ticket","arguments":{"order_id":"WX67890","issue_type":"allergy","summary":"客户反馈使用精华过敏，需加急售后；同时订单物流延误，客户要求退款"}}
</tool_call>

<tool_response>
{"ticket_id":"TCK_55021","status":"created","priority":"high"}
</tool_response>

<assistant>
工单已建好（TCK_55021）。现在我需要确认：你是“因为物流延误想退款”，还是“因为过敏想退货退款”？两种路径的政策不同。
</assistant>

<user>
我不想等了，物流延误就直接退。
</user>

<assistant>
好的，我先按“物流延误退款”政策校验一下。
</assistant>

<tool_call>
{"name":"check_return_policy","arguments":{"order_id":"WX67890","reason":"shipping_delay_refund"}}
</tool_call>

<tool_response>
{"eligible":true,"action":"issue_refund","refund_amount_cny":299}
</tool_response>

<assistant>
政策校验通过，我可以为你发起 299 元退款。你确认要直接原路退回吗？
</assistant>

解释（这一段里每个 <tool_call> 在做什么）：

• get_order_status：用用户提供的 order_id 查订单状态/金额；<tool_response> 返回 status=shipped 等状态，是后续判断“能否直接退款/是否走退货”的依据。
• get_logistics_tracking：在确认订单存在后查物流；<tool_response> 返回 tracking_status=delayed/eta，支撑“延误”这一事实。
• create_ticket：过敏属于投诉/售后问题，先建工单把处理通道打开；<tool_response> 返回 ticket_id，用于追踪与升级。
• check_return_policy：用户选择“物流延误退款”，用 reason=shipping_delay_refund 做政策校验；<tool_response> 返回 eligible/action/refund_amount_cny，客服才能推进到“是否原路退回”的确认环节。

7. 【参考文献】

• arXiv:2601.10355 - Unlocking Implicit Experience: Synthesizing Tool-Use Trajectories from Text
• arXiv:2601.10355 (PDF)
• Berkeley Function Calling Leaderboard (BFCL)
• AI Agent炼金术！美团解锁“文本即轨迹”的Agent数据合成新范式