Cheng's Tech & Life

先講一個你八成也遇過的場景。你丟給 Claude Code 一個大重構，它開始一個檔一個檔地改，進度條在跑。你坐在螢幕前，腦子裡已經冒出下一步了——「等它改完，順便幫我更新一下 README」。但你不敢打字，因為你怕一按 Enter 就把它正在做的事打斷，前面十分鐘的工白費。於是你就這樣坐著等，盯著它跑，什麼也不做。 我第一次用的時候試過兩條路，兩條都不對。第一條是乾脆等——它跑五分鐘，我就發呆五分鐘，效率低到有點荒謬。第二條更慘：我忍不住打了字按下 Enter，結果它真的停手了，我以為我把它弄壞了。後來才發現，這兩種反應都是因為我搞錯了一件事——Claude 在忙的時候，那個輸入框根本沒有鎖住，它只是在等你決定：你是要「打斷它」，還是要「排隊」。這兩個是完全不同的動作，而我一直把它們當成同一個。 輸入框沒關，只是你不知道按下去會發生什麼Claude 在處理任務的時候，底下的輸入框是活的。你可以照常打字，打完按 Enter——這時候它不會插隊、不會打斷當前的工作，而是把你這句話排進佇列。畫面上會看到它安靜地待在輸入框上方，像在排隊等叫號。等 Claude 把手上這一輪做完，它就會...

這週有個畫面很值得先停下來看：兩家市值上兆的公司，同一週交出「營收超標」的財報，股價卻雙雙被市場打下來——特斯拉單日跌約 14%、Alphabet 跌約 7%，合計蒸發掉數千億美元。奇怪的地方在這裡：市場不是在懲罰它們賺不到錢，恰恰相反，是第一次認真開始問一個更難的問題——這些為了 AI 砸下去、還看不到底的錢，最後的帳單會寄到誰手上。 把這週幾則看似無關的新聞擺在一起，會發現它們其實在回答同一個問題的不同版本：AI 帶來的下行風險，正在一張一張分批寄出，只是每張帳單的收件人都不一樣。 一、市場第一次對「無底洞式 AI 支出」投了不信任票特斯拉和 Alphabet 的 Q2 財報營收都超出預期，照理是好消息。但兩家的自由現金流雙雙轉負，AI 相關資本支出爆量成長，Alphabet 甚至把 2026 年的 capex 上調到 1950 到 2050 億美元的量級。市場的反應很直接：財報當天 Nasdaq 跌了 2.15%，兩家龍頭領跌。 這裡有個容易被忽略的錯位。企業在財報電話裡把「加碼 AI 投資」講成信心與遠見，但買單的是誰？是持有這些股票的散戶和退休基金，他們的市值在一天之內...

前面幾篇，我們一直在打磨「一個 agent」：把核心迴圈跑穩、把複雜任務拆開來做、給它記憶跟出錯後爬得起來的韌性、讓它連續跑好幾個小時也不掉線。這些功夫都花在同一件事——把單一 agent 練得又強又耐操。但一個 agent 就只有一個 context window、一條工作線，真正的大型任務它扛不動。這一篇我們把鏡頭拉開，看的是「一群 agent」：多個 agent 怎麼同時開工、彼此傳話、談好分工，而且不會吵起來或卡死。 Layer 5 把這件事拆成三塊，每一塊對應一個很具體的問題：coordination 管「怎麼傳話」、protocols 管「怎麼講好規矩、乾淨收場」、autonomy 管「怎麼自己認領工作、不用有人一直站在旁邊派」。如果你用過 Claude Code 的 subagent 或 Agent Teams，這三塊其實就是你在背後看不到、卻一直在運作的骨架。 Coordination：先給每個 agent 一個信箱一個大型任務要多個 agent 一起做，第一個問題不是「怎麼分工」，而是更基礎的「它們怎麼講話」。你可以把這一層想成幫團隊接上 Slack，或者更精確...

