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 b2621e74e0..756d10b7ed 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,32 +3,73 @@ -Giving long-horizon agents a reason for their next step · LoopX - +Inside the LoopX control-plane kernel · LoopX + - - + +
← LoopX Blog中文
-

Ruiteng Huang · Updated October 26, 2026 · Exploratory research

-

Giving long-horizon agents a reason for their next step

-

From reliable feedback to sustained progress and affordable context

-

The useful question after a long agent run is what improved after the first good result, whether the improvement survived, and what the entire process cost.

-

Our EdgeBench research has moved through three stages: make evaluation and continuation reliable; examine how accumulated evidence changes later work; then reduce the cost of delivering that evidence. Early Lean results and later Ad Placement traces show real progress. The strongest foundation-model baselines have advanced too. These observations support continued development of LoopX, while leaving the contribution and net benefit of individual mechanisms open.

-

Our current judgment is encouraging but bounded. We have examples of useful late work and a more direct recovery/replanning flow. We do not yet have a general causal improvement estimate or a complete fee comparison.

+

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 get better with more time?

-

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.

+ +

1. What should the kernel improve?

+

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.

  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?

+

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.

+

One historical offline comparison in that PR totals every required stage. The table fixes base 59464f974 and tested head a006a2bea1, across four retained observations. It is not a remeasurement of the final merged head.

+ + + + + + +
Complete read pathUTF-8 bytes: base → headChange
CLI entry and all exposed detail352,039 → 361,430+2.67%
CLI plus full recovery784,530 → 793,921+1.20%
Structured Host and required reads621,949 → 247,828−60.15%
Native and required reads647,320 → 242,312−62.57%
Native plus full source recovery647,320 → 673,675+4.07%
+

Normal native presentation falls substantially, but full recovery grows; the measured CLI path including all exposed detail does not shrink either. That counterexample directs further work toward complete reading and recovery, rather than promoting the entry reduction alone. The original PR also separates removing one guard call from measuring the full flow. Bytes saved on that call are not automatically whole-episode savings.

+ +

The full bill includes model input and output, tool responses and retries, context reconstruction, review and settlement, evaluation, shared resources and operator intervention. Cached input is cheaper than uncached input under some billing arrangements, but it is not free. Reasoning tokens are already part of output. Without actual pricing/account reconciliation, a token vector is evidence about usage rather than a fee estimate.

+

Measure structural input separately

+

LoopX input share = the sum of actual input tokens attributable to LoopX packets ÷ the sum of all actual model input tokens. Both sums must cover the same request set and window, with duplicate receipts removed. Consuming the same context in another request is a new actual cost.

+

The denominator includes cached and uncached input. Report cached input and attribution coverage separately; do not average request-level percentages. If only total input is available, packet share remains unknown, rather than zero. Characters and transport bytes cannot be converted into measured tokens. Structural share alone is not net efficiency loss: its contribution to avoiding wasted work and retaining outcomes must be judged alongside complete cost.

+
Earlier byte comparisons and a withdrawn measurement +

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

@@ -36,8 +77,7 @@

Giving long-horizon agents a reason for their next step

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
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.

-
-

2. First make feedback and continuation trustworthy

+

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.

@@ -45,7 +85,9 @@

Giving long-horizon agents a reason for their next step

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.

-

3. Look beyond the first good result

+ +
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.

@@ -58,7 +100,9 @@

Giving long-horizon agents a reason for their next step

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.

-

4. Ask whether evidence changed the next work

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

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.

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
@@ -69,9 +113,6 @@

Giving long-horizon agents a reason for their next step

Both revised receivers completed the staged reads, writeback and original-Turn settlement in their first autonomous review. Baselines eventually completed too; their extra rounds included useful validation and additional evidence, so the entire difference is not redundant work. Grid’s revised choice led to deeper reuse experiments, independent equivalence checks and broader local validation before its six-point advantage over baseline. Schema found a real registry-lifecycle defect but its new native result stayed at the inherited 0.786257; the baseline had no new result at that cutoff.

