从一次性 Agent 到长程控制面

1. 最大化 Agent 产出，最小化人的注意力投入

我做 LoopX 的动机很朴素：让 Agent 多干一些活，尤其是那些总把人拉回键盘前的工作。项目逐渐变长后，瓶颈发生了变化。模型可以解决眼前的问题，但仍然需要人记住目标、分配工作、检查证据、处理权限，再告诉它什么时候继续。

LoopX 同时优化两个目标：Agent 的有效产出，以及获得这些产出所需的人类注意力。产出取决于模型能力、有效并行度、时间利用率和目标对齐程度。LoopX 主要改善后三项，具体工作仍由底层 Harness 和模型执行。

技术目标是：无干预跑稳，有干预跑好。不需要人判断时持续推进，缺少新事实时安静等待，路线失效时重新规划，控制状态矛盾时自我修复，验收满足后停止。人的反馈应当改善后续方向，并成为下一轮可以继承的状态。

这也是吞吐问题。快速回复有价值；多项独立工作能在人离开后继续推进，同样有价值。需要观察的是，每单位算力和人类注意力换来了多少经过验证的产出。

交付一条长上下文推理加速路径

设想把这样一个目标交给 Agent 团队：为开源推理引擎交付长上下文注意力加速后端。工作横跨内核与 Serving 两个仓库，需要建立可复现基线、比较优化假设、提交远程 GPU 实验、检查数值误差、验证并发流量下的集成表现，最后交付带回滚路径的候选版本。下面用这个构造场景解释控制契约，实验工具由选定的 Host 与 Provider 提供。

内核方向的 Peer 研究数据搬运，Serving 方向的 Peer 构建接近真实负载的回放，验证方向的 Peer 检查数值容差与边界条件。Owner 授权开发和有界实验预算，保留发布决策。部分工作可以并行，部分必须等待稀缺 GPU 时隙、兼容的内核修订，或一份足以推翻当前假设的实验结果。

几天后，“Benchmark 绿了”提供的信息远远不够：测的是哪个模型、硬件、输入长度、并发量和修订？吞吐提升是否牺牲了尾延迟？收益是否来自工作负载被悄悄改了？提交 Session 断连前，远程实验究竟有没有启动？下一位 Worker 需要恢复这些区别。

2. 语义控制面要保存什么

模型的工作上下文有限。压缩和 Subagent 可以缓解上下文压力，但一段总结无法可靠地执行所有权、并发、权限和幂等规则。跨 Session 的项目需要持续回答：

• 当前目标是什么，怎样才算验收通过？
• 哪些事实和人类决策仍然有效？
• 每项工作由谁负责，哪些动作已获得授权？
• 某个外部操作究竟有没有发生？
• 下一轮是否值得继续消耗资源，结束后又该做什么？

这些问题定义了 Semantic Control Plane。把 Agent Stack 按恢复对象分成四层，可以看清它的位置。

Runtime 恢复运行环境；LoopX 保存 Agent 正在做什么、为什么做、已经证明了什么，以及下一步是否合法。Codex Thread、Claude Code Session 和 CLI Runner 都可以成为这块共同事实面周围可替换的 Worker。

四个概念有助于精确描述进展：

Turn       = 一次有界执行窗口
Result     = 一轮返回的产物或观察
Transition = 经过验证并获准写入的状态变化
Progress   = 与验收相关的持久状态迁移

一段有说服力的回答属于 Result。相关验证和状态迁移被接受后，它才能成为项目进展。具体定义见架构与术语。

与工作流引擎、Memory 的关系

已有系统解决了持久化的重要部分。LangGraph 的 Checkpoint保存图状态，支持恢复、人类介入与时间回溯；Temporal Activity隔离外部工作，安全重试仍需应用自身的幂等设计。LoopX 增加项目层的判断：什么证据满足验收，哪个 Actor 有权提交变化，当前路线是否还值得继续。

Memory 帮助找回有用的事实，Authority 决定该事实此刻能否支持行动。记住 Owner 曾批准一次发布，有助于理解上下文；把它当成以后每次发布的授权，就会出错。同样，忠实恢复一条已经过时的计划，可能在运行层面非常可靠，却耗尽剩余预算。恢复时需要保留目标，并重新判断路线。

