AI Agent 工具链：MCP 协议与 Function Calling 深入

Function Calling 的效果很大程度上取决于你给工具写的描述。模型看不到你的代码，它只根据工具名称和描述来判断「这个工具能不能解决当前问题」。描述写得模糊，模型就会选错工具或者乱传参数。

# 一个工具的 JSON Schema 定义示例
tools = [{
    "type": "function",
    "function": {
        "name": "search_flights",
        "description": "查询指定城市间的航班信息，返回航班号、时间和价格。用于用户询问机票或出行方案时调用。",
        "parameters": {
            "type": "object",
            "properties": {
                "from": {"type": "string", "description": "出发城市，如北京"},
                "to": {"type": "string", "description": "到达城市，如上海"},
                "date": {"type": "string", "description": "出发日期，格式 YYYY-MM-DD"}
            },
            "required": ["from", "to", "date"]
        }
    }
}]

写描述的几个要点：说清楚工具做什么、什么时候该用、参数什么格式。特别是「什么时候该用」这一句，直接决定了模型在面对模糊问题时会不会乱调工具。

有了 Function Calling 之后，每个 AI 客户端都要自己对接一套工具。你做一个聊天应用要对接天气、日历、数据库；换一个客户端又要重新对接一遍。MCP（模型上下文协议）就是来解决这个重复劳动的：它定义了一套标准协议，工具方实现一次 MCP Server，任何支持 MCP 的客户端都能直接用。

从开发者角度看，MCP 的价值是「写一次工具，到处接入」。你不用为每个 AI 应用单独写对接代码，只要把工具封装成 MCP Server，Claude、IDE 插件、自定义 Agent 框架都能自动发现和调用它。这和 USB-C 的思路一样：统一接口，免去各做各的线。

# MCP Server 的最简结构（伪代码）
from mcp import Server

server = Server("my-tools")

@server.tool()
def search_flights(from_city: str, to_city: str, date: str):
    """查询航班信息"""
    return flight_api.search(from_city, to_city, date)

server.run()

模型生成的工具调用参数不一定对。日期格式可能写错、城市名可能拼成拼音、必填参数可能漏了。在真正执行工具之前，必须加一层校验：按 JSON Schema 检查参数类型和必填项，发现错误就把错误信息返回给模型，让它修正后再试一次。

# 参数校验与纠错循环
while True:
    call = model.next_tool_call()
    errors = validate(call.parameters, tool_schema)
    if not errors:
        result = execute_tool(call)
        break
    # 把错误反馈给模型，让它修正
    messages.append({"role": "tool", "content": f"参数错误: {errors}, 请修正后重试"})

这种「试错-反馈-修正」的循环是 Agent 可靠性的关键。不要假设模型一次就能调对，要把它当成一个会犯错但能看提示改正的实习生，给它纠错的机会。

当你给 Agent 挂了十几个工具时，问题就变成了：模型怎么知道该用哪个？工具太多会让模型困惑，也会占用大量上下文。常见的做法有三种：让模型自己选（工具不多时）、先用一个小模型做工具分类再路由（工具多时）、或者按工作流预先固定每一步用哪个工具（流程明确时）。