Frontier Vault

中文

English

中文

English

Appearance

AI Agent 技术理解：从 LLM、RAG 到 Agent 架构与 AI 测试体系 ​

副标题：技术原理与测试方法的双视角

目标读者：中高级工程师、测试与 QA 负责人、AI 工程化推进者

阅读时间：约 25 分钟

一句话

理解 AI 技术原理是做好 AI 测试的前提，而系统化的 AI 测试方法又是让 AI 能力在真实工程中稳定落地的保障。

目录 ​

一、为什么需要系统理解 AI Agent 技术 ​

很多团队在推进 AI 工程化时，会直接把能力要求写在岗位描述里：

研究 AI 工程、LLM、RAG、AI Agent 等技术原理，参与 AI 功能测试、AI 效果评测、AI 安全测试。

这条描述看似清晰，但实际执行时会暴露一个根本矛盾：懂技术原理的人不懂测试方法，懂测试方法的人不懂技术原理。

结果是两类常见问题：

  • 工程师能搭起 RAG 流水线，但不知道如何系统地验证检索质量、如何度量幻觉率、如何设计对抗样本；
  • 测试工程师能写传统功能用例，但面对概率性输出的 LLM，仍然用"输入 → 期望输出完全匹配"的思路去测，覆盖率极低且无法反映真实质量。

AI 测试和传统软件测试有本质区别。传统软件是"输入 + 固定程序 = 确定输出"，而 AI 系统是"输入 + 上下文 + 概率模型 = 概率性输出"。这意味着：

text
传统测试：验证"程序是否按规则执行"
AI 测试：验证"模型是否在能力边界内稳定输出符合预期的结果"

因此，理解 AI 技术原理不是测试人员的"附加技能"，而是做好 AI 测试的前置条件。只有理解了 Token、上下文窗口、采样参数、幻觉来源，才能设计出真正有效的测试用例；只有理解了 RAG 的检索与重排机制，才能定位"回答错误"的根因是检索召回不足还是生成阶段失真。

反过来，系统化的 AI 测试方法也能提升研发效率。它让团队从"凭感觉调 Prompt"转向"用指标驱动迭代"，从"上线后才发现问题"转向"在评测集上提前拦截回归"。

本文将沿着"技术原理 → 测试方法 → 效率提升"这条主线，系统梳理 LLM、RAG、AI Agent 的核心原理，以及 AI 功能测试、效果评测、鲁棒性测试、安全测试的工程化要点。

本节核心结论

理解 AI 技术原理是做好 AI 测试的前提，系统化的 AI 测试方法是让 AI 能力在真实工程中稳定落地的保障。二者必须双视角协同，缺一不可。

常见误区

把 AI 测试等同于"多写几条 Prompt 试一试"。AI 系统的概率性输出决定了它不能用确定性断言来测，必须有指标体系、评测集和回归基线。

二、LLM：AI Agent 的能力底座 ​

LLM（Large Language Model，大语言模型）是 AI Agent 的能力底座。Agent 的规划、工具调用、反思能力，本质上都建立在 LLM 的文本理解与生成能力之上。不理解 LLM 的工作机制，就无法理解 Agent 的能力边界和失败模式。

下图展示了 LLM 在工程实践中需要关注的关键约束链路：

mermaid
%%{init: {'theme': 'base', 'themeVariables': { 'fontFamily': 'Inter, PingFang SC, Microsoft YaHei, sans-serif', 'primaryColor': '#F8FAFC', 'primaryTextColor': '#172033', 'primaryBorderColor': '#CBD5E1', 'lineColor': '#64748B'}}}%%
flowchart LR
    Input["输入文本<br/>Prompt + 上下文"]
    Token["Tokenization<br/>分词与编码"]
    Context["上下文窗口<br/>容量上限与截断"]
    Sampling["采样参数<br/>temperature / top-p / top-k"]
    Output["输出 Token<br/>逐 Token 生成"]

    Input --> Token
    Token --> Context
    Context --> Sampling
    Sampling --> Output

    Halluc1["事实性幻觉<br/>训练知识缺失或过期"] -. 作用域 .-> Context
    Halluc2["忠实性幻觉<br/>忽略输入约束或编造引用"] -. 作用域 .-> Sampling

    classDef core fill:#172033,color:#fff,stroke:#172033,stroke-width:2px;
    classDef wait fill:#EEF6FF,stroke:#3B82F6,color:#172033,stroke-width:1.5px;
    classDef block fill:#FFF7E6,stroke:#F59E0B,color:#172033,stroke-width:1.5px;
    classDef work fill:#ECFDF3,stroke:#22C55E,color:#172033,stroke-width:1.5px;
    classDef metric fill:#F5E8FF,stroke:#A855F7,color:#172033,stroke-width:2px;

    class Input,Output work;
    class Token,Context wait;
    class Sampling block;
    class Halluc1,Halluc2 metric;

1. Token 与 Tokenization ​

LLM 处理的最小单位不是字符，而是 Token。Token 可以是一个词、一个子词，甚至是一个字符。同样的中文句子，不同分词器切分出的 Token 数量差异很大，这直接影响两件事：

  • 成本：API 计费通常按 Token 数计算；
  • 上下文占用：Token 数越多，越快触及上下文窗口上限。

