用 Agent 开发软件，我越来越在意一件事：从想法、实现到真实反馈，能否形成一个足够短、又能持续运转的闭环。代码生成变快以后，目标、验证、交接和人的注意力，开始决定我们到底能交付多少东西。
我在开发 LoopX 时，逐渐把这个问题理解为：给一个可恢复的执行系统，加上目标、证据、权限与路线演化的语义。本文是面向软件开发者的短分享；完整机制见核心架构长文。
把从想法到验证的链路缩短
在效果与体验导向的产品里，同一个人能带着 Agent 贯穿设计、实现、试用和调整，有两个很直接的优势：反馈不用穿过多次交接，产品与技术的取舍也能在共享上下文里一起调整。发现一个交互不好用，可以连着改界面、协议和测试，再立即体验。
这让我更重视高质量的 human reward：人指出什么值得做、哪里仍然不够好，Agent 把判断落实成下一轮可验证的工作。这里的 reward 可以是具体纠正、验收条件或优先级变化，不必是一个数值，也不意味着在训练模型权重。
这种开发方式也有代价。上下文高度集中，会让独立审查更重要；代码产出上去了，评测资源和人的审阅能力却未必同比增长。多人协作提供的专业分工与独立判断仍然有价值。工程问题是：怎样保留短反馈链，同时让验证、维护和交付承受得住持续迭代。
一个公开案例：把性能优化做到上游
Zheng Cai（@zigzagcai）的公开分享给了一个具体例子：他使用 LoopX 作为工作流引擎，组织 Agent 做 vLLM 性能优化，产物已经合入 vLLM PR #54951。
优化针对 sparse indexer 的 prefill。原来每个 tensor-parallel rank 都重复做 query rows 的 MQA scoring 与 top-k；改法按计算成本，把独立的 query rows 划成连续分片，各 rank 对完整可用 key history 计算自己的部分，再用 all_gatherv 恢复原顺序的 top-k 索引。减少的是重复计算，attention 没有因此变成近似计算。
PR 报告：GLM-5.3-Flash、4×H200、TP4、1M 输入 tokens、C1 顺序请求下，TTFT 从 54.154 秒降到 40.388 秒，降低 25.42%；输入与输出合计 token 吞吐从 17,856.28 提高到 23,675.18 tok/s，提高 32.59%。
这组结果使用 65,536-token batch budget、legacy runner 与显式 FA3 backend，来自四对独立进程重启的 A/B 对照。C1 合计吞吐不等于饱和多并发 serving 吞吐；我没有独立复现，也不能据此分离 LoopX 本身的因果增益。它展示了一条可检查的工程交付：优化机制、测量条件、验证范围和上游接受，都有公开产物。
先证明“测到的就是这项改动”
这个 PR 还有一个很值得保留的细节：新路径要求当前 batch 中的 prefill query rows 至少达到 16,384 × TP。TP4 下，8,192-token batch budget 即使配上 1M 总上下文，也无法激活它。上下文很长，不意味着这次优化实际参与了计算。
作者因此用固定的新旧代码修订和相同的 65,536-token batch budget 重做对照，并明确撤回旧表格对当前改动的归因。对 Agent 研发，这给出一个更严格的验收抓手：产物、激活路径、测量配置和结论必须对得上。一个漂亮的数字，不能代替这条证据链。
对长程开发，这比“Agent 运行了多久”更有意义。发现瓶颈、比较假设、修改实现、复验和响应评审，需要连成同一份工作；失败条件和测量口径也要能被下一轮接住。
给分布式执行加上语义属性
任务队列、租约、事件日志、版本检查和重试，能让执行可追踪、可恢复。它们通常不负责判断：恢复后的路线还值不值得走，测试结果是否适用于当前版本，局部任务结束是否意味着目标达成。Agent 工作使这些问题进入了执行回路。
| 已有执行机制 | 需要明确的语义属性 |
|---|---|
| 持久化与恢复 | 目标、验收与负证据跨会话延续；恢复过时计划时能重新判断。 |
| 认领、租约与并发控制 | 工作归属、执行占用、修改方向和发布权限分别检查。 |
| 结果记录与版本管理 | 证据绑定产物、负载与修订；“执行成功”只支持它实际证明的结论。 |
| 重试、等待与调度 | 区分没有新事实、可继续的独立工作、路线失效和需要人判断。 |
用一个构造的性能研发场景看这种变化：候选 rA 的孤立微基准已经通过，混合负载的 p95 尚未测量。此时人补充：“真正关心混合流量下的延迟，不要用正确性换速度。”这次反馈需要变成验收修订、证据适用范围和下一项工作，而不只是下一轮 prompt 的开头。
模型提出验收 v2 与固定负载的服务级对照，由对应权威接受；内核检查范围、身份和版本后，持久化这次变化。rA 的旧结果仍然有效，但只证明孤立微基准；它不能证明 v2 已满足。发布继续等待，独立的正确性分析与回滚检查仍可推进。下图解释的是控制契约，不是真实 vLLM PR 的运行轨迹。
LoopX 的 Semantic Control Plane 把目标、工作项、约束和已接受的状态迁移外置。模型读取当前事实，提出下一步；执行前检查范围、权限与预算，工具返回真实观察；领域验证器检查结果；内核核对身份、版本和迁移规则，再提交持久状态。任务列表清空，只说明当前计划耗尽，不能单独证明目标已经达成。
这张图说明分工，不是把语义判断全部变成确定性代码。模型与人负责理解、假设和取舍；确定性规则负责保护可表达的边界。验证器也可能不完整，所以还要保留反证、来源和人工复核入口。更细的执行与恢复契约见Effect Program，协作对象见Agent 原生 Kanban。
Semantic Execution Engine 与 Agentic Software
Runta 的 Guanlan Dai 在 Agents aren’t software 中把容错单位上移到语义执行状态，并强调保留仍有意义的判断。它提示了一个问题：进程恢复后，未完成的工作是否仍能接续？
这里需要加一个分布式系统视角的校准：传统软件早就有并发、随机算法、动态调度和外部故障。Agent 带来的变化，是求解路径、工具组合和部分评价结论，可以持续由模型在运行中提出。开放的是求解路径，必须明确的是执行、验证与提交边界。这不会让原有系统工程失效，反而提高了对它的要求。
我的定位是：模型与 harness 承担理解、假设和工具循环；领域能力定义有价值的结果与验证；执行环境约束资源和外部访问；LoopX 在其间保留目标、权责、证据与工作连续性。低延迟、可靠性、成本和扩展性仍然要测，同时还要测换会话、换执行者后有没有丢掉行动依据。
可以把这个整体看成一种 semantic execution engine：输入不只有参数，也有目标和反馈；输出不只有返回值，还包括被接受的状态变化。这个概念描述系统分工；LoopX 具体承担语义控制面，并不替代模型、harness 或执行环境。
Local 与云端可以共享工作身份、证据和验收约定，再适配各自环境。迁移时既要检查代码与依赖，也要检查旧执行者是否已失去写权、授权能否继承、结果是否仍适用于当前验收。相同的状态协议提供连续性，云端交付仍要单独验证。
从分布式系统看：把判断放进可提交的状态
给系统加上语义，具体改变的是状态模型、提交条件与恢复单位。仅把一段自然语言目标存进数据库，仍然会留下同样的工程缺口。
保留权威事实，按需重建读法
目标修订、被接受的决定、证据引用、工作归属与提交回执，需要稳定身份。看板、摘要和“下一步建议”是这些事实的读法，可以按使用者重建。无法重新采集的实验结果与负证据仍需归档；“可以重算展示”不等于“可以丢掉依据”。这正是 LoopX 状态与投影契约要区分的责任。
版本与因果，保护证据的有效范围
“测试通过”应关联候选修订 rA、负载 W1 和验收 v1；人的决定也应绑定其操作范围。rB 或 v2 到来时，系统保留历史事实，再判断哪些结论仍适用。把消息排好序，只能知道先后；要安全行动，还要知道这条证据针对什么、谁有权接受变化。
外部效果不确定时，先核对再重试
设想 Agent 提交 GPU 实验后断连：远端可能已经启动，客户端却没收到响应。AWS 的幂等 API 设计说明了请求身份对安全重试的价值。这里也要用稳定请求 ID 或 Job ID 回读；如果 provider 无法确定结果，就保留不确定性。控制面只结算一次，不会自动保证远端只启动一次。具体恢复链由核心长文的 Effect Program展开。
一致性保护提交，不替代技术判断
租约、revision check 与旧写入者隔离，能拒绝过期执行者的写入；它们无法判断两个都通过局部测试的方案哪个更值得做。协议保护可执行边界，模型、验证器与人共同比较路线。跨 Agent 的共同状态应让事实一致、分歧可见，再通过明确的权威接受决定，不能把最后一次写入当作最好的判断。
因此，长程系统要同时看三件事：安全性——是否越过授权与验收边界；活性——有资格的工作能否被接住，等待后能否恢复；价值——新的投入是否补上验收缺口、减少不确定性。系统可以稳定地运行错误路线，第三项必须由结果反馈持续检验。
让自主开发有持续交付的地基
短反馈链要长期成立，我会优先建设三类基础：
- 可组合的原子能力。让 Agent 用 CLI 完成真实读写，返回有身份的结果与错误，能回读外部事实。先做完整的小闭环，再扩大能力面。
- 可演进的工程约束。在仓库里建立架构边界、RFC、测试、独立评审和发布门禁；让重构持续减少重复权威与代码腐化，而不是只增加补丁。
- 跟得上开发的评价。保存基线、候选修订、负载、预算和反例；将便宜的局部验证与昂贵的完整评测分开，并保留独立验收。多生成几个 diff，不会自动增加有效产出。
把体验反馈变成跨层验收
LoopX 的研发从早期就在用自己的长程能力。2026 年 6 月 1 日的公开 Meta Goal，已把仓库的可运行性、工作接续和验证定义为持续目标；6 月的自迭代案例记录了 benchmark、控制面、规划、界面与文档多条研发线共同推进。后来扩展到多 Agent 和 Personal Workspace，贯穿其间的是同一件事：把研发目标、工作归属、人的反馈和验证结果保留下来，让改进后的系统参与下一轮研发。沿革详见自举与 RSI；提交数量只说明活动规模，不计为能力收益。
这也解释了全链路 co-design 的价值。一个产品问题可以同时改变交互、状态表达与测试要求，方向和工程上下文无需在各层重新解释。现在的交付流程从普通用户任务出发：哪里失败，哪些信息被重复索取，如何走完构建后的页面并回读结果。人的反馈进入后续工作与验收，Agent 在同一条链里调整设计和实现。
Goal 工作区把方向、验收条件、工作地图和人的决定放在一起，分别表达任务进展与目标验收。公开首屏先给本人看预览，再检查桌面、窄屏和键盘路径。下图是仓库中的合成 showcase，展示这种产品组织方式；数字是展示数据。
用原子 CLI 和薄 skill 拼出完整回路
本机推进 LoopX 时，Agent 通过 CLI 读取工作、调用工具、提交结果和回读状态；下一步采用当次 interaction_contract。能力分层把组合边界固定为 Agent → Capability → Provider；外部观察经过领域校验，再回到 Kernel 的工作生命周期。宿主执行工具，领域能力解释结果，Kernel 保留任务、权限和预算。CLI 与薄 skill 连接这些已有能力，不各自维护一套工作规则。
例如可选的 Explore把问题、实验、发现和反证组织成证据图；PR Review 则组织具体版本的审阅计划、证据与结果。研究与交付的领域流程不同，但都复用既有 Todo、claim、gate 和回写边界。Explore 的分支建议不会自行启动 worker 或增加预算。这样扩展一个研究方法或外部工具，可以复用长程基础设施，而不必再造调度器。
让下一次修改更容易：类型、归属与持续重构
维护性需要持续治理行为归属。仓库要求新增枚举与闭集说明其 owner，重构优先删除重复权威、加强类型合同和缩小模块边界；代码量也是成本。规则应成为新修改反复经过的检查，而不只留在首次设计里。
更有代表性的实践是从 2026 年 8 月开始的控制面渐进迁移：先固定行为与权威，再把 Turn 结算、quota、Todo 完成等完整事务的规则及内部持久化效果收敛到 TypeScript；Python 保留仍需要的 transport、兼容显示和外部 adapter。迁移中也发现，逐个 helper 翻译会增加桥接和双份代码，于是改用完整事务切换及旧规则删除作为进展单位。目标是让下一次规则修改更容易定位、测试和回滚。已迁切片与尚未退役的调用方分别记录，不能把整项迁移写成已完成。
自动检查支持独立判断，发布权限单独保留
LoopX 自身的变更闭环从问题刻画走向聚焦实现、回归检查、按风险选择 canary 和审阅。loopx pr-review把结论绑定具体 head；新提交不能继承旧版本的通过结论。测试、审阅、本人决策和发布各自有边界，检查通过不会自动授予合并权。
协作也可以沿完整交付链检查。公开的三 Agent 演示让 builder 请求 analyst 的模型产物，使用实际文件实现求解器，再交给 reviewer 独立复核；修订“预留库存、最低区域分配”后，再实现、再审阅，最后把结果返回原对话。独立穷举 oracle 不导入候选求解器，两个输入版本有各自的精确期望。演示的输入与阶段调度由控制器设置，范围是同主机、同 Goal 的产物采用和跨新会话接续；它不证明无人值守调度或完整跨 host 协作。
让评价跟上开发：分层、反例与资源取舍
LoopX 将评价分层：便宜的确定性合同与真实入口回归支撑日常修改，canary 检查跨面风险，真实模型资格与长程结果评测另行执行。测试要能拒绝错误候选，预期不能照候选实现生成；代码可运行、模型采用协议、长期任务取得收益，需要不同证据。开发速度提高不会自动增加评价资源，分层是在成本约束下保留决定性的检查。
长程自主研发也在不断改造 Agent 自己的接口和规则。LoopX 因此把“输出是否仍可读、概念是否分叉、决策模块是否膨胀、失败后能否正确接续”做成可执行检查。这里的语义复杂度没有被压成一个总分，而是由几类互补的护栏约束。
| 护栏 | 检查对象与方法 | 证明边界 |
|---|---|---|
| CLI 输出合同 | 对真实 stdout 测量字符、UTF-8 字节、行数与 JSON 结构；用相同 fixture 比较 base/head，检查随任务与历史增长的斜率、必需字段和动作语义。热路径有详情下钻入口。 | 更小仍可能丢失关键指导。结构检查之外，还要审阅权限、停止条件与证据义务；体积通过不证明模型理解。 |
| 语义词表漂移 | 扫描 Enum、Literal、命名闭集与 TypeScript as const，核对定义 owner、取值、跨运行时孪生、投影及受支持的生产位点；未登记取值、重复定义和生成绑定漂移进入门禁。 | 证据限于扫描器识别的形式和已覆盖的词表域。未解析动态路径、部分消费者检查仍有缺口，不能宣称任意语义已经等价。 |
| 可维护性棘轮 | Python AST 检查控制面决策函数的语句数与决策点、模块体积、Any 使用及禁止的依赖方向。既有债务、模块预算和审阅例外显式登记；例外带理由与退役计划。 | 新增未审阅债务、有指标例外超界或失效例外会失败。这些指标提示重构风险，不能把函数拆短或降低计数直接算作设计改进。 |
| 状态组合与恢复 | 已有 Turn 检查沿 writeback → quota spend → closeout 注入中断、未知回读与精确重试，独立核对每个逻辑 effect 只提交一次，并保留真实入口和读回证据。 | 使用有限故障序列、真实 File journal 与合成 provider ledger；不证明断电持久性、完整 lease 竞争或所有跨域活性，组合验收仍未全部完成。 |
门禁本身也需要反例。现有测试检查：输出缩小却删除必需语义时仍失败；词表检查不能靠缩窄扫描范围绕过；已有债务例外不能掩盖继续增长。输出预算是回归基线，有价值的新决策信息可以通过同条件测量与审阅调整；压缩则必须保留指导义务。检查通过只说明所检查的合同成立，最终仍要观察模型行为与实际交付。
LHTB 五臂研究提供了一种跨版本、跨执行方式的整体检查：46 个共同任务覆盖 Plain Codex、Native Goal、SSH-Goal 与两代 Heartbeat，模型和推理强度相同。LoopX 1.0.3 Heartbeat 平均 reward 为 0.4948，Plain 为 0.4218，但严格完成数同为 7/46。每个任务与执行方式只有一次有效试验，存在替换试验及预算差异，因此不能据此宣称等预算效率或单一机制的因果收益。把失败、退化与边界一起保留，才有依据决定下一轮把评测资源投入哪里。
本地到云端：复用语义，分别验收执行环境
LoopX 已把控制面合同、领域能力与 host/provider 适配分开；本机原型因此可以保留工作身份、验收和证据，再适配远端工具。当前R6 路线区分“单一权威、混合执行”的过渡形态与完整跨 host 协作。前者不能通过复制一份可独立写入的 Goal 数据库来实现。
完整验收仍要求至少两个真实 host，含一个云端 worker，并检查 tenant/actor 权限、撤销、断连、旧 writer 和不确定提交。共享合同减少重新表达需求的成本；云端资源、依赖与隔离仍需单独证明。这里已有可复用的分工，完整 Local/Cloud 资格仍是待完成的目标。
当 Agent 的工作跨越多轮、多个会话和不同执行者，这些约束就需要成为可继承的状态。长程自主开发追求的是：不需要人判断时，持续推进有价值的工作；需要纠偏时，让一次反馈改变后续行动；证据不足或边际收益下降时，能够等待、换路或收口。
如果这些改进又被用于改进开发系统本身，就出现了系统自迭代的闭环。已有自举与 RSI 文章专门讨论这段沿革与边界；持续提交和修改自身代码，仍不能单独证明能力提升。
从一个你能验收的目标开始
不必先组织一个庞大的 Agent 团队。选择自己的试验仓库，把结果标准、开发范围、预算和发布权限说清楚。例如：
固定当前负载与基线，研究并验证一项性能优化。保留失败实验和反例；每轮记录候选修订、测量条件、剩余缺口与下一步。允许修改试验分支，发布和额外算力花费先由我决定。
从开发者手册接入，再用 loopx doctor 与 loopx status检查环境和已连接项目。第一次实践，要看完整的“执行—验证—写回—接续”：换一个会话后，还能否找回目标、证据、等待条件和人的纠正。
对一次会话就能完成的小任务，额外控制面可能并不划算。对反复需要你恢复上下文、催促续行和核对事实的工作，它才有机会把管理开销赚回来。我希望最终增加的是经过验收的交付，减少的是人反复维持工作连续性的注意力。
接下来读什么
- 应用场景：区分复杂交付、开放探索与持续职责，选择合适的试验。
- 核心架构长文：目标、状态内核、Effect Program、等待与重规划的详细解释。
- Agent 原生 Kanban：工作项、认领、租约、门禁与共享权威状态。
- 阶段性研究与事故复盘：核查反馈、经验和信息新鲜度究竟在哪些地方有效，哪些仍未证明。
- 自举与 RSI：理解“改进进入下一轮”的历史与判断边界。
本文由 LoopX creator Ruiteng Huang 撰写。技术说明依据公开实现；案例与性能数据来自贡献者的公开 PR，本文没有新增实验。核心实现参考：Architecture、Goal / Vision / Replan与Decision Scope。历史长文是背景阅读，操作以当前手册为准。