路由策略

引言 2026年，一个生产级Agent可能需要调用数百甚至上千个工具。从发邮件到查数据库，从写代码到部署服务，工具是Agent与物理世界交互的桥梁。但工具数量增长带来了一个棘手的问题：Agent如何从数百个工具中选择正确的那个？ 这不是一个简单的匹配问题。用户说"帮我看看昨天那个数据"，Agent需要理解"昨天"是哪天、“那个数据"指什么、应该从哪个数据源查、用什么查询语言。工具选择架构的设计直接决定了Agent的能力边界。 一、工具选择的挑战 1.1 规模挑战 当工具数量少于20个时，可以将所有工具描述放入LLM上下文，让模型直接选择。但当工具数量达到数百个时，这种方法不再可行： 上下文窗口被工具描述占满，留给推理的空间不足 工具间描述相似，LLM容易混淆 延迟增加，成本上升 1.2 语义挑战 用户意图与工具描述之间往往存在语义鸿沟。用户说"把这个发给老板”，Agent需要理解这是要发邮件，收件人是"老板"，内容是"这个"（需要从上下文解析）。 1.3 组合挑战 有些任务需要组合多个工具。例如"帮我查一下竞品最近的价格变化并生成报告"需要：搜索竞品列表→查询各竞品价格→对比分析→生成报告文档。工具选择不仅要选对单个工具，还要规划正确的执行顺序。 二、工具选择架构分层 2.1 工具索引层 工具索引层负责工具的注册、描述和索引。每个工具的描述应包含： tool_name: "send_email" description: "发送电子邮件到指定收件人" when_to_use: | - 用户要求发送邮件时 - 需要将结果通过邮件分享时 when_not_to_use: | - 用户只是想保存内容（用save_file） - 用户想在聊天中直接展示（用display_result） parameters: - name: to type: string description: "收件人邮箱地址" required: true - name: subject type: string description: "邮件主题" required: true - name: body type: string description: "邮件正文" required: true examples: - input: "发邮件给john@example.com，主题是项目更新" output: "send_email(to='john@example.com', subject='项目更新', body='...')" cost: "low" latency: "medium" 2.2 工具路由层 工具路由层是架构的核心。当Agent接收到用户请求时，路由层负责从工具池中筛选出最相关的候选工具。 ...