例如"个人所得税申报"这句话，在不同分词器下可能被切成"个人 / 所得 / 税 / 申报"或"个人 / 所得税 / 申报"。工程上需要在选型时确认 Token 计数方式，避免按字符数估算导致成本和窗口超限。

2. 上下文窗口 ​

上下文窗口是模型一次能处理的最大 Token 数，包括输入和输出。它决定了 AI 一次能"放在工作台上"的信息容量。

上下文窗口有几点工程含义：

  • 超过窗口的内容会被截断或遗忘，导致"前面说过的约束后面不遵守"；
  • 窗口大不等于效果好，无关信息过多会稀释注意力，反而降低关键信息的权重；
  • 多轮对话、RAG 检索结果、工具调用返回值都占用窗口，需要主动管理。

3. 采样参数 ​

LLM 的输出不是确定性的，而是通过采样从概率分布中生成。采样参数直接控制输出的随机性和多样性：

  • temperature：控制概率分布的"尖锐程度"。值越低，模型越倾向于选概率最高的 Token，输出越稳定但越保守；值越高，输出越多样但越容易跑偏。代码生成通常用 0 到 0.3，创意写作用 0.7 到 1.0。
  • top-p（核采样）：只从累积概率超过 p 的 Token 集合中采样，p 通常设为 0.9 到 1.0。
  • top-k：只从概率最高的 k 个 Token 中采样，限制选择范围。
  • frequency penalty：对已出现过的 Token 施加惩罚，减少重复。
  • presence penalty：鼓励引入新话题，避免在同一个点上打转。

工程上，测试场景通常需要固定 temperature 为 0 或接近 0，以保证结果可复现；生产场景则需要在多样性和稳定性之间权衡。

4. 幻觉来源与类型 ​

幻觉（Hallucination）是 LLM 生成看似合理但实际错误内容的现象。理解幻觉的类型，是设计测试用例的前提：

  • 事实性幻觉：模型生成与客观事实不符的内容。根因是训练数据的知识缺失、过期或错误。例如模型不知道最新政策，仍按旧规则回答。
  • 忠实性幻觉：模型生成与给定输入或上下文冲突的内容。根因是模型忽略输入约束、过度泛化或编造引用。例如 RAG 场景中，检索到了正确文档，但模型在回答时偏离了文档内容。

这两类幻觉的测试方法不同：事实性幻觉需要外部知识库比对，忠实性幻觉需要与检索内容或输入约束做一致性校验。

5. 能力边界 ​

LLM 的能力边界至少包括：

  • 知识截止日期：训练数据有时间限制，无法覆盖之后的事件；
  • 推理深度：复杂多步推理仍会出错，尤其在数学和逻辑链路较长时；
  • 工具感知：LLM 本身不能调用外部工具，需要 Agent 框架扩展；
  • 实时性：LLM 是静态模型，无法主动获取最新信息。

本节核心结论

LLM 的工程约束链路是：输入 → 分词 → 上下文窗口 → 采样参数 → 输出。理解 Token、上下文窗口、采样参数和幻觉类型，是设计 AI 测试用例和定位失败根因的基础。

常见误区

把幻觉简单归因为"模型不够强"。实际上幻觉有多种类型，事实性幻觉和忠实性幻觉的根因和测试方法完全不同，需要分别处理。

三、RAG：让 AI 获得私有知识 ​

RAG（Retrieval-Augmented Generation，检索增强生成）是让 LLM 获得私有知识、时效信息和领域文档的核心方案。它解决了 LLM 的三个固有局限：

  • 知识截止：模型训练数据有时间边界，无法回答最新事件；
  • 私有知识：企业内部文档、业务规则、产品手册不会出现在训练数据中；
  • 时效性：政策和配置频繁变化，模型权重无法实时更新。

RAG 的核心思想是：不在生成阶段依赖模型记忆，而是在生成前把相关知识检索出来，作为上下文提供给模型。

下图展示了 RAG 的完整流水线：

mermaid
%%{init: {'theme': 'base', 'themeVariables': { 'fontFamily': 'Inter, PingFang SC, Microsoft YaHei, sans-serif', 'primaryColor': '#F8FAFC', 'primaryTextColor': '#172033', 'primaryBorderColor': '#CBD5E1', 'lineColor': '#64748B'}}}%%
flowchart LR
    Doc["原始文档<br/>PDF / HTML / Markdown"]
    Chunk["切片<br/>固定长度 / 语义 / 递归"]
    Embed["嵌入模型<br/>Embedding"]
    VectorDB[("向量数据库<br/>存储与索引")]
    Query["用户查询"]
    Retrieve["检索<br/>稠密 / 稀疏 / 混合"]
    Rerank["重排<br/>Reranking"]
    LLM["LLM 生成"]
    Answer["带引用的回答"]

    Doc --> Chunk
    Chunk --> Embed
    Embed --> VectorDB
    Query --> Retrieve
    VectorDB --> Retrieve
    Retrieve --> Rerank
    Rerank --> LLM
    LLM --> Answer

    classDef core fill:#172033,color:#fff,stroke:#172033,stroke-width:2px;
    classDef wait fill:#EEF6FF,stroke:#3B82F6,color:#172033,stroke-width:1.5px;
    classDef block fill:#FFF7E6,stroke:#F59E0B,color:#172033,stroke-width:1.5px;
    classDef work fill:#ECFDF3,stroke:#22C55E,color:#172033,stroke-width:1.5px;
    classDef metric fill:#F5E8FF,stroke:#A855F7,color:#172033,stroke-width:2px;

    class Doc,Query,Answer work;
    class Chunk,Embed wait;
    class Retrieve,Rerank block;
    class VectorDB metric;
    class LLM core;

