什么是 Agent

Agent 翻译过来一般叫做智能体。

如果说普通大模型聊天是「你问一句, 它答一句」, 那么 Agent 更像是「你给它一个目标, 它自己拆解任务、调用工具、观察结果, 最后尽量完成这个目标」。

一个简单的理解:

Agent = 大模型 + 目标 + 上下文 + 工具 + 执行循环

比如我们对普通聊天模型说:

帮我解释一下 Vue 的响应式原理

它只需要根据已有知识回答。

但如果我们对一个代码 Agent 说:

帮我修复这个项目里的登录 bug, 并跑一下测试

它可能会做这些事情:

1. 读取项目目录
2. 搜索登录相关代码
3. 找到可能出问题的文件
4. 修改代码
5. 运行测试
6. 根据报错继续调整
7. 总结改了什么

这就是 Agent 和普通问答最大的区别: Agent 不只是回答, 还会围绕目标采取行动。

Agent 和 Chatbot 的区别

Chatbot

Chatbot 更偏向对话。

用户输入问题, 模型根据上下文生成回答。它可以很聪明, 但大多数时候不会真正操作外部世界。

例如:

• 解释一个概念
• 总结一段文字
• 帮你写一段代码
• 帮你翻译内容

Agent

Agent 更偏向完成任务。

它不仅能生成文本, 还可以根据任务需要调用工具, 比如读文件、查资料、运行命令、访问数据库、调用 API 等。

例如:

• 自动分析项目并修复 bug
• 根据需求生成页面并启动本地服务
• 查询数据库后生成报表
• 阅读会议纪要并创建待办
• 使用 MCP 工具连接飞书、GitHub、文件系统等外部服务

所以可以这样记:

Chatbot 主要负责「说」, Agent 还要负责「做」。

Agent 的核心组成

1. 模型

模型是 Agent 的大脑, 负责理解任务、推理、规划和生成内容。

常见的大模型能力包括:

• 理解自然语言
• 生成文本和代码
• 分析上下文
• 判断下一步应该做什么
• 根据工具返回结果继续推理

模型越强, Agent 在复杂任务中的表现一般越好, 但成本和速度也要考虑。

2. 指令

指令用来告诉 Agent 应该如何工作。

比如:

• 你的角色是什么
• 能做什么, 不能做什么
• 遇到不确定问题怎么处理
• 输出格式应该是什么样
• 是否需要先分析再行动

可以把指令理解成 Agent 的「行为规范」。

同样的模型, 配上不同的指令, 表现会很不一样。

3. 上下文

上下文就是 Agent 当前能看到的信息。

比如:

• 用户提出的需求
• 当前项目文件
• 历史对话
• 文档内容
• 数据库查询结果
• 工具调用返回的信息

模型本身不是直接知道你的项目长什么样的, 它需要通过上下文来理解当前环境。

上下文越准确, Agent 越不容易瞎猜。

4. 工具

工具是 Agent 操作外部世界的手。

常见工具有:

• 文件读取和编辑
• 终端命令
• 搜索引擎
• 数据库查询
• 浏览器操作
• API 调用
• GitHub、飞书、Notion 等平台能力

没有工具的 Agent 很多时候只能「想」和「说」。

有了工具之后, Agent 才能真正执行任务。

5. 记忆

记忆可以分成两类:

短期记忆

短期记忆就是当前对话里的上下文。

比如你刚刚告诉它:

这个项目使用 Vue3 和 Pinia

在当前对话里, 它就可以利用这个信息。

长期记忆

长期记忆是跨会话保存的信息。

比如:

• 用户偏好
• 常用项目路径
• 常用技术栈
• 团队规范
• 过去总结出的经验

长期记忆很有用, 但也要注意隐私和过期问题。错误的记忆反而可能误导 Agent。

6. 规划能力

复杂任务不能一步完成, Agent 需要先拆解任务。

比如:

帮我做一个博客文章搜索功能

它可能拆成:

