From ff34eb8f4f11028b2dece7ef9b976f22944ac273 Mon Sep 17 00:00:00 2001 From: LoopX Agent <337587101+loopx-agent@users.noreply.github.com> Date: Fri, 16 Oct 2026 20:51:33 +0800 Subject: [PATCH 1/2] docs(blog): scope historical EdgeBench and LHTB conclusions Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com> --- .../edgebench-long-horizon-repairs/index.html | 90 ++++++++--------- .../fixed-borden-score-time-en.svg | 8 +- .../fixed-borden-score-time.svg | 10 +- .../local-score-time-en.svg | 8 +- .../local-score-time.svg | 18 ++-- .../score-time-en.svg | 10 +- .../score-time.svg | 10 +- apps/presentation/site/public/blog/index.html | 2 +- .../edgebench-long-horizon-repairs/index.html | 96 +++++++++---------- .../site/public/blog/zh/index.html | 2 +- 10 files changed, 133 insertions(+), 121 deletions(-) diff --git a/apps/presentation/site/public/blog/edgebench-long-horizon-repairs/index.html b/apps/presentation/site/public/blog/edgebench-long-horizon-repairs/index.html index a463db7270..463ea11db0 100644 --- a/apps/presentation/site/public/blog/edgebench-long-horizon-repairs/index.html +++ b/apps/presentation/site/public/blog/edgebench-long-horizon-repairs/index.html @@ -3,15 +3,15 @@ -Why the agent stood still after 24 hours: one repair round for LoopX long runs · LoopX - +EdgeBench / LHTB: notes from historical runs · LoopX + - - + + @@ -19,39 +19,39 @@
← LoopX Blog中文
-

songoow · October 16, 2026 · Interim research note · Evidence cutoff 03:10 UTC

-

Why the agent stood still after 24 hours

-

One repair round for LoopX long runs: four failure classes, who owns them, and what remains unproven

-

The previous article recorded interim progress on Portfolio and Lean. This round put the same system on a longer clock: 24-hour paired runs against native Codex, plus 90-minute LHTB tasks to test whether goals close too early. The results are not flattering, but they are clear. The LoopX agent kept working while its score did not move; the native control changed methods three times in the same window.

-

This article explains what happened behind those curves. Each of four failure classes has a locatable cause: the first external feedback arrived too late; every review point crashed a wake; review was allowed to “retain the path”, so ten hours went into tuning one solver; and on LHTB the goal declared itself done while the hidden score was far from passing. We label every repair as a product change or a harness change—that distinction decides what a rerun can prove.

-

Our reading: this round mostly exposed product problems, not model problems. Native Codex reached better scores with the same model. Some repairs are complete and verified against the real CLI; others are only directions. The text keeps them apart.

+

songoow · Oct 16, 2026 · Exploratory notes · Historical cutoff 03:10 UTC

+

EdgeBench / LHTB: notes from historical runs

+

Historical builds, interrupted runs and untested hypotheses

+

These are the author’s exploratory notes on historical builds, not official or formal LoopX evaluation results. They do not establish current capability, efficiency or relative performance.

+

The option was withdrawn: #6612 removed --feedback-first and its planning switch. Scores below come from historical combined builds; they neither evaluate the current version nor isolate one change.

+

This round records Borden and Grid runs with planned 24-hour budgets that ended early, plus 90-minute LHTB pilots. The traces help locate engineering issues in submission order, review handoff, repeated tuning and closure evidence. The article separates reproducible local defects, explanations not yet isolated and the author’s proposed follow-up tests, retaining failures, interruptions and counterexamples.

- +

1. What this round asks

-

The last round concluded that the system as a whole had become more effective, but that contributions were not yet separated. This round switched to two task families to approach a sharper question: when a task has a real external evaluator and the budget is long, does LoopX’s control plane make the agent use that time better, or merely keep it awake?

- +

For these particular tasks and configurations, the author asks whether submission order, review and closure evidence help sustain useful work. A few historical traces cannot settle that question. This article records locatable issues and explanations to test; it does not judge LoopX’s general long-horizon capability.

+
TaskScore directionComparisonBudgetStatus
- +
TaskScore directionComparisonPlanned budgetStatus
EdgeBench Borden source inversionhigher is betterLoopX heartbeat (planned entry) vs native Codex24 h, native feedback, 1 h submission cooldownTwo pairs; first interrupted at 12.4 h, second paused at 3 h
EdgeBench Grid Turing robotlower is bettersame24 h, samePaused at 11.7 h
EdgeBench Borden / codec / rust / jaguahigher is better in this groupCombined LoopX candidate, native official, native-goal90 min local, 15 min cooldown13 scored runs: 11 normal finals, 2 runner failures; another 2 unscored startup failures
EdgeBench Borden / codec / rust / jaguahigher is better in this groupHistorical combined LoopX candidate, native official, native-goal90 min local, 15 min cooldown13 scored runs: 11 normal finals, 2 runner failures; another 2 unscored startup failures
LHTB four tasks (covshift and others)hidden-set reward 0–1LoopX heartbeat, single arm, against a historical five-arm study90 minFour pilots finished; covshift rerun with the acceptance gate finished

EdgeBench used gpt-6.1-sol / xhigh; both arms share the model, image and evaluator. LHTB used gpt-5.6-sol / max. “Native feedback” means the agent may submit and receive a public score, with no further submission during the cooldown. The original Borden and second Grid LoopX arms enabled checkpoint capture. The second Borden pair and local combined candidates disabled checkpoints but explicitly enabled TurnEnvelope. These treatments are not one default configuration; section 7 separates them.

-

Several runs did not finish. Two causes: our own experiment controller failed (a container-count guard was tripped by another cohort’s transient judge container; the controller crashed reading a container that was exiting), and we deliberately paused everything while writing this article, to repair before rerunning. Interrupted runs remain evidence—the curves had already made their point—but they are not terminal scores.

- +

Several runs did not finish. Experiment-controller failures included a container-count guard tripped by another cohort’s judge container and a crash while reading an exiting container; other runs were deliberately paused while writing. Pre-interruption traces can support particular fault diagnoses, but missing later windows and normal closeout cannot be filled in as completed 24-hour results.

+

2. What the score curves show

-
Two score-over-time charts. Borden: native Codex first submits at 13.6 minutes and reaches 109 at 194 minutes; LoopX first submits at 48 minutes and reaches 85.6 after 12 submissions at 725 minutes. Grid: LoopX reaches 2075 at 85 minutes and barely moves for 9.5 hours, ending at 2039; native descends from 2260 to 1791.
Borden first pair (left) and Grid second round (right). Points show each submission’s native score, not best-so-far scores. LoopX submits later on Borden; on Grid its placeholder arrives at about minute 12, before native’s minute 21, but it then stays on the same path. Submission timestamps are not feedback-return timestamps.
-

Three phenomena appear on both tasks, independently of each other.

-

The first external feedback arrives late. On Borden, native Codex had its first score at 13.6 minutes; LoopX at 48.2. On Grid it was 21 versus 12 minutes, but LoopX’s first submission was a 3593 placeholder. In a task that accepts one submission per hour, 35 minutes late shifts the whole curve right by half a cooldown.

+
Selected historical runs: Two score-over-time charts. Borden: native Codex first submits at 13.6 minutes and reaches 109 at 194 minutes; LoopX first submits at 48 minutes and reaches 85.6 after 12 submissions at 725 minutes. Grid: LoopX reaches 2075 at 85 minutes and barely moves for 9.5 hours, ending at 2039; native descends from 2260 to 1791.
Historical configurations; not an evaluation of the current version. Borden first pair (left) and Grid second round (right). Points show each submission’s native score, not best-so-far scores. LoopX submits later on Borden; on Grid its placeholder arrives at about minute 12, before native’s minute 21, but it then stays on the same path. Submission timestamps are not feedback-return timestamps.
+

The following observations have different scopes within the historical runs. They suggest follow-up checks; they are not a pattern established for all LoopX runs.

+

First-submission timing and quality need separate checks. On Borden, native Codex first submitted at about 13.6 minutes and LoopX at about 48.2. On Grid, native first submitted at about minute 21 and LoopX at about minute 12, the latter with a 3593 placeholder. A submission timestamp is not the feedback-return time, and earlier submission alone does not establish a better candidate.

The curve flattens on a local solution. On Grid, LoopX reached 2075 at 85 minutes—better than native’s 2182 at the time—then spent 9.5 hours and nine submissions going from 2075 to 2039, under 2%. Native went from 2182 to 1791 in the same window and changed method three times: an embedded C++ accelerator, a dynamic-programming repair step, a sweep over cost parameters. On Borden, from its third submission LoopX changed little but one amplitude constant, gaining about two points per hour.

Submissions sometimes regress. In the first Borden pair, 3 of LoopX’s 11 valid submissions regressed; in the second pair it fell from 68.1 to 41.7, and the evaluator report shows why: the public error improved while the hidden-well error rose from 0.09 to 0.74—it was fitting the public data. Native regressed too (54.7 to 50.3), so this is not specific to LoopX, but every regression costs a cooldown slot.

-

Native’s 109 on Borden needs its own note. The evaluator report returns aggregate metrics for the hidden set, and both the native arm and the fixed LoopX build in local short runs reached 109 by fitting those metrics. That is a protocol leak, not modelling skill; we record it as a task issue and count it as capability evidence for neither side.

-

Local supplement: earlier submission did not yield a win across tasks

+

Native’s 109 on Borden needs its own note. The evaluator report returns aggregate metrics for the hidden set, and both the native arm and the historical combined LoopX build in local short runs reached 109 by fitting those metrics. That is a protocol leak, not modelling skill; we record it as a task issue and count it as capability evidence for neither side.

+

Historical local supplement: timing and scores show no consistent advantage

The local report covers four tasks, 13 scored runs and 71 native submissions. They shared a four-CPU, 16-GiB host; resource ceilings were not exclusive reservations. The chart below starts each arm at its first native-session record, places each submission at submitted_at, and plots the best score through that submission. Lines only connect observations and end at the last submission; there is no fitted function, confidence band or invented zero.

