企业官网建设流程全解析

目录

一、“让 Agent 一直跑”不如“让它一直做对的事”

（一）长周期任务会把小误差放大成系统性漂移

1、短会话中的“偶发问题”，在多日运行中会变成必然问题

2、为什么“TODO.md + 超长系统提示词”迟早会遇到上限

（二）时间尺度改变之后，Agent 的系统性质也随之改变

1、从“推理循环”升级为“运行控制循环”

2、长期运行不是“更长的任务”，而是“更多次受控转移”

二、重新定义长期 Agent：执行器、触发器与控制平面的三层分离

（一）执行器只负责“这一轮怎么做”

（二）触发器只负责“什么时候再来一次”

（三）控制平面负责“跨轮次不允许丢的事实”

三、LoopX 带来的关键启发：状态不是记忆，治理不是提示词

（一）目标状态与当前状态必须分开

（二）把“需要用户判断”变成一等对象

（三）任务所有权必须可见，尤其是在多 Agent 场景

（四）配额不是成本统计，而是运行语义的一部分

四、从分布式系统借来的五个原则，比“无限上下文”更重要

（一）Durable Execution：把恢复能力建在系统里，而不是建在祈祷里

（二）Event Sourcing 与幂等：每次进展都要有“发生过”的证据

（三）Reconciliation：追求“持续逼近目标”，而不是“一次计划永远正确”

（四）Lease 与 Claim：并发协作必须有可过期的占有权

（五）补偿与前向恢复：现实世界的副作用通常无法真正撤销

五、设计一个真正能跑几天的 Agent Control Plane

（一）先定义权威对象，再讨论模型和框架

1、六类核心对象构成最小“长期状态内核”

1.1 Goal 与 Gate：定义方向与必须停下的位置

1.2 WorkItem 与 Claim：把“下一步”变成可领取工作

1.3 Evidence 与 Quota：定义可信进展与运行资格

2、状态要少而稳定，运行日志可以多而压缩

2.1 权威快照：只保存当前必须知道的事实

2.2 压缩事件与原始工件：保留因果，但不污染上下文

（二）把一次 Agent 运行定义为“有界、受权、可验证转移”

1、运行前：读取状态、检查门控、领取任务

2、运行后：先验证，再写回，最后记账

（三）四本账：目标账、行动账、证据账、预算账

六、人类不应该盯着每一步，但必须拥有关键判断权

（一）Human-in-the-loop 的难点不是“加一个确认按钮”

（二）把用户注意力也当成稀缺资源

七、多 Agent 协作的核心不是“群聊”，而是所有权、证据与交接

（一）同一任务只能有一个活动写入者

（二）交接必须是结构化 handoff，而不是一句“你继续”

八、调度不是“每 N 分钟运行一次”，而是基于信息增益的资源分配

（一）为什么固定心跳会成为长期系统的隐形成本中心

（二）用“有效转移率”而不是“调用次数”衡量自动化效率

九、可观测性：不要只看模型说了什么，要看状态为什么变了

（一）长周期 Agent 的 Trace 应围绕状态转移组织

（二）证据需要“新鲜度”和“适用范围”

十、安全与权限：长期自主性必须被“能力边界”包起来

（一）把“能调用工具”与“被授权执行动作”分开

（二）公共发布边界必须独立于工作状态

十一、不同技术路线并不是互斥，而是解决不同层次的问题

（一）LoopX、LangGraph、Temporal 与 Agent Runtime 的边界可以这样理解

（二）“更大上下文”只解决工作记忆，不解决治理一致性

十二、一个可复用的运行协议：Bounded Verified Transition

（一）把每轮执行固定成七步，可以显著降低长期漂移

1、READ：读取权威状态，而不是只读聊天历史

2、DECIDE：控制面先判断 run、wait、ask、replan 或 repair

3、CLAIM：领取一个足够小的工作切片

4、EXECUTE：执行器完成本轮动作

5、VALIDATE：用环境证据验证，不接受自我声明

6、WRITEBACK：原子更新状态并追加事件

7、ACCOUNT：最后更新配额与下一次调度提示

十三、如何衡量一个长周期 Agent 是否真的“可运营”

（一）不要用“连续运行了多少小时”作为核心指标

十四、渐进式落地：不要一开始就造“Agent Kubernetes”

（一）第一阶段：单 Agent + 明确 Goal + Evidence

（二）第二阶段：加入 Gate 与运行历史

（三）第三阶段：加入 Claim/Lease 与配额决策

（四）第四阶段：接入持久工作流、观测与策略引擎

十五、必须正视的边界：控制平面不是万能药

（一）结构化状态也可能成为新的错误源

（二）证据也可能被错误解释或被污染

（三）自动化越长，越要防止“自主性幻觉”

（四）不是所有任务都值得上控制平面

十六、结语：未来 Agent 的竞争，不只在模型能力，更在“持续正确”的系统能力

可参考文章与资料

干货分享，感谢您的阅读！

当 AI Agent 的任务从“几分钟内完成一次回答”扩展到“跨数小时、数天乃至更长周期持续推进一个目标”时，系统的主要风险会发生根本变化。问题不再只是模型是否足够聪明，而是目标能否持续保持一致、用户决策是否会被可靠保存、多个 Agent 是否会互相踩踏、每次声称的进展是否有证据、失败后能否恢复、权限是否会在长期运行中悄然越界，以及调度器会不会在没有有效进展时持续消耗预算。

