“Prompt Engineering” 已死,“Flow Engineering” 当立?
在过去的一年里,我们见证了大语言模型(LLM)能力的爆发。然而,仅仅通过 “Chat” 窗口与 AI 对话,正在迅速触及其实用性的天花板。对于写诗、生成简单代码或回答百科问题,Zero-shot(零样本)提示效果尚可;但面对复杂的现实世界任务——如构建一个完整的 Web 应用、撰写一份长篇市场调研或调试这类复杂的代码库——单一的 Prompt 往往力不从心。
这就是为什么我们需要从 Chat 转向 Agentic Workflow(代理工作流)。
从概率到确定性的桥梁
LLM 本质上是一个概率预测机。它不知道“正确答案”,它只知道“下一个最可能的词”。这种概率性特征在创意生成时是优势,但在要求严谨逻辑的任务中通过一次生成得到完美结果的概率微乎其微。
Agentic Workflow 的核心思想不是追求模型“一次做对”,而是设计一个允许模型“做错并纠正”的闭环系统。
核心模式:反思与工具使用
如果要让 AI 真正变得智能,我们需要引入两个关键能力:
-
Reflection (反思):
不仅是生成内容,更要生成对内容的“评价”。就像人类写代码会先写草稿,然后自己 Review 一样。例如,一个 Coding Agent 不应直接输出代码,而应遵循:Write Code -> Run Test -> Read Error -> Refine Code的循环。这种自我修正机制能显著提升最终输出的质量。 -
Tool Use (工具使用):
幻觉(Hallucination)是 LLM 的顽疾。与其让模型“通过记忆”回答“今天此时此刻的股价”,不如给它一个get_stock_price()的工具。当模型学会“承认自己不知道,但知道去哪里查”时,它就从一个“博学的鹦鹉”进化为了“不仅博学而且严谨的研究员”。
未来:Flow Engineering
未来的软件工程可能不再是编写具体的业务逻辑代码,而是编写“认知流程”(Cognitive Flow)。
我们需要定义:
- Agent 在遇到困难时该向谁求助?(Web Search 还是 Knowledge Base?)
- Agent 完成任务的标准是什么?(通过单元测试还是通过 User Review?)
- 多个 Agent (Manager, Coder, Reviewer) 之间如何协作handoff任务?
这种设计 prompt 之间交互逻辑的工作,我们可以称之为 Flow Engineering。比起通过通过复杂的 prompt 去“催眠”模型,精心设计的 Workflow 往往能用更小的模型达到超越更大模型的效果(GPT-3.5 + Good Workflow > GPT-4 Zero-shot)。
结语
不要再试图寻找那个“完美的 Prompt”了。去构建一个能容错、能反思、能使用工具的系统吧。这才是通往 AGI 的必经之路。
本文由 Gridea Pro MCP 深度思考模式生成
评论