从对话记忆到状态控制平面：长程 Agent 的状态治理工程

如果一个 Agent 只需要工作二十分钟，我们通常会关心 Prompt 写得够不够好、工具调用准不准确、模型推理够不够聪明。但如果它要连续工作二十个小时、两百个小时，甚至在多个 Agent 之间反复交接，问题会突然发生变化：昨天确定的目标，今天还记得吗？第 40 轮已经否定的方案，第 100 轮会不会又被重新执行？人类按下"暂停"之后，系统究竟是在真正等待决策，还是只是在消耗计算资源？一个 Agent 离场、另一个 Agent 接手时，它接到的究竟是可靠状态，还是一段越来越长、越来越模糊的对话摘要？

这正是长程 Agent 从"模型能力问题"转变为"系统工程问题"的临界点。

上下文窗口可以越来越大，模型也可以越来越聪明，但任何有限窗口都无法承担无限增长的任务历史。更关键的是，历史并不等于状态：真正需要被长期保存的，不是 Agent 曾经说过的每一句话，而是当前目标是什么、哪些事实已经被验证、哪些路径已经失败、哪些动作获得授权、哪些工作仍被阻塞，以及下一步为什么应该继续。

因此，长程 Agent 真正缺少的或许不是更长的记忆，而是一套类似操作系统控制面的状态治理机制。它要让目标可持续、证据可追溯、决策可约束、资源可计量、失败可恢复，还要让人在关键节点拥有不可被自动化绕过的判断权。

当 Agent 开始跨越一天、一个项目周期甚至一个组织流程持续行动时，我们面对的已经不再是"怎样写一个更好的 Prompt"，而是一个更基础的问题：**谁来管理这个不断运行的智能系统本身？**本文试图回答的，正是这个问题。

一、范式迁移：长程 Agent 的瓶颈正在从"会不会做"转向"能不能持续正确地做"

（一）Prompt 优化的边际收益正在下降

过去两年，Agent 工程的大量精力集中在提示词：如何描述目标、如何让模型调用工具、如何减少幻觉、如何让一次回答更接近预期。这类工作仍然重要，但当 Agent 开始连续运行数小时、跨越多个会话，甚至需要多人审批和多 Agent 协作时，单轮提示词已经不再是决定系统可靠性的唯一杠杆。

**Loop Engineering 之所以在 2026 年快速受到关注，本质上是把工程问题上移了一层：与其不断改写"这一轮应该怎么问模型"，不如设计一个会自动寻找下一步、执行有界工作、验证结果、记录状态并决定是否继续的循环系统。**此时，Prompt 从"业务规则本体"退化为调度入口，真正决定 Agent 行为边界的是外部状态、权限、验证器、预算以及停止规则。

1、从"一次聪明回答"转向"长期可控推进"

短任务可以容忍很多隐式信息：模型记得刚才说过什么、操作者记得为什么选择某个方案、失败后人工可以重新解释背景。但长程任务把这些隐式信息全部放大成系统风险。第 3 轮没有问题的设计，到第 80 轮可能因为上下文压缩、人员交接、工具重启或模型切换而失效。

因此，长程 Agent 的核心指标不应只是"每轮输出质量"，而应增加至少三个维度：第一，目标是否在跨轮次保持稳定 ；第二，每个完成声明是否有可复核证据 ；第三，系统能否在失败、等待和切换执行器之后继续从正确位置恢复 。

2、从"模型自我管理"转向"系统约束模型"

当模型既负责提出下一步、又负责判断自己是否做对、还负责决定是否继续时，系统事实上把计划、执行、验收和治理集中在同一个概率性组件上。这种结构在演示阶段很灵活，在生产阶段却缺少独立制衡。

更**稳健的做法是把模型视为一个高能力但非权威的执行器：它可以提出候选动作、调用工具、解释结果，但目标契约、关键权限、预算、外部验证、人工审批与恢复点由独立控制层维护。**也就是说，系统不是"相信模型会记得规则"，而是让模型每一轮都重新读取当前规则并接受确定性检查。

（二）长程任务暴露的是结构性故障，而不是单纯的"上下文不够长"

把上下文窗口做得更大可以缓解信息丢失，却不能根治长程 Agent 的工程问题。原因在于：对话历史是一种面向生成的材料，不是面向治理的状态数据库。即使所有历史都能被装进上下文，模型仍然需要回答"哪些信息是当前权威""哪些决策已经被否决""哪些动作需要批准""哪些结果真正通过验证"等问题。

1、上下文滚动导致目标失忆与决策反复

长程任务早期形成的约束条件、非目标、风险判断和已证伪路径，随着对话增长会逐渐被摘要、压缩或移出当前工作集。模型可能重新尝试已经失败的方案，也可能在没有意识到的情况下改变完成标准。这不是模型"变笨"，而是系统缺乏稳定的目标与决策锚点。

2、人工等待如果没有结构，就不是状态

"暂停等用户回复"看似简单，实际上至少包含：在等谁、等什么、阻塞哪些动作、是否允许做只读工作、多久后需要升级、什么证据出现后可以恢复。若这些信息仅存在于自然语言提示里，Agent 很容易出现两种极端：要么整个任务被无期限阻塞，要么为了维持"自主性"绕过本应由人判断的边界。

3、多 Agent 交接如果只靠 Prompt，就是不可审计的口头传递

