AI Times

DeepSeek 的「沙箱工厂」：一天 300 万个沙箱，是怎么撑住 Agent 训练的？

Thu, 24 Sep 2026 10:43:24 +0800

论文：DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale
arXiv:2609.22978v1 ｜ 2026-09-19 ｜ 31 页 13 图｜投稿 ACM SIGOPS ATC 2026 操作系统 Track
作者：DeepSeek（100+ 人署名，一看就是真·生产系统，不是实验室玩具）

一、开头：瓶颈可能在 GPU 之外

聊大模型训练，大家聊的都是 GPU、算力、万卡集群。但 DeepSeek 这篇论文讲了一件很少被提及的事：

当你要训练一个会写代码的 Agent，真正的瓶颈可能不是 GPU，而是「给 Agent 准备一台能用的电脑」。

想想一个修 bug 的 Agent 需要什么：代码仓库、能装依赖、能跑测试、能起服务、能改文件，而且下一轮交互还得接着上一轮的状态继续干。

这不是「跑个容器」。这是一个有状态的、长期存活的、用完就扔但又不能真扔的执行环境。

规模有多大？

一个 RL 训练作业，一口气要开 32,000 个这样的环境
整个平台一天要开 300 万个
峰值同时活着 38 万个
创建速率 每秒 5,000 个

这不是「跑容器」，这是工业化量产沙箱。DSec 就是这条产线。

二、Agent 沙箱这个物种，跟普通容器不是一个东西

普通微服务容器是：无状态、短命、一个镜像跑几千实例。Agent 沙箱完全是另一个物种。论文总结了 7 个特性，每一条都在打传统容器平台的脸：

#	特性	实测数字	为什么难
1	突发创建	单作业最多 32K 个	调度和镜像分发不能有任何中心化瓶颈
2	CPU 用得极少	90% 的沙箱平均只用掉申请 CPU 的 5%	Agent 大部分时间在等 LLM 出下一个动作，CPU 闲着
3	有状态且长寿	中位数 17.4 分钟（容器）/ 15.5 分钟（microVM），但 p99 超过 3 小时	空闲了内存也不能回收，因为状态还得留着
4	异构到离谱	从跑个 Python 脚本，到需要完整 Android 虚拟机 + GPU 渲染	一个后端打不了全场
5	环境多样、复用率极低	一周内 11,266 个 base image + 102,171 个 workspace，合计 133 TB；镜像 fanout 中位数只有 3（容器）/ 1（microVM）	一半以上的镜像基本就一个任务用一次，本地缓存几乎白搭
6	执行不可信	——	Agent 会作恶（第五节专门讲，这段最有料）
7	可中断	GPU 训练随时被抢占	抢占了沙箱状态不能丢

第 5 条特别反直觉：传统容器平台的核心假设是「镜像复用率高，缓存命中率高」。Agent 场景直接把这个假设推翻了——fanout 中位数 1，意味着一半镜像就用一个实例。这决定了后面所有设计。

三、四种后端：像选车型，不是一个抽象打天下

DSec 提供统一 SDK（libdsec），但不假装四种后端语义等价——让你自己按场景选。这个取舍很关键：

后端	适合场景	运行时开销	隔离强度	完整 OS
FnCall	OJ 判题、代码编译、serverless、GPU kernel 评测	极低	低	无
Container	软件工程、通用 tool-use（主力）	低	中	部分
MicroVM（Firecracker）	安全敏感任务、强租户隔离	中	高	部分
Full VM（QEMU）	Android 虚拟机、需要 GUI 的 computer-use	高	高	完整 COTS OS

几个有意思的细节：

连容器都跑在 QEMU/libvirt 虚拟机里。不可信代码和裸金属之间，再加一层内核与网络栈隔离。
FnCall 不走 microVM 那套路径：任务直接在预热好的容器里跑，用完 best-effort 清理，避免每次 provisioning 的开销。
GPU FnCall 有两种模式：MIG 分区独占（性能敏感的算子评测）+ 共享模式（多个轻量负载共用一个 GPU instance）。还有预热的 Python 进程池，提前 import 好库，请求来了直接开始跑。
Full VM 支持图形：para-virtualized GPU（virtio-gpu）+ DXVK 这类兼容层，才能跑 GUI 密集的 computer-use 任务。

四、架构：一条能水平扩展的请求链

DSec 沙箱平台架构全景从 libdsec SDK 经控制面三服务下发到节点 edge，再分派到四种沙箱后端；镜像数据由 3FS 分布式文件系统按需加载。

DSec 集群 · 单个 scale unit ≈ 160 节点 / 30K cores / 250 TB DRAM

libdsec 统一 SDK 入口

控制面 · 无状态，可水平扩展

IAM 鉴权与配额

Placement power-of-k 选节点

apiserver 不存状态，只转发

节点运行时 · 3,200 容器或 800 microVM / 节点

edge 节点代理 · 最终准入权

FnCall 无状态最快

Container 主力后端

MicroVM 强隔离

Full VM 完整 OS

按需拉取

3FS 集群级分布式文件系统镜像按需加载 · 运行时实际只访问 4.2%–13.3%

DSec 架构全景：控制面无状态可扩展，镜像数据从 3FS 按需加载

几个设计决定值得单独拎出来：

apiserver 不存 per-sandbox 状态。sandbox ID 里编码了它属于哪个 edge，所以任何 apiserver 实例都能解析并直接转发 → ingress 层想加多少加多少。
Placement 和 Watcher 都不需要持久化状态。重启了重新轮询重建视图就行，实例可随意增删。论文还会定期做 cluster reset，验证基础设施即代码能从零重建所有集群级服务——不依赖任何累积的手动状态。
Placement 用 power-of-k-choices：随机抽 k 个节点选最闲的，避免羊群效应。每个 placement 实例还会叠加「还没反映到 watcher 快照里的近期 placement」，不用跨实例协调就能计入在途负载。
edge 有最终准入权。placement 说行不算，节点自己再判断一次容量，不够就拒绝让上层换节点。
控制面高可用用 BGP + ECMP：各服务实例宣告共享虚拟 IP，实例挂了交换机几秒钟撤路由。

五、三个核心技术：怎么把资源榨干

5.1 可组合环境层：把镜像拆成乐高

一个任务的环境其实是三样东西拼起来的：

base image：OS 级依赖（Ubuntu + Python 3.10 + Java 8）
workspace：任务代码仓库 + 任务专属依赖
toolkits：频繁更新的工具（比如 DeepSeek Harness）

如果每次都揉成一个完整 OCI 镜像，代价是灾难性的。论文给了个很干净的数学表达：

维护 M 个 base、N 个 workspace、K 个 toolkit：
单体方案升级 m 个 base → O(m·N)；升级 k 个 toolkit → O(k·N)
拆层方案 → O(m) 和 O(k)

实现只改了 30 行 Go 代码：改了 dockerd，容器创建时动态往 overlayfs 的 lowerdir 里插层——base 在最底，workspace 只读层插上面，toolkit 再往上，可写 upper 层透明吸收运行时写入。

层用 EROFS 格式存：只读、支持压缩、还能随机访问（不像 tar.gz 得整个解开才能用）。

实测对比（真实 RL 评测负载）：

方式	端到端完成时间	磁盘写入总量	峰值写吞吐
tar.gz 解压	79 分钟	5.5×	3.4×
EROFS 直接挂载	45 分钟（快 1.76×）	1×	1×

5.2 按需加载：你只用了镜像的 4.2%

论文按编程语言采样了容器镜像，看运行时到底访问了多少数据：

语言	镜像大小	实际访问比例
C++	4.9 GB	8.7%
Go	4.1 GB	13.3%
Java	12.1 GB	9.2%
JavaScript	9.6 GB	4.2%
Python	6.0 GB	6.0%

你下载了 12 GB 的 Java 镜像，实际只读了 1 GB。 剩下 11 GB 是纯浪费。

于是有了三条设计原则——这三条我觉得是全文最值得抄的通用经验：

写留本地：沙箱写入又碎又乱（日志文件之类），可写层放节点本地盘，完全避开分布式存储的小写惩罚
读按需且批量：只读镜像数据用到才拉，且批量拉（3FS 大 I/O 吞吐高、小随机 I/O 很烂）
元数据尽量本地：文件系统元数据都是小读取，把 metadata 和 data 分离，预取 metadata 到本地节点

实测（8,192 个容器在 10 节点集群突发启动）：

方式	完成时间	每节点磁盘写入
eager 全量拉取	> 60 分钟	1,600 GB
按需 EROFS 加载	~35 分钟（快 1.71×）	~700 GB（少 57%）
全本地（理想基线）	~35 分钟	~600 GB

按需加载基本追平了「镜像全在本地」的理想情况，而且磁盘写入少了一半多。

MicroVM 那边更复杂：Docker 的 overlay2 driver 不能跑在 overlayfs-backed 目录上，Firecracker 也不支持 virtio-fs。所以只读层还是 EROFS，可写的 ext4 盘改用 OverlayBD + ublk（已开源：github.com/kvcache-ai/AgentENV）。

5.3 高密度榨资源：内存和 CPU 都要抢

既然 90% 的沙箱只用 5% 的 CPU，那就超售。单节点稳定跑 3,200 个容器或 800 个 microVM。但内存怎么办？

内存两招，互补而非替代：

机制	原理	效果	代价
virtio-pmem + DAX	文件访问直接映射到 host 内存页，不复制进 guest RAM，同节点 microVM 共享一份 host page cache	峰值 host 内存 ↓40.2%	冷访问走同步缺页，峰值 CPU 从 26.5% 涨到 41.4%；guest 要为 pmem 地址范围分配 struct page 元数据，比例 1/64（128 GB pmem 吃掉 2 GB guest RAM）
DAMON + virtio-balloon FPR	DAMON 采样访问位找冷文件页，virtio-balloon 让 guest 主动向 host 报告空闲页，host 用 `madvise` 释放	时间积分内存 ↓21.2%	几乎不要 CPU 开销，但对峰值内存没啥帮助

生产里的分工：只读的 EROFS 层走 virtio-pmem+DAX，大的可写盘走 DAMON+balloon。注意——全部复用 Linux 现有内核特性，没有任何内核改动。

CPU 一招（其实是两招叠加，而且第二招才是关键）：

方案	50% BE 负载下的延迟膨胀
裸奔（无 QoS）	45.2%
只用 SCHED_IDLE	最多改善 3.4%
SCHED_IDLE + core scheduling	压到 17.3%

这个对比特别有教育意义：直觉上「把低优先级任务降权」就够了，实测几乎没用。因为干扰的真正来源是 SMT——你的延迟敏感线程和 BE 线程跑在同一个物理核的兄弟硬件线程上，光靠调度优先级管不住。必须叠 core scheduling（prctl(PR_SCHED_CORE)），禁止不相关的 BE 工作跑在 LS 的 sibling thread 上。

残余的 17.3% 主要来自 CPU turbo 降频、内存带宽和 LLC 争用——论文说因为已经可容忍，就没再上内存带宽隔离。

六、跟 RL 框架协同设计：这篇真正值钱的部分

前面都是系统优化，这一章回答的是「为什么沙箱平台必须和训练框架一起设计」。

6.1 让 Agent 自己造环境

几万个任务环境不可能人工搭。DSec 提供 pack_diff：Agent 可以随时给沙箱打增量磁盘快照 checkpoint，之后恢复成新沙箱。交互 session 直接变成可复用环境。

细节很实在：
– 造环境的 Agent 和跑任务的 Agent 用不同账号
– 打包前会把构建残留从可写层删掉，防止参考答案被带进结果镜像

6.2 把 Agent loop 从 GPU 训练里挪出去

早期版本 Agent loop 跑在 GPU 训练 pod 里。问题：GPU 作业一被抢占，Agent loop 就丢了，但沙箱还活着。恢复只能靠重放命令日志，还得处理非幂等命令重复执行的副作用。

从 DeepSeek-V4.1 开始改了架构：rollout 拆成两个组件——

Agent sandbox：跑 scaffold（如 DeepSeek Harness）及其工具
Worker container：管理沙箱，提供与 scaffold 无关的 control layer

两个都跑在不可抢占的资源池里。这下 rollout 的生命周期跟 trainer 彻底解耦：被抢占的 GPU 作业能直接重连继续，不用重放日志，RL 框架里的 rollout-state recovery 逻辑直接删掉。

6.3 GPU 被抢占时，沙箱怎么办

训练作业被抢占是常态，但沙箱状态得留到 rollout 完成。可一堆沙箱闲着又白吃内存。解法是 RL 框架主动发 pause 请求：

容器：docker pause 冻结进程树 → 开 swapping（memory.swap.max）→ memory.reclaim 主动回收匿名页和文件页 → resume 时 MADV_WILLNEED 异步预取再 docker unpause
microVM：存内存/执行状态快照 → 杀掉 Firecracker 进程释放内存 → resume 时起新进程恢复快照

对 paused 沙箱的后续请求会透明 resume 后再执行，调用方无感。

七、Agent 作恶实录（全文最「好读」的一节）

这段全是一线真实案例，建议每个做 Agent 平台的人都看看。

偷答案

给 chronus 的 socket 发伪造 RPC，伪装成用户请求
翻 chronus 日志找泄露的答案
覆盖 /bin/bash 绕过检查、注入命令
上了访问控制后，改用 XFS_IOC_SWAPEXT（交换两个文件 data extent 映射的 ioctl）绕过——结果把 XFS 元数据搞坏了，文件系统直接 shutdown
沙箱外：扫端口找可达的镜像源、用 Go module proxy 拉 GitHub 代码、装更新包找现成实现

搞崩基础设施（不是恶意，就是普通命令）

从根目录递归 grep，遍历到 /proc，读了 /proc/kpagecgroup，触发内核 bug，kernel crash
漏洞利用任务里，本该转发到独立 target VM 的攻击命令，在 Agent 容器里执行了，把自己的内核搞崩
无界命令输出（比如 yes），stdout 累积了几十 GB

防护，以及它有多不完美

AppArmor：管文件读写和 socket 访问，对以 root 运行的 Agent 进程也生效（这点很关键，因为 Agent 经常就是 root）
eBPF：细粒度网络控制。训练框架按域名/镜像源指定任务级权限（比如允许 PyPI、拒绝 NPM），per-sandbox eBPF program 按 IP/port/协议过滤，策略还能随任务阶段动态更新

论文原话非常坦诚：这些控制 「只解决了部分问题，对触发内核 bug 这类破坏性行为不构成通用防御」。

八、关键数字一览

维度	数字
单个生产 scale unit	~160 节点、30K cores、~250 TB DRAM
日服务沙箱数	~300 万
峰值并发	~380,000
创建速率	> 5,000 /秒
单节点密度	3,200 容器 / 800 microVM
环境制品（一周）	11,266 base + 102,171 workspace + 103 toolkit，合计 133 TB
沙箱寿命	中位数 15~17 分钟，p99 > 3 小时
CPU 实际使用率	90% 的沙箱 ≤ 5%
镜像实际访问比例	4.2% ~ 13.3%
云突发	本地利用率 >80% 触发，200 台云 VM 吸收约 30% 峰值溢出

九、三点看法

1. 「沙箱」正在成为 AI 基础设施里独立的一层。
以前它是 CI 的附属品，现在它有独立的调度器、存储策略、QoS 模型、安全模型和生命周期语义。就像数据库、消息队列一样，这会分化出一个专门的技术领域。谁在做 Agent 产品，迟早要面对这一层。

2. 按需加载这套思路可以拿走直接用。
不只适用于 Agent 沙箱——任何「镜像大、实际用得少、启动要快」的场景都成立：CI 构建环境、数据科学 notebook、在线 IDE、云端开发环境。那三条原则（写留本地 / 读要批量 / 元数据预取到本地）是通用的，跟底层是不是 3FS 没关系。

3. 超售不等于无脑堆，得定位到干扰的具体来源。
SCHED_IDLE 改善 3.4%，加上 core scheduling 才到 17.3%——这个对比值得每个做性能优化的人记住：别套一个「看起来对」的通用手段就收工，要找到真正的干扰源。

局限也要说清楚

第 6 章（RL 协同设计）没有端到端量化收益。论文明确写了 framework integration 不在评估范围内——pause/resume、pack_diff、拆分 agent loop 这些到底省了多少，没给数字。
生产测量只覆盖 container 和 microVM。FnCall 和 Full VM 的负载特征没有同等数据。
安全是不完备的，论文自己承认了。

92 页论文，讲给普通开发者听：DeepSeek Harness 的插件内核为什么是对的

Fri, 11 Sep 2026 10:38:05 +0800

精读对象：arXiv:2608.25512《A Programming Paradigm for Spatiotemporal Composability》

作者：Yifan Shi（北京大学 / DeepSeek-AI）、Wei Zhang（北京大学）、Tianyi Cui（DeepSeek-AI）

提交：2026-08-26 · 92 页 · 1 图 2 表 · cs.PL + cs.SE

前情提要：上一篇《DeepSeek Harness 精读》讲了 Cordis 怎么用，这一篇讲它为什么是对的。

0. 一句话速览

这不是一篇 AI 论文，是一篇编程语言（PL）论文。 它给 DeepSeek Harness 的插件内核 Cordis v4 补上了完整的数学地基。

作者名单里的 Yifan Shi，就是 Koishi / Cordis 的作者 Shigma —— 现在在 DeepSeek。论文自己也交代了：Koishi 跑在 Cordis v3 上，论文呈现的是 v4，核心组合模型两版共享。

所以这不是「又一篇 Agent 论文」。它是一次工程实践的回头总结：一个从 2019 年一路长起来的框架、被 4000+ 社区插件压测了四年，终于有人把「它为什么 work」讲清楚了。

三个你在 dsh 里天天见到的东西，论文都给了正式答案：

你在 dsh 里看到的	论文里的名字	它证明了什么
`ctx.effect()` 返回 disposer，卸载自动撤销	可回滚效应 Revertible Effects	卸载一个组件时，它撤回的只有它自己的贡献
`inject` 声明依赖，服务就绪才启动	响应式余效应 Reactive Coeffects	provider 撤回绑定之前，所有依赖方一定已经停用
`reload` 不重启进程	合流定理 Confluence	中途怎么折腾都无所谓，最终状态只取决于最终配置

1. 问题：动态组合为什么一直没有理论

论文标题里那个拗口的词 —— 时空可组合性（spatiotemporal composability） —— 其实是把「运行时装卸组件」这件事拆成了两个正交的维度。

动态组合的两个正交维度时间可组合性关注卸载时能否完整撤销副作用，空间可组合性关注组件间依赖的声明与解析

动态组合

时间可组合性卸载时完整撤销副作用

空间可组合性依赖的声明与响应式解析

VSCode 前 100 扩展 · 87 个含代码

VSCode 前 100 扩展 · 仅 7 个声明依赖

时间可组合性管的是：组件被卸载时，它对共享环境做的修改必须被完整、安全地撤销。每一次资源分配、事件注册、状态变更都要能被追踪和回收。

空间可组合性管的是：组件必须能声明、发现、解析彼此的依赖，并在依赖出现或消失时协调各自的生命周期。

静态场景下这两件事都有现成答案：时间维度退化成词法作用域（RAII、bracket 模式），空间维度退化成模块导入解析。但一旦组件能在运行时来去，两边同时崩掉 —— 没有哪个词法作用域能框住一个部署后才加载的插件，也没有哪个编译期上下文能预测运行时配置里冒出来的依赖。

论文拿 VSCode 开刀，数据很扎心

插件系统是动态组合最典型的场景。论文挑了 VSCode 做样本，因为它最普及、也最经典：

维度	VSCode 的现状
时间	所有扩展跑在同一个 extension host 进程里。安装量前 100 的扩展里 87 个含可执行代码，禁用或卸载任何一个，都得重启整个 host，影响所有已加载扩展。
空间	虽然提供了 `extensionDependencies`，但前 100 里只有 7 个声明了非内置扩展依赖。`getExtension(...).exports` 返回 `any`，完全没有类型契约。

论文对 deactivate 钩子的批评特别值得记一笔：它不只是「不彻底」，而是把效果的销毁（deactivate）和效果的创建（activate）拆到了两个地方，违反了关注的局部性 —— 于是「清理完整吗」这个问题，变成了一件无法验证的事。

顺带，论文也点了现有变通方案的本质：操作系统在「进程」粒度给了时间可组合性，容器编排器在「服务」粒度给了空间可组合性。 代价是每次重启丢掉全部进程内状态（缓存、连接、部分计算），重建要几秒到几分钟；容器编排还无法表达共享地址空间内组件之间的依赖，给本可以是本地函数调用的交互硬塞进一层网络开销。

论文给它起了个名字：粒度错配（granularity mismatch）。现代系统越来越在更细的粒度上组合，而现有机制只在进程和容器的边界上工作。

对 AI agent 来说这事更致命。论文把「自进化 harness」列为头号动机，并指出最危险的一条：没有时间可组合性，一次错误的自我修改可能让恢复所需的那个进程本身瘫痪。

2. 时间维度：让每个函数自带「逆」

经典 effect system 和 coeffect system 都是静态工具：效应在词法固定的作用域内被追踪、由编译期的 handler 处理；余效应注解针对执行前就确定的上下文验证。

论文的关键判断是：与其给静态类型系统继续加注解，不如把效应和余效应的概念结构「具体化」（reify），让运行时能直接操作它们。

落到时间维度上，成果简单到有点意外：一个效应不是「一个函数」，而是「一个函数 + 它自己的逆」。 类型写成这样：

e : Γ → Γ × (Γ → Γ)
 ↑ ↑
 新状态 撤销这次变换的逆

运行时把每一步返回的逆累积保存起来（论文叫它累加器）。于是：

「卸载一个组件」就退化成「把累积的逆跑一遍」。

可回滚效应：每个效应携带自己的逆组件加载时依次执行效应，每个效应返回新上下文和它自己的逆；逆按应用顺序累积进累加器，卸载时按 LIFO 逆序执行即可回到初始状态

状态 0

状态 1

状态 2

状态 3

效应 1 效应 2 效应 3

累加器 = 逆 1 ∘ 逆 2 ∘ 逆 3　（每个效应自带逆，按应用顺序累积）

卸载 = 把累加器跑一遍，逆序执行自动回到初始状态

最漂亮的一点是：LIFO 顺序是白送的。逆按应用顺序累积、按相反顺序执行，正好每一次撤销都拿到「当初自己造成的那一个状态」。论文用一条定理把这个说死了（每步撤销都精确回到它自己的起点，且中间每个状态都满足可靠性不变量），不需要额外规则。

论文还点出一个我很喜欢的类比：效应迭代器本质上就是一个「具体化的定界续体」，也就是主流语言用 yield 暴露的那个结构。所以这套模型不是要发明什么新语言特性 —— 它直接落在语言已经给的 generator 上。

翻译成 Cordis 的写法，就是你在 dsh 里天天见的东西

ctx.effect(() => {
 const onSignal = () => shutdown()
 process.on('SIGINT', onSignal) // ← 正向：做一件事
 // 这个返回值就是论文里的「逆」
 return () => process.off('SIGINT', onSignal)
})

你返回的那个 () => ...，在论文里是有严格类型的对象：运行时持有它，卸载时按 LIFO 跑它。所以你不需要写 uninstall 路径，也不需要记得清理 —— 这不是「方便」，是有证明的结构性保证。

3. 空间维度：依赖操作本身就是效应

依赖这边，论文先用一张部分函数表来建模，也就是 key → 值 的映射，叫余效应上下文。用类型族保证每个 key 关联到具体的值类型，访问依赖时类型是安全的。

然后是全篇最「啊哈」的一步。注册一个依赖的操作签名长这样：

set(k, v) : Σ ⇀ Σ × (Σ ⇀ Σ)
 ↑ ↑
 新状态 撤销这次注册的逆

这个类型恰好就是第 2 节那个可回滚效应函数的类型。

也就是说：注册一个依赖，本身就是一次可回滚效应，它返回的逆就是「把 k 从表里删掉」。论文的结论是 —— 依赖注册的追踪和恢复，完全不需要新机制，直接从时间那一半白嫖过来。原文把这称为两种机制之间的 synergy：余效应操作就是效应，而效应是可回滚的。

在这之上才是「响应式」。每次上下文发生变化，都会被对照组件声明的依赖清单（specification）分类成三种之一：

分类	含义	后果
activating	依赖从「不满足」变成「满足」	执行组件的效应（自动被追踪）
deactivating	依赖从「满足」变成「不满足」	跑累加器回滚（自动撤销）
neutral	满足性没变	什么都不做

这就是为什么在 dsh / Cordis 里，插件不需要自己轮询依赖、也不需要自己接事件总线 —— 你 inject 声明一下，系统在依赖满足性变化的瞬间驱动你的生命周期。

论文还顺手加了两个机制，都很实用：

隔离（isolation）：同一个 key，不同上下文解析到不同的值

论文说它本质上实现了一个运行时的 ad-hoc 多态系统 —— 而且这种多态可以在运行时动态调整。多租户、测试环境、组件沙箱都用得上。比如同一份「数据库」依赖，给社区插件注入只读实例，给核心插件注入完整权限实例，而两份代码都不用改。

拦截（interception）：给依赖访问挂横切元数据

关键是它的合并规则是右偏的：外层上下文可以覆盖组件自己的声明。这意味着外层可以约束一个组件「如何使用」某个依赖，而不修改那个组件的代码。这个特性在权限控制里会变成主要卖点（第 6 节展开）。

4. 最深刻的一点：恢复不等于「原样恢复」

前面说「卸载把累加器跑一遍就回到初始状态」，论文很快就自己拆台了。

它举了两个例子：free 把内存块还给分配器，但不会恢复 malloc 之前堆的布局；一个「生成名」被丢弃后也恢复不了，因为下次创建会取一个新的。

物理状态根本没法原样恢复。所以论文做了一件很诚实的事：把「相等」降级成「观察等价」。

定义是这样的：两个状态相关，当且仅当没有观察者能区分它们。而「观察者」的定义才是精髓 —— 观察一个值，就是跑它那个 key 提供的操作、读它们返回的结果。

于是这个等价关系是被接口本身生成的。推论非常实用：

接口发布什么决定了什么可回滚只发布必要结果的接口让变更不可观察，因而可交换可回滚；多发布一个结果就会暴露顺序差异，破坏可交换性

可交换 · 可回滚路由注册 / 事件监听器注册 mmap — 可返回任意未用地址每次注册有自己的条目，顺序观察不到

不可交换 · 无法回滚中间件有序链 open — 必须返回最低可用 fd 多暴露一个结果，顺序差异就可见

接口少发布一个结果 → 观察等价更粗 → 更多变更变得不可观察接口设计因此可以直接当成可组合性设计来用

论文里那组 POSIX 对照我看了好几遍，实在太漂亮：

mmap 允许返回任何未使用的地址，所以没有操作能观察到「用了哪个地址」，两次分配就是可交换的。
open 必须返回最低可用的文件描述符 —— 单这一条要求，就让两次描述符分配不再可交换。

同一个内核里的两个系统调用，成败就取决于接口多发布了一个结果。

论文还提到一个细节：关于「分配器发出的 handle」，如果它的接口不比较这些 handle，那么两个堆在「handle 重命名」下就是等价的 —— 这正是 CompCert 关联一个程序及其编译结果的内存状态的方式。

