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/loopxLoopX 是一个面向长时程智能体Long-horizon Agent的控制平面统一管理 Codex、Claude Code 等多种执行框架下的持久化、可治理工作。它的核心机制之一是为一轮 Agent 执行Turn建立了一套类型化决策词汇表——每一轮开始前的路由决策、结束后的结果归类全部由有限、封闭、可校验的枚举值精确描述而不是自由文本。本文带你读懂这套词汇表的设计思路。为什么 Agent 的每轮结局需要类型化描述长时程 Agent 任务可能持续数小时甚至数天期间每一轮执行都可能遇到各种结局成功推进、被外部阻塞、宿主进程失败、校验不通过、额度扣减失败……如果结局只用自然语言记录后续的状态恢复、配额计费、审计追溯就无从谈起。LoopX 的做法是给每一轮 Turn 的决策和结果分别定义封闭的枚举词汇表。调度器只看枚举值做判断人类看渲染后的报告两者共享同一份事实来源。这套词汇表主要分布在三个位置层级枚举作用路由层LoopXTurnRoute本轮该不该启动宿主、走哪条路径结果层LoopXTurnResultKind本轮执行后落在哪个结局循环控制层LoopDisposition循环控制器据此决定下一步动作路由层8 种类型化路由决定这一轮走哪条路在 loopx/control_plane/turn_driver/driver.py 中LoopXTurnRoute定义了 8 种路由值。控制平面在启动宿主之前会先对信封envelope做 schema 校验、签名校验再根据有效动作把本轮归入一条路由路由值含义ready_for_host一切就绪可以启动宿主执行capability_action_required需要先执行受治理的能力意图repair_required需要先修复工作区、状态投影等replan_required需要先重新规划任务user_action_required需要人类介入本轮不启动宿主wait允许安静等待不消耗额度blocked被明确阻塞无法继续contract_error信封 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.jsonhost_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 中DeliveryOutcome4 值surface_only仅表面动作、outcome_gap结果缺口/受阻、outcome_progress结果推进、primary_goal_outcome主目标达成DeliveryTurnKind6 值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 种循环处置外加交付层的 46 种价值词汇类型化换来三大收益失败可定位到具体事务阶段、额度消耗有纪律、状态恢复不靠猜测想深入源码从 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LoopX Turn决策词汇表：17种类型化路由与结果如何精确描述每轮结局
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/loopxLoopX 是一个面向长时程智能体Long-horizon Agent的控制平面统一管理 Codex、Claude Code 等多种执行框架下的持久化、可治理工作。它的核心机制之一是为一轮 Agent 执行Turn建立了一套类型化决策词汇表——每一轮开始前的路由决策、结束后的结果归类全部由有限、封闭、可校验的枚举值精确描述而不是自由文本。本文带你读懂这套词汇表的设计思路。为什么 Agent 的每轮结局需要类型化描述长时程 Agent 任务可能持续数小时甚至数天期间每一轮执行都可能遇到各种结局成功推进、被外部阻塞、宿主进程失败、校验不通过、额度扣减失败……如果结局只用自然语言记录后续的状态恢复、配额计费、审计追溯就无从谈起。LoopX 的做法是给每一轮 Turn 的决策和结果分别定义封闭的枚举词汇表。调度器只看枚举值做判断人类看渲染后的报告两者共享同一份事实来源。这套词汇表主要分布在三个位置层级枚举作用路由层LoopXTurnRoute本轮该不该启动宿主、走哪条路径结果层LoopXTurnResultKind本轮执行后落在哪个结局循环控制层LoopDisposition循环控制器据此决定下一步动作路由层8 种类型化路由决定这一轮走哪条路在 loopx/control_plane/turn_driver/driver.py 中LoopXTurnRoute定义了 8 种路由值。控制平面在启动宿主之前会先对信封envelope做 schema 校验、签名校验再根据有效动作把本轮归入一条路由路由值含义ready_for_host一切就绪可以启动宿主执行capability_action_required需要先执行受治理的能力意图repair_required需要先修复工作区、状态投影等replan_required需要先重新规划任务user_action_required需要人类介入本轮不启动宿主wait允许安静等待不消耗额度blocked被明确阻塞无法继续contract_error信封 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.jsonhost_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 中DeliveryOutcome4 值surface_only仅表面动作、outcome_gap结果缺口/受阻、outcome_progress结果推进、primary_goal_outcome主目标达成DeliveryTurnKind6 值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 种循环处置外加交付层的 46 种价值词汇类型化换来三大收益失败可定位到具体事务阶段、额度消耗有纪律、状态恢复不靠猜测想深入源码从 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考