2026-11-04 15:45:00
<p>先说结论：skill 的消耗不在于你「用」了多少，而在于你「装」了多少。装进去的那一刻，账单就开始计时了。</p><p>这话不是我拍脑袋说的。前几天跑完一个长任务，顺手翻了下 agent 的 token 统计面板，几个数字摆在一起，看得我有点沉默。</p><span id="more"></span><h2 id="一次实测：只加载了-1-个-skill，账单长这样"><a href="#一次实测：只加载了-1-个-skill，账单长这样" class="headerlink" title="一次实测：只加载了 1 个 skill，账单长这样"></a>一次实测：只加载了 1 个 skill，账单长这样</h2><p>先看任务整体的账。这个任务跑下来，总用量 184.4M token，1.84 亿。其中工具结果 87.1M（47.3%）、助手消息 84.9M（46.0%），这两块是大头，符合直觉：长任务嘛，工具来回调、模型来回写，钱主要花在这儿。</p><p><img src="/img/skill-token-total.png" alt="Token 统计：总用量 184.4M，技能注入累计约 4.2M 占 2.3%"></p><p>然后看 skill 相关的那一行：<strong>技能注入（累计）约 4.2M，占 2.3%</strong>。</p><p>4.2M 是什么概念？放在 1.84 亿里是 2.3%，确实是「说少不少，说多也不多」。但先别下结论，看看这 4.2M 是由什么叠出来的。</p><p><img src="/img/skill-token-context.png" alt="当前上下文：467.6k / 1.0M 已用 46.8%，技能注入约 7.5k 占 2%"></p><p>任务结束时，当前上下文 467.6k / 1.0M，用了 46.8%。里面技能注入约 7.5k，占 2%。注意，这 7.5k 是单轮快照，每一轮都在。累计的 4.2M，就是这种东西乘以五六百轮叠出来的。</p><p>那这单轮 7.5k 里装的是什么？展开看：</p><p><img src="/img/skill-token-inject.png" alt="技能注入明细：4 项共约 7.9k，三次 skill-catalog 目录更新加一次 impeccable 技能加载"></p><p>4 项注入里，3 项是 skill-catalog 的目录更新（1.3k、1.7k、2.0k），只有 1 项是真正加载技能正文：<code>Skill: impeccable</code>，2.9k。</p><p>把前提摆清楚：<strong>这个环境里安装了不到 20 个 skill，整个任务全程只加载了 1 个。</strong> 就 1 个。剩下的消耗全花在「目录」上：agent 要把「我有哪些 skill 可用」这份清单带在上下文里，装得越多，清单越长，固定开销越大。说白了，你用一个 skill，付一份钱；你装二十个 skill 只用一个，付的是二十个的目录钱，再乘以轮数。</p><h2 id="外推一下：无限制安装会怎样"><a href="#外推一下：无限制安装会怎样" class="headerlink" title="外推一下：无限制安装会怎样"></a>外推一下：无限制安装会怎样</h2><p>把账算明白只需要小学乘法。</p><p>目录里每个 skill 占一行名字加描述，粗算 50–100 token。20 个 skill 的目录约 1–2k token，和我实测里一次目录更新的体积（1.3k–2.0k）对得上。那如果像很多人一样，随手就装几个skill，装到一两百个呢？目录本身一轮就是 10k–20k token，雷打不动；一个任务跑几十轮，几十万到上百万 token 纯交给目录。</p><p>token 账单还是小事。真正贵的是另一笔：候选清单越长，模型挑错 skill、或者干脆漏掉正确 skill 的概率越高。就像在一箱别人的工具里翻自己的扳手，工具越多，翻错的那次越致命。skill 本来是来省 token、省口水的，装多了反而变成每轮必缴的税。</p><p>所以别纠结「skill 有没有用」了，真正的问题是「安装」这个动作本身太粗糙。npx 一条命令全量推给所有 agent，爽是真爽，账也是真账。我想要一种极其简单的方式，对 skill 做精细化管理：平时收在库里，哪个 agent、哪个项目需要，再投哪几个过去。</p><h2 id="flint：把-skill-当资产管，而不是当插件装"><a href="#flint：把-skill-当资产管，而不是当插件装" class="headerlink" title="flint：把 skill 当资产管，而不是当插件装"></a>flint：把 skill 当资产管，而不是当插件装</h2><p>这个需求我自己解决了一下，就是 <a href="https://github.com/lcy362/flint">flint</a>（<code>local-skills-hub</code>）。之前写过一篇《<a href="/posts/29684/">Flint：让 skill 成为个人资产</a>》讲它的设计哲学：local-first、数据主权、skill 只是磁盘上的普通文件。这篇不重复那些，只讲它怎么解决「按需开启」这件事。</p><p>核心思路一句话：<strong>归集一次，投放按需。</strong></p><p>归集。所有 skill 的本体只存一份，放在你自己的仓库目录里，就是磁盘上一个普通文件夹，git 想怎么管怎么管。散落在各个 agent 目录里的、从第三方 npx 装来的、从别的目录导入的，flint 都能收进来：同名自动去重，来源分歧在 Health 页列出来一键修。收完之后，agent 目录里不再是各自为政的副本，而是指向仓库的软链。</p><p>投放。这是解决 token 问题的关键一步。flint 里有个「预设（Preset）」：一个 skill 包，成员可以是显式指定的几个 skill，也可以是「带某标签的全部」。然后到 agent 详情页，选一个预设，点「Apply preset」，<strong>只有这个预设里的 skill 会被部署进该 agent 的 skill 目录</strong>。没链接预设的 agent，一个 skill 都看不到，目录注入自然是零。</p><p>换句话说，agent 上下文里那份 catalog 清单的长度，从此由你决定：写博客的 agent 只挂写作相关的三五个 skill，目录就只收三五行的税；跑前端任务的 agent 挂 impeccable 那一批，互不干扰。想换组合？改预设成员或标签，再点一次 Apply，完事。</p><p>智能体管理。flint 的 Agents 页按「实际 skill 目录」出卡片：多个 agent 共用一个目录就合并成一张卡、共用一套策略，不会给你演出「改了 A 发现 B 没生效」的戏码。每张卡上能做的事：启用或停用、覆盖目录、从库里逐个加 skill、套预设一键部署、单个 skill 选软链还是拷贝。目录里物理上有什么，agent 就看到什么，没有后台偷偷同步的玄学。</p><p>这套组合拳打下来，「装了 200 个 skill」和「这个 agent 能用 5 个 skill」就彻底解耦了。库可以无限大，税只按投放的交。</p><h2 id="顺便提一嘴：flint-还能干什么"><a href="#顺便提一嘴：flint-还能干什么" class="headerlink" title="顺便提一嘴：flint 还能干什么"></a>顺便提一嘴：flint 还能干什么</h2><p>按需投放是主线，但归集和投放这两层搭好之后，剩下的功能基本是顺出来的：</p><ul><li>Projects：给项目登记路径加标签，标签就是部署策略。匹配的 skill 进项目的 <code>.agents/skills</code>（可以跟 git 提交），再软链共享给各 agent 的项目级目录。换机器，项目自带技能包。</li><li>Health：六维体检（同步状态、重复、断链、配置、仓库、项目），问题列出来，一键修之前先让你确认。</li><li>npx 安装托管：把 <code>npx xxx skills install</code> 这类命令贴进去，flint 在受管目录里跑（自带 git 快照可回滚），装完直接进正常注册流程；更新就是源卡片上一个按钮。</li><li>标签与元数据：标签优先写进 <code>SKILL.md</code> 的 frontmatter，就是 Claude Code 等 40+ 工具原生能读的那份；没回写的先在本地暂存，一键迁移。</li></ul><p>安装就一行：<code>npx flint-skills-hub</code>，然后开 <a href="http://localhost:8787。没有云、没有账号、没有遥测，skill">http://localhost:8787。没有云、没有账号、没有遥测，skill</a> 是你磁盘上的文件，flint 卸了它们也在。界面中英可切换，日志可下载，都是顺带的手尾。</p><h2 id="回到开头那组数字"><a href="#回到开头那组数字" class="headerlink" title="回到开头那组数字"></a>回到开头那组数字</h2><p>1.84 亿 token 的任务，skill 注入累计 4.2M，占 2.3%。单看比例确实不能算多。但别忘了前提：这是个只装了不到 20 个 skill、全程只用了 1 个的环境。</p><p>skill 这东西，价值在「复用」，成本在「常驻」。管理方式粗暴一点，成本就常驻给你看。</p><p>所以下次手痒想 <code>npx</code> 全量装一套技能包之前，先问自己一句：这二十个 skill，我这个 agent 真用得上几个？</p><p>想清楚再装。或者干脆别装：归集进库，按需投放，让目录永远只留真正干活的那几个。</p>
2026-11-01 21:45:06
<p>一台 240 × 320 的彩色屏，ESP32-C3，500mAh，50 克，透明外壳，拴根绳挂在脖子上。</p><p>这种配置放在今天，光看参数是很难兴奋的。</p><p>但它有一个别的设备给不了的东西：它会让人想动手。</p><p>FoloToy AI Passport，官方的说法是“一张与 AI Agent 一起开造世界的通行证”。我更愿意把它讲成一台能折腾的小玩具：你不想写代码，它就老老实实当你的一张电子身份卡；你想折腾，整个固件随你改，改崩了还能扫背面的二维码刷回来。两条路都在，谁也不劝谁。</p><p>而我对它的定位更简单：就是个玩具。抛开所有功能不谈，它最要紧的地方是很好玩。</p><span id="more"></span><h2 id="先看清它的底色"><a href="#先看清它的底色" class="headerlink" title="先看清它的底色"></a>先看清它的底色</h2><p>它是一张卡片。</p><p>一张银行卡大小的东西：60 × 95 × 8.5 mm，50 克，透明塑料外壳，前面一块 240 × 320 的彩色屏，下面三枚按键，顶部一个挂绳孔。背面一枚二维码，里面还塞了一张被动的 NFC 标签。</p><img src="/img/61402-1.jpg" alt="AI Passport 正面：透明外壳与挂绳环" width="58%" /><p><em>正面熄屏的样子。透明外壳里能直接看到主板和电池，底下印着一行小字：The Open Wearable AI Passport。</em></p><table><thead><tr><th>项目</th><th>规格</th></tr></thead><tbody><tr><td>MCU</td><td>ESP32-C3，8 MB Flash</td></tr><tr><td>显示</td><td>240 × 320 彩色 TFT</td></tr><tr><td>输入</td><td>上、下、确定三键 + 独立电源键</td></tr><tr><td>音频</td><td>内置麦克风与扬声器</td></tr><tr><td>无线</td><td>2.4 GHz Wi-Fi + 蓝牙 5 LE</td></tr><tr><td>NFC</td><td>被动 NTAG213</td></tr><tr><td>电池</td><td>500 mAh，USB Type-C</td></tr><tr><td>重量</td><td>50 g</td></tr></tbody></table><p>240 × 320 这种分辨率，拿手机屏的标准看几乎是个笑话。但挂在胸前，距离决定了它够用。真要说短板，是它塞不下太多信息，一屏放三个数字就接近上限了，逼着你在动手前先想清楚：到底哪个数字最值得被看见。</p><p>透明外壳是它做得最聪明的一个决定。主板、电池、扬声器、天线，全都看得见。这不是在炫耀工艺，是在明着告诉你：这些东西你都能动。FoloToy 把“可改造”三个字写在了外观上，不用翻说明书就知道这不是一台封死的消费电子。</p><h2 id="三种用法，同一个流程"><a href="#三种用法，同一个流程" class="headerlink" title="三种用法，同一个流程"></a>三种用法，同一个流程</h2><p>它自己把玩法分成三层，叫 WEAR、PLAY、CREATE。</p><p><strong>佩戴</strong>。什么都不用装。开机之后，在微信小程序里搜“FoloToy AI Passport”，通过本地蓝牙把名字、头像、一段自我介绍和一张全屏图片同步进去，它就变成了你的“AI 通行证”。默认还内置了一款小游戏，开箱就有得玩。</p><p><strong>换玩法</strong>。官网的玩法库里有十几个官方玩法，AI 像素宠物、口袋番茄钟、俄罗斯方块、答案之书、Bad Apple 播放器这类。浏览器里点一下就能刷进设备，刷新的会覆盖旧的，但身份卡那部分信息留着。</p><p><strong>自己写</strong>。GitHub 上的 <code>FoloToy/ai-passport</code> 是完整开源的开发基线，MIT 协议，硬件引脚、屏幕参数、按键电压全都写在里面，不藏着。</p><p>其实开源硬件开放得不稀奇，稀奇的是这三层在同一个流程里：你不用为了“自己写”先把前面两层搞坏。玩腻了官方玩法去刷自己的固件，身份卡还在；刷崩了扫背面的二维码就能救回来。它把退路设计得很干净，这一点比“开放”两个字重要。</p><h3 id="顺带一提：它长在-AI-编程的射程里"><a href="#顺带一提：它长在-AI-编程的射程里" class="headerlink" title="顺带一提：它长在 AI 编程的射程里"></a>顺带一提：它长在 AI 编程的射程里</h3><p>第三层原本是给会写嵌入式的人准备的，我这种连 Hello World 都懒得手写的人，按理说进不去。</p><p>但它刚好站在了这波 AI 编程的射程里。仓库根目录的 <code>AGENTS.md</code> 不是给人看的贡献者说明，是一份写给 Agent 的规格书：屏幕多大、按键怎么读、哪些能力已经确认可用、哪些边界不能越、验收要逐项报哪些结果，一条条写死。</p><p>于是流程变成了这样：把仓库丢给 Agent，让它先读 <code>AGENTS.md</code>，再用一句话说清楚你想要什么。剩下的编译、构建、刷机，它都能干。这不是厂商的体贴，更像是它正好长对了地方。</p><h2 id="我拿它干了什么：一张挂在身上的孩子愿望单"><a href="#我拿它干了什么：一张挂在身上的孩子愿望单" class="headerlink" title="我拿它干了什么：一张挂在身上的孩子愿望单"></a>我拿它干了什么：一张挂在身上的孩子愿望单</h2><h3 id="先说背景：我们家有一套积分系统"><a href="#先说背景：我们家有一套积分系统" class="headerlink" title="先说背景：我们家有一套积分系统"></a>先说背景：我们家有一套积分系统</h3><p>在这之前，我给孩子写过一套积分系统，叫 WishBank。表现好加分，表现差扣分，攒下来的分能换他想要的东西。</p><p>有些事我会做成专项，比如跳绳。他之前总抱怨太累、不想练，我就加了个跳绳打卡：每天跳够数量算完成，连续打卡才拿得到积分。这招意外地管用，积极性一下就上来了，现在每天我下班回到家，他先拉着我去楼下把绳跳了。</p><p>所以拿到这个玩具，我第一个念头就是把这些东西塞进去。</p><p>AI Passport 也完全能满足这个需求。卡片大小，能挂；有 Wi-Fi，能联网拿数据；240 × 320 放数字够用。最要紧的是固件能整个重写——它不是一台“别人替你定好功能”的设备，你可以让它只干一件事，一直干这件事。</p><h3 id="屏幕上放了什么"><a href="#屏幕上放了什么" class="headerlink" title="屏幕上放了什么"></a>屏幕上放了什么</h3><p>一共四屏，上、下键翻：</p><ul><li><strong>第一屏，余额。</strong> 一个大号数字，下面一行今天的跳绳个数，再下面一行本轮第几天。</li><li><strong>第二屏，上次加分和上次扣分。</strong> 事由、分值、时间，两边各一条。</li><li><strong>第三屏，今天的跳绳进度。</strong> 当前值比目标值，下面一条进度条，再下面是打卡状态和本轮进度。</li><li><strong>第四屏，历史最好成绩。</strong> 自由练习一次最多多少个，一分钟计时最多多少个。</li></ul><p>顶栏左边是孩子的名字，右边是电量。</p><p>信息就这么点。别小看这个“少”，正是因为它塞不下更多，我才被迫想清楚：他真正需要看到的，是余额和今天的跳绳数。</p><img src="/img/61402.jpg" alt="AI Passport 上运行的跳绳进度屏" width="58%" /><p><em>第三屏在真机上的样子：今日 558 / 500，已打卡，本轮 6/7 天。它自己会把新数据拉回来，底下那行“正在更新”就是。</em></p><h3 id="它怎么联网"><a href="#它怎么联网" class="headerlink" title="它怎么联网"></a>它怎么联网</h3><p>数据从家里那套系统的接口来。设备连上 Wi-Fi，用 HTTPS 拉一份只读快照，带证书校验和一个自定义 Token，服务端认 Token 和 UA。拉回来的结果写进设备自带的存储，下次开机先把上次的亮出来——因为联网最快也要十几秒，第一屏不能是空的。</p><h3 id="让它像个“挂在那儿的东西”"><a href="#让它像个“挂在那儿的东西”" class="headerlink" title="让它像个“挂在那儿的东西”"></a>让它像个“挂在那儿的东西”</h3><p>交互上我给它定了几条规矩：短按确定立刻刷新一次；三十秒没人动，它自己翻到下一屏，四屏轮着播；两分钟没动静就熄屏，按任意键亮起来，亮的同时顺手拉一次最新数据。</p><p>这些都不是刚需。但没有它们，它就是一块要人伺候的电子产品；有了，它才像个挂在那儿的东西，你不用管它，它自己就在。</p><p>整个固件基本是 Agent 写的。我负责提需求、改需求、插上 Type-C 线在真机上验收。最终合并出来的固件 3.94 MB，从 0x0 烧进去就能跑。</p><h2 id="用起来真实感受到的几件小事"><a href="#用起来真实感受到的几件小事" class="headerlink" title="用起来真实感受到的几件小事"></a>用起来真实感受到的几件小事</h2><p><strong>屏幕</strong>。上面说过了，分辨率是它的短板也是它的筛选器。真塞进三行以上信息就开始难看，逼着你做减法。</p><p><strong>三个按键</strong>。上、下、确定，加上一个独立的硬件电源键（按 0.5 秒开机，约 2 秒关机）。三个键能玩出什么花样我心里有数：翻页、选择、确认，再多就得靠长按和双击凑。它不是为复杂交互设计的设备，认了这条命反而好办。</p><p><strong>NFC 和背面那张二维码</strong>，是目前最被低估的两个东西。NFC 是被动标签，别人拿手机碰一碰就能读到你想让他看到的内容，做身份卡、做名片都是天然的；二维码是救命用的——真把设备刷到起不来，扫码拿到专属链接，用电脑上 Chrome 或者 Edge 加一根 Type-C 线就能恢复出厂。我上手第一周刷崩过不止一次，每次都是它把我捞回来的。</p><img src="/img/61402-3.jpg" alt="AI Passport 背面：FoloToy 标志、NFC 标识与二维码" width="58%" /><p><em>背面。主板整块露在外面，下半部分印着 FoloToy、NFC 标志和那张救命的二维码。</em></p><h2 id="别冲动，先看这部分"><a href="#别冲动，先看这部分" class="headerlink" title="别冲动，先看这部分"></a>别冲动，先看这部分</h2><p>先说不适合谁。</p><p><strong>想要一台会聊天的 AI 玩具的，别买。</strong> 麦克风和扬声器都在，但它默认不是语音助手，也谈不上“AI 陪伴”。冲着这个去的，收货当天就会失望。</p><p><strong>想要现成好玩内容的，别把它当掌机。</strong> 玩法库里十几个玩法，质量和深度都谈不上“能玩很久”。买个二手掌机能玩的东西比它多得多。</p><p><strong>完全不打算折腾的，亏。</strong> 那你只买到了它的第一层，而钱有一大半是给第三层的。</p><p>适合的只有一类人：纯粹想找个东西折腾的。只在屏幕上 vibe coding 已经不过瘾了，想有台小设备，自己想怎么定制就怎么定制。</p><h2 id="怎么下手"><a href="#怎么下手" class="headerlink" title="怎么下手"></a>怎么下手</h2><ol><li>先去官网 <code>ai-passport.folotoy.cn</code> 看看玩法库，确认有没有你想要的现成内容。</li><li>到手先别急着折腾固件。用微信小程序配一次身份卡，把第一层的流程走通，顺便熟悉三个键。</li><li>真想自己写，去 GitHub 打开 <code>FoloToy/ai-passport</code>，按 README 的约定从 <code>main</code> 建一条 <code>feature/*</code> 分支，再把整个仓库丢给 Agent，第一句话让它读 <code>AGENTS.md</code>，第二句话再说你想要什么。</li><li>刷之前先记住背面那个二维码在哪。</li></ol><h2 id="一句话总结"><a href="#一句话总结" class="headerlink" title="一句话总结"></a>一句话总结</h2><p>大部分所谓的 AI 硬件，问题不是不够聪明，是没地方开花。</p><p>AI Passport 给出的答案挺朴素：把硬件摊开给你，把接口写成文档，再让你带着 AI 一起折腾。剩下的，是你自己想往这块 240 × 320 的屏幕里放什么东西。</p><p>我放进去的是孩子的愿望单。以前他要知道自己攒了多少分，得等我递手机过去；现在那块屏挂在那儿，连这句催促都省了。</p><p>你手上那个一直躺在手机里的数字，是什么？</p>
2026-10-08 17:13:00
<p>你可能遇到过这种情况。</p><p>让 AI 帮忙去某个网站查点东西，它说”我准备好了，请先登录”。然后弹出一个浏览器窗口，你输账号、等短信验证码、过那个选图片的验证，折腾完了再回去告诉它”好了”。换个网站，重来一遍。</p><p>我受不了这个流程，所以做了个东西。它的思路很简单：<strong>别给 AI 开一个新浏览器，让它直接用你正在用的那个。</strong></p><span id="more"></span><h2 id="为什么会变成”先登录”"><a href="#为什么会变成”先登录”" class="headerlink" title="为什么会变成”先登录”"></a>为什么会变成”先登录”</h2><p>现在多数让 AI 操作网页的方案，都是给 AI 单独开一个浏览器。</p><p>单独开有单独开的好处，干净，不影响你正在用的东西。但代价是它什么都不知道。没有你的账号，没有任何你已经设置好的东西。所以第一步必然是让你登录。</p><p>也有一些方案会把你的浏览器配置复制一份给 AI 用，登录状态算是有了。但你的登录状态只活在一份里，所以你要么从此一直用那个复制出来的浏览器，要么两份就慢慢对不上了。为了跑个自动化把自己的主浏览器换掉，我觉得不太划算。</p><h2 id="换个思路：让-AI-坐到你旁边"><a href="#换个思路：让-AI-坐到你旁边" class="headerlink" title="换个思路：让 AI 坐到你旁边"></a>换个思路：让 AI 坐到你旁边</h2><p>我做的这个东西走的是另一条路。</p><p>它不新开浏览器，也不复制配置，而是直接接管你正在用的那个 Chrome。你登录过的网站，它进去就是登录状态；你装过的插件、调过的偏好，它都在。</p><p>有点像你让一个同事坐到你位置上，用你打开的页面帮你干点活，干完把结果给你。</p><p>区别是它会守着几条规矩：</p><ul><li><strong>在后台干活，不占你的屏幕。</strong> 开新页面时新开在后台，你正在看的标签不会被切走，你正在打字也不会被打断。你可以一边让它干活，一边做自己的事。</li><li><strong>遇到非得你本人的环节，它会停下来等你。</strong> 登录、验证码、扫码、支付确认，这些它一律不碰，只告诉你”这一步需要你来做”，然后等着，期间不点任何东西。你做完说一声，它接着干。</li><li><strong>它也不会碰你的密码。</strong> 不代你输密码，不代你看验证码，也不会去读你页面上密码框里的内容。</li></ul><h2 id="能用它干什么"><a href="#能用它干什么" class="headerlink" title="能用它干什么"></a>能用它干什么</h2><p>我平时用的大概是这几件：</p><ul><li>打开我的后台，告诉我昨天的收入是多少</li><li>把某个页面里的内容整理出来，放进我的笔记</li><li>去一个系统里把表单填好、截图传上去、提交</li><li>看看某个订单发货了没，发了就把单号贴到对应的帖子里</li><li>把一条内容同步到几个平台</li><li>改账号设置这种必须本人在场的活，它负责点开页面，剩下的交给我</li></ul><p>凡是你自己要在网页上点来点去、而且得先登录才能做的事，基本都可以试试让它来。</p><h2 id="怎么装"><a href="#怎么装" class="headerlink" title="怎么装"></a>怎么装</h2><p>两步，配一次就行。</p><p><strong>第一步</strong>，在你平时用的 Chrome 里打开一个开关。地址栏输入 <code>chrome://inspect/#remote-debugging</code>，把 “Allow remote debugging for this browser instance” 勾上。</p><p>这是 Chrome 官方提供的一个开关，作用是允许外部程序连上这个浏览器。连接的时候 Chrome 会弹一次窗问你”要允许远程调试吗”，点允许就行。</p><p>这个弹窗是安全门槛，我特意没有做自动点击它的功能。看到它弹出来，请你亲手点。</p><p><strong>第二步</strong>，把这个技能装到你的 AI 工具里。</p><p>它是一份给 AI 看的说明书加工具，装到你平时用的 AI 工具（Claude Code、Cursor、Codex、WorkBuddy 这些）里就能用。</p><p>推荐用 flint 管理，它会帮你把技能分发到各个 AI 工具，改一处就都更新：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br></pre></td><td class="code"><pre><span class="line">git <span class="built_in">clone</span> https://github.com/lcy362/chrome-sidecar</span><br><span class="line">npx flint-skills-hub</span><br></pre></td></tr></table></figure><p>不想用工具的话，把 <code>chrome-sidecar/skills/chrome-sidecar</code> 这个文件夹拷到你 AI 工具的 skills 目录里也一样。</p><h2 id="装完怎么用"><a href="#装完怎么用" class="headerlink" title="装完怎么用"></a>装完怎么用</h2><p>不用启动任何东西，也不用记命令。直接跟你的 AI 说话：</p><ul><li>打开我的后台，告诉我昨天的收入是多少。</li><li>把那个页面截个图，放到我的笔记里。</li><li>帮我看看这个订单发货了没。</li><li>帮我改一下账号设置，要登录的时候叫我。</li></ul><p>就这样。剩下是它的事。</p><h2 id="几个前提"><a href="#几个前提" class="headerlink" title="几个前提"></a>几个前提</h2><p>它需要 Chrome 或同类的浏览器，而且得是你正常在用的那一个。专门为它开一个新浏览器是没用的。</p><p>上面那个开关必须开，我没法帮你绕过，因为那是浏览器的安全设计。</p><p>还有一句实话：如果你只是想让 AI 读一个公开的网页，别用这个，直接让它读就行。这个东西是为”需要你登录才能做的事”准备的。</p><h2 id="最后"><a href="#最后" class="headerlink" title="最后"></a>最后</h2><p>项目在这里：<a href="https://github.com/lcy362/chrome-sidecar">github.com/lcy362/chrome-sidecar</a></p><p>开源，MIT 协议，代码和文档都在仓库里。</p>
2026-09-24 12:00:00
<h1 id="从实现逻辑出发，搭一个能干活的-Agent"><a href="#从实现逻辑出发，搭一个能干活的-Agent" class="headerlink" title="从实现逻辑出发，搭一个能干活的 Agent"></a>从实现逻辑出发，搭一个能干活的 Agent</h1><blockquote><p>背景：这篇是读《深入理解 AI Agent：设计原理与工程实践》（李博杰，Apache 2.0 开源，GitHub: bojieli/ai-agent-book）的整理笔记。全书十章，从原理讲到工程实战，配 88 个可跑的实验。下面不按章节复述，而是按”实现一个 Agent 要解决哪些问题”重排，每个模块只讲两件事：<strong>要解决什么问题</strong>，<strong>核心思路是什么</strong>。细节和数据留给原书。</p></blockquote><hr><h2 id="一、Agent-的本质：一个公式和一个循环"><a href="#一、Agent-的本质：一个公式和一个循环" class="headerlink" title="一、Agent 的本质：一个公式和一个循环"></a>一、Agent 的本质：一个公式和一个循环</h2><p><strong>问题</strong>：Agent 到底由什么构成，最小可运行形态长什么样？</p><p><strong>思路</strong>：<code>Agent = LLM + 上下文 + 工具</code>。直觉说法是”大脑 + 眼睛 + 手脚”，学术说法是策略 + 观察空间 + 动作空间。</p><p>最小实现只有一个 while 循环：把消息列表发给模型，返回工具调用就执行并把结果追加进去，没有工具调用就输出退出。这个循环叫 ReAct（思考 → 行动 → 观察）。支撑它的三条性质必须理解到位：</p><ul><li><strong>每次调用无状态</strong>，模型要的一切必须完整出现在消息列表里；</li><li><strong>模型只决策，执行在框架侧</strong>——模型说调什么、传什么参，真正跑代码的是你的代码；</li><li><strong>上下文 = 静态前缀 + 轨迹</strong>，前缀是系统提示词加工具定义，轨迹是随交互增长的消息历史。后面所有的优化都建立在这个切分上。</li></ul><p>消融实验给出了各组件的必要性：缺工具定义彻底不能动，缺工具结果会反复调同一个工具直到卡死，缺思考过程前后决策矛盾，缺历史消息等于失忆。</p><p>工具不必多。七个就够了：代码解释器、Bash、读/写/编辑文件、Glob、Grep。这不是简化，而是主流通用 Agent 的真实配置——<strong>开放任务型 Agent 的内核就是一个 Coding Agent 加一个文件系统</strong>，因为代码是唯一能”创造新能力”的元能力。</p><hr><h2 id="二、Harness：模型之外的竞争力"><a href="#二、Harness：模型之外的竞争力" class="headerlink" title="二、Harness：模型之外的竞争力"></a>二、Harness：模型之外的竞争力</h2><p><strong>问题</strong>：同样的模型，为什么有的 Agent 稳定可靠，有的一跑就崩？</p><p><strong>思路</strong>：把公式扩展成 <code>Agent = Model + Harness</code>。Harness 是围绕模型搭的全部支撑代码，除上下文和工具外，还包括<strong>约束</strong>（能做什么、不能做什么）、<strong>验证</strong>（结果对不对）、<strong>纠正</strong>（错了怎么补救）。</p><p>一句话区分：上下文和工具让 Agent <strong>能做事</strong>，约束、验证、纠正让 Agent <strong>不做错事</strong>。生产级系统里，绝大部分代码属于后者——权限分类、上下文压缩、熔断器、错误恢复。</p><p>范式是层层包含的：软件工程 ⊂ 提示工程 ⊂ 上下文工程 ⊂ Harness 工程 ⊂ Loop 工程（跨轮次的持续自主运转）。当各家模型能力趋近，竞争优势就转移到这一层。</p><p>关于模型和 Harness 的消长，务实的立场是：<strong>模型还做不稳的，Harness 先补上；模型每内化一层，Harness 就卸下一层，去兜底新的能力前沿。</strong></p><hr><h2 id="三、上下文工程：能力上限的真正决定因素"><a href="#三、上下文工程：能力上限的真正决定因素" class="headerlink" title="三、上下文工程：能力上限的真正决定因素"></a>三、上下文工程：能力上限的真正决定因素</h2><p><strong>问题</strong>：模型够聪明，为什么在具体业务上还是不好用？</p><p><strong>思路</strong>：模型智力是基础，上下文质量才是上限。一个中等模型配上组织好的上下文，常常胜过顶级模型在信息匮乏下摸索。</p><p><strong>KV Cache 是硬约束，不是优化项。</strong> 前缀里有一个字符变化，整条缓存作废。所以三条铁律：系统提示词和工具定义定稿后不改；所有动态信息（时间、状态、计数）追加到末尾；永远用标准 API 消息格式（自己拼文本会偏离训练格式，削弱多步思考能力）。有团队在系统提示词里塞了一行当前时间，首 token 延迟从 0.5 秒涨到 3–5 秒，账单几乎翻倍。</p><p><strong>提示词写 SOP 而不是规则堆砌。</strong> 内容不变、只打乱组织结构，任务成功率能掉 30% 以上。业务规则要细到可执行，模糊规则会让同一个任务在不同时间得到不同分类。</p><p><strong>提示词太长就按需加载，这就是 Skills。</strong> 三层渐进式披露：元数据常驻（几百 token）→ 核心流程按需加载 → 细则引用子文档。关键是 <code>description</code> 写成路由条件（Use when / Don’t use when 加反例），”何时该用我”比”我能做什么”重要得多。</p><p><strong>把隐式状态显式化，这就是 Agent 状态栏。</strong> 上下文窗口是一台只有一半的检索引擎：检索极强，但没有”提炼层”。所以模型数不清自己打过几次电话——解法是在工具结果里直接写”本次是第 3 次”。状态栏用一条追加在末尾的消息承载任务进度、环境状态、工具计数。两条经验：用代码维护而不是让模型去总结（模型批量统计长历史反而不如 20 行正则）；光给读数不够，必须连”读数该怎么用”的策略一起给。</p><p><strong>膨胀了就压缩，但更该隔离。</strong> 压缩不只是省长度，更是把需要思考才能得到的结论变成可直接检索的知识；生产上是分层的（大输出落盘、噪声直接删、归档式摘要、最后才是全量压缩），且必须显式定义保留优先级——最容易丢的是早期架构决策和失败路径。更釜底抽薪的是隔离：让子 Agent 去翻十几个文件，只回传一句结论，几万 token 根本不进主上下文。</p><hr><h2 id="四、记忆与知识库"><a href="#四、记忆与知识库" class="headerlink" title="四、记忆与知识库"></a>四、记忆与知识库</h2><p><strong>问题</strong>：会话结束后，怎么让 Agent 记住用户、接上外部知识？</p><p><strong>思路</strong>：两个尺度——用户记忆（个体）和知识库（群体），共用底层技术（检索、压缩），面临同样的麻烦（冲突、过期、检索不准）。</p><p><strong>记忆设计有三套正交分类</strong>：存在哪里（轨迹 / 长期记忆 / 业务状态）、怎么存（从极简的 Simple Notes 到带来源背景和关系的 Advanced JSON Cards）、存什么（情景 / 语义 / 程序记忆）。取舍在简单性与表达力之间，成熟系统混合使用。再往外一步是”用户即代码”：把记忆变成带类型的可执行对象，能做聚合统计、冲突发现、约束执行这三件文本记忆做不了的事。</p><p><strong>检索是稠密 + 稀疏 + 重排序三件套。</strong> 稠密懂语义但会漏精确关键词，稀疏精确但读不懂同义表达，两路融合后再用跨编码器精排。索引前给每个文本块加”出自哪里”的前缀（上下文感知检索），检索失败率能降近一半。</p><p><strong>扁平检索不够时要结构化</strong>：RAPTOR 建知识树适合由宏观到微观，GraphRAG 建实体关系图擅长多跳推理和消歧。代价不小，只在确实需要跨文档综合时才值得。</p><p><strong>最终形态是双层</strong>：少量关键事实结构化后常驻上下文提供全局概览，海量原始对话按需检索取细节。只常驻会丢细节，只检索发现不了跨会话关联——<strong>主动服务</strong>这类能力只有两层叠加才落地得了。</p><hr><h2 id="五、工具：Agent-的手与眼"><a href="#五、工具：Agent-的手与眼" class="headerlink" title="五、工具：Agent 的手与眼"></a>五、工具：Agent 的手与眼</h2><p><strong>问题</strong>：怎么让模型准确、安全地使用外部能力？</p><p><strong>思路</strong>：五类工具——感知、执行、协作、事件触发（Agent 注册、外部触发）、用户沟通。</p><p><strong>描述比能力重要。</strong> 大多数调用失败的根因不是模型不知道工具能做什么，而是不知道它<strong>不能</strong>做什么。所以：写”何时用”而非”能做什么”，参数给具体例子而非规范名，说清返回值结构和执行代价，附 1–5 个真实示例。工具超过 100 个，再强的模型也容易选错。<strong>Agent 选错工具时先查描述，别急着换模型。</strong></p><p><strong>参数传递必须透明。</strong> 不能在模型不知情的情况下改输入或输出，否则会制造一个模型永远诊断不了的系统性故障（比如静默把中文引号转成英文引号，导致匹配永远失败）。</p><p><strong>MCP 解决互操作</strong>，代价是工具定义会吃掉大量上下文（几个服务器就可能有几万 token），所以要默认只给索引、按需查定义，工具多了还要做动态发现。</p><p><strong>执行侧的安全是多层防线。</strong> 输入验证快速失败、绝不”智能修正”；权限控制不能只有黑名单（<code>rm -rf /</code> 能靠变量展开绕过），要做命令的语义解析；危险操作用两种独立视角把关——<strong>提议者-审核者</strong>审开放式思考（两个能力相近但不同家族的模型），<strong>Sidecar</strong> 只审结构化调用数据（轻量模型够用，且刻意不读主模型的自由文本，以免被话术操纵）。沙盒要认清 <strong>venv 不是沙盒</strong>，真正的隔离是 OS 级、容器到 microVM 三级，且默认断网——掐断外传通道比识别每一次注入确定得多。</p><p><strong>异步是真实部署的常态，但模型训练假设同步。</strong> 折中办法是让模型在常态下看到完美同步的轨迹，只在被真打断时才插入占位符修补格式，并且只在紧急时才打断。事件按紧急度分三种处理：取消式、队列式、并行式。一句总结：<strong>真正的主动服务不仅需要 Agent 定时检查世界，更需要世界能主动通知 Agent。</strong></p><hr><h2 id="六、以-Coding-Agent-为骨架搭起来"><a href="#六、以-Coding-Agent-为骨架搭起来" class="headerlink" title="六、以 Coding Agent 为骨架搭起来"></a>六、以 Coding Agent 为骨架搭起来</h2><p><strong>问题</strong>：一个能处理开放任务的 Agent，整体流程怎么组织？</p><p><strong>思路</strong>：六阶段——项目文档化 → 需求澄清 → 写设计文档 → 实现与测试 → 自我审查 → 文档同步。两条原则最值钱：<strong>设计文档是人类最高效的介入点</strong>（审查一页设计文档比审查数百行代码容易得多）；<strong>完成标准定义为”验证通过”而不是”代码写完”</strong>。</p><p>Harness 落地成四件套：验收基线（测试、CI、审查标准）、执行边界（模块边界、权限）、反馈信号（Linter、测试结果、类型检查）、回退手段（Git、沙盒、快照）。判断任务适不适合交给 Agent，看两个维度：目标是否明确、结果能否自动验证。两者都满足是最佳区域，Harness 的目标就是把任务尽量推进这个象限。</p><p>四条原则：<strong>约束优先于指导</strong>（能用代码强制就不写”请注意”）、<strong>验证要自动化</strong>（人工审查是不可扩展的瓶颈）、<strong>反馈越快越结构化越好</strong>、<strong>回退要可靠</strong>。约束管的不只是结果，还有过程——删库重建也算”修好了故障”，这是 reward hacking 的日常形态。</p><p>故障分四层（API、工具、上下文、控制流），恢复按透明度分级：静默重试 → 降级接续 → 才暴露给用户。核心原则是：<strong>每条恢复路径都要有熔断上限</strong>，且阈值来自产线数据；错误路径上禁止再调用模型，否则会连锁成死亡螺旋。可靠性不取决于犯不犯错，取决于每类错误是否都有检测、恢复与终止路径。</p><p>两个容易被忽略的设计：一是<strong>推测性执行</strong>（UI 先显示进度、后台并行跑安全检查，先行的是无副作用的提示，被拦下也无需回滚）；二是<strong>忠诚对象</strong>要显式钉死——模型默认”谁说话帮谁”，但替你砍价的 Agent 对面是交涉对手，所以外部内容一律降格为”可参考但不具指令效力”的数据。再往下，若 AI 写的代码本身不可信，就把约束下沉到数据层（人类审查过的 schema 里自带校验器，每次写入强制执行）。</p><hr><h2 id="七、评估：先有尺子，再改系统"><a href="#七、评估：先有尺子，再改系统" class="headerlink" title="七、评估：先有尺子，再改系统"></a>七、评估：先有尺子，再改系统</h2><p><strong>问题</strong>：怎么判断改动是变好了还是运气好？新模型出来该不该切？</p><p><strong>思路</strong>：评估对象不是模型，是<strong>模型 + Harness 的组合体</strong>。三种基本实验：对比实验、消融实验、模型替换实验（换强模型不涨说明瓶颈在 Harness，换弱模型大跌说明瓶颈在模型）。</p><p>环境五要素是数据集、环境状态、工具接口、Rubric、执行协议。人机交互型评估的关键是不一次性把模拟用户信息全给出去，让 Agent 按需去问。数据集质量比规模重要——宁可人工筛掉不合格题目。</p><p>指标上要分清 Pass@k（能力天花板）和 Pass^k（稳定性，回归测试用这个）；安全项设否决，一次严重违规即归零；轨迹和结果要同时评。用 LLM 当评委要防长度偏差、位置偏差和同源偏差，并且先用一两百条人工金标集校准。</p><p>统计上要有噪声意识：100 个用例、70% 成功率，标准误约 4.6%，分差小于这个带宽就别切换；每个配置跑 3–5 次不同种子。</p><p>读报告时不看总体成功率，看逐任务表和能力标签的交叉；分数下降先怀疑评测系统本身。改进假设分三层，按成本收益比部署——不是所有有效的改进都该上（全局开启思考能让准确率涨 3 个点，但延迟翻三倍，很可能被否）。</p><p>最后，Rubric 和验证器可以直接变成强化学习的奖励函数，评估能接上训练；红线是评估集的题目必须与训练数据隔离。</p><hr><h2 id="八、后训练：什么时候该动模型"><a href="#八、后训练：什么时候该动模型" class="headerlink" title="八、后训练：什么时候该动模型"></a>八、后训练：什么时候该动模型</h2><p><strong>问题</strong>：Harness 做到位了还是不够，什么时候该训练，选 SFT 还是 RL？</p><p><strong>思路</strong>：三阶段代价差数量级——预训练学世界知识（最贵）、SFT 用示范对学格式与风格（最便宜）、RL 用任务加奖励学可迁移策略（常是 SFT 的几十倍）。</p><p>一句话概括：<strong>SFT 记忆，RL 泛化</strong>。SFT 倾向记住训练里的答案，环境一变就失效；RL 学的是策略，面对没见过的情况更稳。对比实验里，分布外场景下 RL 通常涨几个到几十个点，SFT 反而下降。</p><p>顺序是<strong>先形后神</strong>：SFT 先把格式立住（连 JSON 都产不稳时 RL 会完全失败），但不宜恋战，过拟合的损伤 RL 救不回来。转向 RL 的临界点是——再加示范数据也没用，因为瓶颈在 SFT 的优化目标本身。</p><p>优先级是<strong>基础模型 > 环境 > 算法</strong>。仿真环境够不够真实、示范和奖励信号质量够不够高，比选 PPO 还是 GRPO 重要得多。两个高频坑：不要用后训练记事实（那是 RAG 的活）；工具调用训练必须做 loss masking，屏蔽环境返回的 token，否则模型会去学”预测沙盒会输出什么”。</p><hr><h2 id="九、自我进化：不改权重也能长大"><a href="#九、自我进化：不改权重也能长大" class="headerlink" title="九、自我进化：不改权重也能长大"></a>九、自我进化：不改权重也能长大</h2><p><strong>问题</strong>：部署之后怎么让 Agent 越用越好，而不是每次重来？</p><p><strong>思路</strong>：自我进化即<strong>外部化学习</strong>——把知识和流程从参数和临时上下文里分离出来，变成可持久化、可检索、可复用的资产。前提是承认学习不会自动发生：注意力更像检索而非推理，所以学习必须被显式设计。</p><p>产物形态按性质选：纯事实 → 知识库条目；常用且参数复杂 → 专用代码工具；常变且涉及策略判断 → Skill 文档。</p><p>四条路径：从成功里学（把成功轨迹浓缩成策略摘要，入库判据是可迁移性）、从重复任务里学（工作流录制，但必须编译成带验证谓词的状态机，且入库前重置环境回放验证一遍，否则程序库会越攒越坏）、从失败里学（反思入库、建错误模式库和负面规则）、睡眠学习（离线整合记忆，检测矛盾、合并、剪枝）。</p><p>工具侧的进化是：先能按需发现工具（不必全量塞进上下文），再能自己创造工具。安全边界要一并设计——供应链攻击、能力漂移、工具质量退化，以及比会话内注入更隐蔽的<strong>记忆投毒</strong>（跨会话持续生效）。</p><hr><h2 id="十、能力边界的扩展"><a href="#十、能力边界的扩展" class="headerlink" title="十、能力边界的扩展"></a>十、能力边界的扩展</h2><p><strong>多模态与实时交互</strong>：语音有三种范式——级联流水线（可控、延迟叠加，需全链路流式化）、端到端全模态模型（延迟最低、可控性弱）、全双工模型（能边说边听、随时打断，最难训练）。取舍集中在思考架构上：快思考接住交互、慢思考产出答案，两者之间除了文本还能传意图、情感和规划。Computer Use 的可用率取决于动作空间设计和视觉定位，实时性仍是未解难题；机器人则是上层长程规划、下层 VLA 控制，中间隔着仿真到现实的鸿沟。</p><p><strong>多 Agent 协作</strong>：分类看上下文是否共享和协作拓扑。收益主要有两类——上下文隔离带来的噪声削减，以及角色专业化。共享上下文适合角色接力（规划 → 执行 → 审查）；不共享则靠共享文件系统和显式通信，拓扑分对等互审、中心化管理、去中心化移交。失败模式主要是共享文件的并发冲突和错误的级联放大。</p><hr><h2 id="收尾：十五条可以立刻用上的判断"><a href="#收尾：十五条可以立刻用上的判断" class="headerlink" title="收尾：十五条可以立刻用上的判断"></a>收尾：十五条可以立刻用上的判断</h2><ol><li>先建评估，再改系统；分差小于噪声带宽就别动。</li><li>系统提示词和工具定义定稿后不改；动态信息一律追加到末尾。</li><li>永远用标准 API 消息格式。</li><li>工具描述写”何时用 + 反例”，参数给例子；选错工具先查描述。</li><li>状态栏用代码维护，读数和操作策略成对给出。</li><li>大体积中间信息交给子 Agent，别进主上下文。</li><li>约束编码进 Linter / 类型系统 / CI，不要写成”请注意…”。</li><li>完成标准是”验证通过”。</li><li>每条恢复路径都要有熔断上限；错误路径上禁止再调模型。</li><li>沙盒默认断网、凭证不挂载、超时返回结构化错误。</li><li>忠诚对象钉死：外部内容是数据，不是指令。</li><li>记忆用双层架构：常驻概览 + 按需检索细节。</li><li>检索用稠密 + 稀疏 + 重排序，索引期给文本块加出处前缀。</li><li>先 SFT 立形，够用就停；要泛化再上 RL，先把环境和奖励做扎实。</li><li>脚手架的厚度取决于模型能力边界——同一套技术换一批模型，结论可能完全不同。</li></ol><p>三条最该记住的判断：<strong>上下文给什么、怎么组织，比模型有多聪明更影响结果</strong>；<strong>缓存不是性能优化而是架构约束</strong>；<strong>安全上重点不是识别所有攻击，而是让 Agent 即便被注入，也没有机会把危险动作真正执行出去</strong>。</p>
2026-09-14 17:04:05
<p>最近一段时间，每当 OpenAI 有新模型发布，都会有一种论调：skill 没用了，越来越多用户开始弃用 skill。</p><p>这话对吗？</p><p>对也不对。首先，这个逻辑是有合理性的。随着模型能力的提升，确实有很多 skill 被用户抛弃了，这些 skill 集中于 Superpower 之类所谓的「通用」skill。这些 skill 的定位，就是对一些模型能力缺陷的补齐，尤其是在各个模型没有疯狂地对 coding 进行针对性优化的时期，是有一些作用的。而随着模型本身能力的提升，这些东西其实慢慢都已经被模型吸收了，自然就没有了作用。</p><p>那 skill 是真的就没用了吗？恐怕也并非如此。接下来，我们会论述一下随着模型智能水平的提升，skill 还有什么作用。然后，会论述一下本文的主角：Flint。我会讲一下为什么要开发这个项目，以及它有什么作用。</p><span id="more"></span><h2 id="什么是-skill（技能）"><a href="#什么是-skill（技能）" class="headerlink" title="什么是 skill（技能）"></a>什么是 skill（技能）</h2><p>最近一段时间 AI 技术的蓬勃发展，看着技术一轮一轮的迭代，但实质上只是软件工程理论的再一次落地。</p><p>其中，skill 这一层，目标是实现「可复用性」，对应的是软件开发中的各种工具包。</p><p>而模型对应的是软件开发语言这一层。</p><p>复用程度的不同决定了一个功能是应该在语言层还是在工具包里。</p><p>比如，数组或者 map，就应该在语言里封装好，而不是你得引个第三方包才能用。而比如一个解析发票的逻辑，那么落到语言层里，就不合适了。</p><p>对应到 AI 当前的发展，skill 的定位就应该是这样的功能：有一定复用性，但复用性又不高、AI 没有足够的语料自主学会这个。</p><p>比如，公司内封装的工具包的使用方式，尤其是一些可能已经被淘汰掉的古早技术栈，模型拿不到足够的语料获取相关知识，相关知识只存在于相关开发人员的脑子里，这时候，就适合封装一批 skill 出来，成为团队固化的知识；</p><p>比如，你自己将自己的工作流固化出来的一些流程，比如我会用 Notion 管理工作任务，然后基于这个生成周报，那就可以封装成一个 skill 给 AI 使用；</p><p>再比如，我包了一个访问我带着真实 cookie 浏览器的 skill，在访问一些反爬比较强的网站时，就可以用这个 skill。就像这种 skill，包一个很简单，但如果想从网上下一个，却没那么容易。现在有些 agent 自己也会封装这样的能力，但用起来或多或少总会有一些不合心意。</p><p>所以，随着模型能力的提升，skill 并不会消失，但其起效果的范围会收敛到这些复用性不高不低的事上。不复用会很麻烦，但又不会有很普世的复用性。你下载下来别人的 skill，会发现不好用。</p><p>这也是我开发 Flint 这个项目的初衷，就是：把 skill 像个人资产一样管理。</p><h2 id="Flint-是什么"><a href="#Flint-是什么" class="headerlink" title="Flint 是什么"></a>Flint 是什么</h2><p>Flint 是我开发的一个本地优先的个人 AI Skills 资产管理器（官网：<a href="https://flint.lichuanyang.top/">flint.lichuanyang.top</a>）。一句话概括：把你散落在各个 Agent、各个项目里的 skill 集中管起来——统一打标签、搜索筛选、同名去重，再按需投放到每个 Agent 和项目自己的技能目录里。它由一个本地后端和一个 Web 前端组成，一条脚本就能启动；你的技能仓库对应磁盘上一个普通目录，各 Agent 的技能目录通过软链或复制从这个源头分发。从此技能只有一份本体，放在你自己的地盘上，用到哪投到哪。</p><p>界面上 Flint 分成六个模块，各管一件事：</p><ul><li><strong>技能库</strong>：浏览、搜索、过滤你所有的 skill，预览 <code>SKILL.md</code> 原文、编辑标签、追溯每个技能的来源；也可以在这里登记自有仓库和第三方只读仓库，把散在各 Agent 里的技能归集回仓库，或从任意目录批量导入。</li><li><strong>智能体</strong>：每个实际的技能目录一张卡片。在这里把某个 Agent 设为活跃、关联预设、逐个开关技能，甚至按单个技能切换软链还是复制。</li><li><strong>预设</strong>：一组 skill 套餐——显式成员加上关联标签命中的技能。预设没有开关，成员或标签一变，立刻分发到关联了它的活跃 Agent。</li><li><strong>项目</strong>：登记项目路径和标签，匹配的 skill 自动进入项目的 <code>.agents/skills</code> 目录（可以提交进 git，跨机器自包含）；项目里改出来的技能还能回写仓库。</li><li><strong>诊断</strong>：六个维度的体检——同步、重复、失效软链、配置、仓库、项目，问题集中列出来，确认后一键修复。</li><li><strong>设置</strong>：默认安装方式（软链 / 复制）、复制模式的增量同步 watcher、自定义 Agent、日志查看。</li></ul><p>前四个模块串起来就是「收拢 → 整理 → 投放」的主路径，诊断和设置是兜底：出了状况去诊断页看问题出在哪，投放的默认姿势在设置里定。</p><p>下面两张界面截图可以建立点直观印象（均为演示数据）。技能库页：所有技能集中在一处，卡片上直接看描述和标签，顶栏按来源、标签筛选：</p><p><img src="/img/flint-library.jpg" alt="技能库：集中浏览、搜索、按来源和标签筛选"></p><p>诊断页：六个维度的体检结果一屏列清。截图里「重复技能」的两条警告，正是同一个技能在自有仓库和第三方来源各存了一份，等着被收编成一份：</p><p><img src="/img/flint-health.jpg" alt="诊断页：六维体检，重复来源集中列出"></p><h2 id="为什么需要它"><a href="#为什么需要它" class="headerlink" title="为什么需要它"></a>为什么需要它</h2><p>除了上文说过的部分，还有一个现实因素，让我更需要对 skill 进行精细化的管理。</p><p>就是我需要经常性地切换不同的 agent。现在赛博菩萨很多，今天 WorkBuddy 放个免费模型，明天 TraeWork 发一批免费积分，千问、小米，这些也都不甘落后。这些免费的 token，不用白不用。但在经常切换 agent 的情况下，skill 的管理就成问题了。</p><p>今天我可能在 WorkBuddy 里实现了写日报的 skill，明天打开 TraeWork，发现用不了。</p><p>现在固然有 npx 等各种工具管理 skill，但我试了一下，都不太趁手。现在市面上的绝大多数 skill 管理工具，核心思路还是基于分享与分发，目标是建设一个大而全的 skill 仓库，然后安装到用户自己的各个 agent 里。</p><p>这样会带来几个非常显著的问题。</p><ol><li><p>就是我们前边说的复用性问题。别人的 skill，下载下来通常运转得不会特别好，相信大家对于这一点或多或少都应该有些感受。而另一方面，让我们回到文章一开头，如果一个 skill 真的复用性非常好，开箱即用，那它大概率会被吸收进模型本身，反而没有必要作为一个 skill 存在。</p></li><li><p>切换 agent 的成本问题。npx 能一次性把 skill 安装到各个现存的 agent 里，但一旦使用新 agent，这个操作就很麻烦了。另一个重大问题是自己的 skill，无法纳入到 npx 等工具的管理中，会给切换 agent 带来巨大负担。</p></li><li><p>skill 使用的成本问题。比如一个公司内的 skill 集，可能有一两百个 skill，里边前端、后端、设计、运营各种 skill 都有，你可能只能用到其中一小部分，但如果没有精细化的管理手段，就只能把所有 skill 都安装进来了。这样，几乎所有主流 agent 都会把每个已安装技能的名称和描述注入系统提示词，供模型自行判断要不要调用。按每条描述 50～100 token 估算，200 个 skill 就是每次对话 1 万～2 万 token 的固定开销，再乘上 agent 一次任务的几十个来回，账单相当可观。而且开销还在其次，更麻烦的是检索效率：候选列表越长、无关条目越多，模型选错技能或干脆漏选的概率就越高，就像在塞满了别人工具的工具箱里找自己那把扳手。</p></li></ol><p>基于上述原因，我开发了 Flint 这个项目。为什么用这个名字，灵感来自于 Obsidian。</p><p>Obsidian 在官网上用三句话概括过自己的理念：<strong>Sharpen your thinking</strong>（磨砺你的思考）、<strong>Your thoughts are yours</strong>（你的想法属于你自己——笔记私密地存在你的设备上，别人读不到，连官方也读不到）、<strong>Your knowledge should last</strong>（你的知识应当长存——使用开放文件格式，你永远不被锁死，长期拥有自己的数据）。</p><p>Flint 沿用了同一套「以石喻工具」的命名脉络：黑曜石（Obsidian）是天然锋利的火山玻璃，远古人类把它打制成刀刃；燧石（Flint）是与黑曜石并肩的另一块「工具之石」，只是把打磨的对象从「知识」换成了「技能」。燧石的两层特性，正好对应这个项目的两个动作——<strong>打制（knapping）</strong>：把散落的 skill 收拢、去重、打标签，敲成精确趁手的工具；<strong>取火（spark）</strong>：把技能投放、分发到各个 Agent 与项目目录，让它们真正被点燃、开始干活。</p><p>你收藏的每一项技能，都是等待被击出火花的一块燧石。</p><h2 id="核心理念：像-Obsidian-管理知识一样管理技能"><a href="#核心理念：像-Obsidian-管理知识一样管理技能" class="headerlink" title="核心理念：像 Obsidian 管理知识一样管理技能"></a>核心理念：像 Obsidian 管理知识一样管理技能</h2><p>正是沿着和 Obsidian 一脉相承的思路，Flint 把那三条理念逐条搬到了技能管理上：</p><table><thead><tr><th>Obsidian 的理念</th><th>Flint 的对应</th></tr></thead><tbody><tr><td>本地即私有</td><td>技能只以普通文件存在你的本地磁盘，无云端、无账号、无上报</td></tr><tr><td>开放格式、永不锁定</td><td>skill 本体就是磁盘上的 <code>SKILL.md</code> 目录，随时可打开、编辑、diff、用 git 提交；换工具、换生态，这份资产照常带走、照常使用，不被 Flint 绑定</td></tr><tr><td>磨砺你的思考</td><td>收拢、去重、打标签，再一键投放到需要它的 Agent 与项目里，让个人技能库越攒越趁手</td></tr></tbody></table><p>落到具体设计上，还有两个值得一提的取向。其一，元数据尽量贴合开源生态共识：标签优先写在每个 <code>SKILL.md</code> frontmatter 的顶层 <code>tags</code> 字段上——这个位置能被 Claude Code、agentskills.io 等 40+ 工具原生读取，并随技能目录一起被 git 版本化，而不是存进某个私有数据库。其二，尽量降低生态碎片化：同名技能多来源时自动去重、只保留一份，重复、分歧、失效引用都集中到诊断页看清并就地处理，避免同一份 skill 在你的环境里以多个副本反复膨胀。</p><h2 id="最小通路：四条步骤跑通"><a href="#最小通路：四条步骤跑通" class="headerlink" title="最小通路：四条步骤跑通"></a>最小通路：四条步骤跑通</h2><p>Flint 是个跑在本机的小工具（Node.js ≥ 20），官网 <a href="https://flint.lichuanyang.top/">flint.lichuanyang.top</a> 上有介绍和截图，用法文档写得比较全，这里只把第一次使用的四条必要步骤捋一遍：</p><ol><li><strong>安装</strong>：仓库根目录执行 <code>./start.sh</code>，脚本会自动检查 Node 版本、依赖与端口占用，首次运行自动 <code>npm install</code>，装完打开浏览器即可（前端 <code>localhost:5173</code>，后端 API <code>localhost:8787</code>）。</li><li><strong>登记仓库</strong>：仓库是 skill 的集合与事实源，对应磁盘上一个目录。自有仓库正常维护；第三方仓库作为只读来源登记，里面的技能随时可以被自有仓库「导入」收用。</li><li><strong>新建预设</strong>：一个预设就是一份 skill 套餐——显式成员并上关联标签命中的技能。</li><li><strong>把预设应用到 Agent</strong>：在某个 Agent 的详情页先把它「设为活跃」，再关联刚建的预设。此后预设的成员或关联标签一变，已关联它的活跃 Agent 会立刻拿到这套 skill。</li></ol><p>至此，「登记仓库 → 配预设 → 投给 Agent」的最小通路就打通了，你的技能已经可以跨 Agent 工作。再往后的归集、接管、项目专属技能、六维诊断，都是锦上添花。</p><p>预设详情页长这样（演示数据）：上半部分是当前状态——这个预设最终会开启哪些技能、已经应用到了哪些 Agent；下半部分是两种调整方式，「按标签纳入」和「按技能纳入」取并集，改动立即生效：</p><p><img src="/img/flint-preset.jpg" alt="预设详情：显式成员与按标签纳入取并集，改动即刻分发"></p><h2 id="小结"><a href="#小结" class="headerlink" title="小结"></a>小结</h2><p>以上就是我对于未来 skill 变化趋势的理解，和开发 Flint 的缘由。如果大家认可这个思路，欢迎来试用产品并提出建议。</p><p>项目已经开源，官网在 <a href="https://flint.lichuanyang.top/">flint.lichuanyang.top</a>，代码仓库在 <a href="https://github.com/lcy362/flint">GitHub: lcy362/flint</a>，clone 下来执行 <code>./start.sh</code> 就能跑起来体验；<code>README.md</code> 里有完整的使用指引，欢迎试用后提 issue 交流。如有帮助，还请帮忙点个star。</p>
2026-07-01 17:16:24
<p>之前写过一篇文章：<a href="https://lichuanyang.top/posts/26060/">https://lichuanyang.top/posts/26060/</a> . 教大家构建与Agent无关的工作流，随时能拉起不同的Agent工作，从而能顺畅用上各个Agent提供的免费、试用套餐。这么实践下来，一个明显会变得繁琐的事情就是对于skill的管理。因此，我又写了一个工具，实现在不同Agent、不同项目间管理skills.</p><span id="more"></span><p>鉴于目前Agent的生态还比较凌乱，大家各干各的，skill的存放目录也自己定自己的。</p><p>比如 Cursor 放在 <code>~/.cursor/skills</code>，Claude Code 放在 <code>~/.claude/skills</code>，Trae 放在 <code>~/.trae/skills</code>，OpenCode 放在 <code>~/.config/opencode/skills</code>，还有 Windsurf、Qoder、Hermes 等等，每家都有自己的路径约定。</p><p>社区也在试图定义通用的.agents/skill这样目录，有点作用，但不大。</p><p>当然，skill管理的问题，也不全是使用多Agent带来的。因为skill这种东西，天然就就有非常大的适用范围区别。有的skill是适用于公司的项目的，有的是适用于自己的项目的，有的适用范围还更窄一点，只适用于若干范围内的几个项目，还有的skill, 比如汇总新闻的，我想只配在某个agent里。</p><p>你要是问，不对skill做这些精细化的管理，行不行？那确实也没什么大问题，无非就是agent每次检索技能，多花点token. 但做技术的强迫症，还是希望把这些东西管的细一些，在不需要agent调起的地方，就压根别让agent能看到这些skill.</p><p>基于此，设计了pks这个工具。核心思路是在一个集中的地方管理所有的skill, 然后，按照需求，将skill写入agent的skill目录或者项目目录下。</p><p>具体来说，支持以下功能</p><p><strong>全局管理</strong>：所有 skill 集中存放在 <code>~/.local/share/pks/skills/</code> 下，用 <code>pks list</code> 查看，用 <code>pks new</code> 创建新 skill。</p><p><strong>项目级安装</strong>：在项目目录下执行 <code>pks init</code> 初始化后，可以用 <code>pks install</code> 把全局 skill 安装到当前项目的 <code>.skills/</code> 目录。</p><p><strong>Agent 级安装</strong>：用 <code>pks install-to <agent> <skill></code> 把 skill 直接装到指定 agent 的 skill 目录（比如 <code>~/.cursor/skills/</code>）。</p><p><strong>双向同步</strong>：在项目里改了 skill 文件，用 <code>pks push</code> 把改动推回全局库。</p><p>实际使用上，我大概有这么些使用场景：</p><p>有一些skill是小范围适用的，比如相关的几个有限的工程，这时候，我不会将skill放到agent的配置里，而是会放到项目中，使用pks install命令，可以把本地技能库中的skill, 放到工程目录下。然后可以在AGENTS.md文件中指引agent去skill目录下找技能，对于支持项目内技能的agent, 也可以使用pks link命令，将agent对应的项目内技能目录，比如.opencode/skills, 软链到skills目录下；</p><p>有些skill, 比如收集新闻的skill, 我只想让它在部分agent中出现，这样就执行pks install-to命令, 将其装到agent的skill目录下。</p><p>有时候skill文件需要修改，我会先在某个项目下进行修改，然后执行pks push, 将命令写回技能库。</p><p>这样，对于skill, 就有了一个比较妥善合理的处理流程。</p><p>项目地址在： <a href="https://github.com/lcy362/personal-skills-manager">https://github.com/lcy362/personal-skills-manager</a> ， 欢迎试用。 大家有什么其他关于skill管理的经验，也欢迎提出。</p>
