三位创始人谈 AI 智能体的验证、扩展与成本

Wispr 的 Sahaj Garg 说，会议辅助不应只覆盖对话本身。产品使用智能体帮助人们准备会议、聚焦想要完成的目标，并在会后执行后续工作。Wispr 正在构建会前简报和任务自动化功能。

Actively 的 Mihir Garimella 说，其销售产品通常为每个客户账户运行一个智能体，积累记忆并推动账户进展。销售人员和管理者也有跨账户的问题，例如今天应该联系哪五个客户，或哪些交易应纳入预测。Actively 用两周时间构建了负责汇总这些信息的 Watchtower；他说，它已成为产品中使用最多的功能之一。

Pendo 的 Todd Olson 介绍了一项观察用户如何使用应用的产品分析服务。随着应用变化越来越快，分析埋点可能与软件实际行为产生偏差。Pendo 的智能体为代码库创建快照，将其与应用行为比较，并主动提出发现和可能的修复方案。

Garg 用会议简报解释为什么结果很重要。一份有用的简报会说明与会者是谁、为什么重要、会议目的以及相关的此前背景。如果简报把同名的人搞错，反而会让用户困惑。他说，当智能体无法确认信息正确时，不展示内容更好。

Wispr 使用独立评估者检查智能体是否达到了预期结果，以及是否正确标注来源。Garg 说，反馈也能帮助改进原有工作流。结果评估功能使用评分标准，并可让智能体修改工作，直到满足标准。

评分标准既包括客观检查，例如 LinkedIn 资料是否属于正确的人，也包括呈现方式。一份五页的会前材料可能准确，却长到没人愿意看；有效的简报需要便于浏览，并以有用的顺序展示与会者、目的和后续步骤。Wispr 把这些用户体验要求转化为智能体的评判标准。

Lance Martin 问，验证过程如何确定外部信息的真实性。Garg 说，团队可以在会议前约 24 小时开始准备简报，为评估留出时间。另一个使用独立上下文的智能体可以比较资料、邮件和日历邀请，独立判断身份看起来是否正确。

独立验证器与执行任务的智能体工作轨迹分开。Garg 说，Wispr 不必强迫流程持续运行到完美：对于主动提供帮助的助手，在不确定时直接不展示信息即可。目标是在可能时提供帮助，同时避免造成伤害或烦扰。

Actively 面临另一种上下文问题：每家公司对客户账户归属、预测和交易流程都有自己的定义，而源数据可能很混乱。Garimella 说，与产品的互动帮助系统学习这些概念，并将其保存为组织层面的记忆。它也可能提出澄清问题并保存答案，减少初始配置工作。

某些跨账户问题需要深入处理数百笔交易。Garimella 说，Watchtower 能编写代码、缩小候选范围、向独立的账户智能体分派任务并汇总回答。这使它既能应用公司特有的业务逻辑，也能处理针对大量账户的复杂查询。

公司区分几种不同的记忆。每个持续运行的账户智能体会在账户的整个生命周期中积累上下文；跨账户工作则可能揭示预测规则等更广泛的概念。Garimella 还区分了用户层面和组织层面的记忆，不同形式分别改进产品的不同部分。

Olson 说，Pendo 在沙箱中创建客户源代码的快照，因为代码可能包含机密。团队还必须决定哪些工具能与代码交互、接收哪些数据，以及可以采取什么操作。一次会话结束时，系统可能向客户的代码仓库提出拉取请求。

Pendo 曾花时间自建这套基础设施，但覆盖安全方面的边缘情况并非公司的核心价值。Olson 说，它需要一个企业能够信任的系统。同一托管环境既支持夜间批量分析趋势，也支持快速检查源代码、回答单个问题的会话。

Martin 问，什么时候自建智能体框架比使用托管服务更合理。Garg 说，决定因素是框架本身是否对功能价值至关重要。对于会议简报，用户关心的是结果；对于设想中的完全语音控制助手，周边系统则可能提供让产品形成差异的能力。

Garg 将选择归结为控制权与时间、成本之间的权衡：不决定功能价值的基础设施可以购买，控制权至关重要时则自行构建。Olson 补充说，早期产品需要快速实验和客户反馈。团队之后可能为了更细的控制或成本而需要自有基础设施，但最初应把精力放在让产品有用的部分。

Olson 说，Pendo 原有自建方案，但遇到的问题表明它需要重建。与托管智能体比较后，团队在几天内获得了可运行的基础设施，并在几周内完成产品迁移。Garg 说，Wispr 用一天构建出会议助手功能的初版，经过进一步迭代，在几周内支持了用户规模增长 100 至 1000 倍。

对 Wispr 而言，主要工作是弄清用户真正需要什么：构建一个版本、内部使用、请其他人测试，再重复这个过程。团队调整了提示词、技能和工具，也调整了跨来源搜索、检索、排序和呈现的顺序。Garimella 说，Actively 的 Watchtower 同样只花了约两周就从想法走到向客户发布。

