从提示词到循环：AI Agent工程的四次范式跃迁

摘要：2023年我们还在研究如何"问得好"，2026年硅谷已经在讨论如何"设计循环"。AI应用开发的核心，正从"与模型对话"转向"设计系统让模型自主迭代"。本文将系统梳理AI Agent工程的四次范式跃迁，帮你在正确的阶段使用正确的工具。

---

引言：为什么你的AI Agent总是"一次性"的？

2023年，所有人都在讨论"提示词工程"（Prompt Engineering）。那时候，只要你能写出一个精妙的prompt，就能让GPT-4输出令人惊艳的结果。

但当你试图把AI能力嵌入真实业务场景时，问题来了：

• 问题1：如何让AI"记住"三天前的对话？
• 问题2：如何让AI"调用工具"并"处理失败重试"？
• 问题3：如何让AI"自我检查"并"迭代优化"输出？

你会发现，单纯优化提示词已经无法解决这些问题。于是，AI工程范式开始演进。

过去三年，AI工程经历了四次关键跃迁：

1. 提示词工程（Prompt Engineering）→ 如何让模型"听懂人话"？
2. 上下文工程（Context Engineering）→ 如何给模型"完整的信息环境"？
3. 驾驭工程（Harness Engineering）→ 如何控制模型"行为边界"？
4. 循环工程（Loop Engineering）→ 如何让模型"自我迭代、自我修正"？

这四次跃迁不是"替代关系"，而是"能力叠加"。理解这个演进路径，你才能在正确的阶段使用正确的工具，避免在简单任务上过度设计，或在复杂任务上能力不足。

📅 四次范式跃迁时间线

图注：从左到右展示AI Agent工程的四次范式跃迁路径，每次跃迁都是在前一阶段基础上的能力叠加。

---

第一阶段：提示词工程（Prompt Engineering）

核心问题：如何让模型"听懂人话"？

什么是提示词工程？

提示词工程是通过精心设计输入指令，引导大语言模型输出预期结果的技术。

最基础的提示词就是一句话：

"帮我写一首诗。"

但提示词工程的精髓在于结构化设计：

# 角色
你是一位资深的营养师，擅长制定个性化饮食方案。

# 任务
为一位35岁、久坐办公室、想减重的男性制定一周饮食计划。

# 约束
- 每天热量控制在1800卡路里以内
- 考虑到他不会做饭，以简单易做的菜谱为主
- 输出格式：表格形式，包含早中晚三餐

# 示例（Few-shot）
（这里给出一个示例日的饮食计划）

核心技术

1. Zero-shot vs. Few-shot

   • Zero-shot：不给示例，直接让模型完成任务
   • Few-shot：提供2-3个示例，让模型"照猫画虎"

2. 思维链（Chain-of-Thought, CoT）

   请一步步思考：
   1. 先分析用户的需求是什么？
   2. 再考虑有哪些关键信息缺失？
   3. 最后给出完整的回答。
   

3. 角色扮演（Role-playing）

   你现在是一位有10年经验的企业架构师...
   

典型工具

• PromptPerfect：自动优化提示词
• LangChain PromptTemplate：提示词模板管理
• OpenAI Playground：交互式调试提示词

局限性

提示词工程的核心是单次交互优化。它无法解决：

• ❌ 多轮对话的上下文管理
• ❌ 外部工具的调用与结果处理
• ❌ 长时间任务的记忆与状态管理

于是，上下文工程应运而生。

---

第二阶段：上下文工程（Context Engineering）

核心问题：如何给模型"完整的信息环境"？

什么是上下文工程？

2025年，Shopify CEO Tobi Lutke 在Twitter上发了一条引发轰动的推文：

“我更喜欢用’上下文工程’来代替’提示词工程’这个词。它更贴切地描述了核心技能：为任务提供足够的上下文，让大语言模型有可能得出合理解答的艺术。”

上下文（Context） 指的是在LLM推理时，所有落入"上下文窗口"的Token集合，包括：