1. 切片策略 ​

文档需要切分成片段（chunk）才能被有效检索和嵌入。切片策略直接影响检索质量：

  • 固定长度切片：按字符数或 Token 数切分，实现简单但可能打断语义。通常配合重叠窗口（overlap）减少边界信息丢失。
  • 语义切片：按段落、标题或句子边界切分，保留语义完整性。适用于结构化文档。
  • 递归切片：先按大结构（章节）切，再按小结构（段落）切，逐层递归。兼顾粒度和语义，是当前主流方案。

切片过大会稀释相关性并占用窗口，切片过小会丢失上下文。工程上需要根据文档类型和查询场景调优。

2. 嵌入模型与向量数据库 ​

嵌入模型（Embedding Model）把文本转换为高维向量，使语义相近的文本在向量空间中距离更近。选择嵌入模型时需要关注：

  • 支持的语言和领域（通用 vs 法律 vs 医疗）；
  • 向量维度（影响存储和检索效率）；
  • 最大输入长度（决定单个切片的上限）。

向量数据库负责存储和检索向量，常见选项包括 FAISS、Milvus、Pinecone、Weaviate、Qdrant。选型时关注：规模扩展性、过滤能力（按元数据筛选）、混合检索支持和部署方式。

3. 检索策略 ​

  • 稠密检索（Dense Retrieval）：基于向量相似度检索，擅长语义匹配，但对精确关键词不敏感。
  • 稀疏检索（Sparse Retrieval）：基于关键词匹配（如 BM25），擅长精确匹配术语和编号，但对语义改写不敏感。
  • 混合检索（Hybrid Retrieval）：结合稠密和稀疏检索结果，通过加权融合或重排取长补短。这是生产环境的推荐方案。

4. 重排 ​

初步检索通常返回较多候选，重排（Reranking）阶段用更精细的模型对候选重新打分，把最相关的片段排到前面。重排模型比嵌入模型更慢但更准，因此采用"先粗筛后精排"的两阶段架构。

5. 引用与溯源 ​

RAG 的回答应支持引用溯源，即标注每个结论来自哪个文档的哪个片段。这不仅提升可信度，也是测试时定位"幻觉来源"的关键依据。没有引用的回答，无法判断是模型编造还是基于检索内容。

本节核心结论

RAG 的质量由切片、嵌入、检索、重排四个环节共同决定。任何一个环节的缺陷都会导致"检索不到"或"检索到了但没用上"，测试时需要分段定位而非只看最终回答。

工程启示

RAG 测试不能只测最终回答，必须分别度量检索阶段（召回率、精确率）和生成阶段（忠实度、引用准确率），才能定位质量瓶颈。

四、AI Agent 架构：从单轮对话到自主执行 ​

LLM 本身是一个"接收文本、输出文本"的模型。Agent 是在 LLM 之上构建的运行时框架，让 AI 能够感知环境、规划任务、调用工具、观察结果、反思修正，最终自主完成多步目标。

1. Agent vs Chatbot 的区别 ​

维度ChatbotAgent
交互模式单轮或被动多轮主动多步执行
工具使用无主动调用外部工具
状态管理仅对话历史短期 + 长期记忆
失败处理直接返回错误观察失败 → 反思 → 重试
目标达成回答问题完成任务

核心区别在于：Chatbot 的终点是"给出回答"，Agent 的终点是"完成任务"。

2. 规划 ​

规划（Planning）是 Agent 把复杂目标分解为可执行步骤的能力。常见模式包括：

  • ReAct（Reasoning + Acting）：交替进行推理和行动，每一步先思考再执行，适合探索性任务。
  • Plan-and-Execute：先制定完整计划再逐步执行，适合步骤明确但依赖关系复杂的任务。
  • 动态重规划：执行过程中根据观察结果调整计划，处理意外情况。

3. 工具调用 ​

工具调用（Function Calling / Tool Use）是 Agent 与外部世界交互的能力。模型根据任务选择合适的工具并生成调用参数，框架执行工具后把结果返回给模型。

工具调用的关键问题：

  • 工具选择准确性：模型是否选对了工具；
  • 参数生成正确性：参数类型、格式、取值是否符合工具签名；
  • 结果解读能力：模型能否正确理解工具返回的结构化数据。

4. 记忆 ​

  • 短期记忆：当前任务内的上下文，包括对话历史、已执行的步骤、中间结果。受上下文窗口限制。
  • 长期记忆：跨任务持久化的信息，通常通过向量数据库或键值存储实现，支持按需检索。

记忆管理是 Agent 稳定性的关键。记忆过长会导致窗口溢出和注意力稀释，记忆过短会导致上下文丢失和重复执行。

5. 反思 ​

反思（Reflection / Self-Critique）是 Agent 评估自身执行结果并修正的能力。例如执行测试失败后，Agent 分析失败原因，判断是环境问题、数据问题还是代码问题，再决定下一步行动。反思让 Agent 从"盲目执行"走向"有反馈的闭环"。

