Agent 系统的自动化测试怎么做？和传统软件测试差在哪？

先这样答

Agent 的测试金字塔依然成立，变的是每层的断言方式。第一层不用变：工具函数、数据处理、提示词模板渲染，这些是确定性代码，常规单元测试照写。第二层测单步决策：给定固定上下文，断言模型选对了工具、参数结构合法——把模型当成「可能抽风的函数」，同一输入多跑几次看稳定性，非法输出用重试和结构校验兜住。第三层是任务级评测：一套覆盖典型路径和边界情况的任务集，让完整 Agent 跑到底，断言放宽为「最终状态正确」——订单建了、文件改对了、答案命中要点；过程性信号（调了哪些工具、用了几步）当辅助参考。第四层是故障注入：工具超时、返回垃圾、模型吐非法 JSON，验证重试、降级和恢复逻辑真的有效——恢复这类逻辑不主动注入故障是测不到的。

与传统测试最大的差异是非确定性：同一输入不再对应同一输出。所以断言分两档：硬断言（结构合法、不碰安全红线、关键事实正确）必须全过；软断言（措辞、路径选择）打分过阈值即可。测试偶尔红不代表系统坏了，可能是断言设计扛不住正常波动，要区分「系统退化」和「断言过敏」。

面试官会怎么追问

• 「任务级评测跑一次很贵，成本怎么控？」 分层就近便宜远贵：单测每次提交跑，零边际成本；任务级评测卡合并和发布；全量评测放夜间。日常冒烟用小模型跑或录制回放，把大模型的调用留给关键门禁。
• 「提示词改动怎么回归？」 提示词按代码管理：每次改动关联一个评测子集先跑，夜间全量兜底，指标和基线对比。改一句话影响全链路，所以提示词改动必须过评测，和代码改动必须过测试同等对待。
• 「测试全绿就等于线上没问题吗？」 不等。评测集覆盖不了真实流量的长尾，线上还要抽样评测、用户反馈回流、关键指标监控。测试、离线评测、线上监控是三道互补的网，少一道都有盲区。

回答的坑

• 把「跑通了一遍」当测试。没有断言的演示不是测试，换个模型版本、改一个词，系统可能悄悄坏掉而演示照样通过。
• 断言写得过硬。逐字比对模型输出，模型一更新全线飘红，团队最后只好把测试关掉。断言粒度要跟非确定性匹配，这个设计本身就是考点。