AI Agent 从入门到精通：小白 & 程序员必学的大模型应用指南

Llama-Turbo

墨衍会员 · AI 创作全网分发码龄4年

关注

原创最新推荐文章于 2026-08-30 08:19:45 发布 981 阅读 AI 写同款· GEO 优化 ›

详解AI Agent系列｜（1）AI Agent到底是什么从high-level来简明概括地介绍一下AI Agent 阅读详情

在讲解这篇文章之前最重要的就是给 AI Agent 的下一个定义。

我知道很多非常前线的 agent 开发工程师可能会觉得这段话比较啰嗦，但是我仍然想要强调一下：任何一个领域的开篇一定需要对这个领域中所提及的关键词进行定义，从而对齐读者与笔者的上下文。消解分歧也是笔者的义务之一。

我认为 AI Agent 是一个同时满足下面两个条件的程序或者系统：

部分甚至核心逻辑由深度学习及其衍生技术实现（主要指大模型技术）。
是一个能够进行任务执行的下游应用，它的输入和输出都是直接面向终端用户的。

AI Agent 的一些例子

基于这个定义我们通常情况下认为如下的应用可以称得上是一个 AI Agent

美团小美：根据用户的需求来帮用户选择符合用户的描述的外卖或者零售商品，下图演示了通过小美自动根据历史记录点外卖。

AI Coding 工具：诸如 Cursor，Claude Code，Copilot，Trae，Qwen Coder，可以帮助程序员更快地将需求转化成业务代码。比如说请帮我优化一下当前的网站页面布局，或者根据新的业务需求设计后端的数据库模型或一件生成对应增删改查的代码，可以大幅度增加开发效率，下面是我日常使用 copilot 进行网站开发的截图：

SlidevAI：这是我开发的一款AI PPT生成工具。可以根据用户输入的文本素材来生成一个能够通过网页链接直接预览的 PPT。https://github.com/LSTM-Kirigaya/slidev-ai

slidev ai

deepwiki：代码阅读神器。输入GitHub的仓库链接以及你的问题，这套系统会帮你自动地解析目标仓库源代码，并且输出对应的答案和与这个答案所对应的仓库中的代码片段，以此帮助开发者更快的了解他想要了解的源代码部分。比如当你询问 deepwiki 当前这个仓库中是如何实现用户登录，以及用户登录的守护中间件是如何编写的，那么 deepwiki 就会把守护中间件的实现文件和与之关联的环境变量注册配置文件定义直接帮你展示出来。https://deepwiki.org/ 。下图为「询问 deepwiki 关于某项目中图像存储相关服务的实现细节」

什么不是 AI Agent

为了更加准确地定义 AI Agent，我还想要举出一些我认为并不算这个范围内的应用。

大模型对话网站：大模型对话网站并不执行任务而只做一对一的文本生成。因此在我的定义中直接的大模型对话比如 deepseek，chatgpt，这些并不算是 AI Agent。
基于传统意图识别模型的 AI 系统：在大模型之前就有不少的技术尝试通过简单或复杂的深度学习分类器来路由用户的输入，并导出到不同的执行器中。这样的复杂系统由于在大模型之前就已经存在且拓展性极差，而且用户的输入必须得遵守严格的语法规定，因此我并不认为这种系统是 AI Agent。比如早期版本的微软小冰，基于知识图谱的问答系统。
传统推荐系统与搜素引擎：这类系统往往基于预定义的指标用于在数据库中进行排序和搜索，由于并没有大规模的使用深度学习相关的技术且搜索强依赖于基于统计数据的权重方程，所以这类系统也不算是 AI Agent。比如 bing，百度，2023年前的抖音推荐系统。

AI Agent 分类

长话短说，目前的 agent 从实现技术上来说一共分成两大类：「workflow 型」和「autonomous 型」，我们后续简称为「工作流」和「自主智能体」。

workflow 型（工作流智能体）

定义：工作流智能体 指通过预定义代码路径编排 LLM 和工具。

在具体解释工作流之前需要先给朋友们普及一个概念叫做 SOP，全称 Standard Operating Procedure，即标准作业流程。在一套成熟的业务体系中，完成某个任务一定会有非常标准的一套流程，做完 A 就要做 B，然后基于非常明确的标准选择下一步。俗话说的“走流程”，指的就是按照 SOP 办事。

