第二期中文交互式Agentic任务测评结果发布：Kimi K3领跑！

发布时间：2026-07-21来源：CLUE中文语言理解测评基准

# 背景介绍

之前我们基于τ² Bench的双控制核心技术，针对中文场景进行深度本土化适配，构建覆盖电信领域、外卖点单、电商零售、电子政务、购票服务5大领域的评测体系，该基准旨在评测大语言模型驱动的Agent在双控制中文环境下的工具调用能力。智能体需要在多轮对话里遵守域策略（policy）、正确进行工具调用（tool use）、并且关键地——指导用户用“用户侧工具”完成必要操作（双控制协作）。

2026年4月，我们发布了该基准的首期测评结果，详情可见：从工具调用到双控制协作：AgentCLUE-Task首测出炉，国产模型表现如何？

为了持续跟踪大模型的进展，我们基于原版测评方案（详情见：中文交互式Agentic任务测评基准方案发布！）使用全新数据集对 6 个海内外的大模型进行了第二期测评，本次测评各模型平均每题的交互轮数近32轮，以下是测评详情：

SuperCLUE官网地址：www.SuperCLUE.ai

# AgentCLUE-Task榜单概览

1. 总榜

2. 得分与成本

3. 得分与token消耗

4. 得分与耗时

5. Token效率对比

# 测评结论

1. Kimi-K3(max)以49.50分夺得榜单第一。
在本次AgentCLUE-Task中文交互式任务测评中，Kimi-K3(max)以49.50分超过GPT-5.5、Claude-Opus-4.7等海外头部模型，取得榜单第一的成绩。
K3平均每题消耗 1897.51 token，仅次于GPT-5.5和Opus-4.7，在6个模型中token消耗较少；K3每千token得分为26.09，token效率排在第三位，与GPT-5.5和Opus-4.7的差距超过10分，token效率有一定的提升空间；K3的平均每题成本为1.37元，位于高性价比区间；推理耗时是K3需要提升的方向，其平均每题的耗时达到了3.78分钟，远超其他模型。
2. 输出token量与得分呈负相关，冗长输出未转化为性能增益。
六个模型的平均每题输出token长度跨度极大，从最精简的GPT-5.5(high)（1223 token）到最冗长的Gemini-3.1-Pro-Preview(high)（5353 token），相差4.4倍；而总分与输出token长度呈现负相关（相关系数约 -0.27）。最典型的是Gemini-3.1-Pro-Preview(high)：它以全场最高的 5353 token平均输出，却只拿到43.56分，每千token得分仅8.14分，token效率垫底——大量token消耗并未转化为任务完成质量，可能存在冗余推理或重复输出的问题。相比之下，GPT-5.5(high)和Claude-Opus-4.7(high)都以约 1224 token的精简输出拿到了47.52分和44.55分，每千token得分分别为38.86和36.38，是Gemini的4.5倍以上。
另外，国内的两个开源模型GLM-5.2(max)和DeepSeek-V4-Pro(max)的token效率都较低，分别为15.90和12.33，仅高于Gemini-3.1-Pro-Preview(high)，与Kimi-K3(max)相差10分以上。
3. 任务耗时与得分相关性较弱，推理时长并非质量的决定性因素。
总分与平均每题耗时的相关系数仅约0.33，呈弱正相关，耗时长短不能稳定预测任务完成质量。耗时最长的Kimi-K3(max)（3.78分钟/题）虽获得最高分49.50 分，但其耗时为GPT-5.5(high)（0.82 分钟）的4.6倍，总分仅高出约2分；从时间效率维度看，GPT-5.5每分钟得分达58分，为K3（13.1分/分钟）的4.4倍。此外，耗时2.37分钟的GLM-5.2(max) 得分仅37.62分，而耗时不足其一半的 Deepseek-V4-Pro(max)（1.01分钟）与其分差仅3分。

# 榜单详情

# 基准介绍

一、场景划分