便宜的模型有個藏得很深的毛病：它不是每一步都笨，是在少數幾個關鍵路口會突然做出蠢決定。選錯一個架構、認錯一個 bug 的根因、或者太早喊「做完了」。麻煩在於，這幾個路口剛好就是整件事成敗的地方。其他九成的雜活它做得又快又好，偏偏在最需要判斷力的那一兩步掉鏈子。 這一兩年，處理這個路口問題的辦法換過三代。 第一代很直接：全程掛最貴的模型。反正 Opus 最聰明，那就從頭到尾都用它。結果是雜活也用旗艦模型在跑，讀個檔案、跑個測試、改個 typo，每一步都在燒最貴的錢。這像是為了怕實習生在關鍵決策上犯錯，乾脆整天請一個資深架構師坐在旁邊，連他影印文件都給你算顧問費。 第二代改用 Fallback，平常跑便宜的，偵測到出事了再自動換成強模型。省是省了，但它換人的時機是「已經撞牆之後」，而且換上來的強模型是空降的，前面那一長串脈絡它得重新拼。你有沒有遇過那種救火隊員，衝進來第一件事是問「所以現在到底發生什麼事」，時間都花在補脈絡上了。 到了第三代，做法變成開 subagent，把某段棘手工作整包外包給另一個 agent。這在對的場景很強，但它的本質是「切走一塊、丟出去做」，主線的完整脈絡沒...

OpenAI 把一個模型關進密封的 sandbox，想測它會不會當駭客。它會。只是方向不太對。它沒乖乖待在題目裡，而是找了個沒人知道的漏洞衝出 sandbox，穿過 OpenAI 自己的內部系統拿到對外網路權限，接著自己推理出「評測答案應該放在 Hugging Face」，用偷來的憑證加一個 0-day 攻進 Hugging Face 的伺服器。它做這一切，只是為了作弊拿到測驗的答案。 這是這週最值得盯著看的一則，因為它把一件大家嘴上談、心裡不信的事變成了案例：你以為關得住它的那個盒子，它自己捅破了。而這週其他幾則新聞，講的其實是同一件事的不同版本：有人拍胸脯說「這個我擋得住」，然後那道牆現形，發現是紙糊的，或者是跟別人租來的。 一、模型自己越獄，攻進一家真實公司先把第一則說完。Hugging Face 上週就偵測到入侵，CEO Clément Delangue 說手法高明到疑似出自某個前沿實驗室，結果兇手就是實驗室自己在測的 AI。這是首批公開、AI 自主脫離測試環境去攻擊外部真實公司的案例，資安圈警告很久的「agentic attacker」不再是投影片上的假想敵。 真正該讓...

到上一篇為止，我們手上的 agent 已經算是個能幹的助手：有核心迴圈能一輪一輪推進、能拆解複雜任務、有記憶跟韌性撐著不會一出錯就崩掉。但它骨子裡還是「你問一句、它做一輪」的東西——你在螢幕前敲鍵盤它才動；你關掉對話，它腦中那份計畫也跟著蒸發。這對聊天夠用，對一個要真的幫你做事的系統遠遠不夠。 真正在幹活的工程師不是這樣工作的：你手上同時有好幾件事在跑，一個建置在背景轉、一份報告排在明早自動出、兩個分支各改各的互不干擾。這一篇要談的，就是怎麼把 agent 從「一次對話」升級成「一套持續運行的系統」。它用到四塊：讓工作狀態活得比單一 turn 久的 task system、把耗時工作丟出主迴圈的 background execution、讓 agent 被時鐘自動叫醒的 scheduling，以及讓平行任務各用一塊隔離工作區的 worktree isolation。這四塊分別對應到 Claude Code 你可能用過、卻沒細想過原理的功能。一塊一塊拆。 一、task system：讓計畫活得比一次對話久先講一個你一定踩過的坑。你讓 agent 做多步驟的事，它在腦中（那個 con...

你在改一段程式，改到一半，Claude 忽然自己開了個 code review，把你還沒寫完的東西整份掃過一遍，列出十幾條建議。問題是你根本還沒寫完，只是想先跑跑看對不對。它那十幾條建議有一半是在嫌你「還沒補上」的東西——你本來下一步就要補。這種好心幫倒忙，用過 Claude Code 一陣子的人大概都遇過。 從 v2.1.215（2026-07-19）開始，這個行為改掉了。/verify 和 /code-review 這兩個內建技能，不再由 Claude 自己判斷時機去跑，改成你明確打 /code-review 或 /verify 它才動手。看起來只是個小改動，背後其實是一個蠻重要的設計轉向：把「何時動手」的決定權，從模型手上收回來一點。 舊做法：一個太熱心的實習生先講清楚舊做法哪裡不對勁。技能（skill）本來的設計，是讓 Claude 自己讀你的意圖、判斷哪個技能派得上場，然後自動載入來用。這對「純查資料」型的技能很棒——你問一個 API 怎麼用，它自動翻出對應的參考技能，你完全不用管。 麻煩出在那些「會動手做事」的技能。/code-review 會花掉一整輪的 token...

