本文來自微信公眾號： 葉小釵 ，作者：葉小釵，原文標(biāo)題：《OpenClaw、WorkBuddy、Loop 工程：誰在火，誰有用，誰還在 Demo》
今年，市場被OpenClaw洗了一波，數(shù)字員工的概念開始撬動人心，隨后類似的Agent便如雨后春筍，比如Hermes、Aipy、WorkBuddy、釘釘悟空、字節(jié)Aily...
與Agent相關(guān)的專業(yè)名詞也層出不窮，包括Context Engineering、ReAct、Harness、MCP、Skills、Agent Loop...
這種多且雜的局面，把很多人搞得很慌、搞得很亂。介于此，可以站在工程角度撥開這一層層迷霧，首先就可以從兩個問題開始：
第一，現(xiàn)在到底什么Agent在火，真正用得好的Agent是哪個品類，為什么？
第二，為什么Agent會出現(xiàn)？
Agent的場景分類
現(xiàn)階段絕大部分Agent的底層架構(gòu)（Model+Harness）高度趨同，所以對Agent分類意義不大，我們這里需要對其應(yīng)用場景做工程化分類。
這里第一步，我們先窮舉下當(dāng)前市面上有數(shù)的Agent場景：
內(nèi)容生成/創(chuàng)意生產(chǎn)場景；
搜索/研究/知識問答場景；
數(shù)字員工/個人助理場景；
數(shù)字員工平臺/企業(yè)協(xié)同場景；
Coding場景；
客服/AI CRM場景；
專業(yè)服務(wù)場景：醫(yī)療、法律、金融；
現(xiàn)在我們按照火爆、使用程度簡單做下梳理：
一、真火+真有用
要進(jìn)入第一梯隊有幾個硬性要求：大規(guī)模、高粘性、有付費、生產(chǎn)價值清晰，其中是否有人付費是檢驗一個AI工具是否有用的金標(biāo)準(zhǔn)。
現(xiàn)階段符合這個要求的有三類產(chǎn)品：Coding Agent、AIGC與AI客服。
無論是最初的Cursor還是現(xiàn)在的Claude Code、CodeX，他們都在持續(xù)證明一件事：Coding Agent是唯一被大規(guī)模驗證的【真Agent】賽道，日活千萬級，企業(yè)批量采購。
其次是AIGC，這塊也是火得不行，月活上億，但這個東西可能不應(yīng)該被稱為Agent，他其實是AIGC工具。
怎么說呢，Agent是自主完成多步驟任務(wù)，AIGC是輸入Prompt→輸出單次結(jié)果的范式，門檻極低，幾乎就是工具使用。
包括SeeDance2.0的使用，一天就能學(xué)會，但如果要用得好、出的視頻效果好，功夫肯定是在故事框架、連續(xù)敘事能力這些地方。
當(dāng)然，如果把AIGC工具當(dāng)做基礎(chǔ)設(shè)施，在上面架構(gòu)AI漫劇工作流，那就另說了。
最后就是AI客服/AI CRM，都是悶聲發(fā)大財?shù)默F(xiàn)金牛，這是真實可以節(jié)約能力成本的存在，我之前AI客服拿到的成績是10倍提效，團隊ROI很容易被算清楚。
但這東西只能勉強算作Agent，他最核心的模塊是嚴(yán)肅知識問答，這部分大概率不會使用ReAct架構(gòu)，在此基礎(chǔ)上會疊加其他Agent功能。
二、垂直火+門檻高
其次就是專業(yè)領(lǐng)域的Agent了，他們的特點是AI的專業(yè)能力比肩真人，大多數(shù)時候（98%+）能解決問題，但受限于倫理、法律，AI實際做得還有限。代表是：
醫(yī)療：OpenEvidence、阿福、未來醫(yī)生；
法律：Harvey、Lexis+AI
金融：...
這類產(chǎn)品專業(yè)價值高，但因為醫(yī)療、法律、金融這些場景的正確性壓力太大，其實現(xiàn)成本也高，他需要證據(jù)鏈、引用溯源、專業(yè)人士審核、法理通道...
嚴(yán)格來說，Coding Agent應(yīng)該被放到這個品類，因為他們都是協(xié)作型Agent，需要使用者對他的輸出有一定判斷能力；
但因為Coding Agent走得太遠(yuǎn)，又是通用型生產(chǎn)工具，所以被拿出去了，但從實現(xiàn)路徑上，他們會很類似。
另一方面，這種工具一旦要2C使用，那么其實現(xiàn)成本，尤其是對數(shù)據(jù)的要求會非常高！
三、有用戶+有入口+待驗證
辦公入口型Agent這個品類是今年立起來的，幾個代表是：
騰訊WorkBuddy；
釘釘悟空；
飛書Aily/也可能是Coze3.0；
...
就我咨詢企業(yè)觀察所得，現(xiàn)階段很多企業(yè)傾向于使用WorkBuddy這類辦公類Agent作為承載工作流的工具（意思是要把重復(fù)工作干掉）。
只不過理想很豐滿，現(xiàn)實是他們最多用這類工具做些文案生成或者簡單數(shù)據(jù)分析工作。
因為這類東西想要進(jìn)一步推動已經(jīng)不只是工具層面的問題了，他需要面臨各種組織復(fù)雜度衍生的管理問題，包括：SOP混亂、標(biāo)準(zhǔn)不清、跨部門協(xié)作難等。
所以，雖然大家都在搶AI Office的入口，但離最終的數(shù)字員工平臺還很遠(yuǎn)，因為那就不是平臺公司能解決的，除非他們有大量FDE能夠駐場下去...
四、概念火、Demo火、使用存疑
這一塊的典型代表要屬今年爆火的小龍蝦OpenClaw，網(wǎng)上各種瘋傳他神乎其技的案例，這也是普通人想象中最符合要求的數(shù)字員工形象。
只不過，你真的把這東西打開就完犢子了，他很多看起來很屌的案例在真實世界并不是那么回事：
Demo都是在各種有限前提的環(huán)境里，而通用執(zhí)行的Agent面對的是真實世界，真實世界就很難穩(wěn)定了...
真實世界什么都會變，頁面會變、用戶目標(biāo)會不停來回變、各種狀態(tài)也會變...
所以，OpenClaw這類產(chǎn)品真實狀態(tài)是：傳播火，但高頻留存和真實使用這塊要打個大大的問候，如果你問我他最大的價值是什么，我會說：
OpenClaw狠狠的教育了市場，他讓老板們知道Agent可以干活了
在這個基礎(chǔ)上他才便宜了WorkBuddy等數(shù)字員工平臺
還有其他Agent，我們這里就不再展開了，接下來我們來嘗試場景分類：
分類模型
我們這里首先選兩個分類維度：
第一，容錯空間，也就是AI輸出錯了，代價有多大？
高容錯：錯了可以改，用戶損失小，結(jié)果偏創(chuàng)意、偏草稿、偏輔助；
低容錯：錯了會造成生產(chǎn)事故、法律風(fēng)險、資金損失。
第二：行動復(fù)雜度，所謂復(fù)雜度就是AI除了輸出內(nèi)容外有接入什么復(fù)雜度的系統(tǒng)、解決多復(fù)雜的流程，關(guān)注的核心是步數(shù)和工具調(diào)用數(shù)。
低行動復(fù)雜度：只做檢索、分析、總結(jié)等工作；
高行動復(fù)雜度：這里我們稍微寫全面點，包括調(diào)API、操作瀏覽器、改文件、發(fā)郵件、查訂單、改狀態(tài)、創(chuàng)建工單、提交審批、生成PR、發(fā)起退款等。
在這個基礎(chǔ)下，四象限就出來了，我們出張表：
Agent有用的前提
如前所述，今天真正被大規(guī)模使用、企業(yè)持續(xù)付費的Agent（這塊不考慮AIGC了），只有兩個品類：Coding Agent和AI客服。
它們的共同點是，能夠有效提升效率，是生產(chǎn)力工具本身，但他們之間又有所不同：
Coding Agent是協(xié)作型Agent，他對容錯性有要求，但不那么高；
AI客服是流程執(zhí)行型Agent，他對容錯性要求極低，并且因為生產(chǎn)環(huán)境兩大，所以對成本和效率是有要求的；
除此之外，還有很多看起來很火、但還沒解決問題的Agent，其中三個典型案例是專業(yè)Agent、辦公協(xié)同Agent和個人助手Agent：
專業(yè)Agent如AI醫(yī)生，從專業(yè)能力上來說已經(jīng)達(dá)到了真人水準(zhǔn)，但當(dāng)前受制于法規(guī)現(xiàn)在還不能大規(guī)模應(yīng)用；
辦公協(xié)同Agent，潛力巨大，但當(dāng)前被企業(yè)數(shù)字化底座卡死了，因為很多企業(yè)搞不明白SOP和數(shù)據(jù)，這里有大量管理工作要做；
個人助手Agent，能做的十分有限，一方面是多數(shù)人沒意識沉淀自己的Skills和私有數(shù)據(jù)，另一方面是他們這些東西也沒什么價值；
綜上，如果要判斷一個Agent是不是真火，可能還是要從他是否成為了生產(chǎn)工具展開，而生產(chǎn)力工具是結(jié)果，一個Agent能不能真正成長起來還是有很多前提的，比如那些已經(jīng)跑出來的Agent他的共同特點是什么呢？
一、環(huán)境高度數(shù)字化
這是最硬核的前提，這點做不到，后續(xù)就不好展開。
Agent的所處環(huán)境要求一定要是數(shù)字原生的，比如代碼倉庫/數(shù)據(jù)庫/工單系統(tǒng)撒的，他們要有清晰的接口，比如之前GUI的系統(tǒng)，需要做CLI的改造，這樣會更適應(yīng)于AI的要求。
這里Coding Agent大家都懂，不必多說；
就AI客服來說，知識庫充足只是第一步，如果數(shù)字底座做得不好，很多數(shù)據(jù)、很多行為都沒法進(jìn)行的，比如查個訂單都難受。
二、存在即時反饋閉環(huán)
反饋閉環(huán)是Agent能否自主迭代的關(guān)鍵，比如：
Coding Agent有問題，代碼會報錯、界面會點不動；
AI客服回答錯了，客服會罵娘、會要求人工；
這里要存在反饋通路，我們需要根據(jù)反饋通路統(tǒng)計Bad Case，從而才能構(gòu)建數(shù)據(jù)飛輪。
三、高ROI
最后一點很樸實，你這個Agent的引入對企業(yè)來說ROI如何，這也是我們說你的Agent一定要是個生產(chǎn)力工具，這里無論Coding Agent還是AI客服都做得很好。
大家這里要注意，如果對于企業(yè)ROI很低，就算對于個人效率很高的事情，他們也不會做。
企業(yè)偶爾會Coding Agent買單，但絕對不會為你的營銷文案或者PPT買單，而只要ROI算不明白，就不會存在買單這回事，比如：
某頭部互聯(lián)網(wǎng)公司，他們半年前鼓勵全員用AI，每個員工配了幾千元的Token費用，這個月開始，這個費用砍半，因為他們自己也沒發(fā)現(xiàn)這個費用產(chǎn)生了什么價值。
接下來，我們也聊聊那些火起來了，但是有爭議性的Agent為什么還沒站起來的原因：
一、全行業(yè)的數(shù)字底座還沒建設(shè)好
要說Demo驚艷但實際效果不行的Agent，這里首推OpenClaw，他的Demo在固定瀏覽器、固定登錄態(tài)、固定網(wǎng)頁中進(jìn)行，表現(xiàn)優(yōu)異，但一到真實世界就完蛋，他完蛋有很多因素：
全行業(yè)的數(shù)字底座還沒建設(shè)好，我們希望使用API去操作，但卻只能通過GUI去操作（Browser-Use），這東西容錯率很低；
ReAct框架帶來的循環(huán)，成本有點吃緊；
二、企業(yè)數(shù)字基座不行
然后就是辦公協(xié)同/數(shù)字員工平臺類Agent（WorkBuddy、釘釘悟空）了，他們的難以產(chǎn)生價值的最大原因就是企業(yè)數(shù)字化跟不上。
并且，暫時也不能證明企業(yè)數(shù)字化跟上了，這類Agent的ROI就一定高
我們之前為了幫一個企業(yè)實現(xiàn)業(yè)務(wù)AI原生化，直接派了一個總監(jiān)級FDE去駐場了3個月時間?。。?/p>
其中多數(shù)的時間都是在做數(shù)字基座、部門對接標(biāo)準(zhǔn)的工作，所以國內(nèi)幾個數(shù)字員工平臺要做好，可能也得復(fù)制這條路，只不過就做得挺重的了。
三、個人數(shù)字基座不行
現(xiàn)階段很多人都在用Agent，但與其說他們是助理不如說他們是鬧鐘。
這里面依舊會有很多數(shù)據(jù)建設(shè)和風(fēng)險問題，比如我是絕對不會把自己的支付類賬號給AI的，誰知道他訂機票的時候會玩出什么花呢？
四、風(fēng)險+法規(guī)問題
最后就是很多專業(yè)類Agent，現(xiàn)在能力也許到那里了，基本數(shù)字平臺也準(zhǔn)備好了，但是依舊會受限于政策法規(guī)，還需要徐徐圖之。
最后總結(jié)一下，跑出來的Agent至少要具備數(shù)據(jù)充足+ROI為正+能自進(jìn)化的特點，說白了就是：能不能成為穩(wěn)定不出錯成本低的生產(chǎn)工具。
在這個基礎(chǔ)上，我們再來探討為什么需要Agent的問題：
為什么需要Agent？
關(guān)于Agent為什么會出現(xiàn)，我們跳過模型需要外部數(shù)據(jù)這種基本解釋，直接進(jìn)入終極答案，因為：
用戶無限的意圖難以被有限的古法編程所覆蓋
這句話是什么意思呢？我覺得可以從兩點做展開：
核心流程的泛化能力，借助AI實現(xiàn)核心Workflow的泛化，也就是我們常說的Agentic Workflow；
跳出流程的補足能力，這個場景是Agent完全進(jìn)入了現(xiàn)實不知道的場景，但依靠著AI的能力也把實現(xiàn)步驟生成出來了；
這里說得有點抽象，我翻譯翻譯：以前我們寫代碼，程序員需要將所有可能性都提前想好，用if...else...的方式去做流程；
但是用戶的腦子并不會完全照著既定的流程來，他們今天想查天氣、明天就會問你哪個機票最便宜，這也是說意圖/需求是無窮的，難以全部寫到如果里，這里有實際的案例：
我們一個同學(xué)是某客服公司的CTO，上圖是他們某個核心業(yè)務(wù)的工作流圖，他最開始非常簡單，但就是不停的補充用戶的“微調(diào)需求”而變得特別復(fù)雜，3年下來程序員已經(jīng)到了不想改、也改不動的狀態(tài)了，維護成本極高。
再比如，原本公司內(nèi)部有一個處理客戶投訴的老流程（接收->分類->轉(zhuǎn)人工->回復(fù)），使用Agent重構(gòu)后，這個老流程就變聰明了，他會圍繞這個大框架做事，但又會在每個環(huán)節(jié)上疊加必要的小插曲。
然后我們再說說這個跳出流程的補足，也就是完全未知的場景。之前還至少有個框架，后面完全就是Agent自由發(fā)揮了，這里也舉個經(jīng)典案例：
我之前使用釘釘文檔時遭遇了一個問題：文檔空間快滿了，系統(tǒng)提醒你處理，但彈出框上沒有任何引導(dǎo)，點擊下就關(guān)了，所以要升級需要進(jìn)入巨復(fù)雜無比的后臺，也就是這個界面：
于是這里問就來了：
我只是文檔空間滿了，系統(tǒng)提示充值，我并不知道怎么充值；
我本身不想充值，最好能夠不充值解決問題；
類似的問題是很多的，比如一不小心就開啟了京東白條，但等要關(guān)閉的時候，我感受到了噩夢！
他們都是那種直接給我干得一眼抓瞎，TMD還得重頭學(xué)習(xí)，甚至還得搜攻略的東西（這些家伙絕壁是故意的）！
這個時候就進(jìn)入了前文所述：“完全未知場景”，而這個場景卻是Agent可以覆蓋并解決的經(jīng)典Case，當(dāng)然前提是需要完成數(shù)字化底座的改造，這里最簡單的策略就是API CLI化。
比如前面訂單的場景會如何發(fā)生呢？我們來簡單模擬下，對Agent說：
我的釘釘文檔空間滿了，你幫我看看怎么處理。
Agent接到請求后，現(xiàn)場推理出解決路徑，并逐條調(diào)用宿主暴露的CLI能力：
第一輪
Agent先查用量，模型輸出工具調(diào)用：
{"name":"doc_space_usage","arguments":{}}
宿主映射為底層執(zhí)行：
dingtalk doc-space usage--output json
返回：
{"used_gb":2.1,"capacity_gb":2,"status":"exceeded"}
第二輪
確認(rèn)超限后，Agent調(diào)權(quán)限檢查：
dingtalk doc-space permission-check--output json
返回：
{"allowed":true,"admin":"葉小釵"}
第三輪
Agent發(fā)現(xiàn)可以升級，轉(zhuǎn)而生成一條申請文案并且釘釘消息給我確認(rèn)，并調(diào)通知接口：
dingtalk message send--to葉小釵--text"當(dāng)前空間2.1G/2G已滿，建議升級至pro_10g（￥99/月），確認(rèn)后立即生效，是否執(zhí)行？"
等我回復(fù)“確認(rèn)”后，Agent才會執(zhí)行真正的升級命令：
dingtalk doc-space upgrade--plan pro_10g--confirm--output json
整個過程的關(guān)鍵在于兩點：
所有的CLI是什么，Agent全部知曉；
模型有能力根據(jù)這些CLI排列組合處正確的執(zhí)行步驟；
綜上，就是Agent真正出現(xiàn)的原因，很多朋友的業(yè)務(wù)太簡單的，根本不能顯示出Agent的為例，但另一方面如果Agent權(quán)限過大也會很危險。
泛化與工程代價
至此可以給出階段性結(jié)論了：
Agent的價值在于泛化，泛化本身就會引起很多問題
傳統(tǒng)Workflow最大的問題是太死板，所有流程都需要提前設(shè)計，所以一旦用戶意圖變復(fù)雜，流程就會越來越臃腫，維護成本也會越來越高。
Agent不再要求程序員把所有路徑都提前寫死，而是讓模型根據(jù)用戶目標(biāo)、當(dāng)前狀態(tài)、可用工具，動態(tài)規(guī)劃出一條執(zhí)行路徑，這當(dāng)然很爽。
但問題也來了：模型動態(tài)規(guī)劃，就一定會帶來不確定性，比如：
輸入目標(biāo)→理解意圖→制定計劃→調(diào)用工具→觀察結(jié)果→修正計劃→繼續(xù)執(zhí)行
這個鏈路越長，變量就越多，所以我們之前才有Agent是一種Token換架構(gòu)的說法：
Agent用更高的計算成本、效率成本和穩(wěn)定性成本，換取更強的場景泛化能力
總結(jié)下來，這里的工程問題有四點：
第一，穩(wěn)定性差
典型表現(xiàn)是相同的輸入拿不到相同的輸出，他包括：
同一個任務(wù)，今天跑通，明天不一定跑通；
這個用戶能跑通，那個用戶不一定能跑通；
測試環(huán)境能跑通，生產(chǎn)環(huán)境不一定能跑通；
...
第二，效率低+成本高
這兩點都沒辦法，因為Agent的底層是ReAct循環(huán)，他為了保證穩(wěn)定性，只能不斷的確定、不斷的校準(zhǔn)。
但是真正的生產(chǎn)環(huán)境不會那么呆板，實際在跑的程序多半是Workflow+Agent的組合，幾乎80%的核心場景20%工作流就搞定了，剩下的20%場景就交給Agent使出80%的力氣就好。
第三，難治理
這也許是AI/Agent項目難或者說非對稱性高的核心原因，傳統(tǒng)程序出問題可以看日志、看代碼，他的定位邏輯是很清晰的；
但Agent出錯就是很多黑盒了，什么意思呢？意思是你得一個一個試，比如：
它為什么這么理解？
為什么選這個工具？
為什么跳過那個步驟？
為什么沒有轉(zhuǎn)人工？
有些同學(xué)可能有點不懂，我這里簡單說兩句什么叫一個個試，這里涉及到了可觀測性和測試數(shù)據(jù)集了，舉個例子：明明該調(diào)用某個工具，它卻沒調(diào)用，或者調(diào)用了另一個工具？
遇到這種錯，我們的解決方式是逐個修補、反復(fù)試探：
先收集錯誤Case；
然后思考為什么意圖A會匹配到工具B；
微調(diào)工具描述、命名甚至提示詞；
改完后先用失敗用例做驗證，反復(fù)跑；
...
測試數(shù)據(jù)集也是這樣形成的，都是一些小數(shù)據(jù)：有問題輸入、錯誤工具調(diào)用集、參數(shù)提取錯誤Case......
這些東西，每次發(fā)布或者模型更新都得先跑一次，總之挺煩人的，AI項目并沒有大家想的那么高大上，全部在做治理...
為什么跑出來的是Coding Agent和AI客服？
上述也是為什么Agent這塊反復(fù)出現(xiàn)新名詞的原因，無論是MCP、Skills、提示詞工程、上下文工程還是最近集大成的Harness，他們都是為了解決實際工程問題而生。
理解了這一點，我們再回頭看為什么跑出來的是Coding Agent和AI客服？因為他們天然就存在于在高度結(jié)構(gòu)化的數(shù)字環(huán)境里，也很容易做到可觀測性。
Loop工程
理解到這里，我們再來看今年很火的Loop Engineering，就不容易被名詞帶偏了，他解決的是如何讓Agent穩(wěn)定執(zhí)行的問題，也就是說構(gòu)造執(zhí)行環(huán)境的問題。
因為前面我們已經(jīng)說了，Agent的泛化能力一定會帶來不穩(wěn)定、低效率、高成本和難治理的問題。
那Loop工程要解決的，就是怎么把這些問題兜住，他是面向生產(chǎn)級Agent的協(xié)作與治理工程，如果你要打開，會發(fā)現(xiàn)全部是些策略，比如：
結(jié)語
今天我們聊了很多內(nèi)容：
什么Agent在火；
Agent為什么出現(xiàn)；
用好Agent的工程代價是什么；
其實搞這么多事情，最終都是想要回答一個問題：企業(yè)要如何把Agent用好？而這里的答案應(yīng)該也很清晰了：
為Agent構(gòu)造工程環(huán)境+數(shù)字原生底座
這也是很多公司實際在做的事情：追求AI原生。
只不過現(xiàn)階段行業(yè)對于AI原生概念是很模糊的，也沒有個通用的最佳實踐，于是容易出現(xiàn)兩個極端：
一上來就喊AI原生、數(shù)字員工、Agent化組織；
把AI只當(dāng)成個人工具；
根據(jù)之前實踐，普通企業(yè)進(jìn)入AI原生團隊，應(yīng)該是一個漸進(jìn)過程：
L1個人工具
L2團隊助手
L3流程節(jié)點
L4數(shù)字員工
L5原生組織基建
判斷一個團隊是不是AI原生團隊，需要從業(yè)務(wù)出發(fā)看他們在用AI做什么，這里就又要回歸三類核心資產(chǎn)了：
第一，工程能力：能不能把AI做成穩(wěn)定系統(tǒng)；
第二，行業(yè)認(rèn)知：能不能把業(yè)務(wù)Know-how梳理成SOP/Workflow/判斷規(guī)則；
第三，優(yōu)質(zhì)數(shù)據(jù)：能不能把業(yè)務(wù)過程、專家經(jīng)驗、錯誤案例、反饋結(jié)果沉淀成數(shù)據(jù)資產(chǎn)。
畢竟，前面AI切入團隊的七種方式，沒有一種對員工能力是低要求的...
工程能力決定AI能不能跑起來。Demo可以很簡單，但真實項目要調(diào)工具、控成本、做評測，還要能兜底和迭代。沒有工程能力，AI項目很難從Demo走向生產(chǎn)。
行業(yè)認(rèn)知決定AI有沒有業(yè)務(wù)價值。AI不只是回答問題，更要理解業(yè)務(wù)流程、判斷標(biāo)準(zhǔn)和風(fēng)險邊界。沒有行業(yè)Know-how，AI只能做通用問答，很難解決真問題。
優(yōu)質(zhì)數(shù)據(jù)決定AI能不能越用越好。聊天記錄、文檔和表格不等于數(shù)據(jù)資產(chǎn)。真正有價值的數(shù)據(jù)，必須能被結(jié)構(gòu)化、追溯、反饋和評測。否則AI項目很容易上線即巔峰，后面越用越差。
好了，篇幅已經(jīng)不小了，今天的內(nèi)容就到這，希望對各位有用！