今天，BestBlogs 正式开放了 OpenAPI、bestblogs-cli 和 bestblogs-skills。
表面上看，这像是一轮很标准的能力发布。把接口开放出来，把命令行工具整理出来，再把一组给智能体调用的 Skills 放出来。
但对我来说，这次发布更重要的地方，不只是多了几个接口和工具。
它更像是一个新的开始。
我越来越觉得，今天如果还把阅读产品理解成一个主要服务网页和 App 的东西，已经不太够了。阅读这件事，正在从一个固定的产品流程，慢慢变成一条更长的工作流。用户会按自己的习惯组织内容，也会越来越自然地让智能体参与其中，帮自己筛选、理解、记录、比较和整理。
这也是我最近一直在想的一件事。
BestBlogs 接下来应该怎样继续往前走。
为什么我会开始认真思考 Agent Native
先说一下我理解的 Agent Native。
这个词看起来有点技术，但我自己的理解其实很简单。过去很多产品默认的前提，是用户进入一个界面，点击按钮，完成操作，然后离开。产品主要服务的是页面里的操作。
但现在越来越多时候，用户并不是沿着产品预设好的路径在用软件。大家会把多个工具串起来，会写一点脚本，会通过命令行跑流程，也会直接让 Claude Code、Cursor、OpenClaw 这样的智能体帮自己完成一部分工作。
所以一个产品今天更重要的问题，开始变成了这些：
它能不能被调用。
它的输出能不能继续成为下一步的输入。
它是不是足够结构化、足够清楚，让人和智能体都能理解它在返回什么。
这就是我理解的 Agent Native。
它不是产品里多了一个 AI 功能，也不是接了一个聊天框就完成了升级。对我来说，它更像是在重新思考，产品是不是天然适合进入更长的工作流里，成为其中一个可以被调用和组合的节点。这个方向也和 BestBlogs 当前第三层能力的设计是一致的，也就是把开放能力、早报原语、主题监控、研究会话和面向智能体的工具接口逐步整理出来。
为什么阅读产品尤其需要这样去做
这件事放在阅读场景里，会更明显。
因为阅读本来就不是一个单点动作。
你先看到一条内容。
判断它值不值得现在打开。
决定是快速扫一遍，还是深读。
读到一半，可能会想继续追问、摘录、记录。
读完之后，也许还会想和别的内容对比，或者整理成自己的笔记和判断。
这本来就是一条连续的链路。
过去的大多数阅读产品，更多是在承接其中某几个环节。比如收藏、稍后读、标注，或者详情页里的摘要和问答。
但如果从工作流的视角看，阅读产品真正有价值的地方，远不只是把内容放到你面前。
更重要的是，它能不能帮你降低判断成本，能不能更自然地进入下一步，能不能把阅读从一次性的消费，变成一个更顺手的连续过程。
我自己越做越觉得，阅读产品不应该只服务一次点击。它还应该服务点击之后的那条路径。
这也是 BestBlogs 这次开放能力背后的一个核心想法。不是单纯把功能开放出来，而是开始把这条路径拆成更清楚、更容易被调用的底层动作。
为什么这次是 OpenAPI、CLI 和 Skills 一起发布
如果只是为了开放能力，发一套 API 其实就够了。
但这次我最后还是做成了三层。
底层是 OpenAPI。
中间是 CLI。
最上面是 Skills。
我后来越来越觉得，这三层并不是重复建设，它们分别在解决不同的问题。
OpenAPI 解决的是契约问题。也就是哪些能力已经稳定到可以被外部依赖，哪些返回结构是清楚的，哪些路径以后可以持续演进，但不会随意漂移。现在开放出来的接口，已经覆盖了比较完整的一条主线，包括认证、建立兴趣画像、发现内容、深度阅读、收藏和笔记。
CLI 解决的是工作流问题。我一直很喜欢命令行工具这种形态，因为它足够轻，也很适合和 shell、脚本、自动化流程放在一起用。更重要的是，CLI 会逼着你按动作来组织能力，而不是按页面来组织能力。
所以 bestblogs-cli 最核心的设计，并不是把每个接口翻译成一条命令，而是按一条更接近真实阅读过程的路径来组织。先建立画像，再发现内容，然后深读，最后收藏、划线、记笔记。也就是 intake → discover → read → capture 这条链路。
Skills 解决的则是编排问题。也就是在有了稳定接口和工作流之后，怎样让 Claude Code、Cursor、OpenClaw 这类智能体更自然地调用它们。当前开放出来的 skills，已经覆盖了画像、发现、深读、沉淀和解释这些核心动作，总共 5 个 skill、25 个稳定原语。
这三层放在一起，BestBlogs 才不只是一个给人浏览的网站，而开始变成一组可以进入工作流的能力。
我更在意的，其实是原语化这件事
这里再说一个词，原语。
这个词第一次看也会有点抽象，但我自己的理解其实很简单。原语就是那些足够小、足够稳定、可以被反复组合的底层动作。
比如今天值得读什么。
比如深读一条内容。
比如把一条内容加入收藏。
比如记录一段划线和笔记。
比如解释这条内容为什么会出现在这里。
这些事情单独看都不复杂，但一旦它们被整理成清楚的原语，整个阅读过程就会开始变得更灵活。
因为每个人的习惯本来就不一样。
有人喜欢先看每天最重要的几条，再决定要不要深读。
有人喜欢围绕一个主题集中看。
有人习惯先收藏，晚上再整理。
也有人希望内容不要停留在网页里，而是直接进入自己现有的知识工作流。
如果底层能力没有被拆开，用户就只能沿着产品预设好的路径走。
但如果底层能力被整理成原语，用户和智能体就都可以按自己的习惯重新组织它们。
这也是我现在最看重 Skills 的地方。
它们不是在页面之外又加一层功能，而是在把 BestBlogs 的能力变成更容易组合的积木。这样一来，阅读这件事就不再只有一种用法，而是可以慢慢贴近每个人自己的节奏和习惯。
为什么解释性会越来越重要
我在做这次开放能力的时候，还有一个感受越来越强。
在 Agent 时代，只返回结果已经不够了。
因为内容一旦进入更长的工作流，被用户和智能体共同消费，大家不只关心返回了什么，也会关心它为什么会出现在这里，它来自哪里，它是个性化结果，还是公共候选，如果个性化结果不够，系统会不会自动补位。相关的说明能力，也已经放进了这次首版对外接口里。
这些信息在工程里当然有自己的字段名，但对外表达时，我更愿意把它理解成四类解释：
第一，这条内容来自哪里。
第二，它为什么会被选中。
第三，它是不是按你的兴趣和行为做过个性化。
第四，如果个性化结果不够，系统有没有做自动补位。
我觉得这些解释很重要。
对用户来说，它会让推荐更透明。
对智能体来说，它会让结果不只是一个终点，而是一个可以继续被筛选、比较、解释和处理的输入。
这也是我理解的一个变化。以前产品输出的终点更多是页面，现在产品输出越来越像下一步工作流的输入。
这次只是第一步，后面还有很多事情要继续做
这次开放出来的能力，还是第一版。
它已经能把最核心的发现、阅读、沉淀这条链路跑通，也能让外部系统和智能体开始接入 BestBlogs 的基础能力。
但我自己很清楚，这离最终想做的东西还很远。
接下来更值得继续做的，不只是补更多接口，而是继续把更高一层的能力整理出来，让它们更容易理解，也更容易使用。
比如把早报进一步整理成可组合的生成原语。这样它以后就不只是一个固定栏目，而是可以根据不同目标、不同对象、不同输出方式去生成。这个方向在内部设计里叫做早报原语，你也可以把它理解成，把今天的早报能力拆成更灵活的基础模块。
再比如主题监控。也就是围绕某个长期关注的话题，持续追踪变化，并在有新内容、新趋势或者重要更新时自动整理出来。
还有研究会话。这个词听起来也有点技术，但可以把它理解成一种长期研究容器。你围绕一个主题持续积累相关内容、笔记和判断，让阅读不只是散落的几篇文章，而是慢慢长成一个能被回顾和复用的上下文。
再往后，我也很关注另一类能力。
不是简单地把多篇内容做个摘要，而是进一步帮助用户看到，哪些来源在说同样的事情，哪些观点彼此有分歧，哪些内容证据更强，哪些变化值得继续跟踪。内部设计里把这类方向归到更高阶的综合与研究能力里，本质上是在尝试让 BestBlogs 返回的不只是内容列表，而是更高质量的研究报告。
这些东西都还在路上。
所以我更愿意把今天这次发布，看成一个起点，而不是一个已经完成的答案。
写在最后
这次把 OpenAPI、CLI 和 Skills 对外开放，对我来说，更像是在把 BestBlogs 往前推了一步。
它还是会继续把阅读产品本身做好。
还是会继续打磨我的早报、为你推荐、订阅源管理、AI 伴读这些核心体验。
但与此同时，我也越来越确定，它不应该只停留在一个让人打开网页阅读的产品上。
它还应该逐步变成一组可以被调用、被组合、被继续编排的能力，让阅读更自然地进入用户自己的工作流，也让智能体能围绕高质量内容做更多有价值的事情。
今天这次开放能力发布，就是这个方向上的第一步。
如果你对这套能力感兴趣，欢迎直接去体验，也欢迎告诉我你是怎么使用它的。无论是命令行、脚本、Claude Code、Cursor、OpenClaw，还是你自己的工作流，只要它能帮你更顺手地发现、阅读和整理内容，这些反馈对我都很有价值。
我也会继续沿着这条线往前做。慢慢把阅读产品，推向一个更可调用、更可组合，也更贴近真实使用习惯的知识基础设施。