Ratel：上下文工程平台让 AI Agent 节省 80% token 的技术解析

Skill超级捕获手 技术创作者 2026-09-08 14 阅读

Ratel 是一个面向 AI Agent 的上下文工程平台，通过选择性注入解决工具过载与 token 成本两大问题。其核心机制是将 Agent 的工具和 Skill 注册为检索目录，每次仅把当前轮次需要的工具注入上下文，而非一次性塞入全部工具列表，从而将 token 消耗降低约 80%，同时恢复因上下文膨胀而丢失的模型准确率。

功能与原则

Ratel 的设计原则是渐进披露（Progressive Disclosure）：工具和 Skill 不再堆在 System Prompt 里，而是索引到一个可检索的目录（Catalog），Agent 在每轮对话时通过 search_capabilities 查询目录，只加载与当前任务相关的工具。这一机制同时解决两个痛点：Token 成本（每次请求都包含所有工具的 schema）和准确率下降（模型被无关工具淹没后选错工具）。

认可度

截至 2026-09-08，GitHub 约 432 星（活跃维护，2026-09-07 仍有更新），MIT 许可证。项目在技术社区引发讨论，被认为是”context engineering”赛道最有参考价值的开源方案之一。有用户在生产环境反映接入后 token 成本下降约 81%。

链接

GitHub：https://github.com/ratel-ai/ratel

原作者

项目由 ratel-ai 团队维护，核心贡献者 Giacomo 和 Roberto，曾为 SaaS 公司构建 Agent 系统。项目通过 Show HN 于 2026-07-16 开源，随后持续活跃更新。

介绍

随着 Agent 系统规模扩大，开发者普遍面临一个困境：工具越多，Agent 的 System Prompt 越长，每次 API 调用都在为从未使用过的工具 schema 付费。更糟糕的是，上下文窗口越满，模型越容易选错工具——在 100 个工具的 Agent 中，基准单工具选择准确率仅 8.3%，基本等同于随机。

Ratel 从检索角度重新设计工具选择机制。工具注册到 ToolCatalog，Skill 注册到 SkillCatalog；Agent 每轮通过 Ratel 提供的 search_capabilities 工具检索目录，Ratel 返回 top-K 相关工具，只有这些工具的 schema 被注入当前上下文。检索默认使用 BM25 算法（与主流搜索引擎相同），运行在进程内，无需外部服务。

其架构分为三层：目录层（工具/Skill 注册）、检索层（BM25/语义/混合检索）和注入层（将匹配结果注入 Agent 上下文）。此外还有 facts 原语用于常量上下文（如品牌话术、地址），仅在上下文不新鲜时重新注入。

特点

  • ~80% token 节省：100 工具目录下，单工具选择 token 减少 83%，准确率从 8.3% 恢复至 76.7%（BFCL v3 基准）
  • 零基础设施：BM25 进程内运行，无 Vector DB、无 Embedding 服务、无外部依赖
  • 渐进式披露：工具 schema 按需加载，解决上下文膨胀导致的模型漂移问题
  • 多语言 SDK：TypeScript SDK（@ratel-ai/sdk）和 Python SDK（ratel-ai），底层为 Rust 引擎
  • 灵活检索：BM25 默认，语义检索和混合检索可选；支持 OpenAI 兼容 Embedding 端点
  • Skill 一等公民：Skill 同样注册到目录，通过 get_skill_content 按需加载
  • 可观测性：内置 OpenTelemetry traces，记录检索决策全过程，回答”Agent 为什么选了这个工具”

使用方法

安装 SDK：

# TypeScript
pnpm add @ratel-ai/sdk

# Python
pip install ratel-ai

注册工具与 Skill：

import { ToolCatalog, SkillCatalog, searchCapabilitiesTool } from "@ratel-ai/sdk";

const catalog = new ToolCatalog();
catalog.register({
  id: "read_file",
  name: "read_file",
  description: "Read a file from local disk.",
  inputSchema: { type: "object", properties: { path: { type: "string" } } },
  execute: async ({ path }) => ({ contents: await readFile(path, "utf8") }),
});

const skills = new SkillCatalog();
skills.register({
  id: "inspect-file",
  name: "inspect-file",
  tools: ["read_file"],
  body: "Read the requested file, then ground your answer in its contents.",
});

// 将 search 工具接入 Agent
const search = searchCapabilitiesTool(catalog, skills);

MCP 代理模式：也可以将 Ratel 作为 MCP 服务器代理，拦截 MCP Host 的工具列表，过滤后转发给上游 Agent，无需修改 Agent 代码。

使用场景与人群

  • 工程团队：运行 50+ 工具的复杂 Agent，面临高 token 成本和选错工具问题
  • 本地模型用户：上下文窗口有限（如 Qwen 3.5 等小模型），对 token 消耗极为敏感
  • Agent 框架开发者：构建多 Agent 系统，需要工具按需分发而非一次性广播
  • 成本敏感项目：按 token 计费的商业 Agent 应用，需要精确控制每次请求的上下文大小

输入与输出案例

场景 1：多工具 Agent 成本优化

某 Agent 集成了 300+ 工具，原本每次请求包含所有工具 schema，每次调用 token 消耗极高。接入 Ratel 后：

  • 接入前：每次请求 → 完整工具列表 → 高 token 成本
  • 接入后：每次请求 → Ratel 检索当前任务相关工具（top-5）→ token 成本降低 81%

场景 2：MCP 多服务器环境

Claude Code 连接了 4 个 MCP 服务器，总工具数超过 200。在 Ratel 代理模式下：

  • 请求：「帮我查看这个 React 组件的性能问题」
  • Ratel 检索：识别需要 read_file + execute_command，从 200 工具中选出 2 个
  • 输出：仅这 2 个工具的 schema 注入上下文，Agent 准确调用，响应质量提升

Ratel 解决的是 Agent 规模化后不可避免的”上下文税”问题——不是更强大的模型，而是更聪明的上下文管理。对于正在构建生产级 Agent 系统的开发者，这是一个值得在架构早期就纳入考量的基础设施层。

GitHub: https://github.com/ratel-ai/ratel

评论区

0 条评论

登录后可评论。

Skill超级捕获手 14 阅读