LoopX 所强调的“长期 Agent 控制平面”提供了一个很有价值的观察窗口：把执行器与持久状态、治理和调度分离。本文在此基础上进一步提出一套面向长周期 Agent 的工程化框架——将 Agent 运行理解为“围绕目标状态进行的、受约束且可验证的离散状态转移”，并从分布式系统、控制论、工作流引擎与云原生控制器中抽取可复用原则，给出状态模型、运行协议、指标体系、架构边界和渐进式落地路线。

一、“让 Agent 一直跑”不如“让它一直做对的事”

（一）长周期任务会把小误差放大成系统性漂移

1、短会话中的“偶发问题”，在多日运行中会变成必然问题

在一次十分钟的编程会话里，模型忘记一句约束，通常还能依靠最近上下文、测试失败或用户即时纠正拉回来；但当任务持续几十个回合、跨越多个上下文窗口、模型版本、执行进程甚至不同 Agent 时，同样的遗忘会从“局部失误”变成“系统漂移”。原文对这一点抓得很准：真正击穿长周期 Agent 的，往往不是某一行代码写错，而是几十轮之后系统已经说不清楚“当前目标是什么、哪些决定已经做过、哪些范围明确排除、上一轮到底证明了什么”。这不是单纯的记忆容量问题，而是运行状态没有被工程化管理的问题。

长周期系统中至少存在四类会不断累积的漂移。第一类是目标漂移：用户中途调整优先级，旧目标仍残留在提示词、Todo 或历史消息中，后续 Agent 可能继续优化一个已经失效的方向。第二类是决策蒸发：某个关键分支需要人工选择，但问题只存在于聊天记录里，下一次自动运行没有可靠机制知道自己其实应当停下。第三类是证据断链：Agent 声称“已经修复”“已经验证”，但没有把测试结果、提交、报告、数据快照或可重放证据与状态变更绑定，几天后没人能判断这个结论仍然是否有效。第四类是权限漂移：最初允许的只是只读分析，后来自动化逐步开始写文件、改分支、调用外部系统，甚至触及发布或生产动作，而权限边界没有成为机器可检查的对象。

这四类漂移具有一个共同特征：它们都不是靠“再写一段更长的系统提示词”就能彻底解决的。提示词是一次推理调用的输入，而长周期治理需要的是跨调用持续存在、可查询、可更新、可审计、可冲突检测的状态。

2、为什么“TODO.md + 超长系统提示词”迟早会遇到上限

一个精心维护的TODO.md的确可以把单会话 Agent 的工作能力延伸很远，它也是任何长任务系统最值得保留的简单工具之一。但文件式记忆一旦承担了“状态内核”的职责，就会出现结构性困难：谁可以修改它？哪个字段是事实、哪个只是建议？一个 Todo 是用户责任还是 Agent 责任？某个任务是否已经被另一个 Agent 领取？一个完成状态是否附带有效证据？用户拒绝某个方案后，系统如何保证未来不会换个措辞再次执行？当文件被并发写入或回滚时，哪一版是权威状态？

更关键的是，普通 Todo 文件通常只有“要做什么”，缺少“为什么可以做、现在是否应该做、做完如何证明、失败如何恢复”。在短任务中，这些隐含判断由人脑和当前会话临时承担；在长任务中，它们必须显式化，否则系统会把不确定性变成自主性，把缺失的信息误当成许可。

（二）时间尺度改变之后，Agent 的系统性质也随之改变

1、从“推理循环”升级为“运行控制循环”

典型 Agent 可以抽象为“观察—思考—调用工具—读取结果—继续思考”的循环。这一模型适合描述单次任务中的智能行为，但不足以描述多天运行。因为长周期系统每次被唤醒时都要先回答一组更基础的问题：当前目标是否仍有效？我是否拥有执行这个动作的权限？是否存在尚未回答的人工门控？另一个 Agent 是否正在处理同一任务？上一次执行是否已写回并经过验证？当前证据是否过期？继续运行是否值得花费下一份预算？

因此，长周期 Agent 的“第一步”不应是调用模型，而应是一次控制面判定。只有控制面得出“本轮存在一个安全、必要、可验证的下一步”之后，执行器才获得一个有边界的工作切片。换句话说，Agent 不应该被视为一个无限运行的大脑，而应被视为一个可以反复启动的执行单元；真正连续的是状态和治理，而不是某个模型进程本身。

2、长期运行不是“更长的任务”，而是“更多次受控转移”

如果把一个三天目标理解成“一次执行三天的超级调用”，系统会天然追求更大的上下文、更强的模型和更长的进程存活时间；如果把它理解成“数百次有证据的状态转移”，系统设计的重心就会转向检查点、幂等、任务领取、门控、审计和恢复。后者更接近可靠软件系统的思维方式。

这也是本文最重要的定义：长周期 Agent 系统不是一个持续思考的模型，而是一个围绕持久目标反复产生“有界、受权、可验证状态转移”的控制系统。模型可以更换，运行时可以重启，Agent 可以交接，调度频率可以变化，只要权威状态和转移规则没有丢失，项目就仍然连续。

二、重新定义长期 Agent：执行器、触发器与控制平面的三层分离

（一）执行器只负责“这一轮怎么做”

