长周期 Agent 详解：从 Ralph Loop 到可接管 Harness¶

Ch05.012 长周期 Agent 详解：从 Ralph Loop 到可接管 Harness¶

📊 Level ⭐⭐ | 23.4KB | entities/long-running-agent-ralph-loop-handover-harness-ruofei.md

5 张卡治理框架（若飞 2026-06 续篇）¶

若飞 2026-06-01 续篇将"可接管"标准升级为团队 Agent 工作流的5 张卡治理框架。核心 thesis 是引用 Shann 转述 Teknium 的话——"don't automate slop"：流程还没跑明白，先别急着让 Agent 把它自动化。一个松散的流程接上 Agent 不会自动变严谨，只会跑得更快、产物更多、问题更容易被推到后面。

5 张卡清单¶

5 张卡不一定真的写成 5 个文件，但脑子里要分开。混在一起是大多数 Agent 工作流后期不好维护的根因。

Level 1 准入流程（先反着看四层 setup）¶

Hermes 官方扩展路径是"主 Agent → 专职 Agent → orchestrator → cron + 事件"——若飞认为不能照抄。规模会放大质量：质量好，规模是杠杆；质量差，规模就是麻烦。

主 Agent 在窄场景里必须先跑稳以下 4 个验收点：

1. 输入是否稳定——竞品扫描、X 列表、固定站点？输入每次都变，输出不稳并不奇怪
2. 输出谁来收——摘要 / 风险点 / 引用原文 / 公众号素材？收件人不同，格式不同
3. 失败怎么留下来——这次没抓到哪些站点、哪些链接打不开、哪些判断只是推测
4. 哪些动作要人点头——读文档可放开；发消息、改配置、删文件、创建 cron 要慢

自动化不会取消审批，只会把审批集中到更少、更关键的位置。

记忆预算观¶

与上文 Ralph Loop 段对"模糊性复利"的警示互补——若飞 2026-06 续篇明确提出记忆更像预算，不像仓库：

• 注意力预算：每条长期记忆都在花未来的注意力
• 上下文预算：常驻层 MEMORY.md 默认 2,200 字符，USER.md 1,375 字符
• 判断预算：旧偏好可能带偏新项目

四层信息隔离（身份/项目/记忆/历史检索）不是一类东西，必须用不同载体分开（SOUL.md / AGENTS.md / MEMORY.md+USER.md / session_search）。

Skill 准入 + 退场¶

• 准入：无明确触发条件 / 无输入边界 / 无验证方式 / 会改系统状态 → 不沉淀
• 退场：30 天不用 → stale，90 天不用 → archived（Hermes Curator 默认策略）
• 过程资产也会变旧，清理和退场本身就是长期系统的架构一部分

GEPA 证据链边界¶

GEPA 的价值不在"Agent 自己变强了"，而在让改 Skill 有了证据链（轨迹→失败分析→候选变体→评估+约束门+PR review）。当前实现仅 Phase 1（Skill files），其余阶段还在计划。若飞明确表示："我不会直接相信它'学会了'。我会先看它改了什么、为什么改、评估怎么跑、失败样本在哪、人怎么审、怎么回滚。"

4 周试跑路径（Level 1 → 多 Agent）¶

• 第 1 周：只让一个主 Agent 跑窄场景（输入固定 + 输出固定），不写 Skill，先看哪里犯错
• 第 2 周：只沉淀一个 Skill，写小一点
• 第 3 周：再考虑 cron，cron 只拉起任务不替人做最终判断
• 第 4 周：再决定是否拆子 Agent

"主 Agent 跑不稳，就不写 Skill。Skill 没验证，就不上 cron。cron 没跑出稳定结果，就不拆子 Agent。"

总结：若飞 long-running-agent 系列两篇视角融合¶

两篇合并后，长周期 Agent 的完整工程图景是：在方向治理（证据链、6 项标准）之上叠加治理分层（5 张卡、4 周试跑），用"don't automate slop"作为准入门槛，用"可接管"作为终止标准。

