一篇文章告诉你什么是agent

小裴coding

352人浏览 · 2026-05-22 17:46:27

小裴coding · 2026-05-22 17:46:27 发布

前言

前两章讲了大模型的底层逻辑，也讲了怎么写好Prompt。到现在，你已经知道大模型是个“超级大脑”，能理解意图、会逻辑推理、能生成高质量内容。

但它只有嘴、没有手：

它能说“你应该查一下慢查询日志”，但它自己查不了
它能分析“这个API可能是瓶颈”，但它发不了报警、关不了开关、也打不开任何一个文件

学会了Prompt，你能精准控制大模型的输出，但有一个问题Prompt解决不了：就算大模型能给出完美的分析，它依然没法主动去查数据库、发通知、调用API。“说得再好”，也只是在说。

这就是Agent要解决的问题：让大模型从“只能说”变成“真能干”。

一、什么是Agent？

Agent（智能体），是一个以大模型为“大脑”，能自主感知环境、做出决策、调用工具、完成多步骤任务的程序。

拆开来看几个关键词

关键词	含义
自主	不需要人在每一步发指令。你给它一个目标，它自己判断下一步做什么
多步骤	一个任务可能要走5步、10步，Agent自己把这些步骤串起来
工具调用	调用真实的函数，查数据库、搜网页、发通知、写文件，不只是“说说”，而是真的去做

用一个类比帮你建立直觉

大模型单独使用：相当于一个坐在椅子上只会出主意的顾问。你问什么他答什么，但他不会起身去做任何事
Agent：给这个顾问配了一双手。他不仅能给建议，还能拿起电话查数据、发邮件、去仓库核实情况，然后根据新信息继续推进

一句话总结：Agent = 大模型（大脑）+ 工具（双手）+ 执行循环（思考-行动-观察-再思考）

二、为什么需要Agent？

之前我们说过大模型的三大短板：

短板	说明
❌ 没有执行能力	只能生成文字，不能操作外部系统
❌ 知识有截止日期	不知道最新数据，看不到你的私有系统
❌ 没有持久记忆	每次调用对它都是全新的，不能积累任务中间状态

举一个真实的OnCall场景

「数据库今晚23:00报警，帮我查清楚原因」

大模型单独面对：只能说“可能是慢查询、可能是连接池满、可能是锁争用……”——它根本拿不到你的报警日志，查不了慢查询记录，也看不到当时的系统状态。没有Agent，大模型只是个猜测机
传统脚本/Workflow：写死的逻辑，“如果CPU>80%就发警报，如果连接超时就重启服务”。遇到没预料到的情况，它们不知道该怎么办

Agent的价值在于：把大模型的灵活推理能力和真实工具的执行能力结合在一起，让系统能处理那些你没法提前穷举所有情况的复杂任务。

三、Agent的核心组成

Agent由四个组件构成，缺一不可：

1. 大模型（LLM）—— 大脑

负责理解任务、分析当前状态、决定下一步做什么。所有的“推理”都在这里发生：该查什么、查完之后怎么解读、下一步往哪走，全是大模型来判断。

2. 工具（Tools）—— 双手

一个个可以被调用的真实函数：查数据库、调用搜索引擎、读写文件、发通知、调用API……

大模型告诉Agent“调用这个工具、传这些参数”，代码层面真正去执行。工具的结果会返回给大模型，供它继续推理。

大模型不“直接”操作外部系统，它通过工具来“动手”。

3. 记忆（Memory）—— 记事本

类型	说明
短期记忆	当前任务里的对话历史 + 每次工具调用的结果，存在context window里
长期记忆	跨会话需要记住的信息，存在外部数据库，需要时检索出来注入context

为什么需要记忆？多步骤任务里，每一步的结果都是下一步判断的依据。没有记忆，每步都是“从零开始”，Agent根本没法串联多步骤任务。

4. 执行循环（Loop）—— 节拍器

Agent的“引擎”。不断重复“思考→行动→观察”这个循环，直到任务完成。

没有这个循环，Agent只是一次性的问答，无法串联多步骤。这个循环是Agent和普通大模型调用之间最根本的区别。

四、Agent是怎么工作的？ReAct循环

目前最主流的Agent工作范式叫做 ReAct，全称 Reasoning + Acting：

推理（Think）→ 行动（Act）→ 观察（Observe）→ 再推理……

用一个完整的OnCall场景走一遍

json

用户: 帮我调查今晚23:00的数据库报警

