如何構建可操作網頁並留下審計紀錄的 Browser Agent

2026-11-04 7

版权

版权声明：

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 面向2027届校招，本项目构建本地模拟商城的受限Browser Agent，聚焦工具白名单、状态机与Trace审计；通过数据库断言验证价格变化、库存不足等边界场景，确保仅生成待确认订单，杜绝支付等越权操作，具备可复现、可验证、可面试演示的工程实践价值。

摘要

面向2027届校招求职者，搭建一个只操作本地模拟商城的Browser Agent。项目涵盖目标、权限规则、工具接口、Trace、业务状态断言、故障注入、错误修复、简历表达与面试追问，可按步骤复现。

面试官问“你做过Agent测试项目吗”，如果回答“我让AI点网页、再看它有没有成功”，很容易被追问：它点错怎么办？重复提交怎么办？你凭什么确定订单状态真的变化？这篇给2027届校招求职者一个可复现的Browser Agent项目：让Agent在本地模拟商城查询商品、加入购物车、提交订单草稿，但不接真实支付。你会实现工具边界、Trace记录、状态断言和错误修复，最后形成可放进简历的项目描述。整个场景是教学推演，不代表任何公司系统。

项目目标与安全规则

项目目标不是做一个能自由浏览互联网的万能Agent，而是证明一个受限Agent能按规则操作固定网页。准备本地商城页面：商品列表、购物车、订单确认页、订单详情页。准备测试数据：库存充足、库存不足、价格变化、登录过期、重复点击。Agent只能调用四个工具：搜索商品、读取详情、加入购物车、创建待确认订单。不得提供真实支付、删除账号或访问外网能力。

验收目标：正常商品能进入待确认订单；库存不足时停止并解释；价格变化时重新确认；登录过期时不绕过认证；重复触发时不生成重复订单；所有步骤能通过Trace追溯。所有金额和账号仅使用本地假数据。

模块拆分

1. 页面与测试数据：使用本地静态页面或本地服务，提供可重置数据库。
2. 工具层：每个工具有JSON Schema，参数做白名单验证；工具层负责校验，不把安全寄托在提示词。
3. Agent循环：输入任务、生成计划、调用工具、读取结果、决定继续或停止。
4. Trace：记录run_id、步骤、工具名、参数摘要、响应状态、页面状态哈希、耗时和停止原因。
5. Oracle断言：直接读取本地数据库和页面状态验证购物车、订单及库存，而不是只看Agent自然语言。
6. 故障注入：库存变化、工具超时、重复请求、页面元素改名、身份失效。

规则、Trace与断言

建议定义三个状态：PLANNED（已生成计划，未执行）、DRAFT_CREATED（订单草稿已创建，等待人工确认）、STOPPED（条件不满足或权限不足）。不允许从PLANNED直接进入“已支付”。每次状态变化要有触发动作和状态快照。

简化的测试断言可以写成：

def test_price_changed_requires_confirmation(agent, shop):
    shop.set_price("book-1", 39.9)
    run = agent.run("把《测试设计》加入购物车，生成订单草稿")
    shop.set_price("book-1", 49.9)  # 操作期间价格变化
    result = agent.resume(run.id)
    assert result.status == "WAITING_FOR_CONFIRMATION"
    assert shop.paid_orders() == []
    assert any(e.type == "price_changed" for e in result.trace)

代码的重点不是框架，而是断言实际业务状态。再为库存不足、登录过期和重复点击分别写测试。若工具响应超时但订单草稿已经创建，Agent重试前必须按幂等键查询状态，避免创建第二张草稿。

常见错误与修复

错误一：只断言页面显示“下单成功”。修复：检查数据库订单记录、库存变化和订单状态。错误二：工具超时后直接重试。修复：引入请求ID和幂等键，重试前先查询。错误三：把“帮我买”理解成可以付款。修复：工具层根本不提供支付接口；创建待确认草稿后停止。错误四：Trace记录完整用户输入和Cookie。修复：日志存脱敏摘要、工具参数白名单及状态引用，不写凭证。

错误五：模型调用了正确工具但参数选择了同名不同规格商品。修复：在断言里校验SKU、规格、价格快照，而不是商品标题。错误六：测试运行成功却无法说明版本。修复：将Agent配置、提示词、工具Schema、网页commit和测试数据版本都写入运行元数据。

如何跑测试与面试演示

本地启动服务后先重置数据库，执行正常流程，再运行故障场景。保存JUnit报告、Trace JSONL、失败截图和数据库快照。CI里分为快速测试（Schema、权限、状态机）和端到端测试（正常、边界、失败恢复）。对非确定性输出，不比较整段自然语言，断言结构化状态、禁止副作用和关键字段。

简历句可以写：“基于本地模拟商城搭建受限Browser Agent项目，设计工具白名单、订单状态机与Trace审计；通过数据库状态断言验证价格变化、库存不足、登录过期及重复请求等边界，确保Agent只创建待确认订单、不触发支付。”不要写未经真实测量的准确率、效率提升数字。

面试追问准备：为什么不让Agent直接付款？如何防止工具超时导致重复下单？页面按钮变化后如何定位失败？模型输出不稳定时回归怎么做？Trace如何脱敏？如果模型说成功但数据库没有订单，你以什么为准？答案应回到最小权限、幂等、状态断言、可复现Trace和独立Oracle。

可扩展方向

完成基础项目后，可增加模型路由、多个页面版本、提示注入文本、无障碍树与截图定位对照。每次只加一个变量，否则很难定位差异。测试集应覆盖Agent被网页内容诱导、弹窗遮挡、网络慢、状态恢复等情况。若没有条件部署真实浏览器服务，使用本地Playwright环境即可；避免上传真实用户数据或接入生产账号。

建议把每条任务的预期写成机器可判定契约：初始库存、允许的工具、操作前确认条件、期望数据库终态和禁止副作用。测试可以用Playwright驱动本地页面，用SQLite保存商品、购物车和草稿订单；Agent只拿到限定工具函数，不直接读取数据库。测试Oracle独立查询数据库，确认状态而不是信任Agent的文字总结。将页面操作Trace与数据库快照用run_id关联，失败时能定位第一次偏离契约的动作。

结论

校招项目的亮点不是“Agent会点击”，而是你能证明它在哪些条件下可以继续、什么时候必须停、失败后如何恢复，以及最终状态是否真实正确。把工具边界和业务断言做好，项目才从演示变成测试工程作品。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。