Agent 開發的上半場: 環境、Tools 和 Context 如何決定 Agent | 42章經

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

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

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

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

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

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

經過兩年的發展，這波 Agent 確實能夠在實際的工作和生活場景中解決問題，為大家帶來價值了。

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

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

曲凱：怎么理解這個 Context？

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

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

我們的 Context 就包括網頁、收集整理的數據表格、用戶下達的指令，以及分析數據時生成的一些 SQL 等等。

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

文鋒：核心區別在于 Context 的來源。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

曲凱：類似于 Agent 在前端給人演了一場戲。看似它在模擬人類的操作，其實背后還是代碼在驅動。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

文鋒：我認為我們現在處于，并且將長期處于一個垂直 Agent 的時代。

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

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

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

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

文鋒：而 AI Coding 那邊也在講 Coding 是一切的基礎設施（笑）。

曲凱：是啊哈哈，甚至前幾天我還看到一條新聞說 Coding 可能也是未來 AGI 的基礎。

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

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

AI Coding 只能說是大模型執行任務的一個強有力的工具，這個工具存在兩個關鍵問題，一是很難和其他工具協同，二是很難復用。

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

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

曲凱：明白。那 RL 和 Agent 之間的關系是怎樣的？創業公司最終應該如何應用 RL？

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

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

1) 狀態，對應 Context。

2) 行動，對應 Tool Use。

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

那么對于創業公司而言，非常關鍵的就是如何在你的產品中打造出一個好的「環境」。這個環境需要清晰地描述當前的狀態，Agent 可以采取哪些動作，也就是行動空間，以及對于結果好壞的定義。

其中，行動空間決定了你設計的 Workflow 中要有多少個節點。

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

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

所以我也很建議所有 Agent 開發者和產品設計者都去讀一下強化學習之父 Richard Sutton 的《Reinforcement Learning: An Introduction》。看完這本書你會收獲一個 mindset，讓你能夠在設計產品的時候不斷地思考、調整、定義你的環境。

曲凱：怎么評判環境的好壞？

文鋒：評判一個環境好不好，關鍵是要看這個環境能不能基于行動的結果來提供一個激勵信號。

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

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

文鋒：不。我認為 Workflow 和 Agent 會長期共存。

這兩者的本質區別在于，Workflow 由人類驅動，而 Agent 由 AI 驅動。

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

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

曲凱：你已經做了一年多的 Agent，有積累哪些非共識的認知嗎？

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

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

一旦你限制了用戶的自由度，其實就是在讓用戶來適應你的產品，加重用戶的認知負擔。而一個好的 Agent 應該足夠智能，能讓用戶像幸福的小朋友一樣自由地使用它。

那么在現有的交互方式中，Chat 就是最能保障用戶交互自由度的形態。

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

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

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

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

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

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

文鋒：是，另外開發者在 Agent 中預設的 System Prompt 也可以輔助模型的表現，像 Cursor 和 Windsurf 就有幾千行的 System Prompt。

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

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

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

文鋒：是的。總之起手收集到的 Context 越多越好。

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

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

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

然后用戶使用你這個 APP 的過程中，還會持續產生更多的 Context，比如輸入了什么內容、做了什么操作等等。所有這些信息結合在一起，就能幫助系統更精準地識別用戶意圖、預測下一步的需求，甚至主動發問，引導用戶獲得想要的結果。

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

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

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

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

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

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

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

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

第二，你得思考怎么通過產品設計，讓用戶信任 Agent 給出的結果。

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

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

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

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

這個流程我們已經做到了 100% 的準確率。

我們也試過用 Deep Research 和 Manus 去執行這個任務，但發現它們都會丟數據。而且 Deep Research 拿到數據之后，只能生成一份報告，無法像我們一樣完成后續的建聯動作，而 Manus 雖然具備行動能力，但它每一步都在動態 Coding，過程中需要不斷 Debug 和調整，所以很難保證穩定性和成功率。

曲凱：所以你們怎么做到的 100% 準確？

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

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

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

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

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

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

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

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

一類是 Coding Agent。它們交付的結果就是一段可執行的代碼。

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

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

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

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

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

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

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

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

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

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

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

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

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

曲凱：那你對于未來幾年 Agent 的發展有什么預測嗎？

文鋒：現在 AI 發展的速度太快，與其分享一個具體的預測結果，我更想分享一個思考框架。

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

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

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

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

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

曲凱：所以你們產品的激勵信號是什么？

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

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

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

42章經

思考事物本質