Agent 是什么，能干什么

先给结论：

Agent（智能体/代理）不是一种新的模型类型，而是一种围绕 LLM（大语言模型）搭出来的执行架构。它的核心是：给定目标后，模型可以在边界内选择步骤、调用工具、观察结果，再继续调整下一步。

所以，直接调用大模型返回一段内容，一般不算 Agent。它更像普通 LLM 调用、chatbot（聊天机器人）或 completion wrapper（补全封装）。只有当系统具备「目标、工具、状态、循环控制」时，才更接近 Agent。

一句话可以写成：

1

Agent = LLM + Tools（工具） + State（状态） + Loop（循环控制）

这两年很多产品都在说自己是 Agent，但这个词经常被用得很松。把大模型接到一个聊天框里，用户问一句，它答一句，这当然是 AI 应用，但通常还不能算 Agent。后面从来源、执行循环、组成部分和使用场景拆开看。

这些定义从哪里来

我这里不是把某个产品文案直接当定义，而是把几份更接近原始材料的文档放在一起看：

这些材料的侧重点不完全一样。OpenAI 更强调「LLM + instructions（指令）+ tools（工具）+ runtime behavior（运行时行为）」；Anthropic 更强调「workflow（工作流）和 agent 的控制流区别」；LangChain 更强调「model calls tools in a loop（模型在循环中调用工具）」；ReAct 则给出了「推理和行动交替」这一类 Agent 执行循环的经典形式。

如果再看云厂商和企业平台的定义，也基本是同一条线：

这些定义的共同点依然是：目标、环境、工具、状态、行动。差别主要在抽象层级：经典 AI 讲「感知环境并行动」，LLM Agent（大模型智能体）讲「模型调用工具并循环推进任务」，企业平台讲「代表用户或组织完成可审计的业务流程」。

把这些说法合起来，可以得到一个比较稳的边界：

1
2
3
4
5
6

普通 LLM 调用：
user -> LLM -> text

Agent：
user -> runtime（运行时） -> LLM decides -> tool call（工具调用） -> observation（观察结果）
     -> LLM decides next step -> ... -> final result

所以「直接调用大模型返回内容」一般不算 Agent。它更像 chatbot、completion wrapper 或 LLM app。只有当系统允许模型围绕目标选择动作、调用外部工具，并根据执行结果继续推进时，才更符合 Agent 的定义。

ReAct 循环

很多人理解 Agent，会从 ReAct 开始。它不是唯一的 Agent 架构，但很适合解释「为什么 Agent 不是单次回答」。

典型过程像这样：

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

Goal: 帮我分析这个 CSV 文件并画图

Thought: 我需要先读取文件，看看数据结构
Action: read_file("data.csv")
Observation: 文件有 3 列，分别是 date、user_count、error_count

Thought: 适合画两条时间序列
Action: run_code("import pandas as pd ...")
Observation: 图表已生成

Thought: 还需要解释趋势和异常点
Answer: 这是图表和分析结论

这里的重点不是把 Thought 展示给用户，而是这个执行模型：先根据目标决定动作，动作产生观察结果，再根据新结果继续决定下一步。现代产品通常不会把内部推理完整暴露出来，但「工具调用 - 观察 - 继续行动」这个结构仍然是 Agent 的核心。

Agent 通常由哪些部分组成

一个可用的 Agent 不只是一个 prompt，通常至少有这几块：

1. 目标：用户要它完成什么，而不是只回答什么。
2. Planner（规划器）：判断下一步做什么，可以是显式计划，也可以是每轮动态决策。
3. Tools（工具）：搜索、读写文件、调用 API、运行命令、访问数据库、操作浏览器等。
4. Memory / State（记忆/状态）：当前任务进展、已观察到的结果、失败原因、上下文和历史记录。
5. Executor（执行器）：真正执行工具调用，并把结果反馈给模型。
6. Critic / Verifier（评审器/验证器）：检查结果是否满足目标，失败时决定重试、改路径或停止。
7. 停止条件：任务完成、失败不可恢复、达到预算、需要人确认。
8. 安全边界：权限、审批、回滚、日志、敏感操作限制。

这些组件里，最关键的是工具和循环。没有工具，Agent 只能建议；没有循环，Agent 只能回答一次。工具让它能接触外部世界，循环让它能根据反馈修正路径。

还有哪些分类方式

如果从经典 AI 的角度看，Agent 不一定都以 LLM 为核心。AWS 的定义里仍然保留了几类更传统的 Agent 类型：

• Reflex agent（反射型智能体）：根据当前输入和规则直接反应，例如关键字触发的自动回复。
• Model-based agent（基于模型的智能体）：维护一个内部状态或环境模型，再根据模型做决策。
• Goal-based agent（目标型智能体）：围绕目标比较不同路径，选择能达成目标的动作。
• Utility-based agent（效用型智能体）：不只追求完成目标，还会比较收益、成本、风险，选择效用更高的方案。
• Learning agent（学习型智能体）：从历史反馈中调整策略。
• Hierarchical agent（层级型智能体）：上层 Agent 拆任务，下层 Agent 执行子任务。
• Multi-agent system（多智能体系统）：多个 Agent 协作、协调，甚至竞争。

现代 LLM Agent 更常见的是另一种分类：

