在 AI 应用越来越普及的今天，把企业内部的 Word 报告、PPT 方案、Excel 报表、PDF 合同喂给大模型做摘要、提取、分析，已经是很多团队的日常操作。

但每一种格式都像一个独立的"物种"，需要不同的工具链、不同的转换逻辑，出来的 Markdown 质量也是参差不齐。

更糟糕的是，你好不容易找到一个能转 Word 的工具，换个 PPT 就不支持了；找到一个能转 Excel 的，表格合并单元格又处理不好；甚至同一种格式，用不同版本生成的文件，转换结果都不一样。

有没有一个"万能解药"？

Firecrawl 团队用 Rust 写的 anydoc 就是冲着这个目标来的。

这个开源项目在 GitHub 上已经斩获了 13300+ Star，支持 14 种办公格式统一转成 GitHub-Flavored Markdown，转换速度中位数不到 5 毫秒，更关键的是——所有格式转出来的 Markdown 结构完全一致。

项目介绍

anydoc 是 Firecrawl 团队开源的 Rust 文档转换库。

Firecrawl 本身是一家专注于 AI 时代数据提取和网页抓取的公司，他们的核心产品 Firecrawl Parse 已经在处理着大量的文档转换需求。

在实际业务中他们发现，客户的文档格式五花八门：Word、PPT、Excel、PDF、EPUB、RTF、CSV……甚至还有 OpenDocument 格式。

为了给下游的 LLM 提供干净、结构化的 Markdown 输入，团队不得不维护多个转换引擎，每个引擎的输出格式和质量都不一样。

Firecrawl 的联合创始人兼 CTO Nick 提到，"我们决定从零开始写一个库，用统一的架构处理所有格式。"

于是 anydoc 诞生了。它的目标很明确：一个库，14 种格式，统一输出，极速转换。

核心亮点

14 种格式一键通吃

在 Firecrawl 做的基准测试中，anydoc 是唯一能处理全部 14 种格式的工具。其他竞品最多支持 12 种，少的只支持 1-2 种。

具体支持的格式覆盖了办公领域几乎所有主流文件类型：

• • Word：.doc、.docx、.docm

• • PowerPoint：.ppt、.pps、.pot、.pptx、.pptm、.ppsx、.ppsm

• • Excel：.xls、.xlsx、.xlsm、.xlsb

• • OpenDocument：.odt、.ods、.odp

• • 其他：.rtf、.epub、.csv、.pdf

这意味着你不需要再为 Word 准备一个库、为 PPT 准备另一个、为 Excel 再找一个。anydoc 一个就搞定。

所有格式输出一致的 Markdown

anydoc 最核心的设计理念是"共享文档模型 + 单一序列化器"。

它的架构是这样的：每种格式的文档先解析成同一个内部文档模型（包含 blocks、inlines、tables 等结构化节点），然后通过同一个 GitHub-Flavored Markdown 序列化器输出。

这带来了一个非常重要的结果：无论输入是 2003 年的 .doc 文件，还是昨天刚生成的 .pptx，输出的 Markdown 结构完全一致。 标题层级、嵌套列表、合并单元格的表格、脚注、代码块——这些元素在所有格式的转换结果中都能正确保留。

5ms 极速转换

anydoc 是纯 Rust 实现，不依赖任何 ML 模型或外部服务。在 Firecrawl 的基准测试中：

• • 中位数转换时间：4.4-4.7 毫秒

• • 对比 LibreOffice：中位数 1129.5 毫秒，慢了约 245 倍

• • 其他竞品：52-1130 毫秒，慢了约 20-245 倍

这个速度在实际场景中的意义非常大：如果你要批量处理上百份文档，anydoc 可以在几秒钟内完成，而用其他工具可能需要几分钟。

浏览器版本地转换

anydoc 提供了编译成 WebAssembly 的浏览器版本（@firecrawl/anydoc-wasm），文件在浏览器本地转换，永远不会上传到任何服务器。

这对处理敏感文档（合同、财务报表、内部报告等）来说是非常重要的特性。

你可以在自己的 Web 应用中直接集成 WASM 版本，用户上传的文件在本地浏览器中完成转换，零隐私风险。

快速上手

anydoc 提供了 Rust、Node.js、Python 三种主要的编程接口，还有 CLI 工具和 Agent Skill，不同技术栈的开发者都能快速上手。

Node.js 用法

npm install @firecrawl/anydoc

import { toMarkdown, toMarkdownBytes, toDocument } from '@firecrawl/anydoc';
// 从文件路径转换const markdown = await toMarkdown('report.docx');
// 从字节转换，自动检测格式import { readFile } from 'fs/promises';
const bytes = await readFile('report.docx');
const markdown2 = await toMarkdownBytes(bytes);
// 显式指定格式（CSV 等无签名格式需要）const csvBytes = await readFile('data.csv');
const markdown3 = await toMarkdownBytes(csvBytes, 'csv');
// 获取文档模型（保留嵌入资源）const document = await toDocument(bytes);
console.log(document.markdown);
console.log(document.assets);  // 嵌入的图片等资源

Node.js 版本的转换运行在 libuv 线程池上，不会阻塞事件循环，TypeScript 类型定义也随包提供。

Python 用法

pip install firecrawl-anydoc

import anydoc
# 从文件路径转换markdown = anydoc.to_markdown("report.docx")
# 从字节转换with open("report.docx", "rb") as f:
    data = f.read()
markdown2 = anydoc.to_markdown_bytes(data)
# 显式指定格式markdown3 = anydoc.to_markdown_bytes(data, "csv")
# 获取文档模型document = anydoc.to_document(data)
print(document.markdown)
print(document.assets)

Python 版本在转换时会释放 GIL，不会阻塞其他线程，同样提供了类型存根。

Rust 用法

cargo add anydoc

use anydoc::{to_markdown, to_markdown_bytes, Format};
// 从文件路径转换let markdown = anydoc::to_markdown("report.docx")?;
// 从字节转换，自动检测格式let markdown2 = anydoc::to_markdown_bytes(&bytes, None)?;
// 显式指定格式let markdown3 = anydoc::to_markdown_bytes(&bytes, Some(Format::Csv))?;
// 获取文档模型let document = anydoc::to_document(&bytes, None)?;

CLI 工具

不想写代码？直接用命令行：

# 基本用法
npx @firecrawl/anydoc report.docx
# 输出到文件npx @firecrawl/anydoc slides.pptx -o slides.md
# 处理 CSVnpx @firecrawl/anydoc - --format csv < data.csv

Agent Skill

anydoc 还可以作为 Agent Skill 安装到 Claude Code、Codex、Cursor 等 AI 编程助手中：

npx skills add firecrawl/anydoc

安装后，你可以直接在对话中让 AI 帮你转换文档，比如："帮我把这份季度报告转成 Markdown"。

PDF 的特殊处理

anydoc 对 PDF 的处理有一个分层策略：

• • 文本型 PDF：通过内置的 pdf-inspector 库直接提取文本，转换为 Markdown

• • 扫描型 PDF：需要 OCR 处理，anydoc 本身不做 OCR，但可以对接 Firecrawl Parse API 获取 OCR 支持

需要注意的是，PDF 不能用 to_document 方法（因为它不经过文档模型），需要使用 to_markdown_bytes 或 to_markdown。

写在最后

把文档转成 Markdown 这件事，看起来简单，但真正做好并不容易。你需要同时解决格式解析、结构还原、一致性输出、性能优化等多个难题。

anydoc 的价值在于，它不是又一个"凑合用"的转换器，而是用工程化的方式重新定义了这件事的标准：

• • 一个库，14 种格式：不再需要为不同格式维护不同的工具链

• • 5ms 极速转换：在批量处理和实时场景下都能跑得动

• • 统一的 GFM 输出：下游工具和 LLM 不需要做任何适配

• • 本地处理，隐私安全：浏览器版不上传文件，服务器版无外部依赖

• • 活跃的开发生态：Firecrawl 团队持续迭代，社区贡献不断

如果你平时有大量文档需要转给大模型处理——不管是 Word 报告、PPT 方案、Excel 数据还是 PDF 合同，anydoc 都值得放进你的工具箱里试一试。

GitHub：https://github.com/firecrawl/anydoc

摄影：产品经理

地中海风味田园沙拉

最近我看到一项很有意思的实验。

研究者找来几个真实、并且还没有公开答案的AI研究课题，让Agent自己查资料、写代码、跑实验、分析结果。他们给了Agent几天时间和相当可观的算力预算，最后再让真正做过这些课题的研究者评价Agent的成果。

结果不太好。Agent没有产出达到论文标准的研究成果。

研究者还分析了大量运行日志，发现Agent有不少问题：一次实验结果不好，它就过早放弃整个方向；不会合理分配预算；Reviewer已经指出关键问题，它还是沿着原来的路线修修补补；遇到死路时，也不知道回退、修改假设、重新设计实验。

这些现象我都相信，而且非常值得研究。

但如果根据这项实验，直接得出“AI Agent现在还不会做开放式研究”，我会非常谨慎。

因为这种实验最终测到的，从来都不只是AI的研究能力。基础模型、Agent框架、工具、实验设计、操作者水平和人类对照组，全都混在最终结果里面。只要其中一个变量没有控制好，结论就很容易超出证据能够覆盖的范围。

到底用了什么模型？

现在讨论Agent能不能完成一个复杂任务，模型版本已经是一个绕不过去的变量。

不同模型在普通聊天中的差距，有时候看起来只是回答好一点或者差一点。但到了持续几个小时甚至几天的任务中，这些小差距会不断累积。

有的模型更容易忘记最初的目标，有的模型更容易发现前面的假设已经错了；有的模型遇到实验失败会重新规划，有的模型会沿着错误路线继续消耗预算；有的模型可以稳定维护几十步状态，有的模型跑到一半就开始偏离方向。

所以一个Agent实验失败以后，我首先想知道的是：

• 具体用了哪个模型？

• 推理强度怎么设置？

• 上下文怎么管理？

• 允许调用哪些工具？

• 有没有独立的Reviewer？

• 失败以后怎么恢复？

• 预算怎么分配？

把这些信息全部去掉，只留下一句“Agent失败了”，其实没有多少信息量。

同一个基础模型，放进两套不同的Agent框架，最后可能表现得像两个完全不同的系统。模型负责提供推理能力，Agent框架负责维护长期状态、拆解任务、调用工具、验证结果、失败回滚和控制预算。开放式任务，恰好非常依赖这些东西。

因此，一项严谨的Agent研究，首先能够证明的应该是：

在这个模型、这套Agent架构、这些工具和这组资源限制下，系统没有完成这个任务。

这个结论完全没有问题。但能不能进一步概括成“现在的AI做不了这件事”，还需要更多实验来支持。

设计实验的人，真的会用Agent吗？

这个问题可能更加重要。

我以前在一家互联网大厂工作时，接触过一个专门做机器学习和数据挖掘的研究团队。团队里面很多人都是名校硕士、博士，理论基础很好，也有真正的研究能力。他们有些实验会跑几个星期，复杂项目做一两个月也很常见。

后来有一次，我看了他们写的Python代码，印象非常深。

大量重复计算，大量没有必要的循环。明明可以使用集合解决的问题，却在反复遍历列表；明明可以提前计算或者缓存的东西，却每次都重新计算。代码明显是在Jupyter Notebook里面随着实验一点点堆出来的，前面写过的逻辑，后面再复制一次，对时间复杂度和工程结构也没有太多考虑。

其中一些实验如果让我来重构，我认为运行速度提高五倍并不夸张。

这件事情让我意识到，研究能力其实由很多相对独立的技能组成。理论水平、问题选择、实验设计、编程能力、系统工程、数据处理和信息检索，这些能力之间有关系，但远没有强到可以互相替代。

一个机器学习理论很强的人，完全可能写出很差的Python代码。一个很会发论文的人，也可能不擅长构建高效率的实验系统。

到了Agent时代，又多出了一项新的技能：如何组织Agent工作。

这个能力目前被严重低估了。

同样一个模型，有人会写一个巨大的Prompt，然后让Agent自己跑几个小时。有人会先拆分研究问题，给不同方向设置独立的上下文，再设计Reviewer、验证器、检查点和失败回退机制。

有人会让五个Agent同时尝试五种假设，再让第六个Agent专门寻找反例。有人则会让一个Agent从头跑到尾，中间不做任何检查。

如果前者成功、后者失败，我们显然不能把差异全部归因于模型智力。

代码都让AI写，不就解决了吗？

这里马上会有一个很合理的反问：

你举的例子已经过时了。现在最先进的AI写代码已经比绝大部分普通研究员强。如果实验代码、数据处理、实验框架，甚至Agent本身都让AI来写，研究员的工程水平还会影响结果吗？

这个反问非常关键，而且它确实削弱了“研究员代码写得差”这个具体问题的重要性。

如果一个研究团队已经让强模型负责实现实验代码，并且有完整的测试、性能分析、代码审查和结果验证，那么我之前看到的那种低质量Python代码，确实可能大幅减少。

未来的科研工作中，“一个博士因为不会优化Python，导致实验慢五倍”这种事情，很可能越来越少。

但操作者的影响并没有消失，只是往上移动了一层。

过去，研究员亲手写循环。现在，研究员决定让Agent优化什么。

过去，研究员亲手选择数据结构。现在，研究员决定什么结果才算验证通过。

过去，研究员亲手搭建实验框架。现在，研究员需要决定Agent应该探索几条路线、什么时候停止探索、什么情况下重新检查假设，以及Reviewer有没有权限推翻当前路线。

代码可以全部由Agent来写，但下面这些问题，依然要由人或者更上层的系统决定：

• 任务应该怎样拆分？

• 哪些实验可以并行？

• 哪些变量必须控制？

• 什么指标才能提供真正有效的反馈？

• 一次实验失败，究竟是研究假设有问题，还是实验实现有问题？

• 连续三次失败以后，应该继续尝试，还是换一个方向？

• 多个Agent得出冲突结果时，应该相信谁？

• Reviewer提出异议以后，应该补一个实验，还是推翻整个研究设计？

• 什么时候应该增加算力，什么时候继续砸算力已经没有意义？

开放式研究最难的部分，恰好集中在这里。

所以，即使AI解决了代码质量这个底层问题，实验设计者仍然可能搭出一套非常糟糕的Agent系统。

只不过以前的问题表现为O(n²)的循环、重复计算和垃圾Notebook；现在的问题变成了错误的任务拆分、缺失的反馈循环、错误的验证标准和糟糕的停止条件。

甚至还有一个更加隐蔽的风险：Agent写代码太强，反而可能掩盖上层设计的问题。

代码运行得很漂亮，测试全部通过，实验自动化程度很高，最后还生成了一篇结构完整的论文。整个流程看起来非常专业，但研究方向可能从第三个小时开始就已经走偏了。

工程质量高，不代表研究设计也同样高。这两件事情必须分开看。

Agent的能力是一个乘法结果

我现在更愿意把一个复杂Agent系统的最终表现，理解成下面几个因素共同作用的结果：

基础模型 × Agent架构 × 工具质量 × 反馈机制 × 操作者能力

这里不能简单做加法，因为任何一个环节特别差，都会浪费其他环节的能力。

一个很强的模型，如果没有可靠的反馈，很可能非常高效地沿着错误方向跑很远。

