先看日志，再谈阶段

读完那篇从 Prompt 到 Loop 的长文，我最想做的事，是回头看一个真实项目的 Agent 日志。概念表已经够多了，日志更接近工作现场。

原因很简单。一个人说自己已经进入 Loop Engineering，未必算数；日志里有没有任务切片、上下文入口、工具边界、执行记录、验证命令、失败处理和续跑状态，才算数。协作方式成熟以后，会在磁盘上留下痕迹。

我把这个项目匿名叫作 Z 项目。它是一个持续演进的工程系统，演示性质很低。最近几轮记录里，可以看到 promptN.txt、doneN.txt、heartbeat、验收文档和验证命令一块出现。每个任务都有目标、允许修改范围、非目标、验收命令、完成摘要和剩余风险。

这些东西看起来琐碎，其实正好回答了那篇文章背后的问题：人和 AI 的协作杠杆，已经从「怎么写一句 prompt」移到了「怎样设计一套能持续工作的系统」。

四级台阶的实际含义

Prompt、Context、Harness、Loop 这四个词，如果只当流行概念看，很容易变成新名词排队。放到真实项目里，它们对应的是四种不同的工作资产。

Prompt 阶段的核心资产是好用的话术。团队会保存几段模板，告诉模型扮演什么角色、按什么格式输出、用什么步骤思考。这个阶段有效，但很脆。每次换任务、换仓库、换会话，都要重新解释背景。

Context 阶段的核心资产是上下文装配。团队开始意识到，模型每次推理时看到什么，比那句指令本身更要紧。AGENTS.md、架构文档、检索结果、任务相关代码、历史决策、测试失败日志，都进入这个范围。LangChain 把它拆成写、选、压、隔四类动作；Lost in the Middle 这样的研究也提醒我们，长上下文会出现召回和注意力问题，所以多塞材料并不等于更聪明。

Harness 阶段的核心资产是运行外壳。模型有了文件系统、终端、测试命令、沙箱、权限、审批、日志和评测。Addy Osmani 和很多工程实践都在讲同一件事：模型只是 Agent 的一部分，剩下让它能工作的环境才决定了稳定性。Anthropic 在 agent 系统设计里也强调，工具、反馈和可组合工作流，比堆复杂编排更重要。

Loop 阶段的核心资产是循环本身。人逐步命令 Agent 做每个动作的比例下降，更多时间花在触发器、状态文件、工作树、子任务、验收器和失败转人工规则上。Agent 可以从上一次留下的状态继续跑，直到满足可验证的停止条件，或者把阻塞点交回给人。

这四层可以简化成五个成熟度等级。

  • L1 Prompt：主要靠提示词模板推进工作。
  • L2 Context：开始系统管理上下文，减少重复解释。
  • L3 Harness：工具、权限、测试、日志和运行环境成形。
  • L4 Supervised Loop：有受监督的任务循环，人仍然切片、验收和接力。
  • L5 Autonomous Loop：系统能自动发现任务、隔离执行、独立验收、提交结果，并把失败放回队列。

这个分级的用处是避免跳级。L2 没做好，L3 会变成带工具的混乱；L3 没做好，L4 会变成无人看管的错误生成器。

Z 项目的日志说明了什么

Z 项目最近的记录里，最明显的信号是意图已经外化。

每个 prompt 文件都不再停留在「帮我修一下」。它会写清楚目标、为什么做、必须阅读的上下文、允许修改的文件、非目标、实现要求和验证命令。对 Agent 来说，这相当于把任务边界、风险边界和验收边界一起放到工作区里。

done 文件也不再停留在「完成了」。它会记录 status=passed，列出改了哪些文件，说明本轮实际完成的契约，给出验证命令的结果，再把没有证明的能力写成剩余风险。尤其是剩余风险部分，价值很高。它把「这次没有证明什么」写出来，避免把局部测试通过包装成生产可用。

heartbeat 文件和 prompt/done 轮转，则说明项目已经在模拟一种持续工作循环。人把一个大目标拆成若干切片，Agent 按切片执行，完成后写回证据，再进入下一轮。这个模式已经明显越过 Prompt 和 Context，也超过了普通 Harness。

但它还不是完全自治。

任务是谁选的、下一轮怎么开、什么时候认为目标整体完成、失败后怎样自动重试、多个 Agent 怎么隔离并行，这些动作仍然主要由人控制。因此，Z 项目当前最准确的位置是 L4：受监督的 Loop Engineering。

这个判断并不低。很多团队今天还停在 L2 到 L3：文档有一些，工具也能调用，但任务边界、验证证据和风险记录没有稳定格式。Z 项目已经把「人怎么指挥 Agent」变成了可追踪的工作协议。

为什么不能急着冲 L5

从 L4 到 L5，差距不在自动发起更多任务，而在可证明性。

