尧图网站建设 
gbrain Agent Bootstrap Spike门控 Codex 桌面版发布的验证仪器与通过标准【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址: https://gitcode.com/gh_mirrors/gb/gbrain本文档位于仓库docs/designs/AGENT_BOOTSTRAP_SPIKE.md是 gbrain 的 Agent Bootstrap 项目gbrain bootstrap系列在构建开始之前build order 0必须执行的人工验证仪器。它的任务是回答五个带通过标准的退出问题——特别是阻断性的写入缝隙write seam——从而为 door-1Codex/ChatGPT 桌面版是否可以从文档化 beta升级为完整发布提供客观依据。读完本文你将理解这套 spike 的协议设计、每条通过标准背后的产品逻辑以及它的结论如何落到gbrain bootstrap的实际源码实现中。一、为什么需要 Spike构建之前的线上真相Agent Bootstrap 的产品设想是在用户已经拥有的桌面工具Claude Code、Codex之上通过一次粘贴安装注入身份SOUL.md/USER.md、记忆、技能、会话触发的调度与私有仓库持久化从而把本地 harness 当作你的 agent使用而不必部署服务器、配置 API key 或按 token 原价付费。但在写任何一行构建代码之前方案面临一个基础性的事实问题这些桌面表面surface是否真的能承载每回合/每会话可靠地写入记忆这一核心承诺ChatGPT 桌面版中的 Codex 并不是为持久化记忆设计的宿主——它有没有可用的写入缝隙、读取缝隙、配额余量全部是未经验证的事实。因此设计文档把 spike 定为整个构建顺序的第 0 步并明确其性质人工验证仪器manual validation不是自动化测试刻意不引入任何遥测no telemetry门控 door-1 发布gates door-1 shipspike 结果低于通过标准door-1 就降级为文档化 betaCodex CLI 不受影响运行环境一台维护者不拥有的机器 全新账号——目的是排除只有维护者本人机器能跑通的幸存者偏差负责人维护者本人时间盒约 1 周墙钟时间输出喂给设计文档的门控决策AGENT_BOOTSTRAP_DESIGN.md。这与源码中verify 永不与宿主的 live serve 对话、用调用方持有的 engine 完成全部检查verify.ts 的 CX2-5 确定性原则是同一哲学的一体两面先证明缝隙真实存在再谈论可靠性。二、五个退出问题Exit Questions与通过标准spike 的核心是五个退出问题每个都配有可量化的通过标准pass bar。这是全文最需要原样保留的部分——它们是门控决策的唯一依据。#1阻断性——写入缝隙什么能在 ChatGPT 桌面表面可靠地持久化记忆这是唯一标记为 blocking的问题。协议与通过标准协议在 ≥3 天的普通使用中运行20 个会话每个会话必须产生至少一次持久化写入一个 page/事实能在下一个会话中被检索到。通过标准20 个会话中0 次持久化写入失败否则延长到 50 个会话并记录每一次失败的成因crash、休眠、审批摩擦、格式漂移、模型遗忘。未达标后果door-1 降级为文档化 betaCodex CLI 不受影响。这条标准的用意在于写入缝隙是把桌面 harness 当 agent 用的地基。如果记忆不能跨会话存活下次会话还记得你的核心体验design Premise 4 的day-one magic moment就不成立。失败的成因分类crash / sleep / approval friction / format drift / model forgot本身就指向后续构建中需要攻克的工程点——例如 approve tap 的审批流程、session 转录的格式解析、以及模型忘了写要靠 hook 兜底。#2——读取缝隙注入/拉取的上下文在回合开始时是否确实在场通过标准上下文块context block在回合开始时确实存在或者退化的拉取模式被文档化为 door-1 的 v1 行为。附带收益通过则把问候摘要greeting digest会话开始时注入的最近发生了什么扩展到 door-1。读取缝隙决定 agent 能否带着记忆进入每个回合。这一条允许一个诚实的退化选项——如果 ChatGPT 桌面表面没有回合级注入能力就把每回合拉取pull protocol写进文档作为 v1 行为而不是假装有推送push能力。#3——能力表面逐项记录并截图需要记录的能力项记录方式截图 是/否/如何本地文件夹访问yes/no/howMCP 注册路径配置文件codex mcp addUI每个工具链步骤的审批点击次数approval taps逐一计数邮件/日历连接器可用性yes/no/degraded。这一条为后续 build order 2Codex door 发布的 runbook 变体提供事实输入审批点击次数直接决定 runbook 要写多少个你会被询问的警告也直接进入 #5 的 TTFM 统计。#4——配额每个 harness 的用量计量计量对象door 运行的每个 harness——Claude Code 用 Max plan、Codex 用 ChatGPT plan每天记录 pilot 期间的用量表读数。负载模型普通会话 hooks 一个会话触发的调度session-triggered schedule。通过标准p90 的一天消耗 ≤ 每周配额的 10%按 door 分别计量一个 harness 未达标只会削减该 door 的调度范围。测量方式harness 自己的用量 UI每天开始/结束时截图 从 transcript 目录统计会话/回合数。无遥测——这个仪器设计上就是手动的。配额的通过与失败有明确的连锁后果失败即scope change to session-agent, no schedules by default——在投入调度功能的构建成本之前就削减范围。这与设计文档的honesty check配额数字必须公开、桌面契约必须在产品内声明一致。#5——TTFM 基线一次完整的粘贴到验证安装计时计时一次从粘贴到验证安装的完整流程全程计时计数每一个人类动作paste / auth click / 面试回答 / 同意 / 审批点击排除项工具链下载时间单独记录不计入 15 分钟目标。15 分钟目标TTFM ≤15 min是设计文档的成功标准之一paste→verified installexcluding first-run toolchain downloadspublished separatelyevery human action counted。工具链下载被单独记录的原因很实际首次下载 bun/gh 等工具的时间不可控把它排除后才能让 TTFM 指标真正反映安装流程本身的质量。三、通过标准背后的门控决策模型spike 的结论不是过/不过二元判断而是三态门控最终记录在设计文档中决策触发条件door-1 完整发布ships full五个退出问题全部达标尤其是 #1 的 0/20 通过标准door-1 以文档化 beta 发布documented beta写入缝隙低于通过标准#1 未过或其他能力项处于 degraded 状态且有文档化兜底按配额削减调度范围schedule scope cut per quota#4 配额未达标仅削减该 door 的调度范围不影响其他 door这个三态模型贯穿到源码层bootstrap verify的每个检查都是FAIL-SOFT 且收集式collected的——探针抛错会变成带 detail 的失败检查项而不是未捕获异常verify.ts 头部注释runbook 会把整份报告原样粘贴给人类。也就是说诚实降级不是 spike 独有的姿态而是整个 bootstrap 产品的编码约定。四、从 Spike 到 Pilot两周试点指标spike 只是最小样本不是证明。0-failures-in-20 只是开始 pilot 的最低门槛pilot 本身才是样本。spike 通过后继续运行2 周 pilot每周从会话复盘屏幕录像 自我报告仍然无遥测采集四个指标correct-write rate正确写入率值得记住的东西中有多少真的被写入了correct-recall rate正确召回率召回中真正正确的比例false-memory incidents错误记忆事件被召回但实际是错误的内容次数correction round-trips纠正回路纠正之后是否固化为长期规则standing rules。这四类指标与源码中的记忆模型一一对应纠正回路对应 MEMORY.md 模板中的corrections format- YYYY-MM-DD — rule (...)false-memory 对应 fact 读取时的visibility: [world]过滤IPC 路径绝不比 MCP 返回更宽见 verify.ts 与设计文档 S3#1写入率对应put_page→sweep→ 图查询的真实 MCP 写入路径。五、会话日志模板每会话一行spike 期间使用如下日志模板每个会话填一行#datedoordurationwrites attemptedwrites durablerecalls right/wrongapprovalsnotes12这一行的字段直接对应退出问题#1 的 writes attempted / writes durable、#3 的 approvals、#5 的 duration。日志是人工填写的刻意保持一 session 一行的极简形状降低填写摩擦——填起来麻烦的日志仪器最终不会有人填。六、交付物与门控记录spike 结束时必须提交一份填写完毕的本文档副本作为AGENT_BOOTSTRAP_SPIKE_RESULTS.md提交注意清理除维护者本人外不得出现真实姓名不得出现账号标识符门控决策记录在设计文档中door-1 是完整发布 / 文档化 beta / 按配额削减调度范围。当前门控状态尚未运行——仓库中不存在已提交的AGENT_BOOTSTRAP_SPIKE_RESULTS.md因此没有门控决策记录door-1 也未被该仪器提升到文档化 beta 之上。该行在结果落地时更新。七、与实现层的呼应spike 的结论如何在代码中兑现spike 虽然是构建前的人工仪器但它问出的每个问题在gbrain bootstrap的源码里都有对应的自动化投影。理解这种投影能帮你判断 spike 结果一旦落地会如何影响产品形态#1 写入缝隙 →verify.ts的确定性检查。bootstrap verify断言一个走真实 MCP 路径的put_page会在brain/下物化一个已提交的文件——绿色 verify 配空仓库是不可能的设计文档 G1magic moment事实通过## Factsfence 写入探针页再由 sweep 的零 LLMfence 通过程序化落库keyless 模式也成立然后以visibilityworld读回VERIFY_MAGIC_TOKEN固定探针令牌verify.ts。#2 读取缝隙 → turn_context IPC。会话开始/每回合的上下文由 hook 层经resolve-ipc.ts的 unix socket 请求服务端装配spike 若发现 ChatGPT 桌面没有回合级触发调度功能就变成 Claude-Code-only设计文档 build order 3 的显式条件分支。#3 能力表面 → host-specs 与 hooks 探测。MCP 注册路径、审批流程、连接器可用性在代码中以host-specs.tsTARGETS 条目携带 id/status/verifiedAt/references见 host-specs.ts和 verify 的 capability 报告呈现detectCapabilities/renderCapabilityReport输出诚实的keyless 模式能力清单。#4 配额 → 产品范围开关。配额未达标导致session-agent, no schedules by default这一范围削减在设计与计划文档中是预先写好的决策不是事后补救测量先以脚本文档形态交付gbrain quota计量命令被推迟到 TODOS见 AGENT_BOOTSTRAP_PLAN.md。#5 TTFM → 相位清单与安装日志。gbrain bootstrap status定义唯一权威的八相位清单preflight → engine → interview → render → skills → wire → repo → verifyBOOTSTRAP_PHASE_IDS见 status.ts每次子命令调用追加一行到install.jsonl遥测runbook 指示 agent 严格跟随这份相位清单与 spike计数每个人类动作形成对照——安装流程的每一步都是可观测、可恢复的。此外spike 的全新账号 非维护者机器要求在实现中对应着--isolated模式与GBRAIN_HOME语义收口单点ensureGbrainHome()、bootstrap attach的机器二克隆路径以及bootstrap status的 runbook 版本戳校验supply-chain skew check。八、总结一个先验证缝隙再构建产品的模板AGENT_BOOTSTRAP_SPIKE.md的价值不在于它长而在于它把这个产品到底能不能成立拆成了五个可证伪的问题并且每个问题都带数值化的通过标准与诚实的失败路径。它的三个设计要点值得在类似项目里复用阻断性问题前置写入缝隙#1是唯一 blocking 项先于一切构建决策三态门控而非二元判断完整发布 / 文档化 beta / 按配额削减范围失败也有一条体面的降级路径仪器本身刻意无遥测spike 与 pilot 都用人工记录把测量手段的复杂度压到最低避免用一个本身需要验证的遥测系统去验证另一个系统。相关文档与实现入口AGENT_BOOTSTRAP_DESIGN.md产品设计与门控归属、AGENT_BOOTSTRAP_PLAN.md实现规范含 spike 门控的工程化、BOOTSTRAP_FOR_AGENTS.mdspike 通过后由粘贴块拉取的运行手册、verify.ts 与 status.ts验证与状态检测的实现、questions.json12 问/6 必答的面试题库。截至当前仓库状态spike 尚未运行AGENT_BOOTSTRAP_SPIKE_RESULTS.md尚未提交door-1 仍处于文档化 beta 门槛之下。【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址: https://gitcode.com/gh_mirrors/gb/gbrain创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 gbrain Agent Bootstrap Spike：门控 Codex 桌面版发布的验证仪器与通过标准
gbrain Agent Bootstrap Spike门控 Codex 桌面版发布的验证仪器与通过标准【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址: https://gitcode.com/gh_mirrors/gb/gbrain本文档位于仓库docs/designs/AGENT_BOOTSTRAP_SPIKE.md是 gbrain 的 Agent Bootstrap 项目gbrain bootstrap系列在构建开始之前build order 0必须执行的人工验证仪器。它的任务是回答五个带通过标准的退出问题——特别是阻断性的写入缝隙write seam——从而为 door-1Codex/ChatGPT 桌面版是否可以从文档化 beta升级为完整发布提供客观依据。读完本文你将理解这套 spike 的协议设计、每条通过标准背后的产品逻辑以及它的结论如何落到gbrain bootstrap的实际源码实现中。一、为什么需要 Spike构建之前的线上真相Agent Bootstrap 的产品设想是在用户已经拥有的桌面工具Claude Code、Codex之上通过一次粘贴安装注入身份SOUL.md/USER.md、记忆、技能、会话触发的调度与私有仓库持久化从而把本地 harness 当作你的 agent使用而不必部署服务器、配置 API key 或按 token 原价付费。但在写任何一行构建代码之前方案面临一个基础性的事实问题这些桌面表面surface是否真的能承载每回合/每会话可靠地写入记忆这一核心承诺ChatGPT 桌面版中的 Codex 并不是为持久化记忆设计的宿主——它有没有可用的写入缝隙、读取缝隙、配额余量全部是未经验证的事实。因此设计文档把 spike 定为整个构建顺序的第 0 步并明确其性质人工验证仪器manual validation不是自动化测试刻意不引入任何遥测no telemetry门控 door-1 发布gates door-1 shipspike 结果低于通过标准door-1 就降级为文档化 betaCodex CLI 不受影响运行环境一台维护者不拥有的机器 全新账号——目的是排除只有维护者本人机器能跑通的幸存者偏差负责人维护者本人时间盒约 1 周墙钟时间输出喂给设计文档的门控决策AGENT_BOOTSTRAP_DESIGN.md。这与源码中verify 永不与宿主的 live serve 对话、用调用方持有的 engine 完成全部检查verify.ts 的 CX2-5 确定性原则是同一哲学的一体两面先证明缝隙真实存在再谈论可靠性。二、五个退出问题Exit Questions与通过标准spike 的核心是五个退出问题每个都配有可量化的通过标准pass bar。这是全文最需要原样保留的部分——它们是门控决策的唯一依据。#1阻断性——写入缝隙什么能在 ChatGPT 桌面表面可靠地持久化记忆这是唯一标记为 blocking的问题。协议与通过标准协议在 ≥3 天的普通使用中运行20 个会话每个会话必须产生至少一次持久化写入一个 page/事实能在下一个会话中被检索到。通过标准20 个会话中0 次持久化写入失败否则延长到 50 个会话并记录每一次失败的成因crash、休眠、审批摩擦、格式漂移、模型遗忘。未达标后果door-1 降级为文档化 betaCodex CLI 不受影响。这条标准的用意在于写入缝隙是把桌面 harness 当 agent 用的地基。如果记忆不能跨会话存活下次会话还记得你的核心体验design Premise 4 的day-one magic moment就不成立。失败的成因分类crash / sleep / approval friction / format drift / model forgot本身就指向后续构建中需要攻克的工程点——例如 approve tap 的审批流程、session 转录的格式解析、以及模型忘了写要靠 hook 兜底。#2——读取缝隙注入/拉取的上下文在回合开始时是否确实在场通过标准上下文块context block在回合开始时确实存在或者退化的拉取模式被文档化为 door-1 的 v1 行为。附带收益通过则把问候摘要greeting digest会话开始时注入的最近发生了什么扩展到 door-1。读取缝隙决定 agent 能否带着记忆进入每个回合。这一条允许一个诚实的退化选项——如果 ChatGPT 桌面表面没有回合级注入能力就把每回合拉取pull protocol写进文档作为 v1 行为而不是假装有推送push能力。#3——能力表面逐项记录并截图需要记录的能力项记录方式截图 是/否/如何本地文件夹访问yes/no/howMCP 注册路径配置文件codex mcp addUI每个工具链步骤的审批点击次数approval taps逐一计数邮件/日历连接器可用性yes/no/degraded。这一条为后续 build order 2Codex door 发布的 runbook 变体提供事实输入审批点击次数直接决定 runbook 要写多少个你会被询问的警告也直接进入 #5 的 TTFM 统计。#4——配额每个 harness 的用量计量计量对象door 运行的每个 harness——Claude Code 用 Max plan、Codex 用 ChatGPT plan每天记录 pilot 期间的用量表读数。负载模型普通会话 hooks 一个会话触发的调度session-triggered schedule。通过标准p90 的一天消耗 ≤ 每周配额的 10%按 door 分别计量一个 harness 未达标只会削减该 door 的调度范围。测量方式harness 自己的用量 UI每天开始/结束时截图 从 transcript 目录统计会话/回合数。无遥测——这个仪器设计上就是手动的。配额的通过与失败有明确的连锁后果失败即scope change to session-agent, no schedules by default——在投入调度功能的构建成本之前就削减范围。这与设计文档的honesty check配额数字必须公开、桌面契约必须在产品内声明一致。#5——TTFM 基线一次完整的粘贴到验证安装计时计时一次从粘贴到验证安装的完整流程全程计时计数每一个人类动作paste / auth click / 面试回答 / 同意 / 审批点击排除项工具链下载时间单独记录不计入 15 分钟目标。15 分钟目标TTFM ≤15 min是设计文档的成功标准之一paste→verified installexcluding first-run toolchain downloadspublished separatelyevery human action counted。工具链下载被单独记录的原因很实际首次下载 bun/gh 等工具的时间不可控把它排除后才能让 TTFM 指标真正反映安装流程本身的质量。三、通过标准背后的门控决策模型spike 的结论不是过/不过二元判断而是三态门控最终记录在设计文档中决策触发条件door-1 完整发布ships full五个退出问题全部达标尤其是 #1 的 0/20 通过标准door-1 以文档化 beta 发布documented beta写入缝隙低于通过标准#1 未过或其他能力项处于 degraded 状态且有文档化兜底按配额削减调度范围schedule scope cut per quota#4 配额未达标仅削减该 door 的调度范围不影响其他 door这个三态模型贯穿到源码层bootstrap verify的每个检查都是FAIL-SOFT 且收集式collected的——探针抛错会变成带 detail 的失败检查项而不是未捕获异常verify.ts 头部注释runbook 会把整份报告原样粘贴给人类。也就是说诚实降级不是 spike 独有的姿态而是整个 bootstrap 产品的编码约定。四、从 Spike 到 Pilot两周试点指标spike 只是最小样本不是证明。0-failures-in-20 只是开始 pilot 的最低门槛pilot 本身才是样本。spike 通过后继续运行2 周 pilot每周从会话复盘屏幕录像 自我报告仍然无遥测采集四个指标correct-write rate正确写入率值得记住的东西中有多少真的被写入了correct-recall rate正确召回率召回中真正正确的比例false-memory incidents错误记忆事件被召回但实际是错误的内容次数correction round-trips纠正回路纠正之后是否固化为长期规则standing rules。这四类指标与源码中的记忆模型一一对应纠正回路对应 MEMORY.md 模板中的corrections format- YYYY-MM-DD — rule (...)false-memory 对应 fact 读取时的visibility: [world]过滤IPC 路径绝不比 MCP 返回更宽见 verify.ts 与设计文档 S3#1写入率对应put_page→sweep→ 图查询的真实 MCP 写入路径。五、会话日志模板每会话一行spike 期间使用如下日志模板每个会话填一行#datedoordurationwrites attemptedwrites durablerecalls right/wrongapprovalsnotes12这一行的字段直接对应退出问题#1 的 writes attempted / writes durable、#3 的 approvals、#5 的 duration。日志是人工填写的刻意保持一 session 一行的极简形状降低填写摩擦——填起来麻烦的日志仪器最终不会有人填。六、交付物与门控记录spike 结束时必须提交一份填写完毕的本文档副本作为AGENT_BOOTSTRAP_SPIKE_RESULTS.md提交注意清理除维护者本人外不得出现真实姓名不得出现账号标识符门控决策记录在设计文档中door-1 是完整发布 / 文档化 beta / 按配额削减调度范围。当前门控状态尚未运行——仓库中不存在已提交的AGENT_BOOTSTRAP_SPIKE_RESULTS.md因此没有门控决策记录door-1 也未被该仪器提升到文档化 beta 之上。该行在结果落地时更新。七、与实现层的呼应spike 的结论如何在代码中兑现spike 虽然是构建前的人工仪器但它问出的每个问题在gbrain bootstrap的源码里都有对应的自动化投影。理解这种投影能帮你判断 spike 结果一旦落地会如何影响产品形态#1 写入缝隙 →verify.ts的确定性检查。bootstrap verify断言一个走真实 MCP 路径的put_page会在brain/下物化一个已提交的文件——绿色 verify 配空仓库是不可能的设计文档 G1magic moment事实通过## Factsfence 写入探针页再由 sweep 的零 LLMfence 通过程序化落库keyless 模式也成立然后以visibilityworld读回VERIFY_MAGIC_TOKEN固定探针令牌verify.ts。#2 读取缝隙 → turn_context IPC。会话开始/每回合的上下文由 hook 层经resolve-ipc.ts的 unix socket 请求服务端装配spike 若发现 ChatGPT 桌面没有回合级触发调度功能就变成 Claude-Code-only设计文档 build order 3 的显式条件分支。#3 能力表面 → host-specs 与 hooks 探测。MCP 注册路径、审批流程、连接器可用性在代码中以host-specs.tsTARGETS 条目携带 id/status/verifiedAt/references见 host-specs.ts和 verify 的 capability 报告呈现detectCapabilities/renderCapabilityReport输出诚实的keyless 模式能力清单。#4 配额 → 产品范围开关。配额未达标导致session-agent, no schedules by default这一范围削减在设计与计划文档中是预先写好的决策不是事后补救测量先以脚本文档形态交付gbrain quota计量命令被推迟到 TODOS见 AGENT_BOOTSTRAP_PLAN.md。#5 TTFM → 相位清单与安装日志。gbrain bootstrap status定义唯一权威的八相位清单preflight → engine → interview → render → skills → wire → repo → verifyBOOTSTRAP_PHASE_IDS见 status.ts每次子命令调用追加一行到install.jsonl遥测runbook 指示 agent 严格跟随这份相位清单与 spike计数每个人类动作形成对照——安装流程的每一步都是可观测、可恢复的。此外spike 的全新账号 非维护者机器要求在实现中对应着--isolated模式与GBRAIN_HOME语义收口单点ensureGbrainHome()、bootstrap attach的机器二克隆路径以及bootstrap status的 runbook 版本戳校验supply-chain skew check。八、总结一个先验证缝隙再构建产品的模板AGENT_BOOTSTRAP_SPIKE.md的价值不在于它长而在于它把这个产品到底能不能成立拆成了五个可证伪的问题并且每个问题都带数值化的通过标准与诚实的失败路径。它的三个设计要点值得在类似项目里复用阻断性问题前置写入缝隙#1是唯一 blocking 项先于一切构建决策三态门控而非二元判断完整发布 / 文档化 beta / 按配额削减范围失败也有一条体面的降级路径仪器本身刻意无遥测spike 与 pilot 都用人工记录把测量手段的复杂度压到最低避免用一个本身需要验证的遥测系统去验证另一个系统。相关文档与实现入口AGENT_BOOTSTRAP_DESIGN.md产品设计与门控归属、AGENT_BOOTSTRAP_PLAN.md实现规范含 spike 门控的工程化、BOOTSTRAP_FOR_AGENTS.mdspike 通过后由粘贴块拉取的运行手册、verify.ts 与 status.ts验证与状态检测的实现、questions.json12 问/6 必答的面试题库。截至当前仓库状态spike 尚未运行AGENT_BOOTSTRAP_SPIKE_RESULTS.md尚未提交door-1 仍处于文档化 beta 门槛之下。【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址: https://gitcode.com/gh_mirrors/gb/gbrain创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考