我在 Lexmount 团队，最近在整理 Moli 的实际使用案例，也让 Codex 配合本地 Moli 跑了几次网页任务：读产品官网、整理资料，以及操作待办演示页。把过程和碰到的限制整理出来，分享一下。
一开始我也没太理解：Chrome 已经能自动化了，为什么还需要一个面向 Agent 的浏览器？试下来，我更关心的是它怎么把网页交给 Agent，以及操作之后能不能读回状态。
先读取页面，再整理材料
Moli 是 Lexmount 开源的浏览器内核，可以本地运行，能执行 JavaScript、处理 DOM 和页面交互。它的设计是结构优先、按需渲染：先读取文字、链接和结构，需要位置或视觉信息时，再请求布局和截图。
这次整理文章时，Codex 用本地 Moli 1.1.19 读取了产品页和 Chrome 的 Headless 文档。例如：
moli fetch --dump markdown --wait done --timeout 20000 https://browser.lexmount.cn/moli
这里的参数对应我这台机器上的版本，其他版本可以先看 moli fetch --help。
返回的 Markdown 保留了标题、正文和链接，Codex 可以继续从中摘出相关段落。不过，里面也有导航和页脚，拿到内容之后仍然需要筛选。
之前整理几个产品的资料时，还遇到过官网返回 403。那次没拿到正文，就明确记为失败，再找其他公开来源，没有让模型补写。
能点击之后，还要核验结果
另一次是 TodoMVC 待办演示页。Codex 通过 Playwright/CDP 连接本地 Moli，添加三条任务、勾选其中一条，再切换筛选。
我比较在意的是最后一步：刷新页面后，重新读取状态。结果是在同一会话里，三条任务还在，一条保持完成状态。
这只能说明那个演示页上的操作通过了检查，不能推出跨会话同步，更不能推出所有网站都兼容。但它让我看清了整个流程：Codex 安排步骤，Moli 执行网页操作，操作后的状态再交回来检查。
和普通浏览器的区别，要放在具体任务里看
Chrome 本来就支持无头运行和程序控制，读取 DOM 也不是 Moli 独有的能力。Moli 的特点主要在于围绕 Agent 的需求安排结构读取和渲染时机。这次没有做性能对照，所以不下“更快”“更省 Token”的结论。
本地 Moli 和托管的 Cloud Browser 也要分开看：前者是浏览器内核，后者是云端会话服务。复杂页面、特殊接口和 Playwright 的兼容范围，仍然需要逐项验证。
目前我觉得比较值得尝试的，是连续读取多个页面、整理字段和出处，或者提交操作后再检查状态的任务。从一个自己熟悉的小页面开始，比直接交给它一整套复杂流程容易判断效果。
在线体验：Lexmount Playground
Select Language