火山引擎谭待：AI时代，加速度最重要，云和模型需要“Agent友好”-优快云博客

2025年12月18日，火山引擎Force原动力大会在上海召开。

作者 | 高飞

2011年，马克·安德森在《华尔街日报》发表了一篇文章，标题是《为什么软件正在吞噬世界》。他的论点很简单：越来越多的行业正在被软件公司颠覆。软件能力更强的亚马逊、Netflix、Spotify等分别改变了零售、影视和音乐行业。

软件吞噬世界的过程，也是计量单位不断演变的过程。PC时代，微软按“许可证”收费。互联网时代，Salesforce发明了SaaS，按“订阅”收费。云计算时代，“资源”一度成了计量单位，比如用了多少核、多少GB、多少小时。

每一次计量单位的切换，软件就向前吞噬一步。十四年过去，安德森的判断基本应验。但他当时自然无法预料的是，软件本身也在被吞噬。

吞噬发生在两个层面。开发方式在变：Vibe Coding正在兴起，开发者用自然语言描述需求，模型生成代码，程序员的工作从”写代码”变成”审代码”。软件形态也在变：越来越多的软件正在变成Agent，它们不再等待用户点击按钮，而是主动感知、决策、执行。

两层吞噬指向同一个结果：Token正在成为新的计量单位。开发者用Token生成代码，Agent用Token完成任务。

2025年12月18日，火山引擎Force原动力大会在上海召开。火山引擎总裁谭待宣布了一组数字，截至2025年12月，豆包大模型日均Token使用量已突破50万亿，居中国第一、全球第三。最惊人的是其中的加速度，因为这个数字在一年前还只是4万亿。而且，在火山引擎累计Token使用量超过一万亿的企业，也超过了100家。

谭待在会后的媒体采访中，用“内核”这个词来描述这种变化。

“技术的变化，要看它的内核。PC时代的内核是网站，围绕网站有了MySQL、PHP。到了移动时代，产业规模增长十倍，围绕APP有了新的技术栈。到了AI时代，网站和APP都会在，但背后的逻辑会变成Agent。”

所以，在这次大会上，我看到火山引擎的一种打法：云的形态在变，模型的目标也要变。具体来说，是一朵“token友好型”云，和一种“agent友好型”模型。

云的新角色

先说云。

谭待表示，大模型的出现，让企业上云的必要性大幅度增加。他在记者会中讲了一个观察：年初DeepSeek还没出来的时候，很多企业买了AI一体机，但是其中很大一部分没有发挥作用。

这是因为企业无法把全栈AI能力都本地化，“模型三个月就更新一代，私有化的版本会落后太多。更关键的是，如果用模型去做Agent，模型能够本地，但是AgentKit、RAG、向量数据库这些周边技术都没法私有化。这就等于拿了一个可能几个月就会被淘汰的上一代模型，配上一套不全的开源栈，跑在算力不够的设备上。”

所以，他的判断是：AI时代，云的重要性比以前更大，而不是更小。但云的角色需要重新定义。

具体而言，就是模型迭代快，生态依赖多，弹性需求大。方方面面都影响着企业的AI预算和决策。

火山引擎智能算法负责人吴迪在大会演讲中以模型推理这件事为例算了一笔账。

他说，对于大部分团队来说，低成本、高吞吐地推理好一个大模型，可能比后训练好一个大模型更困难。建设初期，企业可能需要付出数百万人民币的投入成本，经历若干个月的上线周期，还要面对复杂的运维工作。进入规模化阶段后，除了线性上涨的硬件成本，还有容易被忽视的隐性支出，比如更高的运维要求、更好的SRE团队、更强的AI架构师，这些都需要时间培养。而当一个新业务的增长曲线爆发时，企业往往来不及做好准备。

