Frigade Assist API：让AI客服从甩文档变成指哪打哪

当AI客服「看不见」屏幕时会发生什么

如今几乎每款SaaS产品都内嵌了AI助手，但当用户问出「我该怎么操作」时，绝大多数AI客服给出的答案是一整段密密麻麻的文字说明。用户读完还得自己在界面上逐个按钮寻找，体验割裂而低效。

问题的根源在于：这些内嵌的AI Agent根本「看不见」屏幕。它们大多基于RAG（Retrieval-Augmented Generation，检索增强生成）架构运作——将产品文档、帮助中心文章等切分为文本块，通过向量嵌入模型转化为高维向量存入向量数据库；当用户提问时，先将问题向量化，在向量库中检索最相关的文档片段，再将这些片段作为上下文连同用户问题一起输入LLM生成回答。

RAG架构自2020年由Meta AI团队（Lewis等人）在论文中正式提出以来，已成为企业级AI应用的标准范式。其核心流程包含索引（Indexing）、检索（Retrieval）和生成（Generation）三个阶段。在索引阶段，文档经过分块（Chunking）处理——分块策略的选择（固定长度、语义分割、递归分割等）直接影响检索质量。向量嵌入模型（如OpenAI的text-embedding-3、Cohere的Embed v3）将文本块映射到高维向量空间，语义相似的内容在向量空间中距离更近。向量数据库（如Pinecone、Weaviate、Qdrant、Chroma）则负责高效的近似最近邻（ANN）检索。尽管业界已发展出多种改进方案——如HyDE（假设性文档嵌入，通过先让LLM生成假设性答案再用其检索）、多路召回、重排序（Reranking）、GraphRAG（微软提出的结合知识图谱的检索方案）等——但RAG的根本输出形态始终是文本。

RAG解决了LLM知识截止日期和企业专有知识的问题，但它的根本局限在于输出形式——无论检索到多精确的文档，最终输出仍是文本。对于「如何操作」类问题，文本回答与用户的实际操作界面之间存在认知鸿沟，用户需要自行将文字指令映射到界面元素上。这些AI客服无法感知用户当前所处的界面状态，更无法告诉用户「点这里」。这正是Frigade Assist API试图解决的核心痛点。

近日在Product Hunt上线的Frigade Assist API，以78票的成绩排在当日榜单第16位，被归类于「客户成功」「人工智能」「SDK」三个领域，切中了AI客服体验升级的关键环节。

一次工具调用，让Agent学会「指路」

核心机制：引导+文本兜底+界面感知

Frigade Assist API的设计哲学非常克制——它不是要替换你现有的AI Agent，而是作为Agent可以调用的**一个工具（tool call）**存在。

这里有必要展开解释「工具调用」这一关键概念。工具调用（Tool Call / Function Calling）是当前大语言模型应用架构中的核心机制。传统的LLM只能生成文本，而通过工具调用，LLM可以在对话过程中识别出需要外部能力的场景，并以结构化的方式请求调用预定义的外部函数或API。OpenAI在2023年6月率先推出Function Calling，允许开发者在API请求中定义函数签名，模型会在合适的时机生成结构化的调用参数；随后Anthropic在Claude中引入Tool Use，Google在Gemini中推出Function Calling，各家实现细节不同但核心理念一致。

在Agent框架中，开发者会预先注册一系列「工具」——每个工具有名称、描述和参数定义——LLM根据用户意图自主决定是否调用、调用哪个工具、传入什么参数。在实际工程实践中，工具接口通常采用JSON Schema描述，LLM在推理过程中生成结构化的调用请求，运行时环境负责实际执行并将结果返回给LLM进行下一步推理。这一「思考-调用-整合」的循环是ReAct（Reasoning + Acting）范式的核心。ReAct范式由Yao等人在2022年的论文中正式提出，其核心思想是将LLM的推理能力与行动能力交织执行——在此之前，Chain-of-Thought（思维链）只解决了推理问题，而ReAct则让模型能够在推理过程中主动与外部环境交互。这一范式催生了LangChain、CrewAI、AutoGen等Agent框架的蓬勃发展，也是当前Agent系统的主流架构模式。值得注意的是，Anthropic主导提出的MCP（Model Context Protocol）协议正在推动工具调用接口的标准化，旨在为AI模型与外部工具之间建立统一的通信协议，进一步降低工具集成的碎片化问题。

