公司級 AI Agent 是什麼？和個人助手差在哪

Q: 公司級 AI Agent 是什麼？

公司級 AI Agent 是能在組織身分、共享狀態、權限政策與隔離執行環境下替員工或專案採取行動的系統，而不只是多人共用的聊天機器人。

Q: 公司級 Agent 一定要使用多個模型嗎？

不一定。公司級與否取決於身分、資料、權限及治理設計，不取決於模型數量；同一個模型可以同時用在個人助手與公司平台。

一個人把 Gmail、GitHub、Notion 和行事曆交給自己的 AI Agent，通常只需要先問一件事：它好不好用？

當多位員工開始使用同一套 Agent 平台，問題會完全改變。財務可以讀哪些資料？工程頻道能不能使用創辦人的 Email 憑證？Agent 在公開頻道記住的內容，會不會出現在私人對話？

這些問題和模型聰不聰明沒有直接關係。

公司級 AI Agent 是能在組織身分、共享狀態、權限政策與隔離執行環境下，代表員工或專案採取行動的系統。

個人助手與公司 Agent 的真正差別，是後者必須處理更多人之間的信任邊界。

個人 Agent 的預設信任模型：你相信你自己

個人助手的設計通常很直接。你安裝 Agent、輸入 API key、登入服務、選擇工作目錄，然後開始交代任務。

Agent 使用的是你的檔案、帳號與權限。即使做錯事，責任範圍大致仍落在同一個使用者身上。這種模型的優點是簡單：Agent 不必在每個動作前重新判斷自己代表誰，也不必區分許多記憶空間。

OpenClaw 的 workspace 就是一個例子。操作指令、記憶檔案、技能與使用者資料，可以放在 Agent 的主要工作環境中。Hermes Agent 則把同一套 Agent 能力延伸到 CLI、Desktop 與 messaging gateway，讓使用者更換模型、設定 personality 並安裝技能。

這些工具也能服務高度信任的小團隊，但最自然的起點仍是一個使用者擁有並管理一個 Agent。公司環境正好相反：你不能假設所有使用者都應共享彼此的信任。

上一篇 YC QM 與公司級權限邊界談的是這個轉換為何發生；這一篇要把分界拆成六層。

第一個分界：Agent 代表誰？

個人 Agent 的答案通常很簡單：代表目前使用者。

公司 Agent 卻可能出現在私人對話、Slack 專案頻道、跨部門群組、背景排程、Webhook 或 CI 任務中。這時「誰送出訊息」不一定等於「Agent 正在代表誰」。

假設工程師在專案頻道要求 Agent 檢查正式環境日誌。Agent 應該使用工程師的個人權限，還是專案被授予的權限？如果另一位沒有正式環境權限的同事也在頻道裡，他能不能看到完整結果？

身分問題不能靠聊天訊息裡的一句提示詞解決。系統必須知道目前代表哪個身分主體（principal）、任務位於哪個工作與權限範圍（scope），以及結果可以交付給哪些對象（audience）。

否則 Agent 很容易變成權限捷徑：使用者自己沒有存取權，卻能透過共享 Agent 取得別人的資料。

第二個分界：記憶屬於誰？

個人 Agent 的記憶通常以「讓它更懂我」為目標。它可以記住寫作風格、常用指令、工作目錄、偏好格式與過去決策。

OpenClaw 將記憶保存在 workspace 的 Markdown 檔案中，讓使用者檢查、修改、備份與版本控制。這種可見記憶很適合個人環境，但進入公司後會多出一個問題：所有權。

員工的私人偏好、部門內部討論、專案決策、客戶機密與管理階層資訊，不應自動進入同一份記憶。

QM 的做法是讓每位員工與每個 room 擁有自己的 scoped memory。私人對話學到的內容不會因為使用者進入共享頻道，就自動變成團隊知識；專案記憶也不必綁在某位員工身上。

公司級記憶追求的不是什麼都記住，而是在正確的地方，讓正確的人取回正確內容。若想看另一種可檢查的長期記憶設計，可延伸閱讀 GBrain 的雙軌 Agent 記憶架構。

第三個分界：有憑證，不等於任意使用

個人 Agent 常讓使用者輸入 API key、登入網站或授權 OAuth。這些憑證代表使用者本人，責任範圍相對清楚。

公司任務可能需要某位員工的 Gmail、專案 GitHub App、資料庫唯讀帳號，或只允許操作測試環境的雲端憑證。此時不能只有「有 key」與「沒有 key」兩種狀態。

授權至少要回答：

