Context才是瓶颈：AI Agent高级能力的上下文工程之道

本文属于「Hermes Agent自进化智能体深度解析」系列 | 模块七 · 第1篇

---

AI Agent的真正瓶颈不是算力，是上下文

2026年了，大模型的能力已经非常强大。但如果你仔细观察AI Agent在实际项目中的表现，会发现一个反直觉的现象：

Agent犯的错误，大多数不是因为"不会做"，而是因为"不知道"。

• 它修改了错误的文件——因为它不知道正确的文件在哪
• 它使用了过时的API——因为它不知道API已经更新了
• 它忽略了关键的约束——因为它不知道这个约束的存在
• 它重复犯同样的错误——因为它不记得上次犯过

所有这些问题的根源都是同一个：上下文不足或不当。

在高级AI Agent的工程实践中，上下文管理（Context Engineering）才是真正的瓶颈。模型能力再强，如果喂给它的上下文是错的、过时的、不完整的，输出就不可能正确。

---

Context Is the Bottleneck：五个维度的挑战

1. Selection（选择）

问题：你的项目有1000个文件、10万行代码、100次对话历史、50条记忆记录。Agent的上下文窗口有限——选择哪些信息注入？

项目文件: 1000个
对话历史: 100轮
记忆记录: 50条
外部文档: 30个

Agent上下文窗口: ~200K tokens

选择问题: 哪些信息对当前任务最重要？

选择错误 → 要么关键信息缺失，要么无关信息占满窗口。

2. Compression（压缩）

问题：即使选对了信息，原始数据的体积可能远超上下文窗口。如何在不丢失关键信息的前提下压缩？

原始: 10个文件，共30000行代码
需要: 浓缩到2000 tokens的上下文摘要

压缩策略:
  - 保留函数签名和接口定义
  - 省略实现细节
  - 保留关键注释
  - 省略样板代码

3. Routing（路由）

问题：不同角色需要不同的上下文。Builder需要代码细节，Reviewer需要规范标准，Orchestrator需要全局视图。

Builder的上下文: 代码模板 + API规范 + 测试框架
Reviewer的上下文: 代码规范 + 安全标准 + 架构文档
Orchestrator的上下文: 项目进度 + 依赖关系 + 风险清单

给Builder看安全标准是浪费Token，给Reviewer看代码模板也不合适。

4. Permissioning（权限）

问题：不是所有上下文都应该对所有角色可见。生产数据库密码不应该出现在Builder的上下文中。

权限控制:
  Builder: 可见代码文件、API文档、测试框架
           不可见生产环境配置、密钥
  Reviewer: 可见代码文件、安全策略、合规标准
            不可见用户个人信息
  Orchestrator: 可见项目全局信息、进度、风险
                不可见技术实现细节

5. Freshness（新鲜度）

问题：上下文信息会过时。5分钟前的文件内容可能已经被另一个Agent修改了。

新鲜度管理:
  实时读取: 文件当前内容（最新）
  缓存读取: 最近一次读取的内容（可能过时）
  记忆读取: 历史记忆中的内容（可能严重过时）

策略: 关键操作前强制刷新，非关键操作可使用缓存

---

Memory Provider vs Context Engine：两个不同的系统

很多人混淆了"记忆"和"上下文"，但它们是两个不同的系统：

Memory Provider（记忆提供者）

职责：跨会话的知识持久化

• 存储什么？长期经验、项目知识、用户偏好、历史决策
• 检索方式？按相关性检索
• 更新频率？每次执行后更新
• 典型实现？Honcho记忆层

Memory Provider 的数据:
  "在社交匹配项目中，用户画像的'自我描述'字段信息密度最高"
  "上次使用FastAPI框架，团队偏好异步API设计"
  "代码审查中发现过3次SQL注入问题，需要加强检查"

Context Engine（上下文引擎）

职责：当前上下文的组织与压缩

