OpenClaw 工具篇（一）：一個專屬瀏覽器、三種附著方式，與被標成「不可信」的搜尋結果
OpenClaw 的瀏覽器是一個獨立的 agent 專用 profile，跟你的個人瀏覽器完全隔離。而 web_search 的回傳結構裡有一個 externalContent.untrusted 標記——搜尋結果在型別層就被標成不可信的外部內容。
ai
1239 篇文章OpenClaw 工具篇（三）：關掉檔案工具不會讓 exec 變成唯讀
exec 是一個會改變狀態的 shell 面：關掉 write、edit、apply_patch 這些檔案工具，完全不會讓它變成唯讀。而沙箱預設是關的，所以 host=auto 實際上會解析到 gateway——真的要沙箱就明確寫，它至少會 fail closed。
OpenClaw 工具篇（二）：Skills 的六層優先順序，與子 agent 不給訊息工具的理由
Skills 從六個來源載入、同名時高優先者勝，而 per-agent 的清單是取代不是合併。子 agent 預設拿不到 session 與訊息工具——它回傳純文字給父 agent，人看得到的回覆權留在父 agent 手上。
OpenClaw 工具篇（四）：當工具多到塞不進 prompt——Code Mode、Tool Search 與 MCP
工具目錄大到塞不進 prompt 時，OpenClaw 有兩個答案：Code Mode 只讓模型看到 exec 與 wait，由它寫小程式去搜尋與呼叫隱藏的目錄；Tool Search 則保留結構化的搜尋／描述／呼叫控制。兩者都不繞過工具政策。
OpenClaw 維運篇：前 60 秒的七行指令，與「感覺變笨了」通常不是模型的錯
官方的分診流程是七行指令跑一遍、兩分鐘出診斷。而「assistant 感覺受限、工具不見了」這個最常見的症狀，多半是工具 profile——minimal 只允許 session_status，coding 才是新本地設定的預設。
OpenClaw UI：新增的側欄可以問「這個 session 在幹嘛」而不打斷它
Control UI 加了一條 session rail：它用 utility model 產生執行摘要，還附一個唯讀的伴讀 thread，讓你問「這個 session 現在怎樣」而不會進入或打斷主 agent 執行。它的內容不會進入 chat.history。
Phil Schmid：為什麼 Agent Harness 是 2026 年最重要的事
模型是 CPU，harness 是作業系統，agent 是應用程式。模型能力再強，沒有好的 harness 就只是 demo。Phil Schmid 認為 harness 是 2026 年 AI 工程最關鍵的基礎設施。
LangGraph：用圖結構管理 Agent 工作流程
LangGraph 把 LLM 工作流程建模成有向圖，解決多輪迭代、條件分支、平行執行這些用線性 pipeline 做很痛的問題。
Langfuse 完整指南：LLM 應用的可觀測性從零開始
Langfuse 是目前最成熟的開源 LLM Observability 平台。這篇從 Tracing、Prompt 管理、評估、Dataset 四個核心功能切入，帶你搞清楚它在實際專案中怎麼用。
Context Engineering：為什麼你的 AI Agent 問題出在資訊，不在模型
Context Engineering 是 2025 年取代 Prompt Engineering 的核心概念：重點不再是「怎麼問」，而是「給什麼資訊」。把對的資訊在對的時機送進 context window，比換更強的模型更有效。這篇整理了定義、四大策略、實作技巧和常見失敗模式。
MCP（Model Context Protocol）：AI Agent 工具呼叫的標準化協定
每個 AI 工具都有自己的呼叫格式，整合成本高。MCP（Model Context Protocol）是 Anthropic 提出的開放標準，統一 AI Agent 與外部工具、資料源的通訊協定，讓工具可以跨 Agent 重用。
Agent Memory 系統：從 RAG 到 Read-Write 記憶的演化
RAG 是唯讀的。Agent Memory 讓 AI 不只能讀，還能寫入和持久化資訊。三種記憶類型：Procedural（行為模式）、Episodic（時間事件）、Semantic（事實知識），構成完整的認知記憶系統。
AI Agent 的三個核心支柱：Context、Cognition、Action
AI Agent 不是黑盒子——它由三層構成：知道什麼（Context）、怎麼想（Cognition）、能做什麼（Action）。搞清楚這三層，才能理解 agent 為什麼有時聰明、有時失控，以及怎麼設計一個真正好用的 agent 系統。
Multi-Agent RAG：多個專業 Agent 協作的分散式檢索架構
單一 RAG Agent 處理所有查詢會遇到知識邊界和效能瓶頸。Multi-Agent RAG 把檢索任務分派給多個專業化 Agent，每個 Agent 有自己的知識庫和檢索策略，由中央 Orchestrator 協調合併結果。
LongRAG：用長上下文模型重新思考 RAG 的 Chunking 策略
傳統 RAG 把文件切成小 chunks 再檢索，但這造成資訊碎片化。LongRAG 利用 100K+ token 的長上下文模型，檢索更大的文件區段（整個章節甚至整份文件），減少碎片化同時保持檢索效率。
Speculative RAG：用小模型平行打草稿，大模型一次驗證
Speculative RAG 用小型專家模型從不同文件子集平行生成多個答案草稿，再由大型模型一次驗證選出最佳答案。論文在 PubHealth 上準確度提升 12.97 個百分點、延遲降低 50.83%——但這是最好的那一格，其他 benchmark 的幅度小很多。
Ollama 完整指南：一行指令在本地跑 LLM
Ollama 把 llama.cpp 包裝成 Docker 風格的 CLI + REST API，一行指令就能在本地跑 LLM。這篇從核心概念、安裝、API、硬體需求到 Modelfile 自訂，完整介紹這個工具適合什麼、不適合什麼。
RAG 系統模式完整指南：從 Naive 到 Multi-Agent 的十代演化與實戰導航
RAG 已經從簡單的「搜尋+生成」演化成涵蓋十個世代的技術體系，2025 年後更進入 Agentic/Reasoning RAG 新階段。本文是系統化導航：從 Naive RAG 到 Multi-Agent/LongRAG 的十代演化、後十代 Agentic Era（Search-R1/RL 搜索、MCP 協議、GraphRAG 3.x、視覺直嵌）、檢索策略、Chunking、Embedding、Reranking、評估框架、可觀測性、成本優化。每個主題都有對應專文深入。
vLLM — 從 PagedAttention 到生產級 LLM 推論引擎
vLLM 用 PagedAttention 解決 KV cache 記憶體浪費問題，搭配 continuous batching 和 prefix caching，成為目前最主流的開源 LLM 推論引擎。
聊天機器人開發完整指南：狀態管理、記憶策略與tech stack選型
聊天機器人不只是接 API。對話狀態管理、記憶機制、Streaming、Guardrails、可觀測性、tech stack選型，每一層都影響使用者體驗。