[第1轮]
Think: 需要先拿到具体的报警详情
Act: 调用 get_alarm_details(time="23:00")
Observe: 返回"连接数突增，连接池耗尽，持续8分钟后自动恢复"

[第2轮]
Think: 连接数突增，需要看是哪些查询造成的
Act: 调用 query_slow_log(timerange="22:50-23:10")
Observe: 发现3条全表扫描的慢查询，来自同一个用户ID

[第3轮]
Think: 根因已经清楚，生成分析报告
Act: 输出最终分析结论 (Final Answer)

几个关键机制

机制	说明
结果回流	每一轮的工具调用结果都会追加到context window里，大模型下一轮能“看到”所有历史
动态决策	每一步该怎么走，是大模型实时推理出来的，不是你提前写好的
何时停止	大模型判断任务已完成时输出“最终答案”，或者达到预设的最大轮数上限

这就是“自主”的含义：你给任务目标，它自己决定怎么走到终点。

五、Agent的另一种工作模式：Plan and Execute

ReAct很好用，但有一个先天的弱点。

ReAct的三个问题

问题	说明
长任务容易「迷路」	跑了8轮之后，context window里堆满历史记录，大模型容易偏离最初目标
容易绕弯路	没有全局规划，每步只看眼前，走了5步才发现方向不对，只能回头重来
token消耗滚雪球	每轮都要带完整对话历史，步骤越多，每轮token消耗越高

Plan and Execute 核心思路

先让大模型把整个任务规划成一份清单，再逐步按清单执行，而不是走一步看一步。

用出行来类比两种模式

模式	类比
ReAct	边开车边看导航：每走到一个路口才决定下一步拐哪。灵活，但容易绕路
Plan and Execute	出发前规划好完整路线：走哪条路、哪里转弯、预计几点到全部规划好，再出发

Plan and Execute 的两个阶段

第一阶段：Planner（规划阶段）

大模型拿到任务，先不调任何工具，专注做一件事：把任务完整拆解成一份有序的子任务清单。

text

用户: 「帮我调查今晚23:00的数据库报警，写一份完整的故障分析报告」

Planner输出的计划:
步骤1: 获取23:00报警的详细信息（报警类型、持续时间、影响范围）
步骤2: 查询报警时间段内的慢查询日志，定位异常SQL
步骤3: 查询报警时间段内的数据库连接数、CPU、内存指标
步骤4: 关联步骤2和步骤3的结果，分析根因
步骤5: 生成完整的故障分析报告，包含时间线、根因和改进建议

第二阶段：Executor（执行阶段）

计划有了，开始逐步执行。每个步骤可以是一次简单的工具调用，也可以是一个小的ReAct循环。

text

执行步骤1:
  → 调用 get_alarm_details(time="23:00")
  ← 返回「连接数突增，连接池耗尽，持续8分钟后自动恢复」

执行步骤2:
  → 调用 query_slow_log(timerange="22:50-23:10")
  ← 发现3条全表扫描的慢查询，来自同一个用户ID

执行步骤3:
  → 调用 get_db_metrics(timerange="22:50-23:10")
  ← CPU正常，连接数峰值达到上限500，内存无异常

执行步骤4:
  → 大模型综合步骤2、3结果进行分析
  ← 结论：慢查询导致连接长时间占用，连接池耗尽触发报警

执行步骤5:
  → 生成故障分析报告
  ← 完整报告输出，任务完成

一个重要机制：Re-planning（重新规划）

执行中途如果遇到了计划没预料到的情况（比如步骤2查不到慢查询，但发现了大量锁等待），Executor可以把这个新信息反馈给Planner，重新生成后续步骤的计划，而不是一条路走到黑。

流程图

text

用户任务
    ↓
[Planner] 大模型一次性生成完整计划
    ↓
执行计划 = [步骤1, 步骤2, 步骤3, 步骤4, 步骤5]
    ↓
[Executor] 按顺序执行每个步骤
    ↓
步骤1 调工具 → 结果
步骤2 调工具 → 结果
步骤3 调工具 → 结果
    ↓ (遇到意外？)
    → 触发 Re-planning，重新调整后续计划
    ↓
最终结果汇总 + 输出给用户

六、ReAct vs Plan and Execute：怎么选？

