LangChain 公開公司代理五大元件：員工身分、共用記憶與背景工作怎麼接？
LangChain 公開行銷、業務與工程代理的共同架構，包含協作入口、使用者與服務身分、雙層記憶、沙箱和排程。解析哪些資料適合共用，以及代理代誰操作服務的界線。
一個人請 AI 寫報告，知道自己的資料放在哪裡就能開始。當整個團隊都能在聊天頻道叫它做事，問題會多出一層：這次到底是誰的資料、誰的權限和誰的工作紀錄？
LangChain 在 2026 年 10 月 24 日公開公司內部代理的共同架構，整理業務、工程與行銷三種工作背後的五個元件。
這套 company harness 可以理解為代理工作的共用底座，從同事接觸它的入口，到辨認身分、保存記憶、執行程式與在背景啟動任務，必須接成同一條路。
共用入口不代表共用所有權限。例如業務代理的電子郵件工具只在私訊開放，行銷代理則只有白名單中的使用者能執行特定發文操作。
我會先用「這一項操作代表誰」檢查公司的代理設計，再決定哪些內容適合共用。若這個答案還不清楚，多加一個聊天入口只會把既有權限問題帶給更多人。
要讓同事自然使用又不混淆工作範圍，起點是把代理放進熟悉的協作入口，並保留需要另外呈現的操作介面。
LangChain 為何讓代理住在 Slack？
公司把三種內部代理放進團隊原本使用的 Slack，讓同事能私訊、標註與看見彼此如何交辦。這裡先解決的是人怎麼接觸代理，而非模型如何提高分數。
官方架構文章列出業務用的 GTM Agent、工程用的 OpenSWE，以及製作行銷內容的 Content Studio。三者任務不同，卻都需要承接同事原本的工作對話。
讓代理有自己的 Slack 應用程式，意味著同事不用為每種任務另找一個入口。在頻道裡交辦，也能讓其他人看見哪些要求有用，減少每個人從空白提示開始摸索。
不過，代理參與討論可能打斷原本的人際對話。團隊因此加入另開討論串的方式，把適合代理處理的工作移出去，保留原來的交流脈絡。
聊天不是所有操作最適合的介面
官方也承認，有些事不適合全部留在 Slack。例如逐封確認少量待寄信件還能處理，大量積壓信件若全靠訊息追蹤，就不容易看出哪些已經審完。
因此，團隊另外做了專用介面。它和聊天入口各有用途：前者讓人集中處理一批操作，後者讓臨時問題與工作交辦自然出現。
這個選擇說明 company harness 不只是一個聊天機器人。它還要安排工作在哪裡提出、結果在哪裡查看，以及哪些決定需要另一個更清楚的畫面。
對想共用代理的團隊而言，可以先按任務找介面，而不是要求所有工作都只能從同一個聊天框完成。入口方便，仍要讓人看得見自己正在批准什麼。
當同一個入口可以被多人使用，系統就必須接著回答每一項工具操作究竟代表哪個身分。
同一代理何時代表員工，何時用自己的帳號？
公司按工具與啟動方式選擇使用者身分或固定服務身分，而非替一整個代理只選一種權限。這是官方認為最棘手的設計問題。
代表使用者操作，常寫成 OBO，也就是由代理以提出要求那個人的身分行動。固定服務身分則像公司專用帳號，不會因為誰在聊天裡叫它而自動換人。
OpenSWE 是明確例子。同事直接傳訊息給它時，可以代表該使用者提出 GitHub PR。PR 是交付程式變更、供團隊審查的紀錄。
但當它在背景做程式審查時，使用的是自己的 GitHub 應用程式身分。前台交辦與事件觸發雖然由同一代理處理，責任來源並不相同。
同一代理裡的工具，也可以有不同身分
業務代理讀取 Salesforce 時使用固定身分，避免每個人都重新登入。電子郵件工具則代表呼叫者本人，而且只在私訊提供，不在共享頻道出現。
這個限制讓工具能力和對話環境一起改變。看得到代理，不代表在任何地方都能叫它讀取或操作個人的電子郵件。
行銷代理也有混合安排。它讀取 Notion 時可代表使用者，操作公司社群帳號則用固定憑證。特定寫入操作只允許白名單中的人提出。
因此，同一個公司帳號還需要區分讀取、草稿和正式發布。固定憑證解決的是用哪個帳號連線，不會自行回答哪些同事有權叫代理對外行動。
確認誰有權操作後，還要避免代理把一個人的資料記成全公司的共同知識。
共用記憶與個人記憶如何分開？
公司代理需要把適合所有同事的知識，和只屬於單一使用者的內容放進不同記憶層。團隊內部將這兩種範圍稱為全域與使用者記憶。
團隊慣例和可重複採用的流程，可能適合前者。個人的偏好與當次工作的私有背景，則不應因為一次對話就變成所有人可讀的筆記。
Managed Deep Agents 記憶文件進一步說明，持久記憶需要主動啟用，並不是建立代理後就預設存在。
持久記憶指的是跨討論串與工作階段仍可沿用的知識，和同一段對話暫時保存的狀態不同。兩者的使用期間不同，刪除或停用時也不能混為一談。
記住誰，要先知道是誰在呼叫
目前文件以代理層與使用者層分開保存。代理層屬於同一個部署，使用者層則依經驗證的人員身分決定，系統不會自動把兩層內容互相複製。
預設使用者記憶只在個人私訊等適當入口提供，共享頻道、群組私訊與直接透過 API 這種程式介面呼叫的工作預設不開放。若要改動，必須設定相應政策，而非只讓模型自行判斷場面是否私密。
一般服務用 API 金鑰也不會自動等於一位可辨識的個人。這說明「請求可以連進來」和「能用哪一份個人記憶」是兩個檢查。
個人對話隔離同樣不等於對所有管理角色隱形。身分文件說明，具備工作區 API 存取資格的人仍可讀取和搜尋部署中的討論串，不能把終端使用者之間的隔離誇大成所有管理者都看不到。
常用記憶會放在每次呼叫模型都載入的筆記，詳細資料則留在需要時才讀取的檔案。這讓團隊慣例容易取得，也避免每次都把所有歷史資料塞進模型能閱讀的範圍。
不過，共用筆記可能受到不同呼叫者影響，不能因為內容被記住，就把它當成新的操作授權。停用某一層記憶也只是停止存取，不代表已保存的檔案隨之刪除。資料保留仍要另外處理。
記憶能補足脈絡，但代理真正要跑程式與呼叫服務時，仍得有另一層執行與憑證設計。
延伸閱讀：Sanity 公開公司代理架構：員工填文件建代理，路由、知識與權限怎麼接？
沙箱與 secret proxy 各自保護什麼？
代理在沙箱外協調工作，將需要執行的程式放進沙箱，再由外部代理層替符合規則的連線加入憑證。這把「決定做什麼」與「程式在哪裡跑」分開安排。
沙箱是獨立的執行環境，用來放代理寫出的程式、相依工具與運算產物。三種內部代理會使用不同基礎映像，也就是預先備好的環境與軟體組合。
OpenSWE 可以依頻道或使用者選擇合適環境，因此不必讓每一次工程工作都從同一個空白系統開始。行銷和業務任務則可以準備自己的相依工具。
但程式即使在隔離環境，仍可能需要呼叫外部服務。若把真實金鑰直接存進環境變數，裡面能執行的程式就可能讀到它。
連線時加憑證，不等於授予所有權限
Sandbox auth proxy 文件說明，外部代理層會比對目的地主機與路徑等規則，再把對應驗證資訊加入連線。
程式因此能使用服務，而不必在自己的檔案或環境裡保存真實憑證。有些工具需要先看到一個憑證變數才肯啟動，這時可以放替代值，由外部代理層在連線時提供真值。
這種安排減少了程式直接取得秘密的機會，卻不代表所有可做的操作都自然合理。若憑證能修改資料，還是要靠服務權限與工具範圍限制能改哪些內容。
網路目的地也有獨立政策。當前文件將組織層級的受限對外連線，和個別沙箱設定分開，不能因為用了 secret proxy，就假設所有外網已關閉或所有網站都可連。
讓程式能安全接觸服務之後，下一個權限問題會出現在沒有同事當場交辦的背景任務。
排程與事件觸發，誰替背景工作負責？
這些內部工作多半由排程或事件啟動，因此身分與工作範圍必須在使用者離線時仍然成立。文章沒有公布一個可套用所有企業的固定自動化比例。
其中一種來源由開發者設定，例如 OpenSWE 接收新 PR 建立事件，隨後做程式審查。這條工作不需要每次都由同事在頻道重打一遍要求。
另一種來源由使用者在對話裡提出，例如請業務代理每天寄送簡報，代理再建立排程。排程只是記錄何時啟動，後面要使用的資料與身分仍需配置。
時間到了，不會自動產生新的授權
兩種來源的共同點，是要把觸發條件與操作範圍說清楚。事件可以告訴系統有新工作，並不等於允許代理自行增加其他未交辦的目的。
以每天整理帳戶資訊為例，需要讀什麼資料、用哪個帳號、把結果交到哪個入口，都是工作定義的一部分。這是依官方例子延伸的設計判斷，實際排程仍須由團隊按自己的工作與權限配置。
背景審查使用自己的應用程式身分，也讓人能把「代理在排程中執行」與「某位員工親自操作」分開。否則事後只看到同一個人名，就不容易還原工作來源。
批次輸出也需要對應的接手方式。若代理準備許多待寄內容，使用專用介面集中審查，比讓人從大量訊息裡猜哪些已核准更符合前面的介面分工。
背景任務能持續運作，前提是團隊知道哪些動作可以自動做，哪些輸出還要回到人能審查的介面。
公司該先共用哪一段代理工作？
適合先共用的是入口、資料與核准角色都能說清楚的工作，而非把所有個人助理一次搬進群組。三個例子顯示，同一套底座也要依工作調整。
工程工作可以先看原始需求、變更與審查如何連在一起。業務工作要分清共用帳戶資訊與個人信件。行銷工作則需要把品牌素材和公司帳號寫入權限分開。
三種任務不能只靠換角色名稱互相替代。它們對個人資料、工具身分與輸出的接收方式不同，這些差異會留在配置與日常操作裡。
官方描述的共同底座建在 Managed Deep Agents 上，而這項由供應商代管的服務目前仍是公開測試版。內部使用經驗提供的是設計參考，沒有保證直接套上五個元件就能得到同樣成效。
我認為先回答「這項操作代表誰」，比先決定要做幾個代理更有幫助。答案清楚後，才能安排哪些記憶共用、程式放在哪裡，以及背景任務需要誰接手。
當每次呼叫都能對回身分、記憶與執行紀錄，共用代理才會成為團隊流程的一部分。
延伸閱讀：Claude Managed Agents 排程教學：每天整理 Slack 與 GitHub，怎麼避免重複通知？
常見問題
LangChain 這次推出全新的公司代理產品嗎？
這篇主要公開內部三種代理共用的架構經驗，五大元件由 Managed Deep Agents 提供基礎能力，不等於同日推出一個全面正式開放的新模型。
每個 Managed Deep Agents 都會記住公司資料嗎？
持久記憶需要啟用，代理層與使用者層也可分別設定。預設對話狀態不等於跨工作階段保存的知識。
用同一個公司帳號，大家就能叫代理發文嗎？
不能這樣推論。LangChain 的行銷代理使用公司帳號時，仍以白名單限制特定操作。連線身分與誰能要求寫入是兩件事。