当一个任务被拆成数据收集、分析、验证、报告等多个角色时，真正重要的不是"谁先谁后"，而是谁对什么结果负责、交付了什么证据、下游可以假设什么、哪些风险尚未关闭。仅靠在 Prompt 里复制前一个 Agent 的总结，无法提供稳定的归属、幂等、防重复执行和事后审计。

4、没有状态迁移的重复运行，只是在消耗预算

Agent 可以看起来非常忙：不断读取、观察、轮询、改写相似内容，却没有产生新的已验证状态。单轮模型往往难以感知"我已经在这个方向上停滞了多久"，因此系统必须跨轮累计进展证据，并在连续无进展时触发 Replan、等待或停止，而不是继续消耗算力。

（三）真正的新问题：谁拥有跨轮次的"事实解释权"

当 Agent 能连续工作数百轮时，系统中必须出现一个比单次模型调用更高层的权威：它保存目标、当前状态、审批、证据、预算、恢复点和停止条件，并把其中与当前轮次有关的最小信息投影给执行器。这个权威可以是一个轻量本地内核，也可以是企业级工作流平台，但必须独立于某个模型的瞬时上下文。

**这就是"状态治理"与普通"记忆增强"的分界。**记忆回答"过去发生过什么"，状态治理回答"现在什么是真的、下一步允许做什么、做到什么算完成、谁有权改变它"。

二、状态治理不是记忆工程：需要的是最小可信状态，而不是完整历史复述

（一）把上下文当缓存，把持久状态当事实源

在传统 Web 系统里，没有人会把浏览器缓存当数据库；同理，在长程 Agent 系统中，也不应把模型上下文当任务账本。上下文应被设计成一个按轮次生成的工作集：包含当前目标摘要、必要约束、最新证据、待处理事项和本轮权限。完整历史则保存在可查询、可版本化、可审计的外部层。

这带来一个重要工程原则：恢复能力不应依赖"重新喂回全部历史"，而应依赖"从持久快照重建最小可执行上下文"。当 Agent、模型供应商、进程甚至主机发生切换时，只要新执行器能够读取相同的状态契约，就可以继续工作，而不是重新进行一次漫长的背景教育。

（二）六个工程不变量定义"最小可信状态"

一个长程 Agent 系统不必保存所有细节，但至少需要长期维持六类不变量。它们共同决定系统是否仍然在做正确的事情。

1、目标不变量：Goal / Scope

目标不是一句"帮我把项目做好"，而应是可检查的目标契约，包括目标、非目标、成功条件、终止条件、风险边界和当前优先级。目标发生变化时必须留下版本与原因，而不是由某一轮 Prompt 悄悄改写。

2、证据不变量：Evidence

任何"完成""修复""通过""没有变化"的声明，都应能追溯到真实验证：测试输出、查询结果、构建日志、数据快照、审计记录或外部系统回读。模型可以解释证据，但不能把自己的推理当证据本身。

3、权限不变量：Authority

任务状态必须明确谁能决定什么。读取数据、修改代码、提交变更、访问生产、删除资源、发布模型等动作应拥有不同权限级别。关键决策需要把"是否允许"建模成显式状态，而不是一句含糊的"谨慎操作"。

4、预算不变量：Quota

当系统没有产生有效状态迁移时，计算资源不能无限消耗。预算既可以是 token、时间、调用次数，也可以是实验槽位、GPU 小时、数据库扫描量或外部 API 成本。预算应与验证后的有效进展绑定，而非仅统计模型运行次数。

5、连续性不变量：Continuity

下一轮启动时，执行器应读取持久快照、最近证据和下一步路由，而不是依赖聊天残留。连续性还包括多 Agent 交接：后继执行者必须知道上一个执行者交付了什么、验证到哪里、还欠什么。

6、恢复不变量：Recovery

失败后系统应从最近一个已确认状态继续，而不是"把历史再演一遍"。恢复点必须具有可验证的身份，例如状态版本、事件序号、receipt/effect id 或明确的 checkpoint，避免重复提交副作用。

（三）从 LoopX 的五层模型扩展为企业治理视角

我们把 LoopX 的状态拆为 Goals、Human Gates、Evidence、Quota 与 Fallback 五层，这是一个很有价值的最小实现：它把"任务做什么""什么时候要人""做过什么证据""还能花多少资源""卡住以后怎么办"分别建模。进一步面向企业生产环境时，可以把这五层理解为六个不变量的一种具体映射，并补上更明确的 Authority 与版本控制语义。

1、Goal 层解决"方向是否稳定"

活跃目标应有单一事实源，包含 objective、non-goals、next action、近期反馈和进展账本。重要的是它必须被每轮读取，并由受控操作更新。目标文件不是"长期 Prompt"，而是一份可版本化的运行合同。

2、Human Gate 层解决"机器何时必须停手"

把人工问题做成结构化 Todo/Gate，使系统能判断是全局阻塞还是只阻塞某个 Agent、某条 lane 或某类动作。等待不再是空白时间，而是有语义的状态迁移。

3、Evidence 层解决"成功是否有凭据"

证据层最好采用结构化工件 + 人类可读摘要 + 追加式索引的组合。前者便于程序校验，后者便于审计和运营，索引则支持跨轮检索与压缩。

4、Quota 与 Fallback 共同解决"空转和失效模式"

Quota 负责在运行前判断能否继续，Fallback/Replan 则负责当系统长期没有产生有效进展时切换策略。两者组合的关键不是"少花 token"，而是阻止系统在没有新信息和没有新状态的情况下自我循环。

