DialFork 专测 Agent“步骤幻觉”：工具调用全对，任务也可能跑偏

Idiap Research Institute 与 Logitech 近日发布了 DialFork，试图补上对话式 Agent 评测中长期缺失的一块：模型有没有按照规定的步骤，把该问、该确认、该告知的内容按顺序说完。项目作者在 2026 年 11 月初的发布说明中称，这是首个专门衡量“程序性幻觉”的基准。

程序性幻觉（procedural hallucination）是指 Agent 的单轮回答可以流畅、事实可以正确、工具调用也可以无误，但整体对话没有继续遵守预先定义的流程。 它既不是传统意义上的事实幻觉，也不等同于调用不存在的工具，而是任务执行顺序和交互义务发生了偏移。

这个问题比“回答错了”更隐蔽，因为它经常看起来一切正常。

例如，用户要求查询天气，Agent 正确调用天气工具，也拿到了准确预报，但它没有把结果告诉用户，而是直接跳到“请为本次服务评分”。从工具日志看，调用名称、参数和返回值全部正确；从最终任务看，用户依然不知道天气，核心目标实际上没有完成。

DialFork 测的不是“会不会做”，而是“有没有照流程做”

DialFork 是一个面向对话式 Agent 的流程遵循评测基准。 按照团队目前披露的方法，它通过模拟带有既定工作流的多轮对话，检查 Agent 在每个节点应该说什么，以及这些对话动作是否以正确顺序发生。

传统 Agent 评测通常把注意力放在工具调用上，因为工具调用最容易结构化：选了哪个函数、参数是否符合 Schema、返回值是否有效，都可以直接比较。天气查询应当调用天气服务，预订酒店应当提交日期和城市，转账操作应当提供账户和金额，这些都有明确字段。

真正的业务流程却不只由工具调用组成。很多关键节点没有任何函数可以记录，例如：

• 在执行高风险操作前，向用户复述金额并请求确认；
• 在信息不完整时，追问缺失字段；
• 在工具返回结果后，把结果明确告知用户；
• 在出现多个候选项时，请用户选择，而不是擅自决定；
• 在操作失败后解释原因，并提供可执行的下一步；
• 在结束会话前确认用户的问题是否已经解决。

对话动作（dialogue act）是 Agent 在某一轮承担的交互功能，例如询问、确认、告知、拒绝或结束会话。 DialFork 的关键价值，就是把这些长期被当成“自然语言包装”的动作提升为可评估对象。

换句话说，过去的评测更像是在检查外卖员有没有找到正确的餐厅、拿到正确的餐；DialFork 进一步检查他有没有把餐送到用户手上，而不是拿到餐后直接让用户打五星。

三类错误不是一回事

程序性幻觉构成了事实准确性和工具使用正确性之外的第三条评测轴。 三者可能同时发生，也可能彼此完全独立。

| 评测维度 | 核心问题 | 典型失败 | 工具调用可能正确吗 | 常见检测方式 | |---|---|---|---|---| | 事实准确性 | Agent 说的内容是真的吗 | 把明天最高温 18℃说成 28℃ | 可以 | 标准答案比对、事实核查 | | 工具使用正确性 | Agent 是否选择了正确工具和参数 | 调错天气服务，或城市参数填错 | 否 | Tool-call F1、Schema 准确率、执行成功率 | | 程序遵循正确性 | Agent 是否完成了规定的对话步骤和顺序 | 查到天气却不告知用户，直接结束或索要评分 | 可以 | 对话动作识别、步骤覆盖率、顺序约束检查 | | 最终任务成功率 | 用户目标最终是否真正完成 | 系统显示成功，但用户没有获得结果或确认 | 可以 | 端到端验收、用户状态检查 |

工具调用评测可以发现“调用了不存在的函数”“参数类型错误”“本来不该调用却调用”等问题，但它无法自然识别“工具结果没有被转述给用户”。这正是 DialFork 要切开的盲区。

工具调用成功不等于任务成功，是这次发布最值得开发者重视的结论。 一个系统即使把工具选择准确率做到很高，只要遗漏了确认、告知或异常处理步骤，仍然不适合进入金融、医疗、售后和企业审批等强流程场景。

为什么这类错误一直没有被认真测量

