2026 年，行业里有一个越来越清晰的共识：模型能力本身正在“商品化”，真正的竞争壁垒已经转移到了模型之外的工程系统上。 那么，当模型不再是唯一瓶颈，工程团队应该如何设计模型之外的系统，才能让 Agent 在生产环境中真正可靠地并自进化？
近日，InfoQ《极客有约》X QCon 直播栏目特别邀请蚂蚁集团资深专家、阿福大模型应用负责人郭春晓担任主持人，和蚂蚁集团阿福 Harness 架构组负责人肖汉松、腾讯高级后台开发工程师任磊达、京东技术总监曲奎林一起，在 QCon全球软件开发大会 2026 （上海站）即将召开之际，共同探讨 Agent 在生产环境中的自进化。
部分精彩观点如下：
从 Harness 到 Loop 最本质的变化，是生产关系的变化：人从执行职责里解放出来，变成 AI 干完活来找人做决策。
Harness 解决“Agent 怎么把任务完成”，Loop 解决“Agent 怎么越变越强”，前者是静态系统，后者是进化系统。
模型能力不等于 Agent 系统能力，能力是锯齿式的，很多“更强的模型”只是叙事更强，不是能力更强。
模型决定能力上限，工程化体系决定交付下限，代码生成率做到 90% 不解决问题，成本只是从开发转移到测试和线上。
Loop 里能自动化的是执行，不能自动化的是决策和验收，最终还得人拍板。
离“真正的自进化”还很远，最大的缺口是 Agent 没有人的上下文。
查看大会日程解锁更多精彩内容：
https://qcon.infoq.cn/2026/shanghai/schedule
完整直播回放可查看：
https://www.infoq.cn/video/52550fXfrMaZhMqwrsC5?utm\_source=home\_video&utm\_medium=article
以下内容基于直播速记整理，经 InfoQ 删减。
郭春晓：在你的实践中，“从 Harness 到 Loop”最本质的变化是什么？肖汉松： 核心是生产关系的变化。现在 Agent 能做很多事情，人从执行的职责里解放出来了。原来是我们人去找 AI 处理事情，现在变成 AI 自己处理完了，来找我们做决策。
任磊达： 业务层面的 Loop，包括现在的 graph，有点像从常规编程 Agent 里抽出来的概念。Harness 做的是怎么让 Agent 跑起来，要接各种 MCP、subAgent 这类基础设施。但 Loop 讲究的是怎么让 Agent 越变越强，要从具体落地里发现问题，再反哺给 Agent，让它越来越适配当前场景，这有点像 SFT。
曲奎林： 我作为前端，感受比较深的是从去年到今年有个大变化，开发人员在持续监督引导方面介入得越来越少了。一句话，从完成任务的角度讲，部分需求可以完全交给 AI 来做整体的生产闭环了。
肖汉松： 阿福线上 badcase 分三类。第一类 Harness 的问题，比如 prompt 写得不好，本来需要搜索解答的问题模型不收，或者工具描述写错了，该调的工具没调起来。第二类模型的问题，容易幻觉，比如用户没有上传体检报告，模型却给用户编一个体检报告；还有指令不遵循，告诉它回答中文，它有时夹杂英文。第三类数据的问题，线上检索回来的数据有问题，模型以为是对的，就答错了。
举一个例子，我们给 Agent 提供计算器工具，但它有时会并发调用十几个计算器去算一道题。原因是计算器的入参是数学公式，复杂的题它只能并发去调。后来换成代码解释器，Agent 自己写代码，一次调用就能算出来，这一个改动解决掉很多 badcase。所以很多问题，如果一开始做 Agent，大部分是 Harness 没设计好。
回到什么时候做 Loop。随着用的人越来越多、场景越来越复杂，线上 badcase 到了修不过来的程度，修复速度要按周算，我们定了目标至少提升到天级别。今年过年 OpenAI 发布了 Harness 工程实践，用 Codex 写代码，全程无人参与。我看到后就想，既然能让 Agent 写代码做需求，也能让 AI 帮我们修 badcase，所以三四月份建了修复 badcase 的 Harness，让它自己修、自己验证。做完又发现，虽然 Agent 能修了，但还是要人派任务。而 Agent 本来可以持续工作，只要把目标定好就能持续工作。所以我们进入 Loop 阶段，让 Agent 自己找 badcase、自己修，本质上就形成了自进化机制。
任磊达： 游戏场景跟 Agent 场景首先有个最大的不同，用户并不认为它是个不确定系统，很多情况下他认为它应该是确定性系统，所以对错误的容忍度不高。bug 就是 bug，不是大模型底座能容忍的。
技术上，GPT-6 出来之前，整个多模态还处在一个非常混沌的状态，AIGC 更多还处于抽奖的状态，很难工程化提升，所以 AIGC 那块效果不好的时候，我们 Agent 的转型更多放在代码层面。代码层面的痛点更多在于游戏本身的复杂度，我之前做互联网，一个组的工作在游戏这边可能就是一个同学，甚至一个同学兼任几个组。
这过程中，现有模型的上下文还是大瓶颈。1M 上下文很多模型支持得不好，成本低的模型还在 200K 左右，就需要更多人的 loop，把任务拆下来。给任何模型算 1+1，成功概率都很大，前提是上下文控制得好，但精力稍微涣散，它就很容易出一些奇奇怪怪的问题。所以复杂度层面、多模态两个都是大攻坚点。管理层面，游戏更偏创业性产业，要提高大家对创意的投入，这也是从个人提效到组织提效的难点。
任磊达： 现在很多更强的模型，更多时候不是能力更强，而是叙事更强，让大家觉得它在所有地方都更强。实际上现在模型的偏好特别厉害，比如 GPT-6 的 3D 建模能力很强，但编码能力没有质的突破；Kimi K3 的前端 UI 审美能力特别强。但排行榜并不会用多维角度去度量什么叫更好的模型。我们用更好的模型时，也经常遇到死循环，用 Manus 去跑这些模型，经历的问题多了，其实在对所谓更强的模型祛魅。
更重要的，是要相信它是有不确定性的，抛去模型本身的叙事之后，我们要把什么东西交给它？因为我们做后服务器长期运营，很多安全运营审核的场景一定要有人的介入。比如网络的边界，不能让 Agent 随便穿过；发布的流程也要保留一些灰度发布的成分来保证服务的稳定性。
郭春晓： 我大概理解了，现在一些底线的问题，其实必须由人来守护。另外想补充，模型能力到底等不等于 Agent 系统能力？其实不等于，因为模型能力是锯齿式的，现在的模型本质上都没有记忆，你必须借助 Agent 的系统能力。还有营销的场景，资损特别大，正常系统有十万分之一的概率有个 bug，但营销系统如果有人发现漏洞，就会把它放大成 100%，所有人都来薅羊毛，事件就变成 100% 了。
曲奎林： 最关键的变化确实在模型之外。模型解决的是能不能生成代码，但业务交付还要解决安全性、稳定性、协作效率、业务结果，中间差了一整套功能体系。
去年大促我们在互动层面做实验，把模型开放给用户，做一个 AI 生成游戏大赛。过程中在 Agent 里做了很多实时验证，但只验证代码能不能跑通，最后看到用户生成的作品，实际 40% 是不可用的，根本玩不了。这说明模型后面还需要很多工程化体系约束它的不确定性。
我们内部交付分几种。第一种是中后台场景，比如运营提交商品表单时设置错误，能不能通过 Agent 的巡检方式解决。第二种是前端代码交付层面，中后台是高频、低定制化的场景，可以用 DSL 让模型生成意图而非实现，加上安全性验证、稳定性巡检。再就是对定制化、低频的需求，比如 C 端，需要多个 Agent 协同、与专家决策。最后会有性能转化和视觉守门。所以模型决定能力上限，工程化体系决定交付下限，真正突破的是把不确定的模型能力装进确定性的交付系统。
曲奎林： 如果只看代码生成这一步，数据会非常漂亮。去年年底我们全员接入使用后，AI 代码生成率可以达到 90% 以上。但把视角拉到交付周期，就会发现它只是把成本从开发阶段转移到测试和线上。大量生成的代码不够可靠，测试阶段不断反复返工，一些隐藏的性能、兼容性、业务风险会直接被带到线上。特别是 C 端页面，生成时没法做验证。所以代码写得快，不代表需求交付得快。真正应该关注的，不是代码生成率，而是端到端的交付周期、一次性通过率、线上事故率，以及最后业务想要的效果。
任磊达： 最大瓶颈还是顺着曲老师刚刚讲的“验证”。现在外部出来的东西，bug 率是之前的两到三倍。怎么解决？肯定是让 Agent 自己去把问题发现出来，人才能真正把效率提上来。
验证中间还有很大瓶颈。Agent 如果让它查自己的代码，一定会有形式化的验证，它会按代码实现去验证，这本质就是为完成任务而完成任务，没有任何实际业务价值，同时让代码越来越难维护。另一方面，它验证了很多东西，甚至都不写断言，如果 prompt 比较简陋，它就把 happy path 跑通，就认为验证完成了。我觉得我们这个场景最大的瓶颈还是在验证这一块。
曲奎林： 我认为最大瓶颈还是两点。第一个是前置的需求怎么澄清。业务可能提不出特别精细化的需求，需求方向理解错了，代码生成得越快，偏差越远。很多业务需求天然就是模糊的，背后有大量没被表达出来的约束。Agent 不仅要听懂用户说了什么，还要根据历史业务信息、交付记录、客观知识，主动发现信息缺口，提出正确的问题，才能把需求转化成可执行、可验证的目标。
第二个是结果验证。前端交付不仅要求视觉上像素级的还原，还要受机型、浏览器、网络环境影响。Agent 如果只是盲写代码，很难既通过视觉验收，又发现定位真机的问题。怎么让 AI 自己识别这些问题？一方面加强 D2C 的能力，把设计稿转化成可执行的设计约束；另一方面让 AI 把测试用例跟真机真正联动起来，看到运行结果哪里错了、为什么错。简单说，前面解决需求有没有理解对，后面解决结果做没做对。
肖汉松： 我补充一个点，现在很多 Agent 的问题，大部分是因为上下文不够。回到平时做需求，你经常发现它做出来的东西不是你想要的，才发现是我们有些信息没说清楚。因为我们认为理所当然的信息，比如业务背景、做决策的取舍，Agent 都没有，它只有你的一句话，或者一个 PRD。倒推回来，是因为现在整个研发模式还是围绕人的，这些信息都在我们脑子里。以前自己做需求写起来很快，因为开会交流、在团队工作十年，很多屎山代码的潜规则我都知道，但 AI 不知道。所以最大瓶颈在这里，怎么解？可能要改变的是整个团队协作，短期只能靠人肉给 AI 补信息。
郭春晓： 任磊达老师说的怎么验证，确实是一个当前还没被解决的问题。后端系统相对好验证，但像营销这种前后端一体的，要去真机上验证，尤其视觉方面，颜色 RGB 有一点偏差就很难验证。我再补充一点，现在 Agent 基础设施其实不是那么健全，以前都是为人打造的，今天一个团队十几个人，一个人有三四个 Agent，同时并发开发就涉及大量抢环境的问题。另外，开会、文档、很多上下文还没完全被 Agent 访问到，所以还需要一个另外的 Agent，它除了能访问 code，还能访问组织的上下文。
肖汉松： 阿福内部 badcase 修复流转分几个阶段。第一个是发现，来源有：每天一个日标的过程，人工去发现线上问题；用户反馈，比如点赞点踩；我们自己巡检，抽样后让 AI 按特定规则去巡检。第二个是归因，看是 Harness 的问题，还是模型的问题，还是数据的问题。归因之后分派给对应同学修复，就像以前做需求，你有个 issue，怎么分发给负责人。分派完进入修复阶段，prompt 有问题就改 prompt，模型有问题就去训模型。解决完进入验证阶段，通过评测集做自动化评测，评测没问题，最后上线 AB 实验，badcase 就算修复完成。
现在哪些能自动化？前面这些流程，AI 基本都能帮我们操作。归因原来人工弄，后来把日志、代码、归因问题发给 AI，它自己就能定位。定位完，我们给它一个路由表，告诉它哪些问题该谁处理，它就把工单分派给对应的人。后来我们做了个能力，可以指派一个 Agent 去修，比如 RAG 的问题有 RAG 小队处理，prompt 的问题有 prompt 小队处理。Agent 修完要自己部署、跑评测，现在评测也做成了工具让 Agent 自己调，验证完还能自己发布开实验上线。
但也不是全自动化了，那样我们也失业了。有两个关键点需要工程师做。第一个是方案的决策，Agent 修 badcase 要出方案，这个方案合不合理，是短期还是长期，要根据情况判断。第二个是验收，Agent 修完是不是真的修了、修到什么程度，要工程师验收。虽然 Agent 能自己验收，但上线前我们有个卡点，必须有人的确认才能上线。所以执行的事情都是 Agent 干，但方案决策和验收这两步，还是工程师整体把控。
任磊达：human in the loop 这个东西听起来特别不性感，但在我们的实践里，human 在里面的效用是最大的，它的品味呈现也是最好的。所以做 Loop Engineering，不能只是个人的 Loop，一定要做成团队的 Loop，把大家的主观能动性都发挥在 Loop 进化的过程中，不能期待 Agent 真的去做自进化。
曲奎林： 我们前端在业务交付里，最重要的就是建立一套机器评估与人类评估结合的 evaluation 机制。机器评估负责高频的客观检查，代码能否编译通过、测试功能是否通过、页面能否还原、是否回归。人类评估负责更深层的问题，是否符合业务目标、交互是否自然、代码是否真正可维护。肖老师也说过，human in the loop 基本不可避免。
举个例子，开发一个登录页，机器确实可以验证登录流程、错误提示、应用端适配、视觉差异。但流程是否真的跑通、交互是否符合业务预期，还是需要人判断，再把人的判断沉淀成测试用例，交给机器继续执行评估。判断一次迭代是否真的变好，不是看代码改了多少，而是看测试通过率是否提升、人工返工是否减少、同类问题是否不再出现。
经过筛选后要分类处理：业务规则、专家经验要进入知识库；典型的失败案例要进入 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 一下之前的东西是不是可以不要了。
肖汉松： 阿福现在在 Loop 上有了一些进展，但还是缺两个大问题。第一个是怎么样让 Agent 拥有我们人所有的上下文，这是最麻烦的一个点。很多事情我们自己知道，但 Agent 不知道。比如你给它加一个工具，上线后效果不好，原因可能是工具里的业务逻辑没写全，导致它回答错了。
第二个差距是，我们现在整个 Agent Loop、还有 Harness 进化的闭环里，只包含了 Harness 本身，就是 prompt、工具、skill 这些模型外围的能力，还没有把整个模型纳入进化的闭环，这是我们接下来的重点工作。
最大的缺口，我觉得还是现在整个进化迭代的流程以人为中心，很多信息没留下来给 AI。很多时候开完会，会议没录音，你跟 Agent 提需求又要复述一遍，一复述可能就漏掉东西。团队大了，很多业务信息没记录，背后的决策都丢在人脑子里。但未来随着内部工作协作软件慢慢进化，这些信息会慢慢记录下来，让 AI 去调取，它拥有上下文之后，做很多事情就不会像现在这么傻了。
任磊达： 刚才肖老师说的一个词特别性感，叫 AI native，人在给 Agent 打工。研发团队的角色可能会变化，我们更多在为 Agent 服务。但这个在我们内部还是持保留态度的，因为游戏本身要讲人性、以人为本。不过回到技术层面，就很好聊了。
我们去设计 Agent loop，这句话听起来复杂，但实际上在实验里，当现在常见的 Agent 都有 goal 那些命令时，我们会在不知不觉中锻炼设计 Agent loop 的能力。给 Agent 设一个 goal，它会有一个非常长程的任务在跑，跑完看结果，就知道之前给的 goal 描述得准不准确、loop 构建得精不精确。因为能看到结果，就知道上一次问题在哪，不断提高个人能力，对整个 loop 的 build 能力在团队里也会提升。实际上，业务团队一般不会大量调用大语言模型去写 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 能不能跑起来、能跑多快。
