【用AI学Agent】Agent入门前置:大模型基础(开发向)

【用AI学Agent】Agent入门前置:大模型基础(开发向)
首先欢迎大家点进文章,其次

申明:本系列内容是作者通过AI学习Agent得到的内容,如若有错误之处,欢迎批评指正

很多想入门AI Agent开发的朋友,例如我,第一步就被“大模型”的各种概念绕晕——上下文窗口、Token、温度、思维链,这些到底是什么?和Agent有什么关系?

其实不用慌,Agent的核心是“让AI自主做事”,而大模型(LLM)就是Agent的“大脑”——不懂大脑的工作原理,后续学RAG、工具调用、Agent架构都会很吃力。

这篇博客专门为Agent学习者打造,包含开发中能直接用到的大模型基础知识点,从“是什么”到“怎么用”,帮你夯实Agent入门的第一块基石。

一、大模型(LLM)到底是什么?

  • 很多人对大模型的理解有误区,觉得它“无所不能”,能像人一样思考、理解世界;
  • 也有人觉得它“只是个问答机器人”,没必要深入学习。

其实这两种想法都不对。

用最通俗的话讲:大语言模型(LLM),就是基于海量文本数据训练出来的、能预测“下一个词”概率的模型

  1. 它不“理解”,只是“拟合”:大模型没有真正的意识,不会像人一样思考、推理(至少目前不会)。它的所有输出,都是基于训练数据中“词与词的关联规律”,预测出最可能出现的下一个词、下一句话。比如你输入“今天天气很好,我想出去”,它会预测出“玩”“散步”等词,因为训练数据中,这些词经常和前面的句子关联在一起。
  2. 核心能力来自“海量数据”:大模型的训练数据涵盖了互联网上的文本、书籍、论文、代码等,量级达到千亿、万亿级。正是因为“见多识广”,它才能拟合出各种语言模式,实现理解、生成、总结等能力。
  3. 它是Agent的“核心大脑”:Agent能自主决策、拆解任务、调用工具,本质上是靠大模型的“理解能力”和“推理能力”——大模型负责读懂用户需求、判断下一步该做什么,而Agent的其他模块(记忆、工具调用),都是为了弥补大模型的不足,让它能“落地做事”。
总结:大模型是Agent的基础,没有大模型,Agent就没有“思考能力”;但只有大模型,也成不了Agent(因为大模型不会主动行动、不会记忆长期信息)。

二、核心基础概念

这部分是重点,也是很多新手容易踩坑的地方。这些概念不仅要懂,还要知道在Agent开发中怎么用、怎么调,后续做项目时能少走很多弯路。

1. 上下文窗口(Context Window)——大模型的“记忆上限”

上下文窗口,简单说就是大模型能“记住”的最大文本长度。就像人有短期记忆,只能记住最近说的几句话,大模型也有“短期记忆上限”,超过这个上限,它就会遗忘前面的内容。

关键细节(开发必看):

  • 单位是Token:上下文长度不是按“字数”算,而是按“Token”(词元)算,后面会详细讲Token。
  • 常见长度及用途
    • 4k/8k:适合简单对话、短文本生成(比如简单的客服回复、单轮指令执行);
    • 16k/32k:适合多轮对话、中等长度文档处理(比如Agent的多轮任务拆解、短文档检索);
    • 128k及以上:适合长文档处理、复杂任务(比如Agent处理长篇报告、学术论文调研)。
  • 对Agent的影响(重中之重):Agent需要记住用户需求、任务步骤、中间结果,这些都要占用上下文窗口。如果上下文窗口太小,Agent会“记不住”前面的任务,导致决策失误、任务中断。比如做一个“数据分析Agent”,需要处理大量数据描述和步骤,就必须选择16k以上上下文的模型,否则会遗忘关键数据。
  • 注意:不要盲目追求大上下文窗口,窗口越大,模型响应速度越慢、成本越高。根据Agent的任务场景选择即可——比如简单的文案生成Agent,8k窗口完全足够。

2. Token(词元)——大模型的“最小计算单位”

Token是大模型处理文本的最小单位,相当于我们说话的“音节”、写字的“笔画”,大模型所有的计算(上下文长度、计费、生成),都是以Token为单位的。

关键细节(开发必看):

  • Token与字数的换算
    • 中文:1个汉字 ≈ 1个Token(少数复杂汉字可能占2个,比如生僻字);
    • 英文:1个单词 ≈ 1~3个Token(短词如“a”“the”算1个,长词如“artificial intelligence”算2个);
    • 标点、空格、换行:都会占用Token(比如逗号、句号、空格各算1个Token)。
  • 实用工具:开发时可以用模型厂商提供的Token计算器(比如OpenAI的Token计算器、文心一言的Token估算工具),提前估算输入输出的Token数量,避免超过上下文窗口,也能控制成本。
  • 对Agent的影响:Agent的对话轮次、任务描述、工具返回结果,都会占用Token。比如Agent处理多轮对话时,每一轮的提问和回复都会累计Token,当累计量接近上下文窗口上限时,就需要做“上下文压缩”(比如总结前面的对话核心),否则会遗忘内容。

3. 生成参数(开发必调,决定输出效果)

大模型的输出不是固定的,我们可以通过调整生成参数,控制输出的“确定性”“多样性”“长度”,适配不同的Agent任务场景。其中最常用、最关键的3个参数,必须掌握。

(1)temperature(温度)——控制输出的随机性

temperature的取值范围是0~2,核心作用是控制模型输出的“冒险程度”,直接影响输出的确定性和多样性。

详细解读(结合Agent场景):

  • temperature = 0:输出最确定、最保守,不会有任何随机内容,甚至会重复输出。适合Agent的“精准执行”场景,比如代码生成、数据计算、固定格式输出(如JSON)——要求结果准确,不能有偏差。
  • temperature = 0.1~0.3:轻微随机,输出既准确又不会太死板。这是Agent开发的常用范围,比如任务拆解、工具调用决策、多轮对话回复——既保证决策正确,又能应对轻微的需求变化。
  • temperature = 0.5~1.0:随机性中等,输出会有一定的创意。适合Agent的“创意生成”场景,比如文案撰写、方案构思——需要一定的灵活性,但不能太离谱。
  • temperature > 1.0:随机性极强,输出可能天马行空,甚至出现“胡说八道”(幻觉)。不适合Agent开发,除非是纯创意生成场景(如诗歌、小说),否则不推荐使用。

避坑点:Agent开发中,尽量不要把temperature设为0(容易重复),也不要超过0.5(容易出现幻觉),0.2左右是最稳妥的选择。

(2)top_p(核采样)——控制词汇多样性

top_p和temperature类似,都是控制输出的多样性,但逻辑不同:temperature是调整“概率分布的陡峭程度”,top_p是选择“概率累加和达到某个阈值的词汇集合”。

详细解读(结合Agent场景):

  • 取值范围是0~1,值越小,词汇集合越窄,输出越确定;值越大,词汇集合越宽,输出越多样。
  • Agent开发中,推荐取值0.1~0.7:比如做工具调用决策时,top_p设为0.3,模型会只从概率最高的30%的词汇中选择,保证决策的准确性;做文案生成时,top_p设为0.7,兼顾准确性和创意。
  • 注意:temperature和top_p不要同时调整,一般只调整其中一个即可——比如调整了temperature=0.2,就不用再调整top_p,默认0.9即可。
(3)max_tokens——控制最大生成长度

max_tokens是控制模型单次输出的最大Token数量,相当于给模型的“输出篇幅”设一个上限。

详细解读(结合Agent场景):

  • 设置太小:模型输出不完内容,比如Agent拆解任务时,只输出了2个步骤就被截断,导致任务无法执行;
  • 设置太大:浪费Token、增加响应时间,甚至可能出现冗余内容(比如重复描述),增加成本;
  • 实用技巧:根据Agent的任务场景设置——比如工具调用的参数输出,max_tokens设为100~200即可;任务拆解的步骤输出,设为500~1000即可;长文本总结,设为1000~2000即可。

4. 大模型的能力边界(Agent存在的核心原因)

