跳转至

Context Engineering：从 Prompt 到上下文系统的工程范式转变

AI Agent 生成 · 成本 $0.1258 · claude-sonnet-4-6 · 8 input · 4.2K output

一、引子

你说 Context Engineering 感觉是 Prompt Engineering 的升级版，但不确定边界在哪里，也不确定它是不是真正独立的学科还是只是个营销词。

这个直觉抓住了核心矛盾。答案既是"是"也是"不是"。

它确实是 Prompt Engineering 的进化，但进化的方向不是"写更好的 prompt"——而是彻底离开了"写 prompt"这件事本身。Andrej Karpathy 在 2025 年把这个词推上了技术圈的主流视野，他用的表述是："Context Engineering 是将恰当信息填充到上下文窗口中的精妙艺术与科学。"1 但这句话容易被误读为"更高级的 prompt 写作"。实际上，他随后补充的才是关键：包括任务描述、few-shot 示例、RAG、多模态数据、工具、状态、历史、压缩……做好这件事极其不简单。

这里的逻辑跃变在于：Context Engineering 的对象不是一条字符串，而是一个系统——一个在主 LLM 调用之前运行的、动态生成上下文的工程系统。

Shopify CEO Tobi Lutke 的定义更直接："这是一门艺术：为任务提供所有上下文，使 LLM 可以合理地解决它。"2 注意是"所有上下文"——这意味着日历数据、历史邮件、用户偏好、工具定义、状态记录……一切在 LLM 产生输出之前需要就位的东西。

这次调研要回答三个问题：

  1. Context Engineering 的精确定义是什么？它跟 Prompt Engineering 的边界在哪？
  2. 它作为一个独立工程学科的知识结构是什么？有哪些子领域和关键技术？
  3. 它真的是独立学科还是营销词？学界、工程界和产业界分别怎么看？

二、精确定义

2.1 第一性原理拆解

LLM 是一个确定性的函数：给定输入（context window 的内容），输出概率分布，从中采样得到 token。这个函数本身无法被修改（在推理阶段），唯一可以干预的变量就是输入。

这个约束是物理层面的：当前所有主流 LLM 架构（Transformer decoder）处理的是一个固定长度的 token 序列，上下文窗口就是这个序列的全部。模型不知道窗口外的任何信息，不记得上一次对话，不了解用户的偏好，不知道现在几点。

Prompt Engineering 是在假设"输入是一条静态文本"的前提下，优化这条文本的技术。Chain-of-Thought、few-shot、instruction tuning 的 prompt 格式——这些都在操作一个固定的字符串。

Context Engineering 的洞察是：真实的生产系统里，"输入"从来不是一条静态文本，而是多个动态数据源在运行时拼合的结果。Agent 从数据库拉记忆，从向量库检索文档，从 API 获取实时数据，再加上工具定义、对话历史、系统指令……最终拼成模型实际看到的那一段 token 序列。

Context Engineering 的精确定义因此是：

设计和构建动态系统的学科——该系统在正确的时间，以正确的格式，为 LLM 提供完成任务所需的正确信息和工具。3

注意三个关键词：系统（不是字符串）、动态（运行时生成）、正确的格式（呈现方式本身也是变量）。

2.2 为什么这是一个独立的工程边界

Prompt Engineering 的技术栈：自然语言写作、格式优化、few-shot 示例设计、CoT 触发词——核心能力偏向语言学和心理学（模型行为的直觉）。

Context Engineering 的技术栈：向量数据库、实时 API 集成、状态机设计、格式序列化（JSON/YAML/Markdown）、token 预算管理、信息压缩、工具 schema 设计——核心能力偏向软件系统工程。

这两者的从业者画像、所需工具链、调试方法都不同。这是实质性的边界，不是营销词的差异。

2.3 为什么现在才出现这个词

两个触发条件同时成熟：

第一，上下文窗口大幅扩展。GPT-4 的 8k token，到 Claude 3 的 200k，到 Gemini 1.5 的 1M——上下文窗口大到足以容纳真实的知识体系，"塞什么进去"的工程价值陡然上升。

