Anthropic 实现 8 倍产出提升：其背后的 Context Engineering 系统揭秘

Anthropic 的工程师们每天合并的代码量是去年同期的 8 倍。模型没有变，硬件没有变，团队规模也没有变。唯一改变的是 Claude 在开始工作前所看到的内容。

大多数开发者把时间花在编写更好的提示词（prompt）上。而 Anthropic 的工程师把时间花在构建更好的上下文（context）上。正是这一转变造就了那 8 倍的差距。

Anthropic 自己的研究直接指出：AI Agent 的质量在很大程度上不取决于模型本身，而取决于你提供给它的上下文。Claude 只能看到上下文窗口内的内容。窗口之外的一切都不存在。这意味着，一名严肃的 AI 工程师的全部工作不是编写巧妙的提示词，而是确保 Claude 在采取任何行动之前，已经掌握了完全准确的信息。

这种准则现在有了一个名字：上下文工程（Context engineering）。它正在取代提示词工程，就像两年前提示词工程取代手动脚本编写一样。

收藏并关注我

我是 Noisy，一名拥有 4 年经验的开发者。我构建 AI 系统、自动化流水线，并探索将技术转化为实际收入的方法。

为什么你的 AI Agent 会给出糟糕的回答

大多数人在 AI Agent 失败时会责怪模型。比如编辑了错误的文件、做出了错误的假设，或者犯了任何开发者都能看出来的明显错误。

问题几乎从来不在模型身上。问题在于上下文缺失。

1大多数人给 Claude 的内容   |  一个提示词
2Claude 真正需要的内容      |  知识、记忆、文件、
3                         |  规则、示例、工具、
4                         |  状态、过往操作

提示词只是一句话。而上下文是 Claude 运行的整个信息环境。一个能用的 Agent 和一个不能用的 Agent 之间的区别，几乎总是取决于那个环境中有什么——而不是运行的是哪个模型。

Anthropic 是这样描述的：大模型（LLM）只能看到上下文窗口中的内容。上下文是 AI 的操作系统。如果构建得不对，无论模型能力多强，一切都无法正常工作。

什么是真正的上下文

大多数人认为上下文就是他们在提问前粘贴的那段文本。那只是其中一层。一个经过精心设计的上下文包含七个协同工作的组件。

1记忆（Memory）           |  Agent 从过往会话中学到的内容
2指令（Instructions）     |  规则、约束、编码风格
3示例（Examples）         |  高质量输出的实际样子
4文件（Files）            |  相关的代码、文档、架构
5过往操作（Previous actions） |  Agent 已经尝试过的内容
6工具结果（Tool results） |  搜索和函数返回的内容
7状态（State）            |  任务当前所处的阶段

Claude 每采取一次行动，上下文就会增长。工具结果返回，新文件被读取，状态更新。Claude 查看新的上下文并决定下一步行动。这个循环才是 Agent 的实际运行机制——不是提示词，也不是模型，而是随着每一步操作不断演进的上下文。

1用户请求
2↓
3基于七大组件构建上下文
4↓
5Claude 决定行动
6↓
7工具执行
8↓
9结果加入上下文
10↓
11Claude 查看新上下文
12↓
13下一步行动
14↓
15重复直到完成

一个糟糕的 Agent 会在第二步破坏这个循环。由于上下文不完整，Claude 只能进行假设。假设错了，输出也就错了。大多数开发者通过重写提示词来解决这个问题。但真正的解决方法是正确地构建上下文。

三层上下文堆栈

Anthropic 建议从三个层面来考虑上下文。每一层都有不同的用途，并在 Agent 工作的不同阶段加载。

1全局上下文（Global Context）   |  始终存在，适用于每个会话
2项目上下文（Project Context）  |  在项目启动时加载
3任务上下文（Task Context）     |  针对特定任务加载

全局上下文是永久层。包括身份、核心规则、编码风格、Agent 绝对不能做的事情。这在不同会话之间永远不会改变，也不需要反复解释。

1全局上下文包含：
2- Agent 的身份和角色
3- 编码标准和风格规则
4- 安全约束
5- 绝对不能触碰或修改的内容
6- 如何处理不确定性

项目上下文是知识层。Claude 理解特定代码库所需的一切——架构、使用的模式、做出的决策及其原因、之前出现过的问题。

1项目上下文包含：
2- README 和架构概览
3- 包含项目特定规则的 AGENTS.md
4- 文件夹结构和命名规范
5- 测试要求和模式
6- 关键依赖项及其选择原因