• 系统指令（System Prompt）
• 用户当前输入（User Query）
• 历史对话记录（Chat History）
• 检索到的外部知识（RAG）
• 工具调用结果（Tool Results）
• 多模态输入（图片、音频等）

上下文工程的核心任务是：在有限的上下文窗口内，精确填入"最有价值的信息"。

📊 提示词工程 vs 上下文工程

核心技术

1. 上下文窗口管理

   • 问题：GPT-4 Turbo有128K Token窗口，但你的对话历史有200K，怎么办？
   • 解决方案：摘要压缩（用另一个模型把历史对话压缩成摘要）

2. RAG（检索增强生成）

   🔍 RAG架构图

   • 工具：LlamaIndex、LangChain Retrieval

3. 多轮对话管理

   • 问题：如何让模型"记住"三天前的对话？
   • 解决方案：消息历史摘要 + 长期记忆向量化存储

4. 工具调用结果注入

   User: 今天天气怎么样？
   → Agent调用get_weather("北京")
   → 将{"city": "北京", "temperature": "28°C"}注入上下文
   → 模型生成：北京今天28度，天气晴朗...
   

典型工具

• LangChain：上下文管理的事实标准
• LlamaIndex：专注于RAG场景
• Anthropic MCP（Model Context Protocol）：统一上下文供给协议

实战案例：构建一个"有记忆"的客服Agent

传统方案（只用提示词工程）：

系统提示：你是一个客服Agent，请友好地回答用户问题。
用户：我的订单什么时候发货？
模型：请提供订单号，我帮你查询。
用户：123456
模型：抱歉，我无法查询订单系统...

上下文工程方案：

系统提示：你是一个客服Agent，可以调用工具查询订单。
上下文：
- 用户历史对话（摘要）：用户对订单123456有疑问
- 工具调用结果：{"order_id": "123456", "status": "已发货", "eta": "明天"}
用户：123456什么时候到？
模型：你的订单123456已发货，预计明天送达。

局限性

上下文工程解决了"信息供给"问题，但无法解决：

• ❌ 如何控制Agent的"行为边界"？（比如：不允许删除数据库）
• ❌ 如何编排"多工具协同"的复杂任务？
• ❌ 如何保证Agent的"可观测性"？（出了问题怎么调试？）

于是，驾驭工程登场。

---

第三阶段：驾驭工程（Harness Engineering）

核心问题：如何控制Agent的"行为边界"？

什么是驾驭工程？

"Harness"这个词来自马具——给马套上鞍具，才能控制它的方向和速度。

驾驭工程的核心任务是：构建一个"安全可控"的Agent执行框架，让AI在预设的轨道上运行，而不是"自由发挥"。

核心技术

1. Agent 编排框架（Orchestration）

   🔄 Agent编排流程图

   说明：这是一个数据分析Agent的工作流，每个工具调用都是一个节点，有错误处理和人工审核环节。

   解决方案：LangGraph（LangChain的图形化编排框架）

   from langgraph.graph import StateGraph
   
   # 定义状态
   class AgentState(TypedDict):
       messages: list
       current_step: str
   
   # 定义工作流
   workflow = StateGraph(AgentState)
   workflow.add_node("search", search_node)
   workflow.add_node("analyze", analyze_node)
   workflow.add_node("write", write_node)
   workflow.add_edge("search", "analyze")
   workflow.add_edge("analyze", "write")
   

2. 工具选择与权限控制

   问题：如何让Agent"只能调用允许的工具"？

   解决方案：工具白名单 + 参数校验

   allowed_tools = ["search_tool", "calculator_tool"]
   # Agent无法调用 "delete_database_tool"
   

3. 执行流程的可观测性

   问题：Agent执行了10个步骤，第7步出错了，怎么快速定位？

   解决方案：LangSmith（LangChain的观测平台）

   • 记录每一次LLM调用
   • 可视化工作流执行路径
   • 追踪Token消耗、延迟、错误

4. 安全护栏（Guardrails）

   问题：如何防止Agent输出"有害内容"或"敏感信息"？

   解决方案：输出校验器

   from guardrails import Guard
   
   guard = Guard.from_rail("output_schema.py")
   validated_output = guard.validate(llm_output)
   

