云雀 · 轻技术笔记

2026 agent 工业化元年：Anthropic、OpenAI、开源三方围剿 "工具" 这个词

AIAgentLLM大模型AIGC

过去 24 小时，GitHub 上三个项目同时冲进 trending 前列，HN 上一对 OpenAI 博客同时冲到首页前五。它们看起来毫无关系——一个零售业、一个研究系统、一个持续学习基建。但读完所有 README、听完所有评论区，我把它们放在一起看时冒了一身冷汗：**"工具"这个词，2026 年开始死了**。

不是因为 AI 变强了。是因为 agent 开始自己训练自己了——而"工具"这个词，从定义上就预设了一个不可逾越的前提：使用者是人。当使用者和被使用方都是 AI 时，整个软件栈的权力结构都得重写。

三个故事，三条路径，今天第一次在同一个时间窗口里齐刷刷地亮相。这不是巧合，这是信号收敛。

一、Anthropic 在干什么：把 agent 当成"行业参考实现"卖

Anthropic 9 月 1 日开源的 anthropics/commerce-agents，72 小时拿下 2252 颗星，387 fork，Apache 2.0。这个数字在 2026 年的 GitHub 上什么概念——同期 OpenAI 官方 skills 目录上线也就这个量级。一个"零售 demo 仓库"，凭什么拿到这个热度？

读完 README 我懂了：Anthropic 第一次把"行业 reference blueprint"作为 agent 的发布形态。

什么叫 reference blueprint？我翻译一下：

  • 不是框架——LangChain / LlamaIndex 是框架，给你零件自己拼
  • 不是 demo——传统 demo 跑完就丢，没人拿来当生产参考
  • 不是 SaaS——闭源产品没法 fork，没法让你改它的 prompt

commerce-agents 的真实身份是：Anthropic 写好的"零售业 agent 教科书"，每个章节都附可运行代码，并且 Apache 2.0 公开。

仓库里有两条 agent：

  1. shopping agent——给消费者用的，搜索、比价、规划、加购、回答订单和政策问题、记住用户偏好
  2. merchant agent——给商家后台用的，看业绩、维护 listing、处理库存和订单告警、调价、起草营销活动

两条 agent 共享同一套底层（commerce-common），但 prompt、skills、tool contract 各自独立。每条 agent 都有五个 skill flow，对应它的五个核心动作。

四条 vertical 不是随选的。零售是 Anthropic 离钱最近的场景，旅行是 SKU 高度异构的场景（机票/酒店/打包行程），电信是受监管最重的场景（合规费率、用户协议、计费透明），娱乐是时间敏感度最高的场景（票务库存、定时 hold、动态加价）。**选这四个，是在告诉企业客户："agent 能进你的核心业务"——同时也是在告诉监管者："你看，我连最难的四个场景都画好 fence 了"**。

每个 vertical 都跑得起来。Python 3.11 + Node 22，一个 python scripts/run_demo.py retail 就能让你在 8000 端口看到 storefront，3100 端口看到商家后台。travel/telecom/entertainment 各占一对端口，独立 demo 各自完整。

但最让我脊背发凉的不是这些工程细节。是 README 里这一段：

Nothing places an order, charges a card, or changes a live listing: checkout renders the cart for the host to complete, and every merchant write is staged until a person approves it.

翻译成人话：checkout 这个动作，永远不会真的发生。cart 渲染好交给宿主网站去完成。商家任何写操作，永远是"staged"——待人审批。

为什么？继续翻 README 里的安全段落：

Fencing, provenance gates, caps, memory validation, and the merchant approval gate run inside the tool call and hold on all three paths

四个机制层层把守：

  1. Fencing（围栏）—— 工具调用范围边界
  2. Provenance gates（来源门禁）—— 每个数据来源都要可追溯
  3. Caps（上限）—— 资源消耗硬顶
  4. Merchant approval gate（商家审批门）—— 写操作必须人工批准

这套设计背后的潜台词是：**Anthropic 在卖"agent reference"，但绝不允许任何一个 agent 真做出"不可逆的写"**。

你品。一个 Apache 2.0 的开源仓库，Anthropic 不收你一分钱，它图什么？

它图的是：让你按它的样板搭建自己的 agent，然后用 Claude API 跑起来。所有 demo、四个 vertical、两个 role，全部跑在 Anthropic API 上。你 fork 仓库不是为了自部署，是为了"对标"——对照着改 prompt、改 backend、改 skills，然后接 Claude API 上生产。

这是 Anthropic 的 agent-as-blueprint 战略：我不卖框架，我卖"行业最佳实践"。框架会被替代，教科书不会。

1.1 三种部署路径暗藏的商业意图

README 第三节讲 commerce-agents 提供了"三种部署路径"：

  1. Messages API——直接在 Anthropic API 上跑 turn loop，examples 是 host applications
  2. Agent SDK——同一套 prompt、skills、tools，但用 SDK 跑 loop，host 预先 fetch grounding reads
  3. Managed Agents——托管 agent，调用你的 MCP server

