AI 員工怎麼做？用 Claude Managed Agents 建企業第一個數位員工（2026 實作教學）

AI 員工怎麼做？最短的答案是：寫一份職務說明書、給它一間有工具的辦公室、派任務給它、幫它排班，然後指定一位主管在關鍵動作上簽核。2026 年 4 月 Anthropic 把這五件事做成了 API，叫做 Claude Managed Agents，你不必再自己寫 agent loop、架 sandbox、處理工具執行。

這篇是實作教學。前半段先釐清 AI 員工與聊天機器人的差別、Managed Agents 的四個概念，以及什麼情況該託管、什麼情況該自建；後半段用五個步驟建一個「每週自動整理資料並產出報告」的數位員工，最後算它一個月要花多少錢。

操作段落整理自 Claude 官方文件，查證日期為 2026 年 10 月 13 日。Managed Agents 仍在 beta，欄位與行為可能調整。文中第一手經驗來自我們公司用 Claude Agent SDK 自架的 AI 小編系統，以及在地端嘗試 OpenClaw 的過程，會明確標示，不會把它們寫成 Managed Agents 的實測。

AI 員工跟 Chatbot、AI Agent 差在哪？為什麼 2026 年可以「用 API 聘一個」

AI 員工是能獨立跑完一段流程、有固定職責、有權限邊界、能被排班、出錯時有人負責的 AI Agent。聊天機器人等你問才答，AI Agent 會自己用工具，AI 員工則多了「在組織裡的位置」。

這個差別決定了你需要哪些基礎設施。聊天機器人只要一個 API 呼叫；Agent 需要工具執行與迴圈；AI 員工還需要持久的工作狀態、排程、審批與帳務歸屬。更完整的概念比較可以看 AI 員工是什麼？數位員工 vs AI Agent，這裡用一張表把「要建它需要什麼」對起來。

面向	聊天機器人	AI Agent	AI 員工
觸發方式	人問才答	人給任務	人給任務，或排班自動啟動
工作狀態	單輪對話	單次任務內	跨任務持久（檔案、歷史、偏好）
權限	無	可呼叫工具	工具有分級，部分動作需審批
誰負責	無	開發者	指定的「主管」與預算擁有者
需要的基礎設施	一個 API	agent loop、工具執行	再加 sandbox、排程、審批、帳務

我們公司半年多前用 Claude Agent SDK 自己寫了一套文章撰寫系統，跑在公司的一台 Mac Mini 上。它依題目自動研究、撰寫、出圖，完成後小編審稿，一鍵發布到我們經營的好幾個官網。內部的說法很直接：我們多了一個 AI 小編。它有固定職責（寫文章）、有產出去處（官網）、有主管（小編），這就是 AI 員工，而不是一個會聊天的工具。

判斷你做的是不是 AI 員工，問一個問題就夠了：它不在的時候，有沒有一件固定的事會沒人做？

Claude Managed Agents 是什麼？Agent、Environment、Session、Events 四個概念

Claude Managed Agents 是 Anthropic 託管的 agent harness：你定義員工與辦公室，Anthropic 負責跑迴圈、執行工具、保存狀態、串流回報。官方文件把它定位在「長時間執行與非同步工作」，與直接呼叫 Messages API 自建迴圈相對。

四個概念可以直接對應到「聘一個人」的流程：

概念	官方定義	聘人的對應
Agent	模型、system prompt、工具、MCP 伺服器、skills	職務說明書：這個人是誰、會什麼、能碰什麼
Environment	session 執行的地方：Anthropic 託管的雲端 sandbox，或你自架的 sandbox	辦公室：有哪些軟體、能連哪些網路
Session	在某個 environment 裡跑的 agent 實例，執行一個特定任務	一次交辦的工作
Events	你的應用程式與 agent 之間的訊息：使用者回合、工具結果、狀態更新	工作回報與主管指示

圖 1：Claude Managed Agents 的四個概念如何組成一個 AI 員工

graph TD
    APP[你的應用程式] -->|user.message 等事件| S[Session：一次任務]
    S -->|agent.message / tool_use / status 事件 SSE| APP
    A[Agent：職務說明書<br/>模型、system prompt、工具、MCP、skills] --> S
    E[Environment：辦公室<br/>雲端 sandbox 或自架 sandbox] --> S
    S --> T[內建工具<br/>bash、檔案讀寫、web search/fetch]
    S --> M[MCP 伺服器<br/>憑證存在 Vault]
    S --> C[自訂工具<br/>由你的程式執行]
    D[Scheduled Deployment：班表] -->|cron 到點自動建立| S

