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

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 以下内容基于直播速记整理，经InfoQ删减。 完整直播回放可查看：https://www.infoq.cn/video/52550fXfrMaZhMqwrsC5?utm_source=home_video&utm_medium=article 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 去跑这些模型，经历的问题多了，其实在对所谓更强的模型祛魅。 更重要的，是要相信它是有不确定性的，抛去模型本身的叙事之后，我们要把什么东西交给它？因为我们做后服务器长期运营，很多安全运营审核的场景一定要有人的介入。比如网络的边界