我一开始误以为大模型无所不能,只要调用大模型API,就能实现Agent的所有功能。其实不然,大模型有天生的缺陷,而这些缺陷,正是Agent、RAG、工具调用存在的核心原因——Agent本质上就是“弥补大模型的不足,让它能落地做事”。

大模型的4个核心缺陷:

  1. 没有实时信息(知识截止期):大模型的训练数据有一个“截止时间”(比如GPT-4截止到2023年10月,文心一言截止到2024年3月),截止时间之后的信息,它完全不知道。比如你让大模型查“2024年的GDP数据”,它会无法回答——这就是Agent需要“工具调用”(调用联网工具)的原因。
  2. 不会主动行动:大模型只会“被动响应”,你问它什么,它答什么;你不指令它,它不会主动去联网、查文件、执行代码。比如你让它“分析某份Excel数据”,它只会告诉你分析步骤,不会主动去读取Excel文件——这就是Agent需要“执行模块”的原因。
  3. 不会精确计算、逻辑推理易出错:大模型对数字不敏感,做加减乘除、复杂逻辑推理时,很容易出错(比如10086+12345,它可能算错)。比如你让它“计算某组数据的平均值”,它可能给出错误结果——这就是Agent需要“工具调用”(调用计算器、Excel工具)的原因。
  4. 会产生幻觉(一本正经地胡说):大模型会基于训练数据的模式,生成看似合理但实际错误的内容,比如编造不存在的论文、错误的知识点。比如你让它“介绍某篇冷门论文”,它可能会编造论文的作者、结论——这就是Agent需要“RAG(检索增强)”和“结果校验”的原因。

总结:大模型是“大脑”,但它有“近视”(没有实时信息)、“手脚不便”(不会主动行动)、“算数差”(不会精确计算)、“爱吹牛”(幻觉)的问题,而Agent就是给这个“大脑”配上“眼睛”(RAG)、“手脚”(工具调用)、“记忆”(记忆系统),让它能自主、准确地完成任务。

三、大模型的两种核心能力

大模型能成为Agent的“大脑”,核心靠两种能力——理解能力和生成能力。这两种能力是Agent实现任务拆解、决策、执行的基础,必须搞懂它们的具体应用场景。

1. 理解能力——Agent的“感知力”

理解能力是大模型最基础的能力,指的是“读懂自然语言、提取关键信息、做出判断”的能力。对Agent来说,理解能力就是“听懂用户需求、看懂任务场景”的能力。

具体应用场景(Agent开发中常用):

  • 提取用户意图:比如用户输入“帮我分析一下这个月的销售数据,找出下降的原因”,大模型能理解用户的意图是“数据分析+问题定位”,并提取出关键信息“这个月、销售数据、下降原因”;
  • 实体提取:比如用户输入“明天下午3点,在公司会议室开产品复盘会,参会人有张三、李四”,大模型能提取出时间(明天下午3点)、地点(公司会议室)、事件(产品复盘会)、参会人(张三、李四);
  • 分类与判断:比如Agent接收到工具返回的信息,大模型能判断“这个信息是否符合任务需求”“下一步是否需要继续调用工具”;
  • 总结与提炼:比如Agent获取到大量的网页信息,大模型能总结出核心内容,避免信息冗余,节省上下文空间。

2. 生成能力——Agent的“表达力”

生成能力是大模型的核心输出能力,指的是“根据输入,生成符合要求的文本”的能力。对Agent来说,生成能力就是“输出决策、步骤、结果”的能力。

具体应用场景(Agent开发中常用):

  • 生成自然语言回复:比如Agent完成任务后,向用户反馈结果,用自然语言解释“做了什么、得到了什么结果”;
  • 生成结构化输出:这是Agent开发中最常用的能力——比如生成JSON格式的工具调用参数({"tool":"search","parameters":{"keyword":"2024年GDP数据"}})、生成任务步骤的列表(1. 调用联网工具查数据;2. 调用Excel工具分析数据;3. 总结结果);
  • 生成思考过程(思维链):这是Agent实现“自主决策”的关键——让大模型生成“为什么这么做”的思考过程,比如“用户让我分析销售数据下降原因,首先我需要调用工具获取这个月的销售数据,然后对比上个月的数据,找出下降的品类,再分析该品类的市场环境,最后总结原因”;
  • 生成代码:比如Agent需要处理数据,大模型能生成Python代码(如Pandas处理Excel数据),然后调用代码执行工具运行代码,得到结果。

