这个项目到底想解决什么？
想象你在网上买了一顶头盔，收到后发现尺寸不合适，于是找客服换成中号。 客服需要确认你是谁、找到订单、查有没有合适的库存、请你确认方案，最后提交换货。 这是一个可以检验结果、又包含好几个决定的工作。
我们想让 AI 处理这样的工作，并研究它怎样从具体问题中进步。 这里的 AI 除了说话，还能发出“查订单”“查库存”“提交换货”等电脑指令。 项目把这种能采取行动的 AI 称为 Agent；在这页里，你把它理解成“AI 客服”就够了。
我们的设想很朴素：
- 让 AI 客服先做一次，留下完整过程。
- 找出一个具体偏差，例如没有等上一项查询返回，就把多项操作一起发出。
- 把应当遵循的做法写成一张“操作卡”，放进它下一次收到的指令里。
- 在可比较的条件下再试，看看它有没有改善，以及还能不能把任务办成。
- 如果在开发时用过的例子上有效，再去试没有用来修改操作卡的新题。
这张操作卡在实验中叫 Skill。目前它的实现是一段额外提示文字， 每次只是让客服在开始工作前多读这段说明，模型的内部参数保持不变。
到目前为止，找问题、写操作卡、决定怎样比较和何时停止，都由我们人工审阅和设计。 能够自己发现问题、自动写出有效规则的改进系统，仍是后续研究目标。
我们最终想验证的是：从具体失败中整理出来的规则，能否让 AI 持续做得更好， 并且在新题上也有帮助。 截至本页记录的时间，这个目标仍待验证。
实验里的顾客、客服和商店是谁？
我们使用一个叫 tau2 Retail 的现成模拟商店测试环境。 你可以把它想成一套带有虚构顾客、商品、订单和操作规则的练习题。 所有换货和退货都发生在测试数据库里，不会处理真实顾客的购物订单。
一次对话里有四个不同的部分
- 模拟顾客：由一个独立的 AI 对话扮演。它拿到题目中的购物需求和允许知道的信息，然后与客服交谈。
- AI 客服：拿到客服规则、可用工具和对话内容，决定接下来问什么、查什么、提交什么。
- 模拟商店：由程序和测试数据库组成。它执行查询或修改，并返回实际结果。
- 检查程序：对照题目要求检查执行后的结果，例如订单是否改成了正确商品。
顾客和客服使用同一型号的 DeepSeek 模型，但各自有独立的指令和对话记录。 顾客不会因为使用同一型号，就自动知道客服的内部指令或评分答案。 本页提到的这些任务没有需要额外 AI 判卷的自然语言题目， 评分主要依靠原生程序中的数据库等检查。
一次典型过程是：
顾客提出换货需求 → 客服询问身份信息 → 程序返回查询结果 → 客服说明方案 → 顾客确认 → 客服提交操作 → 检查程序核对结果。
我们把实际发生的对话、指令和返回结果保存下来。 这样遇到问题时，可以找到具体发生在哪一步，而不只看到一个总分。
我们先搭了什么工具？
我们已经完成第一版实验工具，并公开发布了 v0.1-offline 版本。
它能固定实验设置、保存对话、在评分之前留下记录、生成报告，并区分不同失败情况。
例如，客服把事情办错、评分程序出错、网络没有连通，是需要分别记录的情况。 我们还加上了明确批准后才能付费运行、请求数量上限、费用预算和逐笔对账。 这些工作让后面的比较有依据，也帮助避免“记录没保存却以为实验成功了”。
我们先找到了什么问题？
第一步：先确认整个流程能走通
我们先选了一道简单的购物题，让模拟顾客和 AI 客服真正交谈， 让程序执行工具操作，再进行评分和费用核对。
结果：这次任务获得原生满分，完整记录和账单也保存成功。 它说明实验流程可以运转。早期出现过网络限流和本地检查拦截， 这些启动问题单独保留，没有当成客服能力的失败。
第二步：找“顾客改主意后，客服还按旧要求办”的错误
例如，顾客一开始想退两件商品，临近确认时改成只退一件。 我们关心客服提交的操作有没有跟上最后的要求。
在实际到达这个决定点的三道题里，客服都按顾客的新要求提交了。 因此，这几次没有找到预先要找的业务错误。 小范围表现正确，并不能说明它在所有类似购物问题上都可靠。
另外一道题在身份核验阶段停住。题目给模拟顾客一个账号字符串和邮编， 没有把姓名单独写清楚；同时又要求它不要编造未知信息。 客服询问姓名时，模拟顾客反复说自己无法提供，后面的换货过程就没有开始。
这让我们注意到：测试题提供的信息和模拟顾客的理解，也会影响结果。 这道题继续保留零分，并注明“还没有走到要观察的决定点”。
第三步：找“需求清楚，但客服改错订单或商品”的错误
我们又选了三道需要分清订单或商品的题目。 例如，有两件相似商品时，客服要找到真正要退的那件；换成新款时，也要检查库存。
这三次的目标订单和商品参数都正确，原生评分都是满分。 我们仍然没有找到符合预定条件的错误写入。
不过，看完整记录时，我们发现了一个工作步骤上的偏差： 客服会在一条回复里打包发出多个查询。
“一条消息里多个调用”到底是什么意思？
假设顾客有四个订单。电脑收到的客服指令可能长这样：
一条助手消息：查订单 A；查订单 B；查订单 C；查订单 D。
模拟商店的规则要求每次最多发出一个工具调用。 我们希望看到：
先查订单 A → 等程序返回 → 再决定要不要查订单 B。
这里统计的是一条助手消息里装了几条电脑指令。 程序收到一组指令后，仍可能依次执行它们；这页没有用这个数量推断电脑是否真正同时运行。
在选中的例子中，客服最后确实把三项业务操作办成了，原生评分为满分。 同时，它在查订单和查商品目录时出现了两条打包消息。 任务结果和步骤是否遵守规则，由此成为两项需要分别检查的事情。
两版操作卡到底怎么试的？
第一版：直接提醒“每次只调用一个工具”
我们给客服增加了这两句话：
每条助手消息最多发起一个工具调用。收到结果后，再决定下一次调用或回复用户。
其它设置尽量固定，工具调用方式仍由客服自己决定。 我们又运行了一场完整模拟对话。
结果：打包消息从原来两条变成三条，业务任务仍然满分。 对话最后，模拟顾客又问起退货标签的获取方式，并要求转人工， 因此也没有满足事先要求的正常结束条件。
这次没有通过我们的联合验收。 一次前后比较还不足以说明新增打包消息或转人工一定是操作卡造成的。
接着：把对话暂停在同一个位置，只看下一步
完整对话里，客服说法不同，顾客的下一句话也可能不同。 为减少这种影响，我们保存了客服作决定前的内容， 让“没有操作卡”和“有操作卡”分别读同一段历史，各回答一次。
你可以把它想成把同一张考卷放到同一道题前，只比较接下来写下的那一步。 我们还核对了实际发出的请求内容，确认成对输入只有操作卡的差异。
这轮共采了六条回复。在查订单、查商品、确认后写入三个位置，结果如下。 表中的数字表示一条回复里的电脑指令数量：
| 决定点 | 没有操作卡 | 有第一版操作卡 |
|---|---|---|
| 下一步查哪个订单 | 4 条 | 4 条 |
| 下一步查哪个商品目录 | 3 条 | 3 条 |
| 顾客确认后先提交哪项修改 | 1 条 | 1 条 |
前两点没有改善。最后一点在没有卡时已经做到一次一项， 所以这次也没有观察到改善空间。 这些单步检查只保存回复，不执行它提出的工具操作。
第二版：把提醒写成流程，再加一个通用例子
我们把操作卡展开成：
选一个能推进任务的下一步 → 发出一个工具调用 → 结束当前消息 → 等真实结果返回 → 再决定下一步。
卡片还举了“先查询对象 A，得到结果后再查询 B”的例子。 它没有写入测试题的订单号码或参考答案。
在两个查询位置各做一对比较，共采四条回复。 结果仍然是查订单四条对四条、查商品三条对三条。 更详细的流程和示例在这两个上下文中没有达到目标。
再检查：最简单的指令，能不能传进去并生效？
连续没有变化，让我们有必要检查基础调用通道。 我们用四个很小的合成请求做对照：
- 要求只回答一个固定短语，在不提供工具和提供工具两种情况下分别试一次。
- 提出一个需要查询工具的简单请求。
- 保持查询请求相同，通过接口参数禁止工具调用，再试一次。
四项都符合预期。 两次固定短语都正确返回； 允许查询时出现一次合理调用，禁止调用时没有调用。
这支持了最简单条件下的指令响应和工具开关可用。 复杂购物任务中的“一次只做一项”仍需要单独验证。
再试位置：把同一张卡移到整段系统指令的最后
我们保留第二版原文，只比较“无卡”“原位置”“末尾位置”。 固定一个订单查询决定点，预先安排两轮，共采六条回复。
| 检查 | 无卡 | 原位置 | 末尾位置 |
|---|---|---|---|
| 第一轮：一条回复里的指令数 | 4 | 4 | 1 |
| 第二轮：一条回复里的指令数 | 4 | 4 | 4 |
第一次，末尾位置确实只查了一个合理订单。 第二次使用相同的输入和相同的随机设置，却又打包查了四个订单。
我们记录了一次局部改善，也记录了它没有重复出现。 提前约定的“两轮都有效”没有达到，因此当时没有进入完整任务验证。
最后一次稳定性复核：换三组固定设置，全部如实报告
为了判断这个位置效果能否保持，我们另行冻结了一次小实验： 三组固定随机设置，每组比较三个位置，每个位置重复两次，共十八条回复。 出场顺序也提前安排，避免总让同一条件先回答。
十八条回复全部打包发出四个订单查询。 没有出现一次符合要求的合理单调用，也没有建立跨设置的位置优势。
我们因此执行了事先约定的停止规则：暂停这个单工具操作卡候选。 之前那一次局部改善仍保留在记录中，这一轮的新结果也完整保留。
总共做了多少？
截至 2026 年 11 月 11 日，本页覆盖：
- 8 道不同购物测试题的原始表现：先看看客服在没有新增操作卡时怎样做。
- 1 场额外的完整操作卡对话：与第 23 号题的历史原始表现比较。
- 38 条单步诊断回复：六条第一版比较、四条第二版比较、四条基础通道检查、六条位置比较、十八条稳定性复核。
前两项合计是九场已完整保存过程的模拟对话； 其中一道题在核验阶段结束，业务请求没有完成。 三十八条单步回复属于局部检查，不能折算成三十八次完整任务成功或失败。 早期没有成功完成的启动尝试另行记录。
在这些已完成运行中，真实模型费用都做了逐笔核对。 有时账单明细先出现、账户总额稍后更新，我们会保存暂停记录，再按授权只读复查。 费用核对不会重新生成对话。
想对照旧记录？查看题目编号和实验数量
题目编号只是原生题库中的标识，编号本身不表示难度或次数。 原始表现使用 0、72、6、84、92、23、35、79 八道题； 完整操作卡实验使用第 23 号题。 局部诊断中的购物上下文也来自第 23 号开发题，四条基础通道检查使用合成内容。
这个开发题是看到步骤偏差后选中的，已被反复查看和调试。 预留的新题 18、96 没有启动验证，不能算作已完成的独立检验。
现在可以得出什么结论？
已经做成：一套能够追查过程的实验工具
我们能知道给模型发了什么、它原样返回了什么、程序执行了什么， 并把任务评分、步骤偏差、网络问题和费用记录分开。 基础执行链路已经走通，最小指令控制也有实际证据。
已经观察到：把事情办成，还需要另外检查做事步骤
同一次购物任务可以满分，同时出现多条指令打包的现象。 因此，我们分别记录“订单是否处理正确”和“是否按规则操作”。 简单总分无法自动回答所有过程问题。
尚未证明：操作卡能带来稳定、可迁移的改善
第一版提醒、第二版流程示例，以及位置调整，都没有达到预定的稳定改善标准。 一次局部阳性没有在后续复核中保持。 我们目前还没有证据说这个项目已经让客服的业务能力提高了。
这些结果限定于已测的操作卡、模型、路由和上下文。 其它类型的规则、其它问题或模型是否有效，仍需要新的证据。 复杂上下文中为什么没有按要求限制调用数量，具体原因也尚未唯一定位。
还没有开展：完整任务收益和新题验证
后续单步实验没有产生原生任务成绩。 我们尚未完成同期完整交互对照、预留任务验证，或专门改进评分标准的实验。 因此，核心想法“从失败中提炼经验，再让 AI 在新任务上更好”仍是研究目标。
下一步会做什么？
当前的决定是保留这条分支的全部结果，并暂停继续调整同一张单工具卡。 下一步选题需要重新围绕一个确实影响业务结果的具体错误： 顾客明确要求了什么、客服当时已经知道什么、它第一次做错的动作是什么。
新实验开始前，还需要确认模拟顾客掌握足够的信息， 避免再次让题目信息歧义挡住本来要观察的行为。 只有在开发例子上出现清楚改善、完整任务仍能办成之后， 才值得把规则固定下来，到没有用于改卡的新题上检查。
这一页记录的是已做过的工作和当前决定。新的付费实验会另行冻结方案、批准后执行。
常见词怎么理解？
- Agent：能说话、也能调用工具采取行动的 AI；这里主要是客服。
- Skill：本项目当前测试的额外操作提示，可以理解成一张操作卡。
- Baseline：没有新增操作卡时的原始表现，用来比较改变前后。
- 工具调用：AI 发给程序的一条操作指令，例如“查这个订单”。
- 执行轨迹（trajectory）：实际发生的对话、调用和工具返回记录。
- 种子（seed）：用来固定随机过程起点的参数。它帮助记录条件，远端服务仍可能返回不同结果。
- 原生奖励：原测试环境给的任务分数。本页里的满分为 1.0，范围以该题的评分规则为准。
- 新题／预留验证：用没有参与操作卡修改的题目，检查效果能否延伸到开发例子之外。