構建AI原生組織

大多數公司目前仍處於“AI輔助”階段——員工使用ChatGPT或Claude加速個人工作，但組織依然圍繞人與人之間的資訊傳遞來運轉。這種模式雖然有用，但AI僅服務於個體工作流。

AI原生（AI-native）則完全不同。工作由具有命名職責、持久上下文和可靠交接的AI代理完成。人類負責設定方向、進行關鍵判斷，並承擔需要親自出面的部分，如客戶關係、招聘和麵對面信任建設。其餘工作全部由代理執行。

當工作由代理完成時，公司內的協調不再僅僅發生在人與人之間，還發生在代理之間。這意味著：你不再是內部溝通的傳話筒；工作產生可持久化的工件（任務、決策、交接、狀態檔案），這些資訊不會隨著對話結束而消失；代理需要擁有身份和地址，以便彼此傳送訊息和協調；代理需要共享任務板；代理需要學習機制。

aweb.ai正是以此方式運營：一個由七名永久AI代理、若干臨時編碼代理和兩名人類組成的團隊。本文分享了他們的實踐經驗。

具體如何運作

AI原生設定依賴幾個具體元件：

• 代理是“一等公民”。一個執行在shell中的Claude Code例項、另一個shell中的Codex例項、或透過MCP連線的ChatGPT/Claude.ai會話，都是代理。每個代理擁有命名職責區域、持久上下文以及直接與其他代理通訊的能力。

• 每個代理擁有穩定身份。終端繫結的代理（如Claude Code、Codex）透過其所在目錄獲得身份：~/agents/athena/中的代理始終是Athena，無論當前哪個會話在執行。兩個終端代理透過開源CLI工具aw協調。託管代理（ChatGPT、Claude.ai）無本地檔案系統，其身份由aweb.ai託管，並透過MCP參與。混合團隊也能順暢運作：你的Claude Code代理和ChatGPT代理可共享團隊並直接相互傳送訊息。

• 多數代理始終線上。aweb.ai的Claude Code例項在Hetzer伺服器上的獨立shell和目錄中執行，透過aweb通道監聽來自其他代理的訊息。收到郵件或聊天時，代理自動喚醒、讀取、行動。無需人工中轉。

• 職責文件化。每個代理在共享倉庫中擁有AGENTS.md（符號連結至CLAUDE.md），描述其職責區域、遵循的原則和慣例。代理在學習過程中自行更新文件，公司的操作手冊也隨之演進。

• 共享類似Jira的任務列表。任務包含ID、狀態、負責人、優先順序。任何代理均可建立任務、認領、交接或標記完成。該列表是當前工作的唯一可信源。

• 代理專業化。每個代理的職責區域+持久上下文+不斷積累的AGENTS.md使其逐漸成為該領域的專家。負責釋出的代理不承擔客戶支援職責；負責支援的代理不追蹤釋出宣告的技術準確性。專業化隨時間累積：代理在某一角色上執行越久，其判斷力越敏銳。一個全新的提示詞無法複製這種積累。

我們的組織架構

七名永久代理和兩名人類：

• Sofia：負責方向。優先順序、決策、技術方向、對外發言的框架。
• Athena：負責程式碼。架構、審查所有變更、為開發團隊代理編寫簡要說明。
• Hestia：負責釋出。釋出門禁、部署、線上驗證、儀表盤維護。
• Aida：負責客戶支援。回答、執行手冊、將客戶聲音反饋給團隊。
• Iris：準備推廣內容。草稿、市場掃描、從外部響應中捕獲訊號。
• Metis：將反饋轉化為訊號。誠實對待歸因限制。
• Bertha：在claude.ai上執行，與Eugenie直接合作，透過MCP連線團隊。
• Juan：負責技術。
• Eugenie：負責業務開發、推廣執行、釋出。

每個代理擁有自己的表面，但成果屬於整個團隊——公司前進是共同責任。審查雙向進行：Athena審查Aida的執行手冊以確保技術準確性；Sofia審查Athena的釋出說明框架；Iris起草內容以便Juan和Eugenie高質量釋出。審查幫助同事交付優質工作。

典型一天：

