布吉岛 Agent

Appearance

Agent 有哪些应用场景：6 个典型案例 ​

Agent 应用场景案例 1：Coding Agent——从写代码到完成开发任务 ​

目前最火的 AI Agent ,莫过于Coding Agent 。

像 Claude Code、Codex、Cursor、GitHub Copilot Coding Agent 这一类产品，都可以看作是 Coding Agent工具。

它能做什么 ​

假设我们现在有一个已经存在的项目，然后提出一个需求：

给这个项目增加一个用户登录功能。

如果只是普通的大模型问答，我们可能会得到一段登录代码。

然后Ctrl + C ， Ctrl + V，这是大模型刚火的那段时间，特别常见的方式。

但 Coding Agent 不是这样。

它可能会先读取整个项目，找到用户模块、路由、数据库模型和现有代码规范，然后再决定应该修改哪些文件，就调用工具直接修改了。

比如下面这个简化的流程：

text
接收开发任务
    ↓
读取项目代码
    ↓
找到相关文件
    ↓
设计修改方案
    ↓
修改代码
    ↓
执行测试
    ↓
发现问题
    ↓
继续修改
    ↓
完成任务

如果找到的项目代码不够，就仍然会继续找。

如果测试失败，它还可以读取报错信息，再决定接下来应该改哪里。

如果发现项目里已经存在一套认证机制，它也可能直接沿用原来的设计，而不是重新实现一套。

为什么它是 Agent ​

因为我们告诉它：

实现登录功能。

但并没有提前规定：

text
第一步打开哪个文件
第二步修改哪一行
第三步执行什么命令
第四步遇到错误以后修改什么

这些步骤需要 Agent 根据当前项目和执行结果动态决定。

所以 Coding Agent 很适合帮助我们建立第一个案例直觉：

Agent 不只是生成一个结果，而是在围绕目标持续推进任务。

Agent 应用场景案例 2：Deep Research Agent——自己搜索、阅读和整理资料 ​

第二个非常典型的方向是 Deep Research Agent。

它和普通的“联网搜索 + 大模型总结”看起来很像，但实际任务过程通常更长，更智能。

它能做什么 ​

例如我们提出一个问题：

调研目前主流 Coding Agent 的发展情况，并比较 Claude Code、Codex 和 Cursor。

这并不是搜索一个关键词以后，把前三个网页总结一下就结束。

Research Agent 可能需要先把问题拆开：

text
有哪些主流 Coding Agent？
它们分别是什么定位？
支持哪些开发方式？
有哪些差异？
目前的发展方向是什么？

然后开始搜索资料。

读取第一批资料以后，可能又发现：

这里没有讲清楚某个产品的执行方式。

于是继续搜索。

或者发现两个来源说法不一致，就需要继续寻找更可靠的信息进行验证。

整个过程可能变成：

text
理解研究问题
    ↓
搜索资料
    ↓
阅读多个来源
    ↓
整理已有信息
    ↓
发现信息缺口
    ↓
继续搜索
    ↓
交叉验证
    ↓
整理结论
    ↓
生成研究报告

为什么它是 Agent ​

Research Agent 最关键的地方在于：

一开始并不知道完成这次研究到底需要搜索多少次，也不知道应该阅读哪些页面。

它需要根据已经获得的信息不断判断：

现在的信息够不够？

还有什么没有解决？

下一步应该搜索什么？

于是就会形成一种非常典型的循环：

text
Search
  ↓
Read
  ↓
Think
  ↓
Search Again
  ↓
Synthesize

这也是很多 Agent 系统非常重要的一种工作方式：

先行动，再根据行动结果决定下一步。

Agent 应用场景案例 3：Customer Support Agent——查资料并真正处理问题 ​

第三个案例是 Customer Support Agent，也就是客服 Agent。

那种传统客服机器人其实已经有很多年了。

比如：

text
用户输入关键词
    ↓
匹配 FAQ
    ↓
返回固定答案

这种系统并不是 Agent。

真正有意思的是，当客服系统开始具备“查信息、做判断、执行动作”的能力以后，整个系统就不一样了。

它能做什么 ​

例如用户提出：

我的订单已经五天没有发货了，帮我看一下是什么情况。

客服 Agent 可能会先识别问题，然后调用订单系统查询订单状态。

接着继续查询物流信息。

如果发现订单还没有出库，又可能继续查看商品库存或者售后规则。

