我们造了一个能解决 80% 工单的 AI 客服 Agent——Matt Lawler(AssemblyAI)

• Matt Lawler 是 AssemblyAI 的 FDE（forward deployed engineer，前线部署工程师，被「派」到客户那边一起把东西做出来的工程师），主要承接 inbound 客户（主动找上门的客户）；幻灯片标题页上的头衔是 Lead Forward Deployed Engineer, Onboarding。立场先交代：这是一场厂商演讲，数字都是他讲的自家团队数据，后半段演示用的也是自家的 Voice Agent API。演讲在现场的原题是「FDE Playbook」，YouTube 标题是频道另起的。 → 详细
• AssemblyAI 做语音 AI 基础设施，自己训练基础模型，主要是语音转文字：开会时进来的 Fireflies 会议记录助手，转写稿就出自他们；电话客服 agent、免下车点餐这类实时场景，讲者称多半也是用他们的模型搭的（幻灯片上另列了 Cluely、Granola 两个客户例子，口述没提）。 → 详细
• 他们还卖一个 Voice Agent API，把语音转文字、LLM、文字转语音串成一个接口。讲者称现在每天约 1,000 个 API 注册（幻灯片上也写着这个数），而「至少到两天前为止」他是公司唯一的 onboarding 工程师（负责把新客户带上手的人）——这就是整场演讲的起因。 → 详细

• 他说 FDE 是个什么都能往里装的头衔，各家差别很大。在 AssemblyAI 是被部署到客户那边：吃透对方的场景、经常直接往客户的仓库里提交代码、一个月开好几次会甚至一周好几次，技术和商务上的事客户都找这一个人，由他负责拿下生意、建立信任。幻灯片压成三步：嵌进客户 → 定制到合身 → 赢下生意。 → 详细
• 问题出在算术上：每天 1,000 个注册，一个人没法一对多地上这么多通电话，不是每一单都能亲手做出来，也不能靠一直加招 FDE 来解；他要的是把人腾出来，去带真需要真人主导的单子。幻灯片过渡页写的是「Great services model. Doesn't scale.」（FDE 的其他讲法见 ep106、ep107；同批 262 讲的是 FDE 进别人公司改流程。） → 详细

• 他给在座的 FDE、想当 FDE 的人、公司里有 FDE 团队的人同一条建议：把做 FDE 攒下的知识拿出来， "try to automate yourself out of a job" （想办法把自己的工作自动化掉）。Matt 的原话是「我觉得这应该是你每天的职责」。理由是：想在规模化的前提下把客户体验做好，你自己就不能是好体验的瓶颈——他说这是他们亲身领教过的。幻灯片底注把它落成动作：用你的 FDE 知识分流更多对话，把自己腾给更高价值的工作。 → 详细

• 起点是一个很常见的本能反应：被 inbound 的量淹没了，只想少跟一些人聊。于是他们买了一个现成的客服机器人，让它对着文档答题，以为从此不用再回答简单问题。 → 详细
• 结果它只端到端解决了约 10% 的对话（端到端解决，指从头到尾没有真人介入就把问题了结）。他给的算术是：假如一天 1,000 个对话，机器人接走 100 个，团队每天还是得处理 900 张工单，谈不上能规模化。幻灯片上的横条图是约 10% 端到端解决、约 90% 直接升级给真人；这家机器人的厂商名，口述和幻灯片都没点。 → 详细
• 比 10% 更要命的是没法迭代。他点了三样碰不到的东西：system prompt（给模型定身份和规矩的那段底层指令）、工具、RAG 基础设施（先检索资料再回答的那套管道）。Matt 的原话是「我们碰不到 system prompt，碰不到工具，碰不到 RAG 基础设施」。每次想改点什么去找供应商，得到的回答都是「这个在路线图上了」。幻灯片的总结是：他们需要控制权，和一份自己的路线图。所以决定自己造。 → 详细

▲ 图注：幻灯片「A tiny team, drowning in inbound」：一根横条，蓝色小段标着约 10% 端到端解决，灰色大段标着约 90% 直接升级给真人；底部一行写着他们迭代得不够快，需要控制权和自己的路线图。

