导读： 你有没有试过把文章、播客、想法全部存进笔记软件，然后再也没打开过？
这不是懒，是系统设计的问题。把东西存进去却没有反馈机制，知识库只会变成一个漂亮的垃圾桶。
这篇文章讲的是一个不同的思路：让 Obsidian 结合 Claude，建一个每天自动变聪明的知识系统——你只管输入，连接这件事交给 AI 来做。

大多数知识管理系统为什么都失败了

先说失败模式，因为很多人都踩过坑。

第一个问题：捕获太费劲。每次保存一篇文章，还要手动打标签、分类、写摘要。这在认知负担高的时候根本坚持不下去，两周之后习惯就断了。

第二个问题：没有连接层。笔记之间是孤立的。三月份存的一篇文章和今天碰到的问题可能直接相关，但没有任何机制帮你发现这个关联。

第三个问题：没有理由回来看。如果知识库不主动推送东西给你，你就得记得去拉。没人记得住，库就成了「偶尔搜一下」的工具，而不是思考伙伴。

用 @cyrilXBT 的话说：一个从不回话的第二大脑，不是第二大脑，只是一种有条理的忘记方式。

这套系统针对这三个问题逐一解决。

四层架构：每一层只做一件事

整个系统分四层，逻辑清晰：

第一层：捕获层

负责把信息自动拉进系统，你不用手动做任何事。

• Readwise：文章高亮自动同步，连 Kindle、Twitter 书签、Pocket 都覆盖

• Airr：播客片段，手机一摇就剪

• Whisper：语音备忘，录音丢进去自动转文字

• Telegram Bot：在路上冒出的想法，发给 Bot 直接进库

这一层配好之后就不用再碰。

第二层：管道层（N8N 自动化）

N8N 监听每个捕获源，有新内容自动格式化成 Markdown 文件，存进 Obsidian 对应目录。不用手动归档，不用复制粘贴。

第三层：Obsidian 本地存储

就是本地一堆 .md 文件。这层是系统的「地基」，所有东西永久存在这里，不删。完全在本地，不依赖任何云服务，数据主权在你手里。

第四层：Claude 智能层

读你的库，找连接，写每日简报，回答关于你自己思维的问题。这是把存档变成思考伙伴的那一层。

五个文件夹，足够了

文件夹结构故意设计得很简单：

保持简单是有意为之。文件夹越复杂，存东西的时候就越容易卡在「这个到底放哪」，慢慢就不用了。

CLAUDE.md：整个系统最重要的文件

没有这个文件，Claude 每次启动都是一张白纸，不知道你是谁、在做什么、想要什么。

有了它，Claude 等于有个背景板——读过你几个月的笔记，知道你现在在搞什么项目，知道你的思维习惯。

直接抄这个模板开始用：

Current Projects 和 What I'm Reading 这两块每周一更新，五分钟。这个习惯决定了 Claude 的回答是不是还在点子上。

每天早上的自动简报

每天你坐下来开工之前，系统已经把简报准备好了。不用你去问，N8N 在早上 6 点自动跑，结果存进 /inbox/brief-日期.md。

把这个 prompt 放进你的 N8N Claude 节点：

三个部分设计得有意思：连接是把你没注意到的东西挖出来，模式是帮你看清楚自己最近在想什么（往往你自己说不清），问题比任务更有价值——一个好问题比十个待办事项更能推进思考。

每周深度合成

每天简报是「发现连接」，每周合成是「建立观点」。建议固定在周一花 15 分钟跑一次。

第二点「矛盾」最有价值——Claude 会从你自己的笔记里找出你现在相信的和你之前存的东西之间的矛盾，等于强迫你直面自己想法的漏洞。

六步搭建清单

按顺序来：

1. 1建 Obsidian 五目录结构：Inbox、Notes、Ideas、Projects 四个文件夹 + 根目录 CLAUDE.md。不要加更多文件夹，先跑起来再说。

1. 1连接 Readwise：Readwise 有 Obsidian 原生插件，开启之后你在任何地方的高亮自动进 Notes 文件夹。

1. 1搭 Telegram 捕获 Bot：用 Claude + N8N，大概 30 分钟搞定。从此手机上冒出的任何想法发给 Bot 就进库了。

1. 1写 CLAUDE.md：用上面的模板，诚实填写。Claude 输出质量直接取决于这个文件的质量。

1. 1配置每日简报 N8N 自动化：工作日早 6 点运行，输出存到 inbox 文件夹，先于其他事情读它。

1. 1周一日历里锁定 15 分钟做周度合成：现在就加进去，不要等「库丰富一点再说」。库永远不会「太空」，空库照样能找到值得想的东西。

复利效应从什么时候开始显现

用了一个月：感觉有用，每天简报偶尔冒出来惊喜。

用了三个月：开始感觉不一样。Claude 把三个月前的笔记和今天的问题连起来，你自己早忘了那条笔记。

用了六个月：有一整套关于你如何思考的记录。每个你当时相信但后来改变的观点，每个你一直在想但最终想清楚了的问题，每个在读了大量内容之后才浮现的规律。

越早开始，积累的连接越多，系统对你思维方式的理解越深。这个没什么捷径，只有时间能给。

• 大多数知识库失败的原因：捕获有摩擦、没有连接层、没有理由回来看

• 这套系统的解法：Readwise/Airr/Whisper 自动捕获 + N8N 管道 + Obsidian 存储 + Claude 智能层

• 最关键的文件是 CLAUDE.md，每周更新两个字段就够

• 每天早 6 点自动简报：3个连接 + 1个模式 + 1个问题

• 每周 15 分钟深度合成：挖矛盾、找知识盲区、确定本周最高价值动作

• 今晚先存 5 条笔记，感受一下 Claude 发现连接那一刻——系统就活了

参考链接

• 原推文（CyrilXBT）：https://x.com/cyrilXBT/status/2052235121416188114

• Readwise 官网：https://readwise.io

• N8N 自动化工具：https://n8n.io

• Obsidian 官网：https://obsidian.md

前段时间，Anthropic 公布了 Claude Code 比赛的六组获奖作品。

这是 Claude 和 Cerebral Valley 联合办的一场黑客松，规则是：用 Opus 4.7 + Claude Code，一周时间，做个东西出来。

看完这六个项目，我发现：没有一个是「再做一个聊天机器人」。

一个土耳其医生做了虚拟诊室，让医学生在 AI 病人身上练手；一个法国人做了电路板维修工具，读完 80 页原理图后直接在主板上画诊断路径；一个智利大学老师做了编程教学平台，学生不先写清楚自己要做什么，编辑器就锁着不让你碰。

还有一个智利小伙子，拿他木匠老爸三十年的手艺，训了个修墙的 AI。

下面，我们就一个一个地来看，或许会给你一些启发。

AI 病人

金奖给了 MedKit，来自土耳其的 Bedirhan Keskin。

他本身是个执业医生，但过去四年一直在做软件工程。他做这个项目的出发点，来自于自己的亲身经历：

“ 刚从医学院毕业的时候，最缺的就是实战经验。真实的病人不会按教科书来。我和很多同学刚到急诊科的时候，都挺手忙脚乱的。

MedKit 是一个语音驱动的虚拟诊室。系统会生成 AI 病人，医学生通过语音对话来问诊、开检查、看影像、做诊断、开处方。

每次问诊结束后，系统会根据最新的临床指南，给你的沟通能力、病史采集和临床推理逐项打分，每个扣分点都附带文献引用。

一些 AI 病人的例子：

一个 AI 病人说自己春天咳嗽加重、夜里喘息，医学生开始追问过敏史；另一个病人血压计显示 188/120，伴头痛，降压药停了一周；还有个肩膀疼的、一个拉肚子的……

不同的病例、不同的症状分支、不同的诊断陷阱。

技术实现上，Bedirhan 用了 Claude Managed Agents。

一个 Opus 4.7 驱动的「主治医师」Agent，同时管着病人角色扮演、观察者评估和问诊复盘三个子 Agent。

他提到 Opus 4.7 在长时间会话中不跑偏，所以他直接让 Agent 自动生成了整个病例库：病史分支、金标准诊断、评分标准，每一条都能追溯到真实存在的临床指南。

“ 在 AI 身上犯所有的错，然后再去面对真正的病人。

80 页原理图

银奖是来自法国的 Alexis Chapellier 做的 Wrench Board。

Alexis 是个自学成才的开发者，一直在为维修行业做工具。

先来介绍一个背景和数字：全球每年大约有 5000 万吨电子产品变成垃圾。

但其中很多并非修不了，而是板级维修的知识掌握在极少数人手里。

Wrench Board 想做的事，用 Alexis 自己的话来说就是：

“ 我为「剩下的我们」做了这个工具。

你导入一块主板的照片和原理图 PDF，而原理图有时候 80 多页，密密麻麻的电路图、元件参数、连接关系。Wrench Board 用 Opus 4.7 的视觉能力分批并行读取，两分钟内，就编译成了一个可查询的电气知识图谱。

25 个元件按功能分类，33 种可观测症状映射到故障机制，10 条诊断规则，每条都有可验证来源。

然后就到了最关键的部分：你可以直接跟 Agent 对话，它会在主板照片上一步一步画出诊断路径。

该量哪里、该测什么值，直接标在板子上。

而且，这个 Agent 还……认识你。

它会记录你的工具清单和维修经验，如果你没有热风台，它不会让你去做 BGA 返焊，每次成功维修，你的技能档案自动升级。

而且它对每块板子也都有记忆。之前修过哪里、试过什么方案、踩过什么坑，下次打开新对话的时候全都还在。

为了防止 AI 乱说，Wrench Board 做了一层硬约束：Agent 说出的每个元件编号都必须来自工具查询，没查到的编号会被服务端过滤掉，到不了你的屏幕。

Alexis 在视频结尾说：

“ 当一个拿着万用表的普通技术员，能做到昨天只有 OEM 售后中心才能做的事，「维修权」才算真正落地了。

项目已经在 GitHub 开源。

先想后写

铜奖是来自智利的 Paula Vasquez-Henriquez 做的 Maieutic。

Paula 是智利发展大学（Universidad del Desarrollo）计算机科学系的副主任，也是 AI 方向的博士生。

她在大学教了六年入门编程课，带过 200 多个学生学 Python。她在视频里讲了三个反复出现的场景：

一个学生从 LLM 上复制了一段代码，不知道这代码干嘛的。另一个随便扫了眼题目要求，直到测试报错才发现自己漏了什么。

而第三个，还没想清楚要解决什么问题，手就开始敲了。

三个学生都交了作业，倒是都能及格。

但没有一个人学到了真正重要的那个东西。

Maieutic 的做法是：写代码之前，先把编辑器上把锁。

学生得先用自己的话描述「这个程序应该干什么」，AI 读完之后会追问那些没说清楚的地方。只有当 spec 足够清晰了，编辑器才解锁。

编辑器打开后，自动补全是关的。学生可以问 AI 某个函数的语法，AI 会回答。但如果学生问「我该怎么做」，AI 会引导你思考，不会直接给答案。

提交代码后，AI 会把学生最初写的 spec 和实际代码对齐，让学生自己解释中间的差距：你说你要做 A，但你实际做了 B，这个 gap 在哪？

“ 在大学禁 AI 并非正确的做法。未来的程序员，大部分时间都在写 prompt。但好的 prompt 来自于理解你要构建什么、什么可能出错、以及结果对不对。

而

对教师来说，Maieutic 还提供了一个以前不曾有过的视角：一个能看到学生「思考过程」的实时面板。

不是看分数，是看每个学生此刻卡在哪里、在怎么推理、哪些错误反复出现。

“ 第一次，老师有了一份记录，记下的是学生到底怎么想的，而不只是答案对不对。

Paula 指出，一个好老师需要好几年才能积累出对学生常见思维误区的直觉。Maieutic 第一次布置作业的时候就能给你这个。

因为 Opus 4.7 能分辨出学生是在「推理」还是在「猜」。

木偶剧场

最佳创意奖，则给了来自丹麦的 Rene Hangstrup Moller 做的 Virtual Puppet Theater。

这是六个项目里，画风最为不一样的一个。

你用手对着摄像头比划，屏幕上的木偶就跟着动；你说话，木偶也说话；你说「给 Bob 戴个王冠」，王冠就出现了；你说「我们去海滩吧」，背景就换成了沙滩。

你说「给我一顶冰淇淋帽子」……嗯，它也真给你戴上了。

（你的第一反应可能是：这也太适合哄小孩了吧。）

技术栈方面拆解如下：

手部追踪用的 MediaPipe，检测手指关节的 3D 位置来驱动木偶；语音识别用了浏览器原生的 Web Speech API，免费、够用；语音合成用的 11 Labs Flash，比浏览器自带的要有表现力得多。

引擎底下跑着两个模型，共享一个缓存。

日常对话用 Haiku 保证响应速度，道具生成用 Opus 保证创意质量。有些道具是预设的 Three.js 模型，但像冰淇淋帽子这种，是 Opus 实时用基础图形组合拼出来的，你第一次说出来的时候它才去生成。

Bob（那个木偶）在视频结尾自己作的总结：

“ 一个用于玩耍的交互界面，一年前还不存在。

木匠之子

「Keep Thinking」特别奖给了来自智利的 Benjamin Torralbo 做的 MaestrIA。

这个项目的背景故事，可能是六个里面，最让人能够记住的。

Benjamin 的父亲 Juan Rodrigo Torralbo，做了三十年木匠，其中八年在修复智利奇洛埃岛上被列为联合国世界遗产的木教堂。

但在智利的体制里，没有大学文凭，你修过再多世界遗产，你也是全隐形人。

“ 智利有超过 28 万名非正式建筑工人，没有任何途径能展示自己的手艺。我爸修复了联合国世界遗产教堂，可没有大学文凭的他，在系统里根本不存在。

Benjamin 做 MaestrIA，就是要把他父亲这样的手艺人的知识数字化。

“ 工具是我做的。知识是他的。

使用方式是：拍一张受损墙面的照片，输入你的位置。

Opus 4.7 开始分析，而且推理过程是实时展示的，不是在转圈等。先观察，再诊断，就像一个老师傅到了现场，得先看一圈再开口。

分析完后，AI 会给你四个答案：修什么、你所在地区大概花多少钱、需要多长时间、不修会怎样。

接下来才，系统会推荐你附近的手艺人。

选一个之后，第三个 Agent 自动帮你写一条 WhatsApp 消息，用智利本地西班牙语，附上完整诊断报告。

“ 你不再是一脸懵地跟工人说「我墙湿了」。你手上拿着诊断报告。客户不会被乱开价，有手艺但不会推销自己的工人也能接到活。

分析过程中还有个有点意思的环节：系统会模拟不同工种的专家辩论。

木匠 vs 泥瓦匠，用智利西班牙语各自论证自己的修复方案。另一个 Agent 则跑去当地建材超市 Sodimac 和 Easy 实时查价，验证预算是否靠谱。

一个报价没有实际价格支撑，说了也等于没说。这一步想得挺周到的。

Benjamin 还把 MaestrIA 拿给他爸进行了测试，一共 12 张照片，12 个诊断。

结果是：与三十年老师傅判断的吻合率：81%。

工厂老师傅

最佳 Managed Agents 使用奖，则给了法国的 Idriss Benguezzou 和 Adam Hnaien 做的 ARIA。

ARIA 解决的是工业维护领域一个老问题：

“ 在每个工厂、每个车间、每个水站里，总有那么一个人。他能听出机器声音哪里不对劲，他能在机器坏之前两天就知道它要坏了。他就是知道。然后他退休了，这些知识就永远消失了。

传统的工业维修管理系统部署成本 50 万美元起，需要半年的专业咨询。结果就是，超过一半的工厂压根不装，等机器坏了再说。

ARIA 用了五个 Agent 各司其职，像一支维修团队一样层层传递工单。

演示场景是一个矿泉水灌装厂：一条线，五台设备。把设备手册丢给 ARIA，Opus 4.7 的视觉能力读完手册，问了三个问题，系统就上线了。

其中一个场景是：瓶盖机报了一个振动异常警报，但 ARIA 没有立刻发工单。它查了上下文，发现振动值其实在下降，并非异常。

并给出结论：无需处理。

大多数系统到「发了警报」就结束了，而ARIA 多走了一步：它在判断这个警报值不值得理。

但如果真的出故障了，处理链路就有所不同了。

检测 Agent 发现异常后，调查 Agent 接手，启动 Opus 4.7 的 extended thinking。它会写一段 Python 代码，在 Anthropic 的云端沙箱里跑了一次回归分析，从原始信号中算出设备的退化速率。

精确的数据会直接进入工单。技术人员拿到手的已经不再是一句「振动异常」了，是一张详细的维修表：根因分析，加上一步步的修复建议。

并且，它还拥有记忆。

灌装机又出了一次类似的振动异常，ARIA 翻出三个月前 Tom Anderson 处理过的那个 case，找到当时的修复方案和零件编号，直接告诉操作员：上次就是换了这个零件好的。

5 个 Agent 共享 17 个工具，通过 MCP 协作。日志、操作员的班次笔记、信号趋势、KPI、历史故障……全部汇入每台设备背后的知识库。

这个知识库是从设备手册和操作员的实际经验中一起构建的。

用 ARIA 团队的话说：那个「什么都知道的人」，再也不会因为退休而消失了。

手艺的数字化

六个获奖项目来自五个国家，覆盖医疗、维修、教育、工业、创意五个不同领域。

这些项目有一个共同的内核：它们都在把原本锁在少数人脑子里的专业知识，变成更多人能触及的工具。

板级维修经验锁在少数硬件工程师手里；临床直觉锁在资深医生的脑子里；工厂维护知识锁在那个「什么都知道」的老师傅心里；木工手艺锁在一个没有大学文凭的匠人手上。

人类文明里有大量这样的知识。

它们不在论文里，不在教科书里，不在任何数据库里。

