Claude智能体工具集成指南：自定义工具、MCP与子智能体

Claude智能体已经能读取文件，但要让它在真实工作流里承担职责，还需要给它一套趁手的工具。从自定义函数到MCP服务器，再到子智能体，这套工具链决定了智能体能做多复杂的事。

自定义工具：从函数到智能体能力

自定义工具本质上是你自己代码里的函数。用TypeScript的tool函数或Python的tool装饰器，声明一个名称、描述、输入schema和handler，就把一段普通逻辑变成了智能体可调用的能力。

关键细节在于错误处理：把返回值设为is_error: true，可以控制工具失败时Claude读到的内容。这不是简单的异常抛出，而是让模型理解"发生了什么"并据此决策。只读工具则标记read_only_hint，允许它们并行执行，提升多工具场景下的响应效率。

MCP服务器：进程内与外部服务的统一接入

把自定义工具包进一个进程内MCP服务器，再通过mcp_servers参数传入，并在allowed_tools中列出它的MCP名称，工具就接入了智能体的调用范围。这套机制的价值在于统一：无论是本地函数还是外部服务，都以MCP协议暴露。

需要外部服务时，把MCP服务器指向一个命令或HTTP URL，用通配符放行即可。初始化消息里会标明哪些服务器失败或需要关闭，这是排查工具可用性的第一站。

据视频演示，当工具数量达到数百个时，工具搜索默认开启，Claude只加载当前任务需要的那部分。这解决了工具膨胀带来的上下文压力，也让大规模工具库变得实用。

MCP（Model Context Protocol） 是 Anthropic 提出的开放协议，用于在模型与外部工具/数据源之间建立标准化的通信契约。它把"工具提供方"抽象为服务器（Server），"工具调用方"抽象为客户端（Client，即智能体运行时），双方通过 JSON-RPC 风格的消息交换能力清单与调用请求。协议定义了工具（tools）、资源（resources）、提示（prompts）等原语，并规定了初始化握手流程——这正是初始化消息能报告服务器状态的原因。MCP 的核心价值在于解耦：同一个服务器既可以被本地进程内嵌，也可以作为独立进程或远程 HTTP 服务运行，而调用方无需修改代码。这种设计让工具生态可以跨产品复用，也让企业能把内部系统封装一次、多处接入。

子智能体：隔离上下文与预算控制

子智能体在agents选项中定义，通过agent加入允许的工具列表。每个子智能体运行在全新的上下文中，只返回最终消息——这意味着主智能体不必背负子任务的中间过程，上下文窗口被有效节省。

预算控制靠max_budget_usd参数，给每个子智能体的花费设上限。对于会调用付费API或消耗大量token的场景，这是把成本关进笼子的直接手段。多智能体协作的工程化，很大程度上就是这类隔离与限额机制的设计。

上下文窗口（context window） 指模型单次推理能容纳的 token 总量上限，它同时承载系统提示、对话历史、工具定义与工具返回结果。当主智能体调用一个需要大量中间步骤的子任务时，检索结果、试错日志等中间产物会持续占用窗口，挤占真正重要的信息。子智能体机制的本质是上下文隔离：子任务在独立窗口中运行，只有最终消息回传给主智能体，中间过程被"压缩"成一条结论。这与软件工程中的进程隔离思路类似——用边界换取可控性。代价是信息损失：主智能体无法看到子任务的推理细节，因此子智能体的最终输出需要自包含、可独立理解，这对提示设计提出了更高要求。

工具设计的工程取舍

这套工具链透露出的设计思路值得琢磨。错误信息作为工具输出的一部分交给模型，是把模型当作能读状态的决策者，而非被动执行器。只读标记换并行执行，是在延迟和资源之间做显式权衡。工具搜索默认开启，则默认了工具规模会增长这一现实。

对构建生产级智能体产品的团队来说，这些机制不是可选项。工具定义、MCP接入、子智能体隔离和预算上限，构成了智能体从演示走向可运维系统的基本骨架。文档覆盖了其余细节，但骨架的每一环都需要在具体产品里做适配。

工具搜索（tool search） 针对的是工具规模膨胀问题。当智能体可调用的工具达到数百个时，若把所有工具的名称、描述与 schema 一次性塞进上下文，仅工具定义就可能耗尽可观的 token 预算，还会稀释模型对当前任务的注意力。工具搜索的做法是先把工具库做成可检索的索引，模型按当前任务语义检索出相关子集再加载。这本质上是把"上下文预算分配"问题转化成了检索问题，与 RAG 的思路一脉相承，区别在于检索对象是能力而非知识。其风险在于检索召回不准会导致模型"看不见"本可用的工具，因此工具描述的质量直接决定了这套机制的上限。