diff --git a/apps/presentation/site/public/blog/edgebench-feedback-and-memory/index.html b/apps/presentation/site/public/blog/edgebench-feedback-and-memory/index.html index 756d10b7ed..779c14e98e 100644 --- a/apps/presentation/site/public/blog/edgebench-feedback-and-memory/index.html +++ b/apps/presentation/site/public/blog/edgebench-feedback-and-memory/index.html @@ -3,41 +3,58 @@ -Inside the LoopX control-plane kernel · LoopX - +What does an agent achieve with ten more hours? · LoopX + - - + +
← LoopX Blog中文
-
-

Ruiteng Huang · Updated October 28, 2026 · Kernel engineering and research

-

Inside the LoopX control-plane kernel

-

Useful continuation, faithful recovery, and complete cost

-

Running longer should produce useful later work and retain its results. The control plane’s own cost has to earn its place.

-

Long EdgeBench traces exposed control-plane problems: work changed direction before its original Turn closed; a smaller context entry increased full recovery delivery; one read repeatedly checked the same runtime. This article follows three repairs through their shared semantic owners, what they resolve, and what remains unproven.

-
- -

1. What should the kernel improve?

+

Ruiteng Huang · October 29, 2026

What does an agent achieve with ten more hours?

How EdgeBench reshaped the LoopX control plane

A research run can start ahead, then barely improve for ten hours. It can keep changing code and lose its best result. These failures made us revisit goals, feedback, experiment size and recovery.

The work began with trace diagnosis in early October: repair evaluation and continuation, follow evidence into the next experiment, then charge the control plane for its own cost. This account follows that progression, including results that challenged the approach.

Here, kernel means LoopX’s shared goal, admission, transaction and recovery rules. LoopX keeps the original goal, acceptance conditions, work ownership and evidence durable across sessions and hosts. Its control plane constrains state transitions and supplies feedback for the model’s next choice. It does not certify that the choice is insightful. A recorded finding, a read receipt and a replan entry are intermediate evidence; the relevant chain ends in actual work and a validated outcome.

-

The TypeScript refactor article explains ownership and model-assisted semantic repair. Below, we examine continuation correctness, complete delivery cost and host read cost separately.

+

The TypeScript refactor article explains ownership and model-assisted semantic repair. Below, we follow how these rules affect actual research work.

  1. GoalAcceptance and scope
  2. EvidenceResults and limitations
  3. DecisionContinue or change course
  4. WorkExecute and validate
  5. RetentionKeep the best valid result

We separate three observations: an initial advantage, an improvement obtained later, and retention of the best validated artifact. A higher final score can come almost entirely from a stronger starting point. A better intermediate candidate can disappear from the terminal workspace. More runtime, Todos or graph nodes establish none of these outcomes.

-
-

2. A new route exists. What closes the original work?

-

A review can conclude that a route lacks evidence and create a successor validation task. That task now exists, but the review itself still needs writeback and settlement. If another admission read immediately selects the successor, the model receives conflicting identities: the completed review belongs to the old Turn, while the new task appears to own the current work. Another model wake does not resolve that conflict.

-

#7269 converges the control plane’s continuation semantics. Creating a successor proves a route was recorded; it neither settles the original Turn nor authorizes the successor’s execution. The existing TypeScript replan-transition and quota-settlement owners retain the creation receipt, original obligation and Turn binding. A same-Turn reread returns the original settlement steps. After writeback, only settlement remains; after settlement, this Turn stops. The successor stays open for fresh admission.

-

This also requires separating must_attempt from delivery_allowed. The former requires addressing this Turn’s work obligation; the latter describes permission for ordinary delivery. A required replan can have legitimate planning work while ordinary delivery remains closed. Opening ordinary execution merely to make the agent act would be an authority bug. Leases, budgets, stops and admission for the successor retain their existing owners.

-

Real File / SQLite CLI regressions create a successor and execute the returned writeback and settlement commands unchanged. Premature spending is rejected, repeated settlement produces one debit, and the successor does not replace the original Turn. A later Turn selects the new task. Negative cases change ownership, defer the task or remove its claim; an invalidated creation receipt cannot settle the original result. These checks exercise the state transition and real entrypoint, beyond one field or ACK.

-

The repair keeps model attention on the next useful test and removes opportunities for repeated identity negotiation and admission. It does not guarantee insightful subsequent research. We still follow evidence through a decision, actual work and native outcomes. The same-checkpoint observations provide limited positive evidence and contrary results.

-
-

3. Does a smaller context cost less to deliver completely?

+

1. The research progression

PeriodFocusChangeImplementation
Early OctoberFeedback and starting conditionsRepair blind-run prompts, ledger and recovery defects; establish original-task, scoring and continuation boundaries.#5586, #5844, #5879
October 9–11Original goals and useful feedbackPreserve full evaluation responses, candidate identity and original requirements; implementation or submission is not Goal acceptance.#6031, #6039, #6133, #6199
October 12–16Experiment size and recovery pointsReplace mechanical shrinking with grow / switch / verify; jointly preserve conversation, candidates, evaluation opportunities and budget; switch context before replanning.#6298, #6321, #6305, #6622, #6649
Mid-to-late OctoberLater progress and best retentionSeparate starting advantage, subsequent gain and retained best in common windows; Schema exposes high cost and stalled progress.#6440, #6532, #6671
October 22–28Complete control-plane costReduce passive polling and repeated reads; inspect original-Turn closeout, full context, invalid-baseline fallback and recovery cost.#6983, #7013, #7036, #7197, #7269

Cases are selected for mechanism changes and intelligible failures. PRs anchor phases rather than form an exhaustive daily release log. Dates describe research phases; linked records retain creation, merge and historical qualification details.

2. First make the feedback trustworthy

+

The first Portfolio experiments exposed measurement and execution defects before they could tell us much about strategy. A blind wrapper had removed iterative optimization guidance along with the judge entrypoint. A ledger check attributed earlier market returns to holdings bought only at the closing price. Both confounded the intended comparison; repairing them required new attempts while preserving the old results.

+

One small oracle made the accounting error clear. Start with 100,000 cash, buy 100 units at a closing price of 200, and pay 10 commission. Immediate equity is 99,990 and NAV is 0.9999; the new holding did not earn the preceding rise from 100. Independent reconciliation then matched all 243 days in each of two frozen samples, with equity residual below 4×10⁻⁹ and no share-count difference. This established ledger consistency, not investment skill. The versioned repair is documented in EdgeBench #14.

+

Continuation had a related failure: an outer process could wake repeatedly after a work item ended without recovering a useful next action. The governing question must return to the original goal. Completing a Todo can justify another experiment, waiting, or completion; it cannot by itself settle goal acceptance. Correct recovery and feedback make subsequent research interpretable.

+

When should a long, unfinished task review its direction?

+

A proof task can run for hours while its Todo remains open. If review waits for several completed Todos, the long task that most needs a checkpoint may never reach one. Artificially splitting the task to raise the count does not improve the research.

+

On October 7, #5879 changed the counting basis to settled effective work Turns, allowing review while the same Todo is still open. A tool call is not such a Turn. Progress written without completed settlement does not advance the counter, and repeated history cannot count twice. Explicit settings in the old completed-Todo unit remain intact; each experiment retains its frozen configuration.

+

The other half is what happens after review. Evidence can support continuing the same method; a review need not invent a new route. The merged revision’s real-CLI regression covers counting settled work on one open Todo, excluding a missing settlement receipt, rejecting a review without evidence references, and admitting further work after an evidence-linked continuation. This verifies when review is required and how work can resume. Whether the model chooses better experiments remains an empirical question.

+

Early system progress was measurable

