Context Providers：拯救 Agent 上下文污染的遺失層 (Context Providers: The Missing Layer)

原始來源與檔名：20260512_2026-04-28T092611+0800-Context providers the missing layer between agents and tools.md

來源：[[@ashpreetbedi]] / X (Twitter) — 2026-04-28 原始檔名：2026-04-28T092611+0800-Context providers the missing layer between agents and tools.md

NAPKIN | 餐巾紙

餐巾紙公式

The Problem: Agent <- sees 50 tools (Slack, Drive, Notion) -> Context pollution & scope collision. The Solution: Agent <-> ContextProvider (Sub-agent) <-> Source Tools Main Agent only sees: query_slack(question) and update_slack(instruction).

當你的 Agent 擁有多個系統（Slack, Google Drive, CRM）的工具權限時，它會撞牆：上下文被工具描述塞滿、工具名稱衝突（如多個 search 工具），且主 Prompt 必須記住每個 API 的怪癖。作者提出了一個架構模式：「Context Providers」。在主 Agent 與工具之間插入一層子代理（Sub-agent）。主 Agent 永遠只看到兩個自然語言工具：query_source 和 update_source。底層的複雜 API 邏輯由獨立的子代理處理。這大幅壓縮了主 Agent 的負擔並解決了衝突。

一句話

這是一篇解決 Agent 工具過載與幻覺的關鍵架構文。現代 Agent 架構常常把幾十個 API 工具直接丟給主模型，導致嚴重的上下文污染與作用域衝突（例如 Slack 的 search 和 Drive 的 search 搞混）。解法是引入「Context Providers」封裝層：用一個專門的子代理接管 Slack 的所有底層工具，並只向主代理暴露兩個極簡介面：自然語言查詢（讀）與自然語言指令（寫）。這種「去中心化工具路由」讓主代理的智商瞬間回血。

餐巾紙草圖

[ Traditional Flawed Architecture ]
Main Agent System Prompt:
- Here is how to use Slack's 12 tools.
- Here is how to use Drive's 8 tools.
- Here is how to use CRM's 10 tools.
Result: 80% of context is API docs. Hallucinations happen.

[ Context Provider Architecture ]
Main Agent System Prompt:
- Tools available: `query_slack`, `update_slack`, `query_drive`.
     |
     v (calls `query_slack("What did John say?")`)
Slack Sub-agent (Has the 12 tools, does the lookup logic)
     |
     v (returns plain text summary)
Main Agent synthesizes the final answer.

ROUND 1: SKELETON | 骨架掃描

“這篇文章在說什麼”

三大撞牆期 (The Three Walls):
1. 上下文污染: 引入超過 20 個工具後，Schema 描述佔據了大量 Context，模型開始幻覺。
2. 作用域模糊 (Scope Collision): 多個系統都有 search 或 send_message，模型容易選錯工具，無法組合使用。
3. 工具邏輯與業務邏輯混雜: 主 Prompt 必須包含每個 API 的怪異規則（例如 Slack 必須先找 ID 才能發訊），這讓 Prompt 變得無法維護。
遺失的層級 (The Missing Layer): 打破 Agent <- Tools 的直接映射。建立 Agent <-> ContextProvider <-> Raw Tools 架構。
實作方式: 針對每個資料源（Slack, Drive, DB）建立一個 Context Provider（本質是一個 Sub-agent）。它只向主 Agent 暴露兩個介面：
- query_<source>(question): 自然語言讀取。
- update_<source>(instruction): 自然語言寫入。
與 Skills 的關係: Skills 壓縮了如何完成任務的指令。ContextProvider 與 Skills 完美契合：Slack ContextProvider 的子代理在底層載入 Slack Skill，讓主代理完全不需要知道任務的存在。
驚喜發現:
- 增加一個跳板（Hop）並不會變貴或變慢，因為主 Agent 的 Prompt 變得很小，推理速度大增，抵銷了開銷。
- 主 Agent 變得非常聰明，不需要額外的路由提示詞就能完美呼叫 query_<source>。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

核心論證鏈

封裝與抽象 (Encapsulation and Abstraction): 軟體工程的黃金法則在 Prompt Engineering 同樣適用。微服務架構之所以能解決單體應用的泥潭，就是因為隱藏了底層實作細節。ContextProvider 就是 Agent 的「微服務閘道器 (API Gateway)」。
自然語言即通用協定 (NL as Universal Protocol): 傳統工具依賴 JSON Schema 進行強型別綁定。但 LLM 最擅長的是自然語言。透過把 search_channel(id="C123", query="bug") 轉換成 query_slack("Find discussions about the bug in the engineering channel")，將「找 ID、組 JSON」的髒活下放給專門的子代理，極大降低了主代理的認知負擔。
讀寫分離的安全性 (CQRS): 將 query (讀) 與 update (寫) 分開成為兩個工具，從根本上防止了模型在「只是想搜尋資訊」時，意外呼叫破壞性 API 的危險。

關鍵證據

框架實測：在 Agno 框架中實作後，主 Agent 的 Context 大幅縮減，並且能流暢地在同一個 Turn 內同時呼叫 query_slack 和 query_drive，然後將兩個來源的資訊完美整合，這在傳統的扁平工具架構中幾乎不可能穩定做到。

邊界條件

如果一個任務極其簡單，且延遲要求在毫秒級（例如單純的計算機工具），加入 ContextProvider 會帶來不必要的網路/模型跳轉延遲。此模式最適合用於「龐大且具有自身 API 邏輯」的外部系統（如 ERP, CRM, GitHub）。

ROUND 3: SOUL | 靈魂提取

“還能怎么用”

知識連結: 這篇文章為《How to correctly use MCP servers》中的「Subagent MCP Servers」模式提供了完美的代碼級理論基礎。同時，也解決了《Anatomy of Agent SKILLS》中提到的 Context Bloat 問題。
深層洞見: “The minute you compose tools from sources you don’t control, you get overlap, and the model has no reliable way to disambiguate.” (當你組合來自不可控來源的工具時，就會產生重疊，模型無法可靠地消除歧義。) 工具層的命名空間污染，必須用更高層的代理邊界來隔離。
行動呼籲: 重構你的 Agent 工具鏈：停止把 [gmail_read, gmail_send, slack_search, slack_post, jira_create] 全部塞給你的主 Agent。寫三個小型的 Python 子代理腳本封裝它們，並只丟給主 Agent [ask_gmail, command_gmail, ask_slack, command_slack...]。你會發現 Agent 的智商瞬間提高了一個世代。