Sushil Kumar，Cyara 首席执行官 – 访谈系列

Sushil Kumar，Cyara 首席执行官是一位拥有超过 25 年人工智能、DevOps、云基础设施、产品战略和软件测试领域领导经验的企业软件高管和创业者。他于 2025 年 12 月加入 Cyara 担任首席执行官，此前他是 RelicX.ai 的联合创始人兼首席执行官，在那里构建了一个由生成式 AI 驱动、基于意图的测试自动化平台，该平台被 Harness 收购。随后他领导了 RelicX 技术与 Harness 的整合，并帮助塑造了其 AI 测试自动化战略。在此之前，Kumar 曾在 Broadcom 担任 DevOps 总经理，在 CA Technologies 担任产品高级副总裁，并在 Oracle 工作超过 16 年，期间担任高级产品领导职务，帮助规模化大型企业软件业务。在这些岗位上，他专注于为大型企业构建和扩展 AI、云、DevOps 和自动化平台。他在 Cyara 的任命旨在扩大公司基于 AI 的客户体验保障能力和全球影响力。

Cyara 是一家客户体验保障公司，帮助企业在语音、数字、消息和对话式 AI 渠道上测试、监控和验证客户交互。其 Cyara Agentic Platform 旨在应对 AI 驱动的客户体验带来的日益增长的挑战，包括测试非确定性 AI 代理、检测幻觉和行为漂移、验证合规性、监控生产系统以及评估端到端的客户旅程。该平台结合了 AI 代理测试、生产监控、语音和电信保障、数字渠道测试以及 CX 可观测性，每年支持超过 3.5 亿次客户旅程，覆盖超过 140 个国家的全球足迹。随着企业在面向客户的工作流中部署日益自主的 AI 代理，Cyara 正将其技术定位为评估这些系统在部署前后是否可靠、安全、一致的保障层。

您在职业生涯的大部分时间里一直在构建和扩展企业软件，从 Oracle 和 CA/Broadcom 到创立 Relicx 再到如今领导 Cyara。这样的经历如何塑造了您认为 AI 代理应更像员工而非传统软件来管理的观点？

我在职业生涯的大部分时间里致力于构建和扩展企业软件，而我们在此建立的纪律是围绕确定性系统的纪律。您知道软件应该做什么。您会根据这一预期对其进行验证。当出现故障时，它会告诉您：错误、交易失败或警报。

AI 代理并非如此运作。它们是非确定性的，同一输入可能走不同的路径。更重要的是，它们可以代表公司行事。它们会作出承诺：退款、政策、承诺。而当其中某项出错时，并不会出现故障。错误的答案听起来与正确的答案完全相同。交易成功，仪表盘保持绿色，客户却获得了公司从未同意的东西。

一旦软件能够做出决策和承诺，并且在出错时不会提示，这就需要一种不同的运营模型。

这正是将其与劳动力进行类比的价值所在。您不会通过为员工编写每一个决策脚本来管理他们。您为他们赋予角色，确定随之而来的权限，并随着他们的表现逐步扩大这些权限。代理在相同的结构下也会以同样的方式运作。

我的理解是，自治并不是一次部署决策，而是一系列晋升。代理通过展示能够完成工作、保持在授权范围内以及识别何时需要帮助来获得每一次晋升。

在企业内部，AI 代理的“类 HR”运营模型到底是什么样子，企业应首先落实哪些要素？

从岗位开始。每个代理在投入生产前都应拥有接近岗位描述的文档。它的目标是什么，哪些信息是权威的，能够使用哪些客户数据，能够自行做出哪些决策，以及其责任的边界在哪里。如果公司无法在一段文字中写清这些，说明该代理尚未准备好承担角色，只能用于演示。

该角色衍生出四项要素，顺序至关重要。上线前的证据，即证明代理能够在接近真实环境的条件下完成工作，而非仅在受控测试中。运行中的监督，让您了解代理实际的行为，而不仅仅是系统是否有响应。晋升门槛，只有在有证据支持时才授予更高权限，而不是提前。以及业务部门的负责人（而非工程部门），对该代理的权限和行为负责。

顺序搞错，其他一切都无法成立。如果职责不明确，既无法证明良好表现，也无法确认失败。角色必须先行，其后才是证据。

如果为 AI 代理分配了特定角色，组织应如何在允许其与客户或关键系统交互之前定义其职责、权限和边界？

角色说明了代理的用途。权限说明了它可以触及的范围。这是两个不同的对话，而公司往往只关注前者。

