这是第一篇文章。后续会陆续更新。

• 工具实测 — 上手测试，不堆形容词
• 上手指南 — 一步一步教你用 AI 做事
• 横向对比 — 同类工具的并排对比
• 专题合集 — 精选清单

每个推荐都经过实测。拒绝噪音。

一句话 — RAG 从文档里找答案。Agent 去做事。真实系统几乎都是两者结合：RAG 提供上下文，Agent 基于上下文行动。难点不是选哪个，而是分清楚你问题的哪一层属于哪种模式。

为什么这个对比在现在很重要

过去半年发生了两件事，让 RAG vs Agent 不再是纸上谈兵。

第一：coding agent 在 2025 年 11 月跨过了质量门槛。Simon Willison 在 PyCon 闪电演讲里把这个时刻总结为 agent 从"经常能用"到"基本都能用"——可以作为日常生产力工具了，不再只是 demo。同一个月里 Anthropic、OpenAI、Google 之间的"最强模型"头衔换手了 5 次。

第二：模型实验室自己在转型。Greg Brockman 直说：“模型本身已经不再是产品。” AI21 关闭了模型团队转去做 agent。DeepSeek 第一次组建了 “Harness 团队”。Latent Space 把这个趋势总结为 “所有模型实验室现在都是 agent 实验室”。

当训练模型的人都开始说"模型不是产品"的时候，怎么把模型接到系统里就成了真正的工程问题。RAG 和 Agent 是两个主流答案，解决的问题不一样，选错了会浪费大量 token。

心智模型

RAG：先检索，再生成

RAG 是固定的四步流水线：

用户提问
   │
   ▼
Embedding 模型 → 向量
   │
   ▼
向量库 / 搜索索引 → 取最相关的 top-K 片段
   │
   ▼
片段拼进 LLM prompt 作为上下文
   │
   ▼
LLM 基于检索内容写一次答案

一次检索，一次生成。便宜、确定性高、易于 debug。

Agent：推理 → 行动 → 再推理

Agent 是一个推理循环：

用户目标
   │
   ▼
┌──────────────────────────────────────────┐
│   LLM 读取目标                            │
│   ↓                                       │
│   选择工具 (Read / Edit / Bash / ...)     │
│   ↓                                       │
│   Runtime 执行工具                        │
│   ↓                                       │
│   结果反馈给 LLM                          │
│   ↓                                       │
│   LLM 推理下一步该做什么                  │
│   ↓                                       │
│   选下一个工具                            │
│   ↓                                       │
│   ... 循环直到任务完成                    │
└──────────────────────────────────────────┘

每一轮都烧 token，每一步都可能失败，错误会沿着循环逐步累积。

两个具体例子

RAG 实战：Wiki 语义搜索

我们本地跑了一个知识库——大概 60 篇 markdown，覆盖项目笔记、设计决策、对话记录。直接 grep 行不通，因为问题和答案很少共享关键词。

解决方案是封装了一个 MCP server：

MCP server: wiki-search
  Backend: bge-m3 embedding 模型
  存储:    60+ 篇 markdown 的余弦相似度索引
  输入:    自然语言查询（中英文都行）
  输出:    文件路径 + 章节标题 + 相似度分数

当我问 Claude Code “上个月我们对自动管道是怎么决策的？"，会发生这些事：

1. Claude Code 识别需要搜 wiki，调用 search_wiki("自动管道 决策")
2. 查询被嵌入成 1024 维向量
3. 余弦相似度返回 top 5 相关章节
4. 匹配片段被注入 Claude 的上下文
5. Claude 基于实际文件回答——不会瞎编

这是端到端的 RAG。Wiki 是被动的，它被查询，不主动做事。

Agent 实战：Claude Code 改文件

同一个 Claude Code 实例，换一个问题：“把 mybrew/hugo.yaml 的 baseURL 改成 aibrew.ai，并在 TODO.md 里记一笔。”

第 1 轮:
  LLM 推理: "得先看现有配置"
  工具: Read("mybrew/hugo.yaml")
  结果: 文件内容

第 2 轮:
  LLM 推理: "baseURL 在第一行，改它"
  工具: Edit(old="https://mybrew.cc/", new="https://aibrew.ai/")
  结果: 编辑成功

第 3 轮:
  LLM 推理: "现在更新 TODO.md 标记完成"
  工具: Read("hugo/TODO.md")
  结果: 文件内容

