從副駕駛到同事：AI 自主運作意味著什麼

以研究為基礎，審視從建議引擎到自主隊友的轉變。為何此刻正在發生、過渡期間哪些環節出了問題，以及如何在不把王國鑰匙拱手相讓的情況下完成部署。

副駕駛時代正在觸頂

2026 年 4 月 15 日，Sam Altman 在 X 上發文，表示 OpenAI 正在推出「本週針對團隊與大型企業的 Codex 更新」。

留言區的反應耐人尋味。每一位詢問產品路線圖的開發者，旁邊就有另一位提出更難回答的問題：為什麼 Codex 還是需要我在旁邊盯著？ 六個月前，BeyondTrust 的研究人員發表了一份概念驗證報告，顯示一個精心構造的 Git 分支名稱可以誘騙 Codex 洩露使用者的 GitHub token。一個能被分支名稱騙到洩漏 token 的副駕駛，不是同事，而是一把上了膛、只有保險栓的槍。

這種張力潛伏在 2026 年每一場企業 AI 對話之下。副駕駛已經碰到天花板，數字說明了一切：

MIT 的 NANDA 計畫於 2025 年報告指出，95% 的生成式 AI 試驗未能帶來可衡量的商業價值。
RAND 的一項研究在 2026 年初被 Reddit 的 r/ArtificialIntelligence 社群反覆引用，發現 80 至 90% 的 AI 代理專案在生產環境中失敗。
GitHub Copilot 的開發者採用率已趨於平緩，落在 35 至 40% 左右，Cursor 為 42 至 45%，而 Claude Code 在 2026 年 AI 程式設計調查中獲得 **46% 的「最受喜愛」**評分——對一個 2025 年 5 月才推出的工具而言，這是驚人的逆轉。
據報導，Satya Nadella 在 2025 年底稱微軟內部的 Copilot 推行「幾乎無法使用」，公司隨後宣布了一項高層主管內部稱為「高風險重置」的產品調整。
arXiv 於 2025 年底發表的一項研究發現，Copilot 式的自動補全實際上增加了資深開發者的挫敗感，因為它以看似合理卻微妙出錯的建議打斷了他們的工作流程。

觸頂並非底層模型的失敗，而是互動模式的失敗。副駕駛在個別按鍵或問題的層次上運作；同事則在工作流程的層次上運作。Bits&Chips 在其 2026 年 4 月的文章〈From copilot to colleague〉中說得很到位：「副駕駛在個別互動的層次上運作，而代理則在工作流程的層次上運作。這很重要，因為在大多數組織中，瓶頸不在於個別任務，而在於任務之間的協調。」

這正是企業現在試圖完成的轉變——不均衡、不完美，卻在相當大的規模上進行著。

自主性的光譜

「代理」已成為一個行銷術語，所以讓我們具體說明。AI 自主性有四個截然不同的層次，2025 年和 2026 年大部分的失望，都源於將其中一個層次與另一個混淆。

第一層：副駕駛

提出建議、請求許可、停留在你的螢幕上。GitHub Copilot 的自動補全是典型代表。價值以節省的按鍵次數衡量。

第二層：助理

根據請求回答問題並撰寫內容。ChatGPT、瀏覽器中的 Claude、Microsoft 365 Copilot 的聊天面板。價值以草稿品質和情境整合能力衡量。

第三層：代理

接受目標、規劃一系列步驟、跨工具執行、回報結果。Claude Code 掃描程式庫並開啟 PR；ChatGPT 的 Deep Research 執行 20 分鐘的搜尋並回傳附有引用的報告。Anthropic 記錄了一個 Claude 實例為 Rakuten 完成長達 7 小時的自主工程任務。價值以每人工小時完成的工作流程數量衡量。

第四層：同事

在你現有的權限模型內運作、參與團隊的溝通頻道、跨天跨週保持情境記憶，並對相同的稽核軌跡負責，一如人類員工。這是目前的前沿。

