如果你用過 coding agent，應該遇過這種瞬間：它看起來很順，下一秒卻開始改到你不想動的檔案；或是你本來想手動核准每一步，但任務一長就覺得「一直按同意」根本不現實。於是問題變成：我們到底讓 AI 自己跑多久？怎麼盯？盯到什麼程度才算安全？
本文把一份針對 Claude Code 與公開 API 的大規模互動觀測研究，用更貼近工程團隊日常的角度重寫：從「怎麼定義 Agent」、到「怎麼量測自主性」、再到「風險在哪裡開始冒出來」。你可以把它當作建立內部治理指標與監控儀表板的參考模板。
先講結論：多數 Agent 行為仍偏低風險、可逆；但自主性正在上升，且資安、金融、醫療等高風險領域已出現早期使用。想要安全擴大自主性，靠「每步都人工核准」不夠，得靠部署後監控與更好的介入機制。
先把話講清楚：什麼算 Agent？不是聊天機器人就算
工程師最怕概念空轉，所以直接用可落地的定義：Agent = 會用工具、能採取行動的 AI 系統。工具可能是：
- 跑程式碼、改檔案、下指令
- 呼叫外部 API（查資料、建票、觸發工作流）
- 發訊息或協調其他 Agent
為什麼這樣定義重要？因為你只要能把「工具呼叫」當成基本事件，就能做監控、做審計、做風險分級，不需要先把 Agent 的內部架構講得像論文一樣完整。
兩種觀測視角：API 看廣度、Claude Code 看深度
要研究「大家在真實世界怎麼用 Agent」，有兩個常見痛點：
- 供應商未必看得到客戶完整系統（你用什麼 orchestrator、外面還接了什麼人審流程）。
- 就算看得到流量，也不一定能把零散請求串成同一個 Session。
因此研究採用兩個互補資料源：
- 公開 API（廣）：可以看到很多不同客戶、很多領域，但多半只能以單次工具呼叫分析，無法完整重建長任務的「連續行為」。
- Claude Code（深）：因為是第一方產品，能把一次任務從頭到尾串起來，看它連續跑多久、何時停、停的原因是人類打斷還是它自己問問題。
而且研究使用隱私保護的分析方法，只做彙總與分類，不直接用人工逐筆看內容。
自主性怎麼量？用一個直覺但有用的指標：它連續工作多久才停
在 Claude Code 這種互動式 coding agent 裡，有個很直覺的量法：從它開始動手到它停下來（完成、被打斷、或自己問問題）的時間，當成每一回合的「自主工作時長」。它不是完美指標，因為模型速度、並行子代理、任務難度都會影響，但對理解真實使用很有幫助。
觀測結果有兩層：
- 多數回合很短：中位數大約 45 秒，幾個月內大致在 40–55 秒浮動。
- 長尾在變長：最長那批使用案例，在三個月內，停止前的自主工作時長幾乎翻倍（以 99.9 百分位衡量，從不到 25 分鐘到超過 45 分鐘）。
如果你是帶團隊導入的人，這很像一個訊號：當大家越用越熟、越敢把任務丟大，Agent 就會被允許跑更久。更妙的是，這個變長趨勢跨模型更新很平滑，暗示「信任、工作流、產品設計」的影響，可能不亞於模型本身能力提升。
資深使用者的監督策略很「現實」：少按核准、多用中斷修正
很多治理制度直覺會走向「每一步都要人核准」，但實際使用不一定這樣。觀測顯示：
- 使用者越資深，全自動核准（auto-approve）越常開：新手大約 20% 的 Session 使用全自動，資深可到 40% 以上。
- 同時，使用者越資深，中斷（interrupt）也越常發生：新手約 5% 的回合中斷，資深約 9%。
這其實超像工程師的日常：一開始不放心，想逐步看；但任務變長後，你會改成讓它跑，自己盯進度、看到不對就喊停、補上下文、修正方向。也就是從「事前核准」轉成「過程監看 + 必要時介入」。
對團隊流程的啟示：不要把「按不按核准」當成唯一安全指標，反而要問：你是否提供足夠可觀測性（它現在做什麼、要做什麼、為什麼）、以及足夠低成本的介入方式（中斷、回滾、鎖權限、改目標）。
不只是人類在盯：Agent 自己停下來問問題，其實也是一種安全機制
另一個很實用的觀測是：在複雜任務中，Claude Code 會更常停下來問澄清問題，而且頻率比人類中斷更高，最複雜任務甚至是人類中斷的兩倍以上。
把常見原因翻成工程師語言，大概是：
- 它自己停下來：要你選 A/B 方案、要你提供測試結果或診斷資訊、需求不清楚要你補、缺 token/權限、或它覺得該先確認再動手。
- 你把它喊停：你發現上下文錯了、你想改需求、它卡住/太慢、或你已經拿到足夠提示想自己做下一步（例如跑測試、部署、commit）。
落地建議：把「會停下來問對問題」視為 Agent 的核心能力之一。你可以要求它在高風險工具前先輸出計畫與假設，並把不確定點變成明確的確認清單。
風險在哪裡？大多低風險可逆，但右上角（高風險/高自主）不是空的
公開 API 的部分，研究用模型去估每次工具呼叫的兩個分數（1–10）：風險與自主性，並把相似行為聚成群集。整體看起來「還算安心」：大多數行為偏低風險，且很多動作可逆；Agent 行為目前高度集中在軟體工程（約接近一半）。
但同時也看到一些值得工程主管注意的訊號：
- 在醫療、金融、資安等領域，開始出現使用案例。
- 高風險或高自主的群集雖少，但確實存在；而且一次失誤就可能成本很高。
研究也提供幾個「防護現況」的估計值，方便你對照自家系統：
- 約 80% 的工具呼叫看起來至少有某種 safeguard（權限限制或核准要求）。
- 約 73% 看起來有人類介入（研究同時提醒可能偏高估，可視為上限）。
- 約 0.8% 看起來是不可逆動作（例如對外寄信）。
另外一個很務實的提醒：供應商未必知道「看起來的行為」是否真的落地執行（例如下單交易可能只是測試），也可能是紅隊演練。這代表風險分數更適合當趨勢雷達，用來看右上角是否變密，而不是用來一刀切判定合規。
把研究翻成你可以做的事：三個「不用等政策」就能開始的工程改造
1) 先把不可逆行為抓出來，建立硬門檻
比起要求所有步驟都人工核准，更有效的做法是：對不可逆或高影響行為設門檻，例如：
- 對外發送（寄信/訊息）、下單交易、刪除資料、權限提升、寫入正式環境
- 存取敏感資料（醫療、財務、身分資料）
這些行為可以採用更嚴格策略：強制二次確認、人審、或僅允許在 sandbox 執行。
2) 把「中斷」做成一等公民，而不是當成失敗
資深使用者更常中斷，代表中斷是一種正常的監督方式。建議你在產品或內部工具上確保：
- 一鍵停止、暫停、回滾
- 停止當下能保留狀態與上下文（方便續跑或改方向）
- 中斷原因可被記錄（方便事後改善 prompt、工具或權限策略）
3) 投資部署後監控：你需要的是「看得見」而不是「按得多」
要讓團隊敢放手，關鍵是可觀測性。最低限度你應該能回答：
- 它用哪些工具做了哪些事？耗時多久？結果如何？
- 哪些動作是高風險/不可逆？誰授權？是否有回滾？
- 它停下來問了哪些澄清問題？人類中斷發生在哪些任務型態？
未來趨勢
- 自主性會繼續上升，而且不是只靠模型變強：更可能是使用者信任、工作流成熟、產品互動改善一起推動長尾變長。
- 高風險領域會從「少量嘗試」走向「流程化」：當 Agent 變得更容易接入各種業務工具，右上象限（高自主/高風險）會更常見，監控與審計的重要性會快速上升。
給專業人士的實務建議
- 把「風險分級 + 不可逆門檻」寫進工程規範：例如定義哪些工具必須先計畫再執行、哪些必須人審、哪些只能在 sandbox。
- 用「interrupt/clarify/rollback」當作流程體感指標：這些指標往往比成功率更能早期反映：上下文是否不足、工具是否不穩、權限是否設太寬或太窄。
