AAperture
Back/harness engineering

Resolvers — 智能体的路由表

Updated 2026-04-19
2 min read
336 words

Resolvers — 智能体的路由表

Garry Tan 提出的核心架构模式：Resolver 是上下文的路由表。当任务类型 X 出现时，先加载文档 Y。一句话，但决定了 agent 是复合智能还是缓慢遗忘。

20,000 行的忏悔

Garry 的 CLAUDE.md 曾经 20,000 行。每个 quirk、模式、教训、代码规范、边缘案例都塞进去。感觉在让模型更聪明，实际上在淹没它。

模型注意力退化，响应变慢变不精确。Claude Code 直接告诉他：cut it back。

修复方案：200 行的编号决策树，指向文档：

  • 是人？→ /people/ 目录
  • 是公司？→ /companies/ 目录
  • 是政策分析？→ /civic/ 目录

20,000 行知识，按需访问，不污染上下文窗口。

一次 misfiling 揭露一切

Will Manidis 的 "No New Deal for OpenAI"（政策分析）被 agent 归档到 sources/（raw data dumps）。正确位置是 civic/（政策分析）。

原因：idea-ingest skill 硬编码了 brain/sources/ 作为默认目录，没有咨询 resolver。

审计结果：13 个写入 brain 的 skills 中，只有 3 个引用 resolver。其他 10 个有硬编码路径。

修复：创建 _brain-filing-rules.md，强制每个 brain-writing skill 在创建页面前读取 RESOLVER.md 和 _brain-filing-rules.md。

隐形 Skill 问题

Resolver 将任务路由到 skills。但如果 skill 存在而 resolver 不知道？

OpenClaw 的签名追踪系统完美运行，但 resolver 没有 "signatures" 触发器。skill 存在，能力存在，系统无法到达。这比没有 skill 更糟 —— 创造了能力的幻觉。

Resolver trigger evals：50 个样本输入 + 期望输出的测试套件。

  • False negative：skill 应该触发但没有（触发描述错误或缺失）
  • False positive：错误的 skill 触发（两个触发器重叠）
  • 两者都可通过编辑 markdown 修复，无需改代码

Meta-Skill：check-resolvable

检查 AGENTS.md → skill file → code 的完整链路，发现死链接。

第一次运行发现 6 个不可达 skills（15% 的系统能力是 dark 的）：

  • 航班追踪器（无法通过询问航班触发）
  • 内容创意生成器（只能 cron 运行，不能手动触发）
  • 引用修复器（存在于 skills 目录但 resolver 中未列出）

修复：只需在 AGENTS.md 中添加触发器。现在 check-resolvable 每周运行 —— resolver 的 linter。

Context Rot

Resolver 会腐烂：

  • Day 1：完美
  • Day 30：3 个新 skills 没人加到 resolver（子 agent 凌晨 3 点创建的）
  • Day 60：2 个触发描述不匹配用户实际表述
  • Day 90：resolver 成为历史文档，记录系统"曾经能做什么"而非"现在能做什么"

RLM 自修复 idea：强化学习循环观察每次任务分发，周期性地基于观察证据重写 resolver。

Resolvers 是分形的

Resolver 存在于系统的每一层：

层级 位置 功能
Skill resolver AGENTS.md 任务类型 → skill 文件
Filing resolver RESOLVER.md 内容类型 → 目录
Context resolver 每个 skill 内部 子路由：邮件分类、日程安排、签名追踪

Claude Code 的 skill description 字段本身就是 resolver —— 模型将用户意图匹配到 skill 描述。

Resolver 即管理

40+ skills 和 25,000 文件的系统不是代码，是组织：

  • Skills = 员工（专家、通才、cron 专用、用户面向）
  • Resolver = 组织架构图（谁处理什么、如何路由、升级逻辑）
  • Filing rules = 内部流程（信息存在哪里、如何记录决策）
  • check-resolvable = 审计与合规（系统声称能做的，真的能做到吗？）
  • Trigger evals = 绩效评估（给定真实输入，正确部分响应了吗？）

问题不是模型不够聪明。问题是我们一直在构建没有管理层的组织。只是一堆有才华的员工和模糊的希望他们能协调。

Counterpoints & Gaps

  • Resolver 维护开销随 skill 数量超线性增长，40+ skills 已需 weekly audit
  • RLM 自修复仍处概念阶段，未验证实际效果
  • Garry 的 200 行 resolver 针对个人知识管理优化，企业场景可能需要更复杂的路由逻辑

Sources

Linked from