只会聊天不够用？Agent 如何让 LLM 能做事、会思考、能修正

LLM 只能你问它答，只能生成文本。但当你需要它查数据库、调 API、发邮件、根据结果自动调整策略——纯 LLM 做不到。

你需要 Agent（智能体）：让模型从”会说话”升级为”能做事、会思考、能修正”。

Agent 通过感知 → 规划 → 行动 → 反馈的闭环，调用工具、自主决策、根据执行结果调整，直到完成任务。本篇解析 Agent 的本质、核心构成和生命周期，帮你理解如何构建完整的 Agent 系统。

---

📋 一、Agent 的本质 — 执行 + 决策 + 反馈 的闭环系统

1.1 什么是 Agent？

Agent（智能体） 是一个能够在环境中自主感知、规划、行动、反馈的智能系统。

与传统 LLM 不同，Agent 不仅能够理解和生成文本，还能够：

• 调用工具：执行实际的操作（如调用 API、查询数据库、操作文件）
• 自主决策：根据当前状态和目标，决定下一步行动
• 持续学习：根据执行结果调整策略，直到完成任务

一个真正的 Agent，是一个能在 环境 (Environment) 中工作的系统，包含四个核心能力：

• 感知 (Perception) —— 接收用户输入 + 工具／环境反馈 (Observation)
• 规划 (Planning) —— 使用 LLM 分解问题，决定下一步行动
• 行动 (Action) —— 调用外部工具 / API / 脚本 / 系统接口
• 记忆 (Memory) —— 保存历史信息 / 结果，以利长期任务或上下文连贯

核心公式：

Agent = LLM (大脑) + Tools (手脚) + Memory (记忆) + Loop (自主循环)

形象理解：

• LLM = 大脑，负责思考和决策
• Tools = 手脚，负责执行具体操作
• Memory = 记忆，保存历史经验和知识
• Loop = 循环，持续感知→规划→行动→反馈

组成	核心功能	对应技术	在前几篇中的基础
Perception (感知)	接收输入／反馈	Prompt + Observation	第2篇：Prompt 工程
Planning (规划)	分析任务／选择工具／生成执行方案	CoT / ReAct / Prompt Engineering	第3篇：ReAct 范式
Action (行动)	执行具体操作（API／脚本／文件／数据库）	Function Calling / Tool Call	第3篇：结构化输出
Memory (记忆)	存储历史状态／结果／知识／用户偏好	Context 管理 + 外部数据库/RAG	第2篇：Context Window + 第4篇：RAG

1.2 为什么需要 Agent？LLM 的局限

纯 LLM 的四个天花板：

局限	表现	影响
被动响应	只能在你问它时才回应	无法主动执行任务
文本生成	只能生成文本，无法执行操作	无法调用 API、操作数据库、发送邮件等
单次交互	每次对话独立，无法持续执行	无法完成需要多步骤的复杂任务
无状态	无法记住历史操作和结果	无法基于历史经验优化策略

Agent 的解决方案：

Agent 将 LLM 从”文本生成器”升级为”任务执行器”，让 LLM 能够自主分解任务、调用工具、根据反馈调整策略，直到完成任务。

1.3 LLM vs Agent — 本质上的区别

维度	传统 LLM	Agent (智能体)
主动性	被动（只回应 Prompt）	主动（可以自主决定下一步）
目标 & 任务	单次生成 / 回答	多步、复杂任务 + 行动 + 环境交互
与外界交互能力	仅限文本输入/输出	可以调用工具、API、修改状态、操作系统等
机制	自回归文本生成	决策–执行–观察–反馈的循环（Agentic Loop）
记忆能力	仅限 Context Window	短期记忆 + 长期记忆 + 外部存储

实际对比示例：

❌ 传统 LLM：
用户："帮我查询用户数据，生成报告，然后发送邮件"
LLM："我可以帮你写查询 SQL、报告模板和邮件内容，但无法实际执行这些操作"

✅ Agent：
用户："帮我查询用户数据，生成报告，然后发送邮件"
Agent：
1. Thought: 需要先查询数据库
   Action: query_database(sql="SELECT * FROM users")
   Observation: [查询结果...]
