本周 GitHub Trending 周榜里，重点介绍三个项目：

• Robbyant/lingbot-map：把连续视频实时还原成三维场景的流式 3D 基础模型
• diegosouzapw/OmniRoute：在各种模型、供应商和 Coding Agent 之间做统一路由的 AI 网关
• tirth8205/code-review-graph：通过代码结构图谱减少 AI 做代码审查时需要读取的上下文，这个在前面也有上榜

上周已经重点介绍过的 Nutlope/hallmark 仍然留在榜单里，本周只做简单更新。

Robbyant/lingbot-map

总 Star: 15199, 本周新增 Star: 4435

简介：一个面向连续视频流的前馈式 3D 基础模型，可以一边接收画面，一边恢复相机轨迹和三维场景。

仓库：https://github.com/Robbyant/lingbot-map

它解决什么问题

从照片或视频里重建三维场景并不是新方向，真正困难的是如何把它做成一个可以持续运行的流式系统。

传统三维重建方案往往需要对整段数据反复优化。视频越长，需要保存和联合计算的帧就越多，耗时、显存占用和累计误差都会上升。另一类前馈模型虽然速度更快，但面对几千甚至几万帧的长序列时，又容易忘记早期信息，最终出现相机轨迹漂移和场景错位。

LingBot-Map 的目标，是输入一段连续视频流，直接预测每一帧的相机位姿、深度和点云，把三维重建从一次性的离线任务变成持续更新的过程。

Geometric Context Transformer

项目的核心结构叫做 Geometric Context Transformer。它维护了三类上下文：

• Anchor Context：保存场景的坐标基准，避免后续结果逐渐失去统一尺度
• Pose-reference Window：保留近期关键帧，为当前相机位姿提供局部参照
• Trajectory Memory：记录较长时间范围的运动轨迹，用来修正长期漂移

可以把它理解为：模型既要知道“眼前几帧发生了什么”，也要记得“整个拍摄过程从哪里出发、走过了哪里”。这三类上下文共同解决局部细节和全局一致性之间的矛盾。

为了让长序列推理的成本可控，LingBot-Map 还使用分页 KV Cache 和关键帧策略。普通帧仍然会产生预测结果，但只有部分关键帧进入缓存，避免上下文随着视频长度无限增长。

速度和长视频能力

项目给出的数据是，在 518×378 分辨率下可以达到约 20 FPS，并能够处理超过 10000 帧的长序列。仓库还提供了一个约 13 分钟、25000 帧的室内行走示例。

不过，这并不意味着把任何长度的视频扔进去都能自动得到稳定结果。模型训练时使用的有效视图范围有限，README 也明确提到：序列很长或移动距离超出训练分布时，需要使用关键帧间隔，或者切换到带重叠区域的窗口推理，否则仍然可能发生位姿崩溃。

它更像是把“长视频三维重建”从一个重优化问题，变成了一个需要管理记忆和窗口的流式推理问题。

适合什么场景

这个项目比较直接的应用包括机器人导航、自动驾驶数据处理、无人机巡检、室内空间扫描和 AR/VR 内容制作。

从工程使用门槛来看，它目前仍偏研究和专业应用：推荐环境包含较新的 PyTorch、CUDA 和 FlashInfer，长视频离线渲染还会用到 Kaolin、Open3D 和自定义 CUDA 扩展。普通用户可以直接运行仓库里的示例，但要处理自己的长视频，仍然需要准备合适的 NVIDIA GPU，并理解关键帧、窗口大小和显存之间的取舍。

LingBot-Map 最值得关注的地方，不只是效果，而是它展示了一条很清楚的路线：世界模型不仅要生成画面，还要能够持续接收真实世界的数据，维护一个不会轻易漂移的三维状态。

如果这类模型继续提升速度和稳定性，摄像头输入就不再只是视频文件，而会成为 Agent 理解和操作物理世界的一种实时接口。

diegosouzapw/OmniRoute

总 Star: 27940, 本周新增 Star: 8673

简介：一个部署在本地的 AI 网关，用统一接口连接不同模型供应商，并为 Coding Agent 提供自动切换、成本控制和上下文压缩。

仓库：https://github.com/diegosouzapw/OmniRoute

外部链接：https://omniroute.online

它解决什么问题

现在使用 Coding Agent，麻烦的地方已经不只是选择哪个模型。

不同供应商有不同的 API 格式、鉴权方式、订阅额度和限流规则；Claude Code、Codex、Cursor、Cline 等工具又各自有一套配置。一个模型触发限流后，手工换 Key、换 Provider、换模型，往往会直接打断当前会话。

OmniRoute 在 Agent 和模型供应商之间加了一层统一网关。Coding Agent 只连接一个本地 Endpoint，后面的模型选择、协议转换、失败重试和配额切换由网关负责。