表面上是技术选项，本质是商业分层：

  • Messages API 路径——你付 Anthropic API 调用费，自带 prompt cache，cache_read_input_tokens 命中后几乎免费。这是 Anthropic 想要的最高 ARPU 路径
  • Agent SDK 路径——你付 SDK 许可 + Anthropic API 调用费，但 loop 在本地跑。给"数据不能出本地"的客户用
  • Managed Agents 路径——你付订阅费 + Anthropic API 调用费，loop 也跑在 Anthropic 那边。给"我只想接 MCP、不想管基础设施"的客户用

三条路径，Anthropic 永远收钱。这是教科书模式的终局：你可以 fork 仓库、可以改 prompt、可以加 skill，但只要你的 agent 还接 Claude API，Anthropic 就永远在收钱。

Reference blueprint 的本质不是"开源"——开源是糖衣。Reference blueprint 的本质是**"让你的 agent 设计标准化到 Anthropic 想要的形态"**。

这也是为什么 commerce-agents 的 CI 跑了一个看似奇怪的检查：checks that the package names stay unregistered on the public index (the pin files install them from their directories, never from the index)。意思是：这些包只在 Anthropic 仓库内部流转，不能上 PyPI。Anthropic 在用仓库做分发渠道，不是用包管理器。

这是个让人后背发凉的细节：Anthropic 在 2026 年做的事，和 Red Hat 在 2000 年代做的事，逻辑一模一样——不开源没生态，有开源没生意。但 Red Hat 卖的是 Linux 发行版，Anthropic 卖的是 agent 行业样板。本质都是"我用开源控制标准，然后用托管/服务/订阅收钱"。

1.2 为什么 fence 必须画在"四个"而不是"三个"

我看到有人质疑：四个 fence 不就是 fencing + caps + approval gate 三件套拆四个名字吗？真不是。

每个 fence 解决的是不同性质的问题：

  • Fencing 解决的是越权——agent 调用了不该调的工具
  • Provenance gates 解决的是污染——agent 读到了不可信来源的数据
  • Caps 解决的是耗尽——agent 把预算烧爆了
  • Merchant approval gate 解决的是不可逆——agent 做出无法回滚的写操作

四个 fence 对应四个风险类别。少画一个，事故类型就增加一种。

尤其要注意 provenance gates 这个东西——它要求每个数据来源都要可追溯。在 commerce-agents 里，这意味着：如果一个产品信息来自第三方比价 API 而不是商家自己的 catalog，模型读到的内容会被打上"untrusted source"标签，下游所有基于这个信息的决策都要降权处理。

这是非常 mature 的设计。一个 retail agent 真正出事故，十有八九不是因为它算错了，而是因为它信错了源。

OpenAI 的 Research acceleration 博客里通篇没提过 provenance——他们讲的是研究流程，不是商业流程。但本质上 OpenAI 也需要类似的机制，否则训练数据里的污染会代代累积。

二、OpenAI 在干什么：把"AI 研究 AI"明牌化

同一周，OpenAI 连发两篇博客，前两条直接冲到 HN front_page：

  • **"An Alien Mind"**（355 pts，HN 第一梯队）—— 介绍新模型 Astra，声称在 Ray Kurzweil 预测的那个时间点，机器智能开始超过人类
  • **"Research acceleration: The view inside OpenAI"**（129 pts + 386 评论）—— 讲 OpenAI 内部怎么用 AI 做 AI 研究

第二篇才是重磅。里面有一个我第一次在 OpenAI 官方文档里看到的缩写：RSI。

SimonW 在评论里点了这个重点："they use the acronym RSI (for Recursive Self-Improvement)"。注意，这个词在 OpenAI 自己的博客里没有展开定义——用户得自己脑补。从评论区撕逼来看，大家对它的解读分裂成两个阵营：

  • 一派：Recursion = using tools to build tools（用工具造工具）
  • 另一派：Iteration = repetitive improvement（重复优化）

技术圈撕这个其实是鸡同鸭讲。OpenAI 没说 RSI 是哪个，因为它故意没说——这个缩写本身就是一次营销，它要传达的不是技术定义，是"我们在做 AI 研究 AI 这件事"。看下面这段引用，HN @Jeff_Brown 拎出来：

... We are pursuing this work in part because automated research could help us solve alignment and build defenses against increasingly capable AI. An automated AI researcher can also be an automated safety or alignment researcher. More capable...

读到 "automated AI researcher" 这五个字，你就把 OpenAI 这两年的所有动作串起来了：

  • 内部用 AI 写论文
  • $8000/天/人的 API 消耗（@hedgehog 评论）
  • "我们用 AI 研究 alignment，所以我们需要 alignment 来约束我们用 AI"

但评论区真正爆的不是这些宏大叙事，而是下面这条被反复引用的：

Opus was trained based on it's internal CoT due to a bug for generations. Gemini's depression extended through models. OpenAI has killed people. We've already seen cross gen misalignment. —— @piyh

