YC眼中的五種AI Agent核心形態

原文作者：Taylor Pearson
翻譯：Peggy

編者按：當 AI Agent 從一次性提示碼和 vibe coding，進入更複雜的工作流階段，真正重要的問題已經不再是「模型能不能完成任務」，而是「能否將 AI 能力沉澱為可重複使用、可積累的流程資產」。

本文從 Garry Tan 的 GBrain 出發，總結了當前許多人在使用 Codex、Claude Code、Hermes 等 Agent 工具時逐漸收斂出的五種核心形態：可參數化的 Skills、輕量執行框架 Thin Harness、負責路由的 Resolvers、區分模型判斷與確定性碼的執行層，以及用於長期積累上下文的 Memory。

這些模組組合在一起，指向的是一種新的「過程能力」：將經驗寫成流程，將任務抽象成參數，將穩定規則交給代碼，將判斷和綜合交給模型，再通過記憶層持續沉澱。相比一次性生成的應用或提示詞，這種系統更難被複製，也更可能成為個人、小團隊乃至公司在 AI 時代形成長期競爭優勢的基礎。

以下為原文：

我花了一些時間研究 Garry Tan 的 GBrain。作為一個非技術背景、也不在風險投資行業工作的人，我想提煉一下其中我看到的幾種通用結構形態，以及它真正有趣的地方。

我認為，很多人正在逐漸收斂到同一組核心結構上。它們大概可以概括為 5 種形態，也代表了 Codex、Claude Code、Hermes、OpenClaw 等智能體式 AI 工具在使用方式上的自然演進方向。

相關閱讀：《瘦 Harness，胖 Skill：100 倍 AI 生產力的真正來源》

Skills：從 SOP 到「方法呼叫」

Skills 幾乎是所有人最自然的起點。即便沒有人提醒，使用者也會下意識去構建它，因為它的形態非常熟悉。我一開始把它理解為一種 SOP，也就是用於完成某件事的標準作業流程。使用者提供「要做什麼」，Skill 提供「怎麼做」。

Tan 的理解是，Skill 更像是一次「方法呼叫」。在程式設計中，方法呼叫指的是使用參數呼叫某個程式流程。同一段碼每次都會執行，變化的是參數：什麼數據、什麼問題、什麼目標。例如同一個 process_invoice 函數，可以處理系統裡的每一張發票，而不僅僅是它最初被編寫時對應的那一張。

Skill 也是類似的結構。一個名為 /investigate 的 Skill 可能包含七個固定步驟，這七個步驟不會變。變化的是參數：TARGET（調查對象是誰或是什麼）、QUESTION（你想弄清楚什麼）、DATASET（去哪裡找信息）。將它指向一個醫療行業舉報人案例，它就像一個研究分析師；將它指向 SEC 申報文件，它就像一個法務調查員。同一個文件、同樣的七個步驟，差異由外部世界提供。

這和傳統 SOP 是不同的。大多數 SOP 都是為某一個具體崗位或任務編寫的，比如「處理應付賬款」。每個使用場景對應一套流程。而 Skill 的抽象程度更高，同一套流程可以處理一類問題。一個設計良好的 Skill，可以完成幾十份 SOP 的工作，因為具體案例的信息被從文件中抽離出來，轉移到了參數裡。具體到實際使用，有些 Skill 更接近 SOP，有些則更接近方法呼叫。

Thin Harness：模型是智能，Harness 是手腳

模型，比如 Opus、GPT-5.5 等，是原始智能；Harness，比如 Claude Code、Codex CLI、Hermes、OpenClaw，則是讓模型真正「有手腳」的執行框架。它們負責循環執行、讀寫文件、管理上下文、執行安全約束。其核心代碼大約只有 200 行。

Garry 提到，大多數人都會犯的一個錯誤是不斷往 Harness 裡塞更多東西，我自己也是這樣。我最後積累了 100 個工具定義，以及一堆 MCP 伺服器。結果是，上下文視窗被大量當前任務並不需要的工具說明佔據。模型開始混淆到底該用哪個工具，延遲上升，準確率下降，最終形成所謂的「上下文腐化」。

Resolvers：用路由表解決上下文腐化

解決上下文腐敗的方法，是建立一張路由表。Resolver 的作用是將「剛剛進來的任務類型 X」明確映射到「應該調用 Skill Y」。當你只有 5 個 Skill 時，你不需要 Resolver；但當你有 100 個 Skill 時，各種描述會變得模糊，模型很容易無法在正確時間調用正確的 Skill。Resolver 用明確規則取代了模糊的模式匹配。

Tan 還為文件運行了一套類似 Resolver 的機制：一張獨立的路由表，用來決定某個 Skill 的輸出應該落到文件系統中的哪個位置。這是同一種「審計—路由」結構，被應用到了另一個問題上。這樣一來，輸出就會穩定地進入正確文件夾，而不是放到模型臨時猜測的位置。

