本文首先明确了AI Agent的定义即结合深度学习技术尤其是大模型技术并能执行任务的下游应用。接着文章列举了AI Agent的实际案例如美团小美、AI Coding工具、SlidevAI和deepwiki并区分了哪些应用不属于AI Agent例如大模型对话网站、传统意图识别模型和推荐系统。文章进一步将AI Agent分为两大类工作流型智能体和自主智能体。工作流型智能体通过预定义代码路径编排LLM和工具适用于有明确SOP的场景而自主智能体则基于LLM动态控制决策和工具使用能自主规划选择更灵活但开发和调优难度大。最后文章建议根据实际需求和技术边界选择合适类型的AI Agent。什么是 AI Agent在讲解这篇文章之前最重要的就是给 AI Agent 的下一个定义。我知道很多非常前线的 agent 开发工程师可能会觉得这段话比较啰嗦但是我仍然想要强调一下任何一个领域的开篇一定需要对这个领域中所提及的关键词进行定义从而对齐读者与笔者的上下文。消解分歧也是笔者的义务之一。我认为 AI Agent 是一个同时满足下面两个条件的程序或者系统部分甚至核心逻辑由深度学习及其衍生技术实现主要指大模型技术。是一个能够进行任务执行的下游应用它的输入和输出都是直接面向终端用户的。AI Agent 的一些例子基于这个定义我们通常情况下认为如下的应用可以称得上是一个 AI Agent美团小美根据用户的需求来帮用户选择符合用户的描述的外卖或者零售商品下图演示了通过小美自动根据历史记录点外卖。AI Coding 工具诸如 CursorClaude CodeCopilotTraeQwen Coder可以帮助程序员更快地将需求转化成业务代码。比如说请帮我优化一下当前的网站页面布局或者根据新的业务需求设计后端的数据库模型或一件生成对应增删改查的代码可以大幅度增加开发效率下面是我日常使用 copilot 进行网站开发的截图SlidevAI这是我开发的一款AI PPT生成工具。可以根据用户输入的文本素材来生成一个能够通过网页链接直接预览的 PPT。https://github.com/LSTM-Kirigaya/slidev-aislidev aideepwiki代码阅读神器。输入GitHub的仓库链接以及你的问题这套系统会帮你自动地解析目标仓库源代码并且输出对应的答案和与这个答案所对应的仓库中的代码片段以此帮助开发者更快的了解他想要了解的源代码部分。比如当你询问 deepwiki 当前这个仓库中是如何实现用户登录以及用户登录的守护中间件是如何编写的那么 deepwiki 就会把守护中间件的实现文件和与之关联的环境变量注册配置文件定义直接帮你展示出来。https://deepwiki.org/ 。下图为「询问 deepwiki 关于某项目中图像存储相关服务的实现细节」什么不是 AI Agent为了更加准确地定义 AI Agent我还想要举出一些我认为并不算这个范围内的应用。大模型对话网站大模型对话网站并不执行任务而只做一对一的文本生成。因此在我的定义中直接的大模型对话比如 deepseekchatgpt这些并不算是 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 群聊里的网页阅读助手。01什么是AI大模型应用开发工程师如果说AI大模型是蕴藏着巨大能量的“后台超级能力”那么AI大模型应用开发工程师就是将这种能量转化为实用工具的执行者。AI大模型应用开发工程师是基于AI大模型设计开发落地业务的应用工程师。这个职业的核心价值在于打破技术与用户之间的壁垒把普通人难以理解的算法逻辑、模型参数转化为人人都能轻松操作的产品形态。无论是日常写作时用到的AI文案生成器、修图软件里的智能美化功能还是办公场景中的自动记账工具、会议记录用的语音转文字APP这些看似简单的应用背后都是应用开发工程师在默默搭建技术与需求之间的桥梁。他们不追求创造全新的大模型而是专注于让已有的大模型“听懂”业务需求“学会”解决具体问题最终形成可落地、可使用的产品。CSDN粉丝独家福利给大家整理了一份AI大模型全套学习资料这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】02AI大模型应用开发工程师的核心职责需求分析与拆解是工作的起点也是确保开发不偏离方向的关键。应用开发工程师需要直接对接业务方深入理解其核心诉求——不仅要明确“要做什么”更要厘清“为什么要做”以及“做到什么程度算合格”。在此基础上他们会将模糊的业务需求拆解为具体的技术任务明确每个环节的执行标准并评估技术实现的可行性同时定义清晰的核心指标为后续开发、测试提供依据。这一步就像建筑前的图纸设计若出现偏差后续所有工作都可能白费。技术选型与适配是衔接需求与开发的核心环节。工程师需要根据业务场景的特点选择合适的基础大模型、开发框架和工具——不同的业务对模型的响应速度、精度、成本要求不同选型的合理性直接影响最终产品的表现。同时他们还要对行业相关数据进行预处理通过提示词工程优化模型输出或在必要时进行轻量化微调让基础模型更好地适配具体业务。此外设计合理的上下文管理规则确保模型理解连贯需求建立敏感信息过滤机制保障数据安全也是这一环节的重要内容。应用开发与对接则是将方案转化为产品的实操阶段。工程师会利用选定的开发框架构建应用的核心功能同时联动各类外部系统——比如将AI模型与企业现有的客户管理系统、数据存储系统打通确保数据流转顺畅。在这一过程中他们还需要配合设计团队打磨前端交互界面让技术功能以简洁易懂的方式呈现给用户实现从技术方案到产品形态的转化。测试与优化是保障产品质量的关键步骤。工程师会开展全面的功能测试找出并修复开发过程中出现的漏洞同时针对模型的响应速度、稳定性等性能指标进行优化。安全合规性也是测试的重点需要确保应用符合数据保护、隐私安全等相关规定。此外他们还会收集用户反馈通过调整模型参数、优化提示词等方式持续提升产品体验让应用更贴合用户实际使用需求。部署运维与迭代则贯穿产品的整个生命周期。工程师会通过云服务器或私有服务器将应用部署上线并实时监控运行状态及时处理突发故障确保应用稳定运行。随着业务需求的变化他们还需要对应用功能进行迭代更新同时编写完善的开发文档和使用手册为后续的维护和交接提供支持。03薪资情况与职业价值市场对这一职业的高度认可直接体现在薪资待遇上。据猎聘最新在招岗位数据显示AI大模型应用开发工程师的月薪最高可达60k。在AI技术加速落地的当下这种“技术业务”的复合型能力尤为稀缺让该职业成为当下极具吸引力的就业选择。AI大模型应用开发工程师是AI技术落地的关键桥梁。他们用专业能力将抽象的技术转化为具体的产品让大模型的价值真正渗透到各行各业。随着AI场景化应用的不断深化这一职业的重要性将更加凸显也必将吸引更多人才投身其中推动AI技术更好地服务于社会发展。CSDN粉丝独家福利给大家整理了一份AI大模型全套学习资料这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】