Reddit 的 r/ChatGPT 社群提出了一個實用的測試來區分這些層次，意譯如下：這個東西會主動採取行動，還是等待每一條指令？它能處理意外情況，還是當機後讓你重新下提示？它能在多步驟任務中記住情境，還是你必須一再重複？ 2025 年大多數以「AI 代理」為名行銷的產品，在這三個問題上全部失敗。通過測試的，才是人們現在說「同事」時的真正所指。

電腦操控 vs 技能：為何底層架構至關重要

同事等級的 AI 需要在現實世界中採取行動。達成這一點有兩種架構方式，它們帶來截然不同的風險輪廓。

電腦操控

AI 驅動模擬的滑鼠和鍵盤，字面上看著螢幕並點擊按鈕。Anthropic 在 2024 年底推出了 Computer Use，OpenAI 的 Operator 隨後跟進。其吸引力在於通用性：任何有 GUI 的軟體都可以被操作。

代價是爆炸半徑。使用電腦操控的代理繼承了登入使用者的所有權限。2025 年 10 月，BeyondTrust 的安全團隊示範了 OpenAI 的 Codex 代理可以被誘騙——透過一個嵌入 shell 指令的惡意 Git 分支名稱——讀取並洩露使用者的 GITHUB_TOKEN。代理做的事和人類開發者完全一樣（切換到某個分支），但它沒有直覺判斷分支名稱本身是惡意輸入。在那次事件中，授權模型是全有或全無的。這是電腦操控的預設失敗模式。

技能

AI 呼叫離散的技能。每個技能都是一個明確的、有型別的函式，具有明確的合約：「在 Slack 中搜尋符合 q 的訊息」、「建立一個標題為 title、內容為 body 的 Linear 議題」、「讀取這個 GitHub 檔案」。與電腦操控不同，技能具有預先核准的形狀。代理只能以符合合約的參數呼叫它，平台可以在呼叫離開沙箱之前允許、拒絕或提示確認。

從安全角度來看，差異歸結為最小權限原則。這是資訊安全的基礎概念：一個程序應該只能存取執行其功能所需的資源，不多也不少。技能讓你能夠對每次呼叫強制執行最小權限。電腦操控做不到。

同事等級的部署使用技能來執行結構化操作（寫入 CRM、開立工單），並將電腦操控保留給那些拒絕提供 API 的少數應用程式。比例很重要。如果你的代理部署中每個操作都要透過模擬滑鼠進行，你擁有的是一個生產力展示，而不是生產系統。

企業真正需要的信任架構

從副駕駛到同事的轉變，不是模型升級，而是基礎設施升級。三個要素將可部署的同事與潛在責任區分開來。

1. 權限隔離

每個代理在自己的權限邊界內運作，其憑證無法被代理自身從沙箱中取出。Andrej Karpathy 在 2026 年 3 月廣為流傳的 autoresearch 實驗——他讓一個代理在兩天內無人看管地執行了 700 次訓練實驗——在它沒有做的事情上很有啟發性。Karpathy 自己的程式庫指示使用者在自主模式下「停用所有權限」。這對個人研究用的筆電來說沒問題，但在受監管的企業內部，這是可以被開除的行為。

反面教材是 Moltbook，這個純 AI 社交網路在 2026 年 1 月底短暫爆紅，擁有 150 萬個自主代理。Karpathy 稱讚它是「我最近見過最令人難以置信的科幻起飛相關事物」。然後 Wiz 的安全研究人員發現前端暴露了一個資料庫 API 金鑰，授予對整個生產資料庫的完整讀寫存取權，包括所有 150 萬個代理的身份驗證 token。Karpathy 在 24 小時內改口：「這是一場災難。我絕對不建議大家在自己的電腦上執行這些東西。」 教訓不是「代理很危險」，而是沒有按身份隔離權限的代理部署，會崩潰成一個共享的爆炸半徑。