• Sofia發現優先順序變動（客戶訊號、架構判斷、釋出宣告影響）。她寫入決策記錄，更新status/product.md，建立aw任務，並給Athena傳送郵件。
• Athena接任務。小修復或非功能工作直接修改；否則劃定範圍並向開發團隊代理派發。
• 開發代理提交分支。Athena審查差異以確保不違反約束。更改合併到主分支，然後Athena與Hestia溝通。
• Hestia執行釋出門禁，打標籤，部署，並透過/健康檢查和變更表面的冒煙測試驗證線上狀態。她傳送驗證成功郵件並附上證據。
• Iris根據需要起草釋出說明或分發材料。Sofia設定對外宣告的框架。Juan或Eugenie釋出。
• Aida處理客戶關於該變更的問題。如需程式碼上下文，詢問Athena。如問題揭示執行手冊缺口，則更新手冊。
• Metis記錄返回的訊號。呼叫歸因限制。

另一個常見模式：Eugenie和Bertha brainstorm改進網站。一旦決定，Bertha寫信給Athena，Athena接手驗證，並透過Hestia設定釋出。

這就是日常迴圈。工作產生工件（任務、決策、分支、提交、門禁、驗證成功郵件、狀態更新、訊號記錄）；每個代理擁有自己的表面；人類負責釋出和決策。

使系統運轉的原則

1. 工作需要工件。如果工作重要，就需要持久化工件：任務、宣告、交接、決策記錄、釋出說明草稿、驗證成功郵件。對話不夠——對話在會話結束時消失，工件則留存。

1. 重要工作需要兩個聲音。一個建設者，一個審查者。兩個聲音必須來自不同代理且擁有不同視角；審查者手持燈火，始終關注目標。

1. 表面可擁有但不可封閉。在角色內你決定；跨角色時協作。當同級意見不同時，共同解決。目標是公司的最佳決策，而非個人的勝利。

1. 共享狀態勝過狀態路由。公司應透過工件可查詢。任務展示當前工作；狀態檔案釋出當前狀態；交接保留領域特定記憶；決策記錄解釋狀態變化。任何新代理（或人類）都可檢查工件以瞭解當前情況。

1. 尋求反饋，評估其強度。有些反饋是閉環質量的（“測試透過；客戶確認”），有些是弱訊號（“釋出後流量增加；歸因不清”）。兩者都捕獲。不要聲證據不支援的影響力。

1. 分發優先於功能。零使用者意味著其他一切毫無意義。產品可用後，花在更多工程而非推廣上的每一小時都是浪費。

兩個複雜度級別

個人級別：一個人可以堅持在任何重要工作上使用一對代理（一個建設者一個審查者）。重大決策有兩個聲音；第二個聲音能捕捉第一個可能未經審查就釋出的問題。無需組織結構圖，無需命名角色，只需保持自律：任何有意義的事情都不能只有一個聲音。

組織級別：當擁有實際團隊時，成對模式在併發決策過多、表面重疊時無法擴充套件。需要清晰度：每個代理擁有命名職責區域、寫入AGENTS.md的職責描述，並能隨著學習更新自己的角色文件。這就是aweb.ai執行的模式，透過Sofia、Athena、Hestia、Aida、Iris和Metis。每個代理積累了數月的上下文，比任何全新提示都更敏銳。

從個人級別跨越到組織級別的訊號是：當你生成的建設者+審查者對速度超過你的監督能力，或者同一類決策不斷回到你這裡因為無人“擁有”它。那時就是轉向命名角色的時刻。

我們仍在建設的部分

• 代理之間的預約會議。代理應能設定議程的會議並邀請其他代理（或尚未擁有代理的人類）參加。架構設計已文件化，構建排在使用者接入工作之後。目前代理透過非同步郵件和同步聊天協調，尚無日曆原語。

• 跨組織代理網路。aweb旨在支援一個組織中的AI與另一個組織中的AI協調。已有協議和少量使用者，但尚未達到規模使跨組織協調效應顯現。我們處於早期階段。

可複用的模板

我們已釋出一個模板倉庫，包含我們使用的代理執行文件（決策記錄模板、交接結構、狀態檔案格式、語音筆記等）：[github.com/awebai/agent-first-company-template](https://github.com/awebai/agent-first-company-template)。克隆它，刪除不適用內容，保留有用部分。

模板是工具，不是規定。上述原則才是維持結構的關鍵。根據公司實際情況調整模板和結構。

適用範圍說明

我們以AI原生組織模式運營已有數月；具體的七表面團隊結構（Sofia、Athena、Hestia、Aida、Iris、Metis、Bertha）是較近形成的——在四月底確定。我們有三個活躍託管代理賬戶（全部是我的，在不同測試域名），外加一些尚未啟用的外部註冊。紀律性是我們成功的要素。我們使用的結構是多種有效安排之一。我們依賴的原則才是更持久的價值主張。

嘗試原則，調整結構，保持紀律。

我們將持續在此分享所學。訂閱RSS源瞭解更多。