提效软件研发，AI Agent好用吗？

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

策划 | Kitty

编辑 | 宇琪

2025 年是 Agentic AI 应用的元年，AI4SE（Artificial Intelligence for Software Engineering）能提升效率在行业内形成了高度共识，但在企业落地上面临了不少挑战。那么，AI Agent 实施中有哪些“真坑”与“实锤”？AI 又是如何重塑“需求 - 开发 - 运维”全流程的呢？

近日 InfoQ《极客有约》X AICon 直播栏目特别邀请 了趣丸科技运维总监刘亚丹担任主持人，和中兴通讯资深需求教练和 AI 教练王玉霞、蚂蚁集团高级前端技术专家郭华翔、趣丸科技基础架构组负责人黄金一起，在QCon全球软件开发大会 2025 上海站 即将召开之际， 抢先窥见 AI4SE 的下一站。

部分精彩观点如下：

• 前端知识库具有三大特点：结构复杂、对多模态支持需求高，以及必须重新组织以适配 AI 的理解方式。

• 自学习需要让 Agent 从人机协同中持续学习。人在修正 Agent 决策的过程中，模型从成功经验中学习到非书面化知识，这些经验需通过微调或再训练方式回馈给模型。

• 在落地过程中，效率和质量的提升确实是最容易打动人的。但在衡量这些指标时，我们也要重视“人”的因素，人的成长与幸福感提升同样是 AI 应用的重要价值所在。

• 如果因为技术变化快而犹豫不前，就会错过时机。正确的做法是先上手使用，再在实践中不断优化，让 AI 真正服务于自身研发诉求。

• 无论未来如何变化，人的创造力与价值追求始终是最核心的部分。

在 10 月 23-25 日将于上海举办的 QCon全球软件开发大会2025 上海站上，我们特别设置了 【AI4SE：软件研发提质增效实践】 专题。该专题将结合企业现状与 AI 工具落地软件研发过程的案例，探讨 AI 赋能软件生产过程的场景和效果以及如何构建 L3 级别的 Agentic 技术方案。

查看大会日程解锁更多精彩内容：

https://qcon.infoq.cn/2025/shanghai/schedule

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

完整直播回放可查看：https://www.infoq.cn/video/kKZYkVU4T2QJQ9fjkZmv

刘亚丹：当前的 AI Agent 在研发体系中，到底是一个“聪明的助手”，还是一个可以自主决策的“同事”？它的能力边界在哪里？传统研发的链路（需求 - 设计 - 开发 - 运维）正在如何被 AI Agent 改造？

郭华翔：以前端领域为例，今年在思考产品定位时，我们提出的概念是“AI 协同研发工具链”，希望在研发的全链路上实现工具的智能化升级。之所以强调“协同研发”而非“智能研发”，是因为目前 AI 的能力在简单研发任务中表现良好，但在复杂研发场景中，它更多起到的是辅助决策的作用，因此“协同”这个词更为准确。从技术实现上看，Agent 本质上是一个循环（Loop），而现在常提到的“Human in the Loop”说明人在循环中的介入仍然非常重要。

我们这样界定 AI 的能力边界：凡是工作中重复的、机械的、让人不愿意做的事情，都可以交给 AI 来完成。例如日常的单元测试用例生成、埋点、D to C 的 UI 还原等。这些工作重复且成本不低，却是 AI 擅长的领域。相应地，人类可以将更多精力投入到项目设计、复杂问题的处理等更具创造性和决策性的环节。

至于前端领域对 AI 接受度较高的问题，我的真实感受是，业界在 AI 兴起后对前端的“唱衰”反而最为严重。每次新模型推出时，大家都会调侃“前端要被取代了”。这种现象的原因在于，AI 在前端代码生成方面的效果确实比较好。一方面，前端开源代码资源丰富，模型在训练时因此具备一定倾向性；另一方面，前端代码的交付成果直观可见——生成一个 HTML 页面或功能页面，立即可以展示。这种“可视化的成果”让人更有感知，从而产生“前端受冲击更大”的印象。但我认为，这并非前端对 AI 接受度更高，而是 AI 在前端领域的应用更具可见性，给人一种影响更直接的感觉。从实际情况看，要实现真正的 AI 协同研发，前端领域仍面临很多挑战。

