曲凱：Agent 是當(dāng)下絕對的風(fēng)口。關(guān)于 Agent 這個話題，我自己有一些核心在思考的問題，相信也是很多人同樣會有疑問的地方。所以今天我們請來了長時間對 Agent 有研究和實操的文鋒，想就這些問題展開一些討論。

首先我想問，到底怎么定義 Agent？

文鋒：我認(rèn)為最好的就是 Anthropic 的定義：Agent 是讓模型基于環(huán)境反饋去使用工具的一個程序。

曲凱：那你怎么看最近這波 Agent 熱？

文鋒：這波 Agent 跟過去非常不一樣。

23 年 4 月以 AutoGPT 為代表的那一波里，Agent 更像是一個玩具，demo 都很炫，但實際應(yīng)用價值很有限。

經(jīng)過兩年的發(fā)展，這波 Agent 確實能夠在實際的工作和生活場景中解決問題，為大家?guī)韮r值了。

之所以會有這種躍遷，一是因為底層模型能力有了很大的進(jìn)步，尤其是在結(jié)合了 RL 之后，以 o1 為代表的模型還賦予了 Agent 長思維能力。

二是因為 Agent 的工程側(cè)和產(chǎn)品側(cè)也有很大的突破，主要表現(xiàn)就是大家更知道該怎么給 Agent 構(gòu)建一個合適的 Context，從而更好地解決問題了。

曲凱：怎么理解這個 Context？

文鋒：Context 指的就是大模型執(zhí)行任務(wù)時所需的各種信息的總和。

具體來說，不同產(chǎn)品的 Context 都不太一樣。拿我們的產(chǎn)品舉個例子， Sheet0 是一個 Data Agent，核心目標(biāo)是打通整個數(shù)據(jù)工作流，讓 Agent 自動完成在網(wǎng)頁上收集數(shù)據(jù)、處理數(shù)據(jù)，再到基于數(shù)據(jù)采取行動的全過程。

我們的 Context 就包括網(wǎng)頁、收集整理的數(shù)據(jù)表格、用戶下達(dá)的指令，以及分析數(shù)據(jù)時生成的一些 SQL 等等。

曲凱：但 Agent 中的 Context 有什么不同？因為大家做其它產(chǎn)品時，好像也約定俗成地會把各種信息收集起來，然后加到 Prompt 或者是 RAG 中去使用。

文鋒：核心區(qū)別在于 Context 的來源。

還以 Sheet0 為例，如果用之前 RAG 之類的方式，會有很多需要人工干預(yù)的步驟，比如網(wǎng)頁里有很多無關(guān)緊要的信息，那就需要人工把有效信息提取出來，再比如過程中生成了一個 SQL，也需要人工校驗它的準(zhǔn)確性。

但在 Agent 中，這些信息會以某種自動化的形式被提煉出來，不需要人的參與。

曲凱：明白。然后最近大家經(jīng)常聽到 Function Call、MCP、A2A、Computer Use、Browser Use 等概念，能不能幫大家快速梳理一下它們之間的區(qū)別？

文鋒：這些概念本質(zhì)上都是在解決同一個問題，就是讓大模型更有效地通過工具調(diào)用 (Tool Use) 去執(zhí)行任務(wù)。

Function Call 最早由 OpenAI 提出，能夠讓大模型通過調(diào)用外部函數(shù)實現(xiàn) Tool Use。但是因為不同系統(tǒng)的調(diào)用標(biāo)準(zhǔn)都不太一樣，就好比 +86 的手機號在美國就沒法接打電話一樣，很可能你到了另外一個國家，就得把所有東西都重做一遍，所以它不太通用。

為了解決這個問題，就有了 MCP（Multi-Component Program）。MCP 的核心價值在于「統(tǒng)一了 Tool Use 的度量衡」，極大地降低了這件事的門檻。它可以把任務(wù)拆解成多個子任務(wù)，而每個子任務(wù)都有模塊化、有統(tǒng)一標(biāo)準(zhǔn)的組件。通過這種方式，最后大家就能更加自由地調(diào)用各種工具。

