什么是 Agent？一文讲透 AI 代理
这两年"Agent（代理）"成了 AI 圈最热也最被滥用的词：编码代理、GUI 代理、多代理系统、代理平台……但若追问一句"到底什么才算 Agent"，多数人只能含糊作答。本文给一个清晰的定义，拆解它的核心循环与四大构件，分清它与聊天机器人、工作流的边界，并结合本系列此前介绍过的 LangChain、LangGraph、Agno、PocketFlow、Page Agent 等项目，讲清 Agent 从概念到落地的全貌。读完你再看到"XX Agent"，就能立刻判断它到底是什么、能干什么。
1、Agent 的定义
一句话定义：Agent 是能够感知环境、自主决策、调用工具、循环行动直至达成目标的软件实体。在大模型时代，Agent 的标准形态是：以 LLM 为"大脑"，配上工具、记忆与规划能力，把"用户的一句意图"变成"一连串实际动作"。
定义里的四个关键词：
- 感知：从对话、文档、页面、屏幕等输入中理解现状
- 决策：由 LLM 判断下一步做什么，而不是人写死的流程
- 行动：真正去执行——调 API、读写文件、点击页面、发消息
- 目标导向：围绕任务循环推进，直到完成或确认无法完成
与聊天机器人的分界就在"行动"二字：
- Chatbot 只会"说"：收到问题，生成回答，结束
- Agent 会"做"：收到目标，规划步骤，调用工具，看着结果调整，最后交付
- 你让 Chatbot"帮我订机票"，它给你一段订票攻略；Agent 直接打开订票页面填好表单
2、核心循环：思考-行动-观察
剥掉所有花哨概念，Agent 的内核就是一个循环：LLM 在循环里反复"思考、行动、观察"，直到任务完成。业界称之为 ReAct 模式（Reason + Act），也是"LLM in a loop"这一经典说法的由来。
// Agent 核心循环（示意伪代码）
while True:
thought = llm(context + history) // 思考：决定下一步做什么
action = thought.tool_call // 行动：选择工具与参数
observation = tools.execute(action) // 观察：拿到工具返回的结果
history.append(thought, observation) // 全部记入上下文，供下轮参考
if thought.done: // 模型判定任务完成
break循环的三个环节：
1. 思考（Reason）：模型基于目标与已有观察，推理出下一步
2. 行动（Act）：执行一次工具调用——查库、读文件、点按钮、跑命令
3. 观察（Observe）：把执行结果喂回上下文，进入下一轮
循环意味着自主性：
- 步数不预先写死：简单任务转一圈，复杂任务转几十圈
- 路径不预先写死：模型可中途换工具、换策略、回头重来
- 循环也是成本与风险所在：转多了烧 token，转偏了做错事
3、Agent 的四大构件
把循环撑起来的是四个构件：大脑、工具、记忆、规划。任何 Agent 框架无论怎么包装，都是在组合这四样。
四大构件：
- 大脑（LLM）：负责理解、推理与决策；接哪家模型只改一行参数（LiteLLM 这类网关因此成为基建）
- 工具（Tools）：代理的"手脚"——搜索、代码执行、数据库、文件系统；MCP 协议让工具可以跨代理复用
- 记忆（Memory）：短期记忆是当前会话的工作上下文，长期记忆跨会话沉淀偏好与知识
- 规划（Planning）：把大目标拆成子步骤，必要时先写计划再执行、执行中再修订
构件对应到本系列介绍过的工具：
- 大脑接入：LiteLLM 统一 100+ 模型；Hugging Face 是模型底座
- 工具生态：qmd 把本地知识变成可检索工具；Page Agent 自己就是"操作网页"的工具
- 记忆治理：Headroom 压缩对话历史，本质是在管短期记忆的成本
- 规划与编排：LangGraph 的图、Agno 的人工审批、PocketFlow 的节点循环，都是规划的不同形态
4、Agent 与 Workflow 的区别
最容易被混淆的一对概念：工作流的步骤是人写死的，Agent 的步骤是模型临场决定的。
对比要点：
- Workflow（工作流）：预先编排好的固定管线——先 A 再 B，条件走 C；确定性强、可测试、成本可控
- Agent（代理）：只给目标与工具，路径由 LLM 循环决定；灵活、能应对未知，但不确定性与成本更高
- 判断口诀：步骤能否提前写死？能，用工作流；不能，才上 Agent
两者常常组合出现：
- 真实系统多为混合体：外层是工作流（固定阶段），某一步内嵌 Agent（自主决策）
- LlamaIndex 的查询引擎是典型工作流；LangGraph 的条件边让你在同一张图里两者混用
- PocketFlow 把这一点推到极致：一个 100 行的图内核，既能拼工作流也能拼 Agent
5、Agent 的常见形态
按"操作对象"分类，当下最活跃的四类 Agent 一目了然。
四类形态：
- 编码代理：在代码库里读写文件、跑测试、提 PR——Claude Code、Cursor、Devin 是代表
- GUI 代理：操作图形界面——网页侧有 Page Agent（读 DOM 操作页面），手机侧有 Android CLI 的截图定位方案
- 知识代理：围绕私有数据检索问答——WeKnora 的 ReAct 代理、GraphRAG 增强的问答都属此类
- 通用助理：多工具、长流程的个人助理，如各类 Deep Agent 实现（规划、派子代理、用文件系统）
多代理系统：
- 单个代理能力有限时，多个代理分工协作：主管分派、专家执行、评审把关
- PocketFlow Cookbook 的 Multi-Agent、Supervisor、Debate 教程就是三种经典编队
- 代理之间还需要对话协议——A2A 让代理互调，MCP 让代理统一挂工具
6、从框架到平台：Agent 的工程化
会写循环只是开始，把 Agent 做成可靠的生产系统需要一整层工程。
工程化需求与对应方案：
- 编排控制：LangGraph 用图管理循环与分支；PocketFlow 用最小内核实现同样概念
- 平台运营：Agno 把代理跑成服务，附 API、多租户、审计；Dify 用可视化画布降低门槛
- 上下文治理：长循环的对话历史会爆炸，LLMLingua 与 Headroom 负责把上下文压下来
- 可观测与评测：LangSmith、Langfuse 追踪每一步；没观测的 Agent 等于盲飞
- 安全护栏：高风险动作前人工审批（LangGraph 的 interrupt、Agno 的 human approval）
工程化要点：
1. 先跑通循环，再补记忆与规划，最后上平台能力——顺序别颠倒
2. 给循环设步数与成本上限，防止代理打转烧钱
3. 高危工具（删除、支付、发送）必须挂人工确认
7、什么时候需要 Agent
Agent 不是万能药，选型前先过三问。
三问判断：
1. 步骤能否提前写死？能写死就用工作流，更便宜更稳
2. 失误的代价多大？低危场景（查询、草稿）适合放手；高危场景要么不上要么加审批
3. 任务是否真的多步？一次模型调用就能答的，加循环纯属浪费
适合与不适合：
- 适合：开放式编码任务、跨系统数据操作、需要边看结果边调整的探查型任务
- 不适合：固定报表、单轮问答、强合规流程——工作流与普通调用更合适
- 降级思路：能工作流就工作流，局部再嵌 Agent，别上来就全自主
8、总结
Agent 是以 LLM 为大脑、以工具为手脚、以记忆为上下文、以规划为路径的自主执行系统：内核是"思考-行动-观察"的 ReAct 循环，特征是路径由模型临场决定而非人预先写死。它与 Chatbot 的区别在"会做"，与工作流的区别在"自主"；四大构件（大脑、工具、记忆、规划）撑起循环，多代理与 A2A、MCP 让它们成建制协作。
理解 Agent 的最好路径：先用 PocketFlow 的一百行读懂循环的本质，再看 LangGraph 学编排、Agno 学平台化，配合 LiteLLM、LLMLingua、Headroom 把成本治理住。判断需求时记住三问——步骤能否写死、失误代价多大、是否真多步。对于要在 AI 应用上做技术决策的人，把"什么是 Agent"想透，是抵御概念泡沫、做出正确选型的必要基本功。
