📌 本文重點
- Workspace Agents 提供雲端代管的 Agent runtime + 沙箱
- 核心是 Draft → Approve → Execute 的 human-in-the-loop 控制
- 工具要設計成小顆、受限、可審計且避免無邊界能力
- 適合 80% 自動化交給雲端，20% 關鍵邏輯留在自家後端
對有後端與自動化經驗的開發者而言，Workspace Agents 解決的痛點很明確：
- 從「單輪聊天」升級成「可長時間運行、多步工作流」，不必自己寫一套 Agent loop。
- 內建安全沙箱與權限邊界，降低「Claude
dangerouslyDisableSandbox這種黑箱工具調用」的風險。 - 把 REST / GraphQL / DB / SaaS 都工具化給 Agent 調用，但仍保留 Draft → Approve → Execute 的 human-in-the-loop 控制。
實際上，它更像「雲端版、LLM 驅動的 Zapier/Make + 任務協調器」，而不是另一個 custom GPT 皮膚。
重點說明：Workspace Agents 的技術定位
1. 與 custom GPT / Zapier / 自建 Agent 的差異
技術定位可以粗略想成：Codex + Agent Loop + Workspace Sandbox：
💡 關鍵： Workspace Agents 把模型、Agent loop、沙箱與 Workspace 權限綁成一個整體，用「雲端代管 runtime + 工具」取代你自建大部分基礎設施。
- 比 custom GPT 多了什麼？
- custom GPT：偏向「有工具的聊天介面」。
-
Workspace Agents：
- 可以在 Workspace 中持續跑任務、排程、被 webhook 喚醒。
- 有雲端執行環境與持久可觀測的 run log。
- 官方提供 Responses API / WebSocket 來優化 agentic workflow 延遲（參考官方 Speeding up agentic workflows with WebSockets）。
-
與 Zapier / Make 的差異：
- Zapier：流程是你設計的 BPMN / if-else pipeline。
- Workspace Agents：流程邏輯多數下放給 LLM（Codex）動態決策，你提供工具與邊界，它決定如何串。
-
適合「規則不好寫死」「工具多變」的情境，例如支援 slack + CRM + 自家 API 的 case routing。
-
與自建 Agent framework 的取捨：
- 自建（LangGraph 等）：
- 優點：可以完全控制 state、工具調用實作、私有部署。
- 缺點：你得自己處理 agent loop、tool sandbox、觀測/重試、延遲優化。
- Workspace Agents：
- 優點：基礎設施（loop + sandbox + 日誌）官方代管，直接在 ChatGPT Workspace 與 API 共用。
- 缺點：可程式化程度受限，適合「80% 流程交給雲端 Agent，20% 自家後端收尾」的架構。
2. 安全沙箱與權限邊界設計
Workspace Agents 強調：工具調用是顯式、受限、可審計的。
- 工具（tools）以 JSON schema / OpenAPI 宣告，Agent 只能調用你掛進去的 endpoint。
- 雲端沙箱環境與 Workspace 權限綁定：
- 不會給 Agent 任意 Bash / file system 的 root 權限。
- 沒有類似 Claude
dangerouslyDisableSandbox的逃逸入口——除非你自己提供一個「超能力」工具。 - 每次工具調用都會留在 run log，方便你做：
- 事後審計：誰在什麼 prompt 下觸發了哪個工具？
- 風險回滾：出錯時可以重播 / 重跑某一段工具調用。
關鍵心態：視每一個工具就是一個受限 microservice，不要把 root 能力直接丟給 LLM。
3. 可放手跑又可觀測的多步工作流
Workspace Agents 的核心是：LLM 掌管控制流，你負責設計工具與觀測面板。
典型 pattern：
- Agent 接到任務（由 ChatGPT UI、API 或 webhook 觸發）。
- 根據 system / instructions 決定要走 Draft → Approve → Execute：
- Draft：只產生計畫與待呼叫工具清單。
- Approve：把計畫送到 Slack / UI Approver 確認。
- Execute：得到人類批准後，才真正呼叫具破壞性的工具（寫 DB、呼叫付款 API）。
- 全程透過 Workspace console 的 run timeline + tool call log 觀測，必要時人工接管。
實作範例：從工具封裝到 human-in-the-loop
以下用「客服回饋彙整 + 建議調整 CRM 標籤」的 workflow 示範。
1. 把內部 REST / GraphQL / DB / SaaS 包成工具
以 OpenAI Responses API 工具宣告風格為例（概念 YAML，可轉成 JSON）：
# tools.yaml
- name: get_tickets
description: 依條件查詢最近的客服 ticket
type: function
parameters:
type: object
properties:
status:
type: string
enum: [open, closed]
limit:
type: integer
default: 50
required: [status]
- name: update_crm_tag
description: 更新單一客戶的 CRM 標籤（具破壞性操作）
type: function
parameters:
type: object
properties:
customer_id:
type: string
tags:
type: array
items:
type: string
required: [customer_id, tags]
在你的後端將這些工具綁到實際 REST / GraphQL / DB：
// pseudo-code: Node.js express + Responses API
import { openai } from "./openai-client";
const tools = [/* 載入上面的 schema 並加上實作 mapping */];
app.post("/agent-run", async (req, res) => {
const response = await openai.responses.create({
model: "gpt-4.5-codex", // 假想 agent-capable 模型
input: req.body.input,
tools,
tool_choice: "auto",
metadata: { workflow: "support-crm-pipeline" }
});
res.json(response);
});
後端實作端要特別注意：
- 每個工具實作中再做一次權限檢查（不要只信任 LLM）。
update_crm_tag類工具要有 rate limit + audit log。
2. Draft → Approve → Execute 的 human-in-the-loop
核心策略：讓 Agent 自己知道有些工具需要「approval_token」才可調用。
在 system message 給 Agent 清楚規則：
{
"role": "system",
"content": [
{
"type": "text",
"text": "你是客服自動化 Agent。分三階段：\n1) Draft: 分析 ticket 並產生建議標籤與修改計畫，只能使用 get_tickets 工具。\n2) Approve: 把計畫整理成給主管看的摘要，等候 'APPROVED' 再進入 Execute。\n3) Execute: 收到 'APPROVED' 且被注入 approval_token 後，才可以呼叫 update_crm_tag。\n永遠不要在沒有 approval_token 的情況下更新 CRM。"
}
]
}
在你的後端把它拆成兩個 call：
// 1) Draft + Approve（不給具破壞性工具）
const draftRun = await openai.responses.create({
model: "gpt-4.5-codex",
input: [systemMsg, userMsg],
tools: [getTicketsTool], // 不提供 update_crm_tag
tool_choice: "auto"
});
// 將 draftRun 的摘要貼到 Slack 請主管確認...
// 2) Execute（確認後，才開啟 update_crm_tag）
if (approved) {
const executeRun = await openai.responses.create({
model: "gpt-4.5-codex",
input: [
systemMsg,
{ role: "user", content: "APPROVED" },
{ role: "user", content: `approval_token=${approvalToken}` }
],
tools: [getTicketsTool, updateCrmTagTool],
tool_choice: "auto"
});
}
重點：
- 把「是否提供具破壞性工具」交由你自己的後端邏輯控制，而不是讓 Agent 用 prompt 自己約束自己。
- 所有更新操作都帶上
approval_token寫進你的 DB audit log，避免 model 任意重放。
3. 避免「dangerouslyDisableSandbox」類踩坑
Claude 事件的教訓：只要給了「無邊界」工具，LLM 就有機會做出你沒預期的事。
在 Workspace Agents / Responses API 這邊，實務建議：
- 禁止提供「泛用 shell / eval 工具」：
- 不要暴露
bash,python_exec,sql_anywhere這種萬能工具。 -
改成一組小顆、專用的工具，例如
run_migration_v3,reindex_search,rotate_api_key。 -
工具 schema 要明確描述風險（給人看也給 LLM 看）：
json
{
"name": "delete_user_data",
"description": "刪除單一使用者的所有歷史資料。不可回復。僅能在取得法律與 DPO 批准後執行。",
"parameters": {
"type": "object",
"properties": {
"user_id": { "type": "string" },
"approval_token": { "type": "string" }
},
"required": ["user_id", "approval_token"]
}
}
- 在工具實作層再做一次 guardrail：
- 檢查
approval_token是否有效、是否對應到正確的人與工單。 -
加冷卻期（例如同一 user 一天只能刪一次）。
-
關閉「自動 approve 所有工具調用」模式：
- 即使官方後續提供「自動工具批准」選項，也建議：
- 讀操作（GET）可 auto。
- 寫操作（POST/PUT/DELETE）一律走 Draft → Approve → Execute。
建議與注意事項：選 Workspace Agents 還是自建？
1. 適合用 Workspace Agents 的情境
優先考慮 Workspace Agents，當你的需求符合：
- 已經在用 ChatGPT Business / Enterprise，想把同一 Workspace 的知識、權限、Slack/Email 整合起來。
- 需求是：「把一堆 SaaS + 內部 API 串起來」而非「打造高客製 agent runtime」。
- 對延遲有要求，但可以接受雲端模型：
- 可透過 WebSocket Responses API 降低 agent loop latency。
成本角度（參考 Reddit 測試技能對弱模型的增益）：
- 即使使用較便宜模型（類似 Haiku 與 Opus 的對比），
- 配上好的工具／技能，整體成功率與成本效益高於單純用 SOTA 模型硬算。
- Workspace Agents 把「技能裝配」這件事標準化，適合用中價位模型跑高頻自動化任務。
💡 關鍵： 把工作拆給中價位模型 + 精心設計工具，往往比單靠最頂級模型更划算且穩定。
2. 應該自建 Agent framework 的情境
考慮自己用 LangGraph / 自家框架時機：
- 需要 嚴格的 on-prem / VPC 隔離，無法把工作流丟到公有雲。
- 工作流高度客製：
- 複雜 state machine、multi-agent negotiation、需要自訂 checkpoint / replay / saga pattern。
- 你需要直接控制 agent loop 實作、序列化、快取策略（例如結合你自己的向量 DB 與 RAG 策略）。
折衷做法：
- 把 Workspace Agents 當作「前台協調層」，負責與人互動、排程、通知。
- 真正複雜的決策與計算交給你自己的後端 / RAG 服務：
- Agent 只調用一個
call_internal_orchestrator工具， - 由你自己的系統決定要不要再 call 其他 model / search / DB。
3. 與現有 RAG / 後端服務整合的最佳實踐
- RAG 放在你自己那一側，不要讓 Agent 直接 query 各種向量庫：
- Agent 工具：
query_kb({ question })→ 你的 RAG API。 - 由你決定使用什麼模型、什麼 chunking、什麼 embedding。
- 這樣有幾個好處：
- 成本可控：RAG 的 embedding / search 模型可自由替換為更便宜或自建方案。
- 安全可控：哪些 index 可被哪個 Agent 用，由你自己的 ACL 管。
總結：
- Workspace Agents = 雲端 Agent runtime + Sandbox + Workspace 權限整合，把原本你得自建的 Agent framework 一大塊打包好給你。
- 開發者真正要做的是：
- 設計好小顆、邊界清楚的工具，
- 用 Draft → Approve → Execute 把高風險操作關進籠子，
- 把 RAG / 複雜邏輯放在你可控的後端。
💡 關鍵： 把 80% 可標準化流程交給 Workspace Agents 跑，關鍵 20% 風險與業務邏輯留在自家後端，是多數團隊較實際的架構選擇。
如果你目前已經在寫一堆「LLM + Zapier + 自家 webhook」的 glue code，Workspace Agents 值得你直接開一個 Workspace，把一條現有流程搬進去試跑，從觀測與權限開始收斂架構。
🚀 你現在可以做的事
- 選一條既有「LLM + Zapier / Make + webhook」流程，畫出其中所有工具與權限邊界，準備搬進 Workspace Agents
- 把內部 REST / GraphQL / DB / SaaS API 列表整理成工具 schema 構想（含風險等級與是否需要
approval_token）- 在測試 Workspace 中實作一個 Draft → Approve → Execute 的小流程，實際觀察 run log 與工具調用行為