這是 GitHub 上一個有 50K+ 星星的開源專案，核心概念超狂：把華倫・巴菲特、彼得・林區、凱西・伍德這些傳奇投資家的投資理念寫成 AI Agent，讓他們獨立分析同一支股票，最後由一個「投資組合經理」整合所有意見，決定買還是賣。
聽起來像科幻小說，但實際上它展示了 LangGraph 這套框架有多扯。這不是什麼「自動賺錢機」——完全不會執行真實交易，純粹拿來學習投資哲學和回測的工具。
架構分兩層：
投資家智能體（13 個）：每個都用大語言模型來推理
每個代理人有自己的風格。巴菲特會問「這家公司有沒有競爭護城河」，伍德會追問「十年後的成長潛力在哪」。這真的有夠猛——系統自動把各家投資邏輯轉成提示詞，讓 AI 扮演這些角色。
技術分析智能體（6 個）：用規則邏輯而不是 LLM
這個專案用了 LangGraph 的 StateGraph——說白了就是一個狀態機。執行流程像這樣：
這套模式在多 Agent 系統裡常見到，但 AI Hedge Fund 把它用在金融領域，展示得相當清楚。踩坑點少（如果你知道怎麼設置 LangGraph 的話）。
環境：需要 Python 3.11+ 和 Poetry
1 | poetry install |
LLM 支援：這裡真香——不只 OpenAI，還支援 Anthropic、DeepSeek、Google、Groq，甚至 Ollama 本機執行。想用什麼模型就用什麼，只要設定環境變數即可。
介面：自帶 React + FastAPI 的網頁 UI，不用命令列操作也行。Docker 也支援，懶得裝依賴直接容器化。
這東西不是要你丟三萬塊進去自動賺錢。真正有價值的地方：
坦白說，LLM 在金融領域的應用常常很虛。AI Hedge Fund 這個專案扯欸的地方在於：它沒有吹牛，直接展示了多 Agent 架構如何應用到實際問題，且代碼夠清晰讓你理解邏輯。
MIT 授權，代碼開放，有社群。無論你是想學 LangGraph、多 Agent 系統，或單純對 AI 投資感好奇，都值得 clone 下來試試。
]]>
這是 GitHub 上一個有 50K+ 星星的開源專案，核心]]>
Google 在 4 月 10 號給 Gemini 加了新功能，現在可以生成互動式 3D 模擬和模型。使用者只要下個提示詞，像是「幫我視覺化看看」之類的，Gemini 就能把概念變成可以轉動、調整的 3D 模型。舉例來說，可以讓它模擬雙裂縫實驗的動畫版，還能即時調整各種變數。
這功能對教育和概念驗證來說真的蠻有用的。不用自己寫程式或摸其他工具，直接跟 AI 對話就能出來一個可視化的東西。當然，生成速度和準度還是會有起伏，但整個方向是對的。目前在 gemini.google.com 上可以用，需要 Pro 版本。
原文來源：Google launches interactive 3D simulations for Gemini chatbot
Cursor 這家公司到 3 月已經衝到年經常性收入 20 億美金，其中約 60% 來自企業客戶，包括 OpenAI 和 AB InBev 這些咖。現在還在洽談新一輪融資，估值大概砍到 500 億美金。
要確欸，從去年 11 月融資時的 293 億美金估值來看，這次會不會就是估值調整。不過看他們的技術表現，Copilot 在 SWE-Bench 拿到 56%，Cursor 是 51.7%，但 Cursor 快 30%，效率優勢還是滿明顯的。企業客戶願意給這麼多錢，代表他們確實看到 ROI。
原文來源：Cursor AI 融資情報彙整
在 RSAC 2026 年會上，CVE 委員會成員開始認真討論一個問題：AI 生成的漏洞報告在過去三個月增加了 224%。這看起來爆量，但其實反映了一個更深層的問題——用什麼機制來篩選、驗證這些海量的 AI 產出報告。
CVE 程式已經 26 歲了，由 MITRE 管理，CISA 贊助，去年四月還經歷過一波資金危機，後來才被列入「above the line」預算。現在的困境是，整個系統的運轉還是很仰賴人工審核和驗證，AI 報告的暴增反而加重了「人力膠水」的負擔。長期怎麼改進流程、提升自動化驗證的比例，這才是真正的課題。
歐盟 AI 法案在 8 月 2 號就要對高風險 AI 系統（Annex III）全面執法了。這涵蓋生物識別、就業、信用評分、教育、執法等敏感領域。到時候透明度規則和第 50 條的義務都會生效，違反禁止性規定的罰則是 3500 萬歐元或全球營收的 7%，擇其高者。
每個歐盟會員國還得建立 AI 監管沙盒。芬蘭是第一個去年 12 月就有完整執法權的國家。不過最新的 Digital Omnibus 提案可能會把期限條件性地延到 2027 年 12 月，看後續怎麼推進。對科技公司來說，合規的時鐘已經在跑了，不能再拖。
原文來源：EU AI Act 2026 updates: Compliance requirements and business risks
Axios 在 4 月 6 號挖到的獨家新聞：Meta 打算把下一代 AI 模型的版本開源釋出。這延續了 Meta 這幾年在開源 AI 上的策略。
最近幾個月開源陣營真的很猛，GLM-5.1（744B MoE、MIT License）、DeepSeek-V3.2、NVIDIA Nemotron/Alpamayo 都陸續發佈，效能還一直霸佔排行榜。Meta 加入這波浪潮，等於是賭開源模型的未來。這策略對整個生態來說有利，但對專有模型廠商的壓力也不小。
]]>原文來源：Meta plans to open-source versions of its next AI models
]]>
台灣的《人工智慧基本法》在去年 12 月三讀通過，於今年正式上路。身為一個在科技圈摸爬滾打多年的工程師，我發現自己的日常工作開始被一個全新的東西主宰——不再只是演算法效率和系統架構，還要考慮「法規風險等級」。
說真的，一開始聽到「基本法」這個詞有點 OO——感覺像是什麼憲法級的東西。但看下去才明白，這其實是台灣首部專門針對 AI 的立法，定義了七項核心原則：人權保障、隱私保護、問責性、透明可解釋性……等等。更實際的是，政府底下成立了「人工智慧策略委員會」，數位發展部（MODA）會負責建立 AI 風險分類框架。
這有多重要？簡單說，未來公司採購 AI 服務時，第一個問題可能就不是「效能夠不夠快」，而是「這個工具是第幾級風險」。
政府也跟著投錢——2026 年編了 180 億台幣預算，重點砸在五個「可信任產業」：半導體、AI、國防、資安、次世代通訊。這份清單有意思——台灣的優勢產業都被圈進去了。
關鍵轉折點在於比較歐盟。
歐盟的 AI 法（EU AI Act）今年 8 月就要開始對「高風險」應用強制執法。人臉辨識、徵才演算法、信用評分、教育評量……這些全部都列為高風險。只要不符合歐盟規格？罰款 3500 萬歐元或全球營業額的 7%——哪個比較大就罰哪個。每個歐盟成員國還要建立 AI 監管沙盒，芬蘭早就在 2025 年 12 月率先啟動完整執法了。
台灣的策略完全不同。基本法採用「原則導向」框架，比較像是定義遊戲規則和精神，而不是逐項列舉「什麼東西絕對禁止」。簡單講，歐盟是處方簽，台灣是指南針。
這各有好壞。歐盟的好處是明確——開發者知道界線在哪，「不要碰」就行。但缺點是僵化，得等法律更新才能適應新的風險型態。台灣的原則導向比較靈活，但執行的時候就考驗監管機關和業界的默契了。說實話，我有點擔心這會不會最後淪為「紙上談兵」。
讓我扯回實務層面。
首先，招聘會變得有趣。公司開始需要懂「法規 + 治理 + 技術」的混合型人才。不是只會寫 Python 的工程師，而是能夠評估自己寫的程式碼可能觸及哪些法規風險的人。這個市場缺口會慢慢浮現。
再者，AI 工具的選型會改變。目前我們採購 AI 服務或套件時，考量點大多是精準度、延遲和成本。未來多半要加上「風險分類級別」這一項。低風險工具可以大膽用，高風險工具可能得層層審批，甚至某些組織根本用不了。
第三，台灣在這個位置有點尷尬。我們是全球 AI 晶片和計算力的主要供應方（TSMC、台灣的 GPU 代工……），卻還在討論「應該怎麼管 AI」。這不是什麼高深的觀察，但確實諷刺——造硬體的人比用軟體的人更懂 AI，結果軟體政策反而更先進。
政府標籤出五個「可信任產業」而不是「其他產業」，這本身就說了一個故事。意思是，如果你在做的東西不在這五個框框裡，AI 治理會有不同的標準。
這裡面還有個隱形的議題：資料中心電力。台灣的供電一直是個話題（缺電冬馬甲），AI 算力的爆炸成長需要龐大的電力支撐。這個基本法通過了，但電力配套有沒有跟上？這是另一個故事。
我不會天真的認為一部基本法會立刻改變什麼。真正的轉折點是「執行」——監管機關、業界、學術界要好好溝通，確保這套框架是可運作的，而不是變成另一份沒人讀的政府文件。
但從好的角度想，台灣至少開始了對話。我們不再只是「科技跟進者」，而是在試著定義自己的遊戲規則。對一個靠科技吃飯的國家來說，這很重要。
下次開會時，如果 PM 又提新的 AI 特徵，我還是會問那一句話。但這一次，大概會有更多人思考背後的原因，而不是一片沉默。
]]>參考來源：立法院三讀通過《人工智慧基本法》 - 數位發展部
參考來源：台灣AI治理新紀元 - 台灣人工智慧學校
參考來源：EU AI Act 2026 Updates - Legal Nodes
台灣的《人工智慧基本法》在去年 12 月三讀通過，於今年正式上路。身為一個在科技圈摸爬滾打多年的工程師，我發現自己的日常工作開始被一個全新的東西主宰——不再只是演算法效率和系統架構，還要考慮「法規風險等級」。
AWS 的 Kiro IDE 最近釋出了新的 CLI 版本，重點是加入了 --autopilot、--mode 和 --plan 這三個參數，讓使用者可以直接跳到特定的 agent 模式工作，不用每次都從零開始。以前的 /agent generate 流程現在也整合進 /agent create，預設就會開啟 AI 輔助模式。
Kiro 的策略很清楚：先寫 spec，再生成程式碼。跟 Cursor、Windsurf 這些編輯器比起來，Kiro 更強調規格驅動，這對團隊協作來說還滿實用的，尤其是當你需要在代碼生成之前確認需求的時候。新的 CLI 改動看起來不大，但減少了使用者的操作步數，這種 friction 的消除在日常工作中還是有差的。
微軟在 4 月 3 號發布了 Agent Framework 1.0，主要是把 MCP（Model Context Protocol）和 A2A（Agent-to-Agent）通訊都納入正式支援，.NET 和 Python 現在都能用。他們把 MCP 當作資源層來用，A2A 負責跨框架的 agent 協作，這個分層的設計還滿聰明的。
最有趣的是那個瀏覽器版的 DevUI debugger，可以即時看到 agent 的執行流程，這對除錯確實省事不少。而且 Linux Foundation 的 AAIF 現在管理 MCP 和 A2A，代表這些標準真的往產業化方向走。框架本身支援了一大堆模型和工具，只要 MCP 有定義，基本上都接得起來。
WordPress 官方終於把 @wp-playground/mcp 套件推出來了，這下子 Claude Code 或 Gemini CLI 就能直接連上 Playground，透過 WebSocket 來管理 WordPress 站點。不用 SSH、不用複雜的設定，一行指令就能把 AI agent 接進去。
從裝外掛、建立內容到執行 PHP、管理用戶、跑 WP-CLI 指令，agent 都能做。連線是本地的，用 token 認證，資料都留在你的機器上，安全性這邊還滿放心的。這對想要自動化網站維護的人來說，根本是天選之物——想像一下，跟 Claude 說「幫我更新所有外掛」，然後它自己去跑，這效率才是真的。
昨天才剛報了 CVE-2026-39888（沙箱逃逸），今天 PraisonAI 又被爆出 CVE-2026-39890，這次是 YAML 反序列化遠端程式碼執行，CVSS 評分直接 9.8。問題在於 AgentService.loadAgentFromFile 用的 js-yaml 沒有禁用 !!js/function 和 !!js/undefined 標籤，攻擊者只要上傳一個惡意的 agent 定義檔，YAML 解析時就會自動執行 JavaScript 程式碼。
這兩個漏洞接連爆發，說明 PraisonAI 的安全審查可能不夠嚴格，或者是快速開發時沒有把安全當一回事。已經修復在 4.5.115 版本了，但用舊版本的人得趕快升級，不然真的有風險。這也提醒我們 agent framework 既然要執行動態程式碼，安全邊界要畫得特別清楚。
GitHub 把 Copilot SDK 放進公開預覽階段，現在開發者可以把 Copilot 的 agentic 能力嵌進自己的應用裡。Cloud agent 也更新了安全機制，加了代理防火牆讓你控制網際網路存取權限。而且現在 agent 簽署的每一個 commit 都有簽名驗證（provenance tracking），這樣就能追蹤程式碼的來源。
GitHub 還順帶淘汰了一些模型，4 月 1 號開始整個 Copilot 體驗都不再支援那些舊模型。SDK 公開預覽代表他們想讓更多開發者進來玩，看能找出什麼問題，為正式版做準備。這對想要把 AI 整合進內部工具的團隊來說，終於有個官方的套件可以用。
]]>
Hermes Agent 跑在背景裡，靜靜地執行各種工作。但它的大腦到底存了什麼資料、記憶怎麼組織、成本怎麼算，這些都藏在 ~/.hermes/ 這個資料夾的各種檔案裡——SQLite、Markdown、YAML、JSON 一堆。要看懂這些原始資料，真香的辦法就是一個視覺化的監控面板。這就是 Hermes HUD Web UI 登場的時刻。
Hermes HUD Web UI 是 Hermes HUD 的網頁版本。TUI 版本給你命令列的純粹感，Web 版本就更直覺、更適合長期監看。它用圖表、卡片、即時更新，把 Agent 的內部世界呈現出來。
這個面板不是簡單的可視化工具。設計上採用了 讀寫分離 的思路——你只能看，不能改。這聽起來像是限制，其實是保護。Agent 執行中如果面板能隨意修改狀態，那踩坑的機會太多了。只讀設計確保你的監控動作絕不會搞亂 Agent 的運作。
10 個監控面板包括：Dashboard（總覽）、Memory（記憶體系）、Skills（技能庫）、Sessions（工作階段）、Cron（排程任務）、Projects（專案）、Health（健康狀態）、Agents（Agent 列表）、Profiles（設定檔）、Token Costs（成本統計）。每一個都是從 ~/.hermes/ 直接讀取資料，串聯起來呈現 Agent 的完整樣貌。
前端用的是 React 19，搭配 Vite 做打包、SWR 處理資料快取、WebSocket 吃即時更新。這套組合讓介面反應夠快，不會卡頓。後端是 FastAPI，負責讀取 ~/.hermes/ 裡的各種檔案，經過處理後透過 WebSocket 推送給前端。
有趣的是，整個系統的相依套件極簡。後端只需要 4 個套件，前端也只要 4 個。這在現代 Web 開發裡有夠難得，大多數專案早就被套件海淹沒。這也太香了吧，少依賴代表維護成本低、安全漏洞少、部署快速。
實時更新不是用傳統的輪詢（polling），而是靠 WebSocket 搭配檔案監看。後端監控 ~/.hermes/ 資料夾，一旦檔案有異動就透過 WebSocket 主動推送給前端。這樣既省資源，又能確保你看到的東西永遠是最新的。
看起來簡單的實時更新，其實背後有套講究的快取機制。系統用 mtime 搭配 MD5 雜湊值，針對不同資料型別設定不同的快取生命週期（TTL）。Memory 資料可能快取 30 秒，Projects 資料可能快 60 秒。這樣既不會過度計算，也不會讓資料太舊。
這種漸進式的快取策略看似複雜，卻是 Web 應用必學的技巧。特別是當你要監控 Agent 這種常態執行、資料量龐大的東西，稍微設計不當就容易變成效能災難。
介面提供四種視覺主題：Neural Awakening（神經覺醒）、Blade Runner（銀翼殺手）、fsociety（駭客軍團）、Anime（動漫風）。每一種都有自己的配色和氛圍。如果你長期盯著監控面板，至少讓眼睛不會被單調的灰色折磨。
最特別的是 CRT 掃描線效果，這是致敬老式陰極射線管螢幕的懷舊細節。扯欸，科技越來越現代，反而去模仿 30 年前的東西。但這種懷舊感確實有種魔力，讓人工智慧的監控面板多了份復古的科幻感。
鍵盤快捷鍵支援也很完整。按 Ctrl+K 喚出命令列（Command Palette），可以快速切換面板、篩選資料。習慣用鍵盤的人會很享受這種效率。
Hermes HUD Web UI 在 GitHub 上有 464 顆星。這個數字代表了一個小而精的開源專案被夠多人看見。不是 10 萬顆星的爆款，但也不是無人問津的邊角工具。通常這種規模的專案社群反應最誠摯，也最聚焦。
MIT 授權意味著你可以自由使用、修改、甚至商用。這對想整合或延伸功能的開發者來說，最大化了靈活性。
Hermes HUD Web UI 不是孤立的。它的孿生兄弟 hermes-hud 是 TUI 版本，適合純終端環境。而它們共同監控的 Hermes Agent，才是整個故事的主角。要充分利用這些工具，得先理解 Agent 在幹什麼。
這三者構成了一個完整的生態。Agent 做事，HUD 和 HUD Web 看監控，再根據監控結果調整 Agent 的行為。這種反饋迴圈對 Agent 系統至關重要。
如果你在開發 Hermes Agent，Hermes HUD Web UI 基本上是必備工具。它能讓你快速掌握 Agent 的狀態、發現問題在哪裡、追蹤成本是否超支。特別是當 Agent 執行的工作越來越複雜，這種即時監控就越來越寶貴。
甚至在生產環境，把這個面板當成 Agent 健康狀態的儀表板，也是很合理的用法。讀寫分離的設計確保你監控的同時，不會不小心干擾 Agent 的運作。
最後，如果你在調試 Agent 的記憶體系統或成本計算，Web UI 的各個面板能讓你視覺化看到邏輯的結果，比起翻 JSON 檔案快一百倍。
]]>
Hermes Agent 跑在背景裡，靜靜地執行各種工作。但它的大腦到底存了什麼資料、記憶怎麼組織、成本怎麼算，這些都藏在 ~/.hermes/ 這個資料夾的各種檔案裡——SQLite、Markdown、YAML、JSON 一堆。要看懂這些原始資料，真香的辦法就是一個視覺化的監控面板。這就是 Hermes HUD Web UI 登場的時刻。
這個問題有多嚴重？某次 slack 裡同事分享了一篇研究，久坐超過 9 小時，死亡風險增加 22%。如果每天坐滿 10 小時以上，心血管死亡風險更直接升到 34%。我看著自己的工時紀錄，有點破防。
竹科現在已經不流行「爆肝」了。台積電蓋了兩座運動館、十六面球場，聯發科還有職籃等級的籃球場。這不是公司在做善事，是他們發現工程師坐死了比坐出 bug 更划不來。看看大廠都在轉型健身，我們這些每天和 code 黏在一起的人該認真了。
有夠誇張的是，久坐不只是單純的腰痛。血液循環變差、肌肉萎縮、代謝下降，整個身體系統都在罷工。最絕的是，再怎麼健身房練習也補不回來。根據 Applied Ergonomics 2021 的研究，他們比較了全坐、全站、交替三個方案：
交替才是王道。不是說一定要全天站著，那真的有夠累，而是要在坐和站之間切換。
最簡單的方法就是記住這個數字組合。每 30 分鐘一個循環：
根本不用花額外時間，只是改變工作姿勢。Reddit 上有一堆工程師推薦這招，尤其遠端工作的人更要做，因為沒有上下班的強迫走路，真的有可能從早坐到晚。
我朋友花了八千塊買電動站立桌，用了一個月，現在當書架。這東西不是不行，但很多人的誤解就是「買了站立桌就可以健康」。實際上，站整天跟坐整天一樣爛，重點還是交替。如果你會忘記站起來，那再貴的桌子也沒用。
建議是設個鬧鐘，每 40 分鐘提醒自己一次。手機、電腦、smartwatch 都可以，別等到身體發出警訊才動。
既然坐著最多，那就從座位上開始。Reddit 和健身社群推薦這幾個零成本的動作：
還有一個笑死的研究：4 秒高強度運動 - 就是全力衝刺，只要 4 秒，連續做幾個循環。結果是血脂下降 31%。有夠誇張對吧？
疫情後遠端變常態。很多人以為在家工作比較健康，實際上是最容易久坐的陷阱。沒有通勤、沒有去會議室的走路、甚至廁所也裝得很近，整天可以真的不動。我認識的幾個遠端工程師，開會時才發現自己已經坐了 11 小時，褲子都勒進肉裡。
遠端工作更要強制自己動起來。不管是站立桌、鬧鐘提醒，還是乾脆把廁所裝在遠一點的地方（認真的），都要破壞這個坐著的舒服陷阱。
五年前，竹科工程師的話題是「爆肝怎麼熬」、「颱風天還在 sprint」。現在的年輕工程師，題目變成「廠區健身房怎麼約」、「籃球場隊伍在徵人」。大廠主動投入資源做這件事，不是因為他們變善心，是因為會坐出病的工程師，工作效率比會爆肝的人更爛。
連高層都認可了，我們還有什麼理由不動？
健康不會因為你 deadline 急就自動暫停。腰痛、血栓、代謝差，這些事一旦纏上身，修復的時間比你想像得長。與其等到身體報警才後悔，不如從現在開始改變。
設個鬧鐘，每 30 分鐘站起來。這不是廢話，是真的會改變。
而且，站著想 code，有時候靈感就自己跑出來了。試試看吧。
參考資源：
]]>這個問題有多嚴重？某次 slack 裡同事分享了一篇研究，久坐超過 9 小時，死亡風險增加 22%。如果每天坐滿 10 小時以上，心血管死亡風險更直接升到 34%。我看著自己的工時紀錄，有點破防。
竹科現在已經不流行「爆肝」了。台積電蓋了兩座運動館、十六面球場，聯發科還有職籃等級的籃球場。這不是公司在做善事，是他們發現工程師坐死了比坐出 bug 更划不來。看看大廠都在轉型健身，我們這些]]>
4/8 Anthropic 推出 Claude Managed Agents，把上面這些全包了。你只要定義「agent 要做什麼」，基礎設施的部分 Anthropic 幫你扛。目前是公開測試版，所有 API 帳號都能用。
在動手之前，先搞清楚四個東西的關係：
| 概念 | 是什麼 | 類比 |
|---|---|---|
| Agent | 模型 + system prompt + 工具 + MCP servers | 職位說明書 |
| Environment | 容器設定（套件、網路規則、檔案掛載） | 辦公室環境 |
| Session | 一個正在跑的 agent 實例 | 一次工作任務 |
| Events | 你跟 agent 之間的訊息交換 | 對話和指令 |
Agent 定義一次，可以跨多個 Session 重複使用。Environment 也是——配好一個環境，所有 Session 都能引用。Session 是實際跑任務的地方，每個 Session 有獨立的檔案系統和對話歷史。
如果你已經在用 Claude API 的 Messages endpoint 搭配自己的 agent loop，可能會問：Managed Agents 跟我自己做的有什麼差？
| Messages API | Managed Agents | |
|---|---|---|
| 定位 | 直接存取模型 | 預建的 agent 執行環境 |
| 適合 | 需要細緻控制 agent loop | 長時間執行、非同步任務 |
| 基礎設施 | 自己搭 | Anthropic 代管 |
| 工具執行 | 自己實作 | 雲端沙箱自動執行 |
| 狀態管理 | 自己處理 | 內建 checkpointing |
簡單說：Messages API 給你最大的自由度，Managed Agents 給你最快的上線速度。如果你的 agent 需要跑幾分鐘到幾小時、需要安全的容器環境、而且不想自己管基礎設施——Managed Agents 就是為你設計的。
需要三樣東西：
1 | # macOS |
1 | # Python |
設定 API key：
1 | export ANTHROPIC_API_KEY="your-api-key-here" |
Agent 就是一份「職位說明書」——定義用哪個模型、system prompt 寫什麼、可以用哪些工具。
1 | from anthropic import Anthropic |
agent_toolset_20260401 是全套內建工具——bash、檔案操作、網頁搜尋等等。建立完會拿到一個 agent.id，後面每個 Session 都要用到。
用 ant CLI 也能做同樣的事：
1 | ant beta:agents create \ |
Environment 定義容器的設定——裝什麼套件、網路怎麼開、要不要掛載檔案。
1 | environment = client.beta.environments.create( |
unrestricted 代表容器可以存取外部網路。如果你的 agent 不需要上網，可以設定限制來提高安全性。
有了 Agent 和 Environment，就能啟動 Session 了：
1 | session = client.beta.sessions.create( |
Session 建立後，Anthropic 會在背景 provision 一個容器。
重頭戲來了。開啟 SSE 串流，送出使用者訊息，然後即時收到 agent 的回應：
1 | with client.beta.sessions.events.stream(session.id) as stream: |
跑起來大概長這樣：
1 | 我來寫一個 Python 腳本計算費波那契數列。 |
整個過程中，Claude 自己決定要用什麼工具、自己寫程式碼、自己執行、自己驗證結果。你只要送訊息和收串流。
當你送出 user event，Managed Agents 依序做了這些事：
session.status_idle你也可以在 agent 執行途中送新的 user event 來引導方向，或者中斷它改做別的事。
agent_toolset_20260401 包含的工具：
如果不想給全套工具，也可以只啟用特定工具。
市面上做類似事情的不只 Anthropic。OpenAI 的 Codex 有自己的 sandbox 環境，但走的是 ChatGPT 整合路線而不是獨立 API。Google 的 Gemini API 支援 function calling 但沒有代管的 agent 執行環境。Kiro 和 Cursor 則專注在 IDE 端的 agent 體驗。
Managed Agents 的差異化在於：它是純 API 服務，不綁任何 UI。你可以用它建 Slack bot、內部工具、CI/CD pipeline、自動化工作流——任何需要 AI agent 跑在雲端的場景都行。
標準 Claude token 費 + $0.08/session-hour。
session-hour 只算 active runtime。如果 agent 跑了 15 分鐘就完成，你付 $0.02 的基礎設施費加上 token 用量。跟自己維護一台 sandbox 伺服器的成本比，對大多數使用量來說便宜太多。
幾個要留意的地方：
managed-agents-2026-04-01 beta header（SDK 會自動加）自動化程式碼審查：建一個 agent 接 GitHub webhook，每次有 PR 就自動跑 review，把結果寫回 PR comment。Managed Agents 的沙箱環境讓它能安全地 clone repo 和跑測試。
資料處理 pipeline：讓 agent 定期抓取外部資料、做清洗和轉換、產出報告。長時間執行正是 Managed Agents 的強項。
內部工具 bot：在 Slack 或 Teams 裡接一個 agent，讓團隊用自然語言操作內部系統。Managed Agents 處理 session 管理和工具執行，你只需要寫 Slack 整合的部分。
從自己搭 agent loop 到用 Managed Agents，開發時間可以從幾週壓縮到幾天。$0.08/hr 的代價換來的是不用管沙箱、不用管狀態、不用管重試邏輯。對大多數企業級 AI agent 的場景來說，這個取捨很划算。
]]>原文來源：Claude Managed Agents overview
原文來源：Get started with Claude Managed Agents
參考來源：Claude Code in Action - Anthropic Academy
4/8 Anthropic 推出 Claude Managed Agents，把上面這些全包了。你只要定義「agent 要做什麼」，基礎設施的部分 Anthropic 幫你扛。目前是公開測試版，所有 API 帳號都能用。
4/8 Anthropic 推出 Claude Managed Agents 公開測試版。核心概念：你定義 agent 要做什麼（system prompt、工具、模型），Anthropic 負責跑起來——沙箱執行、狀態管理、agent loop、工具呼叫全部代管。
用法分四步：建立 Agent 定義 → 設定 Environment（預裝套件、網路規則、掛載檔案）→ 啟動 Session → 透過 SSE 串流互動。內建工具包含 bash、檔案操作、網頁搜尋、程式碼執行。整個流程可以用 Claude Console 操作，也可以用新推出的 ant CLI，或直接在 Claude Code 裡面用 claude-api Skill。
定價是標準 token 費 + $0.08/session-hour。Notion、Rakuten、Sentry 已經在用了。Anthropic 自己的測試顯示，在結構化檔案生成任務上，Managed Agents 比標準 prompting loop 的成功率高出最多 10 個百分點，而且最難的任務改善幅度最大。
對開發者來說這解決了一個很現實的問題：自己搭 agent 基礎設施太花時間。sandboxing 要做、state 要管、retry 要寫、觀測性要加——Managed Agents 把這些全包了。$0.08/hr 的代價換來的是「幾天上線」而不是「幾個月搭建」。
4/9 OpenAI 宣布新的 $100/月 ChatGPT Pro 訂閱方案，提供比 Plus（$20/月）多 5 倍的 Codex 用量。五月底前訂閱還有限時加碼到 10 倍。
OpenAI 現在的訂閱階梯變成三層：Plus $20（基本）、Pro $100（5x 額度 + Pro 專屬模型 + 無限 Instant/Thinking）、Pro $200（20x 額度，重度使用者）。同時 Business 年費從 $25 降到 $20/seat，另外新增了 Codex seat——只付 Codex 用量不含 ChatGPT，按 credit 計費。
CNBC 的報導直接寫了：這個定價就是來對標 Anthropic 的。Claude 長期有 $100/月的 Max 方案，OpenAI 終於補上了中間價位帶。Engadget 的評語更直白：「OpenAI has a new $100 ChatGPT Pro plan to better match up with Claude.」
AI coding 工具的價格戰升溫。對使用者來說好消息是選擇變多了。
GitHub Copilot 在 VS Code 的三月更新包（4/8 公告）裡塞了幾個重要功能。最醒目的是 Autopilot——公開預覽的全自主 agent session。跟之前的 agent mode 不同，Autopilot 不需要你在旁邊一直 review，它會自己跑完整個工作流。
其他更新包括：整合瀏覽器除錯（agent 可以直接操作瀏覽器）、chat 支援圖片和影片輸入、新的統一編輯器管理 chat 客製化設定。CLI 那邊也有動作——現在可以接自己的模型 provider 或跑完全本地的模型，不一定要走 GitHub 的 routing。
另外一個實驗性功能叫 Rubber Duck，幫助改善 LLM 在 coding 時的表現。SDK 也進入公開預覽，讓開發者把 Copilot 的 agent 能力嵌入自己的應用。
Autopilot 的方向跟 Cursor 3 的 agent-first 設計、Claude Code 的 Auto Mode 是同一個趨勢——AI coding 工具正在從「輔助」走向「自主」。差別在於各家的安全護欄和品質控管機制。
4/8 揭露，PraisonAI（一個多 agent 協作框架）的 execute_code() 函數存在沙箱逃逸漏洞，CVSS 9.9。攻擊者不需要認證就能遠端執行任意 Python 程式碼。
技術細節：AST-based 黑名單不完整。subprocess 路徑只擋了 11 個屬性名，但直接執行路徑擋了 30+。關鍵的 frame-traversal 屬性（__traceback__、tb_frame、f_back、f_builtins）在 subprocess 清單裡全部缺席。攻擊者提交一段觸發 caught exception 的程式碼，沿著沒被擋的 frame-traversal 屬性一路爬到真正的 builtins dict，拿到 exec 函數，沙箱就形同虛設了。
受影響版本是 1.5.115 之前的所有 PraisonAI，已修補。
加上之前的 Langflow（9.3）、Flowise（10.0）、n8n（10.0）、MLflow（10.0），AI 框架的資安紀錄繼續慘。這些工具為了讓 AI 方便執行程式碼，開了各種 exec/eval 的口子，結果沙箱實作品質參差不齊。「AST 黑名單」這種防禦方式本質上就是在跟攻擊者玩貓抓老鼠——你漏一個屬性，整條防線就崩了。
夾在 Managed Agents 的大新聞裡，Anthropic 同時推出了 ant CLI——一個用 Go 寫的 Claude API 命令列工具。不是 Claude Code（那是 agentic coding），ant CLI 是純粹的 API 客戶端，讓你在終端機裡直接跟 Claude API 互動、用 YAML 管理 API 資源版本。
1 | go install 'github.com/anthropics/anthropic-cli/cmd/ant@latest' |
另一個：Claude Cowork 正式 GA。macOS 和 Windows 版本對所有付費訂閱者開放，不再是 research preview。Cowork 是 Claude Desktop 裡讓 AI 直接操作你電腦檔案的模式——可以讀寫文件、跑 shell 指令、安排排程任務。從 preview 到 GA 代表 Anthropic 對穩定度有一定信心了。
原文來源：Anthropic scales up with enterprise features for Claude Cowork and Managed Agents
Anthropic 這週的策略很清楚：往上走企業代管服務（Managed Agents），往下補開發者工具鏈（ant CLI），中間把 Cowork 推到 GA。OpenAI 用 $100 Pro 方案追上定價缺口，GitHub Copilot 加入全自主模式。AI 工具的競爭焦點已經從「誰的模型比較聰明」轉移到「誰的基礎設施比較完整」。資安那邊，AI 框架被打穿的故事每週都在上演——沙箱不是加了就好，得加對。
]]>微軟的 MarkItDown 就是為了解決這個前處理痛點而生的。一行指令，把幾乎任何格式的檔案轉成 Markdown，保留標題、表格、清單的結構。97K+ stars，MIT 授權，三行 code 就能用。
主流 LLM 的訓練資料裡大量包含 Markdown。對模型來說，收到一份有 ## 標題和 | 表格的 Markdown，比收到一坨沒結構的純文字好懂太多，token 數也不會明顯增加。
MarkItDown 的定位很明確：不做高保真的文件格式互轉（那是 Pandoc 的事），專門為 LLM 管線設計的前處理工具。犧牲排版的視覺還原度，換取語意結構的完整保留。
覆蓋面有夠廣：
另外還能接 Azure Document Intelligence 處理 OCR 和公式提取，共 9 種格式。
1 | # 一行搞定 |
1 | from markitdown import MarkItDown |
沒有什麼設定要調，沒有什麼 config 要寫。裝完就是能用。
這是跟 Claude Code / Claude Desktop 搭配最方便的用法。裝完 MCP server 套件後，跟 Claude 說「幫我分析這份 PDF」，它會自動透過 MCP 把 PDF 轉成 Markdown 再處理。
1 | pip install markitdown-mcp |
提供一個 convert_to_markdown(uri) 工具，支援 STDIO、Streamable HTTP、SSE 三種模式。
處理 PowerPoint 投影片時，裡面的截圖和圖表怎麼辦？MarkItDown 可以接一個 OpenAI 相容的 client，自動用 LLM 生成圖片描述：
1 | from markitdown import MarkItDown |
不限定 OpenAI，任何符合 chat completion API 介面的 client 都能用——Ollama、vLLM、Azure OpenAI 都行。
用 Python 標準的 entry_points 做 plugin 發現。想支援新格式？寫一個 converter 註冊就好。
官方已有的 plugin：
Plugin 預設停用，需要明確啟用：
1 | markitdown --use-plugins document.pdf |
整個轉換流程很直觀：輸入檔案 → StreamInfo 猜測格式（副檔名 + MIME + Magika AI）→ 按優先級遍歷 Converter → accepts() 回 true 就執行 convert() → 輸出 Markdown。
每個 converter 只要實作 accepts() 和 convert() 兩個方法。Plugin 可以用較低的優先級數字搶先內建 converter，比如 markitdown-ocr 就是這樣取代內建的 PDF converter。
| 特性 | MarkItDown | Pandoc | Docling |
|---|---|---|---|
| 定位 | LLM 前處理 | 通用格式互轉 | 文件理解平台 |
| 輸出 | 僅 Markdown | 數十種格式 | Markdown / JSON |
| LLM 整合 | 原生支援 | 無 | 有 |
| MCP Server | 有（官方套件） | 無 | 無 |
| 重點 | 結構保留 + token 效率 | 高保真格式互轉 | 深度文件理解 |
要高保真格式互轉選 Pandoc，要深度文件理解選 Docling，要快速把檔案餵給 LLM——MarkItDown 就對了。
RAG 前處理是最常見的場景。把各種格式的知識庫文件統一轉成 Markdown，再做 chunking 和 embedding。ZIP converter 可以遞迴處理整個壓縮檔，裡面混合 PDF、DOCX、PPTX 都沒問題。
投影片內容提取也很實用。PPTX 轉 Markdown 時會保留投影片編號、標題、表格和圖表數據。搭配 LLM 圖片描述，連投影片裡的截圖都能「讀懂」。
MCP 整合的 AI 助手——透過 markitdown-mcp，讓 Claude Desktop 或 Claude Code 直接讀取任何格式的檔案，你只要說「幫我分析這份報告」就行。
1 | # 一次裝全部格式支援 |
需要 Python >= 3.10。音訊轉寫另外裝 ffmpeg，EXIF 提取裝 exiftool。
幾個要注意的地方。PDF 複雜排版（多欄、浮動圖片）可能丟失結構，最壞情況只能提取純文字。不支援舊版 .doc 格式，只吃 .docx。圖片僅 JPEG/PNG，WebP 和 SVG 不行。數學公式支援不完整。目前沒有 async API，大量檔案處理得自己管併發。
不過對大多數「把文件餵給 LLM」的場景來說，這些限制幾乎碰不到。三行 code 就能解決 80% 的文件前處理需求，這個投入產出比很划算。
]]>原文來源：MarkItDown GitHub Repo
參考來源：MarkItDown MCP Server (PyPI)
微軟的 MarkItDown 就是為了解決這個前處理痛點而生的。一行指令，把幾乎任何格式的檔案轉成 Markdown，保留標題、表格、清單的結構。97K+ stars，MIT 授權，三行 code 就能用。
Stripe 的工程團隊把內部的 AI coding agent 系統 Minions 正式搬上檯面。數字很嚇人：每週自動產出超過 1,300 個 pull request，所有程式碼都經過人類 review。
跟 Copilot 或 Cursor 不同，Minions 不是互動式的程式碼補全工具。它走的是 one-shot 模式——從 Slack thread、bug report 或 feature request 接收任務描述，自己從頭把程式碼、測試、文件全部生出來。背後用的是 Blueprint 架構：部分步驟是確定性的（跑 linter、推 code），部分步驟讓 AI 自由發揮。
實際表現呢？配置調整、依賴升級、小規模重構這類定義明確的任務，Minions 做得不錯。碰到測試失敗，agent 最多嘗試修兩次，修不好就交還人類——這個設計比讓 AI 無限 retry 要聰明得多。
1,300 PR/week 聽起來很猛，但 Stripe 的 codebase 規模也是巨獸等級。真正值得觀察的不是數字本身，而是 Blueprint 這個「確定性 + 彈性」的混合架構——這可能是企業級 AI coding agent 的設計範本。
原文來源：How Stripe built Minions - AI coding agents that ship 1,300 PRs weekly
Anthropic 發布了 Claude Code Analytics API，讓企業組織可以程式化存取 Claude Code 的每日使用數據。endpoint 是 /v1/organizations/usage_report/claude_code，需要 Admin API key（以 sk-ant-admin 開頭）。
能追蹤的指標包括：開發者 session 數、透過 Claude Code 新增/刪除的程式碼行數、commit 數、PR 數、各工具（Edit、Write、NotebookEdit）的接受率和拒絕率，還有成本分析。數據延遲約 1 小時，每筆記錄代表一個使用者一天的活動。
重點：完全免費，所有有 Admin API 存取權的組織都能用。
這個 API 解決的痛點很具體。導入 AI 工具後，管理層最常問的問題就是「到底有沒有提升生產力」。之前只能靠問卷和感覺，現在有量化數據了。當然，「AI 新增的程式碼行數」跟「實際生產力提升」之間的關係還是得打折扣看，但至少有了起點。
Google 在三月底到四月初把兩個大功能塞進了 Gemini API 和 SDK：MCP 工具支援和 Computer Use（Project Mariner）。
MCP 支援意味著 Gemini 現在可以跟 Anthropic、OpenAI 共用同一套工具生態——裝一個 MCP server，三家模型都能用。function calling 的可靠度也拉到了 90%（從 84% 上來），觸發外部工具時更穩定。
Computer Use 目前在 Gemini 3 Pro 和 3 Flash 上可用，讓 Gemini 能自主點擊、填表單、導航 UI。這跟 Anthropic 的 Computer Use 是同一個方向——AI 不只能寫程式，還能操作圖形介面。
另外一個容易被忽略的更新：Gemini 2.5 Pro、2.5 Flash-Lite、2.5 Flash 的退休日期推遲到 2026 年 10 月 16 日。如果你的 production 還在用這些模型，時間多了一些但也不算多。
MCP 的跨平台故事越來越完整了。現在 Anthropic、Google、OpenAI 三家都支援，97M+ 月下載量不是白來的。
Cerebras 的早期投資者 Eclipse Ventures 完成了 13 億美金的新基金募資，投資方向鎖定 AI 基礎設施、機器人和國防科技。
Eclipse 的投資邏輯很清楚：不投 AI 應用層，投 AI 跑起來需要的硬體和基礎設施。Cerebras（AI 晶片）、Hermeus（超音速無人機，剛拿到 3.5 億）、以及其他做製造和國防的新創都在他們的 portfolio 裡。
13 億的規模在 2026 年的創投市場不算最大——Q1 全球創投總額 3,000 億美金，AI 佔了 80%——但 Eclipse 的定位很特殊。大多數 AI 基金在搶應用層的 deal，Eclipse 往下挖一層去投基礎設施，賭的是「不管誰贏了 AI 應用的仗，底下的基礎設施都會賺」。
原文來源：Eclipse Raises $1.3 Billion for Robotics, AI Infrastructure
中國 AI 新創 Spirit AI 在不到 30 天內完成了兩輪融資，累計 4.2 億美金。最新一輪 1.45 億美金由順為資本和雲鋒基金聯合領投——也就是雷軍和馬雲旗下的基金。
Spirit AI 的具體產品細節目前公開資訊不多，但從投資人陣容和融資速度來看，顯然有東西讓這些老手覺得值得押注。中國 AI 市場在 GLM-5.1（MIT 開源 754B）和 Qwen 3.6-Plus（1M context）之後，已經不再只是「追趕者」的角色了。
30 天內拿 4.2 億，融資速度本身就是新聞。
一個容易被漏掉的公告：Anthropic 將在 4 月 30 日終止 Claude Sonnet 4.5 和 Claude Sonnet 4 的 1M token context window beta。屆時 context-1m-2025-08-07 beta header 會失效，超過標準 200K token 的 request 會直接報錯。
要繼續用 1M context，得遷移到 Claude Sonnet 4.6 或 Claude Opus 4.6——這兩個模型標準就支援 1M，不需要 beta header。
如果你的 production 還在用舊模型 + beta header 跑長 context，4/30 之前得搞定遷移。三週的時間不算寬裕。
AI coding agent 從「輔助工具」進化成「自主產出」——Stripe 的 Minions 用 Blueprint 架構讓 1,300 個 PR 帶著品質保證出廠。Anthropic 和 Google 則在基礎設施層面繼續鋪路：Analytics API 給企業量化 ROI，MCP 跨平台支援讓工具生態不再碎片化。錢的部分更直接——Eclipse 13 億美金投 AI 基礎設施，Spirit AI 30 天拿 4.2 億。方向很清楚，速度很快。
]]>這不是什麼未來願景，是 Claude Code 的 --worktree flag 已經能做到的事。Boris Cherny（Claude Code 的創造者）自己的工作流是同時跑 10-15 個 session，每個 session 各自推進不同任務。聽起來很瘋狂？其實設定比你想的簡單得多。
先講問題。你在一個 repo 裡開了 Claude Code session A 修 bug，修到一半想讓另一個 session B 同時去加新功能。結果 B 改了你正在 debug 的檔案，A 的 git status 瞬間爆炸——unstaged changes、merge conflicts、整個 context 亂掉。
Git worktree 解決這個問題。一個 worktree 就是同一個 repo 的一個獨立工作目錄，有自己的 branch、自己的檔案，但共享同一份 git history 和 remote。你可以把它想成「同一個 repo 的平行宇宙」——每個宇宙裡的 Claude 各做各的，完事後 merge 回來就好。
Claude Code 內建了 worktree 支援，不需要自己手動 git worktree add：
1 | # 建立名為 feature-auth 的 worktree 並啟動 Claude |
也可以用縮寫 -w：
1 | claude -w feature-auth |
Worktree 會建在 <repo>/.claude/worktrees/<name>/，branch 名稱是 worktree-<name>，base 分支預設是 origin/HEAD 指向的 branch。
打開三個終端機視窗（iTerm2 的 split pane 或 tmux 都行）：
Terminal 1 — 修 bug
1 | claude -w fix-auth-race-condition |
Terminal 2 — 新功能
1 | claude -w feature-user-preferences |
Terminal 3 — 重構
1 | claude -w refactor-db-queries |
三個 Claude 各在各的 worktree 裡工作，不會互相踩到。
新 worktree 是乾淨的 checkout，不會包含 .env、config/secrets.json 這些 gitignored 的檔案。第一次忘記這件事的時候你的 app 會直接 crash。
在 repo 根目錄建一個 .worktreeinclude 檔案：
1 | .env |
Claude 建 worktree 時會自動把這些檔案複製過去。只有同時符合「match pattern」且「被 gitignore」的檔案才會被複製，tracked 的檔案不會重複。
不只是你手動開多個 terminal。Claude 的 subagent 也支援 worktree 隔離——在 .claude/agents/ 的 agent 定義裡加一行 isolation: worktree，subagent 就會自己建 worktree 來工作：
1 | # .claude/agents/test-runner.md |
或是在對話中直接說「use worktrees for your agents」，Claude 會自動替 subagent 分配獨立的 worktree。
Subagent 做完沒改東西？worktree 自動清掉。有改動？保留等你 review。
Cursor 3 剛發布的 agent-first 架構也支援跑多個 agent，但它是在 IDE 內切換，不是真正的獨立工作目錄。如果兩個 Cursor agent 同時改同一個 repo 的不同檔案，還是有衝突風險。
GitHub Copilot 的多 agent 功能還在早期，主要靠 cloud-based workspace。你的 code 要傳到 GitHub 的 server 上跑。
Claude Code 的 worktree 方案是本地 + 獨立目錄，用 Git 原生機制做隔離。不依賴雲端、不需要特殊 IDE 支援、資料不離開你的機器。缺點是吃硬碟空間——每個 worktree 都是一份完整的 checkout（但共享 .git objects，所以不是完整 clone 那麼大）。
退出 worktree session 時，Claude 會自動處理：
如果你想手動管理：
1 | # 列出所有 worktree |
記得在 .gitignore 加上 .claude/worktrees/，不然 main repo 的 git status 會顯示一堆 untracked files。
Worktree 預設從 origin/HEAD branch 出去。如果你的 origin/HEAD 指向的不是你想要的 branch（例如 clone 很久了，remote 的 default branch 已經改了），手動同步一下：
1 | # 重新同步 origin/HEAD |
如果你需要每次都從不同 branch 分支，可以設定 WorktreeCreate Hook 來自定義 worktree 建立邏輯。
Boris Cherny 的建議是 3-5 個 worktree 為一個 sweet spot。超過這個數量，context switching 的認知負擔（就算是看 Claude 的輸出也需要腦力）會開始抵消平行化的好處。
幾個實用建議：
任務要清晰獨立。如果兩個 worktree 的任務會改到同一組核心檔案，merge 的時候會很痛苦。開始之前先想清楚任務邊界。
用 session name 管理。每個 worktree session 取個好名字：claude -w fix-auth -n "修 auth race condition"，之後用 claude --resume "修 auth race condition" 就能快速回到上下文。
每個 worktree 跑完記得 push。因為 worktree 是本地的，如果你的硬碟出問題，沒 push 的 commit 就沒了。
定期清理。worktree 多了之後 git worktree list 看一下，完成的就 remove，不然佔硬碟空間。
平行跑 AI agent 聽起來很潮，但本質上就是多開幾個獨立工作目錄，用 Git 的原生機制做隔離。沒有什麼黑魔法，只是 Claude Code 把這個流程包裝成一個 --worktree flag 讓你一行指令搞定。試過一次就回不去了。
]]>
這不是什麼未來願景，是 Claude Code 的 --worktree flag 已經能做到的事。Boris Cherny（Claude Code 的創造者）自己的工作流是同時跑 10-15 個 session，每個 session 各自推進不同任務。聽起來很瘋狂？其實設定比你想的簡單得多。
OpenSoul 試圖改變這件事。它在 LLM 之上疊了一層認知架構，靈感來自人腦的神經結構——海馬迴管情節記憶、新皮質管語意記憶、基底核管程序記憶，甚至還有多巴胺和血清素的虛擬版本來調控 AI 的「情緒」。聽起來很科幻？確實，但它的設計文件讀起來比大多數「AI 認知」專案都嚴謹得多。
OpenSoul 把記憶存在 FalkorDB（基於 Redis 的圖資料庫）裡，分成三層：
情節記憶（Episodic Memory）對應海馬迴，記錄具體的對話片段。「你上次說你喜歡喝咖啡」——就是這一層在運作。
語意記憶（Semantic Memory）對應新皮質，儲存從對話中提煉出來的通用知識。「Python 是程式語言」這種事實性資訊住在這裡。
程序記憶（Procedural Memory）對應基底核，記住「這個使用者常犯的錯」之類的行為模式。
每次對話時，系統用 EcphoryRAG 做聯想檢索：先用向量搜尋找到種子節點，再從種子出發用多跳 BFS 展開圖譜，模擬人腦的聯想過程。邊緣權重公式 W = alpha * Recency + beta * Frequency + gamma * Salience 用指數遺忘曲線控制衰減——常用的記憶不容易忘，久沒用的慢慢淡化。跟人腦的遺忘機制蠻像的。
這部分是整個專案最讓人眉毛挑起來的設計。OpenSoul 模擬了虛擬的多巴胺和血清素系統，會動態影響 LLM 的行為：
多巴胺高（興奮狀態）→ temperature 上升、記憶搜尋範圍變廣、回覆風格更活潑
血清素低（低落狀態）→ 回覆變保守、搜尋範圍收窄
這不是噱頭。temperature 和搜尋廣度的動態調控，確實會讓 AI 在不同情境下產出風格不同的回覆。你跟它聊開心的事，它的回覆會變得更發散；你丟一個嚴肅的技術問題，它會收斂回來。
人腦在睡覺時會回放白天的經歷、整合知識、修剪不重要的記憶。Dream Engine 做一樣的事：
預設閒置 5 分鐘就觸發一次。注意，這會持續消耗 LLM API 額度——Dream Engine 本質上是用 LLM 去整理記憶，所以每次「做夢」都在燒錢。
需要 Python 3.11+ 和 Docker（FalkorDB 需要）：
1 | git clone https://github.com/samttoo22-MewCat/OpenSoul.git |
CLI 模式直接聊：
1 | poetry run soul chat |
掛載到 Claude Code 當 MCP Server：
1 | python scripts/setup_mcp.py --cc-enable |
掛上去之後，Claude Code 多了 soul_chat_tool 和 soul_memory_retrieve_tool，等於讓 Claude 擁有跨 Session 的持久記憶。這對長期專案來說蠻有意義的——不用每次開新 session 都重新解釋專案背景。
OpenSoul 附帶了 OpenClaw 技能框架，59 個技能覆蓋瀏覽器自動化、Gmail 收發、Telegram/Discord 操作、程式碼執行、Notion/Trello/GitHub 管理、TTS 語音合成。Judge Agent（對應大腦的眶額葉皮質）負責判斷要不要呼叫工具、選哪一個，用輕量模型（Gemini Flash Lite）做決策來降低成本。
不過 59 個技能大部分只有 SKILL.md 描述檔，少數才有實際 Python 腳本。品質參差不齊，別期待每個都能直接用。
幾個要注意的地方：
FalkorDB 用 SSPL v1 授權，不是 OSI 認證的開源授權。個人用沒問題，但如果你想把它包成 SaaS 提供給別人，可能要公開整個服務棧的原始碼。
核心檔案偏長——agent.py 953 行、api.py 1,334 行。單人開發、13 stars、建立才一個月。概念和架構設計很有深度，但離生產等級還有一段距離。
測試覆蓋率偏低，只有 7 個測試檔案，而且只測不需要資料庫連線的邏輯。
沒有 PyPI 發布，只能 git clone + Poetry 安裝。
star 數不多，但架構設計的深度超過了大多數類似專案。三層記憶圖譜、神經化學狀態機、Dream Engine 的設計都有神經科學的理論基礎，不是隨便取個「cognitive」名字就上架的東西。
如果你對「AI 怎麼擁有記憶」這個問題有興趣，OpenSoul 的原始碼和設計文件值得花時間讀。就算不直接用這個框架，EcphoryRAG 的聯想檢索和遺忘曲線的設計模式，也可以搬到自己的 RAG 系統裡。
至於能不能用在生產環境？現在還不行。但方向對了，剩下的是時間和社群投入的問題。
]]>原文來源：OpenSoul GitHub Repo
OpenSoul 試圖改變這件事。它在 LLM 之上疊了一層認知架構，靈感來自人腦的神經結構——海馬迴管情節記憶、新皮質管語意記憶、基底核管程序記憶，甚至還有多巴胺和血清素的虛擬版本來調控 AI 的「情緒」。聽起來很科幻？確實，但它的設計文件讀起來比大多數「AI 認知」專案都嚴謹得多。
/powerup，終端機裡跑出一段互動式動畫教學。不用開瀏覽器、不用翻文件，在你寫程式的地方直接學怎麼用這個工具。這是 v2.1.89 加進來的新功能，搭配同一時期的 MCP 500K 上限、headless defer 機制和 /cost 增強，四月的第一週就塞了四個版本更新。/powerup 的設計哲學很明確——新手不需要離開終端機就能學會 Claude Code 的核心功能。每個 lesson 都有動畫示範，不是只給你看文字說明，而是實際在終端機裡播放操作過程。
1 | # 啟動 Claude Code 後直接打 |
跟一般文件的差別在哪？文件告訴你「你可以用 /loop 設定排程」，/powerup 則是在終端機裡示範整個設定流程，讓你跟著操作。學習曲線直接壓平一截。
對比一下其他 AI coding 工具的新手引導：Cursor 靠的是 GUI 裡的 tooltip 和官網教學影片，Kiro CLI 在 v1.25 加了 Help Agent 用對話方式解答問題，Copilot 則是內建在 IDE 的 inline suggestion。Claude Code 選擇在 CLI 裡做互動教學是很合理的——你的使用者本來就在終端機裡，幹嘛要他切到瀏覽器？
之前 MCP tool result 的大小限制一直是個痛點。如果你的 MCP server 回傳的資料量比較大——例如資料庫查詢結果、長文件內容、API 批次回應——常常會被截斷。
v2.1.90 把這個上限拉到 500,000 字元，透過 _meta annotation 指定：
1 | { |
500K 字元大概是什麼概念？一篇 5,000 字的中文文章大約 5,000 字元，所以 500K 大概可以塞 100 篇文章的量。對於資料庫查詢結果或 API 批次回應來說，這個空間相當充裕。
不過要注意，塞越多資料進 context 就吃越多 token。不是所有情境都適合開到最大，合理設定才是正途。
這個功能改變了 headless 模式（-p flag）的權限處理邏輯。之前 headless session 碰到需要權限的工具呼叫時，要嘛自動允許要嘛直接拒絕，沒有中間地帶。
現在 PreToolUse hook 多了一個 defer 選項。當 hook 回傳 defer 時，headless session 會暫停在那個工具呼叫上，等你用 -p --resume 重新連上後再決定要不要放行。
1 | # 啟動 headless session |
搭配另一個新功能——PreToolUse hook 現在可以透過 updatedInput 回應 AskUserQuestion，讓 headless 整合自己的 UI 來收集使用者答案。如果你在做 Claude Code 的自動化管線（CI/CD、排程任務等），這兩個功能讓你不用再在「全開放」和「全拒絕」之間二選一。
/cost 指令之前只顯示總花費，現在多了兩個維度：
Per-model split——如果你的 session 用到多個模型（例如主模型 + sub-agent 用不同模型），現在可以看到每個模型各花了多少。
Cache-hit split——顯示 prompt caching 幫你省了多少錢。如果你的工作流會重複送類似的 prompt（例如同一個 CLAUDE.md 被反覆載入），cache hit 率高的話省的錢不少。
1 | /cost |
知道錢花在哪裡才能針對性優化。如果 Haiku 能處理的子任務卻用了 Opus，切一下模型就能省不少。
Bedrock 互動式設定精靈——從登入畫面選「3rd-party platform」就能進入，引導你完成 AWS 認證、region 設定、credential 驗證和 model pinning。之前這些全要手動改設定檔。
Headless 啟動效能改善——-p 模式現在延遲載入 Yoga WASM 和 UI 元件，加上 MCP_CONNECTION_NONBLOCKING=true 可以跳過 MCP 連線等待。如果你的 MCP server 啟動很慢，headless session 不用再被拖著等。MCP server 連線也加了 5 秒上限，不會因為一個 server 卡住而影響整個 session。
記憶體洩漏修復——修了好幾個：大 JSON 輸入被 LRU cache 留住的問題、Edit tool 操作超大檔案（>1 GiB）可能 OOM 的問題、remote session 裡 tool use ID 無限累積的問題。長時間跑的 session 穩定性應該會好很多。
| 版本 | 重點 |
|---|---|
| v2.1.89 | /powerup 互動式教學 |
| v2.1.90 | MCP 500K 上限、Defer permission |
| v2.1.91 | /cost per-model split、cache-hit 顯示 |
| v2.1.92 | Bedrock 設定精靈、記憶體修復、效能優化 |
四個版本在一週內連發，節奏很快。如果你是 Claude Code 的重度使用者，建議更新到最新版再回來看看 /powerup 裡的課程——說不定會發現一些你沒用過的功能。
]]>參考來源：Claude Code Changelog
參考來源：Claude Code in Action - Anthropic Academy
/powerup，終端機裡跑出一段互動式動畫教學。不用開瀏覽器、不用翻文件，在你寫程式的地方直接學怎麼用這個工具。這是 v2.1.89 加進來的新功能，搭配同一時期的 MCP 500K 上限、headless defer 機制和 /cost 增強，四月的第一週就塞了四個版本更新。
/buddy 敲下去，跳出一隻 common 的 snail。你盯著那隻蝸牛三秒鐘，心想：我想要的是 legendary shiny dragon，不是這個。問題是，官方沒有給重新 Roll 的入口。寵物的外觀、物種、稀有度全部由 hash(userID + SALT) 確定性生成——同一個 userID 永遠會得到同一隻寵物。想換？得從底層動手。
這篇把整個寵物系統的原理拆給你看，然後教你怎麼用腳本暴力搜尋到你想要的組合，最後寫進設定檔完成替換。手動派和懶人派的方法都有。
寵物分成兩層，儲存方式完全不同：
Bones（骨架）——外觀、物種、稀有度、屬性值。不存在任何檔案裡，每次都是由 hash(userID + SALT) 即時計算出來的。換句話說，只要 userID 一樣，骨架就永遠一樣。
Soul（靈魂）——名字和性格。存在 ~/.claude.json 的 companion 欄位裡。這部分可以隨便改。
1 | // src/buddy/companion.ts |
注意優先順序：accountUuid 優先於 userID。如果你是 OAuth 登入的使用者，buddy 預設會拿 accountUuid 當種子，不是 userID。這個細節後面會很重要。
首次啟動 Claude Code 時隨機生成的 32 位元組 hex 字串。用途只有三個：遙測分析、A/B 分桶、buddy 種子。跟你的對話歷史、API key、本地設定完全無關。換掉它，什麼功能都不會受影響。
duck、goose、blob、cat、dragon、octopus、owl、penguin、turtle、snail、ghost、axolotl、capybara、cactus、robot、rabbit、mushroom、chonk——總共 18 種。
| 稀有度 | 權重 | 機率 |
|---|---|---|
| common | 60 | 60% |
| uncommon | 25 | 25% |
| rare | 10 | 10% |
| epic | 4 | 4% |
| legendary | 1 | 1% |
眼睛有 6 種：· ✦ × ◉ @ °
帽子有 8 種：none、crown、tophat、propeller、halo、wizard、beanie、tinyduck
屬性值有 5 項：DEBUGGING / PATIENCE / CHAOS / WISDOM / SNARK，各自 0-100 隨機。
Shiny 閃光版：1% 機率。疊上 legendary 的 1%，想拿到一隻 legendary shiny 特定物種的機率大概是十萬分之五——不靠腳本基本上沒戲。
Claude Code 的二進位檔是 Bun 打包的，hash 用的是 Bun.hash()。你可能想用 Node.js 跑搜尋腳本省事，但 Node.js 的 FNV-1a fallback 跟 Bun.hash() 的結果完全不同。
1 | function hashString(s) { |
用 Node.js 跑出來的 userID 寫進設定，領養到的寵物會跟你預期的完全不同。踩這個坑會浪費你一整個下午，別問我怎麼知道的。
結論：搜尋腳本必須用 bun 執行。
適合想完全理解原理、不依賴第三方工具的人。
建立 ~/buddy-reroll.js：
1 | #!/usr/bin/env bun |
把 TARGET_SPECIES、TARGET_RARITY、REQUIRE_SHINY 改成你要的組合。不要求 shiny 的話把條件拿掉，速度會快很多。
1 | bun ~/buddy-reroll.js |
Legendary 通常 50 萬次迭代內就能找到，幾秒鐘的事。Legendary + Shiny 則需要幾千萬次，跑個幾分鐘。找到後記下 UID。
1 | # Step 3：備份 |
為什麼 Step 6 要用環境變數而不是正常登入？因為正常 OAuth 登入會把 accountUuid 寫進設定檔，而 companionUserId() 會優先用 accountUuid，你辛苦搜來的 userID 就被忽略了。用環境變數登入不會寫 accountUuid，/buddy 才會改用 userID 當種子。
不想自己寫腳本？社群已經有幾款開源工具把整個流程包好了。這是給一般使用者最簡單的路線——一行指令就能換到你想要的寵物，連 OAuth Token 都不用碰。
手動方法的核心是「換 userID 種子」，但需要繞開 accountUuid 優先權，所以要操作環境變數和重設設定檔。社群工具走的是另一條路：不換 userID，改去暴力搜尋一個替代的 salt 字串，讓 hash(原 accountUuid + 新 salt) 符合你的目標，然後直接修補 Claude Code 的 binary。使用者不用碰 ~/.claude.json，也不用設環境變數。
| 工具 | 風格 | 特色 |
|---|---|---|
| any-buddy | 互動式 TUI | 23 個預設組合、即時 ASCII 預覽、支援多寵物切換 |
| buddy-reroll | CLI 為主 | 輕量直接、Bun 加速、--doctor 系統檢查 |
| cc-buddy | 雙模式 | EN/中文 UI、物種圖鑑、自我測試 |
互動式 TUI，會引導你一步步完成所有步驟，每步都有即時 ASCII 預覽，適合喜歡視覺化操作的人。
1 | npx any-buddy@latest |
第一次執行會自動下載，無需手動安裝。也可以全域安裝：
1 | npm install -g any-buddy |
直接執行 any-buddy 進入 TUI，會讓你選擇：
選完後工具會自動執行 salt 搜尋、修補 binary、設定 hook，全程在 TUI 內完成。
1 | # 傳說級閃光龍，戴巫師帽，自訂名字 Draco |
-y 旗標跳過所有確認，適合寫進 script。
| 動作 | 指令 |
|---|---|
| 看目前寵物 | any-buddy current |
| 預覽不套用 | any-buddy preview |
| 還原原始寵物 | any-buddy restore |
| 更新後重新套用 | any-buddy apply |
| 切換已存寵物 | any-buddy buddies |
| 重新孵化 | any-buddy rehatch |
1 | -s, --species <name> 物種（duck, cat, dragon, ...，共 18 種） |
沒有 TUI，純 CLI，適合喜歡一行指令搞定、寫進 dotfile 的人。底層使用 wyhash，跟 /buddy 的 hash 演算法完全一致。
1 | # Bun（推薦，原生 hash 較快） |
1 | # 全部指定 |
Claude Code 自動更新會重設寵物，啟用 hook 自動恢復：
1 | buddy-reroll --hook # 啟用持久化（執行一次即可） |
啟用後，每次 Claude 啟動都會自動套用你選的寵物。
1 | buddy-reroll --doctor # 檢查安裝路徑、寫入權限、設定狀態 |
| 你的情況 | 推薦方法 |
|---|---|
| 只想快速換一隻寵物，喜歡視覺操作 | any-buddy（互動式預覽最直觀） |
| 喜歡 CLI、想寫進 dotfile | buddy-reroll（一行搞定） |
| 想完全掌握原理、不依賴第三方 | 手動腳本（見上方「完整操作流程」） |
| Team / Pro 帳號 | any-buddy 或 buddy-reroll（已內建 accountUuid trap fix） |
這篇基於 Claude Code 2.1.89+ 版本分析。如果後續版本更改 SALT 值或 hash 演算法，腳本需要對應調整。
Claude Code 自動更新會覆蓋 binary，社群工具改的東西就沒了。務必啟用 --hook 持久化。手動腳本的使用者因為是改 userID 而不是改 binary，不受自動更新影響。
社群工具都是 MIT 授權、公開原始碼，但會修改 Claude Code 的 binary。介意的人請用手動腳本方法，只改設定檔不碰 binary。
macOS 上修改 binary 後需要 re-sign，社群工具都會自動處理。環境需求：Node.js >= 20，或安裝 Bun runtime。
Shiny 搜尋很慢——1% 機率疊上 legendary 的 1% 再疊上特定物種的 1/18，期望搜尋次數大約是 18 萬次。耐心等幾分鐘就好，Bun 的速度夠快。
一隻 legendary shiny capybara 戴著巫師帽，WISDOM 95 分。值得花五分鐘搞定嗎？值得。
]]>/buddy 敲下去，跳出一隻 common 的 snail。你盯著那隻蝸牛三秒鐘，心想：我想要的是 legendary shiny dragon，不是這個。
問題是，官方沒有給重新 Roll 的入口。寵物的外觀、物種、稀有度全部由 hash(userID + SALT) 確定性生成——同一個 userID 永遠會得到同一隻寵物。想換？得從底層動手。
這篇把整個寵物系統的原理拆給你看，然後教你怎麼用腳本暴力搜尋到你想要的組合，最後寫進設定檔完成替換。手動派和懶人派的方法都有。
智譜 AI（Z.ai）在 4/7 正式發布 GLM-5.1，用的是 MIT License——不是什麼「非商業研究限定」，是真的可以下載、客製化、商用的 MIT。754 億參數，202,752 token context window，在 SWE-Bench Pro 上拿到的分數超過 Claude Opus 4.6 和 GPT-5.4。
但真正讓這個模型跟其他開源模型拉開差距的，是它的「八小時自主任務」能力。Scenario 3 測試裡，GLM-5.1 花八小時從零建出一個 Linux 風格桌面環境——檔案瀏覽器、終端機、文字編輯器、系統監控、甚至還有能玩的遊戲。之前的模型通常做個工具列加一個空視窗就宣告完成了。
API 定價 $1.40/M input tokens、$4.40/M output tokens。北京時間 14:00-18:00 尖峰時段消耗 3x quota，不過四月底前離峰時段都是 1x 標準費率。Hugging Face 上可以直接載。
開源陣營又多了一張真正能打的牌。
原文來源：AI joins the 8-hour work day as GLM ships 5.1 open source LLM
4/7 公告，Anthropic 最新最強的模型 Claude Mythos Preview 以 Private Preview 形式上線 Vertex AI，但你不能直接註冊來用——只有加入 Project Glasswing 計畫的特定客戶才有存取權限。
為什麼限定存取？因為 Mythos 在資安領域的能力太強了。Anthropic 的說法是：「這個模型已經在 OpenBSD、FFmpeg、Linux 等主流軟體中發現了數千個之前沒人知道的零日漏洞。」不是用它來掃描，是它自己找到的。
Project Glasswing 是 Anthropic 和 Google Cloud、微軟等合作的資安聯防計畫。研究預覽期間 Anthropic 承諾用 $1 億的免費額度支撐大部分用量。正式定價是 $25/M input、$125/M output——目前市面上最貴的模型。
Anthropic 明確表示不打算把 Mythos 公開給一般用戶。這倒是 AI 產業第一次有公司說「我們的模型太強了所以不賣」，而不是反過來。
又一個 AI 工作流平台中獎。n8n 被爆出 CVE-2026-21858，CVSS 10.0 滿分，研究者取名叫「Ni8mare」——n8n + nightmare 的諧音，名副其實。
技術上是 Content-Type 混淆漏洞。攻擊者送特製的 HTTP request 到 webhook endpoint，利用 Content-Type header 的錯誤處理覆寫內部解析狀態，一路打到讀取認證密鑰、偽造管理員 session、最終 RCE。整條攻擊鏈不需要任何認證。
受影響版本是 1.121.0 以前的所有 n8n，已修補。主要衝擊自架實例——managed 環境因為本地檔案和密鑰的存取方式不同，最嚴重的攻擊路徑用不了。
加上之前的 Langflow（CVSS 9.3）、Flowise（CVSS 10.0）、MLflow（CVSS 10.0），AI workflow 平台的資安紀錄真的慘不忍睹。這些工具為了讓 AI 方便操作開了太多權限，攻擊者同樣方便。自架 n8n 的團隊現在該去確認一下版本號了。
AI agent 越來越多人用，但治理工具幾乎不存在。微軟在 4/2 開源了 Agent Governance Toolkit（MIT License），宣稱是第一個覆蓋全部 OWASP Agentic AI 十大風險的治理方案。
核心賣點是「確定性的亞毫秒策略執行」——不是用另一個 AI 去監控 AI（那樣延遲和準確度都是問題），而是用預定義的規則引擎做 runtime 攔截。支援 Python、Rust、TypeScript、Go、.NET 五種語言的 SDK。
對企業來說這個工具解決了一個很現實的問題：你讓 AI agent 去操作生產環境的 API，怎麼確保它不會做出格的事？之前大家都在用 prompt engineering 來「拜託」AI 別亂來，現在有了硬性的 policy enforcement 層。
不過「覆蓋十大風險」這種宣稱得打個折扣。工具剛出來，社群驗證還不夠，實際部署的案例也有限。方向對，但成熟度還需要時間。
這則消息被前面幾個大新聞蓋過去了，但其實蠻重要的。GitHub 在四月初通知用戶：從 4/24 開始，Copilot Free、Pro、Pro+ 的用戶互動資料——包括輸入、輸出、程式碼片段和相關上下文——預設會被用來訓練和改進 AI 模型。
關鍵字：預設。不是 opt-in，是 opt-out。你要自己到設定裡關掉。
三月才出過 Copilot 在 150 萬個 PR 裡塞入宣傳「tips」的事件，現在又來這個。用戶信任度本來就在下滑——多份調查顯示開發者對 Copilot 建議品質的滿意度從 2025 年底開始持續走低，延遲變高、上下文感知變差是最常見的抱怨。
Enterprise 和 Business 方案目前不受影響。如果你用的是個人方案，4/24 之前去 Settings 裡面確認一下資料分享選項。
開源模型跟閉源的差距在快速縮小——GLM-5.1 用 MIT 授權直接挑戰 Opus 和 GPT-5.4，同一時間 Anthropic 卻選擇把最強模型鎖起來不賣。AI 工作流平台的資安債繼續爆，微軟試圖用治理工具包補上這個缺口。GitHub Copilot 的資料政策調整提醒我們：免費的東西，你就是產品。
]]>先釐清一件事：Career-Ops 不會幫你自動投履歷。它的定位比較像是求職版的 CI/CD pipeline——你丟一個職缺 URL 進去，它幫你跑完評估、產生客製化 CV、登錄追蹤器，所有產出都要經過你人工審查才送出。
整個系統建構在 Claude Code CLI 上面，但有趣的地方在於它的邏輯不是寫在程式碼裡，而是寫在 Markdown 檔案中。CLAUDE.md 加上 14 個 modes/*.md 定義了所有行為——評估框架、評分公式、PDF 格式、外聯訊息模板。如果你想客製化，改 Markdown 就好，不用動程式碼。
作者把這個設計叫做「Prompt-as-Code」。類比的話，傳統軟體是「用程式碼寫邏輯」，Career-Ops 是「用 Markdown 寫邏輯，讓 AI 當執行引擎」。
每個職缺進來會跑完六個區塊的完整評估：角色摘要（解構 JD）、CV 匹配度（跟你的 cv.md 比對）、層級策略（這個職位適不適合你的職涯階段）、薪資研究（用 WebSearch 查市場行情）、個人化申請計畫、面試準備（STAR+Reflection 格式的故事）。
最後用十個維度加權算分，1 到 5 分，包含匹配度、職涯目標對齊、薪資、文化訊號、Red Flags。系統建議 4.0 以下的就別投了——這個門檻聽起來很嚴格，但回過頭看，把時間花在真正值得的職缺上才是效率最大化。
ATS 優化的 PDF CV——Career-Ops 用 Playwright + Chromium 把 HTML 模板轉成 PDF，但不是隨便轉。單欄佈局讓 ATS 好解析，自動正規化 em-dash 和 smart quotes（這些字元在 ATS 解析時超容易出問題），還會從評估報告中提取關鍵字注入 CV。不是瞎掰經歷，是把你真的有的經驗用 JD 的語言重新包裝。
批次評估——收集了幾十個職缺 URL 之後，batch 模式用 claude -p 啟動多個 headless worker 平行處理。每個 worker 有獨立的 200K token 上下文。評估結果先寫入 TSV，最後由 merge-tracker.mjs 統一合併。避免並行寫入衝突的設計蠻聰明的。
這個模式值得偷。Career-Ops 把檔案分成「系統層」（modes/、templates/、*.mjs）和「用戶層」（config/profile.yml、cv.md、data/、reports/）。系統層可以安全自動更新，用戶層永遠不會被碰。update-system.mjs 拉新版本時不會破壞你的個人資料。
如果你在做任何「需要更新但又不能弄壞使用者設定」的工具，這個模式很值得參考。
| 模式 | 功能 |
|---|---|
oferta | 單一職缺完整評估 |
ofertas | 多職缺並排比較 |
pdf | ATS 優化 CV PDF |
scan | 入口網站掃描新職缺 |
batch | 平行批次評估 |
auto-pipeline | URL 到追蹤器一站完成 |
tracker | 投遞狀態管理 |
apply | 表單填寫助手 |
contacto | LinkedIn 外聯訊息 |
deep | 公司深度研究 |
預設介面名稱用西班牙語（作者是阿根廷人），但 Claude 會用你指定的語言回應。
後端用 Node.js（dependency 只有一個：playwright），Dashboard 用 Go + Bubble Tea + Lipgloss 做終端 UI。資料層沒有資料庫，全部是 Markdown 表格 + YAML + TSV。整個專案大約 6,000 行 mjs/Go/Bash 加上 1,300 行 Markdown modes。
建立四天就衝到 ~20,000 stars，已經合併了超過十個社群 PR。文件品質極高——CLAUDE.md 就寫了 16.7KB，加上完整的 DATA_CONTRACT。
需要 Claude Code CLI 訂閱，batch 模式吃 token 很兇，建議用 Claude Max 方案。首次使用品質有限，系統需要先「認識」你——讓它讀過夠多的 CV 和職涯故事之後才會準。AI 產出的薪資數據和公司資訊可能不精確，所有東西都要人工審查。
Batch 模式下 headless worker 沒辦法用 Playwright，所以 JD 驗證會標記為 unconfirmed。入口網站的 URL 會因為公司換 ATS 系統而過期，需要定期維護。
如果你對「怎麼用 Markdown 建構完整 AI Agent 工作流」有興趣，Career-Ops 是目前最好的參考案例之一。14 個模式的設計、雙層資料契約、批次處理架構，每個都是可以直接套用到其他場景的 pattern。
不一定要拿來求職——把 oferta 模式改成「供應商評估」、把 scan 改成「競品監控」，骨架是完全通用的。
]]>相關連結：Career-Ops GitHub Repo
需要搭配：Claude Code CLI
先釐清一件事：Career-Ops 不會幫你自動投履歷。它的定位比較像是求職版的 CI/CD pipeline——你丟一個職缺 URL 進去，]]>
@claude fix the TypeError in the dashboard component。你翻了個身繼續睡。早上起來打開 GitHub，Claude 已經改好了、推了 commit、還在 comment 裡解釋了根本原因。這不是科幻。Claude Code GitHub Actions 就是在做這件事——把 Claude 塞進你的 CI/CD pipeline，讓它在 GitHub 上自動回應 PR、修 bug、寫測試、甚至從 issue 直接生出整個 PR。
一句話：在 GitHub 的 issue 或 PR 裡 @claude 就能觸發 AI 幫你做事。
具體來說：
而且它會讀你 repo 根目錄的 CLAUDE.md，遵守你定義的 coding standards。不是那種亂槍打鳥的通用建議，是真的看過你的 codebase 之後給的。
打開終端機，在 Claude Code 裡跑一行指令：
1 | /install-github-app |
它會引導你完成 GitHub App 安裝和 secret 設定。前提是你得是 repo admin。
三個步驟：
1. 安裝 Claude GitHub App
到 github.com/apps/claude 安裝，給它 Contents、Issues、Pull requests 的讀寫權限。
2. 設定 API Key
到你的 repo Settings → Secrets and variables → Actions，新增一個叫 ANTHROPIC_API_KEY 的 secret，貼上你的 API key。
3. 加入 Workflow 檔案
在 .github/workflows/ 建立 claude.yml：
1 | name: Claude Code |
就這樣。現在去你的 PR 裡留言 @claude review this 試試看。
每次有人開 PR 或 push 新 commit，Claude 自動跑一輪 review：
1 | name: Code Review |
用 cron schedule 每天早上九點產出昨天的開發摘要：
1 | name: Daily Report |
預設是 Sonnet，但你可以透過 claude_args 切換模型：
1 | claude_args: "--model claude-opus-4-6 --max-turns 10" |
Opus 適合需要深度理解 codebase 的複雜任務——大型重構建議、跨模組 bug 追蹤、架構決策分析。Sonnet 則適合日常的 review 和簡單修改，速度快、成本低。
在 repo 根目錄放一個 CLAUDE.md，Claude 在 CI/CD 裡也會讀。內容建議包含：
這東西的效果比你想像的大。沒有 CLAUDE.md 的時候，Claude 給的建議是通用的「你應該加 error handling」；有了之後，它會說「這裡應該用 AppError 而不是原生 Error，參考 src/utils/errors.ts 的模式」。
直接用 Anthropic API 不是唯一選項。如果你的公司有資料駐留或計費需求，可以走 AWS Bedrock 或 Google Vertex AI：
1 | steps: |
用 OIDC 做認證，不需要存 AWS access key 到 GitHub secret 裡——credential 是臨時的、自動輪換的，比 static key 安全很多。
1 | steps: |
兩種雲端方案都需要先建立自己的 GitHub App（而不是用 Anthropic 官方的），因為認證流程不同。設定稍微複雜一點，但拿到的是完整的資料控制權。
Copilot CLI 上週剛加了 Critic agent，Cursor 3 可以從 GitHub 觸發 agent session。Claude Code GitHub Actions 的差異化在哪？
跟 Copilot 比：Copilot 的 CI 整合是 GitHub 原生的，設定更無腦，但模型選擇受限於 GitHub 提供的選項。Claude 這邊你可以用 Opus、Sonnet，透過 MCP 串接外部工具，自由度更高。
跟 Cursor 比：Cursor 3 的 agent 可以從 GitHub 觸發，但本質上是在 Cursor 的雲端跑，不是 GitHub runner 原生環境。Claude Code Action 跑在 GitHub 的 runner 上，repo 的 CI 環境一致，debug 更方便。
共通點：三家都在往「AI 不只是建議，是直接動手改」的方向走。差別在執行環境、模型選擇、和生態系整合。
兩筆帳要算：
GitHub Actions 費用：跑在 GitHub-hosted runner 上，吃你的 Actions minutes。免費額度用完後按 GitHub 的計費標準走。
API 費用：每次 Claude 互動都消耗 token。複雜任務（分析大 PR、跨模組修 bug）的 token 用量會顯著高於簡單 review。
省錢技巧：
--max-turns 限制對話輪次，避免 Agent 陷入迴圈Claude 不回應 @claude：確認 GitHub App 有裝、workflow 有 enable、API key 有設對。注意是 @claude 不是 /claude。
Claude 的 commit 不會觸發 CI：確認你用的是 GitHub App 或自建 App，不是 Actions 的預設 user。預設 user 的 commit 不會觸發後續 workflow。
認證失敗：API key 是否有效？Bedrock/Vertex 的 credential 設定是否正確？Secret 命名是否完全吻合？
Claude Code GitHub Actions 的核心價值不是「讓 AI 幫你寫 code」——那個 Claude Code CLI 就能做。它的價值是把 AI 嵌入團隊的 GitHub 工作流，讓每個 PR、每個 issue 都有一個不會下班的 reviewer 和 implementer 待命。設定五分鐘，之後每天省的時間遠超過這五分鐘。
]]>原文來源：Claude Code GitHub Actions - Official Docs
參考來源：Claude Code in Action - Anthropic Academy
GitHub Repo：anthropics/claude-code-action
@claude fix the TypeError in the dashboard component。你翻了個身繼續睡。早上起來打開 GitHub，Claude 已經改好了、推了 commit、還在 comment 裡解釋了根本原因。
這不是科幻。Claude Code GitHub Actions 就是在做這件事——把 Claude 塞進你的 CI/CD pipeline，讓它在 GitHub 上自動回應 PR、修 bug、寫測試、甚至從 issue 直接生出整個 PR。
Thoughtworks 的 Distinguished Engineer Birgitta Bockeler 在 Martin Fowler 網站上丟出了一篇重量級文章（2026-04-02 發表），直接正面回答這個問題。她的答案不是「可以」或「不可以」，而是：你需要建構一套系統化的控制機制，叫做 Harness。
Harness = AI Agent 中除了模型本身以外的所有東西。
人類工程師寫 code 的時候，其實自帶一套「隱性 harness」——多年累積的編碼慣例、對複雜度的直覺痛感、「這段寫太爛了我自己看不下去」的美學標準。Agent 沒有這些。它能吐出幾乎任何程式碼，但沒有品味判斷、沒有組織記憶、沒有那種「雖然能跑但三個月後一定出事」的第六感。
所以你得把這些隱性知識外顯化成可執行的控制系統。人類的角色從「寫程式碼」變成「迭代改進 harness」——harness 的品質直接決定你能對 Agent 輸出建立多少信任。
Harness 由兩個方向組成，缺一不可：
Guides（Feedforward）：Agent 動手之前先給它教材。像是 AGENTS.md、Skills、編碼慣例文件、OpenRewrite recipes。
Sensors（Feedback）：Agent 交出成果之後拿去考試。像是 tests、linters、type checkers、AI code review 指令。
Bockeler 講了一句蠻精準的話：
「只有 feedback 的 Agent 會不斷重複同樣的錯誤；只有 feedforward 的 Agent 則編碼了規則卻永遠不知道它們是否有效。」
每個方向又分兩種執行類型：Inferential（語義分析，靠 AI 判斷，較慢）和 Computational（確定性計算，毫秒級，像 linter 和 type checker）。四個象限交叉出來，就是完整的控制矩陣。
整篇文章最值錢的概念在這裡——轉向迴圈（Steering Loop）：
關鍵洞察是：Agent 本身也能協助建構這些控制。讓它寫 structural tests、從重複模式中產生規則草稿、建立 how-to 指南。工程師不再是逐行寫 code 的人，而是不斷調校 harness 的系統設計師。
文章把 harness 比喻為 cybernetic governor（控制論調節器），定義三個維度：
Maintainability Harness（可維護性）——最容易做，因為工具成熟。重複程式碼偵測、cyclomatic complexity、缺少測試覆蓋率、architecture drift，這些都有現成的 computational sensors 可以接。inferential 層面則是偵測語義重複、冗餘測試、暴力修復、過度設計。
Architecture Fitness Harness（架構適應度）——基於 Fitness Functions 概念。用 Skills 提供效能需求（feedforward），再用 performance tests 提供回饋（feedback）。這層需要你對系統架構有清晰定義才做得起來。
Behaviour Harness（行為正確性）——目前最不成熟的維度。Bockeler 很坦白地承認：
「這種方法過度信任 AI 產生的測試，這還不夠好。在行為正確性的 harness 方面，我們還有很多工作要做。」
這段話值得記下來。很多人在吹 AI 能自己寫測試自己驗證，但如果測試本身也是 AI 寫的，你只是在用一個你不完全信任的東西去驗證另一個你不完全信任的東西。
源自 CI/CD 的經典概念——品質左移。
Pre-commit：快速檢查。Linter、基本測試、code review agent，在 commit 之前就擋掉低級錯誤。
Post-integration pipeline：昂貴檢查。Mutation testing、大範圍 code review，放在 CI pipeline 裡跑。
持續漂移偵測：dead code detection、test coverage 品質、dependency scanning。不是一次性的，是持續在背景跑的。
對 AI 產出的 code 來說，左移策略特別重要。Agent 可以在幾分鐘內產出幾百行，如果等到 PR review 才發現方向不對，浪費的不只是 token 費用，還有 reviewer 的腦力。
文章引用了兩個大公司的做法：
OpenAI 團隊用分層架構，透過 custom linters 和 structural tests 強制執行。定期做「garbage collection」掃描偵測 drift。他們的結論很有意思：「我們現在最困難的挑戰集中在設計環境、反饋迴路和控制系統。」注意，不是模型本身，是 harness。
Stripe 的 “Minions” 則是用 pre-push hooks 執行 heuristic-selected linters，強調 shift feedback left。他們用 “Blueprints” 把 feedback sensors 整合到 Agent workflows 裡。
兩間公司殊途同歸：問題不在 Agent 夠不夠聰明，在於你的控制機制夠不夠完整。
有個容易被忽略的概念是 Harnessability——codebase 適合被 harness 控制的程度。
Strong typing 能啟用 type-checking sensors、清晰的模組邊界能啟用架構約束規則、Framework 的使用能抽象化 Agent 不需要處理的細節。反過來說，一堆 any type、沒有模組邊界、到處都是 magic string 的 codebase，harness 根本建不起來。
弔詭的是：Harness 最被需要的地方（legacy codebase），恰恰是最難建構的地方。 這大概是整篇文章最讓人無奈的洞察。
Bockeler 引用了 Ashby’s Law——一個調節器必須擁有至少與其管理的系統同等多的多樣性。LLM Agent 能產出幾乎任何東西，所以理論上你的 harness 也需要無限多樣性。
實務上不可能做到，但有個聰明的折衷：定義明確的服務拓撲（API 服務、Event processing、Data dashboard），針對每種拓撲建立 Harness Templates，涵蓋 80% 的使用場景。剩下 20% 再逐案處理。
文章最後坦誠列出五個開放問題，也是接下來整個產業要面對的：
這些問題沒有簡單答案。但至少 Bockeler 把框架立起來了——接下來是整個社群一起填坑的時間。
如果你正在用 Claude Code、Cursor 或任何 AI coding agent，這篇文章值得從頭讀到尾。它不是在告訴你「AI 很棒趕快用」或「AI 很危險小心」，而是在說：信任不是開關，是工程。 你願意在 harness 上投入多少，就能建立多少信任。
]]>原文來源：Harness Engineering - Martin Fowler
參考來源：Claude Code in Action - Anthropic Academy
Thoughtworks 的 Distinguished Engineer Birgitta Bockeler 在 Martin Fowler 網站上丟出了一篇重量級文章（2026-04-02 發表），直接正面回答這個問題。她的答案不是「可以」或「不可以」，而是：你需要建構一套系統化的控制機制，叫做 Harness。
4 月 2 日，Cursor 團隊做了一件很大膽的事——把整個 IDE 介面砍掉重寫，從零打造一個「agent-first」的開發環境。傳統的檔案樹、tab 列、編輯區？還在，但已經不是視覺中心了。
新介面的核心是一個 Agent 面板。你可以同時跑多個 agent 跨不同 repo，本地和雲端無縫切換，甚至從手機、Slack、GitHub、Linear 啟動 agent session。內建 Git 操作（staging、commit、PR 管理），不用再切到終端機。
背後更有趣的是技術：Cursor 導入了 real-time RL for Composer，用真實使用者互動來訓練模型，最快每五小時就部署一個新 checkpoint。年營收已經突破 20 億美金，Money Forward 的 1,000 多名工程師每天在用，平均每人每週省 15-20 小時。
這個方向跟 Claude Code 的 terminal-first 和 Codex 的 cloud-first 完全不同。三家各押不同賭注，看誰的路線最後勝出會是今年最精彩的戲碼。
原文來源：Meet the new Cursor
Copilot CLI 在 4 月 4 日的 v1.0.18 更新中加入了一個叫 Critic 的新 agent。它的工作很單純：自動審查 Copilot 產出的計畫和複雜實作，找出潛在問題。
聽起來很像之前講的 Harness Engineering 的概念對吧？讓 AI 自己建構 feedback sensor，在交付之前先自我檢查一輪。v1.0.19（4/6 發布）還加了 MCP 設定跨 session 持久化和 OpenTelemetry 監控改善。
這個更新的意義在於：AI coding 工具正在從「生成程式碼」進化到「生成 + 自我審查」的閉環。如果 Critic 的品質夠好，等於 Copilot 自帶了一個免費的 code reviewer。當然，品質到底夠不夠好，得用了才知道。
Block（就是 Jack Dorsey 的公司）正式發布 Goose——一個開源的 AI agent 框架，定位是「你機器上的本地 AI agent」。不綁定特定 LLM，支援多模型配置，整合 MCP server，有桌面 App 也有 CLI。
Goose 能做的事包括從零建立專案、寫程式碼並執行、除錯、編排工作流、呼叫外部 API，全自動。因為是本地執行，資料不離開你的機器。
有意思的是 Goose 跟 MCP 的關係。根據 Arcade.dev 的報導，Goose 是最早影響 MCP 設計方向的開源 agent 之一——MCP 的很多設計決策其實是從 Goose 的實際使用經驗中提煉出來的。現在 MCP 已經捐給 Linux Foundation AAIF，Goose 等於是這個生態系的元老級成員。
開源、本地優先、LLM 不鎖定——如果你對 Claude Code 的訂閱模式或 Cursor 的定價有意見，Goose 是個值得關注的替代選項。
Fortinet 發布緊急修補：FortiClient EMS（企業端點管理伺服器）被發現零日漏洞 CVE-2026-35616，CVSS 9.1。這是一個 pre-authentication API 存取繞過漏洞，未經認證的攻擊者可以直接提升權限，執行未授權操作。
時間線很嚇人：watchTowr 的偵測器在 3/31 就發現攻擊活動，比 Fortinet 4/4 發布公告還早四天。CISA 在 4/6 把它加入 KEV 目錄，聯邦機構必須在 4/9 前完成修補——只給三天。
拿到 EMS 伺服器的控制權意味著什麼？攻擊者可以修改端點配置、推送惡意政策、橫向移動到整個企業網路。影響版本是 7.4.5 到 7.4.6，目前只有 hotfix，正式修補版 7.4.7 還在路上。
Fortinet 今年已經不是第一次出事了。用他們設備的企業，這週請優先排這張工單。
Flowise，一個蠻多人在用的開源 AI 工作流平台，被爆出一個 CVSS 10.0 的滿分漏洞 CVE-2025-59528。這是一個 code injection 弱點，攻擊者可以直接在 server 上執行任意程式碼，達到 RCE（遠端程式碼執行）。
CVSS 10.0 是什麼概念？滿分，不能再高了。遠端可利用、不需認證、影響範圍完整、機密性完整性可用性全部淪陷。
加上前幾天報導的 Langflow CVE-2026-33017（CVSS 9.3），AI agent 基礎設施的資安問題已經不是個案了。MLflow 也有一個 CVSS 10.0 的 command injection（CVE-2025-15379），PraisonAI 的 execute_code() 函數也被發現可以執行攻擊者控制的 Python code。
這些工具的共同特徵：為了讓 AI 方便操作而開放了太多執行權限，結果攻擊者也方便了。 用 AI workflow 平台的團隊，現在該認真檢查一下自己的部署有沒有暴露在公網上。
OpenAI 的 Codex CLI 迎來重大升級：GPT-5.3-Codex-Spark 現在可以直接在 CLI 裡使用。這個模型的賣點是速度——每秒產出超過 1,000 個 token，比前代 GPT-5.2-Codex 快 25%，同時保有 frontier 等級的 coding 能力和更強的推理。
另外 Codex CLI 還加了 Windows sandbox proxy-only networking（OS 層級的出口規則）、ChatGPT device-code sign-in（CLI 環境下的登入改善）、和 dynamic bearer token refresh。
1,000 TPS 是什麼體感？大概就是你按下 Enter 的瞬間，整個函數已經寫完了。延遲感幾乎消失。當然 benchmark 速度跟實際使用體驗之間的落差向來不小，但如果真的接近這個數字，對開發者的工作流會是蠻大的改變。
AI coding 工具這週集體進化：Cursor 重寫介面、Copilot 加 Critic、Block 開源 Goose、Codex 衝到 1K TPS。與此同時，FortiClient EMS 和 Flowise 提醒我們——工具跑得再快，如果安全沒跟上，跑的方向可能是懸崖。
]]>OpenAI 的下一代旗艦模型 GPT-5.5（內部代號「Spud」）已經完成預訓練，目前進入安全評估和紅隊測試階段。根據釋出的資訊，Q2 2026 將正式向公眾宣布。同時，GPT-4 Mini 的改進版本也已開始在 ChatGPT Free 和 Go 用戶之間推出。
從技術角度來看，GPT-5.5 代表著 OpenAI 在訓練效率和模型容量上的新里程碑。去年的爭議主要集中在訓練成本和資源消耗，今年看起來他們找到了更優雅的解法。預計這次發布會直接對 Claude、Gemini 和其他競爭對手形成壓力。
原文來源：OpenAI Updates
重磅消息：NVIDIA 在 2026 年完全放棄遊戲 GPU 新品發布，全力集中在 AI 晶片生產。其中「Vera Rubin」平台已進入滿產狀態，搭載 7 款不同的 AI 加速晶片，預計下半年透過 AWS、Google Cloud、Azure 和 OCI 供應。
有點扎心的是，NVIDIA 這步棋形同宣告：遊戲市場已經不是他們的主戰場了。從 Tesla 到 Meta，再到 OpenAI，AI 基礎設施的訂單已經堆到月球。相比之下，遊戲玩家的 RTX 4090 需求簡直形同虛設。這對 AMD 的 EPYC AI 來說或許是機會，但現在恐怕為時已晚。
ChatGPT 的應用整合能力今天又升級了。現在用戶不只能讀取 Box、Notion、Linear 和 Dropbox 的內容，還能直接在 ChatGPT 對話窗口中修改——建立 Linear 任務、更新 Notion 文件、管理 Dropbox 檔案，全部搞定。
這個更新的意義在於它真正把 ChatGPT 變成了工作流中樞。以前的「讀」只是資料檢索，現在的「寫」才是生產力倍增。想像一下工程師不用切分頁面就能審查 PR、記錄會議筆記、分配任務——這就是為什麼每間公司現在都在拼命做 AI 整合。
安全界的警報：Mbed TLS 3.6.5 以下版本爆出重大漏洞（CVE-2026-34875），CVSS 分數高達 9.8。這套 TLS 庫廣泛用於 IoT 裝置、嵌入式系統和所有 ARM 處理器平台——也就是說，全球數十億台裝置都在危急線上。
一個 CVSS 9.8 的 TLS 漏洞意味著什麼？中間人攻擊、流量竊聽、密鑰洩露——所有最糟的場景都在檯面上。特別恐怖的是，很多企業的 IoT 設備根本無法快速更新韌體。這波漏洞真的會在未來幾個月引爆一堆後端事件。
Payload CMS（熱門無頭 CMS 框架）被爆出密碼恢復流程存在重大漏洞（CVE-2026-34751），CVSS 9.1。未經授權的攻擊者可以直接冒充用戶執行任意操作。官方已在 3.79.1 版本修補。
這類密碼重設漏洞特別致命，因為它通常是帳號安全的最後防線。Payload CMS 在新創和中小企業中使用度不低，如果伺服器還沒升級，現在已經是緊急狀態。趕快查一下自己的依賴版本吧，踩坑的代價真的很貴。
這週的新聞節奏就是這樣——一邊是 AI 的新高度，一邊是資安的新洞窟。GPT-5.5 快來了，NVIDIA 已經贏了，但同時 IoT 和 CMS 世界著火了。對開發者來說，該慶祝新模型，也該焦慮新漏洞。也許這就是 2026 的日常吧。
]]>