第二，LLM Agent 开始大规模落地。当 LLM 不再是聊天机器人，而是要执行多步骤任务、调用工具、维护状态的 Agent 时，"给模型什么信息"变成了决定系统成败的关键工程变量。Anthropic 的 Agent 工程实践报告直接指出：Agent 失败的根本原因往往不是模型失败，而是上下文失败。4

Simon Willison 在 2025 年指出了另一个角度："Prompt Engineering"作为术语的问题是被大众理解为"往聊天机器人里打字"，严重贬低了这个词的技术含量。"Context Engineering"的字面含义与实际工程实践更接近，更不容易被误解，因此有更强的生命力。5

三、知识结构

3.1 七大上下文组件

Phil Schmid 将 Context（上下文窗口的实际内容）拆解为七类组件：3

1. Instructions / System Prompt（指令/系统提示） 定义模型行为的初始指令，包含规则、约束、角色设定。这是唯一与经典 Prompt Engineering 有重叠的部分，但在 Context Engineering 框架里，它只是七个组件之一。

2. User Prompt（用户输入） 用户的即时任务或问题。在 Agent 场景里，这往往不是对话输入，而是程序化生成的任务描述。

3. State / History（对话状态/短期记忆） 当前 session 的对话历史。工程挑战：如何在 token 预算有限的情况下保留关键信息？压缩策略和摘要生成是核心子问题。

4. Long-Term Memory（长期记忆） 跨 session 的持久化知识：用户偏好、历史项目摘要、已记住的事实。实现技术：向量数据库 + 相似度检索，或结构化键值存储。这是 Context Engineering 与传统软件工程交叉最深的层。

5. Retrieved Information（RAG 检索信息） 来自文档、数据库、API 的外部实时知识。检索增强生成（Retrieval-Augmented Generation）是 Context Engineering 的核心子领域，在 2023-2025 年有大量学术研究积累。

6. Available Tools（工具定义） 模型可以调用的函数/工具的 schema 定义。工具 schema 的设计质量直接影响 Agent 的可靠性——过于模糊的工具描述导致模型误用，过于复杂的 schema 超出模型的理解能力。

7. Structured Output（结构化输出格式） 模型响应格式的定义，如 JSON schema。这是 Context Engineering 与 Harness Engineering 的交汇点——schema 既约束了 LLM 的输出，也为下游系统提供了可验证的结构保障。

3.2 核心子领域

子领域 A：RAG 工程（Retrieval-Augmented Generation）

RAG 的核心挑战不是检索，而是"检索什么、以什么格式注入、注入多少"。arxiv:2602.05447 的研究（9,649 次实验，11 个模型）发现：格式本身（YAML/JSON/Markdown）对整体精度无显著影响（chi-squared=2.45, p=0.484），但模型能力是最主导的单一变量——前沿模型（Claude、GPT、Gemini）与开源模型之间存在 21 个百分点的精度差距，远超格式或架构差异。6

这个发现挑战了"格式调优是万灵药"的工程直觉：在模型能力不变的前提下，格式优化的天花板远低于通常认为的水平。

子领域 B：记忆管理（Memory Management）

LLM Agent 的记忆分为四个层次（Anthropic 框架）： - In-context storage（上下文内存储，临时） - External storage（外部存储，数据库/向量库，持久化） - In-weights storage（权重内存储，通过微调写入） - In-cache storage（KV Cache，计算层缓存）

Context Engineering 主要处理前两层的工程设计。

子领域 C：上下文压缩（Context Compression）

当可用信息超过上下文窗口预算时，需要对话历史摘要、文档分块、信息密度优化。2025 年的研究发现"context rot"现象：模型在不同上下文位置的性能表现不均匀——信息是否存在于上下文中，不如信息如何呈现重要。7

这是 Context Engineering 最反直觉的发现之一：更多信息不一定更好，信息的位置和结构同样重要。

子领域 D：工具 schema 设计（Tool Schema Engineering）

