想系統性學習如何開發 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 應用開發有興趣的朋友!