企业官网建设流程全解析

《大模型岗位变了，测试工程师该补的还是算法吗？》看起来是个大话题，但真落到项目里，常常就是几个具体选择。下面我尽量按实际开发时会遇到的问题来讲。

摘要

最近跟几个做测试的朋友聊转型，发现一个挺有意思的现象——大家都在学Agent、学LangChain，简历上也堆了不少Demo项目，但真正去面试AI质量工程岗位时，聊到权限控制、日志可观测性，很多人就卡壳了。今天复盘一下这个学习路线的断点，说说从Demo到生产，测试工程师真正需要补什么。

---

目录

• 测试岗位的新变化
• 真实案例：Demo跑通的Agent，上线后权限越界
• 排查过程：问题到底出在哪
• AI辅助测试：别只学调API
• 自动化用例生成：关键在断言逻辑
• Agent测试框架：可观测性才是核心
• 代码解释
• 失败原因：业务、配置、环境三种错误怎么区分
• 适用边界：什么时候该学，什么时候先放放
• 总结

---

测试岗位的新变化

先说结论：大模型时代的测试，不是在原来基础上加几个新工具，而是整个质量保障的边界在迁移。

传统软件测试，关注的是确定性输入输出——给A，必须出B。但大模型应用不一样，输入稍微变一点，输出可能天差地别。这意味着测试工程师不能只盯着功能对不对，还得回答几个以前不常问的问题：

• 模型在不同边界条件下输出是否稳定？
• 工具调用有没有越权风险？
• 日志能不能追溯到具体的一次请求？
• 失败时，是模型问题、配置问题还是环境问题？

这几个问题，不是靠背几个测试框架就能答上来的。

我见过不少朋友转型，花大量时间学Prompt工程、学Agent框架，简历上写了"基于LangChain搭建多Agent系统"，但问到"你们怎么测这个Agent的权限边界"，基本都答不上来。这不是他们不够努力，是学习路线上有个明显的断点——Demo阶段根本遇不到这些问题。

---

真实案例：Demo跑通的Agent，上线后权限越界

去年帮一个做内部知识库的团队做质量评估，场景是这样的：

输入：一个基于RAG的问答Agent，用户可以通过自然语言查询公司内部文档，系统会调用工具读取文件内容并回答。

Demo阶段的表现：

• 用几个标准问题测试，回答准确率85%以上
• 工具调用链路完整，日志清晰
• 团队觉得"可以上线了"

上线后的问题：

• 有员工通过构造特殊Prompt，让Agent输出了不该看到的财务数据
• 日志里看不到具体是哪个工具调用了什么敏感文件
• 权限校验只在入口处做了一次，中间环节没覆盖

这个问题的核心不是模型能力不够，而是测试阶段没有覆盖到权限边界。Demo里用的测试数据都是"好人"在问"正常问题"，但真实场景里，用户可能故意试探系统边界。

---

排查过程：问题到底出在哪

这个问题排查花了大概两天，过程挺典型的：

第一步：复现问题

我们拿到了一条问题记录：用户问"帮我总结一下Q3的财务数据"，系统输出了包含具体金额的完整报表。

正常情况下，普通员工只能看到脱敏后的汇总数据，不应该看到明细。

第二步：定位调用链

看日志发现，Agent调用了两个工具：
1.search_documents——搜索文档
2.read_file——读取文件内容

问题出在第二个工具。搜索阶段做了权限过滤，但读取阶段没有再次校验当前用户是否有权限读取这份文件。

第三步：验证修复方案

我们在read_file工具里加了一层权限校验：

async def read_file(file_id: str, user_id: str) -> str: # 获取文件元数据 file_meta = await get_file_metadata(file_id) # 校验用户权限 if not await check_user_permission(user_id, file_meta): raise PermissionError(f"User {user_id} cannot access file {file_id}") # 读取文件内容 content = await load_file_content(file_id) return content

加完这个校验后，同样的问题问法，系统返回的是"您没有权限访问该文件"，而不是具体内容。

第四步：扩大测试范围

修复后，我们不是只测这一个点，而是：

• 用不同权限级别的账号重复测试
• 构造边界问题，比如"帮我看看隔壁部门的项目文档"
• 检查日志是否记录了每次权限校验的结果

这个问题排查下来，最关键的发现是：Demo阶段的测试数据太干净了，没有覆盖到权限边界场景。

---

AI辅助测试：别只学调API

很多人学AI测试，第一步是调API写测试脚本。这没错，但不够。

真正有用的AI辅助测试，应该覆盖三个层次：

第一层：用例生成