刘亚丹：黄金老师，您运维的 Agent 都能自学习了，它现在能替 On-Call 工程师做决策了吗？

黄金：运维本身是系统稳定性的保障，如果引入过多不可控因素，会让人难以接受。目前，大模型在运维领域的主要作用是辅助人类——让一个人能完成十个人的工作，或显著提升效率。但人依然是系统中不可替代的核心，当前大多数 AI 应用仍以“增强人”的能力为目标。

AI 目前最擅长的，是一些事务性或流程性的工作，例如单据申请、知识查询、执行标准化操作流程等。但在“客户满意度”或“授权审批”等关键环节，我们仍需要人工参与。因为运维的许多工作依赖流程与多人协作来保障系统稳定，即便 AI 执行正确，也需要人工复核，以防疏漏或误操作导致故障。此外，运维还涉及跨部门协作，例如与产品或测试团队的配合，这些目前 AI 远不能替代。即使未来可能实现，至少现阶段仍需人工主导。再者，运维中存在许多非标准化、需经验判断的场景。让 AI “猜”是不可接受的，这类问题必须由人决策。

我们可以将 Agent 的操作分为“读”和“写”两类——“读”一般问题不大，即便 AI 查询出错也不会影响系统稳定；但“写”涉及变更操作时就必须极度谨慎。由于大模型基于概率生成，存在“幻觉”和错误风险，如果盲目放权，会导致严重后果。因此，AI 应作为辅助工具，由人来发起、审批或监督流程。

郭华翔：这让我想到一个玩笑：有一天你在运维时突然发现 AI 把你的应用下线了。这其实正是当前在运维领域使用 AI 时必须格外谨慎的原因。

刘亚丹：玉霞老师，您做需求 Agent 也一定会涉及到对需求的理解和决策，您如何看待 Agent 自主性的问题？在需求这个看似更“人性化”的领域，边界又在哪里？

王玉霞：我们在需求管理中提出了“需求 Agent”的概念，最初是以“需求 Copilot”的辅助模式开始的。如果需求分析不清晰、价值理解不到位或洞察不充分，后续的工作往往都是徒劳的。因此，我们希望通过更精准的需求分析，识别真正的用户痛点与价值。

目前我们的需求 Agent 能够帮助需求人员处理大量重复性工作，比如用户访谈内容的整理、竞品信息收集等。AI 会先整理好数据，而需求人员则负责筛选和判断哪些信息真正有价值、哪些问题需要重点关注。

在实践中，我们为 Agent 设置了多个“卡点”，即在其完成一定任务后，必须征询人工确认。例如，Agent 分析完需求价值后，需要由人来判断其结论是否正确，再决定是否进入下一步流程。过去为了赶进度，需求阶段的许多细节往往被忽略，如今可以借助 AI 把这些环节做得更精致。现在，我们的需求人员可以将精力集中在价值判断和用户场景挖掘等更高层面的工作上。

刘亚丹：在 AI Agent 落地过程中，最让你们“头疼”的挑战是什么？是技术瓶颈、数据质量、团队接受度，还是流程改造？玉霞老师，您从 0 到 1 构建知识工程，第一步是不是先得“说服”大家？您是怎么做到的？

王玉霞：研发团队最初并不太能接受 Agent 的概念，他们会质疑：Agent 是否真正理解我们的业务？它生成的内容质量是否可靠？为了解决这一问题，我们引入了知识工程的概念。没有知识工程，Agent 就无法理解企业业务知识，效率提升也无从谈起。

然而在刚开始推动时，团队普遍抵触知识工程的构建，因为过去沉淀的知识大多结构化程度低、格式不统一，提炼难度大。对此，我们的教练团队首先承担了知识库建设的基础工作，从必要性入手，完成了前期的要素梳理与框架搭建。完成初步建设后，我们选择了一个最具痛点、交付压力大的团队作为试点，他们对提效有强烈需求，也愿意配合我们进行最小化验证。我们为他们构建了知识库并进行实践验证，比较有无知识库的效果差异。

