本文來自微信公眾號： 葉小釵 ，作者：葉小釵，原文標(biāo)題：《這屆 Agent，全是草臺班子：到底什么 Agent 在產(chǎn)生價(jià)值？》
今年小龍蝦火爆得不行，也把很多老板搞得焦慮得不行，所以現(xiàn)階段Agent已經(jīng)成為了業(yè)內(nèi)普遍認(rèn)可的技術(shù)范式了。
并且今年又連續(xù)出了很多新名詞，又把很多想要學(xué)習(xí)的同學(xué)搞得很慌，但如果你真的想去學(xué)習(xí)或者了解Agent，可以從下面四個(gè)問題出發(fā)，可能會(huì)更接近本質(zhì)：
當(dāng)前常用Agent到底解決了哪些問題？
其次，我們在做技術(shù)選型的時(shí)候，什么時(shí)候選Agent，如何滿足老板/客戶的擠壓和真實(shí)的情況，因?yàn)槔习寤蛘呖蛻舨⒉恢繟gent的技術(shù)詳情，他就是要Agent，這時(shí)候該怎么辦？
然后，請深層次思考，為什么Agent這種架構(gòu)會(huì)出現(xiàn)，難道上述Agent解決的問題場景，其他技術(shù)路徑?jīng)]有辦法嗎？
最后就是，Agent這套技術(shù)架構(gòu)是如何解決哪些問題的，然后由于架構(gòu)原生問題，又帶來了哪些困擾？
比如第一個(gè)Agent解決了哪些問題？就有點(diǎn)難以下口，我們換個(gè)問題來反推這個(gè)答案：
首先，當(dāng)前到底什么Agent在被真實(shí)使用；
其次，這些Agent應(yīng)該如何做分類；
最后，每個(gè)品類Agent應(yīng)該有什么樣的標(biāo)簽；
什么Agent在被真實(shí)使用
首先，我們給真實(shí)使用下一個(gè)定義：
有用戶，這里要分三個(gè)階梯，微量用戶、少量用戶、大量用戶；
有活躍度。整體來說，使用頻繁，意思是不會(huì)因?yàn)楹闷嬗靡淮尉团苈?，這里也分三個(gè)階梯，用兩次就跑、多次使用、頻繁并依賴；
有持續(xù)付費(fèi)，這個(gè)分為，沒有付費(fèi)，續(xù)訂率低，續(xù)訂率高；
如果按照這個(gè)排列組合排下來，他應(yīng)該是這樣的(框架能做出來，但是里面的產(chǎn)品卻只能蒙，因?yàn)槲夷貌坏秸鎸?shí)數(shù)據(jù))：
從這張全景圖我們可以得到幾個(gè)重要啟示或者結(jié)論：
一、不存在通用Agent
當(dāng)前跑出來的Agent不解決通用問題，反而更專注特定場景下的連續(xù)性工作
在AI之前，我們面臨的實(shí)際問題是：流程是固定的（寫代碼/回客服），但輸入是千奇百怪的，傳統(tǒng)規(guī)則引擎搞不定，純?nèi)斯び痔F；
最經(jīng)典的案例就是群昵稱格式統(tǒng)一，如果沒有人出現(xiàn)是一定搞不定的，比如要求要求的格式是：昵稱-崗位-城市，就一定有人寫成昵稱-城市-崗位或者昵稱_崗位_城市等千奇百怪的格式。
而這東西代碼、正則表達(dá)式是搞不定的，這是大模型之前一直存在并困擾你我最大的難題。
所以對我來說，在利用AI的時(shí)候，最核心使用的是其泛化能力，這里AI乃至Agent最核心要解決的問題就出現(xiàn)了：
我會(huì)利用AI/Agent的泛化能力去解決確定性流程中的非確定性應(yīng)對
所以暫時(shí)就不存在什么賈維斯、萬能秘書、萬能員工這種東西，現(xiàn)在做得好的都是在特定場景里，把一類任務(wù)做深，比如：
Coding Agent：核心是理解代碼上下文；
客服Agent：核心是理解用戶意圖；
法律Agent：核心是理解案情事實(shí)；
醫(yī)療Agent：核心是采集患者病情，并輔助分診、診斷與后續(xù)管理；
企業(yè)流程Agent：核心是理解業(yè)務(wù)狀態(tài)，并推動(dòng)跨角色、跨系統(tǒng)流程流轉(zhuǎn)；
這些Agent做的都是【高密度、低創(chuàng)意、高容錯(cuò)】的臟活累活，最終達(dá)成的成果有兩點(diǎn)：
一、解決過程效率問題，解決我們在【查詢-推理-輸出】過程上消磨的時(shí)間；
比如過去的理想情況是寫代碼不需要翻文檔、寫文章不用查資料、客服不需要看話術(shù)和歷史聊天記錄；
二、解決持續(xù)性問題，在有些任務(wù)上，7x24小時(shí)是有可能的，而之前是不可能的，AI的出現(xiàn)就是要把快的部分變得指數(shù)級的快；
在結(jié)論一的基礎(chǔ)下，第二個(gè)結(jié)論應(yīng)運(yùn)而生：
二、受控的自由
生產(chǎn)級Agent對穩(wěn)定性或者說受控性要求極高
所以，Agent是在有明確邊界下的受控智能，也就是讓模型在可控范圍內(nèi)處理不確定性，所以這里也可以推出第三個(gè)結(jié)論：
三、Agent的價(jià)值在于智能
Agent的價(jià)值來源于智能，他受追捧的原因是人的惰性，但被詬病的原因是因?yàn)橹悄芩鶐淼腞eAct技術(shù)架構(gòu)，他存在著不穩(wěn)定、效率低、成本高的特點(diǎn)
因?yàn)樽非蟾M(jìn)一步的泛化能力的正確性/穩(wěn)定性而引入的Agent架構(gòu)，成功打開了潘多拉的魔盒，并且他已經(jīng)成為了被廣泛認(rèn)可的架構(gòu)了
換句話說，Agent極大的降低了工程維護(hù)復(fù)雜度、以及架構(gòu)設(shè)計(jì)復(fù)雜度，比如我們維護(hù)分支爆炸的問題、初期架構(gòu)設(shè)計(jì)全面性可以不足的問題（比如工作流有些分支想不到）；
但是，他同樣帶來了新的工程維護(hù)復(fù)雜度，包括架構(gòu)黑盒問題、調(diào)試難、觀測難等問題；
其次，由于架構(gòu)帶來的不穩(wěn)定性、效率低、成本高，也需要用更多的工程手段去解決：
上面的說法可能不準(zhǔn)確，好一點(diǎn)的說法是：
Agent并沒有降低復(fù)雜度，而是把顯式代碼復(fù)雜度轉(zhuǎn)移成了隱式數(shù)據(jù)與Prompt復(fù)雜度
以前維護(hù)100個(gè)if-else很痛苦，但現(xiàn)在維護(hù)一套復(fù)雜的ReAct循環(huán)、Tools描述和Few-shot示例同樣會(huì)很痛苦。
并且這里痛苦的點(diǎn)還是不一樣的：代碼BUG是確定的，Prompt BUG是隨機(jī)的。
然后就是，Agent架構(gòu)和Workflow并不是沖突的，他們應(yīng)該融合，也確實(shí)是融合了：Workflow負(fù)責(zé)確定性主干，Agent負(fù)責(zé)不確定性局部。
四、技術(shù)選型要看分類
首先，Agent的成功，非常依賴于場景，如果打開的話是該場景所具備的上下文。
現(xiàn)在很多公司都采購或者部署了數(shù)字員工平臺類Agent，比如WorkBuddy、釘釘悟空、甚至古早的Coze、DIfy。
但采購并不等于使用，要用好首先受限于員工的能力，其次受限于組織是否進(jìn)行了AI原生的改造，這里屬于組織課題，之前有探討這里不做展開。
但是左右的技術(shù)/AI負(fù)責(zé)人都可能會(huì)面臨相同的難題：老板要Agent，是因?yàn)槊襟w把Agent包裝成了“無所不能的孫悟空”。
我們這些實(shí)際去落地的就不能這么玩，如果一個(gè)技術(shù)路徑選錯(cuò)了，就會(huì)很難辦。
比如，我最近收到一個(gè)企業(yè)咨詢，他們做AI客服居然選的OpenClaw去做，最后結(jié)果是不穩(wěn)定、慢、還有點(diǎn)小貴，他問我怎么辦？他架構(gòu)都是錯(cuò)的，這還能怎么辦...
這里的策略首先是不能拒絕，其次也不能答應(yīng)，需要做的是真實(shí)的翻譯翻譯：大多數(shù)老板要的根本不是Agent，他要的是：降本提效、少出錯(cuò)、看起來先進(jìn)可以吹牛。
所以你的任務(wù)是把需求重新翻譯成工程問題：
第一類，提效已知任務(wù)，很可能API加RAG就夠了；
第二類，替代人工操作流，前提是先把SOP梳理清楚，至于最后選Agent還是其他路徑，可以再說；
第三類，高價(jià)值專業(yè)決策，這種場景最適合Agent，但如前所述，只能給AI受控的自由；
至此，我們最初前三個(gè)問題大概就已經(jīng)被解答過了（圖可以橫向滑動(dòng)）：
<<<左右滑動(dòng)見更多>>>
在這個(gè)基礎(chǔ)下，我們再次回歸思考一個(gè)問題：為什么Agent會(huì)出現(xiàn)？
為什么Agent會(huì)出現(xiàn)？
首先，模型當(dāng)前雖然很強(qiáng)大，但他是天生缺陷的，他本身只包含了訓(xùn)練后的內(nèi)置數(shù)據(jù)，這里就產(chǎn)生了第一個(gè)矛盾點(diǎn)：
當(dāng)前社會(huì)信息爆炸太嚴(yán)重，一個(gè)星期就可以發(fā)生很多事，模型首先不可能跟得上這個(gè)節(jié)奏；其次他也不會(huì)去跟這些節(jié)奏，因?yàn)榛ヂ?lián)網(wǎng)上多數(shù)數(shù)據(jù)是垃圾，模型不可能去吃這些垃圾，垃圾吃多了會(huì)影響智商的；
除了市面上的信息，各個(gè)企業(yè)還有很多自己私有的數(shù)據(jù)，這些數(shù)據(jù)全部需要跟模型交互，否則在公司場景下模型的意義就不大了；
所以，Agent出現(xiàn)的第一個(gè)原因是，他至少需要與外部世界進(jìn)行信息交流，尤其是一些垂直領(lǐng)域，如果數(shù)據(jù)不足，模型很容易胡言亂語的。
然后就是第二個(gè)原因，也是我們前面說的問題了：我們的產(chǎn)品難以應(yīng)付用戶無限的意圖，這里比較抽象，我們再舉個(gè)例子：
工作流打開就是if else，或者各種規(guī)則引擎，他能干什么，他能很好的解決：已知輸入、已知分支。比如：
用戶問退款，訂單已發(fā)貨，走A流程；
用戶問退款，訂單未發(fā)貨，走B流程；
用戶問發(fā)票，走C流程。
這套東西很穩(wěn)，也很便宜。但問題是，真實(shí)用戶不是這么說話的。用戶可能會(huì)說：
我昨天買的那個(gè)東西還沒收到，我不想要了
你們能不能處理下？
這句話里有退款、有物流、有訂單，還有可能涉及賠償。傳統(tǒng)規(guī)則引擎去做，就要提前把所有表達(dá)、狀態(tài)、組合情況都窮舉出來。于是問題來了：
業(yè)務(wù)分支是有限的，但用戶表達(dá)是無限的
這就是規(guī)則引擎的邊界，也是傳統(tǒng)編程的能力邊界，他做最核心邏輯還行，如果都想提前寫好，維護(hù)成本很高的。
我這邊真實(shí)案例就是，之前一個(gè)兄弟，他們是做客服的，最后那個(gè)Workflow流程自己都維護(hù)不動(dòng)了：
當(dāng)環(huán)境復(fù)雜度上升，Workflow的成本曲線會(huì)很難看：
在這個(gè)場景下Agent的泛化能力就出來了：先做意圖識別，再做步驟規(guī)劃，生成這次要的Workflow，這里因?yàn)橐ＷCWorkflow的正確性所以會(huì)有很多模型的自我質(zhì)疑，最終生成他認(rèn)為對的工作流：
至于這個(gè)工作流是不是真的對，就不好說了，雖然已經(jīng)加了很多循環(huán)驗(yàn)證了：
這里再加一句：
Agent解決的不是怎么回答的問題，而是給出了一套將問題編譯為可執(zhí)行計(jì)劃的框架，甚至于你把Agent這套架構(gòu)本身理解為一套Workflow也是可以的
他是一套用于生成工作流的工作流，這個(gè)也是一套現(xiàn)階段驗(yàn)證出來，很不錯(cuò)的范式
最后再總結(jié)一下：相較于Workflow，Agent架構(gòu)是一種工程架構(gòu)層面的優(yōu)化：
他把一部分原本由工程師在開發(fā)期顯式寫死的控制流（if/else、編排），遷移到運(yùn)行時(shí)由模型來決定（路由、工作流程）
他是用更多的成本（多輪推理+多次工具調(diào)用+更高延遲/Token），換開發(fā)與維護(hù)成本的下降（分支更少、擴(kuò)展更快、長尾更適配）
結(jié)語
所以，Agent沒那么玄乎，他又不是孫悟空...
它本質(zhì)上干的事就一件：把程序員寫死在代碼里的if-else，挪到了運(yùn)行時(shí)讓模型現(xiàn)掛。用AI的泛化能力去解決確定流程里的不確定部分。
當(dāng)然，代價(jià)也是明顯的：代碼Bug是確定的，Prompt Bug是隨機(jī)的。
以前維護(hù)100個(gè)分支頭疼，現(xiàn)在維護(hù)一套ReAct循環(huán)加幾十個(gè)工具描述，去構(gòu)造那套可觀測性日志系統(tǒng)，一樣掉頭發(fā)，只是疼法不同。
所以，其中優(yōu)劣大家自己下去感受吧，畢竟Agent跟Workflow又不是互斥的。