文章目录
1. 三代工程范式概览
1.1 时间线
┌─────────────────────────────────────────────────────────┐
│ AI 工程范式演进时间线 │
├─────────────────────────────────────────────────────────┤
│ │
│ 2023年 2024年 2026年 │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Prompt │ → │ Context │ → │ Harness │ │
│ │ Eng. │ │ Eng. │ │ Eng. │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ "怎么说得好" "知道什么" "在什么环境里做事" │
│ │
└─────────────────────────────────────────────────────────┘
1.2 核心对比表
| 维度 | Prompt Engineering | Context Engineering | Harness Engineering |
|---|---|---|---|
| 时间 | 2023年 | 2024年 | 2026年 |
| 核心问题 | 怎么"说"得好 | "知道"什么 | 在什么"环境"里做事 |
| 粒度 | 单次 LLM 调用 | 信息层/会话层 | 系统层/生命周期层 |
| 关注点 | 说什么、怎么说 | 知道什么、信息从哪来 | 在哪里工作、如何不出错 |
| 主要工具 | 模板、Few-shot | RAG、MCP、Memory | Linter、沙盒、验证回路 |
| 效果半衰期 | 模型更新即失效 | 相对稳定 | 随项目迭代越来越强 |
| 技术壁垒 | 低 | 中 | 高 |
| 适用场景 | 单次问答、简单任务 | 知识密集型任务 | 长时运行、生产级系统 |
1.3 包含关系
┌─────────────────────────────────────────────────────────┐
│ │
│ Harness Engineering │
│ (系统层/生命周期层) │
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ │ │
│ │ Context Engineering │ │
│ │ (信息层/会话层) │ │
│ │ │ │
│ │ ┌──────────────────────────────┐ │ │
│ │ │ │ │ │
│ │ │ Prompt Engineering │ │ │
│ │ │ (单次调用层) │ │ │
│ │ │ │ │ │
│ │ └──────────────────────────────┘ │ │
│ │ │ │
│ └────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
关键理解：这三种范式不是替代关系，而是嵌套包含的关系。Harness Engineering 包含 Context Engineering，Context Engineering 包含 Prompt Engineering。
2. Prompt Engineering 详解
2.1 核心定义
Prompt Engineering 是指通过精心设计输入给 LLM 的指令、示例和参数，以优化单次 LLM 调用输出质量的工程实践。
2.2 核心关注点
┌─────────────────────────────────────────────────────────┐
│ Prompt Engineering 关注点 │
├─────────────────────────────────────────────────────────┤
│ │
│ 🎯 说什么 (What to Say) │
│ ├─ 任务描述清晰度 │
│ ├─ 期望输出格式 │
│ └─ 约束条件明确性 │
│ │
│ 🎯 怎么说 (How to Say) │
│ ├─ 指令结构设计 │
│ ├─ Few-shot 示例选择 │
│ └─ 角色设定与语气 │
│ │
│ 🎯 参数调优 (Parameter Tuning) │
│ ├─ Temperature 设置 │
│ ├─ Top-p / Top-k │
│ └─ Max Tokens 控制 │
│ │
└─────────────────────────────────────────────────────────┘
2.3 典型技术
技术 1: Few-shot Learning
❌ Zero-shot（零样本）:
"将以下文本翻译成英文：
你好世界"
✅ Few-shot（少样本）:
"将以下文本翻译成英文：
例子 1:
输入：你好世界
输出：Hello World
例子 2:
输入：早上好
输出：Good Morning
输入：晚安
输出："
技术 2: Chain-of-Thought (CoT)
❌ 直接提问:
"约翰有 5 个苹果，他给了玛丽 2 个，然后买了 3 个，
现在他有多少个苹果？"
✅ CoT 提示:
"约翰有 5 个苹果，他给了玛丽 2 个，然后买了 3 个，
现在他有多少个苹果？
让我们一步步思考：
1. 约翰最初有 5 个苹果
2. 他给了玛丽 2 个，所以剩下 5 - 2 = 3 个
3. 他又买了 3 个，所以现在有 3 + 3 = 6 个
4. 答案是：约翰现在有 6 个苹果"
技术 3: Role Prompting
❌ 普通提示:
"帮我写一个 Python 函数来排序数组"
✅ 角色提示:
"你是一位有 10 年经验的 Python 专家，
精通算法设计和代码优化。
请帮我写一个 Python 函数来排序数组，
要求时间复杂度为 O(n log n)。"
2.4 能力边界
✅ 擅长的场景
- 单次问答
- 文本生成/改写
- 简单推理
- 格式转换
❌ 无法解决
- 多步骤任务的一致性
- 跨会话的状态管理
- 架构级的行为约束
- 长期可维护性
2.5 效果半衰期
┌─────────────────────────────────────────────────────────┐
│ Prompt Engineering 效果衰减 │
├─────────────────────────────────────────────────────────┤
│ │
│ 效果 │
│ 100% ┤● │
│ 80% ┤│● │
│ 60% ┤││● │
│ 40% ┤│││● │
│ 20% ┤││││● │
│ 0% ┼┼┼┼┼┼───────────────────────────────────── │
│ 模型更新发布 → │
│ │
│ 💡 问题：模型一旦更新，精心设计的 Prompt 可能失效 │
│ │
└─────────────────────────────────────────────────────────┘
3. Context Engineering 详解
3.1 核心定义
Context Engineering 是指通过 RAG（检索增强生成）、MCP（模型上下文协议）、Memory 系统、AGENTS.md 等技术，为 LLM 提供相关上下文信息的工程实践。
3.2 核心关注点
┌─────────────────────────────────────────────────────────┐
│ Context Engineering 关注点 │
├─────────────────────────────────────────────────────────┤
│ │
│ 🎯 知道什么 (What to Know) │
│ ├─ 项目结构信息 │
│ ├─ 业务领域知识 │
│ ├─ 历史对话记录 │
│ └─ 实时系统状态 │
│ │
│ 🎯 信息从哪来 (Where From) │
│ ├─ 文档检索 (RAG) │
│ ├─ 代码库索引 │
│ ├─ 外部 API (MCP) │
│ └─ 数据库查询 │
│ │
│ 🎯 如何注入 (How to Inject) │
│ ├─ 上下文窗口管理 │
│ ├─ 信息优先级排序 │
│ ├─ Token 分配策略 │
│ └─ 压缩与摘要 │
│ │
└─────────────────────────────────────────────────────────┘
3.3 典型技术
技术 1: RAG (Retrieval-Augmented Generation)
┌─────────────────────────────────────────────────────────┐
│ RAG 架构 │
├─────────────────────────────────────────────────────────┤
│ │
│ 用户问题 │
│ ↓ │
│ ┌──────────────┐ │
│ │ 向量检索 │ ←→ 向量数据库 │
│ └──────────────┘ │
│ ↓ │
│ 检索相关文档 │
│ ↓ │
│ ┌──────────────┐ │
│ │ LLM 生成 │ ← 问题 + 检索到的文档 │
│ └──────────────┘ │
│ ↓ │
│ 答案 │
│ │
└─────────────────────────────────────────────────────────┘
技术 2: MCP (Model Context Protocol)
// MCP Server 示例
const mcpServer = {
name: "project-ctx",
version: "1.0.0",
// 提供项目上下文
resources: [
{
uri: "project://structure",
name: "项目结构",
description: "当前项目的目录结构",
mimeType: "text/plain"
},
{
uri: "project://dependencies",
name: "依赖关系",
description: "项目的依赖包列表",
mimeType: "application/json"
}
],
// 提供工具
tools: [
{
name: "search_code",
description: "在代码库中搜索",
inputSchema: {
type: "object",
properties: {
query: { type: "string" }
}
}
}
]
};
技术 3: AGENTS.md
# 项目 AI 协作地图
## 项目概述
这是一个使用 Spring Boot 的用户认证服务
## 构建命令
- 构建：./gradlew build
- 测试：./gradlew test
## 架构规则
- 依赖方向：domain → application → infrastructure
- 所有数据库操作通过 Repository 接口
## 关键文档
- 架构：docs/architecture.md
- API：docs/api.md
3.4 能力边界
✅ 擅长的场景
- 知识密集型问答
- 需要项目信息的任务
- 多轮对话场景
- 信息检索与整合
❌ 无法解决
- Agent 的行为约束
- 系统可靠性保证
- 长期代码库一致性
- 架构漂移问题
3.5 效果半衰期
┌─────────────────────────────────────────────────────────┐
│ Context Engineering 效果衰减 │
├─────────────────────────────────────────────────────────┤
│ │
│ 效果 │
│ 100% ┤●──────── │
│ 80% ┤│●───────────── │
│ 60% ┤││●──────────────── │
│ 40% ┤│││●─────────────── │
│ 20% ┤││││●──────────────── │
│ 0% ┼┼┼┼┼┼──────────────────────────────── │
│ 项目迭代 → │
│ │
│ 💡 相对稳定，但需要持续维护文档和索引 │
│ │
└─────────────────────────────────────────────────────────┘
4. Harness Engineering 详解
4.1 核心定义
Harness Engineering 是指围绕 AI Agent 设计和构建约束机制、反馈回路、工作流控制和持续改进循环的系统工程实践。
4.2 核心关注点
┌─────────────────────────────────────────────────────────┐
│ Harness Engineering 关注点 │
├─────────────────────────────────────────────────────────┤
│ │
│ 🎯 在哪里工作 (Where to Work) │
│ ├─ 沙盒环境设计 │
│ ├─ 权限边界设定 │
│ ├─ 资源访问控制 │
│ └─ 执行范围限制 │
│ │
│ 🎯 如何不出错 (How to Avoid Errors) │
│ ├─ 架构约束执行 │
│ ├─ 自验证循环 │
│ ├─ 错误恢复机制 │
│ └─ 循环检测与中断 │
│ │
│ 🎯 长期如何保持 (How to Maintain) │
│ ├─ 熵管理系统 (GC Agent) │
│ ├─ 跨会话状态管理 │
│ ├─ 持续改进循环 │
│ └─ 约束演进机制 │
│ │
└─────────────────────────────────────────────────────────┘
4.3 典型技术
技术 1: 自定义 Linter
# architecture_linter.py
import ast
class ArchitectureLinter:
def check_violations(self, code):
"""检查架构约束违规"""
violations = []
# 检查 domain 层是否引用 infrastructure
if "domain/" in self.file_path:
tree = ast.parse(code)
for node in ast.walk(tree):
if isinstance(node, ast.Import):
for alias in node.names:
if "infrastructure" in alias.name:
violations.append({
"rule": "ARCH-001",
"message": "domain 层不得引用 infrastructure 层",
"fix": "在 application 层定义接口",
"ref": "docs/architecture.md#dependency-rules"
})
return violations
技术 2: 自验证循环
class SelfVerificationLoop:
def execute(self, task):
"""强制 Build-Verify 循环"""
while True:
# 1. Plan
plan = self.agent.plan(task)
# 2. Build
code = self.agent.build(plan)
tests = self.agent.generate_tests(code)
# 3. Verify
test_result = self.run_tests(tests)
# 4. Fix (如果失败)
if not test_result.passed:
code = self.agent.fix(code, test_result.errors)
continue
# 测试通过，返回
return code
技术 3: 垃圾回收 Agent
class GCAgent:
def daily_doc_sync(self):
"""每日文档同步"""
# 检查最近修改的代码
recent_changes = self.get_recent_changes(hours=24)
for change in recent_changes:
# 检查对应文档是否更新
if not self.is_doc_updated(change):
# 创建修复 PR
self.create_pr({
"title": f"更新文档以反映 {change.file} 的变更",
"body": f"检测到 {change.file} 已修改，但对应文档未更新",
"actions": [
f"更新 {self.get_doc_path(change.file)}"
]
})
4.4 能力边界
✅ 擅长的场景
- 长时运行的 Coding Agent 任务
- 需要架构约束的系统
- 团队规模化使用 AI 生成代码
- 需要长期维护可靠性的系统
❌ 不适用场景
- 简单单次问答（过度设计）
- 纯实验性 Prototype（过早优化）
4.5 效果半衰期
┌─────────────────────────────────────────────────────────┐
│ Harness Engineering 效果演进 │
├─────────────────────────────────────────────────────────┤
│ │
│ 效果 │
│ 100% ┤││││●──────── │
│ 80% ┤││││││●─────── │
│ 60% ┤││││││││●──────── │
│ 40% ┤││││││││││●─────── │
│ 20% ┤││││││││││││●──────── │
│ 0% ┼┼┼┼┼┼┼┼┼┼┼┼┼───────────────── │
│ 项目迭代 → │
│ │
│ 💡 随项目迭代越来越强（正向复利） │
│ │
└─────────────────────────────────────────────────────────┘
5. 三代范式深度对比
5.1 多维度对比矩阵
| 对比维度 | Prompt Engineering | Context Engineering | Harness Engineering |
|---|---|---|---|
| 抽象层级 | 单次调用层 | 信息/会话层 | 系统/生命周期层 |
| 核心问题 | 怎么说得好 | 知道什么 | 在什么环境工作 |
| 设计焦点 | 输入优化 | 信息注入 | 系统设计 |
| 技术手段 | 模板、Few-shot | RAG、MCP、Memory | Linter、验证、GC |
| 时间跨度 | 单次请求 | 单次会话 | 整个项目生命周期 |
| 状态管理 | 无状态 | 会话级状态 | 跨会话持久化 |
| 失败处理 | 重新提示 | 检索更多上下文 | 修改环境，防止重犯 |
| 可测试性 | 困难（手动验证） | 中等（自动化检索） | 强（自动化验证循环） |
| 可维护性 | 低（模型更新失效） | 中（需维护文档） | 高（随迭代增强） |
| 上手难度 | ⭐ 简单 | ⭐⭐⭐ 中等 | ⭐⭐⭐⭐⭐ 困难 |
| 适用团队 | 个人试用 | 小团队 | 大型团队/生产系统 |
5.2 典型场景对比
场景 1: 简单文本翻译
┌─────────────────────────────────────────────────────────┐
│ 场景：简单文本翻译 │
├─────────────────────────────────────────────────────────┤
│ │
│ Prompt Engineering: ✅ 最适合 │
│ - 直接提示："将以下文本翻译成英文" │
│ - 简单、高效、成本低 │
│ │
│ Context Engineering: ❌ 过度设计 │
│ - 不需要额外的上下文信息 │
│ - 增加复杂度和成本 │
│ │
│ Harness Engineering: ❌ 严重过度设计 │
│ - 完全不需要系统级约束 │
│ - 杀鸡用牛刀 │
│ │
└─────────────────────────────────────────────────────────┘
场景 2: 代码库问答
┌─────────────────────────────────────────────────────────┐
│ 场景：代码库问答 │
├─────────────────────────────────────────────────────────┤
│ │
│ Prompt Engineering: ⚠️ 不够 │
│ - 无法知道代码库结构 │
│ - 需要反复提供上下文 │
│ │
│ Context Engineering: ✅ 最适合 │
│ - RAG 检索相关代码 │
│ - MCP 提供项目结构 │
│ - 效果好、成本适中 │
│ │
│ Harness Engineering: ⚠️ 可能过度 │
│ - 如果只是问答，不需要强约束 │
│ - 除非是生产级知识管理系统 │
│ │
└─────────────────────────────────────────────────────────┘
场景 3: AI 驱动的代码生成系统
┌─────────────────────────────────────────────────────────┐
│ 场景：AI 驱动的代码生成系统 │
├─────────────────────────────────────────────────────────┤
│ │
│ Prompt Engineering: ❌ 完全不够 │
│ - 无法保证代码质量 │
│ - 无法防止架构违规 │
│ - 无法管理长期一致性 │
│ │
│ Context Engineering: ⚠️ 部分够用 │
│ - 可以提供项目上下文 │
│ - 但无法约束 Agent 行为 │
│ - 无法保证系统可靠性 │
│ │
│ Harness Engineering: ✅ 必须 │
│ - 架构约束确保代码质量 │
│ - 自验证循环保证测试通过 │
│ - GC Agent 管理长期一致性 │
│ - 费用和权限控制防止灾难 │
│ │
└─────────────────────────────────────────────────────────┘
5.3 效果对比实验
OpenAI 的实验结果清晰地展示了不同范式的效果：
┌─────────────────────────────────────────────────────────┐
│ LangChain Terminal Bench 2.0 对比 │
├─────────────────────────────────────────────────────────┤
│ │
│ 仅用 Prompt Engineering: │
│ ┌────────────────────────────────┐ │
│ │ 得分：52.8% │ │
│ │ 排名：第 30 名 │ │
│ └────────────────────────────────┘ │
│ │
│ Prompt + Context Engineering: │
│ ┌────────────────────────────────┐ │
│ │ 得分：58.5% │ │
│ │ 排名：第 15 名 │ │
│ └────────────────────────────────┘ │
│ │
│ Prompt + Context + Harness Engineering: │
│ ┌────────────────────────────────┐ │
│ │ 得分：66.5% │ │
│ │ 排名：第 5 名 ⭐ │ │
│ └────────────────────────────────┘ │
│ │
│ 💡 底层模型参数完全相同！ │
│ 💡 差异完全来自 Harness 设计！ │
│ │
└─────────────────────────────────────────────────────────┘
6. 如何选择合适的范式
6.1 决策树
开始
│
├─ 任务类型？
│ ├─ 简单文本处理 → Prompt Engineering
│ ├─ 需要知识检索 → Context Engineering
│ └─ 代码生成/多步骤 → 继续
│
├─ 任务时长？
│ ├─ 单次完成 → Context Engineering
│ └─ 需要多轮/跨会话 → 继续
│
├─ 团队规模？
│ ├─ 个人/小团队 → Context Engineering
│ └─ 大型团队 → 继续
│
├─ 可靠性要求？
│ ├─ 实验性质 → Context Engineering
│ └─ 生产级 → 继续
│
└─→ Harness Engineering
6.2 场景匹配表
| 场景 | 推荐范式 | 理由 |
|---|---|---|
| 文本翻译/摘要 | Prompt | 简单直接，无需额外上下文 |
| 问答机器人 | Context | 需要 RAG 检索知识库 |
| 代码库助手 | Context | 需要 MCP 提供项目信息 |
| 简单脚本生成 | Context | 提供 API 文档即可 |
| 复杂功能开发 | Harness | 需要架构约束和验证 |
| 团队协作编码 | Harness | 需要统一规范和 GC |
| 生产级 AI 系统 | Harness | 需要可靠性和长期维护 |
| 实验性项目 | Context | 快速迭代，不过度设计 |
6.3 混合策略
实际上，三种范式经常混合使用：
┌─────────────────────────────────────────────────────────┐
│ 混合策略示例 │
├─────────────────────────────────────────────────────────┤
│ │
│ 层级 1: Prompt Engineering │
│ └─ 设计好每次与 Claude 的对话指令 │
│ │
│ 层级 2: Context Engineering │
│ └─ 通过 CLAUDE.md 提供 AI 需要的项目信息 │
│ │
│ 层级 3: Harness Engineering (可选) │
│ └─ 对于关键操作，添加权限控制和验证循环 │
│ │
│ 💡 大多数团队可以从 Prompt + Context 开始 │
│ 💡 随着成熟度提升，逐步引入 Harness │
│ │
└─────────────────────────────────────────────────────────┘
7. 范式演进趋势
7.1 历史演进
2023年早期
├─ LLM 开始普及
├─ 发现"怎么问"很关键
└─ Prompt Engineering 兴起
2023年晚期 - 2024年
├─ 发现上下文很重要
├─ RAG 技术成熟
├─ MCP 协议推出
└─ Context Engineering 成为主流
2025年 - 2026年
├─ Coding Agent 进入生产
├─ OpenAI 百万行代码实验震撼业界
├─ Martin Fowler 深度分析
└─ Harness Engineering 成熟
7.2 未来展望
┌─────────────────────────────────────────────────────────┐
│ Harness Engineering 未来方向 │
├─────────────────────────────────────────────────────────┤
│ │
│ 2026-2027: 标准化 │
│ ├─ Harness 设计模式库 │
│ ├─ 行业标准规范 │
│ └─ 最佳实践沉淀 │
│ │
│ 2027-2028: 自动化 │
│ ├─ Agent 自我优化 Harness │
│ ├─ 自动约束生成 │
│ └─ 智能熵管理 │
│ │
│ 2028+: 融合 │
│ ├─ Harness 能力融入模型 │
│ ├─ "可撕裂原则"极致体现 │
│ └─ 新的范式可能出现 │
│ │
└─────────────────────────────────────────────────────────┘
7.3 关键观察
“好的 Harness 随模型变强而精简”
— Manus 团队经验
Manus 的核心团队发现，他们最大的性能提升来自于删除复杂的 RAG 管道和路由逻辑，转而依赖更强的基础模型。
启示： Harness 应该是"可撕裂"的（Rippable）。每隔 3-6 个月，重新审视 Harness 的每一个组件——如果模型已经能原生处理，果断删除。
8. 总结
8.1 核心要点
- 三种范式是嵌套包含关系，不是替代关系
- 没有最好的范式，只有最合适的范式
- 从简单开始，逐步演进：Prompt → Context → Harness
- 拥抱"可撕裂原则"：定期精简，删除过时的约束
8.2 选择指南
简单任务 → Prompt Engineering
知识密集 → Context Engineering
代码生成 → Context + Harness (入门级)
生产系统 → Full Harness Engineering
扫一扫
1243
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
