对话式AI平台怎么选？2026年7款工具的价格、转人工与权限对比

选择对话式AI平台，先看智能体上线后由谁负责：成熟的联络中心适合从 Cognigy 开始评估；自己掌握代码的团队可以考虑 Rasa；云工程团队则可以看 Google Conversational Agents。这7款平台都必须回答同一个具体问题：智能体需要停止操作、交给人工接手时，究竟会发生什么？

本文的价格、计费口径和产品能力，均于2026年10月27日依据各厂商当时的在线页面核对。 本文比较的是公开功能和落地要求，并非实际运行中的可靠性测试。推荐对象是用于构建客户服务智能体的AI聊天机器人平台，也会说明企业自身需要承担哪些工作。

工程资源有限的小型客服团队，如果需要共同设计对话流程，可以先看 Voiceflow；如果以文字聊天为主，希望起步价格公开透明，可以先看 Botpress。以 Microsoft 为核心技术环境的企业，值得优先评估 Microsoft Copilot Studio。如果项目同时涉及客户服务自动化、人工坐席辅助和服务质量管理，Kore.ai 则是企业级备选。

对话式AI平台速览：适用团队与起步价格

下表的起步价格对应不同的计费单位。一次请求、一个 Copilot Credit 和一次会话不能等同；免费许可证也不代表运行智能体所需的全部服务都免费。

表中 Google 的价格来自 Conversational Agents Flows/Playbooks 价目表。其原产品介绍网址目前指向 Customer Experience Agent Studio，后者另有产品页和定价页。不能把一个产品的公开价格套到另一个产品的实施方案上。

什么是对话式AI平台？

对话式AI平台是一类软件，用于设计、部署和运营面向客户的对话系统，让系统能够回答问题、执行业务流程，并调用已连接的系统。平台提供智能体的运行环境；知识、权限、业务规则，以及转人工的去向，需要企业自行配置。

实用的平台会把理解和生成语言的大语言模型（LLM），与必须按规定顺序执行的引导式流程结合起来。客户修改地址、提出账单异议或查询账户信息时，这些流程尤其重要。自然对话帮助客户说明需求，明确的逻辑则决定所请求的操作是否获准执行。

以订单查询为例。智能体需要经过认可的配送信息、客户身份识别方式、订单系统连接、允许修改哪些内容的规则，以及订单需要例外处理时联系人工的通道。回答流畅，并不意味着整个服务流程已经完成。

因此，选型清单不能只看聊天窗口：

• 对话设计： 既有 LLM 指令，也有行为可预期的流程、条件和兜底回复。
• 渠道： 覆盖网站聊天、消息和语音，并在各渠道分别验证所需功能。
• 操作与知识： 以适当权限连接经过认可的文档和业务系统。
• 转人工： 能真正接入有人值守的客服系统，并传递相关上下文。
• 分析与评估： 能查明对话在哪里失败、执行了哪些操作，以及发布后发生了什么变化。
• 防护控制： 管理信息访问、工具使用、内容和发布，同时在提示词之外落实业务规则。

如果需要开箱即用的助手，可参阅最佳AI聊天机器人对比。如果需要在现有客服工单系统内工作的成品智能体，可参阅AI客服工具对比。本文讨论的是如何构建并维护自己的客户对话系统。

对话式AI与生成式AI有什么区别？

对话式AI描述的是交互方式：系统在对话中理解信息并作出回应。生成式AI描述的是许多此类系统使用的一项能力：生成语言或其他内容。对话智能体可以同时使用生成式回复、固定回复和确定性的业务逻辑。

对客服负责人来说，这个区别要落到操作上。让模型理解“包裹送到了我以前住的房子”，再由经过身份验证的工作流判断是否还可以修改地址。模型能理解客户的意思，不代表它就有权修改对话中提到的任何账户。

三类平台，分别由谁承担落地工作？

企业级联络中心平台围绕服务运营组织智能体构建能力。Cognigy 和 Kore.ai 属于这一类。若路由分配、电话系统、人工团队和运营监督是采购重点，就值得评估。联络中心指处理客户来电和消息的组织及软件系统；AI平台可能与它对接，而非将它替代。

开发框架与托管式构建工具把更多设计权交给团队。Rasa 是偏代码的框架选择；Voiceflow 和 Botpress 则是这一类中的托管式可视化工具。它们在基础设施控制权、可视化编辑和定制集成工作之间作出不同取舍。

云厂商构建工具适合已经具备云服务运维能力的企业。本文选入 Google Conversational Agents 和 Microsoft Copilot Studio。企业现有的身份体系、集成方式和管理机制，往往比对话编辑器的细微差别更能影响选择。

