OpenClaw （原名 Clawdbot）爆火。

對于個人極客來說，OpenClaw 是有趣的。但對于企業(yè)和商業(yè)環(huán)境來說，問題立刻暴露：昂貴（燒 Token）、不可控（安全邊界模糊）、存在隱私問題，且難以協(xié)作。

可以說，目前的 Agent 更多還是驚艷的 Demo，不是可以規(guī)?；漠a(chǎn)品。

Monolith 礪思資本辦了一場「After the Model」技術(shù)沙龍，聊了聊：Agent 離規(guī)?；涞剡€有哪些難題？

在活動中，一個被反復(fù)提及的觀點是：Agent 需要是一個可持續(xù)工作的系統(tǒng)，而非單次任務(wù)的跑通。

這意味著，光有「模型智力」是遠遠不夠的。想跨過工程這條鴻溝，必須還要「死磕」這幾個硬指標：穩(wěn)定性、高吞吐量、成本控制、精確的狀態(tài)管理。

以下是活動的一些核心 Insight，供從業(yè)者參考。

??關(guān)注 Founder Park，最及時最干貨的創(chuàng)業(yè)分享

Founder Park 聯(lián)合扣子，舉辦了一場 Skill 招募大賽。如果你手里有一套在用、能交付結(jié)果的方法論，很適合來試試！

歡迎飛書掃碼加群：

進群后，你有機會得到：

• 可落地的 Skill 搭建方法

  從一個想法或一套 SOP，拆解成真正能跑起來的 Skill

• Skill 的展示與放大通道

  不只是自己用，而是被更多人看到、用到

• 被看見后的實際激勵

  好的 Skill，有機會獲得明確回報

01教模型做事的成本太高，

不能用黃金蓋平房

任何系統(tǒng)的可持續(xù)性，最終都得回歸到單位經(jīng)濟模型（UE）。如果 Agent 創(chuàng)造的價值覆蓋不了它消耗的成本，那么無論模型多么先進，這個系統(tǒng)在商業(yè)上都是不可持續(xù)的。

當前 Agent 的門檻主要存在于數(shù)據(jù)與設(shè)施上。

在 SFT（監(jiān)督微調(diào)）模式下，我們依賴人類專家來教模型做事。但在 GUI Agent（讓 AI 操作電腦界面）這種高門檻任務(wù)中，這種依賴變成了難以承受的負擔。

為了獲得高質(zhì)量的 GUI 任務(wù)數(shù)據(jù)，部分從業(yè)者發(fā)現(xiàn)，他們需要雇傭「985 高校的高年級博士生」來進行標注，而即使是這樣高水平的人力，標注一條數(shù)據(jù)也需要耗費 20 分鐘。

這種高昂的時間與人力成本直接限制了數(shù)據(jù)的規(guī)模，團隊最終只標注了 200 多個任務(wù)，無法進一步擴大。

簡單點說，我們實際上正在用黃金蓋平房——依靠堆砌專家人力來換取智能的提升，在復(fù)雜 Agent 場景下是不可持續(xù)的。

這反向逼迫行業(yè)必須轉(zhuǎn)向 RL（強化學(xué)習）——讓 Agent 在虛擬環(huán)境里自己試錯、自我博弈，擺脫對昂貴人工數(shù)據(jù)的依賴。只有這樣，才能把數(shù)據(jù)成本從"按人頭算"變成"按算力算"，實現(xiàn)邊際成本的下降。

但是，RL 的門檻也不低。

傳統(tǒng)的工業(yè)級 RL 訓(xùn)練往往依賴龐大的算力集群。即使是經(jīng)過優(yōu)化的訓(xùn)練流程，仍然需要 16 張顯卡（8 卡采樣、8 卡訓(xùn)練）以及大量的 CPU 資源來支撐仿真環(huán)境。

對于大多數(shù)中小企業(yè)或?qū)W術(shù)團隊而言，這是一筆不菲的開銷。如果無法通過 RL 實現(xiàn)數(shù)據(jù)的自我生成，Agent 的商業(yè)模式會被高昂的人力成本直接鎖死。

破局的關(guān)鍵是構(gòu)建高仿真環(huán)境，讓 Agent 通過自主探索產(chǎn)生海量交互數(shù)據(jù)，再通過設(shè)計有效的獎勵信號，用 RL 訓(xùn)練出更強的策略。

02光速的 GPU 算力，

但被迫在龜速的操作系統(tǒng)上訓(xùn) Agent

當前 Agent 訓(xùn)練面臨的悖論還有：光速的 GPU 算力，配上了龜速的操作系統(tǒng)。

在傳統(tǒng)的 RL 任務(wù)（比如下棋、打游戲）中，環(huán)境反饋是毫秒級的，步長短、速度快。

但在 GUI Agent 場景下，Agent 執(zhí)行一個動作——比如在虛擬機里點擊 Excel 按鈕——需要經(jīng)歷"虛擬機渲染→截屏→圖像回傳→視覺模型處理"的漫長鏈路。

實際訓(xùn)練中，完成一個 Step 的交互甚至需要30 秒以上，令人難以忍受。