-
Five local best-score comparisons. Combined LoopX reaches 109 on Borden using aggregate feedback inversion; codec 24.714 trails official 28.620; all Rust arms end around 26.5 to 26.6; LoopX scores 22.655 and 7.743 in the two Jagua comparisons, below official in both. Native-goal Rust and Jagua have scores but lack normal finals.
Local 90-minute budgets; higher is better, with independent task scales. Blue circles: combined LoopX; orange squares: native official; grey dashed triangles: native-goal. Scroll horizontally on a phone or open the original image. Asterisks mark runner failures, not invalid scores.
- +
Selected historical runs: Five local best-score comparisons. Combined LoopX reaches 109 on Borden using aggregate feedback inversion; codec 24.714 trails official 28.620; all Rust arms end around 26.5 to 26.6; LoopX scores 22.655 and 7.743 in the two Jagua comparisons, below official in both. Native-goal Rust and Jagua have scores but lack normal finals.
Historical configurations; not an evaluation of the current version. Local 90-minute budgets; higher is better, with independent task scales. Blue circles: historical combined LoopX; orange squares: native official; grey dashed triangles: native-goal. Scroll horizontally on a phone or open the original image. Asterisks mark runner failures, not invalid scores.
+
Task / comparisonCombined LoopX bestNative official bestNative-goal best
@@ -62,14 +62,14 @@

Local supplement: earlier submission did not yield a win

Using the explicit native-first-record clock here, combined LoopX first submits at about 1.7–3.0 minutes, versus official’s 2.8–9.7. Earlier submission did not ensure a higher final best: codec and both Jagua comparisons trailed, while Rust was close. Candidate/official uncached-input token ratios were about 1.06 on Borden, 1.31 on codec, 1.01 on Rust and 1.67 / 1.57 on Jagua. These runs did not show lower uncached input either; those ratios cannot be converted directly into total billed savings.

Second Borden pair: retain the early lead and the interruption

-
Three submissions per arm in the second Borden pair. Combined LoopX best 68.108 and official best 54.705. Both third submissions regressed, so their best-so-far curves remain flat.
Candidate 12bb5c931; checkpoints disabled, TurnEnvelope explicitly enabled. Time starts at this cohort’s controller start, unlike the local clock. Each arm has three submissions; the last scores are 41.714 and 50.347, while the plotted best-so-far scores remain 68.108 and 54.705.
+
Selected historical runs: Three submissions per arm in the second Borden pair. Combined LoopX best 68.108 and official best 54.705. Both third submissions regressed, so their best-so-far curves remain flat.
Historical configurations; not an evaluation of the current version. Candidate 12bb5c931; checkpoints disabled, TurnEnvelope explicitly enabled. Time starts at this cohort’s controller start, unlike the local clock. Each arm has three submissions; the last scores are 41.714 and 50.347, while the plotted best-so-far scores remain 68.108 and 54.705.

The controller crashed during container resource sampling; the solver processes were later stopped, leaving no normal final results. A stale status file still said running, which did not establish continued execution. The retained best scores are neither completed 24-hour results nor evidence that checkpoint recovery was repaired.

Related public reports and chart data

The frozen feedback-first observations and runner-correction report provides local outcomes, failure categories, token accounting and repair boundaries. Its remote table retains an earlier window; it does not supersede this article’s later interruption observations. The covshift acceptance-gate rerun supports the 0.82 result in section 6 and belongs to a different benchmark.

Download this section’s curve data as CSV: 71 local and 6 second-pair Borden scalar observations, retaining individual score, best-so-far score, clock origin and closeout category. This is plotting data, not task material, solutions, full trajectories or hidden evaluator details, and is insufficient to independently reproduce the complete experiments.

-

3. Late feedback: planning put the submission in the third wake

+

3. Historical planning: submission followed local preparation

The cause reads directly from the session trace and wake receipts. The planned entry has LoopX plan first, and the planner’s default profile is meant for open-ended product directions: it decomposed a bounded task with an explicit evaluator into three sequential Todos—P0 forward model, P0 inversion, P1 “once a runnable candidate exists, iterate via native evaluation”. Each execute wake finished exactly one Todo and then spent one to one-and-a-half minutes on settlement (complete the Todo, claim the next, write back vision, record quota). Submission therefore landed in wake three.

-

This is not a control-plane overhead problem. Planning itself took about 1.3 minutes and settlements a few minutes in total; the real 35-minute gap is Todo order. Putting evaluator feedback after “first get the model right”, in a task where the evaluator can tell you the direction immediately, is the wrong prior.

+

In this trace, planning took about 1.3 minutes and settlement several minutes. Todo order offers a locatable explanation for the roughly 35-minute first-submission gap in this case. But first-candidate quality, later strategy and full cost were not separately controlled. This does not establish that obtaining feedback first is always better, or attribute the entire gap to planning order.

The experimental planning constraint in #6584 put an accepted evaluation before extended local calibration. It was withdrawn in merged #6612: the current runner no longer offers --feedback-first or its planning environment switch. The submission times below describe the historical combined revisions, not a recommended activation or a validated current repair. Across the four local tasks, combined candidates first submitted at about 1.7–3.0 minutes versus official’s 2.8–9.7, using section 2’s clock. The original Borden long-run observation of about 48 minutes used different source, cooldown and operating conditions; it is not a matched “48 minutes down to 2” improvement.

The historical mechanism was a planning input on the benchmark runner’s side, not a product capability gain. It was off by default and changed work order rather than budget, submission rights or decision rules. The trace locates a delay in Todo order; the combined comparisons do not establish an isolated gain. The product question remains how shared planning balances first-deliverable quality with useful feedback; section 5 discusses the separate problem of continuing on a stalled path.

The maintainer requested withdrawal because feedback-first guidance can encourage a lower initial-quality starting point. Earlier feedback alone does not establish a better first deliverable: quality, latency and full cost need separate comparison. Submitting a competitive first candidate and a minimal one may lead later work in different directions; the historical combined runs do not isolate that effect. The original Grid trace shows prolonged iteration around a weak start, but that run did not enable the new feedback-first option. It cannot establish a side effect of that option. A matched rerun needs to test this hypothesis.

@@ -90,16 +90,16 @@

Second Borden pair: retain the early lead and the

One catch-all Todo owned ten hours. The third Todo planning produced was “submit … and continue useful local refinement”. It never closed, its lease was renewed 12 times, and no Todo was ever added. The Todo list carried no strategy: no hypothesis families, no exit criteria, no “if three submissions do not improve, change method”.

Control-plane overhead took about a quarter of the time. 188 LoopX CLI calls plus roughly 345 reads of guard packets and decision files came to about 2.8 of 11.7 hours; 207M input tokens against native’s 146M; 20 context compactions against 7. Native had almost none of this.

Why not simply add “a stalled score forces a pivot”

-

It is the most direct fix, and the first we thought of. But LoopX’s core has no numeric progress signal today. The only “progress” it knows is a classification the agent declares itself—advanced, unchanged, blocked—and the Grid agent declared advanced every round; 2041, 2040, 2039 genuinely looked like progress to it. More importantly, the accepted design explicitly forbids generic core logic from deriving a pivot from a score slope or a failure count: what a metric means is decided by the provider that produced it, not guessed by the control plane. The rule has a reason—“one fewer sorry” on Lean and “two more points” on Borden are not the same kind of progress—and we will not overturn it for one task.

-

The design already reserves a slot for this: external progress review. An independent observer writes typed “drift” receipts after each work transition; in assist mode a streak of consecutive drift receipts escalates into the existing replan obligation, and answering that obligation may not restate an old hypothesis or merely rename things—it must carry new evidence. It is off by default, and the only observer today judges code changes, not evaluator scores. It also has a product defect: when attribution is missing (no agent id, or no typed progress record in the window), assist silently never fires while status looks healthy.

-

So the repair direction is three product changes, none implemented yet: let a provider write a “metric plateau” drift signal, with direction, threshold and the stall judgement owned by the provider while the core only consumes it through the existing obligation chain; make the reason assist cannot fire visible in status; and have the planning contract reject open-ended Todos like “keep optimising”—iterative work must carry exit criteria, and the next round enters through replan. Even with all three, the agent could still answer the obligation with a “new” tuning hypothesis. What they guarantee is that ten hours of in-place tuning can no longer pass unnoticed; they do not guarantee a genuinely different method.

+

The inspected core version records progress through the agent’s self-declared advanced, unchanged and blocked classes; the Grid trace declared advanced each round. Small improvements such as 2041, 2040 and 2039 do not alone decide whether to pivot. Generic core logic should not guess the meaning of a provider metric: “one fewer sorry” on Lean and “two more points” on Borden share no pivot threshold. This motivates explicit ownership of metric interpretation and replanning; it establishes neither that the model can only tune nor that LoopX lacks progress handling.

+

The design already reserves a slot for this: external progress review. An independent observer writes typed “drift” receipts after each work transition; in assist mode a streak of consecutive drift receipts escalates into the existing replan obligation, and answering that obligation may not restate an old hypothesis or merely rename things—it must carry new evidence. In the inspected version it is off by default, and the existing observer judges code changes, not evaluator scores. It also has a product defect: when attribution is missing (no agent id, or no typed progress record in the window), assist silently never fires while status looks healthy.

+

The author proposes three directions, not yet implemented or shown to improve outcomes: let a provider own metric direction, thresholds and plateau judgement while supplying drift through the existing obligation chain; expose why assist cannot fire; and give iterative Todos checkable exit criteria. These are design hypotheses for review, not promised LoopX mechanisms or an accepted roadmap. Even if implemented, their effect on decisions and results would need testing; they cannot guarantee that an agent chooses a better method.

6. Early closure: the acceptance gate changed what counts as done

LHTB’s four pilot tasks showed one pattern. In all four runs LoopX’s scheduler emitted stop_until_explicit_resume between minutes 43 and 60 of a 90-minute budget, with the identical reason: “validated closure evidence derives no-follow-up and confirms no remaining frontier”. Hidden-set rewards at that point were 0.000, 0.028, 0.086 and 0.093. Only the outer continue-until-timeout mechanism brought the agent back; the second phase never stopped on its own.

-

This shares a root with the Portfolio no_followup failure in the previous article: all Todos being complete does not mean the original goal is met. The difference is that a hidden evaluator now tells us plainly that the evidence the agent used to decide “done” was worth nothing. On two tasks the agent’s CLI exited non-zero on the hidden wrapper manifest; on one it passed hidden schema checks and scored zero on an end-to-end stress group weighted 0.89—it had never checked its deliverable through the verification interface the task description names.

-

We did not change the scheduler rule; we changed where closure evidence comes from. #6585 adds the explicit opt-in LOOPX_ACCEPTANCE_CONTRACT=planned: during planning the model also writes a Goal acceptance document—which Todos deliver the result, which executable criteria each is bound to, criteria that must exercise the deliverable through the task’s stated verification interface—and the benchmark host, acting as the trusted local owner, configures it through the existing goal-acceptance contract. Selected Todos then cannot complete until their criteria pass, and the goal cannot close while they stay open.

