工具调用
Function Calling 基础
什么是 Function Calling
概念解释
Function Calling（函数调用）指：大语言模型在生成回复时，不是直接输出最终答案，而是先输出「要调用哪个外部函数、用什么参数」的结构化指令；宿主程序（你的 Python 服务）真正执行该函数，再把结果喂回模型，形成多轮对话闭环。这样模型可以查实时数据、算复杂表达式、操作数据库等，突破「仅靠训练记忆回答」的限制。
原理详解
- 从接口角度：多数厂商把「可调用的函数列表」和「用户问题」一起发给模型；模型在概率分布上被训练/对齐为：在合适时输出 tool_calls（或等价字段），而不是胡编乱造函数结果。
- 从安全角度：模型不直接执行代码，执行权在应用层，便于鉴权、审计、限流。
- 与「纯文本里写 call foo(1,2)」的区别：Function Calling 使用 机器可解析 的 JSON/结构化格式，便于框架自动解析与校验。
OpenAI Function Calling 的工作原理
概念解释
以 OpenAI Chat Completions 为例：你在请求里提供 tools（函数元数据数组）和 tool_choice（可选，控制是否必须调用工具）；模型返回的 message 里可能带有 tool_calls，每一项包含 id、function.name、function.arguments（JSON 字符串）。你的代码解析后执行本地函数，再以 role=tool 的消息把结果追加到对话里，再次请求模型生成面向用户的自然语言答案。
原理详解
- 首轮：system + user + tools → 模型可能返回 assistant + tool_calls。
- 执行：应用根据 name 路由到 Python 函数，arguments 反序列化后调用。
- 次轮：把每条工具结果作为 tool 消息（带 tool_call_id）写回，再请求 → 模型综合工具输出作答。
- 并行：若模型一次返回多个 tool_calls，可并行执行（注意线程安全与副作用）。
- 流式：流式响应里 tool_calls 可能分片到达，需要增量拼接 arguments。
OpenAI 的 Function Calling 大致流程是什么？
客户端把工具定义（名称、描述、参数 JSON Schema）随对话发给 API；模型在需要时返回 tool_calls；宿主解析并执行真实函数；将结果以 tool 角色消息写回并再次调用 API；直到模型不再请求工具或达到轮次上限。核心是「模型只负责决策与参数，执行在应用侧」。
tool_choice 有什么用？
auto 由模型决定；none 禁止工具；required 强制至少调用一次；也可指定某个 function 强制调用。用于调试、合规场景（必须走某工具）或 A/B。
函数定义（JSON Schema）
概念解释
每个可调用函数在 API 里通常描述为：type: function，function.name（唯一标识），function.description（给模型看的自然语言说明），function.parameters（符合 JSON Schema 的对象，描述参数类型、是否必填、枚举等）。
原理详解
JSON Schema 让运行时可以做校验（jsonschema 库），也让模型有明确字段名与类型提示。
建议：description 写清「何时调用、不何时调用」；对模糊词（如「最近」）在描述里约定格式（如 ISO 日期）。
复杂结构可用 object、array、enum、oneOf 等；但过于复杂的 Schema 可能增加模型填错概率，可适当拆分多个小函数。
为什么用 JSON Schema 描述参数？
三方面——（1）跨语言标准，各 SDK 统一；（2）可自动校验，避免脏参数进业务；（3）作为模型「字段说明」，减少胡编参数名。缺点是 Schema 过长会占 token，需要精简描述或工具路由。
必填字段怎么表示？
在 JSON Schema 里用 required: ["a","b"]，同时 properties 里声明各字段 type。OpenAI 工具格式与 JSON Schema Draft 兼容（具体以厂商文档为准）。
MCP 协议（Model Context Protocol）
MCP 是什么
概念解释
MCP（Model Context Protocol）是由 Anthropic 推动的开放标准，用于在 AI 应用（Host） 与 外部数据源/工具（MCP Server） 之间建立统一、可插拔的通信方式。可理解为「AI 侧的 USB-C」：一次实现 Server，多个客户端（Claude Desktop、IDE、自研 Agent）可复用。
原理详解
协议定义了能力发现、资源读取、工具调用、提示模板等消息格式与生命周期。
目标：把「每个产品各写一套插件」变成「标准协议 + 多实现」。
核心组件：Client、Server、Transport
概念解释
- MCP Server：暴露工具/资源/提示的实现进程（如连接 GitHub、数据库）。
- MCP Client：运行在 Host 内，与 Server 建立会话，转发模型侧请求与结果。
- Transport：传输层，常见 stdio（子进程标准输入输出）、HTTP/SSE 等。
原理详解
- stdio 适合本地子进程；HTTP 适合远程服务。
- Client 负责能力协商、把 Server 工具映射为模型可用的工具列表（与 Function Calling 衔接）。
MCP 的优势
概念解释
- 标准化：消息与能力模型统一，降低集成成本。
- 可复用：同一 MCP Server 给桌面、IDE、Agent 用。
- 生态：社区可共享 Server 实现；企业可内网部署私有 Server。
- 隔离：工具崩溃不拖垮主进程（进程边界）。
工具路由（Tool Routing）
当工具数量多时如何高效选择
概念解释
工具过多时，一次性把所有 description 塞进上下文会：费 token、干扰模型、增加误选。解决思路是先缩小候选集再让大模型填参，或用小模型专门做路由。
原理详解
典型阈值：几十到上百个工具就要开始考虑路由（视模型与描述长度而定）。
方法：向量检索、分类/意图模型、层级目录（先选类再选工具）、规则前缀（用户以 /db 开头走数据库类）。