一套优秀的Agent框架，如果接入一个能力很弱的模型，也会在真正需要判断力的地方不断失败。

模型、工具和框架全部配齐，如果实验者选择了一个错误的评价指标，系统一样可能优化出毫无意义的结果。

这也是为什么我越来越不喜欢笼统地问：“这个模型会不会做科研？”

科研根本没有一个统一的评分函数。

写代码时，程序能不能运行是反馈；优化性能时，Benchmark可以直接告诉你速度变快还是变慢；数学证明至少还有相对清晰的正确性标准。

开放式研究困难得多。

一个实验结果不理想，到底说明研究思路错了、代码实现错了、数据错了，还是这个异常本身就是最重要的新发现？成熟研究者的价值，很大一部分就体现在这种判断上。

Agent真正的难题，往往出现在没有清晰反馈信号的地方。

人类对照组也不一定靠谱

这类研究还有另一个经常被忽略的问题：到底拿AI和什么样的人比较？

论文里面很容易写“由领域专家完成”，但“领域专家”是一个非常模糊的标签。

同样是机器学习博士，一个人有很强的系统工程能力，会自动化实验、并行探索、搭建完善的数据处理流程；另一个人习惯手工操作，一条路线跑到底。两个人都可能拥有很好的论文记录，但完成同一个计算密集型研究任务，效率很可能相差几倍。

加入Agent以后，这个差距还会继续扩大。

一个研究员让Agent帮自己写一点代码，整体工作方式没有任何变化。另一个研究员则会重新设计整套研究流程：多个Agent并行探索不同假设，一个Agent持续阅读新论文，一个专门寻找反例，一个审查实验设计，还有一个检查结果是否可靠。研究员本人只介入那些真正需要高层判断的环节。

这两个人，都可以在论文里面被归类为“Human + AI”。

但这个标签已经完全无法描述他们之间的区别。

真正值得做的实验

如果要研究Agent对科研的影响，我更希望看到下面这样的2×2实验：

	传统研究流程	Agent原生流程
普通领域研究员	A	B
强工程能力 / Agent高级用户	C	D

这个实验可以回答几个非常重要的问题。

B与A的差距，可以告诉我们Agent对普通研究员有多大帮助。

D与C的差距，可以告诉我们Agent对高水平操作者有多大帮助。

D与B的差距，则能告诉我们一个很少有人认真测量的变量：会不会使用Agent，到底能带来多大的生产力差距。

我怀疑第三个数字未来会非常大。

工具能力越强，不同使用者之间的差距往往越大。大家都有Google，并没有因此拥有相同的信息检索能力；大家都会写Python，工程能力的差距依然巨大；以后所有研究员都能调用同一个顶级模型，也不会自动获得相同的研究效率。

有些人会把Agent当成一个更聪明的聊天机器人。

另一些人会把它当成一支可以编排、验证和并行调度的研究团队。

明明使用的是同一个基础模型，最后的产出却可能像来自两代不同的工具。

真正值得关注的问题已经变了

“AI会不会替代研究员”这个问题太远，也太粗糙。

未来几年更值得关注的变化，很可能是研究人员之间的生产力差距迅速扩大。

一个研究员以前一年只能深入测试三个方向，以后可能同时探索三十个方向。以前大量时间花在查论文、写实验代码、清洗数据和整理结果上，Agent会逐渐接走这些工作。

人的精力会越来越集中在少数真正有价值的判断上：哪个问题值得研究、哪个证据可信、什么时候应该推翻自己的假设、哪个异常值得继续追下去。

如果一个研究员很擅长这些判断，同时又非常善于组织Agent，他的研究效率可能达到另一类研究员的几倍，甚至一个数量级。

这个变化，完全不需要等到所谓的“自主AI科学家”出现。

所以回到最开始那项实验，我仍然认为它非常值得读。它发现的那些失败模式——长期规划能力差、预算管理混乱、不知道及时回退、面对开放问题缺少研究判断——都是真问题。

只是我们在描述结论时，应该更加准确。

一次Agent研究失败，说明的是一个完整系统失败了。接下来真正有意思的工作，是把这个系统拆开，看看到底是模型、Agent框架、工具、反馈机制、任务设计，还是操作者拖了后腿。

只有做到这一步，我们才真正开始回答那个问题：

AI到底会不会做研究？

最近导师问我：你这学期怎么产出这么快？

我没好意思说实话——因为我大部分科研流程，已经交给AI在跑了。

不是用ChatGPT翻译润色那种"AI辅助"，而是从研究问题梳理、文献综述、实验设计、代码编写、数据分析、论文写作、模拟审稿到Rebuttal回复，一整套流程都有专门的AI技能在干活。

今天这篇文章，我想把这些东西分享出来。

不为别的，就是觉得——如果读研的时候有人告诉我这些，我至少能少走两年弯路。

先说个扎心的事实

01

你有没有算过，一篇论文从选题到投稿，时间都花在哪了？

• 查文献、读文献、整理文献：2-3周

• 梳理研究问题、写开题报告：1-2周

• 写代码、跑实验、调参数：看命，1周到3个月不等

• 写论文（Abstract到Conclusion）：2-4周

• 投稿前自查、改格式、补实验：1-2周

• 被拒稿 → 换目标 → 重投：再走一遍

算下来，一篇论文的"有效思考时间"可能只占30%，剩下70%全是重复劳动和流程性杂活。

而最讽刺的是——这些杂活，AI其实都能帮你干。

我做了什么？

02

我花了挺长时间，把目前市面上最好用的10个AI科研Skills全部整理到了一个网站上。

每个Skill都配有：

• ✅ 功能说明（能干什么、不能干什么）

• ✅ 适用场景（什么情况下用最合适）

• ✅ 安装教程（复制粘贴就能装）

• ✅ 使用示例（真实Prompt，直接抄作业）

10个Skills，700+个子技能模块，覆盖全学科。

不是那种"50个AI工具推荐"的水文——每个Skill我都实际用过，网站上写的都是真实体验。

下面挑几个跟大家聊聊。

10个科研Skills，先剧透几个

03

一句话：从"我只有个模糊方向"到"完整论文初稿"，它陪你走完全程。

你只需要给它一个研究方向，它会通过提问帮你：

• 明确研究问题和创新点

• 规划论文结构

• 逐章写作（摘要、引言、方法、实验）

• 做多角色模拟审稿

• 检查引用真实性和论点支撑关系

最狠的是——投稿前可以先让它模拟审稿人挑刺，把审稿人可能提的问题列出来，你提前补好。

相当于自带一个"预审稿"环节。

一句话：给它一个研究方向，它帮你从选题跑到Rebuttal。

这个我愿称之为"读博外挂"——研究方向分析 → 论文阅读 → 创新点生成 → 代码库分析 → 实验设计 → 自动运行实验 → 结果分析 → 论文写作 → 自动审稿 → Rebuttal。

一条龙。

当然，它也贴心地提醒你：别真的完全"睡觉不管"。建议在创新点确定前、修改代码前、大规模实验前设置人工检查点。

很诚实，我喜欢。

一句话：148个技能，生物信息、化学信息、药物发现全覆盖。

单细胞分析怎么做？Scanpy、差异表达、通路富集、科学可视化——一条Prompt搞定，还帮你输出可复现的Python脚本。

科研绘图？直接说"投稿级图片、色盲友好配色、保留误差棒、输出PDF+SVG+300DPI PNG"，它全给你安排上。

一句话：DID、IV、RDD、PSM、合成控制，经济学管理学社会学全都能用。

给它一份数据，告诉它研究问题，它会：

• 检查数据结构和缺失值

• 明确处理组和对照组

• 生成描述性统计

• 做平行趋势检验

• 跑基准回归

• 做稳健性和安慰剂检验

• 分析异质性

• 输出可复现代码、表格和图片

Stata、R、Python三个版本都有。

一句话：550+个Skill，从PubMed检索到Meta分析全覆盖。

生存分析、Cox回归、Kaplan-Meier曲线、ROC、列线图、免疫浸润、WGCNA……医学数据分析常用的方法基本都有。

而且它很清醒——网站明确标注了："医学属于高风险领域，Skill生成的结论不能直接用于临床决策，必须经过医生和统计师审核。"

这种态度，反而让人更信任。

剩下5个，简单列一下：

怎么领？

04

很简单：

👇 扫描下方二维码，添加小助理

发送关键词「科研skills」

小助理会把网站地址 + 快速上手指南一起发给你。

📌 如果你身边有正在读研、读博、做科研的朋友，欢迎转发给TA。这些东西真的能帮到人。

最后说两句

05

我不敢说这些Skill能让你"论文发到手软"——科研的核心还是你自己的判断力、创造力和实验真实性。

但它们确实能把那些重复的、流程化的、消耗你大量时间但不产生核心价值的活儿接过去。

省下来的时间，你用来思考真正重要的问题。

这才叫AI辅助科研，而不是AI替你科研。

好了，不多说了。

👇 去加小助理吧。

如果你觉得这篇文章有用，点个「在看」和「赞」👇转发给你身边搞科研的朋友，TA会感谢你的。

导读： 你问 Agent“最近一个月大家真正在聊什么”，最常见的答案还是网页摘要。Reddit 评论、X 争论、YouTube 转录、GitHub 动态和 Polymarket 赔率散在不同平台，很难放到一起比较。普通网页搜索最容易漏掉的，恰恰是这一层信息。last30days 把它封装成了一个可安装的 Agent Skill。

GitHub： https://github.com/mvanhorn/last30days-skill

last30days 更像一台“社区信号雷达”，而不是另一个通用搜索框。

普通搜索缺的，是“大家正在怎么说”

查一个刚发生的 AI 话题，网页搜索通常先给你新闻、官网和 SEO 文章。这些信息有用，但它们很难回答另一类问题：

开发者最近在抱怨什么？哪个方案在 Reddit 评论区被反复推荐？一段 45 分钟的视频里，真正值得引用的是哪几句话？市场参与者愿意拿真钱押哪一种结果？

手工查也不是不行。开十几个标签页，搜 X，翻 Reddit，拉 YouTube 字幕，再去 GitHub 看提交和 Issue。麻烦在于，各平台的时间、互动数据和表达方式都不一样，最后还是要人肉去重、排序、判断。

last30days 就是冲着这段脏活来的。

截至 2026 年 7 月 27 日，这个仓库有 53,789 个 Star、4,673 个 Fork，采用 MIT License。最新稳定版 v3.18.3 发布于 7 月 25 日，仓库当天仍有代码推送。

它不是一份提示词，里面真有一台搜索引擎

很多所谓 Skill，本质是一段写得更长的提示词。last30days 不一样。

它的 SKILL.md 负责告诉 Agent 怎样理解用户意图、规划查询、处理权限、调用脚本和组织结果；真正去抓取、清洗、合并、打分的，是仓库里的 Python 引擎。

我粗看了当前仓库结构，tests/ 目录下有 182 个 test_*.py 文件，搜索引擎拆成近 90 个 Python 模块。README 也明确写了 84% 的覆盖率门槛。这个体量已经不是“复制一段 prompt 就能跑”的小玩具。

先判断你问的是新闻、推荐、对比、人物近况，还是提示词技巧。然后解析真正需要查的对象，例如 X 账号、GitHub 仓库、subreddit、YouTube 频道和 TikTok 话题标签。

接着，多个来源并行检索。结果会按相关性、新鲜度和互动信号打分，同一件事在不同平台上的讨论会被合并成一个证据簇，不会把三条转载当成三条独立结论。

最后才由 Agent 做综合，把来源、数字、评论和不确定性压成一份简报。

真正拉开差距的是排序标准，不是平台数量。

传统搜索很看页面权重和关键词匹配。last30days 会把 Reddit 点赞、X 互动、YouTube 观看与评论、Hacker News 分数、GitHub 活跃度、Polymarket 赔率等信号放进同一条研究链路。

高互动不等于正确，但它很适合回答“大家此刻在关心什么”。这和查一个稳定的百科事实，是两种任务。

跑完一次，还能继续往下追

项目早就超出了“一句话查近况”。

你可以让它比较几个工具，自动寻找竞品；也可以用 discovery 模式找正在加速的话题，再对某个证据簇继续 drill。如果担心数据已经变化，还能要求它重新核对 GitHub Star、市场赔率和状态类结论。

它也支持招聘信号、历史时间窗、本地资料目录、JSON 输出和可分享的 HTML 简报。做内容选题、会前准备、竞品研究时，这些能力比“再给我总结一遍”实用得多。

比如，安装后可以直接问：

/last30days "AI video tools" 

或者做对比：

/last30days "OpenClaw vs Hermes vs Paperclip" 

项目要求结果保留来源状态和可追溯信息。某个平台认证失败、限流或没有返回结果，不能被悄悄写成“这个平台上没人讨论”。它还提供 doctor 和 --preflight，分别用来检查来源健康状态，以及在真正搜索前说明可能读取什么、写到哪里、会调用哪些外部服务。

装进 Codex，只有一条命令

Codex、Cursor、Copilot、Gemini CLI 等支持 Agent Skills 的工具，可以全局安装：

npx skills add mvanhorn/last30days-skill -g 

后续更新：

npx skills update last30days -g 

Claude Code 可以走插件市场：

/plugin marketplace add mvanhorn/last30days-skill /plugin install last30days 

直接运行底层脚本需要 Python 3.12 或更高版本。项目在检测到 uv 时可以自动准备兼容的 Python，但系统只有旧版 Python、机器上又没有 uv，第一次运行会被版本检查挡住。

“零配置”能用，但不是全部能力

README 里说的零配置，主要指 Reddit、Hacker News、Polymarket 和 GitHub 等基础来源可以先跑起来。

想把它真正用满，需要继续补环境。

YouTube 依赖 yt-dlp；X 可以读取你明确授权的浏览器登录态，也可以使用 xAI、Xquik 等 API；TikTok 和 Instagram 依赖 ScrapeCreators。Perplexity、Brave 等来源也有各自的密钥和计费方式。

项目的首次设置流程会先询问是否允许读取浏览器 Cookie。这个细节很重要。读取登录态能换来更完整的 X 数据，也会带来账号与凭据风险。服务器、公司电脑或敏感账号上，优先使用独立 API Key，或者干脆关闭浏览器 Cookie。

README 写明项目没有跟踪和分析，研究结果默认保存在本机。但“保存在本机”不等于“完全离线”：接入哪个平台，查询就可能发送到对应的第三方接口。使用前最好先跑一次 --preflight，看看它准备访问什么。

还有一个小提醒。仓库更新很快，README 的“What's new”段落仍停留在 v3.11.1，而当前 Release 和运行时 SKILL.md 已经是 v3.18.3。安装命令和具体能力变化，优先看最新 Release 与 skills/last30days/SKILL.md。

把它当雷达，别当裁判

我觉得 last30days 最适合三类场景：内容创作者找近期选题，产品和投资团队看真实讨论，开会前快速补齐一个人或一家公司的最近动态。

它不适合替你做最终事实裁决。点赞高的评论可能只是情绪强，预测市场也会错，社交平台的人群本来就有偏差。医疗、法律、财务等高风险问题，仍然要回到原始文件和权威来源。