3. 外置状态，可重建的展示面

LoopX 将 Canonical State 与 Projection 分离。Registry 保存目标身份、项目连接、策略和权威来源；追加式 Ledger 记录带身份的事件；Run History 与 Evidence 把执行连接到产物、验证、失败和资源消耗；Active-state Workbench 提供人可读的兼容表面。

Status、任务图、评审包和 Dashboard 都是这些事实的投影。它们可以重建，界面上的状态本身不会独立授予迁移权限。事件溯源状态契约定义了 Replay 与 Identity：同一事件的重放保持幂等，相同身份但内容冲突的事件必须拒绝。

一个 Open Todo 就足以说明复杂性。它可能在等审批、等 PR 合并、等 Monitor 发现变化，也可能被另一 Agent Claim，缺少 Host Capability，处于错误工作区，或被后来的路线替代。仅凭 Open 无法决定是否执行。

Open work
  → 依赖与恢复条件
  → 有范围的授权
  → Claim 与生命周期所有权
  → Host 能力与工作区
  → 事实新鲜度与证据
  → Quota 与当前可执行 Frontier

人的决策也进入同一套持久模型。“等我 Review”“这条路线可以继续”都有具体范围。Decision Scope 契约将权限绑定到 Action、Lane、Goal 或 Project。一条路径等待时，不依赖该决策且已经获得授权的工作仍可继续。

完成同样需要明确边界。关闭 Todo 只是一个局部工作的证据，不会自动满足整个 Goal。如果可执行 Frontier 已经耗尽，Acceptance 仍然开放，系统需要新的路线，或者有证据支持的 No-follow-up 结论。

回到推理加速，“发布前等我确认”的范围是 Release，不会抹去分析 Profile 或验证兼容性的授权。一个有用的投影可以同时展示：内核候选通过局部检查、服务级延迟目标尚未证实、发布等待决策。一个“Blocked”会藏起可推进的分析，一个“Done”又会藏起尚未关闭的验收缺口。

4. 帮助 Agent 决定下一步的 CLI

可以把 LoopX 直观理解为一张可执行 Kanban。卡片有稳定身份、依赖、Claim、Scope、Evidence 和 Successor。移动卡片意味着申请一次可验证的状态迁移，看板展示的是这份契约。

CLI 将工作连续性写进交互。完成任务时，可以创建后继、链接已有后继，或在验收满足后记录结构化 No-follow-up 理由。这样，一次局部成功不会让更大的任务链断线。具体规则见 Todo Contract。

Interaction Contract 分开表达“人需要听到什么”和“Agent 必须做什么”。通知通道可以安静，同时要求 Agent 执行一段有界工作。反过来，状态要求等待时，调度器唤醒也可以合法地不产生工作。

这同时保护 Human 和 Agent 的注意力。Human-facing View 突出值得判断的新问题；Agent-facing View 给出当前权限、下一步、验证和停止条件。双方都不应靠读完全部历史对话来重建当前事实。

Host Scheduler 提供唤醒，LoopX CLI 与轻量 Skill 提供受治理的工作契约。调度 Prompt 应维护这条生命周期，并从状态读取当前决策，避免在自然语言里累积第二份项目计划。

一次交接里应该包含一个判断

内核实验的有效写回应当标明候选修订、对照条件、已测量边界、剩余缺口和后继。下面是解释用记录，不是 CLI Payload，也不是真实运行日志：

完成切片：评估注意力内核候选 A
证据：固定的候选、基线、工作负载与结果清单
已经证明：数值检查通过；孤立内核测试更快
剩余缺口：尚未证明并发流量下的服务 p95
后继：用固定负载回放两个 Serving 构建
权限：允许有界实验；发布仍受 Gate 约束

相比“注意力优化完成，Benchmark 通过”，这份记录防止局部 Microbenchmark 的收益变成未经证实的服务级结论。结果清单应能识别代码、环境、负载和测量方法，让后续 Peer 可以复现，也可以提出质疑。

