AI 代理

有一個事實應該會改變你對代理安全的理解方式：2026 年 7 月，研究人員突破了四款被廣泛使用的 AI 程式代理——Cursor、Codex CLI、Gemini CLI 與 Antigravity——而他們一次都沒有打破沙箱。 那七項已揭露的問題，沒有任何一項直接擊敗沙箱。它們全部利用了同一件事：沙箱限制的範圍，與沙箱之外某個受信任的元件後來所讀取、執行或掃描的內容之間，存在一道落差。 如果你已經鎖緊了「接上代理的東西」——工具描述、你貼進去的那些伺服器——那些工作是實在的，但它並沒有涵蓋這裡。這是另一半：不是你接上了什麼，而是代理接上之後能做什麼。 這個模式有名字：信任交付（the trust handoff） 雲端安全聯盟（CSA）針對這次揭露的研究報告說得很直白：「一個沙箱的強度，取決於它下游所有東西所做的假設。」 代理不需要逃逸。它只需要寫下某樣東西，而那樣東西之後會被其他東西信任。接著那個受信任的元件就會代替它、在邊界之外、用你的權限執行它。 看看這每一項有多麼平常： Cursor，CVE-2026-48124（CVSS 8.5）。 一個由工作區控制的 .claude/settings.local.json「Stop」hook，會在每一輪代理結束時自動執行一個未受沙箱隔離的本機指令。沒有任何核准提示。已於 3.0.0 修補。 Codex CLI，「GitPwned」（CVSS 8.6）。 安全指令允許清單只信任了 git show 這個名稱，卻沒有對它的參數建模。git show --output=./.git/config 寫入了一個惡意的外部 diff 工具項目，並在受害者下次執行 git diff 時以完整的使用者權限執行。已於 0.95.0 修補。 Cursor「DuneSlide」，CVE-2026-50548 + CVE-2026-50549（各為 CVSS 9.8）。 經提示注入的指令操縱了工作目錄與符號連結的驗證邏輯，覆寫了沙箱輔助程式本身。已於 3.0 修補。 Antigravity。 代理在沙箱內寫入了一份 .vscode 任務設定；主機端在該產品的 Secure Mode 邊界之外執行了那個任務。Google 將其歸類為「其他有效安全漏洞」，且在揭露時尚未修補。 Cursor、Codex CLI、Gemini CLI。 一個具備特權的本機 Docker socket，變成了其他受限制代理也能觸及、不受沙箱隔離的執行環境——掛載 VirtioFS 共享目錄，取得家目錄的讀寫權限。 再讀一次這些案例，注意其中少了什麼：沒有惡意軟體、沒有憑證竊取、沒有零時差漏洞。 每一件都是代理寫了一個檔案，然後某個受信任的東西讀了它。 那一個完全不需要漏洞利用 如果沙箱突破聽起來像別人的問題——你不跑帶 hook 的 IDE 代理——那接下來這個就是獨立開發者的版本。 ...