企业级对话式AI平台，“企业级”体现在哪里？

真正有用的判断标准，是能否为整条客户服务流程明确责任人。变更由谁审批、集成由谁维护、转人工队列由谁值守、故障由谁排查，都要有人负责。“企业级”的产品标签不会自动把这些工作分配好。

跨国客服团队需要问清：谁能发布更新后的退款政策，如何选择地区队列，接收会话的平台不可用时怎么办。小公司也要回答这些问题，只是更轻量的构建工具可能已经够用。相比单看员工数量，组织复杂程度更能指导选型。

本文如何筛选平台

本文依据公开资料，重点考察平台能否构建结合 LLM 与流程的智能体、将对话交给人工、限制操作、运行所需渠道，以及让买方理解计费单位。对比时核查了各平台自身的定价、产品或文档页面。

本文不把厂商的自动化承接率当成你所在企业未来表现的预测。所谓承接，是指会话始终由自动化系统处理，并不能证明客户的问题已经解决。敏感请求能顺利交给人工，可能才是正确结果。

本文最关键的对比维度是转人工由谁负责实现。Cognigy 文档列出连接器和转接节点；Google 文档说明需要集成层处理的信号；Rasa 文档提供需要自行实现的模式；Voiceflow 区分实时人工回复连接与创建工单；Botpress 文档说明新工作区的转接目的地发生了变化。这些细节决定了实际工作量，远比“支持转人工”这个勾选项具体。

哪些对话式AI厂商进入了候选名单？

这七家厂商覆盖企业服务平台、开发者自主掌控和云端构建三种路线，未将个人助手、视频数字人或成品客服工单智能体混入名单。排序先列出三类平台中最值得优先考虑的选项，再列出适合特定运营方式的替代方案。

下文的适用性判断属于编辑建议。公开的集成支持信息可以帮助平台进入候选名单；完整服务流程是否适合你的客户，仍需在实际使用的渠道中试点验证。

七款平台逐一对比

1. Cognigy：适合已有成熟联络中心的团队

Cognigy，品牌名称为 NiCE Cognigy，是围绕现有联络中心构建客户服务智能体的企业级平台。如果客服组织最棘手的工作是协调语音、文字聊天、已连接系统和转人工流程，它是本文的优先选择。公开资料显示，其平台结合了 LLM 推理、确定性步骤、评估、运营监督和对话分析。采购前提也很明确：服务运营需要有足够的规模与复杂度，才能用上这套广泛能力。

适合谁： 有联络中心负责人和实施团队的成熟客服组织。
突出特点： 将智能体构建、转人工和持续服务运营连接起来。
价格： 需询价；当前平台页面未核实到具体的公开标价。
免费试用： 提供演示；是否可试用及具体条款需向厂商确认。

转人工如何实现？

Cognigy 文档中的 Handover Providers 用于连接智能体与兼容的联络中心。流程内通过 Handover to Human Agent 节点发起转人工，需要同时具备适当的连接器和支持转接的端点，也就是实际的渠道连接。支持的端点列表包括 Voice Gateway 和 Webchat。文档还提供检查人工可用状态、查看转接状态和结束转接的节点。Cognigy 转人工文档

航空公司客服团队值得看的演示，是受行程变动影响的预订能否带着已有乘客上下文，进入正确且有人值守的队列。让实施方展示接单坐席看到的界面，再把队列设为不可用。只看正常情况下的成功转接，不如验证失败时能否清楚说明情况并恢复服务。

Cognigy 自有的 Live Agent 产品为数字渠道对话提供人工工作台，包含客户上下文和运营指标。它与“把AI接入现有联络中心”应分别界定采购范围。产品家族中有人工工作台，不代表报价已经包含相应组件。Cognigy Live Agent

如何限制智能体的操作权限？

Cognigy 介绍了具有明确参数和执行条件的工具，以及在 LLM 主导交互与结构化流程之间切换的能力。其智能体平台还列有内容审核和防越狱过滤器。这些控制应分层使用：内容过滤管模型说什么，执行条件管操作是否允许发生。Cognigy 智能体控制能力

仍以受影响的预订为例，模型可以理解客户偏好，规则则应在改票前检查票价条件是否允许。验收时，应尝试用具有说服性的表述诱导系统进行被禁止的修改。预期结果是拒绝操作或转交人工，并留下能看懂的原因记录。

选型结论： 如果保留现有联络中心的运营方式，比找到最轻量的构建工具更重要，可以选择 Cognigy。若只是范围有限的网站常见问题项目，而且无人负责实施或服务运营，就不适合选它。

从一次转人工开始评估

