Edda：把 agent 的决定写进本地防篡改账本
用 coding agent 久了之后，会遇到一个很具体的摩擦：不是模型不会改代码，而是它很容易忘掉“为什么这么改”。昨天你和它讨论过一个架构选择，今天新 session 重新打开，它又从零开始提出另一个方案。更麻烦的是，当你同时跑两个 agent，一个负责实现，一个负责 review，它们之间对“谁在改哪里、哪个任务真的做完了”也没有天然的共享状态。
今天看的是 fagemx/edda。它把这个问题收敛成一个本地 primitive：在工作区旁边维护 .edda/，用 append-only、hash-chained 的 SQLite ledger 记录 decisions、notes、session digests、tasks、verdicts 和 command outputs；同时用 per-user store 维护 live coordination state，比如 claims 和 heartbeat。它支持 Claude Code、Cursor、Codex、OpenClaw，也提供 MCP server。
按 GitHub repository API、README、Cargo.toml、release page、tags、latest commit 和 LICENSE 在 2026-09-04 18:06 Asia/Shanghai 能核验的信息，fagemx/edda 当前有 36 stars、2 forks。主要语言是 Rust，GitHub API license 字段是 Apache-2.0，README 和 Cargo.toml 声明 MIT OR Apache-2.0。默认分支是 main，仓库创建于 2026-02-19 11:08:05 UTC，latest push 是 2026-09-04 10:01:01 UTC。最新提交是 9de7662，提交时间 2026-09-04 10:00:47 UTC，提交信息是 docs(cli): dispatch networked Codex via edda, not the plugin sandbox (#861)。最新 GitHub Release 是 v0.4.0，发布时间 2026-09-02 05:38:34 UTC；Cargo.toml workspace version 也是 0.4.0。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | fagemx/edda |
| 定位 | 面向 coding agent 的本地决策记忆和多 agent 协作账本 |
| Stars | 36 |
| Forks | 2 |
| 主要语言 | Rust |
| 许可证 | MIT OR Apache-2.0 |
| 创建时间 | 2026-02-19 11:08:05 UTC |
| Latest push | 2026-09-04 10:01:01 UTC |
| 最新提交 | 9de7662，2026-09-04 10:00:47 UTC |
| 最新 Release | v0.4.0，2026-09-02 05:38:34 UTC |
| 安装方式 | curl install script、Homebrew、cargo install edda、GitHub Releases binary |
| 关键词 | agent memory、decision tracking、hash chain、local-first、MCP、multi-agent |
它抓住的是 session 边界
很多 agent 记忆方案最后会变成一个 Markdown 文件、一个 summary，或者一套 vector memory。它们不一定错，但经常会把“发生了什么”和“为什么接受这个决定”压扁成一段文本。Edda 的角度更像事件日志：决策有 rationale，任务完成要有 receipt，verdict 和 ratify 也是单独事件，而不是把旧记录改掉。
这对长期项目有用。比如你已经决定某个模块保持 single-writer，不引入 Postgres JSONB；下一次 session 启动时，agent 不需要重新读完整聊天记录，而是从 Edda 注入的 context 里看到这条已记录的决定。更重要的是，这个决定是结构化事件，带时间、scope 和理由，后续可以查询，而不是靠模型从一大段 prose 里猜。
README 也把边界说得很清楚：core loop 不需要 LLM。记录、检索、hash chain 和 session-start injection 都在本地完成。可选的 LLM assist 用于长 transcript 的 decision extraction、session-end digest 和 pattern correlation，并且通过 EDDA_LLM_API_KEY 和 daily budget 开启。默认不开 key，就没有这部分 egress。
多 agent 时，记忆会变成协调问题
Edda 有意思的地方不只是“让下一个 session 记得上一个 session”。它把第二层叫 Fleet，处理的是多 agent 同时工作时的 coordination：谁 claim 了哪些路径，哪个 task 正在进行，哪个 task done 但有没有 receipt，哪个 plan phase 需要人工 verdict。
这个方向比普通 TODO list 更贴近 agent 工作流。一个 agent 说“完成了”不等于事实完成，至少应该留下可检查的证据；一个 phase 通过不应该只靠当前会话里的口头同意，而应该记录一个 pin 到 SHA 的 verdict；多个 session 同时编辑同一片路径时，工具至少应该在开始前把 claim intersection 摆出来。
目前 claims 默认是 advisory。也就是说，Edda 会记录并展示冲突，但不会天然变成强制锁。README 提到可以通过 EDDA_ENFORCE_OFFLIMITS=1 或 bridge.enforce_offlimits=true 让 Claude Code hook 拒绝写入 peer-claimed path。这个默认值是合理的：它先让团队看见协调状态，再让更严格的 enforcement 变成显式选择。
v0.4.0 重点在运行时和恢复
最新 release v0.4.0 很适合观察这个项目的方向。它新增了 multi-agent conductor runtime，让 edda conduct run --agent <claude|pi|codex> 可以启动不同 host；edda dispatch 则提供 single-turn agent command，强调 Codex session-to-thread continuity、budget reporting 和 cross-process recovery。
另一个重点是 gate 和 recovery。Release notes 里提到 plans 可以暂停在 AWAITING_VERDICT，通过 edda phase approve 或 edda phase reject 恢复；phases 能声明 owned write surfaces，并转成 coordination claims。任务执行侧也加入 scoped leases、unfinished-attempt reconciliation 和 Windows scheduler launch manifest validation，目标是让中断后的工作可以重新进入，而不是悄悄消失。
这些不是特别好截图的功能，但对 agent orchestration 很关键。真正痛苦的不是“跑一个 agent”，而是 controller 死了、child process 还在、任务状态一半在 stdout、一半在聊天记录、一半在 git branch 里的时候，谁来还原现场。Edda 试图把这些都落成事件、心跳、claim、receipt 和 verdict。
本地优先的好处和代价
本地优先是 Edda 的重要卖点。它不要求外部 SaaS，也不把所有状态放进某个 agent vendor 的私有记忆里。.edda/ledger.db、ledger blobs、branches、drafts、patterns、actors、policy、config 都放在本地，MCP server 只是把这些能力暴露给 client。
这个设计适合个人开发者、小团队、以及经常在 Claude Code、Codex、Cursor 之间切换的人。你可以让不同工具读写同一个 ledger，让“我们为什么这么做”不再绑定到某一个聊天窗口。
但它也有代价。首先，项目很年轻，stars 只有 36，虽然活跃，但还不是广泛验证的基础设施。其次，Rust workspace 当前要求 rust-version = "1.91"，这在 2026 年 9 月属于很新的 toolchain；如果你的机器或 CI pin 在较旧版本，试用前要先处理工具链。第三，README 明确说 today 的 two-tier authority 仍是 workflow convention，不是完整的 cryptographic identity / access-control boundary。不要把它当安全隔离层。
适合谁
第一类是长期让 agent 参与真实项目的人。如果你的主要痛点是“每个 session 都要重新解释历史决定”，Edda 的 Layer 1 可能已经够用。
第二类是同时跑多个 agent 的人。比如一个实现，一个 review，一个补测试。你需要的不只是记忆，而是 claims、task receipts、phase gates 和 peer heartbeat 这种可恢复的工作状态。
第三类是想把 agent 输出变得可审计的人。Hash chain 不会让 agent 自动变可靠，但它至少让“记录被改过没有、某个决定什么时候出现、谁声称完成了什么”变成可追踪的问题。
Caveats
第一，项目还在快速变化。v0.4.0 release notes 很长，latest push 也就在今天，这说明维护活跃，但也意味着接口和工作流可能继续调整。生产使用前最好从非关键仓库试起。
第二，Edda 和 agent hooks 强绑定。Claude Code、Codex、Cursor、OpenClaw 的 bridge 是它的价值来源，也是排障来源。任何 hook 注入、PATH、权限或 workspace detection 问题，都可能影响体验。
第三，coordination enforcement 不是默认硬锁。默认 advisory 对多数个人工作流更友好，但如果你期待强制防止并发写入，需要显式开启并测试相关 bridge 行为。
第四，它解决的是 agent memory / coordination，不是代码理解、搜索或 refactor engine。你可能仍然需要 CodeSage、Serena、语言服务器、测试工具和 review 流程来补齐其他部分。
总结
fagemx/edda 的价值在于，它没有把 agent 记忆只当成“多塞一点上下文”。它把决定、理由、任务、收据、心跳、claim 和 verdict 都看成应该落盘、可查询、可恢复的工程事件。这个角度很适合越来越常见的多 agent 开发方式。
它仍然早期，也需要你接受 hook 和本地 ledger 这套工作方式。但如果你已经开始让多个 coding agent 轮流或并行处理同一个仓库，Edda 值得认真试一次。至少，它提出的问题很对：agent 不只要会写代码，还要能记住自己为什么写、谁正在写、以及什么才算真的写完。