自主 AI 智能体：如何让它连续工作数小时而不产出垃圾

什么是自主 AI 智能体，它与普通请求有何不同

普通的智能体协作是逐步进行的：您编写提示词，智能体执行一步，您查看结果，再决定下一步做什么。自主 AI 智能体则以循环方式工作：您只需一次性描述最终状态，之后智能体会自行重复“执行——检查——修正”，直到达成目标或预算耗尽。启动之后，您可以离开。

听起来很简单，但典型的第一次尝试往往是这样的：智能体早上接到任务，到了晚上才发现它花了好几个小时去修复一个早已修好的 bug，因为它忘了一小时前做过什么。没有人告诉它何时该停下，何时该叫人。下面介绍如何设计一个不会出现这种情况的循环。

需要说明的是，循环并不能替代 harness。Harness 让单次运行变得可靠，循环则让运行能够持续进行。在糟糕的 harness 之上搭建循环，只会更快地产出垃圾。

任务是否适合交给自主智能体

首先要问的是：工作是否有一条可以由机器检验的终点线。“tests/payments 目录下的所有测试都通过”“功能清单中的所有功能都处于 passing 状态”“指标相对基线有所提升”——这些都适合。“把代码做得更好”或“继续改进支付模块”——则不适合：这样的目标没有终点，循环会一直转下去，直到耗尽预算。

值得区分四种循环：

• 逐步式——您输入每一条提示词，这就是常规的交互式工作。
• 按目标式——您设定目标，由独立检查或预算来决定何时停止。这正是数小时自主工作的智能体。
• 按时间式——按计划启动（例如每天早上分析失败的 CI 构建），由您手动停止。
• 按事件式——由外部触发器启动（新的 issue、失败的部署），事件处理完成或达到重试上限即停止。

常见错误是把按时间的循环与按目标的循环混为一谈，例如“每 10 分钟继续做支付”。按计划运行的循环每次都从零开始读取指令，并不知道之前做了什么。如果任务有终点，就需要一个带有进度记忆的按目标循环。

第 1 步：沙箱，即智能体可以在哪里“犯错”

无人值守的智能体迟早会做错事：删除文件、改写迁移脚本、运行耗资源的命令。因此问题不是“如何保证它不犯错”，而是“如何让错误不造成任何损失”。

• 独立的工作副本。git worktree 会在同一个仓库之上为智能体提供独立的目录和分支。主分支不受影响，多个智能体互不干扰，失败的运行只需一条命令即可删除。
• 容器或虚拟机。如果智能体需要完整的命令访问权限，就在容器中运行它，并且让容器无法访问您的主目录、密钥和生产数据库。
• 测试数据。本地数据库、支付系统的沙箱、虚假密钥。智能体的环境中不应出现任何生产环境的密钥。

# 为自主运行创建独立分支和目录
git worktree add ../shop-agent -b agent/f03-refunds

# 运行结束后：查看结果或直接丢弃
git -C ../shop-agent log --oneline main..
git worktree remove ../shop-agent

第 2 步：权限，仅限任务所需的最低限度

智能体独立工作的时间越长，它的权限就应该越小。在 Claude Code 中，权限通过 settings.json 配置（工具和命令的 allow 与 deny 列表）：明确允许任务所需的操作，例如运行测试、代码检查工具、在工作副本中修改文件；同时禁止危险操作，例如推送到主分支、访问密钥、在不需要时执行网络命令。

无需任何确认、全部自动执行的模式，只能在隔离的沙箱中使用，因为最坏的结果只是丢弃一个容器。在能访问您的密钥和仓库的工作机器上，绝不能这样做。

不可违反的禁令应当通过机制来保证，而不是仅仅写在文字里。在指令中写“不要动 migrations/ 目录”只是一个愿望；而阻止修改该目录的钩子或文件系统权限，才是真正的保证。

第 3 步：目标、验证、停止，启动前写清三行

最简单、可行的循环依赖三件事，应当在启动前写下，而不是边做边想：

1. 目标——最终状态是什么样子。
2. 验证——用机器可检验的方式确认目标已达成：一条返回成功或失败的命令。
3. 停止条件——尝试次数、时间或费用的上限，即使目标未达成，超出后循环也会停止。

建议把这些内容放在一个方法论文件中，且只由人来修改。下面是支付后端的示例：

# program.md — 自主运行的方法论

## 目标
.agent/feature_list.json 中的所有功能都处于 passing 状态。

## 指标
处于 passing 的功能数量。只增不减。出现回归 = 立即回滚。

## 约束
- 同一时间只处理一个功能。
- 不修改 migrations/ 和 infra/。
- 不改动依赖项，除非在日志中记录。

## 工作顺序
1. 取第一个不处于 passing 的功能。
2. 实现后运行 pytest 和代码检查工具。
3. 通过则提交并写入 .agent/progress.md；失败则修复。