明确三件事。代理可以接触哪些系统和数据，以及以何种方向，因为读取客户记录和修改记录并非同一权限。它可以自行承担哪些承诺，这决定了金钱和责任所在：退款、信用或政策例外。以及哪些因素会导致交接，包括事先可列出的情形以及代理超出其能力范围的信号。

这些决定不应交给技术团队。他们决定公司承担的风险。负责客户体验和合规风险的人员需要参与划定这些界限，而他们通常是最后被征询的人。

随后必须证明代理始终遵守这些界限。目标并非消除所有可能的错误。错误是会发生的。关键在于代理是否了解自己的边界，知道何时停止，并能在不在客户旅程其他环节产生负面后果的前提下完成分配的工作。

你认为更大的自主权应当通过表现而非一开始就授予。企业在扩大 AI 代理可独立执行的行动范围之前，代理需要展示哪些能力？

现在构建 AI 代理已经很容易，难点在于证明它值得拥有自主权。

在扩大代理自行执行的权限之前，企业需要证据表明它能够始终如一地完成分配的任务并保持在既定边界内。这包括它对预期情境的处理方式，也包括对未预见情境的应对。代理在受控条件下可能表现强劲，但在环境或周边系统变化时可能表现不同。

客户可能从一个简单的账单问题开始，因支付失败而变得沮丧。代理必须在情绪转变发生时识别出来并及时调整方向，而不是继续沿着已验证的路径前进。

在扩大权限之前应满足三点：代理在真实环境下能够完成工作，而不仅仅是在干净的测试环境中。它清楚自身能力的边界并在此止步。并且有人能够随时提供这两方面的证据。

证明的力度必须与自主权的程度相匹配。小决策对应轻量证据。访问支付系统或为公司承担政策例外的能力，则需要更高的门槛。

企业在部署 AI 代理后，如何持续评估其表现，尤其是当其决策质量无法仅靠传统软件测试指标捕捉时？

这正是传统软件思维失效的地方。对确定性软件，你只测试是否通过或失败。而对 AI 代理，即使系统给出成功响应，也可能导致客户交互失败。

因此要评估结果，而非单纯的响应。代理是否理解了客户的意图？是否使用了正确的信息？是否完成了整个流程？是否在其边界内行动并在需要时进行升级？

基础评估——将答案与黄金标准集对比打分——是底线。每家公司都会进行此类评估。决定客户是否继续信任你的关键维度在于：合规性、偏见、滥用以及代理在真实来电者、不同口音、背景噪音、廉价手机、句子中途被打断等情境下的表现。在语音交互中，这一点比人们预期的更为重要，因为每个分数都基于转录文本。如果语音层误听了问题，代理就会回答一个根本没人问的问题。

这组算式值得细细推敲。评估中 99% 的得分听起来很优秀。但若一年有一百万次对话，就意味着有一万次失败。

有两条原则始终成立。验证应独立于代理及模型平台。我们并不自行构建代理，这也是我能坦率地说没有供应商应当评判自家 AI 的原因。标准应是企业自身的政策、对客户的承诺以及监管义务，而非供应商的评分卡。

每一次生产故障都应成为一道门槛。不是工单，也不是积压项，而是代理在下一个版本发布前必须通过的测试。如果生产中出现问题却未转化为代理必须通过的测试，你就会为同一问题付出两次代价。

信任与治理日益被视为扩展代理 AI 的主要障碍。您是否认为技术进步速度快于企业监督能力，这会带来哪些风险？

我认为情况正是如此，且这种差距是结构性的，而非努力不足的结果。一个想法可以在数周内变成面向客户的代理。但围绕该代理的运营纪律、所有权、证据、监督等则需要更长时间，因为这涉及到人员、问责，而不仅仅是软件。

风险在于，差距在扩大时仍保持不可见。代理可能向客户给出自信却错误的答案，却没有错误、没有交易失败，也没有警报。每个仪表盘看起来都是绿色的。传统运营依赖系统告诉你何时出现问题，而代理并不能可靠地做到这一点。

我认为答案并不是放慢脚步。能够在这里取胜的公司将会快速行动。答案是构建证据和监督，让你能够自信且快速地前进。代理获得的自主权越大，你就需要越多的证据来证明它能够承担相应的责任。

当一个自主代理做出错误决策时，最终应由谁负责：开发者、部署它的业务部门、提供模型的供应商，还是批准其使用的高管？

