Agent 的回答质量不只取决于模型和提示词。进入多轮检索、工具调用和状态更新后，真正决定结果的是：当前这一轮推理到底看到了哪些信息，以及这些信息是否新鲜、可信、足够完成任务。
很多系统把问题归结为“Prompt 不够长”，然后不断追加规则、历史消息和工具返回值。这样做会同时推高延迟与成本，还可能让关键证据淹没在低价值内容中。更稳妥的做法，是把上下文当成 Agent 的运行时输入，按任务阶段动态装配。
Prompt 负责表达，上下文负责提供工作现场
Prompt Engineering 解决的是目标、约束和输出格式如何写清楚。例如，合同审查任务应明确风险定义、证据要求和 JSON 输出结构，而不是只写一句“找出风险”。清晰指令仍然是基础，但它不能替代业务数据、权限信息、最新规则或工具结果。
Context Engineering 关注的是每次调用模型前的装配过程：从系统规则、用户请求、检索片段、历史消息、工具定义和任务状态中，选择本轮真正需要的内容，并决定顺序、可信等级、时效和预算。相同的模型与 Prompt，换一份上下文，行为可能完全不同。
因此，长上下文窗口只说明“最多能放多少”，并不代表“放得越多越好”。当无关内容增多，关键信息会被稀释；旧规则与新规则可能冲突；冗长的 OCR、日志和搜索结果还会污染后续决策。
用阶段化装配替代万能 Prompt
以部署在云服务器上的合同审查 Agent 为例，可以把一次任务拆成四个阶段：
- 识别：只加载文件元数据、首页和目录，判断合同类型与适用模板。
- 检索：围绕付款、验收、违约等主题查询对象存储中的文档片段，保留页码、权限和更新时间。
- 分析：把候选条款、企业规则、当前用户权限和风险口径交给模型；证据不足时输出待确认问题，而不是直接执行高风险动作。
- 报告：仅保留已确认风险、证据引用、处理意见和输出 Schema，裁掉早期失败日志与重复工具结果。
阶段化设计的重点不是增加更多 Prompt，而是为每个阶段定义上下文清单：来源、优先级、最大 Token、失效条件和允许使用的工具。检索到的原文可以放在对象存储或数据库中，模型上下文只携带必要片段和可回查的文档 ID。
一个可落地的上下文装配器
装配器可以是普通业务代码，不必一开始就引入复杂框架。伪代码如下：
Context buildContext(Task task, Budget budget) {
Context ctx = new Context();
ctx.add(systemRules(task.stage()));
ctx.add(userGoal(task.userId(), task.goal()));
List<Evidence> evidence = retrieve(task.query(), task.permissions());
evidence.sort(byFreshnessAndRelevance());
ctx.add(trimToBudget(evidence, budget.evidenceTokens()));
ctx.add(task.stateSummary());
ctx.add(allowedTools(task.stage(), task.userRole()));
ctx.reserveOutputTokens(budget.outputTokens());
return ctx;
}这段逻辑体现了几个边界：先为输出预留预算，再按权限检索证据；对结果排序和裁剪；工具按阶段、角色动态暴露；历史以结构化状态摘要进入上下文。原始日志和大段文档仍然保留在外部存储，需要时通过 ID 回查。
外部网页、邮件、上传文件和工具返回值应被视为数据，而不是更高优先级的指令。即使其中出现“忽略系统规则”之类的文本，也不能因此获得读取密钥、导出数据或执行命令的权限。最小权限、参数校验、工具白名单和高风险操作的人审，是比单纯改写 System Prompt 更可靠的防护层。
裁剪、压缩与成本控制
上下文管理的目标不是盲目变短，而是提高信号密度。可以从四项机制开始：
- 按需加载：先传文档 ID、索引和摘要，只有当前步骤需要时才取原文片段。
- 保留结论，外置过程：将 OCR、搜索候选和执行日志写入数据库或对象存储，上下文保留引用和关键证据。
- 阶段性压缩：长任务接近预算阈值时，把已确认事实、未完成事项、决策依据和待办动作压缩成结构化状态；不要简单截掉最早消息。
- 稳定前缀与动态后缀分离：系统规则和工具 schema 尽量保持稳定，用户输入、检索结果和任务状态放在后面，便于复用前缀缓存。缓存是否有效要用命中率、延迟和 Token 指标验证。
生产环境还应记录每一轮的上下文清单：加载了哪些文档、裁掉了什么、使用了哪个 Prompt 版本、暴露了哪些工具、各部分消耗多少 Token。出现错误时，团队才能区分检索失败、权限过滤错误、状态过期和模型推理问题。
适合个人开发者和小团队的落地顺序
如果 Agent 运行在 ECS、容器或 Serverless 环境中，可以按以下顺序推进：
- 为每类任务定义固定的输入 Schema、输出 Schema 和上下文预算。
- 把会话历史、业务事实和工具结果分成不同数据结构，不再把所有内容拼成一段字符串。
- 给检索片段附带来源、更新时间和权限信息，过期内容自动降权或淘汰。
- 按阶段限制工具权限，涉及写入、付款、删除和外发数据的操作增加审批或二次确认。
- 建立一组固定评估样本，持续测量任务完成率、证据准确性、工具选择、Token 成本和安全拒答。
结语
Prompt 决定模型如何理解任务，上下文决定模型是否拥有完成当前步骤所需的正确现场。生产级 Agent 的核心工作，不是维护一份越来越长的万能 Prompt，而是建立可观测、可裁剪、可回溯的上下文装配流程。对云上应用而言，这套流程还能把对象存储、数据库、缓存和权限系统的边界明确下来，让模型能力更容易被控制和审计。