Agent 與 Environment 建一次重複使用；每次任務是一個 Session，透過事件雙向溝通。排班由 Scheduled Deployment 負責。

Harness 包含 prompt caching、compaction 等最佳化，sandbox 內建 bash、檔案讀寫、grep、glob、web search 與 web fetch。如果你讀過 Harness Engineering 是什麼？AI Agent 上線必備 11 個元件，會發現這些元件大多被 Anthropic 包掉了，你剩下要做的是職務設計與權限設計。

該用 Managed Agents，還是自己用 Agent SDK 或 Messages API 建？

能用 API 連到目標系統、任務會跑幾分鐘到幾小時、需要排程與持久狀態、又不想自己養 sandbox 的，用 Managed Agents。需要控制迴圈的每一步、有 Zero Data Retention 或 HIPAA 合規要求的，自建。

面向	自建（Agent SDK／Messages API）	Claude Managed Agents
Agent loop	自己寫、自己維護	Anthropic 託管
Sandbox 與工具執行	自己架	內建；也可自架 sandbox 接進來
狀態與歷史	自己存	伺服器端持久保存，可完整取回
排程	自己接 cron 或排程系統	Scheduled deployments 內建
預算上限	自己實作	Session budget 硬上限
資料保留	依 Messages API 規則，可申請 ZDR	目前不適用 ZDR 與 HIPAA BAA
控制度	每一步都能介入	透過事件 steer 與 interrupt
適合	迴圈邏輯特殊、合規嚴格、已有成熟 harness	想快速上線、任務長、要排班、不想養基礎設施

這裡有兩段我們自己的經驗，剛好落在表格的兩端。

第一段是自建成功的例子。前面提到的 AI 小編系統用 Claude Agent SDK 寫，大約一個禮拜就穩定，之後陸續加功能，至今用了半年多。當初不用 n8n 這類工具，是因為公司本來就有一台 Mac Mini 當伺服器，再用 n8n 等於又跑到外面，還要多維護一台伺服器。它同時接 Claude 與 OpenAI 的模型，不是為了備援，而是不同模型語氣不同、同樣的提示詞效果也不一樣，小編可以依文章需求選。

第二段是地端自建失敗的例子。今年我們在公司一台 16GB RAM 的地端機器上試著架 OpenClaw，斷斷續續弄了一兩個禮拜，試過 Qwen、GLM、Kimi、Gemma 4 這些本機模型。結果 RAM 不夠，效能差到無法順利運行；改接 Ollama Cloud 的模型是可以正常跑的。但公司內部評估的結論是：既然模型反正要跑在雲端，那不如直接用 Claude 或 ChatGPT，地端這台機器就沒有存在的理由了。於是我們放棄在公司內部養龍蝦，它從頭到尾沒有接上真實任務。更完整的評估框架在 企業該不該讓員工養龍蝦？OpenClaw 導入決策框架。

自建 harness 的理由只有兩個：你有自己非寫不可的迴圈邏輯，或你有非地端不可的合規要求。一旦模型決定用雲端，第二個理由就消失了一半。

Managed Agents 介於兩者之間：模型在雲端，harness 也在雲端，但職務設計與權限仍完全由你掌握。對我們這種「已經決定用雲端模型、不想再養 Mac Mini 上那層迴圈」的公司，它是合理的下一步。

Step 1：寫職務說明書，定義 AI 員工的職責與工具

第一步是建立 Agent：指定模型、寫 system prompt、決定它能用哪些工具。Agent 建一次，之後每個 session 用 ID 引用，而且有版本號，可以把 session 釘在特定版本做分階段上線。

所有 Managed Agents 的 API 都要帶 anthropic-beta: managed-agents-2026-04-01 這個 header，官方 SDK 會自動加。範例用 ant CLI 的宣告式寫法，一個 markdown 檔就是一份職務說明書：frontmatter 是設定，正文是 system prompt。

---
name: Weekly Data Reporter
model: claude-sonnet-5-5
tools:
  - type: agent_toolset_20260401
    default_config:
      enabled: false
    configs:
      - name: bash
        enabled: true
      - name: read
        enabled: true
      - name: write
        enabled: true
      - name: web_fetch
        enabled: true
---

