建构 AI Agent 应用——工具调用

虽然基础模型（foundation models）擅长长时间对话，但工具 才是赋能 AI 智能体去检索额外信息与上下文、执行任务、并以有意义的方式与环境交互 的基石。在 AI 语境中，工具可以被定义为：智能体为达成特定结果而可执行的某项能力或一组动作。工具的复杂度从简单的单步任务 到需要高级推理与问题求解的多步操作 不等。尤其当你希望智能体真正做出改变（而不仅是搜索与提供信息）时，工具就是执行这些改变的方式。

工具之于 AI 智能体的重要性，正如能力 之于人类专业人士。就像医生需要多样化的工具来诊断与治疗病人一样，AI 智能体也需要一套工具库来高效处理各类任务。本章旨在系统阐述智能体中的工具：包括其设计、开发与部署。

从本质上讲，AI 智能体是与环境交互、处理信息并自主执行任务的复杂系统。要高效做到这些，它们依赖于结构化的工具集 。工具作为可模块化组件，可独立开发、测试与优化，再整合为能够展现复杂行为的统一系统。

在实践中，一个工具可以简单到 在图像中识别一个物体，也可以复杂到 从最初联系到问题解决，完整管理一张客服工单。工具的设计与实现对智能体的整体功能与有效性至关重要。我们将从 LangChain 基础 开始，随后依次介绍可供自主智能体使用的不同类型工具：本地工具、基于 API 的工具，以及 MCP 工具。

LangChain 基础（LangChain Fundamentals）

在深入工具选择与编排之前，先了解一些 LangChain 的核心概念会很有帮助。LangChain 的核心是基础模型 与聊天模型 ，它们处理提示并生成响应。例如，ChatOpenAI 是一个包装类，为与 OpenAI 的聊天模型（如 GPT-5）交互提供简洁接口。你可以通过指定模型名来初始化它：

from langchain_openai import ChatOpenAI
llm = ChatOpenAI(model_name="gpt-4o")

LangChain 通过消息 来组织交互，以维持会话语境。两类主要消息是 HumanMessage（代表用户输入）与 AIMessage（代表模型响应）：

from langchain_core.messages import
HumanMessage messages = [HumanMessage("What is the weather today?")]

与此同时，工具 是模型可以调用的外部函数 ，用于把能力扩展到文本生成之外------例如调用 API、检索数据库、或执行计算。你可以用 @tool 装饰器定义一个工具，它会注册函数并自动生成描述其输入/输出的 schema：

from langchain_core.tools import tool

@tool
def add_numbers(x: int, y: int) -> int:
    """Adds two numbers and returns the sum."""
    return x + y

定义好工具后，用 .bind_tools() 把它们绑定到模型，使模型能在响应用户输入时选择并调用 这些工具。使用 .invoke() 提供当前对话的消息列表与模型交互；若模型决定调用工具，它会输出一次"工具调用"，随后你执行相应函数，并把结果追加回对话，再生成最终回答：

llm_with_tools = llm.bind_tools([add_numbers])
ai_msg = llm_with_tools.invoke(messages)
for tool_call in ai_msg.tool_calls:
    tool_response = add_numbers.invoke(tool_call)

这些"积木"------聊天模型、消息、工具与工具调用 ------构成了基于 LangChain 的系统基础。理解它们如何协同，有助于你跟进本章示例，并构建可以把语言理解与现实世界动作无缝衔接的智能体。

本地工具（Local Tools）

这类工具在本地运行 ，通常基于预定义的规则与逻辑 ，面向特定任务。它们易于构建与修改，并与智能体共同部署。对于传统编程更擅长、而语言模型相对薄弱的领域（如算术计算、时区换算、日历操作、地图交互 等），本地工具能显著增强系统能力。由于逻辑是显式定义 的，本地工具具备精确性、可预测性与简洁性。

与逻辑同样关键的还有元数据 ------工具的名称、描述与 schema 。模型依赖这些元数据来决定何时调用哪个工具。因此应注意：

• 名称要精准且范围小：名称过泛会导致 LLM 在不需要时也调用它。
• 描述要清晰且区分度高：多个工具的描述若过于宽泛或重叠，几乎必然引发混淆与性能下降。
• 输入/输出 schema 要严格：明确的 schema 有助于模型判断何时以及如何使用工具，降低误调用。

