Agent持续执行与协作：打造长期工作系统的完整指南

一个 Agent 完成一次模型调用，并不等于它能长期工作。

复杂任务可能跨越多个 Turn、多个上下文窗口、多个进程甚至多个会话。中间会遇到工具超时、网络中断、上下文耗尽、权限等待、测试失败、用户改方向和部分任务成功。没有持续执行、协作和验证机制，Agent 很容易在“看起来快完成”的地方丢失状态。

本文把一项长期任务从创建到交付完整走一遍，重点讲三个问题：怎样让它跨时间继续，怎样让人和其他 Agent 介入，怎样证明最终结果真的正确。

一、持续执行不是无限循环

持续执行的目标是让任务跨越时间和故障继续推进，而不是让 Agent 永远不停止。

典型持续执行原语包括：

• 持久化任务目标；
• Turn 和 Thread 生命周期；
• 计划和进度状态；
• 自动续跑和事件唤醒；
• 定时器、等待和外部事件；
• 重试、退避和超时；
• 取消和安全终止；
• 中间检查点；
• Token、时间、费用和并发预算；
• 阻塞、暂停、限额和完成状态。

这些机制共同回答：任务现在在哪里，为什么继续，什么情况下暂停，发生故障后从哪里恢复。

二、持久化目标和任务状态

如果目标只存在当前上下文中，进程退出或压缩历史后，Agent 可能忘记自己为什么工作。目标记录至少需要：

{
  "goal_id": "goal-20260730-001",
  "title": "完成项目上线前检查",
  "success_conditions": [
    "构建成功",
    "核心页面可访问",
    "数据库备份可恢复"
  ],
  "status": "in_progress",
  "current_step": "检查部署配置",
  "blocked_reason": null,
  "budget": {
    "max_minutes": 60,
    "max_retries": 3
  }
}

目标状态应该和模型回复分开保存。模型可以建议“我认为完成了”，但 Harness 仍然要根据测试、审批和完成审计决定是否将状态改为 completed。

三、检查点让恢复变得可能

长任务不能只在最后保存结果。每个独立阶段结束后都应该写检查点：

检查点 1：完成环境检查
检查点 2：完成计划和审批
检查点 3：完成代码修改
检查点 4：完成测试
检查点 5：完成交付物和回滚记录

检查点至少保存：当前版本、已完成步骤、关键输出路径、失败次数、用户决定和下一步动作。恢复时先读取检查点，再重新观察当前环境，不能盲目重复上一次有副作用的动作。

四、重试、退避和失败分类

不是所有失败都应该重试：

指数退避可以避免多个任务同时重试把服务压垮：

import random


def backoff_seconds(attempt, base=2, maximum=60):
    delay = min(maximum, base ** attempt)
    return delay + random.uniform(0, 1)

实际系统还需要全局并发限制、最大重试次数和取消机制。重试时必须考虑动作是否幂等，不能把“再执行一次”当作通用修复方法。

五、等待和事件唤醒

很多任务不是失败，而是在等待外部条件：用户批准、文件上传、CI 完成、定时窗口、第三方回调或人工补充信息。

等待状态应该被持久化：

waiting_for_user
waiting_for_ci
waiting_for_timer
waiting_for_webhook

进程退出后，任务仍然知道自己在等待什么。事件到达时，Harness 再恢复对应任务，而不是让一个进程一直占着线程和上下文。

六、人机协作不是只展示最终答案

长期 Agent 需要在执行过程中向用户提供可理解的进展：当前做了什么、接下来做什么、遇到什么阻塞、是否需要审批。

一条有效进度消息应该包含：

已完成：读取项目结构并记录构建基线。
当前：检查生产环境变量，未修改文件。
发现：缺少数据库连接配置，无法继续部署。
需要你决定：提供测试环境配置，或先只部署静态页面。

用户还应该能够中途 Steering：改变目标、缩小范围、暂停、取消或要求先解释计划。新的指令不能简单覆盖旧状态，Harness 需要记录它影响了哪个目标和哪一个步骤。

七、多 Agent 协作需要通信协议

多 Agent 的协作至少需要：

• 父子任务关系；
• 任务输入和输出格式；
• 共享状态或工作账本；
• 并发限制；
• 消息和状态查询；
• 结果汇总和冲突发现；
• 责任归属。

一个主 Agent 可以委派三个独立任务：

主任务：准备发布说明。

子 Agent A：读取 Git Diff，输出用户可见变化。
子 Agent B：读取测试和部署日志，输出验证结果。
子 Agent C：检查破坏性变更和回滚风险。

主 Agent：汇总结果，处理冲突，生成最终文档。

子 Agent 不应该默认拥有主 Agent 的全部权限。它们最好只读取所需文件，输出结构化结果，由主流程决定是否执行下一步。

