II-Agent：一個把生成與研究塞進同一條管線的開源代理框架

它解決什麼問題，寫給誰看

II-Agent 定位是「為真實工作而建的開源 AI 代理」，這句話讀起來像行銷，但從 README 列出的功能看，它確實想涵蓋生成與研究兩大類。生成端包括手機 App、網站、故事書、影片與圖片，研究端則有快速研究與深度研究。它的目標使用者很明確：不想被封閉平台綁住、想自己帶 API key 的開發者、研究團隊，或正在建內部工具的企業。跟那些只做聊天或只做單一任務的框架不同，II-Agent 把多種工作負載塞進同一套系統，這既是賣點也是潛在風險。它聲稱 100% 開源、Apache-2.0 授權，這對需要審計程式碼的企業是加分項。但要注意，README 提到「no black boxes」，實際上有多少黑盒子，得看程式碼結構，光憑說明文件無法斷定。

架構上的多重服務依賴

從安裝指引可以看出 II-Agent 不是輕量級套件。它需要 PostgreSQL 當主要資料庫、Redis 當快取或佇列、MinIO 當 S3 相容的物件儲存，再加上後端與前端兩個服務。這種架構表示它預設你處理的是有狀態、需要持久化的任務，不是一次性 API 呼叫。前端跑在 1420 埠，後端在 8000 埠，MinIO 管理介面在 9001 埠。開發時用 make dev-all 一次啟動所有服務，這對本地開發者來說方便，但對只想快速試試代理能力的人來說，門檻偏高。文件也提供 Docker Compose 的 make stack 選項，可以免裝 Python 與 Node，但這代表你要維護一整組容器。架構的複雜度換來的是整合能力，例如同時處理文件、簡報與即時編輯，但這也意味著任何一個服務掛掉，整個系統就動不了。

安裝流程與真實指令

安裝分兩條路徑。第一條是傳統開發模式：先裝 Docker、uv、Node.js，然後 git clone 倉庫，執行 make setup 產生 .env 檔並安裝依賴。接著編輯 .env，設定至少一個 LLM 提供者。提供兩種設定方式：一種是把 JSON 直接塞進 .env 的 MODEL_CONFIGS 變數，另一種是複製 model_configs.example.yaml 成 model_configs.yaml，然後在 .env 指定 MODEL_CONFIGS_FILE。JSON 範例裡用的是 claude-sonnet-4-6，YAML 範例則涵蓋 OpenAI、Anthropic、Google 三家，甚至提到 Vertex AI、Azure 與自架模型。設定完執行 make dev-all，後端在 8000、前端在 1420。第二條路徑是純 Docker：複製 docker/.stack.env.example 成 docker/.stack.env，編輯憑證後執行 make stack。兩條路徑都要求你先有 Docker，這不是可選項。

模型配置的彈性與陷阱

II-Agent 支援多模型供應商，而且能在同一個對話中切換供應商，這在 README 的 Chat 功能裡有提到。配置方式集中在 model_configs.yaml 或 MODEL_CONFIGS 環境變數。每個模型需要 model_id、provider、api_key，以及可選的 display_name 與 is_default。這種設計讓你可以把 Anthropic 當主力、OpenAI 當備援，或依任務類型選不同模型。但這裡有個陷阱：model_id 必須跟供應商實際的模型名稱完全一致，例如範例中的 claude-sonnet-4-6 或 gpt-5.4，這些看起來是未來版本或內部命名，實際使用時要確認你的 API 帳號是否能存取這些模型。文件也提到 Vertex AI 與 Azure 的支援，這代表它不只是包一層 OpenAI SDK，而是有針對不同雲端供應商的適配層。但具體怎麼設定 Vertex AI 的憑證，README 沒有展開，只叫你看 model_configs.example.yaml。

生成功能：從提示詞到成品

