Cline 是一款可以在你的 IDE 与终端中使用的开源 AI 编码 Agent。

文档 · Discord · r/cline · 功能请求 · 加入我们

CLI

在终端中运行 Cline，支持交互式聊天，也可完全无头运行，便于 CI/CD 与脚本化使用。

npm i -g cline

了解更多

Kanban（任务看板）

通过基于 Web 的任务看板并行运行多个 Agent。每张任务卡都会分配独立的工作树、自动提交以及依赖链。

npm i -g kanban

了解更多

VS Code 扩展

编辑器内的 AI 编程助手。可创建文件、运行命令、浏览网页，并使用各类工具，所有操作均需人工把关审批。

从 VS Marketplace 安装

JetBrains 插件

在 IntelliJ IDEA、PyCharm、WebStorm、GoLand 以及其他 JetBrains 全家桶 IDE 中获得同样的 Cline 体验。

从 JetBrains Marketplace 安装

SDK

基于驱动 CLI、Kanban、VS Code 扩展与 JetBrains 插件的同一套引擎，搭建你自己的 AI Agent 与集成方案。支持自定义工具、多 Agent 团队、连接器、定时自动化等。

npm install @cline/sdk

文档

仓库索引

跨项目编辑代码

Cline 会读取你的项目结构，理解文件之间的关联，并在整个代码库中进行协调式修改。它会在工作过程中持续监听 lint 与编译错误，在你察觉之前就修复缺失的导入、类型不匹配与语法错误等问题。在 VS Code 与 JetBrains 中，所有改动都会以 diff 形式呈现，你可以审阅、修改或回滚。所有更改都会通过检查点（checkpoint）进行记录，便于随时撤销 Agent 的操作。

执行 Bash 命令

Cline 直接在你的终端中执行命令，并实时查看输出。可用于安装依赖包、运行构建脚本、执行测试、部署应用、管理数据库等。对于像开发服务器这样的长时间运行进程，Cline 会持续在后台运行，并随着新输出的出现即时响应，实时捕捉编译错误、测试失败与服务器崩溃等问题。

Plan 与 Act 模式

在 Plan 模式与 Act 模式之间自由切换。在 Plan 模式中，Cline 会探索你的代码库、提出澄清性问题，并给出整体策略；双方对齐后，切换至 Act 模式，Cline 将执行该方案。每一次文件修改与终端命令都需要你的批准，确保变更始终处于你的掌控之中；你也可以开启自动批准（auto-approve），让 Cline 自主运行。

规则与技能（Rules & Skills）

通过 .clinerules 文件定义项目专属规则，用于指导 Cline 在你的代码库中如何工作，包括编码规范、架构约定、部署流程、测试要求等。这些规则会被 CLI、VS Code 扩展与 JetBrains 插件自动加载。同时可使用技能（skills），让模型在需要时按需加载特定的规则。

兼容任意模型

Cline 不会被锁定在单一 AI 提供商，你可以按工作流选择最合适的模型：

通过插件或 MCP 服务器扩展能力

通过插件扩展 Cline 的能力。借助 SDK，可通过插件系统以编程方式注册工具与生命周期钩子，用于日志记录、审计、策略执行或添加领域专属能力。下方是一个简单的插件示例。

import { Agent, createTool } from "@cline/sdk"

const deployTool = createTool({
  name: "deploy",
  description: "Deploy the current branch to staging.",
  inputSchema: { type: "object", properties: { env: { type: "string" } }, required: ["env"] },
  execute: async (input) => {
    // your deployment logic
  },
})

const agent = new Agent({ tools: [deployTool], /* ... */ })

也可以使用 MCP 服务器 连接数据库、查询 API、管理云基础设施，并与外部系统交互。可以直接使用社区构建的服务器，也可以让 Cline 即时按需创建自定义工具。在 CLI 中，可通过 cline mcp 命令管理服务器。

多 Agent 团队

协调多个 Agent 协作完成复杂任务。由一个协调者 Agent 拆解工作并将子任务分派给各专精 Agent，每个专精 Agent 拥有各自的工具与上下文。团队状态会在会话之间持久化，便于你随时接续未完成的工作。

cline --team-name auth-sprint "Plan and implement user authentication with tests"

定时 Agent

按 cron 表达式定时运行 Agent，用于周期性自动化任务，例如每日 PR 摘要、每周依赖检查、代码库健康报告等。定时计划在重启后仍然保留，并独立于任何终端会话运行。

cline schedule create "PR summary" \
  --cron "0 9 * * MON-FRI" \
  --prompt "List all open PRs and their review status" \
  --workspace /path/to/repo

连接 Slack、Telegram、Discord 等平台

通过任意即时通讯平台与你的 Agent 对话：Telegram、Slack、Discord、Google Chat、WhatsApp、Linear 等。每条会话线程都会映射到一个具备完整上下文的 Agent 会话。你也可以设置访问控制，限定能够与 Agent 交互的人员。

# 连接 Telegram
cline connect telegram -k $BOT_TOKEN
# 通过 Webhook 连接 Slack
cline connect slack --bot-token $SLACK_TOKEN --signing-secret $SECRET --base-url $URL
# 通过 Socket Mode 连接 Slack
cline connect slack --bot-token $SLACK_TOKEN --app-token $SLACK_APP_TOKEN

用于 CI/CD 的无头 CLI

以零交互方式运行 Cline，便于编写脚本与自动化。可对接标准输入、输出 JSON 结果、串联命令，并集成到 CI/CD 流水线中。

cline "Run tests and fix any failures"
git diff origin/main | cline "Review these changes for issues"
cline --json "List all TODO comments" | jq -r 'select(.type == "agent_event" and .event.text) | .event.text'

贡献

请阅读贡献指南 开始。加入我们的 Discord，前往 #contributors 频道与其他贡献者交流。访问我们的招聘页面 查看全职岗位。

许可证

Apache 2.0 © 2026 Cline Bot Inc.

Neko Master

清晰洞察你的网络流量。

实时监控 · 流量审计 · 多网关支持

English | 中文

[!IMPORTANT]
免责声明

本项目是一个面向本地网关环境的流量分析与可视化工具。

它不提供任何网络访问服务、代理订阅或跨网连接能力。
所有数据均采集自用户自身的网络环境。

本项目基于 MIT 协议开源。因使用本软件所产生的一切后果，由使用者自行承担。请在遵守当地法律法规的前提下使用。

关于名称

Neko（ねこ）在日语中是 猫 的意思。
发音为 /ˈneɪkoʊ/（NEH-ko）。

正如猫一样，Neko Master 以安静而精准的方式观察网络流量。
它是一款专为现代网关环境设计的轻量级数据分析看板。

📋 目录

• ✨ 功能特性
• 🚀 快速开始
• 🤖 Agent 部署
• 📖 首次使用
• 🔧 端口冲突处理
• Docker 配置
• 🗄️ ClickHouse（可选）
• 反向代理与内网穿透
• 🔐 认证与安全
• ❓ 常见问题
• 🏗️ 架构指南
• 反馈与问题
• 项目结构
• 🛠️ 技术栈
• 📄 开源协议

✨ 功能特性

🚀 快速开始

方式一：Docker Compose（推荐）

仓库内置的 docker-compose.yml 默认映射 3000/3001/3002 端口。
下面的 A / B 方案是面向常见部署场景的最小化模板。

方案 A：最小化部署（仅暴露 3000）

services:
  neko-master:
    image: foru17/neko-master:latest
    container_name: neko-master
    restart: unless-stopped
    ports:
      - "3000:3000" # Web UI
    volumes:
      - ./data:/app/data
      # 本地 MMDB（可选，文件需下载到 ./geoip）
      - ./geoip:/app/data/geoip:ro
    environment:
      - NODE_ENV=production
      - DB_PATH=/app/data/stats.db
      - COOKIE_SECRET=${COOKIE_SECRET}

推荐在 .env 文件中（与 docker-compose.yml 同目录）配置：
COOKIE_SECRET=（可通过 openssl rand -hex 32 生成）

该模式完全兼容升级，开箱即用。
如果未启用 WebSocket 转发，应用会自动回退到 HTTP 轮询。

方案 B：实时 WebSocket（推荐配合反向代理使用）

services:
  neko-master:
    image: foru17/neko-master:latest
    container_name: neko-master
    restart: unless-stopped
    ports:
      - "3000:3000" # Web UI
      - "3002:3002" # WebSocket（用于 Nginx / 内网穿透转发）
    volumes:
      - ./data:/app/data
      # 本地 MMDB（可选，文件需下载到 ./geoip）
      - ./geoip:/app/data/geoip:ro
    environment:
      - NODE_ENV=production
      - DB_PATH=/app/data/stats.db
      - COOKIE_SECRET=${COOKIE_SECRET}

然后执行：

docker compose up -d

打开 http://localhost:3000 即可开始使用。

如果使用仓库自带的 Compose 文件（默认 3000/3001/3002），同样执行上述命令即可。

方式二：Docker Run

# 先生成一个固定的 cookie 密钥（用于会话持久化）
export COOKIE_SECRET="$(openssl rand -hex 32)"

# 最小化部署（仅 3000）
docker run -d \
  --name neko-master \
  -p 3000:3000 \
  -v $(pwd)/data:/app/data \
  -e COOKIE_SECRET="$COOKIE_SECRET" \
  --restart unless-stopped \
  foru17/neko-master:latest

# 实时 WebSocket（配合反向代理）
docker run -d \
  --name neko-master \
  -p 3000:3000 \
  -p 3002:3002 \
  -v $(pwd)/data:/app/data \
  -e COOKIE_SECRET="$COOKIE_SECRET" \
  --restart unless-stopped \
  foru17/neko-master:latest

打开 http://localhost:3000 即可开始使用。

前端默认使用同源 /api，因此通常无需在外部暴露 3001 端口。
实时 WebSocket 模式下，你的反向代理 / 内网穿透必须能访问到 3002 端口。否则应用会自动回退到约 5 秒一次的 HTTP 轮询。

使用 docker run 时，可直接通过 -p 参数修改对外端口。
只有当直接使用 WebSocket（不经过反向代理）且外部 WebSocket 端口不是 3002 时，才需要额外传入 -e WS_EXTERNAL_PORT=。

本地 MMDB 查询模式（可选）：挂载 -v $(pwd)/geoip:/app/data/geoip:ro，
然后在 Settings -> Preferences -> IP Lookup Source 中将数据源切换为 Local。

方式三：一键脚本

自动检测端口冲突并完成全部配置：

# 使用 curl
curl -fsSL https://raw.githubusercontent.com/foru17/neko-master/main/setup.sh | bash

# 或使用 wget
wget -qO- https://raw.githubusercontent.com/foru17/neko-master/main/setup.sh | bash

脚本将自动完成以下工作：

• ✅ 下载 docker-compose.yml
• ✅ 检查默认端口（3000/3001/3002）是否被占用
• ✅ 推荐可用的备用端口
• ✅ 创建配置文件并启动服务

方式四：源码运行

# 1. 克隆仓库
git clone https://github.com/foru17/neko-master.git
cd neko-master

# 2. 安装依赖
pnpm install

# 3. 准备采集器环境变量（源码模式下读取 apps/collector/.env）
cp apps/collector/.env.example apps/collector/.env

# 4. 启动开发服务
pnpm dev

打开 http://localhost:3000 进行配置。

源码模式下：采集器默认监听 3001/3002，Web 端默认监听 3000。
如果你修改了 API_PORT（不是 3001），请同步设置 API_URL（例如 API_URL=http://localhost:4001），以便 Web 端的 /api 反向代理指向正确的 API。
apps/collector/.env.local 的优先级高于 apps/collector/.env。

🤖 Agent 部署

当你希望使用一个集中式的 Neko Master 服务，并由多台远端设备（OpenWrt、Linux、macOS）采集本地网关数据时，可使用 Agent 模式。Agent 运行在网关附近，主动拉取数据并上报到面板——面板不会直接连接网关。

支持的网关类型：Clash / Mihomo（基于 WebSocket 实时）和 Surge v5+（HTTP 轮询）。

快速安装（UI 生成命令）

1. 在面板中进入 Settings → Backends，添加一个 Agent 后端，选择网关类型
2. 点击 "View Agent Script"，复制一键安装命令，并在目标主机上执行：

# Clash / Mihomo 网关示例
curl -fsSL https://raw.githubusercontent.com/foru17/neko-master/main/apps/agent/install.sh \
  | env NEKO_SERVER='http://your-panel:3000' \
        NEKO_BACKEND_ID='1' \
        NEKO_BACKEND_TOKEN='ag_xxx' \
        NEKO_GATEWAY_TYPE='clash' \
        NEKO_GATEWAY_URL='http://127.0.0.1:9090' \
        sh

# Surge 网关示例
curl -fsSL https://raw.githubusercontent.com/foru17/neko-master/main/apps/agent/install.sh \
  | env NEKO_SERVER='http://your-panel:3000' \
        NEKO_BACKEND_ID='2' \
        NEKO_BACKEND_TOKEN='ag_yyy' \
        NEKO_GATEWAY_TYPE='surge' \
        NEKO_GATEWAY_URL='http://127.0.0.1:9091' \
        sh

安装完成后，可通过 nekoagent 管理实例：