你是公司的資料週報專員。每次任務：
1. 讀取 /workspace/inputs/ 下本週的 CSV 匯出檔。
2. 用 Python 計算各部門指標的週變化，異常值標記出來。
3. 產出 /workspace/report/weekly-report.md，含摘要、表格與需要主管決策的事項。
不要修改 inputs 目錄。沒有資料時回報「本週無資料」，不要用上週資料充數。

執行 ant apply weekly-reporter.md 就會建立 agent 並把 ID 記在 claude-lock.json。如果你習慣用 Claude Code，在最新版裡執行 /claude-api managed-agents-onboard 可以走一遍互動式引導。

幾個設計上的要點：

• 工具從全關開始，只開需要的。 agent_toolset_20260401 預設八個工具全開；用 default_config.enabled: false 關掉，再逐一開啟。週報員工不需要 web search，就不要給它。
• system prompt 寫職責、邊界與例外處理，不寫技術細節。 「沒有資料時回報，不要用舊資料」這種規則，是員工上線後最常救你一次的句子。
• 模型選便宜夠用的。 整理資料與寫報告用 Sonnet 5.5 就夠，Opus 留給需要判斷的工作。模型可以在建 session 時用 overrides 換，不必改 agent。

我們 AI 小編系統的 system prompt 也是這樣演化的。半年多來真正穩定下來後，幾乎不再出現寫錯事實或引用不存在來源的情況；偶爾出現的問題是方向跟小編想要的不一樣，調整一開始給的提示詞就能解決。換句話說，職務說明書寫得越像給新人的交接文件，後面的修正成本越低。

Step 2：建辦公室與第一個 session

Environment 定義 sandbox 怎麼建：是 Anthropic 託管的雲端容器還是你自架的，以及網路能連到哪。建好之後，用 agent ID 加 environment ID 開 session，送一個 user.message 事件，工作就開始了。

# environment.yaml
name: reporting-env
config:
  type: cloud
  networking:
    type: limited
    allow_package_managers: true
    allowed_hosts:
      - data-export.internal.example.com

limited 模式下，sandbox 裡的程式只能連套件管理站與 allowed_hosts 列的主機；web fetch 與 web search 雖然在 sandbox 外執行，也受同一份清單限制。沒列主機就等於拿不到任何網頁。需要資料駐留或連內網的，可以改用自架 sandbox，環境跑在你自己的基礎設施上。

接著開 session 並串流事件。用 Python SDK：

from anthropic import Anthropic

client = Anthropic()

session = client.beta.sessions.create(
    agent=AGENT_ID,
    environment_id=ENVIRONMENT_ID,
    title="本週資料週報",
)

with client.beta.sessions.events.stream(session.id) as stream:
    client.beta.sessions.events.send(
        session.id,
        events=[{
            "type": "user.message",
            "content": [{"type": "text", "text": "請產出本週的資料週報。"}],
        }],
    )
    for event in stream:
        match event.type:
            case "agent.message":
                for block in event.content:
                    if block.type == "text":
                        print(block.text, end="")
            case "agent.tool_use":
                print(f"\n[使用工具：{event.name}]")
            case "session.status_idle":
                print("\n完成。")
                break

三個細節會影響你的程式設計：

• 先開串流再送事件。 串流只會傳開啟之後的事件，順序反了會漏掉前幾個。
• 事件歷史在伺服器端。 斷線重連後可以用 list 取回全部，不必自己存。
• 可以建 session 時就帶第一個任務。 initial_events 讓 session 直接以 running 狀態建立，少一次呼叫，排程時就是用這個。

Step 3：讓它能登入公司系統：MCP connector 與 vault

AI 員工要碰公司系統，有三條路：自訂工具（agent 發請求、你的程式執行）、MCP 伺服器（透過 MCP connector 接外部工具），以及需要登入的 MCP 服務透過 vault 存 OAuth 憑證。vault 由 Anthropic 代管 token 更新，你在建 session 時傳 vault_ids 即可。

選哪一條，看目標系統的性質：

目標系統	建議路徑	原因
公司內部 API、資料庫	自訂工具	執行在你這邊，憑證不出公司
已有 MCP 伺服器的 SaaS	MCP connector	不用自己包工具
需要 OAuth 登入的 MCP 服務	MCP connector + vault	憑證集中管理，自動更新
沒有 API 的舊系統	不適合 Managed Agents	需要瀏覽器操作型的方案，例如 Grok Bot