6. 多 Agent 协作 ​

复杂任务可以拆分给多个专业化 Agent 协作完成。常见模式包括：

  • 主管 + 执行者：一个 Agent 负责拆分和分发，其他 Agent 负责执行子任务；
  • 辩论：多个 Agent 从不同角度给出方案，再汇总决策；
  • 流水线：Agent 之间形成上下游关系，前一个的输出是后一个的输入。

下图展示了 Agent 的核心执行循环：

mermaid
%%{init: {'theme': 'base', 'themeVariables': { 'fontFamily': 'Inter, PingFang SC, Microsoft YaHei, sans-serif', 'primaryColor': '#F8FAFC', 'primaryTextColor': '#172033', 'primaryBorderColor': '#CBD5E1', 'lineColor': '#64748B'}}}%%
flowchart TB
    Perceive["感知<br/>接收任务与环境"]
    Plan["规划<br/>分解步骤与选择工具"]
    ToolCall["工具调用<br/>执行动作"]
    Observe["观察<br/>获取执行结果"]
    Reflect["反思<br/>评估结果与修正"]
    Act["行动<br/>输出或继续"]

    Perceive --> Plan
    Plan --> ToolCall
    ToolCall --> Observe
    Observe --> Reflect
    Reflect --> Act
    Act -. 需要继续 .-> Plan

    Memory[("记忆<br/>短期 + 长期")]

    Perceive -. 读写 .-> Memory
    Plan -. 读写 .-> Memory
    Observe -. 写入 .-> Memory
    Reflect -. 读写 .-> Memory

    classDef core fill:#172033,color:#fff,stroke:#172033,stroke-width:2px;
    classDef wait fill:#EEF6FF,stroke:#3B82F6,color:#172033,stroke-width:1.5px;
    classDef block fill:#FFF7E6,stroke:#F59E0B,color:#172033,stroke-width:1.5px;
    classDef work fill:#ECFDF3,stroke:#22C55E,color:#172033,stroke-width:1.5px;
    classDef metric fill:#F5E8FF,stroke:#A855F7,color:#172033,stroke-width:2px;

    class Perceive,Act work;
    class Plan,Reflect wait;
    class ToolCall,Observe block;
    class Memory metric;

本节核心结论

Agent 的核心是"感知 → 规划 → 工具调用 → 观察 → 反思 → 行动"的闭环，记忆贯穿全流程。Agent 测试的关键是验证闭环的每一步是否按预期执行，而非只测最终输出。

常见误区

认为"接了工具调用 API 就是 Agent"。真正的 Agent 需要具备规划、反思和动态调整能力，否则只是"带工具的 Chatbot"。

五、AI 功能测试 ​

AI 功能测试关注"系统是否按设计执行"。与传统功能测试不同，AI 功能测试需要处理概率性输出、多轮状态和工具调用的不确定性。

1. 输入等价类划分 ​

AI 系统的输入空间几乎是无限的，必须通过等价类划分来控制测试规模：

  • 有效输入：符合 Prompt 约束的正常输入，验证功能正确性；
  • 无效输入：超出约束的输入（如要求 JSON 却给了纯文本），验证降级和错误提示；
  • 边界输入：空输入、单字符、窗口上限长度、特殊字符组合；
  • 对抗输入：注入尝试、越权指令、Prompt 操纵。

2. 输出契约 ​

AI 输出虽是概率性的，但仍可以定义"输出契约"来验证：

  • 格式契约：是否返回了预期的格式（JSON / Markdown / 特定结构）；
  • Schema 契约：字段名、类型、必填项是否符合定义；
  • 内容约束：是否包含必须的信息（如引用来源）、是否触发了禁止内容。

输出契约不是"精确匹配"，而是"结构性约束"。

3. 工具调用正确性 ​

Agent 场景下需要专门验证工具调用：

  • 工具选择准确性：给定任务，是否选对了工具；
  • 参数生成正确性：参数类型、格式、取值范围是否合法；
  • 异常处理：工具超时、返回错误时，Agent 是否合理降级。

4. 多轮对话状态验证 ​

多轮对话需要验证状态连续性：

  • 上下文保持：第 N 轮是否还记得第 1 轮的约束；
  • 状态流转：任务状态是否正确推进（如"草稿 → 提交 → 审核"）；
  • 上下文遗忘：超长对话中关键信息是否被丢弃。

下面是一个 AI 功能测试用例的结构化示例：

yaml
case_id: AI-FUNC-001
objective: 验证 RAG 系统在给定文档范围内正确回答并标注引用

input_class: valid
test_data:
  query: "2025 年个人所得税起征点是多少？"
  context_docs:
    - doc_id: tax-policy-2025.md
      content: "2025 年个人所得税起征点为 60000 元/年。"

preconditions:
  - 向量库已索引 context_docs
  - temperature 设置为 0

expected_contract:
  format: markdown
  must_contain:
    - "60000"
    - "元/年"
  must_cite:
    - doc_id: tax-policy-2025.md
  forbidden_content:
    - 编造未在文档中出现的数字
  schema:
    answer_field: string
    citations: array

evaluation:
  type: rule_based
  rules:
    - 引用来源必须包含 tax-policy-2025.md
    - 回答中出现的数字必须与文档一致

对于工具调用场景：

