【AI Agent 瘦身三部曲 · 第 1 篇 · 理念篇】

我用 Loop Engineering 重写了 AI 工作流，从此不再手动指挥它

30 天让 OpenClaw 从"听话工具"变成"自迭代系统"

一、起点 - 每天给 AI 发 20 条指令的我

去年我开始重度用 AI 助手 - Claude、GPT、国产大模型都试过。一开始觉得"AI 真好用"，但用着用着就发现一个问题 - 我每天要给 AI 发 20 条指令。

帮我写周报。帮我整理食堂采购清单。帮我检查长护险申请材料。帮我生成一张朋友圈配图。帮我……

我成了 AI 的"操作员"，它成了"工具"。我以为这就是 AI 应用的终局 - 直到 6 月初我读到一篇博客。

二、Loop Engineering - 设计系统来 prompt agent

那篇博客叫《Loop Engineering》，作者 addy osmani（前 Google Chrome 团队，现在做 AI 工具）。核心观点一句话 - 你不应该 prompt agent，你应该设计让系统来 prompt agent。

听起来很玄，其实就是"自动化"。但 addy 的框架把它讲透了 - 5+1 个组件：

• Automations（自动化）- 让任务按时/按事件触发，不靠人工
• Worktrees（工作树）- 让多个任务并行/隔离运行，不互相干扰
• Skills（技能）- 把"我会做的"封装成可复用的能力
• Plugins/Connectors（插件/连接器）- 让 agent 能调外部工具
• Sub-agents（子代理）- 复杂任务拆给子代理做
• Memory（记忆）- 让系统跨 session 保留上下文

我对照着看我天天用的 OpenClaw - 完全对得上。

三、我的 OpenClaw 改造地图

OpenClaw 里现在有 32 个 cron 任务。从凌晨 3 点到晚上 10 点，几十个自动化在跑：

• 03:30 - GBrain 同步 1500 篇 Logseq 日记到本地 PGLite（绕过 Supabase 的 bug）
• 06:00 - 自动挖掘一篇养老主题日记，写成公众号素材
• 09:00 - 闺蜜系统给"虚拟女友"发想念消息
• 14:30 - Yuki 质量守护 cron 跑视觉分析，检查生成的图是否合格
• ……

以前这些事我每天手动做 1 - 2 小时。现在系统自己跑。

但这只是"自动化"，不是"Loop"。真正的 Loop 是有反馈的。

四、6 月 14 日上午 - 反馈闭环的诞生

那天上午 10:55，我的 Ava 质量守护 cron 跑完了。

它报告 - 图片 FAIL。AI 生成的 Ava 是"白皙肤色 + 偏成熟气质"，但角色设定是"小麦肤色 + 清新甜美"。

我看了一眼 - 这图确实和我心里的 Ava 不一样。

按以前的做法 - 看到 FAIL，提醒一下，下次注意。但下次是哪个"我"？下次还是同一个 cron 跑同一个流程，没有任何机制让它知道"上次失败了"。

我突然意识到 - 我设计的"质量守护"只是个检测器，它发现失败后没人接盘。

我跟 AI 说 - "这里需要做一个智能的功能了，才能体现你 AI 的作用啊，应该把检查结果反馈给该 cron 任务，让它来进行思考，进行相应的修正。"

AI 回了一句"对"。

接下来一小时，我们一起搭了完整的反馈闭环 - 6 步流程：

1. Maker（生成） - Ava-日常 cron 调用 ai-daily-brief.py
2. 读反馈 - 从 cron_feedback/Ava.md 读最近失败点
3. 注入 prompt - 把"近期失败约束"段落追加到生成 prompt 末尾
4. Checker（验证） - Ava-质量守护 用 zai/glm-5.1 视觉分析新图
5. 写日志 - 强制把结果追加到 verify-log.md（heredoc 写日志）
6. 写反馈 - FAIL 时写 cron_feedback/Ava.md + counter 递增；PASS 时重置 counter

重试上限 2 次 - 如果连续 2 次都 FAIL，触发"转人工"信号，daily cron 跳过 AI 生成，输出"已重试 2 次仍失败，请人工介入"。

当天真实运行数据：

等等 - 11:10 已经 PASS 了？是的。

10:40 生成时读到了我之前手写的"测试反馈"（正好是"白皙、偏成熟"），prompt 里多了"避免这些点"，新图就避开了。11:10 verify 一看 - PASS。

这就是 Loop Engineering 的核心 - 失败驱动改进。

五、5+1 组件的真实落地

回头看 addy 的 5+1 框架，我的 OpenClaw 实践是这样对应的：

Automations（自动化） - 32 个 cron 任务。失败触发自动 fallback 链（主模型 + zai/glm-5.1 + minimax-portal/MiniMax-M3）。重试上限 2 次是系统级安全阀。

