DMBot onepage/ Agent context
Agent harness · Context engineering
Agent Harness 的真正缺口：不是連上 MCP，而是把 Context 接好
模型、提示詞與工具都重要；但一個 agent 在行動前取得的是零散片段，還是已經關聯、排序、可受權限約束的工作脈絡，往往更直接決定它能不能把事做完。
Published: 2026-07-27Source: Sumanth / X ArticleTopic: MCP Gateway
01 / 分清兩層
Connectivity ≠ context
MCP 可把 agent 接到 Jira、GitHub、文件或通訊工具；但每個來源各查各的，並不會自動形成可回答問題的共同脈絡。
02 / 問題所在
別把資料工程交給模型
當模型要在 runtime 自己拼接、去重、判斷關聯與排名，它會耗費 token，也更容易以不完整或互相矛盾的片段作答。
03 / 架構方向
先算好關係，再給答案
預先建立跨文件、人、專案與決策的索引或知識圖譜，讓 agent 取用已整理的 context；模型可專注推理與行動。
Key signals
這篇文章想補上的四個系統訊號
Harness
不是 prompt
生產環境品質還取決於工具、記憶、context 組裝、重試與驗證關卡。
MCP
是協定
它統一了連接方式；它本身不保證搜尋、索引與跨來源關聯的品質。
Claimed test
~2.5×
Glean 公開比較稱，固定模型與 harness、僅更換 context layer 後，其結果偏好約高 2.5 倍。
Governance
同層處理
權限繼承、工具准入、稽核與惡意內容防護，也應隨 context layer 一起設計。
Failure mode
連上很多工具，為何 agent 仍像「半盲」？
01
來源彼此分離
不同 API、不同搜尋語法、不同索引與排名規則，讓「同一個客戶問題」的線索散落在 issue、設計文件、程式碼與對話紀錄裡。
02
模型被迫現場做 join
模型收到的是數個未連結的檢索結果，還得自己推斷人、功能旗標、專案與歷史決策的關係；這是 context 缺口，不只是模型能力問題。
03
答案看似合理，卻不能結案
資訊不足時，agent 往往給出通用排查清單並要求再查；有好的組織脈絡時，才更可能指出 owner、原因與排優先序的下一步。
Design checklist
把「Context」當成一個可設計的產品層
預先關聯，而非每次臨時拼接把文件、程式庫、專案、事件、角色與決策之間的關係建成可更新的資料基礎，降低每次 query 的重複推斷。
保留來源、時間與權限Context 必須能追溯資料來處、反映最新狀態，並依原始系統權限過濾；「相關」不能凌駕於「可看」。
讓 retrieval 有評測不要只評估最終文字。用真實工作問題測試：檢索是否命中、關係是否正確、token 與完成任務的步數是否下降。
把治理做成預設值集中化不是把一切攤平，而是集中施行工具准入、最小權限、稽核、人工核可與對提示注入的防護。
Practical takeaways
給正在做 agent 的團隊：先問這四題
每個關鍵任務需要跨哪些系統的共同事實？先畫出 answer 依賴的資料關係，而不是先堆 connector 數量。
哪些 join、排序與去重能在模型前完成？可預先處理的結構工作，不該反覆以 token 交給模型猜。
錯誤的 context 能否被觀察與修正？保存來源與檢索軌跡，才能將「答案錯了」回推到資料新鮮度、權限或關聯規則。
安全控制是否跟著每一次工具呼叫？讓來源權限、風險檢查與人類核可成為路徑的一部分，而不是部署後再補上的旁路。
Source reading
原文的論點，該如何閱讀
「MCP is connectivity. Not context quality.」Sumanth / X Article · Glean MCP Gateway material
這是原文最值得留下的架構區分。Glean 對效能數字與產品能力的敘述屬供應商主張；其可遷移的工程提醒是：對 agent 成效做評估時，應把資料關聯與 context 品質當成可獨立檢驗的變因。
References