2. Thought: 查询成功，现在生成报告
   Action: generate_report(data=[查询结果])
   Observation: [报告已生成...]
3. Thought: 报告已生成，现在发送邮件
   Action: send_email(to="user@example.com", attachment="report.pdf")
   Observation: [邮件已发送]
Final Answer: 任务完成，已查询数据、生成报告并发送邮件

💡 核心理解：一个 Agent，不只是”会说话”的模型，而是”会做事、有记忆、能反馈、能修正”的系统。

---

♻️ 二、Agent 的生命周期：Agentic Loop（自主循环）

Agent 不是”问一次答一次”，而是不停转的循环：感知 → 规划 → 行动 → 反馈 → 再感知 → 再规划……

2.1 Agentic Loop 流程

四个步骤构成一个闭环：

┌─────────┐
│ Observe │ ← 感知：接收输入和反馈
└────┬────┘
     │
     ↓
┌─────────┐
│  Plan   │ ← 规划：决定下一步行动
└────┬────┘
     │
     ↓
┌─────────┐
│  Act    │ ← 行动：执行工具调用
└────┬────┘
     │
     ↓
┌─────────┐
│Feedback │ ← 反馈：获取执行结果
└────┬────┘
     │
     └────→ 继续循环，直到任务完成

详细步骤：

1. Observe (感知)

   • 接收用户指令或新的输入
   • 接收上一步工具／系统的返回结果 (Observation)
   • 更新当前状态和上下文

2. Plan (规划)

   • LLM 根据当前上下文 + 记忆，分析任务
   • 决定下一步要做什么 (Thought)
   • 选择要调用的工具和参数

3. Act (执行)

   • 调用工具 / API / 脚本 / 系统命令 (Action)
   • 执行具体的操作（如查询数据库、调用 API、操作文件）

4. Feedback (反馈)

   • 获取工具或系统执行结果 (Observation)
   • 更新记忆 / 状态
   • 判断是否完成任务，或继续下一步

5. Loop Continue：重复步骤 1-4，直至满足最终目标或触发终止条件

2.2 为什么要循环 (Loop)

“生成月度报告并发送给团队”——需要查库、分析、生成、发邮件。单次交互的 LLM 做不到，它只能输出一次。

循环让 Agent 可以：查完库→看结果→再决定怎么分析→再生成→再发。多步骤任务、动态调整、某步失败可重试——都靠这个闭环。

1. 多步骤任务：可以分解复杂任务，一步步完成
2. 动态调整：环境是动态的，需要根据中间结果不断调整决策
3. 错误恢复：如果某一步失败，可以调整策略重试
4. 持续优化：可以根据执行结果优化后续步骤

实际示例：

任务：查询用户数据并生成报告

循环1：
  Thought: 需要先查询数据库获取用户数据
  Action: query_database(sql="SELECT * FROM users WHERE date='2025-12'")
  Observation: 查询成功，返回 1000 条记录

循环2：
  Thought: 数据已获取，现在需要分析数据并生成报告
  Action: generate_report(data=[1000条记录], format="PDF")
  Observation: 报告生成成功，文件路径：/reports/monthly_2025-12.pdf

循环3：
  Thought: 报告已生成，任务完成
  Final Answer: 已成功查询用户数据并生成报告

💡 关键理解：Agent 的闭环机制使它不仅能推理，还能”做事情 + 检查结果 + 再做”，这是 Agent 与 LLM 的本质区别。

2.3 循环终止条件 (Termination Criteria)

为了防止无限循环或失控，必须设定合理的终止条件：

终止条件	说明	示例
目标达成判断	Agent 自己判断任务已完成	“报告已发送”、”数据已更新”
资源限制	最大步数、最大时间、最大 API 调用次数	最多执行 10 步、最多 5 分钟
错误阈值	连续失败次数达到上限	连续失败 3 次 → 终止并返回错误日志
人工干预 / 审批	对于高风险操作需要用户确认	删除数据、修改系统配置需要用户确认

