AssemblyAI实战：AI客服Joey如何解决80%工单

从10%到80%：一个被volume压垮的工程师的自救

AssemblyAI的前向部署工程师（Forward-Deployed Engineer，简称FTE）Matt Lawler在一场技术大会上分享了一个颇具代表性的案例：他们如何用Claude Agent SDK从零构建了一个名叫Joey的AI客服代理，把工单的端到端解决率从10%一路拉到了80%。

问题的起点很现实。AssemblyAI主营语音AI基础设施，自研语音转文字（speech-to-text）基础模型，并逐步扩展到完整的语音代理（voice agent）技术栈。随着语音AI需求爆发，他们每天收到约1000个API注册申请。而在两天前，Matt还是公司里唯一的onboarding工程师。一个人对接每天1000个新注册用户，显然不可能。

FTE这个角色本身就强调深度服务——提交代码到客户仓库、每月甚至每周多次会议、理解客户的具体用例。这种一对一的服务模式质量高，但完全无法规模化。Matt给出了一个值得所有FTE深思的观点：你每天的工作目标应该是把自己自动化掉。如果你想在规模化的同时提供更好的客户体验，你自己就不能成为瓶颈。

买来的现成机器人为什么只能解决10%

团队最初的本能反应和很多公司一样——买一个现成的support bot，指向文档，期望它自动回答所有基础问题。结果令人失望：端到端解决率只有约10%。1000个对话里只有100个被机器人消化，团队仍然要处理剩下的900个工单。

更致命的是迭代速度。这个外采方案不开放system prompt、不开放工具调用、不开放RAG基础设施。每次想改点东西，供应商的回复都是"在roadmap上"。对于一个需要快速响应产品变化的团队来说，这种黑盒根本行不通。

于是他们决定自己造——与其招一个新员工，不如"建"一个新员工。Joey由此诞生。

Joey的四部分架构

Joey现在是所有inbound对话的第一道防线：无论你是通过网站聊天窗口、联系销售还是support邮箱，先遇到的都是Joey而非人类。它被设计成"可无限扩展的FTE"——能记住与你的历史对话，所有指标通过Pylon追踪（因为它仍然是支持团队的正式成员），并构建在Claude Agent SDK之上。它能管理自己的基础设施、拥有文件系统、读写和调试代码、调用工具，甚至给自己赋予新能力。

整个架构可以拆成四个核心部分：

文档以本地Markdown形式喂给Claude

Markdown是与Claude协作的最佳格式。团队把全部文档、更新日志、定价页等关键页面都转换成Markdown，本地checkout到仓库里。每次文档系统更新，这些文件也同步更新。这带来一个有意思的副产品：即使整个文档站点宕机，Joey依然能基于本地文件给出最新答案。

检索用Voyage嵌入

为了保证回答质量和速度，团队与Voyage合作使用其embeddings，让Joey能快速定位最相关的文档，减少搜索时间。由于所有文档都是本地文件，当Joey遇到需要串联多份资料的复杂问题时，它可以agentically地在文件系统里深度检索。

Voyage是一家专注于嵌入模型（embedding model）的AI公司，其核心产品是为检索增强生成（RAG，Retrieval-Augmented Generation）场景优化的向量化模型。RAG的基本原理是：将文档切分成片段，用嵌入模型将每个片段转换成高维向量并存储；当用户提问时，同样将问题向量化，在向量空间中找到语义最相近的文档片段，再将这些片段连同问题一起送入语言模型生成回答。相比直接将所有文档塞入上下文窗口，RAG能够处理远超上下文限制的知识库规模，同时降低token消耗和幻觉风险。AssemblyAI选择Voyage而非通用嵌入方案，主要是因为Voyage在技术文档、代码和API参考类内容的检索精度上有针对性优化，更适合开发者支持场景。

用Railway部署，30秒上线新版本

团队不想碰EC2、不想管理实例类型，直接把Joey部署在Railway上。好处是迭代极快：在Slack里发现一次糟糕的对话，写个PR、部署，30秒内就有一个新版本的Joey上线。他们甚至做到过实时监控一场对话、当场发现bug、部署修复，而客户全程无感知。

一个3万行的CLAUDE.md

所有指令以CLAUDE.md的形式提供，据Matt描述大约有3万行的guardrails和与客户沟通的建议。每当Joey给出错误答案或体验不佳，团队就更新这份文件，往后所有对话都会随之改善。整体打包成Docker文件，在Railway上一键容器化部署。

