Letta／MemGPT 完整介紹：把記憶管理做進 Stateful Agent Runtime
Letta 延續 MemGPT 的作業系統類比，但它不是單一 memory API：agent state、可編輯的 in-context memory blocks、conversation history 與外部 archival memory 都由 runtime 持久化，模型也能透過工具主動整理記憶。
#context-engineering
24 篇文章OpenViking：把 Agent 記憶做成虛擬檔案系統
火山引擎開源 OpenViking 把 agent 的記憶、知識、技能存成 viking:// 虛擬檔案系統，用 ls、tree、find 就能翻。三層載入（L0/L1/L2）讓平均檢索只用 550 tokens，LoCoMo 記憶準確率從 24–57% 提升到 80–83%。
Claude Code skill 怎麼寫才不吃 context：入口、門檻、成本、來源
把 Anthropic 的 session 成本建議做成全域 skill，第一版就犯了它要防的錯：description 塞滿觸發關鍵字、用檔案數和分鐘數當硬門檻、把「保護主 context」和「省總 token」混成一件事。三輪修正後入口縮到一頁，細節拆進 references，數量門檻換成四個判斷維度，草稿裡的主張則逐條對官方文件查證。
Context 滿了怎麼辦：七種答案，沒有一種是共識
Chroma 的對照實驗證明：就算塞得下，塞滿也會變差。於是各家 coding agent 發展出七種對策——壓縮、換手、剪枝、少載入、隔離、進模型、換單位。Amp 直接移除 /compact，Atlassian 說摘要該是最後手段，Cursor 的 A/B 測出 46.9% token 降幅。三場分歧的根源不是誰對，是各自在衡量不同的東西。
prompt 與 context engineering 的考法：十張證照怎麼問，跟實務差在哪
多數人以為 GenAI 證照的主軸是 prompt 寫作，但 CCAO-F 的 Prompting 只有 14%，輸出評估卻有 21%；CCDV-F 的 Prompt and Context Engineering 只有 11%。真正被考的是結構化輸出、防禦性 prompt、動態 context 注入、context 壓縮與快取、prompt 生命週期治理，以及「prompt 改了怎麼證明變好」——這六件事比較接近 context engineering 與軟體工程，而不是寫作技巧。另外沒有任何一張要你現場寫 prompt，全是選擇題，所以練「說得出為什麼」比練手感有用。最該記住的一條來自 CCAR-F：業務邏輯必須被保證時，「先改 prompt」通常是錯誤選項。
AI Agent GitHub Digest — 2026-08-18
headroom 把送進 LLM 前的 tool output/log/RAG chunk 先做本地、內容感知的壓縮，7 個月衝上 6.6 萬星；agentmemory 讓 Claude Code、Cursor、Codex CLI 等十幾種 coding agent 共用同一份跨會話記憶，半年衝上 2.7 萬星；Andrew Ng 團隊的桌面 agent OpenWorker 把目標使用者從工程師擴大到一般知識工作者；NVIDIA 的 labs-OO-Agents 用物件導向重新設計 agent 抽象。Mastra 1.59.0 把 CostGuardProcessor 更名 TokenCostControl（breaking），browser-use 0.13.8 加入第一方 OpenClaw skill 支援。
microsoft/AI-Engineering-Coach 的 45 條規則：一份把 agentic 工程意見寫成可執行門檻的清單
微軟員工開源的 VS Code extension，讀本機 Claude Code / Codex / OpenCode 的 session log。真正的內容物是 45 條 Markdown 規則：prompt 短於 30 字元、收到 20 行 AI 程式碼後 15 秒內就送下一則、instructions 檔超過 4000 bytes——把「context engineering」翻成可以爭論的數字。
CS146S Week 4：CLAUDE.md 該寫什麼、hooks 該擋什麼、subagent 該切在哪
課程把指揮 agent 的工具列成四件：指示檔、hooks、commands、subagents。指示檔是唯一每次開機都全額進 context 的，所以它是 config 不是 memory；hooks 補上「規則會被忽略、hook 不會」那一塊；commands 是四件裡唯一由人主動觸發的。課程另給一張表，把軟體任務七步驟裡只剩一步半標成人的工作。
CS146S Week 3：Agent Skills 是一個資料夾，難的是那兩行 description
Agent Skills 的規格小到一句話講得完：一個含 SKILL.md 的資料夾。真正的設計在三層 progressive disclosure——開機只載 name 與 description，命中才讀全文，需要才展開附檔。本站自己的 repo 有 35 個 skill、7,893 行 SKILL.md，開機成本仍然只有那 35 組 metadata。
CS146S Week 2：context 工程、RePPIT，與 MCP 的 98.7% 那一刀
Fall 2026 把整整一週的 prompting 壓成這週的一節，換上 RePPIT（Research、Propose、Plan、Implement、Test）與 MCP。RePPIT 的兩條硬規則最值得抄：propose 一定要兩個方案、寫 code 的那個 instance 不准 review 自己的 code。MCP 那邊 Anthropic 量到把工具改成程式碼呼叫可以把 150,000 tokens 壓到 2,000。
Stanford CS146S 兩版大綱對照：一年之間，這門 AI 開發課改掉了什麼
Stanford CS146S 的 Fall 2026 大綱把 prompting 從整整一週壓成一節，砍掉終端機與 UI 生成兩週，換上 Agent Skills、Agent-Ready Codebases、Background Agents、AI-Native Team。評分也動了：Final Project 從 80% 降到 50%，多出 30% 的 open source 貢獻。這個系列照十週逐篇讀。
context 與記憶：agent 失敗的真正位置
Chroma 測了 18 個前沿模型，全部隨輸入變長而跳崖式退化。記憶失效多半是檢索失效偽裝的。而 KV cache 的真正成本是頻寬不是儲存——decoding 每產生一個 token 都要讀過整個 cache。
幾百個工具怎麼選得準：tool selection 的崩塌曲線與工程解法
工具一多，選擇準確率不是緩降是崩塌：4→51 個工具從 43% 掉到 2%、10→100+ 個從 78% 掉到 13.62%。根治解法是別一次塞全部——Anthropic Tool Search Tool 用 defer loading + 檢索砍 85% token，Opus 4.5 準確率 79.5%→88.1%。description 品質的效益是條件式的：簡單場景沒差，多工具串接場景 correctness 44%→50%。
CodeGraph：本地端程式碼知識圖譜，與「直接走圖才省錢」的真相
CodeGraph 用 tree-sitter 把 codebase 抽成本地 SQLite/FTS5 知識圖譜，讓 AI coding agent 查圖而不是掃檔。官方端到端 benchmark（7 repos、median of 4）平均省 35% 成本、70% tool calls；但前提是 agent 直接走圖——把探索 delegate 給只會讀檔的 subagent，CodeGraph 反而變成 overhead。
Code Mode：把 tool definition 從 context 搬進 code
別再把所有 tool description 在 session 開頭一次塞進 context。讓 model 寫 code、runtime 執行，tool 定義只在 import 那行才進 context — Anthropic 的 GDrive→Salesforce 範例從 ~150K tokens 降到 2K，Cloudflare 的 2,500 endpoints schema 從 1.17M 降到 1K。
Claude Skills：把專業知識打包成資料夾，教一次就一直記得
Skill 是一個資料夾、一份 SKILL.md。三層 progressive disclosure 讓 Claude 在需要時才載入細節，避免每次對話重新解釋偏好。
Agentic Engineering 的記憶問題：從類型、實作到擁有權
Agent 的記憶不是一個插件，而是 harness 本身的一部分。選對記憶類型、估算資料量、再決定用什麼技術——最後，也要搞清楚你是否真的擁有那份記憶。
quidproquo 部落格改進完整規劃：從內容、技術、RAG 設計到 Harness 基礎建設
用自己寫的 30+ 篇 RAG/Agent 文章交叉檢視部落格現狀，整理出橫跨內容品質、網站技術、RAG 設計修正、Harness 基礎建設、AI Agent 應用的完整改進清單，按優先級排列、不分階段。
Claude Code Agent Teams 怎麼用？從 GitHub 6,400+ 個 agent 看設計模式
GitHub 上已有 6,400+ 個 .claude/agents/*.md 檔案。我們拆解了 4 個代表性專案——ChemistryTimes（內容生產 pipeline）、claude-sub-agent（document-driven 開發流水線）、agentic（Temporal.io DAG 平行執行）、vs-copilot-multi-agent（Hook 強制記憶寫入）——加上 ruflo 的企業級 swarm 架構，歸納出 6 種設計模式和 5 個實戰趨勢。
Agent CLI 完整指南：設計邏輯、工具比較與使用原則
Agent CLI 不是更聰明的補全工具，而是能讀懂 codebase、執行多步驟任務、操作真實環境的 AI 代理。Claude Code、Codex CLI、Gemini CLI、OpenCode、Aider、Pi、Kiro、Amp、Cursor CLI... 工具越來越多，但底層共享一套設計邏輯——理解這套邏輯，才能真正用好它們。
從 Prompt 到 Harness：AI 工程的三次演化
AI 工程經歷三個階段：Prompt Engineering（寫好指令）→ Context Engineering（餵對資訊）→ Harness Engineering（設計整個工作環境）。每一次演化不是取代前者，而是在更高的抽象層級上操作。
Context Engineering：為什麼你的 AI Agent 問題出在資訊，不在模型
Context Engineering 是 2025 年取代 Prompt Engineering 的核心概念：重點不再是「怎麼問」，而是「給什麼資訊」。把對的資訊在對的時機送進 context window，比換更強的模型更有效。這篇整理了定義、四大策略、實作技巧和常見失敗模式。
AI Agent 架構模式完整指南：從三支柱到 Multi-Agent 的系統化導航
AI Agent 不是一個技術，是一整個架構體系。本文是系統化導航：從 Agent 三支柱（Context/Cognition/Action）出發，穿過 AI 工程三階段演化（Prompt → Context → Harness），到八種 Multi-Agent 設計模式和生產級 Harness 基礎設施。每個主題都有對應專文深入。
AI Agent 的三個核心支柱：Context、Cognition、Action
AI Agent 不是黑盒子——它由三層構成：知道什麼（Context）、怎麼想（Cognition）、能做什麼（Action）。搞清楚這三層，才能理解 agent 為什麼有時聰明、有時失控，以及怎麼設計一個真正好用的 agent 系統。