企业官网建设流程全解析

LoopX Turn决策词汇表：17种类型化路由与结果如何精确描述每轮结局

【免费下载链接】loopxLong-horizon agent control plane for durable, governed work across Codex, Claude Code, and other harnesses.项目地址: https://gitcode.com/GitHub_Trending/lo/loopx

LoopX 是一个面向长时程智能体（Long-horizon Agent）的控制平面，统一管理 Codex、Claude Code 等多种执行框架下的持久化、可治理工作。它的核心机制之一，是为一轮 Agent 执行（Turn）建立了一套"类型化决策词汇表"——每一轮开始前的路由决策、结束后的结果归类，全部由有限、封闭、可校验的枚举值精确描述，而不是自由文本。本文带你读懂这套词汇表的设计思路。

为什么 Agent 的"每轮结局"需要类型化描述？

长时程 Agent 任务可能持续数小时甚至数天，期间每一轮执行都可能遇到各种结局：成功推进、被外部阻塞、宿主进程失败、校验不通过、额度扣减失败……如果结局只用自然语言记录，后续的状态恢复、配额计费、审计追溯就无从谈起。

LoopX 的做法是：给每一轮 Turn 的"决策"和"结果"分别定义封闭的枚举词汇表。调度器只看枚举值做判断，人类看渲染后的报告，两者共享同一份事实来源。这套词汇表主要分布在三个位置：

路由层：8 种类型化路由决定"这一轮走哪条路"

在 loopx/control_plane/turn_driver/driver.py 中，LoopXTurnRoute定义了 8 种路由值。控制平面在启动宿主之前，会先对"信封"（envelope）做 schema 校验、签名校验，再根据有效动作把本轮归入一条路由：

🔑 值得注意的是contract_error：它不是"报错"，而是一种类型化的拒绝——签名不匹配时宁可路由到拒绝，也不允许模糊执行。这保证了"每一轮为什么没跑"都有精确答案。

结果层：12 种结果类型精确锚定"失败发生在哪一步"

每一轮真正执行后，结局由 loopx/control_plane/turn_driver/transaction.py 中的LoopXTurnResultKind描述，共 12 种：

• 正向结局：validated_progress（验证通过的进展）、validated_completion（验证通过的完成）
• 需要恢复：repair_required、replan_required
• 需要等待/人工：wait、user_action_required
• 阶段化失败：host_failure、validation_failed、writeback_failed、quota_spend_failed、terminal_closeout_failed、iteration_failed

这套结果类型与七阶段事务流水线一一咬合。阶段定义在 loopx/control_plane/turn_transaction_contract.json：

host_execute → typed_result → validation → durable_writeback → quota_spend → scheduler_apply → scheduler_ack

每个失败型结果都被约束必须声明"失败发生在哪个阶段"（例如host_failure必须对应host_execute），且completed_phases必须是该流水线的有序前缀。这意味着任何一份 Turn 回执都能回答三个问题：走到哪一步、卡在哪一步、接下来该做哪一步。

此外，词汇表还内建了"额度纪律"：user_action_required、wait、各类校验失败等结果被归入NO_SPEND_RESULT_KINDS，规则上不允许消耗额度；而"有实质推进"的结果（MATERIAL_RESULT_KINDS）必须完成独立校验才允许写回状态。

循环控制层：8 种处置决定"下一轮做什么"

拿到类型化结果后，循环控制器 loopx/control_plane/turn_driver/loop_controller.py 用LoopDisposition输出 8 种处置：run_now、capability_action_required、wait、stop、user_action_required、repair、replan、terminal。

每份处置都自带三个布尔声明：spends_quota（是否花额度）、launches_host（是否启动宿主）、writes_state（是否写状态）。长时程任务中最贵的资源就是宿主调用和配额，这三个声明让"等待一轮"和"失败一轮"的成本一目了然，避免 Agent 在无效循环中空转烧钱。

交付层：用 DeliveryOutcome 回答"这一轮到底推进了什么"

路由与结果描述的是"过程结局"，而交付词汇表回答"价值结局"。在 loopx/control_plane/work_items/delivery_outcome.py 中：

• DeliveryOutcome（4 值）：surface_only（仅表面动作）、outcome_gap（结果缺口/受阻）、outcome_progress（结果推进）、primary_goal_outcome（主目标达成）
• DeliveryTurnKind（6 值）：contract_only_preparation、compact_evidence、blocker_writeback、product_path_execution、outcome_gap、unknown

其中有一个防作弊细节：显式给出的非法delivery_turn_kind不会被"降级猜测"，而是强制落入unknown——猜测性归类比承认未知更危险。这个边界行为由 examples/delivery-turn-kind-enum-smoke.py 中的冒烟测试持续守护。

这套词汇表如何落地到你看到的一切？

词汇表的下游消费者包括状态文件、CLI 渲染器和仪表盘：loopx/status.py 把类型化结果投影为紧凑的 post-handoff 状态，loopx/cli_commands/turn.py 负责命令行展示，而回归契约（如 regression/automation-loop-heartbeat-poll-contract.py）和单元测试（如 tests/test_loopx_turn_transaction.py）则持续验证"结果类型—事务阶段—额度扣减"三者的一致性。

对普通用户而言，你不需要背诵这些枚举值——但理解它们能让你看懂 LoopX 报告中的每一条状态：每个词都不是自由发挥的文案，而是一个带约束、可验证、可审计的类型化事实。

小结

• LoopX Turn 决策词汇表 = 8 种路由 + 12 种结果类型 + 8 种循环处置，外加交付层的 4+6 种价值词汇
• 类型化换来三大收益：失败可定位到具体事务阶段、额度消耗有纪律、状态恢复不靠猜测
• 想深入源码，从 loopx/control_plane/turn_driver/ 目录开始，配合 tests/test_loopx_turn_settlement_parity.py 理解结算一致性契约

💡 提示：若希望快速上手长时程 Agent 控制，可先运行仓库examples/目录下的 turn 系列冒烟脚本，无需真实宿主即可观察完整的路由与结果词汇流转。

【免费下载链接】loopxLong-horizon agent control plane for durable, governed work across Codex, Claude Code, and other harnesses.项目地址: https://gitcode.com/GitHub_Trending/lo/loopx