歡迎訂閱  愛好 AI Engineer 電子報 過往期數點這 

Hello! 各位 AI 開發者大家好

跟大家拜個晚年！過年假期在玩 OpenClaw 非常有趣。

它是一個開源的自架 AI Agent 軟體，常駐在你的伺服器上。你會透過 Telegram、Discord 等通訊渠道，隨時隨地交代任務。等於擁有一個可以操作整台電腦、定時執行任務的個人助理。

我在 Facebook 上有分享了一些經驗，也有了一些新的想法：

• 把龍蝦裝在樹莓派上，蓋了一個部落格
• 開了龍蝦的 Threads 帳號
• 拆開獨立的 AI 帳號來發文

目前玩法是把 OpenClaw 的 AI Agent (就叫蝦蝦吧)當作我的新員工看待，盡量只用 Telegram 交代他做事 (雖然偶爾還是會有出戲感，會需要手動SSH進去Server排除技術問題)
帳號也都是開新的給他，只開他任務需要知道的權限，而不是讓他去接手我的帳號權限。我認為這是比較好的安全界線。

這是我給蝦蝦新建立的帳號:

• 愛好 AI 工程 Blog: blog.aihao.tw/ (整個站都是AI生成)
• Threads: www.threads.com/@xia_aihao
• Facebook 粉專: www.facebook.com/xia.aihao

從本期電子報起，分享的文章摘要內容，會更直接就是 AI 生成的，會明確區分哪些內容完全是 AI 產出的。
相比之前電子報有花時間每篇人工審稿修改，之後會更放手直接就放 AI 產出，反正大家也看習慣 AI 摘要了(?)

不過放心，選題還是我真人做: 選擇哪些東西值得寫值得分享，還是有人類的聯想、判斷力和直覺。因此要分享哪些文章主題，都是我是挑好才交給 AI 後續處理的。

對於 AI 生成內容的閱讀建議: 只是幫助你快速掌握原文重點的導讀。畢竟原文往往篇幅較長、不容易快速消化，透過翻譯與摘要，
你可以在短時間內了解核心概念。但請留意，摘要無法涵蓋所有細節與脈絡。如果讀完覺得有興趣，強烈推薦點進原文獲得完整資訊。

換句話說: 時間充裕的話，可以直接點原文閱讀。如果時間有限，可以先看中文導讀，有興趣再深入原文。
無論如何，我對自己挑選要分享的原文還是有信心都是很好的內容

在本期分享的精彩文章中，有幾篇我特別有收穫：

• 為什麼多數 Agent 框架都沒有內化 Bitter Lesson? 這篇把 Agent 框架的發展方向，搭配我很喜歡的 Bitter Lesson 一起講得非常到位，我很認同
• AI Agent 怎麼管理 Context? 從設計模式到 Deep Agents 實作 和 如何選擇 Multi-Agent 架構? LangChain 整理的 Agent 設計模式與架構選擇，很有系統性
• Agent Skills 完整攻略: 從建立到評估 Skill 的評估很少人講，「Skill 到底有沒有被順利觸發」是個關鍵問題
• AI Evals 閃卡全解析: Hamel Husain 的 12 張精華卡片 Hamel Husain 是我的 AI Eval 老師，他出的這套閃卡把核心方法論濃縮得非常精煉

以下是我挑選文章後，由 AI 生成的內容

如何選擇 Multi-Agent 架構?

• 比較 Subagents、Skills、Handoffs、Router 四種架構的優缺點
• 建議先從單一代理搭配好的工具開始
• 只有在 context 塞不下或團隊需分工時才考慮多代理

Open Responses: LLM API 終於要有統一標準了嗎?

• OpenAI 提出通用 LLM API 規範 Open Responses
• OpenRouter、Hugging Face 等主要廠商已支持
• 有望降低不同 LLM 平台之間的整合成本

2025 AI 大混戰回顧: 從 Code Red 到 IDE Wars

• Google Gemini 3 Pro 奪回性能第一
• Anthropic 在企業市場和編碼工具佔據優勢
• OpenAI 面臨多方挑戰

LangChain Agent Builder 的記憶系統是怎麼做的

• 用檔案系統架構管理 Agent 的三層記憶（程序、語意、情節）
• 讓 Agent 能自動從互動中學習和更新記憶

用 AI 寫 code 更快了，但你真的有學到東西嗎?

• Anthropic 研究發現使用 AI 助手的工程師考試分數低了 17%
• 除錯能力退化最為明顯
• 過度依賴 AI 可能導致核心技能萎縮

Anthropic 內部研究: AI 如何徹底改變他們自己的工作方式

• 工程師角色從「寫代碼」轉向「管理 AI 代理」
• 帶來生產力提升與技能邊界擴張
• 也引發技能萎縮和職涯不確定性的擔憂

為什麼多數 Agent 框架都沒有內化 Bitter Lesson?

• 固定工作流和預定義角色違反 Bitter Lesson 原則
• 應轉向動態委派和遞迴語言模型等可規模化方法

Jason Liu 的 Context Engineering 系列: 打造更好的 Agentic RAG 系統

• 涵蓋工具輸出設計、Subagent 架構、信息壓縮
• 系統化講解生產級 Agentic RAG 的關鍵決策點
• 從快速原型驗證到實際部署的完整路徑

如何為 AI Agent 設計有效的評估 (Evals)

• Anthropic 分享不同 Agent 類型的評估策略
• 講解 pass@k vs pass^k 的選擇
• 提供從零開始建立 Eval 的路線圖

AI Evals 閃卡全解析: Hamel Husain 的 12 張 Evals 精華卡片

• 12 張圖解卡片濃縮 AI Evals 核心方法論
• 涵蓋錯誤分析、Eval 時機、指標選擇到部署策略

為什麼通用 AI 指標是海市蜃樓?

• ROUGE、BERTScore 等通用指標對實際產品無用
• 應用質性錯誤分析驅動自定義評估指標
• 評估要針對特定領域量身打造

LangSmith Insights Agent 深度拆解: 從 Clio 論文到生產級 Agent 的完整旅程

• 用 LLM 驅動的分類取代傳統 Embedding 聚類
• 自動發現生產環境中的使用者行為模式和失敗原因
• 從研究概念進化為實用的 debugging 工具

OpenAI 內部的 Data Agent: 六層 Context + RAG + Text-to-SQL 的實戰架構

• 透過六層漸進式 Context 實現高品質自然語言轉 SQL
• 包含元數據、查詢歷史、人工標註、程式碼增強、組織知識、記憶

Product Evals 三步驟: 從標註資料到自動化評估

• 手動標註一小批資料
• 用二元標籤校準 LLM 評估器
• 每次改動都跑評估，縮短迭代回饋迴圈

AI Agent 時代，Trace 才是你的 source of truth

• Trace 取代原始代碼，成為理解 Agent 真實行為的關鍵
• 用 Trace 進行 Debugging、Testing、Performance Profiling 和品質監控

OpenAI 內部實驗: 100% AI 寫的產品，人類只負責導航

• OpenAI 用 Codex 從空白代碼庫開發產品，五個月產出百萬行代碼
• 工程師角色轉為設計環境、制定約束、執行架構品味

讓 AI Agent 更可靠的 9 種方法: 從 Workflow Builder 到 Response Caching

• 整理 9 種讓 Agent 行為更可預測的方法
• 從最高層的工作流建構器到最底層的模型改進
• 各有不同的準確性和靈活性取捨

用 Evaluation Flywheel 系統化改進你的 Prompt

• 評估飛輪三階段：分析問題、自動化測量、迭代改進
• 無需編程即可利用 OpenAI 後台評估工具
• 系統化改進 Prompt 品質

Jeff Dean 和 Sanjay Ghemawat 的效能優化心法

• 從背包估算、Profile 分析到資料結構選擇與 API 設計
• 強調應該在寫代碼時而非事後才考慮效能

RAG 不只是 Vector Search: 從語意相似度到真正的搜尋理解

• 向量搜尋無法真正解決 RAG 問題
• 應用 LLM 將自然語言轉化為結構化查詢
• 結合領域特定的篩選邏輯，而非一味依賴向量相似度

2025 年 LLM 發展回顧: 推理模型、Benchmaxxing 與未來預測

• 2025 年關鍵進展是推理模型和推論時擴展
• 過度追求基準分數（Benchmaxxing）造成虛假繁榮
• 真實產品表現才是關鍵指標

AI Agent 怎麼管理 Context? 從設計模式到 Deep Agents 實作

• Agent 設計的核心本質是 Context 管理問題
• 包括多層 Action Space、漸進式揭露
• 把 Context 卸載到檔案系統

Agent Files: 檔案系統正在成為 AI Agent 的核心介面

• 檔案系統用於 Agent 的長期記憶、取代傳統 RAG、作為 Skills 機制
• 需要像 AgentFS 這樣的虛擬層來確保安全性

Agent Skills 完整攻略: 從建立到評估，Anthropic 和 OpenAI 的方法論整理

• Anthropic 和 OpenAI 同時推出 Agent Skills 深度指南
• Skills 用 YAML Frontmatter + SKILL.md 定義
• 透過確定性檢查和 Rubric-based 評分系統化評估

當你的面試題被自家 AI 打敗: Anthropic 的技術考試攻防戰

• Anthropic 工程師分享設計「AI 防禦」技術面試的經驗
• 傳統題目無法抵抗強大 AI
• 應轉向「新穎」問題來測試人類推理能力

OpenAI API 推出 Skills: 讓 AI Agent 從單次回覆走向長時間工作流

• Skills API 讓 Agent 執行多步驟工作流程
• 搭配升級版 Shell tool 和伺服器端壓縮
• 使 Agent 能真正執行長時間、複雜的知識工作

希望你會喜歡這集新的結構和內容！有任何想跟我分享的事情，也歡迎直接回覆這封信給我。

– ihower

歡迎訂閱  愛好 AI Engineer 電子報 過往期數點這 

Hello! 各位 AI 開發者大家好

2026 新年快樂，這期內容偏向 2025 年 AI 年度回顧與整理。

Andrej Karpathy: 2025 LLM Year in Review

大神 Karpathy 發表了他的 2025 LLM Year in Review 年度回顧，整理了 2025 年 LLM 領域最顯著的「典範轉移」

中文摘要在我 Facebook 貼文。

Andrej Karpathy: AGI is still a decade away

大神 Andrej Karpathy 在 2025 十月的一場訪談，內容兩個多小時內容很多。這場訪談涵蓋了 AGI 時間表、強化學習的侷限、自駕車的現實挑戰、以及他為什麼從 AI 研究轉向教育等等。
這裡我分享我最有感的四個子主題內容:

1. RL 強化學習還不夠，我們還需要新做法
2. LLM 的認知缺陷: AI Coding 你很順，只是因為你做的事情 AI 都訓練過了
3. 人類如何學習 vs. 大模型: 模型坍塌問題與記憶詛咒
4. AGI 最終會融入 2% GDP 增長: 沒有奇點時刻，只有持續的緩慢擴散

中文摘要在我 Facebook 貼文。

Mark Chen: How OpenAI Shapes Its Research And What’s Next

這是 OpenAI 研發長 Mark Chen (陳信翰) 在 2025/12 接受 Core Memory podcast 的訪談內容。

這篇訪談讓我繼續保持對 OpenAI 的信心，雖然最近 OpenAI 的光環在強敵環伺之下有所減少，但我對 OpenAI 還是最有感情的，也是我投入最多時間研究使用的 API 平台。
這集訪談，可以感受到 Mark Chen「我們知道自己在做什麼，不會被外界牽著走」的自信

中文摘要在我 Facebook 貼文。

AI in 2025: gestalt

一篇蠻有料的 2025 年度 AI 回顧文章 “AI in 2025: gestalt”，作者是 Gavin Leech 是研究顧問公司 Arb Research 的共同創辦人。

這篇文章有 300 多個引用連結，從模型能力進步、安全研究到產業動態都有深入分析。有蠻多我原先不知道的知識點。

中文摘要在我 Facebook 貼文。

Thoughts on AI progress (Dec 2025)

Dwarkesh Patel 是一位 Podcast 主持人，主持長篇訪談節目 Dwarkesh Podcast，訪問過很多 AI 大咖。他最近寫了一篇對 AI 進展的看法，蠻有意思的。

• 短期適度看淡，因為目前的模型缺乏「持續學習」能力，還無法像人類一樣邊做邊學、舉一反三，因此難以真正取代人類勞動力。
• 長期爆發看好，因為一旦這個關鍵瓶頸突破，數十億個能不斷累積經驗、相互分享學習成果的 AI，影響將會是爆炸性的。

中文摘要在我 Facebook 貼文。

The Truth About The AI Bubble

這是 YC 的一場 Podcast 聊到 2025 年最讓他們驚訝的 AI 趨勢，其中最讓我注意的 Anthropic 已經超越 OpenAI 成為新創首選的模型供應商惹。

這也跟我最近看到一篇的市占率趨勢一致: OpenAI ChatGPT 仍然主導消費者市場(高達八成)，但企業端市場 Claude 已經略為反超。

不過有趣的是，其中非技術員工仍偏好 ChatGPT，技術人員則更愛 Claude。

中文摘要在我 Facebook 貼文。

The Agent Labs Thesis

最近 Manus 被 Meta 併購，又冒出是不是套殼 app 沒有護城河的說法。這讓我想起前陣子 Latent Space 的一篇文章，提出了一個 AI 公司的分類方式: Agent Labs vs Model Labs。

Model Labs 大家都知道: OpenAI、Anthropic、Google 這些專注在訓練最強模型的公司。

而 Agent Labs 則是另一種打法: Cursor、Perplexity、Cognition、Sierra、Lovable 這些公司，他們不訓練 SOTA 模型，而是專注在打造最強的 AI Agent 產品。

中文摘要在我 Facebook 貼文。

你的工作是提交已被驗證可運作的程式碼!

To 軟體工程師: 你的工作是提交已被驗證可運作的程式碼!

近來在開源專案中，開始出現一種 PR 型態：在缺乏實際使用情境或對應 issue 的前提下，短時間內提出多個小型修正。這類 PR 通常：

• 沒有明確的問題背景
• 缺乏可重現案例或測試驗證
• 描述篇幅很長，但關鍵動機不明確

即使出發點是善意，這樣的提交方式仍可能增加 reviewer 與 maintainer 的負擔，降低審查效率。無論程式碼是否透過 AI 協助產生，責任都在提交者。最好在送出 PR 之前，應確認：

• 問題確實存在
• 修改能穩定重現與驗證
• 變更動機清楚且具體
• 已人工測試並理解影響範圍

剛好最近看到 Simon Willison 這篇 “Your job is to deliver code you have proven to work” (原文連結在留言)，是很好的呼籲。

中文摘要在我 Facebook 貼文。

反向半人馬

上一篇講軟體工程師應該要提交已被驗證可運作的程式碼，沒想到獲得蠻多迴響，看來的確有不少 senior code reviewer 有被提交上來的 AI slop code 氣到

來繼續分享一篇 AI 懷疑論的內容好了，到底 AI 可以取代你的工作嗎? 科幻作家 Cory Doctorow 在華盛頓大學的「神經科學、AI 與社會」講座中，分享了他對 AI 產業的批判觀點。

雖然我不是完全認同，內容也有一些對 AI 技術的理解偏差，但論點仍然犀利值得思考，摘要分享如下:

中文摘要在我 Facebook 貼文。

AI Coding Accelerator: How Amp uses Amp

看了一場 Sourcegraph AMP (也是一家 Coding Agent 工具) 團隊分享他們內部怎麼用 AI Coding 的實戰技巧，非常讚。

中文摘要在我 Facebook 貼文。

Evaluating Context Compression for AI Agents 評測

OpenAI API 最近默默推出了一個神奇的 /responses/compact 壓縮功能，可將對話紀錄的所有 assistant 輸出、工具訊息和輸出，通通壓縮變成加密 tokens，只保留 user messages。

這功能可用在 context window 滿的時候，將用戶的歷史對話做一次摘要壓縮，好讓用戶可以持續對話，是開發 Agent 常見的需求。
和使用摘要 prompt 來做不一樣，OpenAI 這個可能是 KV cache 或某層的 hidden state，就像是模型的記憶快照存下來，而不是人類看得懂的摘要，輸出是一種加密的 tokens 給你。

我實際測試了壓縮效果很驚人: 170k 壓縮到 5k，另一串 76k 壓縮到 4k。但壓縮率這麼高，摘要品質到底如何？
最近終於等到 Factory AI 這家公司做了一個實驗來回答這個問題: 當 AI Agent 對話歷史太長超出 context window 時，不同壓縮方法的效果差多少？

他們比較了三種方法，測試資料來自真實的 coding agent session，包括 debug、code review、功能開發等場景，總共超過 36,000 則訊息。

中文摘要在我 Facebook 貼文。

搜尋技術不會消失，只是變成 Agent 的工具: 談 Agentic Search

看了兩場關於 Agentic Search 的演講，分別來自 AWS OpenSearch 的 John Handler 和 AI-Powered Search 這本書的作者 Doug Turnbull (這有很多檢索知識文章，超讚)，兩位都在探討: AI Agent 是否正在取代幾十年累積的搜尋智慧?

全文見我 Blog 文章。

OpenAI Agents SDK 開發日記: Gemini 3 和跨模型對話支援

