Y Combinator 的掌门人 Garry Tan 写了一篇很硬核的长文，聊他在构建个人 AI 智能体系统时踩过的坑，以及他从中提炼出的核心概念：Resolver（解析器）。

故事的起点很真实。Garry 的 CLAUDE.md 文件膨胀到了 20000 行，他把所有经验、模式、边界情况全塞了进去，想让模型变得无所不知。结果适得其反，模型的注意力退化了，响应变慢，准确度下降。Claude Code 甚至直接提醒他：你该精简了。当 AI 开始劝你少说话的时候，你就知道事情过头了。

他的解决方案是一个只有 200 行的文件，本质上是一棵决策树加一堆指针。遇到人物相关的内容，指向 /people/ 目录；遇到公司相关的，指向 /companies/；遇到政策分析，指向 /civic/。20000 行的知识依然存在，但模型只在需要的时候才去读取对应的部分，不再一股脑全塞进上下文窗口。效果立竿见影：响应更快，归档更准，幻觉更少。

真正让他意识到 Resolver 重要性的，是一次归档错误。他让智能体处理一篇关于 OpenAI 产业政策的深度分析文章，结果被归到了 sources/ 目录（存放原始数据的地方），而不是 civic/ 目录（存放政策分析的地方）。他一查，发现自己 13 个会写入知识库的技能里，只有 3 个在调用 Resolver，其他 10 个都是各自硬编码了默认路径。每个技能都在用自己的归档逻辑，每个都是一颗定时炸弹。

这种失败模式特别阴险。不是那种一眼就能看出来的错误，而是信息慢慢被放到了错的地方，知识之间的关联无法形成，知识库逐渐变成一个有 14700 个文件的垃圾抽屉。

修复方法也很优雅：写一个共享的归档规则文档，然后规定所有写入知识库的技能在创建任何页面之前，必须先读取 RESOLVER.md。一条规则，修复了十个技能。之后零归档错误。

Garry 还发现了另一个问题：技能存在但 Resolver 不知道它的存在。他们给智能体做了一个签名追踪系统，功能完美，但当用户问「检查我的签名」时，系统无动于衷，因为 Resolver 里没有对应的触发条件。这比没有这个功能还糟糕，因为你以为系统能做这件事，直到关键时刻才发现它做不到。

他后来做了一个叫 check-resolvable 的元技能，遍历整个链路检查哪些技能是「不可达」的。第一次跑就找出了 6 个，占总技能数的 15%。还有一个关键洞察：Resolver 会腐烂。第一天完美，第 30 天就有新技能没被注册，第 60 天触发描述和用户实际表达方式对不上，第 90 天 Resolver 就变成了一份历史文档。

最后 Garry 把 Resolver 上升到了一个更大的框架：构建 AI 智能体系统本质上就是在做管理。技能是员工，Resolver 是组织架构图，归档规则是内部流程，check-resolvable 是审计合规，触发评估是绩效考核。模型够聪明了，问题在于我们一直在建没有管理层的组织，一堆有才华的员工加上一个模糊的希望，指望他们自己协调。Resolver 就是那个缺失的管理层。

#科技先锋官##How I AI#