先问两件事：什么算完成，怎样做成？
面对一项交给 Agent 的工作，我会先拆开两种不确定性：目标是否明确，过程是否明确。知道自己要什么，和知道怎样得到它，是两回事。
目标明确，是能说清结果、约束与验收标准；过程明确，是已有可复用的做法。步骤很多的流程，也可以很明确；一句“把系统优化好”，却可能同时缺少结果标准和求解路线。
右上：目标、过程都明确。按既定格式转换数据、运行已验证的发布流程，重点在可靠执行。短小的工作用脚本或 Workflow 就很好；如果还要跨天等待、处理中断、对后续结果负责，才出现额外的长程管理需求。
左上：过程明确，目标仍模糊。团队知道怎样写周报，却未必说清它应该帮助谁做什么决策。这时应先澄清读者、价值标准和取舍。把熟悉的流程加速，并不会自动让结果更有用。
右下对应 01，左下对应 02。前者知道终点，需要找路；后者连下一步值得追求什么，也要通过探索逐渐弄清。探索仍然可以约定本轮要回答的问题、证据要求和停止条件，目标模糊不等于无限续跑。
03 是横跨象限的持续职责。一个长期维护仓库的 Agent，可能先澄清性能诉求，再探索瓶颈、完成修复、跟进 PR。它既承担复杂任务，也承担探索，还要在新反馈到来时继续负责。
工作的不确定性，决定该保留什么；
责任的持续性，决定要保留多久。
01 / 把复杂任务做完
“实现一个符合规范的解码器”听起来很确定。但可见样例通过之后，仍可能遗漏边界输入、内存安全和兼容性；重开一个会话，又可能丢掉此前确认的失败条件。
LoopX 的作用，是让目标和验收缺口跨轮次保持连续，让新证据进入下一步决策。模型负责实现与判断，领域验证器负责检验结果；控制面记录哪些结果被接受、哪些工作仍未完成。
这里要保留的不只是完成了哪些步骤，还包括当前验收版本、未解决的缺口、尝试过的修复，以及每条验证绑定的产物版本。任务列表耗尽而验收未满足，下一步仍是重新规划；人修改了兼容性要求，旧版本的通过记录也不能代替新验收。
适合它的任务，通常会经历多轮验证、等待或交接。短小、一次会话就能验收的工作，现有 Agent 可能已经足够，新增控制面需要证明自身开销值得。
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 数量和在线时长只是过程信号。
持续职责还需要明确何时唤醒、何时保持安静、何时必须交给人：新的评审意见可以成为工作输入，未变化的 CI 等待无需反复打扰；权限不足、目标取舍或超出预算，则需要明确停点。一次修复可以完成，维护职责仍可继续；持续职责也应当能被暂停、撤回或交接。
工作会跨越象限，状态必须跟得上
以维护服务性能为例。最初只有“让系统更快”，人和 Agent 先确定负载、指标与兼容边界；结果标准明确以后，还要探索瓶颈在哪里。找到修复路线，工作再转为实现与验收；提交之后，又进入评审、反馈与回归跟进。
这种移动不是单向升级：一次新反馈可能改变目标，一条反例可能推翻路线。探索出来的稳定方法可以沉淀为常规流程，常规流程遇到新条件又需要重新探索。Agent 需要识别当前剩下的是目标分歧、路线不确定，还是纯粹等待。
任务名并不决定位置，当前掌握的信息才决定位置。同样叫“调研”，如果已经约定问题、交付与评分，就可以按验收明确的任务管理；同样叫“重构”，如果方法已成熟，也可以更多依靠既定流程。两条轴描述程度，象限只标出常见的工作形态。
因此，交接时有价值的状态包括：当前目标与约束、为什么选择这条路线、已经被否定的方案、产物与验收版本，以及下一次继续或停止的条件。只保存聊天摘要或“已完成第几步”，很难承接这些变化。
同一项工作可以更换模型、会话或执行者，但目标的修订、失败证据与尚未履行的责任应当连续。这也是长程控制面在三个场景中的共同位置。
领域越丰富，分工越要清楚
控制权与通用生命周期哪个目标与工作项有效，谁可执行，哪些授权和预算适用，怎样交接、等待与提交状态。
领域连续性这个 issue 是否可修，PR 对应哪个修订，CI 和评审到了哪一步，哪些结论仍然有效。
结果契约与判断把领域事实翻译成可验证的下一步：修复、等待、交给人判断或收口，并定义这个场景怎样验收。
外部读写与实际执行调用代码仓库、测试和工具，执行已授权动作并回读结果。GitHub 仍拥有代码、CI 和评审的外部事实。
以 checks failing 为例：领域能力可以提出一个修 CI 的后继任务；它不能因“需要修”就自行得到写仓库或合并权限。换成实验任务，CI 状态变成指标和留出集结论，通用的认领、授权、恢复规则仍应保持一致。
这也是 Capability 的价值：把一个场景中反复出现的判断与结果契约沉淀下来。它并不要求把所有业务阶段都写进 Kernel。
什么时候值得加一层长程控制面？
象限说明工作的不确定性，跨轮次的连续性需求决定是否需要额外的状态管理。一个小时就能验收的探索，未必需要长程系统；路线完全明确的发布，却可能因跨天等待、多人接手和外部反馈而需要它。
- 复杂任务：换会话后，需要重新解释验收、恢复修复进度，或重复确认此前已经发现的缺口。
- 开放探索：多条路线并行，失败经验容易丢失，下一轮需要根据证据而非印象分配投入。
- 持续职责：新任务、评审或外部结果不断到来，人不得不充当调度器和催办员。
这些地方，状态外置化才有具体的价值。引入 LoopX 后，应检查有效产出是否增加、回退和重复工作是否减少，以及人是否少花了管理注意力；同时计算新增的执行与维护成本。
我的目标始终是让 Agent 多干活、人少操心。把探索、执行与持续职责拆开，是为了让不同工作得到合适的管理方式，让人的判断用在值得介入的地方。
Benchmark：从 LHTB 看长程工作，再看三个补充信号
多数 benchmark 已经给定验收，主要检验“目标明确、路线未定”的求解能力。即使一道题要求探索算法，最终要提交什么、如何评分仍然已知；这和开放地选择研究方向、持续承担维护职责，是不同层面的工作。
先看跨领域长程任务中的恢复与回退，再用三项软件工程研究补充续跑、交付和验证行为。四项研究的任务、模型设置与统计口径不同，应分别理解；现有结果还不足以概括 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 成绩和结论均不用于这里的比较。
演进：每一步增加一种可验证的能力
- 单次执行 → 可恢复的长程任务换会话、进程中断后，仍能恢复目标、证据与下一步。先证明一件事能可靠做完。
- 通用任务 → 垂域交付与探索用 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。