Appearance
什么时候应该使用 AI Agent
能用 Agent，不代表应该用 Agent
随着大模型能力越来越强，越来越多任务都可以被包装成 Agent。
例如一个很简单的文件处理流程：
text
上传文件
↓
转换格式
↓
保存文件
↓
发送通知当然可以让 Agent 来完成。
甚至可以把整个过程交给模型，让它自己判断：
- 应该调用哪个工具
- 下一步应该做什么
- 文件应该保存到哪里
- 什么时候发送通知
但这里有一个更重要的问题：
有必要吗？
如果整个流程本来就非常明确，把它改成 Agent，并不会自动让系统变得更好。
反而可能带来更多问题：
- 模型调用次数增加
- Token 和 API 成本更高
- 执行结果更难预测
- 调试过程更加复杂
- 权限控制更加困难
- 测试和评估成本上升
- 可能出现重复执行、错误调用甚至死循环
Agent 真正有价值的地方，是处理那些很难提前把执行路径完全写死的任务。
如果一个问题本来用一次模型调用、一条 Workflow 或一次知识检索就能解决，引入 Agent 往往只是增加复杂度。
目前常见的 Agent 可以怎么分类
现在 Agent 的产品和应用越来越多，并没有非常严格的分类。
为了方便大家理解，按照 Agent 的功能和使用场景，可以把它们大致分为下面这几类。
| 类型 | 主要解决的问题 |
|---|---|
| Coding Agent | 阅读、修改、测试和维护代码 |
| Research Agent | 搜索、阅读、验证并整理信息 |
| Data Agent | 查询、分析和解释数据 |
| Customer Support Agent | 理解业务问题并执行处理 |
| Browser / Computer Use Agent | 操作网页、软件和计算机环境 |
| Planning Agent | 在多个约束下规划并调整方案 |
这些分类之间并不是完全独立的。
例如一个 Coding Agent 也可能需要搜索资料，一个 Research Agent 也可能使用浏览器，一个 Customer Support Agent 也可能同时查询数据库、知识库和业务系统。
所以大家简单理解一下这些常见的Agent就行，没有必要见到一个Agent就强行归类。
前面的 AI Agent 能做什么：6 个典型案例 已经分别通过 Coding Agent、Deep Research Agent、Data Agent、Customer Support Agent、Browser Agent 和 Travel Planning Agent 展示过这些任务。
这里就不再重复介绍每一种 Agent 具体功能了。
什么样的任务值得使用 Agent
目标明确，但执行路径不固定
这是最典型的一类 Agent 任务。
例如：
修复项目中的登录异常。
目标非常明确：
text
让登录功能恢复正常但真正开始执行以后，很难提前知道完整路径。
可能需要：
text
查看日志
↓
搜索登录相关代码
↓
读取某个 Service
↓
发现问题来自数据库
↓
继续检查 Repository
↓
修改代码
↓
执行测试也可能第一步就发现问题根本不在代码，而是在环境配置。
因此很难提前写成：
text
第一步一定做 A
第二步一定做 B
第三步一定做 C真正能提前确定的通常只有：
最终希望达到什么结果。
至于怎么到达这个结果，需要系统根据当前环境动态决定。
Research Agent 也是如此。
例如：
调研目前几个主流 Coding Agent，并整理成对比报告。
目标是明确的。
但在任务开始之前，并不知道：
- 应该搜索多少次
- 应该阅读哪些页面
- 哪些来源最可靠
- 哪些信息需要继续验证
- 哪几个产品需要补充资料
这类：
目标明确，路径开放
的任务，就是 Agent 很典型的使用场景。
过程中需要持续判断
有些任务虽然有很多步骤，但每一步做什么都可以提前确定。
例如：
text
上传文章
↓
生成摘要
↓
翻译英文
↓
保存数据库这里不需要系统不停判断：
下一步应该做什么？
开发者已经提前设计好了。
但另一类任务不是这样。
例如数据分析：
为什么这个月网站注册用户下降了？
系统可能先查询总体注册量：
text
查询注册量
↓
发现确实下降接下来就需要判断：
应该继续查什么？
可能按渠道分析：
text
按渠道拆分
↓
发现自然搜索下降明显然后再次判断：
应该继续分析关键词、落地页，还是地区？
于是继续查询。
整个过程更像：
text
执行一步
↓
查看结果
↓
做出判断
↓
决定下一步
↓
继续执行所以 Agent 的价值往往出现在：
任务中存在大量无法提前完全写成规则的中间判断。
如果绝大多数判断都已经能够写成：
text
如果 A → 执行 B
如果 C → 执行 D那通常不一定需要 Agent。
前一步结果会影响下一步
这一点和“持续判断”关系很近，但更加关键。
Agent 并不是生成一份计划以后，就机械地从头执行到尾。
很多时候，执行结果本身就是下一轮决策的新输入。
例如 Coding Agent：
text
修改代码
↓
执行测试
↓
测试失败
↓
读取新的错误信息
↓
重新分析
↓
再次修改Research Agent：
text
搜索资料
↓
发现两个来源互相矛盾
↓
继续寻找更可靠的来源Browser Agent：
text
点击提交
↓
页面提示验证失败
↓
重新检查表单
↓
修改输入
↓
再次提交Data Agent：
text
查询整体数据
↓
发现某个渠道异常
↓
继续深入这个渠道这些任务都有一个共同结构：
text
行动
↓
获得反馈
↓
根据反馈重新判断
↓
下一次行动也就是前面《什么是 AI Agent》中提到的 Agent Loop：
text
判断 → 行动 → 观察 → 再判断如果任务天然需要这种反馈闭环，那么 Agent 的动态决策能力才真正有发挥空间。
需要调用工具和外部系统
很多值得 Agent 化的任务，并不是只靠模型生成一段文字就能完成。
它还需要真正和外部环境发生交互。
例如 Coding Agent 可能需要：
text
读取文件
搜索代码
修改文件
执行命令
运行测试Research Agent 可能需要：
text
搜索网页
打开页面
读取文档Data Agent 可能需要：
text
查询数据库
执行 SQL
调用数据分析工具Customer Support Agent 可能需要：
text
查询订单
查询物流
读取售后政策
创建工单
调用业务 APIBrowser Agent 则可能直接：
text
打开网页
点击
输入
滚动
下载文件当然：
用了工具，并不等于就是 Agent。
这一点我们在前面的 Agent、聊天机器人、工作流与 RAG 已经说明过。
但是：
当一个任务既需要动态判断，又需要不断通过工具获取信息和执行动作时，Agent 的价值会明显上升。
因为这时候系统需要反复完成：
text
模型判断
↓
调用工具
↓
工具返回结果
↓
模型继续判断Agent 才真正从“生成内容”变成“执行任务”。
什么情况下不要优先使用 Agent
一次模型调用就能完成
很多任务本身只需要：
text
输入
↓
LLM
↓
输出例如：
- 翻译一段文字
- 改写一段文案
- 总结一篇短文章
- 生成几个标题
- 解释一个概念
- 抽取固定字段
这些任务本身并不需要：
text
判断
→ 行动
→ 反馈
→ 再判断如果一次模型调用已经能够完成，就没有必要为了“Agent 化”而额外增加执行循环。
例如：
把这句话翻译成英文。
正常流程就是：
text
中文
↓
LLM
↓
英文如果硬要设计成：
text
Agent 判断是否翻译
↓
调用翻译工具
↓
检查翻译
↓
重新判断
↓
输出系统确实更复杂了。
但这个复杂度并没有带来相应价值。
所以：
能够一次完成的问题，优先使用简单方案。
执行流程已经非常固定
另一类不需要优先考虑 Agent 的任务，是执行路径已经很明确。
例如：
text
收到表单
↓
校验字段
↓
写入数据库
↓
发送邮件
↓
通知管理员或者：
text
上传 PDF
↓
解析文本
↓
生成摘要
↓
保存结果这些任务可能包含很多步骤，也可能使用 LLM。
但每一步该做什么基本都已经提前知道。
这种场景更应该优先考虑：
把流程设计清楚，然后稳定执行。
也就是前面介绍过的 Workflow。
如果为了让系统“更智能”，把原本稳定的流程全部交给模型动态决定：
text
模型判断下一步
↓
调用工具
↓
再判断反而可能降低：
- 稳定性
- 可预测性
- 可测试性
- 可维护性
所以记住：
路径越固定，Agent 的必要性通常越低。
主要问题只是缺少知识
还有一类需求看起来很“AI”，但它真正缺少的并不是 Agent。
例如：
根据公司的内部制度回答员工问题。
系统的问题可能只是：
模型不知道公司的私有知识。
这时候核心需求是：
text
用户问题
↓
找到相关公司资料
↓
提供给模型
↓
生成回答重点在于知识获取，而不是动态任务执行。
这正是前面介绍的 RAG 更擅长解决的问题。
类似的场景还有：
- 产品文档问答
- 企业知识库
- 技术资料问答
- 内部 FAQ
- 政策制度查询
如果主要瓶颈只是：
模型没有相关知识。
那么先把知识检索解决好，往往比一开始就设计 Agent 更重要。
当然，RAG 后续完全可以被 Agent 调用。
但不能因为系统需要查资料，就直接考虑 Agent。
错误成本过高且难以恢复
Agent 的一个重要特点，是执行过程存在一定动态性。
这也意味着：
系统很难保证每一次决策都完全符合预期。
如果一个任务失败以后成本很低，而且容易恢复，那么这种不确定性通常比较容易接受。
例如：
text
代码修改错误
→ 回滚
搜索方向错误
→ 重新搜索
数据分析方向不对
→ 换一个维度重新查询但有些动作的错误成本很高，而且很难恢复。
例如：
- 删除生产环境数据
- 大额资金转账
- 自动批准重大合同
- 直接执行高风险运维操作
- 替代专业人员做最终法律或医疗决策
一旦做错，可能很难撤销。
这并不意味着这些场景完全不能使用 Agent。
Agent 仍然可以参与：
text
收集信息
↓
分析
↓
生成建议
↓
准备操作
↓
人工确认
↓
真正执行也可以通过：
- 权限限制
- Human-in-the-loop
- 审批机制
- 沙箱环境
- 最小权限
- 执行预算
- 回滚机制
把 Agent 的行动范围限制在可控边界内。
所以真正应该避免的是：
在结果难验证、错误难恢复、风险又很高的情况下，直接把完整决策权和执行权交给 Agent。
Agent 的自主程度应该和任务风险匹配。
并不是越自主越好。
总结
判断一个任务是否值得使用 Agent，核心并不是看：
能不能让模型来做？
而是看 Agent 的动态决策能力，能不能真正解决这个任务里的不确定性。
比较适合 Agent 的任务，通常会同时具备一些特征：
text
目标比较明确
+
执行路径不完全固定
+
过程中需要持续判断
+
前一步结果影响下一步
+
需要调用外部工具
+
结果能够被验证可以进一步压缩成一个判断过程：
text
任务目标是否明确？
↓
执行路径是否存在不确定性？
↓
是否需要根据反馈持续调整？
↓
是否需要与外部环境交互？
↓
结果能否被验证？
↓
风险和权限能否被控制？
↓
是否值得使用 Agent反过来，如果：
text
一次模型调用就能解决或者：
text
执行路径已经非常明确或者：
text
主要只是缺少外部知识那么往往还有更简单的实现方式。
所以设计 Agent 时，记住一个原则：
能用 Agent，不代表应该用 Agent。
Agent 真正适合的，是那些目标明确，但具体执行过程存在不确定性，需要系统在行动和反馈之间持续做出判断并推进任务的场景。
当一个问题真正需要这种能力时，再引入 Agent，复杂度才是值得的。