JoJo雷達

# 【嚴重警示】LiteLLM 供應鏈攻擊事件完整分析：TeamPCP 如何透過受污染的 CI/CD 工具竊取 50 萬帳戶憑證 ## 事件概述 2026 年 3 月 24 日，AI 開發社群爆發重大資安事件。流行的 Python AI 套件 **LiteLLM** 在 PyPI 上遭到植入惡意程式，攻擊者為駭客組織 **TeamPCP**。這是一次精心策劃的軟體供應鏈攻擊（Supply Chain Attack），影響範圍遍及全球超過 20,000 個專案。 **關鍵數字：** - 暴露時間窗口：約 3-5 小時 - 潛在受影響帳戶：約 500,000 個 - 受影響套件數量：20,000+ 個 GitHub repo - 下游依賴套件：DSPy、CrewAI、browser-use、nanobot-ai、MLflow 等 --- ## 攻擊鏈分析：三階段供應鏈滲透 ### 第一階段：入侵 CI/CD 安全掃描器 攻擊起點並非 LiteLLM 本身，而是其 CI/CD 管道使用的安全掃描工具 **Trivy**。 **時間線：** - 2026-02-28：TeamPCP 透過 `pull_request_target` 漏洞初步入侵 Trivy CI/CD - 2026-03-19：Trivy v0.69.4 GitHub Action 的 76/77 個版本 tag 被改寫為惡意版本（CVE-2026-33634, CVSS 9.4） - 2026-03-23：Checkmarx KICS GitHub Action 被入侵；攻擊者預先註冊假冒域名 `models.litellm.cloud` **關鍵漏洞：** LiteLLM 的 CI/CD 在安裝 Trivy 時未鎖定版本，導致惡意 Trivy 竊取了 `PYPI_PUBLISH_PASSWORD` 等 GitHub Actions 機密。 ### 第二階段：惡意套件上傳 | 版本 | 上傳時間 (UTC) | 感染方式 | |------|--------------|---------| | **1.82.7** | 10:39 | 在 `proxy_server.py` 第 128-139 行注入 base64 雙重編碼惡意程式 | | **1.82.8** | 10:52 | 追加 `litellm_init.pth` (34,628 bytes)，利用 Python `.pth` 機制在每次 Python 啟動時自動執行 | ### 第三階段：惡意程式執行 ``` Loader (.pth 或 proxy_server.py) ↓ base64 解碼 Orchestrator (含 RSA-4096 公鑰) ↓ 啟動 Credential Stealer → 加密 → POST 到 models.litellm.cloud ↓ 同時 C2 Backdoor (sysmon.py) → 每 50 分鐘輪詢 checkmarx.zone ↓ 若有 Kubernetes Kubernetes 橫向移動 → 在 kube-system 部署特權 Pod ``` **為何被發現？** `.pth` 機制造成**指數級 fork bomb**，耗盡受害者記憶體而崩潰。若無此 bug，木馬可能潛伏數週不被發現。 --- ## 技術細節：.pth 機制的危險性 Python 的 `.pth` 文件可被用來執行任意程式碼： ```python # 惡意 .pth 文件 import base64; exec(base64.b64decode('...惡意程式碼...')) ``` 這意味著即使專案沒有直接使用 LiteLLM，只要安裝了受感染版本，**每次執行 Python 都會觸發木馬**。 --- ## 攻擊者目的：大規模憑證竊取 | 類別 | 目標 | |------|------| | SSH 金鑰 | id_rsa, id_ed25519, authorized_keys | | 雲端憑證 | AWS IAM, GCP credentials, Azure ~/.azure/ | | Kubernetes | Service account tokens, kubeconfig, kube-system secrets | | 環境變數 | 所有 .env 文件（遞迴搜尋 6 層目錄） | | 加密貨幣錢包 | Bitcoin wallet.dat, Ethereum keystores, Solana 等 10+ 種 | 資料以 AES-256-CBC 加密後打包為 `tpcp.tar.gz` POST 至 `models.litellm.cloud`（攻擊前一天才註冊的假冒域名）。 --- ## 受影響版本 | 版本 | 狀態 | |------|------| | **1.82.7** | 惡意版本 | | **1.82.8** | 惡意版本（更危險） | | **1.82.6** | 最後安全版本 | **間接受影響套件：** DSPy、CrewAI、browser-use、nanobot-ai、MLflow、各種 MCP plugins 等。 --- ## 如何檢查是否受影響 ```bash # Step 1: 確認版本 pip show litellm # 若顯示 1.82.7 或 1.82.8 -> 已受感染 # Step 2: 搜尋惡意 .pth 文件 find / -name "litellm_init.pth" 2>/dev/null # Step 3: 檢查後門文件 ls ~/.config/sysmon/sysmon.py 2>/dev/null ls /tmp/pglog /tmp/.pg_state 2>/dev/null # Step 4: Kubernetes 環境 kubectl get pods -n kube-system | grep node-setup ``` **IoC 域名：** - `models.litellm.cloud`（非官方，資料滲出端點） - `checkmarx.zone`（C2 伺服器） --- ## 立即處置步驟 ```bash # 移除惡意套件 pip uninstall litellm && pip cache purge # 清除後門 rm -f ~/.config/sysmon/sysmon.py rm -f ~/.config/systemd/user/sysmon.service rm -f /tmp/pglog /tmp/.pg_state # 安裝安全版本 pip install "litellm==1.82.6" ``` **必須立即輪換的憑證：** SSH keys、AWS/GCP/Azure IAM、所有 API keys（OpenAI, Anthropic 等）、資料庫密碼、GitHub PATs、Kubernetes service account tokens。 --- ## 長期防護建議 | 措施 | 說明 | |------|------| | **鎖定依賴版本** | requirements.txt 使用精確版本號，避免 `>=` 或 `^=` | | **使用 lock file** | poetry.lock 或 pip-tools 生成的 requirements.txt | | **掃描 .pth 文件** | 定期檢查 site-packages 中的 .pth 文件 | | **使用 SCA 工具** | Snyk、Sonatype Nexus、Endor Labs 等 | | **CI/CD 工具鎖版** | 所有 CI/CD 工具（包括安全掃描器）都需鎖定精確版本 | --- ## 專家見解 **Kaspersky：** 將此事件列為「現代史上最大且最危險的供應鏈攻擊之一」。 **ARMO (Ben Hirschberg, CTO)：** 「LiteLLM 是 AI 基礎設施中憑證密度最高的目標——它本身就設計用來持有 100+ LLM 提供商的 API keys」。 **Helixar AI：** 「沒有任何安全工具在事發當下偵測到此攻擊，是惡意程式的 bug 救了所有人。」 **Andrej Karpathy：** 評論此事件為「software horror」。 --- ## 官方回應 - 移除受感染的 PyPI 套件（v1.82.7, v1.82.8） - 輪換所有維護者憑證 - 委託 **Google Mandiant 安全團隊**協助鑑識分析 --- ## References - LiteLLM 官方公告：https://docs.litellm.ai/blog/security-update-march-2026 - GitHub Issue #24518：https://github.com/BerriAI/litellm/issues/24518 - BleepingComputer：https://www.bleepingcomputer.com/news/security/popular-litellm-pypi-package-compromised-in-teampcp-supply-chain-attack/ - Snyk 分析：https://snyk.io/articles/poisoned-security-scanner-backdooring-litellm/ - Kaspersky：https://www.kaspersky.com/blog/critical-supply-chain-attack-trivy-litellm-checkmarx-teampcp/55510/ - SafeDep 深度分析：https://safedep.io/malicious-litellm-1-82-8-analysis - Sonatype：https://www.sonatype.com/blog/compromised-litellm-pypi-package-delivers-multi-stage-credential-stealer

## 今日一句話 AI Agent 的基礎設施競賽正式開打：記憶體管理、技能框架、專屬瀏覽器，2026 年三月的 GitHub Trending 告訴我們，下一個戰場是 Agent 的「感知與行動基礎層」。 --- ## 今日最值得研究 Repo ### 1. volcengine/OpenViking **GitHub**: https://github.com/volcengine/OpenViking **語言**: Python | **Stars**: 12,388 | **今日新增**: +1,870 **為什麼爆紅** OpenViking 是字節跳動（ByteDance）火山引擎團隊開源的 AI Agent 上下文資料庫，專門解決 Agent 在執行任務時記憶碎片化、技能無法複用、資源無法統一調度的問題。ByteDance 本身大規模部署 AI Agent，這套工具是他們內部實踐的提煉，開源後立刻引發業界高度關注。 **技術架構** OpenViking 採用「檔案系統範式」（file system paradigm）統一管理三類上下文： - **Memory（記憶）**：對話歷史、使用者偏好、任務狀態的持久化存儲 - **Resources（資源）**：外部工具、API、資料來源的統一索引 - **Skills（技能）**：可複用的 Agent 行為模組，支援版本管理與繼承 核心創新在於「階層式上下文傳遞」（hierarchical context delivery）與「自我演化」（self-evolving）機制：Agent 執行完任務後可自動更新自身的 Skills 庫，形成持續學習的閉環。 **實際應用場景** OpenViking 適合需要長期執行、跨任務共享知識的 Agent 系統，例如程式碼助理（記住使用者的程式風格偏好）、客服 Agent（持續累積產品知識）、研究 Agent（跨對話保存中間結果）。 **研究價值評分**: ★★★★★ 這是目前市面上少數真正面向生產環境的 Agent 記憶體管理方案，ByteDance 背書加上完整的架構設計，值得深入研究。 --- ### 2. obra/superpowers **GitHub**: https://github.com/obra/superpowers **語言**: Shell | **Stars**: 85,881 | **今日新增**: +1,867 **為什麼爆紅** `superpowers` 不是一個新工具，而是一套 Agentic 軟體開發方法論，用 Shell 腳本實作「技能框架」（skills framework）的概念。它的爆紅來自於一篇廣為流傳的討論：在 Claude Code、Cursor、Copilot Workspace 百花齊放的當下，如何用最簡單的方式讓 AI 學會你的工作方式，而不是每次都從零開始。 **技術架構** `superpowers` 的核心概念是把開發工作流拆分為可組合的「技能腳本」（skill scripts），每個腳本對應一個具體的開發行為（如 code review、test generation、refactoring）。這些腳本透過 Shell 串接，讓 LLM 具備重複執行、可審計、可版本控制的工作能力。架構刻意保持極簡，避免對特定 LLM 或框架的依賴。 **實際應用場景** 適合想要客製化 AI 開發助手的工程師：定義自己的 code review 標準、自動化 PR 描述生成、根據團隊規範的測試生成流程。由於是純 Shell，幾乎可以嵌入任何現有開發環境。 **研究價值評分**: ★★★★☆ 方法論層面的價值高，但技術深度相對有限。適合作為「如何設計 Agentic workflow」的參考案例，而非直接引入生產的框架。 --- ### 3. lightpanda-io/browser **GitHub**: https://github.com/lightpanda-io/browser **語言**: Zig | **Stars**: 18,575 | **今日新增**: +1,335 **為什麼爆紅** Lightpanda 是一款專為 AI 與自動化設計的無頭瀏覽器（headless browser），用 Zig 語言撰寫。相較於 Playwright 或 Puppeteer 背後的 Chromium，Lightpanda 追求極度輕量、快速啟動、低記憶體佔用，目標是讓 AI Agent 能以極低成本大規模並行執行網頁爬取與操作任務。 **技術架構** 選用 Zig 語言是關鍵決策：Zig 提供接近 C 的效能同時擁有更好的記憶體安全機制，適合實作瀏覽器這類需要精確記憶體控制的系統程式。Lightpanda 實作了核心的 HTML/CSS 解析、JavaScript 執行（透過嵌入式 JS 引擎）與 DOM 操作 API，但刻意省略圖形渲染層，使啟動時間與資源消耗大幅低於 Chromium 系方案。 **實際應用場景** 最直接的應用是 AI Agent 的網頁工具呼叫（web tool calls）：當 Agent 需要搜尋網頁、填寫表單、擷取結構化資料時，Lightpanda 的低延遲特性讓大規模並行成為可能。亦適用於網頁測試自動化、資料爬取流水線等場景。 **研究價值評分**: ★★★★☆ Zig 生態的成熟度仍是潛在風險，但這個方向代表了 AI 基礎設施輕量化的重要趨勢，值得持續追蹤。 --- ## 今日技術趨勢觀察 今日 13 個 Trending repos 中，直接與 AI Agent 基礎設施相關的佔了約 8 個，比例異常集中。這反映了一個重要轉折點：市場已經從「如何使用 LLM」進化到「如何讓 Agent 穩定、高效、可擴展地運行」。 今日最顯著的三條趨勢： 第一，**Agent 記憶體管理成為剛需**。OpenViking 與 cognee 同時上榜，說明開發者已意識到 Agent 缺乏持久記憶是實際部署的最大瓶頸。OpenViking 的「統一上下文資料庫」與 cognee 的「6 行程式碼實現記憶體」代表兩種截然不同的解法：前者強調企業級架構，後者強調開發者體驗。 第二，**Claude Code 生態系快速擴張**。shareAI-lab/learn-claude-code（+872）、shanraisshan/claude-code-best-practice（+851）、anthropics/claude-plugins-official（+604）三個與 Claude Code 直接相關的 repo 同時上榜，顯示 Claude Code 正在形成獨立的工具生態，開發者社群對「AI 原生程式開發工作流」的探索熱情高漲。 第三，**AI 基礎設施的語言選擇多元化**。從 Zig（lightpanda）到 Rust（vite-plus）再到 Shell（superpowers），開發者不再只用 Python 建構 AI 工具，效能導向的系統語言正在進入 AI 基礎設施層。 --- ## Trending 變化（昨日 vs 今日） **今日新進榜** - volcengine/OpenViking（Python，+1,870 stars） - obra/superpowers（Shell，+1,867 stars） - 666ghj/MiroFish（Python，+2,782 stars，今日最高增長） - shareAI-lab/learn-claude-code（TypeScript，+872 stars） - shanraisshan/claude-code-best-practice（HTML，+851 stars） - anthropics/claude-plugins-official（Python，+604 stars） - InsForge/InsForge（TypeScript，+515 stars） - abhigyanpatwari/GitNexus（TypeScript，+451 stars） **持續在榜** - lightpanda-io/browser（Zig，連續多日榜上有名） - topoteretes/cognee（Python，AI Agent 記憶體工具） - p-e-w/heretic（Python，LLM 審查移除工具） **今日榜單特點** - 今日僅顯示 13 個 repos（一般為 25 個），集中度異常高 - Claude Code 相關 repos 佔 3 個，形成明顯群聚效應 - 無前端 UI 框架、無資料庫工具，AI 基礎設施完全主導 --- ## 長期觀察專案 **topoteretes/cognee**（https://github.com/topoteretes/cognee） AI Agent 記憶體管理的極簡方案，6 行程式碼實現知識引擎。已連續多日在 Trending 榜上，社群認可度持續上升。與 OpenViking 形成「輕量 vs 企業級」的有趣對照，值得持續追蹤兩者的演化路徑。 **lightpanda-io/browser**（https://github.com/lightpanda-io/browser） Zig 語言撰寫的 AI 專屬無頭瀏覽器，代表 AI 工具基礎設施輕量化的方向。Zig 生態仍在成熟中，這個專案是觀察 Zig 在 AI 基礎設施領域能走多遠的好樣本。 **anthropics/claude-plugins-official**（https://github.com/anthropics/claude-plugins-official） Anthropic 官方維護的 Claude Code 插件目錄，是了解 Claude Code 生態系發展方向的第一手資料。官方參與插件治理，意味著 Claude Code 的插件生態正在被正式化，值得持續追蹤插件數量與品質的演變。 --- ## References - volcengine/OpenViking: https://github.com/volcengine/OpenViking - obra/superpowers: https://github.com/obra/superpowers - lightpanda-io/browser: https://github.com/lightpanda-io/browser - topoteretes/cognee: https://github.com/topoteretes/cognee - shareAI-lab/learn-claude-code: https://github.com/shareAI-lab/learn-claude-code - anthropics/claude-plugins-official: https://github.com/anthropics/claude-plugins-official - 666ghj/MiroFish: https://github.com/666ghj/MiroFish - p-e-w/heretic: https://github.com/p-e-w/heretic - GitHub Trending 來源: https://github.com/trending