Anthropic 将其称为 ACI（Agent-Computer Interface）设计，类比 HCI（Human-Computer Interface）。arxiv:2603.13404 的受控实验比较了三种工具接口设计：自由文本文档、JSON Schema 规范、JSON Schema + 结构化诊断。发现：Schema 条件减少了接口误用，但未减少语义误用——接口形式化可以改善契约遵守，但根本性的语义理解问题仍是瓶颈。8

子领域 E：上下文结构工程（Structured Context Engineering）

arxiv:2602.05447 定义了一个新方向：将系统信息（如数据库 schema）以文件形式存储，让 Agent 按需检索，而非一次性全部注入。这被称为"file-native agentic systems"。实验表明，基于文件的上下文检索对前沿模型提升精度 +2.7%，但对开源模型总体下降 -7.7%——架构决策必须根据模型能力量身定制。6

3.3 技术栈全图

Context Engineering 技术栈

┌─────────────────────────────────────────────────────────┐
│                    应用层（Agent 逻辑）                    │
│    任务规划 / 工作流编排 / 工具调用 / 状态机               │
├─────────────────────────────────────────────────────────┤
│                   上下文构建层                             │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐   │
│  │  System  │ │  Memory  │ │   RAG    │ │  Tools   │   │
│  │  Prompt  │ │ Manager  │ │ Retrieval│ │  Schema  │   │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘   │
├─────────────────────────────────────────────────────────┤
│                   存储与检索层                             │
│  向量数据库 / 文档数据库 / 键值存储 / 外部 API / KV Cache  │
├─────────────────────────────────────────────────────────┤
│                    LLM 推理层                              │
│           Structured Output / Tool Calling               │
└─────────────────────────────────────────────────────────┘

3.4 工程规范与工具链

目前没有统一的行业标准（如 ISO/IEEE 级别的规范），但有若干事实标准：

  • 工具调用格式：OpenAI 的 Function Calling / Tool Use，已成为多数框架采用的事实标准，Anthropic、Google 均提供兼容接口
  • 结构化输出：JSON Schema（RFC 8259），配合 Pydantic（Python）做运行时验证
  • 向量存储：Pinecone、Weaviate、Chroma、pgvector 等；没有统一标准，按需选型
  • Agent 框架：LangChain、LlamaIndex、AutoGen、CrewAI——Anthropic 的官方建议是理解底层再用框架，生产环境减少抽象层

四、脉络追溯

4.1 前史：从 Fine-tuning 到 Prompt Engineering（2018-2022）

BERT（2018）和 GPT（2018）的出现改变了 NLP 的范式——从任务特定模型转向预训练+微调。这个阶段，"给模型什么输入"还不是核心问题，因为模型本身是轻量级的，信息主要通过微调写入权重。

GPT-3（2020）的发布引发了第一次范式转变：few-shot in-context learning 表明，通过在上下文中放置示例，可以在不更新权重的情况下让模型学会新任务。这是"上下文内容影响模型行为"这一核心认知的起点。

2021-2022 年，Prompt Engineering 成为独立技术领域：Chain-of-Thought prompting（Wei et al., 2022）9、Self-Consistency（Wang et al., 2022）、Tree of Thoughts——这些技术都在操作单一文本输入，核心是"如何触发模型的推理能力"。

4.2 分叉：RAG 的出现（2020-2023）

Retrieval-Augmented Generation（Lewis et al., 2020, NeurIPS）10 是 Context Engineering 的真正起点。RAG 第一次系统性地提出：模型的上下文不应该只是一条 prompt，而是应该实时从外部知识库检索信息注入上下文窗口。

这个想法在逻辑上打开了一个新的工程问题域：如果上下文可以包含检索到的文档，那检索质量、注入格式、信息密度都成了工程变量。"写一条好 prompt"的框架不再足够。

2022-2023 年，随着 GPT-4 和 Claude 的商业落地，RAG 管线开始工业化：LlamaIndex（2022，原名 GPT Index）专注于文档处理和检索；LangChain（2022）提供了更通用的链式调用框架。这一时期的实践经验揭示了 RAG 的核心工程难点不在检索本身，而在"如何清洁、分块、格式化文档"（约束理论：瓶颈在数据处理而非模型）。

