Loop Engineering实战：从日志巡检到供应链异常修复闭环

从一次性修复到持续治理

最近在整理 Codex 和 Agent 工作流时，我越来越觉得，AI 编程真正值得关注的地方，已经不只是“怎么写一个更好的提示词”，而是怎么把 AI agent 放进一个持续运转的工程循环里：自动发现问题、定位根因、生成修复、跑测试、部署预发，再由独立验证环节判断是否真的修好。

换句话说，AI 编程的瓶颈，已经不只是“写代码慢不慢”，而是“发现问题、修复问题、验证问题、沉淀经验”这条维护链路是不是还靠人手动推动。

如果人每天都要打开日志平台、复制错误、问 AI、改代码、跑测试、提合并、盯预发，那 AI 只是提高了某个环节的速度。Loop Engineering 要做的，是把整条链路设计成能自己转起来的闭环。

Loop Engineering供应链异常修复闭环

工程循环的五个必要环节

Loop Engineering 的重点不是让 AI “更会写代码”，而是把问题发现、任务隔离、修复执行、独立验证和经验沉淀组织成可重复运行的工程流程。自动化程度必须由风险等级决定，尤其不能默认把生产数据修改和生产发布交给 agent。

我把它总结成四个观点。

第一，维护循环才是真正瓶颈。

AI 已经能很快生成代码，但线上系统的问题不会自动消失。日志分散、错误类型多、排查链路长、测试和部署还要人工推动，才是工程效率真正卡住的地方。

第二，Loop 比一次性 Agent 多了“持续性”。

普通 Harness 是一次会话里给 AI 工具，比如 shell、git、日志查询、测试命令。Loop 在它之上增加了调度、状态、独立验证和跨轮记忆。也就是说，它不是“这次帮我修一下”，而是“每天自己巡检、自己修、自己验，必要时通知人”。

第三，Loop 需要五个动作。

1
2
3
4
5
发现：找出该处理的问题。
交付：把问题隔离给 agent 执行。
验证：让独立检查环节判断结果。
持久化：把结论、失败和修复经验记录下来。
调度：让这套流程定时或按事件反复运行。

第四，Loop 需要六类组件。

1
2
3
4
5
6
Connectors：连接日志、监控、发布、通知等系统。
Automations：定时巡检或事件触发。
Skills：把诊断、修复、发布流程写成 SOP。
Worktrees：隔离不同修复任务，避免互相污染。
Independent verifier：用独立上下文或独立检查程序验证，避免修复者自证。
State：在工单、数据库或版本化文档中记录历史结论、修复方案和巡检状态。

这里还有一个很重要的判断标准：不是所有任务都值得建 Loop。适合建 Loop 的任务，通常要满足四个条件：重复发生、验证能自动化、成本可控、agent 有足够工具。

放到供应链系统里怎么理解

供应链系统非常适合用 Loop Engineering 的思路，因为它的异常不是一次性的。

比如这些问题会反复出现：

1
2
3
4
5
6
7
订单履约超时。
采购到货数量和采购单不一致。
库存预占失败。
出库单状态卡住。
消息消费失败。
供应商回传状态延迟。
报表统计口径和业务事实不一致。

传统做法是：运营或研发发现异常，去查订单、查库存流水、查 MQ、查日志、查数据库，再手动判断是否要修代码或补数据。

Loop Engineering 的做法是把这条链路设计成系统：

1
2
3
4
5
6
7
8
9
每天自动扫描异常订单和错误日志。
按业务类型归类：库存、采购、发货、消息、报表。
让 Codex 读取相关代码、日志和数据样本。
生成根因报告和最小修复方案。
补测试或验证 SQL。
修复一个小切片。
跑测试和回归查询。
通过后提交变更，失败则进入调试循环。
超过重试次数就停止，并把问题交给人。

这样 Codex 不只是“写代码的人”，而是整个维护循环里的执行者。

Codex 供应链案例

假设供应链系统里有一个反复出现的问题：采购到货后，部分订单的库存流水已经写入，但采购到货单状态仍停留在“部分到货”，导致后续财务暂估和供应商履约报表都不准。

这个需求不要直接让 Codex 改代码。先把 loop 定义清楚。

第一步，用普通任务说明定义目标。不同 Codex 版本和使用界面支持的能力并不完全相同，因此不要假设 /goal 是所有环境都可用的通用命令。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
请把下面内容作为本次持续排查任务的目标：
持续排查并修复供应链系统里的采购到货状态异常问题。

目标：
1. 找出近 7 天库存流水已写入但到货单状态未正确更新的样本；
2. 定位是代码逻辑、消息消费、事务回滚还是历史数据导致；
3. 如果是代码问题，生成最小修复并补充测试；
4. 跑相关测试和验证 SQL；
5. 输出修复报告、风险点和人工验收清单。

停止条件：
- 找到明确根因并完成修复；或
- 连续两轮验证失败；或
- 需要真实数据库权限、生产凭证、业务口径确认。

第二步，让 Codex 先做发现。

1
2
3
4
5
6
7
8
9
10
11
请先不要改代码。
请读取项目规则、采购到货模块、库存流水模块、消息消费模块和相关测试。