• 组织什么？将记忆、文件、对话、工具定义组合为当前上下文
• 如何组织？检索、排序、压缩、注入、刷新、摘要
• 更新频率？每轮交互实时更新
• 典型实现？Hermes的Message Assembly阶段

Context Engine 的工作:
  1. 从Memory Provider检索相关记忆 → 5条
  2. 读取相关文件 → 3个文件，压缩到500 tokens
  3. 注入对话历史 → 最近5轮
  4. 添加工具定义 → 当前可用的10个工具
  5. 组装为完整上下文 → 总计80K tokens
  6. 检查Token预算 → 在限额内 ✓

简单来说：Memory Provider管"长期记忆"，Context Engine管"当前注意力"。一个是仓库，一个是工作台。

---

Pluggable Context Pipeline：可插拔的上下文管道

Context Engine的核心是一个可插拔的管道（Pipeline），每个环节都可以独立定制：

[Retrieval] → [Ranking] → [Compression] → [Injection] → [Refresh] → [Summarization]
   检索        排序         压缩           注入         刷新         摘要

Retrieval（检索）

从多个来源检索候选上下文：

• 文件系统：相关的代码文件
• 记忆层：相关的历史经验
• 对话历史：之前的对话内容
• 外部服务：通过MCP获取的实时数据

Ranking（排序）

对检索到的候选上下文按相关性排序：

• 与当前任务的相关程度
• 信息的新鲜度
• 来源的可信度
• Token效率（信息密度）

Compression（压缩）

将排好序的上下文压缩到Token预算内：

• 摘要化：长文本→关键信息摘要
• 结构化：非结构化文本→结构化数据
• 选择性保留：保留核心信息，省略细节

Injection（注入）

将压缩后的上下文注入到消息中：

• 系统提示词
• 用户消息补充
• 工具定义
• 示例对话

Refresh（刷新）

在长时间运行的任务中定期刷新上下文：

• 重新读取可能已变更的文件
• 更新过时的缓存信息
• 调整上下文的优先级

Summarization（摘要）

在上下文即将溢出时，将旧信息摘要化：

• 对话历史 → 关键决策摘要
• 详细文件内容 → 接口定义摘要
• 完整执行日志 → 关键步骤摘要

---

为什么Context Engineering是高级Agent的核心能力？

当你理解了上下文管理的五个维度和可插拔管道的设计，就会明白一个关键事实：

决定AI Agent能力上限的不是模型参数量，而是上下文工程的质量。

一个拥有顶级模型但上下文混乱的Agent，表现远不如一个使用中等模型但上下文精准的Agent。

这就是为什么Hermes Agent将Context Engine作为核心基础设施来设计——它不只是一个辅助组件，而是整个系统智能水平的决定性因素。

---

延伸阅读与交流

本文涉及的Hermes Agent自进化智能体技术体系，目前已有系统化的深度学习资源可供参考。中国通信工业协会通信和信息技术创新人才培养工程项目办公室将于近期组织相关技术专题分享，围绕本文讨论的AI原生架构、智能体工作流、自进化数据层等方向展开系统讲解。

专题信息

• 主题：AI原生Hermes自进化智能体系统
• 时间：2026年7月4-5日（周末）
• 形式：线上直播
• 内容方向：AI原生架构 · Hermes智能体拆解 · 全栈扩展 · 智能自动化 · 产品级实战 · Context Engine · 自进化数据层

分享嘉宾

王老师（Gavin），Agentic AI企业联合创始人兼CTO，十余年硅谷AI系统工程经验。长期深耕NLP、强化学习、可控AI与智能体系统架构，提出"语言即控制（Language as Control）"原创范式，在RLHF、PPO、DPO、GRPO等方向有系统化工程实践，推动智能体技术在社交媒体、医疗、金融、法律、教育等专业场景落地。

技术交流

• 联系人：Sam
• WeChat：NLP_ChatGPT_LLM
• Hermes Agent技术文档：https://hermes-agent.nousresearch.com/docs/