现有 Agent 指标偏爱机器可验证事件，因此天然低估了自然语言步骤的重要性。 函数名称和 JSON 参数是离散结构，容易自动打分；“是否已经向用户清楚说明结果”则涉及语义判断，表达方式还可能有几十种。

例如，“未来两小时有雨”“建议现在带伞”和“降水概率为 80%”都可能完成告知义务，但简单关键词规则很难判断它们是否等价。反过来，一段包含“天气”与“降雨”关键词的客套话，也未必真的传达了工具结果。

只看最终答案同样会漏掉危险的中间步骤。 一个金融 Agent 最终可能完成转账，但如果它跳过了金额确认，这次结果碰巧正确也不能证明流程安全；一个客服 Agent 最终可能关闭工单，但如果没有先确认问题已解决，关闭动作本身就是违规。

使用大模型充当裁判也不能自动解决程序性幻觉。 LLM Judge 擅长判断回答是否自然、相关和完整，却可能被流畅表达误导；如果评分提示中没有明确列出流程状态、必经节点和顺序约束，裁判模型同样可能给“说得很好但做错顺序”的轨迹高分。

程序性幻觉因此不是普通的“上下文漂移”换了一个名字。上下文漂移通常指 Agent 在长任务中逐渐偏离最初目标，例如分析销售数据时转而花大量时间修格式；程序性幻觉更强调违反一个可以明确描述的交互程序，包括漏步、抢跑、重复、乱序和提前终止。

DialFork 真正改变的是评测单位

DialFork 把 Agent 的评测单位从单次回复或单次工具调用，扩展到了完整对话轨迹。 这意味着评测者不能只问“这一轮说得对不对”，还要问“在当前状态下，这一轮是不是应该做这件事”。

一条任务型对话可以抽象为状态机：收集信息、验证信息、请求确认、调用工具、解释结果、处理异常、结束任务。每一步都有进入条件和退出条件，而 Agent 的自然语言输出与工具调用只是状态迁移的外在表现。

以预约维修为例，合理流程可能是：

1. 询问设备型号和故障现象；
2. 检查保修状态；
3. 提供可预约时段；
4. 等待用户选择；
5. 复述时间与地址并请求确认；
6. 创建预约；
7. 告知预约编号和改期方式。

如果 Agent 在第 3 步看到一个空闲时段就直接创建预约，它可能调用了正确工具，也可能得到有效预约编号，但仍然跳过了用户选择和最终确认。对一般聊天机器人来说，这只是体验问题；对真实业务系统来说，这可能是一次未经授权的操作。

流程分叉是对话式 Agent 最容易失控的位置。 用户可能补充信息、改变目标、拒绝建议或插入一个新问题，Agent 必须在回答插入问题后回到原流程，而不是把局部话题当成新的主任务。DialFork 关注“说什么、按什么顺序说”，正适合暴露这种分叉之后无法归位的情况。

不过，截至 2026 年 11 月 5 日，团队在公开发布帖中没有完整列出样本规模、全部参评模型、逐模型得分和统计置信区间。现阶段更稳妥的判断是：DialFork 提出了一个重要且可操作的评测维度，但其区分度、覆盖范围和榜单稳定性，仍需结合后续论文材料、数据集和复现实验判断。

开发者应该怎么补这道防线

最有效的改进不是继续堆更长的系统提示，而是把对话步骤变成可观察、可验证的系统状态。 如果“必须告知查询结果”只藏在数千字提示词中，它很容易在长上下文和多轮插话里失去权重；如果系统明确记录 result_obtained 与 result_disclosed 两个不同状态，遗漏就更容易被发现。

1. 把语言步骤当成一等事件

Agent 的询问、确认和告知都应该进入执行轨迹，而不是只保存工具日志。 开发者至少需要记录当前流程节点、预期对话动作、实际对话动作、工具结果是否已被用户感知，以及任务结束的理由。

这类轨迹能够区分两个看似相同的“成功”：一个是后端工具执行成功，另一个是用户目标完成。两者之间往往还隔着解释、确认和异常处置。

2. 给每个关键节点设置前置条件

高风险动作必须由代码层约束，而不能完全依赖模型自觉。 转账前必须存在有效确认，创建订单前必须锁定用户选择，关闭工单前必须确认解决状态；如果前置条件不满足，即使模型生成了正确工具调用，也应当被执行层拒绝。