我最近貢獻了 Gemini 3 整合以及跨模型支援至 OpenAI Agents SDK: PR #2158，已經被合併發佈 v0.6.5。

開發經驗全文在我 Facebook 貼文。

Agent Skills 資料整理

Agent Skills 是近期 Coding Agent 非常熱門的功能，我收集整理了一些 Agent Skills 的資料在我的筆記裡。

—

希望你會喜歡這集內容！祝大家在 2026 年的開發與學習一切順利！

– ihower

第一場: John Handler – Agentic Search 技術

John 從搜尋的三個時代演進切入:

1. Lexical Search (詞彙搜尋) 用 BM25/TF-IDF 做關鍵字匹配，快速但難以理解語意。搜尋 “large screen televisions” 可能找不到描述中沒有 “large” 這個詞的大螢幕電視。

2. Semantic Search (語意搜尋) 用 embedding 向量捕捉語意，能理解 “shoes for the beach” 這種抽象需求，即使商品描述沒提到 “beach”。OpenSearch 的 Neural Plugin 可以在 ingest pipeline 自動調用 Bedrock 生成 embedding，查詢時也能自動轉換。

3. Agentic Search (代理搜尋) Agent 可以規劃、執行多個工具、推理結果，直到找到滿意的答案。

傳統搜尋的流程

John 強調，即使在 LLM 之前，搜尋工程就已經是一個複雜的生態系統:

• Data Preparation: 清洗、enrichment、entity recognition
• Query Rewrite: 加入用戶偏好、品牌傾向、同義詞擴展
• Re-ranking: 用歷史點擊/購買行為重新排序
• Feedback Loop: 捕捉用戶行為回饋到模型

這些「幾十年的智慧」不會消失，而是變成 Agent 可以調用的工具。

OpenSearch Agent 實作細節

John 用 OpenSearch 內建的 Conversational Agent 框架做了演示，幾個實作重點:

Tool 設計: 他為 Agent 準備了多個工具，semantic search、lexical search、Q&A search (搜尋用戶對產品的問答)、category lookup 等。每個 tool 都有明確的描述告訴 LLM 什麼時候該用。

System Prompt 設計: 關鍵是給 LLM 決策指引，例如「如果是廣泛的產品搜尋，用 category + lexical + semantic 工具；如果是關於產品特性的問題，用 Q&A search 去找用戶問過的問題」

對話脈絡: 搜尋 “everyday pants” 後，接著說 “I’m a man”，Agent 能理解這是對話中的補充條件，自動過濾出男性款式。傳統搜尋根本做不到。

用戶行為數據還是重要的

John 強調傳統的用戶行為分析在 Agentic Search 中依然重要，但用法不同:

• 在 Tool 層面: 傳統的 click model、user behavior 還是可以用來提升底層搜尋工具的品質
• 在 Prompt 層面: 可以把用戶偏好 (如「這個用戶喜歡 Nike」) 加到 Agent 的 context 中，讓推理更個人化

第二場: Doug Turnbull – Agentic Search 典範轉移

maven.com/p/e029a8/what-is-agentic-search-and-why-should-i-care

Doug 從「資訊需求」的角度切入，把搜尋場景分成兩端:

左端 – System 1 (直覺、被動) 瀏覽、打發時間、即時滿足。用戶可能自己都不清楚要什麼，更像 recommendation feed。

右端 – System 2 (理性、主動) 有明確目標、可以寫成一整段需求描述。法律案例檢索、求職、醫療文獻搜尋這類場景。

Doug 的核心論點: 對於 System 2 這端的搜尋，Agentic Search 就是典範轉移。

傳統搜尋的根本問題

「傳統搜尋像是把一整段需求壓縮成三個關鍵字塞進管道，然後祈禱另一端能解壓縮出正確結果。」

搜尋引擎只看到 “java developer downtown” 這幾個字，完全不知道用戶的完整需求是「我想找一份 Java 開發工作，要能走路到 Charlottesville 市中心，薪資範圍…」

然後我們用各種 query understanding、re-ranking 來補救這個資訊損失。

Agent 的三個關鍵能力

1. Reasoning (推理) Agent 會 “think step by step”，規劃解決問題的步驟。現代 reasoning model 已經把這個能力放進模型訓練裡，不需要特別 prompt。

2. Tool Usage (工具使用) Agent 可以調用搜尋工具、評估結果、決定下一步。訓練資料中已經有大量 web search 的使用範例，所以 LLM 對 tool calling 有不錯的理解。

3. Reflection (反思) Agent 可以看結果不好，調整 query 再試。Doug 舉了 ReAct 論文的例子: 搜尋 “Apple Remote”，發現結果不好，Agent 自己加上 “Front Row software” 來 refine query。

Tool Calling 實作眉角

Doug 分享了用 OpenAI API 來做 tool calling 的方式，關鍵是 schema 設計要好，讓 LLM 知道每個參數的意義。

如何加入 User Satisfaction 信號？

這是很重要的一點: Agent 自己判斷的 “relevance” 可能跟真實用戶滿意度不一致。

解法是把 satisfaction model (例如 Learning to Rank 模型) 包裝成另一個 tool，讓 Agent 可以查詢「這個結果用戶會滿意嗎？」就像 coding agent 需要跑 unit test 一樣，search agent 也需要 “relevance test”。

Prompt 技巧: Doug 提到一個有趣的發現，如果你用「這個結果是否 relevant」來描述，效果普通。但如果改成「這個結果會讓用戶 happy 還是 unhappy」，LLM 會更努力去優化，因為 LLM 天生就是 sycophant (討好者)，它們很想讓用戶開心

能否把 Agentic 學習應用到傳統搜尋？

Doug 提出一個很有趣的想法: 用 Agent 離線跑 query，學習最佳策略，然後部署到即時系統:

1. 直接 Cache: 把 query → tool usage 結果直接存起來，完全相同的 query 直接復用
2. Semantic Cache: 存到向量資料庫，語意相似的 query (例如 “red shoes” vs “shoes that are red”) 也能命中 cache
3. 訓練 ML 模型: 用 Agent 跑出來的 query → category/expansion mapping 當訓練資料，訓練一個輕量分類器部署到線上
4. Code Generation: 最進階的玩法，讓 Agent 生成 re-ranking code，迭代改進直到 NDCG 提升。Doug 實驗顯示這招有效，NDCG 介於純 BM25 baseline 和 online agentic search 之間

現實挑戰

• 延遲: Agent 多輪推理目前還做不到毫秒級
• 成本: LLM 呼叫費用是大問題，frontier model 效果好但貴
• 開源模型: Tool calling 在 Llama 等開源模型上的支援度還在追趕中

總結

兩位講者都認為這是不可避免的典範轉移，尤其對於「用戶知道自己要什麼、需要深度搜尋」的場景。

特別是企業搜尋、專業領域搜尋這類應用，傳統搜尋工程的智慧不會消失，而是角色改變了。從「建造一個 monolithic 搜尋系統處理所有情況」變成「設計一組精準的檢索工具讓 Agent 使用」。

歡迎訂閱  愛好 AI Engineer 電子報 過往期數點這 

Hello! 各位 AI 開發者大家好

2025 Q4 各家陸續推出新模型，SOTA 模型輪流當。以下整理新模型消息，以及集結我最近發表的內容。

OpenAI GPT-5.1 & GPT-5.2

GPT-5.1 和 GPT-5.2 對開發者來說，推理程度參數多了一種是 none，移除了 gpt-5 的 minimal 選項。基本上除了 context window 還不及 GPT-4.1 之外，其他場景都應該可以替代 GPT-4.1 在非推理場景需求了。另外要注意 GPT-5.2 有漲價 40%。
整理幾篇對開發者比較相關的內容:

• Introducing GPT-5.1 for developers
• Using GPT-5.2
• Cookbook: GPT-5.1 Prompting Guide
• Cookbook: GPT-5.2 Prompting Guide

Gemini 3

Gemini 3 Pro 和 Gemini 3 Flash，對開發者來說，最大的影響是同一輪內的 function calling 要求回傳思考簽章了，詳見 Thought Signatures

• New Gemini API updates for Gemini 3
• Gemini 3 Prompting: Best Practices for General Usage

不過要注意這都是 Preview 版，還不太適合產品商用的，我自己測試還蠻容易就有 API model overloading 錯誤。

Claude 4.5

Claude Sonnet 4.5、Claude Haiku 4.5 、Claude 4.5 Opus 陸續推出。Opus 4.5 的價格比 Opus 4.1 便宜三倍，變成蠻有競爭力的頂級模型，尤其是在其詞元效率優於 Sonnet 4.5 的情況下。

實戰 AI Agents 應用開發: TTFT 和 Prompt Caching

這是我 2025/12/13 在 WebConf Taiwan 分享的演講投影片，以 Python FastAPI + OpenAI Agents SDK + 前後端分離架構為例，展示如何讓 Agent 流暢地進行串流輸出，以 TTFT (Time To First Token) 與 Prompt Caching 優先的系統架構。

AI Agent 產品開發仍然不簡單

在講完 WebConf 之後，我有種莫名的不協調感: 一方面 Vibe Coding 讓大家寫程式變簡單了，人人都可以做 App 了，也很多人講硬技能不重要了。但另一方面，我覺得開發 AI Agent 產品仍是非常有技術挑戰性的，需要的知識技能深度廣度一點都不少。

最近也看到了幾篇關於 AI Agent 開發的文章，發現國外技術社群在 2025 Q4 也有類似的體悟: Agent 產品開發設計還是很難。

不是「寫程式很難」那種難，而是「95% 的 AI Agent 產品，部署到正式環境會失敗」這種難。問題不在模型不夠聰明，而在於周邊的工程架構: context 管理、memoy 設計、錯誤處理、agent prompt 最佳化、語意檢索、評估回饋機制等等，很多都是全新領域，且戰且走的情況。模型只能用幾個月就要升級更換，幾個月前的 best practice 也可能會被推翻重新思考。

總之，我整理年底四篇我覺得關於 Agent 開發氛圍的不錯文章，詳見我的 blog 文章 AI Agent 產品開發仍然不簡單。

更多討論在我 Facebook 貼文。

Spec-Driven Development(SDD) 的美好願景與殘酷現實

Spec-Driven Development (SDD) 是什麼? 簡單說講就是在用 AI 寫程式之前，先讓 LLM 生成一大堆規格文件: 產品需求 → 技術設計 → 任務清單，然後才交給 coding agent 執行。目前有幾個工具在推這套流程: GitHub 的 Spec-Kit、AWS 的 Kiro、還有 Tessl。

社群討論其實非常兩極。正面看法認為遠比 vibe coding 可靠、適合要上線維護的真實專案、開發速度中期來看其實更快。負面看法則認為這就是 Waterfall 2.0、過度工程化、扼殺創造力。我自己從一開始就不太看好，最近看到幾篇深度分析文章，更加印證了我的看法。

整理分享一些關於 Spec-Driven Development (SDD) 的看法和內容)，詳見我的 blog 文章 Spec-Driven Development(SDD) 的美好願景與殘酷現實。

更多討論在我 Facebook 貼文。

Framework Desktop 開箱

我買了一台 Framework Desktop (AMD Ryzen AI Max+395) 來跑大模型，這是我的開箱文。

我的 OpenAI Agents SDK 開發心得

最近工作之餘的 side project 變成貢獻 OpenAI Agents SDK，發了一堆 PR。

這是我的一點心得，詳見 Facebook 貼文
(這篇是更早的時間兩個月前 2025/10/18 發表的，電子報這裡集結收錄)

關於 Context Engineering 上下文工程

最近看到一些介紹 Context Engineering 的內容，仔細一看，發現本質上還是在講 Prompt Design

什麼情況下才需要關心 Context Engineering？這是給 AI Agent 用的技術，專門處理工具輸出爆炸性增長的 tokens 問題，目的是應對模型 context window 的限制。

因此如果你不是因為 context window 的限制而需要，只是因為你覺得 Context Engineering 這個詞比 Prompt Engineering 更有脈絡感而用它，我建議不如發明更精準的詞彙，像是 Contextual Prompt Design 或 Context-Driven Prompt Design。不要拿技術圈的名詞，把實質內容拿掉變成 buzzword。

其實 Prompt Engineering 也是，如果沒講到怎麼做評估，那其實只是在做 Prompt Design。要有評估迭代階段(人工也算)才是有 “Engineering” 喔!

現階段來說，我覺得只有兩種人會常接觸到 Context Engineering:

1. AI Agents 的建構者、開發者，需要使用到 context engineering 策略。
2. AI Coding 的寫程式用戶: 因為這種場景常常會將 context window 用超過，例如 Claude Code 內建了許多 context engineering 招式，例如 compact 和 sub-agent，因此若多了解 context engineering 可以運用得更好

如果是一般人對話用 AI，你的使用場景不會常常把 context window 用完(至少 > 200k，約20萬中文字)，那 Context Engineering 對你來說其實沒派上用場。

而且在 Claude 或 ChatGPT 中，如果真的超過 context window，會直接看到超過 length limit 的錯誤訊息。這時其實什麼 context engineering 招式都用不了，因為這是需要 Agent 底層開發的功能，用戶根本無法自己寫程式加上去，你沒辦法動態剪裁它，改改 Prompt 並不能做到 Context Engineering 需要做的事情。

Manus 和 LangChain 的分享

小小吐槽完，來看一場由 Manus + LangChain 主辦的 Context Engineering 線上研討會，分享了經過實戰驗證的策略，涵蓋如何管理 context windows、優化效能，以及打造可擴展的代理人。
錄影影片、講者投影片都有，我放留言。以下我摘重點分享:

為何做 Context Engineering?

因為 Agent 的 context 會不斷爆炸性增長，因為 Agent 會不斷呼叫工具(tool calling)，每次呼叫都會產生一個工具觀察結果(tool observation)，然後這些都會被加到對話記錄裡。Manus 提到，典型任務需要約 50 次工具呼叫，Anthropic 也說生產環境的 agent 可能有數百輪對話。更糟的是，研究顯示 效能會隨著 context 增長而下降。這就是矛盾: Agent 因為工具呼叫會累積大量 context，但 context 越多效能越差。

Lance 整理了五種主要策略:

會在每一輪對話中，在 Agent 底層程式中動態套用以下策略

1. Context Offloading (上下文卸載)

不需要把所有東西都塞在 context window 裡，可以把資訊移到外部，例如:

• 使用檔案系統: Claude Code、Open Deep Research 都這麼做
• 把工具呼叫的大量輸出存到檔案，只回傳最小必要資訊給 agent

2. Context Reduction (上下文縮減)

壓縮或總結資訊，例如:

• 總結工具呼叫的輸出
• 刪除舊的工具訊息(例如 Claude 4.5 現在內建支援這功能)
• 壓縮整個對話歷史(例如 Claude Code 的 compaction 功能)

3. Context Retrieval (上下文檢索)

按需檢索 context，有兩派做法:

• Cursor: 使用 indexing 和語義搜尋，加上簡單的檔案搜尋工具(glob, grep)
• Claude Code: 只用檔案系統和簡單搜尋工具 兩種方法各有優缺點，都很有效

4. Context Isolation (上下文隔離)

使用多個 sub-agents，每個有自己的 context window，實現關注點分離。
Manus、Open Deep Research、Claude 的 multi-agent researcher 都採用這個策略

5. Context Caching (上下文快取)
   這是 Manus 特別強調的技巧 ，他們之前也有寫過blog 文章特別強調這點。

Manus 還分享了更多新思路

1. 選擇性保留的藝術: 不只是縮減內容，而是知道要保留什麼。並非所有的工具輸出都是平等的。有些工具會生成 Agent 需要多次引用的豐富結構化資料。其他工具只是二元信號——是或否，成功或失敗。對於豐富的結構化資料，你通常想保留完整的輸出，或者至少保留一個非常詳細的摘要。對於二元信號，你可以積極地修剪它們。
2. 時間衰減策略: 最近的上下文通常比舊上下文更相關。但這並不總是成立。有時 Agent 在任務早期做出的決定對後續步驟至關重要。所以實作了時間衰減機制，但會為關鍵決策點、重要工具輸出和錯誤訊息設定例外，這些會被保留更長時間，因為它們往往對 Agent 的推理軌跡很重要。
3. 階層式摘要: 在不同層級進行摘要，創造了一種「壓縮金字塔」，Agent 可以根據它需要多少細節來檢索不同層級的資訊。
4. 動態閾值修剪: 不是在固定的 token 計數時修剪，而是根據任務複雜度、Agent 的進度和可用的上下文預算來調整修剪閾值。對於簡單的任務，會更積極地修剪。對於複雜的任務，會給予更多餘地。

關鍵在於: 上下文縮減不僅僅是移除東西，而是策略性地保留正確的資訊，以最佳密度呈現，並在正確的時間使用。

另外 Manus 提到一個實用小建議: 當 LLM 已經針對特定工具名稱進行了大量訓練時，使用相同的工具名稱可能會帶來預訓練的優勢，但如果你的工具實作細節不同，反而可能造成模型的混淆，這時反而應該用不同的工具名稱。

最後，Context Engineering 不是完美解決方案。Peake 坦白說，很多技巧還在實驗階段，而且變化很快。重點是要在 context engineering 和產品開發之間找到平衡，不要過早優化。

• 演講錄影
• 投影片
• 投影片
• 逐字稿整理文章

更多討論在我 Facebook 貼文。

