从提示词到上下文工程：管理 Codex 的信息环境

范式转变：为什么"写好提示词"不够了？

2025 年之前，大家谈的是 Prompt Engineering——怎么写好一条提示词。2025-2026 年，行业共识转向了 Context Engineering——怎么管理整个信息环境。

Martin Fowler 的定义很精准：上下文工程就是 "curating what the model sees so that you get a better result"——策展模型看到的信息，从而获得更好的结果。

上下文四支柱框架

改编自 Sourcegraph 的 AI Agent 上下文工程框架，在 Codex 中有具体的对应物：

支柱 1：指令层

静态行为规则，在每次对话开始时自动加载到上下文中。

关键原则：指令层要精简。 每个 token 都在和任务上下文竞争空间。AGENTS.md 里放了 500 行规则，意味着 Codex 还没开始你的任务，上下文就已经被占了 500 行。

交叉引用：AGENTS.md 的详细配置方法见 AGENTS.md 指南；rules 文件见 Rules 配置。

支柱 2：检索层

动态注入的上下文，按需加载。

关键原则：用引用代替塞入。 不要直接把大段代码粘贴到提示词里——用 @path/to/file 引用文件，让 Codex 自己读取。这是 Artifact 句柄模式的核心思想（详见下文）。

支柱 3：协调层

多个 Agent 或线程之间的上下文编排。

交叉引用：子代理的详细配置见 子智能体与并行 章节。

支柱 4：记忆层

跨会话的持久化信息。

交叉引用：记忆机制的详细说明见 记忆与长期上下文 章节。

上下文是有限资源

Google 在上下文工程实践中提出的核心原则：

Artifact 句柄模式

不要用"塞入"的方式提供上下文，用"引用"的方式。

在提示词中使用 Artifact 句柄的三种方式：

# 文件路径引用
查看 @src/features/auth/middleware.ts 的实现。

# 文档引用
遵循 docs/coding-style.md 中的命名规范。

# ID/链接引用
这个需求对应 JIRA-1234，具体要求我已经放在 @docs/requirements/JIRA-1234.md。

上下文工程实践清单

快速配置你的上下文环境（5 分钟）：

• 第一步：精简指令层（2 分钟）——检查 AGENTS.md，删除不再适用的规则
• 第二步：建立检索路径（2 分钟）——确认关键文档有明确路径，方便 @mention
• 第三步：设置记忆边界（1 分钟）——检查哪些信息需要跨线程保留，哪些不需要

"控制幻觉"警告

Martin Fowler 有一个重要提醒：上下文工程会给你一种控制感，但 AI 对上下文的解读是概率性的。

实操建议：

• 迭代构建，不要一次塞太多。 每次加一条规则或一个上下文来源，验证效果后再加下一个。
• 验证输出，不要假设控制。 即使你的上下文工程看起来很完美，也要检查 Codex 的实际输出。
• 接受不确定性。 上下文工程提高的是概率，不是确定性。

验证清单

• AGENTS.md 精简且只包含当前适用的规则
• 用 @mention 引用文件，而不是粘贴大段内容
• 长任务会关注上下文余量
• 大任务会拆分成独立上下文的子任务
• 每次加新规则/上下文后验证了效果

FAQ

Q：上下文工程和 RAG 是什么关系？

RAG（检索增强生成）是上下文工程的一种实现技术——通过检索外部知识库来动态注入上下文。但在 Codex 这样的编码助手场景中，上下文工程更多是关于"管理代码库中哪些信息在什么时候可见"，不完全是传统 RAG。

Q：AGENTS.md 写多少算合适？

没有硬限制，但建议在 100-200 行以内。如果你的 AGENTS.md 超过 300 行，大概率可以精简——把具体规范移到独立文件，AGENTS.md 只保留"什么时候加载什么"的路由规则。

Q：子代理的上下文是独立的吗？

是的。子代理运行在独立的上下文窗口中，不共享主线程的对话历史。它只能看到你在委派时传递的信息，以及它自己的工作目录中的文件。这也是为什么委派时需要把规划写清楚——子代理不知道你和主线程讨论了什么。

选读建议：掌握了上下文工程的思维框架，下一步是把它应用到真实场景——→ 提示词实战案例库。如果你想深入了解记忆层的管理——→ 记忆与长期上下文 章节。