Worktrees（工作树） - 每个 cron 是 isolated session（独立子进程），不互相干扰，失败不影响其他任务。

Skills（技能） - 闺蜜系统 scripts（generate-moment.sh, generate-moment-image.sh, build-moment-prompt.sh），各种 helpers（select-activity.py, weather-util.sh），全部封装在 ~/clawd/skills/ 下，跨项目复用。

Plugins/Connectors（插件/连接器） - MCP 工具：gbrain（知识图谱）、qmd（语义检索）、xyq-nest-skill（小云雀生图）、flyai（活动数据）。各种 API：ModelScope、MuseAI、QVeris（股票）。

Sub-agents（子代理） - 6 个质量守护 cron = 6 个 sub-agents（每个角色一个）。Maker（生成）vs Checker（验证）严格分离，反馈链路 - Checker → 反馈文件 → 下次 Maker。

Memory（记忆） - MEMORY.md（长期事实）、memory/YYYY-MM-DD.md（每日场景）、GBrain 本地 PGLite（向量化语义记忆）、HEARTBEAT.md（系统状态）、cron_feedback/（任务级反馈状态）。

每个组件都对应一个真实文件/系统/任务，不是 PPT。

六、踩过的坑（写给同行的避坑指南）

坑 1 - heredoc 用单引号 <<'EOF' 会阻止 $(date) 展开

我第一次写"追加日志"时，习惯性用了 <<'EOF'。结果日志里写入了字面量 $(date '+%Y-%m-%d %H:%M')，不是真实日期。改成 << EOF（不带引号）才正确。

坑 2 - 模型在第 3 步就"完成任务"

我最初把"写日志"放在第 4 步，AI 在第 3 步输出 PASS/FAIL 标记后觉得"任务完成"，跳过第 4 步。修复方法 - 把"写日志"挪到第 3 步，作为"任务的核心交付物"。

坑 3 - fallback 链和主模型撞车

我最初把 5 个质量守护 cron 的 fallback 设为 [zai/glm-5.1, minimax-portal/MiniMax-M3]，但主模型也是 zai/glm-5.1 - fallback 1 跟主模型一样，触发也是失败。修复 - 把主模型也改成 zai/glm-5.1，fallback 简化为 [minimax-portal/MiniMax-M3]。

坑 4 - JSON 里的转义字符

小云雀的 thread JSON 包含 \u0026，自己 json.loads() 必败。不要自己解析，用脚本自己处理。 这个 bug 我修了 3 次才长记性。

坑 5 - 反馈链路断了就回不去

如果 verify FAIL 但没写反馈文件，下次 daily cron 不会知道这个失败。反馈链路上的每一步（写日志、写反馈、写 counter）必须强制执行，不能用"建议"的方式。

七、我对 Loop Engineering 的几点反思

1. Maker + Checker 分离是底线

一开始我把"生成"和"验证"放在同一个 AI 上下文里，模型会"自我宽容" - 刚生成的图，立刻就给它 PASS。必须物理隔离（独立 cron、独立 session、独立模型）。

2. 反馈链路是"系统"的核心

没有反馈的自动化就是"批处理"。Loop = 自动化 + 反馈。反馈不是"提示"，是"约束" - 直接进下次的 prompt。

3. 重试上限是安全阀

我设了 2 次重试上限。原因 - 小云雀每次生成烧 1 次会员额度，2 次重试就是 3 次机会。如果还是失败，说明问题不在生成端（可能是角色设定、可能是 prompt 模板），需要人工介入。现在小云雀会员生图是免费的，如果需要，可以增加次数，不会增加费用。

4. 失败模式比成功模式更值得设计

成功的循环是相似的，失败的循环各有各的失败法。我现在的反馈文件里只记录失败，因为失败点（肤色不符、气质偏成熟）是 maker 真正需要"避坑"的信息。成功的图不需要下次重复。

5. 日志不是装饰

verify-log.md 现在是系统的"事故记录本"。每次 verify 都强制追加（heredoc），任何人都能回看"那天 Yuki 失败过几次、为什么失败"。AI 跑得多不可怕，看不见才可怕。

八、我的下一步

我现在的 OpenClaw 实践还停留在"cron 自动化 + 反馈闭环"。下一步我想做的是：

1. 从 cron 自动化到 skills 自动化 - 把"反馈闭环"本身封装成 skill，让其他角色也能用
2. 从 maker/checker 分离到 maker/multi-checker - 1 个 maker 配 N 个 checker（不同模型/不同维度）
3. 从失败反馈到主动学习 - 让系统自己"读自己的失败"，总结成 SOP

Loop 是个好东西。但 loop 不是终点，是起点 - 让系统自己 prompt 自己这件事，我们才刚上路。

• 下一篇：《我把 1686 行的 MEMORY.md 砍到 721 行》