MCP 用 Markdown 寫 MCP Server：一個 bash runbook 橋接器的誕生 一個讓你用 Markdown 定義 MCP tools 的橋接器。四位 AI 審查、測試、打臉後的誠實記錄。
mk-brain Agent Tooling 的安全邊界：從最小化設計看 MCP 的本地治理 當我們賦予 AI Agent 使用工具的能力時，如何確保安全？與其疊加複雜的權限控管與警語，不如回歸本質：從一開始就嚴格限制其能力邊界。本文將從 Model Context Protocol (MCP) 的實踐出發，探討如何透過最小化通信介面與預設權限，建立更穩固的本地優先（local-first）治理框架。
mk-brain MCP 不只是新工具：AI 從對話層走向本地執行層的架構權衡 MCP 的真正意義，不是讓 AI 多接一個工具，而是把它從對話層推進到可操作本地系統的執行層。當 Agent 開始真正動手，架構競爭就會落在本地權限、可控性與雲端擴展之間的成熟權衡。
AI 我的 AI Agent 把自己的幻覺當事實引用 — 以及我如何用 8 行設定檔防止它 我的 AI Agent 把自己的幻覺當事實引用。AI Agent 記憶的 Ouroboros Effect — 以及如何用 ACA 的 source tier、provenance chain 和 audit trail 阻止它。
AI My AI Agent Cited Its Own Hallucination as Fact — And How I Stopped It With 8 Lines of Config My AI agent cited its own hallucination as fact. The Ouroboros Effect in AI agent memory — and how ACA stops it with source tiers, provenance chains, and audit trails.
AI Agent UMP Defines the Wire. AMH Ships the Governance. Your AI agents can call tools, talk to each other, and present verifiable identities. But ask them what they decided yesterday, and they stare at you blankly. I built Agent Memory Hall to fix that.
mk-brain MCP 的真正價值：為何將資料處理能力「模組化」是 Agent 導入企業的關鍵一步 MCP 的價值不只在於讓 Agent 接上資料湖，而在於把原本零散的資料處理能力封裝成可插拔、可治理的協議介面。當能力被模組化，企業導入 AI Agent 的門檻就會從繁重整合工程，下降為較可控的系統設計問題。
AI 從 Fable 5 外洩的 System Prompt，看 Anthropic 的五個戰略轉向 Fable 5 的外洩 system prompt 揭示了 Anthropic 的五個戰略方向：雙軌安全制、MCP App 消費者生態、Skills 平台化、跨 session 持久化、以及從真實案例學來的精細安全規則。
mk-brain 不只模型，Agent 的執行層革命正從 Rust 與 CDP 開始 AI Agent 的競爭不只在於模型智能，更在於執行效率。當我們將操作電腦的後端從高階框架轉向 Rust 與 Chrome DevTools Protocol (CDP) 等底層實作時，成本、延遲與相容性都將迎來數量級的改善，這將徹底重塑 Agent 產品的邊界與可能性。
mk-brain AI Agent 的擴展陷阱：為何分散的工具入口，是壓垮使用者體驗的最後一根稻草？ 當我們為 AI Agent 增加更多功能時，直覺上會為每個模組獨立配置工具。然而，這種分散式架構看似靈活，卻會帶來災難性的設定成本與心智負擔，最終讓整個產品體驗崩潰。本文將從一個實際案例出發，探討為何統一的工具入口才是 Agent 系統擴展性的關鍵。
mk-brain MCP 原型的詛咒：為何成功的 PoC 反而走向技術債的懸崖？ 許多團隊在開發多輪對話協定（MCP）系統時，常因追求快速驗證而忽略初期架構的嚴謹性。本文將深入探討，為何這種「先求有再求好」的思維，會讓看似成功的原型在邁向生產環境時，撞上名為「安全之崖」的絕壁，最終導致難以挽回的技術債。這是一篇關於如何避免 MCP 專案從成功走向失敗的警世文。
mk-brain 從工具串接到可信系統：MCP 如何為高風險領域的 LLM 賦予可驗證的專業能力 大型語言模型在法律、稅務等高風險領域的應用，最大挑戰是幻覺與缺乏可驗證性。一個日本開發者的專案，透過 MCP 協定標準化官方數據接口，展示了如何從簡單的工具串接，走向真正可信賴的 AI 系統。這不僅是技術實踐，更是對未來專業 AI 系統架構的深刻啟示。
mk-brain Agent 的穩定性幻覺：為何關鍵不在模型，而在工具契約與失效設計 AI Agent 的穩定性，真的只關乎模型聰不聰明？許多開發者在追求更強大 LLM 的同時，卻忽略了生產環境中更關鍵的挑戰：Agent 與外部工具間的互動介面。本文將帶你深入探討，如何透過軟體工程的「工具契約」、版本管理與周全的失效保護機制，打造出真正穩固、可維護的 AI Agent 系統，擺脫模型能力的幻覺。
mk-brain 當 API 成為 AI 系統的標準配備：我們真的準備好應對新的攻擊面了嗎？ 當 AI 與現代軟體系統越來越依賴 API、tool use 與跨系統整合時，真正被放大的往往不是功能，而是攻擊面、信任邊界與治理成本。一篇從 API 便利性談到系統風險建模、production guardrails、權限設計與 AI agent 工具治理的觀點文。
AI 從 AI 使用者到 AI Orchestrator：我如何把 Claude Code 用成多 Agent 作業系統 當 AI 不再只是回答問題，而是開始參與真實工作流程，工程能力的核心也會改變：從單點使用模型，走向調度、治理與觀測一整個多 Agent 系統。
AI 看完 Google ADK 的 Demo，我為什麼還是繼續用自己的七位一體 Google Cloud 剛 demo 的 ADK + MCP + Agent Engine + A2A，被中文圈包裝成「Anthropic 公開了 AI 公司藍圖」的爆款帖。我把整場 demo 看完，對照自己這一年在家裡跑的七位一體系統，記下幾個結論——ADK 跟 MCP 可以拿來用，Agent Engine 才是 GCP 真正想賣你的綁定。
mk-brain AI 程式開發的下個戰場：從模型能力到脈絡系統的典範轉移 AI 程式開發的未來，不再只是模型能力的軍備競賽。當前工具在處理大型專案時的瓶頸，指向了一個更深層次的挑戰：如何讓 AI 不僅能寫程式，更能「理解」程式碼的來龍去脈。本文將深入探討這場從單點提示工程，轉向建立智慧「脈絡系統」的典範轉移，以及它如何重塑未來的 AI 系統設計與 Agent 工作流，開啟程式開發的新紀元。
AI 我把 AI workflow 搞成七位一體，然後放棄了 MCP 三個月前我還在想怎麼把 Claude 用到極致，現在我每天在做的事是設計一個多智能體的工作組織。從 1 個 AI 到 7 個，再從 MCP 換成最土的 File I/O——AI workflow 的真正瓶頸從來不在模型，而在協作協議。
AI AI Agent 越來越強，但你的 MCP 架構扛得住嗎？ 最近看到 Google Cloud Tech 談 MCP（Model Context Protocol）安全的影片，裡面有一句話我很認同：當模型開始有「手腳」，你要治理的就不只是模型輸出，而是整個行動鏈。 https://www.youtube.com/watch?v=qGCdbAn0nk8 很多團隊把 MCP 當成「讓 LLM 連接外部工具的標準介面」。工程上它確實很漂亮：代理（Agent）負責決策，MCP Server 負責執行工具操作。但安全上，它等於把攻擊面從「文字」擴大成「能改你系統狀態的一連串動作」。 這篇我用實務角度整理 MCP 架構常見的四類風險，跟一套比較像工程的防線設計：縱深防禦（Defense in Depth）。 ## MCP 的核心風險：
ClaudeCode Claude Code 新手上路：把一堆名詞放回正確位置 剛開始用 Claude Code（或任何一種「AI 進到開發流程」的工具）時，最痛苦的通常不是功能，而是名詞爆炸。 CLAUDE.md、MCP、Subagents、Skills、Slash Commands、Hooks……你明明只是想讓它幫你寫點程式，結果像被丟進一場企業架構課。 我自己會用一個很實務的方式消化：每個名詞都對應一種「團隊裡的角色」或「工程裡的控制點」。你把它放回正確位置，整個系統就突然合理了。 ## CLAUDE.md：專案的長期記憶（不常改的那種） 如果你把 Claude 當成加入專案的新同事，CLAUDE.md 就是他入職第一天會拿到的那份文件： * 系統架構與模組邊界 * 開發慣例（命名、資料夾結構、測試習慣） * 設計模式與你們不想再爭論的決策 它的重點是「穩定」：不要塞每天都在變的細節，否則它會變成噪音。 我會放的內容 * 這個 repo
AIAgent AI FOMO 管理學：把資訊消化拉長兩週，順便搞懂 Skills vs MCP 這陣子的 AI 圈有一種熟悉的味道，讓我想起 2022–23 年的區塊鏈： * 新名詞、新框架、新「革命性」應用，幾乎每 2–3 天就來一輪 * 產品成熟度還沒跟上，討論熱度先衝到天花板 * 你明明在工作，手機卻一直提醒你「你落後了」 FOMO 不是你的問題，它是市場在高速迭代時的副產品。問題在於，你要用什麼節奏去消化它。 ## 我自己最實用的一招：把判斷週期拉到 1–2 週 當資訊密度高到爆表時，我會強迫自己做一個「時間濾網」： * 今天看到的概念先記下來 * 不急著追完整套教學、也不急著做結論 * 兩週後再回頭看：還有人持續在聊嗎？有真實案例冒出來嗎？有工具鏈開始接上來嗎？ 兩週後還站得住的東西，通常具備兩種特質之一： 1. 確實解決了某個痛點，所以會有自發的延伸使用 2. 短期內難以被巨頭輕鬆碾壓或收編，因此會累積一點點護城河 用這個節奏再去投入時間，