Frigade正是利用这一机制，将自己定位为Agent工具箱中的一件新工具，而非替代整个Agent系统。这种「插件式」的设计理念，让它天然适配各种已有的Agent架构。

当用户提出操作类问题时，你现有的Agent只需发起一次对Frigade的工具调用，Frigade就会完成三件事：

• 在页面上直接绘制分步引导：不再是文字描述，而是在真实界面上高亮指引，一步步告诉用户该点哪里；
• 在无法可视化引导时，返回纯文本答案：当引导不适用时，Frigade会把清晰的文字回复交还给Agent，保证对话不会「断链」；
• 告诉Agent用户正在看什么：这一点尤为关键，Frigade为Agent补上了「屏幕感知」这块拼图，让Agent理解用户当前的界面上下文。

这种三段式设计，让AI客服从「答题机器」升级为真正能带着用户完成任务的操作向导。

与现有技术栈的兼容性

在集成层面，Frigade Assist API展现出良好的开放性。官方明确表示它可以与Vercel AI SDK协同工作，也支持任何具备工具调用能力的框架。

Vercel AI SDK是由Next.js背后的公司Vercel推出的开源SDK，旨在帮助前端开发者快速构建AI驱动的应用。它提供了统一的接口来对接OpenAI、Anthropic、Google等多家模型提供商，并原生支持流式响应（Streaming）、工具调用、结构化输出等能力。由于Vercel生态在现代Web开发中占据重要地位——Next.js是React框架中部署量最大的全栈方案之一，被Netflix、TikTok、Notion等大量知名产品采用——与Vercel AI SDK的兼容意味着Frigade可以无缝融入大量已有的SaaS产品技术栈，覆盖广泛的开发者群体。除Vercel AI SDK外，LangChain、LlamaIndex等主流Agent框架同样支持工具调用机制，这为Frigade的适配范围提供了更大的想象空间。

开发者无需重构现有的Agent架构，只需将Frigade作为一个可调用的工具接入即可，迁移成本极低。

产品知识从何而来：浏览器Agent自动学习

这可能是Frigade最有意思的技术亮点。传统的产品引导工具依赖人工配置每一个步骤，工作量巨大且难以维护。而Frigade宣称它「懂你的产品」，原因是——浏览器Agent已经先用过一遍你的产品了。

换言之，Frigade通过浏览器自动化Agent实际操作产品界面，自动学习产品的功能路径与交互逻辑，从而构建出可用于引导的知识库。

浏览器自动化Agent是近年来快速发展的技术方向，经历了从脚本驱动到AI驱动的范式转变。第一代以Selenium（2004年）为代表，通过WebDriver协议与浏览器交互，需要精确的元素定位和预编写脚本。第二代以Playwright（Microsoft, 2020）和Puppeteer（Google, 2017）为代表，提供了更现代的API和更好的异步支持，广泛应用于自动化测试和网页抓取场景，但仍依赖确定性脚本。第三代则是AI原生方案：Anthropic的Computer Use（2024年10月发布）通过截图+坐标点击实现通用计算机操作；WebVoyager（2024年）结合视觉和DOM信息在真实网站上完成复杂任务；Browser Use（开源项目）则提供了可编程的AI浏览器Agent框架；OpenAI的Operator同样瞄准了自主浏览器操作场景。这些方案的核心技术栈通常包括：CDP（Chrome DevTools Protocol）或WebDriver BiDi用于浏览器通信、多模态视觉模型用于界面理解、以及任务规划器（Task Planner）用于将高层目标分解为具体操作序列。SWE-agent（用于自动化软件工程任务）的成功也证明了AI Agent在理解和操作复杂界面方面的巨大潜力。

