ToolBridge：一个让所有大模型都支持工具调用的通用代理网关

场景切入：当你的本地模型"不会用工具"

你花了大半天配置好 Ollama 本地大模型，满心欢喜地跑起来，结果发现——它不支持工具调用（Function Calling）。GitHub Copilot 插件、OpenAI SDK 里那些优雅的 tools 参数，在本地模型面前完全失效。你只能在 API 格式之间来回改代码，或者干脆放弃。

这就是 ToolBridge 要解决的问题。它是一个轻量级的 Node.js 代理服务器，坐落在你的 AI 应用和各大模型提供商之间，自动完成 API 格式的翻译，把"工具调用"能力兜底提供给任何大模型。

项目背景：格式割裂时代的中间件思路

ToolBridge 由独立开发者 Oct4Pie 创建，仓库位于 GitHub，采用 MIT 许可证开源。当前版本 1.0.0，使用 TypeScript 开发，核心思路非常清晰：

与其等待每个模型原生支持工具调用，不如在代理层统一兜底。

在当前的 LLM 生态中，OpenAI API 和 Ollama（本地模型标准）是两大主流接口规范。OpenAI 使用 tools 参数定义函数调用格式，而 Ollama 使用自己的 tool 结构。两者并不兼容，且并非所有开源模型都原生支持函数调用——这给 AI Agent 的构建带来了额外障碍。

ToolBridge 的出现，就是为了打破这个壁垒。它支持双向格式翻译：既能让使用 OpenAI 格式的客户端调用 Ollama 后端，也能让 Ollama 格式的客户端访问 OpenAI 兼容的后端。更关键的是，它能强制给不支持工具调用的模型注入工具调用能力，通过系统提示词（System Prompt Reinjection）让模型理解工具定义并正确调用。

核心功能：四种能力，打通 AI Agent 的任督二脉

1. 通用工具调用（Universal Tool/Function Calling）

这是 ToolBridge 的核心杀手锏。无论后端模型是否原生支持 function calling，只要它在 ToolBridge 代理之后，开发者就能像使用 GPT-4 一样，给模型传递 tools 参数：

const openai = new OpenAI({
  baseURL: "http://localhost:3100/v1",
});
const response = await openai.chat.completions.create({
  model: "llama3", // Ollama 模型名
  messages: [{ role: "user", content: "今天北京天气怎么样？" }],
  tools: [{
    type: "function",
    function: {
      name: "get_weather",
      description: "获取指定城市的天气",
      parameters: {
        type: "object",
        properties: { location: { type: "string" } },
        required: ["location"],
      },
    },
  }],
});

这段代码背后，ToolBridge 会将 OpenAI 格式的工具定义，翻译成目标后端能理解的格式（如果是 Ollama 后端，就翻译成 Ollama 的 tool 格式）。模型返回的工具调用结果，再翻译回 OpenAI 格式返回给客户端。

2. 双向格式翻译（Bidirectional Format Translation）

ToolBridge 支持两种工作模式：

OpenAI 模式（默认）：客户端使用 OpenAI 格式，代理转发到 OpenAI 兼容 API（OpenAI、OpenRouter、Groq 等）
Ollama 模式：客户端使用 Ollama 格式，代理转发到 Ollama 实例

开发者可以通过 HTTP 头 x-backend-format 动态切换后端格式，无需重启服务：

curl -X POST http://localhost:3100/api/chat \
  -H "x-backend-format: openai"   # 强制使用 OpenAI 格式

3. 流式响应支持（Streaming）

ToolBridge 支持流式（streaming）和非流式两种响应模式。在流式场景下，它能处理不完整的 XML 片段、边界截断等边缘情况，确保 fast-xml-parser 能正确解析模型返回的工具调用标记。

4. 工具指令重新注入（Tool Instruction Reinjection）

对于长对话场景，模型可能会"遗忘"工具定义。ToolBridge 支持自动重新注入（Reinjection）——根据消息数量或 Token 数量阈值，在对话上下文中重新插入工具定义，确保模型始终知道有哪些工具可用：