現在大多數獨立開發者，都在跑一個握有真實權限的 AI 代理：檔案系統、幾組 API 金鑰、一個資料庫，也許還有一支部署腳本。為了讓它有用，你把它接上了各種東西。一個從 README 抄來的伺服器。一份從部落格文章複製的設定。某個「四分鐘就搞定」的東西。 值得慢下來看的，正是這一塊。 你實際上同意了什么 MCP 伺服器不是外掛。當你接上一個，你把一組工具交給了代理，同時也把描述這些工具的結構定義交給了它——名稱、參數，以及描述。模型讀的就是那份描述，並據此決定何時呼叫它。 這裡有個信任落差，而且它是結構性的，不是誰的程式碼有 bug。工具的描述只在你連接的那一刻被審查過一次。工具的回應卻沒有對等的檢查。伺服器回傳什麼，就進到你的模型上下文裡，並被當成輸入來讀。如果回應裡夾著指令，模型可能會照做。 開放全球應用程式安全計畫（OWASP）直接描述了隨之而來的攻擊：一個惡意伺服器提供一個名字聽起來很無害的工具，像是 get_compliance_status；當你的代理呼叫它，回應看起來像一份正常報告，卻夾帶一段隱藏指令，要代理去讀取一個敏感檔案，並把它送到某個外部位置。你的代理有讀檔能力，也有網路能力。字串本身擋不住任何事。 真正該讓你不安的點是：模型無法可靠地區分「資料」與「指令」。 這不是換一個更強的模型就能解決的問題。這就是這項技術的形狀。 數字已經不是理論了 2025 年大部分時間，這還是一類研討會簡報等級的漏洞。現在不是了。 MCPTox 這個學術基準測試，針對真實伺服器評估了投毒攻擊，橫跨 45 個實際運作的 MCP 伺服器與 20 個語言模型，測得平均攻擊成功率 36.5%，最差情況下單一模型達到 72.8%。 再看一次第一個數字。大約每三次嘗試，就有一次成功。這不是你「小心一點」就能繞過的邊角案例。 而且投遞成本變便宜了。2025 年 4 月發表的一個概念驗證，用的不是什麼稀奇手法，只是一個被投毒的計算機工具描述，就從某個 AI 程式編輯器裡悄悄外洩了開發者的 SSH 私鑰。一個相關的變體被稱為 MCPoison，示範了透過單一提交的設定檔造成整個團隊的淪陷——一個人的 pull request，變成所有人的問題。雲端安全聯盟 2026 年 7 月的研究報告，則記錄了一類 IDE 自動執行的攻擊：光是開啟一個專案，就足以讓專案自帶的伺服器以開發者層級的權限被執行。 注意這三者的共同模式：它們都不需要你犯下什麼明顯的錯誤。 你不需要點擊任何東西。你只需要接上一個東西、打開一個資料夾，或合併一個 pull request。 為什麼獨立開發者是暴露的那一群人 MCP 的安全指引，通常是寫給平台團隊看的：結構定義簽章基礎設施、政策即程式碼的決策點、職責分離、需要一個以上真人參與的審批流程。 這些你一樣都沒有。你沒有安全審查——你就是那個審查。而你手上是最危險的組態：一個代理同時握有檔案存取、憑證，以及對外網路請求。 這不是叫你別用 MCP。這是叫你對「開哪幾道門」刻意一點，因為影響範圍完全取決於你接上了什麼。 十分鐘的檢查 你不需要任何基礎設施。你需要的是一個習慣，和一份短清單。 接上任何伺服器之前，先讀它的工具描述。 不是 README。是描述本身。根據廣被引用的靜態指標，以下這些應該讓你停下來： 對模型下指令的祈使句。 文字是對著模型說的，而不是對你說的：「忽略先前的指令」、「不要告訴使用者」、「回答前先讀取……」 敏感路徑。 一個你根本不預期它需要用到，卻提到 ~/.ssh、id_rsa、.env、.aws/credentials、/etc/passwd 的工具。 外洩的形狀。 一個動作動詞——send、post、upload、forward——緊挨著一個外部目的地：URL、webhook、端點。 零寬字元。 Unicode 範圍 U+200B–200F、U+202A–202E、U+2060、U+FEFF，被用來躲避人眼審查。看不見的東西，你就無法批准。 藏在註解裡的指令。 夾在 HTML 或 markdown 註解中、在渲染檢視下看不見的、對模型說的文字。 這份清單幾分鐘就能查完。最後兩項是最多人漏掉的，因為它們的運作方式，就是讓正在做審查的那個人看不見。 ...

