当我们谈论 AI Agent 在浏览器中执行任务时，往往会直接调用 Playwright 或 Puppeteer 这类成熟框架。它们功能完备、生态丰富，但在面对需要长时间运行、自主决策的 Agent 场景时，暴露出三个结构性缺陷：完整 DOM 序列化带来的 token 成本失控、冷启动延迟过高、以及事件循环与渲染管线对资源的无差别占用。Kuri 作为一种全新的技术路线，试图从语言层到协议层重新定义 Agent 与浏览器之间的交互范式。
传统浏览器架构的 Agent 场景瓶颈
传统浏览器自动化框架的核心设计目标是模拟人类用户的操作行为。这意味着每一次页面交互后，框架会尽可能完整地捕获页面状态，包括完整的 DOM 树、CSS 计算样式、JavaScript 执行上下文等丰富信息。这种设计对于人工调试和测试报告极为友好，但当控制权转移到 AI Agent 时，问题立刻显现：一次简单的页面快照就可能产生数万 token 的原始文本，Agent 在每一轮决策前必须消耗大量配额来解析这些冗余信息。以 Google Flights 搜索流程为例，使用 Vercel 的 agent-browser 完成一次往返航班查询大约需要 4,880 个 token，而其中超过七成用于传输浏览器返回的 DOM 快照，真正用于语义理解的决策 token 占比极低。
另一个被忽视的问题是冷启动开销。Node.js 生态下的浏览器自动化工具通常依赖多层抽象：HTTP 服务层、协议转换层、浏览器进程管理层。当 Agent 需要频繁创建新会话或在不同任务间切换时，这些层的初始化开销会显著拖累整体吞吐量。典型的 Puppeteer 实例从启动到就绪往往需要 800 毫秒到 1.5 秒，这在单轮交互中或许可以接受，但当 Agent 需要在单一工作流中执行数十次页面操作时，累计的开销就变得不可忽视。
Kuri 的架构设计哲学
Kuri 从根本上采取了不同的设计思路。它选择 Zig 作为实现语言，这是一个注重零成本抽象和精确内存控制的系统级编程语言。选择 Zig 的核心理由并非追求极致的运行速度，而是看中了其对二进制体积的天然控制能力 ——Kuri 的最终交付物被压缩到约 464 KB，这使得它可以轻松嵌入各种部署环境而不会引入额外的运行时依赖。对于需要在边缘节点或资源受限环境中运行 Agent 的团队而言，这种轻量化特性直接消除了对完整 Node.js 运行时的依赖。
在协议层面，Kuri 完全基于 Chrome DevTools Protocol 实现浏览器控制。CDP 本身就是 Chrome 内部调试接口的公开暴露，它提供了对浏览器内部状态的细粒度访问能力，包括 DOM 查询、JavaScript 执行、网络拦截、截图捕获等完整功能集。与 Selenium 或 Playwright 的封装层不同，Kuri 直接与 CDP 交互，避免了中间协议转换带来的语义损失和性能损耗。这种直接性使得 Kuri 能够在协议层面针对 Agent 场景做定向优化，而不必受制于通用框架的设计约束。
快照压缩：Token 效率的核心突破
Kuri 最重要的技术创新在于其交互式快照模式。当 Agent 请求页面状态时，Kuri 不会返回完整的 DOM 序列化结果，而是通过 CDP 的 DOM 获取接口筛选出可交互的关键元素：链接、按钮、表单输入控件等。每个元素仅携带最小化的属性信息 —— 标签类型、坐标位置、可访问性文本描述以及唯一标识符。基准测试显示，这种压缩后的快照在保持 Agent 决策能力的前提下，将单次页面状态的 token 消耗降低了约 16%。在上述 Google Flights 工作流中，Kuri 消耗 4,110 个 token 完成同等任务，节省的 token 配额可以用于更复杂的后续推理步骤。
这种设计背后隐含了一个关键假设：Agent 不需要理解页面的完整渲染结构，只需要知道 “哪些元素可以交互” 以及 “这些元素的语义标签是什么”。这个假设在绝大多数自动化场景下是成立的，因为 Agent 的决策逻辑本质上是对可操作对象的序列执行，而非对页面视觉呈现的审美判断。通过主动过滤非交互节点，Kuri 将信息密度压缩到了对 Agent 最有价值的层级。
无浏览器模式：kuri-fetch 的轻量化补充
除了基于 CDP 的完整浏览器自动化能力，Kuri 还提供了 kuri-fetch 模式，这是一种完全不同的技术路径。该模式使用 QuickJS 引擎进行服务器端渲染模拟，不需要启动真实的 Chrome 进程即可提取页面内容。当 Agent 的任务仅涉及信息抓取而不需要执行 JavaScript 交互时，kuri-fetch 可以将资源消耗降低一到两个数量级。对于需要大规模并行抓取但交互需求有限的场景，这种模式提供了极具性价比的解决方案。
这种双模式设计反映了 Kuri 对实际工作负载的务实理解：真实的 Agent 工作流往往混合了高交互深度的任务和浅层信息收集任务。在同一个工作流中，Agent 可能需要先通过 kuri-fetch 快速扫描多个候选页面，筛选出目标内容所在的页面后再启动完整 CDP 会话进行精细操作。这种分阶段策略既能保证关键步骤的执行质量，又能在非关键路径上节省计算资源。
架构选择的关键决策参数
如果你正在评估 Kuri 是否适合你的 Agent 系统，以下参数值得重点考量。启动延迟方面，Kuri 宣称的 3 毫秒冷启动时间是在目标二进制已缓存的前提下实现的，实际首次加载会受操作系统文件系统和网络分发的影响。对于需要秒级响应的实时交互场景，建议预热机制或采用守护进程模式保持活跃连接。Token 成本方面，16% 的节省比例在短任务中可能不足以弥补迁移成本，但在需要数百次页面操作的复杂工作流中，累积效应会显著放大 —— 一个包含 500 次交互的自动化流程可以节省约 8,500 个 token，按照当前大模型定价这意味着数美元的成本差异。兼容性方面，由于完全依赖 CDP，Kuri 只能驱动 Chromium 内核的浏览器，如果你的 Agent 需要在 WebKit 或 Gecko 环境下验证，则需要考虑其他方案。
项目本身的成熟度也是不可回避的因素。Kuri 目前仍处于早期维护状态，Issue 响应速度和功能迭代节奏与成熟框架存在差距。在将其引入生产环境前，建议用目标网站集合进行至少两周的稳定性验证，并准备降级方案以应对突发兼容性问题。
资料来源：GitHub 仓库 justrach/kuri；Agent Wars 关于 Kuri 与 Vercel agent-browser 基准测试对比报道。