[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-loop-engineering-agent-completes-tasks-zh":3,"article-related-loop-engineering-agent-completes-tasks-zh":30,"series-ai-agent-1aeae331-e5da-4bc9-bee6-6d7bbf47874f":81},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"1aeae331-e5da-4bc9-bee6-6d7bbf47874f","loop-engineering-agent-completes-tasks-zh","Loop Engineering 讓 Agent 做完事","\u003Cp data-speakable=\"summary\">我把 Loop Engineering 拆成一套能直接拿去用的 \u003Ca href=\"\u002Ftag\u002Fagent\">Agent\u003C\u002Fa> 完成任務模板。\u003C\u002Fp>\u003Cp>我前陣子一直在折騰 Agent 工作流，心裡憋著一股火。Prompt 寫得挺像樣，工具也接上了，甚至上下文我都餵得很講究，可結果還是老樣子：它會開始做，也會很熱情地回報進展，但一到真正複雜的任務，就開始飄。要嘛第一輪輸出看著對，第二輪就把自己帶溝裡；要嘛它知道「該做什麼」，卻不知道「做到什麼程度算結束」。最煩的是，它還特別會裝作已經完成了。你讓它修一個專案，它給你一堆看起來很像回事的中間產物，最後留下半成品，像是把「努力」當成交付。\u003C\u002Fp>\u003Cp>我後來才意識到，問題不只是 Prompt，也不只是 Context。Prompt 解決的是「怎麼說」，Context Engineering 解決的是「該知道什麼」，但真正讓長任務落地的，是循環本身：執行、檢查、修正、再執行。也就是這篇知乎文章裡講的 Loop Engineering。\u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2049084372561687197\">原文\u003C\u002Fa>把它和 \u003Ca href=\"\u002Ftag\u002Fprompt-engineering\">Prompt Engineering\u003C\u002Fa>、Context Engineering 放在一條線上講，我覺得這個拆法挺對味。因為很多人現在卡住的，不是不會讓 AI 開始幹活，而是不會讓它把活做完。\u003C\u002Fp>\u003Cp>這篇文章的價值，不在於又發明了一個新詞，而在於它把一個很煩但很真實的問題說透了：當任務變複雜，Agent 不能只靠一次性指令，而要靠迭代式執行機制。你得讓它自己看結果、自己發現偏差、自己修正路徑。說白了，Loop Engineering 不是「讓 AI 更聰明」，而是「讓 AI 更像一個會收尾的幹活的人」。\u003C\u002Fp>\u003Ch2>Prompt 只能起跑，不能衝線\u003C\u002Fh2>\u003Cblockquote>但這個階段的侷限性也很明顯：適合相對明確的任務（寫文案、總結文章、提取要點），一旦任務變複雜，Prompt 就不夠用了。\u003C\u002Fblockquote>\u003Cp>這句話我太熟了。Prompt Engineering 最好用的時候，就是任務邊界很清楚：寫個摘要、改個標題、提煉要點、生成一段程式碼片段。輸入和輸出都比較明確，模型只要照著做，通常不會太離譜。但一旦任務開始有狀態、有依賴、有中間判斷，單次 Prompt 就開始發虛。它沒有辦法天然知道「這一步做完之後，下一步該怎麼接」。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782408826097-l6g3.png\" alt=\"Loop Engineering 讓 Agent 做完事\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我自己最早踩坑是在做一個文件整理 Agent 的時候。第一輪我給它一個很完整的指令：讀取\u003Ca href=\"\u002Fnews\u002Fanthropic-overseas-data-center-push-right-move-zh\">資料\u003C\u002Fa>、分類、輸出結構化結果。結果它每次都能給我一個「像樣」的答案，但分類標準總在變，前後不一致，最後你根本沒法把它接進後續流程。那時候我還以為是 Prompt 不夠細，後來發現不是細不細的問題，是一次性指令本來就不適合這種多階段任務。\u003C\u002Fp>\u003Cp>翻譯一下就是：如果任務需要多步推進，你不能只問「請給我答案」，而要設計「每一步之後怎麼判斷是否繼續」。Prompt 的職責只是啟動，真正決定交付品質的是循環控制。\u003C\u002Fp>\u003Cp>實操上，我會先把任務拆成幾類，看看哪些是單輪可完成的，哪些必須多輪收斂。單輪任務繼續用 Prompt；多輪任務直接別硬扛，改成循環式流程。你可以先寫出三個最基本的問題：現在完成了嗎？如果沒完成，差在哪？下一輪\u003Ca href=\"\u002Fnews\u002Fprompt-versioning-belongs-in-production-zh\">應該\u003C\u002Fa>改什麼？\u003C\u002Fp>\u003Cul>\u003Cli>適合單輪：摘要、改寫、資訊提取、固定格式生成。\u003C\u002Fli>\u003Cli>適合循環：程式碼修復、研究歸納、複雜規劃、跨檔案編輯、長任務執行。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Context Engineering 負責餵對資訊，但還不夠\u003C\u002Fh2>\u003Cblockquote>當任務複雜之後，AI 需要知道的更多。它要看的是專案背景、程式碼結構、目標指令、歷史決策、團隊規範……把哪些資訊放進模型上下文裡，是這個階段要解決的問題。\u003C\u002Fblockquote>\u003Cp>這段其實講的是我最認可的一層：上下文不是越多越好，而是越對越好。很多人一上來就把所有材料塞給模型，結果模型看得很累，輸出也很散。Context Engineering 的關鍵不是「填滿視窗」，而是把模型做判斷真正需要的資訊放進去。專案背景、歷史決策、程式碼結構、\u003Ca href=\"\u002Fnews\u002Fai-writes-code-teams-own-debt-zh\">團隊\u003C\u002Fa>規範，這些東西不是裝飾品，它們決定模型會不會在錯誤的軌道上越跑越遠。\u003C\u002Fp>\u003Cp>我在做程式碼審查助手時就吃過這個虧。最開始我只給它 diff，讓它評審。結果它的建議很像一個剛進專案的人，語氣很認真，判斷很自信，但經常忽略倉庫裡已有的約定。後來我把目錄結構、相關模組的歷史改動、lint 規則、測試約束一起餵進去，它的建議才開始像「真在這個專案裡幹過活」。\u003C\u002Fp>\u003Cp>但這裡有個坑：Context Engineering 只能解決「做對」，不能保證「做完」。你給它更好的背景，它更容易判斷方向；可如果任務本身需要反覆試錯，單次上下文再漂亮也沒用。模型還是會卡在中途，或者在某個局部最優裡停住。\u003C\u002Fp>\u003Cp>翻譯一下就是：上下文負責減少誤判，循環負責推動收斂。前者讓它少走歪路，後者讓它別半路停工。兩者不是替代關係，是配合關係。\u003C\u002Fp>\u003Cp>實操上，我建議把上下文分成三層來準備。第一層是任務目標，第二層是目前狀態，第三層是約束和歷史。別把所有資料平鋪進去，最好按「決策優先級」組織。模型先看目標，再看狀態，最後看約束。這樣它在每輪循環裡都能快速定位自己現在在哪。\u003C\u002Fp>\u003Cul>\u003Cli>目標：最終要交付什麼。\u003C\u002Fli>\u003Cli>狀態：目前已經完成了什麼。\u003C\u002Fli>\u003Cli>約束：不能違反什麼規則。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Loop Engineering 的核心不是循環，是收斂\u003C\u002Fh2>\u003Cblockquote>Context Engineering 讓 AI「做對」，Loop Engineering 解決的是「做完成」。\u003C\u002Fblockquote>\u003Cp>這句是整篇文章最值錢的地方。因為「循環」這個詞很容易讓人理解偏了，覺得就是多跑幾輪而已。不是。Loop Engineering 真正關注的不是「多跑」，而是「怎麼從不確定狀態逐步逼近完成態」。如果沒有收斂機制，循環只會變成重複勞動；如果有收斂機制，每一輪都會減少不確定性。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782408819739-leup.png\" alt=\"Loop Engineering 讓 Agent 做完事\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我見過太多 Agent 流程死在「繼續執行」這一步。模型每輪都在產出，但沒人定義什麼叫進步。於是它會在同一個錯誤方向上越修越遠，或者因為局部結果看起來不錯，就誤以為全局已經完成。這個時候你再給它更長的上下文，也沒用。因為問題不是資訊不夠，而是缺少一個明確的停止條件和校驗標準。\u003C\u002Fp>\u003Cp>翻譯一下就是：Loop 不是讓模型一直幹，而是讓每一輪都帶著檢查點。你得規定，輸出必須經過驗證，驗證不過就回滾或修正，驗證通過才進入下一步。沒有這個機制，所謂「Agent」很容易退化成「自動復讀機」。\u003C\u002Fp>\u003Cp>實操上，我會給每個循環加三個固定動作：執行、檢查、修正。執行負責產生結果，檢查負責判斷結果是否達標，修正負責針對偏差重新嘗試。你可以把檢查寫成規則，也可以寫成另一輪模型判斷，但一定要有明確標準。別讓模型自己宣布自己完成了，這事我已經被坑過太多次了。\u003C\u002Fp>\u003Cp>如果你做的是程式碼類任務，我建議檢查至少包含三項：語法是否正確、測試是否通過、結果是否符合目標。如果你做的是研究類任務，檢查至少包含：資訊來源是否可靠、結論是否和材料一致、有沒有遺漏關鍵反例。\u003C\u002Fp>\u003Ch2>失敗後修改，比一把梭更像真實工作流\u003C\u002Fh2>\u003Cblockquote>Agent 處理長任務時，需要反覆執行、自行檢查成果、失敗後修改、試錯了累積經驗。\u003C\u002Fblockquote>\u003Cp>這句話聽起來很樸素，但它其實點出了長任務最真實的樣子。現實裡的工作從來不是「一次寫對」。你寫程式會報錯，改文件會漏段落，做方案會被打回，整理資料會發現欄位不一致。Agent 如果想真的像一個能幹活的系統，就不能只會生成，還得會失敗、會修正、會記住問題。\u003C\u002Fp>\u003Cp>我自己最有感的是做自動化測試修復的時候。第一輪模型經常會給出一個看起來合理的補丁，但跑完測試還是掛。以前我會很煩，覺得它沒理解問題。後來我改成讓它先看失敗日誌，再定位失敗點，再提出修復方案，最後才動手改程式碼。效果立刻不一樣了。因為它不是在空中猜，而是在錯誤資訊裡迭代。\u003C\u002Fp>\u003Cp>翻譯一下就是：失敗不是流程外的意外，而是流程的一部分。你要把失敗當成下一輪輸入，而不是當成流程結束。只要失敗資訊能進入下一輪，Agent 就會越來越接近正確答案。\u003C\u002Fp>\u003Cp>實操上，我會把失敗類型分門別類。比如語法錯誤、依賴錯誤、邏輯錯誤、格式錯誤、目標偏差。不同失敗對應不同修正策略。這樣 Agent 不會每次都從頭亂試，而是能針對性地調整。\u003C\u002Fp>\u003Cul>\u003Cli>語法錯：先修最小可執行版本。\u003C\u002Fli>\u003Cli>邏輯錯：回看目標和約束。\u003C\u002Fli>\u003Cli>格式錯：強化輸出模板。\u003C\u002Fli>\u003Cli>目標偏差：重新注入任務定義。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>別讓 Agent 自己猜完成標準\u003C\u002Fh2>\u003Cblockquote>資訊給少了，AI 缺少判斷依據；資訊給錯了，它可能在錯誤的方向上越走越遠；資訊給多了，它又抓不住重點。\u003C\u002Fblockquote>\u003Cp>這段話其實也能拿來解釋為什麼很多 Agent 總是「差一點」。不是它不會做，而是它不知道什麼叫「做到位」。完成標準如果不清楚，模型就會自己發明標準，而它發明出來的標準通常不可靠。它會偏愛看起來完整、語言漂亮、結構工整的結果，但未必真能交付。\u003C\u002Fp>\u003Cp>我以前寫過一個內容生成流程，最開始只要求「輸出一篇完整文章」。結果模型每次都能交，但總有一種「已經寫完了但沒說到點上」的感覺。後來我把完成標準拆成了幾個可驗證項：是否包含目標主題、是否覆蓋核心觀點、是否提供可執行步驟、是否引用了指定來源。加上這些後，結果立刻穩定很多。\u003C\u002Fp>\u003Cp>翻譯一下就是：完成標準要顯式化，而且最好是可檢查的。不要只寫「請認真完成」，這種話對模型沒有約束力。你得告訴它，什麼算完成，什麼算未完成，什麼情況要繼續循環。\u003C\u002Fp>\u003Cp>實操上，我會建議每個 Agent 任務都配一個 checklist。這個 checklist 不需要長，但必須具體。比如「包含 3 個步驟」「引用 2 個來源」「輸出可直接複製的模板」「測試通過後再結束」。只要標準能被檢查，循環就有了方向。\u003C\u002Fp>\u003Cp>我特別建議把「完成」和「滿意」分開。模型可能覺得自己已經很努力了，但你的標準不是努力，是交付。別心軟，交付標準要硬一點，不然流程會一直拖。\u003C\u002Fp>\u003Ch2>把循環寫成流程，不要寫成願望\u003C\u002Fh2>\u003Cp>如果只看概念，Loop Engineering 很容易被講成一句很空的話：讓 AI 反覆做、反覆改、直到完成。可真正落地時，你需要的是流程，而不是願望。流程意味著每一步都有輸入、輸出、判斷、轉移條件。沒有這些，循環只是一個漂亮的口號。\u003C\u002Fp>\u003Cp>我現在更願意把它理解成四個固定件：目標、狀態、動作、判定。目標決定方向，狀態告訴你現在在哪，動作負責推進，判定決定要不要繼續。只要這四個件齊了，Agent 才能從「會做」變成「做完」。\u003C\u002Fp>\u003Cp>這也是我覺得這篇知乎文章有用的地方。它沒有把 Loop Engineering 說成什麼神秘能力，而是把它放回工程問題裡：怎麼組織一套能反覆執行、能自我修正、能最終收斂的機制。說白了，這就是把「聰明」變成「可交付」。\u003C\u002Fp>\u003Cp>實操上，你可以先從一個最小閉環開始，不要一上來就搞複雜架構。先做一個「生成-檢查-修正」的三段式流程，跑通之後再加記憶、加工具、加多輪分支。很多人失敗不是因為想得不夠大，而是因為一開始就把系統做得太花，最後誰也不知道哪裡出了問題。\u003C\u002Fp>\u003Ch2>你可以直接拿去用的模板\u003C\u002Fh2>\u003Cp>下面這個模板我建議你直接複製，然後按自己的任務改。它的重點不是文風，而是結構：目標、上下文、執行、檢查、修正、停止條件，全都放進去。你可以把它用在程式碼 Agent、研究 Agent、寫作 Agent，甚至是內部自動化流程裡。\u003C\u002Fp>\u003Cpre>\u003Ccode># Loop Engineering Agent Template\n\n## 任務目標\n你要完成的最終結果是：\n- [寫清楚最終交付物]\n\n## 當前上下文\n你現在已知的資訊包括：\n- 專案背景：\n- 當前狀態：\n- 相關檔案\u002F資料：\n- 約束條件：\n- 歷史決策：\n\n## 執行規則\n1. 先閱讀任務目標和上下文。\n2. 制定當前輪次的最小可執行計畫。\n3. 執行計畫，輸出結果。\n4. 自檢結果是否滿足完成標準。\n5. 如果未滿足，說明失敗原因並修正。\n6. 重複 3-5，直到滿足停止條件。\n\n## 完成標準\n只有同時滿足以下條件，才算完成：\n- [條件 1]\n- [條件 2]\n- [條件 3]\n\n## 失敗分類與修正策略\n- 如果是格式錯誤：修正輸出結構。\n- 如果是邏輯錯誤：回到目標和約束重新判斷。\n- 如果是資訊不足：請求補充上下文或暫停執行。\n- 如果是測試失敗：根據失敗日誌定位問題並重試。\n\n## 每輪輸出格式\n### 當前輪次\n- 輪次編號：\n- 當前動作：\n- 產出結果：\n- 自檢結論：\n- 是否繼續：是 \u002F 否\n- 下一步計畫：\n\n## 停止條件\n滿足以下任一條件時停止：\n- 所有完成標準通過。\n- 連續 [N] 輪沒有實質進展。\n- 缺少關鍵上下文，無法繼續。\n- 出現不可恢復錯誤。\n\n## 最終輸出\n請輸出：\n1. 最終結果\n2. 完成情況說明\n3. 仍然存在的風險或未解決問題\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>我建議你在這個模板外面再加一層「檢查器」。如果是程式碼任務，就讓檢查器跑測試；如果是寫作任務，就讓檢查器查結構和事實；如果是研究任務，就讓檢查器核對引用和結論。這樣循環才不會只停留在「模型自評」。\u003C\u002Fp>\u003Cp>另外，別忘了給循環設定上限。無限循環聽起來很優雅，實際上就是浪費 \u003Ca href=\"\u002Ftag\u002Ftoken\">token\u003C\u002Fa> 和時間。你應該明確告訴系統：最多跑幾輪，沒收斂就停下來，轉人工或轉更強的工具。這個邊界非常重要，不然系統會把「堅持」誤解成「死磕」。\u003C\u002Fp>\u003Cp>如果你想看原文，可以從這裡開始：\u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2049084372561687197\">知乎文章《全網爆火的 Loop 到底是什麼？》\u003C\u002Fa>。我這篇是基於原文思路做的工程化拆解，很多表達和模板是我自己整理的，方便你直接拿去改進自己的 Agent 流程。\u003C\u002Fp>\u003Cp>我再補兩個相關參考：\u003Ca href=\"https:\u002F\u002Fplatform.openai.com\u002Fdocs\u002Fguides\u002Fagents\">OpenAI Agents 文件\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.anthropic.com\u002Fresearch\">Anthropic Research\u003C\u002Fa>，還有 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Flangchain-ai\u002Flangchain\">LangChain\u003C\u002Fa>。它們都在不同層面說明了一件事：長任務不是靠一次回答完成的，而是靠可控的循環推進。\u003C\u002Fp>","我把 Loop Engineering 拆成一套能直接拿去用的 Agent 完成任務模板，重點是讓模型自己檢查、修正、收斂到交付。","zhuanlan.zhihu.com","https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2049084372561687197",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782408826097-l6g3.png","ai-agent","zh","daccbfdf-46f3-432e-8b8d-aecb8198d1c1",[17,18,19,20,21],"Loop Engineering","Agent","Context Engineering","Prompt Engineering","工作流",[23,24,25],"Prompt 只能啟動任務，不能保證多步完成，長任務要靠循環控制。","Context Engineering 讓模型做對，Loop Engineering 讓模型做完，兩者要一起用。","把完成標準、失敗分類、停止條件寫清楚，Agent 才不會自己亂猜。",0,"2026-06-25T17:33:18.060707+00:00","2026-06-25T17:33:18.049+00:00","e3b68196-9e64-4c18-a3b6-a73e73bfb367",{"tags":31,"relatedLang":40,"relatedPosts":44},[32,34,37],{"name":33,"slug":33},"agent",{"name":35,"slug":36},"prompt engineering","prompt-engineering",{"name":38,"slug":39},"context engineering","context-engineering",{"id":15,"slug":41,"title":42,"language":43},"loop-engineering-agent-completes-tasks-en","Loop Engineering 让 Agent 把事做完","en",[45,51,57,63,69,75],{"id":46,"slug":47,"title":48,"cover_image":49,"image_url":49,"created_at":50,"category":13},"f5e73cf4-d736-48b7-b785-7bf20719e888","public-sentry-keys-hijack-claude-code-cursor-zh","公開 Sentry key 也能劫持 AI 編碼工具","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782413274580-aa9w.png","2026-06-25T18:47:30.891301+00:00",{"id":52,"slug":53,"title":54,"cover_image":55,"image_url":55,"created_at":56,"category":13},"daf7edd7-d904-4f35-afd6-9caeac32c633","codex-third-party-model-integration-guide-zh","Codex 接入第三方模型實作指南","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782396177606-l65z.png","2026-06-25T14:02:29.294216+00:00",{"id":58,"slug":59,"title":60,"cover_image":61,"image_url":61,"created_at":62,"category":13},"096d7c02-566e-48e1-b7cd-d8218c2d87f4","manus-ai-agent-app-ready-for-real-work-zh","Manus AI 證明代理式 App 已能上線做事","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782379976402-dvi4.png","2026-06-25T09:32:20.496499+00:00",{"id":64,"slug":65,"title":66,"cover_image":67,"image_url":67,"created_at":68,"category":13},"08c3c919-2446-4dda-85fb-c18b6ffc3b8d","grok-build-goal-autonomous-coding-zh","Grok Build 加上 \u002Fgoal，自動寫碼更像樣了","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782374588023-auvp.png","2026-06-25T08:02:38.465826+00:00",{"id":70,"slug":71,"title":72,"cover_image":73,"image_url":73,"created_at":74,"category":13},"0e808308-2bd5-4fc0-a664-698df223abc4","anthropic-claude-tag-research-slack-search-zh","Claude 讓 Slack 變研究庫","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782285516725-yjy9.png","2026-06-24T07:18:02.774232+00:00",{"id":76,"slug":77,"title":78,"cover_image":79,"image_url":79,"created_at":80,"category":13},"8fe481ef-010f-431b-a837-22ccafa68438","benchmark-harness-quality-beats-model-hype-coding-zh","這個 coding benchmark 證明：harness 品質勝過模型光環","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782253062596-f192.png","2026-06-23T22:17:21.208723+00:00",[82,87,92,97,102,107,112,117,122,127],{"id":83,"slug":84,"title":85,"created_at":86},"4ae1e197-1d3d-4233-8733-eafe9cb6438b","claude-now-uses-your-pc-to-finish-tasks-zh","Claude 開始幫你操作電腦","2026-03-26T07:20:48.457387+00:00",{"id":88,"slug":89,"title":90,"created_at":91},"5bede67f-e21c-413d-9ab8-54a3c3d26227","googles-2026-ai-agent-report-decoded-zh","Google 2026 AI Agent 報告解讀","2026-03-26T11:15:22.651956+00:00",{"id":93,"slug":94,"title":95,"created_at":96},"2987d097-563f-46c7-b76f-b558d8ef7c2b","kimi-k25-review-stronger-still-not-legend-zh","Kimi K2.5 評測：更強，但還不是神作","2026-03-27T07:15:55.277513+00:00",{"id":98,"slug":99,"title":100,"created_at":101},"95c9053b-e3f4-4cb5-aace-5c54f4c9e044","claude-code-controls-mac-desktop-zh","Claude Code 也能操控 Mac 了","2026-03-28T03:01:58.58121+00:00",{"id":103,"slug":104,"title":105,"created_at":106},"dc58e153-e3a8-4c06-9b96-1aa64eabbf5f","cloudflare-100x-faster-ai-agent-sandbox-zh","Cloudflare 的 AI 沙箱跑超快","2026-03-28T03:09:44.142236+00:00",{"id":108,"slug":109,"title":110,"created_at":111},"1c8afc56-253f-47a2-979f-1065ff072f2a","openai-backs-isara-agent-swarm-bet-zh","OpenAI 挺 Isara 的 agent swarm …","2026-03-28T03:15:27.513155+00:00",{"id":113,"slug":114,"title":115,"created_at":116},"7379b422-576e-45df-ad5a-d57a0d9dd467","openai-plan-automated-ai-researcher-zh","OpenAI 想做自動化 AI 研究員","2026-03-28T03:17:42.090548+00:00",{"id":118,"slug":119,"title":120,"created_at":121},"48c9889e-86df-450b-a356-e4a4b7c83c5b","harness-engineering-ai-agent-reliability-2026-zh","駕馭工程：從「馬具」到「作業系統」，AI Agent 可靠性的終極密碼","2026-03-31T06:42:53.556721+00:00",{"id":123,"slug":124,"title":125,"created_at":126},"96d8e8c8-1edd-475d-9145-b1e7a1b02b65","mcp-explained-from-prompts-to-production-zh","MCP 怎麼把提示詞變工作流","2026-04-01T09:24:39.321274+00:00",{"id":128,"slug":129,"title":130,"created_at":131},"f2ca7720-b471-4ce5-9336-2a9ac2a876fd","amazon-bedrock-agents-multi-agent-workflows-zh","Amazon Bedrock Agents 進入多代理工作流","2026-04-01T09:30:29.945429+00:00"]