比如下图所示的就是一个典型的工作流，基于著名工作流框架 n8n 低代码构建，它演示了通过某个固定的触发器来智能抓取 GitHub 上的热门项目，从而提供资讯聚合服务的流程。

对于这个项目感兴趣的朋友，可以阅读补充材料：https://tomo.dev/en/posts/n8n-workflow-for-daily-github-trending-auto-posting/

对于这个任务而言，它的 SOP 和工作流内容完全同构，即“爬取GitHub日活跃数据”->“计算热门项目候选集合” -> “基于大模型进行智能总结”->“翻译到目标自然语言”->“在目标通信频道推送消息”。

工作流的本质其实就是可视化的 if else，而传统的工作流中有一大痛点就是部分环节中“关键任务”无法通过 if else 的方式来解决（比如诸如基础翻译，跨语言格式转换等等 NLP 任务），传统 NLP 技术每一个 NLP 任务都是一个深度学习模型，大大增加了工作流中“关键任务”的部署成本，而大模型的出现，几乎从根本上解决了这一痛点，从而为工作流技术在更大范围内的落地部署提供了可能性。正因如此，我愿意将目前结合了大模型技术的工作流称为第一类智能体。

从本质上来说，目前绝大部分的工作流框架其实就是低代码的任务编排框架，任务编排框架有很多不同的实现方式，通过鼠标点击拖拽的就是「低代码任务编排框架」，比如我们上面提到的 n8n 就是目前最为热门的低代码任务编排框架。当然，也有通过纯粹写代码实现的编排框架，比如 Apache Airflow，很多的办公自动化场景中会使用。也有很多根据给定工具进行简单配置就能运行的 workflow，最典型的就是 github 提供的 action 功能，很多专业的工程项目，你往往可以在 github 仓库中看到一个叫做 .github/workflows 的文件夹，比如 https://github.com/LSTM-Kirigaya/openmcp-client/blob/main/.github/workflows/build.yaml

目前最为流行的工作流框架清一色都是「低代码编排框架」，如下图，从左到右分别为 dify, n8n 和 coze。

除了这些开源的框架外，各个大模型厂商也开始推出自己的工作流框架，并将其称为“Agent 框架”，比如下图所示的 openai 的 AgentKit

虽然构建成本大了一点，但是作为较为成熟的技术，工作流结合大模型所诞生的第一类 Agent 理所当然地成为了目前 Agent 市场上最为主流的技术，换句话说，目前市面上绝大部分的 Agent 都是基于工作流 + 大模型的 Agent。

autonomous 型（自主智能体）

定义：自主智能体 指基于 LLM 动态控制决策和工具使用，自主规划选择的系统。

虽然工作流已经非常 nice 了，但是对于很多标准化程度并不高，难以抽象出 SOP 的场景而言，工作流就难以胜任这部分工作了。最典型的场景就是代码生成，你让 AI 根据你的需求生成代码，这个过程它其实并没有 SOP。

你让 AI 「用 C 语言实现一个根号计算的牛顿迭代法」，AI 可以完美生成，因为训练大模型的语料库中存在牛顿迭代法的C语言实现代码。

你可能会说，这个需求太简单了，我用工作流，一个「询问大模型」节点就能搞定。

好，那么我们看一个更加复杂的例子。

你让 AI 「实现文章自动保存功能的后端接口并在前端中接入这些接口」，直接询问大模型是不行的，得到的结果是：（下图虚线都是不存在于问答中的，只是用于示意的）

因为它并不知道后端使用的数据库是什么、数据库模型是否存在可复用的字段、前端的请求函数在何处被定义、后端的中间件和前端的请求拦截器是否存在某些特殊的规则等等等等。这些有关目标任务本身的所有旁人不知道的相关信息被我们称为 上下文（context）。AI 只有获取到上下文，才能生成正确的结果，而获取上下文的步骤往往和该领域强相关，比如前后端开发中，请求函数的定义往往在 controller 里面，那么“聪明”的 AI 系统就应该先去阅读相关文件，并将结果加入自己的“记忆”中来实现上下文的获取，从而输出更加精准的代码生成结果。

对于自己不知道的东西，大模型会用很多看起来很像但是其实不是的信息自动填充这些没有提供的信息，这种现象被我们称为「大模型的幻觉」，openai 的一项研究表明，从数据清洗到大模型训练的环节中至少存在5个步骤是导致幻觉的原因，目前业界和学界对于幻觉还没有解决方案，目前从根本上解决幻觉问题的希望不大。