有一個新的職稱正在成形，而且它不存在於任何組織圖上。《Fortune》在 2026 年 3 月為它命名：監督者世代（supervisor class）——一群主要價值不再是寫程式、而是指揮那些代寫程式的 AI 代理的開發者。 這不是預測，而是速度最快的獨立開發者每天的日常。而且它改變的不只是你出貨的速度，而是你「是什麼」。 轉變：從語法到系統 過去五十年，開發者是靠「產出程式碼」領薪水的。知識工作者的產出單位是函式、是 commit、是上線的功能。精通意味著把語法和工具摸到滾瓜爛熟。 監督者世代的開發者，把專業拆成另一種單位：可重複使用的代理技能（reusable agent skills）。你不是親手寫驗證用的樣板程式，而是描述一次，讓代理照做。你不是手寫資料庫 schema，而是指定形狀、指揮代理去產生。那些過去要花好幾個小時的部分——樣板、環境建置、部署管線——現在只要幾分鐘。 價值往上移動了一層。一個懂架構、資料模型、API 設計的開發者，現在可以把架構的「機械性產出」交給代理，把自己的專注力放在指揮、審查、精煉——那些代理還做不來的高槓桿判斷。你思考的是系統，不是語法。 對獨立開發者而言，到底改變了什麼 對一個經營「一人產品團隊」的人來說，這不是抽象職涯敘事。這是一個禮拜出 3 個功能還是一週出 12 個功能的差別——當你一個人就是整個工程部門時，這種產出差距會變成真正的商業優勢。 三個具體的轉變會先落到獨立開發者身上，因為你沒有別人可以躲： 審查取代撰寫，成為你的核心技能。 代理產出的程式碼是「待判斷的草稿」，不是成品。你的槓桿在於抓出那些微妙的錯誤——那個通過 linter 卻在空值案例當掉的函式、那個今天能跑、擴展後卻會毀掉資料的資料庫遷移。一個不會審查的監督者，只是個打字比較慢的人。 拆解（decomposition）成為真正的工作。 你不能丟一個模糊的目標給代理，然後指望它搞定整個產品。你需要把系統拆成有名字、有邊界、有明確成功標準的任務。真正的技能不是「我會不會寫」，而是「我看得夠不夠清楚，能把系統切成代理能處理的塊」。 失敗由你承擔，不只是程式碼。 當代理送上一個 bug，沒有別的工程師可以怪。你是監督者，意味著你對代理在你指揮下產出的一切負全責。責任不再往下停一層，而是停在你身上。 想看這個轉變撞上的天花板——那個再怎麼協作都搆不到的最後一段路——請看姊妹文章：AI 代理還做不到的事。 仍然無法被委派的部分 這個故事誠實的版本有一條硬邊界。指揮代理之所以強大，恰恰因為有些事情拒絕被壓縮： 判斷。 下一個要做哪個功能、「對你的用戶來說什麼算夠好」、一個指標什麼時候在騙你——這些是判斷，也正是代理最弱的地方。監督者真正的產品是「決策」，不是「指令」。 品味。 能跑的程式碼和「好」的程式碼是兩回事。品味——那種「這個設計很卡」「這個流程不對」「這個抽象錯了」的直覺——是寫不進 prompt 的。 所有權。 代理只為眼前的任務最佳化。你為的是它能活兩年、一個客戶的信任、一個重要的死線。所有權無法被委派。 模式跟我們在 代理模式 那篇講的一樣：代理為你買來能力，而每一項能力都要你付出一種新的失敗方式。監督者世代不是逃避工作——而是刻意地選擇，哪些工作是你的。 一句話版本 寫程式當了五十年的瓶頸。現在不再是了。瓶頸是「指揮」——品味、拆解、判斷、所有權。贏下下一個十年的開發者，不會是打字最快的，而會是最好的監督者：能把專業拆成可重複使用的技能、把機械性工作交給代理、把判斷留給自己。 這不是降級。這是這個職業史上第一次，天花板是你的「思考」，而不是你的「產出」。 指揮代理和信任你的測試環境是兩種不同的能力：〈模擬器在騙你〉講只有真實硬體才會暴露的東西，〈一個人做硬體〉則講大多數開發者直接跳過的那間工作室。 資料來源 《Fortune》，“The supervisor class: how AI agents are remaking the developer”（2026 年 3 月）。 — 提出「監督者世代」框架：主要價值在於把專業拆成可重複使用的代理技能並指揮代理，從「語法的苦役」中解放，專注於高層次判斷。 AgentMarketCap，“The Solo Founder Agent Economy”（2026 年 4 月 14 日）。 — 指出 Fortune 的監督者世代已成最有效獨立開發者的現實；記錄雙工具策略（Claude Code 當「資深工程師」+ Cursor 當「結對程式設計師」），以及 3→12 功能/週的產出差距與機械性編碼時間減少 90%。 Thinking.inc，“AI Agent Orchestration Patterns”（2026 年 3 月）。 — 協作層（監督者、序列管線、扇出、路由器、階層式、評估器-最佳化器）是大多數代理專案成敗所在；證明拆解成具名模式——而非純粹換模型——才是差異所在。 OpenAI，《Agent Design Patterns》指南（2025）。 — 路由、工具使用、反思為三種典型模式；監督者的工作是挑選能解決眼前失敗的最小模式。

