Agent 到職企業，需要一台電腦，也需要一張識別證

AI 生成的概念插圖，以電腦和識別證比喻執行環境與業務存取權限。

一位新同事到職，企業通常會先準備兩樣東西。

一台電腦，讓他能開啟檔案、執行軟體、完成工作。一組帳號和權限，讓他能進入 OA、查閱專案文件、使用 CRM，在職責範圍內讀取和修改業務資料。

電腦準備好了，帳號尚未開通，他仍然很難開始工作。帳號開通了，缺少可用的工作環境，許多任務同樣無法進行。

未來 Agent 進入企業，也會遇到這兩道門檻。

它需要一個執行任務的環境，也需要一套存取業務系統的授權機制。 前者可以由 sandbox，也就是沙箱提供；後者則是 OpenConnector 這類連接與鑑權閘道所處理的問題。

這兩層基礎設施，決定了一個有能力的 Agent，能否真正參與企業的日常工作。

從回答問題，到承擔一份工作

企業中有價值的任務，往往跨越多個系統。

假設你讓 Agent 為明天的客戶會議做準備：查看行事曆中的與會者，查閱最近幾封往來郵件，從 CRM 整理客戶進度，再把討論事項寫進會議文件。

這既需要理解與判斷，也需要實際存取系統。Agent 要知道去哪裡找資料、使用哪個帳號、哪些內容可以讀取，以及結果可以寫到哪裡。

若進一步要求它更新客戶狀態、寄出會議邀請，權限需求也會改變：可以查閱客戶資料，不代表可以修改商機；可以讀取郵件，也不代表可以代公司寄信。

我們在討論 Agent 資料安全時提過：充分的業務脈絡，才能讓 Agent 考慮周全。下一步要回答的是，企業如何把這些資訊與操作能力交給它。

人類員工透過帳號、角色和權限進入系統。Agent 同樣需要明確的存取邊界。

沙箱是 Agent 的工作電腦

員工在電腦上執行軟體，Agent 則需要相應的執行環境。

它可能要執行程式碼、處理試算表、產生檔案，或操作瀏覽器。沙箱提供受限制的環境，約束程式能接觸的檔案、程序與網路資源。隔離程度取決於實作與設定。Anthropic 的沙箱工程說明介紹了檔案系統與網路隔離在 Agent 執行中的作用。

這有點像企業配發電腦：提供工具，也訂出裝置上的工作邊界。

但電腦能執行程式，並不會自動取得財務系統的權限。沙箱能執行程式碼，也不會自動獲得 CRM 或 OA 的合法存取權。

沙箱回答的是：Agent 在什麼環境執行任務，這個環境允許它做什麼？

存取業務系統，還需要另一層基礎設施。

鑑權閘道是識別證背後的門禁系統

識別證代表身分，門禁系統決定這張證件可以開啟哪些門。企業軟體中的帳號、角色與授權，也在做類似的事。

對 Agent 而言，連接與鑑權閘道承擔其中一部分職責：管理應用程式連接與憑證、檢查呼叫權限，再將獲准的操作送往目標系統。

「連上一個應用程式」只是起點。長期可用的存取方式，還要回答：

• 這次使用誰的帳號，代表誰執行？
• 可以讀取哪些資訊，執行哪些寫入？
• 第三方帳號憑證存在哪裡，由誰保護與更新？
• 呼叫失敗時，能否查到原因與紀錄？
• 任務結束或職責改變後，如何收回存取能力？

若把所有應用程式金鑰直接放入 Agent 環境，這些問題就會散落在各種指令碼、設定與部署中。換一次模型或執行環境，團隊可能又要重新盤點。

閘道提供集中處理連接與授權的邊界。Agent 透過獲准的介面送出請求，第三方原始憑證由閘道管理，操作在執行時接受檢查。

「請只讀取資料」可以寫進任務指示；「這次呼叫沒有寫入權限」需要系統落實。 這層約束，讓企業能逐步交付實際操作。

兩層邊界，保護不同的地方

沙箱與鑑權閘道可以共同運作。

概念架構示意：呈現一條經閘道呼叫應用程式的路徑。各層約束不同邊界，實際能力取決於部署與設定。

基礎設施	員工到職的比喻	主要問題
沙箱	工作電腦	在哪裡執行程式碼、處理檔案與任務
連接與鑑權閘道	識別證背後的門禁系統	使用哪個帳號，獲准呼叫哪些業務介面

程式即使一直待在沙箱，也可能透過允許的網路連線向外部系統送出請求。若它持有可刪除客戶紀錄的憑證，沙箱本身不會知道這次刪除是否符合業務職責。

