AI工程范式演进：Prompt → Context → Harness

文章目录1. 三代工程范式概览1.1 时间线1.2 核心对比表1.3 包含关系2. Prompt Engineering 详解2.1 核心定义2.2 核心关注点2.3 典型技术技术 1: Few-shot Learning技术 2: Chain-of-Thought (CoT)技术 3: Role Prompting2.4 能力边界✅ 擅长的场景❌ 无法解决2.5 效果半衰期3. Context Engineering 详解3.1 核心定义3.2 核心关注点3.3 典型技术技术 1: RAG (Retrieval-Augmented Generation)技术 2: MCP (Model Context Protocol)技术 3: AGENTS.md3.4 能力边界✅ 擅长的场景❌ 无法解决3.5 效果半衰期4. Harness Engineering 详解4.1 核心定义4.2 核心关注点4.3 典型技术技术 1: 自定义 Linter技术 2: 自验证循环技术 3: 垃圾回收 Agent4.4 能力边界✅ 擅长的场景❌ 不适用场景4.5 效果半衰期5. 三代范式深度对比5.1 多维度对比矩阵5.2 典型场景对比场景 1: 简单文本翻译场景 2: 代码库问答场景 3: AI 驱动的代码生成系统5.3 效果对比实验6. 如何选择合适的范式6.1 决策树6.2 场景匹配表6.3 混合策略7. 范式演进趋势7.1 历史演进7.2 未来展望7.3 关键观察8. 总结8.1 核心要点8.2 选择指南1. 三代工程范式概览1.1 时间线┌─────────────────────────────────────────────────────────┐ │ AI 工程范式演进时间线 │ ├─────────────────────────────────────────────────────────┤ │ │ │ 2023年 2024年 2026年 │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ Prompt │ → │ Context │ → │ Harness │ │ │ │ Eng. │ │ Eng. │ │ Eng. │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ 怎么说得好 知道什么 在什么环境里做事 │ │ │ └─────────────────────────────────────────────────────────┘1.2 核心对比表维度Prompt EngineeringContext EngineeringHarness Engineering时间2023年2024年2026年核心问题怎么说得好知道什么在什么环境里做事粒度单次 LLM 调用信息层/会话层系统层/生命周期层关注点说什么、怎么说知道什么、信息从哪来在哪里工作、如何不出错主要工具模板、Few-shotRAG、MCP、MemoryLinter、沙盒、验证回路效果半衰期模型更新即失效相对稳定随项目迭代越来越强技术壁垒低中高适用场景单次问答、简单任务知识密集型任务长时运行、生产级系统1.3 包含关系┌─────────────────────────────────────────────────────────┐ │ │ │ Harness Engineering │ │ (系统层/生命周期层) │ │ │ │ ┌────────────────────────────────────────────┐ │ │ │ │ │ │ │ Context Engineering │ │ │ │ (信息层/会话层) │ │ │ │ │ │ │ │ ┌──────────────────────────────┐ │ │ │ │ │ │ │ │ │ │ │ Prompt Engineering │ │ │ │ │ │ (单次调用层) │ │ │ │ │ │ │ │ │ │ │ └──────────────────────────────┘ │ │ │ │ │ │ │ └────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────┘关键理解这三种范式不是替代关系而是嵌套包含的关系。Harness Engineering 包含 Context EngineeringContext 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 示例constmcpServer{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 - APIdocs/api.md3.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.pyimportastclassArchitectureLinter:defcheck_violations(self,code):检查架构约束违规violations[]# 检查 domain 层是否引用 infrastructureifdomain/inself.file_path:treeast.parse(code)fornodeinast.walk(tree):ifisinstance(node,ast.Import):foraliasinnode.names:ifinfrastructureinalias.name:violations.append({rule:ARCH-001,message:domain 层不得引用 infrastructure 层,fix:在 application 层定义接口,ref:docs/architecture.md#dependency-rules})returnviolations技术 2: 自验证循环classSelfVerificationLoop:defexecute(self,task):强制 Build-Verify 循环whileTrue:# 1. Planplanself.agent.plan(task)# 2. Buildcodeself.agent.build(plan)testsself.agent.generate_tests(code)# 3. Verifytest_resultself.run_tests(tests)# 4. Fix (如果失败)ifnottest_result.passed:codeself.agent.fix(code,test_result.errors)continue# 测试通过返回returncode技术 3: 垃圾回收 AgentclassGCAgent:defdaily_doc_sync(self):每日文档同步# 检查最近修改的代码recent_changesself.get_recent_changes(hours24)forchangeinrecent_changes:# 检查对应文档是否更新ifnotself.is_doc_updated(change):# 创建修复 PRself.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 EngineeringContext EngineeringHarness Engineering抽象层级单次调用层信息/会话层系统/生命周期层核心问题怎么说得好知道什么在什么环境工作设计焦点输入优化信息注入系统设计技术手段模板、Few-shotRAG、MCP、MemoryLinter、验证、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 Engineering6.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