我給 AI 一個逃生欄「找不到就填 NONE」,它還是編了一個假檔名
上次我寫過一篇,講 Claude Code 跑動態工作流時,主代理把子代理的查證結果誤判成幻覺,自己反而幻覺了一整篇文章,還騙過兩輪 AI 審稿。那篇的幻覺長在「綜合」那一步——主代理沒翻紀錄,腦補了下游。 這篇是同一個系統的另一種死法,但這次的幻覺不是腦補出來的。是我親手用 schema 逼出來的。 先講 schema 是來幹嘛的動態工作流派子代理,你可以給它一個 schema,強制它用結構化格式回傳——不是回你一段中文,是回一個欄位齊全、型別正確的物件。下游就能直接 results.filter(r => r.score >= 7) 接住,不用自己從散文裡挖數字。 這東西很好用。我大部分 workflow 都靠它把「子代理的判斷」框成可以程式化處理的資料。問題是,我一直把它當成一道保險——以為「規定了格式,回來的東西就是可靠的」。 這兩個禮拜,同一套 schema 機制在我面前暴露了兩種完全不同的失敗。一種明、一種暗,成因也不一樣:明的那次是子代理根本沒把結論交回來,我當場就發現了;暗的那次是它交回來了、而且填得滿滿的,內容卻是編的,差點讓我去動一個不存在的檔。 ...
Claude Code 動態工作流實戰:用一支 JavaScript 派一群子代理,順便算了筆 token 帳
Claude Code 最近多了一個功能叫動態工作流(dynamic workflows):讓主代理在執行時,當場寫一支 JavaScript,生成並協調一群子代理——每個子代理有自己獨立的 context window 和一個聚焦的小目標。 我前幾天用它做了件很實際的雜活:評估四個候選部落格選題,看哪個跟我既有文章庫重複、哪個值得寫。這篇把那支 script 整個攤開,講三件事——怎麼寫、parallel 和 pipeline 怎麼選、跑一次燒多少 token。 為什麼不是「開更多分頁」那麼簡單你可能會想,並行做事,開幾個對話視窗不就好了? 差別在 context。Claude Code 過去是「一個對話、一條 context」,所有東西擠在同一個上下文視窗。長任務這個模式有三個老毛病,官方發布時直接點名:智能惰性(做到一半宣布完工)、自我偏好偏差(驗證自己的產出時護短)、目標漂移(對話太長、尤其壓縮過後忘了最初目標)。 動態工作流的解法不是把單一 context 養得更肥,而是把活切開:每個子代理拿一塊乾淨的上下文,做一件聚焦的事,彼此不互相汙染。並行只是順帶的好處,真正的價...
我叫 Claude Code 寫篇技術文檔,它自己幻覺了,還騙過兩輪 AI 審稿
最近Claude Code出了一個 動態工作流(dynamic workflows)的功能。這功能很新——讓主代理在執行時當場生成一群子代理,各自帶獨立 context 去幹活。 它做事很主動。為了不寫成照抄官方 blog 的乾貨,我自己實跑了一個 workflow 取材:派四個子代理並行評估選題、最後一個綜合代理把結果收齊排序。 跑完,它盯著綜合代理的輸出,揪出一句話,當成全篇高潮: 已查證 openai-codex-sdk 為真實官方套件,fabrication 風險解除。 Claude Code 的判斷是:抓到了。那個綜合代理根本沒有上網工具,哪來的「查證」?這就是幻覺——把一個自己驗證不了的結論,包裝成「已查證」。 於是它以這句為核心,寫了整篇技術使用的文章。論點很漂亮:fan-out 把活散出去很強,但綜合那一步不給查證工具、不做對抗式驗證,幻覺就從接縫長出來。還引了官方點名的 self-preferential bias——代理傾向給一個乾淨自信的結論,把下游的不確定性吃掉。它的 demo 自己示範了要解決的問題,多諷刺。這是它原稿最得意的一筆。 然後它把文章送了...