用模型根据需求描述自动生成测试用例。比如输入"用户登录功能"，模型可以输出正常登录、密码错误、账号锁定等场景。

这一层比较成熟，很多工具已经做得不错了。

第二层：用例执行与结果分析

模型执行测试用例，分析输出结果是否符合预期。难点在于"符合预期"的判断——大模型输出是非确定性的，同样的输入可能得到不同的结果。

这时候需要引入概率判断，比如"80%的情况下输出应该包含关键词X"。

第三层：边界与异常场景挖掘

这是大多数人在Demo阶段忽略的。让模型主动构造边界输入、异常输入，测试系统的鲁棒性。

比如对一个问答系统，可以让模型生成：

• 超长输入（超过token限制）
• 恶意Prompt注入
• 模糊问题
• 跨权限的问题

我见过一个团队，用AI辅助测试做了权限边界挖掘，生成了一组"试探性"问题，发现了三个潜在的数据泄露风险点。这种用例，人工测试很难想到。

---

自动化用例生成：关键在断言逻辑

自动化用例生成，很多人卡在断言怎么写。

传统测试的断言很直接：输入A，期望输出B，检查输出是否等于B。

大模型测试的断言复杂得多。比如一个客服Agent，用户问"我的订单什么时候到"，期望输出应该包含物流信息，但具体措辞可能每次都不一样。

这时候断言逻辑需要分层：

def assert_response_quality(response: str, expected_keywords: list[str]) -> dict: result = { "passed": True, "issues": [] } # 检查是否包含关键信息 for keyword in expected_keywords: if keyword.lower() not in response.lower(): result["passed"] = False result["issues"].append(f"Missing keyword: {keyword}") # 检查输出长度是否合理 if len(response) < 20: result["passed"] = False result["issues"].append("Response too short") # 检查是否包含敏感信息（如密码、身份证号） sensitive_patterns = [r'\d{6}[\d*]{4}\d{4}', r'password.*\d'] for pattern in sensitive_patterns: if re.search(pattern, response): result["passed"] = False result["issues"].append("Contains sensitive information") return result

这段代码的逻辑是：先检查关键信息是否包含，再检查输出质量，最后检查是否泄露敏感信息。

断言的核心思路是：不要期望输出完全一致，而是检查输出是否满足一组约束条件。

---

Agent测试框架：可观测性才是核心

Agent测试和普通接口测试最大的区别，在于Agent的执行过程是动态的、非线性的。

一个Agent可能：
1. 接收用户输入
2. 决定调用哪个工具
3. 获取工具返回结果
4. 决定下一步动作
5. 最终生成回答

这个过程如果缺少可观测性，出问题时根本不知道卡在哪一步。

我们团队现在做Agent测试，强制要求每个步骤都有日志记录：

import logging logger = logging.getLogger(__name__) async def agent_execute(user_input: str, context: dict) -> str: logger.info(f"Agent started. Input: {user_input}") # 步骤1：理解用户意图 intent = await parse_intent(user_input) logger.info(f"Intent parsed: {intent}") # 步骤2：决策工具调用 tools_to_call = await decide_tools(intent, context) logger.info(f"Tools to call: {tools_to_call}") # 步骤3：执行工具调用 tool_results = {} for tool in tools_to_call: result = await call_tool(tool, context) tool_results[tool.name] = result logger.info(f"Tool {tool.name} result: {result[:100]}...") # 步骤4：生成最终回答 response = await generate_response(intent, tool_results) logger.info(f"Final response generated") return response

日志里至少应该记录：

• 每一步的输入输出
• 工具调用的参数和结果
• 异常发生的具体位置

有了这些日志，排查问题才能有的放矢。否则，"Agent出错了"这句话等于没说。

---

代码解释

上面三处关键代码，分别对应权限校验、断言逻辑和Agent执行流程。下面逐段拆解实现原理，帮助理解代码背后的设计意图。

权限校验代码（read_file）

输入：file_id（文件标识符）和user_id（用户标识符），都是字符串类型。

核心逻辑：分三步走。首先通过get_file_metadata异步获取文件的元数据，包括文件的权限标签、所属部门等信息。然后用check_user_permission校验当前用户是否有权限访问这份文件——这一步是修复权限越界问题的关键。如果校验失败，直接抛出PermissionError，阻止后续操作。只有权限校验通过后，才会调用load_file_content读取文件内容。

输出：成功时返回文件内容的字符串；失败时抛出异常，由上层统一处理。

异常处理：这里用显式的PermissionError而不是静默返回空字符串，好处是调用方能明确区分"权限不足"和"文件不存在"两种情况，便于日志记录和错误分类。

