《AI Agent 核心技术解析》|CHAPTER 01 Agent 概述

从文本预测器，到能行动的软件层

LLM 负责推理，工具提供行动，记忆保存状态，循环让任务持续推进。Agent 的价值，不是更会聊天，而是能在运行时决定下一步。

一、LLM 本身做不到什么

一个没有 Agent 框架的 LLM，本质上是一个一次性的函数调用或者叫文本预测器：输入文本，输出文本，然后结束。它有四个根本限制：

这些限制在简单问答中不明显，但面对真实任务时就会失效。"帮我分析这个代码仓库有什么 bug"需要：读文件 → 运行测试 → 看报错 → 修改 → 再验证。这不是一次 LLM 调用能完成的。

二、Agent 的技术本质

Agent 的解决方案非常简单：把 LLM 装进一个循环，给它工具。

这个"Think → Act → Observe → 循环"来自 2022 年的论文

 ReAct: Synergizing Reasoning and Acting in Language Models，

是几乎所有 Agent 框架今天的核心骨架。

一轮 ReAct，在工程上对应的是一次完整的 LLM 调用：

• Thought
  ：模型输出当前步骤的推理文本；
• Action
  ：模型输出一个结构化的 tool call（name + args）；
• Observation
  ：工具执行结果被塞回下一轮 prompt。

需要补充的是，ReAct 不是唯一范式，工程里常见的还有：

• Plan-and-Execute
  ：先全局规划一份 plan，再按计划分步执行。适合长任务、token 预算敏感场景，因为避免了每步都让大模型重新思考。
• Reflexion
  ：在 ReAct 之上加"自我反思 + 记忆"，任务失败后让模型基于失败经验重试。
• Tree / Graph of Thoughts
  ：把推理过程显式树化/图化，支持剪枝与回溯。

核心公式：

Agent = LLM + Tools + Memory + Loop

当然现在的公式应该是

Agent = LLM + harness

其中 LLM 负责推理和决策，Tools 提供行动能力，Memory 让状态在循环间传递，Loop 让多步骤任务成为可能。

Agent 的演化时间线

• 2022 初
   Chain-of-Thought 论文：发现提示 LLM 逐步推理能大幅提升准确率——LLM 可以做多步推理
• 2022 末
   ReAct 论文：将推理链与工具调用结合，首次实现现代意义上的 Agent 循环
• 2023 中
   OpenAI 推出 Function Calling：LLM 能输出结构化工具调用，Agent 从"实验"变成"工程可用"
• 2023
   AutoGPT 爆火又暴露问题：死循环、幻觉、token 失控——推动更结构化框架出现
• 2024
   LangGraph、Devin、Claude Code 等：用状态图和更强的模型让 Agent 真正落地

三、为什么 Agent 不只是"更好的 Workflow"

Agent = 把 workflow 中原本"由人判断、调度、修正"的环节，迁移给模型来完成的系统。

Workflow（如 n8n、Dify 工作流模式）和 Agent 处理"谁来决定下一步"的方式根本不同：

以医疗场景为例（客服、法务、电商咨询都适用这个分布）：

每多一个意图就要加一个分支，节点过千之后：

• 不可观测
  ：人脑已经 hold 不住流程图；
• 不可维护
  ：改一处怕炸一片，回归成本线性上升；
• 不可测试
  ：分支组合爆炸，测试集覆盖不全。

工程上走到这一步，唯一出路就是换范式：

不再由人画 workflow，而是让人只注册工具，模型在运行时自己生成 workflow。

这就是从 Dify 到 Agent ："执行"变成"规划 + 执行"。Agent 不是一种新玩具，它是老一代工作流产品的必然继任者。

四、产品视角：Agent 是新的软件层

从产品角度看，Agent 不是 SaaS 的替代，而是在现有软件栈上方插入了一个新层：

这带来了一个根本性的交互模式转变：

五、为什么 Coding 是 Agent 最先成熟的场景

Coding Agent（Cursor、Claude Code、Codex）比"通用 Agent"成熟得多，原因不在于 AI 更聪明，而在于代码环境天然提供了 Agent 需要的一切反馈机制：

这个洞察反过来也告诉你：要让 Agent 在其他场景成功，就需要为那个场景构建同等质量的"上下文 + 工具 + 验证 + 反馈"环境。

六、Agent 现在处于什么阶段

Agent 作为产品类型，还没有形成稳定形态——类似于 SaaS 早期的 Excel 时期：人人都在用，但垂直细分还没出现。任务演进路径是：

• 聊天
   ChatGPT 开创对话入口，问答为主
• RAG 搜索
   接入知识库，解决知识截止问题
• Deep Research
   多步骤自动研究，开始有 Agent 雏形
• 工作流
   Coze、Dify，结构化多步任务
• AI Coding ★
   现在所处位置——Agent 智能开始溢出到通用场景

（excaildraw mcp 绘制）

为什么现在 Agent 还以 Chat 形态为主？产品形态未稳定时，Chat 是最低门槛的 UI——它可以承载从简单问答到复杂任务委托的任意需求。开发者最先尝试 Agent，而开发者习惯的入口就是对话框。等垂直场景成熟，专用 UI 才会出现。

通用 Agent vs 垂直 Agent

七、三类典型 Agent 场景

根据场景优化目标不同，Agent 产品可以分为三类。判断顺序：先看场景要优化什么，再决定产品形态、技术架构和评估指标。

关键洞察：业务流程型 Agent 的核心价值不是"替代 Workflow"，而是覆盖 Workflow 覆盖不了的地方——模糊输入、边界情况、例外处理。

理解检验

Q1：一个 n8n 工作流，在某个节点调用了 GPT API。请问这个工作流算不算 Agent？

算，因为它用了 LLM不算，因为路径是人预先设计好的，LLM 只是其中一个节点，不负责决定下一步走哪条路算，因为它能自动执行多步骤任务不算，因为 n8n 不是 AI 产品

Q2：以下哪个说法最准确地描述了 Agent 解决的核心问题？

Agent 让 LLM 更聪明，能回答更难的问题Agent 解决了 LLM 的知识截止问题Agent 解决了"设计时无法穷举所有路径"的问题，让系统能在运行时动态决策Agent 让 AI 产品不再需要人工干预

Q3：一家公司要做客服 Agent，处理用户投诉。根据三类场景框架，它最应该属于哪类，核心能力重点是什么？

生产力工具型，重点是长任务执行和上下文管理业务流程型，重点是业务 know-how、内部系统集成和人工确认机制多模态 AIGC 型，重点是多模型编排和批量生成生产力工具型，重点是工具调用和任务状态管理

推荐主要读物

本节课最核心的一手资料是 ReAct 论文——所有现代 Agent 框架的直接源头：

ReAct: Synergizing Reasoning and Acting in Language ModelsYao et al., 2022 · 约 15 分钟可读完读完后你会看到：我们今天用的所有 Agent 框架，本质上都是这 6 页纸的工程实现。