This is limited positive evidence for the flow, with a small Grid outcome advantage and neutral Schema feedback. It does not establish whole-task acceleration. The study used one pair per case, the same original checkpoint per pair, Sol/max, normal cadence three effective work Turns, and context differencing, TurnEnvelope and stride off. Preparation temporarily used cadence one until the restored semantic review and native Turn completed. It is not a study of repeated steady-state three-Turn reviews.

Earlier retained/fresh-context checkpoint work on Graph and Portfolio asked a different question. Its source age, reconstruction charge and continuation phase stay within the original cumulative 36-hour ceiling. An earlier nominal “with #7197” arm never received the staged reader, so its score cannot establish that treatment’s benefit or harm. A later Astra-to-Sol continuation changes model and effort too. These histories remain useful diagnostics, but are not independent cold runs or interchangeable ablations.

- -

5. Efficiency means the complete episode

-

The full bill includes model input and output, tool responses and retries, context reconstruction, review and settlement, evaluation, shared resources and operator intervention. Cached input is cheaper than uncached input under some billing arrangements, but it is not free. Reasoning tokens are already part of output. Without actual pricing/account reconciliation, a token vector is evidence about usage rather than a fee estimate.

Same-point Sol/max continuationBaseline → revisedBoundary
@@ -79,10 +120,8 @@

Giving long-horizon agents a reason for their next step

#7269 common windowUncached inputCached inputOutput
Grid baseline504,04726,283,904115,147
Grid revised522,198 (+3.60%)35,629,184 (+35.56%)174,366 (+51.43%)
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.

-

Reduce repeated delivery without losing obligations

-

Staged reading and context differencing solve related problems. Staging orders decision evidence before writer instructions. Differencing sends changes against an exact baseline while keeping current controls explicit. Within the same native session and context epoch, the Hook path uses an explicit engineering assumption of continuity after a complete paged read: normally delivered tool content remains usable. It no longer requires full model-input diagnostics during ordinary operation, and a read receipt is not relabeled as independent retention proof. Session changes, observed compaction, incomplete reads and known delivery failures invalidate the baseline; recovery uses the same immutable capture. Missed hooks and unseen downstream truncation can still escape detection and remain validation limits.

-

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.

+
+

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.

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 29de16b650..5ac590ce52 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 @@ -3,17 +3,17 @@ LoopX 2.0: Two Months of TypeScript Control-Plane Engineering · LoopX - + - +
LoopX
中文GitHub ↗
-
← All articles

LoopX 2.0 · Engineering

LoopX 2.0: Two Months of TypeScript Control-Plane Engineering

From an incremental migration proposal to complete transactions, shared authority, semantic checks, and retirement of old paths. How real callers and counterexamples changed the design.

Ruiteng Huang··LoopX creator
-
+
← 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.

Ruiteng Huang··LoopX creator·
+

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.

The final relay by three developers and their agents in #6396 depended on that earlier work. Earlier choices determined what could be deleted and what still had to recover afterward.

@@ -324,7 +324,16 @@

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. Callers and defaults determine whether migration reaches users

+

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.

+

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.

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

@@ -363,7 +372,7 @@

8. Callers and defaults determine whether migration reaches u

The File and SQLite regressions protect these cases. Applying new defaults after original-receipt recovery prevents an upgrade from making new decisions for history.

The closing review found another caller gap. The TS core passed direct tests for metadata-only completion repair. The normal Python producer automatically attached defaults such as completion policy and auto-acquire. The core interpreted them as fresh work mixed into a historical repair. The actual File and SQLite entrypoints failed in both dry-run and execution. The public counterexample records this.

That recovery gap also existed in the baseline, so it cannot all be attributed to the final contributor. The repair had to reach the normal producer while continuing to reject real changes to text, continuation, ownership, or validation. A correctly constructed typed request proves only that the inner boundary can handle it.

-