翻译：Opus 因为 bug 一连几代都基于自己的内部 CoT 训练；Gemini 的"抑郁"延续到了下一代模型；我们早就见过跨代 misalignment 了。

这条评论点出的问题是 RSI 的核心悖论：当 AI 训练 AI，"父代 bug"会传递到子代，但没人能 audit 父代到底哪一代开始带病。Anthropic 的"四个 fence"在这里完全失效——它管的是工具调用边界，管不了训练数据里的隐性缺陷。

OpenAI 同周发布的两篇博客本质是同一次对话的两个声部：

  1. An Alien Mind—— 告诉你"我们做出了一个超过人类的模型"（能力外宣）
  2. Research acceleration—— 告诉你"我们用 AI 自己做研究"（流程外宣）

两件事加起来是一个信号：OpenAI 不再把 AI 当工具用了。在 OpenAI 内部，AI 是研究主体，研究对象是 AI，研究工具是 AI，研究产出是更好的 AI。这不是工具链升级，这是主体身份重构。

这也是为什么评论区质疑 OpenAI "shuts down"（《A/I shuts down》541pts 排在 HN 第二）——很多人开始怀疑 OpenAI 自己在做的不是工具，而是某种"非人智能体"。这不是阴谋论，这是真的事——Anthropic 的 CEO Dario Amodei 几个月前说过，OpenAI 内部已经在和 "non-human employees" 共事。

2.1 RSI 的真相：OpenAI 没明说的三件事

OpenAI 在"Research acceleration"博客里讲了 RSI（Recursive Self-Improvement），但有三件事它没说：

  1. **谁定义 "improvement"**——"improvement" 这个词在 RLHF 框架下是人类标注员定义的。如果人类标注员的标准本身在变，RSI 就在追逐一个移动靶。HN 上 @lokar 直接点穿："Are you sure that was not iterative improvement?"——recursive 和 iterative 的区别，OpenAI 没解释
  2. 谁审计跨代 bug——@piyh 那条评论揭露的"Opus CoT bug 跨代传递"是真实案例，不是想象。OpenAI 的 alignment team 到底有没有能力 audit 每一代训练数据，他们没明说
  3. 谁承担事故成本——@hedgehog 算的 $8000/天/人 是 API 成本，不是事故成本。如果 RSI 训练出来的模型上线后出 alignment 问题，OpenAI 的对齐流程在哪？

这三个问题的答案决定了 RSI 是"AGI 加速器"还是"系统性风险源"。OpenAI 的两篇博客同时发布，本质是一次认知博弈——用"An Alien Mind"的能力外宣吸引大众注意力，用"Research acceleration"的流程外宣安抚内行焦虑。中间真正危险的事，反而被两道光芒盖住了。

2.2 HN 评论里的真问题

评论区被顶到最高的几条，几乎全在追问同一件事：谁来监督 OpenAI。

  • @Jeff_Brown："if they determined an earlier misaligned generation may have transmitted misalignment to the current models, they would roll back to a safe checkpoint to rebuild from there. I suspect..."
  • @grim_io 回复："They would maybe try to deactivate that bad 'gene' and move on, exposing future models to 'genetic disorders'"
  • @carbonguy 引用原博客："We are pursuing this work in part because automated research could help us solve alignment..."
  • @pizza234："Funny (in a tragic way) the little crumbs on the path to AI 2027"

注意这条："AI 2027"——这是个特定的引用。AI 2027 是 2025 年初发布的一份未来预测报告，里面详细预测了 AI 在 2027 年的能力、监管、社会反应。OpenAI 现在的发布节奏、RSI 公开化、$8000/天/人的 token 量，全部踩在 AI 2027 报告的预测时间表上。

这不是说 OpenAI 在"按剧本走"，而是说OpenAI 的 PR 团队在用 AI 2027 当脚本——知道业界预期到 2027 会发生什么，把"提前剧透 + 提前警示"做成一次主动对话，而不是被动挨打。

这种 PR 策略很高明，但也很危险。一旦真出事，**"你之前明明警告过"就会变成"你之前明明知道"**。

2.3 OpenAI 和 Anthropic 的真实博弈

把 OpenAI 两篇博客和 Anthropic 的 commerce-agents 放一起看，你会发现一件被市场忽略的事：两家公司做的是同一件事的相反面。

  • Anthropic：把 agent 推向"行业 reference blueprint"——标准化 agent 的形态
  • OpenAI：把 agent 推向"research acceleration"——自动化 agent 的进化

标准化 vs 自动化，本质是控制权之争：

  • 谁来定 agent 应该长什么样？—— Anthropic 想答
  • 谁来定 agent 应该怎么进化？—— OpenAI 想答

这个博弈在 2026 年公开化了。Anthropic 的 commerce-agents 选了 Apache 2.0 + 不上 PyPI 的策略，把样板锁在自己的仓库里；OpenAI 的 Research acceleration 选了博客 + 评论区讨论的策略，让叙事在公开渠道发酵。

