從歷史照片到交互式 3D：Gemini 4 Carbon 用一條提示詞重現埃菲爾鐵塔的建設過程

作者注：本文從 Google 的埃菲爾鐵塔演示出發，解釋多 Agent 如何把歷史圖片和工程資料組織成交互式三維展覽。

術語速覽（to know）

• Agent（智能體）：能調用工具、執行任務的 AI 程序，不只回答問題，還會規劃、執行和檢查結果。
• 多 Agent 協作：多個智能體分工處理子任務，並交換各自的中間結果。
• Antigravity：Google 提供的 AI 開發工具，Gemini 4 Carbon 已在其中上線。
• Swarm（/swarm）：Antigravity 中組織多個智能體協作的預覽功能，於 2026 年 11 月 10 日推出。
• 工程圖紙：用圖形和尺寸表達工程設計的資料，是三維重建的關鍵幾何來源。
• Three.js：在網頁中構建三維場景的 JavaScript 庫，可以直接在瀏覽器裏渲染和交互。
• 格構結構：由許多杆件組合而成的承重結構，埃菲爾鐵塔就是典型的鐵製格構結構。

Google 在 2026 年 11 月 10 日正式開放 Gemini 4 Carbon，並在官方公告中展示了一個很有畫面感的案例：多個 Carbon Agent 藉助 Antigravity 的 /swarm 功能，把歷史照片和工程圖紙轉化爲一個交互式 Three.js 3D 展覽，重現埃菲爾鐵塔 1887—1889 年的建設過程。整個任務由一條提示詞啓動。

這不是“AI 隨手畫了一座鐵塔”。Google 官方公告和 Antigravity 博客對這個案例及 Swarm 機制都有說明。本文會區分三類信息：歷史事實、Google 官方演示的描述，以及我們的分析推斷。

核心價值：讀完本文，你會知道這個演示到底解決了哪些技術問題，多 Agent 在其中扮演什麼角色，以及開發者怎樣用 API 嘗試類似的“圖紙到 3D”工作流。

Gemini 4 Carbon 埃菲爾鐵塔演示核心信息速覽

先看 Google 官方公告中能確認的信息。下表只列出官方明確提到的內容，沒有披露的細節會單獨說明。

需要注意的是，“一條提示詞”不等於“單輪生成”。用戶只發出一次指令，後續的拆解、並行處理和檢查由多個 Agent 在 Swarm 框架裏完成。這是理解整個案例的前提。

埃菲爾鐵塔爲什麼是 Gemini 4 Carbon 的高難度考題

如果只是生成一個“看起來像鐵塔”的模型，這個演示並不稀奇。真正的難點在於，埃菲爾鐵塔本身就是一項資料密集、結構複雜的工程。以下數據來自埃菲爾鐵塔官方網站的歷史檔案。

施工時間線同樣清晰。1887 年 1 月 26 日正式開工，同年 7 月 1 日開始安裝塔柱；1888 年 4 月 1 日第一層建成，8 月 14 日第二層建成；1889 年 3 月 31 日塔頂及整體組裝完成。對於一個“重現建設過程”的展覽來說，這些節點就是時間軸的骨架。

埃菲爾鐵塔的格構結構與抗風設計

據官方歷史資料，鐵塔的設計構想最初來自工程師 Maurice Koechlin 和 Émile Nouguier，建築師 Stephen Sauvestre 參與了外觀設計，古斯塔夫·埃菲爾推動了最終方案。最初方案採用四根格構柱，底部分開，向頂部逐漸匯聚。

塔柱的曲率經過數學設計，用來改善結構抵抗風力的能力。每個金屬構件都在工廠預製，並經過專門設計和計算，圖紙精度達到十分之一毫米。這意味着重建它不是“堆幾何體”，而是要理解杆件、曲線和層級之間的嚴格關係。

Gemini 4 Carbon 如何把二維歷史資料變成三維結構

這一部分是本文的分析，Google 並未公開該任務的內部步驟。從輸入和輸出反推，任務至少需要跨越三道門檻。