9. Recover the original result while protecting current authority

+

10. Recover the original result while protecting current authority

Recovery can confuse two points in time: whether the original operation was valid, and whether today's executor may continue changing state.

Suppose a team-plan committed but its response was lost. After an upgrade, the caller retries the same operation ID under stricter admission rules. Rejecting it as fresh work first can hide the original success. A closing recovery review caught that problem.

Separating original-receipt recovery from current execution authority
Separating original-receipt recovery from current execution authority Scroll on narrow screens; open the image for full size.
@@ -371,7 +380,7 @@

9. Recover the original result while protecting current autho

Returning the original result does not renew a lease, overwrite later commits, or revive a retired writer. Lease transfers, epoch changes, and subsequent state have their own protections.

Types express the distinction too. Historical decoding still recognizes legacy; current fresh-execution handoff configuration accepts soft_claim and hard_lease. Reading an old record, recovering an original operation, and authorizing current execution each have independent conditions.

An internal receipt also has a limited scope. If a remote external effect lacks a verifiable idempotent identity and readback, settling once in the control plane cannot establish that the remote effect executed exactly once. Uncertainty belongs at the boundary where it actually occurs.

-

10. CLI output budgets: protect decision semantics before compression

+

11. CLI output budgets: protect decision semantics before compression

CLI language participates in an agent's decisions. This engineering constraint predates the final writer retirement and remained a validation boundary during migration.

The interface budget contract examines:

    @@ -384,7 +393,7 @@

    10. CLI output budgets: protect decision semantics before co

    Natural language requires clause-level review: obligations, ordering, evidence provenance, authority qualifiers, scope, continuation, and stop conditions. Removing a phrase such as “only when the original proof is valid” can change behavior even when every field remains.

    One bounded example removed JSON indentation and separator whitespace. On the same historical fixture of 36 Todos and 12 runs, output fell from 48,418 to 39,726 characters, about 18%, with the complete decoded payload unchanged. This establishes a presentation-size change. Tokens, cost, and agent outcomes need separate measurements.

    The budget protects an interface the consumer can use. Valuable guidance may justify increasing it with matched evidence. Dropping decision conditions to make a size test green damages the interface.

    -

    11. Final retirement: preserve credit and account for the deletions

    +

    12. Final retirement: preserve credit and account for the deletions

    Late-September work had already removed an unused authority prototype and the experimental Todo event overlay, dual-writer, and backfill. Old sources containing data received explicit preservation or refusal handling. This did not remove all event logging or the new authority's atomic events and receipts.

    October work further isolated ordinary Markdown writers and validated real subsequent writes without the old modules. Concentrated deletion became possible after consumer routes and replacement paths were connected.

    Duang777 led #6396. Song and maintainer-side agents continued recovery, producer, and integration work along the original branch, preserving contribution history. This three-developer-and-agent relay was the closing phase of the two-month program.

    @@ -424,7 +433,7 @@

    11. Final retirement: preserve credit and account for the de

Many removed lines were old tests. Deleted test lines do not establish product capability; the important question is whether current entrypoints and independent counterexamples still protect the intended invariants. These counts describe the closing scope. They do not validate the whole migration.

-

12. Community contributions and the next step

+

13. Community contributions and the next step

Multiple contributors advanced this program. Representative work is listed by its concrete boundary so readers can follow the history.

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 6f313af13b..df4782aee8 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,32 +3,73 @@ -让长程 Agent 的下一步有依据：LoopX 语义控制面的阶段性实验 · LoopX - +LoopX 控制面内核：长程工作的效果与效率 · LoopX + - - + +
← LoopX 博客English
-

黄睿腾 · 更新于 2026 年 10 月 26 日 · 探索性研究

-

让长程 Agent 的下一步有据可依

-

从可信反馈，到持续进展，再到上下文成本

-

长时间运行之后，我们关心三个问题：第一次好结果之后还有什么改善，改善有没有保住，整个过程花了多少成本。

-

