评估面向客户的 AI 智能体时，企业往往把注意力放在它们能做什么上。AI 理解请求并检索到正确信息的可靠性有多高？它能否在不把客户转接给人工的情况下完成一笔交易？
但 AI 部署失败的原因，常常与软件本身的能力毫无关系。真正让项目卡住的，是企业缺少把它成功搭建起来所需的专业能力。提示词怎么配、知识源怎么接、集成怎么搭，以及客户服务运营所需的护栏和评估工具怎么建？
对许多 AI 系统而言不巧的是，这些搭建工作仍然需要专业能力。大公司可以请咨询顾问，或者派驻工程师。但小公司往往在试点阶段苦苦挣扎，始终走不到生产环境。
一个用来构建和运营智能体的智能体
Typewise 提供面向客户体验的 AI 智能体平台，在它所服务的大多数中型企业身上，都看到了这种能力缺口。为填补这个缺口，该公司推出了 Nova，并将其描述为其客户体验平台的”AI 操作员”。Nova 并不是一个直接与客户交互的 AI 智能体。相反，它的职责是构建并管理那一群真正与客户打交道的 Typewise 智能体。
企业接入自己的系统，用日常语言描述想要的客户体验。之后 Nova 就能为账单、退货、保修索赔等领域创建专用智能体，判断它们需要访问哪些系统，并起草约束它们行为的指令（提示词）。
部署之后工作仍在继续。Nova 会监控生产环境中的活动、调查表现的变化并找出可能的原因。例如，如果某项政策或工作流变更之后客户满意度下降，Nova 可以诊断问题、提出修订方案，并在请企业批准之前先对这项变更做模拟推演。
Typewise 并不孤单
NiCE Cognigy 近期推出了一套相关做法，名为 Agentic Building for CX AI。其开源 Agent Plugin 允许 Claude Code、ChatGPT、Codex 和 Gemini 等编码智能体直接与 Cognigy 环境协同工作。
该插件让这些智能体能够获取最新的 Cognigy 文档、通过 MCP 暴露的平台工具、Cognigy 专属技能，以及用于构建 AI 智能体或审计语音配置这类任务的专用智能体。用户可以提供一个通话记录、需求文档、URL 或工作说明书，然后让编码智能体创建相应的流程、知识库、工具和端点。同一个智能体还能测试该实现，并为部署做好准备。
这两种做法目前在呈现方式与目标用户上有所不同。Cognigy 的能力，主要是为开发者、架构师和解决方案顾问准备的实施伙伴，通过一个外部编码助手来使用。Typewise 则把 Nova 定位为一个内置操作员，客服团队可以直接对它下指令，并且它会在整个生产生命周期中持续参与。
软件开始吸收服务，但平台还能活下来吗？
把视线移出 CCaaS 的世界，像最近发布的 Grok Bot 这样的智能体方案，采取了一种更激进的”零代码”路径。用户装好 Grok Bot 平台后，只需直接指示她的第一个智能体——她可能管它叫”运营总监”——让它自己构建起来，并自行生成它认为完成她想要的工作所必需的全部智能体角色。零代码方案延续了几十年的承诺，终于兑现了。
但可自我配置的 AI 智能体的出现，意义并不只在于填补实施能力的缺口。
一个更激进的可能性是：能力越来越强的软件智能体，会整体降低对标准化商业应用的需求。这正是早前那些”SaaS 末日”警告背后的思路，尽管坦白说，那些预言并没有真正应验。
定制化企业软件的问题在于：构建和维护成本高、部署复杂，而且不一定比一款现成的同类最佳应用更好。既然专家已经基于最佳实践把业务流程打磨好、并把这些都固化进了相对负担得起的（一切皆是相对而言！）应用里，企业再去拼凑自己的 ERP 或 CRM 系统就毫无意义。
软件智能体能否改变这道算式？企业不必再买一个功能远超自身所需的复杂 CCaaS 平台，而是可以直接向 AI 智能体描述它想要的客户体验。然后它可以把自己现有的系统接上这个智能体平台，并提供对自身政策、交互历史和运营约束的访问权限。智能体则可以为这家组织专门设计并构建所需的专用智能体、工作流、集成、评估系统和管理工具。
一夜之间，这家企业就有了一个定制化的 CX 应用。那么，我们是不是已经走到了这样一个时代与节点——这种一次性系统开始变得合理了？
大概还没有，至少在未来可预见的范围内没有。不过，在我们当下这个技术指数级加速的时代里，即使有人呼吁给前沿进展降速，谁又能看清几天之后的事呢？
但拥有能够可靠且专业地自我配置的软件？这看起来像是那种可能很快就会成为新入场门槛的能力之一。实施专业能力，正在变成一项产品功能。
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/zixun/72050.html