背景与问题定义¶

长周期 Agent（Long-Running Agent）指需要跨越数小时乃至数天完成复杂工程任务的 AI Agent。与短任务不同，长周期任务面临时间跨度大、上下文压缩失效、目标漂移累积等独特挑战。

Codex 的 /goal 命令解决的是"能不能一直干下去"——即让 Agent 持续运行的问题——但这并不等于解决长任务中做对方向的问题。若飞指出，长周期 Agent 最怕的不是"半途而废"，而是"勤奋地跑偏"：Agent 越跑越相信自己走在正确方向上，实际上已与原始目标渐行渐远。

三类漂移：长周期 Agent 的核心陷阱¶

Ralph Loop 是 AI Agent 的基础运行范式——感知→推理→执行→反馈→下一轮循环。但每轮循环都会引入微小的偏差，积累形成三类系统性漂移：

[!contradiction] 参见 Harness Engineering 长程任务 强调的"半途而废"风险，与本文"勤奋地跑偏更可怕"形成对比——两者并不矛盾，前者关注能力边界，后者关注方向治理。

Ralph Loop 的结构性问题¶

Ralph Loop（感知-推理-执行的快速循环）的问题不在循环内部，而在循环外部——即缺乏目标锚点、状态证据和验证制度。Anthropic 的解决思路是将任务从"聊天继续"（chat continuation）改为"工程继续"（engineering continuation）。

聊天继续依赖上下文记忆，容易随上下文压缩丢失关键信息；工程继续依赖外部化的、可审计的证据文件，使每一轮决策都有据可查。

Jarrod Watts 的"模糊性复利"¶

短任务中的小偏差在长周期中被放大成路径依赖。Jarrod Watts 将这一现象命名为模糊性复利（Ambiguity Compound）：Agent 在早期对模糊问题的暂定解释，会随着每一轮循环被强化，最终变成无法动摇的"既定事实"。

文件化的记忆本身也可能成为污染源。Jarrod 的一个具体案例：某次 Agent 将错误的悲观判断写入 progress log，后续 Agent 都读取了这个判断，集体放弃了本可成功的尝试路径。记忆文件需要分层：事实（Facts）、观察（Observations）、假设（Hypotheses）、决策（Decisions）——最危险的是将"假设"悄悄写成"事实"。

长周期 Agent 的证据链：三层工程抓手¶

若飞提出，长周期 Agent 的可靠运行需要三层证据链，每层都有明确的工程抓手：

前置 Spec 的价值在于将错误决策分叉提前剪掉。明确的 Goal 定义使得 Agent 在每轮循环中都有参照系，而不是依赖自身的上下文记忆来判断当前状态。

Subagent 架构与多 Agent 质量治理¶

Subagent（子 Agent）的第一层价值在于独立上下文：将实现、探索和审查分离到不同上下文中，避免同一上下文内的信息相互污染。

Boris Cherny 的观点指出：一个 Agent 引入的 bug，常常要靠另一个 Agent 来挑出来。这说明多 Agent 架构的本质不是"并行加速"，而是质量治理手段。

由于多 Agent 调用成本高，它适合作为质量关卡（Quality Gate）而非默认架构——即在高风险节点引入 Review Agent 而非全程多 Agent 并行。

可接管的标准：从"能继续"到"能被接管"¶

长周期 Agent 的分水岭不在于"能自己继续运行"，而在于能被接管、回滚、复盘。若飞提出的可交接标准是：下一个执行者（无论是人还是 Agent）能明确回答以下问题：

• 当前目标是什么？ → 需要外部化的 Goal 文件
• 已成事实的有哪些？ → 需要状态快照（Milestone State）
• 哪些只是猜测？ → 需要区分假设与事实的标注机制
• 哪些决策不能随便动？ → 需要 Decision Log 记录关键决策及原因
• 哪些测试能证明当前状态？ → 需要可运行的 Test Suite 作为状态验证
• 真要回滚，最近的安全点在哪里？ → 需要 Git History / Snapshot 机制

