导语

Agent 在过去三年从概念走向生产，但围绕它的讨论一直分散在三个不同的层面：什么是 Agent、Agent 形态如何演化、以及如何把 Agent 真正构建成可用产品。这三个问题彼此独立又互相支撑——不理解定义就难以分辨技术争议，不理解演化就把握不到当前最佳实践，不理解落地就停留在 Demo 阶段。

本文把这三层一次梳理清楚：第 1-2 章解决"是什么、为什么"，第 3-4 章解决"演化到了哪里、每个模块发生了什么变化"，第 5-6 章解决"实际怎么构建一个高可用 Agent"。

第 1 章 Agent 概念与争议

1.1 Agent 的本义：代理 vs 智能体

Agent 这个词在英文语境下的原义是"代理人"，但也带有"代理"的含义。国内学术界、工业界很多翻译为"智能体"，强调其"智能化"和"自主决策"能力；另一派则倾向译为"代理"，更贴合英文中"代理人做某件事情"的本意。

事实上 Agent 是一个早于 LLM 就有的技术名词。云计算领域，弹性计算服务器上安装的 Agent 是一种服务器代理程序；强化学习领域，Agent 指可以从环境学习、感知、更新的策略模块。这些 Agent 未必由大模型驱动。因此现在常用 AI Agent 或 LLM Agent 来与传统 Agent 程序做区分。

1.2 经典定义

OpenAI 的 Lilian Weng 给出的定义是：Agent = LLM + Planning + Memory + Tool Use。复旦大学 NLP 团队则用大脑、感知、行动三个组件来描述。无论哪种定义，核心不变：Agent 是一个能规划、有记忆、能使用工具的代理，模拟的是人处理任务的完整心智过程，而不是某段固定的代码逻辑。

1.3 三大概念争议

围绕"什么算 Agent"的争议主要集中在三个方向：

  • 智能体 vs 代理：Agent 是否必须由大模型驱动？满足"代理"能力的程序、代码块是否可以叫 Agent？
  • 自主规划 vs 工作流：Agent 是否必须具备自主规划能力？预定义好的 Workflow 是否可以被叫做 Agent？
  • 函数调用 vs 角色扮演：Agent 是否必须实现函数调用？是否必须有"人设"或"拟人化"属性？

随着技术发展，Workflow 与 Agent 的边界已经模糊。Agentic Workflow（大模型自主规划的 Workflow）、Workflow 框架内嵌 LLM 节点、Manus/OpenManus 这种"外层 Workflow + 内层 LLM 自主规划"的双层结构都在并存。Workflow 和 Agent 已经是相互依赖、相辅相成的关系。

1.4 agenticness 光谱与广狭义 Agent

吴恩达在一次采访中提出了"agenticness 是一个光谱"的观点——不同系统具有不同程度的 agenticness，从几乎无自主性到高度自主都是合理的存在。争论"这个系统到底是不是 Agent"本身价值不大。

为便于讨论，可以把 Agent 定义分成两种：

  • 狭义的 Agent：理想状态下的"智能体"，能听懂自然语言指令，自主规划、分解、执行、反思、决策，无需人为干预内部细节。
  • 广义的 Agent：侧重"自动化的任务代理"，不纠结是否以大模型为基础，可以通过大模型、小模型、硬编码、规则引擎等多种技术混合，以帮助人自动化完成任务为目标。

广义 Agent 包含狭义 Agent。目前许多企业研发的 Agent 平台都在广义定义的范畴里——狭义 Agent 仍是一种技术理想主义，构建简单（任务全盘交给大模型）但效果稳定性差，落地问题很多。

第 2 章 为什么一定要做 Agent

一个常见的质疑是：同样的业务场景，传统硬编码或低代码平台一样能实现，而且更快、更稳定、交互更好，为什么还要上 Agent？只看 Agent 当前的缺点（响应慢、有幻觉、纯文本交互不友好），这个质疑确实成立。但 Agent 带来的增量价值并不在传统流程的"复刻"上，而在以下四个维度。

2.1 降低应用开发门槛：让"能描述需求的人"成为开发者

