Loop Engineering：每篇文章都在讲，但没人告诉你怎么搭

最近 Loop Engineering 在持续刷屏。

公众号在刷，各种群里在讨论，我也看了好几篇文章。

每篇都有道理——五个组件、目标定义、古德哈特定律，逻辑很清晰，我都信了。

但看完之后有点空。

我的工作流该怎么 Loop 化？从哪起手？搭出来以后长什么样？

没一篇说清楚。

所以想聊聊我自己的理解，以及我们实际在做的事——我们团队搭了个叫 Talos 的系统，算是目前我见过最接近"生产级 Loop Engineering"的垂类实践。

Loop 其实只有两种形态

在我看来，Loop Engineering 这件事，放长了看只有两个终点。

第一个是通用智能 AI。 它足够强，你说一个目标，它自己把整件事推完，不需要任何预制的工作流。/goal 帮我把这个需求做上线 就这一句，剩下的它自己规划、执行、验证。这是终态，也是很多人在等的那个时刻。

第二个是过渡期里的垂类 Loop 系统。 这是现在真正可以落地的路。

用 Agent + Claude Code 这类通用 Harness，加上你自己业务领域的 Harness，搭一个属于自己场景的闭环。

说直白一点就是：把你们已经在跑的工作流 + 知识库，从"给人执行"变成"给 Agent 自循环执行"。

原来是人一步步来：写技术方案、建分支、写代码、跑测试、提 MR，每一步都靠人触发，靠人判断该不该往下走。

Loop 化之后，这些步骤还是那些步骤，只是触发和判断不再需要人盯着了。

五个组件，我用 Talos 翻译一遍

理论上 Loop Engineering 有五个组件：定时任务、工作树隔离、知识体系、连接器、子 Agent 验证。

说得都对，但太抽象。

我拿我们做的 Talos 来对照翻译一遍，会更容易理解。

定时任务，就是让系统自己会动的那个心跳。

注意，这里的"定时任务"不只是字面意义上的定时器，更准确地说是自动触发机制，包含三种形态：

第一种是时间驱动。Talos 的 dispatcher 每 60 秒轮询 TAPD，看有没有命中规则的需求，命中就自动开跑。我们的研发日报、spec 知识库刷新，也是挂在 systemd timer 上，每天固定时间自动触发。

第二种是事件驱动。飞书消息也是触发源——我在飞书群里发一句"帮我跑 xxx 需求的技术方案"，Talos 的 feishu watch 进程监听到消息，解析成命令，塞进任务队列，后续流程和定时触发走同一套执行引擎。

第三种是状态变更驱动。TAPD 里的需求状态变化（比如"已评审"）、GitLab 的 MR 事件（合并、评论、reject），都可以作为触发信号，反哺进 Loop 的下一轮决策。

没有这些触发机制，系统就是死的，还是得靠人来踢一脚才会动——那就不叫 Loop 了。

工作树隔离，就是让多个任务并行不打架。

每个需求在 Talos 里都有独立的工作目录和 git 分支（orphan 分支，req/{dir} 命名），Agent 在自己的沙盒里改代码，改完再合并，完全不干扰别的需求。并发抢占也解决了——Worker 写 runner_id 推 git，push 失败说明被抢走，靠 git 原子性做分布式锁，不用额外的 Redis 或者数据库。

项目知识体系，这个最关键，也最容易被低估。

我们有 spec 知识库、CLAUDE.md、corrections.log 反哺日志、hints.md……这些不是辅助材料，是 Agent 每次启动时的上下文燃料。没有这套东西，每次 Agent 开一个新会话都得从零解释一遍项目是什么、规范是什么、上次踩过什么坑。Loop 跑快跑准，很大程度上靠这块沉淀得有多扎实。

连接器（MCP），让 Agent 真正能在你的工作环境里干活。

光会写代码不够。Talos 接了需求管理系统、CI/CD系统、代码仓库、飞书（通知和人工决策）、用例关系系统、数据库查询、日志查询、trace查询、Prometheus查询等等各类系统。从发现问题 → 写代码 → 提 MR → 通知人 → 人批了 → 自动流转，这一整条链接通了，才叫闭环。

子 Agent 验证，做事的和检查的不能是同一个。

Talos 里，Dispatcher 负责调度、Worker Job 真正执行、Reflux 监听 GitLab webhook 做反哺。还有一层专门的 LLM Judge，跑推断类任务——比如判断 PRD 质量够不够、plan.md 的影响面有没有超红线。一个负责干，另一个负责独立验。

Talos 到底是什么

用一句话定位：

Talos 是一个以状态机为目标定义框架、以 Harness 为内嵌约束层、以 corrections 反哺为飞轮、覆盖产研全链路的生产级 Loop Engineering 系统。