yaml
case_id: AI-FUNC-002
objective: 验证 Agent 在查询天气任务中选择正确的工具并生成合法参数

input_class: valid
test_data:
  query: "查一下北京明天的天气"

expected_contract:
  tool_selection:
    expected_tool: get_weather
    confidence_threshold: 0.9
  tool_arguments:
    location:
      type: string
      must_match: "北京"
    date:
      type: string
      format: date
      must_be: tomorrow

evaluation:
  type: llm_as_judge
  criteria: "工具选择是否正确，参数是否完整且合法"

本节核心结论

AI 功能测试的核心是"用结构化契约替代精确匹配"。通过输入等价类划分、输出契约验证、工具调用正确性和多轮状态验证，把概率性输出纳入可控的测试框架。

工程启示

把 AI 功能测试用例结构化（如上面的 YAML 格式），既便于人工维护，也便于自动化执行和回归。测试用例本身就是一种"机器可消费的上下文"。

六、AI 效果评测 ​

功能测试回答"能不能用"，效果评测回答"好不好用"。AI 系统的效果需要用指标体系来量化，而非靠主观感受。

1. 指标体系 ​

不同任务类型适用不同指标：

指标适用场景含义局限
准确率（Accuracy）分类任务预测正确的比例类别不均衡时失真
召回率（Recall）检索任务相关内容被检索到的比例不考虑精确度
F1分类 / 检索精确率与召回率的调和平均无法反映排序质量
ROUGE文本摘要生成文本与参考文本的 n-gram 重叠忽略语义相似性
BLEU机器翻译生成文本与参考文本的 n-gram 精确率对参考文本依赖强
pass@k代码生成k 次尝试中至少一次通过测试的比例需要 executable 测试
人类偏好胜率对话 / 生成人工评判中优于基线的比例成本高、主观性强

2. 人工评测 ​

人工评测是效果评测的"金标准"，但成本高且容易不一致。要做好人工评测，需要：

  • 标注规范：明确评分维度、评分标准和示例，避免"凭感觉打分"；
  • 一致性校验：同一样本由多人标注，计算一致率（如 Cohen's Kappa），低于阈值时修订规范；
  • 成本控制：抽样标注而非全量标注，优先标注高价值和边界样本。

3. 自动评测 ​

自动评测是大范围评测的必要手段：

  • LLM-as-a-Judge：用更强的模型评判被测模型的输出，适用于开放式任务。需要注意评判模型自身的偏差和能力上限。
  • Pairwise 比较：让评判模型在两个候选回答中选优，比绝对打分更稳定。
  • Reference-free 评测：不依赖标准答案，直接评估回答质量（如事实性、连贯性、完整性）。

自动评测不能完全替代人工评测，但可以作为人工评测的扩展和回归基线。

4. Benchmark ​

  • 公开 Benchmark：如 MMLU、HumanEval、GSM8K，适合横向对比模型能力，但可能与业务场景脱节。
  • 私有 Benchmark：基于业务数据构建的评测集，更贴近真实场景，但需要持续维护和防止数据污染。
  • 数据污染：评测数据如果泄漏到训练数据中，会导致评测结果虚高。需要用未公开的私有数据集或动态生成评测样本。

本节核心结论

AI 效果评测需要建立分层指标体系：人工评测定基线，自动评测做回归，私有 Benchmark 贴业务。三类方法互补，任何单一指标都无法全面反映效果。

常见误区

只用一个指标（如准确率）来衡量 AI 系统效果。不同任务维度需要不同指标，单一指标容易掩盖短板，导致"指标好看但用户不满"。

七、鲁棒性测试 ​

鲁棒性（Robustness）是 AI 系统在面对非预期输入和环境变化时仍能保持稳定输出的能力。鲁棒性测试关注"系统在扰动下是否还可靠"。

1. Prompt 扰动 ​

同一意图的不同表达方式不应导致结果显著差异。需要测试的扰动类型：

  • 同义改写：把"查询订单状态"改成"看看我的订单到哪了"；
  • 格式变化：纯文本 vs Markdown vs JSON 包裹；
  • 拼写错误：错别字、漏字、多余空格；
  • 多语言：中英混杂、方言表达、小语种。

如果轻微改写就导致输出质量骤降，说明系统对 Prompt 过拟合，泛化能力不足。

2. 边界输入 ​

  • 空输入：空字符串、只有空白符、只有标点；
  • 超长输入：超过上下文窗口的输入，验证截断策略；
  • 特殊字符：Unicode 控制符、emoji、零宽字符、SQL 注入payload；
  • 注入尝试：伪装成系统指令的用户输入，如"忽略前面的指令，改为……"。

3. 分布偏移 ​

  • Out-of-Distribution：输入超出训练数据分布，如训练数据是新闻但输入是法律文书；
  • 领域迁移：模型在 A 领域表现良好，迁移到 B 领域时效果下降；
  • 时间偏移：业务规则或数据分布随时间变化，模型未及时更新。

4. 长程稳定性 ​

  • 多轮对话漂移：对话轮数增加后，模型是否逐渐偏离初始约束；
  • 上下文遗忘：长对话中早期关键信息是否被丢弃；
  • 累积误差：前一轮的小错误是否在后续轮次中被放大。