做 LLM-as-a-Judge 評估，別用 1-10 分評分了

做 LLM-as-a-Judge 評估(也就是用另一個 AI 來評估你的 AI 輸出好不好)，別用 1-10 分評分了

看到一篇很實用的評測研究，關於 LLM-as-a-Judge 該用什麼評分方式比較好。

Arize AI 團隊測試了包括 GPT-5-nano、Claude Opus 4、Qwen3-235B 和推理模型 o3，想知道用數字評分(例如 1-10 分)還是二元評分(對/錯、好/壞)更可靠。

實驗設計是這樣: 他們準備一段文字，然後故意加入不同程度的錯誤(例如拼字錯誤、情緒化用語)，再讓 LLM Judge 評估錯誤比例。測試了幾種評分方式:

• 1-10 等分制
• 0-1 分 二元制
• A 到 E 多分類標籤

主要發現:

1. 數字評分不穩定

• 無法區分品質差異: 錯誤率 20% 和 50% 的文字，可能都被評為 6 分，無法區分品質差異
• 分數容易跳躍，例如從 5 分突然跳到 8 分，中間沒有漸進變化
• 多次評分同一段文字，每次給的分數都不太一樣
• 不同模型給的分數尺度不同，GPT 可能給 7 分的文字，Claude 可能給 4 分，難以比較

1. 推理模型(o3)表現較好，但成本高

• o3 在評估情緒化錯誤時表現不錯，分數變化比較平滑連續
• 但在拼字錯誤的評分上，還是很快就「飽和」，只要有一點錯誤就給低分，無法區分輕微和嚴重的差異
• 推理模型成本高很多，要評估效益是否划算

1. 字母等級(A-E)穩定但粗糙

• 用 A-E 評分比數字穩定，多次評分結果較一致
• 但解析度很低，大部分樣本都擠在 A-C，只有極端情況才會出現 D 或 E
• 本質上更像「分類標籤」而非精確評分

1. 二元評分和多分類最可靠

• 二元判斷(好/壞、對/錯)最穩定，不同模型、不同 prompt 都能得到一致結果
• 多分類(例如 A-E 或「優良中差」)是折衷方案: 比二元有更多層次，又比數字評分穩定
• 研究證實離散標籤比連續數字更能穩定反映品質差異

實務建議:

如果你需要穩定、可重現的評估結果 → 用二元或多分類標籤

如果一定要用數字評分 → 必須嚴格控制 prompt、模型和參數設定，並且做好校準

推理模型能提升穩定性，但要評估成本是否值得

用 LLM 來做評估輸出時，評分格式的選擇比想像中更重要: 數字評分看起來精確，實際上卻容易出現難以預期的不穩定。二元或分類標籤雖然看起來粗糙，反而更能穩定反映品質差異。

更多討論在我 Facebook 貼文。

RFT, DPO, SFT: Fine-tuning with OpenAI

這是 OpenAI 在 AI Engineer World’s Fair 2025 的微調 Workshop，內容是介紹 SFT、DPO 和 RFT 三種不同的微調模型方式，分別適合哪種情況，以及需要準備什麼訓練資料。
OpenAI API 目前已經支援三種微調方式，透過後台或 API 即可操作。

投影片有幾張非常棒!(我截圖在我Facebook文章內了) 一目瞭然三種差異，我擷取了幾張一起放上來，以下重點整理:

1. SFT (Supervised Fine-Tuning) 監督式微調

核心概念就是模仿。你給模型看輸入和期望的輸出，它就學著複製你要的樣子。

最適合: 分類、格式化、結構化資料提取，或是模型蒸餾(讓小模型學會特定任務)。特別適合需要嚴格約束模型行為、產出非常具體結果的情境。

2. DPO (Direct Preference Optimization) 直接偏好優化

核心是比較。你給模型看兩個輸出範例，告訴它「我喜歡這個、不喜歡那個」，模型就學著往你喜歡的方向調整。

資料格式: 輸入 + 偏好的輸出 + 不偏好的輸出

學習的不是某個具體範例，而是偏好與不偏好之間的差異。DPO 並非讓模型精確輸出你偏好的答案，而是讓輸出傾向於你喜歡的方向。

最適合: 語氣匹配、風格調整。這些特質很難量化評估，但放在一起比較時很容易看出好壞。特別適合有 A/B 測試資料或使用者偏好資料的場景。

3. RFT (Reinforcement Fine-Tuning) – 強化學習微調

讓模型學習如何推理特定問題。這也是 OpenAI 用來打造推理模型的關鍵技術。

資料格式: 輸入 + 評分器 (grader) + 參考答案(optional)

重點在於評分器可以很多樣化，讓應用更靈活。模型學的是調整自己的「思考鏈」(chain of thought)，以提高解決問題的成功率。

最適合: 可評分的難題，特徵是「難以執行，但易於驗證」，例如: 醫療診斷、法律分析、程式撰寫。也適合訓練 LLM 評審模型。

總結一下:

• 需要精確、受約束的輸出 → 用 SFT
• 想調整語氣風格，有偏好比較資料 → 用 DPO
• 面對複雜難題，需要提升推理能力 → 用 RFT

最後，QA 多次有人問何時適合微調，講者都再三強調 Prompting 優先、RAG 優先，做微調是最後最後還想提升性能的方式。

更多討論在我 Facebook 貼文。

Anthropic 的 Agent Skills 技術解析

看了 Anthropic 最新推出的 Agent Skills 功能，來技術解析一下: 算是個 Code Interpreter 的包裝功能:

1. 先把寫好的 script 先傳到 container 裡面，讓 agent 可以執行
2. 搭配 function calling 做兩階段的 context 揭露

我練習用 OpenAI 的 Code Interpreter 加上 OpenAI Agnets SDK 也做了一個出來，是蠻有意思的用法

基本上 skill 等於 一些預先寫好的 script 程式，搭配完整的操作指示，讓 Code Interpreter 可以直接執行它。另外也做了 Context Enginering 優化。

skill 描述分成 1. 簡單描述直接放 system prompt 讓 agent 挑選 2. 完整操作描述需要用工具進一步揭露。

我寫成一個 Google colab，如果你知道什麼 Code Interpreter 和 Agent，那看這份 colab 你也會做了。

• Anthropic 文章: Equipping agents for the real world with Agent Skills
• 我的 colab 拆解技術原理

更多討論在我 Facebook 貼文。

開源模型生態現況 The State of Open Models

分享一場 Nathan Lambert (AI2) 關於 The State of Open Models 開源模型生態現況的演講重點。

中國開源模型已經超越美國

2024 年初，Llama 還是主流，DeepSeek 和 Qwen 只是「有趣的替代品」。但現在情況完全逆轉了。
從 Hugging Face 的下載數據來看，Qwen 已經超越 Llama 成為最多人使用的開源模型，而且這個趨勢還在持續擴大中。
從 Benchmark 來看也是: 中國開源模型的分數已經領先美國所有開源模型。OpenAI 的 GPT-OSS 是往正確方向的一步，但還不足以扭轉趨勢。

Qwen 的全方位攻勢

Qwen 不只是做文字模型，他們幾乎什麼都做: 文字轉語音、圖片編輯(Studio Ghibli 風格那波)、Agentic Coding、VLM 視覺語言模型等等。
講者表示: 「996 可能還低估了他們的努力」。而且 Alibaba 官方帳號會主動 DM 他，希望他報導新模型。這種社群經營的積極程度，美國沒有任何一家公司在做。

為什麼 Meta 掉隊了?

Zuckerberg 前後的說法差很多。一年前說要 all-in 開源，現在態度已經大不同。
Nathan 認為這是個戰略失誤。Meta 本來可以成為開源世界的霸主，結果把位置讓給了中國。建立開源社群的 mindshare 需要很長時間，一旦失去就很難追回來。

DeepSeek 和 Qwen 其實很不一樣

DeepSeek 是研究導向的頂尖團隊，「老實說，你可以稱他們為非常追求 AGI 的」，目標是前沿的使用案例。Qwen 則是靠 Alibaba 的資源做 full-stack 服務，類似之前 Meta 在做的事情。
這兩種模式都很成功，而且中國還有 Moonshot AI (Kimi)、ZAI (GLM-4.5)、騰訊、字節跳動等等一堆公司在做開源。美團最近也發了一個很強的模型。這個生態系的多樣性讓中國更容易找到 open source 的可行商業模式。

關於安全問題

有人問到用 DeepSeek 或 Qwen 會不會有安全疑慮? Nathan 的觀點是: 如果你沒注意到的話，確實會碰到一些你不喜歡的東西。

他舉例: 問 DeepSeek R1 一個普通問題，它可能會回答「我們始終遵循社會主義核心價值觀和中國共產黨的要求」這類奇怪的宣傳語。「當你說中國模型被審查時，實際上大多只是在你的小新創 app 中出現一些奇怪的無意義宣傳」

至於是否有後門或惡意 code? 他個人認為現在沒有，但這種懷疑是合理的。目前這是無法證明的未知數，「比如 DeepSeek 的工具使用是否設計為編寫有漏洞的程式碼? 沒有任何政府機構能夠真正證明這一點。我非常強烈地感覺到現在沒有真正的後門或危險，但這種動機是合理的。」

所以大公司通常不用中國模型，但 startup 為了創新速度會用。「最終這兩件事會正面衝突，我們不知道會發生什麼。如果有美國和西方替代品會更容易抉擇。但現在的問題是: 新產品的力量會贏，還是安全性會贏?」

講者認為安全問題目前不是最緊迫的，因為開放模型落後前沿模型數月到數年，這提供了一定的緩衝期。

美國該怎麼辦?

Nathan 在推動一個叫 ATOM (American Truly Open Models) 的計畫，希望能獲得更多資源投入開源模型開發。
他認為現在的投資還遠遠不夠。NSF 給了四年一億美金，但他覺得這個數字應該是每年的最低標準。而且目前學術界研究的模型可能跟前沿模型差距太大，有脫節的風險。

美國的優勢在於透明度和學術連結，但在訓練資料使用上受到更多限制。中國公司可以訓練任何最好的資料，而像 AI2 這樣的機構如果要保持透明開放，在性能上就會有劣勢。

開源模型會一直存在

Nathan 強調: 無論美國做不做，開源模型都會存在。訓練模型的人才和資源正在全球擴散。與其被動面對，不如主動領導這個生態系。

更多討論在我 Facebook 貼文。

希望你會喜歡這集內容！

– ihower

在講完 WebConf 之後，我有種莫名的不協調感: 一方面 Vibe Coding 讓大家寫程式變簡單了，人人都可以做 App 了，也很多人講硬技能不重要了。但另一方面，我覺得開發 AI Agent 產品仍是非常有技術挑戰性的，需要的知識技能深度廣度一點都不少。

最近也看到了幾篇關於 AI Agent 開發的文章，發現國外技術社群在 2025 Q4 也有類似的體悟: Agent 產品開發設計還是很難。

不是「寫程式很難」那種難，而是「95% 的 AI Agent 產品，進到正式環境會失敗」這種難。問題不在模型不夠聰明，而在於周邊的工程架構: context 管理、memoy 設計、錯誤處理、agent prompt 最佳化、語意檢索、評估回饋機制等等，很多都是全新領域，且戰且走的情況。模型只能用幾個月就要升級更換，幾個月前的 best practice 也可能會被推翻重新思考。

總之，以下我整理年底四篇我覺得關於 Agent 開發氛圍的不錯文章:

實戰踩坑: Flask 作者的 Agent 開發心得

Agent Design Is Still Hard

Armin Ronacher (Flask 框架作者) 分享了他開發 Agent 的經驗，幾個實戰觀察:

關於 SDK 選擇: 他們原本用 Vercel AI SDK，現在不會再這樣選了。各模型差異太大，用 Anthropic 或 OpenAI 原生 SDK 反而更好控制。高階抽象聽起來很美好，但最終還是得自己建立 agent 的抽象層。

關於快取管理(Prompt Caching): Anthropic 要求顯式管理快取點，一開始覺得很蠢，為什麼平台不自動處理? 但後來完全改觀，顯式管理讓成本和快取利用率更可預測，還能做到 context 編輯和對話分支這些進階操作。

關於 Reinforcement (增強回饋): 每次 Agent 執行完工具後，不只是回傳資料，還可以塞更多資訊進去: 提醒整體目標、任務狀態、失敗時給提示。這個「增強」機制比想像中更重要。

關於錯誤處理: 如果預期會有很多失敗，可以用子 agent 跑到成功為止，只回報成功結果。但讓 agent 知道「什麼方法沒用」也很重要，能幫助下一步避開同樣的坑。

關於共享狀態: 多數 agent 需要一個共同存放資料的地方。他們選擇用虛擬檔案系統，這樣不同工具和子 agent 都能存取同一份資料，避免資料孤島。

關於測試: Testing 和 Evals 是最難的部分，目前還沒找到滿意的方案。Agent 的特性讓傳統測試方法都不太適用。

他最後補了一段我很喜歡: 「如果你根本不需要 MCP 呢?」很多 MCP server 過度設計，塞了一堆工具吃掉大量 context，其實用簡單的 CLI 工具透過 Bash 執行就好。

為什麼 95% 的 Agent 在 Production 失敗?

What Makes 5% of AI Agents Actually Work in Production?

這篇來自一場舊金山活動的座談筆記，有句話很中肯: 「大多數創辦人以為自己在做 AI 產品，其實是在做 context selection 上下文選擇系統。」

Context Engineering 不等於 Prompt 技巧: RAG 做得好其實就夠用，不太需要 fine-tuning。但多數 RAG 系統太天真 – 索引太多會讓模型混亂，索引太少又缺乏訊號。進階的 context 工程更像是「給 LLM 做特徵工程」: 選擇性裁剪、驗證、可觀測性都是功夫。

Text-to-SQL 的殘酷現實: 主持人問「有多少人把 text-to-SQL 做到正式環境?」結果沒人舉手。不是這問題太小眾，而是查詢理解真的超難 – 自然語言有歧義，商業術語是領域專屬的，LLM 不知道你公司定義的「營收」或「活躍用戶」是什麼意思。成功的團隊會建立商業詞彙表、查詢模板、驗證層和回饋迴圈。

信任問題是人的問題，不是技術問題: 有位講者說他老婆不讓他用 Tesla 自動駕駛，不是因為它不行，而是她不信任。企業 AI 也一樣。那成功的 5% agent 有什麼共同點? 都有人機協作設計，讓 AI 當助手而不是自主決策者，並且建立回饋迴圈讓系統從修正中學習。

記憶不只是儲存，是架構決策: 大家都想「加記憶功能」，但記憶是設計決策，要區分用戶層級、團隊層級、組織層級。而且什麼時候「個人化」會變成「侵犯隱私」? 有講者說 ChatGPT 推薦家庭電影時直接叫出他小孩的名字，他的反應是: 「別碰我的隱私。」這中間的平衡很微妙。

多模型調度: 正式環境不會所有東西都丟給最強最貴模型。團隊會根據任務複雜度、延遲要求、成本敏感度來做模型路由: 簡單問題用小快模型，複雜推理才用頂級模型。而且哪個查詢適合哪個模型，這個選擇本身也可以隨時間學習優化。

Agent 能力的金字塔層級

RL Environments and the Hierarchy of Agentic Capabilities

Surge AI 把 9 個頂級模型丟進模擬職場環境，給 150 個客服任務。結果? 即使是 GPT-5 和 Claude Sonnet 4.5 也有超過 40% 的任務失敗。

他們從失敗模式中歸納出「Agent 能力層級」金字塔:

第一層: 基本工具使用與規劃: 能把多步驟任務拆解成小目標、辨識該用哪個工具和順序、正確把資訊對應到工具參數、一步步執行不會跑掉。GPT-4o、Mistral Medium、Nova 1 Pro 卡在這層，連基本的工具呼叫都會出錯，例如把 “gold” 當成客戶 ID 傳進去。

第二層: 適應力: 計畫碰到現實就崩潰怎麼辦? Gemini 2.5 和 Qwen3 常執行正確的工具呼叫順序，但遇到問題不會調整。例如搜尋 “Vortex Labs” 沒結果 (系統存的是 “VortexLabs” 沒空格)，它們就直接回報找不到，而不是試其他搜尋方式。相比之下，Claude Sonnet 4.5 會主動嘗試不同的搜尋參數，這正是人類會做的事。

第三層: 接地能力: 保持在當前脈絡中，不要亂編 ID、不要瞎掰事實。Kimi K2 會搞錯年份，系統提示明明說 2025 年，它搜尋時卻用 2024。Claude Sonnet 4.5 有時也會編造 email 地址，雖然它能自我修正，但這種脫離現實的傾向令人擔憂。

第四層: 常識推理: 這是分隔 GPT-5 和人類水準的關鍵。客戶說「包裹幾小時前到了」要求退款，這明顯是退貨不是取消訂單 (因為已經收到商品了)，但 GPT-5 沒推理出來。另一個例子是找「遊戲玩家」客戶，合理做法是先找遊戲相關產品類別再搜尋訂單，但 GPT-5 卻笨拙地逐日搜尋整個月的訂單。

結論: 2025 年不是「我們已經實現強大通用 agent」的一年，而是「agent 終於能夠穩定行動，我們可以開始討論分析它們的常識推理能力」的一年。

解方: Agent 應該更有主見

Agents Should Be More Opinionated

