後臺發現、任務執行和對外承諾，需要三套不同的規則。
2026 年 9 月 29 日，OpenAI 釋出 Dots：擁有自己的雲電腦、能持續處理專案、會從反饋中學習的常駐 Agent。官方稱它由 GPT-6 Astra 驅動，透過外掛生態可連線超過 4,000 個應用，並能在 ChatGPT、Slack 和 Teams 中接收任務、攜帶脈絡。
這次變化落在工作關係上。普通聊天的節奏是“人提出問題，AI 給出回答”；Dots 描述的節奏則是“人給出目標與標準，Agent 持續推進，把成果和需要判斷的問題帶回來”。如果團隊採用這種方式，任務不會隨著視窗關閉而自然結束，原本靠人盯著的步驟也需要明確的規則。
但“持續線上”並不是一種不受限制的行動許可權。Dots 的後臺主動研究、正在執行的任務、組織試點中的專職 Dot，各有不同邊界。先分清這些邊界，才能判斷該交出哪一部分工作。
Dots 把“聊天之外的工作”放到了產品中心
OpenAI 的釋出頁給出了幾個具體場景：開發者的 Dot 從客戶反饋裡發現重複問題，準備修復、測試和帶影片的 PR；產品負責人收到範圍變化後，Dot 更新發布材料；銷售負責人面對客戶要求變化時，Dot 對照產品文件、準備概念驗證與測試計劃，再把未解決的問題交回來。
這些例子有一個共同點：交付物不是單獨一條回答，而是一組相互依賴的產物。修復程式碼需要測試，釋出材料需要跟著產品範圍變，銷售方案需要跟著驗證結果變。Agent 要保留目標、來源、當前進度和人的修改，而不是每一步都等待重新解釋。
這也是自己的雲電腦和跨渠道脈絡有價值的地方。使用者可以開啟 Dot 的電腦檢視工作，也可以選擇讓它連線自己的裝置。在 ChatGPT 發起的專案，可以在 Slack 中繼續討論；官方說 Dot 會跨渠道攜帶脈絡。這裡應把“產品提供這種機制”和“具體公司已經穩定跑通”分開：釋出頁裡的業務場景是 OpenAI 對產品用法的介紹，不是各行業都有同樣成效的證明。
最容易混淆的，是後臺研究與任務執行
Dots 官方把使用者沒有主動與它工作時的後臺行為稱為 proactive research。這時，Dot 可以從已連線的應用尋找有用的資訊，但工具被限制為只讀：不能發訊息、修改應用內容，不能操控瀏覽器或電腦。
另一方面，釋出頁也描述了 Dot 透過自己的電腦和瀏覽器執行專案。兩段說明並不衝突：後臺自主找線索與使用者交付的執行任務，不是同一種工作狀態。
例如，Dot 從資料中發現“這個客戶可能漏開發票”，屬於發現問題；準備發票草稿屬於形成交付物；把發票傳送給客戶則是對外動作。OpenAI 的早期測試案例明確寫了最後一步發生在使用者批准之後。不能因為有這個案例，就推斷所有後臺發現都能自動觸發傳送。
團隊需要給 Agent 的不是一句“別做危險的事”，而是每類動作的可執行範圍。連線哪個應用，只解決了它能接觸什麼；允許哪些動作，才決定它能改變什麼。
連線許可權、動作規則與成果稽核，是三道不同的關
第一道是資料與系統的訪問範圍。 使用者透過既有 ChatGPT 應用控制管理 Dot 的連線與許可權。即使某項資料有助於任務，也不代表應把整個業務系統開放給它。先列出完成目標所需的最小來源，避免把“可能有用”當作訪問理由。
第二道是動作放行。 Dots 從內建規則開始，Custom Rules 可以允許具體動作、要求批准或阻止動作；內建安全要求仍然有效。官方還介紹了 auto-review：涉及賬號影響或資訊共享的動作，會根據指令、Custom Rules 和安全要求檢查，決定能繼續、需要批准還是必須由人完成。修改密碼這類敏感任務仍由人處理。
第三道是交付物本身的正確性。 系統判斷某個動作可以執行，不代表發票金額、客戶要求、釋出文案一定正確。OpenAI 也提醒要稽核重要工作。對業務負責人來說，審批按鈕前應看到的不只是“是否傳送”，還有來源、關鍵變化、尚未驗證的事實和影響物件。
一個客戶提案可能格式完整、許可權正確，卻包含尚未驗證的整合承諾。動作稽核與業務驗收解決的是兩種問題，團隊需要同時設計。
從一份客戶提案開始，而不是把整個部門交出去
下面是一個建議的任務設計，不是已經測得效率的案例：銷售團隊需要隨著客戶的技術要求更新方案，但不允許 Agent 自動承諾交付日期或寫回 CRM 商機階段。
任務可以這樣拆：
- 確定輸入。 給出本輪客戶需求、已確認的產品說明、上版提案和當前測試記錄。指定哪份記錄是最新版本，並標註不能共享給客戶的內部資料。
- 定義持續工作。 有新要求時，對照已有能力找差異，更新提案草稿和測試清單。沒有證據的能力保留為問題，不改寫成已支援。
- 規定成果位置。 每輪交付包含一份可閱讀的提案、一張變更表、一份未解決問題清單。原始來源與草稿分開儲存，方便逐項核對。
- 劃出動作邊界。 內部草稿允許準備；外部郵件、報價、交期承諾和 CRM 狀態變更由指定負責人確認。具體可執行規則仍需按實際產品能力配置，不能把這份設計當作現成許可權模板。
- 驗收關鍵事實。 解決方案工程師檢查整合與測試，銷售負責人檢查商務承諾。稽核意見必須回到下一輪任務，而不是隻留在一條無關聯的聊天訊息裡。
這樣交付的好處是：負責人不用逐段指導起草，卻仍能檢查“哪裡變了、依據是什麼、有哪些問題”。若 Agent 只能給出一份漂亮提案，無法展示證據與未決項，就還沒有滿足這個任務的驗收要求。
specialist dots 還不能直接理解成通用“AI 員工”
釋出頁還預告了組織專職的 specialist dots：公司給每個 Dot 配置獨立身份、憑據和系統訪問，讓它承擔明確職責。OpenAI 提到採購、發票處理、郵件營銷、客戶支援和商業合同的早期內部探索，並表示從聚焦的企業試點開始。
這與當前使用者的主 Dot 有不同的管理問題。個人 Dot 代表一個人工作；組織專職 Dot 涉及崗位許可權、系統記錄和跨團隊責任。OpenAI 與 Microsoft Agent 365 的合作目標，是把這些 Dot 接入企業既有治理與安全控制。釋出頁沒有把這項整合描述成每個賬號都可以立即啟用的完整服務。
判斷企業試點是否適合自己，應該先問：職責是否足夠窄，訪問範圍能否確定，失敗時能否暫停，結果有沒有負責驗收的人。沒有這些條件，只是給 Agent 一個崗位名稱，並不會讓工作自然可靠。
在持續工作空間裡，先把一個流程驗收清楚
Buda 的 Agent Workspace 把會話、Drive、終端、瀏覽器和 Git 放在同一工作空間；持續檔案使 Agent 能從已有資料和產物繼續工作，使用者也能檢查執行過程與結果。適合先從一個有明確輸入和成果的任務開始，例如維護提案草稿與待驗證清單。
在這類任務中，Buda 承接資料整理、工具執行與可檢查產物。流程穩定後，可以把方法沉澱為 Skill；可安裝的 Skill 可以在 Buda AI 的 Marketplace 搜尋並安裝。需要按時間重複執行的工作再使用 Automations。檔案留存、可複用指令、定時啟動分別解決不同問題，不能用“已經自動化”代替業務驗收。
先安排一輪手動觸發的完整任務，確認來源、輸出和負責人都清楚，再增加持續執行。這比一開始就承諾全天候自主處理全部工作更容易定位錯誤。
常見問題
Dots 全天線上，意味著所有動作都能在後臺自動執行嗎？
不是。官方明確限制後臺 proactive research 的工具為只讀。執行任務時，還要考慮應用許可權、內建規則、Custom Rules 與動作稽核。應該按具體狀態和動作判斷，而不是從“24/7”推斷許可權。
Activity View 和人工驗收有什麼區別？
Activity View 用於瞭解進展，包括後臺工作，並可重新引導 Dot。人工驗收則要檢查關鍵事實、計算和承諾。看見它執行過某一步，有助於追蹤過程，但不能替代對成果的判斷。
哪些套餐可以開始使用？
按 9 月 29 日釋出說明，Dots 在合格市場向 Pro 和 Business Premium 逐步推出；Enterprise（包括 Edu 與 Healthcare）由工作區管理員啟用 beta。官方稱首個 Dot 包含在 Pro 或 Business Premium 中，深度工作有額度，Codex 或 ChatGPT Work 任務仍按各自規則計入使用量。具體賬號應核對當前開放情況，不能把“首個 Dot 包含在套餐”理解為所有執行都無限量。
團隊第一輪試驗該記錄什麼？
記錄已交付與未交付的任務、需要人工修正的事實、因許可權或規則停下的動作，以及最終稽核人花在哪些步驟。先看哪些錯誤重複發生，再調整範圍或標準；不要僅用生成檔案的數量評價 Agent。
來源與延伸閱讀
資料核對日期：2026-09-30。Dots 的能力與開放範圍依據 OpenAI 釋出說明；客戶提案流程為本文建議的任務設計，未宣稱雙方效能等同，也未進行效率實測。