核心论点

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 工作时都会改进。

执行步骤

  1. 审计你的 CLAUDE.md——是配置文件还是教学文档？把它重写成给不了解你项目的高级工程师的入职培训
  2. 分离关注点——架构 context、编码规范、领域知识放在不同文件。加载任务需要的，不是所有东西
  3. 添加渐进披露——MEMORY.md 作为路由文档，控制在 200 行以内，详细主题文件从它链接出去
  4. 用 claim 命名——文件名回答"这相关吗？"而不需要打开。we chose X because Y.md，不是 decisions.md
  5. 挖掘你的会议——录制、提取 claims 和决定、加入图谱。对话中锁定的隐性知识是最大的 context 泄漏
  6. 让 agent 维护它——设置钩子标记矛盾、过时 context 和结构性漂移。agent 应该作为正常工作的副作用改进 context 系统
  7. 衡量 context 健康度——追踪 session 重解释时间、agent drift 率和跨 session 决策一致性。如果你的 agent 问同一个问题两次，你的 context 架构有个洞