它支持 OpenAI、Claude、Gemini 等多种接口风格，并宣称可以连接 290 多个供应商和 500 多个模型。这里的价值不在于数字本身，而在于把模型从某个工具里的固定配置，变成可以按规则调度的资源池。

自动路由和故障切换

OmniRoute 可以按照订阅额度、API Key、价格和免费模型设置多级回退。当当前模型限流、余额不足或请求失败时，网关会尝试下一个可用通道。

对于同时使用多个模型订阅的人，这种方式很实用：优先消耗已经购买的订阅额度，再使用按量 API，最后回退到低价或免费模型。它还提供熔断、Key 冷却和模型锁定等机制，避免一个失效通道被连续重试。

不过，自动切换也会带来一个需要注意的问题：不同模型的工具调用能力、上下文长度和输出风格并不完全一致。连续会话中突然换模型，虽然请求没有中断，但结果的一致性可能发生变化。因此，生产环境最好按任务类型建立明确的路由组，而不是把所有模型放进一个无差别的回退列表。

上下文压缩

除了路由，OmniRoute 还把上下文压缩作为核心卖点。它可以压缩终端输出、工具返回值、重复消息和结构化数据，尽量保留代码、URL 和 JSON 等关键内容。

项目声称，不同压缩组合可以节省 15% 到 95% 的 Token，在工具调用较多的会话中平均节省接近 89%。这些数字来自项目自己的流水线和测试口径，真实收益会随任务变化很大：日志、重复工具输出通常压缩空间较大，而短提示词和高密度代码不会有同样效果。

更重要的是，压缩并非免费午餐。压得越激进，越可能丢失错误上下文、字段含义或细微语义。比较稳妥的方式，是先对工具输出和历史重复内容做可恢复压缩，再根据实际任务评估更激进的模式。

本地部署不等于没有安全成本

OmniRoute 采用本地优先的方式运行，并对保存的 Key 做加密。不过，作为所有 Agent 请求的中间层，它天然可以接触提示词、代码上下文、工具返回值和供应商凭据。

因此，准备在工作项目中使用时，仍然应该检查它的日志策略、流量检查功能、代理配置和数据持久化位置。特别是启用透明代理、MITM 流量分析或团队共享 Key 池时，需要把它当成正式的基础设施来管理，而不是普通桌面插件。

OmniRoute 代表的趋势很明显：当模型数量和 Agent 工具越来越多，开发者需要的已经不是又一个模型客户端，而是一个能够统一管理模型资源的控制层。

它的功能覆盖很广，也因此显得有些“全家桶”。个人用户可以先从统一 Endpoint 和失败回退开始，确认稳定后再逐步启用压缩、共享配额和高级代理功能。

tirth8205/code-review-graph

总 Star: 26060, 本周新增 Star: 6257

简介：在本地把代码库构造成结构图谱，让 Coding Agent 做审查、调试和影响分析时只读取真正相关的部分。

仓库：https://github.com/tirth8205/code-review-graph

外部链接：https://code-review-graph.com

为什么 AI 审查代码很费上下文

让 AI 审查一个小改动，看起来只需要把 diff 交给它。但真正有价值的审查还要回答很多跨文件问题：这个函数被谁调用、修改会影响哪些入口、相关测试在哪里、父类或接口有什么约束。

如果 Agent 不知道代码结构，常见做法就是不断搜索文件、读取调用方，甚至反复扫描整个仓库。仓库越大，Token 消耗越高，而且大量上下文其实和当前修改没有关系。

code-review-graph 的思路，是提前把这些结构关系算出来。

从 AST 变成代码图谱

项目通过 Tree-sitter 解析代码的 AST，把函数、类、文件和模块存成节点，把调用、导入、继承和测试覆盖关系存成边。

代码发生变化后，它会增量更新图谱。Agent 需要审查某个修改时，可以通过 MCP 查询改动的影响半径、调用链、关联测试和风险评分，再决定具体读取哪些文件。

这和普通向量检索的区别是：向量检索回答的是“哪些代码在语义上相似”，代码图谱回答的是“这些代码在结构上如何连接”。前者适合模糊搜索，后者更适合调用链、影响范围和测试关联等多跳问题。

Token 节省数字应该怎么理解

README 给出的核心数字是：在 6 个真实仓库的逐问题测试中，相对于把整个代码库作为上下文，Token 减少倍数的中位数约为 82 倍，最高的 528 倍来自单个最佳案例。

这个结果能说明图谱查询比全仓扫描更节省，但不能直接理解为每次 Code Review 都能省 82 倍。项目自己的另一组测试也显示，当改动只是一个很小的单文件提交时，包含影响关系和源码片段的 Review Context，甚至可能比原始 diff 更大。

