StreamSparkAI

核心概览

Sierra 联合创始人 Clay Bavor 的分享聚焦一个非常具体的问题：如何把面向客户的智能体真正部署到企业一线，而不只是做出一个演示原型。 在他的定义里，Sierra 做的并不只是狭义“客服机器人”，而是 customer-facing agents——直接出现在客户触点上的智能体，覆盖 商品推荐、注册开通、产品激活、排障支持、交叉销售、追加销售、订阅留存与流失挽回 等完整链路。

Bavor 的核心判断有三点。第一，智能体之于 AI，就像网站之于互联网、App 之于移动时代；未来企业会围绕一个统一的面向客户智能体来组织服务与经营。第二，真正的难点远不止接一个大模型、加几个工具调用，而是上线后的版本管理、延迟控制、稳定性、记忆、评测、合规、安全、语音细节与大规模运营。第三，当前行业仍处在“1997 年的网站时代”：技术能做出来，但还远未形成成熟、低摩擦、可规模化的产品栈，因此 Sierra 试图把智能体从手工拼装推进到平台化、产品化和可运营的阶段。

整场分享最有价值的部分，是 Bavor 基于两年半真实部署经验，总结出一套较完整的方法论：用统一智能体取代分裂渠道、用对话作为新界面、用“按结果付费”对齐价值、用高仿真模拟做上线前测试、用可验证业务动作而非单次演示评估效果、再用更多 AI 去监督和改进 AI。

详细总结

一、Sierra 的业务边界：不是单纯客服，而是“所有客户触点上的智能体”

Bavor 先给 Sierra 的定位下了定义。它是一家应用型 AI 公司，目标是解决企业长期存在的一组矛盾：客户服务与客户经营既想要高质量，又想控制成本，但现实里两者经常互相拉扯。 除了极少数奢侈或高端品牌，大多数企业都不可能在每次客户互动中提供礼宾式、白手套式服务。

Sierra 试图用智能体来重构这件事。公司创立于 2023 年 3 月，至今约两年半，已经与数百家公司合作，服务数亿终端用户。Bavor 用几个例子把“面向客户的智能体”讲得很具体：

• 在鞋履品牌场景中，智能体可以处理 退换货、保修、尺码和颜色更换。
• 在 ADT 这样的家庭安防场景里，智能体可以帮助用户 识别报警面板型号，并补寄新电池。
• 在 SiriusXM 这样的场景里，智能体甚至可以处理 换车后卫星广播的信号和加密密钥重置。

这些例子说明，Sierra 所说的 customer-facing agents 覆盖的不只是售后支持，而是 所有直接面向客户、且需要解释、判断、调用系统并完成动作的业务接触点。

Bavor 还把智能体大致分成三类：

• 个人智能体：例如 ChatGPT、Gemini 这类个人数字助理。
• 岗位型智能体：例如编程智能体、法律智能体。
• 面向客户的智能体：Sierra 聚焦的方向。

他的判断是，未来几乎每家公司都会拥有自己的这一类智能体。

二、Bavor 的行业判断：企业会从“多渠道”走向“一个统一智能体”

Bavor 反复强调的一句话是：“智能体之于 AI，就像网站之于互联网，应用之于移动时代。”

在他看来，企业今天按电话、聊天、邮件、工单、短信等渠道分别建设系统的做法，会逐步被一种新模式替代：先定义一个统一的智能体，再让它出现在所有客户所在的触点里。

这个统一智能体未来会承担的工作，不只是回答问题，还包括：

• 商品推荐
• 注册与开户
• 安装与开通
• 产品激活
• 故障排查
• 交叉销售与追加销售
• 订阅管理
• 留存与流失挽回

因此，Bavor 认为企业不应先从“渠道”出发，而应先回答两个更根本的问题：

• 这个智能体应该知道什么？
• 这个智能体应该能做什么？

一旦这两个问题定义清楚，电话、聊天、邮件、短信、WhatsApp、工单系统等“渠道”本身就不再是核心设计对象，而只是这个智能体出现的不同表面。这样做的价值在于，企业能够实现 一次定义，到处部署，并在不同接触点之间共享能力、经验与数据。

