一般用戶只能用到 7 月 7 號，過了這段時間之後，以儲值方式計費。 而且每週的用量只能限制在 50% 以內。 Anthropic 讓分類器更加保守了一點。所以假設你要寫程式或者是要 debug，可能有更大的可能性會自動跳回 Opus 4.8。 問題是，改程式就是 AI 目前最強的地方。 唉，感覺上實在是很雞肋啊。

@akshay_pachaar 在 X 上分享了一個做法，他用 Google agents CLI 搭配 Claude Code，從零建立一支 RAG agent。 他把問題講得很具體：生產級 agent 開發不是只靠提示詞，還需要 spec 設計、評估迴圈和安全監管。 但實作時常常會被工具切換切碎。 編輯器寫程式，終端機搭專案支架，瀏覽器測試，雲端主控台部署，評估又另外一套框架。 每一次切換，都會讓人重新找狀態。 Google 官方 README 對 agents CLI 的定位是：給 coding agent 用的 CLI 與 skills，用來建立 Gemini Enterprise Agent Platform 上的 agent。 它不是新的 coding agent，而是讓你原本使用的 coding agent 更懂得建立、評估與部署 Google Cloud 上的 ADK agents。 官方文件列出它可搭配 Antigravity CLI、Claude Code、Codex 與其他 coding agent。 安裝流程是透過官方 setup 指令，讓 coding agent 取得 7 個 ADK 專用 skills。 這 7 個 skills 分別涵蓋工作流、ADK 程式模式、專案支架、評估、部署、發佈與觀測。 命令面也覆蓋 scaffold、eval generate、eval grade、deploy、publish gemini enterprise。 也就是說，從建立專案、產生評測資料、評分、部署到 Google Cloud，再到註冊 Gemini Enterprise，都被整理成同一條工作流。 @akshay_pachaar 的實測是用 Claude Code 建立 RAG agent。 他表示 agents CLI 從 ADK 的 agentic rag 模板搭出完整專案，接著產生 20 個評測情境，使用 LLM as judge 評分，回傳量化分數卡。 他也提到評估結果在部署前抓到 instruction loophole，這點很接近 production agent 需要的工作方式：不是做好才測，而是在流程中把測試放進去。 最後他表示這支 agent 被部署到 Agent Runtime，也註冊到 Gemini Enterprise，讓組織內其他人可以發現與使用。 這裡需要分清楚官方文件與作者實測。 官方確認的是 agents CLI 的定位、7 個 skills、主要 commands、支援 coding agent，以及本地開發不一定需要 Google Cloud，部署與雲端功能需要 Google Cloud。 至於 20 個評測情境、部署成功、註冊到 Gemini Enterprise，是作者在貼文中的實測描述。 我覺得這題對一人公司與產品開發者有參考價值，原因不是它又多了一個新工具。 而是 agent 開發正在從零散操作，變成一條可以重複執行的流程。 當 scaffold、eval、deploy、publish 都在同一套指令與 skills 裡，開發者比較容易把注意力放回 agent 本身：需求寫清楚了嗎，評估資料夠不夠，部署前有沒有抓到錯誤行為，團隊是否真的找得到並用得上。 來源：https://x.com/i/status/2071509401224261823

