潛在空間 vs. 確定性空間

資料來源#

Garry Tan 對代理系統的設計準則（practitioner-opinion）：務必有意識地思考計算實際發生在哪裡，因為它總是發生在兩個地方之一——而且「我們遇到的所有 AI 工程問題，通常都是因為某些事情發生在等式的一側，但其實應該發生在另一側。」

潛在空間——LLM 本身。它適合處理的事情：品味、判斷、「理解人們說出模糊話語時真正想要什麼」，以及非確定性呼叫。你可以用 markdown 引導它（Agent Context Files）。
確定性空間——工程師早已熟悉的領域：代理程式寫出的程式碼、外部儲存，以及可驗證的狀態。

Tan 在 YC Startup School 的現場案例：從 6,000 名參加者中安排 800 人入座，讓每個人的鄰座都是最適合與其認識的人。分工如下：

合計只需「幾百美元的 tokens，可能還有 10 分鐘」——這項任務在六個月前或許還不具經濟可行性。這個例子可以推廣到更廣的情境：潛在空間為每個決策提供判斷；確定性空間則保存狀態並強制執行約束。

它把這個 wiki 中幾個得來不易的經驗，濃縮成一個診斷問題——這項計算應該放在哪一側？

把狀態移出 context window 是 Context Window Smart Zone 背後的工作準則（smart-zone 預算應花在判斷，而不是儲存），也是這個 vault 自身架構的基礎（LLM-as-Compiler Knowledge Base：wiki 保存狀態；build.py/lint.py 負責確定性的記帳；LLM 只做詮釋性的編譯）。
用 markdown 引導潛在空間 是 Agent Context Files 模式的核心，如今被定位為雙側架構的一半，而不只是獨立技巧。
錯誤分類學——「某些事情發生在不該發生的那一側」——涵蓋兩種熟悉的失敗類型：LLM 在程式碼應負責的地方做算術與狀態追蹤（幻覺式記帳），以及脆弱的程式碼把應由模型處理的判斷硬編碼（Software 3.0 的觀點——Karpathy 的 MenuGen「不應該存在」，因為原生於該典範的版本會把整項任務推入潛在空間）。
它是 Planning / Execution Division of Labor 在架構層級的近親：那一頁把決策拆分為人類與代理；這一頁則把計算拆分為模型與程式碼。

Tan 認為「錯誤的一側」診斷涵蓋了大多數 AI 工程錯誤。是否有任何事件／失敗分類學（代理事後檢討、eval 失敗分析）確實依照計算位置分類失敗，而且落在兩側的比例各是多少？
這個座位案例估算，為 800 個座位分配提供潛在空間判斷需要「幾百美元的 tokens」。隨著模型吸收更多確定性能力（Harness Shrinkage as Models Improve），經濟上最佳的邊界會朝潛在空間移動嗎？還是將狀態移出 context window 仍然是不變的原則？

The New Physics of Business — Garry Tan, Y Combinator — Garry Tan, "The New Physics of Business," AI Engineer, 2026-07-17, §latent space vs. deterministic space (8:38–10:53)