反過來，應用程式呼叫經過閘道，也不代表本機下載的檔案、執行的指令碼與暫存產物都已受到管理。這些仍需要適當的執行環境。

因此，企業要同時管理執行環境與系統入口。對需要執行程式碼、處理檔案和跨系統操作的 Agent，這兩層尤其重要。

企業落地也需要身分管理、任務編排、審批與結果驗收。並非所有 Agent 都需要獨立沙箱，有些任務只透過受控 API 即可完成。電腦與識別證的比喻，凸顯的是執行能力，以及被授予的業務存取能力。

為什麼連接與鑑權閘道值得長期關注

展示時，一次成功呼叫就能呈現 Agent 的潛力。企業持續使用時，則要考慮多個 Agent 能否以不同帳號、不同職責，長期穩定地使用同一批系統。

今天由一個助理整理客戶資料，明天換成另一個模型，之後再加入處理訂單的 Agent。OA、CRM、文件與郵件系統通常仍在，連接設定、授權邊界與維護工作也會延續。

若每個 Agent 都獨立接入，企業就會重複處理介面適配、憑證保存、權杖過期、操作限制與失敗排查。

把這層做成可重用的基礎設施，新 Agent 就能沿用既有連接，再依職責取得權限。開發者能把時間投入業務流程，企業也更容易維持一致規則。

這是我們看重這個方向的原因。當 Agent 開始承擔真實工作，連接與授權就成為持續存在的需求。

對開發者，這是值得投入的公共工程；對企業，這是值得預先規劃的架構邊界；對研究 Agent 產業的投資者，這也是值得理解的基礎設施方向。其長期價值，在於能否減少重複接入、支援跨任務重用，並持續承擔連接、權限與維運責任。

OpenConnector 正在建設這一層

OpenConnector 是 OOMOL 維護的開源連接閘道，管理應用程式連接與憑證，透過 SDK、CLI、MCP 與 HTTP 提供可呼叫的操作。

Agent 或可信任的後端選擇操作與連接後，閘道檢查呼叫憑證和操作策略，再使用對應帳號憑證請求目標應用，回傳結果。

開發者可以查看操作定義、輸入參數與所需授權範圍，在自行部署的環境中設定允許或禁止的操作，透過去識別敏感資訊的執行紀錄排查問題。公開的執行環境、操作定義，以及可在本機執行的處理程式，讓團隊能檢查與擴充呼叫路徑；個別操作的本機執行支援仍需確認。詳見 OpenConnector 文件。

閘道策略要與原應用帳號權限、授權範圍一起生效。帳號能看到哪些客戶紀錄，仍取決於來源系統；寄信也可能需要業務流程中的人工確認。完整的身分與審批體系，需要與閘道配合。

團隊可先用 OOMOL 託管服務接通業務，或自行部署 OpenConnector，管理自己的閘道、憑證與環境。選擇方式見部署指南。

這層基礎設施，值得一起建設

企業軟體接入需要長期維護。各服務的授權方式、參數、錯誤訊息與限制都不同；介面會變、權杖會過期，企業也會增加應用程式與內部系統。

許多工作可以共同受益。修好連接器的分頁問題，其他團隊也能使用；補齊操作所需的授權範圍，後續開發者就少一次排查；公開執行邏輯，其他人便能檢查、修正，再部署到自己的環境。

這就是開源閘道的意義：讓各家公司反覆投入的連接工作，累積成整個生態都能使用的能力。

開放的連接層，也保留更多選擇。Agent 可以演進、模型可以更換，連接能力仍可透過公開介面與實作繼續使用。需要掌控環境的團隊，也有程式碼可讀、有部署方式可循。

開源提供檢查、修改與共同維護的條件。安全仍需程式碼審查、正確設定與持續維運，第三方 API 的授權和使用條款也仍然適用。共建的價值，來自這些具體工作不斷完成與重用。

為下一位「數位同事」準備好到職條件

把 Agent 當成即將到職的新同事，先問：它在哪裡工作？能進入哪些系統？可以讀取什麼、修改什麼？

這些問題有了能落實的答案，企業才能逐步交付更有價值的任務。

我們希望 OpenConnector 成為這套基礎設施的一部分，也歡迎更多開發者參與。從每天使用的應用程式開始：新增需要的操作、修復授權問題、完善參數定義，或回報部署經驗。

前往 OOMOL 官網了解產品與接入方式。希望先驗證業務的團隊，可以在 OOMOL Console連接一個應用程式，從範圍明確的讀取操作開始。

Agent 進入企業，需要工作環境，也需要在合適的權限下進入業務系統。我們選擇從這扇門開始，與社群一起建設。