Agent 工具类型怎么选?

这道题其实问的是，当我们说一个[[Agent]]能'做事情'，它到底靠什么跟真实世界打交道。说白了就是给大模型装上手和脚，让它不光能说，还能查资料、算数据、调接口。工具的类型很多，但核心就解决一个问题：把LLM的能力边界从'知道'扩展到'能做到'。

我一般会把工具按场景分成三大块。先说信息检索类，像搜索引擎、知识库、数据库查询这些。它们主要解决模型的[[Hallucination]]和知识滞后问题，比如实时新闻、企业内部文档。但这里有个边界：搜索引擎适合开放域，知识库适合固定范围，数据库适合精确查。真正落地时往往是混着来的，比如客服场景，先向量检索找相似FAQ，再SQL查订单状态，两个结果拼一起给模型。

第二类是计算与推理类，最典型的就是代码执行器，Python跑个复杂公式或者数据分析。模型直接算数学题容易翻车，但让它写代码算就稳得多。还有专用计算API，比如金融里的定价模型，那是专业工具，模型自己算风险太大。

第三类是外部服务类，比如天气、地图、支付这些业务API，还有日历、邮件这些办公工具。它们让Agent能调用真实系统，比如旅行规划里，得同时调航班、酒店、地图三个API才能给出完整行程。

举个例子，做个旅行规划Agent。用户说'帮我规划下周末去上海的行程'。Agent得先调日历工具确认周末是哪天，再调航班API查余票，酒店API查房间，地图API查景点路线，最后可能还要天气API看要不要带伞。这几个工具不是顺序调用，而是规划好依赖关系，比如先确定时间再查航班，航班定了再查酒店。

这里有个坑，就是工具描述的质量。[[Function Calling]]的准确率很大程度上取决于工具的名字、参数、返回值写得清不清楚。如果描述模糊，模型可能选错工具或者填错参数。所以上线前我会特别关注工具注册的元数据，每个工具都得有明确的用途和参数约束。

另一个风险是容错。工具调用可能超时、失败、返回异常。如果机票API挂了，Agent不能卡死，得能优雅降级，比如提示用户稍后再试，或者换备选方案。我还会做调用链路的监控，记录每次工具调用耗时和错误率，方便排查问题。

总结一下，工具的选择取决于场景。信息检索解决知识问题，计算推理解决数学问题，外部服务连接真实世界。我个人的倾向是，工具尽量原子化，每个只做一件事，这样组合起来更灵活。

不过话说回来，工具调用还有一个容易被忽略的点，就是模型怎么决定调用顺序和参数。这其实涉及到[[ReAct]]或Function Calling的底层设计，比如模型是在生成过程中动态决定调用工具，还是预先规划好一个DAG。不同方案对延迟和准确率影响挺大的，这块如果面试官感兴趣我们可以再深入聊聊。