AI赋能企业增长：实战提效、数据治理与未来机遇深度对话

在全球数字化浪潮蓬勃发展的今天，人工智能正以前所未有的深度与广度渗透到企业发展的每一个环节，成为驱动创新与经济增长的核心动力。那么，如何借助AI技术发掘新的商业与增长机会？又如何利用AI实现更高效的用户获取、留存与转化呢？

近日，InfoQ《极客有约》与AICon直播栏目特邀值得买科技CTO王云峰担任主持，携手阿里巴巴高级技术专家梁筱武、彩讯股份AI产研部总经理邹盼湘，在AICon全球人工智能开发与应用大会2025北京站即将开幕之际，共同深入探讨企业AI提效的实战经验与复盘。

部分精彩观点摘录如下：

• 倘若没有幻觉，创造力便无从谈起。我们必须接纳这种跳跃性思维，同时通过工程化方法将其约束在合理范围内，方能获得理想成果。
• 在各类Agent系统中，数据治理始终是大模型工程实施前的关键前置步骤。
• 项目负责人必须拥有将底层AI能力封装成用户可感知、可理解、可使用的产品功能的能力，并能够与业务部门沟通、熟悉客户场景与流程，从中提炼AI需求。

以下内容根据直播速记整理，经InfoQ编辑精简。

当“小学生”邂逅“博士生”

王云峰：我们首先探讨“模型使用”话题。百川智能创始人王小川曾比喻，当前顶尖模型（如GPT-4、Gemini 3）的智能水平已达“博士生”等级。 但个人感受是：模型虽是博士生，而我们为其搭建的工程环境、乃至编写的Prompt，可能仍处于“小学生”阶段。 这种“能力错配”，常导致我们觉得AI不听话。在过去一年的实践中，你们在工程上如何真正用好这个“博士生”？是否有共识性的经验？

梁筱武：基于我长期从事GUI自动化的背景，以及现今尝试利用AI升级GUI能力，我总结出三点体会。

第一是根据具体场景选择基础模型。GUI操作本质更接近RPA，其在视觉定位与推理方式上，与语音或文本任务存在显著差异。因此，在基础模型的选型与组合上，我们进行了大量探索，尝试了国内外多种模型，最终发现千问3在我们GUI场景中的推理效果较为突出。

第二是Agent架构设计。AI Agent的架构与传统微服务工程体系不同，它需要从不确定性逐步收敛，而非遵循固定流程。因此，如何通过工程化手段使AI模型的输出在可控范围内，让这位“博士生”能与我们的系统进行有效且可控的交互，是架构设计的核心。

在GUI Agent中，我们采用了引入“裁判”角色的方式，在每一步操作中加入裁判判断，这是模型之外的关键机制。

第三是上下文工程，即以往所说的Prompt工程。由于我们不开发基础模型，顶多只会构建一些垂直小模型，如分析类小模型或局部图像识别模型，因此上下文工程成为实现AI工程能力的核心。

王云峰：公司此前举办黑客松，许多同事反馈，若未从头至尾完整构建过一个Agent，便无法真正理解上下文工程的核心意义。我们无法一次性将所有知识灌输给模型，但任务往往需要大量信息，如果上下文工程处理不当，模型能力仅能发挥一小部分。

邹老师，B端客户的需求通常较为固定，你们如何通过工程手段（如思维链CoT），让模型既发挥“博士”的智能，又遵守“小学生”的纪律？

邹盼湘：在B端场景中，C端与B端在AI应用上差异显著。先谈大模型常被提及的“幻觉”问题。许多人视幻觉为负面，但实则正因幻觉，模型才具备生成能力。若模型毫无幻觉，它仅是背诵知识，无法创造新内容。

因此，我们会根据具体场景反向推断是否需要幻觉。完全消除幻觉不可能，但我们可以决定何时需降低幻觉。在创作类场景，如针对不同用户群体的视频营销时，幻觉有助于生成更具想象力与多样性的内容；但在B端业务场景，我们通常需要尽力降低幻觉。

降低幻觉需明确方法：降低的时机、方式，以及在降低幻觉的同时如何保持模型的“博士生”水平。上下文工程在降低幻觉方面至关重要，我们需要将专家经验、工具API执行结果、插件结果、推理链等注入模型，以减少偏差。然而，仅靠上下文工程不足，因为幻觉问题可能源自多个环节，如知识检索、推理规划、工具调用或意图识别等。在B端，我们无法接受黑箱流程，因此我们提出了全流程可观测、可控的方法。

