OpenClaw之后，我们离能规模化落地的Agent还差什么？

我们发现，在模型能力不再是唯一瓶颈的今天，Agent如何真正落地成为从业者关注的焦点。在本次沙龙中，一个反复出现的观点是：Agent需要是一个可持续工作的系统，而非单次任务的跑通。

这意味着它不仅需要模型智力，更需要满足稳定性、高吞吐量、成本控制以及精确的状态管理等严苛的工程指标。

围绕着这一问题，沙龙主要讨论了制约Agent规模化落地，成为可持续工作的System的四重阻碍：成本（Cost）；环境（Environment）、基础设施（Infra）、记忆（Memory）。

我们整理了本次沙龙的一些核心Insight，供从业者参考，希望对大家有所帮助。（注：本文观点不代表Monolith机构观点。）

1. 不能用黄金盖平房

任何系统的可持续性，最终都得回归到单位经济模型（UE）。如果Agent创造的价值覆盖不了它消耗的成本，那么无论模型多么先进，这个系统在商业上都是不可持续的。

当前Agent的门槛主要存在于数据与设施上。

在SFT（监督微调）模式下，我们依赖人类专家来教模型做事。但在GUI Agent（让AI操作电脑界面）这种高门槛任务中，这种依赖变成了难以承受的负担。

为了获得高质量的GUI任务数据，部分从业者发现，他们需要雇佣“985高校的高年级博士生”来进行标注，而即使是这样高水平的人力，标注一条数据也需要耗费20分钟。

这种高昂的时间与人力成本直接限制了数据的规模，团队最终只标注了200多个任务，无法进一步扩大。

简单点说，我们实际上正在用黄金盖平房——依靠堆砌专家人力来换取智能的提升，在复杂Agent场景下是不可持续的。

 这反向逼迫行业必须转向RL（强化学习）——让Agent在虚拟环境里自己试错、自我博弈，摆脱对昂贵人工数据的依赖。只有这样，才能把数据成本从"按人头算"变成"按算力算"，实现边际成本的下降。

但是，RL的门槛也不低。

传统的工业级RL训练往往依赖庞大的算力集群。即使是经过优化的训练流程，仍然需要16张显卡（8卡采样、8卡训练）以及大量的CPU资源来支撑仿真环境。

对于大多数中小企业或学术团队而言，这是一笔不菲的开销。如果无法通过RL实现数据的自我生成，Agent的商业模式会被高昂的人力成本直接锁死。

破局的关键是构建高仿真环境，让Agent通过自主探索产生海量交互数据，再通过设计有效的奖励信号，用RL训练出更强的策略。

2. 当超级大脑配上破电脑

当前Agent训练面临的悖论还有：光速的GPU算力，配上了龟速的操作系统。

在传统的RL任务（比如下棋、打游戏）中，环境反馈是毫秒级的，步长短、速度快。

但在GUI Agent场景下，Agent执行一个动作——比如在虚拟机里点击Excel按钮——需要经历"虚拟机渲染→截屏→图像回传→视觉模型处理"的漫长链路。

实际训练中，完成一个Step的交互甚至需要30秒以上，令人难以忍受。

极高的延迟又进一步导致了计算资源的极度浪费——在传统的RL流程中，架构通常是紧耦合的。这意味着，当GPU在更新模型时，环境在等待；而当环境在采样数据时，GPU又在空转。

这种时空的错配、互相阻塞导致了极低的计算利用率。

除了速度慢，环境的复杂度也呈指数级上升。

不同于文本生成，GUI Agent面临的是一个像素级（Pixel-level）的动作空间，理论上它可以在屏幕上的任意坐标进行点击或拖拽，这使得动作空间接近无限 。

这使得奖励极为稀疏。比如"将Excel内容打印为PDF"这样的任务，Agent需要连续执行几十个步骤。在这个过程中，环境往往一片死寂，不会告诉Agent中间某次点击是对是错，只有最后一步才能得到结果。

这种“长程视野 + 稀疏反馈 + 无限空间”的组合，构成了Agent所在环境的真实面貌——它是一个充满了摩擦的环境。我们不能再用训练聊天机器人的逻辑来训练Agent。

对于创业公司而言，这意味着必须投入资源去构建仿真训练环境，这比单纯购买H100显卡更考验团队的技术沉淀。

3. 基础设施“太重、太贵、玩不起”

如何解决环境问题？

在现场，不同的分享者分别从横向扩展与纵向轻量化两个维度，给出了Infra重构的答案：解耦（Decoupling）。

