2026.09.24 · 第 20 期这篇写的是 9 月 24 日 GitHub 热搜榜的第 6 到第 10 名,星数和名次都是当天抓的快照。
这周的榜单几乎被同一个念头占满了:前四名都在做同一件事,把原本给人用的软件,改造成 agent 能直接调用的形态。办公套件、命令行、运行沙箱、开发框架,一层比一层靠下。
这 5 个我逐个翻了 issue 区:它解决什么问题、谁适合用、踩过什么坑,一起说清楚。
💡 先把这 5 个项目和它们各自解决的问题列一遍,想快速扫的看这段就够:
- dream-num/univer — 把表格文档做成 agent 能操作的运行时（榜内第 6 名）
- HKUDS/CLI-Anything — ⌨ 让所有软件都变成 agent 能调的命令（榜内第 10 名）
- strands-agents/harness-sdk — 用几十行代码搭一个自己的 agent 框架（榜内第 9 名）
- agent-substrate/substrate — 给 agent 造一层"用完就扔"的运行底座（榜内第 8 名）
- Open-Dev-Society/OpenStock — 自己部署一个数据看板,数据自己接（榜内第 7 名）
下面按名次逐个说:它解决什么问题、issue 区里暴露了哪些坑、值不值得你上手。
1. dream-num/univer ⭐ 约 1.6 万 📊 把表格文档做成 agent 能操作的运行时（榜内第 6 名）
先说它是什么:一个 Office 套件 SDK,Apache-2.0,2022 年建库(国内团队,项目在国内技术圈知名度不低)。它把表格、文档、幻灯片、多维表、白板、PDF 放在同一个运行时里,渲染走 Canvas,有一套公式引擎,对外只暴露一套 Facade API,浏览器和 Node.js 里都能跑。现在的定位已经从"开源表格"改成了 The Office Harness for AI Agents。
评论区里看到的: 这个仓库的 issue 区有种"迁徙痕迹"。排在前面的高讨论条目都是 2024 年那批:#3684 一次加了一批统计公式(59 条讨论)、#3798 自动列宽、#1931 权限体系。也就是说,它的底层能力是一年多前在"做表格"的阶段磨出来的,现在的 agent 叙事是后来加的。139 个未关条目、最近还有提交,说明维护没停。
我的判断: 我做过表格类的需求,知道"公式引擎 + 协同 + 渲染"这三件事凑一起有多费劲,所以我不怀疑它的工程量。但它现在的宣传重心在 agent 上,而 agent 真要用起来,还得看它对工具的暴露程度。我的建议是先别当"agent 基建"看,把它当作"可以嵌进自己产品里的表格/文档内核",这个定位下它挺能打。
地址: github.com/dream-num/univer
难度:中,会用 TypeScript 就能嵌
2. HKUDS/CLI-Anything ⭐ 约 5 万 ⌨️ 让所有软件都变成 agent 能调的命令（榜内第 10 名）
先说它是什么:HKU(港大)数据智能实验室做的项目,Apache-2.0,今年 3 月建库,半年涨到 5 万星。一句话就是标题那句:Making ALL Software Agent-Native。它给各种软件套一层命令行外壳,让 agent 通过 CLI 去操作那些本来只给人类用的界面,官方还有个 CLI-Hub 站点汇总这些外壳。
评论区里看到的: issue 区全是很具体的工程问题,能看出这套东西真的在被跑:#308 把 DOMShell 的 MCP 集成升到 2.0.0,原因是原来用 npx 拉,版本没钉住,上游一发新版就漂了(40 条讨论);#233 给浏览器 MCP 调用加超时保护,解决某条命令卡死的挂起问题(25 条);#73 修多会话并发写文件时的数据竞争,抽了一个带锁的保存函数(19 条)。
这三条凑起来正好是这类项目的日常:版本漂移、超时、并发写。它不是那种靠概念涨星的项目,坑是踩在明面上的。
我的判断: 这个思路我特别认同,因为我自己的活儿就是这么干的——把要操作的东西包成命令行,再让 agent 去调。它的价值不在"包了多少个软件",而在于把这套模式标准化了。要提醒的是:5 万星涨得太快,CLI-Hub 里那些外壳的质量一定是参差的,用之前挑一两个自己验一遍,别整包信任。
地址: github.com/HKUDS/CLI-Anything
难度:中,会命令行就行
3. strands-agents/harness-sdk ⭐ 约 7900 🧰 用几十行代码搭一个自己的 agent 框架（榜内第 9 名）
先说它是什么:Apache-2.0,Python 和 TypeScript 双版本,去年 5 月建库,背后是 AWS 开源的 Strands Agents 那套东西。它主张模型驱动,几行代码就能起一个能干活的 agent;模型和云都不挑,你要接哪家都行。
评论区里看到的: 810 个未关条目,是这期里最"热"的一个。三条主线值得念:
#3474 加了 ModelRouter(67 条讨论),让一个 Agent 可以在不同模型之间路由,而不是构造时就锁死一个;#3505 加了 ContextManager(38 条),用一串可组合的策略来压缩上下文,替代原来"溢出了才反应"的做法;#900 做多 agent 的会话持久化。这三条逐层往上叠:模型层、上下文层、会话层,是一个框架从"能跑"走向"可上生产"的必经之路。
我的判断: 如果你要自己写 agent 应用,这类 SDK 比"再套一层别人的成品"靠谱,因为你需要的是能改的积木。但它也意味着你得自己承担架构决策:上下文怎么压、失败了怎么重试、会话存在哪。它给的是零件,不是答案。
地址: github.com/strands-agents/harness-sdk
难度:中高,得懂 agent 的套路
4. agent-substrate/substrate ⭐ 约 3500 🧊 给 agent 造一层"用完就扔"的运行底座（榜内第 8 名）
先说它是什么:Go 写的 agent 执行运行时,Apache-2.0,今年 5 月建库,README 里注明不是 Google 官方支持的产品(但明显出自 Google 那边)。它的指标很硬:目标是在一台机器上跑上百万个沙箱,密度是常规容器运行时的 10 倍,恢复(sub-500ms)和挂起/恢复吞吐都在几百次每秒,内核和网络默认零信任隔离,底层同时支持 microVM 和 gVisor。
它的核心假设挺聪明:agent 这类程序大部分时间是闲着的,那就把大量"演员"映射到少量"工人"上,重度复用。
评论区里看到的: #871 做出口流量的 MITM 隧道 TLS,按 SNI 现签短命证书,而且特意把签名密钥放在独立容器里,不让它落到数据平面(20 条讨论);#856 加了演员的出口策略 API;#287 是 microVM 的最小可用实现(cloud-hypervisor + kata),作者在描述里老实写着"CI 覆盖还不确定能不能在 GHA 上搞定"。
这几条都在同一个主题下:隔离与管控。当一个东西要同时跑几万个不受信任的 agent,安全和调度就是全部。
我的判断: 它解决的是真问题,但离个人用户极远——你得先有"同时跑大量沙箱"的需求。我把它写进来是因为它代表了这周榜单的下限:前面几个还在教 agent 怎么用软件,这个已经在操心几万个 agent 同时跑的时候怎么不出事。这种活看不见,但少了整个生态都站不住。
地址: github.com/agent-substrate/substrate
难度:极高,是给平台团队的
5. Open-Dev-Society/OpenStock ⭐ 约 1.9 万 🗄️ 自己部署一个数据看板,数据自己接（榜内第 7 名）
先说它是什么:一个开源的看板类 Web 应用,AGPL-3.0,TypeScript,去年 9 月建库,现在 1.9 万星。它的定位是"给那些贵得离谱的数据平台做个免费替代":自己部署、自己接数据源,界面里做实时刷新、自定义提醒、以及公司维度的信息聚合。
评论区里看到的: 这是个相对年轻、issue 不多的项目(39 个未关),但方向看得很清楚。#40 补上了自选列表和条件提醒,还接了新闻流;#81 有人提了个模拟盘模块(账号管理、组合分析、自动执行脚本),至今挂着没合;#78 在补简体中文。
我的判断: 先说清一点,这类项目我只从技术角度聊——它本质是个自建的数据看板:前端应用 + 数据源适配 + 提醒规则引擎,这套东西你换成任何领域的数据都成立。它的价值在 AGPL 带来的自由度:代码在手里,数据源能自己换。要留意的是 AGPL 对商用有传染性,放在公司里用之前先看清楚;还有它是"数据展示层",数据本身的质量和来源得你自己负责。
地址: github.com/Open-Dev-Society/OpenStock
难度:中,会部署 Web 应用就行
总结
这期的共同点比往期更集中:五个项目里有四个在把软件改造成 agent 能直接用的形态(办公套件、命令行外壳、开发 SDK、运行沙箱),剩下一个是可以自己部署的数据看板。前四个是给做产品的人准备的,后一个更像普通人能自己搭起来的东西。 我自己会试的是 CLI-Anything:我这半年干的事基本就是"把要操作的东西包成命令行",正好想看看别人是怎么把这套模式做成标准和仓库的。univer 我打算当"能嵌进产品的表格内核"记着。substrate 和 harness-sdk 我用不上,但它们代表了这个生态里正在往下沉的那两层。
如果你平时也爱逛 GitHub、想每周看到这类开源好项目，欢迎关注，我在公众号「暖心hebbie设计学习」每周更新 GitHub 热门项目推荐，开发少踩坑。
数据来源：GitHub Trending（2026-09-24），星星数为发文时数据，仅供参考。
