第1篇：从 Prompt 到 Loop：AI 应用开发范式的四次进化

Peter·Pan爱编程2026-06-28 8:40

文章目录

  • 引言
  • [一、第一阶段：Prompt Engineer ------ 让模型"听懂人话"](#一、第一阶段：Prompt Engineer —— 让模型"听懂人话")
    • [1.1 Prompt Engineer 在做什么？](#1.1 Prompt Engineer 在做什么？)
    • [1.2 Prompt Engineer 的天花板](#1.2 Prompt Engineer 的天花板)
  • [二、第二阶段：Context Engineer ------ 给 AI 装上"记忆"](#二、第二阶段：Context Engineer —— 给 AI 装上"记忆")
    • [2.1 为什么要管上下文？](#2.1 为什么要管上下文？)
    • [2.2 三大核心技术](#2.2 三大核心技术)
    • [2.3 Context Engineer 的天花板](#2.3 Context Engineer 的天花板)
  • [三、第三阶段：Harness Engineer ------ 给 AI 装上"手脚"](#三、第三阶段：Harness Engineer —— 给 AI 装上"手脚")
    • [3.1 从"说"到"做"](#3.1 从"说"到"做")
    • [3.2 工具编排：从单个 API 到工作流](#3.2 工具编排：从单个 API 到工作流)
    • [3.3 Harness Engineer 的天花板](#3.3 Harness Engineer 的天花板)
  • [四、第四阶段：Loop Engineer ------ 让 AI 进入自主循环](#四、第四阶段：Loop Engineer —— 让 AI 进入自主循环)
    • [4.1 什么是 Loop？](#4.1 什么是 Loop？)
    • [4.2 Loop Engineer vs 前三阶段的本质区别](#4.2 Loop Engineer vs 前三阶段的本质区别)
    • [4.3 Loop 的经典模式](#4.3 Loop 的经典模式)
  • 五、本专栏的路线图
  • 六、谁适合读这个专栏？
  • 总结

本系列为《Loop Engineer 实战：从提示工程到自主循环》第1篇

前置条件：对 ChatGPT/大模型有基本使用经验即可，无需编程基础。

引言

2026年，大语言模型（LLM）已经渗透到软件开发的每一个角落。你可以在 Cursor 里让 AI 写代码，在 ChatGPT 里让它写周报，在 Copilot 里让它补全函数------这些都很方便，但也仅止于此。

你有没有想过一个问题：为什么每次都要你来"问"它？

你问一句，它答一句。你再问一句，它再答一句。你永远是那个发令的人，它永远是那个等待的人。这种"一问一答"的模式，本质上和你十年前用 Google 搜索没有区别------只不过搜索引擎返回的是链接，ChatGPT 返回的是自然语言。

但真正的生产力提升，不应该只是"更聪明的搜索"。真正的突破在于：你告诉它目标，它自己想办法完成。 它会自己拆解任务、自己调用工具、自己检查结果、自己修正错误------你在旁边喝咖啡，它把活干完告诉你。

这就是 Loop Engineer 要做的事。

本文作为专栏开篇，将带你纵览 AI 应用开发范式的四次关键进化：从 Prompt Engineer 到 Context Engineer，再到 Harness Engineer，最终抵达 Loop Engineer。理解了这条演进路线，你就理解了整个专栏的"灵魂"。

一、第一阶段：Prompt Engineer ------ 让模型"听懂人话"

1.1 Prompt Engineer 在做什么？

Prompt Engineer 的核心工作是：设计输入文本，引导模型产出期望的输出。

这个阶段的关键技术包括：

  • Few-shot Prompting：给模型几个范例，让它照猫画虎。比如给两个"中文→英文翻译"的例子，第三个它就会自动翻译。
  • Chain of Thought（CoT）：在 Prompt 中加上"让我们一步一步思考"，模型就会把推理过程展开，显著提升数学和逻辑题的准确率。
  • 结构化输出：要求模型返回 JSON、Markdown 表格等固定格式，方便下游程序解析。

举个经典例子------用 CoT 让模型做数学题：

text 复制代码 
# Prompt
问：小明有5个苹果，给了小红2个，又买了3个，他现在有几个苹果？
让我们一步一步思考：
1. 小明最初有5个苹果
2. 他给了小红2个，还剩 5-2=3 个
3. 他又买了3个，现在有 3+3=6 个
因此，小明现在有6个苹果。

问：一个水池有两个进水管，A管单独注满需要3小时，B管单独注满需要6小时。
如果两个管子一起开，需要多少小时注满？

模型会模仿上面的推理模式，一步步算出答案。

1.2 Prompt Engineer 的天花板

Prompt Engineer 确实有用------但它的天花板也非常明显：

局限 说明
无状态 每次对话都是"失忆"的。你问完一个问题，下次再问时它完全不记得你是谁。
无工具 模型只能基于训练数据回答，不能查数据库、不能调 API、不能读文件。
无循环 模型给你一个答案就结束了。如果答案是错的，它不会自己发现并修正。
被动响应 你不问，它不动。它永远不会主动告诉你"数据库挂了"或者"股价跌了"。

一句话总结 Prompt Engineer：你让模型变聪明了，但它还是一条"一次性的问答管道"。

二、第二阶段：Context Engineer ------ 给 AI 装上"记忆"

2.1 为什么要管上下文？

Prompt Engineer 的最大痛点是"失忆"。你每次跟 ChatGPT 聊天，它都在一个全新的"世界"里------除非你把历史对话重新塞回去。

Context Engineer 要解决的核心问题是：如何让 AI 在跨会话、跨时间、跨场景的情况下，记住该记住的信息。

2.2 三大核心技术

① 上下文窗口管理

模型一次能"看"的 Token 数是有限的（早期 GPT-4 是 8K，后来的版本扩展到 128K 甚至更多）。Context Engineer 的第一个任务就是：在有限的窗口里装下最重要的信息。

常见策略包括：

  • 滑动窗口：只保留最近 N 轮对话，旧的丢掉。
  • 摘要压缩：对历史对话做摘要，用 200 Token 的摘要代替 2000 Token 的原文。
  • 分层存储：近期对话保留原文，中期对话保留摘要，远期对话只保留关键事实。

② RAG（检索增强生成）

与其把所有知识塞进 Prompt，不如让模型"遇到问题再去查"。这就是 RAG 的核心思路：

复制代码 
用户提问 → 向量检索相关文档 → 将文档片段注入 Prompt → 模型生成答案

比如你有一个 500 页的产品手册，用户问"如何配置 HTTPS？"------系统会先用向量搜索找到手册中关于 HTTPS 的段落，把这些段落作为"参考资料"一起发给模型。模型既不需要背下整本手册，又能给出精准的答案。

③ 记忆摘要与向量数据库

除了"临时查资料"，AI 还需要"长期记忆"------比如记住用户的偏好、历史对话中的重要信息。这通常通过向量数据库（如 Pinecone、Milvus、Chroma）来实现：

复制代码 
每次对话结束 → 提取关键信息 → 向量化 → 存入向量数据库
下次对话开始 → 根据当前话题检索相关记忆 → 注入 Prompt

2.3 Context Engineer 的天花板

有了记忆，模型确实更"懂你"了。但它依然有一个致命局限：

它有记忆，但没有手脚。

它可以记住你上个月说过你喜欢蓝色，但它不能帮你把网站的主题色改成蓝色。它可以检索到"如何部署 Docker"的文档，但它不能帮你执行 docker-compose up。

三、第三阶段：Harness Engineer ------ 给 AI 装上"手脚"

3.1 从"说"到"做"

Harness Engineer 的核心突破是：让模型不仅能回答问题，还能操作外部世界。

这依赖于一项关键技术------Function Calling（函数调用）：

复制代码 
用户："帮我查一下今天北京的天气"

模型思考：我需要调用天气API
模型输出：{"function": "get_weather", "parameters": {"city": "北京", "date": "2026-06-27"}}

系统执行：调用真实的天气API，拿到结果 {"temperature": 35, "weather": "晴"}

模型接收结果："今天北京天气晴朗，气温35°C，建议注意防暑。"

整个过程模型并没有"真的"去查天气------它只是输出了一段结构化的 JSON，告诉系统"我需要调用这个函数"。系统真正执行了 API 调用，把结果还给模型，模型再根据结果生成自然语言回复。

3.2 工具编排：从单个 API 到工作流

单个 Function Calling 只是起点。Harness Engineer 真正的威力在于编排多个工具：

复制代码 
"帮我分析上个月的销售数据，生成一份报告，发到我的邮箱"

步骤1：调用数据库API → 查询销售数据
步骤2：调用Python解释器 → 用pandas做数据分析
步骤3：调用图表API → 生成可视化图表
步骤4：调用LLM → 撰写分析报告
步骤5：调用邮件API → 发送报告

这就是 Harness（编排）的含义：像指挥家一样，协调多个工具/模型在正确的时机执行正确的任务。

目前主流的编排框架包括 LangChain、LangGraph、AutoGen、CrewAI 等，它们提供了：

  • 工具注册与 Schema 生成
  • 步骤间的依赖管理与数据传递
  • 条件分支与并行执行
  • 错误处理与重试

3.3 Harness Engineer 的天花板

编排让 AI 能干很多事了，但它仍然有一个关键缺陷：

它按照你预设的流程执行，不会自己判断"这条路走不通，我得换一条"。

比如你设计了一个"查天气→推荐穿衣"的流程，某一天天气 API 挂了，整个流程就卡住了。模型不会自己决定"天气 API 不可用，我换个数据源试试"------因为流程是你写死的。

四、第四阶段：Loop Engineer ------ 让 AI 进入自主循环

4.1 什么是 Loop？

Loop Engineer 的核心思想是：模型不只是执行你的指令，它会在执行过程中观察结果、自我评估、调整策略，形成一个自主的"感知-决策-行动"闭环。

复制代码 
┌──────────────────────────────────────────────────┐
│                   AI 自主循环                      │
│                                                   │
│   ┌──────────┐     ┌──────────┐     ┌──────────┐ │
│   │  观察     │ ←→  │  思考     │ ←→  │  行动     │ │
│   │ Observe  │     │  Think   │     │   Act    │ │
│   └──────────┘     └──────────┘     └──────────┘ │
│        ↑                                 │        │
│        └──────── 反馈（Feedback）←────────┘        │
│                                                   │
│   "结果对吗？不对就重来"                               │
└──────────────────────────────────────────────────┘

一个经典的 Loop 流程是这样的：

复制代码 
第1轮：
  思考："我需要查天气，调用 get_weather API"
  行动：调用 get_weather("北京")
  观察：API 返回了 500 错误
  评估："API 调用失败了，可能是参数问题，也可能是服务挂了"

第2轮：
  思考："先检查参数是否正确，再用备用 API 试一下"
  行动：调用 backup_weather_api("北京")
  观察：返回 {"temperature": 35, "weather": "晴"}
  评估："数据拿到了，可以回复用户了"

第3轮：
  行动：生成回复 "今天北京晴，35°C..."
  观察：回复已生成
  评估："任务完成"

4.2 Loop Engineer vs 前三阶段的本质区别

维度 Prompt Engineer Context Engineer Harness Engineer Loop Engineer
记忆 ❌ 无 ✅ 有 ✅ 有 ✅ 有
工具 ❌ 无 ❌ 无 ✅ 有 ✅ 有
流程编排 ❌ 无 ❌ 无 ✅ 预设流程 ✅ 自主决策流程
自我纠错 ❌ 无 ❌ 无 ❌ 无 ✅ 有
循环迭代 ❌ 无 ❌ 无 ❌ 无 ✅ 有

Loop Engineer 不是前三者的替代，而是它们的叠加与升级 。一个完整的 Loop 系统需要：记忆（Context）、工具（Harness）、再加上自主决策和自我纠错的能力。

4.3 Loop 的经典模式

在实际工程中，有几种已经被验证的 Loop 模式：

① ReAct（Reasoning + Acting）

推理和行动交替进行。模型先思考下一步该做什么，然后执行，观察结果，再思考下一步。这是最基础的 Agent 循环模式，也是本专栏第6篇要手写实现的内容。

② Reflexion（反思模式）

在 ReAct 的基础上增加"反思"环节。任务完成后，模型回顾整个过程：哪里做得好？哪里可以改进？把经验教训存入长期记忆，下次遇到类似任务时直接调用。

③ Self-Refine（自我精炼）

模型先生成一个初稿，然后自己当"审稿人"------检查、打分、提出修改意见，再根据意见修改。这个过程可以循环多次，直到质量达标。

这些模式将在本专栏的实战案例中逐一实现。

五、本专栏的路线图

理解了四次进化，你就能看懂本专栏的整体设计：

部分 篇目 内容
第一部分：引子 第1-5篇 概念演进全景，帮你建立完整的认知框架
第二部分：基础篇 第6-15篇 手写 ReAct 循环、状态管理、终止策略、错误处理、工具集成、反馈回路、可观测性、人机协同、安全护栏、框架选型
第三部分：实战案例篇 第16-46篇 12个完整案例：自动写测试、写小说、发公众号、做数据报告、代码审查、翻译、会议纪要、智能客服、简历筛选、研究助手、PPT生成、Web爬虫
第四部分：高级主题 第47-51篇 多Agent协作、评估体系、性能调优、生产部署、职业发展

每一篇都不是"读读就好"的理论文章，而是可以跑起来的代码。

六、谁适合读这个专栏？

  • 后端/全栈工程师：你已经会用 ChatGPT/Cursor，想把 AI 能力嵌入到你的系统里，让它自己干活。
  • AI 产品经理/技术管理者：你想理解 AI Agent 的技术边界，做出合理的架构决策。
  • 自动化爱好者：你对"让程序自动干活"有天然的痴迷，n8n、Zapier 已经满足不了你了。
  • 准备面试/跳槽的开发者：2026年的技术面试，AI Agent 已经是高频考点。

前置要求：会用终端，会写 Python（能看懂就行，不需要精通），对大模型有基本使用经验。

总结

从 Prompt 到 Loop，AI 应用开发范式经历了四次关键进化：

  1. Prompt Engineer 让模型"听懂人话"，但它是无状态、无工具、无循环的。
  2. Context Engineer 给模型装上了"记忆"，但它仍然只会说不会做。
  3. Harness Engineer 给模型装上了"手脚"，但它只能按预设流程执行。
  4. Loop Engineer 让模型具备了"自主决策和自我纠错"的能力，真正形成了"感知-决策-行动"的闭环。

下一篇，我们将深入 Prompt Engineer 的细节------剖析 Few-shot、CoT、结构化提示等核心技巧，同时揭示其无法突破的"三重天花板"。理解了它的局限，你才能理解为什么我们必须继续向前走。

热门推荐
012026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf022026年6月AI大模型全景报告：GPT-5.6、Claude Opus 4.8、Gemini 3.5，中美AI三足鼎立谁主沉浮？032026年6月AI行业全景：从百模大战到Agent元年，这30天发生了什么？04【AI】2026 年具身智能模型和世界模型总结05Trae国际版与国内版深度测评：AI原生IDE的双生花06Claude Code、Codex、Cursor三分天下：2026年AI编程Agent生态全景剖析07GitHub 镜像站点08飞书长连接_事件订阅（接收消息，审批任务状态变更）092026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？102026年AI架构实战：彻底解决OpenAI接口超时与封号，Python调用GPT-5.2/Sora2企业级架构详解（附源码+压测报告）