面向 AI 代理的服务器端工具：架构、延迟及何时切换

• 你的代码会变得更简单，但你仍然需要考虑失败、性能和重试安全。DigitalOcean 负责工具执行，但这些责任仍然由你承担。
• 客户端更适合开发；服务器端更适合生产。客户端提供完整的可见性和本地调试。服务器端在你准备发布时会移除基础设施开销。
• 冷启动仍然是你的责任。DigitalOcean 管理连接，但如果你的 MCP 服务器进入冷启动，启动时间仍会体现在你的响应中。请保持其已预热。
• 工具失败和代理失败是不同的问题。工具超时属于基础设施问题。尽管工具正常工作，但模型回答质量差属于提示问题。请分别跟踪它们。
• 在需要之前先配置好追踪。一旦在生产环境中出现问题，你就会想知道确切是哪次工具调用导致的。请从一开始就设置 Agent Tracing API。
• MCP 服务器必须能够公开访问才能用于服务器端使用。如果你的工具位于私有网络中，请改用客户端 MCP。

DigitalOcean 推理引擎的服务端工具让你可以直接在推理请求中执行工具。你沿用现有的 Model Access Key，无需新凭证，也不引入新的 API。这些工具在 Serverless Inference（无服务器推理）和 Dedicated Inference（专用推理）中均可使用。

目前，你可以在推理请求中接入以下五类外部能力：

1. 网页搜索，由 Exa 提供支持 基于 Exa 神经搜索索引的实时网页搜索。模型自行判断何时需要搜索，执行查询，并把结果融入回答。你可以控制每次请求最多搜索几次（max_uses：1 到 5），以及每次搜索返回多少条结果（max_results：1 到 10）。定价为每 1,000 次请求 10 美元。

2. 网页抓取，由 Exa 提供支持 在推理过程中抓取并提取指定 URL 的内容。Exa 的提取返回的是干净、解析过的文本而非原始 HTML，从而减少模型需要处理的 token 数量。除标准 token 费用外，不另收费。

3. 知识库检索 让模型可以查询你的私有数据。你只需提供知识库 ID，API 就会自动检索相关内容并将其并入响应。

4. 客户自有的 MCP 服务器 把模型接入你运营的任意远程 Model Context Protocol 服务器。在请求中传入服务器 URL 和 Bearer Token 即可，MCP 连接、工具发现和执行均由 DigitalOcean 负责。通过 allowed_tools 参数，你可以控制模型能调用你服务器上的哪些工具。

5. Tool Search（Anthropic 和 OpenAI 模型） 一旦工具定义超过大约 20 到 30 个，每次请求都加载全部定义就会带来可观的输入 token 开销。达到 50 个以上时——这在连接多个内部系统、每个系统又各暴露若干工具的智能体中很常见——每次请求的开销可能高达数百个 token。按每天数千次请求累计，这笔成本会迅速叠加。Tool Search 通过懒加载工具定义来解决这一问题：标记为 defer_loading: true 的工具只在模型需要时才加载进上下文，而非每次请求都加载。

对于 Anthropic 模型，此功能通过 Messages API 使用搜索工具实现（tool_search_tool_regex_20251119 用于模式匹配或 tool_search_tool_bm25_20251119 用于自然语言查询）。对于 OpenAI 模型，此功能通过 Responses API 与 GPT-5.4+ 配合使用 type: "tool_search" 实现。

# Tool Search with Anthropic (Messages API)
import anthropic

client = anthropic.Anthropic(
    base_url="https://inference.do-ai.run/v1",
    api_key="your-model-access-key"
)

response = client.messages.create(
    model="anthropic-claude-opus-4.8",
    max_tokens=2048,
    messages=[{"role": "user", "content": "What is the weather in zip code 94107?"}],
    tools=[
        # The search tool loads immediately
        {
            "type": "tool_search_tool_regex_20251119",
            "name": "tool_search_tool_regex"
        },
        # These tools only load when the model searches for them
        {
            "name": "get_weather_by_zip",
            "description": "Return current weather conditions for a US zip code.",
            "input_schema": {
                "type": "object",
                "properties": {
                    "zip_code": {"type": "string"},
                    "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
                },
                "required": ["zip_code"]
            },
            "defer_loading": True
        },
        {
            "name": "search_files",
            "description": "Search through files in the workspace",
            "input_schema": {
                "type": "object",
                "properties": {
                    "query": {"type": "string"}
                },
                "required": ["query"]
            },
            "defer_loading": True
        }
    ]
)