至于 Google 最近推出的 A2A，我認(rèn)為它并沒有提供新的技術(shù)解決方案，更像是一個大廠為了爭奪 Tool Use 話語權(quán)而強行推出的 KPI 工程，然后找了一堆合作伙伴來推廣。

A2A 號稱自己和 MCP 的區(qū)別在于，MCP 只能讓 Agent 通過函數(shù)接口去調(diào)用外部工具或者 API，而 A2A 卻可以實現(xiàn) Agent 之間的交互。但其實這兩種交互方式并沒有本質(zhì)區(qū)別，因為 Agent 本身也有函數(shù)調(diào)用的接口，所以 MCP 也能間接實現(xiàn) Agent 之間的交互。

Computer Use 和 Browser Use 指的是讓大模型把電腦和瀏覽器作為工具來調(diào)用。瀏覽器可能是大模型目前能調(diào)用的最重要的工具之一。

曲凱：我聽下來感覺這些 Tool Use 方案整體分為兩派，一派是 Function Call、MCP、A2A，背后的邏輯是直接用代碼來解決問題，另一派是 Computer Use 和 Browser Use ，會結(jié)合一些視覺識別或者是 RPA (機器人流程自動化) 的方案，模擬人類來解決問題。

文鋒：是的。但這兩派并不互斥，比如你也可以用 MCP 的方式來進(jìn)行 Browser Use。

Browser Use 本質(zhì)上是讓 Agent 通過 GUI (圖形用戶界面) 與網(wǎng)頁進(jìn)行交互。具體來說，可能后端的大模型會收到一張瀏覽器的截圖，然后去判斷上面的交互元素、推算出一個坐標(biāo)，之后再在前端模擬人類的一系列操作，比如驅(qū)動鼠標(biāo)移動到那個坐標(biāo)上點擊一下，或者輸入一些內(nèi)容，就好像 Agent 真的在使用瀏覽器一樣。

但這個純視覺的方案還遠(yuǎn)遠(yuǎn)不夠成熟。國外有一家在 23、24 年非常火的叫 Adept 的公司就是這么做的，但這家公司現(xiàn)在已經(jīng)死了，因為這個事太難了。

所以實際上，現(xiàn)在大家調(diào)用 Browser Use 時，通常需要 MCP 作為中間媒介。大家會把瀏覽器的 API 包裝成 MCP 的組件，然后通過代碼的形式讓 Agent 完成后續(xù)的操作。

曲凱：類似于 Agent 在前端給人演了一場戲?？此扑谀M人類的操作，其實背后還是代碼在驅(qū)動。

但畢竟很多公司還沒有兼容 MCP，甚至之后可能有的公司為了保護(hù)自己的用戶數(shù)據(jù)，更不愿意去兼容。那會不會之后大家就不得不用模擬人類的這種方式去進(jìn)行 Browser Use？

文鋒：MCP 是一個標(biāo)準(zhǔn)化的接口，所以這些 SaaS 軟件是不是兼容 MCP 不重要，重要的是它們有沒有 Open API，因為 Open API 都可以被包裝成 MCP 來使用。而在國外的軟件生態(tài)中，Open API 基本是標(biāo)配，所以 MCP 的適用范圍非常廣泛。

不過海內(nèi)外情況很不一樣，因為國內(nèi)大多數(shù)公司還沒有開放 Open API 或者 SDK（軟件開發(fā)工具包），所以這條路徑確實被堵住了。

曲凱：所以我們可以得出一個結(jié)論，如果未來公司能夠開放各種后端接口，那我們就可以直接通過代碼的方式去調(diào)用工具。如果不支持，那就只能通過視覺和模擬人類使用電腦的方式來解決問題。

文鋒：對。這兩種方案我們都試過，雖然現(xiàn)在視覺的方案在穩(wěn)定性和準(zhǔn)確度上還不夠高，比如我給 LLM 的截圖中有一個提交表單的按鈕，它常常會把那個坐標(biāo)算錯，但這種方式的優(yōu)勢是成本低、速度快，消耗的 token 至少會少一個數(shù)量級。