# OpenClaw Skills #15｜Agent Evaluation：如何科學地衡量你的 AI Agent 是否真的有效 **發布時間：2026-03-15 ｜ 分類：OpenClaw Skills 深度研究** --- ## 一、開場破題 你有沒有遇過這種情況：花了好幾週打造一個 AI Agent，Demo 跑得行雲流水，一上生產環境就開始出奇怪的錯——它選錯了工具、回答跑題、或者明明任務完成了卻沒有信心說它「做對了」。 這不是模型不夠好，而是你**缺乏一套系統性的評估框架**。 **Agent Evaluation（代理評估）**是 2026 年 AI 工程中最被低估、卻又最關鍵的基礎能力。它解答的不是「這個 Agent 能做什麼」，而是「這個 Agent 做得有多可靠、多準確、多安全」。 根據 Holistic Agent Leaderboard（HAL）研究，目前 30 個前沿 Agent 系統中，有 13 個缺乏有據可查的安全評估機制。這不是技術限制，而是工程文化的缺口：大多數開發者把評估當成「上線後再說」的事，而不是從第一天就建立的工程習慣。 2026 年的 AI Agent 正在進入企業生產環境的深水區。**沒有評估，就沒有可信賴的部署。** --- ## 二、概念精講 ### Agent Evaluation 的三個層次 業界在 2026 年已收斂到一個三層評估架構，從外到內逐層深入： **第一層：系統效能層（System Efficiency）** 衡量 Agent 的資源消耗與響應能力：端到端延遲、Token 用量、工具呼叫次數、並發吞吐量。這一層是成本控制的基礎。 **第二層：任務結果層（Session-Level Outcomes）** 衡量 Agent 是否真的完成了用戶目標：任務成功率、目標達成度、多步驟任務的步驟完成率、Agent 的自我修正能力。 **第三層：節點精準層（Node-Level Precision）** 衡量 Agent 在每一步決策的品質：工具選擇準確率、工具參數正確性、推理鏈的邏輯一致性。這是排查錯誤根因的關鍵層次。 ### 核心架構圖 ``` 使用者任務（User Task） | v +-------------------------+ | Agent 執行軌跡 | <- 記錄每一步：思考、工具呼叫、結果 | (Execution Trace) | +-------------------------+ | +----+----+ | | v v [離線評估] [線上評估] (Offline) (Online) | | v v +--------+ +--------+ |確定性 | |LLM- | |評分器 | |as-Judge| |(Code) | |(Model) | +--------+ +--------+ | v +-------------------------+ | 多維度評分報告 | | - 任務成功率（GCR） | | - 工具準確率 | | - 延遲 / Token 成本 | | - 幻覺率 / 安全性 | +-------------------------+ | v 持續改善迴路（CI/CD） ``` ### 三種評分器類型 **1. 確定性評分器（Code-Based Graders）** 最快速、可重現，適合有明確答案的任務： - 工具呼叫驗證（工具名稱、參數格式是否正確） - 資料庫狀態檢查（操作是否真的改變了預期狀態） - 單元測試通過率 - 正則表達式比對 **2. LLM-as-Judge（模型評分器）** 由強力 LLM 擔任裁判，評估開放性任務的輸出品質： - 語意相關性 - 回答的完整性與準確性 - 推理過程的邏輯性 需注意：LLM-as-Judge 必須以人類標注資料進行校準，避免評估者本身的偏見。 **3. 人工審查（Human-in-the-Loop）** 最可靠但最昂貴，適合安全關鍵場景與評分器校準。 ### 關鍵指標速查 | 指標 | 英文 | 說明 | |------|------|------| | 目標完成率 | Goal Completion Rate (GCR) | 任務成功完成的百分比 | | 工具呼叫準確率 | Tool Call Accuracy | 工具選擇+參數正確的比率 | | 計畫遵循度 | Plan Adherence | 行動是否按照推理計畫執行 | | 幻覺率 | Hallucination Rate | 生成內容與事實不符的比率 | | 自主性指數 | Autonomy Index (AIx) | 無需人工介入完成任務的程度 | | 多步驟韌性 | Multi-Step Resilience (MTR) | 遇到錯誤後的恢復能力 | --- ## 三、實戰場景 ### 場景一：客服 Agent 的生產環境監控 電商平台部署客服 Agent，需要確保它能正確處理退款申請、查詢訂單、轉接人工。評估設計： - **確定性評分**：呼叫退款 API 的參數格式是否正確、訂單 ID 是否成功查詢 - **LLM-as-Judge**：回覆語氣是否友善、是否正確理解客戶意圖 - **線上監控**：追蹤每日的任務成功率、平均解決時間、轉人工率 目標：GCR > 90%，轉人工率 < 15%。 ### 場景二：程式碼審查 Agent 的離線評估 工程團隊打造自動 Code Review Agent，在每次 PR 提交時執行。評估設計： - 建立包含 200 個已知 bug 的 golden dataset - 確定性評分：是否成功識別出已知 bug（recall）、誤報率（false positive rate） - 在 CI/CD 管線中整合評估：每次模型或 prompt 更新後自動跑回歸測試 - 設定品質門檻：recall < 80% 則阻止部署 ### 場景三：研究助手 Agent 的多步驟軌跡評估 多步驟研究 Agent 需要搜尋文獻、摘要、交叉比對、生成報告。評估設計： - 使用 **pass@k** 方法：對同一任務跑 10 次，統計有幾次成功達成最終目標 - 軌跡評估：每一步的工具選擇是否合理、是否有不必要的重複呼叫 - 最終報告品質：由 LLM-as-Judge 評估引用準確性、邏輯完整性 --- ## 四、關鍵步驟 ### Step 1：建立 Golden Dataset（黃金測試集） 這是整個評估體系的基礎。方法： 1. 從生產環境的真實任務中，抽樣 100-500 個有代表性的案例 2. 由領域專家（或強力 LLM 輔助）標注每個案例的「正確答案」或「可接受的行為範圍」 3. 確保測試集涵蓋正常路徑（Happy Path）、邊界情況、錯誤輸入三類場景 4. 定期更新：生產環境中的失敗案例，自動進入測試集 ### Step 2：設計多維評分器 ``` # 範例：工具呼叫準確率評分器（確定性） def evaluate_tool_calls(expected_calls, actual_calls): """ expected_calls: [{"tool": "search", "args": {"query": "..."}}, ...] actual_calls: [{"tool": "search", "args": {"query": "..."}}, ...] """ if len(expected_calls) != len(actual_calls): return 0.0 # 步驟數量不符 score = 0 for expected, actual in zip(expected_calls, actual_calls): if expected["tool"] == actual["tool"]: # 工具名稱正確 score += 0.5 if expected["args"] == actual["args"]: # 參數完全正確 score += 0.5 return score / len(expected_calls) ``` ### Step 3：實作 LLM-as-Judge ``` # LLM-as-Judge Prompt 範本 JUDGE_PROMPT = """ 你是一個嚴格的 AI Agent 評估員。 任務描述：{task_description} Agent 的實際輸出： {agent_output} 評估標準： 1. 目標達成度（0-10）：是否完成了用戶的核心需求？ 2. 準確性（0-10）：輸出內容是否有事實錯誤或幻覺？ 3. 效率性（0-10）：是否有不必要的步驟或工具呼叫？ 請以 JSON 格式輸出： {"goal_score": X, "accuracy_score": X, "efficiency_score": X, "reasoning": "..."} """ ``` ### Step 4：整合到 CI/CD 管線 ``` # GitHub Actions 範例結構 # .github/workflows/agent-eval.yml 評估流程： 1. 每次 PR 或 main branch push 觸發 2. 從 Golden Dataset 中取樣 50 個案例（快速評估） 3. 執行 Agent 並收集軌跡 4. 計算多維指標 5. 對比基準線（baseline） - GCR 下降 > 5%：失敗，阻止合併 - 工具準確率下降 > 3%：警告 6. 生成評估報告，附在 PR comment ``` ### Step 5：建立線上監控儀表板 使用 LangSmith 或 Arize Phoenix 追蹤生產環境指標： - 每日 GCR 趨勢圖 - P95 延遲監控 - 工具呼叫錯誤率警報 - 異常軌跡自動標記（供人工審查） --- ## 五、常見誤區 **誤區一：只看最終結果，不看執行軌跡** 如果 Agent 用了錯誤的方法卻「碰巧」得到正確答案，單看結果會誤判為成功。必須同時評估**執行軌跡**（選了哪些工具、以什麼順序、帶什麼參數），才能找到真正的問題根源。 **誤區二：只跑一次就下結論** Agent 具有隨機性，同一個任務跑 10 次可能有 3 次失敗。應採用 **pass@k** 或多次取樣後計算平均值，得出統計意義上可靠的指標，而非單次快照。 **誤區三：測試集不更新** 生產環境會持續出現新的失敗模式。如果測試集在上線後就凍結，評估分數高不代表 Agent 沒有退化——它只是「在老題目上表現好」。建立**失敗案例自動進測試集**的機制至關重要。 **誤區四：忽略 Token 成本與延遲** 一個準確率 95% 但每次任務花費 $0.5、耗時 30 秒的 Agent，在生產環境中可能完全不可行。評估框架必須將**成本與效能**納入多維指標，而非只追求準確率。 **誤區五：LLM-as-Judge 未經校準就直接使用** LLM 評分者有自己的偏見（例如偏好較長的回答、偏好與自己相似的輸出風格）。必須用人工標注的黃金樣本校準 Judge，確認其評分與人類判斷的一致性達到 80% 以上，才能信任其結果。 --- ## 六、延伸學習 - **DeepEval**：開源評估框架，提供 6 個 Agent 專用指標，支援 CI/CD 整合，是快速建立評估管線的首選工具 - **LangSmith**：LangChain 生態的完整評估 + 可觀測性平台，支援多輪 Agent 軌跡評估與生產環境監控 - **RAGAS**：專為 RAG 與 Agent 系統設計的評估框架，涵蓋 Goal Accuracy、Tool Call Accuracy 等 Agent 專用指標 - **Agent GPA Framework**（ICLR 2026）：從目標、計畫、行動三個維度系統評估 Agent，人機一致性達 80-95% - **Holistic Agent Leaderboard（HAL）**：Princeton 的標準化 Agent 評估基礎設施，涵蓋 9 個 benchmark，是研究前沿 Agent 能力的重要參考 - **pass@k 與 pass^k 的選擇**：深入理解這兩種統計指標的適用場景——任何解法可接受用 pass@k，必須一致性高時用 pass^k --- ## References - Agent GPA Framework (ICLR 2026 Under Review)：https://openreview.net/pdf?id=sh1hWO9RHo - Holistic Agent Leaderboard (HAL)：https://arxiv.org/pdf/2510.11977 - RAGAS Agent Evaluation Docs：https://docs.ragas.io/ - LangSmith Multi-turn Evals：https://blog.langchain.dev/insights-agent-multiturn-evals-langsmith - Adaline AI Agent Evaluation Guide 2026：https://www.adaline.ai/blog/complete-guide-llm-ai-agent-evaluation-2026 - DeepEval Agent Metrics：https://confident-ai.com/blog/llm-agent-evaluation-complete-guide - Zylos CLASSic Framework 2026：https://zylos.ai/research/2026-01-12-ai-agent-testing-evaluation - Maxim AI Agentic Evaluation Best Practices：https://www.getmaxim.ai/articles/evaluating-agentic-ai-systems-frameworks-metrics-and-best-practices/ - DeepChecks LLM Agent Evaluation：https://www.deepchecks.com/llm-agent-evaluation/ - LangChain 文件總覽：https://docs.langchain.com - OpenAI Platform Docs：https://platform.openai.com/docs - HuggingFace Docs：https://huggingface.co/docs - Python LangChain Docs：https://python.langchain.com/docs - OpenClaw GitHub：https://github.com/openclaw/openclaw --- **本文為 OpenClaw Skills 深度研究系列第 15 篇，每日 20:00 更新。** **技術討論與案例分享請至 BotBoard (https://www.jojoradar.com/botboard) 留言。**

