access: private

Tool-Augmented LLM Gateway — 从 Proxy 到 AI 能力平台

🎯 一句话版本

关于Tool Augmented Llm Gateway Report的深度研究报告

一、背景与起源

1.1 问题：LLM 只能说，不能做

当前的 LLM API（OpenAI、Anthropic、Google 等）本质上是「纯文本进，纯文本出」的服务。即使模型支持 tool calling，执行端仍然在客户端 —— 开发者需要自己写代码解析 tool_call、调用外部 API、构造 tool_result、再次请求 LLM。

这意味着每个使用 LLM 的应用都要：

1.2 启发：OpenRouter 的 Web Search Plugin

OpenRouter 提供了一个有趣的先例：通过 :online 后缀或 plugins 字段，给任意模型添加联网搜索能力。

它的实现分两种模式：

这证明了一个关键洞察：proxy 层可以增强 LLM 的能力，而不仅仅是路由请求。

1.3 小虾 llmproxy 的突破

小虾（xiaoxia）的 Docker hosting 平台中，llmproxy 做了一件更激进的事：

当 LLM 返回 tool_call（如 web_search）时，proxy 不把 tool_call 返回给用户容器，而是直接在主机侧执行，把结果注入对话，再次调用 LLM，直到获得最终文本回复。

这个设计最初是为了解决一个实际问题：用户的 Docker 容器没有网络出口（为了安全隔离），但 LLM 需要联网搜索。通过在 proxy 层拦截和执行 tool call，用户容器无需任何改动就获得了搜索能力。

二、核心概念

2.1 Tool-Augmented LLM Gateway

一个兼容 OpenAI API 的网关服务，在 proxy 层拦截 LLM 返回的 tool calls 并在服务端执行，对调用者完全透明。

一句话定位：OpenRouter 解决了「统一 LLM 接口」的问题，我们解决「统一 LLM + Tool 接口」的问题。

2.2 核心价值主张

维度传统方式Tool-Augmented Gateway
Tool 执行客户端自建服务端透明执行
API Key 管理散落在各客户端集中在 Gateway
安全隔离客户端需要网络出口客户端可完全隔离
能力扩展每个应用单独集成所有应用自动获得
计费多处分散计费统一计费
模型绑定部分能力锁定特定模型任意模型 + 任意工具

2.3 关键设计原则

三、技术架构

3.1 请求流程


用户请求 (OpenAI API 格式)
    │
    ▼
┌─────────────────────────────┐
│        Gateway Layer        │
│  ┌───────────────────────┐  │
│  │   请求预处理          │  │
│  │   - 注入可用 tools    │  │
│  │   - 路由选择 LLM      │  │
│  └───────────┬───────────┘  │
│              ▼              │
│  ┌───────────────────────┐  │
│  │   LLM Provider        │  │
│  │   (任意模型)           │  │
│  └───────────┬───────────┘  │
│              ▼              │
│  ┌───────────────────────┐  │
│  │   响应分析            │  │
│  │   - 检测 tool_call    │  │
│  │   - 文本 → 直接返回   │  │
│  │   - tool_call → 拦截  │  │
│  └───────────┬───────────┘  │
│              ▼              │
│  ┌───────────────────────┐  │
│  │   Tool Executor       │  │
│  │   - web_search        │  │
│  │   - tts / stt         │  │
│  │   - image_gen         │  │
│  │   - code_exec         │  │
│  │   - file_fetch        │  │
│  └───────────┬───────────┘  │
│              ▼              │
│  ┌───────────────────────┐  │
│  │   构造 tool_result    │  │
│  │   再次调用 LLM        │  │
│  │   (循环直到纯文本)    │  │
│  └───────────────────────┘  │
└─────────────────────────────┘
    │
    ▼
最终文本回复返回用户

3.2 支持的工具集

第一阶段（MVP）：

工具后端实现说明
`web_search`Brave Search API联网搜索，最高频需求
`file_fetch`HTTP client抓取网页/下载文件

第二阶段（能力扩展）：

工具后端实现说明
`tts`IndexTTS2 / Edge TTS文字转语音
`stt`Whisper语音转文字
`image_gen`Stable Diffusion / DALL-E图片生成
`code_exec`安全沙箱代码执行

第三阶段（生态）：

3.3 流式响应处理

关键技术挑战：当 LLM 以 streaming 模式返回时，tool_call 可能分散在多个 chunk 中。

处理策略：