任务上下文是执行层。包括正在处理的特定文件、当前的工单、直接目标、适用于此特定任务的约束条件。

1任务上下文包含：
2- 当前文件及相关文件
3- 本次会话的具体目标
4- 最近的变更及其结果
5- 当前测试结果
6- 此任务特有的约束

大多数开发者只给 Claude 提供任务上下文。Agent 在每次会话开始时都没有全局或项目上下文，不得不猜测它所不知道的一切。而错误正是源于这些猜测。

AGENTS.md —— 改变一切的文件

https://docs.claude.com/en/docs/claude-code/memory

这是任何严肃的 Claude Code 设置中最重要的一份文件。研究人员已将 AGENTS.md 确定为 AI 编码 Agent 上下文的新标准——它之所以出现在成千上万的生产代码库中，正是因为它确实有效。

AGENTS.md 是项目上下文永久存在的地方。Claude 会在每次会话开始时自动读取它。此后，它再也不需要被告知这些信息。

1# AGENTS.md
2
3## 架构
4使用 Next.js 前端和 Express 后端的单体仓库（Monorepo）。
5所有 API 路由都在 /api 中。切勿直接修改 /legacy。
6
7## 编码规则
8严禁使用 axios。请始终使用 fetch。
9每个组件：TypeScript、Tailwind、Server Actions。
10除页面外，禁止使用默认导出（default exports）。
11
12## 测试
13使用 Vitest 进行单元测试。使用 Playwright 进行端到端测试。
14每次提交前运行 npm test。
15严禁禁用失败的测试——修复它或上报。
16
17## Git
18严禁直接提交到 main 分支。
19务必提交包含清晰描述的 PR。
20每个 PR 必须关联一个 Linear 工单。
21
22## 严禁触碰
23src/payments/ - 任何更改都需要人工审批
24src/auth/tokens/ - 需要安全审查
25.env 文件 - 严禁读取或修改

这个文件中的每一条规则，都是 Claude 将来不会再犯的一个错误。项目运行的时间越长，AGENTS.md 就越具体、越有价值——它积累了 Agent 犯过的每一个错误以及团队确立的每一项约定。

驱动严肃 Agent 的上下文堆栈

优秀的 AI 工程师不会通过编写提示词来开始任务。他们会构建一个上下文堆栈——一种在 Claude 采取任何行动之前加载的结构化信息序列。

1第 1 步  |  加载全局上下文 - 身份、规则、风格
2第 2 步  |  加载项目上下文 - AGENTS.md、架构、文档
3第 3 步  |  在记忆中搜索相关的过往经验
4第 4 步  |  加载此特定任务的相关文件
5第 5 步  |  加载当前状态 - 测试结果、最近变更
6第 6 步  |  定义任务目标及明确的成功标准
7第 7 步  |  Claude 在信息充分的情况下采取行动

对比一下经过良好上下文工程的 Agent 与默认 Agent 的区别：

1糟糕的 Agent：
2问题 → Claude → 回答
3Claude 猜测它不知道的一切
4
5优秀的 Agent：
6问题
7↓ 搜索文档
8↓ 搜索记忆
9↓ 读取 AGENTS.md
10↓ 读取相关文件
11↓ 检查当前状态
12↓ Claude
13↓ 基于完整信息构建回答

第二个 Agent 并没有变得更聪明，它只是信息更充分。模型是完全一样的，但上下文不同。

记忆 —— 会话之间得以留存的上下文

Anthropic 对为上下文提供支持的记忆类型做了明确区分。大多数 Agent 只有一种——当前的对话。这就是为什么它们每次会话都从零开始。

1长期记忆（Long-term memory）   |  从过去所有会话中学到的一切
2短期记忆（Short-term memory）  |  本次对话中早些时候发生的事情
3工作记忆（Working memory）     |  当前上下文窗口中的内容

长期记忆是让 Agent 的价值随时间累积的关键。每一次会话都会增加记忆。每一个错误都会被记录。每一个成功的模式都会被存储。在一个代码库上运行了六个月的 Agent，对该项目的了解程度是任何提示词都无法复制的。

实际的实现方式是一个记忆文件——一个存在于对话之外的 Markdown 文档，Agent 在每次会话开始时读取它，并在结束时更新它。