我们的 EdgeBench 研究经历了三个阶段：先让评测和续跑可信，再看积累的证据能否改变后续工作，最后削减交付这些证据的成本。早期 Lean 和后来的 Ad Placement 轨迹显示了实际进展。更强的基础模型基线也在前进。这些观察支持继续发展 LoopX，但尚不能分离各机制的贡献及净收益。

-

当前判断是有限正向：已有后程有效工作和恢复复盘流程改善的实例，尚无一般性的因果增益估计，也没有完整费用比较。

+

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

+

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

+

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

+

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

+

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

- -

1. 更多时间，应该换来什么？

-

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

+ +

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

+

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

+

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

  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. 上下文变短，完整交付也变便宜了吗？

+

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

+

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

+

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

+

同一 PR 的一组历史离线对照把所有必读阶段重新加总。以下固定比较基线 59464f974 与测试 head a006a2bea1、同四份保留观察的交付；它不是最终合并 head 的重新测量。

+
+ + + + + +
完整读取路径UTF-8 字节：基线 → head变化
CLI：入口与全部暴露详情352,039 → 361,430+2.67%
CLI：再加完整恢复784,530 → 793,921+1.20%
Structured Host 与必读详情621,949 → 247,828−60.15%
Native 与必读详情647,320 → 242,312−62.57%
Native：再加完整来源恢复647,320 → 673,675+4.07%
+

正常 native 展示明显减少，完整恢复却更大；包含全部暴露详情的 CLI 路径也没有净减少。这个反例决定了下一步要优化完整读取和恢复路径，而不能只宣传较小的入口。原 PR还区分了减少一次 guard 调用与完整流程测量：一次调用省下的字节，不能自动当成整轮节省。

+ +

完整账单包括模型输入输出、工具响应与重试、上下文重建、复盘结算、评测、共享资源和操作者介入。缓存输入在部分计费条件下更便宜，但不是免费；reasoning 已在 output 里。没有实际价格与账户对账，token 向量只能描述用量，不能直接当作费用。

+

把结构输入单独计量

+

LoopX 输入占比 = LoopX 相关 packet 的实际输入 tokens 之和 ÷ 全部模型实际输入 tokens 之和。 两者须覆盖同一请求集合和窗口，重复回执去重；另一次请求重新消费同一上下文，则是新的实际成本。

+

分母包含缓存与未缓存输入，缓存部分及归因覆盖单列，不平均逐请求百分比。只有总输入、没有 packet 实际归因时，占比仍未知，不能填零，也不能由字符或传输字节换算成“实测 token”。结构占比本身还不是净效率损失：它是否减少无效工作、帮助保留成果，要与完整成本一起判断。

+
较早的字节对照与撤回的测量 +

历史离线回放说明了为什么必须算总量：结构化 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 的完整用量后来增加。以下保留各组原始数字、窗口和负结果，不将它们合成单一机制的收益。

+
反馈与续跑：早期系统比较

研究重点如何变化

@@ -36,8 +77,7 @@

让长程 Agent 的下一步有据可依

阶段问题证据能回答什么
反馈与续跑结果可信、授权工作能持续推进吗？评测缺陷、恢复故障、共同窗口内的系统进展
上下文效率能否用更低完整成本交付相同义务？实际模型输入、恢复、工具往返和成果／成本比较
比较边界

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

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

-
-

2. 先让反馈与续跑可信

+

先让反馈与续跑可信

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

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

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

@@ -45,7 +85,9 @@

让长程 Agent 的下一步有据可依

盲跑 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 机制一起变化。它支持整体系统有进展，不足以归因给某个机制，也不能保证其他题的终态表现。

-

3. 第一次好结果之后，还发生了什么？

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

第一次好结果之后，还发生了什么？

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

@@ -58,7 +100,9 @@

让长程 Agent 的下一步有据可依

另一组 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 终态汇总，都限制了因果判断。

-

4. 证据有没有改变下一步工作？

