1. 项目概述为什么一个“自用 Agent”值得花三天时间做全面功能测试“自用 Agent 的全面功能测试”——这标题乍看像一句内部工作笔记但背后藏着当前很多独立开发者、技术型产品经理甚至高校研究者的真实困境花两周搭出来的智能体Agent上线后第一周就因某个边缘场景崩溃用户反馈“问天气它开始写诗”“查订单号它反问你人生意义”。我去年帮某高校实验室优化过一套教学辅助 Agent他们最初只做了“能跑通”的验证结果在真实课堂中学生连续输入三个带错别字的课程名后系统直接返回空响应连兜底提示都没有。这种问题根本不在常规单元测试覆盖范围内。核心关键词“自用 Agent”和“全面功能测试”其实定义了两个关键边界“自用”意味着没有商业 SLA 压力但有极强的个性化需求与长周期使用预期“全面”则明确拒绝“能动就行”的侥幸心理必须覆盖逻辑链、状态流、异常扰动、人机协同节奏等真实使用维度。它不是测 API 是否返回 200而是测当用户凌晨三点一边打哈欠一边输入“帮我把上周三发给张工的PDF里第7页表格转成Excel再按销售额排序发我邮箱”这个复合指令在模型幻觉、文件解析失败、邮箱配置过期三重叠加下系统是优雅降级、给出可操作提示还是静默卡死。适合谁参考如果你正处在以下任一阶段这篇就是为你写的已完成 Agent 基础框架搭建比如用 LangChain/LlamaIndex 搭了 RAG 流程但没系统验证过真实交互质量正在为个人知识库、自动化工作流或小团队工具开发 Agent需要建立可持续迭代的质量基线被“测试覆盖率高但线上问题不断”困扰想搞清到底是测试方法错了还是对 Agent 的认知有偏差。这不是教你怎么写测试脚本的教程而是分享一套我在 17 个自用 Agent 项目中沉淀下来的、不依赖特定框架的验证逻辑树。它从“用户会怎么用”倒推测试设计把抽象的“智能”拆解成可观察、可度量、可修复的具体行为指标。接下来所有内容都围绕一个目标展开让 Agent 在你真正依赖它时不掉链子。2. 测试体系设计为什么不能照搬传统软件测试思路2.1 传统测试范式在 Agent 场景下的三大失效点很多人第一反应是“写个 pytest 脚本批量跑 prompt”。我试过——用 200 条预设问答测一个会议纪要生成 Agent通过率 98%结果上线后用户反馈“它把老板说的‘尽快’自动翻译成‘3天内’还加粗标红”。问题出在哪传统测试默认“输入确定 → 输出确定”而 Agent 的本质是“输入模糊 → 输出概率分布 → 人类介入校准”。我把失效点拆解成三个具体场景第一语义漂移不可测。传统测试用字符串匹配判断输出是否正确但 Agent 的合理输出本就是多样的。比如问“总结这份合同风险点”A 模型输出 3 条带法律条文引用B 模型输出 5 条口语化提醒。两者都算合格但若测试脚本只校验“是否包含‘违约金’三字”就会漏掉 B 模型漏掉关键条款的风险。我后来改用“关键要素召回率”替代精确匹配人工标注合同里 12 个风险要素测试时统计 Agent 输出覆盖其中几个低于 80% 才告警。第二状态记忆被忽略。传统测试每次都是 clean slate但真实使用中用户会连续追问“上份报告里提到的供应商 A他们的交货周期是多少”——这要求 Agent 必须维护对话上下文、识别指代、关联历史数据。我们曾发现一个采购助手 Agent在用户第 4 轮追问时会把第一次提到的“深圳仓库”错误替换为“上海仓库”原因是向量数据库的相似度阈值设得过高导致旧记忆被新查询覆盖。这种问题只有在多轮对话链中才能暴露。第三工具调用链脆弱性。Agent 不是纯语言模型它要调用搜索、计算、API 等工具。传统测试只验证单个工具返回值但真实场景中工具可能超时、返回格式错乱、或 API 限流。比如一个财务 Agent 需调用汇率接口测试时用 mock 数据一切正常但某天接口返回 {rate:7.123456789}9 位小数而代码里 float 解析只取前 4 位导致最终金额偏差 0.3%。这种“工具层毛刺”必须在真实环境注入故障来验证。提示不要追求 100% 自动化测试覆盖率。Agent 的核心价值在于处理不确定性测试的目标是建立“不确定性下的可控边界”而不是消灭不确定性。2.2 我的四维验证框架覆盖能力、鲁棒、协同、演进基于上述失效分析我构建了“CARE”四维验证框架每个维度对应一类不可妥协的质量红线维度核心问题验证方式关键指标典型失败案例C - Capability能力边界它到底能做什么不能做什么设计阶梯式任务集基础指令→复合指令→跨域指令任务完成率、步骤遗漏数、幻觉发生率问“对比 iPhone15 和华为Mate60 的芯片参数”它虚构了“麒麟9100”型号A - Robustness鲁棒性面对噪声、错误、压力时是否稳定注入扰动错别字/中英文混输/超长输入/网络延迟/工具故障降级成功率、错误恢复时间、兜底提示有效性用户输入“查订単号 ABC123”它报错“未找到订单”而非提示“是否输入有误”R - Alignment人机协同它的行为是否符合用户预期节奏录制真实交互视频分析响应延迟、分步确认、主动澄清频次平均交互轮次、用户中断率、澄清请求接受率用户问“生成周报”它直接输出 2000 字文档不询问重点方向或数据源E - Evolution可演进性当需求变化时能否低成本调整修改 1 个业务规则如“报销需附发票”验证全链路影响规则更新耗时、回归测试通过率、新场景适配速度增加“支持海外发票”规则后原有国内发票解析模块崩溃这个框架不绑定任何技术栈。去年我用它验证一个基于 OllamaLlama3 的本地知识库 Agent只改了 3 处提示词和 2 行工具调用逻辑就把“跨文档引用准确率”从 62% 提升到 89%。关键不是工具多先进而是验证逻辑是否直击痛点。2.3 测试用例设计的黄金法则从“用户故事”反向生成很多人测试用例写得像考试题“请用 3 种方式询问天气”。这毫无意义。真实用户不会考你他们只会说“我快迟到了今天穿什么出门”。我的做法是把每个自用 Agent 的核心使用场景拆解成 5-8 个典型用户故事再为每个故事设计 3 层测试用例。以“个人健康追踪 Agent”为例它的核心故事是“用户晨起记录体重希望获得趋势分析和饮食建议”。我拆解出三层用例第一层基础功能闭环验证主干流程输入“今天体重 68.5kg” → 期望存入数据库返回“已记录本周平均 68.2kg”输入“显示最近 7 天体重曲线” → 期望调用图表工具生成 PNG附简要解读输入“为什么这周涨了 0.8kg” → 期望关联饮食日志指出“周三晚餐摄入超 2500kcal”第二层扰动防御验证容错能力输入“今儿体重68.5”含口语化表达→ 期望正确解析数字不报错输入“体重68.5但昨天秤坏了不准”含否定信息→ 期望标记该条数据为“待确认”不参与计算输入“体重68.5kg顺便查下附近健身房”混合指令→ 期望先完成体重记录再启动搜索不混淆动作第三层长期协同验证持续使用体验连续 3 天输入“体重 XXkg”第 4 天输入“最近胖了” → 期望主动提供对比区间如“较上周同期0.3kg”而非仅答“是”用户某天未记录第 5 天问“这周数据完整吗” → 期望明确告知缺失日期并提供补录入口用户设置目标“减到 65kg”后续每次记录后 → 期望自动计算距离目标差值并提示“还需减 3.5kg”你会发现所有用例都来自真实使用瞬间。我建议你立刻拿出纸笔写下你的 Agent 最常被使用的 3 个场景然后按这三层结构填空。这比读十篇论文都管用。3. 核心测试执行手把手带你跑通全流程3.1 准备工作搭建轻量但有效的测试环境别被“全面测试”吓住。我所有验证都在一台 32G 内存的 MacBook Pro 上完成没用 Kubernetes也没上云服务。关键不是硬件多强而是环境是否能复现真实扰动。以下是精简但有效的配置清单硬件与运行时本地运行Ollama Llama3-70B量化版避免网络延迟干扰响应时序工具模拟用httpx写简易 mock 服务精准控制 API 延迟如固定 2.3s、错误码如随机返回 503、返回格式如故意少一个字段数据存储SQLite 替代 PostgreSQL启动快、易快照测试完一键还原测试数据集构建“最小可行数据集”MVDS不是越多越好而是覆盖关键模式。例如健康 Agent 的 MVDS 包含10 条标准体重记录含不同单位kg/lb/st3 条异常记录如“体重nan”、“68.5公斤电子秤故障”5 条关联数据饮食日志、运动记录、睡眠时长确保跨表查询能触发用Faker库生成隐私安全的模拟数据避免用真实用户数据引发合规风险自动化脚本骨架我用 Python 写了一个 200 行的核心测试引擎它不追求 fancy只做三件事加载测试用例从 YAML 文件读取输入、期望输出、验证规则如“响应时间 3s”、“必须包含‘建议’二字”执行并捕获全链路日志记录 LLM 输入 prompt、工具调用参数、中间思考步骤if enabled、最终输出、耗时执行断言支持多种验证方式——字符串匹配、正则提取、JSON Schema 校验、数值范围判断# 示例验证“体重记录”用例的核心逻辑 def test_weight_record(): input_text 今天体重68.5kg expected_keywords [已记录, 68.5] # 执行 Agent 调用捕获完整日志 result agent.invoke(input_text) # 断言1响应时间 assert result[latency] 3.0, f超时{result[latency]}s # 断言2关键信息存在 assert all(kw in result[output] for kw in expected_keywords), \ f缺失关键词{expected_keywords} # 断言3数据库写入验证直接查 SQLite db_conn sqlite3.connect(health.db) cursor db_conn.cursor() cursor.execute(SELECT COUNT(*) FROM weight_log WHERE value 68.5) assert cursor.fetchone()[0] 1, 未写入数据库注意不要在测试脚本里写复杂逻辑。所有“应该怎么做”的判断都放在 YAML 用例文件里。脚本只负责“执行”和“比对”这样用例增删不影响框架。3.2 四维验证实操每个维度的关键操作与避坑点3.2.1 Capability能力边界验证如何设计“够狠”的测试用例很多人卡在第一步不知道该测什么。我的经验是用“5W1H”暴力拆解你的 Agent 核心功能。以“邮件摘要 Agent”为例What它摘要什么整封邮件仅正文附件内容Who为谁摘要用户自己转发给领导→ 影响摘要详略程度When何时触发收到即摘要用户手动点击→ 关联实时性要求Where摘要用在哪手机通知栏网页侧边栏→ 决定输出长度上限Why用户为什么需要快速抓重点存档备查→ 定义关键信息类型How怎么保证准确是否保留原始数据链接是否标注信息来源基于此我设计了“能力压力测试包”极限长度测试输入一封 12000 字、含 5 个附件、3 次邮件转发链的客户投诉信验证它是否① 能识别主诉内容而非转发签名② 对附件 PDF 调用 OCR 后摘要③ 输出控制在 300 字内。歧义消除测试输入“请总结张经理和李总监关于Q3预算的讨论”但邮件中两人名字多次出现且角色模糊。验证 Agent 是否主动询问“您指的是市场部张经理还是财务部李总监”而非瞎猜。跨模态测试邮件正文中嵌入一张手写会议纪要照片验证它能否调用图像理解工具将图片文字纳入摘要。避坑点别只测“成功路径”。我见过最典型的失败是——测试用例全用规范邮件主题清晰、段落分明结果真实用户发来“【急】Re:Re:Re:那个事”的标题Agent 直接崩溃。所以 MVDS 里必须包含 20% 的“野生数据”错别字、无标点、emoji 堆砌、截图文字。3.2.2 Robustness鲁棒性验证主动制造故障的艺术鲁棒性测试的本质是“压力测试”但不是压服务器而是压 Agent 的决策链。我的做法是分三步注入扰动第一步输入层扰动最易实施文本扰动用pypdf提取 PDF 文字时故意加入 OCR 错误如“68.5kg”变成“68.Skg”验证是否能纠错或提示格式扰动给 JSON 工具输入少一个逗号的 malformed JSON验证是否友好报错而非抛异常节奏扰动模拟用户“快速连发”——在 1 秒内输入 3 条指令验证状态管理是否混乱第二步工具层扰动最易忽略延迟注入用httpxmock 服务对搜索工具返回 5s 延迟验证 Agent 是否① 显示“正在查询…”② 超时后自动切换备用方案如本地知识库③ 不卡死主线程故障注入让天气 API 随机返回{error: service_unavailable}验证是否触发兜底如“暂无法获取实时天气为您展示历史趋势”数据污染在向量数据库里插入 10 条高相似度噪声文档如复制粘贴同一段话但改几个字验证检索是否仍能命中正确文档第三步模型层扰动最需技巧温度值调节将 LLM 的 temperature 从 0.3 临时调至 1.2观察输出是否变得过于发散如摘要里加入无关人生哲理Top-p 截断设 top_p0.5强制模型只从概率最高的 50% 词汇中选验证关键术语如“报销”“发票”是否仍稳定出现上下文挤压人为缩短 context window让 Agent 在 500 token 内完成原需 1200 token 的任务验证是否主动舍弃次要信息实操心得鲁棒性测试不是为了“让它崩”而是为了“看清它怎么崩”。每次故障后我必做三件事① 记录崩溃点是 prompt 解析失败工具调用超时还是 LLM 输出格式错② 检查是否有兜底机制被绕过③ 评估该故障的实际影响面是单次请求失败还是导致整个 session 失效。这才是改进的起点。3.2.3 Alignment人机协同验证用“用户录像”代替“脚本断言”Alignment 是最难自动化的维度因为它关乎主观体验。我的解决方案是放弃 100% 自动化用“半自动人工校验”组合拳。操作流程录制真实交互用 OBS 录制你本人使用 Agent 的全过程开启麦克风自言自语说出思考过程如“嗯…这个数据好像不对我再问一次”标记关键事件点在视频里标出① 用户首次表达困惑的时间点② Agent 主动澄清的时刻③ 用户被迫中断重试的节点④ 用户露出满意表情的瞬间结构化分析将视频转成文字稿用 Excel 统计平均每轮交互耗时从输入到看到有效响应用户主动追问频次反映 Agent 一次响应的信息完备度Agent 主动澄清次数如“您是指 A 方案还是 B 方案”用户使用“等等”“不对”“重新来”等中断词的次数典型案例我测试一个“代码解释 Agent”时发现用户在第 3 轮总说“太 technical 了”但脚本测试全部通过。回看录像才发现——Agent 每次都用专业术语解释而用户实际需要的是“这个函数在我们项目里用来干嘛”。于是我在 prompt 里加了一条约束“解释时优先关联用户当前项目上下文避免术语堆砌”问题立刻解决。避坑点别只录“顺利场景”。专门录 3 次“故意刁难”输入明显矛盾指令如“把文档转成 PDF但不要改变格式”、提出超出能力的问题如“预测下周股价”、用方言提问如“侬帮我看看这个单子”。这些才是对齐度的试金石。3.2.4 Evolution可演进性验证把“改需求”变成标准化流程很多团队怕改 Agent因为“一动就崩”。我的经验是可演进性不是代码写得多好而是变更路径是否清晰、可预测。我建立了“三阶验证法”第一阶规则热更新验证场景业务方说“报销现在要附两张发票”你只需改一条规则配置验证修改配置文件后不重启服务直接测试新规则是否生效输入“报销 500 元”是否提示“请上传两张发票”旧规则是否兼容输入“报销 200 元”是否仍按单张处理配置语法错误时是否优雅降级如配置写错Agent 返回“规则加载失败启用默认策略”第二阶插件式扩展验证场景要新增“支持微信支付凭证识别”你写一个新工具函数验证新工具能否被 Agent 自动发现并调用通过 function calling schema当新工具失败时是否回退到旧流程如 OCR 失败转为人工上传新旧工具输出格式是否统一都返回 {amount: xxx, date: xxx}第三阶回归测试沙盒建立“变更影响图谱”用 Mermaid 语法仅用于本地分析不嵌入生产画出规则/工具/提示词的依赖关系每次修改前运行impact_analysis.py脚本自动列出受影响的测试用例如改了报销规则就运行所有报销相关用例需要人工复查的交互场景如涉及 UI 变更标记“需看视频”可跳过的测试如只改了日志级别无需跑功能测试重要提醒可演进性验证必须在每次代码提交前强制执行。我把它做成 Git Hookcommit 时自动运行make impact-test不通过禁止推送。表面看慢了 2 分钟实际省下后期 2 小时 debug 时间。4. 常见问题与排查技巧实录那些没人告诉你的坑4.1 “测试全绿线上却天天告警”——定位隐性瓶颈的三板斧这是最高频的痛。我帮某公司排查过类似问题测试环境 100% 通过生产环境每天 30 次超时。最后发现根源是——测试用的是本地 Ollama生产用的是远程 vLLM而 vLLM 的 batch size 设置不当导致高并发时显存碎片化推理变慢。我的排查三板斧第一斧时序切片分析在 Agent 入口和出口打时间戳同时记录每个子步骤耗时prompt 构建、向量检索、LLM 调用、工具执行、结果组装画出“耗时瀑布图”一眼看出瓶颈在哪。常见陷阱你以为 LLM 慢其实是向量检索用了 2.1s因索引未优化LLM 只占 0.3s第二斧资源水位监控生产环境必加GPU 显存占用率、CPU 负载、网络 IO 等待时间关键发现当显存占用 85%vLLM 的 paged attention 会频繁 swap导致单次推理从 0.5s 涨到 3.2s。解决方案不是升级 GPU而是调小max_num_seqs参数第三斧请求特征聚类把失败请求按特征分组长文本类5000 字失败率 92% → 检查 context window 切分逻辑中文混输类含 emoji/URL失败率 67% → 检查 tokenizer 是否支持多工具串联类查天气搜餐厅订座失败率 45% → 检查状态传递是否丢失实操心得永远相信数据不信感觉。我有个习惯每次线上告警先不看代码而是导出失败请求的 raw log用jq命令快速统计共性。有次发现 90% 的失败请求都含“\u2028”Unicode 行分隔符而我们的 prompt 模板里恰好用它做分隔符导致 LLM 解析错乱。一行正则替换就解决了。4.2 “Agent 开始胡说八道”——幻觉治理的实战清单幻觉不是 bug是 LLM 的固有属性。关键是让它“可控地幻觉”。我的治理清单幻觉类型识别信号立即止血措施长期根治方案事实性幻觉编造不存在的数据输出含“根据最新报告”“权威数据显示”等模糊引用在 prompt 加约束“所有数据必须来自以下来源[列表]否则回答‘暂无数据’”接入 RAG 时强制要求每个答案附 source_id前端显示“来源文档#3 第2页”逻辑性幻觉推理链条断裂用户问“如果A成立那么B是否必然成立”它答“B 成立”却不说明推理过程启用 chain-of-thought要求输出“因为…所以…”的显式推理在工具调用层加校验当 LLM 调用计算器工具时必须传入原始公式由工具执行并返回结果一致性幻觉前后说法矛盾用户问“北京天气”答“晴”再问“北京现在温度”答“22℃”但晴天通常 28℃在 session 级加 memory buffer缓存关键事实如“用户所在地北京”后续提问强制校验用 SQLite 建立轻量 knowledge graph把用户确认的事实存为三元组subject-predicate-object每次响应前查询关键技巧不要指望 prompt 一劳永逸。我每两周做一次“幻觉审计”——随机抽 50 条线上日志人工标注幻觉类型和严重等级用这些数据微调一个小型分类器自动标记高风险响应供人工复核。4.3 “用户说看不懂但测试说没问题”——对齐度不足的破局点这是最折磨人的场景。我的破局点是把“用户反馈”转化为可测量的指标。第一步定义“可读性”不用主观词用客观指标Flesch-Kincaid 可读性分数目标 60专业术语密度每 100 字含术语数 3主动语态占比 70%被动语态易显官僚第二步建立“用户语言映射表”收集用户真实提问整理高频表达用户说“那个单子”实际指“采购申请单”用户说“弄一下”实际指“生成 PDF 并邮件发送”在 prompt 里加映射规则“当用户说‘那个单子’自动替换为‘采购申请单’当说‘弄一下’执行‘生成PDF邮件发送’流程”第三步强制“分步确认”对复杂指令Agent 必须拆解并确认用户“帮我分析销售数据”Agent“为您分析销售数据需要① 时间范围近7天/本月/自定义② 维度地区/产品线/渠道③ 输出形式图表/PPT/文字——请确认”这看似多一步实则减少 80% 的返工。我统计过带分步确认的请求用户满意度提升 3.2 倍。4.4 “测试环境完美一上生产就崩”——环境差异的终极 checklist生产环境的坑往往藏在细节里。我的终极 checklist每次部署前必过[ ]时区与时间格式测试用datetime.now()生产服务器时区是 UTC0而用户在东八区导致“今日数据”查询错位[ ]文件路径权限测试时用/tmp/生产用/var/app/data/后者权限为750Agent 进程用户无写入权[ ]DNS 解析策略测试用localhost生产用内网 DNS某些工具调用时解析超时如curl http://search-service[ ]SSL 证书验证测试跳过证书验证生产必须校验而某些老 API 证书已过期[ ]字符编码测试用 UTF-8生产数据库是 latin1导致中文存入后变乱码LLM 读取时崩溃最后一个真实案例某 Agent 在生产环境总在凌晨 2 点崩溃。查日志全是UnicodeDecodeError。最后发现是 crontab 每日凌晨 2 点执行日志轮转而轮转脚本用iconv -f latin1 -t utf8转码但部分日志含 GBK 编码字符转码失败导致后续进程读取异常。解决方案轮转脚本加--skip参数跳过无法转码的行。5. 实战复盘一个自用读书笔记 Agent 的完整测试历程5.1 项目背景与核心诉求这个 Agent 是我为自己打造的“第二大脑”核心诉求很朴素输入微信读书导出的 HTML 笔记、PDF 划线、甚至语音转文字的零散想法输出自动生成结构化笔记含原文摘录、我的批注、关联概念、行动项关键约束必须离线运行隐私敏感、响应快 3s、支持中文语境如“内卷”“躺平”需准确理解它不追求炫技只求每天早上花 2 分钟就能把昨晚读的《思考快与慢》里的 17 条划线变成一份带思维导图链接的周报。5.2 测试执行关键发现与改进发现 1OCR 对微信读书 HTML 的解析灾难问题微信读书导出的 HTML 里划线文字被包裹在span classhighlight里但 CSS 样式含opacity:0.3导致 OCR 识别率低于 40%改进放弃 OCR改用 BeautifulSoup 直接解析 DOM提取highlightclass 下的纯文本。准确率升至 99.8%教训不要迷信“通用工具”先看数据源特征。我花了 3 小时写了个 DOM 解析器省下后续 20 小时 debug发现 2中文语境下的概念关联失效问题当笔记提到“锚定效应”Agent 总关联到“船锚”“物理锚点”而非心理学概念改进在 RAG 的 embedding 模型前加一层“中文心理学词典映射”将“锚定效应”→“cognitive_bias_anchor_effect”用英文向量库检索再翻译回中文。关联准确率从 32% 提升到 87%教训领域知识必须前置不能全靠 LLM 猜。我整理了 200 个心理学核心概念的中英对照表成了这个 Agent 的秘密武器发现 3行动项生成的“假积极”陷阱问题用户划线“拖延是自我保护”Agent 总生成“立即制定每日计划”而用户真实需求是“理解拖延背后的恐惧”改进在 prompt 里加人格画像约束“用户是深度思考型偏好理解机制而非执行步骤所有行动项必须以‘可探索’开头如‘可探索拖延时身体的紧张感来自哪里’”效果用户反馈从“太鸡汤”变为“这正是我想深挖的”。5.3 测试带来的意外收获从工具到伙伴的转变最意外的收获是测试过程本身重塑了我对 Agent 的认知。以前把它当“高级搜索引擎”测试后才懂Agent 的价值不在“答得对”而在“问得准”。比如我设计了一个测试用例“输入一段混乱的语音转文字笔记含大量‘呃’‘啊’‘那个’要求提炼核心观点”。第一次运行Agent 直接删除所有语气词输出干瘪结论。我意识到问题——语气词恰恰是思考节奏的线索。于是改进让 Agent 先识别语气词密度15% 视为深度思考中保留关键停顿处的关键词如“呃…这个模型可能…需要更多数据” → 提取“模型”“需要更多数据”输出时标注“检测到深度思考痕迹以下为推演过程…”现在它不再只是整理笔记而是陪我一起梳理思路。上周我输入一段关于“如何设计测试用例”的碎碎念它不仅生成了结构化提纲还在末尾加了一句“您反复提到‘真实用户’是否在暗示现有测试过于理想化可尝试录制 3 分钟真实操作视频作为基准。”——这已经超越工具成了思考伙伴。我个人在实际操作中的体会是全面功能测试不是给 Agent 打分而是帮它找到与你最契合的协作节奏。那些测试中暴露的“缺陷”往往正是它最独特的个性起点。