结果显示差异显著：没有知识库时，Agent 输出内容往往偏离实际需求；加入知识库后，Agent 能进行波及分析和业务层面的推理。虽然结果不可能百分之百精准，但有了五六成的可用程度，团队再稍作修改即可满足要求，质量显著提升。尤其在需求波及分析场景中，知识库帮助 Agent 识别出以往人工分析常漏掉的关联点，使分析更完整。这让团队切实感受到收益，愿意主动使用 Agent。

刘亚丹：前端智能研发需要什么样的知识库？是组件库文档、最佳实践，还是用户的交互数据？

郭华翔：前端与服务端等其他领域不同，其技术栈灵活多样，知识可大致分为几层：底层是 HTML、CSS、JavaScript 等基础语言；其上是 React、Vue、小程序等领域特定语言；再往上，不同团队会基于最佳实践和经验沉淀自研业务框架或组件库。基础模型通常已掌握前两层的通用知识，但对于团队自建框架、封装组件或领域经验，模型往往无法理解，需要额外训练或工程化手段来补足。

为此，我们主要采取三方面措施。第一，利用知识图谱将分散的知识体系化串联。第二，重构知识库，使其从“面向人类可读”转为“面向 AI 可理解”，通过结构化拆分、问答对构建等方式，让 Agent 能更好地理解。例如，采用 Query ID、规则集或上下文召回机制，使知识能被模型有效检索和应用。第三，对知识进行合理拆分。RAG 检索中，文本切分方式不同会影响召回效果，因此需要针对不同类型内容制定最优的切分策略。

此外，前端知识还涉及 UI 这一特殊维度。组件库或界面描述不仅包含文本，还需多模态理解。Agent 需要能基于文本或图像查询准确召回组件，这要求模型具备对 UI 图片的语义识别和匹配能力。前端知识库具有三大特点：结构复杂、对多模态支持需求高，以及必须重新组织以适配 AI 的理解方式。

刘亚丹：运维 Agent 的自学习进化，需要“喂”给它什么样的数据？这些数据的获取和清洗难度大吗？运维场景对准确性要求极高，Agent 在“自学”过程中如果出了错，如何回溯和归因？如何建立大家对它的信任？

黄金：通用大模型无法访问企业内部的数据，就像毕业生进入公司，需要先阅读内部文档、代码、规章制度，才能真正理解组织运作。同理，Agent 的自学习过程就是让其理解企业内部的运维实体、术语、流程规范和技术架构等高频知识。内部知识往往结构清晰、更新频繁，易于清洗和解释，但仍有技术架构图、图片等难以处理的内容。

更重要的是，真正的专业能力并非仅来自阅读文档。不同运维人员之间的差异主要在于对工具的使用经验与问题排查能力，而这些经验很难完全文档化，甚至有人不愿意记录。因此，自学习需要让 Agent 从人机协同中持续学习。人在修正 Agent 决策的过程中，模型从成功经验中学习到非书面化知识，这些经验需通过微调或再训练方式回馈给模型。

不过，这个过程中仍存在知识错误的问题。仅靠大模型提取和结构化并不能完全避免错误或过期内容。因此，需要建立知识反馈机制：只有被使用或被指出错误的知识，才值得更新。通过消费反馈流程，我们能识别被使用且存在问题的知识，再次修订并结构化输入模型，保证数据的可靠性与时效性。

文档类知识可借助 RAG 技术与标注工具较好处理，但技术架构图或隐性知识仍是难点。运维场景对准确率要求高，因此必须能追踪错误来源。相比传统 AI 运维模型，大模型的优势在于可保存推理过程与决策依据，通过追踪与反思机制改进模型表现。例如，用户反馈结合模型的思维链追踪，可帮助发现问题原因，再整理成高质量数据集重新微调，从而持续优化模型表现。

最后是信任问题。建立对 Agent 的信任是渐进过程，需要让决策与执行过程透明化。在关键环节保持人机共审机制，使运维人员能介入并理解 Agent 的思考逻辑。随着协同机制的优化和输出准确率的提升，信任也将逐步建立。透明的决策与可控的协作是推动 Agent 真正融入工作的关键。

刘亚丹：投入这么大做 AI Agent ，如何衡量它的投资回报率？除了“提效”，还有哪些更重要的衡量维度？

黄金：要打动别人去使用你的 AI Agent，最直接的方式往往是展示效率提升的效果，这是大家衡量收益的常见指标。但除了效率，我们还需要关注质量和人的维度，也就是“质、效、人”三个方面共同评估。