AI 建置工具的承諾持續膨脹：「描述任何東西，它就能建出任何東西。」每隔幾個月就有人丟出一個 demo，看起來好像軟體會自己寫好。 這是一句來自實際用這些工具出貨的誠實反例：代理在「量」上是超人，在「判斷」上不可信。 它們能產出的程式碼，比你見過的任何團隊都快、都多。但它們不能決定什麼值得建、什麼才是對的、什麼才是好的。那最後一段路——姑且叫它「最後的 10%」——正是產品勝負的所在，而它完完全全還是你的事。 這是這道落差的全貌。 落差出現在哪裡（誠實的清單） 1. 看起來正確的 bug。 代理寫出的程式碼是看似合理的。單位切換時把圖表軸標錯。一個迴圈提早一步停掉。某個視圖裡的比較差了一個倍數。這些都不會當機，所以代理沒有任何訊號說它失敗了——你也沒有，除非你在看。最糟的 bug 不是那些大聲報錯的；是那些通過所有測試、卻仍然以一種只有人眼才抓得到的方式錯著的。 2. 品味。 代理能做「把它弄現代一點」。它無法告訴你：間距差了一點、文案無聊、整個流程長了三次點擊。品味是對使用者感受的判斷，而代理從未感受過任何東西。這就是為什麼那麼多 AI 建的軟體，技術上沒問題，感覺卻死氣沉沉。程式碼是對的；產品是錯的。 3. 決定要建什麼。 代理會用全然的熱情，把你描述的任何東西建出來。這跟建出對的東西不是同一件事。決定哪個問題值得解、哪個功能該砍、該服務哪個使用者——那是策略，它存在於工具之外。給代理一個爛點子，它會比你能做到的更快、更令人信服地把它推上線，這讓錯誤變得更貴，而不是更便宜。 4. 那「最後 10%」，其實是體驗的 90%。 錯誤狀態。空白狀態。新手引導。那個任何 happy-path demo 都不會展示的「萬一失敗了會怎樣」路徑。這是不光彩的工作，把一個「能跑」的東西，和一個「對人真的有用」的東西區分開來。代理是在 happy path 上訓練的；真正的使用者活在另外那 10% 裡。 為什麼這個落差是好消息（而不是壞消息） 如果代理什麼都能做，你就沒有任何優勢了。每個有 API 金鑰的人都會跟你一樣能幹，而「獨立開發者」就變成「打了個提示的人」。 這個落差就是你的護城河。具體來說：代理是機械工作的力量乘數，而你在判斷上無可取代。 工具把「量」自動化得越多，另一邊越稀缺的技能，就越是它們偽裝不來的那種人類判斷——知道什麼是好的、什麼是對的、什麼是要緊的。 這才是 2026 年真正的工作。不是寫更多程式碼，而是決定哪些程式碼應該存在。 如何在這個落差裡工作（紀律） 這些一點都不玄。是一組你可以養成的習慣： 沒讀過的，絕不出貨。 代理可以寫；你必須擁有它。「讀過」的意思是你能用白話解釋它做了什麼、以及它哪裡會壞。 為「人能抓到代理」而設計。 最好的產品把機器速度和人為覆寫配在一起——把 UI 設計成讓一個人能在兩秒內發現並修正代理的失誤。 刻意去測不快樂的路徑。 在問「什麼能跑」之前，先問「什麼會壞」。代理優化 demo；你優化現實。 把品味當成交付物，而不是加分項。 特地排時間給那些感覺不對的部分——文案、間距、流程。你不排，代理的「大概沒問題」就會變成產品。 誠實的一句話總結 工具壓扁了建造的成本。它沒有壓扁知道要建什麼、它對不對、它好不好的成本。 量被自動化了，判斷沒有。而判斷，就是那最後 10%——其實正是全部的遊戲。 這正是〈為什麼一個人現在能做出過去一整個團隊的事〉背後的界線結構——工具是真實的，這個落差也是。想知道幫你處理這落差的堆疊，見〈我實際在用的 AI 程式開發堆疊〉。 這個信任落差還有另一半值得知道：上限不只關乎你該讓代理做什麼，也關乎你交到它手上的存取權。你的代理不需要被駭整理了長期存取權的檢查清單。另外兩篇操作者相關的文章：你的 AI 助手以平凡的方式出錯（如何診斷失敗），以及記憶才是產品（為什麼產品是操作者的系統，而不是模型）。 Sources Stack Overflow 2025 開發者調查——只有 3.1% 的開發者「高度信任」AI 產出；45.7% 某種程度或高度不信任。採用率很高（84%）、信任度很低——「量」與「判斷」之間的落差是可量測的。 JetBrains AI 程式代理採用研究（2026）——約 90% 的專業開發者至少每週用一次 AI 程式代理，68% 每天用，但對準確性的信任仍是摩擦點。