1. 理解歷史照片：施工照片拍攝角度不一、清晰度有限，需要識別出畫面中已建成到哪一層、塔柱處於什麼階段，並把照片對應到時間線上的節點。
2. 提取圖紙中的幾何信息：工程圖紙包含立面、剖面、尺寸標註等內容，需要從中讀出塔柱傾角、平臺高度、杆件排布等參數。
3. 推斷空間關係並組織成可重建的數據：照片和圖紙都是二維的，必須把多個視角的信息對齊，推斷構件在三維空間中的位置，再整理成能驅動建模代碼的結構化描述。

Gemini 4 Carbon 的模型卡顯示，它支持文本、圖像、音頻和視頻輸入，輸出爲文本，總上下文額度爲 1,048,576 Token。由此可以合理推斷，展覽是以 Three.js 代碼這種“文本”形式交付的，三維效果由瀏覽器執行代碼後呈現，而不是模型直接輸出一個三維文件。

Google 在同一份公告裏還展示過一個可參照的案例：Carbon 處理 7 份公開的城市規劃 PDF，提取出 206 個工程圖視圖，經過 10 輪夜間迭代，最終生成約 906,000 個三角面的交互式 Three.js 建築模型。兩個案例思路相近，都是“異構資料 → 空間信息 → 交互式三維”。

Gemini 4 Carbon 多 Agent 如何協同完成埃菲爾鐵塔展覽

Google 確認這個案例由多個 Carbon Agent 通過 /swarm 協作完成，但沒有披露本次任務的具體分工。因此下面介紹的是 Antigravity 官方博客描述的 Swarm 一般機制，不是該案例的實錄。

Google 稱 Agent 空閒等待時不消耗 Token，但同時提醒，多 Agent 並行執行仍會明顯增加整體用量。官方還建議按角色分配模型：架構設計、任務協調、複雜審計交給 Carbon，常規實現和並行文件修改交給更快、更輕量的模型。

這種分工對工程資料重建很有意義。協調者需要深度推理來理解“哪些資料對應哪一階段”，而批量生成杆件、拼接場景這類重複工作，並不需要每一步都動用最貴的模型。驗證環節則是質量的保險，因爲單個模型連續生成的三維結構很容易出現比例漂移。

如何用 Gemini 4 Carbon API 嘗試類似的圖紙到 3D 任務

Antigravity 的 /swarm 是產品內功能，開發者無法通過一個 API 參數直接復現。但你可以用 API 搭一個簡化版流程，體驗“讀圖 → 抽參數 → 生成 Three.js”的鏈路。官方模型 ID 爲 gemini-4-carbon。

極簡示例：讓 Carbon 解析一張施工照片

import base64
from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # OpenAI 兼容的統一接口
)

with open("eiffel_1888.jpg", "rb") as f:
    img_b64 = base64.b64encode(f.read()).decode()

resp = client.chat.completions.create(
    model="gemini-4-carbon",
    messages=[{"role": "user", "content": [
        {"type": "text", "text": "判斷照片中鐵塔建到了哪一層，估算塔柱傾角與平臺高度比例，輸出 JSON。"},
        {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{img_b64}"}}
    ]}]
)
print(resp.choices[0].message.content)

import base64
import json
from concurrent.futures import ThreadPoolExecutor
from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)
MODEL = "gemini-4-carbon"


def encode(path: str) -> str:
    with open(path, "rb") as f:
        return base64.b64encode(f.read()).decode()


def ask(content, system: str = "") -> str:
    messages = []
    if system:
        messages.append({"role": "system", "content": system})
    messages.append({"role": "user", "content": content})
    resp = client.chat.completions.create(model=MODEL, messages=messages)
    return resp.choices[0].message.content