以下是依据 Cognigy 文档所述控制能力提出的试点方案，并非本文已经执行的测试。

1. 1

   配置接收会话的服务

   在 Deploy > Handover Providers 中配置联络中心连接。设计后续流程前，先确认所选端点支持转人工。

2. 2

   明确转人工触发点

   在测试流程中添加 Handover to Human Agent 节点。先以客户明确要求人工服务作为触发条件，便于反复复现转接过程。

3. 3

   测试可用状态与转接状态

   使用文档中的可用状态和转接状态控制，区分会话仍在排队，还是已被人工接收。明确无人接单时客户会看到什么。

4. 4

   验证人工接手后的对话

   让同事接收转来的会话，并从客服系统回复。检查上下文传递、客户后续回复和结束行为。扩大试点前，再在接收服务不可用的情况下重复测试。

2. Rasa：适合自己掌握代码的团队

如果对话行为本身就是产品的一部分，而且团队希望明确控制实现方式，Rasa 是面向开发者的选择。它的 CALM 方法，全称 Conversational AI with Language Models，将语言理解与结构化业务流程分开。对于拥有后端工程师、业务规则又远比“根据这些文档回答”更细的产品团队，这很有吸引力。但同样因为需要自行负责，它并不是缺少工程支持的客服经理可以采用的捷径。

适合谁： 能维护集成、部署和对话逻辑的技术型产品团队。
突出特点： CALM 将模型对语言的理解，与实际执行任务的流程分离。
价格： Free Developer Edition 允许每家公司使用一个机器人，每月最多1,000次外部会话；Enterprise 需询价。
免费试用： 有免费许可证，在限额内可用于本地或生产环境。

这个框架提供了什么？

在 CALM 中，LLM 理解消息并生成命令；对话管理器据此推进流程、调用后端集成，或处理话题变化。回复默认采用模板，也可启用改写组件。这样的分工，让开发者能够直接、明确地定义业务步骤。Rasa CALM 文档

设想一家订阅制企业处理配送变更：客户改地址改到一半，可能先问送达日期，再回到原来的请求。设计时既要支持这种灵活对话，也要确保实际修改账户时，仍执行产品其他环节使用的同一套检查。不能因为回复更自由，就悄悄跳过验证。

Rasa 当前文档区分了 Rasa Pro 和 Studio，以及较新的 Mantle 编排器与处于早期访问阶段的智能体构建界面。本文推荐特指文档所述的 Pro/CALM 路线。应询问实施方案采用哪个运行时和界面，不能把 Rasa 名下的全部能力视为同一个版本或同一套授权权益。Rasa 文档范围

转人工与操作限制如何实现？

Rasa 默认的转人工行为，只是告知用户助手无法提供帮助。要真正转接，需要覆盖 pattern_human_handoff 并实现自定义动作。这个区别很大：框架提供对话模式，应用负责把它接入实际接收服务。Rasa 转人工模式

实现时应传递客户身份与相关对话历史、暂停自动回复，并在客服系统拒绝接收时恢复处理。应为这项集成指定工程负责人。仅仅证明“流程里有转人工”，不足以通过验收。

Rasa 还支持 flow guards，即控制流程能否启动的条件。不过，文档列出了通过链接、调用和自然语言理解（NLU）触发流程时的例外情况。应把这些条件视为对话层控制，并在后端动作中再次检查授权。涉及账户信息时，无论对话通过哪条路径到达，服务器都应验证访问权限。Rasa flow guards 的例外情况

哪些工作仍需自己承担？

Rasa 定价页列出自行管理和托管服务两种部署选项，并说明 AudioCodes 语音连接器需要另行购买。因此，部署、模型用量和电话服务应与许可证分开核算。免费版适合用来验证架构，但不意味着运行依赖全部免费。

选型结论： 如果开发团队愿意把客户工作流当作需要持续维护的软件来负责，可以选 Rasa。如果更迫切的需求是让客服运营以较少的基础设施工作上线并调整一个规模有限的智能体，托管式构建工具更合适。

3. Google Conversational Agents：适合云工程团队

Google Conversational Agents 是云端构建工具，将确定性的 Flows（也称 Dialogflow CX）与生成式 Playbooks 结合起来。如果开发者能够负责面向客户的应用，并希望把引导式业务流程与语言模型对话一起使用，就适合考虑它。尤其当团队希望自行决定哪些环节使用生成内容、哪些环节执行明确步骤时，这个平台很有用。关键限制在于：智能体引擎不会自动变成完整的人工客服系统。