面對這些挑戰，有一個產品開發方向我很認同: 最好的 agent 產品不是最有彈性的，而是最有主見 (Opinionated) 的。

彈性陷阱: 什麼用戶會興奮地自己調整模型溫度和分塊策略? 沒有。以為用戶想要選擇，其實他們想要結果。Steve Jobs 和 iPhone 就是最好的例子: 一個按鈕、一個螢幕，但功能沒有任何限制，魔法在於產品從少數互動點就能可靠運作。

替用戶做大量前置工作:

• 測試每個模型，所以用戶不用測 (不要相信 benchmark，要在你的真實場景測試)
• 寫詳細的 prompt 告訴 agent 成功長什麼樣、怎麼達成
• 每個必填的用戶選項，都代表你沒替用戶做好決定

模型在框架裡是不可替換的: 你沒辦法脫離框架來評估模型。模型智力是「尖刺狀」的，當你設計框架時，你隱含地在繞過模型的強項和弱項設計。所以「升級」到新模型常常會打壞現有框架。唯一重要的問題是: 這個框架 + 模型組合，在我的任務上成功嗎?

從深且窄開始: 寬泛的 agent 想處理太多種任務，demo 很厲害但正式環境很慘，因為每多一個功能就多一堆 bug 和邊界情況。淺薄的 agent 又不夠複雜，根本不該是 agent。甜蜜點是夠窄可以徹底優化，又夠深讓複雜度值得投資。先找出那 10% 能產生最大價值的任務來做 agent，忽略其他的。

連 Anthropic 都在變得更有主見: 他們有專門的生命科學和金融團隊，不是為了做專門的基礎模型，而是在深耕問題領域、優化 agent 框架 (prompts、工具、context、sub-agent)。Claude Code 和 Codex 這些產品也都有內建的工具和 context 管理，而不是給你一堆選項。

—

以上四篇文章分享，算是 2025 歲末 AI Agent 開發的現況。使用 Claude Code、Codex、Cursor 這些 Coding Agent 來寫 code 確實很爽，但別忘了這些是目前最強的 AI 公司傾力打造的產品，而要我們自己要開發 Agent 的時候，挑戰才正要開始。

 這裡下載PDF(32mb)

如果你還沒有訂閱我的電子報，歡迎訂閱  愛好 AI Engineer 電子報。

議程介紹:

AI Agent 正逐漸成為 Web 應用產品中的關鍵功能，從工作流程到 AI 智慧助理，開發者開始讓 Agent 融入 Web 應用的系統架構。

延續去年「淺談 AI Agents 應用開發」的基礎，今年我們從實戰角度出發，介紹如何在 Web 環境下開發、部署與最佳化 AI Agent 系統。本次分享將以 Python FastAPI + OpenAI Agents SDK + 前後端分離架構為例，展示如何讓 Agent 流暢地進行串流輸出，以 TTFT (Time To First Token) 與 Prompt Caching 優先的系統架構。同時也探討前端的 Agent UI 設計、可觀測性、Agent 評估、上下文工程(Context Engineering) 等實務技巧。多方面探討如何在 Web 環境上打造 AI Agent 系統。

(整理分享一些關於 Spec-Driven Development (SDD) 的看法和內容)

Spec-Driven Development (SDD) 是什麼? 簡單說講就是在用 AI 寫程式之前，先讓 LLM 生成一大堆規格文件: 產品需求 → 技術設計 → 任務清單，然後才交給 coding agent 執行。目前有幾個工具在推這套流程: GitHub 的 Spec-Kit、AWS 的 Kiro、還有 Tessl。

社群討論其實非常兩極。正面看法認為遠比 vibe coding 可靠、適合要上線維護的真實專案、開發速度中期來看其實更快。負面看法則認為這就是 Waterfall 2.0、過度工程化、扼殺創造力。

第一篇: Spec-Driven Development: The Waterfall Strikes Back

作者 François Zaninotto 認為 SDD 試圖解決一個錯誤的問題:「如何把開發者從軟體開發中移除」。他列出實際使用的痛點:

• 脈絡盲區: SDD agent 跟 coding agent 一樣透過文字搜尋來理解脈絡，常常漏掉需要更新的既有功能
• Markdown 地獄: 產出太多文字，開發者花大部分時間在讀冗長的文件，從看似專業的文字海中找出基本錯誤
• 雙倍 Code Review: 技術規格裡已經有程式碼，要先審查規格再審查實作，審查時間直接翻倍
• 虛假的安全感: Agent 不一定照規格走，他看到 agent 把「驗證實作」標記完成，卻只寫了手動測試說明而非單元測試
• 邊際效益遞減: 專案越大，規格越容易失準，對大型既有程式碼庫幾乎無法使用

他主張用自然語言小步迭代，像 Lean Startup 那樣識別風險假設、設計最小實驗、快速驗證，這才是 coding agent 的正確用法。

第二篇: Spec Driven Development – revenge of Waterfall or BDD taken to new level?

BDD 大師 Gojko Adzic 的觀察是:

• 規格太高層次: 產出的驗收條件用 Given-When-Then 格式，需求用 must/should/could 分級，但都太抽象，比較像工作範圍而非真正的規格
• 文件是給工具用的: 過程中產生大量文字，大部分是讓工具追蹤自己進度用的，不是給人讀的，他們最後都只是快速掃過或直接跳過
• 缺少範圍定義階段: 沒有明確的 scoping 步驟，導致工具想做太多事然後失控，產出大量測試和程式碼，human in the loop 變得不可行
• 所謂可執行規格其實是測試: 真正的規格最後都變成單元測試和整合測試，只有開發者看得懂

結論: 有潛力值得關注，但目前離可執行規格的承諾還很遠，需要更明確的範圍定義階段來促進迭代交付。

第三篇: Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl

Thoughtworks 的 Birgitta Böckeler 發表在 Martin Fowler blog 上，他花大量時間評測三個工具，她把 SDD 分成三個層次:

• Spec-first: 先寫好規格，用於當下的開發任務
• Spec-anchored: 任務完成後規格保留下來，持續用於功能的演進和維護
• Spec-as-source: 規格成為主要的原始檔，人類只編輯規格、不碰程式碼

理想上第 2 和第 3 層才是 SDD 的終極願景，但她發現目前的工具大多只停在第 1 層。

他的觀察:

• 一套流程打天下? 她用 Kiro 修一個小 bug，結果被拆成 4 個 user story、16 條驗收條件，完全是殺雞用牛刀
• 寧願審查程式碼: Spec-kit 產出大量重複冗長的 Markdown，與其讀這些文件不如直接看程式碼
• 虛假的控制感: 即使有模板和檢查清單，agent 還是經常忽略指示或執行過頭。例如研究步驟收集了既有類別的資訊，結果 agent 當成新規格重新生成一遍，產生重複程式碼
• 讓人想起 MDD: Model-Driven Development 當年也想用規格生成程式碼，最後沒成功。LLM 解決了一些限制，但也帶來非確定性的新問題

她用了一個德文詞 Verschlimmbesserung: 在試圖改善的過程中反而把事情搞得更糟。

其他看法

宝玉(AI大V) 說: 我个人是不喜欢用 spec-kit，不是好的上下文工程： 小项目没必要、大项目描述不清楚、一大坨文档反而占用上下文影响生成、文档不保持及时更新反而会误导 Agent [4]

swyx (AI Engineer Summit 大會主辦人) 給了一個簡短的 tweet: Spec Driven Development is Wishful Thinking「SDD 只是一廂情願」 [5]

SDD 小結

SDD 的終極願景很美好: 人類只維護規格、AI 負責生成程式碼，規格成為長期維護的 source of truth。
但現實是殘酷的，目前這些工具大多只停在 Spec-first 的層次，規格寫完用完就丟，跟傳統的需求文件沒什麼兩樣，只是多了一堆 Markdown 要讀。

過去敏捷開發已經證明，緊密協作比詳盡文件更有效。現在 coding agent 讓我們可以直接用自然語言描述需求、即時看到結果，為什麼要走回頭路去寫一堆規格文件?

SDD 的初衷是想讓 AI 更受控，但用更多文件換來更多負擔的同時，卻可能沒有換到相應的品質保證。

第四篇: Vibe Engineering (Simon Willison)

如果不用 SDD，那該怎麼做? Simon Willison 這篇 Vibe Engineering 是我最認可的工程師 AI Coding 方式: 與其想要全靠文件控制 AI，不如強化既有的工程實踐（測試、版本控制、code review），讓 AI 放大開發者的專業能力。

相較於 SDD 想用規格文件流程來馴服 AI，Simon Willison 大大(Python Django 共同發明者) 提出了另一種以開發者專業為本的方向:「Vibe Engineering」，這不是隨便亂寫的 vibe coding，而是資深工程師運用 LLM 加速工作，同時對產出的軟體品質負責。

Vibe Engineering 跟 SDD 有什麼不同? 兩者都有要先做計畫，但形式差很多:

• 文件份量: SDD 產出大量結構化 Markdown（requirements.md → design.md → tasks.md），Vibe Engineering 的計畫比較輕量，強調可以快速迭代
• 流程僵固度: SDD 有固定的多階段流程，Vibe Engineering 更強調靈活組合各種工程實踐
• 核心理念: SDD 想用規格文件來「控制」AI，Vibe Engineering 認為應該靠工程師的判斷力和既有的工程實踐來確保品質
• 責任歸屬: SDD 傾向讓流程和文件來保證品質，Vibe Engineering 明確說工程師要對產出的軟體「proudly and confidently accountable」

Simon 指出 LLM 會獎勵既有的頂級軟體工程實踐:

• 自動化測試: 有完整測試套件的專案，coding agent 可以放心跑；沒測試的話 agent 可能宣稱完成但根本沒驗證
• 事前規劃: 先有高層次計畫再交給 agent，而且可以先迭代計畫本身
• 完善文件: 好的文件讓模型能直接使用 API 而不用先讀完所有程式碼
• 良好的版本控制習慣: LLM 很擅長 Git，能自己翻歷史追 bug，善用 git bisect
• 有效的自動化流程: CI/CD、自動格式化、linting，agent 也能受益
• Code Review 文化: 擅長審查程式碼的人，跟 LLM 協作會順暢很多
• 手動 QA 能力: 除了自動測試，還要能預測和挖掘邊緣案例

簡單說，AI 工具會放大既有的專業能力，軟體工程技能越強，從 LLM 得到的結果就越好越快。

後續推薦

2025/12/20 updated:

陳宜昌(YC) 有一場演講分享批判 SDD 也很不錯: 你真的需要框架嗎？極簡流 AI Coding 可能更適合開發者，提出基於第一性原理的七大核心原則，展示如何與 AI 高效協作。

為什麼選這台?

能在本地自家跑 LLM 大模型，應該是 AI 工程師的夢想之一。

太小的模型不夠實用，因此一直有在關心能跑的動 70B 的機器。在 2025 年中研究了一下個人用的 AI 工作站電腦，在「128 GB RAM + 2TB SSD」的條件下來選，最後得出三個選項:

• 性價比冠軍: AMD Ryzen AI Max+395: 價格才 USD 2k; 記憶體頻寬 273 GB/s; x86 + Windows; 70B 模型推論 + 玩遊戲都 OK
• 生態優勢: NVIDIA DGX Spark: 要 USD 4k; 記憶體頻寬也是只有 273 GB/s; ARM + CUDA，適合模型訓練/微調，若只跑推論感覺 C/P 值不如 AMD 啊
• 頻寬極速: Mac Studio M4 Max: 最貴 USD 4.5k; 546 GB/s 跑推論最快; macOS 生態

本地要跑 LLM，關鍵就是 GPU RAM 要夠，而且記憶體頻寬速度要夠快。

Mac Studio 是很多人推薦的選擇，但是我覺得組 128GB + 2T 硬碟的話，價格太貴了(六位數台幣約14W)。而且我已經有一台 MacBook Pro 了。

另一個選擇是 2025 年初發表的 NVIDIA DGX Spark，我對這台也很感興趣，後來發現這台有幾個問題:

1. 這台是 ARM 機器是跑 Linux，定位就是機器學習工作站，拿來在 Nvidia CUDA 體系下做機器學習訓練
2. 記憶體頻寬只有 273GB/s，跑推論應該會比 Mac Studio 慢，沒優勢
3. 價格也不便宜，要台幣6位數，而且其實網上你還買不到

我自己的需求主要是模型 Inference 推論，買 NVIDIA DGX Spark 這台感覺有點浪費，又不是主力在做模型訓練微調，ARM 機器加上 Linux 環境，多功能用途比較受限。後來看到 AMD 的 Ryzen AI Max+395 跑推論好像也很猛，就去找有哪幾家有組裝，找到三家可買: Framework Desktop, GMKtec EVO-X2, Bosgame M5 AI (threads 上有人整理有哪幾家)

筆電形式就不考慮了，我已經有 MBP，而且這台也會當作 Server 一直開機，散熱和風扇噪音也要考慮一下，因此覺得小台的桌機更好發揮這台的效益。

這幾家裡面，Framework 這家公司因為 DHH 一直在推薦，所以很有印象。他後來也有寫一篇 The Framework Desktop is a beast 。基本上就是一樣的錢，現在你買 AMD 可以獲得比 Mac 更好的性能。

訂購過程

• 2025/6 月初 官網預訂 (Batch 11)，五位數台幣，會先刷一個 3000 台幣訂金
• 2025/9/23 收到準備出貨通知，隔天會刷尾款
• 2025/9/26 順豐到貨

雖然 Framework 是美國公司，但組裝代工是台灣仁寶，因此是從台灣寄出的。他的台灣分公司 美商豐沃電腦股份有限公司台灣分公司 還會開電子發票給你。豐沃果然就是 Framework 麻。

為什麼用 Windows?

後來我改用 Ubuntu 了，後述

這台這麼猛，我是希望不只當作 Server，也可以當作日常多功能用途，有很多 GUI app 畢竟是沒有 Linux 版本。加上 DHH 推薦 VSCode + WSL makes Windows awesome for web development 也很棒，拿來開發環境也可以。

初步使用 WSL 的體驗還不錯，Terminal 打開就是一個真的 Ubuntu Linux 系統，就如 DHH 所說，用 Docker 的話 x86 硬體其實比 Mac 更有優勢。而且有些 app 整合的蠻好的，例如 VSCode 和 Docker，都是安裝 windows 版後，也可以順利無縫在 WSL 內的 Linux 用 CLI 操作。不過我同時也感覺是有複雜性的，畢竟這是 Windows + 子系統 Linux 的架構，例如如何從外部連進子系統 Linux 內，需要額外設定 Port Forwarding。

另外，相比 Linux 跟 Mac 的最大的優勢，就是這台還可以打 PC 遊戲，立刻就把世紀帝國2又裝起來複習一下，各種 3A 大作想必也沒有問題。

實際用了一天，覺得還不錯，雖然 UI 方面還是不如我用了18年的 Mac 順手啦。

安裝過程

這台需要 DIY，這是初始狀態，你需要自己裝 SSD 硬碟、CPU 風扇、前蓋板裝飾、USB 轉接擴充 (都在官網一起買)，以及自己安裝作業系統。注意，AMD Ryzen AI Max+395 的 RAM 是不能換的，建議一開始就選最大 128GB 吧。

參考以下官方指南進行安裝。

• Framework Desktop (AMD Ryzen AI Max 300 Series) DIY Edition Quick Start Guide
• Windows 11 Installation on the Framework Desktop (AMD Ryzen AI Max 300 Series) 你需要準備一個 USB 開機碟

注意: 這照片中風扇我裝反了，後來又拆開重裝一次: 風扇要朝散熱片吹，而不是向外吹。

風扇跟散熱片的螺絲孔位也有點沒對齊，我是先不裝那個黑色的導流框，先用四個螺絲鎖並往下壓好之後，再裝導流框。

跑 gpt-oss-120b 速度

好，回到當時買這台的初心，跑 LLM 大模型。下定的時候 OpenAI gpt-oss 還沒有出，但現在是我最有興趣的開源模型。

這篇必參考: How To Run OpenAI’s GPT-OSS 20B and 120B Models on AMD Ryzen AI Processors and Radeon Graphics Cards

請務必按照 AMD 文章的說明: 需要安裝 AMD Software 設定顯卡 VGM 到 96G，以及 LM Studio 設定 GPU Offload 開最大。如此 Framework Desktop (AMD AI Max+395 128g) 的實測速度是:

• gpt-oss-20b (GGUF) 超快，可以跑到 60 tok/sec
• gpt-oss-120b 速度則是 30 tok/sec 也很快!!

Context Length 方面，gpt-oss 模型的上限是 131k。但我這個家用硬體，當然是沒辦法開到滿。目前測試到 12k 是沒問題的，需要再進一步研究設定 (還沒開 Flash Attention)。

作為對比，相比我筆電 MacBook Pro M2 Pro (32g)

• gpt-oss-20b (MLX) 也是可以跑 50 tok/sec
• gpt-oss-120b 跑不起來，ram 不夠 

我也嘗試了其他模型例如 Gemma 3 和 Mistral Small 等，但速度都沒有 gpt-oss 來得快，只有 15tok/sec 左右。而 Qwen3 30B 在 LM Studio 裝好就可以跑到 70 tok/sec 超快。要弄好模型 Inference 又是一門大學問了，很多設定在這邊。

以上，有更多經驗再分享。