II-Agent 的生成功能涵蓋手機 App、網站、故事書、影片與圖片。README 強調「從短提示詞到完整應用程式」，這暗示它內部有某種任務規劃機制，能把一個高層次請求拆解成多個步驟。Plan Mode 的存在更證實這點：它在實際生成前先做視覺化專案規劃，這對複雜任務是必要的，因為直接從提示詞生成整個 App 容易產生結構混亂的結果。Live Editing 則讓使用者能在生成後即時修改網站、簡報或故事書，這表示系統不是一次性輸出，而是保留可編輯的中間狀態。這些功能背後需要大量的前端整合，例如即時協作編輯，README 提到簡報有「live collaborative editing」，這通常需要 WebSocket 或類似的即時同步機制，但文件沒有說明實作細節。對開發者來說，這意味著擴充這些功能時，你得自己讀程式碼理解架構。

研究功能與自動化整合

研究功能分兩層：Fast Research 給快速答案，Deep Research 做多步驟調查。後者顯然需要代理能自主規劃搜尋、閱讀、彙整的流程。Interactive Website Generation 能把研究簡報變成完整網站，包含結構、視覺、引用與嵌入的 Q&A，這聽起來像是把研究輸出再餵給生成管線。自動化方面，內建與自訂 Skills 可以重複使用工作流程，並連接 GitHub 相關流程。App 整合清單包括 Gmail、Slack、GitHub、Notion、Google Calendar、Discord、Dropbox、Canva，這些都是常見的生產力工具。但要注意，README 只列出名稱，沒有說明整合的深度。例如 Slack 整合是只能發訊息，還是能聽事件並觸發代理？文件沒有講。這種含糊在開源專案中常見，但採用前最好先看程式碼或測試實際行為。

限制與不適合的場景

II-Agent 最明顯的限制是部署複雜度。要跑起來需要五個服務，不是 pip install 就能用。對只想寫個簡單代理的開發者來說，這是過度設計。第二個限制是文件對內部機制著墨甚少。README 列了功能表，但沒有架構圖、沒有資料流說明、沒有 API 文件連結。官方指南連結存在，但內容不在這次提供的材料中，無法確認深度。第三個限制是模型 ID 的版本敏感度。範例中的模型名稱可能是預覽版或特定合作版本，一般開發者用自己的 API key 時，可能遇到模型不存在或權限不足的錯誤。最後，即時編輯與協作功能需要前端持續維護，如果專案維護頻率下降，這些功能最容易壞。以 v0.4 在 2025 年 7 月釋出、最後 push 在 2026 年 8 月來看，開發節奏算活躍，但開源專案的長期維護永遠是風險。

替代方案與真正的差異

市面上類似的開源代理框架不少，例如 AutoGPT 或 MetaGPT。AutoGPT 的出發點是讓代理自主分解任務並執行，它更偏向研究與探索，對生成完整應用程式的支援較弱。MetaGPT 則強調軟體公司模擬，多位代理扮演產品經理、工程師等角色，協作產生程式碼。II-Agent 的差異在於它把生成（App、網站、故事書）與研究（深度研究）整合在同一套系統，而且提供即時編輯與文件操作（PDF、Excel、Word、PowerPoint）。AutoGPT 沒有內建文件編輯能力，MetaGPT 專注程式碼生成，不碰多媒體內容。II-Agent 比較像一個全方位的生產力工具，而非純粹的代理研究平台。但這也代表它的程式碼規模更大，學習曲線更陡。若你的需求是純文字代理，AutoGPT 可能更輕量；若你需要生成完整網站並讓使用者即時修改，II-Agent 的整合優勢才顯現。

編輯結論

想在一套系統裡同時處理生成任務（網站、簡報、故事書）與研究任務（快速研究、深度研究）的團隊，II-Agent 值得試。它把多種模型供應商、文件操作、即時編輯整合在同一個介面，對不想自己拼裝 agent 的開發者來說，省下大量整合時間。但若你只需要單純的聊天機器人或輕量 API 封裝，這套框架太重，啟動要 Docker、PostgreSQL、Redis、MinIO 四個服務，資源成本不低。若你打算部署到生產環境，先確認三件事：model_configs.yaml 裡設定的模型 ID 是否與你實際使用的供應商版本一致，.env 中的資料庫與 Redis 連線字串是否指向你控制的實例，以及 make stack 的 Docker Compose 設定是否涵蓋你需要的擴充服務。II-Agent 的文件對安裝步驟著墨多，但對代理內部如何規劃任務、如何呼叫技能的細節著墨少，這點在採用前要有心理準備。

官方來源

1. Intelligent-Internet/ii-agent on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases