我秋招发现字节跳动的岗位以 Agent 评测为主，很多！有机会我可以写一篇文章，谈谈 Agent 评测。

模型实测了一下，发现你的输入质量很关键，需要把握好使用时机。

学习的一个核心可以放在 RAG + AI Coding 驱动的智能化升级，譬如用 Codex 写一个自动化测试平台的智能体

你好，有时间可以看一下本人的文章《AI 赋能测试实践》系列，希望能给你一些启发。

不过在这里，我也简单的谈一些我的看法，借助 AI 去测试效率提升的核心在于，自动化的智能化。

因为我接触到的大厂，在 AI 提效方面，往往从自动化为切入点，辅佐以 AI，去智能化。譬如：用例自愈、智能生成测试数据、智能优化 Allure 报告。

OMG，你真是吓到我了，合着你的评论区和短视频那种心浮气躁的评论味道一样才不是 AI 味是吗？没事多读点书，微信读书欢迎你。

哎呦喂，我哪里能是你哥呀 你才是我的大哥啊

况且我的评论只是简单的总结一下你的文章，有何不可吗？我挺喜欢认真阅读一篇文章，发下我自己的理解感悟和总结，认为这样才能让我从文章中吸取到精华。老是看到你这种自以为是的评论，这就是为啥我不想评论了。你觉得我 AI 评论你的文章目的是啥呢？有没有可能我的评论习惯就是这样啊？合着非得我 mean 你的时候，你才恍然大悟，哦原来只有人类才会这么 mean，原来的 AI 呢？继续清醒去吧。

但实际上我并没有用 AI 去评论，文章我都认真读了，你这截止到2026年9月28日唯一的一个赞也是我读的。我有共鸣难道很匪夷所思吗？我前公司码上飞视觉测试引擎和你这个确实很像啊，你这条评论显得自己很清醒是吗？清醒嘉豪呗？ 我一个 05 后评论的时候以和谐为主，还能让我怎么评论？发自内心的评论都不行吗？没事咱多读点书吧

我觉得思路非常棒，与码上飞的视觉测试引擎有异曲同工之妙，核心都是去实现 “模拟人类”。

且文章中充满了工程落地的实践智慧，诸如 OCR 无法识别，通过文字来调整公式定位；以及密码输入环节，动态模拟操作。

简单总结一下，Jev 模型的本质是置信度的输出，相当于又为 Harenss 工程增加了一把尚方宝剑。

工程实践中，我们在设计 Harenss 的时候，会有许多置信度工程的开发，对于此，Jev 绝对是是最佳实践。

        关于对于这个问题，我接触到的工业实践是这样的。
        首先，在 Agent 层面，一些环节的 temperature 调低，甚至可以是 0；
        其次，可以引入重试机制，强制重试 3 次，对 3 次结果进行校验如果高度一致就输出，否则就意味着有问题，提前拦截；
        再者，可以有一些传统工程代码层面的强制校验，譬如 AST 抽象代码树校验、亦或者是静态编译校验；
        最后呢，我认为站在评测集角度，我们不仅仅可以自定义一些死的，还可以通过灰度策略去线上捞一些活的评测集。具体的，我们就是会灰度 5%，这 5% 的线上流量，我们回捞的时候，对于失败的我们是 “求贤若渴” 的，这些将会作为我们下一轮的评测数据集进行驱动开发。

这篇文章在 Agent 评测的工业化落地有真实的实践，我认为这在 Agent 收敛下，不失为未来 Agent 测试框架的工业养料。感谢分享！

对于测试的点点点工作，我认为无论 AI 再怎么发展都是必须的，毕竟做出来的产品都是面向人类的，还是需要从人类的视角去点点点的。但是从回归测试以及全面兜底的视角来看，VibeTesting 绝对是有价值的，虽然目前看来是 “理想” 的，但我依旧觉得 VibeTesting 是继 VibeCoding 后最有价值的趋势。

既然是测试之家来的，个人建议直接上测试智能体的项目，推荐从我的这篇文章开始敲起来：

AI 赋能测试实践 05：告别手工脚本，性能测试 Agent 带你玩转测试之家！