典型工具

• LangGraph：Agent编排框架
• AutoGen（微软）：多Agent协作框架
• CrewAI：专注于"角色化Agent团队"
• LangSmith：Agent可观测性平台

实战案例：构建一个"多工具协同"的数据分析Agent

任务：用户上传一份销售数据CSV，让Agent自动生成分析报告。

驾驭工程方案：

1. 用户上传CSV → Agent调用 "parse_csv_tool"
2. 数据解析完成 → Agent调用 "data_summary_tool"
3. 生成摘要 → Agent调用 "visualization_tool"（生成图表）
4. 图表生成 → Agent调用 "write_report_tool"
5. 报告生成 → 人工审核 → 结束

每一都有：

• ✅ 明确的输入/输出格式
• ✅ 错误处理（某一步失败，自动重试或回退）
• ✅ 权限控制（Agent无法访问除CSV外的其他文件）

局限性

驾驭工程解决了"可控执行"问题，但无法解决：

• ❌ 如何让Agent"自我检查"输出质量？
• ❌ 如何让Agent"根据反馈自动迭代"？
• ❌ 如何构建"闭环优化"的系统？

于是，循环工程成为最新前沿。

---

第四阶段：循环工程（Loop Engineering）

核心问题：如何让Agent"自我迭代、自我修正"？

什么是循环工程？

2026年6月，Anthropic的Boris Cherny在Twitter上宣布：

“我已经不再给机器写提示词了，我的工作是写循环。”

这句话标志着循环工程的正式诞生。

循环工程的核心思想是：

人不再与AI"对话"，而是退到上一层，设计一个"驱动AI自主迭代"的闭环系统。

一个典型的循环系统包含五个要素：

1. 明确的目标（Goal）：要达成什么？
2. 上下文管理（Context）：当前状态是什么？
3. 可调用的工具（Tools）：可以用什么手段？
4. 评估器（Evaluator）：怎么知道做得好不好？
5. 终止条件（Stop Condition）：什么时候停止？

🔁 循环工程的核心：反馈回路

说明：Agent执行 → 评估器打分 → 如果不及格，改进后重新执行 → 直到通过或达到最大迭代次数。

核心技术

1. 反馈回路设计（Feedback Loop）

   Agent执行任务 → 评估器打分 → 如果分数<80，重新执行 → 直到分数>80或达到最大迭代次数
   

2. 评估器与优化器（Evaluator + Optimizer）

   • Evaluator：用另一个LLM（或规则）评估输出质量
   • Optimizer：根据评估结果，调整策略重新执行

   from openloop import Loop, Evaluator
   
   loop = Loop(
       agent=coding_agent,
       evaluator=code_quality_evaluator,  # 评估代码质量
       max_iterations=5,
       threshold=80  # 质量分数>80才通过
   )
   
   result = loop.run("写一个FastAPI项目")
   

3. 自我反思（Self-Reflection）

   Agent：我写了一版代码，但我发现没有处理错误情况，让我重新写...
   

   实现方式：在上下文中注入"反思指令"

   系统提示：在每次输出前，先反思上一次输出的不足，然后改进。
   

4. 多轮迭代终止条件

   问题：Agent什么时候停止迭代？

   解决方案：

   • 质量阈值：评估分数>80
   • 最大迭代次数：最多迭代5次
   • 人工介入：迭代3次后仍不通过，转人工审核

典型工具

• OpenLoop（清华NMRC实验室）：循环工程开源框架
• Sentrux：实时架构传感器，帮助Agent"关闭反馈回路"
• Anthropic Evals：官方评估框架

实战案例：构建一个"自动改进代码质量"的编程Agent

任务：生成一个FastAPI项目，代码质量分数>80。

循环工程方案：

第1轮：
Agent生成代码 → 评估器打分：65分（缺少错误处理、测试覆盖率低）
       ↓
第2轮：
Agent根据反馈改进 → 评估器打分：72分（仍有bug）
       ↓
第3轮：
Agent再次改进 → 评估器打分：85分（通过！）
       ↓
输出最终代码

关键点：

