Context Engineering

定义

Context Engineering（上下文工程）是 2025 年中出现的 AI 工程术语，由 humanlayer 的 12-Factor Agents 项目系统化提出，后被 Karpathy 等人推广。核心洞察：Everything is context engineering — LLM 是 stateless functions，输入决定输出。将上下文结构化和优化是提升 Agent 性能的关键杠杆。

上下文五要素

1. Prompt 和指令 — 模型收到的系统级指导
2. RAG 检索文档 — 外部知识注入
3. 历史状态 — 工具调用、结果、过往步骤
4. Memory — 跨会话/跨对话的持久信息
5. 结构化输出指令 — 要求模型以特定格式输出

自定义上下文格式 vs 标准格式

标准 message-based 格式（system/user/assistant/tool roles 交替）适用于大多数场景，但存在 token 冗余和注意力分散问题。自定义格式（如 XML-style 将所有信息打包在一条 user message 中）的优势：

1. 信息密度：结构化的信息布局让模型理解更准确
2. 错误恢复：隐藏已解决的错误和失败调用
3. 安全性：控制传递给模型的敏感数据
4. 灵活性：随经验迭代格式
5. Token 效率：显著减少 token 消耗

Deep Research 的上下文隔离模式

Claude Deep Research Architecture 提供了一个高价值案例：deep research 的性能不是靠把更多网页塞进一个上下文窗口，而是靠 subagent 上下文隔离 + 压缩汇报 + 最终引用绑定。

Claude Code Dynamic Workflows 进一步把中间状态放到 JavaScript workflow script / runtime 中，只有最终报告回到主会话。这是 Context Engineering 的重要原则：上下文窗口不是数据库；循环、分支、中间缓存和大规模搜索结果应尽量外置，只把决策所需的压缩事实带回模型。

与 LLM-Wiki 的关系

• Context Engineering 关注「怎么给 LLM 最好的输入」
• LLM-Wiki 关注「LLM 的输出怎么持久化、组织、维护」
• 两者互补：好的上下文 + 好的归档 = 好的 Agent 系统

关键来源

• factor-03-own-your-context-window-2025-07-03

[2026-08-02] Thariq 上下文工程新规：删 80% 提示词无评测损失

源（Anthropic 创始团队成员、Claude Agent SDK 核心负责人 Thariq 复盘）。

• 团队将 Claude Code 系统提示词删掉超 80%，编码评测无可测损失——Opus 5/Fable 5 这代模型判断力已够好，为防最坏情况写死的一刀切规则反成负担。前提：Opus 5/Fable 5 能力跳变，更老模型没护栏会出错。
• 六组”从前 vs 现在”反转：给规则→给判断力；举例子→设计接口；全塞前面→渐进式披露（按需加载 skill、ToolSearch 延迟加载工具）；反复强调→简洁工具描述；手动写记忆→自动记忆；简单规格→丰富引用（“代码是最高保真的引用”）。
• 判断留删标准：显而易见的事→删；风格偏好→换宽泛意图；反常规约定+出错代价高的硬约束→留。例外：防删文件、防碰生产数据等后果严重性高的硬规则该留就留。
• 推出 claude doctor 命令（Claude Code 内 /doctor）帮助清理过度约束。

与本页既有内容的衔接

• Thariq 的”渐进式披露/按需加载 skill/ToolSearch 延迟加载”是本页”自定义上下文格式 vs 标准格式”中信息密度/token 效率原则的代际升级——从”手动打包信息”到”系统按需加载”。
• 与本页”Deep Research 上下文隔离模式”同源——两者都把决策所需压缩事实带回模型、其余外置；Thariq 把这一原则从研究流程推广到系统提示词本身。
• 反直觉点：与本页”Context Engineering 是 2025 关键杠杆”一致，但 Thariq 揭示杠杆方向反转——不是塞更多上下文，而是删到只剩判断力。详见 范式收敛 analysis。

[2026-08-10] 认知债与意图债：AI 编程时代，理解成为瓶颈

来源：当理解成为瓶颈：AI 编程时代的认知债与意图债（ATA 技术社区，2026-08-10）。

• 写代码从未如此之快，瓶颈从”生产代码”转移到”理解代码”：Context Engineering 的对象因此从”给模型喂什么”延伸到”给人留下什么理解”。
• 认知债（cognitive debt）活在人身上：团队共享理解的侵蚀——AI 生成代码、开发者 accept all 时不长出理解，“连续 accept all 五天后就不知道程序怎么运行了”。上下文盲目复制（把整个仓库/整段对话史不加选择地塞进上下文）只缓解症状，不偿还理解之债；这与本页”上下文窗口不是数据库、决策所需压缩事实才带回模型”的原则同向。
• 意图债（intent debt）活在制品里：目标/约束/理由未被外化，“为什么”在模型做统计最优取舍的那一刻蒸发，既没落进代码也没落进任何人的记忆。解法——把目标/约束/理由外化到 SPEC、AGENTS.md、决策记录——正是本页”结构化上下文”与 Harness Engineering 在做的事；显式意图表达（把”为什么做”和”做完什么样”作为高保真制品交给模型）是意图债的直接对冲。
• 立场引文：Geoffrey Litt “We don’t understand to verify — we understand to participate”（理解是为了参与而非验证——SPEC 和验证标准定好后 AI 执行可以比人更好，但”那如果……会怎样？“只能由脑中装着系统心智模型的人提出）；Karpathy “可以外包思考，不能外包理解”。
• 一线顶级实践者的自认实例：Boris Cherny 自认”理解力的黑洞”（仓库中没人读过的代码越滚越大），见 其工作流源页。

？ 源页建议创建概念页面：三元债模型（技术债/认知债/意图债，Margaret-Anne Storey 提出），以及 Margaret-Anne Storey、Geoffrey Litt、Peter Naur 等 AI 编程理论谱系实体。