从 Harness 到 Loop：Agent 如何走向可靠交付与持续进化？

作者 | QCon 全球软件开发大会

策划 | Kitty

编辑 | 宇琪

2026 年，行业里有一个越来越清晰的共识：模型能力本身正在“商品化”，真正的竞争壁垒已经转移到了模型之外的工程系统上。 那么，当模型不再是唯一瓶颈，工程团队应该如何设计模型之外的系统，才能让 Agent 在生产环境中真正可靠地并自进化？

近日，InfoQ《极客有约》X QCon 直播栏目特别邀请蚂蚁集团资深专家、阿福大模型应用负责人郭春晓担任主持人，和蚂蚁集团阿福 Harness 架构组负责人肖汉松、腾讯高级后台开发工程师任磊达、京东技术总监曲奎林一起，在QCon全球软件开发大会2026 （上海站）即将召开之际，共同探讨 Agent 在生产环境中的自进化。

部分精彩观点如下：

• 从 Harness 到 Loop 最本质的变化，是生产关系的变化：人从执行职责里解放出来，变成 AI 干完活来找人做决策。

• Harness 解决“Agent 怎么把任务完成”，Loop 解决“Agent 怎么越变越强”，前者是静态系统，后者是进化系统。

• 模型能力不等于 Agent 系统能力，能力是锯齿式的，很多“更强的模型”只是叙事更强，不是能力更强。

• 模型决定能力上限，工程化体系决定交付下限，代码生成率做到 90% 不解决问题，成本只是从开发转移到测试和线上。

• Loop 里能自动化的是执行，不能自动化的是决策和验收，最终还得人拍板。

• 离“真正的自进化”还很远，最大的缺口是 Agent 没有人的上下文。

在 10 月 22-24 日将于上海举办的 QCon 全球软件开发大会 2026 （上海站）上，我们特别设置了 【Loop Engineering】 专题。该专题将重点讨论生产级的 Agent、Agent 可读的代码与知识体系、工具协议与安全沙箱、轨迹级可观测性、自动化 Eval、多智能体协作与权限控制，以及基于执行反馈的 Harness 自进化。

查看大会日程解锁更多精彩内容：
https://qcon.infoq.cn/2026/shanghai/schedule

完整直播回放可查看：
https://www.infoq.cn/video/52550fXfrMaZhMqwrsC5?utm\_source=home\_video&utm\_medium=article

以下内容基于直播速记整理，经 InfoQ 删减。

Agent 为什么总在生产环境出问题？

郭春晓：在你的实践中，“从 Harness 到 Loop”最本质的变化是什么？

肖汉松：核心是生产关系的变化。现在 Agent 能做很多事情，人从执行的职责里解放出来了。原来是我们人去找 AI 处理事情，现在变成 AI 自己处理完了，来找我们做决策。

任磊达：业务层面的 Loop，包括现在的 graph，有点像从常规编程 Agent 里抽出来的概念。Harness 做的是怎么让 Agent 跑起来，要接各种 MCP、subAgent 这类基础设施。但 Loop 讲究的是怎么让 Agent 越变越强，要从具体落地里发现问题，再反哺给 Agent，让它越来越适配当前场景，这有点像 SFT。

曲奎林：我作为前端，感受比较深的是从去年到今年有个大变化，开发人员在持续监督引导方面介入得越来越少了。一句话，从完成任务的角度讲，部分需求可以完全交给 AI 来做整体的生产闭环了。

郭春晓：肖老师，你们一开始建设 Harness，主要解决的是 Agent“怎么把任务完成”，什么时候意识到，仅仅把 Harness 做好还不够，必须开始建设 Loop？

肖汉松：阿福线上 badcase 分三类。第一类 Harness 的问题，比如 prompt 写得不好，本来需要搜索解答的问题模型不收，或者工具描述写错了，该调的工具没调起来。第二类模型的问题，容易幻觉，比如用户没有上传体检报告，模型却给用户编一个体检报告；还有指令不遵循，告诉它回答中文，它有时夹杂英文。第三类数据的问题，线上检索回来的数据有问题，模型以为是对的，就答错了。