第 4 轮:
  LLM 推理: "得加在 '域名配置' 段下面"
  工具: Edit(...)
  结果: 编辑成功

任务完成。

四轮迭代，四次工具调用，多次推理。Agent 自己决定做什么、怎么做、什么时候算完成。

一个更刺激的 Agent：游戏服务器控制

我们还接了一个 Terraria 游戏服务器的 MCP bridge——大约 40 个工具（给道具、传送、ban 玩家、刷 Boss、重启服务器）。

玩家在聊天: "@ai 给我一把天顶剑"
  → terra_item_lookup("Zenith") → 解析到 ID 4956
  → terra_give_item(player="kali", item="Zenith") → SUCCESS
  → 道具出现在玩家背包里

对比一下破坏性操作：

玩家: "@ai 把世界结束掉"
  → terra_world_hardmode(confirm=true) 要求显式授权
  → 没确认就拒绝
  → 一旦确认：世界永久进入困难模式（不可逆）

这就是 Agent 模式开始变危险的地方。LLM 拿到了真实系统的方向盘。一次错误工具调用的影响不再是"答错了”，而是"世界毁了"。权限边界变成了一等公民的设计问题。

决策框架

一句话规则：

答案在文档里用 RAG。需要执行动作用 Agent。

更详细的版本：

什么时候必须用 RAG

• “我们的内部 API 文档对限流是怎么写的？”
• “总结一下上周的客户反馈。”
• “那次认证设计讨论的结论是什么？”

什么时候必须用 Agent

• “跑一下测试套件，把失败的修了。”
• “把昨天 RSS 未读里最有意思的三篇挑出来，写成一篇 roundup。”
• “把这个目录重构成新的 logging API。”

大部分真实系统：两个都要

• “找到相关的设计文档，提个符合它思路的代码改动。” → RAG 拉文档，Agent 写代码。
• “看一下 Pinterest 怎么做 MCP 认证的，然后设计我们的认证层。” → RAG 收集参考，Agent 动手写。

混合模式：RAG 驱动的 Agent

大部分 “RAG vs Agent” 对比都忽略了一件事：任何真实的 Agent 内部，RAG 都在多个层面同时发生。

一个 Claude Code session 简化后是这样：

会话启动:
  └─ 加载 CLAUDE.md 进上下文 ................ 启动时 RAG
  └─ 加载相关的 MEMORY.md ................... 启动时 RAG

用户提问:
  └─ Agent 推理目标
       │
       ├─ 工具调用: search_wiki("...") ....... 按需 RAG
       ├─ 工具调用: searxng_web_search("...") . 按需 RAG
       ├─ 工具调用: Read("config.yaml") ...... 确定性检索
       └─ 工具调用: Edit(...) ................ 行动

Agent 循环是外壳。RAG 调用发生在循环内部，按需进行，Agent 觉得需要更多依据时就调一次。

这跟 Pinterest 工程师描述的 MCP 部署完全一致：所有 Agent 界面（chat、IDE、CLI）都连同一组 MCP server，其中一部分是纯检索（Presto 查询、文档搜索），一部分是行动（提工单、重启任务）。Agent 在运行时自己决定调哪个。

生产案例：Pinterest 的 MCP 生态

ByteByteGo 对 Pinterest MCP 部署的写作是少数公开的生产实践之一。

N×M 问题

Pinterest 工程师每天要跨多个系统工作——Presto 查数据、Spark 调批处理、Airflow 跑工作流、查内部文档、追 ticket。他们想让 AI agent 能直接进到这些系统里。

直接做的话：

5 个 agent 界面 × 10 个内部工具 = 50 个定制集成

每加一个界面或工具就乘出更多工作量。还有 50 套 OAuth 流程、50 套 token 生命周期、50 套管道。

MCP 的赌注

Model Context Protocol（MCP）的承诺是把乘法变加法：

5 个 client + 10 个 server = 15 个标准化集成

一个协议两端用。每个界面写一个 client。每个工具包一个 server。它们都说同一种"语言"。

MCP 解决不了的问题

Pinterest 的教训：协议本身是最容易的部分。真正的工程量在协议周围的基础设施：

结论：Agent 越能干，权限和可观测性层就越重要。一个让任何 agent 都能调任何工具的协议，也是让任何被攻陷的 agent 都能调任何工具的协议。

