#核心论点
Prompt engineering 教你问更好的问题。
Context engineering 教你建更好的环境。
一个精心设计的 prompt，放在一个破碎的 context 里，输出的还是垃圾。一个平庸的 prompt，放在一个丰富、结构化的 context 里，每次都能产出有用的结果。
GitClear 分析了 2.11 亿行代码：AI 工具让代码量增加 10%，但质量指标崩了 60%。重构减少 60%，复制粘贴代码上升 48%，代码变动率增加 44%。
这不是模型的问题。这是 context 的问题。
#四个失败模式
#Context Pollution（污染）
虚假或过时的信息进入 window 并不断累积。模型信任 context 里的内容——如果坏数据在里面，下游所有输出都继承错误。
#Context Distraction（干扰）
太多无关信息淹没相关信号。20 万 token 的 window 如果有 18 万是噪音，模型无法区分重要和次要，它把 window 里所有内容当作近似等权重的信息处理。
#Context Confusion（混乱）
工具太多、指令冲突。MCP 出现之前这个问题存在，出现之后反而更严重——50 个工具定义塞进 system prompt，模型花注意力在它根本不需要的工具上，而不是手头任务。
#Context Clash（冲突）
同一 window 里有矛盾信息。你的 CLAUDE.md 说"用 pnpm"，项目 README 说"用 npm"。模型随机选一个，或者更糟，在两者之间来回切换。这就是为什么团队看到 agent 在不同 session 里行为不一致。
#三层架构
Context engineering 的核心 discipline 是设计什么信息、在什么时候、以什么结构到达模型。
Layer 1：什么进入 window（Selection）
Layer 2：它如何被结构化（Architecture）
Layer 3：什么时候刷新（Lifecycle）
大多数人只考虑 Layer 1，把所有东西都丢进 prompt，然后奇怪为什么模型会产生幻觉。研究清楚地表明：context 污染是累积的。一个幻觉的事实会滋生更多下游幻觉。
#Anthropic 的发现
Anthropic 内部研究发现：agent drift——AI 在长任务中逐渐失去连贯性——几乎完全是 context 管理问题，不是 reasoning 问题。他们的解决方案不是更好的模型，而是 compaction、结构化笔记、以及管理 window 内容的多智能体架构。
Manus（那个走红的自主 agent）发布了他们的 context engineering 教训。核心洞察：随着任务 context 增长，context 管理变成整个问题。其他所有能力在 context 退化时都会退化。
#正确的 context 架构
做得好的团队把 context 当作基础设施来对待：
CLAUDE.md 文件不是配置文件，是教学文档。 最好的 CLAUDE.md 读起来像给一位已经会编码、但不了解你代码库的新高级工程师的入职文档。
记忆层次结构 + 渐进式披露。 不是所有东西都需要同时放进 window。引导模型找到它需要的东西，而不是预加载所有东西。
关注点分离。 架构 context 在一个文件，编码规范在另一个，业务领域知识在第三个。模型加载当前任务需要的内容。
project/
├── CLAUDE.md # architecture + boundaries
├── .claude/
│ └── memory/
│ ├── MEMORY.md # routing document (< 200 lines)
│ ├── patterns.md # confirmed conventions
│ ├── decisions.md # architectural choices with reasoning
│ └── debugging.md # solutions to recurring problems
├── docs/
│ ├── architecture.md # system design (the model's map)
│ └── domain/ # business logic the model needs
└── src/ # the actual code
研究的关键洞察：加载了专门领域 context 的专门 agent，比通用 agent 在相同任务上产生的错误显著更少。 超过一半的有效 agent specifications 是 context，不是指令。
更多 context 架构，更少指令。这就是模式。
#知识图谱 vs 扁平 context
扁平 context——一个巨大的 CLAUDE.md、一个长的 system prompt、一个大的 README——线性扩展。每增加一个事实，只增加一个单位价值。
知识图谱组合扩展。每新加一个节点，连接到现有节点。关系涌现。整体大于部分之和。
这就是为什么工具-思维（tools-for-thought）社区无意中为 LLM 构建了完美架构。他们花了多年时间研究原子笔记（一个概念一个文件）、概念间的 wikilinks、内容导航地图、不同参与深度的渐进式披露。
原来这就是 agent 有效遍历知识库所需要的。
模式：
- 原子笔记（一概念一文件，可组合）
- wikilinks 作为语义连接（关系就是链接文本本身）
- 内容地图（路由文档，告诉 agent 去哪找）
- 用于过滤的元数据（启用渐进披露的 frontmatter）
- 声称式标题（文件名是 claim，不是 category）——不是 architecture-decisions.md，而是 we-chose-PostgreSQL-because-our-query-patterns-are-relational.md
当 agent 搜索时，仅看标题就能告诉它是否需要继续读。这是在文件命名层面的 context engineering。
#Tacit Knowledge 问题
你的 CTO 决定用 PostgreSQL 而不是 MongoDB，也许决定被写下来了。但她考虑的权衡、让她觉得显而易见但对其他人不可见的上下文——这些通常都丢失了。
会议过去是纯开销。现在你录制对话，agent 从中挖掘 claims、决定、行动项和战略转变。锁在人们头脑中的隐性知识变成结构化的图状态。
这不是没人读的会议总结。这是人类思维和 agent 外部化表示之间的主动同步。
#Agent 维护知识图谱
杀死每个 wiki、每个知识库、每个"单一真相来源"计划的是维护成本。有人必须保持更新，他们从来没做到。
Agent 不会因为维护而厌倦。不会因为赶会议而跳过更新。杀死每个知识管理系统的东西，正是 agent 被建造去做的事情。
一个结构良好的 context 图谱 + agent 运营商，与 wiki 有根本不同：
- agent 注意到两个笔记相互矛盾时，标记张力
- 注意到规范与代码库不同步时
- 摩擦信号在正常工作中自动累积
- 当足够多的观察堆积起来，agent 提议对系统本身进行结构性更改
它重构自己的指令。当当前的 context 系统造成太多阻力时，它演化自己的架构。
Context engineering 不是一次性设置。它是一个活的系统，每次 agent 工作时都会改进。
#执行步骤
- 审计你的 CLAUDE.md ——是配置文件还是教学文档？把它重写成给不了解你项目的高级工程师的入职培训
- 分离关注点 ——架构 context、编码规范、领域知识放在不同文件。加载任务需要的，不是所有东西
- 添加渐进披露 ——MEMORY.md 作为路由文档，控制在 200 行以内，详细主题文件从它链接出去
- 用 claim 命名 ——文件名回答"这相关吗？"而不需要打开。we chose X because Y.md，不是 decisions.md
- 挖掘你的会议 ——录制、提取 claims 和决定、加入图谱。对话中锁定的隐性知识是最大的 context 泄漏
- 让 agent 维护它 ——设置钩子标记矛盾、过时 context 和结构性漂移。agent 应该作为正常工作的副作用改进 context 系统
- 衡量 context 健康度 ——追踪 session 重解释时间、agent drift 率和跨 session 决策一致性。如果你的 agent 问同一个问题两次，你的 context 架构有个洞