举一个例子，我们给 Agent 提供计算器工具，但它有时会并发调用十几个计算器去算一道题。原因是计算器的入参是数学公式，复杂的题它只能并发去调。后来换成代码解释器，Agent 自己写代码，一次调用就能算出来，这一个改动解决掉很多 badcase。所以很多问题，如果一开始做 Agent，大部分是 Harness 没设计好。

回到什么时候做 Loop。随着用的人越来越多、场景越来越复杂，线上 badcase 到了修不过来的程度，修复速度要按周算，我们定了目标至少提升到天级别。今年过年 OpenAI 发布了 Harness 工程实践，用 Codex 写代码，全程无人参与。我看到后就想，既然能让 Agent 写代码做需求，也能让 AI 帮我们修 badcase，所以三四月份建了修复 badcase 的 Harness，让它自己修、自己验证。做完又发现，虽然 Agent 能修了，但还是要人派任务。而 Agent 本来可以持续工作，只要把目标定好就能持续工作。所以我们进入 Loop 阶段，让 Agent 自己找 badcase、自己修，本质上就形成了自进化机制。

郭春晓：游戏研发场景可能比一般业务更复杂，任务链路长、工具多，而且很多结果最终要进入真实研发流程。你们在实践中发现，Agent 最容易在哪些环节掉链子？

任磊达：游戏场景跟 Agent 场景首先有个最大的不同，用户并不认为它是个不确定系统，很多情况下他认为它应该是确定性系统，所以对错误的容忍度不高。bug 就是 bug，不是大模型底座能容忍的。

技术上，GPT-6 出来之前，整个多模态还处在一个非常混沌的状态，AIGC 更多还处于抽奖的状态，很难工程化提升，所以 AIGC 那块效果不好的时候，我们 Agent 的转型更多放在代码层面。代码层面的痛点更多在于游戏本身的复杂度，我之前做互联网，一个组的工作在游戏这边可能就是一个同学，甚至一个同学兼任几个组。

这过程中，现有模型的上下文还是大瓶颈。1M 上下文很多模型支持得不好，成本低的模型还在 200K 左右，就需要更多人的 loop，把任务拆下来。给任何模型算 1+1，成功概率都很大，前提是上下文控制得好，但精力稍微涣散，它就很容易出一些奇奇怪怪的问题。所以复杂度层面、多模态两个都是大攻坚点。管理层面，游戏更偏创业性产业，要提高大家对创意的投入，这也是从个人提效到组织提效的难点。

郭春晓：很多团队遇到 Agent 失败，第一反应都是“换更强的模型”。在你们的实践里，有没有一些典型问题是模型再强也解决不了，必须靠工程系统解决？

任磊达：现在很多更强的模型，更多时候不是能力更强，而是叙事更强，让大家觉得它在所有地方都更强。实际上现在模型的偏好特别厉害，比如 GPT-6 的 3D 建模能力很强，但编码能力没有质的突破；Kimi K3 的前端 UI 审美能力特别强。但排行榜并不会用多维角度去度量什么叫更好的模型。我们用更好的模型时，也经常遇到死循环，用 Manus 去跑这些模型，经历的问题多了，其实在对所谓更强的模型祛魅。

更重要的，是要相信它是有不确定性的，抛去模型本身的叙事之后，我们要把什么东西交给它？因为我们做后服务器长期运营，很多安全运营审核的场景一定要有人的介入。比如网络的边界，不能让 Agent 随便穿过；发布的流程也要保留一些灰度发布的成分来保证服务的稳定性。

郭春晓：我大概理解了，现在一些底线的问题，其实必须由人来守护。另外想补充，模型能力到底等不等于 Agent 系统能力？其实不等于，因为模型能力是锯齿式的，现在的模型本质上都没有记忆，你必须借助 Agent 的系统能力。还有营销的场景，资损特别大，正常系统有十万分之一的概率有个 bug，但营销系统如果有人发现漏洞，就会把它放大成 100%，所有人都来薅羊毛，事件就变成 100% 了。

郭春晓：你们把前端 Agent 从“代码生成”推进到真正的业务交付，经历了三次工程化拐点。回头看，最关键的变化是不是其实发生在模型之外？

曲奎林：最关键的变化确实在模型之外。模型解决的是能不能生成代码，但业务交付还要解决安全性、稳定性、协作效率、业务结果，中间差了一整套功能体系。