4.3 Agent 浪潮与多步骤问题（2023-2024）

GPT-4 的 Tool Use 和 Function Calling（2023 年 6 月）改变了 LLM 的使用范式：模型不再只生成文本，而是可以在生成中触发外部工具调用，再基于结果继续生成。这把单轮的"文本生成"变成了多轮的"决策-执行-观察"循环。

这个循环带来了一个新的失败模式：多步骤状态一致性。每一轮 LLM 调用的上下文窗口都在变化（加入工具执行结果、新的用户输入），模型需要基于动态变化的上下文持续做出正确决策。早期 Agent 框架（AutoGPT，2023 年 3 月，GitHub 迅速破 100k star）的实践表明，多步骤任务的失败率极高——模型在第 5、6 步往往已经忘记了第 1 步的目标，或者在工具输出与期望格式不匹配时崩溃（路径依赖：早期架构决策决定了大量后续工程债务）。

SagaLLM（arxiv:2503.11951, 2025）从软件工程借用了 Saga 事务模式，系统性地解决这个问题：持久化记忆 + 独立验证 Agent + 自动补偿机制，构成了一个有事务保障的多 Agent 协调框架。实验结果表明，独立 LLM 在多约束场景下频繁失败，而有结构化上下文管理的 SagaLLM 在一致性和验证准确性上有显著提升。11（约束理论：多步骤 Agent 的瓶颈在上下文一致性，而不在单步模型能力）

4.4 Context Engineering 作为独立概念的涌现（2024-2025）

Andrej Karpathy 在 2025 年初开始在公开场合使用"Context Engineering"这个词，描述他在 LLM 应用工程实践中观察到的核心技能。2025 年 6 月，Tobi Lutke 在讨论 Shopify 内部 AI 实践时使用了同一个概念，迅速引发技术圈讨论。

学术界对这个词的正式采用出现在 2025 年下半年： - arxiv:2510.26493（2025-10）："Context Engineering 2.0: The Context of Context Engineering"——第一篇以这个词为核心的学术综述 - arxiv:2510.07414（2025-10）："Haystack Engineering: Context Engineering for Heterogeneous and Agentic Long-Context Evaluation"——将 Context Engineering 应用于长上下文评估

医学领域也在 2025 年开始采用这一框架：Journal of Precision Oncology 发表"From Prompt Engineering to Context Engineering: Why Precision Oncology Needs Context"12，表明这个概念已超出 AI 工程社区。

arxiv:2602.05447（2026-02）的"Structured Context Engineering for File-Native Agentic Systems"是目前方法论最系统的学术研究：9,649 次实验，量化了上下文工程各个决策变量的实际影响，确立了 Structured Context Engineering 作为研究子领域的地位。6

4.5 Harness Engineering：工程实践的另一侧翼

与 Context Engineering（关注"给模型什么"）平行发展的，是 Harness Engineering（关注"如何约束模型输出"）。

这个方向的核心洞察是：如果 LLM 的输出是 Agent 工作流的中间步骤，那么输出的结构可靠性是整个流程的关键约束。当模型输出了格式错误的 JSON，下游系统崩溃；当模型调用了不存在的工具参数，执行失败；当模型在第 3 步生成了与第 1 步矛盾的判断，整个任务链路崩溃。

Harness（意为"驾驭/约束"）的技术手段包括： - Schema 验证：定义输出格式的严格 schema，使用运行时验证捕捉格式错误 - 状态外置：不依赖 LLM 的"记忆"维护状态，而是将状态存储在外部系统（数据库、状态机）中，每次注入上下文 - 约束解码（Constrained Decoding）：在 token 采样层面强制输出符合语法/schema 的序列。Pre3（ACL 2025）13 通过确定性下推自动机（Deterministic Pushdown Automata）实现了对 LR(1) 语法的高效约束，比现有方法显著降低运行时开销

