---
layout: default
title: 什么是 Agent
description: 从工程角度理解 Agent 的最小定义
eyebrow: Agent Basic / 01
---

# 什么是 Agent

很多人第一次接触 Agent 时，会把它理解成下面几种东西之一：

- 一个更聪明的聊天机器人
- 一个能自动调用工具的 LLM
- 一个会自己规划任务的系统
- 一个听起来比 Workflow 更高级的说法

这些理解都碰到了一点，但都不够完整。

## 一个更可用的定义

从工程角度看，**Agent 是一个围绕目标持续推进任务的系统**。  
它通常具备下面几种能力：

- 接收目标，而不是只处理单轮输入
- 保留状态，而不是每次都像第一次对话
- 根据中间结果改变后续动作
- 在需要时调用外部工具
- 在不确定环境里迭代尝试，而不是一步写死

这意味着 Agent 的重点不是“模型更强”，而是“系统闭环更完整”。

## 一个值得记住的公式

如果只用一句话概括 Agent 的组成：

> **Agent = LLM + Context + Tools**

- **LLM**：提供理解、推理和生成能力
- **Context**：决定模型每一步能看到什么信息（指令、历史、状态、检索结果）
- **Tools**：让系统获得外部行动能力（查询、执行、写入）

这个公式的价值在于：它把注意力从“模型多强”转移到“系统怎么组织”。

很多人直觉上认为 Agent 能力的上限取决于模型。但实际工程中，**Context 的质量和 Tools 的设计往往比模型本身更决定系统表现**。同样的模型，在不同的上下文策略和工具配置下，行为差距巨大。

这也是为什么“Context Engineering”（上下文工程）在 2025-2026 年成为行业高频词——它不是 Prompt Engineering 的换皮说法，而是把“送进模型的完整信息组合”作为一等工程问题来设计。

## 先不要把 Agent 想得太神

很多介绍会把 Agent 说得很像“自主智能体”，但在大多数工程场景里，你更应该把它看成：

> 一个由大模型驱动、能根据状态决定下一步动作的任务执行系统。

它并不一定真的“自主”，也不一定总要长期运行、多轮反思、复杂规划。  
很多实用 Agent 其实都很朴素，只是比普通问答系统多了几个关键能力。

## Agent 的最小闭环

先看最小版本，不考虑复杂框架：

```mermaid
flowchart TD
    A([接收目标]) --> B[读取上下文]
    B --> C{决定下一步}
    C -->|需要更多信息| D[调用工具]
    C -->|信息已足够| G([输出结果])
    D --> E[获取返回结果]
    E --> F[更新状态]
    F --> C
```

举个简单例子：

> 目标：分析某个币种今天是否存在异常风险。

一个最小 Agent 可能会这样工作：

1. 读取当前任务目标和已有上下文。
2. 判断下一步需要抓取哪些市场信息。
3. 调用工具查询价格、成交量、新闻或链上数据。
4. 根据返回结果更新内部状态。
5. 如果信息不足，继续补充查询。
6. 如果信息足够，输出风险判断和解释。

这里最关键的不是“它会说话”，而是它会围绕目标不断推进。

## Agent 和普通 LLM App 的区别

普通 LLM App 常常更像这样：

```mermaid
flowchart LR
    A([用户输入]) --> B[模型生成] --> C([输出结果])
```

它可以很好用，但通常是一次性响应。

而 Agent 更像这样：

```mermaid
flowchart LR
    A([目标]) --> B[多步决策] --> C[工具调用] --> D[状态更新] --> E[继续执行] --> F([最终完成])
    E --> B
```

前者强调一次生成，后者强调持续执行。

## Agent 通常包含什么

一个稍微像样的 Agent，往往会逐步引入下面这些部分：

- `State`：当前任务状态
- `Tools`：查询、搜索、执行、写入等外部能力
- `Memory`：会话内或跨会话记忆
- `Planner`：决定下一步做什么
- `Policy / Guardrails`：限制它不能乱做
- `Evaluator`：判断结果是否足够好

不是每个 Agent 都必须全部具备，但越接近真实业务，这些模块就越重要。

## 一个容易踩的坑

很多 Demo 只要实现了“模型调用工具”就开始自称 Agent。  
但如果一个系统：

- 没有明确状态
- 没有执行闭环
- 没有结束条件
- 无法根据结果调整下一步

那它更像是“带工具调用的 LLM”，而不一定是一个完整 Agent。

## 先记住这句话

判断一个系统是不是 Agent，不要先看它用了什么框架，也不要先看它会不会调用工具。

先看三件事：

1. 它是不是围绕目标持续推进任务。
2. 它会不会根据中间状态改变行为。
3. 它是不是一个闭环系统，而不是一次性生成。

## 小结

Agent 的本质不是“更会聊天”，而是“更会执行”。

真正有价值的 Agent，通常不是在 UI 上看起来更智能，而是在系统层面更能处理：

- 多步任务
- 外部环境变化
- 工具协作
- 状态更新
- 不确定条件下的决策

下一篇建议接着看：

- [Workflow 和 Agent 的区别](../02-workflow-vs-agent/index.html)