这与防止工具参数错误的 Schema 校验类似，只是校验对象从“参数是否合法”扩展到了“流程状态是否合法”。

3. 分开评估工具成功和交互成功

一张总分表无法解释 Agent 到底错在哪里。 更合理的评测面板应分别报告工具选择、参数正确率、步骤覆盖率、步骤顺序准确率、未经确认的动作次数、工具结果告知率和最终任务完成率。

如果只报告端到端成功率，团队很难知道优化提示词后究竟减少了哪类错误；如果只报告工具调用准确率，又会把 DialFork 所揭示的问题直接抹掉。

4. 专门测试插话、拒绝和改口

正常路径通常不是 Agent 最脆弱的路径。 真正有价值的测试应该包含用户中途追问、临时改期、否定上一轮信息、提供相互矛盾的条件，以及在确认阶段突然切换话题。

这些测试不一定要求模型知识更强，却会显著增加流程恢复难度。Agent 回答完插入问题后，能否回到原节点继续确认，往往比它能否调用工具更能反映产品成熟度。

5. 让裁判看到明确的流程规范

LLM Judge 只有拿到可验证的步骤定义，才适合判断程序性幻觉。 评测输入应包含当前状态、允许的下一步、必须完成的语言动作、禁止提前执行的动作，以及结束条件，而不是笼统询问“这段回答是否合理”。

对于高风险场景，最好同时采用确定性规则和语义裁判：规则检查顺序、授权和必经节点，大模型判断自然语言是否真正完成了询问或告知。两者结合，比让一个模型从头到尾凭感觉打分更可靠。

这项基准对 Agent 行业意味着什么

DialFork 的意义不在于再造一个模型排行榜，而在于提醒行业重新定义“正确执行”。 过去一年，Agent 产品普遍强调更强的推理、更长的上下文和更高的工具调用成功率，但企业真正关心的通常是稳定遵循 SOP、保留授权边界和正确处理异常。

一个能做复杂推理的模型，未必是最可靠的流程执行者。较强模型可能更主动，也更容易根据局部上下文“自作主张”调整流程；较弱但受严格状态机约束的系统，反而可能在固定业务中更加稳定。

程序性幻觉也会影响当前流行的多 Agent 架构。 当一个规划 Agent 把任务交给执行 Agent，再由汇总 Agent 回复用户时，工具结果可能在节点之间正确传递，却没有任何节点负责最终告知；每个子 Agent 都完成了局部职责，整个系统依然漏掉最后一步。

这类问题无法单靠更好的基础模型彻底消失。 模型升级可以降低漏步概率，但流程约束、状态管理、轨迹观测和回归测试仍然是应用层责任。把所有可靠性问题都归结为“等下一代模型”，对生产系统并不现实。

判断：这是一个小切口，但击中了 Agent 落地的大问题

DialFork 选择的切口不大，却比许多综合跑分更接近真实业务事故。 用户很少关心 Agent 的参数格式是否漂亮，他们只关心系统有没有听懂要求、有没有先征得同意、有没有把结果说清楚。

这项基准目前最大的价值，是给一种常见却难以命名的失败提供了清晰概念：Agent 没有说假话，也没有调错工具，但它没有完成自己承诺遵守的程序。概念一旦被定义，开发者才能为它建立指标、测试集和上线门槛。

这项基准目前最大的局限，是公开材料中的量化信息仍然有限。没有完整样本构成、模型榜单和人工一致性数据，就暂时无法判断它对不同语言、行业流程和开放式对话的覆盖能力，也不能证明某个模型在 DialFork 上领先就一定更适合生产环境。

对正在部署客服、预约、审批、金融或设备控制 Agent 的团队来说，DialFork 已经足够构成一次评测提醒。 下一次检查执行日志时，不要只看工具有没有调用成功，还应多问一句：工具返回之后，Agent 是否把该说的话说了，并且是在正确的时间说的？

参考来源

• DialFork 发布说明与作者介绍：Idiap Research Institute 作者对程序性幻觉、天气查询案例及评测目标的说明。
• Agent 上下文漂移与工具调用幻觉梳理：用于对比上下文漂移、工具调用错误与流程跑偏等不同失败模式。
• Agent 跑偏与轨迹观测讨论：介绍通过执行轨迹和系统级评估发现 Agent 隐蔽错误的实践背景。