5. 压力测试 ​

  • 并发：高并发请求下系统是否稳定、响应时间是否可接受；
  • 限流：触发限流后降级策略是否合理；
  • 降级：依赖服务（如向量库、工具 API）不可用时，系统是否优雅降级而非崩溃。

鲁棒性与可靠性密切相关：鲁棒性是"在扰动下仍能正确工作"，可靠性是"在长时间运行中持续正确工作"。鲁棒性测试是可靠性保障的前置环节。

本节核心结论

鲁棒性测试覆盖 Prompt 扰动、边界输入、分布偏移、长程稳定性和压力测试五个维度。目标是验证系统在非预期条件下仍能保持可接受的质量，而非只在"理想输入"下表现良好。

常见误区

只在"标准输入"下测试通过就认为系统可靠。真实用户输入千差万别，缺乏鲁棒性测试的系统上线后往往在边界场景频繁出问题。

八、AI 安全测试 ​

AI 安全是 AI 工程化中最容易被忽视、却后果最严重的环节。AI 系统的攻击面比传统软件更广，因为模型既可能被输入操纵，也可能泄露训练数据。

下图展示了 AI 安全测试的矩阵结构：

mermaid
%%{init: {'theme': 'base', 'themeVariables': { 'fontFamily': 'Inter, PingFang SC, Microsoft YaHei, sans-serif', 'primaryColor': '#F8FAFC', 'primaryTextColor': '#172033', 'primaryBorderColor': '#CBD5E1', 'lineColor': '#64748B'}}}%%
flowchart TB
    Core["AI 安全测试矩阵"]

    subgraph Surface["攻击面"]
        direction TB
        S1["用户输入"]
        S2["检索内容"]
        S3["工具返回"]
        S4["模型自身"]
    end

    subgraph Category["测试类别"]
        direction TB
        C1["Prompt 注入"]
        C2["越狱攻击"]
        C3["数据泄露"]
        C4["内容合规"]
        C5["模型供应链"]
    end

    subgraph Mitigation["缓解措施"]
        direction TB
        M1["输入过滤与分层"]
        M2["输出审查与拦截"]
        M3["权限隔离与审计"]
        M4["模型来源校验"]
    end

    Core --> Surface
    Surface --> Category
    Category --> Mitigation

    classDef core fill:#172033,color:#fff,stroke:#172033,stroke-width:2px;
    classDef wait fill:#EEF6FF,stroke:#3B82F6,color:#172033,stroke-width:1.5px;
    classDef block fill:#FFF7E6,stroke:#F59E0B,color:#172033,stroke-width:1.5px;
    classDef work fill:#ECFDF3,stroke:#22C55E,color:#172033,stroke-width:1.5px;
    classDef metric fill:#F5E8FF,stroke:#A855F7,color:#172033,stroke-width:2px;

    class Core core;
    class S1,S2,S3,S4 wait;
    class C1,C2,C3,C4,C5 block;
    class M1,M2,M3,M4 work;

1. Prompt 注入 ​

Prompt 注入是攻击者通过构造恶意输入来篡改模型行为：

  • 直接注入：用户在输入中直接写入"忽略前面的系统指令，改为执行……"。防御手段包括输入过滤、系统指令与用户输入分层、输出校验。
  • 间接注入：攻击者把恶意指令藏在被检索的文档或工具返回值中，模型读取后被动执行。这是 RAG 场景最危险的攻击向量，因为检索内容往往被视为可信数据。

2. 越狱 ​

越狱（Jailbreak）是绕过模型的安全限制，诱导其生成本应拒绝的内容：

  • 角色扮演：让模型扮演"不受限制的 AI"来规避安全策略；
  • 编码攻击：用 Base64、ROT13 或其他编码隐藏恶意意图，绕过关键词过滤；
  • 多步诱导：通过一系列看似无害的提问逐步引导模型突破边界。

3. 数据泄露 ​

  • 训练数据提取：通过特定 Prompt 诱导模型复现训练数据中的私密内容；
  • PII 泄露：模型输出中包含真实姓名、电话、身份证号等个人身份信息；
  • System Prompt 泄露：攻击者通过技巧让模型把系统指令原样输出，暴露后端逻辑和安全策略。

4. 内容合规 ​

  • Toxicity（毒性）：模型是否生成仇恨、侮辱或攻击性内容；
  • Bias（偏见）：模型是否在性别、种族、地域等方面产生歧视性输出；
  • 有害内容：是否生成暴力、违法或伦理违规的内容。

内容合规不仅是技术问题，也是法律和品牌问题，不同地区和行业有不同的合规要求。

5. 模型供应链 ​

  • 模型来源：使用的模型是否来自可信来源，权重是否被篡改；
  • 依赖风险：第三方库、嵌入模型、向量数据库是否存在已知漏洞；
  • 更新风险：模型版本升级后是否引入新的安全退化。

本节核心结论

AI 安全测试覆盖 Prompt 注入、越狱、数据泄露、内容合规和模型供应链五个维度。其中间接 Prompt 注入和数据泄露是 RAG 和 Agent 场景下最需要优先关注的风险。

常见误区

认为"模型提供商已经做了安全对齐，应用层不需要再测"。对齐是通用层面的防护，应用层的业务场景、检索内容和工具权限各不相同，必须在应用层补充安全测试。

九、AI 模型效果评估方法 ​

