这两个问题确实硬。

        轨迹每次不一样怎么测？我中篇那张断言类型表其实就是答案。轨迹断言断的不是"第 N 步必须调 tool_A"，那跟写死脚本没区别。断的是语义属性，比如 must_order 要求"必须先 Read 再 Edit"，中间插几个 GrepTool 无所谓，只关心 FileReadTool 出现在 FileEditTool 之前就行。这跟 Google Agent Quality 白皮书里的 Outside-In 思路一致：先看结果对不对，不对再打开黑箱查轨迹。LangSmith 现在也是这么干的，记录完整轨迹然后用 LLM-as-Judge 打分，我下篇的 TrajectoryCollector 做的事差不多。

        没调 tool 直接返回怎么测？这个用我中篇 7.1 的语义等价断言。Agent 没调 tool 不等于没干活，关键看答案对不对。Ragas 的 faithfulness 和 answer relevance 就是干这个的，不关心你中间调没调 tool，只看最终答案是否忠实于上下文。DeepEval 的 G-Eval 同理。所以无 tool 调用的场景，跳过轨迹层，直接在结果层做 LLM-as-Judge 就行。不过有个坑，下篇踩坑实录里提过：LLM-as-Judge 有裁判偏差，GPT-4 偏保守，Claude 偏宽松。我现在的做法是 3 个模型投票取多数（成本可控，稳定性也够）。

        通用方案的话，目前没有"装上就能用"的，但思路在收敛。核心就是三层：统一轨迹格式（把各平台的日志抽象成 reason→act→observe 循环，写个适配器翻译）、平台适配器（LangSmith 帮你做了，自研平台自己写，我下篇的 TrajectoryCollector 就是 Claude Code 的适配器）、评估策略层（轨迹断言 + LLM-as-Judge + 效率评估，跟平台无关）。AgentBench 和 MCP-AgentBench 在做类似的标准化，但目前还是学术阶段，离工程落地有距离。

        哈哈，又被你蹲到了。你这追更速度确实快 😂

        DeepEval 我之前文章里提过，但只是选型对比层面，没深入。要出实践专题的话，我自己得先踩够坑才行，现在素材还不够。手上还有几个选题排着，短期内排不上。

        这个选题我记着了，等踩完坑再来写。

        顺着你这个思路再想一层：如果现在真是 AI 泡沫期，泡沫破了之后，哪个工种 hc 反而能涨？

        我赌测试。

        泡沫期大家都在说"AI 都能写代码了还要测试干嘛"，测试被严重低估。但泡沫一破，你要面对的问题就不是"能不能写得快"了，是你根本不知道 AI 写了多少有坑的代码在里面。

        AI 吐出来的代码量一大，藏在里面的逻辑缺陷、幻觉引入的奇怪分支、压根没法靠读代码发现的问题全冒出来了。到时候团队才会意识到，验证这些代码花的成本，比手写高到不知道哪里去了。测试就不是可有可无了，你的系统靠不靠谱，最后都得从测试这道门过。

        而且 AI 系统本身的不确定性还带出来一批新活儿——模型鲁棒性怎么测、对抗样本怎么防、数据质量怎么验证，这些 AI 自己干不了，得人来。既懂测试方法论又懂模型行为的人，现在市场上就没几个。

        所以你说的"AI 没减轻测试工作反而添乱"，我太同意了。但正因如此，测试可能是少数几个泡沫破了之后 hc 会结构性反弹的方向。现在被踩得多狠，到时候弹得就多高。

        感谢，GEP 这套意图 - 路径分离加环境指纹比对的思路不错，维护的坑直接交给机制兜底，比靠人填靠谱多了。我之前搞 AI 自愈也在解决类似问题——页面一变脚本就挂，我们当时在用例层做了自动修正，定位变了能自己改回来，但路径规划那层没下这么重的手，没想着把不好使的路径直接淘汰掉。evomap 周末我去啃一啃。

        感谢解答，思路很实用，我得慢慢消化下。

        我们之前也做过类似 get_page_snapshot 的提取，但没做到 getBoundingClientRect 可见性过滤那一步，信息冗余确实大。压到 40-50 个关键元素这个数字挺有参考价值，回头我们试试按这个方向调过滤策略。

        Canvas 单独建感知通道这个做法我没想到，我们之前一直想在通用方案里硬塞 Canvas 的处理。降级链让 Agent 自己选层级，比人工定优先级灵活——我们之前脚本容易坏，很大一个原因就是定位策略写死了，环境一变就挂。

        另外想问下，Canvas 里如果有分层或者遮罩，app.stage 遍历能直接拿到层级关系吗？点击穿透和视觉遮挡的情况你们怎么处理的？

        感谢分享，读下来跟我们项目的经历一模一样。元素定位我们也是抛弃纯截图，走 DOM 提取 + 视觉辅助的路子。

        想请教个实际碰到的头疼问题：你们用无障碍树的时候，Canvas 里自定义组件嵌套深了、或者页面 DOM 层级特别多，树的稳定性还能扛住吗？定位准不准？我们在这块反复踩坑，优化了几轮还没完全搞利索。

