IronBee 造出不用大模型的浏览器智能体,自己核对订单
IronBee AI 称,其 Express 浏览器智能体在一家演示网店里用 6.7 秒买下一台 iPhone 15 Pro,花费 0.00054 美元。第二次运行时,它发现结账页面显示成功,而页面背后的订单其实已经失败。公司于 10 月 5 日发布了这篇工程文章。
演示很小,也很具体。根据 IronBee 自己的博客文章,Express 登录、加入商品、填写地址和银行卡,然后一直等到订单页面显示 COMPLETED:九个动作,6.7 秒。
背后的决策引擎叫 Jev,是 TypeSafe 的一个模型,用来回答带选项的选择题。IronBee 说整个流程里没有大模型。每一步都是对 Jev 的一次调用,返回它选中的选项、每个选项的概率和一个置信度分数。不生成文本,也不读取截图。从土耳其发起一次决策约需 300 毫秒,其中大部分花在到服务器的往返上。成本数字才是公司真正在卖的东西。输入每百万 token 收费 0.042 美元,输出免费。IronBee 说,这让一次完整重放的结账(包含判定和复核)降到 0.00054 美元。答案只能是 harness 发来的列表里的一个键,所以模型输出永远不会变成一个选择器、一个坐标或一段脚本。一次运行只能点击屏幕上已经存在的东西。
这比别处上线的截图驱动智能体押得更窄。值得观察的是,遇到不提供干净编号控件列表的页面,这套做法还能不能撑住。
让这套设计站住脚的那次失败
速度很容易拍成视频。文章里更有用的那次运行,是一次出错的结账。页面显示“Order placed successfully!”,订单 API 返回 200,但响应里的负载写着 FAILED。IronBee 的智能体用 7.57 秒、8 个动作和 9 次决策把这次运行标记为失败。它先指向 API 响应,再指向后端日志那一行:notification-service,Order #131 Could Not Be Processed,Reason: Insufficient inventory。
页面说“Order placed successfully!”。订单 API 回了 200,可里面的订单写着 FAILED。
文章说,这些判断没有一条是人为写下的断言。判定这一步本身就是一个 Jev 问题:目标是否成立,有哪些证据支持。文中所有数字都来自 IronBee 自己在 2026 年 9 月 21 日至 10 月 1 日之间的运行。第一个版本在 9 月 24 日跑通,登录并把商品加入购物车 3 次全部成功,耗时 2.85 到 3.05 秒。
这份谨慎有道理,因为本周发布的大部分浏览器智能体材料都不是中立基准。xhluca 的一份 400 行参考实现走的是相反的架构。它用 394 行 Python 给 Gemini 3.8 Flash 提供截图和浏览器控件,其中还包括一段录下来的运行:预订一场工作坊并核对确认信息。两种做法都声称会检查结果,但只有一种按截图付费。
验证是本周的主题
同样的争论也出现在编程工具里。Dotpals 是 Claude Code、Codex 和 Cursor 的开源桌面伴侣,它从命令输出里读测试结果,而不是听智能体自己说。测试失败时它把智能体打回去,也能抓出为了通过而临时改过的测试。Ian Maurer 的文章提到,OpenClaw 团队删掉了自己大约 40 万行测试,覆盖率几乎没变。文章主张写由外而内的测试,用测试描述用户行为,而不是堆越来越多的单元测试。Threadnote 在五个公开仓库上做了一次小型配对研究。它报告说,在有存档交接的情况下,每次通过验证的完成所耗生命周期 token 减少 65.62%,时间减少 46.14%,五个任务全部通过验证,而只靠文件时是五个里通过四个。公司明确说明,这是它在 build 5.1.0-beta.2 上的单模型研究,不是独立评估。
它对问题的说法很直接:“Done”是智能体能生成的一句话,不是测试结果。
持久性也开始受到关注。Pi Durable 是 Arendelle 随 Pi 1.0 一起发布的实验性框架,它给对话做检查点,好让新进程能接着跑。只有当工具声明可以安全重放时,它才重放被中断的工具调用,因为把一笔付款发两遍和重跑一次搜索不是一回事。Ostoyae 是一个面向编程智能体的图执行器,每个任务都在自己的 git worktree 里运行。只有在全新检出的代码上跑通检查命令,它才算这项工作完成。
企业为什么卡住
演示和上线之间的差距是可以量出来的。一份MIT Technology Review Insights 调查访问了 300 位数据和技术高管,发现平均只有约 34% 的企业智能体项目进入生产。这份调查由其定制内容部门制作,而非编辑团队。在扩大智能体对知识的访问时,被提及最多的障碍是数据碎片化,占 55%。
研究一侧,一篇10 月 1 日修订的论文提出了 StructMemEval,用来衡量智能体是否会组织长期记忆,而不只是回忆事实。作者报告说,检索增强的大模型在交易账本和待办清单这类任务上表现吃力。他们还补充,现代模型如果不加提示,并不总能识别出所需的结构。
这些都不意味着 6.7 秒的结账是最难的部分。IronBee 自己的文章大半篇幅写的是出问题的地方。它的核心主张很窄:从列表里选,检查选中的项,用证据而不是页面的成功横幅来判定这次运行。这比一个会读网页的智能体承诺得更少,也更容易测试。
资料来源
9- 01How we built a browser agent with Jev instead of an LLM | IronBee AIEN
- 02Mini-web-agent: Web agents from scratch in under 400 linesEN
- 03Dotpals - Catches agents that edit tests to pass using JEVEN
- 04Red, Green, Remove: Outside-In Tests for Coding AgentsEN
- 05How much do coding agents spend rediscovering a codebase?EN
- 06Pi Durable: What It Is and Why It Matters for Agent AppsEN
- 07A graph runner for coding agentsEN
- 08Connecting AI agents to enterprise knowledge | MIT Technology ReviewEN
- 09Evaluating Memory Structure in LLM AgentsEN
本文所有数字与引语均来自下列来源,未添加来源之外的内容。
本内容由编辑部在人工智能辅助下制作完成。
评论
0- 还没有评论——来说两句吧。