这六项标准将"能继续"（Ralph Loop 层面）升级为"可交接"（工程治理层面），是 Harness 设计在长周期任务中的核心价值体现。

与 Harness Engineering 的关系¶

本文的论述与 Harness Engineering 研究方向高度一致。长周期 Agent 的可接管性是 Harness 在工程层面的具体落地——Harness 提供了控制面（Control Plane），而 Ralph Loop 提供了执行面（Execution Plane）。两者结合才能实现"持续运行 + 方向正确"的双重目标。

外部状态文件（GOAL.md / PLAN.md / PROGRESS.md）比聊天记录更可靠，因为它们不随上下文压缩而丢失，且可被版本控制和审查。参见 对状态管理问题的深入讨论。

核心结论¶

1. "能继续"只解决一半问题：长任务更难的部分是 Agent 停止后能否继续朝着对的方向走，而非仅能恢复会话。
2. /goal 的定位：它把"围绕目标持续推进"做成可管理的控制面，但没有让模型突然多出工程判断力。
3. 文件记忆需要分层：防止"假设"悄悄写成"事实"导致后续 Agent 集体跑偏。
4. 多 Agent 是质量手段而非效率手段：调用成本高，适合做质量治理关卡而非默认并行架构。

深度分析¶

1. "/goal"解决连续性，不解决正确性：Codex 的 /goal 命令本质上是将"围绕目标持续推进"做成可审计的控制面，但它没有让模型突然多出工程判断力。这意味着即使 Agent 能在长周期内不中断执行，它仍可能在错误方向上持续运行——"勤奋地跑偏"比"半途而废"更危险。

2. 三类漂移构成系统性风险而非独立问题：目标漂移、上下文漂移和质量漂移并非各自独立发生，而是通过 Ralph Loop 的反馈机制相互放大。例如，上下文压缩导致关键决策依据丢失，Agent 填补这个空白时会引入假设，这些假设被写入 progress log 后又成为后续循环的"事实"——形成自我强化的漂移链。

3. Anthropic 的"工程继续"范式转换是关键突破口：将任务从"聊天继续"改为"工程继续"，本质上是将证据外化——外部状态文件（GOAL.md、PLAN.md、PROGRESS.md）不随上下文压缩丢失，可被版本控制和审查。这打破了 Agent 内部记忆的封闭性，为外部治理提供了抓手。

4. 模糊性复利是记忆污染的核心机制：Jarrod Watts 的"模糊性复利"概念揭示了长周期 Agent 中最隐蔽的风险——早期对模糊问题的暂定解释经过每一轮循环被强化，最终变成无法动摇的"既定事实"。最危险的场景是将"假设"悄悄写成"事实"，导致后续 Agent 集体跑偏。

5. 可交接性是长周期 Agent 的真正分水岭：若飞提出的六项可交接标准（目标/已成事实/猜测/决策边界/测试证明/回滚安全点）将从"能继续"升级为"可接管"——这意味着长周期 Agent 的最终验收标准不是能否恢复会话，而是下一个执行者能否基于完整证据链做出正确判断。

实践启示¶

1. 在启动长周期任务前，必须完成 GOAL.md + Non-Goal + Acceptance Criteria 的完整定义：将错误决策分叉提前剪掉，而不是依赖 Agent 在运行过程中自我纠正。前置 Spec 是最便宜的风控手段。

2. 建立分层的外部记忆文件制度：区分 Facts（客观事实）、Observations（观察结果）、Hypotheses（假设，需标注置信度）、Decisions（决策及原因）四层。严禁将假设写成事实；假设必须附带推翻条件。

3. 在关键里程碑节点强制引入 Review Agent 作为 Quality Gate：多 Agent 架构的调用成本高，因此不能用作默认并行架构，而应在高风险节点（架构变更、大规模重构、关键决策点）作为质量关卡引入。