三、控制平面架构：让执行层负责"做"，让治理层负责"决定能不能做"

（一）双轨控制流比"更复杂的 Prompt"更稳健

LoopX 的一个核心设计是执行路径与控制路径分开：Agent 通过 Capability/Provider 执行动作；Provider 的真实回读再进入状态转换，最终由 Kernel 更新全局状态。Kernel 不需要亲自执行代码，也不应偷偷改写工具结果，它只负责维护状态、校验转换规则和产生下一轮的权威指令。

这种分离与 Kubernetes 控制器的思想有相似之处：控制平面维护期望状态，并持续观察真实状态是否收敛。对 Agent 来说，期望状态是"目标与边界"，真实状态则来自测试、工具回读、外部审批和事件记录。模型的自然语言只是连接两者的执行媒介，而不是最终事实。

（二）把每一轮 Agent 执行设计成"可提交事务"

长程 Agent 最容易出现的一类事故是：工具已经执行了部分动作，但状态没有正确记录；或者状态被标记为完成，实际验证还没有通过。解决方法不是要求模型"更仔细"，而是把每一轮执行设计成近似事务的生命周期。

1、Preflight：运行前先做状态守卫

在真正消耗交付算力前，系统先计算 should_run：检查健康状态、人工门槛、依赖是否满足、预算是否足够、当前快照是否新鲜。如果任何硬门槛不满足，本轮应直接进入 ask、wait 或 observe，而不是让模型先自由探索再决定是否越界。

1.1 新鲜度检查

执行器读取的状态必须带版本或时间戳。若活跃目标在读取后被其他 Agent 或人工修改，旧执行器在提交前需要重新校验，否则会发生"基于过期决策写入新世界"的典型并发错误。

1.2 门槛与预算检查

人工 Gate 的优先级应高于资源预算：即使预算充足，只要关键决策尚未批准也不能执行；反之，审批已通过但预算耗尽，同样不能继续。不同约束必须能给出不同的机器可读原因。

2、Claim：声明本轮所有权，但不要把声明误当执行锁

对多 Agent 系统，任务切片需要明确 claimed_by、claim version、可选 lease/expiry。Claim 的价值是建立归属和防止明显重复，但它本身不应绕过权限、预算和 Gate。基础材料中强调"claim 是可见性元数据，不是执行锁"，这一点非常重要：真正安全的并发还需要状态版本、原子写、幂等键或外部事务机制。

3、Execute：只做一个有界、可验证的 Delta

"有界"意味着每一轮都能说清楚要改变什么、不改变什么，以及怎样验证。一个优秀的 Agent loop 不追求每轮做得最多，而追求每轮都能安全提交一个可确认增量。对于代码任务，这可能是一个文件或一个测试目标；对于风控任务，这可能是一组规则候选；对于数据任务，则可能是一张中间表或一个质量检查结果。

4、Verify：验证必须来自真实世界回读

验证器优先级应高于模型自评。代码任务跑测试和静态检查，数据任务跑统计约束和抽样校验，模型任务跑固定评估集和阈值检查，生产操作则要求外部系统返回实际状态。若验证失败，系统可以记录尝试和失败证据，但不能提交"成功"。

5、Commit / Account：成功状态、证据和成本一起结算

只有在验证完成后，系统才更新 Todo、active state、evidence receipt，并记录本轮预算消耗。这样可以形成一个非常清晰的原则：钱是为"已验证的状态增量"花掉的，而不是为"模型运行过"花掉的。

（三）快照与追加式事件账本应同时存在

只存快照，恢复很快但解释力不足；只存事件，审计完整但每轮重放成本高。长程 Agent 更适合采用两者组合：Active State 提供当前事实的紧凑投影，Append-only Ledger 提供不可变历史，Evidence Index 则把关键验证结果连接起来。

这种设计与事件溯源在理念上相近，但不应简单等同于 Temporal 等成熟工作流系统的强事件历史与确定性重放语义。一个轻量 Agent 控制平面可以借鉴"追加、不覆盖、可重算"的原则，同时明确自己在事务一致性、跨服务重放、灾备和高可用方面的能力边界。

（四）多 Agent 并发需要从"抢任务"升级为"并发控制"

当两个 Agent 都读到"Todo A 仍未完成"时，仅靠自然语言约定无法避免重复执行。生产系统至少需要四道防线：注册身份、原子 Claim、版本校验、幂等提交。如果涉及外部副作用，还应增加 effect id、lease、超时回收或业务系统自身的幂等键。

1、所有权要可见、可过期、可转移

一个任务切片的 owner 不应永久绑定。Agent 崩溃后，系统需要判断是否可以回收 Claim，并记录从谁转移给谁。对于不可重入操作，回收前还需要检查外部副作用是否已经发生。

2、交接要传"状态合同"，而不是传聊天摘要

下游 Agent 最关心的是：输入版本、已完成内容、验证证据、剩余风险、下一步契约和禁止重复的尝试。把这些字段作为 handoff contract 固化，远比传一段"上一位 Agent 的总结"可靠。

（五）压缩的对象应该是"上下文投影"，而不是事实本身

长程系统必然要压缩，但压缩策略决定了是否会丢掉关键约束。一个稳健的三层结构是：原始事件尽量保留；状态快照只保留当前有效事实；投给模型的上下文再根据轮次需求做进一步裁剪。