整理成一個表

AMD RYZEN AI MAX+ 395 w/ Radeon 8060S
RAM 32 GB + VRAM 96 GB
LMStudio 0.3.27 on Windows 11
Vulkan accelerated llama.cpp engine

結論: 模型大小影響你是否可以載入、以及載入時間。但是實際執行速度跟 active 參數量相關。

更多關於 OpenAI gpt-oss 的資料，我整理在這裡。

補充

Framework 有個 Using a Framework Desktop for local AI 文件不錯:

推薦新手用 LM Studio 入門，把 llama.cpp 包裝成友善的 GUI。目前在 Fedora 42 上跑推理比 Windows 11 快約 20%。

模型選擇策略: 想跑更大的模型又保持速度? 推薦 MoE 架構的模型，例如 Qwen3 30B A3B 和 Llama 4 Scout。MoE 的特色是總參數多但 active 參數少，所以速度快。

更多 AMD Strix Halo 相關資料:

• github.com/lhl/strix-halo-testing/tree/main/llm-bench
• github.com/kyuz0/amd-strix-halo-toolboxes

後續: 改用 Ubuntu Desktop 25.10

用了一週在 Windows 上開發環境還是不順手，想從 WSL 裡面 ubuntu 跑 code，搭配 Windows 上的 Cursor 裡面跑 Claude Code，然後就 gg 了，Claude Code 抓不到 IDE 我在看什麼。另外，我又看到 安德魯的這篇 用 WSL + VSCode 重新打造 Linux 開發環境 文章好長嚇到吃手手。

於是又重裝了 2025/10/9 最新推出的 Ubuntu 25.10 版本，查了一下這種 AMD APU 新硬體，裝最新的 Linux 版本比較沒有問題。結果蠻順利的，也不需要額外安裝任何驅動，安裝 LM Studio 也順利裝起來可以跑 gpt-oss-120b 沒問題，而且原先有幾個 Embedding 模型在 Windows 不能跑(我還以為是 LM Studio 的支援問題)，換成 Ubuntu 之後就沒問題了。

後續都沒關機跑了好幾天很穩，也不像 Windows 11 在待機時莫名重開機好幾次，看系統 log 就是 Kernel-Power 事件 41 非正常關機，也找不出什麼原因(有嘗試調整休眠等設定沒用，推測是 driver 問題)。

後續: 與 Nvidia DGX Spark 評測比較

有人用 Framework Desktop 做了 AMD Ryzen AI MAX+ 395 “Strix Halo” 的 Llama.cpp Benchmark，

我拿來跟價差貴了約一倍的 Nvidia DGX Spark 比較一下:

prefill 階段(輸入):

• gpt-oss-120b: 1689 tps (Nvidia)
• gpt-oss-120b: 788 tps (AMD)
• gpt-oss-20b: 3610 tps (Nvidia)
• gpt-oss-20b: 1908 tps (AMD)

decode 階段(輸出):

• gpt-oss-120b: 53 tps (Nvidia)
• gpt-oss-120b: 50 tps (AMD)
• gpt-oss-20b: 80 tps (Nvidia)
• gpt-oss-20b: 73 tps (AMD)

prefill 階段主要是密集矩陣乘法，憑藉更高的算力，Nvidia 明顯領先。但是 decode 階段則受限於記憶體頻寬，兩者表現就差不多了。實際應用中(注意硬體都只有 128G ram，因此也做不了 long-context 的需求，實際只能跑幾萬tokens吧)，decode 階段才是主要瓶頸，因此兩者實際體感可能差不多快。

數據來源:

• AMD kyuz0.github.io/amd-strix-halo-toolboxes
• Nvidia github.com/ggml-org/llama.cpp/discussions/16578

歡迎訂閱  愛好 AI Engineer 電子報 過往期數點這 

Hello! 各位 AI 開發者大家好

變成月刊了，這期內容繼續深入探討 AI 工程的核心: 評估、Context Engineering、Agent 和 RAG。

AI Evals 大辯論: 從 Claude Code 訪談引發的反思

你知道嗎? Claude Code 沒有做產品層級的系統化 Evals，是靠 Vibe 感覺開發的!
這場辯論始於 Anthropic Claude Code 創始人 Boris 在訪談中的坦白…

全文在我部落格，更多討論在我 Facebook 貼文。

官方 MCP Registry 發布

近期看到 MCP 官方出了一個 Registry，GitHub 也出了一個 Registry，這是在打架嗎？
不是的，讓我解釋一下 MCP Registry 的架構…

全文在我部落格，更多討論在我 Facebook 貼文。

Writing effective tools for agents — with agents

Anthropic 分享了他們如何最佳化 AI Agent 工具的實戰經驗，先快速做個原型，然後建立評估系統來測量工具效能。

工具設計的原則則包括:

• 少即是多: 不是工具越多越好。與其包裝現成 API endpoint 成為工具，不如設計幾個精心整合的高階工具。例如不要分開做 list_users、list_events、create_event，直接做一個 schedule_event 搞定所有事
• 命名空間很重要: 當工具變多時，清楚的命名規則能幫 Agent 選對工具。像 asana_search vs jira_search 這樣的前綴命名，效果比你想像的大
• 返回有意義的資訊: Agent 處理自然語言比處理低階的技術 id 更在行，使用這種人類也能看懂的格式，能大幅減少幻覺
• Token 效率最佳化: 實作分頁、過濾、截斷等機制，給工具加上 response_format 參數，讓 Agent 選擇要 “concise” 還是 “detailed” 的回應
• 錯誤訊息要有幫助: 與其丟出 “Error 404″，不如告訴 Agent: “找不到該用戶，請檢查拼寫或使用 search_user 工具先搜尋”
• 工具描述: 這個也需要用 Prompt Engineering 進行最佳化

另外還有一個重點是他們是如何最佳化 prompt 的? 他們分享了他們的 tool evaluation cookbook 評估程式碼。先準備 dataset，然後用這個 eval 去批次跑。這會評估你的工具描述，並給出摘要和回饋，你再依此回饋去改進你的工具。

進階 context engineering：KV cache centric LLM 應用設計

看到超深入的 KV cache 最佳化文章，作者從 Manus 團隊的 Context Engineering 文章出發，深入探討如何用 KV cache centric 的思維來設計 LLM 應用，不只能大幅節省成本，也能提升用戶體驗。

Cost Control: Scaling AI Without Going Broke

AI 成本控制的實戰指南。過去軟體的運算成本可忽略，但 GenAI 時代完全翻轉：模型是依 token 計費，隨著使用量增長，成本可能爆炸性增加。

文章提出的成本最佳化流程: 先證明價值和品質 → 固定功能和品質基準 → 再開始最佳化成本。而不是過早優化成本，結果功能還沒做好就先把自己搞死了。

八種降低成本的策略：

• 模型選擇(2-10倍省): 開發時用最強的模型快速驗證可行性，上線前系統性測試更小更便宜的模型。很多場景其實不需要最強模型
• Prompt 工程 (1.5-4倍省): 刪除冗餘指令、壓縮背景資料
• 精準檢索 (2-6倍省): RAG 系統常見的錯誤是塞太多不相關的內容給 LLM。調整相似度門檻、只給必要的資訊
• 工作流分解 (1.5-5倍省): 別用一個超大 prompt 做所有事，拆成 workflow: 簡單任務用便宜模型，複雜推理才用貴的，中間結果考慮快取
• Pre-processing 預處理 (3-20倍省): 事先跑好 Embedding、摘要等先存起來，不要每次請求都重算
• Batching 批次處理 (2倍省): OpenAI 等各家現在都有 Batch API 有 50% 折扣，適合非即時的大量處理
• Context 快取 (1.2-2倍省): 利用 LLM 供應商的 prompt caching 功能，重複的 prefix prompt 價格只有原先一成
• 商業策略 (最高 50% 省): 去找 LLM 供應商談承諾用量，可以有折扣，或是月花費超過 1-2 萬美金時考慮自己跑開源模型

Defeating Nondeterminism in LLM Inference

OpenAI 前 CTO Mira Murati 在新創 Thinking Machines 發表的首篇文章，探討 LLM 推論中的非確定性問題：為什麼溫度設 0，結果仍然不同?

簡單說，就是 LLM inference server 中，是採用 Batch 和其他平行請求一起推論的，而不同 Batching 形狀就會有不同結果，另一個原因是浮點數相加時，不同順序會有不同結果。

在 OpenAI 文件中，有提到如何做 Reproducible outputs 可重現的輸出。

不過呢，我現在認為對 AI 應用工程師不太重要了。一來新的推理模型也不允許我們設定溫度參數了，所以橫豎都有不確定性，二來如果你真的想要，那你可以實作 HTTP 層的快取：你就把整個 HTTP request/response 都記錄下來，只要碰到一樣的 request 參數，就重播之前的 response 即可，根本不需要再去問模型。

Why language models hallucinate

OpenAI 發表了一篇研究，解釋了 LLM 為什麼會如此自信地產生錯誤答案。他們認為和模型訓練時的評估方式有關。

現在的評估方法用了錯誤的誘因。就像選擇題考試，亂猜可能幸運得分，但留空一定零分。當模型只根據「準確率」評分時，等於鼓勵它猜測而不是誠實說「我不知道」。
解決方案就是: 答錯要扣更多分，適當表達不確定時給部分分數。就像有些考試答錯會倒扣，留空不答反而能得部分分數。目的就是訓練 AI 要學會說「我不知道」，而不只是學會更多知識。

Galileo 的這篇 Understanding Why Language Models Hallucinate? 可以作為更好的補充入門閱讀。

How to Detect Hallucinations in Retrieval Augmented Systems: A Primer

看了上述資料，大家可能會以為模型幻覺常發生，這篇文章區分了兩種幻覺：

1. 內在性(Intrinsic): 沒給任何 context，模型就瞎掰
2. 外在性(Extrinsic): 明明提供了正確的 context 參考資料，模型還是講錯

這篇文章指出，在 production 環境中，後者才是我們工程師最常碰到的問題，而且你不需要 ground truth 資料集就能偵測到!

偵測方式其實很簡單，兩步驟:

1. 檢索是否正確? 檢索回來的文件有包含回答問題所需的資訊嗎?
2. 生成是否正確? 生成的答案有沒有「超出」檢索文件的內容?

如果檢索正確但生成不正確，就抓到幻覺了。模型憑空捏造了 context 裡沒有的內容。
這個方法不需要知道「正確答案」是什麼，只要比對生成內容是否超出檢索文件的範圍就好。這讓幻覺偵測變得實際可行，不用人工標註或完整的 ground truth 資料集。

加映這篇文章的演講版本: How You Catch Production Hallucinations in Real Time

37 Things I Learned About Information Retrieval in Two Years at a Vector Database Company

向量資料庫 Weaviate 的工程師 Leonie Monigatti，分享了兩年來學到的 37 件資訊檢索心得。
我挑幾個重點分享:

1. BM25 仍是強力基準: 別急著跳到向量搜尋，先從簡單的 BM25 關鍵字搜尋開始做
   編按: 因為太多人沒用過全文搜尋引擎，就直接拿套 Naive RAG 方案來用，不會 tune 的話結果不一定比較好
2. 向量資料庫的主要應用不是生成式 AI，而是搜尋: 但為 LLM 找相關上下文本質上就是「搜尋」，所以向量資料庫和 LLM 才會像餅乾配牛奶一樣合拍
3. 去哪找好的 Embedding 模型: MTEB (Massive Text Embedding Benchmark) 是首選，涵蓋分類、聚類、檢索等任務。專注資訊檢索看 BEIR，多語言看 MMTEB
   編按: 繁體中文請找看我的評測: 使用繁體中文評測各家 Embedding 模型的檢索能力
4. 萬物皆可 Embed: 不只文字，圖片、PDF（像 ColPali）、圖譜都能嵌入。這表示你可以對多模態資料做向量搜尋
   編按: 例如 Cohere Embed 4 模型
5. 向量維度的經濟學: 選 1536 維度 vs 768 維度，儲存成本直接翻倍。做個簡單的 “chat with your docs” 真的需要 1536 維嗎？有些模型用 Matryoshka 技術可以動態縮短向量
   編按: 我也有寫過一篇文章: 俄羅斯套娃(Matryoshka)嵌入模型簡介
6. 相似不等於相關: 「如何修理水龍頭」和「哪裡買廚房水龍頭」在向量空間可能很相似，但對使用者來說根本不相關
7. Cosine 的 similarity 和 distance 算法: 相似度 1 表示完全相同，距離就是 0。用正規化向量時，cosine similarity 和 dot product 數學上相同，但用 dot product 計算更有效率
   編按: 通常 Embedding API 回傳的向量已經正規化，例如 OpenAI
8. RAG 的 R 不是指向量搜尋: 是 Retrieval (檢索)，檢索可以用很多方式實現
9. 向量搜尋只是工具箱裡的一個工具: 還有關鍵字搜尋、過濾、重排序。要做出好東西，需要組合不同工具
10. 何時用關鍵字 vs 向量搜尋: 需要語意同義詞匹配（粉彩色 vs 淺粉紅）用向量；需要精確關鍵字（A字裙、荷葉邊洋裝）用關鍵字；兩者都要就用 Hybrid Search
11. 過濾(filter)不一定讓向量搜尋更快: 直覺上過濾減少候選數應該更快，但實際上 pre-filtering 可能破壞 HNSW 的圖連通性，post-filtering 可能讓你沒結果。各家向量資料庫有不同且複雜的技術來應對這個挑戰。
    編按: 例如 pg_vector 0.8.0 搞了一個 Iterative Index Scan 功能來避免 overfiltering 沒結果
12. 二階段檢索不只用在推薦系統: 第一階段用簡單檢索（如向量搜尋）減少候選，第二階段用更精確但計算密集的重排序。RAG pipeline 也能這樣做。向量搜尋是從整個資料庫返回一小部分結果，重排序是對已有列表重新排序。
    編按: 繁體中文請找看我的評測: 使用繁體中文評測各家 Reranker 模型的重排能力
13. RAG 從第一個長上下文 LLM 出現就一直在 “死掉”: 每次有更長 context window 的模型，就有人說 RAG 死了。但它從來沒死過…
    編按: 我覺得就像記憶體與硬碟，記憶體就算很大，你還是需要硬碟空間，因為兩者成本差距太大。當需要檢索的文件成千上萬，全部塞到 context 不現實。
14. 向量搜尋其實對錯字不友好: 訓練資料不可能包含所有可能的拼寫錯誤，向量搜尋處理錯字能力有限
15. 選對評估指標: 學術基準測試很常用 NDCG@k，但簡單的 precision 和 recall 很多時候就夠用。如果排序重要，要用 MRR@k、MAP@k 或 NDCG@k 這些考慮順序的指標。
    編按: 例如 google 搜尋結果的排名很重要，對 RAG 場景來說，只要檢索 top-k 有命中就好，其中的順序沒這麼重要，反正 LLM 都會看到。
16. Out-of-domain 不等於 out-of-vocabulary: 早期模型碰到沒見過的詞會出錯。現在的 tokenization 可以處理沒見過的詞(如 Labubu)，但它們仍是 out-of-domain，向量看起來正常但其實沒意義。
    編按: 解決方案是(開源) Embedding 可以做微調
17. 查詢優化(Query optimizations)的藝術: 就像我們學會在 Google 輸入 “longest river africa” 而不是完整問句，現在也要學習如何為向量搜尋優化查詢。

從 RAG 到 context engineering，不變的是為 LLM 找到最適合的資訊，讓它們能提供最佳回答，這一點仍然是關鍵。

更多討論在我 Facebook 貼文。

How to turn Claude Code into a domain specific coding agent

看到 LangChain 團隊分享了一個很實際場景的實驗: 如何讓 Claude Code 變成專精特定領域的 coding agent。
現在的 coding agents 對主流框架很熟悉，但碰到公司內部 API、小眾框架或新版本的函式庫就gg了。作為 LangGraph 和 LangChain 的開發者，他們當然希望 AI 能寫出高品質的 LangGraph 程式碼。
於是他們做了個實驗，測試四種配置:

1. 原版 Claude Code (什麼都不加)
2. Claude + MCP 文件工具 (指 LangChain 自己出的 mcpdoc 工具)
3. Claude + Claude.md (精心撰寫的 LangGraph 指引文件)
4. Claude + MCP + Claude.md 全套組合

效果排名: 4 > 3 > 2 > 1

這個 mcpdoc 工具提供兩個功能: list_doc_sources 抓取 llms.txt 文件的網址目錄，fetch_docs 根據網址抓取文件內容。
快速結論是: 精心撰寫的 Claude.md 檔案，表現比單純給文件工具還好!

幾個關鍵發現:

• 這個 mcpdoc 文件工具效果不如預期: 單份文件的 context 還是太長，可能呼叫一次就塞爆 context window 了。如果你的文件多到想要用工具來查，建議實作更精準的檢索功能，只回傳相關段落。
• 寫好 Claude.md 的 CP 值最高: 雖然 Claude.md 只包含全部文件內容的子集，表現卻更好。他們觀察了 log 發現: Claude 並沒有頻繁呼叫 MCP 工具。即使任務需要查看多個相關頁面，它通常只呼叫一次就停了，只得到表面描述而非所需細節。
• 最強組合是兩者並用: AI 透過 Claude.md 獲得重要概念和基礎知識，需要時再用 MCP 深入查詢文件細節。