4. 为每个可回滚点建立 Git Snapshot 或等价机制：确保"真要回滚，最近的安全点在哪里"这个问题有明确答案。Git History + Milestone State 是长周期 Agent 的安全网。

5. 构建可运行的 Test Suite 作为状态验证的主要手段：测试不仅是质量保证工具，更是状态证明机制——能通过的测试套件即代表当前状态的有效性。这比 Agent 自我评估更可靠。

相关实体¶

• 长周期 Agent 详解 从 Ralph Loop 到可接管 Harness
• Code As Agent Harness Survey
• Agentscope Java Harness Framework Enterprise Distributed
• Agent Harness Architecture Design Production Guide
• Harness 之后 状态边界与失败闭环 Ruofei

→ 原文存档

第 3 来源：若飞「再看 Harness Engineering」（2026-06-09）¶

若飞第三篇 Harness Engineering 文章提出核心论点：真正要设计的不是约束，而是可删的工作现场。从五层架构出发，综合 OpenAI、ThoughtWorks/Martin Fowler、Anthropic、Vercel 四家实践，构建了完整的 Harness 工程图景。

核心创新 / 关键数据¶

• 五层架构图：Model（推理核心）→ Tool（手，外部动作）→ Skill（手艺，可复用做事方法）→ Sub-agent（任务分工）→ Harness（管运行），每层有明确的职责边界和失败模式
• Tool vs Skill 区分："Tool 告诉 Agent 能做什么，Skill 告诉 Agent 这类事通常怎么做"——Tool 是能力扩展也是权限边界，Skill 是把团队经验沉淀为可反复调用的过程资产
• Vercel 删 80% 工具案例：内部 text-to-SQL agent 从 6 个专门工具简化为 1 个 bash 文件系统 agent，成功率 80%→100%，耗时/步骤/token 全部下降

对照表：三篇若飞系列文章维度对比¶

与已有 source 呼应¶

• Guides + Sensors 框架（第 3 来源独有）补全了第 1 来源"证据链三层"的操作维度：Guides 对应目标层的"前置引导"，Sensors 对应治理层的"事后验证"——但 Fowler 的拆法更直觉，"前后咬合"的闭环描述比"三层证据"更容易落地。
• OpenAI AGENTS.md 入口地图模式（第 3 来源独有）与第 2 来源"记忆预算观"形成互补：AGENTS.md 不是信息仓库而是导航地图——与"记忆更像预算"的论点一致，但给出了具体结构化方案（规则文件→结构化文档→执行计划→质量记录→产品规格）。
• Vercel 删工具案例（第 3 来源独有）为第 2 来源"Skill 准入+退场"提供了反面验证：退场不只是"30 天不用就 stale"，还要主动检查"这个组件解决哪类失败，最近有没有触发，关掉以后质量和成本会不会变差"——如果说不清，它可能已经是技术债。

实践启示¶

• 优先机械检查：确定性检查（类型、lint、格式化）便宜快可靠；语义检查（LLM review、架构审查）贵且不稳定——刚开始搭 Harness 不必急于把所有东西交给 LLM 评审
• 任务卡 8 项模板：目标/边界/输入/可用工具/验证/状态/停止/回写——如果说不清这几项，Agent 能跑但 review/合并/回滚/接手都会费劲
• 可删约束作为设计原则：每个 Harness 组件必须能回答"解决哪类失败、最近有没有触发、关掉会怎样"——说不清 = 技术债
• 从小流程起步：技术稿核验、小型 bug 修复、配置漂移扫描等低风险流程先跑，不用急着做大而全的 Agent 平台
• Sub-agent 三点校验：子任务独立 + 输出可验证 + 结果可合并——做不到三点只是"多开了几个窗口"

上线状态 / 链接¶

• ThoughtWorks/Martin Fowler Guides + Sensors 框架：生产级方法论，已被多个团队采用
• OpenAI Codex Harness Engineering：内部产品，AGENTS.md 模式可直接借鉴
• Vercel text-to-SQL agent：内部案例，公开报道

→ 第 3 原文存档