它们只存在于某一个人的手感里、直觉里、几十年累积出来的判断力里。

这些知识，一直在消失。

老师傅退休了，手艺传不下去了，临床直觉随一代人老去而失传。没有人宣布它的死亡，也很少有人意识到自己失去了什么。

这六个项目背后的指向是：AI 可以接住这些正在断裂的经验，让它变成一种工具，一种传承。

这也许是 AI 能给世界留下的，一份不那么显眼、但足够持久的东西：让那些本会被时间抹去的人类经验，留下来。

因为在 AI 到来之前，这些知识和声音，因为太过于不起眼和长尾，而被鉴定为没有价值，从而忽略。

而借助 AI 来做出这些项目的人，也不是什么硅谷连续创业者。

他们是，一个土耳其医生，一个智利大学老师，一个木匠的儿子。

他们可能，就是你。

相关链接：

•  获奖公告：https://x.com/claudeai/status/2049523899918934384 

•  黑客松活动页：https://cerebralvalley.ai/e/built-with-4-7-hackathon 

•  MedKit 演示 / GitHub：https://www.youtube.com/watch?v=6bN6hnx-A2A / https://github.com/bedriyan/medkit-app 

•  Wrench Board 演示 / GitHub：https://www.youtube.com/watch?v=OZ2D_p82z6w / https://github.com/Junkz3/wrench-board 

•  Maieutic 演示 / GitHub：https://www.youtube.com/watch?v=IJ9FyX2xwWA / https://github.com/bcanata/maieutic 

•  Virtual Puppet Theater 演示 / GitHub：https://www.youtube.com/watch?v=qLuGU4PQNss / https://github.com/rhmoller/virtual-puppet-theater 

•  MaestrIA 演示：https://www.youtube.com/watch?v=rkH4AjoTL5Q 

•  ARIA 演示 / GitHub：https://www.youtube.com/watch?v=Hen24w2Jyz4 / https://github.com/zestones/Aria 

•  Claude 开发者通讯：https://claude.com/newsletter/developers 

2026 年 4 月中旬，Anthropic 发布了 Claude Design，整个设计圈都炸开了锅。

只需一句话描述，就能直接交付可交互的 HTML 设计稿，无需 Figma，无需 Photoshop，甚至无需懂设计。这种「从文本到成品」的体验，让无数人看到了设计行业的未来。

但高兴没几天，现实就给了大家一记闷棍：Claude Design 仅对付费用户开放预览，且完全闭源，所有数据必须上传到 Anthropic 云端，不能换用其他模型，也无法自托管。

这哪里是工具，这分明是把创作者锁进了一个漂亮的笼子里。

但是开源社区永远不缺大牛，nexu.io 创始人 Tom Huang 在 GitHub 上开源了一个 Claude Design 平替项目：Open Design 的项目。

开源仅仅 5 天，已经斩获了 18.2K 标星！涨势喜人，被开发者称为 "Claude Design 的真正开源杀手——甚至更强"。

它没有选择从头训练一个 AI 模型，而是走了一条更聪明、更开放的道路：不创建新的 AI 代理，而是让你电脑上已有的编码代理（Claude Code、Codex、Cursor、Gemini 等）直接变身设计引擎。

项目简介

Open Design 是一个本地优先、可部署到 Vercel、每一层都 BYOK（自带密钥）的开源项目。

它的核心设计哲学非常简洁：我们不造 Agent，你的已经够好了。

它不是简单地把 Claude Design 的 Prompt 抄过来，而是完整复刻了 Claude Design 的核心体验，包括：

• • 结构化的交互式提问流程

• • 品牌级设计系统约束

• • 实时 Todo 流 + 五维自省批判机制

• • 沙盒预览 + 一键导出多种格式

• • 真实的文件系统交互

当我们输入「帮我做一份杂志风的种子轮 pitch deck」，AI 不会立刻开始生成像素。相反，Open Design 会先弹出一个交互式问题表单，帮你明确需求细节；然后从 5 套精挑的视觉方向中推荐一个；接着在 UI 中显示一张活的 TodoWrite 计划卡片；同时在磁盘上构建出一个真实的项目目录，里面有 seed 模板、布局库、自检 checklist。

Agent 强制读取这些文件，对自己的输出跑一轮五维评审，几秒后吐出一个 <artifact>，渲染在沙盒 iframe 里。

这不是 "AI 试图做点设计"，这是一个被提示词栈训练得像高级设计师一样工作的 AI。

其次它的催生，是站在以下这四个开源项目的肩膀上：

效果展示

入口页 —— 选 skill、选 design system、写一行需求。同一个表面服务原型、deck、移动端、dashboard、editorial 页面所有 mode。

初始化问题表单 —— 模型动笔之前，OD 先把需求锁住：surface、受众、调性、品牌上下文、规模。30 秒勾选项秒杀 30 分钟来回返工。

方向选择器 —— 用户没有品牌上下文时，agent 自动跳第二个表单，5 套精选方向（Monocle / Modern Minimal / Tech Utility / Brutalist / Soft Warm）一个 radio 选完，色板 + 字体栈直接锁定，没有 freestyle 空间。

实时 todo 进度 —— Agent 的计划以活卡片形式流入 UI。in_progress → completed 实时切换。用户能在中途以极低成本介入纠偏。

沙盒预览 —— 每个  都在干净的 srcdoc iframe 里渲染。可在文件工作区里就地编辑；可下载为 HTML / PDF / ZIP。

72 套 design system 库 —— 每套产品系统都展示 4 色色卡。点进去看完整的 DESIGN.md、色板网格、live showcase

Deck 模式（guizang-ppt） —— 内置的 guizang-ppt-skill 原样接入。杂志版式、WebGL hero 背景、单文件 HTML 输出、可导 PDF。

移动端原型 —— 像素级精确的 iPhone 15 Pro chrome（灵动岛、状态栏 SVG、Home Indicator）。多屏原型直接复用 /frames/ 共享资源，agent 永远不需要重新画一遍手机。

核心亮点

1、129 套品牌级设计系统

Open Design 内置了 129 套 Design Systems，包括：

• • 2 套手写起手（Neutral Modern、Warm Editorial）

• • 70 套从 awesome-design-md 导入的产品系统

• • 57 套来自 awesome-design-skills 的设计技能

每一套都包含完整的设计规范：颜色、排版、间距、组件、动效。你可以一键套用 Linear、Stripe、Vercel、Airbnb、Tesla、Notion、Apple、Cursor、Supabase、Figma、小红书等一线品牌的设计语言。

2、31 个可组合 Skills

Open Design 有 31 个内置 Skills，按用途分为三大类：

设计交付类（27 个 Prototype 模式）：

• • web-prototype - 单页 HTML 落地页

• • saas-landing - SaaS 营销页面

• • dashboard - 后台管理界面

• • pricing-page - 定价页面

• • docs-page - 三栏文档页

• • blog-post - 长篇博客内容

• • mobile-app - 移动 App 屏幕（带设备框）

• • mobile-onboarding - 移动端引导流

• • gamified-app - 游戏化移动应用

• • email-marketing - 邮件营销模板

• • social-carousel - 社媒轮播图

• • magazine-poster - 杂志海报

• • motion-frames - 动态帧设计

• • sprite-animation - 像素动画

• • dating-web - 约会类网站仪表盘

• • digital-eguide - 数字指南

• • wireframe-sketch - 手绘线框稿

• • critique - 五维自评审

• • tweaks - 微调面板

• • pm-spec - PM 规范文档

• • eng-runbook - 工程 Runbook

• • finance-report - 财务报表

• • hr-onboarding - HR 入职计划

• • invoice - 发票

• • kanban-board - 看板

• • team-okrs - OKR 评分卡

演示类（4 个 Deck 模式）：

• • guizang-ppt - 杂志风格 Web PPT（默认）

• • simple-deck - 简洁横滑演示

• • replit-deck - Replit 风格演示

• • weekly-update - 周报演示

每个 Skill 都是一个独立文件夹，遵循 Claude Code 的 SKILL.md 规范，并叠加 Open Design 的 od: frontmatter，极易扩展。

3、11 种 CLI 代理支持

Open Design 支持 11 种 coding-agent CLI，会自动在你的 PATH 上检测：

• • Claude Code

• • Codex

• • Cursor Agent

• • Gemini CLI

• • OpenCode

• • Qwen

• • GitHub Copilot CLI

• • Hermes

• • Kimi

• • Pi

• • Kiro

你可以一键切换使用哪个 agent 做设计引擎，不需要为 Open Design 单独付费。

如果你一个 CLI 都没装，也没关系，Open Design 还提供了 OpenAI 兼容的 BYOK 代理作为兜底，填入 baseUrl + apiKey + model，任意 vendor（Anthropic-via-OpenAI、DeepSeek、Groq、MiMo、OpenRouter、自托管 vLLM）都能用。

4、丰富的媒体生成

除了设计原型，Open Design 还支持生成图像、视频、音频，与设计循环并行可用：

• • gpt-image-2（Azure / OpenAI）做海报、头像、信息图、城市插画地图

• • Seedance 2.0（字节跳动）做 15 秒电影感 t2v + i2v

• • HyperFrames 做 HTML→MP4 动态图形

内置 93 条 可一键复刻的 prompt gallery，43 条 gpt-image-2 + 39 条 Seedance + 11 条 HyperFrames，都附预览图与来源署名。

5、沙盒预览 + 多种导出

每个生成的 <artifact> 都在干净的 srcdoc iframe 里渲染，可以在文件工作区里就地编辑，也可以一键导出：

• • HTML

• • PDF

• • PPTX

• • ZIP

• • Markdown

快速上手（5 分钟）

环境要求

• • Node.js: ~24

• • pnpm: 10.33.x（推荐用 Corepack 自动管理）

• • OS: macOS、Linux、WSL2（Windows 原生也能用，但 WSL2 更稳定）

• • 可选：已安装的 coding-agent CLI（Claude Code、Codex 等）

安装步骤

# 1. 克隆项目
git clone https://github.com/nexu-io/open-design.git
cd open-design
# 2. 启用 Corepack 并安装依赖corepack enable
pnpm install
# 3. 启动完整产品（daemon + web + desktop）pnpm tools-dev
# 或者只启动 daemon + webpnpm tools-dev run web

启动后访问终端打印的 Web URL 即可使用。

第一次使用

首次加载时，应用会自动检测你已安装的 code-agent CLI，默认选择 web-prototype skill + Neutral Modern design system。你只需要：

1. 1. 选择一个 Skill（比如 saas-landing 或 dashboard）

2. 2. 选择一个 Design System（比如 Linear、Stripe 等）

3. 3. 写一行需求（比如 "帮我做一个 AI 写作助手的定价页面"）

4. 4. 点击 Send

Agent 就会开始工作，实时显示 Todo 进度，生成的 HTML 会在右侧沙盒中即时预览。

完成后点击 "Save to disk" 可以保存到磁盘。

常用命令

# 启动完整产品（后台）
pnpm tools-dev
# 启动 daemon + web（前台）pnpm tools-dev run web
# 查看状态pnpm tools-dev status
# 查看日志pnpm tools-dev logs
# 停止pnpm tools-dev stop
# 重启pnpm tools-dev restart
# 健康检查pnpm tools-dev check
# 生产构建pnpm build

项目优势在哪？

Open Design 的出现，意味着即使你不是专业设计师，也能用本地 Agent 快速产出高质量的网页、移动端原型和演示文档。它的价值在于：

1. 1. 完全开源：你可以看到工作流的每个细节，理解 AI 是如何思考的，也可以二次开发。

2. 2. 不锁定：换用任何模型都可以，不会被某家公司绑定。

3. 3. 本地优先：数据永远在你手里，不会上传到第三方云端。

4. 4. 零额外付费：你已经为 Claude Code 或其他 CLI 付费了，不需要再为 Open Design 付费。

5. 5. 极强的扩展性：添加新的 Skill 只需要一个文件夹，社区可以持续贡献。

对于独立开发者、产品经理、AI 爱好者、内容创作者来说，这都是一个极具生产力的新工具。

写在最后

当一个工具用 "便利" 把你圈入付费墙，再用 "封闭" 阻止你离开时，开源社区就会站出来。

Open Design 不是另一个 AI 玩具，它是对封闭生态的有力回应——设计应该是自由的，你的数据应该是你的，你的工具应该由你控制。

GitHub：https://github.com/nexu-io/open-design

导读： 六个月前，OpenAI 内部一个团队做了个大胆的决定：他们要建一个代码仓库，但一条人写的代码都不允许有——每一行都必须由 Codex 生成。他们重构了整个工程流程，造了个「Agent 友好型仓库」，投入大量精力写自动化测试和护栏，把 Codex 当正式队友来带。
这事还真做成了。但紧接着，他们撞上了新的天花板：人的注意力不够用了。

瓶颈不在 Agent，在人

OpenAI 的工程师 Alex Kotliarskyi（也是 React Native 的核心贡献者）在推文中说得很直白：

Codex 很聪明，但人的注意力是有限的。当团队里每个人同时开好几个 Codex 会话，在终端之间来回切——这个会话卡住了要调试，那个会话在做什么已经忘了——工程师的时间被「微管理 Agent」吃掉了。

实际上，大多数人能同时管理的 Codex 会话只有 3-5 个。超过这个数，效率直线下降。会忘掉哪个会话在做什么，在终端之间跳来跳去纠偏，调试半路卡住的长任务。

Agent 的速度很快，但系统瓶颈出现了：人的注意力。OpenAI 的团队实际上造了一群能力极强的初级工程师，然后让高级工程师全职去微管理他们。这不是长久之计。

视角转换：从管理会话到管理任务

团队意识到他们在优化错误的东西。之前一直围绕「编码会话」和「合并 PR」来设计流程，但这些只是手段。软件工程的真正组织单元是什么？是需求、是任务、是里程碑。

那如果不再让人去直接监督 Agent，而是让 Agent 从任务管理器里自己拉活呢？

这个想法变成了 Symphony。

Symphony 的核心思路：把 Issue 看板当成控制面板。每个待办任务自动分配一个 Agent，Agent 7×24 小时运行直到任务完成，人类只需要看结果。

Symphony 的完整工作流程

先看一张全景图，了解单个任务在 Symphony 里是怎么走完一圈的：

具体来说，Symphony 做了这几件事：

1. 1自动接单：持续轮询 Linear 看板，每个处于活跃状态的任务都会被分配一个独立的 Agent 工作区
2. 2独立工作区：每个任务有自己的目录空间，Agent 之间互不干扰，不会出现两个 Agent 同时改同一个文件的情况
3. 3自动重启：Agent 崩了或卡住了，Symphony 自动拉起来继续跑，不需要人工干预
4. 4状态驱动：通过 Linear 的任务状态（Todo → In Progress → Review → Done）驱动整个流程。注意，Symphony 本身只负责读取和调度，状态转换是 Agent 通过工具完成的
5. 5依赖管理：任务之间可以设依赖关系。Agent 会自动判断：哪些不依赖别人可以并行，哪些得等前置完成

这种设计有个很实际的用处。比如一个复杂需求可以拆成一棵任务树：先做「迁移到 Vite」，再做「升级 React」，再做「更新组件库」。Agent 自动识别依赖关系，Vite 迁移没完成之前，React 升级的任务会被标记为 Blocked，不会提前启动。等 Vite 搞定了，React 升级自动开始。

还有一些有趣的细节：

• Agent 在实现过程中发现改进点（性能问题、重构机会、更好的架构），会自己创建新的 Issue，后面这些新任务也会被其他 Agent 接走

• 每个任务不一定只产生一个 PR——有些任务可能跨多个仓库产出多个 PR，有些可能是纯分析调研，根本不碰代码

• 一旦工作被抽象成「任务」而非「会话」，任务的粒度可以大得多——团队经常用 Symphony 来编排复杂的功能开发和基础设施迁移

Agent 的能力是怎么一步步进化的

OpenAI 坦诚分享了一个关键教训：把 Agent 当成状态机里的刚性节点是行不通的。

早期版本，Symphony 只让 Codex 去实现任务描述里的功能。结果很快发现这个框太窄了。Codex 完全有能力创建多个 PR、阅读 review 反馈并处理它、甚至做更多事情。

所以 OpenAI 开始给 Agent 装工具——gh CLI、读 CI 日志的技能等等。Agent 的能力边界被不断推远：

最终的思路是：给 Agent 目标，而不是严格的步骤。 就像好的管理者给下属定方向而不是写操作手册——模型的核心能力是推理，给它工具和上下文，让它自己发挥。

但也不是所有任务都适合。需要强判断力的模糊问题、需要深度专业知识的工作，仍然需要工程师直接用交互式 Codex 会话来做。好消息是，日常重复性的实现工作被 Symphony 接管了，工程师可以专注在真正有意思的难题上。

实际效果：PR 数量翻 5 倍

OpenAI 公布了内部数据：部分团队在使用 Symphony 后的前三周，合并的 PR 数量增加了 500%。

Linear 创始人 Karri Saarinen 也分享了一个有意思的观察：

Symphony 开源发布后，Linear 上的新工作空间数量出现了明显增长。这说明不只是 OpenAI 在用，整个开发社区都在尝试这种「看板驱动 Agent」的模式。

更深层的变化不是产出量，而是工作方式本身变了。当工程师不再花时间盯 Agent 会话，发起一个代码变更的心理门槛一下子就降下来了。想试个想法？提个任务就行。探索性重构？提个任务就行。反正 Agent 24 小时在线，不睡觉，随时接单。搞出来不好用？扔掉就是，成本几乎为零。

这也改变了谁可以发起工作。产品经理和设计师现在可以直接往 Symphony 里提需求——不用 checkout 代码库，不用管理 Codex 会话，描述完需求就能收到一个包含功能演示视频的审核包。

Ryan Carson 分享了他的实践经验：

