Agent 原生基礎設施

資料來源#

• Andrej Karpathy: From Vibe Coding to Agentic Engineering
• OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts

摘要#

Andrej Karpathy 觀察到，數位世界仍然是為人類打造，必須重新改寫成為 agents打造。他最在意的「惱人小事」是：文件仍以指示人類為目的。「為什麼人們還在告訴我該做什麼？我什麼都不想做。我該複製貼上什麼給我的 agent？」Agent 原生世界會把工作拆解為遍布世界的感測器與遍布世界的致動器，而且一切都要「優先描述給 agents」。最終，它會走向為人與組織提供 agent 表徵——「我的 agent 和你的 agent 對話，釐清我們會議的細節。」

複製貼上給 agent 的安裝方式#

具體的起點（與 Software 3.0 共通）是：安裝 OpenClaw 並不是執行 shell script，而是把一段文字貼給你的 agent，接著由它檢查環境，並在迴圈中進行除錯。將這件事一般化：agent 原生軟體的分發單位是 prompt／skill，而不是可執行檔。文件、設定與設定流程都應該以「這是你交給 agent 的內容」來提供，而不是「這些是你要執行的步驟」。

感測器與致動器#

Karpathy 以機器人的術語重新詮釋 agent 基礎設施：把任何工作負載拆成感測器（agent 能讀取、易於理解的輸入）與致動器（agent 能採取的行動），然後讓這些介面對 agent 而言清晰可讀。他也主張大力投資於「對 LLM 而言非常易讀的資料結構」。設計問題從*「人類需要什麼 UI？」轉變為「agent 能感知什麼，又能對哪些東西採取行動？」*

部署摩擦的訊號#

他用 MenuGen 測試基礎設施是否已經 agent 原生化：困難的不是程式碼——而是部署到 Vercel（DNS、服務設定、選單、把服務串接起來，「真的很煩」）。理想情境是：「給 LLM 一個 prompt，建立 MenuGen，而我完全不必碰任何東西——它就部署在網際網路上。」當這個往返流程完全不需要人類點擊 GUI，基礎設施就已經成為 agent 原生。（連結至 MCP 與 Computer Use：MCP 讓服務能以程式方式對 agent 清晰可讀；computer use 則是在服務不具備這種能力時的後備方案。）

終點：代表委託人的 agents#

再往外推，就是讓 agent 代表人與組織，透過 agent 對 agent 完成排程、談判與協調。「我會讓我的 agent 和你的 agent 對話，釐清我們會議的細節。」這是 agent 原生世界的社交協定層，也是 AI Employee Framing／Human-AI Accountability Redesign 所提出問題的實際運作介面（誰要為 agent 的承諾負責？）。

相關連結#

• Andrej Karpathy——「為人類撰寫文件」這件惱人的小事
• Software 3.0——複製貼上給 agent 的安裝方式，就是 3.0 的分發模型
• MCP 與 Computer Use——MCP＝結構化的 agent 可讀性；computer use＝為非 agent 原生服務提供的 GUI 操作後備方案；兩者都是這個概念所要求的基礎
• Agent Harness Engineering——在基礎設施層打造 agent 可讀環境，就是 harness engineering 這門學科的實踐
• Agent Loop Pattern——透過感測器／致動器行動的常駐 agents，是 agent 原生世界的執行時期
• Hermes Agent——具體的 agent 原生 daemon（AGENTS.md context、gateway connectors），將聊天介面橋接到 agent 致動器
• AI Employee Framing——「代表委託人的 agents」引發了把 agents 視為行動者時的問責問題
• Living Design System——design_system.html 是同時讓程式碼庫具備機器可讀性與人類可讀性的例子
• Claude Code——消費複製貼上 skills，並驅動 computer-use 致動器的 agent
• Agent Identity Management System (AIMS)——這是 agent 對 agent 終點所需「信任、身分與問責基元」的具體提案：工作負載識別碼、委派授權，以及由既有標準組成的端到端稽核（見下方開放問題）

開放問題#

• 誰來打造長尾人類服務的 agent 原生改寫版——服務擁有者，還是上層的轉譯層（MCP servers、computer-use agents）？
• Agent 對 agent 的談判需要目前尚不存在的信任、身分與問責基元。協定層會是什麼，又由誰治理？部分已有答案：AIMS（IETF draft-klrc-aiagent-auth-03）提出了協定層——agent 對 agent 其實就是工作負載對工作負載，因此 WIMSE／SPIFFE 識別碼、OAuth 2.0 委派＋token-exchange chaining，以及 OpenID Shared-Signals eventing（取自 IETF／CNCF／OpenID）提供身分、委派權限與可稽核的問責；工具端點「本身可能由另一個 AI agent 實作」。但誰來治理仍然是開放問題：AIMS 是沒有 IETF WG 共識的個人提交，它所描述的一整套 specs 本身也仍是 Internet-Drafts——這些基元是提案，尚未獲批准或仲裁。進一步釐清（2026-07）：「誰來治理」的答案具體而言是多元的——身分／驗證／委派部分採 IETF 路線（AIMS），而授權部分採 OpenID Foundation 路線：其 AuthZEN Working Group 於 2026-06-15 核准 AARP（將 CIBA 一般化的前置條件／核准模式——「現在還不行，以下是必要條件」）與 COAZ（MCP 工具授權）設定檔，成為 Working Group Drafts。因此，協定層正由多個組織共同標準化（IETF 負責「你是誰」＋「權限如何委派」；OpenID 負責「是否允許呼叫」＋「之前必須完成什麼」）——持續推進中，但尚無單一仲裁者，也尚未有獲批准的跨組織組合。（標準公告、practitioner-opinion——這些是提議中的草案，並非已定案的規格。）

資料來源#

• 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。這證明 agent 對 agent 的授權協定層正被標準化（OpenID AuthZEN WG：AARP＋COAZ Working Group Drafts），並與 IETF 的身分／委派工作並行，印證上述開放問題中關於治理多元性的部分