QA 的演进：现在是截图，下一步是 API，那再下一步是什么？如果 agent 能通过 API、MCP 或新形式拿到应用的 DOM，QA 会不会变得极其高效？文本是不是最好的表示形式？

截图是给人看的界面，API 是给机器用的接口，agent 出现后接 API 的门槛被降低，交互也更有效⁠1。但真正的下一步不是再找一个更细的接口，而是把验证这件事交给 agent：它可以定期跑、在每次 pull request 时跑，用工具去点前端看是否真的 work，或写测试核对原来的意图和输入输出是否匹配⁠3。它还会把做了什么、怎么想的、测了什么整理给你看，人不必再自己 checkout 代码去点一遍⁠3。所以“最好”的一层是验证主体从人变成 agent，接口只是手段。

如果 agent 能拿到应用的 DOM，通过 API、MCP 或某种新形式访问，它确实能比截图更精确地知道界面状态，少掉“看图猜结构”的损耗。但效率提升不来自 DOM 本身，而来自它能否据此自己判断、多步决策、自己迭代⁠3。反过来，如果只是把 DOM 喂给一个仍需人逐步指挥的流程，省下的只是定位元素的时间。另一个相关判断是：与其写程序机械地调 API，不如用自然语言把任务交给 agent，让它自己处理“已有摘要就跳过、格式不对就调整”这类边角情况，确定性的重心从过程移到结果⁠2。DOM 访问属于同一逻辑：给 agent 更多可操作的信息，让它自己决定怎么测。

关于“文本是不是最好的表示”，材料没有直接回答，但给了一个可迁移的线索：给 AI 的东西可以是为它设计的知识系统，甚至是一个供它搜索的 MCP 工具，在它工作时直接注入上下文⁠5。这说明表示形式的选择标准是“agent 能不能据此可靠地行动”，而不是“是不是文本”。对 QA 来说，DOM 是结构化状态，截图是像素，测试脚本是可执行断言，三者各自适合不同判断；哪种最好取决于你要验证的是视觉呈现、交互行为还是数据正确性。