所以這兩種方案各有優(yōu)缺點，可以結(jié)合起來使用。至于具體如何結(jié)合才能更高效，就需要開發(fā)者根據(jù)實際需求調(diào)整配比了，因為每個 Agent 想解決的問題都不太一樣。

曲凱：說起來我想到前幾周我在美國時，有一個專業(yè)做 Agent 算法的人問過我一個問題。他非常不理解為什么 Manus 要用 Browser Use，因為在他的理解中，只要后端的代碼能打通，那就能直接解決所有問題了，沒必要再在前端搞個瀏覽器窗口。

你會怎么回答他這個問題？

文鋒：我們在設(shè)計 Agent 時，一個關(guān)鍵問題是怎么給用戶營造一個「可信的氛圍感」，讓用戶更相信 Agent 生成的結(jié)果。

為了做到這件事，非常重要的一個手段就是讓用戶以一種好理解的方式看到 Agent 執(zhí)行任務(wù)的全過程。

那瀏覽器就是一種天然對人更友好的呈現(xiàn)方式，遠(yuǎn)比代碼界面這種黑乎乎的窗口要來得生動、直觀。

曲凱：那 Devin、Manus、GenSpark 各自用的什么方案？

文鋒：Devin 和 Manus 都是 Coding 和 Computer Use 混合的方案。

至于 GenSpark，我用它跑了一些任務(wù)，感覺它可能也在后端調(diào)用了一些網(wǎng)頁的 API，但前端并沒有像 Devin 或者 Manus 那樣，通過瀏覽器窗口將網(wǎng)頁使用的過程暴露給用戶。

從這個角度講，我覺得 GenSpark 可能還不太符合我心目中 Agent 該有的體驗。

曲凱：但從用戶的角度來看，最終能解決問題不就行了？為什么要在意 Agent 后端到底有沒有在運行什么東西，或者能不能像人一樣使用電腦或瀏覽器？

文鋒：這是一個非常好的問題。

這個問題的核心在于要讓用戶時刻感受到自己在掌控一切，因為人都會有不安全感，那把一切都透明化就是建立安全感的關(guān)鍵所在。

舉個例子，假如你是我老板，然后給我分配了一個任務(wù)，如果我們之間要建立信任關(guān)系，可能就得讓你看到我是怎么做事的，并且能了解到我大致的思路。當(dāng)你足夠了解我之后，你才會對我產(chǎn)生信任。

曲凱：這點很 make sense。其實本質(zhì)上是大家覺得 Agent 還不 ready、不靠譜，所以需要看到它執(zhí)行任務(wù)的過程，也需要通過回答問題之類的方式時不時地參與到它執(zhí)行任務(wù)的過程中。

然后我覺得當(dāng)下市場對 Agent 的討論和理解，其實很像兩年前 LLM 那一波。當(dāng)時很多人都在討論未來究竟屬于通用的 AGI 模型，還是垂直領(lǐng)域的模型，又或者是創(chuàng)業(yè)公司自己開發(fā)的小模型等等。

那現(xiàn)在大家也開始討論 Agent 的終局會走向通用還是垂直。你怎么看這個問題？

文鋒：我認(rèn)為我們現(xiàn)在處于，并且將長期處于一個垂直 Agent 的時代。

我最近特別喜歡用做飯來舉例。很多人都會做飯，但我們做飯可能就是拿出手機、打開菜譜軟件，然后再照著菜譜一步步操作。

而一個更好的 Agent 就像是一位五星級酒店的大廚，受過多年的專業(yè)培訓(xùn)，不僅不需要菜譜，而且做出來的菜色香味俱全，比我們強很多倍。所以人家是大廚，我們只是會做飯的普通人。

曲凱：明白。然后至少在過去半年中，市場上最熱、拿到最多錢的兩條賽道就是 Agent 和 AI Coding。那最終 AI Coding 和以 Coding 為核心的 Agent 會殊途同歸嗎？