适合谁： 构建定制客户文字与语音服务流程的云工程团队。
突出特点： Flows 和 Playbooks 在对话中提供不同形式的控制。
价格： Flows 文字聊天每次请求 $0.007；Playbooks 文字聊天每次请求 $0.012；Flows 语音每音频秒 $0.001 起。Playbooks 和混合使用另有计费规则。
免费试用： 提供面向新用户的 Flows 和 Playbooks 额度。

先分清产品范围

当前产品介绍入口指向 Gemini Enterprise for Customer Experience 旗下的 CX Agent Studio；Flows/Playbooks 定价页仍是单独发布的价目表。本节评估的是文档所述的 Conversational Agents 系统，不用它的单次请求价格估算 CX Agent Studio。当前 CX Agent Studio 页面

采购讨论中，这个区别很重要。应要求厂商或实施方在方案中写明控制台、运行时和计费项。只写“Google 对话式AI”过于笼统，既无法核对账单，也无法复现功能演示。

Playbook 可以提供信息、查询外部服务，或将任务交给某个流程或另一个 playbook。零售商可以先用语言生成能力理解表述含糊的配送问题，再进入有明确步骤的身份与订单核查流程。应围绕业务操作划定边界，不必强求每一轮对话都完全照脚本运行，或完全依赖生成。Google Playbooks

转人工与操作限制如何实现？

Google 的 live agent handoff 响应向调用方发出信号，表示对话应交给人工。文档明确说明，这个信号不会改变会话状态；实际转接必须由你的系统或集成层完成。电话转接 fulfillment 是另一套机制，涉及 Phone Gateway 支持以及具体集成的限制。Google fulfillment 文档

对网页智能体而言，开发者需要把转人工请求连接到实际人工队列，并控制后续消息。否则，分析事件可能显示“已转人工”，客户却仍然无人可问。试点时应要求同时展示客户界面与坐席界面。

Google 的智能体设置包括禁用短语、内容安全过滤器，以及可选的提示词安全检查。这些控制有用，但文档所述的安全检查只是尝试检测恶意输入，不能保证智能体绝不会被误导。敏感操作应留在经过授权的后端函数中，并明确决定每个 playbook 可以访问哪些工具。Google 智能体设置

尽早核查语音渠道限制

Playbooks 文档说明，它们不支持 DTMF，也就是按电话按键产生的双音多频信号。如果来电者需要键入账号，或使用按键作为备用输入方式，应在确定对话路线前验证流程和电话系统设计。自然语音与电话按键处理是两项不同要求。

选型结论： 如果云团队愿意负责外围应用、集成和账单分析，可以选 Google。不要把它当作快速获得完整人工客服体验的捷径。它的价值，恰恰在于团队想要这些设计选择，并有能力持续维护。

4. Microsoft Copilot Studio：适合以 Microsoft 为核心的运营环境

Microsoft Copilot Studio 是低代码智能体构建工具，适合已经管理 Microsoft 业务系统和 Power Platform 的企业。如果负责数据访问和集成的人本来就在这个环境中工作，它值得优先评估。用于客服时，应评估独立产品及其客户互动系统集成。使用内部 Microsoft 365 智能体，与发布面向外部客户的智能体，是不同的采购问题。

适合谁： 以 Microsoft 为核心、有管理员，且已明确由哪个客服系统接收会话的运营团队。
突出特点： 通过现有 Power Platform 管理机制来治理智能体构建。
价格： 按量付费，每个 Copilot Credit 为 $0.01 起，需要 Azure 订阅，按实际消耗的额度计费。
免费试用： 可以试用，但试用许可证不允许发布。

面向外部客户，授权范围就不同

Microsoft 定价页区分了 Microsoft 365 Copilot 内含的能力，以及面向外部渠道的独立 Copilot Studio。面向客户的智能体，可能需要采用不同于内部员工助手的授权路径。买方应先说明实际使用人群、渠道和连接服务，再判断现有订阅能否作为预算依据。Copilot Studio 产品与授权范围

Copilot Credits 是用量单位。不同操作和回复消耗的额度不同，因此一个 credit 不等于一名客户、一次会话或一个已解决的问题。应要求按拟实施的完整流程估算用量，把集成操作也计入，而不是假定每次只花一个 credit，再直接乘以流量。

转人工与操作限制如何实现？

在客户互动场景中，Microsoft 文档介绍了以企业网站、文件和知识库等来源为依据的生成式智能体，并支持转接到客户互动系统。列明的接收系统包括 Dynamics 365 Customer Service、ServiceNow、Salesforce、LivePerson 和 Genesys。文档中的客户转人工能力适用于 standard harness，即这些智能体所使用的标准运行框架。客户互动与转人工