UI 自动化本质上也算是代码化的一种，selenium、playwright、agentbrowser 这些驱使的 UI 自动化，完全可以由 AI 驱动。但是关于 UI 自动化也确实存在由 AI 视觉大模型驱动的，这种极其有潜力。

        测试的每轮提效其实和整个行业的招聘动向是吻合的，功能测试->自动化测试->测试开发->AI 测试开发，这些变迁本质上就是围绕着测试的可自动化的不断进阶。因为自动化本质上代替了人工，所以能够提效，且这段变迁是不断把测试坐移的。
        因此，AI 提效的核心，持平于开发效率暴涨的核心其实就在于如何更好的让 AI 左移，以及如何让AI 更好的进行回归测试。
        而开发提效效率如此之高，关键就在于大部分的效率拔高因于代码。由此抛砖引玉，我们测试应该思考哪些测试环节可以代码化，这样代码化的测试环节才能够享受到 VibeCoding 的红利，也就是我们测试的 VibeTesting。

其实在我开发了一个智能体项目后，个人体感 token 的测试可以围绕：

1.各轮次 usage（prompt、completion、total）的 toekn 叠加是否等于可观测性，或者接近，因为大多数 agent 是支持可观测性展示 token 数的；

2.每次任务的调用是否符合预算；

3.如果是想测试可观测性在模型测的 token 计数（单一 LLM api 调用），可以采用一些具有代表性的测试样例，结合各个大模型官方的 tokenizer，并在输入测控制 max_tokens=1，直接进行 assert 断言测试。

除此之外，还有哪些角度呢？你可以提供一些思路，如果没有的话，那我认为 token 消耗值得测试的就这么多。

        不愧是啄木鸟啊！感谢指出～

        这段代码主要用来演示如何捕获 diff，触发自动化反馈，确实是只会触发在本地终端，无可争议。

        针对此，通常建议使用 Notification Hook，监听 agent_completed 事件，对接到 IM 上，文中有补充道。

落地的话，结合你们的项目与公司的方向吧。因为专门的 agent 或者是 skill 的形式，对于知识库的依赖以及架构都是不同的，前者属于专门的智能体工程范畴，后者更加灵活重点可以放在知识库的质量上。且如果现有体系属于旧工程师搭建的 GUI 的情况下，其实可以直接考虑轻量 AI 重构，那么知识库也可以作为输入的形式，符合轻量高效。

具体人力时间只能说个大概，从 4 月份开始，人力分为专项 + 专人 all in

这种情况下需要你们公司的 CLI 基础设施建设跟得上，多平台 CLI 化，对于 Agent 而言才是理想环境。

怎么开始伤春悲秋了呢，就拿前段时间大热的 DeepSeek 招聘事件，算是国内无穷趋近 AI 的业务吧。其中就有 QA 岗位：https://app.mokahr.com/social-recruitment/high-flyer/140576#/job/50733e68-4b26-4037-8b63-2ed781aa44ed

        首先针对于 PRD 和技术文档，test-runner 会基于新增功能的全新测试，其中的回归是基于 CLAUDE.md 中涉及到的 “关键风险区域” 和 “历史缺陷” 在现有的回归测试集中进行的回归。
        而且需求不断的迭代完全可以靠 AI 驱动的 case 作为回归集，并且曾经的一些 GUI 或者是已有沉淀下来的 case 早已作为养料用 AI 标准化重构了，所以早已有了一大批可以复用且适合作为回归集的 case 了。
        另外，AI 需要了解的业务逻辑都是通过沉淀的知识库的形式来解决的，我们会先让 AI 去洗现有人类沉淀的文档，并且配有专人去把控去洗，把这些都整理为知识库的形式。
        以及，AI 执行的时候，不需要 “猜” 表的关系，而是依据知识库中的明确指引去执行校验。
        AI 断言在完全的 AI 驱动的情况下，也会有断言标准知识库用于参考，并辅以 prompt 执行。

不客气，一起加油！我简单补充一下：如果 skill 需要扩容的情况下，建议拆开 skill，主 skill 包含子 skill 化，这样效果会更好一些。

嗯是这样的，不同模型用于训练的数据集、偏好对齐、架构都有差异。