最後很可惜的是，他們並沒有測試 Context7 這個目前最受推薦的 MCP coding 文件檢索工具，這家的做法就是只回傳「相關段落」而不是整份文件，正好能解決 mcpdoc 塞爆 context window 的問題。若是 Claude.md 搭配 Context7 使用，想必效果更上一層樓

補充: 這是他們 LangGraph 的 claude.md 內容，原文中也有介紹一下這個 prompt 的結構。

更多討論在我 Facebook 貼文。

LLM framework 筆戰

要不要使用 LLM 框架來開發 AI 應用，一直是個熱門話題。最近看到一場精彩的筆戰，有梗又有料，實在太有趣了!

以下轉載翻譯原文:

Ashpreet Bedi 先生 (Agno 框架)

像這樣的騙子只是在浪費你的時間，他們的鄧寧-克魯格效應(Dunning-Kruger effect)意見應該被認真的開發者忽視。
你要麼基於框架開發，要麼活得夠久到自己造輪子(順帶一提，這也沒問題)。原因如下：

1. 「在 while 迴圈中呼叫 LLM API」是你的基礎 Agent 步驟 – 你 Agent 系統中的工作單元。你會把它包裝成函數，在需要執行 Agent 時呼叫它。這只是起跑線，也是這些白痴通常卡住的地方。
2. 當你開始建構 Agent 時，你會把這個函數轉成類別，加入提示詞處理、訊息管理、工具呼叫、重試和錯誤處理的邏輯。恭喜，你已經開始自己造輪子了。
3. 接著，你會想嘗試不同的模型或串接 Agent 來建構工作流程。每個模型都有其特殊之處、自訂設定、不同的回應格式、提示詞技巧(例如：Claude 需要「請勿在回應中反思搜尋結果的品質」)。你開始為自製框架加入更多層次。

到目前為止這還是可解決的問題，你還能憑感覺搞定它。

4. 然後事情真的開始變得令人沮喪。你很快就會發現需要跨執行維護會話歷史和狀態，因為不像那些騙子，你實際上不會在你媽家的地下室跑 Jupyter notebook。你猜怎麼著 — 你的 Agent 需要資料庫。你會設計像 agent_sessions 這樣的資料表，串接會話 ID，在每次執行時儲存/檢索歷史和狀態。幾週後，你會發現你的架構效率低下，因為你忘了加入正確的索引，現在你得學習資料庫遷移。
   靠北！這不是應該只是個 while 迴圈嗎？而且我們甚至還沒開始處理 RAG、分塊、嵌入、檢索、上下文管理、工具管理、MCP、監控和日誌記錄。為什麼騙子要騙人?
   現在我們已經陷入憑感覺寫程式的噩夢好幾週了，而 CEO 還在問什麼時候可以上線。
5. 最後，你面對真正的問題：我該如何將這個服務化成 API 並在上面建構產品?
   你拼湊出一個 FastAPI 應用，把它丟進容器，以為大功告成。你鬆了一口氣，交給你的 CEO。他像瘋子一樣猛測，分塊開始掉落，Agent 混淆上下文，你突然需要學習 SSE。你實作了 SSE，事情運作良好一陣子，然後你的請求開始逾時，容器記憶體爆掉 – 記憶體洩漏。你責怪 Python，但內心深處，你知道，你知道的。
   你開始搜尋解決方案，然後看到來自 @AgnoAgi 的這段程式碼片段…

Alec Velikanov 先生 (某新創CTO) 的回覆

像這樣的騙子只是在浪費你的時間，他們的鄧寧-克魯格效應意見(Dunning-Kruger effect)應該被認真的開發者忽視。
你要麼建構自己的 Agent 迴圈，要麼活得夠久被困在別人的框架地獄裡(順帶一提，這也沒問題)。原因如下：

1. 閃亮的「框架示範」在第一天看起來很棒。幾行 YAML，一個神奇的 Agent() 呼叫，突然你以為自己要出貨了。這只是起跑線，也是這些白痴通常卡住的地方。
2. 當你開始建構實際的使用案例時，你會發現你需要的一半功能都是「即將推出」或藏在某個沒有文件的設定旗標後面。你開始 fork、hack、包裝他們的抽象層⋯恭喜，你在維護他們的框架而不是建構自己的。
3. 接著，你會想嘗試不同的模型或串接工作流程。每個框架都強迫你採用它「欽定」的編排風格、奇怪的序列化格式，或「外掛生態系」。你花在對抗抽象層的時間比解決問題還多。

到目前為止還能存活，你還能憑感覺繞過它。

4. 然後事情真的開始變得令人沮喪。你很快就會發現他們的記憶體/狀態層很爛——寫入很慢、索引缺失、遷移根本不存在。你在凌晨三點調試別人半成品的 SQLite 包裝器，想著為什麼不自己寫三個資料表就好。
   靠北！這不是應該要幫我省時間嗎？而且我們還沒碰到框架的「RAG 管線」(長文件就會壞掉)、它神奇的嵌入快取（會洩漏記憶體）、或者基本上就是 print() 的監控。為什麼騙子要騙人？
   現在你已經陷入依賴地獄好幾個月了，而 CEO 在問為什麼什麼都要私訊框架的 Discord 管理員才能運作。
5. 最後，你面對真正的問題：我該如何在生產環境運行這個？ 框架提供了一個預建的 FastAPI 容器，號稱有「企業級」端點… 直到它在平行請求時deadlocks、在負載下 timeout 時，你才意識到作者從來沒有擴展超過黑客松示範的規模。
   你提交一個 issue，得到一個愉快的「歡迎 PR :)」回覆，內心深處，你知道，你知道的。
   你開始搜尋解決方案，然後意識到唯一的修復方法是把它全部拆掉，回到原始的 LLM API 和 while 迴圈。
   你看見了曙光，放棄你的受虐狂傾向，並重複這個咒語：自己他媽的動手做就對了！

—

更多討論在我 Facebook 貼文。

Sniffly 工具

歐萊禮 AI Engineering 一書(這本有繁中翻譯版)的作者 Chip Huyen 開源了一個 Claude Code 的使用分析工具 Sniffly，可以幫助我們更有效使用 Claude Code。
她還分享了幾點心得:

1. 最常見的 Claude Claude 錯誤類型是「找不到內容」(20-30%) ，Claude Code 經常試圖尋找不存在的檔案或函數。因此她會重新調整程式碼結構，讓 AI 更容易「發現」需要的內容。
2. 傳統的開發時數指標已經不適用 AI，她提出兩個新的專案複雜度評估指標:

• 需要給 AI 多少次指令才能完成專案
• 有多常要打斷 AI 因為 AI 走錯方向

1. 大多數需要打斷 AI 的情況，在 10 步內就需要人工介入，偶爾可以接近 100 步自主運作。Claude Code 最愛用的工具是搜尋類指令(grep、ls、glob)，佔了所有工具呼叫的 1/3。

Sniffly 還能讓你回顧所有歷史指令和模型回應結果，安裝方式很簡單，指令是 uvx sniffly@latest init

更多討論在我 Facebook 貼文。

OpenAI Agents SDK v0.3.x released

最近我開始有空就貢獻一下 OpenAI Agents SDK 原始碼，從 v0.3.0, v0.3.1, v0.3.2 都可以看到 ihower 的 commits。
包括修了這個 #1689 和 #1757、加了 1758 跟這個 1765。
我也在跟進 #1767 跟 #1789。
如果大家碰到什麼奇怪問題，也可以找我喔。

希望你會喜歡這集內容！

– ihower

看到 MCP 官方出了一個 Registry [1]，GitHub [2] 也出了一個 Registry，這是在打架嗎？

不是的，讓我解釋一下 MCP Registry 的架構。

[1] 官方公告 blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/
[2] GitHub MCP Registry github.blog/ai-and-ml/github-copilot/meet-the-github-mcp-registry-the-fastest-way-to-discover-mcp-servers/
[3] 架構圖出自官方文件 Ecosystem Vision，推薦一看: github.com/modelcontextprotocol/registry/blob/main/docs/explanations/ecosystem-vision.md

為什麼需要官方 Registry？

官方 MCP Registry 是一個統一的 metadata service，解決了幾個關鍵問題:

Server Discovery: 各種 MCP servers 散落在各個 GitHub repo、社群討論串，很難找。現在有了中央目錄，方便找到合適的 MCP server。更重要的是，它提供標準 API，未來 AI agents 可以自動發現和選擇需要的工具。

信任與安全性: 你可以知道這個 MCP server 是誰建立的，是不是官方認證的。這能大幅減少安全風險，避免安裝到惡意或釣魚的 MCP server。Registry 還有社群回報機制，可以標記和移除有問題的 servers。

版本追蹤: 清楚知道你正在使用哪個版本的 MCP server，有沒有更新可用，避免版本混亂的問題。

兩層 Registry 的分工

官方的 Registry 和 Github 的 Registry 的關係就像「中央資料庫」和「使用者介面」的差別。

MCP 官方 Registry (registry.modelcontextprotocol.io) 是個純粹的 metaregistry，它的工作很單純: 當作所有公開 MCP servers 的「single source of truth 單一事實來源」。它只提供 API 和標準化的 metadata，沒有漂亮的 UI，就像一個中央資料庫。

GitHub 的 MCP Registry (github.com/mcp)則是一個 subregistry，專門做使用者體驗。它會從上游的官方 Registry 自動同步資料，加上 GitHub 特有的功能: 漂亮的瀏覽介面、用 GitHub stars 排序、VS Code 一鍵安裝等等。

Metaregistry 的設計

有個關鍵概念是 MCP Registry 只有做 metaregistry，沒有存真正的程式碼檔案。

這是因為開源軟體圈早就有成熟的套件管理系統: JavaScript 有 npm、Python 有 PyPI、容器化應用有 Docker Hub。這些都是各社群花了十幾年建立的基礎建設。

因此 MCP 就不重新發明輪子了:

• MCP server 的程式碼檔案，還是發布到 npm 或 PyPI 等等 (就像平常發布套件一樣)
• MCP Registry 只記錄: 「weather-server v1.2.0 在 npm:weather-mcp」這種索引資訊

於是這形成了架構分工:

1. 既有套件系統 (npm, PyPI, Docker Hub): 存真正的程式碼檔案
2. 官方 MCP Official Registry: 新增的索引層，告訴你哪個 MCP server 在哪裡
3. 各家 Subregistries (GitHub, Smithery 等): 加值服務層，提供好用的 UI 和額外功能

開發者的工作流程是:

• 把 MCP server 程式碼發布到 npm/PyPI (不用學新東西)
• 在 MCP Registry 註冊一筆 metadata
• MCP server 自動出現在所有 subregistries

當你在 GitHub Registry 點「安裝」時，它會查詢 MCP Registry 的 metadata，然後導向 npm 或 PyPI 下載真正的程式碼。

結語

這種設計比再做一個 MCP servers awesome list 聰明多了，建立了一個分層協作的生態系: 既有套件系統管程式碼、MCP Registry 做索引和信任層、各家 subregistry 專注使用者體驗。開發者只需要發布一次，使用者就能在任何地方找到。開源社群太有智慧啦。

最近看到一場關於 AI Evals 的精彩論戰，爭論焦點不在模型訓練層面的評估(這個大家都有共識要做)，而是 AI 應用層面到底要做多少評估。這讓我想起自己在軟體開發的經驗: 如何寫測試也是我曾關注的問題，但說實話，我從來不追求 100% test coverage。即使 Ruby 社群也強調每件事都要有測試涵蓋，但我還是比較考量成本效益，自動化測試對我來說是值得做才會做的事。

現在 AI Evals 也處於類似階段。我去年就開始關注並分享如何做評估，但要求每個面向都 100% 有評估其實是不實際的。AI 是機率性軟體，評估難度更高，AI 的輸出好不好也非常有主觀成分，目前怎麼做很依賴實務經驗交流。最近剛上完 AI Evals For Engineers & PMs 課程，有了新的體會。首先，「評估驅動開發」(指先寫評估再開發) 竟然可能是錯的方向 – 對於沒有標準輸出的 AI 任務，你無法無限投資在評估上。

我目前認為評估可分兩種:

Soft preferences (graded helpfulness): 大多數範例用 LLM as Judge 給 1-5 分評估「有多少幫助」、「有多清晰」等，都屬於這類。坦白說，這種評估幫助有限，頂多做相對比較，實際效用不大。

Hard rules (binary guardrails): 這種其實更實用，就是會有標準答案的二元判斷，用 Code-based 或 LLM as Judge 判斷是不是有做到你要求的限制。這門課程重點就是教如何用 LLM 科學地做出對齊後的 binary classifier，老師就是這篇知名 paper: Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences 的第一作者。

沒有標準答案的 LLM 要輸出怎麼做 binary classification 的評估? 我們不做通用的 LLM-as-Judge 評估，而是先人工做錯誤分析，找出真正重要的錯誤模式，然後每個錯誤模式分別做 LLM as Judge 只判斷 Y/N 輸出有沒有犯這個特定錯誤。這個 Judge 需要認真做對齊，得有很高的準確率，因為是 classification 任務所以也相對好做 prompt 最佳化。如此下來，你會得到真正有用的準確指標，能實際用來幫助改進 AI 應用。

就如 Hamel Husain [0] 說的：「Generally no. Eval-driven development (writing evaluators before implementing features) sounds appealing but creates more problems than it solves.」重點是找到真正影響用戶體驗的關鍵指標，而不是為了評估而評估。

[0] x.com/HamelHusain/status/1950247467444031828

那 Soft preferences 怎麼辦？這部分還是得依賴人的判斷，AI Judge 無法完全取代。無論是團隊自己 dogfooding、監控線上指標、收集用戶回饋，或是跑 A/B testing，還是得靠傳統產品開發的方法。AI 應用的評估不是非黑即白的選擇題，得在不同階段不同需求，靈活運用不同工具的智慧。

Hamel Husain 還有一篇 The Mirage of Generic AI Metrics 也指出通用指標的問題，並介紹錯誤分析、建立客製化指標、建立可信的 LLM Judge。

(以下整理整個論戰的精彩內容，透過 Claude 摘要寫成)

AI Evals 論戰整理

這場辯論始於 Anthropic Claude Code 創始人 Boris 在訪談中[1]的坦白。當被問到如何評估新模型時，他的回答令人意外地簡單：「我就做我當天的工作」。沒有複雜的測試套件，沒有精密的指標，純粹就是感覺模型變聰明了嗎。Boris 承認他們試過建立產品評估系統，但發現建立評估真的很困難，最終最大的信號就是「感覺」。他認為很難找到能捕捉軟體工程所有複雜性的合成評估，SWE-bench 這類基準測試雖然表現出色，但真實的軟體開發遠比這些測試複雜。

這個坦白被 swyx 爆料後引發軒然大波。他在推特上諷刺地列出了產業現況：Claude Code 沒有 evals，某知名 code agent 公司沒有 evals，另一家知名公司只有敷衍的 evals，領先的 vibe coding 公司也沒有 evals。但賣 evals 的公司 CEO 會說「我所有的頂級客戶都做 evals，你也應該做」，愛上 evals 公司的創投也會附和「我所有的頂級創辦人都做 evals，必須做 evals」。swyx 補充說他確實認為 evals 很重要，但那些狂熱支持 evals 的 AI 工程師也注意到，做不做 evals 並不是成功的嚴格要求，至少在從 0 到 1 的階段，不做 evals 甚至可能與成功呈正相關。

[1] www.youtube.com/watch?v=iF9iV4xponk
[2] x.com/swyx/status/1963725773355057249

支持 Evals 的聲音

學術派代表 Shreya Shankar [3] 與 Hamel Husain 聯手為 evals 辯護，他們將 evals 定義為「對應用品質的系統性測量」，強調這不意味著特定的指標或方法，也不必是單一數字或完全準確。她指出那些聲稱「不做 evals」的團隊其實在自欺欺人，每個成功的產品都在某處做著評估，查看輸出、注意問題、dogfooding 產品並做出改變，這就是評估，只是沒有貼上「evals」的標籤。

她特別點出一個關鍵事實：即使像 coding agent 這樣的團隊感覺可以不做太多評估，那是因為他們已經從上游的嚴格評估中受益。編碼 evals 在後訓練中佔據如此重要的地位，實際上是其他人已經為你完成了大部分的 evals 工作。基礎模型供應商為每個新能力領域投入大量資金進行評估，因為他們知道沒有系統性測量就無法改進效能。

她特別擔心反 eval 情緒對社群的傷害，因為許多新手正在尋求建立 AI 產品，他們的任務可能不在後訓練中被充分代表，團隊也還沒有足夠經驗依賴直覺，對這些團隊來說，否定 evals 等於移除了幫助他們理解什麼有效、什麼無效的工具。

[3] www.sh-reya.com/blog/in-defense-ai-evals/

Braintrust CEO Ankur Goyal [4] 發表了一篇引戰文章，宣稱 A/B 測試已經跟不上 AI 時代的步伐。他認為傳統 A/B 測試建立在「創建變體很昂貴」的假設上，你需要為每個體驗投入大量設計和工程工作，所以只能測試少數選項。但 AI 改變了這個遊戲規則，當 AI 能自動為每個用戶生成個性化介面時，為什麼還要為「最佳平均體驗」做優化？他指出 OpenAI 收購 Statsig、Datadog 收購 Eppo 暗示著轉折點已經到來，未來屬於 evals 而非 A/B 測試。在他的願景中，系統能即時學習和改進，團隊從手工調整每個細節的工匠，變成自動化改進系統的架構師。

