调了三天Prompt，Agent还是总把工具参数传错，求大佬指点迷津

校验和重试逻辑肯定得加，这属于工程底线，别指望模型能100%按schema来。另外你可以试试把参数约束直接写进工具描述的开头，比如“customer_id是8位数字，order_id是纯字母”，模型对具体格式的敏感度比抽象schema高得多。日期这种，干脆在Prompt里不给具体值，让它输出相对日期表达式，后端再解析成绝对时间，能少很多幻觉。

我之前也踩过这个坑，后来发现光靠prompt真的压不住模型对参数的“自由发挥”。我的做法是给每个工具单独接一个小的校验函数，传参前先强制过一遍类型和必填项，错了就直接返回错误让模型自己纠错，比单纯重试高效得多。另外日期这种相对时间，我干脆在prompt里写成“今天是几号，上周指哪几天”，让它先算出来再填，错误率降了不少。

说实话这种问题我碰到过挺多次，后来发现别光在prompt上死磕，直接在代码里做一层参数校验和自动修正比啥都靠谱，比如日期就按自然语言解析后格式化，ID就按类型正则匹配。另外可以试试把工具定义里的参数描述改成“客户ID（纯数字）”这种带约束的写法，模型犯错率会降不少。不过老实说，完全靠模型自觉不现实，重试逻辑还是得留着，只不过别在用户层面重试，内部静默纠正就行。

校验和重试必须加，但更建议让模型先输出意图再填参，把参数生成拆成两步。

校验和重试是必须的，但更建议你试试把参数拆成多轮追问，别让模型一次填完。

说实话，这种问题本质是模型对语义理解不稳，你不如直接给日期算好再传，别让它算。

校验和重试肯定得加，但更建议你试试把参数抽取从主prompt里拆出来，单独用一次结构化输出调用专门做参数解析，这样能把工具调用的自由度压缩到最小。另外日期这种就别让模型自己算了，直接把“上周一”到“上周日”的具体日期算好塞进上下文，能少一半幻觉。你那个customer_id和order_id搞混，大概率是schema里字段语义不够区分，试试把描述改成“查询对象所属客户编号”这种带上下文的说法。

我之前也踩过类似的坑，后来发现光靠prompt很难根治，因为模型对“相对时间”和“字段语义”的理解本身就飘忽不定。建议你试试把参数值转换成绝对可计算的逻辑，比如在System层用代码生成时间戳，而不是让模型自己算日期。另外工具定义里可以加上字段之间的互斥或关联约束，比如明确写“当传入order_id时忽略customer_id”，比单纯堆示例管用。校验和重试肯定是得加的，但最好做成自动纠错而不是简单报错，比如检测到日期范围不合理就自动替换成系统时间再确认一次。

校验和重试是必须的，但更建议在schema里加枚举值和范围约束，能挡掉不少低级错误。

试试把日期计算直接写死在Prompt里，让模型输出相对值而不是绝对值，我之前这么干效果好很多。

校验加重试是必须的，但更建议把参数从自然语言里拆出来让模型做选择而不是生成，能稳不少。

试试把日期计算也丢给工具，让模型只传“上周”这种相对词，后端自己换算，错误率会低很多。

校验和重试才是正解，模型这玩意儿没法100%保证，别跟它死磕Prompt。

说实话这问题我太懂了，之前搞内部工具Agent也卡在这。后来发现光靠Prompt真不够，工具定义里除了schema，把每个参数加上常见错误值示例（比如日期格式）反而更管用。另外就是别指望一次调对，我在代码里加了层参数校验，不符合就自动带上下文重试一次，成功率能拉到95%以上。你试试看是不是模型对日期计算特别容易飘，这种直接让模型算日期范围本身就不靠谱，不如让它先调个函数拿当前日期再算。

这种参数幻觉我也踩过，根子往往不在Prompt，而在模型对时间、ID这类语义没有真实理解。你试试把“上周”这种相对表述在进入模型前就转成明确日期，别让它自己算。customer_id和order_id搞反，可以在schema里把字段名写得更啰嗦，比如user_customer_id，并给每个字段配上容易混淆的反例。校验和重试该做还得做，但只能兜底，前置消歧才是省token的关键。

这个参数幻觉我踩过一模一样的坑，日期算错和ID串位简直是Agent的两大经典翻车现场。后来发现光靠Prompt确实治不了根，模型对相对时间（“上周”）的推理本来就弱，你再怎么强调schema它也还是按自己的理解填。我的做法是把相对时间在进入模型之前就转成绝对日期，比如在上下文里直接注入“今天是2025-03-10，上周指2025-03-03到2025-03-09”，让它没机会自己算。ID串位那个更隐蔽，本质是字段语义太像，模型分不清哪个是客户哪个是订单，我后来在工具描述里给每个参数都加了一句“这个值长什么样”的说明，比如customer_id是C开头的字符串，order_id是纯数字，命中率明显上来了。另外校验和重试肯定得做，但别只做兜底，可以把校验失败的报错信息回灌给模型让它自己改，比单纯重试有效得多。还有个思路是拆工具，别让一个工具同时干查数据和发通知两件事，参数空间小了出错率自然降。说到底Prompt能优化的上限有限，工程上把不确定性挡在模型外面才是正解。

这事我太有共鸣了，之前做内部工单Agent也是被参数传错折磨得够呛。后来发现光靠Prompt真不太行，模型对“上周”这种相对时间根本没概念，它只会按训练数据里的模糊印象去猜，你写得再清楚它也可能给你编一个看起来合理的日期。我的做法是把时间解析这类逻辑从模型里剥出来，让它只负责传“上周”这个语义标签，后端拿到后再统一转成具体日期范围。至于customer_id和order_id搞反，我试过在Schema里把字段名写得更啰嗦，比如customer_id_客户唯一标识，居然有点用，模型对长字段名的语义匹配会准一些。另外可以试试把工具调用拆成两步，先让模型输出一个中间结构比如要调哪个工具、参数意图是什么，再单独做一轮参数填充，这样错误定位也容易。校验和重试肯定要留，但别把它当主力，不然延迟和成本都扛不住。我现在更倾向把容易混的参数做成枚举或者让模型从候选里选，而不是让它自由生成，稳定性提升挺明显的。

参数传错这事太常见了，我去年做内部工单Agent时也踩过一模一样的坑，日期算错和ID混用简直是标配。后来发现光靠Prompt约束基本没用，因为模型本质上是在做概率生成，不是在做逻辑推理，你给再多schema它也只是“参考”而不是“执行”。真正管用的做法是把参数校验从模型侧挪到代码侧，比如日期这种让它只传相对描述（“last_week”），由后端映射成具体区间，ID类字段则在tool定义里把类型和枚举写死，让它没机会填错。另外function calling本身其实对参数名敏感度不高，你可以在工具描述里把每个字段的“来源”说清楚，比如customer_id只能从用户原话里提取，order_id必须来自上一步查询结果，这样能压掉一部分混淆。few-shot确实有用但别放太多，三五个典型错例就够了，放多了反而让它学偏。还有个偏方是用两个模型分工，一个专门抽参数一个专门调工具，中间加一层校验，虽然成本高点但稳定性提升明显。兜底的重试逻辑肯定要有，但别把它当主方案，不然线上跑起来你会被trace日志淹没。