横向解耦：打破采样与训练的同步锁

面对GUI Agent交互速度极慢的问题，有研究者提出了一种名为Dart（Decoupled Agent RL）的框架。

其核心逻辑是将采样端与训练端在物理上彻底分开 。

在这一架构下，采样端不再等待模型更新，而是利用 Kubernetes（K8s）并行启动上百个Docker容器作为Environment，持续不断地生产轨迹数据。数据通过一个基于MySQL的轨迹管理器进行异步调度，再输送给训练端。

这种设计虽然引入了Off-policy（数据和模型不同步）的挑战，需要通过数据筛选机制来平衡，但收益是巨大的，至少有三层：

• 消除了GPU等待环境反馈的空转时间
• 实现了5.5倍的环境利用率提升
• 整体训练吞吐量翻了近一倍

这也意味着，Agent的Infra必须具备处理异步数据流的能力，而非传统的同步批处理，将训练过程转变成了一个持续流动的、高吞吐的流水线。

Dart框架

纵向解耦：降低算力门槛

Infra的另一个痛点在于“重”。

现有的工业级框架（如Verl, OpenRLHF）往往针对大规模集群，代码量庞大且模块耦合严重，对于学术界或资源受限的初创团队而言，修改算法逻辑或适配小规模集群的门槛极高。

另一位研究者展示了轻量化的解耦思路——开发模块化框架，将算法逻辑、模型架构与分布式引擎分离。

这种RL-Centric的设计理念，把工程复杂度封装在模块边界内，实现了"逻辑即实现"——研究者可以像搭积木一样，通过插件化配置自由组合GAE、GRPO、PPO等算法组件，大幅降低了处理底层分布式的负担。

同时他们还通过CPU Offload技术实现了显存复用 —— 推理采样时将训练参数卸载至CPU，优化更新时再加载回GPU，显著降低了硬件门槛。

RLLaVA框架

4. 长上下文不是万能灵药

算力和环境之外，另一个问题是状态管理。

Transformer架构虽然强大，但它缺乏可读写存储器，无法显式地存储或更新中间的推理状态，也没有循环或递归机制。

在处理简单问答时，这种无状态特性不是大问题；但在面对复杂的软件开发或长程逻辑推理时，这种缺陷是致命的。

由于缺乏对推理状态的有效管理，模型在解决复杂递归任务时，往往会出现推理链路断裂或逻辑漂移 。

这些问题，相信重度使用AI的用户都能感受到。

学术界与工业界也正在尝试从架构底层进行修补。诸如Mamba等State Space Models（SSM）、Linear Attention机制、Stack机制，正在成为解决这一问题的热门方向。

这些新架构试图通过更高效的状态压缩与传递机制，让模型具备原生的状态推演能力，从而弥补Transformer在长程状态管理上的先天不足。

另一个思路是改变推理的载体。当前大多数Agent依赖自然语言进行思维链推理，但自然语言在精确计算和状态追踪上有局限。

一种思路是让模型学会用代码思考——代码天然具备变量、函数和逻辑流，比自然语言更适合精确的状态管理。

Code Thinking

在工程落地层面，一个常见误区是把Long Context（长上下文）等同于"记忆"。但单纯拉长上下文窗口既不经济也不实用。

实际场景中，记忆被划分为两类：用户侧记忆和执行侧记忆。前者类似传统用户画像，记录用户偏好和基本信息，大多数 AI 客服已具备雏形。后者是 Agent 自我进化的关键——不仅要记住“用户是谁”，更要记住“我上次是如何完成任务的”，包括执行轨迹和经验教训。

当再次遇到类似任务时，Agent 应能复用成功路径或规避踩过的坑，而非从零开始。

在记忆架构上，一种思路是将其设计为file system式的分层存储。当Agent需要回顾时，它执行的是读取文件的操作，而非在上下文窗口中大海捞针。

对于一个系统而言，“记忆”的本质不应该是记住所有的对话历史，而是能够像计算机一样，精确地管理每一个变量的周期与状态。

最后，随着GUI等复杂场景的出现，人工标注的成本显然已不可持续。

未来的数据壁垒，不再是谁爬取了更多的互联网文本，而是谁能构建更逼真的仿真环境，让Agent在其中自我博弈、自我进化。这种通过RL产生的高质量合成数据，将是下一阶段最稀缺的资源。

我们永远处在一个不断出现噪音，排出噪音的商业环境中，Agent的深水区才刚刚开始。