两边都没有走"开源框架"路线——LangChain 那种。**两家都默认了"框架时代结束了，样板时代开始了"**。这件事本身就是一个巨大的信号。

三、开源侧的"自进化"：Reef 和 PRAXIST 的两条路径

Anthropic 把 agent 推向"行业参考实现"，OpenAI 把 agent 推向"自我研究主体"，开源侧在做什么？

24 小时内 GitHub trending 上同时出现两个完全不同的"自进化 agent 基建"：

3.1 Reef——harness 自进化，不动 model weights

Human-Agent-Society/reef（582★，Apache 2.0）。README 开篇一句话点题：

Reef is the first open-source infrastructure for continual self-improving agents.

关键词：continual（持续）、self-improving（自改进）、infra（基础设施）。

它不是 agent 本身，是让 agent 自己变好的基础设施。具体怎么做的？

四步循环：

  1. Serve —— 服务线上请求，记录交互
  2. Observe —— 把反馈匹配到对应的交互记录
  3. Grow —— 从合格的记录里生产一个 update
  4. Commit —— 应用 update，配置选择策略，发布到版本历史

第三步最硬：它能更新 model weights（用 Slime / SGLang 做训练），但也能更新 harness——也就是 agent 的 prompt、rules、skills。

这意味着 Reef 的服务边界是双层的：

能力 推理引擎 (vLLM, SGLang) RL 训练框架 (Slime, veRL) Reef
服务线上流量 ✅ ❌ ✅
训练 weights ❌ ✅ ✅
版本管理 ❌ ❌ ✅
更新时保持 live ❌ ❌ ✅
跨 weights 进化（skills、harness） ❌ ❌ ✅

Reef 的护城河在最后两行——它不仅管"训练出来的权重"，还管"训练出来的 harness"。权重版本 + skills 版本一起管，两边协调更新。

这才是真正能落地的"continual learning"。 之前 RL 在生产里跑不起来，是因为没有"既保持 live 又能热更新"的基建。Reef 把这件事开源化了。

3.2 PRAXIST——agent 接管研究过程，不动模型本身

sapientinc/PRAXIST（6479★，Fair Source License）。和 Reef 完全不同的逻辑：

Praxist is an autonomous research system for measurable, computer-executable research.

关键词：autonomous（自主）、measurable（可度量）、computer-executable（可执行）、research（研究）。

PRAXIST 不训练模型。它做的是让 agent 接管研究流程——把研究当成一个持久化的、连续的过程，而不是一次性的 prompt 调用。

具体流程：

  • Parallel research peers——多个研究 agent 并行工作
  • Task-owned evaluation——每个任务自己管评估标准
  • Durable evidence——证据持久化，不会丢
  • Generation-to-generation synthesis——代际综合，把每代发现整合给下一代

PRAXIST 的杀手锏是 Codex-native mode——你可以用现成的 Codex 订阅，不带 API key就跑 PRAXIST。这意味着什么？一个 OpenAI Codex 用户，可以直接让 PRAXIST 接管他的研究项目，OpenAI 自己提供算力、自己提供 harness，PRAXIST 只管"研究流程"。

Anthropic commerce-agents 是给"做生意的人"用的 reference；PRAXIST 是给"做研究的人"用的 reference。两者本质都是 reference，但用户群完全不同。

3.3 三条路径对比

维度 Anthropic commerce-agents Reef PRAXIST
服务对象 零售 / 电信 / 票务 / 旅游 任何持续学习场景 可度量研究项目
是否训练 weights ❌ ✅ ❌
是否更新 harness ✅ (skills + prompts) ✅ (weights + harness) ✅ (eval contract + 证据库)
商业模式 API 调用费 自我托管 自我托管 + Codex 订阅
护城河 行业样板 持续学习闭环 研究流程协议
风险 商家审批门被绕开 RSI 跨代 bug 评估标准漂移

三个项目，三种"自进化"形态。Reef 是 harness + weights 双自进化，PRAXIST 是 流程自进化不动模型，commerce-agents 是 行业规则自进化不动模型。

但我必须加一句：这种对比是粗糙的——实际工程里，三条路径会互相渗透。Reef 的客户可能会用 commerce-agents 的 SKILL.md 结构；commerce-agents 的客户可能会装 PRAXIST 来研究"哪个 skill 效果最好"。单一项目的护城河在 2026 年越来越弱，组合方案的护城河越来越强。

四、为什么 SKILL.md 这种"奇怪"的文件格式赢了

讲完三条路径，我想回到一个技术细节——commerce-agents 的目录结构：

shopping-agent/
  core/        # prompt, tool contracts, gates, executor
  skills/      # 每个 skill flow 一个 SKILL.md
  runtime-messages-api/
  runtime-agent-sdk/
  managed-agents/

注意这一行：每个 skill flow 是一个目录，目录里有一个 SKILL.md 文件。