这也是为什么我们更小的部署（3 个 MCP server：searxng / wiki-search / terra_llm_bridge）在破坏性操作上加了硬性的 confirm=true 门——比如 ban 玩家、重启世界、开启 hardmode。三个 server 不需要注册中心，但需要授权。

架构对比：Claude Code vs OpenClaw

两个主流 Agent harness 在设计上立场截然不同。ByteByteGo EP214 从 5 个维度拆解：

1. 系统范围

Claude Code 是你召唤来干活的工人。OpenClaw 是永远在听的管家。

2. Agent 运行时

• Claude Code：单线程异步循环——Think → Tool Call → Observe → Repeat。一个进程一次只做一件事。
• OpenClaw：每个 session 独立队列。Gateway 把入站消息分发到各自的队列。

3. 扩展模型

• Claude Code：四个扩展原语，全都接进同一个 Agent 循环：
  • MCP（外部工具服务）
  • Plugin（打包的工具集）
  • Skill（模型可调用的命名流程）
  • Hook（事件驱动的 shell 命令）
• OpenClaw：manifest-first 插件系统。所有插件先经过中央 Registry 才进入 Agent。

4. 记忆机制

• Claude Code：CLAUDE.md 在会话启动时加载进上下文。子目录有自己的 CLAUDE.md，cd 进去时追加加载。
• OpenClaw：MEMORY.md 和日常笔记分离存储。结构化片段上做向量 + 关键词的混合搜索。

5. 多 Agent 拓扑

• Claude Code：主 Agent → 子 Agent 模式。主 Agent 派遣子 Agent 干活。
• OpenClaw：路由分发模式。入站频道路由到专门的 Agent，再交给共享的子 Agent。

更深的规律：Claude Code 优化的是"一个会话做一件事"。OpenClaw 优化的是"多个对话并发，环境感知存在"。两个都是对的，看你的用例。别选错了。

失败模式与反模式

RAG 失败模式

1. 检索没命中相关片段。 Embedding 模型觉得问题和答案语义距离很远，其实并不远。缓解：混合搜索（向量 + 关键词）、重排序、查询扩展。

2. 检索返回太多无关片段。 上下文窗口被噪音填满。缓解：更严格的 top-K、相似度阈值、检索后过滤。

3. 答案根本不在语料库里。 RAG 无中生有不出来——不在索引里的知识，模型还是不知道。缓解：置信度检查，或者 fallback 到 web 搜索。

4. 分块切碎了结构。 你把一个 markdown 文件从表格中间、代码块中间、论证中间切开了。缓解：结构感知分块（按 heading / paragraph / 语义单元）。

Agent 失败模式

1. 推理跑偏。 Agent 陷在循环里，反复尝试同一个失败方法的变体。缓解：最大步数限制、tool call 去重约束、显式的"我试过什么"记忆。

2. 权限越界。 Agent 做得太多。被要求修一个测试，结果重构了半个文件。缓解：prompt 里写明 scope，工具权限收窄，破坏性操作上 human-in-the-loop。

3. Tool call 级联失败。 一次错误的工具调用（比如路径写错），后面跟着五步在"修补症状"而不是"找根因"。缓解：工具返回清晰的错误信息，“试一次失败就上报"的工具设计。

4. 在错的地方烧钱。 20 步 Agent 循环的成本是单次 LLM 调用的 20 倍。如果 RAG 能回答的问题用 Agent 做，你就花了 20 倍的钱拿到更差的答案。缓解：先问自己"这能不能一次检索搞定？“再决定上不上 Agent。

最糟的反模式：RAG 够用却上了 Agent

团队最贵的错误，是给搜索问题做了个 Agent。

如果用户问的是 “文档里哪里写了……？"，你不需要 Agent。你需要一个搜索框接上向量索引。停止用多步推理烧 token 去找一次检索就能浮上来的东西。

给开发者的实战清单

如果你正在做新的 AI 功能，按这个顺序问自己：

1. 把问题用动词描述。 “回答关于 X 的问题” → RAG。“代替用户做 X” → Agent。
2. 如果一次检索能搞定，就一次检索。 更便宜、更快、更可预测。
3. 上 Agent 就在第一天设计权限。 不是第 50 天。Pinterest 的双层认证不是 feature，是生存必需。
4. 为混合模式留接口。 真实 Agent 内部一定会需要 RAG 式检索。挑一个协议（MCP 是显然的默认）一直用。
5. 全链路埋点。 Tool call 次数、检索命中率、跑偏指标。看不到就调不好。
6. 每个任务设预算。 Token 和迭代步数都要设。没有预算的 Agent 会创造性地永远花在错的地方。

