回到文章
積木式經濟席捲多媒體領域。透過代理程式，每個 Space 都是一個積木。實例：巴黎地標 → 潑濺模型。兩個提示詞，一個全新的藝廊。為何這很重要。親自嘗試。一個代理程式透過串聯兩個 Hugging Face Spaces 打造了一個 3D 巴黎藝廊。
我請一個程式編寫代理程式建立一個精美的網站，以 3D 高斯潑濺（Gaussian splats）的形式展示巴黎的紀念碑。我從未開啟過圖像生成器，也從未接觸過 3D 重建工具。這個代理程式透過直接呼叫兩個 Hugging Face Spaces，生成了所有資產（圖像和 3D 潑濺模型），然後將它們連接到一個電影般的瀏覽器中。
這是成果，以靜態 Space 形式即時呈現：
👉 mishig/monuments-de-paris
這篇文章將探討這項技術如何成為可能，以及為何我認為它預示著未來許多多媒體軟體將如何被建構。
積木式經濟席捲多媒體領域
Mitchell Hashimoto 最近描述了一種他稱之為積木式經濟的轉變：最有效的軟體開發路徑不再是精雕細琢的單體式軟體，而是由小型、文件齊全的組件構成，這些組件可以被其他人（越來越多是代理程式）組裝起來。他的關鍵觀察是：AI 在從零開始建構一切方面表現尚可，但在將經過驗證的組件黏合在一起方面卻非常出色。
這個論點主要圍繞程式碼函式庫展開。但同樣的力量也正在衝擊多媒體 AI 領域。使用最先進的圖像模型、影片模型、TTS 模型或 3D 重建模型最困難的部分從來不是模型本身，而是整合：軟體開發套件（SDK）、權重、GPU、輸入格式、輪詢。如果每個模型都能成為一個文件齊全、可呼叫的積木，那麼代理程式就能像組裝 npm 套件一樣將它們黏合在一起。
這正是 Hugging Face Spaces 悄然成為的樣子。
透過 agents.md，每個 Space 都是一個積木
Hub 託管著數千個最先進的模型（其中很大一部分是開放權重模型），而且大多數都部署為互動式 Spaces。截至目前，每個 Gradio Space 也都公開了一個純文字的 agents.md 檔案，它精確地告訴代理程式如何呼叫它：
curl https://huggingface.co/spaces/VAST-AI/TripoSplat/agents.md
一次性返回所有必需的資訊：API 結構描述 URL、呼叫和輪詢模板、如何上傳檔案以及身份驗證提示：
API schema: GET .../gradio_api/info
Call endpoint: POST .../gradio_api/call/v2/{endpoint} {"param_name": value, ...}
Poll result: GET .../gradio_api/call/{endpoint}/{event_id}
File inputs: POST .../gradio_api/upload -F "files=@file.ext"
Auth: Bearer $HF_TOKEN
沒有客戶端函式庫。沒有硬編碼的整合。代理程式讀取這些資訊，就能端到端地驅動 Space。設定一個 HF_TOKEN 即可開始。
真正的關鍵是串聯：一個 Space 的輸出成為下一個 Space 的輸入。提示詞 → 圖像 → 3D。這就是這個藝廊背後的整個管線。
實例：巴黎地標 → 潑濺模型
代理程式串聯了兩個 Spaces：
圖像：ideogram-ai/ideogram4 將每個紀念碑轉換成一張乾淨、深色背景的「標本」照片（並將艾菲爾鐵塔變成一個基座上的小立體模型）。輸入提示詞，輸出圖像。
潑濺模型：VAST-AI/TripoSplat 從每張單一圖像重建出一個 3D 高斯潑濺模型（.ply 檔案）。輸入圖像，輸出 3D 模型。
生成的圖像
重建的潑濺模型
代理程式生成的六張原始圖像，全部獨立於黑色背景上，準備進行單一圖像 3D 重建：
從那裡，代理程式也完成了「黏合」工作。它注意到 TripoSplat 的輸出是 Y 軸向下，於是將它們翻轉直立，自動框選每個紀念碑，將 .ply 檔案壓縮成 .ksplat（約小 3 倍，因此載入速度快），使用 Three.js 建立了一個帶有滾動切換和拖曳旋轉使用者介面的瀏覽器，並將整個專案部署為一個靜態 Space。
唯一的人工輸入是品味層面的調整：「讓它縮小一點」、「用更適合潑濺模型的東西替換方尖碑」、「過渡時間太長」。
其中幾個步驟是代理程式對現實的反應。一個寬大的玻璃金字塔潑濺效果不佳。一個細長的方尖碑很單調。單視圖重建會推斷背面。這正是積木式經濟所預測的「外包研發、快速迭代」循環，只不過研發過程是一場對話。
兩個提示詞，一個全新的藝廊
積木的真正考驗在於其重複使用的成本有多低。一旦這個管線存在，建立全新的藝廊幾乎只需一句話。例如「為日本建立一個類似的潑濺模型 Space」，然後再為埃及建立一個，代理程式就會完成其餘的工作：每個國家六張紀念碑圖像、六個潑濺模型、壓縮、一個瀏覽器和一個部署好的 Space。
🏛️ 埃及紀念碑：
吉薩金字塔、獅身人面像、阿布辛貝神殿、圖坦卡門面具、卡納克神廟、曼儂巨像。
⛩️ 日本紀念碑：
東京鐵塔、姬路城、金閣寺、大阪城、鎌倉大佛、嚴島神社鳥居。
同樣的兩個 Spaces，同樣的 agents.md，只有提示詞改變了。這就是積木式經濟的精髓：新多媒體應用程式的邊際成本趨近於描述它的成本。
為何這很重要
模型變得可組合。一個最先進的潑濺模型和一個最先進的圖像模型，來自不同的組織，無需任何整合程式碼即可串聯。Hub 的開放權重目錄變成了一個可呼叫的多媒體基本元素函式庫。
代理程式偏好有文件且可觸及的內容。agents.md 使 Space 變得極易觸及，因此代理程式會選擇它，而不是必須手動設定的模型。這與 Hashimoto 指出的開源函式庫動態相同。
整合的障礙已基本消失。「將提示詞轉換為旋轉的 3D 紀念碑」過去是一個專案。在這裡，它只是管線中的一個步驟。
親自嘗試
將你的代理程式指向 Space 的 agents.md，讓它開始工作：
# 圖像生成
curl https://huggingface.co/spaces/ideogram-ai/ideogram4/agents.md
# 單一圖像到 3D 高斯潑濺模型
curl https://huggingface.co/spaces/VAST-AI/TripoSplat/agents.md
將任一連結貼到你的程式編寫代理程式（如 Claude Code 等），設定你的 HF_TOKEN，然後要求它建立一些東西。這個藝廊的完整、可重現的管線，即呼叫這兩個 agents.md 端點的腳本，位於 Space 儲存庫中。
積木就在 Hub 上。代理程式已經知道如何黏合。