去年大促我们在互动层面做实验，把模型开放给用户，做一个 AI 生成游戏大赛。过程中在 Agent 里做了很多实时验证，但只验证代码能不能跑通，最后看到用户生成的作品，实际 40% 是不可用的，根本玩不了。这说明模型后面还需要很多工程化体系约束它的不确定性。

我们内部交付分几种。第一种是中后台场景，比如运营提交商品表单时设置错误，能不能通过 Agent 的巡检方式解决。第二种是前端代码交付层面，中后台是高频、低定制化的场景，可以用 DSL 让模型生成意图而非实现，加上安全性验证、稳定性巡检。再就是对定制化、低频的需求，比如 C 端，需要多个 Agent 协同、与专家决策。最后会有性能转化和视觉守门。所以模型决定能力上限，工程化体系决定交付下限，真正突破的是把不确定的模型能力装进确定性的交付系统。

郭春晓：如果只有一个代码生成模型，没有后面的验证、反馈和交付体系，它距离真正的生产力还有多远？

曲奎林：如果只看代码生成这一步，数据会非常漂亮。去年年底我们全员接入使用后，AI 代码生成率可以达到 90% 以上。但把视角拉到交付周期，就会发现它只是把成本从开发阶段转移到测试和线上。大量生成的代码不够可靠，测试阶段不断反复返工，一些隐藏的性能、兼容性、业务风险会直接被带到线上。特别是 C 端页面，生成时没法做验证。所以代码写得快，不代表需求交付得快。真正应该关注的，不是代码生成率，而是端到端的交付周期、一次性通过率、线上事故率，以及最后业务想要的效果。

春晓：如果把 Agent 的失败拆开，你们认为最大的瓶颈分别在哪里？

任磊达：最大瓶颈还是顺着曲老师刚刚讲的“验证”。现在外部出来的东西，bug 率是之前的两到三倍。怎么解决？肯定是让 Agent 自己去把问题发现出来，人才能真正把效率提上来。

验证中间还有很大瓶颈。Agent 如果让它查自己的代码，一定会有形式化的验证，它会按代码实现去验证，这本质就是为完成任务而完成任务，没有任何实际业务价值，同时让代码越来越难维护。另一方面，它验证了很多东西，甚至都不写断言，如果 prompt 比较简陋，它就把 happy path 跑通，就认为验证完成了。我觉得我们这个场景最大的瓶颈还是在验证这一块。

曲奎林：我认为最大瓶颈还是两点。第一个是前置的需求怎么澄清。业务可能提不出特别精细化的需求，需求方向理解错了，代码生成得越快，偏差越远。很多业务需求天然就是模糊的，背后有大量没被表达出来的约束。Agent 不仅要听懂用户说了什么，还要根据历史业务信息、交付记录、客观知识，主动发现信息缺口，提出正确的问题，才能把需求转化成可执行、可验证的目标。

第二个是结果验证。前端交付不仅要求视觉上像素级的还原，还要受机型、浏览器、网络环境影响。Agent 如果只是盲写代码，很难既通过视觉验收，又发现定位真机的问题。怎么让 AI 自己识别这些问题？一方面加强 D2C 的能力，把设计稿转化成可执行的设计约束；另一方面让 AI 把测试用例跟真机真正联动起来，看到运行结果哪里错了、为什么错。简单说，前面解决需求有没有理解对，后面解决结果做没做对。

肖汉松：我补充一个点，现在很多 Agent 的问题，大部分是因为上下文不够。回到平时做需求，你经常发现它做出来的东西不是你想要的，才发现是我们有些信息没说清楚。因为我们认为理所当然的信息，比如业务背景、做决策的取舍，Agent 都没有，它只有你的一句话，或者一个 PRD。倒推回来，是因为现在整个研发模式还是围绕人的，这些信息都在我们脑子里。以前自己做需求写起来很快，因为开会交流、在团队工作十年，很多屎山代码的潜规则我都知道，但 AI 不知道。所以最大瓶颈在这里，怎么解？可能要改变的是整个团队协作，短期只能靠人肉给 AI 补信息。

