北京
“我有一个从不睡觉、从不感到无聊的队友，它每个小时都在戳我们的应用，试图把它弄坏。”这个说法并非来自科幻剧本，而是一位开发者对自己所搭建的自动化测试代理的真实描述。这个代理每隔一小时就会打开一款真实的桌面应用，像一名测试员那样到处点击，一旦看到任何不对劲的地方，就会提交一份完整的缺陷报告。
这个系统背后的故事，就发生在初创公司Zephyr Cloud旗下的“The AI Platform”产品上。这是一款面向团队协作的桌面应用，用户可以在频道内与人工智能专家一起工作。用来驱动这个应用进行测试的，是真实的登录状态、完整的桌面版本，而不是精简后的测试特供版。通过Playwright工具基于Chrome开发者工具协议（CDP，即Chrome DevTools Protocol），代理就像一名新用户一样，直接面对真正服务端渲染出来的界面，去感受“什么地方感觉不对”。
真正让这套方法变得可行的，是两个分头行动的智能代理，分别负责“狩猎”和“修复”。第一个代理负责狩猎：它会探索不同的页面路由，点开对话框，往表单里填东西，同时密切观察应用的每一个响应。一旦确定找到了一个靠谱的问题，它就会写一份完整的缺陷工单，里面包含了重现步骤和截图，最后以GitHub Issue的形式提交到代码仓库。第二个代理则专门负责修复：它会主动捡起这些工单，先在本地把缺陷复现一遍，确认无误后再打补丁，接着抓取修复前后的对比截图作为证据，最终开启一个合并请求。人类开发者仍然需要审核和合并这些改动，代理只是干完了中间那段最繁琐、最磨人的活。
起初，很多人以为“找出Bug”才是整个流程里最困难的部分，实际运行下来却发现，真正的难点是让代理对自己找到的东西保持诚实。一个过于积极的代理会把所有看起来不对劲的东西都打上Bug标签——有些功能其实本就该这样设计，有些异常是由测试数据引起的，还有一些仅仅是因为代理自己也拿不准。这种“噪音”比完全静默更可怕，因为它会让人逐渐丧失对系统的信任。
因此，狩猎代理在找到问题之后，必须先完成一套严格的分类。每一处可疑点都会被划入下面某一类：第一类“真正的Bug”，也就是确实坏掉了的那部分；第二类“符合预期但体验不佳”，功能没问题，但交互上容易让人困惑；第三类“环境或数据问题”，根源在于测试环境而非产品本身；第四类“测试盲区”，属于目前测试覆盖不到的地方，线上其实没坏；第五类“存疑”，代理自己也无法给出明确结论。与之搭配的，还有一个信心等级体系：高信心意味着代理在本次运行中已经用清晰的步骤复现了问题；中等信心代表大概率成立，但有一处细节还不完全确定；低信心则只是看起来可疑，还远没到可以提单的程度。
这套系统有一条让它变得可信的硬规矩：只有当某个产品Bug属于高信心、且可稳定复现时，代理才被允许正式提交工单。对于其余所有情况，它都选择按住不报。开发者的态度很明确——“我宁愿它说‘我无法确认这个问题’，也不想它随便猜测、喊狼来了。”正是这种克制，让自动提交的每一条缺陷都保持了极高的排查价值。
截至目前，狩猎代理已经登记下好几起真实的问题，这些Bug都很安静、很低调，恰恰是那种你在忙着追赶下一个功能时最容易漏掉的东西。比如某个聊天频道会永远卡在“正在获取消息历史”的状态，没有报错，也没有超时提示，用户就这么被晾在那儿；又比如一个用于保存GitHub令牌的字段，明明看上去保存成功了，实际上因为令牌格式不对，系统悄悄拒绝了它，却始终不给用户任何提醒；还有一个设置页面，打开后加载出来的竟然是首页内容。
这些不起眼的小毛病，正是两个无眠代理每晚在真实应用里四处游荡时，一点一点挖出来的。它们不管什么时候，都在用和普通用户一模一样的路径去触碰产品，看到了那些开发者在本地模拟环境里从未见过的异常界面组合。而修复代理紧随其后的补丁动作，又把这些缺陷变成了一个个带着截图对比的合并请求，安静地等着人类同事第二天早上把它合进主分支。对于这个团队来说，最兴奋的并不是拥有了某个会写代码的AI，而是把测试与修复这两件最消耗耐心的体力活，交到两个既不会累、也不会偷懒的“队友”手里。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