-
Task / comparisonHistorical combined LoopX bestNative official bestNative-goal best
Borden109.000‡69.579Not run
Integer compression codec24.71428.62012.836
Rust multicrate reconstruction26.50626.59726.597*
+

These pilots and the earlier Portfolio no_followup case both suggest an acceptance gap: completed Todos do not establish that the original goal is met. In these runs, closure evidence did not cover the full behaviour the hidden evaluation required. Two deliverables exited non-zero under the hidden wrapper manifest; another passed schema checks but scored zero on an end-to-end stress group weighted 0.89. These cases support checking verification-interface coverage, not a general judgement of LoopX’s closure capability.

+

We did not change the scheduler rule; we changed where closure evidence comes from. #6585, now closed without merging, tested the explicit opt-in LOOPX_ACCEPTANCE_CONTRACT=planned: during planning the model also writes a Goal acceptance document—which Todos deliver the result, which executable criteria each is bound to, criteria that must exercise the deliverable through the task’s stated verification interface—and the benchmark host, acting as the trusted local owner, configures it through the existing goal-acceptance contract. Selected Todos then cannot complete until their criteria pass, and the goal cannot close while they stay open.

+
covshiftPilot (default)With acceptance gate (one run)Five-arm study heartbeat
@@ -111,35 +111,35 @@

Why not simply add “a stalled score forces a pivot”

7. Which numbers cannot be used

One finding, made while writing, forced us to requalify the evidence above.

LoopX has a TurnEnvelope that is off by default: it compresses the tens-of-kilobyte quota decision into an inline view of about 8 KB and writes the rest to a file read by reference. Checkpoint handoff appends --turn-envelope to the guard command whenever a capture directory is passed. The original Borden and second Grid runs therefore enabled the envelope implicitly; the local combined candidates and second Borden pair disabled checkpoints but explicitly enabled the envelope. The local receipts say turn_envelope=true and turn_envelope_source=explicit. None is a clean envelope-off control. Absence of that capture failure chain cannot show that disabling the envelope improved stability.

-

That in turn makes Grid the first real long-run measurement of the envelope, and the result is not encouraging: the agent read the full capture file about 345 times, 37–57 KB each—the inline part got shorter, the bytes merely moved, with an extra file read and a socket created per wake, the latter being the crash source of section 4. The roughly one-quarter control-plane overhead was measured with the envelope on. On the other hand, an unmerged experimental build relaxed the envelope’s “re-enter the guard after every workspace change” rule and cut CLI calls from 65 to 25 and quota checks from 40 to 8—the re-entry cadence, not packet size, is the lever.

-

Two conclusions follow. First, handoff and envelope should be decoupled: the quota CLI already has them as two independent switches, and only the heartbeat builder ties them together—a bounded product change. Second, before merging the quota packet and the envelope, run the validation that never happened: checkpoints off, the same task, one pair each with envelope on and off, measuring uncached tokens, packet reads, CLI calls, time share and score. The direction of the merge reads directly from this evidence: the decision text the agent must act on stays inline, full detail is read on demand through a stable CLI readback, and re-entry cadence becomes an explicit rule. That is design work, not in this round’s code.

+

Grid provides a historical observation with the envelope enabled: about 345 full capture-file reads, 37–57 KB each, and roughly one-quarter control-plane overhead recorded under that configuration. Without a matched envelope-off control, this does not attribute the overhead or score plateau to the envelope. Another unmerged combined build, with relaxed re-entry rules, recorded 65 versus 25 CLI calls and 40 versus 8 quota checks. This suggests testing re-entry cadence separately; it does not identify the sole or dominant cause.

+

Two design questions remain to be tested: whether to decouple handoff and the envelope, and how envelope on/off changes uncached tokens, packet reads, CLI calls, time share and score on the same task under matched conditions with checkpoints off. Keeping decision text inline, reading details on demand and declaring re-entry cadence are the author’s candidate directions. These observations establish neither their optimality nor a validated product conclusion.

Three more kinds of numbers must be set aside. Experiment-controller incidents—a container-count guard tripped by a judge container, a controller crashing on an exiting container—shortened runs but are not LoopX failures. Borden’s 109 comes from an evaluation protocol leak, as section 2 explains. And every “after the fix” local number carries several simultaneous changes: feedback-first, the relaxed re-entry rule, an explicit envelope; none can be attributed alone.

8. How to judge this batch of repairs

-

As before, we judge by the gap closed and the evidence, not by PR count. This time there is one more column: whether the change lands in the product or the harness. That column decides what a rerun score can prove—a runner-side fix that improves the curve proves that the runner’s input changed the result, not LoopX’s capability.

-
covshift (historical individual runs; not a paired effect estimate)Pilot (default)With acceptance gate (one run)Five-arm study heartbeat
Hidden-set reward0.0000.820.743
Self-stopminute 55minute 38, but only after all three criteria passed—
Cost$15.8$15.3—
- +

The table separates historical observations, local contract validation and hypotheses still to test. When product code, harness inputs and configuration change together, score differences cannot be attributed to one factor. A merged patch, passing local checks or a changed runner curve does not validate the current LoopX version’s general capability or efficiency.

+
GapOwnerShownNot yet shown
Late first feedbackHarness (experimental planning constraint, now withdrawn)Traces show Todo order delaying submission; local combined first submissions about 1.7–3.0 min, official 2.8–9.7 minAn isolated causal gain or preserved first-result quality; #6612 removes this option rather than accepting timing alone as success
+ - - + +
GapOwnerRecorded or locally validatedNot yet validated
Later first Borden submissionHarness (experimental planning constraint, now withdrawn)Traces show Todo order delaying submission; local combined first submissions about 1.7–3.0 min, official 2.8–9.7 minAn isolated causal gain or preserved first-result quality; #6612 removes this option rather than accepting timing alone as success
Review-point wake crashesProduct (checkpoint selector, quota CLI)Root cause reproduced field for field; 7 new tests fail before / pass after; default path unchangedReadback in a real Docker trial; a stable per-trial transport
Ten hours of in-place tuningProduct (review rules, progress review, planning contract)Mechanism located: review may retain, progress is self-declared, assist fails silentlyAll repair directions unimplemented; even implemented, a different method is not guaranteed
Premature goal closureHarness calling the product acceptance contract (off by default)covshift 0.000 → 0.82 once; closure evidence now verifier-shaped; reconfirm counterexample closedGain after forced continuation; LoopX’s own closure judgement still fires at minute 38
Checkpoints force the envelope onProduct (heartbeat builder)Coupling located; both 24-hour runs are therefore not evidence of default behaviourDecoupling not yet proposed; envelope on/off effect never validated
Premature goal closureHarness calling the product acceptance contract (off by default)Separate covshift runs scored 0.000 and 0.82; branch tests check the acceptance interface and reconfirm counterexample, not a paired gainGain after forced continuation; LoopX’s own closure judgement still fires at minute 38
Checkpoints force the envelope onProduct (heartbeat builder)Coupling located; the interrupted original Borden / Grid runs used non-default configurationsDecoupling not yet proposed; envelope on/off effect never validated
-

What these repairs have in common: each is “the system is working, but the direction of the work was never checked”. The agent did not stop; nobody asked why it was still doing the same thing. The wake was not killed; a legitimate status word was not recognised. The goal was not forgotten; the evidence used to decide “done” had nothing to do with what the evaluator wanted. The value of a long-horizon control plane is not keeping an agent awake for more hours; it is leaving inspectable traces of these “is the direction right” judgements. This round repaired the parts that can be verified item by item; the parts that need the model to choose better are still design.

+

The engineering value is in retaining checkable failure chains, exit criteria and acceptance counterexamples. Corresponding entrypoint reproductions and regression checks can qualify local repairs; a versioned, configuration-explicit rerun retaining failures is still needed to assess long-horizon outcomes. These fragments establish neither that the main cause lies in the product rather than the model nor that LoopX is generally better or worse than native execution.

-

9. Next: repair the product first, then rerun

-

At the historical run cutoff, the remote runs were paused and their evidence retained. Since then #6584 and #6601 reached main, while #6612 withdrew feedback-first. The sequence below is the research proposal, not execution authority: new runs need their own authorization, and #6585 remains a branch experiment pending an accepted owner placement.

+

9. The author’s proposed follow-up validation

+

At the historical run cutoff, the remote runs were paused and their evidence retained. Since then #6584 and #6601 reached main, while #6612 withdrew feedback-first. The sequence below is the research proposal, not execution authority: new runs need their own authorization, and #6585 was closed without merging. Its retained branch evidence does not establish a supported mainline strategy.

- +
StepContentDecisive evidence
Product repairs reach main#6601 wake crashes; handoff/envelope decoupling; plateau signal and visible failure for progress review; planning contract rejecting open-ended TodosReal CLI and TypeScript owner tests; the default-off path byte-identical
Short pairs firstOne 3-hour pair each for Borden and Grid, fixed build vs native, checkpoints offNo crash at review points; review records show a pivot or an evidenced retain
Envelope validationSame task, one pair each with envelope on and off, checkpoints offUncached tokens, packet reads, CLI calls, time share, score
24-hour rerunsOne pair each for Borden and Grid, envelope state declared explicitlyCommon-window comparison with the curves above; failures and interruptions kept
Acceptance experiment retained#6585 branch evidence; mainline placement remains on holdAccepted owner placement and separately authorized execution before any new run
Acceptance experiment retainedHistorical #6585 branch evidence; PR closed without mergingA separately reviewed implementation and new execution authorization before any rerun
-

The previous article ended by saying progress had moved from “keep the agent running longer” to “make more of the runtime produce valid work”. This round takes that one step further: valid work also needs to be asked about its direction. Native Codex changed methods three times in the same window because it saw the score stall and changed; LoopX saw the same score, and every one of its rules allowed it to continue. Fixing that is the actual goal of this round.

+

This article leaves engineering leads from historical configurations, not formal LoopX capability conclusions. The author proposes checking local repairs and then task quality and efficiency under declared source, model, task, feedback, budget and resource conditions. Earlier feedback does not establish better delivery; a locally verified repair does not establish long-horizon gains. A withdrawn strategy is not current activation advice.

-

Scope: EdgeBench Borden Source Inversion, Grid Turing Robot, four 90-minute local tasks, and the LHTB four-task pilot. Numbers come from the frozen windows and wake receipts named in the text and are not interchangeable; interrupted runs are not terminal scores. Public implementation: LoopX; related proposals: #6584, #6585, #6601. Raw trajectories, hidden evaluation material and runtime credentials are not released with this article.

+