实际的 todo complete 支持用 --next-agent-todo 指定后继，或在适用时用 --no-follow-up 记录理由。这些是生命周期操作：受 Quota 约束的仓库推进，需要先满足对应的 Writeback 与 Spend Receipt。脱离当前 Interaction Contract 复制完成命令，可能破坏顺序。应由 Host 读取当前契约，再执行它给出的动作。

5. Effect Program：恢复实际发生过的事

这一节的函数式编程视角，可结合齐梦星空的 Agent Loop、Kleisli Arrow 与函数组合系列阅读。

普通函数可以写成 A → B；Agent 操作更接近 A → F[B]，其中包含权限、持久化、时间、预算、外部调用和失败。模型提出动作，与真实世界发生变化，是两个不同事实。

Goal 状态 → Effect 请求 → 权限 / Quota 解释
  → 外部操作 → Observation / Readback → Receipt
  → 持久状态迁移 → 下一版 Goal 状态

Effect Program 为这些步骤建立 Identity、顺序、Receipt 和失败语义。缺少这些机制，外部操作成功后的崩溃可能导致重复重试；迟到的 ACK 可能结算错误的 Turn；不同模块也可能逐渐形成互不兼容的 Writeback、Spend 和 Closeout 顺序。

公开的 EffectTurn 实现用四个可序列化 Slot 描述一次交互：

interface EffectTurn<Context, Decision extends string> {
  request: EffectRequest<Context>;
  interpretation: EffectInterpretation;
  observation: EffectObservation<Decision>;
  next_effect: EffectNext;
}

Settlement 的下一步是三个互斥分支：failed、execute 或 complete。已选中 Turn 的结算顺序固定为：

Settlement Identity 绑定 Goal、Agent、Turn Instance，以及选中的 Todo 或 Replan Obligation。Matching Receipt 标识已提交步骤。恢复时核对身份，从未提交的后缀继续。Effect Program 测试覆盖顺序、重放、失败和已提交前缀。

远程 GPU 实验刚提交，连接就断了

一次已授权的实验提交到达远程调度器，但 Agent 还没记录响应，连接就断开了。盲目重试可能启动重复 Job，花掉两份预算。恢复时，先用 Provider 的请求身份或 Job ID 回读提交是否被接受；如果 Provider 无法确定结果，这条分支就保留为待核对状态。

确认提交，只能证明 Job 已被接受，不能证明它已完成，更不能证明候选满足验收。提交 Turn 可以结算自己的有界结果，并建立 Monitor；后续验证 Turn 再检查结果清单。两轮各自需要身份和 Receipt。

这是受治理结算的恢复契约。控制面内的 Exactly-once 记账，不意味着任意外部 API 都能 Exactly-once；外部操作仍需 Provider 级幂等或回读。Effect Program 也保留领域所有权：结算代数不会用一个通用 Executor 替代 Goal 规划。

这里有两份账需要核对：外部实验预算，以及控制面的 Turn 记账。LoopX Spend Receipt 不会取消重复 GPU Job，也不能证明远程计费正确。Provider 负责确定外部结果，Kernel 负责结算对应 Turn。把职责分开，昂贵的不确定状态才有办法诊断。

6. 何时执行、等待与重新规划

Quota 编译本轮决策

quota should-run 在算力预算之前，先处理健康与安全、Operator Gate、Evidence Wait 和 Focus Wait，再结合当前工作、Capability、Workspace 与 Scheduler 状态生成 Interaction Contract。结果可能允许有界工作、指出决策 Gate、保持等待、限制交付或要求修复。详见 Quota Allocation。

经过验证的持久写回先于 Quota Spend。Quiet Skip、Preflight Failure 和 Dry-run 不计为 Delivery Spend。即使 Refresh 已经选出下一项动作，Spend Record 仍应归因到刚完成的工作。

围绕当前任务的有界 Planning Horizon

Typed Planning Inventory 支撑多个视图。Action Portfolio 给出少量当前候选；Planning Horizon 展示附近的 Successor、依赖、Resume 关系和 Acceptance Gap；按需 Todo Detail 展开冷路径；Task Graph 提供诊断视图。

可见性不授予执行权。被另一 Agent Claim 的相关任务是协调上下文；可运行但未领取的任务，仍需 Claim 和常规检查。Planning Horizon 协议将读模型与 Selection Authority 分开。