• 他们没有再招人，而是给团队造了一位新成员，起名 Joey。现在不管你是在官网聊天窗口提问、联系销售，还是发信到 support 邮箱，先遇到的都是 Joey 而不是真人——他是所有 inbound 对话的「第一道防线」，定位是团队里最能无限扩展的那个 FDE。幻灯片上还写着：聊天窗口全天候挂在官网每一页上。 → 详细
• 他被当成客服团队的正式一员来管：记得之前跟你聊过什么；所有指标通过 Pylon（他们用的工单平台）追踪，他自己也有 Pylon 的权限，用来管理对话、记住你是谁。（agent 记忆这个话题另见 ep22。） → 详细
• Joey 搭在 Claude Agent SDK 之上。Matt 列的能力是：能管理自己的基础设施、有一个文件系统、能替你写代码和调试代码、能调用工具、还能给自己添加新能力——所以干起活来更像一个 FDE，而不像如今大多数网站上那种标准聊天机器人。 → 详细

• Matt 说这套架构大致有四个主要部分，幻灯片上对应四张编号卡片：本地 markdown 文档、Tier 1 检索、Tier 2 Deep mode、部署在 Railway。那份 CLAUDE.md 不在这四张卡里，是后面代码走读时才讲的（见下一个主题）。 → 详细
• 第一件：文档当本地文件。他的说法是「Markdown 是你的好朋友」：把 markdown 文件交给 Claude，让他了解你业务的方方面面。落到他们自己身上，Matt 的原话是「我们把所有文档都 check out 成本地 markdown，交给了 Joey」。check out 就是从文档系统拉一份副本下来，放进 Joey 自己的文件系统；文档每推一次更新，他那边的文件就跟着更新。好处他举得很具体：就算整个文档站现在挂了，去问 Joey 照样能拿到关于最新上线功能的回答，不需要团队出面。 → 详细
• 代码走读时他补了两个细节。一是范围：不只是 API 文档，新功能、changelog（更新日志）、定价这些官网主要页面全都转成 markdown 交给 Joey；屏幕上的文件树里还能看到服务协议、隐私、安全、SLA 这类法务与合规页面的目录。二是出处：Joey 能看到每份文件对应的网址，回答时可以向客户注明来源，方便对方核对或接着往下读（屏幕上，文件第一行就是一条记着来源网址的注释）。 → 详细
• 第二件：先用 embedding 把最相关的文档捞上来。embedding 是把一段文字变成一串数字，好按「意思相近」来找内容。他们用的是合作方 Voyage 的 embedding，让 Joey 一上来就拿到最相关的文档，不用花很多时间去搜，回答更快。幻灯片把这条路叫「Tier 1 — Retrieval」，写的是语义 + 关键词的混合检索——混合检索和 Tier 这套叫法都只在幻灯片上，口述没说。 → 详细
• 第三件：搞不定再让 agent 自己翻文件。文档就在他本地，所以当他搞糊涂了，或者要把多份资料串起来才拼得出回答时，可以对自己所在的文件系统做 agentic 搜索（不是一次检索定生死，而是像人一样一步步找、读、再找），进入他说的类似深度思考的模式。幻灯片把这条路叫「Tier 2 — Deep mode」，写的是难题会交给一个能搜网页、能写并测试代码的 agent；这两点口述在这一段没提，两边并列记在这里。 → 详细

▲ 图注：幻灯片「Show-the-work: the architecture」：四张编号卡片依次是 Docs as local markdown、Tier 1 — Retrieval、Tier 2 — Deep mode、Ship on Railway；副题写着两条回答路径、保持最新的文档和 30 秒的部署回路。

• 所有护栏（guardrails，规定什么能说、什么不能做的规则）和「该怎么跟客户打交道」的建议，都写在一份 CLAUDE.md 指令文件里。他的原话是「我记得那是一份大概 3 万行的 CLAUDE.md」——这是口头估计，屏幕上只露出了文件开头二十几行，看不到总行数。画面里能辨出大意的部分：开头给 Joey 定身份（AssemblyAI 的客服助手），接着是一串「绝不要输出」的清单，比如内部推理过程、工具名和文件路径、分类标签这类只该留在后台的东西。 → 详细
• 这份文件就是他们的主要迭代对象。每当发现 Joey 跟某个客户聊得不好，或者给了一个错误答案，他们就给这份 CLAUDE.md 发一次更新，此后他的每一场对话都带着这条修正。换句话说，纠错靠的是往一份文字规则里加一条，不用等供应商排期。 → 详细
• 部署选 Railway（一个托管部署平台），理由很直白：不想折腾基础设施，不想起一台 EC2（亚马逊的云服务器），也不想到时候还得换实例类型。整套东西装在一个 Dockerfile 里，往仓库发一次更新，新版本就自动上线，不需要谁手动盯着部署。屏幕上的文件树里还能看到名为 evals 和 tests 的目录，但他们怎么评测 Joey，演讲里没有讲。 → 详细
• 闭环有多快：他们在 Slack 里就能看到 Joey 是不是跟谁聊得不好，很快写一个 PR（代码改动申请）、部署上去，Matt 的原话是「30 秒之内就有一个新版本的 Joey 在线上跑了」。他讲了真事：有过盯着一场正在进行的对话、逮到一个 bug、部署修复，这场对话剩下的部分用的就已经是改好的版本，而那位客户完全不必知道幕后发生过什么。他的总结是，Joey 做的每一件事他们都有完全的掌控——正好对上现成机器人那里什么都碰不到的痛。 → 详细