可观测分为三阶段。第一是意图理解，不同用户问题清晰度各异，因此我们需要意图澄清过程，确保获取真实需求。澄清后进入任务规划阶段，每一步的思考过程，包括使用的知识、调用的工具等，都需呈现出来，让用户看到模型的推理路径。例如行程规划，模型需反复询问时间、人数、交通方式、住宿偏好等信息，以确保规划符合需求。

上线前，我们通过让流程可观测、打印每一步推理过程、注入上下文等方式，使模型尽量沿预期路径执行。上线后，AI应用与传统IT应用的最大差异在于边界不明确。IT系统的输出是可预测的，但AI只能做到“预估”。我们可以将上线时的水平从60分提升至80分，但永远无法达到100分。上线后需不断通过迭代逐步从80分提升到90、95甚至99分，但依然不可能完美。

因此，我们必须通过工程化手段提前注入内容、人为干预或补充等方式，处理模型无法覆盖的部分。

AI模型只是整个系统的一部分，而非全部。因此，我们会增加许多配套模块和管理工具，甚至在某些场景减小模型规模，降低其泛化能力，以提升可控性。有时我们会让模型先生成规划，再由人工校验，最终将规划转化为可控的路径搜索流程。我们在行业内构建Agent时踩过许多坑，因此总结出AI落地应满足可观测、可迭代、可控、可信、可集成的要求。这些要求也反向推动交付团队与产研团队开发相应工具与工程能力，从而支撑整体落地。

王云峰：无论C端还是B端，大家最终的认知趋于一致：大模型的“智商”已很高，但仅有一个高智商的大脑不足以解决问题，仍需大量知识及工程化能力的支撑，而许多知识并不在模型本体中。因此不能期待模型一次给出最终答案，而是需用工程化手段确保其输出可控。

模型的创造性、涌现能力源于多样性，而多样性在今天被称为“幻觉”。如果没有幻觉，便无创造力。我们必须接受这种跳跃，同时用工程化手段将其控制在合理范围内，才能获得所需结果。

数据的“上下文”缺失挑战

王云峰：讨论完模型，我们谈谈“数据”，这是AI的燃料。在值得买，我们为了让AI做好消费决策，必须让它接触大量的用户行为和社区内容。这也是我推动MCP（模型上下文协议）的核心动力：我希望解决AI与企业私有数据之间的“上下文”连接问题。但说实话，此过程比预想艰难。在你们的实践中，让AI“读懂”企业内部业务逻辑，最大障碍是什么？邹老师，您在向B端客户交付时，是否需花费大量时间帮客户“清洗数据”？如果客户的数据质量极差，此时是强行上AI，还是建议客户先重做数字化？

邹盼湘：在实际落地过程中，许多客户会质疑：模型已如此强大，为何仍需要数据？需要何种数据？又该如何进行数据治理？要回答这些问题，需从“为何进行数据治理”谈起。

首先，模型往往无法理解企业自身的业务场景、流程和垂直领域的术语。例如，在运营商场景中，“套餐”指话费套餐，但若直接询问模型“帮我定个套餐”，模型可能理解为麦当劳或肯德基的套餐。因此，在具体业务场景中，我们必须将企业的私域知识传递给模型，使其理解特定术语的真实含义。

此外，数据治理还关系到专家经验的显性化与传递。专家经验通常体现为问题分析方法和处理流程，而模型依赖的是通用知识。如果缺乏专业知识的输入，模型无法解决许多场景化问题。

例如在运营商的10086客服场景中，用户可能咨询套餐、携号转网等业务，而携号转网有严格的流程和条件要求，无法随意办理。过去在线客服往往长时间也无法解决，而线下几分钟即可完成，正是因为其中涉及业务系统调用、条件校验等信息，这些内容若不提供给模型，模型便无法真正理解业务。

我们需要明确哪些数据需要治理，可分为两大类：一类是知识性数据，包括专家经验、文档材料、方案内容以及结构化的分析数据等。这类数据需要显性化沉淀，通常以PPT、Word、知识性数据可以通过两种方式与模型结合：其一是将数据纳入知识库；其二是用于模型训练。如果用于训练，需要明确模型类型（如多模态或语言模型）以及训练阶段（如SFT、强化微调或对齐训练），相应的数据格式、数据量与处理工具也不同，需要进行清洗、去重、标注、脱敏等工作。