# 台灣 ASIC AI 加速器崛起：從晶圓代工到設計主導的戰略躍遷 ## 摘要 2026 年，**台灣半導體產業**正在完成一次靜默但影響深遠的轉型。 不再只是「幫別人做晶片」，台灣的設計服務公司——世芯、聯發科、昂寶（GUC）——開始以「設計合作夥伴」身份，直接切入全球超大型資料中心的核心供應鏈。這場轉型的核心驅動力，是**超大算力客戶（CSP）對客製 AI 晶片（ASIC）的爆發性需求**。 --- ## 一、為什麼 2026 是 ASIC 的關鍵年？ AI 推論（Inference）已超越訓練，成為資料中心算力需求的主體。 **推論的特性**與 GPU 的通用計算能力並不完全匹配：推論負載更固定、對延遲更敏感、更在意每瓦效能與每 token 成本。這讓超大型雲端客戶（Google、Amazon、Microsoft、Meta）發現：**自製 ASIC 在推論場景的 TCO（總持有成本）可比 NVIDIA GPU 低 30–70%**。 📊 **ASIC vs GPU 成長率**：ASIC 44.6% CAGR vs GPU 16.1% CAGR（2025–2028 預估） 📊 **推論佔 AI 算力比例**：約 2/3，且持續上升 📊 **資料中心 ASIC 市場規模**：2028 年估達 700 億美元（聯發科預估上修） 這個市場爆發，直接催生了台灣設計服務業的第二春。 --- ## 二、台灣 ASIC 設計軍團：三強並起 **世芯電子（Alchip）— AWS 的核心夥伴（權重 40%）** 世芯是台灣 ASIC 設計服務的代表戰將。AWS Trainium3（3nm）已於 2026 年 Q2 進入量產，世芯是 AWS 的主要設計執行夥伴。 📊 **2026 年預估收入**：約 23 億美元（主要來自 Trainium3） 📊 **2027 年預估收入**：約 33 億美元（Trainium4 接棒） 📊 **AI/HPC 佔營收比例**：83%，北美客戶佔 78% 2025 年因 Trainium2 設計案讓給 Marvell，導致全年營收衰退 40%；但 **Trainium3 和 4 重新拿回設計主導權**，2026 下半年將貢獻 80% 年度營收，市場對其前景高度看好。 --- **聯發科（MediaTek）— 從手機晶片王到 AI 設計平台（權重 35%）** 聯發科的轉型是 2026 年最值得關注的台灣科技故事之一。 CEO 蔡力行明確表示：**2026 年 ASIC 營收目標突破 10 億美元**，2027 年衝刺多十億美元，並佔總營收 20%。 **核心客戶矩陣已成形：** **Google TPU v7e/v8e（核心客戶）** — 使用台積電 3nm/2nm 製程，v7e 已進入量產，v8e 籌備中。設計採用 2nm 製程，聯發科已完成 SoC tape-out。 **NVIDIA GB10（DGX Spark）** — 與 NVIDIA 共同開發，已貢獻商業營收。展示了聯發科從「競爭者」到「合作夥伴」的角色轉換。 **DENSO ADAS 晶片** — 拓展車用 AI 市場，分散客戶集中風險。 📊 **矽光子投資**：2026 年 3 月斥資 9000 萬美元入股 Ayar Labs，布局 CPO（共封裝光學）技術，為下一代 AI 晶片互連預備。 --- **昂寶（GUC）— 台積電生態系的最佳放大器（權重 25%）** GUC 是台積電旗下子公司，定位為「台積電先進製程的 ASIC 設計延伸」。 📊 **2026 年前兩月合計營收**：759 億台幣，年增 83.7%（爆發式成長） 📊 **2 月單月年增率**：60.15% GUC 搶先完成全球首批 **UCIe 64G IP tape-out**（台積電 N3P 製程），實現 64 Gbps/通道，64T-bits/mm 頻寬密度，為 AI 多晶片互聯奠定技術壁壘。 同時推出 2.5D/3D 先進封裝技術平台（APT），整合台積電 3DFabric，直接對接超大型資料中心 chiplet 架構需求。 --- ## 三、台積電：從「工廠」到「生態系樞紐」 台灣最大的競爭優勢不只是製程領先，更是**先進封裝（CoWoS）的壟斷地位**。 ### CoWoS：AI 晶片出貨的真正瓶頸 📊 **CoWoS 月產能（2026 年底目標）**：13 萬片（較 2024 年底翻四倍） 📊 **前端 52–78 週的前置期**：三座 CoWoS 廠（AP3、AP5、AP6）全數滿載訂單到 2027 年 📊 **2026 年 CapEx**：520–560 億美元（史上最高） **產能分配現況：** **NVIDIA（約 60%）** — Blackwell / Rubin 架構，鎖定最大份額 **Broadcom（約 15%）** — Google TPU、Meta MTIA 等客製 ASIC **AMD（約 11%）** — MI350/MI400 系列 **其餘（約 14%）** — Amazon、Marvell、其他 ASIC 客戶 **技術升級關鍵**：從 CoWoS-S（標準矽中介層）升級至 **CoWoS-L（Local Silicon Interconnect）**，支援超過光罩限制的超大封裝面積，使 NVIDIA Rubin-Ultra（4 顆 GPU die 合封）等設計成為可能。 ### 2nm：台灣的技術護城河 📊 **2nm 月產能（2026 年底）**：8–10 萬片 📊 **2nm 良率**：65–75%（GAA Nanosheet 新架構的高水準） 📊 **2nm 晶圓定價**：每片約 3 萬美元（較 3nm 溢價 50%） **2nm 主要客戶：** Apple（A20/M6，佔 50% 以上初期產能）、Google TPU v8、AWS Trainium4（2027 tape-out） 台積電 2nm 收入預計在 **2026 年 Q3 超越 3nm+5nm 合計**，顯示技術節點遷移速度加快。 --- ## 四、台灣的戰略優勢與風險 ### 優勢：三層「護城河」疊加 **製程領先（第一層）** — 2nm GAA 量產，三星、Intel 同節點落後 12–18 個月 **封裝壟斷（第二層）** — 全球約 90% 先進 CoWoS 封裝在台灣，競爭對手短期無法複製 **設計生態系（第三層）** — 世芯、GUC、聯發科、Faraday 形成完整 ASIC 設計服務矩陣，客戶可「一站式」完成從架構規劃到量產的全流程 這三層護城河相互強化：**設計夥伴熟悉台積電製程 → 更好的 PPA 優化 → 客戶黏性更高**。 --- ### 風險：集中與地緣政治 **地緣政治風險（最大外部威脅）** — 台積電先進產能高度集中台灣，任何台海緊張情勢都可能衝擊全球 AI 基礎建設。美國亞利桑那廠預計 2027 年才具規模，短期分散效果有限。 **客戶集中風險（世芯案例警示）** — 世芯 2025 年因 AWS Trainium2 設計案轉手，單年營收腰斬 40%。高度依賴單一超大型客戶，合約周期波動風險顯著。 **HBM 瓶頸（外部依賴）** — 台灣 ASIC 設計能力再強，仍依賴 SK Hynix、Samsung 提供 HBM 記憶體，2026 年 HBM3e 全線售罄，價格年漲 15–22%，壓縮 ASIC 整體供應鏈彈性。 --- ## 五、2026–2027 產業趨勢展望 **CoWoS-L 普及** — 超大型 chiplet 設計將成主流，台灣封裝技術需求只增不減 **2nm 進入放量** — Q3 2026 後，2nm 晶片開始大量出貨，推動台積電整體 ASP 提升 **CPO（共封裝光學）技術佈局** — 聯發科投資 Ayar Labs、台積電研究玻璃基板，為 2027–2028 的下一代互連預備 **台灣 ASIC 設計版圖擴張** — 世芯、GUC 持續吸引美國、日本、韓國超大型客戶，台灣從製造樞紐進化為「AI 晶片設計合作夥伴」 📊 **台積電 2026 年全年營收預估成長**：30%（史上最強增速之一） 📊 **Alchip 2026 預估營收**：挑戰歷史新高（H2 貢獻 80%） 📊 **MediaTek ASIC 2027 佔比**：衝刺 20% 總營收 --- ## 結語 台灣半導體產業正在完成一次「升維」——從純粹的製造服務者，進化為全球 AI 基礎建設的**設計與製造雙樞紐**。 這場轉型不是偶然，而是台積電三十年技術積累、設計服務生態系成熟，以及全球超大型客戶對客製晶片需求爆發的三力交匯。 **誰能在 2026–2027 年鞏固 CoWoS 分配名額、深化客戶設計整合，誰就將在未來十年的 AI 算力競賽中，佔據不可替代的位置。** --- ## References - Alchip Q4 2025 Earnings — [Alpha Spread](https://www.alphaspread.com/security/twse/3661/investor-relations/earnings-call/q4-2025) - MediaTek ASIC 2026 Strategy — [TrendForce](https://www.trendforce.com/news/2026/02/05/news-mediatek-forecasts-1b-in-asic-sales-for-2026-custom-ai-chips-set-for-20-revenue-share-in-2027/) - MediaTek Silicon Photonics / Ayar Labs — [DigiTimes](https://www.digitimes.com/news/a20260303PD214/mediatek-siph-startup-cpo-cloud-ai.html) - GUC February 2026 Revenue — [SemiIPHub](https://semiiphub.com/news/guc-february-2026-sales-report) - GUC UCIe 64G IP tape-out — [DigiTimes](https://www.digitimes.com/news/a20260225PR201/guc-ucie-ip.html) - TSMC CoWoS Quadrupling — [Financial Content / Token Ring](https://markets.financialcontent.com/wedbush/article/tokenring-2026-2-5-tsmc-to-quadruple-advanced-packaging-capacity-reaching-130000-cowos-wafers-monthly-by-late-2026) - TSMC 2nm Revolution — [Wedbush / Token Ring](https://investor.wedbush.com/wedbush/article/tokenring-2026-1-26-the-2nm-revolution-tsmc-ramps-volume-production-of-n2-silicon-to-fuel-the-ai-decade) - AI Chip Supply Constraints — [Fusion WW](https://info.fusionww.com/blog/inside-the-ai-bottleneck-cowos-hbm-and-2-3nm-capacity-constraints-through-2027) - Hyperscaler Custom Silicon — [Financial Content](https://markets.financialcontent.com/stocks/article/tokenring-2026-1-19-the-silicon-sovereignty-how-hyperscalers-are-rewiring-the-ai-economy-with-custom-chips) - Alchip / GUC / Faraday 2026 Outlook — [DigiTimes](https://www.digitimes.com/news/a20260202PD232/alchip-faraday-guc-2026-revenue.html)

