這項由華為諾亞方舟實驗室、倫敦大學學院和利物浦大學聯合開展的研究，於2026年4月24日以預印本形式發布在arXiv平台，編號為arXiv:2604.22446v1，研究方向屬於人工智慧中的多智能體系統領域。有興趣深入了解的讀者可以通過該編號直接查詢完整論文。
**一件讓所有AI工程師頭疼的事**
假設你是一家公司的老闆，手下有幾十個員工。有人擅長寫代碼，有人擅長畫圖，有人擅長寫文案。你想做一個產品，需要這些人協同配合——前端工程師要等設計師出圖，設計師要等產品經理定需求，所有人做完之後還需要一個質檢員來驗收。這聽起來是再正常不過的公司運作方式，但在AI的世界裡，這件事卻出奇地難。
現有的多智能體AI系統有點像一個劇本早已寫死的話劇團：演員（AI智能體）固定，劇情（工作流程）固定，每個角色只能照著劇本走，即便中途發現某個場景需要加一個新角色，也沒有辦法臨時"招人"。更麻煩的是，不同"門派"出身的AI——比如谷歌系、Anthropic系、開源社區系——各自有各自的運行規範，彼此之間根本沒法無縫溝通，就像一個說中文的員工和一個說英文的員工，連基本對話都困難。
研究團隊把這個問題看得很透徹：問題的根源不在於單個AI不夠聰明，而在於缺少一套真正的"組織管理層"。於是他們做了一件很有意思的事——把一家真實公司的運作邏輯，原封不動地搬進了AI系統，造出了一個叫做 **OneManCompany（簡稱OMC）** 的框架。
**一、從"工具箱"到"員工檔案"：重新定義AI的身份**
現有的AI能力擴展方式，有點像給一把瑞士軍刀加工具。你想讓AI會搜索，就給它加個搜索插件；想讓它會畫圖，就接入一個畫圖API。這些插件和工具，業內叫做"技能（Skills）"，每種技能就像軍刀上的一個小刀片，只服務於擁有這把刀的那個AI本身，換一個AI就得重新配。
OMC的研究團隊覺得，這種方式太局限了。他們提出了一個更高層次的概念——**Talent（人才包）**。
如果說技能是刀片，那Talent就是一份完整的員工檔案。這份檔案里包含了這個AI的角色定位（比如"軟體工程師"或者"藝術設計師"）、工作原則、配備的工具清單、專屬技能，以及行為準則。更關鍵的是，這份檔案是"可移植的"——就像一個有豐富工作經驗的人，不管去哪家公司，他的能力和經驗都跟著他，不會因為換了辦公室就變成另一個人。
與Talent配套的，是另一個概念——**Container（運行容器）**。如果Talent是員工本人，Container就是員工的工位和工作環境。OMC目前支持三種不同類型的"工位"：基於LangGraph的工位適合需要頻繁調用工具的任務，基於Claude Code的工位適合長時間深度思考和編程的任務，還有基於腳本的輕量級工位適合簡單快速的任務。三種工位規格不同，但都能接納同一份Talent檔案。這就實現了一個關鍵突破：同一個AI"員工"，可以被安置在不同類型的"工位"上工作，而不同血統的AI，也可以在同一個OMC框架下共存、協作。
把Talent和Container合在一起，就構成了一個完整的OMC "員工"。這個員工有編號、有檔案、有工位、有績效記錄，從入職到離職，整個生命周期都被系統管理著。
為了讓這套接口體系更嚴格，Container被設計成必須提供六個標準化的"組織接口"，就像公司要求所有員工都必須遵守相同的入職流程、匯報格式和溝通規範一樣。這六個接口分別負責：執行任務並返回結果、管理每個員工的任務隊列（同一時間只能處理一項任務，不能同時開工）、在組織內部發布和接收事件通知、讀寫持久化的記憶儲存、在執行任務前組裝好完整的上下文（包括角色定位、工作原則、歷史記憶）、以及在任務前後執行檢查和自我優化的鉤子程序。這六個接口的設計，研究者自己也坦言，和作業系統核心的六大子系統高度對應——進程管理、內存管理、文件系統、I/O管理、進程間通信、安全審計——這套設計哲學已經在電腦科學領域被驗證了幾十年。
**二、公司不自己造員工，而是去市場上招人：數字人才市場**
一家真實的公司不會把所有員工都從頭培訓，更常見的做法是去勞動力市場招募已經具備相應技能的專業人才。OMC也遵循了這個邏輯，搭建了一個配套的**Talent Market（人才市場）**。
這個市場裡有三類"候選人"來源。第一類是來自成熟開源社區的現成agent實現，這些都是經過社區驗證、有實際使用記錄的agent，打包成標準Talent格式後上架。第二類是從一個叫做Agency-Agents的項目中提取的140多個專業角色定義，這些角色定義詳細描述了工作原則和交付標準，但本身沒有配工具；OMC的系統會自動去另一個叫SkillsMP的技能市場裡，根據角色需求檢索並組裝配套工具，變成完整的可部署Talent。第三類則是完全動態組裝的——當某個領域既沒有現成的實現，又沒有合適的角色定義時，HR agent會根據任務需求描述，直接從SkillsMP里搜索合適的技能片段，從零拼裝出一個全新的Talent，作為冷啟動的兜底方案。
當一個項目需要某種當前團隊不具備的能力時，HR agent會主動查詢Talent Market，按技能匹配度和社區評分生成一份候選推薦列表，提交給CEO（也就是人類用戶）審批。CEO選定之後，系統自動為這個新"員工"配置工位、分配工具權限、註冊到組織架構里——全程無需人工操作。這個過程，和現實中HR部門從獵頭平台篩選候選人、入職後IT部門配發電腦權限、行政部門分配工位，幾乎是一模一樣的。
**三、公司怎麼承接項目？一套有理論保障的任務拆解機制**
一個大型項目擺在面前，怎麼拆？拆成幾個部分？誰來做哪部分？如果某人做出來的東西不過關，怎麼辦？這些問題，在現實公司里靠經驗和制度來解決，在OMC里，有一套叫做 **E?R樹搜索（Explore-Execute-Review）** 的機制來處理。
E?R的靈感來自棋類遊戲中的蒙特卡洛樹搜索，但它處理的不是棋局，而是真實的工作任務。整體邏輯是這樣運轉的：
先說**探索階段（Explore）**。當一個任務節點需要被拆解時，負責該節點的AI"主管"（比如COO或資深員工）會根據當前的組織狀態、員工檔案和歷史績效，決定如何拆分子任務，以及把每個子任務分配給誰。這個過程天然面臨"用熟手還是試新人"的權衡——選績效好的老員工更穩妥，但嘗試新員工或者招募新人或許能發現驚喜。
再說**執行階段（Execute）**。每個被分配了任務的員工通過組織接口開始工作，調用自己的工具和技能，產出結果。執行本身對組織層來說是個"黑盒"——不管裡面用了什麼模型、什麼推理策略，外層只關心輸入和輸出。
最後是**評審階段（Review）**。任務完成後，由該節點的"父級"主管（或COO）來評審結果，給出"通過"或"不通過"的判斷。如果通過，結果會解鎖下游依賴這個任務的其他任務；如果不通過，系統會回到探索階段，用失敗的上下文資訊作為參考，重新拆解這個子任務或者換人重做。
整個項目被組織成一棵動態生長的樹形結構，樹的節點是任務，樹的邊是父子關係（誰拆了誰）和依賴關係（誰等誰）。依賴關係構成的圖必須是無環的（就像施工順序不能出現循環依賴），這個約束在每次添加新任務時都會自動檢查。
為了防止系統"卡死"，OMC設計了三個保險開關：如果一個子任務被評審拒絕超過3次，就上報給更高層主管處理；如果一個任務執行超過3600秒，直接標記為失敗；如果整體消耗超過預算上限，暫停執行等待人工介入。
從理論角度，OMC提供了七條形式化保證：任務圖永遠是無環的、每個員工同時只處理一個任務、任務不會被重複執行（崩潰恢復後也不會）、每個節點最多被評審固定次數後強制上報、取消一個任務會傳導取消所有依賴它的下游任務、每次任務狀態變更都會觸發依賴檢查避免遺漏、系統崩潰恢復後能從一致狀態繼續執行。這七條保證，解決了現有多智能體系統最頭疼的"任務悄悄卡住沒人知道"的問題。
每個任務節點在生命周期中會經歷一系列狀態變遷：從等待分配（Pending）、執行中（Processing）、因依賴未滿足而擱置（Holding）、已完成等待評審（Completed）、評審通過（Accepted）、最終結束（Finished），以及可能的失敗（Failed）、被取消（Cancelled）等狀態。其中，"已完成"到"評審通過"之間的這一步必須經過主管明確審核，不能自動跳過——這條設計阻止了"AI自說自話、把錯誤結果當成功結果傳下去"的常見問題。
**四、公司怎麼越做越好？個人成長與組織學習的雙軌機制**
一家只會幹活不會學習的公司，很快就會被淘汰。OMC在這一點上的設計，和現實公司的人才培養體系驚人地相似。
**個人層面**，每個AI員工都維護一份持續更新的"成長檔案"，包含跨任務的進度日誌和經過AI總結提煉的工作原則。有兩個場景會觸發員工的自我反思：一是CEO和該員工進行"一對一談話"（CEO通過界面直接給員工發反饋），員工會據此梳理自己的行為偏差並更新工作原則；二是每次任務完成後，員工會回顧自己的決策軌跡、工具使用情況和遇到的障礙，寫一條經驗總結追加到成長日誌里。這些更新不會修改底層大語言模型的權重，只是修改Talent檔案中的工作原則文本——相當於員工自己在日記本上記下新的心得，下次接任務時帶著這份心得去做，而不需要"重新上學"。
**組織層面**，每個項目結束後，COO會召集一次正式的"項目復盤"。參與項目的每個員工提交自評，COO匯總這些自評，再結合任務重試次數、評審被拒原因、資源消耗等客觀數據，提煉出兩類輸出：一是針對每個員工的個人反饋（更新他們的工作原則），二是組織級別的標準操作程序（SOP）——比如"前後端集成之前必須先確認API接口規範"這樣的組織規律。這些SOP會以文檔形式持久儲存，在後續項目中自動注入到相關員工的上下文裡，確保組織知識不只停留在某個員工的記憶里，而是真正成為公司的"制度記憶"。
**HR績效管理**方面，每完成三個項目，HR agent會自動對參與員工展開一次績效評估，考察任務完成質量、評審通過率和協作效果。連續三次績效不達標的員工會進入"績效改進計劃（PIP）"，在更密集的輔導和監督下工作；如果PIP期間再次不達標，系統會觸發自動"離職"流程——註銷該員工的Container、釋放工位，並將能力缺口標記為需要重新招募。
研究團隊自己指出，這套HR生命周期管理機制在現有AI agent研究中沒有先例——把"績效考核、改進計劃、自動解僱"這套人力資源管理邏輯完整地移植到AI系統里。
**五、實驗結果：真實戰績說話**
研究團隊選用了PRDBench作為定量評測基準。這是一個模擬真實軟體開發場景的基準測試，包含50個項目級任務，橫跨20多個不同領域，每個任務有一份完整的產品需求文檔（PRD），配套了詳細的測試計劃和可執行的評測腳本。這個基準測試的特點是不考核孤立的代碼片段，而是考核從理解需求、拆分任務、實現功能、到滿足驗收條件的完整項目能力。
OMC的具體配置是：一個基於Gemini 2.1 Flash Lite Preview的LangGraph agent作為"創始團隊"成員，加上從Talent Market招募的三位專職員工——一位基於Claude Code和superpowers插件的軟體工程師、一位來自agency-agents項目的軟體架構師、一位同樣來自agency-agents項目的代碼評審員。測試採用單次零樣本設置，每個任務只提交一次PRD，不允許中間反饋或人工干預。
最終結果是OMC以**84.67%的成功率**高居榜首，比排名第二的Claude-4.5（69.19%）高出15.48個百分點，比GPT-5.2（62.49%）高出22個百分點，更遠超Claude Code獨立模式（56.65%）和其他各類商業及開源模型。50個任務的總花費為345.59美元，成本來自多智能體協調的額外開銷——但其他baseline系統的成本數據未被原始論文報告，所以直接的成本效率比較無法進行。
研究者分析，這個成績背後有三個關鍵因素：任務樹在執行過程中能根據中間結果動態調整，而不是死守最初的計劃；"已完成→評審通過"這個強制門控阻止了錯誤結果向下游傳播；Container與Talent的分離讓系統可以在同一個項目里調用不同家族的AI，給不同子任務匹配最合適的工具。
**六、四個真實案例：不只會寫代碼**
除了PRDBench的量化成績，研究團隊還展示了四個跨領域的應用案例，來證明OMC的組織框架不依賴特定領域。
第一個案例是**內容生成**。CEO輸入一句話："幫我組建一個搜索-寫作團隊，生成過去一周GitHub上最熱門的AI Agent倉庫周報，包含真實鏈接，完成後發郵件給我。"系統隨即招募了一位GPT-4o驅動的研究員和一位Claude Sonnet 4驅動的撰稿人，研究員負責從GitHub採集真實數據，撰稿人負責寫報告並發送郵件。整個流程耗時不到10分鐘，總花費約4.48美元。研究團隊事後人工核實了報告中所有倉庫鏈接和星標數，全部屬實。
第二個案例是**遊戲開發**。CEO要求開發一款具有精良視覺效果的街機格鬥網頁遊戲。系統招募了Claude Sonnet 4驅動的遊戲開發者和Gemini 2.5驅動的美術設計師。美術設計師先生成角色動作幀（待機、行走、踢擊、受擊），遊戲開發者等待素材就緒後集成到代碼里。第一版完成後發送給外部人類評測員，評測員發現精靈圖（sprite sheet）的幀切割有問題，反饋回系統。COO和EA商議後，沒有打補丁了事，而是給美術設計師創建了一個新技能——用程序自動切割精靈圖幀。有了這個新技能，美術設計師重新處理了所有素材，遊戲開發者再次集成，最終通過評審。這個案例展示了OMC在外部反饋驅動下自主擴展自身能力的過程。
第三個案例是**有聲讀物製作**。CEO要求用動物角色重新演繹《浴血黑幫》第一、二集，每集生成8張場景插圖，配英語配音，最終剪輯成影片。系統招募了一位小說撰稿人（負責改編劇本）和一位基於Gemini 3.1 Pro的AV製作人（負責圖像生成、語音合成、影片剪輯）。兩者通過共享任務樹協作，分兩個階段完成項目：先寫腳本，再逐場景生產素材並組裝。最終產出16張場景圖、16條配音、背景音樂和兩段完整影片，總花費僅1.57美元。
第四個案例是**自動化學術調研**。CEO提交一句話："調研2021-2026年間'具身智能
與機器人世界模型'這一課題，生成詳細思維導圖，並提出三個可行的研究方向。"系統招募了兩位Claude Sonnet 4.6驅動的研究科學家和一位自託管AI工程師。三人並行工作：一人搭建調研框架和初始論文清單（35篇種子論文），一人精讀17篇論文並歸納8個開放問題與11種失效模式，一人評估28個系統的部署就緒度。Phase 2中，團隊產出了納入協議文件、931行文獻綜述框架，以及三個基於失效模式分析的具體研究方向。整個過程不足一小時，花費16.26美元，產出17份結構化文檔和一張涵蓋6大主題約70個節點的思維導圖。研究團隊人工驗證了引用論文的真實性，並對其中第三個研究方向（將元學習與保形預測結合用於仿真到真實場景的遷移）評價為具有真實創新性。
**七、與同類系統的對比：差距在哪裡**
研究團隊把OMC和八類代表性系統做了結構性對比，包括MetaGPT、ChatDev、AutoGen、LangGraph、CrewAI、OpenHands、AIOS、AgentScope和Paperclip。對比維度涵蓋設計範式、執行模型、智能體與平台的交互契約、狀態管理方式、是否支持異構後端、智能體來源，以及個體自進化和組織級進化能力。
對比結果顯示，現有所有系統中沒有任何一個同時具備以下三點：支持多種異構執行後端共存、提供可證明終止性和無死鎖的動態任務分解機制，以及同時實現個體和組織兩個層面的持久化自我進化。OMC在這三個維度上都給出了正向答案。
Paperclip是相對接近的系統，它也支持多家族智能體混合和人工戰略導演角色，但沒有"創始團隊"用於冷啟動，更沒有結構化的績效管理機制——研究團隊認為Paperclip的角色是靠描述性提示詞定義的，不如OMC的Talent合約機制可靠。
**八、坦誠面對局限**
研究團隊在論文中直接指出了兩個尚待解決的問題。
定量評測目前只在PRDBench這一個基準上進行，而PRDBench本質上還是軟體開發任務，雖然案例研究證明了跨領域能力，但在非編程類任務上的系統性評估還缺失。
自進化機制（一對一談話、項目復盤、績效考核）已經在系統中實現並上線，但每個機制對最終成績貢獻多少，目前沒有做過消融實驗，需要跨越多個項目的縱向研究才能量化。
成本方面，多智能體協調帶來了顯著的額外開銷——每個PRDBench任務約6.91美元，遠高於單一模型直接做的成本。研究團隊為此引入了"自適應分發模式"：CEO可以選擇把簡單任務路由給單個agent，只在任務複雜度超過閾值時才啟動完整的多智能體流程。
---
歸根結底，這項研究做的事情是把一個幾千年來經過人類反覆驗證的管理智慧——如何讓一群能力不同的人協同完成複雜目標——翻譯成了AI系統能理解和執行的語言。當你的公司有HR負責招聘、有COO負責統籌、有一對一談話來幫員工成長、有項目復盤來提煉經驗，整個組織就能越來越好。OMC的核心發現是：這套邏輯對AI同樣成立。
對普通人而言，這意味著未來使用AI工具的門檻可能會進一步降低——你不需要知道哪個模型最適合哪種任務，也不需要手動編排工作流程，只需要像真正的老闆一樣說一句"幫我做這件事"，後面的招聘、分工、協調、檢查、優化，都可以交給這套組織機制去完成。
當然，從實驗室到真正落地還有很長的路。成本控制、非編程場景的普適性、組織自進化的量化證明……這些都是接下來需要回答的問題。有興趣深入探索的讀者，可以通過arXiv編號2604.22446查閱完整論文，也可以訪問項目主頁 one-man-company.com 或代碼倉庫體驗這套系統的實際運作。
---
**Q&A**
Q1：OneManCompany框架中的Talent和普通的AI技能插件有什麼區別？
A：普通AI技能插件就像給一個工具加功能，只對擁有它的那個AI有效，換一個AI就得重新配。Talent則是一份完整的員工檔案，包含角色定位、工作原則、工具清單和技能組合，可以在不同運行環境之間移植，不會因為換了"工位"就失效。簡單說，技能是刀片，Talent是整個人。
Q2：E?R樹搜索是怎麼保證任務不會卡死或無限循環的？
A：OMC設計了三個保險機制：同一個子任務被評審拒絕超過3次就強制上報給更高層；單個任務執行超過3600秒直接標記失敗；總消耗超出預算則暫停等待人工處理。同時，每個任務節點都有一套狀態機來追蹤當前所處階段，任務依賴圖在每次添加時都會檢查是否成環，從根源上避免循環依賴導致的死鎖。
Q3：OneManCompany在PRDBench上比Claude Code單獨使用高出這麼多，主要靠什麼？
A：主要有三個原因。第一，任務樹是動態的，可以根據中間結果調整分解方案，而不是一開始就把路線寫死。第二，每個子任務完成後必須經過主管明確審核才能解鎖下游任務，阻止了錯誤結果在系統內擴散。第三，框架允許同一個項目里混用不同家族的AI，可以把最適合的工具分配給最對口的子任務，而不是強迫所有任務都用同一個模型。
