AI on LiaoKE

Page-agent项目改进日志

Sun, 14 Jun 2026 00:00:00 +0000

前言

有一次在linux.do上逛的时候,发现了一个有趣的项目(page-agent),可以用自然语言让ai控制网页，不像传统的自动化网页方案，需要利用Python使用有头或者无头浏览器之类的。这个项目直接是作为js脚本，直接可以嵌入或hook在浏览器中,不需要依赖Python或者其他的东西,更简单易用，好上手。

思考

不过很可惜，原项目是完全基于网页dom文本化的操作方案，网页上的图片信息并不会输出在给ai的文本信息里面，也就是说无法识别网页图片，并且在在网页的文字识别上也加了很多限制，有时候有一些网站的有效信息无法被正常识别。于是乎我想研究一下，看一下能不能在原项目的基础上，让它支持识别图片，并且可以识别更多的网页文字。在经过几天的努力，也是终于把这两个问题给搞定了。

改进方法

一、让 AI 识别图片：将图片链接注入 DOM 树

原项目在生成 DOM 树字符串时，默认的属性白名单 r 中 不包含 src，因此 <img> 标签的链接不会传递给 AI。此外，图片元素通常不被标记为“可交互”，导致其属性在 F() 函数中根本不会被提取。

修改步骤：

将 src 加入属性白名单
在 flatTreeToString 函数的开头，r 数组中添加 'src'，这样 src 属性就会在 matchAttributes 中被匹配并输出。
在 dom_tree_default 的 F() 函数中手动提取 <img> 的属性
原代码只有满足 k(e)（交互元素）或 iframe/body 的元素才会提取属性。我们在 F() 中增加一个分支：当 e.tagName.toLowerCase() === 'img' 时，手动将其所有属性复制到 r.attributes 对象中。
在 flatTreeToString 中为 <img> 特殊输出
在 u() 函数中，当遇到 e.tagName === 'img' 时，直接输出 <img src="..." alt="..." /> 格式，并附带 [图片链接: ...] 标记，便于 AI 识别。为了避免输出 data:image 等内嵌图片，用正则过滤掉 Base64 链接。