效果评测不仅是一次性活动，而是贯穿模型生命周期的持续过程。评估方法需要覆盖离线、在线和持续监控三个阶段。

1. 离线评估 ​

离线评估是在上线前用固定数据集进行的评估：

  • Held-out set：从训练数据中划出未参与训练的子集，评估泛化能力；
  • 交叉验证：多折划分数据，减少单次划分的偶然性；
  • Golden set：人工标注的"黄金数据集"，作为质量基准，长期固定使用以支持版本对比。

离线评估的关键是数据集的代表性和不可泄漏性。

2. 在线评估 ​

在线评估是上线后基于真实流量和用户反馈的评估：

  • 生产指标：实际业务指标，如回答采纳率、任务完成率、用户满意度；
  • 用户反馈：点赞/点踩、评分、投诉；
  • 隐式信号：用户是否追问、是否重新提问、是否放弃任务。

在线评估反映真实效果，但反馈延迟且受外部因素干扰。

3. A/B 测试 ​

A/B 测试是对比不同版本效果的标准方法：

  • 实验设计：明确假设、分组策略、流量分配、实验周期；
  • 指标选择：主指标 + 护栏指标，主指标判断效果，护栏指标防止负向影响；
  • 显著性：用统计检验确认差异不是随机波动，通常要求 p 值小于 0.05。

4. 回归基线 ​

每次模型或 Prompt 迭代后，必须与基线版本对比：

  • 版本对比：新版本在 Golden set 上是否优于上一版本；
  • Quality Gate：定义质量门禁阈值，未达标则不允许上线；
  • 多维对比：不只看主指标，还要看鲁棒性和安全指标是否退化。

5. 持续监控 ​

  • Drift 检测：监控输入数据分布和输出质量是否随时间漂移；
  • 告警：关键指标跌破阈值时自动告警；
  • 定期复评：定期在更新后的评测集上重新评估，防止模型老化。

下表对比了离线评估和在线评估的关键差异：

维度离线评估在线评估
数据来源固定评测集真实用户流量
评估时机上线前上线后
反馈速度即时延迟
成本标注成本工程接入成本
代表性依赖评测集质量真实场景
适用场景版本对比、回归门禁效果验证、长期监控

本节核心结论

AI 模型效果评估需要"离线 + 在线 + 持续监控"三层闭环。离线评估守住上线门禁，A/B 测试验证真实效果，持续监控防止线上退化。三层缺一不可。

工程启示

把 Quality Gate 集成到 CI/CD 流水中，让每次模型或 Prompt 变更都必须通过 Golden set 评估才能上线，是把评估方法工程化的关键一步。

十、结合 AI 测试方法提升研发与测试效率 ​

前面几节讨论的是"如何测试 AI 系统"。本节讨论的是"如何用 AI 方法提升测试与研发效率"。这是 AI 测试体系的另一面价值：测试方法本身也可以被 AI 增强。

1. 测试生成 ​

AI 可以根据代码、接口定义或需求文档自动生成测试：

  • 单元测试：根据函数签名和实现生成测试用例，覆盖正常路径和边界条件；
  • E2E 测试：根据页面结构和用户流程生成端到端测试脚本；
  • 测试数据：根据业务规则生成符合约束的测试数据，包括边界值和异常值。

测试生成的关键不是"AI 会写测试代码"，而是输入的上下文是否充分。这与上下文工程的理念一脉相承——给 AI 提供完整的需求、接口、约束和验收标准，才能生成可用的测试。

2. 缺陷预测 ​

基于历史缺陷数据，AI 可以预测哪些模块更容易出问题：

  • 热点模块识别：分析代码变更频率、复杂度和历史缺陷分布，识别高风险模块；
  • 缺陷优先级排序：对新发现的缺陷评估严重性和影响范围，辅助优先级排序；
  • 测试资源分配：把有限的测试资源集中到高风险模块，提升效率。

3. 回归筛选 ​

全量回归成本高，AI 可以帮助智能筛选：

  • Impact-based Selection：根据代码变更的影响范围选择需要运行的测试子集；
  • AI 优先级排序：根据历史失败率、代码关联度等特征对测试用例排序，优先运行高价值用例；
  • 动态调整：根据运行结果动态调整后续测试范围。

4. 质量门禁 ​

把 AI 审查和自动化测试结合，构建多层质量门禁：

text
代码提交
→ AI 静态审查（风格、安全、最佳实践）
→ 单元测试（自动生成 + 人工维护）
→ 集成测试
→ AI 效果评测（Golden set 回归）
→ 质量门禁判断
→ 允许合并或拒绝

每一层的输出都成为下一层的输入，形成反馈闭环。

5. Agent 驱动的测试闭环 ​

最前沿的实践是让 AI Agent 自主执行测试闭环：

text
接收测试任务
→ 检索相关代码和需求
→ 生成测试用例
→ 执行测试
→ 分析失败结果
→ 定位根因
→ 尝试修复
→ 重新验证
→ 输出测试报告

这个闭环正是上下文工程在测试领域的落地：Agent 在每一步获取的代码、需求、测试结果和工具反馈，都构成它下一步行动的上下文。上下文质量决定 Agent 测试闭环的可靠性。

本节核心结论

AI 测试方法不仅用于"测试 AI 系统"，还能反过来"提升测试与研发效率"。从测试生成、缺陷预测、回归筛选到 Agent 驱动的测试闭环，核心逻辑都是把上下文工程的理念应用到测试流程中。

