"工具决定战略。当工具本身发生质变，整个战略体系都需要重构。"
自 ChatGPT 面世以来，AI 工程的核心范式已经悄然完成了三次迭代升级。每一次升级，都不是对前一阶段的否定，而是能力边界的系统性扩展。
理解这三个层次，是理解当前 AI 工程师核心竞争力的钥匙。
需要先说明一点：这三层不是"三代技术"的替代关系，也不是必须逐层通关的等级制度。它们回答的是三个完全不同的问题——怎么表达、喂什么信息、如何行动。工程师真正的成长，是从"只会调 Prompt"走到"能设计一套让模型自主干活的系统"。下面逐层拆解。
一、第一层：Prompt Engineering（提示词工程）
定义
Prompt Engineering 是指通过精心设计输入给 LLM 的文本（Prompt），引导模型产生预期输出的技术与艺术。
核心问题：如何表达指令，才能让模型最好地理解和执行？
这是 AI 工程的第一层，也是门槛最低的一层——它不需要训练模型，不需要改架构，只需要一句话写对。正因如此，它曾被误认为是"AI 工程师的全部工作"。
关键技术
零样本提示（Zero-shot Prompting）
不给任何示例，直接下达指令。它的效果高度依赖模型自身的指令遵循能力，是能力基线最快的一次探测：
直接指令，不提供示例：
"用三个关键词总结以下文章：{文章内容}"少样本提示（Few-shot Prompting）
提供示例建立范式。示例的作用不只是"教格式"，更重要的是对齐判断标准——当任务边界模糊（比如什么叫"消极"），一个示例胜过三句解释：
提供示例建立范式：
"以下是情感分析示例：
正面 → 积极
负面 → 消极
请分析：'{用户输入}'"思维链提示（Chain-of-Thought, CoT）
引导模型逐步推理，把"直接给答案"变成"先写过程再给答案"。这对数学、逻辑、多条件约束类任务尤其有效：
引导逐步推理：
"让我们一步一步地思考这个问题..."
结论：数学/逻辑类任务准确率提升 30-50%角色设定（Persona / System Prompt）
用系统提示定义模型的角色、语气与输出边界。它决定的不只是"说话风格"，还有模型愿意展开到什么程度、遇到不确定时如何表态：
"你是一位拥有20年经验的资深软件架构师，
以简洁、专业的风格回答技术问题..."ReAct（Reasoning + Acting）
在提示格式里交替安排"推理"与"行动"，让模型先想清楚再调用工具，再把观察结果接回推理链。这是通往第三层（Harness）的第一座桥：
交替推理与行动的提示格式：
思考：我需要先查询用户账户状态
行动：query_account(user_id="123")
观察：账户余额 500 元
思考：余额充足，可以处理退款
...核心工具与资源
局限性
Prompt Engineering 的本质局限是：它只能控制"说什么"，无法控制"拿什么来说"。
当模型缺少背景知识、上下文不够充分时，再好的 Prompt 也无济于事。你可以把指令打磨到极致，但模型依然不知道你家产品的定价、你客户的合同条款、你昨天刚上线的接口变更。这一层做到了极致，瓶颈就不再在表达，而在信息——于是问题自然上移到了第二层。
二、第二层：Context Engineering（上下文工程）
定义
Context Engineering 是指系统性地构建、组织和管理输入到 LLM 的完整上下文（Context Window），以最大化信息的有效性和推理质量的工程实践。
Andrej Karpathy 在 2025 年将其概括为：
"Context Engineering 是一门为模型在正确的时间填充正确的上下文窗口内容的艺术与科学。"
核心问题：用什么信息填充上下文窗口，以及如何组织这些信息？
注意这里的关键词是"系统性"和"组织"。上下文工程不是"把找到的资料全塞进去"——那是提示词工程时代的直觉，也是 RAG 落地最常见的失败原因。窗口是有限资源，塞得越满，信噪比越低。
Context 的组成要素
一个生产级应用的上下文窗口，通常同时装着七类信息。理解它们的层级和优先级，是上下文工程的第一步：
[完整上下文窗口]
┌─────────────────────────────────────────────────┐
│ System Prompt（角色定义、行为准则、输出格式） │
│ Retrieved Documents（RAG检索到的相关文档） │
│ Memory（来自向量数据库的历史对话摘要） │
│ Tool Definitions（可调用工具的API说明） │
│ Few-shot Examples（动态选择的相关示例） │
│ Conversation History（近期对话记录） │
│ User Message（当前用户输入） │
└─────────────────────────────────────────────────┘核心技术
RAG（检索增强生成）
把外部知识以检索的方式接入推理过程，是上下文工程最主流的落地形态：
用户问题 → 向量检索 → 相关文档片段 → 注入上下文
目标：解决模型"知识截止"和"幻觉"问题动态上下文管理
上下文窗口是有限资源（即使是200K也有上限），因此需要主动的取舍策略，而不是被动地堆叠：
问题：上下文窗口有限（即使是200K也有上限）
解决方案：
1. 滑动窗口：保留最近N轮对话
2. 摘要压缩：将历史对话压缩为摘要
3. 重要性评分：按相关性动态选择内容
4. 分层记忆：短期/长期记忆分离管理结构化上下文编排
同样的信息，放在不同位置，效果可能完全不同。上下文工程因此有了"版面设计"的属性——不同类型的信息应有固定的位置和格式：
不同类型的信息应有固定的位置和格式：
- 规则类信息 → System Prompt 前置
- 事实知识 → 问题前置（Lost in the Middle 效应）
- 示例 → 紧邻问题（Few-shot的效果取决于位置）Context Caching（上下文缓存）
把不变的部分（系统提示、静态文档）缓存成 KV Cache，只对变化的部分做增量计算。这是上下文工程里最"工程"也最省钱的一招：
固定的 System Prompt + 静态文档 → 缓存 KV Cache
动态的用户输入 → 增量计算
效果：成本降低90%，延迟降低50%Lost in the Middle 效应
研究发现，LLM 更倾向于关注上下文的开头和结尾，中间部分的信息容易被"遗忘"。
工程应对：将最重要的信息放在上下文的开头或末尾。
这个结论看起来简单，但它推翻了"把最相关资料放最前面就够了"的朴素做法——在长上下文场景里，位置本身就是一种信息权重。
Context Engineering vs Prompt Engineering
| 维度 | Prompt Engineering | Context Engineering |
|---|---|---|
| 关注点 | 指令的表达方式 | 上下文的内容与结构 |
| 技术范围 | 单次输入设计 | 完整信息架构设计 |
| 知识来源 | 仅限模型内在知识 | 内在知识 + 外部检索 |
| 动态性 | 静态模板为主 | 运行时动态构建 |
| 工程复杂度 | 低-中 | 中-高 |
从这张表能读出一件事：上下文工程把"写一句话"变成了"设计一套信息架构"。工程师的工作对象从文本变成了系统，从"我怎么问"变成了"模型在每一步能看到什么"。
三、第三层：Harness Engineering（驾驭工程）
定义
Harness Engineering 是指构建围绕 LLM 的完整"智能体操作系统"——通过工具调用、工作流编排、多 Agent 协作、状态管理、反馈循环等机制，将 LLM 的智能能力"驾驭"起来，使其能够自主完成复杂的多步骤任务。
等式：Agent = LLM + Harness
核心问题：如何将 LLM 的智能接入现实世界的工具和流程，使其能够自主行动？
"Harness" 这个词用得极准——它不是"包装"，而是"驾驭"。模型本身是一个能力很强但没有手脚、没有记忆、也没有边界感的个体；Harness 决定它能碰到什么、记得什么、失败时怎么办。
Harness 的核心组件
┌─────────────────────────────────────────────────────────┐
│ Harness 架构 │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Planner │────▶│ Executor │ │
│ │（任务分解/决策）│ │（工具调用/执行）│ │
│ └──────────────┘ └──────┬───────┘ │
│ │ │
│ ┌──────────────┐ ┌──────▼───────┐ │
│ │ Memory │◀────│ Observer │ │
│ │（短期/长期记忆）│ │（结果观察/反馈）│ │
│ └──────────────┘ └──────────────┘ │
│ │
│ Tools: [web_search, code_exec, file_read, API_call...] │
└─────────────────────────────────────────────────────────┘四件事缺一不可：Planner 决定做什么，Executor 真的去做，Observer 看结果对不对，Memory 让下一轮比上一轮聪明。
核心技术
工具调用（Function Calling / Tool Use）
工具调用把自然语言意图翻译成结构化调用。它的工程价值在于"约束"——模型只能调用被明确定义、参数被校验的能力：
[工具定义]
{
"name": "search_web",
"description": "搜索互联网获取最新信息",
"parameters": {
"query": {"type": "string"},
"num_results": {"type": "integer"}
}
}
[模型响应]
{
"tool_use": "search_web",
"arguments": {"query": "2026年AI算力趋势", "num_results": 5}
}ReAct 循环（Reasoning-Acting Loop）
推理与行动交替推进，每一步的观察结果都会改变下一步的推理方向：
Thought: 我需要查询最新的GPU价格
Action: search_web("NVIDIA H200 价格 2026")
Observation: H200 SXM 约 $35,000 per unit
Thought: 价格已确认，可以计算预算
Action: calculate(num_gpus=8, price_per_gpu=35000)
Observation: 总预算 $280,000
Answer: 8张H200的总预算约为28万美元多 Agent 协作
当任务复杂到单个 Agent 无法兼顾时，就拆分角色。分工的关键不是"人多"，而是每个角色都有明确的评判标准：
Orchestrator Agent（编排者）
├── Research Agent（负责信息搜索）
├── Code Agent（负责代码生成与执行）
├── Writing Agent（负责内容整合输出）
└── Critic Agent（负责质量审核）Reflection 与 Self-Correction
让 Agent 自己评估结果、发现错误、重新规划。这是把"一次性执行"变成"可收敛过程"的关键机制：
执行结果 → Critic 评估 → 发现错误 → 重新规划 → 再次执行
这种自我反思机制使 Agent 能够从错误中恢复工作流编排（Workflow Orchestration）
用状态机把控制流显式写出来——什么条件下循环、什么条件下结束、失败后回到哪一步。编排的价值是把"看起来像智能"的不确定性，收敛成可测试、可回滚的工程结构：
# LangGraph 风格的状态机
graph = StateGraph(AgentState)
graph.add_node("plan", planner_node)
graph.add_node("execute", executor_node)
graph.add_node("reflect", reflector_node)
graph.add_conditional_edges("reflect", should_continue_or_end)主流 Harness 框架
| 框架 | 定位 | 核心特点 |
|---|---|---|
| LangGraph | 状态图 Agent 框架 | 精确控制流，支持循环和条件分支 |
| AutoGen | 多 Agent 对话框架 | 微软出品，多角色协作 |
| CrewAI | 角色化多 Agent | 高层抽象，易用性好 |
| Manus | 通用 Agent 平台 | 闭源，端到端任务执行 |
| OpenHands | 开源代码 Agent | 擅长软件工程任务 |
| Claude Computer Use | 界面操作 Agent | 直接操控桌面/浏览器 |
Harness Engineering 的核心挑战
1. 可靠性（Reliability）
LLM 的随机性 + 工具调用的不确定性 = Agent 的高失败率。需要设计完善的重试、回滚、人工干预机制。工程上的现实做法是：假设每一步都会失败，然后为每一步准备退路。
2. 成本控制（Cost Management）
Multi-step Agent 的 token 消耗比单次对话高 10-100 倍。需要精细的工具选择策略和提前终止机制。当"再试一次"变得廉价时，成本就会失控。
3. 可观测性（Observability）
Agent 的决策链路复杂，调试困难。需要完整的轨迹记录（LangSmith、Arize、Langfuse）。没有轨迹，就无法回答"它为什么这么做"这个最基本的问题。
4. 安全边界（Safety Boundaries）
具备工具调用能力的 Agent 可能产生真实世界影响。"最小权限原则"和"人工确认节点"是必要的安全机制。
四、三层范式的演进逻辑
Prompt Engineering
→ 解决"如何表达"的问题
→ 适合：单次、静态、知识边界清晰的任务
Context Engineering
→ 解决"用什么信息"的问题
→ 适合：需要外部知识、长对话、个性化的任务
Harness Engineering
→ 解决"如何行动"的问题
→ 适合：多步骤、需要工具、自主决策的任务三者不是替代关系，而是递进包含：
Harness Engineering
├── 包含 Context Engineering（管理 Agent 的上下文）
│ └── 包含 Prompt Engineering（设计各节点的 Prompt）
└── 额外增加：工具、记忆、多步骤、多 Agent一个实用的判断方法
判断自己该往哪一层投入，可以问三个问题：
1. 模型"知道"但答不好？ → 问题在第一层，去优化指令、示例与输出格式。
2. 模型根本不知道这些信息？ → 问题在第二层，去做检索、记忆与上下文编排。
3. 模型知道也说得对，但做不了？ → 问题在第三层，去补工具、编排与反馈循环。
错层投入是很常见的浪费：给一个信息缺失的系统反复调 Prompt，或者给一个本来只需要一句好指令的任务套上多 Agent 编排。
五、AI 工程师能力重塑
| 阶段 | 核心技能 | 典型产出 |
|---|---|---|
| Prompt Engineering | 自然语言 + 少量编程 | Prompt 模板库 |
| Context Engineering | 信息架构 + RAG 系统 | 知识增强应用 |
| Harness Engineering | 系统设计 + 工具链集成 | 自主 Agent 系统 |
这张表的最后一列值得多看一眼：产出物在变重。模板库可以一个人一周写完；知识增强应用需要数据、检索、评测三条线；自主 Agent 系统则接近一个分布式系统的复杂度——它需要状态管理、失败恢复、权限控制、成本预算和可观测性。
未来的 AI 工程师，本质上是在设计一个以 LLM 为核心决策引擎的智能操作系统，而非仅仅调用 API。
总结
Prompt Engineering 教会了我们如何"说话"。
Context Engineering 教会了我们如何"备课"。
Harness Engineering 教会了我们如何"赋权行动"。
这三层范式的演进，映射了AI从"工具"到"智能体"的根本性转变。掌握这三层能力，是在AI时代保持竞争力的核心。
探索智能，酷在前沿