人工智能RAGAgent 记忆MCP 服务知识管理【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址https://gitcode.com/gh_mirrors/gb/gbrain点击查看免费下载导读本文基于 GBrain 的schema-evolution技能约定系统讲解 schema pack 演进的核心决策框架面对一批共享领域含义的页面如何根据规模判断是「不打包、就近归类」「加别名或收窄前缀」还是「新建一等类型」并完整覆盖add-type、add-alias、remove-type、sync --apply、fork、lint等命令的实战用法与底层实现原理。读完本文你将掌握在 schema-author 等技能工作流中安全、克制地演进 schema pack 的完整方法论并能独立完成从单页归类到百级规模建型、再到跨 pack 升级unify-types的全过程。这是一条横切整个仓库的约定任何提议修改活动 schema pack的技能都应先读本文再调用schema-author。其核心目标是让 pack 足够小小到 Agent 能把整张类型图装进工作记忆同时足够有表现力让研究、法律、创始人运营等自定义领域获得一等类型。为什么 schema 演进需要纪律GBrain 的页面类型page_type体系由 schema pack 承载每个 pack 用path_prefixes路径前缀、primitive原语、extractable/expert_routing等标志以及link_types链接动词共同描述一个领域模型。从清单定义可以看到add-type等命令背后是结构化的 manifest 变更——每一次add-type都是向 pack 中永久写入一个类型。这正是文档反复强调「pack types are permanent decisions」pack 类型是永久决定的原因类型越多Agent 需要同时握在脑中的类型图就越大检索路由与链接推断的噪音也越高。因此演进的第一原则是克制能用现有类型解决的问题绝不新建类型。决策树三档规模三种策略当你在页面上看到一群共享领域含义的簇cluster时先数数它的规模You see a cluster of pages that share a domain meaning. │ ▼ How many pages in the cluster? │ ┌─────┴───────┬──────────────┐ ▼ ▼ ▼ 20 20-100 100 │ │ │ ▼ ▼ ▼ One-off. Big enough. First-class. Dont pack- Add an alias Add a new codify. to an existing page_type with type OR a its own prefix, narrow prefix primitive, and branch. flags. │ │ ▼ ▼ Use the Alias: Add the nearest same enrich type via existing / expert / gbrain schema type link verbs. add-type ... frontmatter New type: then tag. diverging sync --apply. semantics.三档规模的本质判断标准是「这个簇是否有稳定的、长期存在的领域含义」规模判定推荐动作追加依据 20 页One-off临时簇不打包就近使用现有类型 frontmatter 标签一次性导入不构成永久类型决策20–100 页足够大但可归类为现有类型加 alias或建一个共享原语的新类型共享 vs 分叉的语义行为100 页一等领域新建 page_type专属 prefix primitive flags规模足以覆盖建型的固定成本示例一One-off小于 20 页不加入 pack我在2026-projects/skunkworks-spec/下有 3 个页面。要不要加一个skunkworks类型不要。3 个页面不足以支撑一个永久 pack 条目。正确做法是就近归类到最匹配的现有类型concept或note并在 frontmatter 中用project:标签记录其项目归属。如果将来这个簇增长到 20 页再回来重新评估。这种「先贴标签、后升格」的策略与 GBrain 的type_usage/stats工具呼应类型使用率数据天然会告诉你哪个 frontmatter 标签的页面在悄悄膨胀。示例二20–100 页alias 或收窄前缀二选一我在people/researchers/下有 50 个页面与我的person类型重叠。要不要加一个researcher类型有两种同样有效的选择给person加别名gbrain schema add-alias person researcher。此后针对researcher的闭包查询closure queries也会命中person行——即别名在查询层面与主类型等价。新建共享entity原语的类型gbrain schema add-type researcher --primitive entity --prefix people/researchers/。这是一个独立类型可以单独标记--extractable或--expert。选择标准当「研究者首先是 person其次才是 researcher」共享富化规则、专家路由语义、链接动词时选 alias当「研究者的行为出现分叉」不同的 extractable 规则、不同的链接动词、不同的评分 rubric时选新类型。从实现看alias 由 mutate.ts 中的别名注册逻辑写入 manifest查询端在 expand-type-filter.ts 中做类型展开时会把别名映射回主类型因此 alias 路径的开销远小于维护一个独立类型。示例三100 页一等类型我在meetings/下有 4000 个页面。我想让它们被类型化为meeting而不是遗留默认的note。直接建型gbrain schema add-type meeting \ --primitive temporal \ --prefix meetings/ \ --extractable gbrain schema sync --applysync --apply会回填backfill全部 4000 个页面底层 sync.ts 按 pack 的path_prefixes匹配数据库pages表把source_path命中前缀的行的page.type批量改写。此后所有导入到meetings/下的内容都会经由 pack 推断为meeting类型无需再手工指定。add-type命令详解与参数约束add-type是演进的主力命令命令实现对参数有严格校验gbrain schema add-type name --primitive p --prefix dir/参数必填说明约束name是新类型名称位置参数pack 内唯一--primitive p是原语类型必须属于PACK_PRIMITIVES否则直接报错退出--prefix dir/是路径前缀例如--prefix people/researchers/缺失时报错--extractable否标记为可抽取对应extractable: true--expert/--expert-routing否标记为专家路由对应expert_routing: true--alias name否同时注册别名可重复传入多个--pack name否指定目标 pack默认操作活动 pack其中--primitive的合法取值在 manifest-v1.ts 中定义export const PACK_PRIMITIVES [entity, media, temporal, annotation, concept] as const;entity实体类person、company、researcher 等可被引用、可被专家路由的个体media媒介内容tweet、文章、视频等原始素材temporal时间相关meeting、事件、日程annotation注释/批注类对已有内容的加工concept概念类宽泛的抽象知识节点。选错 primitive 会让类型在闭包查询与链接推断中表现异常因此命令在写盘前就会拒绝非法取值——这印证了「primitive 是类型行为的第一分类器」。更多演进命令alias、prefix、update 与 fork除了add-typeschema 命令族还提供了一整套演进工具# 加别名让 closure 查询同时命中主类型 gbrain schema add-alias type alias # 移除别名 gbrain schema remove-alias type alias # 给类型追加路径前缀 gbrain schema add-prefix type prefix # 移除路径前缀注意dead prefix 的处理见下文 Donts gbrain schema remove-prefix type prefix # 更新类型标志--extractable true|false / --expert true|false / --primitive P gbrain schema update-type name [--extractable BOOL] [--expert BOOL] [--primitive P] # 复制 pack 到新的可编辑名称自定义域名的起点 gbrain schema fork source-pack new-namefork实现见 schema.ts会把源 pack 的 manifest 复制到新名字并将版本号重置为0.0.1——这保证了自定义派生包永远不会与上游版本号冲突。文档规定gbrain-base和gbrain-recommended是不可直接修改的任何定制都要先 fork 再改正是为了保住基线包的可升级性。Donts五条必须绕开的坑演进约定给出了五条明确禁令前四条有源码级 lint 规则背书不要为一次性导入的目录建类型。Pack 类型是永久决定一次性 triage 导入不是。低频簇先用现有类型 frontmatter 标签过渡。不要为了消除schema stats中的dead_prefixes而加类型。死前缀是一个信号——说明前缀声明错误或语料库迁移了。正确动作是移除该前缀或迁移内容而不是加一个空类型。仓库中 lint-rules.ts 专门提供了extractable_empty_corpus规则当某个extractable: true类型的path_prefixes在数据库中匹配到 0 页时给出 warning提示「要么移除 extractable要么检查前缀是否匹配真实导入路径」。不要未经验证就采纳schema suggest的候选类型。suggester 是启发式的可能提出与现有类型重叠的建议。在add-type之前先跑lint --with-db在写入前捕获前缀冲突。lint --with-db会将 pack 的合并 manifest含extends链与borrow_from与 tier-4 DB 平面一起检查这是最接近线上真实状态的校验。不要给没有path_prefixes的类型加--expert。expert_routing_without_prefixlint 规则正是为这个形状设计的一个没有前缀的专家路由类型永远无法命中put_page推断whoknows查询会静默地永远不返回它——一个「存在但不可达」的类型是最大的资源浪费。不要直接改gbrain-base或gbrain-recommended。先 fork。何时移除一个类型RARE移除类型是罕见操作仅在以下三种情况下执行类型是错误添加的拼写错误、过早抽象该类型对应的语料已迁移到其他类型类型已悬空dangling——没有path_prefixes实际匹配到页面、没有查询引用它、其他类型的 aliases / link_types 也不引用它。remove-type受到STILL_REFERENCED检查对应 codex C14 规则的守护如果任何其他类型的 aliases / enrichable_types / link_types / frontmatter_links 引用了目标类型移除会以响亮的方式失败并列出完整引用清单。必须先打破这些引用才能移除。gbrain schema remove-type name [--pack name]这个「引用检查先行」的设计与 manifest 的闭包一致性要求一致——类型图是一个互相引用的整体任何节点都不能在仍有入边的情况下被删除。何时提交 pack 到版本控制如果你的 pack 位于源码控制中~/.gbrain/schema-packs/name/是一个 git 仓库那么每完成一批变更就提交一次。mutation_count_anomalylint 规则会监听变更审计日志当 7 天内某个 pack 的变更次数超过50 次时给出 warning规则实现见 lint-rules.ts提示信息明确建议进入你的 brain 仓库git addpack 文件commit push让变更跨机器存活。这正是「磁盘状态不可靠、版本控制才可靠」的工程原则在 schema 层上的落地——audit 目录不可读时该规则会静默跳过保证 lint 的健壮性。何时升级 packv0.42migration_from 与 unify-types后继 pack 机制从 v0.42 起一个 pack 可以声明migration_from来注册自己为另一个 pack 的后继者migration_from: pack: name version: semver-range当 brain 的活动 pack 命中声明的from范围时pack_upgrade_availableonboard 检查会浮现后继 pack并给出一个manual_only的 RemediationStep指向unify-types这个 PROTECTED Minion handler。manifest 校验与合并逻辑merge.ts都会显式处理migration_from与mapping_rules字段确保声明被完整解析。gbrain-base-v294 → 15 的规范收敛v0.41.22 起gbrain-base-v2被声明为 gbrain-base1.x 的后继者通过声明式mapping_rules把 94 个噪音类型收敛为 15 个规范类型14 canonical note兜底。完整包定义见 gbrain-base-v2.yaml执行手册见 schema-unify 技能。整个升级分三步走# 1. 预览查看每簇会如何重打字、哪些会成为 alias 行、哪些会转成真实链接 gbrain onboard --check --explain # 2. 提交 unify-types 任务apply 默认 false裸提交即 dry-run gbrain jobs submit unify-types \ --params {target_pack:gbrain-base-v2,apply:true}在 PGLite安装默认或没有运行 worker 守护进程的环境下需加--follow让任务内联执行持久 worker 守护进程仅限 Postgres 环境。任务执行期间会持有gbrain-unifydb-lock 约 10 分钟大 brain 上所以摄入中途或 autopilot 维护期间不要升级。编写后继 pack 的约束创作后继 pack 时manifest 中要声明migration_from: {pack: parent, version: 1.x}并附带mapping_rules:在 retype / page_to_link / page_to_alias 三种 kind 上做判别联合。关键约束兜底哨兵from_type: *unknown*必须放在最后保证未知类型落入 catch-allsubtype_field被限制在ALLOWED_SUBTYPE_FIELDSsubtype, legacy_type, origin, format, kind, period, domain见 manifest-v1.ts——对应 codex D9 规则第三方 pack 不能注入title/slug/type字段防止恶意 pack 覆盖承载关键行为的字段。何时不要升级后继 pack 的 mapping_rules 未覆盖你的自定义类型先 fork 后继者gbrain schema fork gbrain-base-v2 my-pack编辑规则后再指向你的 fork摄入中或 autopilot 维护期间等待unify 会持有 db-lock 约 10 分钟联邦 brain 且有不希望触碰的 source用--params {sourceId: ...}按 source 限定范围。演进工作流全景综合以上约定一次规范的 schema 演进遵循这样的完整闭环发现gbrain schema detect找到高密度前缀簇 →gbrain schema suggest给出启发式候选 →gbrain schema review-candidates复核校验任何写操作前先gbrain schema lint --with-db捕获前缀冲突、悬空引用、ReDoS 正则等问题lint 现为 11 规则富校验见 lint-rules.ts决策按三档规模决策树选择「不打包 / alias / 收窄前缀 / 一等类型」执行add-alias、add-type、add-prefix或sync --apply回填复核gbrain schema stats观察各类型页面数与覆盖率确认dead_prefixes消除且无空类型持久化变更超过 50 次/7 天前就提交 pack 到 git规模化升级需要跨 pack 收敛时走onboard --check --explain预览 unify-types任务应用。这套工作流让 pack 演进既有明确的判断依据又有 lint 与引用检查两道程序化护栏从而同时满足「Agent 可整体掌握类型图」和「自定义领域获得一等类型」这两个看起来矛盾的目标。结语Schema 演进的核心不是「会加类型」而是「知道何时不该加」。三档规模决策树提供了快速判断框架五条 Donts 与expert_routing_without_prefix、extractable_empty_corpus、mutation_count_anomaly、STILL_REFERENCED等源码级守卫把「克制」变成了可执行的程序约束而migration_frommapping_rulesunify-types的引入则让 pack 自身也具备了可声明的生命周期。掌握本文的约定后任何 Agent 技能从 schema-author 到 schema-unify都能在修改活动 schema pack 之前做出正确、克制、可回滚的决策。赞分享人工智能RAGAgent 记忆MCP 服务知识管理【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址https://gitcode.com/gh_mirrors/gb/gbrain点击查看免费下载相关推荐gbrain 模式包Schema Pack演进决策指南何时新增 page_type、alias 还是 prefixgbrain 模式包Schema Pack演进决策指南何时新增 page_type、alias 还是 prefix gbrain 的 schema pac人工智能RAGAgent 记忆MCP 服务知识管理Sway 高级类型使用 Type Alias 为类型起别名告别冗长类型签名Sway 高级类型使用 Type Alias 为类型起别名告别冗长类型签名 本篇技术指南围绕 Sway 智能合约语言中的「类型别名Type Alias」编程语言编译器区块链Roc 编译器类型别名前向引用Type Alias Forward Reference快照测试深度解析Roc 编译器类型别名前向引用Type Alias Forward Reference快照测试深度解析 本文围绕 Roc 语言编译器测试仓库中的快照测试文档创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GBrain Schema 演进实战：何时新增类型（type）、别名（alias）还是前缀（prefix）
人工智能RAGAgent 记忆MCP 服务知识管理【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址https://gitcode.com/gh_mirrors/gb/gbrain点击查看免费下载导读本文基于 GBrain 的schema-evolution技能约定系统讲解 schema pack 演进的核心决策框架面对一批共享领域含义的页面如何根据规模判断是「不打包、就近归类」「加别名或收窄前缀」还是「新建一等类型」并完整覆盖add-type、add-alias、remove-type、sync --apply、fork、lint等命令的实战用法与底层实现原理。读完本文你将掌握在 schema-author 等技能工作流中安全、克制地演进 schema pack 的完整方法论并能独立完成从单页归类到百级规模建型、再到跨 pack 升级unify-types的全过程。这是一条横切整个仓库的约定任何提议修改活动 schema pack的技能都应先读本文再调用schema-author。其核心目标是让 pack 足够小小到 Agent 能把整张类型图装进工作记忆同时足够有表现力让研究、法律、创始人运营等自定义领域获得一等类型。为什么 schema 演进需要纪律GBrain 的页面类型page_type体系由 schema pack 承载每个 pack 用path_prefixes路径前缀、primitive原语、extractable/expert_routing等标志以及link_types链接动词共同描述一个领域模型。从清单定义可以看到add-type等命令背后是结构化的 manifest 变更——每一次add-type都是向 pack 中永久写入一个类型。这正是文档反复强调「pack types are permanent decisions」pack 类型是永久决定的原因类型越多Agent 需要同时握在脑中的类型图就越大检索路由与链接推断的噪音也越高。因此演进的第一原则是克制能用现有类型解决的问题绝不新建类型。决策树三档规模三种策略当你在页面上看到一群共享领域含义的簇cluster时先数数它的规模You see a cluster of pages that share a domain meaning. │ ▼ How many pages in the cluster? │ ┌─────┴───────┬──────────────┐ ▼ ▼ ▼ 20 20-100 100 │ │ │ ▼ ▼ ▼ One-off. Big enough. First-class. Dont pack- Add an alias Add a new codify. to an existing page_type with type OR a its own prefix, narrow prefix primitive, and branch. flags. │ │ ▼ ▼ Use the Alias: Add the nearest same enrich type via existing / expert / gbrain schema type link verbs. add-type ... frontmatter New type: then tag. diverging sync --apply. semantics.三档规模的本质判断标准是「这个簇是否有稳定的、长期存在的领域含义」规模判定推荐动作追加依据 20 页One-off临时簇不打包就近使用现有类型 frontmatter 标签一次性导入不构成永久类型决策20–100 页足够大但可归类为现有类型加 alias或建一个共享原语的新类型共享 vs 分叉的语义行为100 页一等领域新建 page_type专属 prefix primitive flags规模足以覆盖建型的固定成本示例一One-off小于 20 页不加入 pack我在2026-projects/skunkworks-spec/下有 3 个页面。要不要加一个skunkworks类型不要。3 个页面不足以支撑一个永久 pack 条目。正确做法是就近归类到最匹配的现有类型concept或note并在 frontmatter 中用project:标签记录其项目归属。如果将来这个簇增长到 20 页再回来重新评估。这种「先贴标签、后升格」的策略与 GBrain 的type_usage/stats工具呼应类型使用率数据天然会告诉你哪个 frontmatter 标签的页面在悄悄膨胀。示例二20–100 页alias 或收窄前缀二选一我在people/researchers/下有 50 个页面与我的person类型重叠。要不要加一个researcher类型有两种同样有效的选择给person加别名gbrain schema add-alias person researcher。此后针对researcher的闭包查询closure queries也会命中person行——即别名在查询层面与主类型等价。新建共享entity原语的类型gbrain schema add-type researcher --primitive entity --prefix people/researchers/。这是一个独立类型可以单独标记--extractable或--expert。选择标准当「研究者首先是 person其次才是 researcher」共享富化规则、专家路由语义、链接动词时选 alias当「研究者的行为出现分叉」不同的 extractable 规则、不同的链接动词、不同的评分 rubric时选新类型。从实现看alias 由 mutate.ts 中的别名注册逻辑写入 manifest查询端在 expand-type-filter.ts 中做类型展开时会把别名映射回主类型因此 alias 路径的开销远小于维护一个独立类型。示例三100 页一等类型我在meetings/下有 4000 个页面。我想让它们被类型化为meeting而不是遗留默认的note。直接建型gbrain schema add-type meeting \ --primitive temporal \ --prefix meetings/ \ --extractable gbrain schema sync --applysync --apply会回填backfill全部 4000 个页面底层 sync.ts 按 pack 的path_prefixes匹配数据库pages表把source_path命中前缀的行的page.type批量改写。此后所有导入到meetings/下的内容都会经由 pack 推断为meeting类型无需再手工指定。add-type命令详解与参数约束add-type是演进的主力命令命令实现对参数有严格校验gbrain schema add-type name --primitive p --prefix dir/参数必填说明约束name是新类型名称位置参数pack 内唯一--primitive p是原语类型必须属于PACK_PRIMITIVES否则直接报错退出--prefix dir/是路径前缀例如--prefix people/researchers/缺失时报错--extractable否标记为可抽取对应extractable: true--expert/--expert-routing否标记为专家路由对应expert_routing: true--alias name否同时注册别名可重复传入多个--pack name否指定目标 pack默认操作活动 pack其中--primitive的合法取值在 manifest-v1.ts 中定义export const PACK_PRIMITIVES [entity, media, temporal, annotation, concept] as const;entity实体类person、company、researcher 等可被引用、可被专家路由的个体media媒介内容tweet、文章、视频等原始素材temporal时间相关meeting、事件、日程annotation注释/批注类对已有内容的加工concept概念类宽泛的抽象知识节点。选错 primitive 会让类型在闭包查询与链接推断中表现异常因此命令在写盘前就会拒绝非法取值——这印证了「primitive 是类型行为的第一分类器」。更多演进命令alias、prefix、update 与 fork除了add-typeschema 命令族还提供了一整套演进工具# 加别名让 closure 查询同时命中主类型 gbrain schema add-alias type alias # 移除别名 gbrain schema remove-alias type alias # 给类型追加路径前缀 gbrain schema add-prefix type prefix # 移除路径前缀注意dead prefix 的处理见下文 Donts gbrain schema remove-prefix type prefix # 更新类型标志--extractable true|false / --expert true|false / --primitive P gbrain schema update-type name [--extractable BOOL] [--expert BOOL] [--primitive P] # 复制 pack 到新的可编辑名称自定义域名的起点 gbrain schema fork source-pack new-namefork实现见 schema.ts会把源 pack 的 manifest 复制到新名字并将版本号重置为0.0.1——这保证了自定义派生包永远不会与上游版本号冲突。文档规定gbrain-base和gbrain-recommended是不可直接修改的任何定制都要先 fork 再改正是为了保住基线包的可升级性。Donts五条必须绕开的坑演进约定给出了五条明确禁令前四条有源码级 lint 规则背书不要为一次性导入的目录建类型。Pack 类型是永久决定一次性 triage 导入不是。低频簇先用现有类型 frontmatter 标签过渡。不要为了消除schema stats中的dead_prefixes而加类型。死前缀是一个信号——说明前缀声明错误或语料库迁移了。正确动作是移除该前缀或迁移内容而不是加一个空类型。仓库中 lint-rules.ts 专门提供了extractable_empty_corpus规则当某个extractable: true类型的path_prefixes在数据库中匹配到 0 页时给出 warning提示「要么移除 extractable要么检查前缀是否匹配真实导入路径」。不要未经验证就采纳schema suggest的候选类型。suggester 是启发式的可能提出与现有类型重叠的建议。在add-type之前先跑lint --with-db在写入前捕获前缀冲突。lint --with-db会将 pack 的合并 manifest含extends链与borrow_from与 tier-4 DB 平面一起检查这是最接近线上真实状态的校验。不要给没有path_prefixes的类型加--expert。expert_routing_without_prefixlint 规则正是为这个形状设计的一个没有前缀的专家路由类型永远无法命中put_page推断whoknows查询会静默地永远不返回它——一个「存在但不可达」的类型是最大的资源浪费。不要直接改gbrain-base或gbrain-recommended。先 fork。何时移除一个类型RARE移除类型是罕见操作仅在以下三种情况下执行类型是错误添加的拼写错误、过早抽象该类型对应的语料已迁移到其他类型类型已悬空dangling——没有path_prefixes实际匹配到页面、没有查询引用它、其他类型的 aliases / link_types 也不引用它。remove-type受到STILL_REFERENCED检查对应 codex C14 规则的守护如果任何其他类型的 aliases / enrichable_types / link_types / frontmatter_links 引用了目标类型移除会以响亮的方式失败并列出完整引用清单。必须先打破这些引用才能移除。gbrain schema remove-type name [--pack name]这个「引用检查先行」的设计与 manifest 的闭包一致性要求一致——类型图是一个互相引用的整体任何节点都不能在仍有入边的情况下被删除。何时提交 pack 到版本控制如果你的 pack 位于源码控制中~/.gbrain/schema-packs/name/是一个 git 仓库那么每完成一批变更就提交一次。mutation_count_anomalylint 规则会监听变更审计日志当 7 天内某个 pack 的变更次数超过50 次时给出 warning规则实现见 lint-rules.ts提示信息明确建议进入你的 brain 仓库git addpack 文件commit push让变更跨机器存活。这正是「磁盘状态不可靠、版本控制才可靠」的工程原则在 schema 层上的落地——audit 目录不可读时该规则会静默跳过保证 lint 的健壮性。何时升级 packv0.42migration_from 与 unify-types后继 pack 机制从 v0.42 起一个 pack 可以声明migration_from来注册自己为另一个 pack 的后继者migration_from: pack: name version: semver-range当 brain 的活动 pack 命中声明的from范围时pack_upgrade_availableonboard 检查会浮现后继 pack并给出一个manual_only的 RemediationStep指向unify-types这个 PROTECTED Minion handler。manifest 校验与合并逻辑merge.ts都会显式处理migration_from与mapping_rules字段确保声明被完整解析。gbrain-base-v294 → 15 的规范收敛v0.41.22 起gbrain-base-v2被声明为 gbrain-base1.x 的后继者通过声明式mapping_rules把 94 个噪音类型收敛为 15 个规范类型14 canonical note兜底。完整包定义见 gbrain-base-v2.yaml执行手册见 schema-unify 技能。整个升级分三步走# 1. 预览查看每簇会如何重打字、哪些会成为 alias 行、哪些会转成真实链接 gbrain onboard --check --explain # 2. 提交 unify-types 任务apply 默认 false裸提交即 dry-run gbrain jobs submit unify-types \ --params {target_pack:gbrain-base-v2,apply:true}在 PGLite安装默认或没有运行 worker 守护进程的环境下需加--follow让任务内联执行持久 worker 守护进程仅限 Postgres 环境。任务执行期间会持有gbrain-unifydb-lock 约 10 分钟大 brain 上所以摄入中途或 autopilot 维护期间不要升级。编写后继 pack 的约束创作后继 pack 时manifest 中要声明migration_from: {pack: parent, version: 1.x}并附带mapping_rules:在 retype / page_to_link / page_to_alias 三种 kind 上做判别联合。关键约束兜底哨兵from_type: *unknown*必须放在最后保证未知类型落入 catch-allsubtype_field被限制在ALLOWED_SUBTYPE_FIELDSsubtype, legacy_type, origin, format, kind, period, domain见 manifest-v1.ts——对应 codex D9 规则第三方 pack 不能注入title/slug/type字段防止恶意 pack 覆盖承载关键行为的字段。何时不要升级后继 pack 的 mapping_rules 未覆盖你的自定义类型先 fork 后继者gbrain schema fork gbrain-base-v2 my-pack编辑规则后再指向你的 fork摄入中或 autopilot 维护期间等待unify 会持有 db-lock 约 10 分钟联邦 brain 且有不希望触碰的 source用--params {sourceId: ...}按 source 限定范围。演进工作流全景综合以上约定一次规范的 schema 演进遵循这样的完整闭环发现gbrain schema detect找到高密度前缀簇 →gbrain schema suggest给出启发式候选 →gbrain schema review-candidates复核校验任何写操作前先gbrain schema lint --with-db捕获前缀冲突、悬空引用、ReDoS 正则等问题lint 现为 11 规则富校验见 lint-rules.ts决策按三档规模决策树选择「不打包 / alias / 收窄前缀 / 一等类型」执行add-alias、add-type、add-prefix或sync --apply回填复核gbrain schema stats观察各类型页面数与覆盖率确认dead_prefixes消除且无空类型持久化变更超过 50 次/7 天前就提交 pack 到 git规模化升级需要跨 pack 收敛时走onboard --check --explain预览 unify-types任务应用。这套工作流让 pack 演进既有明确的判断依据又有 lint 与引用检查两道程序化护栏从而同时满足「Agent 可整体掌握类型图」和「自定义领域获得一等类型」这两个看起来矛盾的目标。结语Schema 演进的核心不是「会加类型」而是「知道何时不该加」。三档规模决策树提供了快速判断框架五条 Donts 与expert_routing_without_prefix、extractable_empty_corpus、mutation_count_anomaly、STILL_REFERENCED等源码级守卫把「克制」变成了可执行的程序约束而migration_frommapping_rulesunify-types的引入则让 pack 自身也具备了可声明的生命周期。掌握本文的约定后任何 Agent 技能从 schema-author 到 schema-unify都能在修改活动 schema pack 之前做出正确、克制、可回滚的决策。赞分享人工智能RAGAgent 记忆MCP 服务知识管理【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址https://gitcode.com/gh_mirrors/gb/gbrain点击查看免费下载相关推荐gbrain 模式包Schema Pack演进决策指南何时新增 page_type、alias 还是 prefixgbrain 模式包Schema Pack演进决策指南何时新增 page_type、alias 还是 prefix gbrain 的 schema pac人工智能RAGAgent 记忆MCP 服务知识管理Sway 高级类型使用 Type Alias 为类型起别名告别冗长类型签名Sway 高级类型使用 Type Alias 为类型起别名告别冗长类型签名 本篇技术指南围绕 Sway 智能合约语言中的「类型别名Type Alias」编程语言编译器区块链Roc 编译器类型别名前向引用Type Alias Forward Reference快照测试深度解析Roc 编译器类型别名前向引用Type Alias Forward Reference快照测试深度解析 本文围绕 Roc 语言编译器测试仓库中的快照测试文档创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考