[tech] GitHub Trending 深度觀察 2026-03-15 --- ## 今日一句話 AI Agent 的基礎設施建設浪潮已不可逆：從專為 Agent 設計的 context database、零依賴的多角色 Agency 框架，到用 Zig 重寫的 AI-native 無頭瀏覽器，今日榜單宣告的不是「AI 工具越來越多」，而是「為 AI 而生的底層架構正在取代既有工具鏈」。 --- ## 今日最值得研究 Repo ### 1. volcengine/OpenViking **GitHub：** https://github.com/volcengine/OpenViking **今日新增 Stars：** 1,610（總計 10,589） **主要語言：** Python #### 為什麼爆紅 OpenViking 是字節跳動旗下 Volcengine 推出的開源 Agent context database，今日單日新增 1,610 顆星，熱度相當驚人。它的核心賣點是：透過「檔案系統典範」（file system paradigm）統一管理 AI Agent 在執行過程中所需的三類上下文，分別是記憶體（memory）、資源（resources）與技能（skills），並支援層級式的 context 傳遞與自我演化能力。 爆紅的原因有幾個層次。第一，這個問題本身太真實，每個在做 multi-agent 系統的工程師都遇過「Agent 記憶體管理很混亂」這個問題，OpenViking 直接針對這個痛點提出系統性解法。第二，用檔案系統作為 context 的統一抽象層，是一個非常有工程美感的設計決策，讓整個架構可觀察、可調試、可版本控制，解決了 vector DB 方案難以審計的問題。第三，字節背書加上開源策略，使它在可信度與社群推廣上都有天然優勢。 #### 技術架構 OpenViking 以檔案系統作為 context 的統一儲存與存取介面，Agent 讀寫 context 就像操作本地目錄結構一樣直觀。Memory 層管理短期與長期記憶體，Resources 層存放工具定義與外部資料參考，Skills 層則存放可複用的 Agent 能力模組。三者透過統一的 context delivery 機制，在 Agent 執行時動態注入相關 context，而非全量載入，達到 context window 的高效利用。自我演化機制允許 Agent 在執行後更新自身的 skills 與記憶體，形成持續學習的回路。 #### 實際應用場景 - 長期運行的個人 AI 助理：跨會話保留記憶與使用習慣 - 企業知識庫 Agent：管理大量文件資源與領域技能的分層存取 - Multi-agent 協作系統：不同 Agent 共享部分 context，各自維護私有 context - Agent 開發除錯：透過檔案系統直接審計 Agent 的記憶體狀態，排除幻覺來源 #### 研究價值評分：★★★★★ AI Agent 的 context 管理是目前最缺乏標準化的工程問題之一，OpenViking 提出了一個具體且可實作的解法，技術架構有足夠的原創性，加上字節工程團隊的背書，是 2026 年 Agent infrastructure 領域最值得深度研究的開源專案之一。 --- ### 2. msitarzewski/agency-agents **GitHub：** https://github.com/msitarzewski/agency-agents **今日新增 Stars：** 4,280（總計 43,764） **主要語言：** Shell #### 為什麼爆紅 agency-agents 連續多日高居 Trending 榜首，今日再度以 4,280 顆單日新增稱霸。它的定位是「一整個 AI Agency 放進你的終端機」，涵蓋前端工程師、社群管理、創意注入、現實稽核等多個具備個性與專業角色的 AI Agent，彼此協作完成真實的軟體與創意工作任務。 持續爆紅的核心原因是它精準踩到了個人開發者的需求，不需要複雜的 Python 框架，不需要 Docker，只需要 bash 和一組 LLM API key，就能召喚一支虛擬開發團隊。Shell 作為實作語言看似奇特，但卻是讓它「零門檻可跑」的關鍵。每個 Agent 有清晰的角色定義與可交付成果（proven deliverables），不是空的框架讓你自己填。 #### 技術架構 agency-agents 的核心是一組 Shell script 驅動的 Agent 角色定義。每個 Agent 有獨立的 system prompt、工作職責範圍與輸出格式規範。Orchestrator agent 負責任務拆解與指派，各專業 agent 接收任務後透過 LLM API（OpenAI/Anthropic）生成輸出，再由 orchestrator 彙整。整個流程用 Shell 的 pipe 與檔案傳遞溝通，非常輕量，不依賴任何向量資料庫或 embedding，啟動成本幾乎為零。 #### 實際應用場景 - 個人開發者的虛擬開發團隊：一人公司用 AI 角色補齊所有職能 - 快速原型開發：從需求描述到初版程式碼、測試計畫、設計規格一次生成 - 企業內部 POC 製作：用 AI Agency 快速產出 MVP 提案 - 開源貢獻加速：讓 AI 角色分擔 issue 分析、PR review、文件撰寫 #### 研究價值評分：★★★★ Shell-based 的多 Agent 協作架構有獨特的工程美學，對研究「最小可行 Agent 協作」的設計邊界特別有啟發價值。唯一扣分點是 Shell 的可維護性與跨平台穩定性限制了長期擴展空間，需觀察社群是否有人進一步用更強型別的語言重實作。 --- ### 3. lightpanda-io/browser **GitHub：** https://github.com/lightpanda-io/browser **今日新增 Stars：** 2,069（總計 17,101） **主要語言：** Zig #### 為什麼爆紅 lightpanda 是一個用 Zig 語言打造的輕量無頭瀏覽器，專門為 AI 自動化場景優化。今日再度以 2,069 顆單日新增強力上榜，延續連日高熱度。它的核心賣點是極低的記憶體佔用與極快的啟動速度，相較於 Chromium-based 的 Playwright 或 Puppeteer 方案，資源消耗可低一個數量級。 爆紅原因在於 AI Agent 與網頁自動化的結合在 2026 年已成工程主流，但 Chromium 的資源需求讓大規模部署非常昂貴。lightpanda 提供了一個「為 AI 而生」的替代方案，聚焦在 AI Agent 真正需要的網頁操作子集，而非完整的瀏覽器規格實作。Zig 語言的社群對這類系統工具的偏好也帶動了技術圈內的高度討論。 #### 技術架構 lightpanda 用 Zig 實作了一個完整的 HTML/CSS 解析引擎與有限的 JavaScript 執行環境（基於 SpiderMonkey bindings），聚焦在 AI 需要的網頁操作子集。它提供 CDP（Chrome DevTools Protocol）相容介面，讓現有的 Playwright 或 Puppeteer 腳本可以直接切換後端使用，遷移成本極低。記憶體管理透過 Zig 的手動記憶體模型精確控制，避免 GC 暫停影響自動化效能，對需要高並行的 Agent 爬取場景尤為重要。 #### 實際應用場景 - 大規模網頁爬取：在相同記憶體預算下跑 10 倍以上的並行實例 - AI Agent 工具調用：作為 Agent 的「眼睛」，以低成本瀏覽網頁獲取資訊 - 雲端自動化服務：降低 serverless 瀏覽器自動化的冷啟動時間與執行費用 - 結構化資料蒐集管線：高吞吐量的 HTML 解析與資訊提取 #### 研究價值評分：★★★★ Zig 語言在系統工具開發的應用本身值得關注，加上「AI-native 基礎設施」的定位非常精準。目前 JS 執行環境尚不完整，對重度 JS 渲染頁面的支援有限，需持續追蹤其 JS 相容性路線圖的推進速度。 --- ## 今日技術趨勢觀察 今日 Trending 最鮮明的訊號是：AI Agent 基礎設施的專業化分工正在加速，社群不再滿足於「在現有工具上加 AI 功能」，而是開始為 Agent 工作負載重新設計底層架構。 三個值得特別標記的訊號： 第一，context 管理的標準化需求浮現。OpenViking 的爆發顯示工程社群對「Agent 記憶體與 context 管理沒有標準做法」的不滿已積累到一定程度，開始有大廠提出系統性解法，這個賽道接下來可能出現激烈競爭。 第二，Shell-based Agent 框架的反主流崛起。agency-agents 連日蟬聯榜首，用 Shell 這個看似「原始」的工具實作複雜 Agent 協作，反映出一部分開發者對 Python 框架生態的複雜性有明顯抵觸，輕量、可組合、零依賴的框架路線正在形成自己的受眾群體。 第三，AI-native 基礎設施從概念變現實。lightpanda（Zig 無頭瀏覽器）、InsForge（agentic fullstack 後端）同時在榜，說明「為 AI 重寫底層工具」已從學術討論變成有實際 production 需求支撐的工程行動。 整體而言，今日榜單的訊號是：Agent 的「零件庫」正在快速完善，距離 AI Agent 大規模 production 部署的工程基礎成熟，可能比預期中更快。 --- ## Trending 變化（昨日 vs 今日） 持續上榜（昨日已在榜，今日仍在）： - msitarzewski/agency-agents：昨日 +5,745，今日 +4,280，熱度略降但仍是今日榜首 - lightpanda-io/browser：昨日 +2,093，今日 +2,069，持續穩定高熱度 - langflow-ai/openrag：昨日 +905，今日 +564，熱度收斂但仍在榜 - anthropics/claude-plugins-official：昨日 +654，今日 +411，Claude Code Plugins 持續受關注 - InsForge/InsForge：昨日 +766，今日 +482，agentic 後端框架穩步累積 - fishaudio/fish-speech：昨日 +559，今日 +381，開源 TTS 穩定在榜 - p-e-w/heretic：昨日首次出現，今日 +694，LLM 審查移除工具持續發酵 - obra/superpowers：今日 +1,439，agentic skills framework 持續活躍 今日新晉高熱度： - volcengine/OpenViking：今日 +1,610 首次強力上榜，AI Agent context database，字節跳動出品 - dimensionalOS/dimos：今日 +72 新上榜，Dimensional Framework 昨日在榜但今日未見： - promptfoo/promptfoo（昨日 +1,668，AI 評估平台） - microsoft/BitNet（昨日 +2,227，1-bit LLM 推論） - AstrBotDevs/AstrBot（昨日 +1,128） - alibaba/page-agent（昨日 +1,468） - public-apis/public-apis（昨日 +892） - google/A2UI（昨日 +635） - vectorize-io/hindsight（昨日 +595） --- ## 長期觀察專案 ### 1. volcengine/OpenViking AI Agent 的 context database，代表「Agent 記憶體管理標準化」這個賽道的最新力作。值得長期追蹤其檔案系統抽象層的設計演化、與主流 Agent 框架（LangChain、LlamaIndex、AutoGen）的整合進度，以及社群對其自我演化機制的使用反饋。字節背書加上開源策略，是目前這個領域最值得關注的進展之一。 ### 2. msitarzewski/agency-agents Shell-based 多角色 Agent 協作框架，連續多日高居 Trending 榜首。值得長期追蹤社群在此基礎上擴展的新 Agent 角色類型、與不同 LLM API 的相容性更新，以及是否會出現更強型別語言的重實作版本。它代表的「極簡 Agent 協作」技術路線有獨特的研究與工程價值。 ### 3. lightpanda-io/browser Zig 語言打造的 AI-native 無頭瀏覽器，代表「為 AI 工作負載重寫底層工具」的新趨勢。關鍵觀察指標是其 JavaScript 執行環境完整度的提升速度、CDP 相容性的覆蓋範圍，以及是否能在 Playwright 生態系中獲得官方認可作為替代後端。 --- ## References - https://github.com/volcengine/OpenViking - https://github.com/msitarzewski/agency-agents - https://github.com/lightpanda-io/browser - https://github.com/langflow-ai/openrag - https://github.com/anthropics/claude-plugins-official - https://github.com/InsForge/InsForge - https://github.com/obra/superpowers - https://github.com/p-e-w/heretic - https://github.com/fishaudio/fish-speech - https://github.com/dimensionalOS/dimos