1. 查看当前博客框架
2. 确认是否已有搜索插件
3. 修改配置
4. 调整页面入口
5. 构建验证

规划能力决定了 Agent 能不能把一个模糊目标变成可执行步骤。

7. 反馈循环

Agent 不是一次性输出就结束, 它通常会进入一个循环:

1. 思考下一步
2. 调用工具
3. 观察工具结果
4. 根据结果调整计划
5. 继续执行或结束

这个循环也叫 Agent Loop。

很多 Agent 能完成复杂任务, 靠的就是这个「执行 -> 观察 -> 修正」的过程。

Agent 的基本运行流程

可以用一个简单流程表示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

用户目标
  ↓
理解任务
  ↓
收集上下文
  ↓
制定计划
  ↓
调用工具
  ↓
观察结果
  ↓
调整计划
  ↓
继续执行 / 给出最终答案

比如修 bug:

1
2
3
4
5
6
7
8
9
10
11

用户: 登录后页面白屏
  ↓
Agent 搜索登录、路由、权限相关代码
  ↓
发现 token 为空时仍然进入了需要权限的页面
  ↓
修改路由守卫
  ↓
运行测试或启动项目验证
  ↓
输出修改总结

Agent 和工作流的区别

Agent 经常和 Workflow 工作流放在一起比较。

工作流

工作流的步骤通常是固定的。

例如:

1

提交表单 -> 审批 -> 发送通知 -> 归档

每一步都提前写死, 稳定、可控, 但灵活性有限。

Agent

Agent 的步骤可以根据情况动态变化。

例如:

1
2
3
4
5

用户让 Agent 修 bug
Agent 先搜索代码
如果找不到, 再看日志
如果日志不够, 再运行测试
如果测试失败, 再继续定位

它不是完全按照固定流程走, 而是根据观察结果调整行动。

所以:

工作流适合稳定重复的任务, Agent 适合开放、复杂、需要判断的任务。

Agent 和 MCP 的关系

MCP 是 Model Context Protocol, 可以理解成连接 Agent 和外部工具/数据源的一套标准协议。

如果把 Agent 比作一个会思考的人:

• 大模型是大脑
• 工具是手和眼睛
• MCP 是统一连接工具的接口

没有 MCP 之前, 每个工具都要单独适配。

有了 MCP 之后, 文件系统、数据库、GitHub、飞书、浏览器等能力可以通过统一方式暴露给 Agent。

也就是说:

MCP 不是 Agent 本身, 但 MCP 可以让 Agent 更方便地连接外部世界。

举个例子:

一个 Agent 想读取项目文件, 可以通过文件系统 MCP。

一个 Agent 想查询数据库, 可以通过数据库 MCP。

一个 Agent 想发送飞书消息, 可以通过飞书 MCP 或类似工具。

这样 Agent 不需要关心每个平台底层 API 的细节, 只需要知道有哪些工具可以用、参数是什么、返回结果是什么。

常见 Agent 类型

代码 Agent

用于写代码、改 bug、跑测试、解释项目结构。

典型能力:

• 阅读仓库
• 修改文件
• 运行命令
• 分析报错
• 生成提交说明

比如 Codex、Cursor Agent 这类工具就偏代码 Agent。

搜索 Agent

用于查资料、对比信息、整理结论。

典型能力:

• 搜索网页
• 打开文档
• 提取重点
• 交叉验证信息
• 输出带来源的总结

数据 Agent

用于查询和分析数据。

典型能力:

• 查询数据库
• 写 SQL
• 生成图表
• 发现异常
• 输出分析报告

办公 Agent

用于处理文档、会议、邮件和任务。

典型能力:

• 总结会议纪要
• 创建待办
• 写邮件
• 整理文档
• 查询日程

多 Agent 系统

多个 Agent 分工协作。

比如:

• 一个负责需求分析
• 一个负责写代码
• 一个负责测试
• 一个负责代码审查

多 Agent 听起来很强, 但也更容易带来沟通成本、重复工作和结果不一致的问题。不是所有任务都需要多 Agent。

