Why Decagon's Founders Don't Believe the Labs Are the Last Startups

小模型不只更便宜，还能赢过前沿模型

Decagon 创始团队成员 Jesse 与 Asha，讲的是企业级 AI Agent 最容易被误解的一面：客户看到的是一个能接电话、能回答问题的客服 Agent，背后却是一套模型分工、评测、部署、销售和持续改进的机器。Asha 曾在 Palantir 任 deployment strategist，熟悉大型企业怎样把新技术塞进合规、权限和遗留系统的缝隙里。如今 Decagon 服务银行、航空公司和电信企业，90% 工作流已运行在开源模型——也就是企业能自行部署和改造的模型——上。

这场对话最有意思的地方，不是争论“开源会不会取代闭源”，而是把企业 AI 的账本摊开：什么该用小模型，什么必须留给前沿模型；什么工作该让客户现场团队做，什么必须沉淀成产品；自动化省下来的成本，又会流向哪里。

这期回答了 7 个问题：

1. 为什么 Decagon 把 90% 工作流放到开源模型后，性能反而更好？
2. 小模型在哪些任务上能胜过前沿大模型，哪些任务绝不能省？
3. 企业部署开源模型，真正难的为什么不是下载模型，而是做评测？
4. 一个 Agent 如何进一步接管“部署和改进 Agent”本身的工作？
5. 为什么前置部署工程师若不产出产品，最终只是在做高级咨询？
6. 模型越来越强时，企业 AI 公司真正的护城河究竟是什么？
7. 客服自动化会带来裁员，还是会因服务成本下降而创造更多需求？

被问到 Decagon 为何从 OpenAI、Anthropic 等前沿模型转向开源模型时，Jesse 先讲了一个很现实的限制：语音 Agent 不能只答对，还得立刻答。客户在电话里等两三秒，体验就已经开始变差。Decagon 的客服 Agent 也不是把一整段对话扔给一个模型处理，而是拆成许多窄任务：用户在问什么主题、是否有人恶意捣乱、下一步该调用哪个系统。

这些任务不需要模型会写代码、做数学题、回答百科知识。它只需要在一个固定环节上不犯错。于是 Decagon 把较小的开源模型拿来做微调，也就是用特定任务的数据反复训练，让它专门学会一件事。结果不是“便宜一点、笨一点”的妥协，而是 "on the specific task we want them to do, they actually outperform the large, smart, state-of-the-art models"（在我们希望它完成的那个具体任务上，它们实际上胜过了那些大型、聪明、最先进的模型。）。如今，Decagon 说其 90% 工作流已跑在开源模型上。

这意味着，企业选模型的单位不该再是“哪个模型总分最高”，而该是“这一步到底要完成什么”。任务拆得足够清楚，小模型可以同时拿到准确、低延迟和低成本三项收益。不过这不是把任何开源模型下载下来就能成功。开箱即用的小模型往往不够好，前提是企业已经定义清楚任务，也有数据和能力把它微调到位。

被追问是否还需要最前沿的闭源模型时，Decagon 的答案并不极端。剩下那 10% 工作流，仍会使用闭源前沿模型，尤其是新项目、新产品，以及那些尚未被拆清楚的辅助任务。原因不在于它们更“高级”，而在于它们适合在信息不完整时四处试路。

Decagon 新推出的 Autopilot 就是这种任务。它不是代替客服 Agent 跟一位用户说话，而是回头审阅海量对话，找出系统哪里出了问题，再生成不同版本的主 Agent 做比较。Jesse 对这份工作的描述很直白："I'm going to go and review a million conversations that just happened. I'm going to try and find trends."（我要去审阅刚刚发生的一百万段对话，并尝试找出其中的趋势。） 这不是一个预先写好标准答案的分类任务。它需要归纳、假设、试错，还要判断哪些变化值得测试。

这意味着，企业未来更像是在搭一条模型流水线，而不是在“开源”与“闭源”之间站队。稳定、重复、边界明确的生产环节，交给专用的小模型；探索新机会、寻找异常模式、设计下一轮实验，交给能走多条路径的前沿模型。边界也很明确：新用例还没跑通时，直接调用前沿模型的 API 最省事，基础设施、部署和维护都由模型公司承担。等业务形状稳定后，再把它迁到可控的小模型上。

被问到企业何时会开始后训练开源模型时，Asha 泼了盆冷水：决定采用开源，不等于第二天就能开始微调。企业得先有数据，更难的是建立高质量评测。所谓评测，不是拿公开题库跑一个分数，而是提前规定：这个 Agent 在真实客户场景中，什么叫做成，什么叫失败。

