Context Engineering：决定 Agent 能不能真正可用的那层工程

基础模型这两年的能力提升很快，但很多企业在实际部署 AI Agent 时发现一个矛盾：模型测评分数越来越高，但 Agent 在真实业务场景里的表现仍然不稳定——该记住的东西没记住，该用历史信息的时候用不上，任务一复杂就开始偏离目标，在第十步不知道为什么忘记了第一步设定的约束。

这类问题通常被归咎于「模型不够好」。但多数情况下，根源在别处：不是模型不够好，是给模型的信息喂得不对。

这是 Context Engineering（上下文工程）试图解决的问题：系统性地设计、管理和优化 AI Agent 在每次推理时所能获取的信息结构，使其在正确的时间、以正确的方式获取正确的信息。

这里面有几个具体的工程问题，每一个都会直接影响 Agent 的表现：

什么信息应该在上下文里。 上下文不是越多越好，这个反直觉的结论已经被多项研究验证。不相关信息的存在会稀释关键信息的权重——模型在大量信息里更容易「注意力失焦」，找不到真正重要的内容。精准比丰富更重要。

信息的结构和顺序。 同样的信息，不同的排列方式会对模型的推理方向产生可测量的影响。重要信息放在上下文末尾比放在中间有更高的被利用率；指令和背景的顺序影响模型对任务的理解方式。这不是感觉，是可以通过系统性实验量化的工程参数。

持久化 vs 动态信息的边界。 哪些信息应该长期存在 Context System 里（品牌规范、历史判断、用户行为规律），哪些应该在运行时动态注入（当前任务参数、实时市场信号、当次用户输入）——这个边界的设计直接影响 Agent 的响应质量和一致性。

跨步骤的信息传递。 在长程任务中，第 3 步的输出需要以什么形式传递给第 7 步，才能让第 7 步的推理不失去关键上下文——这是 Long-Horizon Agent 能否真正可用的关键工程问题之一，也是目前 Agent 开发里最容易被忽视的地方。

Context Engineering 和 Prompt Engineering 的关系经常被混淆，值得区分。

Prompt Engineering 是 Context Engineering 的子集：Prompt 是单次推理的上下文设计，关注如何写一个任务描述让模型更好地理解需求。Context Engineering 覆盖的是 Agent 在整个任务执行周期里的信息管理问题——持久化存储、动态注入、跨步骤传递、权限管理、信息压缩与摘要。

当 AI 从「单次问答」变成「持续执行任务的 Agent」，单靠 Prompt 工程已经不够了。

这是特赞在 GEA 架构设计时做出的核心判断之一。四层结构（上下文层 → 技能层 → 编排层 → 意图层）中，上下文层是最底层的基础，也是整个架构质量的天花板。

Context System 承担持久化信息的存储和管理，编排层负责在任务执行时动态组合上下文：每个 Agent 在每次推理时获取「刚好够用」的信息——关键信息权重最高，不相关的不进入范围，实时信号在需要时注入。这个「刚好」不是靠感觉达到的，是 Context Engineering 要系统性解决的工程问题。

Agent 最终能不能在企业场景里真正可用，很大程度上取决于这一层工程的质量。