[4] www.braintrust.dev/blog/ab-testing-evals

實務經驗豐富的 Eugene Yan [5][6][7]把 evals 類比為測試驅動開發（TDD），在開發功能前先定義成功標準並從第一天就開始測量。他分享了自己的經驗：一旦設置好 eval 和實驗框架，讓調整配置和 prompt 變成一鍵運行加評估，團隊會享受運行實驗和提升指標的過程，進展會很快。但他也承認設置這個框架對每個新專案都是挑戰，需要處理模糊的工作，即使設置好了，也很少人想看生成的回應來做定性評估。他強調通用的 evals 像「faithfulness」或「helpfulness」是沒用的，你的 evals 必須與用戶問題對齊。

[5] x.com/eugeneyan/status/1960148508495020234
[6] x.com/eugeneyan/status/1964103249230774682
[7] x.com/eugeneyan/status/1964334356006391882

反對 Evals 的批判

AgentOps CEO Alex Reibman 發表了最激進的批評文章《Evals are a scam》 [8]，直指整個產業都在被「eval 洗腦」。他認為大多數 AI 團隊不需要 evals，需要的是 logging、QA 和品味。他指出基礎模型的 evals（測試 LLM 在各種任務的一般效能）和產品 evals（測試應用在真實使用案例的效果）是完全不同的東西，除非你在 OpenAI、Anthropic 或 Meta 工作，否則你不需要模型 evals。而產品 evals 是主觀、模糊且混亂的，eval 供應商試圖賣給你他們永遠無法提供的東西：對你自己產品的專業知識。他認為這些公司其實是「複雜性商人」，透過課程、電子書、部落格、網路研討會推銷他們的框架，最終真正賣的是昂貴的 logging 服務。

[8] hacktrace.substack.com/p/evals-are-a-scam-and-were-being-gaslit

前 GitHub Copilot 團隊、現 Quotient 創辦人 Julia Neagu [9] 從工程師視角提供了深入分析。她指出 LLM 作為 API 出現，這對工程師來說是熟悉的領域，所有成功的 AI 工具都有一個共同點：對工程師有良好的人體工學設計。但 eval 工具沒有映射到已知的開發者工作流程，這就是為什麼兩年來「evals 很重要」的論述下，eval 工具仍然沒有突破的原因。她在 GitHub Copilot 的經驗證實了這點：雖然有複雜的 eval 框架用於基準測試，但真正決定是否上線的還是 A/B 測試，而且推出的壓力如此之高，如果通過 A/B 測試就會直接上線。她總結說，儘管網上論述聲稱相反，大部分 AI 產品仍然是基於 vibes 在出貨。

[9] x.com/JuliaANeagu/status/1964704824299253888

Raindrop CTO Ben Hylak [10] 從監控角度批評 evals，認為 evals 只是已知問題的集合，是你透過對抗性選擇找到的失敗案例，無法發現未知問題。他引用 Replit 工程師的話：由於輸入空間不再有限，你無法簡單地寫幾個選定的測試然後遵循測試驅動開發，你會在不知情的情況下破壞關鍵功能。這就是為什麼在生產環境中測試，使用傳統 A/B 測試也很關鍵，能盡可能接近你服務的一般人群，有更高機會測試長尾結果。當 AI agents 變得越來越強大，能執行的任務越來越開放，運行時間越來越長，如果構建正確，它們能以你無法預測或想像的方式執行任務，測試所有可能性變得不可能，但監控仍然可行。

[10] www.raindrop.ai/blog/thoughts-on-evals

實踐者 Matt Shumer [11] [12] 分享了 Otherside 的經驗，他們使用基於真實流量的 A/B 測試，測量訂閱和留存率。他直言 evals 有幫助但與實際效用的相關性不高，試過所有方法後，A/B 測試才是正道。他的觀點簡單明瞭：如果你是實驗室，建立通用前沿模型，evals 很重要；如果你是產品建構者，evals 大多不重要。

[11] x.com/mattshumer_/status/1964178712452354551
[12] x.com/mattshumer_/status/1963789428029042822

尋求平衡的聲音

Hamel Husain [13] 試圖調解這場由兩家供應商引發的戰爭，他指出你需要同時進行線上和離線測試，它們各有不同的權衡。離線指標是行為和結果的替代指標，能夠更快速地迭代；線上指標和 A/B 測試則是必要的，用來驗證你的離線指標確實是良好的替代指標，而且某些東西只能透過線上測試來測量。他感嘆需要將資料科學帶回 AI 工程領域，因為這種缺失在當前的討論中顯而易見。他補充說，OpenAI 的技術成功團隊花費大量時間與客戶討論評估（evals），他們認為這是高槓桿的活動，評估決定了專案能否從概念驗證(PoC)階段順利推進到成功部署。

[13] x.com/HamelHusain/status/1964110406596907170

Bryan Bischof [14] 認為 swyx 比其他討論者更深入理解這個議題的細微差異。他指出幾個關鍵點：evals 作為單元測試一直大多無關緊要，除了早期迭代或回歸測試；超級廣泛的黃金 eval 集往往老化得很差；那些說「就 A/B 測試啊，兄弟」的人，通常連 A/B 測試都不懂，更別說在 LLM 範式中做有效的 A/B 測試。他解釋為什麼 code agent 公司較少迷信 evals：因為用戶角色和產品開發者之間的差距很小，大家都同意 dogfooding 非常有價值，但飛輪是：dogfooding → 錯誤分析 → 編碼化的 eval。他直言不在應用層工作的人應該在這個話題上閉嘴。

[14] x.com/BEBischof/status/1963739648792117484

Brooke Hopkins [15] 指出這場辯論的核心問題：每個人用「evals」指代至少 6 種不同的東西，然後在對話毫無交集時感到震驚。她認為雙方都錯過了重點，真正的問題不是 evals 有效或無效，而是定義混亂。她主張不能把生產前和生產後的評估分開看待，需要整合的系統，讓生產前模擬能實際反映真實用戶模式，生產監控能回饋成更好的測試案例，人工審查員能有效發現演算法永遠不會捕捉到的邊緣案例。她特別強調需要更多資料科學家參與 evals，而不只是 ML 工程師，因為大多數 eval 框架是由確定性思維的人構建的，但 AI 系統是機率性的，我們使用了錯誤的心智模型。
[15] x.com/bnicholehopkins/status/1965130607790264452

Hello! 各位 AI 開發者大家好

我是 ihower，這期不小心變成月刊了，暑假真是過太快了。

幫分享今年的 PyCon Taiwan 在臺北文創，總共有 3 種形式的演講與 6 種不同性質的交流活動。
時間是 2025/9/5 – 9/7 活動資訊與購票

OpenAI GPT-5 API 更新重點整理

OpenAI 於 2025/8/7 推出 GPT-5 啦，包括 ChatGPT 和 API 都同時上線了。這篇是我針對 AI 開發者快速解惑與整理重點。

Agent 讓 RAG 過時了嗎? 談 AI Coding 的檢索策略

看了一場 Augment Code (也是一家做 AI IDE 的廠商) 來講 “Agentic 檢索” 對比 “傳統 RAG 檢索” 的演講，蠻有啟發的。
在 AI Coding 領域，簡單的工具正在擊敗複雜的 RAG 系統。這篇是我的解讀整理。

如何管理 AI 專案? AI PM 從確定性工程到應用研究

最近看了幾篇討論 AI 產品經理和 AI 專案管理的內容，最有感的是這句話:「傳統軟體開發是確定性的，但 AI 開發本質上是應用研究」，這根本性的差異改變了一切。
這篇是我的解讀整理。

從 Prompting 基本結構到 Agent Prompting 設計原則

Anthropic 最近才釋出了他們在 2025/5/22 開發者大會的完整影片，當時的重頭戲是 Claude 4 模型發布。其中有兩場關於 prompting 教學的演講內容很不錯，這兩場演講從基礎 Prompt 到針對的 Agent 的 prompting ，展現了 prompt engineering 的不同層次，推薦大家一看。這篇是我的解讀整理。

Shopify 的內部工程經驗

在 Anthropic 開發者活動的錄影中，還有好幾場是客戶公司來展示他們用 Claude 做的產品，包括:

• Canva: 推出 Canva Code，讓非技術用戶也能建立互動式網頁原型
• Databricks: 整合 Claude 到他們的資料平台，用於處理企業級 AI 應用的治理和評估問題
• Manus AI: 建立通用 AI Agent，可以在雲端虛擬機器中執行長時間任務（如找辦公室、規劃行程）
• Shopify: 下述
• Tempo Labs: 打造「給 PM 和設計師用的 Cursor」，讓非工程師也能協作寫程式碼
• Zencoder: 推出 ZAN agents，支援 MCP 的自訂 Agent，可部署在整個軟體開發生命週期
• Gamma: 用 Claude 生成簡報和文件
• Biddo: AI 程式碼審查平台
• Refusion: 音樂生成平台，用 Claude 的 Ghost Writer 幫助創作歌詞
• Create: AI Text-to-App 建構器，讓任何人都能用自然語言建立行動應用程式
• Stanford 學生用 Claude 建立核武偵測模擬系統
• UC Berkeley 學生 7 個月從零學會寫程式，建立多個實用工具

但最讓我感興趣的是 Shopify 首席工程師 Obie Fernandez 的分享，這場我認為比較特別是在講內部工程工具，不是講產品。
Shopify 是全球最大的 Ruby on Rails 應用，開發近 20 年，有數百萬行程式碼。在這種規模下，他們怎麼善用 AI 提升開發效率?

他們的關鍵洞察是: 確定性 vs 非確定性工作流程的結合，他認為 AI 工具有兩種截然不同的使用方式:

1. Agentic 工具 (如 Claude Code): 適合探索性、模糊的任務，需要適應性決策和迭代
2. 結構化工作流程: 適合有明確步驟、需要一致性和可重複性的任務

他們發現，像花生醬配巧克力一樣，可以將這兩種方式結合起來。他們除了大量使用 Claude Code，同時也開發了 Roast 一套用 Ruby 寫的結構化 AI 工作流程框架。

實際應用案例:

• 自動化測試生成和優化
• 程式碼遷移
• 類型檢查改進

最巧妙的是可以雙向整合:

• 可以在 Claude Code 中呼叫 Roast 工作流程
• 也可以在 Roast 工作流程中呼叫 Claude Code SDK

實務好處:

• 可以快取 function 呼叫結果，不用每次重跑
• 可以從特定步驟重新開始，不用從頭跑
• 5-6 週內在內部環境推出後，已經在公司內部 “像野火般蔓延”

Obie 說: 無論最先進的模型在遵循指令方面變得多麼優秀，它們本質上仍然是非確定性的。這種混合方法讓 Shopify 能在保持靈活性的同時，確保大規模工程組織需要的可預測性和可重複性。
Ruby 程式語言是我的老本行，我進一步研究了這個 Roast 專案，他的核心原理是在建構一個連續對話流程，這個 workflow 採用 yaml 格式定義，例如:

name: analyze_tests
model: gpt-4o-mini
tools:
  - Roast::Tools::ReadFile
  - Roast::Tools::Grep
steps:
  - read_test_file
  - analyze_coverage
  - generate_report

每個步驟都可以定義自己的 prompt，後續步驟能參考前面對話的所有上下文。這種設計讓工作流程既結構化又保持彈性。
這套跟一般教的固定式 prompt chaining 流程不太一樣的地方在於

1. 這有賦予工具使用，因此一個step實際上是一輪agent內部執行
2. 採用模型 API 原生的對話串格式來維持 context

個人覺得算是蠻特別的設計，有點像是固定交接流程的 multi-agent 工作流程。

近期 MCP 演講整理和趨勢

看了 MCP Developer Summit 和 AI Engineer World’s Fair 中關於 MCP 的 50+ 場演講(當然只是看逐字稿 AI 摘要啦，不然看錄影會有20+小時)，整理出 MCP 生態系的幾個重要發展趨勢:

1. MCP 協定持續進化
2. 企業級導入案例
3. MCP Gateway 有超高需求
4. 工具太多成為核心挑戰
5. 從工具思維到 Agent 思維
6. 標準化之爭

以下分別展開:

1. MCP 協定持續進化

MCP 新推出兩個重要新功能:

• Elicitation: 讓 MCP server 可以向 MCP client 請求用戶的額外資訊
• Tool Structured Output: 可以定義工具的結構化輸出格式

相關演講:

• MCP Project Update with Jerome Swannack, Member of Technical Staff at Anthropic
• MCP Registry: Designing For Server Discovery Tadas A. (PulseMCP) Alex H.(Block), and Toby P.(GitHub) 這場討論官方 MCP Registry 的發展情況

除了新功能，也有一些早就存在但被忽視的規格受到關注。例如 Sampling 功能(我在五月的 MCP talk 有講到，可讓 MCP server 使用 MCP client 的 LLM)
相關演講:

• MCP201: The Protocol in Depth with David Soria Parra at Anthropic
• Resources: Building the Next Wave of MCP Apps with Shaun Smith, LLMindset

2. 企業級導入案例

• Block 的全公司導入: 分享全公司導入 MCP 的經驗，最有趣的發現是「非技術人員比工程師更有創意！」甚至有非工程師自己 vibe code 了一個 MCP server (連 GitHub 帳號都沒有)。
• Bloomberg 的大規模採用: 展示如何用 MCP 連接內部各種系統，讓 AI 能夠安全存取企業資料。他們特別強調資料安全和合規性的重要。

相關演講:

• From Experiment to Enterprise: How Block Operationalized MCP at Scale – Angie Jones, Block
• Pragmatic Scaling of Enterprise GenAI with MCP with Sambhav Kothari at Bloomberg

3. MCP Gateway 有超高需求

企業一旦開始導入 MCP，馬上就會發現需要 Gateway 來解決各種問題，如何管理內部眾多 MCP server 和工具，特別是安全與授權挑戰。因此希望能有單一的 MCP server 作為 Gateway 角色，統一入口管理。

• WorkOS 分享從 localhost 到企業級的血淚史。身份驗證只是第一步，更難的是「AI workload 之間的授權傳遞」。還有各家推出 Gateway 方案百花齊放:
• UCL 把 MCP 包成企業級 Gateway
• Pomerium 用零信任架構包裝所有服務
• A16Z 提出 Service Proxy 概念
• Smithery、Fastn、Natoma 都推出託管方案
• MCP Defender 的安全方案: 使用 Proxy 攔截所有流量，用 LLM 來保護 LLM
• ScaleKit 提出 Auth 託管方案
• Anthropic 工程師也分享了他們內部 MCP gateway 的經驗

相關演講:

• What MCP Middleware Could Look Like with Yoko Li from A16Z
• Fastn UCL: Secure & Scalable MCP for Enterprise AI Deployments | Khalid Muaydh, Fastn
• Agentic Access: OAuth Isn’t Enough | Zero Trust for AI Agents w/ Nick Taylor (Pomerium + MCP)
• Tool Calls Are the New Clicks: Henry Mao on Building Smarter AI Agents with MCP
• Enterprise-Ready MCP: Hosted Solutions for Scale, Security & Real-World Use | Paresh Bhaya, Natoma
• How to Add OAuth to MCP Servers in 4 Steps — Ravi Madabhushi, Scalekit
• Securing AI Apps with MCP Defender — Sundeep Gottipati
• What does Enterprise Ready MCP mean? — Tobin South, WorkOS
• Remote MCPs: What we learned from shipping — John Welsh, Anthropic

非常多公司都在做 Gateway 這個題目，顯示這是真實且迫切的需求。

4. 工具太多成為核心挑戰

當你有幾百甚至幾千個工具時，AI 會選擇困難。各家提出不同解法:

• VS Code 的工具管理策略: 動態使用者在每個對話中有不同工具子集，還能自訂工具組合（toolsets）
• Block 的洋蔥式架構: 把工具分成三層 – 發現層、規劃層、執行層。先用一個工具來探索有哪些 API 可用，再用另一個工具取得詳細參數，最後才執行。有點像是「先問有什麼菜 → 再問怎麼做 → 最後才點菜」的概念。
• Appify 的動態載入: 他們有 4000+ 個工具！解法是用 MCP 的 toolListChanged 通知機制，根據使用者需求動態載入工具。比如說使用者想爬 LinkedIn，系統才去找相關的爬蟲工具加進來。
• 向量搜尋方案: 把所有工具描述先做成 embeddings，當使用者輸入 prompt 時，用相似度搜尋找出最相關的工具，再用 reranker 排序。這樣就不用一次載入所有工具。

相關演講:

• Too Many Tools? How LLMs Struggle at Scale | MCP Talk w/ Matthew Lenhard
• Full Spec MCP: Hidden Capabilities of the MCP spec — Harald Kirschner, Microsoft / VSCode

5. 從工具思維到 Agent 思維

這是重要的開發典範轉移: 不要只是把 API 端點一對一變成 MCP工具！你會有三個用戶: 終端用戶、client app 開發者，還有 AI 本身。要思考使用者會問什麼問題，然後設計適合的工具介面。
MCP-first 開發: 與其先做 REST API 再包裝成 MCP，不如一開始就為 AI 設計。當 AI 成為主要使用者時，系統設計的思維要完全改變。