郭春晓：任磊达老师说的怎么验证，确实是一个当前还没被解决的问题。后端系统相对好验证，但像营销这种前后端一体的，要去真机上验证，尤其视觉方面，颜色 RGB 有一点偏差就很难验证。我再补充一点，现在 Agent 基础设施其实不是那么健全，以前都是为人打造的，今天一个团队十几个人，一个人有三四个 Agent，同时并发开发就涉及大量抢环境的问题。另外，开会、文档、很多上下文还没完全被 Agent 访问到，所以还需要一个另外的 Agent，它除了能访问 code，还能访问组织的上下文。

Loop 到底 Loop 什么？

郭春晓：我们一直在讲 Loop Engineering，但 Loop 到底 Loop 的是什么？一个 Badcase 从线上出现，到最终变成 Agent 能力的一次提升，在阿福内部完整的链路是什么？这条链路里，哪些环节已经可以自动化，哪些环节目前还必须依赖工程师？

肖汉松：阿福内部 badcase 修复流转分几个阶段。第一个是发现，来源有：每天一个日标的过程，人工去发现线上问题；用户反馈，比如点赞点踩；我们自己巡检，抽样后让 AI 按特定规则去巡检。第二个是归因，看是 Harness 的问题，还是模型的问题，还是数据的问题。归因之后分派给对应同学修复，就像以前做需求，你有个 issue，怎么分发给负责人。分派完进入修复阶段，prompt 有问题就改 prompt，模型有问题就去训模型。解决完进入验证阶段，通过评测集做自动化评测，评测没问题，最后上线 AB 实验，badcase 就算修复完成。

现在哪些能自动化？前面这些流程，AI 基本都能帮我们操作。归因原来人工弄，后来把日志、代码、归因问题发给 AI，它自己就能定位。定位完，我们给它一个路由表，告诉它哪些问题该谁处理，它就把工单分派给对应的人。后来我们做了个能力，可以指派一个 Agent 去修，比如 RAG 的问题有 RAG 小队处理，prompt 的问题有 prompt 小队处理。Agent 修完要自己部署、跑评测，现在评测也做成了工具让 Agent 自己调，验证完还能自己发布开实验上线。

但也不是全自动化了，那样我们也失业了。有两个关键点需要工程师做。第一个是方案的决策，Agent 修 badcase 要出方案，这个方案合不合理，是短期还是长期，要根据情况判断。第二个是验收，Agent 修完是不是真的修了、修到什么程度，要工程师验收。虽然 Agent 能自己验收，但上线前我们有个卡点，必须有人的确认才能上线。所以执行的事情都是 Agent 干，但方案决策和验收这两步，还是工程师整体把控。

郭春晓：你们的实践叫“把 Loop 接进团队”。为什么 Loop 不能只存在于某一个 Agent 或某个工程师身上？如果一个工程师发现一个问题、自己修掉了，这只是一次 Debug，什么时候它才真正变成了 Loop Engineering？

任磊达：human in the loop 这个东西听起来特别不性感，但在我们的实践里，human 在里面的效用是最大的，它的品味呈现也是最好的。所以做 Loop Engineering，不能只是个人的 Loop，一定要做成团队的 Loop，把大家的主观能动性都发挥在 Loop 进化的过程中，不能期待 Agent 真的去做自进化。

郭春晓：前端 Agent 从“生成代码”到“真正交付”，中间最重要的反馈信号是什么？你们怎么判断一次 Agent 迭代到底“变好了”？没有 Evaluation，Loop 会不会只是不断修改，而不是工程化进化？

曲奎林：我们前端在业务交付里，最重要的就是建立一套机器评估与人类评估结合的 evaluation 机制。机器评估负责高频的客观检查，代码能否编译通过、测试功能是否通过、页面能否还原、是否回归。人类评估负责更深层的问题，是否符合业务目标、交互是否自然、代码是否真正可维护。肖老师也说过，human in the loop 基本不可避免。

举个例子，开发一个登录页，机器确实可以验证登录流程、错误提示、应用端适配、视觉差异。但流程是否真的跑通、交互是否符合业务预期，还是需要人判断，再把人的判断沉淀成测试用例，交给机器继续执行评估。判断一次迭代是否真的变好，不是看代码改了多少，而是看测试通过率是否提升、人工返工是否减少、同类问题是否不再出现。

如何把 Loop 真正工程化？