+
Blind Lean raw scoreEarly Resume v14Later Resume (#5844)Early Explore v14Later Explore (#5844)
180 minutes0.11030.34780.11340.4019
450 minutes0.18820.52430.19960.5605
+

These single-run common windows show roughly 2.8–3.5 times the earlier raw scores. Prompts, task entry, runner reliability and LoopX mechanisms changed together. The observation supports progress in the overall system; it does not identify one mechanism’s causal effect or guarantee terminal performance elsewhere.

+
Comparison boundaries

Historical studies include Official, single-call, native Goal, LoopX Resume and LoopX Explore. Explore adds optional evidence capture and planning to continued work. Blind runs retain public tasks, training data and local validators but receive no hidden judge scores or diagnostics; background operator evaluation is not solver feedback. Later native-feedback studies use agent-requested evaluation, a one-hour accepted-submission cooldown and no periodic grading. These are different studies, not one pooled treatment.

Models, effort, prompts, runners and budgets co-evolved. Early studies primarily used Sol/xhigh; later Sol/max and Astra/xhigh cohorts retain their own conditions. One run per arm is descriptive evidence. Missing, stopped, invalid and valid-zero results stay distinct. Source time, evaluation opportunities and cooldown survive checkpoint continuation; donor history is not a new independent repetition.

3. Finishing its own checklist without finishing your goal

+

A research goal asks for a better algorithm. The agent decomposes it into implementation, testing and submission. All three Todos finish and the outer loop stops, although the improvement question remains unanswered. Another form of drift promotes an agent’s provisional local proxy threshold into a hard constraint on further research.

+

#6133 distinguishes original goals and hard constraints from provisional candidate filters, calls for discriminating executed-artifact evidence, and retains scoped negative results. #6199 carries the original research task through startup, the Goal and recovery: implementation, testing and submission are milestones rather than acceptance. #6649 checks what actually reaches replanning, instead of substituting a generic reminder or truncating useful scoped evidence.

+

Persisting the goal makes it retrievable. Delivering it into the next decision gives it a chance to shape subsequent work. The host still enforces deadlines and stops. Goal continuity neither permits indefinite execution nor guarantees a good idea.

4. After failure, take a smaller step—or ask a different question?

+

Always shrinking after failure can trap an agent in local repairs. An implementation error and evidence against an entire mechanism require different responses.

+

#6298 separated work size, route distance and validation extent. #6321 then replaced mechanical grow / hold / shrink mapping with grow / switch / verify: extend a supported route, switch a refuted mechanism, or perform a discriminating experiment. Each route needs a concrete plan. A work unit must be large enough to complete a meaningful test; shorter per-turn text is not that unit.

+

For example, if a solver helps only on highly repetitive inputs, the next useful step might test how benefit depends on repetition before adopting a selector—or retain the old solver. This illustrates the decision distinction, rather than claiming a PR demonstrated general benefit. Explore findings must return to later reviews for assessment of adoption, new information and experiment consequences. A justified continuation need not change direction to raise a replan count.

+

These are optional planning mechanisms. Enabling them still requires checking actual decisions and subsequent outcomes; registering a plan does not demonstrate improvement.

5. What must a recovered research run remember?

+

Copying candidate code preserves only part of the research state. Forget evaluation opportunities already consumed, reset the cooldown or exclude recovery time, and a supposedly matched continuation quietly receives extra resources.

+

#6305 brings conversation, candidates, Explore, Goal, evaluation best, opportunities, cooldown and budget into one checkpoint. Writers pause and the checkpoint is sealed before decisions are released against it. #6622 moves fresh-session switching before replanning: if the old context already chose the route, switching afterward cannot answer how fresh context affects that decision.

+

This contract enables a more focused comparison after one research point: what each arm read, chose, executed and retained. It does not erase model, effort or runner differences, nor turn continuations from one donor into independent repetitions. Unknown recovery qualification remains unknown.

6. Hours later: a better start or new progress?

+

Later experiments shifted the emphasis to work after many hours. We compare a common observation window, then inspect the initial result, later increments and retained candidate. A final ranking alone hides these differences.

+ + + +
Historical cohortObserved resultInterpretation
Sol/xhigh, old/new LoopX, Ad Placement · 14h49,589,589,573 → 49,615,495,839Newer run trailed at 2h and led at 14h; its terminal workspace matched its retained best
Astra/xhigh, Official Grid · 6h → 12h1862 → 1810, lower is betterA stronger foundation baseline still produced useful late improvements
+

Ad Placement provides a concrete instance of later progress rather than a universal plateau. A worse subsequent candidate was rejected and the best version survived. Its raw-score lead is modest—about 0.052%—and only that arm has the cited terminal-workspace verification. The old/new packages changed core and runner together, so this is not an isolated LoopX-feature effect.

+

The Astra result expands the foundation-model frontier in our observations. Official separated speed changes from search changes and obtained successive native improvements. That progress belongs to the foundation/Official path; it cannot be credited to LoopX. Stronger models also raise the standard for a useful harness: context and review costs must earn their place against an improving baseline.

+

Schema: an initial lead is not sustained improvement

+

Schema is the detailed counterexample. In the Sol old/new 14-hour window, the newer run scored 0.804620 versus 0.723684. It already led at the first native result, 0.794620 versus 0.713158, received at different elapsed times. Subsequent increments were only 0.010000 and 0.010526. The larger endpoint advantage mostly reflected the initial result; continuing code changes did not close the six original target requirements.

+

A separate Astra/xhigh 12-hour comparison was less favorable: Official reached 0.881813 and LoopX 0.786257, with neither improving its best between 6h and 12h. LoopX recorded 36 completed compactions versus four, and about 5.32 times the uncached input. Compaction can overlap useful work, and versions, recovery, shared load and scorer conditions differ. The trace still identifies the practical challenge: producing more changes and more control activity did not produce more accepted value.

+
Conditions and limits of these windows

The Sol old/new study used planned + Explore, Sol/xhigh, TurnEnvelope off, agent-requested native feedback and a one-hour cooldown. The 14-hour window was selected after earlier observations as the largest whole hour below the earliest actual termination; it was not an 18-hour completion. The separate Astra study compares each arm’s own first 12 outer hours, including preparation. The Sol window reconciles 7,522 unique responses and 52 received native results; Astra reconciles 5,277 responses and 45 results. Cumulative counters were not repeatedly added; reasoning is included in output. Historical infrastructure failures and unknown whole-run integrity remain recorded. Different treatments, adaptive restarts and a prior operator exposure to an Official terminal aggregate prevent a clean causal verdict.

+

7. What does the control plane itself cost?

Another faulty assumption is that a smaller entry packet means a cheaper agent episode. Moving the goal, facts and writer instructions behind a second command shortens the first view, but the model still needs to read them. Losing context adds reconstruction of the same source. Measuring only entry delivery moves cost outside the table.

#7269 routes the original capture through a shared context reader: complete goals, facts and feedback first; writer format and settlement steps afterward. Review and writeback are two views of one immutable decision, rather than a second admission or two permission owners. Source regressions compare the goal, planning horizon, evidence references, complete writeback contract and action signature. A smaller entry must still reach every obligation.

Differencing adds a prerequisite: the receiver must retain the exact baseline. Within the same native session and context epoch, the current Hook path treats normal tool delivery after complete paging as an engineering assumption of continuity. Session changes, observed compaction, missing pages and known delivery failures invalidate it. Recovery then reads the original complete capture; a fresh decision from another guard cannot recover the old one. Missed hooks and unseen downstream truncation remain limits. A read receipt is not independent proof of model retention.

@@ -59,50 +76,7 @@

Measure structural input separately

Historical offline replay illustrates why totals matter: structured Host and native presentation bytes fell 57.72% and 60.23%, while native entry plus full recovery rose 6.37%. These are historical byte observations, not current-head model-token results. An earlier offline probe also reported a 2.25% increase in CLI bytes, but its qualification as an actual CLI delivery measurement was withdrawn: it omitted final CLI compaction and reformatted entry output. That figure remains only as an invalid historical measurement and supports no complete-delivery or cost conclusion. A 60% smaller view cannot be reported as 60% lower total cost.

Our current efficiency work connects ordinary and staged delivery to the shared transport, reduces repeated reads and rebinding, and removes avoidable settlement round trips. The default with differencing off matters as much as the opt-in path. Enabled delivery also has to recover correctly and remain easy to activate across the product and benchmark. The reference of 15% for all mechanisms combined remains unqualified; it is neither a separate allowance per mechanism nor a reason to omit failures or reconstruction.

-
-

4. Why check one runtime repeatedly during one read?

-

Some overhead belongs to the control plane itself. Reading an Explore context makes several calls to the same managed TS runtime. The Python transport checks its source fingerprint for each call; a request with many quantified findings repeatedly inspects the same source tree. The slow path is a real control-plane read, rather than model inference or the research algorithm.

-

#7013 reuses the existing effect_runtime_request_scope around explore_turn_context. One logical request resolves one runtime revision, and its internal calls use that code version. A finally block releases and resets the scope; the next request resolves afresh. The reused value is runtime code identity, not Goal state or research results cached across requests. TS owners still execute shared rules; Python removes repeated transport work.

-

The original PR measured real isolated CLI calls with 600 synthetic findings. Across three uninstrumented samples after separate warmup, medians changed from 4.005 to 0.495 seconds for File, and 4.268 to 0.603 seconds for SQLite, using Node 24.21, SQLite 3.53 and Python 3.14.8. Complete JSON and source-log bytes stayed equal. This is host latency on a specified historical workload, rather than a current-version remeasurement or eightfold whole-agent acceleration.

-

Regressions independently check that the next request sees a new finding, malformed history still fails, the failed request clears its scope, and a subsequent read recovers after source repair. The old version fails the one-fingerprint-per-request counterexample. A permanent cache could also look faster while losing these boundaries.

-

The direct value is obtaining the same decision input sooner while preserving freshness on the next request. Whether less waiting yields more validated work still needs a complete trajectory. This case measures neither lower model input nor fees.

-
-

5. Did the repairs produce long-horizon value?

-

The counterexamples above establish specific improvements to identity, reading and recovery. Effectiveness still depends on actual subsequent work. Early Lean showed system progress; Ad showed a late lead and retention of its best result. Schema exposed an initial advantage followed by little growth and high control cost. Same-checkpoint #7269 continuation reduced initial review round trips, yet Grid’s complete usage later increased. The original numbers, windows and negative results remain below, without pooling them into one mechanism’s benefit.

-
Feedback and continuation: early system comparisons -

How the research changed

- - - - -
StageQuestionWhat the evidence can establish
Feedback and continuationCan we trust results and keep authorized work useful?Evaluator defects, recovery failures and common-window system progress
Later decisionsDoes accumulated evidence improve the next experiment?Decision-to-work traces and changes after a mature research point
Context efficiencyCan we deliver the same obligations with less complete cost?Actual model input, recovery, tool calls and outcome/cost comparisons
-
Comparison boundaries

Historical studies include Official, single-call, native Goal, LoopX Resume and LoopX Explore. Explore adds optional evidence capture and planning to continued work. Blind runs retain public tasks, training data and local validators but receive no hidden judge scores or diagnostics; background operator evaluation is not solver feedback. Later native-feedback studies use agent-requested evaluation, a one-hour accepted-submission cooldown and no periodic grading. These are different studies, not one pooled treatment.

Models, effort, prompts, runners and budgets co-evolved. Early studies primarily used Sol/xhigh; later Sol/max and Astra/xhigh cohorts retain their own conditions. One run per arm is descriptive evidence. Missing, stopped, invalid and valid-zero results stay distinct. Source time, evaluation opportunities and cooldown survive checkpoint continuation; donor history is not a new independent repetition.

-

First make feedback and continuation trustworthy

-

The first Portfolio experiments exposed measurement and execution defects before they could tell us much about strategy. A blind wrapper had removed iterative optimization guidance along with the judge entrypoint. A ledger check attributed earlier market returns to holdings bought only at the closing price. Both confounded the intended comparison; repairing them required new attempts while preserving the old results.

-

One small oracle made the accounting error clear. Start with 100,000 cash, buy 100 units at a closing price of 200, and pay 10 commission. Immediate equity is 99,990 and NAV is 0.9999; the new holding did not earn the preceding rise from 100. Independent reconciliation then matched all 243 days in each of two frozen samples, with equity residual below 4×10⁻⁹ and no share-count difference. This established ledger consistency, not investment skill. The versioned repair is documented in EdgeBench #14.

-

Continuation had a related failure: an outer process could wake repeatedly after a work item ended without recovering a useful next action. The governing question must return to the original goal. Completing a Todo can justify another experiment, waiting, or completion; it cannot by itself settle goal acceptance. Correct recovery and feedback make subsequent research interpretable.

-

Early system progress was measurable

-
Blind Lean raw scoreEarly Resume v14Later Resume (#5844)Early Explore v14Later Explore (#5844)
180 minutes0.11030.34780.11340.4019
450 minutes0.18820.52430.19960.5605
-

These single-run common windows show roughly 2.8–3.5 times the earlier raw scores. Prompts, task entry, runner reliability and LoopX mechanisms changed together. The observation supports progress in the overall system; it does not identify one mechanism’s causal effect or guarantee terminal performance elsewhere.

-
-
-
Initial advantage, later improvement and retention -

Look beyond the first good result

-

Later experiments shifted the emphasis to work after many hours. We compare a common observation window, then inspect the initial result, later increments and retained candidate. A final ranking alone hides these differences.

- - - -
Historical cohortObserved resultInterpretation
Sol/xhigh, old/new LoopX, Ad Placement · 14h49,589,589,573 → 49,615,495,839Newer run trailed at 2h and led at 14h; its terminal workspace matched its retained best
Astra/xhigh, Official Grid · 6h → 12h1862 → 1810, lower is betterA stronger foundation baseline still produced useful late improvements
-

Ad Placement provides a concrete instance of later progress rather than a universal plateau. A worse subsequent candidate was rejected and the best version survived. Its raw-score lead is modest—about 0.052%—and only that arm has the cited terminal-workspace verification. The old/new packages changed core and runner together, so this is not an isolated LoopX-feature effect.

-

The Astra result expands the foundation-model frontier in our observations. Official separated speed changes from search changes and obtained successive native improvements. That progress belongs to the foundation/Official path; it cannot be credited to LoopX. Stronger models also raise the standard for a useful harness: context and review costs must earn their place against an improving baseline.

-

Schema: an initial lead is not sustained improvement

-

Schema is the detailed counterexample. In the Sol old/new 14-hour window, the newer run scored 0.804620 versus 0.723684. It already led at the first native result, 0.794620 versus 0.713158, received at different elapsed times. Subsequent increments were only 0.010000 and 0.010526. The larger endpoint advantage mostly reflected the initial result; continuing code changes did not close the six original target requirements.

-

A separate Astra/xhigh 12-hour comparison was less favorable: Official reached 0.881813 and LoopX 0.786257, with neither improving its best between 6h and 12h. LoopX recorded 36 completed compactions versus four, and about 5.32 times the uncached input. Compaction can overlap useful work, and versions, recovery, shared load and scorer conditions differ. The trace still identifies the practical challenge: producing more changes and more control activity did not produce more accepted value.

-
Conditions and limits of these windows

The Sol old/new study used planned + Explore, Sol/xhigh, TurnEnvelope off, agent-requested native feedback and a one-hour cooldown. The 14-hour window was selected after earlier observations as the largest whole hour below the earliest actual termination; it was not an 18-hour completion. The separate Astra study compares each arm’s own first 12 outer hours, including preparation. The Sol window reconciles 7,522 unique responses and 52 received native results; Astra reconciles 5,277 responses and 45 results. Cumulative counters were not repeatedly added; reasoning is included in output. Historical infrastructure failures and unknown whole-run integrity remain recorded. Different treatments, adaptive restarts and a prior operator exposure to an Official terminal aggregate prevent a clean causal verdict.

-
-
-
Same-checkpoint review: actual work and complete input -

Ask whether evidence changed the next work

+
Same-checkpoint continuation: outcomes and complete usage

Ask whether evidence changed the next work

A mature checkpoint helps inspect a specific decision boundary. Both receivers inherit the same scientific state and incumbent; we then follow the evidence they read, the experiment they choose, the work they actually perform and the native feedback. A negative local result can be useful if it rules out a branch under stated conditions. Replanning need not force a direction change when continuing is justified.

Recent work on #7269 makes the reader first consume the goal, facts and feedback, then the writeback format. It also releases obsolete task-selection preference and preserves the original Turn settlement after a successor is created. This addresses two observed sources of wasted interaction: reading writer instructions before deciding, and needing another round to resolve which work was settled.

@@ -120,14 +94,22 @@

Measure structural input separately

Same-point Sol/max continuationBaseline → revisedBoundary
Schema revised622,478 (−26.52%)37,570,432 (−7.75%)113,162 (−0.45%)

This observation covers the common 82m27s outer window through October 25, 15:42:31 UTC: initial recovery, review, ordinary work and persisted requests in unfinished Turns. Retained native counters from all four stopped arms were reconciled against their shared donor boundaries, with no counter gaps. Last persisted requests differ by up to 2m22s; unpersisted usage remains unknown. Grid’s revised arm used more of all three components; Schema’s did not increase. In the earlier 68m26s window, Grid’s uncached input fell 7.25%; the longer common window reverses that to a 3.60% increase. Choosing only the earlier window would misrepresent the result. Local review savings have not established net savings for the complete episode.

-
-
-
-

6. Context validation starts from zero

-

The current context study starts Grid, Schema and Ad Placement from their original tasks with Sol/max and an 18-hour upper limit per case. Historical Official or older LoopX runs provide descriptive references where usable. Their model/effort, source, scorer, opportunity and clock differences remain visible; they are not strict matched controls. A new baseline is warranted where the old material cannot answer the relevant question. Attempts with different source versions, continuity bases or transports are analyzed separately, rather than pooled as one treatment.

+
Recent implementation details, in their historical place

A new route exists. What closes the original work?

+

A review can conclude that a route lacks evidence and create a successor validation task. That task now exists, but the review itself still needs writeback and settlement. If another admission read immediately selects the successor, the model receives conflicting identities: the completed review belongs to the old Turn, while the new task appears to own the current work. Another model wake does not resolve that conflict.

+

#7269 converges the control plane’s continuation semantics. Creating a successor proves a route was recorded; it neither settles the original Turn nor authorizes the successor’s execution. The existing TypeScript replan-transition and quota-settlement owners retain the creation receipt, original obligation and Turn binding. A same-Turn reread returns the original settlement steps. After writeback, only settlement remains; after settlement, this Turn stops. The successor stays open for fresh admission.

+

This also requires separating must_attempt from delivery_allowed. The former requires addressing this Turn’s work obligation; the latter describes permission for ordinary delivery. A required replan can have legitimate planning work while ordinary delivery remains closed. Opening ordinary execution merely to make the agent act would be an authority bug. Leases, budgets, stops and admission for the successor retain their existing owners.

+

Real File / SQLite CLI regressions create a successor and execute the returned writeback and settlement commands unchanged. Premature spending is rejected, repeated settlement produces one debit, and the successor does not replace the original Turn. A later Turn selects the new task. Negative cases change ownership, defer the task or remove its claim; an invalidated creation receipt cannot settle the original result. These checks exercise the state transition and real entrypoint, beyond one field or ACK.

+

The repair keeps model attention on the next useful test and removes opportunities for repeated identity negotiation and admission. It does not guarantee insightful subsequent research. We still follow evidence through a decision, actual work and native outcomes. The same-checkpoint observations provide limited positive evidence and contrary results.

+

Why check one runtime repeatedly during one read?

+

Some overhead belongs to the control plane itself. Reading an Explore context makes several calls to the same managed TS runtime. The Python transport checks its source fingerprint for each call; a request with many quantified findings repeatedly inspects the same source tree. The slow path is a real control-plane read, rather than model inference or the research algorithm.

+

#7013 reuses the existing effect_runtime_request_scope around explore_turn_context. One logical request resolves one runtime revision, and its internal calls use that code version. A finally block releases and resets the scope; the next request resolves afresh. The reused value is runtime code identity, not Goal state or research results cached across requests. TS owners still execute shared rules; Python removes repeated transport work.

+

The original PR measured real isolated CLI calls with 600 synthetic findings. Across three uninstrumented samples after separate warmup, medians changed from 4.005 to 0.495 seconds for File, and 4.268 to 0.603 seconds for SQLite, using Node 24.21, SQLite 3.53 and Python 3.14.8. Complete JSON and source-log bytes stayed equal. This is host latency on a specified historical workload, rather than a current-version remeasurement or eightfold whole-agent acceleration.

+

Regressions independently check that the next request sees a new finding, malformed history still fails, the failed request clears its scope, and a subsequent read recovers after source repair. The old version fails the one-fingerprint-per-request counterexample. A permanent cache could also look faster while losing these boundaries.

+

The direct value is obtaining the same decision input sooner while preserving freshness on the next request. Whether less waiting yields more validated work still needs a complete trajectory. This case measures neither lower model input nor fees.

+

8. Context deltas: qualification gaps recorded on October 28

+

The context study recorded on October 28 starts Grid, Schema and Ad Placement from their original tasks with Sol/max and an 18-hour upper limit per case. Historical Official or older LoopX runs provide descriptive references where usable. Their model/effort, source, scorer, opportunity and clock differences remain visible; they are not strict matched controls. A new baseline is warranted where the old material cannot answer the relevant question. Attempts with different source versions, continuity bases or transports are analyzed separately, rather than pooled as one treatment.

First verify that actual delivery changes: the initial full read, a subsequent delta with its continuity basis stated, complete fallback after known baseline loss, and a full review-to-work interaction. Then compare useful progress, retained artifacts and the complete usage vector. Requested flags, receipts and smaller local packets cannot substitute for that evidence. If the feature fails its intended behavior, stop the affected attempt, preserve its costs and history, repair it and use a new attempt identity.

The first Grid and Ad interactions on the new native Hook path have completed full paging, one delta and subsequent task work. Within each same capture, the delta payload was 19.53% and 19.48% smaller than its corresponding full packet. These are single-read payload comparisons: they exclude page envelopes, subsequent model input, hooks, recovery and review costs. They do not establish lower total cost. A complete review-to-native-outcome cycle, sustained benefit and failure recovery remain to be verified.

Our effectiveness target is useful progress after many hours and reliable retention of it. Our efficiency target is comparable accepted value with less complete cost and human attention. The next result must address both. Current runs retain the original deadline, and failed or replaced attempts retain their costs and history.

-
-

Numerical evidence retains each stated historical model, version, window and validity boundary. Public implementation: LoopX. Earlier detailed research records remain in the previous article revision. Raw trajectories, hidden evaluator material, runtime credentials and private operating context are not published here.

+
diff --git a/apps/presentation/site/public/blog/typescript-control-plane-refactor/index.html b/apps/presentation/site/public/blog/typescript-control-plane-refactor/index.html index 5ac590ce52..ad93fa784d 100644 --- a/apps/presentation/site/public/blog/typescript-control-plane-refactor/index.html +++ b/apps/presentation/site/public/blog/typescript-control-plane-refactor/index.html @@ -12,7 +12,7 @@ -
← All articles

LoopX 2.0 · Engineering

LoopX 2.0: Two Months of TypeScript Control-Plane Engineering

From complete transactions and shared authority to model-assisted semantic repairs: real callers, counterexamples and complete costs behind LoopX’s TypeScript control plane.

+
← All articles

LoopX 2.0 · Engineering

LoopX 2.0: Two Months of TypeScript Control-Plane Engineering

An effect succeeds without a checkpoint. An expired executor returns with a valid receipt. An evidence correction restarts finished work. Two months of refactoring brought these problems under complete transactions and shared semantics.

LoopX 2.0 is out. This is an account of the history and technical details behind its TypeScript refactor.

The formal migration RFC merged on August 15. By the concentrated retirement of ordinary legacy writers in mid-October, the program had spanned roughly two months. Several tracks overlapped: transaction ownership, caller integration, shared authority, storage and history costs, Semantics, compatibility, and retirement.

@@ -324,18 +324,27 @@

Counterexamples for the checker itself

False alarms and missed values have different consequences. A conservative candidate set may report an extra problem. Missing a real produced value can let an unregistered output through. Unsupported dynamic forms must preserve an unknown.

The checks also need scan-coverage floors, so scanning fewer files cannot make the result green. Retiring an expanding committed inventory in favor of on-demand full-tree computation did not remove that obligation. Gaps outside supported forms remain explicit, and the tracking issue remains part of the work.

Generation and checking reduce synchronization mistakes. Their assumptions, coverage, and error direction still require review.

-

8. Using stronger models to repair control-plane semantics

-

After migration, we continue using stronger models for design, implementation and review, tracing what a state means across producers, rules, callers and recovery. Models help uncover assumptions spanning files and runtimes; their explanations still face real entrypoints and counterexamples. Both later repairs below fall after October 16 and outside the two-month historical statistics.

-

Correct arguments can still recover through the wrong program

-

The wrong assumption in #7145 was that preserving Goal, Agent and Turn arguments preserved the operation’s recovery route. After entry through an explicit runtime, a failed selection could return a command invoking the global loopx on PATH. Work identity survived, but the executable interpreting its rules changed, potentially loading another version or runtime route.

-

The repair reuses the existing CLI entrypoint builder to carry runtime routing alongside work identity. The regression puts a deliberately failing global CLI first on PATH, then executes the returned argv unchanged. Real File / SQLite paths check original routing, rejection before business side effects and settlement of the original result once. Assertions that a few argument strings appear would miss this defect.

-

An obligation to act is not permission for arbitrary work

-

#7269 further separates the obligation to advance work, ordinary execution permission and original-Turn closeout. A required replan can set must_attempt while ordinary delivery_allowed stays closed. Creating a successor records a new route; it cannot move the old review’s settlement to the new task. Shared TS replan and settlement owners retain the original binding, return its closeout steps on a same-Turn reread, and leave the successor for fresh admission.

-

Native CLI regressions execute the actual returned writeback, settlement and replay. Invalidated-successor cases check that changed ownership, deferral or a removed claim cannot use an old receipt to settle. Whether less identity negotiation improves later work still depends on actual outcomes and complete cost. The kernel efficiency and effectiveness article follows that chain and retains negative context-cost measurements.

-

This extends the earlier #3464 lesson: fewer calls still require preflight before side effects. We constrain model-assisted work through a wrong assumption → the shared semantic owner → an old-version counterexample → real calls, refusal and recovery. The repaired meaning is what matters. PR counts, generated TypeScript and test counts do not independently establish model benefit. We have no per-PR model comparison attributing these repairs to a particular model’s independent causal effect.

+

8. The semantic questions we put stronger models to work on

+

We use stronger models in design, implementation and review, especially to trace assumptions across files and runtimes. The difficult cases often combine individually reasonable checks into an unsafe execution order. Core PRs in August and September already dealt with these problems; they were part of the migration itself.

+

The effect happened, but its checkpoint did not. Is retry safe?

+

A provider succeeds, then the process crashes before writing the checkpoint. The journal says unfinished; a blind retry may execute twice. Treating every uncertain result as success would instead lose work that never happened. A try/catch cannot settle that distinction.

+

On August 22, #3485 introduced a durable prepared attempt and stable effect identity before execution. Recovery asks the provider: confirmed committed means checkpoint the original result; confirmed absent permits execution with the same identity; unknown remains pending recovery. Effect order, receipt prefixes and identity checks remain part of the contract. This is not arbitrary external exactly-once execution: confirming the result depends on provider recovery support.

+

This complements the preflight in #3464. Before execution, determine whether the effect is allowed; after interruption, determine whether it already happened. Moving Python functions to TS one at a time does not protect both boundaries.

+

On September 13, #4286 converged receipt recovery for seven Todo operations on one owner while retaining a finer distinction. Suppose two agents update a task: A commits first; B receives a definite version-conflict rejection, then loses its connection while reading the receipt. The later read failure must not erase the earlier rejection. If the connection drops before the commit response arrives, the result remains uncertain and recovery must use the original operation identity.

+

Both paths can encounter a network error, but they require different next steps. The shared implementation attempts the write once, then reads the original receipt. Its regressions distinguish conclusive rejection, commit uncertainty and exact-receipt recovery. Shared error handling must retain the phase of failure and facts already established.

+

Claiming work and acquiring execution rights must commit together

+

Two agents see an unclaimed task. If the claim is written before the lease is acquired, who owns the intermediate state? If an earlier claimant returns with a receipt after its lease expires, may it keep writing?

+

From the coordination foundations in #3529 and #3669 to the September 6 transaction in #4032, claim, lease and operation receipt converge on one conditional commit. The #3798 store owns atomic persistence; the domain owner checks identity, scope and legal transitions. A receipt proves a past claim succeeded. The current lease and epoch determine permission now. Replay must recover the original result without reviving expired execution rights. Storage revision, domain revision and lease epoch remain different identities.

+

Idempotency therefore requires more than returning an old success. Recovery must remember history and respect present authority. Foundation, shadow and production qualification arrived in stages; the first interface merge did not establish deployment of every backend.

+

Why could correcting evidence restart finished work?

+

A planning update corrects evidence without changing monitor state. Rebuilding the object from defaults can accidentally rearm an already satisfied monitor. Conversely, an explicitly empty list or false cannot be interpreted as an omitted input.

+

On September 10, #4178 converged planning updates on one authority snapshot and a complete TS transaction: omission retains intent, explicit clearing follows field and authority rules, and evidence correction does not rearm a satisfied monitor. It also removed Python’s serialize-to-Markdown-and-parse-back route. This repaired behavior as well as consolidating ownership; describing it as a mechanically equivalent language translation would miss the point.

+

Song’s #4433 and #4494 extended this discipline to vocabulary definitions, actual producers and consumers. A compiling enum does not establish that all callers mean the same thing. The earlier skip / quota_skip example and separation of action from decision belong to this same thread.

+

Making a plausible model answer face a counterexample

+

Ask for the mistaken assumption, then an execution sequence that refutes it: disconnect after commit, replay an expired lease, correct only evidence, explicitly clear a value. Check the real owner, provider and caller.

+

Stronger models help connect scattered conditions; counterexamples, real storage and refusal paths constrain their answers. There is no per-PR model comparison here, so these examples cannot quantify a particular model’s independent contribution. They show the mechanisms and reasons for changing them. Later runtime routing in #7145 and original-Turn closeout in #7269 continue this work rather than defining its whole history.

9. Callers and defaults determine whether migration reaches users

-

Complete transactions need real producers. In September, #4178 converged nonterminal planning updates around one authority snapshot and a TS transaction. It removed a Python route that synthesized Markdown, parsed it again, and performed target reads before the transaction.

-

Omission, null, an empty value, and false each carry intent here. Dry-run must model that intent accurately. An unavailable selected provider must not trigger fallback elsewhere. #4279 later converged read classification and projection-delivery semantics. Some Python read ownership was deliberately retained. Clear ownership matters more than creating a second interpretation to pursue language purity.

+

Complete transactions also need callers to express intent accurately. In #4178, a blank note means no update; an explicit empty list or false is interpreted by its field’s contract. These values cannot all be discarded as absent, or all treated as clearing. Dry-run must model that intent accurately. An unavailable selected provider must not trigger fallback elsewhere. #4279 later converged read classification and projection-delivery semantics. Some Python read ownership was deliberately retained. Clear ownership matters more than creating a second interpretation to pursue language purity.

Defaults expose similar distinctions. Current priority regressions protect these cases:

diff --git a/apps/presentation/site/public/blog/zh/edgebench-feedback-and-memory/index.html b/apps/presentation/site/public/blog/zh/edgebench-feedback-and-memory/index.html index df4782aee8..b939f4df97 100644 --- a/apps/presentation/site/public/blog/zh/edgebench-feedback-and-memory/index.html +++ b/apps/presentation/site/public/blog/zh/edgebench-feedback-and-memory/index.html @@ -3,41 +3,58 @@ -LoopX 控制面内核:长程工作的效果与效率 · LoopX - +让 Agent 多做十小时,究竟多做出了什么? · LoopX + - - + +
-
-

黄睿腾 · 更新于 2026 年 10 月 28 日 · 内核工程与研究

-

LoopX 控制面内核:长程工作的效果与效率

-

原 Turn 收尾、上下文交付与重复读取的三处修复

-

Agent 能运行更久,还要让后续工作有价值、成果保得住,并让控制面本身的成本值得付出。

-

EdgeBench 的长轨迹为我们暴露控制面问题提供了场景:任务已换方向,原 Turn 却未收尾;入口上下文缩短了,恢复总量却增加;一次读取反复核验同一份运行时。这篇沿共享语义 owner 解释三处修复,以及它们解决了什么、还没有证明什么。

-
- -

1. 内核怎样帮助长程工作?

+

黄睿腾 · 2026 年 10 月 29 日

让 Agent 多做十小时,究竟多做出了什么?

EdgeBench 如何反过来改造 LoopX 的长程控制面

一项研究可以起步更好,却在接下来的十小时里几乎没有增长。也可以不断改代码,最后丢掉最好结果。我们用这两种失败,重新审视目标、反馈、实验步长与恢复。

这条研究从 10 月初的轨迹诊断开始,先修评测与续跑,再追踪证据怎样进入下一次实验,最后把控制面自己的成本算进来。下面按这个过程展开:哪些机制改了,哪些结果支持它,哪些结果迫使我们改方向。

这里的 kernel 指 LoopX 共享的目标、准入、事务和恢复规则。LoopX 让原始目标、验收条件、工作归属和证据跨会话、跨宿主持久化。控制面约束状态转换,为模型的下一步提供反馈,但不能认证这个选择是否高明。一条发现、一次读取回执、一条 replan 记录都只是中间证据;真正需要追踪的链条,要落到实际工作和经过验证的成果。

-

这些规则的归属和强模型参与的语义修复,见 TypeScript 重构一文。下面分别检查接续正确性、完整交付成本和 Host 读取成本。

+

这些规则的归属和强模型参与的语义修复,见 TypeScript 重构一文。下面从研究过程检查这些规则怎样影响实际工作。

  1. 目标验收与范围
  2. 证据结果与限制
  3. 决策继续或换方向
  4. 工作执行与验证
  5. 保留保住最佳有效成果

我们区分起点优势、后续增量和最佳成果保留。更高的最终分数,可能主要来自更强的起点;更好的中间候选,也可能没有留在终态工作区里。运行更久、Todo 更多、图更大,都不能替代这三项判断。

-
-

2. 新路线已确定,原来的工作怎样收尾?

-

一次长程工作可能在复盘时发现:原路线的证据不足,应该登记一个新的验证任务。后继 Todo 已经创建,但这轮复盘的结果还没有写回和结算。如果再次读取准入就改选新 Todo,模型会面对两份身份:刚做完的复盘属于旧 Turn,新的工作却被投影成当前任务。多叫醒一次模型,并不能解决这项归属冲突。

-

#7269 收敛的是控制面的接续语义。创建后继任务证明路线已经落地,不证明原 Turn 已经结算,也不授予新任务执行权。 原有 TypeScript replan transition 和 quota settlement owner 保留创建回执、原义务与原 Turn 的绑定;同轮重读返回原结算步骤。写回后只剩待结算步骤,结算后这轮停止,新任务保持 open,留给下一次正常准入。

-

这里还必须区分 must_attempt 和 delivery_allowed:前者要求处理本轮的工作义务,后者描述普通交付是否获准。需要重规划时,即使普通交付关闭,合法的规划工作仍可继续;不能为了让 Agent“动起来”就打开普通执行许可。租约、预算、停止条件和后继任务的准入继续由原 owner 判断。

-

真实 File / SQLite CLI 回归先创建后继,再原样执行返回的写回和结算命令:提前扣额被拒绝,重复结算只有一次 debit,原 Turn 不被后继替换,下一 Turn 才选择新任务。另有归属改变、延后和撤回 claim 的负例,证明失效的创建回执不能结算原结果。这里验证的是完整状态转换和真实入口,不能由一个字段或一次 ACK 代替。

-

这项修复让模型把注意力留给“接下来验证什么”,减少为结算身份反复解释和重新准入的机会。它没有保证下一项研究一定有效;我们仍要追踪证据、选择、后续实际工作和原生成果。同点接续观察给出了有限正向结果及其反证。

-
-

3. 上下文变短,完整交付也变便宜了吗?

+

1. 先看整个研究过程

时间焦点改变实现
10 月初反馈与实验起点排查盲跑提示、账本与恢复错误;建立原始任务、评分和续跑的边界。#5586, #5844, #5879
10 月 9–11 日原目标与有效反馈保留完整评测响应、候选身份、原始要求;一次实现或提交不能冒充 Goal 完成。#6031, #6039, #6133, #6199
10 月 12–16 日实验步长与恢复点从机械缩小动作,转向 grow / switch / verify;联合保存会话、候选、评测机会和预算,复盘前切换 fresh context。#6298, #6321, #6305, #6622, #6649
10 月中下旬后程改善与成果保留共同窗口拆开起点、后续增量和 best 保留;Schema 的高成本与平台期成为反证。#6440, #6532, #6671
10 月 22–28 日控制面完整成本减少被动轮询和重复读取;核对原 Turn 收尾、完整上下文、差分失效回退及恢复费用。#6983, #7013, #7036, #7197, #7269

按机制改变和可解释的失败选择案例;表中 PR 是阶段锚点,不是逐日全量发布清单。日期表示研究阶段,具体创建、合入及历史资格以链接为准。

2. 先确认反馈值得相信

+

最初的 Portfolio 实验先暴露了测量和执行缺陷。一个盲跑 wrapper 在移除评测入口时,也删掉了迭代优化提示;一个账本检查把更早的市场收益归给了收盘时才买入的持仓。它们都混淆了原本的比较。修复后必须另起尝试,旧结果继续保留。

+

一个小反例就能说明记账问题:初始现金 100,000,在收盘价 200 时买入 100 单位并支付 10 手续费,即时权益应为 99,990,NAV 为 0.9999;新持仓没有赚到此前从 100 涨到 200 的收益。之后,对两个冻结样本独立重建,各自 243 天全部吻合,权益残差小于 4×10⁻⁹,股数没有差异。这证明账本一致,不证明投资策略优秀。版本化修复见 EdgeBench #14。

+

续跑也有类似问题:某个工作项结束后,外层进程可以不断唤醒,却没有恢复出有用的下一步。判断必须回到原始目标。Todo 完成之后,可以继续实验、等待或结束,但它本身不能代表 Goal 验收。可靠反馈与恢复让之后的研究变得可解释。

+

长任务没做完,何时检查方向?

+

一个证明任务可以连续做几个小时,Todo 始终处于进行中。如果复盘只在完成若干 Todo 后触发,最需要检查的长任务反而可能一直等不到检查。把任务人为拆碎来凑次数,也不会改善研究。

+

10 月 7 日的 #5879 改了计数依据:按照已经结算的有效工作 Turn触发复盘,同一个 Todo 尚未完成时也能检查方向。这不是每调用一次工具就复盘。只写入进度而未完成结算,不增加次数;重复历史也不能重复计数。原有明确的 Todo 单位设置继续保留,各批实验仍按自己的冻结配置分析。

+

另一半修复在复盘之后。判断现有方法仍然可行,可以带着证据继续原任务,无须为了证明“重规划过”而换路线。该合入版本的真实 CLI 回归覆盖了同一未完成 Todo 上的结算计数、缺失结算回执时不计数、拒绝没有证据引用的复盘,以及有证据地继续后再次获得工作准入。它验证了检查方向的时机与恢复执行的路径;模型是否作出更好的选择,仍要看后续实验。

+

早期系统进展可以量化

+
盲跑 Lean 原始分早期 Resume v14后期 Resume(#5844)早期 Explore v14后期 Explore(#5844)
180 分钟0.11030.34780.11340.4019
450 分钟0.18820.52430.19960.5605
+

这些单次运行的共同窗口里,后期原始分约为早期的 2.8–3.5 倍。提示、任务入口、runner 可靠性和 LoopX 机制一起变化。它支持整体系统有进展,不足以归因给某个机制,也不能保证其他题的终态表现。

+
比较边界

历史研究包含 Official、单次调用、原生 Goal、LoopX Resume 和 LoopX Explore。Explore 在续跑基础上增加可选的证据采集和规划。盲跑仍可使用公开任务、训练数据和本地验证器,但收不到隐藏评测分数和诊断;后台操作者评测不是 solver 反馈。后来的 native-feedback 研究由 Agent 主动申请评测,按已接受提交执行一小时冷却,不做周期评测。这些是不同研究,不能合并成一个处理效应。

模型、effort、提示、runner 和预算共同演化。早期主要用 Sol/xhigh,后来的 Sol/max、Astra/xhigh 批次各自保留条件。每臂一次运行只能提供描述性证据。缺失、主动停止、无效和有效零分分别记录。Checkpoint 接续保留源时间、评测机会和冷却;donor 历史不算新的独立重复。

3. Agent 完成了自己列的任务,却没完成你的目标

+

长程研究的一个危险漂移是:原目标要求改善算法,Agent 把它拆成“实现方案、跑测试、提交结果”。三项 Todo 都完成了,外层循环也结束了,但算法是否更好仍未得到回答。另一个漂移来自 Agent 自己加的筛选门槛:某个局部 proxy 不过线,就被升级成不能继续研究的硬限制。

+

#6133 把原始目标和硬约束,与 Agent 的暂定候选条件区分开;要求有区分力的实际产物证据,并保留适用范围明确的负结果。#6199 将原始研究任务贯穿启动、Goal 与恢复:实现、测试、提交都是里程碑,不能替代目标验收。到 #6649,检查又深入到真正送进 replan 的内容——不能用泛化提醒替代原问题,也不能把有用的 scoped evidence 截成短尾巴。

+

把目标存进文件,只解决了“找得到”;把它完整送进下一次决策,才有机会约束“接下来做什么”。 期限与停止仍由宿主执行。保留目标不等于允许无限续跑,也不保证模型一定找到好方案。

4. 失败之后,应该做小一点,还是换一个问题?

+

如果失败后总是缩小步长,Agent 很容易陷在局部修补里。一次失败可能来自实现错误,也可能说明整个机制假设不成立;这两种情况不该得到同一个“做少一点”。

+

#6298 先把工作规模、路线距离、验证范围分开。随后 #6321 将 grow / hold / shrink 的机械映射改为 grow / switch / verify:扩大已有根据的路线,切换被反证的机制,或者补一个能分辨假设的实验。每条路线需要自己的具体计划,工作单元要足以完成一次有效检验,不能只缩短每轮文本。

+

例如一种求解策略只在高重复输入上有效,合理下一步可能是验证收益是否跟重复程度相关,再决定是否采用选择器;也可能是保留旧策略。这个例子说明三种决策的区别,不是声称某一 PR 已证明通用收益。Explore 记录的发现还要回到后续复盘,看它是否被采用、带来新信息或改变了实验。没有必要为了增加“转向次数”而强行换路线。

+

这些是可选的规划机制。启用它们之后,仍需验证真实决策和后续成果;一个已登记的实验计划不是效果提升。

5. 恢复一次研究,要恢复哪些东西?

+

复制候选代码,只保住了研究状态的一部分。如果接收者忘记已经用过的评测机会、从零计算冷却时间,或把恢复耗时从预算里抹掉,“同点接续”就悄悄获得了额外资源。

+

#6305 将会话、候选、Explore、Goal、评测 best、机会、冷却和预算一起纳入 checkpoint。先暂停写入并封存,再允许围绕该状态做决策。#6622 把 fresh-session 切换提前到复盘之前:否则关键路线已被旧上下文选定,随后换会话无法回答“新上下文怎样影响这次选择”。

+

这个恢复合同支持更有针对性的比较:同一研究点之后,两臂读到了什么、选择了什么、实际跑了什么、留下哪个有效结果。它不能自动消除模型、effort 和 runner 差异,也不能把同一个 donor 的接续当作新的独立重复。未知的恢复资格继续保留为未知。

6. 十几个小时之后,是起点优势,还是新的进展?

+

后来的实验把重点转向十几个小时之后的工作。先比较共同观察窗口,再拆开起点、后续增量和保留的候选。只看终点排名,很容易混淆它们。

+ + + +
历史批次观察结果含义
Sol/xhigh,新旧 LoopX,Ad Placement · 14h49,589,589,573 → 49,615,495,839新版 2h 时落后、14h 时领先,终态工作区与保留的 best 一致
Astra/xhigh,Official Grid · 6h → 12h1862 → 1810,越低越好更强的基础模型基线仍在后程产生有效改善
+

Ad Placement 说明后程并非必然平台期:后来的差候选被拒绝,最佳版本保住了。原始分领先约 0.052%,幅度不大;这里的终态工作区核验也只覆盖这一臂。新旧包同时改变 core 和 runner,不能当作某个 LoopX feature 的独立效应。

+

Astra 的结果推进了我们观察到的基础模型能力边界。Official 将速度修改和搜索修改分开,得到连续的原生改善。这项进展属于基础模型/Official 路径,不能算到 LoopX 头上。更强模型也提高了 harness 的要求:面对不断进步的基线,上下文与复盘成本必须换来相应价值。

+

Schema:起点领先不等于持续改善

+

Schema 是这里展开的反例。Sol 新旧版 14 小时窗口,新版 0.804620、旧版 0.723684。但第一次原生结果已经是 0.794620 对 0.713158,且收到反馈的耗时不同。后续增量仅为 0.010000 和 0.010526。较大的终点优势主要来自起点;后续不断改代码,仍未完成原始六项目标。

+

另一组 Astra/xhigh 的 12 小时比较更不利:Official 达到 0.881813,LoopX 为 0.786257,两边 6h 到 12h 的 best 都没有提升。LoopX 记录了 36 次完成的压缩,Official 为四次;未缓存输入约为其 5.32 倍。压缩可能与有效工作重叠,版本、恢复、共享负载和评分条件也有差异。但轨迹仍指出了实际挑战:更多改动和控制活动,没有转化为更多验收价值。

+
这些窗口的条件与限制

Sol 新旧研究采用 planned + Explore、Sol/xhigh、关闭 TurnEnvelope、Agent 主动申请 native feedback、一小时冷却。14h 是读过早期结果后,按最早实际结束时间以下的最大整小时选定,并非完成 18h。另一组 Astra 比较各臂自己的前 12h,包含准备。Sol 窗口对齐了 7,522 个独立 response 和 52 个收到的原生结果,Astra 为 5,277 个 response、45 个结果;累计计数没有反复累加,reasoning 已在 output 中。历史基础设施失败及整次运行完整性未知继续保留。处理包不同、自适应重启,以及此前操作者读到过一个 Official 终态汇总,都限制了因果判断。

+

7. 控制面自己花掉了多少成本?

另一个错误假设是:入口 packet 变短,Agent 的总成本就会下降。把目标、事实、写回说明从入口挪到第二条命令,确实缩短了首屏;模型随后还要读取它们。若中途丢失上下文,又要重建同一份来源。只量入口,就把成本移出了表格。

#7269 将原有捕获交给共享的上下文 reader:先读完整目标、事实和反馈,再读写回格式及结算步骤。review 与 writeback 是同一个不可变决策的两个视图,不是重新做一次准入,也不各自拥有一套权限判断。源码回归逐项核对目标、规划范围、证据引用、完整写回合同和 action signature;小入口必须仍能到达完整义务。

差分还增加了一个前提:接收者确实保留了那份精确基础。当前 native Hook 路径在同一会话和 context epoch 内,把完整分页后的正常工具交付作为连续性工程假设。会话变化、已观察到的压缩、缺页或已知交付失败会使它失效,随后读取原来的完整 capture;另开一次 guard 取得的新决策不能代替恢复旧决策。漏掉的 Hook 和不可见的下游截断仍是限制,读取回执不是模型保留内容的独立证明。

@@ -59,50 +76,7 @@

把结构输入单独计量

历史离线回放说明了为什么必须算总量:结构化 Host 和原生呈现字节下降 57.72%、60.23%,原生入口加完整恢复上升 6.37%。这些是历史字节观察,不是当前提交的模型 token 结果。早期离线探针还曾报告 CLI 字节增加 2.25%,但因漏掉最终 CLI 压缩并重新格式化入口,已撤回其实际 CLI 交付测量资格。该数字仅作为无效历史记录保留,不用于完整交付或成本结论。不能把视图缩小 60% 写成总成本下降 60%。

当前效率工作把普通入口、分段交付接到共享传输,减少重复读取和重新绑定,消掉可避免的结算往返。差分关闭的默认路径同样重要;开启后也必须正确恢复,并让产品和 benchmark 都易于启用。所有机制合计 15% 的参考目标尚未完成资格验证;它不是每个机制各有一份额度,也不能用来漏记失败和重建成本。

-
-

4. 一次读取,为什么重复检查同一份运行时?

-

有些开销来自控制面自己。读取一页 Explore 研究上下文,需要多次调用同一个受管理的 TS runtime。Python transport 每次调用都核验运行时源码指纹;在包含大量量化发现的请求里,同一份源码树被反复检查。慢的是这一条真实控制路径,不是模型推理,也不是研究算法。

-

#7013 复用已有 effect_runtime_request_scope,把 explore_turn_context 包在一个逻辑请求内。同请求只解析一次 runtime revision,内部调用使用相同代码版本;离开请求时在 finally 中释放并重置,下一次读取重新解析。复用的是运行时代码身份,不是跨请求缓存 Goal 状态或研究结果。 共享规则仍由 TS owner 执行,Python 只收敛 transport 的重复工作。

-

原 PR 对 600 条合成发现执行真实隔离 CLI:单独预热后取三次未插桩样本,中位数 File 从 4.005 秒降至 0.495 秒,SQLite 从 4.268 秒降至 0.603 秒;环境为 Node 24.21、SQLite 3.53、Python 3.14.8。完整 JSON 与来源日志字节一致。这是具名历史负载上的 Host 延迟,不是当前版本复测或整轮 Agent 的八倍提速。

-

回归还独立检查:下一次请求能读到新 finding;损坏历史继续报错;失败后 scope 已清除,修复来源后的下一次读取可恢复。旧实现会在“一次请求只核验一次”的反例上失败。单纯加一个永久缓存虽然也可能更快,却会失去这些边界。

-

这类优化的直接价值,是更快拿到同一份决策输入,同时保留下一次请求的新鲜性。更少墙钟等待是否换来更多可验证成果,仍需要完整工作轨迹;本例没有测出更少模型输入或费用。

-
-

5. 工程修复有没有换来长程价值?

-

上述反例能证明身份、读取和恢复的具体改进。效果还要回到真实后续工作:早期 Lean 有系统级进展,Ad 有晚期反超和保住最佳的实例,Schema 则暴露了起点领先但后续几乎不增长、控制成本偏高的问题。同点 #7269 接续减少了初次复盘往返,但 Grid 的完整用量后来增加。以下保留各组原始数字、窗口和负结果,不将它们合成单一机制的收益。

-
反馈与续跑:早期系统比较 -

研究重点如何变化

- - - - -
阶段问题证据能回答什么
反馈与续跑结果可信、授权工作能持续推进吗?评测缺陷、恢复故障、共同窗口内的系统进展
后续决策积累的证据改善了下一次实验吗?决策到工作的轨迹、成熟研究点之后的变化
上下文效率能否用更低完整成本交付相同义务?实际模型输入、恢复、工具往返和成果/成本比较
-
比较边界

历史研究包含 Official、单次调用、原生 Goal、LoopX Resume 和 LoopX Explore。Explore 在续跑基础上增加可选的证据采集和规划。盲跑仍可使用公开任务、训练数据和本地验证器,但收不到隐藏评测分数和诊断;后台操作者评测不是 solver 反馈。后来的 native-feedback 研究由 Agent 主动申请评测,按已接受提交执行一小时冷却,不做周期评测。这些是不同研究,不能合并成一个处理效应。

模型、effort、提示、runner 和预算共同演化。早期主要用 Sol/xhigh,后来的 Sol/max、Astra/xhigh 批次各自保留条件。每臂一次运行只能提供描述性证据。缺失、主动停止、无效和有效零分分别记录。Checkpoint 接续保留源时间、评测机会和冷却;donor 历史不算新的独立重复。

-

先让反馈与续跑可信

-

最初的 Portfolio 实验先暴露了测量和执行缺陷。一个盲跑 wrapper 在移除评测入口时,也删掉了迭代优化提示;一个账本检查把更早的市场收益归给了收盘时才买入的持仓。它们都混淆了原本的比较。修复后必须另起尝试,旧结果继续保留。

-

一个小反例就能说明记账问题:初始现金 100,000,在收盘价 200 时买入 100 单位并支付 10 手续费,即时权益应为 99,990,NAV 为 0.9999;新持仓没有赚到此前从 100 涨到 200 的收益。之后,对两个冻结样本独立重建,各自 243 天全部吻合,权益残差小于 4×10⁻⁹,股数没有差异。这证明账本一致,不证明投资策略优秀。版本化修复见 EdgeBench #14。

-

续跑也有类似问题:某个工作项结束后,外层进程可以不断唤醒,却没有恢复出有用的下一步。判断必须回到原始目标。Todo 完成之后,可以继续实验、等待或结束,但它本身不能代表 Goal 验收。可靠反馈与恢复让之后的研究变得可解释。

-

早期系统进展可以量化

-
盲跑 Lean 原始分早期 Resume v14后期 Resume(#5844)早期 Explore v14后期 Explore(#5844)
180 分钟0.11030.34780.11340.4019
450 分钟0.18820.52430.19960.5605
-

这些单次运行的共同窗口里,后期原始分约为早期的 2.8–3.5 倍。提示、任务入口、runner 可靠性和 LoopX 机制一起变化。它支持整体系统有进展,不足以归因给某个机制,也不能保证其他题的终态表现。

-
-
-
初始优势、后程改善与成果保留 -

第一次好结果之后,还发生了什么?

-

后来的实验把重点转向十几个小时之后的工作。先比较共同观察窗口,再拆开起点、后续增量和保留的候选。只看终点排名,很容易混淆它们。

- - - -
历史批次观察结果含义
Sol/xhigh,新旧 LoopX,Ad Placement · 14h49,589,589,573 → 49,615,495,839新版 2h 时落后、14h 时领先,终态工作区与保留的 best 一致
Astra/xhigh,Official Grid · 6h → 12h1862 → 1810,越低越好更强的基础模型基线仍在后程产生有效改善
-

Ad Placement 说明后程并非必然平台期:后来的差候选被拒绝,最佳版本保住了。原始分领先约 0.052%,幅度不大;这里的终态工作区核验也只覆盖这一臂。新旧包同时改变 core 和 runner,不能当作某个 LoopX feature 的独立效应。

-

Astra 的结果推进了我们观察到的基础模型能力边界。Official 将速度修改和搜索修改分开,得到连续的原生改善。这项进展属于基础模型/Official 路径,不能算到 LoopX 头上。更强模型也提高了 harness 的要求:面对不断进步的基线,上下文与复盘成本必须换来相应价值。

-

Schema:起点领先不等于持续改善

-

Schema 是这里展开的反例。Sol 新旧版 14 小时窗口,新版 0.804620、旧版 0.723684。但第一次原生结果已经是 0.794620 对 0.713158,且收到反馈的耗时不同。后续增量仅为 0.010000 和 0.010526。较大的终点优势主要来自起点;后续不断改代码,仍未完成原始六项目标。

-

另一组 Astra/xhigh 的 12 小时比较更不利:Official 达到 0.881813,LoopX 为 0.786257,两边 6h 到 12h 的 best 都没有提升。LoopX 记录了 36 次完成的压缩,Official 为四次;未缓存输入约为其 5.32 倍。压缩可能与有效工作重叠,版本、恢复、共享负载和评分条件也有差异。但轨迹仍指出了实际挑战:更多改动和控制活动,没有转化为更多验收价值。

-
这些窗口的条件与限制

Sol 新旧研究采用 planned + Explore、Sol/xhigh、关闭 TurnEnvelope、Agent 主动申请 native feedback、一小时冷却。14h 是读过早期结果后,按最早实际结束时间以下的最大整小时选定,并非完成 18h。另一组 Astra 比较各臂自己的前 12h,包含准备。Sol 窗口对齐了 7,522 个独立 response 和 52 个收到的原生结果,Astra 为 5,277 个 response、45 个结果;累计计数没有反复累加,reasoning 已在 output 中。历史基础设施失败及整次运行完整性未知继续保留。处理包不同、自适应重启,以及此前操作者读到过一个 Official 终态汇总,都限制了因果判断。

-
-
-
同点复盘:实际工作与完整输入 -

证据有没有改变下一步工作?

+
同点接续:完整结果与用量

证据有没有改变下一步工作?

成熟 checkpoint 可以帮助观察一个具体决策边界。接收者继承相同科学状态和 incumbent,再追踪它读了什么证据、选了什么实验、实际做了什么、原生反馈如何。负向本地结果若能在明确条件下排除一条分支,也有价值。继续原方向有依据时,replan 不必强行改道。

近期 #7269 让 Agent 先读目标、事实和反馈,再读写回格式;释放过时的任务选择偏好,并在创建 successor 后保留原 Turn 的结算身份。它对应两个真实往返来源:决策前先读大段写入指令,以及后续任务创建后还要补一轮确认结算归属。

@@ -120,14 +94,22 @@

把结构输入单独计量

同点 Sol/max 接续基线 → 修订口径
Schema 修订622,478(−26.52%)37,570,432(−7.75%)113,162(−0.45%)

这里覆盖截止 10 月 25 日 15:42:31 UTC 的共同 82 分 27 秒外层窗口,包含初始恢复、复盘、普通工作和未结束 Turn 已落盘请求。以四臂停止后保留的原生计数复核,扣除同一源点的历史用量,未发现计数缺口。各臂最后落盘请求最多相差 2 分 22 秒,尚未落盘的用量仍未知。Grid 修订臂的三类用量都更高;Schema 三类都未增加。早先 68 分 26 秒窗口里 Grid 未缓存输入下降 7.25%,延长共同窗口后却转为上升 3.60%,说明不能择取早期窗口来宣布节省。局部复盘减负未证明整段过程净省钱。

-
-
-
-

6. 从零开始的上下文验证

-

当前上下文研究让 Grid、Schema、Ad Placement 从原始任务开始,使用 Sol/max,每题最多 18h。可用的历史 Official 或旧 LoopX 作为描述性参考,保留模型/effort、源码、评分器、机会和时钟差异,不冒称严格配对;旧材料无法回答相应问题时再补 base。各次尝试按实际源码、连续性依据和传输路径分别分析,不合并成同一处理。

+
近期实现细节:放回它们所属的阶段

新路线已确定,原来的工作怎样收尾?

+

一次长程工作可能在复盘时发现:原路线的证据不足,应该登记一个新的验证任务。后继 Todo 已经创建,但这轮复盘的结果还没有写回和结算。如果再次读取准入就改选新 Todo,模型会面对两份身份:刚做完的复盘属于旧 Turn,新的工作却被投影成当前任务。多叫醒一次模型,并不能解决这项归属冲突。

+

#7269 收敛的是控制面的接续语义。创建后继任务证明路线已经落地,不证明原 Turn 已经结算,也不授予新任务执行权。 原有 TypeScript replan transition 和 quota settlement owner 保留创建回执、原义务与原 Turn 的绑定;同轮重读返回原结算步骤。写回后只剩待结算步骤,结算后这轮停止,新任务保持 open,留给下一次正常准入。

+

这里还必须区分 must_attempt 和 delivery_allowed:前者要求处理本轮的工作义务,后者描述普通交付是否获准。需要重规划时,即使普通交付关闭,合法的规划工作仍可继续;不能为了让 Agent“动起来”就打开普通执行许可。租约、预算、停止条件和后继任务的准入继续由原 owner 判断。

+

真实 File / SQLite CLI 回归先创建后继,再原样执行返回的写回和结算命令:提前扣额被拒绝,重复结算只有一次 debit,原 Turn 不被后继替换,下一 Turn 才选择新任务。另有归属改变、延后和撤回 claim 的负例,证明失效的创建回执不能结算原结果。这里验证的是完整状态转换和真实入口,不能由一个字段或一次 ACK 代替。

+

这项修复让模型把注意力留给“接下来验证什么”,减少为结算身份反复解释和重新准入的机会。它没有保证下一项研究一定有效;我们仍要追踪证据、选择、后续实际工作和原生成果。同点接续观察给出了有限正向结果及其反证。

+

一次读取,为什么重复检查同一份运行时?

+

有些开销来自控制面自己。读取一页 Explore 研究上下文,需要多次调用同一个受管理的 TS runtime。Python transport 每次调用都核验运行时源码指纹;在包含大量量化发现的请求里,同一份源码树被反复检查。慢的是这一条真实控制路径,不是模型推理,也不是研究算法。

+

#7013 复用已有 effect_runtime_request_scope,把 explore_turn_context 包在一个逻辑请求内。同请求只解析一次 runtime revision,内部调用使用相同代码版本;离开请求时在 finally 中释放并重置,下一次读取重新解析。复用的是运行时代码身份,不是跨请求缓存 Goal 状态或研究结果。 共享规则仍由 TS owner 执行,Python 只收敛 transport 的重复工作。

+

原 PR 对 600 条合成发现执行真实隔离 CLI:单独预热后取三次未插桩样本,中位数 File 从 4.005 秒降至 0.495 秒,SQLite 从 4.268 秒降至 0.603 秒;环境为 Node 24.21、SQLite 3.53、Python 3.14.8。完整 JSON 与来源日志字节一致。这是具名历史负载上的 Host 延迟,不是当前版本复测或整轮 Agent 的八倍提速。

+

回归还独立检查:下一次请求能读到新 finding;损坏历史继续报错;失败后 scope 已清除,修复来源后的下一次读取可恢复。旧实现会在“一次请求只核验一次”的反例上失败。单纯加一个永久缓存虽然也可能更快,却会失去这些边界。

+

这类优化的直接价值,是更快拿到同一份决策输入,同时保留下一次请求的新鲜性。更少墙钟等待是否换来更多可验证成果,仍需要完整工作轨迹;本例没有测出更少模型输入或费用。

+

8. 上下文差分:10 月 28 日记录的资格仍有缺口

+

截至 10 月 28 日的上下文研究让 Grid、Schema、Ad Placement 从原始任务开始,使用 Sol/max,每题最多 18h。可用的历史 Official 或旧 LoopX 作为描述性参考,保留模型/effort、源码、评分器、机会和时钟差异,不冒称严格配对;旧材料无法回答相应问题时再补 base。各次尝试按实际源码、连续性依据和传输路径分别分析,不合并成同一处理。

先核实实际交付确实改变:首次完整读取、声明连续性依据的后续差分、已知基线失效时的完整回退,以及一次从复盘到工作的完整交互。再比较有效进展、成果保留和完整用量。开关、回执、局部小包都不能替代这些证据。Feature 偏离预期时,停止相关尝试,保留其成本和历史,修复后用新的尝试身份重启。

-

新原生 Hook 路径的首批 Grid、Ad 交互已完成完整分页、一次差分及后续任务工作。同一次捕获内,差分载荷分别比对应完整包小 19.53%、19.48%;这只是一轮读取的载荷比较,不含分页封装、后续模型输入、Hook、恢复或复盘费用,不能外推为总成本下降。完整复盘到后续原生成果、持续收益和故障恢复仍待验证。

效果目标是很多小时之后仍能取得有效进展并保住成果;效率目标是用更低完整成本和人工介入取得同等验收价值。下一份结果需要同时回答它们;当前运行不重置原定截止时间,替换尝试的失败和消耗也保留。

-
-

数值分别保留各历史模型、版本、窗口与有效性边界。公开实现:LoopX。早期详细记录保留在上一版文章。这里不发布原始轨迹、隐藏评测材料、运行时凭证或私有操作上下文。

+

新原生 Hook 路径的首批 Grid、Ad 交互已完成完整分页、一次差分及后续任务工作。同一次捕获内,差分载荷分别比对应完整包小 19.53%、19.48%;这只是一轮读取的载荷比较,不含分页封装、后续模型输入、Hook、恢复或复盘费用,不能外推为总成本下降。完整复盘到后续原生成果、持续收益和故障恢复仍待验证。

效果目标是很多小时之后仍能取得有效进展并保住成果;效率目标是用更低完整成本和人工介入取得同等验收价值。下一份结果需要同时回答它们;这些尝试沿用各自原定截止时间,替换尝试的失败和消耗也保留。

+

数值分别保留各历史模型、版本、窗口与有效性边界。公开实现:LoopX。早期详细记录保留在上一版文章。这里不发布原始轨迹、隐藏评测材料、运行时凭证或私有操作上下文。

diff --git a/apps/presentation/site/public/blog/zh/typescript-control-plane-refactor/index.html b/apps/presentation/site/public/blog/zh/typescript-control-plane-refactor/index.html index c5267facba..b4bb4de776 100644 --- a/apps/presentation/site/public/blog/zh/typescript-control-plane-refactor/index.html +++ b/apps/presentation/site/public/blog/zh/typescript-control-plane-refactor/index.html @@ -3,16 +3,16 @@ LoopX 2.0:两个月的 TypeScript 控制面重构 · LoopX - + - + -
← 全部文章

LoopX 2.0 · Engineering

LoopX 2.0:两个月的 TypeScript 控制面重构

从完整事务、共享权威到强模型参与的语义修复:用真实调用、反例与完整成本解释 LoopX TypeScript 控制面的重构。

+
← 全部文章

LoopX 2.0 · Engineering

LoopX 2.0:两个月的 TypeScript 控制面重构

副作用做完却没记账,旧执行者拿着成功回执回来,修正证据意外重启任务——两个月的重构,逐步把这些问题收敛到完整事务和统一语义。

LoopX 2.0 发布了。借这个节点,我想把 TypeScript 重构的历史和技术细节整理出来。

正式迁移 RFC 在 8 月 15 日合入。到 10 月中旬集中清理普通旧 writer,这项工程已经跨了差不多两个月。它有多条并行线:事务规则迁移、调用方收敛、共享权威、存储与历史成本、Semantics,以及后续兼容与退役。

@@ -324,18 +324,27 @@

检查器也需要能推翻自己的反例

这里误报与漏报的代价不同。保守扩大候选值可能多报一个问题;漏掉真实生产值,会让未登记输出通过检查。没有把握的动态形式应留下 unknown。

检查还要有扫描覆盖下限,不能靠少扫文件过线。后来删除持续膨胀的已提交 inventory,改成按需计算全树清单,也没有取消这个义务。当前支持形式之外仍有缺口,跟踪 issue 继续保留。

这项工作让我很认同一个实践:自动生成和自动检查,可以减少同步错误;它们自己的前提、覆盖和错误方向,也需要被审查。

-

8. 用强模型修复控制面语义

-

迁移之后,我们继续借助强能力模型做设计、实现和评审,沿生产者、规则、调用方与恢复路径核对同一个状态的含义。模型适合帮助追踪跨文件、跨 runtime 的隐含假设;它提出的解释仍要接受真实入口和反例检验。下面两项修复晚于 10 月 16 日,不计入前文两个月的历史统计。

-

参数全对,恢复命令仍可能跑错程序

-

#7145 的错误假设是:Goal、Agent、Turn 参数保持不变,就仍在恢复同一次工作。实际从指定 runtime 进入后,选择失败返回的命令可能重新调用 PATH 上的全局 loopx。参数身份保留了,解释规则的可执行程序却变了;它可能加载另一版本,甚至另一条运行路径。

-

修复复用原 CLI entrypoint builder,把运行时入口与工作身份一起带到恢复命令。回归把一个故意失败的全局 CLI 放在 PATH 前面,随后原样执行返回的 argv。真实 File / SQLite 路径检查原入口保留、拒绝先于业务副作用、原结果只结算一次。只断言命令中存在某几个参数,会漏掉这个缺陷。

-

必须处理本轮,不等于可以执行任何工作

-

#7269 进一步区分推进义务、普通执行许可和原 Turn 收尾。需要重规划时 must_attempt 可以成立,普通 delivery_allowed 仍关闭;创建 successor 是新的路线事实,不能把旧复盘结算到新任务名下。共享 TS replan / settlement owner 保留原绑定,让同轮重读先返回原结算步骤,后继再走新准入。

-

原生 CLI 回归执行实际返回的写回、结算与重放;失效后继负例确认换归属、延后或撤 claim 都不能借旧回执结算。模型少一次身份协商是否带来更有价值的后续工作,要继续追踪真实成果与完整成本;内核效率与效果一文展开了这条链,也保留上下文压缩的负成本。

-

这延续了前文 #3464 的经验:减少调用也要保留副作用之前的 preflight。我们让强模型参与的工作落到错误假设 → 共享语义 owner → 旧版失败的反例 → 真实调用、拒绝与恢复,检验的是被修复的含义。PR 数量、生成的 TypeScript 和测试数量都不能独立证明模型收益;目前也没有逐 PR 的型号对照,不能把这些修复归因为某个模型的独立因果效果。

+

8. 强模型参与的,是这些跨边界的语义问题

+

我们把强能力模型用在设计、实现和评审里,尤其是跨文件、跨 runtime 的假设检查。真正难的部分往往是:几个局部判断都对,组合起来却允许错误的执行顺序。8、9 月的核心 PR 已经反复遇到这类问题;它们不是迁移收尾后的补丁。

+

副作用已经发生,记录还没写下:重试会不会做两遍?

+

假设 provider 已执行成功,进程却在写 checkpoint 前崩溃。只检查 journal,会看到“未完成”;直接重试可能重复执行。相反,把所有不确定都当作成功,又会吞掉尚未发生的工作。这不是一个 try/catch 能解决的问题。

+

8 月 22 日的 #3485 在执行前持久化 prepared attempt 和稳定的 effect identity。恢复先询问 provider:确认已提交,就补记原结果;确认不存在,才按同一身份执行;结果未知,就停在待恢复状态。 对 effect 顺序、receipt 前缀和身份的检查同时保留。这里没有承诺任意外部系统都能 exactly-once:能否确认原结果,仍取决于 provider 的恢复能力。

+

它接续了 #3464 的 preflight:执行前判断“能不能做”,中断后判断“是否已经做过”。两者共同保护一次完整操作。只把 Python 函数逐个翻译成 TS,保不住这两个时间边界。

+

9 月 13 日的 #4286 把七类 Todo 操作的回执恢复收敛到一个 owner,并保留了更细的区别。假设两个 Agent 同时修改任务:A 先提交,B 因版本冲突被明确拒绝;随后 B 查回执时断网。后一次读取失败,不能抹掉前一次明确拒绝。 若断连发生在提交响应返回前,结果才需要保持未知,并沿原 operation identity 恢复。

+

这两条路径最后都可能遇到网络错误,下一步却不同。共享实现只尝试一次写入,随后读取原回执;对应回归分别检查明确拒绝、提交结果未知和准确回执恢复。统一错误处理不能丢掉错误发生的阶段,也不能把已知事实降成未知。

+

领取任务和取得执行权,必须是同一件事

+

两个 Agent 同时看到一个未领取任务。如果 claim 已写入、lease 尚未取得,中间状态究竟归谁?如果旧 Agent 曾成功领取,租约过期后又拿着旧 receipt 回来,它还能继续写吗?

+

从 #3529、#3669 的协调基础,到 9 月 6 日的 #4032,领取、租约和操作回执被纳入同一次条件提交。#3798 的 store 负责原子持久化,领域 owner 判断身份、作用域和合法转换。回执证明过去那次领取成功;当前租约与 epoch 才决定现在能否执行。 操作重放要能找回原结果,却不能复活已失效的执行权。不同存储中的 revision 也不能与领域版本或 lease epoch 混用。

+

这解释了为什么“幂等”不是把旧成功结果返回就结束。正确恢复既要记住历史,也要服从现在的权威状态。早期 foundation、shadow 和生产路径的资格是分阶段建立的,不能把第一个接口合入日写成所有后端都已投入使用。

+

修正一条证据,为什么会重新触发已经结束的工作?

+

规划更新尤其容易出现看似无害的默认值错误。用户只修正一条证据,没有改监控状态;如果更新逻辑用缺省值重建整个对象,已经满足的 monitor 可能被重新启用。与此同时,调用方显式传入空列表或 false,也不能被当作“没有提供”。

+

9 月 10 日的 #4178 将规划更新收敛到同一份权威快照和完整 TS transaction:省略保留原意,显式清空按字段与权限解释,证据修正不重新武装已满足的 monitor。它还删掉了 Python 合成 Markdown 再解析回状态的路径。这既是边界收敛,也是行为修复,不能笼统宣称逐字迁移、行为完全不变。

+

Song 后续的 #4433、#4494 把这种检查延伸到词表的定义、实际生产与消费:一个枚举能编译,不代表所有调用方都在表达同一个含义。前文的 skip / quota_skip 和 action / decision 分离,属于同一条语义主线。

+

怎样约束模型给出的“看起来正确”

+

让模型先指出错误假设,再构造会推翻它的执行序列:提交后断连、旧 lease 重放、只更新证据、显式清空。随后检查真实 owner、provider 和调用入口。

+

强模型帮助把散在各处的条件连起来;反例、真实存储与拒绝路径约束它的答案。目前没有逐 PR 的模型型号对照,不能据此量化某个模型的独立收益。我们能展示的是这些机制怎样改变,以及为什么需要改变。后来的 #7145 运行时路由、#7269 原 Turn 收尾是这条主线的延续,不代替前中期的核心工作。

9. 调用方和默认值,决定迁移能否到用户手上

-

完整事务需要真实 producer 接入。9 月的 #4178 将非终态规划更新收敛到一个权威快照与 TS transaction,删除 Python 合成 Markdown、再解析和事务前 target 读取的绕路。

-

省略、null、空值、false 在这一层都有含义。dry-run 要准确模拟,不能因为选定 provider 不可用就回退别处。随后 #4279 也收敛了读取分类与投影交付语义;部分 Python read owner 被有意保留。一个 owner 是否清楚,比为了语言纯度再造一份解释更重要。

+

完整事务还要求调用方准确表达意图。前述 #4178 中,空白 note 表示不修改;显式空列表和 false 则是按对应字段解释的输入。不能把它们统一过滤为“没传”,也不能一律解释成“清空”。dry-run 要准确模拟,不能因为选定 provider 不可用就回退别处。随后 #4279 也收敛了读取分类与投影交付语义;部分 Python read owner 被有意保留。一个 owner 是否清楚,比为了语言纯度再造一份解释更重要。

新建默认值是另一个例子。当前 priority 回归保护以下区别:

diff --git a/loopx/capabilities/content_ops/README.md b/loopx/capabilities/content_ops/README.md index 977548ccbd..1ad4be6a73 100644 --- a/loopx/capabilities/content_ops/README.md +++ b/loopx/capabilities/content_ops/README.md @@ -41,6 +41,68 @@ Mini-World 既可独立交付,也可成为视频中的素材或镜头;按具 同时审阅完整成片的表达、画面、声音、节奏与全部制作成本;机械检查、创意判断、 观众证据和未验证项分别记录。 +### Source-led selection and whole-film refinement / 全景选材与整片精修 + +For an engineering launch or retrospective, inventory the topic's full relevant +timeline before selecting examples. Include early architectural decisions, +mid-course corrections, outcome evidence and counterexamples. Distinguish a +proposal, a merged implementation and demonstrated adoption. A recent PR, a +large diff or a striking number is not by itself the strongest story. Keep a +compact selection rationale with the draft: the audience question, mistaken +assumption, changed mechanism, decisive evidence and why this example matters. +Update linked articles and companion posts when that selection changes. + +When a canonical film already exists, inspect the complete film and its source +description first. Refine from that source unless the brief calls for a new work; +retain its identity, reusable footage, editable composition and an edit list. +Remove superseded candidates from the active review set without erasing their +source history. Do not quietly substitute an unrelated recent demo. + +Review the full proposed edit, not only its opening or poster: + +- Give each passage a distinct viewer question and observable payoff. Prefer + a concrete action, result or contrast to repeated positioning. Cut duplication + across narration, captions, slide copy and adjacent shots. Information density + means more understood information, not smaller type, faster speech or a fixed + quota of cuts per minute. +- Let the evidence determine framing and duration. Keep units, conditions, + counterexamples and source boundaries legible; preserve a result's limitation + when moving or shortening its shot. Judge screenshots at the actual viewing + size, including a narrow player, rather than only at editing resolution. +- Listen to complete narration and joins, and watch caption entry/exit against + the image. Check names, pronunciation, emphasis, pauses, abrupt audio changes + and music masking. Decoder success, PCM peaks and a supplied transcript cannot + certify this listening judgment. Report it as untested if not performed. +- Keep the baseline and candidate available for comparison. Record what changed + across the whole film, remaining creative weaknesses and production cost. + Distinguish technical readiness, editorial judgment and observed audience + comprehension; do not label an untested candidate the highest-quality result. +- Validate playback in the intended review surface, including seeking across + edit joins, captions and source/candidate switching. A local decoder can accept + a mixed-source export that the browser rejects. Repair the encoding and repeat + that actual playback path before calling the artifact technically ready. + Check which audio tracks the player actually selects: separate narration tracks + may be treated as alternatives rather than mixed together. For one intended + soundtrack, render a mix containing every required layer and check narration + at the opening and inserted shots; a nonzero full-film peak can hide silent + passages. This does not replace listening to the complete result. + +工程宣发先按完整时间线铺开材料,再选能说明核心机制、技术价值和实际结果的 +案例;近期 PR、改动行数和醒目数字不能替代选材理由。选材改变时,同步修订 +文章、配套帖与影片。已有正式素材时先完整检查原片及来源,再保留工程与剪辑 +映射进行精修,退下的候选退出当前审阅目录。 + +整片逐段检查观众问题、画面证据与新增信息,删除跨旁白、字幕和镜头的重复。 +提高信息密度不靠小字、加速语音或强行缩短停顿。条件、单位、反例和来源必须 +仍能读懂。完整听看声音衔接、字幕节奏和实际观看尺寸;未做听审或观众理解 +测试就保留未验证,不以成功导出代替创作质量。在实际审阅播放器中检查完整 +播放、跨剪辑点拖动、字幕和版本切换;本地解码通过不代表浏览器兼容。 +还应核对播放器实际选择的音轨:独立旁白轨可能被当作备选轨,而非同时 +混音。只有一套配音时,导出包含全部所需声音层的混音,并核对开场和新增镜头 +是否有旁白;整片峰值非零不能排除局部静音,也不能替代完整听审。以上 +复用现有作品修订和交付检查,不新增自动接受、发布权限、强制审批轮次或 +独立视频编辑器。 + The capability also ships a provider-neutral item lifecycle for real local operations queues. It preserves stable item identity, revision-bound approval, delivery receipts, exact readback, and supersession without copying draft bodies diff --git a/packages/loopx-media/README.md b/packages/loopx-media/README.md index ab8befece3..91c6d9868e 100644 --- a/packages/loopx-media/README.md +++ b/packages/loopx-media/README.md @@ -165,6 +165,11 @@ producing a subtitle file that silently loses or reinterprets accepted text. ## Bounds and review +For source selection, information density, narration and complete-film judgment, +use the capability's [whole-film refinement workflow](../../loopx/capabilities/content_ops/README.md#source-led-selection-and-whole-film-refinement--全景选材与整片精修). +The technical checks below qualify encoding and source integrity; they do not +replace that creative review or prove audience understanding. + Plans are limited to 90 seconds, 30 shots, 20 local assets and 80 ordered caption cues, with at most 1920×1080 at 30 fps. Each source is at most 64 MiB; all source snapshots together are at most 128 MiB. The render has a 120-second