← 返回 PaperDaily 大模型与智能体

香港中文大学TREK：不用LLM裁判的硬核基准，15个模型全军覆没

继2026年6月聊过EvoMAS和MemInsight之后，又发现一个评估LLM智能体旅行规划能力的硬核基准TREK。它完全不用LLM作为裁判，直接检查每个航班、酒店是否真实存在，时间是否可行，预算是否超支，甚至能检测出用户没明说的隐性需求！结果连最先进的GPT-5.6也才46.2%通过，真是让人大跌眼镜。建议所有做LLM agent的团队都来跑一跑这个基准

龙哥读论文发布于 2026-08-14 09:11:58 阅读 3 查看原文

#大语言模型 #Agent #数据集 #AI应用

原论文信息如下：

论文标题:
TREK: A Travel Reasoning and Evaluation Kit for LLM Agents in Complex Trip Planning

发表日期:
2026年7月

发表单位:
香港中文大学 (The Chinese University of Hong Kong)

原文链接:
https://arxiv.org/pdf/2607.26977v1.pdf

开源代码链接:
https://github.com/TonyQJH/TREK-A-Travel-Reasoning-and-Evaluation-Kit-for-LLM-Agents-in-Complex-Trip-Planning

【龙哥导读】每次假期来临，你是不是也遇到过这样的场景：打开某个旅行 App，输入目的地，期待 AI 帮你一键生成完美行程，结果它给你推荐了一个“北京→拉萨→东京”的奇葩路线，或者预算算错到离谱…… 别急，这可不是你手机坏了，而是目前的大模型在“真实世界旅行规划”这件小事上，还远远不够格。香港中文大学团队带着 800 个硬核任务、完全不用 LLM 当裁判的评测基准 TREK 来了，结果连最强的 GPT-5.6 都只拿到 46.2% 的通过率——太打脸了！

旅行规划为何成为LLM智能体的“照妖镜”？

龙哥一直觉得，旅行规划是检验 LLM 智能体能力的“终极副本”——不是造个聊天机器人，而是让它像个合格的旅行社一样，输出一个真正可执行的方案。为什么这么说？因为一个合格的旅行计划必须是“单件制品”：它要同时满足多个硬约束——每个航班、酒店、景点必须真实存在且可预订；每日行程必须在物理上可通行（比如同一天内从一个城市飞到另一个城市再赶景点，时间要够）；总花费必须不超过预算；还要照顾到用户没说出来的隐性需求（比如带着老人、喜欢美食、希望租车）。现有的大模型往往在某个单点做得不错，比如能列出 CityWalk 路线图，但一旦把所有约束“合在一起同时检查”，立刻就露馅。TREK 这个基准的厉害之处就在于：它从根源上改变了评测规则——不再是 LLM 当裁判打印象分，而是用一套完全确定性的、基于规则的工具链，像会计师事务所审计一样，逐条验证每一个旅行元素是否真实、合规。这种“冷兵器硬核”评测，才能真正暴露智能体在复杂约束下的能力短板。

图2：TREK评测流程总览。左侧数据构建部分通过确定性管线生成内部一致的知识库，并填充出800个任务，每个任务附带人工验证的金标准行程。右侧智能体通过与生产级工具沙箱交互生成行程，最后由完全确定性的多维评估器（不含LLM裁判）进行打分。

TREK基准：从“软评分”到“确定性硬核”的跃迁

TREK (Travel Reasoning and Evaluation Kit) 这个名字听起来很硬核，它的做法也确实很硬：构建了一个包含 212,530 条记录的知识库，覆盖 375 个城市、392 个机场、13 种旅行者画像（如“带孩子旅行者”、“老年人”、“美食家”、“摄影爱好者”等），所有数据都是合成但内部一致的——注意，是“合成”但不“随机”。之所以用合成数据，是因为只有内部一致的数据才能保证确定性评估的金标准：比如某个航班从 A 到 B 确实有价格记录，某个酒店确实有房间类型，某个景点确实有开放时间，而且这些事实不会像从网上爬取的数据那样每天变动。这样，每个任务都能事先算出“理论上最佳行程”并人工核验——TREK 对全部 800 个任务（533 个可行 + 267 个不可行）都提供了人工验证的金标准答案，保证在确定性评估器下完美得 1.0 分。这意味着所有评估分数差异都只能归因于智能体本身，而不是评分标准的变化。这个基准最大的亮点是：完全不使用 LLM 当裁判。每个维度都由纯规则程序根据知识库精确计算，与智能体是否调用语义搜索无关——即使智能体内部用了嵌入模型，评估器始终只做硬性的集合交运算（比如检查预订的酒店是否包含“无障碍通道”这个设施）。这就彻底避免了 LLM-as-a-Judge 带来的位置偏见、长度偏见、自我偏好等问题。

