解析器：智能体的路由表

Garry Tan 2026-04-16 18.4 KB 335.7K 1.3K 𝕏 文章列表

本文探讨了构建高效 Agent 系统中的关键组件“Resolver”（解析器）。作者指出，与将所有知识塞入系统提示词导致性能下降不同，Resolver 作为一个上下文路由表，能根据任务类型动态加载相关文档。文章通过纠正文件分类错误的实例，展示了如何利用 Resolver 管理技能调用，解决“技能不可见”问题，并通过评估测试确保路由的准确性，从而实现智能体的持续记忆与有效检索。

# Resolvers: The Routing Table for Intelligence **作者**: Garry Tan **日期**: 2026-04-15T18:14:34.000Z **来源**: [https://x.com/garrytan/status/2044479509874020852](https://x.com/garrytan/status/2044479509874020852) --- ![Image](/doc/574/image/img_e2a76a6d31b9.jpg) In "Thin Harness, Fat Skills", I introduced five definitions for building agent systems that actually work. Skills got all the attention. People bookmarked the skill-as-method-call pattern, the diarization concept, the thin harness architecture. Good. Those matter. But the one that got almost no attention is the one that matters most. Resolvers. And the reason they got ignored is the same reason they're so important: they're invisible when they work, and catastrophic when they don't. A resolver is a routing table for context. When task type X appears, load document Y first. That's it. One sentence. But that one sentence is the difference between an agent that compounds intelligence and an agent that slowly forgets what it knows. This is the story of how I learned that the hard way. ## The 20,000-line confession My CLAUDE.md was 20,000 lines. I'm not proud of this. Every quirk, every pattern, every lesson I'd ever encountered with Claude Code, every convention for my codebase, every edge case I'd been burned by. I kept adding. The file kept growing. It felt productive. It felt like I was making the model smarter. I wasn't. I was drowning it. The model's attention degraded. Responses got slower and less precise. Claude Code literally told me to cut it back. That's when you know you've gone too far — the AI is telling you to stop talking. The instinct is natural. You want the model to know everything. So you cram everything into the system prompt, the instructions file, the context window. You're trying to make the model omniscient by proximity. It doesn't work. You can't make someone smarter by shouting louder. You make them smarter by giving them the right book at the right moment. The fix was about 200 lines. A numbered decision tree. Pointers to documents. When the model needs to file something, it walks the tree: - Is it a person? → /people/ directory - A company? → /companies/ directory - A policy analysis? → /civic/ directory Twenty thousand lines of knowledge, accessible on demand, without polluting the context window. That 200-line file is the resolver. It replaced 20,000 lines of instructions. And the system immediately got better — faster responses, more accurate filing, fewer hallucinations. Not because the model got smarter. Because I stopped blinding it with noise. The misfiling that revealed everything I asked my agent to ingest Will Manidis's essay "No New Deal for OpenAI" — a devastating policy analysis of OpenAI's industrial policy brief. It's the kind of piece that breaks down a company's regulatory strategy, maps the political implications, names the institutional actors. Sharp civic analysis. The agent filed it in `sources/`. Wrong. `sources/` is for raw data dumps and bulk imports. CSV files. API exports. Scraped datasets. This was political analysis — it belongs in `civic/`, where policy pieces, political actors, and institutional dynamics live. Why did it happen? The idea-ingest skill had hardcoded `brain/sources/` as the default directory. It didn't consult the resolver. It had its own half-assed filing logic baked into the skill itself. When no explicit path was given, it fell back to `sources/` the way a lazy intern throws everything in the "misc" folder. One misfiled article. I could have fixed it and moved on. Instead I pulled the thread. ## The audit When I caught the Manidis misfiling, I audited every skill that writes to the brain. I have 13 of them. Skills for ingesting articles, PDFs, meeting transcripts, videos, investor updates, voice notes, tweets. Each one writes pages to the brain repo. Only 3 out of 13 referenced the resolver. The other 10 had hardcoded paths. Idea-ingest defaulted to `sources/`. PDF-ingest defaulted to `originals/`. Meeting-ingest wrote to `meetings/`. Each skill had internalized its own filing assumptions. Each one was a potential misfiling waiting to happen. This is the pattern that kills agent systems. Not a dramatic failure. Not a hallucination that produces nonsense. A slow, silent drift where information goes to the wrong place, connections don't form, and the knowledge base gradually becomes a junk drawer with 14,700 files in it instead of a structured intelligence layer. The fix wasn't fixing 10 skills individually. That's whack-a-mole. You fix one, another drifts. The fix was a shared filing rules document — `_brain-filing-rules.md` — and a mandate that every brain-writing skill reads `RESOLVER.md` before creating any page. One rule. Ten skills fixed. The filing rules doc also catalogs common misfiling patterns. Sources vs. originals. People vs. companies (when someone IS a company). Civic vs. sources (the Manidis case). Every mistake, documented, so the same mistake can't happen a different way. Zero misfilings since. Every new skill that writes to the brain now has a two-line mandate at the top: *Before creating any new brain page, read `brain/RESOLVER.md` and `skills/_brain-filing-rules.md`. File by primary subject, not by source format or skill name.* ## The invisible skill problem The above example talks about where to put files in your memory repo, but it applies to skill files (fat skills) and code to call (fat code) as well. A resolver routes tasks to skills. But what happens when a skill exists and the resolver doesn't know about it? For my OpenClaw, we built a signature-tracking system inside the executive assistant skill. It worked perfectly. Tracked DocuSign deadlines, surfaced unsigned documents, drafted reminders. Beautiful piece of engineering. Completely invisible. When someone asked "check my signatures" or "what do I need to sign," the system shrugged. The resolver didn't have a trigger for signatures. The skill existed. The capability existed. The system couldn't reach it. It's like having a surgeon on staff but not listing them in the hospital directory. This is worse than not having the skill at all. A missing skill is honest — the system says "I can't do that" and you know to build it. A skill that exists but isn't reachable creates the illusion of capability. You think the system handles signatures. It doesn't. And you don't find out until the moment it matters. After a month of building, we had 40+ skills. Some created in response to specific incidents, others spawned by sub-agents running crons. Nobody was maintaining the resolver table. Skills were being born but not registered. The system had capabilities it didn't know it had. So I built resolver trigger evals. A test suite of 50 sample inputs with expected outputs: > Input: "check my signatures" > Expected: executive-assistant (signature section) > Input: "who is Pedro Franceschi" > Expected: brain-ops → gbrain search > Input: "save this article to brain" > Expected: idea-ingest + RESOLVER.md Two failure modes. False negative: skill should fire but doesn't, because the trigger description is wrong or missing. False positive: wrong skill fires, because two triggers overlap. Both fixable by editing markdown. No code changes. The resolver is a document, and documents are cheap to fix. I told my Claw: "Make sure the resolver is tested and also there are proper eval LLM tests for all the prompts and skills that use the resolver." This isn't optional. If you can't prove the right skill fires for the right input, you don't have a system. You have a collection of skills and a prayer. ## The meta-skill The trigger evals catch routing failures. But there's a deeper problem: skills that exist but have no path from the resolver at all. Not a wrong path — no path. I was debugging a skill that should have fired and didn't. The usual drill: check the trigger description, check the resolver table, trace the chain. And I realized there was no systematic way to verify that a skill was reachable. You could check one skill at a time. You couldn't check all of them. So I invented `check-resolvable`. A meta-skill that walks the entire chain — AGENTS.md → skill file → code — and finds dead links. I told my agent: "Check if there is a direct line between the agents.md resolver all the way to this running. And then remember this as a 'check-resolvable' skill. The skill should actually check if this skill or codepath is either directly called out in the resolver or callable via something in the resolver. And if it isn't, figure out what resolvable skill should call it." First run found 6 unreachable skills. Six capabilities the system had built but couldn't access. A flight tracker that nobody could invoke by asking about flights. A content-ideas generator that only ran on cron but couldn't be triggered manually. A citation fixer that existed in the skills directory but wasn't listed in the resolver at all. Six. Out of 40+. Fifteen percent of the system's capabilities were dark. Fixed in an hour. Just added triggers to AGENTS.md. Now check-resolvable runs weekly. It's the resolver equivalent of a linter — it tells you what's broken before a user discovers it the hard way. ## Context rot Here's the thing nobody tells you about resolvers: they decay. Day 1, the routing table is perfect. Every skill is registered. Every trigger is accurate. Every path resolves. You feel like a genius. Day 30, three new skills exist that nobody added to the resolver. They were built in response to real needs, by sub-agents running at 3 AM, and nobody updated the table. Day 60, two trigger descriptions don't match how users actually phrase things. The skill handles "track this flight" but users say "is my flight delayed?" The description says one thing. The user says another. The skill doesn't fire. Day 90, the resolver is a historical document. An artifact of what the system *used to* be able to do. Not what it can do now. I noticed the system was drifting. Skills were being invoked by direct instruction — "read skills/flight-tracker/SKILL.md" — instead of through the resolver, because the resolver didn't have the right triggers. The system worked because I knew which skill to call. That's not a system. That's a person with a filing cabinet. Yesterday, in office hours with a YC company, a CTO asked me: "Could an RLM be used to solve context rot particularly around resolvers?" The idea: a reinforcement learning loop where the system observes every task dispatch. Which skill fired. Which didn't. Which tasks had no match. Which tasks matched the wrong skill. And periodically — maybe nightly, maybe weekly — it rewrites the resolver based on observed evidence. Not a human maintaining a table. The table maintaining itself. Eight hundred task dispatches over a month. The system sees that "is my flight on time" never triggers flight-tracker but "check my flight" does. It rewrites the trigger description. The system sees that pdf-ingest fires for investor update emails, but investor-update-ingest should have caught them first. It adjusts priority. This is forward-looking. We haven't fully built it. Claude Code's AutoDream system — memory consolidation during idle time — is a primitive version. It reviews accumulated context and compresses it. Apply that principle to the resolver specifically, and you get a routing table that improves with use. A resolver that learns from its own traffic. That's the endgame for agent governance. ## Resolvers are fractal One more principle, and it's the one that makes everything click. Resolvers compose. They exist at every layer of the system, not just the top. The skill resolver lives in AGENTS.md. It maps task types to skill files. "Who is this person?" → brain-ops. "Ingest this PDF" → pdf-ingest. "Check my calendar" → google-calendar. This is the one everyone thinks of. The filing resolver lives in RESOLVER.md. It maps content types to directories. Person → `people/`. Company → `companies/`. Policy analysis → `civic/`. This is the one that caught the Manidis misfiling. The context resolver lives inside each skill. When the executive assistant skill fires, it has its own internal routing: email triage goes one way, scheduling goes another, signature tracking goes a third. Sub-routing within the skill. Claude Code already has this pattern. Every skill has a description field. The model matches user intent to skill descriptions automatically. You never have to remember that `/ship` exists. The description *is* the resolver. It's resolvers all the way down. The same architecture, at every layer. That's what makes it scale from 5 skills to 50, from 1,000 files to 25,000, from a toy demo to a production system that processes 200 inputs a day. ## The shape of the thing Let me pull this together. A resolver is 200 lines of markdown that replaced 20,000 lines of crammed context. When it's missing, skills invent their own filing logic and everything slowly degrades. When it's present but untested, capabilities go dark — you have a surgeon the hospital can't find. When it's tested but static, it rots within 90 days. When it's tested and self-healing, the system compounds. The pattern: - Load the right context at the right moment. Don't cram. - Mandate that every skill consults the resolver. Don't trust individual filing logic. - Test the routing, not just the output. Trigger evals. - Audit reachability. Check-resolvable. Weekly. - Make the resolver learn from its own traffic. The endgame. The resolver is the governance layer of an agent system. The traffic cop, the filing clerk, the org chart, and the institutional memory, all in one document that a model can read in 200 milliseconds. Almost nobody is building them explicitly. Everyone is cramming 20,000 lines into the system prompt and wondering why the model seems dumber than it should be. The model isn't dumb. It's drowning. Give it a routing table and watch what happens. ## The thing I didn’t realize I was building Up to this point, I’ve been describing resolvers as a technical pattern. A way to make agents work better. Route tasks. Load the right context. Avoid drowning the model. That framing is true. It’s also too small. What I actually built is closer to management. Think about what’s happening in a real system with 40+ skills and 25,000 files. You don’t just have code. You have an organization. Skills are employees. Each one has a capability. Some are specialists. Some are generalists. Some only run on cron. Some are user-facing. The resolver is the org chart. It defines who handles what, how tasks get routed, and what happens when something doesn’t match. It’s also escalation logic — when one path fails, where does it go next? The filing rules are internal process. Where information lives. How decisions get recorded. What counts as a “person” vs a “company” vs a “policy analysis.” Without that, you don’t have a knowledge base. You have a junk drawer. check-resolvable is audit and compliance. It doesn’t care if the code is beautiful. It asks a simpler question: can the system actually do what it claims? Are there capabilities that exist but can’t be reached? Trigger evals are performance reviews. Given a real input, does the right part of the organization respond? If not, you don’t retrain the model. You fix the description. You update the routing. You make the org legible. Once you see it this way, a lot of the confusion around agents disappears. The problem isn’t that models aren’t smart enough. The problem is that we’ve been building organizations with no management layer. Just a pile of talented employees and a vague hope they’ll coordinate. Resolvers are that missing layer. And once you treat them that way, the goal changes. You’re not just wiring up tools. You’re designing an organization that can grow, adapt, and stay coherent over time. That’s a different problem. And a much bigger one. ## I want you to build your own brain Everything in this article — the resolver pattern, the trigger evals, check-resolvable, the filing rules, the self-healing loop — runs in production, every day, on my personal agent. It processes 200 inputs daily. It has 25,000 files. It compounds. I open-sourced the entire system. My open source project GBrain ships with the resolver pattern built in. `gbrain init` creates RESOLVER.md, the decision tree, and the disambiguation rules. Your agent starts filing correctly from day one. The check-resolvable skill comes built-in. You don't have to discover these patterns by breaking things — the system embodies them. GStack is the coding layer. Fat skills in markdown. 72,000+ stars on GitHub. The skills in GStack call the knowledge in GBrain. Together they're the full architecture: intelligence on tap. OpenClaw or Hermes Agent is the conductor — the thin harness that runs the agent loop, manages sessions, and executes crons. GBrain and GStack are skills that plug into it. Your agent reads GBrain's compiled truth before answering. Your crons run the rollup pipelines while you sleep. This isn't a SaaS product. It's an architecture. The source code is open. The skills are markdown. The brain is a git repo you own. If any piece disappeared tomorrow, your knowledge survives as plain text files. This is the new dawn of personal software. This is not packaged software. This is software that you build for yourself, but with the fat skills and fat code and thin harness that is your own personal mini-AGI. The future is already here, and I want you to have it in your pocket. The architecture fits on an index card. The knowledge fits in a git repo. The only thing missing is you starting. -- GBrain to build your personal mini-AGI in OpenClaw or Hermes Agent github.com/garrytan/gbrain GStack to help you build faster in Claude Code github.com/garrytan/gstack ## 相关链接 - [Garry Tan](https://x.com/garrytan) - [@garrytan](https://x.com/garrytan) - [71K](https://x.com/garrytan/status/2044479509874020852/analytics) - [Thin Harness, Fat Skills](https://x.com/garrytan/status/2042925773300908103) - [github.com/garrytan/gbrain](https://github.com/garrytan/gbrain) - [github.com/garrytan/gstack](https://github.com/garrytan/gstack) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [2:14 AM · Apr 16, 2026](https://x.com/garrytan/status/2044479509874020852) - [71.3K Views](https://x.com/garrytan/status/2044479509874020852/analytics) - [View quotes](https://x.com/garrytan/status/2044479509874020852/quotes) --- *导出时间: 2026/4/16 10:12:37* --- ## 中文翻译 # 解析器：智能的路由表 **作者**: Garry Tan **日期**: 2026-04-15T18:14:34.000Z **来源**: [https://x.com/garrytan/status/2044479509874020852](https://x.com/garrytan/status/2044479509874020852) --- ![Image](/doc/574/image/img_e2a76a6d31b9.jpg) 在《细瘦线束，丰满技能》一文中，我介绍了构建真正行之有效的代理系统的五个定义。技能（Skills）获得了所有的关注。人们收藏了“技能即方法调用”模式、日记化概念以及细瘦线束架构。很好。这些确实很重要。但几乎没人注意的是那个最重要的定义。解析器。它们被忽视的原因恰恰就是它们如此重要的原因：当它们正常工作时，它们是隐形的；而当它们失效时，后果是灾难性的。解析器就是针对上下文的路由表。当任务类型 X 出现时，首先加载文档 Y。就这么简单。一句话。但这一句话决定了代理是能复利式地增长智能，还是会缓慢地遗忘它所知道的知识。这就是我惨痛吸取教训的故事。 ## 2万行的自白我的 CLAUDE.md 文件有 2 万行。我并不为此感到自豪。每一个怪癖、每一个模式、我在使用 Claude Code 时遇到的每一个教训、我代码库的每一个约定、以及每一个让我吃过亏的边缘情况。我不断地往里加。文件不断变大。感觉很有生产力。感觉像是我在让模型变得更聪明。其实不然。我是在淹没它。模型的注意力下降了。响应变得更慢且更不精确。Claude Code 直接地让我缩减文件。那是你知道你做过头了的时刻——AI 叫你闭嘴。这种本能是自然的。你希望模型知道一切。所以你把一切塞进系统提示词、指令文件和上下文窗口。你试图通过接近性让模型变得全知。这行不通。你不能通过更大声的喊叫来让人变聪明。你是在通过在正确的时刻给他们正确的书来让他们变聪明。解决方案大约是 200 行。一个编号的决策树。指向文档的指针。当模型需要归档某样东西时，它会沿着树走： - 是一个人？ → /people/ 目录 - 是一家公司？ → /companies/ 目录 - 是政策分析？ → /civic/ 目录两万行的知识，按需访问，且不污染上下文窗口。那个 200 行的文件就是解析器。它取代了 2 万行的指令。系统立刻变得更好了——响应更快，归档更准确，幻觉更少。不是因为模型变聪明了。而是因为我不再用噪音蒙住它的双眼。那个揭示一切的误归档我让我的代理摄取 Will Manidis 的文章《OpenAI 没有新政》——这是一篇对 OpenAI 产业政策简报的毁灭性政策分析。这是那种拆解一家公司监管战略、描绘政治影响、点出机构参与者的文章。犀利的社会分析。代理把它归档到了 `sources/`。错了。`sources/` 是用来存放原始数据转储和批量导入的。CSV 文件。API 导出。抓取的数据集。这是政治分析——它属于 `civic/`，那是政策文章、政治参与者和机构动态存放的地方。为什么会发生这种情况？点子摄取技能将 `brain/sources/` 硬编码为默认目录。它没有查阅解析器。它自己在技能内部内置了半吊子的归档逻辑。当没有给出明确路径时，它默认回退到 `sources/`，就像一个懒惰的实习生把所有东西都扔进“杂项”文件夹一样。一篇误归档的文章。我本来可以修好它然后继续。但我却顺藤摸瓜。 ## 审计当我发现 Manidis 的误归档时，我审计了每一个向大脑写入的技能。我有 13 个这样的技能。用于摄取文章、PDF、会议记录、视频、投资者更新、语音备忘录、推文的技能。每一个都会向代码仓库写入页面。 13 个里面只有 3 个引用了解析器。另外 10 个都有硬编码路径。点子摄取默认到 `sources/`。PDF 摄取默认到 `originals/`。会议记录写到 `meetings/`。每个技能都将自己的归档假设内在化了。每一个都是潜在的误归档，随时可能发生。这就是扼杀代理系统的模式。不是某种戏剧性的故障。也不是产生胡说八道的幻觉。而是一种缓慢、无声的漂移，信息去了错误的地方，连接没有形成，知识库逐渐变成了一个塞满 14,700 个文件的杂物抽屉，而不是一个结构化的智能层。解决办法不是一个个修复这 10 个技能。那是打地鼠游戏。你修好一个，另一个又漂移了。解决办法是一个共享的归档规则文档——`_brain-filing-rules.md`——以及一条强制规定，每个向大脑写入的技能在创建任何页面之前必须先阅读 `RESOLVER.md`。一条规则。修复十个技能。归档规则文档还记录了常见的误归档模式。Sources 与 Originals。People 与 Companies（当某人*就是*一家公司时）。Civic 与 Sources（Manidis 案例）。每一个错误都被记录下来，这样同样的错误就不会以另一种方式再次发生。从那以后零误归档。现在每个新的向大脑写入的技能在顶部都有两行强制命令：*在创建任何新的大脑页面之前，阅读 `brain/RESOLVER.md` 和 `skills/_brain-filing-rules.md`。按主要主题归档，而不是按来源格式或技能名称。* ## 隐形技能问题上面的例子谈论的是把文件放在你的记忆仓库的什么地方，但它同样适用于技能文件（丰满技能）和要调用的代码（丰满代码）。解析器将任务路由到技能。但是，当一个技能存在而解析器却不知道它时，会发生什么？对于我的 OpenClaw，我们在行政助理技能内部构建了一个签名追踪系统。它运行得很完美。追踪 DocuSign 截止日期，显示未签署的文件，起草提醒。工程杰作。完全隐形。当有人问“检查我的签名”或“我需要签什么”时，系统无动于衷。解析器没有针对签名的触发器。技能存在。能力存在。系统无法触达它。这就像你有一位外科医生在职，但并没有把他列在医院的名录里。这比根本没有技能还要糟糕。缺失的技能是诚实的——系统会说“我做不了这个”，你就知道需要去构建它。一个存在但无法触达的技能制造了具备能力的假象。你以为系统处理签名。其实不然。而且你直到关键时刻才会发现。经过一个月的构建，我们有了 40 多个技能。有些是为了应对特定事件而创建的，另一些则是由在定时任务中运行的子代理生成的。没有人维护解析器表。技能诞生了，但没有注册。系统拥有它不知道自己拥有的能力。所以我构建了解析器触发器评估。一个包含 50 个样本输入和预期输出的测试套件： > 输入：“检查我的签名” > 预期：executive-assistant（签名部分） > 输入：“Pedro Franceschi 是谁” > 预期：brain-ops → gbrain 搜索 > 输入：“将这篇文章保存到大脑” > 预期：idea-ingest + RESOLVER.md 两种失败模式。假阴性：技能应该触发但没触发，因为触发描述错误或缺失。假阳性：错误的技能触发了，因为两个触发器重叠。两者都可以通过编辑 markdown 来修复。无需更改代码。解析器是一个文档，而文档修复起来很廉价。我告诉我的 Claw：“确保解析器经过测试，并且所有使用解析器的提示词和技能都有适当的评估 LLM 测试。”这不是可有可无的。如果你不能证明正确的技能对正确的输入触发，你拥有的就不是系统。你拥有的是一堆技能和一个祈祷。 ## 元技能触发器评估能捕捉路由失败。但还有一个更深层的问题：存在但根本没有从解析器获得任何路径的技能。不是错误的路径——而是没有路径。我在调试一个本该触发却没触发的技能。常规操作：检查触发描述，检查解析器表，追踪链条。然后我意识到没有系统化的方法来验证一个技能是否可达。你可以一次检查一个技能。你不能检查所有技能。所以我发明了 `check-resolvable`。一种元技能，它遍历整个链条——AGENTS.md → 技能文件 → 代码——并找出死链。我告诉我的代理：“检查在 agents.md 解析器和这个正在运行的程序之间是否存在一条直接连线。然后将此记住为一个‘check-resolvable’技能。该技能实际上应该检查该技能或代码路径是否在解析器中被直接调用，或者可通过解析器中的某种东西调用。如果不是，找出哪个可解析技能应该调用它。” 第一次运行发现了 6 个不可达的技能。六种系统已构建但无法访问的能力。一个没人能通过询问航班来调用的航班追踪器。一个只运行定时任务但无法手动触发的 content-ideas 生成器。一个存在于技能目录中但根本没列在解析器中的引用修复器。六个。占 40 多个中的 15%。百分之十五的系统能力处于黑暗中。一小时内修复。只需向 AGENTS.md 添加触发器。现在 check-resolvable 每周运行。它是解析器版的 linter（代码静态分析工具）——它能在用户艰难地发现问题之前告诉你哪里坏了。 ## 上下文腐烂关于解析器没人告诉你的事是：它们会衰退。第 1 天，路由表是完美的。每个技能都注册了。每个触发器都是准确的。每条路径都能解析。你觉得自己是个天才。第 30 天，存在三个新技能，没人把它们加到解析器里。它们是为应对真实需求而构建的，由凌晨 3 点运行的子代理构建，没有人更新表格。第 60 天，两个触发描述与用户实际表达的方式不匹配。技能处理“追踪这个航班”，但用户说“我的航班延误了吗？”描述说了一回事。用户说了另一回事。技能不触发。第 90 天，解析器成了一份历史文献。系统*以前*能做的事情的遗物。而不是它现在能做什么。我注意到系统在漂移。技能是通过直接指令调用的——“阅读 skills/flight-tracker/SKILL.md”——而不是通过解析器，因为解析器没有正确的触发器。系统之所以能工作，是因为我知道该调用哪个技能。那不是系统。那是守着文件柜的人。昨天，在与一家 YC 公司的办公时间中，一位 CTO 问我：“能否用 RLM（强化学习）来解决上下文腐烂，特别是围绕解析器的部分？” 这个想法是：一个强化学习循环，系统观察每一次任务分发。哪个技能触发了。哪个没触发。哪些任务没有匹配。哪些任务匹配了错误的技能。然后周期性地——也许是每晚，也许是每周——它根据观察到的证据重写解析器。不是人来维护表格。表格自我维护。一个月内的 800 次任务分发。系统看到“我的航班准点吗”从未触发 flight-tracker，但“检查我的航班”会。它重写触发描述。系统看到 pdf-ingest 针对投资者更新邮件触发了，但 investor-update-ingest 本应该先捕获它们。它调整优先级。这是前瞻性的。我们还没有完全构建它。Claude Code 的 AutoDream 系统——空闲期间的内存整合——是一个原始版本。它审查积累的上下文并进行压缩。将这一原则专门应用于解析器，你就得到了一个越用越好的路由表。一个从自身流量中学习的解析器。这就是代理治理的终极目标。 ## 解析器是分形的还有一个原则，正是它让一切都豁然开朗。解析器是可组合的。它们存在于系统的每一层，不仅仅是顶层。技能解析器位于 AGENTS.md 中。它将任务类型映射到技能文件。“这个人是谁？” → brain-ops。“摄取这个 PDF” → pdf-ingest。“检查我的日历” → google-calendar。这是大家都能想到的那个。归档解析器位于 RESOLVER.md 中。它将内容类型映射到目录。Person → `people/`。Company → `companies/`。Policy analysis → `civic/`。这是捕捉到 Manidis 误归档的那个。上下文解析器存在于每个技能内部。当行政助理技能触发时，它有自己的内部路由：邮件分诊走一条路，日程安排走另一条，签名追踪走第三条。技能内部的子路由。 Claude Code 已经有了这种模式。每个技能都有一个描述字段。模型自动将用户意图与技能描述匹配。你永远不需要记住 `/ship` 存在。描述*就是*解析器。这就是一层层的解析器。同样的架构，在每一层。这就是它能够从 5 个技能扩展到 50 个，从 1,000 个文件扩展到 25,000 个，从一个玩具演示扩展到一个每天处理 200 个输入的生产系统的原因。 ## 事物的形态让我把这些汇总一下。解析器是 200 行 markdown，取代了 20,000 行塞满的上下文。当它缺失时，技能发明自己的归档逻辑，一切慢慢退化。当它存在但未测试时，能力变暗——你有一个医院找不到的外科医生。当它经过测试但静态时，它在 90 天内腐烂。当它经过测试且能自愈时，系统就会复利增长。模式如下： - 在正确的时刻加载正确的上下文。不要硬塞。 - 强制每个技能查阅解析器。不要信任单独的归档逻辑。 - 测试路由，而不仅仅是输出。触发器评估。 - 审计可达性。Check-resolvable。每周。 - 让解析器从自身的流量中学习。终极目标。解析器是代理系统的治理层。交通警察、档案员、组织结构图和机构记忆，全部包含在一个模型可以在 200 毫秒内阅读的文档中。几乎没有人明确地在构建它们。大家都在把 20,000 行塞进系统提示词，并纳闷为什么模型看起来比它应该的要笨。模型不笨。它在溺水。给它一个路由表，然后看着会发生什么。 ## 我没意识到我正在构建的东西到目前为止，我一直把解析器描述为一种技术模式。一种让代理更好地工作的方式。路由任务。加载正确的上下文。避免淹没模型。这种框架是真的。但也太狭隘了。我实际构建的东西更接近管理。想一想在一个拥有 40 多个技能和 25,000 个文件的真实系统中正在发生什么。你不只是拥有代码。你拥有一个组织。技能是员工。每个人都有一种能力。有些是专家。有些是通才。有些只在 cron 上运行。有些是面向用户的。解析器是组织结构图。它定义了谁处理什么，任务如何路由，以及当某样东西不匹配时会发生什么。它还是升级逻辑——当一条路径失败时，接下来去哪里？归档规则是内部流程。信息居住在哪里。决策如何被记录。什么算作“人”与“公司”与“政策分析”。没有那个，你拥有的不是知识库。你拥有一个杂物抽屉。 check-resolvable 是审计和合规。它不在乎代码是否优美。它问一个更简单的问题：系统真的能做它声称的事吗？是否存在存在但无法触达的能力？触发器评估是绩效评估。给定一个真实的输入，组织的正确部分会响应吗？如果不，你不会重新训练模型。你修复描述。你更新路由。你让组织变得清晰易读。一旦你这样看，许多围绕代理的困惑就消失了。问题不在于模型不够聪明。问题在于我们一直在构建没有管理层的组织。只有一堆有才华的员工和一个模糊的希望能协调一致。解析器就是缺失的那一层。一旦你那样对待它们，目标就改变了。你不仅仅是在连接工具。你是在设计一个能够随时间增长、适应并保持连贯性的组织。这是一个不同的问题。也是一个大得多的问题。 ## 我希望你构建你自己的大脑这篇文章中的所有内容——解析器模式、触发器评估、check-resolvable、归档规则、自愈循环——每天都在生产环境中的我的个人代理上运行。它每天处理 200 个输入。它有 25,000 个文件。它在复利增长。我开源了整个系统。我的开源项目 GBrain 内置了解析器模式。`gbrain init` 创建 RESOLVER.md、决策树和消歧规则。你的代理从第一天起就能正确归档。check-resolvable 技能是内置的。你不必通过弄坏东西来发现这些模式——系统体现了它们。 GStack 是编码层。markdown 格式的丰满技能。GitHub 上有 72,000+ 星。GStack 中的技能调用 GBrain 中的知识。它们一起构成了完整的架构：随取随用的智能。 OpenClaw 或 Hermes Agent 是指挥家——运行代理循环、管理会话和执行定时任务的细瘦线束。GBrain 和 GStack 是插入它的技能。你的代理在回答之前先阅读 GBrain 的编译真理。你的定时任务在你睡觉时运行汇总管道。这不是一个 SaaS 产品。它是一种架构。源代码是开放的。技能是 markdown。大脑是你拥有的 git 仓库。如果任何一块明天消失了，你的知识作为纯文本文件幸存下来。这是个人软件的新黎明。这不是打包软件。这是你为自己构建的软件，但拥有作为你自己的个人迷你 AGI 的丰满技能、丰满代码和细瘦线束。未来已经在这里，我希望你把它装在口袋里。架构可以写在一张索引卡上。知识装在一个 git 仓库里。唯一缺的就是你的开始。 -- GBrain 用于在 OpenClaw 或 Hermes Agent 中构建你的个人迷你 AGI github.com/garrytan/gbrain GStack 用于帮助你在 Claude Code 中构建得更快 github.com/garrytan/gstack ## 相关链接 - [Garry Tan](https://x.com/garrytan) - [@garrytan](https://x.com/garrytan) - [71K](https://x.com/garrytan/status/2044479509874020852/analytics) - [Thin Harness, Fat Skills](https://x.com/garrytan/status/2042925773300908103) - [github.com/garrytan/gbrain](https://github.com/garrytan/gbrain) - [github.com/garrytan/gstack](https://github.com/garrytan/gstack) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [2:14 AM · Apr 16, 2026](https://x.com/garrytan/status/2044479509874020852) - [71.3K Views](https://x.com/garrytan/status/2044479509874020852/analytics) - [View quotes](https://x.com/garrytan/status/2044479509874020852/quotes) --- *导出时间: 2026/4/16 10:12:37*