从提示词->上下文->harness工程的演进

早期的工程重心完全集中在模型本身——如何让它听懂话。然而，当我们将大模型应用于长周期的复杂真实业务（如连续运行数小时的自动编程、深度研究或 Anthropic 提出的 Computer Use/Claude Cowork 级别人机协作）时，我们发现单纯的“沟通”是不够的。

这就催生了AI工程学的三次迭代：从解决表达问题的 Prompt Engineering，到解决信息供给的 Context Engineering，最终走向解决稳定执行的 Harness Engineering。

1.Prompt Engineering —— 解决“如何表达清楚”

在这个阶段，模型被视为一个“拥有海量知识但缺乏常识的超级实习生”。工程的核心挑战是消除人类自然语言中的模糊性，将其转化为模型能够高概率生成正确输出的指令。

a. 核心命题与解决的痛点

• 核心命题：如何精准地向模型表达任务意图？
• 解决痛点：模型“听不懂”或“误解”指令，导致输出格式错误、风格不符或逻辑断层。
• 适用场景：单轮对话、短文本生成、静态的数据提取、翻译等“一问一答”式任务。

b. 关键突破技术

• 角色设定 (Role-playing)：通过赋予模型特定的人设（如“你是一个拥有20年经验的前端架构师”），隐式地激活模型权重中特定领域的知识分布，从而调整输出的专业度和基调。
• 少样本提示 (Few-shot Prompting)：通过提供 2-3 个高质量的输入/输出范例，利用模型的上下文学习（In-context Learning）能力，让它直接“模仿”而非仅仅“理解”规则。
• 思维链 (Chain-of-Thought, CoT)：强制要求模型在给出最终答案前，先输出分布推理过程（“Let's think step by step”）。这不仅是让输出更清晰，本质上是利用模型每生成一个 token 所消耗的算力，为复杂逻辑腾出“思考草稿纸”。

c. 局限性

Prompt Engineering 假设了环境是静态的。当面对需要跨越多个文档、需要调用外部工具或持续数天的任务时，静态的 Prompt 无法应对动态变化的信息流。

2.Context Engineering —— 解决“如何信息供给”

随着模型上下文窗口（Context Window）扩展到 1M 甚至 2M tokens（如 Claude 3 系），工程师们发现，一味地扩大窗口不仅极其昂贵，而且会导致模型“注意力涣散”（Lost in the Middle 现象）。因此，Context Engineering 应运而生，它不再关心“怎么说”，而关心“给它看什么”。
另一方面，即使模型能够支持超长上下文，但是在实际场景中，输入如果接近上下文窗口，不仅会出现上下文腐坏（内容过多，模型无法很好的分析和回答问题），也会出现上下文焦虑（提前结束输出）

a. 核心命题与解决的痛点

• 核心命题：如何在对的时间、以对的密度，向模型提供最相关的背景信息？
• 解决痛点：模型“看不到”关键信息，或者被过载的垃圾信息淹没导致幻觉（Hallucination）。
• 适用场景：企业级知识库问答、长文本代码库分析、多轮复杂交互。

b. 关键突破技术

• 检索增强生成 (RAG, Retrieval-Augmented Generation)：加入外挂知识库。通过向量数据库和混合检索技术，只把与当前 query 最相关的 Top-K 信息塞进提示词中。
• 渐进式披露 (Progressive Disclosure)：面对庞大的代码库，不一次性给全，而是先给目录树（Architecture Map），让模型自己决定需要“展开”查看哪个具体文件的代码。
• 分层上下文与状态注入：在多轮任务中动态维护上下文。Context Engineering 包含了“Prompt 规划”。它需要决定：System Prompt 里放什么（基础规则），历史消息保留多少（滑动窗口机制），当前执行步骤的上下文如何注入。

c. 局限性与向上的过渡

Context Engineering 保证了模型在单次推理时拥有“完美的情报”。但它仍然是一个静态的切片。当模型需要自主运行 8 个小时去重构一个微服务架构时，谁来决定什么时候去检索？如果检索失败了怎么办？如果模型陷入了死循环怎么办？这就是 Harness 需要接管的地方。

3.Harness Engineering —— 解决“如何稳定执行”

但从范围上来看，harness engineering相对于context engineering增加了状态管理、智能体编排与验证

a. 核心命题与解决的痛点

• 核心命题：如何构建一个鲁棒的运行环境，确保智能体在长周期任务中不脱轨、不遗忘、能自愈？
• 解决痛点：模型在执行长周期复杂任务时“做不对”（状态丢失、陷入死循环、产生滚雪球式的错误）。
• 典型案例：Anthropic 运行 8 小时无错的 Computer Use 智能体。它不是靠一个完美的 Prompt 撑了 8 小时，而是靠底层极其强壮的 Harness 架构。

b. 关键突破技术

• 多智能体编排 (Orchestration)：Harness 将任务拆解，分别派发给“规划者（Planner）”、“执行者（Actor）”和“评审者（Reviewer）”。
• 评估器分离与反馈循环 (Evaluators & Feedback Loops)：这是 Harness 的灵魂。当模型写完一段代码后，并不会立马标记任务的完成，而是自动在沙箱中运行编译、跑测试用例（Sensors）。如果报错，Harness 会将错误堆栈信息打包，重新扔回给模型要求修改。这完全独立于 Context Engineering，这是一种运行时（Runtime）的干预。
• 状态与工作区管理 (State & Workspace Management)：给模型配备持久化的“文件系统”和“记忆库”。让大模型可以将中间结果落盘（保存为文件），这样即使会话中断，Agent 也能读取上一步的工作状态继续执行，真正实现了跨会话的长期任务。

4.三者的区别

5.为什么长周期任务必须依赖 Harness？

如同 Anthropic 团队在构建长时间运行智能体时所发现的：大模型本质上是非确定性的（Non-deterministic），它们只思考下一个 Token。如果你让它连续思考 8 个小时，微小的错误概率会不断累积。

Context Engineering 只能保证每次思考时“手上拿的资料是对的”。 但只有 Harness Engineering 能够保证运行的过程稳定