Garry Tan 在 Harness Design 那篇文章里提出了 5 个构建实用 Agent 系统的定义。Skills 获得了所有关注，但有一个被严重忽视的概念，才是真正的核心：Resolvers。

而且它被忽视的原因，和它之所以重要是同一个：它正常工作的时候完全看不见，一旦出问题就是灾难性的。

Resolver 是什么

一句话：Resolver 是上下文世界的路由表。

当任务类型 X 出现时，加载文档 Y。就这一句话。

这一个问题句，是"会积累智能的 Agent"和"慢慢遗忘自己知道什么的 Agent"之间的全部差别。

20,000 行教训

Garry 的 CLAUDE.md 曾经有 20,000 行。每一个 quirks、每一种代码规范、每一个踩过的坑、所有约定、所有边界情况。他不断往里加，文件不断膨胀。感觉自己在让模型变聪明。

实际上他在让模型溺水。

模型注意力退化，响应变慢、精度下降。Claude Code 直接告诉他：删掉一部分吧。——AI 叫你少说话的时候，就知道你已经加得太多了。

直觉告诉你要让模型什么都知道，所以把所有东西都塞进系统提示词、塞进指令文件、塞进上下文窗口。你在试图通过接近来让模型变得全知。这不奏效。你不能通过更大声地喊叫来让一个人变聪明。让他变聪明的方式是：在正确的时刻给他正确的书。

修复方案约 200 行。一个编号决策树，加上文档指针。当模型需要归档东西时，它走这个树：

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

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

一次归错档案暴露的真相

让 Agent 摄入 Will Manidis 的政策分析文章《No New Deal for OpenAI》——一篇分析 OpenAI 监管战略的尖锐文章。Agent 把它归到了 sources/。错。sources/ 是放原始数据和批量导入的：CSV、API 导出、抓取的数据集。这是政策分析，应该放在 civic/。

为什么会发生？idea-ingest 技能把 brain/sources/ 硬编码为默认目录。它不查 resolver。它有自己的半吊子归档逻辑。每个技能都有自己内部的归档假设。

当 Garry 审计所有向 brain 写文件的技能时——共 13 个——发现只有 3 个引用了 resolver。剩下 10 个全是硬编码路径。

这就是杀死 Agent 系统的方式。不是戏剧性失败。是缓慢、沉默的漂移：信息去了错误的地方，连接无法形成，知识库慢慢变成了一个塞了 14,700 个文件的杂物抽屉，而不是一个结构化的智能层。

修复方案不是逐个修 10 个技能——那是打地鼠。修一个，另一个又漂移了。修复方案是：一份共享的归档规则文档 + 一条强制令：每个向 brain 写文件的技能，在创建任何页面之前必须先读 RESOLVER.md。

技能存在但路由不知道

Garry 的团队在 executive assistant 技能里做了一个签名追踪系统。运行完美，完全不可见——当有人问"查我的签名"或"我需要签什么"时，系统耸耸肩。Resolver 没有签名这个触发器。技能存在。能力存在。系统找不到它。

这比没有这个技能更糟糕。没有技能是诚实的——系统说"我做不到"，你知道要去建一个。技能存在但不可达——创造的是能力的假象。你以为系统会处理签名。它不会。而且你只在关键时刻才发现。

一个月内建了 40+ 个技能。有些是为响应特定事件建的，有些是 sub-agent 在跑 cron 时生的。没人维护 resolver 表。技能在出生，但没有登记。系统拥有的能力，它自己都不知道。

于是 Garry 建了 resolver trigger evals：一套 50 个样本输入的测试套件，每个都有预期输出。

输入："check my signatures" → 预期：executive-assistant
输入："who is Pedro Franceschi" → 预期：brain-ops → gbrain search
输入："save this article to brain" → 预期：idea-ingest + RESOLVER.md

两种失败模式：假阴性（应该触发但没有）和假阳性（触发了错误的技能）。两者都可以通过编辑 markdown 修复，不需要改代码。Resolver 是一个文档，文档修起来便宜。

然后是 check-resolvable——一个元技能，走整条链路（AGENTS.md → skill 文件 → 代码），找出死链接。第一次运行发现了 6 个不可达的技能。15% 的系统能力是暗的。一小时后修复完，只需要在 AGENTS.md 加触发器。

Resolver 会衰减

第 1 天，路由表是完美的。第 30 天，3 个新技能没人加进 resolver。第 60 天，触发器描述和用户实际措辞不匹配——技能处理"track this flight"，用户说"is my flight delayed?"。第 90 天，resolver 变成了一份历史文档，是系统曾经能做什么的遗迹，不是现在能做什么。

终局思路：强化学习循环。系统观察每一次任务分发——哪个技能触发了，哪个没触发，哪些任务没有匹配，哪些任务匹配错了——然后周期性基于观察到的证据重写 resolver。一个会从自己的流量中学习的路由表。

Resolver 在每一层都存在

不只是顶层的技能路由。

技能 resolver（AGENTS.md）：任务类型 → 技能文件
归档 resolver（RESOLVER.md）：内容类型 → 目录
上下文 resolver（每个技能内部）：技能内部的子路由

Claude Code 已经有了这个模式——每个技能都有描述字段，模型自动匹配用户意图和技能描述。你不需要记住 /ship 存在。描述本身就是 resolver。层层叠加的 resolver。

本质是管理层

Garry 说他实际构建的东西更接近管理学。

Agent 组件对应管理概念
技能员工
Resolver组织架构图
归档规则内部流程
check-resolvable审计合规
Trigger evals绩效考核

问题从来不是模型不够聪明。问题是我们一直在建没有管理层的组织。只有一群有能力的员工和一丝模糊的希望，希望他们能协调。

Garry 开源了他的方案：

  • GBrain：个人知识库，内置 resolver 模式。gbrain init 创建 RESOLVER.md 和决策树，从第一天起就正确归档。
  • GStack：Markdown 格式的 fat skills，GitHub 72,000+ stars。
  • OpenClaw/Hermes Agent：薄 harness，运行 Agent 循环、管理 session、执行 cron。

架构可以写在一张索引卡片上，知识存在 git repo 里。

这不是 SaaS 产品。这是一套架构。源码开放，技能是 Markdown，知识库是你自己拥有的 git 仓库。