在大模型刚出现的初期，模型运行缓慢，不一定带来效率提升，但可能显著提高产出质量。衡量回报可以从两方面入手：一是直接指标，比如研发效率、代码生成占比、迭代速度、Bug 数量变化等；二是更容易被忽视的“人”的层面。AI 的介入在一定程度上能提升人的心智水平和工作体验。举例来说，我们团队以前没有从事 IDE 插件开发的人，但借助 Vibe coding 的方式，团队成员快速掌握并开展了相关工作。

对于一些固定、繁琐的工作，让大模型或 Agent 来处理，可能在速度上不一定超越熟练的人类开发者，但能显著减轻人的重复劳动负担，提升工作幸福感和专注度。长期来看，这能促使整个研发团队向更高效、更积极的方向发展。

在落地过程中，效率和质量的提升确实是最容易打动人的。但在衡量这些指标时，我们也要重视“人”的因素，人的成长与幸福感提升同样是 AI 应用的重要价值所在。

刘亚丹：华翔老师，在蚂蚁这样体量的公司，推动这样一个大型智能项目，最初的立项是如何论证其必要性和潜在 ROI 的？

郭华翔：我可以基于团队实践经验总结几点，这里不代表公司观点。从 AI 提效的角度看，我们常用的衡量指标无非包括代码产出量、有效代码比例、自动化测试用例数量、UI 比对识别问题数等。但若要准确衡量 AI 带来的整体提效，比如“效率提升 30%”这样的指标，其实从完整的研发生命周期角度来看是很难量化的。回顾我们项目的推进，大致经历了三个阶段。

第一阶段是“氛围带动期”。大约一年前 AI 刚兴起时，我们看到许多公司在探索 AI coding 或 Agent 应用。虽然当时业务场景不一定成熟，但我们认为不能等待，而应主动尝试。那时我们做了一些内部小规模实践，比如提升日常问题处理效率、优化工具使用体验、尝试简单的代码生成。尽管模型能力有限、效果一般，但这阶段种下了探索的种子。

二阶段是“落地成效期”。当项目初见成效、需要向管理层汇报或纳入年度规划时，问题就变成了：要投入多少人力？投入产出比是多少？提质提效的指标怎么设？我们当时并未过分强调效率指标，而是聚焦如何“快速把事情做成”。我们基于蚂蚁内部原有的前端基础设施进行整合与智能化升级，从而在较短时间内打通了 “AI for IC” 的全链路，实现从单点突破到整体智能化改造。

第三阶段是“推广共建期”。项目上线后使用体验良好，团队积极反馈，其他部门也希望加入共建，共同推进智能化研发工具的使用。这样不仅提升了项目的内部与外部影响力，也强化了企业的基础体系建设。

战略是打出来的，不是等出来的。AI 技术发展迅速，今天的创新可能明天就成常态，后天就被淘汰。如果因为技术变化快而犹豫不前，就会错过时机。正确的做法是先上手使用，再在实践中不断优化，让 AI 真正服务于自身研发诉求。

刘亚丹：“AI 时代最大的红利是行动”。当方向尚不明确时，先迈出一步，本身就是在通往成功的路上。AI Agent 正在改变研发模式，这是否意味着程序员、运维工程师、需求分析师等角色定义会发生根本性变化？各位团队的同学需要具备哪些新技能来适应这个趋势？是更需要 Prompt 工程能力，还是业务理解能力，或者是 AI 运维能力？

王玉霞：随着 Agent 的出现，我们团队也在探索“一个人带一个团队”的新型研发模式。目前传统研发角色定义暂未根本改变，但在新模式下，角色边界正逐渐模糊。例如，需求和测试可能由同一人负责，或由人和 Agent 协同完成。我们仍处在不断实验与调整的过程中。

很多人担心 AI 会替代岗位。其实，AI 并非消灭工作，而是提升岗位要求，关键在于人如何去驾驭 AI。以“提示词工程师”或“上下文工程师”为例，不同技术阶段要求不同，但核心能力是开发与应用 AI，让它真正服务于业务，而不仅仅是“被动使用者”。我们要具备设计并打造适合自身业务的 Agent 的能力，而非仅依赖他人提供的工具。

