Agent-Native Infrastructure

資料來源#

• Andrej Karpathy: From Vibe Coding to Agentic Engineering
• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501
• OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts

摘要#

Andrej Karpathy指出，數位世界仍是為人類打造，必須改寫成適合代理程式的環境。他最常抱怨的一件事是：文件竟然是寫來指示人類的。「為什麼大家還在告訴我要做什麼？我什麼都不想做。我該複製貼上什麼給我的代理程式？」原生支援代理程式的世界會將工作拆解為感測世界的感測器，以及作用於世界的致動器，並且所有事物都要「優先描述給代理程式」。最後，還要為人和組織建立代理程式代表：「我的代理程式會和你的代理程式交談，商量我們開會的細節。」

複製貼上給代理程式的安裝方式#

具體的起點（也和 Software 3.0 相同）：安裝 OpenClaw 不靠 shell script，而是把一段文字貼給代理程式，由它檢查你的環境並在迴圈中除錯。推而廣之：原生支援代理程式的軟體，其散布單位是提示／技能，而非可執行檔。文件、設定和安裝流程都應該提供「把這些交給你的代理程式」，而不是「由你執行以下步驟」。

感測器與致動器#

Karpathy 用機器人學的概念重新詮釋代理程式基礎設施：把任何工作負載拆成感測器（代理程式可讀取的清楚輸入）和致動器（代理程式可採取的動作），接著讓這些介面都能被代理程式理解。他也強調要大力投資「對 LLM 來說非常清楚易讀的資料結構」。設計問題於是從「人類需要什麼樣的 UI？」轉向「代理程式能感知什麼，又能對哪些事採取動作？」

部署摩擦透露的訊號#

Karpathy 用 MenuGen 測試基礎設施是否已原生支援代理程式：難的不是程式碼，而是部署到 Vercel（DNS、服務設定、選單、串接服務，「煩死了」）。他的理想是：「給 LLM 一個提示，建好 MenuGen，我完全不用碰任何東西——它就部署到網際網路上。」當這趟往返完全不需要人類點擊 GUI，基礎設施才算原生支援代理程式。（這也連到 MCP and Computer Use：MCP 讓服務能以程式方式被代理程式理解；無法做到時，電腦操作就是備援方案。）

終點：由代理程式代表委託人#

進一步推演，代理程式將代表人和組織，透過代理程式對代理程式完成排程、協商與協調。「我會讓我的代理程式和你的代理程式交談，商量我們開會的細節。」這就是原生支援代理程式世界的社交協定層，也是 AI Employee Framing／Human-AI Accountability Redesign 所探討的問題開始浮上檯面的地方（誰要為代理程式的承諾負責？）。

反向案例：意外成為原生支援代理程式的環境（DHH，2026 年 8 月）#

本文的前提是：為人類打造的世界必須改寫成適合代理程式的環境。DHH 提供了相反的案例，而在本文語料中，這是對此概念最有意思的觀點：桌面 Linux 不需要改寫，因為那些讓它對人類不友善的特性，正是代理程式想要的（Lex Fridman #501，2026-08-26，practitioner-opinion；請注意，他發行 Linux 發行版，因此這同時是分析和產品定位）。

有四項特性，沒有一項是為此而設計：

• 所有東西都是設定檔或 CLI 工具。「代理程式喜歡 Unix 哲學……地球上幾個主要作業系統——Mac、Windows、Linux——沒有一個比 Linux 更適合這種機制。而這五分鐘前還是它最大的缺點。」Karpathy 所說的感測器／致動器拆解方式，在這個平台上早已存在；沒有人需要另外打造。
• 晦澀的錯誤訊息變成資產，而非負擔。「代理程式可以拿那段對一般人來說毫無意義的具體錯誤訊息，連結到它預訓練時讀過 4,000 萬行 Linux 程式碼這件事，於是它確切知道該去哪裡找。」沒有原始碼就無法利用的明確資訊，現在有了原始碼就能派上用場。
• 每個已安裝元件的原始碼都能取得。「代理程式知道的不只是 Linux 作業系統的原始碼，還包括我那台電腦上每一個軟體的原始碼。」代理程式除錯 macOS app 時，只能推理黑箱；同一個代理程式在 Linux 上，則能讀取當機二進位檔的原始碼。他把這點做成產品功能——Omarchy Quattro 有當機監看器，可從 systemd 記錄一路分析到出錯的原始碼行，讓代理程式診斷任何 app 當機，接著提交錯誤報告。
• **整台電腦都能用文字重現。**他對替代方案的抱怨很具體，並非出於意識形態：macOS 預設按鍵綁定和 Raycast 設定完全無法自動化——「你得像穴居人一樣用滑鼠點來點去。」

可推廣的論點是一條本文目前尚未提出的篩選規則：**環境的狀態越以文字表示、動作越能透過命令執行、內部越容易讀取，就越原生支援代理程式。**透過 GUI 設定、原始碼封閉、每台機器都得逐一點擊的環境，才需要改寫；那些從未為了人類操作便利而妥協的環境，早已準備就緒。這是否能預測採用情況——也就是他更強烈的主張，Linux 終於能因此進軍桌面市場——仍是預測，而他也在推銷這項預測。