▲ 图注：代码走读画面：左侧文件树能看到 docs 目录下的各个子目录，以及 bot.py、CLAUDE.md、Dockerfile、railway.toml 等文件；编辑器里打开的是 CLAUDE.md，首行标题为 Pylon Support Bot。画面小字偏糊，只能辨出大意。

• 讲者称，端到端解决率从 10% 升到 80%，是在这个版本上线的头一个星期里做到的，实现方式还「相当朴素」。幻灯片这一页的小标就是「RESULTS · WEEK ONE」，副题补了半句口述没有的：先用一周做到，之后靠持续迭代把它保持住。这是厂商自述；「解决」具体怎么判定，演讲里没有讲。 → 详细
• 成本：token 与基础设施成本合计约每月 700 美元（他说这句时自己改了一次口，先说 token 加推理，又改成基础设施）。幻灯片上只有一张卡写着约 700 美元跑全部，没有拆分，也没有工单总量或对比的人力成本——所以这是一个总数，算不出单张工单的成本。 → 详细
• 他特意堵了「挑分母」这个口子。他说有些人喜欢在这类指标上玩花样，报一个 80%，其实只算了某几类工单；他们不是这样。依据是入口设计，Matt 的原话是「你没法直接找到真人，除非先经过 Joey，并且明确让他升级」，所以进来的工单 100% 都由他先接。幻灯片上四张数字卡正是这套口径：80% 端到端解决（无人介入）/ 100% 首次接触都先过 Joey（没有跳过他直达真人的路）/ 约 20% 升级给人 / 每月约 700 美元。 → 详细

▲ 图注：幻灯片「RESULTS · WEEK ONE」：标题是 From 10% to 80% — for ~$700/month，四张数字卡分别是 80% 端到端解决、100% 首次接触先过 Joey、约 20% 升级给人、每月约 700 美元；底部黑条写着 Joey 还做不了的事就是下一步要自动化的清单。

• 那 20% 升级给人的，他说都有正当理由，举了几类：要调整费率（原词 rate change，也可能指调用限额，听不准）、要做 data opt-out（数据退出，即要求自己的数据不被另作他用）、要跟他们签一份协议、或者需求只能由 FDE 或法务的人介入。他的判断是：这些事眼下还需要人，但最终都能自动化掉。 → 详细
• 升级清单就是路线图。他说这是整件事最妙的地方：凡是 Joey 现在还做不了的事，Matt 的原话是「就等于给了我们一张非常清晰的清单」，告诉团队接下来该做什么才能继续扩展（幻灯片底部黑条写的是同一句话）。和买现成机器人时正好对照——那时候路线图在供应商手里，现在升级记录就是自己的路线图。 → 详细
• 两个已经照这张清单补上的例子：Joey 没法给客户发 BAA（涉及医疗数据时要签的一种合规协议，后面演示里会出现）——那就给他一个可以当资料引用的链接；Joey 没法谈价格——现在可以了，你告诉他自己有多少小时的量，他会报一个费率，你还能跟他砍价。Matt 说原本要升级的事已经自动化了不少，后面还有很多要做。 → 详细