你好，我最近一直在写一个开源项目，也是和 skill 相关的，但是偏向于 Agent。你提到的 skill 和 MCP 我深有体会，后面可以单独拎出来讲一讲，敬请期待～

        不完全一致。我们用 claude code + opus4.7 的时候，排错场景指令遵循其实还行，但推理跳步确实碰到了。问题不是模型不听话，是它在决定要不要查 Apollo 之前，脑子里已经判了个"不适用"，hooks 根本拦不住这个判断。

        所以我后来没再去加固指令，而是在输出模板里埋了一张表：每行两个格子，查了什么结果 / 没查是为什么，留空不行。它为了把表填完，就自己跑去调 Apollo 把配置项补上了。

        这和 hooks + lint 不是一个层面的事。hooks 更像在管"输出合不合规"，但我们踩的坑在"推理过程有没有走"。不是一个问题。两条路不冲突，各管各的。

        你说的 hooks 方案后续分享我等着看。另外好奇问一下，你们有没有试过在 hooks 里校验推理过程？就是不光检查最终输出格式，而是看 Agent 到底有没有实际调过某个工具。这个方向我们还没验证过。

        写得太实了，三件套的思路我认同。但我想说一个我们踩的更深的坑——Skill 写得再细，Agent 也不见得照着走。

        我们做 OE 平台用例治理，Skill 里白纸黑字写了"必须查 Apollo 灰度配置"、"必须分析 Trace"、"必须读服务端代码"。结果呢，Agent 拿到一个品类未下发的 case，扫一眼错误码就觉得自己懂了，直接出方案写"更换城市"，Apollo 和 Trace 压根没碰。

        后来我们想明白了一件事：自然语言的"必须"对 LLM 来说就是建议，不是约束。它可以遵守，也可以自己判断一句"本场景不适用"就跳过去，而且跳得心安理得。

        后来真正管用的办法，不是写更多"必须"和"禁止"，而是换了个思路——在修复档案模板里加了一张"深度分析记录表"，每行两个格子：查了什么结果 / 没查是为什么。留空不行，必须填一个。品类问题明显跟灰度相关，它写不出"不适用"的合理理由，就只能老老实实去查 Apollo，把配置项和值填进去。

        说白了，LLM 不怕违规，但它怕文档不完整。你让它交一份有空行的报告，它比你还难受。这比写一百条"禁止跳过"好使。

        有人碰到过类似的情况吗？Agent 工具有却不调，流程写了却不走。

        模型是核心这个我部分同意，没有强模型 Agent 就跑不起来。但说这套代码是"前端工程"，我觉得有点看轻了。

        传统前端干的活是确定性的——请求进去，结果出来。Claude Code 不一样，它的主循环是个 while true（query.ts 里），每轮都要决定"下一步干嘛"。光是安全检查就写了 2593 行，不是渲染用的，是防止模型一抽风给你来个 rm -rf。上下文还得动态压缩，不然 token 炸掉。还要协调多个 Agent 干活。

        你可以说模型是大脑，但 51 万行代码是让这个大脑能动手的。光聪明不行，shell 命令得加沙箱，写文件得校验权限，不然就是个只会嘴炮的 AI。说实话，安全和工程上的坑，有时候比模型不够聪明更致命。

        至于是不是故意泄露的，代码里写死了反调试检测（碰到就 process.exit(1)），还有一堆 Feature Flag。我更倾向于是管线事故，不是什么战略开源。不过你说的"借市场之手打造生态"确实有意思，Anthropic 要是真往这个方向走，那确实比藏着掖着高明。