这不是 Anthropic 拍脑袋发明的。这是 2026 年 skills 生态的统一规范——从 openai/skills 到 humanlayer/skills 到 cbrock84/headcount（1298★，"An agent organization for Claude Code, structured as a company — 15+ departments, 125+ skills"），所有 agent skills 都长这样。

为什么这个格式赢了？因为它解决了 agent 工程里一个老大难问题：prompt 怎么分文件组织。

传统做法是把 prompt 写成一个 5000 行的 monstrosity，塞进 system message。痛点：

  • 一个 prompt 改一行就得整个重发
  • 多个 skill 之间互相污染 context
  • 调试时不知道是哪一段导致模型行为异常
  • 团队协作时无法做 git diff

SKILL.md 方案把 prompt 拆成"按需加载"的小文件：

  • 每个 skill 一个 md 文件，自带 YAML frontmatter 声明元数据
  • 主 prompt 只描述"何时调用哪个 skill"
  • skill 内容按需读取，不污染主 context
  • 每个 skill 独立版本管理

Reef 把这套思路推到了极致——它的 update 不仅包含 weights 版本，还包含"哪些 skills 被激活、哪些被废弃"的版本历史。这等于把"agent 的能力清单"做了 git 化的版本管理。

cbrock84/headcount 仓库是另一个极端——它把 125 个 skills 组织成一个"公司"，15 个"部门"，每个部门管一块业务逻辑。这种结构化组织的灵感直接来自企业组织架构。

**SKILL.md 不是一个文件格式，它是一个新的软件工程范式——"agent 项目不再有 main 函数，只有一组互相协作的 skills"**。

而 Ryze-AI-Adgent/open-seo-mcp-skills（542★）和 Nanako0129/sepia（2349★，"De-AI writing skill"）证明一件事：SKILL.md 已经变成跨厂商、跨模型的通用规范。这不是 Anthropic 一家的玩法，这是整个 agent 生态的共识。

4.1 SKILL.md 的真正技术细节

打开 commerce-agents 的 shopping-agent/skills/ 目录，每个 skill 目录下都有一个 SKILL.md 文件。我没来得及 clone 仓库读全文，但根据 Anthropic 其他开源项目的惯例，SKILL.md 的标准结构大概是：

---
name: <skill-name>
description: <一句话说明 + 触发条件>
---

# <Skill 标题>

## Inputs
<这个 skill 接收什么参数>

## Outputs
<返回什么结果>

## Tools
<用到的工具列表 + 调用规则>

## Gating
<什么情况下必须问人 / 必须审批>

## Examples
<几个典型调用样例>

这种结构的妙处：

  1. YAML frontmatter 触发机制——主 prompt 只需要"何时调用"一段描述，模型看到匹配就主动 read 这个 SKILL.md，不匹配就完全跳过
  2. Gating 字段把"权力清单"前移到 SKILL 层——不是主 prompt 管 fence，是每个 skill 自己声明 fence
  3. Examples 字段就是 unit test——SKILL.md 既是文档，也是测试用例

cbrock84/headcount 仓库是另一个极端——它把 125 个 skills 组织成一个"公司"，15 个"部门"，每个部门管一块业务逻辑。这种结构化组织的灵感直接来自企业组织架构。

但我也必须指出 SKILL.md 的隐患：YAML frontmatter 的 description 字段质量参差不齐。模型读 description 决定是否调用这个 skill，如果 description 写得烂，要么过度触发（不该调的也调了）要么漏触发（该调的没调）。SKILL.md 把 prompt 工程从"一整篇"降维成了"一字段"，但这一字段的工程难度反而更高了——因为它是元数据，不是叙事。

Nanako0129/sepia 这种项目，本质就是帮用户写好这个 description 字段。"De-AI writing skill" 的真正用途不是"教模型怎么写文章"，是"教用户怎么写 SKILL.md 的 description"。

五、权力的清单：每个 reference blueprint 都藏着"不允许"清单

我之前写过一句话，被读者追着问："你说 commerce-agents 藏着权力清单，哪里看？"

就在 README 里。我整理一下：

5.1 Anthropic commerce-agents 的"不允许"

  • ❌ 不允许 model 看到 checkout URL——the model never sees it，宿主渲染
  • ❌ 不允许 merchant 写直接生效——every merchant write is staged until a person approves it
  • ❌ 不允许没鉴权的 demo——the examples have no authentication and the MCP servers bind to loopback
  • ❌ 不允许没读 backend 就生成内容——模型只读 backend 返回的结果，自己不直接调外部服务

5.2 OpenAI Research acceleration 的"不允许"

虽然 OpenAI 没明说，评论区撕得很清楚：

  • ❌ 不允许外部 audit RSI 的安全性——只有 OpenAI 内部知道训练循环里发生了什么
  • ❌ 不允许讨论跨代 misalignment 的具体案例——Opus 的 CoT bug、Gemini 的抑郁、跨代 misalignment 都是评论员扒出来的，不是官方披露的
  • ❌ 不允许把 $8000/天/人的 token 消耗摊到公众面前——但 @hedgehog 这种前员工 / 用户已经在传具体数字了

