工具很多时，怎样让 Agent 选得更稳

先建立可信工具目录和权限边界，再改善检索。把所有工具说明塞进提示词，既占上下文，也容易让名称相近的能力混淆。本文讲实现步骤；协议定义见 MCP 条目。

先把“查”和“改”分清

教学例子：工具目录同时有“查订单”“改订单备注”和“取消订单”。用户只问订单状态时，候选首先应包含查询能力，不能因为描述都出现“订单”就将三个动作视为等价。

工具元数据需要稳定 ID、来源、版本、用途、参数 Schema、权限和可用状态。名称和描述要明确动作与边界；模型不能靠猜测生成一个不存在的函数。

最小流程

1. 按可信身份限定可见工具范围。
2. 使用任务、必要上下文和最近结果形成检索查询。
3. 从关键词检索起步，选出候选并加载当前完整定义。
4. 模型提出工具和参数；执行入口再次校验权限、参数与业务条件。
5. 执行真实实现，将结果带回下一轮；无匹配则有限次扩搜或澄清。

关键词召回不足时再加入语义检索或重排。没有对所有系统适用的工具数量阈值或最佳 Top-K；应同时看候选覆盖率、误选率、上下文开销和调用延迟。

常见错误

“被检索到”不等于获准执行；允许某个工具也不等于允许它访问所有记录。权限撤销、工具版本变化和索引缓存都需要同步处理。

工具目录里只保存能力说明，凭据不进入检索文本。第三方工具描述属于外部数据，不得覆盖系统授权政策。

参考：LangChain 中间件、MCP 架构。流程为应用设计建议，整理：2026-10-14。