企业官网建设流程全解析

在生产级 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（分形）结构：

• 技能 Resolver（AGENTS.md）：用户查询 → 匹配技能文件。例如“检查我的签名” → executive-assistant 技能。
• 归档 Resolver（RESOLVER.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 万个文件的“杂物间”。表面功能齐全，实际检索和关联完全失效。

解决路径不是逐个修技能（打地鼠），而是：

1. 新建_brain-filing-rules.md记录所有常见误归档模式；
2. 强制所有写脑技能在创建页面前，先读 RESOLVER.md 和 filing-rules；
3. 每周跑一次check-resolvable元技能，扫描 unreachable skills（ unreachable 技能占比一度高达 15%）。

老方案 vs 新方案：生产级权衡矩阵

Resolver 的自我进化：从静态表格到自愈治理层

Resolver 不是一劳永逸。它会腐烂：新技能在半夜由子 Agent 建好却没注册、用户真实表述和 trigger description 逐渐脱节、优先级错位……

Garry Tan 正在探索的终极方案是用强化学习环（RL loop）让 Resolver 自我迭代：观察每一次任务分发 → 记录实际命中技能 → 夜间重写 trigger description 和优先级。这不是科幻，而是把“AutoDream”式的记忆整合机制，专门应用在路由层。

一旦 Resolver 实现自愈，整个 Agent 系统就从“堆技能”变成了“设计组织”：技能是员工，Resolver 是组织架构图，filing rules 是内部流程，check-resolvable 是合规审计，trigger evals 是绩效复盘。

这才是真正让人脊背发凉的洞察——我们以前以为在造工具，其实在无意中构建了一个需要管理层的“组织”。

在生产环境落地前你必须做的三件事

1. 立即创建 RESOLVER.md 和 _brain-filing-rules.md，把所有技能的触发描述和归档逻辑全部文档化；
2. 给每个写脑技能增加两行强制前置：先读 Resolver，再执行；
3. 每周定时跑 check-resolvable 元技能，把 unreachable capabilities 曝光在团队周会上。

当你把 Resolver 真正跑通的那一刻，你会发现：模型从来没变笨，是我们终于学会了“在正确时刻给它正确的书”。

AI Agent 的下一次进化，不再是把模型变更大，而是把治理层建得更聪明。Resolver 就是那个被严重低估、却决定系统能否长期存活的隐形基础设施。

基于 YC 总裁 Garry Tan 在 X 平台上的深度分享与 GBrain/GStack 开源实践，我把这些硬核模式重构为可直接落地的生产资产。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。