面试题 · Agent
搜索「知识库」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请详细描述在构建AI Agent时，通常会调用哪些类型的工具，并解释每种工具的作用和使用场景。
Agent工具主要分为以下几类，每类解决不同能力边界问题：
1. 信息检索类
2. 计算与推理类
3. 外部服务类
4. 感知与交互类
使用场景示例
按学习路线查看教程、项目和面试题。
| 场景 | 工具组合 |
|---|---|
| 智能客服 | 知识库检索 + 订单API + 工单创建 |
| 数据分析助手 | SQL查询 + Python执行 + 图表生成 |
| 旅行规划 | 航班API + 酒店API + 地图API + 日历工具 |
关键设计原则
实际落地中，工具通常通过Function Calling或ReAct范式接入，需要配套的工具注册中心、权限管控和调用链路监控。
场景切入
假设你在做智能客服，用户问“帮我查一下上个月的订单”，Agent需要先查知识库、再调订单API、最后可能还要写个Python算个总额。你一般会给Agent配哪些工具？每种工具什么场景下用？
层层追问
Agent规划任务时，你觉得工具应该怎么分类？……那如果模型算数老出错，你会加什么工具？……除了计算，还有哪几类常见工具？比如要查外部数据、要操作业务系统，分别对应什么？
直球架构
请系统性地讲一下构建AI 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。不同方案对延迟和准确率影响挺大的，这块如果面试官感兴趣我们可以再深入聊聊。