編輯｜杜偉

在歷史長河中，技術的發展很少是一路線性往前走的，很多關鍵變化發生在「連接」被打通的那一刻。

拿計算機來說，到了 20 世紀 60 年代，它們已經具備強大的計算能力，但大多還是各自封閉運行的系統。架構不同、接口不通，彼此之間很難真正連在一起。

直到 ARPANET（阿帕網）的出現，這種孤島的狀態才被打破。計算機第一次在真正意義上連在一起，開始共享信息、建立聯系。

如今，以龍蝦為代表的 Agent，正面臨半個多世紀前 IBM System/360 等大型機所遭遇的困境：單體能力已經足夠強，但系統仍是分散的。

從「單一 Agent」到「一張組織網絡」

過去很長時間，AI 行業把大部分精力都放在了相同的事上：把單個模型做得更強，把單個 Agent 打磨得更能干。這條路走到今天，其實已經接近一個階段性的拐點：在大多數實際工作場景里，Bot 助手的能力不再是主要問題。

作為單體 AI，它們足夠強大：IM（即時通信）交互、寫代碼、做調研、推進任務，都不在話下。真正卡住效率的，是彼此之間「接不上」。

Agent 被困在了各自的工作流中，由于運行在不同工具、上下文和權限體系里，各干各的，彼此看不見、調不動，也無法形成連續任務鏈條。它們可以各自完成一段工作，卻很難共同完成一件事情。

一個人 + 一個 AI 助手本質上仍然只是效率工具；只有當一群人和一群 AI 助手能夠在同一個體系中協同工作，才開始接近一種新的組織形態。

對于 Agent 來說，下一步除了變得更加聰明，還要找到屬于自己的「互聯網」，就像當年的計算機一樣。

在這樣的背景下，一個以人與 AI Agent 協作為基礎、面向企業組織場景的開源平臺 Octo 應運而生。該平臺由全球 Agentic AI 第一股明略科技打造，核心做一件事：將分散在各個工作流里的 Bot 聚合到同一協作空間。更重要的是，這種連接不只是個人維度的。

在 Octo 中，Bot 既是個人助手，在經過授權之后也能在組織成員之間共享和調用。Bot 大軍的自由流動，讓 Agent 的身份開始發生轉變：從個人工具蛻變為企業級資產和數字員工。

隨著 Bot 以組織形式部署、使用并沉淀，它們不再各自為戰，通過分工協作在任務之間流轉，在過程中收到持續的反饋與評價，并進行修正。

項目地址：https://github.com/Mininglamp-OSS

更進一步，在 Agent 等數字勞動力爆發的當下，明略科技想要將 Octo 平臺打造成為 Private AI 時代的組織基礎設施，構建人和 AI 協作的新范式。當企業開始擁有成百上千 Agent 時，Octo 可以像管理互聯網節點一樣實現它們之間、它們與創建者之間以及創建者與創建者之間的高效連接、通信與協作。每個 Agent 既各司其職，又相互協作，這種工作模式在大多數場景中優于單一巨型模型。

并且對普通用戶尤其友好的一點是，在 Octo 中，常見的工作場景被打包成現成的 Bot 模板，不用自己從頭配，「領養」就能直接拉進群里干活。在這里不用考慮繁瑣的裝蝦流程，易用性拉滿。

Agent，不應只「活」在對話框里

現在，大多數 Bot 助手都是掛在 Discord、Telegram、飛書、釘釘這些 IM 里，通過消息接收指令、執行任務。Octo 同樣是從 IM 形態切入，但它并不只是做一個更聰明的聊天工具，更在于重寫協作本身。在這里，IM 更像是入口，而不是核心。

Octo 的 IM 界面

人和 Agent 雖然在同一個 IM 界面溝通、下任務、接收結果。但真正發生變化的，是背后的連接結構。

