Busabase × Google Gemini CLIGemini CLI 知识库
终端任务可以恢复，但有价值的结果必须说清楚来源、证据和限制，经过审核后才能交给下一个 Agent。
三种本地产物
指令、恢复点和证据解决的是三种不同问题。
Gemini CLI 会按层级加载 GEMINI.md 上下文；开启 checkpointing 后，它可以在文件修改前保存本地 checkpoint，也会保留会话历史。这些能力服务当前运行，但不能单独证明实验成功，更不能证明结果已经适合复用。
实验台账
不保存整段终端记录，也能让每次结果可复现。
下一位执行者能够还原问题、输入、命令、环境、结果和限制，这条记录才真正有用。原始产物用链接关联，不要把所有日志都塞进一篇长笔记。
| 字段 | 需要记录什么 |
|---|---|
| hypothesis | 这次运行想验证什么？ |
| input_ref | 使用了哪个数据集、Issue、文件或来源？ |
| command | 执行了哪个明确任务或入口？ |
| environment | 适用哪个仓库、分支、模型或运行环境？ |
| result | 用白话说明发生了什么。 |
| evidence | 日志、输出文件、截图或测试在哪里？ |
| review_state | 提议中、审核中、已接受还是已拒绝？ |
| next_run | 下一次尝试应该改变什么？ |
一次运行也有生命周期
把执行进度和最终保留下来的主张分开。
交互运行和自动运行都会产生大量中间结果。在证据补齐、审核者接受结论之前，它们都只是工作材料。
定义问题和验收标准。
在已知环境中执行并保留产物。
用证据和限制概括结果。
检查可复现性，拒绝无依据主张。
让后续运行读取正式记录。
证据必须可检查
让结果和支持它的文件或输出放在一起。
Busabase 可以把结构化记录与文件、文档和 Skill 放在同一个工作区。Gemini CLI 先读取已接受摘要，只有当前任务需要细节时才打开原始产物。
- 主张
- 迁移已完成，未发生数据丢失。
- 证据
- Dry-run 报告、行数对比与验证输出。
- 限制
- 目前只在预发布数据集完成验证。
- 审核者
- 数据负责人接受该结果并允许进入下一阶段。
MCP 是传输层，不是信任模型
Gemini 的工具确认和 Busabase 的数据审核应该分开。
Gemini CLI 支持 Streamable HTTP MCP 和 OAuth discovery，也能筛选工具，并在服务器未被显式信任时请求确认。Busabase 补上另一层判断：工具调用成功，不等于它提出的值已经可以成为正式事实。
这个工具可以执行吗？
工具确认、include/exclude 清单、服务器信任
这个值应该成为正式事实吗？
Change Request、字段差异、审核者、合并历史
关于长期运行知识的问题
Gemini CLI 知识库常见问题
Busabase 会取代 GEMINI.md 吗？
不会。GEMINI.md 是随 Prompt 加载的操作上下文；Busabase 保存带字段、证据、负责人和变更历史的已审核结果。
Checkpoint 就是被接受的结果吗？
不是。Checkpoint 是本地恢复机制，可以还原文件和会话状态，但不能证明运行正确，也不能证明团队已经接受结果。
终端日志应该全部复制进 Base 吗？
通常不需要。保存简洁结果，把相关日志或输出文件作为证据关联起来，并让记录保持适合多次运行比较的结构。
自动运行可以提交记录吗？
可以，只要连接和权限允许。用稳定的 run key 去重；会影响共享知识的输出，合并权仍应留给审核者。
第一个工作流适合做什么？
选择可重复的研究或验证任务，例如依赖评估、迁移演练、基准审查、事故诊断或发布准备检查。
从一条值得复现的结果开始
给下一次 Gemini CLI 运行留下证据，而不是一堆终端记录。
建立一张小型实验表，关联原始输出，在结论成为下一次运行输入之前完成审核。