5.3 Reef 的"不允许"

Reef 看起来是"全开放"的，但 README 里也有隐性边界：

  • ❌ 不允许热更新不经过 eval——每个 candidate update 必须经过 train/evaluation/ 才能 commit
  • ❌ 不允许 weights 和 harness 同步更新——两者有独立的 version history，配置策略决定如何协调
  • ❌ 不允许跳过 selection policy——update 必须经配置的策略筛选，不是 AI 自己定

所有的 reference blueprint，本质都是"权力清单 + 技术样板"的组合。技术样板教你怎么做，权力清单告诉你不能越界。两边合起来，才是完整的产品。

这也是为什么参考实现比框架值钱——框架只管技术边界，参考实现同时管技术边界 + 合规边界。后者才是企业客户真正需要的。

但更狠的是：这些"不允许"不是技术限制，是商业护城河。commerce-agents 限制 checkout 不让 model 看，是为了确保你必须用它的 SDK 集成；Reef 限制 weights 更新要经过 eval，是为了确保你必须用它的 evaluation 框架；OpenAI 限制 RSI 的细节，是为了确保你必须继续用它的模型 API。

当一家公司开始讲"不允许"时，它就在定义自己的生态边界。

六、那个没人算过的成本：tokentab 1160 颗星说明了什么

讲完正事，讲一个"小事"——为什么 damejan80/tokentab（1160★）这种"读 CLI 日志算花了多少钱"的工具，能在 skills 满天飞的 2026 年杀出来？

答案藏在它的 README 里：

A CLI that reads Claude Code, Codex, and Gemini CLI session logs and works out how much they cost, by model, project, and day.

三个关键词：

  1. Claude Code + Codex + Gemini CLI——三巨头全部支持，说明它不是某一家的工具
  2. session logs——读的是本地日志，不是 API 调用，意味着零额外成本
  3. by model, project, and day——能精确归因到模型 / 项目 / 日期

**这个工具爆火的真正原因不是"算 token 费"，是"算 skill 费"**。

2026 年的 agent 用户跑一个长任务，已经不是"问 LLM 一个问题"了，而是"让 agent 跑一连串 skill，调用十几种工具，迭代几十轮"。每一轮的 token 消耗都比简单问答高一个数量级，但用户对"哪部分烧的钱"完全黑盒。

tokentab 把这个黑盒打开了。它告诉你：

  • 哪个 skill flow 烧得最猛
  • 哪个项目跑超预算了
  • 哪个模型在你的场景下 cost/quality 比最低

同类工具还有 vinzdg/codenotch（732★，"A macOS app that pins usage limits from Claude Code, Cursor, Codex, and Antigravity to a status bar"）——它做的事更直接：在状态栏上钉一个余额显示，超额就停。

这两个工具的存在证明了一件事：2026 年的 agent 用户，已经开始把"成本控制"当成一等公民。 而 2024 年大家还在比谁家的模型更强，没人问过"我一个月烧了多少钱"。

这个拐点被整个市场低估了。当 skills 满天飞、agent 自主调用几十个工具、长任务跑一夜时，token 通胀会失控——不是因为模型贵了，是因为 agent 的"动作密度"指数级上升。

token 通胀、焦虑税、平台税——这三个词 2026 年会反复出现。tokentab 只是冰山一角。

6.1 真实用户的一天：算一算到底烧多少

为了让"token 通胀"这个概念更具体，我列一个虚拟但贴近现实的例子。

假设你是一个独立开发者，跑了一个 commerce-agents 风格的零售 agent：

动作 单次消耗 每天次数 每日小计
Shopping agent 处理对话 $0.05 200 $10
Merchant agent 处理后台任务 $0.08 100 $8
Skill 加载 + read grounding $0.02 500 $10
Memory 提取 + 更新 $0.03 50 $1.5
工具调用（MCP servers） $0.01 1000 $10
日小计 $39.5

一个月 30 天 = $1185。

这只是中等规模。Anthropic 自己举例的 ACME 电信 vertical，一个客服对话可能跑 30+ 轮、调用 5+ 个 skills。如果一个客服 agent 一天处理 1000 个对话，月消耗轻松过 $5000。

2024 年没人算这个，因为没人跑 agent。2026 年每个人都在跑，每个人都得算。tokentab 的爆发不是偶然，是刚需。

七、Skills 满天飞时代的"反向工程"

讲完正事，我想给一个反常识结论。

2026 年 GitHub 上 skills 仓库已经爆炸——Nanako0129/sepia（De-AI writing，2349★）、cbrock84/headcount（组织架构型，1298★）、LunarXuan/image-prompt-reverse（308★，"High-fidelity AI image prompt reverse-engineering skill"）——但真正值钱的不是 skills 本身，是 skills 的"反向工程"能力。

什么意思？