Status: the author’s exploratory historical engineering notes, not official or formal LoopX evaluation conclusions or current capability claims. Scope: EdgeBench Borden Source Inversion, Grid Turing Robot, four 90-minute local tasks, and the LHTB four-task pilot. Numbers come from the frozen windows and wake receipts named in the text and are not interchangeable; interrupted runs are not terminal scores. Public implementation: LoopX; related proposals: #6584, #6585, #6601. Raw trajectories, hidden evaluation material and runtime credentials are not released with this article.

diff --git a/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/fixed-borden-score-time-en.svg b/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/fixed-borden-score-time-en.svg index 067cdc469c..93ce628260 100644 --- a/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/fixed-borden-score-time-en.svg +++ b/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/fixed-borden-score-time-en.svg @@ -1,6 +1,6 @@ - -Second Borden pair: combined candidate and native officialThree submitted reports per arm. Best-so-far scores 68.108 and 54.705; last submissions 41.714 and 50.347. Interrupted, no native finals; checkpoint disabled and envelope explicit. - + +Second Borden pair: combined candidate and native officialHistorical exploratory runs, not official LoopX results or current capability. Three submitted reports per arm. Best-so-far scores 68.108 and 54.705; last submissions 41.714 and 50.347. Interrupted, no native finals; checkpoint disabled and envelope explicit. + Second Borden pair · higher is better 0 @@ -34,4 +34,6 @@ Native official 54.705 + +Historical, interrupted runs; not official LoopX evaluation results or current capability. diff --git a/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/fixed-borden-score-time.svg b/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/fixed-borden-score-time.svg index c167189505..7f13b99464 100644 --- a/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/fixed-borden-score-time.svg +++ b/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/fixed-borden-score-time.svg @@ -1,6 +1,6 @@ - -Borden第二对:组合候选与原生official每臂三次提交;历史最佳68.108与54.705,最后提交41.714与50.347。已中断,无正常终态;checkpoint关闭,envelope显式开启。 - + +Borden第二对:组合候选与原生official历史探索性运行,不代表 LoopX 官方评测或当前版本能力。每臂三次提交;历史最佳68.108与54.705,最后提交41.714与50.347。已中断,无正常终态;checkpoint关闭,envelope显式开启。 + Borden第二对 · 分数越高越好 0 @@ -26,7 +26,7 @@ -组合修复版 LoopX 68.108 +历史组合 LoopX 68.108 @@ -34,4 +34,6 @@ 原生 official 54.705 + +历史中断运行;不代表 LoopX 官方或正式评测结论及当前版本能力。 diff --git a/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/local-score-time-en.svg b/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/local-score-time-en.svg index e674966b0c..2abe73ab3c 100644 --- a/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/local-score-time-en.svg +++ b/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/local-score-time-en.svg @@ -1,6 +1,6 @@ - -Local 90-minute best-score trajectories71 scalar observations from 13 scored runs. Lines connect best-so-far scores at submission timestamps. Independent task scales; no fit or confidence bands. Two runs lack native final results. - + +Local 90-minute best-score trajectoriesHistorical exploratory runs, not official LoopX results or current capability. 71 scalar observations from 13 scored runs. Lines connect best-so-far scores at submission timestamps. Independent task scales; no fit or confidence bands. Two runs lack native final results. + 90-minute local budget · best score so far · higher is better (a) Borden source inversion @@ -213,4 +213,6 @@ ‡ 109 uses aggregate feedback inversion. Historical combined revisions only; not a test of the current repair head. + +Historical runs; not official LoopX results or current capability. feedback-first was withdrawn (#6612). diff --git a/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/local-score-time.svg b/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/local-score-time.svg index 2afcb7f9f3..d7a0d6b9d5 100644 --- a/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/local-score-time.svg +++ b/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/local-score-time.svg @@ -1,6 +1,6 @@ - -本地90分钟历史最佳分曲线13条有评分运行中的71次提交。点为提交时刻对应的历史最佳分,各题独立刻度;无拟合或置信带,两条运行缺正常终态。 - + +本地90分钟历史最佳分曲线历史探索性运行,不代表 LoopX 官方评测或当前版本能力。13条有评分运行中的71次提交。点为提交时刻对应的历史最佳分,各题独立刻度;无拟合或置信带,两条运行缺正常终态。 + 本地90分钟预算 · 截至该次提交的最佳分 · 越高越好 (a) Borden 源反演 @@ -28,7 +28,7 @@ -组合修复版 LoopX 109.000 ‡ +历史组合 LoopX 109.000 ‡ @@ -63,7 +63,7 @@ -组合修复版 LoopX 24.714 +历史组合 LoopX 24.714 @@ -104,7 +104,7 @@ -组合修复版 LoopX 26.506 +历史组合 LoopX 26.506 @@ -146,7 +146,7 @@ -组合修复版 LoopX 22.655 +历史组合 LoopX 22.655 @@ -191,7 +191,7 @@ -组合修复版 LoopX 7.743 +历史组合 LoopX 7.743 @@ -212,4 +212,6 @@ ‡ 109分包含聚合反馈反推。 使用早期组合版本; 不能作为当前修复头的实测。 + +历史探索性运行;不代表 LoopX 官方评测或当前能力。feedback-first 已撤回(#6612)。 diff --git a/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/score-time-en.svg b/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/score-time-en.svg index 32d0bd9a73..e733b7284f 100644 --- a/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/score-time-en.svg +++ b/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/score-time-en.svg @@ -1,6 +1,6 @@ - -Borden source inversion (higher is better) · Grid Turing robot (lower is better)Each point is one submission the evaluator accepted; aligned by submission time, missing points are not filled. - + +Borden source inversion (higher is better) · Grid Turing robot (lower is better)Historical exploratory runs, not official LoopX results or current capability. Each point is one submission the evaluator accepted; aligned by submission time, missing points are not filled. + Borden source inversion (higher is better) 0 @@ -90,4 +90,6 @@ LoopX heartbeat Native Codex -Each point is one submission the evaluator accepted; aligned by submission time, missing points are not filled. \ No newline at end of file +Each point is one submission the evaluator accepted; aligned by submission time, missing points are not filled. +Historical, interrupted runs; not official LoopX evaluation results or current capability. + \ No newline at end of file diff --git a/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/score-time.svg b/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/score-time.svg index 2c1843602d..edcefb8fc6 100644 --- a/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/score-time.svg +++ b/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/score-time.svg @@ -1,6 +1,6 @@ - -Borden 源反演(分数越高越好) · Grid 图灵机器人(分数越低越好)每个点是一次被评分器接受的提交;曲线按提交时刻对齐,不填补缺失点。 - + +Borden 源反演(分数越高越好) · Grid 图灵机器人(分数越低越好)历史探索性运行,不代表 LoopX 官方评测或当前版本能力。每个点是一次被评分器接受的提交;曲线按提交时刻对齐,不填补缺失点。 + Borden 源反演(分数越高越好) 0 @@ -90,4 +90,6 @@ LoopX heartbeat 原生 Codex -每个点是一次被评分器接受的提交;曲线按提交时刻对齐,不填补缺失点。 \ No newline at end of file +每个点是一次被评分器接受的提交;曲线按提交时刻对齐,不填补缺失点。 +历史中断运行;不代表 LoopX 官方或正式评测结论及当前版本能力。 + \ No newline at end of file diff --git a/apps/presentation/site/public/blog/index.html b/apps/presentation/site/public/blog/index.html index 89c9136441..9e414cb1c3 100644 --- a/apps/presentation/site/public/blog/index.html +++ b/apps/presentation/site/public/blog/index.html @@ -36,7 +36,7 @@

Read by question

Research notes · EdgeBench and LHTB

-

Why the agent stood still after 24 hours: one repair round for LoopX long runs

Real 24-hour traces from Borden, Grid and LHTB explain late feedback, review-point crashes, in-place tuning and premature closure—why each happened, whether it belongs to the product or the harness, and which repairs are verified versus still hypotheses.

Read the article
+

EdgeBench / LHTB: notes from historical runs

Exploratory notes by songoow on historical, partly interrupted EdgeBench/LHTB runs. The feedback-first option is withdrawn; these are not official LoopX results or current capability claims.

Read the article

Agentic Software · Development

diff --git a/apps/presentation/site/public/blog/zh/edgebench-long-horizon-repairs/index.html b/apps/presentation/site/public/blog/zh/edgebench-long-horizon-repairs/index.html index abc2c11594..e25180b119 100644 --- a/apps/presentation/site/public/blog/zh/edgebench-long-horizon-repairs/index.html +++ b/apps/presentation/site/public/blog/zh/edgebench-long-horizon-repairs/index.html @@ -3,15 +3,15 @@ -24 小时之后,Agent 为什么停在原地:LoopX 长程运行的一轮修复 · LoopX - +EdgeBench / LHTB:一轮历史试跑的工程复盘 · LoopX + - - + + @@ -19,39 +19,39 @@
-

songoow · 2026-10-16 · 阶段性研究稿 · 证据截点 03:10 UTC

-

24 小时之后,Agent 为什么停在原地

-

LoopX 长程运行的一轮修复:四类故障、它们的归属,以及尚未证明的部分

-

上一篇文章记录了 Portfolio 与 Lean 上的阶段性进展。这一轮我们把同一套系统放到更长的时间尺度上:与原生 Codex 成对运行 24 小时,并在 LHTB 的 90 分钟任务上检验目标是否会过早关闭。结果不好看,但很清楚:LoopX 的 Agent 一直在工作,分数却不动;原生对照在同一时间里换了三次方法。

-

本文解释这些曲线背后发生了什么。四类故障各自有可定位的原因:第一次外部反馈来得太晚;每到复盘点就崩溃一次;复盘允许“保持现状”,于是十个小时都在同一个解法上微调;以及在 LHTB 上,目标在隐藏评分远未达标时就宣布完成。我们把每项修复标注为产品改动还是实验脚本改动——这个区分决定了重跑的结果能说明什么。

-

我们的判断是:这轮暴露的主要是产品问题,不是模型问题。原生 Codex 用同一个模型拿到了更好的分数。修复有一部分已经完成并通过真实 CLI 验证,有一部分只是方向;两者在文中分开标注。

+

songoow · 2026-10-16 · 作者探索性工程记录 · 历史证据截点 03:10 UTC

+

EdgeBench / LHTB:一轮历史试跑的工程复盘

+

历史配置、提前中断、局部修复与待验证假设

+

本文是作者对历史实验版本的探索性工程记录,不代表 LoopX 官方或正式评测结论,也不能据此概括当前版本的能力、效率或与原生 Codex 的优劣。

+

开关已撤回:--feedback-first 及其规划环境开关已由 #6612 移除。本地分数来自包含该策略及其他改动的历史组合版本,不能当作当前版本或单项改动的效果验证。

+

本轮记录了 Borden、Grid 上计划预算为 24 小时、实际提前中断的运行,以及 LHTB 的 90 分钟试点。轨迹用于定位提交顺序、复盘交接、持续微调和闭合证据中的工程问题。文中区分可复现的局部缺陷、尚未隔离的解释和作者建议的后续验证,保留失败、中断与反例。

- +

1. 这一轮在回答什么问题

-

上一轮的结论是“系统整体比最初更有效,但贡献还没拆清”。这一轮我们换了两类任务来逼近一个更具体的问题:当任务有真实的外部评分器、而且时间足够长时,LoopX 的控制面是让 Agent 更会用这段时间,还是只是让它一直醒着?

- +

作者在这组特定任务与配置中想检查:提交顺序、复盘和闭合证据是否有助于持续产生有效工作。这个研究问题不能由少量历史轨迹直接回答;本文先保留可定位的问题与待检验的解释,不作 LoopX 通用长程能力的判断。

+
任务评分方向对照预算状态
- +
任务评分方向对照计划预算状态
EdgeBench Borden 源反演越高越好LoopX heartbeat(planned 入口)对原生 Codex24 小时,原生反馈,提交冷却 1 小时两对;第一对 12.4 小时中断,第二对 3 小时暂停
EdgeBench Grid 图灵机器人越低越好同上24 小时,同上11.7 小时暂停
EdgeBench Borden / codec / rust / jagua本组均越高越好LoopX 组合修复版、原生 official、native-goal90 分钟本地,冷却 15 分钟13 条有评分:11 条正常终态、2 条运行器失败;另有 2 次无评分启动失败
EdgeBench Borden / codec / rust / jagua本组均越高越好LoopX 历史组合版本、原生 official、native-goal90 分钟本地,冷却 15 分钟13 条有评分:11 条正常终态、2 条运行器失败;另有 2 次无评分启动失败
LHTB 四题(covshift 等)隐藏集 reward 0–1LoopX heartbeat 单臂,与历史五臂研究比较90 分钟四题试点完成,covshift 带验收门重跑完成
-

EdgeBench 使用 gpt-6.1-sol / xhigh,两臂同一模型、同一镜像、同一评分器;LHTB 使用 gpt-5.6-sol / max。“原生反馈”指 Agent 可以主动提交并拿到公开评分,冷却时间内不能再提交。原 Borden 与 Grid 第二轮的 LoopX 臂启用了检查点捕获;Borden 第二对和本地组合修复版关闭了检查点,但显式开启了 TurnEnvelope。这些处理不能混为一个默认配置,第 7 节会具体区分。

-

这些运行有不少没有跑完。原因有两类:我们自己的实验控制脚本出了故障(容器计数守卫被另一组的评分容器触发;控制进程在读取一个正在退出的容器时崩溃),以及本文写作时我们主动暂停了全部运行,先修复再重跑。中断的运行仍然是证据——曲线在中断前已经说明了问题——但不能当作终态成绩。

- +

EdgeBench 使用 gpt-6.1-sol / xhigh,两臂同一模型、同一镜像、同一评分器;LHTB 使用 gpt-5.6-sol / max。“原生反馈”指 Agent 可以主动提交并拿到公开评分,冷却时间内不能再提交。原 Borden 与 Grid 第二轮的 LoopX 臂启用了检查点捕获;Borden 第二对和本地历史组合版本关闭了检查点,但显式开启了 TurnEnvelope。这些处理不能混为一个默认配置,第 7 节会具体区分。

+

这些运行有不少没有跑完。实验控制脚本曾被另一组的评分容器触发计数守卫,也曾在读取退出中的容器时崩溃;部分运行则在写作时主动暂停。中断前的轨迹可以支持特定故障的定位,但缺少后续窗口和正常收尾,不能补成完整 24 小时结果。

+

2. 分数曲线说明了什么

-
两张分数–时间图。Borden:原生 Codex 第 13.6 分钟首次提交,第 194 分钟到 109;LoopX 第 48 分钟首次提交,12 次提交后在第 725 分钟到 85.6。Grid:LoopX 第 85 分钟到 2075 后 9.5 小时几乎不动,终点 2039;原生从 2260 一路降到 1791。
Borden 第一对(左)与 Grid 第二轮(右)。点表示各次提交的原生分数,不是历史最佳分。Borden 上 LoopX 首次提交更晚;Grid 上它约第 12 分钟提交占位解,早于原生的约第 21 分钟,但此后长期停留在同一路线。提交时刻不等于评分反馈返回时刻。
-

三个现象在两道题上都出现了,而且互相独立。

-

第一次外部反馈来得晚。Borden 上原生 Codex 在第 13.6 分钟拿到第一个分数,LoopX 在第 48.2 分钟;Grid 上是 21 分钟对 12 分钟,但 LoopX 的第一次提交是一个 3593 的占位解。在一个每小时只能提交一次的任务里,晚 35 分钟意味着整条曲线向右平移半个冷却周期。

+
所选历史运行:两张分数–时间图。Borden:原生 Codex 第 13.6 分钟首次提交,第 194 分钟到 109;LoopX 第 48 分钟首次提交,12 次提交后在第 725 分钟到 85.6。Grid:LoopX 第 85 分钟到 2075 后 9.5 小时几乎不动,终点 2039;原生从 2260 一路降到 1791。
历史配置观察,非当前版本的能力评测。Borden 第一对(左)与 Grid 第二轮(右)。点表示各次提交的原生分数,不是历史最佳分。Borden 上 LoopX 首次提交更晚;Grid 上它约第 12 分钟提交占位解,早于原生的约第 21 分钟,但此后长期停留在同一路线。提交时刻不等于评分反馈返回时刻。
+

下列现象来自所列历史运行,出现范围并不相同。它们可用于提出后续检查项,不能外推为所有 LoopX 运行的共同模式。

+

首次提交的时序与质量需要分开看。Borden 上原生 Codex 首次提交约在第 13.6 分钟,LoopX 约在第 48.2 分钟;Grid 上则是原生约第 21 分钟、LoopX 约第 12 分钟,后者为 3593 的占位解。提交时刻不等于反馈返回时刻,更早提交本身也不证明候选质量更好。

曲线在一个局部解上变平。Grid 上 LoopX 第 85 分钟就到了 2075——当时比原生的 2182 更好——此后 9.5 小时、9 次提交,分数从 2075 走到 2039,下降不足 2%。原生同期从 2182 到 1791,中间换了三次方法:嵌入 C++ 加速器、加入动态规划修补步骤、对代价参数做扫描。Borden 上 LoopX 从第 3 次提交起几乎只改一个振幅常数,每小时提高约 2 分。

提交有时倒退。Borden 第一对里 LoopX 11 次有效提交出现 3 次倒退;第二对里从 68.1 掉到 41.7,拆开评分器报告看,公开部分的误差在改善,隐藏井位的误差从 0.09 升到 0.74——它在拟合公开数据。原生也倒退过(54.7 到 50.3),所以这不是 LoopX 独有的问题,但每次倒退都浪费一个冷却周期。

-

原生在 Borden 上的 109 需要单独说明。评分器报告会返回隐藏集合的聚合指标,原生臂和本地短测里的修复版 LoopX 都通过拟合这些指标到达了 109。这是协议层面的泄漏,不是建模能力;我们把它记为任务问题,不计入任何一方的能力证据。

-

本地多题补充:更早提交,没有变成全面领先

+

原生在 Borden 上的 109 需要单独说明。评分器报告会返回隐藏集合的聚合指标,原生臂和本地短测里的历史组合版本 LoopX 都通过拟合这些指标到达了 109。这是协议层面的泄漏,不是建模能力;我们把它记为任务问题,不计入任何一方的能力证据。

+

本地历史补充:提交时序与分数未呈现一致优势

本地报告覆盖四个任务、13 条有评分运行和 71 次原生提交。它们共用一台四核、16 GiB 主机,资源上限不是独占预留。下图按每臂原生会话首记录归零,取 submitted_at 定位每次提交,再绘制截至该次提交的历史最佳分;线只连接观测点,止于末次提交,没有拟合函数、置信带或补造的零分。

-
本地五组历史最佳分曲线。组合 LoopX 在 Borden 达109,但包含聚合反馈反推;编解码24.714低于official的28.620;Rust三臂约26.5至26.6;Jagua两轮LoopX分别22.655和7.743,均低于official。native-goal的Rust和Jagua有评分但缺正常终态。
本地90分钟预算,分数越高越好,各题刻度独立。蓝色圆点为组合 LoopX,橙色方点为原生 official,灰色虚线三角为 native-goal;手机上可横向滚动或打开原图。星号表示运行器失败,不表示评分无效。
- +
所选历史运行:本地五组历史最佳分曲线。组合 LoopX 在 Borden 达109,但包含聚合反馈反推;编解码24.714低于official的28.620;Rust三臂约26.5至26.6;Jagua两轮LoopX分别22.655和7.743,均低于official。native-goal的Rust和Jagua有评分但缺正常终态。
历史配置观察,非当前版本的能力评测。本地90分钟预算,分数越高越好,各题刻度独立。蓝色圆点为历史组合 LoopX,橙色方点为原生 official,灰色虚线三角为 native-goal;手机上可横向滚动或打开原图。星号表示运行器失败,不表示评分无效。
+
任务 / 轮次组合 LoopX 最佳原生 official 最佳native-goal 最佳
@@ -62,21 +62,21 @@

本地多题补充:更早提交,没有变成全面领

以这里明确的原生首记录时钟计算,组合 LoopX 首次提交约1.7–3.0分钟,official约2.8–9.7分钟。更早提交并没有保证更高的最终最佳分:编解码和两轮Jagua均落后,Rust接近。组合版对official的非缓存输入token比值约为Borden 1.06、编解码1.31、Rust 1.01、Jagua 1.67 / 1.57;这些运行也没有显示出更少的非缓存输入,不能直接换算为总费用节省。

Borden第二对:保留早期领先,也保留中断

-
Borden第二对每臂三次提交,组合LoopX历史最佳68.108,official历史最佳54.705;第三次提交均回落,故历史最佳线保持不变。
候选 12bb5c931,checkpoint关闭、TurnEnvelope显式开启;横轴从本组控制器启动归零,与本地曲线时钟不同。每臂三次提交,最后一次分别为41.714和50.347;图中保留的是历史最佳68.108和54.705。
+
所选历史运行:Borden第二对每臂三次提交,组合LoopX历史最佳68.108,official历史最佳54.705;第三次提交均回落,故历史最佳线保持不变。
历史配置观察,非当前版本的能力评测。候选 12bb5c931,checkpoint关闭、TurnEnvelope显式开启;横轴从本组控制器启动归零,与本地曲线时钟不同。每臂三次提交,最后一次分别为41.714和50.347;图中保留的是历史最佳68.108和54.705。

这对运行的控制器在容器资源采样时崩溃,随后求解进程被停止,缺少正常终态结果。陈旧状态文件仍写着 running,不能据此视为持续执行;保留的最佳分也不能作为24小时完成成绩,或作为检查点恢复已经修好的证据。

相关公开报告与图表数据

反馈优先观察与运行器修复报告(冻结版本)提供本地成绩、失败分类、token口径和修复边界;其远端表保留更早窗口,不能覆盖本文后续的中断记录。covshift验收门重跑记录对应第6节的0.82结果,属于另一个基准。

下载本节曲线数据CSV:本地71条、远端Borden第二对6条标量观测,保留单次分、历史最佳、时钟原点与收尾分类。它是绘图数据,不包含任务材料、解答、完整轨迹或隐藏评测明细,不能据此独立复现完整实验。

-

3. 迟到的反馈:规划把提交排到了第三次唤醒

+

3. 历史规划:提交被排在局部准备之后

从会话轨迹和唤醒回执可以直接读出原因。planned 入口让 LoopX 先做一次规划,规划器的默认画像是面向开放式产品方向的:它把一个有明确评分器的有界任务拆成了三个顺序 Todo——P0 正向模型、P0 反演、P1“有了可运行的候选之后,再通过原生评测迭代”。每次执行唤醒恰好完成一个 Todo,然后花一到一分半钟做结算(完成 Todo、认领下一个、写回 vision、记录配额)。提交因此落在第三次唤醒。

-

这不是控制面开销的问题。规划本身约 1.3 分钟,结算合计几分钟;真正的 35 分钟差距来自 Todo 的顺序。把评测反馈排在“先把模型做好”之后,在一个评分器可以立即告诉你方向的任务里,是一个错误的先验。

+

这段轨迹中,规划约 1.3 分钟,结算合计几分钟;Todo 的顺序为本次首提交约 35 分钟的差距提供了可定位的解释。但首份候选质量、后续路径和完整成本没有被分别控制,不能据此认定“先取得反馈”一定更优,或把全部差距归因于规划顺序。

#6584曾实验性地要求先取得一次接受的评测,再扩展本地校准。这条约束已由合入主干的#6612撤回:当前运行器不再提供--feedback-first及其规划环境开关。下述首提交时间属于历史组合版本,不是当前启用建议,也不验证现行修复。本地四题的组合版本首提交约1.7–3.0分钟;同组official约2.8–9.7分钟,具体时钟见第2节。原Borden长测约48分钟的观察来自不同源码、冷却和运行条件,不能写成同条件的“48分钟降到2分钟”。

历史机制是实验运行器一侧的规划输入,不是产品能力的提升。它当时默认关闭,改变工作顺序,不改变预算、提交权或决策规则。轨迹定位到Todo顺序中的延迟;组合对照并不证明单因素收益。产品仍需回答共享规划怎样兼顾首次交付质量与有用反馈;第5节讨论的是路径停滞后仍持续原地工作的另一个问题。

维护者要求撤回,原因是feedback-first指引可能引导模型落入质量更低的初始点。更早取得反馈本身不证明首份交付更好,质量、延迟和完整成本需要分别比较。先交一个有竞争力的候选,和先交一个最小的候选,可能让后续工作走向不同;历史组合运行不能隔离这个效果。原版Grid的轨迹显示了围绕弱起点长期迭代的现象,但它没有启用新增的feedback-first,不能把该现象写成这个选项的已知副作用。这一点需要在同条件重跑中检验。

4. 复盘点崩溃:一个状态字没有被接受

-

Grid 的 4 个复盘点全部崩溃;Borden 第一对 87 次唤醒里 24 次失败,8 次是 EffectRuntimeInternalError,16 次是 ValueError。本地组合修复版未启用检查点交接,没有观察到这条复盘捕获故障链;这不抹去本地另有的两条native-goal运行器超时和两次启动失败。失败的直接代价只有二十几分钟的原生时间,但每次失败都打断结算,并把之后的唤醒推进“先恢复、再审查”的模式——复盘变成了恢复的副产品。

+

Grid 的 4 个复盘点全部崩溃;Borden 第一对 87 次唤醒里 24 次失败,8 次是 EffectRuntimeInternalError,16 次是 ValueError。本地历史组合版本未启用检查点交接,没有观察到这条复盘捕获故障链;这不抹去本地另有的两条native-goal运行器超时和两次启动失败。失败的直接代价只有二十几分钟的原生时间,但每次失败都打断结算,并把之后的唤醒推进“先恢复、再审查”的模式——复盘变成了恢复的副产品。

六步故障链:宿主捕获检查点;Agent 同轮选择 Todo 触发行内 guard 重读;回执状态为 upgraded;选择器只接受 committed 或 replayed 并抛出无类型错误;唤醒失败且 CLI 覆盖已保存决策;下一次唤醒沿用已结束的 socket。下方三个修复框对应第 3、5、6 步。
用真实 CLI 与 TypeScript owner 复现的故障链,与 Grid 的唤醒输出逐字段一致。

根因是一个没有被接受的状态字。宿主在复盘点捕获检查点之后,Agent 在同一轮选择 Todo;这次选择会在 CLI 内部重新读取一次 guard,回执的状态渲染为 upgraded——它是同一份持久回执的合法视图,表示选择已把绑定追加上去。检查点选择器只接受 committed 和 replayed,于是抛出一个没有类型的错误,宿主把它表面化为内部错误,整次唤醒结束。

CLI 一侧把损害放大了。被拒绝的交接落进了外层 guard 的兜底分支,被报告为 quota_unexpected_collection_error——“取数失败”——并覆盖了已经保存的决策文件。下一次唤醒恢复的原生会话还记得上一轮的交接 socket,而那个 socket 随上一次唤醒一起删除了,于是先是配额校验失败,再是捕获目录的 ValueError。两道题的失败唤醒都是这一条链。

@@ -90,16 +90,16 @@

Borden第二对:保留早期领先,也保留

一个笼统的 Todo 占了十个小时。规划产出的第三个 Todo 是“提交……并继续有用的本地改进”。它从未关闭,租约续了 12 次,没有新增任何 Todo。Todo 列表里没有策略:没有“假设族”,没有退出条件,没有“如果三次提交不改善就换方法”。

控制面开销约占四分之一。188 次 LoopX CLI 调用加上约 345 次读取 guard 包和决策文件,大约占 11.7 小时中的 2.8 小时;输入 token 2.07 亿对原生的 1.46 亿;上下文压缩 20 次对 7 次。原生几乎没有这类开销。

为什么不能简单加一条“分数停滞就强制换路”

-

这是最直接的修法,我们也最先想到它。但 LoopX 的核心今天没有任何数值的进展信号。它唯一知道的“进展”是 Agent 自己申报的分类——advanced、unchanged、blocked——Grid 的 Agent 每一轮都申报 advanced,而 2041、2040、2039 在它看来确实是进展。更重要的是,已接受的设计明确禁止通用核心从分数斜率或失败计数推导换路决定:一个指标意味着什么,由产生它的 provider 决定,不由控制面猜。这条规则有它的道理——Lean 上“删掉一个 sorry”和 Borden 上“分数涨 2 分”不是同一种进展——我们不打算为了一道题推翻它。

-

设计里已经为此留了位置:外部进展审查。一个独立的观察者在每次工作转换后写入类型化的“漂移”回执;在 assist 模式下,连续若干次漂移会升级为现有的重新规划义务,而回答这个义务时不能复述旧假设或只改名字——必须带新证据。它默认关闭,今天唯一的观察者判断的是代码变化,不是评分器分数。而且它有一个产品缺陷:当归属信息缺失(没有 agent-id,或窗口里没有类型化进展记录)时,assist 会静默地永远不触发,status 看起来却一切正常。

-

所以修复方向是三条产品改动,都还没有实现:让 provider 可以写入“指标停滞”这一类漂移信号,方向、阈值和是否算停滞由 provider 决定,核心只消费它并走现有的义务链;让 assist 无法触发的原因在 status 里可见;让规划契约拒绝“继续优化”这类没有退出条件的开放式 Todo,迭代工作必须带退出条件,下一轮通过重新规划进入。即使这些都做了,Agent 仍然可能用一个“新的”调参假设来回答义务——它能保证的是不能在无人察觉的情况下原地微调十个小时,不能保证它真的换到一个不同的方法。

+

本文核对的核心版本以 Agent 自报的 advanced、unchanged、blocked 分类记录进展;Grid 轨迹中每轮都申报 advanced。2041、2040、2039 的小幅改善不足以单独判断是否应换路。通用核心不应猜测 provider 指标的含义:Lean 中“少一个 sorry”和 Borden 中“多两分”没有共同的换路阈值。这说明需要明确指标解释与重规划的归属,不能据此断言模型只会微调或 LoopX 没有进展能力。

+

设计里已经为此留了位置:外部进展审查。一个独立的观察者在每次工作转换后写入类型化的“漂移”回执;在 assist 模式下,连续若干次漂移会升级为现有的重新规划义务,而回答这个义务时不能复述旧假设或只改名字——必须带新证据。在本文核对的版本中,它默认关闭,已有观察者判断的是代码变化,不是评分器分数。而且它有一个产品缺陷:当归属信息缺失(没有 agent-id,或窗口里没有类型化进展记录)时,assist 会静默地永远不触发,status 看起来却一切正常。

+

作者据此提出三项尚未实现、也未验证收益的方向:由 provider 定义指标方向、阈值与停滞判断,并通过既有义务链提供漂移信号;显式显示 assist 无法触发的原因;让迭代 Todo 带可检查的退出条件。这些是待评审的设计假设,不是 LoopX 已承诺的机制或正式路线图。即使实现,也须再检验能否改善决策与结果,不能保证 Agent 会选择更好的方法。

6. 过早关闭:验收门改变了“什么算做完”

LHTB 的四道试点任务给出了同一个模式。四次运行里,LoopX 的调度器都在 90 分钟预算的第 43–60 分钟发出 stop_until_explicit_resume,理由一字不差:“已验证的闭合证据推导出无后续,并确认没有剩余前沿”。此时隐藏集 reward 分别是 0.000、0.028、0.086 和 0.093。只有外层“继续直到超时”的机制把 Agent 叫了回来,第二阶段没有再自行停止。

-

这和上一篇文章里 Portfolio 的 no_followup 故障同源:所有 Todo 都完成了,不等于原目标已经满足。区别在于这次有一个隐藏评分器清楚地告诉我们,Agent 用来判断“做完了”的证据是什么都不是。两道题的 Agent 在隐藏包装清单上直接退出非零,一道题通过了隐藏的格式检查却在权重 0.89 的端到端压力测试上得零——它从未针对任务说明里写明的验证接口检查过自己的交付物。

-

我们没有改调度规则,而是改了闭合证据的来源。#6585 增加显式开启的 LOOPX_ACCEPTANCE_CONTRACT=planned:规划阶段让模型同时写一份目标验收文档——哪些 Todo 交付结果、每个 Todo 绑定哪些可执行的验收条件、条件必须通过任务说明的验证接口来检验交付物;实验宿主以受信任的本机 owner 身份,通过现有的 goal-acceptance 契约配置它。之后被选中的 Todo 在条件通过之前不能完成,目标也不能在它仍然开着时关闭。

-
任务 / 轮次历史组合 LoopX 最佳原生 official 最佳native-goal 最佳
Borden109.000‡69.579未运行
整数压缩编解码24.71428.62012.836
Rust 多 crate 重建26.50626.59726.597*
+

这些试点与此前 Portfolio 的 no_followup 案例都提示一个验收缺口:Todo 完成不等于原目标已满足。在本组运行中,闭合证据未覆盖隐藏评估所要求的完整行为。两题的交付物在隐藏包装清单上退出非零,另一题虽通过格式检查,却在权重 0.89 的端到端压力测试上得零。它们支持检查验收接口覆盖,不足以概括 LoopX 的一般闭合能力。

+

我们没有改调度规则,而是改了闭合证据的来源。#6585(现已关闭、未合并)的历史分支试验引入显式开启的 LOOPX_ACCEPTANCE_CONTRACT=planned:规划阶段让模型同时写一份目标验收文档——哪些 Todo 交付结果、每个 Todo 绑定哪些可执行的验收条件、条件必须通过任务说明的验证接口来检验交付物;实验宿主以受信任的本机 owner 身份,通过现有的 goal-acceptance 契约配置它。之后被选中的 Todo 在条件通过之前不能完成,目标也不能在它仍然开着时关闭。

+
covshift试点(默认)带验收门(单次)五臂研究 heartbeat
@@ -110,36 +110,36 @@

为什么不能简单加一条“分数停滞就强制换路”

7. 哪些数字不能用

写到这里,有一个发现迫使我们重新给前面的证据定性。

-

LoopX 有一个默认关闭的 TurnEnvelope:把几十 KB 的配额决策压缩成约 8 KB 的行内视图,其余内容写到文件按引用读取。检查点交接的实现会在传了捕获目录时自动给 guard 命令加上 --turn-envelope。原Borden与Grid第二轮因此实际启用了envelope;本地组合修复版和远端Borden第二对虽然关闭checkpoint,却显式开启了envelope。本地回执明确为 turn_envelope=true、turn_envelope_source=explicit。它们都不是干净的envelope-off对照;没有观察到捕获故障链不能证明关闭envelope改善了稳定性。

-

这反过来让 Grid 成了 envelope 的第一份真实长程测量,结论不乐观:Agent 读了约 345 次完整的捕获文件,每个 37–57 KB——行内变短了,字节只是换了地方,还多了一次文件读取和一个每次唤醒新建的 socket,后者正是第 4 节崩溃的来源。那约四分之一的控制面开销是 envelope 打开时测出来的。另一方面,一个未合入的实验版本放宽了 envelope 的“每次改动工作区就重新进 guard”规则,CLI 调用从 65 降到 25、配额检查从 40 降到 8——说明重入节奏才是开销的大头,不是包的大小。

-

由此引出两条结论。第一,交接和 envelope 应当解开:配额 CLI 本来就是两个独立开关,只有 heartbeat 构建器把它们绑在一起,这是一个有边界的产品改动。第二,在把配额包和 envelope 融合之前,先做那个一直没做的验证——不开检查点、同一题 envelope 开/关各一对,测未缓存 token、包读取次数、CLI 调用数、时间占比与分数。融合的方向可以从这些证据里直接读出来:Agent 必须据以行动的决策文本留在行内,完整细节通过稳定的 CLI 读回按需获取,重入节奏写成显式规则。这是设计层面的工作,不在这一轮的代码里。

+

LoopX 有一个默认关闭的 TurnEnvelope:把几十 KB 的配额决策压缩成约 8 KB 的行内视图,其余内容写到文件按引用读取。检查点交接的实现会在传了捕获目录时自动给 guard 命令加上 --turn-envelope。原Borden与Grid第二轮因此实际启用了envelope;本地历史组合版本和远端Borden第二对虽然关闭checkpoint,却显式开启了envelope。本地回执明确为 turn_envelope=true、turn_envelope_source=explicit。它们都不是干净的envelope-off对照;没有观察到捕获故障链不能证明关闭envelope改善了稳定性。

+

Grid 提供了一份开启 envelope 的历史运行观察:Agent 约读取 345 次完整捕获文件,每个 37–57 KB;约四分之一的控制面开销是在此配置下记录的。但没有同条件 envelope-off 对照,不能据此把开销或分数停滞归因于 envelope。另一个未合入组合版本放宽重入规则后记录到 CLI 调用 65 与 25、配额检查 40 与 8 的差别;这提示应单独检验重入节奏,不证明它是唯一或主要原因。

+

由此形成两个待验证的设计问题:交接与 envelope 是否应解耦,以及在不开检查点、同题同条件下,envelope 开/关怎样影响未缓存 token、包读取次数、CLI 调用、时间占比和分数。保留行内决策文本、按需读回细节并明确重入节奏,是作者提出的候选方向;这些观察没有证明其最优性,也不构成已经验证的产品结论。

还有三类数字要单列。实验控制脚本的事故——容器计数守卫被评分容器触发、控制进程读取退出中的容器时崩溃——缩短了运行,但不是 LoopX 的故障。Borden 的 109 来自评分协议泄漏,第 2 节已经说明。所有“修复后”的本地数字都带着多项变化同时发生:feedback-first、放宽的重入规则、显式 envelope;没有一个可以单独归因。

8. 怎样评价这批修复

-

和上一篇一样,我们按解决的缺口与证据评价,不按 PR 数量。这次多了一列:改动落在产品还是实验脚本。这一列决定了重跑的分数能说明什么——一个运行器侧的修复让曲线变好,证明的是“运行器的输入改变了结果”,不是 LoopX 的能力。

-
covshift(历史单次运行,非配对效果估计)试点(默认)带验收门(单次)五臂研究 heartbeat
隐藏集 reward0.0000.820.743
自行停止第 55 分钟第 38 分钟,但在三条条件全部通过之后—
费用$15.8$15.3—
- +

下表区分历史运行观察、局部契约验证与尚待验证的假设。产品代码、实验运行器输入及配置同时变化时,分数差异不能单独归因;补丁合入、局部测试通过或运行器曲线变化,都不等于当前 LoopX 的通用能力或效率已经得到验证。

+
缺口归属已证明尚未证明
首次反馈太晚实验脚本(实验性规划约束,现已撤回)轨迹显示Todo顺序延后提交;本地组合版首提交约1.7–3.0分钟,official约2.8–9.7分钟单因素收益或首次交付质量保持;#6612移除此选项,没有把时序更早当成验收成功
+ - - + +
缺口归属已记录或局部验证尚未验证
Borden 首提交较晚实验脚本(实验性规划约束,现已撤回)轨迹显示Todo顺序延后提交;本地组合版首提交约1.7–3.0分钟,official约2.8–9.7分钟单因素收益或首次交付质量保持;#6612移除此选项,没有把时序更早当成验收成功
复盘点唤醒崩溃产品(检查点选择器、配额 CLI)根因逐字段复现;7 个新测试修复前失败、修复后通过;默认路径不变真实 Docker 试验中的读回;稳定的逐试验传输
原地微调十小时产品(复盘规则、进展审查、规划契约)机制定位:复盘允许保持、进展信号是自报分类、assist 静默失效全部修复方向尚未实现;即使实现也不保证换到不同方法
目标过早关闭实验脚本调用产品的验收契约(默认关闭)covshift 0.000→0.82 单次;闭合证据改为验证器形状;重确认反例已堵强制继续之后的增益;LoopX 自身的闭合判断仍在 38 分钟触发
检查点强制打开 envelope产品(heartbeat 构建器)耦合点已定位;两次 24 小时运行因此不是默认行为的证据解耦改动尚未提交;envelope 开/关的效果从未被验证
目标过早关闭实验脚本调用产品的验收契约(默认关闭)covshift 两次单独运行分别为 0.000、0.82;分支实验验证验收接口与重确认反例,不是配对收益估计强制继续之后的增益;LoopX 自身的闭合判断仍在 38 分钟触发
检查点强制打开 envelope产品(heartbeat 构建器)耦合点已定位;原 Borden / Grid 的中断运行采用了非默认配置解耦改动尚未提交;envelope 开/关的效果从未被验证
-

这批修复的共同点是:每一个都是“系统在工作,但工作的方向没有被检查”。Agent 没有停,只是没有人问它为什么还在做同一件事;唤醒没有被杀死,只是一个合法的状态字没有被认出;目标没有被遗忘,只是用来判断“做完了”的证据和评分器要的东西无关。长程控制面的价值不在于让 Agent 多醒几个小时,而在于让这些“方向是否正确”的判断留下可以检查的痕迹。这一轮我们修好了其中可以逐项验证的部分;需要模型做出更好选择的部分,还只是设计。

+

这些记录的工程价值是保留可核对的故障链、退出条件与验收反例。局部修复可以通过对应入口复现和回归测试核验;是否改善长程任务表现,还需要声明版本与配置、保留失败的对照重跑。本文不能从这些片段推出“问题主要在产品而不在模型”,也不能据此评价 LoopX 整体优于或弱于原生执行器。

-

9. 下一步:先修产品,再重跑

-

历史运行截点时,远端运行已暂停,证据保留。此后#6584与#6601已进入主干,#6612撤回feedback-first。下列顺序是研究提案,不授予执行权限:新运行须另有授权,#6585仍保留为分支实验,主干归属等待owner接受。

+

9. 作者建议的后续验证

+

历史运行截点时,远端运行已暂停,证据保留。此后#6584与#6601已进入主干,#6612撤回feedback-first。下列顺序是研究提案,不授予执行权限:新运行须另有授权,#6585现已关闭且未合并;保留的分支证据不表示主干支持这项策略。

- +
步骤内容决定性证据
产品修复进入主干#6601 唤醒崩溃;交接与 envelope 解耦;进展审查的停滞信号与可见失效;规划契约拒绝开放式 Todo真实 CLI 与 TypeScript owner 测试;默认关闭路径逐字节一致
短对照先行Borden 与 Grid 各一对 3 小时,修复版对原生,不开检查点复盘点不再崩溃;复盘记录里出现换路决定或带证据的保持
envelope 效果验证同一题 envelope 开/关各一对,不开检查点未缓存 token、包读取次数、CLI 调用、时间占比、分数
24 小时重跑Borden、Grid 各一对,明确声明 envelope 状态与本文曲线在共同窗口比较;保留失败与中断
保留验收实验#6585分支证据;主干归属仍暂停先接受owner归属,并取得另行执行授权,才可开始新运行
保留验收实验#6585历史分支证据;PR已关闭、未合并另行评审实现并取得新执行授权后,才可重跑
-

上一篇文章结尾说,进展已从“让 Agent 多跑一会儿”走向“让更多运行时间产生有效工作”。这一轮把那句话推进了一步:有效工作还需要被问方向。原生 Codex 在同一时间里换了三次方法,因为它看到分数不动就换了;LoopX 看到了同样的分数,而它的每一条规则都允许它继续。修好这一点,才是这一轮真正的目标。

+

本文留下的是历史配置下的工程排查线索,而不是 LoopX 的正式能力结论。作者希望后续在明确的源码、模型、任务、反馈、预算与资源条件下,分别检查局部修复是否生效,以及任务质量和效率是否受益。更早反馈不等于更好交付,局部修复通过不等于长程收益成立;已撤回的策略不能作为当前启用建议。

-

研究范围:EdgeBench Borden Source Inversion、Grid Turing Robot、四道90分钟本地任务,以及 LHTB 四题试点。数字来自文中注明的冻结窗口与唤醒回执,口径互不替代;中断运行不构成终态成绩。公开实现入口:LoopX;相关提案:#6584、#6585、#6601。原始轨迹、隐藏评测材料与运行环境凭证不随本文发布。

+

定位:作者的探索性历史工程记录,不代表 LoopX 官方或正式评测结论及当前版本能力。研究范围:EdgeBench Borden Source Inversion、Grid Turing Robot、四道90分钟本地任务,以及 LHTB 四题试点。数字来自文中注明的冻结窗口与唤醒回执,口径互不替代;中断运行不构成终态成绩。公开实现入口:LoopX;相关提案:#6584、#6585、#6601。原始轨迹、隐藏评测材料与运行环境凭证不随本文发布。

diff --git a/apps/presentation/site/public/blog/zh/index.html b/apps/presentation/site/public/blog/zh/index.html index 4a13c487d7..6d3acaae1f 100644 --- a/apps/presentation/site/public/blog/zh/index.html +++ b/apps/presentation/site/public/blog/zh/index.html @@ -36,7 +36,7 @@

研究札记 · EdgeBench 与 LHTB

-

24 小时之后,Agent 为什么停在原地:LoopX 长程运行的一轮修复

从 Borden、Grid 与 LHTB 的 24 小时真实轨迹,解释迟到的反馈、复盘点崩溃、原地微调与过早关闭为什么发生、各自归属于产品还是实验脚本,以及哪些修复已验证、哪些仍是假设。

阅读全文
+

EdgeBench / LHTB:一轮历史试跑的工程复盘

songoow 对历史 EdgeBench/LHTB 实验配置的探索性工程记录,包含提前中断、局部修复与待验证假设。feedback-first 开关已撤回;不代表 LoopX 官方或正式评测结论及当前版本能力。

阅读全文

Agentic Software · 开发范式

From 97c8371f308e03c48e344a6fb08fd4ac4e46b0a4 Mon Sep 17 00:00:00 2001 From: huangruiteng Date: Sat, 17 Oct 2026 01:41:53 +0800 Subject: [PATCH 2/2] fix(blog): align primary score charts with the submission clock MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The article now states that 13.6 and 48.2 minutes are first-submission times and that a submission timestamp is not the feedback-return time, but both primary score charts still labelled that annotation "First feedback" and "首次反馈", so a shared or standalone figure asserted a feedback latency the prose does not claim. Change only the two annotation strings; every coordinate, plotted value and score stays as it was. Add paired English/Chinese label assertions to the bilingual blog smoke so the figure and the article must name the same event clock and keep the same measured numbers, with regression mutations proving the check fails when either figure returns to the feedback clock. Signed-off-by: LoopX Agent Signed-off-by: huangruiteng --- .../score-time-en.svg | 4 +- .../score-time.svg | 4 +- examples/blog-bilingual-index-smoke.mjs | 95 +++++++++++++++++++ 3 files changed, 99 insertions(+), 4 deletions(-) diff --git a/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/score-time-en.svg b/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/score-time-en.svg index e733b7284f..83e81975df 100644 --- a/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/score-time-en.svg +++ b/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/score-time-en.svg @@ -41,7 +41,7 @@ 85.6 Minutes since trial start -First feedback: native 13.6 min, LoopX 48.2 min +First submission: native 13.6 min, LoopX 48.2 min Grid Turing robot (lower is better) 1.8K @@ -92,4 +92,4 @@ Native Codex Each point is one submission the evaluator accepted; aligned by submission time, missing points are not filled. Historical, interrupted runs; not official LoopX evaluation results or current capability. - \ No newline at end of file + diff --git a/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/score-time.svg b/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/score-time.svg index edcefb8fc6..eeeb28e570 100644 --- a/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/score-time.svg +++ b/apps/presentation/site/public/blog/images/edgebench-long-horizon-repairs/score-time.svg @@ -41,7 +41,7 @@ 85.6 自试验开始的分钟数 -首次反馈:原生 13.6 分钟,LoopX 48.2 分钟 +首次提交:原生 13.6 分钟,LoopX 48.2 分钟 Grid 图灵机器人(分数越低越好) 1.8K @@ -92,4 +92,4 @@ 原生 Codex 每个点是一次被评分器接受的提交;曲线按提交时刻对齐,不填补缺失点。 历史中断运行;不代表 LoopX 官方或正式评测结论及当前版本能力。 - \ No newline at end of file + diff --git a/examples/blog-bilingual-index-smoke.mjs b/examples/blog-bilingual-index-smoke.mjs index f1e4b64c0c..cf27f6d612 100644 --- a/examples/blog-bilingual-index-smoke.mjs +++ b/examples/blog-bilingual-index-smoke.mjs @@ -145,9 +145,65 @@ export async function validateBilingualBlog(blogDir) { } } + await validateEventClockLabels(blogDir); return { articleSlugs: englishSlugs }; } +// A primary chart annotation must name the same event clock the article +// declares. These long-horizon scores are aligned to each submission, so a +// figure must not assert a feedback-return latency the prose never claims, and +// the measured numbers stay in both the chart and the article so a label edit +// cannot silently drop the measurement. +const EVENT_CLOCK_LABELS = [ + { + slug: "edgebench-long-horizon-repairs", + directory: "", + figure: "images/edgebench-long-horizon-repairs/score-time-en.svg", + annotation: "First submission: native 13.6 min, LoopX 48.2 min", + rejected: "First feedback", + }, + { + slug: "edgebench-long-horizon-repairs", + directory: "zh", + figure: "images/edgebench-long-horizon-repairs/score-time.svg", + annotation: "首次提交:原生 13.6 分钟,LoopX 48.2 分钟", + rejected: "首次反馈", + }, +]; +const EVENT_CLOCK_VALUES = ["13.6", "48.2"]; + +async function validateEventClockLabels(blogDir) { + for (const contract of EVENT_CLOCK_LABELS) { + const figure = await readFile(resolve(blogDir, contract.figure), "utf8"); + assertIncludes( + figure, + contract.annotation, + `Primary chart must name the declared event clock: ${contract.figure}`, + ); + if (figure.includes(contract.rejected)) { + throw new Error( + `Primary chart must not assert a feedback clock: ${contract.figure}`, + ); + } + const article = await readFile( + resolve(blogDir, contract.directory, contract.slug, "index.html"), + "utf8", + ); + for (const value of EVENT_CLOCK_VALUES) { + assertIncludes( + figure, + value, + `Primary chart must keep its measured value: ${contract.figure} ${value}`, + ); + assertIncludes( + article, + value, + `Article must state the same measured value as its chart: ${contract.slug} ${value}`, + ); + } + } +} + // Minimal element model for the sorting module. It keeps only the two browser // facts that module depends on: children are read in live order, and detaching a // card blurs whatever was focused inside it. The packaged page is checked in a @@ -220,6 +276,27 @@ async function assertPairedLinkRejected(blogDir, slug, anchor, message) { } } +async function assertClockLabelRejected(blogDir, { figure, declared, regressed }, message) { + const temporaryRoot = await mkdtemp(join(tmpdir(), "loopx-blog-event-clock-")); + const fixtureBlog = join(temporaryRoot, "blog"); + try { + await cp(blogDir, fixtureBlog, { recursive: true }); + const figurePath = resolve(fixtureBlog, figure); + const source = await readFile(figurePath, "utf8"); + if (!source.includes(declared)) { + throw new Error(`Could not locate the declared event clock in ${figure}`); + } + await writeFile(figurePath, source.replace(declared, regressed)); + await rejects( + () => validateBilingualBlog(fixtureBlog), + /Primary chart (must name the declared event clock|must not assert a feedback clock)/, + message, + ); + } finally { + await rm(temporaryRoot, { recursive: true, force: true }); + } +} + const modulePath = fileURLToPath(import.meta.url); if (process.argv[1] && resolve(process.argv[1]) === modulePath) { const articleUrl = "https://loopx-project.github.io/loopx/blog/example/"; @@ -288,5 +365,23 @@ if (process.argv[1] && resolve(process.argv[1]) === modulePath) { `中文`, "A correct data-href must not hide an incorrect navigable href", ); + await assertClockLabelRejected( + blogDir, + { + figure: "images/edgebench-long-horizon-repairs/score-time-en.svg", + declared: "First submission: native 13.6 min, LoopX 48.2 min", + regressed: "First feedback: native 13.6 min, LoopX 48.2 min", + }, + "An English chart that restores the feedback clock must fail the paired label check", + ); + await assertClockLabelRejected( + blogDir, + { + figure: "images/edgebench-long-horizon-repairs/score-time.svg", + declared: "首次提交:原生 13.6 分钟,LoopX 48.2 分钟", + regressed: "首次反馈:原生 13.6 分钟,LoopX 48.2 分钟", + }, + "中文主图恢复反馈口径也必须被配对标签检查拦下", + ); console.log(`blog-bilingual-index-smoke: ok (${articleSlugs.length} paired articles)`); }