AI Agent 产品经理血泪史（二）-欲知方圆，则必规矩【Workflow篇】

血泪史系列开篇大受欢迎，感谢大家认可。不过基本也只能是忙里抽闲，断断续续写，很多时候写一段隔一段时间回来又忘了前面想写什么。好，咱们继续聊Agent产品经理的血泪史——这次的主题是Workflow。直接进入正题。

第一篇：AI Agent产品经理血泪史：一年来我摸过的那些石头【Tools篇】
第二篇：我们接着讲

，Agent 的核心。
第三篇：RAG - 大模型的第二大脑
第四篇：Multi Agent 会放在最后讲，具体何时还不知。

01 - Workflow的前身-集成平台

大模型带火了很多词，workflow就是其中之一。如果我说“集成平台”，可能知道的人就少很多。其实比较有名的大家可能见过，比如Zapier——OpenAI的御用集成平台，还有类似的Make，国内就是集简云，飞书的连接器等等。

以前的叫法叫集成平台，顾名思义就是把很多应用的能力/数据集合到平台上，然后再按一定的逻辑串起来，就成了一个能干活的串串（workflow大概就是这么来的）。为了更形象，从集简云截了个图。

这些串串里面基本就是按照固定的规则前后串起来，但规则非常死，基本就是 IF/ELSE。

直到大模型来了，事情开始变得有趣了。

大约一年零4个月前，为了自己看资讯方便，用GPT-3.5搭了一个自动化的博客。那时候没有Tools、没有Coze、也没有Workflow，硬是用Zapier搭建的。

做的事情其实很简单：从RSS上按照固定时间间隔抓取信息，根据定的标准评分，超过的就翻译发送到博客，没超过就扔掉。仔细看这个串串和上面的串串之间的差异，就是中间多了一个大模型节点。大模型能处理一些非结构化数据，代替IF/ELSE之外做判断。

02 - 无处不在的流程

我们不再赘述大模型为啥不能一次把活干好——毕竟你自己都做不到的事情，别老想着为难别人。

回溯我们对大模型认知的过程，不难发现流程的概念一直存在。

最早是COT——Chain of Thought，Let's think step by step。让大模型学会思考，再输出更符合预期的答案。虽然与传统的直进直出Prompt相比，COT能让模型带来更多思考（其实只是更多token自回归带来的准确性提升），但很多时候结果产出与人类预期还是有偏差，抽奖不可避免。

去年5月份的时候，在云中江树的LangGPT中第一次看到了workflow这个词。下面是他主页上的一个示例：

## Workflow
1. You will analysis the given the personal information.
2. Create a summary of my diet and exercise plan.
3. Create a detailed workout program for my exercise plan.
4. Create a detailed Meal Plan for my diet.
5. Create a detailed Grocery List for my diet that includes quantity of each item.
6. Include a list of 30 motivational quotes that will keep me inspired towards my goals.

这种通过Prompt描述流程的方式，虽然不能100%奏效，但在上下文不复杂、贪念不大的情况下，还是能work的。

不过，单次模型请求很难处理一件复杂的事情——比如1,2,3,4,5,6写了很多点，模型并不能很好地遵循。那怎么办？

03 - 软的不行就来硬的

拆！

如果单次请求里面不能很好地遵循并完成所有事情，那就拆出来，一步一步去做。比如用户表达了目标，让大模型根据这个目标拆分出step by step的子任务，再通过工程方式循环请求子任务（中间可能插入新任务），直到所有子任务执行完成。这就是去年轰动一时的AutoGPT（Planning and excute）。

但AutoGPT其实只是学术界的一种探索，很难落地。除了一些demo产品，只在实在智能的RPA上见过。原因非常多，之前的文章里提了很多次。这里只说几个最难解的：

1. 计划赶不上变化，提前规划的任务如何保证都能正确执行？
2. 大模型也不是全知全能，如何保证规划的任务就是对的？
3. 既然是工程化执行，何时进入循环、何时退出循环又是一个问题。

下面是当时在实在智能RPA Agent上的截图。有兴趣也可以自己去搜AgentGPT，自己跑几个case就知道了。

其实大家后来都有在解这些问题，只是思路、解法不太一样。比如OpenAI开始搞Tools，FastGPT搞了可视化的workflow编排，后面大家都意识到workflow是一个短期最优解，于是各家都开始做。

04 - 从自动编排到手动编排

上图分别是Coze和Dify的workflow可视化编排页面（框架：React Flow）。不得不说Coze的确不是最早做编排的，但集各家之所长，用户体验做得的确得人心。再回过头对比AutoGPT的实现，就能发现这个差异：AutoGPT的任务是大模型编排出来的——可以理解为

；而Workflow里面的子任务是我们人为编排的——就称为吧。

由此带来的优化也非常明显：

1. 在流程中加入人类Knowhow，补足模型知识的不足；
2. 专家测试试跑，减少生产环境中的反复无效反思，至少不会让用户觉得你的Agent真蠢；
3. 引入图的概念，灵活组织节点，连接各类工具（让你的Agent看起来很牛逼）。

加入图的概念之后，workflow的天花板就变得非常高了。因为可以在流程中任意增加节点，各种类型的节点，不仅能套工具，还能套其它Agent，也能写代码用硬逻辑处理，还能接大模型代替人类进行判断。能力的上限，很大概率就是你想象力的上限。灵活和可控，把Agent能力的天花板往上顶了一大截——这就是workflow的功劳。

之前评价一个Agent平台好不好用：1看基座模型的function calling能力，2看workflow的灵活性，3看平台创作者的workflow写得好不好。1和2看的是技术能力，其实也没啥门槛。

05 - 突破更多的灵活性

读到这里还有问题的同学，大概能猜到是什么样的。像Coze、Dify这样的平台，虽然带来了可视化workflow的便捷操作和LLMOps的基建支持，但还有很多想法实现不了，对吧？比如循环，再比如并行分支……这个时候建议开始写代码。

去年底Langchain就基于图的概念推出了全新的Agent框架Langgraph，很灵活，但仍有一些问题——Langchain上的问题同样被带到了Langgraph。对于只想简单入手写个Agent的，门槛略高。

相比之下，更推荐莫欣老师的Agently框架。客观公正地评价，写一次就会爱上那种感觉——只需要专注于构思Agent的实现，剩下的coding交给框架。附上官网和Langgraph的比较截图。

06 - 最后

做AI产品挺难的，大模型也没有那么神奇，祛魅的成本很高，不要轻易被自媒体蛊惑了。发Paper的那帮人，跟做产品的这帮人，要考虑的东西也不太一样。