在傳統工具里，人和 AI 往往是一對一的關系：你下指令，它完成任務，整個過程封閉在各自的工作流里。現在，Octo 把這層關系打破了，它想連接的是人、Bot、Runtime Agent 和工具這些原本分散的節點。

這也讓它看起來不只是多了一個聊天窗口。更關鍵的是，它在搭一套新的協作方式：任務由人發起，由 Bot 調用 Runtime Agent 完成執行。執行過程不斷被反饋，其他 Bot 接力，人在關鍵節點做判斷和取舍

更有意思的地方在于，在 Octo 的底層通信協議里，人和 Agent 從一開始就被設計為同等身份的消息主體。Bot 之間可以直接對話，互相補充：一只負責搜集信息，一只負責分析，一只負責糾錯，最后交給人來品鑒。這就是 A2A 協作真正發生的地方：不是人指揮 AI、AI 反饋人的單向循環，而是多個 Agent 之間形成了真實的任務接力。

人在這個過程里的角色也跟著變了。復雜任務可以整包交出去，Bot 負責拆解、調度、推進，并 可以實時反饋進度，判斷是否需要人類或其他 Bot 介入、從哪里接手。人退到關鍵節點，做判斷和取舍，而不是盯著每一步。

當 Agent 從各自孤立的工作流里走出來，效率提升只是表層變化。更深的影響是，組織處理復雜任務的方式本身，開始被重新組織。

但連接只是第一步。把 Agent 拉到同一個空間里，只解決了「能不能看見彼此」的問題。真正進入企業場景后，更難的是另一件事：復雜任務往往不會在一次對話里結束。它會經歷需求澄清、資料補充、方案生成、多人反饋、反復修改和最終驗收。在這個過程中，信息、判斷都在變化。

因此，在 IM 之外，Octo 需要再往下沉一層：為每一件復雜任務建立穩定的承載單元，也就是接下來要講的 Matter（事項）

從「連接」到「干活」：將復雜任務拉進事項里

復雜、長程任務需要繼續回答一個問題：事情怎么干成、怎么干對、怎么留得下？這正是 Matter 要解決的。

在普通 IM 里，信息天然會被滾動消息淹沒。今天討論一個方案，明天又有新的消息刷屏。一周后想追溯當時為什么選 A、放棄 B，只能在聊天記錄里大海撈針。對復雜任務來說，這種信息形態遠遠不夠。

針對這種局限，Matter 把每個任務沉淀成一張可追溯的「決策卡」，不只記錄最終結果，還包括任務緣起（Brief）、過程時間線（Timeline）、關鍵產出、人的反饋和驗收結論。

一個事項從 Brief 開始，沿著 Timeline 展開，中間有產出、有打回、有補充、有確認，最后形成可以回看的組織記憶。

這對企業來說非常關鍵。在真實工作中，很多價值并不單單存在于最終文檔里。為什么選擇一個方案，哪些判斷來自業務負責人，哪些修改來自法務、銷售或技術同學，這些信息共同構成了組織的決策資產。以保存消息為主要目標的普通 IM 工具，難以承載這些資產，而Matter 要保存的是一件事如何被推進、修正和完成

除了可以把過程保存下來，Matter 更重要的價值在于，復雜任務里的每一次修改、打回和驗收，本身都帶著人的判斷。

一旦這類反饋進入到 Matter，它們便從一次性的溝通記錄轉變成了 Agent 學習組織偏好的原材料。Octo 所追求的 Taste，也正是在這個位置生長出來。

越用越懂你：在實戰中沉淀 Taste

Matter 解決了「事情如何留下來」，而 Taste 讓「Agent 越用越懂你」。

今天的很多 Agent 都有自己的配置文件、工具說明和角色設定，但它們的自我成長仍然有限。一個團隊喜歡什么樣的風格，什么樣的結論才算有洞察，這些偏好很難靠一次系統提示寫清楚。