他從這件事推導出的終點也值得放進本文：如果作業系統從頭到尾都以文字和命令為基礎，**作業系統本身就會成為你用 vibe coding 打造的對象。**Omarchy 隨附一組技能，教任何代理程式如何為桌面撰寫外掛，並在三天內產生 330 個社群外掛（Open Source Under Agent Contributions）。「既然你想到什麼 app 都能用 vibe coding 寫出來，你也應該能用 vibe coding 打造自己的作業系統。」

延伸閱讀#

• Andrej Karpathy — 對「寫給人類看的文件」的抱怨
• Software 3.0 — 複製貼上給代理程式的安裝方式，就是 3.0 的散布模式
• MCP and Computer Use — MCP = 結構化、可供代理程式理解；電腦操作 = 操控 GUI 的備援方案，適用於不支援代理程式的服務；兩者都是這個概念所要求的基礎
• Agent Harness Engineering — 在基礎設施層級打造代理程式可理解的環境，就是代理程式 harness 工程
• Agent Loop Pattern — 透過感測器／致動器持續運作並採取行動的代理程式，就是原生支援代理程式世界的執行環境
• Hermes Agent — 具體的原生代理程式 daemon（AGENTS.md context、gateway connectors），連接聊天介面與代理程式致動器
• AI Employee Framing — 「代表委託人的代理程式」會帶出把代理程式視為行動者時的責任歸屬問題
• Living Design System — design_system.html 是讓程式碼庫同時易於機器和人類理解的例子
• Claude Code — 消化複製貼上的技能並驅動電腦操作致動器的代理程式
• Agent Identity Management System (AIMS) — 為代理程式對代理程式的終點提供「信任、身分和問責原語」的具體提案：工作負載識別碼、委派授權，以及由既有標準組成的端對端稽核（請參閱下方未解問題）
• Open Source Under Agent Contributions — 代理程式可理解的平台如何改變自身的貢獻流程：技能隨產品提供、三天產生 330 個外掛，以及由代理程式分類處理成果
• DHH (David Heinemeier Hansson) — 主張桌面 Linux 意外成為原生支援代理程式的實務工作者，以及押注此觀點並發行相關 Linux 發行版的人

待解決的問題#

• 誰會打造適合代理程式的改寫版本，以涵蓋大量面向人類的服務——服務提供者本身，還是上層的轉譯層（MCP 伺服器、電腦操作代理程式）？
• 代理程式對代理程式的協商需要尚不存在的信任、身分和問責原語。協定層會是什麼？由誰治理？部分已有解答：AIMS（IETF draft-klrc-aiagent-auth-03）提出了協定層——代理程式對代理程式其實就是工作負載對工作負載，因此 WIMSE／SPIFFE 識別碼、OAuth 2.0 委派與權杖交換串接，以及 OpenID Shared-Signals 事件機制（取自 IETF/CNCF/OpenID）可提供身分、委派權限與可稽核的問責；工具端點「本身可能由另一個 AI 代理程式實作」。但由誰治理仍是開放問題：AIMS 是未經 IETF WG 共識的個人提案，描述的規格堆疊本身也仍是網際網路草案——這些原語只是提案，尚未核准或裁定。進一步釐清（2026-07）：「由誰治理」的答案明確是多方參與——身分／驗證／委派部分走 IETF 路線（AIMS），授權部分則走 OpenID Foundation 路線：其 AuthZEN Working Group 在 2026-06-15 核准 AARP（將 CIBA 概括化的先決條件／核准模式——「目前不行，以下是必要條件」）與 COAZ（MCP 工具授權）設定檔，作為 Working Group Drafts。因此，協定層正由多個機構共同標準化（IETF 負責「你是誰」＋「權限如何委派」；OpenID 負責「是否允許這項呼叫」＋「執行前必須滿足哪些條件」）——進展中，但尚無單一仲裁者，也尚未核准跨機構組合方式。（標準公告、practitioner-opinion——仍是提案草案，並非定案規格。）

資料來源#

• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501 — DHH、Lex Fridman #501（2026-08-26，practitioner-opinion，發行版供應商的利益衝突）：Linux 意外原生支援代理程式的論點——設定檔／CLI 介面、預訓練讓晦澀錯誤變得可理解、原始碼可取得、文字可重現機器狀態；當機監看器與外掛技能的實作

• Andrej Karpathy: From Vibe Coding to Agentic Engineering

• OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts — OpenID Foundation，…advances authorization for the agent era with new AuthZEN Working Group Drafts，2026 年 6 月 15 日，practitioner-opinion。證明代理程式對代理程式的授權協定層正逐步標準化（OpenID AuthZEN WG：AARP + COAZ Working Group Drafts），與 IETF 的身分／委派工作並行——補足上方未解問題中多方治理的部分