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 处理"谁来决定下一步"的方式根本不同：

	Workflow	Agent
路径由谁决定	人在设计时写死	LLM 在运行时推断
对未知情况	报错或兜底	推理后尝试新路径
错误恢复	预设的 fallback	LLM 理解错误后调整
可预测性	高（路径固定）	低（每次可能不同）
可调试性	高（哪步出错一目了然）	低（推理链难审计）
适合场景	路径已知、需要稳定	路径未知、需要灵活

**概括来说：**Workflow 是人把智能_提前_编码进结构；Agent 是把智能_推迟到运行时_，交给 LLM 即兴生成。Agent 是 Workflow 的泛化，但"泛化"低估了这个转变——它同时引入了不确定性，并把"谁在思考"从设计者转移到了 LLM。

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

覆盖目标	需要覆盖的病种数
80% 诊疗	约 200 种
90% 诊疗	约 6000 种
100% 诊疗	6 万+ 种，持续新增

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

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

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

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

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

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

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

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

传统 SaaS	Agent 时代
用户操作软件界面	用户委托 Agent 完成任务
系统记录对象	Agent 围绕任务组织上下文
人来判断和点击	LLM 自主规划，人审阅结果

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

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

Agent 的核心需求	代码环境的天然支持
知道自己做对了没有	运行测试 → pass / fail 立刻知道
清晰的上下文	代码本身是精确的、结构化的上下文
稳定的工具接口	Terminal / 文件系统接口几十年没变
出错后能恢复	git 随时回滚

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

六、Agent 现在处于什么阶段

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

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

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

通用 Agent vs 垂直 Agent

	通用 Agent	垂直 Agent
代表产品	Claude Code、GPT-4o	Salesforce Agentforce、行业数字员工
优势	泛化能力强，边界宽	注入领域 know-how，更可靠
劣势	在垂直场景不如专用的准确	边界窄，迁移成本高
关键能力	上下文管理、工具调用、长任务	业务系统集成、权限、审计

七、三类典型 Agent 场景

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

	01 生产力工具型	02 业务流程型	03 多模态 AIGC 型
代表场景	AI Coding、AI 文档、AI 研究	销售、客服、运营、数字员工	图片、视频、营销素材
核心价值	提升个人/团队效率，把复杂知识工作交给 Agent	覆盖 workflow 中的模糊输入、判断和例外处理	提升内容生产效率，让结果可感知、可传播、可复用
重点能力	上下文管理、工具调用、任务状态、长任务执行	业务 know-how、内部系统集成、权限、审计、人工确认	多模型编排、资产管线、风格控制、批量生成
主要指标	留存、频次、任务完成率、节省时间	处理时长、错误率、流程覆盖率、成本	生成质量、采纳率、传播效果
演进方向	工具提效 ──────→ 流程接管 ──────→ 内容生产

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

理解检验

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

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

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

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

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

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

Agent 概述：技术视角与产品视角的统一理解