但如果你的工作经常卡在“我知道网页上写了什么，却不知道人们最近到底在说什么”，这个项目值得装进 Agent 工具箱。

真正省下来的，是一串很难标准化的动作：找对账号、翻评论、看互动、拉字幕、合并同一事件，再把噪声压成一份能继续追问的简报。

GitHub 项目地址： https://github.com/mvanhorn/last30days-skill

摄影：产品经理

卤猪耳朵

这两天，一份梁文锋的投资者交流会文字稿在微信和全网刷屏。

不出意外，熟悉的造神运动又开始了。

很多人从这份接近四小时的交流中摘出只言片语，反复转发：梁文锋如何看 AGI，如何看产品，如何看开源，如何看世界模型，如何看中国 AI 的未来。

然后迅速得出结论：

梁文锋说得对。

AGI 就应该这样发展。

AI 公司就不应该急着做产品。

世界模型不重要，视频生成不是主线，应用都是“芝麻”，基础模型和 AGI 才是“西瓜”。

这种场景，我们其实已经见过很多次。

DeepSeek 出名之前，杨植麟也曾被造过一段时间的神。后来 DeepSeek 横空出世，聚光灯又迅速转向梁文锋。

人们似乎总希望找到一个足够聪明的人，替自己回答所有问题。

但我想说的是：梁文锋当然是一个非常优秀的科学家和工程师，但他同时也是一家公司的创始人。

他不是站在上帝视角描述 AGI 的唯一未来。

他是在为 DeepSeek 选择一条最适合自己的道路。

他自己都没有说，这是唯一正确的路线

在这份交流稿里，梁文锋给出了一条相当清晰的 AGI 路线：

先发展语言模型和思维链，再发展 Agent，接下来解决持续学习，让 AI 能够参与开发自己的下一代模型，之后再进入具身智能。

这套叙事很完整，也很有吸引力。

但很多传播者忽略了他后面说的几句话。

他说，这是“我们的推测”。

他说，每个人的观点不一样，“没有对错之分”。

他说，这是他们认为“最轻松”的路线图。

他甚至非常坦率地解释，为什么希望先解决持续学习，再做具身智能：因为这样可以用前面的 AI 帮助开发后面的技术，公司会更省力，不需要依靠大量人力去做那些“比较累、比较苦”的事情。

这已经说得非常清楚了。

这不是一条经过证明的 AGI 定律，而是 DeepSeek 基于自身资源、团队结构和技术优势所做的一次战略下注。

这条路线可能是对的。

但世界模型可能也很重要，多模态可能不只是一个组件，具身智能也未必需要等到所谓的“奇点”之后才开始。

没有人知道答案。

包括梁文锋自己。

他对产品的态度，本质上是一种公司战略

这份稿子里，梁文锋确实表现出了非常强烈的“轻产品”倾向。

他说，过去三年，任何时候花大量时间讨论商业化路径和产品线，都是浪费时间。

他说，DeepSeek 的很多产品并不完善，但他们也没有打算把这些地方全部补齐。

他说，C 端用户、B 端收入和 API，都是做 AGI 过程中产生的“副产品”。

最引人注目的一句话是：

他们做模型的第一目标，不是让所有用户觉得好用，而是让 DeepSeek 自己觉得好用。因为只有先帮助 DeepSeek 提高研发效率，才能更快做出下一代模型。

站在一家产品公司的角度，这些话甚至有些刺耳。

但如果站在 DeepSeek 的角度，它们又完全可以理解。

DeepSeek 没有字节的流量，没有腾讯的社交关系，没有阿里的企业客户体系，也没有成熟的销售和服务团队。

如果它选择与这些巨头争抢 C 端用户、垂直场景和企业客户，就必须进入一个自己并不占优势的战场。

相反，如果它把所有精力集中在基础模型、训练效率和推理成本上，把应用机会留给其他公司，它就可以成为整个产业的模型供应者。

这不仅减少了竞争对手，也增加了合作伙伴。

所以，梁文锋并不是在客观地证明“AI 产品不重要”。

他是在说明：对现在的 DeepSeek 来说，亲自做大量产品并不是收益最高的选择。

这是一个很好的公司战略。

但它不一定适用于所有公司。

对于掌握行业数据、客户关系、工作流和分发渠道的创业公司来说，产品可能不是基础模型的附属品，反而可能是最重要的护城河。

开源和低价，也不只是理想主义

很多人读完这份稿子，最感动的是梁文锋反复强调的“善意”“克制”和“开源”。

这些东西当然值得尊重。

但如果把它们完全理解成一种不考虑商业利益的理想主义，同样是不完整的。

梁文锋自己说得很明白：

“克制是一种战略。”

他认为，DeepSeek 即使开源最强模型，也不会影响自己的 API 收入。因为把模型真正部署好、把推理成本做到和 DeepSeek 一样低，依然有很高的门槛。

换句话说，DeepSeek 开放的是模型，但它认为自己仍然掌握着效率和成本优势。

它不追求垄断式的暴利，但并不意味着它不追求商业回报。

在交流稿中，梁文锋详细计算了 API 的回本周期，也讨论了 B 端收入、现金流、净利润和上市公司的可能性。

他甚至说，如果未来技术不再进步，DeepSeek 也可以全力卖 API，仅仅依靠这项业务，就可能支撑起一家上市公司。

这不是一个不食人间烟火的科学家。

这是一个对自己商业模式有清晰计算的公司创始人。

开源、低价和克制，既是他的价值观，也服务于 DeepSeek 的竞争策略。

二者并不矛盾。

“AGI 愿景”本身也有组织价值

这份交流稿中，一个很容易被忽略的关键词是：团队稳定。

梁文锋说，DeepSeek 最大、甚至唯一不能退让的核心利益，就是保持团队稳定。

为什么？

因为只要核心团队不走，他相信 DeepSeek 即使遇到挫折，也可以继续研究，迟早能够做出 AGI。

而“做成 AGI”这个宏大愿景，恰好能够吸引和留住最优秀的研究人员。

它让员工觉得，自己不是在优化一个普通产品，不是在完成几个季度的 KPI，而是在参与一个改变世界的科学项目。

这是一种极其强大的组织叙事。

它可以凝聚员工，可以吸引人才，也可以让投资者接受公司暂时不追求收入最大化。

同时，DeepSeek向合作伙伴承诺自己不会吃掉所有应用机会，也会让更多公司愿意采用它的模型。

所以，这场交流会不能只被当成一场技术分享。

它同时是一场完整的公司战略说明：

对员工讲愿景，对投资者讲回报，对合作伙伴讲边界，对市场讲开源与克制。

这不代表梁文锋在欺骗任何人。

他很可能真诚地相信自己所说的一切。

但一个观点是真诚的，和一个观点符合自己的利益，从来不是互斥的。

不要因为一个人成功过，就相信他对未来的所有判断

DeepSeek 的成功，证明了梁文锋在模型架构、工程效率、成本控制和组织管理方面做对了很多事情。

但它不能证明他对 AGI 未来的所有判断都是正确的。

一个人在一个问题上取得巨大成功之后，人们很容易把这种成功外推到所有问题上：

既然他做对了 DeepSeek，那么他对产品的判断也是对的。

既然他把模型成本降下来了，那么他对世界模型的判断也是对的。

既然他能管理好一家 AI 公司，那么他对未来十年的技术路线也一定是对的。

这恰恰是造神最危险的地方。

我们不再分析他的论据，而是开始相信他的身份。

但真正理性的阅读方式应该是：

把梁文锋当成一个极其优秀、极具洞察力，同时也有明确公司立场的创业者。

认真听他的判断，也认真检查这些判断背后的前提。

哪些是技术事实？

哪些是尚未验证的预测？

哪些是 DeepSeek 的资源限制？

哪些是为了凝聚团队、说服投资者和建立生态而形成的战略叙事？

如果换成一家拥有数亿用户的互联网公司，他还会不会认为产品是“芝麻”？

如果未来应用层产生了真正的数据飞轮和工作流壁垒，DeepSeek 会不会重新进入产品？

如果持续学习迟迟无法突破，这条“最轻松的路线”还能不能成立？

这些问题，不能因为说话的人叫梁文锋，就停止追问。

我并不反对梁文锋。

相反，我非常尊重他所取得的成就，也欣赏他在交流中表现出的坦率、克制和思考能力。

但尊重一个优秀的人，不等于把他变成神。

真正的尊重，是把他说的话当作值得认真检验的观点，而不是不容置疑的答案。

梁文锋不是 AGI 的先知。

他是一位正在牌桌上下注的公司创始人。

而我们最不应该做的，就是因为他曾经押对了一次，便认定他接下来押下的每一注，都是未来。

说明：本文依据网络流传的《梁文锋投资者交流会·录音文字稿》进行分析。该稿件注明由语音识别自动转写并经 AI 整理，未区分说话人，部分专有名词及数字可能存在误差，具体表述应以原始录音为准。

最近在折腾AI助手的时候，我发现了一个特别尴尬的问题。

不同平台的机器人生态完全不一样。QQ有QQ机器人，飞书有飞书机器人，Telegram有Telegram Bot...它们各自为政，互不兼容。

想在多个平台同时拥有一个统一的AI助手？对不起，不存在的。

直到我遇到了 AstrBot。

这个项目简直就是为我这种"多平台重度用户"量身打造的。

它就像一个万能的AI连接器，一次配置，就能让你的AI助手同时出现在QQ、飞书、钉钉、Telegram、Slack等十几款主流聊天软件中。

不管你在哪个平台，都能随时召唤同一个AI助手，享受统一的服务体验。

项目介绍

AstrBot是一个开源的一站式 Agentic 个人和群聊助手框架。

项目由 AstrBotDevs 团队开发维护，代码完全开源免费。从 GitHub 数据来看，这个项目已经积累了相当高的人气——已收货 37.4K Star。

它的目标很明确：陪伴与能力从来不应该是对立面。我们希望创造的是一个既能理解情绪、给予陪伴，也能可靠完成工作的机器人。

核心亮点

1. 多平台覆盖

AstrBot 支持的消息平台堪称"豪华阵容"：

• • 官方维护：QQ、OneBot v11、Telegram、企业微信、微信公众号、飞书、钉钉、Slack、Discord、LINE、Satori、KOOK、Misskey、Mattermost

• • 社区维护：Matrix、Rocket.Chat、VoceChat

• • 即将支持：WhatsApp

无论是国内常用的 QQ、飞书、钉钉，还是国际流行的 Telegram、Discord、Slack，AstrBot 都能完美对接。

一次部署，全平台生效，真正实现"一个助手，无处不在"。

2. 模型生态

在AI模型方面，AstrBot 的支持广度同样令人惊叹：

LLM 服务：OpenAI、Anthropic、Google Gemini、Moonshot AI、智谱 AI、DeepSeek、Ollama（本地部署）、LM Studio（本地部署）、AIHubMix、优云智算、硅基流动、PPIO 派欧云、302.AI、小马算力、ModelScope、OneAPI

LLMOps 平台：Dify、阿里云百炼、Coze

语音服务：OpenAI Whisper、SenseVoice、小米 MiMo Omni（语音转文本）；OpenAI TTS、Gemini TTS、GPT-Sovits、FishAudio、Edge TTS、阿里云百炼 TTS、Azure TTS、Minimax TTS、小米 MiMo TTS、火山引擎 TTS（文本转语音）

无论是云端大模型还是本地部署方案，无论是中文模型还是英文模型，AstrBot 都能轻松接入。

你可以根据自己的需求和预算，灵活选择最适合的模型服务。

3. 1000+ 插件

AstrBot 拥有一个非常活跃的插件生态，目前已有超过 1000 个社区插件可供一键安装。这些插件覆盖了各种实用场景：

• • 生活服务：天气查询、快递追踪、点歌、菜谱推荐

• • 办公效率：文档处理、日程管理、代码解释

• • 娱乐互动：游戏、抽奖、表情包生成

• • 工具助手：计算器、翻译、网页搜索

插件的安装和管理也非常简单，通过 WebUI 界面就能完成，无需任何代码知识。

4. Agent Sandbox

这是 AstrBot 最有特色的功能之一。它内置了一个 Agent Sandbox（智能体沙箱）环境，可以安全地执行代码、调用 Shell 命令，并支持会话级资源复用。

这意味着你的 AI 助手不仅能聊天，还能帮你：

• • 编写和运行 Python 代码

• • 执行 Shell 脚本

• • 搜索网页获取实时信息

• • 处理文件和数据

而且所有操作都在隔离环境中进行，安全性得到了充分保障。

5. 人格设定与情感陪伴

AstrBot 不仅仅是一个工具型助手，它还具备角色扮演和情感陪伴的能力。你可以为它设定不同的人格：温柔的小姐姐、幽默的段子手、专业的程序员、贴心的生活顾问...

通过精心设计的人格设定，AstrBot 能够理解你的情绪，给予恰当的回应，成为你随时可以倾诉的AI伙伴。

功能特性

• • 多模态对话：支持文本、图片、语音等多种形式的交互。无论是发送一张图片让AI分析，还是用语音输入进行对话，AstrBot 都能轻松应对。

• • 知识库功能：你可以上传自己的文档、资料，构建专属的知识库。

• 

• • MCP 与 Skills：支持 MCP 标准，可以接入各种第三方工具和服务。同时内置 Skills 系统，让AI能够完成更复杂的任务编排。

• • 自动上下文压缩：在长时间对话中，AstrBot 会自动对历史对话进行压缩和摘要，避免上下文过长导致的效率下降和成本增加。

• • WebUI 管理界面：提供直观的可视化管理面板，无需命令行操作

快速上手

方式一：uv 一键部署（推荐）

这是最简单快捷的部署方式，适合熟悉命令行的用户：

# 安装 uv（如果尚未安装）
curl -LsSf https://astral.sh/uv/install.sh | sh
# 安装 AstrBotuv tool install astrbot --python 3.12
# 初始化环境（仅首次执行）astrbot init
# 启动服务astrbot run

启动成功后，访问 http://localhost:6185 即可打开管理面板。首次登录用户名是 astrbot，密码在启动日志中查找。

更新 AstrBot：

uv tool upgrade astrbot --python 3.12

方式二：Docker 部署（适合服务器）

对于需要部署在服务器上的场景，Docker 是更稳定的选择：

# 克隆仓库
git clone https://github.com/AstrBotDevs/AstrBot
cd AstrBot
# 启动容器docker compose up -d

国内用户可以修改 compose.yml，将镜像源替换为：

image: m.daocloud.io/docker.io/soulter/astrbot:latest

方式三：桌面客户端部署

如果你只想在本地使用，不想折腾服务器，可以下载桌面客户端：

前往 https://github.com/AstrBotDevs/AstrBot-desktop 下载对应系统的安装包，安装后即可使用。

方式四：启动器部署

对于希望快速部署并实现环境隔离多开的用户，可以使用 AstrBot Launcher：

前往 https://github.com/Raven95676/astrbot-launcher 下载安装。

写在最后

AstrBot 是一个非常强大且实用的开源项目。它不仅解决了多平台AI接入的问题，还提供了完整的 Agentic 能力、丰富的插件生态和安全的执行环境。

无论是个人用户想要一个随时陪伴的AI伙伴，还是企业用户想要搭建智能客服系统，AstrBot 都能满足需求。

