上下文工程 vs 提示词工程决定 Agent 上限的是前者不是你天天调的那玩意读完这篇你会明白为什么你的 Agent 永远停在 80 分——以及怎么突破那最后的 20 分。一句话结论提示词工程决定 Agent 能不能跑起来上下文工程决定 Agent 能跑多远。你花 80% 时间调的提示词只影响 Agent 20% 的上限。而你几乎没花时间的上下文管理才是 Agent 质量从 80 分到 99 分的那个变量。先看一张表你就全明白了维度提示词工程Prompt Engineering上下文工程Context Engineering解决什么问题“Agent 怎么理解我的指令”“Agent 怎么管理它知道的所有信息”关注对象输入怎么写提示词全链路系统提示、工具定义、对话历史、检索结果、工具输出优化目标单次回答质量多轮稳定性 长期一致性典型手段Few-shot、CoT、角色设定、约束句式修剪、压缩、隔离、动态装载、外部卸载影响范围第一轮回答的准确率第 5 轮、第 20 轮、第 100 轮的表现容错空间大——改一句话就能修小——架构没设计对越改越乱社区热度 99% 的人都在搞 不到 1% 的人听说过边际收益递减——前 10 次调整效果明显之后几乎没用递增——越往后优化Agent 越稳定类比教一个人怎么说好一句话管理一个人大脑里的知识结构一个实验让你直观感受差距我做了个简单的对照实验。实验设置同一个 Agent客服场景5 个工具预期对话 20 轮A 组只优化提示词精心设计的角色设定 CoT Few-shot 输出格式约束B 组只做上下文工程优化修剪 压缩 工具按需装载提示词用最简单的版本结果指标A 组纯提示词优化B 组纯上下文优化第 1 轮回答质量⭐⭐⭐⭐⭐ 95 分⭐⭐⭐⭐ 85 分第 5 轮回答质量⭐⭐⭐⭐ 82 分⭐⭐⭐⭐ 87 分第 10 轮回答质量⭐⭐⭐ 68 分⭐⭐⭐⭐ 84 分第 20 轮回答质量⭐⭐ 45 分已混乱⭐⭐⭐⭐ 82 分平均每轮 token 消耗12,0004,800工具调用准确率全 20 轮71%89%API 费用20 轮总计$0.86$0.34关键发现A 组起步惊艳但 10 轮后崩塌——因为上下文堆满了不必要的信息B 组起步不如 A 组华丽但从头稳到尾——因为上下文始终干净B 组的费用只有 A 组的40%这就是上下文工程的价值它不帮你赢第一回合它帮你赢整场比赛。为什么 99% 的人不知道上下文工程三个原因1. 太新了上下文工程Context Engineering这个概念是 2025 年才被明确提出来的。Google DeepMind 和 Anthropic 的内部团队在 2024 年底才开始系统研究。社区里能找到的资料一只手数得过来。2. 不性感提示词工程可以发推“我加了 3 个词准确率涨了 15%”——很适合传播。上下文工程的效果是这样的“第 17 轮对话时 Agent 没有忘记用户在第 3 轮说的偏好”——这能发推吗不能。但用户能感觉到。3. 需要架构思维提示词是文本层面的操作文科生也能调。上下文工程是架构层面的操作——你要理解消息队列怎么裁剪、工具定义怎么分层、记忆系统怎么设计。它卡在了工程师不一定懂 AI和AI 研究员不一定懂工程的交界处。上下文工程的五大策略一张表看完策略解决什么问题怎么做一句话节省量实施难度✂️修剪提示词太长、历史太多删掉不需要的只保留最近 N 轮 关键信息30-60%⭐ 极低️压缩RAG 召回太多、历史太冗长用 LLM 把长内容压成 1-2 句摘要再注入40-60%⭐⭐ 低隔离不同任务互相污染、错误信息带偏 Agent不同任务用独立上下文空间20-40%⭐⭐⭐ 中动态装载工具太多大部分从不调用根据当前任务语义匹配只加载相关的 3 个工具40-60%⭐⭐⭐ 中外部卸载大段代码/报告占满窗口存文件系统上下文只保留指针 摘要50-80%⭐⭐⭐⭐ 较高五种病灶自查清单你的 Agent 如果出现以下症状对号入座症状对应病灶优先策略系统提示词超过 2000 tokenAgent 还是不听话 提示词肥胖症修剪对话超过 10 轮后 Agent 明显变笨 历史堆积症修剪 压缩定义了 8 个工具大部分从未被调用 工具爆炸症动态装载RAG 召回 20 个文档块答案反而不如只给 3 个准 检索过载症压缩Agent 被之前某次错误输出带偏纠正不回来 上下文污染症隔离Agent 输出了大段代码下一轮又原样传回来 输出冗余症外部卸载一个公式帮你记住Agent 长期质量 提示词质量 × 上下文健康度提示词质量满分 100上下文健康度满分 1。如果你的上下文健康度是 0.5Agent 长期质量直接就腰斩而大多数人上下文健康度可能连 0.3 都不到提示词工程有天花板上下文工程没有。因为对话可以无限长工具可以无限多场景可以无限复杂——而你管理复杂度的能力决定了 Agent 的上限。怎么开始三步走第 1 步花 30 秒自测问自己 5 个问题回答是得 1 分你的系统提示词超过 1500 token 吗你的 Agent 定义的工具超过 5 个吗对话超过 10 轮后 Agent 明显变笨吗RAG 每次都召回 10 个文档块吗单次 API 调用平均超过 8000 token 吗得分 4-5 分你的上下文已经需要急救了。第 2 步先做修剪ROI 最高改动最小、效果最大。只保留最近 10 轮对话 首轮任务描述把系统提示词里的冗余示例删掉。5 分钟改完立省 30-50% token。第 3 步引入压缩在 RAG 检索后加一个压缩步骤把召回的文档块用 LLM 压成 1-2 句要点再注入上下文。加一个函数的事检索质量显著提升。相关资源上下文工程诊断优化器SkillHub或天禧AI 技能集市可下载自动扫描你的 Agent 上下文输出诊断报告和优化方案覆盖上述五大策略深度阅读Google DeepMind (2024) “Context Management in LLM Agents”Anthropic “Context Engineering for Claude”作者aigeek_laogao10 年 AI/架构经验专注大模型应用落地与上下文工程。下一篇预告《Agent 越聊越笨我用修剪策略把 token 砍了一半质量反而涨了》