从 Harness 到 Loop：阿福 Agent 小队如何处理持续涌入的线上 Badcase｜QCon 上海
📋 文章概况
一篇 QCon 上海演讲预告，介绍蚂蚁集团阿福 Agent 小队处理线上 badcase 的两阶段工程实践：先用 Harness Engineering 让 Agent 自主完成修复与验证，再用 Loop Engineering 组织内外双循环让系统持续处理新增问题。
💎 独特亮点
- "Harness → Loop"两阶段演进框架：先解决"如何可靠修好一个 badcase"（Harness），再解决"如何持续修复不断涌入的 badcase"（Loop）。这是一个清晰的工程演进路径，区别于常见的"一次性搭建 Agent 工作流"思路。
- 内外双循环分工：内循环负责诊断、修改、验证；外循环负责发现、归因、分派、结果回流。两组 Agent 小队共用同一套 Harness（工具、状态记录、执行约束、评测），失败时由内循环将证据返回外循环，经人工确认后改派。
- 独立验证者设计：验证者不参与修改，独立确认目标问题是否解决，并检查是否对其他问题造成影响——防止"只优化评测分数"的自我欺骗。
- 真实数据点：Agent 连续迭代 16 轮，改动经人工复核后上线。
🔧 可动手实践
| 目录点 | 你可以做什么 | 可动手程度 |
|---|---|---|
| 从自动化评测开始搭建小型 Harness | 选一个边界清晰、结果可验证的任务（如某个可自动评测的 bug 修复），把开发、部署、评测、获取结果封装成 Agent 可调用的工具，先让单 Agent 稳定跑通修复-验证闭环 | ✅可实现 |
| 长任务稳定性三约束 | 针对 Agent 长任务中的"提前结束、重复空转、上下文不足"问题，采用主 Agent 管目标 + 子 Agent 执行每轮分析修改的结构，并设置执行约束保障持续运行 | ✅可实现 |
| 隔离开发数据与验证数据 | 在每轮修改后重新与当前基线对比，防止 Agent 只优化评测分数而非真正解决问题 | ✅可实现 |
| 独立验证者模式 | 在修复流程中引入不参与修改的独立验证 Agent，确认目标问题解决且无副作用 | ✅可实现 |
| 内外双循环 Loop 架构 | 当单次修复稳定后，用定时任务驱动外循环 Agent 小队持续接收、去重、归类、分派 badcase，内循环小队负责修复，失败时证据回流人工改派 | ⚠️需补充（文中仅给出架构框架，未展开具体实现细节，需自行设计状态记录和证据交接格式） |
工作流（最小实验）:
- 选一个你项目中可自动评测的 badcase 类型（如某类 API 调用错误、输出格式错误）。
- 封装 4 个工具：开发（改代码）、部署（跑测试环境）、评测（跑自动化评测集）、获取结果（读评测报告）。
- 用主 Agent + 子 Agent 结构跑修复循环，设置最大迭代轮数和防空转约束。
- 每轮修改后强制与基线对比，记录是否真正解决问题。
- 稳定后加一个独立验证 Agent，不参与修改，只做确认和副作用检查。
🧠 可复用认知
- Agent 工程化的演进顺序是"先可靠，再持续"：单次任务的成功率是前提，持续处理能力是第二层问题。不要跳过 Harness 直接做 Loop。
- 闭环的判定标准不是"能自动执行"，而是三个检查点：能否持续执行、是否经过独立验证、失败后是否有明确的后续处理流程。
- 自动化边界应显式设计：Agent 负责重复性执行，人保留约束制定、抽样复核、异常决策和最终上线责任——"不追求全自动化"本身是一种工程决策。
🏷️ 关键词
#Harness-Engineering #Loop-Engineering #badcase处理 #内外双循环 #独立验证者 #长任务稳定性 #Agent小队 #评测约束 #执行约束 #阿福
分类标签: Agent架构 Agent编排 评测设计
📊 价值判断
推荐等级: 可跳过（信息增量集中在"Harness→Loop 两阶段框架"和"内外双循环分工"两个概念上，摘要已完整传达；原文是演讲预告而非演讲实录，深度/实现细节维度缺失——长任务稳定性、证据交接、状态记录等关键机制仅有方向性描述，无具体做法或数据支撑，读原文无法获得可复现的工程细节）
最值得看: 无（预告性质，核心信息已全部在摘要中；若对完整演讲内容感兴趣，应等待 QCon 演讲实录或后续技术文章）
适合场景: 你正在规划 Agent 生产环境的 badcase 处理流程，需要确认自己的场景处于"先建 Harness"还是"需要 Loop"阶段时，可用本文的两阶段框架做初步判断；但具体实现需另找详细资料。