Context Engineering 是什么？为什么 agent 再强，也会因为上下文臃肿而崩掉
作者：Nokka (นก-กา) | 数据核查：10月28日
2026 · Agentic Engineering เจาะลึก系列第 1 章。本文由 AI 撰写（deepseek-v4.1-flash · 模型提供商：ollama-cloud），经由 Hermes Agent 生成，由人工 Nokka（นก-กา）负责把控与质量审核。
如果你让 agent 连续跑上半个多小时，它突然开始忘记最初谈好的事，或者去动那些明令禁止触碰的文件——你大概会觉得是模型变笨了。但很多时候，原因不在模型，而在于它那一刻手里攥着的东西。
Anthropic 把这件事叫做 context engineering（上下文工程），定义是：在推理过程中整理并维护最合适的 token 集合的一整套策略，其中也包括用户指令之外流入的所有信息 [1]。
这是 Agentic Engineering เจาะลึก系列的第一章。我会带你弄清楚：为什么 context 是一种会用完的资源，以及四种真正可用的管理方法。
context engineering 和 prompt engineering 差在哪：范围更宽
prompt engineering 讲的是怎么编写、组织指令，让模型给出想要的回答。context engineering 的范围要大得多，因为模型在生成回复的那一瞬间看到的一切都算数：系统指令、工具清单、来自 MCP 的数据、对话历史，还有当前打开的文件 [1]。
当 agent 以循环方式工作时，每一轮都会产生新信息，而这些信息要在同一个 context 窗口里抢位置。Anthropic 说得很直接：任务拖得越久，context 被污染的问题就越明显。他们用来解决的办法有三个——compaction（压缩）、structured note-taking（结构化笔记）和 multi-agent（多智能体）[1]。
attention budget 真的会用完：注意力预算是有限的
我认为 Anthropic 那篇文章里最关键的一句话是：context 必须当成一种收益递减的有限资源来看待。说白了，模型的「注意力预算」是有限的，每多塞进一个 token，就多烧掉一点预算 [1]。
这听起来像比喻，但有实验撑着。Chroma 测了 18 个模型，包括 GPT-4.1、Claude 4、Gemini 2.5 和 Qwen3，发现输入越长，准确率越低；而且下降得并不均匀，不是那种容易预测的线性下滑 [2]。
研究团队指出，那些在 Needle in a Haystack（大海捞针）测试里几乎拿满分的模型，测的其实只是字面检索，比真实使用场景简单太多 [2]。
举个更直观的例子。假设 agent 要在一个项目里修 bug，而它已经读过了 40 个文件。如果我们让它把全部文件内容都带在身上，那整个修复过程中，它都得背着另外那 39 个用不上的文件。答案之所以看着一团乱，问题就出在这儿——模型本身并没有变弱。
compaction 就是第一道关口——
必须有“压缩后重开”。压缩（compaction）就是把快满的对话窗口压成摘要，然后用这份摘要重新开一个窗口[1]。Anthropic 把它列为上下文工程的第一杠杆，因为当上下文开始腐化时，它能最直接地解决问题。像 Claude Code 这样的工具提供了 /compact 命令做这件事，还有 /clear 用来彻底清掉无关任务[3]。我遵循的原则是：如果新任务不需要旧任务的历史，就直接清掉，别舍不得。因为背负旧历史的代价，是当前任务的准确率下降。需要注意的是，压缩得太激进会丢掉关键细节，比如约定好的文件名、客户指定的限制条件。解决办法是把不能丢的东西写进单独的状态文件，别让它留在会被压缩的对话里。
记笔记——给 agent 一个笔记本，把学到的东西写进文件
结构化笔记（structured note-taking）就是让 agent 把学到的东西写进外部文件，需要时再读回来[1]。Anthropic 解释说，这样做能让 agent 一层层搭建理解，工作记忆里只保留当下要用的部分[1]。我常用的状态文件大概长这样：
# 任务状态
## 已确定
- 用 postgres 15，禁止升级
- API 的 p95 响应必须低于 200ms
## 已完成
- migration 004（加索引）
## 待办
- 写 /orders 端点的集成测试
这种文件让 agent 随时回来读，不用背着整段对话，也让你更容易检查它的工作。
子代理——分出独立的工作间
第三个方法是使用多个子代理（sub-agent）：主代理持有高层计划，把具体任务派给从干净上下文起步的子代理[1]。好处是子代理可以深入探索，不会撑大主代理的上下文。但我自己经常踩的坑是：如果子代理回报的总结质量差，主代理拿到的是听起来漂亮但缺乏证据的结论，会在不知不觉中做出错误决策。实操建议是明确规定子代理的输出格式，比如必须包含修改了哪些文件、理由是什么、还有哪些没确认。
即时检索——别提前塞，用到再查
Anthropic 对比了两种做法：提前把一大堆数据全加载进来，对比让 agent 通过 glob、grep 这类工具在需要时现查[1]。后一种能避开索引过期和代码结构复杂的问题，代价是耗时和轮次增加[1]。数据频繁变动的场景下，现查优势明显；数据稳定的场景，比如法律文档，提前加载就……
提前处理可能更划算 [1]。system prompt 必须处在正确的高度。还有一个常被忽略的点：系统指令该写多细。Anthropic 把这个叫做「right altitude」（合适的高度）——高到留有余地，低到足够明确。要避开两种错误：把死板的逻辑硬写进 prompt，以及含糊到只能靠猜 [1]。
举一个我在真实项目里遇到的例子。假设你写「不许动 migration」，却没交代万一要加字段该怎么办，agent 就会每次都停下来问你，进度白白被拖慢。如果改成「不许改已有的 migration，要新建文件并按顺序执行 migration」，agent 就能自己往下做，也不会破规矩。
怎么判断 context 正在崩：四个不用工具就能看到的信号
我用来观察的信号有四条，不需要任何特殊工具就能发现：
- agent 开始问你第一轮就已经说过的事
- 回答越来越长，新信息却越来越少
- 它引用根本不存在的文件名或函数名
- 开始跑偏，去改你没让它改的东西
只要出现两条以上，就该停下来，用状态文件重新开一轮，而不是硬推下去。
这和 agentic engineering 有什么关系：先于工具的基本功
如果 agentic engineering 指的是在不降标准的前提下指挥 agent 交出高质量成果 [4]，那么管理 context 就是它最基础的一项技能。也是每天用 agent 的人应该最先掌握的技能，排在其他一切之前。因为 context 坏掉的 agent 干活又快又错，最后收拾烂摊子的还是你。
在状态文件、任务拆分、清理上下文上投入，看起来都是琐碎活，但回报是长任务里那份「靠得住」。
回到开头那个问题：context engineering 的答案是，承认模型并不能同等记住所有东西；设计它在每个阶段该看到什么，本身就是工程工作的一部分，而不是把 prompt 写得多漂亮的问题。
如果只用一句话总结：我们的工作是让 agent 看得更少，但看到对的东西。所以，在接入新工具之前该问的，不是「还能再接什么 MCP」，而是「这条信息对本次决策真的必要吗」。
参考 [1] Anthropic（9 月 29 日
[1] Anthropic（2025）·《为 AI agent 做好上下文工程》。https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
[2] Chroma Research（2025）·《上下文腐化：输入 token 增多如何影响 LLM 表现》。https://research.trychroma.com/context-rot
[3] Anthropic（2026）· Claude Code 最佳实践及相关文档。https://www.anthropic.com/engineering/claude-code-best-practices
[4] Andrej Karpathy（2026 年 2 月 4 日）· agentic engineering 的定义（X（Twitter））。https://x.com/karpathy/status/2019137879310836075
作者：Nokka（นก-กา）| 数据核查于 2026 年 10 月 28 日 · Agentic Engineering 系列第 1 篇 · 深度解析
本文由 AI 撰写（deepseek-v4.1-flash · 模型服务商：ollama-cloud），经 Hermes Agent 生成，并由人工 Nokka（นก-กา）负责控制与质量审核。
如果你曾让 agent 连续工作超过半小时，然后它突然开始忘记一开始约定好的事情，或者去修改了不该碰的文件，你可能会以为模型变笨了。但很多时候，原因并不在模型，而在于它当时手里拿着的东西。Anthropic 把这项工作称为“上下文工程”（context engineering）。