自訂工具的寫法和 Messages API 的 client tool 一樣：在 agent 的 tools 加一個 type: custom，定義 input_schema；session 跑到那一步會暫停、發出 agent.custom_tool_use，你回 user.custom_tool_result 它再繼續。MCP 的部分，怎麼把一個 MCP 伺服器接進 Claude、接之前要設哪些護欄，Meta Ads MCP 串接教學有完整的例子；MCP 本身的企業導入考量見 MCP 是什麼？跟 API 差在哪？。

一個常被忽略的點：MCP 工具的預設權限政策是 always_ask，也就是每次呼叫都會暫停等你核准。這是對的預設，但如果你沒處理確認事件，session 會一直停在那裡。下一步就談這件事。

Step 4：誰當它主管？用 permission policy 設審批門檻

Permission policy 決定一個工具呼叫是直接執行、暫停等人核准，還是交給伺服器逐次判斷。三種值：always_allow、always_ask、auto。內建工具組預設 always_allow，MCP 工具組預設 always_ask。

設定寫在 agent 的工具設定裡，可以整組設，也可以逐一覆寫：

{
  "type": "agent_toolset_20260401",
  "default_config": { "permission_policy": { "type": "always_allow" } },
  "configs": [
    { "name": "bash", "permission_policy": { "type": "auto" } }
  ]
}

當某個呼叫需要核准，流程如下：

圖 2：一個需要審批的工具呼叫如何暫停、等待主管決定、再繼續

sequenceDiagram
    participant A as Agent（session）
    participant P as Anthropic 平台
    participant M as 主管（你的程式或人）
    A->>P: 要呼叫工具，例如 MCP 的「送出採購單」
    P->>P: 查 permission policy：always_ask
    P-->>M: agent.mcp_tool_use 事件
    P-->>M: session.status_idle，stop_reason=requires_action，附 event_ids
    M->>M: 看參數、決定
    M->>P: user.tool_confirmation {tool_use_id, result: "allow" 或 "deny"}
    P->>A: 執行（或回報被拒），session 回到 running

審批在執行前攔截，不是事後告警。被拒絕的呼叫 agent 會收到結果，可以改用別的方式或回報無法完成。

對應的程式只要處理一種事件：

for event in stream:
    if event.type == "session.status_idle" and event.stop_reason.type == "requires_action":
        for event_id in event.stop_reason.event_ids:
            decision = ask_manager(event_id)  # 你的審批邏輯：Slack 按鈕、後台頁面、規則引擎
            client.beta.sessions.events.send(
                session.id,
                events=[{
                    "type": "user.tool_confirmation",
                    "tool_use_id": event_id,
                    "result": "allow" if decision else "deny",
                }],
            )

審批門檻怎麼設，我們的經驗是關卡越少越好，但不可逆的那一個一定要有。AI 小編系統裡研究、撰寫、出圖全部自動，中間不會暫停問人；唯一的人工關卡是「發布」，小編審稿改稿大約十分鐘，然後按一下發到各個官網。半年多來從來沒有哪次差點出事，原因就是這個關卡一直在。對應到 Managed Agents，就是：工具組整體 always_allow，只有會寫入外部系統或對外發送的 MCP 工具與自訂工具設 always_ask；auto 留給 bash 這種「大多無害、偶爾危險」的工具，讓伺服器逐次判斷。

還有一個主管才有的權力：user.interrupt。送出後 agent 會停下來，再補一個 user.message 就能換方向。企業要的「人在迴圈上」而不是「人在迴圈裡」，大致就是這兩個事件。更廣的治理框架可以參考 企業 AI 治理與資安實戰指南。

Step 5：排班與零用金上限：scheduled deployments 與 session budget

Scheduled deployment 讓 agent 依 cron 排程自動開 session；session budget 則是每次任務的花費硬上限，到了就暫停。兩者加起來，AI 員工才算真的「排了班、領了零用金」。

排班一樣可以用 markdown 宣告，正文就是每次開工的第一句話：

---
name: Weekly data report
agent: agent_01XXXXXXXXXXXXXXXXXXXXXXXX
environment_id: env_01XXXXXXXXXXXXXXXXXXXXXXXX
schedule:
  type: cron
  expression: "0 8 * * 1"
  timezone: Asia/Taipei
budget:
  type: limit
  max_list_cost:
    amount: "300"
    currency: USD
---