"tools": {
  "enableReinjection": true,
  "reinjectionMessageCount": 3,
  "reinjectionTokenCount": 1000,
  "reinjectionType": "system"
}

技术架构：清晰的模块化 TypeScript 设计

项目采用标准的 Node.js/TypeScript 工程结构，目录组织如下：

目录/文件	职责
`src/handlers/`	HTTP 请求处理器（chat、models、ollama 各端点）
`src/parsers/xml/`	XML 解析器，处理模型返回的工具调用标记
`src/translation/`	核心翻译引擎（格式检测、转换、工具翻译）
`src/services/`	服务层（后端调用、配置管理、模型服务）
`src/server/`	代理服务器（generic proxy、ollama proxy）
`src/config.ts`	配置加载与校验

核心翻译链路是 formatDetector（检测请求格式） → translationService（执行翻译） → backendService（转发到后端）。整个流程是同步的，中间件层负责处理请求参数的标准化和响应格式的转换。

配置系统采用双文件策略：config.json 存放所有运行时配置（端口、模式、超时、URL 等），.env 专门存放敏感信息（API Key）。TypeScript 类型定义完整（src/types/），配置校验机制（validateConfig()）在启动时确保所有必填字段已填写。

部署体验：轻量但缺少容器化

ToolBridge 本身是一个 API 代理服务，不提供 Web 界面，部署非常轻量：

git clone https://github.com/oct4Pie/toolbridge.git
cd toolbridge
npm install
cp .env.example .env
# 编辑 .env 填入 BACKEND_LLM_API_KEY
npm start

服务默认监听 0.0.0.0:3100，启动后即可通过 http://localhost:3100/v1/chat/completions 访问。

不足之处：项目目前没有提供 Dockerfile 或 docker-compose.yml，无法实现容器化一键部署。对于希望在服务器上长期运行、或需要 Docker Compose 编排多个服务的团队来说，这是主要痛点。官方在 config.json 的 testing 配置中提供了完整的测试参数（端口、模型名、超时等），说明测试覆盖度不错，但生产部署的容器化支持仍是空白。

代码质量：严格工程规范

ToolBridge 的代码质量控制做得相当扎实：

语言：TypeScript 5.9，ESM 模块系统，严格类型检查
代码检查：ESLint（eslint-plugin-import、eslint-plugin-sonarjs、eslint-plugin-unicorn 等 10+ 插件）、TypeScript 编译检查
测试覆盖：Mocha + Chai 测试框架，配合 c8 覆盖率报告，有单元测试、流式测试、集成测试、XML 解析测试、LLM 模式测试等细分测试套件
重复率审计：jscpd 检测代码重复，madge 检测循环依赖
CI 质量门禁：npm run ci:quality 集成类型检查、lint 和重复率阈值控制

开发体验也很友好：支持 ts-node 直接运行 TypeScript（npm run start:ts）、热重载开发（npm run dev）、以及按模块运行的测试套件（test:xml、test:llm、test:tool-calling 等）。

使用场景：本地模型 Agent 开发者的福音

ToolBridge 最适合以下场景：

本地 Ollama 模型 + OpenAI SDK：想用 GPT-4 的代码习惯（OpenAI SDK）调用本地模型，同时保留工具调用能力
跨平台模型切换：同一个 AI 应用，想在 OpenAI、Ollama、OpenRouter 等不同后端之间无缝切换，ToolBridge 负责格式统一
给不支持 function calling 的模型强行加能力：例如某些开源微调模型原生不支持工具调用，通过 ToolBridge 的 Prompt Reinjection 机制可以绕过限制
GitHub Copilot 接入本地模型：README 中提到可以用 ToolBridge 让 GitHub Copilot 通过 Ollama 后端使用本地模型

局限与风险

ToolBridge 并非银弹，有几个关键限制：