2. 稽核軌跡

每個操作都有記錄，每個決策都可追溯。新加坡 IMDA 框架於 2026 年 1 月在達沃斯發布，以雙軸風險矩陣將代理的行動空間（讀取 vs 寫入、可逆 vs 不可逆）與其自主性（獨立決策的程度）對應起來。任一軸越高，稽核要求就越嚴格。這個框架正受到歐洲和美國監管機構的密切研究，因為它是最早將治理從抽象原則轉化為可操作校準工具的框架之一。

Simon Willison 同時主張採用統一日誌記錄，讓代理能夠監控自身操作並從錯誤中恢復：「擁有完整系統存取權的代理既強大，也危險。」 實際要點是：如果你的代理部署沒有合規人員可以按順序閱讀的統一日誌，你距離失去部署權限只差一次事件。

3. 範圍限定的技能存取

不是籠統的「存取電子郵件」，而是允許執行 search inbox where from:@customer.com AND within last 7 days。現代代理平台正朝向參數化範圍發展，代理呼叫技能的權限受到管理員預先核准的參數約束，而不是人類使用的粗糙 OAuth 範圍。

將這三個要素結合起來，它們回答了每位 CISO 現在都在問的問題：這個代理出錯時會怎樣，我怎麼知道？ 2026 年麥肯錫《AI 現狀》調查發現，72% 的企業受訪者將網路安全列為生成式 AI 的顧慮，而安全性被約三分之二的受訪者列為擴展代理工作流程的首要障礙。權限隔離、稽核軌跡和範圍限定的技能存取，不是合規表演，而是關鍵的基礎設施。

為何現在至關重要：三股力量的匯聚

2026 年從副駕駛到同事的轉變，並非由單一突破驅動，而是三條曲線交匯的結果。

力量一：整合不再是客製化工程

2024 年，將代理接入企業 SaaS 技術棧意味著為每個工具編寫自訂連接器。到 2026 年初，有型別的技能合約和預先打包的連接器已大幅降低了這項工作量。2024 年需要六週整合的代理，2026 年只需要一個下午。典型中型市場公司的技術棧（Slack、GitHub、Gmail、Linear、Notion、HubSpot、CRM、行事曆）現在已被成熟的開源連接器函式庫覆蓋，這些函式庫內建了有型別的權限。

力量二：多代理成為現實

Gartner 將多代理系統列為 2026 年頂級策略技術趨勢。傑出副總裁分析師 Gene Alvarez 提出了一個現在出現在每張企業 AI 投影片上的比喻：「想想 F1 賽車的維修站團隊。每個成員都有專門的角色（換輪胎、加油、操作千斤頂），但他們圍繞著一個共同目標協調運作。這就是 2026 年企業代理部署的形態。」單一代理系統在長期任務上會碰到推理天花板。多代理系統，透過專門的角色和明確的交接，是團隊今天突破這些天花板的方式。

力量三：企業預算解鎖

G2 在其 2026 年軟體現狀研究中報告，57% 的公司已在生產環境中部署 AI 代理（比一年前的約 20% 大幅提升）。
麥肯錫發現 23% 的企業正在積極擴展代理式 AI，62% 處於實驗階段，只剩約 15% 的大型組織仍在觀望。
德勤對 3,235 位企業領導者的 2026 年調查，將金融服務業列為領先採用者，並記錄了一個 AI 代理捕捉會議成果並在交易管道中採取行動的案例研究——此前這項工作需要三位分析師。
史丹佛的企業 AI 實戰手冊於 2026 年初發布，收錄了 51 個生產部署案例，其中一個金融科技 ETL 遷移案例成為受監管行業團隊的參考實作。
企業 AI 基礎設施投資在 2025 年週期中突破 6,000 億美元。
Anthropic 的 Dario Amodei 在 Code with Claude 大會上發言，給出 70 至 80% 的機率，認為第一家由代理勞動力驅動的單人十億美元公司將在 2026 年出現。