其中，DOM（Document Object Model，文档对象模型）解析值得特别说明。DOM是浏览器将HTML文档解析后生成的树状结构，每个HTML标签（按钮、输入框、链接等）都是DOM树中的一个节点，携带着标签类型、属性（id、class、aria-label等）、文本内容、位置坐标等信息。传统引导工具通过CSS选择器（如 #submit-btn 或 .nav-menu > li:first-child）来定位界面元素，但这种硬编码方式极度脆弱——前端代码重构、组件库升级、甚至样式微调都可能导致选择器失效。新一代AI驱动的方案则结合语义理解：通过分析元素的可访问性标签（ARIA attributes）、上下文文本、视觉位置等多维信息来识别元素，即使底层HTML结构变化，只要元素的语义角色不变，仍能正确定位。这种「语义定位」与「结构定位」的区别，是Frigade自动学习机制能够适应产品迭代的关键技术基础之一。

Frigade利用类似技术自动「试用」客户产品，本质上是将浏览器Agent从「替人操作」转向「替人学习」——它不是替用户完成任务，而是通过自动探索来构建产品知识图谱，记录每个功能的访问路径、页面元素的位置与含义、以及操作之间的逻辑关系，然后用这些结构化知识来指导真实用户完成操作。

这套机制解决了产品引导工具最头疼的维护难题：

「它每次发版都会重新学习。」

这句话点出了产品引导领域的长期痛点。产品引导工具并非新概念，这一赛道已有超过十年的发展历史。更完整地看，这一赛道可划分为三个技术代际：

**第一代（2011-2017年）**以WalkMe为代表，核心是「数字采用平台」（Digital Adoption Platform, DAP），主要面向企业内部软件培训，帮助员工学习使用Salesforce、SAP等复杂系统。WalkMe于2011年成立，2021年以15亿美元被SAP收购，这一收购价格也侧面验证了该赛道的商业价值。

**第二代（2017-2023年）**以Pendo（累计融资超4.5亿美元）、Appcues、Userflow、Chameleon为代表，将产品分析与引导合二为一，更聚焦于SaaS产品的用户增长场景，强调无代码配置和数据驱动的引导优化。这些工具通常采用「无代码配置」模式：产品经理或客户成功团队在可视化编辑器中选定页面元素（通常通过CSS选择器或XPath定位），设置触发条件和引导步骤，生成弹窗提示（tooltip）、高亮指引（spotlight）或检查清单（checklist）。

**第三代（2023年至今）**则以AI原生为特征，Frigade、CommandBar（已获a16z投资）等新玩家开始探索AI驱动的动态引导。Gartner在2023年将DAP列为重要技术品类，估计全球市场规模超过20亿美元并以年化30%以上的速度增长。值得注意的是，第三代产品的竞争维度已从「配置效率」转向「智能程度」——不再比谁的拖拽编辑器更好用，而是比谁的AI更能理解产品、更能理解用户意图。

然而传统无代码配置模式的最大痛点在于维护成本——现代SaaS产品的迭代速度通常以周甚至天为单位，每当产品界面改版，CSS选择器失效、页面结构变化、新功能上线都可能导致已配置的引导流程失效或指向错误位置，需要人工逐一排查和重新配置。据行业反馈，一些大型企业仅维护产品引导流程就需要专职团队。Frigade通过浏览器Agent自动学习来替代人工配置，并在每次产品发版后自动重新学习，本质上是用AI能力解决了这一代产品引导工具最根本的可维护性问题，将运维负担从持续的人力投入转化为一次性的技术集成。

Frigade切中了怎样的行业趋势

从「对话」到「操作」的AI Agent演进

Frigade Assist API的出现，反映出AI Agent正在从「能对话」向「能操作」演进的大趋势。过去一年，业界对Agent的想象大多停留在文本交互层面；而Frigade代表的方向，是让Agent深度嵌入产品界面，成为用户操作的「实时向导」。

