企业官网建设流程全解析

php网站开发cms,个人网站备案做淘宝客,请假条模板,假视频网站源码出售背景 随着整个AI业界的发展#xff0c;我逐渐发现无论是集团内外#xff0c;还是各行各业#xff0c;都有越来越多人开始关注、学习Agent#xff0c;并且开始实践、开发、部署Agent。因此#xff0c;无论是从Agent的概念#xff0c;还是具体落地方法论上#xff0c;也出…背景随着整个AI业界的发展我逐渐发现无论是集团内外还是各行各业都有越来越多人开始关注、学习Agent并且开始实践、开发、部署Agent。因此无论是从Agent的概念还是具体落地方法论上也出现了越来越多的争议和讨论当然这种思维模式和落地实践上的百花齐放也是非常有利于促进Agent这个新兴技术的持续发展的。本文我想要探讨的一个主要话题就是“如何构建真正能在业务上落地的、可用性高的Agent”。当然这个问题也是一个比较复杂、庞大的话题我无法在文中给出通用的解决方案仅仅是从阿里云服务领域的Agent构建视角出发来讨论一下我们在Agent开发和调优的过程中走过的路、踩过的坑。也希望这些方法论能够抛砖引玉、对其他领域尤其是to B领域提供一点点参考价值Agent概念的争议Agent这个技术近些年越来越火各种Agent产品也是层出不穷从早些年的各种大模型应用开发平台、大模型开源框架到后面逐步发展成各种Agent产品和Agent平台比较火的有阿里云百炼、Dify、Coze等通用Agent构建平台、AgentForce之类的垂类Agent平台以及Manus、Opeartor、AutoGLM这样的通用Agent产品还有许多如Cursor、Claude Code、TRAE这样的集成了Agent能力的AI项目。以上这些应该没有人会否认他们是Agent平台或Agent产品包括含Agent能力的项目但我也听到了许多人在Agent概念上存在着各种各样的讨论甚至是争论。究其根本原因是Agent这项技术本身还在快速发展和演化中因此会出现非常多不同的声音我认为这是很正常的。因此本文我主要将大家对于Agent概念的争论的主要矛盾点总结一下主要聚焦在以下几个方面智能体 vs 代理Agent一定是要“智能”的吗这意味着Agent是否必须是由LLM驱动满足“代理”能力的程序、代码块是否可以叫Agent自主规划 vs 工作流Agent一定是要能“自主规划”吗预定义好的规划如Workflow是否能被叫做Agent函数调用 vs 角色扮演Agent一定要实现函数调用吗如果只是通过Prompt完成一段指令是否被称作AgentAgent一定要有“人”的属性吗角色扮演类的LLM是否属于Agent关于上述这些争论我们一个一个来讨论。智能体 vs 代理首先是**“智能体”和“代理”**之争。Agent这个词在英文语境下的原始词义主要是**“代理人”的含义但是也有“代理”的含义。这里的“代理”指的是一种行为**主要指的是可以代替人来完成某些事情的行为而“代理人”这个词有一种**“人”的属性在里面像客服、助手很多时候在英文中就会翻译成Agent更接近一种有“智能”能力的生命体、智慧体。因此国内的学术界、工业界很多就给Agent翻译成“智能体”**这其实是衍生出了一个更“高大上”的中文翻译当然这么翻译也没问题更加侧重于将它的“智能化”、“自主决策”能力比较形象的刻画了出来。但是另外也有一派人认为Agent更应该翻译成“代理”这样翻译不会刻意强调其“智能化”的属性它更贴合Agent这个词在英文中的“代理”人做某件事情这个行为的本意。其次他们认为在LLM火爆之前计算机领域和AI领域也早就已经有了Agent这个技术名词了Agent并非LLM时代才有的专属名词只是LLM的出现让Agent这个技术的能力又进一步提升了一个更高的层次。比如在云计算领域我们会在弹性计算服务器ECS上安装“Agent”这个Agent指的就是一种服务器代理程序它是方便我们管理ECS资源、安全监控的一种**“代理程序”虽然阿里云将这种Agent起名叫“云助手”但这个Agent他只是一个代码程序并非真的存在“智能”能力。另外在强化学习领域也很早就有了Agent的概念跟现在LLM驱动的Agent定义上更接近了主要指的是一种可以从环境学习、感知、更新的策略模块**但这个强化学习的概念提出的也比较早这里的Agent未必一定是由大模型LLM驱动他可以是小模型比如BERT甚至也可以是一段能更新固定参数的策略代码只要符合从环境中感知、学习、更新的这个行为就可以称其为是一个Agent。因此Agent其实是一个早于LLM就有了的技术名词所以也有很多人将现在的这种更加智能化的Agent称为AI Agent或者LLM Agent来和之前的Agent程序做区分大家如果看一些相对严谨的学术文章或者技术博客确实会有在Agent前面加一些前缀其目的就是为了避免与其他Agent混淆让大家搞不清这篇文章究竟是在讲哪种Agent。自主规划 vs 工作流另外一个争论比较多的就是Agent是不是应该必须要有**“自主规划”**能力。这个争论其实也是由“智能体”vs“代理”之争引申而来的Agent如果定义为“智能体”那么他必须得有自主规划的能力因为只有真正遇到问题的时候能自己规划、分解、解决问题才有了一种生命体、智慧体的感觉才更符合大家对于“智能体”这个词的认知。然而认为Agent是“代理”的人也会很自然而然的认为只要Agent能够完成代理的这个行为它就可以被称为是一种Agent因此不一定非要强调Agent的自主规划能力通过LLM或者程序硬编码等方式即使按照人工提前预编排好的流程Workflow它能一步一步执行下去这也是一种代理模式因此也符合Agent代理的概念。所以这一派会认为无论是大模型自主规划、还是Workflow预先编排只要能实现**“代理完成任务、解放生产力”**这个过程他就是一种Agent。下面是LangChain的一张描述Workflow和Agent的区别的图[3]Workflow是通过预编排的流程来控制LLM作为嵌入节点或者用LLM直接来控制流程而Agent则是大模型自主进行环境感知作出反馈。而左侧这种继承了LLM能力的Workflow是否属于Agent是目前存在争议的地方。随着技术的发展现在越来越多出现了Workflow和Agent的各种交叉组合比如Agentic的Workflow可以理解为是大模型自主规划的Workflow大模型遇到复杂任务的时候先生成Workflow然后按照Workflow去运行还有基于Workflow来构建的Agent或者Multi-Agent是在Agent外层大的框架是由Workflow设定的避免发散跑偏但内部的模块是LLM驱动的可以根据具体情况自主决策。即使是像Manus/OpenManus这样的“通用AI Agent”我们仔细来看其外部也是有一个大的Workflow框架来约束LLM的规划步骤确保LLM不会彻底让流程发散失控但其内部的每个节点都是由LLM进行自主规划以实现更加灵活的效果最终展示出来的也是一种很高度智能化、但同时又相对稳定的通用Agent效果所以现在来看Workflow和Agent已经是相互依赖、相辅相成的关系了无法彻底切割清楚。函数调用 vs 角色扮演第三个争论点聚焦在Agent承担的任务范围和交互形式上。如果我们把Agent看做是“智能体”的概念那么很容易会想到它要有一定的“人设”所以很多人认为角色扮演这类才属于Agent必须要有一个“拟人”的属性在类似“数字人”的概念比如可以是一个云计算领域“专业客服工程师”、可以是一个“三甲医院的专家医生”也可以是你喜爱的某个动漫人物、角色等。即使是仅仅是写了一个人设写一段Prompt使用LLM来运行哪怕不需要规划、子任务分解、函数调用只要有人设这就算是一种Agent。而将Agent看做“代理”的人会认为Agent的重点不一定要有“拟人化”的属性只要能完成规划、问题分解甚至只要有函数调用就可以认为是一种Agent因为Agent只要是接入了函数调用能力能够代理完成某个具体任务这类大模型甚至是程序就可以被认为是一种Agent。Agent的概念梳理看完上面的各种派别是不是感觉已经绕进去了Agent由于概念的特殊性不同人、不同企业、不同学者对它的认知其实是有较大差异的会出现很多不同的理解这个其实也很正常因为很难统一所有人的想法而且也不需要统一所有人的想法这些想法的多样性正恰恰促进了Agent这项技术的不停发展和革新。前段时间吴恩达有一个采访[1]里提到了一段话他指出当时很多人在争论“这个系统到底是不是 Agent”、“它是否真正具备自主性”但这类争论本身并没有太大价值。与其浪费时间在这些语义层面的问题上不如换一种方式思考。他提出“agenticness 是一个光谱”的概念不同系统具有不同程度的 agenticness从几乎无自主性到高度自主都是合理的存在只要系统具备一定程度的自主性都可以归入 agentic 系统的范畴。“如果你想构建一个具备一点点或者很多自主性的 agentic 系统那都是合理的。没必要去纠结它是否‘真正是 Agent’。”吴恩达说。吴恩达所说的这个系统里的agenticness类似是一个光谱指的是一个系统自主性的程度可能是从完全没有智能能力到非常智能化的场景因此这个agenticness是一个光谱。为了让大家更好的理解Agent我们暂且把Agent定义的分成**“广义的Agent定义”和“狭义的Agent定义**”两种类型。狭义的Agent定义即理想状态下的“Agent”是一种“智能体”能够听懂人的自然语言指令完成复杂任务的自主规划、分解、执行、反思、决策等有较强的主观能动性无需人为干预其内部细节。广义的Agent定义更侧重于“自动化的任务代理”不纠结于是否以大模型为基础可以通过大模型、小模型、硬编码、规则引擎等在内的一种或多种技术的混合以帮助人自动化完成任务为主要目标。从这里能看到广义的Agent概念里是包含了狭义Agent的目前国内外许多企业研发的Agent平台其实都在“广义Agent定义”的范畴里因为“狭义的Agent定义”目前来看还是一种**“技术理想主义”**是一个我们需要不断努力为之奋斗的、美好的目标。然而现实是比较残酷的“狭义的Agent”虽然构建起来很简单任务要求全盘交给大模型来做即可 但是效果的稳定性不佳落地过程中有太多的问题导致大家不得不采用各种各样的方法来约束Agent时期更加可控所以说想要做到理想状态下的大模型自主决策现在技术还不够成熟。Agent落地过程中的挑战“如何构建Agent”的问题已经有很多的文章在讨论了比较好的一篇文章是Anthropic的《Building Effective Agents》[2]这里面已经给出了许多构建Agent的范式和方法论大家可以去阅读参考。本文更希望讨论的是如何构建更加“高可用性”的Agent。前文说到“狭义的Agent”是一种技术理想主义至少在现阶段的大模型的能力上还是不够完善和成熟的无法做到完全达到预期的智能化因此在这种背景下大家在Agent构建落地的过程中很容易遇到非常多的挑战和问题因此接下来我希望能在文章中探讨这些具体挑战应该如何解决从而能总结出如何构建更加容易落地、更加高可用的Agent。我总结了下Agent构建过程中的问题大致可以分为以下四大类。挑战一运行效果不稳定构建Agent非常重要的一项工作就是提示词Prompt。提示词通俗来讲其实就是用自然语言描述一下任务要求看起来其实很简单但实操过的话大家会很容易发现想要写出一个能够稳定运行的提示词并不是很容易甚至大家有的提示词写出来像小作文一样长越写越复杂复杂。而且写完之后提示词在运行过程中很容易出现不稳定的情况然后还要不断去调优它甚至出现无论怎么调优Agent依然不稳定的情况这是非常痛苦的一点。挑战二规划如何平衡第二个痛点之前我们讲到广义的Agent里面是有很多种技术方案的大致上可以分为大模型自主驱动的以及Workflow预编排的类型。然而大模型自主驱动的模式也是很容易不可控的可能我的预期是这样运行但它自己经过规划、执行、反思、总结之后变成了另外的方向甚至完全走偏这都是很有可能的。然而如果通过Workflow的方式去做规划又需要投入大量人力成本去编排导致Agent的构建也会非常低效有时候要好几天才能搞出一个相对完善的Workflow这就让Agent的构建成本越来越高因此怎样去平衡规划的问题也是一个比较痛的点。挑战三领域信息集成第三个挑战就是如何将领域信息或者领域知识注入到大模型里面。因为大家很多时候用的模型都是通用领域的基座大模型或者开源的基座大模型基本上都不具备领域垂类的知识信息因此大模型对于领域特定词汇、特定知识、甚至领域特定流程的理解上就都会很难理解因此怎样合理的把领域知识注入到Agent里面也是一个挑战。挑战四Agent的响应速度第四个痛点是Agent的响应速度问题。如果将Agent上线到生产环境中作为需要稳定运行的一段程序这时候性能问题就变得非常重要。大家会发现大参数的模型运行Agent的效果还不错但速度实在是非常慢尤其是带有思考的推理模型要更长的时间。而小参数的模型虽然速度快了很多但运行Agent的效果又一般经常不稳定。运行性能和推理效果是呈反比的关系这也是让很多人对Agent落地比较头痛的一个问题。从提示词调优出发首先看第一个挑战Agent运行效果不稳定。Agent运行不稳定大概率是提示词书写不当导致的不稳定。提示词确实还是不太容易写好的一般情况下直接写很容易出现下面的问题提示词过短任务要求主体不明、表意不明、模糊不清模型在不清晰的情况下只能“脑补”按照自己的理解来执行任务容易与预期不符。提示词过长注意力失焦重点遗忘现在的模型虽然都有长上下文的窗口但从实际情况来看当提示词比较长的时候模型在运行过程中很容易顾头不顾尾导致有些指令遵循有些不遵循。提示词中存在冲突、矛盾等这个很可能你自己都没有意识到提示词的冲突这会让模型理解起来有些困困惑。模型会在运行过程中一会儿遵循你的某一条要求一会儿遵循你的另一条冲突的要求导致不稳定。具体如何写提示词的文章、教程公司内外各大平台如ATA、知乎、掘金等等已经非常之多了在这里我不会具体去讲如何写提示词的结构和书写规范这些而是关注在当我写完一套提示词如果效果不好该如何解决我们的解法最开始是提供一套提示词模板。这些模板经过大量调试、测试发现运行已经比较稳定了。然后让写提示词的同学尽量遵循这个模板来写相对来讲就比每个人直接写要更容易稳定。但我们后来发现这个方式也有些问题很多时候大家过度套用模板不需要写的内容也一定要生搬硬套写进来或者模板有好几套也不知道该选择用哪套。写的过程中也会出现一些跟模板冲突的问题等等。之后我们采用AI辅助做提示词生成和调优把提示词模板给到AI结合你的需求先写一版你来确认提示词的逻辑是否正确如果有问题你可以及时跟AI提出来去调整然后由AI来帮你继续调优。比如说冲突、矛盾的部分AI就是可以检测出来的它可以告诉你这其中某些要求和另外一些要求之间是有逻辑问题的。因为“最懂大模型的是大模型自己”所以我们可以先搞清楚大模型的“脑回路”才能更好的让大模型理解我们的需求可以不断的和大模型进行沟通持续迭代的把提示词整理优化出来再让它自己去运行这个提示词来看效果到底是否符合预期。Agent规划层的权衡第二个挑战规划如何平衡。这里的规划Planning主要指的是Workflow和大模型自主规划如何权衡的问题。这里我参考LangChain的Blog画了一张图[4]来表达Workflow和自主规划的可控性和智能化能力很显然会看到一个规律LLM自主规划的智能化程度越高可控性越低而Workflow编排的可控性越高则智能化则越低。可控性高但智能化要求低的场景通常是一些标准化、重复执行的场景更适合Workflow。从阿里云客户服务领域的视角来看什么样的场景适合Workflow呢比如订单财务类就是典型的标准化场景举个例子要去查询某个订单有没有过期或者要计算是否需要退订部分费用这些都是标准化的如果这类逻辑判断、数学计算类的场景让大模型深度参与就很容易出现幻觉。再比如排班类场景也是类似需要定时提醒客服具体的排版时间这类情形需要严格按照排班表去推送如果出现幻觉比如遗漏了某些同学没提醒到位就可能会导致他没有按时上班那就非常麻烦。所以像这些场景我们为了避免出现这些不稳定、幻觉的问题就可以选择通过Workflow的方式实现确保可控性优先适当降低自主性和智能化。但智能化要求较高的场景通常是一些探索化、问题复杂的场景更适合大模型自主规划。比如RDS数据库的实例异常诊断一般客户来咨询的时候就只是描述说“我的RDS查询非常缓慢”或者“实例有异常”这类描述一般都比较模糊但用户也很难给出更多信息了因为这确实是需要我们要进入实例仔细排查、诊断的。比如需要诊断数据库的会话连接数有没有异常QPS有没有异常内存、慢SQL是不是都有可能导致这个问题因此它涉及到的可能性就非常之多很难通过一个大而全的Workflow去承载所有的可能性。如果针对这些场景要编排一个Workflow出来可能要非常庞大而且可能会出现很多排列组合的分支判断这很可能会容易崩溃掉。这类场景就比较适合用大模型自主决策因为首先大模型在训练阶段就学习过RDS数据库基础的技术语料再结合我们通过提示词给它几个大的方向比如检查会话连接数、CPU、内存、慢SQL等方向进行排查它就能知道结合用户输入的问题排查RDS异常时大概从哪几个维度开始就可以通过我们的工具API去自主查询、诊断、决策、解决这些问题。它不一定要全部诊断完成根据前一步的诊断结果再进一步决定下一步要如何决策这样一步步走下去就非常适合用大模型自主规划。还有一种场景比较适合大模型自主规划的是Agentic RAG。阿里云客户服务场景中有许多的中长尾产品或场景尤其是长尾产品我们其实不一定都有梳理好的知识库但是能找到相应的官方文档或者用户手册。在没有高质量的知识的情况下又需要去解决这些问题就可以用Agentic RAG的方式让大模型自主生成搜索的query搜索完成之后再进一步自主检查、反思搜索结果是否符合预期然后决定是否自主去调整query重新搜索进行这种更加deep search的搜索最终经过多次搜索、检验的过程找到最合理的答案。这种场景也非常适合大模型自主规划模的式。那么这两种情况是上面曲线图最两端的情况能否实现上面曲线的中间状态呢答案是可以如果想要实现上面曲线图里的中间状态就需要做到LLM自主规划与Workflow相结合也就是使用Multi-Agent多智能体架构来实现。在阿里云服务领域有个场景是“邮箱无法收发信诊断”客户来咨询的时候一般会说我邮箱无法收发信了有的用户会把邮箱账号发过来有的用户会把邮箱域名发过来有的用户会直接把具体报错发过来可能性比较多。但排查邮箱账号的状态和域名状态还有报错的时候这些中间过程是可以编排一个确定性的排查过程的所以我们就把这些中间过程做成了稳定、可控的Workflow但是为了应对客户可能的多种不同类型的输入形式为了让模型更加自主灵活的决策调度于是在这些Workflow的外面我们又使用一个LLM来动态决策调用哪个Workflow实现了一种**“内部稳定可控外部自主灵活”**的效果。那么这种“内可控、外自主”的模式就是一种基于Multi-Agent实现的模式那么也可以反过来比如“外可控、内自主”比如前文提到过的Manus/OpenManus也是外面有一个大的Workflow框架内部的每个节点都是由LLM进行自主规划的模式。Workflow的演化路径探索LLM自主规划这个其实主要就是提示词在驱动大模型完成复杂任务大部分的过程也是都是模型黑盒的内部决策 实际上没有太多技术上的方案。但是在Workflow这块的探索其实就有非常多模式了。在这里我也想花点篇幅分享一下我们在Workflow这条路上探索过的一些演化路径。首先由于我们的Agent平台是面向客服和业务同学的因此我们最开始的一版的Workflow实现就树立了一个“尽可能降低用户编排Workflow的成本和复杂度”的目标因此就让用户用自然语言来编排Workflow当时的设计思路是“自然语言编排流程图LLM驱动按步执行”。具体的操作过程就是让用户先用自然语言描述出你的流程然后通过AI大模型来帮你生成流程图DAG图然后让大模型驱动按照流程图一步一步执行直到最终完成整个流程节点。这样做的好处是构建方法和成本确实很低自然语言描述即可允许可以编排一个**“不完备”**的流程图大模型运行过程中也会智能化的识别每个步骤的任务要求自动补充节点之间的参数衔接问题。但也有其问题比如运行速度太慢因为每个环节都要大模型决策节点一旦比较多全部走完一遍要很长时间并且只能从头开始执行一路到结尾暂时无法从中间某个环节直接进入。所以后来为了提升速度和稳定性我们就做了第二种Workflow是“代码/大模型混编 规则驱动按步执行”为了节省时间不需要全部节点都用大模型来驱动而且改用规则引擎驱动。用户描述流程还是通过自然语言的方式描述但经过大模型AI转换成流程图之后所生成的流程图中间的节点除了必须用大模型来生成、总结的情况之外其他节点类型你都可以用代码、脚本、规则来实现类似一种离线的预编译过程尽可能减少大模型带来的耗时增加、幻觉、不稳定性的问题将这些逻辑固化为代码、规则。经过这样的设计我们发现运行速度确实变快了很多但依然只能从头执行到尾如果中间过程出现一些客户的问题发生了转移或者跳转我们没办法做非常灵活的控制同时由于引入了代码和大模型的混合编排导致Workflow的构建成本比纯自然语言的形式高了很多因为规则引擎驱动的流程图必须是**“完备”**的流程图节点之间的参数传递必须准确无误否则就会报错因为大部分客服和业务同学很难直接介入对代码、规则的调优导致Workflow的构造过程门槛变的很高AI生成的流程图很多时候也并非完全完备导致构建过程频繁出现各类问题需要花费大量人力去调试。之后由于更加灵活的场景的需要我们需要大模型更灵活的在Workflow的流程的多个节点或者分支之间可以更灵活的识别和流转我们演化出第三种Workflow思路即**“自然语言编排 大模型自主规划执行”。自然语言编排过程与第一种没有什么太大差别也还是自然语言描述然后AI转换成“不完备”**的流程图即可但是在运行的时候不是让大模型从头一步一步运行到结束而是大模型基于这个流程图直接去回复客户执行相应动作。也就是说我们不让大模型完全自己发挥去做规划而是用这张流程图作为参考信息给大模型去做类似RAG的这种参考规划这样的模式相比前两种模式更加灵活、更加智能。目前这三种Workflow模式我们是并存的在实际场景中具体应用哪一种更合理是要具体问题具体分析的没有一种完全完美的解决方案。领域数据集成与响应速度优化另外还有两个挑战一个是领域数据集成的问题另一个是响应速度优化的问题我放在一起说下。首先如何在通用基座大模型中集成领域数据这块主要有下面三个方法Prompt中动态领域要求根据服务场景匹配度在Prompt加载的过程中动态引入领域先验知识通过类似RAG的方式根据场景动态搜索和匹配加载领域的知识或者业务经验能够更好的让模型了解领域知识通常又不会占用太多的上下文窗口引入外部技能通过调用领域工具、知识库、文档等让LLM有更多方式自主选择获取领域数据可以通过让模型自主选择在某些场景下是不是可以自主决策调用这些工具、知识库、文档能够额外引入一些动态的领域信息领域大模型训练在上面的方法实在搞不定领域知识理解的情况下可以通过训练领域大模型来注入领域知识将领域知识通过模型预训练、后训练等多阶段的训练可以将领域知识注入到大模型中从根本上提高领域任务的精准性但成本相对较高比如先构造领域数据源比如领域知识库、文档SOP工具API、各领域产研提供的一些MCP Tools、阿里云的OpenAPI。接下来经过汇总、清洗构造成语料包括单步工具调用、多步工具调用、反问澄清、Multi-Agent调用、条件判断、场景拒识等等然后给模型去做SFT/DPO/GRPO等等。评估的方式也有多种比如说工具选择准确率、动作执行准确率、参数提取准确率以及模型生成回复的效果评估。最后模型可以在线上推理、规划、动作、观察反思、生成等环节得到相比通用模型更好的效果。另外一个痛点是Agent的执行速度问题大参数的模型速度慢、小参数的模型效果不好应该如何解决呢我们也有一些探索过的方法论给大家分享一下代码参数预转换在前文Workflow演化路径的这个探索过程中我有提到可以尽量减少Agent中大模型参与的比例比如使用流程预编译好的Workflow将非必要的LLM模块转换为代码或脚本语言来提高运行效率各种推理加速方式通过各种加速推理的优化方法来提升模型的运行效率比如模型量化Int4、int8等、优化KV Cache、使用各种加速框架如FlashAttention、vLLM等、更换高性能GPU等降低模型参数量在满足需求的前提下选用小参数模型如果这是高频场景比如Function call那就非常适合小参数模型用大参数量的LLM作为教师模型去蒸馏小参数量的LLM也可以在提高速度的同时尽量保留大参数模型的推理效果。Agent构建和持续调优的路径根据上面的一些调优的方法论我最后总结了一个Agent构建和持续调优的路径图如下所示。首先在尝试使用Agent来解决一个需求问题的时候可以先从大模型自主决策的方式构建一个原型Demo的Agent因为通过提示词工程先做一版Agent是ROI最低的方式先通过简单的实现看下初始的Agent版本形态是否符合业务或自己的需要。然后在提示词的基础上按照上文所属的让提示词更稳定的调优方法多次调优几个版本看看是否能保持稳定的运行。如果发现效果依然不好在某些情况下总是出现不稳定的情况可以尝试第二步在Agent的规划Planning层面开始尝试拆解Workflow通过构造更加结构化的Workflow来让Agent在一定的框架范围内驱运行来提高它的稳定性同时Workflow如果使用代码规则编排也可以提升其运行速度达到一些性能上的要求。如果发现Workflow的方式虽然稳定但智能化能力变弱开始出现固化、不灵活等情况或者分解了Workflow依然搞不定比如说我需要某些地方足够的灵活又需要某些环节足够可控我们就需要设计更加复杂的Multi-Agent架构通过将复杂任务拆解成多个子任务通过多个子Agent来承接这些子任务并设计多个子Agent之间的通信方式和形态最后进行端到端的测试看这样部分灵活部分可控的方式是否能够满足复杂场景下的要求。最后如果实在前面的方式都尝试了某些情况下还是很难调优或者对准确率、速度、稳定性、智能化能力都有着极高的要求那么就需要对这个Agent的一些关键环节做模型的定制化训练和调优了这个步骤一版是先确定要训练的任务然后需要花较大的经历去寻找和构造所需的训练数据之后做相应的模型训练和调优。最终来验证经过训练后的模型对相应的任务问题是否能到达预期。从使用提示词开始构建原型到Workflow的构造、Multi-Agent架构设计、模型的训练和调优这个成本是随之不断的在上升的但理想情况下Agent的运行效果也是随着成本的投入在不断得到提升至于要做怎样的技术选项、投入多大成本最后达到怎样的效果这取决于你的场景的具体要求。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…学习是一个过程只要学习就会有挑战。天道酬勤你越努力就会成为越优秀的自己。如果你能在15天内完成所有的任务那你堪称天才。然而如果你能完成 60-70% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】