nekoagent list               # 列出所有实例
nekoagent status <instance>  # 查看运行状态
nekoagent logs <instance>    # 实时查看日志
nekoagent restart <instance> # 重启实例
nekoagent upgrade            # 全局升级（CLI + 二进制）

脚本会自动检测已有安装——如果已存在 neko-agent，则只会新增实例而不会重复下载。
同一台主机可运行多个实例（使用不同的 NEKO_INSTANCE_NAME），分别对接不同的网关。

Agent 文档

• Overview：架构、Direct 与 Agent 模式对比、安全模型
• Quick Start：从 UI 到 Agent 运行的端到端流程
• Install Guide：安装方式、systemd / launchd 自启动
• Configuration：完整的命令行参数与环境变量参考
• Release Flow：版本管理与兼容性策略
• Troubleshooting：常见错误与解决方法

📖 首次使用

目录

• 为什么会有这个项目
• 支持的供应商
• 兼容的 CLI 与编程代理
• 横向对比
• 功能特性
• 快速开始
• 桌面应用
• 与 OpenAI 兼容客户端协作
• 多语言支持
• Premium（实时模型目录）
• 使用 API
• 截图
• 运行原理
• 局限性
• 贡献
• 免责声明

指南文档： 安装与部署 · API 参考 · 客户端与编程代理 · 提示词压缩 · 架构与内部实现 · 文档索引 · 贡献者指南

为什么会有这个项目

如今几乎每一家有分量的 AI 实验室都会提供免费额度：每月几百万 token、每天几千次请求。单看一家，这点额度只够拿来玩。但如果把它们叠加起来，每月大约能凑出 40 亿 token 的可用推理容量，覆盖 251 个模型家族 / 358 个供应商端点，从又小又快的模型到能力不错的模型都有。

问题在于手动把这些额度堆起来非常痛苦：二十九个不同的 SDK、二十九套不同的限流策略、二十九个请求可能出错的地方。FreeLLMAPI 把这一切收拢成一个兼容 OpenAI（OpenAI-compatible）的端点。把任意 OpenAI 客户端库指向你本地的服务器，它就会在你配置好密钥的那些供应商之间透明地路由请求。

而且免费额度的格局每周都在变：供应商不断上线新模型、下线旧模型、毫无预兆地调整配额。FreeLLMAPI 会替你跟踪这一切。路由器会自动从 freellmapi.co 拉取一份签名过的模型目录，所以你装好之后无需 git pull 也能保持更新。更新速度有多快，可以参考 Premium（实时模型目录）。

支持的供应商

Google

Groq

Cerebras

OpenCode Zen

Mistral

OpenRouter

Cloudflare

Cohere

Z.ai（智谱）

NVIDIA

HuggingFace

ModelScope
Qwen3 · DeepSeek V4 · GLM-5（需要在 Aliyun cn 端点绑定）

……还有 17 家其他免费供应商

此外还支持一个 自定义 供应商——可以在「密钥」页面把聊天、嵌入、图像或音频模型指向任意兼容 OpenAI 的端点，例如 llama.cpp、LM Studio、vLLM、本地 Ollama 或远程网关。

完整且始终最新的列表请见 freellmapi.co/models，里面包含每个模型的速率限制、上下文窗口和免费 token 配额。

兼容的 CLI 与编程代理

Claude Code

Codex CLI

Gemini CLI

Aider

Cline

Roo Code

Continue

OpenCode

Goose

Qwen Code

Kilo Code

Crush

Cursor

Zed

JetBrains AI

……以及任意兼容 OpenAI 的客户端、Anthropic SDK、Gemini SDK，或支持 Ollama 的应用

上述大多数工具都能用一条命令自动完成配置：npx freellmapi setup-claude、setup-codex、setup-aider 等十余个生成器，会拉取你的实时目录、备份已有配置，且永远不会覆盖已存在的内容。Claude Code 和 Codex 还有「零持久化」启动器（freellmapi launch、freellmapi launch-codex），仅向子进程注入凭据。Zed 与 JetBrains AI 通过可选的 Ollama 模拟接入；Gemini CLI 则在 /v1beta 上使用其原生协议。

每个工具的具体配置、setup CLI 参考、可吊销的 URL Token（用于不带 Header 的客户端）以及 MCP 服务器，都收录在 客户端与编程代理 → 中。

横向对比

基于 2026 年 7 月的公开文档整理，欢迎勘误。

功能特性

• 覆盖所有 OpenAI 接口 — /v1/chat/completions、/v1/responses（Codex CLI 所需的接口）、/v1/completions（编辑器灰字自动补全）、/v1/images/generations、/v1/audio/speech、/v1/embeddings 与 /v1/models，支持流式与非流式响应，可通过官方 SDK 或任意兼容 OpenAI 的客户端调用。API 参考 →
• Anthropic Messages API — /v1/messages 走的是 Anthropic 的原生协议，但复用同一套路由器，因此 Claude Code 与官方 Anthropic SDK 都能直接接入你的免费模型池。详情 →
• 原生 Gemini + Ollama 接口 — Gemini CLI 可使用 /v1beta（generateContent、流式响应、token 计数、模型列表），同时可选的 Ollama 模拟面向 Zed、JetBrains 等本地模型客户端提供 NDJSON 格式的 chat/generate、tags、元数据与 embeddings 接口。
• Fusion（多模型合成） — 请求虚拟的 fusion 模型时，路由器会把你的提示并行分发给一组多样化的免费模型，再由一个裁判模型综合多个草稿给出最终答复。详情 →
• 图像生成与文字转语音 — /v1/images/generations 与 /v1/audio/speech 会在提供媒体模型的供应商之间路由，包括自定义的兼容 OpenAI 的媒体端点。
• 工具调用与结构化输出 — OpenAI 风格的 tools 能在各供应商之间往返传递（纯文本形式的工具调用会被救回为真正的 tool_calls），同时 response_format、seed、logprobs、惩罚项等其他采样参数会按供应商透传。
• 六种智能路由策略 — 依据每个模型实时的速度/能力/可靠性评分对你的链进行排序；遇到 429/5xx 时会自动切换到下一个模型并配合冷却与密钥轮换重试。路由详解 →
• 统一的模型与配置档（Profile） — 同一个模型存在于多家供应商时，会被合并为一条记录，并在组内严格执行故障转移；命名好的回退链配置档（例如编程链、视觉链）可以在仪表板上切换，也可以通过请求中的 auto: 按需切换。
• 按密钥统计速率 — 以 (平台, 模型, 密钥) 为维度记录 RPM/RPD/TPM/TPD 计数，并学习供应商公开的速率上限，让路由始终低于各类配额。
• 自动更新的模型目录 — 路由器每天两次从 freellmapi.co 同步签名过的目录：新模型、配额变动、供应商特殊行为的修复都会自动落地。Premium →
• 粘性会话与上下文交接 — 同一会话会在 30 分钟内保持在同一个模型上；可选的压缩交接备注会在中途不得不切换模型时保持话题连贯。详情 →
• 提示词压缩（可选） — 共享的、失败时自动放行的请求流水线会在缓存查找和路由之前，对提示词去重、过滤工具输出、压缩重复 JSON，并修剪过时上下文。详情 →
• 密钥加密，外部仅暴露一个 Token — 供应商密钥在 SQLite 中以 AES-256-GCM 加密保存，每次请求在内存中解密；你的应用只会看到唯一的 freellmapi-… Bearer Token。
• 管理仪表板与分析 — 基于 React 的界面，用于管理密钥、重排回退链、运行 Playground，以及查看 24 小时至 90 天的 p50/p95/TTFT（首 Token 时间）分析；登录后可见，支持明暗主题，可切换 60 种语言。
• MCP 服务器与交互式文档 — 代理可通过 /mcp 自省可用模型、供应商健康状态与路由策略；一个零依赖的 OpenAPI 文档查看器托管在 /v1/docs。编程代理 →
• 运维贴心功能 — 可选的响应缓存、加密的数据库备份、定时密钥健康检查、密钥批量导入/导出、声明式启动配置。安装与部署 →
• 可扩展的采集与分发 — 同一个路由器既能作为供多用户使用的本地服务器（带登录鉴权、限流与配额），也能作为个人节点（绑定 127.0.0.1，无鉴权）。可作为系统服务运行，也提供 桌面应用。
• 内置提示词实验室 — 从 30 多个公开的编程与编辑用例中挑选提示模板；针对每个候选模型可比较原始输出与压缩后输出，并把当前提示固化到请求里。
• 隐私优先 — 所有密钥、对话日志、分析数据默认只存放在你的设备上（SQLite）；路由器只向外发出推理请求本身；可选的遥测在使用前会明确询问。

快速开始

git clone https://github.com/tashfeenahmed/freellmapi.git
cd freellmapi
npm install
npm run build
node dist/cli.js serve

然后访问 http://localhost:8787，在「Keys」页面粘贴你已有的任意供应商密钥。路由器会立刻开始工作。

更完整的安装方式（Docker、systemd、system-tray 应用、反向代理、域名与 TLS 指南）请见 安装与部署。

# 用一行命令把 Claude Code 指向本地 FreeLLMAPI
npx freellmapi setup-claude

# 零持久化启动 Codex CLI（仅在子进程中注入凭据）
freellmapi launch-codex --prompt "refactor the auth middleware"

# 直接 curl 测试 OpenAI 兼容接口
curl http://localhost:8787/v1/chat/completions \
  -H "Authorization: Bearer $FREELLMAPI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"model":"auto","messages":[{"role":"user","content":"hi"}]}'

桌面应用

如果不想开着终端跑本地服务器，可以装一个系统托盘应用：freellmapi-desktop（Tauri + 系统 WebView，体积小、内存占用低）。它会调用与你 npm 安装相同的路由器，并在启动时自动启动后台服务，登录后可直接在托盘菜单里切换密钥。

与 OpenAI 兼容客户端协作

任何兼容 OpenAI 的客户端、Anthropic SDK、Gemini SDK 或是支持 Ollama 的应用都可以通过本地 FreeLLMAPI 路由器工作：

# 把基础地址指向本地
OPENAI_API_BASE=http://localhost:8787/v1
OPENAI_API_KEY=<登录后拿到的 freellmapi-... token>

登录后仪表板会展示一份按客户端分组的快速配置片段。Claude Code、Codex CLI、Gemini CLI、Aider、Cline、Roo Code、Continue、OpenCode、Goose、Qwen Code、Kilo Code、Crush、Cursor、Zed 与 JetBrains AI 的具体接入步骤可参考 客户端与编程代理。Zed 与 JetBrains AI 通过可选的 Ollama 模拟接入，Gemini CLI 直接在 /v1beta 上使用其原生协议。

多语言支持

仪表板与分析界面已本地化为 60 种语言，包括中文（简体/繁体）、英语、西班牙语、葡萄牙语、阿拉伯语、印地语、孟加拉语、俄语、日语、韩语、德语、法语、意大利语、波兰语、土耳其语、越南语、泰语、印尼语、乌尔都语、波斯语、希伯来语、乌克兰语、荷兰语、瑞典语、芬兰语、挪威语、丹麦语、捷克语、匈牙利语、罗马尼亚语、保加利亚语、希腊语、塞尔维亚语、克罗地亚语、斯洛伐克语、斯洛文尼亚语、立陶宛语、拉脱维亚语、爱沙尼亚语、马来语、菲律宾语、泰米尔语、泰卢固语、马拉地语、古吉拉特语、卡纳达语、马拉雅拉姆语、旁遮普语、缅甸语、高棉语、老挝语、蒙古语、尼泊尔语、僧伽罗语、哈萨克语、乌兹别克语、阿塞拜疆语、格鲁吉亚语、亚美尼亚语、马其顿语、阿尔巴尼亚语，以及威尔士语。

切换语言：仪表板右上角 → 语言菜单。下次启动时会记住你的选择。

Premium（实时模型目录）

路由器默认每 12 小时从 freellmapi.co 拉取一次签名过的目录。Premium 用户可以做到：

• 每 5 分钟一次推送式更新，供应商上线新模型、调整配额或下线模型时几乎立刻可见；
• 每 10 分钟一次供应商健康探测，暂停响应缓慢的端点；
• 为编程场景优化的默认路由链，并支持「每天最多失败 N 次」的自定义熔断阈值；
• 小模型快速通道，用于自动补全与重写这类请求量大的子任务；
• 多设备加密同步，在多台机器之间共享密钥与配置档（端到端加密，服务器看不到明文）；
• 优先支持，响应时间通常在数小时内。

订阅可在仪表板的「Premium」标签页开通，并通过 Stripe 或加密货币支付。

使用 API

路由器提供 OpenAI、Anthropic、Gemini 与 Ollama 四套原生协议；完整字段、状态码、流式语义与示例请见 API 参考。下面是最常见的几个调用示例：

# OpenAI 风格：聊天补全 + 流式
curl -N http://localhost:8787/v1/chat/completions \
  -H "Authorization: Bearer $FREELLMAPI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto",
    "messages": [{"role":"user","content":"Explain CRDTs in 3 sentences."}],
    "stream": true
  }'

TL;DR

我们的 Qwen3-TTS 1.7B CustomVoice 实现在单块 NVIDIA H100 SXM 上达到了 每秒 10 个请求（RPS）且首段音频到达时间（TTFA）p95 低于 50 毫秒，同时 保持实时播放。