AI 生成的内容需要人判断其准确性与合理性，如果业务理解或技术能力不足，就可能无法识别其中的错误或偏差，从而将潜在风险带入产品中。AI 不会自行考虑后果，若缺乏明确约束或规则，它可能“自由发挥”，生成看似完整、质量高但实则存在隐患的内容。

我们也有内部实践发现，AI 生成的前后端应用虽然开发速度快，一两天即可上线，但上线后往往暴露出诸多问题。生产效率提高了，但质量未必可靠。因此，要真正用好 AI 和 Agent，必须在设计阶段就全面规划和约束，确保每个环节都得到有效控制和质量把关。

刘亚丹：首先，角色确实在发生变化，我们需要思考如何跟上这种转变。正如那句话所说，“取代你的不是 AI，而是会使用 AI 的人。”因此，我们首先要主动拥抱技术，让 AI 成为自身能力的加成。其次，AI 的确能够高效完成任务，但我们也要具备判断能力，去区分“做得快”和“做得对”之间的差别。

黄金：随着 AI 的发展，业界逐渐形成一个共识：AI 不会完全取代开发者，而是会促使角色的重构。从我们内部的观察来看，研发岗位的能力正在趋向融合。首先，开发者需要了解 AI 的边界，明确它能做什么、不能做什么。其次，要学会如何与 AI 协作、驱动其产出并验证结果。由此我们提出了“T 型人才”的概念。

所谓 T 型人才，指的是既了解整个研发流程，又在某一业务领域具备深入理解的人。如果对自身业务场景缺乏理解，无论 AI 能力多强，也难以产出真正有价值的成果。开发者需要对用户和交互有深刻理解，这种角色的融合体现在研发、测试与产品职责的交叉上。举例来说，如果不懂测试逻辑，就难以验证 AI 生成代码的质量；如果缺乏产品思维，也无法让 AI 产出具备价值的功能。至于提示词工程，我们发现随着模型能力的增强，其重要性会逐渐下降。更关键的将是对业务的理解、对行业的洞察以及对 AI 使用方式的把握。AI 的加入，促使研发角色向更高价值的方向演进——从过去单纯“码字”的工作，转变为对产品和用户需求的深度理解。

未来，研发人员的主要职责将是结合 AI 洞察用户需求，在特定场景下推动创新，并利用 AI 生成能够承载这些创新能力的产品。同时，要监督 AI 的协作过程与输出结果的正确性。这将成为研发角色的核心变化，即从执行型角色向决策与创造型角色转变。

郭华翔：未来的研发不会消失，而是会变得更加多元。可能会出现两类人：第一类是能够熟练使用 AI 工具的人，他们就像 copilot 系统中的“pilot”，能够有效地指挥和驾驭多个 agent，提高研发效率和质量。第二类是我们正在探索的新角色——AI 应用工程师。他们利用传统技术（如前端 JS、后端 Java 或 Kotlin 等）结合 agent 构建与 RAG、上下文工程等 AI 技术，去设计和开发新一代的智能研发工具与产品。

这种 AI 应用工程师不仅要具备传统开发技能，还需掌握 AI 相关知识，包括长上下文管理、agent 框架与构建方法等。未来的研发不再沿着单一方向发展，而是朝不同维度演进。每个人都可以思考自己更适合成为哪一类研发者，并据此规划发展路径。

刘亚丹：对于广大中小企业来说，可能无法从头构建自己的 Agent 系统。应该优先在哪个环节（需求、开发、测试、运维）引入 AI Agent ？你们的技术方案中，有哪些部分未来可能开源或已经可以借助开源方案来实现？能否给他们一些低成本起步的建议？

郭华翔：中小企业没必要事事从零开始，当前业界已有大量成熟方案，问题往往不是“没有可用工具”，而是“不知道该选哪个”。从基模型（如 GLM、Kimi）到上下文管理工具（如 Content7、MCP），再到 agent 框架（如 LangChain、LangGraph），以及 SPEC 驱动工具，几乎每个环节都有可用的开源方案。关键是明确自身痛点，然后选取最合适的工具。这些工具当然无法解决全部问题，但若能先解决 60%-70%，已经能带来明显提升。随着 AI 引入后效率提高，企业自然有更多精力优化架构和实现个性化需求。

