AI 工作流，选图形界面，还是命令行？

nkwshuyi

于 2024-07-09 15:14:47 发布

阅读量631

点赞数 18

文章标签：人工智能

本文链接：https://blog.csdn.net/nkwshuyi/article/details/140312138

版权

在知识星球上，星友「土豆君」提问：

非常感谢王老师今天的思路分享，我是一名独立开发者，本来我都觉得沉浸式翻译已经做的非常好了，没有什么机会，但看到王老师分享的三步翻译法让我觉得翻译其实还是可以优化，自己可以去尝试构建翻译产品。

另外借此感谢下王老师一直以来的分享，从学术的视角科普 AI 的最新进展，推荐的很多开源项目或应用自己是不太可能关注到的，因为自己关注的焦点都在应用端。

而通过王老师让我了解到一些东西，比如 fabric。我是最近通过 coze 才关注到 AI 工作流的，对这个非常感兴趣想尝试动手做一些有意思的小产品，主要也是看到 coze 构建的生态很强大，不仅能轻松构建工作流 (支持脚本 / 图片流 / 大模型 / 各种插件 / Agent 等)，而且有很多用户自发开发的 Agent、插件、工作流，使得普通用户可以直接用构建好的 Agent，非常方便。

前几天直播我也看了，看了两遍才明白提到的一些 AI 工作流产品，crewai、autogen、human-in-the-loop。我也从 fabric 看到一个多模态 Agent：PraisonAI。

但我只在最近用过 coze，上面那些产品不太了解，请问下王老师你能再写篇文章详细讲下工作流吗？目前的 coze 形态跟你提到的那些工作流产品有些什么不一样呢？

还有我个人想请教一个问题，作为个人开发者，只有时间没有什么其他资源，想要应用工作流去快速构建 AI 相关的产品，技术上应该采取什么样的工作流方式？

比如，通过脚本 + GPT API 就可以实现 AI 工作流的一些操作，只是脚本构建起来会稍微困难一点。

那如果引入 fabric，脚本 + fabric，好像文字处理确实会简单很多，但如果遇到图片处理、搜索处理，还是需要自己去解决这些图片 / 搜索脚本的问题，这里可能会复杂一些。

那如果我使用 coze api，通过 coze 工作流去构建我的 Agent，如果 coze 平台有图片处理、搜索处理相关的插件，那么构建就方便些，没有的情况就比较麻烦，而且依赖平台用户的插件，有不确定性。

那王老师直播提到的目前最新的几个工作流工具能轻松的解决我遇到的这个多模态分步骤处理的问题吗？以及最新的几个工作流工具有些什么用途？

或者说针对我想借助 AI 工作流构建新的小产品王老师有什么建议？

最后再感谢下王老师，关注公众号好久了，现在才加入进来😹。

我觉得星友的提问很详细认真，也很有代表性，所以我在这里把答案分享出来，希望对你也有帮助。

首先我要介绍一些背景信息。

星友提及的「王老师今天的思路分享」，指的是我这篇文章《如何用 AI 工作流实现高质量长文翻译？》。我在里面介绍了如何利用 AI 工作流，把一篇长技术文档，自动翻译成这个样子：

另外问题中提到的「前几天直播」，指的是我在上周在视频号做的直播《聊聊 AI 工作流 + 答疑》。我把其中讲解 AI 工作流的部分，给你展示在这里。

如果你想了解后续的答疑互动内容，请访问我的视频号-直播回放功能。

背景信息介绍完了，下面是我对星友问题的完整回答（有改动）：

Coze 和 Dify 代表了目前 AI 工作流中的图形界面类别。特点是上手简单直观，功能也很强大。尤其是 Dify 作为开源框架，个人用户可以免费本地部署用，后续升级成为团队和企业级产品也有路径。如果学习的话，推荐得到 AI 学习圈里快刀青衣和尹会生的相关视频教程。

而 fabric, general agent, phidata 等则是命令行形式的代表。缺点是需要你得掌握编程，才能把它的能力发挥出来。选哪一个路径，其实主要看每个人的情况与偏好。

让我选的话，目前我会选后者。为什么呢？

因为你是个开发者，开发别人不曾有的、或者是做得不够尽善尽美的功能，才是产品生存的必要条件。因此把别人现成的 DSL 模板搬过来用，与你的目标是不匹配的。

不管你是用图形界面，还是命令行，都需要学习成本。学会了之后，如果一切执行顺风顺水，那自然是图形界面显得更加和蔼可亲。但是一旦出现问题，才是真正的考验到来。

你想要了解错误的含义，你想要知道工作流能力的边界，你想把自己头脑中的新设计实现出来，却没有人提供现成的模板……

此时命令行有个好处，就凸显了出来——不管是 shell 命令还是 Python 代码，都是文本。而文本，对目前的大语言模型来说，就是能力范围之内的事情。

就拿我最近这篇 AI 工作流翻译文章为例，你以为我从头到尾自己写了 Python 代码来调用 fabric 工作流？当然不是。我几乎一直都是在用自然语言提要求，然后让 Claude 3.5 Sonnet 帮忙实现。

而因为是命令行，所以我跟 Claude 沟通起来就特别顺畅。尤其是 Claude 的 artifacts 和 project 功能，用起来太舒服了。

可如果我用的是 Dify 这样的图形交互界面，那么我需要如何给「大语言模型顾问」提供信息？

我觉得至少就得包括：

版本信息
错误提示
图形化的工作流样貌（因为你得让它明白哪一步出问题，这个其实不大好描述）
足够丰富的其他上下文

不仅如此，我还得考虑 Dify 目前已知的限制等因素…… 这些问题虽然大部分最终相信都能解决，但是很麻烦。

所以你会看到 Dify 的学习群里，大家问题五花八门。而对于 fabric 用户来说，我看到的绝大多数问题，都发生在一开始的安装和后续自定义 pattern 的更新配置上。至于执行流程的设定，那是要多流畅有多流畅。因为你会把注意力放在提示词撰写和流程调整这种真正有意义的事情上。

fabric 能否处理多模态？目前不行。但是这有什么关系呢？它自己的样例里面，yt 命令就能获得视频的脚本，让你看到工作流串接的能力。

另外谁说你在 Python 脚本里只能调用 fabric？你可以调用 general agent，用它来读取图片；你也可以调用 exa.ai ，用它来搜集资料；你还可以调用 phidata，让它呼叫一组 agents 组成 LLM OS 完成其中的某一个步骤，只要有足够的必要性……

这种组合，才是真正的灵活。你想到一个词儿了对吧？

没错，善用佳软张玉新老师提过的「重器轻用」。哈哈。

希望这个分享，对星友能有帮助，也希望你能从中获得一些收益。

祝 AI 工作流使用愉快！

点赞 +「在看」，转发给你身边有需要的朋友。收不到推送?那是因为你只订阅，却没有加星标。

欢迎订阅我的小报童付费专栏，每月更新不少于3篇文章。订阅一整年价格优惠。