一、2026选 AI 客服机器人要先学会判断再谈名单
在2026年，企业选择AI客服机器人已不仅是功能对比，而更需关注两个深层变化：供给端的“同质化”与需求端的“责任上移”。
1.供给端“同质化”加剧
近两年，大模型、RAG、智能体等能力迅速普及，厂商宣传趋于一致：都支持多轮对话、都能接入大模型、都具备知识库问答。这使得采购决策容易陷入“看参数、看演示、看PPT”的表面判断。
2.需求端“风险责任上移”
过去选型重在功能匹配与流程覆盖；如今，面向客户的生成式AI对话系统已成为客服团队的重点试点方向。一旦上线对外服务，企业承担的不再只是“功能是否好用”，更包括客户体验、合规安全、品牌声誉及运营连续性等多重风险。
二、选型失败的常见根源：认知起点偏差
企业选型时若起点有误，即使产品功能强大，最终也难以成功落地。常见误区如下：
误区一：将AI视为“更聪明的FAQ”
如果仅将目标定义为“回答更像人”，容易忽略两大隐患：
- 错答带来的客户体验与合规风险，尤其在涉及价格、政策、隐私等领域。
- 模型被攻击、被诱导输出不当内容的安全风险（如提示注入，已被OWASP列为重点风险类别）。
误区二：将AI视为“一次性交付的软件”
许多企业在规模化阶段遇到的障碍，并非“能否做出”，而是“能否持续稳定运行并持续产生价值”。麦肯锡调研指出，从试点走向规模化仍是普遍难点，高绩效组织更倾向于建立明确的流程来决定“何时必须进行人工校验”。
三、企业真正需承担的三大风险维度
引入大模型能力不是终点，风险可控与运营可持续才是选型的根本约束。企业需系统评估以下三类风险：
1. 客户体验风险
主要表现为错答不可控、口径不一致、承诺失真等。选型时应重点考察：
- 错误回答的可控性：能否引用依据、能否主动拒答、能否在不确定时顺畅转人工。
- 是否具备回答追溯机制，减少因模型“幻觉”带来的隐性风险。
2. 系统与安全风险
包括提示注入、数据泄露、权限越界等新型威胁。需注意：
- 提示注入并不像传统SQL注入那样可被“彻底修复”，现实策略是降低其影响与后果（NCSC观点）。
- 生成式AI相关的数据策略违规正成为普遍问题。根据Netskope 2026报告，企业平均每月出现数百起此类违规，“个人账号/影子AI”的使用仍占较高比例。
3. 落地交付与运营风险
落地交付与运营风险 即上线后无人持续运营、效果指标不可追踪、价值归因困难等问题。 参照国内信通院及人工智能标准化总体组发布的行业规范，企业需建立覆盖模型全生命周期的运营与治理机制（LLMOps），避免陷入“重建设、轻运营”的误区，确保AI应用持续产生业务价值。
四、市场全景：AI客服机器人厂商的四大路线
当前AI客服机器人市场呈现多元化发展格局，企业可根据自身需求、技术基础与资源禀赋，在不同类型厂商间进行选择。本节将厂商划分为四条主要路线，并对其代表性产品进行客观分析，旨在为企业选型提供清晰的参照系。
（一）客服系统演进型厂商
这类厂商通常从传统客服系统、工单系统或联络中心软件演化而来，在客服业务流程闭环、系统整合与运营管理方面积累较深，AI能力作为增强模块嵌入既有体系。
1. 合力亿捷
能力基因与定位
合力亿捷成立于 2002 年，拥有深厚的电信运营商行业背景和AI创新能力。其发展路径从最早的呼叫中心软件，进化到云客服，再到如今的“AI Agent（数字员工）”平台。这种基因决定了其产品在通信底层稳定性、高并发处理以及电话/在线全渠道融合方面具有天然优势，是典型的“通信+AI”双轮驱动型厂商。
AI能力侧重点
- 流程嵌入式AI：提供大模型能力平台（MPaaS），支持通过编排组合模型、企业知识与工具能力，以满足不同任务场景，在语音、文本等多模态场景中，AI客服机器人支持多轮对话，并实现95%以上的准确率。
- 提供可视化的 Agent 编排平台，支持通过“拖拉拽”的方式构建业务流程。其 AI 能力涵盖了自研的毫秒级 ASR（语音识别） 和 TTS（语音合成），支持方言识别、情绪识别和随时打断，语音交互体验高度拟人化。
业务闭环与落地考量
- AI原生深度集成于全系产品：非外挂式AI能力贯穿坐席辅助、智能路由、质检与工单流转全流程，实现从接待到办结的闭环。
- 全渠道统一： 一套系统即可打通电话、微信（公众号/小程序/企微/群）、APP、官网、视频客服乃至 WhatsApp 等海外渠道，保证数据与服务体验的一致性。
- 交付方法论： 针对大模型落地难的问题，合力亿捷独创“调研-设计-编排-试运行-运营”的五步法实施标准，并配备“销售+设计工程师+运营工程师”的交付铁三角，提供从冷启动到持续调优的陪跑服务
适配建议
- 更适合：中大型企业及成长型企业（座席规模10–10,000+），特别适合景区文旅、医院、政务、汽车、零售电商、生活服务、制造等“服务即业务”的行业。
- 需谨慎：仅需轻量级网页咨询机器人，且不愿改变现有服务流程的团队。
2. Genesys｜Genesys Cloud CX
能力基因与定位
Genesys Cloud CX 是云原生联络中心平台，强调端到端客户体验编排，并提供叠加式的AI能力（如Copilot）。
AI能力侧重点
- 坐席与主管辅助：Copilot功能专注于实时辅助，如下一步最佳行动建议、会话总结等，旨在提升坐席效率与决策质量。
- 可度量的AI使用：采用“AI Experience tokens”的计费模式，使AI使用成本相对透明和可控。
业务闭环与落地考量
- 优势：在联络中心全链路管理与坐席人机协作方面能力突出。
- 选型关键点：业务办理闭环的实现，依赖于企业自身业务系统的接口对接与治理水平。需验证工具调用失败时的降级与回退机制。
适配建议
- 更适合：全渠道联络中心体量较大、希望建立统一智能化运营体系、且具备相应流程治理能力的中大型企业。
- 需谨慎：仅寻求轻量级机器人、内部缺乏数据与运营治理机制的团队。
3. Zendesk
能力基因与定位
Zendesk以服务管理与工单系统见长，其AI路线是在现有服务解决方案上叠加AI Agents（自动化处理）和Agent Copilot（坐席辅助）。
AI能力侧重点
- 全渠道自动化处理：AI Agents旨在承接全渠道客户交互，实现规模化自动化。
- 坐席效能提升：Agent Copilot 提供摘要、建议回复等辅助功能。
业务闭环与落地考量
- 优势：在服务流程（工单分类、流转、处理、知识沉淀）的闭环运营上具有优势。
- 选型关键点：若涉及外部业务系统操作，需重点评估集成深度与稳定性，并确保从自助到工单到人工的流程可统一治理与复盘。
适配建议
- 更适合：服务运营体系成熟、工单流程与多渠道管理需求强、希望利用AI提升效率并逐步扩展自动化范围的企业。
- 需谨慎：以“复杂业务办理自动闭环”为核心目标，但接口治理与流程标准化尚未准备好的企业。
（二）云大厂与底座型厂商
这类厂商通常以云计算和大模型基础设施为底座，提供平台级AI能力，并向下游客服场景输出解决方案，适合对算力、平台生态及统一治理有较强需求的企业。
1. 百度智能云｜客悦（Keyue/客悦ONE）
能力基因与定位
客悦依托百度智能云与文心大模型构建，定位为云与大模型底座驱动的智能客服产品线。其产品谱系覆盖智能客服机器人、外呼、洞察与通信平台，倾向于提供“平台能力+行业解决方案”的一体化服务。
AI能力侧重点
- 对话理解与个性化：强调利用大模型提升对话质量与回复风格的可配置性。
- 知识增强与可控性：重视通过检索增强生成（RAG）等技术，将回答与企业知识库绑定，以降低模型“幻觉”风险。
业务闭环与落地考量
- 优势：适合设计“从咨询到流程动作”的场景，旨在通过智能交互简化业务流程。
- 选型关键点：企业需重点关注业务接口的对接深度、权限与字段校验的完备性，以及供应商是否能提供端到端的流程编排与异常兜底方案，而非仅提供对话能力。
适配建议
- 更适合：已具备一定数字化基础，希望将客服、外呼触达与运营洞察联动闭环，且对云生态与大模型底座能力有依赖的企业。
- 需谨慎：内部缺乏持续运营与知识维护机制，或业务高度复杂但接口治理尚不成熟的团队。
2. 华为｜AICC（智能联络中心）
能力基因与定位
华为AICC定位于一体化智能联络中心，依托其长期的通讯技术与全球客户服务经验，强调全媒体（语音、视频、消息等）渠道接入与统一工作台能力。
AI能力侧重点
- 运营侧提效：AI能力重点落地于智能坐席辅助（摘要、话术推荐）、智能质检、智能培训与知识自动化构建，旨在提升客服团队运营效率与服务质量。
业务闭环与落地考量
- 优势：在联络中心端到端链路（接入、路由、工作台、运营）上具有完整性与稳定性。
- 选型关键点：若涉及业务办理自动化，需重点验证其与企业后端系统（如CRM、工单）的集成深度与流程编排能力，不应仅关注联络中心功能本身。
适配建议
- 更适合：联络中心体量较大、全渠道（尤其语音视频）需求明显、且重视坐席效率与运营治理的企业。
- 需谨慎：仅需轻量级在线咨询机器人，或业务办理深度依赖复杂系统集成但内部治理薄弱的团队。
3. 竹间智能（Emotibot）
能力基因与定位
竹间智能更偏向对话式AI平台公司，以情感计算与语义理解为核心能力，产品矩阵覆盖对话机器人、坐席助手、实时质检、知识库等，侧重通过AI提升交互体验与客服团队运营效能。
AI能力侧重点
- 对话策略工程化：在对话管理、出话策略等层面提供较细颗粒度的可配置能力。
- 人机协同运营：提供实时坐席辅助、质检、培训等工具，旨在将AI深度嵌入客服工作流。
业务闭环与落地考量
- 优势：在提升对话质量与人机协作效率方面具有特色，适合优化现有客服体系。
- 选型关键点：实现“能办事”的闭环，高度依赖于与企业业务系统的对接深度与工具调用的可控性，需在概念验证阶段重点验证。
适配建议
- 更适合：客服体系较为成熟，希望重点强化对话质量、人机协作与运营智能化（质检、培训）的企业。
- 需谨慎：追求高度自动化的业务办理闭环，但自身接口与权限治理准备不足的团队。
（三）垂直场景型厂商
这类厂商专注于特定行业或业务场景（如电商、跨境、私域），产品通常上手快、场景贴合度高，但在平台化能力和复杂系统集成上可能有一定局限。
1. 瓴羊｜Quick Service（智能客服）
能力基因与定位
瓴羊Quick Service定位为全触点一站式客服系统，整合语音、IM、工单、AI与数据能力，侧重快速搭建可运营的客服体系，覆盖消费者、客服与管理者的全链路角色。
AI能力侧重点
- 组合式AI能力：强调AI问答、AI辅助与AI知识库能力的组合应用，并与大模型技术结合落地。
业务闭环与落地考量
- 优势：擅长“咨询-协同-工单”的客服内部闭环，适合需要快速建立一体化客服运营能力的企业。
- 选型关键点：需明确机器人能否触发业务动作、工单流程是否可配置可审计，以及与企业现有CRM/订单系统的对接稳定性。
适配建议
- 更适合：希望快速落地全触点客服体系，并需要“机器人+人工+工单+运营工具”组合能力的企业。
- 需谨慎：追求深度跨系统自动办理，但自身接口与权限治理不成熟的团队。
2. SaleSmartly
能力基因与定位
SaleSmartly更偏向为电商/跨境场景设计的全渠道对话运营与自动化工具，强调在多平台（如Shopify）上实现会话集中管理、自动化分流与团队协作。
AI能力侧重点
- 意图识别与工作流自动化：通过AI识别意图并触发自动化工作流，以承接高频对话，减少人工投入。
业务闭环与落地考量
- 优势：在电商场景的轻量闭环（咨询、引导、信息收集、分派）上贴近业务，部署灵活。
- 选型关键点：需验证人机切换规则的明确性、与现有售后/工单系统的对接能力，以及运营数据的可分析性。
适配建议
- 更适合：跨境或电商团队，渠道分散，希望快速搭建“全渠道承接+自动化分流+团队协作”体系。
- 需谨慎：集团型或强合规场景，以及依赖复杂业务系统写入实现深度闭环的企业。
3. 云起未来｜客服GPT / 云猫AI
能力基因与定位
云起未来产品定位为私域/多平台运营场景的轻量化智能客服助手，强调多平台账号统一管理、拟人化回复与快速部署上手。
AI能力侧重点
- 大模型接入与体验优化：支持接入主流大模型，并提供情绪识别、话术润色等功能，旨在提升沟通体验。
业务闭环与落地考量
- 优势：在多平台对话承接与统一运营界面方面具有便利性。
- 选型关键点：若需实现“能办事”的深度闭环，必须验证其与业务系统/工单系统的集成能力、权限校验与审计留痕机制是否完备。
适配建议
- 更适合：私域或电商客服团队，需要快速获得多平台、7×24小时自动回复能力。
- 需谨慎：以复杂业务办理自动闭环为核心目标，且对系统集成与审计治理要求高的企业。
（四）平台/工具型厂商
这类厂商提供构建AI Agent或智能对话应用的开发平台与工具链，高度灵活，但要求企业自身具备较强的产品化、集成与运营治理能力。
1. HiAgent（火山引擎）
能力基因与定位
HiAgent定位为企业级AI Agent与LLM开发运维平台，提供从构建、部署到监控优化的全生命周期工具链，类似AI领域的“DevOps平台”。
AI能力侧重点
- 工程化搭建与运维：核心价值在于提供组件、SDK和示例，提升AI原生应用的开发效率与可运维性（可观测、可优化）。
业务闭环与落地考量
- 优势：适合企业将AI Agent能力平台化沉淀，并在多场景复用。
- 选型关键点：平台提供工具调用与编排能力，但业务闭环完全依赖企业自身对系统接口、权限、审计链路的设计与实施。需明确效果责任与SLA归属。
适配建议
- 更适合：拥有内部产品/研发团队，希望自建AI Agent平台能力并在多业务复用的中大型企业。
- 需谨慎：希望“开箱即用”或缺乏数据/权限治理能力，却计划直接上线面向客户的自动执行型Agent的团队。
2. Coze（扣子）
能力基因与定位
Coze是通用型AI Agent应用开发与生产力平台，强调可视化、低代码的快速构建能力，同时为开发者提供工程化形态（Coze Studio）。
AI能力侧重点
- 工作流与插件生态：通过工作流编排和插件扩展，支持用户构建具备工具调用能力的智能体。
业务闭环与落地考量
- 优势：在降低Agent构建门槛方面表现突出，适合快速原型验证。
- 选型关键点：其本质是构建层平台，企业需自行补齐客服全链路所需的渠道接入、坐席工作台、工单系统等，并承担所有集成与治理责任。
适配建议
- 更适合：有较强技术或运营团队，希望自主搭建和迭代AI Agent，并应用于多个内部或对外场景的企业。
- 需谨慎：缺乏配套客服系统底座与持续运营能力，仅采购该平台用于构建对外客服机器人的团队。
3. Yellow ai
能力基因与定位
Yellow ai定位为企业级对话式自动化平台，专注于客户体验（CX）与员工体验（EX）自动化，提供统一的AI Agents构建、测试与优化平台。
AI能力侧重点
- 多模型与复杂目标执行：利用多种LLM驱动AI Agents完成复杂目标，并强调全渠道（包括语音）自动化能力。
- 广泛的预集成：提供超过150个预构建的企业系统集成连接器。
业务闭环与落地考量
- 优势：在企业系统集成广度与全渠道支持上具备优势，适合需要连接多系统的自动化场景。
- 选型关键点：需从“集成数量”转向“闭环可靠性”验证，重点关注权限校验、失败兜底、跨渠道一致性及审计追溯能力。
适配建议
- 更适合：多渠道、多系统、希望实现较高比例自动化、并具备相应治理能力的中大型企业。
- 需谨慎：仅需基础FAQ或在线咨询，内部流程与数据治理能力较弱的团队。
四、选型决策的实用路径：先排除，再对齐，后验证
为避免陷入功能对比的陷阱，建议采用以下三步法：
第一步：先排除
识别不适合企业当前阶段的产品形态与技术路线，避免“买贵、买重、买错”。
第二步：再对齐
将选型目标从“追求更智能”调整为“在风险可控的前提下，提升效率与体验”。
第三步：后验证
通过可复现的概念验证（PoC）或试点，检验关键能力，而非被厂商演示效果牵引。下文将提供各能力维度的验证重点。
六、技术能力演进的四个关键变化
企业需理解并跟进以下四个“能力换挡”，它们决定了AI客服的实质价值。
变化一：从“规则命中”到“大模型理解”——准确率不再是唯一指标
- 核心变化：能力从简单的FAQ匹配，扩展到意图识别、多轮上下文理解，并通过检索增强生成（RAG）将回答尽可能绑定事实依据。
- 选型关注点：重点考察错答的可控性。例如，置信度低时能否明确拒答或转人工；能否输出引用来源，形成可追溯的证据链。
- 验证方法：使用真实历史问题集进行盲测，区分“回答是否正确”与“回答是否可追溯”；重点抽查高风险意图（如价格、隐私、投诉等）的应答表现。
变化二：从“只会说”到“能办事”——机器人是否能参与业务流程
- 核心变化：从对话系统升级为“可调用工具的执行者”，能够查询订单、创建工单、修改状态、触发业务流程等。
- 选型关注点：这决定了其是“咨询工具”还是“服务协作者”。但同时带来更高的治理要求，必须严格管控权限与审计，防范提示注入导致的越权操作。
- 验证方法：检查权限模型（最小权限原则、分级授权）；确认工具调用的可审计性（记录谁触发、用何数据、执行何操作）；验证失败兜底机制（如接口失败时能否降级，而非编造答案）。
变化三：从“演示效果”到“规模稳定性”——并发、监控与兜底成为分水岭
- 核心变化：企业开始将生成式AI能力从试点推向更大范围上线，规模化难点凸显于稳定性、成本与运营流程。
- 选型关注点：系统需能稳定承载高峰流量，并在异常时优雅降级。安全与数据风险在规模化后会被放大。
- 验证方法：要求厂商提供压测报告与容量规划；考察全链路监控能力（从渠道接入到结果回写）；明确各项兜底策略（如超时、模型不可用、检索为空时的处理标准）。
变化四：从“一次性上线”到“长期运营”——持续优化机制决定长期投资回报
- 核心变化：客服机器人不再是“买完即用”的软件模块，而是一套需持续治理的数据与运营系统。
- 选型关注点：必须将“上线”拆分为“上线+运营”。缺乏持续评估与优化机制，效果将难以维持或改善。
- 验证方法：考察厂商是否提供完整的运营指标体系（如自动解决率、错答率、满意度等）；是否支持回归测试流程；是否具备从人工处理结果反哺知识库的闭环机制。
七、按企业成熟度对号入座：选路线优于选品牌
同一项AI能力，在不同组织内可能产生截然不同的结果。根据自身成熟度选择技术路线，比单纯对比品牌更为可靠。
1. 起步期企业（数字化基础弱、流程分散）
- 核心目标：承接高频、标准化咨询，减轻人工压力，优先追求“答得一致可控”，而非“全自动闭环”。
- 推荐路线：优先考察垂直场景型产品或现有客服系统的演进型方案，以上手快、能快速跑通为首要标准。
- 常见陷阱：用演示效果替代真实验证；忽视上线后的知识维护与效果衰减；因数据边界不清导致“影子AI”风险。
2. 成长型企业（渠道多、业务复杂、跨部门协同需求显性）
- 核心目标：不仅“回答”，还要“触发动作”（如建工单、查状态），缩短服务链路，并建立可复用、可追踪的运营体系。
- 推荐路线：优先考虑客服系统演进型方案，因其在接待、转人工、工单、质检等环节的整合度更高。云大厂/底座型方案可作为备选，但需仔细评估落地复杂度。
- 常见陷阱：将“能调用接口”等同于“能安全办成事”，忽视权限模型与审计链路；人机协作边界模糊，导致效率与风险失控。
3. 集团/复杂组织（多系统、强合规、强治理）
- 核心目标：将AI客服建设为“组织级能力”，实现统一口径、统一审计与统一风控，并支持多业务单元复用。
- 推荐路线：常采用“云大厂/底座型 + 客服系统演进型”的组合评估思路。底座提供平台能力与统一治理，业务系统保障端到端的服务交付与运营。
- 常见陷阱：将安全合规简化为供应商资质审查，忽视自身数据分级、访问控制等治理措施的落地；低估提示注入等新型风险的长期性与不可根除性。
八、六维选型评估法：将“好不好”转化为可验证指标
为避免空泛讨论，建议从以下六个维度进行结构化评估，每个维度聚焦于“如何判断”以及“需要何种证据”。
维度一：业务覆盖深度——是“答得像”，还是“办得成”
- 判断要点：是否支持从对话到业务动作（查、写、改、建单、触发流程）；能否对关键意图设置执行前提（如身份、权限校验）。
- 索取证据：工具调用的完整链路说明（含失败处理逻辑）；关键业务意图的自动化边界定义。
- PoC验证：测试正常流程闭环、异常情况降级、敏感操作复核三类用例。
维度二：人机协作与兜底机制——“转人工”是主动的风险控制
- 判断要点：是否具备基于置信度、敏感意图等规则的明确升级机制；转人工时能否无缝传递完整上下文。
- 索取证据：转人工策略的配置灵活性与审计复盘能力。
- 风险提示：需建立工程化的兜底方案以应对提示注入、不安全输出等OWASP重点列出的风险。
维度三：系统与数据整合能力——决定真实投资回报率
- 判断要点：能否与企业现有身份认证、权限、审计体系集成；是否遵循“数据最小化”原则，避免敏感信息不必要的暴露。
- 索取证据：标准化集成方式清单与数据流向说明（包括脱敏、留存与删除策略）。
- PoC验证：完整跑通一条真实业务链路，并确保全流程可追踪、可审计。
维度四：稳定性与安全合规——规模化后风险呈指数级放大
- 判断要点：高峰并发、容灾降级策略是否完备；安全策略是否覆盖提示注入、越权执行等LLM新型风险。
- 索取证据：压测报告或容量模型；详细的安全与审计控制措施说明；其风险治理框架是否能与NIST AI RMF等权威框架对齐。
- 重要认知：对提示注入等风险应有现实预期，重点在于降低影响而非追求彻底消除。
维度五：运营与迭代机制——上线只是开始
- 判断要点：是否具备可持续的运营闭环，包括知识更新、效果评估、回归测试、版本管理等。
- 关键指标：应同时关注结果指标（如自动解决率、满意度）与过程指标（如转人工率、高风险错答占比）。
- 框架对齐：可参考NIST AI RMF或新加坡PDPC的AI治理框架，确保运营机制符合持续治理的理念。
维度六：交付与服务能力——谁为效果负责
- 判断要点：厂商是否提供清晰的交付边界、角色分工与验收标准；是否具备从PoC到试点再到规模化推广的成熟方法论。
- 索取证据：交付方法论文档、各阶段验收清单及风险回滚方案。
- 核心提醒：规模化成功的难点往往在于工作流程与组织协作的重构，供应商的“运营陪跑”能力至关重要。
九、落地前必须明确的五个关键问题
在最终决定前，团队内部应对以下五个问题达成共识，这是项目成功的基石。
问题一：自动化的边界在哪里？哪些必须由人工负责？
- 建议做法：将客服意图按风险分级（如低风险可自动、中风险需复核、高风险强制转人工），并将此规则固化到流程中。
问题二：知识、数据与流程由谁准备与维护？
- 落地关键：必须明确知识更新的责任主体、频率与审核流程。若涉及业务办理，需清晰定义接口、规则与异常处理的责任归属，避免出现“系统问题”与“数据问题”相互推诿的局面。
问题三：业务部门是否深度参与？还是完全外包给IT或供应商？
- 必要条件：客服运营、质检等业务团队必须深度参与，负责定义服务口径、制定兜底策略、设置核心指标。因为客服机器人对外输出的是“企业承诺”，而不仅是技术功能。
问题四：试点应该如何设计，才能避免成为“样板间”？
- 设计原则：试点范围需兼顾真实性与可控性。应提前定义清晰的扩面门槛（需达到哪些指标）与回滚红线（出现何种问题需中止）。
问题五：是否设计了退出与回滚机制？
- 必须内容：在方案中明确故障/风险的触发条件（如高风险错答频发、接口异常率超标）以及对应的一键降级策略（如从自动执行降级为仅建议或仅转人工）。这是系统韧性的重要体现，也是应对难以根除的新型风险的务实策略。