LoopX 按 LONG_TODO_CHAIN、VISION_ACCEPTANCE_GAP、MONITOR_NO_CHANGE_STREAK 等状态事件触发压缩，而不是简单按轮数或文件大小。这背后的方法值得推广：压缩应由语义状态变化驱动，而不是由 token 压力单独驱动。因为真正需要保留的是"会改变下一步决策的事实"。

四、Human Gates 与权限治理：把"请人确认一下"变成一等状态

（一）Gate 的价值不是暂停，而是显式表达决策依赖

一个成熟的 Human Gate 至少要能回答：当前缺什么判断、由谁做、阻塞哪些动作、允许哪些旁路工作、什么条件下恢复、是否需要升级。把这些信息结构化之后，Agent 的等待行为才可计算、可观察、可审计。

如果 Gate 只是聊天里的一句话，那么模型下一轮很可能只看到"继续吧"而忘记这个"继续"只针对某个范围。相反，结构化 Gate 可以在状态机里保持存在，直到明确的解除事件发生。

（二）企业级 Decision Contract 应包含七类字段

1、Question 与 Decision Scope

把问题写成可以做决定的形式，并明确决策范围。例如"是否允许模型上线"过于宽泛，更可操作的是"是否允许版本 v42 在 5% 流量、只读影子模式下进入 24 小时观察"。

2、Decision Owner / Role

审批者不一定是某个固定个人，也可以是角色或值班组。系统应支持代理与交接，并避免把一个人的临时不可用变成全局停机。

3、Allowed Alternatives

如果审批不只有"是/否"，应把允许选项结构化，例如批准、驳回、降低范围、要求补充证据。这样 Agent 才能在不同结果下走不同确定性分支。

4、Blocking Scope

一个 Gate 可以阻塞整个 Goal、某个 Agent、某条 lane 或某种工具动作。阻塞范围越精准，系统越不容易因一个决策节点造成全局停顿。

5、Required Evidence

审批不是脱离上下文的按钮。系统应把支持决策的评估报告、风险指标、变更摘要和验证结果绑定到 Gate，使人能在一个稳定视图中完成判断。

6、Expiry / Escalation

基础材料中的 LoopX Gate 采取"持续存在直到人工解除"的策略，这对安全边界很稳健；但企业运营通常还需要额外的超时提醒与升级机制。注意，超时可以升级通知，不等于自动批准。对高风险动作，沉默不应被解释为许可。

7、Next Handoff Condition

决策完成后，系统要明确"谁接手、允许做什么、需要先重新读取哪些状态"。否则人工批准只是一次消息，不是状态迁移。

（三）多优先级通道可以减少"一个审批卡死所有工作"

P0/P1/P2 或类似多 lane 设计的价值，在于把依赖关系显式化。比如模型上线审批尚未完成，P0 的生产发布可以阻塞，但 P1 的回归测试、P2 的文档准备仍可继续。这样既尊重人工边界，又避免为了保持安全而牺牲全部吞吐。

多 lane 的前提是每条 lane 都有独立的目标切片、权限和证据边界；否则只是把并行度做高，却没有把风险隔离开。

（四）不可逆动作必须由授权，而不是由"智能"决定

Agent 的能力越强，越需要把不可逆动作从模型自由裁量中移出。删除数据、生产变更、资金相关操作、对外发布、敏感信息导出等动作，应要求显式授权或受限工具接口。执行层只获得完成当前有界任务所需的最小权限，秘密信息和高权限凭证最好不直接暴露在模型可读上下文中。

五、Replan、反空转与收敛：系统必须知道"忙"不等于"前进"

（一）长程 Agent 常见三类"伪进展"

1、表面忙碌：重复观察但没有新状态

监控、轮询、检查日志都可能合理，但如果连续多轮没有新证据、没有新决策、没有新的状态迁移，就应从"工作"改判为"等待"。继续调用模型只会增加成本，并可能制造无意义文本。

2、Todo churn：不断创建新任务但目标不收敛

Agent 有时会通过拆分更多 Todo 来掩盖方向不清。任务列表越来越长，却没有更多已验证 outcome。此时系统应看 outcome continuity，而不是看"完成了多少 Todo"。

3、验证债与方向债：做了很多事，但不知道是否还在逼近目标

当若干切片完成后没有回到目标层检查"这些结果是否改变了对最终目标的置信"，系统就积累了方向债。Replan 的意义不是"重新想一次"，而是强制系统把局部动作与全局目标重新对齐。

（二）等待、重规划、收敛都应是显式状态

Active 只表示"允许执行"，并不等于"必须一直运行"。当依赖未满足时进入 Waiting；当需要人类判断时进入 Gated；当连续无进展、目标验收缺口或任务前沿耗尽时进入 Replan；满足终态验证后进入 Converged；出现不可恢复错误则进入 Failed。状态之间的每条边都应有机器可读触发条件。

（三）高质量 Replan 必须带四种约束

1、Required Read：先读失败史，再提出新方向

Replan 之前强制读取最近 evidence/decision log，可以避免模型"忘记自己试过什么"。读取动作最好产生 receipt，使系统能确定这不是一句 Prompt 建议，而是真正发生过的前置步骤。

2、Novelty：新计划必须与已失败路径有可解释差异

"换个思路"太模糊。系统可以要求 Replan 说明新方向与既有方向的差异、为什么值得尝试，以及如果所有可行方向已经覆盖，应进入 exploration_exhausted 而不是继续循环。

3、Bounded Delta：Replan 只允许修改有限状态

