AI Agent

八月初，阿里 Qwen 團隊放了一顆炸彈。Qwen3.8-Max，2.4 兆引數的 MoE 架構，950 億活躍引數每 token，一百萬 token 上下文。 headline 讀起來像科技新聞——數字很大，但真正有意思的不是數字本身，而是這代產品定位的微妙轉變。 Qwen3.8-Max 不再只是一個「會寫程式的聊天機器人」。它的核心定位是 cowork——一個能在長週期任務中自主執行、自我修正、最終交付可運作成果的 agent。聽起來像行銷話術，但這次拿出來的案例確實有東西可看。 從「回答問題」到「完成任務」 過去一年，我們已經見識過不少 AI coding agent 的演示：寫一段程式碼、修一個 bug，或者生成一個小工具。這些展示都很好看，但現實中的工作往往比這複雜得多。 Qwen3.8-Max 的三個自主任務案例把門檻拉高了。第一個是讓模型從零開始建立一個叫 oh-my-cli 的 CLI 框架，完全自主運作超過十天。到七月三十日為止，這個專案累積了 265 個 commit、127 個 pull request 和 151 個 issue。模型自己把使用者回饋轉成 issue、分配給 agent、跑測試、修 bug，形成一個自我進化的迴圈。 第二個案例更誇張：給它一篇研究論文的連結和 GPU 資源，讓它自己重現實驗然後做得更好。模型花了大約五天、寫了七千六百行程式碼、跑了三十三輪 GPU 訓練，最後在 AIME24 數學基準上比原論文的方法又提升了 2.7 分。這不是寫一篇漂亮的分析報告，而是真正產出可執行的程式碼、訓練模型、驗證結果。 第三個案例是讓模型參加一個真實的競賽——天貓平臺的多模態對話意圖識別挑戰，526 個真人團隊競爭。模型在二十四小時內自己讀規則、寫程式、微調 BERT 和 RoBERTa 語言模型、結合視覺模型做整合，最後以 0.853 的準確率擊敗了 458 個團隊，排在第八十七名。 這些案例的共通點是：模型不是在回答一個明確的問題，而是在一個開放目標下持續運作、自我修正、最終交付成果。這跟過去我們對 LLM 的想像不太一樣。 Benchmark：看著好看，但別全信 Qwen 隨發布公佈了完整的基準分數表，涵蓋編碼代理、通用代理和一般能力三大類。不過這些分數全部是阿里內部跑出來的結果，沒有第三方獨立驗證。 Terminal-Bench 2.1 拿到 86.6，超過了 Claude Opus 4.8 和 Fable 5 的 84.6，但低於 GPT-5.6 Sol 的 88.8。PaperBench 拿到 93.0，超越所有對手。GPQA Diamond 是 92.6，跟上一代 Qwen3.7-Max 的 92.4 幾乎一樣，成長幅度不大。 ...

前陣子幫團隊搭一個內嵌式 AI Agent，最頭痛的不是模型選型或 prompt engineering，而是「Agent 要怎麼連使用者的 Gmail、GitHub、Notion」。傳統做法是讓使用者在 App 裡填 API Key，或者走一輪 OAuth2 流程，把 token 存在自己的資料庫。每加一個服務提供者，就要多寫一套認證邏輯、token 重新整理機制、許可權管理。做三個服務還勉強撐得住，做到十個以上就是維護噩夢。 OpenConnector 解決的就是這個問題。它是一套開源的「聯結器閘道」，定位跟 Composio 類似，但走的路線不太一樣——憑證、許可權範圍、執行記錄全都留在閘道層，Agent 只拿到中繼資料和結果，不用碰金鑰。 它到底在做什麼 OpenConnector 讓你「連一次帳號，就能讓 Agent 隨處使用」。 你部署一臺 OpenConnector Gateway（跑在本機 Docker、Fly.io、Cloudflare Workers，或者直接上 OOMOL SaaS），然後在儀錶板裡把 Gmail、GitHub、Slack 這些服務一一連線。之後你的 Agent 透過 SDK、CLI、MCP 或 HTTP API 呼叫 Action，閘道自動處理憑證注入、token 重新整理、許可權檢查，最後回傳結果。 Agent 永遠不知道 OAuth token 長什麼樣子。金鑰只存在閘道內。 Agent 和使用者應用程式之間多了一層「憑證邊界」。這在 SaaS 產品裡特別好用——不用把每個使用者的 API Key 存在自己的資料庫，也不用擔心 token 過期時 Agent 卡住。閘道自動處理 refresh token、重新授權。 部署選項 OpenConnector 有四條路可以走。 最輕量的是跑在本機 Docker 上。docker compose up 一行指令就起來了，儀錶板在 localhost:3000，MCP endpoint 也在同一個 port。適合開發階段或內部工具用。 ...