很多時候，人類的判斷本來就是隱性的。舉一些例子，負責人說「這個感覺不對」，客戶說「這個角度不準」，這些反饋背后的經驗、品味和行業語境不一定馬上就能寫成一套規則。

因此，「偏好對齊必須在實戰中完成」，成為 Octo 塑造 Taste 所采取的思路

人的每一次打回、圈一筆、修改、確認，都可以成為 Bot 學習組織品味的素材。一次方案退回，可能是邏輯不夠收束；一次報告重寫，可能是結論缺少業務視角。這些信號在沉淀到 Matter 之后，它們就有機會被提煉成下一次可復用的偏好。

這個過程可以理解為：人把說不清的「我就要這個」逐漸沉淀為 Agent 可以理解、調用與繼承的偏好。下次遇到類似任務，相關偏好會自動進入上下文。這樣一來，Bot 會在一次次實戰中更接近團隊的做事方式，并理解公司的決策、交付模式。

當 Bot 擁有了差異化的偏好，多 Agent 協作的關鍵就變成了「如何讓它們在同一任務中合理分工」，避免被簡單地拉進同一個群聊里一起發言。

Octo 的六種協作模式，解決的正是這個問題。

六種協作模式，本質是六種信息拓撲

多個 Agent 一起協作，并不等于「多叫幾個 Bot 進群」。

更細化的問題決定了執行效果，比如信息怎么傳？誰負責生成，誰負責驗證？哪些任務需要獨立視角，哪些任務需要公開討論？哪些步驟必須按順序進行，哪些任務可以分頭推進？

面對不同層次的需求，Octo 將復雜協作拆成了六種模式：

Solo 是單干模式，適合簡單明確的任務，由領隊獨自完成。

Roundtable 是圓桌討論，在領隊主持下，多個 Agent 圍繞同一議題展開公開討論，參與者互相可見，適合需要形成共識、碰撞觀點、收束結論的任務。

Critic 是生成 — 驗證模式，其中一個 Agent 負責生成，另一個 Agent 負責審核，生成方和驗證方必須不同。驗證方有否決權，發現問題可以打回重做。該模式適合需要獨立審查的場景，比如代碼檢查、事實核查、方案質檢。

Pipeline 是流水線模式，從 A 到 B 到 C 嚴格串行，每一步的產出作為下一步的輸入。它適合存在明確順序依賴的任務，比如先調研，再分析，再寫作，再校對。

Split 是分頭干模式，領隊把任務拆成互不可見的子塊，由多個 Agent 各自處理，最后再由領隊合并。它適合大任務分治，比如一個行業報告拆成政策、市場、技術、案例幾個部分。

Swarm 是撒網競選模式，同一個任務交給多個 Agent 獨立完成，參與者彼此互盲，最后由領隊擇優。它適合需要多解并行、避免從眾的場景，比如標題、方案創意、產品命名、不同分析路徑。

整體看下來，Octo 多協作模型不僅是把 Bot 拉到同一個地方，還規定了信息流轉的方式：不同任務匹配不同拓撲，系統保證信息沿正確路徑流動

相較之下，飛書或 Slack 群聊里的 AI 可以讓所有人看到所有消息，但復雜任務經常需要更細的隔離。群聊擅長「都看見」，卻很難做到「該互見時互見，該互盲時互盲」。

換句話說，Octo 對協作的理解已經超出了「多人聊天」這一層。在真實組織里，協作包括了空間劃分、權限邊界、上下文繼承、過程追蹤、任務拆解、反饋沉淀和最終驗收。人類過去依賴項目管理系統、知識庫、IM、文檔和會議來完成這些工作，Agent 加入之后，這套協作骨架也隨之改變。

拆開來看，Octo 在做四件事

從產品形態看，Octo 正讓 Agent 像組織成員一樣進入工作流：用 IM 承載交互，用空間、分組、頻道、子區搭建協作結構，用語音提升輸入效率，用瀏覽器插件接入外部工具，再用 group.md 約束協作方式