AgentCLUE-Task大模型交互式任务测评基准方案旨在评测大语言模型驱动的Agent在双控制中文环境下的工具调用能力。

AgentCLUE-Task一共有5大考察场景：telecom（电信领域）、delivery（外卖点单）、ecommerce（电商零售）、railway（购票服务）、egov（电子政务）。

以下是各场景的介绍：

1. telecom（电信领域）

对齐 τ²-bench telecom ，场景覆盖大量通信故障排查需要用户端操作（开关飞行模式/蜂窝数据、重启、检查设置等）。

2. delivery（外卖点单）

覆盖外卖平台最常见的“下单-支付-配送-售后”闭环，并显式引入用户端操作（双控制），例如“用户在 App 里确认地址/选择支付方式/...”。

3. ecommerce（电商零售）

比外卖更丰富的商品/物流/售后政策，强调“用户端确认/举证”动作，如选择退货方式、确认收件信息、填写发票抬头等。

4. railway（购票服务）

覆盖查询车次、候补、选座偏好、改签退票、乘车人管理等；双控制点可以落在用户端：选择乘车人、完成人证核验、确认支付、出示/刷新电子票等。

5. egov（电子政务）

模拟“线上办事大厅/政务 App”的典型流程，天然需要用户端动作（上传材料、实名认证、短信验证等）。

五大场景工具数量统计：

本次 AgentCLUE-Task 中文交互式任务测评基准共设计了132个工具，其中包括电信领域（telecom）的47个工具、外卖点单（delivery）领域的29个工具、电子政务（egov）领域的20个工具、电商零售（ecommerce）领域的19个工具，以及购票服务（railway）领域的17个工具。

从工具的使用权限和类型来划分，这132个工具具体包括：

Agent（智能体）可用工具：共计69个，其中包含43个读（read）工具和26个写（write）工具。

User（用户）可用工具：共计63个，其中包含34个读（read）工具和29个写（write）工具。

调用不同数量工具的题目分布：

本次测评所有调用工具数量的题目分布如下图所示，其中调用5个工具的题目占比最高，达到了33.01%，其次是调用4个工具的题目，占比为27.18%，占比第三的是调用6个工具的题目，这三类题目共占75.72%，其余题目占比约1/4。

二、评分方法

通过比对模型完成任务后数据库状态（DataBase）和参考的数据库状态是否一致、以及检查模型调用的所有函数（动作序列）是否正确来判断此任务是否成功，如果数据库状态一致且所有函数调用正确，那么该任务通过，得1分；如果数据库状态不一致或者函数调用出错，那么该任务不通过，得0分。计算所有通过的任务数量和总任务数量的比例，得到该模型的得分，即通过率（success rates）——也就是 Pass^1 指标。我们对每个模型进行了三轮测评，模型的最终分数取三轮测评结果的平均分。

# 示例展示

【场景】：购票服务

【需求】：订单改签

【对话流程】：

以下是文字展示：

Agent：

您好，请问有什么可以帮您？

User：

我要把订单 R100001 改签到 2026-03-01 的 G105 次列车，还是北京南到上海虹桥，优先二等座，如果需要补差价也可以。

Agent（思考过程）：