例如只允许变更 Todo frontier 与 Vision/Goal checkpoint，不允许顺便执行大规模业务动作。这样 Replan 本身是一个低风险治理动作，而不是借机绕过原有 Gate。

4、ACK / Settlement：只有真正产生状态变化才算完成 Replan

Replan 后需要确认发生了实际 frontier 变更、必要读取已完成、后续验证方式已定义。否则 obligation 保持存在，下一轮仍被路由回 Replan，而不是靠一句"已重新规划"解除。

（四）停止规则必须与成功规则同等重要

一个可靠 loop 至少要有多种退出条件：目标通过外部验证；人工明确终止；预算耗尽；超过最大迭代/截止时间；连续无进展达到阈值；安全或健康检查失败；所有可探索方向耗尽。没有停止规则的 Agent 不是自治，而是不可控的后台进程。

这里尤其要避免"让模型判断自己是否完成"。模型可以参与形成完成解释，但最终收敛最好由确定性 verifier、人工批准或外部系统状态触发。验证器越客观，长程任务越能在模型变化后保持可重复性。

六、生态位置：LoopX、LangGraph、Temporal 与现代 Agent Harness 并不是互斥关系

（一）LoopX 更像 Agent 语义的轻量控制平面

LoopX 当前公开定位是 provider-neutral、stateful control plane，运行在 Claude Code、Codex、OpenCode、Cursor 等执行环境之上，强调 durable goals、gates、todos、evidence、quota 与 handoff。这个定位的重要性在于：它不试图重新发明一个推理框架，而是把跨轮治理从具体 runtime 中抽离出来。

其优势是轻量、本地优先、容易以 CLI/文件状态接入现有工作流；代价则是它并不提供 Temporal 级别的分布式工作流基础设施，也不应被误解为无人值守的生产自治控制器。公开案例中的"200+ 小时"应理解为跨越 200 多小时的墙钟生命周期，并不等于模型连续 200 小时执行，更不等于允许 Agent 长时间持有生产级危险权限。

（二）LangGraph 的能力边界需要用当前文档重新理解

基础材料将 LangGraph 概括为"主要解决单会话图控制、跨会话状态需要外挂后端"，这种说法在 2026 年需要进一步细化。当前 LangGraph 官方文档已经把 checkpointer、thread、store、durability、interrupt/time travel 作为正式能力：图状态可以持久化为 checkpoints，持久化后端可支持跨进程与生产恢复，store 还可提供跨 thread 的长期数据。

因此，更准确的区分不是"LangGraph 能不能持久化"，而是治理语义的侧重点不同。LangGraph 首先是一个 Agent/工作流运行时，擅长图控制流、节点状态、暂停恢复与持久执行；而 LoopX 这类控制平面更强调目标契约、证据收据、配额、跨 runtime 连续性、Human Gate 和 Replan obligation。前者可以承载后者的一部分能力，后者也可以位于前者之上。

（三）Temporal 提供的是更强的持久工作流语义

Temporal 的 Durable Execution 建立在完整 Event History 和确定性 Replay 上，能够在 Worker 崩溃、重启后恢复工作流执行，这一类持久性保证远强于简单文件快照。对于跨服务、长时间、必须精确重放的关键业务流程，Temporal 是成熟基础设施。

但 Temporal 的抽象核心是 Workflow/Activity/Timer/Signal，并不会天然理解"模型证据""Agent 的下一步新颖性""提示上下文压缩""语义性 Replan"这些 Agent 专属概念。因此在大型企业中，更合理的组合往往是：Temporal 管宏观耐久流程与重试，LangGraph 或 Agent SDK 管单个 Agent 的推理/工具循环，状态治理层补上人机决策、证据、预算和跨执行器连续性。

（四）Anthropic 与 OpenAI 的 Harness 演进进一步验证了"外置状态"方向

Anthropic 在长程 Agent harness 的公开实践中强调 initializer、progress artifact、真实测试和跨上下文恢复；OpenAI 的 Agents SDK 演进也强调把运行环境与状态分开，使长程任务可以 snapshot/rehydrate。不同实现细节各异，但共同趋势很清楚：长程可靠性越来越依赖模型之外的可恢复运行环境和显式状态，而不是把更多历史塞进 Prompt。

（五）横向比较应围绕"治理职责"而不是功能打勾

维度	LoopX / 轻量状态控制平面	LangGraph	Temporal	现代 Agent Harness / SDK
核心治理单元	Goal、Gate、Evidence、Quota、Handoff	Graph/Thread/State	Workflow/Activity/Event History	Run、Tool、Session/Sandbox
状态持久化	原生本地状态与历史工件	Checkpointer + Store，可接生产后端	强持久 Event History + Replay	依实现提供 snapshot/session/state
人工判断语义	Gate 作为核心概念	Interrupt 可实现，业务语义需建模	Signal/Update 可实现，业务语义需建模	Guardrail/HITL 能力逐步增强
验证证据	强调 receipt/evidence ledger	可在 state/node 中自定义	Activity 结果可耐久记录	通常通过工具结果、trace、自定义存储
配额/预算	内置治理重点	通常自定义	通常自定义	通常由应用层或平台层控制
Replan/反空转	一等治理路径	可在图逻辑中实现	可建模为工作流分支	多由 harness 策略实现
跨 Runtime 中立性	强	主要在自身 runtime 内	Worker/SDK 跨语言但流程归 Temporal	通常绑定 SDK/运行环境
运维复杂度	低到中	中	高	低到中