它的部署方式灵活多样，无论是快速体验还是生产环境部署，都有合适的方案。

项目地址：https://github.com/AstrBotDevs/AstrBot

摄影：产品经理

鳗鱼饭

昨天，我去逛了一圈世界人工智能大会，也就是 WAIC。

今年的会场里，有一个词几乎无处不在：

Agent。

做大模型的在讲 Agent，做企业服务的在讲 Agent，做招聘、营销、医疗、金融、法律、教育的，也都在讲 Agent。

过去两年，大家还在说自己做的是“大模型应用”“AI 助手”“行业 Copilot”。到了今年，不在产品介绍里加上 Agent，好像都不好意思说自己是一家 AI 公司。

但我在现场和一些公司聊下来以后，产生了一个很强烈的感受：

很多人不只是没有做好 Agent，甚至连 Agent 到底是什么东西，都没有真正想明白。

他们会很兴奋地告诉我：

我们做了一个某某 Agent，可以帮你完成某某工作。

于是我接着问：

那我怎么用？

这个问题听起来很简单，但很多人的回答立刻开始变得含糊。

有的说：

我们有一个网页，你登录进去就可以用了。

有的说：

我们给你提供 API，你们系统接一下就行。

还有的说：

我们可以私有化部署，也可以嵌入你们现在的软件。

这些回答本身都没有错。

问题在于，他们经常把“Agent 是什么”和“Agent 怎么交付”混成了同一件事。

好像做了一个网页，网页里面放了一个聊天框，它就是 Agent。

或者在大模型外面包了一层 API，这个 API 就叫 Agent。

甚至有些人会产生一种很奇怪的想象：

我做好了一个 Agent，就像做好了一个 Excel 文件一样，可以直接把这个 Agent 发给你，你拿过去就能用。

但实际上，Agent 从来不是一种固定的软件形态。

它既不天然是一个 APP，也不天然是一个网站、API、函数或者软件模块。

这些都只是它可能呈现出来的外壳。

Agent 不是一种产品形态，而是一种运行方式

先说结论。

我认为，Agent 最准确的定义应该是：

Agent 是一种能够接收目标、观察当前状态、自主决定下一步行动、调用外部工具，并根据行动结果继续调整，直到完成任务或触发终止条件的软件系统。

这里最关键的，不是用了大模型，也不是接了几个工具。

而是四件事：

目标、决策、行动、反馈。

假设我给一个投资尽调 Agent 下达任务：

帮我调查一下这家公司是否值得投资。

一个真正的 Agent，不应该只是把这句话连同几份材料一起塞给大模型，然后生成一篇看起来像模像样的报告。

它应该能够自己推进任务。

比如先拆解问题：

• 这家公司是做什么的？

• 所处行业怎么样？

• 收入和利润是否真实？

• 核心客户是谁？

• 有没有法律风险？

• 创始团队过去做过什么？

• 市场规模和竞争格局如何？

• 目前还缺哪些证据？

然后，它可能去搜索公开资料，查询企业数据库，阅读财报，分析访谈记录，调用估值模型。

如果中途发现收入数据和新闻报道矛盾，它应该继续调查。

如果发现某个关键文件缺失，它应该知道自己暂时不能下结论。

如果某个工具调用失败，它应该更换参数、重新尝试，或者请求人工介入。

整个过程更像这样：

观察当前状态
判断下一步做什么
选择工具并执行
查看执行结果
更新当前状态
再决定下一步做什么

这个循环，才是 Agent 的核心。

因此，Agent 并不是一个神秘的新文件格式，也不是某种独立于现有软件体系之外的新物种。

它本质上仍然是一套软件系统。

只是这套系统过去由程序员提前规定每一步怎么走，现在其中一部分路径选择，开始交给模型动态决定。

网页、APP、API，都只是 Agent 的入口

既然 Agent 是一套系统的运行方式，那么它当然可以被包装成不同的产品形态。

最常见的是网页。

比如一家公司做了一个合同审查 Agent。

用户登录网站，上传合同，点击“开始审查”，过一会儿得到一份报告。

从用户的角度看，它就是一个网站。

但网站只是前端入口。

网页背后可能启动了一个任务队列，Agent 在服务器上读取合同、识别条款、查询法规、对比模板、发现风险，最后再生成结果。

它也可以被包装成一个 APP。

用户在手机里输入任务，后端启动同一套 Agent 系统。

它还可以被包装成 API。

B 公司向 A 公司发送一个请求：

帮我分析这家公司过去三年的经营风险。

A 公司返回一个任务编号。

过几分钟或者几小时后，B 公司再来查询任务状态，最终取得报告。

对 B 公司来说，它只是调用了一个 API。

但在这个 API 背后，可能发生了几十次模型调用、搜索、数据库查询和代码执行。

它也可以被包装成 SDK。

A 公司把代码库交给 B 公司，让 B 公司把 Agent 运行在自己的服务器里，连接自己的数据库，使用自己的模型和权限系统。

它还可以被做成一个 Docker 镜像，部署进企业内网。

甚至可以被包装成一个 MCP Tool，让另一个 Agent 来调用。

所以，当一家公司的产品负责人说：

我们做了一个 Agent。

这句话本身几乎没有提供任何有效信息。

因为我仍然不知道：

• 这是一个网站，还是一个 API？

• 它运行在谁的服务器上？

• 用户把什么任务交给它？

• 它能采取哪些实际行动？

• 数据会不会离开企业？

• 是否支持异步任务？

• 失败以后如何重试？

• 是否有人工审批？

• 谁为最终结果负责？

“我们做了一个 Agent”，就像一家餐厅告诉你：

我们做的是现代化餐饮系统。

听起来很高级，但你仍然不知道它到底卖什么菜，怎么点餐，多少钱，以及能不能吃。

很多所谓 Agent，其实只是工作流

现在行业里还有另一个非常普遍的问题：

把所有带大模型的自动化流程，都叫作 Agent。

例如：

读取文件
提取文字
调用大模型总结
把结果整理成表格
发送邮件

如果这五个步骤是程序员提前写死的，那么它本质上是一个 AI 工作流。

工作流没有任何问题。

事实上，在大量真实的企业场景里，工作流往往比 Agent 更稳定、更便宜，也更容易审计。

但它不是因为接了大模型，就自动变成了 Agent。

工作流的核心是：

程序员提前决定路径。

Agent 的核心则是：

程序员定义目标、工具和边界，模型在运行过程中动态决定路径。

两者并不是非黑即白，中间存在大量混合形态。

比如前半段使用固定流程，到了异常处理环节，再由 Agent 判断应该查询哪份资料、调用哪个工具。

这种混合架构在生产环境里反而可能更加合理。

问题不在于一个产品是不是“纯 Agent”。

问题在于，很多公司一边使用完全固定的流程，一边为了融资、宣传或者赶时髦，强行把工作流包装成 Agent。

最后导致这个词迅速失去意义。

“做了一个 Agent”不等于“别人可以直接拿来用”

我在 WAIC 现场遇到的另一个典型误区，是一些人默认：

只要我们把 Agent 做出来，其他公司就可以直接使用。

但企业软件从来没有这么简单。

假设 A 公司做了一个销售 Agent，B 公司想使用。

这时真正的问题不是：

你有没有 Agent？

而是：

这个 Agent 如何进入 B 公司的业务系统？

如果它要读取客户信息，就要连接 B 公司的 CRM。

如果它要发送邮件，就要获得邮箱权限。

如果它要判断客户是否值得跟进，就需要理解 B 公司的销售规则。

如果它要修改商机阶段，就要接入内部权限体系。

如果它要联系客户，还需要确定哪些动作可以自动执行，哪些必须经过人工批准。

这时，A 公司真正需要交付的，可能是：

• 一个 SaaS 网站

• 一组 API

• 一个 SDK

• 一套私有化部署系统

• 一个 MCP Server

• 一套数据连接器

• 一套权限和审批机制

• 一套日志、监控与审计系统

Agent 只是其中负责“理解任务并动态决策”的一部分。

它不是整个产品，更不是整个交付过程。

一家企业真正购买的，也通常不是一个抽象的 Agent。

企业购买的是某种具体能力：

帮我审查合同。
帮我筛选客户。
帮我处理工单。
帮我调查公司。
帮我分析财务风险。
帮我生成销售线索。

至于这个能力背后用了一个 Agent、十个 Agent，还是一个普通工作流，客户其实并不关心。

客户关心的是：

• 输入什么？

• 输出什么？

• 正确率多少？

• 执行需要多久？

• 能不能接入现有系统？

• 数据是否安全？

• 出错了谁负责？

• 到底能省多少钱？

如果这些问题回答不清楚，那么“Agent”三个字说得再多，也只是技术包装。

判断一个 Agent，别先问它用了什么模型

现在很多人在介绍 Agent 时，最喜欢先说：

我们底层使用了某某大模型。
我们用了多 Agent 架构。
我们支持 RAG、MCP 和长期记忆。
我们构建了行业知识库。

这些当然可以介绍。

但它们都不是最重要的问题。

真正判断一个 Agent 是否成立，我更关心下面几件事。

第一，它能接受什么完整任务？

不是“它能回答什么问题”，而是用户可以把什么工作完整地交给它。

第二，它能采取什么行动？

只能生成一段文字，和能够查询数据库、修改 CRM、运行代码、发送邮件，是完全不同的产品。

第三，执行路径是谁决定的？

如果所有步骤都已经被开发者写死，那它更接近工作流。

如果模型会根据中间结果决定继续搜索、切换工具、调整策略，它才更接近 Agent。

第四，它有没有状态？

它是否知道任务已经做到哪里，哪些信息已经验证，哪些问题还没有解决，哪些工具曾经失败。

第五，失败以后怎么办？

一个演示版系统往往遇到错误就结束。

一个生产级 Agent 必须知道什么时候重试、什么时候换工具、什么时候暂停、什么时候交给人。

第六，权限怎么控制？

如果 Agent 可以发邮件，它可以发给谁？

如果它可以修改数据库，它可以修改哪些字段？

如果它可以付款，付款上限是多少？

如果没有权限、审批、审计和回滚，那么所谓的“自动执行”，很可能只是把风险藏了起来。

第七，别人到底怎么接入？

网页、API、SDK、私有部署、MCP，还是别的形式？

如果一家公司只能反复告诉你“我们做了一个 Agent”，却始终说不清楚别人如何把它接入现有业务，那么这个 Agent 很可能还只是一个 Demo。

Agent 不是产品答案，它只是实现手段

我并不是说 Agent 没有价值。

恰恰相反，我认为 Agent 很可能会成为未来软件系统里非常重要的一层。

过去的软件要求用户自己理解功能。

用户要知道点击哪个按钮，填写哪张表格，选择哪个菜单，才能让软件完成某件事。

Agent 带来的变化，是用户可以直接描述目标：

帮我把最近一个月流失的高价值客户找出来，分析流失原因，再分别制定召回方案。

系统再自己决定需要查哪些数据、运行哪些分析、生成什么内容。

从这个角度看，Agent 确实有可能改变软件的交互方式。

但 Agent 不是产品答案。

它只是实现产品能力的一种手段。

就像数据库不是产品答案，云计算不是产品答案，微服务也不是产品答案。

一家创业公司不会因为用了 PostgreSQL，就自动变成一家优秀公司。

也不会因为把单体系统拆成微服务，就突然获得商业价值。

同样，做了 Agent，也不意味着自动拥有产品、客户和商业模式。

今年大家一窝蜂创业做 Agent，让我想起过去很多技术浪潮。

每当一个新的技术概念出现，行业最先做的往往不是认真理解它，而是先把自己原来的东西重新命名一遍。

聊天机器人改名叫 Agent。

自动化脚本改名叫 Agent。

工作流改名叫 Agent。

搜索加总结也改名叫 Agent。

最后，所有东西都是 Agent，也就等于没有东西是 Agent。

结语

从 WAIC 回来以后，我越来越觉得，今天行业里最缺的并不是更多 Agent。

而是先把几个最基本的问题想明白：

你到底在帮谁完成什么任务？
为什么这个任务需要 Agent，而不是普通工作流？
Agent 能够采取什么行动？
它如何接入客户现有系统？
客户最终购买的究竟是什么能力？

Agent 不是一个 APP，不是一个网站，不是一个 API，也不是一个函数。

它是一套软件系统内部，围绕目标自主判断、调用工具、根据反馈持续执行的机制。

APP、网站、API、SDK、MCP 和私有化部署，只是别人接触这套能力的不同方式。

所以，下一次再有公司告诉你：

我们做了一个 Agent。

先别急着问它用了哪个模型。

你只需要问一句：

那我到底怎么用？

这个问题，通常比任何技术架构图都更能检验，它做出来的到底是一个真正的产品，还是又一个披着 Agent 外衣的演示项目。

左庭右院蔬菜自助

for _ in range(max_iterations):
    result = extractor.run(spreadsheet, feedback)
    vision_check = vision_verifier.verify(result)
    latex_check = latex_verifier.verify(result)
if vision_check.passed and latex_check.passed:
return result
    feedback = vision_check.feedback + latex_check.feedback

C ← {S, Prompt, Tool interfaces}
Y ← C[-1]
vision_pass, Δv ← parse_verification(Cv[-1])
latex_pass, Δl ← parse_verification(Cl[-1])

Δv

vision_feedback

C ← {S, Prompt, Tool interfaces}

context = [
    spreadsheet,
    prompt,
    tool_interfaces,
]

C[-1]

defchoose_best_feature(dataset, features):
    best_feature = None
    best_gain = float("-inf")
for feature in features:
        groups = split_dataset(dataset, feature)
        gain = calculate_information_gain(dataset, groups)
if gain > best_gain:
            best_gain = gain
            best_feature = feature
return best_feature

until verification succeeds or max-iterations reached
return Y*

for _ in range(max_iterations):
    ...
if verified:
return result
raise VerificationError("Verification failed")

return {
"success": False,
"result": last_result,
"errors": feedback,
}

FocuSD Island，一个用Tauri + React构建的轻量级桌面悬浮岛工具，终于填补了Windows平台的空白。

它的名字寓意深刻——Focu Study与Deep Work，旨在帮助每一个追求高效的用户进入深度工作状态。

它以透明、无边框、始终置顶的「悬浮岛」形式停靠在屏幕顶部。

默认是紧凑的胶囊形态，只显示当前最重要的信息；展开后则能展示完整的功能面板：Codex状态指示灯、今日待办、每日笔记、剪贴板历史、媒体控制...所有你需要的信息，都触手可及。

功能特性

1️⃣ 悬浮岛窗口

默认状态下，FocuSD是一个精致的胶囊悬浮在屏幕顶部，不占用过多空间，却能显示当前的专注任务和Codex状态。点击展开后，丰富的功能面板立刻呈现：

• • 折叠/展开：点击即可切换，操作极其简单

• • 边缘收起：鼠标移开自动收起，不打扰工作

• • 托盘隐藏：需要时可完全隐藏到系统托盘

2️⃣ 今日待办

新增、编辑、完成、删除任务，还能将某个任务设为「当前专注任务」。当你开始专注工作时，把最重要的任务置顶，让它时刻提醒你目标所在。

3️⃣ Codex状态指示灯

这是FocuSD最具特色的功能之一。在设置页一键安装或修复Codex hooks后，你就能在悬浮岛上看到实时的Codex运行状态：

