AI Agent重塑软件工程全流程：落地挑战与未来展望

随着2025年成为Agentic AI应用元年，AI4SE（人工智能赋能软件工程）在提升效率方面已形成行业高度共识，但企业落地仍面临诸多挑战。那么，AI Agent实施中有哪些真实痛点与已验证方案？AI又如何重塑从需求到运维的完整研发链条？

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

部分核心观点如下：

• 前端知识库呈现三大特征：体系结构复杂、对多模态支持要求高，且必须重构以适应AI的理解模式。
• 自学习机制需让Agent从人机协作中持续进化。人类在修正Agent决策时，模型从成功经验中习得非书面化知识，这些经验通过微调或再训练方式反馈给模型。
• 在落地过程中，效率与质量提升最易打动人心。但衡量时，我们同样需关注“人”的维度，个体成长与幸福感提升也是AI应用的重要价值体现。
• 若因技术快速变化而犹豫不决，便会错失良机。正确做法是先实践应用，再在迭代中优化，让AI真正服务于自身研发需求。
• 无论未来如何演进，人类的创造力与价值追求始终是核心所在。

以下内容基于直播实录整理，由InfoQ编辑精简。

刘亚丹：当前AI Agent在研发体系中，究竟扮演“智能助手”还是自主决策的“同事”角色？其能力边界何在？传统研发链路（需求-设计-开发-运维）正如何被AI Agent改造？

郭华翔：以前端领域为例，今年我们在产品定位上提出“AI协同研发工具链”概念，旨在实现全链路工具的智能化升级。强调“协同研发”而非“智能研发”，是因AI在简单任务中表现优异，但在复杂场景中更多起辅助决策作用，故“协同”更准确。从技术看，Agent本质是一个循环，而“Human in the Loop”表明人的介入仍至关重要。

我们如此界定AI能力边界：凡重复性、机械性、人不愿从事的工作，皆可交由AI完成。例如日常单元测试用例生成、埋点、设计稿转代码等。这些工作重复且成本不低，却是AI擅长领域。相应地，人类可聚焦于项目设计、复杂问题处理等更具创造性与决策性环节。

至于前端对AI接受度较高的问题，我的真实感受是，业界在AI兴起后对前端的“唱衰”反而最甚。每次新模型推出，总有人调侃“前端将被取代”。此现象源于AI在前端代码生成上效果较好。一方面，前端开源代码资源丰富，模型训练有倾向性；另一方面，前端代码交付成果直观可见——生成HTML页面或功能，立即可展示。这种“可视化成果”让人感知更强，从而产生“前端受冲击更大”印象。但我认为，这非前端接受度更高，而是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 agent3.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真正实现，人类社会或许会进入一种“按需分配”的理想状态，也许那时我们甚至不再需要工作。就像《头号玩家》中，人们生活在虚拟世界中，探索新的存在方式。这当然是遥远的畅想，但也提醒我们——无论未来如何变化，人的创造力与价值追求始终是最核心的部分。