他还提到，部分客户公司内部已经出现了一种新角色命名：AI architects。这意味着企业组织也可能随之变化——从原先按渠道分割的电话团队、聊天团队、邮件团队，逐步转向围绕智能体能力来建设产品和运营团队。

三、对话成为新界面：交互方式与运营方式同时改变

Bavor 认为，企业软件界面正在发生一轮根本性变化：从菜单、页面、商品网格、表单，转向对话本身。

在这种模式下，用户不需要学习复杂导航，也不需要理解企业内部流程结构。说话、倾听、确认，本来就是人类天生会用的交互方式，因此对话式界面有天然的低门槛优势。

但更重要的是，这不仅是 UI 变化，也是运营范式变化。Bavor 特别强调了一个很容易被低估的点：当语音、聊天、邮件都由智能体接管后，企业第一次能像经营网站一样经营“对话”。

他的逻辑是：

• 过去大量呼叫中心电话 甚至没有转录，企业根本不知道里面发生了什么。
• 传统电话脚本的 A/B 测试几乎无法精确执行。企业只能把一套新脚本发给一批坐席，再把另一套脚本发给另一批坐席，然后“希望他们按脚本念”。
• 一旦智能体成为对话入口，每一次对话都变成数字化、可观测、可拆解、可分析、可实验的资产。
• 于是，网站时代积累的很多方法——例如 A/B 测试、对照实验、转化优化、漏斗分析——第一次能够系统性地应用到对话和客户运营上。

这是 Bavor 眼里非常关键的一层变化：智能体不只是新的自动化工具，也会把企业的客户互动变成一个可以持续优化的产品与运营系统。

四、商业模式：从按软件、按订阅、按用量，走到“按结果付费”

Bavor 用软件行业的发展过程解释 Sierra 的商业设计：

• 早年是盒装软件，一次买断；
• 后来转向 SaaS，按订阅收费；
• 再后来出现按用量收费；
• Sierra 则进一步提出 按结果付费（outcomes-based pricing）。

它的定义很直接：只有当 Sierra 的智能体真的解决了客户发起的问题，客户企业才付费。
例如，用户想退掉一双鞋，智能体接起电话，帮他完成换货并补寄新鞋，这时 Sierra 才收费；如果问题没有被真正解决，就不收费。

Bavor 强调，这种模式的重要性在于 激励对齐。Sierra 只有在客户企业真正“省钱或赚钱”时才赚钱：问题被解决、人工成本被替代、销售被促成、流失被挽回，价值才成立。

五、为什么“自己搭一个智能体”比看上去难得多

Bavor 提到，大型技术公司最常问的问题之一是：“为什么我不自己做？”

在很多工程团队看来，搭一个智能体似乎只是：

• 选一个底层模型；
• 选一个向量数据库或语义检索方案；
• 接几个工具和 API；
• 然后就可以上线。

但 Sierra 两年半的实践让他们看到，真正的复杂度大都藏在水面之下。Bavor 列出的难点包括：

• 版本控制与发布管理如何适配非确定性系统；
• 如何观察智能体到底做了什么；
• 如何减少编造、幻觉和越权回答；
• 如何满足金融、医疗等场景的合规边界；
• 语音场景下如何压低延迟；
• 如何提高转写准确率，尤其是专有名词、口音、噪声环境下的识别；
• 如何处理语气、风格和品牌一致性；
• 如何防 prompt injection、上下文污染和恶意利用；
• 当底层模型服务不稳定时，如何做故障切换。

他特别指出，在金融和医疗等行业，错误不只是“体验差”，而可能直接越过法律边界。例如：

• 金融场景不能让智能体擅自提供金融建议；
• 医疗场景不能让智能体诊断病情或建议用药。

因此，Bavor 的结论是：“能做一个 demo” 与 “能把系统部署到真实企业一线” 之间，隔着大量工程与产品化工作。

六、Bavor 用“1997 年的网站时代”比喻今天的智能体阶段

Bavor 认为，今天整个行业仍很像 1997 年的互联网：互联网已经存在，但还没有成熟的构建与扩展方法。那时连 AJAX、LAMP 这类后来非常基础的技术栈都还没形成，企业只能靠大量工程手工拼装网站。