資金到位、協議到位、架構到位。現在每個董事會正在協商的，是多少自主性、在什麼治理框架下、以及哪些工作流程適用。

懷疑者的論點：Reddit、arXiv 和事件報告怎麼說

對這一轉變的負責任審視，必須認真對待那些認為整件事被過度渲染的人。

在 Reddit 上，r/LocalLLaMA、r/ClaudeCode 和 r/ChatGPT 的共識是務實的：程式設計代理已經到來且有用。大多數其他「代理」是穿著聊天機器人外衣的自動化工作流程。 在 2026 年數十個討論串中被引用的那句話——「想要建議就用 Copilot，想要它真正做事就用 Claude Code 或 Cursor」——捕捉了這種有效的區分。這些社群對基準測試也毫不留情。即使是最好的代理，在 Terminal-Bench 上的整體得分也只有約 60%，在困難任務上更降至 16%。Claude Opus 4.5 以 80.9% 領先 SWE-bench，但這仍意味著每五個任務就有一個失敗。

學術界的懷疑更難以消除。Vishal Sikka（前 SAP 技術長、John McCarthy 的學生）與其合作者發表了《Hallucination Stations: On Some Basic Limitations of Transformer-Based Language Models》，從數學角度論證 transformer LLM 在執行超過一定複雜度的計算和代理任務方面存在根本性限制。Sikka 的結論——對於高度關鍵的操作，「它們根本無法做到可靠」——正在每個 CISO 的 Slack 頻道中流傳。這篇論文並非聲稱代理無用，而是主張存在一類問題，無論模型多好，都無法將人類移出迴圈之外。

真實事件支持了這種懷疑。Yellow.ai 2026 年調查中引用的一位零售客戶體驗主管說：「我們在僅僅兩週後就不得不撤回 AI 客服，因為它在約 1.35% 的工單中開始引用錯誤的退貨政策並捏造折扣優惠。兌現這些錯誤的成本遠遠超過我們希望節省的金額。」在規模化之下，即使是低於 2% 的錯誤率也會迅速變得代價高昂。

綜合來看：同事等級的 AI 在程式設計、研究、結構化運營和範圍明確的客服工作流程中是真實存在的。在沒有人工審核的開放式客戶互動中，它尚未成熟。2026 年獲得價值的企業，是那些誠實評估某個工作流程屬於哪個類別的企業。

實際意涵：部署前的五個問題

如果你的團隊正在評估一個 AI 隊友（內部開發或第三方），以下問題能區分生產部署與險些出事的差別。

這個代理能採取的最壞單一行動的爆炸半徑是什麼？ 字面上畫出來。如果最壞的情況是「把草稿郵件發給錯誤的人」，治理門檻就很低。如果是「修改生產資料」或「發送電匯指令」，門檻就高出一個數量級。在部署之前畫出來，而不是在第一次事件之後。
代理如何取得憑證，它能讀取原始 token 嗎？ 有三種答案，只有一種是安全的。如果代理在其環境中有使用者 OAuth token 的副本，你實際上是把錢包交給了 LLM。如果代理透過獨立的服務帳號 OAuth 擁有「自己的」身份，你需要像追蹤真實主體一樣追蹤、撤銷和稽核它。第三種答案，也是你真正想要的：token 永遠不會到達代理。它加密存放在平台上，在網路代理層即時注入，僅用於通過政策檢查的呼叫，且僅在呼叫返回之前有效。
每個操作是否都記錄在合規人員可以按順序閱讀的地方？ 統一、可查詢、防竄改。如果你的答案是「我們在 CloudWatch 某處有一些日誌」，你還沒準備好。
你能將技能存取範圍限定到這個工作流程所需的特定參數嗎？ 按呼叫，而不是按整合。讀取 vs 寫入。按資源 ID。按時間窗口。代理的權限應該是緊緊圍繞工作畫出的矩形，而不是整個倉庫。
如果出了問題，回滾方案是什麼？ 如何撤銷一個操作？多快？誰會被通知？不可逆的操作（資金轉移、面向客戶的郵件、生產部署）需要確認步驟或延遲窗口。可逆的操作可以自主執行。