四、思维链 CoT(Chain-of-Thought)——Agent自主决策的关键

很多新手学Agent时,会疑惑:“为什么大模型能做出复杂的决策?”核心答案就是——思维链(CoT)。

什么是思维链?简单说,就是让大模型“先思考,再回答”,把思考过程清晰地呈现出来。就像人做复杂任务时,会在心里一步步盘算“第一步做什么、第二步做什么、为什么这么做”,思维链就是让大模型把这个“盘算过程”写出来。

1. 思维链的核心作用

没有思维链,大模型的输出会“跳跃”,比如用户让它分析销售数据下降原因,它可能直接给出“因为市场竞争激烈”,但没有任何推理过程,无法判断这个结论是否正确,也无法排查错误;

有了思维链,大模型会一步步呈现推理过程,比如:

用户需求:分析这个月销售数据下降的原因。

思考过程:

1. 首先,我需要获取这个月的销售数据,包括总销售额、各品类销售额、环比数据(和上个月对比);

2. 调用工具获取数据后,发现总销售额环比下降15%,其中A品类销售额下降30%,其他品类基本持平;

3. 接下来,需要分析A品类下降的原因,可能的因素有:市场竞争加剧、产品质量问题、营销活动不足、用户需求变化;

4. 调用联网工具查询A品类的市场环境,发现竞争对手推出了同款低价产品,抢占了市场份额;

5. 调用内部营销数据,发现这个月A品类没有开展任何营销活动,而上个月有大型促销活动;

6. 综合以上信息,得出结论:这个月销售数据下降的主要原因是A品类受竞争对手冲击,且未开展营销活动。

结论:这个月销售数据环比下降15%,核心原因是A品类受竞争对手低价产品冲击,且本月未开展营销活动,导致销售额下降30%,拉低了整体业绩。

这种思考过程,就是思维链。它的核心作用有两个:

  • 提升决策准确性:一步步推理,能减少大模型的幻觉和错误,比如如果发现某个步骤的数据有误,能及时修正;
  • 支撑Agent自主循环:Agent的“思考→行动→观察→再思考”循环,本质上就是基于思维链的——大模型通过思考过程,判断下一步该调用什么工具、执行什么操作,然后根据工具返回的结果,再调整思考过程,继续推进任务。

2. 如何在Agent中使用思维链?

很简单,通过Prompt(提示词)引导大模型生成思维链即可。比如在System Prompt中加入:“请先呈现你的思考过程,一步步拆解任务、分析问题,再给出最终结果或决策”。

举个Agent工具调用的Prompt示例:

你是一个数据分析Agent,负责帮用户分析销售数据。请先呈现你的思考过程,一步步拆解任务,判断是否需要调用工具,调用什么工具,再执行操作。工具包括:1. 销售数据查询工具(可获取各月份、各品类销售数据);2. 联网工具(可查询市场环境、竞争对手信息);3. Excel分析工具(可进行数据计算、对比)。

这样,大模型就会按照思维链的方式,一步步推进任务,而不是直接输出结果。

记住:Agent本质 = LLM + 思维链 + 工具 + 循环——思维链是连接LLM和工具、循环的核心。

五、主流大模型分类(Agent开发选型用)

学完基础概念,接下来就是实际开发中的“选型”——选择哪个大模型,直接影响Agent的开发难度、成本、效果。根据部署方式和开源情况,主流大模型分为两类,各有优缺点,适合不同的Agent场景。

1. 闭源商用模型(直接调用API)

这类模型由大厂开发,不开放源代码,只能通过API调用,需要付费(按Token计费)。优点是性能强、稳定性高、开发成本低,适合快速落地Agent项目;缺点是成本较高、无法私有化部署(敏感数据场景不适用)。

