尧图网页设计 
Memoh会话运行时原理AI Agent会话如何在服务器重启后不丢失上下文【免费下载链接】Memoh✨ The open-source multi-agent platform. Every agent gets its own computer, desktop, network, and long-term memory. You can bring your own key, or host your coding agent like Claude Code, Codex and so on.项目地址: https://gitcode.com/gh_mirrors/me/MemohMemoh 是一个开源多智能体Multi-Agent平台每个 AI Agent 都拥有自己的云端电脑——独立的工作区、桌面、网络和长期记忆。这篇文章面向新手用户用尽量少的代码讲清楚 Memoh 的会话运行时Session Runtime是如何工作的为什么服务器重启、甚至多实例滚动升级时AI Agent 的会话上下文不会丢失进行中的任务也能自动续跑。你会遇到的问题AI 会话怕重启大多数聊天机器人都有一个通病服务端一重启正在进行的对话就断片了。轻则回答中断、需要你重发一遍重则 Agent 忘记了自己正在执行什么任务之前积累的判断全部归零。对普通用户来说这种体验很难受对自托管Self-Hosted部署的管理员来说更糟——升级服务器、重启容器都成了高危操作。Memoh 把这个问题当成架构级问题来解决它不是尽量别断而是保证断得掉、续得上。核心思想一先写账本再干活持久化优先Memoh 的会话运行时建立在一个简单但关键的原则上任何输入在被接受accepted之前必须先落到数据库任何执行状态的变化都以 PostgreSQL 中的账本ledger为准。具体来说你的每一次提问在系统里会生成一条session_runs账本记录包含你的原始输入内容全局唯一身份标识invocation_id、run_id、turn_id当前执行状态运行中 / 等待审批 / 已完成 / 已中断等已持久化的中间输出这套账本的设计约束写在 会话运行时正确性要求 中核心条款 SR-DUR-001 明确写道Server 在返回 accepted 后退出重启后的系统必须仍能查询到原始用户输入、run 身份和最后一个已持久化状态……不能只把已接受输入保存在 goroutine、WebSocket handler 或进程内 Manager 中。翻译成大白话进程的内存只是草稿纸数据库才是账本。进程随时可以死账本永远在。核心思想二给每次执行发身份证重复提交不会跑两遍Memoh 用一组严格的身份标识把一次对话切成几个互不混淆的概念身份作用invocation_id标识一次提交。网络抖动导致你连点两次发送系统保证只执行一次run_id标识一次被接受的执行。整个执行过程围绕它展开turn_id标识对话时间线上的一个回合把你的输入、Agent 的回答、工具调用关联起来decision_id标识一次审批或用户补充输入请求保证你的回答不会被应用到错误的执行上这带来两个对用户很友好的保证幂等重试请求发出去没收到回音你安全地重试不会触发第二次模型调用、不会写入两条重复消息。单会话串行同一个会话同一时刻只有一个执行者owner不会出现两个服务器实例同时在跑同一个会话的情况。这套算法和并发测试集中在 internal/agent/runtime/session/ 目录其中的 admit.go 负责准入判断fence.go 负责所有权围栏fencing校验。核心思想三优雅关机打标 自动恢复续跑这是整个机制里最精彩的部分分三步走第一步关机前留纸条。服务器收到停机信号后会先关闭新输入、给所有正在运行的会话打上session_runtime.interrupted已中断标记然后才取消执行、关闭 HTTP 服务。整个优雅关机预算是 30 秒Docker Compose 侧允许 45 秒。第二步启动后自动翻账本。服务器重启后一个有界的工作协程会扫描账本中所有被中断的运行读取其中保存的版本化恢复上下文原始提问、模型选择、执行位置、剩余时间预算等然后用一个稳定的身份resume:原run-id提交续跑任务。第三步续跑时先看现场。恢复出来的执行会重新加载已提交的历史并指示模型先检查被中断的工具执行结果再决定下一步动作——避免盲目重复执行一个已经跑了一半的命令。这三步的完整描述在 docs/agent-runtime.md 的 Graceful shutdown and session resume 一节。需要说明的诚实边界SIGKILL、OOM 这类猝死无法可靠地写标记此时运行会收敛为lost丢失状态——但你的输入依然保存在账本里可以手动重试或开启新任务。核心思想四多实例部署时的租约 围栏如果你部署了多台服务器比如做负载均衡或滚动升级还会出现一个新问题谁来执行这个会话旧实例还没死透新实例已经开始接手怎么办Memoh 用两个经典分布式手段解决租约Leaseowner 身份必须持有跨实例可验证的租约单实例部署用进程内内存后端多实例部署用 Redis/Valkey启动时会校验配置缺少依赖会拒绝进入多实例模式。围栏令牌Fencing Token每次所有权转移都会让令牌单调递增旧 owner 迟到的写入会带着过期令牌被数据库直接拒绝。效果是即使新旧两个实例短暂并存也最多只有一个拥有写入权会话不会出现精神分裂。这套机制在多实例下的黑盒验收测试位于 internal/agent/runtime/session/acceptance/其 README 中列出了关键场景双服务器重连快照、跨实例 abort 路由、owner 进程被 SIGKILL 后状态仍可查询收敛为lost、终态重放不产生重复消息等。真实压过一遍滚动升级不丢会话原理说得再漂亮还是要实战检验。Agent 生命周期 QA 报告 记录了一次真实的滚动替换演练旧实例正在服务流量新实例接入同一个 PostgreSQL 和 Valkey通过 UI 发起一个带真实长命令的会话命令还在执行、模型还在流式输出切换代理上游到新实例停掉旧实例45 秒宽限不发送任何新的用户消息观察新实例的账本、UI 和任务文件。结果会话在新实例上自动恢复UI 出现ROLL_RESUMED标记所有权从实例 C 转移到 D围栏令牌从 26 递增到 27代理健康探测 42 秒内 200/200 全部成功任务文件的执行凭据在替换前后各一行、没有重复。长任务场景同样验证过父子 Agent 各执行了 660 秒的真实子命令跨越重启边界完整完成。外部运行时Claude Code / Codex如何续命如果你托管的是 Claude Code、Codex 这类自带会话记忆的外部 AgentMemoh 还有第二道保险这些运行时会在 Bot 的工作区数据卷上保存自己的会话文件Codex 的 rollout、Claude Code 的 transcript。Memoh 记录的是如何恢复它的元数据Codex thread id / rollout 路径、Claude 会话 ID重启后按路径优先恢复原生会话万一原生会话无法恢复本轮会开启新会话并明确告知native_history_lost通知后续轮次从 Memoh 的组合上下文继续——而聊天历史始终完整保存在 PostgreSQL 里不会丢。写在最后回到开头的问题AI Agent 会话为什么能在服务器重启后不丢上下文Memoh 的答案可以浓缩成四句话持久化优先输入和状态先写进 PostgreSQL 账本内存只是缓存身份严格invocation_id/run_id/turn_id保证幂等、防重、防错配中断有标记、恢复有流程优雅关机打interrupted标记重启后自动发现、自动续跑、先检查工具现场再行动多实例有租约、有围栏所有权转移全程可验证旧实例的迟到写入一律作废。对于自托管用户这意味着升级、重启、扩容都成了低风险操作对于普通用户这意味着你的 AI Agent 真正活在服务器上——即使合上笔记本它也记得自己正在做什么。想深入了解设计细节可以对照阅读 docs/design/session-runtime-requirements.md 与 docs/design/context-memory-scheduling.md。【免费下载链接】Memoh✨ The open-source multi-agent platform. Every agent gets its own computer, desktop, network, and long-term memory. You can bring your own key, or host your coding agent like Claude Code, Codex and so on.项目地址: https://gitcode.com/gh_mirrors/me/Memoh创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Memoh会话运行时原理：AI Agent会话如何在服务器重启后不丢失上下文
Memoh会话运行时原理AI Agent会话如何在服务器重启后不丢失上下文【免费下载链接】Memoh✨ The open-source multi-agent platform. Every agent gets its own computer, desktop, network, and long-term memory. You can bring your own key, or host your coding agent like Claude Code, Codex and so on.项目地址: https://gitcode.com/gh_mirrors/me/MemohMemoh 是一个开源多智能体Multi-Agent平台每个 AI Agent 都拥有自己的云端电脑——独立的工作区、桌面、网络和长期记忆。这篇文章面向新手用户用尽量少的代码讲清楚 Memoh 的会话运行时Session Runtime是如何工作的为什么服务器重启、甚至多实例滚动升级时AI Agent 的会话上下文不会丢失进行中的任务也能自动续跑。你会遇到的问题AI 会话怕重启大多数聊天机器人都有一个通病服务端一重启正在进行的对话就断片了。轻则回答中断、需要你重发一遍重则 Agent 忘记了自己正在执行什么任务之前积累的判断全部归零。对普通用户来说这种体验很难受对自托管Self-Hosted部署的管理员来说更糟——升级服务器、重启容器都成了高危操作。Memoh 把这个问题当成架构级问题来解决它不是尽量别断而是保证断得掉、续得上。核心思想一先写账本再干活持久化优先Memoh 的会话运行时建立在一个简单但关键的原则上任何输入在被接受accepted之前必须先落到数据库任何执行状态的变化都以 PostgreSQL 中的账本ledger为准。具体来说你的每一次提问在系统里会生成一条session_runs账本记录包含你的原始输入内容全局唯一身份标识invocation_id、run_id、turn_id当前执行状态运行中 / 等待审批 / 已完成 / 已中断等已持久化的中间输出这套账本的设计约束写在 会话运行时正确性要求 中核心条款 SR-DUR-001 明确写道Server 在返回 accepted 后退出重启后的系统必须仍能查询到原始用户输入、run 身份和最后一个已持久化状态……不能只把已接受输入保存在 goroutine、WebSocket handler 或进程内 Manager 中。翻译成大白话进程的内存只是草稿纸数据库才是账本。进程随时可以死账本永远在。核心思想二给每次执行发身份证重复提交不会跑两遍Memoh 用一组严格的身份标识把一次对话切成几个互不混淆的概念身份作用invocation_id标识一次提交。网络抖动导致你连点两次发送系统保证只执行一次run_id标识一次被接受的执行。整个执行过程围绕它展开turn_id标识对话时间线上的一个回合把你的输入、Agent 的回答、工具调用关联起来decision_id标识一次审批或用户补充输入请求保证你的回答不会被应用到错误的执行上这带来两个对用户很友好的保证幂等重试请求发出去没收到回音你安全地重试不会触发第二次模型调用、不会写入两条重复消息。单会话串行同一个会话同一时刻只有一个执行者owner不会出现两个服务器实例同时在跑同一个会话的情况。这套算法和并发测试集中在 internal/agent/runtime/session/ 目录其中的 admit.go 负责准入判断fence.go 负责所有权围栏fencing校验。核心思想三优雅关机打标 自动恢复续跑这是整个机制里最精彩的部分分三步走第一步关机前留纸条。服务器收到停机信号后会先关闭新输入、给所有正在运行的会话打上session_runtime.interrupted已中断标记然后才取消执行、关闭 HTTP 服务。整个优雅关机预算是 30 秒Docker Compose 侧允许 45 秒。第二步启动后自动翻账本。服务器重启后一个有界的工作协程会扫描账本中所有被中断的运行读取其中保存的版本化恢复上下文原始提问、模型选择、执行位置、剩余时间预算等然后用一个稳定的身份resume:原run-id提交续跑任务。第三步续跑时先看现场。恢复出来的执行会重新加载已提交的历史并指示模型先检查被中断的工具执行结果再决定下一步动作——避免盲目重复执行一个已经跑了一半的命令。这三步的完整描述在 docs/agent-runtime.md 的 Graceful shutdown and session resume 一节。需要说明的诚实边界SIGKILL、OOM 这类猝死无法可靠地写标记此时运行会收敛为lost丢失状态——但你的输入依然保存在账本里可以手动重试或开启新任务。核心思想四多实例部署时的租约 围栏如果你部署了多台服务器比如做负载均衡或滚动升级还会出现一个新问题谁来执行这个会话旧实例还没死透新实例已经开始接手怎么办Memoh 用两个经典分布式手段解决租约Leaseowner 身份必须持有跨实例可验证的租约单实例部署用进程内内存后端多实例部署用 Redis/Valkey启动时会校验配置缺少依赖会拒绝进入多实例模式。围栏令牌Fencing Token每次所有权转移都会让令牌单调递增旧 owner 迟到的写入会带着过期令牌被数据库直接拒绝。效果是即使新旧两个实例短暂并存也最多只有一个拥有写入权会话不会出现精神分裂。这套机制在多实例下的黑盒验收测试位于 internal/agent/runtime/session/acceptance/其 README 中列出了关键场景双服务器重连快照、跨实例 abort 路由、owner 进程被 SIGKILL 后状态仍可查询收敛为lost、终态重放不产生重复消息等。真实压过一遍滚动升级不丢会话原理说得再漂亮还是要实战检验。Agent 生命周期 QA 报告 记录了一次真实的滚动替换演练旧实例正在服务流量新实例接入同一个 PostgreSQL 和 Valkey通过 UI 发起一个带真实长命令的会话命令还在执行、模型还在流式输出切换代理上游到新实例停掉旧实例45 秒宽限不发送任何新的用户消息观察新实例的账本、UI 和任务文件。结果会话在新实例上自动恢复UI 出现ROLL_RESUMED标记所有权从实例 C 转移到 D围栏令牌从 26 递增到 27代理健康探测 42 秒内 200/200 全部成功任务文件的执行凭据在替换前后各一行、没有重复。长任务场景同样验证过父子 Agent 各执行了 660 秒的真实子命令跨越重启边界完整完成。外部运行时Claude Code / Codex如何续命如果你托管的是 Claude Code、Codex 这类自带会话记忆的外部 AgentMemoh 还有第二道保险这些运行时会在 Bot 的工作区数据卷上保存自己的会话文件Codex 的 rollout、Claude Code 的 transcript。Memoh 记录的是如何恢复它的元数据Codex thread id / rollout 路径、Claude 会话 ID重启后按路径优先恢复原生会话万一原生会话无法恢复本轮会开启新会话并明确告知native_history_lost通知后续轮次从 Memoh 的组合上下文继续——而聊天历史始终完整保存在 PostgreSQL 里不会丢。写在最后回到开头的问题AI Agent 会话为什么能在服务器重启后不丢上下文Memoh 的答案可以浓缩成四句话持久化优先输入和状态先写进 PostgreSQL 账本内存只是缓存身份严格invocation_id/run_id/turn_id保证幂等、防重、防错配中断有标记、恢复有流程优雅关机打interrupted标记重启后自动发现、自动续跑、先检查工具现场再行动多实例有租约、有围栏所有权转移全程可验证旧实例的迟到写入一律作废。对于自托管用户这意味着升级、重启、扩容都成了低风险操作对于普通用户这意味着你的 AI Agent 真正活在服务器上——即使合上笔记本它也记得自己正在做什么。想深入了解设计细节可以对照阅读 docs/design/session-runtime-requirements.md 与 docs/design/context-memory-scheduling.md。【免费下载链接】Memoh✨ The open-source multi-agent platform. Every agent gets its own computer, desktop, network, and long-term memory. You can bring your own key, or host your coding agent like Claude Code, Codex and so on.项目地址: https://gitcode.com/gh_mirrors/me/Memoh创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考