王玉霞：我们公司也分两种情况：一是自研 AI 研发工具，优点是能与内部系统打通，体验顺畅；但由于要兼顾各业务部门需求，推进速度往往赶不上外部 AI 的发展。二是各研究团队也会利用开源工具做前沿探索，从模型到 agent 框架均采用开源方案，以小投入快速验证业务场景，再将成熟经验集成回内部工具中。这样既能鼓励创新探索，也有助于内部工具的自我成长。未来，企业内部研发工具的成熟度提升后，也会逐步开放和开源，建设更广泛的生态。

黄金：对于中小型企业，我不太建议大规模自建 AI 系统，尤其在缺乏人才储备和对 AI、agent 技术理解不足的情况下，盲目投入可能会造成信心受挫。目前 AI 技术仍在快速演进阶段，尚无统一标准，各种方案百花齐放。

目前在研发流程中，引入 AI 最合适的环节是开发阶段。无论企业内部架构如何，开发语言与技术栈相对标准化，可以较容易地融入 AI 能力。例如在测试阶段，可通过视觉模型实现 UI 自动化测试等，这类方案已有成熟工具可用。虽然短期内难以显著提升整体效率，但在局部流程上能带来明显改善。

对于深入 AI agent 开发的团队来说，私域数据的模型微调是常见挑战。我们现在的方案是通过 Langfuse 采集 trace 数据与用户反馈，再利用 Easy Dataset 自动生成微调所需数据集，包括常见的 QA 样本；同时还会从内部文档中提取语料，配合 LLAVA Factory、XLOSS 等工具进行微调。

刘亚丹：如果展望未来 1-2 年，你们认为各自领域 AI4SE 的下一个爆发点或颠覆性应用会是什么？华翔老师，有想过前端工程 3.0 之后会有 4.0 吗？会是什么样子？

郭华翔：前端的核心依然离不开与 UI 以及用户操作界面相关的内容，因此未来前端的爆发点仍然会围绕多模态展开。多模态主要体现在两个维度：一是如何从视觉稿或图片生成代码；二是如何利用多模态技术实现 UI 的自检与质检，从而保证产物的稳定性。

此外，当前各公司内部已有大量工具，但由于历史原因，这些工具往往分散各处、难以统一调度。因此，我认为未来可能会在 browser use 或 computer use 等方案上迎来新的爆发点。这类方案无需对现有架构进行全面改造，就能在一定程度上帮助企业提升研发链路的串联效率。

前端工程 3.0 并不是对以往体系的完全颠覆，而是在传统优秀经验的基础上叠加智能化能力，通过 AI 提高工具的易用性与开发效率。如果从这个角度看，未来或许会有 4.0 的出现——随着模型的进步，AI 将能解决更多不确定性问题，从而催生新的架构和研发范式。

但也有可能不会再有“4.0”这个概念，因为 AI 的到来正在重塑研发的角色和定位。AI 的赋能让一个原本的前端工程师成为“超级个体”，不仅能做前端，还能涉足后端、设计等多个领域。这时，我们再去定义“前端”或“后端”的意义就不大了。未来也许不再区分前端工程，而是回归更宏观的“软件 3.0”或“软件 4.0”的概念。

刘亚丹：玉霞老师，如果需求 Agent 再进化，未来会不会出现“AI 产品经理”（有可能现在已经出现了），甚至部分替代产品经理的角色？

王玉霞：其实在一些小型应用场景中，AI 已经能够完全独立完成开发，我们称之为“AI 原生”应用，但这并不意味着 AI 已经取代了产品经理。对于简单应用，AI 确实可以从头到尾实现开发与上线；但对于一般或复杂的应用，AI 仍然无法独立完成，需要人与之协同。

目前我们将应用分为三类：第一类是简单应用，可完全交由 agent 开发；第二类是中等复杂度的应用，需要人机协同；第三类是大型复杂系统，仍以人为主导。对于复杂系统，我们通常会将项目拆解为更小的模块，交由 agent 分步执行。这样 agent 能更高效地辅助开发，而人类则负责整体架构与产品逻辑的设计。随着技术演进，AI 的自主能力会逐步提升，复杂工程也有望被拆解为更多可自动完成的子任务。

