随着AI的快速迭代，AI越来越多的被应用在我们的产品功能中。
今天主要分享一下，在面对一个新的AI需求时，我们是如何评估需要落地的技术方案的。
涉及如何确定需求是一个AI需求，如何确定是使用工作流还是智能体，又或者是多智能体协作。
让我们先来看看，我们的工具箱里，有哪些趁手家伙事：
-
传统工程逻辑：没有AI时，我们解决问题的基础。
-
大语言模型（LLM） ：直接调用，利用其理解、推理、生成能力。
-
工作流（Workflow） ：定义了明确的、可预测的执行步骤，AI在预设的步骤边界内工作。
-
智能体（Agent） ：由AI完全主导任务的规划、工具调用顺序和决策，具备高度灵活性。
-
多智能体协作（Multi-Agent） ：多个具有不同角色的智能体协同工作，解决极其复杂、无标准流程的问题。
第一个是传统的工程逻辑，没有AI的时候，我们的需求、功能都是用这个方案实现的
其他五个是我们可以使用的AI落地方案，并且这五个是随着业务复杂度的上升依次选择。
每个工具背后都有自己的适配逻辑，以及不同的资源消耗成本。AI工具越往后工作量、tokens消耗都是巨大的变化。
有时资源上的硬性要求（上线节奏、时间点、tokens开销等资源限制）也会限制我们的方案选择
以下两个指标，给大家做参考：
-
tokens消耗的硬性费用：Agent消耗的tokens是workflow的5-10倍，多智能体消耗的 Token 大约是单体的 10 到 15 倍。
-
开发周期：workflow 可以单周内可能完成，单Agent 通常要几周时间，多智能体根据复杂度可能需要1-N个月才能做完。
在我们要完成AI需求的时候，我们的首选落地方案一定要选择尽可能简单的解决方案。
咱们主打一个遵循奥卡姆剃刀原理，如无必要，勿增实体。
切记杀鸡不用牛刀。
判断需求是否为AI需求
当我们面对一个需求的时候，我们首先要判断这个需求是不是AI需求，只有AI需求我们才会动用我们工具箱里的AI工具。
那么什么是AI需求？
1. 能用AI，并且只能用AI的需求
只有当一个需求能用AI，并且只能用AI的时候，这才可以被称为AI需求。
为什么要有这个要求呢？
因为我们需要稳定性更好、时效性更高、成本更低的方案来实现我们的需求。
如果一个需求能用传统程序的编程方式来解决，那么它一定比AI的解决方案稳定性更好、时效性更高、成本更低。
我们看两个例子：
- 要求判断用户输入的语种是什么，中文、英文、韩语？
这个需求是AI需求么？
首先这个需求都可以用AI做。
但同时，这个需求也可以用程序通过·unicode`的编码范围也可以实现。
那么这个需求就不是一个AI需求，因为它不是能且只能用AI做。
- 要求判断用户输入的内容是否是积极的，是否可以出现在评论区。
这个需求是AI需求么？
首先这个需求都可以用AI做。
其次是否可以用程序实现？分词、关键词匹配或许是个解决方案。
但是面对一些阴阳怪气、正话反说的评论内容，这个技术方案就无法完美解决了。
所以这个需求，我们会认为是一个AI需求。
但是具体是不是要把它作为一个AI需求，还要具体看场景，
场景是否能够接受一定的容错率？
2. 需求场景具备一定的容错率或者会有兜底逻辑\人工检查
我们都知道大模型的输出是会存在幻觉的，也就是我们无法保障它永远百分百按照我们的预期进行返回。
所以需求场景是否具备一定的容错率，这一点就很重要。
如果需求场景一点容错率都没有，那么它不是一个适合AI的需求。
但是我们依然是可以在产品设计的方向上进行补充。最常见的有两个方案：设计兜底逻辑、添加人工检查逻辑。
例如兜底逻辑：在问答场景，需要精确回答但是又不确定答案的问题统一被拦截，然后设定固定输出：我不确定。
人工检查呢？那就更简单了，用户也是人，把信息扔给用户让用户进行确认操作就是个不错的解决方案。
特别是ToB的产品，ToB的产品一定要确保不是黑盒操作，一定要保留用户的知情权和控制权。
例如，toB的助手，用户说要修改某个产品信息，我们的助手一定要做的是，把最终要执行的任务显示给用户看，让用户进行确认。
这个就是人工检查的逻辑之一，另外ToB的AI产品设计我后面会写文章具体说，先点个关注吧。
到此时，我们就可以明确一个需求是不是AI需求了。
接下来就要分析具体的落地方案。
落地方案选择
我们工具箱里的工具，都有各自的适配逻辑，当我们确定了需求为AI需求之后，我们就需要开始考虑用哪个方案落地。
根据实际经验来看，非常大的一部分需求直接通过LLM调用就可以解决，直接调用大模型，利用大模型的理解能力来进行分析、判断、生成等功能。
例如：产品中加入数据分析功能，加入基础的对话功能，这类需求就是利用AI执行了思考的工作，语义理解、推理、生成等
当需求开始逐渐变复杂,特别是需求有明确的工作流程的时候，我们开始考虑使用workflow来明确定义任务。
尤其是我们对任务的执行流程有严格的控制倾向时，workflow可以很好的保证任务的可预测性和一致性。
例如：数据分析功能需要做横向的对比，或者对话功能需要使用本地知识库。
那么Workflow 和 Agent的区别是什么呢？
流程是否完全由AI主导
workflow是我们写好了程序，控制好整个流程，定义了任务执行路径，并在每个步骤中的操作方式设定了处理边界，AI可以在我们设定的边界内进行一些动态的行为。
工作流中的每个步骤都可以利用智能体的推理和工具使用能力，但整体流程遵循既定路径，也就是说整个任务的流程是可预测的
而Agent是在整个任务执行过程中，使用哪些工具、执行任务的顺序以及何时停止进行反馈，全都由AI自主进行。
这就是AI的主导性，当流程需要完全由AI主导时，特别是需要灵活性和模型驱动决策时，我们就考虑选择Agent。
通常什么情况下？我们需要一个完全由AI主导的需求呢？
当我们的任务复杂到没有一个标准的工作流程时， 这说明此时我们已经没办法使用workflow了，因为这已经不是ifelse写流程能解决的了。
而在Agent和Multi-Agent之间，我们通常会尽量选择Agent。
首先是因为Multi-Agent的tokens费用、开发周期、不确定性都太高了
其次是传统企业需要用到Multi-Agent的场景真的不多。
何时我们会一定选择Multi-Agent呢？
当我们必须要使用多智能体的协作能力时。
例如：研究项目、系统故障排查，连步骤都无法提前定义，这时我们才需要多智能体。
此处建议大家，在考虑Multi-Agent之前，可以先考虑一下Agent + Skill
由skill来提供不同的专业能力，由Agent解决协调调用问题，
避免引入多Agent而为系统带来复杂度，又能同样完成任务。
不过要注意，这个方案会比Multi-Agent耗时更长，
虽然做智能体时，我们已经不太在乎响应时间，但是用户的时间还是很宝贵的，尽量不要浪费吧。
在回顾一下选型方案：一旦确定为AI需求，就从最简单的方案开始评估。
| 方案 | 核心特征 | 适用场景 | 资源消耗与周期（参考） |
|---|---|---|---|
| 大语言模型（LLM） | 直接调用，充当“思考/生成引擎” | 基础对话、内容摘要、简单分析判断等单次思考/生成任务。 | 低，开发快 |
| 工作流（Workflow） | 流程由程序定义，AI在预设步骤边界内工作。任务流程可预测。 | 有明确步骤的需求，如：结合知识库的问答、分步骤的数据分析、有固定审批流的信息处理。 | 较低，单周内可完成 |
| 智能体（Agent） | 流程完全由AI主导，自主规划、调用工具、决策。具备高度灵活性。 | 任务复杂，没有标准工作流程，需要模型驱动决策。如：根据模糊目标自主上网搜索并撰写报告。 | 高（Token消耗是Workflow的5-10倍），通常需数周 |
| 多智能体协作 | 多个专业Agent协同，解决单一Agent能力或视角不足的问题。 | 极其复杂的开放式任务，如：模拟市场辩论、复杂的系统故障排查与研究项目。 | 极高（Token消耗是单Agent的10-15倍），需1-N个月 |
结语
好的，各位，关于AI需求如何选择落地方案，核心就讲这么多。
总结起来就三步走：
-
先看到底是不是AI需求。别为了用AI而用AI，能用传统工程逻辑解决的，那叫降本增效。顺便看看场景，能不能有点容错率，或者能不能设计个兜底、加个人工复核。
-
确定是AI需求后，从最简单的方案开始考虑。能直接调大模型解决的，就别上工作流。能靠工作流控制流程的，就别让智能体“自由发挥”。能一个智能体加各种“技能”搞定的，就坚决别启动“多智体协作”这种烧钱又耗时的大工程。杀鸡用牛刀，除了显得你很有钱，没任何好处。
-
选方案时，脑子里时刻要盘算两本账：tokens消耗（钱）和开发周期（时间）。Agent的消耗是Workflow的5-10倍，多智体更是指数级增长。开发周期也是从“周”到“月”，考虑下你的预算和排期。
我是华洛，关注我学习更多AI落地的实战经验与技巧。
加油，共勉。
☺️你好，我是华洛，All in AI多年，专注于AI在产品侧的应用以及企业AI员工的设计。
关注我：华洛AI转型纪实
专栏文章
# 从0到1打造企业级AI售前机器人——实战指南二：RAG工程落地之数据处理篇🧐
