Loop 工程实战：把 Agent 循环写成可维护的任务运行时
基于“架构师”公众号若飞文章整理。公开页不全文转载原文，重点提炼工程结构、可复用规则、OpenClaw/Codex 落地建议和可沉淀 skill 方向。
来源信息
| 原文 | Loop 工程实战：从任务循环到可维护闭环 |
|---|---|
| 作者/账号 | 若飞 / 架构师（JiaGouX） |
| 导出状态 | 已导出 Markdown 到本地 source，并生成结构化 intake analysis JSON。 |
| 版权处理 | 本文只做分析与短摘录，不复制原文长段内容。 |
Article Intake 结果
| 主类型 | 开发实践 |
|---|---|
| 主题标签 | AI Agent, Loop Engineering, Agent Loop, Harness, 状态机, 任务运行时, CI Pipeline, 前端副作用 |
| 价值判断 | 可沉淀 skill, 可写报告, 可加入知识库 |
| 分析模板 | 开发实践 |
| 路由 | skill_candidate + knowledge_entry + full_report |
| 下一步 | 提炼一个 Loop Runtime/Agent Task Loop 设计检查 skill。 |
核心框架
文章最重要的判断是：Agent Loop 不应被当成一条更长的 prompt，而应被当成任务运行时。传统工程里已有类似结构：任务队列、状态机、CI Pipeline、前端状态流、工作流引擎。Agent 带来的变化，是循环体里多了一个会规划、会调用工具、也会犯错的模型。
State
保存当前任务事实。不能只靠聊天上下文记忆，因为长任务会压缩、遗忘和混淆历史。
Intent
根据状态决定下一步。关键是把“该做什么”从模型临场发挥里部分拿出来。
Action
访问文件、日志、issue、CI、PR、数据库等外部系统。读写权限要分级，写入动作要收口。
Verify
检查结果是否可信。执行者不能只靠自我声明完成，需要独立测试、日志、链接、事实来源或人工复核。
Commit
把候选结果写入真实系统。计划、diff、comment 草稿和真实提交应分开处理。
Trace
记录每轮发生了什么。过程记录会成为改进 Skills、Memory、工具和提示词的材料。
最小闭环
文章给出的工程直觉可以压缩成一条链：
state -> intent -> effect -> event -> state如果要写入真实系统，再加一道验证与提交：
state -> intent -> effect -> verify -> commit这条链很朴素，但它解决了 Agent Loop 的几个核心问题：状态不是散在聊天里，副作用不是随手发生，重试不是无限循环，完成不是模型自己盖章。
为什么 CI 失败分流适合做第一版
文章推荐从 CI 失败分流这类小闭环开始，而不是让 Agent 直接“自动优化整个系统”。这个判断很稳，因为 CI 失败分流具备几个好条件：输入明确、日志可引用、结果容易人工复核、失败可接手、写入动作风险低。
| 候选场景 | 适合原因 | OpenClaw/Codex 映射 |
|---|---|---|
| CI 失败分流 | 日志明确，分类可验证，建议可人工确认。 | 读取失败 job、PR、commit，输出证据链和修复建议。 |
| 文档命令校验 | 读多改少，命令输出就是证据。 | 检查 README、技能说明、安装步骤是否还能跑通。 |
| PR 风险预检 | diff 明确，能输出候选风险清单。 | 在提交前做独立上下文 review 和测试建议。 |
| 依赖升级扫描 | 范围可限制，适合报告化输出。 | 扫描 package、lockfile、breaking changes 和影响目录。 |
| changelog 候选生成 | 读 git history，结果由人编辑确认。 | 生成发布说明草稿，不直接发布。 |
副作用要收口
这篇文章把前端状态流经验迁移到 Agent Loop：先推导候选结果，再集中处理提交动作。这个观点对真实 agent 系统非常关键。
| 动作类型 | 建议边界 |
|---|---|
| 读文件、读日志、读 issue | 默认允许，但要记录来源。 |
| 生成计划、diff、comment 草稿 | 候选结果，不直接提交。 |
| 写文档、开候选 PR | 低风险写入，但 diff 必须可审。 |
| 改权限、部署、删数据、对外承诺 | 默认人工确认。 |
| 重试外部 API | 必须有限流、退避和次数上限。 |
如果把这些边界提前写进控制面，Agent 的能力就能在执行面释放，而不会变成难以审计的自由发挥。
容易踩的坑
聊天记录当状态库
聊天上下文会被压缩和遗忘，不能承担唯一事实源。长任务需要结构化状态记录。
权限全交给 Agent
模型可以建议动作，但哪些命令只读、哪些 API 可写、哪些动作需确认，要写在系统里。
没有独立验证
没有测试、lint、链接检查、事实来源或人工复核，就容易把“说得像完成”当成“真的完成”。
只看结果不看过程
Trace 能暴露模型误判、工具不稳定、规则过宽和验证器过松，是后续改进的燃料。
对 OpenClaw 的落地建议
- 为长任务建立统一状态文件：goal、phase、attempt、evidence、proposal、handoffReason、updatedAt。
- 把“候选输出”和“外部提交”分成两步；发消息、发邮件、改权限、部署、删除数据都走确认点。
- 给每类 Loop 定义最大步数、最大重试、停止条件和人工接管原因。
- 把过程 trace 写成可回放事件流，后续用于更新 memory、skills 和工具输出格式。
- 先从报告生成、文章分析、CI/文档校验这类读多改少场景开始，不急着做高风险自动修复。
- 沉淀一个 `agent-loop-runtime-audit` skill：输入一个任务循环设计，检查 State、Intent、Action、Verify、Commit、Trace 是否齐全。
我的判断
这篇文章比很多“Agent Loop”讨论更实用，因为它没有停在概念层，而是直接把 Loop 写成状态、事件、reducer、intent selector 和执行器。它真正想说的是：Agent 的智能应该被放进一个工程骨架里，而不是让工程骨架消失在自然语言 prompt 里。
对我们来说，它最适合作为 OpenClaw 长任务系统的设计参考。下一步可以把它沉淀成一个检查表：任何“让 Agent 持续做某事”的需求，都先问有没有状态源、证据链、验证器、提交点、重试上限和人工接管。答不出来，就先别放长线自动跑。
原文入口
完整文章请阅读原文。这里保留一个短摘录作为报告依据：
Loop 更接近任务运行时，不只是一条更长的 prompt。
| 微信公众号原文 | https://mp.weixin.qq.com/s/zOWRaGZUMWee2dRixmL-sA |
|---|