状态机（16 个状态 + 21 个 transition + 三层门禁）就是"目标定义"——每一步的完成条件都是机器可验证的，比一句 /goal 粒度细得多。

两段式准入（标题关键字 + 影响面白名单）、P0 永不自动化、MAX_ATTEMPTS 上限……这些是 Harness，是约束层，防止 Agent 把系统搞乱。

corrections.log 反哺、spec-patch 沉淀……这是飞轮，让 Loop 越跑越准，而不是永远停在 Day 1 的水平。

但我要说一个很多人没提到的关键点——

"不再手写 Prompt"，指的是运行时不需要人介入，不是说不需要预制 Skill。

Talos 的 Worker 跑的是 Zeus Skills（req-plan、req-impl、req-push……），这些 Skill 文件里的提示词，是我们提前设计好的。Loop 决定什么时候调用哪个 Skill，但 Skill 本身的内容，还是人工在前期写定的。

所以更准确的理解是：Loop Engineering 消灭的是运行时的人工干预，不是前期的工作流设计。 反而，工作流设计得越扎实，Loop 就跑得越稳。

早期设计的一个坑

搭 Talos 的时候踩过一个坑，值得聊一下。

最初的设计里，状态机是 Talos 的主驱动——dispatcher 每轮扫描需求状态，判断该往哪走，然后调用对应的 Skill。AI 只负责在某个 Skill 格子里干活，干完交回，状态机接管，决定下一步去哪。

听起来挺完整的，但用起来有点拧巴。

最聪明的活儿——写代码、出技术方案——交给 AI 了。但推动整个流程往前走的那只手，还是我写的 if-else。

而且每次工作流有新变化，我就得去补规则。有一次，工作流新加了"记录 Agent 调用日志"的设计，Talos 跑到推送环节，发现工作区有未提交文件，门禁直接拦下。两边都没错，但拼在一起就停了——等我去打补丁。

现实的分支是无穷的，我的策略是有限的，这条路走不通。

现在的设计：目标契约

意识到这个问题之后，我们把架构反过来了。

核心转变是：不再用流程驱动 AI，而是用目标约束 AI。

现在向 Talos 下发任务，不是说"先跑 plan、再跑 impl、再跑 push"，而是给它一份目标契约（GoalSpec）：

target:          这个需求的需求ID
desired_outcome: mr_draft（我想要的结果）
success_criteria:
  - 所有单测通过
  - MR 描述完整
stop_policy:
  ask_on_high_risk:       true   # 碰到高风险操作先问我
  ask_before_schema_change: true  # 改表结构前一定要停
  no_merge:               true   # 不能自动合并
budget:
  max_minutes: 60
  max_steps:   20

我只说我要什么、边界在哪——怎么推进，它自己决定。

Talos 没消失，它退到了"治理"的角色。状态机还在，但它现在是进度账本，记录走到哪了、尝试了几次、有没有超预算——不再是指挥棒。门禁还在，但它们是 AI 决策时的校验，不是驱动流程的那只手。

控制权交给 AI，否决权留给 Talos。

HITL 也变了。原来是"撞到我预设的墙才停"，现在是 stop_policy 写进目标契约里，AI 自己在推进过程中判断有没有踩到边界——踩到了主动停下来找人，而不是傻傻撞墙。

回到那次推送报错——目标驱动的 Talos 看到"有未提交文件"，自己判断出这是调用日志不是业务变更，提交掉继续。整件事它自己消化了，不需要我知道。而真正该找我的事（改数据库 schema），stop_policy 一个都不会漏。

这件事的本质

聊了这么多，我觉得垂类 Loop 系统的本质就一件事：

把你已经在跑的工作流，从"人来执行"升级成"系统自循环"。

你的 SOP 是什么、知识沉淀在哪、质量门禁怎么卡、出问题怎么找人——这些都不用重新发明，你只是把执行的角色，从人换成了 Agent。

工作流设计有多扎实，Loop 就跑得有多稳。

这也是为什么我不太信"用了 Loop Engineering 就不用设计工作流了"这种说法。工作流设计的工作量没少，甚至更多——因为你得把以前靠人"临场判断"的那些东西，变成系统能自动识别和处理的逻辑。

人遇到奇怪情况会说"算了，我自己改一下"。Agent 不行，它只会按照你给的边界走。所以前期的工作流和知识体系设计，才是 Loop 能不能跑起来的真正地基。

我们能放心交给云端自动跑的，现在还只是那一小撮风险低、规则清楚的需求。大部分活儿，还是得人盯着和 AI 一起干。

但方向是对的，我越来越确定这一点。

剩下的就是慢慢验证：多覆盖一类需求、多交出去一点控制、多看一眼 AI 到底能不能自己扛住。

走错了退回来，想通了再往前走。😌