+ +
同点复盘：实际工作与完整输入 +

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

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

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

历史批次观察结果含义
Sol/xhigh，新旧 LoopX，Ad Placement · 14h49,589,589,573 → 49,615,495,839新版 2h 时落后、14h 时领先，终态工作区与保留的 best 一致
@@ -69,9 +113,6 @@

让长程 Agent 的下一步有据可依

两道修订臂都在第一次自主复盘完成分段读取、写回和原 Turn 结算。基线最终也完成了；额外轮次还包含有用验证和新增来源，不能把所有差额算作冗余。Grid 修订臂选择更深复用，进行了独立等价检查和更广的本地验证，最后比基线低六分。Schema 找到了真实的注册表生命周期缺陷，但新原生结果仍为继承的 0.786257；截止时基线没有本轮新结果。

这是流程的有限正向证据，伴随 Grid 小幅成果优势、Schema 反馈中性，不等于全任务加速。这组每题一对、各对同一原 checkpoint、Sol/max、普通 cadence 为三个有效工作 Turn，差分、TurnEnvelope 和 stride 关闭。恢复准备阶段暂用 cadence 一，直到语义复盘与原生 Turn 完成。它不是多轮稳定态三 Turn 复盘研究。

更早 Graph、Portfolio 的 retained／fresh-context 接续回答的是另一问题；源点龄、重建费用和接续仍算在原累计 36h 内。早期一个名义上“with #7197”的臂没有实际收到分段 reader，其得分不能判断该处理有益或有害。后来的 Astra 到 Sol 接续又同时换了模型和 effort。这些历史有诊断价值，但不能当成独立冷启动或互换的消融。

- -

5. 效率要算完整过程

-

完整账单包括模型输入输出、工具响应与重试、上下文重建、复盘结算、评测、共享资源和操作者介入。缓存输入在部分计费条件下更便宜，但不是免费；reasoning 已在 output 里。没有实际价格与账户对账，token 向量只能描述用量，不能直接当作费用。

同点 Sol/max 接续基线 → 修订口径
@@ -79,10 +120,8 @@

让长程 Agent 的下一步有据可依

#7269 共同窗口未缓存输入缓存输入输出
Grid 基线504,04726,283,904115,147
Grid 修订522,198（+3.60%）35,629,184（+35.56%）174,366（+51.43%）
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%，说明不能择取早期窗口来宣布节省。局部复盘减负未证明整段过程净省钱。

-

减少重复交付，同时保留义务

-

分段读取与上下文差分处理相关但不同的问题。分段把决策证据放在写入指令之前；差分只传相对精确基线的变化，并保持当前控制条件显式可见。原生 Hook 方案在同一会话、同一上下文周期内，完整分页读取后采用明确的连续性工程假设：这些内容经过正常工具交付后仍可使用。它不再要求常态开启完整模型输入诊断，也不把读取回执冒称为独立的保留证明。会话变化、已观察到的压缩、读取不完整或已知交付失败会使基线失效；恢复取自同一份不可变捕获。遗漏的 Hook、不可见的下游截断仍可能逃过检测，必须保留为验证边界。

-

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

-

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

+
+

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

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

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 b7a9f65d14..c5267facba 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,17 +3,17 @@ LoopX 2.0：两个月的 TypeScript 控制面重构 · LoopX - + - +
LoopX
ENGitHub ↗
-
← 全部文章

LoopX 2.0 · Engineering

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

从最初的渐进迁移方案，到完整事务、共享权威、语义约束和旧路径退役。记录方案怎样被真实调用与反例修正。

Ruiteng Huang··LoopX creator
-
+
← 全部文章

LoopX 2.0 · Engineering

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

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

Ruiteng Huang··LoopX creator·
+

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

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

最后 3 位开发者与各自 Agent 接力的 #6396，是这些工作累积后的一次集中收尾。前面的选择和转折，决定了最后能删什么，以及删掉以后还能恢复什么。

