Cheng's Tech & Life

便宜的模型有個藏得很深的毛病：它不是每一步都笨，是在少數幾個關鍵路口會突然做出蠢決定。選錯一個架構、認錯一個 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 變成一大坨，自己回頭看都眼花。手動整理這些結構是苦工，而且是那種「你知道該做、但很不想做」的苦工。 原來這步不用自己做轉折點是我發現...

AI 公司最愛掛在嘴邊的一句話是「我們不綁死任何單一供應商」。這一週的幾條新聞，剛好把這句話戳出幾個洞。表面上它們互不相干——一樁算力租約、一次模型跳票、幾張晶片出口許可，可是只盯著單一則，你會漏掉底下那件正在發生的事：整個產業的命脈，正一節一節收斂到少數幾個點上。 一、Anthropic 傳向 Meta 租最高 100 億美元算力據 Reuters，Anthropic 正在跟 Meta 洽談租用運算能力，兩年規模上看 100 億美元，用來撐住 Claude 的需求。談判還在早期，Meta 目前也沒有成熟的對外賣算力業務，未必談得成。 真正該注意的不是金額，是關係本身。Meta 的 Llama 和 Anthropic 的 Claude 是正面對打的競品，這筆租約會讓兩家同時變成「對手兼客戶」。當你的算力房東就是你的競爭對手，議價權、優先權、甚至斷租的風險，全都握在對方手上。這種依賴不會出現在任何一季的財報數字裡，但它是實打實的下行風險。上行有限（省點自建成本），下行卻可能是關鍵時刻被掐脖子。 來源：TechFundingNews 二、Meta 推出 Muse Spark 1.1，...

第一篇和第二篇我們把一個 agent 的骨架搭起來了：核心迴圈會呼叫模型、執行工具、把結果塞回對話，然後再問一次模型。這套流程處理「幫我讀這個檔、改那一行」綽綽有餘。但只要任務一變大，你自己在 Claude Code 裡大概都體驗過那個場景：它跑到一半開始鬼打牆，忘了三步前答應要做的事，或是對話長到某個點突然變慢、變貴，最後乾脆漏掉一半需求。 模型沒變笨，它只是扛不住了。大任務會從兩個方向壓垮一個 agent：一是沒有一份看得見的計畫，走著走著就迷路；二是 context window 被塞爆，該記住的東西被無關的雜訊擠出去。這一篇要講的 Layer 2，就是專門解決「扛不住」的四招：planning & todos、subagents、skills、context management。它們的共同目標只有一句話：讓 agent 在面對真正複雜的工作時，還能保持頭腦清醒。 第一招：planning & todos，先把大任務拆成 ticket你接到一個橫跨十幾個檔案的重構，第一件事會做什麼？不會是打開第一個檔案就開始改，而是先在 Jira 上開一串 ticket，...

先分清楚：你是坐在旁邊，還是放它自己跑Claude Code 在 v2.1.212（2026-07-17）悄悄加了三個 session 級的資源上限。官方 changelog 講得很平淡，多數人滑過去大概也不會多想。但這三個開關的價值，完全取決於你怎麼用 Claude Code，所以在講該不該動它們之前，得先把使用情境切成兩種。 第一種，你坐在終端機前面，一句一句跟它對話，它每要動一次危險操作你都看得到。這種情況下，這三個上限你幾乎可以當它不存在。第二種，你把一個任務丟給它，關掉螢幕去睡覺，或乾脆掛在排程上每天自動跑。這種情況下，這三個數字就從「裝飾」變成「保險絲」。 我用電箱裡的保險絲來想這件事最順。保險絲不是拿來限制你用電的，你想開幾盞燈、吹不吹冷氣，它一概不管。它只在一種時刻起作用：電線快要走火、整間房子有燒起來的風險時，「啪」一聲把電切掉。這三個上限的角色一模一樣。平常你感覺不到它們，它們只在 agent 陷入某種失控迴圈、準備把你的 token 額度燒到見底的那一刻，跳出來把電閘拉下。 三根保險絲各自防的是什麼火先把三個開關擺出來，順便說清楚每一根防的是哪一種走火。它們...