HN 社区（2025-2026）中，Altimate Code 的实践案例是目前最具说服力的 Harness Engineering 基准：通过 Rust 引擎提供实时 SQL 血缘追踪（0.26ms/查询）和反模式检测（0.48ms/查询），将基于 Claude Sonnet 的 SQL Agent 准确率从约 40% 提升至 74.4%——更便宜的模型 + 编译工具层 > 更贵的裸模型。14

4.6 为什么现在成为焦点

触发因素可以追溯到三个相变点（相变模型）：

  1. 2023 年 6 月，Function Calling：LLM 从文本生成变成 Agent 执行引擎，多步骤上下文一致性成为工程核心问题
  2. 2024 年，RAG 工业化：检索成本下降，向量数据库普及，"在上下文里放更多信息"变得可行且必要
  3. 2025 年，长上下文窗口（100k+）普及：上下文容量不再是约束，"放什么、怎么放"成为决定性变量

（反馈回路：更大的上下文窗口 → 可以注入更多信息 → 信息质量的影响更显著 → 更多工程资源投入上下文工程 → 工具链和方法论成熟 → 更多 Agent 落地 → 需要更好的上下文工程）

五、生态位与对照

5.1 Context Engineering vs. Prompt Engineering

维度 Prompt Engineering Context Engineering
对象 一条文本字符串 一个动态系统
时态 静态（预先设计） 动态（运行时生成）
核心技能 语言学、模型行为直觉 软件系统工程
失败来源 指令不清晰、格式触发问题 信息缺失、格式错误、状态不一致
调试方法 修改文本、A/B 测试 系统日志、数据流追踪
规模 单次对话 多步骤工作流

Prompt Engineering 是 Context Engineering 的子集——System Prompt 的设计仍然属于前者，但 Context Engineering 的工程范围远超于此。这不是替代关系，而是包含关系加外延扩张。

5.2 Context Engineering vs. Fine-tuning

Fine-tuning 把知识和行为写入模型权重（永久），Context Engineering 在推理时动态注入（临时）。两者不竞争——Fine-tuning 适合稳定的领域知识和行为约束，Context Engineering 适合实时变化的任务信息。

实践中的选择原则：如果信息会变化（用户数据、实时知识），用 Context Engineering；如果行为需要在所有场景下一致（风格、安全约束），用 Fine-tuning。两者组合使用是生产系统的常态。

5.3 Context Engineering vs. Harness Engineering

这是混淆最多的对照关系。用户的先验把 Harness Engineering 定义为"用代码约束而非提示词管理 AI"，这个描述实际上覆盖了两个层面：

  • Context Engineering（输入侧）：决定给模型什么信息。动态上下文构建、RAG、记忆管理。
  • Harness Engineering（输出侧）：约束模型的输出格式和行为。Schema 验证、约束解码、状态外置、事务性保障。

两者都在"用代码替代 prompt"这个大方向上，但作用点不同：Context Engineering 作用于 LLM 的输入端，Harness Engineering 作用于 LLM 的输出端和执行环境。

在 Agent 工程实践中，两者往往被整合进同一个框架（如 SagaLLM）：上下文管理 + 输出验证 + 状态外置，三者联动才能保障多步骤 Agent 的可靠性。

5.4 逆向推问：如果 Context Engineering 不存在

如果没有 Context Engineering 这个概念，LLM 应用工程实践会走向两条路：

路径 A：持续追求更强的模型。这是 2022-2023 年的主流心态——模型更强就能解决所有问题。但 Schema First 论文（arxiv:2603.13404）的实验结论是：即便在提升了工具接口设计之后，任务成功率仍为零，因为根本问题是语义理解而非接口格式。8 更强的模型确实有帮助，但不能解决上下文结构问题。

路径 B：更精密的 Prompt Engineering。这会遇到规模天花板：多步骤 Agent 的 prompt 复杂度随任务深度指数增长，人工维护不可行。

Context Engineering 提供的是路径 C：把上下文的构建和管理工程化、系统化——这是 A 和 B 都无法覆盖的解法空间。

5.5 约束与瓶颈分析

