普通API测试和智能体测试，差在哪一步？

有作者提到，自己曾花数周编写模拟Salesforce端点，只为测试一个智能体流程，并认为多数API mock适合测HTTP请求，但对测试AI智能体不够有用。这个痛点值得求职者注意：面试时能说清差异，比背工具名更有用。

普通API测试通常关注单次请求与响应：给定输入，断言状态码和字段。智能体测试往往跨多步，前一步修改的内容会影响后续决策。如果mock不保留状态，智能体在第二步读到的仍是初始数据，测试就退化成演示。

面试被问到差异时，可以这样组织：普通mock验证接口契约，智能体测试还要验证状态在请求间是否延续、多步行为是否可复现。

怎么设计一个可重复、可评分的智能体测试场景？

素材提到，State Machines的本地企业API副本在请求间保留状态，使智能体可以修改内容并在同一工作流后续步骤中依赖新状态；其环境设计为每次从同一场景开始，使多步行为可重复到足以评分，而不仅是演示。

这里有两个可迁移的思路。第一，固定初始场景：每次测试从同一份数据开始，避免上次运行残留影响结果。第二，让状态可追踪：智能体改了哪条记录、后续步骤是否读到新值，都要能断言。

假设一个模拟场景：智能体先修改订单地址，再查询物流。如果环境不保留状态，第二步查到的还是旧地址，测试就无法判断它是否真的完成了任务。

需要说明的是，State Machines是否真实存在、是否已发布或可公开使用，素材并未确认。面试中不要把它当作自己用过的工具，可以把它当作一种设计思路来讨论。

面试被问智能体测试经验，怎么讲才不空？

用三个点组织回答：状态保持、可重复场景、评分而非演示。然后诚实区分自己实际做过的部分。

如果只做过普通接口测试，可以说：我目前主要验证单次请求，但理解智能体测试需要跨请求保留状态，我会先确认目标岗位的测试环境是否支持状态回放，再设计从同一场景开始的用例。

读岗位描述时，还要确认：测试对象是单轮调用还是多步工作流？环境能否重置到固定初始状态？评分标准是人工判断还是自动断言？这些问题比“我会用某工具”更能体现判断力。

一个小建议：挑一个你熟悉的多步流程，用纸笔画出状态变化和断言点，面试时讲这个思路，比罗列工具名更实在。