现在的 Z 项目里，人仍然承担四个关键职责：选任务、定边界、判完成、消化结果。把这四件事全交给系统之前，需要补几块基础设施。

第一，独立验收器要更强。写代码或改文档的 Agent，不适合给自己的结果打最终分。至少要有独立 checker，最好还要有确定性验证命令、回归用例、发布门禁和人工抽查。完成不能只是一句声明，要有证据。

第二，trajectory 要结构化。现在 prompt/done 已经记录了结果，但还可以进一步记录每一步工具调用、关键判断、失败原因、重试次数、成本、耗时和证据链接。没有这层轨迹，失败分析只能靠翻聊天记录。

这里可以借鉴一些统一 Agent harness 项目的做法。比如 AweAgent 把不同任务类型放进共享执行核心，并把 evaluation 和 trajectory 当作一等数据。它面向的是研究场景，但给工程项目的启发很直接：只要轨迹和评测还是散在聊天记录里，Loop 就很难被比较、复盘和训练。

第三，隔离执行要常态化。真正的 Loop 往往需要多个候选方案并行跑，最稳的方式是给每个任务或候选方案一个独立工作树。这样 Agent 可以大胆试错，人也能比较差异，而不用担心几个修改互相污染。

第四，理解债要被写进流程。Loop 跑得越快，人越容易只看摘要，不读实现。Z 项目已经有剩余风险记录，下一步可以补一类「理解债」记录：哪些改动人还没有读透，哪些业务假设仍依赖 Agent 解释，哪些模块需要人工复查。

第五，自动触发要有白名单。每天扫 CI 失败、整理候选回归、补充低风险测试，这类任务适合先自动化；权限、发布、数据写入和业务状态迁移，仍应留在人类审批之后。Loop 的边界应该按风险分层，不能只看技术上能不能自动跑。

原文最值得学习的地方

那篇文章真正有用的部分，是把 AI 协作从「技巧」拉回「工程」。它提醒了三件事。

第一，意图要写到磁盘上。模型会忘，仓库不会忘。团队的规则、偏好、禁区、验收标准和历史原因，只留在人脑里，就会在每次新会话里重新丢失。Z 项目的 prompt/done 机制，已经在这条路上走得很远。

第二，上下文要少而准。很多人以为 Context Engineering 等于把更多资料塞给模型，实际更像缓存管理。最该出现的信息进窗口，不该出现的信息留在文件、索引、状态记录或子任务里。上下文越满，噪音和冲突越多。

第三，信任要从主张走向证明。Agent 说「完成了」只是一个主张。测试通过、审计记录、评测结果、人工验收、可回放轨迹，才让这个主张有重量。Z 项目里最值得保留的习惯，就是把通过了什么、没证明什么分开写。

我还会再补一个判断：Loop Engineering 对个人能力的要求更高。Prompt 阶段，写错一句话最多得到一个差答案；Loop 阶段，设计错循环，系统会重复地产生差结果。杠杆变长以后，人的判断不能退出，只能上移。

给 Z 项目的下一步建议

如果要继续往前走，我不会先追「全自动」。更好的路线，是把 L4 做扎实。

  • 把 prompt/done 从文件约定升级成轻量任务状态机，至少包含 planned、running、passed、failed、blocked、accepted 几类状态。
  • 给每个切片生成机器可读的验收清单，方便独立 checker 逐条判断。
  • 把 trajectory 存成结构化 JSON，同时保留人能读的 markdown 摘要。
  • 给低风险循环建立自动触发器，比如每日 CI 分诊、回归候选整理、文档断链检查。
  • 高风险任务继续保留人工审批，并把审批原因写入证据。
  • 对每个已接受结果补一段理解债记录，说明人是否已经读懂关键改动。
  • 用独立工作树承载并行方案，避免多轮 Agent 修改互相覆盖。
  • 定期抽样回看失败日志，把常见失败变成新的规则、测试或上下文入口。

这些建议听起来不如「无人值守 Agent」刺激，但更接近工程现实。成熟的 Loop 会让人把注意力放到更该看的地方：目标是否正确，证据是否足够，边界是否守住，团队是否还理解自己正在发布的东西。

最后看阶段

把 Z 项目放回这套坐标系，它已经越过 Prompt 和 Context 阶段。它有明确的上下文管理、工具边界、验证命令、运行证据和风险记录，属于高级 Harness；它又通过 prompt/done/heartbeat 形成了持续切片和接力，进入了受监督 Loop。

所以我会把它标成：L4 Supervised Loop Engineering。

这也是我觉得那篇文章最适合实践者的用法。不要先问自己是不是已经会写 Loop，先打开最近十轮 Agent 日志，看里面有没有状态、边界、证据、失败和续跑。日志会说实话。