如果知识进入知识库，则需考虑数据来源、类型、更新机制、冲突处理与时效性管理。治理的重点集中在解析入库、索引与召回阶段，确保知识在被检索时一致、有效且准确。

另一类数据是生产过程中的数据，包括API调用记录、系统日志、任务执行链路等。这类数据有时会作为模型强化学习的素材，但更多情况下，会在实时推理时作为上下文提供给模型。在此过程中必须设置严格约束，不能将所有数据直接暴露给模型，尤其在多Agent环境中，数据可能被模型错误缓存并在不同代理间传递，从而造成跨权限的数据泄露风险。

例如，若财务Agent获取到企业财务数据并被模型缓存，而招聘Agent又在无权限的情况下访问到这些缓存数据，就会引发严重安全隐患。因此，在生产数据治理中，需要重点关注账号体系、权限控制、隐私保护、数据脱敏，以及防范外部提示投毒等问题。

完成这些治理措施后，就需要进行模型效果评估。评估可分为技术指标和业务指标两类。技术评估包括准确率、召回率、回答一致性与相关性等；业务评估则关注用户增长率、客服难进率、销售转化率、用户活跃度等关键指标。这些业务数据的观测与分析，是Agent持续迭代优化的基础。

Agent能否持续迭代的核心驱动力是ROI，因此必须依赖这些上线后的数据来评估收益、定位问题是技术问题还是业务问题。此类数据治理属于上线后的持续运营工作，而非AI ready阶段的前置治理。

王云峰：梁老师，飞猪的GUI Agent是直接查看屏幕的，这似乎绕过了“数据接口”的治理难题。这算是一种“捷径”吗？这种方式对数据的理解深度足够吗？

梁筱武：在GUI Agent中，除了知识性数据，还有一个显著特殊性：图形数据。GUI的图像数据若不准确，就会导致模型无法找到界面元素的位置。因此，图像数据的质量对GUI Agent的效果至关重要。

为此我们做了大量工作。例如，在提供GUI数据时，我们必须设计大模型能够理解的格式，这也是上下文工程的一部分。GUI操作涉及“动作空间”，包括点击、拖拽等事件，而普通非GUI场景并不存在动作空间的概念。因此，我们需向模型明确这些动作的定义，使其能够正确预测下一步动作。

此外，在实际应用中，模型的准确率永远无法达到100%，尤其在各企业存在大量非标准化、定制化UI的情况下。标准按钮模型可以轻松识别，但企业自定义按钮或特殊组件往往难以识别，因此我们必须通过数据灌入与示例教学帮助模型理解。例如，在处理某些上下滑动组件时，我们需要明确告诉模型这是滑动结构，提供样例以便其学习，与其他AI模型的训练逻辑类似。

同时，在GUI Agent中，我们还会对高频操作场景采用CAG（缓存式LAG）等技术，对热点图形数据进行专门处理，以提升识别与操作的稳定性。总体而言，图像数据的准确性直接决定GUI Agent的执行效果，如果模型无法识别图形或进行纠错，就无法实现高精度操作。在所有类型的Agent中，数据治理始终是大模型工程的前置关键环节。

是“真提效”还是“更疲惫”？

王云峰：老板们都在倡导提效，但有时一线员工反馈是“更累了”：以往自己写代码/写文案，现在要给AI写Prompt，写完还需复核，出错还得担责。在你们的项目上线后，是否遇到过这种“越用越累”的情况？你们认为，真正的“提效”拐点在哪里？

梁筱武：“员工是否感觉不累”，核心在于准确率。我们在构建AI Agent时始终要面对准确率问题。与传统确定性的流程式工程不同，AI是一个不断将不确定性收敛的过程。如果准确率较低，员工会缺乏信心，会觉得使用AI很累。以我们的GUI Agent为例，今年四月份准确率只有约40%，员工很难依赖它。

而到了九月份，我们将准确率提升到90%–95%后，团队对AI的信心显著增强，也真正看到AI在提效上的价值。我们的C端业务目前已完全由AI接管，效率提升非常明显。

第二个感受是工程体系和工具体系对提效的影响。在构建AI工程时，需要配套调试工具、孵化工具、脚手架、Prompt模板库等基础设施，让员工能够直接使用，而不用花时间处理和AI本身无关的技术细节，这与过去流程式架构的工具建设类似。

如果基础设施齐备，整体开发效率会显著提升。此时员工只需要关注AI的核心部分，如上下文工程、推理能力、图像识别质量或语言质量等。一旦同时具备足够高的准确率和完善的工程工具体系，员工自然愿意使用AI，也能在实际业务中真正提升效率。