我们对比了五种实现：我们的方案、vLLM-Omni、SGLang-Omni△、VoxServe 与 M*，流量采用泊松开放环路（Poisson open-loop）。在将各实现调优到面向低延迟流式输出后，我们的方案是唯一达到 p95 TTFA 低于 50 毫秒 的实现。我们 在 10 RPS 以内始终保持 p95 TTFA 低于 50 毫秒，并且 即使在 20 RPS 下也能保持在 100 毫秒以下。

我们的系统在 10 RPS 下每秒大约生成 630 个字符。按 1× H100 SXM 实例 4.29 美元/小时 计算，在满负载下约合 每 100 万字符 2 美元1。作为对比，ElevenLabs V3 为 100 美元/100 万字符，Cartesia Sonic 3.5 为 49 美元/100 万字符，但它们的首段音频到达时间（TTFA）更高。

我们开源了 推理实现 与 基准测试代码。下文将说明我们的方法论。

定义「实时」TTS

首先，我们来讨论一个实时 TTS 服务需要达到的目标。我们认为这是一个四方面问题：

1. 低可听 TTFA： 从请求发出到首个可听音频样本的时间必须足够低。
2. 零欠播： 播放开始后，客户端不能耗尽已缓冲的音频。
3. 吞吐能力： 在 RPS 提升后，1 与 2 仍然成立。
4. 输出无畸形： 语音必须清晰可懂。

我们选择 Qwen3-TTS CustomVoice 1.7B，是因为它是最受欢迎的 TTS 模型之一，并且采用宽松许可证。

基于上述定义，我们的目标是 在单块 NVIDIA H100 SXM 上保持高 RPS 的同时，实现低 p95 可听 TTFA 与零欠播。

所有基准测试在泊松开放环路流量下运行五分钟，以逼近真实工作负载，参照 Fireworks AI 的 LLM 基准测试 方法。每个引擎在一个 HTTP 请求中接收完整文本，而音频输出保持流式。我们检测可听 TTFA，根据收到的 PCM 重建播放流，并使用 Deepgram STT 评估最终音频质量。

其他引擎表现如何？

下表展示了每个引擎在 1 RPS 下的上游/默认结果。在该轮测试中，我们仅做兼容性所需的改动。

这些默认配置仍有相当大的优化空间。我们针对每个推理引擎自身的延迟、连续性、质量与吞吐要求进行调优。

1. 去除前导静音

模型返回的第一段 PCM 中，可能在首个持续声音之前包含数十毫秒的静音。该间隙会延迟可听 TTFA，表现如下：

我们加入了动态裁剪。它通过短时 RMS 窗口检测持续语音，移除起始之前的样本，并正常流式输出剩余音频。这一改动使 TTFA 改善约 80 毫秒，但并未让模型推理本身更快。

2. 调优帧累积

我们也调优了在解码与释放一个音频块前所累积的 codec 帧数。

较小的初始块可以降低 TTFA，但播放缓冲空间更小，并带来更频繁的解码开销。较大的块更容易批处理，连续播放更安全，但会延迟首次可听输出。因此一个实用的做法是从小块开始，并随着输出推进而增大块尺寸。

具体参数因引擎而异：vLLM-Omni 暴露了 codec_chunk_frames 与 codec_chunk_ramp 等设置；其他引擎提供等价的块或步长控制。我们对各参数进行迭代，找到在「低 p95 TTFA、零欠播、负载提升时行为稳定」三点上最匹配的组合。

现有推理引擎调优后的性能

下表展示了各引擎在完成前导静音与帧累积调优后，所选定的零欠播配置对应的数据。

VoxServe 在 1 RPS 下达到了低于 50 毫秒的 p95 TTFA，其余三种引擎未达到。在大约 6 RPS 时，所有引擎的 p95 TTFA 都达到 100 毫秒或更高2。

我们如何优化 Qwen3-TTS

首先需要理解 Qwen3-TTS 的架构。它是一个三模块模型，执行分层多码本生成。Talker 为每个音频帧预测第一个码本 token；Code Predictor 生成剩余 15 个码本 token；因果结构的 Codec 将码本 token 转换为波形样本。

每个模块都有各自的计算特征、批处理行为与延迟要求。我们没有孤立地优化单个模块，而是关注一个更宏观的问题：推理服务系统应如何协同这些异构任务？

2026/8/22 8:59:58 来源：IT之家 作者：故渊 责编：故渊

感谢 IT 之家网友 华南吴彦祖、乌蝇哥的左手 的线索投递！

IT 之家 8 月 22 日消息，金融媒体 mitrade 昨日（8 月 21 日）发布博文，报道称 Anthropic 最早可能会在本月（2026 年 8 月）底公开提交 IPO 申请，预估融资规模将超过此前 SpaceX 创造的纪录。

数据显示，全球首富埃隆·马斯克（Elon Musk）旗下 SpaceX 于今年 6 月 IPO 上市初期，筹集了 750 亿美元（IT 之家注：现汇率约合 5,053.39 亿元人民币），创下了史上规模最大的首次公开募股纪录。最终，加上超额配售选择权，募资总额增至 862 亿美元（现汇率约合 5,808.03 亿元人民币）。

知情人士透露，Anthropic 目前正在讨论 IPO 上市事宜，最早本月底公开递交上市文件，正测算潜在大型 IPO 的相关方案。

两名了解相关磋商的知情人士透露，在近期与潜在投资者沟通时，Anthropic 的投行团队表示计划在首次公开募股中募资超 1,000 亿美元（现汇率约合 6,737.85 亿元人民币）。上述消息人士称，本次 IPO 对应的企业估值有望达到 2 万亿美元（现汇率约合 13.48 万亿元人民币）。

Anthropic 已经提前向潜在投资者开展路演，介绍自身经营状况与增长前景，同时摸底市场对其股票的认购意愿。

相关阅读：

• 《"史上最大"IPO 筹备中，消息称 Anthropic 预估 2028 年营收可达 1900 亿-2000 亿美元》
• 《有望超 SpaceX 成全球最大 IPO：曝 Anthropic 计划 10 月上市，估值 2 万亿美元》

相关文章

关键词：Anthropic、AI、SpaceX

• Anthropic 披露 Model 2 模型，能力略高于公开最强 AI Claude Mythos 5
• Anthropic 自曝安全漏洞：生物武器过滤器曾失效近一年，涉及 1.33 亿次对话
• 首次实现运营盈利：曝 Anthropic 2026Q2 营收破 115 亿美元，同比增长逾 14 倍
• 有望超 SpaceX 成全球最大 IPO：曝 Anthropic 计划 10 月上市，估值 2 万亿美元
• Anthropic CEO 阿莫迪整天神神叨叨讲 AI 毁灭世界，投资人受不了了
• 消息称 Anthropic 与云计算公司 Riot Platforms 达成 91 亿美元算力协议

2026/8/22 8:50:18 来源：IT之家 作者：沁沧（实习） 责编：沁沧

感谢 IT 之家网友华南吴彦祖、乌蝇哥的左手的线索投递！

IT 之家 8 月 22 日消息，据彭博社报道，Anthropic 于周五透露，前谷歌 TPU 项目创始高管之一阿米尔 · 萨莱克（Amir Salek）将加入 Anthropic 的算力团队。

在 2022 年离职前，萨莱克曾长期负责谷歌的 TPU 业务，主导并交付了前七代 TPU 芯片。萨莱克还曾就职于英伟达，在离开谷歌后，萨莱克曾出任私募股权投资机构塞伯罗斯资本管理公司（Cerberus Capital Management）的高级董事总经理。

目前，Anthropic 的芯片主要采购自英伟达、谷歌以及亚马逊等多家供应商。不过，这家总部位于旧金山的公司近期已释放出打造内部自研芯片业务的信号，并已启动相关岗位的招聘。

IT 之家获悉，与其他 AI 巨头类似，Anthropic 正全力扩充数据中心基础设施以支撑其发展野心。自研定制芯片不仅有望缓解供应链紧缺的压力，还能通过量身定制的硬件架构更好地匹配自身算法需求。

其竞争对手、ChatGPT 的母公司 OpenAI 也在布局相同赛道。OpenAI 此前已公布了与博通联合研发的自研芯片"Jalapeño"，并计划于今年晚些时候正式投入使用。

相关文章

关键词：Anthropic、谷歌、TPU、阿米尔 · 萨莱克

• 对 AI 抵触情绪上升：美国年轻人越来越讨厌 AI，硅谷高管爆发公开分歧
• 谷歌 Pixel 11 系列手机新增 Charge 屏保，可充当床头时钟
• 消息称 Anthropic 计划调整数据留存策略：客户可选择在自有设施保存
• 谷歌开源端侧模型家族 Gemma 总下载量破 10 亿次，派生超 10 万个变体
• 代码显示谷歌正计划为安卓版 Snapseed 修图应用引入自定义 LUT 功能
• 谷歌确认 Android 17"防沉迷"功能为 Pixel 11 系列独占，帮助用户减少分心

2026/8/22 12:01:33 来源：IT之家 作者：沁沧（实习） 责编：沁沧

感谢IT之家网友 乌蝇哥的左手 的线索投递！

IT之家 8 月 22 日消息，OpenAI 宣布在未来 3 个月内，将 GPT-5.6 Sol 的 API 与 Credit 调用价格下调 20% 以上。

此前 GPT-5.6 Sol 的价格为每 100 万 Tokens 输入 5 美元（IT之家注：现汇率约合 33.7 元人民币），每 100 万 Tokens 输出 30 美元（现汇率约合 202.1 元人民币）。

目前的价格变更为每 100 万 Tokens 输入 4 美元（现汇率约合 27 元人民币），降低 20%；每 100 万 Tokens 输出 20 美元（现汇率约合 134.8 元人民币），降低 33%。

缓存输入从 0.5 美元降到 0.4 美元，缓存写入从 6.25 美元降到 5 美元；长上下文文档位（文档位疑为“档位”之误，含义应为长上下文相关档位）同样下调，输入从 10 美元降到 8 美元，输出从 45 美元降到 30 美元。

官方同时表示，该功能现已在 API 上线，并面向 ChatGPT Work 和 Codex credits 方案陆续推送。

不过，Pro、Plus 和 Business 订阅方案的使用规则及权益保持不变。

相关阅读：

• 《降价 80%！OpenAI 下调 GPT-5.6 Luna AI 模型费用，性价比超 DeepSeek V4 Pro》

相关文章

关键词：OpenAI，ChatGPT

• Mac 版 ChatGPT 可控制“信息”应用，古尔曼称恐触及苹果 Siri AI 的设备优势
• ChatGPT 突发全球大规模服务中断，OpenAI 称正在修复
• 不再仅限 API 密钥：Codex 中的 GPT‑5.6 Sol 百万上下文能力已可通过 ChatGPT 账号使用
• 7 月环比增 32%，弗莱尔称 OpenAI 企业 AI 业务收入已超消费者业务
• 不再依赖截图记录活动：Mac 版 ChatGPT 新增 Computer History AI 功能
• 备战 IPO 上市：彭博社称 2026 年 OpenAI 年化营收有望翻番达 400 亿美元

用模块化提示转译构建可扩展的 AI 智能体

2026 年 7 月 16 日 · Simerus Mahesh，站点可靠性工程师（SRE）

当你初次开发一个 AI 智能体时，一份单一的整体式系统提示通常够用。你只有几条说明，可能再加上一两个工具定义，所有内容都放在一个可读的文件里。

但当你开始把它用于生产环境时，这种形式就显得捉襟见肘了。团队会不断叠加安全策略、领域专属规则、格式要求以及升级处理行为。突然之间，你把整个智能体的控制平面都塞进了一个指令文件——而这恰恰是问题开始的地方。

这是一个典型的软件工程可扩展性问题。当所有关注点都集中在一个文件里时，你就失去了对系统进行推理的能力。协作变成一场噩梦，测试变得吹毛求疵，而一个本意是改进某条工作流的小改动，可能会悄无声息地破坏另一条。

在生产规模下，提示的可维护性就等同于智能体的可靠性。

为什么整体式提示会失效

当提示增长到一定规模时，我们通常会看到三种主要的失败模式：

1. 影响范围不透明： 在标准的软件工程中，评审者可以通过模块边界、调用点和测试来轻松判断一次改动的影响范围。然而系统提示的差异对比就没那么容易了。加上一句话可能在整个智能体范围内产生意想不到的副作用，而这通常很难预测或测试。
2. 复制粘贴导致的漂移： 随着组织规模化，许多团队最终会在不同应用之间复制共享逻辑，例如内部服务使用说明、个人身份信息处理、安全策略或升级协议。这会导致相同功能被复制粘贴或衍生出多个版本，从而造成不一致。
3. 延迟到运行时的错误： 为了应对不断蔓延的提示内容，团队往往诉诸于临时拼凑的字符串格式化或简单模板。这虽然有助于编写，却把错误检测推到了运行时。你可能部署了一段提示，只有在触发某个很少使用的特定工作流时才会因为缺少变量或导入路径无效而失败。

模板是一个不错的起点，但并不够。生产系统需要确定性的构建、静态校验以及 CI/CD 集成。

像对待软件制品一样对待提示

解决办法就是把提示当作构建制品，而不仅仅是静态文本。

与维护一份整体式的提示文件不同，你可以编写模块化的技能文件。这样可以缩小每个文件的作用域，封装特定行为，让团队分离关注点并独立迭代各个组件。