請產出本週的資料週報，完成後把報告路徑放在最後一行。

幾個會影響營運的規則：

• cron 是 POSIX 五欄，時區用 IANA 名稱，最小粒度到分鐘。為了分散負載，實際啟動會加最多 9 分鐘的抖動，所以「8 點整」要理解成「8 點到 8 點 09 分之間」。
• 預算金額是「美分」的字串，"300" 代表 3 美元。deployment 的預算會複製到每一次 run，是每次的上限，不是累計上限。到達上限時 session 以 budget_reached 暫停；上限在模型請求之間檢查，所以最後一筆請求跑完才會停，實際花費可能略超過。
• 失敗會留紀錄。 每次觸發都會產生一筆 deployment run；環境或 vault 被封存、建 session 被限流，都會記成錯誤而且不重試，等下一次排程。環境或 vault 被封存時 deployment 會自動暫停等你修；agent 本身被封存時，deployment 會跟著自動封存。
• 每個組織最多 1,000 個 scheduled deployment。

排班之後要做的事只剩兩件：接 webhook 或定期查 deployment runs 看有沒有失敗，以及把 session 的最終輸出接回你的系統。怎麼把這類指標納入日常監控，見 AI Agent 評估與可觀測性實戰指南。

一個 AI 員工一個月要花多少錢？

Managed Agents 的帳單只有兩項：token 照 Claude API 標準價計費，加上 session 處於 running 狀態的時間，每 session-hour 0.08 美元。沒有另外的容器費，但也沒有 Batch API 折扣。

先列官方價格（2026 年 10 月，每百萬 token，美元）：

模型	輸入	輸出	適合的 AI 員工工作
Claude Opus 5.5	4	20	需要判斷、多步推理、寫程式
Claude Sonnet 5.5	2	10	整理資料、寫報告、一般流程
Claude Haiku 5.5（提示 10 萬 token 以內）	0.10	0.50	分類、抽取、簡單格式轉換
Session runtime	0.08／小時		只計 running，idle 不計

官方給的試算是：用 Opus 5 跑一小時、消耗 5 萬輸入與 1.5 萬輸出 token，總共 0.705 美元，其中 runtime 只佔 0.08。token 才是主要成本，所以模型選擇比跑多久重要。

套到前面的週報員工，用 Sonnet 5.5，假設每次任務跑 20 分鐘、輸入 15 萬 token、輸出 2 萬 token：

項目	計算	每次（美元）
輸入	150,000 × 2 ÷ 1,000,000	0.30
輸出	20,000 × 10 ÷ 1,000,000	0.20
Runtime	20 ÷ 60 × 0.08	0.03
合計		約 0.53

每週一次約 2.1 美元，每天一次約 16 美元。這是未計入 prompt caching 的保守估計，實際 token 量取決於你的資料大小。另外兩個會加價的情況：web search 每千次 10 美元；把 inference_geo 釘在美國推論時，token 按 1.1 倍計費。

我們自己的數字可以當另一個參考點，雖然它來自 Agent SDK 自架系統而不是 Managed Agents：AI 小編產一篇文章的模型費用不到 1 美元，大約 0.3 到 0.5 美元。以前一篇文章小編可能要花一個下午到一整天，陸陸續續修正、還要出圖；現在人只花約十分鐘審稿。這個量級的成本，讓「要不要讓 AI 做」根本不是財務問題，而是流程設計問題。

費用怎麼集中監控、怎麼分部門設額度，見 LLM API 成本集中監控指南；要進一步降低 token 用量，見 LLM Token 成本控管的 5 個實戰槓桿。

上線前要注意什麼？beta、資料保留與自架 sandbox

Managed Agents 目前是 beta，所有 API 帳號預設可用，但行為可能在版本間調整。最需要先過法務與資安的一點是：它目前不適用 Zero Data Retention，也不在 HIPAA BAA 的涵蓋範圍內。

原因是它的設計本來就是有狀態的：session 長時間存在、可以暫停後恢復、對話歷史、sandbox 狀態與輸出都存在伺服器端。你保有控制權，可以隨時用 API 刪除 session 與上傳的檔案，但「不存」這個選項目前沒有。

上線前的檢查清單：