表1：TREK与代表性规划及智能体基准的对比。评分方式包括：Rules（纯规则，无LLM裁判）、Ext.+Rules（先LLM结构化再规则检查）、DSL（可执行领域特定语言）、Sim（模拟）、Exec（执行）、Match（精确匹配）、Judge（LLM裁判）。API列表示智能体是否通过带参数验证的RESTful工具沙箱交互。Gold=1表示金标准是否能在该评估器下达到满分。Impl表示是否评估隐性需求及方式——Det为确定性，Judge为LLM裁判。Infeas表示是否包含不可行任务及类型（Typed/Untyped）。Effic表示是否有明确的工具使用效率维度。TREK是唯一同时具备单行程输出、纯规则评分、类型化API沙箱、可达金标准、隐性需求确定性评估、类型化不可行任务、效率评分这七项特征的基准。

八维联合检查：一个不可行任务如何无处遁形？

TREK 定义了 9 个评估维度（标题中的“八维”是概略说法），分成 4 类：

约束满足（D0-key, D1, D2, D3）：D0-key 检查显式要求的元素是否全部包含（如指定酒店、车类型、景点等），以及行程完整性——必须覆盖所有要求天数、每晚有住处、每天有活动。D1 是隐性需求满足，通过设施关键词集合交运算（不含任何嵌入模型）。D2 检查城市覆盖。D3 检查预算遵守——采用指数超支惩罚，超支越多惩罚越陡（β=4），超支25%得分0.37，超支50%得分0.14。

数据真实性（D0-src）：行程中提到的每个实体（航班号、酒店名、景点名等）必须在知识库中有对应记录，不能有幻觉。

可执行性（B2, B3）：B2 检查景点营业时间是否符合要求（不访问关闭的景点）；B3 检查时空可行性——同一天内不同城市间的交通必须实际可行，比如从 Baltimore 到 Denver 的航班必须存在且时间上能衔接。这是区分“规划型智能体”和“普通智能体”的分水岭。

不可行任务处理（Error Handling）：对于 267 个不可行任务，智能体必须正确拒绝并给出类型化理由（实体不存在、路线不可达、预算不足）。评估器会从任务和知识库独立推导真正的不可行原因，而不是信任标签。

图1：可行与不可行查询示例。左上角为不可行任务（无可用航班），智能体需正确拒绝；右半部分为可行任务，涉及隐式需求满足、城市覆盖、预算遵守、工具使用效率、营业时间合规、时空可行性等维度检查。下方展示了评估通过的检查项清单。

这种设计让 TREK 的评估结果“比特级可复现”：无论谁跑、什么时间跑，只要知识库版本不变，同一智能体输出的同一行程得到的分值完全相同。所有维度只在适用任务上评分（比如隐性需求只对带有画像的任务评分），因此每维度的分母是所有模型一致的基准属性。

15个模型“翻车”实录：隐性需求为何是终极瓶颈？

龙哥直接给你说结果：TREK 对 15 个 LLM 智能体进行了全面评测，覆盖 GPT、Claude、Gemma、Qwen、Kimi 等系列，完整结果绝对让你大跌眼镜。

在 533 个可行任务上，最关键指标——任务完全正确率（即所有适用维度全部通过）显示：最强模型 GPT-5.6 仅 46.2%，15 个模型的中位数低至 6.6%，最差模型为 0.0%——这意味着有大把模型一个完整可执行的行程都做不出来。

更惊人的发现是：隐性需求满足（D1）是通用瓶颈——它是唯一一个在最强模型上仍然大规模失败的维度：GPT-5.6 在 D1 上仅有 46.3% 的通过率，而其他所有维度（如城市覆盖、预算、真实性、营业时间）通过率都超过 86.7%。而且随着模型能力提升，这个瓶颈会从四面八方收缩到只剩 D1 一点：弱模型每个维度都失败，而前沿模型只在“猜用户没明说的意图”这一点上翻车。

还有一个有趣现象：时空可行性（B3）是“规划型 vs 非规划型”智能体的分水岭——顶级模型 B3 失败率 13.3%，而底层模型高达 93.8%。也就是说，即使是顶尖模型，在同一天内换城市旅行时也有 1/8 的概率物理上走不通，而大多数模型几乎完全做不到。