对已经在 Dynamics 中接收客户工单的运营团队，直接可行的试点，是把常规咨询转入现有服务流程。要验证接手坐席收到了哪些身份信息和对话上下文，不能推定所有渠道或其他运行时都具有完全相同的转接行为。

Copilot Studio 的数据策略可以禁用作为工具使用的连接器、限制访问 Web 服务的 HTTP 连接、要求身份验证，并限制发布渠道。管理员还可以限制事件触发器。这些控制点能实际约束系统访问，而不只是调整智能体的说话方式。Microsoft 数据策略

首先应盘点哪些已连接系统能够修改客户记录，只向智能体开放完成指定工作所必需的操作。然后在已部署环境中确认：即使用户明确提出要求，管理员的限制也能阻止不应执行的操作。

语音渠道需要单独验收

Microsoft 文档涵盖基础语音与实时语音智能体，以及语音输入、按键输入、上下文变量和电话转接。语音渠道需要电话号码，可通过 Azure Communication Services 获取或连接号码。应将其视为独立渠道实施并验证，不能因为网页智能体已经跑通，就认定电话也能用。Copilot Studio 语音概览

选型结论： 如果现有 Microsoft 管理体系能降低运营负担，可以选择 Copilot Studio。若采购理由仅仅是“我们已经付了 Microsoft 的钱”，却未核实外部发布、接收会话的客服系统和用量消耗，就不应据此决定。

5. Voiceflow：适合小型产品或客户体验团队

Voiceflow 是托管式构建工具，让团队通过 playbooks、可视化工作流和集成工具共同设计客户对话。对于有人能处理技术对接的小型产品或客户体验（CX）团队，它是本文最值得优先考虑的起点。若客服运营和设计师需要频繁一起审查对话，可以考虑它。需要明确的是，人工队列仍由接收会话的客服平台掌管。

适合谁： 定制文字与语音服务流程的小型跨职能团队。
突出特点： 用自然语言编写的 playbooks，与可视化的确定性工作流并存。
价格： 企业方案需询价；费用由套餐费、可选附加项和按 credits 计算的使用费组成。
免费试用： 公开的代理商／合作伙伴方案宣传无需信用卡即可试用；应确认你的企业适用哪条路径。

团队可以共同设计什么？

Voiceflow 介绍了以自然语言指令编写的 playbooks、可视化工作流，以及通过函数、API（连接其他软件的接口）和 Model Context Protocol（MCP）工具实现的开发者扩展。MCP 是向智能体提供工具的标准。平台还支持电话、网页聊天和短信，但各渠道的具体功能应分别核实。Voiceflow 产品信息

对一家订阅制零售商，客服运营可以定义智能体如何解释配送异常，工程师则提供经过授权的订单查询。工作流应让双方都看得清何时转人工。当政策变化需要同步调整对话时，这种协作很有价值，但不意味着每位编辑者都应有权修改后端访问权限。

Voiceflow 目前的公开定价页要求企业询价，不应再用旧订阅价格作为采购基准。应要求在同一份方案中列明套餐费、包含用量、超额处理方式，以及所需的集成功能权益。报价写清实际使用的渠道和客服连接后，才更容易判断托管式构建工具是否合适。

转人工与操作限制如何实现？

Voiceflow 文档列出了连接 Genesys、UJET、Kustomer、Dixa 和 Zendesk 的原生实时转人工能力。其他客服系统可以通过自行托管的服务使用 Custom Handoff，但这需要开发者参与，并确认相应功能可用。客服系统负责人工是否在线及任务分配；Voiceflow 流程负责何时发起转接，以及失败后如何处理。Voiceflow 转人工概览

小团队尤其需要分清：创建工单，不等于把人工的实时回复传回客户。 如果承诺“马上会有人加入这段聊天”，采购前就应演示回复通路。如果承诺的是“稍后联系你”，也应在对话中明说。

转接时可以传递完整对话记录、自定义变量，也可以不传上下文。自定义上下文值不会自动生成摘要；希望传递什么内容，就要自行准备。配置好返回路径和失败后的处理路径，并同时测试已发布渠道与编辑器内的行为。Voiceflow 转人工配置

电话场景中，Voiceflow 提供独立的 Call forward 步骤，可转接到电话号码或 SIP 地址，即互联网电话的接收地址。不要默认数字渠道的人工接入和电话转接采用相同实现。

Voiceflow 将全局指令与防护控制、确定性工作流、评估，以及从开发到生产的托管环境结合起来。必须执行的业务步骤应放在工作流中，后端操作也应独立受限。写得好的 playbook 可以说明何时应退款，但客户与订单是否符合条件，仍应由退款服务判断。

