本地27B AI Agent自主完成亚马逊购物：一次跑通全流程

一次真实世界的本地Agent实验

一位开发者在Reddit上分享了一个颇具启发性的实验：家里的A4纸用完了，他没有自己动手下单，而是把亚马逊账户交给了一个完全在本地运行的AI Agent，只下达了一条指令——「在亚马逊搜索A4纸，找到价格划算的商品并购买，尽量自己处理所有环节」。结果是，这个Agent在一次运行中完整地完成了任务。

这个实验的价值不在于「买了一包纸」，而在于它验证了一条正在被越来越多人关注的技术路线：用本地运行的大模型驱动浏览器Agent，让推理、决策和工具执行几乎全部留在自己的机器上。

技术栈拆解：几乎全流程本地化

从作者披露的配置来看，这套系统由三部分组成：

• 模型：本地运行的 Qwen3 27B（原文写作 Qwen3.8 27B）
• 运行时：TensorSharp，一个开源的本地 LLM 推理引擎 + Agent 运行时
• 工具能力：通过 Playwright 技能实现浏览器交互

最值得关注的一点是Agent循环的本地化程度。作者强调，推理、reasoning、Agent状态管理、代码生成和工具执行全部在本地完成，唯一离开机器的只有与亚马逊本身的网络交互。换句话说，模型的「大脑」和「决策过程」不经过任何云端API，用户的操作意图和中间状态不会外泄给第三方模型服务商。

对于隐私敏感的场景——比如涉及个人账户、支付信息的操作——这种架构天然具备优势。你不需要把账户凭证或购物意图交给远程模型，模型只是在你自己的硬件上「思考」，然后指挥浏览器去点击。

Qwen3 27B是阿里巴巴通义千问^广告团队发布的开源大语言模型系列之一，27B指参数量约为270亿。参数量决定了模型的「体量」——参数越多，模型通常具备更强的推理和指令跟随能力，但同时对本地硬件的要求也越高。运行27B级别的模型，通常需要至少24GB显存的消费级GPU（如RTX 3090/4090）或具备统一内存架构的高端Mac（如M2/M3 Ultra）。Qwen3系列的特点是在多语言理解、代码生成和工具调用方面表现出色，这使其成为需要生成Playwright代码并控制浏览器的Agent任务的合适选择。Playwright本身是微软开发的开源浏览器自动化框架，支持通过Python、JavaScript等语言编写脚本来控制Chromium、Firefox、WebKit等浏览器，完成点击、填表、截图、页面导航等操作——正是驱动「浏览器Agent」的核心工具层。

人类只介入了两次

在整个任务过程中，作者只手动干预了两次：

1. 登录亚马逊账户——出于安全考虑，登录环节没有交给Agent
2. 确认最终购买——在下单前做人工审批

除此之外的所有环节都由Agent自主完成：搜索关键词、浏览商品列表、比较不同产品和价格、在亚马逊页面间导航、决定买哪一款，以及准备订单。

这种「关键节点人工把关，其余全自动」的模式，实际上是当前浏览器Agent比较现实且安全的落地形态。完全无人值守地让Agent操作支付账户风险过高，而在登录和付款两个高风险动作上保留人工确认，既保留了自动化的效率，又守住了安全底线。

24分钟的真实代价

作者提供了完整的原始Agent/工具执行轨迹视频，其中包含Agent生成的浏览器指令和Playwright代码。需要注意的是，视频是8倍速播放的，实际完成整个任务耗时约24分钟。

这个数字很能说明问题。买一包A4纸，人类手动操作可能只需要一两分钟，而本地27B模型驱动的Agent花了将近半小时。差距主要来自本地推理速度、每一步决策的reasoning开销，以及浏览器交互的等待时间。

这提醒我们，本地Agent目前更多是可行性验证而非效率优势。它证明了「不依赖云端也能跑通复杂的多步骤真实任务」，但在速度上距离实用还有明显差距。对于追求隐私、可控性和离线能力的用户来说，这个代价或许值得；但对于追求效率的日常场景，它暂时还不是最优解。

24分钟的耗时背后有一个关键的技术瓶颈：本地推理的token生成速度（tokens per second，TPS）。云端API通常能达到每秒数十甚至上百个token的输出速度，而在消费级GPU上运行27B模型，速度往往只有每秒10-30个token。对于一个多步骤的购物Agent，每一步决策都需要模型完整地「思考」一遍——读取当前页面内容、分析状态、生成下一步行动指令——每次reasoning的输出可能达到数百乃至上千个token。叠加Playwright执行浏览器操作的等待时间、页面加载时间，以及Qwen3开启「思考模式」（extended thinking）后更长的推理链，整体任务时长被显著拉长。这也是为什么视频需要8倍速播放才不显得冗长。随着量化技术（如GGUF格式的4-bit量化）和推理优化框架（如llama.cpp、MLX）的进步，本地推理速度正在持续提升，但与云端的差距短期内仍然显著。

下一站：iPhone上的本地Agent

作者提到，下一个挑战是把同样的体验在iPhone上通过 TensorAgent 跑起来。而移动端的难点相当明确：一是本地推理速度受限于手机算力，二是iOS的浏览器限制让工具执行变得困难得多。

手机端本地Agent如果真能落地，意义会比桌面端更大——它意味着一个完全装在口袋里、不联网也能思考、能替你操作App的私人助手。但从27B模型的算力需求和iOS的沙盒限制来看，这条路显然不会轻松。

TensorAgent是TensorSharp生态下面向移动端的项目，目标是将本地LLM推理和Agent运行时搬到iPhone等移动设备上。iOS平台的限制不仅来自算力——最新的苹果芯片（如A17 Pro、A18）在神经网络计算上已颇具竞争力——更关键的障碍是iOS的系统沙盒机制。苹果不允许第三方浏览器使用自己的渲染引擎（所有iOS浏览器底层都必须用WebKit），同时应用间的交互受到严格限制，这意味着Playwright这类桌面端浏览器自动化方案无法直接移植。开发者需要寻找替代方案，例如在应用内嵌入WebView进行受控交互，或通过iOS的辅助功能（Accessibility）API模拟操作——后者在权限和稳定性上都面临更多挑战。模型规模方面，手机端通常只能运行1B-7B级别的量化模型，能力上限与27B存在明显差距。

本地浏览器Agent的价值与局限

这个实验之所以引发讨论，是因为它触及了一个核心问题：我们是否需要把Agent的智能部分留在本地？

支持本地路线的理由很充分：数据隐私、无API成本、可离线、完全可控。整个决策链条对用户透明，甚至可以审计Agent生成的每一行Playwright代码。

但局限同样明显：需要相当的本地硬件才能跑27B模型、推理速度慢导致任务耗时长、模型能力上限受限于本地能部署的模型规模。相比之下，云端旗舰模型驱动的Agent在能力和速度上往往更强。

对整个行业而言，这类实验的意义在于持续探索「隐私优先」的Agent形态。随着小模型能力提升和消费级硬件算力增长，本地Agent的性价比曲线可能会逐渐改善。TensorSharp这类开源项目的价值，正是在于把这条路线的可行性摆到台面上，让更多人可以复现和改进。