如果你使用过 Cursor、Claude Code 或其他 AI Coding 工具，应该遇到过这样的情况：
同样一个模型，同样一句需求，在一个项目里表现很好，换到另一个项目却经常答非所问。
你让它修改一个接口，它改错了文件；让它增加一个功能，它没有遵守项目现有的架构；明明项目里已经有一个工具类，它却重新写了一套；甚至你已经告诉它某个规则不能违反，它还是会继续这么做。
很多时候，问题并不是模型不会写代码。
而是它不知道足够多的东西。
这也是 Context Engineering 开始受到关注的原因。
如果说 Prompt Engineering 关注的是「我应该怎么告诉模型」，那么 Context Engineering 更关注：为了让模型完成任务，我到底应该让它知道什么？
这两个问题看起来很接近，但面对复杂 Agent 时，区别会越来越明显。
1. Prompt Engineering 解决什么问题
Prompt Engineering 并没有过时。
在简单任务中，一个好的 Prompt 仍然非常重要。
例如：
请把下面的 方法重构一下：
要求：
1. 保持接口兼容；
2. 降低数据库查询次数；
3. 增加异常处理；
4. 给出修改后的代码。
这里已经包含了任务、约束和输出要求。
对于一次性的文本生成、代码生成、总结、分类等任务，这样的 Prompt 通常已经足够。
但软件开发中的很多任务并不是一次性的。
例如：
给这个项目增加用户注册功能。
这句话真正包含的信息其实非常少。
Agent 要完成它，至少还需要知道：
项目是什么框架？
目录结构是什么？
Controller 怎么写？
Service 怎么写？
数据库表在哪里？
Model 怎么定义？
验证规则是什么？
异常怎么处理？
返回格式是什么？
认证体系是什么？
测试怎么写？
哪些代码不能修改？
如果这些信息没有进入 Agent 的上下文，那么你即使把 Prompt 写得再漂亮，也很难得到稳定的结果。
所以，复杂任务真正的问题开始从：
「怎么写 Prompt？」
变成：
「怎么给 Agent 准备一个足够好的工作环境？」
这就是 Context Engineering 的核心。
Anthropic 将 Context 描述为 Agent 的关键但有限资源，并强调上下文需要被持续地策划、管理和压缩，而不是简单地把更多信息塞进 Context Window。
2. Context 到底是什么
Context 很容易被理解成「Prompt」。
实际上，Prompt 只是 Context 的一部分。
对于一个 Agent 来说，可以把 Context 粗略理解为：
Context
│
├── System Instructions
├── User Request
├── Project Rules
├── Conversation History
├── Repository Context
├── Retrieved Knowledge
├── Tool Definitions
├── Tool Results
├── Memory
├── Task State
└── Previous Actions
例如一个 Coding Agent 正在修改 PHP 项目。
它当前真正需要的 Context 可能是：
任务：
增加用户注册接口。
项目规则：
使用 Hyperf 3.1。
Controller 不直接访问数据库。
业务逻辑放在 Service。
统一使用项目异常体系。
相关代码：
app/Controller/UserController.php
app/Service/UserService.php
app/Model/User.php
数据库：
users 表结构。
测试：
tests/Controller/UserControllerTest.php
当前状态：
代码已经修改，但测试失败。
这些内容共同构成了 Agent 当前所处的「工作环境」。
因此，Context 并不等于：
Prompt + 更多文字
更准确地说：
Context 是 Agent 在当前任务中能够看到、依赖和使用的信息集合。
这也是为什么 Context Engineering 比单纯 Prompt Engineering 更接近一个系统工程问题。
3. 为什么“更多 Context”并不一定更好
这里有一个很容易犯的错误：
既然 Context 很重要，那是不是把所有东西都塞进去就行？
当然不是。
假设一个项目有：
1000 个 PHP 文件
200 张数据库表
5000 条历史 Commit
100 篇技术文档
几十万行日志
你全部交给 Agent，并不意味着它会因此变得更聪明。
相反，大量无关信息可能让 Agent 更难找到真正重要的内容。
例如你要求：
修复 UserController 的参数验证问题。
结果给它：
整个 Repository
+
全部 Git 历史
+
所有数据库表
+
所有日志
+
所有 API 文档
真正有价值的信息可能只有：
UserController
UserRequest
ValidationService
相关测试
项目验证规范
所以 Context Engineering 的关键不是：
让 Agent 获得更多信息。
而是：
让 Agent 在正确的时间获得正确的信息。
Anthropic 的实践文章也特别强调了这一点：Context 是有限资源，Agent 的上下文管理需要考虑信息选择、压缩、隔离和任务阶段，而不是无限增加输入内容。
4. Context Engineering 到底在做什么
如果把 Context Engineering 简单化，可以把它理解成四件事情：
获取
↓
筛选
↓
组织
↓
维护
首先是获取。
Agent 需要知道哪些信息？
例如：
Repository
Documentation
Database
Knowledge Base
Memory
Tools
然后是筛选。
并不是所有信息都与当前任务相关。
例如：
当前任务：修改支付回调
高相关：
PaymentService
PaymentController
PaymentCallback
支付接口文档
相关测试
低相关：
用户头像
文章系统
后台菜单
日志系统
接下来是组织。
即使信息本身正确，如果组织方式混乱，Agent 仍然可能理解错误。
例如与其给它几十个散乱规则，不如明确组织：
项目规范
架构约束
编码规范
当前任务
相关文件
测试要求
完成标准
最后是维护。
Agent 完成一个复杂任务往往不是一次调用。
它可能：
读取代码
↓
修改代码
↓
运行测试
↓
发现错误
↓
读取错误信息
↓
修改代码
↓
重新测试
每一步都会产生新的状态。
因此 Context 也会不断变化。
这也是 Agent 与普通 Chatbot 的一个重要区别。
5. RAG、Memory 和 Tools 都属于 Context 的一部分
理解这一点之后，很多 AI 技术之间的关系会变得清楚。
例如 RAG。
传统 RAG 通常是：
用户问题
↓
检索知识
↓
相关文档
↓
LLM
↓
回答
从 Context Engineering 的角度看，本质上是：
在模型回答问题之前，为它动态准备相关 Context。
Memory 也是类似的。
例如 Agent 之前已经知道：
用户喜欢 PHP / Hyperf。
项目使用 MySQL。
项目采用 Redis。
这些历史信息如果在当前任务中有价值，就可以进入当前 Context。
Tools 同样如此。
当 Agent 调用：
search_code()
工具返回：
UserService.php
UserController.php
UserRepository.php
这些结果也会成为 Agent 下一步决策所依赖的 Context。
所以可以把它们放在一起理解：
Context
│
┌────────────┼────────────┐
↓ ↓ ↓
RAG Memory Tools
│ │ │
知识检索 历史状态 外部能力
│ │ │
└────────────┼────────────┘
↓
Agent
这也是为什么 Context Engineering 与 RAG、Memory、Tool Calling、MCP 最终会产生非常紧密的联系。
6. Context Engineering 在 AI Coding 中尤其重要
AI Coding 是理解 Context Engineering 最好的场景之一。
假设你对 AI 说：
给这个项目增加 Refresh Token。
如果 AI 只看到这一句话，它只能依靠自己的经验猜。
但如果它能够获得：
项目结构
+
现有登录代码
+
Token 服务
+
数据库结构
+
项目编码规范
+
异常规范
+
测试代码
+
当前 Git 状态
它对项目的理解就完全不同了。
例如项目已经存在：
app/
├── Controller/
├── Service/
├── Model/
├── Middleware/
└── Exception/
并且项目规定：
Controller
↓
Service
↓
Repository
↓
Model
如果 Agent 不知道这个规则，它可能直接在 Controller 中写数据库逻辑。
代码本身可能完全可以运行。
但它已经破坏了项目架构。
所以 AI Coding 中一个非常重要的问题是：
如何让 Agent 理解“这个项目应该怎么写”，而不仅仅是“这段代码应该怎么写”。
这也是 Cursor Rules、AGENTS.md、项目文档、代码库索引等机制存在价值的原因。
它们本质上都是在向 Agent 提供项目 Context。
7. Context 的质量比 Context 的数量更重要
对于 Agent 来说，可以简单建立一个判断：
Context Quality
≈
相关性
+
完整性
+
一致性
+
时效性
+
可验证性
例如：
“项目使用 Redis”
这是一条信息。
但如果进一步告诉 Agent：
项目使用 Redis 7。
缓存统一通过 CacheService 操作。
禁止 Controller 直接访问 Redis。
分布式锁使用 Redis LockService。
缓存 Key 必须使用项目统一前缀。
这就变成了更有价值的 Context。
因为它不仅告诉 Agent「是什么」，还告诉它：
怎么用
在哪里用
什么时候不能用
应该遵守什么规则
2026 年的一些研究已经开始尝试把 Context Engineering 作为独立的工程方法进行研究。例如相关研究将 Context 的质量进一步拆分为相关性、充分性、隔离性、经济性和来源可追溯性等维度。不过这些仍属于快速发展的研究领域，不应该把某一种学术框架当成行业统一标准。
这一点需要特别说明：
Context Engineering 目前并不是一个已经标准化的协议或统一规范。
它更像是 AI Agent 工程实践中逐渐形成的一种方法论。
8. 从 Prompt Engineering 到 Context Engineering
两者并不是替代关系。
更准确的关系应该是：
Prompt Engineering
↓
告诉模型“应该怎么做”
│
▼
Context Engineering
↓
提供模型“完成任务需要知道什么”
│
▼
Agent Engineering
↓
让 Agent 能够持续地理解、行动和验证
例如：
Prompt：
请实现用户注册功能。
这是任务。
再加入：
Rules：
Controller 不处理业务逻辑。
所有数据库操作必须通过 Repository。
异常统一使用 BusinessException。
这是约束。
再加入：
Repository：
UserController.php
UserService.php
UserRepository.php
User.php
这是代码 Context。
再加入：
Tool：
运行 PHPUnit。
这是执行能力。
再加入：
Test：
UserRegisterTest.php
这是验证 Context。
最终 Agent 才真正拥有完成任务所需要的工作环境。
所以可以把一个复杂 Agent 的输入理解成：
任务
+
规则
+
相关知识
+
当前状态
+
工具
+
历史
+
验证标准
而 Prompt 只是其中一个部分。
9. Context Engineering 的难点：动态 Context
真正复杂的 Agent 并不会一直使用一份固定 Context。
假设 Agent 正在处理一个 Bug：
用户：
修复订单退款接口。
第一阶段，它可能需要：
订单模块
退款模块
相关数据库结构
第二阶段发现：
第三方支付接口超时。
那么新的 Context 就应该加入：
支付 SDK
支付配置
超时处理
相关日志
第三阶段运行测试：
RefundServiceTest
失败
新的 Context 又变成：
测试代码
测试错误
调用栈
当前修改
因此：
Context
不是固定 Prompt
而是：
随着任务执行不断变化的状态。
这也是长时间运行 Agent 面临的一个核心问题。
如果一个 Agent 执行几分钟甚至几个小时，所有历史消息、工具结果和中间状态都不断累积，Context 很快就会变得庞大。
所以实际 Agent 系统需要进行：
Context Selection
Context Compression
Context Summarization
Context Isolation
Context Retrieval
Anthropic 关于长时间运行 Agent 的工程实践中，也专门讨论了 Context Management 和 Compaction，用于避免 Agent 因为上下文持续增长而耗尽 Context Window。
这说明一个重要事实：
Context Engineering 不是“把资料塞给模型”，而是管理 Agent 在整个任务生命周期中所需要的信息。
10. Context Engineering 会成为 AI 开发的基础能力
如果只是使用 ChatGPT 生成一段代码，Prompt Engineering 仍然非常有价值。
但当你开始构建：
AI Coding Agent
RAG
Knowledge Base
MCP
Multi-Agent
AI Workflow
Autonomous Agent
问题就会逐渐发生变化。
你会开始问：
Agent 应该知道什么？
这些信息从哪里来？
哪些信息应该进入 Context？
什么时候进入？
什么时候应该删除？
工具结果应该怎么处理？
历史信息应该保存多久？
哪些信息可信？
哪些信息不能被 Agent 使用？
Context 太长怎么办？
多个 Agent 应该共享哪些 Context？
这些问题已经不是简单的 Prompt 技巧，而是系统设计问题。
所以我认为 Context Engineering 最值得理解的地方，不是又出现了一个新的 AI 术语，而是它提醒我们：
当 AI 从“回答问题”进入“完成任务”，决定 Agent 表现的就不再只是模型本身，而是它在执行任务时所处的整个信息环境。
模型决定了 Agent 能够做到什么。
Context 决定了 Agent 知道什么、理解什么以及基于什么做决定。
Tools 决定了 Agent 能够做什么。
而验证机制决定了 Agent 做得是否正确。
这几者结合起来，才构成真正可靠的 Agent 系统。