1# 项目记忆
2
3## 架构决策
4- 选择 Supabase 而非 Firebase：实时性要求不高，需要 SQL 查询
5- 从 REST 迁移到 tRPC：实现全栈类型安全，2026 年 6 月
6
7## 有效的实践
8- 重构前提高测试覆盖率可防止回归
9- 将大型 PR 拆分为功能标志（feature flag）发布可减少审查时间
10
11## 无效的实践
12- 自动生成迁移：模式漂移导致了生产事故
13- Agent 并行写入同一文件：始终使用工作树（worktrees）
14
15## 常见模式
16- 身份验证问题几乎总是追溯到中间件顺序
17- 性能问题通常始于数据库查询层

每次会话都会读取此文件，每次会话也都会更新它。Agent 永远不会遗忘。

MCP —— 来自各处的上下文

上下文不仅来自仓库中的文件。生产环境的 Agent 需要来自团队工作所用的每一个系统的上下文——工单跟踪器、错误监控器、文档、数据库、沟通工具。

模型上下文协议（Model Context Protocol，简称 MCP）是 Claude 在无需为每个系统进行自定义集成的情况下，从外部系统提取上下文的方式。

1文件系统      |  本地文件、配置、代码库
2GitHub        |  工单、PR、提交历史、CI 结果
3Linear / Jira |  工单、优先级、项目状态
4Slack         |  做出的决策、讨论中的上下文
5Postgres      |  实时数据、模式、查询结果
6Google Drive  |  文档、规范、会议纪要
7Sentry        |  实时错误、频率、受影响用户

配置了 MCP 的 Agent 不仅仅能看到代码。它还能看到描述为什么需要此功能的工单、决定架构的 Slack 对话、显示用户如何触发错误的 Sentry 错误信息，以及修复方案需要遵循的数据库模式。

这就是完整的上下文。Claude 无需猜测，就能做出正确决策所需的一切。

上下文工程工作流

这就是一个经过正确上下文工程的任务从头到尾的样子。

与其这样：

1构建导出功能。

不如给 Claude 提供：

1目标
2导出功能正在阻碍免费用户向付费用户的转化。
3查看信号：/signals/export-too-hidden.md
4
5相关文件
6src/features/export/ - 当前实现
7src/components/ui/Button.md - 需要遵循的按钮模式
8tests/features/export.test.ts - 现有测试覆盖率
9
10架构约束
11阅读 AGENTS.md 部分：导出规则
12严禁直接修改计费集成
13
14成功标准
15所有现有测试通过
16新测试覆盖三种导出格式
17PR 已开启并关联 Linear 工单 EXP-47
18src/payments/ 无任何更改

任务相同，但上下文完全不同。输出结果不是渐进式的提升，而是本质上的不同，因为 Claude 是在信息充分的情况下做出决策，而不是在进行智能猜测。

这个周末的实践设置

第 1 天 - 构建三层上下文堆栈。编写一个包含身份和核心规则的全局上下文文件。创建包含项目架构、编码规范和严禁触碰列表的 AGENTS.md。设置一个在会话开始时加载、结束时更新的记忆文件。

第 2 天 - 通过 MCP 连接外部上下文。安装 GitHub 连接器，让 Claude 查看你的工单跟踪器和 PR 历史。安装文件系统连接器，使其能高效导航代码库。如果你的团队使用 Slack 或 Linear 进行决策，也请添加它们。

第 3 天 - 测试差异。用你旧的“仅提示词”方法和完整的上下文堆栈分别运行同一个任务。输出结果的差距就是 8 倍生产力提升的来源。

已经发生的转变

提示词工程关注的是寻找正确的措辞。而上下文工程关注的是构建正确的信息环境。

Anthropic 最优秀的 AI 工程师不会花时间去构思巧妙的提示词。他们花时间确保 Claude 在采取任何行动之前，已经掌握了完全准确的知识、记忆、文件、规则和状态。提示词只是最后 1% 的工作，而上下文占据了其余 99%。

一个提示词完美但上下文糟糕的 Agent 会犯下“聪明”的错误。一个提示词平庸但上下文完整的 Agent 会做出正确的决策。模型是一样的，但信息环境不同。

上下文是 AI 的操作系统。构建好它，8 倍的产出差距就不再是 Anthropic 才会发生的事，而会成为你代码库中的常态。

大多数开发者会继续重写他们的提示词，并纳闷为什么结果没有改善。而少数人会花一个周末构建一个合适的上下文堆栈，从此再也回不去旧模式了。

你的人生由你自己构建 —— 所以选择正确的道路。

/ 如果这很有用 —— 请关注我 /