AI实用工具:Astryx给Agent装设计系统,OmniRoute一个端点接237家LLM

2026年7月9日

今天三个工具分别来自三个不同的"权力中心"——Meta、开源社区和微软生态——但踩中了同一个趋势：AI Agent 不再是代码的"消费者"，而是代码的"共同生产者"。一个让设计系统对 Agent 可读可操作，一个把 API 调用成本压缩到接近零，一个让 .NET 开发者终于有了和 Claude Code 平起平坐的 IDE 武器。

Astryx — Meta 开源的 150+ 组件设计系统，同时为人类和 AI Agent 设计

用 AI 写前端的人迟早撞上一个尴尬时刻：Agent 写出了能跑的组件，但每个组件都长得不一样——间距不一致、颜色硬编码、无障碍属性缺失。这不是 Agent 的错，是它没有设计系统的约束。你可以在 prompt 里写"用 shadcn 的 Button 组件"，但 shadcn 的文档是给人读的，Agent 从这里学到的只是 API 表面，学不到设计意图、组合模式和边界条件。

Astryx 的解法是把设计系统本身做成 Agent 的一等公民。150+ 个组件不只是暴露 props 类型——每个组件带 JSDoc 注解，标注了组合提示、边界约束和主题变量。Agent 读的是结构化知识，不是从文档里猜。

这套设计系统在 Meta 内部跑了 8 年，支撑了 13,000+ 个内部应用。它不是实验室项目——是经历过 React 版本升级、设计语言迭代、多团队并行开发的实战产物。CLI 是理解 Astryx 设计理念的关键入口：一个自描述的 Agent 清单。Agent 一次调用就能拿到每个命令的参数类型、可选值、默认值和响应格式。astryx build "用户登录页面" 返回按角色分组的组合套件，实测把 Agent 的组件召回率从 15% 提升到 71%。

10 套主题全都基于 CSS 变量级联，改一套变量整个系统跟着变。主题层和组件层完全解耦。基于 React 和 StyleX，MIT 协议，40 位贡献者。

# 安装核心 + 主题
pnpm add @astryxdesign/core @astryxdesign/theme-neutral
pnpm add -D @astryxdesign/cli

# 初始化项目（安装依赖、配置主题、生成 Agent 文档）
npx astryx init

# 浏览所有组件
npx astryx component --list

# Agent 组合式构建（返回结构化组合方案）
npx astryx build "数据仪表盘主页"

# 生成自定义主题
npx astryx theme build --config my-theme.config.ts

同类工具对比

Astryx 和其他设计系统的核心差异不在组件数量——shadcn、MUI、Ant Design 的组件都更多。差异在于对 Agent 的亲和度。shadcn 的文档、MUI 的 API 参考、Ant Design 的示例页面——这些都是为人设计的。Astryx 多了一层：组件元数据是机器可读的，CLI 是自描述的，组合规则被编码进了 build 命令的输出结构。这不是"可以用 Agent 操作"，而是"被设计成由 Agent 操作"。

⭐ 7,199 · MIT License · Beta · 40 贡献者 · Meta 官方

GitHub：github.com/facebook/astryx · 官网：astryx.atmeta.com

OmniRoute — 免费 AI 网关，一个端点接入 237 个 LLM 提供商

用 Claude Code 或 Codex 写代码的人，几乎都经历过这个循环：Claude Code 的订阅配额用完了 → 切到 Codex → Codex 限速了 → 换 Cursor → Cursor 的免费额度也见底了。每个工具用自己的 API Key、自己的额度、自己的限速策略。你想省钱用免费模型，但每个都要单独注册、单独配 SDK、单独记额度。管理成本比省下来的钱还高。

OmniRoute 用一个本地网关解决了这个问题。它在 localhost:20128 起一个 OpenAI 兼容的 /v1 端点，后面接了 237 个 LLM 提供商，其中 90+ 有免费额度，11 个永久免费。你把 Claude Code、Codex、Cursor、Cline、Copilot 全部指向这一个端点，OmniRoute 负责背后的路由、fallback、格式转换和 token 压缩。

核心路由引擎有 17 种策略，日常最有价值的就三个场景：Cost-optimized 路由（简单问题走免费模型）、Priority fallback（配额用完自动切）、Context-relay（跨模型会话保持上下文）。RTK + Caveman 双层 token 压缩是 OmniRoute 最被低估的功能——工具密集型会话平均省 89% 的 token。如果你一个月花 $100 在 API token 上，压缩层大概能帮你降到 $11-40。