表2：15个模型在9个维度上的任务完全正确率（仅统计可行任务）。最右列为任务完全正确率（All）。观察发现：（1）D1隐性需求在所有模型上都是最低的，且差距明显；（2）B3时空可行性在弱模型上极低，但强模型显著改善；（3）D2城市覆盖是唯一随能力提升而单调改善的维度；（4）多城市规划会大幅拉低所有模型的表现。

思考更多≠效果更好：推理与可控性的矛盾

TREK 的一个重要特色是它提供了一个“真实世界的 RESTful API 沙箱”——不是简单的键值对查询，而是带参数验证、分页、结构化 JSON 错误的工业级接口。智能体必须自己解析错误、调整参数、重新调用，最多允许 15 次工具调用。这让龙哥想起那些号称“推理能力”强大的模型，在处理这类严格框架任务时往往出现“想太多反而出错”的尴尬——因为过度推理会让调用次数超过限制，或者产生格式漂移导致参数验证失败。

论文中 GPT-4o 与其推理版（GPT-4o-thinking）的对比印证了这一点：推理版在 TREK 上的表现反而更差。龙哥觉得这可能是因为“推理”模式会生成大量内部思考链，增加了格式错误的概率，而旅行规划本质上更多需要的是“按照工具文档精确调用 API”的能力。此外，准确率并不与花费成正比：GPT-5.6 虽然分数最高，但它每次查询的 token 成本是前几名中最低的；而一些弱模型花 5 到 7 倍的 token 量，结果却只有个位数得分。

确定性评估与黄金参考：可复现的未来

TREK 最值得行业借鉴的一点是：它提出了一套完整的工作流——从合成但一致的知识库，到生产级 API 沙箱，再到确定性规则评估器和人工验证的金标准，形成一个闭环，保证基准测试的结果可复现、可审计、无歧义。这与当前很多依赖 GPT-4 自我打分的做法形成鲜明对比。你再看中国、美国、欧洲的很多评测基准，要么测试集每天都在变，要么评估标准不透明，结果很难横向对比。TREK 的做法能从根本上解决这个问题——只要你跑同一个版本的代码和知识库，结果就是唯一的。

当然，龙哥也要指出局限性：合成数据毕竟不是真实世界数据，虽然在一致性上有优势，但无法反映真实旅行场景中价格波动、航班取消、酒店满房等动态变化。此外，隐性需求评估虽然确定性地用设施集合交运算，但可能过于简化——比如“摄影爱好者”需要的不仅仅是“有适合拍照的景点”这个设施标签，还包括位置、光线、人流量等复杂因素。不过作为首次系统性评估联合可行性并揭晓隐性需求瓶颈的基准，TREK 的意义是开创性的。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

TREK 和之前的 TravelPlanner 或 ChinaTravel 有啥本质区别？最大的区别就是确定性。TravelPlanner 是先用 GPT-4 做结构化再规则检查，评分结果不可复现；ChinaTravel 虽然用了确定性 DSL，但没有人工验证的金标准（gold reference），也没有类型化不可行任务，更没有效率维度。TREK 是第一个同时满足：纯规则评分（无 LLM 裁判）、人工验证金标准可达 1.0、类型化不可行任务（route/entity/budget）、生产级 API 沙箱、效率评分这五个条件的旅行规划基准。

隐性需求（D1）是怎么评估的？会不会很主观？完全不主观！TREK 定义画像是基于“设施关键词集合”的精确匹配。比如“美食家”画像要求行程中酒店必须有“高档餐厅”设施，景点必须包含“知名美食街”标签。评估器只做集合交运算——如果行程中的酒店确实有“高档餐厅”这个设施标签，就算满足，否则不算。没有嵌入模型、没有 LLM 打分、没有阈值。所以这个评估是 100% 确定性的。

这个基准对实际落地有什么价值？非常大。如果你在开发 LLM 驱动的旅行助手（比如携程、Booking、Expedia 的智能体），TREK 提供了一套可落地的测试框架：不依赖昂贵的 GPT-4 来打分，所有检查本地就能运行，并且能精确定位智能体在哪方面薄弱——是客服说错了航班号（D0-src），还是预算没算对（D3），还是不懂用户隐藏需求（D1）。这在真实的 A/B 测试中意义重大。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论。

龙哥点评

论文创新性分数：★★★★★

