区分 chatbot、workflow、agent、multi-agent
chatbot：核心是单轮或多轮对话式交互，本质是“用户输入->模型推理->输出文本”，没有工具调用、没有多步骤任务分解，关键特征是无状态或若状态、不产生“行动”，只产生“话语”。
workflow：开发者预先定义好固定的执行路径（if-else、顺序、并行分支都是硬编码好的），LLM只是这个固定路径里的某几个节点
Workflow 示例:
用户提交请求 → [固定步骤1:调用LLM做意图分类]
→ [固定步骤2:根据分类结果走不同分支]
→ [固定步骤3:调用对应的API]
→ [固定步骤4:LLM生成回复]
LLM没有权限决定要不要跳过某一步，这是Workflow和Agent的本质区别-控制权在谁的手里。
agent：模型只能推理,tool只能被执行,agent是两个的整合，Agent 的核心特征是"控制权交给了大模型"
mulit-agent：是多个agent协助，
| 协作模式 | 说明 |
|---|---|
| 主从式(Orchestrator-Worker) | 一个主Agent负责任务分解和调度,多个子Agent各自执行专项任务 |
| 平行协商式 | 多个Agent各自独立处理后,结果汇总投票/裁决 |
| 流水线式 | Agent A的输出是Agent B的输入,像工厂流水线 |
| 辩论式 | 多个Agent对同一问题给出不同观点,互相质询修正 |
理解 agent 的基本循环：observe -> think -> act -> observe理解 agent 的基本循环：observe -> think -> act -> observe
Observe(观察):获取当前环境状态/信息。第一次是"接收到用户任务",之后每一轮是"上一次Act执行完的结果反馈"
Think(思考):大模型基于当前观察到的信息进行推理——判断"任务是否已经完成"、"如果没完成,下一步该做什么、该调用哪个工具"
Act(行动):执行 Think 阶段决定的动作,通常是调用某个工具(查数据库、调API、执行代码)
Observe(再观察):把 Act 执行后的结果(可能成功、可能报错、可能返回了新信息)作为新的观察输入,进入下一轮 Think
这个循环终止的条件是大模型自己在 Think 阶段判断"任务已完成,不需要再 Act 了",然后跳出循环、整理最终答案返回给用户。
明白什么时候不该用 agent：任务可预测、流程稳定、普通脚本能解决时，agent 反而增加不确定性
1.Agent的“自助决策权”本身就是不确定性的来源，本质是概率采样，不是确定性逻辑，用 Agent 让大模型"自己想该怎么做",相当于把一个本该用 if-else 写死的逻辑,交给一个有随机性的组件去决定——这是给系统凭空引入了不必要的不确定性。
- 选择不同的工具调用顺序
- 对同一个工具传入略有差异的参数
- 甚至偶尔"跳过"某个本该执行的步骤,或者"多此一举"执行了不必要的步骤
2.成本和延迟的代价不对等，Agent循环里每轮Think都是一次LLM调用，一个稍微复杂点的任务可能要跑3-5轮甚至更多循环才能完成，而如果流程本身是确定地，用普通代码一次执行就能完成同样的事，成本和延迟可能是几十倍的差距。
3.可观测性和可调试性大幅下降，确定性代码的最大优势是行为可预测、可单元测试、出问题能精确复现。而Agent因为每次的推理路径可能不同，同样的输入额偶尔走出不同的执行路径，这会带来以下问题：
- 无法写传统意义上的单元测试(测试用例期望的是固定输出,但 Agent 输出有波动)
- 线上出问题难以复现——"为什么这次它没调用应该调用的工具?"这类问题往往很难定位,因为背后是模型的推理过程,不是可断点调试的确定性代码
- 回归测试成本高——传统代码改动后跑一遍测试用例就能确认没有破坏原有逻辑,Agent 因为存在随机性,同样的测试用例可能这次通过、下次又不通过
4.“错误累计”和“路劲偏移”的风险，Agent 循环是多轮迭代的,每一轮的 Think 都基于上一轮 Act 的结果。如果某一轮判断出现偏差(比如工具调用参数错了、或者对返回结果理解错了),这个错误会带入下一轮的 Observe,进而影响后续所有轮次的判断——这叫误差累积/路径偏移。而确定性流程因为每一步都是硬编码的,不存在"模型理解错了导致后续全部偏移"这种风险。
5.总结判断
| 判断维度 | 用确定性代码/Workflow | 用 Agent |
|---|---|---|
| 流程是否固定 | 是(每次执行路径一样) | 否(路径取决于中间结果,需要动态判断) |
| 决策是否需要"理解"和"推理" | 不需要,规则/条件已知 | 需要,比如需要理解自然语言意图、处理模糊输入 |
| 对错误的容忍度 | 低(金融交易、库存扣减等) | 相对可以接受一定试错空间(比如探索性任务) |
| 是否需要处理开放式/未知边界的输入 | 否,输入结构清晰 | 是,比如用户用自然语言提出五花八门的需求 |
| 成本和延迟敏感度 | 高(高并发、低延迟场景) | 相对不敏感(复杂低频任务) |