什么时候 LoopX 不是答案¶

理解架构后，还需要决定哪些任务值得放进控制面。判断依据是需要协调的状态和失败成本：是否跨会话、是否等待外部结果、是否交接，以及重复执行会造成什么后果。

先看接入成本是否值得¶

假设你只想给一个函数补类型标注，能在当前会话内验证，失败后重做也便宜。连接项目、建立 Goal、维护 Todo 和回执可能比这次任务本身更费事。普通会话通常已经足够。

如果同一项修复需要等待 CI、处理多轮 review、换 Agent 接手，外置状态开始有价值。下一位执行者可以知道哪些结果已被验证、哪个决定仍未完成。任务短也可能有高风险副作用，时长不能单独决定是否需要治理。

LoopX 能记录 Goal、acceptance、工作队列、权限和证据，也能通过 Capability 支持具体领域的判断。但仅有一条 done 记录，不能证明代码正确、实验显著或文案被接受。

接入前，先说明什么观察足以支持完成。探索性任务可以先定义阶段验收，例如交付可检验的假设与下一次实验；需要人工判断的结果可以保留对应 Gate。无需强行把所有质量判断变成自动测试。

使用判断： 谁负责验收，依据哪份结果，结果不成立时下一步是什么？

状态读取、准入、验证和写回都会增加工作。减少重复执行、避免无意义唤醒又可能降低总成本。因此，单轮延迟与整体完成时间需要分别测量，不能预先断言其中一项必然变差。

如果瓶颈只是模型的一次响应，增加控制面不会直接提升模型速度。若瓶颈来自反复找上下文、等待无人处理或重复执行，LoopX 的状态与调度可能改善整条路径。

使用判断： 比较相同任务的完成时间、真实资源消耗和人工介入，确认恢复收益能否抵消维护成本。

状态底座负责工作生命周期事实。LoopX 也有带来源、范围和撤销语义的 Agent 偏好，以及 decision context、reward memory、turn recall 等能力或接入边界。

这些能力不等于任意聊天都自动进入永久知识库。偏好不是 action authority，召回内容需要检查来源、新鲜度和适用范围；是否可用还取决于当前版本、配置与 provider。

使用判断： 要保存的是 Todo/回执、明确的用户偏好，还是外部知识材料？先选择已有 owner，再决定保存与召回方式，避免把全部聊天塞进 active state。

LoopX 决定允许推进的工作、结算和恢复边界；Host 提供模型会话、工具和具体运行环境。两者通过 adapter 连接，可见性、后台唤醒和恢复能力随 Host 而异。

控制面可以改善计划、协作和验证，但不能保证模型每一步推理正确，也不能授予 Host 原本没有的权限。换 Host 时仍要复核接入能力和当前 identity，不能假定所有集成都有同等保证。

使用判断： 问题来自执行能力不足，还是来自状态、协调或恢复缺失？选择能覆盖实际缺口的组合。

这些条件同时成立时，普通会话是合理选择。需要长程执行时，用任务资格卡记录真正需要保存和治理的内容，从一个可验证的任务开始。

先完成一次接入和交付，再检查一次与你的风险有关的等待、会话切换或恢复。观察状态是否可读、结果是否保留、失败是否有下一步；把额外维护和人工操作一并算入成本。

架构选择的落点是具体任务：它减少了哪类重复与协调成本，引入了哪些新责任，现有边界能否覆盖你真正担心的失败。