对比维度	ReAct	Plan and Execute
决策时机	每一步实时决策	开始前一次性规划
全局视野	弱（只看当前这步）	强（提前看到全貌）
灵活性	强（随时根据结果调整）	弱（计划一旦生成，调整成本高）
适合任务步骤	少（3步以内）	多（5步以上的复杂任务）
token消耗	随步数线性增长，后期很贵	规划阶段集中消耗，执行阶段较轻
实现难度	低（结构简单）	中（需要管理计划状态和re-planning逻辑）

简单记忆

任务步骤少、目标模糊、需要随机应变 → 用ReAct
任务步骤多、目标明确、需要全局把控 → 用Plan and Execute

生产系统最常见的搭配

外层 Plan and Execute + 内层 ReAct

用规划保证大方向不跑偏，用ReAct保证每个子任务执行时足够灵活。

七、Agent vs Workflow：什么时候用哪个？

这是初学者最容易搞混的问题，也是实际选型最关键的判断。

维度	Workflow	Agent
决策者	你（写死的代码逻辑）	大模型（实时推理）
执行路径	固定	动态
适合场景	步骤明确、重复性高	任务开放、情况多变
可预测性	高	低
成本	低	高（多轮LLM调用）

两者没有高下之分，适合不同的场景

流程能写清楚、步骤是固定的 → 优先用Workflow，更稳、更省钱、更可预期
任务是开放式的、需要根据中间结果动态决策 → 用Agent

最常见的实际架构

Workflow做骨架，Agent负责其中需要判断的环节

两者结合，不是非此即彼。

八、Agent开发的真实挑战

学完了怎么用，也要知道坑在哪。

挑战1：幻觉传导

大模型在第一步做出错误判断，后续所有步骤都建立在这个错误假设上，最终结论可能完全跑偏。单步幻觉在普通问答里代价不大，但在Agent的多步骤链条里，第一步的错误会被逐步放大。

应对：工具结果要可验证；对高风险操作（写入数据库、发通知、执行脚本）加人工确认步骤。

挑战2：工具调用失败

工具不是百分之百可靠：网络超时、返回格式异常、权限不足……Agent没有合适的fallback设计，一个工具失败就可能卡死或走偏。

应对：每个工具都要有明确的错误返回格式；System Prompt里说清楚“如果工具返回错误应该怎么处理”。

挑战3：成本和速度

每一轮循环都是一次LLM调用，一个任务跑10轮，消耗是单次问答的10倍。用Agent是有代价的。

应对：合理设置最大循环轮数上限；能用Workflow解决的不要用Agent。

挑战4：循环风险

Agent可能陷入“查了A，发现需要查B，查完B又觉得需要查A……”的无效循环。

应对：设置最大迭代次数，超出就强制结束；让大模型在每步推理时明确判断“当前信息是否已经足够得出结论”。

九、一个真实Agent的样子（伪代码）

说了这么多，Agent代码层面长什么样？这是一个极简的Agent骨架：

python

def run_agent(user_message):
    messages = [
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": user_message},
    ]
    
    while True:
        # 1. 调用大模型，让它思考下一步
        response = llm.call(messages)
        
        # 2. 如果大模型说"我完成了"，退出循环
        if response.is_final_answer:
            return response.content
        
        # 3. 否则，执行大模型指定的工具
        tool_result = execute_tool(response.tool_name, response.tool_args)
        
        # 4. 把工具结果追加到messages，供下一轮参考
        messages.append({"role": "tool", "content": tool_result})

核心逻辑就4步

调大模型，让它决策
判断是否完成，完成就退出
没完成就执行工具，把结果追加进messages
带着新结果再调大模型，进入下一轮

真实系统会在这个基础上加：错误处理、最大轮数限制、日志记录、人工审批步骤等。但骨架就这些，不复杂。读懂了这段伪代码，Agent的核心机制就装进脑子里了。

十、总结

整理一下这一章的核心认知：

问题	答案
Agent是什么？	以大模型为大脑，能自主调用工具、完成多步骤任务的程序。让大模型从“只能说”变成“真能干”
核心组成	大模型（大脑）+ 工具（双手）+ 记忆（记事本）+ 执行循环（节拍器）
核心机制	Think→Act→Observe循环，每轮工具结果都回流给大模型，直到完成
和Workflow的本质区别	决策者不同。Workflow是你提前写好的代码逻辑，Agent是大模型实时推理

后续章节预告

章节	内容	与Agent的关系
Function Calling	大模型怎么“告诉”代码层调用哪个工具	Agent工具调用的底层机制
RAG	Agent怎么访问私有知识库	本质上是一种特殊的工具
MCP	工具的标准化协议	让Agent能接入更广泛的生态工具