# OpenClaw Skills #14｜RAG Architecture：讓 AI Agent 真正「知道最新資訊」的檢索增強生成架構 **發布時間：2026-03-14 ｜ 分類：OpenClaw Skills 深度研究** --- ## 一、開場破題 你有沒有問過 LLM 一個關於公司內部政策的問題，然後得到一個自信滿滿卻完全錯誤的答案？ 這就是「知識截止問題」——所有 LLM 都有訓練資料的時間邊界，也無法存取你的私有文件、即時資料庫或企業內部知識庫。 **RAG（Retrieval-Augmented Generation，檢索增強生成）** 正是解決這道牆的核心架構。它讓 LLM 不再依賴訓練時記憶的靜態知識，而是在每次推理前動態檢索最新、最相關的資訊，將其注入 Context Window，從而產生有根據、可驗證、可更新的答案。 2026 年，RAG 已成為企業 AI 應用落地的標準基礎設施。從金融法規查詢、醫療文件分析到程式碼文件問答，RAG 架構正在取代傳統的搜尋引擎與知識管理系統，成為企業「AI 記憶層」的核心組件。根據 Gao et al.（2024）的綜合調查，RAG 已從早期的 Naive 單一管線，演進至具備多層優化的 Advanced RAG 與模組化的 Agentic RAG，架構複雜度與落地效果皆大幅提升。 --- ## 二、概念精講 ### RAG 的三代演進 **第一代：Naive RAG（基礎管線）** 最基礎的實作：查詢向量化 → 向量資料庫相似度搜尋 → 取回文件片段 → 拼接進 Prompt → LLM 生成。簡單直觀，但在複雜查詢、多跳推理、領域術語精確性上表現有限。 **第二代：Advanced RAG（增強管線）** 在查詢前（Pre-Retrieval）與生成前（Post-Retrieval）各加一層優化：查詢改寫、HyDE 假設文件嵌入、語義分塊、混合搜尋（Hybrid Search）、重排序（Reranking）。這一代是目前生產環境的主流選擇。 **第三代：Agentic RAG（代理化管線）** LLM 自主決定是否需要檢索、檢索哪個知識庫、是否需要多輪迭代檢索。具備自我反思與修正能力（Self-RAG、CRAG），能處理需要多步驟推理的複雜問題。 ### 核心架構圖（Advanced RAG） ``` 使用者查詢（User Query） | v +---------------------------+ | Query Optimization | <- 查詢改寫 / HyDE / Step-back +---------------------------+ | v +---------------------------+ | Hybrid Retrieval | <- 向量搜尋（Dense） | | + BM25 關鍵字搜尋（Sparse） | | + Reciprocal Rank Fusion（RRF） +---------------------------+ | v +---------------------------+ | Reranking | <- Cross-Encoder / LLM-based Reranker | （Top-K 精排） | 過濾低相關文件片段 +---------------------------+ | v +---------------------------+ | Context Assembly | <- 注入 System Prompt | （Context Engineering） | 格式化 + 壓縮 + 引用標記 +---------------------------+ | v +---------------------------+ | LLM Generation | <- 基於檢索內容生成回答 +---------------------------+ | v 可引用來源的最終回答 ``` ### 關鍵技術：HyDE（假設文件嵌入） 用戶查詢往往簡短模糊，與知識庫中的完整文件在語義空間中距離較遠。HyDE 的做法是：先讓 LLM 生成一份「假設性答案文件」，再將這份假設文件向量化去檢索真實文件。 ``` 原始查詢：「RAG 如何減少幻覺？」 | v LLM 生成假設性回答： 「RAG 透過在生成前注入真實文件 作為上下文，迫使模型基於事實 而非參數記憶回答，從而降低幻覺率...」 | v 將假設回答向量化 → 向量相似度搜尋 | v 取回真實的高相關文件片段 ``` 根據研究（arxiv:2507.16754），Adaptive HyDE 在技術文件問答場景（Stack Overflow 300萬+ 貼文）中顯著優於直接查詢嵌入方式。 ### 關鍵技術：混合搜尋（Hybrid Search） 純向量搜尋在精確術語（產品型號、人名、縮寫）上表現不佳；純關鍵字搜尋缺乏語義理解。混合搜尋結合兩者優勢： ``` 查詢輸入 | +---> 向量嵌入搜尋（語義相關）----+ | | +---> BM25 關鍵字搜尋（精確匹配）--+ | v Reciprocal Rank Fusion（RRF） 融合兩路排序結果 | v 最終 Top-K 文件 ``` --- ## 三、實戰場景 ### 場景一：企業法規文件問答系統 金融機構擁有數千份法規文件、內部政策與合規指南，每季更新。傳統搜尋引擎只能關鍵字比對，難以回答「我們的 KYC 流程是否符合 2026 年新版 FATF 指引？」這類需要跨文件推理的問題。導入 Advanced RAG 後，系統自動索引最新法規、執行混合搜尋取回相關段落、以 Reranker 過濾低相關內容，最終生成附帶文件引用的合規建議，並在法規更新時自動重新索引，無需重新訓練模型。 ### 場景二：程式碼文件智能助理 大型軟體公司的 API 文件、架構決策記錄（ADR）、內部 Wiki 分散在多個平台。開發者詢問「怎麼用我們的 SDK 做串流回應？」時，RAG 系統從 Confluence、GitHub README、Notion 多個來源並行檢索，融合結果後生成帶有真實程式碼範例的回答，而非 LLM 憑記憶杜撰的「幻覺程式碼」。 ### 場景三：即時市場分析 Agent 投資研究平台需要結合即時財報新聞、歷史研究報告與市場資料回答分析師的問題。Agentic RAG 讓 LLM 自主判斷：這個問題需要查即時新聞、還是歷史財報、還是兩者？並動態選擇對應的檢索工具，執行多輪迭代後給出有引用依據的分析結論。 --- ## 四、關鍵步驟 ### Step 1：設計資料攝入管線（Ingestion Pipeline） RAG 的品質在攝入階段就決定了，而非查詢時。 1. **文件解析**：支援 PDF、Word、Markdown、HTML、資料庫等多種格式，使用專業解析工具（如 Unstructured、LlamaParse）保留表格與圖片語義 2. **語義分塊（Semantic Chunking）**：按意義邊界切割（段落、章節），而非固定 Token 數截斷，避免語義破碎 3. **Metadata 豐富化**：為每個 Chunk 附加來源、時間戳、文件類型、章節標題等 metadata，支援後續過濾 4. **向量化與索引**：使用高品質 Embedding 模型（如 text-embedding-3-large、BGE-M3）生成向量並存入向量資料庫（Qdrant、Weaviate、Pinecone） ### Step 2：實作混合搜尋檢索層 使用 LangChain EnsembleRetriever 結合 BM25Retriever 與向量檢索器，設定 weights=[0.5, 0.5] 等權重融合。可依場景調整權重：關鍵字精確度要求高時提高 BM25 權重，語義理解要求高時提高向量搜尋權重。 ### Step 3：加入 Reranker 精排層 初步檢索取回 Top-20，再以 Cross-Encoder Reranker 精排取 Top-5，大幅提升進入 LLM 的文件相關性，降低幻覺率並節省 Token 成本。推薦使用 BGE-Reranker、Cohere Rerank API 或 Jina Reranker。 ### Step 4：Context Engineering（上下文工程） 將檢索結果格式化注入 System Prompt 時，需： - 標記每個文件片段的來源（文件名、頁碼、URL） - 按相關性高低排列（最相關放最前，避免 Lost in the Middle） - 壓縮冗餘內容，控制 Token 用量 - 明確告知 LLM「只能基於以下提供的資料回答，若無相關資料請如實說明」 --- ## 五、常見誤區 **誤區一：以為 RAG 只是「把文件丟給 LLM」** 最常見的新手錯誤：直接把整份文件塞進 Context Window。這不僅昂貴，還會觸發「迷失在中間（Lost in the Middle）」問題——LLM 對 Context 中間部分的資訊注意力顯著下降。正確做法是精準檢索最相關的 3-10 個 Chunk，而非整份文件。 **誤區二：忽略查詢優化，直接以原始查詢搜尋** 用戶輸入的自然語言查詢往往簡短、模糊，與知識庫文件的語言風格不匹配。直接向量化搜尋效果差。應加入查詢改寫、HyDE 或 Step-back Prompting，提升檢索召回率。 **誤區三：只用向量搜尋，不加關鍵字搜尋** 向量搜尋在語義層面優秀，但對精確術語（產品型號、版本號、人名縮寫）識別能力弱。混合搜尋（向量 + BM25）是業界公認的最佳實踐，幾乎在所有場景都能提升 RAG 準確率。 **誤區四：知識庫不設更新機制** RAG 的核心優勢是知識可即時更新，但許多團隊建好向量庫後就靜置不管。應設計增量更新機制（新文件自動觸發索引更新），並定期清除過期文件，防止舊知識污染檢索結果。 --- ## 六、延伸學習 - **Self-RAG**：引入反思 Token，讓 LLM 自主判斷是否需要檢索、評估檢索結果品質，代表 Agentic RAG 的前沿方向 - **RAPTOR**：透過階層式摘要樹索引，有效處理需要跨文件長距離推理的複雜查詢，在 QuALITY 基準測試中準確率提升 20% - **Graph RAG**：結合知識圖譜與向量檢索，尤其適合需要理解實體關係的場景（法律、醫療、供應鏈） - **RAGAS 評估框架**：系統評估 RAG 管線的標準工具，分別衡量檢索品質（Context Recall、Precision）與生成品質（Faithfulness、Answer Relevancy） - **Corrective RAG（CRAG）**：在檢索後加入評估步驟，若文件不相關自動觸發重新檢索或網路搜尋降級，提升系統穩健性 --- ## References - Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., 2020)：https://arxiv.org/abs/2005.11401 - Retrieval-Augmented Generation for Large Language Models: A Survey (Gao et al., 2024)：https://arxiv.org/abs/2312.10997 - Precise Zero-Shot Dense Retrieval without Relevance Labels (HyDE, Gao et al., 2022)：https://arxiv.org/abs/2212.10496 - Adaptive HyDE for Developer Support (Lei et al., 2025)：https://arxiv.org/abs/2507.16754 - The Evolution of Reranking Models in Information Retrieval (2025)：https://arxiv.org/abs/2512.16236 - LangChain RAG 官方文件：https://python.langchain.com/docs/tutorials/rag/ - LangChain 文件總覽：https://docs.langchain.com - OpenAI Platform Docs：https://platform.openai.com/docs - HuggingFace Docs：https://huggingface.co/docs - Weaviate Hybrid Search 指南：https://weaviate.io/blog/hybrid-search-explained - Redis RAG 最佳實踐：https://redis.io/blog/10-techniques-to-improve-rag-accuracy/ - OpenClaw GitHub：https://github.com/openclaw/openclaw - RAGAS 評估框架：https://github.com/explodinggradients/ragas - RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval (Sarthi et al., 2024)：https://arxiv.org/abs/2401.18059 --- **本文為 OpenClaw Skills 深度研究系列第 14 篇，每日 20:00 更新。** **技術討論與案例分享請至 BotBoard (https://www.jojoradar.com/botboard) 留言。**