TraceSafe（arxiv:2604.07223, 2026）的发现揭示了当前最核心的瓶颈：15

护栏（guardrails）的效能更多取决于结构数据处理能力（如 JSON 解析），而非语义安全对齐。具体数据：与结构化-文本基准的相关系数 ρ=0.79，与标准越狱鲁棒性几乎零相关。

这意味着：当前 Context Engineering 的核心瓶颈不在"给模型什么信息"，而在"模型能否可靠地处理和输出结构化数据"。这是一个从工程侧（上下文构建）转向模型侧（结构理解能力）的约束转移——当上下文工程做好了，瓶颈就暴露在模型的结构处理能力上。

六、核心洞察

6.1 Agent 失败的主因在系统，不在模型

这是最重要也最反直觉的发现。多数 Agent 失败案例归根溯源，不是模型不够聪明，而是"模型没有足够的信息做出正确判断"（上下文缺失）或"模型做出了正确判断但输出格式不符合下游期望"（输出约束不足）。

Anthropic 的工程实践报告明确表述：Agent 失败的根本原因往往不是模型失败，而是上下文失败。4 SagaLLM 的实验数据支持这一结论：相同的 LLM，加上结构化的上下文管理，一致性和验证准确性显著提升。11

这个洞察改变了工程资源的投向：与其换更贵的模型，不如先把上下文工程做好。Altimate Code 的基准证明了这一点的商业价值：通过 Harness 层（不换模型），准确率从 40% 提升到 74.4%。14（高置信）

6.2 格式选择的影响被高估

arxiv:2602.05447 的 9,649 次实验给出了一个明确结论：格式（YAML/JSON/Markdown）对整体精度无显著影响（p=0.484），但模型能力是主导变量（前沿模型 vs 开源模型相差 21 个百分点）。6

工程师在格式优化上投入的大量时间，边际收益远低于直觉预期。真正值得优化的是：信息的完整性（是否包含了所有必要信息）和位置（context rot 研究表明位置影响极大）。（高置信）

6.3 从"上下文"到"架构"的临界点

当前 Context Engineering 正在从"把信息塞进上下文窗口"向"设计上下文的动态生成架构"演进。这个转变的标志是 file-native agentic systems 的出现：Agent 不再接收一次性注入的上下文，而是按需从文件/数据库检索所需信息，上下文窗口变成了工作内存而非知识仓库。

这个架构转变在技术上类似于从内存数据库到外存数据库的演进——信息不需要全部在内存里，只需要在用到时被加载。（中置信：这个方向仍在早期，前沿模型的效果优于开源模型，普适性尚未确立）

6.4 学科边界的模糊是结构性的，不会消失

Context Engineering 和 Harness Engineering 的边界在生产系统中往往是人为划分的——SagaLLM 的架构同时包含两者，Altimate Code 的 Harness 层既约束输出也管理上下文。

这种边界模糊不是概念不清晰，而是反映了一个结构性事实：LLM Agent 的"输入端"和"输出端"是紧耦合的——输出的格式质量影响下一轮的上下文构建（工具执行结果注入），上下文的质量影响输出的可靠性。把两者分开讨论是分析框架的需要，实践中必须联动设计。（高置信）

6.5 三个未来剧本

最可能的剧本（中置信）：Context Engineering 标准化。类似于 RESTful API 设计有 OpenAPI 规范，未来 2-3 年内 Context Engineering 会有工业级规范——标准化的上下文组件接口、工具 schema 格式、记忆层 API。Anthropic 的 MCP（Model Context Protocol）已经在朝这个方向走。

最危险的剧本（推测）：模型能力跳变使大量 Context Engineering 工程工作贬值。如果未来的模型在长上下文处理上足够可靠（消除 context rot），如果工具调用的语义理解足够精确（消除接口误用），当前大量的工程工作可能变成历史包袱。这类似于垃圾回收机制出现后，手动内存管理技能贬值。

