蚂蚁阿福用双Loop处理线上Badcase，持续修复仍保留人工上线关口
阿福将修复验证与问题发现分派分成内外循环，结合独立评测和人工确认推进持续质量治理。
蚂蚁阿福用双 Loop 处理线上 Badcase，持续修复仍保留人工上线关口
先把单次修复做可靠，长任务受执行与评测约束
蚂蚁阿福上线后，随着用户增长，线上 Badcase 持续增加。问题从发现、归因、分派到修复、验证和关闭，要经过多名工程师交接，即使已有 AI 辅助，处理能力仍难覆盖新增问题。团队为此分阶段改造：先建设支撑可靠修复的 Harness，再把新问题持续接入 Loop。
这些信息来自 9 月 7 日公开的会议预告及演讲提纲。阿福 Harness 架构组负责人肖汉松计划在 10 月 22 日至 24 日举行的 QCon 上海站分享相关实践。当前公开材料属于实践介绍，未披露完整实验数据。可以据此理解工程机制，整体修复成功率、成本和适用范围仍不能下定论。
第一阶段把开发、部署、发起评测和获取结果接成 Agent 能够调用的工具，让它自主分析、修改和验证。执行约束用于处理提前结束、反复空转和上下文不足等长任务问题：主 Agent 管理目标，子 Agent 承担每轮分析与修改。工具接通之后，还需要持续运行的约束，才能把单轮建议变成多轮修复过程。
修复效果由评测约束判断。团队将开发数据和验证数据隔离，每轮修改后重新与当前基线比较，避免 Agent 只围绕可见评测分数优化。材料列出一次真实任务：Agent 连续迭代 16 轮，改动最终经人工复核后上线。这个案例说明多轮执行已被用于真实任务，16 轮并不代表固定修复预算，也无法证明所有问题都能自动处理。
单次修复通过工具执行和隔离评测持续获得反馈。
内外循环接续任务，失败证据回到分派环节
单次修复与验证能够稳定运行后，人工发现问题、定位归属、发起任务和回收结果成为新的瓶颈。团队把完整流程分成衔接的两个循环：外循环负责问题接收、归因、分派和后续流向；内循环负责诊断、修改和验证。两支 Agent 小队共用 Harness 的工具、状态记录、执行约束和评测能力。
进入外循环的一批 Badcase 先经过去重、归类和初步归因，再按问题归属创建任务。内循环根据证据定位问题层级，确认修改范围，审查方案后实施修改。这样的任务交接需要携带问题及证据，单纯转发一句修复要求无法覆盖这些步骤。
验证者独立于修改者工作。验证既要确认目标问题解决，也要检查修改是否影响其他问题。开发与验证数据隔离、修改后对照基线、独立验证者检查，分别约束不同环节，共同减少只把眼前样例修好的风险。
当前小队无法处理时，需要把判断结果和证据退回外循环，经过人工确认后重新分派。异常改派与最终上线仍由人把关。工程师减少逐项执行重复操作，继续负责约束制定、抽样复核、异常决策和最终确认。公开材料没有列出所有可自动处理的 Badcase 类型，也未给出人力节省比例，实际边界仍需结合后续实践验证。
提纲建议从自动化评测着手，先使边界清晰、结果可验证的小型 Harness 稳定运行，再用定时任务驱动 Loop 持续处理问题。持续执行、独立验证和失败后明确流向，是其中相互配合的条件。系统能自动接单，还需要证明它可以正确关闭任务、解释失败并交还责任人。
外循环分派问题，内循环修复验证，失败证据返回人工确认。
从可验证的小问题起步，给持续修复设上线关口
以下是企业采用建议。客服知识库错误、内部检索漏召回和标准化工单分类偏差，适合先筛选边界清晰的样例做试验。金融和医疗团队可从资料整理、草稿、检索和异常提示入手，避免一开始将客户承诺、诊疗建议或资金操作交给自动修改链路。选择已有人工验收标准的问题，才能比较接入前后的变化。
自动关闭任务应有独立的验收记录。业务负责人保存留出样本和当前基线，修复 Agent 只获得必要开发数据；验收同时观察目标问题、相邻业务和历史失败样例。记录重开率、人工复核耗时、无效迭代与单次修复总成本，比仅统计生成补丁数更有用。这些是建议的试点指标，材料没有提供可直接套用的目标值。
持续接单还需设置预算、停止条件和异常队列。超出迭代预算、证据不足或修改触及更高权限时暂停执行，由责任人确认是否改派。每次交接保留样例标识、版本、测试结果和未解决判断，避免下一支小队重复试错。外循环若持续接收重复或低质量反馈，也可能增加无效工作，去重和分类质量应单独抽查。
最终上线、医疗建议、法律承诺和对外正式发送均需人工确认。试点账户采用最小权限，敏感数据脱敏，保存变更与审批日志，准备可执行的回滚或补偿方案。先跑通一个可验证的小闭环，再扩大问题类别和自主范围，能让业务部门看清每一步的效果与责任。
企业从明确验收标准的小问题开始，保留最终上线审批。
消息参考来源