先看工作，再看抽象
验收明确的复杂任务
重构、迁移、协议实现。终点比较明确，执行路线仍有不确定性。
保留：验收缺口、版本、修复证据关注：完成率与成本
开放探索类任务
调研、算法实验、系统优化。下一条路线由新证据不断改变。
保留：假设、反证、候选方向关注：有效发现与验证
持续交付的数字员工
接收 issue、修复、跟进评审，处理新反馈，并对结果持续负责。
保留：职责、外部状态、等待条件关注：交付质量与人的投入
这三类可以嵌套。一个长期维护仓库的 Agent，可能先探索性能问题，再完成一项验收明确的修复，最后持续跟进 PR。前两类主要描述工作如何求解，第三类还增加了持续的职责与到达的新任务。
真正延续下来的，应当是工作及其判断依据。
01 / 把复杂任务做完
“实现一个符合规范的解码器”听起来很确定。但可见样例通过之后，仍可能遗漏边界输入、内存安全和兼容性；重开一个会话，又可能丢掉此前确认的失败条件。
LoopX 的作用，是让目标和验收缺口跨轮次保持连续，让新证据进入下一步决策。模型负责实现与判断，领域验证器负责检验结果；控制面记录哪些结果被接受、哪些工作仍未完成。
适合它的任务，通常会经历多轮验证、等待或交接。短小、一次会话就能验收的工作，现有 Agent 可能已经足够，新增控制面需要证明自身开销值得。
Benchmark：从 LHTB 看长程工作，再看三个补充信号
先看跨领域长程任务中的恢复与回退，再用三项软件工程研究补充续跑、交付和验证行为。四项研究的任务、模型设置与统计口径不同，应分别理解；现有结果还不足以概括 LoopX 的普遍增益。
LHTB：比 Plain 和原生 Goal 多做成了什么？
GPT-5.6 Sol / max · 46 个匹配任务 · 每题每臂一条有效运行
LHTB 考什么：Long-Horizon Terminal-Bench 要求 Agent 在有状态的容器中，跨数百个有依赖的终端动作完成工作。46 题覆盖九类：软件与逆向工程、科学计算、地球/气候/能源、多模态、研究复现、系统/性能/安全、游戏、APEX 专业工作流、逻辑谜题。比如迁移旧框架、复现论文、完成投行交付或逐步玩 2048。类别与代表任务 →
怎样评分：隐藏验证器检查最终产物或可重放结果，给出 0–1 的 Reward；本研究以 ≥ 0.95 计为通过。平均进展与完整验收分别报告。
| 执行方式 | 平均 Reward | 通过 / 46 |
|---|---|---|
| Plain | 0.4218 | 7 |
| 原生 Goal | 0.4475 | 4 |
| LoopX Heartbeat（1.0.3） | 0.4948 | 7 |
观察：相对 Plain，LoopX 均分增加 0.0731（17.3%），逐题为 17 胜、13 平、16 负，通过数相同；相对原生 Goal，均分增加 0.0473（10.6%），为 23 胜、13 平、10 负，通过数从 4 到 7。胜负按公开原始分数严格比较；均分提升不代表每题都更强。
哪些题更受益：按任务要求做事后分组，研究复现/建模（4 题）相对 Plain / Goal 的平均差为 +0.2802 / +0.2179；逻辑谜题（4 题）为 +0.2739 / +0.1374。去掉 Tabular，研究组仍正向。Sokoban 能保留已解关卡，Rush Hour 要记录并复查长路线，Tabular 要反复实验与验证——这是值得检验的适用条件。
哪里没有清晰优势：多模态（6 题）为 −0.0034 / +0.0058，科学计算与仿真（7 题）为 +0.0161 / +0.0099。游戏组不能一概而论：2048 提升，Snake 却低于 Plain；APEX 法律事项低于 Goal，DuckDB 更是 0 对约 0.770。持续推进不能替代感知、领域判断与正确性验收。
Insight：优先关注“能验证下一步，也能保留有效进展”的任务。全体逐题差值中位数，对 Plain 为 0、对 Goal 约 0.0003，均分收益集中。分组每类仅 4–7 题，且不是官方逐题分类；题目结构只提供解释假设，尚不能确认实际收益来自哪种机制。九组的样本量、胜平负、敏感性与题目原文 →
范围：这里的 LoopX 是实验中的 1.0.3 fresh-exec Heartbeat。运行设置不同，且包含更长时限的替代 trial，没有重复 seed。LoopX 记录成本 $551.73，高于 Plain / Goal 的估算 $212.97 / $344.25；计费口径也不一致，尚不能宣称同预算效率优势。
SWE-Marathon：续跑要补上真实缺口
GPT-5.6 Sol / high · 15 个匹配任务 · 3 个保留模式，每格运行 1 次 · 超时系数 0.3
观察：原生 Goal 完成 4/15，Heartbeat 完成 5/15；两组总成本从 $533 增至 $830，约多 56%。
Insight：zstd 个案中，续跑补充了可见测试之外的验收；excel 个案多次续跑仍未完成。值得追查的是下一轮补了什么缺口，以及这份收益是否值得新增成本。
范围：每格只有一次运行，多项机制同时变化。已有个案收益，也有无效续跑；尚不能确认稳定增益或成本优势。
DeepSWE × Sol：完成差异要拆开看
脚本默认 GPT-5.6 Sol / xhigh · 113 个任务 · 历史 best-valid 汇总
观察：裸 Codex、原生 Goal、Heartbeat 分别完成 54、60、70 题。Heartbeat 比 Goal 多 10 题，但默认时间窗口也更长。
Insight：源码把“继续执行”与“有效交付”分开处理：worktree 中有代码，收集器仍可能拿到空补丁。应分别检查恢复、补丁交付与独立验收，再追查它们对完成差异的贡献。
范围：每任务取最佳有效结果，非单次通过率；预算不同，尝试次数和成本未完整披露。合入未复验成绩，不能视为同预算净增益。
DeepSWE × V4 Flash max：让反例改变实现
DeepSeek V4 Flash / max + Codex · 冻结 113 题 · 按相同 hint 条件比较 Goal 与 LoopX
观察：LoopX 的按题平均 feature 覆盖高约 2 个百分点。两组均有 hint 的事后长时切片中，完成数从 12/29 增至 14/29，累计耗时少 16.4%。
Insight：精选案例里的差别在于，失败反例是否被保留，外部契约能否推翻实现假设。验证的价值要体现在修复与复验上，而不只是增加检查次数。
范围：覆盖不等于成功率；长时切片为事后分组，耗时包含成功与失败运行。局部发现不能外推为总体提升或等质量加速。
让进度可恢复，让已有成果可保留，再检查续跑是否补上了验收缺口。
四项研究提供了局部正向观察，也暴露了回退、成本和归因问题。下一步需要在匹配预算和重复实验中，分别验证恢复、回滚、交付与反例驱动修复的收益。
SWE-Marathon 与 DeepSWE × Sol 已撤回的 SSH Goal、Codex CLI 成绩和结论均不用于这里的比较。
02 / 在开放探索中找路
“找到一个更好的算法方案”没有预先写好的完整任务链。真正的进展可能是验证一个假设，也可能是排除一条看似有希望的路线。只保留成功结论，下一轮就容易重试已被否定的想法。
Explore 已有可选的证据图和有界分支规划：节点表示问题与发现，关系表达 supports、refutes、leads_to。规划建议需要经过正常执行边界，图本身不启动 Worker，也不授予花费权限。
Auto Research 把这一思路组织成研究工作：选题、提出假设、执行实验、独立评价、形成报告。现有协议与命令提供了基础，公开 showcase 文档仍包含蓝图和待验证项；实际效果需要在具体任务中证明。
RSI 放在这里，但收紧含义
如果改进对象变成 Agent 自己的工具、策略或 Harness，就进入自改进研究。能修改自身代码，只是能够提出候选版本；持续变强还需要独立评价、跨任务泛化、回归检查和回滚。
把历史经验用于下一次决策、自动生成实验、修改 Harness，是不同层次。这里可以讨论通往递归自改进（RSI）的实验路径，不能把“自动迭代”直接说成已经实现开放式自我提升。
03 / 持续承担交付责任
一个 PR / issue fix 数字员工，工作的起点是“这件事是否值得修”，交付后还要面对 CI、评审意见、分支变化和合并结果。任务不断到来，外部事实也不断变化。
生成补丁之后，责任还没有结束。
下面用一个构造场景说明：修复已提交，CI 和评审仍在进行。点击外部状态，看下一步如何改变。
- 外部事实
- GitHub 返回当前修订的 checks pending。
- 领域状态
- 记录 PR、修订与检查状态；相同观察无需制造新进展。
- 能力提出下一步
- 保留监控和恢复条件，等待结果。
- 控制面检查
- 按授权、预算和执行资格准入；等待范围之外的工作仍可推进。
- 对人的意义
- 没有重要变化时保持安静，避免把轮询变成催促。
交互图为设计说明，不连接真实仓库，也不执行任何 GitHub 操作。
“数字员工”在这里意味着有持续职责、边界、记忆与反馈闭环。是否值得使用，要看被接受的修复、重开与回归、处理时延、每次交付成本，以及需要人反复盯守多少次。PR 数量和在线时长只是过程信号。
领域越丰富，分工越要清楚
控制权与通用生命周期哪个目标与工作项有效，谁可执行，哪些授权和预算适用，怎样交接、等待与提交状态。
领域连续性这个 issue 是否可修，PR 对应哪个修订，CI 和评审到了哪一步，哪些结论仍然有效。
结果契约与判断把领域事实翻译成可验证的下一步：修复、等待、交给人判断或收口，并定义这个场景怎样验收。
外部读写与实际执行调用代码仓库、测试和工具，执行已授权动作并回读结果。GitHub 仍拥有代码、CI 和评审的外部事实。
以 checks failing 为例：领域能力可以提出一个修 CI 的后继任务；它不能因“需要修”就自行得到写仓库或合并权限。换成实验任务，CI 状态变成指标和留出集结论，通用的认领、授权、恢复规则仍应保持一致。
这也是 Capability 的价值：把一个场景中反复出现的判断与结果契约沉淀下来。它并不要求把所有业务阶段都写进 Kernel。
演进：每一步增加一种可验证的能力
- 单次执行 → 可恢复的长程任务换会话、进程中断后，仍能恢复目标、证据与下一步。先证明一件事能可靠做完。
- 通用任务 → 垂域交付与探索用 issue-fix 和研究任务承接真实工作，保留领域状态，定义有价值的结果。
- 单个 Agent → 小团队协作先让 2–3 个 Worker 完成两轮依赖交付：接收产物、独立验收、吸收纠偏，并把结果送回。
- 本地协作 → 跨 Host 的持续工作验证共享状态、权限撤回、旧执行者隔离、网络故障和共同预算；注册成功不等于协作成立。
- 可持续运行 → 可衡量地改进用结果反馈改善选择、记忆与策略；用对照实验、留出验证和回滚证明收益。规模扩张另行验收。
以上是建设顺序与验证目标，不是完成清单。现有基础、局部实现、蓝图和端到端资格应分别理解。
我希望交给 Agent 的，逐渐从一条指令变成一份可以持续履行的工作约定。
这份约定要让人看得懂、改得动，让 Agent 接得住，也让失败之后仍有证据可查。
公开依据与延伸阅读
技术内容仅据公开仓库材料整理。源码与数据引用固定到本次读取修订；历史实验使用其自身版本。本页没有新增实验结果。
- LHTB：与 Plain、原生 Goal 的对比；46 题公开聚合数据；实验设置与范围；简报中的机制与正反案例；LHTB 官方说明。研究贡献者见原文。
- SWE-Marathon：持续自我验证；设置、正反个案与局限；公开聚合数据。贡献者与案例来源见研究原文。
- DeepSWE × Sol：从继续执行到有效交付。独立研究简报，含 113 任务历史结果、机制图与固定修订的一手来源；研究归档贡献：@gwh6669999，#4502。
- DeepSWE × V4 Flash max：从提示到行为；披露范围；固定修订的图表、案例与指标。
- Explore：证据图、规划与权限边界。
- Auto Research：公开蓝图与命令路径。
- PR / Issue Fix：State Kernel 与领域状态如何协同。
- 整体路线图：产品目标与独立验收里程碑。
- 从一次性 Agent 到长程控制面；LoopX：长程 Agent 的原生 Kanban。