刘亚丹：黄金老师，趣丸运维 Agent 经历了从 1.0 到 2.0 的自学习进化。如果展望运维 AI 的 3.0 阶段，您认为它的形态会发生根本性变化吗？AI Agent 的深入应用，是否可能从根本上重塑运维的范式？比如，直接告诉 Agent“保证数据库服务在高峰期的稳定性”，它就能自主分解任务并执行。您认为这种变革在未来一两年内会初现端倪吗？

黄金：参考李飞飞提出的 AI agent 综述，我们认为有几个关键趋势。首先是在感知层面，AI 将能理解更复杂的外部数据。例如，大模型已具备一定的视频理解能力，能从视觉、文本等多模态输入中获取信息。其次，随着 agent 的发展，现有大量以人为中心设计的运维系统与基础设施，也将逐步转向面向 AI 的交互模式，比如更适配 agent 的数据结构和通信协议。

未来可能会出现 agent 间通过类似 MCP 或 A2A 协议进行交流的场景。届时，多个 agent 可以像操作系统中的进程一样相互协作，独立又互联。这种多 agent 协作目前仍然复杂，但被认为是 AI agent 3.0 时代的核心特征。正如 OpenAI 创始人提到的，AI 应用的最高阶段将是“多 agent 协作”，它将带来类似人类社会协作所产生的智慧跃迁。

未来的运维模式也会随之变化。过去我们强调平台工程化，通过平台统一各种运维工具；而未来的运维更可能是“动嘴操作”——通过自然语言指令调度多个 agent 协同完成任务。人将成为“口述驾驶员”，而 agent 则执行具体操作。

目前，多数 AI agent 系统采用“规划 - 执行”模式，通过任务拆解、分步执行的方式解决复杂问题，这在 Vibe coding 等场景中已得到验证。不过，多 agent 的高效协作仍需时间。它涉及时效性、计算开销等复杂问题。随着模型推理成本的下降，未来两三年内或将实现更稳定的多 agent 协作系统。

刘亚丹：我们人类在信息过载的环境中会被注意力分散，agent 其实也会面临类似问题。一个 agent 的上下文越大，它要关注的问题范围也越广，反而可能导致注意力分散。未来的 AI 发展中，无论是单体 agent 还是多 agent 协同系统，我们都需要关注如何让它们保持聚焦，合理分配注意力。只有保护好每个 agent 的“注意力资源”，AI 系统才能持续稳定地演化与进步。

观众：使用者在未知领域遇到 AI 幻觉应如何处理？

郭华翔：要让 AI 解决它本身不知道的问题，和人学习的路径类似：必须先补充领域知识，这可以通过标注、沉淀、借鉴或抓取相关资料来实现。让模型“知道”这些知识有几种常见方式：一是通过模型预置，例如后训练或微调，但这种方式更新慢、成本高；二是通过 RAG 或上下文工程在推理时注入外部知识。若没有相应的输入，单靠模型的记忆概率生成新知识是不现实的。模型确实在尝试推理与涌现，但若缺乏准确知识输入，就容易产生严重幻觉——表面上看很自信、很完整，但实际上是无用的话语。处理未知领域的关键在于保证模型在推理时能获得可靠的知识来源，而不是期望模型凭空创造出准确答案。

观众：AI 教练是做什么的？企业大规模 AI 提效涉及用户教育，应如何完成？

王玉霞：AI 教练主要承担三项工作：一是带领团队在 AI 前沿进行技术探索与实践；二是提炼并推广可落地的方法和工具，帮助团队快速复用好的实践；三是对项目组进行能力赋能，让团队在较短时间内体验到 AI 带来的收益并能上手应用。

在用户教育方面，我们发现传统培训效果有限，效果更好的方式是“战训营”式的实操教学——带着笔记本、以实际业务场景练习，边做边学。这样的实战演练能更快地将不同能力水平的同事拉平，让更多人切实感受到 AI 的价值。

观众：智能体如何互联互通？

黄金：很多人理想化地把 agent 问题当成马尔可夫决策过程（MDP）式的协作，希望 agent 之间像人一样互相协作解决问题。但现实中能真正高效协作的例子很少，根本原因之一是注意力预算与上下文管理的限制。上下文越长，信息越多，agent 的注意力和处理成本也越高，如何在有限的注意力预算内把“该知道的信息”准确地传递给需要的 agent，是一个复杂的问题。