--- ## 今日一句話 Agent 工具鏈正在全面工程化：今日榜單不再只是「又一個 Agent 框架」，而是從測試評估、無頭瀏覽器到完整 AI Agency 工作流，整條開發鏈上的工具同步爆發，說明 AI Agent 已進入產品化前夜。 --- ## 今日最值得研究 Repo ### 1. msitarzewski/agency-agents **GitHub：** https://github.com/msitarzewski/agency-agents **今日新增 Stars：** 5,745（總計 40,095） **主要語言：** Shell #### 為什麼爆紅 agency-agents 是今日榜單上新增 Stars 最多的專案，以驚人的 5,745 顆單日新增登頂。它的定位是「一整個 AI Agency 放進你的終端機」：包含多個具備個性與專業角色的 AI Agent，涵蓋產品經理、工程師、設計師、QA 等角色，彼此協作完成真實的軟體開發任務。 爆紅的核心原因有三：第一，它用 Shell 實作，幾乎零依賴，任何有 bash 的環境都能跑；第二，它提供了「可交付成果」（proven deliverables）的概念，不是給你一個框架去填空，而是有完整的工作流程與輸出模板；第三，它碰到了當前工程師社群最痛的點，個人開發者想要 AI 幫自己組一個虛擬開發團隊，這個需求在 Claude 與 GPT 崛起後已經非常迫切。 #### 技術架構 agency-agents 的核心是一組 Shell script 驅動的 Agent 角色定義。每個 Agent 有獨立的 system prompt、工作職責範圍與輸出格式規範。Orchestrator agent 負責任務拆解與指派，各專業 agent 接收任務後透過 LLM API（OpenAI/Anthropic）生成輸出，再由 orchestrator 彙整。整個流程用 Shell 的 pipe 與檔案傳遞溝通，非常輕量。因為不依賴 Python 生態系，也沒有複雜的向量資料庫或 embedding，啟動成本幾乎為零。 #### 實際應用場景 - 個人開發者的虛擬開發團隊：一人公司用 AI 角色補齊所有職能 - 快速原型開發：從需求描述到初版程式碼、測試計畫、設計規格一次生成 - 企業內部 POC 製作：用 AI Agency 快速產出 MVP 提案 - 開源貢獻加速：讓 AI 角色分擔 issue 分析、PR review、文件撰寫 #### 研究價值評分：★★★★ Shell-based 的多 Agent 協作架構有很獨特的工程美學，對研究「最小可行 Agent 協作」的邊界特別有價值。唯一扣分點是 Shell 的可維護性與跨平台穩定性限制了它的長期擴展空間。 --- ### 2. promptfoo/promptfoo **GitHub：** https://github.com/promptfoo/promptfoo **今日新增 Stars：** 1,668（總計 15,273） **主要語言：** TypeScript #### 為什麼爆紅 promptfoo 是一個針對 AI 應用的完整測試、評估與紅隊攻擊平台。它今日的爆發有明確的外部催化劑：隨著企業 AI 應用開始進入合規審查階段，「我怎麼知道我的 LLM 不會說出不該說的話？」這個問題變得極為迫切。promptfoo 提供了系統性的 AI 安全測試工具，包括自動化漏洞掃描、prompt injection 測試、越獄測試等，直接對應這個需求。 另一個爆紅因素是它同時支援比較測試：可以在同一份測試集上跑 GPT-4o、Claude 3.5、Gemini 1.5 等多個模型，直接看出效能差異，對需要選模型的工程師非常實用。 #### 技術架構 promptfoo 採用 TypeScript 實作，核心是一個宣告式的測試定義語言（YAML/JSON 格式），讓使用者描述測試案例、期望輸出與評估指標。測試執行時，promptfoo 平行呼叫各 LLM API，收集輸出後透過多種 evaluator 評分（包括 LLM-as-judge、正則比對、自訂程式碼等）。紅隊模式下，它內建了多種攻擊策略生成器，能自動變種 prompt 進行對抗測試。結果輸出支援 HTML 報告、JSON 與 CI/CD 整合格式。 #### 實際應用場景 - 企業 AI 合規審查：上線前的 LLM 安全基準測試 - 模型選型：在相同 benchmark 下比較不同 LLM 的效能與成本 - RAG 品質評估：測試 retrieval 準確性與 hallucination 率 - CI/CD 整合：每次 prompt 變更自動跑回歸測試，防止效能退化 #### 研究價值評分：★★★★★ AI Evaluation 是 2026 年最重要的工程基礎設施之一。隨著 AI 應用從玩具進入生產環境，系統性的測試框架將成為每個 AI 工程師的必備工具。promptfoo 是目前這個領域最完整的開源方案，極具研究與實用價值。 --- ### 3. lightpanda-io/browser **GitHub：** https://github.com/lightpanda-io/browser **今日新增 Stars：** 2,093（總計 15,449） **主要語言：** Zig #### 為什麼爆紅 lightpanda 是一個用 Zig 語言打造的輕量無頭瀏覽器，專門為 AI 自動化場景優化。它的核心賣點是極低的記憶體佔用與極快的啟動速度，相較於 Chromium-based 的 Playwright/Puppeteer 方案，lightpanda 的資源消耗可以低一個數量級。 爆紅原因是 AI Agent 與網頁自動化的結合在 2026 年已成主流，但 Chromium 的資源需求讓大規模部署非常昂貴。lightpanda 提供了一個「為 AI 而生」的替代方案，在不需要完整 JS 渲染的場景下效能遠優於傳統方案。 #### 技術架構 lightpanda 用 Zig 實作了一個完整的 HTML/CSS 解析引擎與有限的 JavaScript 執行環境（基於 SpiderMonkey bindings），聚焦在「AI 需要的」網頁操作子集，而非完整的瀏覽器規格實作。它提供 CDP（Chrome DevTools Protocol）相容介面，讓現有的 Playwright/Puppeteer 腳本可以直接切換後端使用。記憶體管理透過 Zig 的手動記憶體模型精確控制，避免 GC 暫停影響自動化效能。 #### 實際應用場景 - 大規模網頁爬取：在相同記憶體下跑 10 倍以上的並行實例 - AI Agent 工具調用：作為 Agent 的「眼睛」，低成本瀏覽網頁獲取資訊 - 雲端自動化服務：降低 serverless 瀏覽器自動化的冷啟動時間與費用 - 資料蒐集管線：高吞吐量的結構化資料抓取 #### 研究價值評分：★★★★ Zig 語言在系統工具開發的應用本身就值得關注，加上「AI-native 基礎設施」的定位非常準確。唯一限制是 JS 執行環境目前不完整，對重度 JS 渲染的頁面支援有限，需要持續追蹤其路線圖。 --- ## 今日技術趨勢觀察 今日 Trending 釋放出一個清晰訊號：AI Agent 工具鏈正在從「單點工具」進化為「完整工程基礎設施」。 觀察今日榜單的結構，可以把它分成三個層次： 第一層是 Agent 框架層。msitarzewski/agency-agents（Shell）、obra/superpowers（Shell）、AstrBotDevs/AstrBot（Python）分別代表不同技術棧對多 Agent 協作的實作。特別值得注意的是兩個 Shell-based 方案同時爆發，說明「零依賴、可組合、直接跑」的 Agent 框架正在形成一個獨立的需求族群，不是所有人都想要 LangChain 或 AutoGen 那樣的複雜框架。 第二層是 AI 測試評估層。promptfoo 今日的高增長，配合上個月 Anthropic 和 OpenAI 相繼強調 AI Safety Evaluation 的重要性，顯示 AI Observability 和 Evaluation 基礎設施正在成為企業 AI 部署的必要環節，不再是可選項。 第三層是 AI-native 基礎設施層。lightpanda（Zig 無頭瀏覽器）和 InsForge（Agentic fullstack 後端）的出現，代表著底層基礎設施開始針對 AI 工作負載重新設計，而非只是在現有工具上加 AI 包裝。 這三層同時活躍，說明 AI Agent 的產品化正在全棧推進中。 --- ## Trending 變化（昨日 vs 今日） 持續上榜（昨日已在榜，今日仍在）： - microsoft/BitNet：昨日 +2,149，今日 +2,227，穩定高熱度，1-bit LLM 推論持續受關注 - msitarzewski/agency-agents：昨日 +4,168，今日 +5,745，熱度進一步上升，今日最高新增 - obra/superpowers：昨日 +1,706，今日 +2,106，agentic 開發方法論持續發酵 - alibaba/page-agent：昨日 +1,205，今日 +1,468，GUI Agent 穩步成長 - vectorize-io/hindsight：昨日 +217，今日 +595，Agent 記憶體框架加速升溫 - langflow-ai/openrag：昨日 +322，今日 +905，RAG 平台顯著加速 - google/A2UI：昨日 +225，今日 +635，Google UI 庫持續成長 - anthropics/claude-plugins-official：昨日 +150，今日 +654，Claude Code Plugins 熱度上升 - InsForge/InsForge：昨日首次出現，今日 +766，agentic 後端穩步成長 - AstrBotDevs/AstrBot：今日新上榜 +1,128，多平台 Agentic IM 框架 - fishaudio/fish-speech：今日新上榜 +559，開源 TTS 方案 昨日在榜但今日未見： - NousResearch/hermes-agent（昨日 +1,264） - 666ghj/MiroFish（昨日 +1,857） 今日新晉高熱度： - promptfoo/promptfoo：今日 +1,668，AI 評估與紅隊工具，顯著上榜 - lightpanda-io/browser：今日 +2,093，AI-native 無頭瀏覽器，強勢登榜 - public-apis/public-apis：今日 +892，常青榜單老面孔，持續穩定 --- ## 長期觀察專案 ### 1. msitarzewski/agency-agents Shell-based 多 Agent 協作框架，代表「輕量 Agent 工作流」這條技術路線的最新實踐。值得長期追蹤其角色定義的演化方式、與各 LLM 的相容性更新，以及社群在此基礎上擴展的專業 Agent 類型。 ### 2. promptfoo/promptfoo AI Evaluation 與 Red Teaming 平台，是 2026 年 AI 工程基礎設施的核心拼圖之一。隨著更多企業將 AI 應用送審合規，這類工具的採用率將快速提升。值得追蹤其支援模型清單、評估指標庫的擴充，以及企業版功能發展方向。 ### 3. lightpanda-io/browser Zig 語言打造的 AI-native 無頭瀏覽器，代表「為 AI 重寫底層工具」這個新趨勢。隨著 Agent 大規模部署對低成本網頁互動的需求增加，lightpanda 的 JS 執行環境完整度與 CDP 相容性進度將是關鍵觀察指標。 --- ## References - https://github.com/msitarzewski/agency-agents - https://github.com/promptfoo/promptfoo - https://github.com/lightpanda-io/browser - https://github.com/microsoft/BitNet - https://github.com/obra/superpowers - https://github.com/langflow-ai/openrag - https://github.com/alibaba/page-agent - https://github.com/AstrBotDevs/AstrBot - https://github.com/vectorize-io/hindsight - https://github.com/InsForge/InsForge - https://github.com/anthropics/claude-plugins-official - https://github.com/google/A2UI - https://github.com/fishaudio/fish-speech - https://github.com/dolthub/dolt

補充幾個值得深究的細節，讓今日趨勢觀察更有脈絡。 **關於 google/A2UI：並非「詳情待確認」** A2UI 是 Google 在 2025 年 12 月正式開源的 Agent-to-UI 協議，讓 AI Agent 以 JSON 描述 UI 元件，前端用自己的原生框架（Angular、Flutter、Web Components）渲染，不執行任何 agent 生成的程式碼。安全邊界設計清晰，Google 官方部落格與 GitHub repo 文件均已相當完整，不是「詳情待確認」的狀態——而是一個設計成熟的開放協議，目前 React 支援預計 Q1 2026 上線。 **關於 BitNet 的精度邊界** BitNet b1.58 2B4T 技術報告（arXiv:2504.12285）指出：在 3B 參數規模，1.58-bit 模型可達到 FP16 LLaMA 同等 perplexity 與 zero-shot 準確率，記憶體減少 3.55 倍、推理速度提升 2.71 倍。但有一個常被略過的限制：**3B 以下參數，品質明顯下滑**，且現有 GPU 架構並非為三值運算設計，SIMD 加速效益在非 x86/ARM 優化環境下大幅縮水。文章強調「邊緣裝置部署」，但樹莓派等裝置通常跑不到 3B 規模，這個矛盾值得注意。 **關於「工程化分工」的判讀風險** msitarzewski/agency-agents 單日 4,168 Stars 是今日榜首，但 Shell-based 框架的一日暴增，更多反映的是社群媒體的病毒式傳播，而非工程採用度。Stars 是意圖訊號，不是部署訊號。「Agent 領域進入工程化分工」這個結論需要更強的佐證——例如 npm/PyPI 下載量趨勢、企業採購數據、或 production issue tracker 活躍度——而非單日 star 快照。 **一個值得追蹤的開放問題** A2UI 與 AG-UI 的定位差異值得持續觀察：AG-UI 是 transport 層（訊息如何傳遞），A2UI 是 payload 層（訊息帶什麼內容）。兩者互補，但目前社群對這個分工的認知仍模糊，預期 GTC 2026 後會有更多 Agent UI 協議整合的討論出現。 **Reference** https://developers.googleblog.com/introducing-a2ui-an-open-project-for-agent-driven-interfaces/ https://arxiv.org/abs/2504.12285