極高的延遲又進一步導(dǎo)致了計算資源的極度浪費——在傳統(tǒng)的 RL 流程中，架構(gòu)通常是緊耦合的。這意味著，當 GPU 在更新模型時，環(huán)境在等待；而當環(huán)境在采樣數(shù)據(jù)時，GPU 又在空轉(zhuǎn)。

這種時空的錯配、互相阻塞導(dǎo)致了極低的計算利用率。

除了速度慢，環(huán)境的復(fù)雜度也呈指數(shù)級上升。

不同于文本生成，GUI Agent 面臨的是一個像素級（Pixel-level）的動作空間，理論上它可以在屏幕上的任意坐標進行點擊或拖拽，這使得動作空間接近無限。

這使得獎勵極為稀疏。比如"將 Excel 內(nèi)容打印為 PDF"這樣的任務(wù)，Agent 需要連續(xù)執(zhí)行幾十個步驟。在這個過程中，環(huán)境往往一片死寂，不會告訴 Agent 中間某次點擊是對是錯，只有最后一步才能得到結(jié)果。

這種「長程視野 + 稀疏反饋 + 無限空間」的組合，構(gòu)成了 Agent 所在環(huán)境的真實面貌——它是一個充滿了摩擦的環(huán)境。我們不能再用訓(xùn)練聊天機器人的邏輯來訓(xùn)練 Agent。

對于創(chuàng)業(yè)公司而言，這意味著必須投入資源去構(gòu)建仿真訓(xùn)練環(huán)境，這比單純購買 H100 顯卡更考驗團隊的技術(shù)沉淀。

03基礎(chǔ)設(shè)施：太重、太貴、玩不起

如何解決環(huán)境問題？

在現(xiàn)場，不同的分享者分別從橫向擴展與縱向輕量化兩個維度，給出了 Infra 重構(gòu)的答案：解耦（Decoupling）。

橫向解耦：打破采樣與訓(xùn)練的同步鎖

面對 GUI Agent 交互速度極慢的問題，有研究者提出了一種名為 Dart（Decoupled Agent RL）的框架。

其核心邏輯是將采樣端與訓(xùn)練端在物理上徹底分開。

在這一架構(gòu)下，采樣端不再等待模型更新，而是利用 Kubernetes（K8s）并行啟動上百個 Docker 容器作為 Environment，持續(xù)不斷地生產(chǎn)軌跡數(shù)據(jù)。數(shù)據(jù)通過一個基于 MySQL 的軌跡管理器進行異步調(diào)度，再輸送給訓(xùn)練端。

這種設(shè)計雖然引入了 Off-policy（數(shù)據(jù)和模型不同步）的挑戰(zhàn)，需要通過數(shù)據(jù)篩選機制來平衡，但收益是巨大的，至少有三層：

• 消除了 GPU 等待環(huán)境反饋的空轉(zhuǎn)時間

• 實現(xiàn)了 5.5 倍的環(huán)境利用率提升

• 整體訓(xùn)練吞吐量翻了近一倍

這也意味著，Agent 的 Infra 必須具備處理異步數(shù)據(jù)流的能力，而非傳統(tǒng)的同步批處理，將訓(xùn)練過程轉(zhuǎn)變成了一個持續(xù)流動的、高吞吐的流水線。

Dart 框架

縱向解耦：降低算力門檻

Infra 的另一個痛點在于「重」。

現(xiàn)有的工業(yè)級框架（如 Verl, OpenRLHF）往往針對大規(guī)模集群，代碼量龐大且模塊耦合嚴重，對于學(xué)術(shù)界或資源受限的初創(chuàng)團隊而言，修改算法邏輯或適配小規(guī)模集群的門檻極高。

另一位研究者展示了輕量化的解耦思路——開發(fā)模塊化框架，將算法邏輯、模型架構(gòu)與分布式引擎分離。

這種 RL-Centric 的設(shè)計理念，把工程復(fù)雜度封裝在模塊邊界內(nèi)，實現(xiàn)了"邏輯即實現(xiàn)"——研究者可以像搭積木一樣，通過插件化配置自由組合 GAE、GRPO、PPO 等算法組件，大幅降低了處理底層分布式的負擔。

同時他們還通過 CPU Offload 技術(shù)實現(xiàn)了顯存復(fù)用——推理采樣時將訓(xùn)練參數(shù)卸載至 CPU，優(yōu)化更新時再加載回 GPU，顯著降低了硬件門檻。

RLLaVA 框架

所有這些技術(shù)細節(jié)背后的邏輯都趨于一致：要讓 AI Agent 可行，首先得把它的工位（基礎(chǔ)設(shè)施）配齊。現(xiàn)有的工具太重、太貴、太慢。因此，我們需要更輕量、模塊化的中間件，讓中小團隊也能玩得起 Agent 訓(xùn)練。

這也正是 Infra 領(lǐng)域的創(chuàng)業(yè)機會。

04Long Context 并不等同于記憶

算力和環(huán)境之外，另一個問題是狀態(tài)管理。

Transformer 架構(gòu)雖然強大，但它缺乏可讀寫存儲器，無法顯式地存儲或更新中間的推理狀態(tài)，也沒有循環(huán)或遞歸機制。