对开放式研究，Explore Capability补充问题、假设、实验和 Finding 的证据图。规划层可以组织分支，执行仍走正常 LoopX 生命周期。失败路线和组合探索的理由由此保留下来，不必把所有细节塞进下一轮 Prompt。

等待一个新事实

Monitor Resume 需要等待开始之后发生的 Material Change。Generation Fence 比较当前 Monitor Generation 与保存的 Baseline；历史结果、无变化轮询和重复 Replay 都不能算新信号。实现见 Resume Condition。

主路径等待时，独立 Fallback 可以继续推进。没有新事实的轮询应退避；反复无进展时，需要具体 Blocker、Expiry、Successor 或 Replan 决策。

Replan 有身份，也必须有结果

当前路线无法继续支撑验收时，Replan 会成为机器执行的义务。obligation_id 标识这一代问题，旧义务的迟到 ACK 无法关闭新义务。

触发原因包括重复语义停滞、Todo 连续性中断、验收缺口、任务链过长、周期复盘和 Frontier 耗尽。合法等待与普通 Scheduler Wake 有自己的语义，不会自动意味着必须 Replan。

结算需要绑定当前 Exact Obligation，并产生已接受的语义变化，例如可运行 Successor、具体 Blocker、有新证据支持的路线，或有依据的 No-follow-up。只改计划文字、只发 ACK 无法满足它。Goal / Vision / Replan 契约定义了这条边界。

一次有效 Replan 改变什么

假设新内核提升了孤立测试的吞吐，但连续两次 Serving 实验仍未达到 p95 目标。再做一轮内核调优，可能已经不是正确的下一步。有效 Replan 应记录“局部加速尚未转化为端到端价值”，提出调度或显存争用的竞争假设，建立只改变一个因素的对照实验，再让集成路线依赖结果。这里描述的是构造情境，不是真实运行的测量结果。

控制面可以要求有意义的迁移、拒绝过期 ACK。新假设的质量仍取决于模型、工具、证据和人的判断。Typed Obligation 让失败变得可见、可恢复，洞察本身仍需要做出来。

7. 为判断设计交互面

Agent 进入代码、文档、研究和沟通场景后，Operator 需要简洁的决策视图：哪个项目需要判断？哪条高优路线被阻塞？什么可以独立推进？Monitor 是否发现重要变化？最近的活动是否形成了有效进展？

产品闭环是 Signal Inbox → Anchor Selection → Performance Review。外部信号进入有界 Inbox；Human 与 Agent 选择少数高价值锚点；再按 Value、Quality、Control、Cost、Learning 复盘结果，让反馈进入下一轮。

汇报也是注意力边界。重要交付、阶段闭环、路线决策或主要阻塞值得更新；普通刷新和无变化 Monitor 不应反复打断人。相关事件可以合并、去重。Periodic Report 能力与智能展示面 RFC分别描述已有机制和更完整的产品方向。

人的价值落在方向与质量标准上

长程 Agent 改变了我投入时间的位置。早期花很多精力管理卡片、重启 Session；连续性改善后，更值得做的是检查产物、收紧目标，并说明一个看似合格的结果为什么还不够好。“这张图没有解释失败边界”，比又一次泛泛地要求继续更有价值。

对推理项目，关键干预可能是：“用户在意混合流量下的交互延迟，离线吞吐分数提高还不够。”这个判断会改变工作负载、验收和下一项实验，应当跨越当前对话。如果每开一个 Session 都要再贴一遍，说明系统还在丢失项目的重要部分。

我希望 Operator Surface 降低这类反馈的成本：同时看到产物、证据、尚未决定的选择，以及再投入一轮的预期价值。更多并行 Agent 能创造价值，前提是 Review 与协调负担不以同样速度增长。人的注意力也是运行预算的一部分。

8. 数字团队需要显式权限

并行 Worker 需要共同目标、独立的工作边界和可靠交接。LoopX 使用 Equal Peer 模型：Agent Identity 表示工作角色，不构成永久层级。临时 Coordinator 可以路由工作，但不会自动获得完成或重新分配其他 Peer 任务的权限。