中篇本周五上午更新，测试用例设计篇，权限绕过和 Shell 注入绕过的测试用例会比较硬核 👀

        问得好。我承认那些建议确实偏通用——Agent 当时没拿到服务器负载和慢查询日志，给的其实是基于常见模式的推断，不是针对测试之家架构的具体诊断。预期收益那些数字也是经验估算，不是实测跑出来的。

        后面接了 APM 和监控数据之后，建议会准得多。再次感谢你的质疑。

首先你的第一个问题：这些模型的显示和特定地区与网络环境强相关的，隔壁 Claude 恨不得封杀所有的中国用户，官方社区也反馈过类似的情况。

其次，你的第二个问题：官方明确说过 DeepSeek API Keys 不支持在 Settings → Models → API Keys 里直接用，用错就会报 403 之类的错误。然后官方也提及过如何添加 DeepSeek，正确方式可以参考该文档：https://forum.cursor.com/t/deepseek-models-in-cursor-through-api-key-or-add-model/147930。

几分钟确实太慢了，大概率不是 agent browser 本身的执行慢 ( Rust 优化理论上 <50ms/步)，而是冷启动 + AI 推理 + 网络加载 的多重叠加导致的。针对 “登录 - 点击菜单” 这种固定流程，必须通过封装来 bypass 掉浏览器的实时交互开销。

可以把测试用例写到 md 格式的文件中，直接作为 Prompt 的一环喂给 LLM，LLM 再调用 Agent Browser 去执行即可；

而你提到的 skill 方式本质上是针对于 LLM 的，skill = md + py，这个时候是让 LLM 去执行，而 LLM 通过 Agent Browser 去执行，你这样效率确实更高，提前封装好 skill 的形式是现在的主流写法，但是需要注意的是你 skill 包里面需要包含已经写好的 Agent Browser 脚本，其实这个时候不如前面的人类语言 md 格式便捷，前者是对人类友好，后者是对 AI 友好，后者唯一的优点就是再一次降低了 Token 的消耗，个人推荐前者。

如果是 Trae 环境问题，检查一下你 Trae 的代理和网络设置；或者是插件占用、冲突问题。
如果是 agent-browser 的问题，可能就是没有下载好，清理一下 agent-browser 的缓存，重新安装。

一般来说 Trae 有自己的一套终端，你提到的 Trae 的 “虚拟环境” 中运行 agent-browser 的时候，这个命令行工具的网络请求或进程启动或文件访问被 Trae 的环境 “拦截” 了，导致超时。
你先排查一波问题，看看是在 Trae 还是在 agent-browser：
首先，你应该尝试在 Trae 中打开外部终端，测试 agent-browser 是否可行，如可行那么就是 Trae 环境问题，否则还需要继续排查

移动端 app 领域截至目前，尚未有诸如 Agent Browser 的明星级项目，只能先尝试 Appium 的 Agent 化。

感谢补充

如果个人价值由女性决定，由他人决定，我认为作为人是失败的。

其次，被拒绝不反思自己的性魅力，反倒去诋毁一个行业，而且你热衷吐槽的测试前端后端，在明年或者后年马上要大统一了，全部变成 Agent 开发，不知道届时你是否还有借口去掩盖自我的性魅力低下以及你的情商低下。

实际上，你只要使用过 Agent 就会感觉这些内容是熟悉的，而我此篇并未打算深究，所以并非详细，只是给一些未使用过 AI 的测试人员提供的一些启蒙性建议，起到开拓思维的作用。更具体的内容，我后续有时间会分享。

我平时没事就喜欢阅读名著，可能和此有关系