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
不過要注意這都是 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 貼文。
🧵 關於 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:
- AI Agents 的建構者、開發者，需要使用到 context engineering 策略。
- 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 都採用這個策略
- Context Caching (上下文快取)
這是 Manus 特別強調的技巧 ，他們之前也有寫過blog 文章特別強調這點。
🔹 Manus 還分享了更多新思路
- 選擇性保留的藝術: 不只是縮減內容，而是知道要保留什麼。並非所有的工具輸出都是平等的。有些工具會生成 Agent 需要多次引用的豐富結構化資料。其他工具只是二元信號——是或否，成功或失敗。對於豐富的結構化資料，你通常想保留完整的輸出，或者至少保留一個非常詳細的摘要。對於二元信號，你可以積極地修剪它們。
- 時間衰減策略: 最近的上下文通常比舊上下文更相關。但這並不總是成立。有時 Agent 在任務早期做出的決定對後續步驟至關重要。所以實作了時間衰減機制，但會為關鍵決策點、重要工具輸出和錯誤訊息設定例外，這些會被保留更長時間，因為它們往往對 Agent 的推理軌跡很重要。
- 階層式摘要: 在不同層級進行摘要，創造了一種「壓縮金字塔」，Agent 可以根據它需要多少細節來檢索不同層級的資訊。
- 動態閾值修剪: 不是在固定的 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 多分類標籤
主要發現:
- 數字評分不穩定
- 無法區分品質差異: 錯誤率 20% 和 50% 的文字，可能都被評為 6 分，無法區分品質差異
- 分數容易跳躍，例如從 5 分突然跳到 8 分，中間沒有漸進變化
- 多次評分同一段文字，每次給的分數都不太一樣
- 不同模型給的分數尺度不同，GPT 可能給 7 分的文字，Claude 可能給 4 分，難以比較
- 推理模型(o3)表現較好，但成本高
- o3 在評估情緒化錯誤時表現不錯，分數變化比較平滑連續
- 但在拼字錯誤的評分上，還是很快就「飽和」，只要有一點錯誤就給低分，無法區分輕微和嚴重的差異
- 推理模型成本高很多，要評估效益是否划算
- 字母等級(A-E)穩定但粗糙
- 用 A-E 評分比數字穩定，多次評分結果較一致
- 但解析度很低，大部分樣本都擠在 A-C，只有極端情況才會出現 D 或 E
- 本質上更像「分類標籤」而非精確評分
- 二元評分和多分類最可靠
- 二元判斷(好/壞、對/錯)最穩定，不同模型、不同 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 的包裝功能:
- 先把寫好的 script 先傳到 container 裡面，讓 agent 可以執行
- 搭配 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 你也會做了。
更多討論在我 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