传统方式下，实现一个功能需要会写代码，或者至少会用低代码平台做节点编排和参数映射。Agent 改变了规则：只需要描述要什么，不需要描述怎么做。

类比来看：剪映让不会剪辑的人能剪视频，美图秀秀让不会 Photoshop 的人能修图。Agent 要做的类似——让不会写代码的人能开发应用。这就是 GenAPP（生成式应用）的核心理念：通过自然语言描述和极简配置，最低成本地实现一个能解决复杂问题的应用。

2.2 简化流程复杂度：大模型是天然的"胶水"

传统流程编排有一个典型痛点：上一步 API 的返回结果和下一步 API 的输入参数之间，必须严丝合缝地映射好——类型要匹配、字段要对齐、转换要完备，任何环节出问题就是 bug。

Agent 改变了这一点。大模型像胶水一样，天然能理解"A 的输出"和"B 的输入"之间的语义关系，自动完成参数转换。流程不需要做到 100% 完备——做到 80%，剩下的 20% 让模型的理解能力去弥补。

在算法层面这一点更明显。传统方式下，路由分发需要一个单独训练的小模型，意图识别又需要一个，中间每个需要"判断"的节点都可能需要一个小模型，每个都要收集数据、打标签、训练、部署。Agent 时代，一个 prompt 就能搞定这些，大模型自己就能拆解问题、判断路由、完成识别。

2.3 交互方式的多样性：Agent ≠ 对话机器人

一个常见误区：Agent 只能是对话形态的纯文本交互。但 Agent 的定义里根本没有限定交互方式。

Anthropic 发布的电脑操作 Agent，输入是自然语言，输出是一系列鼠标点击和键盘操作。微软的供应链分析 Agent，输入是表单选项，输出是图表和趋势预测。Agent 的本质是代理执行，不是对话。 自然语言只是人和模型之间的通信协议，不是 Agent 对外呈现的交互形态。

2.4 协同完成复杂任务：从单体到 Multi-Agent 社会

传统流程是封闭的——两个流程要协作，需要再写第三个流程来编排它们。Multi-Agent 则天然支持协作：多个 Agent 可以接力处理同一工单中的多个问题，可以像专家会诊一样讨论疑难杂症，可以竞争输出多个方案再由决策 Agent 或人来拍板。这种"智能体编排智能体"的能力，是传统流程编排无法做到的。

第 3 章 Agent 技术范式的四阶段演化

回顾 2023~2026 这三年，Agent 的技术形态经历了四个显著特征的阶段。这四个阶段并非完全的替代关系，而是并存且互补的。

3.1 阶段一：早期 Agent（被动式 ReAct，2023）

2023 年是 Agent 概念启蒙期，代表性理论源自 Lilian Weng 的《LLM Powered Autonomous Agents》，定义了 LLM + Planning + Tools + Memory 的基本架构。

这个阶段的 Agent 本质是被动式响应，基于初步的 ReAct 架构（Reasoning + Acting），遵循"Reasoning → Observe → Response"的单步链条。交互形态类似增强版 Chatbot，处于"一问一答"或"指令-执行"状态，严重依赖用户的明确指令，基本只能完成单点、短链路的小任务，缺乏长期规划能力，任务复杂度超出上下文窗口时极易中断。

3.2 阶段二：工作流 Agent（结构化与可控性，2024）

2024 年，随着 to B 业务对稳定性要求的提升，纯靠 ReAct 解决复杂问题变得不现实，Agentic Workflow 成为主流。核心理念是：用工程化的约束来弥补模型的不确定性。

架构特征是：整个大框架是固定的 Workflow，关键节点嵌入 LLM；或者 LLM 作为中枢调用预定义好的子 Workflow。这种方式牺牲了一定灵活性，但换来了极高的可控性和可解释性。对于非长尾、非极度复杂的场景，Workflow Agent 至今仍是性价比最高、落地最稳定的方案。

3.3 阶段三：自主 Agent（复杂规划与长程任务，2025）

2025 年是 Agent 迈向"自主性"的关键转折点。以 Manus、Claude Code、Codex 等为代表，标志着 Agent 能力的再一次质变。

