# 策展 · X (Twitter) 🔥🔥🔥

> 作者：Ashpreet Bedi (@ashpreetbedi) · 平台：X (Twitter) · 日期：2026-04-28

> 原始來源：https://x.com/ashpreetbedi/article/2048817143974613089

## 中文摘要

Agent與工具間的缺失中介層「Context Provider」解決三道痛點。

開發Agent時若整合多工具，常遇三道障礙：上下文污染、範圍重疊導致效能衰退，以及主Agent因工具指令淹沒而忘記任務核心。新協議透過「Context Provider」中介層，讓主Agent僅見兩個簡化工具，大幅改善問題，早測結果顯示效能優異。

**三道障礙剖析**

Agent整合Slack、Google Drive與Notion等工具時，立即顯露三問題：
- **上下文污染**：每個工具耗費寶貴上下文，包括schema、描述與範例使用，全部塞入系統提示。Slack工具組8至12個，Gmail 6至10個，Calendar再6個，加上Drive、GitHub、CRM與網路，輕易達50工具。超過20工具後，模型開始幻覺不存在工具或以錯誤形狀呼叫。
- **範圍模糊無法組合**：Slack與Google工具皆需workspace參數，一個的search與另一個衝突；send_message可能指Slack、email或CRM。Agent選錯機率達一半，命名慣例無效，因為相同詞彙在不同來源有合法差異。整合外部MCP伺服器、第三方SDK或其他團隊工具時，重疊難免，模型無可靠辨識方式。
- **工具邏輯綁定主Agent**：這是最深層障礙，主Agent系統提示須解釋Slack細節，如DM前查user ID、發文前解析channel ID，耗數百token。Gmail、Calendar皆然，系統提示成所有API怪癖的聯合。即使使用者僅問Slack，每回合仍攜帶全規則，主Agent須同時推理使用者問題與各API機制。新來源需改提示，祈禱無回歸問題。

**Context Provider中介層**

傳統Agent架構為Agent直接連工具，或經MCP伺服器、Skills中介，但主Agent仍見所有原始工具表面，如全Slack工具、Drive工具、CRM工具，系統提示須含使用方式。

新架構插入薄中介層：**Agent <-> Context Provider**，每個Provider包一來源（如Slack、檔案系統、Drive）。對呼叫Agent僅暴露兩個工具：
- query_<source>(question)：自然語言讀取
- update_<source>(instruction)：自然語言寫入

主Agent不見Slack的12工具，只見query_slack與update_slack；不見Drive怪癖，只見query_drive。加10來源，主Agent工具表面仍線性維持2N。

每個工具背後是專屬子Agent，擁有該來源工具、怪癖、查前寫模式、分頁細節，在獨立上下文執行，返回乾淨結果。Python範例：
```python
from agno.agent import Agent
from agno.context.slack import SlackContextProvider
from agno.context.gdrive import GDriveContextProvider
from agno.context.database import DatabaseContextProvider

slack = SlackContextProvider(id="slack", token=...)
drive = GDriveContextProvider(id="drive", service_account_file=...)
crm = DatabaseContextProvider(id="crm", sql_engine=engine)

agent = Agent(
    model=...,
    tools=[*slack.get_tools(), *drive.get_tools(), *crm.get_tools()],
)
```
主Agent僅見四工具：query_slack、query_drive、query_crm、update_crm。

**與Skills比較**

Skills試圖解決第三障礙，將任務指令（如Slack使用法）打包成模組，相關時載入，而非常駐系統提示。這將任務知識移至條件載入，但Slack工具仍會在技能啟動後落至主Agent，載入2技能仍衝突search，甚至技能衝突悄然搞亂Agent。

Context Provider與Skills互補更好。Slack Provider的子Agent可載入Slack技能，在真正執行Slack的脈絡發揮最佳效用，而非主Agent僅求答案的環境。分工為：Skills壓縮任務執行法，Context Provider隱藏任務存在，直至主Agent委派。

**實際範例**

完整cookbook見cookbook/12_context，開箱來源包括：
- Filesystem (00)、database (04)、Slack (05)、Google Drive (07)、GitHub (12)、網路經Exa或Parallel、直接SDK或MCP端點 (01, 02, 03, 11)。皆遵query_<id> / update_<id> 形狀。

**讀寫分離與安全**：
- 04_database_read_write.py建SQLite DB，讓Agent插入聯絡人、讀回並以直接SQL驗證。讀寫經獨立子Agent與引擎。
- 12_github.py對真repo同形狀：讀經唯讀子Agent於clone，寫經per-session worktree於<prefix>/<task> branch，最終成PR。Agent無法推main branch，但可讀之。

**多來源組合**：
- 09_web_plus_slack.py展現扁平工具無法無編排碼達成：Agent從Slack頻道拉主題、逐題網路搜尋、回傳內部討論對外部參照的簡報。

**MCP包裝**：
- 06_mcp_server.py將任MCP伺服器（stdio或HTTP）包成單query_<id>工具。子Agent指令從伺服器list_tools()回應建構，呼叫Agent永不見陳舊工具文件，將50工具MCP壓至主Agent單一工具。

**意外發現**

測試揭露數項觀察：
- **子Agent成本低於預期**：原以為額外跳轉主導成本，實非。主Agent上下文小幅加速且品質佳，子Agent僅觸發相關來源回合。在Scout工作負載，token總數低來源數時持平，高來源數時改善；每來源數壁鐘延遲皆降。
- **主Agent提示大幅縮小**：預期需些許編排邏輯，實無需。均勻表面讓路由簡為「選對query_<source>」。gpt-5.4開箱即用，無需來源使用指導，此魔力需親測方懂作者興奮。
- **組合順暢**：兩Provider同回合互讀（如query_slack討論、query_drive文件），主Agent寫合成。多來源互動更佳。
- **來源增減簡易**：加/刪一來源一行，換後端（如Exa至Parallel網路Provider）限Provider內，主Agent無感。來源即用，無需改主Agent提示。

**開放問題**

仍探索事項：
- 主Agent提示多薄？正以評估hill-climb，探無指令世界可否？
- 會話跨呼叫快取：同query_<source>("who's on the X channel")兩回合後不重做。
- 使用者認證跨跳轉存活：部分解（Scout傳user_id、session_id、metadata、依賴至子Agent），OAuth來源待完善。
- 何時暴露底層工具：小來源受益Agent直驅（schema成本低、Agent推理為瓶頸），協議有模式，正界定界線。

連結：
- Examples
- Scout

## 標籤

Agent, MCP, Anthropic, Claude