Agent 系统可调用哪些工具?

这道题问的是[[Agent]]系统能调哪些工具，但我觉得面试官真正想听的不是列清单，而是你怎么理解LLM和外部世界的边界。说白了，模型本身是个封闭的推理引擎，它不知道实时股价，不会算复杂的数学，更动不了你的数据库。所以工具的本质是给模型装上一双眼睛和两只手，让它能看、能算、能操作。

工具类型我能分三大类。先说信息获取类的，比如搜索引擎、知识库检索、数据库查询。这类工具解决的是模型知识截止和[[幻觉]]的问题。举个例子，客服场景里用户问‘我上周的退款到账了吗’，模型不可能知道，它得调一个订单查询API，把用户ID传进去，拿到结果再回答。这里有个边界：搜索引擎适合开放域，知识库适合企业内部，两者可以互补，但别混用，否则搜索返回的网页噪音会污染业务回答。

再说计算和执行类，比如代码解释器、计算器。LLM做算术经常翻车，5位数乘法都可能算错，所以精确计算必须交给外部工具。代码解释器还能做数据分析和画图，这在数据分析Agent里很常见。但这里有个风险：执行用户提交的代码要放在沙箱里，否则等于开了后门。

最后是业务操作类，像订单系统、库存API、消息推送。这类工具让Agent从回答问题变成执行动作。比如电商场景，用户说‘帮我改收货地址’，Agent先调查询API验证订单状态，再调用修改API，最后发确认短信。中间每一步都可能失败，比如订单已发货就不能改，所以工具调用必须处理错误，让模型根据错误信息决定重试还是放弃。

这些工具怎么被模型调用？核心是[[Function Calling]]机制。我们把每个工具定义成JSON Schema，包括名字、参数、返回值。模型收到用户问题后，先判断需不需要调工具，如果需要，就输出一个结构化的调用请求，系统去执行，把结果塞回给模型，模型再组织回答。选择哪个工具是模型自己决定的，一般用[[ReAct]]模式，让模型边推理边行动。

落地时有个坑：工具数量一多，全塞进上下文会爆掉。所以我会做工具检索，先把所有工具的[[embedding]]建好，用户问题来了先检索出最相关的几个工具，再让模型选。这样既省token又减少干扰。

另外我还要提一个点：工具调用失败时，模型怎么自我修正？比如API超时，模型是直接放弃还是换个工具重试？我倾向让模型试两次，如果还失败就告诉用户‘暂时不可用’。这其实引出一个更深的问题，就是Agent的鲁棒性和安全边界怎么设计，比如怎么防止模型被恶意工具调用带偏。

所以总的来说，我会把工具调用看成LLM能力的外延，关键不是堆工具，而是设计好调用协议和错误处理，让模型在可控的范围内帮用户干活。