基于这个判断，火山方舟推出了“推理代工”服务。吴迪用了一个比喻：就像一台已经调校完成的顶级赛车，只等用户把模型插入发动机就能开跑。用户上传加密后的模型checkpoint，无需运维底层GPU，无需做复杂的网络和调度配置，只需要关注流量本身。

数据显示，当企业选择云上集群替代自建集群时，硬件和运维成本下降约一半；进一步使用方舟的推理代工后，对比云上租赁GPU算力，客户还能获得1.6倍的吞吐提升，并通过弹性采购避免空闲时段的资金浪费。

英伟达黄仁勋在GTC上有一句名言，“买的越多，省的越多”。火山引擎也发布了一项“AI节省计划”，口号是”用得越多，省得越多”，最高可为用户节省47%的使用成本。

弹性是另一个关键词。吴迪在会上展示了一张真实的流量曲线图：绿色是某业务的真实流量，蓝色是方舟提供的算力，两条曲线紧紧贴合。方舟能在分钟级完成百卡到千卡的伸缩。

不过，一切放在云端，安全就会成为企业尤其是大企业的一种顾虑。对此，火山引擎把安全作为一个关键特性。火山引擎推出了AICC（AI机密计算），让用户可以把所有模型，包括开源的和豆包的，都纳入机密计算保护。

Agent的胃口

我们再说模型。

Token不会凭空消耗。谁在大量吃Token？火山引擎的判断是：未来消耗Token的主体将是Agent，而非人类用户。

这个判断初听反直觉。毕竟现在用豆包APP的是人，和ChatGPT对话的也是人。但是其中内在的逻辑是：人与AI的对话量有限，但Agent自动执行任务时产生的Token消耗，将远超人工对话。

谭待在采访中用“天花板”理论来解释这个差异：对于AI的采用，有的行业起量特别快，但天花板低；有的行业起量特别慢，但天花板很高。陪伴型聊天的天花板就不高，因为一个人每天能够讲话的时间就那么多。但是，深度研究类Agent就正好与此相反，企业管理者一天可能只问一次“豆包，你告诉我明年什么行业会更好”。但要回答好这个问题，Agent背后可能要去做各种搜索、比对、数据清洗、假设扩展。这一个需求的Token消耗，就超过了一整天的陪伴聊天总量。

换句话说，Agent吃掉的不是“对话量”，本质是“工作量”。它把原本需要多人多次完成的任务压缩成一次请求，背后是成百上千次的模型调用。

企业也在用实际行动投票。谭待披露的数据显示：2024年，平均一家企业投产的智能体数量是58个；到2025年，这个数字已经达到200多个，有的企业甚至投产了超过1000个。

但谭待同时指出了一个悖论：“现在模型已经够强了，但是真正把这个强用好的企业也不多。这还就是因为Agent迭代太慢，它需要有一套新的、为Agent开发运行设计的AI原生架构。”

他在演讲中拆解了这个鸿沟：很多团队能用几天时间就搓出一个Agent的demo，但接下来要把它跑在生产环境，符合SLA、合规、安全、成本等各项要求，往往要花费数月甚至更久。问题的本质是：缺少为Agent规模化运行而设计的基础设施。

火山引擎发布的AgentKit平台试图填补这个空白。谭待把核心能力归纳为八个模块：Identity（身份与权限管理）、Runtime（运行时环境）、Sandbox（沙箱工具服务）、Gateway（统一入口）、Memory（记忆库）、可观测能力、Evaluation（评测体系）、Guardrails（安全护栏）。

从我个人的理解，既然Agent是在协助人工作，那么它的管理逻辑也应该借鉴人类组织的经验。这八个模块的设计逻辑，某种程度上复刻了人类组织管理的基本原理。

分别拆解一下：

Identity对应角色与责任边界；Runtime对应制度环境与生产纪律；Sandbox对应风险隔离与安全试点；Gateway对应流程与入口治理；Memory对应组织记忆；可观测能力对应管理可见性，毕竟德鲁克说”不能衡量就难以管理”；Evaluation对应绩效评估与持续改进；Guardrails对应规则与边界内建。当Agent从工具变成执行单元，系统就需要一套能让它像组织成员一样被授权、被约束、被评估、被追责的生产体系。