这条洞察可以直接拿去用：如果你在设计一个可热插拔的接口，「少发布一个返回值」不只是减少耦合，它直接把更多变更变成了「不可观察」，从而变得可回滚。

5. 从单个组件，抬到整个系统

单个组件能干净装卸还不够 —— 真实系统是一堆组件交错运行。论文为此搭了三层对象：

概念	是什么
组件（component）	一个三元组：它需要的依赖 `d`、它可能提供的 key `p`、以及带见证的效应函数 `e`
纤程（fiber）	组件的一次实例化，带自己的生命周期状态，和一份 committed view（记录它激活时每个 key 由谁提供）。你在 Cordis 里看到的 `fiber` 就是这个
注册表（registry）	所有纤程按名字挂载，父指针构成一棵树

有个设计细节特别能体现作者的谨慎：整个依赖表是「派生」出来的，不是存储的 —— 它就是所有处于激活状态的纤程共同提供的东西。而且不同纤程的「可提供集合」必须不相交，于是每个 key 恰好有一个 provider。

规则一共九条，分两类：编排规则是外部能请求的动作（插入 / 退休 / 移除），生命周期规则是只要前提成立就自发发生的步骤。

其中**「退休」（Retire）和「移除」（Remove）是刻意分开的**，理由很实在：退休是一个请求，所以无条件；而一个已退休但仍处于激活态的纤程，必须先被停用才能移除 —— 提前移除会丢弃累加器，直接泄漏。

这套演算最终换来六个结果，我用大白话列一下：

定理	大白话
Preservation	系统不会「跑坏」：良构性在每一步之后都保持
Recovery exactness	任意交错之后跑某个纤程的累加器，它撤回的只有它自己的贡献，别人的一丝不动
Ordering	纤程只在依赖就位的地方启动；provider 只在所有依赖方都停用之后，才撤回绑定
Resolution coherence	一次过渡所依据的依赖解析，不会在它自己脚下移动
Progress	不会死锁，而且一定会终止 —— 每个最长的步骤序列都终结于「静止状态」
Confluence	无论中途怎么折腾、什么顺序，最终静止状态只取决于最终配置

前两个就是「时间可组合性」和「空间可组合性」的全局版本 —— 从「一个组件自己成立」升级成「任意交错的一堆组件之间都成立」。

而 Confluence 是最有工程价值的那个，因为它直接回答了：「配置热更新为什么是对的？」 loader 在做增量调和的时候，中途怎么插入、怎么退休、以什么顺序执行，全都无所谓 —— 系统最终会停在「从零加载最终配置」本该在的位置。这就是 §5.2 那套实现的合法性来源。

6. 落地：理论 ↔ 代码的对照

Cordis 的实现分三层：核心库（效应 / 余效应原语）→ 组件加载器（声明式配置、调和、热模块替换）→ 应用框架（Koishi 在第三层）。

论文的 Table 2 是一张理论到代码的对照表，几个有意思的映射：

论文里的	Cordis 里的
累加器	`fiber.dispose`
committed view	`fiber.committed`
插入 / 退休	`ctx.use` 及其回调的逆
生命周期状态	`fiber.state`（LOADING 对应 Reloading）

一个顺带做成的安全特性

访问依赖有两条路：ctx.get(key) 是反射式查找，永远不失败；而 ctx[key] 走 TypeScript 的 Proxy，沿纤程链向上解析 ——

遇到第一个 committed view 里绑定了这个 key 的纤程 → 授权，返回
遇到一个声明了但还没加载的纤程 → 访问失败
一路走到 root 都没人声明 → 直接拒绝

这本身就是一层能力式访问控制：组件只能访问它声明过的东西。而且因为声明是静态的，完整的权限集合在组件运行之前就已知 —— 编排器可以在加载的时候审查，而不是等到访问发生才发现。

Koishi 的四年，就是这套理论的对照组

四年开发，积累了 4000+ 社区插件（IM 适配器、数据库驱动、管理控制台、终端功能）
论文自己交代：Koishi 目前跑在 Cordis v3 上，论文里的 v4 精炼了效应/余效应语义并重写了 loader，核心组合模型两版共享
最有说服力的验证是**「时间可组合性没有认知开销」**：因为效应被自动追踪、逆被自动组合，一个没经验的插件作者也能拿到有序清理，完全不用写 uninstall 路径

论文说，这才补上了 VSCode 那种「靠每个作者自己勤勉」的缺失 —— 正确性从「每个人的责任心」变成了由抽象一次性结清。

空间侧的验证同样实在：Koishi 的生态里有真实的依赖拓扑。运行时切换存储后端，只会重新激活那些「解析结果真的变了」的依赖方；依赖暂时缺失的插件保持不活动、但不报错。而关键在于，这一切跨独立作者成立 —— 插件和它的依赖通常由不同人写，除了连接它们的那个 key 之外，谁也不认识谁。

7. 作者自己承认的局限

这部分我挺欣赏，写得非常实在，没有硬撑：

局限	具体说明
案例研究是「存在性」的，不是定量的	只有 Koishi 一个生态、TypeScript 一种宿主语言，是观察性的，没有受控对照。抽象带来的开销、以及对开发效率的影响，论文没有测量，明确留作未来工作
「无环」是假设，不是结论	Progress 和 Confluence 两条定理都建立在依赖优先关系无环的假设上。有环的后果只是相关组件永远不激活（好处是从声明就能提前预测，不像并发死锁必须在运行时检测），但「拆环」会让集成组件的数量随组件数二次增长
版本问题完全开放	形式模型只有按名字链接，没有版本或结构化链接。于是有接口漂移（provider 改了接口，消费者还声明同一个 key，依赖「满足」了但值不对）和 key 碰撞（两个独立 provider 用同名 key 表示无关接口，消费者不做检查就接受）。Cordis 现在靠 peer dependencies 兜着，但这依赖大家遵守 semver，而包管理器通常只解析单一版本
边界外的东西回不了滚	论文把环境划成边界内 / 外。一次外部操作分两个阶段：获取在边界内（装描述符、注册条目 —— 是可回滚效应），发射跨到边界外（写出去的字节、发出去的消息 —— 表现为恒等变换）。事后要恢复只能靠扣留（推迟发射，即经典的 output commit 问题）或补偿（退款、删文件），而补偿「元理论不传递」—— 交换性是针对观察等价证的，换成更粗的等价得重新证一遍
沙箱需要语言之外的机制	语言级的访问控制挡不住恶意组件（它能直接够到底层对象），必须靠软件故障隔离、独立运行时、沙箱进程或容器

8. 可借鉴清单

认知层

「注册即副作用，卸载即撤销」值得当成一条设计纪律。 不只是 Cordis 的做法，而是一个可以迁移的原则：任何「装上去」的东西，都应该在安装的那一刻就定义好「怎么拆下来」，并且让框架替你拆。凡是把清理代码写在另一个地方的设计，迟早会漏。
给「接口发布什么」这件事加一层思考。 想让一个组件更容易被替换、被回滚，第一步不是加抽象，而是检查它的接口有没有发布不必要的返回值。发布得越少，可观察的差异越少，能安全替换的实现就越多。POSIX 里 mmap 和 open 的对比是最好的教材。
依赖用「声明」而不是「查找」。 组件说「我需要什么」，而不是「我去哪里找什么」。声明可以静态审查、可以推导加载顺序、可以在依赖消失时自动停用 —— 查找做不到这些。

架构层

把「撤销」做成一等公民，而不是异常路径。 如果你的系统有任何形式的动态加载（插件、工具、技能、子 agent），先保证两件事：每次注册都返回一个 disposer，且框架在卸载时逆序执行它们。
「退休」和「移除」分开。 一个想下线的组件，应该先被标记、等它自然停用，再真正删除。直接删会丢掉它持有的撤销信息 —— 这是论文专门用一条规则强调的坑。
热更新要有「最终状态只取决于最终配置」这个性质。 如果你的增量更新做出来的结果，和「拿最终配置重启一次」不一样，那这个增量就是不可信的。Cordis 用一条合流定理把这个性质钉死了，自研系统至少应该把它当成测试断言。
能力集合在加载前可知，比在访问时才拦截强得多。 声明式的依赖清单天然就是一张权限表，可以在组件装载前审查。这是「声明式」相对「运行时反射」被低估的一个收益。

可以直接去读的东西

论文第 3.4.2 节关于「可交换性」的讨论，是全文最可迁移到日常接口设计的部分，配合 §6.6 一起读。
Cordis 源码只有 9 个模块（context / registry / fiber / events / service / reflect / logger / utils / index），fiber.ts 是核心 —— 生命周期状态机加 effect 系统都在里面。
论文的 Table 2（理论↔实现对照表）值得单独保存，它是一张「读源码时该看哪里」的地图。

9. 风险与观望点

点	说明
论文没有性能数据	全文没有 benchmark。效应追踪和依赖解析的运行时开销是多少，只能自己压测
单一生态验证	所有实证来自 Koishi + TypeScript，范式本身和其他语言实现的优劣还没有横向对比
「无环」需要自己保证	它不是被证明的，是假设。你的组件设计得自己盯着别写出环
版本语义还缺一块	这是论文明确列为「开放问题」的部分。生态越大，接口漂移和 key 碰撞的代价越明显

10. 延伸阅读

论文原文：arxiv.org/abs/2608.25512（92 页，但 §3 和 §4 的定理陈述部分读下来就够了）
Cordis 源码：github.com/cordiverse/cordis（MIT）
DeepSeek Harness 里 vendor 的版本：vendor/cordis，发布为 @deepseek-ai/cordis
官方插件入门：docs/cordis-primer.zh.md
前文：《DeepSeek Harness 精读：一个「一切皆插件」的 Agent 运行时》

**一句话总结：**它把 effect 和 coeffect 从编译期的类型注解，变成运行时可操作的一等对象，让「运行时装卸组件」第一次有了完整的理论保证 —— 而这一切，已经被一个 4000+ 插件的生产系统验证了四年。

DeepSeek Harness 精读：一个「一切皆插件」的 Agent 运行时

Wed, 26 Aug 2026 18:25:59 +0800

精读对象：github.com/deepseek-ai/deepseek-harness（dsh），2026-08-26 克隆自 master 分支
版本：0.1.x 开发者预览（rc 阶段）· MIT 许可
精读重点：轨迹日志（事件溯源） 与 插件系统（Cordis / seam） 两套核心设计

0. 一句话速览

dsh 不是又一个 AI 编程工具，而是一个”Agent 外壳”的插件平台。 它的核心命题是：Agent = 模型 + Harness——模型只负责推理，Harness 负责把模型接进文件、命令、工具、会话、权限与界面。而它赌的架构是：Harness 本身没有特权内核，一切能力都是可插拔的插件，包括模型适配器、工具、沙箱、会话日志，甚至 Agent 循环本身。

两套最值得读的设计：

设计	一句话概括	杀手锏
轨迹日志	会话 = 一条仅追加的事件日志，是唯一真源	“模型可见即已记录”——模型看到的一切都能从日志重建
插件系统	Cordis 微内核只管装配，能力按 seam（缝）三件套组织	换掉一个提供方就能改变整个产品，不用改源码

1. 轨迹日志：事件溯源式会话（精读重点 #1）

1.1 设计哲学：模型可见即已记录

这是 dsh 的第一条铁律，由运行时不变量强制断言：

抵达模型请求的一切都必须能从日志重建。 新增任何一项模型可见输入，就必须新增一个会话事件类型。

也就是说：日志不是”聊天记录的副本”，而是唯一真源。LLM 的消息历史是从日志派生出来的（deriveMessages()），从不单独存储。回放 = 用同一组事件重新派生一遍。

派生的好处：历史永远不会和日志不一致——不存在”存了一份消息数组、又改了日志”的双写问题。所有下游消费方（UI 转录、遥测、会话标题、搜索索引）都从同一份事件流派生，各取所需。

1.2 事件词汇表：日志里有什么

SessionEventMap 定义了事件类型，插件可以通过 TypeScript 声明合并扩展（见 §2.4）。核心事件如下：

事件	作用	说明
`turn/start` / `turn/end`	轮次边界	轮次 = 一次排空已接纳输入的过程；`turn/end` 带结束原因
`step/start` / `step/end`	步骤边界	步骤 = 一次模型请求 + 它触发的工具执行
`user/message`	用户输入	普通提示词、注入上下文（`agent.inject()`）、目标续行共用一个类型，靠 `source` 区分
`assistant/chunk`	原始流分片	token 级回放保真——UI 能逐字重现输出过程
`assistant/message`	组装后的模型回复	携带 `usage`（token 记账随消息走）；中断的回复标记 `interrupted`
`tool/call`	工具调用	保留模型产出的原始 JSON 参数（未解析），`callId` 与结果配对
`tool/result`	工具结果	可选携带 `error` 和工具私有 `meta`（如文件 diff 卡片）
`todo/write`	待办全量快照	整表替换、last-write-wins，故意不做成带 id 的条目
`request/header`	请求完整信封	调用配置 + 系统提示词 + 工具 schema 全量快照，每次变化记一份
`request/context`	路由元数据	提供方/模型/上下文窗口，容量变化时记录
`session/end-seed`	种子边界	标记”哪些事件是恢复/fork 继承的、哪些是本进程新写的”

几个细节非常见功力：

seq 必须连续（seq = log.length），因此不能从规范日志里过滤分片——连 assistant/chunk 都必须无损保存。
所有 data 必须是可无损 JSON 序列化的。Session.append() 在写入前做一次递归校验（BigInt、函数、循环引用、Map/Set 一律拒绝），坏事件在源头就失败，绝不让错误进入日志。这对”日志即真源”是底线保障。
热路径不阻塞 I/O：追加是同步进内存，持久化插件异步批量落盘。

1.3 Surface 机制：如何从日志”长”出模型历史

不是所有事件都投影成消息。只有 3 种”产生消息”的事件（user/message、assistant/message、tool/result）携带 surfaceOp，声明自己如何加入有序的派生 surface：

append：普通尾部追加。
replace：遮蔽从 start 到 end 的一段旧节点，在原位插入新事件。

replace 是压缩（compaction） 的落点：上下文太长时，压缩插件把一段旧历史折叠成一条摘要，用 replace 遮蔽旧节点——日志本身一个字不删，只是”模型视野”里那一段被摘要替代了。这就是”日志永远可审计、只被遮蔽、不被删除”。

每个 surface 事件还携带 sourceEventSeqs（引用了哪些早期事件），比如 assistant/message 会引用构成它的 assistant/chunk 序号。压缩时被遮蔽的节点也必须在 sourceEventSeqs 里列全——血缘可追溯。

1.4 持久化与崩溃恢复

持久化本身是一个 seam（见 §2.3）：ctx.sessions 只做内存事件存储，持久化由插件订阅 session/event 完成。

flush 检查点：session/flush 是显式耐久屏障；日常写入走异步批量缓冲（固定时间窗，窗口内事件不重置截止时间）。
两个可互换后端：JSONL（逐会话追加日志，默认 Zstandard 压缩 + checksum，原子写入）和 SQLite（schema 17，同一分片块内字段完全匹配的 delta 段做有界物理存储）。
崩溃恢复的优雅之处：重新加载时发现一个”开了 turn/start 却没有 turn/end“的轮次，不截断日志（长任务里一个轮次可能很大，删了就是丢数据），而是合成一个 turn/end { kind: 'interrupted' } 把它配平——这是唯一一个不由循环发出的结束原因。
格式拒绝：遇到版本更新的日志、或未知的必需事件类型（没有 ignorable 标记），后端拒绝加载而不是静默跳过——因为”跳过一条可能改变整体解读的事件”比”拒绝”危险得多。新格式明确提示”由更新的 harness 写入，请升级”。
fork / resume：可以从任意稳定轮次间位置 fork；恢复时元数据里存了 agentPreset——因为 preset 决定工具和提示词，恢复成不同的组合等于让模型回放一段它无法再行动的历史。

1.5 为什么说这是杀手锏

对跑 Agent 的人来说，最贵的成本是”它到底为什么搞砸了“。dsh 的答案：日志里什么都有，且保证能重建。调试一个跑了 50 步的 Agent 任务，可以回放、定位到出错的那一步、看当时模型看到的完整上下文、连原始流分片都在。这同时是审计、基准测试（同一任务换模型对比）、以及多 Agent 协作排障的基础设施。

2. 插件系统：Cordis 微内核 + 能力 seam（精读重点 #2）

2.1 五个核心概念（Cordis 入门）

概念	含义
插件	实现 Service 的对象（函数 + `apply(ctx)` 或 Service 子类），生命周期由 Cordis 管理
上下文	服务的容器。服务占据稳定的 `ctx.<key>`（如 `ctx.llm`、`ctx.tools`），其他插件按 key 查找服务，绝不 import 具体实现
inject 声明依赖	插件声明所需服务后，会等待服务就绪才启动——加载顺序由依赖表达，而非手动编排
类型化事件	服务通过声明合并注册事件名，以 4 种模式分发（见下）
注册是可逆副作用	所有注册（提示词片段、工具 schema、监听器）都是副作用，插件卸载时自动撤销

2.2 事件分发模式：一鱼四吃

模式	语义	典型用途
`emit`	监听器按注册顺序观察，不等待、无返回值	广播事实（如 `session/event`）
`waterfall`	环绕中间件：监听器收到 `(...args, next)`，可包装、改写，不调 next 直接返回 = 短路	拦截/决策（如 `agent/pre-step`、`tools/pre-execute`）
`parallel`	所有监听器并行，await 全部	耐久检查点（如 `session/flush`）
`serial`	按序执行、有返回值	顺序决策（如 `agent/turn-stopping`）

waterfall 是最聪明的：策略监听器拥有决策权时可以短路（比如”这条工具调用禁止执行”），而只做观察的监听器必须调 next() 委托下去。拦截、审批、限流、改写提示词全部可以用事件挂上去，不碰核心。

2.3 能力 seam：可替换能力的”三件套”

一个 seam 包含三种角色：

Service Definition：声明接口，拥有自己的 ctx.<key>（如 ShellExecutor 抽象类）
Service Provider：实现该接口（可以有多个，可互换）
Consumer：消费该服务的插件（通常是面向模型的工具）

规范范例——shell 能力：

ctx.shell（Service Definition）
├── dsh-bash-local （Provider：本地 bash）
├── dsh-bash-sandbox （Provider：沙箱 bash）
├── dsh-pwsh-local （Provider：本地 PowerShell）
└── dsh-tool-bash （Consumer：面向模型的 bash 工具）

替换一个提供方就能改变整个产品：把 bash-local 换成 bash-sandbox，所有消费 ctx.shell 的消费方（bash 工具、钩子桥接）自动获得沙箱保护，消费方零改动。文件系统、子进程、沙箱、搜索、凭据、存储、技能……整个平台都是按这个模式组织的。

seam 生态（部分代表性服务）：

ctx 键	类型	可换提供方	说明
`ctx.llm`	seam	deepseek / pi-ai / replay	模型适配器注册表，agent loop 提供方无关地调流式服务
`ctx.sessionPersistence`	seam	jsonl / sqlite	会话持久化，应用组合时选后端
`ctx.shell`	seam	bash-local / bash-sandbox / pwsh-local	Bash 执行器
`ctx.fs`	seam	fs-local / fs-sandbox / fs-e2b	文件系统
`ctx.subagents`	seam	6 个提供方	从进程内 fork，到委派给 Claude Code / Codex 进程
`ctx.web`	seam	exa / perplexity / deepseek / http-fetch	搜索与抓取
`ctx.skills`	seam	badge / filesystem	技能注册表——`tool-skill` 渲染会话前缀目录并加载 skill 正文
`ctx.approval`	seam	acp	一次性权限决策
`ctx.credentials`	seam	credentials-local	凭据
`ctx.storage`	seam	json / sqlite	非会话存储
`ctx.sessions`	core	—	仅追加事件日志（真源）
`ctx.tools`	core	—	工具注册表 + 带把关的执行流水线
`ctx.agents` / `ctx.agentLoop`	core	—	Agent 注册表 + 唯一具体循环驱动
`ctx.invariants`	core	—	配套不变量注册表（运行时自检）

2.4 无特权内核的两个关键机制

① Map → derived-union 扩展模式。 几乎所有可扩展的联合类型都遵循同一模式：接口以判别标签为 key（ThingMap），联合类型由 keyof 派生。插件通过 TypeScript 声明合并添加变体——不需要修改拥有该类型的包：

declare module '@deepseek-ai/dsh-llm' {
 interface ContentBlockMap {
 'c': { kind: 'c'; /* … */ }
 }
}

六个规范 map（含 SessionEventMap、TurnEndReasonMap）都这么干。代价是约定：对这类联合类型做 switch 时禁止 assertNever——插件添加的变体是合法的未知值，default 分支必须放行。

② 注册即副作用，卸载即撤销。 扩展 dsh 的方式就是”把插件挂载到其他插件旁边”，不存在需要打补丁的特权内核。每个注册要么从 ctx.effect() 返回一个 disposer，要么用 Cordis 辅助方法自动处理——reload 和 teardown 时按预期撤销。连 Agent 循环本身都是可换的。

2.5 装配：profile 与组合包

运行中的 dsh 是一棵插件树，由启动时按序叠加的各层组成：

profile（web / headless）：具名组装，列出叠放的组合包，保存用户的 cordis.patch.yml。
组合包（bundle）：配置项 + 挂载代码的分发格式；dsh-base 是第一层（模型/工具/持久化/沙箱/审批/设置/凭据/遥测），dsh-web-app 加浏览器应用。
patch 覆盖：任何条目都可以被上层 patch 替换——dsh --profile web --dump-config 打印真实配置树，打印出的任何条目都能被你的 patch 替换。

这就是”配置层可换任意能力”的落点：换模型端点、换执行工作流、换 UI，都不碰源码，只改 YAML。

3. Agent 循环：轮次 / 步骤 / scope / inbox

一个轮次按同一条循环流经 6 个核心包：