郭春晓：Loop Engineering 的难点可能不是“有没有 Loop”，而是能不是不是真实且能够被复现的。第二，能确认问题是来自 Agent，而不是需求不清、数据错误或下游系统故障。第三，它代表一类共性问题，而不是一次偶发情况。第四，解决它能明显改善正确性、安全性，或给业务带来结果。

经过筛选后要分类处理：业务规则、专家经验要进入知识库；典型的失败案例要进入 Agent 评测集；未经确认的投诉、偶发异常和互相冲突的反馈，就不应该让 Agent 记住。怎么判断变好？关键是做 Agent 评测，建立持续更新的机制。反馈期之后，不仅要重测原来的问题，还要用 Agent 没见过的同类问题检测它能不能举一反三，并确认原有能力有没有退化。最后通过小流量商业验证，观察人工干预率、事故率和业务指标。

肖汉松：我补充一个视角，做线上 Agent，线上很多反馈，用户投诉、线上 badcase，大部分我们都要去看。让它们进入 Loop，一个重要的手段是先用一个 Agent 做初步归因，再按聚类方式批量处理，而不是一个个处理。判断变好，基本上就是评测集，再通过小流量 AB 实验。

哪些 Loop 可以自动化？线上 badcase 如果是一类通用问题，这种修复值得做成 Loop。还有一些 bug 修复、简单需求，因为它们的问题验证好定义，有 bug 就有对应用例，简单需求加个按钮、加个小功能，测试验证用例比较好定义。不适合自动化的，第一个是模糊的问题，比如大的架构设计，一定是结合具体业务情况、资源分配、现有技术条件去综合决策。还有一个是评测集本身，唯一很难自动化的就是定义评测集这件事，因为如果让 Agent 自己给自己造题，就没有人核验对错了。

任磊达：我补充一点其他视角。我们作为业务团队，肯定没精力做评测集，评价它变好，更多是整个研发的体感层面，是不是经常在做重复的、很无聊的事情。什么反馈应该进入 Loop？其实就是发现这种重复的东西，把研发体感的抱怨收集起来，变成 Loop。

第二，如果把精力完全放在“什么该进 Loop、什么不该进”，压力很大。有一个很有名的 Agent 叫 Manus，递归执行化的火就是来源于 Manus。它会自动生成 skill，当它觉得对话轮数太多、或工具执行轮数太多、是复杂任务时，会自动沉淀下来。而且它会自动移动、遗忘。只要有个遗忘机制在，我们对什么东西需要进入 Loop 这件事，压力就没那么大了。让我们的 Harness 有自动遗忘的能力，就可以通过监控指标观测，包括模型升级时 review 一下之前的东西是不是可以不要了。

Agent 能真正“自进化”吗？

郭春晓：肖老师，你认为阿福现在离“真正自进化的 Agent”还有多远？最大的缺口是什么？

肖汉松：阿福现在在 Loop 上有了一些进展，但还是缺两个大问题。第一个是怎么样让 Agent 拥有我们人所有的上下文，这是最麻烦的一个点。很多事情我们自己知道，但 Agent 不知道。比如你给它加一个工具，上线后效果不好，原因可能是工具里的业务逻辑没写全，导致它回答错了。

第二个差距是，我们现在整个 Agent Loop、还有 Harness 进化的闭环里，只包含了 Harness 本身，就是 prompt、工具、skill 这些模型外围的能力，还没有把整个模型纳入进化的闭环，这是我们接下来的重点工作。

最大的缺口，我觉得还是现在整个进化迭代的流程以人为中心，很多信息没留下来给 AI。很多时候开完会，会议没录音，你跟 Agent 提需求又要复述一遍，一复述可能就漏掉东西。团队大了，很多业务信息没记录，背后的决策都丢在人脑子里。但未来随着内部工作协作软件慢慢进化，这些信息会慢慢记录下来，让 AI 去调取，它拥有上下文之后，做很多事情就不会像现在这么傻了。

郭春晓：任老师，如果 Loop 最终能够自动运行，那么传统研发团队的角色会不会发生变化？工程师未来是在“写 Agent”，还是在“设计 Agent 的 Loop”？

任磊达：刚才肖老师说的一个词特别性感，叫 AI native，人在给 Agent 打工。研发团队的角色可能会变化，我们更多在为 Agent 服务。但这个在我们内部还是持保留态度的，因为游戏本身要讲人性、以人为本。不过回到技术层面，就很好聊了。