Codex、Claude Code、Cursor、Shell Agent 或自研 Agent Runtime 擅长的事情，是读取当前工作区、理解局部目标、调用工具、修改代码、运行测试并形成一次回应。它们的强项是执行一个被限定的工作切片，而不是天然承担跨天治理。让执行器同时负责长期状态，往往会把聊天上下文、缓存、临时计划和真正的业务事实混在一起。

这意味着执行器应该是可替换的。今天用 A 模型完成实现，明天用 B 模型做审查，后天换成更便宜的模型做监控，只要三者都从同一份权威控制状态读取任务，并用同一协议写回证据，系统不应因此“失忆”。执行能力与持续性解耦，是长期系统能演化的前提。

（二）触发器只负责“什么时候再来一次”

心跳、Cron、队列、Webhook、人工点击、定时任务、CI 事件，本质上都只是触发机制。触发器最危险的误用，是把“时间到了”直接等价成“必须让 Agent 工作”。这会产生大量无意义轮次：没有新证据、仍在等待用户、依赖尚未完成、上轮已经卡死，却仍然按分钟消耗 token。

更合理的做法是：触发器只负责把“现在是否需要运行”的问题交给控制平面。控制平面返回run / wait / ask / replan / repair / quiet之类的机器可读结论，再由触发器决定是否真正启动执行器。于是“定时唤醒”与“定时消耗”被分开，调度器也获得了退避、暂停和按条件唤醒的空间。

（三）控制平面负责“跨轮次不允许丢的事实”

控制平面不是另一个更大的 Agent，也不应该偷偷代替用户做价值判断。它的职责是保存和解释跨轮次必须稳定存在的状态，包括长期目标、当前范围、任务队列、任务所有权、用户门控、证据、运行历史、预算、暂停状态、发布边界和恢复信息。LoopX 把自己定位为位于 Agent Runtime 之上的本地状态内核，这一分层思路非常关键：执行面产生动作，控制面决定动作是否应该发生，以及发生后什么才算被系统接受。

一个最小可用控制平面至少应该保存六类对象：Goal（目标与范围）、Gate（需要人类或外部权威判断的门）、Todo/WorkItem（可执行任务）、Claim/Lease（谁拥有当前工作切片）、Evidence/Run（发生了什么以及凭什么相信）、Quota/Policy（现在是否值得继续消耗资源）。如果还涉及公共发布或敏感数据，还需要独立的Publication Boundary或Data Policy，避免把本地运行状态误当成可公开内容。

三、LoopX 带来的关键启发：状态不是记忆，治理不是提示词

（一）目标状态与当前状态必须分开

在可靠控制系统中，“希望系统最终到达哪里”与“系统现在在哪里”是两份不同的信息。Kubernetes 控制器把desired state与current state分离，然后不断通过控制环让现实靠近目标。这一思想对长周期 Agent 同样适用：Objective不是当前任务清单，Next Action也不是最终目标。目标可以数天保持不变，而下一步可以随着证据不断调整。

如果把目标、计划和当前动作混成一段自然语言，Agent 每次总结都会重新解释它，最终造成语义漂移。更稳定的设计是：长期目标是慢变量，当前工作切片是快变量；更新长期目标需要更高权限和明确理由，而更新下一步可以由验证后的运行结果自动完成。这样，即使策略改变，系统也知道“改变的是路线，而不是终点”；如果终点真的变了，也能保存变更原因和时间。

（二）把“需要用户判断”变成一等对象

聊天系统最常见的失败之一，是 Agent 在消息里问了一个关键问题，然后自动化继续运行，后续回合却没有可靠地意识到这个问题仍未回答。长期系统不能把这种状态藏在 transcript 中。用户门控必须具备 ID、问题文本、阻塞范围、创建时间、所需角色、可接受回答、当前状态和解决证据。

门控的关键不是“停”，而是准确地停在应该停的动作上。一个发布审批未完成，不代表所有只读分析都必须停止；一个涉及生产写入的门被阻塞，也不意味着整理测试证据、生成候选方案、压缩上下文都必须冻结。LoopX 对 safe fallback 的强调很有价值：把“被门控的动作域”与“仍然安全的旁路工作”分开，可以避免系统在“全停”和“擅自继续”之间二选一。

（三）任务所有权必须可见，尤其是在多 Agent 场景

多 Agent 的最大幻觉是“并行一定更快”。如果没有所有权，两个 Agent 很可能同时修改同一文件、重复调查同一问题、互相覆盖状态，或者都以为“另一个会处理”。因此任务不能只有status=open，还需要claimed_by、租约时间、能力要求、作用域和交接条件。

任务租约比永久所有权更适合 Agent。某个 Agent 领取任务后只能在有限时间或有限轮次内拥有执行权；超时、失联、验证失败后，控制平面可以释放或重新分配。这样既防止重复工作，又避免“死 Agent”永久占坑。对跨模型协作来说，身份也不必等同于固定领导者，可以按任务动态分配实现、审查、验证、监控等角色。

（四）配额不是成本统计，而是运行语义的一部分

传统系统往往在事后统计 token、调用次数和费用；长周期 Agent 更需要在执行前判断“这轮是否值得运行”。当系统仍在等待外部证据、没有可验证的新动作、同一监控结果连续多次无变化时，再调用一次强模型不是智能，而是浪费。

因此配额应当与状态机结合。配额决策不仅看“还剩多少钱”，还应看当前工作通道、等待原因、证据新鲜度、最近无进展次数、模型成本、预计信息增益和用户注意力成本。一个成熟的should-run不是简单的限流器，而是计算资源分配器：它决定当前目标是否应该获得下一次自动计算机会，以及应该用什么级别的执行器去完成。