【用開源權重模型在本地建立 Coding Agent】今天在 X 上看到 @rasbt 寫的內容，他提到最近整理了一篇新文章，專門教大家如何用開源權重模型在本地建立 coding agent，而且一切都在本機執行，完全不依賴雲端 API。他表示這篇文章的靈感來自很多人詢問他的設定方式，他也希望透過這份整理，鼓勵更多人開始嘗試用本地模型處理實際工作。他提到今年隨著更好的 LLM 和更好的 coding harness 出現，本地模型已經不只是玩具，而是可以拿來處理嚴肅工作的選項。文章內容是一份逐步指南，說明如何把本地 LLM 連接到本地 coding harness，例如很多開發者已經熟悉的 Claude Code 或 Codex。他也附上一份挑選模型時可以使用的評估清單。第一，檢查長上下文下的 RAM 使用量，確認模型是否適合真實工作，而不是只在短 prompt 裡表現良好。第二，測量 prefill 和 decoding 的 tok/sec，確認速度是否夠快，不會讓開發流程變得卡頓。第三，確認模型理論上具備足夠的工具呼叫能力，因為 coding agent 不只是聊天，而是需要讀檔、改檔、執行命令與回報結果。第四，把模型放進 coding harness 裡，用比較有挑戰性的任務測試它是否真的能完成工作。他也提到，當然還有更專門的工具可以把效能再壓榨得更好，但這篇文章的重點是提供一個保持彈性的入門套件。也就是說，使用者可以先用這套方式開始，之後隨時切換到新釋出的本地模型。如果某個任務目前的本地模型還處理不好，也可以在同一個熟悉的 harness 裡接回雲端模型。對想降低資料外流風險、控制成本，或只是想理解本地 agent 工作流的人來說，這篇比較像是一份可操作的起點。

@angeldot_ 在 X 上分享了一個做法，他提到一位日本開發者先安裝 Claude Code 的 Find Skills，接著問：「有沒有適合 [你的目標] 的 skill？」。Claude Code 會依照這個目標找出比較適合專案的 skills。 原文還提到，這位開發者把它用在 YouTube 自動化系統，作者表示系統因此順利運作。這裡我會把它看成一個很實際的工作流提醒，不是保證工具裝好就會成功。 很多人用 Claude Code 做專案時，卡住的地方不一定是模型不會做，而是每次都從空白提示詞開始。你要重新說明需求、目標、限制、檔案結構、可用工具，以及希望 Claude 採用的工作方式。如果專案類型常常更換，這些重複描述會很耗時間。 Find Skills 的用法剛好補上這一段。你先把目標講清楚，例如要做 YouTube 自動化、整理內容流程、建立小工具、寫前端原型。再問 Claude Code 有沒有適合這個目標的 skill。它就像一個技能查找入口，幫你把專案目標接到比較適合的技能組合。 這對 AI 一人公司或 AI 副業很有用。原因不是它會替你完成所有事情，而是它減少了開工前的查找成本。你不用記住每個 skill 的名字，也不用每次都重新設計提示詞框架。先描述目標和限制，再讓 Find Skills 找入口，接著才開始讓 Claude Code 執行。 我會把這個流程拆成三步。第一步：先寫一句具體目標，例如「我要做一個 YouTube 內容自動化流程」。第二步：問 Claude Code 有沒有適合這個目標的 skill。第三步：看它推薦的技能是否符合你的資料來源、輸出格式和可接受風險。 原文的安裝方式是用 npx skills add 安裝 Find Skills。因為貼文裡的完整指令含特殊符號，實際使用前仍建議回到原文或工具來源確認。 來源：@angeldot_完整原文：https://x.com/i/status/2070620788592369881 來源：https://x.com/i/status/2070620788592369881

還在埋頭寫 prompt？真正高效的 AI 自動化，關鍵從來不是一句完美指令，而是「設計流程」。 我整理了一個 Claude Code 技能 —— Loop Engineering：用十種迴圈模式（重試、反思、評估、規劃、工具呼叫、查證、記憶、多代理、人類介入、持續優化），帶你把任務拆成「會反覆執行、檢查、修正、直到達標」的系統。 它會先逼你回答七個關鍵設計問題，再選用合適的模式組合，最後才談用哪個工具落地。平台中立（Codex、n8n 都適用），在 Claude Code 裡還附原生工具對照表。 一鍵安裝、也可手動複製，MIT 授權，歡迎取用 👇🔗 https://github.com/iamraven-tw/loop-engineering 介紹文章放在 進階｜打造個人化生產力系統(Lv2)