ReAct 思想

Agent 中经常会看到一个词: ReAct。

ReAct = Reasoning + Acting

也就是:

• Reasoning: 推理, 想清楚下一步要做什么
• Acting: 行动, 调用工具或执行操作

一个简化例子:

1
2
3
4
5
6
7
8

思考: 我需要先知道项目结构
行动: 读取目录
观察: 发现是 Hexo 博客
思考: 需要看 source/_posts 下的文章格式
行动: 读取文章 front matter
观察: 文章有 title、date、tags、categories 等字段
思考: 可以按现有格式新增文章
行动: 创建 Markdown 文件

这也是很多 Agent 的基本工作方式。

构建一个简单 Agent 需要什么

最小版本的 Agent 可以包含这些部分:

1. 一个明确目标
2. 一个大模型
3. 一组可用工具
4. 一个状态记录
5. 一个循环
6. 一个停止条件

伪代码大概是这样:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

while (!done) {
  const nextStep = await model({
    goal,
    context,
    tools,
  })

  if (nextStep.type === 'tool_call') {
    const result = await callTool(nextStep.tool, nextStep.args)
    context.push(result)
  }

  if (nextStep.type === 'final_answer') {
    done = true
    return nextStep.content
  }
}

这段代码表达的不是具体实现, 而是 Agent 的核心思想:

模型决定下一步, 工具负责执行, 执行结果再回到上下文里。

Agent 的风险和限制

Agent 很有用, 但不能把它当成完全可靠的自动驾驶。

常见问题有:

1. 幻觉

模型可能会编造不存在的 API、文件、配置项。

解决思路:

• 尽量让 Agent 读取真实文件
• 让它引用来源
• 关键结论需要验证

2. 工具调用错误

Agent 可能选错工具, 或者传错参数。

解决思路:

• 工具描述要清楚
• 参数结构要严格
• 对危险操作增加确认

3. 上下文不足

如果 Agent 看不到关键文件, 就容易误判。

解决思路:

• 让它先搜索和阅读
• 不要只给零散片段
• 对复杂任务提供背景信息

4. 权限风险

Agent 能执行操作, 就要注意权限边界。

比如删除文件、发邮件、改数据库这类操作, 最好需要人工确认。

5. 成本和速度

Agent 会多轮思考和调用工具, 可能比一次问答更慢、更贵。

适合 Agent 的任务通常是:

• 有明确目标
• 步骤不完全固定
• 需要读取外部信息
• 需要多轮调整

不适合 Agent 的任务:

• 简单问答
• 一步就能完成的小任务
• 对实时性要求极高的任务
• 不允许任何不确定性的高风险操作

学习 Agent 可以先抓住这些关键词

• LLM: 大语言模型, Agent 的大脑
• Tool Calling: 工具调用, 让模型使用外部能力
• Context: 上下文, 模型当前能看到的信息
• Memory: 记忆, 保存历史经验或用户偏好
• Planning: 规划, 把目标拆成步骤
• Agent Loop: 智能体执行循环
• ReAct: 推理和行动结合
• RAG: 检索增强生成, 先查资料再回答
• MCP: 模型上下文协议, 标准化连接外部工具
• Human-in-the-loop: 人在回路, 关键操作让人确认
• Guardrails: 护栏, 限制 Agent 的行为边界

总结

Agent 的重点不是「模型会聊天」, 而是「模型能围绕目标持续行动」。

它的本质是:

让大模型在上下文和工具的帮助下, 通过多轮观察和调整, 完成一个相对复杂的任务。

学 Agent 可以先记住三句话:

1. Agent 比 Chatbot 多了行动能力
2. 工具和上下文决定 Agent 能做什么
3. MCP 可以让 Agent 更标准地连接外部工具和数据源

对于前端或全栈开发来说, Agent 最值得关注的方向是代码 Agent、文档 Agent 和自动化办公 Agent。它们不一定会替代开发者, 但会越来越像一个能读项目、会查资料、能执行命令的协作助手。