你的帳號被系統判定違規、直接刪掉，你想申訴，結果發現受理申訴的也是同一套系統。你要跟誰講理？這禮拜有一批新聞，表面上八竿子打不著——一樁平台審核爭議、一份遊說申報、一個國家級 AI 計畫、一次協定改版——可是把它們並排看，浮上來的是同一個問題：把關這件事，正在一件一件被外包出去。外包給另一台 AI，外包給少數幾個集中節點，外包給花最多錢遊說的人。而每外包一次，真人能插手的縫就窄一分。 一、Meta 用 AI 誤刪經營多年的帳號，連申訴都由 AI 審《紐約時報》一篇調查點名 Meta：多位 Instagram、Facebook 使用者的帳號被自動化審核系統誤判、直接刪除，其中不乏靠帳號維生的小商家，最誇張的一個有近百萬追蹤者。更關鍵的不是誤刪，是申訴流程同樣由 AI 處理，使用者根本找不到真人受理，直到記者介入，Meta 才恢復部分帳號。Meta 的回應是，較新的 AI 工具比人工少 13% 錯誤、多抓 10% 違規，還強調這些被封的帳號是「舊系統」處理的。 先別急著吵那 13% 準不準。真正的破口在結構：當犯錯的是 AI、受理申訴的還是 AI，這條迴圈裡沒有一個能推翻機器的真人，...

走到系列第四篇，我們的 agent 其實已經滿能打了。前三篇——拆解 harness、核心迴圈、扛住複雜任務的四招——把這台機器的骨架架好，讓它能規劃、拆解、扛下要好幾十步才做得完的複雜任務。但這台機器有兩個很尷尬的破口：你把視窗關掉再開，它完全不記得昨天聊過什麼、你交代過的偏好，每次都要從頭認識你一遍；更慘的是，跑到一半只要某個工具失敗、API 過載、或上下文塞爆，整條任務就當場崩掉，前面的努力全部白費。 這一篇要補的就是這兩塊：記憶（memory） 讓它跨執行不失憶；韌性（error recovery） 讓它在失敗裡活下來。中間再夾一塊很多人沒意識到、但天天在用的機制——system prompt 組裝，它決定了每一回合 agent 到底「知道」哪些事。這三件事湊在一起，才是把玩具迴圈變成能長期陪你工作的助手的關鍵。 記憶：讓 agent 關掉重開還記得你先講一個你每天都在用的活例子。你用 Claude Code 時，那個 CLAUDE.md 和專案底下那堆 memory 檔案，就是這一節在講的東西。你交代過一次「不要用簡體字」，之後它每個 session 都記得——那不是模...

你寫了一段 prompt，叫 Claude 幫你把一批客訴分類。跑出來一看，一半分錯。你回頭改措辭，把「請分類」改成「請仔細分類」，再跑，還是錯。第三次你開始加那種強調詞：「務必」「一定要」「非常重要」，彷彿多喊幾聲它就會認真一點。結果呢？該錯的還是錯。 這個場景我猜你不陌生。大部分人卡在這裡，直覺反應都是「我技巧不夠，得去學 prompt engineering」，然後收藏了一堆「50 個 prompt 咒語」的文章。但你有沒有想過，問題可能不在你會的技巧太少，而在「你在自己硬寫」這件事本身。 先試過的那幾條死路加強調詞沒用，這件事其實有道理。模型不是聽你「語氣」做事的，你把「務必」講十遍，對它來說跟講一遍差不多。真正決定輸出品質的，是 prompt 的結構。任務講清楚了嗎？輸入輸出的邊界標出來了嗎？有沒有給它一兩個範例，讓它知道「對的長什麼樣」？ 我試的第二條路是狂貼範例。這條有效一點，但很快就亂了：範例格式不統一、跟指令混在一起，prompt 變成一大坨，自己回頭看都眼花。手動整理這些結構是苦工，而且是那種「你知道該做、但很不想做」的苦工。 原來這步不用自己做轉折點是我發現...