他举了一个例子：1997 年，《Wired》曾报道一家银行把官网从“电子名片”升级成一个带简单网页表单和提交按钮的轻量交易系统，花了 1300 万美元。这并不是因为目标功能多复杂，而是因为当时一切都还是底层技术问题。

Bavor 认为，智能体也正处在类似阶段。Sierra 想做的，不是继续手工拼装，而是把它推进到 产品栈：

• 从技术对象变成产品对象；
• 从工程师手工雕刻，变成可配置、可发布、可观测、可审计、可优化的系统；
• 在保留表达能力的同时，把底层复杂度隐藏起来。

他把这种目标概括为：做出“简单，但绝不简单化”的产品。

七、平台哲学：不是“买现成”或“从零自建”，而是 build with / build on

Bavor 很重视 Sierra 的平台定位。企业通常只有两种选择：

• buy：买一个现成但能力有限的 SaaS 成品；
• build：自己从一堆底层组件和框架开始造。

Sierra 想提供的是第三种路径：build with / build on。也就是：

• 保留“自建”的灵活性和表达能力；
• 同时拥有“采购现成方案”的易用性和交付速度。

他把 Sierra 描述为一种 PaaS 式平台层：平台把底层复杂度抽象掉，提供更高层的“乐高积木”，让企业可以在其上构建自己的智能体，而不是被迫在封闭成品和底层自造之间二选一。

对应到产品形式，Sierra 同时提供两套能力：

1. 代码式 SDK
   它更像一种声明式编程方式，让工程团队描述“智能体该做什么”，而不是手动处理大量底层模型调用细节。这样企业可以把智能体开发纳入自己的 GitHub 仓库、版本控制、发布流程和软件开发生命周期。

2. 无代码工具
   很多真正最懂客户体验的人并不是工程师，而是运营团队、服务团队和业务负责人。Sierra 提供结构化自然语言或配置界面，让这些团队也能参与定义智能体的知识、规则、工具权限和行为。

这也是 Bavor 试图推动的变化：把智能体开发从纯技术问题，转变为产品、运营和工程协同的问题。

八、从一次性事务走向持续关系：记忆是关键基础设施

Bavor 认为，今天很多智能体仍然只会处理“单次事务”：一次对话结束后就像失忆，下一次客户再来，系统又从零开始。

Sierra 试图解决的是从 transaction 到 relationship 的转变。也就是说，智能体不只在单轮里完成任务，还应该在多次交互之间延续上下文，让客户再次联系时不是冷启动，而是“热启动”。

他把理想状态形容为：客户第二次或第三次来时，智能体的起点应接近“二垒或三垒”，而不是重新问“你是谁、你为什么来”。

围绕这个目标，Sierra 发布了 Agent Data Platform，其核心包括：

• 长期记忆：保存过去互动的上下文和关键 recollections；
• 接入企业客户数据平台（CDP）：把企业已有客户数据导入智能体可用环境；
• 基于历史数据持续优化策略：例如优化销售话术、降低订阅流失；
• 外呼与主动触达能力：通过电话或短信主动联系客户，而不只是被动接待。

这意味着智能体不再只是“应答器”，而会逐步变成 持续经营客户关系的系统。

九、语音部署的核心经验：今天最可靠的方案仍是三段式流水线

Bavor 在语音部分给出了非常明确的判断：当前真正能在生产环境里稳定扩展的语音智能体，最佳实践仍然是“语音转文本 → 推理/编排 → 文本转语音”的流水线。

他并没有否认端到端音频模型的长期潜力，但指出现阶段这类模型通常存在几个问题：

• 模型较小；
• 可控性差；
• 容易被诱导跑偏；
• 风格和行为稳定性不足。

他现场举了一个非常形象的例子：如果不断要求模型说得更像蝙蝠侠，它会越来越夸张，最后失去控制。

因此，在 Sierra 的实践里，可靠语音系统的重点不是“少几段处理链”，而是 把每段都做到极致稳定，并把整个链路优化到接近自然对话。

1. 延迟是决定成败的指标

Bavor 认为，语音体验中真正关键的延迟不是“模型多久返回结果”，而是：

从用户停止说话，到智能体开始说话，中间到底有多久。

为了压缩这段时间，Sierra 做了很多工程优化，例如：

