# 模型不是瓶颈，Harness 才是；而 Harness 里最被低估的一层是"上下文质量"！ 在企业 Agent 应用中，上下文往往散落在十几个系统里（Jira、Confluence、GitHub、S...

- 来源：Meng Shao
- 发布时间：2026-07-27 22:25
- AIWatch 分数：62
- AIWatch 标记：未精选
- AIWatch 链接：https://aiwatch.icu/events/evt_01kyj1qb5tv544hqmhd16fjk2t
- 原文链接：https://x.com/shao__meng/status/2081747876993233109

## 精选理由

常规快讯，保留列表

## AI 摘要

Sumanth_077 指出 MCP 仅解决连接层，上下文仍碎片化；Glean 通过预计算统一索引和知识图谱，使 Agent 上下文偏好提升 2.5 倍并节省 30% token。

## 正文

在企业 Agent 应用中，上下文往往散落在十几个系统里（Jira、Confluence、GitHub、Slack……），只能看到单一系统的智能体等于"盲人摸象"！

对 MCP 的关键批评：连通性 ≠ 上下文质量
@Sumanth_077 指出：
· MCP 解决的是连接层问题——用统一协议接入所有系统；
· 但现成的 MCP 工具各查各的源：Jira 一套 API、GitHub 一套 API，搜索逻辑、索引、排序互不相通，跨系统的信息关系没有任何共享理解；
· 结果是：当问题横跨多个系统时，模型被迫在运行时做数据的 join、去重、排序和关系推断。

这不是上下文工程，这是让模型在回答问题之外还要兼职做数据工程。后果是烧更多 token、答案更不准，且每一次查询都在重复付这个代价——"Harness 是连通的，但里面的上下文是碎的"。

Glean @glean 给出的方案：把 join 提前做
解法思路是将运行时的关联计算前置为预计算：
· MCP 调用不再直接打到各个源系统的 API，而是经过 Glean 的 MCP Gateway，路由到一个跨全公司数据（100+ 连接器）预先构建好的统一索引 + 知识图谱；
· 文档、人、项目、决策之间的关系提前解析好，智能体拿到的是已经完成关联、排序、去重的结构化上下文，而非五个 API 返回的原始碎片。

文中的对比数据：在约 175 条企业查询、相同模型和 Harness 的条件下，Glean 的上下文被偏好的比例是现成 MCP 工具的 2.5 倍，后者平均多耗 30% token。

集中式上下文层顺便解决了治理问题
MCP 规模化后的安全治理是真痛点，文章的方案是让安全随上下文层"自带"：
· 每次调用继承源系统权限（Jira 里看不到的工单，通过 Gateway 也看不到）；
· OAuth 走 Glean 的授权服务器，下游凭证不落在宿主机；
· 管理员控制工具分发，每次调用都做提示注入和恶意内容检查。