• • 绿灯常亮：Codex正在处理任务

• • 红灯显示：任务空闲或已完成

• • 无需切换窗口：随时掌握AI助手状态

4️⃣ 每日笔记

与待办任务配合使用，形成完整的日归档系统。记录会议要点、学习心得、突发灵感，所有内容都会在跨日后自动归档，并可导出为Markdown文件。

5️⃣ 历史回顾

以卡片或时间线方式查看已归档的日期，回顾过去每一天的工作和思考。这不仅是记录，更是一种自我反思和成长的方式。

6️⃣ 剪贴板历史

自动记录文本和图片剪贴板内容，支持：

• • 快捷键呼出剪贴板面板

• • 一键复制历史内容

• • 删除单个条目或清空全部

7️⃣ 媒体控制

查看系统音频活跃状态，控制播放/暂停、上一首、下一首。让你在专注工作的同时，也能享受音乐的陪伴。

8️⃣ 外观设置

调整透明度、缩放比例、顶部间距、主题颜色，并保存自定义预设。让FocuSD完美融入你的桌面环境。

9️⃣ 系统集成

• • 系统托盘菜单：随时访问设置和功能

• • 开机自启动：Windows用户登录后自动运行

• • 无需手动开启：每天打开电脑即可开始专注

快速上手

方式一：通过Release部署（推荐）

适合只想直接使用的人：

1. 1. 打开 https://github.com/zzliu93-debug/FocuSD/releases 页面

2. 2. 下载最新版本的Windows安装包（推荐 FocuSD Island_0.1.0_x64-setup.exe）

3. 3. 按提示完成安装

4. 4. 首次启动后，在设置面板中配置：

• • Markdown保存目录（建议指向Obsidian库）

• • 开机自启动选项

• • Codex状态指示灯（需要时开启）

• • 剪贴板历史

• • 外观预设

方式二：通过源码部署（开发者）

# 克隆仓库
git clone https://github.com/zzliu93-debug/FocuSD.git
cd FocuSD
# 安装依赖pnpm install
# 构建应用pnpm tauri build
# 构建完成后，可执行文件位于：# src-tauri/target/release/focusd-island.exe

开发模式

# 启动Tauri桌面开发模式
pnpm tauri dev
# 或仅启动前端开发服务器pnpm dev

写在最后

在这个信息爆炸的时代，保持专注变得越来越困难。

FocuSD Island不仅是一个工具，更是一种工作方式的改变。它把你需要的信息集中在屏幕顶部，让你能够专注于真正重要的事情——思考和创造。

开源地址：https://github.com/zzliu93-debug/FocuSD

32k+ Star，这个项目正在打造"离线知识堡垒"。

一个让我脊背发凉的项目——Project N.O.M.A.D.。

这玩意儿在 GitHub 上已经有32.7k Star，而且还在疯狂增长。它的口号很简单：Knowledge That Never Goes Offline（永不离线的知识）。

翻译成中文就是：一台自给自足的离线生存AI电脑。把AI、维基百科、地图、课程全塞进本地，一键部署，彻底摆脱网络依赖。

它的开发者是 Crosstalk Solutions，一个在 YouTube 上有 47.5 万订阅者的技术团队，创始人Chris Sherwood有20多年的网络领域经验。

核心亮点

1、本地 AI 聊天，私人智能助手

Project Nomad 内置了基于Ollama 的本地AI聊天功能。

• •完全离线：模型跑在你的电脑上，不需要连网

• •支持RAG：可以上传文档，让AI基于你的知识库回答问题

• •数据安全：没有任何数据会上传到云端，零遥测

• •模型可选：从1B参数的轻量模型到70B的大模型，根据你的硬件选择

即使在断网的情况下，依然可以问AI，你想要知道的所有问题。

2、海量离线内容，人类知识库随身携带

这可能是 Nomad 最让人震撼的功能——它把整个 Wikipedia 都塞进了你的本地。

• •完整维基百科：以ZIM格式存储，英文维基百科约99.6GB，包含文章、插图、索引

• •Project Gutenberg：超过75,000本公版电子书，涵盖文学、历史、科学

• •医疗手册：离线可查的医疗指南和参考文献

• •生存指南：急救、野外生存、灾难应对相关文档

• •WikiHow：实用生活指南数据库

这些内容都通过Kiwix引擎提供，启动速度极快，完全不需要网络连接。

3、离线教育平台

Nomad内置了Kolibri 教育平台，这是一个专门为离线环境设计的教育系统。

• •Khan Academy课程：完整的数学、科学、编程课程

• •进度追踪：记录学习进度，支持多用户

• •离线播放：视频、练习、测验全部离线可用

这对偏远地区、旅行家庭来说简直是福音。即使在没有网络的地方，孩子的教育也不会中断。

4、离线地图

内置ProtoMaps 离线地图，支持下载区域地图，包含商业列表和兴趣点。

• •搜索功能：离线搜索地点

• •导航支持：基础导航功能

• •区域下载：按需下载你需要的地区地图

5、实用工具箱

Nomad还打包了一系列实用工具：

• •CyberChef：数据处理神器，支持加密、编码、哈希等200+操作

• •FlatNotes：本地笔记工具，支持Markdown

• •文件浏览器：管理你的本地文件

• •密码管理器：安全存储你的密码

• •自定义Docker：一键添加你需要的其他容器服务

这些工具平时可能用不上，但在关键时刻，它们就是你的数字瑞士军刀。

6、傻瓜式管理，零门槛上手

Nomad提供了一个Command Center（命令中心），通过浏览器访问，统一管理所有功能。

• •一键安装：所有工具和资源都可以通过界面一键安装

• •自动更新：可选自动更新，保持内容最新

• •零遥测：没有任何数据上传到第三方

• •状态监控：实时查看各服务状态

不需要懂技术，不需要敲命令，普通人也能轻松管理。

快速上手

在Debian-based系统上，只需一条命令：

sudo apt-get update && \
sudo apt-get install -y curl && \
curl -fsSL https://raw.githubusercontent.com/Crosstalk-Solutions/project-nomad/refs/heads/main/install/install_nomad.sh \
-o install_nomad.sh && \
sudo bash install_nomad.sh

安装完成后，打开浏览器访问http://localhost:8080 即可开始使用！

高级安装（Docker Compose）

如果你需要更多控制，可以使用Docker Compose方式：

curl -fsSL https://raw.githubusercontent.com/Crosstalk-Solutions/project-nomad/refs/heads/main/install/management_compose.yaml \
-o docker-compose.yml
# 编辑配置文件，替换占位符docker compose up -d

常用管理命令

安装后，Nomad提供了几个辅助脚本：

# 启动所有服务
sudo bash /opt/project-nomad/start_nomad.sh
# 停止所有服务sudo bash /opt/project-nomad/stop_nomad.sh
# 更新命令中心sudo bash /opt/project-nomad/update_nomad.sh
# 卸载（不可恢复！）curl -fsSL https://raw.githubusercontent.com/Crosstalk-Solutions/project-nomad/refs/heads/main/install/uninstall_nomad.sh -o uninstall_nomad.sh && sudo bash uninstall_nomad.sh

安全与隐私

Nomad在设计上非常注重隐私：

• •零遥测：没有任何内置的遥测功能，不会收集用户数据

• •完全离线：除了初始安装和内容更新，不需要网络连接

• •本地存储：所有数据都存储在你的设备上

• •开源透明：Apache 2.0许可证，代码完全公开可审计

不过需要注意的是，Nomad没有内置身份认证。如果你要在局域网内共享，建议使用网络级别的访问控制。官方表示未来可能会添加可选的认证层。

写在最后

在这个一切都依赖云端的时代，Project Nomad像是一股清流。

它告诉我们：知识不应该被网络绑架，智能不应该依赖服务器，数据应该属于用户自己。

也许你不会真的遇到断网几个月的情况，但这个项目提醒我们：在数字世界里，保持一定的独立性和自给自足能力，是一种重要的"生存本能"。

如果你有一台闲置的旧电脑，不妨试试安装Nomad。把它变成你的离线知识堡垒。

GitHub：https://github.com/Crosstalk-Solutions/project-nomad

摄影：产品经理

简单吃点

最近几个月，一个很明显的趋势是，越来越多的 Agent 产品开始做「多人协作」。

一个 Agent 当 PM，一个 Agent 当程序员，一个 Agent 当 UI，一个 Agent 当测试。用户只需要在群里提一个需求，剩下的事情交给 Agent 自己讨论，最后把结果交回来。

第一次看到这种产品的时候，我觉得这个方向很合理。现实世界里的公司就是这么工作的，一个需求往往也是 PM、研发、设计一起讨论出来的。如果 AI 能把这一套流程复刻出来，理论上应该会比单个 Agent 更强。

但是后来我越想越觉得，这里面可能有一个根本性的问题。

问题不是模型不够聪明，也不是 Agent 不够多，而是整个工作流的顺序可能就设计错了。

举一个很简单的例子。

假设有人在会议上问：

大家都喜欢什么动物？

A 说：

我喜欢熊猫。

B 说：

我喜欢狗。

然后 C 看着 B，笑着说：

太巧了，我也喜欢狗。

这句话为什么成立？

因为 C 在 B 开口之前，脑子里其实已经有自己的答案了。如果 B 说自己喜欢猫，C 还是会回答狗；如果 B 说自己喜欢熊猫，C 依然会回答狗。B 的发言没有改变 C 的想法，他们只是碰巧得出了相同的结论，所以 C 才会说一句「真巧」。

现在我们把这个过程换成今天很多 Multi-Agent 的工作方式。

PM Agent 提出问题，Agent A 回答熊猫，Agent B 回答狗，然后 Agent C 回复：

太巧了，我也喜欢狗。

乍一看，两种情况几乎一模一样。

但实际上完全不是一回事。

因为今天绝大多数 Multi-Agent 都是串行执行的。当 Agent C 开始推理的时候，它已经知道了 A 和 B 的所有回答，这些内容都会作为上下文放进 Prompt。也就是说，Agent C 并不是先形成自己的观点，再发现和 B 一致；相反，它是在已经知道 B 喜欢狗的前提下继续生成自己的回答。

因此，这里的「真巧」其实并不存在。

它不是三个独立思考的人碰巧想到了一起，而是后面的 Agent 在前面的上下文基础上继续写了下去。

很多人可能会说，那把三个 Agent 改成并行执行，不就解决了吗？

我觉得，只解决了一半。

如果三个 Agent 同时开始推理，彼此都不知道另外两个人的答案，最后再统一提交结果，那么 C 再说「真巧，我也喜欢狗」，这句话终于是真的了，因为三个人确实是在互相隔离的情况下独立完成了思考。

但是，我认为并行本身并不是重点。

重点是，讨论之前必须先有独立思考。

这一点在人类团队里其实非常普遍。

程序员不会一边写代码，一边把每一行代码发到群里讨论；设计师不会画到一半就让所有人一起修改；大家通常都是先完成第一版，再进入 Code Review、Design Review 或者架构评审。

讨论的目的，不是帮助每个人产生观点，而是验证观点、发现漏洞、互相挑战。

今天很多 Multi-Agent 恰恰反过来了。

它们从第一步就在讨论，所有 Agent 共用一份上下文，不停同步、不停交流。最后得到的答案，看起来像多人协作，实际上更像是一个模型在不同身份之间来回切换，把一段很长的 Prompt 拆成了几段对话。

所以我越来越觉得，未来真正优秀的 Multi-Agent，也许更应该借鉴 Git，而不是 Slack。

每个 Agent 都应该先拥有自己的分支，独立完成第一版方案；然后系统再自动比较这些方案，看看哪些地方一致，哪些地方冲突，哪些地方遗漏，最后再决定哪些问题值得讨论、哪些内容可以直接合并。

真正有价值的讨论，应该发生在每个人都有了自己的判断之后，而不是思考开始之前。

所以，我并不是反对 Multi-Agent。

相反，我认为未来一定会进入 Multi-Agent 时代。

但我越来越相信，一个真正优秀的 Multi-Agent 系统，不应该是「先讨论，再思考」，而应该是「先独立思考，再讨论」。

这两个流程看起来只是交换了一下顺序，但它们最终产生的信息质量，可能完全不是一个数量级。

最近在做一个 RAG 项目，需要把大量技术文档喂给大模型。

一开始用的是常规的网页抓取方案，结果抓回来的内容简直惨不忍睹——导航栏、页脚、广告、脚本代码混在一起，50000 token 的 HTML 里真正有用的内容不到 800 token。

更气人的是，有些网站还加了 Cloudflare 防护，直接返回 403 或者验证码页面。用 Playwright 跑无头浏览器吧，又慢又重，一个请求要等好几秒。

在 GitHub 上翻了无数项目，试过了 trafilatura、newspaper3k、readability 等等，效果都差强人意。

直到发现了 webclaw，简直是打开了新世界的大门！

项目介绍

webclaw 是一款专为 AI 工作流打造的高性能网页提取工具。

它的核心目标很简单：把网页转成干净、结构化、适合大模型使用的内容。

不同于传统的网页抓取工具，webclaw 从底层重新设计了整个提取流程。它用 Rust 编写，通过 TLS 指纹模拟浏览器行为，在不启动真正浏览器的情况下就能绕过大多数反爬机制。

提取引擎会自动识别并剔除导航栏、广告、脚本等无用信息，只保留核心正文内容。

核心亮点

🌟 Token 优化：减少 90% 的无效信息

这是 webclaw 最惊艳的特性。原始 HTML 页面通常包含大量的导航链接、CSS 样式、脚本代码、重复的页脚内容等。

这些信息对人类阅读来说是必要的，但对 AI 模型来说纯粹是浪费 token。

webclaw 的提取引擎采用九步优化流水线，通过文本密度、语义标签、链接比例、位置信息、上下文相关性等多种指标对 DOM 节点进行综合评分。

导航栏、广告、页脚、评论区等低分值节点会被自动剔除，而文章正文、标题、图片说明等高分值节点会被保留并整理。

⚡ 极速响应：比 Chrome 方案快 20 倍

传统的网页抓取方案（如 Playwright、Selenium）需要启动完整的浏览器实例，加载整个渲染引擎、JavaScript 引擎、CSS 解析器等，每个请求耗时 2-3 秒甚至更久。

这对于需要频繁访问网页的 AI Agent 来说是无法接受的——用户无法容忍等待几秒才能得到回答。

webclaw 采用完全不同的思路：它不启动浏览器，而是在 TLS 层面模拟浏览器行为。TCP 握手、加密套件、扩展信息、指纹特征等全部模拟 Chrome 142 的行为，让反爬系统误以为是真实用户访问。

这种方式带来了惊人的性能提升：

• • 静态页面平均响应时间仅 118ms

• • 本地提取 10KB 页面只需 0.8ms

• • 本地提取 100KB 页面只需 3.2ms

• • 本地提取 500KB 页面只需 12.1ms

• • 整体性能比基于 Chrome 的方案快 20 倍

🤖 原生 MCP 支持：无缝接入 AI Agent

webclaw 内置了 MCP（Model Context Protocol）服务器，这意味着它可以直接接入 Claude Code、Cursor、Windsurf、OpenCode、Codex 等主流 AI 工具，无需编写任何适配代码。