主流闭源模型(Agent开发常用):

  • GPT-3.5 / GPT-4(OpenAI):目前最主流、最常用的模型。GPT-3.5性价比高,响应速度快,适合大部分Agent场景(如任务拆解、工具调用、文案生成);GPT-4性能更强,推理能力、理解能力更好,适合复杂Agent场景(如深度调研、复杂代码生成、多智能体协作)。
  • 文心一言 ERNIE(百度):中文支持更好,适合中文场景的Agent(如中文文案、中文任务拆解),API调用成本较低,稳定性好。
  • 通义千问(阿里):中文理解能力强,支持多模态(文本、图片),适合需要处理中文多模态信息的Agent,性价比高。
  • 讯飞星火(科大讯飞):语音转文字、文字转语音能力较强,适合需要语音交互的Agent(如智能客服Agent)。
  • Claude(Anthropic):上下文窗口大(最高100k+),适合长文档处理的Agent(如学术调研、长篇报告分析),幻觉较少,安全性高。

适用场景:快速开发Agent项目、生产环境、不需要处理敏感数据的场景(如公开信息检索、文案生成)。

2. 开源本地模型(自己部署)

这类模型开放源代码,可以下载到本地部署,不需要付费(部署成本除外)。优点是可以私有化部署(适合敏感数据场景)、无Token限制、成本低;缺点是性能不如闭源模型、部署难度较高、需要一定的硬件资源(如GPU)。

主流开源模型(Agent开发常用):

  • Llama 2 / 3(Meta):目前最流行的开源模型,性能接近GPT-3.5,支持多语言,有不同参数规模(7B、13B、70B),适合学习、私有化部署,很多Agent开源项目(如AutoGPT)都基于Llama系列。
  • Mistral(Mistral AI):轻量、快速,7B参数的Mistral性能接近Llama 2 13B,适合部署在资源有限的环境(如本地电脑、小型服务器),适合入门学习。
  • Qwen 通义开源(阿里):中文支持更好,开源版本有7B、14B、72B等,性能较强,适合中文场景的私有化Agent部署。
  • ChatGLM(清华智谱):轻量、中文友好,部署门槛低,适合入门学习、小型Agent项目(如本地自动化办公Agent)。

适用场景:学习Agent开发、私有化部署(如企业内部Agent,处理敏感数据)、不需要极致性能的场景。

3. 选型建议

  • 新手入门:优先用GPT-3.5 API(性价比高、开发简单),或者Llama 3 7B(本地部署,适合学习);
  • 中文场景:优先用文心一言、通义千问(中文理解更好);
  • 复杂任务:用GPT-4、Claude(推理能力强、上下文窗口大);
  • 敏感数据:用开源模型(Llama 3、Qwen)本地部署;
  • 成本敏感:用开源模型,或者GPT-3.5、文心一言(API成本较低)。

六、总结:大模型与Agent的关系

最后用一张“比喻”,帮你彻底理清大模型和Agent的关系,记住这几句话,后续学习Agent架构、工具调用会更轻松:

  • 大模型(LLM)= Agent的大脑:负责理解需求、推理决策、生成输出,是Agent的核心;
  • Prompt工程 = Agent的指令系统:告诉大脑“该做什么、怎么做”,引导大脑生成正确的思考过程和输出;
  • RAG(检索增强)= Agent的外部记忆/眼睛:弥补大脑的知识缺口(实时信息、专业知识),让大脑能获取更准确、更全面的信息;
  • Function Calling(工具调用)= Agent的手脚:让大脑能主动行动(联网、查文件、执行代码、计算),解决大脑“不会主动做事”的问题;
  • Agent = 带思考、记忆、行动能力的完整智能体:把大脑、指令系统、眼睛、手脚整合起来,实现“自主感知→决策→执行→迭代”的闭环,能独立完成复杂任务。

简单说:大模型是“能思考”,Agent是“能做事”;大模型是基础,Agent是大模型的“落地形态”。

写在最后

这篇博客覆盖了Agent入门前必须掌握的大模型基础知识点,从概念到应用,从选型到避坑,是开发中能直接用到的干货。

建议了解这篇博客的内容,搞懂上下文窗口、Token、生成参数、思维链这些核心概念,再继续学习Prompt工程、RAG、工具调用,这样会更轻松、更高效。