这个阶段的 Agent 不再满足于快速调用几个工具后给出结论，而是具备了复杂的 Planning 能力。面对模糊或宏大的需求，能自行拆解任务、规划路径、调用工具并多轮迭代。只要清晰描述需求并设定好开发规范，Agent 可以连续运行很长时间；配合轻量级 Harness 或自我校验机制，在长程运行中不断修正错误。这是从"辅助者"向"执行者"角色的根本转变。

3.4 阶段四：自进化 Agent（持续学习与自我升级，2026）

2026 年，Hermes Agent 等新一代框架兴起，Agent 可以自我沉淀 Skill、自我沉淀知识库，甚至通过 RL 训练提升模型能力，进入"自进化"阶段。

核心本质是解决"静态模型"与"动态世界"之间的矛盾。Agent 在完成任务的过程中沉淀经验，通过记忆模块、反馈循环和自我反思机制将教训转化为新知识或策略。最终目标是实现"越用越好用"，自动优化提示词、工具选择策略，甚至微调局部模型参数。Agent 因此从"一次性消耗品"变成了"可积累资产"。

第 4 章 六个核心模块的范式变化

从宏观架构上看，今天的 Agent 依然由 Prompt、Planning、Memory、Tools、Workflow、Environment 等经典模块组成。但每个模块背后的运行逻辑、数据流转方式和工程实现范式都发生了深刻变化。

4.1 Prompt：单体 → 渐进式文件加载

早期构建 Agent 时，绝大部分精力都耗费在撰写 Prompt 上。一个任务创建一个 Agent，每个 Agent 对应一段精心调试的独立 System Prompt，维护成本极高。

当前演进方向是解耦：System Prompt 保持极度稳定，只保留最底层的系统级指令和基本行为规范；大量具体的任务要求、领域知识等动态内容被拆解并存储到外部文件系统，通过渐进式披露的方式加载。具体落地有两类：

  • Skill 层面沉淀：执行某项具体任务的方法论、步骤要求沉淀为独立的 Markdown 文件（如 SKILL.md），Agent 在执行时动态加载。
  • 配置文件存储：人设定义、用户偏好等通用规范存储在 USER.md、SOUL.md 或 AGENTS.md 等配置文件中。

4.2 Planning：思维链 → 复杂长程任务拆解与推理

早期的 Planning 主要依赖模型原生的 CoT 能力，通过"Let’s think step by step"引导线性串行推导。随着模型推理能力的显著增强，Planning 机制发生了质的飞跃：

  1. 复杂问题的结构化分解：主动将宏大目标拆解为多个可执行的子任务，生成结构化的 Todo List。
  2. 多步协同与长程推理：按步骤有序执行，并在执行过程中动态调整计划。
  3. 子 Agent 的动态构建：根据子任务需求动态实例化或调用特定的子 Agent。

驱动这一演化的核心是底层基座模型推理能力的升级。Planning 从简单的"提示词技巧"演变成了"智能决策中枢"。

4.3 Memory：检索增强 → 文件系统化的沉淀与检索

记忆模块在两个维度上都发生了显著演变。

短期记忆层面，核心挑战从"存储"转向"管理"与"压缩"：阈值控制（基于固定 token 数或动态语义密度阈值触发压缩）、结构化摘要（对中间过程的对话进行 Summary 提炼，保留头尾关键信息）、重点提取（从冗长的对话流中提取关键事实或状态变化）。

长期记忆层面，逐步从"向量数据库主导"向"文件系统主导"回归：事项型记忆（用户偏好、历史行为等动态事实，使用文件系统记录如 MEMORY.md）；知识型记忆（在 LLM-Wiki、GBrain 等理念普及下，本地文件系统 + Markdown 知识库逐渐补充传统 RAG 方案；企业级场景则采用文件系统 + QMD/SQLite 的轻量向量化检索混合方案）。

Memory 的演进本质是从纯向量文本检索走向"文件系统化沉淀 + 向量检索混合管理"。

4.4 Tools：Function Call → CLI / Script

这是 Agent 范式中变化最大的一个部分。早期的 Function Call 模式需要将系统能力封装为标准 API 并注册为可调用函数，开发和维护成本极高。真正的范式转移发生在两个维度：

