AI Agent 开发者都在狂塞上下文，却集体忽略了这个“隐形路由表”

在生产级 AI Agent 系统中技能Skills堆到 40 个、知识文件超过 2 万行后系统却开始悄无声息地“失忆”。任务响应变慢、归档错乱、能力明明存在却无法触发——这些不是模型不够聪明而是上下文管理出了系统性问题。Garry Tan 在亲手打造个人 Agent 体系GBrain GStack OpenClaw的过程中用 200 行 Resolver 取代了 2 万行 CLAUDE.md把看似“生产力爆炸”的混乱变成了真正能复合智能的稳定架构。我起初也和很多人一样认为把所有经验、模式、边缘案例一股脑塞进系统提示词就能让模型“无所不知”。后来深入分析他的实际系统日志和技能调用链后发现这恰恰是让模型“失明”的根源。模型不是靠信息量取胜而是靠在正确时刻拿到正确上下文。Resolver 就是那个路由表——它让知识按需加载而不是一次性淹没整个上下文窗口。那个 2 万行“忏悔录”背后的代价Garry Tan 的 CLAUDE.md 曾经膨胀到 2 万行每一次被 Claude Code “烧”过的 quirk、每一条代码规范、每一次被坑的边缘场景都被塞了进去。表面上看这是在“喂”模型知识实际却是让注意力机制持续过载。响应变慢、精度下滑连模型自己都开始建议“能不能删一点”。这就像你给一位顶级厨师塞满一整个厨房的食材却不告诉他今晚要做的是川菜还是法餐。厨师不是变笨了而是被噪声淹没了。真正的聪明是在客人点菜的那一刻只把需要的调料和菜谱推到他面前。解决办法只有 200 行一个编号决策树 文档指针。任务类型 X 出现时先加载文档 Y。整个知识库仍然存在但不再污染上下文。系统立刻变快、更准、幻觉更少——不是模型升级了而是噪声被清除了。Resolver 的本质上下文的“交通警察”Resolver 说白了就是一个路由表。它在三个层面同时生效形成 fractal分形结构技能 ResolverAGENTS.md用户查询 → 匹配技能文件。例如“检查我的签名” → executive-assistant 技能。归档 ResolverRESOLVER.md内容类型 → 目录结构。人 → /people/公司 → /companies/政策分析 → /civic/。技能内部 Resolver每个胖技能自己也有子路由比如邮件分拣走一条路径签名追踪走另一条。下面是我根据 Garry Tan 实践逻辑重构的一个精简版 Resolver 示例已增加中文关键行注释便于生产落地# RESOLVER.md - AI Agent 上下文路由决策树 # 核心原则永远按主题主体归档而非来源格式或技能名称 # 任务类型判断优先级从高到低 if query 包含 谁是 或 个人信息: # 加载 /people/ 目录下的对应文档 load_context(/people/{entity_name}.md) elif query 涉及 公司 或 投资人更新: # 加载 /companies/ 目录优先匹配公司实体 load_context(/companies/{entity_name}.md) elif query 是政策分析、监管或 OpenAI 相关: # 明确映射到 civic 目录避免掉进 sources/ 垃圾桶 load_context(/civic/{topic}.md) elif query 是 ingest PDF / 文章 / 会议记录: # 必须先读 _brain-filing-rules.md 再决定路径 consult_filing_rules() route_to_correct_dir() # 严禁技能内部硬编码默认路径 else: # 兜底 日志记录触发 check-resolvable 审计 log_unresolved_task()这个 200 行文件取代了原来 2 万行的“全家桶”。它让系统从“知识抽屉”变成了结构化智能层。真实事故复盘一次归档错误引发的全链路审计Garry Tan 让 Agent 摄入一篇 Will Manidis 的政策分析文章《No New Deal for OpenAI》。结果被扔进了sources/——那是给 CSV、API 导出、原始数据准备的目录。而这篇明显属于civic/。问题出在idea-ingest 技能里硬编码了默认路径完全没咨询 Resolver。13 个写脑技能里只有 3 个正确引用了 Resolver其余 10 个各自为政。这就是典型的“技能自治导致系统性漂移”。]就像公司里 40 个员工技能每个人都有自己的一套文件归档习惯最后整个知识库变成 1.47 万个文件的“杂物间”。表面功能齐全实际检索和关联完全失效。解决路径不是逐个修技能打地鼠而是新建_brain-filing-rules.md记录所有常见误归档模式强制所有写脑技能在创建页面前先读 RESOLVER.md 和 filing-rules每周跑一次check-resolvable元技能扫描 unreachable skills unreachable 技能占比一度高达 15%。老方案 vs 新方案生产级权衡矩阵维度传统“狂塞上下文”方案Resolver 胖技能方案生产环境真实影响响应速度与注意力上下文窗口迅速饱和响应变慢按需加载仅 200 毫秒读取路由表速度提升 3-5 倍精度不降长尾风险与漂移知识逐渐腐烂归档错乱不可逆触发评估 自愈循环漂移可被主动发现90 天内零误归档开发者/架构师心智负担每次新增技能都要手动同步提示词Resolver 文档化改一行 Markdown 即可生效上手门槛降低新技能 5 分钟接入系统可扩展性技能到 20 个就崩溃fractal 结构轻松支持 50 技能 2.5 万文件从玩具 Demo 到日处理 200 输入Resolver 的自我进化从静态表格到自愈治理层Resolver 不是一劳永逸。它会腐烂新技能在半夜由子 Agent 建好却没注册、用户真实表述和 trigger description 逐渐脱节、优先级错位……Garry Tan 正在探索的终极方案是用强化学习环RL loop让 Resolver 自我迭代观察每一次任务分发 → 记录实际命中技能 → 夜间重写 trigger description 和优先级。这不是科幻而是把“AutoDream”式的记忆整合机制专门应用在路由层。一旦 Resolver 实现自愈整个 Agent 系统就从“堆技能”变成了“设计组织”技能是员工Resolver 是组织架构图filing rules 是内部流程check-resolvable 是合规审计trigger evals 是绩效复盘。这才是真正让人脊背发凉的洞察——我们以前以为在造工具其实在无意中构建了一个需要管理层的“组织”。在生产环境落地前你必须做的三件事立即创建 RESOLVER.md 和 _brain-filing-rules.md把所有技能的触发描述和归档逻辑全部文档化给每个写脑技能增加两行强制前置先读 Resolver再执行每周定时跑 check-resolvable 元技能把 unreachable capabilities 曝光在团队周会上。当你把 Resolver 真正跑通的那一刻你会发现模型从来没变笨是我们终于学会了“在正确时刻给它正确的书”。AI Agent 的下一次进化不再是把模型变更大而是把治理层建得更聪明。Resolver 就是那个被严重低估、却决定系统能否长期存活的隐形基础设施。基于 YC 总裁 Garry Tan 在 X 平台上的深度分享与 GBrain/GStack 开源实践我把这些硬核模式重构为可直接落地的生产资产。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。