Decagon 的评测集是围绕自己的任务生成的，不能直接套公共 benchmark。他们也不只看某个模型的单项能力，而是看多个模型、工具和业务规则串起来后，能不能交付最终客户结果。Asha 说得很清楚："if we can clearly tailor our eval to customer outcomes it's way better than just looking at like loss curves over time"（如果我们能把评测清晰地对准客户结果，那就远胜于只看损失曲线随时间的变化。） 损失曲线是训练时的内部指标，像学生刷题的正确率；客户结果则是用户最终有没有顺利改签、问题有没有被真正解决。

因此，Decagon 把训练和评测所需的大量基础设施留在内部，因为它们紧贴自身业务；但标注数据获取、数据集多样性测量这类跨公司通用工作，则交给外部供应商。这意味着，开源模型会越来越容易获得，真正难复制的却是“怎样评估一条工作流是否替客户办成了事”。也正因如此，企业迁移开源的速度可能比想象中慢：卡住它们的往往不是模型，而是数据、治理和评测能力。

被要求举例说明模型进步带来了什么意外变化时，Jesse 讲了 Decagon 自己的交付流程。早期部署一个客服 Agent，团队得手写 AOP，即 Agent Operating Procedures，简单说就是教 Agent “遇到这类情况按什么步骤办”的操作手册；还要接入客户系统、编写测试、模拟各种异常情况。Agent 上线后，团队还要人工阅读对话，找出表现差的主题。

现在，Decagon 把这整段劳动交给了 Duet。它不是更快的客服 Agent，而是一个更大、更慢的第二 Agent。Jesse 的定义是："it's like a second agent that's much bigger, much slower, but its job is to do all the tasks I just described."（它就像第二个 Agent：更大、更慢，但它的工作就是完成我刚才描述的所有任务。） 团队给 Duet 对话记录和业务文档，它可以生成流程、编写测试和模拟；上线后再监控对话，找出薄弱主题，并起草改进方案。

Duet 先把“写 AOP”产品化，Duet Autopilot 又继续把“上线后的复盘和迭代”产品化。这意味着，Agent 公司最有杠杆的下一步，不只是让客户少做重复工作，也要让自己少做配置、测试、质检和优化的重复工作。每多一个客户，不必等比例增加交付人手。边界在于，这种二级 Agent 依赖推理模型的能力。Decagon 承认，公司刚成立时模型还做不到这些事，产品形态是模型能力跨过门槛后才出现的。

被问到前置部署工程师如何从客户现场工作演化而来时，Asha 把一个流行岗位说得很不浪漫。所谓前置部署工程师，是深入客户组织、边部署边理解工作流的工程师。AI 产品刚出现时，这种角色很必要，因为连客户自己也未必知道新工作流该怎样设计。但如果每个客户的需求都靠驻场团队手工解决，规模一大，公司就会被人头卡住。

Decagon 给这类团队定了硬规则：从客户现场发现的缺口，产出必须进入核心产品，不能只做成一次性定制。因为一旦沉淀下来，下一批提出同样需求的 10 个客户都能直接使用。Jesse 的警告很尖锐："If you can't do that, then you're just building a glorified consulting truck."（如果你做不到这一点，那你打造的就只是一辆被美化过的咨询卡车。）

一位从 Sierra 切换到 Decagon 的客户，给出了速度差异：此前一年只搭建了 3 条 customer journeys，也就是不同客户场景下的服务流程；切换后约一个月就搭了 7 条。客户想要的是更透明的“glass box”模式：自己的团队能看懂对话、参与迭代、自己创建新流程，而不是一切都得透过外部工程师这个黑箱。这意味着，前置部署的价值不在于“驻得多深”，而在于能否把客户痛点编码成所有人可复用的产品。

被问到公司当前真正的瓶颈是什么，嘉宾没有说模型、算力或语音延迟，而是先回答招聘。这个回答听上去反直觉：既然 Decagon 已经让 Agent 承担那么多执行工作，为什么还要持续扩张团队？他们的判断是，模型能外包越来越多明确的执行步骤，但还不能可靠地判断“该造什么、不该造什么”，也不能判断一件产品是否已经足够好，可以停止。

Asha 把这层能力称为产品判断：理解目标、约束、竞争局面，再做取舍。她说："I don't yet think they're at the point where they can make the call on what to build"（我还不认为它们已经到了能够决定该造什么的阶段。） 他们还举了 AI 编程创业公司的例子：这批公司本该是最擅长用模型的人，却仍在疯狂招聘。原因很简单，如果竞争对手能用 AI 在三分之一时间完成路线图，理性选择不是缩编，而是在同样时间里做出三倍更多东西。

