工具调用是 LLM Agent 走向真实任务的关键能力。但工具一旦接入真实世界，错误调用就不再只是“答错题”，而可能变成发错邮件、删错文件、下错订单，或者消耗真实 API 成本。
近年来，大模型在函数调用、工具选择、多步规划上的能力快速提升，但在复杂任务中，Agent 仍然经常出现几类问题：
选错工具；
参数格式不符合 schema；
参数语义看似合法、实际不对；
多轮任务中漏掉关键步骤；
一个自然的想法是：让 Agent 先调用真实工具，看到执行结果后再反思、修正、重试。
但这条路并不总是安全。
真实 API 可能有费用和限流；更重要的是，很多工具调用会改变外部状态。比如发送邮件、发布推文、删除文件、取消订单、修改航班预订等。一旦调用错误，后果不一定能撤销。
这正是我们被ICML 2026 接收的论文 Gecko 想解决的问题：
能不能在真实工具执行前，先为 Agent 提供一个状态化的模拟环境，让它在模拟中试错、获得反馈、修正计划，最后再去调用真实工具？
Gecko 是什么？
论文的全名是：
A Simulation Environment with Stateful Feedback for Refining Agent Tool Calls
Gecko缩写取自关键词：agent+feedback+environment
它是一个面向 LLM Agent 工具调用的状态化模拟环境。
简单来说，Gecko 给 Agent 提供了一个“工具调用沙盒”。在这个沙盒里，Agent 可以先尝试执行工具调用计划，Gecko 会根据工具 schema、任务目标和当前状态，返回一系列反馈：
这个工具名和参数是否合法？
如果工具被调用，可能会返回什么结果？
任务是否已经完成？如果没完成，还差什么？
这些反馈会被用于下一轮工具调用修正。
最终，当 Gecko 判断某条模拟轨迹已经能完成任务时，这条轨迹会作为 in-context guidance 提供给真实工具 Agent，让它在真实环境中完成最终执行。
Gecko 的核心组件
Gecko 由五个关键组件构成。
组件 |
作用 |
|---|---|
API Schema Converter |
将工具定义转换为 OpenAPI schema，为后续验证、路由和响应生成提供统一结构 |
Argument Validator |
检查工具名、必填字段、参数类型、schema 约束和语义合理性 |
Response Generator |
基于工具 schema、候选调用和当前状态，生成符合 schema 的模拟响应 |
Task State Estimator |
维护任务状态，记录多轮工具调用后任务进展如何变化 |
Task Feedback Generator |
判断任务是否完成，并把未完成原因反馈给 Agent |
1. API Schema Converter
不同工具通常有不同的描述格式。Gecko 会先把工具定义转换成 OpenAPI schema，让后续校验、路由和响应生成都有统一的结构化依据。
这一步保证 Gecko 能面向大量工具扩展。
2. Argument Validator
Agent 生成工具调用时，最常见的问题之一就是参数错误。Gecko 的参数校验分为两层：
第一层是规则校验，例如：
工具是否存在；
required 参数是否缺失；
是否传入了 schema 中不存在的字段；
参数类型是否正确；
enum、range、format 等约束是否满足。
第二层是语义校验。
有些约束无法完全写进 schema，只能通过自然语言描述表达。比如某个字段要求传入股票 ticker，那么 "Apple Inc." 虽然是字符串，但语义上不如 "AAPL" 合适。Gecko 会结合工具 schema、任务上下文和候选参数，判断参数是否语义合理。
3. Response Generator
如果工具调用通过校验，Gecko 会生成一个符合 schema 的模拟响应。
这里不是“随便编一个返回值”，而是要满足两点：
响应格式符合真实工具的 schema；
响应内容和当前任务状态保持语义一致。
因此，Gecko 的响应生成会结合当前工具调用、OpenAPI schema 和当前估计的任务状态。这样可以让多轮工具调用中的模拟结果保持连贯。
4. Task State Estimator
很多 Agent 任务不是单次调用能解决的，而是多步、多轮、带状态变化的过程。
Gecko 会维护一个估计的任务状态，记录当前任务进展。每次模拟工具调用后，任务状态都会被更新。
例如文件是否已经移动、订单是否已经取消、航班是否已经改签等，都可以被抽象成状态。
这个状态不仅用于判断计划是否在推进任务，也会被后续的 Response Generator 参考，用来生成与当前环境一致的模拟工具响应。换句话说，Gecko 不是孤立地为每一次调用生成返回值，而是在一个持续更新的任务状态上进行模拟：前一步的结果会影响后一步的反馈，成功、失败和约束变化也能在后续调用中体现出来。
因此，Task State Estimator 是 Gecko 实现 stateful simulation 的核心组件之一。它让模拟环境能够记住已经发生过什么，并基于这些状态为 Agent 提供更接近真实执行过程的反馈。
5. Task Feedback Generator
最后，Gecko 会把当前任务状态和用户目标进行对比，判断任务是否完成。
如果没有完成，它会生成任务级反馈，告诉 Agent 问题在哪里、下一步应该关注什么。
这和普通的工具报错不同。普通报错通常只告诉你某个调用失败了；Gecko 的反馈更接近“任务层面”的判断：这个尝试还没有完成目标，因为 temp 文件夹没有按用户要求创建在 document 文件夹下。
这类反馈对多步任务尤其重要。
GATS：基于 Gecko 的测试时扩展方法
在 Gecko 之上，作者提出了 GATS：Gecko Agent Test-time Scaling
它的流程可以概括为五步：
初始化 Gecko session，加载工具 schema 和任务状态；
Planning LLM 在 Gecko 中生成候选工具调用轨迹；
Gecko 对轨迹进行校验、模拟响应、状态更新和任务判断；
如果任务失败，把失败轨迹和反馈返回给 Planning LLM，继续重试；
如果任务成功，把成功轨迹作为上下文指导，交给使用真实工具 Agent 执行。
这里有一个重要设计：
失败的模拟尝试不会污染后续尝试。每次 retry 都会从相同的初始 Gecko 状态快照开始。
这让 Agent 可以安全地探索不同工具调用方案，而不会把失败尝试的副作用带入真实环境。
为什么需要模拟？
对 Agent 来说，工具调用不是普通文本生成。它更像是在真实系统里执行操作。
以一个简单文件操作任务为例：
请把
report.pdf移动到document文件夹下的新建temp文件夹中。
Agent 可能第一次生成：
mkdir(temp)mv(report.pdf, temp)
这看似合理，但如果 temp/ 被建在了当前目录，而不是 document/ 目录下，任务其实失败了。
传统做法可能需要真实执行后才发现问题。
而在 Gecko 中，这个计划会先在模拟环境里运行：
Attempt 1:mkdir(temp)mv(report.pdf, temp)Gecko feedback:Task failed. temp/ is beside document/, not under it.
然后 Agent 可以根据反馈修正：
Attempt 2:cd(document)mkdir(temp)mv(../report.pdf, temp)Gecko feedback:Task completed.
这时，成功的模拟轨迹再被交给真实工具 Agent，指导它完成真实执行。
这就是 Gecko 的核心价值：
让 Agent 在真实行动前，先在模拟世界里预演计划并获得反馈。
实验：提升工具调用能力，减少真实工具试错依赖
Gecko 和 GATS 在两个工具调用 benchmark 上进行了评估：
Benchmark |
任务特点 |
|---|---|
BFCLv3 |
包含 non-live single-turn、live single-turn 和 multi-turn |
𝜏²-bench |
面向真实零售和航空场景，包含用户交互、领域 API 和业务规则 |
结果显示，GATS 能稳定提升多种 LLM 的工具调用能力。
和其他测试时方法相比如何？
GATS 不只是“多采样几次”。作者还将它与 Reflexion、Self-Refine、Best-of-N、Majority Voting 等方法对比。
在两个设置下，GATS 都取得了最高性能，同时真实工具调用开销保持在合理范围内。
这说明 Gecko 能在真实执行前提供有效的纠错信号。
数据库依赖场景下的 Hybrid Adaptation
在真实业务系统中，工具调用通常不只面对一组静态 API，还会依赖背后的数据库状态。这个数据库可能很大、结构复杂，并且包含大量任务相关的隐含事实。
这会给模拟环境带来一个挑战：如果 Gecko 完全模拟所有工具返回，那么它不仅要理解 API schema，还要尽可能复刻真实数据库中的内容和查询语义。一旦数据库状态没有建模完整，read-only 查询的返回结果就可能和真实环境不一致，进而影响后续计划判断。
因此，在 𝜏²-bench 的 airline 和 retail 场景中，Gecko 采用了一种 hybrid adaptation：
read-only 工具直接访问真实数据库，减少隐藏数据库带来的模拟偏差；state-changing 工具仍然由 Gecko 模拟，避免在试错阶段产生真实副作用。
这样做的核心不是简单地“有些工具真实、有些工具模拟”，而是按工具风险和状态影响进行分层：读取类工具主要追求信息一致性，写入类工具主要追求安全可控。
这个设计也说明 Gecko 并不要求所有工具都必须被完整模拟。更实际的做法是根据部署环境选择合适的边界：对低风险、只读的信息获取使用真实系统；对高风险、会改变状态的操作保留沙盒模拟。通过这种方式，Gecko 可以在尽量贴近真实环境的同时，仍然为 Agent 的试错和修正提供安全缓冲。
Gecko 的意义
Gecko 代表了一种 Agent 设计思路：
为 Agent 建立一个可反馈、可重试、可维护状态的模拟层。
这件事的价值不只在 benchmark 提分，它还可能成为 Agent 工具使用的基础设施：
测试时优化
Agent 在执行前先通过模拟反馈修正计划，提高真实执行成功率。
数据合成
Gecko 可以生成高质量工具调用轨迹和失败-反馈-修正样本，用于 SFT。
强化学习环境
原本静态的工具调用数据集，可以通过 Gecko 转化为可交互的 RL 环境。
项目信息
论文：Gecko: A Simulation Environment with Stateful Feedback for Refining Agent Tool Calls
Project Page: https://camel-ai.github.io/gecko
Code: https://github.com/camel-ai/gecko
Paper: https://arxiv.org/abs/2602.19218
THE END
往期内容推荐：
