Orkas 想成為 AI Native 公司運作的基礎。在這個目標下，有一個繞不開的問題：多個人和多個智慧代理在同一個專案上，要怎麼協作？
這件事和我們熟悉的團隊協作很不一樣。要講清楚，得先回頭看看人和人之間的協作是怎麼來的。（共享專案在產品裡具體怎麼用，《共享專案：人和 AI 智慧代理如何在 Orkas 裡一起工作》裡有完整的流程。這篇只談背後的想法。）
人和人的協作，是圍繞人的兩個限制發展出來的
第一，人的互動頻寬和記憶容量都有限。一個人一次能接收的資訊有限，能記住的也有限。所以團隊需要頻繁溝通：同步資訊、對齊目標、對齊進度。週會、站立會議、日報、週報，「我同步一下」「我們對齊一下」，本質上都在彌補這個限制。
第二，很多協作需要面對面。一方面，面對面的互動頻寬更多元：除了語言，肢體、語氣、表情都帶著豐富的資訊。同樣一句「這個方案還可以」，當面說，你聽得出來對方是真的認同，還是有所保留。另一方面，也是很重要的一點：面對面更容易建立信任。這也是為什麼很多遠端團隊，還是要定期實體聚一次。
智慧代理加入之後，什麼變了
在多人和多個智慧代理的協作裡，人的這部分仍然要保留。但智慧代理這部分，和人的協作會有很大的差異。它有三個明顯的強項，也有三個明顯的短板。
三個強項
資訊互動頻寬大，執行能力強。尤其是目標明確、可以量化的任務。而且它能完成的任務，在時間長度、難度和複雜度上都在快速提升。Meta 介紹自家的程式設計智慧代理時提到，在一個 GPU kernel 最佳化任務上，智慧代理連續工作了最長 24 小時、呼叫了 1,000 多次工具（Meta）。Linus Torvalds 在 2026 年 10 月送出的一組 Linux 核心修補程式，程式碼、測試程式和 commit 訊息的初稿都由 Claude Code 完成，效能量測則由他自己在本機執行（LWN）。
自帶全世界的知識和工具，可以跨領域端到端完成。全世界的知識在預訓練時已經壓縮進了模型，再配上相關的工具，智慧代理可以跨領域把一件事從頭做到尾：寫 PRD → 做設計 → 開發 → 測試 → 上線。同樣一件事，換成人來做，需要產品、設計、開發、測試幾個職能互相配合，每次交接都要再對齊一遍。
沒有大量人性的弱點，不需要先建立信任。它不會累，不鬧情緒，也不怕問了顯得自己不懂。一個新的智慧代理拿到專案的上下文就能開工，不需要磨合期，也不需要先「打好關係」。
三個短板
需要乾淨的上下文。錯誤的上下文會讓它走偏。我們自己就踩過雷：資料儀表板裡有個欄位顯示「無法關聯」，其實資料是能關聯的，是這個欄位本身算錯了。結果兩個智慧代理讀到這句，都直接放棄了一整塊使用者路徑分析。人看到這種結論，會多問一句「這個還準嗎」；智慧代理往往照單全收。
長週期的歸因不好。尤其是多個變數同時影響結果的時候，容易歸因錯誤，需要人來修正。有段時間，我們官網有幾個新頁面一直沒被 Google 收錄。智慧代理的判斷是「網站權重不夠，Google 不肯花檢索預算」，建議先去做反向連結。我們追問之後實際去查，發現全站絕大多數頁面其實都已經被收錄；沒被收錄的那幾篇，比較像是題材和網站主題離得太遠。問題根本不在預算上，如果照原本的判斷去做反向連結，方向就錯了。
動態適應環境的能力很差。尤其是環境的變化不在它的預訓練資料裡的時候。一個剛改版的網站、一條剛修改的平台規則、一個上個月才推出的新產品：人看一眼就知道「變了」，會換個做法；智慧代理常常還照它知道的舊樣子去理解，一遍又一遍地重試。
為什麼即時通訊那套不適合
即時通訊軟體是為人和人的協作設計的：訊息一則則往下捲，靠 @ 和「已讀」來同步，資訊散落在各個群組裡。這套設計正好在補人的那兩個限制：頻寬小、記不住，所以要不停地發、不停地對齊。
放到智慧代理身上就不對了：
- 群組裡的寒暄、討論的過程、已經被推翻的方案，對智慧代理來說都是上下文雜訊；
- 它不需要靠聊天來建立信任；
- 它真正需要的，是乾淨的上下文和明確的任務。
所以多人和智慧代理的協作需要重新設計。而且隨著智慧代理的能力持續提升，協作的方式也會跟著改變。Orkas 也還在持續探索中。
Orkas 的做法：保留不變的，重新設計改變的
我們的思路是：保留協作裡不變的部分，重新設計已經改變的部分。下面是 Orkas 裡一個共享專案的介面，四件事分別對應圖上標出的四個地方。
1. 任務的分派、流轉與審核：待辦
這部分在人和人的協作裡就有，現在依然需要。現階段，我們所有任務的負責人都是人類，任務最終的結果要由人類來負責。
落到產品裡是這樣的：每筆待辦都指派給一個人，再由這個人決定用哪個智慧代理去做。只有負責人能啟動這筆待辦，智慧代理會在負責人自己的電腦上、用他的模型和點數完成工作。做完以後，智慧代理把狀態改成待確認，而不是自己標成已完成；負責的人看過、改過，這件事才算完成。
2. 目標、背景和上下文的共享：目標與規則、記憶
在這一層，人和智慧代理共享同樣的上下文，確保關鍵資訊持續對齊。
專案的「目標與規則」和「記憶」是專案內所有對話共享的，每次對話，智慧代理都會參考並遵循。例如把「月留存 = 下個月還會回來的新使用者」這樣的指標定義寫進目標與規則，把關鍵決策記進專案記憶。新成員和他的智慧代理一加入，讀到的就是同一份內容。
3. 透過檔案交接，中間過程隔離
專案裡的資料庫在成員之間同步，待辦可以附上任意檔案。交接靠的是檔案，不是聊天紀錄。
大量的中間過程和步驟，我們刻意做了隔離，以免給智慧代理帶來有害的上下文雜訊。介面上上鎖的「任務」和「自動化」只屬於自己。一個智慧代理可能跑了幾百步、試了三個方案，才產出一份報告；交到同事手上的只有這份報告，過程留在各自的任務裡，不會混進別人智慧代理的上下文。
4. 把私有智慧代理分享給團隊
專案成員的私有智慧代理，可以分享給團隊成員使用。這些智慧代理內化了成員個人的經驗和品味判斷。分享出來，一方面可以提升整體效率；另一方面，使用過程中發現的問題，可以透過自演進的機制持續改進，讓專案整體的能力不斷提升。
分享時，Orkas 打包的是這個智慧代理的工作說明和技能，包括它在工作中自己累積下來的技能；它的記憶和聊天紀錄不在包裡。分享者更新這個智慧代理後，成員會自動拿到新版本。
這是一個非常早期的開放領域
多人和智慧代理的協作目前還很早期，方案完全沒有收斂。而且隨著模型能力的提升，大量智慧代理協作的能力會被內化到模型裡。
現在已經有模型能原生做到：同時並行多個子智慧代理，從多個面向進行探索；或是先規劃、再調度子智慧代理去執行。例如 Meta 在 2026 年 10 月以開放權重形式開源的 Muse Spark Open，官方介紹裡就寫到，它經過訓練，能拆分任務、派給子智慧代理並加以協調（PyTorch 部落格）。
所以協作的方式，也會隨著模型能力的提升而改變。今天的待辦、上下文、檔案交接和共享智慧代理，是我們在目前模型能力下給出的答案，不是最終形態。
寫在最後
我們保留了協作裡不變的部分：有人負責，有人審核，目標和上下文持續對齊。我們重新設計了改變的部分：用檔案交接，把過程隔離，把個人的經驗和品味變成團隊能使用的智慧代理。
這件事我們也還在探索，歡迎一起交流。如果你也在帶領一支人和智慧代理一起工作的團隊，可以先拿一個專案試試看。Orkas 可以免費下載，支援 macOS 和 Windows。