实现示例：

# 终止条件检查（伪代码）

def should_terminate(agent_state):
    # 1. 目标达成
    if agent_state.is_goal_reached():
        return True, "任务已完成"
    
    # 2. 资源限制
    if agent_state.steps >= MAX_STEPS:
        return True, "达到最大步数限制"
    if agent_state.elapsed_time >= MAX_TIME:
        return True, "达到最大时间限制"
    if agent_state.api_calls >= MAX_API_CALLS:
        return True, "达到最大 API 调用次数"
    
    # 3. 错误阈值
    if agent_state.consecutive_failures >= MAX_FAILURES:
        return True, "连续失败次数过多"
    
    # 4. 人工干预
    if agent_state.requires_approval and not agent_state.user_approved:
        return True, "等待用户审批"
    
    return False, None

🔹 实战提示：合理设置终止条件，既能保证任务完成，又能防止资源浪费和安全风险。

---

🧱 三、Agent 的关键模块：构建一个完整 Agent 系统

一个 Agent 系统通常包含：规划器（决定做什么）、工具（执行操作）、执行器（调用工具）、记忆（存历史）。

3.1 🧠 Planner (规划器) — LLM + Prompt 控制

职责：

• 将当前任务 + 环境状态 + 记忆 / 历史信息 编成 Prompt
• 使用 Prompt 指导 LLM 输出 结构化 Thought + Action

关键能力：

• Prompt Engineering：包括角色定义、格式约束（见第3篇）
• Function Calling：支持工具调用输出（见第3篇：结构化输出）

工作原理：

# Planner 工作流程（伪代码）

def plan(memory, task, available_tools):
    # 1. 构建 Prompt
    prompt = f"""
    你是一个任务规划助手。
    
    当前任务：{task}
    
    历史记录：
    {memory.get_history()}
    
    可用工具：
    {format_tools(available_tools)}
    
    请分析任务，决定下一步行动。
    输出格式：
    Thought: [你的思考]
    Action: [工具名(参数)]
    """
    
    # 2. 调用 LLM
    response = llm.generate(prompt)
    
    # 3. 解析输出
    thought, action = parse_response(response)
    
    return thought, action

3.2 🛠️ Tools & Executor (工具与执行器)

工具 (Tool)：任何外部函数 / API / 模块 / 脚本 / RAG 查询 / 系统接口 —— 让 Agent 能做真实有用的事情。

工具类型示例：

• API 调用：调用外部 API（如天气查询、翻译服务）
• 数据库操作：查询、更新数据库
• 文件操作：读取、写入、删除文件
• 系统命令：执行系统命令（需谨慎）
• RAG 查询：检索知识库（见第4篇）

工具规范 (Tool Schema)：必须为每个工具定义清晰输入 / 输出格式（最好使用 JSON Schema），让 Planner 输出可被正确解析。

示例：

# 工具定义（JSON Schema）

tool_schema = {
    "name": "query_database",
    "description": "查询数据库",
    "parameters": {
        "type": "object",
        "properties": {
            "sql": {
                "type": "string",
                "description": "SQL 查询语句"
            }
        },
        "required": ["sql"]
    },
    "returns": {
        "type": "array",
        "description": "查询结果"
    }
}

执行器 (Executor)：负责实际执行工具调用，并捕获返回结果 (Observation)，包括成功输出或错误信息。

执行流程：

# Executor 工作流程（伪代码）

def execute(tool_name, args):
    try:
        # 1. 验证参数
        validate_args(tool_name, args)
        
        # 2. 执行工具
        result = tools[tool_name](**args)
        
        # 3. 返回结果
        return {
            "success": True,
            "result": result
        }
    except Exception as e:
        # 4. 错误处理
        return {
            "success": False,
            "error": str(e)
        }

💡 实战提示：

• 工具设计：尽可能将工具设计得简单、接口清晰、失败可控
• 错误处理：工具应该返回明确的错误信息，帮助 Agent 调整策略
• 安全性：对于危险操作（如删除、修改），需要额外的权限检查