八个模块显然很多，在大会前的沟通中，我请火山引擎云基础产品负责人田涛涛帮忙挑选企业AI负责人应该关注的三个要素，他选择了：身份、评测、入口。

他解释，传统应用时代，企业只需要管理“人”的权限；在Agent时代，企业需要管理Agent、工具、系统之间的关系，身份不清、权限不明，就会出现严重的安全问题。评测自然同样关键，开发者可能认为Agent表现不错，一旦换一个模型版本、换一种使用方式，就可能出问题。最后是网关，火山引擎在网关层提供了一套基于Ranking模型的搜索机制，通过语义匹配让模型找到正确的工具。

对于这套Agent打法的实效，谭待用这次Force大会的报名系统做了现场演示。传统开发模式下，实现一个Agent至少需要1500到2000行代码。通过AgentKit，同样的功能只需要61行，代码量减少96%。

另外，Agent的胃口不仅大，而且杂，也就是多模态。

谭待说：以前用户使用就是聊天，所以支持文字就行了。但现在让模型帮助处理事情，输入可能就带视觉的，比如在车里、在线下摄像头。工具返回的结果很多也是视觉化的，所以模型必须要有视觉化的理解，才能理解这些工具的结果。

这次大会发布的豆包大模型1.8（Doubao-Seed-1.8）正是沿着这个方向设计的。官方定位是“面向通用真实世界Agent”，核心目标是从纯语言生成走向主动决策。

技术报告显示，在衡量通用AI助手能力的GAIA基准测试中，豆包大模型1.8得分87.4，超越GPT-5 High的76.7；在多模态视觉搜索任务MM-BrowseComp上得分46.3，领先GPT-5 High的27.7。

更值得注意的是框架兼容性，无论是Claude Code、Trae还是OpenHands，豆包大模型1.8都能保持稳定表现，说明模型具备的是内在的工具理解能力，而非依赖特定框架的提示词工程。

消费Token的主体是Agent，而Agent要在真实世界干活，就必须能看、能听、能读。

模型对Agent友好，首先意味着对多模态友好。

模型和Agent，都在”强化学习”

模型和Agent是企业AI业务落地的一体两面。有趣的是，在两者之间，我们还能找到一个技术上的连接点，它就是强化学习。

自模型演化至推理形态，强化学习的重要程度就与日俱增，而且带来新的AI算力架构需求。

吴迪在会前沟通中用了一个类比。

传统的预训练系统“像一块石头一样紧凑”，几千张卡以极高的互联同构连接在一起。强化学习系统“像一个太阳系”，有Trainer、Rollout、Reward，以及散布在周围的大量沙盒和虚拟机环境。

这个比喻就解释了模型的强化学习和Agent的构建，在底层逻辑是相通的，它们都需要在环境中学习。Agent需要在真实的应用环境中执行任务、获得反馈、调整策略；强化学习需要在模拟环境中尝试行动、获得奖励或惩罚、优化决策。核心逻辑一致：通过与环境的交互来提升能力。

因此，吴迪在演讲中也反复强调：强化学习将变得越来越重要。现在大部分AI系统还是静态的，难以随着用户数据的增长去自发进化。Agent要真正融入企业核心业务，就必须能够自我学习。

火山方舟这次在大会上推出了Serverless RL强化学习平台。吴迪用抖音客服的案例做了演示：算法工程师用真实客户对话总结出训练剧本，设计虚拟环境让模型扮演客户与待优化的客服模型大量对话，再通过多维度的Reward评分体系（语气、流程、情绪识别等）形成自动循环。结果显示，经过强化学习的模型表现出更好的专业度和拟人度，问题解决率提升了10个百分点，并节约了80%的工程准备时间。