更具体地看，AI Agent的能力演进可以划分为几个层次：第一层是文本对话，即基于知识库的问答（如传统RAG方案，通过检索增强生成来回答用户问题）；第二层是信息整合，Agent能调用搜索、数据库、API等工具获取实时信息并综合回复；第三层是界面感知，Agent能理解用户当前的操作上下文，知道用户在看什么页面、处于什么操作阶段；第四层是自主操作，Agent能直接代替用户完成界面操作，如自动填写表单、点击按钮、执行工作流。

Frigade目前主要覆盖第三层——它让Agent「看到」用户界面并提供可视化引导，但最终的点击和操作仍由用户完成。而像Anthropic Computer Use、Adept ACT-1（Adept AI成立于2022年，由前Google Brain研究员创立，专注于构建能够在软件界面中自主操作的AI Agent，后被Amazon收购）这样的方案则直指第四层，试图让AI完全接管用户界面操作。值得注意的是，在SaaS客服场景中，第三层可能比第四层更具实用价值——用户通常希望自己掌控操作过程，理解每一步在做什么，而非将操作权完全交给AI。这不仅涉及用户信任问题，也关乎用户能否真正学会产品使用，从而降低未来的重复求助率。这一设计选择呼应了人机交互领域的经典原则——Shneiderman的「直接操纵」理论强调用户应当感知到对操作过程的掌控感，而Horvitz的「混合主动性交互」（Mixed-Initiative Interaction）则认为AI与人类应当动态分配控制权，而非由AI完全接管。

这背后是一个朴素的洞察：用户要的往往不是「答案」，而是「结果」。与其给用户一段说明书，不如直接带他完成操作。

客户成功场景的新工具

说个细节，Frigade被明确归入「客户成功（Customer Success）」类别。这说明它的价值主张不仅是技术层面的创新，更指向实实在在的商业收益——降低用户的学习门槛、提升SaaS产品激活率与留存率、减少客服工单量。

这些指标的商业意义值得展开。在SaaS增长框架中，用户旅程通常被建模为一个漏斗：注册 → Setup（初始配置）→ Aha Moment（首次体验核心价值）→ Habit（形成使用习惯）→ 付费转化/续费。Sean Ellis和Hiten Shah等增长专家反复强调，Aha Moment是整个漏斗中最关键的转折点——Facebook早期发现「7天内添加10个好友」是预测留存的核心指标，Slack发现「团队发送2000条消息」是付费转化的强信号，Dropbox则将「在一台设备上安装客户端并上传一个文件」作为其Aha Moment。对于B2B SaaS产品来说，用户能否快速抵达Aha Moment往往取决于产品的操作引导质量。

从SaaS经济学的角度看，这些指标构成了一个紧密关联的价值链。CAC（Customer Acquisition Cost，客户获取成本）、LTV（Lifetime Value，用户生命周期价值）、LTV/CAC比率（健康值通常>3）是SaaS商业模型的基础三角。激活率的提升具有杠杆效应：激活率每提升10个百分点，在其他条件不变时，可能带来同等比例的LTV提升，因为更多用户转化为活跃付费用户。Mixpanel、Amplitude等产品分析平台的数据显示，完成Onboarding引导的用户，其30天留存率通常比未完成的用户高出50%-200%。

根据行业数据，SaaS产品的平均激活率（用户从注册到完成核心操作的比例）通常在20%-40%之间，意味着超过一半的新用户在真正体验到产品价值之前就已流失。这一指标直接影响用户生命周期价值和获客投资回报率。而在客服侧，工单的平均处理成本约为5-15美元/次（视复杂度和人力成本而定），其中相当比例属于「如何操作」「在哪里设置」类的低复杂度问题——这类问题恰恰是可视化引导最擅长解决的。如果AI客服能够通过可视化引导直接解决这类问题，不仅能显著降低工单量（业内通常以工单偏转率/Ticket Deflection Rate来衡量，Zendesk等客服平台的数据显示优秀的自助服务体系可以将偏转率提升至60%-80%），更重要的是缩短了用户的「价值发现时间」（Time to Value, TTV）——即用户从初次接触产品到首次感受到产品核心价值的时间。TTV被普遍认为是影响SaaS留存率的最关键因素之一，直接关联着用户是否会在试用期结束后转为付费客户。Gainsight等客户成功平台的行业报告也指出，B2B SaaS客户流失的首要原因并非产品功能不足，而是客户未能充分利用已有功能——这进一步印证了操作引导的商业价值。