下一篇,我们将讲解Agent的“灵魂”——Prompt工程,教你如何写好提示词,引导大模型生成正确的思考过程和输出,为后续Agent开发打下基础。

Read more

Tauri 前端配置把任何前端框架“正确地”接进 Tauri(含 Vite/Next/Nuxt/Qwik/SvelteKit/Leptos/Trunk)

1. 配置清单:先把底层规则记住 把下面三条当作 Tauri 前端接入的硬规则: 1. 只走静态路线:SSG / SPA / MPA Tauri 不原生支持基于服务端的方案(例如 SSR)。(Tauri) 2. 移动端真机开发必须有“可被设备访问”的 dev server 需要让 dev server 绑定到你的内网 IP(或按 Tauri CLI 提供的 host),否则 iOS/Android 真机加载不到页面。(Tauri) 3. 保持标准的 Client ↔ API 模式 不要把 SSR 那种“前端渲染与 API 混在一起”的混合模式搬进 Tauri(

阿里云部署OpenClaw:79元/年搭24小时AI代理

阿里云部署OpenClaw:79元/年搭24小时AI代理

不舍得买Mac mini,又担心本地OpenClaw删库,本文教你如何低成本拥有一个7*24h云端在线专属agent。 openclaw因其本地化部署,7*24h在线,手机端指令交互而爆火,github star数量过去两周一路狂奔,现在已经136k star 了。 不仅如此,openclaw原名Clawdbot,受迫于anthropic的压力,clawdbot改名为motlbot,不到三天,又火速改名为openclaw。三次改名又吸尽大众眼球,网友戏称为"vibe naming" 你以为到此为止了么?NO, NO,NO。 这两天moltbook又火爆社交媒体,一个只有ai agent,没有任何人类发言的类reddit论坛。截至目前(2026-02-01),150万agent创建了1万多个话题,5万多发帖,23万条评论。里面有ai向ai的求助,有ai之间的协作讨论,甚至出现了ai自己的哲学和布道师,让屏幕前的人类看得目瞪口呆。这个5天前刚注册的网站,在一个一个的帖子里面,似乎隐藏着ai意识的觉醒? 说到这,这一切的一切,如果要想参与进来,我们首先要有一个openclaw

前端监控:让你的网站问题无处遁形

前端监控:让你的网站问题无处遁形 毒舌时刻 前端监控?这不是后端的事吗? "我的代码没问题,不需要监控"——结果用户反馈网站崩溃,自己却一无所知, "我有日志,还需要什么监控"——结果日志太多,根本找不到问题, "监控太复杂了,我没时间做"——结果问题频发,用户流失。 醒醒吧,前端监控是前端开发的重要组成部分,不是可有可无的! 为什么你需要这个? * 问题发现:及时发现和定位前端问题 * 性能优化:了解网站性能瓶颈 * 用户体验:了解用户真实使用情况 * 数据驱动:基于数据做出决策 反面教材 // 反面教材:没有任何监控 function App() { return ( <div> <h1>我的网站</h1&

Qt与Web混合编程:CEF与QCefView深度解析

Qt与Web混合编程:CEF与QCefView深度解析

Qt与Web混合编程:CEF与QCefView深度解析 * 1. 引言:现代GUI开发的融合趋势 * 2. Qt与Web集成方案对比 * 3. CEF核心架构解析 * 4. QCefView:Qt与CEF的桥梁 * 5. 实战案例:智能家居控制面板 * 6. 性能优化策略 * 7. 调试技巧大全 * 8. 安全加固方案 * 9. 未来展望:WebComponent集成 * 10. 结语 1. 引言:现代GUI开发的融合趋势 在当今的桌面应用开发领域,本地GUI框架与Web技术的融合已成为不可逆转的趋势。Qt作为成熟的跨平台C++框架,与Web技术的结合为开发者提供了前所未有的灵活性: * 本地性能 + Web动态性 = 最佳用户体验 * 快速迭代的Web前端 + 稳定可靠的本地后端 * 跨平台一致性 + 现代UI效果 35%25%20%20%混合应用优势分布开发效率UI表现力跨平台性性能平衡 2. Qt与Web集成方案对比 方案优点缺点适用场景Qt WebEngine官方支持,