同时整理需要验证的数据条件：
1. purchase_receipt 状态不是 COMPLETED；
2. stock_ledger 已存在对应 receipt_id；
3. receipt_item 的 received_qty 已等于 planned_qty；
4. 最近 7 天内出现；
5. 排除人工关闭或取消的单据。

输出异常样本查询 SQL、可能原因列表和下一步排查计划。

第三步，把诊断流程沉淀成 skill 思路。

1
2
3
4
5
6
请按 supply-chain-receipt-diagnosis skill 的方式执行：
1. 先确认业务状态机；
2. 再查库存流水和到货明细；
3. 再查消息消费日志；
4. 再看最近相关 git diff；
5. 最后输出事实、推理、结论，不要跳步。

如果还没有这个 skill，可以先把它当成提示词使用。等这类问题出现三次以上，就值得写成真正的 SKILL.md。

第四步，让 Codex 生成修复计划。

1
2
3
4
5
6
7
8
请基于上面的诊断结果，生成修复计划，不要直接改代码。

计划必须包含：
1. 要修改的 Service、Mapper、消息消费者或定时补偿任务；
2. 要新增的单元测试和集成测试；
3. 是否需要补偿历史数据；
4. 事务边界和幂等风险；
5. 回滚方案。

第五步，小步实现。

1
2
3
4
5
6
7
8
9
现在只实现第一步：补充一个失败测试。

测试场景：
库存流水写入成功，到货明细数量已满足完成条件，但到货单状态仍未更新。

要求：
- 先让测试失败；
- 不修改业务实现；
- 完成后展示测试名称和失败原因。

第六步，再让 Codex 做最小修复。

1
2
3
4
5
6
7
8
现在根据失败测试做最小修复。

要求：
- 不改接口协议；
- 不重构无关代码；
- 保持现有事务模型；
- 如果涉及消息重复消费，必须加幂等判断；
- 修复后运行相关测试。

第七步，独立验证。

1
2
3
4
5
6
7
8
请用 code review 的方式审查当前 diff。

重点检查：
1. 是否只是修复采购到货状态异常；
2. 是否会影响少到、多到、不合格品逻辑；
3. 是否有重复消费导致状态反复更新的问题；
4. 库存流水和到货状态是否在同一事务或有补偿机制；
5. 测试是否覆盖重复消息和事务失败。

第八步，持久化经验。

1
2
3
4
5
6
7
8
请把这次问题总结成一条可复用的排查规则：
- 触发条件；
- 相关表；
- 相关日志；
- 常见根因；
- 验证 SQL；
- 修复注意事项；
- 下次自动巡检建议。

这一步形成可审计的状态记录。记录应放在团队可维护的工单、runbook 或版本库中，不能只依赖某次对话的上下文。

完整闭环与质量门禁

对供应链系统来说，一个可落地的 Codex Loop 可以这样走：

1
2
3
4
5
6
7
8
9
10
11
定时巡检
-> 查询异常订单/到货单/库存流水
-> Codex 读取代码和日志
-> 生成根因报告
-> 写失败测试
-> 最小修复
-> 跑测试和验证 SQL
-> 独立 review
-> 预发验证
-> 人工确认生产发布
-> 记录经验和新规则

关键不是追求“全自动发布生产”，而是按风险设置质量门禁。涉及库存数量、金额、权限和生产数据修复时，应要求人工审批、双人复核、审计记录和可执行的回滚方案。

落地限制与治理措施

第一个限制，是验证器不够强。

如果只有单元测试，AI 可能把错误隐藏掉，比如把错误日志降级，或者只处理 happy path。解决办法是至少三层验证：单元测试、业务 SQL 校验、预发环境回归。

第二个限制，是成本容易失控。

每天全量扫日志、读代码、跑大模型诊断，很容易消耗大量 token。解决办法是分级：先用简单规则和小模型筛选高风险问题，再把少量问题交给 Codex 深度处理。

第三个限制，是工具链建设成本高。

Loop 不是只写提示词，它需要日志查询、测试命令、发布脚本、通知通道、状态记录。解决办法是先选一个窄场景，比如“采购到货状态异常”，不要一上来覆盖整个供应链。

第四个限制，是自动修复可能误伤。

供应链系统里状态机、库存、财务、报表互相影响，自动修复不能绕过人。解决办法是设置硬停止条件：涉及金额、库存数量、生产数据修复、权限变更时，必须人工审批。

第五个限制，是经验没有沉淀。

如果每次排查都停留在一次对话里，下一次还是从零开始。解决办法是把常见问题写入 skill、runbook、异常规则库或巡检配置，让 loop 越跑越聪明。

总结

Loop Engineering 最值得借鉴的地方，是它把 AI 编程从一次性任务推进到生产闭环。它不是让 AI 一次性写更多代码，而是设计一套能持续发现问题、修复问题、验证问题、沉淀经验的系统。

放到供应链系统里，我认为最适合先做的不是“让 Codex 自动开发大需求”，而是“让 Codex 自动巡检和修复高频异常”。比如采购到货状态异常、库存流水不一致、消息消费失败、订单履约超时。

真正稳的 AI 工程化，不是把人完全拿掉，而是让人从手动推动循环，变成设计循环、审查风险和批准关键节点。

参考资料