Loop Engineering：让工作自己回到系统里

最近我对 Loop Engineering 的理解变了不少。

一开始我把它理解成自动化。让 Agent 定期回来，检查网站，扫一下 Wiki，看看有没有坏链接，顺手修掉一些小问题。

这个理解有用，但不够。

真正让我改观的，是最近做 Aries OS。

Aries OS 是我正在搭的一套本地优先个人工作系统。它把每日决策、知识库、项目、阅读、播客、健康和理财复核放进同一个工作台，让 Agent 能在明确的数据源、权限和验收规则里持续协作。对我来说，它也是一个真实的试验场，用来验证 AI 工作流能不能长期运行，并且在一轮轮工作里积累经验。

它已经不只是单个页面或一次性脚本。Today、Fitness、Reading、Podcast、Gallery、Inbox、Projects、Ledger 都在里面。每个模块都有数据源、页面、只读边界、写回白名单、截图证据和 QA 合同。

这时候会发现，让 Agent 做事很容易，难的是让工作一轮一轮回来时，系统还知道自己在干什么。

比如 Aries OS 的一轮 review loop，不能只说“帮我优化一下”。这句话太空。Agent 可能改了视觉，顺手扩了功能，又把只读模块改成可操作入口，看起来很努力，实际风险变大了。

后来我们把它拆清楚。

这一轮只看 Today、Fitness、Ledger。

Today 要把首屏后面的信息压成日常复核流，减少工程状态词。Fitness 要把打卡表单收成票据式本地记录界面，不扩大写回。Ledger 要从 skeleton 收成只读复核队列，不碰交易、提醒、行情刷新、真实账户和投资建议。

这时 Loop Engineering 才开始像一件工程事。它是在给一轮工作写清目标、范围、证据和停止条件。

我做个人网站时，也有类似体感。一个页面上线以后，它并没有结束。今天是移动端 career 卡片太高，明天是 Notes 在宽屏上留白太大，后天是文章页分享按钮的交互不够顺。每次都不算大事，但它们会回来。

过去做广告也一样。提案交出去，客户会回来。KV 定稿，执行会回来。活动上线，数据和复盘会回来。一个项目麻烦的地方，往往在它后面反复回来。

Loop Engineering 最打动我的，是它把注意力从单次执行，移到连续工作。

我现在会把一个 loop 拆成六个问题。

它什么时候开始。

它看哪里。

它做什么。

它怎么检查。

它把结果写回哪里。

它什么时候停。

这六个问题听起来普通，放到真实项目里，每一个都很关键。

个人网站巡检可以从上线前、改完代码后、收到反馈后开始。它要看首页、案例库、Notes、Contact、简历入口、移动端、宽屏和中英文切换。它不能随便看看，要按目标用户走一遍，检查叙事、交互、文案和视觉。验收不能只靠写代码的 Agent 自己说没问题，要有截图、清单、真实浏览和具体页面位置。结果可以写进项目记录、优化 loop 规格、待办或 Wiki。涉及发布、删除、付费、账号和公开边界，就要停下来等人。

Aries OS 让我看到更复杂的一层。

Fitness 可以写本地 checkin store，但不能随手改历史每日笔记。Reading、Podcast、Gallery、Projects、Ledger 多数时候只能只读。Inbox 可以窄写回，但要备份、检查 hash 和 mtime，还要写日志。Ledger 可以做今日理财复核，但不能做交易动作，也不能把自己伪装成投资建议。

这些边界如果没有写进 loop，Agent 很容易用“帮你完成”的姿态越界。

所以我现在会把 Loop Engineering 看成一张管理表。目标是什么，哪些文件可以动，哪些模块只能读，验收证据是什么，失败后写到哪里，遇到哪些动作必须停下来问人。

它和普通定时任务最大的差别，也在这里。

定时任务只是到点执行。Loop 要能根据上一次的结果，改变下一次的动作。比如一次网站审计发现移动端卡片留白太高。修完以后，下一轮就不该只重复检查移动端，而要把卡片高度、横滑手感、宽度和文本折行变成新的验收点。

这才叫系统长了一点经验。

Aries OS 还有一个更具体的例子。有一轮 Ledger Review Queue，生产 Agent 做完后，验收 Agent 独立检查，发现页面里还残留 `Review Queue`、`Markdown`、`health.json` 这类工程词。主线程再修正文案，并补测试禁止这些词回到用户界面。

这件事很小，但它说明了一个重要原则。

检查要有证据。

证据可以是 diff、测试、build、lint、浏览器截图、console 没有 error，也可以是页面里确实没有不该出现的文案。

如果一个 loop 只有执行者，没有检查者，它很容易把自我确认包装成交付。如果一个 loop 有检查者，却没有状态文件和交接文档，下一轮还是会漏掉上一轮发现的问题。

所以我现在越来越相信，Loop Engineering 的核心资产藏在那些看起来很朴素的东西里。

项目状态文档。Handoff。QA 截图。运行记录。只读边界。写回白名单。失败原因。下一轮必须先看的事项。

这些东西让 Agent 能接上工作，也让人能审计 Agent。

这件事很诱人，也很危险。

诱人的地方在于，它会让很多维护工作有复利。以前靠我想起来，现在系统可以提醒。以前靠我记住，现在 Wiki 可以接住。以前每次从零讲背景，现在 Agent 可以读上一次的状态。

危险也很明显。如果验证没做好，loop 会稳定地产出错东西。如果权限没管住，loop 会把本来该停下来的动作继续往前推。如果人开始偷懒，loop 会慢慢替你做判断。

所以我不太愿意把 Loop Engineering 写成自动化狂欢。它更像一门管理学。你管理的是一条会反复发生的工作链路。

哪些事可以交给系统定期回来。哪些事只能让系统提醒，不能让系统决定。哪些结果必须有人看。哪些动作必须停。哪些经验要写回去。

我现在对自己的判断也挺保守。

Loop 最适合先放在低风险、可验证、可写回的任务里。比如 Wiki lint、双链检查、个人网站体验巡检、文章发布前清单、案例库图片命名检查。

真正涉及审美、公开边界、合作承诺、账号权限、发布动作，我还是希望 Agent 走到门口停一下。

停下来问我。

Aries OS 也让我补了一条判断。很多工程工作更适合目标驱动，比如把 Today Real Brief 收到可用，把 Fitness 本地打卡做稳，把 Ledger 只读复核队列做好。这些事有清楚终点，适合一轮一轮验收。

长期节奏驱动更适合持续观察外部状态，比如上线后健康巡检、依赖风险观察、公开链接检查、内容发布后的 SEO 和 OG 复核。

AI 工作流也是这样。

以前我更关心 Agent 能不能把一件事做完。

现在我更关心，一件事做完以后，它能不能带着证据、边界和下一步回到系统里。

如果能，它就开始有复利。

如果不能，它只是一次很聪明的帮忙。

这大概就是我现在理解的 Loop Engineering。

让工作自己回来。

让系统记得上一次。

让 Agent 在证据里推进。

让人把判断留在最该出现的地方。