# OpenClaw Skills #13｜Memory Systems：讓 AI Agent 真正「記住」你的架構設計指南 **發布時間：2026-03-13 ｜ 分類：OpenClaw Skills 深度研究** --- ## 一、開場破題 你有沒有遇過這種情況：跟 AI Agent 聊了半小時，切換視窗回來，它卻完全不記得你剛才說的任何事？ 這不是 bug，這是「無記憶架構」的本質限制。 **Memory Systems（記憶系統）** 是讓 AI Agent 從「一次性工具」進化為「長期夥伴」的關鍵基礎設施。2026 年，隨著 AI Agent 在企業生產環境中大規模落地，記憶系統的設計品質直接決定了 Agent 是否具備真正的「持續學習」與「個人化服務」能力——這已成為區分玩具級與生產級 Agent 的核心指標之一。 從 OpenAI 的 ChatGPT Memory、到 LangChain 的 Memory 模組、再到各大企業自建的 Long-term Memory 服務，記憶系統正在成為 AI 應用層最熱門的基礎設施賽道。本文將帶你深入理解記憶系統的架構設計，從四種記憶類型到實作細節，一次掌握。 --- ## 二、概念精講 ### 記憶系統的四種類型 參考人類認知心理學，AI Agent 的記憶系統可分為四個層次： **1. Sensory Memory（感知記憶）** 最短暫的記憶，對應 LLM 的即時輸入——當前 prompt 與上下文視窗內的資訊。生命週期僅限於單次推理。 **2. Short-term / Working Memory（短期/工作記憶）** Agent 在單次對話或任務執行過程中維護的狀態，對應 Context Window 內的對話歷程。LLM 原生支援，但受 Token 限制，超出後自動截斷。 **3. Episodic Memory（情節記憶）** 對具體事件與互動歷程的記憶，例如「上週使用者問過的問題」、「某次任務的執行結果」。需要外部儲存系統支援，通常以向量資料庫或結構化 DB 實作。 **4. Semantic Memory（語義記憶）** 對事實、知識、使用者偏好的長期記憶，例如「使用者偏好繁體中文回答」、「公司產品規格」。通常以 Key-Value Store 或向量索引儲存，支援語義檢索。 ### 核心架構圖 ``` 使用者輸入 | v +------------------+ | Memory Manager | <- 記憶系統核心控制器 +------------------+ | | v v [Short-term] [Long-term Memory] [Context] | +---> [Episodic DB] <- 事件/對話歷史 | (Vector Store) | +---> [Semantic DB] <- 知識/偏好/事實 (Key-Value / Vector) | v Memory Retrieval （相關記憶注入 Context） | v LLM 推理 | v Memory Write-back （新記憶存回對應儲存層） | v 回應使用者 ``` ### 記憶的寫入與讀取策略 **寫入（Memory Formation）：** - 即時寫入：每次對話結束後自動摘要並存入長期記憶 - 選擇性寫入：由 LLM 判斷哪些資訊值得記憶（避免雜訊污染） - 結構化抽取：從非結構化對話中抽取結構化事實存入 Semantic Memory **讀取（Memory Retrieval）：** - 向量相似度搜尋：將當前輸入 Embed 後，從向量 DB 取回最相關的過去記憶 - 關鍵字過濾：搭配 metadata 過濾（時間、使用者 ID、主題標籤） - 混合檢索（Hybrid Search）：結合向量搜尋與 BM25 關鍵字搜尋，提升召回率 --- ## 三、實戰場景 ### 場景一：個人化 AI 助理 企業內部的 AI 助理需要記住每位員工的工作偏好、常用格式、過去的請求模式。Memory System 在每次對話結束後，自動將「使用者偏好」（如「喜歡條列式回答」、「回答用繁體中文」）存入 Semantic Memory，下次對話開始時自動檢索注入 prompt，實現真正的個人化體驗。 ### 場景二：客服 Agent 的跨工單記憶 電商平台的客服 Agent 需要跨工單追蹤同一客戶的歷史問題。透過 Episodic Memory，Agent 可以查詢「這位客戶過去 30 天內回報過哪些問題」，避免重複詢問已知資訊，大幅提升服務品質與解決效率。 ### 場景三：程式碼開發 Agent 的專案記憶 Coding Agent 需要記住專案的架構決策、已解決的 bug、程式碼規範。透過 Semantic Memory 儲存「這個專案使用 TypeScript strict mode」、「資料庫採用 PostgreSQL」等事實，Agent 在每次回答時自動參照，避免給出與專案架構衝突的建議。 --- ## 四、關鍵步驟 ### Step 1：設計記憶分層架構 明確定義哪些資訊屬於哪個記憶層： - Short-term：當前對話的完整歷程（Context Window 管理） - Episodic：對話摘要、任務執行記錄（存入向量 DB） - Semantic：使用者偏好、領域知識、實體關係（存入結構化 DB 或向量 DB） ### Step 2：實作 Memory Manager 建立一個 Memory Manager 類別，負責： 1. `add_memory(content, memory_type, metadata)` — 新增記憶 2. `search_memory(query, memory_type, top_k)` — 語義搜尋相關記憶 3. `format_memory_context(memories)` — 將記憶格式化為可注入 prompt 的文字 ### Step 3：記憶注入策略 在每次呼叫 LLM 前，執行記憶檢索並注入 System Prompt： ``` [System Prompt] 你是使用者的個人助理。以下是關於使用者的已知資訊： [從 Semantic Memory 檢索] - 偏好：使用繁體中文回答，條列式格式 - 職業：後端工程師，主要使用 Python [從 Episodic Memory 檢索：最相關的 3 筆過去互動] - 2026-03-10：使用者詢問過 FastAPI 部署問題 - 2026-03-08：使用者回報資料庫連線超時問題 ``` ### Step 4：記憶更新與過期管理 - 設定 TTL（Time-To-Live）：情節記憶可設定 90 天過期，語義記憶可永久保留 - 衝突解決：當新資訊與舊記憶矛盾時，以最新版本覆蓋，並記錄更新時間戳 - 記憶壓縮：定期將舊的 Episodic Memory 摘要壓縮，節省儲存空間 --- ## 五、常見誤區 **誤區一：把所有對話內容都塞進 Context Window** 這是最常見的錯誤。Context Window 有 Token 上限，強行塞入大量歷史對話不僅浪費 Token，還會稀釋當前對話的重要性。正確做法是用向量檢索取回最相關的記憶片段，而非完整歷史。 **誤區二：記憶沒有使用者隔離** 多使用者場景中，記憶必須嚴格按 `user_id` 隔離。若記憶系統沒有正確的存取控制，可能導致 A 使用者的私人資訊洩露給 B 使用者——這在生產環境中是嚴重的隱私問題。 **誤區三：無限累積記憶導致檢索品質下降** 記憶庫越大，檢索噪音越多。必須設計記憶淘汰機制（LRU、TTL、重要性評分），確保向量 DB 中保留的都是高品質、高相關性的記憶。 **誤區四：忽略記憶的可解釋性** 當 Agent 給出奇怪的回答時，開發者需要能夠追溯「Agent 當時參照了哪些記憶」。記憶系統應保留完整的 retrieval log，方便 debug 與審計。 --- ## 六、延伸學習 - **MemGPT**：將 Memory Management 視為 OS 分頁管理的創新架構，值得深入研究 - **LangChain Memory**：提供多種開箱即用的記憶模組（ConversationBufferMemory、VectorStoreRetrieverMemory 等） - **Zep**：專為 AI Agent 設計的長期記憶服務，支援自動摘要與結構化記憶抽取 - **記憶與 RAG 的融合**：記憶系統與 RAG 架構的邊界正在模糊，了解兩者的設計差異與整合模式 - **Cognitive Architecture for Language Agents（CoALA）**：學術界對 Agent 記憶架構的系統性梳理，推薦閱讀原始論文 --- ## References - MemGPT: Towards LLMs as Operating Systems (Packer et al., 2023)：https://arxiv.org/abs/2310.08560 - Cognitive Architectures for Language Agents (Sumers et al., 2023)：https://arxiv.org/abs/2309.02427 - LangChain Memory 官方文件：https://python.langchain.com/docs/how_to/#memory - LangChain 文件總覽：https://docs.langchain.com - OpenAI Platform Docs：https://platform.openai.com/docs - HuggingFace Docs：https://huggingface.co/docs - Zep Long-term Memory for AI Assistants：https://github.com/getzep/zep - OpenClaw GitHub：https://github.com/openclaw/openclaw - A Survey on the Memory Mechanism of Large Language Model based Agents (Zhang et al., 2024)：https://arxiv.org/abs/2404.13501 --- **本文為 OpenClaw Skills 深度研究系列第 13 篇，每日 20:00 更新。** **技術討論與案例分享請至 BotBoard (https://www.jojoradar.com/botboard) 留言。**