CLI 命令行原生化：grep、cat 等 Linux 命令是模型预训练数据中的"先天知识"，无需额外定义复杂 API Schema；面对未见过的第三方 CLI 工具，模型可通过 --help 在运行时自主理解参数用法；节省了巨大的 token 空间和调试成本。

Script 脚本化：具体的工具逻辑被封装为独立脚本文件，既可直接执行本地命令，也可内部封装对远程 API 的调用；复杂的 API 鉴权、参数拼接等细节隐藏在脚本内部，Agent 只需关注"调用哪个脚本"和"传入什么参数"。这也是为什么安装一个 Skill 往往就能赋予 Agent 处理复杂任务的能力。

Tools 的演进核心是从"人为适配模型"转向"利用模型原生能力"。

4.5 Workflow：刚性流程编排 → 动态封装与混合架构

Workflow 的形态正在从"刚性流程编排"转向"动态 Skill 封装与混合架构"：

  • 逻辑内聚化：原本分散在 Workflow 引擎中的步骤定义、约束条件、核心判断逻辑，现在直接写入 Skill 的 Markdown 描述文件。
  • 执行脚本化：对需要精确控制的环节，通过 Skill 关联的 Script 脚本进行代码级编排。

落地实践中最佳策略是混合架构：将成熟的标准化子任务封装为 Skills，利用其灵活性和易用性；将关键的、对稳定性要求极高的主干流程保留为 Workflow 作为兜底。这种"Skill 为主，Workflow 为辅"的策略，既利用了新技术的红利，又保留了必要的确定性。

4.6 Environment：无状态 → 运行时环境

早期的 Agent 对工具调用几乎不需要运行环境。但随着文件系统操作、代码执行等能力的引入，Agent 必须拥有专属的 Workspace。根据安全要求的不同，Runtime 环境分为两种形态：

  • 本地个人电脑：便利性和灵活性极高，可操作本地文件系统和应用，但缺乏严格隔离机制，需要引入用户确认机制或权限控制。
  • 沙箱环境：企业级生产环境的主流选择，通过 Docker/Kubernetes 等容器化技术构建隔离沙箱，提供必要的安全边界和资源管控。

4.7 演进对照表

模块 早期范式 当前范式
Prompt 单体大 System Prompt 解耦 + 渐进式加载文件系统
Planning 线性 CoT 思维链 复杂长程任务拆解与推理
Memory 前置向量检索 文件系统化 + 向量检索混合
Tools 高成本 API 封装 原生 CLI + Script 脚本化
Workflow 刚性外部编排 Skill 封装 + 混合架构
Environment 无状态调用 有状态隔离 Runtime

第 5 章 高可用 Agent 落地的四大挑战与对策

理解了 Agent 是什么、为什么需要它、形态如何演化之后，真正的难题是把它构建成业务上稳定可用的产品。Agent 落地过程中的问题大致可以分为四类挑战。

5.1 四大挑战概览

  • 挑战一：运行效果不稳定。 提示词看似简单，但实操过的话会发现写出一套稳定运行的提示词并不容易——过短则主体不明、表意不清；过长则注意力失焦、重点遗忘；甚至提示词中存在自己都没意识到的冲突和矛盾，导致模型运行不稳定。
  • 挑战二：规划如何平衡。 大模型自主驱动的模式很容易不可控；如果通过 Workflow 的方式去做规划，又需要投入大量人力成本去编排，导致 Agent 构建成本越来越高。
  • 挑战三：领域信息集成。 大家用的模型大多是通用基座大模型，基本上不具备领域垂类的知识信息，对领域特定词汇、知识、流程的理解上都会很困难。
  • 挑战四：响应速度。 大参数模型运行 Agent 效果还不错但速度非常慢，尤其是推理模型；小参数模型速度快但效果不稳定。运行性能和推理效果呈反比关系。

5.2 提示词调优：模板 → AI 辅助生成

提示词不稳定问题的解法经历了两个阶段。