我们去设计 Agent loop，这句话听起来复杂，但实际上在实验里，当现在常见的 Agent 都有 goal 那些命令时，我们会在不知不觉中锻炼设计 Agent loop 的能力。给 Agent 设一个 goal，它会有一个非常长程的任务在跑，跑完看结果，就知道之前给的 goal 描述得准不准确、loop 构建得精不精确。因为能看到结果，就知道上一次问题在哪，不断提高个人能力，对整个 loop 的 build 能力在团队里也会提升。实际上，业务团队一般不会大量调用大语言模型去写 Agent，更多还是在编排 Agent。

郭春晓：曲老师，当 Agent 可以自己生成、验证、修复和交付之后，你认为人的价值最终应该放在哪里？

曲奎林：这个问题有点高。先说现状，现在业界的 Agent 还有一定差距。如果未来真的能自己生成、验证、修复，整个交付流程都完善，那整个系统的失控速度也会是前所未有的。

所以人的价值，更多是给 Agent 设置边界，就是它不可逾越的地方到底是哪些，要重新审视它的长期价值、安全底线、数据隐私红线。另一个层面，软件工程从来不只是代码问题，还涉及组织利益、资源，包括人性博弈。中厂大厂其实有很多组织摩擦，多方利益冲突、资源有限、需求朝令夕改，怎么建立信任、建立共识，更多需要人来维护。

郭春晓：如果未来模型能力增长的速度越来越快，而工程系统没有同步进化，会不会反而成为 Agent 落地的最大瓶颈？

任磊达：这个问题特别务实。因为无论是前两天 GPT-6 出了之后，它要我们主动去删一些 prompt，还是 Claude 4.5 出了之后，Claude Code 自己删了 80% 的提示词，它都在说一个东西：模型已经把 Harness 的一些能力更加鲁棒地吸收进去了。比如在 Claude 4.5 里，它甚至有读写文件本身的一些记忆能力了。如果在 Harness 里有重复的东西，就像 GPT-5.6 还在用 Superpowers 一样，它就会跟模型本身互相打架。

Harness 作为跟模型接得最近的一层，它只要一打架，使用者会非常痛苦。所以要从两个角度做：第一是 Harness 本身的选型，选更适配模型的 Harness；第二是把自己在 Harness 上面搭的业务 Harness，做一个跟模型升级的适配，用 Loop 的视角去看我们跟模型交互方式的快速变化。

肖汉松：前面提到计算器的例子，有些数学题 Agent 做不对，把计算器换成代码解释器它就能做对了。说白了就是我们工具提供得不对，导致 Agent 做不出这道题。

再补充一个例子。我们让 Agent 做 badcase 自动优化，让它跑评测集，要先部署到线上。当时让它去部署，结果运维的部署系统报错了，报错返回里又没有提供报错信息，AI 就一直在重试，整个链路卡住。如果是人，会先看日志，报错信息没给，就直接找运维系统的 owner 排查。但 Agent 做不到，它只知道失败不知道为什么，同时你又没告诉它可以找谁解决。这些其实都是模型外围的东西，环境没准备好、工具没准备好，它就有很多问题解决不了。

郭春晓：过去做 Agent，更多思考怎么让 Agent 更聪明。但当模型能力越来越强以后，会发现真正把 Agent 带到生产系统的，靠的已经不是一个更强的模型了。在生产过程中，模型的能力叫过溢，普通用户已经用不到更强模型的智力了。所以它需要的不是更强的模型，而是 Harness 让 Agent 有能力完成任务，需要评估知道它做得对不对，需要 feedback 让真实问题被看见，需要 Loop 把反馈带回功能系统。

今天从三位老师的分享，不管是游戏这个创意领域，还是营销这个要 100% 对的行业，我们看到整个业界不再是构建一个 Agent，而是构建一个能持续运行、持续反馈、持续验证、持续改进的 Agent 系统。这可能是从 Harness 静态理念，走向 Loop 理念最核心的变化。离真正的自进化还有很长的路，但至少看到，未来 Agent 竞争的不仅是模型层，模型决定 Agent 能走多远，工程系统决定 Agent 能不能跑起来、能跑多快。

今日荐文

你也「在看」吗？