关于“AI是提升效率还是让人更累”这个问题，我认为两者并存。首先，AI的确显著提升了效率，包括我个人在写材料、做调研、分析、制定方案、项目管理和会议记录等方面，都大量依赖AI工具，效率提升非常明显。

但与此同时，我们也确实变得更累了。一方面，整个行业正处于技术转型期，我们必须持续学习新技术、拓展认知、补充知识，这本身就会带来压力。另一方面，虽然AI能替我们处理许多任务，但我们面对的整体工作量和复杂度也显著提高了。以往做IT开发，需求明确，产出可量化，周期也较为可控。

但在AI时代，我们需要花大量时间验证效果、解释现象、分析问题、不断探索。以前开发一个页面三天就能完成，而现在要把AI的准确率从80%提升到95%，所需时间几乎无法预测。项目在估算成本和投入产出时的难度也比过去高得多，一旦有某个点无法突破，投入就会成倍增加，团队的压力也随之上升。

我认为这种“更累”主要出现于当前阶段。未来，随着我们对AI的认知逐渐清晰，业务流程被重新梳理，各类改造逐步完善，我们会逐渐进入一个更轻松的阶段。但目前我们仍处于最艰难的过渡期，大家都在寻找最优路径、沉淀工具、做好服务治理和数据治理，同时还要应对算力基础与模型本身的持续迭代。

王云峰：我想先引用直播开场提到的一份报告，其中有些数据非常值得讨论。这是MIT主导的一项联合研究，主要评估当前人工智能技术能覆盖美国经济中多少劳动力任务。他们提出了一个概念，叫“Iceberg Index”（冰山指数），意指我们通常看到的只是水面上的少部分，而大部分价值都在水下。

研究结论显示，目前AI技术能力已可以覆盖美国经济中约11.7%的劳动力任务，涉及的薪资规模高达1.2万亿美元。但其中有一个反常识的发现：那些位于“冰山之上”的技术圈层任务，实际上只占约2.2%的劳动力。如果只看到这些数据，可能会得出“AI的冲击主要集中在技术行业”的错误结论。

然而，这项研究构建了1.3万个技能，并与1.3万多个AI工具进行交叉匹配，最终发现：除了显而易见的编程和创意类岗位之外，大量认知型和行政型任务在技术上也已高度可自动化。这些任务并非集中在技术密集行业，而是广泛存在于金融审核、保险理赔审核、物流协调、医疗行政管理、供应链监控等领域。

这些岗位并非技术行业，但却支撑着现代经济的基础。换言之，“冰山之下”的任务规模是“冰山之上”的五倍。从这份报告得出的关键结论是：真正取代岗位的不是AI本身，而是“更会使用AI的人”。

更进一步问，随着AI越来越强， 那些原本做基础工作的人，他们的工作是被AI彻底替代了，还是被迫转型了？ 作为技术管理者，两位老师现在招人的标准变了吗？你们更看重候选人的什么能力？

梁筱武：整体来看，AI确实在这些领域发挥了作用，但我认为岗位不会消失，而是会转变为借助AI完成更高效的工作。例如原来做金融科目核对的人，未来可能会基于AI输出结果进行更深入的分析。

从技术研发的角度看，招聘标准也会有一些变化，但总体而言，软件工程的基础能力、架构能力仍是招聘的核心，不会发生根本性变化。可能会新增一些加分项，例如具备AI工程相关能力、概率思维能力、效果评估能力等。与大模型交互的工程从来无法做到100%准确，因此如何理解概率模型、如何让模型的输出收敛到更高准确率，都会成为重要能力。同时，像基座模型效果评估、上下文工程评估等也都是加分项。

若能快速进行评估、具备工具和方法支撑，自然能提升效率。还有一个当下越来越重要的能力，是从业务场景中识别AI价值的能力。例如金融从业者需要从对账走向数据分析，而对开发工程师来说，以往只需按照PRD完成功能开发，但今天我们的任务更像是一个AI工程：要理解业务场景，找到适用的AI技术，并让工程能够与之匹配。如果能成功识别场景并找到适配技术，那么无论团队效率还是个人效率都会显著提升，这也会让工程师获得很强的成就感。