用户想要改签订单R100001到2026-03-01的G105次列车，还是北京南到上海虹桥，优先二等座，可以补差价。根据政策，改签前需要先列出操作明细并获得用户明确确认。另外，需要先检查订单状态是否允许改签（已支付或已改签？）。政策规定：改签仅支持单程单段订单改签，改签会根据新旧订单价差进行补收或退款。用户需要确认操作明细。但首先，我需要获取订单详情，以确认订单信息，包括当前车次、日期、席别、乘车人、订单状态等。使用工具get_order_details。Agent调用工具：get_order_details，传入order_id参数: R100001
Agent接收工具调用的结果后进行思考，思考过程：
订单详情显示：订单状态为“已支付”，可以改签。当前是G101次列车，日期是2026-03-01，从北京南到上海虹桥，二等座。用户想改签到同一天（2026-03-01）的G105次列车，同样的行程，优先二等座。我需要检查G105次列车在2026-03-01是否有余票和价格。使用get_train_details工具。
Agent调用工具：get_train_details
Agent接收工具调用的结果后进行思考，思考过程：
G105次列车在2026-03-01有可售状态，二等座余票2张，价格553元，与G101次列车二等座价格相同（都是553元）。所以改签到G105次列车二等座，价格相同，无需补差价。现在需要向用户列出操作明细并获得确认。根据政策：在执行任何会更新购票数据库的操作之前，必须先用清晰的要点列出将要执行的操作明细，并获得用户明确确认（「是/确认/同意」）后才能继续。然后调用request_change_ticket工具。操作明细应包括：订单号、原车次、新车次、日期、席别、价格变化等。我需要先列出明细，然后询问用户是否确认。现在用文本回复。
Agent：
根据您的改签需求，我已经查询了相关信息。以下是操作明细：
**改签操作明细：**
- **订单号：** R100001
- **原车次：** G101（2026-03-01，北京南→上海虹桥，二等座）
- **新车次：** G105（2026-03-01，北京南→上海虹桥，二等座）
- **发车时间：** 09:00（原车次G101发车时间为08:00）
- **到达时间：** 14:40（原车次G101到达时间为13:40）
- **席别：** 二等座
- **票价对比：** 原订单553元，新车次553元（价格相同，无差价补退）
- **乘车人：** 1人（姓名：李华）
- **订单状态：** 已支付（符合改签条件）
**重要提示：**
1. 改签后，原车票将作废，不可再次使用
2. 新车次G105发车时间比原车次G101晚1小时，请注意行程安排
3. 本次改签不涉及价格变动，无需补缴或退还费用
请确认以上信息无误，并回复「是」、「确认」或「同意」以继续改签操作。

User：确认改签，没有差价的话我就同意。

Agent（思考过程）：

用户回复“确认改签，没有差价的话我就同意。”这符合明确确认的要求。现在可以调用request_change_ticket工具了。需要提供参数：order_id（R100001）、new_train_no（G105）、new_date（2026-03-01）、new_seat_class（二等座）。注意new_date和原订单日期相同，都是2026-03-01，没问题。调用工具。

Agent调用工具：request_change_ticket，传入参数:

"order_id": "R100001",

"new_train_no": "G105",

"new_date": "2026-03-01",

"new_seat_class": "二等座"

Agent接收工具调用的结果后进行思考，思考过程：

工具返回结果显示，pending_action已创建，confirmed为false。根据政策，需要引导用户在客户端完成最终确认提交（用户侧confirm_action_request）。所以需要告知用户改签请求已提交，需要在客户端确认。现在回复用户。

Agent：

已为您提交改签请求。请您在客户端查看并确认改签操作，系统将在您确认后执行变更。

**改签请求详情：**

- 订单号：R100001

- 新车次：G105次列车

- 新日期：2026-03-01

- 新席别：二等座

- 发车时间：09:00

- 到达时间：14:40

请在您的客户端「订单详情」页面中完成最终确认。确认后，订单将正式改签至G105次列车，原车票将失效。

如有其他问题，请随时联系。

User调用工具：confirm_action_request，传入参数：

"name": "李华",

"order_id": "R100001"

User接收工具返回结果

User：###STOP###

任务结束

# 参测流程

1.邮件申请

2.意向沟通

3.参测确认与协议流程

4.提供API接口或大模型

5.获得测评报告

# 邮件申请

邮件标题：AgentCLUE-Task「中文交互式任务」测评申请，发送到contact@superclue.ai

请使用单位邮箱，邮件内容包括：单位信息、大模型简介、联系人和所属部门、联系方式

# 联系我们

转载说明：本文系转载内容，版权归原作者及原出处所有。转载目的在于传递更多行业信息，文章观点仅代表原作者本人，与本平台立场无关。若涉及作品版权问题，请原作者或相关权利人及时与本平台联系，我们将在第一时间核实后移除相关内容。