夜雨聆风你的AI装了一堆工具，为什么还在"凭嘴回答"？
问题从来不是工具不够，是它压根不知道该用哪个。
01 我遇到最尴尬的一件事
我本地跑的那套AI工作流，说出来够唬人的——
长期记忆文件、技能库、跨平台搜索、浏览器自动化、小红书MCP、爬虫、出图、Zep/Letta记忆服务、GitHub、Docker、一堆API……
但真到干活的时候，画风是这样的：
我说："帮我查一下某个赛道最近的资料。"
它回："好的，我从以下几个方面帮您分析……"
然后它开始纯靠常识往外蹦字。
我不是没有工具。我是工具全装了，AI根本没调度起来。
02 最大误区：工具装了，不等于AI会用
现在大家都在往Claude Code、Codex、Cursor上接工具。
Web Search、Browser-Use、Scrapling、xhs-mcp、TikHub、Zep、Letta、GitHub CLI、各种MCP……
但都跳过了一个关键问题：
工具"挂上去了"，跟"AI知道什么时候该用它"，是两码事。
更别说让它判断——
这活儿该调哪个工具？ 哪几个工具得串起来用？ 谁先上谁后上？ 挂了怎么办？ 哪些事儿可以自己干了再汇报，哪些必须先请示？
这些没想清楚，工具越多越抓瞎。
最后就是：你攒了10把刀，它切菜还是用手撕。
03 真正缺的那一层：运行时路由
我后来想明白了一件事：问题不在某个工具不好使，是中间缺了一层。
用户指令进来，不应该直接丢给模型"自由发挥"，而应该先过一道判断：
指令 → 识别任务 → 拆解能力需求 → 匹配工具 → 判断风险 → 调用/确认 → 失败降级 → 输出
我把这层叫运行时工具路由层。
它就干一件事：搞清楚当前任务到底需要什么能力。
举个实际例子——
用户说："查一下最近小红书上儿童水杯的用户痛点。"
你以为只是一句"搜索"？错了。这句话背后藏着5个能力需求：
小红书平台检索 笔记/评论/标题/发布时间的内容抓取 从用户原话里提炼痛点的归纳能力 按你习惯的格式输出的偏好调取 参考你之前做过的同类分析的经验回溯
系统不该只调一个搜索了事。
它应该先拆能力清单，再去工具池里找谁能干这活儿。
04 别写死"搜索=某某工具"
我一开始也走过弯路——给每个工具写死触发规则：
搜索 → Agent Reach 开网页 → Browser-Use 偏好 → Zep 小红书 → xhs-mcp 出图 → Agnes AI
短期没问题。长期一定崩。
因为工具会不断迭代替换。今天用Agent Reach，明天换Perplexity，后天加TikHub，后面还有视频解析、飞书、Notion……
每来一个新工具就改一遍总规则，越改越乱。
所以正确姿势不是"任务→工具名"，而是：
任务 → 能力需求 → 谁有这能力就谁来
打个比方——公司里不是"所有设计活都找张三"，而是"这活儿需要UI+动效+品牌能力，谁有谁来"。
工具调度也是同一个逻辑。
05 我的解法：工具注册表 + 路由规则
我把方案拆成了两块：
一块叫runtime_tool_router，负责判断：
用户要干嘛？ 需要哪些能力？ 哪些能自动调？哪些必须先问？ 挂了怎么降级？ 什么时候查偏好？什么时候查经验？
另一块叫tool_registry，负责记录：
当前有啥工具 每个工具有啥能力 触发词是什么 风险等级 挂了降级给谁 当前能不能用
每个工具不是写个名字就完事，得有一张"工具身份证"。
比如Agent Reach这张卡长这样：
能力标签： cross_platform_search / link_discovery / competitor_search
适用场景： 跨平台搜索、找资料源、找竞品、找热点
触发词： 全网、跨平台、找链接、竞品、对标
风险等级： 只读，低风险，可自动调用
失败降级： WebSearch → Browser-Use → Scrapling
再看Browser-Use这张卡：
能力标签： browser_automation / dynamic_page_read / web_detail_extract
适用场景： 打开网页、读取动态页面、翻页、看评论、看价格
风险分级：
只读浏览 → 可自动调用 涉及登录/发布/提交 → 必须人工确认
失败降级： WebFetch → Jina Reader → Scrapling
新工具进来怎么办？补一张卡，结束。 整个路由体系不用动。
06 自动调用 ≠ 乱来
一说"AI自动调工具"，有人就慌：它会不会乱删文件？乱push代码？乱花API钱？
所以必须划清边界。
低风险、只读、可逆的——直接干，别墨迹：
搜公开网页 打开你给它的URL 抓公开内容 读本地文件 查记忆和经验 出草稿和提示词
用户都说"查一下"了，你还问"需要我帮您查吗"——这不是谨慎，这是添堵。
高风险、不可逆的——必须先过你这一关：
删/覆盖文件 Git commit / push 发布内容 登录账号 付费操作 改数据库、Docker核心配置
好的Agent：该主动时不犹豫，该请示时不擅作主张。
07 一句"请你智能调用工具"为什么没用？
很多人觉得，我在prompt里加一句"请你根据任务智能调用工具"就够了。
不够。远远不够。
因为这句话太抽象了。AI需要的是可执行规则，不是口号。
可执行规则长什么样？
用户说"查一下" → 识别为搜索任务 → 提取能力：web_search → 查注册表 → 匹配Agent Reach/WebSearch → 找到链接后需要web_detail_extract → 匹配Browser-Use → 涉及用户格式偏好 → 匹配Zep → 涉及同类经验 → 匹配Letta → 输出
这才叫可执行。
否则AI只会说"好的我注意"，然后下次照旧纯嘴输出。
08 五层架构，各管各的
我现在跑的体系分五层：
第一层 Memory——用户偏好、行为规则、错误日志、长期上下文
第二层 Skills——写作、出图、搜索、商业分析、工作流、开发
第三层 Tool Registry——工具能力、触发词、降级方案
第四层 Runtime Router——任务判断、能力匹配、风险确认、失败降级
第五层 Reference——具体工具的安装/调用/限制/状态
每层只干自己的活儿。新工具加入，动注册表那一层就行，其他不用碰。
09 别把所有规则塞进一个超大prompt
我以前也犯这个错：恨不得把所有规则写进一个巨型prompt。
结果？上下文浪费，模型分不清主次。
正确做法是按需加载——
普通聊天，不用加载工具说明 写文章，不用读Git工作流 出图，不用管爬虫配置 查小红书，不用看出图模板 改代码，不用读公众号排版规则
开机只读核心规则，干活时再按需读取。
10 这套东西解决的不是"一个工具不好用"
短期看，它解决的是：AI为什么不调工具？
长期看，它解决的是：工具越来越多，Agent怎么保持秩序？
没有注册表 → 工具越多越乱 没有路由层 → AI不知道什么时候该动手 没有风险分级 → 要么啥都不敢干，要么啥都敢干 没有降级方案 → 工具一挂，任务就死 没有长期记忆 → 每次都不知道你喜欢什么格式 没有经验回溯 → 同样的坑次次踩
本质上，这是把AI从"聊天助手"推进到"工作系统"。
聊天助手的逻辑：你问一句，我答一句。
工作系统的逻辑：你给目标，我拆任务、调工具、查记忆、借经验、跑流程、交结果。
11 如果你也在折腾AI工作流
别一上来就疯狂接工具。先干三件事：
第一，盘清楚你现有的工具。 搜索、浏览器、爬虫、出图、记忆、代码、平台、自动化——先分个类。
第二，给每个工具打能力标签。 别光写名字。写清楚：它能解决什么需求？适合什么场景？挂了谁顶上？
第三，写一份运行时路由规则。 哪些任务主动调工具、哪些必须确认、失败怎么降级、什么时候查记忆、什么时候查经验。
做到这三步，你的AI才真正像一个能干活的助理。
否则，你只是有一堆工具，但它不会用。
写在最后
以前觉得AI Agent的命门是模型能力。
跑了几个月才发现，模型只是底座。
真正拉开差距的，是这几件事：
记忆体系 · 技能体系 · 工具注册 · 运行时路由 · 风险分级 · 经验沉淀
工具越来越多以后，最扎心的不是"我没有工具"。
而是——我有工具，但它不知道什么时候该用哪个。
下一阶段AI Agent的竞争，不是谁接的工具多，是谁的调度体系更像一个真正的工作系统。
能被正确调用的工具，才有价值。
觉得有用？转给你那个工具装了一堆、但AI还在靠嘴输出的朋友。
