裸 Codex
使用 codex app-server,不启用 Goal 或 LoopX,按单次执行方式工作。
From f26910438023cc1cb049e3a831086669d7601b1c Mon Sep 17 00:00:00 2001 From: huangruiteng <14976749+huangruiteng@users.noreply.github.com> Date: Fri, 18 Sep 2026 01:35:46 +0800 Subject: [PATCH] feat(site): publish application scenarios and DeepSWE Sol research brief Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com> --- apps/presentation/site/README.md | 15 ++ .../public/benchmarks/deepswe-sol/index.html | 137 ++++++++++++ .../public/benchmarks/deepswe-sol/study.css | 148 +++++++++++++ .../blog/zh/application-scenarios/index.html | 195 ++++++++++++++++++ .../zh/application-scenarios/presentation.js | 28 +++ .../site/public/blog/zh/index.html | 4 + apps/presentation/site/src/App.tsx | 7 +- apps/presentation/site/vite.config.ts | 4 +- .../dashboard-frontstage-browser-smoke.mjs | 4 +- ...board-frontstage-design-baseline-smoke.mjs | 2 +- examples/export-frontstage-share-bundle.mjs | 4 + examples/frontstage-share-bundle-smoke.mjs | 27 ++- 12 files changed, 565 insertions(+), 10 deletions(-) create mode 100644 apps/presentation/site/public/benchmarks/deepswe-sol/index.html create mode 100644 apps/presentation/site/public/benchmarks/deepswe-sol/study.css create mode 100644 apps/presentation/site/public/blog/zh/application-scenarios/index.html create mode 100644 apps/presentation/site/public/blog/zh/application-scenarios/presentation.js diff --git a/apps/presentation/site/README.md b/apps/presentation/site/README.md index a480765c7..b4a27ec8a 100644 --- a/apps/presentation/site/README.md +++ b/apps/presentation/site/README.md @@ -20,6 +20,21 @@ navigation work without JavaScript. Vite copies these pages into both the local build and the existing Pages export; no separate hosting or content service is needed. Relative navigation supports both root and repository base paths. +The Chinese DeepSWE × Sol research brief is a static page at +`public/benchmarks/deepswe-sol/`, linked from the homepage research collection. +It uses the shared editorial tokens and ships through the same public-directory +copy as the Blog. Its historical results and mechanism explanations cite the +immutable v1 archive; editing the brief must not rewrite that archive or restore +withdrawn scores. The article works without JavaScript and has stable section +anchors for other articles to cite. + +The Chinese application-scenarios article at `public/blog/zh/application-scenarios/` +links the three research briefs with comparable summaries. Its full text and +initial PR-state example are static HTML; `presentation.js` progressively adds +presentation typography, section navigation, and the synthetic state selector. +These controls stay hidden when JavaScript is unavailable. No real repository +state or write APIs are involved. + Edit the paired HTML editions together, including their index summaries and metadata. Preserve matching section anchors and public source attribution. Keep source-document exports, private references, and unreviewed media outside diff --git a/apps/presentation/site/public/benchmarks/deepswe-sol/index.html b/apps/presentation/site/public/benchmarks/deepswe-sol/index.html new file mode 100644 index 000000000..08552af5b --- /dev/null +++ b/apps/presentation/site/public/benchmarks/deepswe-sol/index.html @@ -0,0 +1,137 @@ + + +
+ + + +DeepSWE · GPT-5.6 Sol · v1 研究解读
+113 个软件工程任务,把长程 Agent 的三个问题放到一起:工作怎样继续,补丁是否交付,结果是否正确。
+研究归档贡献 @gwh6669999 ↗
2026 年 9 月 16 日合入 · 实验修订 2cef51d
113 TASKS / HISTORICAL BEST-VALID
+01 / RESULTS
Heartbeat 相比原生 Goal 多完成 10 个任务,完成比例相差约 8.8 个百分点。这是值得继续研究的观察;汇总表本身还不能说明,差异来自额外计算量、恢复策略,还是交付修复。
| 配置 | 完成任务 | 完成比例 | Partial | F2P | P2P |
|---|---|---|---|---|---|
裸 Codex plain | 54 / 113 | 47.8% | 0.9206 | 0.745 | 0.997 |
原生 Goal goal | 60 / 113 | 53.1% | 0.9620 | 0.868 | 0.997 |
LoopX + Heartbeat heartbeat | 70 / 113 | 61.9% | 0.9739 | 0.886 | 0.993 |
Partial、F2P 与 P2P 沿用原表字段;F2P 关注失败测试转为通过,P2P 关注原有通过测试是否保持通过。公开归档未提供逐题归约数据与完整计分脚本,本页不重新定义权重,也不将这些比例当作独立任务数。
+原生 Goal 相比单次执行已经出现差异;Heartbeat 的历史完成数进一步上升。三组 P2P 均接近 1,但 Heartbeat 略低,不能只用完成数概括全部质量变化。
没有逐任务的成败配对,无法知道哪些任务转正或转负;没有完整尝试次数和成本,无法估计成功率稳定性、单位成本收益或单项机制的因果效应。
02 / EXECUTION CONFIGURATIONS
这五种配置同时改变了运行接口、状态组织和继续方式。它们提供不同的实验切口,不能看成只开关一个功能的消融实验。
使用 codex app-server,不启用 Goal 或 LoopX,按单次执行方式工作。
仍使用 app-server;原生 Goal 保持活跃时,由 app-server 继续推进。
首次调用 codex exec,取得会话标识后使用 resume;外部 supervisor 读取 LoopX 状态,分段推进并检查交付。
由外部调用 loopx turn run-once --host codex-cli,组织多段执行。
使用 app-server,在同一会话与 Goal 中处理 blocked 状态并重新启动 turn。
配置描述来自归档 README 与运行器源码,只说明历史实验怎样组织执行;不证明当前 LoopX 全部能力已经得到验证。
+03 / CONTINUATION
归档里的 supervisor 并非只重复一句“继续”。它取回任务提示,恢复已有会话,检查代码交付和工作项状态,再决定结束或进入下一轮。
heartbeat-prompt --thin
取出当前任务,附加补丁交付要求。
exec → exec resume
从事件中保留会话标识,限制单段运行。
normalize_delivery
整理补丁,再读取 P0 工作项状态。
交付与状态同时满足才收口;缺失交付时补修复工作项。
supervisor 返回执行完成;功能正确性仍交给独立验证器。
新增交付修复 Todo,在剩余预算内继续。
返回失败,不把已运行很久当作完成依据。
历史函数 _goal_terminal 实际检查 Todo 列表:至少存在一个 P0 项,且所有 P0 项处于 done 或 deferred。它没有直接证明整个业务目标完成,也不验证补丁功能。
默认最多唤醒 8 次,轮间间隔 5 秒,单段超时 7,200 秒、总窗口 14,400 秒;命令行可覆盖这些值。单段子进程超时后 supervisor 仍可继续判断。这些是源码中的默认配置,不是历史每个任务的实际唤醒数或耗时。
继续执行需要判断依据,停止执行也需要。
+04 / DELIVERY & VERIFICATION
归档记录了一个具体的交付边界:Agent 可以在关联 worktree 中开发,但 DeepSWE 从主工作目录收集 git diff <base> HEAD。代码存在、提交存在,仍可能没有进入最终收集的产物。
修改与提交
可应用 · 非空 · 内容一致
交给独立验证器
workspace_delivery.py;不代表每次历史运行都发生了 worktree 恢复。枚举工作树,收集相对任务基线的补丁,并按补丁哈希去重。没有改动时返回 empty;存在多个不同补丁时返回 ambiguous。只有唯一补丁才继续检查可应用性、恢复到主目录,并核对恢复前后的哈希。
交付整理器确认“补丁被交到了正确位置”。研究口径还要求无运行异常、任务校验和匹配、独立验证结果存在且一致。功能是否正确由验证器判断,不能用流程终态或非空补丁代替。
历史整理器会提交未提交的改动,并在隔离实验工作区恢复补丁。这是运行器介入交付的行为。成功提交不一定完全由 Agent 自主完成;缺失交付也不一定意味着模型不会解题。比较时应把生成代码、运行器恢复和最终验证分开记录。
这份实现会对实验主目录执行重置与补丁恢复,依赖专用、隔离的任务环境。本文解释它的交付机制,不把原脚本当作日常仓库操作指南。
流程完成、产物交付、功能正确,是三个要分别验证的事实。
+05 / SCOPE & NEXT EXPERIMENT
这份贡献提供了可读的运行器和历史汇总。要进一步判断哪种机制有效,需要把计算预算、重复尝试和交付处理重新放到可对照的实验里。
| 维度 | 已公开的依据 | 对结论的影响 |
|---|---|---|
| 模型与推理强度 | 两个启动脚本默认 openai/gpt-5.6-sol / xhigh。 | 逐次运行配置未公开,默认值不等于每次调用的证明。 |
| 时间与资源 | remaining59 脚本给 LoopX 的 Goal 超时为 14,400 秒,plain / goal 为 3,600 秒;LoopX 另设 3.0 的 agent timeout multiplier。 | 不是等预算对比;超时上限也不是实际耗时。不能推导成本效率。 |
| 聚合与尝试 | 113 任务,逐任务选最佳有效结果;没有完整逐题尝试清单。 | 不是 pass@1,无法重建成败配对、方差或置信区间。 |
| 版本与复现 | 实验基于 2cef51d。原始 14 个文件归档;依赖外部任务定义、支持模块与运行环境。 | 不是独立可运行的发布包。文件身份、语法与导入检查不等于实验复现。 |
| 已知执行缺陷 | 归档说明保留了 59 任务启动器与 54 任务准入不匹配、profile 初始化竞争、启动和重试处理等问题。 | 不能把准入回执视为每次运行均有效的保证;需要在修复后的独立实验中验证。 |
06 / SOURCES
本文只使用公开归档与源码,引用固定到读取修订。没有运行新实验,没有新增或恢复已撤回的成绩。
场景与实践 · 长程 Agent
+有些工作需要把一件事做完,有些需要找到下一条值得走的路,还有些需要长期对结果负责。它们需要不同的领域能力,也需要跨会话保留下来的目标、证据与约束。
+重构、迁移、协议实现。终点比较明确,执行路线仍有不确定性。
保留:验收缺口、版本、修复证据调研、算法实验、系统优化。下一条路线由新证据不断改变。
保留:假设、反证、候选方向接收 issue、修复、跟进评审,处理新反馈,并对结果持续负责。
保留:职责、外部状态、等待条件这三类可以嵌套。一个长期维护仓库的 Agent,可能先探索性能问题,再完成一项验收明确的修复,最后持续跟进 PR。前两类主要描述工作如何求解,第三类还增加了持续的职责与到达的新任务。
+真正延续下来的,应当是工作及其判断依据。
+“实现一个符合规范的解码器”听起来很确定。但可见样例通过之后,仍可能遗漏边界输入、内存安全和兼容性;重开一个会话,又可能丢掉此前确认的失败条件。
+LoopX 的作用,是让目标和验收缺口跨轮次保持连续,让新证据进入下一步决策。模型负责实现与判断,领域验证器负责检验结果;控制面记录哪些结果被接受、哪些工作仍未完成。
+适合它的任务,通常会经历多轮验证、等待或交接。短小、一次会话就能验收的工作,现有 Agent 可能已经足够,新增控制面需要证明自身开销值得。
+三项研究分别观察续跑、交付和验证行为。任务、模型设置与统计口径不同,应分别理解;现有结果还不足以概括 LoopX 的普遍增益。
+ +GPT-5.6 Sol / high · 15 个匹配任务 · 3 个保留模式,每格运行 1 次 · 超时系数 0.3
+观察:原生 Goal 完成 4/15,Heartbeat 完成 5/15;两组总成本从 $533 增至 $830,约多 56%。
+Insight:zstd 个案中,续跑补充了可见测试之外的验收;excel 个案多次续跑仍未完成。值得追查的是下一轮补了什么缺口,以及这份收益是否值得新增成本。
+范围:每格只有一次运行,多项机制同时变化。已有个案收益,也有无效续跑;尚不能确认稳定增益或成本优势。
+ +脚本默认 GPT-5.6 Sol / xhigh · 113 个任务 · 历史 best-valid 汇总
+观察:裸 Codex、原生 Goal、Heartbeat 分别完成 54、60、70 题。Heartbeat 比 Goal 多 10 题,但默认时间窗口也更长。
+Insight:源码把“继续执行”与“有效交付”分开处理:worktree 中有代码,收集器仍可能拿到空补丁。应分别检查恢复、补丁交付与独立验收,再追查它们对完成差异的贡献。
+范围:每任务取最佳有效结果,非单次通过率;预算不同,尝试次数和成本未完整披露。合入未复验成绩,不能视为同预算净增益。
+ +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 成绩和结论均不用于这里的比较。
+“找到一个更好的算法方案”没有预先写好的完整任务链。真正的进展可能是验证一个假设,也可能是排除一条看似有希望的路线。只保留成功结论,下一轮就容易重试已被否定的想法。
+Explore 已有可选的证据图和有界分支规划:节点表示问题与发现,关系表达 supports、refutes、leads_to。规划建议需要经过正常执行边界,图本身不启动 Worker,也不授予花费权限。
Auto Research 把这一思路组织成研究工作:选题、提出假设、执行实验、独立评价、形成报告。现有协议与命令提供了基础,公开 showcase 文档仍包含蓝图和待验证项;实际效果需要在具体任务中证明。
+ +如果改进对象变成 Agent 自己的工具、策略或 Harness,就进入自改进研究。能修改自身代码,只是能够提出候选版本;持续变强还需要独立评价、跨任务泛化、回归检查和回滚。
+把历史经验用于下一次决策、自动生成实验、修改 Harness,是不同层次。这里可以讨论通往递归自改进(RSI)的实验路径,不能把“自动迭代”直接说成已经实现开放式自我提升。
+一个 PR / issue fix 数字员工,工作的起点是“这件事是否值得修”,交付后还要面对 CI、评审意见、分支变化和合并结果。任务不断到来,外部事实也不断变化。
+生成补丁之后,责任还没有结束。
+下面用一个构造场景说明:修复已提交,CI 和评审仍在进行。点击外部状态,看下一步如何改变。
+ +交互图为设计说明,不连接真实仓库,也不执行任何 GitHub 操作。
+“数字员工”在这里意味着有持续职责、边界、记忆与反馈闭环。是否值得使用,要看被接受的修复、重开与回归、处理时延、每次交付成本,以及需要人反复盯守多少次。PR 数量和在线时长只是过程信号。
+以 checks failing 为例:领域能力可以提出一个修 CI 的后继任务;它不能因“需要修”就自行得到写仓库或合并权限。换成实验任务,CI 状态变成指标和留出集结论,通用的认领、授权、恢复规则仍应保持一致。
这也是 Capability 的价值:把一个场景中反复出现的判断与结果契约沉淀下来。它并不要求把所有业务阶段都写进 Kernel。
+以上是建设顺序与验证目标,不是完成清单。现有基础、局部实现、蓝图和端到端资格应分别理解。
+我希望交给 Agent 的,逐渐从一条指令变成一份可以持续履行的工作约定。
+这份约定要让人看得懂、改得动,让 Agent 接得住,也让失败之后仍有证据可查。
+技术内容仅据公开仓库材料整理。源码与数据引用固定到本次读取修订;历史实验使用其自身版本。本页没有新增实验结果。
+LoopX · 博客
关于长程 Agent 的设计、工程与实践。
场景 · 实践与研究
2026 年 9 月 18 日
沿三个工作场景理解目标、证据与交付责任,并列解读 SWE-Marathon、DeepSWE × Sol 与 V4 Flash max 的研究信号。
阅读全文Agent-native Kanban · 长程协作
2026 年 9 月 15 日