1. AI 应用的工作模式

目录

• [1 工作模式概述](#1 工作模式概述)
• [2 关于"中枢"](#2 关于“中枢”)
• • [2.1 基础原理](#2.1 基础原理)
  • [2.2 关于"多模态模型"](#2.2 关于“多模态模型”)
  • [2.3 生成图、视频、音频的模型](#2.3 生成图、视频、音频的模型)
• [3 关于"记忆"](#3 关于“记忆”)
• • [3.1 上下文是怎么传递给模型的](#3.1 上下文是怎么传递给模型的)
  • [3.2 超长上下文是怎么处理的](#3.2 超长上下文是怎么处理的)
  • [3.3 长上下文为什么变慢、变贵](#3.3 长上下文为什么变慢、变贵)
• [4 关于"工具"](#4 关于“工具”)
• • [4.1 基础知识](#4.1 基础知识)
  • [4.2 工具说明书很长很大怎么办](#4.2 工具说明书很长很大怎么办)
• [5 关于"行为模式 / 规划"](#5 关于“行为模式 / 规划”)
• • [5.1 ReAct（Reasoning + Acting）](#5.1 ReAct（Reasoning + Acting）)
  • [5.2 Plan-and-Solve](#5.2 Plan-and-Solve)
  • [5.3 Reflexion（反思型 Agent）](#5.3 Reflexion（反思型 Agent）)
  • [5.4 Multi-Agent（多 Agent 协作）](#5.4 Multi-Agent（多 Agent 协作）)
  • • [5.4.1 基础知识](#5.4.1 基础知识)
    • [5.4.2 合作模式](#5.4.2 合作模式)
    • [5.4.3 通信机制](#5.4.3 通信机制)
    • [5.4.5 注意点](#5.4.5 注意点)

1 工作模式概述

我们可以从基础模型开始，逐渐给它加能力，来了解从简单到复杂的 AI 应用的底层逻辑。

• 中枢 / 大脑：底层大模型
• 记忆：记录上下文对话内容，把历史记录也作为输入
• 工具：让大模型先判断是否需要调用工具，（比如需要调用，则调用工具，然后把用户问题+工具结果一起传给模型），工具包括 向量数据库、网络搜索、本地编程、其他本地工具
• 行为模式 / 规划：例如先做计划，再一步步完成任务，再比如通过"思考 → 行动 → 观察 → 再思考"的循环来完成任务。

如果上述都具备，我们可以将其称为 AI Agent，也就是一个智能体。

2 关于"中枢"

2.1 基础原理

• 模型架构：Transformer
• 核心结构：self attention

2.2 关于"多模态模型"

• 多模态模型的架构

图像/音频/视频
  →  [模态专属 Encoder] ★★★
  →  [Projector/Adapter 对齐层] ★★★
  →  [统一 LLM]文本
  →  [文本 Embedding] 
  →  （已经在 LLM 空间内）

• 各模态怎么变成「Token」
  每个模态的输入先通过各自的 Encoder 变成相应的 "token 序列"（或者叫 高维向量序列 更严谨）。
  此时，图像、音频、文本 token 的向量空间不兼容。所以需要一层 Projector / Adapter / Connector（叫法不同，作用一样）通常是一个轻量的 MLP（多层感知机，也可以叫全连接层）或少量 Transformer 层，把视觉/音频特征向量映射到 LLM 的 embedding 空间。

2.3 生成图、视频、音频的模型

• 文生图（T2I）

  • 演进路线：U-Net → DiT（Diffusion Transformer）
  • DiT（Diffusion Transformer）。通过 VAE（如 SD 的 8× 压缩 VAE）把图像压到隐空间,再切成 patch，当成序列用 Transformer 处理。
  • 文本条件注入方式：
    • Cross-Attention（早期）：图像 token 作为 Query，文本 token 作为 Key/Value（早期 DiT 如 PixArt）
    • Joint Self-Attention（MM-DiT）（现在主流）：把图像 token 和文本 token 拼接在一起，统一过 Self-Attention，双向信息流动（SD3、Flux 等主流方案）

• 文生视频 / 图生视频（T2V / I2V）

  • 演进：3D U-Net → DiT + 3D VAE（视频被当作「时空立方体」处理）

• 文生音乐（T2M）

  • 架构最多样化，没有一家独大的情况

架构路线	代表模型	原理
自回归 Transformer	MusicGen、Suno、Jukebox	音频先通过 VQ-VAE / EnCodec 编码成离散 token（类似文本 token），然后用 Transformer 像写文本一样逐个预测音频 token。文本条件通过 Cross-Attention 或前缀嵌入注入。
Diffusion / DiT	Stable Audio Open、MusicLDM	在音频的连续隐空间（如 Mel 谱或 VAE 隐空间）上做扩散去噪，骨干可以是 U-Net 或 DiT。
Flow Matching	MusicFlow	类似扩散，但用流匹配目标函数，训练更稳定。
State-Space Models (SSM)	Prefix SiMBA	用 Mamba/S4 等状态空间模型替代 Transformer，声称在长序列上训练效率更高。
混合架构	Seed-Music	Transformer 做理解 + 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] 你好！有什么可以帮你的？ </s><s>[INST] 今天天气怎么样 [/INST]

3.2 超长上下文是怎么处理的

• 模型能力：很多模型接受超长的输入，也就是输入token数的上限高，比如市面上可以找到上限在 128k、200k、1M 的模型。
  • 补充：有些模型通过架构层面的优化来做到炒成上下文处理，常见技术包括：稀疏注意力、分层注意力、Ring Attention、Longformer
• 模型外的策略
  • 滑动窗口
  • 摘要压缩：前面的对话总结成一段摘要，替代原始消息
  • RAG：把历史存入向量数据库，每次只检索「相关的」片段

3.3 长上下文为什么变慢、变贵

Transformer 的注意力机制复杂度是 O(n²)

4 关于"工具"

工具调用的业界专业名词是 Function Calling

4.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 ReAct（Reasoning + Acting）

• 核心逻辑：思考 → 行动 → 观察 → 再思考 → 再行动......
• 过程举例

用户问："2024年诺贝尔物理学奖得主是谁？他现在的年龄是多少？"

Step 1 [思考]：用户想知道2024年诺贝尔物理学奖得主及其年龄。
             我需要先搜索2024年诺贝尔物理学奖得主是谁。

Step 2 [行动]：调用 search_tool(query="2024年诺贝尔物理学奖得主")

Step 3 [观察]：工具返回结果："约翰·霍普菲尔德（John Hopfield）和杰弗里·辛顿（Geoffrey Hinton）"

Step 4 [思考]：得主有两位。用户问"他"（单数），可能需要分别查两人的年龄。
             先查约翰·霍普菲尔德的年龄。

Step 5 [行动]：调用 search_tool(query="John Hopfield age 2024")

Step 6 [观察]：工具返回："约翰·霍普菲尔德出生于1933年7月15日，2024年91岁。"

Step 7 [思考]：再查杰弗里·辛顿的年龄。

Step 8 [行动]：调用 search_tool(query="Geoffrey 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 和 Action，Observation 由系统自动填入：

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 [汇总输出]：基于所有收集到的信息，生成最终报告。

• 对比

维度	ReAct	Plan-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 [反思]：代码用了递归但没有基准条件，导致无限递归。
             我应该改用迭代方式，或者加上 n<=1 的终止条件。

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 合作模式

• 1. 层级式（Hierarchical / 中央调度）
  • 原理：一个中心节点拥有全局视角，其他节点是执行者。
  • 适用场景：任务目标明确、可以预先拆解成独立子任务（如写报告、做调研）。
  • 要点
    • Orchestrator 本身也是一个 LLM，它的 Prompt 要强调「只调度、不执行」。
    • 子 Agent 的输出要结构化，方便 Orchestrator 汇总。

        ┌─────────────┐
        │ Orchestrator │  ← 总指挥，理解任务、拆解、分配、汇总
        │  (调度者)    │
        └──────┬──────┘
               │
    ┌─────────┼─────────┐
    ▼         ▼         ▼
┌───────┐ ┌───────┐ ┌───────┐
│Agent A│ │Agent B│ │Agent C│  ← 各负责一个子任务
│(调研) │ │(分析) │ │(写作) │
└───────┘ └───────┘ └───────┘

• 2. 流水线式（Pipeline / 接力）
  • 原理：像工厂流水线，每个 Agent 只处理一个环节，输出作为下一个 Agent 的输入。

• 适用场景：任务有明确的先后顺序 ，且每个环节的输出格式稳定（如内容生产、数据处理）。

  • 要点：
    • 前一环节的输出质量直接影响后一环节，所以接口契约（输出格式）必须严格定义。
    • 如果 Agent B 发现 Agent A 的输出有问题，需要有回退机制（打回重写或自己修正）。

用户输入 → [Agent A: 提取关键词] → [Agent B: 检索资料] → [Agent C: 生成摘要] → [Agent D: 审核] → 输出

• 3. 对等协作式（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 注意点

• 1. 上下文割裂问题（最严重）
  • 现象：Agent A 知道「用户喜欢简洁风格」，但这个信息没有传给 Agent B，导致 B 写得很啰嗦。
  • 根因：每个 Agent 是独立的 LLM 调用，上下文不共享。
  • 对策：
    • 设立全局上下文（如用户画像、风格指南），每个 Agent 的 Prompt 开头都注入。
    • 关键信息在 Agent 间传递时，用显式摘要而非「你自己去看」。
• 2. 循环依赖与死锁
  • 现象

Agent A: "等 Agent B 给我数据"
Agent B: "等 Agent C 给我结论"
Agent C: "等 Agent A 给我方向"

• 对策：

  • 设置最大轮次/超时机制。
  • 层级式架构中，Orchestrator 必须有强制中断权。
• 3. 接口契约不一致
  • 现象：Agent A 输出的是 Markdown 列表，Agent B 期望的是 JSON，导致解析失败。
  • 对策：
    • 在 Agent 间定义严格的 Schema（如 Pydantic 模型），输出不符合就重试。
    • 加一个「格式转换 Agent」作为适配层。
• 4. 责任模糊与推诿
  • 现象：两个 Agent 的职责有重叠，出了问题互相甩锅。
  • 对策：
    • 每个 Agent 的 System Prompt 必须明确定义输入、输出、职责边界。
    • 避免「你帮忙看看」这种模糊指令，改成「你负责检查代码中的 SQL 注入漏洞」。
• 5. 成本与延迟的指数增长
  • 现象：5 个 Agent 各轮 3 次，就是 15 次 LLM 调用，响应时间 30 秒+。
  • 对策：
    • 能串行不并行，能并行不串行：没有依赖关系的子任务同时调用。
    • 引入「快路径」：简单任务不走多 Agent，直接单 Agent 解决。
    • 小模型做路由/筛选，大模型只做核心决策。