agent-tools 系列第 1 篇 · 行业分析 · 约 1800 字

---

2023 年 6 月，OpenAI 发布了 Function Calling。一夜之间，所有 Agent 框架都有了一个共同的命题：怎么让 LLM 调用外部工具？

两年过去了。LangChain 的 Tool 抽象已经迭代了三版，Anthropic 推出了 Tool Use，Google 有了 Gemini Function Calling，MCP 协议试图用统一标准终结碎片化。

看起来很繁荣。但拆开来看，每个方案都在不同维度上让人难受。

繁荣之下的四个痛点

痛点一：框架绑架。

你用 LangChain 的 @tool 装饰器写了一个工具。现在你想把这个工具直接给另一个不用 LangChain 的团队用——不行。工具和框架是焊死的。要迁移？重写。

这不是 LangChain 的问题。OpenAI 的 function definition、Anthropic 的 tool use block、Google 的 function declaration——每个厂商都定义了自己的 Schema 格式。工具一旦用一种格式定义，切换到另一种就需要翻译层。

痛点二：Agent 调用工具没有安全护栏。

LLM 本质上是概率模型。它可能传一个 10MB 的字符串给你的工具函数，可能传 50 层嵌套的 JSON，可能在一秒内调用同一个工具 1000 次。

大部分框架对此的处理是——什么都不做。你把函数注册进去，Agent 直接调用。没有参数校验，没有速率限制，没有熔断机制。生产环境里这就是事故。

痛点三：不可独立部署。

你的工具注册表是嵌在 Agent 进程里的。你想让另一个服务复用同一批工具？做不到。你想让工具暴露成 HTTP API 给非 Python 客户端调用？做不到。你想让 Claude Desktop 通过 MCP 协议访问你的工具？做不到。

工具系统和 Agent 系统耦合在一起，导致工具无法独立演进、独立扩容、独立对外服务。

痛点四：测试是噩梦。

LangChain 的 Tool 类依赖一个庞大的继承体系。你想单独测试一个工具的执行逻辑？你得 mock 掉半个框架。OpenAI 的 function calling 直接和 API 调用耦合——不调 API 就没法验证 Schema 正确性。

业界的四种答案

回看 2024-2025 年，工具调用领域形成了四种主要方案：

方案 A：厂商原生（OpenAI / Anthropic / Gemini）

最轻量。直接写一个 JSON Schema，跟着 chat completion 请求一起发给 API。适合单机脚本和原型验证。

问题是：Schema 没有复用性，每次调用都要传完整的工具定义（吃 token）；没有执行层——LLM 只返回"我想调用哪个工具"的参数，真正的执行逻辑你得自己写。

方案 B：框架内置（LangChain / LlamaIndex）

生态最丰富。LangChain 有上千个预制工具，从搜索引擎到数据库到代码解释器。

问题是：框架耦合。LangChain 的 Tool 和 BaseTool 和 BaseModel 深度绑定，牵一发动全身。做技术选型时选了 LangChain，就等于把所有工具实现押注在了一个框架上。

方案 C：协议标准（MCP）

架构最先进。Anthropic 提出的 Model Context Protocol 定义了一套 Client-Server 协议，让任何 MCP Server 的工具都能被任何 MCP Client 发现和调用。

问题是：MCP 解决的是「通信协议」，不是「工具管理」。它告诉你工具怎么被发现、怎么被调用，但不关心这个工具是谁注册的、参数怎么校验、失败了怎么重试、是否该被熔断。这些「执行层」的能力，MCP 不管。

方案 D：agent-tools 的定位

agent-tools 走的是第四条路：一个可独立部署、带完整安全护栏、协议无关的工具基础设施。

它不替代 MCP——它可以是 MCP Server 背后的 Tool Registry。它不排斥 LangChain——它导出的 Schema 可以喂给任何框架。它不绑定厂商——一套 ToolMetaData 生成所有格式。

核心思路就一句话：工具调用是 Agent 的「手」，LLM 是 Agent 的「脑」。手和脑应该解耦。

解耦意味着什么

具体来说，agent-tools 和现有方案的关键差异在三个设计决策上：

决策一：零内部依赖

agent-tools 不依赖任何其他 Agent OS 包，也不依赖任何特定 LLM SDK。pip install agent-tools 只装两个依赖：jsonschema 和 pyyaml。

这意味着你能在任何 Python 项目里用它——Flask、FastAPI、Django、CLI 脚本、Jupyter Notebook。它不是"框架的一部分"，它是一个独立的库。

决策二：安全是内置的，不是外挂的

速率限制、参数校验、输入清洗、熔断器——这些不是"后续可以加"的功能，而是执行管道的默认环节。工具在被 Agent 调用之前，会经过 PreHook 链的参数检查和 RateLimiter 的频率控制。调用失败会自动分类（可重试 / 不可重试 / 致命），并根据分类决定重试策略。

这不是说 agent-tools 比别的方案更"安全"。而是说，安全护栏是框架的责任，不该推给每个工具的实现者。

决策三：协议是外壳，注册表是引擎

agent-tools 的 ToolRegistry 是一个独立运行的「工具注册中心」。它可以同时对外提供三种协议：

• HTTP REST API（给 Web 应用调用）
• MCP stdio（给 Claude Desktop 调用）
• MCP SSE（给远程 Agent 调用）

同一个工具注册一次，三种协议自动可用。这背后的思想是：工具的定义和执行是一回事，工具的暴露方式是另一回事。

这个系列会写什么

接下来 20 篇，我们会从 @tool 装饰器开始，逐步走到线程安全、熔断机制、审计系统、模块化架构。每一篇都是可以独立阅读的，但连起来是一个完整的设计故事。

下篇预告：《五分钟上手——@tool 装饰器与第一个工具》。我们会写第一段 agent-tools 代码，看一个函数是如何在几行内变成可被 Agent 调用的工具的。

---

agent-tools项目地址：https://gitee.com/yindeyue/agent_tools/

参考

• OpenAI Function Calling: https://platform.openai.com/docs/guides/function-calling
• Anthropic Tool Use: https://docs.anthropic.com/en/docs/build-with-claude/tool-use
• MCP Specification: https://modelcontextprotocol.io/
• LangChain Tools: https://python.langchain.com/docs/concepts/tools/
• agent-tools GitHub: https://github.com/anthropics/agent-tools