模型会先查找它需要的工具，仅加载该定义，然后调用它。一旦工具数量超过 20 到 30 个，这一点就变得尤为重要——每次请求的输入 token 节省会逐渐累积。

# Standard web search
from openai import OpenAI

client = OpenAI(
    base_url="https://inference.do-ai.run/v1",
    api_key="your-model-access-key"
)

response = client.chat.completions.create(
    model="openai-gpt-4o",
    messages=[{"role": "user", "content": "What changed in DigitalOcean pricing this month?"}],
    tools=[{"type": "web_search", "max_uses": 3, "max_results": 5}]
)

# One request, one response
print(response.choices[0].message.content)

没有服务器端工具时，完成此任务需要三个步骤：将消息发送给模型，获取工具调用指令，自行执行搜索，然后将结果发送回以得到最终答案。使用服务器端工具时，所有这些操作都在单次 API 调用中完成。

研究代理

能够搜索网页并获取页面的研究代理可以回答需要实时信息的问题：当前定价、最近的产品变更、发生在模型训练截止之后的新闻，或任何需要多来源综合的内容。

使用服务器端工具的工作方式：

response = client.chat.completions.create(
    model="openai-gpt-4o",
    messages=[{
        "role": "user",
        "content": "Summarize the key changes to Kubernetes networking in the last 6 months and their implications for teams running microservices."
    }],
    tools=[{
        "type": "web_search",
        "max_uses": 5,
        "max_results": 5
    }]
)

模型决定何时搜索、搜索什么、搜索多少次，以及何时拥有足够信息来撰写摘要。无论代理内部运行多少次搜索，您的应用程序代码保持不变。

如果没有服务器端工具，您需要自己实现循环：捕获工具调用，调用搜索 API，将结果追加到对话中，再次调用模型，并重复此过程，直到模型生成最终答案。

通过 MCP 连接到内部系统的 AI 应用

已经为内部工具（项目管理、调度、CRM、内部 API）构建 MCP 服务器的团队可以将其连接到任何推理请求，而无需更改其应用程序代码。

response = client.chat.completions.create(
    model="openai-gpt-4o",
    messages=[{
        "role": "user",
        "content": "Pull the open support tickets for our enterprise tier and draft a weekly digest for the team."
    }],
    tools=[{
        "type": "mcp",
        "server_label": "internal-crm",
        "server_url": "https://tools.yourcompany.com/mcp",
        "authorization": "Bearer your-mcp-token",
        "allowed_tools": ["list-tickets", "get-ticket-details", "get-customer-info"]
    }]
)

allowed_tools 列表用于控制模型在你的 MCP 服务器上能执行哪些操作。如果不设置这个列表，模型就能调用服务器暴露的全部工具，因此最佳实践是只列出当前任务所需的工具。

你的 MCP 服务器必须能被公网访问，因为推理层会从 DigitalOcean 的网络发起连接，而不是从你的应用运行环境。如果服务器目前只接受内网流量，就需要将其暴露到公网。

组合多种工具的多步骤智能体

更复杂的智能体会在一次请求中组合使用多种工具。例如，一个尽职调查智能体可以在同一次推理调用中完成三件事：搜索某家公司的近期新闻、抓取其定价页面，并查询内部知识库，了解你与该公司已有的合作情况。

response = client.chat.completions.create(
    model="openai-gpt-4o",
    messages=[{
        "role": "user",
        "content": "We're evaluating Acme Corp as a vendor. What's their current product, recent news, and do we have any history with them?"
    }],
    tools=[
        {
            "type": "web_search",
            "max_uses": 3,
            "max_results": 5
        },
        {
            "type": "knowledge_base_retrieval",
            "knowledge_base_id": "vendor-history-kb"
        }
    ]
)

模型会根据提示词中的任务，自行决定使用哪些工具以及按什么顺序使用。

客户端执行是指由你的应用代码来运行工具。你把用户消息发给模型，模型回复“我需要搜索 X”，你的代码执行搜索，再把结果传回去，模型随后给出最终答案。整个过程都在你自己的进程中运行，因此速度很快，但每一步都要由你来编写和维护。

服务端执行则是由 DigitalOcean 替你运行工具。你只需发出一次请求，工具的调用、执行和返回结果都会在响应回来之前完成。代价是：对外部服务的网络调用发生在这次请求内部，这部分耗时会计入你的总响应时间。

客户端工具执行：具体耗时如何

当工具由你的代码运行时，耗时取决于这个工具具体做什么：

