想系統性學習如何開發 LLM、RAG 和 Agents 應用嗎? 歡迎購買我的課程 大語言模型 LLM 應用開發工作坊
Hello! 各位 AI 開發者大家好 👋
這一期電子報間隔比較久啊，最近又是自己開課🔥錄影回放票販售中，又是準備 GenAI 年會的演講。有點忙碌。AI 世界當然也是毫不停歇: Llama 4、OpenAI GPT-4.1、o3 跟 o4-mini、Claude 4 等新模型連發。
🔝 淺談模型上下文協定 MCP 應用開發 投影片
無懸念 MCP 會是 Agent 應用以及開發非常重要的一環了，這是我在生成式 AI 開發者年會所做的 MCP 分享，內容包括: Why MCP、什麼是 MCP、MCP server 和 client、Remote MCP server 的發展、Sampling 和 Agents as Tools 多代理人架構、 MCP 的 Roadmap 等等。
錯過現場也沒關係，GenAI 年會提供線上回放票，可在這裡購買 👉 pse.is/7jrlk8 有我的專屬 $250 折扣碼：IHOWER
🧠 OpenAI: A Practical Guide to Building Agents
OpenAI 發布了一份打造 AI Agent 的白皮書指南，內容包括什麼時候該用 Agent、Agent 如何設計、多代理人架構，並使用 OpenAI Agents SDK 示範。
篇幅不長也不難，覺得蠻實在的，不是那種不明覺厲的技術白皮書。我自己也蠻推薦用 OpenAI Agents SDK (這是 Python 版本，也有出 JavaScript 版本)，輕量好上手、沒有多餘的抽象、Production-Ready 我需要的功能都有: python async, streaming, handoffs, multi-agents, MCP, tracing, guardrails 等等。
要上手 OpenAI Agents SDK 我推薦看他文件 Quickstart 和 Examples，也可以看 Elvis Saravia 有場教學影片 和 Guide。
我自己的課程也有一個多小時的內容在教 OpenAI Agents SDK 來實作 multi-agents 架構，包含 Handoffs、Agents as Tools、Sequential Workflow、Parallelization、Orchestrator-Workers、Human-in-the-loop、Self-Reflection、Guardrails 全套架構通通都有實作範例。
新一代 Agent 框架
坦白說，去年之前我還認為 LLM 應用不需要任何額外框架，直接用官方 API 就夠了。但從今年開始，我的看法改變了: 我認為 “Agent” 這個軟體元件概念已經開始成熟，能夠成為一種基礎的開發範式。最近半年新出的 OpenAI Agents SDK、Google ADK、Pydantic AI 這幾套框架，已經將 “Agent” 當作基礎開發元件，逐漸收斂出相似的實作模式與設計共識，特別是 multi-agents 架構幾乎都有對等的範例，例如我前面提到的架構，在 Google ADK 中也都能找到非常類似的實作，例如:
| OpenAI Agents | Google ADK |
| Handoffs | LLM-Driven Delegation (Agent Transfer) 和 Coordinator/Dispatcher Pattern |
| Deterministic flows | Sequential Pipeline Pattern |
| Parallelization (Orchestrator-workers) | Parallel Fan-Out/Gather Pattern |
| Self-Reflection | Review/Critique Pattern 和 Iterative Refinement Pattern |
| Agents as Tools | Explicit Invocation (AgentTool) |
| 「Agents as Tools + Handoffs」多層組成 | Hierarchical Task Decomposition |
這種發展，讓我聯想到當年 Web Framework 百花齊放，然後 MVC 架構成為主流時的感覺: 從各做各的，到逐漸建立起一套共同語言與範式。反之，一些和上述三套設計哲學很不同的舊框架，例如 LangGraph、Llama Agents、CrewAI、AutoGen 等等，我則不建議學習採用。
引戰 LangGraph 番外篇
這 OpenAI 白皮書中有段 Declarative as non-declarative graphs 的論述:
「有些框架採宣告式設計，開發者必須預先在圖形化的流程圖中—由節點（代理）與連線（確定性或動態交接）構成—明確定義每一個分支、迴圈與條件判斷。這種方式雖然視覺上清晰，但隨著工作流程愈趨動態與複雜，就變得繁瑣且難以維護，甚至得學習專用的領域特定語言（DSL）。相較之下，OpenAI Agents SDK 採用更具彈性、以程式碼為先的做法。開發者可直接用熟悉的程式語言撰寫流程邏輯，無需事先繪製完整的流程圖，就能實現更動態、易於調整的代理協調。」
白皮書雖然沒有明說，但明眼人都知道”有些框架“”就是指 LangGraph，因此這引起了 LangChain 創辦人 Harrison Chase 對號入座非常不滿，還特別寫了一篇 How to think about agent frameworks 反擊，而 Latent Space 也整理各方觀點: In the Matter of OpenAI vs LangGraph。
我個人非常認同 OpenAI 的說法，幾乎是一針見血，官方這麼坦白寫出人家的痛點真的沒問題嗎 😆 我自己也偏好輕量級、以程式碼為先的框架設計: 最近正好在研究 Python 如何做企業級的 workflow 系統，在比較 Prefect 和 Airflow 的差異。看到 Prefect 寫的一篇 You Probably Don’t Need a DAG 強化了我的想法:
- DAG 限制你只能使用有限子集的程式碼，無法寫出原生程式語言中常見的控制邏輯
- DAG 比純程式碼更難閱讀和撰寫
- 品質保證是以犧牲開發彈性換來的，放棄原生語言的靈活性，改學一套受限的 DSL
這裡所說的 DAG，其實就是用一種專門的 DSL(領域特定語言)來描述整個流程控制。我相信 DAG 在重量級場景一定有價值，但 Prefect 的論述和 OpenAI 的論述，本質上都在倡導一種 workflow 編排哲學: 不需讓工作流程被工具與靜態圖結構綁死，而是可以回歸程式語言本身的表達能力。
🔍 OpenAI: Practical Guide for Model Selection for Real‑World Use Cases
這篇文章是 OpenAI 發布的最新模型選擇指南，並提供三個開發案例來分析搭配哪些模型。
- 模型特性對比: 在 GPT 4.1、o3 與 o4-mini， 詳細比較各模型的核心優勢、適用場景和升級路徑
- 三個實務案例: 法律文件問答系統、製藥研發 AI 助手、保險表單處理
這三個案例非常精彩，含金量很高，推薦可以認真看看他們是怎麼做的。
特別是第一個案例雖然叫做 RAG，但卻完全沒用到 embeddings 來做索引處理，而是模擬人類瀏覽文件的方式，讓 LLM 去全文閱讀尋找相關資訊。
🌟 OpenAI Responses API 新功能
- Remote MCP server: 可以直接讓 OpenAI 直連 remote MCP server，效率大大提升，在我 MCP 投影片中有一張我做的流程圖可以看出前後差異。
- Code Interpreter: 終於也移植到 Responses API 了
- Image generation tool: 圖片生成除了有單獨的 API 端點，也可以當作 tool 使用
- Encrypted reasoning items: 讓你拿到加密後的推理 tokens (就是不讓你看推理過程)，方便你再次回傳給 OpenAI API 使用，適合用在 function calling 場景
- Background mode: 長時間任務可以讓 OpenAI 在背景執行
緊接著 Claude API 也宣布支援 Remote MCP server 了: New capabilities for building agents on the Anthropic API
👍 OpenAI GPT-4.1 Prompting Guide
如果你用非推理模型 GPT-4.1 來開發 Agent，那這篇指南別錯過了，包括:
- 三個 system prompt 咒語: 強力要求模型呼叫工具前需要先計畫、需要連續呼叫工具來解決用戶問題
- 建議的 Prompt Structure 提示結構
# Role and Objective
# Instructions
## Sub-categories for more detailed instructions
# Reasoning Steps
# Output Format
# Examples
## Example 1
# Context
# Final instructions and prompt to think step by step- 分隔符號推薦用 Markdown 或 XML，不推薦用 JSON
- 若有很長的 context 內容的話，建議將你的指示重複放在開頭和結尾。如果不想重複，偏好放上方
- 不建議使用全大寫字母或其他誘因，如賄賂或小費，可能會有副作用
🎯 Fiction.liveBench
The Fiction.LiveBench 是最近常看到的長上下文評測基準，專門用來測試 LLM 在處理長篇文本時的理解能力。
與其他評測基準不同的是，Fiction.LiveBench 不僅僅測試模型是否能找到長文本中的資訊(像「大海撈針」那樣的測試)，而是評估模型對故事內容的深入理解，包括：
- 追蹤隨時間變化的人物關係，例如：從恨到愛，再到恨，最後變成執著
- 基於已建立的線索做出合理預測
- 理解讀者知道的秘密與角色知道的秘密之間的區別
最近 Llama 4 宣稱有 10M 長上下文引起轟動，但我通常都是讓子彈飛一會:
Q: 真的有人會跑到 10M 嗎？果然在各供應商(例如在OpenRouter上的)，都沒有支援到 10M，頂多就是 1M。想來是因為要耗費太多記憶體，又很少人會實際用到
Q: 那實際效果如何？根據 Fiction.LiveBench 的結果，Llama 4 表現令人失望。
以下是一些結論:
- OpenAI 的 o3（GPT-4o）是目前表現最佳的模型
- DeepSeek-R1 優於 o3-mini，對價格敏感的用戶來說是個不錯的選擇
- GPT-4.5-preview 和 GPT-4.1 是最好的非推理模型
- Google 的 Gemini 2.5 Pro 表現出色
- Anthropic 的 Sonnet-3.7 比 3.5 有顯著改進
- Llama 4 系列表現不佳，Maverick 比上一代 Llama 3.3 70B 還差，而 Scout 的表現更是糟糕
🛠️ 12-Factor Agents – Principles for building reliable LLM applications
這篇 Agent 架構設計的 12 個要素給了我很多啟發。作者沒有採用任何框架，事實上，他就是不滿意現在的任何 Agent 框架才寫的這篇。
即使 LLM 會繼續變聰明，但一定會有核心的工程技術讓基於 LLM 的軟體更加可靠、更具擴展性且更易維護。
- 前言: 我們如何走到 Agent 軟體: 丟掉 DAG，你不需要為每個步驟和 edge case 寫程式，而是可以給 Agent 目標和改變狀態的工具
- 要素 01: 自然語言轉換為工具呼叫
- 要素 02: 掌握你的 prompt
- 要素 03: 掌握你的 context window
- 要素 04: 工具只需要結構化的輸出
- 要素 05: 統一的執行狀態與業務狀態
- 要素 06: 使用簡單的 API 來啟動/暫停/恢復 Agent
- 要素 07: 透過工具來聯繫真人
- 要素 08: 掌控你的控制流程
- 要素 09：將錯誤訊息放到 context window
- 要素 10: 小而專注的 Agent
- 要素 11: 隨處觸發，與使用者零距離
- 要素 12：讓你的 Agent 成為無狀態的 reducer
📚 OpenRouter 上的 5 個「免費」模型推薦
Kyo 分享了他在 OpenRouter 平台上的五個免費模型的使用經驗: DeepSeek: R1、DeepSeek V3、Qwen3-32B、Qwen3-235B-A22B、Google Gemma 3 27B
希望你喜歡這集內容！如果你想更有系統地掌握這些 LLM 開發技術，歡迎購買我的🔥大語言模型 LLM 應用開發工作坊(2025升級版)課程。也歡迎把這門課推薦給對 LLM 應用開發有興趣的朋友！