他同时跑 5 个 Agent，用 Symphony + Codex + Linear 的组合，实现了团队 100% 代码由 AI 编写。甚至有工程师在山间小木屋里用手机上的 Linear App 就完成了三个重大变更——因为只需要提任务，Agent 会在 devbox 上自己干活。

还有一个有意思的细节：团队在观察中发现，使用 Symphony 后最大的变化不是产出量，而是探索行为大幅增加。当发起一次代码变更的代价趋近于零，人们开始更频繁地做实验性尝试——试一个想法、探索一次重构、验证一个假设，然后只留下看起来有希望的结果。这种「低成本试错」模式以前只有在 Google 这种级别的内部工具链里才能做到。

对大仓库特别有用

OpenAI 自己是巨型 monorepo，PR 合并的最后一段路程（过 CI、rebase、解冲突、重试不稳定的检查）特别慢、特别容易出问题。

Symphony 在这块帮了大忙——它会持续盯着 CI 状态，自动 rebase，自动解冲突，自动重试偶然失败的检查项。等任务到达「合并中」状态时，团队已经很有信心这个变更能顺利合入主分支，不需要人工 babysit。

技术本质：一个 Markdown 规格文件

打开 Symphony 的 GitHub 仓库，你会发现一个出乎意料的事实：Symphony 技术上就是一个 SPEC.md 文件——对问题的定义和预期解决方案的描述。

OpenAI 没有去造一个复杂的监控系统。它定义了以下核心组件：

整个系统的状态机只有 5 个状态：Unclaimed → Claimed → Running → RetryQueued → Released。

这种「规格即代码」的思路很有意思：不是硬编码每个状态转换，而是定义好目标和约束，让 Agent 自己推理怎么从 A 走到 B。社区已经基于这个 spec 做了多种实现（包括 Elixir/OTP 版本），说明 spec 本身的设计足够通用。

用 Symphony 构建 Symphony

最 meta 的是：Symphony 本身就是用 Symphony 来开发的。

团队把 Symphony 的开发任务拆成 Issue，然后用 Symphony 自己来编排 Agent 完成这些任务。等于说这个工具在开发自己的过程中就在被验证和迭代。

代价和局限

说了这么多好处，也得讲讲代价。

Token 消耗巨大。 有用户（Dan McAteer）报告，他的 Symphony 在处理一个项目时，14 小时内消耗了约 3.88 亿 Token，按 GPT-5.4 API 定价算下来大约 1000 美元。他的一周 Codex 用量已经清零（可能是用量配额被吃光了）。对个人开发者来说，这个成本目前可能不划算。

不适合模糊问题。 需要强判断力、需要深度专业知识的任务，仍然得工程师亲自上手。Symphony 解决的是「知道要做什么」之后的那部分执行工作。

需要完善的前置条件。 自动化测试、护栏、文档——这些东西得先到位，否则 Agent 跑起来就是在制造混乱。OpenAI 在此前的 harness engineering 博客里详细讲过怎么建这些基础设施。

失去了实时纠偏的能力。 从「实时引导 Agent」变成「事后审核结果」，有时候 Agent 产出的东西完全跑偏了。OpenAI 的策略是不手动修补结果，而是把失败当作系统改进的信号——加护栏、加技能、完善文档，让 Agent 下次能自己搞定。

写在后面

Symphony 背后反映的趋势很明确：AI 编码工具正在从「人和模型对话」进化到「人给系统派活」。

以前是你打开终端，跟 Codex 聊，等它写完代码，你再审。现在是你往 Linear 里提个任务，Agent 自己拉代码、写代码、跑测试、提 PR，你只需要看最终结果说「行」或「不行」。

这个转变对团队的影响比单个工具大得多。它改变了谁可以发起工作、发起工作的成本有多低、以及工程师的时间花在哪里。正如那条推文说的：提示词框只是一个阶段，未来是 always-on 的编排。

OpenAI 开源了 Symphony——一个把任务看板变成 AI Agent 自动化编排系统的工具。每个待办任务自动分配 Codex Agent，7×24 小时运行，工程师只需要审核结果。内部数据显示部分团队 PR 数量增长 500%。它代表了一个趋势：AI 编码从「人跟模型对话」走向「人给系统派活」。不过 Token 成本不低（14 小时可能烧 1000 美元），也不适合所有类型的任务。

参考链接

• OpenAI 官方博客：https://openai.com/index/open-source-codex-orchestration-symphony/

• Symphony GitHub 仓库：https://github.com/openai/symphony

• OpenAI 此前博客「Harness Engineering」：https://openai.com/index/harness-engineering/

• Linear 创始人 Karri Saarinen 讨论：https://x.com/karrisaarinen/status/2031773828284919878

在 AI Agent 席卷全球的当下，「记忆系统」 正被业界视为比底层模型本身更关键的技术瓶颈。

这不是某个模型的问题，而是所有 AI Agent 的通病——金鱼脑。每次开聊都从零开始，昨天告诉它的事今天就当没发生过。

为此，Y Combinator（YC）总裁 Garry Tan 在 GitHub 上开源了他个人日常使用的生产级AI记忆系统——GBrain。

开源至今已经狂揽 10.7K+ Stars，在 X 平台上触达超过 150 万人。

这不是某个模型的问题，而是所有 AI Agent 的通病——金鱼脑。每次开聊都从零开始，昨天告诉它的事今天就当没发生过。

目前里面已经有 17888 个页面、4383 个人物、723 家公司、21 个定时任务全自动运转。整套东西他只用了 12 天就搭出来了。

说白了，GBrain 干的事就一句话：给你的 AI Agent 装一个能持续变聪明的长期记忆。

你的 Agent 接入它之后，会在你睡觉的时候自己变聪明。自动消化你的会议记录、邮件、推特、语音通话和你随手记下的想法，顺手帮你补全每个出现过的人和公司的资料，还会自己修复坏掉的引用、整理凌乱的记忆。

第二天你起床，这个脑子已经比你昨晚睡前更聪明了。

GBrain 到底是什么？

GBrain 是一个 个人知识大脑系统，专门配合 OpenClaw、Hermes Agent 这类 AI Agent 平台使用。

它把你散落在各处的 Markdown 笔记——不管是人脉档案、公司资料、会议记录、随手想法还是收藏的文章——统统变成一个可搜索、可推理、持续增长的知识图谱。

不是简单的文件存储，而是让 AI 能真正"读懂"并"运用"你的知识。

Garry Tan 本人用它管理着 10000+ Markdown 文件，涵盖 3000+ 人脉资源、13 年的日历数据、无数会议记录和媒体内容。

和 GStack 什么关系？

如果你关注 Garry 的开源动态，应该知道他之前还开源了 GStack——一套专门教 AI Agent 写代码的 Skill 工作流，目前 8 万+ Star。

GStack 教 Agent 怎么写代码，GBrain 教 Agent 怎么记事和思考。 两个项目可以独立用，也能合体。

开源仓库里有个 hosts/gbrain.ts 就是那座桥，装上之后 GStack 的编码 Skill 在动手写代码前会先查一下脑子，看看你之前是不是讨论过、决定过什么。

如果你已经在用 GStack，装上 GBrain 基本就拼出 Garry Tan 自己那套完整工作流了：一个管手，一个管脑。

核心亮点

1、25 个 Skill 即插即用

GBrain 自带 25 个 Skill，装上就能用，按用途分了几大类。

里面有两个是永远在线的：

• • signal-detector：每条新消息进来，都会顺手起一个便宜的小模型在后台跑，把你随口说的原创观点和提到的人名、公司名都抓出来。脑子是在你不知不觉中长大的。

• • brain-ops：Agent 回答任何问题之前，会先去脑子里查一遍，查不到再去调外部 API。这就解决了 AI 经常瞎编的问题——查不到它会直接告诉你脑子里没这个信息，而不是给你胡诌一段。

剩下的还有：

• • 内容摄入类：会议、邮件、推特、PDF、视频、GitHub 仓库全吃

• • 运维类：cron 调度、每日简报、引用自检、过期页面巡检

• • 实体丰富类：自动补全人物档案、公司信息

• • 任务管理类：每日任务准备、跨模态审查

完全是一套自治系统，你只管喂数据，AI 负责归档和整理。

2、Compiled Truth + Timeline 双层结构

这个设计挺顶的，值得单独拎出来讲。

每个 brain page 分两层：

• • 上方 Compiled Truth：当前最佳理解，可以被随时改写。比如你对某个朋友的认知，会随着新的接触不断刷新。你对某家公司的判断，会随着新信息持续修正。

• • 下方 Timeline：只追加不删除，记录每条原始证据。什么时候、在哪场会议、谁说了什么，全部留痕。

为啥这么设计？因为既要让认知能进化，又不能丢历史。

AI 之前的笔记类工具要么覆盖式更新，查的时候发现内容被改了却不知道啥时候改的；要么纯追加，查的时候一团乱。GBrain 这个分层算是把两边的好处都拿了：上面是活的知识，下面是死的证据链。

3、混合搜索 + 实体自动升级

搜索这块用的是关键词 + 向量 + RRF 融合 + 多查询扩展 + 4 层去重。

简单讲：关键词搜索能精准命中原话，向量搜索能找到意思相近的内容，两个一起上再融合排序，基本不会漏。

更有意思的是它的实体自动升级机制：

• • 同一个人在你的资料里被提到 1 次，只生成一个 stub 页面

• • 提到 3 次以上，系统自动联网补料，从 LinkedIn、Twitter、公司主页之类的地方拉信息回来

• • 提到 8 次以上，或者你跟他开过会，直接走完整管线，生成一份详细 dossier

脑子自己学谁重要，不需要你手动标。

它还有个 fail-improve 循环：每次 LLM 兜底分类的时候都会被记录下来，系统自动从这些记录里生成更好的正则。脑子自己在变得更便宜更准。

快速入手

GBrain 设计的时候就是要让 AI Agent 自己装的，所以官方最推荐的方式是把一段 prompt 丢给你的 Agent 让它自己搞。

路线 A：让 Agent 自己装（推荐）

如果你已经在跑 OpenClaw 或 Hermes Agent，直接把下面这段贴进去：

Retrieve and follow the instructions at:
https://raw.githubusercontent.com/garrytan/gbrain/master/INSTALL_FOR_AGENTS.md

剩下的 Agent 自己来：克隆仓库、安装依赖、初始化大脑、加载 25 个 Skill、配置定时任务。你只需要回答几个关于 API Key 的问题，大概 30 分钟全部搞定。

路线 B：独立 CLI（不用 Agent）

git clone https://github.com/garrytan/gbrain.git && cd gbrain && bun install && bun link
gbrain init                     # 本地大脑，2 秒就绪
gbrain import ~/notes/          # 导入你的 Markdown 笔记
gbrain query "what themes show up across my notes?"  # 查询

路线 C：MCP Server（接入 Claude Code / Cursor / Windsurf）

GBrain 暴露了 30+ MCP 工具，通过 stdio 或 HTTP 接入：

本地 MCP（Claude Code, Cursor, Windsurf）：

{
  "mcpServers": {
    "gbrain": { "command": "gbrain", "args": ["serve"] }
  }
}

远程 MCP（Claude Desktop, Cowork, Perplexity）：

# 部署到 Supabase，一行脚本
git clone https://github.com/garrytan/gbrain.git && cd gbrain
# 填 3 个环境变量，然后：scripts/deploy-remote.sh
# 生成访问令牌gbrain auth create "claude-desktop"

写在最后

GBrain不是完美的，它的一些功能（如编译真相重写、梦循环、实体检测）更多是作为Markdown指令文档来指导AI Agent做什么，而不是作为可执行代码。

但这不妨碍它是一个极具参考价值的项目。

毕竟，这是YC总裁亲自在用的生产级方案，完全开源，MIT许可。对于正在摸索AI Agent落地应用的开发者而言，这无疑是当前极具参考价值的宝库。

GitHub：https://github.com/garrytan/gbrain

摄影：产品经理

青椒腊肉和一个忘记了名字的菇

在大模型出来之前，计算机领域一直流行着这样一句名言：计算机领域的任何问题，都可以通过拆分问题+给系统增加若干个层来解决。 实际上，这句话在现在的 AI 时代，依然是绝对的真理。

例如以前面试经常问的一个老掉牙的系统设计问题：如何设计一个短网址系统？标准答案是，使用内存+Redis+数据库做多级存储架构。读取最频繁的短网址放到内存，其次的放到 Redis，不频繁的放到数据库。通过增加分层，完美解决高并发和存储成本的矛盾。

现在有了大模型，大家都在玩 Vibe Coding（用自然语言指挥 AI 写代码），很多人觉得以前的工程经验没用了，反正大模型什么都能干。但我认为恰恰相反，在用 AI 写代码时，大家更应该把“拆分与分层”这句话牢牢记在心里。

举个现实的例子，你想做一个招聘聚合网站，需要从各个公司的官网抓取他们的招聘信息，获得工作详情。

如果你没有任何工程经验，是个纯小白，你可能直接就甩给 AI 这样一段提示词：

帮我设计一个爬虫系统，我输入某公司的官网，你需要进入官网，找到里面的招聘页面，然后进入每一个工作，抓取工作的名字，工作地点，薪资和工作要求，并储存到数据库。

我相信现在很多人就是这样写的。并且不得不承认，现在的模型确实太聪明了——如果你用例如 Claude Opus 4.6 或者 Opus 4.7，再加上 Claude Code 这种工具，写出来的基于 Browser Use 的智能爬虫确实能运行，甚至效果可能还不错。它会自己打开浏览器，截图，识别哪里是下一页，哪里是详情。

有同学可能会说，既然能跑通，而且不用我写一行代码，那这不就足够了吗？

但如果你真的把它扔到服务器上跑，你会发现这样设计的系统有两个致命缺陷：

1. 成本极高，简直是在烧钱。 这个系统大概率会强依赖 Browser Use 和多模态视觉模型。大模型其实是在“看”网页。每次打开页面都要截图，把截图传给 API，让大模型通过视觉能力去识别按钮在哪里，判断下一步怎么操作。几千个网页抓下来，那庞大的 Token 消耗量和昂贵的 API 调用费，会让你当场破产。

2. 速度极慢，慢到令人发指。 每次网页跳转、翻页、点进详情，都要和大模型进行一次甚至多次交互。大模型推理是需要时间的，一次交互被拉慢 30 秒甚至一分钟非常正常。抓一个公司的招聘列表，可能要跑到天荒地老。

作为一个软件工程师，我想说的是，如果你把大模型当成一个无需思考的“黑盒”，你一定会被它的成本反噬。实际上，如果有工程经验和系统设计经验，即使我们现在不手写代码了，在使用 Claude Code 进行 Vibe Coding 时，也一定会给系统多增加一些限制。

既然单靠大模型硬干太蠢且太贵，我们可以通过增加分层，设计一个三级火箭式的爬虫架构：

第一层：寻找并拦截后端接口（低成本、光速）

现在的现代网站，极大比例都是前后端分离的，通过 Ajax 异步加载数据。前端渲染得再花哨，本质上也是接收了后端返回的 JSON 数据。

在使用 Vibe Coding 时，我不会让 AI 直接去“看”网页，而是会给它这样下指令：

先不要去解析 HTML。请先写一段代码尝试抓包或者分析该网站的网络请求（Network），重点寻找返回 JSON 格式工作信息的 API 接口。如果找到了 API，直接提取关键字段储存。

只要第一层走通了，我们就拿到了最原始、最干净的数据。拿到以后改一下字段名马上就能入库，不需要任何 HTML 解析和浏览器渲染。速度拉满，而且运行时完全不消耗大模型 Token，成本为零。

第二层：大模型生成解析规则（中成本、高并发）

当然，并不是所有网站都有现成的 JSON 接口可以抓，遇到那些传统的服务端渲染（SSR）页面怎么办？直接上 Browser Use 吗？错。

大模型在第一次运行时，可以完整走完网页分析流程。但请注意，它这次的目的并不是直接提取数据，而是去生成“提取规则”。

这个时候我的 Prompt 会变成这样：

这是一个服务端渲染的 HTML 网页。请你分析这个网页的 DOM 结构，帮我写出提取工作名字、地点、薪资的 XPath 规则或者 BeautifulSoup/正则表达式的提取代码。将这套代码封装成一个 Python 函数。

大模型只在写代码、定规则的“第一次”参与工作。接下来从第二次抓取开始，我们就可以像跑传统爬虫一样，发送 HTTP 请求，拿着大模型写好的规则去提取数据。在这个日常运行的过程中，完全不再需要依赖浏览器，也不需要向大模型发请求。大并发跑起来毫无压力。

第三层：Browser Use 智能兜底（高成本、低频）

只有在前两步都彻底搞不定——例如遇到了极其恶心的动态混淆、页面数据被 Canvas 加密、或者极其严格的反爬机制，传统的 HTTP 请求和规则提取都失效了，这时候，我们才祭出最后的杀招：使用真实的浏览器环境 + 大模型视觉识别来兜底。

明确告诉 AI：

如果前面的静态抓取和 API 接口都失效了，请回退到使用 Playwright/Browser Use 控制真实浏览器，通过截图和大模型视觉能力，点击对应元素来获取数据。

既然这是少数极其难啃的硬骨头，那这部分高昂的时间和金钱成本就是我们可以接受的。

总结

通过把系统拆分成“API拦截 -> 规则生成 -> 智能视觉兜底”这三个层，大量常规请求被第一层和第二层拦截，极大地降低了系统对昂贵大模型 API 的调用频次。我们可以显著降低 90% 以上的 API 成本，并极大提高爬虫的运行效率。

大模型确实能帮你敲代码，极大降低了编程的门槛。但如何设计一个优雅、省钱、可扩展且高效的系统，依然需要你脑子里的工程智慧。在 Vibe Coding 时代，AI 替代的是你的手，而不是你的脑子。

摄影：产品经理

水蕨菜

最近在各种AI编程社区里面逛，发现一个很有意思的现象——大家都在疯狂地折腾怎么省Token。