• 动机：他不想只做一个替团队挡问题的东西，也不想做一个谁都做得出来的通用客服机器人——他们是做语音的，客户做的是 voice agent，所以他要自己做一个。Voice Agent API 是演讲当周才接进 Joey 的，官网上可以切到语音模式直接说话。 → 详细
• 形态：语音进、语音出，只用一条 WebSocket 连接（让浏览器和服务器保持长连接、双向实时传数据的通道），里面串起自家的语音转文字模型、一个 LLM 和文字转语音；讲者称实时、低延迟。 → 详细
• 停顿、打断、barge-in（用户在 agent 说话时插话）都由 API 代为处理；音色自带，不用再找别的供应商；能调的工具和用文字时完全一样（幻灯片上写的是他的 MCP 工具现在能用语音调，MCP 这个词口述没说）。下一步是顺利的话当周晚些时候给他接上一个电话号码。 → 详细

▲ 图注：幻灯片「Joey gets a voice」：四张卡的标题分别是 Speech in, speech out、Real-time, low latency、Our own voices、Same tools, by voice；第一张卡的小字写着 One WebSocket 和 STT、LLM、TTS。

• Matt 是在本地模拟的：在座的人会后多半会去试 Joey，他不想给真正的支持团队队列再添负担。Joey（agent 的合成语音）先开口，自报家门并问有什么可以帮忙。 → 详细
• Matt 的问题：想用 AssemblyAI 做一个 ambient medical scribe（在诊室里旁听医患对话、自动生成病历的工具），但开始测试前得先签一份 BAA（Business Associate Agreement，业务伙伴协议，美国医疗隐私法规 HIPAA 要求处理病人数据的供应商签的那份协议），问 Joey 能不能办。 → 详细
• Joey 的回答（合成语音，以下是转述）：先说要查一下，随后给了四点——可以，现在就能自己把 BAA 签掉，填完标准的 HIPAA 业务伙伴协议即可；前提是先有一个绑了卡的付费账户；签署 BAA 会自动退出模型训练；相关文档的链接已放在聊天里。这正是主题九里那条「发不了 BAA 就给他一个可引用的链接」补上之后的样子。 → 详细
• 两边道别（Joey 还祝他演示顺利）之后，Matt 借这段对话做了个对比：两年前他刚进 AssemblyAI 支持团队时，这样的问题必须由真人处理，支持工程师没法马上回，客户只能等，等来的还是套话；现在这类基础问题有一个 24/7 能聊的「FDE」。还有一层 meta 的意思：你用语音问 Joey 怎么用 Voice Agent API，其实已经在用它了。 → 详细

▲ 图注：现场语音演示的聊天窗口（两个时刻左右拼图）：左边是 Joey 的问候和讲者口述被转成的紫色提问气泡，右边是 Joey 的回答气泡，下方挂着两枚来源标签。画面原本很小，放大后字是糊的。

• 他的核心主张：不管你在客户那边部署了多久、嵌得多深，要理解客户在做什么，Matt 的原话是「最好的办法就是自己动手把他们那个产品也做一遍」。dogfood 的字面意思是「吃自家的狗粮」，即自家产品自己先当真用户用。 → 详细
• 他说如果这场演讲只带走一件事，不只是去做一个自己的 Joey，而是：做 FDE 就得一直 dogfood 自家产品，光教客户怎么上手不够，每个新功能、新产品都要带着亲手用过、搭过、发布过攒下的认识去教。他自己也是这么过来的，Matt 的原话是「同样的墙我都得一堵一堵撞过去」：延迟、turn-taking（轮流发言，判断该谁说话）、barge-in、打断处理，所以现在给客户的建议更准，也更能体会他们的处境。幻灯片上多强调了一句：用的是客户用的同一个 API，没有内部捷径。 → 详细
• 收尾号召：去动手做点什么，做自己的 Joey 也好、做 voice agent 也好（他顺带说，要做 voice agent 就在 AssemblyAI 上做）；干 FDE 这份活的，就把客户在做的产品原样自己做一遍，别光等客户来求助——顺带还可能把自家的客户体验也做好。幻灯片结尾页把全场压成三句：找出重复的活、把你的工具交给 agent、去做你客户在做的东西。 → 详细

• 现场：Matt 说会后可以到 AssemblyAI 的展位找他，问 Joey 是怎么搭的；他还特意征集反馈——如果你跟 Joey 聊出了奇怪的对话，告诉他，他们会接着修，他也可以当场演示怎么部署上线。 → 详细
• 幻灯片结尾页写着两个入口：到 assemblyai.com 可以直接和 Joey 对话；Voice Agent API 的文档在 assemblyai.com/docs/voice-agents。口述没有念这两个网址，也没有给个人联系方式。 → 详细