Agent Basic / 01
什么是 Agent
很多人第一次接触 Agent 时，会把它理解成下面几种东西之一：
- 一个更聪明的聊天机器人
- 一个能自动调用工具的 LLM
- 一个会自己规划任务的系统
- 一个听起来比 Workflow 更高级的说法
这些理解都碰到了一点，但都不够完整。
一个更可用的定义
从工程角度看，Agent 是一个围绕目标持续推进任务的系统。
它通常具备下面几种能力：
- 接收目标，而不是只处理单轮输入
- 保留状态，而不是每次都像第一次对话
- 根据中间结果改变后续动作
- 在需要时调用外部工具
- 在不确定环境里迭代尝试，而不是一步写死
这意味着 Agent 的重点不是“模型更强”，而是“系统闭环更完整”。
先不要把 Agent 想得太神
很多介绍会把 Agent 说得很像“自主智能体”，但在大多数工程场景里，你更应该把它看成：
一个由大模型驱动、能根据状态决定下一步动作的任务执行系统。
它并不一定真的“自主”，也不一定总要长期运行、多轮反思、复杂规划。
很多实用 Agent 其实都很朴素，只是比普通问答系统多了几个关键能力。
Agent 的最小闭环
先看最小版本，不考虑复杂框架：
flowchart TD
A([接收目标]) --> B[读取上下文]
B --> C{决定下一步}
C -->|需要更多信息| D[调用工具]
C -->|信息已足够| G([输出结果])
D --> E[获取返回结果]
E --> F[更新状态]
F --> C
举个简单例子：
目标：分析某个币种今天是否存在异常风险。
一个最小 Agent 可能会这样工作：
- 读取当前任务目标和已有上下文。
- 判断下一步需要抓取哪些市场信息。
- 调用工具查询价格、成交量、新闻或链上数据。
- 根据返回结果更新内部状态。
- 如果信息不足，继续补充查询。
- 如果信息足够，输出风险判断和解释。
这里最关键的不是“它会说话”，而是它会围绕目标不断推进。
Agent 和普通 LLM App 的区别
普通 LLM App 常常更像这样：
flowchart LR
A([用户输入]) --> B[模型生成] --> C([输出结果])
它可以很好用，但通常是一次性响应。
而 Agent 更像这样：
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，不要先看它用了什么框架，也不要先看它会不会调用工具。
先看三件事：
- 它是不是围绕目标持续推进任务。
- 它会不会根据中间状态改变行为。
- 它是不是一个闭环系统，而不是一次性生成。
小结
Agent 的本质不是“更会聊天”，而是“更会执行”。
真正有价值的 Agent，通常不是在 UI 上看起来更智能，而是在系统层面更能处理：
- 多步任务
- 外部环境变化
- 工具协作
- 状态更新
- 不确定条件下的决策
下一篇建议接着看：