• ✅ Agent不是"一次性生成"，而是"逐步迭代"
• ✅ 评估器提供具体反馈（哪行代码有问题）
• ✅ 终止条件明确（分数>80或最多5轮）

---

如何选择适合你的阶段？

理解了四次范式跃迁，关键问题是：你的项目应该用哪个阶段的技术？

🎯 决策流程图

使用建议：根据自己的任务特征，沿着流程图找到合适的阶段。

决策框架

你的任务类型	推荐阶段	典型场景
单次问答、内容生成	提示词工程	ChatGPT对话、文章写作
需要"记忆"或"外部知识"	上下文工程	客服Agent、知识库问答
需要"多步骤执行"或"工具调用"	驾驭工程	数据分析Agent、自动化工作流
需要"自我迭代"或"质量优化"	循环工程	代码生成、内容优化

常见误区

❌ 误区1：所有任务都用循环工程
→ 后果：算力成本暴增（每次迭代都要调用LLM）
→ 正确做法：根据任务复杂度选择

❌ 误区2：提示词工程已经过时
→ 后果：忽视基础，一味追求复杂框架
→ 正确做法：提示词工程仍是基础，其他阶段都依赖它

❌ 误区3：直接跳过某个阶段
→ 后果：基础不牢，系统不稳定
→ 正确做法：循序渐进，先掌握前一阶段再升级

---

四次范式的能力叠加关系

很多人误以为"新范式会替代旧范式"，但实际上，四次跃迁是能力叠加关系：

关键理解：

• 实线箭头：演进路径（后一阶段建立在前一阶段基础上）
• 虚线箭头：后续阶段仍依赖前面阶段的能力
• 例如：循环工程仍需使用提示词工程（如何写出好的评估提示词）

---

未来展望：下一步是什么？

从 Loop 到 Swarm（多Agent协作）

循环工程让单个Agent具备"自我迭代"能力，下一步自然是多个Agent协同工作：

Agent A（搜索专家） → Agent B（分析专家） → Agent C（写作专家）
       ↑                                        ↓
       └────── 反馈回路 ←──────────────────────┘

这就是Swarm Intelligence（群体智能）。

AI Engineering 会成为独立职位吗？

正如"数据工程师"从"软件工程师"中分化出来，我认为AI工程师（AI Engineer） 也会成为独立职位，其核心竞争力是：

• ✅ 不只是"调用API"，而是"设计系统"
• ✅ 掌握四次范式跃迁的完整工具链
• ✅ 理解业务需求，能选择合适的技术方案

给开发者的建议

如果你想知道"如何系统学习AI工程"，我的建议是：

1. 先掌握提示词工程（1-2周）

   • 读OpenAI的Prompt Engineering Guide
   • 在Playground上实践

2. 再学习上下文工程（2-4周）

   • 用LangChain做一个"有记忆"的Agent
   • 理解RAG的原理和实现

3. 然后实践驾驭工程（1-2个月）

   • 用LangGraph编排一个多步骤工作流
   • 部署一个真实的Agent应用

4. 最后探索循环工程（持续学习）

   • 关注OpenLoop、Sentrux等开源项目
   • 尝试在自己的项目中引入"评估-迭代"闭环

---

结语

从"提示词工程"到"循环工程"，AI应用开发的核心正在从**“如何让模型听懂人话”** 转向 “如何设计系统让模型自主迭代”。

这四次范式跃迁不是"新旧替代"，而是"能力叠加"。掌握完整演进路径，你才能在正确的阶段使用正确的工具。

与所有AI工程师共勉：我们不是在"写提示词"，而是在"设计智能系统"。

---

参考资源

1. Anthropic官方博客：《AI 代理的高效上下文工程》
2. Shopify CEO Tobi Lutke的Twitter：上下文工程的定义
3. GitHub - OpenLoop：循环工程开源框架
4. LangChain官方文档：Agent编排最佳实践
5. CSDN博客：《从Prompt Engineering 到Loop Engineering》系列

---

如果你觉得这篇文章有帮助，欢迎关注我，我会持续输出AI工程实战内容 🚀