Loop Engineering
Loop Engineering 指的是用一套设计好的循环系统，代替人工每次向 Agent 发送指令。在我第一次听到这个词的时候，我脑子里第一个蹦出来的就是“淦，这也能造个新词”。
但我本身是认同这套想法的，这也是 FylloCode 的一个目标。早在 FylloCode 项目初始化的时候，我就已经在考虑这条路径：由定时任务驱动固定的工作流，或者驱动开放性的 Agent 任务。所以 FylloCode 一开始就设计了任务、工作流、第三方集成、定时任务这几大部分。只不过目前还在打磨前面的 ACP Agent 和 Agent 工作流，还没有来得及把 cycle 这一层完整做出来。
我觉得 Loop Engineering 不是凭空冒出来的新东西。我们回头看研发同学的日常工作，本身就是一个又一个循环，只不过以前我们身处其中，并没有把它抽象成一个系统。
举个研发同学的例子：
- 早晨起床先看一眼手机，有没有收到昨晚的告警通知
- 到工位打开任务管理系统，看看有没有新分配的任务，昨天的 bug 测试是否验收通过
- 拿到一个需求或 bug，开始做系统分析和方案设计
- 修改代码，部署测试环境
- 通知上下游任务完毕
- 继续关注测试反馈、线上指标和下一批需求
需求、代码、测试、发布、监控、反馈会不断回到下一个任务里。研发同学的价值也不只是把某一次需求做完，而是在这个循环里持续做判断：哪里应该自动化，哪里应该沉淀规则，哪里必须保留人工评审，哪里可以交给系统自己跑。
到了 Agent 时代，大模型公司希望 Agent 接手我们一项又一项任务，自然就会走到这一步。只不过现在所谓的 Loop 还处在很早期。如果完全以 AI Native 的方式执行循环，它会消耗大量 token，可能只有大模型公司才能用得起。我甚至会觉得，这也是他们愿意推动这类形态的原因之一。
所以在 FylloCode 最开始设计的时候，我就决定优先使用 API 的方式做集成。理由很简单：API 集成更加快速、稳定，而且不消耗 token。像任务读取、状态回写、流水线触发、工单更新这类高频动作，如果每次都让 Agent 通过自然语言和工具调用去“理解一遍”，我们的钱包会瘪的很快。
Loop Engineering 真正有价值的地方，是把应该转什么-什么时候停-结果写回哪里-下一次如何复用这些问题工程化。
一个 Coding Loop 需要什么
如果要设计一个 Coding 场景下的 Loop，我认为至少需要这几部分：
- 定时系统：这是很多 Loop 的起点，它负责让任务不只依赖人工发起。
- 信息来源：比如项目管理系统、指标监控系统、日志系统，或者用户指定的一段 prompt。
- Agent：自主性 Agent 接收到信息后，需要先分析甄别，再决定是否继续行动。
- 工作流：信息可以直接交给 Agent，也可以由定时系统触发固定工作流；两者也可以组合。
- 知识沉淀：已经解决过的问题、做过的判断、踩过的坑，需要能被下一次任务复用。
- 结果回写：每次循环的执行结果，最好能回到原来的任务、工单、监控或项目上下文里。
这几部分看起来像产品功能列表，但本质上是架构边界。定时系统负责触发，信息来源负责输入，Agent 负责判断，工作流负责约束动作，知识沉淀负责复用，结果回写负责让循环闭合。
这也是我做 FylloCode 时一直在考虑的问题。Agent 工作流不应该只是“把 prompt 包起来循环执行”，而应该是一套可追踪、可沉淀的研发系统。
定时系统
这是 Loop 的出发点。OpenClaw 让我惊喜的其中一个原因，就是它内置了定时任务。这样 OpenClaw 可以主动来与用户沟通。
我认为一个好的定时系统不应该只是 cron 表达式。它至少应该能选择项目、运行自定义 prompt、选择不同的 Agent 和模型，也应该能看到运行频率、运行状态和运行环境。一个任务可以运行在本地，也可以运行在云端，但它背后的项目上下文、权限边界和执行记录必须清楚。
上面提到的 Agent、工作流，以及没有展开讲的 Skills、MCP，我认为都应该能在一个任务里被设定。否则定时系统就只是“定时叫醒 Agent”，而不是一个真正可以承载研发循环的调度入口。
信息来源
信息来源可以多种多样，但一定要有。
它可以是项目管理系统里的新任务，就像 FylloCode 第一个对接的是云效工作项。它也可以是监控系统里的告警、日志系统里的异常模式，甚至是一段用户写好的 prompt，比如 调用 xx skill 检查 xx 状态。
信息来源也不一定只在定时任务开始的时候使用。它可能以固定频率触发，间隔检查是否达到了某个条件。比如某条流水线是否失败、某个 MR 是否通过评审、某个任务是否进入了可处理状态。
这里我更倾向于把“信息读取”做成确定性的 API 能力，而不是完全丢给 Agent 自己探索。Agent 适合做判断和综合分析，但高频、结构化、可预期的信息获取，应该尽量走稳定接口。这样 Loop 才不会把 token 花在重复且低价值的事情上。
Agent 与工作流
Agent 和工作流是两种不同的东西，但它们可以组合。
一种方式是由自主性 Agent 处理开放信息，针对不同情况调用不同工作流。比如它看到某个告警后，先判断影响范围，再决定是创建 bug、通知负责人，还是启动一个诊断流程。
另一种方式是由固定工作流直接触发，中间某个节点交给 Agent 处理相关信息。比如先拉取任务、创建 worktree、读取项目规范，再让 Agent 做方案分析，最后进入实现或等待人工确认。
我更偏向后者和前者结合，而不是把所有权都交给 Agent。因为在真实研发里，开放判断和确定流程都存在。我们要做的不是把系统设计成“完全自由”或“完全固定”，而是把不确定性关在合适的位置里。
Agent 可以自由思考，但它应该在明确的项目边界、权限边界和工作流边界里思考。工作流可以固定推进，但在需要判断的时候，也应该允许 Agent 做分析和取舍。这两者结合起来，才有可能既有自动化收益，又不牺牲工程可控性。
知识沉淀
知识沉淀是我做 FylloCode 的核心目标之一。
Agent 不只是协助我们做 Coding，还应该能把过程中的知识固化下来，帮助未来的决策。否则每次循环都像一个新的会话：重新搜索、重新理解、重新犯错，然后由人再提醒一遍。
FylloCode 目前已经做了 lineage。它算是知识沉淀的一种，通过 lineage 可以知道当时为什么做了这些决策，比如任务从哪里来，讨论了什么，中间产生了哪些决策，Proposal 如何形成，最后哪些 commit 落地。
但 lineage 不是全部。FylloCode 很快会上线一个真正在对话过程中沉淀知识的功能，它和 lineage 负责的是两个不同方向。比如你在解决一个困难的 bug，做了很多尝试，耗费了很多时间，FylloCode 会把其中的关键信息作为知识沉淀下来，给以后提供帮助。但这类知识不一定应该进入 lineage，因为它不是某次任务的脉络，而是项目经验的一部分。
这个区别很重要。不是所有信息都应该进入同一个容器。架构设计里，数据能不能长期有效，应该被谁消费，什么时候被唤起，是否需要人工审查，都会影响它应该落到 lineage、spec、guideline 还是 knowledge。
如果这些沉淀位置不分清楚，知识系统最后也会变成垃圾堆。看起来什么都记了，实际用的时候什么都拿不准。
结果回写
很多人讨论 Loop 时会关注触发和执行，但我认为回写同样重要。
一个任务如果从项目管理系统来，结果就应该能回到项目管理系统。一个告警如果来自监控平台，诊断结论和处置动作就应该能和告警关联起来。一次 Agent 执行如果生成了方案、代码和测试结果，这些信息也应该能回到项目自己的 lineage 或知识系统里。
没有回写，Loop 就不是闭环，只是一次自动执行。
这也是为什么 FylloCode 会把第三方集成作为基础能力，而不是只做一个 Agent 聊天壳。因为在团队研发里，任务、代码、测试、发布、工单本来就分散在不同系统中。FylloCode 不应该替代这些系统，而应该把 Agent 的工作结果接回这些系统，让团队现有工具链继续成立。
并行工作
还有一个点，很多 Loop 讨论里没有明确写，但 FylloCode 很早就把它做进了隐含流程里，就是 git worktree。
我之前就考虑到，Coding Agent 给研发提速后，大家一定不会满足于串联执行任务。如果 Agent 可以同时推进多个需求，那就需要一个干净的 git worktree，让不同任务在不同工作区里推进，而不会影响 main worktree。
这个小细节带来的并行能力会直接改变研发组织方式。
过去一个人同时开几个需求，真正的瓶颈在于上下文切换和代码冲突。但 Agent 参与后，只要任务边界、项目上下文、执行环境和回写关系都能被系统管理，人就可以从“亲自写每一行代码”转向“审查多个执行中的工程循环”。
这也是研发方式会发生变化的地方。未来程序员的价值会越来越集中在判断、拆解、边界设计、风险识别和最终验收上，而不是把全部时间花在机械编码上。
Loop 做不到的事
目前所谓的 Loop，只是用 Agent 循环替代了部分人工操作。但异常并不会因为自动化消失，反而可能变得更难处理。
Loop Engineering 是 AI 时代自然发展的过程。就像 Prompt Engineering 到 Context Engineering，再到 Harness Engineering，随着模型自身能力增强，以及上下文和工具能力增加，Agent 才能做越来越多的事情。Loop Engineering 也可能只是这个时代的一个过客。它有价值，但不应该被神化。
在这个过程中，验证会变得更难。
无人值守的循环任务，也意味着无人值守的循环错误。每个循环的结束只是声明，不是证明。Agent 说任务完成了，不代表它真的满足了架构约束、业务目标和长期维护要求。真正的决策依然需要我们参与，真正的交付也仍然需要我们负责。
如果放任不管，你的理解会继续退化。循环越快地输出你没写过的代码，实际代码和你最终理解之间的差距就越大，这就是理解债。越流畅的循环只会加速这种差距的积累，除非你仔细阅读循环生成的代码，并把关键判断重新纳入自己的理解里。
舒适的才是最危险的。当循环自行运转时，人的惰性会让我们很容易放弃思考，接受它的一切反馈。如果你带着判断力去设计循环，它就是良药；但如果你只是为了逃避思考而设计循环，它就成了加速器。同样的行动，可能会带来相反的结果。
所以我对 Loop Engineering 的态度是：可以做，而且应该做，但必须把它当成工程系统来做。
我们需要定时系统，但不能只关心触发。
我们需要 Agent 自主性，但不能放弃边界。
我们需要知识沉淀，但不能把所有内容都塞进同一个地方。
我们需要并行提速，但不能丢掉验证和审查。
在当下这个时代，变化会越来越快，我们需要顺应它。我们可以构建 Loop，但一定要去“构建”，而不是只按下启动键。