解决Agent工具调用僵局：当拦截词策略失效后的重构思路

最近在折腾自托管机器人的时候，遇到了一个颇为尴尬的局面：为了强行让某些'偷懒'的模型调用工具，我写了一堆拦截词。结果呢？工具是调用了，但代码逻辑也变得像一团乱麻，最后把自己坑死了，完全推不动重构。

这事儿在开发圈里其实挺常见，尤其是今年大家在搞各种 Agent 的时候。今天就来复盘一下这个问题，并聊聊怎么从'硬补丁'走向'正规军'的架构思路。

🤔 问题的根源：模型与工具的博弈

场景是这样的：原本我的机器人实现了一个简单的 Agent Loop（代理循环），但在对接某些特定模型（比如 5.4 mini 版本）时，发现模型特别'佛系'。你让它查天气、搜资料，它倾向于在那儿瞎编或者用内置知识'自问自答'，就是不愿意挂载外部工具。

起初的暴力解法： 为了解决这个'偷懒'问题，我采取了一种简单粗暴的策略——关键词拦截。在用户的输入层加了一堆 if-else，只要命中特定的指令词汇，就强制绕过模型的自然意图判断，直接把工具扔给它。

后果：

1. 维护灾难： 拦截词列表越来越长，稍微改一句逻辑，可能就要测试几十个场景。
2. 灵活性归零： 用户换个说法，系统就不认识了，体验极差。
3. 模型能力浪费： 强行插入上下文，干扰了模型原本的推理能力。

到了 2026 年，这种'打补丁'式的开发方式显然已经跟不上 Agent 智能化的节奏了。

🛠️ 参考 Codex 的思路：全量托管与优雅退出

项目 qq-maid-bot 示意图

既然硬行不通，那就得看看成熟方案是怎么做的。研究了 Codex 的代码逻辑，发现它的核心哲学是：信任模型，但保留控制权。

Codex 的做法并不是预先拦截，而是让用户输入直接进入 Agent Loop。这时候只有两个分支：

1. 闲聊模式： 模型判断不需要工具，直接结束本轮循环。
2. 任务模式： 模型自行决定调用工具，进入工作流。

为什么这样更稳？ 这把'是否调用工具'的判断权交还给了 LLM（大语言模型）。现在的模型，哪怕是轻量级的 Mini 版，在 System Prompt 设计得当的情况下，区分'闲聊'和'指令'的能力其实已经相当不错了。强行拦截反而是在告诉模型：'我不信任你，你必须听我的。'

💡 针对群聊场景的重构方案

回到我的痛点：在群聊场景下，不可能直接上顶配的大模型（成本和延迟都扛不住），但又必须保证 Mini 模型能干活。

与其写死拦截词，不如尝试以下这套三层过滤架构：

第一层：轻量级语义路由

在进入主 Loop 之前，用一个极小的模型（或者嵌入模型）跑一次快速分类。

• 如果是纯粹的打招呼、表情包回复 -> 走简单的预设模板回复，不消耗 Token 调用大模型。
• 如果包含任务意图 -> 放行进入 Agent Loop。

第二层：System Prompt 强约束

不要在代码逻辑里写拦截词，而是把'工具癖好'写在 System Prompt 里。

• 负面提示： 明确告诉模型'严禁使用未提供的知识回答实时信息'。
• 工具优先： '在回复用户前，必须先检查是否有相关工具可用'。

第三层：Codex 式 Loop + 熔断机制

参考 Codex，让流程跑起来。如果模型连续两轮都没有调用任何工具却还在输出，就触发熔断，强制返回一句提示语：'不好意思，这个问题我需要工具辅助，暂时无法解决。'

这样做的好处是，代码里没有任何关于'天气'、'时间'这类具体的拦截词，全是逻辑控制，以后想换模型或者加工具，都不用动核心代码。

🚀 实际落地建议

如果你现在也面临着'代码改不动'的困境，不要试图去修复那些 if-else，直接推倒重来一层路由层可能是最快的。

1. 剥离意图识别： 把'这是什么问题'和'怎么回答这个问题'分开。前者用小模型或规则，后者用 Agent Loop。
2. 拥抱'失败'： 承认 Mini 模型有处理不了的边界，与其让它胡说八道，不如优雅地报错或降级处理。
3. 工具定义要清晰： 很多时候模型不调用工具，是因为工具的 Description 写得太烂。检查一下你的工具描述，是否清晰地告诉了模型什么时候该用它。

Agent 的开发本质上是在调度和约束之间寻找平衡。当我们放弃了'驯服'模型的执念，转而设计一套允许模型'自我表达'但边界清晰的流程时，代码往往就会豁然开朗。

希望这个思路能给同样在折腾 Bot 的朋友一点启发，别让拦截词成为技术债，早重构早解脱。