Context才是瓶颈：AI Agent高级能力的上下文工程之道
Context才是瓶颈：AI Agent高级能力的上下文工程之道
本文属于「Hermes Agent自进化智能体深度解析」系列 | 模块七 · 第1篇
AI Agent的真正瓶颈不是算力，是上下文
2026年了，大模型的能力已经非常强大。但如果你仔细观察AI Agent在实际项目中的表现，会发现一个反直觉的现象：
Agent犯的错误，大多数不是因为"不会做"，而是因为"不知道"。
它修改了错误的文件——因为它不知道正确的文件在哪
它使用了过时的API——因为它不知道API已经更新了
它忽略了关键的约束——因为它不知道这个约束的存在
它重复犯同样的错误——因为它不记得上次犯过
所有这些问题的根源都是同一个：上下文不足或不当。
在高级AI Agent的工程实践中，上下文管理（Context Engineering）才是真正的瓶颈。模型能力再强，如果喂给它的上下文是错的、过时的、不完整的，输出就不可能正确。
Context Is the Bottleneck：五个维度的挑战
- Selection（选择）
问题：你的项目有1000个文件、10万行代码、100次对话历史、50条记忆记录。Agent的上下文窗口有限——选择哪些信息注入？
项目文件: 1000个
对话历史: 100轮
记忆记录: 50条
外部文档: 30个
Agent上下文窗口: ~200K tokens
选择问题: 哪些信息对当前任务最重要？
选择错误 → 要么关键信息缺失，要么无关信息占满窗口。
- Compression（压缩）
问题：即使选对了信息，原始数据的体积可能远超上下文窗口。如何在不丢失关键信息的前提下压缩？
原始: 10个文件，共30000行代码
需要: 浓缩到2000 tokens的上下文摘要
压缩策略:
- 保留函数签名和接口定义
- 省略实现细节
- 保留关键注释
- 省略样板代码
- Routing（路由）
问题：不同角色需要不同的上下文。Builder需要代码细节，Reviewer需要规范标准，Orchestrator需要全局视图。
Builder的上下文: 代码模板 + API规范 + 测试框架
Reviewer的上下文: 代码规范 + 安全标准 + 架构文档
Orchestrator的上下文: 项目进度 + 依赖关系 + 风险清单
给Builder看安全标准是浪费Token，给Reviewer看代码模板也不合适。
- 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 的工作:
- 从Memory Provider检索相关记忆 → 5条
- 读取相关文件 → 3个文件，压缩到500 tokens
- 注入对话历史 → 最近5轮
- 添加工具定义 → 当前可用的10个工具
- 组装为完整上下文 → 总计80K tokens
- 检查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等方向有系统化工程实践，推动智能体技术在社交媒体、医疗、金融、法律、教育等专业场景落地。
技术交流
赵老师 13311271064
浙公网安备 33010602011771号