当前多 agent 协作的常见模式有三种：第一是路由模式——请求由一个路由器分发给最适合的 agent，agent 回答后将结果返回；该模式在选错 agent 或信息不足时会失败。第二是由“管理员 agent”或规划器（planner）负责分配任务与调度，基于每步结果反思并决策下一步，这在实践中用得较多。第三是网状（broadcast）模式，所有 agent 同时获得信息并协作讨论，但这种方式计算与通信开销极大，随着 agent 数量增加成本呈指数级增长。

最近的一些研究提出了“专家召集（expert recruitment）”等机制：先判断问题所属领域，召集相关专家组成临时团队，由规划器按步骤分配任务，专家完成后再由规划器整合与反思。这种结构类似 supervisor 的层级，但挑战在于如何隔离并传递上下文，以及保证每个 agent 获得其执行所需的信息，否则规划会失败且需重试，耗时且代价高昂。

刘亚丹：当 Agent 越来越强大，我们作为开发者的价值究竟在哪里？

王玉霞：如今 agent 的能力越来越强大，但我认为这并不会削弱开发者的价值，反而更能凸显我们的核心作用。正如前面所说，agent 在理解业务、分析复杂问题、以及进行人际沟通等方面，仍然难以与人类相提并论。我们可以将标准化、重复性或大规模数据分析等工作交给 agent 去完成，而开发者则应把精力集中在更具创造性和思维深度的领域。

Agent 的出现不是在削弱，而是在帮助我们卸下繁琐的工作负担。过去许多事务都需要我们亲自完成，如今借助 agent，我们能够把更多时间用于设计、创新和沟通等更高价值的活动。这些是人类开发者无法被替代的核心能力，我们应当进一步强化并聚焦于此，让自身价值在更高层次上得到体现。

黄金：从工业革命、电脑的普及到早期的 AI 翻译，每一次都曾引发“人是否会被取代”的担忧。然而事实证明，技术并没有让人类失业，反而让人能从低效、重复的劳动中解放出来，去从事更有创造力的工作。

未来，AI 也许会替代部分具体岗位，但无法完全取代人的智力与创造力。若有一天 AI 真能与人类拥有相同的智慧与意识，它将不再是工具，而是一种新的“硅基生命”。但在那之前，我们要做的不是抗拒，而是学习如何掌握和利用 AI，结合人类更高层次的思维方式去创造价值。比如，当老板让你做调研时，如果只是把任务交给 AI，然后原封不动地提交结果，这样的工作很容易被取代。但若你能基于 AI 的研究结果加入自己的判断和见解，形成独立输出，这才是人类思维的真正价值所在。

郭华翔：回到开发者这个身份，编程本身依然是理解与描述世界的重要语言，就像物理和数学一样。未来无论 AI 如何发展，代码仍是构建智能系统的基础。AI 和 agent 虽然提升了生产效率，但它们自身依然是由代码构成的，因此理解什么是优秀的代码与架构，仍然是开发者不可或缺的能力。

其次，在企业级研发场景中，开发者面临的挑战不仅是代码产出的效率，更要思考如何保证架构合理、产品体验优秀、系统可持续迭代。这些问题正是当前 AI 仍难以完全解决的部分。因此，在未来 1 到 3 年内，开发者需要继续提升编程水平，同时善用 AI 工具，提高交付质量与效率。

刘亚丹：从另一个角度看，如果把开发者的价值仅仅局限在“写代码”，那确实低估了这个职业的意义。开发者服务的对象往往是产品经理，而产品经理又服务于最终用户。开发者的工作是把产品经理的构想通过代码转化为用户可感知的价值。因此，只要我们始终围绕“创造用户价值”去思考和行动，无论角色或技能如何演进，开发者的核心地位都不会被取代。

当然，如果有一天 AGI 真正实现，人类社会或许会进入一种“按需分配”的理想状态，也许那时我们甚至不再需要工作。就像《头号玩家》中，人们生活在虚拟世界中，探索新的存在方式。这当然是遥远的畅想，但也提醒我们——无论未来如何变化，人的创造力与价值追求始终是最核心的部分。

活动推荐