欢迎关注我们的工作 Synergy，已经在 Github 开源~
https://github.com/SII-Holos/synergy
0. Long-Horizon 难在哪里
一个 agent 要持续工作几小时、几天、甚至跨越数百上千次模型调用和工具执行，通常会死于三类失败：
- 遗忘：早期决策被压缩丢失、模型“失忆”、重复已做工作
- 崩溃：断电/重启/单点异常，运行状态丢失
- 漂移：目标在长链中稀释，模型“提前收尾”/漂移（Anrhtopic-context anxiety, https://www.anthropic.com/engineering/managed-agents）
行业（尤其 Anthropic）目前的结论是：跨窗口交接物 > 压缩；生成/评估分离；harness 组件编码"模型做不到的事"。Claude Code 与 Codex 的答案大多停留在"更强的压缩 + 外部文件约定（progress 文件、feature list）+ cloud 托管"。
Synergy 的根本立场是，把这三类失效的解法从 prompt 层下沉到运行时结构层——交接物不是文件约定而是持久状态机；验证不是自评而是独立会话；恢复不是 JSONL 重放而是本地磁盘权威。
L0 地基
Long-horizon 首先是一个持久性工程问题，然后才是上下文问题。
Claude code/Codex 是进程内对话，jsonl 只是记录；Synergy 以磁盘上的会话状态为权威源，内存里的执行循环只是一个带租约的执行窗口。
具体地，Synergy 将消息、工具 part、inbox、Pendingreply、workflow 等状态全部落盘，在 Synergy 程式意外被 kill 时，重启自动从持久化状态重建运行时。
Synergy 先保证“跑三天不丢状态、崩了还能接着跑”，其余机制才有意义。有点类似 Claude Code 的checkpoint 文件系统和 Codex 的会话 JSONL，但没有把“恢复”做成系统级自愈。
此外，Synergy Desktop based-on Electron，前后端经过多轮性能优化，性能非常精良，在本机实测 12 个 sessions 并发也非常流畅，对比 codex 开启 3 个并发 sessions 后就会出现卡顿、唤起风扇。
L1 上下文经济
Prompt & Cache
Synergy 的 Prompt 组装大致可以分为 7 层。
A. system 数组(按缓存稳定性排序,靠前)
| Layer 1: Agent base prompt
| Layer 1.5: AGENTS.md 指令
| Layer 2: 权限 (profile/sandbox) 上下文
| Layer 3: Cortex 委派上下文 (subagent)
| Layer 4: Workflow 上下文 (Plan/Lattie/LightLoop 等 Loop Engineer)
B. lateSystem 数组(动态尾段)，会被包成一个独立 user 消息 <runtime-context>,追加在对话历史最后、当前用户消息紧邻之前
| Layer 5: Memory/Experience 召回
| Layer 6: env 环境块(时间戳/工作目录 Scope/git 状态)
| Layer 7: agenda/cortex/DAG 提醒
组 B 动态组装，且保持在尾部，以提高缓存命中率。实测在以难命中著称的智谱官方 coding plan，使用 Synergy + GLM-5.3 Max 缓存命中率达到 96.5%。
Compaction
Synergy 的 Compaction 由专用的 compaction agent 生成，产物是隐藏 continuation 消息、user anchor message（保证长任务多次压缩方向不漂移）、recovery hint。核心是以摘要为主、不做已有工作、早期上下文细节原生支持 session_read 工具绕过摘要直读原文。
Claude Code 的 compaction 由 摘要(对话总结) + 磁盘重注入 构成，其中 磁盘重注入了 CLAUDE.md/auto memory/plan/最近编辑/查看的5个文件/skills/hooks…，其核心策略为磁盘内容永不总结，只总结对话。其压缩后质量主要靠外部状态重注入，赌“上下文中重要部分在磁盘文件上”。
Cidex 的 compaction 由 摘要(handoff) + 最近 ~20k tokens 用户消息 + 工具状态 组成，且通过专用的 compaction model 进行压缩，核心是最近用户消息原样保留。其压缩质量主要靠 handoff + 原始用户消息片段，赌“最近用户意图+LLM交接文档”。
好吧现在 Astra 端出来了，Codex Harness 也有所升级，终于摆脱了拉完了称号。
Synergy 是持久化的会话模型，既没有 Claude 的磁盘重注入清单，也没有 Codex 的 20k 片段保留，只注入了工作总结（summary）以及用户意图（anchor user message），但多了"任何时候都能精确回溯"的能力（session read）。
Prune
与 Claude Code 工具输出整体进上下文不同，Synergy 的工具输出默认进行截断（只有 50KB/2000行 直接进入上下文，完整版落盘 toolOutput/ 供 Grep/Read/Task 读取），并且异步在后台对旧的大工具输出从模型投影移除，压缩时整个会话 LLM 摘要，旧工具输出也随历史一起总结。
L2 记忆分层
在最近 Astra 发布时，Codex 的升级也一并释出，其中有一条就是，『Codex不再单纯依靠压缩总结保存历史，而是可以跨上下文窗口保存笔记，并搜索此前消息和工具输出，从而找到之前的需求、测试结果以及修改记录』。然而这个在五个月前 Synergy 开源之初就已经有了。
Synergy 的记忆总体分五个层次。
Session：原始对话即记忆
Session 保存的就是全量的原始对话数据，并且原始对话也作为记忆的一部分，不同的会话间也可以自由引用，本质上就是对记忆的回溯，你回去看上次聊了什么，这就是记忆在起作用。上下文压缩只是因为窗口有限做的工程妥协，不是记忆的形态本身。
Note：人机共创的备忘录
Claude Code 和 OpenClaw 写 MEMORY.md，这些本质上是 Agent 给自己写的备忘录——人看不到、也改不了。Synergy 的 Note 不是这个思路。Note 是 Agent 和人在同一个平面上共创的：人可以写一段，Agent 可以追加、整理、替换，反过来也一样。Agent 每天的 markdown 日记也可以放在 Note 里，但 Note 的核心定位不是 Agent 的私人备忘，而是协作的工作面，这同样也是记忆的组成部分。
Memory：带分类和召回逻辑的 Agent 知识库
Memory 是 Agent 自己决定写入的结构化知识。它有两个关键设计：一是分类（user/self/relationship/interaction/workflow/coding/writing/asset/insight/knowledge），不同类的知识重要性不同；二是召回逻辑（always/contextual/search_only），决定了什么时候该想起来——身份类的信息每次都注入，偏好类的按语义相关性自动召回，低优先级的只在主动搜索时才出现。写入时机也完全由 Agent 控制：对话中发现值得记录的就写，上下文压缩时 Chronicler 也会自动提取。
Experience：基于 MemRL 的行为轨迹学习
Experience 记录的是 Agent 针对每个 task 的完整 trajectory，然后提取 intent 和 script，设置一个 reward window 进行延迟评估，用 LLM-as-Judge 在 outcome/intent/execution/orchestration/expression 五个维度打分，召回后更新多维度 Q-value。核心思路是：不用重新训练模型，靠检索过去「做得好」和「做得差」的经验，就能改善 Agent 的 performance。它回答的问题不是「我知道什么」，而是「我上次遇到类似情况时，做对了还是做错了」。并且这个过程是无感的，被动的，异步的。
Skill：程序性记忆——知道怎么做
它编码的是步骤、流程、决策树：怎么正确地提交 commit、怎么创建一个新 Agent、怎么配置 MCP 服务器。Skill 不是事实列表，而是操作手册。它通过 SKILL.md 文件定义，Agent 按需加载——碰到相关场景时才调用，不需要把所有方法都塞进上下文。
L3 执行架构
长任务单靠一个 agent 串行太慢了，Synergy 的处理是 Cortex 子会话树：每个子任务 = 独立持久会话（独立模型、独立上下文窗口、独立工作区），并采用异步两阶段完成协议（通知与结果分离），并将这些子任务有依赖关系显式建模 DAG，节点完成后自动推进下游。
L4 工作流状态机
长任务的“下一步该作什么”的权威状态不应该放在模型上下文里（会被压缩、遗忘、context anxiety），而放在持久化的编排状态里，并通过状态机工具推进。
Synergy 内置了四种 workflow 对应四种长程形态。
- Plan -> Blueprint：先写决策完整的交付物，不留开放决策，将“想清楚”与“动手”分成两个阶段，且 Blueprint 是持久 Note──跨会话、跨压缩。
- Blueprint Loop：执行会话跑完后，独立审计会话检查交付产物、检查历史 trajectory，来裁定执行结果，并可驳回状态机转换，回到执行会话修改。
- Lattice：组装多个 Blueprint Loop，采用七态 Run 状态机（clarifying → planning → reviewing_pathway → blueprinting → reviewing_blueprint → awaiting_execution → executing），步骤历史不可变，每执行完一个 Blueprint 后允许 replan 未开始的未来步骤；每步完成回到 pathway review——“根据上一步结果自适应下一步”。
- Boss Mode：持久化 worker 树（任意深度、worker 可再 spawn worker），没有中央状态机，具体形态还在测试中。
这些状态机不追求让模型更聪明，而是让模型更少需要记得。方向、阶段、验证、预算全部外置成系统状态；模型在每个时刻只需要做"当前这一步"。