Agent总在胡说八道？问题多半出在「工具接地」上

一个被低估的失败原因

大家讨论Agent可靠性，总盯着模型能力。但真实项目里，Agent出错的头号原因往往是”工具用错了”：该查数据库却编了数据、参数传错、调用了不存在的接口、或者干脆该用工具时却靠想象力回答。

这个问题的学名叫工具接地（tool grounding）——让模型真正”踩在地上”，基于真实工具和真实结果说话。

工具接地的四个典型故障

故障一：幻觉调用。 模型编造一个不存在的工具名或参数，任务直接失败。

故障二：该用不用。 明明有查询工具，模型却靠记忆瞎答，结果过时或错误。

故障三：参数漂移。 工具名对了，但日期格式、ID、枚举值传错，调用白费。

故障四：结果误读。 工具返回了正确数据，模型却解读反了。

这四类里，“该用不用”和”结果误读”最隐蔽，因为表面看没报错。

五个可立即落地的改进

1. 工具描述写到”傻瓜级”

模型选工具全靠描述。**别写”查询数据”，要写清楚”什么时候用、输入什么、返回什么、有什么限制”。**描述越具体，误用越少。把每个工具的适用场景和禁忌都写进去。

2. 强制”先想后调”

在流程里加一步：遇到需要外部信息的问题，必须先声明”我需要调用X工具获取Y”，再执行。这个显式步骤能大幅减少”该用不用”。

3. 参数做严格校验

让工具调用前经过一层校验：类型对不对、枚举值合不合法、必填项全不全。错误要在调用前拦住，而不是等返回报错再补救。

4. 结果回填后再回答

规定模型必须基于工具返回的内容作答，不能穿插自己的记忆。对关键字段，要求它引用原文，方便你追溯。

5. 加”自我核对”环节

任务结束前，让Agent做一次自检：**我用到的每个事实，来源是工具还是我的猜测？**任何说不清来源的，要么补调用，要么明确标注不确定。

一个务实的测试方法

别只测”顺利情况”。专门构造工具失败、返回空、返回异常数据的情况，看Agent会不会傻乎乎地编下去。能优雅降级（比如说”查询失败，请稍后重试”）的Agent，才配进生产。

工具接地和模型能力的关系

模型越强，工具接地的收益越大——因为它更会”见机行事”。但反过来说，工具接地做不好，再强的模型也白搭。这是工程问题，不是靠换个更贵的模型能解决的。

一句话总结

Agent不靠谱，先别急着换模型，回去看工具描述、参数校验、结果回填和自我核对这四关。把工具接地做扎实，Agent的可用性会有肉眼可见的提升。