OpenExecutive：把八位 C-level 裝進一個人格的開源多代理系統

它想解決的是「同一個問題問八次，得到八種答案」

多代理系統最常見的失敗不是答錯，而是答得不一致。你上午問策略代理要不要進軍東南亞，它說先做市場驗證；下午問財務代理同一件事，它直接算出一份三年現金流。兩個答案各自合理，合起來卻不是一家公司會說的話。OpenExecutive 的設計前提就是這個：對外只保留一個高管人格，八個專科代理是內部實作，README 寫得很直白，內部代理架構永遠不會暴露給使用者。

目標讀者因此不是「想要一組 AI 工具」的人，而是想要一個固定口吻的虛擬顧問的人。README 列出的八個角色涵蓋策略、財務、人事、法務、營運、行銷、產品與董事會溝通，這個組合明顯偏向已經有規模、需要對外與對董事會交代的公司，而不是還在找產品市場契合的早期團隊。

Orchestrator 的資料流：工具呼叫、雙層檢索、單一人格

README 的架構圖把流程寫成五段：使用者訊息先進入 Executive Orchestrator，由它決定要用哪些工具，平行呼叫專科代理；每個專科代理各自到 ChromaDB 取回相關脈絡；脈絡來自內建 MBA 知識與你上傳的公司文件兩層；最後合成為一段高管回覆。

檢索層的切分值得注意。內建知識是 git 追蹤的 Markdown，放在 knowledge/builtin/，啟動時種入 ChromaDB；公司文件則切塊後存進另一個名為 company_docs 的集合。兩者分開意味著你可以整批換掉公司文件而不動內建知識，反過來升級內建知識也不會污染你的私有語料。README 另外強調檢索脈絡是注入使用者回合，而不是注入被快取的系統提示，這個選擇直接決定了提示快取能不能生效。

模型分配也是分層的：Executive 與多數專科代理用 claude-sonnet-5，策略、財務、法務與董事會四個角色改用 claude-opus-5 並開啟 extended thinking。這是成本與推理深度的取捨，四個最需要長鏈推理的位置留給較貴的模型。

片段記憶與排程器：跨會話記得你上個月被建議了什麼

每次回應之後，系統會跑一輪背景的 claude-haiku-4-5，把決策、倡議與建議抽出來寫進 SQLite。下一個會話開場時帶入一段 <past_decisions> 區塊，於是 Executive 記得它上個月建議過什麼。這個設計的價值在於問責：當你回頭問「上次那個定價方案後來怎麼了」，系統有東西可以對照，而不是從零重講一遍。

代價寫在 README 裡，而且寫得很清楚：內建排程器用 UPDATE … RETURNING 搶佔到期任務以避免重複觸發，因此 API 必須以單一實例運行，未先處理排程器就不能水平擴展。這是整個專案最硬的一條部署約束。任何想在 Kubernetes 上開三個副本的計畫，都會先撞到這行字。

片段記憶本身也有邊界。抽取由另一個模型在背景完成，寫入的是 SQLite，README 沒有說明記憶的修剪、衝突解決或遺忘機制。長期使用下，<past_decisions> 區塊只會越來越長，這部分在文件裡是空白。

啟動：make dev 之前要先補齊的環境變數

官方路徑很短。複製 repo 之後，把 .env.example 複製成 .env，填入 ANTHROPIC_API_KEY，Web UI 的 Google 登入則要補上 AUTH_* 那一組，README 指向 docs/auth.md 說明 Google Cloud Console 的步驟，然後執行 make dev。UI 開在 3000 埠，API 在 8000 埠。

設定檔的優先順序容易踩到。repo 根目錄的 .env 會被 make dev 與 make docker 同時載入給 API 和 UI，Auth.js 在執行時需要 AUTH_SECRET、AUTH_GOOGLE_ID 與 AUTH_GOOGLE_SECRET。另外 packages/ui/.env.local 也會被讀取，但只放 UI 專屬的鍵；同一個鍵同時出現在兩個檔案時，根目錄的 .env 優先。

不用 make 的貢獻者走手動路徑：在 packages/core 底下執行 uv sync，啟用虛擬環境後用 uvicorn openexecutive.api.main:app --reload --port 8000 起 API，另一個終端進 packages/ui 執行 npm install 與 npm run dev。

首次啟動的等待要有心理準備。README 說明第一次 uv sync 會拉進 ChromaDB 與 sentence-transformers/PyTorch 這批重量級 ML 依賴，首次開機還要下載約 90 MB 的嵌入模型來建本地向量索引，所以第一次 make dev 要幾分鐘才會就緒，之後就快了。環境需求是 Python 3.11+ 與 Node 22+。

提示快取與單實例：兩個設計決定，兩種風險

系統提示被刻意拆成 Executive 人格、公司檔案與知識索引三塊分別快取，README 說在頭幾輪之後快取命中率可達 85%。規則很嚴：任何動態內容都不能放進被快取的區塊。這條規則同時是效能保證與維護負擔，日後任何人想在系統提示裡塞一段即時資料，都會無聲地打壞快取命中率，而系統不會報錯。

