人工智能RAGAgent 记忆MCP 服务知识管理【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址https://gitcode.com/gh_mirrors/gb/gbrain点击查看免费下载在 gbrain 这样的技能型 Agent 架构中路由文件RESOLVER.md/AGENTS.md承载着用户意图 → 技能路径的映射是每次会话都要读入上下文的核心资产。本文基于仓库内 skills/functional-area-resolver/SKILL.md 展开系统讲解功能域调度器Functional-Area Dispatcher这一压缩模式如何把粒度到技能行的路由表改写为按功能域聚合、带(dispatcher for: ...)子技能清单的调度条目并配以仓库内 A/B 评测证据evals/functional-area-resolver/与可复现命令。读完本文你将掌握从压缩前置条件、面积划分、条目格式到强制验证门禁的完整闭环并能在自己的 Agent 工作区复刻这套零运行时开销的两层路由方案。问题路由表膨胀正在吃掉上下文预算gbrain 工作区中的技能会不断增长。每新增一个技能路由文件就多一行触发短语 - 技能路径。当技能数量达到 200 时RESOLVER.md/AGENTS.md的体积会膨胀到25–30KB而这份文件在每次会话启动时都会被完整加载直接挤占本应投入实际工作的上下文预算。从源码看路由文件在 gbrain 中的解析位于 src/core/check-resolvable.ts该模块会把RESOLVER.md与同级AGENTS.md解析成结构化条目同一文件中注释明确支持两种格式、并在 OpenClaw 部署中做双文件合并同时校验所有 manifest 技能是否可到达、检测 MECE 覆盖。也就是说路由文件不仅是给人看的清单更是 gbrain 运行时路由与校验的系统事实来源system of record其体积直接关联每次会话的基础上下文成本。解决方案每个功能域一行子技能清单内联核心思路用每个功能域一条目取代每个技能一行。每个面积条目把所有可派发到的子技能列在(dispatcher for: ...)子句中LLM 只需读一条面积条目即可路由到正确的子技能。压缩前270 行、25KB- Creating/enriching a person or company page - enrich - Fix broken citations in brain pages - citation-fixer - Publish/share a brain page as link - brain-publish - Generate PDF from brain page - brain-pdf - Read a book through lens of a problem - strategic-reading - Personalized book analysis - book-mirror - Brain integrity - brain-librarian ...压缩后13 行、13KB- **Brain knowledge**: create/enrich/search/export brain pages, filing, citations, publishing, book analysis, strategic reading, concept synthesis, archive mining - brain-ops (dispatcher for: enrich, query, brain-pdf, brain-publish, brain-export, brain-librarian, citation-fixer, book-mirror, strategic-reading, concept-synthesis, archive-crawler, ...)压缩后体积约为原来的48%。仓库中保留了这一真实转换的完整样本evals/functional-area-resolver/variants/baseline.md270 行逐技能清单来自生产AGENTS.md压缩前状态、已脱敏与 evals/functional-area-resolver/variants/functional-areas.md压缩后 13 个功能域条目。为什么有效两层派发的核心认知压缩模式的成立依赖一个关键认知LLM 路由时并不需要每个子技能一行。它只需要三样东西面积识别Area recognition——这是关于 brain 页面的 → Brain Knowledge子技能可见性Sub-skill visibility——(dispatcher for: ...)列表告诉模型这个域下到底有哪些可用技能技能文件本身——一旦 LLM 读到brain-ops/SKILL.md它就获得了完整的内部路由细节。这就是两层派发two-layer dispatch路由文件只负责路由到面积面积技能文件再负责路由到具体子技能。每一层只做一件事且做好这一件事。值得注意的是面积条目中的箭头支持两种写法模板默认用 ASCII-部分生产部署使用 Unicode→。gbrain 评测 harness 的正则同时兼容两者见下文实测数据但更早版本的 harness 只匹配 Unicode→因此文档要求 gbrain 版本至少为 v0.32.3.0。实测数据A/B 评测证明了什么该模式并非拍脑袋设计而是经过了受控 A/B 评测验证。评测实现位于 evals/functional-area-resolver/三种路由架构在三个 Anthropic 前沿模型Opus 4.7、Sonnet 4.6、Haiku 4.5上针对真实生产AGENTS.md内容、20 条手写训练夹具 5 条留出盲测夹具、每夹具 × 变体3 个种子重复进行测试95% 置信区间用 t 分布df2t-critical4.303计算。双评分规则STRICT 与 LENIENT评测中的每一行输出都携带两个分数二者意义不同STRICTcorrect预测的技能 slug 与期望完全相等——LLM 是否返回了精确 slugLENIENTcorrect_lenient预测落在与期望相同的派发面积内——LLM 是否落在正确的面积哪怕它从(dispatcher for: ...)里选了一个更具体的子技能。这更接近生产行为对邮件意图落进gmail也算成功即使路由条目写的是executive-assistant。对于没有 dispatcher 子句的变体baseline、resolver-of-resolversLENIENT 退化为 STRICT。训练语料n203 seeds × 3 变体 × 3 模型LENIENT变体Opus 4.7Sonnet 4.6Haiku 4.5体积baseline270 行逐条 bullet81.7% ± 7.2%86.7% ± 7.2%73.3% ± 7.2%25KBfunctional-areas本文模式98.3% ± 7.2%100% ± 0%88.3% ± 7.2%13KBresolver-of-resolvers无 dispatcher 子句63.3% ± 14.3%41.7% ± 7.2%65.0% ± 12.4%10KB留出盲测语料n53 seedsLENIENT变体Opus 4.7Sonnet 4.6Haiku 4.5baseline100% ± 0%100% ± 0%100% ± 0%functional-areas100% ± 0%100% ± 0%100% ± 0%resolver-of-resolvers100% ± 0%73.3% ± 28.7%100% ± 0%数据说明了什么训练集上 functional-areas 全面击败 baseline三个模型均 1317 个百分点同时体积仅为 baseline 的 48%。留出集上双方均饱和在 100%误差范围内打平。(dispatcher for: ...)子句是承重信号resolver-of-resolvers 变体剥掉该子句后在 Sonnet 上崩到 41.7%——这正是当初 PR 预言的灾难性失败场景如今被实测复现。模式按设计工作大多数STRICT 失败其实是 LLM 选了更具体的子技能如选gmail而非executive-assistant。STRICT 低估了模式价值LENIENT 才反映生产 Agent 的真实行为。模式价值随模型档次放大压缩收益LENIENT 训练集在 Opus 上 17pp、Sonnet 上 13pp、Haiku 上 15ppSonnet 上 functional-areas 与 resolver-of-resolvers 的差距最干净100% vs 41.7%说明模型容量会影响 dispatcher 信号被利用的程度。可复现命令cd evals/functional-area-resolver node harness.mjs --model opus # ~225 次 LLM 调用Opus 定价约 $1.70 node harness.mjs --model sonnet # 约 $1.00 node harness.mjs --model haiku # 约 $0.30 node rescore.mjs baseline-runs/2026-05-11-opus-4-7.jsonl # 零成本重新打分运行凭证model、prompt_template_hash、fixtures_hash、harness_sha、ts保存在evals/functional-area-resolver/baseline-runs/2026-05-11-{opus-4-7,sonnet-4-6,haiku-4-5}.jsonl每次运行都会写 JSONL首行为 receipt绑定 harness 版本与输入哈希保证可审计重放其后每夹具 × 变体 × 种子一行。方法学上的注意事项生产提示词是承重件若使用朴素返回技能 slug的提示词不含关于(dispatcher for: ...)的指令所有压缩变体在 Opus 上都会崩到约 30–60%。dispatcher-aware 提示词在 evals/functional-area-resolver/harness-runner.ts 的PROMPT_TEMPLATE中核心指令是当用户意图命中某个面积时从该面积的 dispatcher for 列表返回最具体的子技能而不是 dispatcher 本身。在自己的 Agent harness 里请以它为模板缺了它压缩就会失效。同作者风险训练语料与变体出自同一次发布留出语料在变体创作之前写成且从未调整缓解但未消除过拟合。置信区间基于 n3 种子重复的 t 分布需守住 n3 下限高 CI 意味着底层样本噪声大。单一厂商结果三个模型均为 Anthropic跨厂商验证Gemini、GPT是 v0.33.x 的后续项。留出集很小n5多数单元饱和在 100%harness 无法区分100%与95% 加一次非确定性 miss扩充到 ≥20 是 v0.33.x 的后续项。评测夹具与变体一览训练夹具n20与留出夹具n5分别见 evals/functional-area-resolver/fixtures.jsonl 与同目录fixtures-held-out.jsonlREADME 中列出。夹具格式为{intent:..., expected_skill:...}覆盖 enrich、brain-pdf、brain-publish、brain-librarian、citation-fixer、book-mirror、strategic-reading、concept-synthesis、archive-crawler、media-ingest、google-calendar、executive-assistant、perplexity-research、x-ingest、checkin、daily-task-manager 等目标技能且这些目标技能在两个变体中同时存在已对照真实生产 AGENTS.md 验证。此外还包含针对skillify、skill-creator、book-mirror、concept-synthesis等相邻元技能的对抗性负样本防止拓宽后的触发词过度捕获本不属于 functional-area-resolver 的意图。三种变体的构造与定位evals/functional-area-resolver/variants/baseline.md270 行逐条 bullet取自生产AGENTS.md压缩前提交93848ff3b^已脱敏约 25KBevals/functional-area-resolver/variants/functional-areas.mddispatcher 模式取自AGENTS.md: functional-area resolver — 25KB→13KB, 100% routing accuracy提交93848ff3b约 13KBevals/functional-area-resolver/variants/resolver-of-resolvers.md从 functional-areas 机械剥离(dispatcher for: ...)子句得到的消融对照约 10KB。前置研究静态提示词版的分层路由该模式是2024–2025 年分层 Agent 路由研究方向的静态提示词类比。已发表的分层方案都在运行时通过第二次 LLM 调用解析层级本模式把层级内联进单次 LLM 遍历的 dispatcher 列表中AnyToolarXiv:2402.04253meta-agent → category-agent → tool-agent 三层结构在 16K API 上比扁平检索高 35.4pp。(dispatcher for: ...)子句相当于把 meta-agent 的视图折叠进一次 LLM 遍历RAG-MCParXiv:2505.03275基于嵌入的预检索报告 49.2% 提示词 token 缩减与 3.2× 准确率提升。token 缩减的故事与本文一致48% 体积缩减但机制不同RAG 检索 vs 静态 dispatcherAnthropic Agent Skills渐进式披露——frontmatter约 80 token常驻加载、SKILL.md 正文命中后才加载。本技能把同一原则应用到路由表层而非每个技能正文层。2025–2026 年文献中尚无针对静态提示词分层路由的公开基准所有已发表方案都在运行时经第二次 LLM 调用解析层级。本模式的开源贡献在于层级可以被内联进单次 LLM 遍历的 dispatcher 列表并保持路由准确率详细方法学见 evals/functional-area-resolver/README.md。实操如何压缩你的路由文件Step 1前置条件任一不满足即拒绝压缩两个门禁任一失败都不允许动手源路由文件小于12KB压缩开销会超过收益git status显示路由文件有未提交改动压缩器的编辑会与用户正在做的工作纠缠。用户需要显式以--force才能覆盖任一门禁。Step 2决定压缩哪个文件gbrain 工作区运行时通常合并两份路由文件见 src/core/check-resolvable.ts v0.31.7 的双文件解析逻辑skills/RESOLVER.md与同级的../AGENTS.md。选择策略只有一份超 12KB压缩那一份小的一份保持不动两份都超 12KB分别压缩顺序为先AGENTS.mdOpenClaw 风格部署中通常更大再RESOLVER.md只有小的一份超 12KB少见同样压缩它。如果部署只使用一份路由文件本节直接跳过压缩那一份即可。Step 3识别功能域按领域对技能分组。典型面积按部署调整Brain Knowledge—brain-ops作 dispatcherContent Ingestion—ingest作 dispatcherCalendar Scheduling—google-calendar作 dispatcherEmail Comms—executive-assistant作 dispatcherResearch Investigation—perplexity-research作 dispatcherX/Twitter Social—x-ingest作 dispatcherPlaces Travel—checkin作 dispatcherProduct Building—acp-coding作 dispatcherInfrastructure—healthcheck作 dispatcherTasks Logistics—daily-task-manager作 dispatcherPeople Contacts—google-contacts作 dispatcher真实样例可对照 evals/functional-area-resolver/variants/functional-areas.md 中的 13 个功能域条目含 Political、Inter-agent、Circleback 等域。Step 4面积条目格式每条面积条目遵循如下模板- **{Area Name}**: {comma-separated trigger phrases} - {dispatcher-skill} (dispatcher for: {comma-separated sub-skill names})规则触发短语要足够宽以捕获意图如brain pages, enrich, search, filing, citations, book analysis子技能列表要全面——这是 LLM 知道有什么可用的途径dispatcher 技能文件自身应有内部路由表如brain-ops/SKILL.md内部再细分。从源码看harness 的正则(?:→|-)\s*([a-z][a-z0-9-]*)\s*\(dispatcher for:\s*([^)])\)evals/functional-area-resolver/harness-runner.ts正是靠解析dispatcher for:子句来建立面积 → 子技能的 LENIENT 映射这也解释了为什么子技能名必须完整、命名必须符合[a-z][a-z0-9-]*的小写连字符规范。Step 5常开条目保持独立Gate 与常开条目acknowledge、multi-user、entity-detector等保持为单独行——它们在每条消息上都会被检查而不是被派发。Step 6强制验证路由准确率提交压缩文件前必须过两道门任一失败不得提交。门 1结构化验证。确认routing-eval.jsonl夹具在压缩后的路由文件下仍能解析到正确技能。在你刚编辑的路由文件所在工作区运行gbrain routing-eval --json若夹具准确率跌破 95%回滚并调优面积条目后再跑。门 2针对你编辑文件的本机 LLM A/B 验证。确认前沿 LLM 在你这版特定压缩下仍能钻入 dispatcher 列表到达子技能。harness 位于 gbrain 仓库内因此需要一份 gbrain 仓库检出。把你编辑好的路由文件拷入 harness 的 variants 目录再用--variants指向它# 在 Agent 工作区中定位你刚压缩的路由文件 EDITED/path/to/your/AGENTS.md # 或 skills/RESOLVER.md以你编辑的为准 # 在 gbrain 仓库检出目录中 cd /path/to/gbrain/evals/functional-area-resolver TMP$(mktemp -d)/variants mkdir -p $TMP cp $EDITED $TMP/my-edit.md # 针对你的文件跑 harness串行约 75 次调用 × $0.0076 ≈ Opus 上约 $0.57 ANTHROPIC_API_KEY... node harness.mjs --variants-dir $TMP --variants my-edit \ --model opus --parallel 3 --yes该 harness 使用 gbrain 内置的夹具集因此验证的是对 gbrain 内置夹具覆盖的路由意图LLM 是否落到了正确的子技能——这是对共享技能的回归检查而不是对你夹具集的完整重评。要做完整评测覆盖请按本技能的fixtures.jsonlfixtures-held-out.jsonl结构用针对你自己技能的意图复制一套。若你变体的 lenient同面积分数跌破 95%回滚压缩并调优。常见原因某个子技能从(dispatcher for: ...)列表中被遗漏面积触发短语过窄LLM 识别不出意图面积合并过度激进面积太少——见反模式ASCII-与 Unicode→不一致——harness 现在两者都接受但更早版本只匹配 Unicode。请将 gbrain 钉在 v0.32.3.0。harness 评测中常见的误报不是你的压缩有 buggbrain 内置夹具针对enrich、query、gmail、executive-assistant等技能名如果你的路由文件根本不暴露这些技能这些夹具出现 strict 失败是预期行为。只要这些技能出现在你的(dispatcher for: ...)列表中lenient 打分就仍然准确。Step 7提交前先审 diff向用户展示拟议编辑或实际 git diff在暂存前等待明确批准——与skills/book-mirror/SKILL.md的约定一致。行为契约本技能承诺以下保证该节也是合规性测试的断言依据路由与 frontmatter 中的规范触发词一致仅当 Step 1 前置条件通过文件 ≥12KB 且工作树干净或--force时才执行压缩Step 6 的强制验证门在用户编辑过的文件上触发而非示例变体用户在提交压缩文件前必须运行gbrain routing-eval --json并且跑 gbrain 仓库 harnessnode harness.mjs --variants-dir tmp --variants my-edit隐私契约保持不变压缩输出不得泄漏任何 fork 专属的文件系统路径字面量服务端 brain home、OpenClaw fork home。输出格式压缩后的路由文件遵循 Step 4 的面积条目模板。每条为- **{Area Name}**: {trigger phrases} - {dispatcher-skill} (dispatcher for: {sub-skill list})dispatcher 箭头可以是 ASCII-本模板默认或 Unicode→部分生产部署使用gbrain harness 两者都接受。反模式实测失败过什么带 pipe 表格的 resolver-of-resolvers已实测失败见评测表。LLM 会从表格里选面积名而不是钻入子技能。删除子技能名没有(dispatcher for: ...)列表LLM 无法路由到具体子技能。这个列表就是路由信号本身。面积太少合并到 5 个面积会让每个面积过宽。12–15 个面积是甜区。面积太多违背初衷。如果你有 50 个面积不如保留逐技能行。维护新增技能与新增功能域新增技能时确定它的功能域把技能名加进该域的(dispatcher for: ...)列表更新该域的技能文件补充路由细节运行 Step 6 的路由评测验证。新增功能域时创建带内部路由的 dispatcher 技能在路由文件中新增面积条目运行 Step 6 的路由评测验证。变更记录v1.0.0 — 2026-05-11初版。模式随 gbrain v0.32.3.0 发布附带留出 A/B 评测见evals/functional-area-resolver/。技能在发布前由compress-agents-md更名为functional-area-resolver——贡献在于模式本身而非文件名。进一步探索本技能的路由夹具skills/functional-area-resolver/routing-eval.jsonl——含正例意图与针对相邻元技能的对抗性负样本ambiguous_with标注评测全套材料evals/functional-area-resolver/README.md方法学、文件清单、限制与 v0.33.x 后续项harness 单元测试无需 API keybun test evals/functional-area-resolver/harness-runner.test.ts45 个用例底层路由解析与校验实现src/core/check-resolvable.ts——支持双文件RESOLVER.mdAGENTS.md合并解析并提供可到达性校验与 MECE 检测同族压缩与上下文预算话题skills/context-audit/、skills/measure-before-you-fix/等目录。赞分享人工智能RAGAgent 记忆MCP 服务知识管理【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址https://gitcode.com/gh_mirrors/gb/gbrain点击查看免费下载相关推荐GBrain Functional-Area Resolver用功能区域调度器把 Agent 路由表从 25KB 压到 13KB 而不损失路由精度GBrain Functional Area Resolver用功能区域调度器把 Agent 路由表从 25KB 压到 13KB 而不损失路由精度 本指南围绕人工智能RAGAgent 记忆MCP 服务知识管理GBrain 路由表压缩实战Functional-Area Resolver 功能区域调度器模式GBrain 路由表压缩实战Functional Area Resolver 功能区域调度器模式 导读 本文围绕 GBrainGarrys Opinion人工智能RAGAgent 记忆MCP 服务知识管理gbrain functional-area-resolver A/B 评估用 48% 体积证明功能域调度器路由模式的 A/B 评测方法论gbrain functional area resolver A/B 评估用 48% 体积证明功能域调度器路由模式的 A/B 评测方法论 本文以 gbrai人工智能RAGAgent 记忆MCP 服务知识管理上一篇SymPy测试框架完全指南单元测试与数学验证终极教程下一篇Asus笔记本性能衰减恢复G-Helper重置BIOS设置教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考