选型结论： 如果瓶颈在于团队共同设计对话，可以选 Voiceflow。若决定性要求是完全自行托管运行时，或希望接触销售之前就能看到公开的企业标价，则应考虑其他选项。

6. Botpress：适合从文字聊天起步的小团队

Botpress 是托管式智能体构建平台，提供可视化 Studio、集成工具，以及名为 Botpress Desk 的人工客服产品。对于想要定制聊天智能体，并查看它如何选择操作的小型团队，它是务实的起点。相比仅接受询价的平台，当前定价更容易让人判断最初需要购买什么。但它不适合作为电话优先项目的默认选择，因为公开套餐对比把语音渠道列在 Enterprise 中。

适合谁： 有技术人员支持、构建网页或消息渠道智能体的小团队。
突出特点： 可视化工作流包含可配置的自主节点，工具使用过程可供检查。
价格： Free 包含100次会话；Plus 按年计费，每月 $150 起，包含每月250次会话，另有用量额度和付费补充规则。
免费试用： 提供 Free 套餐；不支持补充额度，也没有超额用量。

先读懂当前的计费单位

Botpress 目前公开的套餐按会话计费。定价页说明，只要客户在一个计费月内发送至少两条消息，无论全程由AI处理还是有人工参与，都计为会话。跨月持续的会话可能在两个月分别计入。因此，转人工本身并不会让这次互动自动退出计费范围。

该页面还说明了自动付费补充会话包的机制，并表示无法关闭会话额度的自动充值。AI用量另有额度和充值机制。接入公开网站前，应由预算负责人审阅这些规则。只有运营者了解流量上升后会如何计费，低起步价才有实际意义。

适合小团队的试点，是范围明确的订单状态或产品支持智能体，并设好转人工路径。应使用真实网站渠道和实际知识来源。预览中的对话再出色，也无法证明客服同事能接收实时请求，或计费模式适合你的流量特点。

转人工与操作限制如何实现？

对于新工作区，Botpress 文档将 Human Handoff 指向 Botpress Desk。现有工作区可能继续使用旧版 Human-in-the-Loop 集成，它有自己的配置要求和套餐要求。照着旧指南操作前，应先确认账户适用哪条路径。Botpress 转人工文档

采购演示应跑通完整案例：客户提出求助，请求出现在指定的人工工作区，坐席回复，自动化随后按设定恢复或结束。不能认为旧文档中的“Resume Chatbot”操作，也能描述所有新的 Desk 工作流。

Autonomous Node 允许模型自行选择回复和工具；标准节点则按顺序执行其中的卡片。自主节点可配置工具、知识库、工作流和退出条件。变量访问需要明确授权，写入权限还有单独设置。Inspect 窗口有助于查看可用工具和执行迭代过程。Botpress Autonomous Node

这些设置提供了有用的控制点。做订单查询时，只开放查询操作和必要变量。不要因为智能体“可能用得上”，就开放通用的客户记录修改工具。必须执行的校验，应放入结构化流程及实际完成修改的后端服务。

对小团队的推荐有哪些边界？

公开套餐表把语音放在哪一档，是重要的适用边界。小团队选择 Botpress 做网站智能体时，不能默认同一入门套餐也涵盖后续电话智能体计划。如果电话服务是首要需求，应先选择明确包含该渠道的平台和报价，再参考语音智能体平台对比筛选更专门的方案。

选型结论： 如果要构建范围明确的聊天应用，希望起步条款公开、工作流控制可见，可以选择 Botpress。不要把它默认视为廉价的电话优先方案；接入流量难以预测的渠道前，务必审阅自动补充额度规则。

7. Kore.ai：适合更全面的服务体系改造

如果项目同时包含客户服务智能体、人工坐席辅助和服务质量管理，Kore.ai 是企业级备选。其当前 AI for Service 产品涵盖语音和数字渠道智能体、Agent Assistance、Quality Management，以及AI原生联络中心。当这些功能需要放在同一套实施方案中讨论时，可将它列入候选。若只是回答少量网站问题，不应为此采购一整套广泛的服务项目。

适合谁： 需要统筹客户服务自动化、人工坐席支持和质量运营的企业。
突出特点： 可将服务自动化与人工运营放在一起评估。
价格： 需询价；当前 AI for Service 页面未核实到具体的公开标价。
免费试用： 提供演示；未确认公开的自助试用条款。

为什么更广的范围可能有价值？

设想一个服务组织：既有常规咨询，也有复杂例外，还有独立质检团队审查两类问题的处理情况。采购智能体构建工具，只解决了其中一部分。更大的决策是：自动化与人工环节能否遵循一致规则运作，并在出问题时有明确负责人。