def worker_extract(path: str) -> str:
    """並行工作者：從單張照片或圖紙中提取結構參數"""
    return ask([
        {"type": "text", "text": "提取該資料中的結構信息：所屬施工階段、塔柱傾角、平臺高度比例、可見杆件排布，只輸出 JSON。"},
        {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{encode(path)}"}}
    ], system="你是結構工程資料分析員，數據不確定時標註 uncertain，不要編造。")


def builder(merged: str) -> str:
    """構建者：根據合併後的參數生成 Three.js 頁面"""
    return ask(
        "根據以下結構參數，生成單文件 HTML，使用 Three.js 構建四根格構塔柱與兩層平臺，"
        "並提供 1887—1889 時間軸滑塊按階段顯示結構：\n" + merged
    )


def verifier(merged: str, html: str) -> str:
    """驗證者：檢查代碼與參數是否一致"""
    return ask(
        "檢查下列 Three.js 代碼是否與結構參數一致，列出比例錯誤、階段錯誤和無法運行的代碼：\n"
        f"參數：{merged}\n代碼：{html}"
    )


sources = ["photo_1887.jpg", "photo_1888.jpg", "drawing_elevation.jpg"]

with ThreadPoolExecutor(max_workers=3) as pool:
    results = list(pool.map(worker_extract, sources))

merged = json.dumps(results, ensure_ascii=False)
html = builder(merged)
report = verifier(merged, html)

with open("eiffel_exhibit.html", "w", encoding="utf-8") as f:
    f.write(html)
print(report)

這段代碼是我們用普通 API 模擬 Swarm 思路的簡化實現，並非 Google 的內部方案。有兩點需要留意：Carbon 會忽略 temperature、top_p 等採樣參數，傳入 thinking_budget 會返回 HTTP 400；默認推理等級爲 MEDIUM，高等級推理更耗 Token、響應更慢。

🚀 快速上手建議：做這類多圖、多步驟實驗時，最好先用小樣本驗證提示詞效果。推薦通過 API易 apiyi.com 獲取免費測試額度，一個 API Key 即可在 Gemini、Claude、OpenAI 等模型之間切換，方便把“輕量模型做批量提取、強推理模型做規劃和驗證”的分工落到代碼裏。

Gemini 4 Carbon 交互式 3D 展覽與傳統交付形式對比

Three.js 的作用，是讓三維場景直接在瀏覽器中運行。觀衆不需要安裝軟件，就能旋轉視角、縮放細節，或拖動時間軸查看不同年份的施工狀態。下表對比了幾種常見的歷史資料呈現方式。

交互式展覽最大的價值在於“可追溯”。因爲它本質上是代碼，每一層平臺、每一段塔柱都對應可讀的參數，後續發現與圖紙不符時可以定點修正，而不是推倒重來。這也是驗證 Agent 能夠發揮作用的基礎。

Gemini 4 Carbon 埃菲爾鐵塔演示的影響分析

先強調邊界：這是 Google 官方展示的案例，不是獨立第三方驗證的結果。它說明了 Carbon 加 Swarm 能做到什麼，但不能直接推出“任何建築資料都能穩定重建”的普遍結論。

對開發者的影響

• 工作流從單次調用轉向編排：一條提示詞背後是多個 Agent 的分工，開發者需要關注任務拆解、中間結果格式和驗證機制。
• 成本要按任務而非按單價計算：Carbon 首發價爲每百萬輸入 Token 2 美元、輸出 10 美元，12 月 1 日起翻倍；思考 Token 計入輸出，多 Agent 並行還會放大用量。
• 多模型混用更現實：官方建議只讓 Carbon 承擔規劃、協調和審計，批量執行交給輕量模型，這對控制成本很關鍵。

對行業的影響

• 歷史建築數字化：大量只存在於照片和圖紙中的建築，有機會以更低門檻轉化爲可交互模型，供研究者比對。
• 工程資料重建：城市規劃 PDF 案例和鐵塔案例都指向同一方向，即從異構文檔中提取空間信息。
• 數字展覽與教育可視化：博物館和教師可以把“5,300 張圖紙、250 萬顆鉚釘”這類抽象數字，變成學生能拖動時間軸觀察的場景。

同時也要看到限制。/swarm 目前仍是預覽功能，模型卡明確提示 Carbon 可能出現幻覺，高推理等級可能響應較慢甚至超時。在需要嚴格精度的工程場景中，AI 重建結果仍應由專業人員複覈。

常見問題 FAQ

Gemini 4 Carbon 埃菲爾鐵塔演示核心要點 Key Takeaways

• 案例本質：多個 Carbon Agent 把歷史照片和圖紙轉成 Three.js 交互展覽。
• 一條提示詞不等於單輪生成：背後是 Swarm 的任務拆解與並行協作。
• 工程難度真實存在：18,038 件構件、5,300 張圖紙，結構精度要求極高。
• 交付形式是代碼：Carbon 輸出文本，展覽以可修改的 Three.js 代碼呈現。
• 成本要看整體：多 Agent 並行放大用量，按角色混用模型更經濟。
• 邊界要說清：官方演示不代表普遍性能，Swarm 仍是預覽功能。
• 上手方式：可藉助 API易 apiyi.com 統一接口，小樣本驗證讀圖與建模流程。

總結

Gemini 4 Carbon 的埃菲爾鐵塔演示，核心看點有三個：

1. 輸入是異構歷史資料：照片和工程圖紙需要被理解、對齊，並轉換爲空間參數。
2. 過程是多 Agent 協作：一條提示詞啓動 Swarm，協調、執行、驗證分工完成任務。
3. 交付是可交互的三維展覽：Three.js 讓 1887—1889 年的施工過程能在瀏覽器中被自由瀏覽。

對開發者來說，更值得借鑑的是“深度推理模型做規劃、輕量模型做執行、驗證環節兜底”的編排思路。推薦通過 API易 apiyi.com 用小規模資料先跑通流程，再決定是否投入更大的多 Agent 任務。

📚 參考資料

1. Google 官方公告：Gemini 4 Carbon is now available：埃菲爾鐵塔案例與 /swarm 發佈信息
2. 鏈接： blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-carbon-now-available/

3. 說明： 案例的原始描述、開放範圍與價格變化

4. Google Antigravity 官方博客：Gemini 4 Carbon in Google Antigravity

5. 鏈接： antigravity.google/blog/gemini-4-carbon-in-google-antigravity/

6. 說明： Swarm 的協調、並行工作、對抗式驗證與消息板機制

7. Gemini 4 Carbon Model Card：Google DeepMind 模型卡

8. 鏈接： deepmind.google/models/model-cards/gemini-4-carbon/

9. 說明： 輸入輸出模態、上下文額度與已知限制

10. Gemini 4 Carbon 開發者指南：Google Cloud 文檔

11. 鏈接： docs.cloud.google.cn/gemini-enterprise-agent-platform/models/guides/gemini-4-carbon

12. 說明： Thinking Level、參數限制與長解碼說明

13. 埃菲爾鐵塔官方歷史資料：La tour Eiffel

14. 鏈接： toureiffel.paris/en/the-monument/history
15. 說明： 構件數量、圖紙數量、施工時間線與結構設計背景

作者: APIYI 技術團隊
技術交流: 對多 Agent 編排或多模態 3D 生成有疑問，歡迎通過 API易 apiyi.com 網站首頁聯繫我們交流

延伸閱讀

• 讓模型寫 Three.js 而不是直接生成 3D 文件：代碼中間層工作流的 5 個啓示:以 Qwen3.5-4B-GLB-3D-Coder 爲例，拆解“文本→Three.js→GLB”的代碼中間層工作流，並給出本地部署、雲端接入與 Godot 驗證的實操步驟。
• Gemini 4 Carbon 發佈解讀：59 分反超 Opus 5.5，17 項贏 15 項卻調不到:Gemini 4 Carbon 在 Artificial Analysis 綜合智能指數拿到 59 分登頂，官方 17 項對比贏 15 項。但它沒有 API 型號 ID，也沒有開放時間表。本文按口徑拆清分數，說明現階段爲什麼調不到，以及國內開發者現在可以先用 gemini-4-argon。