• 在你自己的进程中运行的函数（输入校验、字符串格式化）：不到 1 毫秒
• 同一台机器上通过 stdio 连接的 MCP 服务器：每次调用 0.91 至 1.10 毫秒——这一数值来自一项针对生产环境 MCP 部署的研究，是实测平均值
• 调用外部 API 的 HTTP 请求：50 到 300 毫秒，视具体服务而定

这些耗时中的每一毫秒，你都能在自己的日志里看到。

服务端工具执行：具体耗时如何

当 DigitalOcean 替你调用工具时，这次调用所花的时间会直接加到你的响应时间上。两种工具在延迟特征上差异明显。

网页搜索：DO 的网页搜索由 Exa 驱动。Exa 维护的是一套预先构建好的神经网络索引，而不是每次请求都现场爬取网页。在覆盖 15 家搜索 API 提供商的 2026 年基准测试中，Exa 得到了专门测量，落在基于索引的梯队：中位数低于 400ms，中位数与 p95 之间相差无几。同一份测试还发现，那种每次请求都要实时抓取结果的实时 SERP API，中位数耗时在 600 到 700ms 之间，波动大得多，多家提供商的 p95 甚至超过 5 秒。这种尾部风险是实时爬虫才有的，DO 所用的基于索引的后端并不存在。

客户自有的 MCP 服务器：这里的风险是冷启动。如果 MCP 服务器最近没处理过请求，就得先重启才能响应。对一个基于 Node.js 的 MCP 服务器来说，光是加载运行时和模块就可能超过 2 秒。如果你的服务器在两次请求之间没有保持运行，那么每次新对话的首次调用都要付出这笔启动成本。

当工具延迟不断叠加

每调用一次工具，总响应时间就会增加一些。单次调用通常没什么问题，问题出在智能体连续调用多次工具的时候：每一次都会叠加在上一次之上。

举个例子：一个研究型智能体通过 DO 基于 Exa 的搜索依次执行 3 次网页搜索，每次调用中位数耗时不到 400ms，那么在模型生成回复之前，光是搜索环节就要花掉约 1.2 秒。

对基于索引的搜索来说，这是典型情况。作为对比，实时搜索 API 每次调用的中位数耗时在 600 到 700ms 之间；而在 p95 档位上，Proxyway 2026 年基准测试中的多家提供商单次调用超过了 5 秒，3 次连续调用合计就会超过 15 秒。尾部风险取决于你选的是哪个后端。工具调用会层层叠加，每多加一次，碰到慢尾的概率也就更高。

如果你的智能体是在做研究、回答复杂问题，或者在后台运行，每项任务多几秒钟并不是问题。但如果你要做的是语音助手或实时应用，用户期望一秒之内就得到回复，那么每一次工具调用都很关键。这种情况下，客户端工具或更快的单步任务才是更合适的选择。

把工具执行搬到服务端之后，连接生命周期、重试和扩容就都不用你再操心了。不过在正式上手服务端工具之前，有三点需要提前想清楚。

1. 为工具失败编写明确的指令

客户端工具一旦失败，会抛出异常，由你的代码捕获处理；换成服务端工具就不一样了——如果一次网页搜索没返回有用的结果，模型会拿着手里仅有的信息继续推理，未必会告诉你这次搜索其实一无所获。

解决办法很简单：把这一点写进系统提示词。比如“如果知识库没有返回相关结果，就如实说明，并请用户换个说法重试”，模型就有了明确的行动路径，不必靠自己瞎猜。针对空结果场景写下明确指令，能让你的 Agent “稳定有用”，而不只是“通常有用”。

2. 将 MCP 写操作设计为可安全重试

读取类工具（网页搜索、网页抓取、知识库检索）可以放心重试：请求超时了就再发一次，什么都不会改变。

经由客户自有的 MCP 服务器执行写操作时，就要多加小心了。请求一旦超时，你无法确定操作到底执行了没有。正确的做法是给每个写操作分配一个唯一的请求 ID，由 MCP 服务器据此对重试请求去重。这样既能安全重试，又不会造成重复写入。

3. 弄清失败发生在哪一层工具

DO 托管工具与你自建的 MCP 服务器，故障路径各自独立。如果所有工具同时失效，说明问题出在托管基础设施层；如果网页搜索一切正常、唯独 MCP 调用失败，那就要检查你自己的服务器了。

构建告警时应当把这两种情况区分开来。笼统的“工具故障”作为单一告警类别，很难据此采取行动；而“DO 托管工具宕机”与“MCP 服务器不可达”之分，能让你直接锁定该排查哪里。

以下情况应使用服务端工具：