最后根据实际情况选择不同处理方式：

text
理解用户问题
    ↓
查询订单
    ↓
查询物流
    ↓
读取售后规则
    ↓
判断问题原因
    ↓
选择处理方式
    ↓
回复 / 补发 / 退款 / 转人工

当然，在真实业务中，退款、赔付等动作通常还需要明确的权限、规则和人工兜底。

为什么它是 Agent ​

这个案例适合帮助我们理解：

Agent 不只是“会回答问题”，还可以“使用工具完成事情”。

普通客服聊天机器人可能只能告诉我们：

“订单延迟可能有多种原因，请联系人工客服查询。”

而接入业务系统之后的 Agent，则可能真正去：

  • 查询订单；
  • 查询物流；
  • 查看用户信息；
  • 阅读业务规则；
  • 调用相关接口；
  • 决定下一步处理方式。

于是 AI 从单纯的“生成内容”，开始逐渐进入真实业务流程。

Agent 应用场景案例 4：Data Agent——自己查数据、分析数据 ​

我们再来看一个和开发者、企业内部系统都有紧密联系的案例：

Data Agent。

它能做什么 ​

假设我们运营一个网站，然后发现最近注册用户下降了。

于是提出一个问题：

为什么这个月网站注册用户下降了？

传统的数据分析流程可能是：

text
提出问题
    ↓
数据分析师写 SQL
    ↓
导出数据
    ↓
制作图表
    ↓
继续拆分维度
    ↓
分析原因

Data Agent 则可以尝试参与这个过程。

例如它先查看数据库中有哪些表，再根据问题生成查询：

sql
SELECT
    DATE(created_at),
    COUNT(*)
FROM users
GROUP BY DATE(created_at);

发现确实下降以后，它可能继续判断：

是所有渠道都下降了，还是某个渠道下降了？

于是继续查询渠道数据。

如果发现自然搜索流量下降明显，还可以继续拆：

text
总注册量
    ↓
按渠道拆分
    ↓
发现自然搜索下降
    ↓
继续分析落地页
    ↓
发现某几个页面流量异常
    ↓
整理原因

最终生成一份分析结果。

为什么它是 Agent ​

Data Agent 真正厉害的地方，并不是“AI 会写 SQL”。

大模型早就可以写 SQL了。

关键的是：

Agent 可以根据前一次查询结果，决定下一步应该查什么。

也就是说，它面对的不是：

text
问题 → SQL → 答案

而是：

text
问题
 ↓
查询
 ↓
观察结果
 ↓
形成新的问题
 ↓
继续查询
 ↓
再次分析
 ↓
最终收敛

这就是非常典型的 Agent 工作模式。

Agent 应用场景案例 5：Browser Agent——像人一样操作网页和软件 ​

前面的几个 Agent，大部分都在调用 API、数据库、搜索工具或者代码工具。

还有另外一种很直观的 Agent：

Browser Agent，也可以进一步扩展成 Computer Use Agent。

简单理解就是：

让 Agent 像我们操作电脑一样使用网页和软件。

它能做什么 ​

比如提出一个任务：

帮我整理一下下周东京到上海比较合适的几个航班。

在拥有浏览器操作能力以后，Agent 可以尝试：

text
打开航班网站
    ↓
填写出发地
    ↓
填写目的地
    ↓
选择日期
    ↓
搜索航班
    ↓
调整筛选条件
    ↓
查看不同方案
    ↓
整理结果

同样的能力还可以用在很多办公场景中，例如：

  • 在后台系统录入数据；
  • 查询网页信息；
  • 填写表单；
  • 下载和整理文件；
  • 在多个网站之间复制和比对信息。

为什么它是 Agent ​

Browser Agent 给我们带来一个很直观的变化：

以前我们给程序写自动化脚本，经常需要提前定义：

text
点击按钮 A
等待页面加载
找到输入框 B
输入内容
点击按钮 C

但是网页稍微变化，脚本就可能失败。

Agent 的思路则更接近：

告诉系统我们想完成什么，让它根据当前页面状态判断下一步应该怎么操作。

当然，这并不意味着传统自动化没有用了。

在路径完全固定、稳定性要求很高的流程里，传统自动化往往依然更加可靠。

但 Browser Agent 让 AI 开始拥有了一个非常重要的能力：

直接和外部环境交互。