Claude Agent SDK（即Anthropic的代理开发工具包）是Anthropic为开发者提供的一套框架，允许开发者将Claude作为自主代理部署，使其能够管理工具调用、维护多轮对话状态、执行代码以及调用外部API。与直接调用Claude API不同，Agent SDK的核心设计理念是让模型在完成复杂任务时能够"自主规划步骤"——例如决定何时检索文档、何时调用工具、何时请求人工介入。这种架构特别适合客服场景，因为用户的问题往往不是单一的，而是需要跨越多个知识源和操作步骤才能解决。Pylon则是一个专为B2B客户成功团队设计的客户沟通与工单追踪平台，可以将来自Slack、邮件、聊天窗口等渠道的对话统一管理，并提供指标追踪功能。

CLAUDE.md是Anthropic为Claude代理设计的一种约定文件格式，类似于为代理提供"岗位说明书"和"行为手册"。当Claude Agent在某个项目或仓库中运行时，它会优先读取这个文件来理解自己的角色定义、行为边界（guardrails）、沟通风格要求以及特定场景下的处理规则。3万行的体量意味着团队将大量的边缘案例处理逻辑、客户沟通话术、产品知识和升级判断标准都编写进去，形成一个持续演化的"机构记忆"。这种以纯文本文件驱动代理行为的方式的优势在于：每次更新CLAUDE.md并部署，所有后续对话立即生效，不需要重新训练模型，实现了规则更新与模型能力的解耦。

结果：80%解决率，月成本约700美元

仅在部署的第一周，一个相当朴素的实现就把端到端解决率从10%推到了80%，总成本约为每月700美元（token加基础设施）。

Matt特别强调了这个数字的真实性。有些团队会"玩"指标——比如只在某个工单子集上宣称80%。但Joey的情况不同：除非你明确要求升级，否则你无法直接触达人类。Joey实际处理了100%的inbound工单，只把其中20%出于正当理由升级给人类——比如费率变更、数据退出训练、签署协议，或者只有FTE和法务才能介入的需求。

更妙的是，Joey无法处理的部分恰好构成了一张清晰的"团队扩展待办清单"。它发不了BAA？那就给它一个可引用的资源链接。它不能聊定价？那就让它学会报价——现在你去网站告诉Joey你有多少小时用量，它会直接给你报价，甚至可以和它讨价还价。

把自己的产品吃进去：dogfooding的意义

这个案例最值得玩味的不是省了多少人力，而是"自我验证"（dogfooding）的理念。AssemblyAI做语音，客户也在用它的API构建语音代理，所以Matt给Joey接上了语音能力。

现在Joey支持语音模式：speech in、speech out，一条WebSocket连接串起语音转文字、LLM和文字转语音，全部为语音场景优化。它处理停顿、打断、barge-in等交互细节，自带语音，工具调用与文本模式完全一致。团队还计划接入电话号码，让用户能随时打电话获得实时支持。

这里有一层"元"结构：当你用语音和Joey讨论如何构建语音代理API时，你本身已经在使用这个产品，直接看到了自己的产品体验会是什么样子。

Matt给出的核心结论直白而有力：如果你是FTE，就应该持续吃自己的狗粮。不要只教客户如何上手，而要亲自去构建客户正在构建的同类产品。他自己正是在给Joey加语音的过程中，撞上了延迟、轮次切换、打断处理这些真实的墙，才真正理解了用这套API的客户在经历什么，从而能给出更好的建议。

对于任何有FTE团队或正在考虑AI客服自动化的公司，Joey提供了一个可复制的范式：开放可控的架构、本地Markdown知识库、快速迭代的部署流水线，以及用升级清单驱动团队持续扩展能力。

Dogfooding（吃狗粮）是科技行业的一个惯用术语，源自"吃自己的狗粮"这个英文俚语，意指公司内部员工实际使用自家产品。这个概念在FTE（Forward-Deployed Engineer，前向部署工程师）角色中有特殊的战略意义：FTE的职责是深度嵌入客户环境、帮助客户成功落地产品，而不亲自使用产品的FTE往往只能给出理论建议，无法真正感知客户遇到的摩擦点。WebSocket是Joey语音模式的技术基础——它是一种在单个TCP连接上建立全双工通信的协议，允许服务器和客户端之间持续、低延迟地双向传输数据，非常适合实时语音流这类对时延极度敏感的场景。传统的HTTP请求-响应模式无法支撑语音的连续性，而WebSocket可以保持一条长连接，持续传输音频数据帧。