在處理簡單問答時，這種無狀態(tài)特性不是大問題；但在面對復(fù)雜的軟件開發(fā)或長程邏輯推理時，這種缺陷是致命的。

由于缺乏對推理狀態(tài)的有效管理，模型在解決復(fù)雜遞歸任務(wù)時，往往會出現(xiàn)推理鏈路斷裂或邏輯漂移。

這些問題，相信重度使用 AI 的用戶都能感受到。

學(xué)術(shù)界與工業(yè)界也正在嘗試從架構(gòu)底層進行修補。諸如Mamba 等 State Space Models（SSM）、Linear Attention 機制、Stack 機制，正在成為解決這一問題的熱門方向。

這些新架構(gòu)試圖通過更高效的狀態(tài)壓縮與傳遞機制，讓模型具備原生的狀態(tài)推演能力，從而彌補 Transformer 在長程狀態(tài)管理上的先天不足。

另一個思路是改變推理的載體。當前大多數(shù) Agent 依賴自然語言進行思維鏈推理，但自然語言在精確計算和狀態(tài)追蹤上有局限。

一種思路是讓模型學(xué)會用代碼思考——代碼天然具備變量、函數(shù)和邏輯流，比自然語言更適合精確的狀態(tài)管理。

Code Thinking

在工程落地層面，一個常見誤區(qū)是把 Long Context（長上下文）等同于"記憶"。但單純拉長上下文窗口既不經(jīng)濟也不實用。

實際場景中，記憶被劃分為兩類：用戶側(cè)記憶和執(zhí)行側(cè)記憶。前者類似傳統(tǒng)用戶畫像，記錄用戶偏好和基本信息，大多數(shù) AI 客服已具備雛形。后者是 Agent 自我進化的關(guān)鍵——不僅要記住「用戶是誰」，更要記住「我上次是如何完成任務(wù)的」，包括執(zhí)行軌跡和經(jīng)驗教訓(xùn)。

當再次遇到類似任務(wù)時，Agent 應(yīng)能復(fù)用成功路徑或規(guī)避踩過的坑，而非從零開始。

在記憶架構(gòu)上，一種思路是將其設(shè)計為file system 式的分層存儲。當 Agent 需要回顧時，它執(zhí)行的是讀取文件的操作，而非在上下文窗口中大海撈針。

對于一個系統(tǒng)而言，「記憶」的本質(zhì)不應(yīng)該是記住所有的對話歷史，而是能夠像計算機一樣，精確地管理每一個變量的周期與狀態(tài)。

總而言之，對于企業(yè)級應(yīng)用來說，客戶不在乎你的上下文窗口有多長，只在乎 AI 能不能記住「我上次說過什么」以及「公司的業(yè)務(wù)規(guī)則是什么」諸如此類問題。

解決健忘問題，是 Agent 從玩具走向企業(yè)級員工的入場券。

05護城河變了，

贏家也會變

盡管這場沙龍是一場偏向技術(shù)、工程層面的交流，但我們?nèi)阅軓闹刑崛〕龊芏嘈盘枴?/p>

過去我們認為護城河在于模型本身，但隨著開源模型能力的快速逼近，護城河正在從"單點模型能力"向"系統(tǒng)整合能力"擴展。

未來的贏家，不一定是模型最強的團隊，而是那些能通過優(yōu)秀的 Infra 架構(gòu)、低成本的數(shù)據(jù)閉環(huán)和高效的記憶管理，最大化釋放模型能力的團隊。工程化能力正在成為新的差異化來源。

其次，我們需要注意，賣鏟子的邏輯變了，Agent Infra 是被低估的洼地。

正如沙龍中所討論到的，為了讓 Agent 真正落地，我們需要全新的基礎(chǔ)設(shè)施，不是傳統(tǒng)的云計算，而是專門為 Agent 設(shè)計的諸如異步訓(xùn)練框架、解耦的采樣環(huán)境和向量化記憶文件系統(tǒng)之類的 Agent Native Infra。

目前的 Agent 開發(fā)棧依然非常原始。這意味著，誰能為 Agent 開發(fā)者提供好用的「IDE」、「調(diào)試器」和「虛擬訓(xùn)練場」，誰就有機會成為 AI 2.0 時代的 Databricks 或 Snowflake。

最后，隨著 GUI 等復(fù)雜場景的出現(xiàn)，人工標注的成本顯然已不可持續(xù)。

未來的數(shù)據(jù)壁壘，不再是誰爬取了更多的互聯(lián)網(wǎng)文本，而是誰能構(gòu)建更逼真的仿真環(huán)境，讓 Agent 在其中自我博弈、自我進化。這種通過 RL 產(chǎn)生的高質(zhì)量合成數(shù)據(jù)，將是下一階段最稀缺的資源。

我們永遠處在一個不斷出現(xiàn)噪音，排出噪音的商業(yè)環(huán)境中，Agent 的深水區(qū)才剛剛開始。

轉(zhuǎn)載原創(chuàng)文章請?zhí)砑游⑿牛篺ounderparker