效果：
AI 收到的 <browser_state> 中会出现如 [图片链接: https://example.com/photo.jpg] 的信息，AI 知道这是一张图片，可以调用后续的工具来识别。

二、突破文字识别限制：移除文本节点的可见性过滤

原项目对文本节点的输出设有多重限制：

l(e) 检查：若文本位于可交互元素内部则跳过。
isTopElement 检查：只有父元素是“顶层元素”（未被遮挡、不在视口外）时才输出。
isVisible 检查：父元素必须可见（offsetWidth/Height > 0 且 CSS 未隐藏）。

这些限制导致许多嵌套较深或位置特殊的文本（如 Monaco 编辑器内的代码、被 overflow: hidden 包裹的内容）无法被 AI 读取。

修改步骤：

移除 l(e) 检查：在 flatTreeToString 中删除 if (l(e)) return; 这一行。
移除 isTopElement 检查：将文本输出的条件从 e.parent.isTopElement 改为直接忽略，只保留 e.parent.isVisible（或完全去掉，保留所有可见文本）。
放宽 x(e) 函数：在 dom_tree_default 中，将 x(e) 改为始终返回 true，让所有文本节点都被视为可见，不会被丢弃。
可选：移除 C(e) 中的尺寸检查：如果希望进一步解除限制，可将 C(e) 中的 offsetWidth > 0 && offsetHeight > 0 条件改为始终 true，但这会导致大量不可见元素被纳入，建议谨慎。

效果：
现在几乎所有可见的文本节点都会被输出，包括代码编辑器内部的代码、被遮挡的说明文字、侧边栏小字等。AI 的上下文信息量显著增加，但同时 token 消耗也会上升，可根据实际场景调整。

三、让 AI 自主调用图片识别工具

仅让 AI “看到”图片链接还不够，还需要让它能够理解图片内容。我们增加一个自定义工具 recognize_image，AI 可以调用它来识别指定 URL 的图片，并将结果写回图片的 alt 属性。

工具定义（使用 Zod 进行参数校验）：

recognize_image: {
  description: '识别指定 URL 的图片内容，将识别结果写入该图片的 alt 属性，并返回描述文本。',
  inputSchema: z.object({
    imageUrl: z.string().url(),
  }),
  execute: async function (input, { signal }) {
    const { imageUrl } = input;
    // 优先尝试直接使用 URL，失败则转换为 Base64
    // 调用视觉 API（如 Qwen-VL、GPT-4V 等）
    const response = await fetch('...', { ... });
    const description = ...; // 从 API 响应中提取描述
    // 查找页面中对应的 img 元素，写入 alt
    const img = document.querySelector(`img[src="${imageUrl}"]`);
    if (img) img.alt = description;
    return `图片识别完成，描述为：“${description}”`;
  }
}

总结

于是乎，在经过了以上这些操作，成功让原项目支持了图片识别以及解除了一些网页文字识别的限制。以下是我改进版的仓库地址 https://github.com/iliaoke/page-agent

我对几种LLM扩展工具的区别与使用心得

Mon, 02 Feb 2026 00:00:00 +0000

关于LLM的几种工具扩展方法的区别和见解

LLM本身只能当做聊天对话机器,他只可以接收对话，然后返回回答,本身是不能干任何额外的事情.

我们使用ai的一些扩展功能，比如联网搜索和其他的工具本质上是让AI返回指定参数,交由外部工具去完成,然后在拿外部工具执行到的信息作为上下文,再返回给AI,llm只是决策者而并非执行者,工具真正的逻辑执行部分和判断部分需要人为的完成.

而市面上主流的LLM主要有以下几种方法扩展工具

1.Tool Calls(很少使用)

这个是一些大语言模型本身自带的功能,可以让用户自定义一段工具介绍，然后让LLM在适当的时候返回工具调用的结构体,然后由用户解析结构体执行程序之后，再返回获取到的结果来完善上下文

缺点: LLM和工具的衔接部分需要自己人为书写,比如需要判断LLM有没有返回工具调用信息,如果返回了，要根据返回的信息进行选择调用,写的工具越复杂，衔接部分需要花费的时间就越大,并且不同的模型的Tool Calls返回的信息可能还有所不同，不同模型的Tool Calls标准不一样，同一个工具需要对不同的模型单独做适配,所以并不流行(不过算是最早的给llm扩展工具的方法)

2.Mcp(流行)

这是一套严格的标准,不会像Tool Calls一样可能因为模型的问题，返回的结构体有所差异,有mcp客户端,还有mcp服务器,工具的连接方式有远程，也有本地调用,是一套很完善的规则.

缺点: 因为调用流程过于严谨和繁琐,所以很容易引起llm上下文直接爆炸,让llm抓不到重点,对话越到后面效果越差。部署和开发也相对麻烦,因为有服务端，客户端，还有一些七七八八.而Tool Calls,可以直接在一个片段代码里面完成开发.

3.Skills(流行)

这个是最近claude推出,我对他的理解是最高级别的prompt,这个严格来说并不是一个标准,而是共识,更偏向于一个技术理念,需要IDE自己去实现这个理念（Claude开源了他们官方skills的实现）,不像mcp和Tool Calls是有一定的标准的,要严格按照官方的标准来。

Skills某种程度上来说和Tool Calls有点类似,但是他不需要写LLM和工具之间的桥接代码,并且还可以完成一些prompt才可以做的事，比如说自定义一下语气和注意事项.

Tool Calls每写一个工具，我需要自己再写程序去判断LLM返回的工具调用信息，然后再去执行运算(并且还可能因为不同的模型返回的信息有差异而导致兼容性问题),而放到Skills,我只需要自定义一段话,不需要写具体的代码(工具本身是要写代码的，只是调用不需要写代码),比如在特定的时候执行某个文件目录下面的某个代码片段传入某些参数,相当于把桥接部分交由了程序本身(如Vscode和windsurf)去执行,所以说需要程序去适配Skills,它是共识和理念，而不是一套标准.(不过当流行起来的时候，共识理念最终也会成为大家默认的标准)

总结

总结:以上三种给LLM扩展工具的方式,我个人对未来最看好的是Skills,我认为把这套逻辑和共识再进行优化加强是完全可以比过Tool Calls和mcp。Tool Calls桥接部分比较麻烦,一切运转都要依靠代码,还有兼容性问题;mcp开发部署繁琐,且容易引起上下文爆炸,LLM运行缓慢.Skills恰好能解决这两者的缺点

谈谈我对AI的一些理解

Tue, 09 Dec 2025 00:00:00 +0000

前言:

用ai也用了这么久了,今天想谈一下自己对AI的理解.从chatgpt刚问世开始,我就在开始使用大模型.也算是最早使用大模型的那批人.随着大模型的发展愈演愈烈,也衍生出了很多分支比如AI IDE,应用内集成AI聊天助手,大模型识别图像等等.

而随着AI能干的事越来越多,有些人产生了自我怀疑(我能做的事AI都能做,那还需要我干什么),而另外一部分人则产生了依赖(你看ai都是这么说的了(盲目相信AI)).

而我也用大模型用了这么久了,今天便在这里谈一下我自己的认知

我的认知

我始终认为Ai始终是作为一个工具,用来提升工作效率,而非核心.大模型本身的特点就注定了有一些工作是无法代替人类.比如项目的一些宏观设计和管理,一些最新的技术的使用和获取.它是一个超大知识的集合体,它的作用是降低我在知道该怎么做的情况下，让我避免去查代码文档，一步一步慢慢实现功能所带来的时间成本.而不是想做什么，跟AI说一句话，让他帮我实现就行了,我们要做的是工程师，是设计师，而不是让AI作为核心，我们负责提要求。不然就相当于我们是甲方，AI是乙方。我们应该当的是boss，是甲方,AI当我们底下的员工，来负责完成我设计的东西（乙方需求）。

所以在我看来,使用AI无非就两个档次

初级者:什么都不懂,只知道自己想要什么,反正让AI完成就行了。(这在学习的初期确实可以很快带来成就感,但始终无法避免一个问题,你不懂的始终不懂，懂的是AI而不是你,你并没有任何的核心竞争力)
真正掌握AI的人:自己设置架构，自己设置语法要求,自己设置UI层级和UI设计风格,规定使用的技术栈,让AI按照自己的规定去完成对应的工作。AI是提升效率的工具，而不是自己的大脑,真正应该怎么做，应该是自己知道，而不是AI知道。

所以在这个时代,有人害怕ai,有人依赖AI,那我的答案是掌握AI.

如何选择最适合你的 AI IDE 与扩展插件

Mon, 08 Dec 2025 00:00:00 +0000

AI IDE 工具推荐

为什么使用 AI IDE？

传统 AI 聊天无法：
- 实时读取本地文件
- 兼顾项目的宏观框架管理
偏商业化的 AI IDE：
- 一般不允许自定义第三方服务商接口
- 强制使用平台模型收取订阅费
- 实时读取本地文件
- 适配开发的执行流程与逻辑

因此，为了高效开发和项目管理，需要使用 AI IDE。

AI IDE 的能力评价指标

硬实力：自带模型能力
软实力：上下文补全与逻辑能力
- 通过插件、执行策略、隐藏的上下文prompt 等实现

两者缺一不可

AI 编程工具分类

1. CLI 命令行AI开发工具

开发效率比 IDE 差
- 文件引用需手动输入
不适合宏观项目管理
适合单一功能的改进
代表工具：
- OpenAI Codex★★★(也有vscode 插件版本,但开发效率不如集成式ai ide,仍然是片段式更改)
- Claude Code★★★(也有vscode 插件版本,但开发效率不如集成式ai ide,仍然是片段式更改)
- OpenCode（开源）（可自定义服务商接口，但上下文能力较弱）

2. IDE AI 开发工具

直接从文件管理器拖入文件即可
支持项目级宏观管理

国内 AI IDE

Trae
- 特有 Solo 模式（和普通模式感觉主要是 UI 差别，在功能上感觉差的不是很大，可能隐藏 prompt 有所优化）
- 可使用规定的国内其他服务商接口
Qoder
- 无特色
- 上下文消耗快
- 无法使用国外模型或其他接口
通义灵码
- 无特色
- 无法使用国外模型或其他接口

国内 IDE 的共性

喜欢构建工作区文件全量索引，每次提问前先查索引文件，消耗大量上下文 token，有时查找的文件过多反而忽略关键问题
国内模型编码能力较弱，且不允许使用国外更强的模型
方便支付订阅, 界面中文支持较好

国外 AI IDE

GitHub Copilot★★
- VSCode 插件形式
- 适合片段式的文件
- 上下文补全能力较弱
- 无法全面定制化
Cline★★（开源）
- 可自定义任意服务商
- VSCode 插件形式
- 适合片段式的文件
- 上下文补全能力较弱
- 无法全面定制化
Kilo（开源）
- 可使用规定的第三方服务商api
- VSCode 插件形式
- 适合片段式的文件
- 上下文补全能力较弱
- 无法全面定制化
Cursor★★★
- 基于 VSCode 深度定制
- 自研模型 Composer 1 (专为编程训练, 功能强大)
- 可使用规定的其他服务商 API
- agent可以直接连接github远程储存库(特色功能)
- 预设 Prompt 优秀输出质量高，但免费额度少，订阅贵
- 亮眼功能：
  - 浏览器设计模式：可以直接在ide里面打开网页，并且选择元素，方便设计网页
  - debug：可以根据log寻找隐藏bug
kiro 电脑安装闪退，我用不了(哭)
Windsurf★★★
- 基于 VSCode 深度定制
- 自研模型 SWE-1.5 (专为编程训练, 功能强大)
- 亮眼功能：
  - Memories：可以根据对话和习惯生成对应的记忆（ai自动生成记忆，以在对话之间保持上下文连贯性）
  - DeepWiki：独家功能,定位项目中关键函数或变量，了解用途和在项目其他地方引用 (方便学习他人的开源项目)
  - CodeMap：独家功能,用于分析现有项目代码结构,可以根据输入的问题生成项目代码实现的流程图,点击流程图可以定位对应代码实现的部分（对于解剖他人项目的功能实现很有用）
  - 浏览器设计模式：可以直接在ide里面打开网页，并且选择元素，方便设计网页
  - 对话消息互通：独家功能,不同对话之间可以选择互通消息，如两个不同的项目,具有一定的关联性，我们就可以通过这个功能实现两个项目在对话层面上的互通，而不需要ai去研究另外一个项目的代码，防止添加过多的内容，导致上下文混乱
- 免费额度高，价格便宜
- 支持规定的其他服务商 API
Zen Editor（开源）
- 可使用任意服务商接口
- 自带免费额度高
- 上下文补全能力较弱

总结推荐

综合价格、模型能力和上下文补全能力，我个人首推 Windsurf
DeepWiki、CodeMap 和消息互通是其最大亮点，让其上下文补全能力非常强大
其他 AI IDE 在 UI 功能上同质化严重，差别主要在 AI 模型、执行逻辑和预设 Prompt
如果不考虑开发效率，单论编码能力,openai的codex和claude code这种命令行式开发可能是最强的一批,其次就是cursor和windsurf