收尾

RAG vs Agent 的对立框架在 2023 年合理——那时它们是两个抢同一个工作的范式。到了 2026 年，它们是同一个系统的互补层。

真正有意思的问题不是选哪个，而是 你问题的哪一层属于哪一层。分对了就能交付。分错了就要花一个季度重做。

对大多数现在在落地的团队来说，答案长这样：

                ┌───────────────────────────────┐
                │   Agent 循环（外层）          │
                │   推理 + 工具选择              │
                └──────────┬────────────────────┘
                           │
        ┌──────────────────┼──────────────────┐
        │                  │                  │
        ▼                  ▼                  ▼
    RAG 检索        操作类工具           计算
    （知识）        （修改状态）        （数学、代码）

Agent 做决策。RAG 提供信息。工具执行动作。这就是全栈。

参考来源

• ByteByteGo EP216 — RAGs vs Agents
• ByteByteGo — How Pinterest Built a Production MCP Ecosystem
• ByteByteGo EP214 — Claude Code vs. OpenClaw: 5 Design Dimensions
• Simon Willison — The Last Six Months in LLMs in Five Minutes
• Latent.Space — All Model Labs Are Now Agent Labs

AI Brew 是一个 AI 工具和开源项目的精选站。每个推荐都先经过实测才会出现在这里。

你能看到什么

• 工具实测 — 真上手用过。能跑通吗？值得花时间吗？
• 开源项目深读 — 值得关注的 GitHub 项目，用人话讲清楚。
• 上手指南 — 一步一步带你用 AI 做出真实可用的东西。
• 横向对比 — “X vs Y vs Z 谁更适合做 …” 的实用对比。
• 专题合集 — 主题清单，需要选择时一目了然。

理念

互联网不需要又一个 AI 新闻聚合器。我们酿造，不喷洒——每篇文章都经过测试、筛选、为人类而写。

谁在写

一个每天都在用 AI 工具的人。花在折腾上的时间比写作多——能进到这里的都是从折腾里活下来的。

一句话 — 华为在 IEEE ISCAS 2026 发布的韬(τ)定律，把摩尔定律的"缩晶体管尺寸"换成"缩时间常数 τ"，覆盖整个计算栈。论文是真的，量产数据是具体的，但"自登纳德以来第一个缩放定律"这个口号经不起细看。本质上这是一篇扎实的 3D 集成工程论文，外面包了一层关于中国如何在没有先进光刻的情况下做高性能芯片的战略叙事。

发布概况

2026 年 5 月 25 日，IEEE 国际电路与系统研讨会（ISCAS）在上海举行。华为半导体业务部总裁何庭波做主旨演讲，题为《半导体新路径探索与实践》。核心内容：一个新的缩放原则，华为命名为韬(τ)定律，对外宣称是"中国首个系统性半导体产业发展原则"。

同日，论文《A Time Scaling Theory for Multi-Layer Electronic Systems》提交到 ChinaXiv 预印本平台（ChinaXiv:202605.00224）。几小时内阅读量超过 3 万、下载量超过 1.3 万——这在预印本平台上不常见。

这件事值得认真对待，正因为它是论文，不是 PPT。

核心 reframe

过去 60 年，摩尔定律靠"缩晶体管尺寸"推动半导体进步。论文开篇承认行业共识：

“For six decades, Moore’s geometric scaling drove progress in semiconductors… returns from pure dimensional shrinking have flattened, leading-edge design budgets exceed one billion dollars per chip, and cost-per-transistor at the most advanced nodes is no longer falling.”

那么下一阶段缩什么？论文的关键转折在这一句：

“Spatial scaling served merely as the instrument for compressing time.”

（空间缩放只是手段，本质压缩的是时间。）

换言之：摩尔定律从来不是关于晶体管面积，而是关于"系统完成一件事需要多少时间"。用户根本不在乎芯片是 3nm 还是 5nm，他们在乎的是 App 200ms 还是 300ms 打开。

如果时间一直是底层目标，为什么不直接把时间作为衡量指标？ 这就是 τ 缩放：用单一特征时间常数 τ 作为统一优化目标，覆盖从晶体管开关（皮秒）到 AI 工作负载（秒），跨 12 个数量级。