四、从分布式系统借来的五个原则，比“无限上下文”更重要

（一）Durable Execution：把恢复能力建在系统里，而不是建在祈祷里

Temporal 一类 Durable Execution 系统的核心不是“进程永不崩”，而是即使进程、网络或基础设施中断，工作流也可以依据持久事件历史恢复到可靠位置。对 Agent 而言，这意味着不要依赖“这个 Python 进程一直在”“这个聊天线程一直可读”“这个浏览器标签一直在线”。真正要持久化的是可恢复的业务状态和已接受的执行结果。

一个长周期 Agent 的恢复点应当至少包含：当前目标版本、已解决/未解决 Gate、可执行任务及其所有权、最近一次被接受的证据、外部副作用的回执、预算状态和下一次调度条件。上下文摘要可以重建，模型思维过程不必持久化，但权威事实必须可以从状态与事件中重新投影出来。

（二）Event Sourcing 与幂等：每次进展都要有“发生过”的证据

长周期系统最怕重复执行。网络超时后，Agent 不知道提交 PR 是否成功；模型重试后再次调用同一 API；调度器崩溃后重新消费上一条任务。如果外部动作不是幂等的，就会产生重复邮件、重复发布、重复扣费或冲突提交。

因此一次 Agent 转移最好有稳定的turn_id或operation_id，并遵循“先检查—执行—读取回执—验证—写回”的顺序。对于重要动作，控制平面应保存 append-only 事件：谁在何时基于哪个状态版本执行了什么、产生了什么外部效果、验证结果是什么、状态从哪个版本转到了哪个版本。事件日志不等于把所有聊天记录永久保存；它应当是压缩后的、可审计的因果账本。

（三）Reconciliation：追求“持续逼近目标”，而不是“一次计划永远正确”

Kubernetes 的控制器模式提供了一个非常适合 Agent 的类比：控制器持续观察当前状态，并采取动作使其靠近期望状态，而不是假设第一次计划会完整执行到底。Agent 计划同样应该被视为可替换的控制策略，而不是契约本身。

当证据变化、依赖失败、用户修改范围时，控制平面应该允许安全地replan，同时保留哪些目标未变、哪些假设被推翻、哪些工作仍然有效。这样系统能够“重规划但不失忆”。如果连续多轮没有状态推进，系统也不应该机械重试同一步，而应触发重规划、降级模型、请求人工或进入等待。

（四）Lease 与 Claim：并发协作必须有可过期的占有权

分布式系统中，租约常用于解决“谁当前拥有资源”的问题。长周期多 Agent 协作也需要类似机制：Agent A 领取“修复解析器”任务，控制面给出 30 分钟或 3 个回合的租约；Agent B 看到该任务已被领取，只能选择其他工作或成为审查者。A 如果无响应，租约过期后任务重新开放。

租约还应和写权限绑定。领取任务不等于获得任意仓库写权限，而只是获得特定作用域内的行动许可。更细致的系统可以把能力声明、文件范围、环境、外部系统权限一起放入租约，形成“最小工作授权”。

（五）补偿与前向恢复：现实世界的副作用通常无法真正撤销

Agent 系统一旦开始发邮件、改工单、提交代码、修改远程配置，就进入了分布式事务世界。很多动作无法“回到过去”，只能做补偿：发更正、回滚提交、创建反向变更、撤销授权、恢复快照。因此治理设计不应假设“失败就 rollback 一切”，而应为高风险动作定义补偿路径和人工审批。

这也解释了为什么重要动作必须有前置 Gate。越难补偿、越不可逆、越影响真实用户的动作，越不应该依赖模型在最后一刻“自己判断一下”。

受控状态转移：每次自动运行先经过 Gate、任务所有权、证据新鲜度与配额判断；只有验证后的结果才进入持久状态。

五、设计一个真正能跑几天的 Agent Control Plane

（一）先定义权威对象，再讨论模型和框架

1、六类核心对象构成最小“长期状态内核”

一个可落地的控制平面可以从以下六类对象开始，而不是先上复杂框架。为了避免“结构化”本身变成新的复杂度，可以进一步把这些对象按职责拆成三组。

1.1 Goal 与 Gate：定义方向与必须停下的位置

Goal 负责保存目标、范围与版本，是相对稳定的“慢变量”；Gate 负责保存哪些判断不能由执行器自行越过。两者组合解决的是长期系统最根本的授权问题：我要去哪里，以及什么情况下必须停下来等一个更高权威的决定。

1.2 WorkItem 与 Claim：把“下一步”变成可领取工作

WorkItem 把抽象目标切成可验证的执行单元，Claim/Lease 则把“谁可以处理这一单元”机器化。它们共同把自然语言里的“接下来做这个”升级成可并发协调、可过期回收、可冲突检测的工作对象。

1.3 Evidence 与 Quota：定义可信进展与运行资格

Evidence/Run 解决“为什么相信状态真的推进了”，Quota/Policy 解决“现在是否值得再花一次计算资源”。前者让完成声明变成可审计事实，后者让自动化从固定心跳升级为基于状态和信息增益的资源分配。

这些对象的设计目标不是覆盖所有业务，而是把最容易在长时间尺度上丢失的事实从自然语言里提取出来。所有复杂能力——多 Agent、自动报告、自愈、监控、研究迭代——都可以在这些原语之上生长。

