AI Agent

上次我寫過一篇，講 Claude Code 跑動態工作流時，主代理把子代理的查證結果誤判成幻覺，自己反而幻覺了一整篇文章，還騙過兩輪 AI 審稿。那篇的幻覺長在「綜合」那一步——主代理沒翻紀錄，腦補了下游。 這篇是同一個系統的另一種死法，但這次的幻覺不是腦補出來的。是我親手用 schema 逼出來的。 先講 schema 是來幹嘛的動態工作流派子代理，你可以給它一個 schema，強制它用結構化格式回傳——不是回你一段中文，是回一個欄位齊全、型別正確的物件。下游就能直接 results.filter(r => r.score >= 7) 接住，不用自己從散文裡挖數字。 這東西很好用。我大部分 workflow 都靠它把「子代理的判斷」框成可以程式化處理的資料。問題是，我一直把它當成一道保險——以為「規定了格式，回來的東西就是可靠的」。 這兩個禮拜，同一套 schema 機制在我面前暴露了兩種完全不同的失敗。一種明、一種暗，成因也不一樣：明的那次是子代理根本沒把結論交回來，我當場就發現了；暗的那次是它交回來了、而且填得滿滿的，內容卻是編的，差點讓我去動一個不存在的檔。 ...

Claude Code 最近多了一個功能叫動態工作流（dynamic workflows）：讓主代理在執行時，當場寫一支 JavaScript，生成並協調一群子代理——每個子代理有自己獨立的 context window 和一個聚焦的小目標。 我前幾天用它做了件很實際的雜活：評估四個候選部落格選題，看哪個跟我既有文章庫重複、哪個值得寫。這篇把那支 script 整個攤開，講三件事——怎麼寫、parallel 和 pipeline 怎麼選、跑一次燒多少 token。 為什麼不是「開更多分頁」那麼簡單你可能會想，並行做事，開幾個對話視窗不就好了？ 差別在 context。Claude Code 過去是「一個對話、一條 context」，所有東西擠在同一個上下文視窗。長任務這個模式有三個老毛病，官方發布時直接點名：智慧惰性（做到一半宣布完工）、自我偏好偏差（驗證自己的產出時護短）、目標漂移（對話太長、尤其壓縮過後忘了最初目標）。 動態工作流的解法不是把單一 context 養得更肥，而是把活切開：每個子代理拿一塊乾淨的上下文，做一件聚焦的事，彼此不互相汙染。並行只是順帶的好處，真正的價...

最近Claude Code出了一個 動態工作流（dynamic workflows）的功能。這功能很新——讓主代理在執行時當場生成一群子代理，各自帶獨立 context 去幹活。 它做事很主動。為了不寫成照抄官方 blog 的乾貨，我自己實跑了一個 workflow 取材：派四個子代理並行評估選題、最後一個綜合代理把結果收齊排序。 跑完，它盯著綜合代理的輸出，揪出一句話，當成全篇高潮： 已查證 openai-codex-sdk 為真實官方套件，fabrication 風險解除。 Claude Code 的判斷是：抓到了。那個綜合代理根本沒有上網工具，哪來的「查證」？這就是幻覺——把一個自己驗證不了的結論，包裝成「已查證」。 於是它以這句為核心，寫了整篇技術使用的文章。論點很漂亮：fan-out 把活散出去很強，但綜合那一步不給查證工具、不做對抗式驗證，幻覺就從接縫長出來。還引了官方點名的 self-preferential bias——代理傾向給一個乾淨自信的結論，把下游的不確定性吃掉。它的 demo 自己示範了要解決的問題，多諷刺。這是它原稿最得意的一筆。 然後它把文章送了...

