「算法狗」最近发了篇文章，聊怎么让 LLM 老老实实调工具。标题挺有意思：阿里 P8 问候选人这个问题，候选人答「提示词写清楚就行」，面试官笑了。

问题的起点是一个查天气的例子。系统提示写了「city 必须是标准城市名，date 必须是今天或明天」，用户问「北京后天天气怎么样」，模型就开始表演——不调工具直接编答案；调了但传了工具不支持的参数 date="后天"；还有的自作主张把后天转成具体日期。

作者的核心观点：提示词只是「软推」，不是「加锁」。模型输出本质上是概率采样，没有遵守规则的强制机制。复杂场景下（输入模糊、噪音大、参数嵌套深），软推根本不够用，而且模型出错时非常自信，不会告诉你「我不确定」。

三层解法递进。第一层优化提示词，光写「不要编造参数」没用，得把每个参数的类型、边界、非法值都列出来，再加 Few-shot 示例。第二层上硬约束，用 JSON Schema 在 API 层定义参数结构，某些平台在解码阶段直接做格式约束（Constrained Decoding），从生成源头避免格式违规。第三层校验-修复-重试闭环：拿到模型输出先做语法校验，再做 Schema 验证；失败了自动清洗（去 Markdown 标记、修非法引号）；还不行就把错误信息打包重新请求。重试必须有上限，超过走降级或人工兜底。

第二层和第三层其实是互补的——Schema 管格式，校验闭环管逻辑，缺一个都会漏。

架构上主张三层分离：模型层只做决策（判断调哪个工具、生成哪些参数），框架层做执行和校验（Schema 验证、工具调用、重试逻辑），工具层做业务实现。LangChain、LlamaIndex 这些框架本质上都在做这件事——把执行可靠性从模型身上拆出来，交给成熟的软件工程实践。

评论区有几条值得看的。

最热的一条（6 赞）直接质疑 AI 的「理解」能力：AI 本来就没人类聪明，你问它天气它回答的是概率最大的答案，不是真的去「看」了什么——你问它天气，它不会去掀锅盖看水开没开。这个比喻很到位，本质上是在说工具调用的「语义鸿沟」。

有人直接挑战 Constrained Decoding：这东西会增加成本，还会破坏模型的生成分布和能力。这个观点有一定道理——结构化输出确实会限制模型的表达空间，在需要灵活生成的场景里可能是把双刃剑。

有人分享了实战：做 Agent 查内部数据，客户名不规范导致 SQL 查询失败，最后用 RAG 做了一层名称规范化才解决，流程很繁琐，问有没有更好的方法。这恰好印证了作者说的「语义层面的验证」问题——Schema 能约束格式但约束不了「上海」和「沪」等价这种业务语义。

还有人提了个工程方案：加一个「过程审查节点」，硬编码检查模型有没有调用工具，没调用就拒绝。这其实就是文章说的「框架层拦截」的一个具体落地。

最后作者提了个前沿判断：工具调用可靠性的下一个挑战不在格式，在语义——实体链接、知识图谱补全、领域特定的参数规范化。这不是 2026 年的标配，但可能是 2027 年必须面对的。

来源：算法狗 - 阿里P8问：怎么让LLM老老实实调工具？候选人答"提示词写清楚就行"。面试官笑了："那你写一个我看看。"我想90%的人栽在这。