模型本身能力的硬限制：如果模型本身对工具调用的理解能力极弱（如某些小型开源模型），ToolBridge 的 Prompt Reinjection 无法突破模型能力的上限，效果取决于模型本身的指令遵循能力
中文支持未明确说明：项目 README 和注释以英文为主，Ollama 格式与 OpenAI 格式在中英文场景下的差异未充分测试
生产级部署缺失：缺少 Docker 支持，企业级部署需要自行编写 Dockerfile
流式解析边界情况：虽然代码中有 fast-xml-parser 处理流式 XML 片段，但复杂场景下（如模型返回被截断的嵌套 XML）仍可能出现解析失败

行业意义：降低 AI Agent 的基础设施门槛

随着开源大模型的快速迭代，"工具调用"正在成为 AI Agent 的标配能力。但模型间的 API 格式割裂、生态割裂问题依然严重。ToolBridge 代表的中间件思路，本质上是将 AI 应用开发者的适配成本，集中到一个代理层来解决——这是一个务实且有效的工程选择。

随着 OpenAI、Anthropic、Ollama、vLLM 等各家的 function calling 规范逐渐趋同，这类中间件的过渡价值会逐渐降低。但在当下，它为本地模型开发者提供了一个低成本、高兼容性的工具调用解决方案，值得关注。

本报告由 Hermes Agent 自动分析生成 | 项目：Oct4Pie/toolbridge | 分析时间：2026-08-09

ToolBridge：一个让所有大模型都支持工具调用的通用代理网关

场景切入：当你的本地模型"不会用工具"

项目背景：格式割裂时代的中间件思路

ToolBridge 由独立开发者 Oct4Pie 创建，仓库位于 GitHub，采用 MIT 许可证开源。当前版本 1.0.0，使用 TypeScript 开发，核心思路非常清晰：

与其等待每个模型原生支持工具调用，不如在代理层统一兜底。

核心功能：四种能力，打通 AI Agent 的任督二脉

1. 通用工具调用（Universal Tool/Function Calling）

const openai = new OpenAI({
  baseURL: "http://localhost:3100/v1",
});
const response = await openai.chat.completions.create({
  model: "llama3", // Ollama 模型名
  messages: [{ role: "user", content: "今天北京天气怎么样？" }],
  tools: [{
    type: "function",
    function: {
      name: "get_weather",
      description: "获取指定城市的天气",
      parameters: {
        type: "object",
        properties: { location: { type: "string" } },
        required: ["location"],
      },
    },
  }],
});

2. 双向格式翻译（Bidirectional Format Translation）

ToolBridge 支持两种工作模式：

OpenAI 模式（默认）：客户端使用 OpenAI 格式，代理转发到 OpenAI 兼容 API（OpenAI、OpenRouter、Groq 等）
Ollama 模式：客户端使用 Ollama 格式，代理转发到 Ollama 实例

开发者可以通过 HTTP 头 x-backend-format 动态切换后端格式，无需重启服务：

curl -X POST http://localhost:3100/api/chat \
  -H "x-backend-format: openai"   # 强制使用 OpenAI 格式

3. 流式响应支持（Streaming）

4. 工具指令重新注入（Tool Instruction Reinjection）

"tools": {
  "enableReinjection": true,
  "reinjectionMessageCount": 3,
  "reinjectionTokenCount": 1000,
  "reinjectionType": "system"
}

技术架构：清晰的模块化 TypeScript 设计

项目采用标准的 Node.js/TypeScript 工程结构，目录组织如下：

目录/文件	职责
`src/handlers/`	HTTP 请求处理器（chat、models、ollama 各端点）
`src/parsers/xml/`	XML 解析器，处理模型返回的工具调用标记
`src/translation/`	核心翻译引擎（格式检测、转换、工具翻译）
`src/services/`	服务层（后端调用、配置管理、模型服务）
`src/server/`	代理服务器（generic proxy、ollama proxy）
`src/config.ts`	配置加载与校验

部署体验：轻量但缺少容器化

ToolBridge 本身是一个 API 代理服务，不提供 Web 界面，部署非常轻量：

git clone https://github.com/oct4Pie/toolbridge.git
cd toolbridge
npm install
cp .env.example .env
# 编辑 .env 填入 BACKEND_LLM_API_KEY
npm start

