CommitLore
让编码代理只接收仍然有效的 Git 决策、约束与警告。
- Star 数
- ★ 18
- 最近更新
- 4 天前
- License
- MIT
- 主语言
- TypeScript
- FA 评分
- 89/100 · 表现良好
30 秒速览
- 可在哪里用
- 通用 · 跨平台Codex · Claude Code（部分支持）
- 开始前需要
- 典型场景
- 维护长期代码库的团队，可记录某项架构方案为何因隐藏约束而被否决，避免后续代理再次建议同一路线。
- 主要局限
- 捕获是辅助式流程，任何宿主都未被认证为会对每个符合条件的提交进行确定性评估。
- 源码审查
- 89/100 · 表现良好
这个 Agent 能做什么，适合哪些场景？
CommitLore 是面向编码代理的 Git 原生决策记忆系统，重点保存代码差异无法表达的约束、被否决方案和警告。它提供 CLI、提交钩子、Claude Code 与 Codex 插件，以及供其他受支持宿主使用的 MCP 接口。记录以 Git trailer 或 `refs/notes/commitlore` note 保存，SQLite 仅作为可重建索引，因此决策记录由仓库持有。系统按仓库路径和生命周期筛选记录，在代理编辑文件前仅交付仍处于 active 状态的相关内容，并按 directive、claim 或 blocked 标示信任等级。它适合需要避免代理重复提出已被否决方案的团队，但不是通用会话存档、用户记忆或向量数据库替代品。
端到端流程由 Capture、Verify、Preserve 和 Deliver 四步组成。commitlore capture 为代码差异无法保留的决策背景生成候选记录，并依据会话转录与已暂存 diff 进行检查；接受后的记录进入 Git trailer 或 refs/notes/commitlore。commitlore stale 区分 active、superseded 和 expired 记录，commitlore context 根据代理即将编辑的路径选择当前仍有效的记录。插件钩子或 MCP 在编辑前交付结果；内容会依据默认模式或签名模式被分级为 directive、claim 或 withheld，而交付本身不会阻止编辑。commitlore doctor 检查安装、旧钩子和 squash 继承等状态，commitlore coverage 则说明扫描覆盖范围。
- 维护长期代码库的团队，可记录某项架构方案为何因隐藏约束而被否决，避免后续代理再次建议同一路线。
- 使用 Claude Code 或 Codex 修改敏感模块的开发者，可在编辑前自动取得与目标路径有关的有效决策。
- 希望由仓库而非托管记忆服务控制工程知识的组织，可将记录保存在 Git trailer 或 notes 中并随代码审查和迁移。
- 需要管理决策变更的项目，可将旧记录标记为 superseded 或 expired，避免相关但已失效的内容被当作当前指令。
- 采用 GitHub Squash and merge 的团队，可配置
action/preserve，在分支提交被压缩时继承 CommitLore 记录。
如何安装或部署这个 Agent？
需要 Node.js 22.23.2 或更高版本以及 Git。macOS 和 Linux 可运行：
curl -fsSL https://raw.githubusercontent.com/MongLong0214/commitlore/v1.5.1/install.sh | sh -s v1.5.1Windows 可运行：
& ([scriptblock]::Create((irm https://raw.githubusercontent.com/MongLong0214/commitlore/v1.5.1/install.ps1))) v1.5.1Claude Code 的连接步骤是：
/plugin marketplace add MongLong0214/commitlore
/plugin install commitlore@commitloreCodex 的连接步骤是：
commitlore plugin install-codex插件不会把 commitlore 加入 PATH，因此仍需单独安装 CLI。安装或更新插件后应启动新的代理会话。
如何使用这个 Agent？
进入目标 Git 仓库，初始化 CommitLore，并先查询一次当前目录的上下文：
cd your-repository
commitlore init
commitlore context .之后照常工作和提交。受支持的 skill 集成会在普通提交请求中考虑是否需要保存决策；多数提交不应产生记录。若团队希望已接受的记录无需逐条确认即可暂存，可为仓库显式启用：
commitlore auto on该设置属于仓库级团队策略。若使用 GitHub 的 Squash and merge，还需按项目提供的工作流配置 action/preserve；本地 git merge --squash 则由 commitlore init 安装的 prepare-commit-msg 钩子处理。
这个 Agent 有哪些优点和局限？
- 记录保存在普通 Git trailer 或 notes 中；SQLite 只是可重建索引，不是唯一事实来源。
- 路径范围与 active、superseded、expired 生命周期过滤相结合，可防止已撤销决策继续作为当前指导交付。
- 区分 directive、claim 和 blocked，并提供需要 Git 验证及仓库本地 signer allowlist 的更强签名模式。
- 同时提供 CLI、提交钩子、Claude Code/Codex 插件和 MCP 路径，覆盖多种编码代理宿主。
- 公开的测量包含边界和负面结果；所述实验中，路径范围在固定两条记录预算下保留了 2/2 相关记录。
- 捕获是辅助式流程，任何宿主都未被认证为会对每个符合条件的提交进行确定性评估。
- Node.js 22.23.2+ 与 Git 是硬性运行要求，插件安装也不能替代 CLI 安装。
- Git notes 默认不会随普通 clone 获取；必须通过
commitlore init配置refs/notes/commitlore镜像。 - GitHub Squash and merge 会丢失分支 trailer，必须额外部署具有
contents: write权限的保留 Action。 - 编辑前钩子也会在 Read 等工具调用时触发，每次匹配调用最多消耗配置的上下文预算；默认上限为 800 tokens。
- 公开效果数据来自有限模型、单一工具链或构造任务，不能证明所有模型都会读取或遵循交付的记录。
这个 Agent 与同类方案有什么区别？
通用记忆或 RAG 主要检索语义上相关的旧文本；CommitLore 询问的是哪些决策现在仍适用于特定仓库路径。它以 Git 为权威来源，显式管理 active、superseded、expired 生命周期，并对交付内容划分 directive、claim 和 blocked，而不是把所有相关文本直接当作当前指导。相应地，它的范围更窄，不适合作为会话归档、通用用户记忆或向量数据库的替代品。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|
| CommitLore 当前 | 89 · 表现良好 | ★ 18 | 4 天前 | TypeScript | — |
| PowerContext | 55 · 缺口较多 | ★ 1.1k | 4 天前 | Python | Codex · Claude Code |
| Puppyone 上下文驱动器 | 39 · 缺口较多 | ★ 1.3k | 3 个月前 | TypeScript | ChatGPT · Claude Code |
| Tura | 65 · 存在缺口 | ★ 641 | 11 天前 | Rust | — |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
证据显示产品以仓库本地 Git trailer、notes 和可重建 SQLite 索引为核心，不依赖托管记忆服务；工作流使用显式最小权限，并把执行贡献者代码与持有发布凭据的作业隔离。README 和 SECURITY.md 清楚说明记录如何进入 Git、如何传给宿主、默认作者匹配并非认证、签名模式如何 fail-closed，以及宿主收到内容后数据不再受 CommitLore 控制。敏感内容在暂存前扫描，疑似注入内容会被阻止进入模型可读路径；CI 对生产依赖执行零阈值审计，第三方 Actions 多数固定到提交。外部写入、notes 推送、hook 链接和 PR 评论均有明确描述，原 hook 可由卸载恢复，索引也可删除重建。扣分在于 auto 模式一经仓库级启用便可不逐条确认，因而用户确认并非全程强制；npm 依赖采用范围版本且开发依赖审计不阻断；来源和许可证清楚，但发布者身份未由给定材料独立验证。
README、SECURITY.md、package.json、CI 和测试对存储模型、信任等级、安装形态及 GitHub Action 行为基本一致。CI 明确检查支持的 Node 下限与当前 LTS、Git 平台差异、完整历史、notes mirror、独立 clone、已打包入口、测试文件实际执行情况和机器可验证的文档数字；测试还覆盖浅克隆、缺失分支、只读令牌、远端拒绝及非权限错误等失败路径，并提供具体错误提示。扣分仅在依赖可用性：需要较新的 Node 22.23.2+、Git 和可访问的 GitHub 源码标签，项目为 private npm package、没有注册表回退，notes 也不会随普通 clone 自动获取，这些都会增加普通环境中的可用性风险。
文档分别覆盖 Claude Code、Codex、Hermes、MCP 型宿主、AGENTS.md 宿主、macOS、Linux、Windows、squash merge 与不同信任模式，并明确产品不是通用记忆、会话归档或向量数据库。能力边界尤其清晰，包括 capture 非确定性、delivery 不阻止编辑、部分覆盖、notes 获取限制、guard 的低精度/召回率及默认 directive 的弱认证语义。扣分在触发精度：作者明确承认没有宿主能保证每个合格 commit 都被评估，编辑前 hook 还会在多类工具调用上频繁触发。环境适配扣分是因为给定 CI 主要证明 Linux/macOS，Windows 虽有安装命令却没有同等静态测试证据，且严格的 Node 版本和 notes 配置提高接入门槛。
README 具有清楚的快速开始、能力矩阵、工作原理、限制、证据和文档索引；安装命令固定到 v1.5.1，并解释无脚本安装、升级、卸载、会话重启、hook 链接和 squash 配置。协议术语、命令、记录字段与 package 版本命名稳定且有测试约束；示例和常见边界丰富，限制披露具体。MIT 元数据与完整 LICENSE 一致。扣分在版本与维护：材料显示 release 链接、当前版本、稳定协议和仅支持最新发布版，但未提供完整 changelog；有私密漏洞报告、响应预期和 issue 路径，却没有独立可验证的维护团队、接班安排或明确多人责任分工。
输出按 path、lifecycle 和 trust grade 筛选，并展示限制、被拒方案、警告、记录 ID 与提交标识，适合在编辑前直接使用；部分结果和截断会显式标记。相较普通全文记忆，它提供 Git 所有权、生命周期淘汰、路径范围和信任分级，边际价值具体。成本收益也有量化且克制的材料：给出重提率、retired record 泄漏、100k commit 查询和 token exposure 数据，同时公开单一模型、单一 corpus、固定预算等边界，并说明每次 hook 最多 800 token、无记录时无消耗。满分依据是静态材料对效用和成本均有可追踪说明；这不代表本次审查执行或复现了结果。
主要主张可追到具体命令、协议字段、配置项、CI gate、测试断言和 benchmark 结果文件生成流程。README 的安全、安装、能力和证据声明得到 SECURITY.md、package.json、两个工作流及 Action 测试的交叉支撑；CI 还要求 README 数字可再生成、规范示例保持同步、测试文件不得静默漏跑。事实与推断区分尤其明确：现场报告被标注为非测量，agent study 不被外推，delivery 不等于模型阅读或服从，guard 空结果不等于安全，默认作者匹配不被称作认证。基于所给静态文件，这三项没有可指出的实质缺口；但低置信度仍表示未执行任何测试或独立复现。
- 本次仅依据所给文件进行静态审查，未执行安装程序、CLI、测试、benchmark 或 GitHub Actions。
- 默认 author-string directive 模式不能抵抗能够提交代码的攻击者；高信任仓库应启用签名要求并维护 trustedSigner allowlist。
- 启用仓库级 auto 模式后，记录可不经逐条确认被暂存；采用前应审查团队策略、hook 变更和写入 Git 历史的后果。
- 普通 clone 不会自动取得 refs/notes/commitlore；若初始化或 mirror 配置缺失，上下文可能不完整。
- GitHub pull_request_target 示例持有 contents:write；必须继续遵守不检出、不执行 fork head 内容的约束。
- 安装依赖固定 GitHub 标签和较新的 Node 版本，且没有 npm registry 回退；应评估源可用性、供应链固定策略和升级流程。
常见问题
没有任何决策记录的仓库会持续消耗上下文吗？
默认的 directive 能证明作者身份吗？
commitlore.trustedSigner allowlist；allowlist 缺失、为空或不可读时不会授权任何人。删除 SQLite 索引会丢失决策吗？
普通 clone 一定包含全部记录吗？
refs/notes/*；运行 commitlore init 后才会配置 notes 镜像。部分扫描的缺失结果也不能证明记录不存在，可用 commitlore coverage 检查覆盖范围。