邹盼湘：我们面向B端，同时配置研发和交互团队，过去几年也经历了多轮阵痛，因此在人员要求上做出了较大的调整。过去从需求、方案设计、开发到测试上线，流程清晰，但现在客户往往不清楚从哪些场景切入、哪些值得做、做完需要怎样的环境以及能达到什么效果，整体预期并不明确。因此，我们将项目的“一号位”从项目经理调整为兼顾项目管理与产品设计的角色。他必须既理解业务、具备产品思维，又要懂战略规划，并掌握一定的AI基础技术。

我们发现很多传统项目经理难以承担AI项目，因为他们的工作逻辑很难转变。面对客户提出的问题，他们往往不知道如何判断需求是否合理，也缺乏对目标、时间和成本的评估意识，容易导致团队内部出现大量沟通与执行层面的内耗。

因此，我们要求项目一号位必须具备将底层AI能力包装成用户可感知、可理解、可使用的产品功能的能力，并能与业务部门沟通、熟悉客户场景和业务流程，从中提出AI需求。同时，他还需理解主流AI技术，特别是RAG和Agent，对其原理、能力边界、适用场景及可达上限有清晰判断，以确保项目能够有序、高质量地交付。

另一个关键岗位是测试工程师。传统测试只需验证功能是否正确、能否跑通、是否有bug，而现在测试必须具备业务理解和产品思维，参与全流程的质量保障。从真实使用场景出发设计端到端测试用例及边缘场景测试，不再局限于单个API的验证。同时，他要站在用户视角评估产品质量与体验，能识别整体产品问题并提出优化建议。

测试人员还需要具备风险意识，识别AI系统在特定业务场景下可能存在的风险，如隐私泄露、决策错误及其他不可控问题。这些风险可能需要通过产品功能完善、架构优化或代码设计调整来解决。此外，测试也必须具备良好的协作与学习能力，能与算法、开发和产品团队就缺陷及质量风险达成共识。

在学习能力方面，我们要求公司全员具备AI能力，包括销售、解决方案、交付和研发线条。公司为各类岗位提供了AI培训路线、学习资料与评估指标。例如，测试人员需学习对抗性攻击、大模型评测基准、Agent评测标准等，以补齐过去无法评价Agent效果的短板。

对于前端岗位，过去只需根据UI完成功能开发，而现在他们需要参与交互界面设计，提出创新的用户体验，包括流式响应、多模态交互、可溯源结果呈现等。在AI时代，许多产品界面将大幅简化，甚至可能只有一个对话框，交互在任务执行过程中实时触发。因此，前端需要思考何时呈现信息、以何种形式呈现、如何处理多任务并行等问题。

王云峰：AI产品的开发与传统开发在范式上有明显差异，思路也完全不同。我们曾经遇到的问题是，如果研发人员缺乏强学习能力或对新事物的接受能力，无法判断AI的优势与局限，而继续沿用传统确定性技术的思路进行设计，往往无法胜任，甚至可能无法通过试用期。

因此，我们非常看重的一点是候选人是否真正愿意使用AI，并且在日常中频繁使用AI、具备一定判断力，能形成真实的体感。只有这样，在产品设计或开发过程中才能把握AI的特性与行为规律。其他岗位也同样如此，广泛使用AI对提升工作效率具有非常显著的作用。

价值与终局——成本核算与未来展望

王云峰：我们实际一点，算算账。当前的Token成本、推理成本依然不低。如果让您给企业老板一个建议：什么样的业务场景，是现在立刻、马上就应该用AI重构的？什么样的场景，建议“再等等”？

邹盼湘：我认为当前的核心痛点主要集中在场景选择与价值衡量。做场景选择时要避免两个极端：一是好高骛远，即在探索阶段就尝试对核心系统进行AI化升级；一旦出现问题，后果难以承受。二是隔靴搔痒，即选择极低频的边缘场景，虽然安全，但无法产生实际业务价值。

在场景选择上，我们采用几个评估原则。首先从业务价值出发，理想场景应具备高频、刚需和明确的付费方。其次从数据就绪度评估数字化程度、知识结构化程度及相关文档沉淀情况。理想状态下，数据已准备充分，具备AI升级改造的基础。

此外，还需关注容错空间，通过引入human-in-the-loop的人机协同模式，将错误率控制在可接受范围内。如果某个场景既无人监管，又属于核心业务，则不宜在早期触碰。