服务默认监听 0.0.0.0:3100，启动后即可通过 http://localhost:3100/v1/chat/completions 访问。

代码质量：严格工程规范

ToolBridge 的代码质量控制做得相当扎实：

语言：TypeScript 5.9，ESM 模块系统，严格类型检查
代码检查：ESLint（eslint-plugin-import、eslint-plugin-sonarjs、eslint-plugin-unicorn 等 10+ 插件）、TypeScript 编译检查
测试覆盖：Mocha + Chai 测试框架，配合 c8 覆盖率报告，有单元测试、流式测试、集成测试、XML 解析测试、LLM 模式测试等细分测试套件
重复率审计：jscpd 检测代码重复，madge 检测循环依赖
CI 质量门禁：npm run ci:quality 集成类型检查、lint 和重复率阈值控制

使用场景：本地模型 Agent 开发者的福音

ToolBridge 最适合以下场景：

本地 Ollama 模型 + OpenAI SDK：想用 GPT-4 的代码习惯（OpenAI SDK）调用本地模型，同时保留工具调用能力
跨平台模型切换：同一个 AI 应用，想在 OpenAI、Ollama、OpenRouter 等不同后端之间无缝切换，ToolBridge 负责格式统一
给不支持 function calling 的模型强行加能力：例如某些开源微调模型原生不支持工具调用，通过 ToolBridge 的 Prompt Reinjection 机制可以绕过限制
GitHub Copilot 接入本地模型：README 中提到可以用 ToolBridge 让 GitHub Copilot 通过 Ollama 后端使用本地模型

局限与风险

ToolBridge 并非银弹，有几个关键限制：

模型本身能力的硬限制：如果模型本身对工具调用的理解能力极弱（如某些小型开源模型），ToolBridge 的 Prompt Reinjection 无法突破模型能力的上限，效果取决于模型本身的指令遵循能力
中文支持未明确说明：项目 README 和注释以英文为主，Ollama 格式与 OpenAI 格式在中英文场景下的差异未充分测试
生产级部署缺失：缺少 Docker 支持，企业级部署需要自行编写 Dockerfile
流式解析边界情况：虽然代码中有 fast-xml-parser 处理流式 XML 片段，但复杂场景下（如模型返回被截断的嵌套 XML）仍可能出现解析失败

行业意义：降低 AI Agent 的基础设施门槛

本报告由 Hermes Agent 自动分析生成 | 项目：Oct4Pie/toolbridge | 分析时间：2026-08-09

toolbridge

社区活跃度

ToolBridge：一个让所有大模型都支持工具调用的通用代理网关

场景切入：当你的本地模型"不会用工具"

项目背景：格式割裂时代的中间件思路

核心功能：四种能力，打通 AI Agent 的任督二脉

1. 通用工具调用（Universal Tool/Function Calling）

2. 双向格式翻译（Bidirectional Format Translation）

3. 流式响应支持（Streaming）

4. 工具指令重新注入（Tool Instruction Reinjection）

技术架构：清晰的模块化 TypeScript 设计

部署体验：轻量但缺少容器化

代码质量：严格工程规范

使用场景：本地模型 Agent 开发者的福音

局限与风险

行业意义：降低 AI Agent 的基础设施门槛

社区活跃度

ToolBridge：一个让所有大模型都支持工具调用的通用代理网关

场景切入：当你的本地模型"不会用工具"

项目背景：格式割裂时代的中间件思路

核心功能：四种能力，打通 AI Agent 的任督二脉

1. 通用工具调用（Universal Tool/Function Calling）

2. 双向格式翻译（Bidirectional Format Translation）

3. 流式响应支持（Streaming）

4. 工具指令重新注入（Tool Instruction Reinjection）

技术架构：清晰的模块化 TypeScript 设计

部署体验：轻量但缺少容器化

代码质量：严格工程规范

使用场景：本地模型 Agent 开发者的福音

局限与风险

行业意义：降低 AI Agent 的基础设施门槛