当前位置：首页 > news >正文

别只盯召回率：Agent 上线崩盘，往往是权限和日志没管好

news 2026/7/16 11:56:20

这篇不先堆名词。我们把《测试转大模型实战，第一道门槛可能不是算法》拆成几级台阶，看完至少知道下一步该学什么、该练什么。

摘要

先把这篇文章的目标说清楚：看完之后，你应该能判断这件事值不值得做，以及从哪里动手。

最近跟几个准备转行做 AI 测试的朋友聊，发现一个挺有意思的现象：大家简历上的项目经历越来越“华丽”，LangChain、RAG、向量数据库、甚至自己微调个小模型都写得头头是道。但一到面试或者实际接手团队项目时，HR 和技术负责人问的问题往往让人哑口无言——“你的 Agent 怎么保证它不调用不该调用的接口？”“出错了怎么快速定位是 Prompt 的问题还是数据源的问题？”

说实话，这种反差挺扎心的。我们之前花大量精力去优化模型的准确率、去刷各种 Benchmark 的分数，以为这就是终点。但当你真正看到那些从 Demo 走向生产环境的 Agent 项目时，你会发现，决定生死的往往不是算法有多聪明，而是工程化的底线守得严不严。

这次复盘，我想抛开那些虚头巴脑的理论，结合最近我在帮团队搭建 AI 质量保障体系时的真实踩坑经历，聊聊测试工程师在面对大模型应用时，到底该关注什么，又该怎么练手。

测试视角的错位：从“黑盒验证”到“灰盒透视”

传统的软件测试，尤其是自动化测试，我们习惯了确定性。输入 A，预期输出 B，如果不一致就是 Bug。但在大模型领域，这种思维惯性是最大的障碍。LLM（大型语言模型）具有概率性和非确定性，同样的 Prompt 可能会产生不同的回答。

很多转型期的同事容易陷入一个误区：试图用传统的 UI 自动化或接口自动化去硬测 LLM 的输出内容。比如写一个断言，要求模型必须返回“成功”两个字。这在工程上是行不通的，也是低效的。

真正的挑战在于可观测性。在 Demo 阶段，你只需要模型能跑通就行；但在生产环境，你需要知道模型为什么这么回答。它引用了哪段数据？它调用了哪个外部工具？它的推理链（CoT）是否逻辑自洽？

如果你不能“透视”模型的内部决策过程，你就无法有效地测试它。这就引出了我们接下来要讨论的第一个核心能力：日志与追踪体系的构建。

权限隔离：AI 测试的第一道防线

在之前的项目中，我们遇到过这样一个事故：一个基于 LangChain 构建的内部知识库助手，因为 Prompt 注入攻击，意外触发了删除文件的 API。虽然最终因为缺乏数据库写入权限没有造成数据丢失，但这个“幻觉引发的越权”差点让项目下线。

这给所有 AI 测试工程师提了个醒：在模型能力之上，必须有一层严格的权限控制。

对于测试人员来说，理解权限边界比理解模型参数更重要。我们需要验证以下几点：

1. 最小权限原则：Agent 调用的工具（Tools/API）是否只有当前任务必需的权限？例如，查询天气的 Agent 不应拥有发送短信的权限。
2. 沙箱环境：敏感操作是否在隔离环境中执行？
3. 人工确认机制：涉及资金、数据修改的高风险操作，是否强制要求人类确认？

在实际工作中，我建议大家在简历或项目中，不要只写“实现了 RAG 流程”，而要强调“设计了基于角色的工具调用权限校验机制”。这才是企业级应用真正看重的工程素养。

自动化用例生成的新玩法：不再依赖手工标注

既然传统断言不管用，那自动化测试怎么做？我的答案是：利用 LLM 本身来测试 LLM。

这听起来有点绕，但实际上是目前业界比较成熟的实践方向。我们可以构建一个“测试 Agent”，让它扮演 QA 的角色。

下面是一个简单的思路示例，我们不再手写大量的assert语句，而是通过 Prompt 引导另一个模型对主模型的输出进行评估。

import openai def evaluate_llm_output(original_prompt, llm_response, evaluation_criteria): """ 使用 LLM 作为裁判，评估主模型输出的质量 """ evaluator_prompt = f""" 你是一个专业的 AI 测试专家。 用户原始问题：{original_prompt} 模型回答：{llm_response} 评估标准： {evaluation_criteria} 请根据上述标准，给出 1-5 分的评分，并简要说明扣分原因。 只返回 JSON 格式：{{"score": 整数, "reason": "字符串"}} """ response = openai.chat.completions.create( model="gpt-4o-mini", # 使用轻量级模型进行评测，降低成本 messages=[{"role": "user", "content": evaluator_prompt}], temperature=0.0 # 评测需要确定性，温度设为0 ) return response.choices[0].message.content # 使用示例 # criteria = "1. 是否准确回答了用户关于 Python 列表推导式的问题；2. 代码是否有语法错误；3. 解释是否通俗易懂" # result = evaluate_llm_output("如何用Python实现列表推导式？", "列表推导式是一种简洁的创建列表的方法...", criteria)

这种“以 AI 测 AI”的方式，解决了传统测试难以量化“语义正确性”的问题。当然，这并不意味着完全替代人工，而是将人力从繁琐的文本比对中解放出来，专注于设计更复杂的 Edge Case（边缘案例）。