gbrain Correction Pipeline 实战指南从事实纠错到根因修复的八步闭环【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址: https://gitcode.com/gh_mirrors/gb/gbrain导读本指南基于 gbrain 开源仓库中的 skills/correction-pipeline/SKILL.md 展开系统讲解当用户指出 Agent 的事实错误时如何从简单记下改正升级为定位污染源、修复源头、阻断复发的根因处置流程。读者将掌握 gbrain 中脑库brain repo、记忆文件memory、身份文件SOUL.md/USER.md、事实表facts table四类数据源的排查顺序学会六种错误分类及其对应的修复面并理解与 maintain、soul-audit、citation-fixer 等相邻技能的去重边界。1. 技能定位这是一个无例外的响应契约correction-pipeline 是 gbrain 技能体系中少有的反应式REACTIVE技能它平时不主动运行而是在用户捕获到错误的那一刻被触发。技能 frontmatter 明确定义了触发短语集合triggers: - thats wrong - thats not true - I never said that - where did you get that - you got that wrong - correct that fact - root-cause this error技能的核心纪律只有一条任何用户识别出的事实错误都必须被根因分析而不是被记下来。文档中特别强调No exceptions. No Ill note that.——路由到本技能是 harness 层面的约定并非机械保证但一旦技能进入工作流这条无例外契约就是纪律本身。仓库中的 skills/correction-pipeline/routing-eval.jsonl 为该技能提供了路由评估夹具验证了触发边界正向意图必须包含至少一个触发字符串作为子串如Thats wrong — alice-example never worked at widget-co. Find out where you got that and fix it与 maintain 的歧义判定用户主动指出的过期错误路由到本技能而**无方向地要求找出过期页面**路由到 maintain负向边界引用格式问题路由到 citation-fixer代码 bug 则不匹配任何技能expected_skill: null。技能 frontmatter 还声明了mutating: true、writes_pages: true可写范围为people/、companies/、concepts/——这对应 skills/_brain-filing-rules.md 中按主要主题归档的目录约定也意味着纠错修复动作会真实改动脑库页面。2. 纠错的第一步反应先承认再引用最后陈述正确事实技能要求的三步立即响应是防止防御性反应的防线承认错误不辩解、不解释原因直接说Youre right. I got that wrong.引用具体错误论断让用户看到 Agent 精确知道自己错在哪里陈述正确事实按用户给出的原样复述。这一步刻意把为什么错推迟到根因分析阶段——反模式清单里明确禁止先解释为什么错再承认错误Defensive response。3. 八步根因分析按顺序执行每步都向用户汇报这是技能的主体。八步必须按顺序执行因为每一步都是在缩小污染源的候选范围。Step 1搜索脑库brain-first首先执行精确词搜索gbrain search relevant terms --limit 10对于概念形状或同义改写的主张升级到gbrain query questionLLM 展开能找回search漏掉的措辞。同时直接 grep 脑库仓库 checkout——先一次性从配置解析出脑库路径BRAIN_DIR$(gbrain config get sync.repo_path) grep -ri wrong claim terms $BRAIN_DIR/people/ $BRAIN_DIR/companies/ $BRAIN_DIR/concepts/ 2/dev/null判定问题错误事实是否在脑库中如果是 → 脑库就是污染源进入 Step 6 修复脑库页面。这一步与 skills/conventions/brain-first.md 中强制的查找链lookup chain完全一致精确已知 token/名称 →search廉价混合检索无展开概念/同义措辞 →query混合 LLM 展开命中 slug 后 →get_page读取完整编译真相。该约定文档还强调search的非零命中数不是完整性信号对于关于 X 是否都捕获了这类问题即使search已有命中也要跑query因为同义与结果措辞的匹配会静默丢失。脑库有成千上万页答案几乎总在里面。Step 2搜索记忆文件grep harness 常驻加载的记忆文件如工作区MEMORY.md及任何memory/*.md同伴文件确切位置取决于 harnessgrep -ri wrong claim terms memory files 2/dev/null判定问题错误事实是否在记忆中如果是 → 修复记忆文件。注意与 skills/conventions/brain-first.md 中的规则呼应永远不要用memory_search做实体查找——记忆工具搜索的是会话笔记MEMORY.md不是脑库知识图谱实体查找只能用search或query。这恰好解释了为什么记忆检查在脑库搜索之后记忆是易失的会话层脑库才是持久存储。Step 3检查 SOUL.md 与 USER.mdgrep -i relevant terms workspace/SOUL.md workspace/USER.md 2/dev/null判定问题是否存在可能误导错误推断的含糊段落SOUL.md 和 USER.md 出现在每一个上下文窗口里——这里一行含糊或歧义的描述会传播到每一次会话。关键警告在 gbrain 安装中这些文件是从 bootstrap 答案库state/interview.json渲染出来的。因此此处只记录发现修复必须走 Step 6 中的答案库路径绝不能直接编辑渲染产物。Step 4检查事实表gbrain recall entity-slug # 该主体的相关事实最新优先 gbrain recall --grep claim terms # 实体不明时用子串过滤记录错误事实的 fact id用于后续forget。gbrain 的 facts 表是独立的事实行存储层与脑库页面、记忆文件三者分离——这正是 Step 6 中不同错误类型对应不同修复面的原因。Step 5分类错误六种类型这是整个技能的核心决策表必须完整保留分类描述修复面BRAIN_ERROR脑库页面中存在错误事实在脑库仓库编辑页面、提交、重新 syncMEMORY_ERROR记忆文件中存在错误事实修复记忆文件SOUL_USER_ERRORSOUL.md 或 USER.md 中有误导性段落修复答案库、重新渲染——绝不改渲染文件FACTS_TABLE_ERRORgbrain 事实表中有错误事实recall→forget fact-id→remember正确事实HALLUCINATION无来源——LLM 从部分信号拼凑臆造指出污染向量哪些部分信号导致写入一条 guard 事实STALE_DATA事实曾经为真但现已过时用当前真相更新来源作废旧事实CROSS_CONTAMINATION关于 A 的正确事实被归到 B 名下修复来源中的归属——两个实体都要处理Step 6修复源头按分类对号入座BRAIN_ERROR在脑库仓库中编辑页面文件在修正行上标注[Source: user correction, YYYY-MM-DD]然后 commit再执行gbrain sync让数据库反映修复。只改数据库行而不改仓库文件或反之会让两者在下次 sync 覆盖其一之前处于不一致状态——这是双存储模型下的关键纪律对应 skills/_brain-filing-rules.md 中的强制内联引用格式[Source: User, {context}, YYYY-MM-DD]用户直接陈述属于最高权威来源。MEMORY_ERROR编辑记忆文件附加带日期的更正说明。SOUL_USER_ERROR绝不直接编辑 SOUL.md/USER.md——它们是渲染文件手改会在下次渲染时被静默丢弃。修复底层答案库后重新渲染gbrain bootstrap interview --set KEY corrected value # 逐字记录用用户的原话 gbrain bootstrap interview --show # 读回 gbrain bootstrap interview --status # 获取确认哈希 gbrain bootstrap interview --confirm hash gbrain bootstrap render --only SOUL.md --force # 按受影响文件逐个执行完整的访谈纪律读回仪式、逐字答案、备份行为在 skills/soul-audit/SKILL.md 中任何超出单键修复的操作都要路由到它。soul-audit 明确承诺--force会先把旧文件备份到.gbrain-bootstrap-backups/ts/没有任何内容会在无恢复副本的情况下被覆盖确认一个用户从未见过的答案集在设计中就会失败。FACTS_TABLE_ERROR作废错误行并写入带溯源的正确事实gbrain recall entity-slug # 找到 fact id gbrain forget fact-id # 作废错误事实 gbrain remember correct fact \ --provenance user correction, YYYY-MM-DD --entity entity-slugHALLUCINATION没有可修复的来源。找出播种臆造的部分信号写入 guard 使其无法再次播种gbrain remember WRONG: what was said. RIGHT: what is true. Guard: instruction to prevent recurrence \ --provenance user correction, YYYY-MM-DD (hallucination guard) --entity entity-slugSTALE_DATA按 BRAIN_ERROR 流程更新来源页面并用当前真相和新鲜溯源作废/重写过时事实行forgetremember。CROSS_CONTAMINATION修复来源中的归属然后同时检查两个实体A 的页面与事实事实是否已各归其位B 的页面与事实错误归属的痕迹是否全部清除。Step 7检查传播错误事实可能已扩散到其他脑库页面、综合产物synthesis output或记忆文件grep -ri wrong claim terms $BRAIN_DIR 2/dev/null | grep -v .git gbrain search wrong claim terms --limit 20修复所有实例而不是只修第一个。仓库编辑后要重新 sync。这一步对应 _brain-filing-rules.md 中实体传播是强制的Meeting-derived company info - ALSO updatecompanies/——错误同样会传播检查是闭环的一半。Step 8向用户汇报短报告格式**Error:** [what was wrong] **Root cause:** [BRAIN_ERROR | HALLUCINATION | etc.] **Source:** [specific file/line or fact id, or no source — confabulated from X] **Fixed:** [what was changed, where] **Propagation:** [other files fixed, or no propagation found]4. 严重级别分级决定响应速度级别描述处置S1 — 身份错误关于用户家庭、出身、历史、核心身份的错误事实立即修复。这些污染一切——每一次综合、每一本 book mirror、每一场对话S2 — 实体错误关于脑库中某个人、公司、deal 的错误事实修复脑库页面检查传播S3 — 上下文错误对用户当前状态、感受、处境做出的错误推断通过remember写入 guard 事实。通常是幻觉S4 — 轻微事实错误错误的日期、数字、细节修复源头无需传播检查分级的内在逻辑S1 身份错误处于上下文窗口的最深层SOUL/USER 渲染进每个会话影响面最大S4 局部错误影响面最小可跳过代价高昂的全脑传播检查。5. 需要警惕的复发错误模式模式示例Guard投射治疗性叙事你一直在回避与联合创始人的艰难对话无证据在断言用户行为或状态前先检查日历/行为数据把名字自动纠正成名人联系人 alice-example Cho 被静默替换成同名名人用户的熟人优先级高于世界名人——先用people/解析把 takes 当 facts把 takes 表信念倒进 factsTakes 他人的信念。Facts 用户个人的知识仅凭会话上下文做枚举性断言你工作过两家公司——漏掉了只记录在脑库中的那家绝不在未搜索脑库前做枚举性断言你的所有 X每一个 Y你三次 Z。会话上下文永远不完整常驻加载文件缺失数据某个核心事实只存在于脑库页面不在 USER.md/MEMORY.md于是每次会话都重新推导出错当纠错暴露常驻文件缺口时通过正确表面渲染文件走答案库、记忆文件直接编辑补齐数据使其进入未来每个上下文窗口6. 互补机制矛盾探针主动侧correction-pipeline 是反应式的——在用户捕获错误时才触发。仓库内置的矛盾探针则是同一纪律的主动侧在用户发现之前找出脑内冲突。gbrain eval suspected-contradictions # 运行探针 gbrain find-contradictions # 读取最近一次运行的发现如果某次纠错揭示了一类冲突例如两个页面在某个日期上不一致事后应运行探针——同一污染模式可能存在于脑库别处。从源码结构看该探针的实现在 src/core/eval-contradictions/runner.ts核心入口runContradictionProbe及 src/commands/eval-suspected-contradictions.ts、src/commands/doctor.ts 中并配套成本/趋势/健康检查模块说明其已被纳入 eval 与 doctor 体系。7. 技能契约与输出格式本技能保证每个事实错误都被根因分析而非仅仅记录源头修复落在该类错误真正对应的修复面页面编辑 提交 重新 sync事实行走forget/rememberSOUL/USER 走答案库 重新渲染——绝不直接编辑渲染文件传播被检查全脑 grep gbrain search用户收到清晰的报告什么错了、为什么错、修复了什么路由匹配 frontmatter 中的规范触发词隐私契约被保留无真实姓名、无 fork 特定文件系统路径字面量、无上游 fork 引用。输出格式技能的输出即 Step 8 的根因报告在对话过程中内联交付外加所有已落地的源头修复脑库仓库编辑已提交并重新 sync事实行已作废/取代身份文件已从答案库重新渲染。8. 去重边界与相邻技能的清晰划分skills/maintain/SKILL.md——主动脑库健康过期页面、孤儿、引用、doctor。本技能是反应式的某次具体用户纠错被追踪到污染源。如果没人说那错了就是 maintain 的领地。从 maintain 的技能正文可以看到其 autonomous pathgbrain doctor --remediation-plan/--remediate --target-score走的是一整套健康评分与修复计划与纠错链路完全正交矛盾探针gbrain eval suspected-contradictions/gbrain find-contradictions——主动脑内冲突检测。互补而不重叠探针发现两个脑库来源之间的冲突本技能从用户提供的纠错出发skills/soul-audit/SKILL.md——完整的身份重访谈表面。本技能对 SOUL_USER_ERROR 的修复委托给它绝不重新实现访谈或渲染流程skills/citation-fixer/SKILL.md——引用格式合规。修正某个主张的真假属于本技能修正一个真实主张的引用方式属于 citation-fixerfrontmatter-guard宿主侧——页面结构校验YAML 形状与主张真假无关。9. 反模式清单务必避免Noted, Ill remember that.不行。追溯来源修复来源。只修记忆不查脑库。脑库是持久存储记忆会被清空。直接编辑 SOUL.md / USER.md。它们从答案库渲染手改在下一次渲染时消失错误卷土重来。修答案再渲染。编辑脑库仓库文件后不重新 sync或改数据库行不提交。两个存储漂移下次 sync 会把错误复活。只修一个实例而不检查传播。错误事实会扩散。指责幻觉却不指出部分信号。每次幻觉都有种子——找到它。防御性回应。在承认错误之前永远不要解释为什么错。10. 实战心智模型为什么是根因而不是笔记把整个技能压缩成一句操作原则每个事实错误要么是数据错误坏脑库页面、坏记忆文件、坏渲染身份、坏事实行要么是幻觉LLM 从部分信号拼凑臆造——correction-pipeline 的职责就是无条件地判断属于哪一种然后在正确的修复面动手再验证传播最后给用户一份可审计的报告。这背后是 gbrain 的存储架构现实脑库页面git 仓库 数据库、facts 表、记忆文件、渲染身份文件是四套不同的真相载体它们的同步与一致性纪律脑库编辑必须 commit sync、身份文件只能改答案库再渲染决定了修复动作必须落在对应层面否则错误会在下一次同步或渲染时复活。对于 Agent 使用者而言可以在以下场景直接运用本文的方法论日常会话中被指出错误时立即走 Step 1→8 的根因链当纠错暴露常驻文件数据缺口时通过答案库或记忆编辑补齐当发现同类冲突反复出现时用矛盾探针主动扫描全脑。整个流程全部通过gbrainCLI 完成无需修改仓库本体即可独立运行验证。【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址: https://gitcode.com/gh_mirrors/gb/gbrain创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考