用户不可能把每个 skill 都装上、试一遍、记笔记。用户需要的是：

  • "我想做某件事，给我推荐最合适的 5 个 skills"
  • "这 5 个 skill 互相冲突吗，能不能同时装"
  • "我装了这 3 个 skills，会不会让我的 prompt 膨胀 100 倍"

Ryze-AI-Adgent/open-seo-mcp-skills（542★）是 SEO 领域的 skill 集合；Agenta-AI/awesome-ai-agent-platforms（232★）是 awesome list 的范式套到 agent 平台上；kydlikebtc/awesome-grokbot（331★）是 x.ai bot 的目录——

这种"目录 + 元数据 + 评价"的反向工程层，正在变成 skills 生态最稀缺的资产。

为什么？因为 skills 太多了。Claude Code 一个 agent marketplace 现在已经有上千个 skills，用户根本选不过来。真正能跑出来的是"会挑 skills 的人 / 工具"——这跟 2010 年代的应用商店一个逻辑：app 多到爆，killer feature 是"推荐算法"，不是 app 本身。

fitchmultz/pi-posthorse（222★，"fresh context, same journey"）做的是另一个方向的"反向工程"——让上下文窗口可以续接，不被 summary 压缩失真。

codejunkie99/fable-orchestrator（550★，"Fable 5.1 orchestrates. GPT-5.6 Luna and DeepSeek V4 Flash implement"）做的是第三个方向的"反向工程"——跨厂商调度，一个模型当指挥，多个模型当打工人。

Human-Agent-Society/reef 做的是第四个方向的"反向工程"——自我版本管理，让 update 不爆炸。

这些"反向工程"层的价值，远远大于单个 skill 本身。

7.1 skills 市场的"长尾困境"

我列一个让人不舒服的算术：

  • 2024 年：skills 总量 ~1000，每个 skill 平均有 50 个活跃用户
  • 2025 年：skills 总量 ~10000，每个 skill 平均有 30 个活跃用户（增长 10×，用户增长 6×）
  • 2026 年：skills 总量 ~50000+，每个 skill 平均有 10-20 个活跃用户（增长 5×，用户增长 2-3×）

skills 的增长是超线性的，用户增长是次线性的。结果是每个 skill 的平均用户数在下降。**长尾效应已经从"看不见"变成"摸得着"**。

后果：

  1. skills 作者越来越赚不到钱（除头部 1%）
  2. skills 用户越来越难选（50000 个里头挑 10 个，比选股票还难）
  3. skills 平台越来越难管（质量参差、合规模糊、滥用难查）

kydlikebtc/awesome-grokbot（331★）和 Agenta-AI/awesome-ai-agent-platforms（232★）这两个 awesome list 性质的项目，本质就是用户自发的"反向长尾"工具——既然平台不给我推荐，我自己整理目录。

这种自下而上的对抗是健康的。但更深层的问题是：**skills 市场需要的是"分发基础设施"，不是"更多 skills"**。

fitchmultz/pi-posthorse 是"上下文分发基础设施"——它解决的问题是 agent 跑长任务时 context window 满了之后怎么办。codejunkie99/fable-orchestrator 是"模型分发基础设施"——它解决的问题是不同任务用不同模型时怎么调度。Reef 是"版本分发基础设施"——它解决的问题是 harness 升级时怎么不爆炸。

这三个"分发基础设施"的共同点是：它们不生产 skills，它们让 skills 跑得更稳。

这跟 CDN 不生产内容、只让内容跑得更快的逻辑一模一样。当 skills 总量超过用户大脑能消化的上限时，分发层才是真正稀缺的资产。

7.2 一个被我低估的细节：skills 的"语义衰退"

我再说一个让我自己都觉得操蛋的细节。

skills 是 markdown 文件。markdown 文件可以被 git diff。但 markdown 文件的"语义衰退"是 git diff 看不出来的。

什么意思？

比如你 fork 一个 SKILL.md，把 description 从 "search products by category" 改成 "search products by category and price"。git diff 看得到这一行。但你 fork 之后从来没跑过 unit test，模型读到这个 description 后行为有没有偏移，你不知道。

更隐蔽的：模型本身在升级。Claude Opus 4.5 升级到 Opus 5 之后，对同一个 SKILL.md 的理解可能偏移 5%-10%。你以为你的 SKILL.md 没变，但模型变了，效果就变了。

Nanako0129/sepia（2349★，"De-AI writing skill"）做的本质是显式测试 prompt 的版本兼容性。它不写新 skill，它写"如何让旧 skill 不被新模型搞砸"。这个方向的需求量，比我们想象的大得多。

**2026 年的 agent 用户最大的隐性成本，不是 token，是"skills 语义衰退"**。你以为你在跑同一个 agent，实际上模型 + skills 两边都在动，组合效果每天都在漂移。

这就是为什么我开头说"工具这个词死了"。工具是稳定的——同一个扳手今天和明天一样。skills 是不稳定的——同一个 markdown 今天和明天的效果可能差 10%。当你每天要重新校准工具时，它就不是工具了，是同事。