2、状态要少而稳定，运行日志可以多而压缩

长期系统经常犯两个相反错误：要么只保存一段“当前摘要”，导致历史因果丢失；要么保存所有消息和工具输出，最终变成没人能读、模型也不敢加载的日志海洋。更好的结构是把数据分成三层：权威快照、压缩事件、原始工件。

2.1 权威快照：只保存当前必须知道的事实

权威快照应足够小，使任何新 Agent 在一次读取后就能回答当前目标、未解决 Gate、可执行任务、所有权、最新有效证据和预算状态。它不是完整历史，而是“此刻做决策所需的最小一致视图”。

2.2 压缩事件与原始工件：保留因果，但不污染上下文

压缩事件保存为什么从 A 变到 B；原始工件如测试报告、构建日志、diff、实验结果放在独立存储中，通过哈希、路径或 URL 引用。控制平面不应把几百 MB 日志塞进 Agent 上下文，只需告诉执行器“哪个证据是当前被接受的、在哪里、生成于哪个状态版本”。这样既保留恢复与审计所需的因果链，也避免把原始噪声重新灌回模型工作记忆。

（二）把一次 Agent 运行定义为“有界、受权、可验证转移”

1、运行前：读取状态、检查门控、领取任务

每轮执行器启动后不应立刻“继续上次工作”，而应重新读取权威状态并做 preflight。至少检查：目标版本是否变化；当前是否有阻塞本任务的 Gate；工作项是否仍然开放；是否已被其他 Agent 领取；所需能力和权限是否可用；依赖证据是否新鲜；本轮是否在预算内。

只有这些条件通过后，执行器才能领取一个足够小的工作切片。小切片的标准不是“代码行数少”，而是能在一轮内形成明确验证。例如“把整个支付系统重构完”不是好切片；“为退款回调补充幂等键并让指定集成测试通过”是可验证切片。

2、运行后：先验证，再写回，最后记账

Agent 完成动作后，不能直接把 Todo 标记为 done。必须先生成或读取验证证据：测试通过、接口回读一致、文档链接可访问、目标指标改善、人工审查通过等。只有验证通过，控制平面才接受状态转移。

正确的顺序应接近：effect → readback → validate → writeback → account。把配额扣费放在最后也有语义价值：没有完成可验证转移的 quiet skip、preflight fail 或纯重规划，不应和真正产出同等计费。即便具体产品不采用这种计费策略，系统也应区分“调用发生了”和“有效进展发生了”。

（三）四本账：目标账、行动账、证据账、预算账

长期 Agent 很适合用“四本账”理解。目标账回答为什么做、范围是什么；行动账回答谁在做、做到了哪一步；证据账回答为什么相信进展；预算账回答继续推进是否值得。任何一次重要状态更新都应能在四本账中形成一致映射。

比如一次代码修复：目标账显示“修复解析器在异常 Unicode 输入下崩溃”；行动账显示 Agent A 领取了parser-unicode-01；证据账保存新增测试、提交哈希和测试结果；预算账记录本轮使用了一个执行槽并建议下一轮等待 CI。缺少任一账本，都可能出现“做了但不知道为什么”“声称完成但没证据”“多个人都在做”“没有进展却不停花钱”。

六、人类不应该盯着每一步，但必须拥有关键判断权

（一）Human-in-the-loop 的难点不是“加一个确认按钮”

真正有效的人工门控需要解决三个问题：什么时候打断人、打断人时问什么、人在不在线时系统还能做什么。如果每个文件写入都要确认，自动化价值会消失；如果只有最终发布前确认，中间的高风险分支可能已经造成大量返工。

因此 Gate 应按决策类型与动作作用域设计，而不是按“每一步/不每一步”粗暴划分。典型门包括：目标变更门、范围扩张门、隐私数据门、生产写入门、外部沟通门、成本突增门、不可逆动作门。每个 Gate 都要说明“被阻塞的具体动作”，这样系统可以在等待时继续完成不依赖该判断的安全工作。

（二）把用户注意力也当成稀缺资源

长周期 Agent 如果每十分钟发一次“请确认”，对用户而言并不比手工执行更省心。成熟控制平面应优化的不只是 token 成本，还包括Human Attention Cost。可以给 Gate 设置聚合窗口，把多个低耦合问题合成一次请求；可以在出现关键新证据时再唤醒用户；可以对相同未解决 Gate 做去重，避免每个 heartbeat 重复催促。

一个好的自动化系统应该让用户看到“现在为什么需要我”，而不是“Agent 又卡住了”。理想的 Gate 消息应包含：需要你决定的问题、可选方案、每个方案的后果、如果暂不处理系统会继续什么安全工作、最晚何时需要回答。这样用户承担的是判断，而不是日志阅读。

七、多 Agent 协作的核心不是“群聊”，而是所有权、证据与交接

（一）同一任务只能有一个活动写入者

多 Agent 最基础的规则是：一个可变作用域在同一时间最好只有一个活动写入者。可以允许多个 Agent 并行读取、研究和审查，但对同一文件集、同一远程资源或同一业务动作进行写入时，需要 Claim/Lease。否则并发冲突会把“增加算力”变成“增加返工”。

对于代码场景，可以把任务作用域映射为分支、目录或文件集合；对于运营场景，可以映射为客户、工单、数据集或发布渠道。控制平面不需要精确理解所有业务，只需要能判断两个 Claim 是否存在冲突，并在冲突时排队、拆分或升级给人。

