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自进化智能体技术体系，目前已有系统化的深度学习资源可供参考。

 

分享嘉宾

 

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

ccia-666