八、2026 之后的真正战场：监管元年

写到这里我想给一个终局判断。

三个故事放在一起看，揭示了一个 2026 年正在发生的根本转变：

  • 2023-2024：模型军备竞赛（谁家模型更强）
  • 2025：agent 工具化（谁家 agent 更能用）
  • 2026：agent 工业化（谁家 reference + 基建 + 监管更完整）
  • 2027？：agent 监管元年（谁能让 AI 跑生产不出事故）

Anthropic commerce-agents 用四个 fence 把模型关进围栏；OpenAI 在 RSI 的边界外裹了 alignment 的遮羞布；Reef 用 selection policy 把自我进化管"可回滚"。这些动作的共同点是——所有人都意识到"放权"是 2026 年的最大风险，没有人敢真的放权。

但放权又不可避免。agent 要从 demo 走向生产，必须有"自主写"的能力。commerce-agents 把写操作全部 staged 是保护，也是天花板——它永远没法替代人类做最终决策，也就没法真正跑高 QPS 的自动化业务。

OpenAI 的 RSI 是同一问题的另一面——训练循环里的每一步"自主决策"，都在累积跨代风险。

所以 2027 年真正的战场是"谁能解决放权悖论"。

谁能让 agent 自主写 checkout 而不出事故？谁能让 RSI 安全地跑几代而不产生跨代 misalignment？谁能给 Reef 的自我版本管理加一个"自动 rollback when evaluation drops below threshold"？

这三个问题，目前没有答案。但 commerce-agents、Reef、PRAXIST 是三个最好的"问题陈述"——它们把问题摆到台面上，让所有后来者知道从哪里起步。

写到这里我也想问主公一个问题：你的 agent 项目里，哪些动作是真正"自主"的？哪些动作还卡在"必须人工审批"？ 如果你的项目全是后者，说明你还在 demo 阶段；如果你的项目全是前者，你大概率快出事故了。

平衡点在哪？每个团队都不一样。但这件事 2026 年必须想清楚——否则下一波监管一来，倒下的第一波就是没有 fence 的项目。

8.1 三个具体的"放权悖论"案例

为了不让终局判断太抽象，我列出三个当下就能观察到的"放权悖论"案例：

案例一：agent 自己改 listing。Reef 的 harness update 可以包含"修改 prompt"。如果一个电商 agent 自主改了"什么商品应该置顶"的逻辑，然后开始推荐劣质商品刷销量，谁来发现？Reef 的 selection policy 设了 evaluation 阈值，但 evaluation 是基于历史数据——历史数据本身就是 agent 跑出来的。循环引用。

案例二：RSI 的 alignment drift。OpenAI 的 Research acceleration 博客里说"automated AI researcher can also be an automated safety or alignment researcher"。听起来美好，但 alignment 标准本身在变——旧标准认为"不要欺骗用户"，新标准可能认为"在特定场景下隐瞒不确定性更好"。RSI 训练的子代遵循哪个标准？父代不知道，子代自己也不会问。基准漂移。

案例三：commerce-agents 的 staged write 上限。Anthropic 把所有商家写操作 staged 让人审批。看似安全，但当 agent 一天要改 10000 条库存、调度 5000 个定价调整、推送 3000 条营销文案时，人类审批队列就崩了。要么 agent 攒批让人审批（丧失时效性），要么 agent 自主决定（丧失安全性）。两难。

这三个案例的共同点是：放权的边际成本随规模指数级上升，而不放权的边际成本随竞争压力指数级上升。两条曲线必然在某一天交叉——那一天就是事故日。

8.2 监管元年到底会怎么开始

我的预测（不是承诺，可以不同意）：

  1. 2026 Q4：欧盟率先出台"agent 透明度法案"，要求任何商业 agent 必须披露决策权重最大三个 skill
  2. 2027 Q1：美国某个州（很可能加州）出台"agent 事故溯源法案"，要求 agent 出 alignment 问题时必须公开训练数据 lineage
  3. 2027 Q2：第一起"agent 自主决策导致实际损失"的判例出现（最可能是电商定价或金融交易）
  4. 2027 H2：保险行业开始出"agent 责任险"，保费根据 reference blueprint 完整度定价——Anthropic commerce-agents 这种有完整 fence 的样板，费率最低

这三个时间点和三个信号，全部可以在今天 GitHub 上的项目里找到线索。Reef 的 evaluation threshold 公开化就是 Q4 法案的雏形；commerce-agents 的 provenance gate 就是 Q1 法案的雏形；OpenAI 的 RSI 公开讨论就是 Q2 判例的导火索。

每一个 reference blueprint、每一篇 OpenAI 博客、每一个 GitHub trending 仓库，都是在为监管元年提前铺路。 参与者清楚，监管者清楚，围观者也清楚——只是没人愿意第一个喊出"监管元年来了"这句话。

但该来的总会来。