上一篇《从“会问问题”到“会干活”什么是 AI Agent》把 Agent 的架构和运行机制梳理过了。写 Agent第一步是让程序能调用大语言模型LLM读文件、联网、上框架是后续的机制系列里会在后面逐个添砖加瓦地介绍并实现。本篇主要介绍LLM API相关并用 Python 跑通第一个最小 Agent——由代码维护 messages、循环调用 chat.completions.create、在终端多轮对话。一、为什么要学今天这些内容Agent 的“思考”几乎都发生在大语言模型LLM里。若只把它当黑盒一旦和AI聊天发现它变慢、报错、突然记不住上文很容易归咎于“模型不行”或“Prompt 没写好”——但部分根因其实是由于按 Token 计费、上下文窗口有上限、多轮对话要把历史再发一遍占满额度和预算导致的。 其次为什么要先写“只会聊天”的最小 Agent若没一步步亲手跑通后面工具报错或框架封装太深很难分清是模型胡说 、消息没传对还是哪个机制没实现好。只有跑一遍代码才能彻底弄清LLM在线上怎么运作后面加读文件、加记忆时才知道该删什么、该留什么而不是功能越堆阵脚越乱。我们先用最少代码跑通“用户输入 → 调 API → 回复”是为了以后每加一层能力都能看清代码、看清日志未来排错才有抓手。 所以本篇路线先弄懂 LLM 和 Chat API → 弄清 messages、Token、上下文窗口、温度与 max\_tokens → 跑通最小 的Agent。二、LLM 基础从 Transformer 到 API 参数不必一次背下所有名词但心里要有一张从里到外的路线图后面五块内容按这个顺序展开 1. 模型内部靠什么生成文字 主流 Chat 模型背后多是Transformer一种神经网络结构先简单记住。它生成回答的方式可以想成加强版输入法联想已经有一段上文比如你写的 system、用户的问题、模型刚写出来的半句话模型每次负责猜 “下一个 Token 最可能是什么”猜出一个就把它拼到末尾再基于变长后的整段上文继续猜下一个——如此反复直到凑成完整回复。所以不是“一下子从脑子里蹦出整篇答案”而是反复“上文 → 下一个词”堆出来的。 2. 为什么LLM既会聊天、又会胡说产生幻觉LLM大致要经过预训练 → 监督微调SFT→ 人类反馈对齐RLHF等阶段把它训成像助手一样接话、跟着指令走。但LLM底层任务是接下一个概率最高的 Token训练里没把必须为“真”设成硬目标所以即便听起来逻辑通顺但事实则可能是模型编造的。 3. LLM用起来要付什么“代价”、有什么硬限制 按 Token 计费还有上下文窗口上限。这直接决定对话能不能加长、账单会不会突然变贵、长 system提示词会不会把额度占满。 4. LLM能调哪些参数 例如 温度temperature、max\_tokens。同样的问题参数不同回答可以一个稳、一个飘。 5. 怎么使用程序去实现和LLM对话简单地说就是用 messages 列表封装对话通过 API 发给云端。这和本文后面的最小 Agent 是同一套东西。 下面从第 1 块介绍到第 5 块和写Agent 无关的数学推导会省略但和排错、控成本、调行为相关的会尽量介绍完整。2.1 Transformer当今 LLM 的骨架ChatGPT、Claude、DeepSeek、通义……生成式大语言模型的核心几乎都是基于Transformer结构。弄清楚Transformer前先了解一个很重要的名词Token。 模型处理文字时LLM不会按“你肉眼看到的一个汉字”为单位而是先把句子切成更小的片段每一块叫一个 Token词元可粗理解为模型内部的“字数碎片”。例如英文一个单词Agent是一个Token中文里“智”和“能”可能各占一个 Token也可能合并取决于具体模型的分词方式。2.3 节会专门讲 Token 与计费、窗口的关系这里先记住Transformer 和对话 API 里出现的“字”其实都是 Token。 Transformer的公式不需要推导记忆但要清楚下面三件事 1它解决什么问题。 更早的 RNN/LSTM 按字逐个读长文本难并行、远距离依赖容易丢。Transformer用自注意力Self-Attention序列里每个Token 都能直接“看见”其它 Token彼此都是上文里的碎片而不是“一个字”的严格对应并行算整段长距离关系例如主语和句末动词更容易抓住。 2自注意力在直觉上干什么。 想象模型正要写出下一个 Token它会把当前已经出现的所有 Token 都扫一遍给每一个Token 打一个“和这一步有多相关”的分数用户问题里的关键词分数高无关的虚词分数低离得很远但语义重要的词例如句首的主语也可能被拉高。再把高分的信息揉在一起用来决定下一个 Token 写什么——这就是自注意力的直觉。它不是只盯着前一个字而是整段上文一起参与判断。它也不是先想好整篇再输出而是每一步都在推导“在给定目前所有 Token 的前提下下一个最可能是什么” 3前面说的 Transformer也可以理解成一套可复用的“积木”核心是上一段讲的自注意力。研究者用同一类积木能搭出不同的“整机”差别在于整机里有没有专门“只负责读懂输入”的一半、有没有专门“只负责往下写”的另一半。这就是 编码器Encoder 和 解码器Decoder 的来源它们是 Transformer 积木的不同搭法 ·编码器偏向“把已有文字读透”——适合分类、检索、打标签典型整机叫 Encoder-only如 BERT不负责聊天式续写。 ·解码器偏向“根据已有文字接着往下生成”——聊天续写走的就是这条路。 ·编码器 解码器左边整机读源句右边整机写目标句——早期翻译常见如 T5。 三种搭法可以看成下面这张图最上面蓝框Transformer 共用积木自注意力 前馈层下面三种整机都由它搭出来。 左列“只读型”像批改作文读完给标签不会接着跟你聊天。中列“先读后写”像翻译左边读完整句右边写结果现在做 Chat Agent 较少用这种当主模型。右列“边读边写”像输入法联想根据已经出现的全部文字一个字一个字往下接GPT、DeepSeek 对话版属于这类。 当在Python 里调用 chat.completions 时会向云端发一个“聊天包裹”模型按内部逻辑接字生成一整段 assistant 回复。不要误以为模型在脑子里想好一整篇再粘贴给你其实更像手机输入法根据已经出现的字一个小碎片一个小碎片往下接每个碎片叫 Token。Agent在其中负责发包裹、收整段回复、把回复记进 messages。拆开看LLM内部处理流程来看简单地可以用下图表示。其中自回归是指刚接上的Token 也会变成下一步的“已有文字”这是 LLM 内部的生成方式。多轮对话时Agent会把上一轮助手回复也放进 messages 再请求否则模型内部接字时“看不到”上文。2.2****模型怎么来的预训练 → SFT → RLHF阶段一预训练Pre-training ·数据海量文本网页、书籍、代码等一般没有“用户 / 助手”对话格式。 ·目标下一个 Token 预测——给定前文猜下一个字。 ·得到什么基座模型Base Model。它懂语言、懂不少世界知识但你不问它“请用三点总结”它未必按助手方式回答更像极强补全机。 ·局限没对齐人类偏好可能续写出有害、偏见、编造内容训练目标只是像训练语料。 阶段二监督微调SFT, Supervised Fine-Tuning ·数据人工写的 指令理想回答 成对样本以及多轮对话示范。 ·目标仍多是预测 Token但数据格式已是“用户这样问 → 助手应这样答”。 ·得到什么Instruct / Chat 模型——会按指令办事、会聊天你让它“分点写”“列三条”它也更愿意用 1、2、3 或条目式排版回答而不是只吐一大段不分段的文字。常见的LLM通常已是 SFT 之后的产品。 ·局限 SFT 阶段已经让模型习惯“先读一段系统设定再回答用户”但 不保证永远遵守也不保证不编造——只是概率上更愿意配合。 阶段三人类反馈强化学习RLHF, Reinforcement Learning from Human Feedback ·动机SFT 数据覆盖不全同样指令可以有“更清晰 / 更安全 / 更诚实”多种答法。 ·典型三步1. 用 SFT 模型生成多个回答人标注哪个更好。2. 训练 奖励模型Reward Model 模仿人类偏好。3. 用强化学习常见 PPO调整策略让生成结果在奖励模型上得分更高。 ·效果更爱拒绝危险请求、语气更“助手化”、更少明显冒犯代价是有时过度保守或不肯直说不知道。 ·补充工业界也有 DPO 等简化对齐、或“SFT 规则过滤”路线不必死记算法名记住 RLHF 是“偏好对齐”阶段即可。2.3 Token**模型看的不是“一个字”**2.1 节已说明Token 是模型把文本切开后的最小片段。API 不认“汉字个数”只认 Token。每个 Token 在模型内部对应词表里的一个编号切分由分词器Tokenizer完成常见算法BPEByte Pair Encoding,它把高频片段逐步合并进词表。另外还需要清楚 1. 英文里常 1 个单词 ≈ 1 个 Token中文往往 1 个字 ≈ 12 个 Token视模型与分词器而定同样一段话中文通常比英文“更费 Token”。 2. 计费输入 Token 输出 Token 分开计价多轮对话每次把整段历史再发一遍输入 Token 会暴涨Agent 成本的大头常在这里。 3. 上下文窗口上限也是按 Token 算不是按字符。 4. 工具名、JSON、代码 有时会被切成很多小 Token同样语义比自然语言更贵。 如果想粗算“发出去之前已经占了多少”——算的是 Chat 用的 Token数不是字数详见下面几行 Python。先安装pip install tiktoken作用在发 API 之前粗算一段文字会占多少 Token仅作估算最终以厂商账单为准import tiktoken1. 选与你要调的模型匹配的分词方式不同模型计数可能略有差别enc tiktoken.encoding_for_model(“gpt-4o-mini”)2. 把你准备发给模型的内容拼起来数——例如 system 多轮历史 本轮 usersystem “你是技术助教用简体中文、分点回答。”user “用三句话解释 Token 和上下文窗口的关系。”text system user # 真实场景里还要加上以往 assistant 的回复n len(enc.encode(text))print(“这段内容大约 Token 数:”, n)print(“若模型窗口是 128000则输入约占:”, round(n / 128000 * 100, 2), “%还未算模型回复长度”)跑完后会得到一个整数例如 42——表示这段文字大约占 42 个 Token。多轮对话时每一轮都要把历史再数一遍、再发一遍所以轮数越多输入 Token 往往越高。若接近窗口上限就要删历史、做摘要或只传片段。 这时会冒出一个问题材料很多时怎么办 比如 Agent 要读几十份 PDF不可能把全文都塞进 messages——窗口和费用都会爆。工程上的常见做法是先按“意思像不像”筛出少量相关段落再只把这几段交给 Chat 模型写回答。“按意思搜”靠的就是另一类接口里的Embedding嵌入向量把一段话变成一串数字意思相近的段落数字也相近。它和上面数的 Token 不是同一条路但做 Agent 迟早会听见这个词这里提前打个照面避免和聊天 Token 混成一团。 Embedding和Token的差异先简单一句话总结Token 管对话怎么生成、怎么计费Embedding 管按意思找材料检索用。Token化是把文本切碎供聊天模型接字生成Embedding 化是把整段语义压成向量供检索、相似度匹配。后续介绍RAG时再拎出来细讲。 另外读资料时你可能会碰到 “向量化” 这个词。在 LLM / RAG 语境里一般是指Embedding把一句话、一段文档变成 向量一串浮点数用来判断“哪两段话意思更接近”。工程里常说“做向量化”“写入向量库”和英文\*embedding\*、\*vectorize\* 是同一类事。2.4 上下文窗口硬天花板上下文窗口Context Window 单次请求里输入 模型准备生成的输出 能占用的 最大 Token 数。例如 8K、32K、128K——厂商会写在模型说明里。 · 整包 messages 都算输入system、每一轮 user / assistant、以后的 tool 结果全占额度。 · 不是“记得住无限对话”超过上限API 会报错或部分产品自动截断最早的消息——早期 system 或关键指令可能被裁掉导致Agent 突然“变傻”或忘掉之前的事。 · 输出也占空间你设的 max\_tokens 越大留给“模型还能生成多长”的预算越多但和输入共享同一次调用的资源规划具体以厂商文档为准。2.5 生成参数温度、top_p、max_tokens之前提到模型内部是“猜下一个 Token”。猜的时候它不是只盯着一个固定答案而是对词表里很多候选各有一个概率有的很高有的很低。真正输出哪一个还要再经过一步采样可以理解为按这些可能性“抽签”决定下一个 Token。除了必填的 model、messages还可以在同一次请求里带上 temperature、top\_p、max\_tokens。 temperature温度的作用模型先给每个候选 Token 一个权重谁更可能出现在下一位temperature 决定抽签有多“野”。 · 设得很低常用 0 或 0.10.3几乎总是抽到权重最高的那个 → 回答 稳、重复度高同样问题多次问字句往往差不多。适合 要格式准、别乱发挥 的场景。 · 设得较高如 0.71.0权重低一些的候选也有机会被抽到 → 回答 更活、更发散但也更容易 跑题或胡说。适合写文案、头脑风暴。 注意temperature0 并不等于“一定正确”只是 几乎不随机。该错仍会错只是每次错法可能很像。 top\_p又叫核采样它主要指的是限制抽签范围的办法只在“加起来够格”的一小撮热门候选Token里抽把特别离谱、概率极低的词先排除掉。例如 top\_p0.9 表示从最可能的词开始往下累加累到概率总和约 90% 就停只在这堆里抽签。 max\_tokens主要作用是限制本轮最多生成多少 Token。它既能防止一次啰嗦烧光预算也避免生成停不下来但如果设太小会使得LLM的话没说完就发生截断。 以上几点这里有个简单的代码示例response client.chat.completions.create(model“gpt-4o-mini”,messagesmessages,temperature0.2,max_tokens1024,)2.6****调用线上模型鉴权与 Chat API在开发Agent时绕不过以下三件事他们是调用LLM API的基础鉴权ZHIPU_API_KEY或兼容名 OPENAI_API_KEY放在系统环境变量不写进 .env、不进 Git。地址ZHIPU_BASE_URL / OPENAI_BASE_URL 指向官方或国内 OpenAI 兼容 网关。请求体chat.completions.create核心是 messages 模型名 上文采样参数。大语言模型LLM此时可以压缩表述为一个通过 HTTP 访问的、Decoder-only Transformer 对话接口按 Token 计费受上下文窗口约束用采样参数调节输出随机性。2.7 messages**API 里的“对话状态”**一次 Chat 调用长这样逻辑上{“model”: “gpt-4o-mini”,“messages”: [{“role”: “system”, “content”: “你是……岗位说明”},{“role”: “user”, “content”: “用户这句话”},{“role”: “assistant”, “content”: “模型上一轮回复”},{“role”: “user”, “content”: “用户下一句话”}]}多轮对话时不是只发最后一句 user的消息而是把历史 user/assistant 的一起发给模型这样LLM能记得上文。2.8****一次调用在程序里怎么走本篇只介绍多轮 user / assistant API 调用无 system 文件、无工具、无 ReAct等。最小 Agent 在终端里每轮对话大致按下面顺序执行三、最小 Agent 长什么样接下里会写一个Agent 工程的最小起点它不包含任何Agent相关的机制只是一个托管多轮对话的聊天壳。3.1****项目结构minimal_chat_v1/├── agent_session.py # 核心配置、messages、调 Chat API├── minimal_agent.py # 入口终端里循环读你的输入├── requirements.txt # 依赖openai、python-dotenv├── .env.example # 可选模型、地址、temperature不含 Key└── README.md本篇 Agent 的代码就 agent\_session.py minimal\_agent.py 两个文件。下面按“先总后分、对照源码”介绍代码在文章最后附录的git链接。3.2****核心代码说明3.2.1 先建立整体思维链程序在干什么本系列示例用 Python 实现下文聚焦上述介绍的概念与代码对应关系 而Python 的学习资料比较多不讲Python语法。 本篇的代码主要是在内存里维护一份对话列表 messagesuser每说一句话就把整份列表发给模型再把模型的回复追加进列表。下图把从启动到一轮对话的闭环画在一起代码主要拆成两个文件文件角色类比agent_session.pyAgentSession 管配置、messages、发请求Agent 的“会话引擎”minimal_agent.pymain()while True 读终端输入、打印结果包在引擎外面的“终端壳”3.2.2 agent_session.py会话引擎程序启动时会 load\_config()读环境变量里的API Key、模型名、接口地址、temperature 等。.env 里可以放非敏感项Key 用 ZHIPU\_API\_KEY表示安全起见不把key写进文件。 AgentSession 初始化时class AgentSession:def __init__(self) - None:self.config load_config()self.client build_client() # 用 Key base_url 建好 OpenAI 兼容客户端self.messages: list[dict] [] # 对话历史本篇从空列表开始几个词需要记一下 ·list有序列表[] 表示空。 ·dict键值对一条消息长这样 {role: user, content: 你好}。 ·self.messages挂在“会话对象”上的变量只要程序不退出它就会一直累积这就是多轮记忆的来源。核心方法 chat()一轮对话的四步这是整篇最重要的函数对照源码里的AgentSession.chat def chat(self, user_text: str) - tuple[str, MechanismSnapshot]:① 把刚说的话记进 messagesself.messages.append({“role”: “user”, “content”: user_text})# ② 组装请求参数模型名 整段 messages含历史 kwargs {model: self.config.model, messages: self.messages} if self.config.temperature is not None: kwargs[temperature] self.config.temperature # ③ 发 HTTP 请求等模型返回 response self.client.chat.completions.create(\*\*kwargs) assistant\_text response.choices[0].message.content or # ④ 把模型回复也记进 messages供下一轮使用self.messages.append({“role”: “assistant”, “content”: assistant_text})return assistant_text, self.snapshot()每次 create 传进去的 messages就是当前列表里的全部条目不是“只发最后一句”。所以本篇后续实验 1 里第二轮问“我叫什么”模型能看见第一轮 user/assistant的对话消息。 需要注意的是失败要 rollback\_last\_user()这是因为chat() 里第 ① 步已经把你的话写进 messages 了。如果第 ③ 步网络报错列表里会留着一条“只有 user、没有 assistant”的脏数据。rollback\_last\_user() 就是把最后那条 user 删掉避免下次请求带着半截对话。3.2.3 minimal_agent.py这个文件很短逻辑是“启动引擎 无限循环读输入”def main() - None:session AgentSession() # 创建会话内部已完成连 API、messages[]while True: # 一直循环直到你输入 exit user\_input input(你: ).strip() if user\_input.lower() in {exit, quit, q}: break # 退出循环程序结束 reply, snap session.chat(user\_input) # 交给引擎处理一轮 print(f\n助手: {reply}\n) # 把文字显示在终端 文件末尾的if __name__ “__main__”:main()这个表示用 python minimal\_agent.py 直接运行时才执行 main()。这是 Python 脚本的常见写法不用深究。minimal\_agent.py 里还会打印 [usage]本轮 Token这是方便学习的观测不改变 Agent 行为。3.2.4 读源码的建议顺序打开 minimal_agent.py找到 main() 和 while True弄清“输入从哪进、回复从哪出”。打开 agent_session.py找到 AgentSession.__init__ 和 chat()对照 3.2.2 的四步。回到 2.7 节 JSON 示例把 messages 先理解成在 chat() 里被 append 两次user、assistant的列表。而整篇 Agent 的“壳”就是维护 messages 调 chat.completions.create。3.4 国内LLM兼容配置API Key 用系统环境变量LLM SDK 从 os.environ 读换地址即换厂商。系列示例默认 智谱 GLM-4.7-FlashAPI 模型名 glm-4.7-flash免费模型PowerShell当前终端$env:ZHIPU_API_KEY“你的智谱APIKey”Linux / macOSexport ZHIPU_API_KEY你的智谱APIKey复制 .env.example 为 .env只放非敏感项例如ZHIPU_BASE_URLhttps://open.bigmodel.cn/api/paas/v4ZHIPU_MODELglm-4.7-flashOPENAI_TEMPERATURE0.2Key 在 智谱开放平台 申请。若改用 OpenAI / DeepSeek改 ZHIPU_BASE_URL / ZHIPU_MODEL或兼容的 OPENAI_* 变量名代码不用动。四、动手跑起来并做实验4.1****安装与运行方式 A桌面机制查看器推荐与下文截图一致左侧聊天右侧实时看 messages 条数、Token、JSON不用改代码打日志。运行以下命令cd agent_lab/mechanism_viewer_v1pip install -r requirements.txt先设置 ZHIPU_API_KEYpython mechanism_client.py此时会弹出窗口 “minimal_chat 机制查看器”左下输入框打字 → 点 “发送”要重来点 “清空会话”。右侧 “机制面板” 看轮次与 Token“messages JSON” 看发给 API 的完整列表。方式 B终端 CLIcd agent_lab/minimal_chat_v1pip install -r requirements.txt先设置 ZHIPU_API_KEYcopy .env.example .env # 可选只放模型/地址/温度python minimal_agent.py终端里会出现提示输入问题回车输入 exit 退出。CLI 默认只在终端打印 [usage]没有机制面板。4.2****实验 1证明 messages 在历史累积连续问“我叫小明。”然后“我叫什么” 第二次应能答出“小明”因为第一轮 assistant 已在 messages 里。 · 桌面查看器会看到右侧 messages 条数 从 0 → 2 → 4或切到 messages JSON 标签确认列表变长。· 终端 CLI则在代码里临时 print(len(messages))看到每轮 2 条user、assistant。下面的实验建议动手完成。4.3****实验 2温度对比固定用下面这一句用三个比喻解释什么是 AI Agent每个比喻一句话。步骤在 minimal_chat_v1/.env 里设 OPENAI_TEMPERATURE0重启桌面查看器或 CLI改 .env 后要重开才生效。清空会话发送上面那句话把回答复制或截图保存。把 .env 改成 OPENAI_TEMPERATURE0.9再重启、再清空会话原封不动再问同一句话。4.对比两次回答0 往往更稳、更套路、多次重试差别小0.9 往往比喻更跳、措辞更活、重问一次可能换一套说法——这就是 temperature 在塑造采样随机性。4.4****实验 3感受 Token 与历史变长多聊十几轮观察 输入 Token 是否逐轮上升——这就是后面要做 Memory 摘要、RAG 只塞片段的经济原因。·桌面查看器机制面板里看 本轮 / 累计 Token若显示“厂商未返回 usage”换模型或看终端 [usage]。·终端 CLI若返回 usage 字段会打印 response.usage也可临时 print(len(messages)) 感受条数在变长。传统产品经理正在成为下个被淘汰的“传统岗位”。过去画原型、写 PRD、跟进度的“传统技能包”在AI时代正迅速贬值。63% 的企业转型做 AI 产品当下的问题不再是“要不要学 AI ”而是“如何构建 AI 产品”。前段时间还跟字节、腾讯的资深 AI 产品经理沟通他们反馈在大量招人只要有 AI 相关的项目经验基本都能拿到面试机会而且领导很舍得给钱涨薪 40-60% 很正常01接下来的产品人得卷AI能力了如今AI大火行业极速发展的背后懂AI 产品人才却严重稀缺。这不是要你转技术岗而是要掌握构建 AI 产品的核心方法如何将你的领域知识转化为 AI 产品的核心竞争力如何用 AI 技术实现你的产品需求如何设计真正懂用户的 AI 交互体验……懂AI就是产品经理的“救命稻草”风口之下与其焦虑被行业淘汰不如先人一步享受AI技术带来的红利我把AI产品经理的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】不限年龄不限岗位没有代码基础也能学现在扫码完课还送《AI产品面试题库》《AI大模型应用案例集》02掌握技术实战快速转型想成为一名卓越的AI大模型产品经理需要从技术、到项目实战的全方位转型指南**1**AI产品应用原理解析产品经理也能听懂对于产品经理来说如果你不懂技术做不了业务和AI大模型技术衔接、定义不了数据需求是没法完整的落地一个产品的本次课程专门面向产品经理人群解析当下最热门的AI产品应用的必备的「大模型」、「多模态」的实际应用和算法原理解析AI产品应用技术积累大模型能力简单易懂不需要会代码小白也能掌握大模型微调掌握主流大模型如DeepSeek、Qwen等的微调技术针对特定场景优化模型性能。学习如何利用领域数据如制造、医药、金融等进行模型定制AI Agent智能体搭建学习如何设计和开发AI Agent实现多任务协同、自主决策和复杂问题解决。构建垂类场景下的智能助手产品如制造业中的设备故障诊断Agent、金融领域的投资分析Agent等2超全行业案例解析课程详细讲解现阶段大模型在各个行业和领域的应用现状包括零售与电商、教育、医疗、泛娱乐、法律等等10大行业详细讲解案例的思路、应用场景以及背后的技术原理、核心技术揭秘各个行业、场景的真实现状和未来产品的发展与机遇可以说讲解完一个案例就能积累一个AI产品实践的经验课程中所涉及到的实战项目都可以直接在自己的工作中使用让自己的产品/项目有可借鉴的成功案例3AI产品经理求职专项辅导课程中会系统的帮助大家拆解字节、腾讯、百度等大厂AI PM岗位JD关键词掌握AI PM高频面试题型与回答框架展示 AI 相关能力的关键技巧Prompt设计、模型评估、A/B测试、成本意识、与算法/工程协作经验To B类AI产品经理突出“行业理解 技术落地 商业闭环”能力的简历结构设计展示项目成果从客户需求洞察到技术方案设计展现端到产品思维如何评估To B AI产品的可行性、客户付费意愿与实施成本To C类AI产品经理拆解头部公司岗位JD将过往尽力转化为AI产品叙事逻辑从行业趋势、产品设计题、案例分析数据分析题、技术理解边界等全流程辅导面试避免无效海投、锁定最适合的AI产品岗位03本次课程全程直播讲解能直接对话大佬和专业助教不懂就问超详细的案例小白也能轻松get完课后还赠送《AI产品经理面试题库》、《AI大模型应用案例集》不断更新中……适合人群想转型AI产品经理、AI项目管理专家、AI产品解决方案等岗位想进行AI产品创业的创业者想成为制作AI产品的程序员想利用AI解决企业问题的管理岗想在AI方向寻找就业方向的毕业生AI方向前景广阔、待遇好目前很多产品人已经通过完整学习拿到大厂高薪offer收入嗷嗷涨我把AI产品经理的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
AI Agent核心：从Transformer到最小Agent实战，带你玩转LLM API！
上一篇《从“会问问题”到“会干活”什么是 AI Agent》把 Agent 的架构和运行机制梳理过了。写 Agent第一步是让程序能调用大语言模型LLM读文件、联网、上框架是后续的机制系列里会在后面逐个添砖加瓦地介绍并实现。本篇主要介绍LLM API相关并用 Python 跑通第一个最小 Agent——由代码维护 messages、循环调用 chat.completions.create、在终端多轮对话。一、为什么要学今天这些内容Agent 的“思考”几乎都发生在大语言模型LLM里。若只把它当黑盒一旦和AI聊天发现它变慢、报错、突然记不住上文很容易归咎于“模型不行”或“Prompt 没写好”——但部分根因其实是由于按 Token 计费、上下文窗口有上限、多轮对话要把历史再发一遍占满额度和预算导致的。 其次为什么要先写“只会聊天”的最小 Agent若没一步步亲手跑通后面工具报错或框架封装太深很难分清是模型胡说 、消息没传对还是哪个机制没实现好。只有跑一遍代码才能彻底弄清LLM在线上怎么运作后面加读文件、加记忆时才知道该删什么、该留什么而不是功能越堆阵脚越乱。我们先用最少代码跑通“用户输入 → 调 API → 回复”是为了以后每加一层能力都能看清代码、看清日志未来排错才有抓手。 所以本篇路线先弄懂 LLM 和 Chat API → 弄清 messages、Token、上下文窗口、温度与 max\_tokens → 跑通最小 的Agent。二、LLM 基础从 Transformer 到 API 参数不必一次背下所有名词但心里要有一张从里到外的路线图后面五块内容按这个顺序展开 1. 模型内部靠什么生成文字 主流 Chat 模型背后多是Transformer一种神经网络结构先简单记住。它生成回答的方式可以想成加强版输入法联想已经有一段上文比如你写的 system、用户的问题、模型刚写出来的半句话模型每次负责猜 “下一个 Token 最可能是什么”猜出一个就把它拼到末尾再基于变长后的整段上文继续猜下一个——如此反复直到凑成完整回复。所以不是“一下子从脑子里蹦出整篇答案”而是反复“上文 → 下一个词”堆出来的。 2. 为什么LLM既会聊天、又会胡说产生幻觉LLM大致要经过预训练 → 监督微调SFT→ 人类反馈对齐RLHF等阶段把它训成像助手一样接话、跟着指令走。但LLM底层任务是接下一个概率最高的 Token训练里没把必须为“真”设成硬目标所以即便听起来逻辑通顺但事实则可能是模型编造的。 3. LLM用起来要付什么“代价”、有什么硬限制 按 Token 计费还有上下文窗口上限。这直接决定对话能不能加长、账单会不会突然变贵、长 system提示词会不会把额度占满。 4. LLM能调哪些参数 例如 温度temperature、max\_tokens。同样的问题参数不同回答可以一个稳、一个飘。 5. 怎么使用程序去实现和LLM对话简单地说就是用 messages 列表封装对话通过 API 发给云端。这和本文后面的最小 Agent 是同一套东西。 下面从第 1 块介绍到第 5 块和写Agent 无关的数学推导会省略但和排错、控成本、调行为相关的会尽量介绍完整。2.1 Transformer当今 LLM 的骨架ChatGPT、Claude、DeepSeek、通义……生成式大语言模型的核心几乎都是基于Transformer结构。弄清楚Transformer前先了解一个很重要的名词Token。 模型处理文字时LLM不会按“你肉眼看到的一个汉字”为单位而是先把句子切成更小的片段每一块叫一个 Token词元可粗理解为模型内部的“字数碎片”。例如英文一个单词Agent是一个Token中文里“智”和“能”可能各占一个 Token也可能合并取决于具体模型的分词方式。2.3 节会专门讲 Token 与计费、窗口的关系这里先记住Transformer 和对话 API 里出现的“字”其实都是 Token。 Transformer的公式不需要推导记忆但要清楚下面三件事 1它解决什么问题。 更早的 RNN/LSTM 按字逐个读长文本难并行、远距离依赖容易丢。Transformer用自注意力Self-Attention序列里每个Token 都能直接“看见”其它 Token彼此都是上文里的碎片而不是“一个字”的严格对应并行算整段长距离关系例如主语和句末动词更容易抓住。 2自注意力在直觉上干什么。 想象模型正要写出下一个 Token它会把当前已经出现的所有 Token 都扫一遍给每一个Token 打一个“和这一步有多相关”的分数用户问题里的关键词分数高无关的虚词分数低离得很远但语义重要的词例如句首的主语也可能被拉高。再把高分的信息揉在一起用来决定下一个 Token 写什么——这就是自注意力的直觉。它不是只盯着前一个字而是整段上文一起参与判断。它也不是先想好整篇再输出而是每一步都在推导“在给定目前所有 Token 的前提下下一个最可能是什么” 3前面说的 Transformer也可以理解成一套可复用的“积木”核心是上一段讲的自注意力。研究者用同一类积木能搭出不同的“整机”差别在于整机里有没有专门“只负责读懂输入”的一半、有没有专门“只负责往下写”的另一半。这就是 编码器Encoder 和 解码器Decoder 的来源它们是 Transformer 积木的不同搭法 ·编码器偏向“把已有文字读透”——适合分类、检索、打标签典型整机叫 Encoder-only如 BERT不负责聊天式续写。 ·解码器偏向“根据已有文字接着往下生成”——聊天续写走的就是这条路。 ·编码器 解码器左边整机读源句右边整机写目标句——早期翻译常见如 T5。 三种搭法可以看成下面这张图最上面蓝框Transformer 共用积木自注意力 前馈层下面三种整机都由它搭出来。 左列“只读型”像批改作文读完给标签不会接着跟你聊天。中列“先读后写”像翻译左边读完整句右边写结果现在做 Chat Agent 较少用这种当主模型。右列“边读边写”像输入法联想根据已经出现的全部文字一个字一个字往下接GPT、DeepSeek 对话版属于这类。 当在Python 里调用 chat.completions 时会向云端发一个“聊天包裹”模型按内部逻辑接字生成一整段 assistant 回复。不要误以为模型在脑子里想好一整篇再粘贴给你其实更像手机输入法根据已经出现的字一个小碎片一个小碎片往下接每个碎片叫 Token。Agent在其中负责发包裹、收整段回复、把回复记进 messages。拆开看LLM内部处理流程来看简单地可以用下图表示。其中自回归是指刚接上的Token 也会变成下一步的“已有文字”这是 LLM 内部的生成方式。多轮对话时Agent会把上一轮助手回复也放进 messages 再请求否则模型内部接字时“看不到”上文。2.2****模型怎么来的预训练 → SFT → RLHF阶段一预训练Pre-training ·数据海量文本网页、书籍、代码等一般没有“用户 / 助手”对话格式。 ·目标下一个 Token 预测——给定前文猜下一个字。 ·得到什么基座模型Base Model。它懂语言、懂不少世界知识但你不问它“请用三点总结”它未必按助手方式回答更像极强补全机。 ·局限没对齐人类偏好可能续写出有害、偏见、编造内容训练目标只是像训练语料。 阶段二监督微调SFT, Supervised Fine-Tuning ·数据人工写的 指令理想回答 成对样本以及多轮对话示范。 ·目标仍多是预测 Token但数据格式已是“用户这样问 → 助手应这样答”。 ·得到什么Instruct / Chat 模型——会按指令办事、会聊天你让它“分点写”“列三条”它也更愿意用 1、2、3 或条目式排版回答而不是只吐一大段不分段的文字。常见的LLM通常已是 SFT 之后的产品。 ·局限 SFT 阶段已经让模型习惯“先读一段系统设定再回答用户”但 不保证永远遵守也不保证不编造——只是概率上更愿意配合。 阶段三人类反馈强化学习RLHF, Reinforcement Learning from Human Feedback ·动机SFT 数据覆盖不全同样指令可以有“更清晰 / 更安全 / 更诚实”多种答法。 ·典型三步1. 用 SFT 模型生成多个回答人标注哪个更好。2. 训练 奖励模型Reward Model 模仿人类偏好。3. 用强化学习常见 PPO调整策略让生成结果在奖励模型上得分更高。 ·效果更爱拒绝危险请求、语气更“助手化”、更少明显冒犯代价是有时过度保守或不肯直说不知道。 ·补充工业界也有 DPO 等简化对齐、或“SFT 规则过滤”路线不必死记算法名记住 RLHF 是“偏好对齐”阶段即可。2.3 Token**模型看的不是“一个字”**2.1 节已说明Token 是模型把文本切开后的最小片段。API 不认“汉字个数”只认 Token。每个 Token 在模型内部对应词表里的一个编号切分由分词器Tokenizer完成常见算法BPEByte Pair Encoding,它把高频片段逐步合并进词表。另外还需要清楚 1. 英文里常 1 个单词 ≈ 1 个 Token中文往往 1 个字 ≈ 12 个 Token视模型与分词器而定同样一段话中文通常比英文“更费 Token”。 2. 计费输入 Token 输出 Token 分开计价多轮对话每次把整段历史再发一遍输入 Token 会暴涨Agent 成本的大头常在这里。 3. 上下文窗口上限也是按 Token 算不是按字符。 4. 工具名、JSON、代码 有时会被切成很多小 Token同样语义比自然语言更贵。 如果想粗算“发出去之前已经占了多少”——算的是 Chat 用的 Token数不是字数详见下面几行 Python。先安装pip install tiktoken作用在发 API 之前粗算一段文字会占多少 Token仅作估算最终以厂商账单为准import tiktoken1. 选与你要调的模型匹配的分词方式不同模型计数可能略有差别enc tiktoken.encoding_for_model(“gpt-4o-mini”)2. 把你准备发给模型的内容拼起来数——例如 system 多轮历史 本轮 usersystem “你是技术助教用简体中文、分点回答。”user “用三句话解释 Token 和上下文窗口的关系。”text system user # 真实场景里还要加上以往 assistant 的回复n len(enc.encode(text))print(“这段内容大约 Token 数:”, n)print(“若模型窗口是 128000则输入约占:”, round(n / 128000 * 100, 2), “%还未算模型回复长度”)跑完后会得到一个整数例如 42——表示这段文字大约占 42 个 Token。多轮对话时每一轮都要把历史再数一遍、再发一遍所以轮数越多输入 Token 往往越高。若接近窗口上限就要删历史、做摘要或只传片段。 这时会冒出一个问题材料很多时怎么办 比如 Agent 要读几十份 PDF不可能把全文都塞进 messages——窗口和费用都会爆。工程上的常见做法是先按“意思像不像”筛出少量相关段落再只把这几段交给 Chat 模型写回答。“按意思搜”靠的就是另一类接口里的Embedding嵌入向量把一段话变成一串数字意思相近的段落数字也相近。它和上面数的 Token 不是同一条路但做 Agent 迟早会听见这个词这里提前打个照面避免和聊天 Token 混成一团。 Embedding和Token的差异先简单一句话总结Token 管对话怎么生成、怎么计费Embedding 管按意思找材料检索用。Token化是把文本切碎供聊天模型接字生成Embedding 化是把整段语义压成向量供检索、相似度匹配。后续介绍RAG时再拎出来细讲。 另外读资料时你可能会碰到 “向量化” 这个词。在 LLM / RAG 语境里一般是指Embedding把一句话、一段文档变成 向量一串浮点数用来判断“哪两段话意思更接近”。工程里常说“做向量化”“写入向量库”和英文\*embedding\*、\*vectorize\* 是同一类事。2.4 上下文窗口硬天花板上下文窗口Context Window 单次请求里输入 模型准备生成的输出 能占用的 最大 Token 数。例如 8K、32K、128K——厂商会写在模型说明里。 · 整包 messages 都算输入system、每一轮 user / assistant、以后的 tool 结果全占额度。 · 不是“记得住无限对话”超过上限API 会报错或部分产品自动截断最早的消息——早期 system 或关键指令可能被裁掉导致Agent 突然“变傻”或忘掉之前的事。 · 输出也占空间你设的 max\_tokens 越大留给“模型还能生成多长”的预算越多但和输入共享同一次调用的资源规划具体以厂商文档为准。2.5 生成参数温度、top_p、max_tokens之前提到模型内部是“猜下一个 Token”。猜的时候它不是只盯着一个固定答案而是对词表里很多候选各有一个概率有的很高有的很低。真正输出哪一个还要再经过一步采样可以理解为按这些可能性“抽签”决定下一个 Token。除了必填的 model、messages还可以在同一次请求里带上 temperature、top\_p、max\_tokens。 temperature温度的作用模型先给每个候选 Token 一个权重谁更可能出现在下一位temperature 决定抽签有多“野”。 · 设得很低常用 0 或 0.10.3几乎总是抽到权重最高的那个 → 回答 稳、重复度高同样问题多次问字句往往差不多。适合 要格式准、别乱发挥 的场景。 · 设得较高如 0.71.0权重低一些的候选也有机会被抽到 → 回答 更活、更发散但也更容易 跑题或胡说。适合写文案、头脑风暴。 注意temperature0 并不等于“一定正确”只是 几乎不随机。该错仍会错只是每次错法可能很像。 top\_p又叫核采样它主要指的是限制抽签范围的办法只在“加起来够格”的一小撮热门候选Token里抽把特别离谱、概率极低的词先排除掉。例如 top\_p0.9 表示从最可能的词开始往下累加累到概率总和约 90% 就停只在这堆里抽签。 max\_tokens主要作用是限制本轮最多生成多少 Token。它既能防止一次啰嗦烧光预算也避免生成停不下来但如果设太小会使得LLM的话没说完就发生截断。 以上几点这里有个简单的代码示例response client.chat.completions.create(model“gpt-4o-mini”,messagesmessages,temperature0.2,max_tokens1024,)2.6****调用线上模型鉴权与 Chat API在开发Agent时绕不过以下三件事他们是调用LLM API的基础鉴权ZHIPU_API_KEY或兼容名 OPENAI_API_KEY放在系统环境变量不写进 .env、不进 Git。地址ZHIPU_BASE_URL / OPENAI_BASE_URL 指向官方或国内 OpenAI 兼容 网关。请求体chat.completions.create核心是 messages 模型名 上文采样参数。大语言模型LLM此时可以压缩表述为一个通过 HTTP 访问的、Decoder-only Transformer 对话接口按 Token 计费受上下文窗口约束用采样参数调节输出随机性。2.7 messages**API 里的“对话状态”**一次 Chat 调用长这样逻辑上{“model”: “gpt-4o-mini”,“messages”: [{“role”: “system”, “content”: “你是……岗位说明”},{“role”: “user”, “content”: “用户这句话”},{“role”: “assistant”, “content”: “模型上一轮回复”},{“role”: “user”, “content”: “用户下一句话”}]}多轮对话时不是只发最后一句 user的消息而是把历史 user/assistant 的一起发给模型这样LLM能记得上文。2.8****一次调用在程序里怎么走本篇只介绍多轮 user / assistant API 调用无 system 文件、无工具、无 ReAct等。最小 Agent 在终端里每轮对话大致按下面顺序执行三、最小 Agent 长什么样接下里会写一个Agent 工程的最小起点它不包含任何Agent相关的机制只是一个托管多轮对话的聊天壳。3.1****项目结构minimal_chat_v1/├── agent_session.py # 核心配置、messages、调 Chat API├── minimal_agent.py # 入口终端里循环读你的输入├── requirements.txt # 依赖openai、python-dotenv├── .env.example # 可选模型、地址、temperature不含 Key└── README.md本篇 Agent 的代码就 agent\_session.py minimal\_agent.py 两个文件。下面按“先总后分、对照源码”介绍代码在文章最后附录的git链接。3.2****核心代码说明3.2.1 先建立整体思维链程序在干什么本系列示例用 Python 实现下文聚焦上述介绍的概念与代码对应关系 而Python 的学习资料比较多不讲Python语法。 本篇的代码主要是在内存里维护一份对话列表 messagesuser每说一句话就把整份列表发给模型再把模型的回复追加进列表。下图把从启动到一轮对话的闭环画在一起代码主要拆成两个文件文件角色类比agent_session.pyAgentSession 管配置、messages、发请求Agent 的“会话引擎”minimal_agent.pymain()while True 读终端输入、打印结果包在引擎外面的“终端壳”3.2.2 agent_session.py会话引擎程序启动时会 load\_config()读环境变量里的API Key、模型名、接口地址、temperature 等。.env 里可以放非敏感项Key 用 ZHIPU\_API\_KEY表示安全起见不把key写进文件。 AgentSession 初始化时class AgentSession:def __init__(self) - None:self.config load_config()self.client build_client() # 用 Key base_url 建好 OpenAI 兼容客户端self.messages: list[dict] [] # 对话历史本篇从空列表开始几个词需要记一下 ·list有序列表[] 表示空。 ·dict键值对一条消息长这样 {role: user, content: 你好}。 ·self.messages挂在“会话对象”上的变量只要程序不退出它就会一直累积这就是多轮记忆的来源。核心方法 chat()一轮对话的四步这是整篇最重要的函数对照源码里的AgentSession.chat def chat(self, user_text: str) - tuple[str, MechanismSnapshot]:① 把刚说的话记进 messagesself.messages.append({“role”: “user”, “content”: user_text})# ② 组装请求参数模型名 整段 messages含历史 kwargs {model: self.config.model, messages: self.messages} if self.config.temperature is not None: kwargs[temperature] self.config.temperature # ③ 发 HTTP 请求等模型返回 response self.client.chat.completions.create(\*\*kwargs) assistant\_text response.choices[0].message.content or # ④ 把模型回复也记进 messages供下一轮使用self.messages.append({“role”: “assistant”, “content”: assistant_text})return assistant_text, self.snapshot()每次 create 传进去的 messages就是当前列表里的全部条目不是“只发最后一句”。所以本篇后续实验 1 里第二轮问“我叫什么”模型能看见第一轮 user/assistant的对话消息。 需要注意的是失败要 rollback\_last\_user()这是因为chat() 里第 ① 步已经把你的话写进 messages 了。如果第 ③ 步网络报错列表里会留着一条“只有 user、没有 assistant”的脏数据。rollback\_last\_user() 就是把最后那条 user 删掉避免下次请求带着半截对话。3.2.3 minimal_agent.py这个文件很短逻辑是“启动引擎 无限循环读输入”def main() - None:session AgentSession() # 创建会话内部已完成连 API、messages[]while True: # 一直循环直到你输入 exit user\_input input(你: ).strip() if user\_input.lower() in {exit, quit, q}: break # 退出循环程序结束 reply, snap session.chat(user\_input) # 交给引擎处理一轮 print(f\n助手: {reply}\n) # 把文字显示在终端 文件末尾的if __name__ “__main__”:main()这个表示用 python minimal\_agent.py 直接运行时才执行 main()。这是 Python 脚本的常见写法不用深究。minimal\_agent.py 里还会打印 [usage]本轮 Token这是方便学习的观测不改变 Agent 行为。3.2.4 读源码的建议顺序打开 minimal_agent.py找到 main() 和 while True弄清“输入从哪进、回复从哪出”。打开 agent_session.py找到 AgentSession.__init__ 和 chat()对照 3.2.2 的四步。回到 2.7 节 JSON 示例把 messages 先理解成在 chat() 里被 append 两次user、assistant的列表。而整篇 Agent 的“壳”就是维护 messages 调 chat.completions.create。3.4 国内LLM兼容配置API Key 用系统环境变量LLM SDK 从 os.environ 读换地址即换厂商。系列示例默认 智谱 GLM-4.7-FlashAPI 模型名 glm-4.7-flash免费模型PowerShell当前终端$env:ZHIPU_API_KEY“你的智谱APIKey”Linux / macOSexport ZHIPU_API_KEY你的智谱APIKey复制 .env.example 为 .env只放非敏感项例如ZHIPU_BASE_URLhttps://open.bigmodel.cn/api/paas/v4ZHIPU_MODELglm-4.7-flashOPENAI_TEMPERATURE0.2Key 在 智谱开放平台 申请。若改用 OpenAI / DeepSeek改 ZHIPU_BASE_URL / ZHIPU_MODEL或兼容的 OPENAI_* 变量名代码不用动。四、动手跑起来并做实验4.1****安装与运行方式 A桌面机制查看器推荐与下文截图一致左侧聊天右侧实时看 messages 条数、Token、JSON不用改代码打日志。运行以下命令cd agent_lab/mechanism_viewer_v1pip install -r requirements.txt先设置 ZHIPU_API_KEYpython mechanism_client.py此时会弹出窗口 “minimal_chat 机制查看器”左下输入框打字 → 点 “发送”要重来点 “清空会话”。右侧 “机制面板” 看轮次与 Token“messages JSON” 看发给 API 的完整列表。方式 B终端 CLIcd agent_lab/minimal_chat_v1pip install -r requirements.txt先设置 ZHIPU_API_KEYcopy .env.example .env # 可选只放模型/地址/温度python minimal_agent.py终端里会出现提示输入问题回车输入 exit 退出。CLI 默认只在终端打印 [usage]没有机制面板。4.2****实验 1证明 messages 在历史累积连续问“我叫小明。”然后“我叫什么” 第二次应能答出“小明”因为第一轮 assistant 已在 messages 里。 · 桌面查看器会看到右侧 messages 条数 从 0 → 2 → 4或切到 messages JSON 标签确认列表变长。· 终端 CLI则在代码里临时 print(len(messages))看到每轮 2 条user、assistant。下面的实验建议动手完成。4.3****实验 2温度对比固定用下面这一句用三个比喻解释什么是 AI Agent每个比喻一句话。步骤在 minimal_chat_v1/.env 里设 OPENAI_TEMPERATURE0重启桌面查看器或 CLI改 .env 后要重开才生效。清空会话发送上面那句话把回答复制或截图保存。把 .env 改成 OPENAI_TEMPERATURE0.9再重启、再清空会话原封不动再问同一句话。4.对比两次回答0 往往更稳、更套路、多次重试差别小0.9 往往比喻更跳、措辞更活、重问一次可能换一套说法——这就是 temperature 在塑造采样随机性。4.4****实验 3感受 Token 与历史变长多聊十几轮观察 输入 Token 是否逐轮上升——这就是后面要做 Memory 摘要、RAG 只塞片段的经济原因。·桌面查看器机制面板里看 本轮 / 累计 Token若显示“厂商未返回 usage”换模型或看终端 [usage]。·终端 CLI若返回 usage 字段会打印 response.usage也可临时 print(len(messages)) 感受条数在变长。传统产品经理正在成为下个被淘汰的“传统岗位”。过去画原型、写 PRD、跟进度的“传统技能包”在AI时代正迅速贬值。63% 的企业转型做 AI 产品当下的问题不再是“要不要学 AI ”而是“如何构建 AI 产品”。前段时间还跟字节、腾讯的资深 AI 产品经理沟通他们反馈在大量招人只要有 AI 相关的项目经验基本都能拿到面试机会而且领导很舍得给钱涨薪 40-60% 很正常01接下来的产品人得卷AI能力了如今AI大火行业极速发展的背后懂AI 产品人才却严重稀缺。这不是要你转技术岗而是要掌握构建 AI 产品的核心方法如何将你的领域知识转化为 AI 产品的核心竞争力如何用 AI 技术实现你的产品需求如何设计真正懂用户的 AI 交互体验……懂AI就是产品经理的“救命稻草”风口之下与其焦虑被行业淘汰不如先人一步享受AI技术带来的红利我把AI产品经理的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】不限年龄不限岗位没有代码基础也能学现在扫码完课还送《AI产品面试题库》《AI大模型应用案例集》02掌握技术实战快速转型想成为一名卓越的AI大模型产品经理需要从技术、到项目实战的全方位转型指南**1**AI产品应用原理解析产品经理也能听懂对于产品经理来说如果你不懂技术做不了业务和AI大模型技术衔接、定义不了数据需求是没法完整的落地一个产品的本次课程专门面向产品经理人群解析当下最热门的AI产品应用的必备的「大模型」、「多模态」的实际应用和算法原理解析AI产品应用技术积累大模型能力简单易懂不需要会代码小白也能掌握大模型微调掌握主流大模型如DeepSeek、Qwen等的微调技术针对特定场景优化模型性能。学习如何利用领域数据如制造、医药、金融等进行模型定制AI Agent智能体搭建学习如何设计和开发AI Agent实现多任务协同、自主决策和复杂问题解决。构建垂类场景下的智能助手产品如制造业中的设备故障诊断Agent、金融领域的投资分析Agent等2超全行业案例解析课程详细讲解现阶段大模型在各个行业和领域的应用现状包括零售与电商、教育、医疗、泛娱乐、法律等等10大行业详细讲解案例的思路、应用场景以及背后的技术原理、核心技术揭秘各个行业、场景的真实现状和未来产品的发展与机遇可以说讲解完一个案例就能积累一个AI产品实践的经验课程中所涉及到的实战项目都可以直接在自己的工作中使用让自己的产品/项目有可借鉴的成功案例3AI产品经理求职专项辅导课程中会系统的帮助大家拆解字节、腾讯、百度等大厂AI PM岗位JD关键词掌握AI PM高频面试题型与回答框架展示 AI 相关能力的关键技巧Prompt设计、模型评估、A/B测试、成本意识、与算法/工程协作经验To B类AI产品经理突出“行业理解 技术落地 商业闭环”能力的简历结构设计展示项目成果从客户需求洞察到技术方案设计展现端到产品思维如何评估To B AI产品的可行性、客户付费意愿与实施成本To C类AI产品经理拆解头部公司岗位JD将过往尽力转化为AI产品叙事逻辑从行业趋势、产品设计题、案例分析数据分析题、技术理解边界等全流程辅导面试避免无效海投、锁定最适合的AI产品岗位03本次课程全程直播讲解能直接对话大佬和专业助教不懂就问超详细的案例小白也能轻松get完课后还赠送《AI产品经理面试题库》、《AI大模型应用案例集》不断更新中……适合人群想转型AI产品经理、AI项目管理专家、AI产品解决方案等岗位想进行AI产品创业的创业者想成为制作AI产品的程序员想利用AI解决企业问题的管理岗想在AI方向寻找就业方向的毕业生AI方向前景广阔、待遇好目前很多产品人已经通过完整学习拿到大厂高薪offer收入嗷嗷涨我把AI产品经理的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