跨 Host 后，这些区别更重要。Shared Goal Authority 将语义迁移规则与存储分开：Authority 层拥有 Revision、Lease Epoch、Receipt 和冲突判断；Storage Provider 提供 Load、Compare-and-put 与 Durability。Storage Generation、Authority Revision 与 Lease Epoch 描述不同事实，需要分别标识。

Shared Goal Authority RFC 与 Authority Store 实现记录了这项工作。跨 Host 产品化仍在持续验证；接口存在，不代表任意分布式数字团队已经成为开箱即用的产品。

好的 Handoff 是工作边界之间的接口。跨仓库变更中，它可以是一份 API 契约和固定修订，再由消费方完成兼容性验证。把整段对话转给另一 Agent，让它猜哪些决定仍然有效，交接成本会很高。应优先在验收边界可分离的地方并行；紧密耦合的修改，交给同一位 Worker 可能更省。

9. 围绕稳定内核演进垂域能力

LoopX 将 Goal、Todo、Gate、Quota、Evidence、Recovery 和调度语义留在 Kernel。垂域行为沿三个独立边界演进：

• Capability：对调用者承诺的结果，包括领域策略与验证。
• Provider：有界的本地或外部实现，返回 Observation 与 Readback。
• Extension：可选交付与生命周期，包括安装、检查、启用、升级和回滚。

Agent → Capability → Provider → 外部或本地系统
Readback → Capability 验证 → Kernel 状态迁移

安装 Extension 本身不授予 Goal Authority 或外部写权限；Provider 不决定 Kernel 是否接受迁移。这让可选集成与 Provider-neutral Core 共存。详见 Extensions and Capabilities。

Hook 在特定阶段插入有界行为。Turn-start Hook 可以获取范围内的 Observation；Interaction-projection Hook 提供只读视图；Post-writeback Hook 可以在主状态提交后记录不含副作用的 Intent。Intent 仍需经过独立且获授权的生命周期，才能触发外部交付。

Code Evolving 从真实工作的证据开始：固化最小实现切面，明确观察与失败边界，需要时独立交付，调用者结果稳定后再沉淀 Capability。只有跨领域反复出现的不变量才进入 Kernel。这样既能吸收实验，也能避免复制权限模型。

在推理场景中，垂域 Capability 可以拥有实验对照契约与结果验证，GPU 调度 Provider 负责授权范围内的 Job 提交、状态回读与取消。替换集群 Provider，不应改变什么算有效对照。这是职责放置示例，不代表 LoopX 已内置某个 GPU 集成。只负责传递结果的集成，可能只需要 Provider 与生命周期，无须增加新 Capability。

10. 证据能回答什么

一个运行很久的项目，与一次更好的 Benchmark 结果，证明的是不同事情。Showcase 可以展示 Turn、等待、Review 和恢复之间的连续性，经过的项目时间不等于连续推理时间。Benchmark 回答某个系统在指定条件下完成了什么。

更广泛的研究也说明设置值得认真对待。OpenAI 报告，UK AISI 的 Cyber Range 评测把 Token 预算从 10M 提高到 100M 后，性能提升最高达 59%。这是该评测设置下的结果，不是 LoopX 的结果，也不意味着运行越久一定越好；它支持把 Harness 与预算一起测量。参见 OpenAI 的评测方法讨论。

SWE-Marathon：收益、成本与失败的接入模式

LoopX 公开研究由 BouwenZhou 贡献，在 SWE-Marathon v1.1 的 15 个匹配任务上比较五种模式，共 75 次 Trial，每个任务、每种模式各一次。模型为 GPT-5.6 Sol，Reasoning Effort 为 high；Codex 0.151.0、LoopX 0.5.3、Harbor 0.20.0，Timeout Multiplier 为 0.3。这是历史实验版本，与本文其他部分引用的实现修订分开理解。

Heartbeat 相比原生 Goal 多完成一个任务，平均连续分提高 0.011，总成本增加约 56%。codex-cli 模式更差，并出现一次构建失败；该失败保留在共同分母中。研究提出，有人值守的 Host 模式与无人续跑之间的错配，可能解释部分表现，但这是待验证假设，没有被实验单独隔离。设置与局限 · 固定版本的聚合数据。

