AI Agent 上下文工程怎么做？从提示词工程到 Context Engineering 的企业落地指南

企业做 AI Agent 项目，演示阶段往往一切顺利，上线后却陆续出现答非所问、任务跑到一半忘记目标、工具反复调错、Token 账单翻倍等问题。Google DeepMind 的 Philipp Schmid 对此有一个被频繁引用的判断：如今大多数 Agent 失败不再是模型失败，而是上下文失败。模型是引擎，而上下文工程是决定引擎往哪开、烧多少油的路况系统。本文结合 Anthropic、LangChain 和 Manus 等团队的公开实践，拆解上下文工程的核心方法，并给出企业落地的建设清单。

1. 从提示词工程到上下文工程

提示词工程解决的是"对模型说什么"，上下文工程解决的是"模型在回答的那一刻能看到什么"。两者差别在生产环境中会被迅速放大。

一个执行十几步任务的企业 Agent，每一轮都在累积状态：对话历史越来越长，工具返回的内容不可预测，检索到的文档相关性参差不齐。写到第十步时，最初那句精心设计的提示词早已被埋在大量过期工具输出和冗余历史中间。LangChain CEO Harrison Chase 对此的描述很直接：你无法预知第 14 步的上下文长什么样，因为前面 13 步可能拉进任何东西。

Karpathy 把大模型比作一种新的操作系统，上下文窗口就是它的内存——容量有限，需要精心管理。Cognition 则更干脆：上下文工程实际上是构建 AI Agent 的工程师的第一要务。对企业而言，这意味着 Agent 项目的核心工作量正在从"调提示词"转向"设计信息流"。

2. 上下文窗口是预算，不是仓库

很多团队的第一反应是换更长上下文的模型。这个方向收效有限。Chroma 发布的 Context Rot 报告测试了包括 GPT、Claude、Gemini、Qwen 在内的 18 个模型，结论是随着输入变长，即使简单检索任务的可靠性也持续下降。Anthropic 的工程博客解释了原因：注意力机制对 n 个 token 产生 n² 的两两关系，每增加一个 token 都在消耗有限的"注意力预算"。上下文是边际收益递减的资源，不是无底仓库。

Manus 公布的数据更能说明长任务的累积速度：一个典型任务平均需要约 50 次工具调用，输入输出 token 比接近 100:1。每次工具返回都留在上下文里，最初的任务指令逐渐被推向窗口中部——而那里恰好是召回最差的位置，这就是所谓"lost in the middle"。目标丢失不是模型的偶发缺陷，而是上下文失管后在长任务上的必然结果。

对企业项目，正确的起点是把上下文当预算来核算：系统提示词、工具定义、典型历史各占多少 token，模型开始干活之前是不是已经烧掉了三四成预算。

3. 四个基本操作：写入、选择、压缩、隔离

LangChain 把上下文工程归纳为四个可组合的操作，与 Anthropic、Manus 独立总结出的策略高度重合，可以视为当前行业的共识基线。

• 写入（Write）：把信息放到上下文窗口之外。工具返回超过阈值（例如 2 万 token）就写入文件系统，上下文里只留路径和前十行预览；任务计划写成 NOTES 或 TODO 文件而不是留在对话里。文件系统因此成为 Agent 的外置记忆。
• 选择（Select）：按需拉取，而不是预载全部。维护轻量标识符（文件路径、URL、查询语句），在当前步骤需要时才取数。同样的思路可以用于工具本身——对工具描述做检索，每一步只装载最相关的 5 到 8 个工具，LangChain 报告这能把工具选择准确率提升约 3 倍。
• 压缩（Compress）：分层进行。先截断可恢复的内容（文件内容删掉但保留路径），再对不可恢复的历史做结构化摘要——保留会话意图、已产出的结果、下一步计划，而不是简单截取前文。
• 隔离（Isolate）：把脏活累活交给子智能体。一个研究型子 Agent 可以读完 6100 token 的资料，只把 420 token 的结论返回给主 Agent，主上下文保持干净。串行工具调用超过五步的任务，都值得评估是否该拆。

4. Manus 的生产经验：缓存、文件系统与目标复述

Manus 团队在经历四次框架重写后公开的经验，补充了工程实现层面最容易被忽视的三点。