论文最强的方法论主张是这一句：

“τ scaling is the first scaling principle since Dennard to establish a shared optimization target across the entire computing stack.”

（τ 缩放是自登纳德缩放以来第一个为整个计算栈建立统一优化目标的缩放原则。）

这是个大主张。后面会再讨论。

τ 怎么算：四层结构

论文把 τ 拆到四层，每一层都有自己的优化目标：

有意思的是论文把频率、延迟、带宽、吞吐都归到 τ 的不同层级——一个框架，12 个数量级。

量产案例 #1：Kirin 2026 SoC

这是论文最实在的部分。Kirin 2026 是首款采用 LogicFolding 的商用芯片，今年秋季上市。

LogicFolding 到底干了啥

“LogicFolding is a design methodology that partitions digital, analog, and memory circuits across vertically stacked active tiers.”

人话：原本平面布局的数字 / 模拟 / 存储电路，被拆分到多个垂直堆叠的有源硅层，通过高密度混合键合连接。原本要在 2D 平面绕远路的信号，现在走垂直短路。

效果：

“Signal wires become substantially shorter, parasitic RC decreases sharply, clock skew tightens, and the chip operates at a higher clock frequency at the same device node.”

关键词是 “at the same device node”——不换光刻节点，靠重构互连拓扑拿性能。从晶体管那里拿不到的，从走线那里拿。

数据（论文给的）

Kirin 2026 实测：

如果第三方独立测量能复现这些数字，这不是工艺节点升级，是结构重组的工程成果。

量产案例 #2：AI 数据中心

任何缩放原则的硬测试：毫瓦能跑通，吉瓦能跑通吗？

“Whether a principle developed in the milliwatt smartphone regime survives translation to the gigawatt regime of AI training and inference.”

论文给的答案是：能，但前提是必须把 τ 当系统目标，不能只优化单颗加速器。

关键的瓶颈 reframe

论文最重要的产业判断：

“Modern AI systems are dominated by data, not by compute. Over 80% of energy in large AI clusters is spent on data movement, and over 70% of system cost goes to data storage.”

（现代 AI 系统由数据主导，不是计算。大集群 80% 能耗花在数据移动上，70% 成本花在数据存储上。）

这是 AI 基础设施的隐性真相：芯片规格表上的 TOPS 数字大多数时候不重要，因为 80% 能耗都耗在芯片间、机柜间、存储层间搬字节。

三件套方案

1. 灵衢总线（Unified Bus） —— 内存语义统一总线，消除 PCIe / NVLink / RDMA / Ethernet / InfiniBand 多层协议转换：

“Conversion-free, peer-to-peer transmission.”

端到端远程访问延迟从 几十微秒降到约 100 纳秒，主通信路径的系统 τ 缩短约 500 倍。

2. Hi-ONE 近封装光互连 —— 单芯片到了多 Tb/s 后铜互连撑不住：

“At multi-Tb/s per chip, copper becomes physically impractical.”

Hi-ONE 单模块 8 Tb/s 带宽，面板到面板 100 米，单条光链路匹配芯片 UB 带宽。

3. 3D Folding —— 扇出困境：计算面积按芯片面积（N²）增长，但 I/O 和供电只能沿芯片周长（N）增长。解决方法：把 I/O 和供电折叠到垂直堆叠里，不再挤在边缘。

预测：2035 年硬件集成度增长 100 倍以上。

老实的免责声明

论文里有一句话埋得比较深，但对理解 τ 缩放不是什么特别重要：

“τ is a time law, not a joule law.”

（τ 是时间定律，不是焦耳定律。）

人话：τ 缩放解决的是时间问题，不解决能耗。如果你把 AI 集群加速 10 倍但功耗也涨 10 倍，瓶颈只是从延迟换到了电力、散热和钱上。

论文承认这一点，并指出需要配套手段：协议精简、降低每比特传输能耗、近存计算、背面供电、动态电压频率调节。但这些是配套，不是 τ 框架本身的产物。任何评估 τ 缩放的人都应该记住这条边界。

值得肯定的是，何庭波在论文里显式承认了这个边界——不像大多数"新定律"营销稿，对自己的局限轻描淡写。

经得起推敲的部分 vs 需要审视的部分

经得起推敲