这是多项机制同时变化的探索性比较。每格没有重复 Trial，无法据此估计波动；相对裸 Codex 的较大部分提升，在原生 Goal 基线中已经出现。表格支持继续研究续跑方式和接入质量，尚不足以证明 LoopX 的普遍增益，或每项内核机制的效率。

一个继续验证有价值的案例

Wanli-Lee 贡献的 Case Insight 投影进一步给出了具体例子。zstd-decoder 任务中，裸 Codex 在 52 步、六个可见 Fixture 后停止，最终评测通过 37 个隐藏检查中的 25 个。SSH LoopX 模式用了 135 步，通过 37/37；Heartbeat 模式用了 453 步，构建 156 项验收检查，也通过 37/37。数字来自公开聚合 Case 分析，描述的是这些运行中的观察。

值得检验的假设是：额外 Turn 在产生新证据和修复时有价值。持续重读相同计划，也能消耗更多预算，却未必改善结果。工程目标是让停止条件对验收缺口、失败假设与边际收益下降敏感。

后续实验需要重复匹配 Trial，报告波动与每次成功的成本，并分别改变续跑策略、证据保留和恢复机制。中断 Effect、Peer 交接也需要专项验证。研究计划描述了更大的评测空间。一个有希望的案例，值得用更严谨的实验继续追问。

11. 从一个真实项目开始

从开发者手册与 Quick Start进入。通过现有 Agent 连接一个项目，检查目标与下一步安全动作，再交给它一个验收条件可见的有界任务。并行 Peer 和可选集成，可以随工作需要逐渐加入。

安装完成后，用以下命令检查环境与已连接项目：

loopx doctor
loopx status

让第一个闭环小到可以判断

1. 选择可观察的结果。推理项目先固定工作负载、质量边界、延迟目标与基线，再交给 Agent。
2. 说明权限边界。分别约定开发、实验花费和发布权限，同时为独立工作提供足够范围。
3. 检查一个完整周期。看 Selection、执行、验证、Writeback 和 Successor；确认新 Session 能恢复当前事实。
4. 试一次等待与纠偏。等待远程结果时允许独立分析，并纠正一个不充分的性能结论；检查下一轮是否同时继承等待条件和反馈。
5. 沿证据支持的方向扩展。为可分离工作加入 Peer，观察协调成本、重复失败和注意力消耗。

短小、明确、能在一个 Session 内舒服完成的任务，现有 Agent 可能已经足够好。当连续性、有范围的决策、证据和协作本身变成反复要做的工作时，LoopX 才更有价值。它增加的开销，应当在真实项目里赚回来。

我的长期愿望，是一支能跨项目、跨 Host 持续工作的数字团队，同时让指挥它的人看得懂、改得动。这是要继续建设和验证的方向，不代表所有环节都已完成。开源也改变了项目本身：其他开发者会带来不同任务、失败方式和质量标准。更好的 LoopX，应当从这些具体需求里长出来。

参考与延伸阅读

原文

• 飞书原文：从一次性 Agent 到长程控制面——LoopX 的目标、状态内核与 Effect Program。中文原始长文，与本博客改编版分别维护。

LoopX 实现与实验证据

• LoopX 架构：目标、状态与执行边界的整体设计。实际使用可从开发者手册开始。
• Effect Program 实现与对应测试：核对结算顺序、Receipt、重放与中断恢复。
• SWE-Marathon 双语研究简报与固定版本的聚合数据：阅读五种模式的实验设置、结果、成本和局限。

Agent Loop 与函数式编程

齐梦星空的小红书系列（2026 年 5 月），从带 Effect 的计算出发讨论工具调用与组合：

• 主线一:Agent Loop是effectful program(1)
  2026-05-11
• 主线一:Tool Calling是Kleisli arrow (2)
  2026-05-12
• 主线一: Agent Loop里的小魔法:函数组合(3)
  2026-05-14

相关公开材料

• OpenAI：A shared playbook for trustworthy third party evaluations：理解 Harness、预算与评测结论之间的关系。
• LangGraph：Persistence：Checkpoint、恢复与人类介入的持久化基础。
• Temporal：Activities：外部动作、重试与应用级幂等的职责边界。