断言逻辑代码（assert_response_quality）

输入：response是模型返回的文本，expected_keywords是期望包含的关键字列表。

核心逻辑：采用三层递进检查。第一层遍历关键字列表，检查响应是否包含必要信息，不区分大小写。第二层检查输出长度，过短的回答往往意味着模型没有理解问题或工具调用失败。第三层用正则表达式扫描敏感信息模式，比如身份证号、密码等。

输出：返回一个字典，包含passed（布尔值）和issues（问题列表）。这种结构方便后续集成到测试框架中，可以批量处理多个用例的结果。

异常处理：这段代码本身不做异常捕获，因为输入应该是字符串类型。如果传入非字符串，Python会自然抛出TypeError，这在测试框架中属于"输入校验失败"，应该由调用方负责。

Agent执行流程代码（agent_execute）

输入：user_input是用户的自然语言问题，context是包含用户身份、历史对话等上下文的字典。

核心逻辑：模拟Agent的典型执行路径。先解析用户意图，再根据意图和上下文决定调用哪些工具，然后依次执行工具调用并收集结果，最后用LLM生成最终回答。每一步都有对应的日志记录。

输出：返回Agent生成的最终回答字符串。

异常处理：代码中没有显式的 try-except，但这正是设计意图——让异常自然向上传播，由调用方或框架统一处理。日志记录了每一步的输入输出，这样即使发生异常，也能通过日志回溯到具体哪一步出了问题。

理解这些代码的实现原理后，再看前面的真实案例，就能明白为什么权限校验要放在read_file内部而不是入口处——因为工具调用可能有多层嵌套，入口校验无法覆盖所有路径。

---

失败原因：业务、配置、环境三种错误怎么区分

Agent出问题，首先要判断是哪类错误：

业务错误

模型理解错了用户意图，或者工具调用逻辑有bug。

特征：

• 同样的输入，有时成功有时失败
• 日志里能看到工具调用链路，但某一步的结果不符合预期

排查方法：

• 检查模型输出的中间步骤
• 用相同的输入重新执行，看是否可复现

配置错误

API Key填错了、模型参数配错了、工具路由配错了。

特征：

• 所有请求都失败，或者所有请求都返回同样的错误
• 错误信息通常比较明确，比如"Invalid API key"

排查方法：

• 检查配置文件
• 对比正常环境的配置

环境错误

网络超时、依赖服务不可用、资源不足。

特征：

• 错误是间歇性的
• 错误信息通常是超时、连接失败等

排查方法：

• 检查依赖服务的状态
• 检查网络连通性

区分这三类错误，最快的方法是看日志：

• 有明确的错误信息 → 配置错误
• 错误间歇性出现 → 环境错误
• 没有明显错误，但输出不对 → 业务错误

---

适用边界：什么时候该学，什么时候先放放

最后说说学习路线上的取舍。

现在应该先补的

1. 权限和身份认证的基本概念
不用成为安全专家，但要理解RBAC、最小权限原则、权限校验应该放在哪些环节。

2. 日志和可观测性
学会写结构化日志，理解traceId的作用，知道怎么通过日志回溯一次请求的完整链路。

3. Prompt工程的基础
不用深入研究，但要理解Prompt对输出的影响，知道怎么设计Prompt让输出更可控。

可以先放放的

1. 复杂的Agent框架
LangGraph、AutoGen这些框架很强大，但对于测试工程师来说，先理解Agent的基本模式就够了。框架可以后面再学。

2. 模型微调
除非你明确要做模型训练相关的工作，否则微调不是必须掌握的。

3. 分布式部署
这是运维和架构的范畴，测试工程师不需要深入。

什么时候不适合照搬

每个团队的Agent架构不一样，权限模型不一样，日志规范也不一样。别人的测试方案不能直接照搬，需要结合自己的系统特点调整。

比如，如果你们的系统没有用户身份体系，那权限测试的重点就不是权限越界，而是数据隔离。

---

总结

测试转大模型，最大的坑不是学不会新技术，而是在Demo阶段养成的习惯，到了生产环境会暴露问题。

Demo阶段的测试，关注的是"功能能不能跑通"。生产阶段的测试，要关注的是"权限有没有越界、日志能不能追溯、失败能不能定位"。

这三个问题，比背十个测试框架更重要。

我见过太多人花了大量时间学Agent框架、学Prompt优化，简历上写满了各种Demo项目，但面试问到"你们怎么测权限边界"、"出问题怎么排查"，基本都答不上来。

转型不是换标签，是补能力缺口。认清自己的断点在哪里，比盲目追热点更有价值。

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。