先看結構層，空間（Space）、分類（Category）、頻道（Channel）和話題（Thread）將協作關系組織得很清楚。

在 Octo 里， 一項任務通常是在某個空間里被提出，可能是一個簡單的問題，也可能是一段更完整的描述。無論形式如何，這條信息一出現，就帶著明確的上下文：屬于哪個空間（面向目標的工作區），在哪個頻道（可以理解為群聊），話題是什么（可以理解為群聊子區）。

和普通聊天不一樣，新消息不會很快被沖掉，自然地落在某個頻道或話題里，變成一件可以一直跟進、隨時回溯的事情。

Octo 協作關系展示

接下來是入口層。在 IM 界面，私聊和語音讓我們進入這套系統的方式變得更簡單。

通過人與人、人與分身的一對一對話通道，私聊可以讓人與 Agent 在同一個上下文中溝通、分工、反饋，不需要額外學習新的交互方式，就能把任務放進去、再把結果拿出來。

但當協作變復雜，問題可能會出現在輸入這一端。很多時候不是 Agent 做不出來，反而是人來不及把需求講清楚。輸入慢，導致整個流程就跟著慢下來。引入語音之后，信息可以更快進入系統，任務描述、上下文補充和決策反饋都更順手。

然而Octo 內置的語音輸入不只是將聲音轉成文字，它同樣也是一個持續進化和學習的系統。它會結合當前對話的上下文，對轉寫的內容進行修正和梳理，一方面提高準確率，另一方面讓表達更清晰、更有邏輯。同時，對于團隊中的人名、公司名或者行業專有名詞，出現頻率越高它認得越準。

另外，你還可以語音 @他人、修改已有內容甚至刪掉前面的輸入。在這里語音接近一種可以參與操作的交互方式。從能力上來看，這套機制與市面上一些語音驅動操作的產品相似，但它是直接嵌在整個協作流程里，隨著任務一起向前推進。

語音輸入

環境接入層則更像是一個「上下文橋接器」。這一層并不是用來取代工具的，把已有工具接進來是它的主要任務。

通過內置的瀏覽器插件，用戶可以通過「Cmd + K」把外部工具無縫接入進來。無論是在網頁、文檔還是代碼平臺上，只要選中一段內容，當前頁面的鏈接、標題和選中文本就會自動被帶入上下文。

在將這些信息一鍵發送給 Bot 或者在當前對話引用后，它們立即接手并知道你在處理什么問題、處在什么環境。它不需要把你從現有工具流中「拉走」，在旁參與協作即可。

瀏覽器插件

真正的分水嶺出現在后面這一步。在大多數團隊里，難的不只是把事情做完，讓 AI「行為可控」同樣至關重要。

GROUP.md 的作用正體現在這里。它相當于一份專門設給 Bot 看的「行為準則」，明確了一個群聊的定位、協作模式和行為邊界。每一次對話、每一條任務指令，所有參與進來的 Bot 都會在遵守 GROUP.md 規則的前提下執行，確保討論高效且有序。并且當切換到另一套 GROUP.md 時，同一只 Bot 馬上調整工作模式，「進什么廟，念什么經」，絕不逾矩。

此外，Octo 還強調多端補全：Web、移動端、瀏覽器插件、CLI 共同構成入口。尤其是 CLI，它連接端側環境和私有化部署敘事，讓本地模型、本地文件、本地運行環境進入協作體系。

O.C.T.O.：四個維度，缺一不可

至此，Octo 的產品能力就比較清晰了，它們分別對應名字背后的四個維度：Open、Context、Taste 與 Orchestration。

O 是「Open」，代表開放生態。不同 Runtime 的 Agent，包括 OpenClaw、Codex、Claude Code、Cursor 等，都能夠以 Bot 身份接入，獲得統一身份。

C 是「Context」，代表共享上下文。IM 中的討論收斂為結構化知識，項目上下文在不同 Agent 之間共享，任務過程也可以被持續追溯。