3.3 💾 Memory / Context Manager (记忆管理器)

Agent 需要同时处理 短期记忆 与 长期记忆：

短期记忆 (Short-term Memory)

定义：当前 Loop 的历史（Thoughts, Actions, Observations），用于保持上下文连贯。

存储内容：

• 当前任务的执行历史
• 最近几步的思考过程
• 工具调用的输入和输出

管理方式：

• 存储在 Context Window 中
• 当 Context Window 满时，进行摘要压缩

示例：

# 短期记忆结构（伪代码）

short_term_memory = {
    "task": "查询用户数据并生成报告",
    "history": [
        {
            "step": 1,
            "thought": "需要先查询数据库",
            "action": "query_database",
            "observation": "查询成功，返回 1000 条记录"
        },
        {
            "step": 2,
            "thought": "数据已获取，现在生成报告",
            "action": "generate_report",
            "observation": "报告生成成功"
        }
    ]
}

长期记忆 (Long-term Memory)

定义：通用知识库、用户偏好、历史任务结果、RAG 存储。

存储内容：

• 用户偏好和习惯
• 历史任务的成功经验
• 知识库（通过 RAG 存储）
• 常见错误和解决方案

管理方式：

• 存储在外部数据库或向量库中
• 需要时检索相关记忆

示例：

# 长期记忆结构（伪代码）

long_term_memory = {
    "user_preferences": {
        "report_format": "PDF",
        "email_recipients": ["team@example.com"]
    },
    "knowledge_base": {
        "type": "RAG",
        "vector_db": "pinecone",
        "embeddings": [...]
    },
    "task_history": [
        {
            "task": "生成月度报告",
            "date": "2025-11",
            "success": True,
            "steps": 3
        }
    ]
}

记忆压缩与管理

因为 Context Window / Token 限制（见第2篇），需要对过长历史做 摘要 / 压缩 或外部存储。

压缩策略：

• 摘要：将多步历史压缩为摘要
• 关键信息提取：只保留关键信息
• 外部存储：将旧历史移到外部数据库

示例：

# 记忆压缩（伪代码）

def compress_memory(history):
    if len(history) > MAX_HISTORY_LENGTH:
        # 提取关键信息
        summary = llm.summarize(history)
        
        # 保存到长期记忆
        long_term_memory.save(summary)
        
        # 只保留最近几步
        return history[-5:]
    return history

3.4 完整 Agent 系统架构示例

将 Planner、Tools、Executor、Memory 组合起来，形成一个完整的 Agent 系统：

# 完整 Agent 系统（伪代码）

class Agent:
    def __init__(self, llm, tools, memory):
        self.llm = llm
        self.tools = tools
        self.memory = memory
        self.executor = Executor(tools)
        self.planner = Planner(llm)
    
    def run(self, task):
        """运行 Agent，执行任务"""
        steps = 0
        
        while steps < MAX_STEPS:
            # 1. 检查终止条件
            if self.should_terminate():
                break
            
            # 2. 规划（Plan）
            thought, action = self.planner.plan(
                task=task,
                memory=self.memory,
                available_tools=self.tools.list()
            )
            
            # 3. 检查目标是否达成
            if self.is_goal_reached(thought):
                return {"success": True, "result": thought}
            
            # 4. 执行（Act）
            tool_name, args = self.parse_action(action)
            observation = self.executor.execute(tool_name, args)
            
            # 5. 更新记忆（Memory）
            self.memory.update(
                thought=thought,
                action=action,
                observation=observation
            )
            
            steps += 1
        
        return {"error": "max steps exceeded"}

# 使用示例
agent = Agent(
    llm=gpt4,
    tools=[query_db, generate_report, send_email],
    memory=Memory()
)

result = agent.run("查询用户数据并生成报告")

关键组件协作：

用户任务
   ↓
Planner (规划) ← 使用 LLM + Prompt
   ↓
Executor (执行) ← 调用 Tools
   ↓
Memory (记忆) ← 存储历史
   ↓
反馈循环 → 继续规划

---

🔍 总结：为什么构建 Agent 很重要

Agent 真正将 LLM 从”文本生成器”推向”任务执行器”，具有以下核心价值：

Agent 的核心价值

价值	说明	实际应用
自动化复杂任务	不仅是”问答/生成文本”，而是”查资料 + 处理 + 输出 + 执行”	自动报告生成、数据分析、流程自动化
可追踪 & 可审计	每一步都有工具调用、Observation、Memory 记录	便于审计、调试、问题排查
持续能力 & 演化	通过 Memory 和工具库，可以重复利用已有能力，也能扩展新能力	学习用户习惯、优化任务执行
从辅助到主动	不只是被动回应用户，而是主动完成任务	自动监控、自动响应、主动优化

Agent 的应用场景

1. 自动化测试

任务：自动生成测试用例并执行
Agent：
1. 分析需求文档
2. 生成测试用例
3. 执行测试
4. 生成测试报告

2. 数据分析

任务：分析用户行为数据
Agent：
1. 查询数据库获取数据
2. 数据清洗和处理
3. 数据分析和可视化
4. 生成分析报告

3. 内容生成

任务：生成技术文档
Agent：
1. 检索相关技术资料（RAG）
2. 整理和总结
3. 生成文档
4. 格式化和发布

💡 核心理解：Agent 是 LLM 从”会说话”到”能做事 + 会思考 + 会改”的演化，是构建真正智能自动化系统的基础。

---

📚 延伸阅读（含可直接访问链接）

以下资源按主题分类，每个资源都附有简要说明，帮助你选择合适的学习材料。

🔄 ReAct 范式

• ReAct: Synergizing Reasoning and Acting in Language Models（ReAct 原始论文）：ReAct 范式的开创性论文，展示了如何结合推理和行动。必读论文，适合所有读者。

• ReAct 项目主页：ReAct 的官方项目主页，包含示例 Prompt 模板和代码。强烈推荐，适合想实践 ReAct 的开发者。

📖 Agent 系统综述

• Adaptive and Resource‑efficient Agentic AI Systems（Agent 系统综述）：2025 年的 Agent 系统最新综述。适合想了解 Agent 系统最新进展的读者。

• A Survey on Agentic Multimodal Large Language Models（多模态 Agent 综述）：多模态 Agent 的全面综述。适合想了解多模态 Agent 的读者。

🛠️ Agent 框架与实践

• LangChain Agents（LangChain Agent 文档）：LangChain 的 Agent 文档，包含完整示例。强烈推荐，适合想快速上手的开发者。

• LlamaIndex Agents（LlamaIndex Agent 文档）：LlamaIndex 的 Agent 文档。适合使用 LlamaIndex 的开发者。

• AutoGPT 项目：AutoGPT 的开源项目，展示了完整的 Agent 实现。适合想学习 Agent 实现的开发者。

🔧 工具调用与 Function Calling

• OpenAI Function Calling（OpenAI 工具调用）：OpenAI 的 Function Calling 官方文档。必读，适合使用 OpenAI API 的开发者。

• Anthropic Tool Use（Claude 工具使用）：Anthropic 的工具使用文档。适合使用 Claude 的开发者。

• LLM Tool Calling Best Practices（工具调用最佳实践）：工具调用的最佳实践指南。适合想优化工具调用的开发者。

💾 Memory 管理

• LangChain Memory（LangChain 记忆管理）：LangChain 的记忆管理文档。适合需要实现记忆功能的开发者。

• Vector Memory for Agents（Agent 向量记忆）：LlamaIndex 的向量记忆实现。适合需要长期记忆的开发者。

🇨🇳 中文资源

• Agent 系统设计指南（中文）：Agent 系统设计的中文指南。适合中文读者。

---

🔔 系列说明

本文是《🧠 LLM/Agent 从入门到精通：告别浅尝辄止》系列第 6 篇。上一篇：GPT-4、Claude、Llama 怎么选？模型选型避坑指南。下一篇：Agent 怎么”想”和”做”？ReAct 决策引擎代码级拆解。