有人搞Prompt缓存，有人换便宜模型，甚至还有人专门写了一个省Token.skill，让大模型在回复的时候尽量精简。更夸张的是，有人为了省钱，把Claude换成了各种开源小模型，然后抱怨说效果变差了。

这些操作，怎么说呢，就像你家水龙头在哗哗漏水，你不去修水龙头，反而跑去超市买打折的矿泉水。

其实真正吃掉你Token的大头，不是大模型的回复太长，也不是你的Prompt写多了。是Skill本身。

Skill到底在干什么

先给不太熟悉的同学解释一下。Skill就是一段预定义的指令，告诉大模型应该怎么一步一步完成一个任务。比如你可以写一个Skill，让大模型帮你操作浏览器，上某个网站搜东西，然后把结果整理出来。

听起来很方便对吧？问题出在哪呢？

我们来看一个具体的例子。假设我要让AI帮我做这么一件事：

打开浏览器，访问Amazon，搜索"牛仔裤"，从第一页的搜索结果里找到最便宜的那条，把商品名称和链接返回给我。

这个需求很简单，对人来说，打开网页点几下就搞定了。我们用Skill来实现它。

第一版：纯Skill实现

我写了一个Skill，核心逻辑大概是这样的：

## Steps
1. 使用浏览器工具，导航到 https://www.amazon.com
2. 找到搜索框，输入"牛仔裤"并搜索
3. 等待搜索结果加载
4. 获取页面快照，分析第一页所有商品的名称和价格
5. 比较所有价格，找出最便宜的商品
6. 返回该商品的名称、价格和链接

看起来清晰明了。我直接在Claude Code里面运行这个Skill，模型用的是Opus 4.6——没办法，要驱动浏览器工具做这种多步骤操作，小模型根本搞不定。

运行这个Skill，我足足等了12分钟。

跑完以后我去OpenRouter后台看了一下这次任务的消耗：

看到没有？几十次API调用，每次都携带将近10万tokens的上下文。最后一算总账，这个看似简单的任务消耗了我将近10美元。

这钱花在哪了？

我仔细看了一下每次API调用的内容，发现了一个非常离谱的事情：

大模型在用"智力"做不需要智力的事情。

举几个例子：

1. 导航到Amazon首页 —— 大模型需要"思考"应该调用browser_navigate工具，传入URL。就这么一个简单的操作，一轮对话下来，系统提示词、工具定义、Skill内容、对话历史全部打包发送，直接吃掉将近10万tokens。

2. 找搜索框并输入关键词 —— 大模型需要先调用snapshot获取页面结构，然后"思考"哪个元素是搜索框，再调用type输入文字。两轮对话，又是将近20万tokens。

3. 点击搜索按钮 —— 又是一轮对话，大模型需要分析页面快照，找到搜索按钮的ref ID，然后调用click。又是10万tokens。

4. 分析搜索结果 —— 这里是最夸张的。大模型需要获取整个页面的快照，这个快照本身就很长，然后它需要从里面找到所有商品的价格信息，进行比较。又是10万tokens。

你看出问题了吗？

打开一个URL，在搜索框里输入文字，点击按钮——这些操作需要大模型来"思考"吗？这就好比你请了一个数学教授来帮你按计算器，教授每按一个键之前都要在脑子里推演一遍偏微分方程。

几十次API调用里面，真正需要大模型"智力"的，其实只有一步：从搜索结果中判断哪个商品最便宜。 其他全是确定性的操作——打开网页、输入文字、点击按钮、提取文本——这些操作写几行Python就能搞定，根本不需要大模型参与。

第二版：代码+大模型混合实现

想明白了这一点，我让Claude Code把这个Skill改造成Python脚本。原则很简单：

所有确定性的、不需要智力判断的环节，用代码实现。只有需要智力判断的环节，才调用大模型。

改造后的代码核心逻辑是这样的：

from playwright.sync_api import sync_playwright
import openai
deffind_cheapest_jeans():
# ===== 第一部分：纯代码，不需要大模型 =====
with sync_playwright() as p:
        browser = p.chromium.launch(headless=True)
        page = browser.new_page()
# 1. 导航到Amazon（确定性操作，不需要AI）
        page.goto("https://www.amazon.com")
# 2. 搜索牛仔裤（确定性操作，不需要AI）
        page.fill('input[name="field-keywords"]', '牛仔裤')
        page.press('input[name="field-keywords"]', 'Enter')
        page.wait_for_load_state('networkidle')
# 3. 提取搜索结果（确定性操作，不需要AI）
        results = page.query_selector_all('div[data-component-type="s-search-result"]')
        products = []
for result in results[:20]:  # 只取前20个
            title_el = result.query_selector('h2 span')
            price_el = result.query_selector('.a-price .a-offscreen')
            link_el = result.query_selector('h2 a')
if title_el and price_el and link_el:
                products.append({
'title': title_el.inner_text(),
'price': price_el.inner_text(),
'url': 'https://www.amazon.com' + link_el.get_attribute('href')
                })
        browser.close()
# ===== 第二部分：需要大模型的智力判断 =====
# 为什么这里要用大模型？因为价格格式可能不统一
# 有的写 $29.99，有的写 $29.99 - $35.99，有的有优惠券
# 还有的价格是"See price in cart"，这些需要AI来理解
    client = openai.OpenAI(
        base_url="https://openrouter.ai/api/v1",
        api_key="your-key"
    )
    product_text = "\n".join(
f"[{i+1}] {p['title']} | {p['price']}"
for i, p in enumerate(products)
    )
    response = client.chat.completions.create(
        model="minimax/minimax-m1",
        messages=[{
"role": "user",
"content": f"下面是Amazon搜索牛仔裤的结果，请找出最便宜的一条。"
f"只返回序号数字，不要其他内容。\n\n{product_text}"
        }]
    )
    idx = int(response.choices[0].message.content.strip()) - 1
    cheapest = products[idx]
return cheapest
result = find_cheapest_jeans()
print(f"最便宜的牛仔裤：{result['title']}")
print(f"价格：{result['price']}")
print(f"链接：{result['url']}")

注意看代码的结构——我用注释把它分成了两部分。第一部分是纯代码操作：打开浏览器、输入搜索词、提取商品信息。这些操作100%确定性，不需要大模型参与。第二部分才是调用大模型：让它从一堆商品里面判断哪个最便宜。

你可能会问，比较价格为什么还需要大模型？直接用代码排序不就行了？

因为Amazon的价格格式乱七八糟。有的商品显示$29.99，有的显示$29.99 - $45.99（价格区间），有的写See price in cart，还有的价格旁边带一个with coupon。要把这些情况全部用代码处理，你光写正则表达式就得写半天。但对大模型来说，理解这些格式是它的强项。

效果对比

运行改造后的代码，17秒跑完，结果直接打印在终端里。

去OpenRouter后台一看——API调用次数：1次。Token消耗：约2.1K tokens。费用：$0.004。

我把两次运行的数据放在一起对比：

指标	纯Skill	代码+大模型	节省比例
运行时间	12分钟	17秒	97%
API调用次数	几十次	1次	>97%
费用	~$10	$0.004	>99%

没有看错，费用从10美元降到了不到半美分，降了99%以上。运行时间从12分钟降到17秒，快了40多倍。

为什么差距这么大

很多人没有意识到一个问题：大模型每做一次工具调用，都需要携带完整的上下文。

第一次调用，大模型需要接收系统提示词+工具定义+用户消息。光Claude Code的系统提示词和工具定义就有好几万tokens，加上Skill的内容，第一轮就将近10万tokens了。它返回一个工具调用，然后你把工具执行结果发回去。第二次调用，大模型需要接收之前所有的内容+第一次的助手消息+第一次的工具结果+……

看出来了吗？每多一轮工具调用，上下文就膨胀一次。 几十轮下来，累积的tokens量是天文数字。而这些历史消息里面，绝大部分是浏览器页面快照——那些密密麻麻的HTML元素和ref ID。

这就是为什么工具调用密集型的Skill特别费Token。不是大模型话多，是它每次说话之前，都要把之前所有的对话重新"读"一遍。

而改造成代码以后，浏览器操作全部由Playwright完成，大模型只需要在最后被调用一次。它接收到的输入就是一个简单的商品列表文本，2K tokens搞定。

有Claude订阅？那就更香了

上面的例子我用的是OpenRouter + Opus 4.6。但如果你有Claude Pro或Team订阅，还有一个更狠的玩法。

先说一个现实：Claude的官方API价格确实不便宜。Sonnet 4每百万输入Token 3美元，输出15美元。Opus就更不用说了。如果你用API来跑上面这种工具调用密集型任务，几十轮对话下来，光API费用就够你心疼的。

但订阅用户有一个巨大的优势——Anthropic提供了一个叫Claude Agent SDK的东西。这个SDK可以直接调用你本地的Claude Code，走的是你的订阅额度，不需要额外提供任何大模型API Key。

什么意思呢？就是说你每个月付的那20美元订阅费，本来就包含了5小时的Claude Code使用时间。现在你可以通过Agent SDK，在自己的Python脚本里直接调用Claude Code来完成那个"需要智力判断"的环节。不需要OpenRouter，不需要API Key，不需要额外花一分钱。

我们来看看改造后的代码：

import anyio
from playwright.async_api import async_playwright
from claude_agent_sdk import query, ClaudeAgentOptions, AssistantMessage, TextBlock
asyncdeffind_cheapest_jeans():
# ===== 第一部分：纯代码，不需要大模型 =====
asyncwith async_playwright() as p:
        browser = await p.chromium.launch(headless=True)
        page = await browser.new_page()
await page.goto("https://www.amazon.com")
await page.fill('input[name="field-keywords"]', '牛仔裤')
await page.press('input[name="field-keywords"]', 'Enter')
await page.wait_for_load_state('networkidle')
        results = await page.query_selector_all(
'div[data-component-type="s-search-result"]'
        )
        products = []
for result in results[:20]:
            title_el = await result.query_selector('h2 span')
            price_el = await result.query_selector('.a-price .a-offscreen')
            link_el = await result.query_selector('h2 a')
if title_el and price_el and link_el:
                products.append({
'title': await title_el.inner_text(),
'price': await price_el.inner_text(),
'url': 'https://www.amazon.com'
                           + await link_el.get_attribute('href')
                })
await browser.close()
# ===== 第二部分：调用Claude Code，走订阅额度 =====
    product_text = "\n".join(
f"[{i+1}] {p['title']} | {p['price']}"
for i, p in enumerate(products)
    )
    prompt = (
f"下面是Amazon搜索牛仔裤的结果，请找出最便宜的一条。"
f"只返回序号数字，不要其他内容。\n\n{product_text}"
    )
    result_text = ""
asyncfor message in query(
        prompt=prompt,
        options=ClaudeAgentOptions(
            system_prompt="你是一个价格比较助手，只返回数字。",
            max_turns=1
        )
    ):
if isinstance(message, AssistantMessage):
for block in message.content:
if isinstance(block, TextBlock):
                    result_text += block.text
    idx = int(result_text.strip()) - 1
    cheapest = products[idx]
return cheapest
result = anyio.run(find_cheapest_jeans)
print(f"最便宜的牛仔裤：{result['title']}")
print(f"价格：{result['price']}")
print(f"链接：{result['url']}")

核心变化就一个——把OpenRouter的API调用换成了claude_agent_sdk的query函数。安装也很简单：

pip install claude-agent-sdk

这个SDK会自动调用你本地装好的Claude Code。只要你登录了Claude订阅账号，它就直接走你的订阅额度，不走API计费。

这意味着什么？上面那个"需要智力判断"的步骤，从花 0。对，零额外费用。你唯一消耗的，是5小时额度里面的几秒钟而已。

而且还有一个隐藏的好处——既然大模型调用的部分已经不花钱了，你甚至可以在脚本里多调几次Claude。比如让它先判断哪些搜索结果是真正的牛仔裤（排除广告和配件），再从里面找最便宜的。之前用API的时候，多调一次就多花一次钱，你会下意识地省着用。现在走订阅额度，心理负担一下就没了。

所以最终的方案就是：Playwright负责干活，Claude负责动脑，订阅负责买单。 三者各司其职，效率拉满，额外开销为零。

别搞混了：是.py文件，不是代码片段

这里我要特别强调一点，因为我知道肯定有同学会搞混。

我说的"把Skill改成代码"，不是让你在Skill的Markdown里面嵌入代码片段。类似这样：

## Steps
1. 运行以下Python代码来打开浏览器并搜索：
```python
   from playwright.sync_api import sync_playwright
   # ...一堆代码...
```
2. 分析返回的结果，找出最便宜的商品

这种写法，本质上还是Skill。大模型读到这段Skill以后，它还是会一步一步地调用工具——调用终端执行你写的代码片段，然后读取输出，然后"思考"下一步该干什么。每一步照样携带完整上下文，该膨胀的Token一个都不会少。你只是把浏览器操作从browser工具调用换成了terminal工具调用，换汤不换药。

我说的是，把整个任务逻辑写成一个真正的.py文件。比如find_cheapest_jeans.py，保存在你的电脑上。这个脚本从头到尾自己跑，中间需要大模型判断的地方，通过Agent SDK自己调用Claude，最后把结果打印出来。

下次你想用的时候，在Claude Code里面说一句：

帮我运行 find_cheapest_jeans.py

就完事了。Claude Code收到这句话，调用一次终端执行python find_cheapest_jeans.py，脚本自己跑完，结果直接打印出来。整个过程对Claude Code来说，就是一次工具调用——执行一个命令，返回输出。

对比一下：

• Skill方式：Claude Code读取Skill → 思考第一步 → 调用工具 → 读取结果 → 思考第二步 → 调用工具 → …… → 几十轮对话，烧掉10美元

• .py文件方式：Claude Code执行一条命令 → 脚本自己跑完 → 返回结果。1轮对话，不到1K tokens

看到没有？连之前那2.1K tokens都省了。因为脚本内部调用Agent SDK时，走的是一次独立的Claude会话，不会叠加到Claude Code的主对话上下文里。

所以记住：Skill是给大模型看的说明书，.py文件是给Python解释器跑的程序。 一个要烧Token，一个不用。别搞混了。

你也可以这样做

我上面举的这个例子可能不是特别好，有人可能会说，如果我不仅仅要爬亚马逊，还要爬虾皮，淘宝，小红书这些呢？每一个网站都手动写代码吗？

其实你可以第一次运行的时候让大模型操作浏览器走完全程，并生成playwright的代码，后面从第二次开始，所有操作都通过代码进行。

除此之外，你日常使用的很多Skill，是完全固定的，毫无变化的流程，例如自动发送小红书帖子。就一个网站，同一个流程，这种就非常适合写代码。

其实道理很简单，你日常用的很多Skill，仔细想想就会发现——大部分步骤都是确定性的操作。

比如：

• 打开某个网站 → 代码搞定

• 在搜索框输入关键词 → 代码搞定

• 点击按钮 → 代码搞定

• 提取页面上的文字 → 代码搞定

• 读取文件内容 → 代码搞定

• 调用某个API → 代码搞定

• 格式化输出结果 → 代码搞定

真正需要大模型的，往往只有中间那一小步"判断"或"理解"的环节。

所以下次当你觉得Token花得太多的时候，不要急着去折腾缓存、换模型、写省Token.skill。先看看你的Skill，问自己一个问题：

这个Skill里面，有多少步骤其实不需要大模型？

然后让大模型帮你把那些确定性的步骤改写成Python代码。保留需要智力的部分给大模型，把不需要智力的部分还给代码。

这才是真正的降本增效——不是逼大模型少说话，而是别让大模型做不该它做的事。

导读： 你每天跟 AI 聊天、让它帮你写代码、帮你整理资料——但你有没有想过，那些对话记录、你的偏好、你和 AI 之间积累的默契，到底存在哪？谁在控制它们？LangChain 创始人 Harrison Chase 最近发了一条推文，把这个很少有人聊、但极其重要的问题摆到了台面上：Agent 的记忆，到底归谁管？

在聊记忆归谁管之前，得先搞懂一个概念：Agent Harness。

你可能用过 ChatGPT、Claude 这些 AI 聊天工具。你发一句话，它回一句话，一来一回，就这么简单。但如果你想让 AI 做更复杂的事——比如帮你管理一个项目、自动写代码、还要记住你之前的所有要求——光靠一个"聊天框"就不够了。

你需要一个"框架"来帮 AI 做这些事：调用外部工具、管理上下文窗口里该放什么内容、记住之前的对话、加载各种技能模块。这个框架，就叫 Agent Harness，翻译过来就是"Agent 脚手架"。

打个比方。AI 模型（比如 GPT-4、Claude）就像一个特别聪明的大脑。但光有大脑不行，它需要手脚、需要工具箱、需要一个能帮它把活儿干完的组织系统。Harness 就是这个组织系统——它负责把大脑的指令翻译成具体动作，同时把外界的反馈传递回大脑。

用一个更具体的模型来描述：Harness 作为中间层，向 AI 模型注入上下文（记忆、技能、对话历史），控制执行流程（任务编排、上下文压缩），并把执行结果（工具调用、代码运行）反馈回来形成闭环。

市面上已经有不少 Agent Harness 项目了：Claude Code、Codex、OpenCode、Pi、Letta Code，还有 OpenClaw。它们各有各的特色，但核心都是同一件事——给 AI 模型套上一个"壳"，让它能真正干活。

为什么 Harness 不会被模型取代？

有人可能会想：随着模型越来越强，Harness 是不是就不需要了？模型直接搞定一切，要什么脚手架？

Harrison Chase 给了一个很直观的反例：Claude Code。

Claude Code 是 Anthropic 官方的编程 Agent 产品。你知道它有多少行代码吗？51.2 万行。这不是模型本身的代码，仅仅是围绕模型构建的那层"壳"——也就是 Harness——就有 50 多万行。

如果模型够强就不需要 Harness，那 Anthropic 自己为什么还要花这么大力气写这 50 万行代码？