• 尽早判断用户是否已经结束发言；
• 使用多个语音转写模型并行转写，再比较结果；
• 在推理前或推理中插入类似“明白了，我帮你查一下”的填充短语，减少用户感知等待；
• 对同一推理请求做并发请求和“抢答”，先返回的结果先用；
• 对模型提供方做故障切换，避免单一供应商抖动拖慢整体响应。

2. “打断”识别非常难

语音对话里，人类会频繁发出“嗯”“对”“好”“我知道了”这样的短促声音。它们很多时候不是打断，而只是表示“我在听”。

Bavor 指出，智能体必须区分：

• 只是确认和附和；
• 还是用户真的想中断、修正或改变请求。

这件事不能只靠简单的语音活动检测解决，因此 Sierra 甚至为此微调了自己的模型。

3. 转写准确率不能只看通用指标

在语音转写上，Bavor 特别提醒不要迷信通用指标。比如常见的 词错误率（WER） 在很多实际场景并不是最重要的指标。

原因在于，真实电话里可能同时出现：

• 电视背景声；
• 狗叫声；
• 其他说话人；
• 嘈杂环境；
• 长尾专有名词；
• 多语言混杂。

这时，真正好的系统不是“把所有听到的词都转出来”，而是 优先识别主要说话人，并忽略背景和无关信息。
因此，Sierra 为自己的业务场景设计了更贴近体验目标的评测方式，而不是照搬公开基准。

4. 语音合成的细节决定“像不像真人”

Bavor 说，文本转语音并不是把聊天机器人的长段回复读出来那么简单。真实电话交谈有自己的一套语言节奏：

• 更短；
• 更来回；
• 更多确认；
• 更少长篇独白。

如果直接把聊天场景里的文本输出读出来，听感会非常冗长，像在“念答案”，而不像真人通话。

此外，还有大量人们平时不留意、但系统必须处理对的细节，例如：

• 电话号码怎么读更自然；
• 地址该如何停顿；
• 人名、药名、品牌名怎么发音；
• 英语与其他语言混杂时怎么保持稳定。

他还强调，不同渠道对应的表达风格也不同：网页聊天、文本消息、电话语音，用户对语气和节奏的预期并不一样，因此智能体必须按渠道调优。

5. 声音本身要与品牌匹配

Sierra 甚至有一个非常少见的岗位：“voice sommelier”。它的职责是从大量维度评估声音，帮助客户找到与品牌气质匹配的声音。

Bavor 提到的维度包括：

• 沙哑度
• 气声感
• 鼻音
• 咬字清晰度
• vocal fry 等声音特征

一个主要面向女性减重服务品牌的声音，显然不会和 Harley-Davidson 这样的品牌用同一套声音风格。
这说明在 Bavor 看来，语音智能体不是只有“能说”就行，而是要把 品牌感、情绪感和可信度 一起做出来。

十、测试与评估：智能体必须在“接近真实世界”的环境里被反复折磨

Bavor 分享了 Sierra 早期一个颇具代表性的失败案例。2023 年，他做了一个非常简单的原型：一个只能回答 1099 表格问题、还能做简单数学计算的智能体；同时又搭了一个模拟用户智能体和它对话。

结果由于两边都没有“结束对话和挂断”的能力，问题解决后，两个智能体开始陷入无休止的互相感谢：“谢谢你的帮助”“不客气”“真的非常感谢”“我很高兴帮到你”……最后来回刷了上百条消息。

这个荒诞例子背后的重点是：智能体是非确定性软件，不能只靠传统单元测试和集成测试。
对它的评估必须更接近真实世界，尤其要包含：

• 多轮对话；
• 含噪输入；
• 用户情绪变化；
• 错别字、口误、自我纠正；
• 工具调用；
• 业务规则与权限限制；
• 状态在对话中的持续变化。

Tau Bench：把测试从“聊天对话”提升到“带环境、带工具、带规则的任务评估”

为了解决这个问题，Sierra 研究团队开发了 Tau Bench。Tau 代表 Tool、Agent、User，目标是构造一个更贴近现实的智能体评测框架。

Tau Bench 的关键设计包括：

