標籤: ChatGPT

📌 本文重點

• Workspace Agents 提供雲端代管的 Agent runtime + 沙箱
• 核心是 Draft → Approve → Execute 的 human-in-the-loop 控制
• 工具要設計成小顆、受限、可審計且避免無邊界能力
• 適合 80% 自動化交給雲端，20% 關鍵邏輯留在自家後端

對有後端與自動化經驗的開發者而言，Workspace Agents 解決的痛點很明確：

1. 從「單輪聊天」升級成「可長時間運行、多步工作流」，不必自己寫一套 Agent loop。
2. 內建安全沙箱與權限邊界，降低「Claude dangerouslyDisableSandbox 這種黑箱工具調用」的風險。
3. 把 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：

1. Agent 接到任務（由 ChatGPT UI、API 或 webhook 觸發）。
2. 根據 system / instructions 決定要走 Draft → Approve → Execute：
3. Draft：只產生計畫與待呼叫工具清單。
4. Approve：把計畫送到 Slack / UI Approver 確認。
5. Execute：得到人類批准後，才真正呼叫具破壞性的工具（寫 DB、呼叫付款 API）。
6. 全程透過 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 這邊，實務建議：

1. 禁止提供「泛用 shell / eval 工具」：
2. 不要暴露 bash, python_exec, sql_anywhere 這種萬能工具。

3. 改成一組小顆、專用的工具，例如 run_migration_v3, reindex_search, rotate_api_key。

4. 工具 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"]
}
}

1. 在工具實作層再做一次 guardrail：
2. 檢查 approval_token 是否有效、是否對應到正確的人與工單。

3. 加冷卻期（例如同一 user 一天只能刪一次）。

4. 關閉「自動 approve 所有工具調用」模式：

5. 即使官方後續提供「自動工具批准」選項，也建議：
   • 讀操作（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 與工具調用行為