1. 先别被新词绕晕Prompt Engineering 没死只是换了个战场如果你最近在关注 AI 应用开发大概率被“AI Agent”、“工作流”、“循环工程”这些词刷屏了。很多人开始讨论“Prompt Engineering提示词工程是不是过时了”好像单靠写提示词已经不够用了。我的看法很直接Prompt Engineering 不仅没死反而成了更底层、更关键的基建。它从过去“用户对着聊天框写指令”的单一场景进化成了驱动 AI Agent 和工作流自动化的核心逻辑单元。所谓的“已死”只是因为它不再是一个孤立的技巧而是被系统性地工程化了。简单来说早期的 Prompt Engineering 像是教一个人完成一项具体任务比如“写一首关于春天的诗”。而现在我们要用 Prompt 来设计和指挥一个团队AI Agent并定义这个团队处理复杂任务的标准化流程工作流甚至让这个流程能自动循环、自我优化。这就是“循环工程”概念出现的背景——它关注的是如何让多个提示词或 AI 调用像齿轮一样咬合持续运转。所以这篇文章不是要比较哪个词更高级而是帮你理清这四者的关系Prompt Engineering提示词工程是砖块是原子能力。负责让单次 AI 调用输出稳定、可靠的结果。AI Agent智能体是具备特定角色和能力的“员工”。它内部封装了提示词、工具调用如搜索、写代码、查数据库和记忆上下文等。工作流Workflow是生产线或审批流程。它定义了多个步骤可能涉及多个 Agent 或工具的执行顺序、条件分支和数据处理逻辑。循环工程Cyclical Engineering是让这条生产线能自动重启、自我迭代的机制。比如一个分析报告生成工作流能自动检查数据更新触发新一轮分析。接下来我会用一个实际的场景带你从一块砖Prompt开始搭建一个能自动运转的智能系统讲透这背后的实操逻辑。2. 从“一块砖”到“一个员工”Prompt 如何进化成 Agent很多人觉得写 Prompt 就是“和 AI 聊天”但在工程化视角下一次有效的 Prompt 调用必须追求确定性。这恰恰是构建更复杂系统的基础。2.1 工程化的 Prompt要的是稳定输出不是惊喜假设我们需要 AI 从一段用户反馈中提取产品名称和问题类型。一个糟糕的 Prompt 是“看看这段反馈说了啥”——输出完全随机。一个工程化的 Prompt 会这样设计你是一个专业的客服数据分析助手。请严格按照以下要求处理用户反馈 **输入** {user_feedback} **处理规则** 1. 从反馈中提取提到的**产品名称**。如果未明确提及则输出“未知”。 2. 判断问题类型必须是以下类别之一[功能故障, 体验建议, 价格疑问, 售后咨询, 其他]。 3. 以 JSON 格式输出且只输出 JSON不要有任何额外解释。 **输出格式示例** { product: 智能音箱X1, issue_type: 功能故障 }这个 Prompt 体现了几个关键工程思想角色定义明确了 AI 的职能边界客服数据分析。结构化输入预留了{user_feedback}这样的变量插槽便于程序化调用。明确规则与枚举限制了输出范围减少了歧义。严格输出格式要求 JSON方便下游代码直接解析。实测经验在批量处理数据时这种格式严格的 Prompt 成功率远高于开放式提问。我通常会先用几十条样本跑一遍统计 JSON 解析成功率如果低于 95%就需要回头优化 Prompt 的指令或格式约束而不是去调模型参数。2.2 Agent给“员工”配上工具包和备忘录单个 Prompt 能力再强也只能完成一步。当任务变复杂比如“分析反馈如果是功能故障就去查知识库找解决方案然后生成一封回复草稿”就需要 AI Agent。一个典型的 AI Agent例如基于 LangChain、Dify、Coze 等框架构建包含三个核心部分规划Planning理解复杂目标拆解成子任务。这部分靠的是更高级的“规划型” Prompt。工具使用Tool Use可以调用外部能力如计算器、搜索引擎、数据库、API。这是 Prompt Engineering 的延伸Prompt 用于正确描述工具的功能和调用方式。记忆Memory保存对话历史、上下文信息保证在长流程中不迷失。这涉及到如何用 Prompt 有效地总结和提取记忆关键点。搭建一个查天气并建议穿着的 Agent其内部逻辑链可能是规划 Prompt“用户想知道北京今天的天气并得到穿衣建议。你需要先获取天气再分析并给出建议。”工具调用 Prompt对天气 API“调用get_weather工具参数为city北京。”工具调用 Prompt对分析模块“当前天气数据为{weather_data}。请根据温度、湿度和天气现象生成简洁的穿衣建议。输出格式建议...”记忆将用户查询“北京天气”和最终建议存入短期记忆以便后续对话能关联。避坑提示新手搭建 Agent 最容易犯的错误是把所有逻辑都堆在一个巨型 Prompt 里。正确做法是“分而治之”用多个专注的小 Prompt 分别负责规划、工具选择、参数生成、结果总结。这样每个模块都更容易调试和优化。当 Agent 行为异常时首先检查的是各个步骤的输入输出而不是去修改那个庞大的主 Prompt。3. 串联与协作用工作流编排多个 Agent单个 Agent 可以处理一条任务线。但当业务逻辑涉及多步骤、多分支、多人或多种 AI协同时就需要工作流Workflow来编排。工作流工具如 n8n、Dify 工作流、Coze 工作流、Flowable、Camunda本质上是一个可视化的逻辑编排器。它定义了节点Node每个节点是一个操作单元可以是一个 AI Agent 调用、一个数据库查询、一个条件判断、一个代码脚本。连接线Edge定义了节点之间数据流动的方向和条件。上下文Context在整个流程中传递的数据。3.1 一个内容审核工作流案例假设我们要自动化处理用户生成的图片内容节点1触发监听文件上传事件。节点2Agent A图片理解调用多模态 AIPrompt 为“描述这张图片的主要内容并判断是否包含 NSFW不适宜在工作场所浏览内容。输出 JSON{“description”: “...”, “is_nsfw”: true/false}。”节点3条件分支如果is_nsfw为true则流向节点4否则流向节点5。节点4动作将图片移至隔离区并发送通知给管理员。节点5Agent B标签生成调用另一个 Prompt“根据图片描述{description}生成最多5个内容标签。输出逗号分隔的字符串。”节点6存储将图片元信息路径、描述、标签存入数据库。在这个工作流中Prompt Engineering 体现在哪里节点2的 Prompt 必须输出结构化的、布尔值的is_nsfw因为下游的条件分支节点依赖这个字段做判断。如果输出是模糊的“可能包含”工作流就会失败。节点5的 Prompt 接收了上游节点2的输出{description}作为变量这要求节点2的输出格式必须稳定。整个工作流的可靠性取决于每个 AI 节点 Prompt 的输出稳定性。实操要点搭建工作流时不要急于连接所有节点。应该逐个节点进行单元测试。先用一份标准输入数据手动运行每个 AI 节点确认其输出格式和内容完全符合下游节点的输入要求。很多工作流卡住问题都出在数据接口即 Prompt 的输出格式对不上。3.2 低代码平台与编码的取舍现在很多平台如 Dify、Coze提供了低代码甚至无代码的工作流搭建界面这大大降低了入门门槛。但你需要了解其边界优点快速原型验证可视化调试内置常用 AI 模型和工具。局限复杂业务逻辑、自定义数据处理、高性能批量处理可能受限。对于需要深度定制、与企业内部系统集成、或处理海量数据的场景你可能仍需回归“编码”方式使用 LangChain、AutoGen 等框架或直接用 SDK 调用 API 来编排工作流。这时你对 Prompt 作为“函数调用参数”的理解就需要更深入。4. 让流程转起来循环工程的逻辑与实现工作流解决了“一次执行”的自动化。而“循环工程”关注的是如何让这个流程能够持续、自动地重复执行并在循环中引入优化。这才是实现真正“自动化”的最后一公里。循环不仅仅是“定时触发”它包含更丰富的模式4.1 循环的常见模式定时/事件驱动循环最简单的一种。例如每天凌晨 2 点自动运行数据报表生成工作流每当客服系统有新工单就触发一个分析 Agent。状态检查循环示例一个监控系统状态的工作流。Agent A 检查服务是否健康如果异常则触发 Agent B 执行重启脚本然后 Agent A 再次检查直到状态恢复为“健康”才退出循环。关键循环的退出条件必须由某个 Agent 或节点明确给出如status “healthy”否则会成为死循环。迭代优化循环人类在环示例一个自动生成营销文案的工作流。Agent 生成初稿 - 人工审核打分/修改 - 将评分和修改内容作为反馈输入给 Agent 用于调整生成策略微调 Prompt 或模型参数- 下一次生成时效果更好。这是“循环工程”的精华它形成了一个“执行-评估-学习”的闭环让系统能自我进化。多 Agent 协同循环示例模拟软件开发的“辩论”流程。Agent A程序员写一段代码。Agent B测试员尝试找出 bug 并提出修改意见。Agent A 根据意见修改代码。如此循环直到 Agent B 找不出更多问题或达到最大循环次数。关键需要设计好每个 Agent 的“辩论规则”Prompt以及循环终止的条件如达成共识、超时、轮次上限。4.2 实现循环的关键技术点在工程上实现这些循环需要注意以下几点状态持久化工作流每次执行可能是无状态的。要实现跨次循环的记忆如记住上次检查的结果、迭代的轮次必须借助外部存储——数据库、Redis 或简单的文件。工作流节点需要包含“读取状态”和“更新状态”的操作。循环控制必须在工作流中明确设计控制循环的节点。通常是“条件判断”节点它根据当前状态来自数据库或上一个 AI 节点的输出决定是跳回开头继续循环还是走向结束。防失控机制最大重试/循环次数任何循环都必须设置硬性上限防止因逻辑错误或外部服务异常导致无限循环。超时控制给每个循环周期设置总超时时间。异常熔断如果连续多次循环都因相同错误失败应触发熔断停止循环并报警。日志与可观测性循环系统更难调试。必须记录每一轮循环的输入、输出、关键状态和决策路径。当结果不如预期时你可以回溯查看是哪一轮、哪个 Agent 的判断出了问题。一个简单的状态检查循环伪代码逻辑max_retries 3 current_retry 0 target_status “healthy” while current_retry max_retries: # 调用状态检查 Agent status call_agent_check_status() if status target_status: log(“服务已恢复健康循环结束”) break else: log(f”第 {current_retry 1} 次检查状态异常: {status}“) # 调用修复 Agent call_agent_fix_issue() current_retry 1 time.sleep(60) # 等待一分钟再检查 if current_retry max_retries: log(“达到最大重试次数循环异常终止”) send_alert()5. 落地实战从零设计一个智能需求分析工作流让我们把以上所有概念串联起来设计一个相对完整的场景自动处理用户提交的、模糊的产品需求并输出结构化需求文档和初步原型图描述。目标用户输入一句话想法如“做一个能帮我自动总结论文的 App”系统经过多轮分析和细化输出一份结构化的 PRD产品需求文档和界面描述。5.1 第一步拆解任务与设计工作流蓝图我们不会一上来就写 Prompt 或画工作流。先拆解任务需求澄清与扩展把一句话想法扩展成多个具体问题。交互式问答可选人类在环如果需求不明确向用户提问。生成结构化 PRD包括用户画像、功能列表、非功能需求等。生成原型图描述根据 PRD描述主要界面的布局和元素。审查与修正检查 PRD 和原型描述的一致性。据此我们设计工作流节点节点1输入接收用户原始需求。节点2Agent A需求澄清器分析需求输出关键疑问点列表。如果疑问点多则触发“人工介入”分支否则直接使用原始需求。节点3人工介入节点可选将问题列表发给用户通过邮件、消息等等待用户回复并将回复内容合并回流程。节点4Agent BPRD 生成器基于澄清后的需求生成结构化 PRDMarkdown 格式。节点5Agent C原型描述生成器基于 PRD生成界面描述。节点6Agent D审查员对比 PRD 和原型描述检查一致性。如不一致则携带审查意见跳转回节点4PRD生成器形成一个小循环进行修正。直到审查通过或达到最大循环次数。节点7输出输出最终的 PRD 和原型描述。5.2 第二步为每个 Agent 编写工程化 Prompt这是最核心的步骤Prompt 的质量直接决定工作流能否跑通。Agent A需求澄清器的 Prompt 示例你是一个资深产品经理。你的任务是将用户模糊的需求转化为可执行的产品问题。 用户需求{user_input} 请按以下步骤思考并输出 1. 识别需求中的核心动词和宾语如“总结”、“论文”。 2. 列出至少3个需要澄清的关键问题以确保需求可执行。问题应围绕用户角色、使用场景、核心功能边界、输入输出格式展开。 3. 评估需求的明确程度。如果上述问题超过2个且答案对产品定义至关重要则设置 need_human_clarify 为 true否则为 false。 请严格按照以下 JSON 格式输出不要有任何额外文本 { “core_verb”: “...”, “core_object”: “...”, “clarification_questions”: [“问题1”, “问题2”, ...], “need_human_clarify”: true/false }为什么这样设计输出是结构化的 JSON且包含一个明确的布尔值need_human_clarify。下游的条件分支节点可以直接根据这个字段的值来决定工作流走向。Agent D审查员的 Prompt 示例你是一个严格的质量保证专员。请审查产品需求文档PRD和对应的原型图描述是否一致。 PRD {prd_content} 原型图描述 {prototype_description} 请重点检查 1. PRD 中提到的核心功能是否在原型描述中有对应的界面或交互体现 2. 原型描述中的主要界面元素是否在 PRD 中有功能定义或说明 输出 JSON { “is_consistent”: true/false, “inconsistency_details”: [“不一致点1描述”, “不一致点2描述”, ...], “suggestion”: “针对不一致点的修改建议如无则为空字符串” }为什么这样设计它不仅是判断“是否一致”还输出了具体的不一致细节和建议。当is_consistent为false时工作流可以带着inconsistency_details和suggestion跳回 PRD 生成器节点4让 Agent B 根据这些反馈进行修正。这就构成了一个迭代优化循环。5.3 第三步在工作流平台中实现与调试以 Dify 或 n8n 这类工具为例搭建画布依次拖入“HTTP 触发”、“AI Agent”、“条件判断”、“人工任务或延迟等待”、“AI Agent”、“循环节点”、“结束”等组件。配置 Agent 节点将写好的 Prompt 填入对应的 Agent 节点并正确设置输入变量如{user_input}来自触发节点{prd_content}来自上游节点。配置循环在“审查员”Agent 节点后连接一个“条件判断”节点。条件设置为{{检查上一个节点的输出 JSON 中的 is_consistent 字段}}是否为false。若为false则连接线指向“PRD 生成器”节点同时需要将inconsistency_details和suggestion作为新参数传入。若为true则连接线指向“输出”节点。设置循环上限在指向“PRD 生成器”的连接线上或使用专门的循环计数节点设置最大循环次数如3次防止 PRD 和原型描述永远无法一致导致死循环。单元测试与联调单节点测试给每个 AI Agent 节点输入模拟数据确保输出格式完全符合预期。链路测试用一份标准需求数据跑通整个正向流程无需人工介入和循环。分支与循环测试构造一份模糊的需求触发人工介入分支构造一份有矛盾的 PRD 和原型描述触发审查循环。5.4 第四步监控、优化与扩展系统跑起来后工作才刚开始监控日志查看每次运行的记录重点关注“审查循环”被触发的频率和原因。如果某个需求总是需要多次循环可能意味着 Agent B 或 Agent C 的 Prompt 需要优化。收集反馈将最终输出给真实用户或产品经理评价将“人工修改意见”作为训练数据反过来优化各个 Agent 的 Prompt。扩展能力未来可以接入更多工具比如在生成原型描述后接入一个文生图模型直接生成原型草图。在 PRD 生成后接入一个代码生成 Agent输出基础的项目脚手架代码。将整个工作流封装成一个 API供其他系统调用。6. 总结回归本质让 AI 可靠地为你工作回到最初的问题Prompt Engineering、AI Agent、工作流、循环工程到底是什么关系你可以这样理解Prompt Engineering是语法它定义了如何与 AI 模型进行有效、可靠的单次通信。AI Agent是单词或短语它封装了特定的“技能”由 Prompt 工具 记忆构成。工作流是句子和段落它通过语法数据接口将多个单词Agent组织起来表达一个完整的复杂意图。循环工程是文章的修辞手法如排比、递进让句子工作流能够重复、迭代、升华形成更强大的表达力自动化系统。Prompt Engineering 远未过时而是变得更加重要和基础。它的挑战从“如何让 ChatGPT 写出更好的诗”变成了“如何设计一套稳定、可组合、可循环的提示词系统来驱动一个自动化智能体团队”。对于想深入这个领域的开发者我的建议是先深耕 Prompt不要满足于聊天级别的 Prompt。练习写出能产生严格结构化输出、能处理边界情况、能充当可靠“函数”的 Prompt。这是所有高级应用的地基。再用框架组装 Agent选择一个你熟悉的框架LangChain, Dify, Coze 等亲手将几个这样的“Prompt 函数”与工具、记忆组装成一个能完成小任务的 Agent理解其内部的数据流。最后用工作流解决真实问题找一个你工作中重复性高、有明确步骤的业务痛点尝试用工作流将其自动化。从简单的线性流开始逐步加入条件分支最后再考虑循环逻辑。在这个过程中你会深刻体会到最耗费时间的往往不是学习新工具而是将模糊的业务逻辑精确地翻译成 AI 能稳定执行的指令序列Prompt和流程规则Workflow。这才是 AI 时代真正的“工程”能力。
1. 先别被新词绕晕Prompt Engineering 没死只是换了个战场如果你最近在关注 AI 应用开发大概率被“AI Agent”、“工作流”、“循环工程”这些词刷屏了。很多人开始讨论“Prompt Engineering提示词工程是不是过时了”好像单靠写提示词已经不够用了。我的看法很直接Prompt Engineering 不仅没死反而成了更底层、更关键的基建。它从过去“用户对着聊天框写指令”的单一场景进化成了驱动 AI Agent 和工作流自动化的核心逻辑单元。所谓的“已死”只是因为它不再是一个孤立的技巧而是被系统性地工程化了。简单来说早期的 Prompt Engineering 像是教一个人完成一项具体任务比如“写一首关于春天的诗”。而现在我们要用 Prompt 来设计和指挥一个团队AI Agent并定义这个团队处理复杂任务的标准化流程工作流甚至让这个流程能自动循环、自我优化。这就是“循环工程”概念出现的背景——它关注的是如何让多个提示词或 AI 调用像齿轮一样咬合持续运转。所以这篇文章不是要比较哪个词更高级而是帮你理清这四者的关系Prompt Engineering提示词工程是砖块是原子能力。负责让单次 AI 调用输出稳定、可靠的结果。AI Agent智能体是具备特定角色和能力的“员工”。它内部封装了提示词、工具调用如搜索、写代码、查数据库和记忆上下文等。工作流Workflow是生产线或审批流程。它定义了多个步骤可能涉及多个 Agent 或工具的执行顺序、条件分支和数据处理逻辑。循环工程Cyclical Engineering是让这条生产线能自动重启、自我迭代的机制。比如一个分析报告生成工作流能自动检查数据更新触发新一轮分析。接下来我会用一个实际的场景带你从一块砖Prompt开始搭建一个能自动运转的智能系统讲透这背后的实操逻辑。2. 从“一块砖”到“一个员工”Prompt 如何进化成 Agent很多人觉得写 Prompt 就是“和 AI 聊天”但在工程化视角下一次有效的 Prompt 调用必须追求确定性。这恰恰是构建更复杂系统的基础。2.1 工程化的 Prompt要的是稳定输出不是惊喜假设我们需要 AI 从一段用户反馈中提取产品名称和问题类型。一个糟糕的 Prompt 是“看看这段反馈说了啥”——输出完全随机。一个工程化的 Prompt 会这样设计你是一个专业的客服数据分析助手。请严格按照以下要求处理用户反馈 **输入** {user_feedback} **处理规则** 1. 从反馈中提取提到的**产品名称**。如果未明确提及则输出“未知”。 2. 判断问题类型必须是以下类别之一[功能故障, 体验建议, 价格疑问, 售后咨询, 其他]。 3. 以 JSON 格式输出且只输出 JSON不要有任何额外解释。 **输出格式示例** { product: 智能音箱X1, issue_type: 功能故障 }这个 Prompt 体现了几个关键工程思想角色定义明确了 AI 的职能边界客服数据分析。结构化输入预留了{user_feedback}这样的变量插槽便于程序化调用。明确规则与枚举限制了输出范围减少了歧义。严格输出格式要求 JSON方便下游代码直接解析。实测经验在批量处理数据时这种格式严格的 Prompt 成功率远高于开放式提问。我通常会先用几十条样本跑一遍统计 JSON 解析成功率如果低于 95%就需要回头优化 Prompt 的指令或格式约束而不是去调模型参数。2.2 Agent给“员工”配上工具包和备忘录单个 Prompt 能力再强也只能完成一步。当任务变复杂比如“分析反馈如果是功能故障就去查知识库找解决方案然后生成一封回复草稿”就需要 AI Agent。一个典型的 AI Agent例如基于 LangChain、Dify、Coze 等框架构建包含三个核心部分规划Planning理解复杂目标拆解成子任务。这部分靠的是更高级的“规划型” Prompt。工具使用Tool Use可以调用外部能力如计算器、搜索引擎、数据库、API。这是 Prompt Engineering 的延伸Prompt 用于正确描述工具的功能和调用方式。记忆Memory保存对话历史、上下文信息保证在长流程中不迷失。这涉及到如何用 Prompt 有效地总结和提取记忆关键点。搭建一个查天气并建议穿着的 Agent其内部逻辑链可能是规划 Prompt“用户想知道北京今天的天气并得到穿衣建议。你需要先获取天气再分析并给出建议。”工具调用 Prompt对天气 API“调用get_weather工具参数为city北京。”工具调用 Prompt对分析模块“当前天气数据为{weather_data}。请根据温度、湿度和天气现象生成简洁的穿衣建议。输出格式建议...”记忆将用户查询“北京天气”和最终建议存入短期记忆以便后续对话能关联。避坑提示新手搭建 Agent 最容易犯的错误是把所有逻辑都堆在一个巨型 Prompt 里。正确做法是“分而治之”用多个专注的小 Prompt 分别负责规划、工具选择、参数生成、结果总结。这样每个模块都更容易调试和优化。当 Agent 行为异常时首先检查的是各个步骤的输入输出而不是去修改那个庞大的主 Prompt。3. 串联与协作用工作流编排多个 Agent单个 Agent 可以处理一条任务线。但当业务逻辑涉及多步骤、多分支、多人或多种 AI协同时就需要工作流Workflow来编排。工作流工具如 n8n、Dify 工作流、Coze 工作流、Flowable、Camunda本质上是一个可视化的逻辑编排器。它定义了节点Node每个节点是一个操作单元可以是一个 AI Agent 调用、一个数据库查询、一个条件判断、一个代码脚本。连接线Edge定义了节点之间数据流动的方向和条件。上下文Context在整个流程中传递的数据。3.1 一个内容审核工作流案例假设我们要自动化处理用户生成的图片内容节点1触发监听文件上传事件。节点2Agent A图片理解调用多模态 AIPrompt 为“描述这张图片的主要内容并判断是否包含 NSFW不适宜在工作场所浏览内容。输出 JSON{“description”: “...”, “is_nsfw”: true/false}。”节点3条件分支如果is_nsfw为true则流向节点4否则流向节点5。节点4动作将图片移至隔离区并发送通知给管理员。节点5Agent B标签生成调用另一个 Prompt“根据图片描述{description}生成最多5个内容标签。输出逗号分隔的字符串。”节点6存储将图片元信息路径、描述、标签存入数据库。在这个工作流中Prompt Engineering 体现在哪里节点2的 Prompt 必须输出结构化的、布尔值的is_nsfw因为下游的条件分支节点依赖这个字段做判断。如果输出是模糊的“可能包含”工作流就会失败。节点5的 Prompt 接收了上游节点2的输出{description}作为变量这要求节点2的输出格式必须稳定。整个工作流的可靠性取决于每个 AI 节点 Prompt 的输出稳定性。实操要点搭建工作流时不要急于连接所有节点。应该逐个节点进行单元测试。先用一份标准输入数据手动运行每个 AI 节点确认其输出格式和内容完全符合下游节点的输入要求。很多工作流卡住问题都出在数据接口即 Prompt 的输出格式对不上。3.2 低代码平台与编码的取舍现在很多平台如 Dify、Coze提供了低代码甚至无代码的工作流搭建界面这大大降低了入门门槛。但你需要了解其边界优点快速原型验证可视化调试内置常用 AI 模型和工具。局限复杂业务逻辑、自定义数据处理、高性能批量处理可能受限。对于需要深度定制、与企业内部系统集成、或处理海量数据的场景你可能仍需回归“编码”方式使用 LangChain、AutoGen 等框架或直接用 SDK 调用 API 来编排工作流。这时你对 Prompt 作为“函数调用参数”的理解就需要更深入。4. 让流程转起来循环工程的逻辑与实现工作流解决了“一次执行”的自动化。而“循环工程”关注的是如何让这个流程能够持续、自动地重复执行并在循环中引入优化。这才是实现真正“自动化”的最后一公里。循环不仅仅是“定时触发”它包含更丰富的模式4.1 循环的常见模式定时/事件驱动循环最简单的一种。例如每天凌晨 2 点自动运行数据报表生成工作流每当客服系统有新工单就触发一个分析 Agent。状态检查循环示例一个监控系统状态的工作流。Agent A 检查服务是否健康如果异常则触发 Agent B 执行重启脚本然后 Agent A 再次检查直到状态恢复为“健康”才退出循环。关键循环的退出条件必须由某个 Agent 或节点明确给出如status “healthy”否则会成为死循环。迭代优化循环人类在环示例一个自动生成营销文案的工作流。Agent 生成初稿 - 人工审核打分/修改 - 将评分和修改内容作为反馈输入给 Agent 用于调整生成策略微调 Prompt 或模型参数- 下一次生成时效果更好。这是“循环工程”的精华它形成了一个“执行-评估-学习”的闭环让系统能自我进化。多 Agent 协同循环示例模拟软件开发的“辩论”流程。Agent A程序员写一段代码。Agent B测试员尝试找出 bug 并提出修改意见。Agent A 根据意见修改代码。如此循环直到 Agent B 找不出更多问题或达到最大循环次数。关键需要设计好每个 Agent 的“辩论规则”Prompt以及循环终止的条件如达成共识、超时、轮次上限。4.2 实现循环的关键技术点在工程上实现这些循环需要注意以下几点状态持久化工作流每次执行可能是无状态的。要实现跨次循环的记忆如记住上次检查的结果、迭代的轮次必须借助外部存储——数据库、Redis 或简单的文件。工作流节点需要包含“读取状态”和“更新状态”的操作。循环控制必须在工作流中明确设计控制循环的节点。通常是“条件判断”节点它根据当前状态来自数据库或上一个 AI 节点的输出决定是跳回开头继续循环还是走向结束。防失控机制最大重试/循环次数任何循环都必须设置硬性上限防止因逻辑错误或外部服务异常导致无限循环。超时控制给每个循环周期设置总超时时间。异常熔断如果连续多次循环都因相同错误失败应触发熔断停止循环并报警。日志与可观测性循环系统更难调试。必须记录每一轮循环的输入、输出、关键状态和决策路径。当结果不如预期时你可以回溯查看是哪一轮、哪个 Agent 的判断出了问题。一个简单的状态检查循环伪代码逻辑max_retries 3 current_retry 0 target_status “healthy” while current_retry max_retries: # 调用状态检查 Agent status call_agent_check_status() if status target_status: log(“服务已恢复健康循环结束”) break else: log(f”第 {current_retry 1} 次检查状态异常: {status}“) # 调用修复 Agent call_agent_fix_issue() current_retry 1 time.sleep(60) # 等待一分钟再检查 if current_retry max_retries: log(“达到最大重试次数循环异常终止”) send_alert()5. 落地实战从零设计一个智能需求分析工作流让我们把以上所有概念串联起来设计一个相对完整的场景自动处理用户提交的、模糊的产品需求并输出结构化需求文档和初步原型图描述。目标用户输入一句话想法如“做一个能帮我自动总结论文的 App”系统经过多轮分析和细化输出一份结构化的 PRD产品需求文档和界面描述。5.1 第一步拆解任务与设计工作流蓝图我们不会一上来就写 Prompt 或画工作流。先拆解任务需求澄清与扩展把一句话想法扩展成多个具体问题。交互式问答可选人类在环如果需求不明确向用户提问。生成结构化 PRD包括用户画像、功能列表、非功能需求等。生成原型图描述根据 PRD描述主要界面的布局和元素。审查与修正检查 PRD 和原型描述的一致性。据此我们设计工作流节点节点1输入接收用户原始需求。节点2Agent A需求澄清器分析需求输出关键疑问点列表。如果疑问点多则触发“人工介入”分支否则直接使用原始需求。节点3人工介入节点可选将问题列表发给用户通过邮件、消息等等待用户回复并将回复内容合并回流程。节点4Agent BPRD 生成器基于澄清后的需求生成结构化 PRDMarkdown 格式。节点5Agent C原型描述生成器基于 PRD生成界面描述。节点6Agent D审查员对比 PRD 和原型描述检查一致性。如不一致则携带审查意见跳转回节点4PRD生成器形成一个小循环进行修正。直到审查通过或达到最大循环次数。节点7输出输出最终的 PRD 和原型描述。5.2 第二步为每个 Agent 编写工程化 Prompt这是最核心的步骤Prompt 的质量直接决定工作流能否跑通。Agent A需求澄清器的 Prompt 示例你是一个资深产品经理。你的任务是将用户模糊的需求转化为可执行的产品问题。 用户需求{user_input} 请按以下步骤思考并输出 1. 识别需求中的核心动词和宾语如“总结”、“论文”。 2. 列出至少3个需要澄清的关键问题以确保需求可执行。问题应围绕用户角色、使用场景、核心功能边界、输入输出格式展开。 3. 评估需求的明确程度。如果上述问题超过2个且答案对产品定义至关重要则设置 need_human_clarify 为 true否则为 false。 请严格按照以下 JSON 格式输出不要有任何额外文本 { “core_verb”: “...”, “core_object”: “...”, “clarification_questions”: [“问题1”, “问题2”, ...], “need_human_clarify”: true/false }为什么这样设计输出是结构化的 JSON且包含一个明确的布尔值need_human_clarify。下游的条件分支节点可以直接根据这个字段的值来决定工作流走向。Agent D审查员的 Prompt 示例你是一个严格的质量保证专员。请审查产品需求文档PRD和对应的原型图描述是否一致。 PRD {prd_content} 原型图描述 {prototype_description} 请重点检查 1. PRD 中提到的核心功能是否在原型描述中有对应的界面或交互体现 2. 原型描述中的主要界面元素是否在 PRD 中有功能定义或说明 输出 JSON { “is_consistent”: true/false, “inconsistency_details”: [“不一致点1描述”, “不一致点2描述”, ...], “suggestion”: “针对不一致点的修改建议如无则为空字符串” }为什么这样设计它不仅是判断“是否一致”还输出了具体的不一致细节和建议。当is_consistent为false时工作流可以带着inconsistency_details和suggestion跳回 PRD 生成器节点4让 Agent B 根据这些反馈进行修正。这就构成了一个迭代优化循环。5.3 第三步在工作流平台中实现与调试以 Dify 或 n8n 这类工具为例搭建画布依次拖入“HTTP 触发”、“AI Agent”、“条件判断”、“人工任务或延迟等待”、“AI Agent”、“循环节点”、“结束”等组件。配置 Agent 节点将写好的 Prompt 填入对应的 Agent 节点并正确设置输入变量如{user_input}来自触发节点{prd_content}来自上游节点。配置循环在“审查员”Agent 节点后连接一个“条件判断”节点。条件设置为{{检查上一个节点的输出 JSON 中的 is_consistent 字段}}是否为false。若为false则连接线指向“PRD 生成器”节点同时需要将inconsistency_details和suggestion作为新参数传入。若为true则连接线指向“输出”节点。设置循环上限在指向“PRD 生成器”的连接线上或使用专门的循环计数节点设置最大循环次数如3次防止 PRD 和原型描述永远无法一致导致死循环。单元测试与联调单节点测试给每个 AI Agent 节点输入模拟数据确保输出格式完全符合预期。链路测试用一份标准需求数据跑通整个正向流程无需人工介入和循环。分支与循环测试构造一份模糊的需求触发人工介入分支构造一份有矛盾的 PRD 和原型描述触发审查循环。5.4 第四步监控、优化与扩展系统跑起来后工作才刚开始监控日志查看每次运行的记录重点关注“审查循环”被触发的频率和原因。如果某个需求总是需要多次循环可能意味着 Agent B 或 Agent C 的 Prompt 需要优化。收集反馈将最终输出给真实用户或产品经理评价将“人工修改意见”作为训练数据反过来优化各个 Agent 的 Prompt。扩展能力未来可以接入更多工具比如在生成原型描述后接入一个文生图模型直接生成原型草图。在 PRD 生成后接入一个代码生成 Agent输出基础的项目脚手架代码。将整个工作流封装成一个 API供其他系统调用。6. 总结回归本质让 AI 可靠地为你工作回到最初的问题Prompt Engineering、AI Agent、工作流、循环工程到底是什么关系你可以这样理解Prompt Engineering是语法它定义了如何与 AI 模型进行有效、可靠的单次通信。AI Agent是单词或短语它封装了特定的“技能”由 Prompt 工具 记忆构成。工作流是句子和段落它通过语法数据接口将多个单词Agent组织起来表达一个完整的复杂意图。循环工程是文章的修辞手法如排比、递进让句子工作流能够重复、迭代、升华形成更强大的表达力自动化系统。Prompt Engineering 远未过时而是变得更加重要和基础。它的挑战从“如何让 ChatGPT 写出更好的诗”变成了“如何设计一套稳定、可组合、可循环的提示词系统来驱动一个自动化智能体团队”。对于想深入这个领域的开发者我的建议是先深耕 Prompt不要满足于聊天级别的 Prompt。练习写出能产生严格结构化输出、能处理边界情况、能充当可靠“函数”的 Prompt。这是所有高级应用的地基。再用框架组装 Agent选择一个你熟悉的框架LangChain, Dify, Coze 等亲手将几个这样的“Prompt 函数”与工具、记忆组装成一个能完成小任务的 Agent理解其内部的数据流。最后用工作流解决真实问题找一个你工作中重复性高、有明确步骤的业务痛点尝试用工作流将其自动化。从简单的线性流开始逐步加入条件分支最后再考虑循环逻辑。在这个过程中你会深刻体会到最耗费时间的往往不是学习新工具而是将模糊的业务逻辑精确地翻译成 AI 能稳定执行的指令序列Prompt和流程规则Workflow。这才是 AI 时代真正的“工程”能力。