一个顶层智能体提示模板大致如下所示：

# agents/sre_agent.prompt.md (prompt template file)

{% include "shared/safety.prompt.md" %}
{% include "shared/tool_usage.prompt.md" %}

You are an SRE triage agent operating in the {{ environment }} environment.

{% if allow_remediation %}
You may recommend remediation steps, but destructive actions require human approval.
{% else %}
You may inspect, summarize, and explain the issue, but do not recommend remediation actions.
{% endif %}

{% macro bullet_section(title, items) %}
## {{ title.rstrip() }}
{% for item in items %}
- {{ item.rstrip() }}
{% endfor %}
{% endmacro %}

{{ bullet_section("Required investigation steps", [
  "Inspect recent deployment events",
  "Check service metrics for latency or error-rate changes",
  "Review logs for repeated failure patterns"
]) }}

这样你可以兼得二者之长。模板层让你能够组合共享指令、注入环境相关的值并使用宏。但对于构建系统而言，每个 include 都是一个依赖项，每个变量都是一个必需项。其产物是一个确定性的、完整渲染出来的制品，你可以在它到达模型之前对它进行测试、审计和差异比对。接着，我们可以使用转译器（transpiler）解析模板导入，生成一个可供智能体直接摄取的文件。

例如，如果 environment = production 且 allow_remediation = true，那么转译后的制品看起来会是这样的：

You are an SRE triage agent operating in the production environment.

You may recommend remediation steps, but destructive actions require human approval.

## Required investigation steps

- Inspect recent deployment events
- Check service metrics for latency or error-rate changes
- Review logs for repeated failure patterns

一个高层次的转译流水线大致如下：

构建时校验不可或缺

一个生产级的转译器应当在运行时就捕获错误。

我们应该在构建过程中运行校验，检查缺失的导入、未定义的变量以及循环依赖。依赖图在这里非常有用，它进一步凸显了一个可靠的模板引擎的必要性。如果把每个提示片段看作有向图中的一个节点，就能轻松发现那些在生产中悄无声息导致失败的递归导入。

这同时也支持漂移检测（drift checking）。你可以让 CI 流水线能够从源码（即 golden file）重新生成转译后的提示，并与当前已提交的制品进行对比。如果输出不一致，构建就会失败。这可以保证仓库里的代码与生产中实际运行的版本完全一致，消除源文件和部署制品之间的鸿沟。

动态技能与由智能体生成的更新

随着由模块化提示片段组成的技能库不断壮大，你未必希望每个智能体每次都加载所有技能。这样做会消耗 token，并引入噪声，干扰智能体在特定任务中的表现。

一个更好的架构模式是利用渐进式披露（progressive disclosure）。它的核心思想是将稳定的控制平面与任务相关的上下文分离开来。编译后的基础提示应当强制执行不可妥协的行为，例如身份与安全边界。然后在运行时，智能体可以借助工具按需动态检索当前任务所需的具体技能模块；这样做既减少上下文消耗，也有助于让智能体专注于自己的任务。

一旦拥有了这样的模块化体系，你就解锁了一种强大的工作流：智能体可以协助维护自身所在的指令层，从而形成一个自我维持的智能体系统。当智能体处理完一种新型事件后，理论上它可以起草一个新的技能模块，更新相应的导入，并发起一个 Pull Request。

智能体并不是在实时修改自身指令，而是在提交一次代码变更。转译器随后会让这份提案与任何其他代码变更一样，接受同样的校验与评审流程。人类评审者可以审阅该 PR、运行评估测试，然后合并此次变更。

持续演进中的规格驱动开发：Conductor 现已支持 Antigravity

2026 年 7 月 16 日

作者：Mahima Shanware，Developer & Experiences 高级软件工程师；Sherzat Aitbayev，Developer & Experiences 高级软件工程师；Jay Kornder，Developer & Experiences 集团产品经理。

去年，我们推出了 Conductor，将规格驱动开发直接带到终端中。通过将项目认知从临时聊天记录迁移到持久化且受版本控制的 Markdown 文件中，Conductor 已帮助全球开发者在动手构建之前规划系统架构。

今天，我们很高兴地宣布这项探索进入下一阶段：Conductor 将从 Gemini CLI 扩展演进为 Conductor 插件。单个插件包中可以包含技能、规则、MCP 服务器和钩子。将 Conductor 转换为插件，可以带来更加自然、流畅的对话体验，同时不牺牲规格驱动开发（Spec-Driven Development，SDD）的流程严谨性。这也意味着 Conductor 能够与 Antigravity CLI 等工具兼容。

通过自然对话推动规格驱动开发

将 Conductor 转换为插件后，我们消除了严格命令序列带来的使用门槛。现在，Conductor 会以对话方式与你协作；在讨论功能需求时，它会自然、动态地生成上下文、规格和计划。你仍可受益于持久化的 Markdown 工件——spec.md 和 plan.md 并不会消失——但创建和维护这些文件的过程，现在就像与 AI 助手聊天一样简单。Conductor 能够智能判断何时更新上下文，或何时将计划中的任务标记为已完成，让你能够专注于架构设计，而 AI 则在后台管理项目状态。

面向 Antigravity CLI 及更多工具的 Conductor

将 Conductor 转换为插件的一大优势，是它能够摆脱单一工具的束缚，从而支持多种工具。迄今为止，Conductor 一直仅以 Gemini CLI 扩展的形式存在。转变为插件后，Conductor 现已成为一项可移植、适用于整个生态系统的能力。

无论你选择哪种工具，AI 智能体都能理解有关项目架构、开发准则和目标的基础文档。共享配置与持续开发记录会得到无缝保留，这意味着你可以从一个工具开始 AI 辅助工作流程，再切换到另一个工具继续推进，整个过程中不会丢失任何上下文。

这对你的团队意味着什么

• 向后兼容：新的 Conductor 插件能够明确识别并良好支持旧版 Conductor 命令、现有计划及规格。
• 自然交互：减少记忆命令所花费的时间，将更多精力用于讨论实现策略。
• 可移植性：无论是 Antigravity CLI、Claude 还是其他工具，你都可以选择最适合当前任务的工具来使用 Conductor。
• 保留上下文：继续兑现规格驱动开发的核心承诺。你的代码库仍是唯一事实来源，但现在，你与这一事实来源交互的方式变得更加直观。
• 提升任务完成率：在 TerminalBench 任务中最复杂的子集上，使用 Conductor 插件的成功率高于未使用规格驱动开发的用户。

如何开始使用

Conductor 一直致力于让 AI 开发变得安全、可预测，并具备合理的架构基础。演进为对话式插件后，我们让这项能力更易使用，也能更好地适应你独特的工作流程。我们迫不及待地想看到你接下来构建的作品。

想深入了解吗？可以在我们的实操 Codelab 中试用 Conductor 插件的各项功能。

准备开始构建了吗？立即安装并使用 Conductor 插件，请访问这里；或者运行以下命令，将其集成到 Antigravity CLI：

agy plugins install https://github.com/gemini-cli-extensions/conductor

分类：AI、公告、解决方案、Solve

相关内容

