欢迎来到**上下文工程（Context Engineering）**时代。如果说大语言模型（LLM）是 CPU，那么上下文就是 RAM。正如在传统计算中一样，我们管理这种“内存”的方式，定义了系统实际能够完成的任务上限。
多年来，我们一直把上下文窗口（Context Window）当成“杂物抽屉”。如果一个模型支持 128K token，我们就试图将 128K token 的原始文本塞进去，然后祈祷最好的结果。然而，结果往往差强人意：幻觉、忽略指令以及“记忆中断”。
2025 年的“苦涩教训（Bitter Lesson）”教会了我们：智能不仅是模型规模的函数，更是**信息密度（Information Density）**的函数。如果一个拥有 200 万 token 上下文的模型必须在 190 万 token 的噪声中进行筛选，它并不会变得更“聪明”。上下文工程是一门外科手术般精确地组装最佳提示词状态，以最大化模型推理能力的学科。它是从“检索增强生成（RAG）”向“上下文优化推理（Context-Optimized Reasoning）”的转型。在这个新范式中，我们优先考虑提示词的信噪比（SNR），并认识到每一个无关的 token 都是对模型认知带宽的征税。
在 2024 年，检索增强生成（RAG）曾是王者。我们将文档切成 500 token 的块，存储在向量数据库中，并检索最匹配的前 5 个块。这是源于当时较小的上下文窗口（8K 到 32K token）的权宜之计。
然而，由 Google 的 Gemini 1.5 Pro 开创，并在 Gemini 2.0 和 3.0 的 200 万+ token 窗口中日臻完善的**长上下文语境学习（Long-Context ICL）**的兴起，彻底改变了博弈规则。当你能将包含 50,000 个文件的整个代码库放入单个提示词时，传统的 RAG “切块（Chunking）”策略反而成了累赘。切块破坏了文件之间的结构化关系，丢失了代码库的“结缔组织”。
2026 年的视角：我们不再只是“检索切块”，而是“策划环境（Curate Environments）”。长上下文模型允许进行 RAG 永远无法实现的全局推理。例如，模型现在可以识别出前端 React 组件与后端 Go 服务之间微妙的架构不一致，因为它同时“看到”了两者，而不是将它们视为孤立的碎片。这实现了我们所谓的“全栈调试（Holistic Debugging）”，即模型可以在单次推理过程中追踪整个技术栈的数据流。
尽管 2026 年的模型拥有海量窗口，但 Transformer 架构的基本物理特性依然存在：注意力（Attention）是一种有限的资源。
来自 Anthropic（Claude 4）和 Google（Gemini 3）的研究确认，模型依然表现出“U 形”性能曲线。放置在上下文最开始（系统提示词）和最末尾（用户查询）的信息能得到高精度处理。然而，埋藏在中间的信息往往会遭受**注意力衰减（Attention Decay）的影响，这就是著名的“中间位置丢失（Lost in the Middle）”**现象。
从分析角度看，这是由于注意力机制中的 Softmax 归一化导致的。在一个 100 万 token 的序列中，中间位置的一个相关 token 必须与另外 999,999 个 token 竞争注意力权重的份额。此外，存储注意力状态的**KV 缓存（KV Cache）**随着序列长度的增加而变得越来越“嘈杂”。长程依赖必须跨越数百层自注意力，如果没有显式的强化，信号往往会消散。
工程解决方案：我们现在使用注意力感知排序（Attention-Aware Ranking）。我们不仅仅提供相关信息，还将最关键的“推理锚点（Reasoning Anchors）”——如核心 API 定义或关键约束——放置在上下文窗口的外围。通过将“沉重”的数据夹在开头和结尾的高重要性锚点之间，我们利用模型的架构偏置，确保注意力始终集中在最重要的位置。
如果说上下文是 RAM，那么**上下文剪枝（Context Pruning）**就是我们的垃圾回收器。在 2026 年，我们不再向模型发送原始文件。我们使用“剪枝代理（Pruner Agents）”——轻量级模型（如 Gemini Nano 或专门的基于 BERT 的评分器）——在昂贵的推理模型看到内容之前过滤噪声。
常见的剪枝技术包括：
如何在不耗尽上下文预算的情况下表达一个 100 万行的代码库？答案是层级化摘要（Hierarchical Summarization）。
在 AiDIY 项目中，我们实现了一种“摘要树（Tree-of-Summaries）”方法，提供信息的“渐进式披露”：
这允许 Agent 通过 L0-L2 拥有“全局感知”，同时通过 L3 保持“局部精度”。这种层级结构模仿了人类工程师导航代码的方式——我们并不记忆每一行，而是根据心理地图进行导航。当 Agent 需要某个 L1 模块的更多细节时，它会“向下钻取（Drill Down）”，按需将 L2 骨架替换为 L3 代码。
2026 年最显著的基础设施转变是提示词缓存（Prompt Caching）。Anthropic 在 2024 年的早期实验已演变为所有主要供应商的标准“KV 缓存即服务”。
在多 Agent 工作流中，“上下文移交（Context Handovers）”曾是延迟和成本的主要来源。Agent A 完成任务后，我们必须将整个 500K token 的历史记录重新发送给 Agent B。今天，我们使用持久化上下文句柄（Persistent Context Handles）。当 Agent A 完成一个回合时，其 KV 缓存状态会持久化在供应商的边缘节点。Agent B 随后只需引用 context_handle_id 即可恢复状态。
回合 1: 用户 -> [系统提示词 + 代码库 (已缓存/静态)] -> Agent A
回合 2: Agent A -> [结果 + 历史记录 (增量追加到缓存)] -> Agent B
回合 3: Agent B -> [优化后的解决方案] -> 用户
通过将上下文中的“沉重”部分（文档、代码库地图）保留在持久化缓存中，我们将“首个 Token 时间（TTFT）”从 10 秒降低到了 200 毫秒。“战略级 RAM”现在是持久化的，允许进行跨越数天工作的长程 Agent “会话”，而不会丢失其“思路”。
随着窗口的增大，出现了一种新的威胁：上下文投毒（Context Poisoning）。如果 Agent 在其长上下文窗口中检索到了恶意的第三方 README 或被投毒的 StackOverflow 片段，该片段可能包含“间接提示词注入（Indirect Prompt Injections）”。
在 2026 年，我们通过命名空间隔离和注意力掩码（Namespace Isolation and Attention Masking）来解决这个问题。上下文被划分为“可信”（内部代码、用户指令）和“不可信”（搜索结果、第三方文档）片段。我们使用专门的“护栏包装器（Guardrail Wrappers）”，用类 XML 标签包裹不可信文本。模型经过微调，可以识别这些标签为“被动数据”——模型可以阅读它们，但在架构上被阻止执行其中的任何祈使命令。这在上下文窗口内部创建了一个“数据沙箱”。
Rich Sutton 的“苦涩教训”指出：“利用计算能力的通用方法是最有效的。”在 2026 年的背景下，更新后的教训是：利用精心策划、经过工程化设计的上下文的通用模型是最有效的。
上下文工程不再是一个“锦上添花”的优化，它是现代 AI 技术栈的核心架构层。通过掌握长上下文 ICL、注意力感知排序和层级化摘要，我们将 LLM 从有天赋但健忘的“随机鹦鹉”转变为可靠的、专业级的工程合作伙伴。
展望 2027 年和 Gemini 4 的到来，前沿领域不再是我们可以容纳多少 token，而是我们可以在不丢失信号的情况下忽略多少 token。AI 的未来不仅在于构建更大的大脑，更在于构建更好、更高效的记忆。
一个原始模型，无论它多么智能，就像一个没有底盘、方向盘或刹车的强大引擎。在生产环境中，单靠引擎非但不能解决问题，反而是一种风险。所谓的“产品”，是确保引擎安全地将车辆带到目的地的整个系统。正是这种认识催生了 Harness 工程（Harness Engineering）这一学科——它是将概率模型转化为确定性智能体系统（Agentic System）的编排、安全和可观测性层。
在本文中，我们将深入探讨为什么 Harness（治理框架/工程支撑层）已成为智能体时代的“操作系统”，以及它如何定义“炫酷演示”与“可靠生产系统”之间的界限。
从核心来看，Harness 是一个复杂的控制系统。虽然简单的 LLM 调用是无状态且线性的（输入 → 输出），但智能体 Harness 是有状态且循环的。它在系统层面实现了我们所说的 OODA 循环（观察 Observe、定位 Orient、决策 Decide、行动 Act）。
在一个现代 Harness 中，“决策”（模型的输出）仅仅是一个步骤。Harness 会用校验和反馈循环来包裹这个决策。
如果没有这种结构，智能体就会遭受“上下文漂移”（Context Drift）的困扰，即推理循环在工具错误和幻觉中丢失了原始目标的踪迹。
在 2026 年，我们不再接受“内部服务器错误”作为智能体的最终状态。现代 Harness 是**自愈（Self-Healing）的。这是通过从简单的日志记录转向细粒度追踪（Granular Tracing）**实现的。
当工具执行失败时——无论是超时、格式错误、JSON 异常还是权限错误——Harness 都会捕获整个执行追踪（Trace）。使用像 AgentOps 这样的工具，这些追踪会立即由轻量级的“纠错模型”或基于启发式的修复智能体进行分析。
假设一个智能体生成的 SQL 查询由于语法错误而失败。
SQLException，将失败的查询、错误消息和架构上下文包装到一个新的提示词中。它要求模型“修复语法错误并重试”。这一过程对用户是透明的，最终实现了 raw 模型原本会陷入停滞的成功结果。这种“自愈”能力有效地将智能体工作流的可靠性提高了一个数量级，将成功率仅为 70% 的模型转变为成功率达到 99% 的产品。
智能体时代的可观测性不仅仅关乎 CPU 使用率或延迟；它关乎推理追踪（Reasoning Traces）。我们需要看到智能体为什么做出决策，而不仅仅是它做了什么。
生产级 Harness 将“思维链”（CoT）与“工具调用”分离。这允许开发人员监控智能体的内部逻辑。通过实施细粒度追踪，我们可以识别失败模式：
通过将这些追踪暴露给可观测性平台，团队可以不仅为“错误”设置警报，还为“逻辑偏离”设置警报。例如，如果智能体在某项任务上花费了超过 5 个推理周期且没有取得任何进展，则可能会触发警报。
随着智能体变得越来越复杂，传统的单元测试变得力不从心。你无法对一个概率系统进行单元测试。相反，我们已经转向使用**“黄金数据集”（Golden Sets）进行持久性测试（Durability Testing）**。
黄金数据集是 100 多个复杂、多步任务的精心集合，且具有已知的“良好”结果。持久性测试涉及针对该数据集重复运行智能体。
我们不再关心底层模型的“MMLU 分数”。相反，我们衡量：
通过使用以大模型为评判者（LLM-as-a-Judge）（通常是像 GPT-5 或 Claude 4 这样更强大的模型）来评估智能体工作的产出，我们为智能体行为创建了一个持续集成（CI）流水线。
安全是智能体落地的最大障碍。如果智能体拥有删除文件或转移资金的“能力”，它必须受到严格安全层的约束。
在工程良好的 Harness 中，工具不会与应用程序运行在同一个环境中。它们是**沙箱化（Sandboxed）**的。
Harness 充当双向防火墙。它检查用户输入以防范**提示词注入（Prompt Injection）攻击，并检查模型输出以防范数据泄露（Data Leakage）**或有毒内容。如果模型意外在响应中包含密钥，Harness 会在响应到达 UI 之前对其进行脱敏处理。
人工智能领域的发展速度极快。今天“最尖端”的模型在六个月后可能就会过时。这引出了我们的**“为删除而构建”（Build to Delete）**哲学。
生产级 Harness 必须是**模型无关（Model-Agnostic）**的。处理数据库错误的逻辑或校验送货地址的逻辑不应硬编码在模型的提示词中。相反，它应该是 模块化 Harness 架构 的一部分。
通过将推理引擎（模型）与执行环境（Harness）解耦，我们可以在几分钟内更换模型。当 OpenAI 发布更快的模型或 Anthropic 发布更易于调教的模型时，我们只需更新 Harness 中的“推理提供商”。安全护栏、状态机和自愈逻辑保持不变。这种模块化正是让 AI 应用“面向未来”的关键。
在 2026 年，我们不把 Harness 看作一个“包装器（Wrapper）”，而是将其视为智能体的操作系统。它提供了基础服务——内存、文件系统访问、安全和进程管理——使得“应用程序”（智能体的推理）能够可靠地运行。
展望未来，人工智能领域的竞争优势将不再属于那些拥有最大模型的人，而属于那些拥有最强大 Harness 的人。这是智能与工程交汇之处，也是概率与可靠性碰撞之处，更是“模型”最终蜕变为“产品”的归宿。
随着我们步入 2026 年，那个时代已经彻底结束。“魔法咒语”已经消亡，取而代之的是系统契约（System Contract）。提示词工程已经成熟为软件工程的一个严谨分支。在这里，自然语言被视为一种高级编排层，受到结构完整性、模式强制（Schema Enforcement）和严格性能优化的约束。本文将探讨这一转变，以及定义生产级 AI 系统的全新模式。
从启发式方法到系统契约的转变，源于一个根本性的认识：LLM 不是通过说服来响应的“魔盒”，而是基于上下文运作的概率推理引擎。当我们告诉模型“一步步思考”时，我们并不是在“激励”它，而是在触发一条特定的推理路径，为推理过程分配更多的计算资源（Token）。
在 2026 年，我们不再依赖这些脆弱的助推。现代框架将提示词视为一种规范（Specification）。正如 OpenAPI 规范定义了两个微服务之间的契约，系统契约定义了 LLM 交互的预期行为、约束条件和数据格式。如果模型失败了，我们不会去文本中寻找更好的“感觉（Vibe）”，而是寻找契约逻辑的漏洞或支撑数据的匮乏。这一转变标志着“提示词的专业化”：目标不再是诱导模型给出响应，而是从非确定性引擎中工程化出确定性的结果。
“推理模型”（如 OpenAI 的 o1/o3 以及随后的 GPT-5 一代）的到来，从根本上改变了提示词工程的版图。早期的模型需要关于“如何思考”的显式引导。然而，重推理的模型自带了内置的、内化的**思维链（Chain of Thought, CoT）**机制。
在与 GPT-5 或 o3 协作时，添加“让我们一步步思考”往往是多余的，甚至可能适得其反。正如 Google AI 在其 2025 年的《Gemini 3.0 架构报告》中指出的，在具有原生推理时间扩展（Inference-time Scaling）的模型中过度指定推理路径会导致“指令干扰”：模型优化的内部逻辑会与用户的脚本指令发生冲突。
在这种新范式下，指令的重要性在下降，而边界的重要性在上升。我们不再告诉模型如何解决问题，而是定义其解空间（Solution Space）。这包括：
通过专注于边界，我们允许模型的内部推理在既定的安全护栏内，寻找通往解决方案的最有效路径。我们将 LLM 视为一个能力极强但极度刻板的代理（Agent），它需要严谨的工作范围。
结构完整性是系统契约的支柱。依赖“自然语言流”是产生解析错误和幻觉的温床。
提示词设计中最显著的变化之一是 XML 标签的普及。虽然最初是由 Anthropic 推广的，但这种模式现在已成为跨模型的标准。诸如 <context>、<instructions>、<example> 和 <output_schema> 之类的 XML 标签提供了清晰的语义边界，模型的注意力机制可以轻松锁定这些边界。
<task_specification>
<context>
你正在分析一个旧有的 COBOL 代码库，以查找潜在的内存泄漏。
该系统运行在基于 CICS 的 IBM z/OS 环境中。
</context>
<constraints>
- 仅报告与 CICS 事务处理相关的泄漏。
- 忽略批处理模块中的泄漏。
- 输出必须是符合所提供模式的有效 JSON。
</constraints>
<input_code>
{{CODE_SNIPPET}}
</input_code>
</task_specification>
XML 优于 Markdown 标题，因为它是无歧义的。当“关于代码的指令”和“包含指令的代码”被包裹在不同的标签中时，模型可以轻易区分它们。它还支持嵌套结构，这对于复杂的、多阶段的 Agent 工作流至关重要。
陈旧的“扮演一名高级开发人员”已经演变为系统能力配置集（System Capability Profiles）。我们不再定义模糊的人格，而是定义一套可用的“思维工具”和知识领域。我们告诉模型：“你可以访问以下领域知识：[Rust 所有权检查器, Actix-Web 模式]。你被限制在以下编码风格：[禁止使用 Unsafe, 函数式优先]。”
这是一份能力的契约，而不是一场戏剧表演。通过显式定义模型的“心理状态”和“工具箱”，我们降低了其响应的方差。本质上，我们是在通过上下文“配置”模型的权重，将其引导至与任务最相关的高维子空间。
在 2026 年，“纯文本”被视为一种过时的输出格式。现代系统使用**结构化输出（Structured Outputs）或受限解码（Constrained Decoding）**来确保模型的输出符合严格的 JSON Schema 或 Pydantic 模型。这使 LLM 从“散文生成器”转变为“数据生成器”。
当输出被保证是匹配特定模式的有效 JSON 对象时，LLM 可以直接集成到类型安全的代码库中，无需脆弱的正则解析或“遇错重试”循环。模式（Schema）本身成为系统契约的一部分，精确定义了模型必须提供什么信息以及以何种格式提供。
随着 LLM 集成到实时生产系统中，延迟成为了首要敌人。业界的回答是提示词缓存（Prompt Caching）。
提示词缓存允许 LLM 供应商存储提示词初始部分的“编译状态”。如果提示词的前缀（例如，你那 10,000 Token 的系统指令和文档语料库）在不同调用之间保持一致，模型可以“跳过”该部分的计算，从而极大地缩短**首字延迟（Time-To-First-Token, TTFT）**并降低成本。
这催生了前缀模式（Prefixing Pattern）：
提示词工程现在涉及精细地排列这些层，以最大化“缓存命中”。如果你在提示词的最开始放了一个动态日期或用户名，你就破坏了其后所有内容的缓存，实际上会导致延迟翻倍并显著增加账单。
AI 工程中一个反复出现的辩论是：何时微调模型，何时使用上下文学习（In-Context Learning, ICL）。在 2026 年的格局中，**多样本 ICL（Many-shot ICL）**已成为大多数企业任务的主导策略。
随着上下文窗口达到数百万 Token（如 Gemini 2.0/3.0, Claude 5），我们可以将数百甚至数千个示例直接注入提示词。OpenAI 在 2025 年关于“多样本上下文学习”的研究表明，提供 500-1000 个高质量示例的模型在相同任务上的表现往往优于微调模型，且具有“即时更新”的额外优势。
如果业务逻辑发生了变化——比如你的金融代理有了新的监管要求——你只需更新提示词中的示例即可。相比之下，微调会创建一个“冻结”的伪像，需要完整的重新训练周期和评估流程才能更新。ICL 是 LLM 世界的“内存（RAM）”——快速、灵活、易失；而微调则是“硬盘”。在 2026 年，对于任何需要敏捷性的任务，我们优先考虑上下文智能（Contextual Intelligence, ICL）而非参数化智能（Parametric Intelligence, Fine-tuning）。
为了说明这些概念，让我们看看 AiDIY 项目中使用的现代编程代理提示词结构。注意其中没有废话，并大量使用了结构化契约。
# 系统契约：AiDIY-CODE-V2
## 版本：2026.4.5
## 状态：生产环境
<capabilities>
- 多文件重构及依赖图分析。
- 通过 `grep_search` 和 `ast_parser` 进行符号搜索。
- 生成单元测试（Vitest/Pytest），目标是 100% 的分支覆盖率。
</capabilities>
<environment_context>
- 项目：AiDIY 知识库（微前端架构）
- 语言：TypeScript 5.8 / Node.js 24
- 标准：整洁架构（Clean Architecture）, 六边形架构, 领域驱动设计 (DDD)。
- 测试：Vitest + Playwright。
</environment_context>
<operating_protocol>
1. 研究：使用 `list_directory` 和 `grep_search` 映射依赖关系。
2. 计划：在 `<plan>` 标签内输出技术实现方案。
3. 执行：使用 `replace` 工具应用手术式的更改。避免对部分更新使用 `write_file`。
4. 验证：执行本地测试套件和 Lint 检查。
</operating_protocol>
<constraints>
- 在 TypeScript 中绝不使用 'any' 或 'as' 类型断言。
- 所有文件路径必须是绝对路径，并经由 `ls` 验证。
- 不得修改 `.env` 文件或凭据。
- 更改范围严格限制在 `<task>` 标签内。
</constraints>
<output_contract>
- 所有推理过程必须包裹在 <thought> 标签内。
- 工具调用必须是符合工具规范（Tool Specification）的有效 JSON。
- 最终响应必须对照原始 `<plan>` 总结更改内容。
</output_contract>
这个提示词不是一段对话，它是一个执行环境。它定义了工具、规则以及代理预期的状态转换。
展望 2020 年代的后半叶，“代码”与“提示词”之间的界限将继续模糊。我们正看到 **提示词领域特定语言（Prompt DSLs）**和编译器的兴起，它们接收高级意图并针对特定的模型架构进行优化，自动从向量数据库注入相关示例，并修剪不必要的 Token 以适应模型的特定注意力头配置。
在这个时代取得成功的工程师将不是那些懂得如何与 AI “交谈”的人，而是那些懂得如何为其构建架构的人。他们将理解 ICL 与微调之间的权衡、提示词缓存的细微差别，以及模式驱动契约的至关重要性。提示词工程并未消亡，它终于成为了一门真正的工程学。我们正在从“魔法咒语”迈向“系统契约”，其结果比我们在 LLM 早期所想象的任何事物都更可靠、更具扩展性、更强大。
在翻译过程中，我遵循了 2026 年 AI 领域的专业语境，选择了以下术语：
This blog will feature technical deep-dives, tutorials, and insights from full-stack and AI engineering projects.
Stay tuned for more content!
]]>