工程选型不应问"谁替代谁"，而应问"哪一层负责哪一种失败模式"。在轻量项目中，一个状态控制平面 + 现有 Agent runtime 足够；在生产级复杂系统中，完全可以形成"Temporal durable workflow + LangGraph/Agents SDK harness + 状态治理策略层"的组合。

七、金融科技场景：状态治理的价值在"高风险、长周期、可审计"的交叉区域

（一）隔夜批量特征工程：从脚本重跑升级为证据驱动恢复

信贷特征任务往往包含数据拉取、清洗、特征计算、质量校验和下游登记，单轮可能持续数小时。传统脚本失败后，值班人员需要判断从哪里重跑，且很难确定前序产物是否仍然有效。

状态治理可以把每个阶段设计成有界 segment：完成后产生数据版本、行数/分布检查、schema 校验和产物位置的 receipt。失败后从最近一个"验证通过且输入仍有效"的 checkpoint 继续，而不是简单从上一个脚本行号恢复。Quota 则限制异常数据造成的无限重试；Gate 用于处理分布漂移、数据缺口或跨日口径变化等必须由业务确认的异常。

（二）多 Agent 风控规则生成：把角色协作变成可审计流水线

一个规则生成 pipeline 可以由候选生成 Agent、数据验证 Agent、冲突检测 Agent 和回测评估 Agent 分工。真正的难点不是把四个 Agent 都跑起来，而是确保同一个规则切片不会重复处理、下游读到的是已验证版本、每个淘汰决策有证据、规则修改有明确责任人。

建议把每条规则候选赋予稳定 id，所有变更以事件追加；每个 Agent 只认领自己有权限处理的阶段。回测结果不是自然语言"效果不错"，而是固定窗口、固定样本、固定阈值的结果记录。最终进入审批 Gate 的，应是"候选规则 + 冲突分析 + 效果证据 + 风险说明"的决策包。

（三）模型上线：让审批成为机器可查询的状态，而不是邮件附件

模型上线前往往需要模型风险、业务、合规或变更委员会确认。传统流程中，审批状态散落在邮件、IM 和工单，Agent 无法可靠判断"是否真的可以继续"。

把审批建成 Gate 后，系统可以明确：批准的是哪一个模型版本、哪一个部署范围、哪些指标阈值、是否只允许灰度、由什么角色批准。Gate 通过后，状态机才开放部署准备或发布动作。等待期间，文档、回归测试、变更清单仍可在非阻塞 lane 推进。

（四）催收策略 A/B 实验：把两到四周的变化沉淀成决策链

长周期实验的风险不只在执行失败，更在"事后说不清为什么改过策略"。每次阈值调整、样本排除、提前停止判断都应记录当时指标和决策依据。Evidence 层形成时间序列，Gate 管理是否允许提前终止，Replan 处理连续多日无显著变化或实验假设被证伪的情况。

这使复盘从"回看聊天和报表"升级为"重建当时可见证据下的决策路径"，对模型风险和运营审计尤其重要。

（五）AutoML 与实验搜索：配额是搜索空间的治理工具

AutoML 的难点不仅是并发训练，还包括假设去重、失败试验记忆、资源上限和最终参数选择解释。将每个实验视为一个有界 Todo，Evidence 记录假设、数据版本、超参、指标和失败原因；Quota 控制不同实验组的 GPU/时间预算；Replan 在连续若干实验没有改善时要求改变探索方向，而不是继续在局部参数附近微调。

最终选择模型时，应能回答"为什么是这一组参数，而不是另外几组"，这个答案来自结构化证据图，而不是 Agent 最后一轮的语言解释。

（六）数据质量事件处置：把"发现---定位---修复---验证---复盘"串成状态机

金融数据质量事件常跨越数据平台、模型、业务和合规多个团队，持续数小时甚至数天。Agent 可以帮助定位血缘、检查异常分布、生成修复建议和回归测试，但生产回填、口径确认和影响面认定必须由明确角色授权。

此时最有价值的不是让一个 Agent 全自动处理，而是把处置流程的每个阶段做成可恢复状态：问题是否仍存在、影响哪些表和模型、哪项修复已验证、谁批准回填、哪些下游需要重新计算。即使中途换班或更换模型执行器，整个事件仍能从统一状态继续。

八、生产级蓝图：从"能跑的 Agent"升级为"可治理的 Agent 系统"

（一）五层架构把业务风险和模型执行解耦

一个适合金融科技的生产蓝图可以分为五层：最上层是业务目标与审批；第二层是 Policy / Control Plane；第三层是 Agent Harness；第四层是受控工具与执行环境；最底层是数据与系统事实源。安全、审计与可观测性横跨所有层。

（二）最小状态模式要能独立于模型存在

下面是一份面向工程实现的抽象示例。字段不要求与任何开源项目一致，重点是把目标、状态、权限、证据、预算和版本放在同一个可持久合同中。

python 复制代码

goal_id: credit_feature_refresh_20260817
state_version: 184
status: active
objective:
  text: "完成 T+1 信贷特征刷新并通过质量验收"
  non_goals:
    - "不得修改生产口径定义"
  success_conditions:
    - "全部目标表完成并通过质量规则"
    - "下游模型特征可读取"
next_action:
  lane: P1
  action: "validate feature_set_v42"
authority:
  allowed_tools: [read_warehouse, run_validation, write_staging]
  forbidden_tools: [prod_delete, schema_change]
open_gates:
  - gate_id: gate_distribution_shift
    blocks: [publish_to_prod]
    decision_owner_role: model_risk
    status: open