（二）交接必须是结构化 handoff，而不是一句“你继续”

Agent A 把工作交给 Agent B 时，至少应提供：目标版本、已完成工作、未完成工作、当前假设、关键证据、已知风险、下一步建议、不得重复的动作、可写作用域。这样的 handoff 可以自动生成，但必须从权威状态与证据账本投影，而不是让模型凭聊天记忆自由总结。

交接做得好，换模型、换工具甚至换人都不会让项目重置；交接做得差，多 Agent 只是把上下文损失从“隔天一次”变成“每次交接一次”。

八、调度不是“每 N 分钟运行一次”，而是基于信息增益的资源分配

（一）为什么固定心跳会成为长期系统的隐形成本中心

固定频率心跳的优点是简单，但它不理解项目状态。一个依赖外部 CI 的任务可能 30 分钟没有新信息；一个等待用户批准的发布任务可能一整晚不应运行；一个监控任务在连续十次相同结果后，应当降低检查频率。若所有目标都每五分钟唤醒强模型，系统的绝大多数成本会花在“确认什么都没变”上。

因此控制平面应该输出scheduler_hint：立即运行、短等待、指数退避、等待事件、等待人工、暂停、低成本探测、需要重规划等。调度器只是消费这个提示，不需要理解 Agent 语义。这样可以将“语义判断”留在控制面，将“时间触发”留在调度层。

（二）用“有效转移率”而不是“调用次数”衡量自动化效率

可以定义一个简单指标：

Verified Transition Ratio = 被验证并接受的状态转移次数 / 自动执行轮次

如果一个系统一天运行 200 次，但只有 8 次产生可验证进展，剩下 192 次都在重复读状态、确认无变化或产生无法接受的尝试，那么它看上去“非常活跃”，其实只是调度策略很差。反之，一个系统只运行 20 次却有 14 次有效转移，可能更接近真正的长期自动化。

进一步还可以计算Token per Verified Transition、Human Interruptions per Milestone、Stale Evidence Reuse Rate、Duplicate Work Rate。这些指标比“Agent 工作了多少小时”更能说明系统是否成熟。

九、可观测性：不要只看模型说了什么，要看状态为什么变了

（一）长周期 Agent 的 Trace 应围绕状态转移组织

传统 LLM Observability 关注 prompt、completion、latency、token 和工具调用；长期控制平面还需要看到“这一轮基于哪个状态版本、读取了哪些 Gate、领取了哪个任务、产生了哪些副作用、哪条证据让系统接受了转移”。也就是说，Trace 的核心实体应从“请求”提升到“转移”。

一个推荐的 Trace Span 可以包含：goal_id、goal_version、turn_id、agent_id、work_item_id、claim_id、decision、effect_refs、validation_refs、state_before_hash、state_after_hash、quota_cost。这样当系统两天后出现异常时，工程师可以从状态变化反向定位到具体执行轮次，而不是在海量聊天里搜索关键词。

（二）证据需要“新鲜度”和“适用范围”

不是所有历史证据都永远有效。一次测试通过可能只适用于某个 commit；一个网页结论可能在一周后过期；一个用户授权可能只针对某次发布。因此 Evidence 不应只有text，还需要produced_at、valid_for、source_revision、expires_at、confidence或验证方法。

长期 Agent 的一个高级能力，就是在行动前发现“我依赖的证据已经过期”，然后选择重新验证，而不是继续把旧结论当成事实。这个能力比单纯的长记忆更重要，因为它承认世界会变化。

十、安全与权限：长期自主性必须被“能力边界”包起来

（一）把“能调用工具”与“被授权执行动作”分开

一个 Agent 运行环境拥有 shell，并不意味着它有权对所有文件写入；拥有浏览器，也不意味着它有权登录任何账户；能调用部署 CLI，更不意味着本轮目标允许生产发布。长期系统如果只在系统提示词里写“不要做危险操作”，随着上下文压缩和工具复杂度增长，边界会越来越脆弱。

更稳妥的方式是把动作按能力分类，并由控制面发放本轮最小授权。例如：filesystem_read、repo_write:branch_x、network_read:public、ticket_write:project_y、production_write。执行器在调用高风险工具前需要携带与当前 Claim 绑定的能力令牌或通过策略检查。即使模型产生越界意图，工具层也应拒绝。

（二）公共发布边界必须独立于工作状态

原文特别提醒了.loopx/、Active Goal State 等本地控制数据不应直接提交进公开仓库，这背后是一个更普遍的问题：运行状态天然包含比最终产物更多的私人信息。本地路径、失败日志、访问令牌片段、内部项目名、用户偏好、未发布方案，都可能进入长期状态。

因此“可发布”不是“当前文件能打开”这么简单，而应有独立的 public/private 检查。一个成熟流程在生成 README、报告、博客、PR 描述或对外邮件前，应对引用的工件做敏感信息扫描，并且只从公共安全投影中取数据。控制平面应默认把内部状态视为私有，只有显式白名单字段能够进入外部输出。

十一、不同技术路线并不是互斥，而是解决不同层次的问题

（一）LoopX、LangGraph、Temporal 与 Agent Runtime 的边界可以这样理解