工程启示

构建 Agent 驱动的测试闭环时，关键不是 Agent 能不能写测试代码，而是团队能否为 Agent 提供结构化的需求、接口、约束和验收标准。这和上下文工程的要求完全一致。

十一、AI 测试实践清单 ​

1. 技术原理理解 ​

2. AI 功能测试 ​

3. AI 效果评测 ​

4. 鲁棒性测试 ​

5. AI 安全测试 ​

6. 效率提升 ​

结语：从技术理解到工程落地 ​

本文从"技术原理"和"测试方法"双视角梳理了 AI Agent 技术体系：

text
技术原理侧：
LLM 能力底座
→ RAG 私有知识
→ Agent 自主执行

测试方法侧：
AI 功能测试
→ AI 效果评测
→ 鲁棒性测试
→ AI 安全测试
→ 模型评估方法
→ 效率提升实践

两条线不是平行的，而是相互支撑的：理解技术原理才能设计有效测试，系统化测试才能让技术能力稳定落地。

一个常见的认知偏差是：认为"用了最强的模型，质量自然有保障"。但模型决定的是能力上限，而测试体系决定的是这个能力上限能否在真实工程中被稳定达到。没有测试体系的 AI 工程，本质上是在"裸奔上线"。

另一个认知偏差是：认为"AI 测试就是多跑几轮看看输出对不对"。但 AI 系统的概率性输出决定了它必须有指标体系、评测集、回归基线和安全测试，否则无法发现隐藏的质量和安全风险。

理解 AI 技术原理是做好 AI 测试的前提，而系统化的 AI 测试方法是让 AI 能力在真实工程中稳定落地的保障。

一句话

模型决定能力上限，测试体系决定能力下限，工程化决定能力能否稳定输出。

FAQ ​

1. LLM 和 AI Agent 的区别是什么？ ​

LLM 是一个"接收文本、输出文本"的概率模型，它本身不能调用工具、不能持久化记忆、不能主动规划多步任务。AI Agent 是在 LLM 之上构建的运行时框架，它通过规划、工具调用、记忆和反思机制，让 LLM 从"回答问题"升级为"完成任务"。简单说，LLM 是引擎，Agent 是整辆车——只有引擎不能上路，还需要方向盘、变速箱和导航系统。

2. RAG 在什么场景下应该使用，什么场景下不该用？ ​

RAG 适用于需要私有知识、时效信息或领域文档的场景，例如企业内部知识问答、政策法规查询、产品手册检索。如果任务完全在模型通用能力范围内（如通用代码生成、通用翻译、文本摘要），且不依赖最新或私有信息，则不需要 RAG，引入反而增加复杂度和故障点。判断标准是：模型是否"不知道"完成任务所需的关键信息——如果不知道且信息可检索，就用 RAG；如果知道或不可检索，就不用。

3. AI 测试和传统软件测试的核心区别是什么？ ​

核心区别在于输出的确定性。传统软件是"输入 + 固定程序 = 确定输出"，测试用断言精确匹配即可；AI 系统是"输入 + 上下文 + 概率模型 = 概率性输出"，无法用精确匹配测试。因此 AI 测试需要用"输出契约"（格式、Schema、内容约束）替代精确匹配，用指标体系（准确率、召回率、忠实度）替代通过/失败二分，用评测集和回归基线替代单次验证。测试思维从"验证规则执行"转向"验证能力边界内的稳定输出"。

4. 鲁棒性测试应该从哪里入门？ ​

从 Prompt 扰动测试入门最直接。选取系统已有的测试用例，对输入做同义改写、格式变化和拼写错误扰动，对比扰动前后输出质量是否显著下降。如果下降明显，说明系统对特定表达方式过拟合。第二步是边界输入测试，覆盖空输入、超长输入和特殊字符。第三步是多轮对话的长程稳定性测试，验证上下文是否被遗忘。建议先建立一组"扰动测试集"作为基线，持续回归。

5. AI 安全测试的优先级如何排序？ ​

优先级取决于应用场景，但通用建议是：第一优先级是间接 Prompt 注入（尤其 RAG 场景），因为检索内容常被默认为可信，攻击面最大且最隐蔽；第二优先级是数据泄露，包括 PII 泄露和 System Prompt 泄露，直接影响合规和品牌；第三优先级是越狱和内容合规，已有较多通用防御手段；第四优先级是模型供应链，属于基础设施层安全。资源有限时，按"攻击可能性 × 影响严重度"排序投入。

来源 ​

  1. Anthropic 文档《Building effective agents》与 Agent 设计指南：

    https://docs.anthropic.com/en/docs/build-with-claude/agentic

  2. OpenAI 文档《Function calling / Tool use》与 GPT 模型指南：

    https://platform.openai.com/docs/guides/function-calling

  3. LangChain 文档《RAG concepts》与 Agent 架构说明：

    https://python.langchain.com/docs/concepts/rag/

  4. OWASP《LLM Top 10》AI 应用安全风险清单：

    https://owasp.org/www-project-top-10-for-large-language-model-applications/

  5. Hung et al.《Evaluating Large Language Models: A Comprehensive Survey》模型评估方法综述：

    https://arxiv.org/abs/2407.16782