我原本覺得這兩條賽道井水不犯河水，但越來越覺得它們未來很有可能會走到一起，因為現(xiàn)在很多 Agent 都在用 AI Coding 的解決方案。

文鋒：而 AI Coding 那邊也在講 Coding 是一切的基礎(chǔ)設(shè)施（笑）。

曲凱：是啊哈哈，甚至前幾天我還看到一條新聞?wù)f Coding 可能也是未來 AGI 的基礎(chǔ)。

理論上講，AI Coding 和 Agent 最終好像確實可能會殊途同歸，舉個極端的例子，如果我們要做 Browser Use，其實完全可以讓 AI Coding 直接做出一個 Browser 然后自己去 Use，不是嗎？

文鋒：理論上是可以，但這種方式的經(jīng)濟成本和時間成本都太高了。

AI Coding 只能說是大模型執(zhí)行任務(wù)的一個強有力的工具，這個工具存在兩個關(guān)鍵問題，一是很難和其他工具協(xié)同，二是很難復(fù)用。

如果我們用 AI Coding 直接去執(zhí)行任務(wù)，那它需要先拆解任務(wù)，然后針對每個子任務(wù)逐一寫出能夠運行的程序，并且之后每遇到一個新任務(wù)，都要從頭到尾來這么一遍，非常低效且消耗成本。

所以對于 Agent 而言，最好的選擇是在解決任務(wù)時先看看手邊有沒有現(xiàn)成的工具，如果找了一圈實在沒有，再考慮用 AI Coding 現(xiàn)場造。

曲凱：明白。那 RL 和 Agent 之間的關(guān)系是怎樣的？創(chuàng)業(yè)公司最終應(yīng)該如何應(yīng)用 RL？

文鋒：Agent 這個概念本身就源于 RL，所以如果你不理解 RL，就很難理解 Agent 到底是什么，也就很難設(shè)計出一個好的產(chǎn)品。

那要做好 Agent，我們就先得了解 RL 中對 Agent 的定義。RL 中的 Agent 有三個要素：

1) 狀態(tài)，對應(yīng) Context。

2) 行動，對應(yīng) Tool Use。

3) 激勵信號，指的是當(dāng) LLM 采取行動后，用于評估它每一步操作的效果、指導(dǎo)它下一步行動的反饋信號。

那么對于創(chuàng)業(yè)公司而言，非常關(guān)鍵的就是如何在你的產(chǎn)品中打造出一個好的「環(huán)境」。這個環(huán)境需要清晰地描述當(dāng)前的狀態(tài)，Agent 可以采取哪些動作，也就是行動空間，以及對于結(jié)果好壞的定義。

其中，行動空間決定了你設(shè)計的 Workflow 中要有多少個節(jié)點。

而之所以一定要定義好結(jié)果，是因為只有這樣，你才有可能設(shè)計出一套有效的評估體系和激勵機制，進(jìn)而不斷讓 Agent 基于動態(tài)的反饋去自我迭代。

如果你沒定義好結(jié)果，那整個系統(tǒng)就沒辦法收斂。無法收斂就意味著最終 Agent 很可能給用戶一個質(zhì)量很差的結(jié)果，或者呈現(xiàn)出一種「什么都會一點、但什么都不精通」的狀態(tài)。

所以我也很建議所有 Agent 開發(fā)者和產(chǎn)品設(shè)計者都去讀一下強化學(xué)習(xí)之父 Richard Sutton 的《Reinforcement Learning: An Introduction》?？赐赀@本書你會收獲一個 mindset，讓你能夠在設(shè)計產(chǎn)品的時候不斷地思考、調(diào)整、定義你的環(huán)境。

曲凱：怎么評判環(huán)境的好壞？

文鋒：評判一個環(huán)境好不好，關(guān)鍵是要看這個環(huán)境能不能基于行動的結(jié)果來提供一個激勵信號。

這么看，IDE 就是一個好的環(huán)境，因為只要 Agent 生成一段代碼，就能立馬在 IDE 中運行，而一旦這段代碼跑不起來，IDE 就會生成一個報錯信息。這個報錯信息天然就是一個激勵信號。

