浏览器agent的开发

开发背景

了解Harness的运行机制以后,我找了个小东西练练手.我选择了浏览器插件.

1. 我固执的认为,后续的AI很大概率会以插件的方式存在,而浏览器是一个非常重要的工具.
2. 完全了解Harness的原理,冲入一个完全陌生的领域,能检测AI对我的提升.

基于上述2点,我选择了为浏览器开发一个AI插件.

这个是源码,有心人自取.

开发过程

我借鉴了pageAgent的源码,使用了openClaw的底层框架--pi-core-agent.

我原本以为openClaw作为一个现象级的应用,它选择的框架应该是一个经过大量测试应用,相对成熟的框架.

对于我来说,typescript是一个相对陌生的领域,虽然我在没有AI的时代写过一点边角的ts.但是在AI的帮助下,基于我对浏览器和ts的了解,我能非常快速的上手.成功在1周内,花费5.5亿token的情况下,居然把项目完成了.

这边说几点体会

底层框架

可以这么说,pi-core-agent其实是一个先行者,而且非常小巧. 框架功能内聚很强,边界比较清晰.

但是,和我之前用的solon-ai完全不能相比. 虽然solon-ai在java领域都说不上话,但是solon-ai提供的扩展能力,比pi-core-agent提升了很多.

主要体现在以下几点

• pi项目除了pi-core-agent以外,提供了pi-coding-agent,这个是一个非常精炼的编码agent. 我要吐槽的是,作为harness核心之一的session存储,居然是在pi-coding-agent中实现的.而且框架内绑定了文件系统,还无法更换.

由于技术栈想通,一个运行在操作系统上,一个运行在浏览器内,就一个存储的绑定,造成session存储就不能复用,这点不得不说,是框架设计的局限.

• 作为harness理念的另外一个核心功能,上下文压缩.在pi-core-agent中,是有上下文压缩的功能和代码的,但是pi-core-agent实现上下文压缩的切入点,有2个 . 一个叫主动压缩,是在agent-end的时候,调用上下文压缩,另外一个叫被动压缩,就是在访问模型返回400 out of limit 的时候,调用上下文压缩. 浪费token倒是次要的,这种被动压缩的行为,在和其他的框架相比的时候,就显得很奇怪.

比如

opencode是在ReactAgent的turn-end的时候,先调用剪枝,在turn-start的时候,调用压缩.

solon-ai-agent是利用java内的拦截器机制,可以随便在什么时候调用,在solon-code的官方示例中,是在ReactAgent的observation阶段调用压缩.

在先入为主的理念,再看到这种被动压缩,我就觉得非常奇怪.

既然agent-end了,那说明当前agent是一个阶段性完成,这个时候压缩就没有意义了.

真正使用了pi-core-agent,我才觉得,这个框架没有之前想象的那么完美,可能openClaw最新的式微,早在pi-core-agent的时候,就已经埋下了.

插件的坑

在浏览器插件的领域内,始终有一个插件,是极客的梦想插件--油猴.在AI时代,油猴应该有更大的价值.所以在AI插件内,理所应当的就应该让插件生成脚本,然后类似油猴的机制,操作浏览器.

万万没想到啊,浏览器插件被google限制死了,那个万恶的CSP机制.通俗的话讲,就是插件内,无法运行插件自带的任何脚本.

所以,我把规则引擎的执行理念,在浏览器插件上重新设计了一份.简单的说,为了规避CSP,我自己设计了一个脚本引擎,这个引擎就是规则引擎的规则配置信息,通过在脚本引擎中重新实现.

在规则引擎中,规则的配置本身就是一个数据,只是这个数据可以被编译成各种可运行的内容而已.为什么会选择规则引擎呢?因为只有规则引擎,才有if-else,for和函数调用的模型.

确定这个想法,花费1晚上,设计这个脚本引擎,花费1天,实现这个脚本引擎6个小时.

相对于之前实现规则引擎,设计2-3天,花费了至少1周的时间,我需要把这套设计同步给其他人,再花费5人月实现出来,还充满bug,修修补补.这个应该就是AI时代对于我的提升了.

写在最后

对于一个我比较陌生的技术栈,凭借我那浅薄的认知,在AI的帮助下,居然能在1周内完成项目,这个本身就能说明很多问题.也能解释很多问题.

我想我对AI的理解,应该更深入了,有以下思考可以分享

• 我一直举这么个例子.做项目就好比造桥,在AI时代,很多事情不用亲自做,而是交给AI.但是造桥,需要人帮AI把一座桥的桥墩给树立好,桥墩的含义有2个方面 1. 桥墩的走向就是桥的走向 技术路线,实现方向都是桥墩,AI是不可能帮你确定这种问题的. 2. AI阶段的难点就是,在不同的位置,桥墩和桥墩之间的距离,高度是不一样的,你无法确定,你设计的2个桥墩,AI能帮你把这2个桥墩之间的事情都处理好.

• 大模型本身存在很大的问题,给大模型一个网页,输入我的目标,由于网页上的按钮,连接非常多,AI经常性会找错东西,点错内容, 如果不给与模型一个完整的流程,基本上无法让模型完成任何东西.这个让我想起2个月前,老外玩的一个测试,在没有提示词的情况下,8岁孩子能完成的事情,AI无法完成.在插件的测试过程中,我真切的感受到了这种"愚蠢"

• AI所完成的事情,本质上是通过多次迭代,多次尝试来完成.注意,不是一次性成功,这种交互模式上的变化,和接口调用完全不相符.因为多次尝试才能做完,如果判断完成,就是一个非常重要的问题.在软件开发领域,之前TDD模式因为被测试代码和测试代码之间的比值经常在1:3左右,所以无法推广,现在AI时代下,TDD模式会成为标配.

• 模型的上下文宽度会影响AI的普及.我在插件内提供了全局html的工具,在小网站,能全部加载,在大网站,一加载就死,无论上下文压缩,剪枝怎么实现,就是上下文超长.而deepseek让整个AI进入到了1M时代,虽然还是不能加载所有的内容,相信再过1-2年,上下文应该到2-5M,到那个时候,AI的生态还会继续进化.