AI 资源库 · 已整理 6 项
查看与基础设施相关的 AI 资讯、工具、Skill、工作流和开源项目。
在旧金山举行的 Universe ’26 大会上，GitHub 管理层回应了平台稳定性问题。他们表示已经增加 400 万核 CPU 和 160 PB 存储，并彻底重构后端基础设施。原因是 AI Agent 的访问方式和人类开发者差别很大，一些原本运行正常的服务出现了意外故障，因此不只是扩容，还要重写核心服务。对于前 CEO Thomas Dohmke 新创办的 GitHub 替代品 Entire，GitHub COO Kyle Daigle 说“世界不需要一个新的 GitHub”，开发者可能只是需要不同的工具。Dohmke 则回应称开发者显然需要新选择。这些投资和调整目前已经公布，但文章没有说明具体上线时间。
GitHub 的提交量涨得极快：2024 年平均每月约 6500 万次，今年 4 月 14 亿次，8 月 29 亿次，9 月已达到 74 亿次，公司称主要推手是 AI Agent 带来的自动化需求。这种增长也让服务频繁出故障，所以 GitHub 今年已增加 400 万个 CPU 核心（多数在 Azure 上）、160 PB 高速存储和 50 Tb/s 网络带宽，并加强 GitHub Actions 算力。同时它正把计算和存储拆开重新架构，内部测试写入吞吐最高提升 35 倍。对开发者的意义是：这轮扩容已在进行，目标是减少卡顿和宕机，但新架构的具体上线时间原文未说明。
Uber 的工程团队重新搭建了外卖应用 Uber Eats 的搜索流程，并报告称用户从下单搜索到看到结果的整体等待时间减少了一半。此前搜索链路较长、各环节串行执行，加上广告数据与检索逻辑交织，导致响应偏慢。这次他们改进了衡量首屏展示的方法、精简了检索环节、让多个数据获取步骤并行执行，还重新设计了广告数据并优化了底层基础设施，同时借助智能体编程流程辅助开发。对普通用户来说，这意味着在 Uber Eats 里搜餐、加载结果会更快。团队表示还在探索微批处理、基于商品的检索和 HTTP multipart 流式传输，但这些尚未开放，处于探索阶段。
提供的材料未提及具体可用工具。
这篇文章讲的是一位开发者对供应商锁定问题的看法。很多基础设施团队在选型时，会因为赶工期或预算压力选择某家厂商的托管服务，当时看起来合理，但时间一长就越来越难换掉，比如数据库、身份认证、日志监控都和某家云绑死了。作者认为，开源软件能帮助团队更容易检查、迁移和替换系统，从而保留选择的余地。不过他也提醒，开源本身不保证一定能避免锁定，如果团队在开源基础上仍然做出紧耦合的设计，照样会被绑住。文章以 Linux 内核和 Kubernetes 为例，说明开源许可证和治理结构如何防止单一厂商单方面改变规则。
提供的材料未提及具体可用工具。
dynatrace-oss/dynatrace-kirocrew-app
这是 Dynatrace 的看板式控制塔应用，提供只读视图，按生命周期泳道（New、Ongoing、Under maintenance、Recently closed）对 problems 进行分诊，并按健康状态（Unhealthy、Watch、Healthy）分组展示 services 和 applications。默认的 Smart 排序由 KiroCrew agent（dynatrace-smart-rank cron，每 15 分钟运行）根据类别权重、影响范围、根因存在性、持续时间、复发情况以及环境记忆对活跃问题卡片按分诊紧急度排序，并在卡片上展示排名与一行理由；同时也提供按严重程度、最新、影响最多、运行最久等确定性排序。应用本身只读，不会关闭问题或改变 Dynatrace 状态，需要执行的动作会跳转到 Dynatrace 或交给 KiroCrew agent。
Modal 的两名资深工程师 Colin Weld 和 Connor Adams 最近写了一篇文章，讲他们怎样把公司用来跑代码的“沙箱”系统整个推倒重做。原来的问题是：用 Kubernetes 这种常见容器管理方式，没法同时支撑几百万个沙箱，也没法每秒新建几万个。他们从底层重新设计后，做到了这两点。对读者的用处是：如果你关心云端跑代码、AI 智能体执行环境这类场景，这提供了一条不用 Kubernetes 也能大规模扩容的思路。目前文章只是经验分享，没有提到具体产品是否开放或开源。
提供的材料未提及具体可用工具。