八、验证是独立的反馈回路

Agent 采取动作后，必须观察结果，再决定继续还是修复：

提出方案
    |
执行动作
    |
运行测试 / 观察页面 / 检查数据
    |
读取外部证据
    |
通过 -> 进入下一步
失败 -> 定位原因 -> 最小修复 -> 重新验证

验证原语包括：

• 单元测试、集成测试和端到端测试；
• 编译、类型检查和 Lint；
• 命令退出码和日志；
• 浏览器页面、网络请求和截图；
• 数据库一致性和迁移检查；
• 独立 Reviewer 或 Critic Agent；
• Diff、分支、提交和可回滚版本；
• 文档、报表、图片和其他 Artifact。

模型的自我评价只能作为线索，不能替代外部证据。一个页面“看起来没问题”，不等于所有资源加载成功；一条测试命令返回 0，也不代表没有未覆盖的关键路径。

九、完成审计要逐项对照

任务结束时，Harness 应该重新读取完成条件，逐项建立证据：

完成条件 1：构建成功
证据：CI Run 381，exit code 0

完成条件 2：核心页面可访问
证据：浏览器检查 /dashboard、/settings，截图和网络请求无错误

完成条件 3：数据库备份可恢复
证据：恢复到临时库，完整性检查通过，关键记录可读

未完成：生产环境回滚演练尚未执行

如果某个条件没有证据，就应该标记为未验证，而不是在最终回答里省略。完成审计是把“做过动作”和“达到目标”区分开的关键。

十、交付物要可审查和可继续使用

Agent 的交付不应该只有一段聊天文本。根据任务类型，可以交付：

• 修改后的文件和 Patch；
• 测试报告和日志摘要；
• 版本号、Commit 或 Pull Request；
• 可下载的报告、表格和图片；
• 部署记录、配置说明和回滚步骤；
• 数据库迁移和恢复说明；
• 未解决问题和下一步建议。

每个交付物都要说明生成时间、输入范围、验证方法和已知限制。文件名和目录结构也要稳定，方便后续任务继续读取。

十一、失败恢复和安全终止

当任务陷入循环、资源超限、外部服务异常或发现风险时，Agent 要能够安全停止：

1. 停止新动作，不再扩大影响。
2. 终止可终止的子进程和工具调用。
3. 保存当前状态、日志和已完成产物。
4. 释放临时凭证和资源。
5. 告知用户阻塞原因和恢复选项。

取消不是删除现场。为了可审计和可恢复，取消后仍应保留任务状态和关键证据。对于已产生的外部副作用，还需要提供补偿或回滚流程。

十二、从一次任务到长期系统

可以按成熟度逐步建设：

Level 1：单轮工具 Agent

能读取文件、执行命令并返回结果。

Level 2：有状态任务

有目标、计划、检查点和会话恢复。

Level 3：可靠执行

有权限、审批、超时、有限重试和测试反馈。

Level 4：协作系统

能让用户中途调整方向，也能委派、等待和汇总子任务。

Level 5：长周期系统

能跨会话运行，处理异步事件和部分失败，并在预算和治理边界内交付可验证结果。

不需要所有项目都追求 Level 5。个人脚本可能只需要 Level 2；涉及生产发布、用户数据和长期监控时，才需要逐步补齐更高层能力。

十三、完整生命周期示例

一个上线任务可以这样运行：

创建目标和完成条件
       |
读取项目规则和当前工作区
       |
生成计划并请求高风险审批
       |
执行一组可回滚修改
       |
运行测试和浏览器检查
       |
保存检查点和版本
       |
发现失败：暂停、记录、有限重试
       |
验证全部完成条件
       |
交付 Diff、产物、日志和回滚说明

这条链路的重点不是让模型完全自由，而是让它在自由推理和确定性边界之间工作。模型负责提出和调整方案，Harness 负责状态、权限、执行、证据和交付。

结论

持续执行、协作和验证交付，决定了 Agent 能否从一次聪明的回答变成一个可靠的工作系统。

持久目标让任务跨越会话，检查点和重试让它跨越故障，协作原语让人类和其他 Agent 能够介入，验证原语让结果不再依赖模型自评，交付原语则把工作变成可审查、可复用、可回滚的成果。

一个真正能长期工作的 Agent，不是永远不停的模型，而是在明确目标、预算、权限和证据条件下，知道何时继续、何时等待、何时重试、何时停止并交付。

参考资料

• Git 官方文档，用于核对版本、分支、提交和恢复相关能力。
• Playwright 官方文档，用于核对浏览器验证和端到端测试。
• OWASP LLM01: Prompt Injection，用于理解持续运行 Agent 的输入风险。