最终，部署代理的公司拥有结果的所有权。系统的构建和运营涉及多个方，但客户与模型提供商没有直接关系。客户只与标有该交互名称的公司建立关系。

这并不意味着责任只归于某个人。责任贯穿整个决策链。开发者负责系统的构建方式。业务部门决定代理被允许执行的操作。供应商负责其提供的技术。领导层负责确保公司拥有控制措施和监督，以全面管理风险。

错误在于认为因为模型做出了决策，模型就拥有该决策的所有权。事实并非如此。如果代理代表你向客户作出承诺，该承诺属于品牌。客户本能地理解这一点，监管机构也是如此。

AI 代理在遇到测试期间未预见的情形时可能表现不可预测。企业应如何在让代理接触客户、金融系统或敏感数据之前，对这些边缘案例进行测试？

你必须假设代理最终会遇到它未被设计处理的情形。关键在于它遇到时会发生什么。

因此要超出预期路径进行验证。给代理模糊的请求。给它冲突的信息。给它不完整的上下文。让它处于正确答案应是停止并升级而非继续的情境中。加入真实世界的条件，在语音交互中即包括口音、噪音、差的连接以及通话中途改变话题的来电者。目标不是确认代理能工作，而是了解在条件不理想时它的表现。

更重要的一点是，你必须验证整个客户旅程，而不是单独验证代理本身。模型通常不是问题所在。当出现问题时，我的第一个问题是模型接收了什么上下文。可能是过时的知识文章，或是两个系统的政策冲突，亦或是交接时遗漏了客户已说明的内容。每个组件都可能通过自己的测试，但客户旅程仍可能在它们之间的衔接处失败。

我们在这层系统之间已经投入多年进行仪表化，覆盖了 450 家企业和每年超过 3.5 亿次客户旅程。无论是否具备代理特性，它都会以相同方式出现故障。我们还看到基于超过 55 家不同供应商技术以及所有主要联络中心平台构建的代理，这让我们确信无论底层模型如何，模式都是一致的。

在代理获得重要访问权限之前，企业应拥有其在顺利和不顺利情况下的行为证据。

随着公司从确定性软件转向能够推理、规划、沟通并跨多个应用执行操作的系统，AI 测试将如何演进？

测试必须从询问系统是否产生了预期答案，转变为询问它是否实现了正确的结果。

这是一项重大转变。代理可能会采用多条不同路径来解决同一客户问题，而这些路径会随着模型和背后知识的变化而改变。你无法为每一种可能的交互编写脚本。必须评估代理是否理解了意图，是否在过程中做出合理决策，并且是否始终遵守赋予它的边界。

我想提醒一点，因为行业正以昂贵的方式走向错误。预发布测试现在比以往更重要，而不是更不重要。它决定了代理是否已准备就绪。认为可以跳过测试直接观察生产的论点，实际上是把风险转移到面对客户时才发现。

变化在于，预发布测试不再是流程的终点。生产环境会揭示受控环境无法完全复现的条件，而生产中发现的问题将成为代理在下一次发布前必须通过的测试。发布前的验证、生产中的警惕以及二者相互促进。第六个月运行的代理应当在可衡量的方面优于最初上线的版本。

展望未来，哪些因素将使成功构建可信 AI 劳动力的组织脱颖而出，而不是仍停留在小规模代理 AI 试点的组织？

真正从代理中获得回报的组织是那些围绕证据构建运营模型的组织。那些停滞的组织通常并非被技术阻碍，而是因为没有人能够提供下一层级批准所需的成果。法律部门或风险委员会会提出合理的问题，却没有答案，于是试点仍然停留在试点阶段。技术可能已经准备就绪，但组织仍无法证明应赋予其更大的权限。

这就是试点与运营劳动力之间的区别。试点中，总有人在监视。运营模型中，每个代理都有一个可以用一句话概括的职责。其权限是有限且书面的。其绩效由除构建团队之外的其他方进行评估。生产失误会成为发布的门槛。更多自主权随之而来。

第二个区别是所有权。在实现规模的公司中，代理归属于其服务的业务职能，并有一位明确的所有者对其行为负责。若它仍然是由 AI 团队拥有的 AI 项目，则会保持小规模，因为没有业务领导者愿意承担他们无法控制的风险。

这些并不陌生。它与公司已经管理被赋予真实责任的可信人员的方式非常接近。

试点可以凭借组织的信念运行。规模化则需要证据。

感谢这次精彩的采访，想了解更多的读者请访问 Cyara。