围绕 KV-Cache 设计。 生产环境中缓存命中的输入 token 成本约为未缓存的十分之一，缓存命中率直接决定延迟和账单。实践要点是保持提示词前缀稳定、上下文只追加不修改、序列化结果确定——哪怕在时间戳这种细节上不注意，缓存命中也会明显恶化。工具管理同理：不要动态增删工具定义导致缓存失效，而是用前缀约束或屏蔽的方式限制当前可用动作。

用复述对抗目标漂移。 Manus 的 Agent 会不断重写一个 todo 文件，把全局计划反复推到上下文末尾——也就是注意力权重最高的位置。这利用的是注意力机制的近因偏好，不需要改模型，只用自然语言就能持续校准方向。对企业流程类 Agent（审批、问数、工单处理），等价做法是让 Agent 维护一份随时重读的任务清单，而不是指望它"记住"开头说了什么。

保留错误现场。 反直觉但重要：不要把失败的调用和报错从上下文里抹掉。保留错误痕迹能让模型隐式更新判断，避免在同一个坑上重复失败。错误恢复能力恰恰是真实生产环境和学术评测之间最大的差距之一。

5. 企业落地的五个检查项

结合上述方法，企业自研或定制 Agent 时可以按这份清单逐项核对：

• 上下文预算：统计系统提示词、工具定义、历史消息、检索内容的 token 占比，开工前烧掉四成一上的要压缩或外置。
• 外置阈值：给工具返回设置硬性外置线（例如 2 万 token 写文件留路径），给整体上下文设置压缩触发线（例如窗口的 85%），Anthropic 的数据表明在 75% 左右停下的会话质量优于把窗口塞满的会话。
• 工具分层：常驻核心工具控制在十到二十个，其余能力通过脚本、命令行或按需检索提供，避免让模型在两百个工具里做选择。
• 目标外化：长任务必须有可重写的任务文件，压缩或重启后 Agent 能凭它恢复方向，而不是靠残留的对话碎片。
• 上下文质量度量：跟踪 Agent 引用过期信息的频率、重复检索已有数据的次数、关键指令在窗口中的位置，并把这些指标纳入项目验收标准和可观测体系。

对于私有化部署场景还要多想一层：国产开源模型在企业级显卡上的可用上下文窗口受显存约束，窗口越大推理越慢。上下文工程在这里不只是质量问题，更是硬件成本问题——压缩和外置做得越彻底，同等硬件能承载的并发越高。

6. 数舵科技如何做上下文工程？

数舵科技官网公开的AI 智能系统解决方案覆盖 AI Agent、RAG 知识库、私有化部署以及与 CRM、ERP、OA、工单等业务系统的集成。在定制项目中，我们把上下文设计前移到需求阶段：工具清单与分层策略、检索内容的装载时机、历史压缩规则、任务计划文件和外置存储的边界，都会在方案里写明，而不是上线后发现问题再补。

工程实现上，我们基于 LangChain4j 的企业级 Agent 框架支持工具结果外置、上下文窗口阈值压缩、子智能体隔离等模式，并配合统一的 Trace 记录每个任务的 token 构成与缓存命中情况，让上下文成本和质量都可度量、可复盘。如果企业的 Agent 试点已经出现"越跑越笨"或费用异常，通常从上下文预算分析入手，一到两周就能定位主要矛盾。

写在最后

上下文工程的本质，是在正确的时机把正确的高信号 token 摆到模型面前，其余一概拿走。它不依赖某个特定模型或框架，四个基本操作——写入、选择、压缩、隔离——在任何技术栈上都成立。当企业把上下文从"提示词加聊天记录"重新理解为一种需要核算、调度和度量的生产资源，Agent 才算真正具备进入核心业务流程的条件。

相关阅读：

• AI Agent 可观测性怎么建设？从调用链、质量到 Token 成本的生产治理指南
• 企业 AI 项目验收怎么做？从 RAG 知识库到 AI Agent 建立可量化标准
• RAG 知识库系统怎么做？企业检索增强生成的落地实践
• MCP 协议是什么？企业如何用 Model Context Protocol 打通 AI 与业务系统
• 企业多智能体协同怎么做？从单 Agent 到 Multi-Agent 的架构演进
• 企业 AI 私有化部署怎么选？知识库、智能体和内网应用的建设重点