所以它最适合的不是几百行代码的小项目，也不是改一个拼写错误，而是大型仓库里的跨模块修改、调用链分析、架构理解和持续审查。

接入现有 Coding Agent

安装之后，code-review-graph install 会识别 Codex、Claude Code、Cursor、Gemini CLI、GitHub Copilot 等工具并写入 MCP 配置；再通过 build 命令扫描当前代码库。

项目默认提供 30 个 MCP 工具，除了 Review Context，还包括变化检测、影响范围、架构概览、语义搜索、多仓库管理和 Wiki 生成。对于上下文紧张的客户端，也可以只暴露少数必要工具，避免工具描述本身占用太多 Token。

所有结构图谱默认保存在本地，向量 Embedding 是可选能力。这一点对不能把公司代码发送到额外服务的场景比较重要。

这个项目背后的判断很准确：Coding Agent 的效率问题，不只是模型推理速度和上下文窗口大小，更取决于它能否在调用模型前找到正确的上下文。

长期看，代码图谱、LSP、搜索和版本历史可能会共同组成 Agent 的代码感知层。code-review-graph 目前未必能替代成熟的静态分析工具，但它提供了一个很适合 MCP Agent 使用的结构化入口。

koala73/worldmonitor

总 Star: 72561, 本周新增 Star: 9054

简介：把全球新闻、地缘政治、自然灾害、市场和基础设施信号汇总到地图上的实时态势面板。

仓库：https://github.com/koala73/worldmonitor

World Monitor 聚合了 500 多个新闻源，并在 3D 地球和二维地图上叠加军事、灾害、经济和基础设施等数据。它提供世界、科技、金融、商品、能源等多种界面，也支持使用 Ollama 在本地生成新闻摘要。

项目不仅是一个网页 Dashboard，还提供桌面应用、REST API、MCP、CLI 和多语言 SDK。它适合做信息聚合和趋势观察，但其中的 AI 摘要、跨来源关联和国家风险评分都属于辅助分析结果，不应该直接当成事实判断或投资依据。

Nutlope/hallmark

总 Star: 16513, 本周新增 Star: 5797

简介：帮助 Claude Code、Cursor 和 Codex 避免生成模板化 UI 的设计 Skill。

仓库：https://github.com/Nutlope/hallmark

Hallmark 上周已经重点介绍过，本周仍然保持了很高的热度。它通过页面宏观结构、主题选择、57 项反模式检查和生成前自检，减少 Coding Agent 常见的“AI 模板味”。

它最近强调了 Custom 模式：当现有主题不适合需求时，不再勉强套模板，而是根据 brief 重新设计配色、字体和布局。这个变化进一步说明，前端 Skill 的重点正在从“提供固定规则”走向“帮助 Agent 做设计判断”。

1jehuang/jcode

总 Star: 11095, 本周新增 Star: 2586

简介：一个用 Rust 编写、面向多会话工作流的 Coding Agent Harness。

仓库：https://github.com/1jehuang/jcode

jcode 把重点放在性能、可定制性和同时运行多个会话上。项目展示的自测结果里，终端首帧速度和多会话内存占用明显低于多个同类 CLI，不过这些数据来自项目方特定机器和测试方法，更适合作为设计取向参考。

它反映出 Coding Agent 的竞争开始从“能不能调用模型”扩展到运行时层面：启动速度、资源隔离、会话管理和并行任务体验都会影响日常使用。

ibelick/ui-skills

总 Star: 6234, 本周新增 Star: 2139

简介：一个面向设计工程师的 UI Skills 集合，可以根据任务为 Agent 选择相应的设计规则。

仓库：https://github.com/ibelick/ui-skills

ui-skills 上周已经进入候选表，本周周增占比进一步达到 34.3%。它提供一个 CLI，用来浏览、获取和启动不同类别的 UI Skill，例如基础界面和动效规则。

它和 Hallmark 放在一起看很有意思：一个更像带有明确审美主张的完整设计 Skill，另一个更像可以按任务选择的 Skill 工具箱。两者共同说明，UI 生成正在从通用 Prompt 转向可组合、可版本化的设计能力。

本周小结

这周的三个重点项目看起来方向不同，实际上都在解决同一个问题：怎样在输入规模不断扩大的情况下，让 Agent 或模型只保留真正有用的状态。

LingBot-Map 管理的是长视频里的几何上下文，OmniRoute 管理的是多个模型通道和会话上下文，code-review-graph 管理的是大型代码库里的结构上下文。它们都没有简单地把更多内容塞进模型，而是在模型前面增加了一层选择、压缩和记忆机制。

这可能也是 AI 工具进入下一阶段后的共同变化：模型能力仍然重要，但真正决定系统是否好用的，越来越是模型周围的上下文工程和运行基础设施。