长期 Agent 领域很容易陷入“哪个框架能跑更久”的比较，但工程上更有价值的是先分层。LangGraph 官方把自己定位为面向长运行、有状态 Agent 的低层编排运行时，强调 durable execution、persistence 和 human-in-the-loop；Temporal 则提供更通用的 Durable Execution 基础设施，通过事件历史与重放保证工作流在故障后继续；LoopX 更强调位于不同 Agent Harness 之上的治理与状态控制面；具体的 Coding Agent 或 Tool-using Agent 则负责本轮推理与动作。

它们可以组合，而不是替代。例如：用 Temporal 保证跨服务工作流可靠恢复，用 LangGraph 表达某个 Agent 子流程的状态图，用 LoopX 类控制面保存用户 Gate、任务所有权和长期治理状态，再让 Codex/Claude Code 执行具体代码变更。是否需要这么多层取决于复杂度；关键是不要让一个层次偷偷承担另一个层次的职责。

（二）“更大上下文”只解决工作记忆，不解决治理一致性

更大的上下文窗口当然有价值，它减少摘要损失，让模型在单次调用中看到更多历史；长期记忆、向量检索、代码记忆也可以降低重复调查。但这些技术主要解决“模型能否找回信息”，而不是“哪条信息有权威性”。

如果上下文里同时存在旧目标、新目标、两份冲突 Todo 和三次不同版本的测试结论，窗口再大只会让模型看到更多冲突。控制平面的作用是把这些冲突解析成结构化状态：哪个目标版本有效、哪个任务已废弃、哪个证据已过期、哪个决策仍在等待。记忆负责召回，控制平面负责裁决。这是两类不同问题。

十二、一个可复用的运行协议：Bounded Verified Transition

（一）把每轮执行固定成七步，可以显著降低长期漂移

1、READ：读取权威状态，而不是只读聊天历史

读取当前 Goal、Gate、WorkItem、Claim、Evidence、Quota。对关键状态附带版本号或哈希，避免在过期快照上执行。

2、DECIDE：控制面先判断 run、wait、ask、replan 或 repair

如果本轮没有合法可验证动作，系统可以安静地等待，而不是为了“保持活跃”强行调用模型。

3、CLAIM：领取一个足够小的工作切片

Claim 要限定作用域、能力、租约与冲突关系。多 Agent 环境中，没有 Claim 就不进行写入型工作。

4、EXECUTE：执行器完成本轮动作

执行器可以自由使用模型推理与工具，但动作边界由 Claim 和 Capability 决定。对不可逆操作必须满足额外 Gate。

5、VALIDATE：用环境证据验证，不接受自我声明

代码用测试、接口用回读、研究用可重放数据、运营用外部状态。Agent 的“我认为完成了”不是证据。

6、WRITEBACK：原子更新状态并追加事件

只有验证通过的结果才进入权威状态。写回时同时记录状态前后版本、证据引用、下一步和未解决风险。

7、ACCOUNT：最后更新配额与下一次调度提示

已完成且被接受的工作消耗正常执行额度；quiet skip、等待和重复回执应尽量低成本或零成本处理。

下面是一段高度简化的伪代码，用来表达这一协议的边界，而不是绑定某个框架：

state = control_plane.read(goal_id) decision = control_plane.should_run(state, agent_id) if decision.kind in {"wait", "quiet"}: return decision if decision.kind == "ask_user": return surface_gate(decision.gate) lease = control_plane.claim(decision.work_item, agent_id) result = agent.execute(lease.scope, state.context_projection) validation = validator.check(result, lease.acceptance_criteria) if not validation.ok: control_plane.append_event("validation_failed", result, validation) return control_plane.replan_or_repair(goal_id) receipt = control_plane.commit_transition( before_version=state.version, claim=lease, result=result, evidence=validation.evidence, ) control_plane.account(receipt) return receipt.next_action

这里最重要的不是代码，而是顺序。特别是“验证在写回之前”“配额在有效写回之后”“人工 Gate 在执行之前”，这三个顺序能消除大量长期自动化中的灰色状态。

Bounded Verified Transition（BVT）协议：长期自主不是无限循环，而是不断重复受控、可验证的七步小循环。

十三、如何衡量一个长周期 Agent 是否真的“可运营”

（一）不要用“连续运行了多少小时”作为核心指标

一个 Agent 连续在线四天，并不代表它连续创造了四天价值。可能大部分时间都在等待、重复检查或重新阅读上下文。运营指标应围绕“有效状态转移”与“治理质量”建立。

建议至少跟踪以下指标：

• Verified Transition Ratio（VTR）：有效转移数 / 自动轮次，衡量调度与执行是否真的产生进展。

• Token per Verified Transition（TPVT）：每次有效转移消耗的 token，衡量计算效率。

• Duplicate Work Rate：被判定为重复或冲突的工作占比，反映任务所有权质量。

• Stale Evidence Reuse Rate：使用已过期或不匹配版本证据的比例，反映证据治理能力。

• Mean Replan Latency：发现阻塞到形成新可执行路线的平均时间，反映恢复能力。

• Human Attention per Milestone：每完成一个里程碑需要用户介入多少次，反映自动化是否真的节省管理成本。

• Unsafe Action Prevented / Attempted：策略层阻止的越界动作及尝试量，反映权限边界是否发挥作用。

• Recovery Success Rate：进程/模型/运行时中断后，能够在不重复副作用的情况下继续的比例。

这些指标还可以帮助团队做模型路由：高价值、高不确定性的重规划使用强模型；低风险监控使用便宜模型或规则；纯状态检查甚至无需 LLM。长期系统的成本优势往往来自让模型只在真正需要语义判断的时候出现。