MCP 是连接 AI 模型和外部工具的标准协议，通过统一的接口规范，AI Agent 可以调用各种工具而无需了解底层实现细节。

只需一行命令即可完成配置：

npx create-webclaw

这个命令会自动检测你安装的 AI 工具，并为每个工具生成相应的配置文件。配置完成后，重启你的 AI 工具，webclaw 的所有功能就会自动可用。

安装后，你的 AI Agent 就能直接执行网页抓取、站点爬取、内容对比、品牌信息提取等操作。

🛡️ 智能反爬绕过：自动应对 Cloudflare 等防护

现代网站普遍使用 Cloudflare、Akamai、DataDome 等反爬系统。这些系统会检查 TLS 指纹、浏览器特征等，普通的 HTTP 请求很容易被拦截。

webclaw 通过 primp 库在底层模拟 Chrome 的 TLS 指纹，使得请求看起来完全像来自真实浏览器。对于需要 JavaScript 渲染的页面，webclaw 会自动检测并切换到渲染路径，无需手动配置。

📦 丰富的输出格式：满足各种场景需求

webclaw 支持多种输出格式：

格式	适用场景
markdown	保留结构的干净内容
llm	专为大模型优化的紧凑格式
text	纯文本，最小化格式
json	结构化元数据和提取字段
html	清理后的 HTML

其中 llm 格式特别值得一提，它会进一步去除重复链接、空段落等，是喂给 RAG 系统的最佳选择。

快速上手

方法一：MCP 一键安装（推荐）

npx create-webclaw

这个命令会自动检测你安装的 AI 工具（Claude Code、Cursor、Windsurf 等）并完成配置。

方法二：Homebrew（macOS）

brew tap 0xMassi/webclaw
brew install webclaw

方法三：预编译二进制

从 GitHub Releases 页面下载 macOS 或 Linux 二进制文件：
https://github.com/0xMassi/webclaw/releases

方法四：Docker

docker run --rm ghcr.io/0xmassi/webclaw https://example.com

使用示例

基础提取

# 提取单页内容（默认 markdown 格式）
webclaw https://example.com
# 指定输出格式webclaw https://example.com --format markdown
webclaw https://example.com --format llm
webclaw https://example.com --format json

只保留主内容

webclaw https://example.com/blog/post --only-main-content

自定义选择器

webclaw https://example.com \
  --include "article, main, .content" \
  --exclude "nav, footer, .sidebar, .ad"

爬取文档站

webclaw https://docs.rust-lang.org --crawl --depth 2 --max-pages 50

提取品牌信息

webclaw https://github.com --brand

页面变化对比

# 保存快照
webclaw https://example.com/pricing --format json > pricing-old.json
# 对比变化webclaw https://example.com/pricing --diff-with pricing-old.json

SDK 使用

TypeScript

import { Webclaw } from "@webclaw/sdk";
const client = new Webclaw({ apiKey: process.env.WEBCLAW_API_KEY! });
const page = await client.scrape({
  url: "https://example.com",
  formats: ["markdown"],
  only_main_content: true,
});
console.log(page.markdown);

Python

from webclaw import Webclaw
client = Webclaw(api_key="wc_your_key")
page = client.scrape(
    "https://example.com",
    formats=["markdown"],
    only_main_content=True,
)
print(page.markdown)

写在最后

webclaw 是一款真正理解 AI 工作流需求的网页提取工具。它从底层重新设计了网页提取流程，通过 TLS 指纹模拟、智能内容评分、多格式输出等特性，解决了传统抓取工具存在的三大痛点：

痛点一：抓不到——反爬防护

痛点二：抓不干净——大量噪声

痛点三：抓了没用——格式不适合 AI

如果你正在构建 RAG 系统、AI Agent，或者需要定期抓取网页内容，webclaw 值得一试！

GitHub：https://github.com/0xMassi/webclaw

brew install rmux

导读： OpenAI 给 Codex App 加了一个很有意思的新功能：你不用再把一套重复流程写成长 prompt，可以直接演示一遍，让 Codex 把它整理成一个可复用的 skill。
这功能叫 Record & Replay。它最值得看的地方，不是“AI 会看屏幕”这个噱头，而是它把人类的操作习惯、文件位置、检查步骤，变成了可以检查、可以编辑、下次还能继续调用的工作流。

先看视频：它到底演示了什么

OpenAI Developers 发的演示视频，用的是一个很真实的场景：团队每次发布 YouTube 视频，都要从发布表格里拿标题、描述，找到对应素材包，再去 YouTube Studio 里填字段、上传缩略图和英文字幕，把视频设为 private，最后确认保存无误。

这就是典型的“人觉得烦，AI 又常常不知道你偏好”的流程。

这段视频的关键信息其实就一句话：你不是在教 Codex 一个答案，而是在教它你做事的方法。

从 prompt 迁移到 skill

以前我们要让 AI 帮忙做重复工作，通常会写一大段 prompt：表格在哪里、文件怎么命名、先点哪个按钮、最后怎么检查。只要少写一步，结果就容易漂。

Record & Replay 换了一种方式：你先打开录制，把流程演示一遍；录完后，Codex 会回看这段记录，把它整理成一个 skill。这个 skill 不是黑盒，它是可检查、可编辑的。

这点很重要。

真正能落地的自动化，往往不只靠“模型聪明”。它还要记住团队内部的小规矩：素材包怎么命名，表格哪一列是标题，上传后要不要设成 private，最后要检查哪个页面。很多流程写成 prompt 会很啰嗦，但演示一遍就很自然。

所以我更愿意把 Record & Replay 理解成：把一次可观察的操作，压缩成团队可复用的操作记忆。

下次复用时，它不只会照抄

演示后半段，OpenAI 重新开了一个线程，附上“下一个视频包”，让 Codex 直接处理。

这里的重点不是它机械重复鼠标动作，而是它会把新的素材包匹配到表格里的正确行，再填写元数据、加缩略图、加英文字幕、设为 private，并验证保存是否正确。

这和传统录屏宏不一样。

录屏宏怕页面变、文件名变、数据变；Record & Replay 生成的是 skill，后续执行可以结合 Computer Use、Browser Use、连接的插件，或者它们的组合。说白了，它更像是把“操作 SOP”交给一个会看上下文的执行者，而不是把鼠标轨迹刻死。

当然，别把它想成万能自动化。越稳定、越短、目标越明确的流程，越适合录制。比如：

一个很朴素的判断标准：如果你能把它写成 SOP，只是懒得写，那么它就很适合被录一次。

使用前别忽略限制

这次更新不是所有用户一打开就能用。官方文档里写得比较清楚：Record & Replay 目前面向 macOS 上的 Codex App，并且需要启用 Computer Use；可用地区也有限制，EEA、英国、瑞士暂不支持。

这背后也有一个产品边界：它记录的是你的操作流程，所以你应该主动控制开始和停止录制。涉及密码、密钥、个人隐私、客户数据的步骤，最好不要直接录进去。

如果你准备试，我建议先从低风险流程开始：

1. 1选一个你一周至少做两次的重复任务。
2. 2先把素材和窗口整理好，减少录制里的噪音。
3. 3演示一遍完整流程，尤其不要跳过最后的检查步骤。
4. 4生成 skill 后先读一遍，确认它理解的是“规则”，不是某次偶然操作。
5. 5再用一个新样本跑一遍，看它是否真的能迁移。

这里最容易被忽略的是第 4 步。Record & Replay 的价值，恰恰在于生成出来的 skill 可以被人审。你不需要盲信模型，你可以把它当成一份自动写好的 SOP 草稿。

这次 Codex App 更新还有什么

Record & Replay 是这次最抢眼的功能，但 2026 年 6 月 18 日的 Codex App changelog 里还有几项偏“重度用户”的更新。

版本号是 26.616。除了 Record & Replay，更新还包括：

我的判断是，Codex App 正在从“代码助手”往“工作流执行器”走。以前你让它改一段代码，现在你更可能让它接管一段跨应用流程：浏览器、桌面、表格、插件、文件系统，一起被编进一个可复用 skill 里。

这条路不会一夜之间成熟。录制质量、隐私边界、失败恢复、多人协作里的权限管理，后面都会冒出来。

但方向已经很清楚：未来很多重复工作，不会先被写成自动化脚本，而是先被人演示一遍。

最后补一句：入口在插件里

如果你在 Codex App 里没看到 Record & Replay，先去左侧「插件」里搜索并添加。装好后，它才会出现在输入框里供你调用。

Record & Replay 的真正价值，不是省掉一次 prompt，而是把团队里那些“只有熟手才知道”的操作细节沉淀成可编辑 skill。它适合稳定、重复、低风险的流程；不适合高风险、强判断、规则经常变化的任务。

摄影：产品经理

榴莲千层蛋糕

最近 Anthropic 的 Mythos / Fable 5 很火。

有人说，Mythos 已经接近“准奇点”。也有人说，它代表了 AI 的下一次跃迁。网络安全、软件工程、科研自动化，都要被它改写。

我不太信。

我不是说 Mythos 一定是假的。也不是说 Anthropic 没有做出更强的模型。从公开信息看，Mythos 大概率确实很强。尤其是在漏洞发现、漏洞链构造、PoC 生成、长周期代码任务上，它可能比普通模型更进一步。

但“很强”和“准奇点”不是一回事。

中间差得很远。

我真正反感的是另一件事：Anthropic 把一个普通人用不到、测不了、也没法复现实验的模型，包装成了一个神秘、危险、只有少数人能接触的东西。

然后很多人看了几篇官方文章，几个合作方案例，就开始脑补：这个东西是不是已经接近超智能了？

这就不是判断了。

这是信仰。

没真正用过，就别谈“准奇点”

一个人如果没有真正用过 Mythos，就很难评价 Mythos。

更准确一点说，如果他没有拿自己的真实任务去跑，没有和 Opus、GPT-5.5、Gemini、Kimi 做同条件对比，只是看了公开材料，就说它是“准奇点”，那这个判断太虚了。

什么叫“准奇点”？

至少应该是这样的：模型能在开放问题里稳定推进。它不只是会写代码、修 bug。它还要能从一个模糊想法出发，自己设计方案，自己做实验，自己 debug，自己修正方向，最后完成一个复杂闭环。

而且，这种能力不能只出现在一个特定场景里。

不能只是网络安全强。不能只是某些代码任务强。它应该在科研、产品、工程、商业分析、复杂决策里都有稳定表现。

现在公开材料能说明什么？

最多说明 Mythos 在某些网络安全和代码任务上很强。它可能能发现漏洞。可能能生成 exploit，可能能加速安全研究。

这当然厉害。

但这离“准奇点”还差得很远。

把“漏洞发现表现好”直接升级成“准奇点”，中间缺了太多证据。

Anthropic 最强的，可能不是模型

我对 Anthropic 最大的不信任，不是因为它技术差。

恰恰相反，它技术很强。

但它太会讲故事了。

它不会直接说：“我们已经做出了超智能。”

它会换一种说法。它会说：这个模型太强。太危险。只能给经过审核的合作方使用。普通用户不能随便接触。政府也开始介入。

这套叙事非常厉害。

越不让你用，你越觉得它强。

越强调安全风险，你越觉得它接近失控。

越只放出少数案例，你越会想象：没放出来的部分肯定更惊人。

最后，一个闭环就形成了。

因为它太强，所以不能公开。

因为不能公开，所以你没法验证。

因为你没法验证，所以只能相信官方和少数合作方。

因为只有少数人能用，所以它显得更神秘，也更强大。

这不就是车库里的喷火龙吗？

车库主人说，里面有一条龙。你看不到，也摸不到，更不能测。

他说，不是不想给你看。是这条龙太危险。

问题是，越不让看，越有人相信里面真有龙。

漏洞发现战绩，不等于模型本身的能力

Anthropic 公开展示过 Mythos 的漏洞发现成果。

比如，它扫描了很多开源项目，发现了候选漏洞。之后，部分漏洞经过外部安全公司 review，部分被披露，部分被修复，部分拿到了 CVE 或 GHSA。

这些成果不能无视。

Cloudflare、Mozilla 这类组织也公开提到过 Mythos 或 Opus 在安全研究中的作用。它们不太可能拿自己的声誉陪 Anthropic 演一场完全虚构的戏。

所以我不认为 Mythos 是纯空气。

但漏洞发现不是模型一个人完成的魔法。

它是一套系统工程。

一个真实有效的漏洞发现流程，可能包括很多东西。比如代码仓库筛选，静态分析，fuzzing，sanitizer，agent scaffold，prompt 设计，大规模并行计算，自动验证，人类安全研究员 triage，漏洞去重，披露流程，厂商修复，CVE/GHSA 归档。

最后发现一个漏洞，到底是谁的功劳？

是模型本身？

是更大的推理预算？

是工具链？

是传统安全工具？

是人类研究员？

这些要拆开看。

如果把整个 pipeline 的成果都记在 Mythos 头上，那就是叙事偷换。

我真正想看的，不是“我们发现了多少漏洞”。

我想看同条件对照。

同一个代码库。

同一套工具链。

同样的运行时间。

同样的推理预算。

同样的人类介入规则。

然后比较 Opus 4.6、Opus 4.8、Fable 5、Mythos 5、GPT-5.5 的结果。

只有这样，才能知道 Mythos 到底强在哪里。

否则，它可能是 base model 真有质变。也可能只是旧模型拿到了更多 test-time compute。也可能是 agent scaffold 做得更好。也可能是传统工具和人类 triage 在背后扛了大头。

这几种情况完全不是一回事。

Fable 5 会不会只是“更多算力的 Opus”？

我一直有一个怀疑。

所谓 Fable 5，会不会本质上就是 Opus 系列模型，加上更高推理预算、更少限制、更好的工具链，以及更激进的 agent workflow？

这个怀疑不是空穴来风。

很多人都有过类似体验：一个模型刚发布时非常惊艳。过一段时间后，突然变笨了。

这不一定是模型权重变了。

线上模型不是一个单纯的权重文件。它是一整套服务系统。

推理预算、系统负载、路由策略、系统提示词、安全策略、上下文压缩、工具调用、fallback 模型，都会影响用户感受到的“智商”。

一个模型看起来更聪明，不一定说明底层智能发生了代际跃迁。

它可能只是获得了更长的思考时间。更多的推理 token。更少的拒答。更强的工具链。更稳定的执行环境。

如果 Fable 5 / Mythos 5 的优势主要来自这些系统层能力，那它当然会比普通 Opus 更强。

但这不等于它是准奇点。

这就像一辆车跑得更快。

原因可能是发动机换代了。

也可能是轮胎更好，赛道更平，油门限制被取消，补给团队更专业。

你不能只看终点成绩，就说发动机一定发生了革命。

下线事件，让 Mythos 更像神话

Fable 5 / Mythos 5 因为美国政府出口管制指令而暂停访问。这是整件事里最戏剧化的一幕。

官方说法是，美国政府要求 Anthropic 暂停外国人访问这些最强模型。理由是国家安全，以及潜在 jailbreak 风险。

Anthropic 表示不同意，但还是执行了。

这件事当然有现实基础。

判断一个用户是不是 foreign national，不是看 IP、手机号、信用卡地址就能解决的。这里面有 KYC，有企业主体，有实际使用人，有员工身份，有转授权，有审计，也有法律责任。

