2026/10/30 · Weekly Radar
LangChain 拆解自家三個內部 agent（GTM Agent、OpenSWE、Content Studio）各自收斂出的五個共同元件：住在 Slack、身分、記憶、沙箱執行、排程觸發，把它整理成公司內部 agent 平台的通用配方。
這篇是 Harrison Chase 與 Caspar Broekhuizen 於 2026 年 10 月 24 日發表的文章，主題是如何打造「company harness」，也就是給整間公司使用的內部 agent 平台。LangChain 已在行銷、業務與工程團隊各自建了內部 agent，並說這些 agent 改變了團隊的工作方式；作者觀察到每個團隊最後都收斂到同一組核心元件，共五個：一、住在大家已經在工作的地方（LangChain 是 Slack）；二、身分，agent 要知道誰在問，並對某些服務代表該使用者行事、對另一些服務則用自己的身分；三、記憶，可分為全域或個人層級，或兩者兼具；四、沙箱化的程式執行，且能從沙箱內發出經過授權的請求；五、排程執行，很大比例的執行是排程或事件觸發，而非人手啟動，作者稱之為「ambient agents」。
GTM Agent 是常駐、主動的業務 agent，會監看並回覆 email、追蹤新的合格潛在客戶、每天發簡報、回答客戶帳戶問題，也能跑 outbound 行銷活動。OpenSWE 是工程 agent，負責起草與處理 pull request，並對所有 PR 做 code review。Content Studio 是行銷 agent，依 LangChain 的風格與市場定位起草部落格、圖片、簡報與影片等素材。作者說三者都用同一套方式打造，因此可當作一般性的配方。
這些 agent 都住在 Slack，各有自己的 Slack app，可以私訊，也可以在頻道裡 tag。在頻道裡使用的好處是其他人能看到同事怎麼用 agent。他們做了「breakout threads」功能，讓 agent 可以移到頻道中自己的討論串，不干擾人類的對話。有些任務不適合在 Slack 做，例如要審核 GTM Agent 想寄出的一大批 email，用 Slack 訊息很難追蹤，所以另外做了自訂 UI。
作者稱身分是「最棘手」的問題。業界主要有兩種做法：on-behalf-of（OBO），agent 以呼叫它的使用者身分行事；以及固定憑證，不論誰呼叫都用同一組憑證，例如 service account。每個 agent 都混用兩者。OpenSWE 被人私訊時以那個人的身分行事，例如用對方的 GitHub 帳號開 PR；在背景執行 code review 時則用自己的身分（一個 GitHub app）。GTM Agent 存取 Salesforce 用固定身分，免得每個人都要登入；email 則代表呼叫者操作，而且這些工具只在私訊中開放，不在共用頻道。Content Studio 存取 Notion 時代表呼叫者；Twitter 則用公司的一組固定憑證，且只有白名單使用者能執行特定操作，例如不是每個人都能發文，有些人只能讀或起草。
所有 agent 都有兩層記憶：適用所有使用者的全域記憶，以及只適用特定使用者的個人記憶，由 agent 自己判斷每則資訊該歸在哪一層。作者形容記憶「大概是目前最少被探索的領域」，並說後續還有很多規劃中的工作。
三個 agent 都會寫程式並執行，通常是為了完成任務。共同模式是 agent 本身在沙箱外運作、連進沙箱執行程式；每個 agent 用的 base image 略有不同、依賴也不同，最偏程式的 OpenSWE 還會依頻道與使用者選擇 base image。三者都使用 LangSmith Sandboxes 的 secret proxy，讓沙箱內的程式能安全地存取外部服務。
很大比例的執行是排程或事件觸發（文中沒有給具體數字），來源有兩種：開發者設定的，例如 OpenSWE 監聽新 PR 並逐一 review；使用者設定的，例如作者請 GTM Agent 每天給一份簡報，它就自己建了一個 cron job 來交付。
這些 agent 全部建在 Managed Deep Agents 上，它跑在開源的 Deep Agents harness 之上，為上述每個問題（頻道、cron、沙箱、記憶、身分）提供基礎設施，同時保留客製 agent 行為的彈性。文末附上 quickstart 連結。
五個元件裡最難的兩個，身分「最棘手」、記憶「最少被探索」，作者自己都承認還沒解完；結尾倒是已經可以把你導去 Managed Deep Agents 的 quickstart。藍圖先賣，地基還在施工。