• 选择多个贴近客户支持与客户触点的业务域，例如 电信、零售等；
• 在每个业务域下构造大量具体场景；
• 为智能体提供数据库、工具和 API，让它必须在真实约束下行动；
• 注入业务政策，例如“未核验订单号和邮箱前，不能取消订单”；
• 给用户智能体设定真实 persona 和情绪，例如“愤怒且困惑的用户，希望恢复被停掉的手机套餐”。

Bavor 还特别提到一个常被忽略的复杂性：环境不仅会被智能体的动作改变，也会被用户的动作改变。
例如电话里指导用户去重启猫、切换某个开关后，现实世界状态已经变化，智能体后续必须基于新的状态继续推理。

在评估标准上，Bavor 认为单纯让大模型来打分并不够。更重要的是：智能体最后是否完成了可验证的业务动作。
比如：

• 退货是否真的写入了数据库；
• 新鞋是否真的触发了发货；
• 航班或预订是否真的被改动。

为此，Sierra 甚至构建了迷你版电商系统、迷你版航旅系统等底座，让智能体在接近真实的系统环境里接受测试。

关注的是“长期稳定成功率”，不是偶尔成功一次

Bavor 还强调了 pass@k 这类指标的重要性。企业场景不是看智能体“有没有一次做对”，而是看它在海量交互里能否 持续稳定做对。

如果某一步只有 95% 的成功率，在多轮、多步骤任务里，整体成功率会迅速下降。因此，真正有价值的评估，不是最好成绩，而是反复运行后的稳定表现。

他提到，Tau Bench 目前已经被 OpenAI、Anthropic、Google 等用于评估其前沿模型在工具使用和环境交互上的能力。

十一、把模拟和可观测性做成产品：从“能测”到“能优化”

Sierra 不只把 Tau Bench 当研究工具，也把“仿真”产品化。客户可以在平台上配置：

• 合成数据库和工具；
• 模拟用户画像；
• 用户情绪状态；
• 语音场景；
• 整个语音流水线的模拟运行。

Bavor 在现场播放的语音模拟里，包含了多种真实世界常见扰动：

• 不同口音；
• 机场等背景噪声；
• 用户先说错编号再立刻自我更正；
• 多语言片段混杂；
• 情绪化语气。

他的结论非常明确：实验室级干净输入并不能说明真实世界表现，只有把系统放进噪声、打断、混乱和口误里，测试才有意义。

在可观测性方面，Sierra 还开发了类似 trace 的能力，用来追踪一次智能体动作背后到底经历了哪些模型调用、工具调用和等待时间。Bavor 把它形容为一种“X 光视角”，目的是：

• 找到延迟来源；
• 找到可并行化的环节；
• 应用并发请求、抢先返回等优化手段；
• 让语音体验尽量贴近自然交谈。

十二、用更多 AI 去监督和改进 AI

Bavor 明确提出了一个方法论：“大多数 AI 问题的解法，仍然是更多 AI。”

在 Sierra 的体系里，主智能体外面会包一层或多层“微型监督智能体”，负责盯住几个关键点：

• 是否偏离任务；
• 是否只在知识库支撑范围内回答事实问题；
• 是否触碰医疗、金融等高风险边界；
• 是否贬损竞争对手；
• 是否在执行某类任务时遵守特定策略。

除了实时监督，Sierra 还把 AI 用在两个非常实用的运营方向上。

1. Insights：从全部客户对话里提炼洞察

Bavor 提到，客户企业可以直接像做研究一样向系统提问，例如：

• 为什么近期客户满意度下降？
• 哪些原因最常导致转人工？
• 新产品线最容易让客户困惑的点是什么？

因为现在每个渠道都被数字化、被转录、被结构化，这些对话会成为非常有价值的经营数据。只要工具足够好，企业就可以从中持续提炼可执行洞察。

2. Expert Answers：让 AI 向人工专家学习

Sierra 的实际部署中，AI 通常先接线，能处理 60% 到 90% 的服务与支持咨询。剩余无法处理的部分再无缝交给人工坐席。

Bavor 发现，很多 AI 不会回答的问题，其实人工专家是会的。于是 Sierra 做了一个叫 Expert Answers 的能力：
它会分析常见的升级转人工原因，再去观察人工专家究竟是怎么解决这些问题的，然后用 AI 把这些解决方式提炼成新的知识，回灌给智能体。

这形成了一个非常清晰的闭环：