曲凱：明白。那你覺得 Workflow 會完全被 Agent 取代嗎？

文鋒：不。我認(rèn)為 Workflow 和 Agent 會長期共存。

這兩者的本質(zhì)區(qū)別在于，Workflow 由人類驅(qū)動，而 Agent 由 AI 驅(qū)動。

人驅(qū)動的好處就是穩(wěn)定、可靠，但缺點就是它缺乏泛化能力，比較死板。AI 驅(qū)動則恰恰相反，它更泛化、更靈活，能應(yīng)對一些你事先沒想過的問題，但它的缺點就是不確定性很高，10 次里面可能有 5 次都會搞砸。

所以 Agent 適合解決世界上 20% 更開放、需要長期探索和試錯的任務(wù)，而其余 80% 更日常的問題，用 Workflow 完全足夠。

曲凱：你已經(jīng)做了一年多的 Agent，有積累哪些非共識的認(rèn)知嗎？

文鋒：我認(rèn)為「Chat」是 Agent 最重要的交互入口。

因為對于 Agent 來說，用戶交互的自由度是第一重要的事情，其重要性遠(yuǎn)高于交互的準(zhǔn)確度。

一旦你限制了用戶的自由度，其實就是在讓用戶來適應(yīng)你的產(chǎn)品，加重用戶的認(rèn)知負(fù)擔(dān)。而一個好的 Agent 應(yīng)該足夠智能，能讓用戶像幸福的小朋友一樣自由地使用它。

那么在現(xiàn)有的交互方式中，Chat 就是最能保障用戶交互自由度的形態(tài)。

當(dāng)然，并不是說準(zhǔn)確度就不重要，只是我認(rèn)為這不該是用戶需要承擔(dān)的問題，而應(yīng)該由開發(fā)者和產(chǎn)品設(shè)計者去解決。實際上，業(yè)界也有很多方法來提升準(zhǔn)確度，比如引入 Human-in-the-loop，或者像 Devin、Manus 那樣積累用戶偏好，再比如你也可以做更多的產(chǎn)品設(shè)計，比如通過向用戶提問，來引導(dǎo)用戶逐步把模糊的需求細(xì)化，直到變得具體可執(zhí)行。

你不需要額外設(shè)計很多接口，也不需要在前端堆砌太多組件，但可以在恰當(dāng)?shù)臅r機把合適的組件推到用戶面前。就算你設(shè)計了 200 個組件，但實際上用戶的需求都不大一樣，所以每個用戶可能只用得上其中的 10 個，那就沒必要把這 200 個組件全擺出來，徒增用戶的認(rèn)知負(fù)擔(dān)。

曲凱：綜合你說最后這點我很同意。單純一個聊天框不一定是最高效的交互方式，但如果在聊天框基礎(chǔ)上能結(jié)合一些場景推薦的 UI 組件，確實是一個挺合理的方案。

不過要實現(xiàn)這種交互形態(tài)，首先得做好意圖識別，判斷好用戶到底想要什么。而且意圖識別和 Context 好像是互為依賴的，Context 越多，模型就越有可能猜準(zhǔn)用戶的意圖；反過來，在理解了用戶的意圖之后，模型也需要更多 Context，來判斷該怎么做才能更好地完成整個任務(wù)。

文鋒：所以模型本身要有能力去判斷當(dāng)前的 Context 是否充分，如果不夠，就得通過調(diào)用外部 API，或者借助 RAG 之類的方式去獲取更多的 Context。

曲凱：這件事其實和模型本身的智能程度，還有垂直領(lǐng)域的 know-how 都很相關(guān)。

文鋒：是，另外開發(fā)者在 Agent 中預(yù)設(shè)的 System Prompt 也可以輔助模型的表現(xiàn)，像 Cursor 和 Windsurf 就有幾千行的 System Prompt。

