先给结论：

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

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

一句话可以写成：

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

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

## 这些定义从哪里来

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

| 来源 | 文档 | 对 Agent 的关键描述 |
|---|---|---|
| OpenAI | [Agents SDK - Agents](https://openai.github.io/openai-agents-python/agents/) | Agent 是配置了 instructions（指令）、tools（工具），并可选配置 handoffs（交接/委派）、guardrails（护栏/安全约束）、structured outputs（结构化输出）等运行时能力的 LLM。 |
| OpenAI | [Agents SDK - Tools](https://openai.github.io/openai-agents-python/tools/) | Tools（工具）让 Agent 可以获取数据、运行代码、调用外部 API，甚至使用计算机。 |
| OpenAI | [Agents SDK - Handoffs](https://openai.github.io/openai-agents-python/handoffs/) | Handoff（交接/委派）允许一个 Agent 把任务委派给另一个 Agent，适合理解 multi-agent（多智能体）不是多个 prompt（提示词）简单拼接。 |
| Anthropic | [Building Effective Agents](https://www.anthropic.com/research/building-effective-agents) | Workflow（工作流）是预定义代码路径；Agent 是 LLM 动态指导自身流程和工具使用，并控制任务完成方式的系统。 |
| Anthropic | [Writing effective tools for agents](https://www.anthropic.com/engineering/writing-tools-for-agents) | Agent 的效果很大程度取决于工具设计；这说明 Agent 的核心不只是聊天，而是借助工具完成真实任务。 |
| LangChain | [Agents](https://docs.langchain.com/oss/python/langchain/agents) | Agent 是让模型循环调用工具，直到任务完成的系统。 |
| LangChain | [Context engineering in agents](https://docs.langchain.com/oss/python/langchain/context-engineering) | Agent 会运行 model/tool calling loop（模型/工具调用循环），直到模型不再调用工具，然后生成最终响应。 |
| Yao et al. | [ReAct: Synergizing Reasoning and Acting in Language Models](https://arxiv.org/abs/2210.03629) | ReAct（Reasoning and Acting，推理与行动）把 reasoning traces（推理轨迹）和 task-specific actions（面向任务的动作）交替生成，让模型在推理时也能与外部环境交互。 |

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

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

| 来源 | 文档 | 侧重点 |
|---|---|---|
| OpenAI | [New tools for building agents](https://openai.com/index/new-tools-for-building-agents/) | Agent 是能代表用户独立完成任务的系统，重点是复杂、多步骤任务。 |
| Google Cloud | [What are AI agents?](https://cloud.google.com/discover/what-are-ai-agents) | Agent 使用 AI 代表用户追求目标、完成任务，具备推理、规划、记忆和一定自主性。 |
| AWS | [What are AI agents?](https://aws.amazon.com/what-is/ai-agents/) | Agent 是能与环境交互、收集数据，并用这些数据执行自导向任务的软件程序。 |
| IBM | [What are AI agents?](https://www.ibm.com/think/topics/ai-agents) | Agent 会用可用工具设计 workflow，并自主执行任务。 |
| Microsoft | [AI agents: what they are](https://news.microsoft.com/source/features/ai/ai-agents-what-they-are-and-how-theyll-change-the-way-we-work/) | Agent 是语言模型之上的一层，会观察、收集信息、形成行动计划，并在允许时自己行动。 |

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

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

```text
普通 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 不是单次回答」。

典型过程像这样：

```text
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 则可能真的去执行：

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

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

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

```text
普通 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 可以简单理解为「带工具、状态和执行循环的大模型应用」。它不是单纯更聪明的聊天机器人，而是一个能围绕目标采取行动的软件系统。

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

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

四个问题都成立，就比较像 Agent。只成立第一个，通常只是普通 AI 助手。只成立工具调用但没有循环，也更像固定 workflow。真正有价值的 Agent，不在于名字，而在于它能不能在清楚边界内，把一个需要多步判断和执行的任务推进到可验证结果。