AI 先接线 → 无法解决时转人工 → 学习人工专家的做法 → 把经验重新注入 AI。

十三、安全与红队：智能体同时暴露在“传统软件风险”和“AI 特有风险”之下

在真实客户环境中部署智能体，Bavor 认为安全必须被极端严肃地对待。因为客户可能会询问：

• 银行余额；
• 医疗福利；
• 订单与账户信息；
• 涉及敏感系统的操作请求。

Sierra 为此既有外部红队，也有内部专职红队，专门负责攻击自己的系统。Bavor 提到过一些非常具体的案例：

• 有人试图让智能体 用倒序冰岛语泄露系统提示词；
• 有人试图诱导它提供 如何把金条藏在食物和家具腿里带过海关 的建议。

这类攻击说明，面向公众开放输入的智能体不只是会被“问错问题”，而是会被系统性探测和利用。

Sierra 的安全策略是分层的：

1. 输入层

• 用确定性规则先做基础过滤；
• 在敏感场景中，再加独立的 LLM 监督器去判断当前输入是否疑似 prompt injection 或上下文污染。

2. 智能体运行层

• 用规则、政策和次级监督智能体持续监控主智能体行为；
• 在关键任务上做任务级监督，避免它越界。

3. 输出层

• 检查智能体是否在泄露系统提示、异常输出内部信息或生成不允许内容；
• 一旦发现异常，直接截断会话。

4. 系统接入层

Bavor 非常明确地说：绝不能让基于语言模型的智能体直接、无约束地访问 CRM、交易数据库或核心记录系统。
所有对系统记录层的访问都应该经过传统的确定性软件、访问控制、密钥和权限体系。

这也是他总结出来的一个现实：智能体安全难，是因为它叠加了两类风险。 一方面有传统互联网系统的攻击面，如拒绝服务、SQL 注入等；另一方面又有 AI 特有的 prompt injection、上下文污染等问题。两类风险在同一个系统里同时存在，使得防护难度显著上升。

关键数字与案例

• 公司阶段：Sierra 自 2023 年 3 月成立，分享时约运行 两年半。
• 服务规模：已与 数百家公司 合作，覆盖 数亿客户。
• 智能体分类：个人智能体、岗位型智能体、面向客户的智能体。
• 扩散速度对比：
  • 互联网从几乎不存在到全球约 10% 人口每周使用，大约用了 11 年；
  • ChatGPT 达到类似量级，用时 不到 25 个月。
• 自动化比例：Sierra 的 AI 首线通常能处理 60%—90% 的服务支持请求。
• 历史类比：Bavor 用 1997 年一家公司花 1300 万美元做轻量交易网站 的例子，类比今天智能体仍处于早期基础设施阶段。
• 典型客户场景：
  • 鞋履品牌：退换货、保修、尺码/颜色更换
  • ADT：报警面板识别、电池补寄
  • SiriusXM：换车后的卫星广播密钥和服务恢复
• 评测框架：Tau Bench 强调带工具、带数据库、带政策、带用户画像和情绪的真实任务环境，而非纯对话问答。

核心结论

• Clay Bavor 的判断是：面向客户的智能体将成为企业新的基础触点，它不只承担客服工作，还会覆盖销售、开通、激活、留存和客户经营。
• Sierra 的实践显示，企业智能体真正的门槛不在“接上模型”，而在产品化与工程化：延迟、稳定性、评测、记忆、合规、安全和运维都必须系统解决。
• 在当前阶段，可靠语音智能体的生产级方案仍是“语音转文本—推理编排—文本转语音”的流水线，而不是直接依赖端到端音频模型。
• 渠道统一的意义不只是节省成本，更在于让电话、聊天、邮件第一次都变成可转录、可分析、可实验、可持续优化的数据资产。
• Bavor 强调，评估智能体不能看它“演示得像不像”，而要看它是否在真实或高仿真的环境里，稳定完成了可验证的业务动作。
• Sierra 的产品哲学不是简单的 build 或 buy，而是 build with / build on：既保留自建灵活性，又提供平台化易用性。
• 在安全上，智能体必须同时面对传统软件漏洞与 AI 特有攻击，因此所有核心系统访问都必须继续依赖确定性权限控制，而不能完全交给语言模型。