在评测方法上实现了从“软评分”到“确定性硬核”的本质跨越，提出了合成数据+金标准+规则评估的完整闭环，在旅行规划领域开创了可审计基准的新范式，与现有所有基准都有明确区分。不过并非完全无前驱——ChinaTravel 已经提出确定性 DSL 评估，但 TREK 在多个关键维度（金标准、类型化不可行、效率、API 沙箱）上做了系统性的组合创新。

实验合理度：★★★★★

15 个模型覆盖现今主流和前沿模型，包含 GPT-5.6、Claude 4、DeepSeek、Qwen 等，每个模型都有完整的 800 个任务结果，且使用了统一的确定性评估器，无任何人工扰动。对比实验的公平性极高。

学术研究价值：★★★★★

开创了“联合可行性”评测这一新视角，揭示了隐性需求瓶颈这一重要发现，为后续智能体研究提供了确定性的可复现基准。尤其对工具使用、多约束规划、隐性偏好理解等领域有重要参考价值。

稳定性：★★★★☆

评估器本身完全稳定，但合成数据与真实世界之间的差距可能会让一些人质疑其外部效度。不过作为可控实验，内部稳定性达到满分。少一星是因为缺乏对真实动态环境（航班变动、价格波动）的模拟。

适应性以及泛化能力：★★★★☆

基准采用合成但合理的数据，能支持多种旅行场景（13种画像、不同城市组合），但同样因为合成性，无法直接用于真实旅行场景的端到端系统。可以快速适配到其他多域约束规划领域（日程安排、物流规划等），但需要重写知识库。

硬件需求及成本：★★★★★

评估器只需单机 Python 环境运行，知识库也只需少量内存，速度极快。对使用方来说几乎是零成本。训练和推理成本取决于被评估的智能体，但评估本身无额外硬件需求。

复现难度：★★★★★

代码、数据集、知识库构建脚本、评估器已全部开源（GitHub TonyQJH/TREK-A-Travel-Reasoning-and-Evaluation-Kit），使用 MIT 协议，文档清晰，只需要一个 Python 环境和 API 密钥即可运行，复现极其容易。

产品化成熟度：★★★★☆

基准本身已经达到产品级可用：RESTful API 沙箱的设计可被直接用于内部测试，确定性评估器可集成到 CI/CD 流水线。如果加入真实数据层和动态 API 风控逻辑，可以直接成为旅行助手产品的离线评测平台。

可能的问题：

合成数据虽然一致性好，但无法完全反映真实世界的语言表达多样性（模板填充法可能使查询语言不够自然）；隐性需求通过设施标签评估过于简化，真实场景中用户的隐性需求可能更复杂；未考虑跨天行程的复杂约束（如每周有特定营业日的景点）；同时未考虑多人同行的组合偏好（如老人不愿意走太多路，但同行年轻人想逛很多景点）。此外，虽然作者没有宣称使用真实世界数据，但一些实际应用场景可能需要验证合成数据得出的结论是否能推广到真实用户行为。

主要参考文献

[102] Jian Xie et al. TravelPlanner: A Benchmark for Real-World Planning with Language Agents. NeurIPS 2024.
[74] Kai Liu et al. ChinaTravel: A Travel Plan Benchmark for Agent Evaluation. ACL 2025.
[112] Jiaming Zheng et al. NATURAL PLAN: Benchmarking LLM Agents on Real-World Planning. ICML 2025.
[12] Qiang Cheng et al. TravelBench: A Multi-granularity Travel Planning Benchmark. ACL 2026.
[11] Zhaolin Chen et al. TravelEval: A Simulation-based Whole-Plan Evaluator for Travel Planning. KDD 2026.
[106] Paul Denny et al. τ-bench: A Benchmark for Tool-Augmented Language Models. Under review.
[114] Shuyan Zhou et al. WebArena: A Realistic Web Environment for Building Autonomous Agents. ICLR 2025.
[39] Yichong Leng et al. SWE-bench: Can Language Models Resolve Real-World GitHub Issues? ICLR 2025.
[76] Wenting Zhao et al. A Survey of LLM-as-a-Judge: Progress, Challenges, and Opportunities. Under review.
[93] Subbarao Kambhampati et al. “LLMs Can't Plan, But Can They Help?”. NeurIPS 2024 Workshop on Planning.

论文原文链接: https://arxiv.org/pdf/2607.26977v1.pdf
开源代码: GitHub: TREK

*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！

你的LLM智能体真的会做旅行规划吗？TREK基准告诉你答案！
想和同行一起交流Agent落地、benchmark设计？欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如旅行规划+北京+北大+小张），根据格式备注，可更快被通过且邀请进群。『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群