誰擁有這個憑證？
哪個 scope 能使用？
是單次還是長期授權？
什麼時候過期？
能不能立即撤銷？
使用紀錄由誰查看？

憑證只是技術材料；授權（grant）才是在描述這份能力被交給誰。

第四個分界：Workspace 不等於 Sandbox

Workspace 解決的是「Agent 在哪裡工作」；sandbox 解決的是「Agent 出錯時，影響能不能被限制」。

如果 Agent 可以直接在員工日常電腦執行指令，它取得的可能不只是一個專案資料夾，還包括 SSH key、瀏覽器登入狀態、雲端 CLI 憑證與公司內網權限。

個人使用者可能願意用更高權限換取更強能力，公司不能把這種交換當成所有人的預設值。

QM 為每個 scope 提供能保留工作狀態的沙箱（durable sandbox）。Agent 能在裡面安裝工具、保存檔案並延續任務，但不同 scope 不應因此取得彼此的工作環境。

真正需要隔離的是檔案、程序、憑證、網路與工作狀態。只把 Agent 放進容器，卻掛載整個共享磁碟並注入所有 secrets，仍然不是有效邊界。

Sandbox 不是安全魔法盒。它的價值是縮小出錯時的爆炸半徑。

第五個分界：頻道不只是聊天介面

許多 Slack Bot 只是把頻道當成輸入與輸出管道：收到訊息、呼叫模型、貼回答案。真正的 Agent 狀態仍屬於中央帳號。

這種模式可以回答問題，卻不一定適合長期協作。一個專案頻道通常有自己的參與成員、文件、決策、Repo、排程與外部服務。

如果 Agent 要成為專案的一部分，頻道就不能只是訊息來源。它需要成為具有記憶、技能、權限與交付對象的共享 scope。

這也是多人 Agent 平台和單純多開 Agent 的差別。公司需要管理的不只是 Agent 如何合作，還包括人與 Agent 如何在同一個空間工作。

第六個分界：出了事，能不能知道發生什麼？

個人 Agent 做錯事，使用者可能查看 terminal history、對話紀錄或 Git diff。公司環境不能只靠個人回想。

當 Agent 代表員工操作正式系統，組織需要知道：

誰啟動任務？
任務在哪個 scope 執行？
使用哪些工具與憑證？
哪些動作經過人工批准？
結果傳給誰？
使用哪個模型與 harness？
能否停止、撤銷或還原？

這就是稽核與治理層的工作。管理者不只在管理軟體，也在管理 Agent 可以代表公司做出的行動。

個人助手與公司 Agent 的六層比較

面向	個人 AI 助手	公司級 Agent
最佳化目標	個人生產力與彈性	協作、邊界與治理
身分	單一使用者	員工、群組、專案、服務
記憶	個人 workspace	Personal 與 shared scope
憑證	使用者直接提供	Scoped grant、期限與撤銷
執行	本機、VPS、個人容器	Per-scope sandbox
協作	私人對話或個人入口	Shared scope 與交付對象
稽核	使用者自行追查	組織政策、批准與行動紀錄

這不代表公司級 Agent 一定更好。對單一使用者來說，組織層可能只是額外負擔。你不需要為三個個人工作流建立完整的身分解析、audience policy 與管理後台。

反過來說，公司也不應因為某個個人 Agent 很好用，就把同一套信任模型擴張到整個組織。

個人工具的優勢是自由；公司平台的價值是邊界。

什麼時候個人 Agent 已經不夠用？

問題不在固定人數，而在信任關係是否開始分裂。出現下列情況時，就應評估公司級架構：

不同員工不應共享全部資料。
Agent 需要在私人與公開頻道切換。
公司想統一限制模型與工具。
專案需要不依附單一員工的共享記憶。
不同團隊需要使用不同憑證。
高風險動作需要人工批准。
組織需要完整行動紀錄。
員工離職後，Agent 資產必須移交或撤銷。

只要這些問題開始出現，繼續增加個人 Agent 通常只會增加維護成本。

如果現階段只是想把口述內容整理成文章、訊息或任務，可以先用範圍更窄的 Typeless AI 語音轉錄，不必為單一需求提早引進公司級管理層（control plane）。

利益揭露：Typeless 連結為聯盟連結；若你透過連結訂閱，本站可能獲得分潤，不影響你的價格與本文判斷。

個人 Agent 的問題是它懂不懂我；公司 Agent 的問題是它知不知道自己現在代表誰。

下一篇會繼續往技術架構走：當每位員工與每個專案都有自己的 Agent，記憶、憑證與沙箱究竟要怎麼隔離？

常見問題