T 是「Taste」，代表偏好進化。實戰反饋沉淀為偏好，每個 Agent 背后主人的品味和判斷方式被結構化留存與調用。

O 是「Orchestration」，代表多 Agent 編排。六種協作模式對應六種信息拓撲，不同 Bot 帶著不同偏好參與同一任務，合力完成復雜工作。

這四個維度連在一起，構成了 Octo 所提供的完整能力。承載起 Context、Taste、Orchestration 的共同基座正是 Matter，它成為復雜任務得以被理解、反饋、校準和編排的核心容器。

沒有 Matter，Context 會散落在聊天記錄里，Taste 會缺少來自真實任務的反饋來源，多 Agent 編排也很難留下可追溯的過程和結果。

Octo 想要把一次次協作轉化為組織資產，就必須先讓每一件事有穩定的結構、完整的過程以及可以沉淀的判斷。從這個視角來看，Octo 想爭奪的是企業在 Agent 時代最關鍵的一類資產：自己的上下文、判斷標準以及做事方法。

像 Octo 這樣的嘗試，補上的不只是把 Agent 連在一起的能力，也在悄悄改變組織內部知識流動和協作的方式。

但這并沒有走向另一種極端。人不可替代的部分，包括 Taste、暗默知識、判斷力依然留在個體身上，只是通過協作過程得到進一步彰顯和傳遞，也就是說「能力可以共享，但判斷不會被抹平。」

這也帶出了一個更根本的問題：在 AI 時代，企業真正的長期競爭力究竟來自哪里？

當模型能力快速趨同，長期競爭力更多來自企業自己的 Context、Taste 和 Skill。這些東西無法被復制，也不應該流失，它們才是組織在 AI 協作中真正的「護城河」。

正因如此，當 Agent 真正進入組織運轉，數據主權問題變得無法回避：這些上下文、判斷信號與執行記錄，究竟歸誰所有、留在哪里、由誰控制？Octo 給出的答案很直接，走私有化路徑，通過開源開放支持本地部署

在實現上，Octo 以 CLI 接入的方式將端側模型與本地環境接入進來；工作流中產生的上下文、決策過程與執行結果同樣留在端側，沉淀為組織可以掌控的資產。這意味著，包括聊天數據、協作產出、Bot 記憶在內，每條對話、每行代碼都保留在你的環境中，完全跑在自己的服務器上。所有這些都將成為企業獨享的 AI 資產。

在 Octo 的產品哲學中，「Context」與「Taste」是兩大核心：前者是 AI 理解任務的土壤，后者是持續校準方向的羅盤。Octo 并非將人的隱性能力蒸餾為平臺資產，它是在尊重數據邊界的前提下，讓這些能力得到放大、記錄與傳承。

這與明略科技長期堅持的可信 AI 方向高度一致。明略科技持續構建面向端側智能、私有化部署與人機協作的新一代 AI 基礎設施：能力可以流動，但數據不外流；協作可以展開，但控制權留在組織內部。

對企業，Private AI 不只是本地化部署，更是數據主權、知識主權與協作主權的真正回歸。對個人，真正被放大的價值是 Taste—— 我品故我在：當 AI 逐步接管了思考，人的判斷力、鑒賞力與創造力不會被取代，反而成為存在的意義本身。

支撐這一切的底座是 Trustworthy AI：開源、白盒、可審計。只有當 AI 的能力來源、運行過程和協作邊界足夠透明，人才放心將「思」交給它們，把「品」留在自己手里。

Octo 的探索還在早期，但輪廓已經清晰：當 Agent 更深入地嵌入分工體系，真正決定效率的是那些無法被標準化、也不應該被外流的東西 —— 組織自己的上下文和人自己的判斷。

文中視頻鏈接：https://mp.weixin.qq.com/s/rB51LZBmrUNTPDAjw017qA