[Vibe coding : UX 實作] 從 AGENTS.md 到瀏覽器戰爭：定義 AI Agent「內涵」的協作憲章

From AGENTS.md to the Browser Wars: A Charter for AI Agent Character

前言：AGENTS.md 的「美麗陷阱」

最近，由 OpenAI 和 Google 共同推動的 AGENTS.md，在開發者社群中引起了極大的關注。它被譽為「給機器的 README」，旨在為 AI 程式設計 Agent 提供一套標準化的專案指令。表面上看，這似乎是解決 AI 工具碎片化問題的完美方案，一個我們期待已久的統一標準。

参考来源：

• http://agents.md/

• https://www.factory.ai/agents-md

• https://github.com/openai/agents.md

當 Devin、Copilot 等 AI Agent 成為程式開發者的「第二大腦」，一個不大不小的問題也隨之浮現：我們該如何與這些越來越聰明的「數位同事」高效溝通，確保他們不僅能完成任務，更能打造出以人為本的產品？

為了解決設定檔混亂的「巴別塔」問題，OpenAI 與 Google 等巨頭聯手推出了 AGENTS.md。表面上看，這似乎是我們期待已久的萬靈丹。

但我認為，它其實是一個「陷阱」。

它用一個看似簡單的標準，讓我們誤以為只要填個表單，就能解決 AI 開發的根本難題。開發者的第一反應可能是：「又來一個 .md 檔案？這真的能解決問題，還是只是另一個需要維護的負擔？」

我的觀點是：AGENTS.md 的價值完全不在於檔案本身，而在於它迫使我們去建立一套全新的、結合了 UX、敏捷開發和 Prompt Engineering 的工作流程。如果你只是把它當成另一個設定檔來寫，那它注定會失敗。

本文將深入探討，如何利用這個「陷阱」，將 AGENTS.md 從一份簡單的指令集，升級為定義 AI 核心「內涵」的協作章程。

---

為何 CONTRIBUING.md 不夠用？Agent 需要的是原則，不是步驟

我深入研究後發現社群最大的爭議點在於：既然 LLM 這麼強，為何不直接優化給人類看的 CONTRIBUTING.md？

答案藏在 AGENTS.md 的核心設計理念中：它提供了一套可執行的約束 (enforceable constraints)。它不只是一份靜態的說明書，而是一個動態的操作手冊，能將 AI Agent 固有的非確定性行為，嵌入到一個確定性、可預測的軟體開發流程中。例如，它會強制 AI 在提交程式碼前，必須完成 Linting、型別檢查和測試。

這實際上是將 AI 從一個單純的「程式碼生成器」，轉變為一個能理解並執行整個「開發工作流」的自主實體。也正因如此，一份給人類看的 CONTRIBUTING.md 遠遠不夠。

---

必然的分裂：平台戰爭的序幕

當我以為我們終於找到一條通往標準化的清晰路徑時，一個巨大的矛盾浮現了：如果 AGENTS.md 這麼好，為什麼各大巨頭——包括最初的參與者——都在推出自己的版本？

這不是標準化失敗的跡象。我認為，這是下一場平台戰爭的序幕。

---

表面：解決真實痛點，實質：構建護城河

不可否認，AGENTS.md 的出現，確實解決了開發者的真實痛點。在此之前，AI 開發工具的配置文件呈現極度碎片化的狀態：

• Cursor 使用 .cursorrules

• Claude Code 要求 CLAUDE.md

• Gemini CLI 需要 GEMINI.md

• 其他工具還有各種 .agentrc

這種混亂迫使開發者為每個 AI 工具維護不同的設定，創造了巨大的維護負擔。也因此，當 OpenAI 將 agents.md 域名收購並宣布為「廠商中立」標準時，社群反應熱烈——至今，GitHub 上已有超過 20,000 個開源專案採用了此格式。

然而，在這片罕見的產業「團結」景象之下，隱藏著更深層的策略考量。

---

深層：技術、商業與安全的三角制衡

巨頭們各自推出標準的根本原因，是在技術、商業和安全三個維度上進行的一場精妙的權力遊戲。

1. 技術的必然性：從單一指令到複雜協作

AGENTS.md 的簡潔性是其優點，也是其極限。它無法承載日益複雜的 AI 開發需求，這催生了各種「變體」：

• Google 的 GEMINI.md：為了解決大型專案 (monorepos) 中單一 AGENTS.md 過於臃腫、浪費 tokens 的問題，Google 設計了階層式的 GEMINI.md 結構，讓 Agent 能更精準地載入相關上下文。

• Anthropic 生態的 CLAUDE.md：在社群驅動下，CLAUDE.md 成為複雜「多代理協作」的實施指南，協調產品經理、UX 設計師、程式碼等多個 Agent 共同工作，這是單一 AGENTS.md 無法處理的。

更深層次地，這些變體是為了支援更底層的協議戰爭，如 Anthropic 的模型上下文協議 (MCP) 和 Google 的代理對代理協作協議 (A2A)，這些都需要專有的、更詳細的配置檔案來承載。

2. 商業的陽謀：標準化下的生態系戰爭

巨頭們的策略並非拋棄標準，而是在開放標準的基礎上尋求差異化，這是「佔領工作流」的陽謀。透過提供 GEMINI.md 的階層式上下文管理，或 CLAUDE.md 的多代理協作指南，他們讓開發者在其生態系內能實現更強大的功能。這大大提高了開發者的「轉換成本」，一旦習慣了特定工具的高級功能，就很難轉向其他平台，從而實現了生態系的鎖定。

3. 安全的底線：不可妥協的信任與控制

最後，也是最關鍵的，是安全。在企業級應用中，最小權限原則 (Principle of Least Privilege) 和 沙盒化 (Sandboxing) 是不可妥協的底線。如何為 Agent 配置 Docker 沙盒環境？如何管理動態的、即時的權限？這些高度依賴特定工具和平台的實施細節，無法用一份通用的 AGENTS.md 來定義。因此，專有文件成了確保信任與控制的必要載體。

所以，我們必須接受這個現實：分裂是必然的。這也讓如何寫好一份 agents.md 的「原則」，變得比爭論哪個「版本」更好，來得更加重要。這就帶我們回到了核心問題。

---

AI Agent 的「內涵」如何定義？一份給開發者的 AIPET 轉譯指南

這就引出了我思考的核心：一個好的 AI Agent 到底意味著什麼？它遠不止是高效執行任務這麼簡單，更需要交付優質的代理式使用者體驗 (Agentive UX)——使用者明確地將意圖 (intent) 授權給 AI，由 AI 作為使用者的代理人來完成目標。

但如何將「好的 UX」這個抽象概念，轉化為可執行的工程指令？我的方法是，將 AIPET 設計框架，轉譯成我們開發者都熟悉的軟體工程原則：