模型很强，但不止模型很强 | 火山引擎 Agent 开发走向闭环
当 Agent 开始进入真实业务。
**
当 Agent 开始进入真实业务。
👦🏻 作者: 镜山
🥷 编辑: Koji
🧑🎨 排版: NCon
过去这一年，大家都在谈大模型。不管是朋友圈还是技术群，话题总离不开「国内外哪家模型又突破了」或者「哪个榜单 Benchmark 又被刷新了」。
但回归到日常工作里，很多人的体感其实是比较纠结的：模型确实很强，但想把它真正用进业务里，变成一个好用的 Agent，这事还是挺麻烦的。
环境怎么配？Prompt 怎么调？业务数据怎么接？
这些琐碎的细节，依然是门槛。
带着这些很具体的问题，「十字路口」团队参加了 2025 火山引擎冬季 Force 大会开发者论坛，全场基本都在围绕着「Agent」。
12 月 18 日是 Force 大会的第一天，当天出了 2 个热点：
【1】豆包多模态大模型 1.8 正式发布；
【2】豆包大模型日均使用量超 50 万亿 tokens。
而 19 日的这场「开发者主论坛」相比前一天的「各种数字」，火山引擎这次给出了一套很多人都很熟悉的工具：火山方舟、AgentKit、扣子编程、TRAE CN 企业版。
其实很多人，对这次大会上出现的这些名字应该不陌生。
之前的文章里，我们陆陆续续聊过扣子的低代码能力，也分享过 TRAE 在编程上的体验。
🚥
在这次 Force 大会上，这一套 Agent 开发流已经升级成为了一套完整的 Agent 开发矩阵。
从底层的模型服务，到中间的开发平台，再到上层的具体开发工具，火山引擎这次把 Agent 开发的「拼图」拼的更完整了。
我们想从下面这几个层面和大家聊聊：我们具体的观察、感受和这几个 Agent 矩阵工具的升级。
为什么我们需要一个「Agent 矩阵」？
我们一直在说，2025 年 AI 正处于「风起于青萍之末」。
这句话想表达的是，很多真正重要的变化，往往是从细节中慢慢发生。过去两年里，我们更容易被参数规模、榜单成绩这些「显学」吸引。
但当 AI，尤其是 AI Agent，真正进入具体场景、开始被用起来时，过程反而显得有些安静。
也正是在这个阶段，一个新的变化开始变得清晰：靠「手搓」做出来的 Agent 开发方式，性价比越来越低。
所以，在深入聊具体工具之前，我想先退一步，聊聊很多人现在正面对的 Agent 开发工作流，也聊聊「我们需要怎样的 Agent？」。
过去这一年，很多人对 Agent 的理解还停留在「写一个好的 Prompt」。但真正动手做过落地项目的开发者都知道，做一个 Demo 和做一个企业级能用的 Agent，中间隔着很远。
一个成熟的 Agent 工作流，要比我们想象的复杂：
你需要底层的模型支持（不仅仅是对话，还有上下文、多模态），需要中间的编排逻辑（让它知道什么时候查库、什么时候调接口），需要记忆机制（让它记住用户的历史），还需要一套完善的评估和监控体系（它胡说八道了怎么办？）。
确实很复杂。
所以，单靠某一个工具，其实很难覆盖全链路。
光有 IDE，你要自己手搓所有的项目，效率太低；光有低代码平台，遇到复杂的定制化业务，又容易卡住；光有模型 API，离业务场景又太远。
这就是为什么在 Force 大会现场，很多人看到这套「Agent 开发矩阵」时，会产生一种比较直观的感受：原来这些问题，被系统性地拆解掉了。
大概分为 3 个层面：
【1】底座层（火山方舟）
这一层解决的是最基础的问题。
你不需要自己去训练模型，火山方舟把大模型封装成了服务（MaaS），提供了最基础的推理、微调和上下文能力。
【2】平台层（AgentKit）
这一层解决的是「组装」问题。
AgentKit 面向的是更复杂、更严肃的业务场景，强调可控的流程编排。它的目标都很明确：尽量减少重复造轮子，把精力留给业务本身。
【3】工具层（TRAE & 扣子）
这一层解决的是「手搓」问题。
当标准组件不够用时，AI IDE 能试着帮你搞定个性化的核心代码。扣子则偏向快速试错和验证，让想法能尽快跑起来。
把这 3 层放在一起看，其实传达了一个很清晰的信号：
Agent 的开发，已经从零散工具，走向了一套可以贯通模型、平台、工程的全链路方案。
有了这个「全景视角」，我们再来看看这个矩阵里的每一个组件，它们都在往什么方向创新，就会明白它们各自在解决什么问题。
接下来，我们整理了其中 5 个比较值得关注的亮点。
1）扣子开发平台重大升级了
扣子开发平台现在正式更名为扣子编程，官方给它的定位是：一站式云端 Vibe Coding 开发平台。
如果你是一个懂业务的产品经理、运营，甚至只是一个有明确需求和好点子的普通人，你现在要面对的第一个问题，基本不是功能怎么设计。
你要问的是要不要去学 Python、要不要折腾本地环境、服务器和部署是不是也得一起补课？
在 Force 大会上，扣子编程给出的答案是：需要，但不如以前需要了。
这句话的潜台词是，代码能力固然重要，但它已经不再是参与开发的唯一入场券。
这就是扣子编程和 Vibe Coding 将会带来的新体验。
Vibe Coding 带来的变化是整个开发流程的起点往前挪了。过去，开发往往从环境配置开始，一路走到写代码、调试、部署和运维。
现在，起点变成了表达需求，用户能直接通过自然语言对话，构建智能体（Vibe Agent）、工作流（Vibe WorkFlow）和网站了。
扣子编程在其中做的一件关键事情，是把「写代码」和「让代码跑起来」之间那一整段很消耗精力和时间、也最容易劝退非技术背景用户的链路，缩短了。
安装软件和配置环境这件事可以试着「削减重要性」，打开浏览器就可能是完整的开发环境。
现在，「扣子编程」平台对「能讲清需求却不想为部署和运维付出大量学习成本的人」，以及「那些想快速验证一个想法，而不是一开始就搭一整套技术体系的人」，会更友好，而且 Vibe Infra 也是这次扣子编程更新的重点，AI Agent 平台 已经具备一套可以自动管理、部署和运行的基础设施能力。
2）TRAE CN 企业版发布
TRAE 是字节在 AI IDE 上推出来的旗舰产品。
在过去的很长一段时间里，它吸引到了足够多的用户。
现场大会透露出来了几个数字：TRAE 在字节内部有 92% 的工程师使用，个人版注册用户已经突破了 600 万，而且，TRAE 也被用在了字节内部的真实场景里。
比如在抖音生活服务团队里，TRAE 对 AI 代码贡献率超过了 43%。
对于开发者来说，AI IDE 的提效很明显。市场上，也有非常多的同品类产品。
回想一下我们以前写代码的状态：大部分时间其实都是在改 Bug、写单元测试、查文档。
所以对于个人开发者，TRAE 的提升效率能力是很被看重的。但对于企业来说，引入 AI IDE 最大的顾虑其实是：确定性。
AI 写的代码安不安全？能不能直接跑？会不会引入新的漏洞？
这也是很多人在现场特别关注 TRAE CN 企业版的原因。
这回发布的 TRAE CN 企业版在上面这几个问题上，都试着做了一些创新，主要也都是为了应对企业场景。
针对企业的性能要求、部署适配、效能追踪，以及代码安全的四大挑战，TRAE CN 企业版进行了全面优化：企业级大仓性能、高并发和长上下文窗口支持；实现了从知识库到 Agent 的全场景业务适配。
支持实时效能追踪管理，以及全链路代码加密传输。云端零存储，保障企业安全合规。
在企业场景这一块，大会上其实也给出了几个挺有「分量感」的新数字，用来说明 TRAE CN 企业版到底是按什么级别来设计的。
比如在代码和资产规模上，它已经可以支持 10 万级文件、1.5 亿行代码的超大仓库索引，这基本就是冲着真实企业级代码库去的。
对很多有多年历史、代码一直在叠的团队来说，AI IDE 可以试着在整体代码语境里工作了。在算力侧，TRAE CN 企业版将直接对接企业级 GPU 集群，同时还能把交互延迟压到毫秒级响应，这点其实很关键。
因为一旦进入真实研发流程，AI 如果「想一会儿再回你」，体验会迅速崩掉，而毫秒级反馈才能真正嵌进日常编码节奏里。
它对超长上下文窗口的支持，本质上也是在适配复杂工程场景。
现实中的企业级编程，很少是单文件、单模块的问题。上下文要能拉得足够长，AI 才有可能理解「为什么当年这么写」。
从这些数字背后能看出来，TRAE CN 企业版在尽量把 AI 拉到真正能承载企业复杂度的程度。
3）8 分钟做云端 Agent 的 AgentKit
AgentKit 可以理解为火山引擎给企业准备的一整套 Agent 工具箱，试着让做 Agent 这件事，从「很难落地」变成「能直接上手」。
很多人现在做 AI Agent 都有类似的体验，Demo 跑得很好，效果也不错，但一到真要接业务、接数据、接权限，就开始「慌」了。
AgentKit 试图解决的，就是这些 Demo 到生产之间的断层。
从定位上看，AgentKit 更像是一套企业级 Agent 的底座。
它关注的不是某一个模型、某一段 Prompt，但试着把 Agent 从开发、部署、运行，到运维和调优这一整条链路都试着 Cover 住。
具体说的话，想要做到这一点，AgentKit 一共有 8 个核心模块作为支撑，从最开始的身份权限管理 Identity、运行时 Runtime、云沙箱 Sandbox、网管 Gateway、记忆库 Memory、可观测 Observability、评测 Valuation、到安全围栏 Guardrails。
这一大串的模块能力，共同组成了企业里能用得上的 Agent。
换句话说，它在回答更现实的问题：这个 Agent 上线之后会不会出事？出了事能不能查清楚？能不能控制住影响范围？
现场大会，给了一个非常直观的例子：8 分钟从 0 开始做了一个可生图和生视频的 AI Agent，并部署到了云上。
这个现场的测试，展示出了火山引擎这套 AgentKit 在现实场景里的能力和完整性。
4）火山方舟助力企业级 Agent 构建
如果说 TRAE CN 企业版、扣子编程和 AgentKit 是直观地构建产品，那么火山方舟就是支撑这些的基座。
火山方舟其实我们已经很熟悉了。
在在这次大会上，以前的火山方舟我们理解的是 MaaS（模型即服务）平台，可能就是租个 GPU、调个 API。
但这次方舟展示的逻辑，基本是： Agent 的全生命周期。它试图解决 3 个比较本质的问题：怎么造得快？怎么变聪明？怎么记得住？
开发过复杂 Agent 的人都知道，手动管理上下文和工具调用确实很困难、繁琐。
火山方舟 Responses API，实际上是把这些麻烦的任务都「标准化」了。
它自带了上下文管理，支持多轮对话的链式处理，文本、图文混合，都能衔接住。
现场也给出了几个真实案例，像高途用它来做搜题和伴学，齐心用它来做商品合规检查，成本下降非常直观，有的场景甚至能降 80%。
为了让开发者更好地完成工具调用，火山方舟体验中心推出「开发者模式」，它可以把每一次请求、每一个工具的并行调用都变成了可视化的节点。这种「像 IDE 一样调试 API」的体验，对开发者来说其实是比较友好的。
其次，现在大家的共识是：预训练只是让模型走完了第一步，要让它在特定业务里表现的还可以，得靠强化学习（RL）。
但 RL 的门槛太高了。
火山方舟上线了 Serverless RL 平台，其实是把强化学习变成了 Serverless 服务。企业不需要自己去搭复杂的训练集群，也不用管仿真环境的加速，只需要关注业务数据。
最后，一个能干活的 Agent，需要有数据库做支撑。火山Viking 这回也是大会的重点之一：
VikingDB 向量数据库本次升级了递进式的信息检索方式：结合大模型ranking算法，对召回结果做更细的判断和排序，实现先找"全"的相关结果，再选"对"的精确结果。
同时，火山 Viking 记忆库进行了进一步升级：不止记住文字，更能定格视觉以及。
再加上它把记忆库和知识库做了融合，Agent 不仅能记住「资料里写了什么」，还能记住「用户以前做过什么任务」。
从工具到创新，火山方舟作为底座，正在让 Agent 变得「更聪明一点点、更懂业务一点点」。
5）开发者群落
最后，我想聊聊技术之外的东西，毕竟工具还是需要人来用。
这次 Force 大会之后，原来的「火山引擎开发者社区网站」已经升级为「Agent 开发者社区」，里面会围绕 Agent 提供更完整的知识结构和学习路径。
网站如下：https://developer.volcengine.com/
同时，新上线了一个叫做「动手实验室」的模块，本质上是一个可以直接上手的云沙箱环境。
在这个实验室里，官方提供了免费的实验云资源。你可以直接调用豆包大模型、AgentKit 这些核心工具，跟着教程从 0 搭建一个真实的 Agent 应用。
未来 TRAE 和扣子的相关场景也会陆续进来。
除了工具和学习资源，现场还正式发布了新的 Agent 核心开发者计划，未来将会有很多积极的布道者和技术专家都加入进来。
线下层面，我在现场还看到了一个新的组织正式亮相了：ADG（Agent Developer Group）。这是火山引擎发起的城市开发者社区项目，目前已经在北京、上海、深圳和成都落地，明年还会去到广州、杭州、武汉等地，来帮助本地开发者一起学习 Agent。
这对于开发者来说还挺重要的。AI 技术迭代这么快，一个人闭门造车很容易陷入迷茫。
与人连接的能力，在 AI 时代很重要。
2025 年被称为 AI Agent 元年，正处在「风起于青萍之末」的阶段。
它往往从一些很具体、很务实、能真正落地的细节，开始展现，大家开始把注意力更多放在真实场景下的 Agent 工作流上。
Agent 开发因此也正在走向一套更完整、更可复用的体系。
当模型、平台和工具之间的边界更容易衔接，开发者不必再反复在基础问题上消耗精力时，AI Agent 才有机会成为「真实业务」的一部分。
这种变化不一定能立刻带来「超级惊艳」的效果，但会一直降低开发者们进入的门槛。
AI 不会淘汰开发者，它只会奖励那些善用工具、且对世界充满好奇心的人。