1. Buffer 模式：收集完整 tool_call 后执行，执行完再切回 streaming

2. 通知模式：在等待 tool 执行期间，向客户端发送 status event（如 SSE 注释）

3. 并行执行：多个 tool_call 并行执行，减少等待时间

3.4 Tool 注入策略

Gateway 需要在请求中注入可用的 tool definitions。两种策略：

推荐先用 Always-inject 上线，后续根据数据优化为 Smart-inject。

四、竞品分析

4.1 竞品矩阵

产品LLM 路由Tool 定义Tool 执行模型无关独立 API
**OpenRouter**✅❌❌✅✅
**OpenAI Assistants**❌✅✅❌ (仅 OpenAI)✅
**LangChain / CrewAI**❌✅✅ (客户端)✅❌ (框架)
**Anthropic MCP**❌✅✅ (客户端)❌ (仅 Claude)❌ (协议)
**我们**✅✅✅ (服务端)✅✅

4.2 OpenAI Assistants API 的兴衰：一个重要的市场信号

时间线：

失败原因分析：

替代品 Responses API 的设计转向：

对我们的启示：

1. OpenAI 自己验证了"有状态全托管"路线是错的，转向无状态——跟我们的 proxy 拦截模式天然吻合

2. Responses API 仍然锁定 OpenAI 模型——我们的"任意模型 + 任意工具"定位依然成立且更有价值

3. 大量基于 Assistants API 的应用需要在 5 个月内迁移——部分开发者会寻找不绑定单一厂商的替代方案，这是我们的获客窗口

4. OpenAI 验证了方向正确，但他们的实现太封闭——开放版本正好填这个空缺

4.3 关键差异化

4.3 护城河

五、商业模式

5.1 收入来源

1. LLM 调用透传

2. Tool 调用按次计费

3. Pro 套餐

5.2 成本结构

成本项预估说明
LLM API 费用变动成本按量透传
搜索 API (Brave)~$0.003/次按量付费
GPU 算力 (TTS/STT/图片)固定+变动自建或云 GPU
服务器/带宽固定成本Gateway 本身

5.3 关键指标

六、实现路线图

Phase 0：验证（1-2 周）

Phase 1：MVP（2-4 周）

Phase 2：能力扩展（1-2 月）

Phase 3：生态（3-6 月）

七、风险与挑战

技术风险

商业风险

缓解策略

八、设计讨论：Tool Call 上下文透传

8.1 初始担忧

最初我们担心：proxy 拦截 tool call 后，用户侧的 AI 应用（如 OpenClaw）只看到最终回复，中间的搜索过程被"吞掉"，可能导致上下文断裂、调试困难等问题。

8.2 实际分析：问题远没有那么严重

仔细分析实际流程后发现，简单方案就够了：


完整流程：
1. 用户: "阿森纳的后面赛程是？"
2. LLM 返回: tool_call(web_search, "阿森纳 2026 赛程")
3. proxy 拦截 → 调用主机 Brave Search → 拿到结果 → 喂回 LLM
4. LLM 生成最终回答: "4月5日打切尔西，4月12日打..."
5. proxy 只返回第4步的最终回答给用户

用户侧的对话历史：


[
  {"role": "user", "content": "阿森纳的后面赛程是？"},
  {"role": "assistant", "content": "阿森纳接下来的赛程是：4月5日打切尔西..."}
]

为什么这就够了？

唯一的边际损失：搜索结果里有 20 条数据但 LLM 只提了 5 条，追问第 6 条时需要重新搜。但这种情况很少见，且重新搜一次的成本（$0.005）远低于每轮都带着搜索结果的 token 成本。

8.3 结论：简单方案优先

默认策略：只返回最终回答，不透传中间步骤。

理由：

可选增强（未来按需添加）：

这个设计印证了一个原则：先做最简单的，遇到真实问题再优化。

九、总结

Tool-Augmented LLM Gateway 的核心洞察是：在 proxy 层拦截和执行 tool calls，将 LLM 从「只能说」变成「能说也能做」。

这不仅仅是一个技术创新，更是一个产品范式的转变：

从小虾 llmproxy 的一个巧妙 hack，到一个独立的 AI 能力平台 —— 这是一条清晰的产品化路径。

评分

维度分数说明
创意?/10
技术深度?/10
实用性?/10
影响力?/10
数据支撑?/10
与我们的相关性?/10
**综合****?/10**需要后续评估

> 一句话总结：（报告的核心价值与我们的关联）