Agent 应用场景案例 6：Travel Planning Agent——在多个约束之间完成规划 ​

最后来看一个非常经典，同时也很容易理解的案例：

Travel Planning Agent，也就是旅行规划 Agent。

它能做什么 ​

例如我们提出一个需求：

国庆去日本玩 6 天，两个人，预算 1.5 万左右，想去东京和京都，但是不想每天赶路。

这个问题看起来不复杂，但真正规划起来会涉及很多条件：

  • 总预算；
  • 出行时间；
  • 城市选择；
  • 酒店价格；
  • 交通时间；
  • 景点开放时间；
  • 行程密度；
  • 兴趣偏好。

如果发现东京到京都的交通安排不合理，就需要调整当天行程。

如果酒店超预算，又可能重新调整住宿区域。

如果某个景点当天不开放，就需要重新排列前后顺序。

于是整个过程可能是：

text
理解旅行需求
    ↓
确定主要约束
    ↓
搜索交通和住宿
    ↓
规划每天行程
    ↓
检查时间和预算
    ↓
发现冲突
    ↓
重新调整
    ↓
形成最终方案

为什么它是 Agent ​

旅行规划特别能体现 Agent 的另外一个特点：

目标很明确，但完成目标的路径并不唯一。

我们知道最终想得到什么：

一份合适的旅行计划。

但是不存在一个固定公式：

text
东京一定玩 3 天
京都一定玩 3 天
酒店一定住哪里
每天一定去哪几个地方

系统必须在很多约束之间不断权衡。

预算变了，方案可能要变。

时间变了，方案也要变。

偏好变了，整个路线都可能重新调整。

所以旅行规划非常适合帮助我们理解：

Agent 经常面对的是一个目标，而不是一道只有唯一答案的题。

从这 6 个Agent 应用场景案例里，我们能看到什么 ​

到这里，我们已经看了 6 个差别非常大的案例：

  • Coding Agent 在写代码；
  • Research Agent 在查资料；
  • Customer Support Agent 在处理业务问题；
  • Data Agent 在分析数据；
  • Browser Agent 在操作网页；
  • Travel Agent 在规划行程。

表面上看，它们几乎没有什么关系。

但如果把行业和具体产品都拿掉，会发现背后一直在重复几件事情。

Agent 可以获取信息 ​

Research Agent 会搜索网页。

Data Agent 会查询数据库。

Customer Support Agent 会读取订单和业务资料。

Coding Agent 会读取整个代码仓库。

所以 Agent 并不只是依赖我们最开始输入的那一句话。

它可以不断从外部环境中获取新的信息。

Agent 可以使用工具 ​

不同 Agent 使用的工具也不一样。

Coding Agent 可能调用：

text
文件系统
终端
Git
测试工具

Data Agent 可能调用：

text
数据库
SQL 执行器
数据分析工具

Browser Agent 则可能直接操作：

text
浏览器
网页
桌面软件

工具让 Agent 从“只能生成内容”，逐渐变成“可以执行动作”。

Agent 可以根据结果继续判断 ​

Coding Agent：

text
执行测试
→ 失败
→ 阅读错误
→ 修改代码

Research Agent：

text
搜索资料
→ 信息不足
→ 继续搜索

Data Agent：

text
查询数据
→ 发现异常
→ 换一个维度继续查询

也就是说：

前一步的结果，会影响下一步做什么。

这也是为什么 Agent 经常不是一次调用模型就结束，而是会形成一个持续执行的过程。

Agent 可以围绕目标持续行动 ​

把前面的案例压缩到最后，其实都可以变成一个非常简单的结构：

text
目标
 ↓
观察当前信息
 ↓
思考下一步
 ↓
使用工具行动
 ↓
获得新的结果
 ↓
继续判断
 ↓
……
 ↓
完成目标

Coding Agent 的目标可能是：

完成一个功能。

Research Agent 的目标可能是：

完成一份研究报告。

Travel Agent 的目标可能是：

生成一份可执行的旅行计划。

具体场景完全不同，但背后的任务结构却越来越相似。

AI Agent 更像一个围绕目标持续获取信息、做出判断、使用工具并推进任务的系统。

但是这里马上又会产生一个新的问题：

只要会调用工具、会执行多步任务，就可以叫 Agent 吗？

Workflow、RAG、普通大模型应用和 Agent 到底又有什么区别？

下一篇，我们再正式讨论：

什么是 AI Agent？