最近 “Agent” 这个词被频繁提起. 有人说它是 LLM 的下一站, 有人说它只是套了壳的脚本. 这篇文章想把这个词拆开讲清楚: Agent 到底是什么, 它和我们熟悉的 Chatbot, Workflow, RPA 有什么区别, 以及它现在能做什么, 不能做什么.

一句话定义

Agent 是一个能够感知环境, 自主决策, 并通过调用工具来完成目标的程序.

注意这里的三个关键词: 感知, 决策, 工具. 缺了任何一个, 它都不能被称为 Agent.

  • 只感知不决策 -> 那是传感器.
  • 只决策不行动 -> 那是聊天机器人.
  • 只行动不思考 -> 那是脚本.

Agent 的核心循环

几乎所有现代 Agent 都跑在同一个循环里, 通常被称为 ReAct Loop (Reason + Act):

观察 (Observe) -> 思考 (Think) -> 行动 (Act) -> 观察 (Observe) -> ...

具体来说:

  1. 观察: Agent 接收当前状态, 包括用户输入, 工具返回值, 环境反馈.
  2. 思考: 基于目标和当前状态, 推理下一步该做什么. 这一步通常由 LLM 完成.
  3. 行动: 调用一个工具 (Tool Call), 比如搜索网页, 读写文件, 执行命令.
  4. 回到观察: 把行动结果作为新的输入, 进入下一轮循环.

循环的终止条件可以是: 目标达成, 超出预算 (步数, token, 时间), 或者 Agent 自己判断无法继续.

Agent 的组成部分

把一个 Agent 拆开看, 通常包含四块:

1. 大脑 (LLM)

负责推理和决策. 当前主流选择是 GPT-4 系列, Claude 系列, Gemini 系列等具备 function calling 能力的模型. 大脑的质量直接决定了 Agent 的上限.

2. 工具 (Tools)

Agent 能调用的所有外部能力. 工具的设计是 Agent 工程里最关键的部分之一. 一个好的工具应该:

  • 名字和描述清晰, 让 LLM 知道什么时候该用.
  • 输入输出 schema 明确, 减少 LLM 的猜测成本.
  • 错误信息可读, 让 LLM 在失败时能自我修正.

常见的工具类型:

  • 信息获取: 搜索, 抓取网页, 查询数据库.
  • 文件操作: 读, 写, 编辑, 搜索.
  • 执行环境: 跑代码, 跑命令, 跑测试.
  • 外部服务: 发邮件, 发消息, 调 API.

3. 记忆 (Memory)

短期记忆通常就是当前对话的上下文窗口. 长期记忆需要外部存储, 比如向量数据库, KV 存储, 或者结构化的笔记文件. 记忆决定了 Agent 能不能跨会话工作.

4. 规划 (Planning)

简单 Agent 不需要显式规划, 走一步看一步. 复杂 Agent 会先生成一个计划, 再逐步执行, 中途根据反馈调整. 常见的规划模式包括 Plan-and-Execute, Tree of Thoughts, 以及多 Agent 协作.

Agent 和它的近亲们

名字 是否自主决策 是否调用工具 是否长期运行
Chatbot 否 否 否
Workflow 否 (流程预定义) 是 是
RPA 否 (步骤预定义) 是 是
Agent 是 是 是

差别的核心在于 谁来决定下一步做什么. Workflow 和 RPA 的下一步是开发者写死的, Agent 的下一步是模型在运行时推理出来的. 这带来了灵活性, 也带来了不确定性.

一个最小可运行的例子

下面是一个用伪代码写的最小 Agent, 帮助理解循环本身:

def run_agent(goal: str, tools: list, max_steps: int = 10):
    history = [{"role": "user", "content": goal}]

    for step in range(max_steps):
        # 思考: 让 LLM 决定下一步
        response = llm.chat(history, tools=tools)

        # 如果模型直接给出答案, 结束
        if response.finish_reason == "stop":
            return response.content

        # 否则执行工具调用
        for tool_call in response.tool_calls:
            result = execute_tool(tool_call)
            history.append({
                "role": "tool",
                "name": tool_call.name,
                "content": result,
            })

    return "超出步数限制, 任务未完成."

真实世界的 Agent 框架 (LangGraph, AutoGen, CrewAI 等) 都是在这个骨架上加更多控制: 错误处理, 状态机, 多 Agent 协作, 持久化, 观测等.

Agent 现在能做什么

  • 代码助手: Cursor, Claude Code, Kiro 这类工具, 在 IDE 里读代码, 改代码, 跑测试.
  • 浏览器自动化: 打开网页, 填表单, 抓数据, 完成预订.
  • 数据分析: 接到一份 CSV, 自己写代码, 出图, 写报告.
  • 客服与运营: 处理工单, 查订单, 发退款, 回邮件.
  • 科研助手: 读论文, 跑实验, 整理结果.

Agent 还做不好什么

诚实地说, 当前的 Agent 远不是 “通用助手”. 几个明显的短板:

  1. 长程任务容易跑偏. 步数一多, 误差累积, 后期开始幻想或者绕圈.
  2. 成本不可预测. 一个看似简单的任务, 可能跑出几十次工具调用.
  3. 对环境的鲁棒性差. 网页改个按钮, 工具改个参数, Agent 可能就卡住.
  4. 难以调试. 失败了不知道是模型的问题, 提示词的问题, 还是工具的问题.
  5. 安全边界模糊. 一个能执行命令, 能联网, 能读文件的 Agent, 一旦被恶意输入操控, 后果不小.

写给开发者的几条经验

如果你打算自己做 Agent, 有几点是反复踩坑后才学到的:

  • 先把工具做好, 再考虑模型. 工具的 schema 和错误信息, 比换更强的模型收益更大.
  • 限制循环预算. 步数, token, 时间, 至少卡一个, 不然账单会教你做人.
  • 让 Agent 可以观察自己. 把每一步的思考和行动记下来, 调试时是救命的.
  • 把不确定性留给模型, 把确定性留给代码. 能写死的逻辑就不要交给 LLM.
  • 小步验证. 别一上来就让 Agent 端到端跑一个复杂任务, 先跑三五步看看.

结语

Agent 不是魔法, 也不是噱头. 它是 “LLM + 工具 + 循环” 这个组合在工程上的自然演化. 它的能力边界正在快速扩张, 但工程上的难点也很真实. 与其纠结 “这是不是真的 Agent”, 不如关注一个更朴素的问题: 它有没有真的帮你完成事情.

如果有, 那它就是一个好 Agent.