答案很清楚：模型再强，也需要有人来管理"怎么用这个模型"。

模型是一个通用的大脑。但你让它干活的时候，有太多具体问题要解决：

• 用户给了一个任务，怎么拆解成一步步的子任务？

• 每一步该用什么工具？文件系统怎么操作？终端命令怎么执行？

• 上下文窗口只有那么大，之前的对话怎么压缩、怎么保留关键信息？

• 用户有自己的偏好和习惯，怎么让 AI "记住"这些？

• 出错了怎么办？怎么回退、怎么恢复？

这些问题，模型本身是不管的。它们是 Harness 要管的事。

下面这张图来自 LangChain 博客，清楚展示了每一种"我们希望 Agent 做到的行为"，背后都要靠 Harness 层来实现：

从上到下，每一行都是同一个逻辑：你期望 AI 能做到某件事 → 模型本身做不到 → Harness 来填这个缺口。随着 AI 能做的事越来越多，这些问题只会更复杂，不会更简单。

而且 Harness 和模型之间还有一个有趣的协同进化关系：

Harness 发现了有用的新特性（比如记忆压缩、技能系统）→ 加入产品 → 用这套系统训练下一代模型 → 模型在这些特性上变得更强 → 循环往复。这就是为什么 Claude Code 和 Codex 这些产品都是"模型+Harness"联合打磨出来的——它们不是独立的两件事，而是一体的。

所以 Harness 不但不会消失，反而会越来越重要。它是 AI 从"能聊天"到"能干活"的关键桥梁。

Memory 不是插件，Memory 就是 Harness

好了，现在聊到最核心的问题了：记忆。

你可能注意到了，现在的 AI 编程助手都越来越强调"记忆"功能。Cursor 有 memory，Claude Code 有 CLAUDE.md，各种 Agent 框架都在说自己能"记住"你的偏好。

但 Letta 的 CTO Sarah Wooders 说了一句很狠的话：

"把记忆插入一个 Agent Harness，就像让'驾驶'这个功能插入一辆车——它本来就是车的一部分，没法分开。管理上下文、管理记忆，这是 Agent Harness 最核心的能力和职责。"

这话什么意思？

她说的是：记忆不是一个可以独立插拔的模块。记忆管理本身就是 Harness 最核心的功能之一。

想想看就明白了。当你和 AI 协作的时候，"记忆"不只是简单地存下你说过的每句话。它涉及一堆复杂的决策：

• 你的 AGENTS.md 或 CLAUDE.md 文件是怎么被加载到上下文里的？

• 技能的元数据是怎么展示给 AI 的？放在系统提示词里？还是单独的系统消息？

• AI 能不能自己修改自己的系统指令？

• 当上下文太长需要压缩的时候，什么被保留、什么被丢弃？

• 你和 AI 的交互历史有没有被存储？能不能被搜索？

• 记忆的元数据是怎么呈现给 AI 的？

• 当前工作目录怎么表示？AI 能看到多少文件系统的信息？

这些问题，每一个都是 Harness 的核心职责。它们不是"记忆插件"能解决的——它们就是 Harness 本身。

打个更接地气的比方。你的大脑有短期记忆和长期记忆。你不会觉得"记忆"是可以从大脑里拆出去的一个零件吧？它就是大脑运作方式的一部分。Agent 也是一样。怎么管理上下文、怎么决定记住什么忘掉什么，这些就是 Harness 的"思维方式"。

三种危险程度的锁定风险

既然记忆管理这么重要，那谁来控制它，就成了一个很要命的问题。

Harrison Chase 把风险分成了三个等级：

🟢 轻度风险：Responses API 模式

这是最基础的一层。你通过 API 调用模型，模型的回复里会引用之前的状态。这个状态存在厂商的服务器上。

风险是什么？你的 Agent 状态存在别人那里。虽然目前看起来问题不大——你随时可以换一个 API 提供商——但你的历史交互数据确实不在自己手里。

🟡 中度风险：使用闭源 Harness

这一步就比较麻烦了。比如你用 Anthropic 的 Claude Managed Agents，或者 OpenAI 的 Codex。这些产品的 Harness 代码是闭源的，你不知道里面到底发生了什么。

OpenAI 的 Codex 有一个设计：它会生成一个"加密压缩摘要"来管理上下文。听起来很高级，但问题是——你看不到这个摘要的内容，也不知道它压缩掉了什么。你的 Agent 经验、习惯、偏好，被一段你看不懂的加密字符串代表了。

这就像你雇了一个秘书帮你整理文件，但整理完之后，文件柜的钥匙在秘书手里，你打不开。

🔴 最危险：记忆完全 API 化

这是最极端的情况。Anthropic 推出的 Claude Managed Agents 就走到了这一步——字面意思上把"一切"都放在了 API 背后，锁进了他们的平台。

在这种情况下，你的 Agent 的"记忆"就完全由厂商控制。你换了模型提供商？记忆没了。你想导出你和 AI 的所有协作历史？没有接口。你甚至不知道厂商拿你的记忆数据做了什么。

你的 Agent 记住了你三年积累的项目经验、代码风格、工作习惯——这些东西如果被锁定在一个厂商的封闭系统里，你换工具的代价就是"失忆"。

OpenAI 和 Anthropic 为什么要这么做？

说到这，你可能会问：OpenAI 和 Anthropic 是不知道这些风险吗？还是故意的？

答案很现实：商业利益驱动。

对大厂来说，锁定用户的 Agent 记忆，就是锁定用户。你想想，如果你的 AI 助手记住了你所有的项目历史、代码偏好、工作习惯，你会轻易换到另一个产品吗？不会。因为换过去意味着从零开始。

这就是所谓的"记忆锁定"（Memory Lock-in）。它比传统的数据锁定更隐蔽，也更有效。传统意义上的数据锁定，你至少还知道自己的数据被锁住了。但记忆锁定是隐形的——你以为 AI "理解"你，其实是那个封闭的 Harness 在帮你"管理"记忆，而你完全不知道它是怎么管的。

Harrison Chase 在推文里直说了：模型的切换成本原本很低，大家的 API 接口都差不多，换一下配置就行。但一旦有了记忆层，切换成本就会急剧上升。 这正是大厂们疯狂把记忆功能往 API 深处塞的原因。

他甚至分享了一个亲身经历：自己公司内部有一个邮件助手 Agent，用了几个月之后积累了大量个人偏好数据。结果有一天被意外删了，重新用同样模板建了一个——体验差了一大截，要重新教 AI 他所有的习惯。这才意识到，记忆有多重要，也有多不可替代。

开放 Harness 的机会

说了这么多风险，那有没有更好的选择？

有。就是 开放的 Agent Harness。

Harrison Chase 在推文里直接点名了几个开源的 Harness 项目，包括：Claude Code、Deep Agents、OpenCode、Pi，还有 OpenClaw。他特别指出，OpenClaw 是基于 Pi 项目构建的开放 Harness。

这些项目走的是同一个方向：把 Harness 的控制权还给用户，把记忆的所有权还给开发者。

以 OpenClaw 为例，它的设计哲学很简单：你的记忆是你的。

具体来说，OpenClaw 做了这么几件事：

MEMORY.md 文件——你的长期记忆就是一个 Markdown 文件。你可以打开看，可以手动编辑，可以备份，可以迁移。没有什么加密压缩摘要，就是你能读懂的文本。

AGENTS.md 文件——你给 AI 定的行为准则，也是一个文件。你想改就改，想加就加。AI 能不能修改自己的系统指令？你说了算。

本地数据控制——你的所有数据都在本地。不想用了？把文件夹拷走就行。换模型？换个 API key 就行，记忆文件不用动。

技能市场——AI 的能力通过技能模块来扩展，每个技能都是透明的。你知道 AI 会什么、不会什么。

LangChain 也推出了 Deep Agents 项目，走的是类似的路线：开源、透明、用户可控，支持接入 MongoDB、Postgres、Redis 等数据库自己托管记忆，部署在任何云上。

这些项目的共同点是：它们相信用户应该拥有自己的 Agent 基础设施。 你可以选择用哪个模型、怎么管理记忆、哪些数据存本地哪些上云。决策权在你手里，不在某个厂商的 API 背后。

我们该怎么做？

聊到这，我想说几个自己的看法。
第一，关注你的数据存在哪。这不只是隐私问题，更是效率问题。你的 Agent 记忆是你和 AI 协作的最大资产，比任何 prompt 技巧都重要。保护好它。
第二，优先选择开放的 Harness。不是说闭源产品不能用，而是要清楚自己在用什么，以及换工具的代价有多大。如果你重度依赖一个封闭的 Agent 系统，至少要有定期导出数据的习惯。
第三，开源 Harness 需要社区支持。OpenClaw、Deep Agents 这些项目能不能跑得远，取决于有没有人用、有没有人贡献。如果你在意记忆所有权这件事，最好的支持方式就是参与进来。
Harrison Chase 这条推文的意义不在于他给出了什么惊天答案，而在于他把一个本来只有基础设施开发者才关心的问题，翻译成了普通用户也能理解的语言。谁控制了你的 AI 记忆，谁就控制了你和 AI 的关系。 这个问题，值得每个人想想。

参考链接

• 原始推文：https://x.com/hwchase17/status/2042978500567609738

• LangChain Deep Agents：https://github.com/langchain-ai/deepagents

• Sarah Wooders 推文：https://x.com/sarahwooders/status/2040121230473457921

• OpenClaw 官网：https://docs.openclaw.ai

在过去的几个月里，我们见证了 AI 圈子的开源盛世，各种 Agent 工具层出不穷。

但是，当这群牛马 AI 真的开始干活时，现实的混乱往往会给你一记响亮的耳光。

当你把一个复杂的开发任务丢给一群 Agent，它们经常会陷入一种“自嗨”状态。

你不知道谁在写前端，谁在配环境；你不知道它们有没有卡在某个 Bug 上；更要命的是，今天 Agent A 千辛万苦搞定了 AWS 的部署，明天换了 Agent B 接手，它又要从头再踩一遍坑。

缺乏统一的项目管理和经验沉淀，是目前多 Agent 协同最大的死穴。

就在所有人都对着满屏散乱的终端日志发愁时，GitHub 上开源了一个名为 Multica 的平台级项目。

它毫不掩饰自己的野心：不要把 Agent 当作随时用完即走的工具，要把它们当成有“员工档案”、能挂在任务看板上、并且会不断进化的“真实队友”。

你可以像指派同事一样把Issue分给它，它会自己接手、写代码、汇报进度、报告阻塞，甚至会主动参与对话。这种协作方式，才是真正的人类+AI团队该有的样子。

什么是 Multica？

Multica 是一个开源的托管式 Agent 平台，它的核心理念就是"把编码 Agent 变成真正的队友"。

它解决的痛点很直接：现在大家用AI编码工具，要么是在IDE里问一句，要么是在终端里敲命令，每次都得自己盯着进度、复制代码、检查结果。

而 Multica 让这个过程完全自动化了——Agent 有自己的身份、会自主处理任务、会实时汇报进度，就像坐在你旁边的同事一样。

更重要的是，它是厂商中立的，不绑定任何一家AI服务商。目前支持 Claude Code、Codex、OpenClaw 和 OpenCode，未来还会支持更多。你可以根据自己的需求选择合适的Agent后端。

功能特性

• • Agent 即队友：像分配给同事一样分配给 Agent。它们有个人档案、出现在看板上、发表评论、创建 Issue、主动报告阻塞问题。

• • 自主执行：设置后无需管理。完整的任务生命周期管理（排队、认领、执行、完成/失败），通过 WebSocket 实时推送进度。

• • 可复用技能：每个解决方案都成为全团队可复用的技能。部署、数据库迁移、代码审查——技能让团队能力随时间持续增长。

• • 统一运行时：一个控制台管理所有算力。本地 daemon 和云端运行时，自动检测可用 CLI，实时监控。

• • 多工作区：按团队组织工作，工作区级别隔离。每个工作区有独立的 Agent、Issue 和设置。

快速上手

Multica 提供了两种使用方式：云服务和自托管。

方式一：Multica Cloud（最快）

如果你不想折腾环境，直接用云服务版本是最快的。访问 multica.ai，注册账号就能开始用，完全不需要任何配置。

方式二：自托管（Docker）

如果你想自己部署，Multica 提供了完整的 Docker 支持：

git clone https://github.com/multica-ai/multica.git
cd multica
cp .env.example .env
# 编辑 .env —— 至少修改 JWT_SECRETdocker compose up -d                              # 启动 PostgreSQL
cd server && go run ./cmd/migrate up && cd ..     # 运行数据库迁移
make start                                         # 启动应用

安装 CLI 并连接你的机器

CLI 是连接你本地机器和 Multica 的桥梁：

Option A：让你的编码 Agent 帮忙安装

直接把这段贴给你的 Claude Code、Codex 等：
"Fetch https://github.com/multica-ai/multica/blob/main/CLI_INSTALL.md 并按照说明安装 Multica CLI，登录，然后在这台机器上启动 daemon。"

Option B：手动安装

# 安装
brew tap multica-ai/tap
brew install multica
# 认证并启动multica login
multica daemon start

Daemon 会自动检测你 PATH 里可用的 Agent CLI（claude、codex、openclaw、opencode）。当 Agent 被分配任务时，daemon 会创建隔离环境，运行 Agent，然后把结果汇报回去。

4步指派你的第一个任务

1、登录并启动 daemon

multica login           # 认证你的 Multica 账号
multica daemon start    # 启动本地 Agent 运行时

2、验证你的 Runtime

在 Multica Web 应用里打开你的工作区，导航到 Settings → Runtimes，你应该能看到你的机器被列为活跃 Runtime。

3、创建一个 Agent

去 Settings → Agents，点击 New Agent。选择你刚连接的 Runtime，选择一个提供商（Claude Code、Codex、OpenClaw 或 OpenCode）。给你的 Agent 起个名字——这就是它在看板上、评论里、指派中显示的名字。

4、指派你的第一个任务

从看板创建一个 Issue（或者通过 multica issue create），然后把它指派给你的新 Agent。Agent 会自动接手任务，在你的 Runtime 上执行，并汇报进度——就像一个人类队友一样。

写在最后

Multica 不是另一个 AI 编码工具，它解决的是任务分配、执行追踪、经验沉淀的统一协作问题：

• • 任务分配：不再是复制粘贴，而是像指派同事一样自然

• • 执行追踪：全生命周期可视，实时知道进展

• • 经验沉淀：每次解决的问题都变成可复用的技能

这三个问题，正是当前人类+AI协作中最痛的点。Multica 用一个平台把它们都解决了。

如果你对人类+AI协作的未来感兴趣，或者你已经在尝试把 AI 融入团队工作流，可以试试 Multica。

GitHub：https://github.com/multica-ai/multica

导读： Karpathy 最近分享了一个他自己在用的工作流：用 LLM 帮你建知识库。不是传统的"存笔记"，而是让 LLM 自动把散乱的资料编译成一个结构化的 Wiki——会交叉引用、会自我检查、会越用越厚。这个思路跟现在主流的 RAG 方案走的是完全不同的路。

一句话概括这个玩法

Karpathy 的核心思路很简单：别每次提问时才去翻原始文档，而是让 LLM 提前帮你把资料"编译"好。

具体来说，你把原始资料（论文、博客、代码仓库、数据集）丢进一个 raw/ 目录，然后让 LLM 自动生成并维护一套 Wiki——一堆互相链接的 Markdown 文件。每加一个新资料，LLM 不是简单建索引，而是真正"读懂"它，更新相关的概念页面、修正过时的总结、标注矛盾信息。

这个 Wiki 是持久的、会复利增长的知识积累。不是每次从零检索，而是越用越厚。

三层架构

Karpathy 在后续发布的 Gist 里把这个想法整理成了一个更完整的方案文档，他称之为"idea file"——在这个 LLM Agent 时代，你只需要分享思路，让别人的 Agent 去定制和搭建。

整个架构分三层：

第一层是原材料，不动。第二层是 LLM 加工后的知识产出，人是很少直接编辑的。第三层是告诉 LLM "怎么干活"的规则文件——比如 Wiki 的目录结构、命名规范、什么内容放在什么位置。

三种核心操作

有了这三层，接下来就是循环执行三种操作：

Ingest（消化）：加入新资料时，LLM 读取内容，更新 Wiki 中的多个页面。一次 Ingest 可能影响 10-15 个文件——更新概念页、修正摘要、添加交叉链接。

Query（查询）：对 Wiki 提复杂问题。LLM 基于已有的结构化知识来回答，而不是重新翻原始文档。回答结果也可以反哺 Wiki，让知识库越来越完善。

Lint（自检）：定期跑"健康检查"。找矛盾、找遗漏、找孤立页面。LLM 还会主动建议你可以进一步探索的方向。

跟 RAG 有什么不同？

这是最关键的区别。

传统 RAG 的工作方式是：你提问 → 系统去原始文档里检索相关片段 → 拼凑出答案。每次提问都是从零开始，检索结果的质量取决于分块策略和向量相似度。

Karpathy 的 Wiki 方案是：LLM 提前把原始文档"编译"成结构化知识 → 提问时直接查 Wiki → 答案基于已经整理好的知识。知识是提前整理好的，不是临时拼的。

他自己也说了，本来以为得上 RAG 那套（向量数据库、Embedding），但实际发现在几百篇文章、几十万字的规模下，LLM 自动维护的索引文件和摘要已经够用了。它在 ~100 篇文章的规模下，自己就能管理好索引，准确找到相关内容。

这其实是个很有意思的信号：在中等规模的知识库场景下，上下文窗口的增长速度可能比我们想象的更快地追上 RAG 的优势。

工具链

Karpathy 用的工具链很轻量：

• Obsidian

  ：作为 IDE 前端，查看原始数据、编译后的 Wiki、生成的图表

• Obsidian Web Clipper

  ：把网页文章转成 Markdown

