跳到正文
世界时间EU--:--UK--:--USA--:--CN--:--PLDEFRIT中文EN

关于人工智能与技术的门户事件 · 分析 · 访谈 · 技术背景

搜索
直播
›

IronBee 造出不用大模型的浏览器智能体,自己核对订单

IronBee AI 称,其 Express 浏览器智能体在一家演示网店里用 6.7 秒买下一台 iPhone 15 Pro,花费 0.00054 美元。第二次运行时,它发现结账页面显示成功,而页面背后的订单其实已经失败。公司于 10 月 5 日发布了这篇工程文章。

人工智能与模型解释王雅琴发布: 2026年10月5日5 分钟阅读资料来源 9
IronBee 造出不用大模型的浏览器智能体,自己核对订单

演示很小,也很具体。根据 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 自己的文章大半篇幅写的是出问题的地方。它的核心主张很窄:从列表里选,检查选中的项,用证据而不是页面的成功横幅来判定这次运行。这比一个会读网页的智能体承诺得更少,也更容易测试。

评论 0

资料来源

9
  1. 01How we built a browser agent with Jev instead of an LLM | IronBee AIEN
  2. 02Mini-web-agent: Web agents from scratch in under 400 linesEN
  3. 03Dotpals - Catches agents that edit tests to pass using JEVEN
  4. 04Red, Green, Remove: Outside-In Tests for Coding AgentsEN
  5. 05How much do coding agents spend rediscovering a codebase?EN
  6. 06Pi Durable: What It Is and Why It Matters for Agent AppsEN
  7. 07A graph runner for coding agentsEN
  8. 08Connecting AI agents to enterprise knowledge | MIT Technology ReviewEN
  9. 09Evaluating Memory Structure in LLM AgentsEN

本文所有数字与引语均来自下列来源,未添加来源之外的内容。

本内容由编辑部在人工智能辅助下制作完成。

王雅琴

王雅琴

人工智能、模型与技术

王雅琴负责FLASH24的人工智能、模型与技术报道,覆盖科技、人工智能与模型、媒体与互联网领域。她习惯直接查阅技术文档、模型卡与官方博客,而非依赖新闻稿,对未经核实的参数和跑分数据一概不放行。每篇报道前,她会逐项核对基准测试结果,对照论文原文与开源代码,确认版本号、数据集和评测条件是否一致。她常联系开发者与研究人员求证细节,也盯着各大厂商的发布会和论文截稿日期,横向比较同类模型的实际表现。私下她自建服务、折腾家庭网络,这让她对部署成本和真实算力需求有直观判断。她的原则是:没有可复现来源的数字,不写进稿子。

编辑部 →

评论

0
  1. 还没有评论——来说两句吧。

写评论

评论公开展示。我们不发布辱骂、垃圾信息和广告内容。