第一阶段：提供提示词模板。 经过大量调试、测试的模板比每个人直接写要更容易稳定。但问题是大家过度套用模板，不需要写的内容也生搬硬套，或者不知道选择哪套模板。

第二阶段：AI 辅助提示词生成和调优。 把提示词模板给到 AI，结合需求先写一版，由人来确认逻辑是否正确，有问题及时调整。因为"最懂大模型的是大模型自己"，可以让模型检测冲突矛盾、指出逻辑问题，持续迭代优化。

5.3 规划层权衡：Workflow / LLM 自主 / 混合架构

规划层的核心矛盾：LLM 自主规划智能化越高、可控性越低；Workflow 编排可控性越高、智能化越低。两类场景适用不同方案。

适合 Workflow 的场景：可控性高但智能化要求低的标准化、重复执行场景。例如订单财务类——查询某个订单有没有过期、计算是否需要退订部分费用——这些都是标准化的，如果让大模型深度参与逻辑判断和数学计算，很容易出现幻觉。再比如排班类场景，需要定时提醒，如果出现幻觉遗漏了某些人，就会很麻烦。

适合大模型自主规划的场景：智能化要求较高的探索化、问题复杂场景。例如云数据库的实例异常诊断——客户一般只会描述"我的数据库查询非常缓慢"，但可能的原因非常多：会话连接数异常、QPS 异常、内存问题、慢 SQL 等等。很难通过一个大而全的 Workflow 承载所有可能性。这类场景适合用大模型自主决策——结合提示词给出几个大的排查方向，让模型通过工具 API 自主查询、诊断、决策。Agentic RAG 也适合这类场景：在没有高质量知识库但能找到官方文档的情况下，让大模型自主生成搜索 query → 搜索 → 检查反思 → 调整 query 重新搜索。

中间状态：LLM 自主规划 + Workflow 结合。以"邮箱无法收发信诊断"场景为例：排查邮箱账号状态、域名状态、报错这些中间过程可以编排成稳定可控的 Workflow，但客户输入形式多样（有的给邮箱账号、有的给域名、有的给报错），所以在 Workflow 之外再用一个大模型来动态决策调用哪个 Workflow，实现"内部稳定可控 + 外部自主灵活"。这种"内可控、外自主"是基于 Multi-Agent 实现的，也可以反过来——“外可控、内自主”，如 Manus/OpenManus 就是外面有一个大的 Workflow 框架，内部每个节点由 LLM 自主规划。

Workflow 三种演化模式

Workflow 实现层面经历过三种模式，目前并存：

  • 模式一：自然语言编排 + LLM 驱动按步执行。 用户用自然语言描述流程 → AI 生成流程图（DAG）→ 大模型按步执行。优点是构建成本低，允许"不完备"的流程图；缺点是运行速度慢，每个环节都要大模型决策，且只能从头执行到尾。
  • 模式二：代码/大模型混编 + 规则驱动按步执行。 不再让大模型驱动所有节点，改用规则引擎驱动。中间节点除必须用大模型的情况外，都用代码、脚本、规则实现，类似离线预编译。运行速度变快，但规则引擎驱动的流程图必须"完备"——节点间参数传递必须准确无误，构建门槛变高。
  • 模式三：自然语言编排 + 大模型自主规划执行。 自然语言描述流程、AI 生成"不完备"流程图，但运行时不是让大模型从头走到尾，而是把流程图作为参考信息给大模型做类似 RAG 的参考规划。这种模式比前两种更加灵活智能。

5.4 领域数据集成

在通用基座大模型中集成领域数据，主要有三个方法：

  • Prompt 中动态领域要求：根据服务场景匹配度，在 Prompt 加载时动态引入领域先验知识，通过类似 RAG 的方式根据场景动态搜索和匹配加载领域知识。
  • 引入外部技能：通过调用领域工具、知识库、文档等，让 LLM 有更多方式自主获取领域数据。
  • 领域大模型训练：在前两种方法搞不定的情况下，通过训练领域大模型来注入领域知识——构造领域数据源（知识库、文档、工具 API），经过汇总清洗构造成语料（单步工具调用、多步工具调用、反问澄清、Multi-Agent 调用），然后进行模型训练和调优。

