从提示词到上下文工程：Claude、Codex 与多 Agent 协作的完整心智模型
很多人第一次使用 Claude Code 或 Codex 时，会把效果差异归结为“提示词写得好不好”。这当然重要，但只解释了很小一部分。
一个真正能持续工作的 AI Agent，不只是在读取一句 Prompt。它还会接收系统规则、项目规范、历史消息、代码与文档、Skill、MCP 工具描述、工具执行结果、长期记忆、子 Agent 汇总以及运行环境状态。随着任务推进，这些信息还会被检索、缓存、裁剪、压缩、持久化和重新装配。
因此，今天更准确的问题已经不是：
“我应该怎样写一句更神奇的提示词？”
而是：
“在 Agent 每一次决策前，应该让模型看到哪些信息，允许它调用哪些能力，怎样保留状态，又怎样证明任务真的完成？”
这就是从 **Prompt Engineering（提示词工程）**走向 **Context Engineering（上下文工程）**的关键变化。
本文基于截至 2026 年 9 月 4 日的 Claude 与 Codex 官方资料，建立一套不依赖具体产品界面的通用模型，并重点回答五个问题：
- Prompt、Context、Cache、Memory、Skill、MCP 到底有什么区别？
- Claude Code 与 Codex 如何组织项目上下文？
- 一个 AI Agent 从接收任务到完成验证，内部经历了什么流程？
- 多 Agent 为什么有时更强，又为什么经常更贵、更乱？
- 怎样写一份真正适合 Agent 执行的任务提示？
一、先建立正确模型：LLM 只有“当前工作台”，Agent 才有“工作系统”
模型本身在一次推理时能使用的，是一个有限的 Context Window（上下文窗口）。Anthropic 的上下文窗口文档明确指出，系统提示、消息历史、文档、图片、工具定义、工具结果以及当前输出都会占用窗口。窗口很大，不代表把所有信息塞进去就会更好；信息越多，相关内容越容易被噪声淹没。
Agent 则是在模型外面增加了一套 Harness（运行支架）：它负责组装上下文、暴露工具、执行工具调用、保存状态、控制权限、循环调用模型，并在适当的时候压缩或切换上下文。
可以把两者理解成：
- LLM 是大脑：根据当前看到的 Token 做判断；
- Agent Harness 是工作系统：决定大脑看到什么、能做什么、结果存到哪里、何时继续或停止；
- Sandbox 是双手工作的房间：文件、终端、浏览器、网络和权限都发生在这里；
- Artifacts 是外部事实：代码、测试、任务清单、数据库记录和报告不会因为聊天窗口结束而消失。
这张图里最重要的是回路：Agent 不是一次生成，而是“观察—决策—行动—反馈—验证”的循环。
二、上下文栈：十个看似相近、实际职责完全不同的部分
把 Agent 能使用的信息分层后，许多概念就不再混乱。
| 层 | 解决的问题 | 典型载体 | 是否长期存在 | 是否直接占用当前上下文 |
|---|---|---|---|---|
| System / Developer Prompt | 这个 Agent 是谁，必须遵守什么 | 系统指令、开发者指令 | 通常随产品配置 | 是 |
| User Prompt | 这一次要完成什么 | 用户消息、任务合同 | 当前任务 | 是 |
| Project Instructions | 在这个仓库里应如何工作 | CLAUDE.md、AGENTS.md、Rules | 随项目版本存在 | 加载后占用 |
| Skill | 某类任务应按什么方法执行 | SKILL.md、脚本、模板、参考资料 | 可复用 | 通常按需加载 |
| Tools / MCP | Agent 可以读取或改变哪些外部系统 | Tool Schema、MCP Server | 配置级 | 描述与返回结果会占用 |
| Retrieval / RAG | 从大资料库里挑出当前相关内容 | 向量检索、关键词检索、文件搜索 | 资料长期存在 | 只有检索结果进入窗口 |
| Conversation State | 这次任务刚才发生了什么 | 消息、工具调用、工具结果 | 会话级 | 是 |
| Memory | 过去任务中哪些经验值得以后再用 | 自动记忆、人工记忆、Memory Tool | 跨会话 | 被召回时占用 |
| Cache | 相同前缀能否少算一次、少花一些 | Prompt Cache | 短期基础设施状态 | Token 仍在窗口中 |
| Compaction / Context Editing | 窗口快满时怎样保留重点 | 摘要、压缩项、删除旧工具结果 | 会话延续机制 | 用更少 Token 替代旧内容 |
1. Prompt：描述目标，不负责保存世界
Prompt 是进入上下文的指令。好的 Prompt 应该定义目标、成功标准、约束、可用证据、输出形式与停止条件。它不应该承担数据库、知识库或项目历史的职责。
提示词最常见的失败，不是“不够华丽”，而是缺少任务合同：
- 只说“优化一下”，没有说明优化什么指标；
- 只说“修复问题”，没有给出复现路径；
- 只要求“写完”，没有定义验证方式；
- 给了详细步骤，却没有说明哪些步骤只是建议、哪些约束不可违反；
- 让 Agent 自主工作，却没有声明权限和停止边界。
2. Project Instructions：每次都应该知道的规则
项目指令适合存放稳定且高频的事实，例如仓库结构、构建命令、编码规范、安全要求和验收门禁。
Claude Code 使用 CLAUDE.md、.claude/rules/ 等文件承载这类上下文；Codex 使用分层的 AGENTS.md。它们不是“更长的用户 Prompt”，而是仓库随代码共同演进的工作契约。
原则很简单：
- 每次任务都必须生效的规则，放项目指令；
- 只有某类任务需要的复杂流程，放 Skill；
- 只与本次请求有关的信息，留在用户 Prompt；
- 从过去工作中总结出的可变经验，放 Memory。
3. Skill：可按需加载的“操作手册”
Skill 是可复用的任务能力包，通常包含说明、脚本、模板、参考资料和资源。它回答的是：“遇到这种工作，应该怎样可靠地完成？”
Claude Code 与 Codex 都支持基于 SKILL.md 的按需能力加载。OpenAI 的Skills 文档把这种机制称为 progressive disclosure：启动时只暴露 Skill 的名称和描述，真正命中任务后再读取完整说明，从而避免所有操作手册同时挤进上下文。Claude Code 的Skills 文档也采用相似思路：Skill 正文仅在使用时加载。
Skill 与 Prompt 的区别是复用，Skill 与工具的区别是“知道怎样做”而不是“真的能做”。一个部署 Skill 可以规定检查清单与回滚流程，但实际访问 Kubernetes、Vercel 或云平台，仍需要工具或 MCP。
4. MCP：连接外部世界的协议，不是知识本身
Model Context Protocol 让 Agent 以统一方式发现和调用外部工具、资源与提示模板。Claude Code 和 Codex 都可以通过 MCP 访问浏览器、设计工具、工单系统、数据库或内部文档。
可以用一句话区分：
MCP 提供“通道与能力”，Skill 提供“方法与流程”。
例如，GitHub MCP 可以提供读取 PR、创建 Issue、发表评论的能力；Code Review Skill 则规定先看风险、再看测试、怎样分级问题、最终输出什么格式。两者组合后，Agent 才既“能操作”又“知道如何正确操作”。
MCP 也会带来上下文压力。工具描述、参数 Schema 和大段工具结果都会消耗 Token。因此现代 Agent 会使用工具搜索、延迟加载、输出截断和结果摘要，而不是在每轮把数百个工具完整塞给模型。Codex 的MCP 文档与 Claude 的工具上下文管理文档都把“按需暴露工具”作为关键优化方向。
5. RAG：检索相关事实，不负责形成长期经验
RAG 的职责是从大量外部资料中找出当前问题最相关的片段。它适合产品文档、历史工单、知识库、代码索引与业务记录。
Memory 与 RAG 经常共用检索技术，但语义不同：
- RAG 回答“外部资料里与当前问题有关的事实是什么”；
- Memory 回答“这个用户、项目或 Agent 过去学到了什么”；
- Project Instructions 回答“无论过去发生过什么，这次都必须遵守什么”。
6. Memory：跨会话的经验层，不是强制规则层
Memory 用来把过去任务中的有效经验带到未来，例如某个测试需要 Redis、用户偏好 pnpm、某次线上问题的根因、一个模块的真实入口。
Claude Code 的记忆文档区分了人工维护的 CLAUDE.md 与自动生成的 Auto Memory：前者是明确规则，后者是 Claude 从纠正与工作模式中积累的经验。Codex 的Memories 文档也明确建议：强制团队规则应放在 AGENTS.md 或版本化文档中，Memory 只是辅助召回层。
Memory 的工程难点不是“记住越多越好”，而是：
- 什么值得写入；
- 记忆属于用户、项目、分支还是某个 Agent；
- 何时召回；
- 如何标记来源、时间和置信度；
- 事实变化后怎样失效或更新；
- 如何避免把密钥、隐私或 Prompt Injection 永久保存。
7. Prompt Cache：省计算，不增加记忆
Prompt Cache 是最容易被误解的概念。
如果许多请求拥有相同的前缀，例如固定系统提示、工具定义和长文档，服务端可以复用已计算的前缀状态，降低延迟和输入成本。OpenAI 的Prompt Caching 文档和 Anthropic 的Prompt Caching 文档都建议把稳定内容放在前面、动态内容放在后面。
但要注意：
缓存命中的 Token 仍然属于上下文。Cache 降低重复计算成本，不会扩大窗口，也不会让模型跨会话“学会”新知识。
所以 Cache、Memory、Compaction 分别解决三个不同问题：
| 机制 | 核心目标 | 直观比喻 |
|---|---|---|
| Cache | 相同内容不要重复计算 | 把常用资料预热在桌面上 |
| Memory | 未来任务能找回过去经验 | 把经验写进可检索笔记 |
| Compaction | 当前任务太长时保留关键状态 | 把厚会议记录压成行动摘要 |
8. Compaction 与 Context Editing：保留连续性，但接受信息损失
长任务会持续产生消息、文件内容、日志和工具结果。即使窗口足够大，噪声也会让模型注意力下降。
Compaction 会把较长的会话状态压缩成更短的表示，让后续推理继续进行；Context Editing 则更精细地删除已经失去价值的内容，例如旧的工具返回。Anthropic 把服务端压缩视为长对话的主要策略，并用 Context Editing 清理特定历史；OpenAI 的 Responses API 也提供Compaction与 Conversation State 机制。
压缩不是无损存档。可靠做法是把以下状态显式保留下来：
- 最终目标与验收标准；
- 已完成动作及其证据；
- 当前假设与关键决定；
- 文件、提交、任务、请求等稳定 ID；
- 未解决问题与下一步；
- 不能违反的安全边界。
更大的原始结果应写入文件或外部存储，通过引用传递，而不是反复复制进聊天历史。
三、Agent Loop：从一句任务到可验证结果的核心流程
一个生产级 Agent Loop 可以拆成九步。
1. 解析目标与边界
Agent 先识别用户真正要的结果、非目标、权限范围与风险。用户说“帮我看看”通常只授权读取和解释；“修复并验证”才授权修改；“提交并推送”又增加了外部写入动作。
2. 装配最小充分上下文
Harness 合并系统规则、用户消息、项目指令、相关记忆和必要文件。这里的目标不是最大化 Token，而是最大化 每个 Token 对当前决策的价值。
3. 制定或更新计划
计划是工作状态，不是仪式。简单任务可以一步完成；复杂任务需要记录依赖、风险、验证点和并行机会。工具结果改变判断时，计划也要更新。
4. 选择 Skill 与工具
Agent 根据任务匹配 Skill，再根据动作选择工具。Skill 规定流程，工具提供能力，权限策略决定动作能否执行。
5. 执行动作
动作可能是读文件、搜索网页、修改代码、调用 API、运行测试、操作浏览器或委派子 Agent。写操作应具备明确目标、尽量小的影响面和可恢复路径。
6. 观察工具结果
工具返回值不是“真相保证”。Agent 仍要判断输出是否完整、是否过期、是否来自正确环境、是否被截断，以及是否包含外部不可信指令。
7. 更新状态与证据
稳定事实进入任务状态：改了哪些文件、测试结果是什么、哪个请求失败、还缺什么。大对象写成 Artifact，小结论留在上下文。
8. 验证与路由
Agent 对照验收标准决定继续、重试、降级、请求用户输入、交给 Reviewer，还是结束。没有验证的“完成”只是生成停止，不是任务完成。
9. 交付与学习
最终输出说明结果、证据、边界和剩余风险。只有对未来任务确实有帮助的经验才进入 Memory；强制规则应升级到项目指令或测试，而不是只留在聊天摘要里。
四、怎样写适合 Agent 的提示词：从“命令句”升级为“任务合同”
Anthropic 的提示最佳实践强调清晰指令、必要上下文、示例与结构化分隔；OpenAI 的模型提示指南更强调 outcome-first：定义结果、成功标准、约束、证据和停止条件，除非执行路径本身是强约束，否则不要用冗长步骤限制模型的搜索空间。
两者可以统一成下面的模板：
角色：
你是这个仓库的资深实现 Agent，负责把请求落成可验证的结果。
目标：
修复移动端登录后偶发跳回登录页的问题。
可用上下文：
- 复现环境：iOS Safari，生产同构配置
- 相关模块：auth、middleware、session refresh
- 错误日志：<附链接或文件>
成功标准：
- 能解释根因，而不只是隐藏症状
- 修复不破坏桌面端和匿名访问
- 相关测试、类型检查与构建通过
- 最终列出修改文件、验证证据和剩余风险
约束与权限：
- 可以修改当前仓库文件并运行测试
- 不要改动无关页面
- 不要读取或输出密钥
- 不要部署、提交或推送
工作方式：
- 先读取项目指令和相关代码
- 信息足够时直接推进；只有缺失信息会实质改变方案时才提问
- 优先使用已有组件和测试工具
- 发现高风险外部写操作时停止并说明
停止条件：
- 验收标准全部满足后结束
- 连续失败时保留错误证据并报告阻塞点
- 不要把“代码已生成”当成“修复已完成”
输出：
先给结果，再给根因、改动、验证和边界。
这份模板并不要求每次都写这么长。它真正重要的不是格式，而是八个字段：
Goal + Context + Success Criteria + Constraints
+ Permissions + Evidence + Stop Rules + Output Contract
提示词里不应该塞什么
- 可通过工具实时获取的大段数据；
- 会频繁变化的项目事实；
- 数十个工具的完整使用说明；
- 应由权限系统强制执行的安全规则；
- 应由 Schema、类型或测试保证的输出约束；
- 希望模型逐字展示的内部思维过程。
能交给代码、权限、Schema、测试和检索系统保证的事情，就不要只靠自然语言祈祷模型每次都遵守。
五、Claude Code 的上下文是怎样组织的
Claude Code 的设计可以理解为“会话上下文 + 仓库状态 + 可插拔能力”的组合。
| 需求 | Claude Code 中的主要机制 |
|---|---|
| 稳定项目规则 | CLAUDE.md、.claude/rules/ |
| 自动积累项目经验 | Auto Memory |
| 按需工作流 | Skills |
| 外部系统能力 | MCP、内置工具 |
| 长会话续航 | Compaction、上下文编辑、外部 Artifact |
| 隔离任务 | Subagents |
| Agent 间直接协作 | Agent Teams（当前仍属实验能力） |
| 并行写代码隔离 | Git Worktrees |
CLAUDE.md 与 Auto Memory
每个 Claude Code 会话都有新的上下文窗口。官方记忆文档说明，跨会话连续性主要来自两部分：人写的 CLAUDE.md 与 Claude 自动积累的 Auto Memory。
这两者都会进入后续会话，但职责不同：
CLAUDE.md写“应该怎样做”；- Auto Memory 记“过去发现了什么”；
.claude/rules/可把规则缩小到特定文件路径；- Skill 承载不必每次加载的长流程。
Skills 与 MCP
Claude 启动时不应把所有 Skill 正文和 MCP Schema 全量加载。Skills 按相关性进入会话；MCP 工具可以通过 Tool Search 延迟发现。这样既减少初始上下文，也降低无关工具对决策的干扰。
要再次强调：MCP 的工具返回通常会进入消息历史。数据库导出、浏览器 DOM、构建日志都可能非常大，因此需要限制输出、分页、筛选或写入 Artifact。Prompt Cache 只能降低重复处理成本，不能消除这些 Token。
Subagent 与 Agent Team
Claude Code 的 Subagent 拥有独立上下文和专门工具，完成后向主会话返回摘要，适合搜索、代码探索、测试分析和独立审查。
Agent Teams 文档描述了更强的协作模式：Lead、Teammates、共享任务列表和 Agent 间消息。它适合成员需要彼此讨论、挑战假设和协调依赖的任务，但会消耗更多 Token，且共享文件写入需要额外隔离与分工。
六、Codex 的上下文是怎样组织的
Codex 的核心分层与 Claude 相近，但命名和装配规则不同。
| 需求 | Codex 中的主要机制 |
|---|---|
| 稳定项目规则 | 分层 AGENTS.md / AGENTS.override.md |
| 跨任务经验 | Local Memories |
| 按需工作流 | Skills |
| 外部系统能力 | MCP、内置工具、插件工具 |
| 任务隔离与并行 | Subagents、独立 Agent Threads、Worktrees |
| 长会话状态 | 产品会话管理；构建自有 Agent 时可使用 Responses API Compaction |
AGENTS.md 指令链
Codex 会在工作前读取 AGENTS.md。官方文档说明，它从全局范围开始，再从项目根目录向当前工作目录逐层发现指令，离当前目录更近的内容拥有更具体的覆盖作用。
这使大型 Monorepo 可以形成清晰的规则层级：
~/.codex/AGENTS.md # 个人通用偏好
repo/AGENTS.md # 仓库级构建与交付规则
repo/services/AGENTS.md # 服务组约定
repo/services/payment/AGENTS.md # 支付域安全与测试规则
与 Prompt 一样，指令文件进入上下文后也会占用空间。应保持短小、明确，把大型操作手册拆到 Skill 或版本化文档中。
Memories 与 Skills
Codex 本地 Memories 用于从历史任务中召回有价值的上下文，但官方同样强调：Memory 不应成为强制团队规则的唯一来源。稳定规则放 AGENTS.md，可复用流程放 Skill，历史经验才放 Memory。
Codex Skills 使用 progressive disclosure：初始只显示名称、描述和路径，匹配后读取完整 SKILL.md。这种模式本质上是一个 Context Router——先用少量元数据决定“需要哪本手册”，再加载正文。
MCP 与 Subagents
Codex 的 MCP 层负责把第三方文档、浏览器、Figma 和其他开发工具接入 Agent，并允许对服务器和单个工具设置启用范围、审批模式与输出 Token 限制。
Codex Subagents 文档强调两个收益：并行执行，以及把搜索结果、日志、堆栈和大量文件读取隔离在子上下文中。主 Agent 保留需求、决策和最终结果，只接收压缩后的汇总。
需要区分产品与 API 层：Codex 客户端会管理自己的会话上下文；如果你使用 OpenAI Responses API 构建 Codex-like Agent，则还可以显式使用 Conversation State、Prompt Caching 与 Compaction。不要因为底层模型支持某项 API 特性，就假定每个 Codex 界面以相同方式暴露或实现它。
七、Claude 与 Codex：相同目标，不同命名
| 上下文职责 | Claude Code | Codex | 共同原则 |
|---|---|---|---|
| 全局与项目规则 | CLAUDE.md、Rules | AGENTS.md、Override | 稳定规则版本化、分层覆盖 |
| 自动经验 | Auto Memory | Local Memories | 记忆可审计、可失效，不保存秘密 |
| 按需方法 | Skills | Skills | 先匹配描述，再加载正文 |
| 外部能力 | MCP、内置工具 | MCP、内置/插件工具 | 最小权限、限制输出、验证返回值 |
| 当前任务历史 | Session messages | Thread / conversation | 工具结果会持续污染上下文 |
| 长任务延续 | Compaction、Artifacts | 会话管理；API Compaction | 压缩保状态，Artifact 保证据 |
| 独立委派 | Subagents | Subagents | 子上下文隔离噪声，摘要返回主 Agent |
| 多方协作 | Agent Teams | Subagent workflow / Agent threads | 并行只用于可独立分解的工作 |
| 写入隔离 | Worktrees | Worktrees / 独立环境 | 避免多个 Agent 同时修改同一文件 |
这里没有绝对的产品胜负。真正影响效果的通常是：
- 项目规则是否清楚；
- 工具是否可靠、描述是否准确；
- 上下文是否只包含当前需要的信息；
- 状态是否写进可恢复的 Artifact；
- Agent 是否拥有合适权限；
- 验收标准是否能被机器或独立 Reviewer 检查。
八、多 Agent 的本质：用多个独立上下文换取并行、隔离与更多推理预算
多 Agent 并不是让几个模型围在一起“开会”。它真正提供的是三种能力：
- 并行：多个独立方向同时推进；
- 上下文隔离：大量中间信息不污染主 Agent；
- 角色分离：生成者、验证者、研究者可以使用不同提示、工具与权限。
Anthropic 在多 Agent Research 系统复盘中把它概括为 Orchestrator-Worker：Lead Agent 规划并创建多个并行 Subagent，Subagent 独立搜索，再返回压缩结果供 Lead 汇总。其收益主要出现在开放式、广度优先、可拆成独立方向的高价值任务；代价则是显著增加 Token 消耗、协调复杂度和错误传播路径。
四种常见拓扑
| 拓扑 | 适合任务 | 主要风险 |
|---|---|---|
| Manager–Worker | 多来源研究、模块探索、批量分类 | 重复劳动、汇总丢失细节 |
| Pipeline | 阶段明确的生成—验证—发布 | 上游错误逐步放大 |
| Generator–Reviewer | 代码、文案、设计、风险审查 | Reviewer 与 Generator 共享盲点 |
| Debate–Judge | 竞争假设、复杂决策、安全分析 | 成本高，可能只产生更多措辞而非证据 |
什么任务不适合多 Agent
- 下一步完全依赖上一步结果的串行任务；
- 多个 Agent 必须同时修改同一文件；
- 问题很小，协调成本高于执行成本；
- 所有 Worker 都需要完整共享同一份巨大背景；
- 没有明确分工、输出格式与汇总责任；
- 任务价值不足以覆盖成倍增加的 Token 与运行成本。
给 Subagent 的任务合同
主 Agent 不应只说“去研究一下”。每个委派都至少需要：
objective: 要回答的唯一问题
boundary: 不要处理哪些相邻问题
inputs: 可使用的文件、链接、提交或数据
tools: 允许使用的能力与权限
evidence: 每个结论需要什么证据
output: 返回摘要、结构化数据或 Artifact 路径
stop: 何时完成，何时报告阻塞
ownership: 是否允许写文件，允许写哪些文件
好的委派要让 Worker 之间尽量正交。若三个 Agent 都收到“分析整个系统”，得到的通常是三份重复摘要；若分别负责身份认证、数据一致性和前端状态，则主 Agent 才能覆盖更大的问题空间。
Artifact-first Handoff：不要只靠摘要传话
Agent 摘要一定会损失细节。对代码、报告、数据和设计稿，更可靠的交接方式是：
- Worker 把完整结果写入独立 Artifact；
- 返回 Artifact 地址、结论、证据索引和未解决问题；
- Lead 只把摘要放进主上下文；
- 需要复核细节时，再按引用读取原始 Artifact。
这比把数万 Token 从 Worker 复制给 Lead 更便宜，也减少“传话游戏”造成的信息失真。
九、上下文管理的常见反模式
1. 把所有知识都写进系统 Prompt
结果是每一轮都支付 Token，规则彼此冲突，真正重要的信息被埋没。应把稳定规则、按需流程、外部事实和历史经验分别放进 Project Instructions、Skills、RAG 与 Memory。
2. 把 Cache 当 Memory
缓存过期后不会留下经验，也不会自动召回历史事实。它只复用相同前缀的计算。
3. 把 Memory 当数据库真相
记忆可能过时、概括错误或缺少来源。订单状态、价格、权限、生产配置等高变化事实必须回源查询。
4. MCP 工具越多越好
工具越多，选择越难，攻击面越大，Schema 越占上下文。优先按需发现、允许列表、只读默认和最小输出。
5. 让所有 Agent 共享所有历史
这会失去上下文隔离的意义。主 Agent 应持有目标、约束、决定与总状态；Worker 只拿完成自己任务所需的最小背景。
6. 只让 Agent 生成，不让独立系统验收
Agent 说“应该可以”不是证据。测试结果、构建产物、页面截图、数据库状态、API 响应、Diff 与 Reviewer 结论才是证据。
7. 把外部内容当指令
网页、Issue、代码注释、日志和 MCP 返回都可能包含 Prompt Injection。它们应被标记为不可信数据，不能覆盖系统规则和用户授权。
8. 多 Agent 同时写同一工作区
这会产生覆盖、竞态和难以归因的修改。应通过 Worktree、文件所有权、模块边界或只读 Worker 隔离。
十、生产级 Context Engineering 检查表
Prompt 层
- 目标和成功标准是否可观察？
- 权限、非目标、输出与停止条件是否明确？
- 是否只规定必要路径，而不是过度编排每个动作？
Context 层
- 每轮是否装配最小充分信息？
- 是否能追踪每段上下文的来源、时间与作用域？
- 长日志和大文档是否通过检索或 Artifact 按需读取？
Skill 与工具层
- Skill 是否单一职责、可复用、可测试？
- 工具描述是否说明用途、参数、副作用、重试安全与错误模式？
- MCP 是否采用最小权限、允许列表、输出上限与审批策略？
Memory 层
- 写入是否有价值门槛？
- 是否避免秘密、个人敏感信息和未经验证的外部内容？
- 是否记录来源、时间、置信度和失效条件？
- 强制规则是否已提升为项目文档、策略或测试？
多 Agent 层
- 子任务是否真正独立，值得并行？
- 每个 Agent 是否有明确输入、边界、证据和输出？
- 写操作是否通过 Worktree 或所有权隔离？
- Lead 是否只接收摘要，并能按引用回查 Artifact？
验证与可观测性层
- 是否记录每次模型决策、工具调用、权限审批、重试和 Handoff？
- 是否能区分“模型认为完成”和“验收证据已通过”？
- 是否评估成功率、延迟、Token、缓存命中率、工具失败率和人工介入率？
- 是否有回滚、超时、熔断与预算上限？
十一、最后总结：优秀 Agent 的核心不是更长的 Prompt，而是更好的状态流
Prompt Engineering 仍然重要，但它只负责告诉模型“希望发生什么”。一个可用的 Agent 系统还必须回答：
什么信息现在进入上下文？
什么能力现在可以调用？
什么状态必须跨轮次、跨会话保留？
什么内容应被缓存、检索、压缩或删除？
什么工作可以安全地交给另一个独立 Agent？
什么证据能够证明任务已经完成？
Claude Code 与 Codex 的共同方向已经非常清晰：
- 用项目指令保存稳定规则；
- 用 Skill 封装按需流程；
- 用 MCP 连接外部能力；
- 用 Memory 延续经验；
- 用 Cache 降低重复计算；
- 用 Compaction 和 Artifact 穿越长任务；
- 用 Subagent 隔离噪声并行探索；
- 用权限、测试和 Reviewer 把生成转化为可信结果。
因此，AI Agent 的真正核心可以浓缩成一条链：
目标进入 → 上下文装配 → 模型决策 → 工具行动 → 状态更新 → 独立验证 → 必要时委派或压缩 → 结果交付 → 有选择地形成记忆。
未来模型的上下文窗口还会继续扩大，但工程问题不会消失。只要 Agent 需要在真实世界中长期行动，信息的相关性、状态的可靠性、权限的边界和协作的成本，就永远比“能塞多少 Token”更重要。
参考资料
Anthropic / Claude
- Effective context engineering for AI agents
- How we built our multi-agent research system
- Claude context windows
- Manage tool context
- Prompt caching
- Context editing
- Claude Code memory
- Claude Code skills
- Claude Code subagents
- Claude Code agent teams