这意味着，生产率提升不会自动换来更小的团队。在竞争激烈的市场里，它常常先变成更高的交付预期。组织的稀缺资源，正从“谁能把任务做完”转向“谁能选对任务、砍掉错误任务、及时定义完成标准”。当然，模型侧仍有待解问题，例如语音到语音模型、更小模型的原生能力。只是对 Decagon 而言，短期最缺的不是一个更会执行的 Agent，而是更多能做方向判断的人。

被直接追问“如果未来达到 AGI，Decagon 十年后凭什么存在”时，嘉宾没有把答案放在某个模型上。他们认为，即使模型完美无错，企业也不能把所有内部资源一股脑开放给它。银行、航空公司、电信企业都有权限边界、监管红线和遗留系统。企业需要明确 Agent 能做什么、不能做什么；还需要数百名业务专家共同审核它的行为，并在真实运行前后持续测试。

这套围绕模型的权限、协作、评测、监控和系统接入，被 Decagon 视为短期的部署层护城河。模型再强，也得被安放进一间有门禁、有流程、有旧设备的大工厂里。Asha 对这层壁垒的寿命却没有假装笃定："now once that gets commoditized because the agents can build that on the fly that I don't know and we'll figure out in three years from now"（但一旦这一切因为 Agent 能即时构建而被商品化，我就不知道了；我们三年后再弄清楚。）

这意味着，未来几年的企业 AI 竞争，未必由“谁调用到最强模型”决定，更可能取决于谁能把合规、权限、遗留系统和多方协作做成可复制的部署能力。但它也是一道阶段性壁垒：如果更强的 Agent 能现场生成这些配置和基础设施，今天最难的部署工作可能反过来被自动化。嘉宾没有回避这个不确定性，这比把“企业数据”喊成永久护城河更接近真实处境。

被问到客服作为首个端到端自动化场景，会怎样影响岗位时，Decagon 给出的例子不是一张裁员表。一位早期客户原本每月约有 5 万个客服咨询。接入 Decagon 后，这家公司发现，5 万并不代表用户只有 5 万次求助需求，而只是原有服务入口能承接的数量。客服成本下降后，他们把支持入口放到更多页面，在用户最容易卡住的位置突出展示，甚至让免费用户也能即时得到帮助。

Jesse 的概括是："I think it's like AI will kill jobs but not careers in a way because like those jobs that are being done currently should not be done by humans."（我觉得，AI 某种程度上会消灭岗位，但不会消灭职业，因为现在由人做的那些工作本就不该由人来做。） 这里说的岗位，是高频接电话、查系统、点几下按钮、复述标准答案的工作。单位服务成本下降后，企业可以把原来只给高价值客户的服务扩展给更多人，用更快响应改善激活、留存和转化。

这不意味着裁员风险不存在。Decagon 明确说，有些客户会大幅减少对 BPO——业务流程外包客服团队——的依赖，甚至不再需要 BPO。但也有客户不是为了压缩人头，而是业务增长太快，不想让运营团队跟着同比膨胀；还有客户会把人转去做更复杂、与收入更相关的工作。自动化后的结果，取决于企业把节省下来的成本当作利润，还是当作扩大服务供给的燃料。

“小模型不是降配”与“前置部署的终局必须是产品”，其实在讲同一件事：企业 AI 的规模化，不靠把一个最聪明的模型塞进所有场景，而靠把模糊工作拆成可定义、可评测、可复用的环节。模型选择只是第一步。真正决定结果的是，你能否知道哪个环节该用专用小模型，哪个环节仍需前沿模型探索；能否把客户现场学到的例外情况，变成下一个客户也能使用的产品能力。

“开源模型的真正门槛不在训练”与“AGI 之后的短期护城河是企业部署层”也指向同一层现实：模型能力不是企业结果。客户结果要经过评测、权限、合规、业务规则、遗留系统和组织协作，才能落地。模型越强，这些连接工作未必越少，反而可能让更多原本做不到的工作流变得值得连接。

对读者而言，最该警惕的不是“会不会被某个模型替代”，而是继续把自己的工作描述成一团不可拆的经验。能被明确写成步骤、标准和结果的部分，会越来越快地被 Agent 接走；更稀缺的部分，则是定义目标、识别例外、判断取舍，以及把一次经验沉淀成下一次不必重做的系统。