• 真有论文，真有数据。ISCAS 主旨 + ChinaXiv 预印本 + 量产芯片实测数字。不是营销 PPT。
• 对自己的边界诚实。“τ 不是焦耳定律"这句话显示了工程师的克制。
• 战略上自洽。在没有 EUV 光刻访问权的前提下，中国需要一条"不依赖 2nm / 1nm 工艺节点也能做高性能芯片"的路径。3D 集成 + 系统协同就是这条路。给它一个名字和可测量的指标，是合理的。
• Kirin 2026 秋季上市。可验证的主张有可验证的时间节点。

需要审视

“自登纳德以来第一个缩放原则” 这句话承担了太多。但是：

• 3D 集成早已存在。TSMC CoWoS、Intel Foveros、AMD chiplet 封装、Samsung X-Cube——都是某种形式的垂直集成。
• HBM 本质上就是 3D 折叠的存储栈。
• Imec 的 CFET 研究就是 gate 级别的 3D folding。

论文用"作用层级不同"来区分 LogicFolding 和现有 3D IC / chiplet——前者作用在芯片内部的电路拓扑，后者作用在封装层级。这是合理的区分，但这是一个增量改进，不是范式突破。

“2031 年达到 1.4nm 等效密度” 是个密度目标，不是工艺节点目标。论文这里说得比较小心，但周边媒体报道经常混为一谈。3D 堆叠拿到的等效密度是真的；这不等于产业链能造真正的 1.4nm 节点，不应该混淆。

“6 年 381 颗芯片基于 τ 缩放” 是事后归纳。华为一直在出芯片，追溯性地把它们归到统一理论框架下是好叙事，但不验证这个理论的预测性。

没有公开的对标基准。TSMC N2、Intel 18A、Samsung 3GAP 在这个 τ 图上的位置是什么？论文没说。在独立测量做了苹果对苹果的对比之前，“2035 年 100 倍"是路线图，不是结果。

战略意义

去掉"缩放定律"的外壳，剩下一个自洽的产业论点：

“如果你重新组织芯片内部的电路结构、并把整个系统作为单一优化目标，你不需要最先进的光刻工艺也能造出有竞争力的高性能芯片。”

这是为不依赖 ASML EUV 机器的中国半导体战略给出技术支撑。同时也是对 AI 基础设施的另一种愿景——以互连为中心、系统级协同设计、边缘上光、不再到处铺铜。

不管韬定律会不会成为"下一个摩尔定律”，它实际演示了后摩尔时代有多条路径。问题是哪条路径能兑现承诺。

接下来盯什么

• Kirin 2026 秋季上市：41% 能效、55% 密度提升——第三方能复现吗？
• ISCAS 2026 论文正式版：LogicFolding 声称的 RC 缩减有没有其他解释？
• 行业反应：TSMC、Intel、Samsung 会不会跟进 τ 式叙事？还是搞自己的"缩放原则"品牌？
• 能耗数据：既然 τ 不解决能耗，AI 负载在昇腾上的实际 J/op 跟英伟达最新代差多少？
• 超出 Kirin：LogicFolding 会下沉到昇腾 AI 芯片吗？论文声称适用 AI 系统，但量产 demo 只有手机 SoC。

一句话定性

韬定律论文是一篇扎实的工程论文，外面包了一层超大号的战略叙事。技术核心——LogicFolding、灵衢总线、Hi-ONE、3D Folding——都是有实测数据的真东西。把它框定为"下一个摩尔定律"在方法论上夸大了这件事——这本质是已知 3D 集成技术的增量延伸，加上系统级协同设计。

这不是批评。绝大多数真实的工程进步都是增量的。营销层是给工程层提供资金的方式。真正重要的是 Kirin 2026 今年秋天上市时，能不能跑出论文里宣称的数字。如果能，那中国就发表了一份可信的高性能芯片技术路线图，而这份路线图不依赖于先进光刻——这件事比"下一个摩尔定律"重要得多。

参考来源

• Tingbo He — A Time Scaling Theory for Multi-Layer Electronic Systems（ChinaXiv 预印本）
• 华为官方 — ISCAS 2026 韬(τ)定律
• 与非网 — 速读何庭波"时间缩放"论文
• Gizmochina — Huawei proposes Tao Law as alternative to Moore’s Law
• 21 经济网 — 韬定律是什么，跟摩尔定律有什么不同
• 证券时报 — 韬(τ)定律来了！华为半导体，突传重磅
• 虎嗅 — 华为发布"韬定律"半导体新理论 提出以时间缩微替代几何缩微