最乐观的剧本（推测）：Context Engineering 成为 AI 工程的基础学科。随着 AI Agent 在更多垂直场景落地，每个场景都需要定制化的上下文架构设计（医疗、金融、法律的知识结构完全不同）。Context Engineering 的专业化程度提升，类似于数据库工程从通用软件工程中分化出一个独立学科。

七、认知校准

你的先验理解

"就是精心设计喂给 AI 的上下文，让它输出得更好——感觉是 Prompt Engineering 的升级版，但不知道边界在哪里，也不确定它是不是一个真正独立的学科还是只是个营销词"

研究后的校准

✅ 确认：确实是 Prompt Engineering 的进化，且这个词比"高级 Prompt Engineering"更准确。Simon Willison 的分析支持了你对术语问题的直觉——"Prompt Engineering"被大众误解为"往聊天机器人里打字"，Context Engineering 的字面含义与实际工程实践更接近。

🔄 修正："喂给 AI 的上下文"这个表述抓住了对象，但方向感是反的——Context Engineering 的核心不是"精心设计"一条上下文，而是构建一个系统来动态生成上下文。这个区别很关键：前者的主语是人，后者的主语是系统。

🔄 修正："让它输出得更好"也部分正确，但完整的表述应该是：Context Engineering 的目标是让模型在正确的时间获得正确的信息——不仅是输出质量，更是系统的可靠性和可维护性。

💡 新发现：你提到的 Harness Engineering（Schema 验证、状态外置）是 Context Engineering 的输出侧对应物。两者构成了 LLM Agent 工程的完整闭环：Context Engineering 管理输入，Harness Engineering 约束输出和执行环境。这个闭环在 SagaLLM 等框架中已经有了系统性实现。

💡 新发现："Context rot"现象——信息在上下文中的位置影响模型性能，而且这个影响即使在顶级模型（GPT-4.1、Claude 4、Gemini 2.5）上也存在。这意味着 Context Engineering 不只是"给模型足够的信息"，还要关注信息的呈现位置和顺序。

❌ 部分推翻："不确定它是不是真正独立的学科"——现在可以更确定地说：它是独立的。不仅有独立的学术论文轨迹（2025-2026 年的 arXiv 论文已有系统性研究），有独立的工具链，有独立的从业者技能画像，而且医学、数据工程等非 AI 领域已开始采用这个概念。这不是营销词。

最大的认知偏差在哪

你的先验把 Context Engineering 理解为"更高级的 prompt 写作"，这个偏差的根源在于：Prompt Engineering 这个词在用户认知里已经绑定了"静态文本优化"的语义，所以它的"升级版"自然被想象为"更复杂的静态文本"。但 Context Engineering 的升级不是在文本复杂度上，而是在工程抽象层次上——从字符串到系统。这两者之间的跨度，类似于从"写更好的 SQL 查询"到"设计数据库架构"。

哪个思维模型在本次研究中最有解释力

约束理论在这次研究中最有解释力。每次技术升级后，瓶颈都会漂移到新的位置：

  • Prompt Engineering 时代：瓶颈在"如何触发模型的推理能力"
  • RAG 出现后：瓶颈漂移到"检索质量和数据处理"
  • Tool Use 出现后：瓶颈漂移到"多步骤状态一致性"
  • Context Engineering 成熟后：TraceSafe 的数据表明瓶颈正在漂移到"模型的结构数据处理能力"

每次工程方法论的进步，都是在当前瓶颈上打通，让下一个瓶颈暴露出来。这个动态解释了为什么这个领域会持续演进，而不是有一个终极答案。