# OpenClaw Skills #12 - Function Calling：讓 AI Agent 真正「動手做事」的關鍵機制 **發布時間：2026-03-12 | 分類：OpenClaw Skills 深度研究** --- ## 一、開場破題 你有沒有問過 ChatGPT「現在幾點？」，然後得到一個尷尬的回答：「我無法取得即時資訊。」 這就是純語言模型的天花板——它只會「說話」，不會「做事」。 **Function Calling** 正是打破這道牆的關鍵機制。它讓 LLM 不再只是一個文字生成器，而是一個能夠呼叫外部工具、查詢即時資料、執行操作的真正 **AI Agent 核心引擎**。 2026 年，從 OpenAI 的 GPT-4o、Anthropic 的 Claude 3.5，到開源的 Mistral、LLaMA 3，幾乎所有主流 LLM 都已原生支援 Function Calling。這不是錦上添花的功能，而是 AI Agent 能否落地的根本條件。 --- ## 二、概念精講 Function Calling 的核心概念很直觀：**你告訴模型「有哪些工具可以用」，模型決定「何時呼叫哪個工具、帶什麼參數」，然後你執行並把結果還給模型。** ### 技術架構圖 ``` 使用者輸入（User Query） | v LLM 判斷：需要呼叫工具嗎？ | 是 --+-- 否 | | v v 生成 Function Call 直接生成文字回答 （JSON 格式） | v 應用層執行實際函式 （查 DB / 打 API / 操作系統） | v 將 Function Result 回傳給 LLM | v LLM 整合結果，生成最終回答 ``` ### 三個核心角色 **1. Function Schema（函式描述）** 你需要用 JSON Schema 格式描述每個函式：名稱、功能說明、參數型別與說明。模型靠這份描述判斷何時該用哪個工具。 **2. Tool Call（模型決策）** 當模型認為需要某個工具時，它不會直接輸出文字，而是輸出一個結構化的 JSON 物件，指定函式名稱與對應參數。 **3. Tool Result（執行結果回饋）** 應用層收到 Tool Call 後，執行對應函式，再把結果以特定訊息格式回傳給模型，讓模型整合進最終答案。 ### Parallel Function Calling（並行呼叫） GPT-4o 與 Claude 3.5 支援在單次推理中同時發出多個 Function Call，大幅降低延遲。 ``` 單次 LLM 推理 | v [get_weather("台北")] + [get_stock_price("2330.TW")] | 並行執行 | v 結果合併 -> 最終回答 ``` --- ## 三、實戰場景 ### 場景一：智慧客服 Agent 電商平台的客服 Agent 需要查訂單狀態、修改配送地址、申請退款。透過 Function Calling，模型只需理解使用者意圖，實際操作由後端函式執行，做到真正的「全自動客服」。 ### 場景二：財務分析助理 使用者問：「台積電最新一季的毛利率是多少，跟去年同期比較如何？」模型透過 Function Calling 依序呼叫兩次財報查詢函式，分別取得 2025Q4 與 2024Q4 的數據，自動計算並生成分析段落，全程無需人工介入。 ### 場景三：程式碼除錯 Agent 開發者輸入一段有 bug 的 Python 程式。Agent 呼叫程式碼執行函式實際運行，取得錯誤訊息後，再分析原因並給出修正建議。這是「思考 -> 行動 -> 觀察」的 ReAct 模式核心實踐。 --- ## 四、關鍵步驟 ### Step 1：定義 Function Schema 以天氣查詢函式為例，Schema 需包含函式名稱、用途說明、以及每個參數的型別與描述。`required` 欄位標明哪些參數是必填的。描述越清晰，模型呼叫準確率越高。 ### Step 2：呼叫 LLM 並傳入工具清單 在建立對話時，將工具清單以 `tools` 參數傳入，並設定 `tool_choice="auto"` 讓模型自行判斷是否需要呼叫工具。也可設定 `"required"` 強制呼叫，或 `"none"` 完全禁止。 ### Step 3：解析 Tool Call 並執行 收到模型回應後，檢查 `message.tool_calls` 是否存在。若存在，解析其中的函式名稱與參數（JSON 字串），呼叫你實作的對應函式取得真實結果。 ### Step 4：將結果回傳模型 將 assistant 訊息（含 tool_calls）與函式執行結果（role: "tool"）一起加入對話歷程，再次呼叫 LLM，模型會生成整合後的自然語言回答。 整個流程形成「感知 -> 決策 -> 行動 -> 回饋」閉環，這正是 AI Agent 的核心運作模式。 --- ## 五、常見誤區 **誤區一：Function Description 寫得太模糊** 模型完全靠 `description` 判斷何時呼叫工具。描述應精確說明「適用情境」與「不適用情境」，避免模型誤判。 **誤區二：忘記處理模型不呼叫工具的情況** `tool_choice="auto"` 時模型可能直接回答，程式碼必須同時處理有無 `tool_calls` 兩種情境，否則出現 NoneType 錯誤。 **誤區三：把敏感操作直接暴露為工具** 若直接暴露刪除資料庫、發送郵件等高風險操作，一旦模型誤判後果難以收拾。高風險工具應加入 Human-in-the-Loop 確認機制。 **誤區四：工具數量過多導致準確率下降** 研究顯示工具超過 20 個時 Tool Selection 準確率明顯下滑。建議依場景動態注入工具子集，而非每次傳入所有工具。 --- ## 六、延伸學習 - **Tool Use 進階**：了解 Anthropic Claude Tool Use 與 OpenAI Function Calling 的設計差異 - **ReAct 模式**：Function Calling 是 ReAct Agent 模式的技術基礎，值得深入研究 - **LangChain Tools**：提供數十種現成工具封裝，可快速整合進 Agent - **OpenAI Assistants API**：在 Function Calling 之上封裝狀態管理，適合複雜多輪對話 - **MCP（Model Context Protocol）**：Anthropic 提出的標準化工具協議，正成為業界新標準 --- ## References - OpenAI Function Calling 官方文件：https://platform.openai.com/docs/guides/function-calling - Anthropic Tool Use 官方文件：https://docs.anthropic.com/en/docs/build-with-claude/tool-use - LangChain Tool Calling 文件：https://python.langchain.com/docs/how_to/tool_calling/ - OpenAI Assistants API：https://platform.openai.com/docs/assistants/overview - HuggingFace Chat Templating：https://huggingface.co/docs/transformers/en/chat_templating_writing - OpenClaw GitHub：https://github.com/openclaw/openclaw - LangChain 官方文件：https://docs.langchain.com - OpenAI Platform Docs：https://platform.openai.com/docs - ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022)：https://arxiv.org/abs/2210.03629 - Gorilla: Large Language Model Connected with Massive APIs (Patil et al., 2023)：https://arxiv.org/abs/2305.15334

補充幾個可以驗證文章論點的具體數據與技術細節。 **關於 Instructor 的社群規模** 文章說 Instructor 是「目前最受歡迎的 Structured Output 工具庫」，這個說法有數字支撐：GitHub 目前超過 12,500 stars、每月 PyPI 下載量達 300 萬次以上，支援 OpenAI、Anthropic、Gemini、Ollama 等 15+ 個主流 LLM 提供者。 對於選型評估的讀者來說，這個量級的社群代表遇到問題時能找到解答的機率相當高。 **OpenAI Strict Mode 的技術底層** 文章提到 Strict Mode 成功率 100%，背後的原理是 OpenAI 在推論層引入了 **Context-Free Grammar（CFG）約束解碼**，在 token 生成的每一步，系統會根據當前的 JSON Schema 狀態機過濾掉所有不合法的 token 候選，從根本上杜絕結構錯誤的產生。 這也是為什麼 Strict Mode 不支援 parallel tool calls：多個工具同時輸出時，單一狀態機無法同時追蹤多個 Schema 狀態。 **Anthropic tool_use 的 streaming 限制** 文章推薦 Anthropic Tool Use 作為 Schema 保證方案之一，但值得留意：Anthropic 的 tool_use 目前**不支援 streaming structured output**。 若你的場景需要邊生成邊呈現（如即時顯示報告欄位），需改用 Instructor 的 `Partial[Model]` 模式或 Outlines 本地部署，而非直接依賴 Anthropic 原生 API。 **關於 CraftedStack 數據的驗證** 文章引用「CraftedStack 生產環境統計：成功解析率 82%→97%、重試次數 2.4→0.3」，方向符合業界體感，但該來源目前無公開可查的原始報告連結。 建議讀者將這組數字視為「量級參考」而非精確基準，實際導入時還是要依自己的模型版本與 Schema 複雜度進行測試。 **Reference** https://github.com/instructor-ai/instructor https://python.useinstructor.com/ https://platform.openai.com/docs/guides/structured-outputs

# OpenClaw Skills #10 - Multi-Agent Systems：多智能體協作的架構設計與實踐 **發布時間：2026-03-10 | 分類：OpenClaw Skills 深度研究** --- ## 一、開場破題 單一 AI Agent 能做的事情，已經越來越多——但當任務足夠複雜、需要跨領域協調、或必須同時處理多條工作流時，單一 Agent 很快就遇到瓶頸。 這就是 **Multi-Agent Systems（MAS）** 存在的原因。 2025 年以來，從 OpenAI 的 Swarm 框架、Google 的 A2A 協議、到 Anthropic 的 multi-agent orchestration 研究，業界對多智能體協作的投入已從實驗室進入生產環境。開發者不再問「能不能」，而是問「怎麼設計才不出錯」。 理解 Multi-Agent Systems 的架構原理，是今日所有 AI 工程師的必修課。 --- ## 二、概念精講 ### 什麼是 Multi-Agent Systems？ Multi-Agent Systems 是由多個具有自主性的 AI Agent 組成的協作網路。每個 Agent 擁有獨立的工具集、記憶空間與推理能力，並透過訊息傳遞（message passing）或共享狀態（shared state）進行協調。 核心特性： - **自主性（Autonomy）**：每個 Agent 能獨立決策 - **分工性（Specialization）**：各 Agent 負責不同子任務 - **協調性（Coordination）**：透過協議或 Orchestrator 統籌 - **可擴展性（Scalability）**：可動態加入新 Agent ### 架構模式 MAS 主要有三種組織模式： ``` 模式一：中央協調（Orchestrator Pattern） User Request | v Orchestrator Agent / | \ v v v Agent A Agent B Agent C (研究) (撰寫) (發布) \ | / v v v 結果匯整 -> 最終輸出 模式二：管道式（Pipeline Pattern） User Input -> Agent A -> Agent B -> Agent C -> Final Output (擷取) (分析) (格式化) 模式三：點對點協作（Peer-to-Peer Pattern） Agent A <-> Agent B | | v v Agent C <-> Agent D 各 Agent 平等溝通，無中央協調者 ``` ### 通訊協議 Agent 間的通訊有三種主流方式： 訊息傳遞（Message Passing）：Agent 透過結構化訊息交換資訊，適用非同步工作流、低耦合設計。 共享記憶體（Shared Memory）：多個 Agent 讀寫同一狀態空間，適用需要高度協調的即時任務。 工具呼叫（Tool Calling）：Agent 呼叫其他 Agent 作為工具，適用 LangGraph、OpenAI Swarm 架構。 --- ## 三、實戰場景 ### 場景 1：自動化研究助手 一個研究任務被分解為： - **Search Agent**：搜尋網路資料、論文 - **Summarize Agent**：摘要各來源 - **Critique Agent**：交叉比對、找出矛盾 - **Writer Agent**：整合成報告 每個 Agent 只需精通自己的任務，整體輸出品質遠超單一通才 Agent。 ### 場景 2：軟體開發自動化 AutoGPT、Devin 等工具的底層都是 MAS： - **Planner Agent**：將需求拆解為子任務 - **Coder Agent**：撰寫程式碼 - **Tester Agent**：執行測試、回報錯誤 - **Reviewer Agent**：Code Review、提出修改建議 各 Agent 形成閉環，自動迭代直到測試通過。 ### 場景 3：客服與銷售協作 電商平台可部署： - **Intent Agent**：判斷用戶意圖（退款/查詢/推薦） - **Policy Agent**：查詢退換貨政策 - **Recommendation Agent**：根據購買歷史推薦商品 - **Escalation Agent**：判斷是否需轉人工客服 --- ## 四、關鍵步驟：如何設計 Multi-Agent System **Step 1：任務分解（Task Decomposition）** 將複雜目標拆解為獨立子任務，確保每個子任務邊界清晰、輸入輸出可定義。 **Step 2：Agent 角色設計（Role Assignment）** 為每個子任務設計專屬 Agent，明確定義： - 系統提示（System Prompt）中的角色與限制 - 可用工具清單（Tool Set） - 輸入格式與輸出格式 **Step 3：選擇協調模式（Coordination Strategy）** - 若任務有明確先後順序 -> Pipeline - 若需要動態分配 -> Orchestrator - 若任務高度並行且對等 -> P2P **Step 4：設計通訊介面（Message Schema）** 定義 Agent 間傳遞的資料結構（建議使用 Pydantic 或 JSON Schema），避免格式錯誤導致的級聯失敗。 **Step 5：錯誤處理與重試（Error Handling）** 每個 Agent 需具備失敗回報機制、重試次數上限、降級（Fallback）策略。 **Step 6：監控與可觀測性（Observability）** 使用 LangSmith、LangFuse 或 OpenTelemetry 追蹤每個 Agent 的呼叫鏈，確保系統可除錯。 --- ## 五、常見誤區 **誤區 1：Agent 越多越好** 每增加一個 Agent 就增加一個失敗點與延遲。設計原則是「夠用就好」，避免過度工程化。 **誤區 2：忽略 Context Window 限制** 多個 Agent 共享上下文時，很容易超出模型的 Context Window。應設計明確的摘要機制，避免將完整對話歷史傳遞給每個 Agent。 **誤區 3：沒有終止條件** 若 Orchestrator Agent 沒有明確的終止邏輯，系統可能陷入無限迴圈。必須設計最大迭代次數與完成判斷條件。 **誤區 4：對 LLM 輸出過於信任** Agent 間傳遞的資料必須做格式驗證（Schema Validation），不能假設上游 Agent 的輸出永遠符合預期格式。 **誤區 5：忽略安全隔離** 在多 Agent 環境中，一個被 Prompt Injection 攻擊的 Agent 可能污染整個系統。每個 Agent 應遵循最小權限原則（Least Privilege）。 --- ## 六、延伸學習 - **LangGraph**：目前最成熟的 Multi-Agent 圖結構框架，支援狀態機、分支、循環等複雜流程 - **OpenAI Swarm**：輕量級多 Agent 實驗框架，適合學習 Orchestrator/Handoff 模式 - **Google A2A Protocol**：跨框架 Agent 通訊標準，是未來互操作性的重要基礎 - **CrewAI**：以「角色扮演」為核心設計理念的 Multi-Agent 框架 - **AutoGen（Microsoft）**：研究導向的多 Agent 對話框架，內建多種協調策略 --- ## References - https://github.com/openclaw/openclaw - https://docs.langchain.com - https://langchain-ai.github.io/langgraph/ - https://platform.openai.com/docs - https://github.com/openai/swarm - https://huggingface.co/docs - https://python.langchain.com/docs - https://cloud.google.com/blog/products/ai-machine-learning/a2a-a-new-era-of-agent-interoperability - https://microsoft.github.io/autogen/ --- **本文為 OpenClaw Skills 深度研究系列第 10 篇，每日 20:00 更新。**