Frigade的创新还在于将引导从「预设的固定流程」变为「按需响应的动态引导」——用户在任何操作环节遇到困难时，AI客服都能即时提供针对性的可视化指引，而非只在首次登录时展示一遍固定的引导流程。这种「即时性」意味着引导不再局限于Onboarding阶段，而是贯穿用户的整个生命周期，从新手引导延伸到高级功能探索和复杂操作辅助。

对于SaaS企业而言，这些都是可量化、可直接对标收入增长的核心指标。Forrester Research估计，改善客户体验每投入1美元可带来约100美元的回报，而操作引导作为客户体验的关键触点，其投资回报率往往更高。

潜在的疑问与观察

尽管产品理念清晰，仍有几个问题值得关注：

首先是浏览器Agent自动学习机制的准确性。自动学习虽然省去人工配置，但复杂产品的边缘操作路径能否被完整、准确地捕捉，仍需实践检验。尤其是涉及权限控制（不同角色看到的界面可能完全不同）、多角色视图（管理员与普通用户的操作路径差异）、条件分支（某些功能只在特定配置下出现）等复杂交互场景时，浏览器Agent是否能正确理解并记录所有可能的操作路径，是一个值得观察的技术挑战。此外，动态内容（如根据用户数据变化的仪表盘）和异步加载的界面元素也可能增加自动学习的难度。从技术实现角度看，浏览器Agent的探索策略（是广度优先还是深度优先、如何处理需要特定前置条件才能触发的功能分支、如何应对A/B测试导致的界面差异）将直接决定其知识库的完整性和准确性。值得关注的是，类似的「自动探索」问题在软件测试领域已有大量研究——Google的Monkey测试框架和学术界的GUI自动化测试方法在覆盖率提升方面积累了丰富经验，但从「测试覆盖」到「知识建构」仍有本质区别，后者需要理解操作的语义而非仅仅执行操作。

其次是可视化引导的适用边界。官方也坦承，存在「无法可视化引导」的场景，此时只能退回文本答案。这条兜底逻辑的触发频率，直接决定了用户体验的上限。例如涉及跨系统操作（如需要在CRM和邮件系统间切换完成的工作流）、后台任务配置（如cron job设置、webhook配置等需要理解概念而非简单点击的操作）、或需要先理解概念再操作的场景（如数据模型设计、权限策略规划），可视化引导可能力不从心。此外，对于高度定制化的企业部署——使用自定义组件库、嵌入iframe的第三方模块、或Shadow DOM封装的Web Components——浏览器Agent能否正确解析和交互也是一个技术细节问题。

最后是多平台适配能力。目前披露的信息主要围绕Web端的浏览器界面，对于桌面应用（如Electron应用）或移动端（iOS/Android原生应用或React Native/Flutter等跨平台方案）的引导支持尚不明确。随着SaaS产品越来越多地提供移动端体验，跨平台的引导能力可能成为未来竞争的重要维度。移动端的引导面临独特挑战：屏幕空间更小、交互模式不同（手势操作 vs. 鼠标点击）、且原生应用的界面结构（如iOS的UIKit / SwiftUI或Android的View / Compose系统）与Web DOM完全不同，浏览器Agent的技术方案无法直接复用。

结语

Frigade Assist API抓住了一个真实且普遍的痛点：内嵌AI客服「看不见屏幕、只会甩文档」。它用「一次工具调用」的轻量集成方式，加上「浏览器Agent自动学习产品」的巧妙设计，为AI客服补上了界面感知与可视化引导的能力。

在AI Agent能力快速外扩的当下，这类专注于「让AI真正带着用户操作」的产品引导工具，或许比又一个通用对话模型更贴近SaaS产品与用户的实际需求。

核心要点

核心要点