Garg 说，不必维护框架后，团队可以专注于某次会议中哪些信息重要、呈现方式是否合适。他认为，非正式测试有助于判断产品是否有用，但一旦人们开始依赖它，就需要系统评估。评估一项无人需要的功能，本身不会让它变得有吸引力。

Garimella 解释说，对 Actively 而言，并非所有记忆都同样容易替换。长期保存的账户记忆内容详细，是产品的核心。公司自行管理这部分，包括如何建立索引以便高效查询，以及如何在记忆增长、可能出现损坏时保持稳定。

其他记忆——字段含义、组织如何运作和个人偏好——必须好用，但不需要为 Actively 专门设计。托管记忆处理这一层，让团队能集中精力改进销售工作的产品体验。Garimella 说，使用几个月后，公司仍没有觉得需要替换它。

Martin 澄清了架构：每个账户智能体都有 Actively 自己管理的独立记忆系统，而 Watchtower 可以访问整组智能体的记忆。要回答销售人员应当处理哪五个账户，托管智能体会结合账户上下文、用户偏好和公司优先级。它可以编写代码查询账户记忆，并向多个智能体分派工作。

这种跨账户视图对销售人员和管理者都有用。Garimella 说，一名管理五位客户经理的主管可能要负责 500 个账户。Watchtower 提供了针对这一更大范围提问的方式，同时各账户智能体仍可用于处理单个账户的工作。

Pendo 的智能体结合客户代码访问权限和应用的运行数据。Olson 说，团队在不到两周内建立了托管智能体方案，但仍需调整以符合运营控制要求。有了这一基础后，系统便能支持多种工作流。

当开发人员提交代码变更时，Pendo 会启动一个会话，审查改动并进行轻量级用户体验检查。变更合并后，系统可以判断是否需要更新分析埋点，并提出自己的代码变更。夜间，它可以寻找下降的转化率，并将下降与此前的代码变更联系起来。

该产品还会检查人与智能体的对话是否出现更高的错误率，并可能建议修改提示词。Olson 的长期目标是让软件能够注意到自身运行情况、提出修复建议，并帮助团队保持快速推进。他说，评估仍然重要，但真实用户行为能提供额外证据。

Martin 指出，精心整理的评估集也可能不能代表真实用户。Garg 描述了先进行非正式测试、等功能看起来有用后再系统改进的过程。内部反馈是起点，但存在让产品过度适应公司员工用法的风险。

Garg 建议收集外部反馈，包括正面和负面反应，并按任务、回归问题和困难场景组织测试。他也希望离线评估的评分标准与检查实时结果的标准保持一致。他说，只要用户实例足够，就能相对较快地建立有用的测试集。

Garimella 说，Actively 的内部销售团队使用了产品，但他们的问题不能代表每一位客户。团队开始研究真实客户查询，并询问当事人为什么提出查询、想得到什么。团队使用客户数据围绕这些案例建立评估，避免测试过于抽象。

创始人们尚未完全解决对记忆实时变化的系统进行评估的问题。Garimella 说，可以检查智能体如何与记忆交互，但离线结果检查依赖外部状态。Garg 补充说，Slack 等第三方工具也会随时间变化，除非团队模拟外部系统，否则很难建立稳定的测试集。

谈到迁移到新模型时，嘉宾建议建立良好的评估集，并避免把提示词过度针对某一模型系列优化。创始人们也希望供应商解释新模型特有的失败模式。讨论中提到的一个例子是，某个模型会产生更明显的 AI 写作习惯，例如过多破折号和别扭的句式。

成本是另一个问题。Garg 说，团队需要权衡控制权的价值与运行托管服务的成本。他估计，对于提前 24 小时准备的工作，如果更容易使用批处理，可能节省 50%–75% 的成本。目前 Wispr 在谨慎花费的同时专注于创造用户价值，预计会逐步优化细节。

Olson 希望获得更细致的信息，了解哪些调用产生了成本，尤其是夜间大型批处理。早期团队可以降低频率或减少发送的数据量，而不必精细优化。他预计，到了更大规模和更成熟的阶段，更多控制权就会变得重要。

Garimella 说，负责协调复杂搜索的主智能体使用前沿模型可能值得，但对 500 个账户的每项任务都使用它可能太贵。Actively 对部分工作使用更便宜的模型。他希望获得更多成本控制手段，例如批处理或弹性处理，而不是只能在两种方案之间全选或全不选。

他还希望找到提高响应速度的方法，例如预热隔离环境以减少启动延迟。在他看来，托管智能体目前特别适合需要前沿智能、运行数分钟且对成本或几秒钟延迟相对不敏感的困难任务。其他任务可能需要更多控制手段。

Garg 回到自建还是购买的问题：如果某项功能只有大幅降低成本或获得更多控制权才能实现，可能就需要自定义框架。他预计 Wispr 未来可能为语音控制的幕僚长助手自建框架，同时在其他地方继续使用托管基础设施。Olson 补充说，托管服务在验证可行性时也很有优势，因为实验成本还包括获得结论所需的时间。