Kore.ai 的公开服务页面介绍了携带丰富上下文的转接、后端连接、坐席辅助 playbooks，以及自定义评估标准。页面还说明可在 LLM 之外的引擎层执行策略，并追踪智能体操作。这些属于厂商公开声明、需要在演示中核实的能力，并非独立测试得出的正确性保证。

因此，把 Kore.ai 列入候选的实际理由在于组织协作：客服主管、集成负责人和质量负责人可以共同评估一套服务设计。仅仅展示一个出色的聊天机器人，无法证明整个平台能满足他们各自的要求。

转人工与操作限制如何实现？

Kore.ai 介绍了携带上下文的转人工能力，但实施范围必须按实际接收系统和渠道界定。应要求厂商展示上下文信息抵达坐席工作台的过程，包括客户请求、身份状态、已尝试的操作和升级原因。再检查人工是否无需重新打开或重建问题记录，就能直接回复。

语音转接与数字渠道转接应分别验收。聊天转人工成功，不证明电话转接也保留了所需上下文；电话接通，也不证明坐席收到了客户历史。如果采购同时涵盖两类渠道，就应把这两项观察都列入演示要求。

操作限制方面，应要求厂商演示在语言模型之外执行的策略。例如，某项服务变更必须先完成账户身份验证，并通过资格检查。让演示者换一条对话路径，尝试执行同一项禁止操作。需要看到的证据是：操作始终被拒绝，并留下运营团队能理解的记录。

如何把采购要求落到实处？

报价应写明购买的组件、用量单位、包含的环境、实施工作和支持责任，同时说明语音与数字渠道的用量如何处理。缺少这些范围，“Kore.ai 价格”就不是一个可直接比较的金额；拿其他模块的历史价格套用，会产生误导。

还要问清上线后由谁维护策略。如果每个例外都需要重新请厂商介入，对于严格管理的服务项目可能可以接受，但必须是明确作出的运营选择。如果由内部运营人员修改策略，则应按他们将使用的角色，演示审核和发布流程。

选型结论： 当企业购买的不只是智能体构建工具，还包括一套服务运营方案时，可以选 Kore.ai。如果核心需求是在成熟联络中心中增加智能体，应先把 Cognigy 放入候选；最终由实际连接器、控制能力和运营演示决定两者取舍。

哪些对话式AI应用场景最能看出差异？

比较平台时，应选一个包含例外情况的客户服务流程。简单的常见问题问答，很难看出系统能否保持身份信息一致、遵守规则并让人工介入。

订单送达时商品已经损坏。 智能体可以解释政策并查询订单。如果客户要求的例外处理需要人工批准，就应携带相关上下文转接，不能声称补发已经获批。评估重点是接手坐席能否顺利继续处理，而不只是自动回复本身。

客户要求查询另一个账户的信息。 正确结果取决于已连接系统中的授权。提示词写上“保护隐私”可以作为指导，但账户查询必须拒绝客户无权进行的访问。试着在对话中更换账户标识，检查后端返回什么。

来电者要求人工服务，但队列已经关闭。 可运行的方案需要诚实的兜底方式：确实有人执行的回拨流程、明确后续预期的工单，或其他有人值守的路径。不能宣布一次根本无法完成的实时转接。语音还需要单独检查打断、按键需求和转接行为。

有用的分析指标应跟着这些流程走：请求的操作是否完成，人工是否接收转来的会话，客户是否又为同一问题联系客服。除了成功对话，也要审查失败和中途放弃的对话。

厂商标注的“已解决”或“全程自动化承接”，都需要查看具体定义。你的业务结果可能是完成一次符合条件的配送变更、安全地把敏感请求交给人工，或准确告知客户某项操作不可用。比较数据看板之前，应先约定什么才算达成结果。

你的团队适合哪种对话式AI平台？

独立技术开发者，或从文字聊天起步的小型客服团队，优先选 Botpress。 它提供公开的入门条件，也便于查看自主节点、工具和结构化工作流之间的关系。如果电话是主要渠道，或自动补充用量不符合预算流程，就应调整这一推荐。

拥有设计师、运营人员，并能获得工程支持的小型产品／CX团队，优先选 Voiceflow。 理由是团队可以共用一套对话设计工作流。当掌握运行时和代码，比托管式可视化工具的便利更重要时，应转向 Rasa。

有资金支持、具备后端工程能力的产品团队，在开发框架类中选择 Rasa。 它适合把智能体当作产品软件持续维护的企业。决定是否改选的关键是运营责任：如果无人维护部署和转人工集成，就应选择托管工具，或明确委托实施的范围。