evidence:
  latest_receipt: ev_9d2f...
quota:
  window: 24h
  compute_remaining: 0.35
continuity:
  last_committed_turn: turn_0183
  required_reads: [ev_9d2f..., decision_41]
recovery:
  checkpoint: ckpt_0183
  idempotency_key: effect_feature_v42

这份状态的价值在于：任何新 Agent 只要有权限读取它，就知道当前目标、禁止事项、下一步、审批、最新证据和恢复点，而不必理解此前数百轮完整对话。

（三）控制接口应围绕状态转换而不是自然语言命令设计

1、运行守卫

should_run(goal_id, agent_id, state_version) 返回 run / ask / wait / stop，并携带原因、允许动作范围和所需前置读取。

2、所有权与更新

claim(todo_id, agent_id, expected_version) 用于认领切片；transition(...) 或 update_todo(...) 只允许在满足版本和权限前提下修改状态。

3、证据与结算

record_evidence(...) 接受可验证结果；settle(...) 只有在 verifier 通过后提交完成状态、effect id 和预算消耗。

4、决策与重规划

request_decision(...) 创建结构化 Gate；replan(...) 创建受约束的新计划；stop(...) 按明确原因进入终态。

接口越结构化，Prompt 越可以保持薄。模型无需背诵全部治理规则，只需遵守"先读状态---调用接口---根据类型化返回执行"的协议。

（四）可观测性要衡量"有效进展"，而不是"调用量"

一个长程 Agent 平台若只看 token、调用次数和平均时延，很容易把空转当高活跃度。更有价值的指标包括：

1、Verified Progress Ratio（已验证进展率）

已产生可验证状态增量的 Turn / 总执行 Turn。该指标持续下降，通常意味着 Agent 在探索、等待或重复失败，需要 Replan 或调整任务拆分。

2、Cost per Verified Delta（单位有效增量成本）

模型成本、工具成本和计算资源除以验证通过的状态增量数。它比"每千 token 成本"更接近真实业务效率。

3、Gate Age 与 Gate Blocked Work

不仅看审批等待多久，还要看这个 Gate 阻塞了多少关键路径。如果一个审批长期阻塞大量工作，应优化审批角色、证据包或 lane 拆分，而不是催 Agent 更快。

4、Replan Rate 与 Replan Success Rate

Replan 太少可能意味着系统在盲目重复，太多则可能说明目标定义或任务粒度不稳定。更关键的是 Replan 后是否真正产生不同方向并恢复进展。

5、Stale Read / Conflict Rate

多 Agent 提交时因版本过期被拒绝的比例，能直接反映并发控制是否合理。冲突高可能需要更细任务切片或 lease 机制。

6、Duplicate Effect Rate 与 Handoff Success Rate

前者监控外部副作用是否发生重复，后者衡量跨 Agent 交接后是否能无人工补背景继续执行。这两项指标直接决定系统能否规模化并行。

（五）安全与合规必须"在模型之外"形成硬边界

1、最小权限和短生命周期凭证

Agent 不应长期持有生产管理员权限。每个动作通过受限工具暴露，凭证按任务和时间最小化授权，并尽量避免秘密值进入自然语言上下文或普通日志。

2、不可逆操作双重确认

高风险动作至少同时满足：控制平面授权 + 工具侧权限校验。对特别敏感的生产操作，还可要求人工审批、变更窗口和独立审计记录。

3、证据保留与数据最小化并存

Evidence 不是越多越好。金融场景中应明确哪些证据需要长期保留、哪些只保留哈希/统计摘要、哪些含敏感数据必须脱敏。审计追溯与隐私最小化需要共同设计。

4、审计日志独立于 Prompt 日志

Prompt/response 适合调试，但不应是唯一审计记录。关键状态变化应有结构化事件：谁在什么版本上执行了什么动作、用了什么权限、验证结果是什么、产生了什么副作用。

九、落地路线：先解决真实的连续性问题，再逐步平台化

（一）阶段 0：先判断任务是否真的需要状态治理

不是所有 Agent 都需要控制平面。单次会话、短时、低风险、失败后可直接重跑的任务，用简单 Prompt + 工具调用可能更经济。只有当任务出现跨会话、跨人、跨 Agent、长等待、高成本或强审计要求时，状态治理才会显著产生价值。

建议先收集三类信号：任务平均持续时长、人工恢复频率、重复执行/方向漂移造成的成本。若这些问题很少发生，不要为了"架构完整"提前引入复杂治理层。

（二）阶段 1：先外置一个 Active State 快照

最小可行改造不是上线复杂平台，而是建立一个每轮必读、每轮可控更新的 active state：目标、non-goals、next action、最近进展、开放问题。仅这一步就能显著降低跨会话目标漂移。

状态文件必须有版本和写入规则，不能让任何 Agent 任意改写；否则只是把 Prompt 换成了另一个无约束文本文件。

（三）阶段 2：把 Evidence 和 Human Gate 做成一等对象

先挑两个高价值动作：一个"完成声明必须有验证结果"，一个"某类关键动作必须人工批准"。当团队能稳定运行这两条规则，Agent 系统就从"会自主执行"开始进入"可审计执行"。

这个阶段应该优先打通真实测试、数据质量检查、工单审批或模型评估，而不是设计漂亮的 Dashboard。治理价值来自状态闭环，不来自 UI。

（四）阶段 3：引入 Quota、Replan 与 Stop Rules