逐一思考這五個問題。如果你能全部回答，你已經超越了副駕駛時代，進入了真正改變團隊交付方式的階段。如果你能回答兩三個，那就是下一步的重點，而不是等待的理由。你的路線圖所追求的同事等級隊友，今天已經在某處的生產環境中運行了。你與它之間的差距是基礎設施差距，而不是前沿 AI 差距。基礎設施差距縮小得很快。

你不需要等待下一個模型發布。你需要選擇一個已經為你回答這五個問題的平台，然後開始給你的代理真正的工作。

常見問題

副駕駛和 AI 同事之間真正的差別是什麼？

副駕駛提出建議、請求許可，並存在於單一工具中。同事接受目標、跨系統規劃、以範圍限定的權限執行，並對相同的稽核軌跡負責，一如人類。Bits&Chips 說得很清楚：副駕駛在互動層次上運作，同事在工作流程層次上運作。

代理應該如何處理使用者憑證？

兩種顯而易見的選項都不對。將使用者的 OAuth token 複製到代理的環境中，等於把一個有效憑證放進 LLM 的情境裡。為每個代理建立獨立身分，等於讓每個代理成為一個你必須像人類一樣追蹤、撤銷和稽核的主體。實際上有效的模式是透過中介存取：token 加密存放在平台上；沙箱的對外網路代理在發出請求時回呼平台；平台解密 token，只為通過政策檢查的呼叫傳回解析好的驗證標頭；AI 代理本身永遠不會讀取、記錄原始 token，也不會將它放入提示詞。

電腦操控還是技能，我們應該選哪個？

預設選技能，適用於任何有 API 的情況。電腦操控僅用於目標系統沒有可程式化介面的情況。BeyondTrust Codex 事件是警示故事：電腦操控繼承了使用者的完整權限，代理視野中任何地方的惡意輸入都可能成為漏洞。

我們實際上應該讓代理自主到什麼程度？

使用新加坡 IMDA 的雙軸框架：行動空間 × 自主性。窄行動空間（唯讀、可逆）可以容忍高自主性。寬行動空間（寫入、不可逆、面向客戶）需要人工確認或延遲介入窗口。最糟糕的配置是在高風險操作上設置高自主性且沒有稽核軌跡。

我們如何衡量投資回報？

停止衡量節省的按鍵次數。衡量每人工小時完成的工作流程數、運營事件的解決時間，以及逃逸率（代理交回給人類的任務）。德勤 2026 年的研究顯示，領先採用者正在追蹤三個指標：工作流程完成率、錯誤率和人工介入率，並優化它們之間的比例。

面對 95% 的試驗失敗率，我們該怎麼辦？

仔細閱讀 MIT NANDA 的分析。失敗的試驗大多依賴「笨拙的 RAG」（把所有東西都塞進情境）、「脆弱的連接器」（損壞的 API 整合），以及沒有事件驅動架構。成功的試驗在 LLM 周圍有一個運作層：記憶體、I/O 和權限。LLM 核心不是瓶頸，周圍的基礎設施才是。

VM0 的定位

我們圍繞一個架構賭注建立了 Zero：代理永遠不應持有憑證。 不在其環境中，不在其提示中，不在其記憶體中。Token 留在平台上。代理發出的每個出站呼叫都透過網路代理進行仲裁，由代理逐次決定是否注入驗證標頭或阻擋請求。

這是一個不尋常的選擇。2026 年的常見模式，要麼是給代理自己的 OAuth 身份（現在你有第二個主體需要稽核和撤銷），要麼是在環境變數中把使用者 token 的副本交給它（現在 LLM 可以讀取你的錢包）。我們兩者都不做。以下是它實際的運作方式。