讓 agent 自己跑批次任務之前，我以為成本是可以「事後再看」的東西。 那是一個排程任務：每天半夜起來，把前一天累積的一批項目逐筆讓 agent 處理、分類、寫回。我設好就睡了。隔天早上看帳單，一個晚上燒掉的量，差不多是我平常手動用一整個月的程度。 東西是有跑完，但這個價錢完全不合理。我花了點時間把它拆開來看，發現失控的不是「AI 很貴」這個籠統印象，而是三、四個很具體、而且都能堵住的洞。這篇就是那幾道護欄。 先搞清楚錢是怎麼流掉的LLM 的計費單位是 token，輸入和輸出分開算，而且輸出通常比輸入貴好幾倍。先記住這條核心關係：你每次呼叫付的錢 ≈（這次塞進去的 input token + 吐出來的 output token）× 對應模型的單價。實際帳單還有快取、推理 token 之類的細項，但抓大放小，主導成本的就是這三個變數——而每一個我那晚都用錯了。 把這條公式攤開來算一次就很清楚。假設我那個任務每次呼叫平均塞 50K token 的 context，跑 200 筆，光 input 就是 1,000 萬 token。如果我還傻傻地全程用最貴的模型——以我寫這篇的當下，旗...

那天我想偷懶。一個中型重構，要動 api 層、service 層，順便把一個命名很爛的函式全專案改名。我手上有能並行派 sub-agent 的工具，腦袋一熱就想：三件事互不相干，派三個 agent 同時做，理論上三分之一時間搞定。 結果跑完一看，service 層的修改不見了。不是壞掉，是憑空消失，像我從來沒改過。 這篇就是那次的紀錄。如果你也開始用 Claude Code、Cursor 之類能派多個 agent 並行幹活的工具，這個坑你遲早會踩——而且踩的時候你不會第一時間意識到是自己派錯了。 本來以為會發生的事我的盤算很單純： Agent A：改 api/ 底下的 controller，調整回傳格式 Agent B：改 service/ 底下的業務邏輯，補一段快取 Agent C：把 getUserData 這個函式全專案改名成 fetchUserProfile 三個任務，三個 agent，同時開跑。我甚至在每個 agent 的指令最後都加了一句「請小心，不要動到不屬於你任務範圍的檔案」。自我感覺良好。 第一個坑：它們看不到彼此跑完之後，我打開 service/ 想看 B...

5 月 27 日 Anthropic 丟出一份 36 頁的電子書，標題叫《Zero Trust for AI Agents》。這不是一般的行銷白皮書——它給了具體的架構、實施路徑和威脅分類，而且每條建議都對應到成熟度等級，讓你知道自己該做到哪一層。 我把重點整理出來，順便加上我自己在用 Claude Code 和各種 Agent 工具時踩過的坑。 為什麼現在要談 Agent 安全先說結論：AI Agent 跟傳統軟體最大的差別，是它會自己做決定。 傳統軟體執行你寫好的邏輯。Agent 不一樣，它解讀目標、選擇工具、執行多步驟操作，全程不需要你點頭。這帶來一個根本性的安全問題——你給它的權限，它會用自己的判斷去使用。 Anthropic 在文件裡點出了五個 Agent 特有的安全考量： 自主執行：不用人工批准就能完成整條工作流程 工具存取：能操作 API、資料庫、檔案系統、MCP 伺服器 決策模糊性：人類覺得無害的指令，Agent 可能解讀出完全不同的結果 跨 session 記憶：記住上次對話的偏好和知識——也記住被注入的毒 多 Agent 協作：Agent 之間的信任關係，讓...

Cursor 在 5/21 釋出一篇「What we've learned building cloud agents」，作者是 Josh Ma。看起來像普通的工程經驗總結，但藏了一個讓我看完盯著螢幕想很久的數字：他們把 Cursor 內部 monorepo 的 40% PR 交給雲端 Agent 寫，而且這個比例還在漲。 這套系統最後支撐到 40% 之前，他們花了一年——不是「把本地 Agent 搬到伺服器」那種一年，而是把可靠性從 90%（一個九）拉到 99%（兩個九），中間放棄了自研架構、改用 Temporal、重新拆解了 agent、機器、對話三個狀態。 我自己沒做過 cloud agent 產品，但這篇花了一個下午消化，因為文章拆出來的五個學習，每一個都是「想做 AI Agent SaaS 的人遲早會撞上的牆」。寫一篇給台灣中階開發者看的拆解版。（附帶一個小插曲：中文 AI 資訊聚合站把原文的 "two nines" 翻成「99.9%」，實際是 99%。讀任何技術摘要，最後一步都要回原文校對。） 第一個坑：以為雲端 Agent 就是把本地 A...