你不想自己维护工具基础设施。网页搜索与检索背后的连接生命周期、凭证管理、重试与扩缩容，都是实打实的工程投入。当这些开销超过失去直接控制的代价时，把它们交给托管层才是明智之举。

凭证不应写进应用代码。Web API、内部系统和第三方服务往往离不开密钥。服务端工具让你把凭证保存在使用它们的工具一侧，而不必经由应用层中转。

多个智能体或团队成员需要共用同一套工具。客户端工具的作用范围仅限于你的代码所运行之处；服务端工具则对任何向你的推理端点发起请求的智能体开放，无需重复配置。

你需要网页搜索或实时检索。否则，你就得自行接入一家搜索服务商，还要编写处理工具调用的循环逻辑。这些活儿服务端工具都能替你完成。

你已经在使用 DigitalOcean Inference。只要手上有 Model Access Key，启用服务端工具只需在现有 API 调用中多传一个字段。

以下情况应使用客户端工具：

你正处于开发阶段，需要完整的可见性。客户端执行是透明的。你可以记录每一次工具调用、检查请求负载、设置断点，并在本地复现故障。而服务端执行则需要借助追踪 API，才能获得同等的可见性。

工具运行快、纯本地执行、不发起网络调用。在内存中运行的函数（如 schema 校验、字符串解析、数值计算）在客户端执行的开销不到一毫秒。把它们搬到服务端只会白白增加一次网络往返，毫无收益。

延迟预算已经没有余量。假设你在开发语音助手，用户期望 400 毫秒内得到响应，而仅模型推理就要占掉 300 毫秒，那么每一次工具调用的往返耗时都举足轻重。

工具逻辑依赖你的应用状态。那些依赖本地会话数据、内存状态或服务端所持数据库连接的工具，很难封装成 MCP 服务器。这类工具应留在客户端。

你需要掌控重试行为。在客户端，工具失败后如何处理完全由你决定：重试、启用兜底方案，还是向用户抛出特定错误。而服务端的重试行为则由推理层决定。

务实的路径

当核心难题在于管理工具基础设施时（生产环境往往正是如此），服务端才是正确的默认选择。而当你需要确切了解系统内部正在发生什么时（开发阶段几乎总是如此），客户端则是更好的默认选择。

先用客户端工具开发，持续补充可观测性手段，直到摸清各种故障模式。当基础设施开销超过调试收益时，再切换到服务端进行生产部署。

如果你曾用 LangChain 或 OpenAI API 构建过智能体，下面来看看这几种方案的差异。

LangChain tools 默认是客户端的。你把工具定义为 Python 函数，LangChain 将它们包装在一个循环中，然后在自己的代码里运行整个过程。这样可以获得最大的可见性和控制力。代价是你需要自行维护基础设施：连接、重试、错误处理和凭证管理都由你负责。LangChain 不会为你管理工具执行；它只是提供你编写的循环的框架。

OpenAI’s Responses API built-in tools（网页搜索、代码解释器、文件搜索）是与 DO 的服务器端工具在架构上最接近的匹配。OpenAI 在推理请求内部管理执行；你声明工具并得到一个响应。但 OpenAI 的工具构建方式带来了真正的架构后果：它们与 OpenAI 的模型层绑定。如果你今天在 GPT-4o 上使用内置网页搜索构建研究代理，后来想让同样的代理在 Claude 上运行，则必须从头重新构建工具层——因为 OpenAI 的内置工具仅适用于 OpenAI 模型。DO 的服务器端工具则将工具层与模型层解耦。你只需配置一次工具，即可在 DO 目录中的任何模型上运行。更换底层模型不需要改动工具的设置方式。你还可以在内置工具之外，连接客户自有的 MCP 服务器。

DO’s server-side tools 在工作方式上更接近 OpenAI 模型而非 LangChain：托管执行、单请求流。但它们通过 MCP 将这种模式扩展到客户自有的基础设施。在所有三种情况下，权衡是相同的：托管执行意味着你无法直接看到工具调用内部发生了什么。你用可观测性换取更少的基础设施管理负担。

对于已经在生产环境中运行 LangChain 的团队，服务器端工具可以减少你需要维护的基础设施，但不会取代你已经构建的代理逻辑。对于正在评估哪种方式先采用的团队，当你希望在不拥有工具层的情况下快速交付时，服务器端工具是最合适的选择。

MCP（模型上下文协议）是 AI 模型连接外部工具和数据源的一种标准方式。可以把它想象成一个插件系统：你构建一个小型服务器来暴露你的内部工具，例如数据库查询或 CRM 检索，模型在对话过程中可以调用这些工具。