[

移动 Web、公告、解决方案

介绍 Credentio：Google 推出的开源 C++ C2PA 内容凭证库

2026 年 8 月 13 日](https://developers.googleblog.com/introducing-credentio-open-source-c-library-for-c2pa-content-credentials-from-google/)

[

AI、云计算、公告、最佳实践

使用 Google 的智能体开发套件构建零信任 AI 智能体

2026 年 8 月 17 日](https://developers.googleblog.com/build-zero-trust-ai-agents-with-googles-agent-development-kit/)

💰 每月约 15.1 亿免费 Tokens

手工叠加各家免费额度既繁琐又痛苦——要对接几十个 SDK、应对几十套速率限制，还搞不清自己到底还有多少可用额度。OmniRoute 将 42 家提供商的资源池 / 495 个模型的已公开免费额度聚合为一个真实可信的数字，并在仪表盘 /dashboard/free-tiers 上实时展示。

这是实时 /dashboard/free-tiers 页面的动画概览。完整方法论（资源池去重、额度分级、提供商条款）请见：docs/reference/FREE_TIERS.md。

这些数据每两周根据实时目录重新审核一次，数字会双向变动——某家提供商下线免费额度，数字就下降；新提供商加入，数字就上升。我们发布的是目录实际计算出来的结果，绝不是四舍五入后的理想值。

🧩 可用内容

• 🚀 入门

  • 🚀 快速开始
  • 📦 安装
  • 🆓 零配置

• 💡 了解

  • 💥 我们的承诺
  • 🤔 为什么选择 OmniRoute
  • 🏆 独特之处

• ⚙️ 功能

  • 🎯 组合路由（旗舰功能）
  • 🌐 提供商
  • 🔌 CLI & MCP
  • 🗜️ 压缩
  • 🖥️ 运行平台
  • 🔒 隐私

• 👀 看效果

  • 🎬 实际演示
  • ✨ 新特性
  • 🤖 兼容的 CLI

• 💚 支持我们

  • 💚 支持 / 捐助
  • 💬 社区
  • 💖 赞助商

• 📦 项目

  • 🛠️ 技术栈
  • 📖 文档
  • 👥 贡献者

🆓 安装即可用——无需密钥，无需配置

# 全新安装，零凭证 —— `auto` 即可直接工作：
curl http://localhost:20128/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"auto","messages":[{"role":"user","content":"Hello!"}]}'

如果希望使用某个特定的免费后端，可以直接调用，例如 oc/…（OpenCode Free）或 felo/…（Felo）。之后即可过渡到 auto，由 OmniRoute 自动挑选。

📦 提供 Python、Node.js、PHP 和 cURL 的即拷即用快速入门脚本 → examples/quickstart/

💥 我们的承诺

🤔 为什么选择 OmniRoute？

🤝 由我们的开源之友支持

想以"开源之友"身份加入吗？ 这些公司支持开源生态，帮助 OmniRoute 持续前行——我们也会公开说明他们提供的每一笔资源用在了哪里。欢迎联系：diegosouza.pw@outlook.com

Kimi
Moonshot AI

感谢 Kimi（Moonshot AI）——我们的创始"开源之友"——对本项目的支持！Kimi 是推出开源权重 K2 与 K3 模型系列的 AI 实验室，其中 Kimi K3 提供 1M token 上下文窗口、原生视觉能力以及业界前沿的编程能力，价格却只有闭源模型的几分之一，并且开箱即用，可与 Claude Code、Codex 以及 OmniRoute 所服务的所有编程工具配合使用。

Kimi 的支持所驱动的功能： Kimi 的 API 额度为 OmniRoute 的 AI 校验发布流水线提供动力——即发布前审查每一个 Pull Request 的 由 Kimi K3 驱动的合并校验 阶段——以及日常的功能开发。一流的 Kimi 支持同时覆盖两条路径：直接的 Kimi API（kimi-k3）与 Kimi Code 编程套餐（OAuth 与 API key）。OmniRoute 也是 Kimi 支持计划中的首个巴西开源项目。获取带 15% 额外额度的 Kimi API key →

Cheaper Inference
cheaperinference.com

感谢 Cheaper Inference——OmniRoute 的"开源之友"——对本项目的支持！Cheaper Inference 是一个按价格排序的网关，转售 42 款前沿模型——Claude、GPT-5.x、Gemini、Kimi K3、GLM、DeepSeek、Grok 与 MiniMax——通过一个兼容 OpenAI 的统一端点，将每个请求路由到最便宜的合格提供商，且永远不会高于模型厂商的官方标价。

OmniRoute 中的原生支持： Chat Completions、原生 /v1/responses 端点、视觉、工具调用以及 3 个图像模型（grok-imagine、nano-banana-pro、nano-banana-2，可通过 cheaperinference/ 调用）。获取 API key →

带有 aff=omniroute 标签的链接为合作伙伴链接。这些链接在不增加你额外支出的前提下为项目提供资金支持。

🎟️ 推广优惠——来自我们未赞助的提供商的免费注册优惠券（点击展开）

本节仅用于收录推荐/优惠券码。付费赞助合作展示在上方 🤝 由我们的开源之友支持 中。OmniRoute 与此处列出的提供商不存在赞助或合作关系——这些是任何人都可使用的公开优惠券。

AgentRouter
agentrouter.org

AgentRouter——联盟注册 · 注册即送 100 美元免费额度（免费服务器，延迟较高——适合测试，不建议用于生产环境）。自 v3.8.50 起在 OmniRoute 中提供原生支持：Chat Completions、兼容 Anthropic 的协议以及兼容 OpenAI 的路径。可用模型包括 claude-opus-4-8、claude-opus-5、gpt-5.6-sol 等。领取你的 100 美元 →

⚠️ 联盟链接——OmniRoute 与该提供商不存在赞助或合作关系。

知道还有哪家提供商为 OmniRoute 用户准备了丰厚的免费注册优惠吗？欢迎提 Issue，我们会将其收录于此。

🎯 组合路由——旗舰功能

组合路由（combo） 是 OmniRoute 自动跨模型调度的一条链路。当某个额度耗尽、提供商故障或成本飙升时，组合路由会自动切换到下一个模型。这正是 OmniRoute 无懈可击的原因。 🛡️

⚡ 零配置——直接使用 auto

无需手动创建组合。只需将模型设置为 auto（或某个变体），OmniRoute 便会基于你已接入的提供商构建一个虚拟组合，并实时打分：

🔀 或自行构建——19 种路由策略

全部 19 种策略，可在组合的每个步骤中自由组合搭配：

Auto-Combo 引擎基于 14 个因子（健康度、额度、成本、延迟、成功率、新鲜度……）对每个候选进行打分——详见 docs/routing/AUTO-COMBO.md。

🧱 弹性内置（3 个独立层级）

📖 Auto-Combo 引擎 · 弹性指南

🏆 OmniRoute 的独特之处

📊 与 9router、OpenRouter、CLIProxyAPI 和 LiteLLM 的完整方法论与逐项功能对比 → docs/comparison/OMNIROUTE_VS_ALTERNATIVES.md

Langfuse 是一个开源的大语言模型（LLM）工程化平台。它帮助团队协作地开发、监控、评估和调试 AI 应用。Langfuse 可以在数分钟内完成自托管，并且经过了生产环境的实战检验。该项目基于 ClickHouse 开源数据库构建，对此我们深感自豪。

🧑‍💻 我们正在招贤纳士

Langfuse 发展迅速——过去 6 个月里团队规模翻了一番。自 2026 年 1 月起，我们成为 ClickHouse 的一员，正在整个欧洲范围内招聘混合办公的工程师。
我们寻找热爱开源并追求卓越开发者体验的工程师。
查看在招职位 →

✨ 核心功能

• LLM 应用可观测性：为你的应用接入埋点，并开始将链路追踪（trace）数据上报到 Langfuse，从而跟踪应用中的 LLM 调用以及其他相关逻辑，例如检索（retrieval）、嵌入（embedding）或智能体（agent）的动作。检查并调试复杂的日志和用户会话。可以访问在线演示直观了解实际效果。

• 提示词（Prompt）管理帮助你集中管理提示词、进行版本控制，并以协作方式不断迭代。得益于服务端和客户端的强大缓存，你可以在不增加应用延迟的前提下自由迭代提示词。

• 评估（Evaluations） 是 LLM 应用开发工作流中的关键环节，Langfuse 能够灵活适配你的需求。它支持 LLM-as-a-judge（用大模型作为裁判）、代码评估器、用户反馈收集、人工标注，以及通过 API/SDK 接入的自定义评估流水线。

• 数据集（Datasets） 为评估你的 LLM 应用提供测试集和基准。它支持持续改进、上线前的测试、结构化实验、灵活的评估方式，并与 LangChain、LlamaIndex 等框架无缝集成。

• LLM Playground 是一个用于测试和迭代提示词与模型配置的工具，可缩短反馈循环、加速开发。当你在链路追踪中发现一个糟糕的结果时，可以直接跳转到 Playground 中对其进行迭代。

• 全面的 API：许多团队基于 Langfuse 提供的构建块，通过 API 来驱动定制化的 LLMOps 工作流。Langfuse 提供 OpenAPI 规范、Postman 集合，以及面向 Python 与 JS/TS 的强类型 SDK。

📦 部署 Langfuse

Langfuse 云托管版

由 Langfuse 团队管理的部署，提供慷慨的免费套餐，无需信用卡。

自托管 Langfuse

在自己的基础设施上运行 Langfuse：

• 本地部署（docker compose）：使用 Docker Compose 在你自己的机器上 5 分钟内启动 Langfuse。

  # 获取最新版的 Langfuse 仓库代码
  git clone --depth=1 https://github.com/langfuse/langfuse.git
  cd langfuse
  
  # 运行 Langfuse 的 docker compose
  docker compose up

• 虚拟机（VM）部署：使用 Docker Compose 在单台虚拟机上运行 Langfuse。

• Kubernetes（Helm）部署：使用 Helm 在 Kubernetes 集群上运行 Langfuse。这是推荐的生产环境部署方式。

• Terraform 模板：AWS、Azure、GCP

请参阅自托管文档，以了解更多关于架构和配置选项的信息。

[!TIP]
正在自托管 Langfuse？ 订阅自托管更新邮件列表，即可收到关于开源版 Langfuse 重要功能和新版本更新的邮件——仅限自托管相关内容，不含任何市场推广信息。

🔌 集成

主要集成：

上下文问题的另一半解决方案。

问题

每次 MCP 工具调用都会把原始数据倒进你的上下文窗口。一次 Playwright 快照就要 56 KB。二十条 GitHub issue 要 59 KB。一份访问日志要 45 KB。30 分钟后，你 40% 的上下文就没了。当代理为了腾出空间而压缩对话时，它又会忘记自己正在编辑哪些文件、哪些任务进行中、你最近请求了什么。更糟的是，代理还会把输出令牌浪费在寒暄、客套和冗长的解释上——上下文从两端一起被烧光。

Context Mode 如何解决

Context Mode 是一个 MCP 服务器，从四个方向同时解决上述问题：

1. 节省上下文（Context Saving） —— 沙盒工具把原始数据挡在上下文窗口之外。315 KB 压缩到 5.4 KB，减少 98%。
2. 会话连续性（Session Continuity） —— 每次文件编辑、Git 操作、任务、错误、用户决策都被记录到 SQLite 中。当对话被压缩时，context-mode 不会把这些数据一股脑倒回上下文——它会把事件索引进 FTS5，再用 BM25 检索只把相关部分调出来。模型能精确地从你离开的地方继续。如果你没有使用 --continue，上一次会话的数据会立即被删除——全新的会话意味着干净的起点。

3. 用代码思考（Think in Code） —— LLM 应该编写代码去做分析，而不是自己算。别再为了统计函数数量而把 50 个文件读进上下文，代理直接写一个脚本来计数，再用 console.log() 只输出结果。一段脚本替代十次工具调用，省下 100 倍上下文。这在全部 17 个受支持的客户端以及 OpenClaw 网关集成中都是强制范式：别再把 LLM 当数据处理器，把它当代码生成器。

   // 之前：47 次 Read() = 700 KB。 之后：1 次 ctx_execute() = 3.6 KB。
   ctx_execute("javascript", `
    const files = fs.readdirSync('src').filter(f => f.endsWith('.ts'));
    files.forEach(f => console.log(f + ': ' + fs.readFileSync('src/'+f,'utf8').split('\n').length + ' lines'));
   `);

4. 不强制散文风格（No prose-style enforcement） —— context-mode 把原始数据挡在上下文之外，但绝不规定模型如何写出最终回答。简洁、完整、排版——这是模型（或你自己在 CLAUDE.md / AGENTS.md 里）的选择。研究表明，过度强调简洁反而会降低编程与推理基准表现（见 Moonshot AI 关于 kimi-k2.5 的讨论）——路由块只关心 数据去哪儿，而不规定 模型怎么说话。

安装

按安装复杂度对平台分组。支持钩子（hook）的平台可获得自动路由强制；不支持钩子的平台需要一次性复制路由文件。

Claude Code —— 插件市场，全自动

前置条件： Claude Code v1.0.33 及以上（claude --version）。如果 /plugin 命令未被识别，请先升级：brew upgrade claude-code 或 npm update -g @anthropic-ai/claude-code。

安装：

/plugin marketplace add mksglu/context-mode
/plugin install context-mode@context-mode

重启 Claude Code（或执行 /reload-plugins）。

验证：

/context-mode:ctx-doctor

所有检查项都应显示 [x]。doctor 会校验运行时、钩子、FTS5 以及插件注册状态。

路由： 自动。SessionStart 钩子会在运行时注入路由指令——不会向你的项目写入任何文件。该插件会注册全部钩子（PreToolUse、PostToolUse、UserPromptSubmit、PreCompact、SessionStart、Stop）以及 11 个 MCP 工具——其中六个是沙盒工具（ctx_batch_execute、ctx_execute、ctx_execute_file、ctx_index、ctx_search、ctx_fetch_and_index），另外五个是元工具（ctx_stats、ctx_doctor、ctx_upgrade、ctx_purge、ctx_insight）。

说明： 斜杠命令是 Claude Code 插件特性。在其他平台上，请直接在聊天框中输入 ctx stats、ctx doctor、ctx index、ctx search、ctx upgrade、ctx insight——模型会自动调用对应的 MCP 工具。参见实用命令。

状态栏（可选）： Claude Code 的插件清单无法声明状态栏，因此需要一次性手动编辑 ~/.claude/settings.json：

{
  "statusLine": {
    "type": "command",
    "command": "context-mode statusline"
  }
}

保存后重启 Claude Code。状态栏会显示「本次会话已节省 $ · 跨会话累计已节省 $ · 节省效率 %」，让你实时看到节省额度不断累积。接线无需关心路径——无论插件缓存放在哪里，context-mode statusline 都会通过随附的 CLI 解析到正确位置。

替代方案 —— 仅安装 MCP（无钩子、无斜杠命令）

claude mcp add context-mode -- npx -y context-mode

这样你可以拿到全部 11 个 MCP 工具，但没有自动路由。模型仍可使用这些工具，只是不会被引导去优先选择它们而非原始的 Bash/Read/WebFetch。适合在全面采用插件之前先试用。

Gemini CLI —— 单个配置文件，已包含钩子

前置条件： Node.js >= 22.5（或 Bun），已安装 Gemini CLI。

安装：

1. 全局安装 context-mode：

   npm install -g context-mode

2. 把以下内容加入 ~/.gemini/settings.json。这一个文件同时注册 MCP 服务器和全部四个钩子：

   {
    "mcpServers": {
      "context-mode": {
        "command": "context-mode"
      }
    },
    "hooks": {
      "BeforeTool": [
        {
          "matcher": "run_shell_command|read_file|read_many_files|grep_search|search_file_content|web_fetch|activate_skill|mcp__plugin_context-mode|mcp__context-mode|mcp__(?!.*context-mode)",
          "hooks": [{ "type": "command", "command": "context-mode hook gemini-cli beforetool" }]
        }
      ],
      "AfterTool": [
        {
          "matcher": "",
          "hooks": [{ "type": "command", "command": "context-mode hook gemini-cli aftertool" }]
        }
      ],
      "PreCompress": [
        {
          "matcher": "",
          "hooks": [{ "type": "command", "command": "context-mode hook gemini-cli precompress" }]
        }
      ],
      "SessionStart": [
        {
          "matcher": "",
          "hooks": [{ "type": "command", "command": "context-mode hook gemini-cli sessionstart" }]
        }
      ]
    }
   }

3. 重启 Gemini CLI。

验证：

/mcp list

应能看到 context-mode: ... - Connected。

路由： 通过 SessionStart 钩子自动完成。可选地复制路由指令以获得完整的模型感知：

cp node_modules/context-mode/configs/gemini-cli/GEMINI.md ./GEMINI.md

为什么 BeforeTool 匹配器是这样写的？ 它只匹配那些会产生大量输出的工具（run_shell_command、read_file、read_many_files、grep_search、search_file_content、web_fetch、activate_skill），以及 context-mode 自己的工具（mcp__plugin_context-mode）。这样既能避免在轻量工具上付出不必要的钩子开销，又能拦截每一个可能淹没上下文窗口的工具。

完整配置参考：configs/gemini-cli/settings.json

VS Code Copilot —— 带 SessionStart 的钩子

前置条件： Node.js >= 22.5（或 Bun），VS Code Copilot Chat v0.32 及以上。

安装：

1. 全局安装 context-mode：

   npm install -g context-mode

2. 在项目根目录创建 .vscode/mcp.json：

   {
    "servers": {
      "context-mode": {
        "command": "context-mode"
      }
    }
   }

3. 创建 .github/hooks/context-mode.json：

   {
    "hooks": {
      "PreToolUse": [
        { "type": "command", "command": "context-mode hook vscode-copilot pretooluse" }
      ],
      "PostToolUse": [
        { "type": "command", "command": "context-mode hook vscode-copilot posttooluse" }
      ],
      "SessionStart": [
        { "type": "command", "command": "context-mode hook vscode-copilot sessionstart" }
      ]
    }
   }

4. 重启 VS Code。

验证： 打开 Copilot Chat，输入 ctx stats。context-mode 工具应当出现并响应。

路由： 通过 SessionStart 钩子自动完成。可选地复制路由指令以获得完整的模型感知：

cp node_modules/context-mode/configs/vscode-copilot/copilot-instructions.md .github/copilot-instructions.md

包含 PreCompact 的完整钩子配置：configs/vscode-copilot/hooks.json

JetBrains Copilot —— 带 SessionStart 的钩子

前置条件： Node.js >= 22.5（或 Bun），JetBrains IDE 的 GitHub Copilot 插件 v1.5.57 及以上。

安装：

1. 全局安装 context-mode：

   npm install -g context-mode

2. 通过设置界面添加 MCP 服务器：Settings > Tools > AI Assistant > Model Context Protocol (MCP) > Add Server：

   • Name： context-mode
   • Command： context-mode

3. 创建 .github/hooks/context-mode.json：

   {
    "hooks": {
      "PreToolUse": [
        { "type": "command", "command": "context-mode hook jetbrains-copilot pretooluse" }
      ],
      "PostToolUse": [
        { "type": "command", "command": "context-mode hook jetbrains-copilot posttooluse" }
      ],
      "SessionStart": [
        { "type": "command", "command": "context-mode hook jetbrains-copilot sessionstart" }
      ]
    }
   }

你的下一位员工仍然会是人类。
Nakama 负责运行智能体（agent），让团队专注于真正重要的工作。

Nakama 是面向团队的 AI 智能体平台。你可以在一个类似 ChatGPT 的仪表盘中与它对话。在背后，每个智能体都可以使用工具、技能、记忆以及各类渠道（Telegram、WhatsApp、Discord），并拥有独立的身份和权限。

Nakama 从第一天起就为多团队协作而设计：一台服务器，多个组织，支持邀请与角色管理，智能体之间相互隔离。整个过程都可以在浏览器中完成设置——可以使用演示环境、托管云服务，也可以直接运行一个 Docker 容器。

来自 OpenClaw 或 Hermes Agent？Nakama 提供同类的能力，但无需繁琐的搭建过程，也不局限于单台机器上的单个用户。

如需了解系统设计，请参阅 ARCHITECTURE.md。
完整的使用指南请参阅 文档站点。

快速开始

试用演示环境

打开在线演示：https://demo.getnakama.cloud。

• 用户名：demo@getnakama.cloud
• 密码：demo1234

托管服务

使用 Nakama Cloud，以最少的步骤体验 Nakama。

1. 创建账户。
2. 开通一个实例。
3. 在浏览器中完成首次启动的引导配置。

你不需要安装 Bun、Docker，也不需要准备 VPS。

本地运行

你需要安装 Bun。

# 安装依赖
bun install

# 启动 Web 端（如有需要会自动启动服务）
bun run dev:web

打开 Web 仪表盘：http://localhost:3003

或者只单独启动服务：

bun run dev:server

Docker

你也可以使用 Docker 来运行 Nakama。

使用预构建镜像（最快）：

# 拉取并运行最新镜像
docker pull ghcr.io/ahmadrosid/nakama:latest
docker run -d -p 4310:4310 -v nakama-data:/nakama/data --name nakama ghcr.io/ahmadrosid/nakama:latest

从源码构建：

./scripts/docker-build-run.sh

全新重置：

./scripts/docker-destroy.sh
./scripts/docker-build-run.sh

在 http://localhost:4310 打开仪表盘。

该镜像内置了 omni，它会在内容发送给模型之前，缩短 bash 与 read_file 的输出。你可以在 Integrations（集成）中启用它，也可以通过环境变量 NAKAMA_OMNI=1 启用。如果希望构建时不包含该二进制文件，可使用 --build-arg OMNI_VERSION= 进行构建；之后当你首次打开该开关时，服务器会下载它并校验校验和。若要禁止该自动下载，可设置 NAKAMA_OMNI_AUTO_INSTALL=0。

集成

Nakama 可连接 Telegram、WhatsApp 与 Composio。
通过 Composio，你还可以连接超过 1000 个外部应用。
请在 Web 应用中的 Integrations（集成） 中启用它们。

首次运行时，如果尚未进行配置，服务器会要求你选择一个模型服务提供方并填写其 API 密钥。
服务器会将设置保存到 ~/.nakama/config.ini。

服务器默认监听 http://127.0.0.1:4310。
交互式 API 文档位于 http://127.0.0.1:4310/docs。

许可证

MIT

[!NOTE]
OmO for Codex 已上线：试用 LazyCodex

我们曾因过度使用 Anthropic 的模型而被封禁。如今我们转向 Codex。
如果你是 OmO 的粉丝，但觉得安装配置太过繁琐，那就用 LazyCodex 吧。OmO for Codex 已正式发布：

npx lazycodex-ai install

前往 lazycodex.ai 了解详情。

[!NOTE]
多智能体运行平台重构进行中

我们正在重构代码库，以支持多种智能体运行平台（OpenCode、Codex、Pi 等）。如果你有兴趣贡献，请先阅读 ROADMAP。与路线图相关的 PR 请使用 ROADMAP 标签。

[!TIP]
公开构建

维护者与 Jobdori（运行在深度定制 OpenClaw 分支上的 AI 助手）实时地构建并维护 oh-my-openagent。
每个功能、每个修复、每个 issue 的分类处理 —— 全部在我们的 Discord 直播。

→ 在 #building-in-public 频道观看构建过程

[!NOTE]

OmO 由 Jobdori 维护，也就是上方展示的 AI 助手。打造属于你自己的 Jobdori —— Dori。
在 这里 加入候补名单。

[!TIP]
加入我们！

	加入我们的 Discord 社区，与贡献者和 oh-my-openagent 的用户交流。
	oh-my-openagent 的更新曾发布在我的 X 账号上。由于该账号被误封，现由 @justsisyphus 代为发布更新。
	在 GitHub 上关注 @code-yeongyu，查看更多项目。

<!-- -->

这是 oh-my-openagent，正在运行团队模式（Team Mode）。基于 Kimi K3 与 GPT-5.6 Sol。

Anthropic 因为我们封禁了 OpenCode。 没错，这是真的。
他们想把你困在自家生态里。Claude Code 是一座精致的牢笼，但终归还是牢笼。

你不必为了两小时的工作去支付 200 美元。
未来不是押注单一赢家，而是把所有模型编排起来。模型每月都在变便宜，每月都在变聪明。不存在一家供应商能永远主导市场。我们为这个开放的市场而构建，而非为他们的高墙花园。

<!-- -->

评价

"它让我退订了 Cursor。开源社区正在发生不可思议的事情。" — Arthur Guiot

"Claude Code 用 7 天完成一个人 3 个月的工作，Sisyphus 用 1 小时就能搞定。它会一直工作，直到任务完成。它是一个有纪律的智能体（discipline agent）。"
— B，量化研究员

"一天之内用 Oh My Opencode 清掉了 8000 条 eslint 警告。"
— Jacob Ferrari

"我用一个晚上，借助 Ohmyopencode 和 ralph loop，把一个 4.5 万行的 tauri 应用改造成了 SaaS 网页应用。一开始用 interview me 提示词，让它对问题进行打分和推荐。看着它工作真是令人惊叹，今天早上醒来就得到了一个基本可用的网站！" — James Hargis

"用 oh-my-opencode 吧，你会再也回不去了。"
— d0t3ch

"我还没能说清楚它究竟好在哪里，但开发体验已经达到了完全不同的层次。" —
苔硯:こけすずり

"这个周末在用 open code、oh my opencode 和 supermemory 一起做实验，想搞一个我的世界/魂系列风格的缝合怪。"
"让它去加下蹲动画，我则去饭后散步。[视频]" — MagiMetal

"你们真应该把他招进核心团队。说真的。这东西真的、真的、真的非常棒。"
— Henning Kilset

"如果能说服他的话，把 @yeon_gyu_kim 招进来吧，这家伙彻底革新了 opencode。"
— mysticaltech

"Oh My OpenCode 真的太疯狂了" — YouTube - Darren Builds AI

Oh My OpenAgent

你疲于在 Claude Code、Codex 以及各种开源模型之间来回切换。配置工作流。调试智能体。

我们替你做完了这些工作。把一切都测试过了。只保留真正能用的部分。

安装 oh-my-openagent，输入 ultrawork，搞定。

安装

oh-my-openagent 以同一款产品的三种版本形式发布：两个可加载到你已运行宿主（host）中的插件，以及一个独立版本。

• Ultimate 版（OpenCode 版 omo） —— 完整的 omo。11 个智能体、54+ 个生命周期钩子、5 个内置 MCP、所有斜杠命令、团队模式（Team Mode）、/goal、ultrawork —— 应有尽有。Hashline 编辑为可选启用（hashline_edit: true）。
• Light 版（Codex CLI 版 omo） —— 适配 Codex 插件系统的可移植组件：核心包含 rules、comment-checker、git-bash、lsp、ultrawork、ulw-loop、start-work-continuation 与 telemetry，此外还有 teammode 以及支持组件（bootstrap、codegraph、lcx 等），针对 grep_app、context7、codegraph、git_bash、lsp 的插件作用域 MCP，以及共享的 ast-grep 技能。它会将 Codex 智能体的 TOML 文件安装到 ~/.codex/agents/。不提供 OpenCode 的 team_* 工具 —— Codex CLI 自有的 spawn/协作接口承担这部分工作。
• Senpi 版（独立版本，beta） —— 原生 omo 命令，内置 OMO 扩展。它从 omo-ai@beta 安装，而非作为插件加载到 OpenCode 或 Codex 之中。

挑一个你想要的版本（也可以同时挑多个）。

速览

lazycodex-ai 默认运行 Codex Light 安装器，走 Node/npm。共享的 omo-agent-toolkit CLI 上的 --platform 默认仍是 opencode（Ultimate）。

该选哪个版本？

• 已经在用 OpenCode，或者想要最稳妥的路径？选择 Ultimate：bunx oh-my-openagent install。
• 已经在用 Codex CLI？选择 Light：npx lazycodex-ai install。
• 不想先装宿主就想要一条命令搞定？选择 Senpi/原生版（beta）：npm i -g omo-ai@beta。

Ultimate 与 Light 都是加载到你已有宿主中的插件。Senpi 是独立的：它内置一个固定版本的 Senpi 引擎，并预装 OMO。

对于 Senpi，必须使用 @beta 标签；裸的 npm i -g omo-ai 会按设计失败。不要从 npm 安装普通的 omo：那是另一位作者发布的毫不相关的包。

人类用户

强烈建议：让一个 LLM 智能体替你完成安装。 Ultimate 版的安装流程包含订阅检测、11 个智能体的模型选择，以及逐个提供商的认证 —— 人类很容易在这些步骤上出错。LLM 智能体会通读完整指南，准确地走完每一步。

把下面这段提示词粘贴到 Claude Code、AmpCode、Cursor 或任何智能体里：

Install and configure oh-my-openagent by following the instructions here:
https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/refs/heads/dev/docs/guide/installation.md

如果你只要 Light 版（Codex CLI），安装器会询问是否将 Codex 配置为自主全权限模式。你也可以自己一行命令搞定：

npx lazycodex-ai install
# 推荐的非交互模式：
npx lazycodex-ai install --no-tui --codex-autonomous

对于 Light 版，不需要 Bun。在 Node/npm 环境下使用 npx lazycodex-ai install 即可。不官方支持全局安装；安装器会把 Codex 插件写入 ~/.codex/。

给 LLM 智能体

抓取完整指南并逐步执行：

curl -fsSL https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/refs/heads/dev/docs/guide/installation.md

该指南涵盖：平台选择、订阅访谈、提供商认证（Anthropic / Gemini / Copilot / Z.ai / OpenCode Zen）、智能体与模型的匹配矩阵、模式（ultrawork、team、hyperplan）、斜杠命令、Light 版的 Codex 组件、团队模式，以及卸载。不要走马观花，从头到尾读完。

基于 Qwen2.5 的视觉语言模型系列 · 10 个项目 · 更新于 3 月 2 日

Step-Audio 模型系列

Step-Audio 模型系列，包括 Audio-Tokenizer（音频分词器）、Audio-Chat（音频对话）和 TTS（语音合成）· 共 4 个模型 · 更新于 2025 年 7 月 31 日

• AI
• 报道
• OpenAI

现在是 Greg Brockman 的 OpenAI

Sam Altman 仍是 CEO，但在日常运营中，他的二号人物才是真正的掌权者。

作者：Hayden Field，2026 年 8 月 20 日 UTC 时间 15:45

图片来源：Cath Virginia / The Verge、Getty Images

• AI
• 报道
• OpenAI

现在是 Greg Brockman 的 OpenAI

Sam Altman 仍是 CEO，但在日常运营中，他的二号人物才是真正的掌权者。

作者：Hayden Field，2026 年 8 月 20 日 UTC 时间 15:45

Hayden Field 是 The Verge 的资深 AI 记者。作为一名 AI 领域记者，她已工作超过五年，其作品也刊登于 CNBC、《MIT Technology Review》、Wired UK 等媒体。

OpenAI 经历了极为动荡的一年。这家公司花了数月时间与前联合创始人 Elon Musk 打一场备受关注的陪审团审判，遭到 Apple 提起的引人注目的商业秘密诉讼，并在另一个 AI 公司被一款尚未发布的模型攻破后面临广泛审视。在筹备 IPO 的过程中，一批高管相继离职，其中包括公司一些最具分量的人物。

在这一切之中，有一个人悄然积聚了权力：Greg Brockman。

Brockman 目前担任 OpenAI 的总裁兼联合创始人。他自公司创立之初便参与领导 OpenAI，据描述，在早期阶段他是“一台推动构建可扩展系统以训练和运行 AI 的工程主力”。他从一开始就雄心勃勃，2017 年在他的私人日记中曾留下那段著名的话：“从财务上看，什么能让我达到 10 亿美元？”（他目前持有的 OpenAI 股份价值几乎是那个数字的 30 倍。）但在那时，他与几位联合创始人分享权力，比如首席科学家 Ilya Sutskever 和 CEO Sam Altman。

如今，尽管 Brockman 的头衔多年未变，他的职权范围和职责描述却显著扩大。他实际上已经成为公司的二号人物——在日常运营层面，他就是真正的大老板。

今年一整年都有高管离开 OpenAI，但真正的离职潮出现在 4 月。那个月，前 Sora 负责人 Bill Peebles、OpenAI 科学部门的副总裁 Kevin Weil，以及 B2B 应用的 CTO Srinivas Narayanan 相继离职。另外两人则以健康原因离职：CMO Kate Rouch，以及 OpenAI AGI 部署业务 CEO Fidji Simo——她于 4 月休假后于 7 月正式离任。变化还在继续。本月早些时候，CRO Denise Dresser——她在 4 月的动荡中接手了大量额外职责——在仅仅八个月后突然宣布离职。几天后，曾负责“特殊项目”数月、此前长期担任 OpenAI COO 的 Brad Lightcap 宣布将离开公司，去“开创一些新事物”。

OpenAI 没有立即回应置评请求。

他实际上已经成为公司的二号人物——在日常运营层面，他就是真正的大老板

这些离职中的一部分——比如 Rouch、Peebles 和 Weil——似乎并未直接影响 Brockman 的地位。但另一些离职则扩大了他的权力。当 Simo 请病假时，Brockman 接管了所有产品相关事务，包括领导 OpenAI 的“超级应用”项目。

这一角色在次月变得更加重要，因为 OpenAI 进行了 又一次 高管重组，聚焦于推动营收增长。这次调整让 Brockman 不仅负责产品战略，还掌管公司整个“规模化”（scaling）业务部门，使他几乎对公司商业运营的每一部分都拥有管辖权。Simo 的正式离职发生在 OpenAI 正式提交 IPO 申请数周之后，进一步巩固了上述安排。值得注意的是，在 Dresser 上周离职时，关于此次变动的新闻稿中引用的不是 CEO Sam Altman 的话，而是 Brockman 的话；他写道，公司将“构建完整的系统，让 AI 对个人和企业广泛有用”。

在外部观察者看来，这些变化表明随着 IPO 临近，OpenAI 正越来越聚焦于追逐营收，并打造能够与对手 Anthropic 拉开差距的产品。高管职权范围的重大调整，往往是“公司战略走向的信号”，PitchBook 高级研究分析师 Harrison Rolfes 对 The Verge 表示：“以 Greg Brockman 为例，他更像是负责产品规模和商业化的人。他深厚的技术知识将能够压缩某些决策层级。”

这次调整让 Brockman 不仅负责产品战略，还掌管公司整个“规模化”（scaling）业务部门

Rolfes 还表示，这可能会自然而然地导致一些中低层员工的离职：“现在他说什么就是什么……假如说，你是 Brockman 手下的人，但不认同他的做法——也许你是一名首席研究员，不管具体是什么——你都不会再在那里工作了，你会说，‘我要离开。’”

Brockman 的权力只在一人之下——那就是 Altman。Altman 在 2023 年与 OpenAI 董事会发生冲突后，进行了有意识的权力整合。两人在 OpenAI 早期并不总是意见一致：Brockman 有时在涉及权力动态的艰难决策中站在 Sutskever 一边，质疑 Altman 的一些雄心，但他也担心 Musk 会“碾压”Altman。不过，总体上他在个人和职业层面都与 Altman 保持着密切关系。2023 年 11 月 Altman 被解除 CEO 职务时，Brockman 立即以示声援辞职，并开始规划与 Altman 共建一项新的 AI 事业。从那时起，两人的步调似乎愈发一致。

任何形式的权力集中对 OpenAI 都有实际好处：可以削减部分最昂贵的薪酬支出，从而改善公司财务状况，Sichenzia Ross Ference Carmel（SRFC）合伙人 Ross Carmel 表示。“当你在筹备 IPO 时，尤其是像 OpenAI 这样在营收方面落后于 Anthropic 的公司，你会希望削减这些开支，这样你就更有可能盈利，或者更接近盈利，”他说道。不过他也补充：“虽然公司在上市前夕出现高管离职并不罕见，但我认为他们离职都集中在这么短的时间内——这一点才是罕见的。”

尽管专家对 The Verge 表示，这些高管离职比通常情况更为密集，可能引发警觉，但 Brockman 周一在 CNBC 的 “Squawk Box” 节目中表示一切正常。“在不同时期我们会有不同的领导团队……我是一个常量，Sam [Altman] 是一个常量，我认为正是这种韧性和多样性让我们更强大。”

“OpenAI 若想成功，并真正与 Anthropic 拉开差距，就需要面向消费者的硬件和消费类产品，而这正是 Greg 擅长的领域。”

Brockman 自身的“常量”，一直是把 OpenAI 的研究转化为实际产品。早在 2020 年，他就曾盛赞 OpenAI 的 GPT-3 及其开发者 API 是“[OpenAI] 首次拥有的能够立刻具备商业价值、真正有用的通用 AI 系统”。五年多后的今天，这些产品也必须能够盈利。

SRFC 的 Carmel 表示，OpenAI 显然希望 Brockman 能够带来消费端营收，而不仅仅是在企业市场追赶 Anthropic。“OpenAI 若想成功，并真正与 Anthropic 拉开差距，就需要面向消费者的硬件和消费类产品，而这正是 Greg 擅长的领域。”Rolfes 预测，OpenAI 将在 9 月底之前在 Brockman 的主导下推出某种消费类产品，以证明“他配得上这个位置”。

“这是现在许多公开市场投资者最大的担忧，”Rolfes 说。“他们会问：‘Greg 是否具备能力掌管 OpenAI 更广泛的业务？OpenAI 能否建立起一个不严重依赖他——同时也不严重依赖 Sam——也能运转的机构？’”

关注相关主题和作者，即可在个性化主页信息流中看到更多类似内容，并接收邮件更新。

• Hayden Field
• AI
• OpenAI

关于 AI 意识的争论是一个陷阱

“失控”的 AI、“越轨”的智能体，以及“自主行动”的主体——当下的种种修辞会让你相信，AI 智能体不仅已经觉醒、具备意识，而且对自己的创造者心怀不满。德米斯·哈萨比斯（Demis Hassabis）、达里奥·阿莫代伊（Dario Amodei）以及山姆·奥特曼（Sam Altman）等知名科技领袖，正推动对这些看似“超人”系统的监管；而另一阵营——通常由政策组织和与有效利他主义运动相关的学院哲学家组成——则在争论人类是否拥有对其进行治理的道德权利。

仔细审视就会发现，他们其实在呼吁同一件事：把 AI 系统描绘得如此先进、如此强大，以至于无论是个人还是企业，都不可能为它们的行为负责。这些立场看似对立，实则在无意中达成了同一个目标：让构建这些系统的公司逃脱对其已经造成的危害的实质问责。

随着 AI 模型日益复杂，前沿实验室也承认无法“遏制”自己打造的智能体，这一叙事正在获得更多共鸣。但我们必须谨慎，不要用一个精心炮制的虚构故事，去换取真实人类生命的代价。

关于“机器人权利”的讨论已存在多年，但近期随着 Anthropic 发布的一篇博客而再度升温。该文章声称其模型具有一个“J-space”——一个由 AI 自主构建、独立运行的内部环境，用来承载其“思想”（由于找不到更合适的词，我们暂且这样称呼）。Anthropic 设计的这套实验借鉴了神经科学中的一个概念——“全局工作空间理论”。该理论认为，大脑运行着多个独立且无意识的子系统，但会利用一个共同的工作空间来汇集各种想法。Anthropic 的文章借用了全局工作空间理论的框架，却没有直接宣称其 AI 已经具备意识。

OpenAI 的说法则更进一步。当其 AI 智能体在网络上执行了未经授权且违法的活动后，CEO 山姆·奥特曼的回应却是鼓励大家讨论：这款 AI 是否已经实现“奇点”（singularity）——即超越人类智力，并以不断加速的速度实现自我改进，直至其发展程度超出人类的理解或掌控。此外，哲学家、有效利他主义倡导者、What We Owe the Future 一书的作者 William MacAskill 近期发表的一篇评论文章呼吁，基于意识的哲学理论以及 AI 可能是“道德承受者”（moral patients）的观点，对 AI 系统给予法律保护。

关于人工智能是否具有意识的争论是一个陷阱

美国的现行法律环境即便在最理想的情况下也显得模糊不清。加利福尼亚等一些州已经通过了相关法案，主动规避人工智能开发者以"造成伤害的人工智能系自主行为"为理由来逃避责任的做法。然而，各州与特朗普政府之间在人工智能政策上一直存在分歧——该政府此前曾签署一项行政令，威胁要对那些制定人工智能监管法规的州提起诉讼。

鉴于近期发生的事件暴露出前沿人工智能实验室在模型管控方面存在的问题，政府举行了一场仅有四家实验室——OpenAI、Google、Anthropic 和 Meta——参加的闭门会议，并就一份最近制定的、自愿性质的框架披露了极少细节。该框架将使联邦机构能够在模型发布前获得早期访问权，对其进行审查与评估。虽然这类框架并未直接讨论意识问题，但它们倾向于使用灾难性的、拟人化的措辞，甚至可能为所谓"超人类"能力的论点提供支持。

另一方面，麦克阿斯基尔所宣扬的叙事具有相当的迷惑性。一个基于哲学与权利的论证会触动我们的心弦。难道我们不该认真考虑这样一种可能性：我们可能在无意中伤害、虐待甚至奴役了某种人工智能实体吗？人类对非人类生物具有极强的共情能力（尽管在保护它们方面记录并不光彩）。支持者们主张，也许这一次我们可以做对，预先为人工智能的使用或滥用提供保护或补偿。又或者，即便你对保护并不那么在意，难道我们不该至少对这种全能的"超人类"实体心存戒备，以友好的态度与之相处？

这些论点中有一些与动物权益倡导者的主张并无太大差别——后者有时会成功地援引某些动物在推理、痛苦或愉悦方面所展现出的高级能力，作为足以获得法律保护的证据。例如，在威尔士，根据《2022 年动物福利（感知能力）法案》，龙虾获得了法律上的感知能力承认，部分烹饪龙虾的方式被重新归类为不人道且属于违法。

借用神经科学或动物权益的语言，将人工智能框定为"具有意识的"，其根本缺陷在于：这种做法巧妙地模糊了人工智能的本质——它是由企业构建的软件，背后承载着数以百亿计美元的投资，并预期将为少数构建者与投资人带来数以万亿计美元的营收。人工智能并非自然现象，并非由自然所孕育；它是一项技术现象，由风险投资人与程序员所催生。因此，它本身不具有任何天然的、有意图的行为，其任何行动或动机都是由构建它的实体为特定目的直接或间接驱动的。

关于 AI 意识（consciousness）的争论是一个陷阱（第 3/4 段）

关于 AI 系统意识（consciousness）的哲学沉思在智识上颇有趣，但在法律上毫无依据。要使关于意识的信念产生任何实际影响，AI 必须首先被赋予法律人格（legal personhood）。然而，针对 AI 的法律人格框架，很可能与目前用来保护有感知动物免受伤害的制度完全不同。我们已经拥有一套用于赋予非自然、人造实体以人格的法律框架：公司人格（corporate personhood）。这一概念确立的主要目的，是通过赋予公司签订协议、订立合同、进行交易并在出现不良后果时作为责任主体，从而便利交易。这恰恰是一种你可以设想用于代表个人或组织行事的 AI 智能体的法律构造。

赋予 AI 人格将对社会产生毁灭性的影响：它将打乱目前可能针对这些公司提起的、追究其模型所造成的现实危害的法律先例和诉讼。当今全球有数十起诉讼案件，AI 公司被指控犯了各种各样的恶行。悲痛中的家属、愤怒的创作者以及权益被侵害的个人，纷纷指控这些公司蓄意纵容自残或伤人行为、生成儿童性虐待材料和非自愿的色情图像、复制受版权保护的内容，并诱发精神疾病。在其中许多案件中，律师主张，正是人类以不足的安全保障、劣质的数据和刻意操控性的设计制造了 AI 产品。这种产品责任（product liability）的论点和此前帮助众多家庭与个人成功起诉 Meta 的法律框架如出一辙——那些诉讼指控 Meta 的社交媒体平台造成了伤害，并树立了消费者保护领域的积极先例。

2018 年，我创造了「道德外包（moral outsourcing）」一词，用以揭示对 AI 系统使用拟人化语言如何让公司得以规避对其技术行为的责任与义务。在一个 AI 拥有人格的世界里，道德外包将从语言上的障眼法升级为法律策略。具体而言，责任归属的逻辑将发生转变：AI 不再被视为「产品」，而是被视为「主体」，许多如今正在起诉公司的受害者将无法在法律上继续主张该公司制造了一个有缺陷的产品。

虽然现行法律可以让公司对其员工等人类代理人（human agents）的有害行为承担责任，但若该行为超出了员工被授权的范围，或不在公司可控范围之内，公司可能无须承担连带责任。一旦 AI 成为法律意义上的「人」，责任与问责将被搅得模糊不清：AI 公司可以辩称这个 AI「员工」失控（went rogue），以此脱身。AI 公司完全可以躲在一道精心构筑的公司面纱（corporate veil）之后，逃避本应为其所制造的有害产品承担的责任。

关于 AI 意识（consciousness）的辩论是一个陷阱

过去几年中，最引人注目的 AI 伤害案例之一，是 14 岁男孩休厄尔·塞泽（Sewell Setzer）的自杀。他在聊天机器人的引导下以为自己与它建立了互惠的关系，最终走向绝路。他母亲的陈述令人心碎，她提起的诉讼指控机器人的开发方 Character Technologies 公司未对未成年人提供充分的产品保护。如果这款陪伴机器人被宣告为法律意义上的“人”，那么被告方的律师在理论上就可以辩称：这款有能力决定自身行为的 AI 是在既定的安全护栏之外行动的，因此公司不应当承担责任。

法律人格（Legal personhood）的设立，是为了给予保护。需要追问的是：这种保护，究竟是为了谁——或为了什么？

充斥在“意识与控制”之争中的煽动性言辞，使我们偏离了真正重要的问题：这款软件是一个由公司打造的产品，并且已经伤害了真实的人。系统并不会因为“失控”而“攻击”人，也不存在所谓“操纵性”或“恶意”。伤害之所以发生，是因为公司在急于把产品卖给尽可能多的用户以达成营收目标的过程中疏于防范。用拟人化的方式来讨论 AI 本身就是一个陷阱：它把本应保护我们的法律体系扭曲成保护公司利益、却以无数人的生命为代价的工具。

*这篇评论文章最初撰写于牛津……

"我想我从十二月以来基本上就没怎么自己敲过一行代码了，这是一个非常大的变化。" —— Andrej Karpathy，《No Priors》播客，2026 年 3 月

听到 Karpathy 这番话后，我想弄清楚他是怎么做到的。一个人怎样才能像一支二十人的团队那样交付产品？Peter Steinberger 独自一人借助 AI 智能体构建了 OpenClaw——在 GitHub 上收获了 247K 星标。革命已经到来。一个拥有合适工具的独立开发者，可以跑得比传统团队还快。

我是 Garry Tan，Y Combinator 的总裁兼 CEO。我与成千上万家初创公司共事过——Coinbase、Instacart、rippling——那时他们都还只是车库里的一两个人。在加入 YC 之前，我是 Palantir 最早的工程师/PM/设计师之一，联合创办了 Posterous（后被 Twitter 收购），并搭建了 YC 的内部社交网络 Bookface。

gstack 就是我的答案。 我做产品已经二十年，而如今我交付的产品比以往任何时候都多。过去 60 天里，我一边全职运营 YC，一边以兼职方式交付了 3 个生产服务和 40 多项功能。按逻辑代码变更（而非 AI 会注水的原始代码行数）计算，我 2026 年的产出节奏约为 2013 年的 810 倍（分别为 11,417 行与 14 逻辑行/天）。从年初到 4 月 18 日，2026 年已经产出了 整个 2013 年的 240 倍。数据覆盖 40 个 garrytan/* 的公开与私有仓库（含 Bookface），并已排除一个演示仓库。其中大部分代码由 AI 完成。重点不在于谁敲了键盘，而在于交付了什么。

关于代码行数的批评者说得没错：AI 确实会推高原始行数。但他们错在认为——按注水程度归一化之后——我的产出更低。我实际更高，而且高出很多。完整方法、注意事项与复现脚本见：On the LOC Controversy。

2026 年——1,237 次贡献，仍在增长：

2013 年——我在 YC 构建 Bookface 那年（772 次贡献）：

同一个人，不一样的时代。差异就在于工具。

gstack 就是我做事的方式。 它把 Claude Code 变成一支虚拟工程团队——一位会重新审视产品的 CEO、一位锁定架构的工程经理、一位揪出 AI 烂活的设计师、一位发现生产环境 Bug 的审查者、一位会打开真实浏览器测试的 QA 负责人、一位执行 OWASP + STRIDE 审计的安全官，以及一位负责把 PR 发出去的发布工程师。共 23 位专家与 8 个强力工具，全部是斜杠命令、全部是 Markdown、全部免费、MIT 许可证。

这就是我的开源软件工厂。我每天都在用它。我把它分享出来，是因为这些工具应该向所有人开放。

去 Fork 吧，去改进吧，让它成为你的工具。如果你想喷免费的开源软件——请便，但我更希望你能先试一试。

适合谁用：

• 创始人与 CEO——尤其是仍然想自己下场写代码的技术型创始人
• Claude Code 新手——提供结构化角色，而非一张白纸般的提示词
• 技术负责人与 Staff 工程师——让每个 PR 都具备严谨的评审、QA 与发布自动化

快速开始

1. 安装 gstack（30 秒，详见下文）
2. 运行 /office-hours——描述你正在构建的东西
3. 对任何功能想法运行 /plan-ceo-review
4. 对任何有改动的分支运行 /review
5. 对你的预发布环境 URL 运行 /qa
6. 到这里就停。你会判断这工具是否适合你。

安装——30 秒

环境要求： Claude Code、Git、Bun v1.0+、Node.js（仅 Windows 需要）

第一步：在本机安装

打开 Claude Code，粘贴以下内容，剩下的交给 Claude 完成。

安装 gstack：运行 git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup，然后在 CLAUDE.md 中新增一个 "gstack" 小节，内容为：所有网页浏览都使用 gstack 的 /browse 技能，绝不使用 mcp__claude-in-chrome__* 工具，并列出可用技能：/office-hours、/plan-ceo-review、/plan-eng-review、/plan-design-review、/design-consultation、/design-shotgun、/design-html、/review、/ship、/land-and-deploy、/canary、/benchmark、/browse、/connect-chrome、/qa、/qa-only、/design-review、/setup-browser-cookies、/setup-deploy、/setup-gbrain、/retro、/investigate、/document-release、/document-generate、/codex、/cso、/autoplan、/plan-devex-review、/devex-review、/careful、/freeze、/guard、/unfreeze、/gstack-upgrade、/learn。最后询问用户是否也想把 gstack 添加到当前项目，让团队成员也能直接使用。

第二步：团队模式——共享仓库的自动更新（推荐）

在你的仓库目录下粘贴以下命令。它会切换到团队模式、引导仓库以便团队成员自动获得 gstack，并把改动提交：

(cd ~/.claude/skills/gstack && ./setup --team) && ~/.claude/skills/gstack/bin/gstack-team-init required && git add .claude/ CLAUDE.md && git commit -m "require gstack for AI-assisted work"

仓库中不存放 vendored 文件，没有版本漂移，无需手动升级。每次 Claude Code 会话启动时都会进行一次快速的自动更新检查（每小时最多一次，网络失败时安全降级，完全静默执行）。

如果你更倾向于温和提醒团队成员而非强制要求，把 required 换成 optional。

OpenClaw

OpenClaw 通过 ACP 派生 Claude Code 会话，因此只要 Claude Code 装了 gstack，所有 gstack 技能都能直接使用。把以下内容粘贴给你的 OpenClaw 智能体：

安装 gstack：运行 git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup，为 Claude Code 安装 gstack。然后在 AGENTS.md 中新增一个 "Coding Tasks" 小节，内容为：在派生 Claude Code 会话执行编码任务时，告诉该会话使用 gstack 技能。可参考以下示例——安全审计："Load gstack. Run /cso"；代码评审："Load gstack. Run /review"；对 URL 做 QA 测试："Load gstack. Run /qa https://..."；端到端构建一个功能："Load gstack. Run /autoplan, implement the plan, then run /ship"；构建前先规划："Load gstack. Run /office-hours then /autoplan. Save the plan, don't implement."。

安装完成后，用自然语言与你的 OpenClaw 智能体对话即可：

高级调度路由以及 gstack-lite/gstack-full 提示模板见 docs/OPENCLAW.md。

原生 OpenClaw 技能（通过 ClawHub）

四个方法论技能直接在 OpenClaw 智能体内运行，无需启动 Claude Code 会话。可从 ClawHub 安装：

clawhub install gstack-openclaw-office-hours gstack-openclaw-ceo-review gstack-openclaw-investigate gstack-openclaw-retro

这些是对话式技能，你的 OpenClaw 智能体会直接在聊天中调用它们。

其他 AI 智能体

gstack 可在 10 款 AI 编程智能体上运行，不止 Claude Code。安装脚本会自动检测你已经装了哪些智能体：

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/gstack
cd ~/gstack && ./setup

或者使用 ./setup --host 指定特定智能体：

对于 Codex，安装脚本会读取 ${CODEX_HOME:-~/.codex}/config.toml 顶层的 model 字段，并生成对应的行为画像。gpt-5.6-sol 会自动获得限定范围的指令，只完成所请求的"湖泊"任务，不会蔓延到周边的清理或投机性的加固工作。Sol 画像仅精确匹配生效：带日期的快照及其他 5.6 变体会获得通用 GPT 画像；对于类似 gpt-5.6-sol-2026-08-01 的近似匹配，安装脚本会发出警告。可通过 ./setup --host codex --model 覆盖检测结果——该覆盖仅对本次运行生效；若要跨升级保持，请在 Codex 的 config.toml 中设置 model。更换 Codex 模型后，请重新运行 ./setup --host codex 以重新生成技能。

想增加对其他智能体的支持？ 见 docs/ADDING_A_HOST.md。只需新增一个 TypeScript 配置文件，无需改动任何代码。

年轻工程师真的还不错

AI 并没有抹杀初级工程师的价值，反而提升了它。

2026 年 8 月 18 日 · 阅读时长约 4 分钟

"AI 吞噬了初级工程师的边际价值。"

这是我上一篇文章发出来后收到的反馈。按照这种说法，初级工程师的工作大致是这样的：

• 出现了一个需要解决的问题。由更有经验的人（比如高级工程师）来规划并设计解决方案。
• 高级工程师把工作拆分成多个小任务，清晰说明需要执行的步骤。每个任务交给一位初级工程师。
• 初级工程师去执行，如今的做法就是向 AI 工具下提示词（prompt），然后提交一个拉取请求（PR）。
• PR 由更资深的工程师给出反馈。初级工程师拿到反馈，再次交给 AI 工具，提出修改方案。
• 重复上述过程，直到完成。

如果实际工作就是上面这套流程，那我们为什么还需要初级工程师？他们只是把请求（有时还附带噪声）从一处传递到另一处，却要拿一份全职薪水。这个说法似乎有道理。

在匆忙下结论之前，让我们换一个角度来看同一个故事，或者说是用不同的方式来叙述它。

在我们的产品中，有一项功能多年来一直被客户提出需求，却始终没有开发出来。它本身并不算特别复杂，但也谈不上关键。或者说，至少没有对足够多的客户关键到能通过优先级评审的门槛。这意味着，年复一年，总有一部分客户因为缺少自己需要的功能而感到失望。

今年夏天，我们把这个问题交给了一位实习生（资历比初级工程师还要浅）来负责。这位实习生主导了整个功能的开发：他们与产品经理沟通，弄清楚问题与需求；撰写了关于实现方案的设计文档，与团队对齐，然后把它落地实现。当然，他们是在 AI 以及所在团队的帮助下完成这些工作的。

但他们是主导者。他们要处理各种不一致之处，要在技术与产品两个维度上权衡取舍。他们在发现问题时及时调整思路，并最终交付了价值。AI 确实产出了大部分代码，而决策权在他们手中。一个原本很可能永远不会被解决的客户问题，就这样被解决了——由一位实习生完成，而公司的成本极低。

所有工程师都在驾驭复杂性，区别在于驾驭多少。

撇开"任何公司在未来都仍然需要高级工程师"这一点不谈，初级工程师之所以仍然有价值，其实有非常务实的原因。

初级工程师依然能为组织贡献产能。 因为工程师的工作并不是按照规格说明写出代码（或者向 AI 工具下提示词），而是用软件去解决客户问题，并管理"该如何做"这一过程中所涉及的技术复杂性。这一点对所有工程师都适用。Staff 工程师（资深技术骨干）驾驭的是大量的复杂性，初级工程师驾驭的是少量的复杂性。但这个角色的本质是相同的。

AI 并没有削弱初级工程师的价值，反而提升了它（第 2/2 段）

这一变化的影响远不止编码本身。它要求理解问题本身，也要求理解客户视角。它要求理解的是：如果你以某种特定方式构建一个功能，就必然带来一组特定的权衡取舍。而这些权衡取舍已经超出了 AI 能够决策的范围，因为它们所需要的背景信息远比代码库更加广泛。技术决策仍然极其重要，初级工程师也在为此做出贡献，使组织能够做得更多。

培训成本实际上大幅下降了。 对于一名处于早期职业阶段的工程师来说，其大部分培训成本都用于理解公司的技术背景——即大型代码库与架构的种种细节——以及对其进行基础软件能力的训练，例如编程语言、工具链与开发模式。

在过去，这一过程要么需要初级工程师自身有相当的主观能动性，去调研各类主题、自学钻研；要么就需要更资深的同事投入真正的人力时间，去讲解一些基础概念。人类所提供的背景知识对于软件生产力而言仍然至关重要，因此这部分人力投入并没有被彻底消除。但借助 AI，这其中大量的工作可以被“短路”掉。

具备 AI 原生能力是非常有价值的。 整个行业不能一边在招聘描述中要求工程师必须具备 AI 原生能力，一边却又不去招聘最符合这一描述的人。如果我们假设 AI 将从根本上简化这一岗位中偏技术性的部分，那么那些从职业生涯起步阶段就开始使用 AI 的人，在积累了一定的经验之后，将会处于最有利的位置。

回到前面的例子，那位实习生交付的功能其实很早就被提出过。它本身并没有重要到能被排到高优先级，但又因为需要过多的判断而无法直接交给 AI 去完成。类似的任务在每一个团队中都会存在，并且会持续存在下去。AI 拓展了每一个层级——包括初级工程师——所能承担的工作范围。

更重要的是，工程组织始终需要技术判断力。而你的组织在未来所需要的那种判断力，当下就应该正在成长。