## 停止与升级
- 同一功能失败 3 次——标记为 blocked，转向下一个功能。
- 剩余功能全部 blocked——停止并写出报告。
- 任何涉及客户资金、访问权限或数据删除的任务——不执行，而是升级给人处理。

第 4 步：检查-修正循环，进度存放在磁盘上

上下文窗口无法承受长时间的工作：它会溢出、被压缩，会话也会重新启动。因此进度必须保存在文件中，而不是存在智能体的“脑子”里：带状态的任务列表、记录已完成与失败尝试的日志，以及 git 历史。

一个好的模型是“只能向前转动的棘轮”，例如 Andrej Karpathy 的 autoresearch 项目：智能体一夜之间进行数百次机器学习实验。每一轮迭代都是：阅读方法论，提出假设，修改代码，用固定的时间预算运行实验，并与基线比较。有改进则提交，没有改进则回滚。结果写入日志，然后进入下一个假设。

这个方案有两点值得借鉴：

• 每次尝试的预算固定。这样尝试之间才有可比性，一个失败的假设也不会耗尽整夜的时间。
• 主分支只保留改进。所有没有成功的内容都被回滚，而不是留在旁边。git log 就变成了一份经过验证的工作日志，第二天早上很容易读懂。

该项目还通过文件划分了角色：基础设施和评估代码无人修改，实验代码只由智能体修改，方法论只由人修改。智能体无法通过修改衡量方式来“提高”结果。

第 5 步：谁来判定完成，由独立的评估者决定

当没有人参与循环时，智能体的自我评价就成了唯一的刹车，而这个刹车并不可靠。刚刚写完代码的智能体倾向于认为代码是正确的：它能看到自己的推理过程，并且“知道”自己想要做什么。

生成者与评估者分离的规则如下：

• 评估的不应是完成工作的那个会话。在 Claude Code 中，子智能体很适合这个角色，因为每个子智能体都有自己的上下文。
• 评估者只获得干净的上下文：需求、diff 和运行结果，不包括执行者的任何推理。
• 条件允许时，评估者应使用另一个模型，或至少使用另一套提示词和另一种角色。
• 结论依据评分细则作出，每一项都要附上证据：测试的某一行、命令的输出、diff 中的位置。

机器检查仍然是首要的。评估者的作用是覆盖测试无法发现的问题：需求被误解、测试是为代码量身定制的、改动超出了任务范围。

停止条件：智能体应在何时放弃

没有停止条件的循环迟早会陷入死循环。最基本的一组条件如下：

检查进展时应看实质，而不是尝试次数：“完成了 40 次迭代”毫无意义，“通过的功能数从 5 增加到 9”才有意义。如果任务停滞，应当交给人处理，而不是再让循环跑一遍。

自主智能体那些不易察觉的风险

显而易见的风险——被删除的文件、损坏的构建——可以通过沙箱和权限来防范。更危险的是那些几周内悄悄累积的隐性损耗：

• 验证债务。满足于“看起来正常”，而不是“已由机器确认”。对策是始终使用机器可验证的停止条件，没有例外。
• 理解力退化。您越来越不了解自己的代码。对策是强制阅读 diff：循环的速度不应超过您阅读的速度。
• 认知投降。您不再对结果有自己的判断，什么都接受。诚实地统计“稍后再看”却没有看的次数，会很有帮助。
• 上下文膨胀。长时间运行会积累大量历史，每一步都更昂贵，效果也更差。上下文压缩和外部记忆应从第一个循环就开始使用，而不是等一切都失控之后。

一个晚上内如何启动第一个自主循环

不要一开始就说“让智能体自己找任务并完成”。自主性应当循序渐进：先是带目标和停止条件的单一任务，然后是一个按计划运行的自动化，再然后是在隔离工作副本中分离执行者和检查者，最后才是能够自行发现工作并并行运行的循环。

1. 找一项您每周手动做至少两次、并且有可验证终点的任务。
2. 写下目标、验证方式和停止条件——三行。
3. 创建独立的 worktree 并设置权限：允许运行测试和修改文件，禁止推送和访问密钥。
4. 建立进度文件，并要求智能体在每次迭代后更新它。
5. 分离角色：执行者编写代码，检查者在独立的上下文中评估 diff。
6. 设置总体上限，第一次运行后一小时就检查结果，而不是等到第二天早上。

小结

自主 AI 智能体的可靠程度，取决于它的边界：一个错误不会造成损失的沙箱、最小化的权限、机器可验证的目标、磁盘上的记忆、独立的评估者，以及带有人工升级的严格停止条件。缺少这些，长时间运行就不是节省时间，而是推迟了清理烂摊子的时间。如何围绕真实项目搭建这样的循环——从 program.md 到独立评估者——我们在 harness engineering 课程中结合实践进行了讲解。