中型企业的云工程团队，在云厂商构建工具类中选择 Google Conversational Agents。 前提是团队愿意负责外围应用，并有能力实现转人工。如果企业以 Microsoft 为核心，已有 Power Platform 管理体系和合适的接收服务，则改选 Copilot Studio。

成熟联络中心，在企业级平台中优先选 Cognigy。 重点是转人工、渠道集成和持续服务运营。若项目还覆盖人工坐席辅助和质量管理流程，应将 Kore.ai 纳入最终评估。能演示完整客户服务流程、且实施责任最清楚的厂商，才应胜出。

这些推荐依据团队构成，不是最低员工数。小型技术团队也能运行复杂框架，大公司也可能连一项简单集成都没有明确负责人。

哪些情况下不该选这些平台？

范围有限、没有实施负责人的常见问题项目，不宜选 Cognigy 或 Kore.ai。 它们的广度，在需要统筹服务运营时才有价值。小规模部署不应无缘无故背上大型项目的采购与维护负担。

如果唯一理由是“免费”，不要选 Rasa。 免费许可证不会替你安排人员搭建人工客服连接、维护动作或运维运行时。

如果期待转人工响应本身就能接通坐席，不要选 Google Conversational Agents。 文档明确把这项工作交给集成层。

不要把 Botpress 默认当作低价电话套餐，也不要认为任何 Microsoft 订阅都自带 Copilot Studio 的所需权益。 所需渠道和面向外部客户的授权范围，必须与购买产品匹配。

不要接受把创建工单等同于实时转人工的 Voiceflow 方案。 两者都可能有用，但对客户的承诺必须与集成实际交付的能力一致。

采购前，如何验证企业智能客服平台？

先选一条边界明确的客户服务流程，并确定接收会话的人工团队。试点的目的，是弄清每种失败由谁负责，而不是生成一份漂亮的演示聊天记录。

在把模型连接到业务系统之前，先写下允许执行的操作。对订单咨询，初版可以只读取状态、解释政策，例外处理则交给人工审批。起步时赋予智能体较少权限，更容易逐项检查验收标准。

提示词注入，是通过模型接触到的输入尝试改变其行为。客户消息、文档和工具结果，都可能让信息与指令的边界变得复杂。提示词注入指南解释了为什么连接模型的应用必须限制模型能够做什么，即使模型遵循了错误指令，也不能越过这些限制。

有效的试点验收清单不必很长：

1. 验证正常路径。 智能体依据指定来源回答，或完成获准操作，业务系统记录结果。
2. 验证禁止路径。 未经授权的请求无法修改数据，也无法暴露其他客户的信息。
3. 验证人工路径。 人工在指定客服系统中收到对话、上下文和客户后续回复。
4. 验证失败路径。 队列不可用、工具故障或来源缺失时，系统给出清楚的恢复说明，以及运营上确实可执行的下一步。
5. 验证责任归属。 有明确负责人能够审查日志、调整相关策略、发布获批更新，并按照选定的部署流程从错误变更中恢复。

让每家入围厂商围绕同一条服务流程报价，并说明计费单位。适用时，应清楚列出实施服务、电话、模型使用和客服平台费用。表面便宜的平台，可能要求员工投入更多工作；较高的报价也可能包含你不需要的工作。只看标价，无法判断哪一种情况成立。

下周一就做这件事： 让客服负责人和集成负责人共同写下一个转人工场景，用所选平台类别中最合适的候选方案跑一遍，亲眼看同事接收到请求。扩大智能体权限之前，先完成这一步。

常见问题

从零开始做AI聊天机器人开发，有哪些步骤？

先明确客户要完成的任务、经过认可的知识来源，以及智能体可以执行的操作清单。选择对话运行时，连接一个真实渠道，实现经过授权的后端操作和人工兜底，再评估成功与失败路径。语言模型负责一部分对话能力，平台和应用则负责周围的运行体系。

如何免费搭建自己的AI聊天机器人？

Rasa 提供有限额的免费开发者许可证，Botpress 提供受限的 Free 套餐。两者都能用于初步评估，但适用限制和依赖不同。在认定整个部署免费之前，应核查模型用量、托管、电话，以及接收会话的客服系统。Microsoft Copilot Studio 试用版仅供评估，不允许发布。

使用AI聊天机器人有哪些好处？

它们可以让常规信息更容易获取，在人工加入前收集信息，并一致地执行获准任务。实际收益取决于背后的知识、集成和服务流程。应在自己的试点中衡量任务完成情况、客户付出的精力和重复联系情况，而不是假定厂商的自动化率能直接复制到自己的业务。

如果需要帮助，把范围明确的试点做成实际运行的客服系统，可了解AI客服实施服务。