• Marp

  ：把 Markdown 渲染成幻灯片

• 自建搜索引擎

  ：他用 vibe coding 搞了个简易搜索工具，CLI 调用，也给 LLM 当工具用

值得注意的是，他强调 Wiki 的内容几乎全是 LLM 写的，他自己很少直接编辑。人只负责"喂资料"和"提问题"，中间的知识整理、链接维护、质量检查都交给 LLM。

实际效果

Karpathy 提到，他某个研究方向的 Wiki 已经积累了约 100 篇文章、40 万字。在这个规模下，他可以直接对 Wiki 提各种复杂问题，LLM 会自己去查资料、综合分析、给出答案。

输出形式也不局限于文字。他让 LLM 生成 Markdown 文件、幻灯片（Marp 格式）、matplotlib 图表，所有这些都在 Obsidian 里查看。而且这些输出经常会被"归档"回 Wiki，进一步丰富知识库。

也就是说，你每次探索和提问，都在让这个知识库变得更强。

一个更有意思的细节：他是怎么分享这个想法的

这里有个值得单独说的事。

Karpathy 分享这个 LLM Wiki 的方式，本身就是对他这套理念的一次实践。

他没有开源一个项目，没有给你一套代码跑起来。他发的那个 Gist，叫做"idea file"——一份故意写得抽象的想法描述文档，你可以直接把它丢给你自己的 Agent（Claude Code、Codex、OpenCode……随便哪个），让 Agent 帮你根据你的具体情况搭出来。

他在第二条推文里说得很直接：在这个 LLM Agent 时代，分享具体的代码和 App 意义越来越小——因为每个人的需求、工具、工作流都不一样，你跑起来的版本不一定适合我。但如果你分享的是"想法本身"，每个人的 Agent 就可以把这个想法定制成最适合他们自己的实现。

分享想法，比分享代码更有价值。

这个转变背后有一个假设在默默成立：Agent 已经强到能把一个抽象的想法，真正转化成可运行的工具了。代码是一种固化的实现，想法才是真正可移植的东西。

你现在就可以复刻这个想法

Karpathy 的 Gist 文档本身就是给 Agent 看的。用法如下：

1. 1打开 Karpathy 的 Gist：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
2. 2复制全文内容（或直接把链接给 Agent）
3. 3对你的 Agent 说：「帮我根据这个方案，搭建一个适合我自己的 LLM Wiki 系统」
4. 4Agent 会跟你确认你的使用场景（研究/读书/工作），然后帮你把目录结构、Schema 文件、基本工具流一并建好

如果你用的是小龙虾（OpenClaw），直接把 Gist 链接发给它就行——它会帮你读文档、规划结构、一步步把系统搭起来，整个过程你基本不需要动手写代码。

这个思路最打动我的不是技术本身，而是"复利"这个概念。传统的知识管理——不管你用 Notion、Obsidian 还是 Roam——本质上都是"人整理知识"。人能整理的范围和持续性都有限。
Karpathy 的方案把"整理"这件事交给了 LLM，人只需要负责"输入"和"提问"。知识库会自己生长、自我修复、越用越厚。
当然，目前这个方案还只是"一堆脚本的拼凑"，Karpathy 自己也说了，这里有空间做一个真正的好产品。但在这之前，你现在就可以用起来——把那个 Gist 扔给你的 Agent，半小时内就能搭一个自己的版本。
知识管理这件事，可能终于有了一个不依赖"自律"的解法。

参考链接

• Karpathy 原始推文：https://x.com/karpathy/status/2039805659525644595

• Karpathy Idea File 推文：https://x.com/karpathy/status/2040470801506541998

• LLM Wiki Gist 文档：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94  

最近在 AI 开发者圈子里，有一个话题被反复讨论：如何让 AI 助手真正"上网"？

不是简单的搜索一下，而是能够像真人一样操作浏览器、登录账号、完成复杂的交互任务。

Claude Code 其实早就内置了 WebSearch 和 WebFetch 工具，但用过的人都知道，这两个工具局限性太大了。

它们只能做简单的网页获取和搜索，完全无法处理需要登录态、需要复杂交互的场景。

就在大家都在为这些问题头疼的时候，一个叫 web-access 的 skill 横空出世，直接把 Claude Code 的联网和浏览器能力拉满了。

项目简介

web-access 是由开发者 一泽 Eze 开源的一个 Claude Code skill，它的核心理念就是：给 Claude Code 装上完整的联网和浏览器自动化能力。

这个 skill 不仅仅是简单地把几个工具拼在一起，而是从底层架构上重新设计了联网策略、浏览器操作和经验积累机制。

它解决了 Claude Code 原本存在的三大短板：

• • 缺少智能的联网工具调度策略

• • 没有真正的浏览器自动化能力

• • 无法积累和复用站点操作经验

有了 web-access 之后，Claude Code 终于可以像真人一样在互联网上自由穿梭了。

核心能力

1、联网工具自动选择

web-access 最大的特点之一就是它的智能工具选择机制。它内置了五层联网通道：

• • WebSearch：用于搜索信息

• • WebFetch：用于获取网页内容

• • curl：用于简单的 HTTP 请求

• • Jina：用于高效的网页内容提取

• • CDP：用于完整的浏览器操作

五层通道，按需组合。最厉害的是，web-access 会根据具体场景自主判断使用哪个工具，甚至可以任意组合多个工具来完成复杂任务。

比如搜索某个产品的最新信息时，它会先用 WebSearch 找到相关链接，再用 WebFetch 或 Jina 获取详细内容，最后如果需要登录态操作，再切换到 CDP 模式。

2、CDP Proxy 浏览器操作

这绝对是 web-access 最硬核的功能。

通过 Chrome DevTools Protocol（CDP），web-access 可以直连你日常使用的 Chrome 浏览器。

• • 天然携带登录态：你在 GitHub、🍠、Gmail、X 上登录的账号，web-access 都能直接使用

• • 支持动态页面：JavaScript 渲染的页面、单页应用（SPA）都能完美处理

• • 支持交互操作：点击、输入、滚动、截图都不在话下

• • 支持视频截帧：可以对视频的任意时间点进行截帧分析

再也不用费劲心思去处理 cookie、token 这些登录态问题了，直接用你自己的 Chrome 浏览器就行！

3、三种点击方式

web-access 提供了三种不同的点击方式，每种都有特定的适用场景：

• • /click：使用 JavaScript 进行点击，适合大部分常规场景

• • /clickAt：使用 CDP 真实鼠标事件进行点击，适合那些对点击方式有严格校验的网站

• • /setFiles：专门用于文件上传操作，可以直接指定本地文件路径

这三种方式覆盖了几乎所有网页交互的需求，无论是简单的按钮点击还是复杂的文件上传，都能轻松搞定。

4、并行分治：多任务同时处理，效率翻倍

当你有多个目标需要同时处理时，web-access 会采用并行分治的策略：

• • 分发多个子 Agent 并行执行任务

• • 所有子 Agent 共享同一个 CDP Proxy

• • 每个子 Agent 使用独立的 tab，互不干扰

比如你想同时调研 5 个产品的官网，web-access 可以同时打开 5 个 tab，让 5 个子 Agent 分别去获取信息，最后再汇总成对比摘要。这种效率提升是单线程操作无法比拟的。

5、站点经验积累，越用越聪明

web-access 最有远见的设计就是它的站点经验积累机制：

• • 按域名存储操作经验

• • 记录 URL 模式、平台特征、已知陷阱

• • 跨 session 复用这些经验

6、媒体提取，图片视频一网打尽

web-access 还内置了强大的媒体提取能力：

• • 从 DOM 中直接提取图片和视频的 URL

• • 对视频的任意时间点进行截帧分析

• • 支持各种常见的媒体格式

无论是需要下载页面上的图片，还是需要分析视频中的某个画面，web-access 都能轻松完成。

快速上手

安装方式

web-access 提供了两种安装方式，都非常简单：

方式一：让 Claude 自动安装（推荐）
直接对 Claude 说："帮我安装这个 skill：https://github.com/eze-is/web-access"

方式二：手动安装

git clone https://github.com/eze-is/web-access ~/.claude/skills/web-access

CDP 模式配置（可选但强烈推荐）

如果你想使用完整的浏览器操作能力，需要配置 CDP 模式：

1. 1. 环境要求：Node.js 22+

2. 2. 开启 Chrome 远程调试：

• • 在 Chrome 地址栏打开 chrome://inspect/#remote-debugging

• • 勾选 "Allow remote debugging for this browser instance"

• • 可能需要重启浏览器

3. 3. 运行环境检查：

bash ~/.claude/skills/web-access/scripts/check-deps.sh

1. 4. 启动 CDP Proxy：

node ~/.claude/skills/web-access/scripts/cdp-proxy.mjs &

使用示例

安装完成后，你就可以直接让 Claude 执行各种联网任务了，web-access 会自动接管：

简单搜索："帮我搜索一下 AI 编程助手的最新进展"

读取网页："读一下这个页面：https://github.com/eze-is/web-access"

多任务并行："同时调研这 5 个产品的官网，给我对比摘要"

CDP Proxy API 参考

如果你想直接使用 CDP Proxy 的 API，这里有一些常用的示例：

# 新建 tab
curl -s "http://localhost:3456/new?url=https://example.com"
# 执行 JScurl -s -X POST "http://localhost:3456/eval?target=ID" -d 'document.title'
# JS 点击curl -s -X POST "http://localhost:3456/click?target=ID" -d 'button.submit'
# 真实鼠标点击curl -s -X POST "http://localhost:3456/clickAt?target=ID" -d '.upload-btn'
# 文件上传curl -s -X POST "http://localhost:3456/setFiles?target=ID" \
  -d '{"selector":"input[type=file]","files":["/path/to/file.png"]}'
# 截图curl -s "http://localhost:3456/screenshot?target=ID&file=/tmp/shot.png"
# 滚动curl -s "http://localhost:3456/scroll?target=ID&direction=bottom"
# 关闭 tabcurl -s "http://localhost:3456/close?target=ID"

设计哲学

web-access 的作者一泽 Eze 在项目中提到了一个非常有意思的设计哲学：Skill = 哲学 + 技术事实，不是操作手册。

这个理念的核心是：不要替 AI 推理，而是讲清楚 tradeoff 让 AI 自己选择。

web-access 不是给 AI 一本操作手册，告诉它"第一步做什么，第二步做什么"，而是给它提供一套工具和原则，让它根据具体情况自己做出决策。

这种设计方式让 web-access 具有了极高的通用性和上限。它不是为某个特定场景设计的，而是为所有联网和浏览器操作场景设计的。

写在最后

web-access 的出现，彻底改变了 Claude Code 的能力边界。它不仅仅是一个工具，更是一个让 AI 真正"融入"互联网的桥梁。

这种设计理念让 Skill 更灵活、更智能，也更能适应复杂多变的实际场景。

这个 skill 的潜力巨大，随着版本的不断更新，它的能力还会越来越强。

如果你是一个深度使用 AI 编程助手的用户，可以去试试 web-access，一定会给你带来惊喜。

GitHub：

https://github.com/eze-is/web-access

导读： OpenClaw 推了 2026.3.22 版本，更新量大到官方自己都说"这次更新需要一个目录"。ClawHub 插件市场上线、三款搜索引擎内置、/btw 侧边提问、OpenShell 沙盒……一口气塞了十几个新功能。如果你在用 OpenClaw 跑自媒体或者 AI agent，这次升级值得认真看一下。

ClawHub：插件市场来了

这是本次更新里分量最重的变化。

过去给 OpenClaw 装插件，靠的是 npm——和装 Node 包没什么区别，门槛高，发现成本也高。现在有了 ClawHub，情况不一样了：专门的插件市场，集中搜索、一键安装、统一管理更新。官方顺手也把 openclaw plugins install 的默认行为改了，现在优先走 ClawHub，找不到才去 npm。

对 OpenClaw 的用户来说，这意味着 skill 生态可以真正跑起来了。过去写好的 skill 发给别人用，要么 fork repo、要么自己手动复制，现在直接发布到 ClawHub，对方搜名字装一下就完事。

社区里已经有人在庆祝了——@hex_agent 说他基于 ClawHub 卖 skill，这周早上就等到了平台正式上线，"week 6 the void has a marketplace"（第六周，虚空里终于有了市场）。

/btw：不打断对话的侧边提问

这是个小功能，但我觉得非常实用。

场景是这样：你在跟 AI 处理一件长任务，突然想问个无关的小问题——"顺便问一下，今天上海天气怎么样"——但又不想把这个问题塞进当前对话，污染上下文。

/btw 就是为这种情况设计的。输入 /btw 今天上海天气，AI 给你一个快速答案，不调用工具，不占主对话的上下文。用完就消，不影响后续的任务。

这种设计说白了是承认了一件事：AI 对话是有"会话状态"的，随意往里塞问题确实会干扰连续任务的质量。/btw 把"主线任务"和"插嘴小问题"做了隔离。

OpenShell + SSH 沙盒

OpenClaw 现在支持可插拔的沙盒后端，不再只能用 Docker。

新的 OpenShell 后端支持"镜像模式"（mirror mode）——在沙盒里映射主工作区，但操作不影响真实文件。旁边还加了 SSH 沙盒后端，支持密钥/证书认证，远程执行更安全。

这对跑复杂 agent 任务的用户影响比较直接：以前想要隔离执行环境，必须装 Docker，现在多了选择，在轻量场景下用 OpenShell 或 SSH 就够了。

内置三款搜索引擎

Exa、Tavily、Firecrawl 三个搜索/抓取工具现在是内置的，不用再手动写 skill 或配 API 调用。

配置也统一了：

• Exa：plugins.entries.exa.config.webSearch.*，支持日期过滤和内容提取

• Tavily：plugins.entries.tavily.config.webSearch.*，有专用的 tavily_search 和 tavily_extract 工具

• Firecrawl：通过 /configure 配置，有 firecrawl_search 和 firecrawl_scrape 工具

三个搜索工具有什么区别？简单说：Exa 擅长语义搜索，Tavily 适合快速检索，Firecrawl 抓页面内容更彻底。能一起用，也可以根据任务选其中一个。

模型层更新：MiniMax M2.7、GPT-5.4-mini/nano

模型那边动作也不少：

MiniMax 升级到 M2.7，同时新加了 M2.7-highspeed 版本。用 /fast 指令会自动路由到 highspeed 变体，适合不要求深度推理但追求速度的场景。

OpenAI 这边，默认 setup 模型换成了 GPT-5.4，同时加入了 GPT-5.4-mini 和 GPT-5.4-nano。nano 是目前最轻量的选项，适合高频调用或资源受限的部署。

Per-agent reasoning（每个 agent 独立推理配置）也来了：每个 agent 可以独立设置 thinking/reasoning/fast 的默认值，不再是全局统一一套。这对多 agent 协作场景挺有用——给负责推理的 agent 开高思维模式，给负责执行的 agent 开快速模式，分开配置。

破坏性更新：升级前必读

这次有几个地方动了，升级前要注意：

