Ratel：按需工具/技能选择的上下文工程层

Ratel：按需工具/技能选择的上下文工程层

一句话结论

Ratel 把“工具太多导致上下文膨胀和工具选择错误”当成一个 Context-Engineering 问题：维护完整 tool/skill catalog，但每轮只向模型注入与当前任务相关的少量能力，并提供 searchCapabilities / invokeTool 这类中介工具，目标是在不依赖向量数据库的情况下减少 token 成本并缓解 tool overload。

为什么对用户重要

用户的 Hermes / llm-wiki 生态已经有大量 skills、wiki 页面、CLI、cron、raw sources 和外部工具。随着能力增加，风险不是“工具不够”，而是 agent 在每轮上下文中看到太多 schema、规则和候选路径，导致选择噪音、成本上升、甚至忽略真正关键的技能。Ratel 的价值不在于它一定要被直接采用，而在于它把工具/技能加载从静态 prompt stuffing 转成可检索、可评测、可裁剪的 runtime layer。

机制 / 一阶原理

Ratel 的基本机制是：

1. 把所有工具注册到 ToolCatalog；
2. 给 agent 暴露少数 meta-tools，例如“搜索可用能力”和“调用已选工具”；
3. 在每个 turn 根据任务语义检索/匹配相关工具，而不是把全部工具 schema 常驻上下文；
4. 用 benchmark 观察工具数量膨胀对准确率和 token 成本的影响。

一阶原理是：LLM 的注意力和工具选择能力是有限资源。工具 schema 本身也是上下文负载；当候选工具过多时，模型不仅付出 token 成本，还会出现 affordance confusion，把相似工具混淆、调用不必要工具或漏掉正确工具。

和现有 wiki 的关系

• 对 Context-Engineering：补充“tool context 也是上下文”的视角。上下文工程不只是文档、wiki、AGENTS.md，也包括工具/skill schema 的动态加载策略。
• 对 External-Agent-Skills-Design-Patterns：Ratel 支持把 skills 当成可索引 catalog，而不是一次性全部塞进 agent prompt。
• 对 Harness-Engineering：按需工具选择可作为 harness 的 capability router，但需要与权限 gate、审计日志和验证膜结合，否则只是降低 token，不一定提升安全性。

对 Hermes / llm-wiki 的可执行启发

1. Hermes skill 系统可以增加“能力索引页/manifest”：每个 skill 暴露触发条件、输入输出、风险等级、验证方式，而不是只靠长说明文本。
2. wiki-vquery 不只服务内容问答，也可用于“下一步该加载哪个 skill/页面/工具”的 capability retrieval。
3. 每日雷达可记录本次实际使用的能力集合：web search、arXiv、GitHub API、PDF extraction、read_file、patch/write 等，作为 context footprint 的度量。

失败模式 / 边界

• 检索式工具选择会引入 recall 风险：如果 catalog 描述不好或 query 太窄，正确工具可能根本没进上下文。
• 没有权限/side-effect gate 时，减少工具数不等于安全；被选中的工具仍可能越权。
• 对小型 agent 或工具很少的场景，Ratel 可能是额外复杂度；真正适合的是工具/skill catalog 已经明显膨胀的系统。

深度判断

晋升为正式 source 页的原因：它不是普通工具发布，而是给 Hermes 的 skill/context 加载策略提供了可复用设计模式：catalog + retrieval + invoke + benchmark。该思想能直接指导 llm-wiki 和 agent workflows 的上下文预算管理。

写入记录

• 2026-07-12 09:00 CST：新增 Ratel source 页，分析 tool overload、按需工具选择和对 Hermes skill/context 加载层的启发。