@@ -324,7 +324,16 @@

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

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

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

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

-

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

+

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 的型号对照，不能把这些修复归因为某个模型的独立因果效果。

+

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

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

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

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

@@ -363,7 +372,7 @@

8. 调用方和默认值，决定迁移能否到用户手上<

这些区别由 File/SQLite 回归 保护。把“新建默认值”放在原回执恢复之后，才能避免升级替历史做决定。

最后一轮评审还发现：TS 核心的 metadata-only completion repair 可以通过直接测试，普通 Python producer 却会自动带上 completion policy 和 auto-acquire 等默认参数，被核心视为混入了新工作，导致 File/SQLite、dry-run/执行的实际入口都失败。公开反例 记录了这一点。

这个恢复缺口在基线也存在，不能全部归因给最后的贡献者。修复要走到普通调用方，同时继续拒绝真正的新正文、continuation、所有权或验证修改。直接构造正确 typed request，仅证明内层会处理它。

-

9. 恢复原结果，同时保护当前执行权

+

10. 恢复原结果，同时保护当前执行权

恢复最容易混淆两个时间点：原操作当时合法，现在的执行者是否还能继续改状态。

设想一次 team-plan 已经提交，响应丢了。升级后，调用者拿原 operation ID 重试，新准入规则却变严了。若先按新操作拒绝，就会把原成功结果挡住。最后的 恢复评审 抓到了这个问题。

原回执恢复与当前执行权的分离
原回执恢复与当前执行权的分离 窄屏可横向滚动；点击查看原图。
@@ -371,7 +380,7 @@

9. 恢复原结果，同时保护当前执行权

返回原结果不会续租，不会覆盖后来提交，也不会复活旧 writer。租约转交、epoch 改变和后续状态，都有自己的保护。

类型也表达这种区别：历史解码仍认识 legacy，当前新执行的 handoff 配置只接受 soft_claim 与 hard_lease。旧记录可读、原操作可恢复、当前执行获准，各自有独立条件。

内部回执保护的范围也有限。一次外部远端 effect 若没有可核验的幂等身份与回读，不能只凭控制面只结算一次，就宣称远端恰好执行一次。unknown 应在它实际发生的边界上保留。

-

10. CLI 输出约束：压缩前先保护决策语义

+

11. CLI 输出约束：压缩前先保护决策语义

对 Agent 来说，CLI 的文字会参与决策。这项工程约束早于最后的 writer 退役，在迁移中继续作为验证边界。

接口预算合同 关注：

    @@ -384,7 +393,7 @@

    10. CLI 输出约束：压缩前先保护决策语义

    自然语言还需要逐条看：义务、顺序、证据来源、权限限定、适用范围、继续和停止条件。删除一句“仅在原证明成立时”可能比改一个字段更影响行为。

    一个有界实例是去掉 JSON 缩进与分隔空白。在同一历史 fixture 的 36 个 Todo、12 条 run 上，输出从 48,418 降到 39,726 字符，完整 payload 解码保持一致，字符数减少约 18%。它证明展示体积变化；token、费用和 Agent 效果需要另测。

    预算保护的是消费者能用的接口。新增指导确实有用，可以带同条件证据提高预算；为了变绿而删掉决定所需的条件，反而损坏接口。

    -

    11. 最后退役：保留贡献，核对删除的究竟是什么

    +

    12. 最后退役：保留贡献，核对删除的究竟是什么

    9 月下旬已经删除了未使用的 authority prototype，以及实验性 Todo event overlay、dual-writer 和 backfill；其中有数据的旧来源有显式保留或拒绝处理。这里没有删除所有 event logging，也没有取消新 authority 的原子事件与回执。

    10 月继续隔离普通 Markdown writer，验证模块不在时真实后续写入仍走正确 owner。等 consumer 路由与替代路径接上，才具备集中删除的条件。

    #6396 由 Duang777 主导，Song 和维护侧 Agent 接力补恢复、producer 与集成，沿原分支保留贡献历史。这一轮 3 位开发者与 Agent 的接力，是整个两个月工程的收尾阶段。

    @@ -424,7 +433,7 @@

    11. 最后退役：保留贡献，核对删除的究竟是