场景确定后，需要进一步评估其价值。我们通常从两方面衡量：一是总拥有成本，包括显性成本（如GPU等硬件投入、Token费用）和隐性成本（如人力运维、合规与风险成本）；二是价值机会，包括效率提升、体验改善和决策优化。效率提升对应降本省人，体验改善可能带来提价或留存，决策优化有助于规避风险。当价值机会减去总拥有成本为正时，从ROI角度看，这个场景就值得投入。

梁筱武：目前还没有一个能适用所有行业的通用方法来判断“AI该在哪个场景落地”。无论是C端、B端、App端还是机器人，各行业国内外都在试验，各类应用场景正处于“遍地开花”的探索阶段。我的建议是采用快速迭代方式，小规模试点、小流量验证，持续大胆尝试。

同时，企业需要具备与大模型类似的“快速反思能力”。在任何项目与产品实践中，如果发现方向不对，要能迅速纠偏并切换到新的场景继续验证。

从当前的实践来看，在“效率提升”这一方向已有大量成功案例。大模型在效率层面的优势非常明显，商业效果则因应用成本和场景不同而存在差异。在企业内部，从简单任务开始试验通常最为稳妥，例如使用数据分析类AI自动生成日报和周报，以替代重复性的文本整理工作，这类改造通常能取得不错的效果。

在更复杂的效果型场景，如Agent的探索方面，各家公司仍在不断试验，目前还很难总结出普适的套路。但我认为，可以大胆尝试，并尽量贴近大模型的思维方式，将自身产品体系与底层模型能力深度融合。当Agent产品与大模型在认知模式和工作方式上实现对齐后，其整体速度和迭代效率将显著提升。

观众：如何精确匹配个人对商品的需求和商品信息？

王云峰：传统搜索中，用户输入query，系统从原始商品信息中进行匹配，再由用户判断结果是否相关。后来出现推荐算法，通过用户行为进行预测，但这也容易形成“信息茧房”，因为系统会不断强化用户过往行为，使其接收越来越同质化的信息。我们认为，如果利用AI对全网数据进行结构化整理，可以打破这种局限。

AI能理解用户行为背后的真实需求。如果用户提出一个意图，我们应充分利用其相关的身份信息去推断更真实的需求。此外，商品信息往往并不完整，因此需要结合大量用户描述、社交媒体内容和公开资料，构建对商品的完整表述，以判断商品适用的场景。用户的购物需求本质上是特定场景与商品适配性的匹配，通过完善商品与场景的描述，才能更好地实现人与商品之间的精准匹配。

但现有数据质量无法完全满足这一需求，因此必须在前期进行充分的数据预处理与治理，只有把数据打好底子，后续的匹配效果才能得到保证。

观众：邹老师，您在给企业做AI应用落地的过程中遇到的最难环节是什么？

邹盼湘：这个问题很难回答，因为从整体架构构建、数据治理到账号权限、安全等模块都不容易。但如果一定要选最难的环节，我认为是服务治理。B端场景不是从零构建新产品，而是要把AI与企业现有业务流程、业务系统和业务数据深度融合。过去我们做IT时，是物理世界与IT世界的融合；现在是AI与IT世界的融合。以我们在南网的智能问诉项目为例，过去制作数据看板和分析流程时，每一步都是人编码定义，而现在需要实时动态构建，因此必须把原有流程知识化。过去系统由人操作，现在要实现人机协同，让系统具备一定的思考能力，需要设计好人与系统共生的方式。

在企业项目中还会遇到系统数量庞大的问题。例如在线公司有十几个业务系统、超过四万个API。如何将这些API转化为模型可调度的插件或MCP服务，并保证它们的性能、管理、注册与监控，都是服务治理中的关键难题。任何一个环节处理不好，都可能导致整体系统混乱。

观众：Agent自主操作手机的模式会不会失控，让设备擅自行动？

梁筱武：如果Agent的准确率和流程控制在可确定范围内，它是不会失控的。但由于Agent天然具有不确定性，不可能做到100%准确。如果准确率是95%，那么剩下5%的不确定场景就需要通过风险前置方式来处理，包括在产品流程和技术实现层面进行防护。例如，在Agent需要进行规划与推理时，一旦前序步骤出现错误，我们应该能够快速终止流程，从源头避免异常扩散。

我们还可以在产品端加入流程控制机制，例如“阀门式”安全措施；在技术端加入可视化链路，甚至引入第三方裁判或监督机制，对关键步骤进行实时中断。通过这些方式，可以有效规避Agent在不确定性场景中的风险。本质上，这是关于如何设计AI产品与技术体系，使那部分不可避免的不确定性得到妥善处理。