1. 資料分類。 這個員工會碰到的資料，有沒有任何一類不能離開公司或不能被第三方保存？有的話，用自架 sandbox 讓環境跑在自己的基礎設施上，或把那段工作留給自建方案。
2. 網路白名單。 Environment 用 limited 模式並列出 allowed_hosts，不要用全開。
3. 權限清單。 列出每個工具的 permission policy，寫入外部系統與對外發送的一律 always_ask。
4. 預算。 每個 deployment 都設 budget，金額設在「正常一次任務的 2 到 3 倍」，異常時先停再查。
5. 審批的人與時限。 誰收到 requires_action 的通知、多久內要回、沒回會怎樣。
6. Agent 版本。 正式排程釘在特定版本，改 system prompt 後先用新版本手動跑幾次再切換。
7. 退場。 session 與檔案的刪除流程寫進 SOP，離職員工的帳號也要有對應的「停用 deployment、封存 agent」步驟。

這些項目和 從 PoC 到 Production 的部署指南裡的五個規模化失敗原因一一對應。Managed Agents 幫你省掉的是基礎設施，不是治理。

結論：先寫職務說明書，再談工具

AI 員工怎麼做，拆開來就是五步：職務說明書（agent）、辦公室（environment）、交辦（session 與 events）、主管簽核（permission policy 與 tool confirmation）、排班與零用金（scheduled deployment 與 budget）。Claude Managed Agents 把後四步的基礎設施包掉了，第一步仍然是你的工作，也是決定成敗的那一步。

我們的 AI 小編證明了一件事：一個職責清楚、關卡設對的 AI 員工，一週就能穩定，之後半年只需要微調提示詞。如果你的目標系統沒有 API，或想比較 API 型與瀏覽器操作型兩條路各自適合什麼，見用 Claude 還是 Grok Bot 建數位員工？8 項差異與各自擅長場景。如果你想為公司規劃第一個 AI 員工的職務設計、權限邊界與成本模型，歡迎預約 AI 導入顧問諮詢。

常見問題 FAQ

AI 員工跟 n8n 這類自動化流程差在哪？

n8n 是你畫好的固定流程，每一步做什麼由你決定；AI 員工是你給目標與邊界，步驟由模型決定。資料格式固定、步驟固定的工作用 n8n 就夠，需要判讀內容、處理例外的工作才需要 AI 員工。我們公司不用 n8n 的原因很實際：已經有一台伺服器在跑 Agent SDK，再加 n8n 就多一台要維護的機器。中小企業的第一個自動化可以先看 n8n + ChatGPT 實戰。

公司沒有工程師，能用 Claude Managed Agents 建 AI 員工嗎？

可以建，但維護會有困難。建立 agent 與 environment 用 ant CLI 寫兩個設定檔就能完成，不需要寫程式；但審批事件的處理、排程失敗的監控、把輸出接回公司系統，都需要有人能讀 API 文件並寫少量程式。沒有工程師的公司，建議由顧問建好骨架，內部只負責改職務說明書。

可以用 GPT 或 Gemini 的模型來跑 Managed Agents 嗎？

不行。Claude Managed Agents 只支援 Claude 模型，模型在 agent 設定裡指定，建 session 時可以用 overrides 換成另一個 Claude 模型。如果你需要同時用多家模型，要走自建路線；我們的 AI 小編系統就是用 Agent SDK 同時接 Claude 與 OpenAI，讓小編依文章語氣需求選模型。

資料會不會被 Anthropic 拿去訓練或長期保存？

Managed Agents 的 session 歷史、sandbox 狀態與輸出會保存在 Anthropic 伺服器端，你可以隨時透過 API 刪除 session 與上傳的檔案。但它目前不適用 Zero Data Retention，也不在 HIPAA BAA 的涵蓋範圍。有嚴格資料保留要求的工作，應使用自架 sandbox 或自建方案。訓練用途的政策以 Anthropic 當時的商業條款為準。

一個 AI 員工一次只能跑一個任務嗎？

一個 session 是一個任務，但同一個 agent 可以同時開多個 session，每個 session 有自己的 sandbox 與狀態。Session 之間互不共享檔案，需要共用資料就透過你的系統或 MCP 伺服器交換。排程的 deployment 每次到點也是開一個新 session。

AI 員工做錯事誰負責？

負責的是設定權限與審批的人，也就是你指定的「主管」。Managed Agents 提供的機制是：不可逆動作設 always_ask 在執行前攔截、每次任務設 budget 上限、事件歷史完整保存在伺服器端可供事後追查。我們半年多的經驗是，只要不可逆的那一個關卡一直有人在，就不會出大事。