firstmate重启免疫设计剖析状态落盘机制如何保证在途工作永不丢失【免费下载链接】firstmateTalk to one agent. Ship with a crew.项目地址: https://gitcode.com/gh_mirrors/fi/firstmatefirstmate 是一个agent 发行版让你只和一个 AI 大副对话就能指挥一队 AI 编码 agent 并行干活。它最硬核的设计是重启免疫所有关键状态都写入磁盘而非聊天记忆杀掉任何会话后下一个会话都会从磁盘自动对账、原地续跑。本文剖析这套状态落盘机制的三层结构与恢复流程帮你看懂它为何敢承诺在途工作永不丢失。设计哲学为什么重启应该是个无事发生大多数 AI 编码工具有个通病上下文只活在对话里。会话一关进行到哪一步、答应了什么、卡在哪里全部清零。firstmate 在 VISION.md 里把这件事上升为一条核心原则——A restart is a non-event重启是非事件一切重要的东西都能活过任何对话的死亡在途的工作、做出的承诺、待定的决策、船长的偏好都存在于持久化记录中而不是聊天记忆里。这句话翻译过来就是对话可以随时死磁盘上的记录才是权威。系统通过从磁盘 活跃会话状态对账恢复所以杀任何会话都不会丢东西、不会吓到任何人。这个承诺能成立靠的是下面三层落盘结构。第一层data/目录——持久任务记录data/是整个船队的账本全部是本地 Markdown 文件重启后依然完整文件作用data/backlog.md任务队列、依赖关系、历史持久的待办账本data/captain.md本 home 的船长偏好与工作方式data/captain-shared.md主 home 共享给二副的偏好data/learnings.md运行中踩过的坑、经验教训带日期、会衰减整理data/projects.md项目注册表与交付姿态data/id/brief.md每个任务的派工简报data/id/report.md侦察类任务的调研报告拆除后依然保留关键点在于任务的是什么、做到哪、怎么交付这些信息从来不在对话里而在这些文件里。worker 死了可以重拉但账本本身永远在。第二层state/目录——运行时信号与持久唤醒队列state/存放运行时记录与信号详见 AGENTS.md 的目录约定它是进程死了、记录还在的缓冲层state/id.status—— worker 追加的唤醒事件日志注意是事件历史不是当前状态state/id.meta—— 任务元数据PR 编号、worktree、harness 等state/id.inbox/—— 持久的指令收件箱发给 worker 的每条消息都是落盘记录worker 处理完才移走state/.wake-queue——持久唤醒队列这是重启免疫的心脏。为什么唤醒队列如此重要看 docs/architecture.md 的设计可执行的唤醒只在恢复证据发布之后才写入state/.wake-queue。这意味着哪怕 watcher 进程被中途打断、或者处理回合崩了队列记录依然完好——下一个会话启动时会原样呈现这些待办唤醒并且有生成期绑定确认机制处理完之前中断工作就保持持久状态等幂等的重放处理绝不丢。一句话通知不是发消息而是写记录 响门铃。门铃没听见不要紧记录还在磁盘上等着。第三层会话后端——活着的 worker 端点前两层是纸面记录真正干活的 worker 则活在会话后端里tmux 为硬默认另有 herdr、zellij、Orca、cmux。后端为每个任务提供一个可见的独立端点tmux 窗口、herdr 标签页等worker 在自己的 git worktree 里干活。重启免疫在这里的体现是firstmate 重启时不会盲目重建一切而是探测每个已记录端点的存活状态只处理确认死亡的端点——二副secondmateagent 确认死亡后会走同一派工路径自动重拉而存活状态模糊的端点一律不动避免重复监督。宁可慢不可错。会话启动对账7 步恢复清单每次新会话启动bin/fm-session-start.sh 会执行一条固定的对账流水线定义在 AGENTS.md 第 3 节锁——先拿到 home 级会话锁保证同一时刻只有一个会话改状态引导——工具链检测、worktree 纠缠检查、二副存活清扫死二副在此自动重拉唤醒队列——把state/.wake-queue里的持久唤醒作为本轮第一个工作队列呈现同时打印全局 OPEN DECISIONS未决决策与 UNREAD STATUS未读状态监督操作说明——按当前 harness 渲染监督协议块舰队状态摘要——每个任务的元数据、状态日志尾部、端点存活快读网络检查——GitHub 鉴权、死二副重拉、项目克隆刷新全部在后台延迟阶段跑上下文摘要——projects.md、secondmates.md、captain.md、learnings.md全文载入。这套流程保证了 docs/architecture.md 中Restart-proof章节承诺的体验杀了会话重开firstmate 自己读账本、对现状、补唤醒然后接着干。/stow技能收尾前先让记忆落盘还有一个容易被忽略的细节对话里往往藏着还没写进磁盘的持久知识——临时说出口的偏好、刚做下的决定、没记下来的下一步。firstmate 提供了 /stow 技能来解决这个缝隙扫一遍当前会话找出所有只存在于聊天里的持久知识按固定优先级路由到磁盘船长按钮偏好 →captain.md项目事实 → 项目的AGENTS.md未完成的下一步 → backlog先检查再更新绝不盲目追加条目分层pinned / aging / perishable并会随时间衰减归档最后给出一句诚实的裁决现在这个会话是否安全可以结束/重置并附一个可复制的恢复指针告诉新会话该先加载哪些文件。docs/verification/stow-memory.md 中记录了这套 JIT 加载本地记忆的验证证据——新会话确实能从一个被 git 排除的本地技能目录里把知识捞回来。这正是重启免疫的最后一块拼图不仅系统状态落盘连你的对话记忆也有落盘出口。worker 死了怎么办三条恢复路径重启免疫不等于不用处理故障AGENTS.md 第 5 节定义了明确的恢复路径故障恢复动作二副确认死亡会话启动时自动重拉不碰其子树普通 worker 端点死亡走 stuck-crewmate-recovery保住已记录的 worktree 与未落地的工作只恢复所有权工作未落地就要清理teardown 拒绝拆除——拒绝丢弃是发现项不是障碍原则非常一致恢复只对齐已记录的直接报告永远不清扫、不猜测、不发明工作。总结这套设计值得借鉴的 5 个点记录即权威——对话是易失缓存磁盘才是数据库事件与状态分离——状态日志是追加式事件流当前状态要靠专门的对账脚本读避免读最后一行的陷阱先落盘后通知——队列记录先于通知存在通知丢了记录还在幂等恢复——中断前的工作保持可重放重复处理不会造成重复结果保守恢复——模糊的存活信号一律不动手确认死亡才重建。对新手用户而言最直观的体验是你可以随时杀掉整个 tmux、重启电脑、甚至换台机器 clone 一份 home——在途任务、未决决策、已承诺的回复都会在下一个会话里自己回来上班。这也就是 README 里那句 Restart-proof 的全部含义。想深入了解建议按顺序读 README.md 的 How It Works、docs/architecture.md 的 Restart-proof 章节以及 AGENTS.md 的目录约定与 Recovery 章节。【免费下载链接】firstmateTalk to one agent. Ship with a crew.项目地址: https://gitcode.com/gh_mirrors/fi/firstmate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
firstmate重启免疫设计剖析：状态落盘机制如何保证在途工作永不丢失
firstmate重启免疫设计剖析状态落盘机制如何保证在途工作永不丢失【免费下载链接】firstmateTalk to one agent. Ship with a crew.项目地址: https://gitcode.com/gh_mirrors/fi/firstmatefirstmate 是一个agent 发行版让你只和一个 AI 大副对话就能指挥一队 AI 编码 agent 并行干活。它最硬核的设计是重启免疫所有关键状态都写入磁盘而非聊天记忆杀掉任何会话后下一个会话都会从磁盘自动对账、原地续跑。本文剖析这套状态落盘机制的三层结构与恢复流程帮你看懂它为何敢承诺在途工作永不丢失。设计哲学为什么重启应该是个无事发生大多数 AI 编码工具有个通病上下文只活在对话里。会话一关进行到哪一步、答应了什么、卡在哪里全部清零。firstmate 在 VISION.md 里把这件事上升为一条核心原则——A restart is a non-event重启是非事件一切重要的东西都能活过任何对话的死亡在途的工作、做出的承诺、待定的决策、船长的偏好都存在于持久化记录中而不是聊天记忆里。这句话翻译过来就是对话可以随时死磁盘上的记录才是权威。系统通过从磁盘 活跃会话状态对账恢复所以杀任何会话都不会丢东西、不会吓到任何人。这个承诺能成立靠的是下面三层落盘结构。第一层data/目录——持久任务记录data/是整个船队的账本全部是本地 Markdown 文件重启后依然完整文件作用data/backlog.md任务队列、依赖关系、历史持久的待办账本data/captain.md本 home 的船长偏好与工作方式data/captain-shared.md主 home 共享给二副的偏好data/learnings.md运行中踩过的坑、经验教训带日期、会衰减整理data/projects.md项目注册表与交付姿态data/id/brief.md每个任务的派工简报data/id/report.md侦察类任务的调研报告拆除后依然保留关键点在于任务的是什么、做到哪、怎么交付这些信息从来不在对话里而在这些文件里。worker 死了可以重拉但账本本身永远在。第二层state/目录——运行时信号与持久唤醒队列state/存放运行时记录与信号详见 AGENTS.md 的目录约定它是进程死了、记录还在的缓冲层state/id.status—— worker 追加的唤醒事件日志注意是事件历史不是当前状态state/id.meta—— 任务元数据PR 编号、worktree、harness 等state/id.inbox/—— 持久的指令收件箱发给 worker 的每条消息都是落盘记录worker 处理完才移走state/.wake-queue——持久唤醒队列这是重启免疫的心脏。为什么唤醒队列如此重要看 docs/architecture.md 的设计可执行的唤醒只在恢复证据发布之后才写入state/.wake-queue。这意味着哪怕 watcher 进程被中途打断、或者处理回合崩了队列记录依然完好——下一个会话启动时会原样呈现这些待办唤醒并且有生成期绑定确认机制处理完之前中断工作就保持持久状态等幂等的重放处理绝不丢。一句话通知不是发消息而是写记录 响门铃。门铃没听见不要紧记录还在磁盘上等着。第三层会话后端——活着的 worker 端点前两层是纸面记录真正干活的 worker 则活在会话后端里tmux 为硬默认另有 herdr、zellij、Orca、cmux。后端为每个任务提供一个可见的独立端点tmux 窗口、herdr 标签页等worker 在自己的 git worktree 里干活。重启免疫在这里的体现是firstmate 重启时不会盲目重建一切而是探测每个已记录端点的存活状态只处理确认死亡的端点——二副secondmateagent 确认死亡后会走同一派工路径自动重拉而存活状态模糊的端点一律不动避免重复监督。宁可慢不可错。会话启动对账7 步恢复清单每次新会话启动bin/fm-session-start.sh 会执行一条固定的对账流水线定义在 AGENTS.md 第 3 节锁——先拿到 home 级会话锁保证同一时刻只有一个会话改状态引导——工具链检测、worktree 纠缠检查、二副存活清扫死二副在此自动重拉唤醒队列——把state/.wake-queue里的持久唤醒作为本轮第一个工作队列呈现同时打印全局 OPEN DECISIONS未决决策与 UNREAD STATUS未读状态监督操作说明——按当前 harness 渲染监督协议块舰队状态摘要——每个任务的元数据、状态日志尾部、端点存活快读网络检查——GitHub 鉴权、死二副重拉、项目克隆刷新全部在后台延迟阶段跑上下文摘要——projects.md、secondmates.md、captain.md、learnings.md全文载入。这套流程保证了 docs/architecture.md 中Restart-proof章节承诺的体验杀了会话重开firstmate 自己读账本、对现状、补唤醒然后接着干。/stow技能收尾前先让记忆落盘还有一个容易被忽略的细节对话里往往藏着还没写进磁盘的持久知识——临时说出口的偏好、刚做下的决定、没记下来的下一步。firstmate 提供了 /stow 技能来解决这个缝隙扫一遍当前会话找出所有只存在于聊天里的持久知识按固定优先级路由到磁盘船长按钮偏好 →captain.md项目事实 → 项目的AGENTS.md未完成的下一步 → backlog先检查再更新绝不盲目追加条目分层pinned / aging / perishable并会随时间衰减归档最后给出一句诚实的裁决现在这个会话是否安全可以结束/重置并附一个可复制的恢复指针告诉新会话该先加载哪些文件。docs/verification/stow-memory.md 中记录了这套 JIT 加载本地记忆的验证证据——新会话确实能从一个被 git 排除的本地技能目录里把知识捞回来。这正是重启免疫的最后一块拼图不仅系统状态落盘连你的对话记忆也有落盘出口。worker 死了怎么办三条恢复路径重启免疫不等于不用处理故障AGENTS.md 第 5 节定义了明确的恢复路径故障恢复动作二副确认死亡会话启动时自动重拉不碰其子树普通 worker 端点死亡走 stuck-crewmate-recovery保住已记录的 worktree 与未落地的工作只恢复所有权工作未落地就要清理teardown 拒绝拆除——拒绝丢弃是发现项不是障碍原则非常一致恢复只对齐已记录的直接报告永远不清扫、不猜测、不发明工作。总结这套设计值得借鉴的 5 个点记录即权威——对话是易失缓存磁盘才是数据库事件与状态分离——状态日志是追加式事件流当前状态要靠专门的对账脚本读避免读最后一行的陷阱先落盘后通知——队列记录先于通知存在通知丢了记录还在幂等恢复——中断前的工作保持可重放重复处理不会造成重复结果保守恢复——模糊的存活信号一律不动手确认死亡才重建。对新手用户而言最直观的体验是你可以随时杀掉整个 tmux、重启电脑、甚至换台机器 clone 一份 home——在途任务、未决决策、已承诺的回复都会在下一个会话里自己回来上班。这也就是 README 里那句 Restart-proof 的全部含义。想深入了解建议按顺序读 README.md 的 How It Works、docs/architecture.md 的 Restart-proof 章节以及 AGENTS.md 的目录约定与 Recovery 章节。【免费下载链接】firstmateTalk to one agent. Ship with a crew.项目地址: https://gitcode.com/gh_mirrors/fi/firstmate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