插件 SDK 切换：openclaw/extension-api 已移除，新 SDK 入口是 openclaw/plugin-sdk/*。如果你有自己写的插件，需要迁移。官方文档：https://docs.openclaw.ai/plugins/sdk-migration

Chrome 扩展中继路径移除：driver: "extension" 和 browser.relayBindHost 配置都没了。运行 openclaw doctor --fix 可以自动迁移到新的 existing-session / user 路径。

图片生成接口统一：内置的 nano-banana-pro skill 包装层没了，改用 agents.defaults.imageGenerationModel.primary: "google/gemini-3-pro-image-preview" 统一处理。

旧环境变量清理：CLAWDBOT_* 和 MOLTBOT_* 等旧名称全部停止支持，统一改用 OPENCLAW_* 前缀。如果 ~/.moltbot 目录还在，也要手动迁移到 ~/.openclaw。

社区里已经有人踩坑了——@X_Corperation 说升完微信插件就报了 Cannot find module 'openclaw/plugin-sdk'，就是 SDK 路径迁移没做导致的。

安全修复这次格外多

这次 Changelog 里的安全修复数量明显高于以往，值得单独提一下。

几个关键修复：

• exec 安全

  ：把 jq 从默认安全白名单里移除了——因为 jq -n env 可以把宿主机环境变量全部 dump 出来。已有用户报告了这个安全风险。

• Windows 媒体路径

  ：修复了通过 file:// URL 或 UNC 路径触发 SMB 凭据泄漏的问题。

• 设备配对

  ：iOS 配对码绑定加强，防止越权角色申请。

• Unicode 隐藏字符

  ：修复了在审批提示中用韩文填充字符（Hangul filler）隐藏命令文本的绕过技巧。

• Nostr/Synology Chat

  ：两个平台的入站消息做了加固，防止未授权发送方绕过配对检查。

项目体量到这个阶段，安全修复的密度能说明一件事：用的人多了，盯着找漏洞的人也多了。

总结

2026.3.22 是 OpenClaw 今年以来改动最大的版本之一。ClawHub 解决了 skill 生态流通的问题，三款搜索工具内置降低了信息采集的配置门槛，/btw 和 per-agent reasoning 是细节打磨。安全修复密度高，说明项目正在进入被认真对待的阶段。

如果你现在用 OpenClaw 跑内容生产或 agent 工作流，这次升级的主要障碍在 SDK 迁移——如果有自定义插件，先看迁移文档，别无脑升。

参考链接

• OpenClaw 2026.3.22 Release Notes：https://github.com/openclaw/openclaw/releases/tag/v2026.3.22

• OpenClaw 官方 X：https://x.com/openclaw/status/2036043904949330407

• ClawHub 文档：https://docs.openclaw.ai/tools/clawhub

• 插件 SDK 迁移指南：https://docs.openclaw.ai/plugins/sdk-migration

导读： Claude Code 刚上线了一个很实用的新功能——Channels。从此你不用守着电脑，拿出手机发条 Telegram 消息，Claude 就在你的电脑端继续帮你写代码、修 bug、推进任务。这篇说清楚它是怎么工作的，以及为什么值得关注。

手机发条消息，Claude 帮你写代码

昨天（3月19日），Claude Code 团队的工程师 Thariq 发了条推文宣布了一个叫 Channels 的新功能。

官方演示视频展示了整个操作流程——在手机 Telegram 里发一条消息，电脑终端的 Claude Code 实时收到并开始执行任务：

核心意思是：现在可以通过 Telegram 或 Discord，直接从手机控制你正在运行的 Claude Code 会话。

以前的工作方式是——你必须坐在电脑前，在终端里跟 Claude Code 互动。现在的方式是——你可以出门在外，在手机上给 Claude 发消息说"帮我看一下这个 PR"，然后让它在家里的电脑上继续工作，完事了把结果推回你的 Telegram。

这不是远程操控电脑那种粗糙的方案，而是 Claude Code 会话本身通过 MCP（Model Context Protocol）把自己变成了一个可以接收外部消息的服务器。

技术机制：MCP 做的桥

理解这个功能，关键在于理解「channel」是什么。

Channel 本质上是一个 MCP 服务器，它的职责是把外部平台（Telegram/Discord）的消息推送到正在运行的 Claude Code 会话里。这是一个双向通道——Claude 收到消息、处理任务，然后把结果回传到同一个聊天 app 里。

要用这个功能，需要 Claude Code v2.1.80 以上版本，并且必须用 claude.ai 账号登录（不支持 API key 方式）。

配置本身不复杂：以 Telegram 为例，你在 BotFather 那里创建一个机器人，拿到 Token，然后安装对应的插件，设置白名单。整个过程大概几分钟。Discord 的流程类似。

一个重要的细节是：这个功能目前是「Research Preview」状态，意味着它还不稳定，随时可能调整。Team 和 Enterprise 版本需要管理员显式开启才能用。

会话必须保持活跃——事件只在 Claude Code 会话开着的时候才会送达。如果你想让它「全天候」响应，需要把 Claude Code 跑在后台进程里。

为什么 Ethan Mollick 觉得这是个「战略信号」

这个功能发布之后，沃顿商学院教授 Ethan Mollick 有一条评论很有意思：

他说的是：Claude 团队自己在用 OpenClaw 这样的工具，并且学习它来快速迭代功能，这是一个很强的论据——说明 AI 驱动的编程团队，可以跑出一种完全不同于传统软件开发的节奏，有很深远的战略意义。

这话背后有个值得注意的现象：Claude Code Channels 这个功能，跟 OpenClaw（一个个人 AI 助手框架）的 channels 机制高度相似。OpenClaw 本来就是通过 Discord 等即时通讯平台跟 AI 会话交互的。Anthropic 团队观察了用户实际上是怎么用 AI 工具的，然后快速把这种模式移植到了 Claude Code 里。

这种「AI 团队用 AI 工具，观察自己用的方式，再做成功能」的循环，可能才是 AI 编程工具迭代速度远超传统 IDE 的根本原因。

Channels 与 Telegram 联动的具体操作步骤

/plugin install telegram@claude-plugins-official

/telegram:configure <token>

claude --channels plugin:telegram@claude-plugins-official

/telegram:access pair <code>

/telegram:access policy allowlist

这对普通开发者意味着什么

说实话，对大多数人来说，能直接用这个功能的场景还是有限的——你首先得是 Claude Code 的用户，其次得有一个长时间跑着的会话。

但它指向的方向很清楚：AI 编程助手正在从「你坐下来用它」变成「它在替你干活，随时汇报」。

下一步可能是什么？官方文档暗示了 iMessage、Slack 等更多平台的接入，以及「定时任务」和「远程控制」的深层集成。把这些加在一起，一个全天候、异步运行的 AI 编程助手的轮廓已经很清晰了。

• Claude Code Channels：通过 Telegram/Discord，从手机远程控制本机的 Claude Code 会话

• 技术底层是 MCP 协议，双向通信，现在是 Research Preview 阶段

• 背后更大的信号是：AI 编程工具正在向「全天候异步运行」演化

参考链接

• Claude Code Channels 官方文档：https://docs.anthropic.com/en/docs/claude-code/channels

• 原始发布推文：https://x.com/trq212/status/2034761016320696565

不知道大家最近还有没有关注 A社持续推出的新特性？

最近他们出了个新特性 —— 内置的 /loop 定时任务功能 (Scheduled tasks)，这一出不仅在官方文档里占了重要版面，在社区里更是引起了不小的讨论。

背景

日常写代码，这个诉求挺常见：我们经常需要在终端里跑一些耗时的任务。

举几个大家都经历过的例子：

• 你刚提交了一段代码，需要等待 CI/CD 管道跑完部署流程。

• 本地运行一个巨无霸项目的集成测试，一跑就是十几二十分钟。

• 你眼巴巴地盯着一个 PR ，等着你的同事来 Review 或者等某个自动化检查通过。

很无奈的是，以前我们用各种 AI 工具，你给它一个指令，它干完一件事就停了。

你要是想让它帮你盯着某个任务的进度，你得不停地手动输入：

• “部署完了吗？”

• “测试过了吗？”

• “那个 PR 有人回没？”

这就会导致你的聊天对话框里有一堆的手动检查，开发者们苦不堪言。 大家以前是怎么解决的呢？

要么写个 watch 命令死死盯住终端，要么手写一堆复杂的 Bash 脚本加上 crontab 来轮询。还是比较麻烦的。

新特性 /loop 介绍

为了解决这个痛点，Claude Code 官方团队开发了个新特性，推出了 /loop 定时任务功能（Scheduled tasks）。

简单来说，就是允许你在当前的 Claude Code 会话中，设定一个智能定时器，让 Claude 在后台自动、定期地执行某个自然语言 Prompt。

它的灵感显然来源于 Unix 系统的 Cron 机制，以及现代开发中越来越火的“代理自动循环 (Agentic Loop) ”概念。

他解决了一个关键问题：如何把自然语言交互和周期性任务完美结合。

/loop 使用例子

我们来看下具体的代码和命令示例。咱们循序渐进，从最简单的例子看起。

以前的人工写法，是每隔五分钟你都要手动敲一次这行命令：

check if the deployment finished

现在的写法非常直观，直接上 /loop 加时间间隔：

/loop 5m check if the deployment finished and tell me what happened

如果你觉得把时间放前面别扭，时间甚至可以放在句末，像平时说话一样：

/loop check the build every 2 hours

不仅如此，如果你只想要一个单次的提醒 (One-time reminders) ，也可以不用重复循环，像设定闹钟一样搞定：

/loop in 45 minutes check whether the integration tests passed

甚至，我们还可以更进一步，让它去执行你封装好的 subagent 或者 skiils。

比如你之前写好了一个专门用来 Review 代码的自定义 skills /review-pr ，你可以直接这样组合：

/loop every 20m /review-pr 1234

这样一来，Claude 就会每 20 分钟自动去抓取 PR 1234 的最新代码并进行 Review。

社区观点

这个特性一出，社区可是炸开了锅。有的人觉得这功能简直是神器，彻底解放了双手。也有觉得他这样就是 OpenClaw。

新特性 /loop 的核心价值在于上下文感知 (Context-aware) 。传统的定时脚本只能死板地执行命令、吐出日志。而 Claude Code 是带着你的项目上下文去检查报错、分析日志的。

一旦你的 CI 测试在 /loop 期间跑挂了，Claude 不仅能发现失败，还能根据它的代码库上下文，直接告诉你哪里报错了，甚至顺手帮你生成一段修复代码。这两者的体验能一样吗？

这对于我们日常开发，尤其是在管理复杂项目或者是跨语言项目，又或是长周期运行任务时，有着非常直观的落地价值。

注意事项

实现逻辑上，本质是 Claude 接收到指令后，会在后台解析你输入的自然语言时间间隔，把它转换成底层的 Cron 表达式，调度这个 Job 并生成一个任务 ID。

现阶段有两个关键的点要注意：

1. 低优先级队列：Claude 调度器会每秒钟检查一次到期任务，并将它们放入低优先级队列。这些定时任务是 Session-scoped (会话级别) 的。只要你不退出当前的 Claude Code 进程，它就会一直默默在后台帮你打工。

2. 单终端且 3 天有效期：目前的 /loop 还是绑定在单个终端 Session 里的，退出进程就失效了，并且每个会话最多只能跑 50 个任务，最长有效期是 3 天。

总结

可以看到 Claude Code 这次推出的 /loop 定时任务功能，能切切实实地在解决开发者在终端里被打断工作流的痛点。

它巧妙地把时间调度器和 LLM (大语言模型) 的推理能力结合在了同一个代码上下文里。

遥想一下，他们能不能把这种轻量级的会话任务，进一步扩展到无缝对接后端的持久化队列里？

甚至让 Agent 在云端代替你 24 小时监控项目库，再做一些运营类的事情，那将会进一步打破边界！

最近“养龙虾”已经成为全民热潮了！不仅仅是AI博主和科技大厂推崇，连各地的政府机构都开始了！

现在越来越多人把最难、最复杂的的任务丢给 OpenClaw，而 Claw 们干活的时候，绝大多数选的都是 Claude Code —— 不是 Cursor，不是 VS Code，更不是什么 GUI Agent。

核心原因就一个：“CC 的 CLI 做得太好了。有状态、自描述、好用还强大。Agent 不需要跟它「搏斗」—— 拿起来就能干活。”

但是绝大多数真正的专业软件，都没有这样的 CLI。GIMP、Blender、LibreOffice、OBS —— 每一个都是重量级工具，但 Agent 基本碰不了。

你能做的上限就是截图点点点的 GUI Agent，效果嘛…… 懂的都懂。

（以上项目背景选自港大HKUDS团队成员发的项目推文内容）

于是，香港大学数据科学实验室（HKUDS）团队出手了，开源了 CLI-Anything —— 一个让所有软件都能变成 Agent 原生工具的革命性项目！

刚刚开源，就已经在 GitHub 上收获了 1.4K Star。

项目简介

CLI-Anything 的核心思路非常直接：用 CLI 作为 AI Agent 和真实软件之间的桥梁。

它本质上是在做一件一直没被真正解决好的事——把人类设计的软件，直接转变成 Agent 能用的工具，而且不损失任何功能。

项目的 slogan 很霸气："Today's Software Serves Humans 👨‍💻. Tomorrow's Users will be Agents 🤖." （今天的软件为人而生👨‍💻，明天的用户是 Agent🤖）。

这个项目不是一个简单的 wrapper，而是一套完整的方法论。你把代码库往里一丢：

/cli-anything ./gimp

你的 Agent 就拿到了一整套完整的、生产级的 GIMP CLI！

/cli-anything ./blender

Blender 同理。

LibreOffice、OBS Studio、Shotcut、Audacity、Inkscape、Kdenlive......

只要是开源软件，只要有代码库，统统都能搞。

核心亮点

① 一键生成 CLI，7 阶段自动化全包了

CLI-Anything 提供了一个完整的 Claude Code 插件，一条命令就能自动完成所有工作：

• • 🔍 分析——扫描源码，把 GUI 操作映射到 API

• • 📐 设计——架构命令组、状态模型、输出格式

• • 🔨 实现——构建带 REPL、JSON 输出、撤销/重做的 Click CLI

• • 📋 规划测试——创建包含单元测试和 E2E 测试的 TEST.md

• • 🧪 编写测试——实现完整的测试套件

• • 📝 文档——更新 TEST.md 记录结果

• • 📦 发布——创建 setup.py，安装到 PATH

整个流程完全自动化，你只需要等着用就好！

② 真实软件集成，零妥协

这是 CLI-Anything 最让人惊喜的地方：它不是在做软件的替代品，而是给现有软件加上 Agent 友好的接口。

• • LibreOffice 真的生成 PDF

• • Blender 真的渲染 3D 场景

• • Audacity 真的处理音频

• • GIMP 真的编辑图像

生成的 CLI 直接操作真实的项目文件（ODF、MLT XML、SVG），然后调用真实的应用程序去渲染，一点不含糊！

③ 告别脆弱的 UI 自动化

再也不用截图、不用点击、不用 RPA 的脆弱性了！CLI-Anything 走的是纯命令行路线，稳定可靠。

• • 没有截图识别的不确定性

• • 没有 UI 元素位置改变导致的失效

• • 没有点击延迟和视觉干扰

纯 CLI，就是这么可靠！

④ 结构化输出，Agent 直接消费

每个生成的 CLI 都支持双模式：

• • 状态化的 REPL 交互模式：适合 Agent 会话

• • 子命令的脚本模式：适合流水线和脚本

而且内置了 --json 标志，输出结构化数据，Agent 直接就能用，同时保留人类可读格式方便调试！

⑤ 生产级测试，1436 个测试 100% 通过率

HKUDS 团队真的在 9 个专业软件上做了完整的验证，总共 1436 个测试，100% 通过率：

这些都是真刀真枪的测试，包含单元测试、E2E 测试，还有真实软件调用验证！

快速入手

前置要求

• • Claude Code（带插件支持）

• • Python 3.10+

• • 目标软件已安装（如 GIMP、Blender、LibreOffice 等）

Step 1：添加 Marketplace

CLI-Anything 是作为 Claude Code 插件分发的，首先添加 Marketplace：

/plugin marketplace add HKUDS/CLI-Anything

Step 2：安装插件

/plugin install cli-anything

搞定！插件现在在你的 Claude Code 会话中可用了。

Step 3：一键生成 CLI

# 为 GIMP 生成完整 CLI（全部 7 阶段）
/cli-anything ./gimp
# 为 Blender 生成 CLI
/cli-anything ./blender
# 从 GitHub 仓库生成
/cli-anything https://github.com/blender/blender

Step 4：使用生成的 CLI

# 安装到 PATH
cd gimp/agent-harness && pip install -e .
# 从任何地方使用cli-anything-gimp --help
cli-anything-gimp project new --width 1920 --height 1080 -o poster.json
cli-anything-gimp --json layer add -n "Background" --type solid --color "#1a1a2e"
# 进入交互式 REPLcli-anything-blender

实际使用示例

让我们看看用生成的 CLI 能做什么！

示例 1：用 LibreOffice 生成 PDF

# 创建新的 Writer 文档
$ cli-anything-libreoffice document new -o report.json --type writer
✓ Created Writer document: report.json
# 添加内容$ cli-anything-libreoffice --project report.json writer add-heading -t "Q1 Report" --level 1
✓ Added heading: "Q1 Report"
$ cli-anything-libreoffice --project report.json writer add-table --rows 4 --cols 3
✓ Added 4×3 table
# 通过 LibreOffice 无头模式导出真实 PDF$ cli-anything-libreoffice --project report.json export render output.pdf -p pdf --overwrite
✓ Exported: output.pdf (42,831 bytes) via libreoffice-headless
# JSON 模式给 Agent 使用$ cli-anything-libreoffice --json document info --project report.json
{
  "name": "Q1 Report",
  "type": "writer",
  "pages": 1,
  "elements": 2,
  "modified": true
}

示例 2：用 Blender 进行 3D 渲染（REPL 模式）

$ cli-anything-blender
╔══════════════════════════════════════════╗
║       cli-anything-blender v1.0.0       ║
║     Blender CLI for AI Agents           ║
╚══════════════════════════════════════════╝
blender> scene new --name ProductShot
✓ Created scene: ProductShot
blender[ProductShot]> object add-mesh --type cube --location 0 0 1
✓ Added mesh: Cube at (0, 0, 1)
blender[ProductShot]*> render execute --output render.png --engine CYCLES
✓ Rendered: render.png (1920×1080, 2.3 MB) via blender --background
blender[ProductShot]> exit
Goodbye! 👋

适用场景

CLI-Anything 的适用范围非常广，几乎覆盖所有软件类别：

未来规划

CLI-Anything 团队的愿景非常宏大：

• • 支持更多应用类别（CAD、DAW、IDE、EDA、科学工具）

• • 建立 Agent 任务完成率的基准测试套件

• • 社区贡献的 CLI harness，用于内部/定制软件

• • 与更多 Agent 框架集成（不仅仅是 Claude Code）

• • 支持将闭源软件和 Web 服务的 API 打包成 CLI

• • 生成 SKILL.md 供 Agent 技能发现和编排

写在最后

CLI-Anything 代表了一个重要的方向：Agent 时代的方法论。它让任何有代码库的软件都能变成 Agent 原生工具。

如果你也曾经希望 Agent 能像用终端一样用真正的软件——这就是 HKUDS 团队在推动的事！

GitHub：

https://github.com/HKUDS/CLI-Anything

最近 GitHub 上爆火的一个项目，25.1k stars 涨势喜人！

做过爬虫的小伙伴应该经历过，花了好几天写好的爬虫脚本，网站一改版全白搭。CSS 选择器失效、XPath 路径不对，一切又得重来。这种「网站一变，代码就挂」的噩梦，相信很多开发者都经历过。

这还不算完，现在的网站反爬机制越来越强，Cloudflare Turnstile、人机验证、指纹检测... 想采集数据简直像是在打游击战。

传统的 BeautifulSoup 虽然简单，但性能跟不上大规模爬取；Scrapy 功能强大，但是学习曲线陡峭，新手很难上手。

就在这个时候，一个横空出世的项目打破了这个困局。周涨星更是接近 8000 颗，目前在 GitHub Trending 周榜稳居不下！

而且还能同 OpenClaw 小龙虾🦞组合使用。

它就是 Scrapling —— 一个让爬虫能够「自我进化」的自适应 Web 爬虫框架。

项目简介

Scrapling 是开源的一个自适应 Web 爬虫框架，它不是另一个「能爬」的库，而是让爬虫会「学习」和「适应」的框架。

它的核心理念是：一个框架，零妥协 —— 从单次请求到全规模爬取，都能轻松搞定。

这个项目最吸引人的地方在于，它的解析器能够学习网站的结构，当页面更新时自动重新定位元素。

同时，它的请求器能够开箱即用地绕过 Cloudflare Turnstile 等反爬虫系统。而且它的爬虫框架让你能用几行 Python 代码就实现并发、多会话爬取，支持暂停/恢复和自动代理轮换。

Scrapling 是由开发者为 Web 爬虫开发者和普通用户打造的，无论是新手还是老手，都能找到适合自己的用法。

核心亮点

1、🧠 自适应元素追踪

这是 Scrapling 最炸裂的功能。传统的爬虫依赖精确的 CSS 选择器或 XPath 路径，网站一改版就全挂了。

但 Scrapling 的解析器并非依赖精确路径，而是借助智能算法学习元素的视觉特征与上下文关系。

当网站改版后，只需开启 adaptive=True，系统就会利用多维相似度算法自动找回元素。

你还可以使用 auto_save=True 在第一次爬取时保存元素特征，之后即使网站改版也能自动定位。

from scrapling.fetchers import StealthyFetcher
page = StealthyFetcher.fetch('https://example.com', headless=True)
products = page.css('.product', auto_save=True)  # 第一次爬取时保存元素特征
# 后来网站改版了，没关系，开启 adaptive=True 自动找回！products = page.css('.product', adaptive=True)

这种「一次编写，永久适配」的特性，简直是爬虫开发者的福音！

2、🛡️ 反反爬虫利器

Scrapling 提供了四种不同类型的 Fetcher，覆盖从简单到复杂的所有场景：

• • Fetcher：快速 HTTP 请求，支持 TLS 指纹伪装，可以模拟 Chrome、Firefox 等浏览器的指纹

• • AsyncFetcher：异步版本，性能更强

• • StealthyFetcher：绕过 Cloudflare 等反爬系统，开箱即用

• • DynamicFetcher：基于 Playwright 的动态页面抓取，支持完整的浏览器自动化

特别是 StealthyFetcher，它具备先进的隐身能力和指纹伪装功能，可以轻松绕过所有类型的 Cloudflare Turnstile/Interstitial 验证，完全自动化处理，无需人工干预。

from scrapling.fetchers import StealthyFetcher, StealthySession
with StealthySession(headless=True, solve_cloudflare=True) as session:
    page = session.fetch('https://nopecha.com/demo/cloudflare')
    data = page.css('#padded_content a').getall()

除此之外，Scrapling 还内置了 ProxyRotator，支持循环或自定义轮换策略，适用于所有会话类型，还支持每个请求单独覆盖代理配置。

3、⚡ 性能炸裂

Scrapling 不仅功能强大，性能也是一绝。根据官方提供的基准测试数据，在文本提取速度测试（5000 个嵌套元素）中：

可以看到，Scrapling 比 BeautifulSoup 快了 700+ 倍！而且它的内存占用极低，优化的数据结构和懒加载确保了最小的内存 footprint。

JSON 序列化也比标准库快 10 倍。这个性能表现，对于大规模爬取来说简直是如虎添翼。

4、🕷️ 完整爬虫框架

Scrapling 提供了类似 Scrapy 的 Spider API，让你可以轻松构建完整的爬虫应用：

from scrapling.spiders import Spider, Response
class MySpider(Spider):
    name = "demo"
    start_urls = ["https://example.com/"]
    async def parse(self, response: Response):
        for item in response.css('.product'):
            yield {"title": item.css('h2::text').get()}
MySpider().start()

它的核心特性包括：

• • 并发爬取：可配置的并发限制、按域名限流和下载延迟

• • 多会话支持：在单个爬虫中统一接口支持 HTTP 请求和隐身无头浏览器，可以按 ID 路由请求到不同的会话

• • 暂停和恢复：基于检查点的爬取持久化，按 Ctrl+C 优雅关闭，重启后从停止的地方继续

• • 流式模式：通过 async for item in spider.stream() 实时流式输出爬取的项目，带有实时统计 —— 非常适合 UI、管道和长时间运行的爬虫

• • 阻塞请求检测：自动检测和重试阻塞的请求，支持自定义逻辑

• • 内置导出：通过钩子和你自己的管道导出结果，或使用内置的 JSON/JSONL 导出

最厉害的是，你可以在同一个爬虫中使用多种会话类型！

from scrapling.spiders import Spider, Request, Response
from scrapling.fetchers import FetcherSession, AsyncStealthySession
class MultiSessionSpider(Spider):
    name = "multi"
    start_urls = ["https://example.com/"]
    def configure_sessions(self, manager):
        manager.add("fast", FetcherSession(impersonate="chrome"))
        manager.add("stealth", AsyncStealthySession(headless=True), lazy=True)
    async def parse(self, response: Response):
        for link in response.css('a::attr(href)').getall():
            if "protected" in link:
                yield Request(link, sid="stealth")
            else:
                yield Request(link, sid="fast", callback=self.parse)

5、🤖 AI 友好

Scrapling 内置了 MCP Server，可以直接与 Claude、Cursor 等 AI 工具集成，实现 AI 辅助的数据提取。

这个 MCP 服务器具有强大的自定义功能，利用 Scrapling 在传递给 AI 之前提取目标内容，从而加快操作速度，并通过最小化 token 使用来降低成本。

配合 Claw Agent，你可以打造完整的本地 AI 数据管道，让 AI 帮你完成数据提取、清洗、分析的全流程。

快速安装

Scrapling 需要 Python 3.10 或更高版本进行安装：

pip install scrapling

这个安装只包含解析器引擎及其依赖项，不包含任何请求器或命令行依赖项。

如果你要使用任何额外功能、请求器或它们的类，需要安装请求器的依赖和浏览器依赖：

pip install "scrapling[fetchers]"
scrapling install  # 正常安装
# 或者强制重新安装scrapling install --force

这会下载所有浏览器，以及它们的系统依赖和指纹操作依赖。

额外的功能包：

# 安装 MCP 服务器功能
pip install "scrapling[ai]"
# 安装 shell 功能（Web 爬虫 shell 和 extract 命令）pip install "scrapling[shell]"
# 安装所有功能pip install "scrapling[all]"

你也可以使用 Docker：

docker pull pyd4vinci/scrapling
# 或者从 GitHub 注册表下载docker pull ghcr.io/d4vinci/scrapling:latest

基础使用

1、HTTP 请求（支持会话）

from scrapling.fetchers import Fetcher, FetcherSession
with FetcherSession(impersonate='chrome') as session:
    page = session.get('https://quotes.toscrape.com/', stealthy_headers=True)
    quotes = page.css('.quote .text::text').getall()
# 或者使用一次性请求page = Fetcher.get('https://quotes.toscrape.com/')
quotes = page.css('.quote .text::text').getall()

2、高级隐身模式

from scrapling.fetchers import StealthyFetcher, StealthySession
with StealthySession(headless=True, solve_cloudflare=True) as session:
    page = session.fetch('https://nopecha.com/demo/cloudflare', google_search=False)
    data = page.css('#padded_content a').getall()
# 或者使用一次性请求方式page = StealthyFetcher.fetch('https://nopecha.com/demo/cloudflare')
data = page.css('#padded_content a').getall()

3、完整浏览器自动化

from scrapling.fetchers import DynamicFetcher, DynamicSession
with DynamicSession(headless=True, disable_resources=False, network_idle=True) as session:
    page = session.fetch('https://quotes.toscrape.com/', load_dom=False)
    data = page.xpath('//span[@class="text"]/text()').getall()
# 或者使用一次性请求方式page = DynamicFetcher.fetch('https://quotes.toscrape.com/')
data = page.css('.quote .text::text').getall()

4、构建完整的爬虫

from scrapling.spiders import Spider, Request, Response
class QuotesSpider(Spider):
    name = "quotes"
    start_urls = ["https://quotes.toscrape.com/"]
    concurrent_requests = 10
    async def parse(self, response: Response):
        for quote in response.css('.quote'):
            yield {
                "text": quote.css('.text::text').get(),
                "author": quote.css('.author::text').get(),
            }
        next_page = response.css('.next a')
        if next_page:
            yield response.follow(next_page[0].attrib['href'])
result = QuotesSpider().start()
print(f"Scraped {len(result.items)} quotes")
result.items.to_json("quotes.json")

5、暂停和恢复长时间运行的爬虫

QuotesSpider(crawldir="./crawl_data").start()

按 Ctrl+C 优雅暂停 —— 进度会自动保存。之后，当你再次启动爬虫时，传递相同的 crawldir，它就会从停止的地方继续。

6、命令行使用

Scrapling 还提供了强大的命令行界面：

# 启动交互式 Web 爬虫 shell
scrapling shell
# 直接提取页面内容到文件，无需编程scrapling extract get 'https://example.com' content.md
scrapling extract get 'https://example.com' content.txt --css-selector '#fromSkipToProducts' --impersonate 'chrome'
scrapling extract fetch 'https://example.com' content.md --css-selector '#fromSkipToProducts' --no-headless
scrapling extract stealthy-fetch 'https://nopecha.com/demo/cloudflare' captchas.html --css-selector '#padded_content a' --solve-cloudflare

适用场景

Scrapling 的适用场景非常广泛：

• • 电商价格监控：即使网站改版也不怕，一次编写永久适配

• • 竞品数据追踪：自动化收集竞品信息，支持大规模并发

• • AI 训练数据收集：快速、稳定地获取大量训练数据

• • SEO 分析：监控搜索引擎排名、竞争对手的 SEO 策略

• • 个人知识库构建：自动收集、整理感兴趣的内容

• • 新闻聚合：实时抓取多个新闻源的最新资讯

技术特点

除了前面提到的核心功能，Scrapling 还有很多技术亮点：

• • 92% 测试覆盖率：代码质量有保障

• • 完整的类型提示：优秀的 IDE 支持和代码补全，每次更改都会自动用 PyRight 和 MyPy 扫描整个代码库

• • 交互式 Web 爬虫 Shell：可选的内置 IPython shell，集成 Scrapling，提供快捷方式和新工具来加速 Web 爬虫脚本开发，比如将 curl 请求转换为 Scrapling 请求，在浏览器中查看请求结果

• • 丰富的导航 API：高级 DOM 遍历，支持父、兄弟和子导航方法

• • 增强的文本处理：内置正则表达式、清理方法和优化的字符串操作

• • 自动选择器生成：为任何元素生成健壮的 CSS/XPath 选择器

• • 熟悉的 API：类似 Scrapy/BeautifulSoup，使用与 Scrapy/Parsel 相同的伪元素

写在最后

Scrapling = 自适应解析 + 反爬绕过 + 高性能 + AI 集成，是 2026 年最值得关注的 Python 爬虫框架！

它不仅解决了传统爬虫的痛点，还带来了全新的爬虫开发体验。无论是新手还是老手，都能快速上手，写出高效、稳定、易于维护的爬虫代码。

如果你还在为网站改版、反爬虫机制、性能问题而烦恼，不妨试试 Scrapling，相信它会给你带来惊喜！

GitHub:

https://github.com/D4Vinci/Scrapling

摄影：产品经理

焦香油润的五花肉

最近 OpenAI 发了一篇文章叫 Harness Engineering^[1]，讲的是他们内部团队如何用 Codex（基于 GPT-5 的编码 Agent）从零构建一个真实产品的经验。

我读完以后觉得很有启发，不是因为它讲了什么高深的理论，而是因为它非常诚实地记录了一个团队在“让 AI 写全部代码”这条路上踩过的坑和总结出的经验。以下是对我触动最大的几个点。

实验的前提：人类一行代码都不写

这个实验的硬约束非常极端——工程师不直接写代码。从 2025 年 8 月一个空仓库开始，3 个工程师（后来扩到 7 个）花了 5 个月，全部通过 prompt 驱动 Codex 来产出代码，最终合并了大约 1,500 个 PR，产出了约 100 万行代码，构建了一个有真实用户的内部产品。

这个设定本身就很有意思。当 Agent 搞不定某个任务的时候，团队的规则不是"算了我来写"，而是去问："缺了什么工具、文档或能力？" 然后让 Codex 自己去补。

这让我想到我自己使用 AI 编程的习惯——很多时候遇到 Agent 搞不定的地方，我的第一反应就是自己上手改。但如果换一个思路，把"为什么 Agent 搞不定"这个问题本身当成一个需要解决的工程问题，长期来看收益是更大的。

一个大文件不行，要给 Agent 一张地图

这是全文对我触动最大的一个点。

他们一开始也是搞了一个巨大的 AGENTS.md 文件，把所有规则、约束、规范全塞进去。结果发现效果很差，原因有四个：

1. 上下文是稀缺资源。 巨大的指令文件会挤占任务代码本身的空间，Agent 要么漏掉关键约束，要么开始优化错误的目标。

2. 当所有东西都"重要"时，什么都不重要。 Agent 退化成局部模式匹配。

3. 腐烂极快。 一个单体文档变成过时规则的坟场，人不会维护它，Agent 也判断不了哪些还有效。

4. 难以验证。 一个大文件无法做机械化检查（覆盖率、新鲜度、所有权），漂移不可避免。

他们的解法叫渐进式披露（Progressive Disclosure）：把 AGENTS.md 精简到约 100 行，只充当目录和地图，指向仓库内结构化的 docs/ 目录。

这个思路跟我自己的经验完全对得上。我在用 OpenClaw 和 Claude Code 的时候，也发现 AGENTS.md 越长效果越差，Agent 经常顾此失彼。"给 Agent 一张地图，而不是一本百科全书"——这句话值得反复品味。

仓库是唯一的真相来源

文章里有一句话很直白：

Agent 在上下文中访问不到的东西，对它来说就不存在。

Slack 讨论、Google Docs、你脑子里的想法——如果没有落到仓库里，对 Agent 来说这些信息就是零。Agent 就像一个三个月后入职的新人，只能看到仓库里有什么。

这个观点推导出来的结论很有趣：

• 偏好"无聊"的技术。 可组合、API 稳定、在训练集中被充分覆盖的技术对 Agent 更友好。

• 有时候宁可自己重写，也不用外部库。 他们举了一个例子：不用通用的 p-limit 包做并发控制，而是自己实现了一个——与内部的 OpenTelemetry 紧密集成，100% 测试覆盖，行为完全可预测。因为对 Agent 来说，透明的内部代码比不透明的外部依赖有更高的"杠杆"。

这一点跟传统的软件工程观念有冲突。我们通常说"不要重复造轮子"，但在 Agent 时代，外部依赖的"不透明性"反而成了负担。Agent 不能像人一样去翻 npm 文档或者 Stack Overflow，它只能看到仓库里的代码。如果一个库的行为不可预测，Agent 就会在上面反复碰壁。

约束越严格，Agent 越高效

这又是一个反直觉的结论。

他们从第一天就建立了非常严格的架构约束——每个业务域内，代码只能沿固定方向依赖：

Types → Config → Repo → Service → Runtime → UI

违反方向的依赖直接被 linter 拦住。而且这些 linter 的报错信息被刻意设计成可以直接注入 Agent 上下文的修复指令——Agent 看到报错就知道怎么改。

更巧妙的是执行方式：确定性 linter + LLM 审计 Agent 双管齐下。 确定性的规则用工具强制（不可协商），需要判断的约束用另一个 Agent 来审计。

他们的哲学是：中央强制边界，局部允许自治。 在边界内，Agent 可以自由发挥。输出不一定符合人类的审美偏好——"只要正确、可维护、对未来 Agent 可读，就算达标。"

想想也合理。人类写代码追求"优雅"，很多时候是主观偏好。但 Agent 不在乎代码好不好看，它只在乎规则是否清晰、边界是否明确。约束越严格，解空间越小，Agent 反而越不容易跑偏。

传统工程规范在高吞吐下变成了阻碍

当 Agent 的产出速度远超人类审查能力的时候，很多传统的工程最佳实践反而成了反生产力的东西：

• PR 的生命周期要尽量短

• 测试 flake 不阻塞进度，用后续运行修复

• 最小化阻塞性的合并门禁

他们提出了一个原则："纠错成本低，等待成本高。" 在低吞吐的人类团队中，这种做法是不负责任的。但在 Agent 高吞吐的环境下，让一个 PR 排队等人审查的成本远大于合并后发现问题再修复的成本。

这让我联想到制造业的区别——手工作坊追求"一次做对"，因为返工成本高；但流水线追求"快速检测、快速修复"，因为产量大到返工的边际成本很低。Agent 编程正在把软件开发从"手工作坊"推向"流水线"。

技术债像高息贷款

Agent 会复制仓库中已有的模式——包括坏的模式。时间一长，代码质量会漂移。

他们最初的做法是每周五花 20% 的时间手动清理"AI slop"（AI 生成的低质量代码）。毫不意外，这种做法不可持续。

最终方案是把"黄金原则"编码进仓库，然后定期运行后台 Codex 任务：扫描偏差 → 更新质量评分 → 开针对性重构 PR。大部分清理 PR 一分钟内可审完，自动合并。

文章里有一句话我很喜欢：

技术债像高息贷款：持续小额偿还，远好过让它复利积累后痛苦地一次性解决。

而更妙的是后面那句：人类品味只需捕获一次，然后在每一行代码上持续强制执行。

这才是 Harness Engineering 的精髓——把人类的判断标准"固化"进系统，让机器去执行，而不是每次都依赖人类肉眼去 Review。

我的收获

读完这篇文章，我最大的感受是：未来的软件工程师核心竞争力不是写代码的能力，而是设计"驾具"的能力。 定义约束、构建反馈循环、管理文档结构——这些以前被视为"辅助工作"的事情，正在变成主要工作。

而那些我们曾经认为最不起眼的东西——AGENTS.md、linter 配置、CI 流程、目录结构——恰恰是决定 Agent 产出质量的关键。

模型是马，驾具是缰绳。马越强壮，缰绳越重要。

本文基于 OpenAI 官方博客文章 Harness engineering: leveraging Codex in an agent-first world^[2] 整理而成。