目录1 工作模式概述2 关于“中枢”2.1 基础原理2.2 关于“多模态模型”2.3 生成图、视频、音频的模型3 关于“记忆”3.1 上下文是怎么传递给模型的3.2 超长上下文是怎么处理的3.3 长上下文为什么变慢、变贵4 关于“工具”4.1 基础知识4.2 工具说明书很长很大怎么办5 关于“行为模式 / 规划”5.1 ReActReasoning Acting5.2 Plan-and-Solve5.3 Reflexion反思型 Agent5.4 Multi-Agent多 Agent 协作5.4.1 基础知识5.4.2 合作模式5.4.3 通信机制5.4.5 注意点1 工作模式概述我们可以从基础模型开始逐渐给它加能力来了解从简单到复杂的 AI 应用的底层逻辑。中枢 / 大脑底层大模型记忆记录上下文对话内容把历史记录也作为输入工具让大模型先判断是否需要调用工具比如需要调用则调用工具然后把用户问题工具结果一起传给模型工具包括 向量数据库、网络搜索、本地编程、其他本地工具行为模式 / 规划例如先做计划再一步步完成任务再比如通过“思考 → 行动 → 观察 → 再思考”的循环来完成任务。如果上述都具备我们可以将其称为 AI Agent也就是一个智能体。2 关于“中枢”2.1 基础原理模型架构Transformer核心结构self attention2.2 关于“多模态模型”多模态模型的架构图像/音频/视频 → [模态专属 Encoder] ★★★ → [Projector/Adapter 对齐层] ★★★ → [统一 LLM]文本 → [文本 Embedding] → 已经在 LLM 空间内各模态怎么变成「Token」每个模态的输入先通过各自的 Encoder 变成相应的 “token 序列”或者叫 高维向量序列 更严谨。此时图像、音频、文本 token 的向量空间不兼容。所以需要一层 Projector / Adapter / Connector叫法不同作用一样通常是一个轻量的 MLP多层感知机也可以叫全连接层或少量 Transformer 层把视觉/音频特征向量映射到 LLM 的 embedding 空间。2.3 生成图、视频、音频的模型文生图T2I演进路线U-Net → DiTDiffusion TransformerDiTDiffusion Transformer。通过 VAE如 SD 的 8× 压缩 VAE把图像压到隐空间,再切成 patch当成序列用 Transformer 处理。文本条件注入方式Cross-Attention早期图像 token 作为 Query文本 token 作为 Key/Value早期 DiT 如 PixArtJoint Self-AttentionMM-DiT现在主流把图像 token 和文本 token 拼接在一起统一过 Self-Attention双向信息流动SD3、Flux 等主流方案文生视频 / 图生视频T2V / I2V演进3D U-Net → DiT 3D VAE视频被当作「时空立方体」处理文生音乐T2M架构最多样化没有一家独大的情况架构路线代表模型原理自回归 TransformerMusicGen、Suno、Jukebox音频先通过VQ-VAE / EnCodec编码成离散 token类似文本 token然后用 Transformer像写文本一样逐个预测音频 token。文本条件通过 Cross-Attention 或前缀嵌入注入。Diffusion / DiTStable Audio Open、MusicLDM在音频的连续隐空间如 Mel 谱或 VAE 隐空间上做扩散去噪骨干可以是 U-Net 或 DiT。Flow MatchingMusicFlow类似扩散但用流匹配目标函数训练更稳定。State-Space Models (SSM)Prefix SiMBA用 Mamba/S4 等状态空间模型替代 Transformer声称在长序列上训练效率更高。混合架构Seed-MusicTransformer 做理解 Diffusion 做生成或分阶段生成先粗后细。音频 tokenization 是关键音频采样率极高44.1kHz不能直接逐采样点生成。通常先用 VQ-VAE如 EnCodec、SoundStream把波形压缩成几百到几千 Hz 的离散 token再在 token 空间生成。自回归 vs 扩散的选择自回归生成速度快一次前向一个 token适合实时应用但长音频一致性依赖模型记忆。扩散生成质量高、可控性强但需要多步迭代速度慢。文生音乐目前自回归 Transformer 和 Diffusion 并存Suno 等商业产品多用自回归路线而研究界在探索 DiT 和 SSM 替代方案。3 关于“记忆”3.1 上下文是怎么传递给模型的首先我要讲一下 AI 应用调用大模型的方法。大模型能力一般都会封装成 API它可能部署在公司本地的服务器也可能是使用第三方提供的接口。应用的后端通过调用API来和模型对话。上下文一般会以列表的形式记录列表中是一个一个的“对象”每个对象至少包含“角色标签”以及他说的“内容”。然后整个列表传递给 大模型API。大模型API 可以简单分成“应用层”和“模型层”模型层接收的就是一个“字符串”当然“模型层”内部还会把字符串转为 token 串最终交给模型本身。那么对于调用 API 接口的人而言对话列表需要转换成字符串中间会出些一些专门用于切分和标注的特殊token。大致就像下面这样API 接收的对话列表{messages:[{role:system,content:你是一个 helpful 的助手},{role:user,content:你好},{role:assistant,content:你好有什么可以帮你的},{role:user,content:今天天气怎么样}]}API 应用层转为字符串将要传给“模型层”s[INST] SYS 你是一个 helpful 的助手 /SYS 你好 [/INST] 你好有什么可以帮你的 /ss[INST] 今天天气怎么样 [/INST]3.2 超长上下文是怎么处理的模型能力很多模型接受超长的输入也就是输入token数的上限高比如市面上可以找到上限在 128k、200k、1M 的模型。补充有些模型通过架构层面的优化来做到炒成上下文处理常见技术包括稀疏注意力、分层注意力、Ring Attention、Longformer模型外的策略滑动窗口摘要压缩前面的对话总结成一段摘要替代原始消息RAG把历史存入向量数据库每次只检索「相关的」片段3.3 长上下文为什么变慢、变贵Transformer 的注意力机制复杂度是 O(n²)4 关于“工具”工具调用的业界专业名词是Function Calling4.1 基础知识要点结构化输出训练时约定了比如有工具列表而用户问题需要调用工具那么模型返回的输出就是一个结构化的用于工具调用的结果比如某种格式的 json需要工具列表在调用 模型API 的时候对话记录、可用工具表存放在不同的字段一同传递给模型循环调用一个涉及工具调用的系统一般是循环调用的比如一致循环到模型不再输出“工具调用”的请求而是直接输出文本为止。框架很多框架LangChain、AutoGen、OpenAI 的 Assistants API把循环框架定义好了你只需要定义工具函数然后运行开始对话框架自动完成「生成 → 执行 → 再生成」的循环一个案例看懂工具调用流程用户问北京今天天气怎么样 ↓ [步骤1] 模型收到问题 系统提示告诉它有哪些工具可用 ↓ [步骤2] 模型生成一段工具调用请求JSON格式 { name: get_weather, arguments: { city: 北京, date: 今天 } } 注意模型此时还没有回答用户它只输出了这个 JSON ↓ [步骤3] 外部系统API后端/你的代码解析这个 JSON 发现要调用 get_weather 函数于是真的去查天气 API ↓ [步骤4] 工具返回结果 {temperature: 32°C, condition: 晴, humidity: 45%} ↓ [步骤5] 外部系统把工具结果包装成一条新消息塞回对话列表 ↓ [步骤6] 模型再次收到「原始问题 工具调用记录 工具返回结果」 这次它生成最终回复北京今天天气晴朗气温 32°C湿度 45%。4.2 工具说明书很长很大怎么办方法1精简工具描述Prompt 工程优化手段做法效果删除冗余只保留「工具名 一句话功能 必填参数」删除示例、默认值说明、长篇背景减少 50%~70% token参数分级把参数分为「常用参数」和「高级参数」默认只展示常用参数降低认知负担结构化极简不用自然语言段落用表格或 JSON Schema 的精简版模型对结构化信息更敏感方法2工具分组, 参数合并分组描述减少共用参数的冗余描述方法3动态筛选原理方法小的意图模型规则引擎关键词匹配一个 Embedding 检索系统RAG方法4工具说明书原理Prompt 里只放工具摘要工具的详细参数说明放在外部需要调用函数时把完整工具说明放入上下文5 关于“行为模式 / 规划”在 Function Calling 的部分我们已经注意到需要“循环调用”来让流程自动完成某些任务。所以自然我们就会问出1循环的终止条件是什么2更复杂和完备的行为模式有哪些3我如何自己设计行为模式总览模式核心逻辑适合什么任务ReAct边想边干动态调整信息检索、问答、探索性任务Plan-and-Solve先定计划再执行报告生成、复杂工作流Reflexion干完复盘自我纠错代码生成、数学计算、需要验证的任务Multi-Agent分工协作各司其职大型项目、需要多角色配合的任务5.1 ReActReasoning Acting核心逻辑思考 → 行动 → 观察 → 再思考 → 再行动……过程举例用户问2024年诺贝尔物理学奖得主是谁他现在的年龄是多少 Step 1 [思考]用户想知道2024年诺贝尔物理学奖得主及其年龄。 我需要先搜索2024年诺贝尔物理学奖得主是谁。 Step 2 [行动]调用 search_tool(query2024年诺贝尔物理学奖得主) Step 3 [观察]工具返回结果约翰·霍普菲尔德John Hopfield和杰弗里·辛顿Geoffrey Hinton Step 4 [思考]得主有两位。用户问他单数可能需要分别查两人的年龄。 先查约翰·霍普菲尔德的年龄。 Step 5 [行动]调用 search_tool(queryJohn Hopfield age 2024) Step 6 [观察]工具返回约翰·霍普菲尔德出生于1933年7月15日2024年91岁。 Step 7 [思考]再查杰弗里·辛顿的年龄。 Step 8 [行动]调用 search_tool(queryGeoffrey Hinton age 2024) Step 9 [观察]工具返回杰弗里·辛顿出生于1947年12月6日2024年76岁。 Step 10 [思考]我已经收集到全部信息可以回答用户了。 Step 11 [回答]2024年诺贝尔物理学奖授予了约翰·霍普菲尔德和杰弗里·辛顿。 其中霍普菲尔德91岁辛顿76岁。提示词核心公式角色设定 工具说明书 严格的 Thought/Action/Observation 格式规范 2 个多轮 Few-shot 示例 Final Answer 终止信号。举例你是一个智能助手可以通过调用工具来解决用户的问题。 ## 可用工具 1. **search**(query: string): 搜索引擎用于查找实时信息、新闻、百科知识等。 2. **calculator**(expression: string): 计算器用于执行数学运算。 ## 输出格式规则 你必须严格按照以下格式输出每轮只输出 Thought 和 ActionObservation 由系统自动填入 Thought: 你对当前情况的思考。分析用户的问题判断是否需要调用工具如果需要决定调用哪个工具以及参数是什么。 Action: 工具名称和参数参数必须是合法的 JSON 格式。 系统会执行 Action 并返回 Observation然后你会继续 你可以进行多轮 Thought/Action/Observation。当你认为已经获得足够信息可以直接回答用户时输出 Thought: 我已经获得足够信息可以给出最终答案。 Final Answer: 对用户的最终回答。 ## 示例 1 Question: 2024年巴黎奥运会中国获得了多少枚金牌 Thought: 用户询问的是2024年巴黎奥运会中国代表团的金牌数量这是一个实时信息我需要调用搜索工具查询。 Action: search({query: 2024年巴黎奥运会中国金牌数量}) Observation: 2024年巴黎奥运会上中国体育代表团共获得40枚金牌、27枚银牌、24枚铜牌。 Thought: 我已经获得了确切信息中国获得了40枚金牌可以回答用户了。 Final Answer: 2024年巴黎奥运会上中国体育代表团共获得40枚金牌。 ## 示例 2 Question: 北京今天的气温乘以2再加上10等于多少 Thought: 这个问题需要两个步骤先查询北京今天的气温然后进行数学计算。我先搜索天气信息。 Action: search({query: 北京今天气温}) Observation: 北京今天晴气温22°C到33°C当前气温28°C。 Thought: 当前气温是28度。用户问的是28乘以2再加上10我需要用计算器。 Action: calculator({expression: 28 * 2 10}) Observation: 66 Thought: 计算结果是66我可以给出最终答案了。 Final Answer: 北京今天当前气温是28°C乘以2再加上10等于66。 ## 现在开始 Question: {用户输入} Thought:5.2 Plan-and-Solve过程举例先规划后执行用户问帮我调研一下新能源汽车行业写一份简要报告。 Step 1 [制定计划] 1. 搜索2024年全球新能源汽车销量数据 2. 搜索主要厂商比亚迪、特斯拉的市场份额 3. 搜索行业技术趋势固态电池、自动驾驶 4. 整合以上信息生成结构化报告 Step 2-4 [按步骤执行]逐个调用搜索工具收集信息。 Step 5 [汇总输出]基于所有收集到的信息生成最终报告。对比维度ReActPlan-and-Solve计划方式走一步看一步动态调整先定好完整路线图灵活性高能根据中间结果随时改计划低计划定了后很少改适用场景目标不明确、需要探索的任务目标明确、步骤清晰的任务风险可能陷入循环或偏离目标计划可能一开始就是错的实际应用很多 Agent 框架会把两者结合——先用 Plan-and-Solve 定大方向再用 ReAct 处理每个子步骤的细节。5.3 Reflexion反思型 Agent核心逻辑执行 →评估结果→反思错误→ 重新尝试关键点引入了一个「评估/反思」环节让 Agent 能自我纠错。通常需要一个「Evaluator」可以是另一个 LLM 调用也可以是单元测试、编译器等外部验证工具。反思的结果可以写入长期记忆下次遇到类似任务时避免犯同样的错。举例用户任务写一个 Python 函数计算斐波那契数列。 Step 1 [行动]LLM 生成代码并执行。 Step 2 [观察]运行报错——RecursionError: maximum recursion depth exceeded. Step 3 [反思]代码用了递归但没有基准条件导致无限递归。 我应该改用迭代方式或者加上 n1 的终止条件。 Step 4 [重新行动]生成修正后的代码。 Step 5 [验证]运行成功输出正确。单Agent 流程小结┌─────────────────────────────────────────┐ │ 用户输入任务 │ └─────────────────┬───────────────────────┘ ▼ ┌──────────────────────────────────────────┐ │ 大脑LLM: 理解任务 → 制定计划/思考 │ │ ReAct: Thought / Plan-and-Solve: Plan│ └─────────────────┬────────────────────────┘ ▼ ┌────────────────┐ │ 需要调工具吗 │ └───────┬────────┘ │ ┌─────────┴─────────┐ ▼ ▼ [是] [否] ▼ ▼ ┌────────────┐ ┌──────────────┐ │ 输出 Action │ │ 直接输出答案✅│ │ (工具调用) │ │ (Finished) │ └────┬───────┘ └──────────────┘ ▼ ┌─────────────────────────────────────────┐ │ 外部系统执行工具 → 拿到 Observation │ └─────────────────┬───────────────────────┘ ▼ ┌─────────────────┐ │ 需要反思/纠错 │ └────────┬────────┘ │ ┌──────────┴─────────┐ ▼ ▼ [是] [否] ▼ ▼ ┌──────────┐ ┌──────────────┐ │ 反思错误 │ │ 把 Observation│ │ 调整计划 │ │ 写入 Memory │ └────┬─────┘ └──────┬───────┘ │ │ └─────────┬─────────┘ ▼ ┌─────────────────────────────────────────┐ │ Memory记忆更新: 把行动和结果存档 │ │ 短期: 加入对话上下文 │ │ 长期: 写入向量数据库/经验库 │ └─────────────────┬───────────────────────┘ ▼ ┌─────────────────┐ │ 任务完成了吗 │ └────────┬────────┘ │ ┌──────────┴────────┐ ▼ ▼ [否] [是] ▼ | 回到「大脑思考」环节 │ ▼ ┌──────────────┐ │ 输出最终结果✅ │ └──────────────┘5.4 Multi-Agent多 Agent 协作5.4.1 基础知识核心逻辑多个 Agent 分工合作各司其职每个板块都可以做的很精通避免角色冲突举例任务开发一个电商网站 Agent A [产品经理]分析需求写 PRD 文档 ↓ Agent B [架构师]根据 PRD 设计技术方案 ↓ Agent C [前端开发]写前端代码 ↓ Agent D [后端开发]写后端代码 ↓ Agent E [测试]运行测试报告 bug ↓ 发现 bug→ 返回给 C/D 修复 → 再交给 E 测试关键点每个 Agent 有自己的角色设定System Prompt和工具集。Agent 之间通过「消息传递」协作而不是共享同一个上下文。需要一个协调者Orchestrator来分配任务和汇总结果。5.4.2 合作模式层级式Hierarchical / 中央调度原理一个中心节点拥有全局视角其他节点是执行者。适用场景任务目标明确、可以预先拆解成独立子任务如写报告、做调研。要点Orchestrator 本身也是一个 LLM它的 Prompt 要强调「只调度、不执行」。子 Agent 的输出要结构化方便 Orchestrator 汇总。┌─────────────┐ │ Orchestrator │ ← 总指挥理解任务、拆解、分配、汇总 │ (调度者) │ └──────┬──────┘ │ ┌─────────┼─────────┐ ▼ ▼ ▼ ┌───────┐ ┌───────┐ ┌───────┐ │Agent A│ │Agent B│ │Agent C│ ← 各负责一个子任务 │(调研) │ │(分析) │ │(写作) │ └───────┘ └───────┘ └───────┘流水线式Pipeline / 接力原理像工厂流水线每个 Agent 只处理一个环节输出作为下一个 Agent 的输入。适用场景任务有明确的先后顺序且每个环节的输出格式稳定如内容生产、数据处理。要点前一环节的输出质量直接影响后一环节所以接口契约输出格式必须严格定义。如果 Agent B 发现 Agent A 的输出有问题需要有回退机制打回重写或自己修正。用户输入 → [Agent A: 提取关键词] → [Agent B: 检索资料] → [Agent C: 生成摘要] → [Agent D: 审核] → 输出对等协作式Peer-to-Peer原理多个 Agent 平等对话通过讨论、辩论、协商来达成共识或产出更优方案。适用场景需要多角度思考、创意发散、方案评估如头脑风暴、策略辩论、代码 Review。要点必须设定终止条件如轮次上限、共识达成标准否则会无限讨论下去。引入一个「仲裁 Agent」来打破僵局否则容易陷入僵局。┌─────────┐ 讨论/协商 ┌─────────┐ │ Agent A │ ←────────────────→ │ Agent B │ │(正方) │ │(反方) │ └────┬────┘ └────┬────┘ │ │ └──────────┬───────────────────┘ ▼ ┌─────────┐ │ Agent C │ ← 观察者/仲裁者 │(评委) │ └─────────┘竞争式Competitive / 赛马原理多个 Agent 各自独立出方案由评审 Agent 打分或投票选出最佳。适用场景创意生成、文案写作、方案设计需要多样性时。要点Judge Agent 的评估标准必须事先明确否则打分主观性太强。可以结合「迭代优化」选出的最优方案再交给 Agent 做 refine。举例用户任务 → [Agent A 生成方案] ─┐ [Agent B 生成方案] ─┼→ [Judge Agent 评估打分] → 选出最优 [Agent C 生成方案] ─┘5.4.3 通信机制共享记忆池Shared Memory原理所有 Agent 读写同一个状态空间如一个结构化的 JSON、数据库、或黑板。优点信息透明任何 Agent 都能看到全局进度。缺点容易产生写冲突两个 Agent 同时改同一块需要锁机制或顺序控制。消息传递Message Passing原理Agent 之间像发微信一样点对点通信。优点通信精准不污染其他 Agent 的上下文。缺点信息可能孤岛化——Agent C 不知道 A 和 B 聊了什么需要显式转发。广播式Broadcast原理一个 Agent 的输出广播给所有其他 Agent。优点信息同步快。缺点每个 Agent 的上下文会被大量无关信息撑爆需要信息过滤层。5.4.5 注意点上下文割裂问题最严重现象Agent A 知道「用户喜欢简洁风格」但这个信息没有传给 Agent B导致 B 写得很啰嗦。根因每个 Agent 是独立的 LLM 调用上下文不共享。对策设立全局上下文如用户画像、风格指南每个 Agent 的 Prompt 开头都注入。关键信息在 Agent 间传递时用显式摘要而非「你自己去看」。循环依赖与死锁现象Agent A: 等 Agent B 给我数据 Agent B: 等 Agent C 给我结论 Agent C: 等 Agent A 给我方向对策设置最大轮次/超时机制。层级式架构中Orchestrator 必须有强制中断权。接口契约不一致现象Agent A 输出的是 Markdown 列表Agent B 期望的是 JSON导致解析失败。对策在 Agent 间定义严格的 Schema如 Pydantic 模型输出不符合就重试。加一个「格式转换 Agent」作为适配层。责任模糊与推诿现象两个 Agent 的职责有重叠出了问题互相甩锅。对策每个 Agent 的 System Prompt 必须明确定义输入、输出、职责边界。避免「你帮忙看看」这种模糊指令改成「你负责检查代码中的 SQL 注入漏洞」。成本与延迟的指数增长现象5 个 Agent 各轮 3 次就是 15 次 LLM 调用响应时间 30 秒。对策能串行不并行能并行不串行没有依赖关系的子任务同时调用。引入「快路径」简单任务不走多 Agent直接单 Agent 解决。小模型做路由/筛选大模型只做核心决策。
1. AI 应用的工作模式
目录1 工作模式概述2 关于“中枢”2.1 基础原理2.2 关于“多模态模型”2.3 生成图、视频、音频的模型3 关于“记忆”3.1 上下文是怎么传递给模型的3.2 超长上下文是怎么处理的3.3 长上下文为什么变慢、变贵4 关于“工具”4.1 基础知识4.2 工具说明书很长很大怎么办5 关于“行为模式 / 规划”5.1 ReActReasoning Acting5.2 Plan-and-Solve5.3 Reflexion反思型 Agent5.4 Multi-Agent多 Agent 协作5.4.1 基础知识5.4.2 合作模式5.4.3 通信机制5.4.5 注意点1 工作模式概述我们可以从基础模型开始逐渐给它加能力来了解从简单到复杂的 AI 应用的底层逻辑。中枢 / 大脑底层大模型记忆记录上下文对话内容把历史记录也作为输入工具让大模型先判断是否需要调用工具比如需要调用则调用工具然后把用户问题工具结果一起传给模型工具包括 向量数据库、网络搜索、本地编程、其他本地工具行为模式 / 规划例如先做计划再一步步完成任务再比如通过“思考 → 行动 → 观察 → 再思考”的循环来完成任务。如果上述都具备我们可以将其称为 AI Agent也就是一个智能体。2 关于“中枢”2.1 基础原理模型架构Transformer核心结构self attention2.2 关于“多模态模型”多模态模型的架构图像/音频/视频 → [模态专属 Encoder] ★★★ → [Projector/Adapter 对齐层] ★★★ → [统一 LLM]文本 → [文本 Embedding] → 已经在 LLM 空间内各模态怎么变成「Token」每个模态的输入先通过各自的 Encoder 变成相应的 “token 序列”或者叫 高维向量序列 更严谨。此时图像、音频、文本 token 的向量空间不兼容。所以需要一层 Projector / Adapter / Connector叫法不同作用一样通常是一个轻量的 MLP多层感知机也可以叫全连接层或少量 Transformer 层把视觉/音频特征向量映射到 LLM 的 embedding 空间。2.3 生成图、视频、音频的模型文生图T2I演进路线U-Net → DiTDiffusion TransformerDiTDiffusion Transformer。通过 VAE如 SD 的 8× 压缩 VAE把图像压到隐空间,再切成 patch当成序列用 Transformer 处理。文本条件注入方式Cross-Attention早期图像 token 作为 Query文本 token 作为 Key/Value早期 DiT 如 PixArtJoint Self-AttentionMM-DiT现在主流把图像 token 和文本 token 拼接在一起统一过 Self-Attention双向信息流动SD3、Flux 等主流方案文生视频 / 图生视频T2V / I2V演进3D U-Net → DiT 3D VAE视频被当作「时空立方体」处理文生音乐T2M架构最多样化没有一家独大的情况架构路线代表模型原理自回归 TransformerMusicGen、Suno、Jukebox音频先通过VQ-VAE / EnCodec编码成离散 token类似文本 token然后用 Transformer像写文本一样逐个预测音频 token。文本条件通过 Cross-Attention 或前缀嵌入注入。Diffusion / DiTStable Audio Open、MusicLDM在音频的连续隐空间如 Mel 谱或 VAE 隐空间上做扩散去噪骨干可以是 U-Net 或 DiT。Flow MatchingMusicFlow类似扩散但用流匹配目标函数训练更稳定。State-Space Models (SSM)Prefix SiMBA用 Mamba/S4 等状态空间模型替代 Transformer声称在长序列上训练效率更高。混合架构Seed-MusicTransformer 做理解 Diffusion 做生成或分阶段生成先粗后细。音频 tokenization 是关键音频采样率极高44.1kHz不能直接逐采样点生成。通常先用 VQ-VAE如 EnCodec、SoundStream把波形压缩成几百到几千 Hz 的离散 token再在 token 空间生成。自回归 vs 扩散的选择自回归生成速度快一次前向一个 token适合实时应用但长音频一致性依赖模型记忆。扩散生成质量高、可控性强但需要多步迭代速度慢。文生音乐目前自回归 Transformer 和 Diffusion 并存Suno 等商业产品多用自回归路线而研究界在探索 DiT 和 SSM 替代方案。3 关于“记忆”3.1 上下文是怎么传递给模型的首先我要讲一下 AI 应用调用大模型的方法。大模型能力一般都会封装成 API它可能部署在公司本地的服务器也可能是使用第三方提供的接口。应用的后端通过调用API来和模型对话。上下文一般会以列表的形式记录列表中是一个一个的“对象”每个对象至少包含“角色标签”以及他说的“内容”。然后整个列表传递给 大模型API。大模型API 可以简单分成“应用层”和“模型层”模型层接收的就是一个“字符串”当然“模型层”内部还会把字符串转为 token 串最终交给模型本身。那么对于调用 API 接口的人而言对话列表需要转换成字符串中间会出些一些专门用于切分和标注的特殊token。大致就像下面这样API 接收的对话列表{messages:[{role:system,content:你是一个 helpful 的助手},{role:user,content:你好},{role:assistant,content:你好有什么可以帮你的},{role:user,content:今天天气怎么样}]}API 应用层转为字符串将要传给“模型层”s[INST] SYS 你是一个 helpful 的助手 /SYS 你好 [/INST] 你好有什么可以帮你的 /ss[INST] 今天天气怎么样 [/INST]3.2 超长上下文是怎么处理的模型能力很多模型接受超长的输入也就是输入token数的上限高比如市面上可以找到上限在 128k、200k、1M 的模型。补充有些模型通过架构层面的优化来做到炒成上下文处理常见技术包括稀疏注意力、分层注意力、Ring Attention、Longformer模型外的策略滑动窗口摘要压缩前面的对话总结成一段摘要替代原始消息RAG把历史存入向量数据库每次只检索「相关的」片段3.3 长上下文为什么变慢、变贵Transformer 的注意力机制复杂度是 O(n²)4 关于“工具”工具调用的业界专业名词是Function Calling4.1 基础知识要点结构化输出训练时约定了比如有工具列表而用户问题需要调用工具那么模型返回的输出就是一个结构化的用于工具调用的结果比如某种格式的 json需要工具列表在调用 模型API 的时候对话记录、可用工具表存放在不同的字段一同传递给模型循环调用一个涉及工具调用的系统一般是循环调用的比如一致循环到模型不再输出“工具调用”的请求而是直接输出文本为止。框架很多框架LangChain、AutoGen、OpenAI 的 Assistants API把循环框架定义好了你只需要定义工具函数然后运行开始对话框架自动完成「生成 → 执行 → 再生成」的循环一个案例看懂工具调用流程用户问北京今天天气怎么样 ↓ [步骤1] 模型收到问题 系统提示告诉它有哪些工具可用 ↓ [步骤2] 模型生成一段工具调用请求JSON格式 { name: get_weather, arguments: { city: 北京, date: 今天 } } 注意模型此时还没有回答用户它只输出了这个 JSON ↓ [步骤3] 外部系统API后端/你的代码解析这个 JSON 发现要调用 get_weather 函数于是真的去查天气 API ↓ [步骤4] 工具返回结果 {temperature: 32°C, condition: 晴, humidity: 45%} ↓ [步骤5] 外部系统把工具结果包装成一条新消息塞回对话列表 ↓ [步骤6] 模型再次收到「原始问题 工具调用记录 工具返回结果」 这次它生成最终回复北京今天天气晴朗气温 32°C湿度 45%。4.2 工具说明书很长很大怎么办方法1精简工具描述Prompt 工程优化手段做法效果删除冗余只保留「工具名 一句话功能 必填参数」删除示例、默认值说明、长篇背景减少 50%~70% token参数分级把参数分为「常用参数」和「高级参数」默认只展示常用参数降低认知负担结构化极简不用自然语言段落用表格或 JSON Schema 的精简版模型对结构化信息更敏感方法2工具分组, 参数合并分组描述减少共用参数的冗余描述方法3动态筛选原理方法小的意图模型规则引擎关键词匹配一个 Embedding 检索系统RAG方法4工具说明书原理Prompt 里只放工具摘要工具的详细参数说明放在外部需要调用函数时把完整工具说明放入上下文5 关于“行为模式 / 规划”在 Function Calling 的部分我们已经注意到需要“循环调用”来让流程自动完成某些任务。所以自然我们就会问出1循环的终止条件是什么2更复杂和完备的行为模式有哪些3我如何自己设计行为模式总览模式核心逻辑适合什么任务ReAct边想边干动态调整信息检索、问答、探索性任务Plan-and-Solve先定计划再执行报告生成、复杂工作流Reflexion干完复盘自我纠错代码生成、数学计算、需要验证的任务Multi-Agent分工协作各司其职大型项目、需要多角色配合的任务5.1 ReActReasoning Acting核心逻辑思考 → 行动 → 观察 → 再思考 → 再行动……过程举例用户问2024年诺贝尔物理学奖得主是谁他现在的年龄是多少 Step 1 [思考]用户想知道2024年诺贝尔物理学奖得主及其年龄。 我需要先搜索2024年诺贝尔物理学奖得主是谁。 Step 2 [行动]调用 search_tool(query2024年诺贝尔物理学奖得主) Step 3 [观察]工具返回结果约翰·霍普菲尔德John Hopfield和杰弗里·辛顿Geoffrey Hinton Step 4 [思考]得主有两位。用户问他单数可能需要分别查两人的年龄。 先查约翰·霍普菲尔德的年龄。 Step 5 [行动]调用 search_tool(queryJohn Hopfield age 2024) Step 6 [观察]工具返回约翰·霍普菲尔德出生于1933年7月15日2024年91岁。 Step 7 [思考]再查杰弗里·辛顿的年龄。 Step 8 [行动]调用 search_tool(queryGeoffrey Hinton age 2024) Step 9 [观察]工具返回杰弗里·辛顿出生于1947年12月6日2024年76岁。 Step 10 [思考]我已经收集到全部信息可以回答用户了。 Step 11 [回答]2024年诺贝尔物理学奖授予了约翰·霍普菲尔德和杰弗里·辛顿。 其中霍普菲尔德91岁辛顿76岁。提示词核心公式角色设定 工具说明书 严格的 Thought/Action/Observation 格式规范 2 个多轮 Few-shot 示例 Final Answer 终止信号。举例你是一个智能助手可以通过调用工具来解决用户的问题。 ## 可用工具 1. **search**(query: string): 搜索引擎用于查找实时信息、新闻、百科知识等。 2. **calculator**(expression: string): 计算器用于执行数学运算。 ## 输出格式规则 你必须严格按照以下格式输出每轮只输出 Thought 和 ActionObservation 由系统自动填入 Thought: 你对当前情况的思考。分析用户的问题判断是否需要调用工具如果需要决定调用哪个工具以及参数是什么。 Action: 工具名称和参数参数必须是合法的 JSON 格式。 系统会执行 Action 并返回 Observation然后你会继续 你可以进行多轮 Thought/Action/Observation。当你认为已经获得足够信息可以直接回答用户时输出 Thought: 我已经获得足够信息可以给出最终答案。 Final Answer: 对用户的最终回答。 ## 示例 1 Question: 2024年巴黎奥运会中国获得了多少枚金牌 Thought: 用户询问的是2024年巴黎奥运会中国代表团的金牌数量这是一个实时信息我需要调用搜索工具查询。 Action: search({query: 2024年巴黎奥运会中国金牌数量}) Observation: 2024年巴黎奥运会上中国体育代表团共获得40枚金牌、27枚银牌、24枚铜牌。 Thought: 我已经获得了确切信息中国获得了40枚金牌可以回答用户了。 Final Answer: 2024年巴黎奥运会上中国体育代表团共获得40枚金牌。 ## 示例 2 Question: 北京今天的气温乘以2再加上10等于多少 Thought: 这个问题需要两个步骤先查询北京今天的气温然后进行数学计算。我先搜索天气信息。 Action: search({query: 北京今天气温}) Observation: 北京今天晴气温22°C到33°C当前气温28°C。 Thought: 当前气温是28度。用户问的是28乘以2再加上10我需要用计算器。 Action: calculator({expression: 28 * 2 10}) Observation: 66 Thought: 计算结果是66我可以给出最终答案了。 Final Answer: 北京今天当前气温是28°C乘以2再加上10等于66。 ## 现在开始 Question: {用户输入} Thought:5.2 Plan-and-Solve过程举例先规划后执行用户问帮我调研一下新能源汽车行业写一份简要报告。 Step 1 [制定计划] 1. 搜索2024年全球新能源汽车销量数据 2. 搜索主要厂商比亚迪、特斯拉的市场份额 3. 搜索行业技术趋势固态电池、自动驾驶 4. 整合以上信息生成结构化报告 Step 2-4 [按步骤执行]逐个调用搜索工具收集信息。 Step 5 [汇总输出]基于所有收集到的信息生成最终报告。对比维度ReActPlan-and-Solve计划方式走一步看一步动态调整先定好完整路线图灵活性高能根据中间结果随时改计划低计划定了后很少改适用场景目标不明确、需要探索的任务目标明确、步骤清晰的任务风险可能陷入循环或偏离目标计划可能一开始就是错的实际应用很多 Agent 框架会把两者结合——先用 Plan-and-Solve 定大方向再用 ReAct 处理每个子步骤的细节。5.3 Reflexion反思型 Agent核心逻辑执行 →评估结果→反思错误→ 重新尝试关键点引入了一个「评估/反思」环节让 Agent 能自我纠错。通常需要一个「Evaluator」可以是另一个 LLM 调用也可以是单元测试、编译器等外部验证工具。反思的结果可以写入长期记忆下次遇到类似任务时避免犯同样的错。举例用户任务写一个 Python 函数计算斐波那契数列。 Step 1 [行动]LLM 生成代码并执行。 Step 2 [观察]运行报错——RecursionError: maximum recursion depth exceeded. Step 3 [反思]代码用了递归但没有基准条件导致无限递归。 我应该改用迭代方式或者加上 n1 的终止条件。 Step 4 [重新行动]生成修正后的代码。 Step 5 [验证]运行成功输出正确。单Agent 流程小结┌─────────────────────────────────────────┐ │ 用户输入任务 │ └─────────────────┬───────────────────────┘ ▼ ┌──────────────────────────────────────────┐ │ 大脑LLM: 理解任务 → 制定计划/思考 │ │ ReAct: Thought / Plan-and-Solve: Plan│ └─────────────────┬────────────────────────┘ ▼ ┌────────────────┐ │ 需要调工具吗 │ └───────┬────────┘ │ ┌─────────┴─────────┐ ▼ ▼ [是] [否] ▼ ▼ ┌────────────┐ ┌──────────────┐ │ 输出 Action │ │ 直接输出答案✅│ │ (工具调用) │ │ (Finished) │ └────┬───────┘ └──────────────┘ ▼ ┌─────────────────────────────────────────┐ │ 外部系统执行工具 → 拿到 Observation │ └─────────────────┬───────────────────────┘ ▼ ┌─────────────────┐ │ 需要反思/纠错 │ └────────┬────────┘ │ ┌──────────┴─────────┐ ▼ ▼ [是] [否] ▼ ▼ ┌──────────┐ ┌──────────────┐ │ 反思错误 │ │ 把 Observation│ │ 调整计划 │ │ 写入 Memory │ └────┬─────┘ └──────┬───────┘ │ │ └─────────┬─────────┘ ▼ ┌─────────────────────────────────────────┐ │ Memory记忆更新: 把行动和结果存档 │ │ 短期: 加入对话上下文 │ │ 长期: 写入向量数据库/经验库 │ └─────────────────┬───────────────────────┘ ▼ ┌─────────────────┐ │ 任务完成了吗 │ └────────┬────────┘ │ ┌──────────┴────────┐ ▼ ▼ [否] [是] ▼ | 回到「大脑思考」环节 │ ▼ ┌──────────────┐ │ 输出最终结果✅ │ └──────────────┘5.4 Multi-Agent多 Agent 协作5.4.1 基础知识核心逻辑多个 Agent 分工合作各司其职每个板块都可以做的很精通避免角色冲突举例任务开发一个电商网站 Agent A [产品经理]分析需求写 PRD 文档 ↓ Agent B [架构师]根据 PRD 设计技术方案 ↓ Agent C [前端开发]写前端代码 ↓ Agent D [后端开发]写后端代码 ↓ Agent E [测试]运行测试报告 bug ↓ 发现 bug→ 返回给 C/D 修复 → 再交给 E 测试关键点每个 Agent 有自己的角色设定System Prompt和工具集。Agent 之间通过「消息传递」协作而不是共享同一个上下文。需要一个协调者Orchestrator来分配任务和汇总结果。5.4.2 合作模式层级式Hierarchical / 中央调度原理一个中心节点拥有全局视角其他节点是执行者。适用场景任务目标明确、可以预先拆解成独立子任务如写报告、做调研。要点Orchestrator 本身也是一个 LLM它的 Prompt 要强调「只调度、不执行」。子 Agent 的输出要结构化方便 Orchestrator 汇总。┌─────────────┐ │ Orchestrator │ ← 总指挥理解任务、拆解、分配、汇总 │ (调度者) │ └──────┬──────┘ │ ┌─────────┼─────────┐ ▼ ▼ ▼ ┌───────┐ ┌───────┐ ┌───────┐ │Agent A│ │Agent B│ │Agent C│ ← 各负责一个子任务 │(调研) │ │(分析) │ │(写作) │ └───────┘ └───────┘ └───────┘流水线式Pipeline / 接力原理像工厂流水线每个 Agent 只处理一个环节输出作为下一个 Agent 的输入。适用场景任务有明确的先后顺序且每个环节的输出格式稳定如内容生产、数据处理。要点前一环节的输出质量直接影响后一环节所以接口契约输出格式必须严格定义。如果 Agent B 发现 Agent A 的输出有问题需要有回退机制打回重写或自己修正。用户输入 → [Agent A: 提取关键词] → [Agent B: 检索资料] → [Agent C: 生成摘要] → [Agent D: 审核] → 输出对等协作式Peer-to-Peer原理多个 Agent 平等对话通过讨论、辩论、协商来达成共识或产出更优方案。适用场景需要多角度思考、创意发散、方案评估如头脑风暴、策略辩论、代码 Review。要点必须设定终止条件如轮次上限、共识达成标准否则会无限讨论下去。引入一个「仲裁 Agent」来打破僵局否则容易陷入僵局。┌─────────┐ 讨论/协商 ┌─────────┐ │ Agent A │ ←────────────────→ │ Agent B │ │(正方) │ │(反方) │ └────┬────┘ └────┬────┘ │ │ └──────────┬───────────────────┘ ▼ ┌─────────┐ │ Agent C │ ← 观察者/仲裁者 │(评委) │ └─────────┘竞争式Competitive / 赛马原理多个 Agent 各自独立出方案由评审 Agent 打分或投票选出最佳。适用场景创意生成、文案写作、方案设计需要多样性时。要点Judge Agent 的评估标准必须事先明确否则打分主观性太强。可以结合「迭代优化」选出的最优方案再交给 Agent 做 refine。举例用户任务 → [Agent A 生成方案] ─┐ [Agent B 生成方案] ─┼→ [Judge Agent 评估打分] → 选出最优 [Agent C 生成方案] ─┘5.4.3 通信机制共享记忆池Shared Memory原理所有 Agent 读写同一个状态空间如一个结构化的 JSON、数据库、或黑板。优点信息透明任何 Agent 都能看到全局进度。缺点容易产生写冲突两个 Agent 同时改同一块需要锁机制或顺序控制。消息传递Message Passing原理Agent 之间像发微信一样点对点通信。优点通信精准不污染其他 Agent 的上下文。缺点信息可能孤岛化——Agent C 不知道 A 和 B 聊了什么需要显式转发。广播式Broadcast原理一个 Agent 的输出广播给所有其他 Agent。优点信息同步快。缺点每个 Agent 的上下文会被大量无关信息撑爆需要信息过滤层。5.4.5 注意点上下文割裂问题最严重现象Agent A 知道「用户喜欢简洁风格」但这个信息没有传给 Agent B导致 B 写得很啰嗦。根因每个 Agent 是独立的 LLM 调用上下文不共享。对策设立全局上下文如用户画像、风格指南每个 Agent 的 Prompt 开头都注入。关键信息在 Agent 间传递时用显式摘要而非「你自己去看」。循环依赖与死锁现象Agent A: 等 Agent B 给我数据 Agent B: 等 Agent C 给我结论 Agent C: 等 Agent A 给我方向对策设置最大轮次/超时机制。层级式架构中Orchestrator 必须有强制中断权。接口契约不一致现象Agent A 输出的是 Markdown 列表Agent B 期望的是 JSON导致解析失败。对策在 Agent 间定义严格的 Schema如 Pydantic 模型输出不符合就重试。加一个「格式转换 Agent」作为适配层。责任模糊与推诿现象两个 Agent 的职责有重叠出了问题互相甩锅。对策每个 Agent 的 System Prompt 必须明确定义输入、输出、职责边界。避免「你帮忙看看」这种模糊指令改成「你负责检查代码中的 SQL 注入漏洞」。成本与延迟的指数增长现象5 个 Agent 各轮 3 次就是 15 次 LLM 调用响应时间 30 秒。对策能串行不并行能并行不串行没有依赖关系的子任务同时调用。引入「快路径」简单任务不走多 Agent直接单 Agent 解决。小模型做路由/筛选大模型只做核心决策。