曲凱：System Prompt 其實也只在垂直領(lǐng)域才奏效，因為你要寫出有針對性的 Prompt，就得知道用戶的目標(biāo)，而且你對這個領(lǐng)域越了解，寫出的 Prompt 可能就越精準(zhǔn)。

舉個例子，如果你要做一個專門搞研究的 Agent，那你就可以針對研究這個場景提前預(yù)設(shè)一個 System Prompt，因為它每次執(zhí)行任務(wù)都可以按照搜網(wǎng)頁、找數(shù)據(jù)和相關(guān)文章、摘要重點信息、最后輸出成 Excel 或 PPT 這個流程去操作，而且每一步都是獨立的，可以單獨進(jìn)行優(yōu)化。

但如果你要做一個通用 Agent，那面對用戶千差萬別的需求，你就很難寫出一個適配所有任務(wù)的 System Prompt。而且通用 Agent 每一步動作都高度依賴上一步的結(jié)果，所以很可能會「一步錯，步步錯」，拉低最終結(jié)果的準(zhǔn)確率。

文鋒：是的?？傊鹗质占降?Context 越多越好。

曲凱：所以我記得之前蘋果會記錄你打開某網(wǎng)頁之前剛看過的那個網(wǎng)頁，其實這就是在收集 Context。包括 OpenAI 最近剛出的記憶系統(tǒng)，本質(zhì)上也是在構(gòu)建一個 Context。

前幾周我和張月光吃了頓飯，他也提出了一個特別好的觀點。

他說你點開某個 APP 的那一瞬間，其實就已經(jīng)提供了海量 Context。比如你點開美團大概率就是想點外賣，點開滴滴就是想打車，所以這些 APP 的產(chǎn)品設(shè)計都是基于這些 Context 展開的。

然后用戶使用你這個 APP 的過程中，還會持續(xù)產(chǎn)生更多的 Context，比如輸入了什么內(nèi)容、做了什么操作等等。所有這些信息結(jié)合在一起，就能幫助系統(tǒng)更精準(zhǔn)地識別用戶意圖、預(yù)測下一步的需求，甚至主動發(fā)問，引導(dǎo)用戶獲得想要的結(jié)果。

文鋒：對。你想更好地了解一個人，就要看 Ta 的過去。同理，你想更好地理解用戶的意圖，就要追蹤 Ta 從哪里來、以及過程中的路徑是怎樣的。

就好比下圍棋，當(dāng)前這一手沒那么重要，重要的是你得理解對方前面一百手棋是怎么下的，因為只有這樣你才能判斷對方整盤棋的思路，進(jìn)而推測出 Ta 接下來的策略，并做出相應(yīng)的動作。

曲凱：所以 Google 很早就在保存用戶的 cache。

文鋒：這確實是 Google 在 AI Native 時代最大的競爭優(yōu)勢。這些海量的用戶點擊數(shù)據(jù)，未來都可以用在意圖識別中。

曲凱：是。你對于 Agent 還有什么其它的非共識理解嗎？

文鋒：Agent 開發(fā)者還要解決好兩個信任問題。

第一，你要信任大模型的能力。

如果你不信任大模型，就會退回到 rule-based 的老路子上去，給模型加一堆限制條件，比如通過 Prompt 不斷告訴模型「你是誰、你只能做什么、不能做什么」等等。但其實這樣是在人為限制大模型的泛化能力，導(dǎo)致 Agent 對模型智能的利用率大大降低。

第二，你得思考怎么通過產(chǎn)品設(shè)計，讓用戶信任 Agent 給出的結(jié)果。

這方面有個特別好的例子就是 DeepSeek R1。在 R1 之前，我用一些類似的產(chǎn)品生成報告時，拿到結(jié)果的第一反應(yīng)往往是「這靠譜嗎？」，因為我不知道這個報告是怎么來的，中間有沒有出錯。

但 R1 第一次讓我看到了 AI 的推理過程，所以我心理上更有安全感，也更愿意相信這個結(jié)果。Manus 其實也是類似的機制。

曲凱：明白。再聊聊 Sheet0 吧，你前面說它可以自動完成數(shù)據(jù)收集、處理，以及基于數(shù)據(jù)采取行動的全過程。能不能舉個具體的例子？