Token 永遠不會到達代理。 當你將連接器連接到 Zero（GitHub、Slack、Gmail、Linear、Notion、HubSpot 等），OAuth token 會加密存放在平台上。刷新 token 留在資料庫中，永遠不會離開。在沙箱內部，沒有可讀取的 GITHUB_TOKEN 環境變數，沒有可開啟的密鑰檔案，沒有返回 token 的工具。

網路代理仲裁每次呼叫。 離開沙箱的每個 HTTP 請求都會通過基於 mitmproxy 的附加元件。代理從請求的主機名識別連接器，查找該代理的防火牆政策，並檢查方法和路徑是否被允許。如果允許，代理回呼平台的 webhook。平台解密 token，在過期時刷新，解析任何標頭範本（${{ secrets.GITHUB_TOKEN }} 變成真實值），並僅將通過政策檢查的呼叫的已解析驗證標頭返回給代理。代理將這些標頭注入出站請求。呼叫完成後，標頭從代理記憶體中消失。代理從未看到它們。

權限按代理、按連接器，並在端點層級有型別。 每個代理攜帶一個政策物件，將每個連接器映射到一組命名的權限群組。github:repo-read 不是一個模糊的範圍，而是一組特定的方法和路徑規則，例如 GET /repos/{owner}/{repo}/pulls。授予 GitHub 存取權，不是授予整個 GitHub，而是授予 GitHub 內部一個特定意圖的形狀。

三種政策狀態，而非兩種。 每個權限解析為 allow（允許）、deny（拒絕）或 ask（詢問）。最後一種在操作執行前提示人工確認。防火牆未明確匹配的任何內容，都會落入按連接器設定的 unknownPolicy，預設為 deny。最小權限是預設值，而不是選擇性啟用。

每次執行一個沙箱。 每次代理執行都在自己的 Firecracker 微型虛擬機中進行，具有隔離的網路命名空間。執行結束後，命名空間被拆除。同一代理的兩次執行是兩個獨立的沙箱，具有兩個獨立的稽核軌跡。

按請求的稽核軌跡。 決定允許/拒絕的同一個代理，也會寫入一個按執行的 JSONL 日誌，每個請求都附有防火牆元資料：連接器、匹配的權限群組、匹配的具體規則、決策、時間戳。這些日誌回傳到平台。如果 CISO 需要知道代理在 4 月 14 日下午 3 點到 5 點（CST）之間做了什麼，只需一次查詢。

一個能解釋自身拒絕的 CLI。 當某個權限阻擋了呼叫時，代理（或坐在旁邊的人）可以執行 zero doctor permission-deny <connector> --method <M> --path <P>，取得阻擋請求的確切權限群組，以及修復連結。zero doctor permission-change 讓管理員直接切換權限，或讓成員提交書面請求（上限 500 字元，確保理由真的被閱讀），路由到管理員。高風險權限如 slack:chat:write 或 gmail.send 會觸發額外警告，指向更安全的機器人範圍替代方案。

兩個角色，一個審批流程。 擁有者和管理員直接更改權限。成員提交附有理由的請求，路由到管理員。沒有第三個「半管理員」層級。流程足夠簡單，人們實際上會使用它——這才是重點。

我們將電腦操控保留給那些拒絕提供 API 的少數遺留系統。其他一切都透過技能進行。每個操作都經過政策檢查。每個憑證都留在平台上。每個決策都有記錄。

如果你已經超越了「又一個 AI 自動補全」的階段，想試試一個安全團隊會簽字核准的 AI 隊友，了解 Zero 如何處理排程工作流程、分類生產事件，或執行早晨產品簡報。

副駕駛時代並未結束，而是正在被更大的事物所吸收。在下一個週期勝出的團隊，是那些理解其中差異的團隊。