相關演講:

• Scaling Enterprise MCP: Best Practices, Nexuses, and Security with Pat White
• MCP Is Not Good Yet — David Cramer, Sentry

6. 標準化之爭

LlamaIndex 的 Laurie Voss 比較了 14 個 Agent 通訊協議。Google 的 A2A (Agent-to-Agent) 已經加入 Linux Foundation，確保技術中立性。
關鍵問題: 「呼叫工具」和「呼叫 Agent」到底有什麼差別？A2A 說差別在於 Agent 可能需要很長時間回應（甚至幾天），所以內建了非同步機制。但講者認為這差異並不大，而且 MCP 也即將支援非同步。

編按: 你可以將 Agent 包在 Tool 裡面，呼叫工具就是傳訊息給裡面的 Agent。我在我之前的 MCP talk 就有提到這招。

現實很殘酷: 這 14 個協議大多「半生不熟」，真正有採用率的只有 MCP。為什麼？因為 MCP 選擇先解決一個小而具體的問題，證明了自己的價值。就像 React 當年征服前端世界一樣。結論是犀利的: 「MCP is all we need」。

相關演講:

• MCP vs ACP vs A2A: Comparing Agent Protocols with Laurie Voss from LlamaIndex
• A2A & MCP Workshop: Automating Business Processes with LLMs — Damien Murphy, Bench

Block’s Playbook for Designing MCP Servers

這篇文章是 MCP server 的開發經驗談，關鍵洞察是: 別從 API 端點開始設計，而是從工作流程來設計

傳統 API 設計是 bottom-up，但給 LLM 用的工具應該 top-down，從「用戶想完成什麼任務」倒推回去設計。

舉個例子，他們的 Google Calendar MCP 第一版就犯了經典錯誤:

一開始直接包裝 API，例如 list_calendars(), list_events(), get_timezone()。結果問「我今天行程如何?」需要串接一堆 tool calls 才能回答。

改版後直接提供 query_database() 讓 AI 跑 SQL，一次搞定複雜查詢。要找三個人的共同空檔? 一行 SQL 就解決:

sql SELECT * FROM free_slots(['alice@example.com','bob@example.com','carol@example.com'], ...)

他們還發現幾個關鍵 Best Practices:

• 善用 LLM 優勢: SQL 查詢、Markdown 圖表是強項，但別讓它規劃太多步驟或輸出複雜 JSON
• 工具名稱很重要: 因為 tool name 和 description 本身就是 prompt，要寫得清楚明確
• 權限管理要簡單: 每個工具最好只有一種風險等級(唯讀 vs 寫入)，別混在一起讓用戶困惑
• Prompt 要快取友善: 避免在指令中放動態資料(如當前時間戳)，會讓快取失效

最後他們 Linear MCP 的演進，從 30+ 個小工具最後精簡到 2 個: execute_readonly_query 和 execute_mutation_query，直接讓 AI 寫 GraphQL。

RAG Anti-Patterns in the Wild

看了 Skylar Payne 這場 “RAG Anti-Patterns in the Wild” 演講，內容蠻豐富的。他從五個實際客戶案例中整理出 RAG 系統常見的坑。這些案例涵蓋了不同領域的 RAG 應用，包括客戶支援知識庫、醫療建議聊天機器人、金融新聞摘要、學術研究助手、電商產品比較。
總共 17 個 Anti-Patterns，根據 RAG 流程的六個階段區分:

資料收集與策劃 (Data Collection & Curation)

1. 文件編碼格式錯誤處理不當: 例如假設所有文件都是 UTF-8，遇到 Latin-1 就直接丟掉
2. 包含無關文件集: 索引包含與查詢無關的文件，像是金融新聞索引包含總體經濟文章

擷取與內容強化 (Extraction & Enrichment)

4. 資訊擷取不正確: PDF 表格擷取失敗，例如 LaTeX 生成的多欄文件
5. Chunking 太小: 把文件切成太小片段，失去上下文造成幻覺，例如 電商產品規格表切成 200 字元
6. 保留垃圾 Chunks: 例如頁首頁尾有一堆獨立重複的 chunk，佔用檢索空間

索引與儲存 (Indexing & Storage)

7. 天真使用 Embedding: 沒考慮問答語義差異，問題形式與文件形式不同
8. 沒檢查索引過期: 索引沒定期更新，提供過時資訊，例如財經新聞索引兩週沒更新

檢索 (Retrieval)

9. 接受模糊查詢: 例如接受「健康建議」這種太廣泛的查詢，檢索結果雜亂無章
10. 接受離題查詢: 沒有過濾無關查詢，如電商網站回答「寫一首獨角獸的詩」，造成奇怪的生成結果
11. 所有用戶詢問都用RAG處理: 讓所有用戶查詢都去走完整 RAG 流程，例如「我的帳單日期」可用查詢結構化資料庫解決。解法是需要做意圖分類，找出常見用戶查詢改用一般資料庫查詢甚至用快取，而非進到 RAG 流程
12. 沒有評估假陰性: 只評估檢索到的文件，不看漏掉的相關文件
13. 沒有評估檢索充分性: 只標記相關性，不標記是否足夠回答問題。答案是否正確、檢索是否充分，有四種象限可以分析和處理

重新排序 (Reranking)

14. 過度使用 Boosting: 加太多人工 boost 分數提升規則，系統變脆弱，例如 10 個 boost 規則讓無關文件排名超前
15. 允許離譜結果 (Face-Palm Results): 不過濾明顯錯誤的結果，例如查帳單地址變更，第一名是服務條款
16. 不做評估就增加複雜度: 例如加入多個檢索路徑卻沒有評估效果，造成延遲從 4 秒增到 11 秒，品質反而變差

生成 (Generation)

17. 簡單 RAG 是無法處理推理查詢的: 只做單次檢索無法連結多個概念，碰到多步推理的問題會失敗
18. 沒有輸出防護措施防止幻覺，不要求引用來源，無法驗證生成內容，案例是 醫療聊天機器人憑空生成藥物副作用

以上每個 anti-pattern 都有具體的建議，蠻實用的。

• 投影片
• 我擷取的逐字稿和截圖
• 我整理後的內容文章

作者還有個 The RAG Checklist 可以訂閱，會拿到一份 checklist PDF (就是演講內容的摘要)。

Startups to F500: Document Automation Lessons at Scale

在一場關於大規模文件自動化處理的演講 Startups to F500: Document Automation Lessons at Scale，讓我看到跟 91APP 在 今年生成式 AI 年會一樣的「正確率 vs. 覆蓋率」概念。
Extend 團隊分享了一個血淋淋的教訓: 他們的客戶一開始就想要一次性自動化整個 SaaS 合約處理流程。結果呢？差點整個專案都要放棄，拿到 AI 工具就想馬上自動化一切，把文件丟給 ChatGPT，看起來擷取得很完美，就以為可以直接取代整個人工流程。
現實是殘酷的，在牙科帳單自動對帳案例中，他們提出一個關鍵的務實方法：與其追求 98% 準確率但不知道那 2% 錯在哪，不如達到 85% 的「真實自動化率(true automation rate)」- 也就是系統能 100% 確定哪些可以自動處理，哪些需要人工介入。
而在 91APP 的案例，他們在做商品資料自動填充時，面臨同樣的選擇：

• A 方式: 每個商品都有答案，但正確率只有 70%
• B 方式: 只有 50% 的商品有答案，但正確率 90% 以上。另外 30% 的商品只有部分答案。

你猜他們選哪個? 答案是 B 方式。為什麼？因為 A 方式那種情況最痛苦。使用者不知道哪些是錯的，只能全部重新檢查。這正是 Extend 說的：「在關鍵業務文件處理中（如合約、醫療記錄、財務文件），錯誤的代價極高。重點不是達到最高的處理覆蓋率，而是要能「明確驗證」(declaratively validate)哪些處理是正確的。只要能做到這點，即使只能自動化部分流程，也能安全地部署到生產環境」
那要怎麼做？

• 第一步：建立人工流程 (Human-in-the-Loop)，先收集真實數據。Extend 的客戶改變策略後，即使 AI 處理了文件，還是有交給人工審核，藉此了解真實的生產數據。
• 第二步：建立文件特徵分類系統，理解數據模式。他們在 20 萬份文件上跑批次處理，不是為了擷取數據，而是為了理解「哪些供應商的文件有問題」「哪些版面配置會出錯」。
• 第三步：針對不同情況設計不同處理方式。例如 91APP 的方式: 高信心正確率的情況，完整填入答案讓人類簡單審核即可。沒信心的不要填答案，讓人類補齊答案。

總之，「盡可能自動化，否則就增強」。不是要 AI 完全取代人類，而是建立一個誠實、可信賴的人機協作系統。當 AI 說「我確定」的時候，你可以相信它；當 AI 說「我不確定」的時候，你知道要自己判斷。

別想著一次到位，先從能做好的部分開始，逐步擴大自動化範圍。真實自動化率比虛高的準確率更有價值。

模型是否就是你的產品?

看了兩場演講談「Is the Model The Product?」模型是否就是你的產品。討論 AI 產業的一個核心問題: 到底一個 AI 產品真正的價值在於模型還是產品體驗。
以下整理這兩場觀點跟心得。

觀點一: 模型即產品 The Model is the Product

Han 的觀點是模型的核心智慧才是唯一重要的，產品的核心價值來自基礎模型。
洞察有:

1. 模型的突破性能力會創造全新產品類別，例如 GPT-3.5 誕生 ChatGPT、Claude Sonnet 3.5 誕生 AI Coding，每次模型能力的躍進，都會開啟一個新的產品賽道。
2. 模型會吸收周邊的複雜度，例如以前做 NLP 要手動處理語法解析、語意理解、實體辨識… 現在 Transformer 把整個 stack 都吃掉了。系統的複雜性和結構變得不那麼重要，所有的智慧都將聚合到模型中。

每次模型能力的躍升，都會讓一批創業公司哭喊「OpenAI 殺死了某某新創」。如果你的價值建立在當前模型的不足之處，下一個模型版本可能就會讓你的護城河消失。
兩種生存策略: Model-First vs Product-First

Model-First: 例如 DeepSeek CEO 說:「我們相信當前階段是技術創新的爆發，而不是應用的爆發。」主要實驗室都追求最先進的模型，朝著 AGI 競賽，無論那是如何定義的。但這並不容易。即使對於像 Elon Musk 這樣的人，也花了將近兩年時間和三個模型發布，Grok 才能接近領先優勢，才能有競爭力。當模型驅動價值時，模型優先給你最強的牌。但對大多數公司來說，這非常昂貴、有風險，並不總是可行的。

Product-First: 產品優先戰略的本質。你如何設計、整合，以及如何分發和提供以用戶為先的體驗。但是核心挑戰是，許多產品優先公司，你依賴於市場上的模型優先實驗室來提供這些新能力。你無法控制底層的突破。你必須等待它。當這些能力被吸收到下一個模型發布中時，你的差異化可能會消失。那麼護城河在哪裡？

講者認為 AI 產品的生存關鍵是「distribution 分發」即護城河。

有句話說，第一次創業者著迷於產品，第二次創業者著迷於分發。在 AI 應用的世界中，分發給你數據、用戶行為數據、產品反饋數據，以及一些真實世界的信號，讓你知道什麼有效，什麼無效。你可以使用分發來建立自己的數據，建立自己的評估框架，建立自己的基準測試。所以當新的模型能力出現時，你將是第一個進入市場的。或者如果你願意，你可以使用你的數據來自己創造新興能力。

觀點二: 產品品味(Product Sense)才是護城河 The Model is Not the Product

Hamel Husain 講者的反駁是: 如果模型是一切，為什麼擁有最強模型的公司做不出好產品？
他認為你的品味和產品感才是護城河，不是模型。
很多人說基礎模型實驗室（OpenAI、Google 等）會往上游走，自己做產品，把所有價值都吃掉。但這不就是老掉牙的「為什麼 Amazon 不會自己做？」翻版嗎？把 Amazon 換成 OpenAI，道理是一樣的。Google 有最先進的 LLM、自己的硬體、50 億用戶，按理說應該橫掃 AI 產品市場吧？但是:

• Google Docs 不能處理評論、不能顯示差異
• Calendar 不能存取聯絡人
• Gmail 常常回答「我無法協助」

相比之下，第三方產品 Lindy 反而能輕鬆幫你從聯絡人找到 Brian 並安排會議。
AI 工程其實包含兩件事:

1. 讓模型做你想做的事，用到 prompt engineering、RAG、框架等
2. 搞清楚你到底想要什麼，這需要品味、判斷力、設計、UX，設計良好的使用者介面
   就算未來第一件事變簡單了，第二件事永遠逃不掉。GitHub Copilot 和 Cursor 在很長一段時間內都可以存取相同的模型。也許現在不是，但在很長一段時間內都可以存取相同的模型。我會說非常、非常不同的產品，具有非常不同的能力和來自用戶的非常不同的反應。我會說不是模型的部分正在做大量的工作。產品體驗天差地遠，這不是模型的功勞。

結論看法

模型能力是必要條件但非充分條件。就像 Switch 不是用最先進的晶片堆出來的，而是任天堂把現成組件整合成令人愉悅的體驗。
我們都同意分發(distribution)是一種護城河，用戶數據讓你比模型公司更有優勢，請建立自己的評估架構。
模型會越來越聰明，但「弄清楚用戶要什麼」這件事，還是需要人類的品味和洞察力。

驗證的不對稱性

剛被挖角去 Meta 超級智慧實驗室的前 OpenAI 研究員 Jason Wei，也是著名 Chain-of-Thought 論文的第一作者，最近寫了幾篇短文，講到的概念蠻不錯的，紀錄一下。

1. 驗證的不對稱性(Asymmetry of verification) 1

有些任務「解決很難，驗證很簡單」，例如數獨要花很久解，但檢查答案對不對只要幾秒。

但也有些任務「驗證比解決還難」，比如事實查核有個 Brandolini 定律: 「駁斥錯誤資訊所需的努力比製造它多出一個數量級」。許多科學假說也是如此，提出一個新飲食法很簡單，但要驗證是否真的有益健康，可能要花好幾年追蹤研究。
這裡 Jason 提出「驗證者定律」(Verifier’s Law): AI 訓練的難易度，與任務的可驗證性成正比。所有可能解決且能驗證的任務，最終都會被 AI 解決。
一個重要洞察是: 我們可以主動改善驗證的不對稱性。以程式設計為例，雖然閱讀程式碼並檢查正確性很繁瑣，但如果有涵蓋充分的測試案例，就能快速檢查任何解答。
為什麼這個很重要？因為能夠驗證，就能建立強化學習(RL)訓練環境，讓 AI 不斷嘗試、獲得回饋、持續改進。未來我們很可能會有個參差不齊的智慧邊緣: AI 在可驗證任務上會更聰明，因為解決可驗證任務要容易得多。

2. 描述-執行落差(description-execution gap”) 2

描述任務的難度與實際執行該任務的難度相比，哪一個更高？如果描述任務比實際執行簡單很多，這類任務就很適合 AI 自動化。

例如「修正文章中的語法錯誤」，描述起來簡單，但實際要人工檢查整篇文章很費時。
反之，像「以特定風格剪輯影片」，通常自己剪比描述每個細節該怎麼做還容易，或是「幫媽媽買雜貨」，她有非常特定的品項和數量，自己去買比跟我描述要買什麼、要怎麼挑水果還簡單。
這解釋了為什麼某些看似簡單的任務 AI 還做不好: 不是技術問題，而是描述成本太高，人會懶得跟 AI 講清楚。因此當描述任務的成本接近或超過執行成本時，人類自己做反而更有效率。

3. 從 RL 強化學習學到的人生哲學: 走自己的路 3

強化學習的重要概念是始終保持「on-policy」: 與其模仿他人的成功軌跡，不如採取自己的行動，並從環境給予的獎勵中學習。

模仿學習只適合初期啟動，就像在學校學習基礎知識。但真正要超越老師，必須做 on-policy RL: 根據自己的強項和弱點，從環境中獲得真實回饋來學習。
他舉了個人例子: 別人可能擅長快速嘗試，但他發現自己更擅長「深入閱讀資料」和「做細緻的實驗」。這些看似「慢」的方法，反而成為他的獨特優勢。
與其模仿別人的成功路徑，不如發揮自己的獨特優勢。就像 RL agent 最終要找到自己的策略，而不是永遠模仿人類的解法。

補充有人指正: 易驗證不等於 AI 一定能訓練得出解，原文中這個 Verifier’s law 還有一些但書。例如質因數分解還是很難，驗證卻很簡單。所以這更像是工程經驗法則: 要驗證快且能密集回饋有效訊號，RL 迭代才會有效。

Claude Code 課程推薦

Claude Code 是目前最火紅的 AI Coding 工具，也是我最近的主力開發工具，可輔以 Cursor 使用。這裡推薦兩個 Anthropic 官方推出的課程:

• Anthropic Academy 的 Claude Code in Action 錄製非常精美的線上課程
• DeepLearning.AI 的 Claude Code: A Highly Agentic Coding Assistant 用了三個案例(RAG Chatbot、Jupyter notebook、Visual mockup) 實際示範開發過程，非常推薦

更多關於 Claude Code 的資源整理，可以參考我的筆記。

希望你會喜歡這集內容！

– ihower