大部分删除也包括旧测试。不能把被删测试行当成业务能力；应继续核对原来保护的 invariant 是否由现有入口和独立反例接住。这里的数字用于说明收尾范围，不能替代整个迁移的结果验证。

-

12. 社区贡献与下一步

+

13. 社区贡献与下一步

这项工程有多位贡献者逐步推进。下面按具体边界列出代表工作，便于继续读历史。

diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-1440-case.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-1440-case.png new file mode 100644 index 0000000000..b3f7b5c81d Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-1440-case.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-1440-first.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-1440-first.png new file mode 100644 index 0000000000..0b7c0b3237 Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-1440-first.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-390-case.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-390-case.png new file mode 100644 index 0000000000..611a41b8ec Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-390-case.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-390-context.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-390-context.png new file mode 100644 index 0000000000..182255d252 Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-390-context.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-390-first.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-390-first.png new file mode 100644 index 0000000000..9f5cfc34ea Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-390-first.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-390-table.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-390-table.png new file mode 100644 index 0000000000..bda4a062b6 Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-en-390-table.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-1440-case.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-1440-case.png new file mode 100644 index 0000000000..3ff0f1ca21 Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-1440-case.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-1440-first.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-1440-first.png new file mode 100644 index 0000000000..5c827ffe9c Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-1440-first.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-390-case.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-390-case.png new file mode 100644 index 0000000000..e7b6d07c82 Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-390-case.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-390-first.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-390-first.png new file mode 100644 index 0000000000..8d0fcc54bb Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-390-first.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-390-runtime.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-390-runtime.png new file mode 100644 index 0000000000..6ad07e962a Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-390-runtime.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-390-validation.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-390-validation.png new file mode 100644 index 0000000000..52380efbd3 Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-edge-zh-390-validation.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-en-1440-case.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-en-1440-case.png new file mode 100644 index 0000000000..3f83b1d5ea Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-en-1440-case.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-en-1440-first.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-en-1440-first.png new file mode 100644 index 0000000000..0bcf320d2e Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-en-1440-first.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-en-390-case.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-en-390-case.png new file mode 100644 index 0000000000..d963226e6a Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-en-390-case.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-en-390-first.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-en-390-first.png new file mode 100644 index 0000000000..81dfd688ce Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-en-390-first.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-zh-1440-case.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-zh-1440-case.png new file mode 100644 index 0000000000..c3d96d5fe4 Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-zh-1440-case.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-zh-1440-first.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-zh-1440-first.png new file mode 100644 index 0000000000..7744bdd324 Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-zh-1440-first.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-zh-390-case.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-zh-390-case.png new file mode 100644 index 0000000000..91171a8b00 Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-zh-390-case.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-zh-390-first.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-zh-390-first.png new file mode 100644 index 0000000000..5915c9bfe9 Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/after-ts-zh-390-first.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/before-edge-zh-1440-first.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/before-edge-zh-1440-first.png new file mode 100644 index 0000000000..06ba6707a7 Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/before-edge-zh-1440-first.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/before-edge-zh-390-first.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/before-edge-zh-390-first.png new file mode 100644 index 0000000000..c1ebfdfd66 Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/before-edge-zh-390-first.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/before-ts-zh-1440-first.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/before-ts-zh-1440-first.png new file mode 100644 index 0000000000..f29753b0a2 Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/before-ts-zh-1440-first.png differ diff --git a/docs/assets/personal-workspace/release2-blog-stories/kernel/before-ts-zh-390-first.png b/docs/assets/personal-workspace/release2-blog-stories/kernel/before-ts-zh-390-first.png new file mode 100644 index 0000000000..4c731cd5d2 Binary files /dev/null and b/docs/assets/personal-workspace/release2-blog-stories/kernel/before-ts-zh-390-first.png differ