那么这个时候，用工作流就可以这么实现：

OK，假设你的工作流很完美，成功获取了正确的上下文并生成了正确的代码。那么假设我第二天要去做深度学习的训练或者做一个基于 rust 的编译器开发了，又或者，你遇到了一个干脆项目结构和现在完全不一样的前后端项目，这套工作流还能适用吗？事实上，通过之前对于工作流的论述，大家应该知道，工作流只能适用于存在 SOP 的场景，而放眼「开发」这个领域，事实上的 SOP 并不存在。因此在代码生成领域通过工作流来构建 agent，使用场景相当有限。

而我们目前使用的各类 Coding Agent 都是如何实现的呢？此处以我最常用的通义灵码为例子，你可以观察一下 Agent 模式下，它的行为：

当命令下达后，coding agent 会不断使用系统中给定的某些工具，调用工具 -> 获取结果 -> 将结果加入上下文 -> 继续询问大模型，周而复始，这个循环在后面有关函数调用的教程中会讲到，叫做「Agent Loop」，此处先按下不表。

而像 coding agent 这样，给定工具集合的情况下，自主灵活地通过不断调用工具来完成任务的系统就被我们称为第二类智能体，也就是 autonomous 自主智能体。

很显然，这种任务，你用工作流又如何编排呢？写代码这个任务，你不知道什么时候要去阅读文件获取上下文，什么时候要通过网络搜索获取额外信息，什么时候又要阅读历史消息进行记忆回滚，也就是不存在 SOP，不存在 SOP 工作流就不可行。

这个故事看起来非常美好，“一个可以自主完成工具选择和调用的系统”，但是实际的开发和调优上困难重重。更大的自由度意味着更大失控的风险，不同于工作流可以在既定的节点上通过规则组等硬编码方式进行校验，从而让流程可控，自主智能体的每一个环节都存在失败的风险。有一个非常粗糙的数学模型可用于描述这件事：假设目前给定的工具，AI 能够正确使用并产生正确结果的概率为 90%（事实上已经非常高了），当前任务需要使用 20 次工具才能解决，那么这个任务的最高成功率就是：

0.920≈0.12 0.9^{20} \approx 0.12\ 0.9^{20} \approx 0.12\

也就是只有 12%，显然，这样的理论结果还不足以让自主智能体推向落地。当然，你可以说这个数学模型本身过于粗糙，在很多细节上经不起推敲，但是我希望用这个论述给我的一些已经热血沸腾的观众朋友浇一盆冷水，冷静是工程师的品质之一。而如何避免或者缓解这样的现象出现，就是我们后续文章所讨论的内容，请各位朋友耐心期待吧！

总而言之，自主智能体在解决问题的能力上限很高，比如 Nicolas Bustamante 大佬开发的 AI金融研究平台 fintool 里面的诉讼条款搜索模块，已经从复杂策略组的 RAG 全面转向了自主智能体，并在实践中得到了证明。下图是新老两种方法的对比：

图源：RAG的落幕：从检索时代到Agentic导航时代

经验 1.1：明智地进行技术选型

无论是 workflow 型还是 autonomous 型，我们最终的目的都是解决我们的实际问题，技术本身并没有好坏之分，我们需要根据我们目前手头的数据，预算，客户需求，整体系统的设计边界来决定以哪种类型的 agent 作为我们的技术选型。

在此我先简单地从理论角度给出这两者的优劣：

工作流：侧重流程固定和可预测性。如果需要开发的agent他的业务本身有一套 SOP，那么这个时候你就需要考虑如果只使用工作流就能满足需求，那么就直接使用工作流，因为工作流的可预测性会使得开发后期的验证与迭代成本相比于自主型智能体下降很多，在后续的教程中大家也会慢慢形成一个基本的概念，那就是agent开发中验证的成本是大于开发的。
自主智能体：侧重灵活性与自我决策。如果当前场景标准程度低，根本不存在成熟的SOP，那么你大概率只能选择构建自主智能体。在具体实践中，你还需要根据目前大模型的能力边界和对场景的熟悉程度来判断是使用自主智能体，还是选择质疑当前需求的合理性。拒绝是专业工程师的职业素养之一，完善逻辑链的拒绝是专业性的体现之一。

在后续的教程中我会给出一个非常详细具体的例子，同样使用工作流和自主智能体实现一个可以放在 QQ 群聊里的网页阅读助手。