前言 如果你曾經用過 VideoScribe 或 Doodly 做過白板動畫，你就知道這套視覺語言有多麼強大——手繪線條在白色背景上一筆一筆出現，搭配旁白，能把複雜概念講得連阿公阿嬤都聽得懂。但問題也很明顯：手動選素材、排時間軸、錄旁白，一支兩分鐘的影片花個半天是常有的事。 現在，一位開發者 Yogendra Yatnalkar 推出了一個開源專案 Storyboard AI ，主打「輸入一段文字，自動產出一支完整的白板動畫影片」，從腳本、分鏡、插圖生成、動畫到配音字幕，全流程 AI 驅動。這個專案在 Reddit 的 r/SideProject 上引發了不少討論，目前已經獲得超過 59 個讚。 這篇文章帶你深入認識這個工具，看看它到底能做到什麼程度，以及跟市面上其他方案相比，有什麼優勢和限制。 Storyboard AI 到底是什麼？ 簡單來說，Storyboard AI 是一套 Agentic Pipeline（智能代理管線），它的核心概念是用一個「導演代理（Director Agent）」來統籌整個影片製作流程。你只需要提供一個主題或一段文字描述，它就會自動完成以下步驟： 研究與腳本撰寫：根據你給的主題，自動生成一段有吸引力的敘事腳本。 分鏡規劃：把腳本拆解成多個場景，規劃每個場景的視覺呈現方式。 素材生成：為每個場景生成白畫風格的插圖。 動畫製作：模擬手繪過程，讓畫面以「邊畫邊出現」的效果呈現。 配音與字幕：合成語音旁白，並精準對齊字幕。 整個過程你幾乎不需要插手，這就是它被稱為「E2E（End-to-End）」的原因。 技術架構：它怎麼做到的？ Storyboard AI 的技術堆疊相當紮實，我們來拆解它的核心組件： 1. Director Agent 與子代理架構 Director Agent 是整個管線的大腦。它會將你輸入的高階主題拆解成多個場景，然後將每個場景的任務委派給專門的子代理： 腳本代理：負責根據主題生成敘事腳本。 分鏡代理：規劃每個場景的視覺結構。 素材代理：生成白畫風格的插圖。 動畫代理：處理繪畫動畫效果。 音訊代理：合成旁白語音並對齊字幕。 這種「一個大代理帶一群小代理」的架構，在當前 AI Agent 應用中是非常主流且有效的设计模式。 2. 關鍵模型配置 專案的 config.py 中定義了幾個核心模型，目前使用的是 Google 的 Gemini 系列： MODEL_NAME = "gemini-2.5-pro" IMAGE_GEN_MODEL = "gemini-3-pro-image" VEO_MODEL = "veo-3.1-generate-preview" gemini-2.5-pro：負責腳本生成、分鏡規劃等文字與邏輯任務。 gemini-3-pro-image：生成白畫風格的插圖素材。 veo-3.1-generate-preview：處理影片動畫生成。 3. SAM 3 分割引擎 Storyboard AI 用到了 Segment Anything Model 3（SAM 3） 來做實例分割（instance segmentation）。這讓它能精確地從生成的插圖中提取出需要動畫化的元素，確保繪畫效果準確到位。 ...

前陣子我發現一個現象：Hermes Agent 第一次發話時的初始上下文，從之前的 1.6K tokens 左右，悄悄爬升到了 2.8K tokens，增幅接近 75%。 起初以為只是個人設定差異，結果去 Reddit 的 r/hermesagent 一看——好家伙，幾乎 everybody 都在抱怨同樣的事。 這篇就來好好聊聊這個問題：從發現、原因分析、社群反饋到實戰解法，一次講清楚。 什麼叫「初始上下文」？為什麼它很重要？ 在深入之前，先釐清一個概念：Hermes Agent 每次發話（無論你只打一個「hi」），都會把完整的 system prompt 送給模型。這包含： 核心行為規則與 persona 所有已載入工具的 schema 定義 Skill 清單（名稱 + 描述） AGENTS.md（開發者指南） Memory、User Profile、SOUL.md 等個人設定 這些全部打包在一起，就是所謂的「初始上下文」或「system overhead」。 為什麼重要？ 因為這塊 overhead 是固定成本。你發一句「今天天氣如何」和發一段 5000 字的程式碼需求，初始上下文幾乎是一樣的。對 token 計費的模型來說，這意味著你在為「沒用到的東西」付費。 更糟的是，如果這個 overhead 持續膨脹，長期下來就是一筆可觀的開銷。 1.6K → 2.8K：增長從何而來？ 根據 Reddit 社群的深度 audit，Hermes 每次發話的 token 組成大致如下： 組成部分 Token 佔比 說明 工具定義 (Tool Schemas) ~38% 50 個工具的 schema，預設全部載入 AGENTS.md ~22% 開發者指南，在 repo 內會自動載入 MCP 工具 ~9% 如 Shopify 等第三方整合 Skill List ~7% 279 個 skills 的名稱+描述 Memory / Profile / Persona ~12% 個人設定與記憶 System Prompt ~12% 行為規則、格式規範 以一個預設安裝來說，初始上下文大約落在 14K–16K tokens。但如果你把 AGENTS.md、MCP 工具、以及大量不用的 skills 排除，可以壓到 4K–6K。 ...