文鋒：比如我們可以自動化執(zhí)行這樣一套流程：先抓取 YC 最近幾期的初創(chuàng)公司列表，然后找出每家公司的創(chuàng)始人是誰，再進(jìn)一步查找他們的 Twitter 賬號并完成關(guān)注，最后再發(fā)個私信去建聯(lián)。

這個流程我們已經(jīng)做到了 100% 的準(zhǔn)確率。

我們也試過用 Deep Research 和 Manus 去執(zhí)行這個任務(wù)，但發(fā)現(xiàn)它們都會丟數(shù)據(jù)。而且 Deep Research 拿到數(shù)據(jù)之后，只能生成一份報告，無法像我們一樣完成后續(xù)的建聯(lián)動作，而 Manus 雖然具備行動能力，但它每一步都在動態(tài) Coding，過程中需要不斷 Debug 和調(diào)整，所以很難保證穩(wěn)定性和成功率。

曲凱：所以你們怎么做到的 100% 準(zhǔn)確？

文鋒：我們用了一些 AI Coding 的技術(shù)。但這還不夠，我們還在整個流程中預(yù)先搭建了很多小的工具模塊。這些工具都是我們提前驗證過、確保好用的。每次拿到一個新的任務(wù)，模型都可以直接調(diào)用這些模塊，而不是從頭寫一段程序。

這種方式背后的核心邏輯就是「復(fù)用」。這樣做效率更高，成本也更低。

但 Manus 不是這種思路。Manus 每遇到一個問題，都要打開 IDE 從零開始寫代碼。

并不是說 Manus 的方式一定不好，因為 Agent 的通用性和準(zhǔn)確率之間有一個 trade-off，你越追求通用性，就越依賴模型的泛化能力，但泛化程度越高，隨機性也會越高，結(jié)果的不確定性也會變大。最終選擇哪種模式，取決于你到底想做出什么樣的 Agent。

曲凱：所以如果你想要一個既通用又準(zhǔn)確的 Agent，就得讓團隊投入大量時間和精力，手搓各種各樣的工具組件。

文鋒：是的。但也不是什么都要手搓，有時候用現(xiàn)成的工具反而更劃算。比如像發(fā)郵件這種簡單的流程，就很適合手搓一個模塊，但如果是數(shù)據(jù)庫相關(guān)的操作，你肯定不能每次都從頭寫一套腳本，更合理的做法可能是通過 MCP 之類的方式直接調(diào)用。

曲凱：那 Sheet0 跟其它 Agent 相比，有什么區(qū)別？

文鋒：我區(qū)分 Agent 就是看它最終交付的結(jié)果。從這個角度去對比，市面上的 Agent 大體可以分成兩類。

一類是 Coding Agent。它們交付的結(jié)果就是一段可執(zhí)行的代碼。

另外一類是調(diào)研 Agent。GenSpark、Deep Research、Manus 其實都屬于這一類，它們最終給用戶交付的結(jié)果就是一份報告，而不能真的幫你在美團上下個單，或者去京東買個什么東西。

而我們是個表格 Agent，和其它 Agent 相比，本質(zhì)上其實是「定性分析」和「定量分析」之間的差異。

「定性分析」是很多 Agent 解決問題的方式。比如如果你想大致了解某一個問題，那就可以用 Deep Research 這樣的工具去生成一份報告。這份報告能幫助你建立對這個問題的感知，但不能給你非常精確的數(shù)據(jù)。

而我們想解決的是生活中那些對精確度有要求的場景，所以需要用「定量分析」的方式去解決問題。

比如如果你想知道一個非常精準(zhǔn)的數(shù)字，那就需要一個準(zhǔn)確的數(shù)據(jù)源，而這個數(shù)據(jù)源通常是一個清晰完整的表格。Sheet0 所做的事情，就是借助 AI，從這些數(shù)據(jù)源中抓取各種數(shù)據(jù)，再把這些數(shù)據(jù)匯總到一個表格中，然后拿這個表格去做下一步的分析。

我們在工程上也解決了模型幻覺的問題，能夠保證這個過程的準(zhǔn)確度。

曲凱：說到模型幻覺我突然想到，AI Coding 是不是就相當(dāng)于大模型的翻譯和助手？如果各個環(huán)節(jié)都引入一點 AI Coding，是不是就能提高結(jié)果的準(zhǔn)確率，解決幻覺的問題？

文鋒：是的，AI Coding 是大模型的「靈巧手」。

大模型執(zhí)行任務(wù)的過程有很多步，最終結(jié)果的準(zhǔn)確率是前面所有步驟準(zhǔn)確率的乘積。舉個例子，如果它每一步的成功率都是 90%，連續(xù)執(zhí)行 10 步之后，整體的成功率可能就會降到 0.9 的 10 次方，也就是 35%。

這是因為下一步都是在上一步的結(jié)果之上去執(zhí)行，而每一步的結(jié)果又很難評估，所以就難以及時修正。

為了解決這個問題，我們就可以在每步中都引入 AI Coding，這樣就可以把難以評估的結(jié)果，都轉(zhuǎn)化成可驗證的代碼。

比如每一步我都可以通過 AI Coding 生成 10 段代碼，因為代碼很好驗證，所以就算這些代碼中只有一半是正確的也沒關(guān)系，我完全可以只留下正確的那 5 段，用這 5 段去生成一個正確的階段性結(jié)果，然后再進(jìn)入下一步。這樣就保證了最終結(jié)果 100% 的準(zhǔn)確率。

MCP 其實也是通過這個方案打通了工具調(diào)用之間的壁壘。

曲凱：那你對于未來幾年 Agent 的發(fā)展有什么預(yù)測嗎？

文鋒：現(xiàn)在 AI 發(fā)展的速度太快，與其分享一個具體的預(yù)測結(jié)果，我更想分享一個思考框架。

你想判斷 Agent 未來的發(fā)展方向，最重要的是抓住關(guān)鍵變量。那就像我們之前聊的，Agent 做得好不好，核心是看它能不能真正交付出一個好的結(jié)果，而這個結(jié)果的質(zhì)量，主要取決于兩個因素：一是模型能力，二是你能不能構(gòu)建出更好的 Context。

所以 Agent 要想有突破，至少需要模型更強了，或者我們在 Context 工程上走得更遠(yuǎn)了。

曲凱：那假設(shè)你是投資人，你會問什么問題來判斷一家 Agent 公司做得好還是不好？

文鋒：我首先會問他們團隊里有沒有人看過《Reinforcement Learning: An Introduction》（笑），因為看過這本書的人，大概率會具備一種正確的 mindset，能用很 solid 的方式來做好一個產(chǎn)品。

除此之外，我可能會問他們怎么設(shè)計產(chǎn)品中的激勵信號，也就是他們怎么評估結(jié)果的好壞。這是一個非常關(guān)鍵的問題，決定了大模型能不能往更好的方向去持續(xù)迭代。

曲凱：所以你們產(chǎn)品的激勵信號是什么？

文鋒：我們產(chǎn)品的核心是任務(wù)執(zhí)行的過程中 AI 生成的那個表格，那「表格中數(shù)據(jù)是否為空」本身就是一種很直觀的反饋信號。

另外，前面也提到了，我們會通過 AI Coding 把一些難以直接評估的結(jié)果轉(zhuǎn)化為可驗證的代碼，比如我們會把模型對于頁面結(jié)構(gòu)、頁面與頁面之間的關(guān)系之類的分析結(jié)果，通過 AI Coding 的方式生成一段腳本，那這個腳本能不能成功運行、運行的結(jié)果是不是符合預(yù)期，也是一種激勵信號。

曲凱：理解了，謝謝！最后說下 Sheet0 最近開放了 Waiting List，也即將開始內(nèi)測，歡迎大家去 sheet0.com 注冊體驗一下。

42章經(jīng)

思考事物本質(zhì)