当你的工具在自己的代码中运行时，调试非常直接：出现故障时你能看到错误并进行修复。当工具在推理层中运行时，你会失去这种直接视角。在发布之前，有三件事值得提前配置。

1. 从一开始就启用追踪

使用客户端工具时，每次工具调用都会记录在你自己的日志中。使用服务器端工具时，这些细节存储在 DigitalOcean 的基础设施中。使用 Agent Tracing API 查看每次工具调用的开销。如果没有它，响应变慢可能是由于模型、网络搜索或冷启动的 MCP 服务器导致，你将无法确定具体原因。

2. 分别追踪工具延迟，独立于总响应时间

总响应时间对代理工作负载来说过于宽泛，不够细致。应追踪每次单独工具调用的耗时、每个请求发起的工具调用次数，以及工具返回无用结果的频率。DigitalOcean 控制面板提供聚合的推理指标；若需按工具细分，则需要使用追踪 API 或自行添加埋点。

3. 区分工具故障与代理故障

“代理未工作”可能有两种不同的含义：工具出现故障（搜索超时，知识库未返回结果），或者工具正常但模型仍给出错误答案。需要不同的修复方案：一种是基础设施问题，另一种是提示问题。如果把它们当作同一个指标来跟踪，就会使两者都更难诊断。

• 我今天可以在服务器端使用哪些工具？ 网络搜索、网页获取、知识库检索、客户自建的 MCP 服务器以及 Tool Search（用于 Anthropic 和 OpenAI 模型的懒加载）。

• 使用服务器端工具会产生额外费用吗？ 知识库检索、MCP 和 Tool Search 不会超出标准推理定价产生额外费用。网络搜索按每 1,000 次请求收取 10 美元。

• 我可以在同一个代理中混合使用客户端和服务器端工具吗？ 可以。您可以在推理请求中传递服务器端工具定义，同时在自己的代码中处理其他工具。它们相互独立工作。

• 我的 MCP 服务器需要放在公共互联网上吗？ 是的，针对服务器端 MCP。DigitalOcean 的推理层会从其自身网络连接到您的服务器，因此您的服务器需要一个公开的 URL。如果做不到这一点，请改用客户端 MCP。

• 如果服务器端工具在请求过程中失败会怎样？ 模型会继续使用它所获得的任何部分结果。它并不总会告知您工具未返回有用结果。请在系统提示中编写明确的指令，以说明当工具无结果返回时应如何处理。

• 当工具在服务器端运行时，我该如何调试响应缓慢的问题？ 使用 代理追踪 API。它会显示每次工具调用所花费的时间，从而帮助您判断是模型还是特定工具成为了瓶颈。

• 什么是 Tool Search，何时应该使用它？ Tool Search 会懒加载工具定义。标记为 defer_loading: true 的工具仅在模型需要时加载，而不会在每次请求时加载。当您的代理拥有众多工具且希望降低输入令牌使用量时，请使用它。

• 何时应该继续使用客户端工具？ 当您仍在开发阶段且需要轻松调试时，当您的工具在私有网络上运行时，或者当您的延迟预算非常紧张且每次网络往返都很重要时。

将工具执行移至服务器端会改变复杂性所在的位置。您原本需要自行管理的基础设施（连接、凭据、重试、扩容）将转移到托管层。您的智能体代码将变得更小，而您团队需要负责的运营范围也会缩小。

但构建智能体的困难部分不会随之迁移。为工具故障进行设计、保持 MCP 服务器温暖、将工具错误与模型错误区分开来、了解需要监控的内容：这些仍然是您的工作。区别在于，您是在稳定的基础设施之上完成这些工作，而不是同时还要维护管道运行。

这些权衡与您使用的提供商无关。架构决策不会根据您运行推理的位置而改变。

如果您此刻正在做决定，这里是简要版本：如果您的主要问题是基础设施开销，例如凭据、连接、重试和扩容，则使用服务器端工具；如果您的主要问题是可见性或控制，则使用客户端工具；如果您尚未确定，则先从客户端开始，了解故障模式，然后在基础设施成本超过调试收益时转向服务器端。

DigitalOcean 资源

• 如何使用服务器端工具 — DigitalOcean 文档
• 推理功能 — DigitalOcean 文档
• 推理定价 — DigitalOcean 文档
• Agent 追踪数据 — DigitalOcean 文档

MCP 基准测试

• MCP Bridge：面向模型上下文协议服务器的轻量级、与 LLM 无关的 RESTful 代理 — arXiv

Exa 基准测试

• 2026 年搜索 API：概览与基准测试 — Proxyway
• Exa Instant 发布 — Exa 博客