所以，这不是在 API 前面写一个 if-else 就能搞定的事。

但从传播效果看，这件事几乎完美服务了 Mythos 的神话叙事。

很多人会自然得出一个结论：

这个模型太强了，所以政府都怕。

这个模型太危险了，所以不能给普通人用。

这个模型被封了，所以它一定比公开模型强很多。

这就是最强的饥饿营销。

我不能证明这是 Anthropic 自导自演。也不能证明它联合政客制造了骗局。

这种说法证据不足，操作复杂度也很高。

但无论动机是什么，结果很清楚：Mythos 变得更神秘了。

它更像一个“你用不到，但你必须敬畏”的东西。

对一家特别擅长安全叙事和风险叙事的 AI 公司来说，这个结果太有利了。

真正的问题，是边界被揉在了一起

我对 Mythos 的怀疑，不是简单说它是假的。

更准确地说，我怀疑 Anthropic 把很多边界揉在了一起。

它把模型能力和系统工程能力揉在一起。

漏洞发现可能是模型、工具链、fuzzing、算力、人类 triage 的综合成果。但对外讲的时候，大家记住的是 Mythos。

它把候选漏洞和确认漏洞揉在一起。

模型提出几万个 candidate finding，不等于发现了几万个真实漏洞。候选、确认、披露、修复、拿到 CVE，是完全不同的层级。

它把特定领域能力和通用智能跃迁揉在一起。

即使 Mythos 在 cyber 任务中很强，也不能推出它在科研、商业、产品、复杂工程上都接近准奇点。

它把安全限制差异和底层智能差异揉在一起。

Fable 5 被说成 Mythos 的安全版。但外界并不知道它们到底差在哪里。

是底层模型一样，只是安全策略不同？

还是工具权限不同？

还是推理预算不同？

还是 agent scaffold 不同？

它还把“不能公开”和“强到不能公开”揉在一起。

一个模型不能公开，原因可能很多。合规、商业、成本、风险管理、产品未成熟、政府压力，都有可能。

不能因为不能公开，就默认它强到离谱。

这些模糊地带，就是 Mythos 神话生长的地方。

如果真强，就拿出硬证据

如果 Anthropic 真想证明 Mythos 不是营销，那就应该拿出更硬的证据。

不是精选案例。

不是合作方背书。

也不是“我们发现了很多漏洞”这种总量数字。

我想看到的是可复现 benchmark。

我想看到同 harness、同预算、同任务集下的模型对照。

我想看到原始运行轨迹。

我想看到人工介入比例。

我想看到误报率。

我想看到单个真实漏洞的平均成本。

模型到底如何阅读代码？

如何提出假设？

如何验证？

如何排除错误方向？

如何生成 PoC？

中间有没有人类给关键提示？

跑了多少次？

失败了多少次？

花了多少推理 token？

用了多少 GPU 小时？

最后，一个真实高危漏洞的成本是多少？

这些问题不回答，外界就无法判断 Mythos 到底是什么。

它到底是一次智能跃迁？

还是一次工程系统的堆料胜利？

如果它真的强，就应该经得起同条件对照。

我的判断

我现在对 Mythos 的判断很简单。

它大概率不是纯骗局。它应该确实在某些 cyber 和代码任务中有真实提升。

但公开证据远远支撑不了“准奇点”这个说法。

这个词更多来自营销、稀缺性和外界脑补。

Fable 5 / Mythos 5 的优势，未必来自 base model 的质变。

它更可能是模型、推理预算、agent scaffold、工具链、长上下文、记忆、安全策略、人类流程一起堆出来的系统能力。

Anthropic 最成功的地方，也许不是 Mythos 本身。

而是它把 Mythos 包装成了一个外界无法验证、但足够令人兴奋和恐惧的神秘强模型。

Fable 5 下线事件，不管真实原因是什么，都进一步强化了这个神话。

普通人越用不到，就越容易相信它强得离谱。

所以，真正理性的态度不是无脑否定，也不是无脑崇拜。

而是要求可复现证据，同条件对照，原始日志，人工介入比例，以及成本数据。

我不是说车库里一定没有喷火龙。

我只是说，在我看到火焰、鳞片、脚印和独立检测报告之前，我不会因为车库主人说“它太危险，所以不能给你看”，就相信里面真的有一条龙。

尤其是，当这个车库主人本来就是全世界最擅长讲“龙很危险，所以你必须相信我”的公司之一。

导读： 一个北海道农民说，他给自己的田里雇了一个工程师，名字叫 Codex。
这不是段子。Hiroki Tomiyasu 用 ChatGPT 和 Codex，把温室通风口、农场数据、卫星图、作业记录这些过去需要工程团队才能拼起来的东西，做成了自己能用的工具。
这件事最有意思的地方，不是 AI 会不会种地，而是一个没有软件背景的人，开始把自己的农场当成产品来迭代。

他不是工程师，却把农场当成产品在迭代

Hiroki Tomiyasu 原本不是农业世家，也不是软件工程师。他早年做过公务员，后来参与废弃梯田复垦，才慢慢进入农业。

现在，他在北海道经营大约 100 公顷农场，种西兰花、南瓜、葱、大豆等作物。这个规模放在日本已经不小，意味着每天都有大量重复但不能出错的现场工作：看天气、看温室、看地块、查苗情、算播种量、记作业记录。

传统解法通常很贵：买专用农业设备，请系统集成商，或者忍受一堆互不相通的工具。Tomiyasu 的选择比较野：用 ChatGPT 想方案，用 Codex 写代码，再把便宜硬件、云服务和自己的农场经验拼起来。

他在 X 上那句日文很传神：给田里雇了一个工程师，名字叫 Codex。

这句话好笑，但背后不是“AI 替代农民”的故事。更准确地说，是农民第一次拥有了一个随叫随到的低成本工程搭子。

以前你想做一个小功能，比如“我能不能在 LINE 里远程打开温室通风口”，这句话说完，后面立刻是一串麻烦事：电机怎么接、控制板用什么、云端接口怎么写、断网怎么办、状态怎么记录、权限怎么管。

对普通人来说，难点从来不是“想不到”，而是“做不出来”。Codex 改变的是后半句。

Codex 具体做了什么

最出圈的案例，是温室通风口远程控制。

Tomiyasu 想让自己在 LINE 里发指令，就能远程控制塑料温室的换气。最后这套系统用到了 ESP32 控制板、电机驱动、Cloudflare Workers、D1 数据库，以及 LINE 机器人接口。

注意，这里最妙的不是“用了什么技术栈”。这些东西单看都不稀奇，难的是把它们串成一个能在农场里用的系统。

他不是只让 Codex 写网页按钮，而是让它参与到接线图、控制逻辑、状态记录这些更接近现场工程的环节。也就是说，AI 不只在屏幕里写代码，它开始往真实世界伸手。

温室远程控制只是其中一个场景。ChatGPT Pro Substack 里提到，Tomiyasu 还把 AI 用在了这些地方：

这张表看起来像工具清单，但本质上是一件事：把农场里零散的“现场知识”，变成机器也能读懂、能调用、能复用的数据和流程。

这件事为什么值得认真看

很多人第一次看到这个案例，会把重点放在“农民会写代码了”。我觉得这个理解有点浅。

真正的重点是，AI 把“需求”和“实现”之间那条又长又贵的路，压短了。

以前一个农场主想做自动化，有两种常见结果。要么买成套系统，价格高，功能还未必贴合自己的地；要么找外部团队定制，沟通成本很高，后续维护更麻烦。

Tomiyasu 的方法像第三条路：先用自己的语言描述问题，再让 AI 帮他把问题拆成模块。能买现成硬件就买，能用免费或低成本云服务就用，代码和接线方案则一点点试出来。

这就很接近今天很多小公司、个人开发者正在发生的事：不是突然拥有了顶级工程团队，而是原来根本不值得启动的“小需求”，现在可以自己做了。

农业尤其适合这个变化。

因为农场里的问题非常具体：这块地今天温度怎样，那间温室要不要通风，某个叶片是不是病害，哪片田长势不均，今天谁在哪里干了什么。这些问题不宏大，但密度极高。

AI 在农业里的第一价值，可能不是替人做决策，而是让现场的人把自己的经验变成系统。

难点也在这里：AI 需要吃到现场信息

这个案例里有个很容易被忽略的硬道理：AI 想真正帮上农业，前提是它得吃到现场信息。

这句话比“AI 改变农业”更实在。

温度、地块、天气、作业人员、设备状态、材料库存，这些信息如果都在纸上、脑子里、微信群里、机器面板上，AI 再聪明也只能猜。它真正能帮忙，是在你把现场变成可读取的数据之后。

所以这个故事里最朴素、也最难的部分，其实不是 Codex 写了多少代码，而是 Tomiyasu 愿意把农场一点点数字化：地块放进 Airtable，温度接入机器人，设备状态写进数据库，卫星图叠到自己的地图上。

这也是为什么我不太喜欢把它包装成“农民逆袭工程师”的爽文。

AI 没有凭空替他解决农业问题。真正起作用的是三样东西叠在一起：他懂自己的地，AI 懂技术拼装，硬件和云服务足够便宜。

少一个，都很难成立。

普通人能学到什么

这篇文章对普通读者的价值，不是让大家都去买 ESP32 控制温室。

更值得学的是 Tomiyasu 的问题拆法。

当你遇到一个真实场景里的麻烦，不要一上来问“AI 能不能替我做完”。可以换成下面这种问法：

这个提示词的重点是“最小可行版本”。别一开始就做大系统，先做一个能帮你少跑一趟、少查一次、少手算一遍的小工具。

Tomiyasu 的案例提醒我们：AI 落地不一定先发生在最光鲜的办公室，也可能先发生在温室、电控箱、菜地和聊天群里。

它不总是替代一个职业。很多时候，它只是把一个人原本做不到的工程能力，暂时借给他用。

如果说过去的自动化属于大公司和专业团队，那么现在的问题变成了：谁最了解现场，谁就最有机会把 AI 用出真正的效率。

参考链接

• ChatGPT Pro Substack 原文：https://chatgptpro.substack.com/p/hiroki-tomiyasu

视频制作行业正在经历一场革命。

过去，要做出一支像样的产品宣传视频或者知识解说视频，你需要专业的剪辑师、动画师、配音员，可能还要花几万块钱找外包团队。

即使是小团队自己做，也得精通AE、Pr这些复杂的工具，光学习成本就高得吓人。

而且，这一切成本和门槛都还是建立在人工操作的基础上的。

就在这个时候，Open Design 团队干了一件大事。他们用了3天时间，写了3万行代码，把视频制作这件事彻底改写了，而且照样是开源的。

现在，你只需跟你的 AI Agent 说句话，或者粘贴一个公众号文章链接，它就能直接给你生成一支动态的 MP4 视频。而且，这个过程完全在你本机上运行，没有云端渲染费用，也不绑定任何厂商。

这就是 html-video —— 一个把HTML变成视频的革命性工具。

什么是html-video？

html-video 是 Open Design 团队官方研发的开源项目，它的核心理念很简单：在你的电脑上，把 HTML 变成视频。

你不需要是专业的剪辑师，也不需要是动画专家。你只需要：

1. 1. 描述一个视频（或者直接粘贴一个文章链接/GitHub仓库）

2. 2. 让你的 Agent 来处理

3. 3. 导出真实的 MP4 视频

这个过程中，Agent会自动帮你：

• • 选择合适的渲染引擎

• • 挑选最匹配的视频模板

• • 填入你的内容

• • 渲染出高质量的视频

而且，所有这些都在你的本地机器上完成，不用上传到任何云端，也没有单次渲染费用。

核心亮点：为什么html-video不一样？

1、基于Hyperframes框架

html-video 不是从零开始的。它的默认渲染引擎是 Hyperframes，这是一个成熟的 HTML+CSS+GSAP 框架，专门用来做动态HTML动画。

而整个项目的架构思想，其实和 Open Design 在设计领域的产品是一脉相承的。

而且，这个架构是可插拔的。现在默认用的是Hyperframes，未来Remotion、Motion Canvas、Manim这些引擎都会一一接进来。加一个新引擎，所有模板、所有agent、整条工作流就都自动用上了。

2、21套顶级HTML视频模板

html-video 内置了21个精选、许可清晰的视频模板，每一个都是经过精心设计的。

这些模板不是随手凑的一堆，而是覆盖了各种常见的使用场景：

• • 数据可视化：纽约时报风格的动态折线图、瑞士网格数据卡，适合「数字涨上去了」类叙事

• • 标题与特效：故障艺术标题、动感排版、打字机光标，适合开场爆点

• • 主视觉与电影感：极光液态渐变背景、漏光电影感画面、暖色颗粒杂志风

• • 产品宣传：15秒/30秒多场景产品宣传片

• • 解说骨架：决策树解说、Takram有机动效

每个模板都有清晰的分类和标签，agent 可以根据你的意图自动匹配最合适的模板。

更重要的是，这些模板都可以在 Open Design 中找到，保持了设计系统的一致性。

3、分页预览、分页编辑、帧文字编辑

传统的视频制作工具，你改一点东西就得重新渲染整个视频，等上半天才能看到效果。html-video 完全改变了这个工作流。

它支持：

• • 分页预览：每一帧都可以单独预览，不用等整个视频渲染完

• • 分页编辑：每一帧都可以单独编辑，想改哪帧改哪帧

• • 帧文字编辑：直接在界面上修改每帧的文案，所见即所得

而且，它支持多种视频尺寸：

• • 横屏 16:9

• • 竖屏 9:16

• • 方形 1:1

• • 小🍠 4:5

你可以根据发布平台随时切换尺寸，不用重新制作。

4、自动识别本地6种Code Agent

html-video 最厉害的一点是，它可以自动识别你电脑上已经安装的 coding agent。目前支持14个主流的 agent：

• • Open Design (Vela)

• • Windsurf CLI

• • Trae CLI

• • Claude Code

• • Cursor Agent

• • Codex CLI

• • Hermes

• • Gemini CLI

• • Grok Build

• • Qwen Code

• • OpenCode

• • GitHub Copilot CLI

• • Aider

• • Anthropic Messages API

这些 agent 会在你的 PATH 上自动探测，你只需要在 studio 的顶栏一键切换就可以了。没有本地 agent 也没关系，你可以直接使用官方 AMR 接入，或者配置 Anthropic API key，studio 直接走 Messages API。

而且，studio 默认把 Open Design (Vela) 排在最前面——一次登录、多种模型、成本更低——然后回落到第一个可用的 agent，保证你永远有一个能用的后端。

5、已接入MiniMax

视频没有声音是不完整的。html-video 已经接入了 MiniMax，你可以一键给视频加上背景音乐和旁白。

在 Settings → Audio 里填入 MiniMax API key，然后在每个项目的 Soundtrack 面板：

• • 背景音乐：描述一种情绪（比如「舒缓的电影感氛围，缓慢推进」），MiniMax 会生成一段器乐

• • 旁白：输入文案，MiniMax 会朗读出来（TTS）

两者都会通过 ffmpeg 混进导出的 MP4，音乐还会自动压低到人声之下，还支持可选的淡入淡出效果。

快速上手

在开始之前，你需要先安装几个依赖：

