Loop Engineering（循环工程）这个词在 AI 开发圈越来越热，但大多数讨论停留在抽象概念层面。最近，拥有 25 年以上软件工程经验的 Seb（@plainionist）在 X 上分享了他当前的实战配置，把一个模糊的理念变成了可复制的工程实践。
什么是 Loop Engineering？
Seb 梳理了社区对 Loop Engineering 的共识，核心由六个模块组成：
Sub-agents（子代理）：多个专业 Agent 协作。一个负责执行，一个独立验证，一个把控全局目标。
Worktrees（工作树隔离）：通常用 Git worktree 实现，让多个 Agent 在同一仓库上并行工作而不冲突。
State（状态持久化）：把状态存在对话之外，比如 STATE.md 或 issue 看板。这对长周期或多轮循环至关重要。
Skills（技能文件）：把规范、标准和可复用流程写成 SKILL.md，避免每次会话重新推导上下文。
Plugins & Connectors（插件与连接器）：通过 MCP 等协议连接外部工具（issue 追踪、PR 系统、数据库），让 Agent 能行动而不只是提建议。
Automations（自动化触发）：定时或事件驱动的流程，自动发现任务、分类优先级并启动执行。比如 cron job、/loop 命令或 GitHub Actions。
Seb 的具体配置
三 Agent 分工
Seb 使用 SwarmForge 框架（由 Robert C. Martin 设计），把角色拆成三个独立 Agent：
- Architect（架构师）：负责制定计划
- Implementer（实现者）：只修改生产代码
- Verifier（验证者）：检查结果并编写测试
规划、编码、验证三权分立。更有趣的是，Seb 在 Architect 的指令里加了一条规则："如果需要代码细节，不要直接读代码，用子代理去分析。" 结果 GitHub Copilot 会自动生成临时子代理来完成分析和验证任务。
Worktree 隔离
SwarmForge 为每个角色维护独立的工作空间和分支。工具会自动创建并维护每个 Agent 的 worktree，同时提供指令约束 Agent 的行为边界。
状态管理
Seb 的状态系统极简：
- Tickets：仓库内的 Markdown 文件，未完成的 ticket 就是待办，完成的直接删除
- Implementation Plan：当前 ticket 的详细拆分，由 Architect 编写、团队共享，放在
agent_context文件夹 - Logbook：团队内部的手交接记录，Seb 自己从不看，纯粹给 Agent 协调用
Skills 设计
Seb 刻意把 Skills 设计得很精简，只保留可复用的工作流：
- 编写 implementation plan
- 拉取下一个 ticket
- 运行 retrospective（复盘）
他明确区分了 Skills（能力描述）和知识库（领域知识），不把架构文档塞进 Skills 文件。
插件与自动化
目前 Seb 没有使用任何 MCP 服务器或 CLI 插件——所有相关产物（ticket、知识库、代码）都通过文件系统直接访问。不过他的 AI 团队最近写了不少辅助脚本，用于代码库发现、回归检查和团队工作流。
自动化方面，Seb 选择半自动模式：他手动把一批 ticket 标记为 "ready"，然后让团队按优先级处理。高风险变更需要 Architect 评估后向他申请批准。全自动运行对他来说还太早，"否则我会堆出一 pile 未审批的工作。"
作者的转变
Seb 说他的 "loop" 还不能完全脱离他运行，但他的角色已经发生了根本变化：
我几乎不再直接写代码了。我也不再花大量时间解释具体的编码步骤。我写 ticket 定义新功能和改进，然后 review 最终结果。大多数情况下直接批准，偶尔写更多 ticket 来跟进 review 反馈。
所以价值不在于全自动化。价值在于，越来越多的工作从"做具体改动"转移到了"改进交付这些改动的系统"。
这句话精准地概括了 Loop Engineering 的本质——不是让 AI 替代人，而是让人从执行层升级到系统层。