用本地小模型接管 AI Agent 工具调用：开源 OATs 实战方案

使用 AI 编码 Agent 时，你是不是也有这样的困惑：每次让 Agent 调用一个工具函数，都要走一遍昂贵的大模型推理——哪怕这个工具只是查个文件、调个 API、计算个日期，也得让 GPT-4 级别的模型来决策。一个月下来，API 账单直线飙升。

Open Agent Tools Coder (OATs) 正是为了解决这个问题而生的开源方案。它提出了一个简单但有效的架构：用本地小模型（甚至 270M 参数的 FunctionGemma）来接管 Agent 的工具调用决策，把大模型留给真正需要推理的对话场景。

OATs 的核心思路

OATs 的核心不是”用更好的模型”，而是”用更合适的模型”。它的架构包含两个关键组件：

1. Prompt Index（提示索引）：预编译本地代码仓库中所有函数的功能描述，形成一个自然语言→函数的映射索引
2. 小模型调度器：用小参数模型（FunctionGemma 270M、Qwen3.6-27B 等）根据用户输入的 prompt，从索引中检索并调用最匹配的函数

整个流程是：用户/大模型发出请求 → 小模型解析意图 → Prompt Index 检索匹配函数 → 小模型执行工具调用 → 返回结果。大模型只在需要复杂推理时才介入。

安装与初始化

OATs 的安装非常轻量：

git clone https://github.com/district-solutions/open-agent-tools-coder oats
cd oats
pip install -e .
pip install --upgrade aiohttp

初始化后，可以用 get-tools 命令来验证本地的 Prompt Index 是否正确构建：

get-tools -p 'get third friday'

如果一切正常，你会看到类似下面的输出：

{
  "status": true,
  "actions": ["get_third_friday_dates"],
  "src_files": ["coder/date.py"],
  ...
}

这意味着”get third friday”这条自然语言请求，已经被正确映射到了 coder/date.py 中的 get_third_friday_dates 函数，无需任何大模型参与。

小模型配置方案

OATs 支持多种本地模型方案：

入门配置（单卡 12GB）：FunctionGemma 270M + Qwen3.6-27B（AWQ 量化），用 vLLM 部署

cd stack
./restart-vllm-qwen36-27b.sh

进阶配置（24GB+）：Qwen3.6-35B-A3B + FunctionGemma，支持更复杂的工具调用场景

安装完成后，OATs 默认会在本地运行一个编码 Agent 终端，所有工具调用都走本地小模型。你可以在配置文件中指定哪些场景走大模型（复杂推理、代码生成），哪些走小模型（文件操作、数据查询、日期计算）。

实战场景：成本对比

假设你每天有 1000 次工具调用请求：

当然，本地部署有硬件成本（GPU 采购或租赁），但当你拥有 GPU 后，边际增量成本几乎为零。对于需要大规模运行 Agent 的团队，这个差异非常显著。

更广泛的应用场景

OATs 的 Prompt Index 概念不仅仅适用于编码任务。官方维护了 141,000+ 个预构建工具的索引库，包含从文件操作到数据库查询的各种常用工具。你还可以在 HuggingFace 数据集 上找到更多的 Prompt Index 资源。

典型的适用场景包括：

• CI/CD 管道中的工具调用：测试、构建、部署等确定性操作走小模型
• 数据处理 Agent：文件转换、格式化、批量处理等重复性任务
• 内部工具集成：公司内部脚本、API 封装、运维命令

最佳实践

1. 先用 get-tools 验证映射：在部署模型之前，先用这个命令确认 prompt→function 的映射是否正确
2. 分阶段引入：先从简单的工具开始（文件 I/O、日期处理），逐步扩展到复杂的工具链
3. 混合调度：复杂任务走大模型＋小模型工具调用的组合模式，平衡准确率和成本
4. 自定义索引：修改本地的 .ai/AGENT.repo_uses.python.tools.json 文件，微调函数描述以优化匹配

局限性

• 依赖本地 GPU（至少 12GB VRAM 运行 Qwen3.6-27B 量化版）
• Prompt Index 需要定期更新以保持与代码库同步
• 对于需要上下文推理的复杂工具调用，小模型可能不如大模型准确
• 中文支持依赖于所选小模型的中文能力

总结

OATs 的核心理念不是发明新的 AI 能力，而是做架构上的分拆——把”要思考的事”和”要执行的事”分开。对于 AI 工具调用这个场景，70% 以上的调用是确定性的（查数据、调 API、解析文件），没有必要每次都让大模型来处理。用一个 270M 的小模型配合 Prompt Index 索引，就能完成大部分工具调度工作，既降低了延迟和成本，也释放了大模型的计算资源给真正需要推理的任务。

对于正在自建 AI Agent 基础设施的团队来说，这个架构思路值得借鉴。OATs 的完整代码和文档都在 GitHub 开源，可以按需集成到现有的 Agent 工作流中。