Skillify 是他的另一個配套思路：它是一套質量循環，用來把一次性的 Skill 變成可長期複用的基礎設施。Tan 描述的 10 步流程包括：契約定義、在適合的地方使用確定性代碼、單元測試、集成測試、LLM-as-judge 評估、Resolver 條目、審計腳本、檢查哪些 Skill 沒有調用路徑，以及端到端冒煙測試。測試標準很簡單：如果你必須向模型重複問同一個問題兩遍，那就是失敗。

Latent vs. Deterministic：判斷交給模型，確定性任務交給代碼

需要認真區分哪些工作應該交給LLM，哪些應該交給確定性系統。LLM 擅長判斷、綜合、模式識別和讀懂言外之意；但它不擅長算術、組合優化，也不適合處理任何需要每次給出同一個答案的任務。LLM 本質上是概率性的，當確定性方案可以解決問題時，就不應該用LLM。

大多數非技術背景的人，往往低估了確定性層的價值。大家的默認反應，是把所有事情都丟給模型。但如果某件事可以用確定性方式完成，那幾乎就應該這樣做。而且你不需要自己是程序員，因為模型可以替你寫代碼。真正需要訓練的是一種紀律：每次都問自己，這件事能不能用代碼穩定、低成本地完成？如果答案是可以，就讓模型把那段代碼寫出來。

Memory：讓系統真正可積累

要讓系統有用，它必須具備某種形式的記憶。我還不確定最正確的形態是什麼，現在很多人也在用不同方式構建：向量嵌入、語義相似度、知識圖譜、混合存儲等。Tan 的做法和我一樣：就是一個 markdown 文件夾。

他的結構是：每個人一頁、每家公司一頁、每個概念一頁。每一頁頂部是「當前可信結論」，也就是隨著新證據不斷重寫和更新的綜合判斷；底部則是一條只追加、不覆蓋的時間線。

選擇 Markdown 會帶來幾個結果。首先，文件本身就是系統的主記錄，而不是某種導出結果。你可以在 VS Code 裡打開它、手動編輯它，Agent 會自動讀取這些變化。其次，類型化關係，比如 works_at、invested_in、founded、attended、advises，會在每次寫入時通過正則表達式自動抽取出來，因此知識圖譜可以在不消耗 token 的情況下自行連接。這個具體 schema 很適合他的工作，但對其他人來說，可能需要根據自己的職業和業務場景重新定製。

此外，還有一個信號探測器在後台運行。某個人被提到一次，就會生成一個 stub 頁面；如果他在多個來源中被提到三次，就會觸發網頁信息補全；一次會議結束後，則會運行完整流程。夜間的「dream cycle」會掃描對話、補全過時實體信息，並修復失效引用。基礎層是文本，在此之上的所有東西都便宜、可組合。

底層當然還有更多細節，但我認為，這些就是其中最重要的輪廓，而且它們在相當程度上具有普遍性。

我自己其實已經搭建了大約一半這樣的架構。過去還沒有達到必須引入真正 Resolver 的規模，但現在已經到了這個階段，所以我剛剛做了一輪小重構，讓自己的系統變得模型無關，並內置 Resolver。目前我還沒有搭建的關鍵部分，是後台自動運行的信號探測器和夜間 dream cycle，也就是自動信息補全與整理機制，這是我接下來想嘗試加入的部分。

我懷疑，不同建造者正在向類似結構收斂，本身就是一個信號：這種形態雖然未必適用於所有人，但總體上大概率是有用的。即便具體實現細節會有重要差異，但這種總體結構，正在被越來越多人獨立摸索出來。

我最近一直在問自己的問題是：如何用 AI 建立可持續的競爭優勢？

大家都對 vibe-coded 應用和一次性 prompt 很興奮，這當然非常酷。我自己最開始也是這樣玩起來的，並因此入坑。但任何可以通過一次性 prompt 構建出來的東西，它的均衡價格最終都會下降到構建它所需的 token 成本，也就是幾美分。

再加上一套類似日誌整理或 dream cycle 的機制。比如系統在夜間自動發現某位合夥人的 K-1 分配在沒有策略變化的情況下下降了 40%；或者注意到某個客戶的家庭辦公室扣除結構，可以遷移到另一個客戶身上，結構可以複用，但身份和隱私仍然留在原處。

這樣一來，她可以收取少量溢價，每年服務更多客戶，而競爭對手很難複製，因為這套結構並不是等她成功後才凭空出現的，而是從一開始就在持續積累。

從表面看，這個工具只是一個 markdown 資料夾。但每個文件裡的每一行，背後都來自大量有意識的測試、搭建和迭代。真正形成競爭壁壘的，不是文件本身，而是這些文件所承載的流程能力。

[原文連結]

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia