什么是AI Agent

Agent是一个能自己决定下一步要做什么、并能真正执行并根据结果调整下一步的AI系统
只有满足自我决策、真实执行和动态调整三个特性的才能称作Agent，否则就是只会聊天的chatbot或只会按固定流程走的workflow

和普通LLM调用的差别

普通调用：

一次请求，一次响应。模型完全不知道回答后会发生什么，也不关系

Agent：

核心区别就在于循环。Agent不是一问一答，是想->做->看->再想的循环，直到任务完成或它判断无法实现

Agent的四个组成部分

模型是大脑。负责推理、决策、生成。如果模型能力太弱再多的工具也规划不过来
工具是身体。模型无法自己查数据库，跑代码等。这些都要靠工具。工具这么接进来就是Function Calling、MCP干的事了
记忆就是记忆。 要能记住当前对话、任务状态、长期知识。没有记忆，Agent 每轮都像失忆，多步任务根本做不完
规划是策略。 面对复杂任务，要能拆步骤、排顺序、定失败后的退路。规划能力弱的 Agent，遇到多步任务就乱走

Agent 的核心循环：ReAct

ReAct 是 Agent 最经典的运行模式，全称 Reasoning + Acting。

一轮循环大概是：

1. Thought：模型想“现在该干什么”
2. Action：决定调哪个工具、传什么参数
3. Observation：拿到工具返回的结果
4. 回到 1，基于新结果继续想

举个具体例子，用户问“帮我查一下杭州今天天气，如果下雨就提醒我带伞”

第一轮：

• Thought：先查天气
• Action：调 get_weather(city="杭州")
• Observation：多云，23°C，无雨

第二轮：

• Thought：没下雨，不需要提醒带伞
• Action：直接回答
• 结束

如果查出来是“大雨”，第二轮就会变成“调提醒工具”或者“在回答里加带伞提示”。

这个循环可以跑很多轮，直到模型判断任务完成，或者判断做不了。

一个最小 Agent 的伪代码

def agent(query, max_steps=10):
    messages = [{"role": "user", "content": query}]

    for step in range(max_steps):
        # 1. 模型想下一步
        response = llm.chat(messages, tools=tool_schemas)

        # 2. 如果模型不调工具，说明它要直接回答
        if not response.tool_calls:
            return response.content

        # 3. 执行工具
        for call in response.tool_calls:
            result = execute_tool(call.name, call.arguments)
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": result
            })

    return "达到最大步数，任务未完成"

这段代码很短，但 Agent 的本质都在里面：

• 循环：for step in range(max_steps)
• 模型决策：llm.chat(messages, tools=...)
• 执行：execute_tool(...)
• 结果回灌：把工具结果 append 回 messages
• 退出条件：模型不调工具了，或者达到最大步数

max_steps 很重要。没有它，模型可能在一个死循环里反复调同一个工具，烧 token 烧到天荒地老

另一种规划模式：Plan-and-Execute

ReAct 不是唯一的运行方式。Agent 还有一种常见的规划模式，叫 Plan-and-Execute

一句话区别：

ReAct 是边走边想，Plan-and-Execute 是先想好再走

ReAct：

想一步 → 做一步 → 看结果 → 再想下一步

每一轮只决定“下一步做什么”，不提前规划完整路径

Plan-and-Execute：

先制定完整计划 → 按计划逐步执行 → 执行中根据结果调整计划

先把任务拆成步骤列表，再一步步执行。伪代码大概是这样：

def plan_and_execute(query, max_replans=3):
    plan = planner.plan(query)      # 先拆完整计划
    results = []

    for step in plan:
        result = executor.run(step, context=results)
        results.append(result)

        if not result.success:      # 某步失败，重新规划
            plan = planner.replan(query, plan, results)
            break

    return synthesizer.summarize(query, results)

两种模式各有各的适用场景：

• ReAct 适合：任务路径不固定、每一步依赖上一步结果、需要边做边调整的场景。比如排查问题、探索式检索
• Plan-and-Execute 适合：任务步骤相对明确、可以提前拆解、步骤之间依赖关系清楚的场景。比如“查资料 → 整理 → 写报告”这种流程

代价也不一样：

• ReAct 灵活，但容易绕路，每轮都要调模型，成本高，没有全局视角
• Plan-and-Execute 有全局视角，步骤清楚，但计划可能一开始就错，执行中环境变了要能重规划，Planner 本身也可能拆错步骤

实际生产里，很多 Agent 不是纯 ReAct 或纯 Plan-and-Execute，而是混着用：

先 Plan 拆出高层步骤
每个步骤内部用 ReAct 执行
某一步失败 → 触发 Replan

比如一个排查类 Agent：

计划：
1. 查产品文档
2. 查历史工单
3. 生成排查步骤

执行第 1 步时，用 ReAct 循环：检索 → 看结果 → 不够再检索

所以 ReAct 和 Plan-and-Execute 不是二选一，是不同层次的规划
ReAct 管“下一步做什么”，Plan-and-Execute 管“整体分几步”。

---

Agent 不是万能的

写 Agent 最容易犯的错，是什么都想用 Agent 做

Agent 有明确的代价：

第一，贵。 一次问答可能变成五轮循环，每轮都在生成 token。框架选错、不做难度路由，成本能翻好几倍

第二，慢。 多轮循环意味着多次模型调用，延迟是叠加的。对实时性要求高的场景，Agent 不一定合适

第三，不稳定。 模型每一步都可能判断错，错一步后面全歪。生产环境要有 max_steps、要有兜底、要有验证

第四，难调试。 固定流程出问题，看日志就知道哪一步错了。Agent 出问题，你要复盘它每一轮“想了什么、为什么这么想”，难度高很多

所以一个实用的判断标准是：

任务步骤固定、不需要模型自己判断的，用 Workflow，别用 Agent
任务步骤不固定、需要根据中间结果调整的，才用 Agent