内置 MCP 服务器（95 个工具、3 种传输方式、30 个作用域）让你可以用 MCP 协议操作网关——查询额度、切换路由策略、查看压缩统计。A2A 协议让 Claude Code 和 Codex 在同一个网关上协作。JA3/JA4 TLS 指纹伪装防止被提供商识别为自动化流量。开源 MIT，本地运行，你的 Key 不经过任何云端。

# 全局安装
npm install -g omniroute

# 启动网关（自动打开 Web 仪表盘）
omniroute

# 一键配置 Claude Code 走网关
omniroute setup-claude-code

# 一键配置 Codex CLI
omniroute setup-codex

# Docker 部署
docker pull diegosouzapw/omniroute
docker run -p 20128:20128 diegosouzapw/omniroute

同类工具对比

OmniRoute 和 LiteLLM 走的是两条不同方向。LiteLLM 是 Python 生态的 provider 网关——更成熟、文档更全、企业功能更多。OmniRoute 是 TypeScript/Node 生态的"开发者优先"网关——压缩、MCP、A2A 全部内置，免费 tier 聚合做得更激进。如果你是企业环境需要完整网关管理面板，LiteLLM 更合适；如果你是开发者想省钱且不被限速打断工作流，OmniRoute 的零配置 + 压缩 + 免费 tier 组合目前无出其右。

⭐ 13,784 · MIT License · v3.8.46 · 200 贡献者 · 275 releases

GitHub：github.com/diegosouzapw/OmniRoute · 官网：omniroute.online

VS-MCP — Visual Studio 的 Roslyn 驱动 MCP 服务器

.NET 开发者在 AI 编码工具的浪潮中一直站在尴尬的位置。Claude Code、Codex CLI、Cursor 这些工具对 TypeScript/Python/Go 的支持已经很成熟了，但面对一个大型 C# 解决方案——几十个项目、几百个类、复杂的泛型继承链——它们退化成 grep。FindSymbols 被降级为文本搜索，Go to Definition 变成了文件名猜测。这是因为这些 Agent 工作在文件系统层面，而 .NET 代码的真正结构在编译器的符号表里。

VS-MCP 的解法是把 Roslyn（C# 编译器）和 Visual Studio 调试器的完整能力暴露为 41 个 MCP 工具。Agent 搜索 WhisperFactory 时，grep 可能返回 47 个文本匹配——包括注释、字符串、测试数据里的偶然出现。VS-MCP 的 FindSymbols 用 Roslyn 的语义索引，返回精确结果。

41 个工具分四层：语义导航层（13 个 Roslyn 工具：FindSymbols、FindSymbolDefinition、FindSymbolUsages、GetInheritance 等）、代码分析层（GetDiagnostics 获取 Roslyn 后台分析结果）、重构层（RenameSymbol 解决方案级安全重命名、FormatDocument VS 原生格式化）、调试层（19 个工具 Preview：断点管理、单步执行、变量检查、Docker/WSL 进程附加）。响应被刻意压缩——比同类方案省 70-90% 的 token。

# 在 Visual Studio 2022/2026 中
# 扩展 → 管理扩展 → 搜索 "MCP AI Server" → 安装

# Claude Code 配置（.mcp.json）
{
  "mcpServers": {
    "vs-mcp": {
      "type": "http",
      "url": "http://localhost:3010/sdk/"
    }
  }
}

# Cursor 配置（.cursor/mcp.json）
{
  "mcpServers": {
    "vs-mcp": {
      "url": "http://localhost:3010/sdk/"
    }
  }
}

同类工具对比

VS-MCP 和 VS Code 系的 MCP 扩展走的是两个方向。VS Code 的 MCP 扩展做的是"把编辑器功能暴露给 Agent"——这些能力 Claude Code 本身已经具备了。VS-MCP 做的是"把 Agent 不具备的能力给它"——Roslyn 的语义索引精度远超文件系统搜索，VS 调试器的断点/单步/变量检查是 Claude Code 完全做不到的。对于 .NET 开发者，VS-MCP 是把 Agent 从一个"文本搜索器"升级成了"有编译器大脑的开发者"。

Visual Studio Marketplace · 4,236 安装 · v2.0+ · Free

GitHub：github.com/LadislavSopko/mcpserverforvs