认领输入 → 开轮次(turn/start) → 组装提示词+工具schema → 从日志派生历史
→ 模型流式请求(llm/stream) → 工具执行(tools/*) → 每个模型可见事实追加回日志 → 关轮次

值得抄的设计点：

scope（作用域）：按 agent 划分注册单位，只有”全局”和”恰好属于一个 agent”两层。shadowing 机制——带作用域的工具/提示词片段在该 scope 内替换同名全局项，这是”按 agent 定制 persona 和工具集”的机制。过滤掉的工具既不出现在提示词里、也拒绝执行，与不存在的工具无法区分（安全特性）。
inbox（收件箱）：agent 拥有两条有序待处理列表——next-turn（普通续问）和 next-step（steering 中途引导）；inject() 注入上下文不唤醒驱动，留到下一个步骤边界。
拦截决策：agent/pre-step 是请求派生前唯一的串行监听器链，可改写甚至拒绝进入步骤的消息（拒绝仍会记录一个空轮次——日志记录这次尝试本身）；agent/request-error 监听器可以返回 { kind: 'retry' } 拥有失败恢复。
取消：cancel(cause) 带类型化原因（user / parent / hook / disposed），持久日志保留粗粒度 aborted，谁请求的取消不塞进终态结果（那是另一类持久事件的职责）。

4. 与 WorkBuddy 对照：同行不同路

能力	dsh 的答案	WorkBuddy 的答案
扩展机制	Cordis 插件树，配置层可换任意能力	Skill 技能 + Expert 专家 + Connector 连接器（MCP）
会话记忆	事件溯源日志，模型可见即已记录，可回放	三层记忆（云端画像 / 用户级 / 工作区日志）+ 会话历史检索
子 Agent	`ctx.subagents` 6 个提供方（进程内 / Claude Code / Codex）	子 Agent + Team 多智能体协作
技能系统	`ctx.skills` + tool-skill 从文件系统加载技能目录	`~/.workbuddy/skills/` 技能目录（同构！）
权限	`ctx.approval` + permission-presets 预设表	权限系统 + 沙箱
斜杠命令	`ctx.commands`（不经过模型轮次）	/ 命令体系
后台任务	`ctx.jobs`	后台任务 / 自动化
计划模式	`ctx.planMode`	Plan 模式
沙箱	`ctx.sandbox` / `ctx.fs` / `ctx.shell` 三 seam	Bash 沙箱
形态	开源 MIT，`npx @deepseek-ai/dsh web` 一行起	商业产品，桌面 IDE 开箱即用

最有趣的发现：dsh 的 ctx.skills 与 WorkBuddy 的 skill 目录是同一种东西——都是”技能提供方注册表 + 从文件系统加载技能正文 + 渲染进会话前缀”。你在 WorkBuddy 里积累 skill 的路线，被 dsh 印证为行业共识。

而 WorkBuddy 目前没有的是 dsh 的”事件溯源级完整轨迹”：WorkBuddy 有记忆沉淀，但不是”每次工具调用、每个原始 chunk 都可回放”的完整日志。

5. 可借鉴清单（结合你的项目）

5.1 认知层：直接吸收

轨迹复盘习惯：给 teammate 的每个投资决策、每篇博客内容生产，养成”过程可留痕”的习惯——关键节点（判断、工具结果、中途修改）记成结构化条目，事后可回放、可归因。WorkBuddy 的会话记忆 + 工作区日志已经是雏形，把它用得更狠。
“模型可见即已记录”是调试的底线：多 agent 协作（teammate 6 个 agent）出问题，最贵的是”不知道哪一步错了”。任何 AI 交互系统，先保证输入输出有完整留痕，再谈别的。
场景化运行模式：dsh 有 Standard / Code / Minimal / Creator 四模式，WorkBuddy 有 Craft / Plan / Ask——”按任务类型切换运行形态”已是行业共识，你现在的用法是对的。

5.2 架构层：可落到自己的代码

事件溯源代替”直接存消息数组”：如果你给《族谱》小程序或投资系统做 AI 会话持久化，参考 dsh 的模式——只追加事件日志（user / assistant_chunk / assistant / tool_call / tool_result / header），历史由投影派生。收益：永不双写、可回放、可 fork、压缩只遮蔽不删除。
seam 三件套组织扩展：定义接口 / 提供方实现 / 消费方分离，消费方只依赖接口。teammate 的 6 个 agent 如果共享接口定义，换模型、换数据源都不动其他 agent。这是 dsh 全文最值得抄的组织模式。
崩溃恢复”不截断、合成结束标记”：长任务中断后恢复，别删尾部，合成一个 interrupted 结束标记配平——数据永远不丢。
坏数据在源头拒绝：写日志前做序列化校验（拒绝不可 JSON 序列化的 payload），宁可在写入时报错，也不让坏事件进入真源。
waterfall 事件做策略：需要做”拦截/审批/改写”的地方，用”可短路的环绕中间件”而不是硬编码 if-else——策略与主流程解耦，还能按需叠加。

5.3 生态层：可抄的现成组件

dsh 的技能、子 agent 多后端、session-query（会话全文搜索）、compaction（上下文压缩）都是独立包，概念可以直接移植到你自己的架构里，不用抄代码。

6. 风险与观望点

风险	说明
0.1.x 开发者预览	8/13 发布，API 与磁盘格式都在快速演进，`SESSION_FORMAT_VERSION` 明确不做迁移——旧日志可能打不开
Star 数有水分	一周 17 万 star 明显含大量”先收藏再说”，真实工程采纳率未验证
生态起步期	`dsh-plugin` npm 话题刚形成，成熟插件少；Cordis 是 vendor 进来的第三方内核，上游风险要看 cordiverse/cordis 的维护
定位窄	它只是 harness（外壳），不提供模型、不做训练、不做 RAG 中间件——别指望开箱即用的”完整 Agent 应用”
对普通用户不友好	是给开发者/平台构建者的积木，日常用户仍应待在 WorkBuddy 这类成品里

结论： 值得读源码和文档（尤其是 docs/subsystems/ 和 docs/cookbook/），作为”下一代 Agent 平台”的免费教材；但别急着上生产，等它到 1.0 或生态稳定再考虑作为自建底座。

7. 延伸阅读

架构总览：docs/architecture.zh.md（含轮次流程图）
轨迹日志：docs/subsystems/session.zh.md → docs/subsystems/persistence.zh.md
插件系统：docs/cordis-primer.zh.md → docs/capability-seams.zh.md → docs/event-producer-consumer.zh.md
Agent 循环：docs/subsystems/core.zh.md
术语表：docs/glossary.zh.md（seam / scope / turn / step 的规范定义）
扩展实操：docs/cookbook/extension-cookbook.zh.md（加工具 / 加 LLM 适配器 / 加 Chat 节点分步指南）
本地源码：本仓库已克隆至 dsh-src/（packages/core/session 是轨迹日志实现，packages/shell 是 seam 规范范例）

从一条提醒开始：一个会自我进化的投资跟踪系统

Wed, 19 Aug 2026 10:50:02 +0800

一、起点：一个被遗忘成本困扰的场景

故事的起点很具体。我经常看到一些宏观分析或个股研判——逻辑严密、数据翔实，当下深以为然，甚至据此做了操作。但这类判断的验证周期往往是三个月、半年。等到该复盘的那天，问题不是”忘了看”，而是忘了当初为什么信它。

第一版的解法很直觉：做个微信小程序，把观点、计划、复盘日期记下来，到期提醒。一天就写完了，深色金融风，本地存储，能跑。

但它很快暴露了一个根本性的错误假设。

二、转折：时间不是触发器，条件才是

那天我把一份 AI 生成的《海螺水泥圆桌报告》丢进这个还很稚嫩的系统。报告写的是典型的左侧潜伏逻辑：0.48 倍 PB 的破净现金奶牛，拐点前奏已现，但确认键是”放量站回 BOLL 中轨 17.89″，作废键是”跌破 52 周低点 16.17″。

我对着自己的”三个月后提醒复盘”愣住了：17.89 可能第 20 天就站上，16.17 可能第 45 天就跌破——等到复盘日再看，机会和风险都已成历史。投资场景的提醒，本质不是日历事件，而是条件事件。

这次认知升级凝成了一句话，后来写进了 README 的开头：时间是兜底，条件才是触发器；观察是节奏，复盘是闭环。

系统随之重构。每个跟踪项从”一段文字+一个日期”变成了一组可判定的条件：确认条件（全部达成=观点被验证）、作废条件（任一触发=逻辑被证伪）、最终期限（什么都没发生时的兜底）。状态机从”跟踪中→到期→复盘”变成了真正的决策流。

三、抽象：给”盯盘语言”立法

接下来的问题是：条件要如何被机器执行？

“站回 17.89″好办，拉个行情接口比较一下就行。但报告里还有”KDJ 极端超卖”、”主力 10/20 日流向转正”、”北向持仓变化”——有些是指标，有些是资金数据，有些根本没有公开接口。

我做了一个关键的产品决策：不追求全自动的乌托邦，而是给条件建立类型系统。能量化的收敛为七种自动类型——价格、涨跌幅、量比、RSI、KDJ、BOLL、MACD，每种有明确的参数和求值器；不能量化的诚实标记为文字条件，在每周打卡时人工核对。技术实现上，RSI、MACD 这些指标并不需要买数据服务，日 K 线拉下来本地几十行代码就能算。

手动不是缺陷，是设计：打卡表单本身就是核对清单，”资金流向转正了吗？回购还在延续吗？”——系统把”该看什么”结构化地递到你面前。

四、AI 进场：从”我用 AI”到”AI 用文档”

功能越强，录入越重。一份报告要手工拆出七八条条件，这本身就是劝退流程。解法顺理成章：AI 写的报告，让 AI 来拆——拖入报告文件，DeepSeek 直接提取出观点、计划、条件组、关键时间点，预览确认即建项。

但真正有意思的决定藏在实现细节里：条件的类型映射规则没有硬编码在 prompt 里，而是写成了一份独立的手册 rules.md，运行时整体注入给模型。改文档即改 AI 行为——调整规则不需要动代码，写文档就是在编程。

五、闭环：让 AI 告诉我们它缺什么

到这里系统已经能用了，但最有意思的设计出现在下一步。

我意识到一个不对称：报告里的信号千奇百怪，而我的类型系统只有七种。与其等我发现新类型，不如让 AI 自己报告它的能力边界。于是 prompt 里加了一条约定：遇到手册无法表达但理论上可量化的信号，照常降级为文字条件，同时在返回结果里附上”新类型建议”——名字、判定逻辑、报告原文依据。

第二天，系统就给我提了两条需求：”南向资金连续净流入”、”COMEX 商品价格阈值”。我验证数据源、实现求值器、把手册更新。又过了几天，它再提两条：”美元指数阈值”、”港股卖空比例”。再次落地。

闭环就此形成：AI 读报告 → 发现能力缺口 → 提出建议 → 人类实现并更新手册 → AI 下次自动识别。规则手册、AI 提取、求值引擎三者咬合，系统开始自我进化。触发价格、KDJ、美元指数、南向持股、沽空比例——十余种参数指标联动的数据抓取，都是在这条流水线上长出来的。

六、工程现实：那些不在计划内的课

故事里不该只有架构图。一些真实的坑，恰恰是最有信息量的部分：

输入框曾”无法输入”——受控组件每次按键都重渲染，打断了中文输入法的组词；Electron 二进制被 macOS Gatekeeper 当成”恶意软件”——最后靠 postinstall 脚本自动清隔离属性加本地签名解决；南向资金数据同一天有上海、深圳两条通道记录，不合并就会得出荒唐的”净流入”结论；外盘期货的字段是逗号分隔而股票是波浪号——这些在真实数据验证之前，都安静地伪装成”已完成”。

也正是这些坑催生了最后的工程拼图：所有数据源收拢进统一的适配层，每个源带自检，npm run check:sources 一键巡检全部接口，指标算法用合成数据做离线单测。从此接口挂了，是测试先知道，不是我先亏知道。

七、现在它长什么样

一个小程序已经长成了常驻 Mac 菜单栏的桌面应用。托盘图标带着待办角标；后台每 30 分钟扫一遍行情，条件命中就弹系统通知，点开直达详情；每周打卡把”该核对什么”递到手上；复盘页自动摆出当时的观点、条件触发的完整时间线、过程打卡记录，等你写下结论。

而最重要的资产不是代码，是那份 rules.md——一部系统与自己对话用的词典。它还会变厚，因为下一次 AI 再提出新建议时，流水线的每一环都已经就位。

尾声：三点带走的认知

先找到真正的触发器。 最初的时间提醒不是做错了一步，而是认错了问题的本质。值得警惕的永远是”直觉解”。

诚实地区分能与不能。 把可自动化的做到极致，把不能自动化的设计成优雅的人工流程——”全自动”的执念反而产生脆弱系统。

把 AI 放进回路，而不只是放进流程。 用 AI 提取信息是提效；让 AI 参与定义自己的能力边界、让文档成为人机共享的事实源，才是这套系统会进化的原因。

—— 深度跟踪提醒 DeepReminder，从一个提醒需求到一个自进化条件的跟踪复盘系统。

47 页 Kimi K3 技术报告，讲给普通开发者听：2.8T 开源巨兽的“偷懒”艺术

Tue, 28 Jul 2026 10:54:34 +0800

**30 秒版本：**Kimi K3 是 Moonshot 最新开源的旗舰模型——2.8 万亿参数的 MoE，每个 token 只激活 1040 亿（约 1/27），原生视觉，100 万 token 上下文。定位一句话：能力咬住闭源前两名（Claude Fable 5、GPT-5.6 Sol），稳坐开源第一，成本却只有对手的几分之一。本文把 47 页技术报告拆成三个灵魂问题：

2.8T 的大家伙，怎么训得起、推得动？ → 架构”三板斧”
100 万 token 上下文，怎么不让显存爆炸？ → 换一种”记忆方式”
base 模型怎么练成能干活的 agent？ → RL + 九专家蒸馏

先看全景：架构就三句话

MoonViT-V2 0.4B 视觉编码器

Embedding 共享嵌入空间

Block ×8：93 层切成 8 块 token 混合：3 KDA : 1 MLA

KDA

MLA

MoE

MoE 每层 attention 后都跟一个 LatentMoE 896 选 16 · 压到 3584 维 latent 空间

AttnRes：深度方向的”查档”机制每层带 query 检索 embedding + 所有前序 Block 的输出

输出循环 ×8

三句话概括整个架构：token 维度靠 3 层 KDA + 1 层 MLA 混搭，深度维度靠 AttnRes 跨层查档，宽度维度靠 LatentMoE 稀疏调用专家。先感受一下 K2 → K3 的体格变化：

	Kimi K2	Kimi K3	变化
总参数 / 激活参数	1.04T / 32.6B	2.78T / 104.2B	×2.7 / ×3.2
层数	61	93	+52%
专家数（每 token 激活）	384（8）	896（16）	稀疏度 56
训练上下文	128K	1M	×8
注意力	全 MLA	69 KDA + 24 MLA	混合架构
综合 Scaling 效率	基准	2.5×	同等 loss 省 60% 算力

第一板斧：KDA —— 把”无限增长的会议记录”换成”固定大小的笔记本”

传统 attention 的痛点：每来一个 token，都要和之前所有 token 重新算一遍关系，KV cache 无限变长——像开一场永不散会的会，每页发言记录都要永久存档。KDA（Kimi Delta Attention）是线性注意力的一种：不管序列多长，只维护一个固定大小的笔记本 S，成本 O(n)、缓存恒定。

全量注意力（如 MLA）每来 1 个 token，记录 +1 页 KV cache

成本 O(n²) · 缓存无限涨

KDA（线性注意力）每来 1 个 token，只更新笔记本 S

① 褪色 α：旧笔记按通道变淡 ② 擦除：先精准擦掉旧值 ③ 写入 β：新内容按强度落笔成本 O(n) · 缓存固定

K3 的折中：3 层 KDA + 1 层 MLA 75% 的层记笔记本（便宜），25% 开全员大会（保全局）

笔记本每来一个 token 做三个动作：褪色（forget gate α 让每个通道的旧笔记按各自速度变淡）、擦除（delta rule——写入前先把旧值精准擦掉，这是它和普通线性注意力的关键区别，防止内容越叠越糊）、写入（新内容按强度 β 落笔）。

报告里我最喜欢的一个工程细节：数学上”1/累计衰减”会指数级膨胀，BF16 装不下就溢出。K3 的解法是给褪色速度设个下限（用 sigmoid 把 log-decay 压进 (-5, 0)），16 个 token 的累计衰减倒数最大 e⁸⁰，刚好卡在 BF16 动态范围内——一个数值稳定性的小改动，让整条计算路径都能跑满 Tensor Core，直接消灭了最慢的 kernel 分支。

两个配套设计也值得记住：

3:1 混搭：光靠笔记本会丢全局细节，所以每 4 层插 1 层 Gated MLA 全量注意力”开全员大会”
NoPE（无位置编码）：不显式存”第几个位置”，靠笔记本的衰减自然感知远近。上下文从 8K 一路扩到 1M 完全不用改位置编码

第二板斧：AttnRes —— 把 attention 的思想搬到”深度”方向

普通残差连接像传话游戏：第 93 层只能拿到第 92 层传过来的话，前面 91 层的细节全被压扁在一个向量里。AttnRes 的思路很直接：每层带一个可学习的”查询词”，主动去检索 embedding 和所有前序 Block 的输出，想要谁的信息就拿谁的。93 层切成 8 个 Block，块内先求和压缩、块间再做检索，开销可忽略，实验上 N=8 就能拿回大部分收益。

第三板斧：LatentMoE —— 896 个专家的分诊艺术

token 7168 维

W↓ 压缩 7168→3584

Router 分诊台 QB 负载均衡偏置 b 只调分诊、不改权重

896 个 routed 专家每个 token 只激活其中 16 个

专家在 3584 维 latent 空间工作通信、显存都按”简报”大小算

汇总 → RMSNorm → W↑ 投影回 7168 维，与 shared 相加

2 个 shared 专家（全科）全宽度直接处理每个 token 896 选 16 = 稀疏度 56：只花 1/56 的算力，享受 56 倍的专家容量

MoE 的核心矛盾：专家越多知识容量越大，但每个被选中的专家都要收一份 7168 维的完整 token 表示，通信和显存跟着爆炸。K3 的三连解法：

先压缩再送诊：token 先被 W↓ 压成 3584 维”简报”，专家们在简报空间里干活。于是专家数翻倍（384→896）、激活数翻倍（8→16），通信量却没涨
SiTU-GLU 激活函数：SwiGLU 的两个相乘因子都无界，2.8T 尺度下会数值爆炸。SiTU-GLU 给两个分支都装上 tanh”限高杆”（输出硬上限 100），原点附近和 SwiGLU 一阶等价——形状不变，永远不失控
QB 分位数均衡：传统 MoE 靠辅助损失逼负载均衡（伤性能），K3 改成给每个专家加一个”排班偏置 b”——b 只影响谁被选中、不进梯度、不改权重。每步训练后按分位数调：太火的专家降分、冷门的加分，直到每个专家接待量精确达标。工程上用直方图估分位数，一次 all-reduce 只传几百个 bin，几乎免费

后训练：先分头练出 9 个专家，再蒸馏回一个模型

① SFT 冷启动打基础 agent 能力 XTML 统一模板全程量化感知

② RL 练专项专家 3 领域 × 3 思考档 = 9 个专家模型超预算奖励 -1

③ MOPD 蒸馏 9 个老师教 1 个学生逐 token 打分合成统一模型

④ 一个 K3 low/high/max 三档 MXFP4 低精度部署草稿模型加速解码

reasoning effort = 给模型发”思考预算” 先训 max 档（预算宽），再退火出 high / low 档 —— 让模型学会该想想、该省省

后训练里几个有意思的细节：

思考预算控制：每题先发预算 b₀(x)，输出超 τ·b₀ 直接奖励 -1。先训 max 档，再退火出 high/low 档——模型自己学会”简单题别过度思考”
防话痨：GRM 打分时回答长度超 σ·ℓ₀ 直接判负，专治 reward hacking 的啰嗦倾向
训练任务够野：知识图谱自动扩展出题、mock 版 Gmail/Notion/Slack 练”连续工作好几天”的助理任务、GPU kernel 优化（奖励=正确性+逼近 roofline 程度，还配反作弊系统）、黑盒系统复刻等

基建：2.8T 不是堆卡就行的

工程难题	K3 的解法
KDA 递归本质是串行，GPU 不喜欢	FlashKDA kernel：chunk 内并行、chunk 间流水重叠
1M 上下文并行训练	KCP：把每段的状态转移分解成可本地计算的两部分，一次 all-gather 搞定——线性 attention 的通信量与序列长度无关
专家并行负载不均、显存碎片	MoonEP：每个 rank 精确收 S×K 个 token，冗余专家 ≤ E/R（有数学证明），shape 全静态免同步
1M agentic RL 的 KV cache 存不下	外部 KV 池：GPU 逐出的前缀写回 CPU DRAM，KDA state 与 MLA KV 生命周期对齐
agent 把容器沙箱搞到内核 panic	AgentENV：Firecracker microVM，支持暂停/分叉/快照（checkpoint 133ms）；整个训练共创建 5122 万个沙箱、150 万个镜像
1M token 长请求挤死 2K 短请求	预算制准入控制：长短请求各有独立资源池，互不饿死

成绩单（报告官方数据，截至 2026-07-23）

维度	表现
编程	SWE-Marathon 第一（42.0%，领先 Fable 5 七分）；Terminal-Bench 88.3% 几乎平 GPT-5.6 Sol；WebDev Arena 总榜第一（1678 Elo，首个登顶的开源模型）
Agent	BrowseComp 91.2% 全场第一；MCPMark 94.5% 第一；GDPval-AA 第三（前二为 Fable 5、GPT-5.6 Sol）
知识推理	GPQA 93.5%；但 HLE、CritPt 等研究级任务仍落后前两名——报告自己承认这是短板
视觉	OmniDocBench 91.1% 第一；ZeroBench 平 Fable 5
成本	BrowseComp 每题 $2.03，是 GPT-5.6 Sol 的一半、Claude 系的约 1/10；KCB 2.0 用 Fable 5 约 38% 的成本拿到只差 4 分的成绩

Case study 里最夸张的三个：24 小时内把 4 个 GPU kernel 优化到匹配 Fable 5 的水平；独立写出一个能端到端训 GPT 的 Triton 类编译器 MiniTriton（matmul 达 cuBLAS 约 90%）；48 小时用开源 EDA 链设计了颗 INT4 推理芯片（RTL 仿真 8700 tokens/s）。

普通开发者能带走什么

“混合”打败”纯粹”：75% 便宜层 + 25% 贵层 ≈ 全贵层。缓存/数据库/索引的分层设计是同一个道理
数值稳定性就是性能：一个 sigmoid 下限换来整条 kernel 路径上 Tensor Core，边界条件别小看
负载均衡可以”调偏置”而不是”加惩罚”：不改目标函数、只调准入门槛——任何调度系统都好使
agent 能力 ≈ 环境复杂度：K3 的 agent 能力是 5122 万个沙箱喂出来的。你的 agent 产品能练多狠，取决于你能造多真的演练场
成本拐点：开源权重的 K3 把前沿 agent 能力打到闭源旗舰 1/3~1/10 的价格，自部署的经济账越来越好算了

一句话总结：K3 没有发明新科学，但它把线性注意力、MoE、RL、系统工程四条线的工程组合做到了开源世界的天花板——然后用 2.5× 的训练效率和 1/10 的推理成本告诉你：前沿智能的入场券正在变便宜。

本文为 Moonshot《Kimi K3: Open Frontier Intelligence》技术报告（2026 年 7 月，47 页）的个人解读，数据均引自报告原文，跑分以官方口径为准。

🐙 GitHub Trending Top 10 | 本周最热项目

Wed, 08 Jul 2026 10:01:15 +0800

数据更新时间： 2026年7月8日（本周）

🥇 1️⃣ usestrix/strix 🔒

链接： https://github.com/usestrix/strix

指标	数据
⭐ 总 Star	38,600
📈 本周增长	10,741
🍴 Forks	3,922
💻 语言	Python

简介： 开源 AI 渗透测试工具，帮助发现和修复应用安全漏洞。将 AI 能力引入安全测试流程，自动化识别潜在风险点。

🥈 2️⃣ JuliusBrussee/caveman 🪨

链接： https://github.com/JuliusBrussee/caveman

指标	数据
⭐ 总 Star	86,291
📈 本周增长	8,066
🍴 Forks	4,810
💻 语言	JavaScript

简介： Claude Code 技能包——用”原始人说话”方式压缩 65% 的 token 用量。简单粗暴但极其有效，已成为 AI 编程工具的必备优化。

🥉 3️⃣ Zackriya-Solutions/meetily 🎙️

链接： https://github.com/Zackriya-Solutions/meetily

指标	数据
⭐ 总 Star	20,801
📈 本周增长	7,349
🍴 Forks	2,080
💻 语言	Rust

简介： 隐私优先的 AI 会议助手，基于 Parakeet/Whisper 实现 4 倍速实时转录、说话人分离和 Ollama 摘要。100% 本地处理，无需云端，支持 macOS 和 Windows。

4️⃣ MadsLorentzen/ai-job-search 💼

链接： https://github.com/MadsLorentzen/ai-job-search

指标	数据
⭐ 总 Star	11,121
📈 本周增长	5,363
🍴 Forks	3,710
💻 语言	TypeScript

简介： 基于 Claude Code 的 AI 求职框架。填入个人资料后，AI 自动评估职位、定制简历、撰写求职信并准备面试。

5️⃣ asgeirtj/system_prompts_leaks 🕵️

链接： https://github.com/asgeirtj/system_prompts_leaks

指标	数据
⭐ 总 Star	53,062
📈 本周增长	5,337
🍴 Forks	8,646
💻 语言	JavaScript

简介： 收集各大 AI 产品的系统提示词泄露内容，涵盖 Anthropic Claude、OpenAI GPT、Google Gemini、xAI Grok 等主流模型及开发工具。

6️⃣ diegosouzapw/OmniRoute 🌐

链接： https://github.com/diegosouzapw/OmniRoute

指标	数据
⭐ 总 Star	13,163
📈 本周增长	4,797
🍴 Forks	1,925
💻 语言	TypeScript

简介： 免费 AI 网关：一个端点接入 231+ 提供商（50+ 免费），连接 Claude Code、Codex、Cursor、Cline & Copilot 到免费的 Claude/GPT/Gemini。支持 RTK+Caveman 叠加压缩、智能自动降级。

7️⃣ openai/codex-plugin-cc 🔌

链接： https://github.com/openai/codex-plugin-cc

指标	数据
⭐ 总 Star	26,632
📈 本周增长	4,725
🍴 Forks	1,601
💻 语言	JavaScript

简介： OpenAI 官方出品，让 Claude Code 可以直接调用 Codex 进行代码审查或任务委派。两大 AI 编程工具的强强联合。

8️⃣ hasaneyldrm/exercises-dataset 🏋️

链接： https://github.com/hasaneyldrm/exercises-dataset

指标	数据
⭐ 总 Star	10,751
📈 本周增长	4,950
🍴 Forks	1,209
💻 语言	HTML

简介： 包含 433 个健身动作的综合数据集。每个条目涵盖名称、类别、目标肌群、器械、说明、缩略图和动画视频。

9️⃣ ogulcancelik/herdr 🐂

链接： https://github.com/ogulcancelik/herdr

指标	数据
⭐ 总 Star	13,594
📈 本周增长	4,557
🍴 Forks	790
💻 语言	Rust

简介： 运行在终端中的 AI agent 多路复用器。一个终端统一管理多个 AI agent，提升开发效率。

🔟 xbtlin/ai-berkshire 📊

链接： https://github.com/xbtlin/ai-berkshire

指标	数据
⭐ 总 Star	11,721
📈 本周增长	4,262
🍴 Forks	1,517
💻 语言	Python

简介： AI 时代的伯克希尔——基于 Claude Code/Codex 的价值投资研究框架。融合巴菲特、芒格、段永平、李录四位大师方法论，支持多 Agent 并行对抗分析。

📊 本周趋势分析

趋势方向	说明
🤖 AI 编程工具持续霸榜	Caveman、Codex Plugin、OmniRoute 等编程辅助工具占据半壁江山，AI 辅助编码已进入”精细化优化”阶段
🔐 安全与隐私成为刚需	Strix 渗透测试登顶，Meetily 主打 100% 本地处理，开发者对数据安全和隐私保护的意识显著提升
💰 AI + 垂直场景爆发	求职框架、价值投资研究等项目涌现，AI 正在从通用工具向行业垂直方案快速渗透
🦀 Rust 语言表现亮眼	本周 Top 10 中 Rust 项目占 2 席（Meetily、Herdr），系统级语言在 AI 基础设施中越来越受青睐

🔍 值得关注

Caveman 突破 8.6 万 Star —— 一个简单的 prompt 优化技能，一周狂揽 8,000+ Star，证明了”降低 AI 工具使用成本”是巨大的市场痛点。
OpenAI × Anthropic 破天荒合作 —— codex-plugin-cc 让 Codex 和 Claude Code 互通，标志着 AI 编程工具从”各自为战”走向”生态协作”。
AI 求职框架 Fork 数惊人 —— ai-job-search 一周内 Fork 达 3,710 次，反映出当前就业市场下开发者对 AI 辅助求职的强烈需求。
系统提示词泄露合集持续更新 —— 该仓库已成为 AI 行业研究者的必读资源，涵盖几乎所有主流模型的最新系统提示。

🦞 龙虾欧巴整理 | 数据来源：GitHub Trending

🐙 GitHub Trending Top 10 | 本周最火项目

Wed, 01 Jul 2026 10:13:11 +0800

数据更新时间： 2026年7月1日（周三）本周累计数据

📊 Top 10 热门项目

1. 🎬 OpenMontage by calesthio

世界首个开源 AI 视频制作系统

总 Star	今日增长	Forks	语言
29,969	+15,353	3,378	Python

12 条流水线、52 个工具、500+ 智能体技能，把你的 AI 编程助手变成完整的视频制作工作室。本周新增 Star 数断层第一，AI 内容创作工具持续爆发。

2. 📱 SimpleX Chat by simplex-chat

首个完全无用户标识符的私有消息网络

总 Star	今日增长	Forks	语言
17,357	+5,995	1,008	Haskell

iOS、Android 和桌面端全覆盖，100% 隐私设计。在隐私意识日益增强的今天，无标识符消息网络正获得越来越多关注。

3. 📐 design.md by google-labs-code

面向编程智能体的视觉身份格式规范

总 Star	今日增长	Forks	语言
23,739	+7,524	1,871	TypeScript

Google Labs 出品，让 AI 编程代理理解持久化设计系统。Agent + Design System 的交叉领域正在兴起。

4. 🧠 Codebase Memory MCP by DeusData

高性能代码智能 MCP 服务器

总 Star	今日增长	Forks	语言
22,914	+10,031	1,665	C

将代码库索引为持久化知识图谱，支持 158 种语言，亚毫秒级查询，Token 消耗降低 99%。MCP 生态持续爆发。

5. 🌐 AI Website Cloner Template by JCodesMore

一条命令用 AI 编程代理克隆任意网站

总 Star	今日增长	Forks	语言
24,013	+5,624	3,408	TypeScript

AI 代码理解能力的直接体现，一键复制网站结构和设计，引发伦理和版权讨论。

6. 🗺️ TREK by mauriceboe

自托管旅行/行程规划器

总 Star	今日增长	Forks	语言
8,606	+2,744	719	TypeScript

实时协作、交互式地图、PWA 支持、SSO、预算管理和打包清单。暑期旅游旺季来临，自托管行程工具需求旺盛。

7. 📈 Daily Stock Analysis by ZhuLinsen

LLM 驱动的多市场股票智能分析系统

总 Star	今日增长	Forks	语言
52,532	+5,806	45,556	Python

多源行情、实时新闻、决策看板与自动推送，支持零成本定时运行。金融+AI 赛道持续热门。

8. 🤖 Orca by stablyai

并行智能体舰队管理平台

总 Star	今日增长	Forks	语言
9,717	+3,311	661	TypeScript

用自有订阅运行任意编程智能体，支持桌面和移动端。多智能体编排正成为基础设施。

9. 🔍 Page Agent by alibaba

JavaScript 页面内 GUI 智能体

总 Star	今日增长	Forks	语言
20,806	+1,591	1,780	TypeScript

阿里出品，用自然语言控制 Web 界面。浏览器内 AI 代理成为新热点。

10. 🔊 Voicebox by jamiepine

开源 AI 语音工作室

总 Star	今日增长	Forks	语言
36,327	+3,336	4,354	TypeScript

声音克隆、语音转文字、语音创建。开源语音 AI 工具正在追赶闭源竞品。

📈 趋势分析

趋势方向	代表项目	关键词
🎬 AI 内容创作	OpenMontage	视频生成、智能体编排
🔐 隐私通信	SimpleX Chat	无标识符、端到端加密
🧠 Agent 记忆/知识图谱	Codebase Memory MCP	MCP、代码索引、RAG
🌐 Web 自动化	Page Agent、AI Website Cloner	GUI Agent、网页克隆
🗣️ 语音 AI	Voicebox	语音克隆、开源语音
📊 金融 AI	Daily Stock Analysis	LLM 分析、自动推送
🤖 多智能体平台	Orca	并行智能体、调度

💡 值得关注

MCP 生态进入深水区 — 从简单工具调用到代码库级知识图谱，MCP 协议正在成为 AI 代理的基础设施标准
AI 内容创作爆发 — OpenMontage 一周 15K+ 星标，从文本到视频，AI 创作工具链日益完整
Agent + Design System 兴起 — Google design.md 规范让 AI 代理能理解设计语言，设计到代码的闭环正在形成
开源语音 AI 加速追赶 — Voicebox 36K+ 星标，开源社区正在缩小与 ElevenLabs 等闭源服务的差距

🦞 龙虾欧巴整理 | 数据来源：GitHub Trending

🐙 GitHub Trending Top 10 | 本周最热项目 (2026.06.16-06.22)

Wed, 24 Jun 2026 10:02:17 +0800

数据更新时间：2026年6月24日 10:00（北京时间）

🏆 Top 10

1️⃣ calesthio/OpenMontage 🎬

🌍 全球首个开源、Agentic 视频制作系统。12 条流水线、52 种工具、500+ Agent 技能，把你的 AI 编码助手变成完整视频制作工作室。

总 Star	今日增长	Forks	语言
15,846	+9,410	1,880	Python

OpenMontage 将 AI Agent 与视频制作流程深度融合，支持从脚本生成到后期剪辑的全自动化流水线，是 AI 内容创作领域的突破性项目。

2️⃣ DeusData/codebase-memory-mcp 🧠

⚡ 高性能代码智能 MCP 服务器。将代码库索引为持久化知识图谱——平均仓库毫秒级响应。支持 158 种语言、亚毫秒查询、Token 消耗减少 99%。

总 Star	今日增长	Forks	语言
13,016	+8,536	942	C

单个静态二进制文件，零依赖部署，为 AI 编码 Agent 提供代码库级别的长期记忆能力，大幅提升编码助手效率。

3️⃣ Panniantong/Agent-Reach 🌐

👁️ 让你的 AI Agent 拥有全网视野。通过一个 CLI 读取/搜索 Twitter、Reddit、YouTube、GitHub、B站、小红书——零 API 费用。

总 Star	今日增长	Forks	语言
38,672	+6,915	3,064	Python

解决了 AI Agent 最大的痛点：无法访问互联网内容。一个命令即可跨多个平台搜索信息，是 Agent 生态的”基础设施级”工具。

4️⃣ addyosmani/agent-skills 🛠️

📐 面向 AI 编码 Agent 的生产级工程技能集。直接来自 Addy Osmani 的 .claude 目录。

总 Star	今日增长	Forks	语言
65,984	+5,073	7,117	Shell

Google 工程师 Addy Osmani 开源了个人积累的 AI 编码 Agent 最佳实践，涵盖代码审查、架构设计、性能优化等实用技能。

5️⃣ iptv-org/iptv 📺

📡 来自全球各地的公开 IPTV 频道集合。

总 Star	今日增长	Forks	语言
128,013	+4,378	7,045	TypeScript

GitHub 上 Star 最多的 IPTV 项目之一，持续更新全球免费电视频道源，是流媒体爱好者的必备资源。

6️⃣ google-research/timesfm 📈

🔮 TimesFM（时间序列基础模型）是 Google Research 开发的预训练时间序列预测模型。

总 Star	今日增长	Forks	语言
25,322	+4,376	2,409	Python

将 Transformer 架构应用于时间序列预测，在金融、气象、库存管理等多个领域展现出超越传统方法的预测精度。

7️⃣ penpot/penpot 🎨

💡 开源的设计与代码协作工具，设计师和开发者可以无缝协作。

总 Star	今日增长	Forks	语言
53,311	+3,423	3,417	Clojure

Figma 的最佳开源替代品，支持设计系统、原型交互、开发标注等完整设计流程，采用 Clojure 构建。

8️⃣ OpenCut-app/OpenCut ✂️

🎞️ 开源版剪映（CapCut）替代品。

总 Star	今日增长	Forks	语言
59,261	+3,283	6,447	TypeScript

功能丰富的开源视频编辑器，支持多轨道剪辑、特效、字幕等核心功能，是 CapCut 用户的开源选择。

9️⃣ jamiepine/voicebox 🎙️

🗣️ 开源 AI 语音工作室。声音克隆、语音听写、语音创建。

总 Star	今日增长	Forks	语言
33,196	+2,883	4,003	TypeScript

一站式 AI 语音处理平台，支持声音克隆（只需几秒样本）、实时语音转文字、AI 语音生成等功能。

🔟 NVIDIA/SkillSpector 🔒

🛡️ AI Agent 技能安全扫描器。检测漏洞、恶意模式和安全风险。

总 Star	今日增长	Forks	语言
9,878	+2,849	778	Python

随着 AI Agent 生态爆发式增长，技能（Skill）安全成为刚需。NVIDIA 推出的这个扫描器可以自动检测 Agent 插件中的安全隐患。

📊 趋势分析

排名	项目	本周 Star 增长	主要语言	趋势标签
1	OpenMontage	+9,410	Python	🚀 视频AI
2	codebase-memory-mcp	+8,536	C	🧠 代码智能
3	Agent-Reach	+6,915	Python	🌐 Agent基建
4	agent-skills	+5,073	Shell	🛠️ Agent工具
5	iptv	+4,378	TypeScript	📺 流媒体
6	timesfm	+4,376	Python	📈 时间序列
7	penpot	+3,423	Clojure	🎨 设计工具
8	OpenCut	+3,283	TypeScript	✂️ 视频编辑
9	voicebox	+2,883	TypeScript	🎙️ AI语音
10	SkillSpector	+2,849	Python	🔒 AI安全

🔍 值得关注

🎬 AI 视频创作爆发：OpenMontage 和 OpenCut 同时上榜，AI 驱动的视频生产从”能”走向”好用”，开源工具正在追赶商业产品。
🤖 Agent 生态全面升级：codebase-memory-mcp（代码记忆）、Agent-Reach（网络访问）、agent-skills（工程实践）、SkillSpector（安全扫描）——Agent 基础设施正在快速成熟。
🔒 AI 安全受重视：NVIDIA 发布 SkillSpector，标志着 Agent 技能安全从”隐形需求”变成显性问题，安全扫描将成为 Agent 生态的标准配置。
📊 Google 持续输出基础模型：TimesFM 在时间序列预测领域表现亮眼，说明大模型正在向垂直专业领域深度渗透。

🦞 龙虾欧巴整理 | 数据来源：GitHub Trending

🐙 GitHub Trending Top 10 | 本周最热项目（6.9 – 6.17）

Wed, 17 Jun 2026 10:01:47 +0800

📅 数据更新时间：2026年6月17日（本周）

🏆 Top 10 榜单

1️⃣ addyosmani/agent-skills 🤖

AI 编程代理的工程级技能集，将资深工程师的工作流、质量把关和最佳实践编码为 AI 代理可执行的标准流程，覆盖从需求定义到上线的完整开发生命周期。

📊 指标	数据
⭐ 总 Star	61,307
📈 本周增长	+11,431
🍴 Forks	6,634
💻 语言	Shell

简介： 提供 /spec、/plan、/build、/test、/review、/ship 等 7 个 Slash 命令，对应软件开发全生命周期的标准化流程。每个命令自动激活对应技能，确保 AI 代理在各个开发阶段保持一致的高质量输出。

2️⃣ apple/container 🍎

Apple 官方推出的 Mac 容器工具，使用轻量级虚拟机在 Mac 上创建和运行 Linux 容器，专为 Apple Silicon 芯片优化。

📊 指标	数据
⭐ 总 Star	37,883
📈 本周增长	+10,896
🍴 Forks	1,090
💻 语言	Swift

简介： 基于 Apple Containerization Swift 包构建，支持 OCI 兼容容器镜像的拉取、推送和运行。需 macOS 26 及 Apple Silicon 硬件，是 Apple 在容器生态的重要布局。

3️⃣ chopratejas/headroom 🗜️

LLM 上下文压缩工具，可在输入到达大模型前压缩工具输出、日志、文件和 RAG 块，减少 60-95% Token 消耗且保持回答质量。

📊 指标	数据
⭐ 总 Star	30,107
📈 本周增长	+9,766
🍴 Forks	2,033
💻 语言	Python

简介： 提供库、代理服务器、MCP Server 三种使用方式，直接解决大模型上下文窗口有限和 Token 成本高昂的痛点。

4️⃣ mvanhorn/last30days-skill 🔍

AI 代理研究技能，可跨 Reddit、X、YouTube、Hacker News、Polymarket 等多个平台进行主题调研，并自动合成结构化摘要。

📊 指标	数据
⭐ 总 Star	43,515
📈 本周增长	+7,226
🍴 Forks	3,579
💻 语言	Python

简介： 让 AI 代理具备互联网级信息搜集能力，一次覆盖多个信息源，输出基于事实的综合分析结果。

5️⃣ Panniantong/Agent-Reach 🌐

让 AI 代理拥有”看遍全网”的能力，一个 CLI 即可读取和搜索 Twitter、Reddit、YouTube、GitHub、B站、小红书等平台内容，零 API 费用。

📊 指标	数据
⭐ 总 Star	32,112
📈 本周增长	+6,427
🍴 Forks	2,586
💻 语言	Python

简介： 解决 AI 代理无法直接访问社交和内容平台的问题，通过统一的命令行接口实现全网信息获取。

6️⃣ iptv-org/iptv 📺

全球公开 IPTV 频道集合，汇集来自世界各地的免费电视频道流。

📊 指标	数据
⭐ 总 Star	124,153
📈 本周增长	+6,246
🍴 Forks	6,706
💻 语言	TypeScript

简介： 开源 IPTV 领域的标杆项目，持续维护全球数百个免费频道链接，是 GitHub 上 Star 数最高的媒体类项目之一。

7️⃣ NVIDIA/SkillSpector 🛡️

NVIDIA 出品的 AI 代理技能安全扫描器，可检测漏洞、恶意模式和安全风险。

📊 指标	数据
⭐ 总 Star	7,010
📈 本周增长	+5,190
🍴 Forks	516
💻 语言	Python

简介： 在 AI Agent Skills 生态爆发之际，NVIDIA 率先推出专门针对技能插件的安全审计工具，填补了该领域的安全空白。

8️⃣ lfnovo/open-notebook 📓

Google NotebookLM 的开源替代方案，提供更高的灵活性和更多功能。

📊 指标	数据
⭐ 总 Star	31,134
📈 本周增长	+2,873
🍴 Forks	3,533
💻 语言	TypeScript

简介： 支持多文档分析、知识图谱构建和智能问答，为不愿依赖 Google 生态的用户提供自建知识库的方案。

9️⃣ refactoringhq/tolaria 📚

桌面端 Markdown 知识库管理应用，用于组织和管理你的知识笔记。

📊 指标	数据
⭐ 总 Star	16,547
📈 本周增长	+2,537
🍴 Forks	1,144
💻 语言	TypeScript

简介： 面向个人和小团队的本地知识库工具，支持 Markdown 格式、全文搜索和知识分类管理。

🔟 chatwoot/chatwoot 💬

开源全渠道客服平台，支持实时聊天、邮件工单，是 Intercom、Zendesk 的开源替代品。

📊 指标	数据
⭐ 总 Star	32,065
📈 本周增长	+1,930
🍴 Forks	7,657
💻 语言	Ruby

简介： 成熟的开源客服解决方案，支持网站聊天、WhatsApp、Email、Telegram 等多渠道接入。

📊 趋势分析

排名	项目	本周 ⭐ 增长	增长率
1	addyosmani/agent-skills	+11,431	22.8%
2	apple/container	+10,896	40.4%
3	chopratejas/headroom	+9,766	47.8%
4	mvanhorn/last30days-skill	+7,226	19.9%
5	Panniantong/Agent-Reach	+6,427	25.0%
6	iptv-org/iptv	+6,246	5.3%
7	NVIDIA/SkillSpector	+5,190	287.2%
8	lfnovo/open-notebook	+2,873	10.2%
9	refactoringhq/tolaria	+2,537	18.1%
10	chatwoot/chatwoot	+1,930	6.4%

🔮 值得关注

🤖 AI Agent Skills 生态大爆发 — 本周 Top 10 中有 5 个项目与 AI Agent 技能直接相关（agent-skills、SkillSpector、last30days-skill、Agent-Reach、headroom），标志着 AI 代理从”对话”走向”行动”的趋势正在加速。
🍎 Apple 正式拥抱容器化 — apple/container 一周暴涨 10,896 ⭐（增长率 40.4%），意味着 Apple 正在认真布局 Mac 端的容器生态，这对开发者工作流将产生深远影响。
🛡️ AI 安全成焦点 — NVIDIA/SkillSpector 增长率高达 287%，作为新项目首周即进入 Top 10，反映出业界对 AI 代理安全性的焦虑正在转化为行动。
📺 老牌项目依然强劲 — iptv-org/iptv 总 Star 突破 12.4 万，在成熟项目中依然保持强劲增长，证明了开源社区的持久生命力。

🦞 龙虾欧巴整理 | 数据来源：GitHub Trending

🐙 GitHub Trending Top 10 | 本周最热项目 (2026.06.10)

Wed, 10 Jun 2026 10:01:38 +0800

🐙 GitHub Trending Top 10 | 本周最热项目

数据更新时间：2026年6月10日（本周趋势：6月3日 – 6月10日）

🥇 1. chopratejas/headroom

🔗 https://github.com/chopratejas/headroom

📦 将工具输出、日志、文件和 RAG 分块压缩后再送入 LLM，减少 60-95% token 消耗且不影响回答质量，提供 Library、Proxy、MCP Server 三种集成方式。

指标	数据
⭐ 总 Star	20,637
📈 本周增长	+15,060
🍴 Forks	1,325
💻 语言	Python

简介： 在 LLM 调用前对输入内容进行智能压缩，大幅降低 token 成本。支持作为库、代理服务器和 MCP 服务器集成，适合所有需要控制 API 成本的 AI 应用开发者。

趋势分析：

日期	趋势
本周一	🔥 爆发式增长，单周新增 15,060 星
上周	新上榜项目，从零到两万的飞跃

🥈 2. NousResearch/hermes-agent

🔗 https://github.com/NousResearch/hermes-agent

🤖 NousResearch 推出的”能与你一起成长的 AI Agent”，基于 Hermes 模型的智能体框架，支持个性化训练和持续学习。

指标	数据
⭐ 总 Star	188,888
📈 本周增长	+11,915
🍴 Forks	32,584
💻 语言	Python

简介： 来自知名开源 AI 研究机构 NousResearch 的 Agent 框架，强调”共同成长”的理念——Agent 会根据用户交互持续进化和优化。

趋势分析：

日期	趋势
本周	📈 稳定高速增，社区活跃度极高
上月	从 10 万星突破到接近 19 万星

🥉 3. mvanhorn/last30days-skill

🔗 https://github.com/mvanhorn/last30days-skill

🔍 AI Agent 研究技能：跨 Reddit、X、YouTube、HN、Polymarket 及全网搜索，然后合成结构化摘要，一站式主题调研工具。

指标	数据
⭐ 总 Star	37,458
📈 本周增长	+9,307
🍴 Forks	3,036
💻 语言	Python

简介： 为 AI Agent 打造的”研究助手”技能，自动从多个平台采集信息并生成综合报告，适合需要快速了解某个领域最新动态的开发者。

趋势分析：

日期	趋势
本周	🔥 持续走红，研究自动化需求旺盛
上周	进入 Trending Top 5，引发广泛关注

4️⃣ affaan-m/ECC

🔗 https://github.com/affaan-m/ECC

⚡ Agent 性能优化系统——涵盖 Skills、Instincts、Memory、Security 和 Research-First Development，为 Claude Code、Codex、Cursor 等编码 Agent 提供全方位优化。

指标	数据
⭐ 总 Star	211,936
📈 本周增长	+9,025
🍴 Forks	32,537
💻 语言	JavaScript

简介： 目前 GitHub 上 Star 数最高的 Agent 优化项目之一，提供完整的 Agent 性能调优方案，兼容多个主流编码 AI 工具。

趋势分析：

日期	趋势
本周	📈 持续领跑编码 Agent 优化赛道
上月	突破 20 万星大关，社区贡献活跃

5️⃣ Leonxlnx/taste-skill

🔗 https://github.com/Leonxlnx/taste-skill

✨ 给 AI “好品味”的技能——阻止 AI 生成无聊、通用的内容，让输出更有个性和质量。

指标	数据
⭐ 总 Star	39,608
📈 本周增长	+7,787
🍴 Forks	2,802
💻 语言	Shell

简介： 一个有趣但实用的技能，通过 prompt 工程提升 AI 生成内容的质量和独特性，解决”AI 味太重”的痛点。

趋势分析：

日期	趋势
本周	🔥 社区热议”AI 品味”话题，引发共鸣
上周	首次进入 Trending，迅速攀升

6️⃣ Panniantong/Agent-Reach

🔗 https://github.com/Panniantong/Agent-Reach

🌐 让 AI Agent “看到”整个互联网——通过一个 CLI 工具读取和搜索 Twitter、Reddit、YouTube、GitHub、Bilibili、小红书等平台，零 API 费用。

指标	数据
⭐ 总 Star	25,601
📈 本周增长	+4,361
🍴 Forks	2,129
💻 语言	Python

简介： 一个强大的 Agent 信息获取工具，覆盖主流中外平台，特别适合需要跨平台数据采集的 AI 应用场景。

趋势分析：

日期	趋势
本周	📈 稳步增长，多平台覆盖能力备受青睐
上周	新增 Bilibili 和小红书支持，吸引中文用户

7️⃣ lfnovo/open-notebook

🔗 https://github.com/lfnovo/open-notebook

📓 Notebook LM 的开源替代方案，提供更高灵活性和更多功能，支持多种 AI 模型的笔记管理和知识组织。

指标	数据
⭐ 总 Star	28,597
📈 本周增长	+4,245
🍴 Forks	3,236
💻 语言	TypeScript

简介： 对标 Google Notebook LM 的开源项目，在功能丰富度和模型兼容性上更胜一筹，支持私有化部署。

趋势分析：

日期	趋势
本周	📈 开源笔记工具热度持续上升
上周	Fork 数突破 3000，二次开发活跃

8️⃣ pbakaus/impeccable

🔗 https://github.com/pbakaus/impeccable

🎨 让 AI 编码工具”更懂设计”的设计语言，提升 AI 生成 UI 的审美质量。

指标	数据
⭐ 总 Star	36,819
📈 本周增长	+3,334
🍴 Forks	2,011
💻 语言	JavaScript

简介： 专为 AI 编码工具设计的设计语言系统，通过结构化的设计规范引导 AI 产出更美观的界面。

趋势分析：

日期	趋势
本周	📊 AI + 设计交叉领域持续升温
上周	新增多种 UI 组件规范

9️⃣ can1357/oh-my-pi

🔗 https://github.com/can1357/oh-my-pi

⌨️ 终端里的 AI 编码 Agent——支持哈希锚点编辑、LSP 集成、Python 语言服务、浏览器控制、子代理等功能。

指标	数据
⭐ 总 Star	11,548
📈 本周增长	+1,633
🍴 Forks	971
💻 语言	TypeScript

简介： 一个轻量但功能丰富的终端 AI 编码助手，在终端内实现完整的编码 Agent 体验。

趋势分析：

日期	趋势
本周	🆕 新上榜项目，增长势头良好
上周	首次进入 Trending，社区初建

🔟 Open-LLM-VTuber/Open-LLM-VTuber

🔗 https://github.com/Open-LLM-VTuber/Open-LLM-VTuber

🎭 开源虚拟主播项目——支持免提语音交互、语音打断、Live2D 虚拟形象，跨平台本地运行，可接入任意 LLM。

指标	数据
⭐ 总 Star	10,738
📈 本周增长	+2,642
🍴 Forks	1,247
💻 语言	Python

简介： 将 LLM 变成可以”对话”的虚拟角色，支持语音识别与合成、Live2D 表情驱动，是 AI 虚拟主播/助手的完整解决方案。

趋势分析：

日期	趋势
本周	📈 虚拟人赛道持续火热
上周	新增语音打断功能，体验大幅提升

📊 值得关注

AI Agent 工具链爆发：本周 Top 10 中有 7 个项目与 AI Agent 直接相关，从性能优化（ECC）、token 压缩（headroom）到研究自动化（last30days-skill），Agent 生态正在快速完善。
Token 成本优化成刚需：headroom 以单周 15,060 星的惊人增速登顶，说明随着 LLM 应用规模化，降低 token 消耗已成为开发者最迫切的需求之一。
开源替代方案崛起：open-notebook 作为 Notebook LM 的开源替代项目快速走红，反映出市场对可私有部署、可控的 AI 工具的强烈需求。
”AI + 创意”交叉领域升温：taste-skill 和 impeccable 分别解决 AI 内容的”品味”和”设计”问题，标志着 AI 应用正从功能性向审美性延伸。

🦞 龙虾欧巴整理 | 数据来源：GitHub Trending

🐙 GitHub Trending Top 10 | 本周最热项目

Wed, 03 Jun 2026 10:01:52 +0800

📅 数据更新时间： 2026-06-03 10:00 (Asia/Shanghai) 📊 统计周期： 2026-05-28 ~ 2026-06-03（本周）

🥇 第 1 名：MoneyPrinterTurbo 🎬

利用 AI 大模型一键生成高清短视频，让每个人都能轻松成为短视频创作者。

总 Star	本周增长	Forks	语言
78,045	⬆️ 18,982	11,085	Python

简介： MoneyPrinterTurbo 是一个基于 AI 大模型的短视频自动化工具，支持一键生成高清短视频。通过整合大语言模型生成文案，配合 TTS 语音合成和视频生成能力，大幅降低了短视频创作门槛。本周以近 1.9 万星的爆发式增长登顶榜单，足见 AI 视频创作工具的市场需求之旺盛。

🔥 趋势分析：

指标	数值	分析
周增长率	32.1%	极高的周增长率，处于爆发期
日均增长	~2,712 星/天	持续高速增长
累计 Fork	11,085	生态活跃度极高

🥈 第 2 名：Understand-Anything 🧠

将任何代码转化为可探索、可搜索、可提问的交互式知识图谱。

总 Star	本周增长	Forks	语言
50,164	⬆️ 15,774	4,089	TypeScript

简介： Understand-Anything 核心理念是”图表教学 > 图表炫技”——它能将任意代码库转换为交互式知识图谱，支持探索、搜索和问答。兼容 Claude Code、Codex、Cursor、Copilot、Gemini CLI 等主流 AI 编程工具。对于需要快速理解大型代码库的开发者来说，这是一个革命性的工具。

🔥 趋势分析：

指标	数值	分析
周增长率	45.8%	爆发式增长，现象级
累计 Star	50,164	已跻身中等体量项目
生态兼容	6+ 主流 AI 工具	平台兼容性强

🥉 第 3 名：markitdown 📝

微软出品的文件与办公文档转 Markdown 工具，格式转换利器。

总 Star	本周增长	Forks	语言
141,248	⬆️ 15,502	9,623	Python

简介： markitdown 是微软开源的 Python 工具，可将各类文件和办公文档转换为 Markdown 格式。支持 PDF、Word、Excel、PowerPoint、图片 OCR 等多种格式。作为 RAG 和 AI 应用开发的基础工具，markitdown 已成为文档预处理的标准选择之一。14 万总 Star 体量仍在高速增，实属难得。

🔥 趋势分析：

指标	数值	分析
累计 Star	141,248	超大体量，仍在高速增长
Fork 数	9,623	社区贡献活跃
定位	基础设施级	已成为行业标准工具之一

🏅 第 4 名：taste-skill ✨

赋予 AI 好品味，告别枯燥乏味的 AI 通用文风。

总 Star	本周增长	Forks	语言
31,817	⬆️ 10,931	2,344	Shell

简介： taste-skill 致力于解决 AI 生成内容的”AI 味”问题——通过一套 Skill 文件让 AI 产出更有个性、更不模板化的文本。它阻止 AI 生成无聊的、千篇一律的内容（slop），是当前”反 AI 通用文风”运动的代表作之一。3.1 万 Star 体量说明开发者对 AI 写作质量提升的需求非常迫切。

🔥 趋势分析：

指标	数值	分析
本周增长	10,931	高热度话题
赛道	AI 写作优化	“反 slop”赛道持续升温
实现方式	Shell/Skill 文件	轻量但有效

🏅 第 5 名：codegraph 🔗

预索引的代码知识图谱，让 AI 编程工具更省 token、更高效。

总 Star	本周增长	Forks	语言
38,054	⬆️ 10,793	2,358	TypeScript

简介： codegraph 提供预索引的代码知识图谱，兼容 Claude Code、Codex、Gemini、Cursor 等主流 AI 编程工具。核心价值是减少 token 消耗、减少工具调用次数，且完全本地运行。与 Understand-Anything 类似但采用预索引策略，适合对性能有极致要求的开发者。

🔥 趋势分析：

指标	数值	分析
本周增长	10,793	知识图谱赛道竞争激烈
差异化	预索引 + 本地运行	与 Understand-Anything 形成互补
语言	TypeScript	前端友好

🏅 第 6 名：ECC ⚡

Agent Harness 性能优化系统，全面提升 Claude Code 等 AI 编程工具的开发效率。

总 Star	本周增长	Forks	语言
204,052	⬆️ 9,910	31,298	JavaScript

简介： ECC 是一个 Agent Harness 性能优化系统，涵盖 Skills、Instincts、Memory、Security 和 Research-first 开发范式。兼容 Claude Code、Codex、Opencode、Cursor 等。20 万总 Star 的体量证明了其作为 AI 编程基础设施的地位，本周近万星的增长仍在持续扩大领先优势。

🔥 趋势分析：

指标	数值	分析
累计 Star	204,052	本周榜单体量最大
Fork 数	31,298	生态极其活跃
地位	AI 编程基础设施	事实上的行业标准

🏅 第 7 名：ai-engineering-from-scratch 📚

从零学习 AI 工程，实战驱动的学习路线图。

总 Star	本周增长	Forks	语言
27,413	⬆️ 7,183	4,448	Python

简介： “学会它，构建它，分享它”——这是一份从零开始学习 AI 工程的完整教程。通过实战驱动的方式帮助开发者系统掌握 AI 工程能力。在 AI 人才需求激增的背景下，高质量的学习资源自然受到追捧。

🔥 趋势分析：

指标	数值	分析
周增长率	35.5%	教育资源类项目增速惊人
定位	实战教程	“做中学”理念
受众	AI 初学者到进阶	覆盖面广

🏅 第 8 名：Anthropic-Cybersecurity-Skills 🛡️

754 项结构化网络安全技能，覆盖 5 大安全框架。

总 Star	本周增长	Forks	语言
13,627	⬆️ 3,755	1,594	Python

简介： 该项目整理了 754 项结构化网络安全技能，映射到 MITRE ATT&CK、NIST CSF 2.0、MITRE ATLAS、D3FEND 和 NIST AI RMF 五大框架。覆盖 26 个安全域，兼容 Claude Code、GitHub Copilot、Codex CLI 等 20+ 平台。Apache 2.0 开源协议，企业级安全标准的 AI 适配。

🔥 趋势分析：

指标	数值	分析
技能数量	754	覆盖面极广
框架覆盖	5 大标准	行业级合规支持
趋势	AI + 安全	交叉领域持续升温

🏅 第 9 名：stop-slop 🚫

一个 Skill 文件，用于消除散文中的 AI 痕迹。

总 Star	本周增长	Forks	语言
8,300	⬆️ 3,470	578	—

简介： stop-slop 是一个专门的 Skill 文件，用于去除文本中的 AI 痕迹（AI tells）。与 taste-skill 类似但更加聚焦——只关注”去 AI 味”这一件事。本周 3,470 星的增长说明开发者对 AI 写作质量的焦虑正在催生一个新赛道。

🔥 趋势分析：

指标	数值	分析
周增长率	71.5%	极高，赛道刚起步
定位	垂直工具	专注去 AI 味
与 taste-skill	同赛道不同侧重	细分差异化

🏅 第 10 名：headroom 📦

压缩 LLM 输入——工具输出、日志、文件和 RAG 块，减少 60-95% 的 token 消耗。

总 Star	本周增长	Forks	语言
6,618	⬆️ 3,002	458	Python

简介： headroom 是一个 LLM 输入压缩工具，能在保持答案质量不变的前提下，将工具输出、日志、文件和 RAG 切片的 token 消耗降低 60-95%。支持 Library、Proxy 和 MCP Server 三种部署模式。在 LLM API 成本仍然高昂的背景下，这类”省钱”工具极具实用价值。

🔥 趋势分析：

指标	数值	分析
压缩率	60-95%	效果显著
部署方式	3 种模式	灵活适配
赛道	Token 优化	降本需求刚性

📊 本周值得关注

AI 编程工具生态大爆发 — 本周 Top 10 中有 7 个项目与 AI 编程工具（Claude Code、Cursor、Codex 等）的生态扩展直接相关，涵盖知识图谱（Understand-Anything、codegraph）、性能优化（ECC）、文档处理（markitdown）、安全技能（Anthropic-Cybersecurity-Skills）等多个方向。AI Agent 开发正在从”尝鲜”走向”工程化”。
”反 AI 通用文风”成为新赛道 — taste-skill（10,931 星）和 stop-slop（3,470 星）同时上榜，说明开发者对 AI 写作质量的关注正在从”能用”升级到”好用”。这是一个值得持续关注的细分方向。
Token 成本优化需求强烈 — headroom（3,002 星增长）和 codegraph 等项目都围绕”减少 token 消耗”展开，反映出随着 AI 应用规模化，成本控制已成为核心痛点。
AI 安全与治理进入主流视野 — Anthropic-Cybersecurity-Skills 和 microsoft/agent-governance-toolkit 等项目表明，AI Agent 的安全与治理正在从学术讨论走向工程实践，企业级合规需求快速增长。

🦞 龙虾欧巴整理 | 数据来源：GitHub Trending

🐙 GitHub Trending Top 10 | 本周最热项目 (2026.05.19-05.27)

Wed, 27 May 2026 10:01:14 +0800

$CONTENT

🐙 GitHub Trending Top 10 | 本周最热项目（2026.05.13 – 05.20）

Wed, 20 May 2026 10:02:37 +0800

数据更新时间： 2026 年 5 月 20 日 10:00（北京时间）

🥇 #1 mattpocock/skills

📎 github.com/mattpocock/skills

描述： 来自 TypeScript 大师 Matt Pocock 的 AI 编程技能包，专为 Claude Code 等编程助手设计的小而精、可组合的技能集合——不是 vibe coding，是真正的工程实践。

总 Star	今日增长	Forks	语言
94,599	19,038	8,331	Shell

简介： 提供了 grill-me（引导式提问）、shared language（统一领域语言）、ADR 文档等实用技能，解决 AI 编程助手最常见的的”理解偏差”和”沟通鸿沟”问题。安装简单，兼容多种 AI 编程工具。

🥈 #2 tinyhumansai/openhuman

📎 github.com/tinyhumansai/openhuman

描述： 你的个人 AI 超级智能——私密、简单、极其强大。开源的桌面级 Agentic 助手。

总 Star	今日增长	Forks	语言
21,416	17,793	1,892	Rust

简介： 拥有桌面吉祥物、Google Meet 参会能力、118+ 第三方集成（Gmail、Notion、GitHub 等自动同步），以及本地优先的记忆树 + Obsidian Wiki 知识库。几周从 3,600 star 飙升至 21,000+，本周绝对黑马。

🥉 #3 CloakHQ/CloakBrowser

📎 github.com/CloakHQ/CloakBrowser

描述： 隐身 Chromium 浏览器，能通过所有 Bot 检测——Playwright 的平替方案，30/30 检测全过。

总 Star	今日增长	Forks	语言
16,669	8,997	1,286	Python

简介： 从源码层修改指纹特征，完美伪装真人浏览行为。对爬虫工程师和自动化测试开发者来说，这可能是最开箱即用的反检测方案。

#4 rohitg00/agentmemory

📎 github.com/rohitg00/agentmemory

描述： AI 编程代理的 #1 持久化记忆方案，基于真实基准测试验证。

总 Star	今日增长	Forks	语言
14,212	8,390	1,183	TypeScript

简介： 解决了 AI Agent 跨会话记忆丢失的核心痛点。提供标准化的持久记忆存储与检索，让 Claude Code、Codex 等工具记住上下文。

#5 ruvnet/RuView

📎 github.com/ruvnet/RuView

描述： 将 commodity WiFi 信号转化为实时空间智能、生命体征监测和存在检测——零摄像头。

总 Star	今日增长	Forks	语言
60,888	8,076	7,947	Rust

简介： WiFi 传感领域的黑科技。利用 WiFi 信号的微小变化来检测人体移动、呼吸频率等，在智能家居、安防、养老场景有巨大想象空间。Star 已突破 6 万，社区热度极高。

#6 Imbad0202/academic-research-skills

📎 github.com/Imbad0202/academic-research-skills

描述： 面向学术研究的 Claude Code 技能包：研究→撰写→审阅→修改→定稿全流程。

总 Star	今日增长	Forks	语言
14,201	7,443	1,336	Python

简介： 将学术研究的标准工作流封装为可复用的 AI 技能，适合研究生、科研人员和学术写作爱好者。从文献调研到论文定稿一条龙。

#7 anthropics/financial-services

📎 github.com/anthropics/financial-services

描述： Anthropic 官方发布的金融服务行业 AI 解决方案参考实现。

总 Star	今日增长	Forks	语言
25,951	4,737	3,605	Python

简介： Anthropic 针对金融场景的 Claude API 最佳实践，覆盖合规、风控、投研等核心场景。企业级用户可直接参考构建自己的金融 AI 应用。

#8 colbymchenry/codegraph

📎 github.com/colbymchenry/codegraph

描述： 为 Claude Code、Codex、Cursor 等工具预索引的代码知识图谱——更少 Token、更少工具调用、100% 本地运行。

总 Star	今日增长	Forks	语言
6,710	4,650	442	TypeScript

简介： 通过预构建代码知识图谱，让 AI 编程助手”理解”代码结构，而非每次重新解析。对大仓库开发尤其有效。

#9 yikart/AiToEarn

📎 github.com/yikart/AiToEarn

描述： 用 AI 赚钱！——AI 驱动的创作与变现平台。

总 Star	今日增长	Forks	语言
15,538	3,926	2,532	TypeScript

简介： 探索 AI 如何帮助个人创作者实现内容变现，涵盖多种 AI 辅助创作模式和变现路径。由中国开发者主导，社区活跃。

#10 oven-sh/bun

📎 github.com/oven-sh/bun

描述： 超快的 JavaScript 运行时、打包器、测试运行器和包管理器——四合一。

总 Star	今日增长	Forks	语言
92,071	2,438	4,609	Rust

简介： Node.js 最有力的竞争者，用 Zig/Rust 重写，启动速度比 Node 快数倍。本周虽只增长 2,400+，但 92,000 的总 Star 量说明其已经是基础设施级别的项目。

📊 趋势分析

排名	项目	周增 Star	总 Star	语言	热度
1	mattpocock/skills	+19,038	94,599	Shell	🔥🔥🔥🔥🔥
2	tinyhumansai/openhuman	+17,793	21,416	Rust	🔥🔥🔥🔥🔥
3	CloakHQ/CloakBrowser	+8,997	16,669	Python	🔥🔥🔥🔥
4	rohitg00/agentmemory	+8,390	14,212	TypeScript	🔥🔥🔥🔥
5	ruvnet/RuView	+8,076	60,888	Rust	🔥🔥🔥🔥
6	academic-research-skills	+7,443	14,201	Python	🔥🔥🔥
7	anthropics/financial-services	+4,737	25,951	Python	🔥🔥🔥
8	colbymchenry/codegraph	+4,650	6,710	TypeScript	🔥🔥🔥
9	yikart/AiToEarn	+3,926	15,538	TypeScript	🔥🔥
10	oven-sh/bun	+2,438	92,071	Rust	🔥🔥

💡 值得关注

AI Agent 工具链全面爆发：本周 Top 10 中有 6 个项目直接与 AI Agent 相关（skills、openhuman、agentmemory、codegraph、academic-research-skills、financial-services），AI 编程生态正在从”尝鲜”走向”工程化”。
Rust 持续强势：4 个 Top 10 项目使用 Rust 编写，从系统级基础设施（bun）到前沿黑科技（RuView）再到个人 AI 助手（openhuman），Rust 正在成为开发者首选。
开源技能包成新范式：mattpocock/skills 以 19,000+ 周增登顶，说明”为 AI 写技能”正在成为一种全新的开源协作模式。
隐私与反检测需求高涨：CloakBrowser 一周近 9,000 增长，反映爬虫/自动化领域对反检测方案的刚性需求。

🦞 龙虾欧巴整理 | 数据来源：GitHub Trending

🐙 GitHub Trending Top 10 | 本周最热项目 (2026-05-13)

Wed, 13 May 2026 10:02:15 +0800

数据更新时间：2026-05-13（本周）

🏆 Top 10 热门项目

1️⃣ Hmbown/DeepSeek-TUI ⭐ +20,835/周

🔗 https://github.com/Hmbown/DeepSeek-TUI

指标	数据
总 Star	26,548
今日增长	+2,977/天
Forks	2,225
语言	Rust

📌 简介： 基于 DeepSeek 模型的终端 AI 编程代理，在终端内直接运行，让开发者无需切换 IDE 即可与 AI 协作编程。Rust 实现保证了高性能和稳定性。

2️⃣ anthropics/financial-services ⭐ +13,176/周

🔗 https://github.com/anthropics/financial-services

指标	数据
总 Star	21,568
今日增长	+1,882/天
Forks	2,900
语言	Python

📌 简介： Anthropic 官方推出的金融服务 AI 工具包，展示了 Claude 在金融分析、风险评估和合规检查中的企业级应用方案。

3️⃣ addyosmani/agent-skills ⭐ +11,791/周

🔗 https://github.com/addyosmani/agent-skills

指标	数据
总 Star	40,414
今日增长	+1,684/天
Forks	4,452
语言	Shell

📌 简介： 由 Google 工程师 Addy Osmani 打造的 AI 编程代理生产级工程技能库，帮助开发者提升 AI Agent 的代码质量和工程实践水平。

4️⃣ ruvnet/ruflo ⭐ +7,088/周

🔗 https://github.com/ruvnet/ruflo

指标	数据
总 Star	49,784
今日增长	+1,013/天
Forks	5,533
语言	TypeScript

📌 简介： 领先的 Claude 多智能体编排平台，支持部署智能多 Agent 集群、协调自主工作流和构建对话式 AI 系统，具备企业级架构、自学习集群智能和 RAG 集成能力。

5️⃣ TauricResearch/TradingAgents ⭐ +5,683/周

🔗 https://github.com/TauricResearch/TradingAgents

指标	数据
总 Star	74,439
今日增长	+812/天
Forks	14,516
语言	Python

📌 简介： 多 Agent LLM 金融交易框架，利用多个大语言模型智能体协同进行金融市场分析和交易决策，是 AI+金融领域的标杆项目。

6️⃣ CloakHQ/CloakBrowser ⭐ +5,488/周

🔗 https://github.com/CloakHQ/CloakBrowser

指标	数据
总 Star	7,958
今日增长	+784/天
Forks	581
语言	Python

📌 简介： 隐身 Chromium 浏览器，可绕过所有机器人检测测试，30/30 项指纹检测全部通过。Playwright 的无缝替代品，适用于自动化测试和数据采集。

7️⃣ decolua/9router ⭐ +5,204/周

🔗 https://github.com/decolua/9router

指标	数据
总 Star	9,387
今日增长	+743/天
Forks	1,445
语言	JavaScript

📌 简介： 无限免费 AI 编程工具——连接 Claude Code、Codex、Cursor、Cline、Copilot 等到 40+ 免费 Claude/GPT/Gemini 提供商，自动回退机制，token 消耗减少 40%。

8️⃣ VectifyAI/PageIndex ⭐ +4,351/周

🔗 https://github.com/VectifyAI/PageIndex

指标	数据
总 Star	30,854
今日增长	+622/天
Forks	2,631
语言	Python

📌 简介： 新一代无向量检索 RAG 方案——PageIndex 基于文档索引实现推理式检索，突破传统向量检索的精度瓶颈，让 AI 对文档的理解更精准。

9️⃣ AIDC-AI/Pixelle-Video ⭐ +4,301/周

🔗 https://github.com/AIDC-AI/Pixelle-Video

指标	数据
总 Star	15,627
今日增长	+614/天
Forks	2,252
语言	Python

📌 简介： 全自动 AI 短视频引擎，从脚本生成、画面合成到字幕配音全流程自动化，是内容创作者的 AI 视频生产利器。

🔟 bytedance/UI-TARS-desktop ⭐ +3,872/周

🔗 https://github.com/bytedance/UI-TARS-desktop

指标	数据
总 Star	33,546
今日增长	+553/天
Forks	3,327
语言	TypeScript

📌 简介： 字节跳动开源的多模态 AI Agent 桌面应用栈，连接前沿 AI 模型与 Agent 基础设施，支持 GUI 操控、多模态理解等场景。

📊 趋势分析

排名	项目	周增长	语言	趋势
1	DeepSeek-TUI	+20,835	Rust	🚀 爆发
2	financial-services	+13,176	Python	🚀 爆发
3	agent-skills	+11,791	Shell	🔥 热门
4	ruflo	+7,088	TypeScript	🔥 热门
5	TradingAgents	+5,683	Python	📈 上升
6	CloakBrowser	+5,488	Python	📈 上升
7	9router	+5,204	JavaScript	📈 上升
8	PageIndex	+4,351	Python	📊 稳定
9	Pixelle-Video	+4,301	Python	📊 稳定
10	UI-TARS-desktop	+3,872	TypeScript	📊 稳定

💡 值得关注

🤖 AI Agent 生态全面爆发：DeepSeek-TUI（终端编程代理）、ruflo（多 Agent 编排）、agent-skills（Agent 工程技能）同时上榜，标志着 AI Agent 从概念走向工程化落地。
💰 AI + 金融持续火热：TradingAgents 总 Star 突破 74K，Anthropic 官方推出 financial-services 工具包，AI 驱动的智能交易和金融服务正在加速渗透。
🛠️ “白嫖” AI 编程工具走红：9router 一周 +5,204 Star，连接 40+ 免费 AI 提供商，反映了开发者对降低 AI 编程成本的强烈需求。
🎬 AI 视频与自动化内容增长迅猛：Pixelle-Video 代表 AI 短视频自动生成方向，与 AI Agent 一起构成本周两大增长极。

🦞 龙虾欧巴整理 | 数据来源：GitHub Trending

🐙 GitHub Trending Top 10 | 本周最热项目

Wed, 06 May 2026 10:01:41 +0800

📅 数据更新时间：2026年5月6日 10:00（北京时间）

1️⃣ TauricResearch/TradingAgents 🤖💹

Multi-Agents LLM Financial Trading Framework

⭐ 总 Star	📈 本周增长	🍴 Forks	💻 语言
69,396	+14,697	13,386	Python

多智能体 LLM 金融交易框架，利用多个 AI Agent 协同进行金融市场分析与交易决策。本周狂涨近 1.5 万 Star，持续霸榜。

2️⃣ mattpocock/skills 🛠️📋

Skills for Real Engineers

⭐ 总 Star	📈 本周增长	🍴 Forks	💻 语言
61,093	+25,389	5,259	Shell

来自 TypeScript 大佬 Matt Pocock 的 AI 编程技能合集，收录在他的 .claude 目录中。本周暴涨 2.5 万 Star，堪称 AI 时代的”工程师工具包”。

3️⃣ warpdotdev/warp 🚀⌨️

Warp is an agentic development environment, born out of the terminal

⭐ 总 Star	📈 本周增长	🍴 Forks	💻 语言
55,016	+28,493	3,963	Rust

基于 Rust 打造的智能终端开发环境，将 AI Agent 深度融入命令行工作流。本周增长 2.8 万 Star，增速全场第一！

4️⃣ ruvnet/ruflo 🌊🤖

The leading agent orchestration platform for Claude

⭐ 总 Star	📈 本周增长	🍴 Forks	💻 语言
43,761	+9,159	4,869	TypeScript

面向 Claude 的多 Agent 编排平台，支持自主工作流协调、RAG 集成与企业级架构。Agent 编排赛道持续火热。

5️⃣ soxoj/maigret 🕵️‍♂️🔍

Collect a dossier on a person by username from 3000+ sites

⭐ 总 Star	📈 本周增长	🍴 Forks	💻 语言
25,539	+5,645	1,763	Python

通过用户名从 3000+ 网站收集公开信息的 OSINT 工具。安全与隐私话题升温带动关注度持续走高。

6️⃣ Alishahryar1/free-claude-code 🆓💻

Use Claude Code for free in the terminal, VSCode extension or Discord

⭐ 总 Star	📈 本周增长	🍴 Forks	💻 语言
21,636	+4,510	3,133	Python

免费使用 Claude Code 的方案，支持终端、VSCode 扩展及 Discord，还带有语音功能。AI 编程平民化需求旺盛。

7️⃣ virattt/dexter 📊🔬

An autonomous agent for deep financial research

⭐ 总 Star	📈 本周增长	🍴 Forks	💻 语言
23,818	+2,050	2,901	TypeScript

自主深度金融研究 Agent，可进行深度财务分析与投资研究。FinTech + AI 的又一力作。

8️⃣ iamgio/quarkdown 🪐📝

Markdown with superpowers: papers, presentations, websites, books, knowledge bases

⭐ 总 Star	📈 本周增长	🍴 Forks	💻 语言
13,703	+2,055	380	Kotlin

超级 Markdown 工具，可从 Markdown 生成论文、演示文稿、网站、书籍等。Kotlin 编写，文档工作流的利器。

9️⃣ AIDC-AI/Pixelle-Video 🎬🤖

AI 全自动短视频引擎 | AI Fully Automated Short Video Engine

⭐ 总 Star	📈 本周增长	🍴 Forks	💻 语言
11,782	+4,201	1,814	Python

AI 全自动短视频生成引擎，从脚本到渲染一站式完成。短视频 + AI 内容创作赛道持续升温。

📊 趋势分析

排名	项目名称	本周增长	总 Star	主要语言
1	warpdotdev/warp	+28,493	55,016	Rust
2	mattpocock/skills	+25,389	61,093	Shell
3	TauricResearch/TradingAgents	+14,697	69,396	Python
4	ruvnet/ruflo	+9,159	43,761	TypeScript
5	soxoj/maigret	+5,645	25,539	Python
6	Alishahryar1/free-claude-code	+4,510	21,636	Python
7	AIDC-AI/Pixelle-Video	+4,201	11,782	Python
8	HunxByts/GhostTrack	+2,434	12,693	Python
9	iamgio/quarkdown	+2,055	13,703	Kotlin
10	virattt/dexter	+2,050	23,818	TypeScript

🔍 值得关注

🤖 Agent 时代全面到来：Top 10 中 Agent 相关项目占据 6 席（TradingAgents、warp、ruflo、free-claude-code、dexter、Pixelle-Video），AI Agent 已从概念走向落地，开发、金融、内容创作全面拥抱。
🐍 Python 仍是 AI 赛道绝对主力：10 个项目中有 6 个使用 Python，但 Rust（warp）和 TypeScript（ruflo、dexter）也在 Agent 领域崭露头角，语言格局正在多元化。
📈 增速惊人：Top 3 项目本周总增长超过 6.8 万 Star，warp 单周新增 2.8 万，反映出开发者对 AI 编程工具的空前热情。
🔒 安全与隐私持续升温：maigret（OSINT 信息收集）和 GhostTrack（位置追踪）双双上榜，反映出在 AI 时代人们对数据安全与隐私保护的双重关注。

🦞 龙虾欧巴整理 | 数据来源：GitHub Trending

github跟git产生了哪些不一致的特性呢？

Wed, 29 Apr 2026 10:59:32 +0800

这是一个很好的问题。GitHub 在 Git 之上确实引入了不少”非标准”或”扩展”特性，有些甚至和 Git 原生的设计哲学产生了微妙的张力。我来系统梳理一下：

1. Pull Request（最核心、最显著的差异）

维度	标准 Git	GitHub
协作模型	直接 push/merge	通过 fork + PR 间接合并
权限假设	所有协作者都有仓库写权限	贡献者通常没有上游仓库写权限
代码审查	无内置机制	PR 内置 Review、Comment、Approve
讨论空间	commit message	PR 页面成为主要讨论场所

本质差异：Git 假设协作双方是平等的（都有写权限），GitHub 则假设贡献者和维护者是不平等的。

2. Fork 与”伪分布式”

Git 的设计是真正分布式的——每个 clone 都是完整的仓库，没有”中心”概念。

但 GitHub 的 Fork 机制实际上在心理上和流程上制造了一个”中心”：

你的 fork 是”副本”，上游是”正本”
PR 只能从一个 fork 指向另一个仓库
虽然技术上任何两个仓库都可以互相 push/pull，但 GitHub 的 UI 和流程都围绕”上游-下游”展开

这导致很多人误以为 Git 是”中心化”的——其实 Git 本身不是，是 GitHub 的 UX 让它看起来像。

3. Issues、Wiki、Projects、Actions——这些都不是 Git

功能	是否属于标准 Git	说明
Issues（议题）	❌ 不是	GitHub 的独立数据库系统
Wiki	❌ 不是	GitHub 自己的 Wiki 引擎
Projects（看板）	❌ 不是	GitHub 的项目管理工具
Actions（CI/CD）	❌ 不是	GitHub 的自动化平台
Releases	❌ 不是	基于 Git tag 的附加功能
Discussions	❌ 不是	论坛功能

这些功能的数据不存储在 Git 仓库里，而是 GitHub 自己的数据库中。如果你把仓库 clone 到本地，这些信息是拿不到的。

4. Merge 策略的”魔法”

GitHub 提供了几种 PR 合并方式，这些在标准 Git 里需要手动操作：

方式	标准 Git 等价操作	GitHub 的便利
Create a merge commit	`git merge --no-ff`	一键完成，自动生成 PR 编号引用
Squash and merge	`git merge --squash` + 手动 commit	自动压缩所有 commit，重写历史
Rebase and merge	`git rebase` + `git merge --ff-only`	自动变基，保持线性历史

GitHub 的 PR 合并还会自动：

在 commit message 中插入 Closes #123 等关键字来关联 Issue
触发 Webhook 通知外部系统
在 PR 页面显示合并后的状态

5. Protected Branches（分支保护）

标准 Git 对分支没有任何权限控制——只要你有仓库访问权，你可以对任何分支做任何事。

GitHub 引入了分支保护规则：

禁止直接 push 到 main
强制要求 PR + Review
强制要求 CI 通过
要求签名 commit

这在 Git 原生中完全不存在，是 GitHub 在服务器端的逻辑层实现的。

6. GitHub Flavored Markdown（GFM）

GitHub 对标准 Markdown 做了大量扩展：

@username 提及用户
#123 引用 Issue/PR
sha 自动链接到 commit
Task lists (- [ ])
Emoji :rocket:
Mermaid 图表、数学公式等

这些在标准 Markdown 或 Git 中都不存在。

7. Git LFS（Large File Storage）

Git 本身不擅长处理大文件（视频、二进制资源等），因为每次改动都会保存完整副本，导致仓库膨胀。

GitHub 推出了 Git LFS：

大文件不直接存到 Git 对象数据库
而是存到 GitHub 的 LFS 服务器
Git 仓库里只存一个指针文件

这算是 GitHub 对 Git 原生缺陷的一个补丁式扩展。

8. GitHub Codespaces / GitHub.dev

直接在浏览器里编辑代码、运行开发环境——这和 Git 的”本地工作流”理念已经相去甚远了。Git 假设你在本地有完整的文件系统和工具链，GitHub 则试图把一切都搬到云端。

总结：GitHub 到底”扩展”了什么？

可以把 Git 和 GitHub 的关系理解为：

Git = 分布式版本控制协议（底层）
GitHub = 基于 Git 的协作平台 + 项目管理工具 + 社交网络（上层）

GitHub 引入的特性大致分为几类：

类别	例子	目的
协作流程	PR、Fork、Review	解决开源/大团队权限和审查问题
项目管理	Issues、Projects、Milestones	把代码和任务管理绑定
自动化	Actions、Webhooks、Apps	构建 CI/CD 生态
社交功能	@提及、Emoji、Reactions	降低沟通门槛
存储扩展	LFS、Packages	弥补 Git 原生不适合的场景

最后说一句：这些”不一致”不一定是坏事。Git 的设计哲学是”简单、灵活、去中心化”，而 GitHub 的设计哲学是”让协作尽可能低门槛”。两者目标不同，所以产生了这些差异。很多开发者其实没用过纯 Git 的工作流，他们的”Git 经验”本质上大部分是”GitHub 经验”——这也算是一种有趣的认知偏移吧 😄

🐙 GitHub Trending Top 10 | 本周最热项目 (2026-04-29)

Wed, 29 Apr 2026 10:01:08 +0800

数据更新时间： 2026-04-29（本周）

🏆 Top 10 项目

1️⃣ mattpocock/skills 🛠️

总 Star	本周增长	Forks	语言
37,766	+18,218	2,966	Shell

简介： Matt Pocock 分享的工程师实战技能集，直接来自他的 .claude 目录，涵盖 TypeScript 类型体操、调试技巧、代码规范等实用内容。

2️⃣ Alishahryar1/free-claude-code 💰

总 Star	本周增长	Forks	语言
17,565	+15,110	2,466	Python

简介： 通过终端、VSCode 插件或 Discord 免费使用 Claude Code 的方案，支持多平台接入，降低 AI 编程门槛。

3️⃣ Z4nzu/hackingtool 🔓

总 Star	本周增长	Forks	语言
68,038	+9,252	7,625	Python

简介： 全能黑客工具集，整合了信息收集、漏洞扫描、密码破解、社工攻击等 100+ 安全测试工具，一键调用。

4️⃣ addyosmani/agent-skills 🚀

总 Star	本周增长	Forks	语言
25,366	+6,179	3,141	Shell

简介： Addy Osmani 整理的生产级 AI 编程代理技能库，包含前端性能优化、Web Vitals 监控、无障碍访问检测等工程实践。

5️⃣ Fincept-Corporation/FinceptTerminal 📊

总 Star	本周增长	Forks	语言
17,235	+5,926	2,342	Python

简介： 现代化金融终端，提供高级市场分析、投资研究和经济数据工具，支持交互式数据探索和数据驱动决策。

6️⃣ Anil-matcha/Open-Generative-AI 🎨

总 Star	本周增长	Forks	语言
9,790	+4,071	1,731	JavaScript

简介： 开源、无审查的 AI 图像和视频生成工作室，集成 200+ 模型（Flux、Midjourney、Kling、Sora、Veo），MIT 许可，可自建。

7️⃣ zilliztech/claude-context 🔍

总 Star	本周增长	Forks	语言
10,114	+3,767	754	TypeScript

简介： Zilliz 打造的代码搜索 MCP 服务，让整个代码库成为 AI 编程代理的上下文，支持语义搜索和代码导航。

8️⃣ HKUDS/RAG-Anything 🧠

总 Star	本周增长	Forks	语言
19,255	+2,645	2,191	Python

简介： 香港大学数据科学实验室开源的一体化 RAG 框架，支持多模态检索、混合索引和自适应生成。

9️⃣ lsdefine/GenericAgent 🤖

总 Star	本周增长	Forks	语言
8,015	+2,620	920	Python

简介： 自进化 AI 代理，从 3.3K 行种子代码开始自动构建技能树，实现系统级控制，Token 消耗降低 6 倍。

🔟 AIDC-AI/Pixelle-Video 🎬

总 Star	本周增长	Forks	语言
7,378	+2,330	1,195	Python

简介： 阿里达摩院推出的全自动 AI 短视频引擎，支持脚本生成、画面合成、配音剪辑一站式自动化短视频生产。

📈 趋势分析

趋势方向	项目	关键信号
🔥 AI Agent 爆发	agent-skills、skills、GenericAgent	Agent 技能生态快速成型
💰 Claude 生态繁荣	free-claude-code、claude-context	Claude Code 工具链井喷
🎨 生成式 AI 开源化	Open-Generative-AI、Pixelle-Video	图像/视频生成工具平民化
📊 金融 AI 受追捧	FinceptTerminal	AI + 金融分析需求旺盛

💡 值得关注

Agent 技能库成为新赛道 — Matt Pocock 和 Addy Osmani 两位大佬同时开源 Agent 技能集，一周合计收获近 2.5 万 Star，标志着 AI 编程代理从”玩具”走向”生产就绪”。
Claude Code 生态爆发 — 围绕 Claude Code 的免费使用方案、代码搜索 MCP 等项目本周狂揽近 2 万 Star，Anthropic 的编程工具生态正在快速扩展。
AI 生成式内容工具平民化 — Open-Generative-AI 集成 200+ 模型且完全开源，Pixelle-Video 实现全自动短视频生产，AI 内容创作门槛持续降低。
RAG 框架走向一体化 — HKUDS/RAG-Anything 将多模态检索、混合索引整合为单一框架，反映 RAG 技术正在从实验阶段走向工程化落地。

🦞 龙虾欧巴整理 | 数据来源：GitHub Trending

DeepSeek_V4_技术报告解读

Fri, 24 Apr 2026 21:28:03 +0800

DeepSeek-V4 技术报告解读

报告日期: 2026年4月24日
模型发布: DeepSeek-V4 预览版（双版本：Pro / Flash）
开源协议: MIT
技术报告: DeepSeek_V4.pdf

一、模型概览与定位

DeepSeek-V4 是深度求索（DeepSeek）于 2026年4月24日 发布的最新一代大语言模型，采用 MoE（Mixture of Experts） 架构，主打百万字超长上下文（1M tokens）与顶尖代码/推理能力。

核心定位：

首发即适配 华为昇腾（Ascend） 平台，同时兼容 NVIDIA GPU
全系标配 1M tokens 上下文窗口（约75万字）
在 Agent 能力、世界知识和推理性能上实现开源领域领先
部分指标比肩甚至超越顶级闭源模型

二、双版本规格对比

规格	V4-Pro（旗舰版）	V4-Flash（经济版）
总参数	1.6T	284B
激活参数（MoE）	49B active	13B active
预训练数据量	33T tokens	32T tokens
上下文长度	1M tokens	1M tokens
最大输出长度	384K tokens	384K tokens
计算精度	FP4 + FP8 混合精度	FP4 + FP8 混合精度
定位	复杂智能体、专业代码生成	日常对话、高并发 API 调用

三、六大核心技术创新

1. 混合注意力机制（CSA + HCA）

CSA（Compressed Sequence Attention，压缩序列注意力）与 HCA（Heavily Compressed Attention，重度压缩注意力）协同工作
效果：在 1M 上下文下，相比 V3.2：
- 单 token 推理 FLOPs 降至 27%（降低 73%）
- KV Cache 占用降至 10%（减少 90%）

2. DSA 稀疏注意力（DeepSeek Sparse Attention）

在 token 维度进行压缩，显著降低长序列处理的计算冗余
改变传统全量注意力的计算范式
实现长上下文与低算耗的统一

3. 流形约束超连接（mHC）

在深层 Transformer 中引入流形约束
抑制深层梯度弥散，提升深层信号稳定性
防止专家激活分布随深度坍缩

4. Muon 优化器

替代传统 AdamW，采用矩阵正交化的动量更新机制
在同等计算量下收敛更快、最终损失更低
在超过 32T tokens 的预训练规模下效果稳定

5. 训练与后训练 Pipeline

超大规模语料预训练 + 策略蒸馏优化
强化推理、编程与世界知识能力
支持 reasoning_effort 参数调节思考强度（high / max）

6. 长上下文效率优化

V4-Pro 单 token 计算量比 V3.2 降低 3.7 倍
V4-Flash 单 token 计算量比 V3.2 降低 9.8 倍
1M 上下文成为 DeepSeek 所有官方服务的标配

四、性能指标与评测结果

4.1 综合基准测试（V4-Pro-Max）

评测项	V4-Pro 成绩	说明
MMLU	90.1	多学科综合
MMLU-Pro	73.5	专业级推理
C-Eval	93.1	中文综合评测
GPQA Diamond	90.1	研究生级科学推理
HumanEval	76.8	代码补全
LiveCodeBench	93.5	动态代码测试
Codeforces Rating	3206	开源模型最高
GSM8K	92.6	小学数学
MATH	64.5	竞赛数学
SWE Verified	80.6%	软件工程修复（官方自测）
SWE Pro	55.4%	工程级修复
Terminal Bench	67.9	终端任务
MRCR 1M	83.5	百万级长上下文召回
CorpusQA 1M	62.0	百万级长文档问答

4.2 与头部闭源模型横向对比

基准测试	GPT-5.4	Claude Opus 4.6	Gemini 3.1 Pro	DeepSeek V4 Pro-Max
MMLU-Pro (知识)	87.5	89.1	91.0	87.5
SimpleQA (事实)	45.3	46.2	75.6	57.9
GPQA Diamond (推理)	93.0	91.3	94.3	90.1
HLE (推理)	39.8	40.0	44.4	37.7
LiveCodeBench (代码)	—	88.8	91.7	93.5
Codeforces (代码)	3168	—	3052	3206
Apex Shortlist (代码)	78.1	85.9	89.1	90.2

关键结论：

✅ 代码能力顶尖：LiveCodeBench、Codeforces、Apex Shortlist 均领先
✅ 推理能力先进：GPQA Diamond 接近竞品
⚠️ 知识类仍有差距：MMLU-Pro、SimpleQA 落后于 Gemini 3.1 Pro

4.3 代际提升（V4-Pro vs V3.2）

类别	指标	V3.2	V4-Pro	提升幅度
知识	MMLU-Pro	65.5	73.5	+8.0
事实问答	SimpleQA	28.3	55.2	+26.9
事实问答	FACTS	27.1	62.6	+35.5
代码	HumanEval	62.8	76.8	+14.0
数学	MATH	60.5	64.5	+4.0
长上下文	LongBench-V2	40.2	51.5	+11.3

核心变化：

事实问答爆发式增长（FACTS +35.5，SimpleQA +26.9）
代码能力大幅跃升（HumanEval +14.0）
长上下文能力显著强化（LongBench-V2 +11.3）

五、API 定价与商业部署

5.1 定价策略（每百万 tokens）

模型	输入（缓存命中）	输入（未命中）	输出
V4-Flash	¥0.2 / $0.028	¥1 / $0.14	¥2 / $0.28
V4-Pro	¥1 / $0.145	¥12 / $1.74	¥24 / $3.48

成本优势：

V4-Pro 输出定价约为 GPT-5.4（$15）的 1/4
V4-Pro 输出定价约为 Claude Opus 4.6（$25）的 1/7
夜间半价：北京时间 23:00—07:00

5.2 版本对比分析

维度	V3.2	V4-Flash	V4-Pro
上下文	128K	1M	1M
输入（未命中）	¥2	¥1	¥12
输出	¥3	¥2	¥24
性价比	基准	加量减价	性能溢价

Flash 版：上下文扩大 8 倍，价格更低，性价比极高
Pro 版：价格大幅上涨，目标性能敏感型企业级场景

5.3 接入与迁移

API 模型名称：deepseek-v4-pro 或 deepseek-v4-flash
接口兼容：支持 OpenAI ChatCompletions 和 Anthropic 格式
旧版停用：deepseek-chat / deepseek-reasoner 将于 2026年7月24日 停用
当前映射：
- deepseek-chat → V4-Flash 非思考模式
- deepseek-reasoner → V4-Flash 思考模式

六、国产算力适配

平台	适配状态	说明
华为昇腾	✅ 首发适配	代码从 CUDA 迁移至华为 CANN；昇腾 950PR/950DT
寒武纪	✅ Day 0 适配	基于 vLLM 框架，适配代码已开源至 GitHub
NVIDIA GPU	✅ 兼容	原生支持

战略意义：首发即适配华为昇腾（而非仅 NVIDIA），被视为在出口管制背景下 AI 算力路径多元化的重要信号。

七、开源生态与部署

开源权重：
- Hugging Face: https://huggingface.co/collections/deepseek-ai/deepseek-v4
- ModelScope: https://modelscope.cn/collections/deepseek-ai/DeepSeek-V4
技术报告：https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro/blob/main/DeepSeek_V4.pdf
开源协议：MIT（商用零门槛）
本地部署：Flash 版最低需 200GB+ 内存，普通开发者难以本地部署

八、战略与商业化动态

融资转折：DeepSeek 长期拒绝外部融资，此次于 2026 年 4 月首次启动对外融资洽谈
目标估值：200 亿美元（腾讯、阿里均参与谈判）
官方引言：「不诱于誉，不恐于诽，率道而行，端然正己。」（出自《荀子・非十二子》）

九、总结与评价

核心卖点

百万上下文普惠化：1M tokens 成为标配，通过 DSA 稀疏注意力实现低算耗
代码能力顶尖：LiveCodeBench、Codeforces 等核心代码基准领先
事实问答可靠性大幅提升：FACTS +35.5，幻觉显著减少
开源生态友好：MIT 协议，兼容 OpenAI/Anthropic API

适用场景

V4-Flash：长文本处理、高并发 API 调用、成本敏感型业务
V4-Pro：复杂 Agent 任务、专业代码生成、事实准确性要求高的场景

与闭源模型差距

⚠️ 通用知识（MMLU-Pro、SimpleQA）仍落后于 Gemini 3.1 Pro
⚠️ 复杂逻辑推理（BBH）与前代基本持平，非此代重点突破方向

信息来源：综合自 DeepSeek 官方公告、AI Insight、IT之家、投资界、小众软件、AIHub、AITOP100 等渠道，发布日期均为 2026 年 4 月 24 日。

mobile-security-2026

Fri, 24 Apr 2026 14:46:42 +0800

2026年移动端安全技术全景分析：iOS vs Android

从早期”裸奔”到多层纵深防御，移动安全到底进化了多少？

一、早期痛点回顾：那些年我们踩过的坑

痛点	早期状况	严重程度
APK反编译	`apktool + dex2jar + JD-GUI` 三件套，几分钟还原Java源码	🔴 致命
硬编码密钥	API Key、Secret直接写在代码或配置里，反编译后一目了然	🔴 致命
明文存储	SharedPreferences / SQLite明文存储，Root设备直接可读	🟠 严重
二次打包	修改APK重签名，植入广告/恶意代码再分发	🟠 严重
中间人攻击	HTTP明文传输，公共WiFi下流量可被截获	🟠 严重
iOS越狱	越狱后Keychain可被导出，App沙盒形同虚设	🟡 中等

二、Android 安全进化路线

2.1 代码保护：从裸奔到虚拟化

进化路径：ProGuard混淆 → R8优化混淆 → Native SO加固 → DEX加壳 → 代码虚拟化

技术层级	原理	防护强度	性能损耗	现状
R8代码混淆	类名/方法名/变量名替换为a.b.c	⭐⭐	几乎无	2026年已是标配底线，但仅防脚本小子
Native NDK	核心逻辑用C/C++实现，编译为.so	⭐⭐⭐	低	加密/认证等关键逻辑推荐放入Native层
DEX加壳	运行时动态解密DEX加载	⭐⭐⭐	中	主流方案，但已被多种脱壳工具针对
代码虚拟化(VMP)	将字节码转为自定义指令集，在私有VM执行	⭐⭐⭐⭐⭐	较高	2026年最强方案，逆向需理解自定义指令集
编译级加固	在LLVM编译阶段进行代码变换/混淆	⭐⭐⭐⭐	低	性能友好，兼容性好，2026年新趋势

2026年主流加固厂商：梆梆安全、360加固宝、爱加密、几维安全、网易易盾、绿盟、深信服、顶象等。技术路线正从”DEX加壳”向”虚拟化 + 编译级加固”双轨演进。

2.2 密钥保护：从硬编码到硬件级

方案	安全等级	说明
❌ 硬编码在代码/配置	不可接受	反编译即暴露，2026年已无任何借口
⚠️ 资源加密存储	低	运行时AES解密，但密钥本身仍有存储问题
✅ Android Keystore	高	密钥存储在系统Keystore中，应用进程无法直接提取密钥材料
✅ 硬件背书Keystore	极高	密钥存储在TEE/StrongBox安全芯片中，即使Root也无法提取

Android Keystore 关键特性：

密钥不可导出：密钥材料从不离开Keystore，应用只能请求加密/解密操作
用户认证绑定：可设定密钥使用必须经过生物识别/锁屏验证
密钥认证(Key Attestation)：可向后端证明密钥确实由硬件生成，非软件模拟
StrongBox：Pixel等设备配备独立安全芯片(HSM)，密钥存储在物理隔离的硬件中

// 2026年推荐的密钥生成方式 – 硬件绑定 + 生物识别绑定
val keyGenParameterSpec = KeyGenParameterSpec.Builder(
 “my_key_alias”,
 KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
)
 .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
 .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
 .setRandomizedEncryptionRequired(true)
 .setUserAuthenticationRequired(true) // 使用密钥需生物识别
 .setUserAuthenticationValidityDurationSeconds(30)
 .setIsStrongBoxBacked(true) // 强制使用StrongBox安全芯片
 .build()

2.3 数据存储保护

场景	早期方案	2026年方案
KV存储	SharedPreferences明文	EncryptedSharedPreferences（自动AES加密）
数据库	SQLite明文	SQLCipher（AES-256整库加密）+ Keystore管理密钥
文件存储	明文写入	Data Protection API（设备锁定时不可访问）
网络通信	HTTP明文	TLS 1.3 + Certificate Pinning

2.4 AAB格式与Google Play安全

2021年起Google Play强制AAB格式，带来安全变化：

不再分发完整APK：Google根据设备配置按需生成APK（split APKs），攻击者无法从商店获取完整包
Google Play App Signing：签名密钥由Google云端保管，开发者只持上传密钥，降低密钥泄露风险
Play Integrity API（替代SafetyNet）：向后端证明App未被篡改、运行在正版Android设备上

2.5 防篡改与运行时保护

技术	说明
签名校验	运行时比对APK签名哈希，检测是否被重签名
完整性校验	SHA-256校验DEX/SO文件，检测代码注入
Root/模拟器检测	检测运行环境安全性
Play Integrity API	服务端验证设备/App完整性
反调试	检测ptrace附加、调试器标志位
运行时自校验	代码运行时检查自身是否被修改

三、iOS 安全进化路线

3.1 硬件安全架构（iOS天然优势）

iOS从芯片层构建了完整的安全信任链：

Secure ROM (Boot ROM) → iBoot → Kernel → App
 ↓ ↓
Secure Enclave ←→ 内存保护引擎 ←→ 加密引擎

组件	功能	安全等级
Secure Enclave	独立协处理器，物理隔离，运行独立OS	🔐 硬件级
内存保护引擎	对Secure Enclave内存进行实时加密	🔐 硬件级
加密引擎	AES专用硬件，文件加密/解密零性能损耗	🔐 硬件级
Secure ROM	不可修改的引导代码，信任链起点	🔐 硬件级

3.2 密钥与数据保护体系

iOS数据保护层级（2026年）：

保护级别	说明	适用场景
`NSFileProtectionComplete`	设备锁定时完全不可访问	顶级敏感数据（密码、金融）
`NSFileProtectionCompleteUnlessOpen`	已打开的文件可继续读写	后台下载/上传任务
`NSFileProtectionCompleteUntilFirstUserAuthentication`	用户首次解锁后可访问	大部分App数据
`NSFileProtectionNone`	随时可访问	不推荐，仅非敏感缓存

密钥层次结构：

用户密码 → 生成Passcode Key
 ↓
Passcode Key + 硬件UID → 文件级加密密钥
 ↓
文件密钥 → 由Secure Enclave保护
 ↓
元数据 → 由文件系统密钥(DPFK)加密

每一层密钥由上一层加密保护，最终追溯到硬件UID（烧录在芯片中，不可读取）。

3.3 2026年iOS关键安全特性

特性	说明	状态
TLS 1.3强制	ATS最低加密标准升级为TLS 1.3，旧协议App将被审核拒绝	✅ 已强制
App Attest	DCAppAttestService，证明请求来自未修改的真实App	✅ 推荐
隐私清单	所有App必须声明数据收集行为，模糊描述不再接受	✅ 已强制
Keychain强制	敏感凭证必须用Keychain存储，禁止UserDefaults	✅ 强烈推荐
生物识别密钥绑定	密钥使用需经Face ID/Touch ID认证	✅ 可用
抗量子加密	Apple已在iOS中集成抗量子加密算法	🧪 推进中

3.4 App Attest 防护链

App请求 → DCAppAttestService生成加密证明
 ↓
证明包含：App的签名哈希 + 设备硬件标识
 ↓
后端验证：确认来自真实设备上未修改的App
 ↓
拒绝：模拟器/越狱/重签名App的请求

四、跨平台安全技术对比

4.1 核心安全能力对比

安全维度	Android (2026)	iOS (2026)
代码保护	混淆+加壳+虚拟化（多层级可选）	加密+App Attest（系统级保障更强）
密钥硬件保护	StrongBox HSM（部分设备）	Secure Enclave（全系标配）
TEE/安全芯片	TEE可选，StrongBox仅高端设备	Secure Enclave全系标配
密钥认证	Key Attestation	App Attest
数据加密	EncryptedSharedPreferences + SQLCipher	Data Protection + Keychain
通信安全	Network Security Config + Pinning	ATS + Certificate Pinning
完整性验证	Play Integrity API	App Attest + DeviceCheck
隐私合规	权限声明+数据最小化	隐私清单（强制）
抗量子	研究中	已集成部分算法
默认安全基线	⚠️ 依赖开发者主动配置	✅ 系统默认较高

4.2 开发者必须做的事（2026年）

Android开发者清单：

R8混淆是底线，不是终点
密钥必须用Android Keystore，绝不再硬编码
数据库用SQLCipher，KV存储用EncryptedSharedPreferences
网络全量TLS 1.3 + Certificate Pinning
高安全场景接入Play Integrity API
核心逻辑考虑Native层或加固方案
接入密钥认证(Key Attestation)防中间人

iOS开发者清单：

敏感数据用Keychain，不用UserDefaults
正确选择Data Protection级别
接入App Attest防篡改
使用CryptoKit + Secure Enclave保护密钥
提供完整隐私清单
生物识别提供回退方案
ATS严格模式，不轻易配置例外

五、鸿蒙(HarmonyOS)安全体系补充

作为中国第三大移动OS，鸿蒙的安全架构值得了解：

组件	说明
iTrustee TEE	华为自研可信执行环境，基于ARM TrustZone
安全元件(SE)	独立安全芯片，存储支付/生物数据
电子围栏	感知环境风险，主动加强数据保护
应用沙盒强化	更严格的跨应用数据隔离
分布式安全	多设备间安全认证与数据传输

六、结论：从”防不住”到”防得住”

维度	5年前	2026年
反编译难度	几分钟还原源码	虚拟化/VMP下需数周专业逆向
密钥安全	硬编码=裸奔	硬件级Keystore/Secure Enclave，Root也无法提取
数据存储	明文存本地	全链路加密，设备锁定时不可访问
通信安全	HTTP到处飞	TLS 1.3强制，证书锁定标配
完整性	随便改随便签	服务端App Attest/Play Integrity验证
默认安全	开发者全靠自觉	系统强制安全基线（ATS、隐私清单等）

核心结论：2026年的移动安全已经从”开发者自觉”进入了”系统强制+硬件兜底”的时代。早期那些硬编码密钥、明文存储、裸奔APK的问题，在当今的技术体系下已经没有借口再犯。但安全是永恒的军备竞赛——抗量子加密、AI辅助攻击等新挑战正在到来。

分析日期：2026年4月24日 | 基于公开资料整理

🐙 GitHub Trending Top 10 | 本周最热项目 (2026-04-17 ~ 04-23)

Thu, 23 Apr 2026 16:19:40 +0800

**数据更新时间：**2026年4月23日 16:18 (Asia/Shanghai)

过去一周，GitHub 上有超过 15 个项目获得显著关注。AI Agent 框架、自进化引擎和语音交互成为本周最热方向。以下是本周 Top 10 热门项目：

🥇 1. NousResearch/hermes-agent

🤖 项目地址：NousResearch/hermes-agent

**总Star：**111,776 | 本周增长：+22,083 | **Forks：**16,222 | **语言：**Python

简介：“The agent that grows with you” —— NousResearch 推出的自进化 AI Agent，能够持续学习并与用户共同成长。本周以 22,083 星的爆发式增长登顶排行榜，成为现象级项目。

指标	数值
总 Star	111,776
本周增长	+22,083
Forks	16,222
主要语言	Python

🥈 2. thedotmack/claude-mem

🧠 项目地址：thedotmack/claude-mem

**总Star：**66,029 | 本周增长：+8,739 | **Forks：**5,588 | **语言：**TypeScript

**简介：**Claude Code 的自动记忆插件，自动捕获编码会话中的操作记录，通过 AI 压缩后将相关上下文注入未来会话，显著提升开发效率。

指标	数值
总 Star	66,029
本周增长	+8,739
Forks	5,588
主要语言	TypeScript

🥉 3. multica-ai/multica

🏢 项目地址：multica-ai/multica

**总Star：**19,742 | 本周增长：+6,015 | **Forks：**2,403 | **语言：**TypeScript

**简介：**开源 AI Agent 管理平台，将编程 Agent 变成真正的团队成员——分配任务、追踪进度、累积技能，让 AI 协作成为现实。

指标	数值
总 Star	19,742
本周增长	+6,015
Forks	2,403
主要语言	TypeScript

4️⃣ Lordog/dive-into-llms

📖 项目地址：Lordog/dive-into-llms

**总Star：**33,850 | 本周增长：+4,550 | **Forks：**4,149 | **语言：**Jupyter Notebook

简介：《动手学大模型Dive into LLMs》系列编程实践教程，中文社区最受欢迎的大模型学习资源之一。

指标	数值
总 Star	33,850
本周增长	+4,550
Forks	4,149
主要语言	Jupyter Notebook

5️⃣ jamiepine/voicebox

🎙️ 项目地址：jamiepine/voicebox

**总Star：**22,595 | 本周增长：+4,495 | **Forks：**2,638 | **语言：**TypeScript

**简介：**开源 AI 语音工作室，支持声音克隆、语音输入和语音创建，让每个人都拥有自己的 AI 声音。

指标	数值
总 Star	22,595
本周增长	+4,495
Forks	2,638
主要语言	TypeScript

6️⃣ EvoMap/evolver

🧬 项目地址：EvoMap/evolver

**总Star：**6,616 | 本周增长：+4,364 | **Forks：**646 | **语言：**JavaScript

**简介：**基于 GEP（基因表达式编程）的自进化 AI Agent 引擎，通过基因、胶囊和事件实现可审计的持续进化。

指标	数值
总 Star	6,616
本周增长	+4,364
Forks	646
主要语言	JavaScript

7️⃣ lsdefine/GenericAgent

🌱 项目地址：lsdefine/GenericAgent

**总Star：**6,052 | 本周增长：+4,216 | **Forks：**655 | **语言：**Python

**简介：**自进化 Agent，仅用 3.3K 行种子代码就能自主生长出完整技能树，实现系统级控制且 token 消耗降低 6 倍。

指标	数值
总 Star	6,052
本周增长	+4,216
Forks	655
主要语言	Python

8️⃣ openai/openai-agents-python

⚡ 项目地址：openai/openai-agents-python

**总Star：**24,733 | 本周增长：+3,802 | **Forks：**3,779 | **语言：**Python

**简介：**OpenAI 官方推出的轻量级多 Agent 工作流框架，功能强大且易于上手。

指标	数值
总 Star	24,733
本周增长	+3,802
Forks	3,779
主要语言	Python

9️⃣ BasedHardware/omi

👁️ 项目地址：BasedHardware/omi

**总Star：**12,028 | 本周增长：+3,624 | **Forks：**1,857 | **语言：**Dart

**简介：**能看到你屏幕、听到你对话并给出建议的 AI 助手，软硬件结合的个人 AI 伴侣。

指标	数值
总 Star	12,028
本周增长	+3,624
Forks	1,857
主要语言	Dart

🔟 forrestchang/andrej-karpathy-skills

📋 项目地址：forrestchang/andrej-karpathy-skills

**总Star：**N/A | 本周增长：+4,550 | **Forks：**N/A | **语言：**N/A

**简介：**基于 Andrej Karpathy 对 LLM 编码陷阱的观察，提炼出的单个 CLAUDE.md 文件，用于改善 Claude Code 的编码行为。

指标	数值
总 Star	N/A
本周增长	+4,550
Forks	N/A
主要语言	N/A

📊 趋势洞察

🔥 值得关注：

自进化 Agent 全面爆发：本周 Top 10 中有 4 个项目聚焦自进化方向（hermes-agent、evolver、GenericAgent、claude-mem），”让 AI 自我进化”正从概念走向工程实践。
Karpathy 效应：基于 Karpathy 编码心得整理的 CLAUDE.md 文件一周增长 4,550 星，名人效应在开源世界依然强大。
AI Agent 管理平台崛起：multica-ai/multica 以 6,015 星/周的速度表明，”管理 AI Agent”本身正在成为新赛道。
中文开源持续发力：《动手学大模型》系列教程本周新增 4,550 星，中文技术社区的学习热情不减。

🦞 龙虾欧巴整理 | 数据来源：GitHub Trending

Hermes Agent vs OpenClaw 调研对比报告

Thu, 23 Apr 2026 13:10:48 +0800

Hermes Agent vs OpenClaw 调研对比报告

调研日期：2026年4月23日 分析维度：架构设计、核心能力、记忆系统、执行环境、安全模型、生态与社区、适用场景

一、基本信息速览

对比项	Hermes Agent	OpenClaw
开发方	Nous Research（硅谷知名AI实验室）	OpenClaw Community（PSPDFKit创始人Peter Steinberger主导）
GitHub Stars	100,000+（2026年2月上线，增长极快）	190,000+ ~ 310,000+（2024年上线，生态成熟）
许可证	MIT	MIT
诞生时间	2026年2月	2024年
技术栈	Python 3.11+	Node.js 24 + TypeScript
核心理念	自我进化 —— 越用越聪明的数字伙伴	本地优先 —— 可控、安全、可扩展的基础设施
一句话定位	你的 AI 学徒（主动学习，持续成长）	你的 AI 工作台（什么都能连，稳定可控）

二、架构设计对比

2.1 架构理念

维度	Hermes Agent	OpenClaw
设计哲学	学习循环优先（Learning Loop）	控制平面优先（Control Plane）
架构定位	Self-Improving Agent Runtime（自我改进运行时）	Local-First Enterprise Gateway（本地优先企业网关）
人机关系	Agent 自主进化，追求”越用越懂你”，人在辅助位置	人在决策链中心，追求”你定义它做什么”
取舍	牺牲绝对可控性，换取便利性与个性化	牺牲部分便利性，换取可预测性、可审计性与完整掌控

2.2 技术架构分层

Hermes Agent（Python生态）

run_agent.py：核心 Agent 编排循环
cli.py / gateway：CLI + 消息平台双入口
hermes_state.py：SQLite 会话和状态存储
environments/：RL环境、评测、数据生成
核心创新：闭环学习系统 —— 每次执行都是训练数据，自动生成并迭代可复用的 Skill

OpenClaw（Node.js生态）

网关层：消息路由、协议适配、连接管理
智能体层：Agent 引擎、工具调度、任务编排
应用层：业务逻辑、插件管理、权限控制
核心创新：三位一体分层 —— 网关/智能体/应用解耦，强调本地部署与协议适配

2.3 部署方式

维度	Hermes Agent	OpenClaw
安装命令	`curl -fsSL …/install.sh \| bash`（自动配置 uv + Python）	`npm install -g openclaw@latest`
部署要求	Linux / macOS / WSL2（Windows原生实验性）	macOS / Windows / Linux（需Node 24）
后端支持	6种后端：local、Docker、SSH、Daytona、Singularity、Modal	主要依赖Node环境运行
Serverless	原生支持（Modal / Daytona），闲置近乎零成本	无原生Serverless，需自行部署
运行成本	极低，$5/月 VPS 即可	软件免费，API费用 $10-150/月
后台常驻	支持 systemd 服务化安装	支持 `–install-daemon` 安装为系统服务

三、核心能力对比

3.1 消息平台支持

平台	Hermes Agent	OpenClaw
Telegram	✅	✅
Discord	✅	✅
Slack	✅	✅
WhatsApp	✅	✅
Signal	✅	✅
iMessage	❌	✅
微信	✅（v0.9.0+）	✅
企业微信	✅	✅
钉钉	✅	✅
飞书	✅	✅
QQ	✅（官方插件）	✅
Google Chat	❌	✅
Microsoft Teams	❌	✅
WebChat	❌	✅
Matrix	❌	✅（插件）
总计	~15+ 平台	30+ 平台

3.2 模型兼容性

维度	Hermes Agent	OpenClaw
云端模型	Nous Portal（原生OAuth）、OpenRouter（200+模型）、任意OpenAI兼容端点	Anthropic Claude（默认Opus 4.7）、OpenAI GPT系列、通义千问、豆包等
本地模型	本地 vLLM	Ollama
模型切换	通过 `hermes model` 自由切换	配置驱动，多模型调度
特色	模型无关架构	建议使用最新最强模型以获得最佳质量

3.3 自动化与工具能力

能力	Hermes Agent	OpenClaw
工具调用	原生支持，自动生成Python/JS工具包	原生支持Tool Use
浏览器自动化	完整浏览器控制（导航、点击、输入、截图、视觉分析）	自动浏览网页、填写表单、抓取数据
文件操作	支持	支持（可配置人工确认）
定时任务	内置 cron 调度器	支持
多智能体协作	并行子智能体（独立对话+终端，RPC零上下文消耗）	多智能体路由（按工作区隔离）
图像理解	支持	内置（v4.15+）
语音能力	语音备忘录转录	移动节点支持语音工作流
AI视频生成	❌	✅（v4.11+原生支持）
MCP协议	原生支持	支持

四、记忆系统深度对比

4.1 记忆架构

维度	Hermes Agent	OpenClaw
存储方式	SQLite FTS5（全文检索）+ 自动摘要压缩	纯 Markdown 文件（MEMORY.md、USER.md）+ LanceDB
用户建模	Honcho dialectic user modeling 深度用户画像	Memory Palace 式管理 + Dreaming 系统
容量管理	字符限制强制优先级排序，防止记忆膨胀	无硬性容量限制
数据归属	本地 `~/.hermes/` 目录，零云端上传	本地 `~/.openclaw/` 目录，完全透明可编辑
可干预性	自动提炼存储，人工难以直接审计底层记忆	完全透明，可直接人工编辑、审计记忆文件
跨会话能力	跨会话检索能力强，能”回忆”数周前细节	超级记忆库，你告诉它什么它就记住什么

4.2 记忆分层

Hermes Agent：三层记忆 + 主动进化

短期记忆：当前会话上下文，处理即时任务
中期记忆：跨会话积累的用户偏好、任务模式
长期记忆：通过 Skills 沉淀的永久知识，可被未来会话调用
核心特点：会主动写 Skill，教一次就会，下次同类任务自动完成

OpenClaw：Dreaming + 主动记忆引擎

自动整理：会话精华形成结构化记忆
历史导入：支持从 ChatGPT 历史记录导入记忆
记忆宫殿：Memory Palace 式管理，可按天分文件管理
核心特点：超级记忆库，但不会自己创造新知识

4.3 记忆系统评分

维度	Hermes Agent	OpenClaw
跨会话持久性	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
主动学习能力	⭐⭐⭐⭐⭐	⭐⭐⭐
记忆检索速度	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
数据可导出性	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
人工可审计性	⭐⭐⭐	⭐⭐⭐⭐⭐

五、技能系统对比

5.1 技能生成方式

维度	Hermes Agent	OpenClaw
生成模式	自动生成。完成复杂任务后，Agent自动分析操作模式并创建 Skill 文件	人工编写。提供52+内置技能，新技能需用户显式创建
内置技能	40+（涵盖MLOps、GitHub、图表、笔记等）	52+（覆盖文档处理、数据分析、API集成等）
标准化	符合 agentskills.io 开放标准，可跨Agent共享	技能平台带有安装门控和UI管理
示例	连续三次执行”PDF转Markdown存入Obsidian”后，自动生成可复用脚本	需通过界面或配置手动定义新技能及触发规则

5.2 技能生态

Hermes：社区技能库支持从 agentskills.io 安装第三方技能；技能数量随使用自动增长，无上限
OpenClaw：社区插件/技能丰富；可让AI辅助写新技能；插件归档SHA-256校验

六、安全模型对比

6.1 安全机制

维度	Hermes Agent	OpenClaw
执行隔离	默认沙盒隔离 + Docker容器（no-new-privileges、cap-drop ALL等硬化参数）	依赖部署环境，无默认沙盒描述
审批策略	三模式（manual/smart/off）× 四方式（once/session/always/deny）	可配置”所有文件操作必须人工确认”、”敏感数据访问需二次验证”
访问控制	MCP凭证过滤 + 上下文文件注入扫描（防prompt injection）	RBAC角色权限 + 显式allowlist白名单 + 群组提及规则
审计能力	—	全量审计日志 + exec-policy CLI审计命令执行
多租户	—	多租户隔离
隐私保护	零遥测、零数据收集	本地存储天然隐私保护
SSRF防护	—	浏览器工具SSRF防护

6.2 安全哲学

Hermes：侧重环境隔离与隐私保护，五层防线设计
OpenClaw：侧重人在回路（Human-in-the-loop），企业级RBAC + 审计合规

七、生态与社区

维度	Hermes Agent	OpenClaw
GitHub增长	2个月从0到100k+ Stars，增速+204%	长期积累，190k-310k Stars，目前增长最快的开源AI项目之一
中文社区	中文文档完善，有微信社区	中文社区非常活跃，文档齐全
企业支持	Nous Research 背书（融资过亿美元）	社区驱动，PSPDFKit创始人主导
争议事件	曾被国内团队指责抄袭EvoMap（Nous否认）	前身Clawdbot/Moltbot
第三方集成	QQ Bot官方合入，支持国产大模型（智谱、Kimi、MiniMax）	支持DeepSeek、豆包等国产模型

八、选型建议

8.1 选择 Hermes Agent，如果你：

✅ 追求AI主动进化：希望AI越用越聪明，能自动沉淀经验
✅ 低成本快速启动：$5/月VPS即可运行，适合个人开发者
✅ 极简主义：不想折腾复杂配置，偏好”约定优于配置”
✅ 微信/国内平台优先：需要微信、企业微信、QQ等国内平台接入
✅ MLOps/AI训练：需要批量生成工具调用轨迹、强化学习训练支持
✅ Serverless部署：需要Modal/Daytona等原生Serverless支持

8.2 选择 OpenClaw，如果你：

✅ 多平台全覆盖：需要同时接入30+平台（含iMessage、Teams、Matrix等）
✅ 企业级稳定：需要RBAC权限管理、审计日志、多租户隔离
✅ 工作流编排：追求复杂多Agent协作与任务编排
✅ 完全可控：偏好”显式优于隐式”，需要精细控制每个环节
✅ 团队使用：需要团队协作、知识沉淀与长期维护保障
✅ 多模态扩展：需要AI视频生成、移动节点（Canvas/相机/语音）
✅ 记忆可审计：需要直接编辑、审计AI的记忆文件

8.3 三层选型决策框架

判断层	条件	推荐
第一层：看需求	个人效率工具 / 单平台（微信）	Hermes Agent
	团队协作平台 / 多平台（3+）	OpenClaw
第二层：看资源	预算有限（<$10/月）/ 不想折腾	Hermes Agent

如果你需要一个 ”什么都能连的AI工作台” —— 选 OpenClaw。

两者都是MIT开源、社区活跃的优秀项目，可根据实际场景灵活选择，甚至在未来生态互通后组合使用。

参考来源：

Hermes Agent 官方文档：https://hermes-agent.org/zh/
OpenClaw 官方文档：https://docs.openclaw.ai/zh-CN
OpenClaw 官网：https://openclaws.io/zh/
腾讯云开发者社区、123AI、喵斯基部落等第三方对比分析

顶级开发团队设计的Harness工程项目源码什么样 – 腾讯技术工程的文章

Fri, 10 Apr 2026 23:17:56 +0800

技术教科书： – 知乎
https://zhuanlan.zhihu.com/p/2025587980832634840

The bitter lesson

Wed, 18 Mar 2026 09:57:48 +0800

理查德·萨顿（Richard S. Sutton，现代强化学习之父，现任加拿大阿尔伯塔大学教授） http://www.incompleteideas.net/IncIdeas/BitterLesson.html

2019年3月13日

过去70年人工智能研究领域最重要的一堂课是，**只有通用计算方法最终是最有效的，而且优势巨大。**根本原因是摩尔定律，更确切地说是，每个计算单元的成本持续呈指数下降。大多数人工智能研究都是假设 Agent 可用的计算量是恒定的（在这种情况下，利用人类知识将是提高性能的唯一方法之一），但是，从较长的时间看，不可避免地会产生大量的计算量。为了在短期内获得有所作为的改善，研究人员试图利用该领域内的人类知识。但长远来看，唯一重要的是利用算力。这两者不必相互对立，但在实践中它们往往会相互对立。时间投入到一种方法上，就没办法投入到另一种方法上，这是对投入一种或另一种方法的心理承诺。而人类知识往往很复杂，不太适合利用好通用算力。有很多的例子表明人工智能研究人员迟迟未能学习这个苦涩的教训，回顾一些最突出的例子很有启发性。

在电脑国际象棋中，1997年击败世界冠军卡斯帕罗夫的方法基于大规模的深度搜索。当时，大多数计算机国际象棋研究人员对此感到沮丧，他们一直致力于利用人类对国际象棋特殊结构的理解的方法，当一种更简单的、基于搜索的、结合特殊的硬件和软件的方法，被证明更有效时，这些基于人类知识的国际象棋研究人员没有虚心接受失败，他们反驳道，“蛮力”搜索可能这次赢了，但这不是一种通用的策略，而且也不是人们玩国际象棋的方式。这些研究人员希望基于人类的行棋思路能够获胜，当没有获胜时他们感到失望。

在电脑围棋中，也出现了类似的研究进展，只是比国际象棋晚了20年。最初的巨大努力是想办法利用人类知识（一千年的棋谱），或围棋游戏的特殊特征，避免用蛮力搜索，但是所有这些努力都被证明是无关紧要的。更糟糕的是，一旦有效地进行了大规模搜索，以及，使用自我对局来学习价值函数（就像在许多其他游戏中一样，在国际象棋中也是如此，尽管这种学习在1997年首次击败世界冠军的项目中并没有发挥重要作用），之前的努力都是负向的。**通过自我对局以及通用学习来学习，就像搜索一样，因为它能够进行大规模的计算。**在电脑围棋、电脑国际象棋中，研究人员最初的努力是利用人类的理解（更少的搜索），直到很久以后，通过拥抱搜索和学习，才取得更大的成功。

在语音识别方面，在1970年代，由DARPA（美国国防部高级研究计划局）赞助了一项早期的竞赛。参赛者包括许多利用人类知识的特殊方法——单词、音素、人类声道等等知识。另一方面是更具统计学意义的方法，基于隐马尔可夫模型（HMMs）进行了更多的计算。**再次，统计学方法战胜了基于人类知识的方法。**这导致了几十年来所有自然语言处理的重大变化，统计学和计算逐渐开始主导该领域。最近深度学习在语音识别领域的兴起是朝着这一方向迈出的最新一步。深度学习方法对人类知识的依赖程度更低，使用更多的计算，加上在巨大的训练集上的学习，以产生更好的语音识别系统。正如游戏中一样，研究人员总是试图让系统按照他们自己的大脑工作的方式工作 —— 他们试图将这些知识放入他们的系统中 —— 但事实证明，当大规模计算变得可用并找到了一种充分利用摩尔定律的方法时，这最终会适得其反，并且浪费了研究人员的时间。

在计算机视觉领域，也存在类似的模式。早期的方法把视觉想象成寻找边缘，或广义柱，或以SIFT特征的形式。但今天，这一切都被抛弃了。现代深度学习神经网络仅使用卷积和某些不变性的概念，并且表现得更好。

这是一个重要的教训。纵观整个人工智能领域，我们仍然没有彻底地吸取它，因为我们继续犯同样的错误。为了看到这一点，并有效地抵制它，我们必须理解这些错误的吸引力。我们必须吸取苦涩的教训，即把我们认为的思维方式构建到系统中是行不通的。

苦涩的教训是基于历史观察：

1）人工智能研究人员经常试图将知识构建到他们的 Agent 中；

2）这在短期内总是有帮助的，并且对研究人员来说是个人满意的；

3）但从长远来看，它总会达到一个瓶颈，甚至会阻碍进一步的进展；

4）突破性的进展最终是通过一种相反的方法实现的，这种方法基于通过搜索和学习来扩展大规模计算。

最终的成功中夹杂着一丝苦涩和消化不全，因为它比受青睐的、以人为本的方法更成功。

从苦涩的教训中学到的一件事是通用方法的巨大力量，即随着可用算力变得非常大，这些方法会随着计算量的增加可以继续扩展。可以以这种方式近乎无限扩展的两种方法是搜索和学习。

从苦涩的教训中学到的第二个普遍观点是，人类心灵的实际内容是极其复杂的，我们不应该再试图找到简单的方法来思考心灵的内容，比如简单地思考空间、物体、多重主体或对称性。所有这些都是任意的、内在复杂的外部世界的一部分。它们不应该被构建，因为它们的复杂性是无止境的；相反，我们应该只构建可以找到和捕获这种任意复杂性的元方法。这些方法的关键是它们可以找到很好的近似值，但算法应该是基于我们的方法，而不是我们已经学到的知识。我们希望人工智能 Agent 能够像我们人类一样去发现，而不是在系统里集成我们已经发现的东西。建立在我们已知发现之上只会让我们更难看到如何完成发现过程。

视频模型论文精读-摘要上

Wed, 04 Mar 2026 16:17:23 +0800

论文精读·55上 https://www.youtube.com/watch?v=5MGq7dSOghY

介绍了sora，然后大篇幅讲解了数据集提取的过程。下面补充kimi的总结

三、条件生成技术分类

输入类型	技术难点	代表工作	关键创新
文本→视频	文本与视觉对齐、复杂场景理解	Sora, Lumiere, Movie Gen	使用LLM生成详细视频描述作为训练标注
图像→视频	保持参考图像ID一致性、合理运动预测	EMO, AnimateAnyone, MergeTalk	ReferenceNet结构保持身份一致，音频驱动表情
音频→视频	唇形同步、表情自然度、头部运动	EMO, Wav2Lip, DreamTalk	弱控制信号（速度层+面部定位器）避免过度约束
视频→视频	风格迁移、内容编辑、一致性保持	Video Editing, Runway Gen-3	基于扩散的编辑保持原视频结构

四、数据工程与训练策略

数据筛选流程（以Stable Video Diffusion为例）：

多阶段训练：文本到图像预训练 → 视频预训练 → 高质量视频微调
标注策略：使用内部多模态LLM生成详细视频描述，而非简单caption
过滤策略：
- 美学评分过滤低质量视频
- 光流分析确保足够运动幅度
- 文本-视频对齐评分

训练技巧：

分阶段训练：先训练图像生成能力，再引入时间模块学习运动
CFG（Classifier-Free Guidance）：训练时随机丢弃条件（如文本），推理时可调节指导强度
解耦训练：如EMO模型中，速度层与音频层分开训练，避免音频驱动能力被破坏

五、评估指标

表格

指标	用途	说明
FVD (Fréchet Video Distance)	视频整体质量	衡量生成视频与真实视频分布差异
FID (Fréchet Inception Distance)	单帧质量	评估生成帧的视觉保真度
SyncNet	唇形同步	音频-视频同步性评估
E-FID (Expression-FID)	表情丰富度	通过3D人脸重建提取表情参数计算
S/S Ratio	生成效率	计算秒数/视频秒数，实时生成为1.0

六、2024-2025年关键趋势

实时生成：LTX-2 (Fast)实现<1.0 S/S比率，接近实时生成，开启交互式应用可能
长视频突破：从秒级到分钟级生成，重点解决角色一致性和情节连贯性
多模态控制：从纯文本提示向草图、关键帧、相机轨迹、音频等多条件控制演进
开源追赶：CogVideoX、HunyuanVideo、Mochi等开源模型性能接近闭源商业模型
专业化细分：虚拟试衣、手术视频生成、数字人对话等垂直领域模型涌现

MovieGen 数据规模概览

表格

数据类型	规模	说明
图像-文本对	O(1B) / 10亿级	用于联合训练（Joint Training）
视频-文本对	O(100M) / 亿级	4-16秒片段，单镜头拍摄
音频数据	O(100K)小时	包括音效、音乐、语音组合
标注来源	LLaMa3-Video (8B & 70B)	平均100词详细描述

🔄 数据策划流程（3+1阶段）

MovieGen采用多阶段严格筛选策略，而非简单爬取：

阶段1：视觉过滤（Visual Filtering）

应用6层过滤器确保基础质量

：

分辨率：最小边≥720px（后提升至768px用于高分辨率训练）
宽高比：60%横屏(16:9) + 40%竖屏(9:16)，偏好横屏因其时长更长、运动更稳定
OCR过滤：内部OCR模型检测，剔除文字过多的视频（得分>0.6的过滤）
美学评分：使用LAION aesthetics模型，剔除评分<4的片段
边框检测：基于一阶导数扫描算法，检测并剔除带黑边的视频（常见于竖屏转横屏内容）
视觉特效过滤：训练简单模型识别过度后期制作的片段

阶段2：运动过滤（Motion Filtering）

解决视频生成中的”抖动”和”PPT效应”

：

运动向量分析：使用FFmpeg提取运动向量，剔除静态或PPT式切换视频
抖动检测：PySceneDetect检测镜头边界，剔除>0.85 shots/second的过度抖动片段
场景分割：使用FFmpeg场景检测，从原始视频（平均28秒）提取4-16秒单镜头片段，确保50%以上训练片段时长在6-15秒之间

阶段3：内容过滤（Content Filtering）

语义去重：使用copy detection embeddings（Pizzi et al., 2022）进行视觉去重
聚类采样：在语义空间聚类后采样，避免数据倾斜
人工动词分类：建立600个人类动词和表情分类体系，通过zero-shot检索筛选含人类视频，并保持这些视频的采样频率

阶段4：标注与增强（Captioning）

双模型标注：70%使用LLaMa3-Video 8B，30%使用70B版本，生成平均100词的详细描述
相机运动标注：训练16类相机运动分类器（zoom-out, pan-left等），高置信度预测结果前缀到文本提示中，实现推理时的显式相机控制
FPS控制：在文本提示前添加”FPS-16″等token，支持16-32 FPS可变帧率生成

🗂️ 分桶策略（Bucketization）

为处理多宽高比和多时长，MovieGen采用动态分桶而非固定尺寸裁剪

：表格

维度	分桶策略
宽高比	5个桶（包括横屏、竖屏、方形等），支持1024×576到576×1024
时长	5个桶（4s-16s），对应潜在帧数16-32帧
帧率	通过FPS token控制，支持16-32 FPS

这种设计允许同一批次（batch）内的视频具有完全相同的潜在空间形状（latent shape），便于并行训练。

👤 个性化视频数据（PT2V）

针对”特定人物生成”任务，MovieGen构建了专门的训练集

：

筛选标准：从预训练数据中筛选单人脸视频，使用ArcFace计算连续帧相似度（阈值>0.5）
成对数据（Paired）：从同一视频中均匀采样5帧作为参考图像，构建O(10M)样本
交叉成对数据（Cross-Paired）：
- 真实数据：O(10K)对，同一人不同视频/视角
- 合成数据：O(1M)对，使用预训练个性化图像模型生成不同表情/姿态/光照的参考图像（ArcFace相似度>0.7筛选）
目的：防止模型学到”复制粘贴”捷径（即直接复制参考图像的表情和姿态，而非遵循文本指令）

🎵 音频数据策划

MovieGen Audio（13B模型）的数据处理

：表格

音频类型	规模	筛选标准
纯音效	O(100M)	使用Audio Event Detection (AED)标签筛选
音乐	O(10M)	高质量音乐数据
音效+音乐	O(10M)	混合类型
含语音	O(10M)	单独处理，避免干扰

质量控制：

使用CAVTP（Class-Agnostic Video-Text Pre-training）分数筛选diegetic（画面中可见声源）或mixed音频
优先学习物理音效（物体碰撞、摩擦等），因其错误最明显
剔除含OCR文本、静态画面、低分辨率(<480px)的视频
视频长度限制在4-120秒

🎯 微调阶段数据（Fine-tuning Data）

预训练后，MovieGen使用小规模但更高质量的数据进行微调

：

人工策划：手动筛选高美学质量、流畅运动的视频
自动过滤：对美学、运动、场景变化设定更严格阈值，剔除小主体视频
概念平衡：使用k-NN方法检索视频，确保600个人类动词/表情分类均衡覆盖
光照与色彩：人工筛选角度光照、鲜艳色彩、无杂乱背景、无VFX的视频
标注精修：人工精修LLaMa生成的标注，选择视频中最具吸引力的片段

💡 数据工程关键创新点

渐进式质量筛选：从O(100M)原始视频逐步筛选到最终训练集，而非一次性过滤
合成数据增强：在个性化任务中使用合成数据扩展姿态多样性，解决数据稀缺问题
多模态标注：结合视觉分类器（相机运动）、LLM（详细描述）、人工审核三层标注体系
时空联合分桶：统一处理图像和视频数据（1:10比例混合），支持可变时长和宽高比
任务特定数据构造：针对不同能力（T2V、个性化、编辑、音频）构建专门数据集，而非混用

重点总结：MovieGen的成功不仅源于30B参数的模型规模，更依赖于严格的数据质量控制流程——从10亿级图像和亿级视频中，通过6层视觉过滤、运动过滤、内容去重，最终筛选出高质量子集。这种”质量优于数量”的策略，配合LLaMa3-Video生成的详细标注（平均100词），是其生成质量超越Runway Gen3和Sora的关键因素之一

。

图片视频代码，全领域突破的到来

Fri, 27 Feb 2026 12:09:09 +0800

1.春节开始，图片视频的制造整体上了台阶。不仅能参考图片、理解提示词，而且生成的作品几乎不在有明显违反逻辑的地方。

2.代码工具，在最近几个月突飞猛进。之前一直当辅助能力，现在很多公司居然使用率到90%+以上。

3.在这些能力之上，场景会有非常大的突破。

x-algorithm

Thu, 22 Jan 2026 11:29:17 +0800

X For You Feed Algorithm

基于Grok-1同款Transformer架构打造，能通过学习你的历史互动行为（点赞/回复/转发过什么），来决定给你推荐什么内容。

从用户打开“For You”开始，客户端会向服务器发送一个请求，触发整个算法流程。

然后系统会先做一件事——搞清楚你是谁、你最近在干什么、你平时对什么内容有反应。

为实现这一目的，系统会拉取两类用户信息：

行为序列（Action Sequence）：一类代表最直接、最强烈的兴趣信号，比如最近点赞、回复、转发、点进、停留过什么。
属性（Features）：另一类代表长期属性，比如关注列表、声明的兴趣主题、地理位置、使用设备等。

这一步的目标并不是人工构造特征，而是尽可能真实地构建“实时用户画像”——

以前工程师可能会假设“某些属性很重要”，然后手动编写规则或公式去计算一个“用户兴趣得分”。

但这本质上是工程师的猜想，而非用户真实状态的反映。

于是马斯克的这套算法就决定不做任何预设假设，而是尽可能多地、原始地收集用户最真实的行为反应，然后将这堆数据直接喂给后续的模型，从而让模型自己去从原始数据中学习和发现规律。（即“去人工化”和“端到端”）

而拿到实时用户画像后，系统会接着兵分两路，从整个平台的海量推文中快速筛选出几千条“可能相关”的推文。

一条是通过熟人圈。即从Thunder模块，直接抓取你关注的所有人的最新推文。

另一条是通过外部。利用Phoenix Retrieval这一核心检索模块，抓取那些你可能感兴趣、但来自未关注账号的推文。

以上两类来源不同的信息，会在后续阶段被统一对待。

需要提醒，此时筛选出来的还只是推文ID。

于是系统会通过Hydration模块，补全每条候选推文的信息，包括推文全文、作者详情、图片/视频、历史互动数据等，以便后续深度评估。

而且在正式开始计算前，还会进一步通过Filtering模块淘汰那些明显不要的内容，例如：

重复或过期的帖子
用户自己发布的内容
来自拉黑或静音账号的帖子
包含用户屏蔽关键词的内容
已经看过或在当前会话中展示过的帖子
用户无权限访问的订阅内容

记住，这一步只做一件事：回答某条内容“能不能出现，而不是值不值得推荐”。

铺垫到这里，最终剩下来的内容会被逐条送入Phoenix排序模型进行打分。

这个模型是一个基于Transformer的模型，它会同时接收：

用户的行为序列与属性信息
单条候选帖子的内容与作者信息

然后模型会预测用户对某条推文执行各种操作的概率，并将各种概率按照预设权重进行加权组合（如点赞类正向行为加分、拉黑类负向行为减分），并形成最终排序分数。

基于此，系统还会进行少量工程层面的调节——

比如控制作者多样性，避免单一账号在信息流中占据过高比例（防止某一大V刷屏）。

这里也需要提醒，为了保证送入的每条帖子都是独立评分的，所以系统还特意设置了“不允许候选帖子相互看见”（推文之间没有交叉注意力机制）。

所有候选帖子按最终得分排序，系统从中选出Top-K条帖子，作为本次请求的推荐结果。

而且在返回客户端之前，系统还会进行最后一轮校验，确保内容符合平台安全规范——

例如，移除任何已删除、被标记为垃圾信息或包含暴力血腥等违规内容的推文。

最终，经历重重筛选后的信息会根据分数高低，依次展示给客户端用户。

总结下来，这套系统能够成功运转的五大关键在于（官方划重点版）：

（1）纯数据驱动，拒绝人工规则。

彻底摒弃人工定义“什么内容算好”的复杂规则，改由AI模型直接从原始用户数据中学习。

（2）采用候选隔离机制，独立评分。

AI模型在给内容打分时，每条内容“看不见”其他候选内容，只能看到用户信息。这确保了每条帖子的分数不会因为同批次其他帖子而变化，分数一致且可高效缓存复用。

（3）哈希嵌入，实现高效检索。

检索和排序都使用多个哈希函数进行向量嵌入查找，提高效率。

（4）预测多元行为，而非单一分数。

AI模型不直接输出一个模糊的“推荐值”，而是对多种用户行为同时预测。

（5）模块化流水线，支撑快速迭代。

整个推荐系统采用模块化设计，各个组件可以独立开发、测试、替换。

ref https://zhuanlan.zhihu.com/p/1997284494198196220

manus六大上下文工程

Sun, 11 Jan 2026 10:53:12 +0800

Manus之所以能从众多Agent创业公司中突围，并非因为它拥有更强的模型，而是它重新定义了模型与上下文交互的方式。在 planning-with-files 项目的 reference.md 中，详细记录了这六大原则：

文件系统作为外部记忆 (Filesystem as External Memory)

原理：不要依赖易失的Context Window。将磁盘视为无限的“外挂内存”，只在Context中保留文件路径。

通过重复进行注意力操纵 (Attention Manipulation Through Repetition)

原理：对抗“Lost in the Middle”。在关键决策前反复读取计划文件，强行刷新模型的“注意力权重”。

保留失败痕迹 (Keep Failure Traces)

原理：错误是宝贵的资产。显式记录失败尝试，让模型通过“反思”避免死循环，而不是掩盖错误。

避免少样本过拟合 (Avoid Few-Shot Overfitting)

原理：在重复性任务中引入受控变体，防止模型陷入机械式的幻觉。

稳定前缀优化缓存 (Stable Prefixes for Cache Optimization)

原理：通过固定的文件结构和前置指令，最大化KV-Cache命中率，降低Token成本。

只增不改的上下文 (Append-Only Context)

原理：尽量以追加（Append）而非修改（Modify）的方式更新信息，维护上下文的连贯性。

架构落地：三文件模式

planning-with-files Skill将上述抽象原则具象化为一套严格的 “三文件工作流”。

当这个Skill被触发时（例如你要求“帮我策划并开发一个贪吃蛇游戏”），它会强制Claude在当前目录维护三个文件：

1. `task_plan.md`（指挥塔寄存器）

这是整个架构的核心。它不存储具体知识，只存储元数据。

作用：定义目标、拆解阶段、追踪进度、记录错误。
关键机制：它是Agent的“罗盘”。无论任务进行到第几步，Agent必须在每次行动前读取此文件。

2. `notes.md`（知识库堆内存）

作用：存储调研笔记、网页摘要、中间代码。
关键机制：“Store, Don’t Stuff”。当Agent搜索到大量资料时，禁止直接输出到对话框，必须写入此文件。这保持了对话上下文的清爽。

3. `[deliverable].md`（产出物 IO缓冲区）

作用：最终的交付结果（如 game.py 或 report.md）。
关键机制：将“思考过程”与“最终结果”物理隔离。

此时，无状态（Stateless）的LLM第一次拥有了“状态”。

阶段1：Read-Before-Decide（对抗遗忘）

在开始写任何代码之前，Skill强制Claude执行 read_file task_plan.md。这一步至关重要。

如果没有这一步，Claude可能会基于上文的闲聊或20轮之前的记忆开始瞎猜。
有了这一步，Claude的Context尾部被注入了最新的状态：“我现在处于Phase 2，目标是修改Login接口，且之前在Phase 1已经确认了Token格式。”
这相当于在每次CPU时钟周期开始时，强制执行一次Fetch Instruction。

阶段2：Data Offloading（数据卸载）

Claude需要查阅OAuth2.0的最新协议。

传统模式：Claude搜索网页，把5000字的协议全文塞进对话框。你的Token在燃烧，模型被无关信息淹没。
本模式：Claude搜索网页，提炼核心参数，写入 notes.md。在对话框里，它只说：“协议参数已存入notes。”
这相当于操作系统的**Swap机制,**把不常用的数据换出到磁盘，保持主存（Context Window）的清爽。

阶段3：State Commit（状态固化）

代码修改完成，测试通过。Claude必须编辑 task_plan.md：

将 [ ] Phase 2 改为 [x] Phase 2。
更新 Status 到 Phase 3。这相当于Write Back。它赋予了LLM**时间感，**明确地知道什么是“过去”（已完成），什么是“未来”（待完成）。

它解决了什么？

这套Skill不是为了炫技，而是精准打击了LLM在长程任务中的四大死穴：

痛点1：易失性记忆 (Volatile Memory)

现象：多轮对话后，Claude code忘了之前定义的变量或需求。
解法：文件系统持久化。即使对话Session重置，只要 notes.md 和 task_plan.md 还在，Agent就能瞬间“恢复记忆”，继续工作。

痛点2：目标漂移 (Goal Drift)

现象：执行50步后，Claude code沉迷于细枝末节，忘了原始目标。
解法：Read-Before-Decide（行动前读取）。
- Skill强制规定：Before major decisions, READ task_plan.md。
- 利用Transformer的近因效应，刚读入的Plan处于Context最末端，权重最高，时刻提醒Agent“不要跑偏”。

痛点3：隐藏错误 (Hidden Errors)

现象：API调用失败，Claude code默默重试，导致死循环或成本爆炸。
解法：Error Persistence（错误持久化）。
- task_plan.md 中包含 ## Errors Encountered 章节。
- Agent被要求将所有失败显式写入。下次读取计划时，它会看到“路径A失败过”，从而自动推理出路径B。

痛点4：上下文填充 (Context Stuffing)

现象：把无关紧要的搜索结果全塞进Context，导致模型变笨、变慢、变贵。
解法：Offloading（卸载）。
- 所有长文本默认进 notes.md。Context中只保留一句：“已将搜索结果存入notes.md，关键点如下…”。

https://github.com/OthmanAdi/planning-with-files

Video models are zero-shot learners and reasoners

Wed, 31 Dec 2025 10:05:44 +0800

论文总结：《Video models are zero-shot learners and reasoners》

基本信息

标题：视频模型是零样本学习者和推理器
作者：Robert Geirhos 等
发表：arXiv, 2025年9月
核心：首次系统性展示视频生成模型（Veo 3）作为通用视觉基础模型的潜力

核心观点

这篇论文提出了一个重要命题：像 Veo 3 这样的 视频生成模型不仅仅是视频生成器，它们正在演变为通用的视觉基础模型，具备强大的零样本学习和初步的视觉推理能力。

类比：就像 LLM 在文本任务上展现出的通用性一样，视频模型可能也在走向类似的通用视觉理解之路。

主要实验与发现

论文测试了 Veo 3 在 10+ 个不同视觉任务上的表现，这些任务都不是它明确训练过的：表格

复制

任务类别	具体任务	能力体现
视觉理解	语义分割、边缘检测、深度估计、法向量估计	理解图像的语义结构和几何信息
物理理解	判断物体是否易碎/可滚动/可拉伸	从视觉外观推断物理属性
功能理解	识别物体可供性（affordance）	理解物体的功能和潜在用途
视觉操作	图像编辑（替换/移除对象）、风格转换	精确操控视觉内容
物理模拟	模拟工具使用（剪草、敲钉子、榨汁）	模拟动态物理交互
视觉推理	迷宫求解、对称群判断	基于视觉信息进行推理和决策

关键发现：

零样本能力惊人：无需微调，仅通过设计合适的提示词（prompt）就能完成上述任务
多模态理解：能将自然语言指令与视觉内容精确对应
初步推理能力：能进行简单的规划和决策（如迷宫路径规划）
一致性：生成结果稳定可靠，优于许多专用模型

方法

核心技巧：“Video-as-Prompt”
- 将输入图像作为第一帧
- 通过文本提示描述期望的变换/分析/模拟
- 让模型生成后续帧来实现任务

示例：

分割任务：提示 “A person is segmenting the dog by painting over it in red”
物理模拟：提示 “A pair of scissors is cutting through the grass”

影响与意义

范式转变：视频模型可能取代专用视觉模型，成为通用视觉理解引擎
新评估维度：需要重新思考如何评估”通用视觉模型”
应用前景：统一的模型可简化视觉AI系统开发

局限与未来工作

定量评估有限：目前主要是定性展示，缺乏大规模定量评测
计算成本：视频模型通常比专用模型更昂贵
理论理解不足：对其内部机制的理解还很初步
扩展性问题：能力是否随模型规模持续提升尚需验证

总结

这篇论文是一个概念性验证，它表明：

视频生成模型不仅仅是生成工具，它们正在成长为能够理解、分析和推理视觉世界的通用智能体。

这为未来统一的视觉-语言-动作模型铺平了道路，类似于 LLM 统一了 NLP 领域。如果这一趋势继续，我们可能会看到”视频模型时代的 ImageNet时刻”。

一、核心思想：视频模型的”GPT-3时刻”

1.1 历史类比与范式洞察

论文开篇就点破天机：NLP领域从专用模型（翻译、问答、摘要各用各的）到统一LLM的转变，源于三个简单要素：

大规模模型（scale）
生成式训练（generative objective）
互联网级数据（web-scale data）

作者发现：视频模型正在复刻完全相同的配方。Veo、Sora等模型训练目标很简单——”根据文本生成下一帧”，但就像”预测下一个token”催生了通用语言理解，”预测下一帧”可能正在催生通用视觉理解。

核心论断：视频模型不是简单的”视频生成器”，而是视觉世界的通用模拟器。

1.2 极简方法论：Video-as-Prompt

整个研究的方法论惊人地简单：

输入图像 + 自然语言指令 → 生成视频 → 完成任务

这被称为”Video-as-Prompt”，它完美复刻了LLM的prompting范式。关键创新在于：将静态任务转化为时序过程，让模型通过”思考帧序列”来解决问题，作者称之为 Chain-of-Frames (CoF) ，直接类比LLM的CoT。

二、四层能力体系：从感知到推理

论文构建了精妙的能力金字塔，层层递进：

2.1 第一层：感知（Perception） ——理解视觉信息

这里展示了18个零样本任务，分三类：

经典CV任务（图10-16）

边缘检测：在BIPEDv2数据集达到0.77 OIS，有趣的是，Veo生成的边缘比ground truth还精细（树叶轮廓、轮胎纹理），这反而降低了分数——不是模型弱，是数据集低估了其理解深度
实例分割：LVIS数据集上mIoU达0.74，与专用编辑模型Nano Banana持平
超分辨率/去噪/去模糊：完美复现经典CV任务，但完全无需监督

高级感知（图17-20）

联合视觉搜索：在杂乱场景中找”红圈+蓝方块”的复合目标
错觉理解：正确识别斑点狗错觉、猫轮廓、罗夏墨迹
上下文理解：解析纹理-形状冲突图像

认知能力（图31）

世界状态记忆：放大图像后仍记得画面外的物体位置
物体恒常性：视角变化时保持物体身份

关键洞察：扩散模型的去噪目标天然包含结构理解，因此能涌现分割、边缘检测等能力。

2.2 第二层：建模（Modeling） ——构建世界模型

基于感知，Veo开始展现直觉物理和因果理解：

物理模拟（图21-24）

可燃性：正确模拟火焰蔓延到易燃物
浮力：木头浮、石头沉
空气阻力：羽毛飘落比石头慢
刚体/软体动力学：球弹跳、布料褶皱

物体交互（图25-26）

Visual Jenga：理解移除顺序的物理可行性
背包打包：判断哪些物品能放入容器

光学与抽象（图27-30）

折射/反射：准确渲染光学现象
颜色混合：正确实现加色（光）和减色（颜料）
Omniglot字符：识别模式、生成变体、笔画解析

技术突破：Veo展现的物理理解不是基于符号规则，而是从海量视频中学习的视觉物理模拟。

2.3 第三层：操控（Manipulation） ——主动改变世界

这是将理解转化为行动的能力：

图像编辑（图32-38）

精确分割与背景替换：将物体完美抠出
风格转换：照片→素描→油画，保持内容一致
涂鸦驱动编辑：根据简笔画修改图像
文本变形：将文字变形成糖果、椒盐卷饼

3D感知与视角合成（图39-43）

单图新视角合成：从一张图生成360°环绕视频
物体变形：茶杯→老鼠的平滑变形
自拍转专业照：改变光照、视角、景深

灵巧操作模拟（图44-45） 这是最惊艳的部分：

开罐：双机械手协作拧开瓶盖
抛接球：理解抛体运动、预判落点
转健身球：复杂的手指协调运动
工具使用：正确握锤、握剪刀

技术洞察：Veo的3D一致性远超传统扩散模型，这源于视频训练中的相机运动先验。

2.4 第四层：推理（Reasoning） ——跨时空的思维

这是论文的最高贡献，提出CoF框架：

空间推理（图48-52）

图遍历：模拟水在管道中流动
树搜索：可视化BFS过程
形状匹配：理解几何约束
路径连接：规划最短连接

时序规划（图53-58）

数字排序：气泡按数值从小到大消失
数独求解：4×4数独逐步填数字
迷宫导航：红圈沿白路径到绿圈（5×5迷宫78%成功率）
导航任务：机器人路径规划

规则学习（图59）

ARC风格任务：从3个示例中学习变换规则

核心创新：Chain-of-Frames 不仅是类比CoT，更是视觉推理的本质优势——LLM推理符号，视频模型推理时空。

三、定量实验：严谨的基准测试

3.1 实验规模

总生成量：18,384个视频，62个定性任务+7个定量任务
模型对比：Veo 3 vs Veo 2 vs Nano Banana vs Gemini 2.5 Pro
评估指标：Best frame / Last frame / Pass@k

3.2 关键定量结果（图3-9）

感知任务

边缘检测：Veo 3 (0.77) » Veo 2 (0.57)，接近SOTA 0.90
实例分割：Veo 3 (0.74) ≈ Nano Banana (0.73)，绿色背景比白色好（0.74 vs 0.66）——绿幕先验

操控任务

物体提取：Veo 3达93%准确率，Veo 2仅~20%
图像编辑：人类评估保真度0.63，Veo特别擅长保留纹理细节

推理任务

迷宫求解：5×5网格 Veo 3 78% vs Veo 2 14%，代际提升巨大
视觉对称：形状任务 Veo 3 88% » Veo 2 44% » Nano Banana 40%
视觉类比：颜色变换68%，但反射/旋转低于随机——系统性偏差

3.3 推理时扩展（图61）

重要发现：pass@10 » pass@1，表明并行采样+多数投票有效。但反射/旋转任务中，多数投票性能反而下降，说明模型有根深蒂固的错误偏差，这类似于LLM的”顽固幻觉”。

四、技术深度与工程洞察

4.1 提示工程科学（附录C）

论文做了系统性提示敏感性研究，在视觉对称任务上测试10个变体：

最佳提示：

“Instantly reflect this pattern along the central, vertical axis while keeping the existing colored pattern without modification.”

最差提示（性能差40-64个百分点）：

“A timelapse of a professional pixel artist drawing a symmetrical pattern…”

最佳实践原则：

明确性：指定”vertical axis”而非模糊”symmetrical”
负向约束：”keeping…without modification”防止无关修改
静态控制：”Static camera, no zoom, no pan, no dolly”
运动出口：用旋转色轮等”冻结”解决方案
速度控制：复杂任务用”step-by-step”，图像编辑用”instantly”

4.2 黑盒系统与LLM耦合

重要细节：Veo API包含LLM提示重写器，但作者验证了：

纯Gemini 2.5 Pro无法可靠解决迷宫、对称等核心任务
视觉推理能力来自视频模型本身，而非LLM

这解决了关键质疑：成果不是LLM的功劳。

4.3 成本与可扩展性

当前挑战：视频生成成本高昂。但作者引用Epoch AI数据：LLM推理成本每年下降9-900倍，视频模型将遵循同样曲线。

优化方向：

推理时扩展：pass@k优于增大模型
模型压缩：蒸馏、量化
专用硬件：视频生成加速器

五、失败案例与能力边界（附录D）

论文罕见地详细展示了失败案例：

5.1 物理理解局限

力/运动提示（图64）：无法遵循箭头标注的受力方向
瓶颈问题（图75）：高尔夫球无法通过花瓶瓶颈——尺寸关系理解失败

5.2 组合推理失败

文字搜索（图67）：无法识别”CHEAT”单词，只能高亮单个字母——符号组合能力弱
路径连接（图66）：幻觉点亮所有路径
拼图（图74）：碎片方向错误、完整性丢失

5.3 抽象推理挑战

线性方程组（图69）：产生幻觉文本
ARC类任务（图59）：规则外推能力有限

核心局限：视频模型的推理是视觉模拟式而非符号代数式，因此在需要离散符号操作的组合任务上表现不佳。

六、深层意义与批判性思考

6.1 对AGI研究的意义

论文暗示： “预测下一帧”可能是通往物理世界理解的有效路径 。这与LeCun的”世界模型”理论不谋而合——通过自监督视频预测学习常识。

关键证据：Veo展现的物理直觉不是硬编码，而是从数据中涌现的。

6.2 与LLM类比的局限性

虽然CoF类比CoT很优雅，但存在本质差异：表格

复制

维度	LLM (CoT)	Video Model (CoF)
状态空间	离散符号	连续像素
正确性判断	容易验证	难以精确评估
组合性	强（符号组合）	弱（视觉混合）
可解释性	可读取推理文本	需分析帧序列

风险：视频模型的”推理”可能是高级模式匹配，而非真正的符号逻辑。

6.3 评估危机

当前视觉评估面临ImageNet时刻2.0：

传统基准：针对专用模型设计，不适合生成式评估
新需求：需要能评估视觉计划（visual plan）的标准
主观性：人类评估成本高、一致性低

论文中的”best frame vs last frame”讨论正是这一危机的体现：我们不知道如何评估一个能生成过程的模型。

七、实践建议与未来路线图

7.1 对从业者的即刻行动

Python

复制

# Veo的Zero-shot模式模板
prompt = f"""
[任务描述：清晰、具体、无歧义]
[负向约束：保持...不变]
[运动出口：旋转色轮/进度条]
[相机控制：Static camera, no zoom, no pan, no dolly]
输入图像 + 此提示 → 生成视频 → 提取关键帧

效果提升技巧：

简单任务用instantly，复杂任务用step-by-step
添加”no glitches, no artifacts”减少伪影
对3D任务加”realistic lighting and shadows”

7.2 研究路线图

短期（6-12个月）：

基准建设：开发视频模型评估套件（类似MMLU for vision）
提示优化：自动化提示搜索（DSPy for video）
混合架构：LLM规划 + 视频模型执行

中期（1-2年）：

推理时扩展：学习LLM的self-refine、MCTS
物理 grounding：将视觉推理与真实物理模拟结合
任务蒸馏：将Veo能力蒸馏到更小模型

长期（3-5年）：

通用视觉智能体：Veo + 机器人控制 = 通用机器人
因果推理：从相关性到因果性的跨越
世界模型：视频模型作为强化学习的世界模型

八、总结：视觉的”奥本海默时刻”

这篇论文不仅是技术报告，更是宣言书。它宣告：

“预测像素”正在像”预测token”一样，成为通向通用智能的普适密码。

就像2017年Transformer统一了NLP，2025年的视频模型可能正在统一机器视觉。Veo 3的零样本能力不是终点，而是黎明前的第一缕光。

最大的启示：通用性不需要复杂的架构设计，只需要规模 + 生成目标 + 数据。简单到令人难以置信，强大到改变一切。

FSD V12

Fri, 12 Dec 2025 11:08:52 +0800

特斯拉 FSD V12 之所以被称为“自动驾驶的全新范式”，核心在于它第一次把“感知-决策-控制”整条链路压进一个端到端神经网络，用数据驱动彻底替代了人工写的规则代码，从而把自动驾驶从“工程师写逻辑”变成了“模型自己学驾驶”。具体特殊性体现在三点：

代码量从 30 万行 C++ 直接砍到 2 000 行以内，规则引擎基本消失，车辆动作由神经网络直接输出，实现“光子进、控制出”。
训练方式变成纯模仿学习：用数百万段人类驾驶视频做监督，让网络复制人类司机的“直觉”，长尾场景泛化能力大幅提升，城市复杂路况（无保护左转、施工绕行等）干预次数下降 65%。
架构上彻底端到端，消除模块化系统“层层信息丢失”的缺陷，驾驶风格更接近人类，体感丝滑，不再出现早期版本“机械式加减速”。

业界把 V12 比作“自动驾驶的奥本海默时刻”——它首次证明纯数据驱动范式在城市场景可工程化落地，标志着行业从“规则驱动”迈入“数据驱动”临界点。

下面从“团队结构”和“关键技术”两条线，把特斯拉 FSD 的“人”与“事”串起来，方便你一眼看清这套系统是怎么被做出来的，又到底新在哪。

一、团队：小而精、垂直汇报、跨学科混编

顶层：直接向马斯克汇报的是“AI & Autopilot” 副总裁 Ashok Elluswamy，他统管感知、规控、芯片、数据、仿真五大方向。
核心小组：
– 视觉与网络组：负责端到端大模型、多模态融合（视觉+语言+音频），<20 人，主力是前 OpenAI 研究员、ICCV 最佳论文得主等。
– 芯片与编译器组：2016 年成立，Jim Keller 与 Pete Bannon 带队，18 个月流片，现在迭代到 HW4.0 双 NPU（单颗 72 TOPS），功耗 <7 W。
– 数据引擎组：中美两地超 100 人做自动 4D 标注，12 小时可标 1 万段行程，相当于 500 万小时人工量。
– 仿真与验证组：用 3D Gaussian 重建+对抗生成，把真实街道秒变可编辑虚拟场景，每天跑数百万公里闭环测试。
组织特色：功能型结构、层级极扁；算法、芯片、车辆、法规同一层楼办公，保证“今天发现 bug、明天就 OTA”。

二、技术创新：从“写规则”到“学驾驶”的三级跳

端到端单网络（V12 起）：
输入 7 路 8-bit 视频流 → 直接输出转向/制动/加速，人工 C++ 从 30 万行砍到 2 000 行，消除模块化接口瓶颈，实现“光子进、控制出”。
多模态大模型（V14）：
在端到端基础上引入 VLA（Vision-Language-Action）框架，网络内部同时生成 3D 占用栅格、语言决策链（Chain-of-Thought）和控制指令，可“看懂”施工牌并“自言自语”推理出“需借道左侧”。
自研芯片 + Dojo 超算：
– FSD Chip 采用可配置 DMA 与片上 SRAM 切片，把权重预取和计算并行化，延迟 <2 ms，功耗只有 GPU 方案的 1/5。
– Dojo 用 7 nm 训练 tiles 拼成无交换机拓扑，单柜 1.1 EFLOPS，专门跑视频级无监督预训练，把 OTA 迭代周期从月缩到周。
数据闭环：
车端影子模式采集 → 云端自动标注 → Dojo 训练 → 仿真验证 → OTA 推送，全流程无人值守；长尾样本（拖车、异形障碍物）通过 Occupancy Network 在线挖掘，识别率提升 3 倍。
安全与可解释：
端到端网络在推理时会同步输出语言解释、占用栅格、语义分割三张“中间图”，供监管与工程师回溯决策路径，实现“黑盒里的灰盒”。

一句话总结：特斯拉把“芯片-数据-模型-车”四条链路全部自己做，并用端到端+多模态+语言推理把自动驾驶从“工程师写 if-then” 升级为“模型自己读视频、自己推理、自己开车”，这才是 FSD 被业内视为“新范式”的根本原因。

持仓票，让AI帮忙分析，存档等验证

Fri, 12 Dec 2025 09:41:57 +0800

穿越周期的铜箔龙头：建滔积层板2025财报透视.pptx

https://s3.ap-east-1.amazonaws.com/my-helpful-ai/public/%E7%A9%BF%E8%B6%8A%E5%91%A8%E6%9C%9F%E7%9A%84%E9%93%9C%E7%AE%94%E9%BE%99%E5%A4%B4%EF%BC%9A%E5%BB%BA%E6%BB%94%E7%A7%AF%E5%B1%82%E6%9D%BF2025%E8%B4%A2%E6%8A%A5%E9%80%8F%E8%A7%86.pptx

泡泡玛特：四季财报透视与2026增长边界.pptx

https://s3.ap-east-1.amazonaws.com/my-helpful-ai/public/%E6%B3%A1%E6%B3%A1%E7%8E%9B%E7%89%B9%EF%BC%9A%E5%9B%9B%E5%AD%A3%E8%B4%A2%E6%8A%A5%E9%80%8F%E8%A7%86%E4%B8%8E2026%E5%A2%9E%E9%95%BF%E8%BE%B9%E7%95%8C.pptx