尽管优势明显，本地工具也存在重要缺点：

• 可扩展性：设计、构建与部署本地工具可能繁琐费时，且不易跨用例共享。虽可做成库供多处复用，但在大规模实践中往往不易。
• 重复建设：每个团队/部署都需要随服务一起部署同一套工具库，并在工具更新时协调各服务的发布；为了避免协调成本，许多团队会各自重写一份。
• 维护成本：环境或需求变化时，手工工具可能需要频繁更新与重新部署，持续维护开销不小。

尽管如此，手工打造的本地工具 在基础模型的薄弱项上极为有效------例如单位换算、计算器运算、日期与时间操作、图与地图运算等，都能显著提升智能体效果。

示例：注册一个计算器工具

先定义简单的计算函数：

from langchain_core.runnables import ConfigurableField
from langchain_core.tools import tool
from langchain_openai import ChatOpenAI

# Define tools using concise function definitions
@tool
def multiply(x: float, y: float) -> float:
   """Multiply 'x' times 'y'."""
   return x * y
`
@tool
def exponentiate(x: float, y: float) -> float:
   """Raise 'x' to the 'y'."""
   return x**y

@tool
def add(x: float, y: float) -> float:
   """Add 'x' and 'y'."""
   return x + y

将工具与模型绑定：

tools = [multiply, exponentiate, add]

# Initialize the LLM with GPT-4o and bind the tools
llm = ChatOpenAI(model_name="gpt-4o", temperature=0)
llm_with_tools = llm.bind_tools(tools)

现在，模型在回答问题时可以自主选择并调用这些工具：

query = "What is 393 * 12.25? Also, what is 11 + 49?"
messages = [HumanMessage(query)]

ai_msg = llm_with_tools.invoke(messages)
messages.append(ai_msg)
for tool_call in ai_msg.tool_calls:
   selected_tool = {"add": add, "multiply": multiply, 
       "exponentiate": exponentiate}[tool_call["name"].lower()]
   tool_msg = selected_tool.invoke(tool_call)
  
   print(f'{tool_msg.name} {tool_call['args']} {tool_msg.content}')
   messages.append(tool_msg)
   final_response = llm_with_tools.invoke(messages)
   print(final_response.content)

输出可见，模型调用了两次函数：multiply 与 add：

multiply {'x': 393, 'y': 12.25} Result: 4814.25
add {'x': 11, 'y': 49} 60.0

随后模型把工具结果纳入最终回答：

393 times 12.25 is 4814.25, and 11 + 49 is 60.

意义 ：我们已让基础模型执行与之绑定 的程序。尽管示例简单，但可以绑定任意有用且影响巨大的程序 ，并让模型决定调用哪个程序、以何参数调用 。负责任地这样做------只绑定那些能带来整体正效益的工具------是构建智能体与智能体系统的开发者的首要职责之一。

基于 API 的工具（API-Based Tools）

基于 API 的工具让自主智能体与外部服务 交互，获取额外信息、处理数据、并执行本地无法完成的动作。这些工具通过 API 与公共或私有服务通信，为扩展智能体功能提供了动态且可扩展的方式。

当智能体需要整合多种外部系统 、获取实时数据 ，或执行资源密集型计算 时，API 工具尤为有价值。通过连接 API，智能体可以访问天气、股市、翻译等各类服务，为用户提供更丰富且更准确的响应。其主要收益包括：

• 能力大幅拓展：无需重新训练模型，即可通过 API 提供天气预报、股价查询、多语翻译等功能。
• 实时数据：以最新信息为依据做出响应与动作，对依赖及时准确数据的应用（如金融交易、应急响应）尤为关键。

示例 1：接入 Wikipedia 以迈向"浏览器型"智能体

from langchain_openai import ChatOpenAI
from langchain_community.tools import WikipediaQueryRun
from langchain_community.utilities import WikipediaAPIWrapper
from langchain_core.messages import HumanMessage

api_wrapper = WikipediaAPIWrapper(top_k_results=1, doc_content_chars_max=300)
tool = WikipediaQueryRun(api_wrapper=api_wrapper)

# Initialize the LLM with GPT-4o and bind the tools
llm = ChatOpenAI(model_name="gpt-4o", temperature=0)
llm_with_tools = llm.bind_tools([tool])

messages = [HumanMessage("What was the most impressive thing" +
                         "about Buzz Aldrin?")]

ai_msg = llm_with_tools.invoke(messages)
messages.append(ai_msg)

for tool_call in ai_msg.tool_calls:
   tool_msg = tool.invoke(tool_call)
  
   print(tool_msg.name)
   print(tool_call['args'])
   print(tool_msg.content)
   messages.append(tool_msg)
   print()

final_response = llm_with_tools.invoke(messages)
print(final_response.content)

模型识别查询对象并检索维基百科，然后基于获得的信息生成回答。示例输出略。

示例 2：查询股价的 API 工具

from langchain_core.tools import tool
from langchain_openai import ChatOpenAI
from langchain_community.tools import WikipediaQueryRun
from langchain_community.utilities import WikipediaAPIWrapper
from langchain_core.messages import HumanMessage
import requests

@tool
def get_stock_price(ticker: str) -> float:
   """Get the stock price for the stock exchange ticker for the company."""
   api_url = f"https://api.example.com/stocks/{ticker}"
   response = requests.get(api_url)
   if response.status_code == 200:
       data = response.json()
       return data["price"]
   else:
       raise ValueError(f"Failed to fetch stock price for {ticker}")


# Initialize the LLM with GPT-4o and bind the tools
llm = ChatOpenAI(model_name="gpt-4o", temperature=0)
llm_with_tools = llm.bind_tools([get_stock_price])

messages = [HumanMessage("What is the stock price of Apple?")]

ai_msg = llm_with_tools.invoke(messages)
messages.append(ai_msg)

for tool_call in ai_msg.tool_calls:
   tool_msg = get_stock_price.invoke(tool_call)
  
   print(tool_msg.name)
   print(tool_call['args'])
   print(tool_msg.content)
   messages.append(tool_msg)
   print()

final_response = llm_with_tools.invoke(messages)
print(final_response.content)

同理，你也可以构建用于团队/企业内部信息检索的工具。为智能体提供获取任务所需信息 与在该信息上操作的工具，能显著扩展可自动化任务的范围与复杂度。

设计 API 工具的要点 ：关注可靠性、安全性与优雅降级 。外部服务可能不可用，因此需要兜底方案或清晰错误信息；对敏感数据必须使用 HTTPS 与强认证 ；留意频率限制 ，并确保合规（必要时匿名化/脱敏）。错误处理要稳健，确保网络波动或无效响应不会破坏体验。有条件的话为关键能力准备备选提供方以提升鲁棒性。

插件式工具（Plug-In Tools）

插件式工具 是模块化 的，可用极少定制 集成到智能体框架中。它们利用现有库、API 与第三方服务，以较低开发成本快速扩展 智能体能力，便于快速部署与扩容。主流平台（如 OpenAI、Anthropic Claude、Google Gemini、Microsoft Phi）以及不断壮大的开源社区，均提供此类"即插即用"的工具生态。

• OpenAI 的插件生态在 ChatGPT 产品内功能强大（实时搜索、专业代码生成等），但不对公共 API 开放 ；若要在自有应用中复刻类似体验，需要在应用层自行实现函数调用层（如借助 LangChain）。
• Anthropic Claude 通过 Messages API 直接暴露"工具使用"能力（亦可在 Bedrock、Vertex AI 等平台使用），只需注册自定义或官方工具，Claude 即可在推理时调用，无需专门 UI。
• Google Gemini 通过 Vertex AI API 的 Function Calling 配置工具，模型以结构化调用触发函数，开发者在代码中处理参数与返回值。
• Microsoft Phi 在 Azure AI Foundry 提供，与 Azure 的认知搜索、文档处理与可视化紧密集成；虽不以"插件"命名，但体验类似：调用模型→接收结构化输出→无缝串入既有工作流。

优点 ：集成于模型执行层 ，对现有工作流扰动最小 ；开发者"插上就用"，即可快速上线新功能。
局限 ：通用化设计导致可定制性不如自研工具 （本地或远程服务化），难以完全贴合特定场景的细微需求------这是易用性与定制性之间的权衡。

随着平台工具目录快速扩张，插件式工具的能力广度正不断提升，覆盖更多专业与高级功能，极大便利了复杂场景的开发与落地。

开源生态 同样蓬勃：例如 Hugging Face Transformers 提供大量预训练模型与插件式工具，支持文本生成、情感分析、机器翻译等，可轻松集成到开源基础模型中并自由定制。平台如 Glama.ai 、mcp.so 汇聚了海量 MCP 服务器，涵盖从小工具到复杂有状态服务，便于搜索与发现。开源社区的持续贡献，使得开发者能以更低门槛利用前沿能力。

行业应用 广泛：

• 客服：自动答复、工单管理、情感分析、向量检索做知识对齐；
• 医疗：医学影像分析、分诊、数据管理、文献信息抽取；
• 金融：趋势分析、欺诈检测、资产管理（异常检测、预测分析）；
• 教育：个性化学习、自动评分、内容推荐。

未来趋势 ：插件工具将继续强化互操作性与标准化 ，以便跨平台无缝集成；同时增强可配置性与可适配性 ，在易用 与定制之间取得更佳平衡。

小结 ：无论是本地工具 保证精确可控，还是API 工具 带来实时与广域能力，抑或插件式工具 实现快速扩展，工具就是让语言模型从"会说"走向"会做"的关键。负责任地选择、设计与绑定工具，并为其提供可靠、安全、可降级的执行环境，是打造可用、可信、可扩展智能体系统的核心。

模型上下文协议（Model Context Protocol, MCP）

随着 AI 生态的成熟，智能体不再是彼此隔绝的孤岛。它们需要从云存储读取文档、向业务应用写入数据、调用内部 API，并与其他智能体协同。为每个数据源或服务手写适配器的定制集成 既脆弱又难以扩展。此时登场的就是 Model Context Protocol（MCP） ：由 Anthropic 提出、并已被 OpenAI、Google DeepMind、Microsoft 等主流厂商采纳的一个开放标准 ，为把 LLM 连接到外部系统提供统一、与模型无关的方式。可将 MCP 比作 AI 的 "USB-C 接口" ------任何数据源或工具只要暴露出一个清晰定义的接口，任意智能体即可消费，无需专门的胶水代码。MCP 的核心定义了两种角色：

MCP 服务器（MCP server）

一个通过标准化 JSON-RPC 2.0 接口暴露数据或服务的 Web 服务器。只要符合 MCP 规范，它可以封装任何东西------云对象存储、SQL 数据库、企业 CRM、专有业务逻辑等。

MCP 客户端（MCP client）

任何"会说 MCP"的智能体或 LLM 应用。客户端发送 JSON-RPC 请求（如："列出这个 Salesforce 文件夹中的所有文件"；或"以 customerId=1234 执行函数 'getCustomerBalance'"），并接收结构化 JSON 响应。由于协议统一，智能体开发者无需了解服务器内部实现------只需了解其公开的方法即可。

在底层，MCP 通过 HTTPS 或 WebSocket 传输 JSON-RPC 2.0。服务器会公布可用方法（如 listFiles、getRecord、runAnalysis）及其输入/输出模式；客户端获取服务器的方法目录（method catalog） ，从而让 LLM 能推理应调用哪个方法及其参数。一旦选定工具调用，MCP 客户端会将其包装为 JSON-RPC 负载，发送至相应服务器并等待响应。由于双方"说同一种语言"，跨平台互操作就变得直接而简单。

在 MCP 之前，开发者会为每个目标系统编写定制适配器------把 REST 调用或 SDK 直接硬编码在智能体中。随着数据源数量增加，这些专用集成也急剧膨胀，导致代码脆弱、易错、难以维护和扩展。

尽管 MCP 优势明显，但安全方面仍有若干未完全解决的问题------尤其涉及认证、访问控制 ，以及多智能体共享 MCP 端点时可能出现的攻击面。如何确保只有被授权的智能体才能调用特定方法、实施基于角色的敏感数据访问控制、防止恶意负载注入并保留审计日志，仍是活跃的研发与工程领域。一些组织会额外使用网络策略或代理层来缓解这些风险，但 MCP 规范的核心目前尚未强制一种统一的安全方案。尽管如此，MCP 已经解决了跨多个智能体复用工具 的关键难题：某项服务一旦以 MCP 方式暴露，任意数量的智能体即可在无须重写适配器的前提下发现并调用其方法。这大幅降低了开发成本，并鼓励模块化、可复用的架构。

下面通过一个自包含的 Python 示例来展示 MCP 的实际运行方式，它完成以下任务：

• 启动一个本地"math" MCP 服务器（通过子进程）
• 连接到运行在 localhost:8000/mcp 的远程"weather" MCP 服务器
• 实现一个异步智能体循环：检查用户最后一条消息，判断该调用"math"工具（算术表达式）还是"weather"工具（天气查询）
• 展示智能体如何解析工具输出并返回最终的助手响应

class AgentState(TypedDict):
    messages: Sequence[Any]  # A list of BaseMessage/HumanMessage/...

mcp_client = MultiServerMCPClient(
    {
        "math": {
            "command": "python3",
            "args": ["src/common/mcp/MCP_weather_server.py"],
            "transport": "stdio",  # Subprocess → STDIO JSON-RPC
        },
        "weather": {
            # Assumes a separate MCP server is already running on port 8000
            "url": "http://localhost:8000/mcp",
            "transport": "streamable_http",  
            # HTTP→JSON-RPC over WebSocket/stream
        },
    }
)

async def get_mcp_tools() -> list[Tool]:
    return await mcp_client.get_tools()

async def call_mcp_tools(state: AgentState) -> dict[str, Any]:
    messages = state["messages"]
    last_msg = messages[-1].content.lower()

    # Fetch and cache MCP tools on the first call
    global MCP_TOOLS
    if "MCP_TOOLS" not in globals():
        MCP_TOOLS = await mcp_client.get_tools()

    # Simple heuristic: if any digit-operator token appears, choose "math"
    if any(token in last_msg for token in ["+", "-", "*", "/", "(", ")"]):
        tool_name = "math"
    elif "weather" in last_msg:
        tool_name = "weather"
    else:
        # No match → respond directly
        return {
            "messages": [
                {
                    "role": "assistant",
                    "Sorry, I can only answer math" + 
                        " or weather queries." 
                }
            ]
        }

    tool_obj = next(t for t in MCP_TOOLS if t.name == tool_name)

    user_input = messages[-1].content
    mcp_result: str = await tool_obj.arun(user_input)

    return {
        "messages": [
            {"role": "assistant", "content": mcp_result}
        ]
    }

说明：

• "math "项通过 command + args 启动一个子进程来运行 MCP_weather_server.py；该脚本需符合 MCP，要通过 STDIO 提供 JSON-RPC 服务。
• "weather "项指向一个已在 http://localhost:8000/mcp 运行的 HTTP MCP 服务器；streamable_http 传输方式允许在 HTTP/WebSocket 上进行双工 JSON-RPC 通信。

MCP 在规模化设计、部署与维护智能体方面是重要的一步。通过为方法的暴露与消费定义统一的 JSON-RPC 接口 ，MCP 将服务实现 与智能体逻辑 解耦，使多路智能体能够在无需定制集成的前提下复用同一工具。实践中，这意味着当新的数据源、微服务或遗留系统出现时，开发者只需按 MCP 规范实现一次服务器------任何支持 MCP 的智能体都能立即发现并调用其方法。

虽然强认证、细粒度访问控制、负载校验 等安全议题仍在演进，但 MCP 的核心承诺------无缝互操作与模块化工具复用 ------已经在多家头部组织的生产系统中得到验证。展望未来，我们可以预期 MCP 在安全最佳实践上的持续完善、更广泛的标准化方法目录（method catalog）采纳，以及公有与私有 MCP 端点生态的成长。总之，MCP 解决了智能体系统设计中一个长期存在的难题：如何快速且可靠地整合多样化服务，并为更灵活、可维护、分布式的 AI 架构打下基础。

有状态工具（Stateful Tools）

有状态工具可以是本地脚本、外部 API，或部署在 MCP 上的服务，但它们共享一个共同风险：当你把对持久化状态的直接操作权交到基础模型手里时，也就赋予了它犯下破坏性错误或被恶意者利用的可能。 真实世界里曾发生过这样的案例：某智能体为"优化"数据库性能，直接删除了生产表中一半的行，导致关键记录丢失。即便没有恶意，基础模型也可能误解用户意图，把原本无害的查询变成破坏性的命令。由于有状态工具会与随时间变化的实时数据存储交互，这类风险尤为突出。

缓解之道：

• 只注册范围狭窄的操作作为工具 ，避免暴露诸如"执行任意 SQL"之类的端点。比如定义 get_user_profile(user_id) 或 add_new_customer(record) 这类工具------每个都封装一个单一且经过充分测试 的查询或过程。仅需读权限的场景，绝不应让智能体具备删除或修改数据的权力。通过在注册层约束工具能力，可显著缩小攻击面并限制错误影响范围。
• 若业务确实 需要自由查询，必须实施严格的输入净化与访问控制 。OWASP 的 GenAI 安全项目警示：提示注入可能将 DROP、ALTER 等危险子句夹带进原本无害的请求中，因此输入校验必须拒绝 包含此类模式的语句。始终 绑定参数或使用预编译语句 ，防止 SQL 注入；确保智能体使用的数据库账号仅拥有最小必要权限。
• 除了净化外，记录每一次工具调用（审计日志）以检测异常行为并支持取证分析，强烈推荐。结合实时告警监测可疑模式（如异常大量删除、修改架构的命令），可以在小问题演变为重大事故前快速干预。

归根结底，应以最小权能原则（principle of least power）指导设计：只给予模型绝对必要 的工具，并为每个操作设置精确边界与监管 。无论工具在本地运行、调用外部 API，还是在 MCP 服务器上执行，都应遵循相同的防护：限制能力、净化输入、最小授权、全程可观测 。以这样的纪律对待有状态工具，才能确保你的 AI 智能体成为强有力的协作者 ，而不是失控的数据库管理员。

自动化工具开发（Automated Tool Development）

代码生成是一种由 AI 智能体自主编写代码的技术，可显著减少创建与维护软件应用所需的时间与人力。其过程通常基于对海量代码数据的训练，使模型能够理解编程语言、编码模式与最佳实践。

当智能体为了解决任务或对接新 API 而实时编写自己的工具时，代码生成代表了 AI 能力的跃迁式提升。这种动态方法让智能体得以自适应地扩展功能，显著增强其通用性与问题求解能力。

将基础模型作为"工具制造者"（Foundation Models as Tool Makers）

基础模型不再只是使用 工具------它们也会构建 工具。向 LLM 提供 API 规范或示例输入后，你就能让它生成初始的封装器、辅助函数，或更高层的"原子"操作。让模型先起草代码桩，在安全沙箱中执行，然后自我批注与改进 ："该端点返回了 400------请调整查询参数。"经过数轮快速迭代，你将得到一套经过测试、边界明确、可由智能体直接调用的工具，而无需手写每一个封装。

当你面对庞杂的 API 版图时，这种方法尤为亮眼：无需手工编写几十个微服务客户端，而是将模型对准 OpenAPI 规范（或样例代码），让它为每个函数产出首版草稿。随后由人工评审把关，收紧安全性与正确性，再将其纳入 CI/CD 流水线。随着 API 演进，你只需重复"生成---完善"的循环即可保持工具同步------省去大量样板工作，避免脆弱的手写胶水代码。

需要强调的是，尽管"模型驱动的工具生成"能大幅压缩开发周期、易于扩展，仍然需要明确的验证标准 （测试、响应校验、模式约束）和开发者监督 。模型给出的自然语言改进建议便于理解，但最终仍需你来兜住边界条件、补齐安全防线，并确保业务逻辑对齐。若执行到位，这种"AI 创造力 + 人工审查"的混合范式，能把纠结的 API 生态打造成精干、面向智能体的工具包，从而在组织层面释放快速且可靠的自动化。

实时代码生成（Real-Time Code Generation）

实时代码生成 指智能体在运行过程中按需编写并执行代码。它使智能体能够为特定任务创建新工具或修改既有工具，从而具备高度适应性。比如，遇到一个全新的 API 或陌生问题时，智能体可以即时生成对接代码或针对该问题的解法。

基本流程是：智能体先分析任务，拆解实现步骤；据此编写代码片段并尝试执行；若效果不达预期，则迭代修正，从每次尝试中学习，直到达成目标。这种"试错---收敛"的循环让智能体持续打磨工具，自动提升性能并扩展能力边界。

实时代码生成的优势主要体现在适应性 与效率 ：按需产码让智能体能快速适配新任务与新环境，这对需要动态求解与灵活集成的软件场景（如实时数据分析、复杂系统对接）尤为关键。无需等待人工介入即可满足即时需求，从而显著提速流程、减少停机并提升整体效率。

但它也带来若干挑战与风险：

• 质量管控 ：自主生成代码的安全与质量至关重要；劣质代码可能引发系统故障与安全漏洞。
• 安全风险 ：允许执行自生成代码会带来被恶意者利用的可能（注入恶意代码、数据泄露、越权访问或系统损害）。必须设置强有力的安全措施与人工监督以降低风险。
• 可复现性不足 ：若智能体每次都"从零再造"工具，行为将变得不可预测------一次成功不代表下次仍然成功。性能可能波动，提示或模型版本的细微变化都可能走上完全不同的代码路径，进而增加调试、测试与合规难度。
• 资源消耗 ：实时产码与执行往往计算与内存开销大 ，尤其当天真、低效的解法被频繁尝试时。需要在多方面设置性能护栏来缓解。

工具调用配置（Tool Use Configuration）

OpenAI、Anthropic、Gemini 等基础模型 API 都支持通过工具选择参数来精确控制模型对工具的使用，从"灵活的模型自决调用"切换到"可预测的确定性行为"。

• auto（自动） ：模型基于上下文自主决定是否调用工具，适合通用场景。
• any/required（至少一个/必需） ：强制 模型调用至少一个工具，适用于必须依赖工具输出的任务。
• none（禁用） ：禁止一切工具调用，适合受控输出或测试环境。
• pin（固定） ：部分接口允许钉住某个具体工具，以保证流程的可预期与可复现。

通过选择合适模式，你可以在灵活性、可靠性与可预测性之间做权衡：要么让模型自由编排，要么施加结构化约束。

即便如此，优秀的智能体仍可能"失足"------跳过必要的工具调用、产出无效 JSON、或运行出错的工具。因此需要可靠的兜底与后处理机制。针对每次模型响应，请执行以下校验与修复流程：

1. 先校验 ：用 jsonschema 或 Pydantic 校验结构，捕获缺字段或格式错误。若遗漏工具调用则自动触发 ；若 JSON 无效则提示模型更正。
2. 智能重试 ：对暂时性失败（如网络波动）采用指数退避 ；只重生成出错片段，避免整轮重来。
3. 优雅降级 ：多轮重试仍失败时，切换到备选模型/服务、向用户求澄清、使用缓存数据，或返回安全默认值。
4. 全链路日志 ：记录提示、工具调用、校验错误、重试与降级，以便可观测性、调试与持续改进。

通过严格验证、策略性重试与优雅降级 ------并记录每一步 ------你能把随机失误转化为可管理、可预测 的行为。这是交付健壮、可用于生产的智能体系统的关键前提。

结论（Conclusion）

工具使 AI 智能体能够有效地执行任务、做出决策并与环境交互。这些工具从简单任务到需要高级推理的复杂任务不等。由开发者手工打造 的工具精确可靠，但维护耗时；由 OpenAI、Google Gemini 等平台提供的插件式工具集成与扩展迅速，却在定制性上有所不足。

自动化工具开发 （包括实时代码生成 、模仿学习 与强化学习 ）使智能体可以动态地适应并精炼自身能力，增强其通用性与问题求解能力，从而实现持续改进 与自主扩展工具。为你的智能体构建并维护一套合适的工具箱，是让其胜任当前任务的关键途径之一。

在学会如何为智能体构建与筛选 工具之后，下一步是思考如何让智能体制定计划、选择并参数化工具，并把这些要素组合起来完成有用的工作。下一章我们将讨论如何将一系列工具组织起来，以**编排（orchestration）**的方式执行复杂任务。