---
title: 长周期-agent-详解-从-ralph-loop-到可接管-harness
source_url: https://mp.weixin.qq.com/s/ML5aD3f2ilHWjSB-wpBukw
publish_date: 2026-05-10
tags: [wechat, article, claude, openai, agent, harness, multi-agent, coding]
review_value: 7
review_confidence: 7
review_recommendation: neutral
ingested: 2026-05-16
sha256: 1121ed3fea101a8e9947ce02b74bc528544e2c0146cfc1ebd6d9ae68693dfa2a
---
长周期 Agent 详解：从 Ralph Loop 到可接管 Harness
这两周 Codex /goal 在群里被翻来覆去聊了好几轮。
它的思路很直白：给 Agent 一个一直挂在那儿的目标，别每隔几分钟就停下来问一句"要不要继续"。
但凡跑过稍微长一点的 AI 编程任务，大概都能体会那种烦：活儿没干完，Agent 先停了；人回来补一句"继续"，它又得从头热身一遍。
周末我把 Jarrod Watts 那条长帖、他开源的 long-running-agent-skill、OpenAI /goal 的官方文档，以及 Anthropic 最近两篇 long-running agent 和 context engineering 的文章串着翻了一遍。读完之后，脑子里最先冒出来的不是某个新功能，而是我们近期一直在聊的那条线：Harness、上下文工作集、上下文操作，再到 Martin Fowler 那篇反复讲的"非确定性怎么进研发链路"。
/goal 解决的，主要是"持续性"。
更难那一层在于：一个 Agent 跑几个小时，跨好几个上下文窗口，中途还把任务分给若干个 subagent，最后做出来的东西，还能不能被验证、被审计、被人或下一个 Agent 接着干下去。
以前我们担心 Agent 半途而废。
现在更让人头大的，是它一直在跑，一直很卖力，最后交了一个表面像模像样、方向已经偏掉的系统。
顺着这条线往下看，我现在更在意的是另一个问题：
长周期 Agent 的下一道坎，是任务跑完之后，留下的现场够不够清楚。下一个 Agent、下一个模型，或者下一个人，能不能直接接着往下做。
接不住，跑得越久，风险积得越深。
太长不看
• Codex /goal 很重要，但它解决的主要是"能不能一直干下去"，不等于把长任务的正确性也一起解决了。
• 朴素 Ralph Loop 的问题不在循环次数，而在每一轮都在悄悄积累目标漂移、上下文漂移和质量漂移。
• 长周期 Agent 比起"半途而废"，更怕"勤奋地跑偏"。
• 前置 Spec 的价值，是把错误的决策分叉提前剪掉，避免后面的 token 在错路上越跑越远。
• 外部状态文件比聊天记录靠谱。GOAL.md、PLAN.md、STANDARDS.md、PROGRESS.md 这类文件，是留给"下一任"的接管证据。
• Subagent 的第一层价值不是角色扮演。独立上下文可以用来做实现、探索和审查，减少自我确认。
• 多 Agent 不便宜，更适合当成质量治理手段。任务能拆、收益够高、验证链路清楚的时候，它才划算。
• 长周期 Agent 的分水岭，是从"能自己继续"走到"能被接管、能被回滚、能被复盘"。
先把几件事放在一起看
我习惯把同一时段出现的几件事摆在一起看。这次也是，单独看只是一个工具、一条帖子或一篇工程总结，放到一起，问题会清楚很多。
最早 Geoffrey Huntley 提 Ralph Loop 的时候，思路并不复杂：不要把失败、尝试和日志全堆在一个越来越长的会话里，每一轮都从相对干净的上下文开始，靠文件、代码、测试和 git history 自然继承进展。
Block 在自家开源 Agent 工具 Goose 里也实现过类似机制：worker 每轮做事，reviewer 独立审查，两边的摘要、反馈和完成标记都写进文件，下一轮再重新读取。我看到这段的时候印象挺深。这里有用的地方，不只是"循环"这个动作，还有"上下文重置 + 外部状态"这两件事。
OpenAI 把这个方向往前推了一步。/goal 给 Codex 一个 durable objective，让它围绕一个可验证的停止条件跨多轮持续工作。Karpathy 二月那条被疯传的推里，把这种用法形容成 "spinning up AI agents…managing and reviewing their work in parallel"，还说更大的活儿是搭一层 long-running orchestrator，把工具、记忆和指令都接上去。今天的 /goal，差不多就是这条路上一个早期的产品形态。
Anthropic 那篇 long-running agents 写得更工程化一些。他们列出的失败模式都挺眼熟：Agent 一次想做太多、上下文耗尽后只留下半成品、后来的 Agent 只能猜前面发生了什么、看到已有进展就过早宣布完成。给出的对策也朴素：initializer、feature list、progress file、git history、增量推进、端到端验证。
往上再看一层，是 Karpathy 和 Tobi Lütke 那条 context engineering 的主线。Tobi 那句被反复引用的话，说他更愿意把核心技能叫 context engineering，而不是 prompt engineering。放到今天这个问题里，其实说的还是：到底把哪些信息、按什么顺序、以什么形式放进模型当前能处理的工作集里。这点我们在《Agent Harness 上下文管理：聊天记录还是工作集？》和《AI 编程的下一场架构迁移：从代码检索，到上下文操作》里都聊过。
它们从不同地方进入：Ralph Loop、Codex /goal、long-running harness、context engineering。放回工程现场里看，最后会落到同一处：
长任务的进展不该只存在于模型上下文里，更适合迁移到一个可读取、可验证、可回滚的工作区。
不然 Agent 跑得越久，只是把风险从"它会停"换成"它会带着脏上下文继续跑"。
从 /goal 说起：能继续，只是第一步
先把 /goal 放回它擅长的位置。
Codex /goal 的价值是真实的。OpenAI 官方文档把它定义成给 Codex 一个 durable objective，让目标跨多轮稳定存在；同时也强调一个好的 goal 要有明确目的、约束、验证方式和停止条件。
这两句话基本已经说清楚 /goal 的定位：它没有让模型突然多出一份工程判断力，但把"围绕一个目标持续推进"这件事，做成了一块可以管理的控制面。
以前我们靠人类不停在旁边补几句：
继续。
再检查一下。
别停，到完成为止。
现在变成了一个更结构化的东西：目标、状态、预算、完成审计。
这一步有价值。
只是"能继续"只解决了一半问题。长周期任务里更难的部分，往往不是 Agent 会不会停，而是它不停之后还能不能朝着对的方向走。
一个稍微复杂点的需求背后，藏着一堆隐含决策：交互怎么设计、边界怎么处理、旧代码要不要迁、测试覆盖到哪里算够、安全默认值怎么选、哪些功能这次先不做。
这些东西如果一开始没人讲清楚，Agent 就会自己往里填。
它不是故意乱填。它会按概率、上下文和已经看到的代码，推断一个"看起来合理"的答案。第一轮偏一点，第二轮基于这个偏差继续推理，第三轮干脆把前两轮的输出当成既成事实。跑得越久，系统越自洽。
但这个"自洽"，未必还是你想要的那个东西。
Jarrod 在原帖里把这种现象叫 ambiguity compounds，翻成"模糊性复利"我觉得挺贴切。
模糊需求放到短任务里，顶多是一点小偏差；放到长周期 Agent 里，它会变成路径依赖。
Ralph Loop 的边界，在循环外面
Ralph Loop 的直觉很朴素：Agent 没干完，就把它拉回来接着干。
这思路不傻。很多场景下，模型多花点 token 确实结果更好。Sonnet 4.6 在 BrowseComp 上多烧 10 倍 token，分数能涨大约 10 个百分点；Boris Cherny 也提过类似观察：往一个编程问题里多投 token，结果通常会更好，他们叫 test time compute。
但是"多想一会儿"和"干一个长任务"不是一回事。
后者更像一个工程现场。
工程现场里，一个人连续干几天，最怕的并不是中间歇一歇，而是：
• 最初的目标已经悄悄变形，但没人发现；
• 中间做过哪些取舍没人记录；
• 测试到底覆盖到哪儿没人说得清；
• 后来接手的人只能猜前面为什么这么改；
• 系统看上去做完了，但只走通了一条局部路径。
放到 Agent 身上，我会把它压成三类漂移：
漂移 | 典型表现 | 后果
--- | --- | ---
目标漂移 | Agent 忘了最初要解决的问题，开始追求局部完整 | 做出来的东西和真实需求对不齐
上下文漂移 | 压缩、截断、摘要让关键信息丢失 | 后续判断基于残缺事实
质量漂移 | Agent 越做越相信自己已经做完 | 测试缺失、边界错误、架构变形
所以我倾向把 Ralph Loop 的边界理解成：循环本身不够。
真正起作用的东西，多半在循环外面：目标锚点、状态证据、验证制度。
Anthropic 那篇 long-running agents 的工程总结也是类似口径。它直接讲：长任务靠 compaction 撑不住。他们的做法是引入 initializer、progress file、feature list、git history，把推进切成增量，再配端到端验证。说白了，是把任务从"聊天继续"改成"工程继续"。
这两个词听着像，差别很大。
聊天继续，靠上下文。
工程继续，靠证据。
第一件事：先把关键分叉说清楚
我自己刚开始让 Agent 接长任务的时候，也经常把第一句话写得很大：
帮我把这个系统做完。
把这个产品重构一下。
做一个能上线的版本。
这种话对人不够用，对 Agent 更不够用。
因为它把大量隐含决策都丢给了模型。模型会很勤快地补全，但补出来的，未必是你心里那个版本。
Jarrod 的做法里有一个前置 interview 阶段，思路和 Matt Pocock 的 grill-me skill 很像：让 AI 先反过来追问你，把边界、目标、取舍、验收标准都问一遍，再正式进入自主执行。
这一步看起来慢，其实是在省后面的返工。
我会把它想成一棵决策树。
一个长周期任务开工之前，前面摆着一堆分叉：
• 这次是修 bug，还是顺手重构？
• 要兼容旧接口，还是允许破坏性调整？
• 优先性能，还是优先可维护性？
• 测试只覆盖快乐路径，还是把边界条件也补了？
• UI 跟着现有设计系统，还是可以重新做？
• 失败时是自动重试，还是停下来等人类确认？
开工前不剪枝，这些分叉就会被 Agent 在执行中临时拍板。
临时拍板多了，就开始漂。
所以前置 Spec 的价值，不在"多写一份文档"，而在把关键分叉提前剪掉，让后面那些 token 不要在错路上越走越远。
我现在会把 Spec 和 Vibe Coding 放在同一条线上看。
Vibe Coding 适合探索、原型、把想法先跑出来。可一旦进入长周期任务，Spec 就不是传统流程的包袱，而是上下文治理的一部分。
一个不至于太烂的长任务 Spec，至少要能回答四个问题：
问题 | 文件或机制
--- | ---
我们到底要什么 | GOAL.md / objective
哪些明确不做 | non-goals / constraints
怎么判断完成 | acceptance criteria
哪些决策不能让模型临时猜 | standards / architecture notes
这一步越清楚，后面的 Agent 才越像在施工，而不是在脑补。
第二件事：把记忆写到窗口外
谈到长周期 Agent 的"记忆"，很容易第一反应就是"把上下文窗口做大"。
长窗口当然有用。但窗口再长，也不适合承担所有历史。
这一点我们在《Agent Harness 上下文管理：聊天记录还是工作集？》里已经聊过：上下文窗口更像当前推理的工作集，不是聊天记录，也不是资料仓库。Tobi Lütke 那句"context engineering 比 prompt engineering 更准确"，背后大致也是这个意思。
放到长任务里，这点会更明显。
一个 Agent 跑几个小时，中间会搜文件、试错、改代码、跑测试、修失败、再调计划。很多信息当时有用，但不适合长期留在主上下文里；有些信息很关键，得跨窗口稳定保留。
这时候，文件系统反而比聊天记录靠谱。
Jarrod 的 long-running-agent-skill 里维护的是 GOAL.md、STANDARDS.md、IMPLEMENT.md、PROGRESS.md 这一组。命名不用照搬，但这组文件背后的想法很有用：
它们首先是写给下一个执行者看的接管证据，其次才是写给人类的项目文档。
不过这里要补一个反直觉的点。
文件化记忆，也会污染。
Jarrod 最近分享过一个长任务里的例子：某次优化跑到一半，一个 Agent 判断"继续优化在数学上不可能"，把这个结论写进了 progress log。之后每个新 Agent 启动时都会读取这份日志，第一印象都变成"这件事做不到"，于是接连一串 Agent 都不再认真尝试，直到人类介入才发现：那个判断本身是错的。
例子不大，但很典型。
我们经常说"把状态写进文件"，可状态文件并不是个垃圾桶。它写下去就会变成后续 Agent 的世界观。
所以长周期 Agent 的记忆文件得分层，至少要把四类东西分开：
• 事实：改了哪些文件、哪些测试通过、哪个 commit 是安全点；
• 观察：某次尝试看到什么现象、哪条路径看起来不太稳；
• 假设：当前怀疑的原因，但还没验证；
• 决策：已经定下的取舍，后续不能随便推翻。
最危险的是把"假设"悄悄写成"事实"，让后面的 Agent 一代代继承下来。
对应到可接管性，我会再拆成四类证据：
证据 | 说明
--- | ---
目标证据 | 为什么做、做到什么算完成、哪些不做
状态证据 | 已经做到哪里、当前卡在哪儿、下一步是什么
决策证据 | 为什么选这条路、放弃了哪些方案
验证证据 | 跑了哪些测试、哪些失败过、凭什么相信当前状态是对的
没有这些，长周期 Agent 就只是一段拉得很长的会话。
有了这些，中途换一个 Agent、换一个模型、换一个人接手，才有机会继续。
这也是今天我最想强调的一个词：可接管。
所谓可接管，不是"能恢复会话"那么简单。恢复会话只是把聊天历史拿回来。可接管的标准是，下一个执行者能回答几个朴素问题：
• 当前目标是什么？
• 已经成事实的有哪些？
• 哪些只是猜测？
• 哪些决策不能随便动？
• 哪些测试能证明当前状态？
• 真要回滚的话，最近的安全点在哪里？
这些问题答不上来，长任务跑得越久，最后留下的就越像一团没人敢碰的上下文。
第三件事：用独立上下文做审查
Subagent 放进长任务里，第一层价值很朴素：先解决上下文隔离。
一个主 Agent 做长任务，会不停积累自己的判断。它读过哪些文件、试过哪些路径、为什么放弃某个方案，这些都会影响后续推理。
这当然有好处。没有连续性，任务根本推不下去。
但连续性也会带来自我确认。
Agent 很容易相信自己前面做过的判断，尤其在上下文已经变脏之后。它会把局部测试通过当成全局完成，把一个解释得通的失败原因当成真实原因，把"我已经修复"当成既成事实。
这时候，一个 fresh reviewer 就有价值。
Reviewer Agent 不需要继承全部探索过程。它只看目标、diff、标准、测试结果和关键决策，然后从一个相对干净的上下文里，问几个朴素问题：
• 这次改动是否真的满足目标？
• 有没有改出需求之外的东西？
• 测试是不是只覆盖了快乐路径？
• 旧行为有没有被悄悄破坏？
• 这里的架构取舍，下一个人能不能看懂？
这更接近真实的 code review。
Boris Cherny 在 Claude Code 那条推里说过一句我挺认同的话：让结果更好的一种方式，就是用独立的上下文窗口；这也是 subagent 之所以有用的原因。一个 Agent 引入的 bug，常常要靠另一个 Agent 来挑出来。
Anthropic 在 multi-agent research system 那篇里也提醒过：多 Agent 适合那种任务能并行拆、信息量超过单 Agent 上下文、结果价值又足够高的场景。代价也很明白，token 成本和协调成本都会显著上去。他们给的数字是，普通 agent 大概是 chat 的 4 倍，多 agent 系统差不多到 chat 的 15 倍。
所以我自己的看法比较克制：多 Agent 不适合作为默认架构，它更像一种偏贵的质量治理手段。
绝大多数任务里，一个清楚的目标、一个干净的工作集、一组确定性测试，往往就够用了。
但任务一旦跨多个模块、探索路径很多、review 成本很高，Subagent 的价值就显出来了：
• Explore subagent 负责大范围搜索，不让主上下文被搜索结果淹掉；
• Implementer subagent 负责局部实现，任务边界更小；
• Reviewer subagent 独立审查，不继承实现者的心理负担；
• Orchestrator 收拢结果、更新状态、推进里程碑。
这里要处理的，是不同上下文的信息密度。不要让一个 Agent 既当工人又当工头。
长周期 Agent 需要一条证据链
把前面几件事拼到一起看，长周期 Agent 需要一条证据链。
它不是一条更长的 prompt，也不靠一张看起来很气派的多 Agent 组织图。
简单说，就是从目标、状态到验证，每一步都留下下一个执行者能读、能查、能质疑的东西。
我会把它压成这张表：
层级 | 核心问题 | 工程抓手
--- | --- | ---
目标层 | 它到底要做什么 | Goal、Non-goal、Acceptance Criteria、前置澄清
状态层 | 它现在做到哪儿 | Progress、Decision Log、Git History、Milestone State
治理层 | 它做得对不对 | Tests、Review Agent、Lint、Typecheck、Human Checkpoint
这三层缺任何一层，长任务都会很脆。
只有目标，没有状态，后续 Agent 不知道前面走到哪儿了。
只有状态，没有验证，系统会把"做过"当成"做对"。
只有验证，没有目标，测试通过也未必是用户想要的东西。
所以我觉得 /goal 重要，但它远远不是终点。
/goal 让一个目标可以持续存在。接下来要补的，是围绕这个目标形成的外部状态、增量验证和接管机制。
说到最后，还是回到 Harness。
模型负责理解、生成、推理和修正。
Harness 负责把目标、上下文、工具、权限、状态、反馈和验证组织好，让模型的非确定性能力，能进入一个相对确定的工程过程里。
可接管，才是长任务的生产级标准
问题到这里会自然变成：长周期 Agent 到底什么时候算"能用"？
我现在不太愿意用"能连续跑多久"来回答。
跑 8 小时不难，烧 token 就行。难的是 8 小时之后，它有没有给你留下一份还能读、还能接的现场。
更接近生产级的标准，是看它能不能被接管。
接管可以有很多形态：
• 人类工程师接手，能在几分钟里判断出当前状态；
• 新 Agent 接手，能读懂目标、计划和未完成项；
• Reviewer 接手，能基于 diff 和标准审查质量；
• CI 接手，能用确定性反馈挡住明显错误；
• 未来的模型接手，能继承前面沉淀下来的工程约束。
这背后是软件工程一个很老的问题。
我们写 commit message、开 PR、补测试、写 ADR、留 changelog，原因从来都不只是"人类记性差"。更底层的那一层，是任何工程系统都不能依赖某一个人当下的临时上下文。
Agent 时代也一样。
与其指望模型一直记得所有事，不如让它每次醒来都能重新读到事实。
这也是《架构师》最近几篇一直绕回 Harness 的原因。
Cursor 复盘讲的是 Harness 怎么持续评估、观测、回滚和适配模型；Martin Fowler 提醒的，是非确定性进了研发链路之后，确定性验证反而更值钱；我们前两天聊《AI 编程的下一场架构迁移：从代码检索，到上下文操作》，说的是代码检索、读取、执行、验证这些动作正在进入 Agent 的运行循环；再往前一点，《Boris Cherny 访谈后的一个信号：开发工具正在从 IDE 变成 Agent 控制台》和《Karpathy 最新访谈：从 Vibe Coding 到 Agentic Engineering》也在说类似变化：开发工具的重心，正在从"写代码"往"管 Agent"这边挪。
今天这篇再往前迈半步：
Agent 一旦长时间运行，Harness 就不能只关心"怎么让它继续"，还得关心"怎么让别人接得住"。
接不住，就谈不上什么生产级。
写在最后
我对长周期 Agent 整体还是乐观的。
Codex /goal、Jarrod 的 long-running-agent-skill、Anthropic 的 long-running harness 实验，几个方向都值得继续看。它们都在说明一件事：行业正在从"单轮智能"往"持续执行"挪。
但如果只盯着"持续"，会错过更关键的一层。
长周期任务，不是一条拉得更长的聊天记录。
它更像一个小型工程系统：有目标，有计划，有状态，有审查，有验证，有回滚点，也有让下一任执行者能直接读懂的现场。
如果压成一句话，我会这么说：
长时间 Agent 的下一道坎，是它跑了很久之后，留下的过程和结果还能不能被人、或者被下一个 Agent 接得住。
这也是接下来做 Agentic Engineering 时绕不过去的一块。
模型走进研发流程之后，系统还是得能被人和后来的 Agent 共同拥有。