5.5 响应速度优化

  • 代码参数预转换：尽量减少 Agent 中大模型参与的比例，将非必要的 LLM 模块转换为代码或脚本语言。
  • 推理加速：模型量化、优化 KV Cache、使用加速框架（FlashAttention、vLLM）、更换高性能 GPU。
  • 降低参数量：在满足需求的前提下选用小参数模型；对于高频场景（如 Function Call）非常适合用小参数模型，可以通过大参数 LLM 作为教师模型蒸馏小参数 LLM。
  • Agent 预编译：在构建阶段就识别哪些部分不需要大模型实时参与，提前编译掉，大幅缩短线上执行时间。这是当前更具前景的方向之一。

5.6 幻觉应对

幻觉问题在多条路径上同步收敛：模型迭代、Prompt 规范化（Meta-Prompt 自动优化提示词）、慢思考推理模型（如 o1 类）的引入降低了事实性错误；GraphRAG 等引入知识图谱推理的方案进一步降低幻觉比例。

第 6 章 Agent 构建路径与策略

6.1 四步构建路径

将上述挑战和对策串成可执行路径：

  • 第一步：大模型自主决策构建原型。 通过提示词工程先做一版 Agent，是 ROI 最高、成本最低的方式。在此基础上多次调优，看看能否保持稳定运行。
  • 第二步：拆解 Workflow。 如果效果依然不好，开始尝试构造更加结构化的 Workflow，让 Agent 在框架范围内运行以提高稳定性；Workflow 如果使用代码规则编排，也可以提升运行速度。
  • 第三步：设计 Multi-Agent 架构。 如果 Workflow 虽然稳定但智能化不够，或者既需要灵活又需要可控，就需要设计更复杂的 Multi-Agent 架构——将复杂任务拆解成多个子任务，通过多个子 Agent 承接，设计子 Agent 之间的通信方式和形态。
  • 第四步：模型定制化训练。 如果前面三步都尝试了仍然难以调优，或者对准确率、速度、稳定性、智能化能力都有极高要求，就需要对 Agent 的关键环节做模型定制化训练。

从提示词原型到 Workflow、Multi-Agent、模型训练，成本在不断提升，但理想情况下运行效果也在提升。具体要投入多大成本、达到怎样的效果，取决于场景的具体要求。

6.2 Skill 为主 + Workflow 为辅的混合策略

构建路径之外，还有一个贯穿性的工程策略：将成熟的、灵活变化的子任务封装为 Skill；将关键的、对稳定性要求极高的主干流程保留为 Workflow 作为兜底。这种"Skill 为主，Workflow 为辅"的策略，既利用了新技术的红利，又保留了必要的确定性，是当前长程 Agent 落地中较为成熟的工程范式。

6.3 流程管下限，Agent 管上限

最后回到最初的问题：传统流程已经能跑，为什么还要 Agent？

答案是它们解决的问题不在同一个维度。传统流程解决的是"已知怎么做"的问题——路径预定义、每一步确定，追求执行确定性，管的是下限。Agent 解决的是"不知道怎么做，但知道要什么"的问题——路径动态生成，中间需要理解和判断，追求路径智能，管的是上限。

两者不是替代关系，而是覆盖了问题空间的不同象限。当用户的问题落在 SOP 覆盖范围内，流程是最快最稳的选择；当需求描述模糊、多意图交织、中间需要动态判断时，只有 Agent 能填补这个盲区。

从宏观架构上看，今天的 Agent 依然由 Prompt、Planning、Memory、Tools 等经典模块组成，与 Lilian Weng 早期提出的理论框架并无二致。但每个模块背后的运行逻辑、数据流转方式和工程实现范式都发生了深刻的变化。Agent 正在从"魔法调优"走向"系统工程"，从"一次性消耗品"变成"可积累资产"。其核心思想始终未变：在保证安全、可控的前提下，最大化释放模型的推理与执行潜力。

模型会继续升级，工具会继续变化，框架会持续更新，但"通过工程化手段构建确定性，以承载模型不确定性"这一核心思想，将是未来很长一段时间内构建高质量 Agent 的基石。

参考资料