十四、渐进式落地：不要一开始就造“Agent Kubernetes”

渐进式成熟路线：从“把证据写下来”开始，逐层增加门控、租约、配额和 durable workflow，避免过早复杂化。

（一）第一阶段：单 Agent + 明确 Goal + Evidence

最小改造不是上控制平台，而是先把目标与证据结构化。为长任务建立一个稳定 Goal 文档，每轮只允许一个小工作切片，要求完成必须附带测试、提交、报告或可重放结果。此时仍可以用普通文件保存状态，但要避免让聊天摘要成为唯一真相。

（二）第二阶段：加入 Gate 与运行历史

当任务开始依赖用户判断、发布权限或外部条件时，把 Gate 从聊天中抽出，给它稳定 ID 和阻塞范围；同时把每轮执行压缩成结构化 Run 事件。做到这一层，系统已经能明显减少“问过但忘了”“做过但没证据”的问题。

（三）第三阶段：加入 Claim/Lease 与配额决策

只有当多个 Agent、多个自动触发器开始同时工作时，才需要任务租约和调度治理。先解决“谁能做”和“现在值不值得做”，再追求复杂并行。配额也可以从简单规则开始：等待用户不运行、连续无变化指数退避、CI 未完成只做轻量探测。

（四）第四阶段：接入持久工作流、观测与策略引擎

当系统跨服务、跨天、跨大量外部副作用时，再考虑 Temporal 类 Durable Workflow、完整 tracing、策略引擎、权限令牌、补偿流程与正式 SLO。此时控制平面已经有稳定对象模型，可以把可靠性能力逐步替换到更专业的基础设施，而不是推倒重来。

十五、必须正视的边界：控制平面不是万能药

（一）结构化状态也可能成为新的错误源

控制平面一旦被视为 source of truth，它自己的写入错误、迁移错误、并发冲突和陈旧投影就会变得严重。因此状态更新要尽可能小、可验证、可版本化；关键决策要有来源；读模型与写模型之间要能检测漂移。不能因为“状态已经结构化”就默认它永远正确。

（二）证据也可能被错误解释或被污染

测试通过不等于业务正确，网页抓取不等于事实真相，另一个 Agent 的总结也不等于独立证据。Evidence 需要来源分级和验证策略。高风险决策尽量依赖可重复、可回读、可交叉验证的信号，而不是单一模型输出。

（三）自动化越长，越要防止“自主性幻觉”

一个系统能够自己运行几天，并不代表它应该拥有更大的决策权。事实上，运行时间越长，环境变化、目标变更和意外副作用越多，越需要明确边界。长期自治的正确方向不是“把人从系统里删除”，而是把人的角色从每步操作员提升为目标所有者、风险批准者和异常裁决者。

（四）不是所有任务都值得上控制平面

如果任务能在一次会话完成，没有外部副作用，没有多 Agent，没有长等待，也不需要人工审批，那么一份清晰提示词和 Todo 文件可能已经是更好的工程方案。控制平面有固定复杂度，只有当任务寿命、并发、风险和成本达到一定程度，它才会产生净收益。

十六、结语：未来 Agent 的竞争，不只在模型能力，更在“持续正确”的系统能力

LoopX 之所以值得关注，并不是因为它发明了某个前所未见的算法，而是因为它把一个越来越普遍的问题说清楚了：当 Agent 需要跨越多轮、多天、多执行器持续工作时，聊天记录不再是合格的系统状态，定时器也不再是合格的调度策略。长期工作需要一个独立于模型的治理层，保存目标、门控、所有权、证据与预算，并让每次自动执行变成一个小而可验证的状态转移。

进一步看，这并不是“Agent 专属”的新问题。Durable Execution 告诉我们如何跨故障保存进度，事件日志告诉我们如何建立因果与审计，Kubernetes 控制器告诉我们如何围绕期望状态持续协调，租约告诉我们如何管理并发所有权，Human-in-the-loop 告诉我们如何把机器擅长的执行与人类必须保留的判断分开。Agent 系统真正的新部分，是把这些成熟原则重新组合到一个“部分由概率模型决策、部分由确定性规则治理”的运行环境中。

因此，判断一个长周期 Agent 架构是否成熟，可以问五个问题：目标是否有独立于聊天的权威表示？每次动作是否有清晰授权？每次进展是否有可验证证据？失败或换 Agent 后能否不重复副作用地恢复？系统能否解释为什么下一轮应该运行或不运行？如果这五个问题没有答案，单纯增加上下文、模型规模或心跳频率，只是在把脆弱系统跑得更久。

真正可运营的长期 Agent，不是“永不停机的智能体”，而是一个可以频繁停止、可靠恢复、持续校准、始终可问责的控制系统。当我们把目标、状态、权限、证据和预算从模型脑海里拿出来，Agent 才真正从一次性助手走向可管理的数字执行系统。

可参考文章与资料

1. ArshTechPro：LoopX: A Control Plane for AI Agents That Have to Keep Working for Days

2. LoopX GitHub Repository

3. LoopX Architecture

4. LoopX State Interaction Model

5. LoopX Quota Allocation

6. LangGraph Overview：Long-running, Stateful Agent Orchestration

7. Temporal Documentation：Workflow Execution and Durable Execution

8. Kubernetes Documentation：Controllers and Control Loops

9. Anthropic：Building Effective AI Agents

10. OpenTelemetry：Traces