依赖	最低版本	检查方式
Node.js	20+	node --version
pnpm	9+	pnpm --version
ffmpeg	任意较新版本	ffmpeg -version
Chromium（或 Playwright 浏览器）	—	npx playwright install chromium

默认渲染引擎用无头 Chromium 录制带动画的 HTML，再用 ffmpeg（libx264）编码为 MP4。如果没有系统安装的 Chromium，可以装 Playwright 内置的。

安装和运行都很简单：

pnpm install
pnpm -r build
node packages/cli/dist/bin.js studio  # 在 http://127.0.0.1:3071 打开 studio

然后在浏览器里打开 http://127.0.0.1:3071，你就可以看到 html-video 的 studio 界面了。

在 studio 里，你可以：

1. 1. 挑一个模板（或者直接描述视频/粘链接）

2. 2. 跟 agent 对话

3. 3. 逐帧改文案

4. 4. 加配乐

5. 5. 导出 MP4

就这么简单。

支持三种输入方式：

• • 网页文章：抓取并扁平成 Markdown。像微信公众号这种服务端渲染的页面开箱即用。

• • GitHub 仓库：通过公开 API 拉取简介、顶层结构、README——很适合做「解读某开源项目」的视频。

• • 只给一句话：描述主题，agent 从零写内容。

无论哪种来源，它都会成为视频真正依据的素材——不是套模板时的摆设。

agent 会读取抓来的内容，自己决定需要几个场景，写出一份 content-graph 故事板：要点变成帧，要点之间的关系（这个承接那个、这个对比那个）变成边，再把所选模板的视觉风格逐帧应用上去。

CLI工具

除了图形化的 studio，html-video 还提供了可脚本化的 CLI 工具：

node packages/cli/dist/bin.js doctor  # 探测已安装的 agent + 引擎
node packages/cli/dist/bin.js search-templates --intent "github stars race" --top 3

这对于想把 html-video 集成到自己 CI/CD 流程中的团队来说非常有用。你可以写个脚本，每天自动生成项目进度视频，或者自动把新发的博客文章转成视频。

写在最后

html-video 给我们展示了一种全新的视频制作方式。它不是要取代专业的剪辑师，而是要让每一个人都能轻松地制作出高质量的视频。

而且，这一切的成本都极低——你只需要一台电脑，不需要任何专业设备，也不需要给任何云端服务付费。

Open Design 团队用了3天时间写了3万行代码，给我们带来了这样一个革命性的工具。这就是开源的力量——一群聪明人聚在一起，就能改变世界。

如果你对这个项目感兴趣，不妨去 GitHub 上看看，给它一个 Star，或者直接上手试试。

GitHub地址：https://github.com/nexu-io/html-video

导读： Claude 官方5月26日发了一条很轻的推文：6 个 Claude 项目，都来自同一个问题，“why not？”
这句话有点像玩笑，但里面藏着一个很真实的变化：AI 不只是在替人写代码，它正在把“我突然有个想法”到“我先做个能玩的版本”之间的距离，压到非常短。

先看这 6 个 why not 项目

这条串帖里，Claude 官方引用了 6 个用户项目。它们共同点很明显：都不是传统意义上的“大产品”，更像一个人脑子里突然冒出的趣味需求，然后被 Claude 推到了可交互状态。

第一个是 Pressed Petals。作者做了一个散步时“按压花朵”的小应用：你像在现实里夹花一样，把路上遇见的花收进一本数字标本册。

第二个是 digital sketchbook。它不是普通相册，而更像一本可以翻动、整理、观看纸上手稿的数字素描本。重点不是“AI 画得多好”，而是把个人创作物变成一个可浏览的小空间。

第三个是一个天气兔子。纽约天气忽冷忽热，作者干脆做了只兔子，根据天气告诉你该穿几层衣服，还能放成小组件。

第四个更离谱，也更能说明这波“why not”的味道：有人做了几个小 Claude agent，让它们在 Mac Dock 周围走来走去。它未必“有用”，但它非常会让人想点开看。

第五个是 Jason Kneen 展示的一个 Claude artifact：一个可交互的微型世界。它看起来像一个小型网页游戏或沙盒原型，角色、地块和界面都已经跑起来了。

第六个是日落预测工具。你输入位置或坐标，它帮你看某个地方什么时候适合追日落。这个项目最有意思的地方在于，它不是“天气 App”的大而全，而是只解决一个很具体、很个人的瞬间。

这 6 个项目放在一起看，反而比单独看更有信息量。

它们不是在证明 Claude 能做多复杂的系统，而是在证明另一件事：很多过去“不值得专门开发”的小想法，现在值得先做一版看看。

AI 原型时代最重要的变化，不是每个人都变成工程师，而是很多想法终于不用死在“算了，太麻烦了”那里。

评论区真正讨论的是两件事

我翻了一圈评论区，讨论大致分成两条线。

第一条线是兴奋。很多人把 “why not?” 当成了现在用 AI 做东西的默认姿势：先别写完整需求文档，先让 Claude 或 Claude Code 把第一版跑起来。一个常见说法是，过去你会问“我能不能做这个”，现在问题变成了“为什么不先试一下”。

这种情绪背后，其实是原型成本的塌陷。以前一个小工具要经过需求、设计、前端、后端、部署，哪怕只是给自己用，也会被一串成本劝退。现在很多项目不需要先证明商业价值，只要它足够具体、足够让你想要，就可以先长出来。

第二条线是反噬。评论区也有人借这个话题吐槽 Claude 的使用限制、模型版本切换、远程会话问题，以及“项目还没做完就碰到限额”的体验。

这不是跑题。恰恰相反，它说明这类工具已经进入真实使用阶段了。只有当用户真的把 Claude 当成生产力入口，限额、稳定性、模型可用性才会从“小瑕疵”变成“流程中断”。

所以这条推文看起来很轻，但它同时暴露了 Claude 生态的两面：

这里最值得记住的一句评论大意是：why not 是很好的开始，但更难的问题是，why this？

我很喜欢这个提醒。AI 能把动手门槛降低，但它不能替你判断这件事到底值不值得继续做。第一版越容易出现，越需要人来负责品味、边界和取舍。

这波变化，对普通人更重要

过去几年，AI 编程的叙事经常围绕“替代程序员”“提高研发效率”“企业降本增效”。这些当然重要，但这条 Claude 串帖展示的是另一种更柔软的力量：个人想法开始有了落地的机会。

Pressed Petals 不像一个 VC 会投的项目，天气兔子也不像一个成熟 SaaS。但它们有一种很稀缺的东西：作者自己的生活感。

这可能才是 AI 工具进入大众创作后的第一个真实信号。不是每个人都要做下一个 Notion、Figma 或 Cursor。很多人只是想做一本自己的数字素描本，一个会提醒穿衣服的小组件，一个帮自己追日落的网页。

这些项目小到不值得开会，却具体到值得存在。

而 Claude 官方把它们集中展示出来，也是在传递一个很明确的产品心智：Claude 不只是聊天框，也不只是写代码机器，它想成为“把脑内小念头变成可交互物”的那层中间件。

这对 OpenAI、Google、Anthropic 这些公司都一样。下一阶段的竞争，不只是模型跑分，也不是谁的发布会更炫，而是谁能让普通人的“临时起意”最顺滑地落到屏幕上。

这 6 个项目真正值得看的，不是它们多宏大，而是它们足够具体。AI 把“做一个小东西”的成本打下来后，创作会先从这些轻、小、怪、个人化的项目里长出来。
但评论区的另一半声音也在提醒：当大家真的开始依赖 AI 做事，限额、稳定性、隐私和模型版本管理，就不再是后台问题，而是创作体验本身。

参考链接

• Claude 官方串帖：https://x.com/claudeai/status/2059292334714466595

• Pressed Petals 原帖：https://x.com/yescynfria/status/2047382983263522909

• digital sketchbook 原帖：https://x.com/michelletliu/status/2021303957990015159

• Weather bunny 原帖：https://x.com/pau_wee_/status/2042608561197297942

• Dock agents 原帖：https://x.com/Ryan__Stephen/status/2036453073842049175

• Tiny world artifact 原帖：https://x.com/jasonkneen/status/2053282825722343752

• Sunset predictor 原帖：https://x.com/kathytzhou/status/2036864620611219628   

上周，朋友的团队新入职了一个实习生，让他负责熟悉他们的一个微服务项目。项目有 10 多万行代码，15+服务模块，各种依赖关系错综复杂。

实习生对着代码库看了整整一周，还是不知道从哪里开始。团队里的老员工都忙着赶进度，没时间手把手带。

这种情况在开发团队里太常见了。每次加入新团队，或者接手一个陌生的项目，我们都要经历一段痛苦的代码考古期——对着一堆文件和函数，不知道它们之间是怎么关联的，改一行代码生怕牵一发而动全身。

文档要么过时，要么写得让人看不懂，问同事又不好意思频繁打扰。

不过最近，我发现了一个开源神器，彻底改变了这个现状——Understand Anything。这个工具不是那种简单的代码搜索工具，而是直接把整个代码库变成了一张可交互的知识图谱。

就像给代码库做了一次CT扫描，让你能清晰地看到每一个模块之间的关系，点哪里看哪里，就像浏览地图一样简单。

而且它支持模糊搜索、语义搜索，甚至能在提交前分析代码变更的影响范围，让你提前知道改哪里会"惊动"哪些模块。

更厉害的是，这个项目短短几个月就在 GitHub 上获得了 17.8k 的星标，支持 Claude Code、Cursor、Codex 等主流AI编程工具。

项目简介

Understand Anything 是一个基于 Claude Code 的插件，它通过多智能体（Multi-Agent）流水线分析你的代码库，构建出一个交互式知识图谱。

它解决了开发者在新接手大型、复杂项目时无从下手的痛点，将枯燥的代码阅读过程转变为可视化的探索体验。

设计理念也很明确："目标不是一个让你惊叹代码库有多复杂的图谱，而是一个能教会你每一块如何配合工作的图谱"。

核心亮点

1、交互式知识图谱

这是 Understand Anything 最核心的功能。通过 /understand-dashboard 命令启动基于 React Flow 技术的可视化界面，你可以看到：

• • 颜色编码的架构分层：API、Service、Data、UI、Utility 等不同层级用不同颜色区分

• • 可点击的节点：每个文件、函数、类都是一个节点，点击就能查看代码和 LLM 生成的解释

• • 可拖拽的布局：支持缩放、平移，就像浏览地图一样探索代码结构

最棒的是，这个图谱不是静态的——它会随着你的项目更新而自动增量更新，只重新分析变化了的文件，效率很高。

2、业务逻辑可视化

切换到领域视图，你就能看到代码如何映射到真实的业务流程。

领域、流程和步骤都以横向图的形式呈现，即使是产品经理或 QA 这样的非技术角色，也能快速理解。

3、六大超级功能

功能	说明
🧭 引导式学习	自动生成架构漫游，按依赖顺序学习，告诉新手"先看这个，再看那个"
🔍 模糊与语义搜索	不仅能按名称搜索，还能按含义搜索——输入"处理用户认证的部分"，就能找到相关代码
📊 差异影响分析	提交前查看你的变更会影响系统的哪些部分，提前知道"涟漪效应"
🎭 自适应UI	仪表盘会根据用户角色调整细节水平——给新手展示简化版，给资深开发展示完整版
🏗️ 分层可视化	自动按架构层分组，彩色编码图例，一目了然
📚 语言概念	在上下文中解释12种编程模式（泛型、闭包、装饰器等），让新手边看代码边学习

4、知识库分析

Understand Anything 不仅能分析代码，还能分析知识库。

如果你有一个 Karpathy-pattern LLM wiki（带 wikilinks 的 markdown 文件），它能提取实体、关系和主张，把你的知识变成可导航的图谱，发现概念之间的显式和隐式关系。

这个功能对团队的文档管理特别有用——再也不用担心文档散落各处、难以查找了。

技术原理

Understand Anything 的核心是一个由多个专业智能体组成的流水线。当你运行 /understand 命令时，这些智能体会按顺序协作完成分析：

智能体	角色
project-scanner	发现文件，检测语言和框架
file-analyzer	提取函数、类、导入，产生图节点和边
architecture-analyzer	识别架构层级
tour-builder	生成引导式学习漫游
graph-reviewer	验证图谱的完整性和引用完整性
domain-analyzer	提取业务领域、流程和步骤（使用 /understand-domain 时）
article-analyzer	从维基文章中提取实体、主张和隐式关系（使用 /understand-knowledge 时）

文件分析器是并行运行的——最多支持5个并发，每批处理20-30个文件。而且支持增量更新，只重新分析自上次运行以来发生变化的文件，大大提高了效率。

快速上手

Understand Anything 的安装和使用非常简单，只需要几个命令就能上手。

第一步：安装插件

Understand Anything 支持多种 AI 编码平台，我们来看看不同平台的安装方式：

Claude Code（原生支持）

/plugin marketplace add Lum1104/Understand-Anything
/plugin install understand-anything

macOS / Linux（适用于 Codex、Gemini CLI、Cursor、Copilot 等）

curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash

如果你想跳过交互式提示，直接指定目标平台：

curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash -s codex

支持的平台值包括：gemini、codex、opencode、pi、openclaw、antigravity、vibe、vscode、hermes、cline、kimi。

Windows（PowerShell）

iwr -useb https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.ps1 | iex

安装程序会把仓库克隆到 ~/.understand-anything/repo，并为你选择的平台创建正确的符号链接。之后重启你的 CLI 或 IDE 即可。

第二步：分析你的代码库

安装完成后，在 IDE Agent 聊天框输入：

/understand

这样就会启动多 Agent 并行分析。分析结果会保存为 .understand-anything/knowledge-graph.json。

如果你想用中文生成内容（知识图谱节点描述和 Dashboard UI），可以加上语言参数：

/understand --language zh

支持的语言包括：en（默认）、zh、zh-TW、ja、ko、ru。

第三步：探索仪表盘

分析完成后，输入：

/understand-dashboard

这样就会打开一个交互式 Web 仪表盘，你的代码库会被可视化为一个图谱——按架构层进行颜色编码，可搜索，可点击。选择任意节点，你就能看到它的代码、关系以及通俗易懂的解释。

更多实用命令

除了上面的三个基本命令，还有很多实用的功能：

# 用自然语言提问关于代码库的任何问题
/understand-chat How does the payment flow work?
# 分析你当前变更的影响范围/understand-diff
# 深入解释特定文件或函数/understand-explain src/auth/login.ts
# 为新团队成员生成入职指南/understand-onboard
# 提取业务领域知识（领域、流程、步骤）/understand-domain
# 分析一个 Karpathy-pattern LLM wiki 知识库/understand-knowledge ~/path/to/wiki

写在最后

理解代码是软件开发中最基础也最重要的环节之一。好的工具能让这个过程变得事半功倍，Understand Anything 就是这样一个工具。

它不是要替代你阅读代码，而是给你一个地图，让你知道该往哪里走，让你更快地理解项目的全貌。

无论是刚入职的新人，还是想深入了解项目的资深开发者，都能从中受益。

GitHub：https://github.com/Lum1104/Understand-Anything

官方主页：https://understand-anything.com/

在线演示：https://understand-anything.com/demo/