構建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源瞭解更多。