單實例排程器則是另一種性質的風險。它是一個正確性機制，不是效能機制：UPDATE … RETURNING 的搶佔語意只在單一寫入者下成立。這代表 OpenExecutive 的擴展方向只能是垂直的，或者你得先把排程器拆出去。README 自己指出了這條路，但沒有說拆出去之後長什麼樣，docs/architecture.md 被指向為完整設計所在。

把兩件事放在一起看，會發現這個專案的部署模型其實相當傳統：一個有狀態的後端、一個本地向量庫、一個本地 SQLite。這不是缺點，只是意味著它不是為無狀態雲端原生部署設計的，挑選運行環境時要照這個前提來。

什麼時候它會是錯的工具

第一種情況是法務。General Counsel 代理處理合約、IP、僱傭法基礎與合規，但 README 用的是「employment law basics」這個詞，basics 就是邊界。涉及具體司法管轄區的僱傭爭議或跨境合約條款，這個代理產出的是起點而不是結論。

第二種情況是水平擴展。前面說過，API 必須單實例。如果你的使用模式是突發的高並發，這個架構會直接卡住。

第三種情況是供應商約束。整套推理綁在 Anthropic Claude API 上，預設模型是 claude-sonnet-5，深度推理用 claude-opus-5，記憶抽取用 claude-haiku-4-5。想跑本地模型或想保留換模型的自由，這個專案幫不上忙。

還有一個容易被忽略的訊號：repo 標示的授權是 NOASSERTION，而 README 的徽章與技術棧表都寫 Apache 2.0。兩者不一致。在把這個專案放進商業流程之前，這件事必須先弄清楚，我無法從現有材料判斷哪一個才是對的。

跟單一通用助手比，差別在檢索切分而不是代理數量

替代方案不是另一個多代理框架，而是你現在就在用的那個單一通用助手加上你自己餵的檔案。兩者最實際的差別有三處。

檢索切分。OpenExecutive 把內建知識與公司文件分成兩個 ChromaDB 集合，內建知識隨 repo 版本走，公司文件獨立更新。單一助手通常是把你所有上傳檔案混在一個檢索池裡，內建常識與私有語料互相競爭排名。

記憶的持久性。片段記憶寫進 SQLite，跨會話保留，並以 <past_decisions> 區塊在開場注入。通用助手的記憶多半綁在單一對話串或帳號層級，跨月的建議追蹤通常要自己貼回去。

角色分工的顯性化。八個專科代理各自有領域提示與檢索，Orchestrator 負責平行呼叫。通用助手是一段提示打天下，深度取決於你當下寫得多細。

反過來說，如果你的問題大多是單輪、低風險、不需要跨月追蹤，那這套編排只是多花錢與多維運。八個代理平行呼叫代表每次提問可能觸發多次模型請求，這在簡單問答上是純粹的浪費。

維護成本與授權：先確認再投入

維護面有幾個具體項目。ChromaDB 是本地嵌入式，索引要自己顧；首次開機的嵌入模型下載約 90 MB，之後的知識更新要重新種入。SQLite 存片段記憶，備份與遷移都在你手上。排程器單實例，任何部署拓撲變更都得先過這一關。repo 裡另有 fly.api.toml、fly.ui.toml，以及 QA 對應的 fly.api.qa.toml、fly.ui.qa.toml，還有一個可選的 fly.honcho.toml 記憶應用設定，顯示官方部署路徑是 Fly.io，並區分 dev 與 QA 兩套環境。integrations/ 底下有 Slack、Email、Telegram、Google Chat、Discord 五種整合，scripts/ 放的是 Fly secrets 與 Google 授權的操作腳本，evals/ 則有 LLM-as-judge 的評測執行器。這些都是要跟著模型版本一起維護的表面積。

授權方面，README 的徽章與技術棧表標示 Apache 2.0，但 repo 中繼資料顯示 NOASSERTION。這不是法律意見，只是提醒：在把程式碼併入產品之前，去看 LICENSE 檔案的實際內容，不要只看徽章。

最後一個觀察。這個 repo 沒有檢索到任何 release，首頁指向的 openexec-ui-dev.fly.dev 是 dev 環境。對於一個自稱虛擬高管團隊的系統，dev 環境的穩定性不代表你在生產環境會得到的東西。

編輯結論

OpenExecutive 適合已經在用 Anthropic API、想把「策略、財務、法務、人事」這類反覆出現的顧問型問答固定成一套人格與檢索流程的團隊，尤其是願意自己維護 ChromaDB 索引與 SQLite 記憶的 Python 工程師。不適合需要水平擴展 API 的團隊，因為 README 明確寫著排程器靠 UPDATE … RETURNING 搶佔到期任務、API 必須單實例運行，未先處理排程器就不能水平擴展；也不適合想避開特定模型供應商的人，整套推理都綁在 Claude 上。動手前先確認三件事：repo 根目錄 .env 與 packages/ui/.env.local 同時存在時的覆蓋順序、首次 uv sync 會拉進 ChromaDB 與 sentence-transformers/PyTorch 這批重量級依賴、以及授權檔的實際內容，因為 GitHub 標示為 NOASSERTION，與 README 徽章上的 Apache 2.0 並不一致。這三點沒確認完，後面的架構討論都沒有意義。

官方來源

1. Issues
2. Project website
3. README
4. SenteLabsAI/OpenExecutive on GitHub