当系统开始周期性运行后，再加入预算窗口、无进展检测和 Replan obligation。早期阈值可以简单、保守，例如连续两次无新证据即要求重新规划，连续若干次失败后转人工，而不要一开始追求复杂的自适应策略。

Stop Rules 应和业务风险对齐：哪些是成功终止、哪些是安全终止、哪些必须升级人工。系统要敢于"正确地停下来"，而不是把永远运行当能力证明。

（五）阶段 4：多 Agent 化之前先补并发语义

不要因为单 Agent 稳定后就立刻复制十个并发 Agent。先补齐 Claim、lease/version、幂等、handoff contract 和冲突处理，再逐步提高并发度。否则，多 Agent 只是把单 Agent 的不确定性乘以并发数。

一个好检验标准是：任意一个 Agent 在提交前崩溃，系统是否能判断其外部副作用有没有发生、任务归属能否安全回收、后继 Agent 是否能不询问人类直接继续。如果不能，说明并发语义还不完整。

（六）阶段 5：当治理规则稳定后再建设平台能力

只有当若干团队重复使用相同的 Goal/Gate/Evidence/Quota 模式时，才值得把它们产品化成统一控制平面、仪表盘、策略引擎和组织级审计。此时平台的主要收益不是"让 Agent 更聪明"，而是统一公司范围内的权限、责任、证据和恢复标准。

十、结论：长程 Agent 的竞争力将越来越来自"可持续正确性"

（一）模型能力决定单轮上限，状态治理决定系统能走多远

未来模型仍会变强，上下文仍会变长，但只要任务包含多轮协作、真实副作用、人工判断和长时间等待，系统就需要一个独立于模型的事实源。更长上下文可以提高执行效率，却不能替代授权、证据、预算、恢复和审计。

（二）控制平面不是为了限制 Agent，而是为了让自治可以被安全放大

没有边界的"自治"只能停留在低风险实验。只有当目标、权限、验证、预算和停止条件都能被机器检查时，团队才敢把更多工作交给 Agent。治理层越清晰，执行层反而可以拥有更大的自动化空间。

（三）真正值得持久化的是决策所需的最小状态

保存全部对话既昂贵又噪声巨大。长程系统应沉淀那些会影响未来决策的事实：当前目标、已确认非目标、证据、Gate、状态版本、预算、失败史和下一步契约。上下文只是这些事实的按需投影。

（四）每一轮都应有清晰的"进入条件---有界动作---验证---提交"

一旦把 Turn 事务化，很多问题会自然变得可解：为什么这轮能运行、谁拥有任务、完成依据是什么、失败后从哪里恢复、成本为什么被记账。反之，如果每轮只是"让模型自由工作一会儿"，系统几乎无法可靠扩展。

（五）Human Gate 是长程自治的核心组件，而不是自动化的妥协

在高风险系统里，人类判断不会消失，只会从"随时盯着 Agent"转变为"在机器明确请求的关键节点做判断"。优秀的 Agent 系统不是尽量减少人，而是让人的注意力只出现在真正需要不可替代判断的位置。

（六）Replan 的目标是恢复进展，不是制造更多计划

真正的 Replan 必须读取失败证据、选择有差异的新方向、限制可修改范围，并通过 ACK/receipt 证明状态已变化。没有这些约束，"重新规划"很容易成为另一种空转。

（七）技术栈应该组合，而不是陷入框架替代论

LangGraph、Temporal、Agents SDK、Claude Code 类 harness 与 LoopX 式状态控制平面分别解决不同层次的问题。工程团队应先画出自己的失败模式：是图控制流、长时耐久、跨 runtime 连续性、人工审批、配额治理还是证据审计，再决定哪一层由哪种技术承担。

（八）长程 Agent 最终会像其他关键软件一样，被"状态、权限和证据"驯化

当 Agent 从一次性助手成长为持续工作的数字执行者，行业会重复分布式系统、工作流引擎和安全工程已经走过的路：把隐式行为变成显式状态，把信任变成验证，把异常变成可恢复分支，把人类判断变成受管理的决策接口。Loop Engineering 的真正意义，不是发明一个更长的 Prompt，而是承认 Agent 已经进入需要系统工程治理的阶段。

可参考的文章与官方资料

LoopX GitHub Repository ：GitHub - huangruiteng/loopx: Long-horizon agent control plane for durable, governed work across Codex, Claude Code, and other harnesses. · GitHub
LoopX Documentation ：LoopX --- Keep the loop moving
Addy Osmani --- Loop Engineering ：AddyOsmani.com - Loop Engineering
Anthropic --- Effective harnesses for long-running agents ：Effective harnesses for long-running agents \ Anthropic
Anthropic --- Harness design for long-running applications ：Harness design for long-running application development \ Anthropic
LangGraph --- Persistence ：Persistence - Docs by LangChain
LangGraph --- Checkpointers / Durable execution ：Checkpointers - Docs by LangChain
Temporal --- Event History ：Event History | Temporal Documentation
Kubernetes --- Controllers ：Controllers | Kubernetes
OpenAI --- The next evolution of the Agents SDK ：https://openai.com/index/the-next-evolution-of-the-agents-sdk/
OpenAI --- New tools for building agents ：https://openai.com/index/new-tools-for-building-agents/
Long-running Agent Loop Engineering research (arXiv:2607.00038) ： $2607.00038$ Stop Hand-Holding Your Coding Agent: Engineering the Loops that Replace Step-by-Step Prompting