• Chat agent（对话型智能体）：以对话为入口，能查资料、调用工具、完成轻量任务。
• Coding agent（代码智能体）：读代码、改文件、跑测试、生成 patch（补丁）或 PR（Pull Request，合并请求）。
• Browser agent（浏览器智能体）：打开网页、点击、填写表单、下载资料。
• Data agent（数据智能体）：查数据库、写 SQL、做分析、生成图表。
• DevOps / SRE agent（运维/站点可靠性智能体）：查日志、看监控、执行诊断命令、生成修复建议。
• Security agent（安全智能体）：分析告警、关联日志、生成调查结论或响应动作。
• Business workflow agent（业务工作流智能体）：处理报销、合同、客服、采购、销售线索等流程。
• Background agent（后台智能体）：不一定和人实时聊天，而是在队列、事件或定时任务里持续处理工作。

这里要注意一点：这些分类不是互斥的。一个代码 Agent 也可能是 browser agent；一个 SRE Agent 也可能同时用 SQL、shell、监控 API 和工单系统。

Agent 能干什么

Agent 适合处理「目标明确，但步骤需要根据中间结果调整」的任务。比如：

• 排查问题：读取日志、查询监控、复现错误、定位原因、给出修复建议。
• 写代码：理解需求、修改文件、运行测试、根据失败结果继续修。
• 信息整理：搜索资料、交叉验证来源、提炼结论、生成报告。
• 运维操作：检查服务状态、执行诊断命令、做有限范围的修复。
• 办公自动化：整理邮件、创建日程、更新表格、生成文档草稿。
• 数据分析：读取数据、写查询、画图、解释异常点。
• 客服：查询订单、判断政策、补充信息、必要时转人工。
• 安全运营：收集告警上下文、查资产、关联 IOC、生成处置建议。
• 采购和财务：比价、核对发票、补齐报销材料、更新 ERP。
• 研究和情报：跨网页、论文、内部文档收集证据，最后生成带来源的结论。
• 个人助理：订票、排日程、整理待办，但高风险动作要有人确认。

普通聊天模型也能告诉你「应该怎么排查数据库连不上」。Agent 则可能真的去执行：

1
2
3
4
5
6
7
8

1. SSH 到服务器
2. 查看服务状态
3. 检查端口监听
4. 查看防火墙规则
5. 读取应用日志
6. 尝试连接数据库
7. 根据错误继续排查
8. 给出结论，或在授权后执行修复

这就是 Agent 和建议型助手的区别：一个主要生成答案，一个会围绕目标推进任务。

放到基础设施场景里，可以这样类比：

1
2

普通 LLM ~= 一个会回答问题的 runbook（运行手册）
Agent    ~= 一个能自己 kubectl get、分析日志、执行修复、验证结果的 SRE（站点可靠性工程）自动化执行体

例如「VM pod 一直 Terminating，帮我修复」这个任务，普通模型可能列出排查步骤；Agent 则可能先 kubectl describe pod，发现存储卷还被锁住，再检查 CSI 或 RBD 状态，最后在权限允许时执行修复并再次 kubectl get pod 验证。

Workflow（工作流）和 Agent 的区别

不是所有自动化都需要 Agent。

如果路径固定，用普通 workflow 更好。例如「每天 9 点拉取报表，转成 PDF，发到群里」这种任务，规则明确、分支很少，写脚本或工作流更稳定。

Agent 更适合路径不固定的场景。例如「这次 CI 为什么失败，帮我修一下」。它可能需要先看失败 job，再看日志，再判断是测试问题、依赖问题还是代码问题，然后选择不同动作。这里提前写死所有路径很难，让模型参与决策才有价值。

可以这样划分：

• workflow：人把步骤写死，模型只是其中一个节点。
• agent：人给目标和边界，模型参与决定下一步。

Multi-agent（多智能体）是什么

Multi-agent 不是简单开多个聊天窗口。更合理的理解是：把一个大任务拆给多个有不同职责的 Agent，并让它们通过明确的交接机制协作。

例如一个代码变更可以拆成：

• 实现 Agent：负责修改代码。
• Review Agent：只看 bug、回归风险和测试缺口。
• CI Agent：跟踪失败日志并定位原因。
• 文档 Agent：补充变更说明。

这里的关键不是「数量多」，而是职责边界清楚、上下文交接清楚、最终有一个收敛点。否则 multi-agent 很容易变成多个模型各说各话。

使用 Agent 时要小心什么

Agent 的能力来自工具和权限，也意味着风险来自工具和权限。

如果一个 Agent 能读文件、执行命令、访问生产环境、发送邮件、修改数据库，那它就不只是聊天助手，而是一个会影响外部世界的软件执行体。设计时至少要考虑：

• 哪些工具可以自动调用，哪些必须人工确认。
• 修改类操作有没有日志、diff、回滚方式。
• 敏感数据会不会被带进不该去的上下文。
• 任务失败时是停止、重试，还是升级给人处理。
• 成本、耗时和调用次数有没有预算限制。

不要因为它叫 Agent，就默认应该拥有所有权限。一个生产可用的 Agent，边界通常比能力更重要。

总结

判断一个系统是不是 Agent，可以问四个问题：

1. 它有没有明确目标，而不只是回答问题？
2. 它能不能调用外部工具？
3. 它会不会根据工具结果调整下一步？
4. 它有没有停止条件和安全边界？

四个问题都成立，就比较像 Agent。只成立第一个，通常只是普通 AI 助手；只有工具调用但没有循环，更像固定 workflow。关键不在名字，而在它能不能在清楚边界内，把一个多步任务推进到可验证结果。