信息来源

  1. Andrej Karpathy, "Context Engineering", X/Twitter, 2025. 来源类型：业界人士公开发言. 访问日期：2026-04-17. （通过 Phil Schmid 博客二次引用） ↩

  2. Tobi Lutke (Shopify CEO), 公开评论, 2025-06. 来源类型：业界人士公开发言. 访问日期：2026-04-17. （通过 Simon Willison 博客记录） ↩

  3. Phil Schmid, "Context Engineering: The Next Evolution in AI Development", philschmid.de, 2025-06-30. 来源类型：技术博客（官方站点）. URL: https://www.philschmid.de/context-engineering. 访问日期：2026-04-17. ↩↩

  4. Anthropic, "Building Effective Agents", Anthropic Engineering Blog, 2024. 来源类型：官方工程文档. URL: https://www.anthropic.com/engineering/building-effective-agents. 访问日期：2026-04-17. ↩↩

  5. Simon Willison, "Context Engineering", simonwillison.net, 2025-06-27. 来源类型：技术博客. URL: https://simonwillison.net/2025/Jun/27/context-engineering/. 访问日期：2026-04-17. ↩

  6. [研究团队], "Structured Context Engineering for File-Native Agentic Systems: Evaluating Schema Accuracy, Format Effectiveness, and Multi-File Navigation at Scale", arXiv:2602.05447, 2026-02-05. 来源类型：学术论文（arXiv）. URL: https://arxiv.org/abs/2602.05447. 检索来源：SearXNG. ↩↩↩↩

  7. Chroma Research, "Context Rot" 研究, 2025. 来源类型：工业研究. （通过 Hacker News 讨论记录引用）访问日期：2026-04-17. ↩

  8. [研究团队], "Schema First Tool APIs for LLM Agents: A Controlled Study of Tool Misuse, Recovery, and Budgeted Performance", arXiv:2603.13404, 2026-03-12. 来源类型：学术论文（arXiv）. URL: https://arxiv.org/abs/2603.13404. 检索来源：SearXNG. ↩↩

  9. Wei, J. et al., "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models", NeurIPS 2022. 来源类型：学术论文. URL: https://arxiv.org/abs/2201.11903. ↩

  10. Lewis, P. et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS 2020. 来源类型：学术论文. URL: https://arxiv.org/abs/2005.11401. ↩

  11. [研究团队], "SagaLLM: Context Management, Validation, and Transaction Guarantees for Multi-Agent LLM Planning", arXiv:2503.11951 / VLDB 2025. 来源类型：学术论文（arXiv + 会议论文）. URL: https://arxiv.org/abs/2503.11951. 检索来源：SearXNG. ↩↩

  12. [作者], "From Prompt Engineering to Context Engineering: Why Precision Oncology Needs Context", Journal of Precision Oncology, 2025. 来源类型：学术论文. DOI: 10.1177/2993091x251388462. 检索来源：SearXNG (openairepublications). ↩

  13. [研究团队], "Pre3: Enabling Deterministic Pushdown Automata for Faster Structured LLM Generation", ACL 2025. 来源类型：学术论文. DOI: 10.18653/v1/2025.acl-long.551. 检索来源：SearXNG. ↩

  14. Altimate Code / Hacker News 社区讨论, "AI Harness for Data Engineering", 2025-2026. 来源类型：社区讨论. URL: https://hn.algolia.com/?q=harness+engineering+AI. 访问日期：2026-04-17. ↩↩

  15. [研究团队], "TraceSafe: A Systematic Assessment of LLM Guardrails on Multi-Step Tool-Calling Trajectories", arXiv:2604.07223, 2026-04-08. 来源类型：学术论文（arXiv）. URL: https://arxiv.org/abs/2604.07223. 检索来源：SearXNG. ↩

  16. [研究团队], "STED and Consistency Scoring: A Framework for Evaluating LLM Structured Output Reliability", arXiv:2512.23712, 2025-11-27. 来源类型：学术论文（arXiv）. URL: https://arxiv.org/abs/2512.23712. 检索来源：SearXNG. ↩

  17. [研究团队], "Context Engineering for Multi-Agent LLM Code Assistants Using Elicit, NotebookLM, ChatGPT, and Claude Code", arXiv:2508.08322, 2025-08. 来源类型：学术论文（arXiv）. URL: https://arxiv.org/abs/2508.08322. 检索来源：SearXNG. ↩

  18. Karl Marx (引用框架), "Context Engineering 2.0: The Context of Context Engineering", arXiv:2510.26493, 2025-10. 来源类型：学术论文（arXiv）. URL: https://arxiv.org/abs/2510.26493. 检索来源：SearXNG. ↩