2026-04-08 13:00:00
我一直觉得 [[X]] 的 Bookmark 是个很尴尬的功能。收藏的时候特别顺手，回头找的时候却基本靠运气。我的书签列表也是这样，技术帖子、产品发布、研究分享、各种零碎灵感全都混在一起，存得越多，越像一个只能往里扔东西的抽屉。最近我频繁在用 [[Claude Code]] 和 [[Codex]]，于是对这件事更在意了：这些明明是我自己筛过一遍的信息，能不能别只躺在网页里，而是真正进到本地工作流里。
我看到 [[Field Theory CLI]] 的第一反应，就是这东西抓的点很准。它不是再造一个书签页面，也不是给收藏夹换一套花哨 UI，而是干脆把 X 的书签拉到本地文件和本地数据库里，再把搜索、分类、统计、Markdown 导出、知识库整理这些动作全接到命令行上。思路很直接，但就是这份直接让我觉得它靠谱。因为一旦书签进了本地，它就不再只是网页侧栏里那串几乎不会点开的历史记录了。
项目仓库在 https://github.com/afar1/fieldtheory-cli，官方页面在 https://www.fieldtheory.dev/cli/。如果你平时确实会在 X 上攒很多技术链接、开源项目、研究论文或者长贴，这个项目大概率会让你有点共鸣。
[[Field Theory CLI]] 最打动我的一点，是它对收藏夹这件事情的判断很现实。我使用这个项目之后，才发现我从开始使用 X 以来已经收藏了超过 9000 条内容，而这些内容之前一直都是不可搜索、不可分类、基本也谈不上再利用。不是书签没价值，而是它们被堆到最后，价值几乎被锁死了。
这个项目的解决方案也不绕。先把书签抓下来，变成你自己的本地数据；然后建立搜索索引；再看你是想做分类、统计，还是继续导出成 Markdown，甚至整理成知识库。官方 README 给出的默认目录是 ~/.ft-bookmarks/，里面至少会有 bookmarks.jsonl、bookmarks.db、bookmarks-meta.json 这几类文件。如果你走 API 模式，还会多出 oauth-token.json；如果继续用 ft md 或 ft wiki，还会生成 md/ 目录。
我自己最看重的就是这一步。一旦数据落到本地，整个问题就变了。你不再是被困在 X 的网页里翻旧收藏，而是手里真的有了一份自己的数据集。你可以全文检索，可以按作者、日期、分类过滤，可以做统计，也可以把它变成 Markdown 再扔给 AI 去问答。说白了，它解决的不是同步难题，而是“收藏之后就再也不看”的老问题。
安装没什么门槛，官方推荐命令就是：
npm install -g fieldtheory
要求也很明确，核心前提是 [[Node.js]] 20 及以上。装完以后你会得到 ft 这个命令，当然也可以直接调用 fieldtheory。
第一次上手，我建议按官方 quick start 来，先确认整个链路跑通，不要一开始就把所有高级功能全打开：
ft sync
ft search "distributed systems"
ft viz
ft categories
ft stats
ft sync 是整个流程的入口。按 README 的说法，第一次运行时它会尝试从浏览器会话里提取你当前的 X 登录状态，然后把书签下载到本地的 ~/.ft-bookmarks/。如果你在 macOS 上，这一步通常最顺手，因为项目一开始就是围绕 Mac 场景做的。macOS 支持 Chrome、Brave、Arc、Firefox 的会话同步，Linux 和 Windows 也写明可以通过 Firefox 或 OAuth API 模式来使用。
如果你不想让工具直接读浏览器会话，或者你本来就在非 macOS 环境里，那更稳妥的方式就是走 OAuth：
ft auth
ft sync --api
这套模式的跨平台兼容性更好，语义也更清楚。默认的 ft sync 用的是 X 网页端自己的内部 GraphQL 接口，官方文档已经明说了；而 ft sync --api 则是走 OAuth 认证后的 API 模式。前者省事，通常不需要你单独折腾开发者接口；后者更正规，也更适合跨平台环境。
如果只把 [[Field Theory CLI]] 当成一个“下载书签”的命令，那就有点低估它了。真正让我觉得它有意思的，是作者顺手把下载之后的利用场景也做进来了。根据当前的 ft --help 和 README，下面这些命令最值得先上手。
ft search "llm memory"
ft list --category tool
ft show 12345
ft classify
ft categories
ft domains
ft stats
ft viz
ft search 用的是 BM25 全文搜索，不是最基础的字符串匹配。这点很重要，因为书签这种东西，你大多数时候记不住精确标题，只记得大概和哪个概念、哪个框架、哪个作者有关。ft list、ft show、ft stats 则分别对应过滤、单条查看和整体统计，适合用来快速摸清自己的收藏到底都堆了些什么。
另一个让我眼前一亮的能力是分类。项目里既有 ft classify --regex 这种轻量、规则驱动的做法，也有 ft classify 这种直接调用大模型来分类的路线。当前 CLI 帮助里甚至明写了，这个动作依赖 claude 或 codex CLI。换句话说，它一开始就默认你会把本地书签和本地 AI 工具链一起用。这和很多传统 Bookmark 工具的思路很不一样，因为它不是停在“给内容加标签”这一步，而是把分类直接接进了 agent 工作流。
如果你收藏的大量内容本身就是论文、开源项目、产品发布、研究线程或者安全事件，这套分类体系会挺顺手。官方 README 里当前列出的默认类别包括 tool、security、technique、launch、research、opinion、commerce。它不算特别细，但拿来先把一团乱麻理出第一层结构，已经够用了。
我觉得 [[Field Theory CLI]] 和普通 Bookmark 工具真正拉开差距的地方，不是界面，而是后面的这几组命令：
ft md
ft wiki
ft ask "What have I bookmarked about MCP tools?"
ft ask "Which tools should I revisit this month?" --save
ft skill install
这里面的意思很明确。ft md 可以把书签导出成独立 Markdown 文件，ft wiki 可以进一步把它们整理成互相关联的知识库，ft ask 则是直接对这套本地知识库提问。我越来越觉得，个人知识管理里真正稀缺的不是“存链接”这件事，而是存下来之后还能不能继续查、继续问、继续重组。这个项目就是在补这一段。
如果你平时就在用 [[Obsidian]]、[[Claude Code]] 或 [[Codex]]，这个项目的价值会更明显。因为现在很多人的工作流已经变成这样：代码、文档、笔记、shell 命令都在本地协同，而 AI 代理只要能读到这些文件，就能继续帮你做搜索、总结、比较和判断。[[Field Theory CLI]] 做的事情，就是把原本锁在 X 产品里的 Bookmark 也拽进这套流程里。作者甚至直接提供了 ft skill install，用来给 Claude Code 和 Codex 安装 /fieldtheory skill。看到这里我基本就明白了，它压根不是后来才想到和 agent 结合，而是一开始就是按这个方向设计的。
所以这个工具最适合的，不是“我偶尔收藏两条推文”的用户，而是已经把 X 当成技术情报流、研究资料流或者项目观察流在用的人。你收藏过的内容，本质上就是你长期关注方向的一份样本库。样本库一旦进了本地知识系统，AI 才真的有机会帮你做更高层的整理和调用。
虽然我挺喜欢这个项目的方向，但有几个边界还是应该先说清楚，不然很容易把预期拉太高。
首先，它的核心价值是本地化和可搜索，不是云端多端同步。你如果要的是那种随手点开 App，就能在手机和网页之间无缝同步的消费级收藏工具，它可能不是最合适的选项。它更偏开发者，也更偏本地工作流。
其次，默认同步用的是 X 的内部 GraphQL 接口。官方文档已经把这件事说得很直白了。这种做法的好处是省事，不用受官方 API 配额限制；代价也很明显，它天然会受平台接口变化影响。所以我会把它看成一个很好用的个人工具，而不是某种被平台正式背书、可以永远稳定运行的官方集成。好在项目还提供了 ft auth 和 ft sync --api 这条更正规的路线，真遇到变化，至少还有备选方案。
再次，分类和问答能力虽然很吸引人，但它们依赖你本地本来就有相应的 AI 工具链。比如当前 CLI 帮助里明确写着，ft classify 需要 claude 或 codex CLI。也就是说，[[Field Theory CLI]] 不是自己内置了一整套远端 AI 服务，而是尽量复用你机器上已经有的 agent 环境。就工程设计来说，我反而很喜欢这种做法，因为它更轻，也更符合“数据留在本地”这件事。
最后，这个项目虽然已经不只是一个 “Mac 专用小工具” 了，但官方站点和 README 的表述还带着一点阶段性差异。简单说，首页强调的是它最早起家的环境，README 展示的是现在扩展后的能力。真要上手，还是以你自己的浏览器、操作系统、登录方式能不能跑通 ft sync 或 ft sync --api 为准，不要只看首页那一句话就下结论。
如果只用一句话来概括，我会说 [[Field Theory CLI]] 做的事情是：把原本死在平台里的 X Bookmarks，重新变成你自己能检索、能分类、能导出、还能交给 AI 继续工作的本地数据。
我喜欢这种工具，是因为它解决的不是“再做一个入口”，而是“把已经有的信息重新激活”。很多时候我们并不缺收藏能力，缺的是让收藏重新流动起来的那一步。[[Field Theory CLI]] 正好补上了这一段，而且做法非常贴近今天真实存在的本地 AI 工作流。对于已经在用 [[Obsidian]]、[[Claude Code]]、[[Codex]]，又长期把 X 当成信息雷达的人来说，它很值得试一试。
你不一定非要把它理解成一个书签工具。更准确一点说，它是一个把个人信息流回收到本地，再继续加工成知识库和 agent context 的 CLI。我自己很看好这个方向，因为接下来很多真正有价值的个人数据，大概率都会慢慢从“继续放在平台里”转向“先拿回本地，再交给自己的工具链处理”。而在这个方向上，[[Field Theory CLI]] 是一个很典型、也很有意思的开源项目。
2026-04-08 13:00:00
前面我分别写过使用 asdf-vm 管理编程语言多个版本和多版本管理工具 mise 使用详解。那两篇更偏工具介绍，适合第一次认识 asdf 和 mise。但真轮到自己迁移的时候，最关心的通常不是概念，而是另外一个问题：我已经在机器上用 asdf 管了很多年的 Python、Node.js、Ruby，现在如果想换到 mise，到底该怎么换，才能既不打断当前工作，又不把已有项目折腾乱。
我自己这段时间重新梳理了一遍本地环境，最后得出的结论很简单：不要一上来就卸载 asdf，也不要先把所有仓库里的 .tool-versions 全部改成 mise.toml。最稳妥的路线，是先让 Shell 切到 mise，然后继续复用已有的 .tool-versions 文件，等核心项目都验证稳定之后，再决定哪些项目值得进一步切到 mise 自己的配置格式。这样做的好处是迁移成本非常低，基本不会影响你今天就要交付的代码和脚本。
先说清楚一点，我并不是觉得 asdf 不能用了。尤其是 asdf 在 0.16.0 之后完成了 Go 重写，速度和维护性都比早年的 Bash 版本好很多，继续用完全没有问题。只是从我自己的日常体验来看，mise 在两个地方更合我胃口。
第一个地方是命令体系更扁平。以前在 asdf 里，安装插件、安装版本、写入本地版本，往往要分成好几步来做；而在 mise 里，很多常见动作可以直接收敛成一条 mise use。第二个地方是迁移成本确实低。官方文档明确提到 mise 可以直接读取 .tool-versions，也能通过 asdf backend 使用大量 asdf 插件。这意味着对于已经用 asdf 很久的人来说，mise 不是一套完全重新学习的新体系，而更像是在原有习惯上做一次更平滑的升级。
不过这里也有一个很重要的边界要提前讲明白：mise 虽然兼容 .tool-versions，但默认不会复用你 ~/.asdf 下面已经安装好的版本目录。也就是说，迁移之后第一次执行 mise install 的时候，它很可能还是会重新下载一遍你常用的 Python、Node.js 或者别的工具。这一点如果事先没意识到，迁移时很容易产生“为什么又下载一次”的错觉。
我建议在正式动手之前，先记住下面几件事情，这几件事情基本决定了整套迁移动作应该怎么做。
.tool-versions，所以旧项目不一定要立刻改配置文件。install 和 use 是两件事，前者偏向“下载到本地”，后者偏向“安装并写入当前配置”。mise.toml，如果你看过我之前那篇文章，里面大量出现的 .mise.toml 更像是早期习惯写法，迁移时最好跟当前官方默认保持一致。plugin add 再 install 再 local。global 和 local 语法，那么迁移时也要顺便意识到：新版 asdf 本身都已经把这套命令改成了 set，所以你现在换成 mise，其实并不只是“从 asdf 换到另一个工具”，同时也是一次重新整理肌肉记忆的机会。把这几件事情想清楚之后，迁移就会简单很多。因为你会发现自己真正要处理的，不是几十个项目配置文件，而是 Shell 初始化、版本安装目录和几条常用命令的替换。
如果你在 macOS 上，按照当前官方文档，最省心的方式依然是通过 Homebrew 安装：
brew install mise
安装之后，我会直接把激活命令写进 ~/.zshrc：
echo 'eval "$(mise activate zsh)"' >> "${ZDOTDIR-$HOME}/.zshrc"
source "${ZDOTDIR-$HOME}/.zshrc"
官方文档提到，某些安装方式下 Homebrew 可能会自动处理一部分激活逻辑，但我个人还是更喜欢显式写一行配置。原因很简单，环境问题通常都出在“我以为系统会帮我做这件事”，显式配置虽然土一点，但排查起来最省心。配置完成之后，先跑一遍 mise doctor，这一步能很快发现 PATH、Shell hook、插件解析之类的问题。
如果你之前在 ~/.zshrc 或 ~/.bashrc 里已经有 asdf 的初始化代码，这个时候可以把旧的加载逻辑删掉或者注释掉，只保留数据目录本身，不急着物理删除文件：
# 老 asdf 常见初始化方式
. "$HOME/.asdf/asdf.sh"
. /opt/homebrew/opt/asdf/libexec/asdf.sh
我不建议在第一天迁移时就把 ~/.asdf 整个删掉。先让 Shell 只走 mise，确认几个核心项目都能正常跑，再决定要不要做后续清理，这样风险最低。
这一步是我觉得整篇文章里最值钱的地方。很多人迁移工具时，总想把配置文件一并“升级”掉，但对已经稳定运行的项目来说，这通常不是最划算的选择。因为 mise 官方本来就支持 .tool-versions，所以最省事的方式其实是保持项目文件不动，直接进入项目目录运行：
cd your-project
mise install
如果当前目录里已经有 .tool-versions，mise 会按照里面声明的版本去安装对应工具。装完之后，再跑一遍你最关心的命令确认环境是否正确：
node -v
python -V
ruby -v
mise ls
只要这一步验证通过，说明这个项目已经基本被 mise 接管了，而你根本没有改动项目里的版本文件。对团队仓库来说，这个策略尤其友好，因为你不需要为了个人环境偏好去提交一堆和业务无关的配置变更。
下面这张表，是我自己迁移时最常参考的一组命令映射。你不需要一口气全部记住，只要把最常用的几条先换过来，后面自然就顺手了。
| 场景 | asdf 常见写法 | mise 写法 |
|---|---|---|
| 给当前项目安装并写入版本 |
asdf plugin add pythonasdf install python 3.12.9asdf set python 3.12.9
|
mise use [email protected] |
| 只安装一个版本，不改当前项目配置 | asdf install python 3.12.9 |
mise install [email protected] |
| 设置用户级默认版本 | asdf set --home python 3.12.9 |
mise use -g [email protected] |
| 查看远程可安装版本 | asdf list all python |
mise ls-remote python |
| 查看本地已经安装的版本 | asdf list python |
mise ls python |
| 按项目配置批量安装 | asdf install |
mise install |
| 安装缺失插件 | asdf plugin add flutter |
mise plugins install flutter |
| 安装并切到某个 Node 版本 |
asdf plugin add nodejsasdf install nodejs 22.17.0asdf set nodejs 22.17.0
|
mise use [email protected] |
如果你脑子里还保留着更老一代 asdf 的命令，比如 asdf local 和 asdf global，也不用担心。你完全可以把它们分别理解成 mise use 和 mise use -g。迁移过程中最重要的不是百分百对应每个历史语法，而是抓住 mise 的核心思路：尽量用更少的命令，把“安装”和“声明当前项目该用哪个版本”这两件事情一次做完。
还有一个我觉得很容易踩坑的点，是工具命名不一定一一对应。比如你在 asdf 里常用的是 nodejs 插件名，到了 mise 里通常会写成 node。所以如果你直接照着旧习惯把插件名照搬过来，偶尔会遇到名字不一样的情况。遇到这种问题时，直接用 mise search 或者去查官方 registry，比硬猜更省时间。
等你确认 mise 已经稳定接管了日常开发环境，这时再来考虑要不要把某些项目从 .tool-versions 切到 mise.toml。我自己的建议是，不要为了“新”而切，而是等你真正需要 mise 独有能力的时候再切，比如环境变量、任务定义、工具选项或者多 backend 支持。
举个非常典型的例子，如果一个项目除了版本管理之外，还希望顺手把环境变量和常用命令也集中在一起，那 mise.toml 的价值就出来了：
[tools]
node = "22"
python = { version = "3.12", virtualenv = ".venv" }
pnpm = "10"
[env]
NODE_ENV = "development"
[tasks.dev]
run = "pnpm dev"
这种写法和 .tool-versions 最大的区别，不只是文件格式从纯文本换成了 TOML，而是它开始承担更多“项目开发入口”的角色。你可以在一个文件里声明运行时版本、环境变量、虚拟环境、任务命令，团队协作时也会更直观。
不过对已经运行很多年的老项目，我依然建议保守一点。哪怕你最后决定切换，也最好先在一个项目里试，再逐步推广，而不是一口气改完整个工作目录。工具迁移最怕的不是技术上做不到，而是一次改动范围过大，最后谁都说不清到底是哪一处变更引入了问题。
如果让我把这次迁移经验压缩成几条最实用的建议，我会这样做。
.tool-versions，只用 mise install 验证兼容性。mise use、mise install、mise ls-remote 和 mise ls。mise.toml。~/.asdf 里的历史数据，不要把清理动作放在验证之前。这套顺序看起来有点慢，但对真实项目环境来说，这恰恰是最快的。因为它把“迁移工具”这件事拆成了很多个可以随时停下来的小步骤，每一步都能验证，每一步失败了也都容易回退。
如果你已经用了很多年 asdf，那你大概率和我一样，并不缺一个“更强”的工具介绍，你缺的是一套迁移时不伤筋动骨的实践方案。mise 最吸引我的地方，不是它一定比 asdf 快多少，而是它给了我一种更轻的维护方式：新项目可以直接用一条命令起步，老项目又不用被迫马上重写版本文件，这种兼容和渐进式迁移的体验，才是真正让我决定换过去的原因。
所以我的建议非常直接：先把 Shell 切过来，让旧项目继续跑 .tool-versions，把常用命令慢慢换成 mise 的写法，最后再决定哪些项目值得升级到 mise.toml。如果你照这个顺序做，整个替换过程会比想象中平滑得多，而且几乎不会影响你现有的开发节奏。
2026-04-07 13:00:00
最近在折腾自己的 AI 工具链时，我遇到了一个非常现实的痛点。手里同时握着 [[Claude]] Pro、ChatGPT Plus、Gemini Advanced 这几个订阅，每次想在自己的脚本或小工具里调用它们的能力，都只能望洋兴叹——订阅账号给的是网页端或 CLI 工具的使用权，而不是 API Key。如果想走 API 路径，就得额外付一次费，而且 API 的定价往往比订阅贵得多。于是我一直在找一个能把订阅账号的额度转化为 API 调用能力的方案，直到最近发现了 [[CLIProxyAPI]] 这个项目。今天就聊聊这个工具到底解决了什么问题。
简单来说，CLIProxyAPI 是一个代理服务器，它可以把 Gemini CLI、Claude Code、OpenAI Codex、Qwen Code、iFlow、Antigravity 等官方 CLI 工具的 OAuth 登录态包装成 OpenAI、Gemini、Claude、Codex 兼容的 API 接口。听起来有点绕，我换个角度解释一下：当你在本地用 gemini 命令或者 claude 命令登录官方 CLI 之后，系统会在本地缓存一份 OAuth token，这份 token 的使用额度是走你的订阅账号的。CLIProxyAPI 做的事情，就是在这份 token 上架一个 HTTP 服务，对外暴露标准的 API 接口，让任何支持 OpenAI SDK、Anthropic SDK 或 Google GenAI SDK 的客户端都可以通过这个代理来调用模型。
这个项目由 router-for-me 团队维护，仓库地址是 github.com/router-for-me/CLIProxyAPI，使用 Go 语言编写。从 Star 数和 Fork 数来看，这个项目在国内外开发者社区中的关注度相当高，围绕它衍生出的第三方工具已经有十几个，包括 macOS 菜单栏应用 vibeproxy、Claude Code 多账号切换工具 CCS、跨平台管理面板 ProxyPal 等等，形成了一个小而精的生态圈。
CLIProxyAPI 最核心的能力是协议转换。无论你上游绑定的是哪个家族的 AI 服务，对外暴露的接口都可以是 OpenAI 的 /v1/chat/completions、Anthropic 的 /v1/messages、Google 的 /v1beta/models/... 或者 Codex 的 /v1/responses 格式。这意味着你可以用 OpenAI 的 SDK 去调用 Claude Sonnet 4.5，也可以用 Anthropic 的 SDK 去调用 Gemini 3 Pro，协议层由代理自动翻译。对于那些希望在不同模型之间做 A/B 测试、或者希望把多家模型聚合进同一个应用的开发者来说，这个特性非常实用。
多账号轮询和负载均衡是另一个让人眼前一亮的功能。项目支持为 Gemini、OpenAI、Claude、Qwen 和 iFlow 配置多个 OAuth 账号，代理会以 round-robin 的方式自动在多个账号之间分配请求。对于免费额度有限的场景，多账号聚合可以有效拉高整体的可用配额；对于有多台订阅的企业用户或团队来说，这个功能直接解决了账号管理的头疼问题。特别是 Gemini CLI 的免费额度相当慷慨，绑定几个 Google 账号就能获得相当可观的 Gemini 2.5 Pro 免费调用量。
在模型支持方面，CLIProxyAPI 目前覆盖的列表相当全面。[[Gemini]] 系列包括 gemini-3-pro-preview、gemini-3-pro-image-preview、gemini-2.5-pro、gemini-2.5-flash 等多个版本，甚至支持 gemini-2.5-flash-image 这类多模态图像生成模型。[[OpenAI]] 这边覆盖了 gpt-5 和 gpt-5-codex。[[Anthropic]] 的 Claude 系列从 claude-opus-4-1、claude-sonnet-4-5 到 claude-haiku-4-5 都在支持范围内。此外还包括阿里的 qwen3-coder-plus、qwen3-max 系列，DeepSeek 的 deepseek-v3.2 和 deepseek-r1，Moonshot 的 kimi-k2，智谱的 glm-4.6 等国产大模型，甚至还能接入 OpenAI 兼容的上游服务商比如 [[OpenRouter]]。这个列表几乎涵盖了当下所有主流的闭源大模型。
OAuth 认证流程是这个项目的灵魂所在。当你在命令行运行认证命令时，CLIProxyAPI 会启动一个本地 HTTP 服务器接收 OAuth 回调，整个流程跟官方 CLI 工具的登录体验几乎一模一样。认证完成后，token 会被加密保存在本地配置目录中，之后所有的 API 调用都会自动使用这份 token。对于 Gemini 还支持传统的 Generative Language API Key 方式，如果你有 AI Studio 的 Key 也可以直接配置进去。
其他值得一提的能力包括流式响应和非流式响应两种模式、Function Calling/Tools 支持、多模态输入（文本+图像）、以及对 Amp CLI 和 IDE 扩展的原生适配。流式响应对于构建聊天界面来说是刚需，而 Tools 支持则让你可以在本地跑起像 [[Agent]] 这样的复杂工作流。
从我这几天的体验来看，CLIProxyAPI 最直接的应用场景是让订阅账号释放出更多价值。举个例子，我平时订阅了 ChatGPT Plus 和 Claude Pro，这两个订阅加起来每月大约 40 美元。在没有 CLIProxyAPI 之前，我只能在官方客户端里使用这些模型；有了它之后，我可以把这两个订阅的额度打通给本地的开发工具链，比如在自己写的知识库摘要脚本里调用 Claude Sonnet 4.5，在自动化翻译流水线里调用 GPT-5，完全不需要额外的 API Key。虽然官方的订阅额度也有限，但对于个人项目和日常自动化任务来说，这些额度已经相当够用了。
另一个让我觉得非常实用的场景是与本地 AI 工具的集成。像 [[Cline]]、Roo Code、[[Cursor]] 这些 AI 编程助手都支持配置自定义的 OpenAI 兼容端点，我只要把 CLIProxyAPI 的地址填进去，就可以在这些工具里无缝使用自己订阅的 Claude Code 或 GPT-5 额度。这种组合方式彻底改变了我的开发流程，因为我不再需要为每一个 AI 工具都单独购买 API 额度，所有的 AI 能力都可以汇集到一个统一的代理入口。
对于国内开发者来说，CLIProxyAPI 还有一个隐性的好处，就是它可以作为网络层的统一出口。你只需要保证 CLIProxyAPI 所在的服务器能够稳定访问 OpenAI、Anthropic、Google 这些上游服务，本地客户端只要能连接到 CLIProxyAPI 就行。这种部署方式对于那些在网络受限环境下工作的团队来说非常友好。
团队共享账号也是一个值得讨论的场景。如果你所在的小团队有一个共享的 Claude Max 或 ChatGPT Team 订阅，通过 CLIProxyAPI 部署一个内部服务，大家就可以通过 API 的方式共享使用这个订阅，配合多账号轮询还可以进一步扩大可用配额。当然，这里需要注意订阅服务商的使用协议，避免违反相关条款。
这篇文章最早写出来的时候，我对安装部分写得还是太“概念型”了，像是在告诉你“它不难装”，而不是告诉你“到底怎么装”。我重新看了一遍 CLIProxyAPI 官方 quick start 之后，发现最稳的上手方式其实非常清晰：先准备一份最小配置，再选一种安装路径，完成 OAuth 登录，最后把下游工具指向这个代理。你只要按这个顺序走，第一次跑通不会太费劲。
我自己的建议是，第一次不要同时折腾 Claude、Gemini、Codex 三家账号，也不要一上来就配管理面板、模型别名、多账号轮询。先让单账号、单 provider 跑通，再慢慢往上加。CLIProxyAPI 的功能面很宽，但它真正容易让人卡住的，其实是第一次“配置、登录、启动、验证”这四步没串起来。
不管你用 [[Homebrew]]、[[Docker]] 还是源码编译，最终都要落回一个 config.yaml。官方 config.example.yaml 很长，第一次看容易有点吓人，但本地自用其实只需要一份极简配置就能启动：
host: "127.0.0.1"
port: 8317
remote-management:
allow-remote: false
secret-key: "change-this-management-key"
auth-dir: "~/.cli-proxy-api"
api-keys:
- "local-dev-key"
debug: false
这份配置里，host: "127.0.0.1" 的意义非常大，它会把服务限制在本机监听，避免你在没做好鉴权之前就把代理直接暴露到局域网甚至公网。auth-dir 是 OAuth 凭证保存目录，Gemini、Claude、Codex 这些登录态最后都会落到这里。api-keys 则是你给下游客户端使用的访问令牌；比如 [[Claude Code]]、[[Codex]]、[[Gemini CLI]] 或者你自己的脚本在访问 CLIProxyAPI 时，就可以用这个 key 做最基本的请求鉴权。至于 remote-management.secret-key，如果你希望开启管理 API 和管理面板，这个值就不要留空；官方文档说它在启动时会自动哈希回写，所以填明文即可。
从官方 quick start 来看，CLIProxyAPI 目前把主流安装路径都准备好了。
如果你在 macOS 上，最轻松的方式就是直接用 [[Homebrew]]：
brew install cliproxyapi
brew services start cliproxyapi
这里有一个官方文档里提到但很多人第一次会忽略的细节：如果你是通过 brew services 跑服务，默认配置文件路径不是 ~/.cli-proxy-api/config.yaml，而是 $(brew --prefix)/etc/cliproxyapi.conf。如果你更喜欢把所有配置和登录态都统一放在 ~/.cli-proxy-api/ 目录里，官方给的做法是把默认路径软链接过去：
brew services stop cliproxyapi
mv "$(brew --prefix)/etc/cliproxyapi.conf" "$(brew --prefix)/etc/cliproxyapi.conf.bak"
ln -s ~/.cli-proxy-api/config.yaml "$(brew --prefix)/etc/cliproxyapi.conf"
brew services start cliproxyapi
如果你在 Linux 上，官方 quick start 给了一个一键安装脚本：
curl -fsSL https://raw.githubusercontent.com/brokechubb/cliproxyapi-installer/refs/heads/master/cliproxyapi-installer | bash
如果你用的是 Arch，也可以直接从 AUR 安装，然后交给 [[systemd]] 用户服务管理：
yay -S cli-proxy-api-bin
mkdir -p ~/.cli-proxy-api
cp /usr/share/doc/cli-proxy-api-bin/config.example.yaml ~/.cli-proxy-api/config.yaml
systemctl --user start cli-proxy-api
systemctl --user enable cli-proxy-api
如果你喜欢容器化部署，官方提供的 [[Docker]] 路径也很直接，而且很适合把服务放到一台单独的机器上长期运行。最基本的启动命令就是：
docker run --rm -p 8317:8317 \
-v /path/to/your/config.yaml:/CLIProxyAPI/config.yaml \
-v /path/to/your/auth-dir:/root/.cli-proxy-api \
eceasy/cli-proxy-api:latest
最后一种就是源码编译。官方 quick start 给出的命令也非常朴素：
git clone https://github.com/router-for-me/CLIProxyAPI.git
cd CLIProxyAPI
go build -o cli-proxy-api ./cmd/server
如果你走这条路，后面的登录命令和启动命令里，把 cliproxyapi 替换成你自己的可执行文件路径就行，比如 ./cli-proxy-api。
如果你在 Windows 上，官方 quick start 给的路径更直接：下载最新 release 二进制或者桌面 GUI 应用，直接运行即可。对不想自己维护服务进程和配置文件路径的人来说，GUI 包装版反而会更省事。
CLIProxyAPI 不会替你自动“继承”本机已经登录好的官方 CLI 状态，它有自己的一套 OAuth 登录流程，会把拿到的凭证保存到 auth-dir。这一步其实就是整个安装流程里最关键的一步。
官方 provider 文档里给的命令很明确。Gemini CLI 的 OAuth 登录用：
cliproxyapi --login
如果你是已经在用 Gemini Code 的老用户，官方还建议必要时显式带上 --project_id：
cliproxyapi --login --project_id <your_project_id>
Gemini 的本地 OAuth 回调默认走 8085 端口。Codex 的登录命令是：
cliproxyapi --codex-login
它的本地回调端口是 1455。[[Claude Code]] 的登录命令则是：
cliproxyapi --claude-login
它的本地回调端口是 54545。这几个登录命令都支持 --no-browser 参数，也就是不自动拉起浏览器，而是直接把登录 URL 打印出来。如果你是在远程服务器、SSH、或者没有图形界面的环境里部署，这个参数会很有用。
如果你用 Docker 跑登录，官方文档也给了对应写法。比如 Gemini OAuth：
docker run --rm -p 8085:8085 \
-v /path/to/your/config.yaml:/CLIProxyAPI/config.yaml \
-v /path/to/your/auth-dir:/root/.cli-proxy-api \
eceasy/cli-proxy-api:latest /CLIProxyAPI/CLIProxyAPI --login
Codex 和 Claude 也是同一个思路，只是把端口和参数换成 1455 + --codex-login、54545 + --claude-login。如果你计划长期用 Docker 部署，这里一定要把 auth-dir 做成持久化挂载，不然容器删掉之后登录态也会一起没掉。
很多人卡在这里，是因为登录做完了，但并没有立刻验证“代理是否真的已经在工作”。我的建议是，启动服务之后，先不要急着接 [[Cline]]、[[Cursor]]、Roo Code 这些复杂客户端，而是先用最简单的方式验证一下端口、鉴权和模型路由是否正常。
如果你是前台运行，就直接：
cliproxyapi
如果你在 macOS 上已经装成 Homebrew 服务，那就直接：
brew services start cliproxyapi
跑起来之后，先用一个最简单的请求去测。这里我通常会用 OpenAI 兼容的方式测一遍，因为大部分工具最后也都是按这个入口接。比如你已经把 api-keys 配成了 local-dev-key，那就可以用一个最小的 chat/completions 请求去试，模型名则替换成你已经登录好的上游模型：
curl http://127.0.0.1:8317/v1/chat/completions \
-H "Authorization: Bearer local-dev-key" \
-H "Content-Type: application/json" \
-d '{
"model": "claude-sonnet-4-5-20250929",
"messages": [
{"role": "user", "content": "Hello"}
]
}'
如果这一层已经通了，再去接下游客户端，问题定位会简单很多。否则一旦你直接把它塞进复杂工具链里，出问题时你会分不清是 CLIProxyAPI 没起好、OAuth 没登好、模型名不对，还是客户端本身配置错了。
这部分是我觉得官方文档特别实用、但很多中文介绍文章都没讲清楚的地方。CLIProxyAPI 不只是一个“有个 HTTP 端口”的代理，它还专门给 [[Claude Code]]、[[Codex]]、[[Gemini CLI]] 这类工具写了接入指南。
先看 [[Claude Code]]。官方文档给的方式是改环境变量：
export ANTHROPIC_BASE_URL=http://127.0.0.1:8317
export ANTHROPIC_AUTH_TOKEN=sk-dummy
export ANTHROPIC_DEFAULT_OPUS_MODEL=gemini-2.5-pro
export ANTHROPIC_DEFAULT_SONNET_MODEL=gemini-2.5-flash
export ANTHROPIC_DEFAULT_HAIKU_MODEL=gemini-2.5-flash-lite
也就是说，[[Claude Code]] 自己仍然以为自己在调用 Anthropic 风格的接口，但底层已经被你重定向到了 CLIProxyAPI。你甚至可以让它表面上跑 Opus、Sonnet、Haiku 三个档位，实际上走的是 Gemini、GPT-5 或 Qwen。对喜欢在一个工具里切不同模型的人来说，这个能力非常强。
[[Codex]] 的接法和 Claude Code 不一样。官方文档建议直接改 ~/.codex/config.toml 和 ~/.codex/auth.json：
model_provider = "cliproxyapi"
model = "gpt-5-codex"
model_reasoning_effort = "high"
[model_providers.cliproxyapi]
name = "cliproxyapi"
base_url = "http://127.0.0.1:8317/v1"
wire_api = "responses"
auth.json 则只需要一个占位 key：
{
"OPENAI_API_KEY": "sk-dummy"
}
这段配置的价值在于，你不需要真的持有 OpenAI API Key，也能让 Codex 走 CLIProxyAPI 暴露出来的 Responses API 兼容入口。
[[Gemini CLI]] 则分两种情况。如果你希望走 Google OAuth 路线，官方文档要求设置：
export CODE_ASSIST_ENDPOINT="http://127.0.0.1:8317"
但这里有一个官方文档特别提醒的限制：这种方式目前只能本地访问，因为 loadCodeAssist、onboardUser、countTokens 这些请求没有独立认证机制，文档里甚至写明了 127.0.0.1 是硬编码的。换句话说，Gemini CLI 的 OAuth 接法非常适合本机自用，但不适合直接拿来做远程共享网关。
如果你走的是 Gemini API Key 模式，则是另一组变量：
export GOOGLE_GEMINI_BASE_URL="http://127.0.0.1:8317"
export GEMINI_API_KEY="sk-dummy"
这一种就比 OAuth 本地模式自由得多，理论上可以把 CLIProxyAPI 放在任意 IP 或域名后面，只要网络和鉴权都处理好。
如果你问我现在最推荐的安装顺序，我会给一个非常保守但成功率很高的版本。第一步，在本机或一台受信任的服务器上写好最小 config.yaml，先把监听地址收紧到 127.0.0.1。第二步，根据自己的环境选择安装路径；macOS 走 Homebrew，远程服务器走 Docker，喜欢纯净控制的走源码编译。第三步，不要贪多，只登录一个 provider，比如先做 cliproxyapi --claude-login 或 cliproxyapi --codex-login。第四步，启动服务后先用 curl 验证一遍，再去接 [[Claude Code]]、[[Codex]] 或 [[Gemini CLI]]。
这样做的好处是，任何一步出问题都很好排查。你不会在第一天同时处理配置文件、三个 OAuth、多个模型别名、复杂客户端集成、管理面板和公网暴露这些问题。CLIProxyAPI 的功能很多，但第一次安装最需要的，其实不是“把所有功能都打开”，而是“先有一个稳定可用的最小闭环”。
关于模型路由，CLIProxyAPI 提供了一个很灵活的机制。当客户端请求某个模型名时，代理会根据配置里的 alias 和 provider 规则决定到底走哪个上游。比如你可以把 claude-opus-4.5 这个不存在的模型名映射到实际可用的 claude-sonnet-4-5，或者把 gpt-4o 映射到 GPT-5。这个映射机制对于那些硬编码了模型名的旧工具来说简直是救命稻草。
踩过的坑也顺手分享一下。第一个坑是不同 provider 的登录命令和本地回调端口并不一样，Docker 部署时如果你没把对应端口映射出来，浏览器授权走到一半就会卡住。第二个坑是 Homebrew 服务模式下的默认配置路径和 ~/.cli-proxy-api/config.yaml 并不是同一个地方，这件事如果你没注意，会产生“我明明改了配置但服务不认”的错觉。第三个坑是 Gemini CLI 的 OAuth 接法目前更偏本机模式，不适合直接拿来做远程共享入口，真正想做远程网关时要更谨慎地选择 Gemini API Key 模式或者别的 provider。
虽然 CLIProxyAPI 解决了很多实际问题，但使用时还是有几点风险需要认真考虑。首先是服务条款的合规性问题。OpenAI、Anthropic、Google 这些服务商的订阅协议通常会对 API 代理、账号共享等行为有明确限制，虽然从技术上来说 CLIProxyAPI 只是复用了官方 CLI 工具的本地 token，但这种用法在协议层面是否合规，严格来说存在灰色地带。我个人的建议是，仅用于个人场景或者团队内部开发测试，不要将其用于商业化的 API 转售。
其次是账号封禁的风险。如果你通过 CLIProxyAPI 的请求模式过于激进，比如短时间内发起大量请求、或者在多个 IP 地址下并发使用同一个账号，可能会触发服务商的风控系统，导致账号被限制甚至封禁。特别是 OpenAI 和 Anthropic 对异常使用模式的检测相当敏感，使用时建议保持合理的请求频率。
第三是 token 的安全问题。CLIProxyAPI 在本地保存的 OAuth token 等价于你账号的登录凭证，如果服务器被入侵，攻击者可以直接使用这些 token 以你的身份调用 API。因此强烈建议把 CLIProxyAPI 部署在受信任的私有网络环境中，不要把它的 API 端口直接暴露到公网，即便要暴露也一定要配置好认证和访问控制。
最后一点是项目的长期可用性。CLIProxyAPI 的工作原理本质上是逆向官方 CLI 的认证协议，一旦官方修改了 OAuth 流程或协议格式，项目就需要同步更新适配。好在目前项目迭代非常活跃，从 v6.9 版本的发布频率来看，维护者对官方变化的响应速度相当快，但作为使用者仍然需要有一定的心理准备，万一某天某个上游的支持突然失效，要有 Plan B。
在 CLIProxyAPI 出现之前，市面上也有一些类似的方案。比如 [[One API]] 和 [[New API]] 这类项目，它们的定位是统一的 API 中转平台，但主要依赖 API Key 而不是 OAuth 订阅，使用者仍然需要购买各家的 API 额度。CLIProxyAPI 最大的差异化就在于它能把订阅账号的额度转化为 API 能力，这是 One API 们做不到的事情。
另一个同类项目是 LiteLLM，它也提供了 OpenAI 兼容的统一接口，支持上百种模型，但同样是基于 API Key 的方案，并且不支持 OAuth 订阅账号。从使用场景来看，LiteLLM 更适合企业级的 API 网关场景，而 CLIProxyAPI 则更贴近个人开发者和小团队的实际需求。
在 CLIProxyAPI 的生态中还衍生出一些 Next.js 实现的 fork 或灵感衍生项目，比如 9Router 和 OmniRoute，它们在功能上类似，但技术栈和部署复杂度有所不同。如果你对 Go 语言不熟悉，又喜欢 Node.js 生态，可以考虑这些替代方案。不过从功能完整度和社区活跃度来看，CLIProxyAPI 仍然是目前最成熟的选择。
CLIProxyAPI 这个项目本质上是一个聪明的桥梁，它站在官方 CLI 工具和开发者工具链之间，用 OAuth 代理的方式把订阅账号的价值最大化。对于那些同时手握多个 AI 订阅、又想在自己的开发流程中自由调用这些模型的人来说，它几乎是不可替代的解决方案。从我个人的使用体验来看，这个项目的代码质量、文档完整度和迭代速度都相当让人放心，Go 语言的实现也让它的部署门槛非常低。
更宏观地看，CLIProxyAPI 的出现反映了一个有趣的趋势：AI 服务商提供的订阅和 API 之间存在明显的价格差和能力差，这种差距催生了各种「套利」工具和创新用法。从用户视角，这类工具帮我们从被动的订阅消费者变成主动的能力整合者；从行业视角，它也在倒逼服务商思考订阅与 API 的定价策略是否合理。我猜测未来 OpenAI、Anthropic 等公司可能会推出更加灵活的订阅计划，允许订阅用户通过官方 API 调用一定额度的模型，这样既满足开发者需求，又避免了灰色地带的合规风险。
对于还在观望的朋友，如果你手里有闲置的 AI 订阅、又有本地 AI 工具链整合的需求，不妨花半个下午时间尝试部署一下 CLIProxyAPI。它不会让你的订阅账单变少，但一定会让你觉得订阅花得更值。至少对我来说，这个工具让 Claude Pro 和 ChatGPT Plus 订阅的价值实实在在地翻了一倍——从只能在官方客户端使用，变成了可以随时随地嵌入任何工作流的 API 能力。
2026-04-07 13:00:00
最近我一直在折腾自己的投资工作流，想把 AI Agent 和真实的行情、持仓、交易动作接到一起。手里一边是 [[Longbridge]] 账户，一边是 [[OpenClaw]] 这类可以扩展 Skill 的开源 Agent，单看都不缺能力，问题是它们原本不在一个工作界面里。查行情要切 App，下单要切网页，想做一点自动化分析还得自己补脚本。直到我把 Longbridge 官方的 longbridge-terminal 和 OpenClaw 里的 Longbridge Skill 接上，这套东西才终于顺了起来。现在我可以直接在终端里问 AI 一句话，让它去查报价、看持仓、整理数据，必要的时候再把下单命令准备好。这篇就把我自己跑通的过程和一些实际感受整理下来。
先说说我为什么会折腾这件事。[[Longbridge]] 的 App 其实已经做得不错，日常看盘、下单都没有问题。但我平时大部分时间都泡在终端和编辑器里，一旦要在写代码的间隙看一眼 NVDA 报价、核对一下持仓盈亏，或者顺手验证一个交易想法，就得把注意力从当前窗口里抽出去。看起来只是多点几下，实际很打断节奏。另一条路是自己写脚本接 OpenAPI，但那又是另一种麻烦，因为每多一个需求，往往就多一段脚本要维护。
OpenClaw 刚好把这个问题接住了。它本身是一个开源的 AI 助手，支持 Skill 机制。只要某个能力最终能落到命令行上，就能被包成一个 Skill 交给 AI 调用。这个思路不复杂，但很好用，因为它把“工具会用”和“AI 会调这个工具”分成了两层。CLI 负责把能力暴露出来，Skill 负责告诉 AI 什么时候该用、该怎么用。对我这种已经有一堆终端工具的人来说，这比重新等一个完整 GUI 产品成熟要现实得多。
把 Longbridge 接进去之后，很多以前要自己动手拼的小动作都可以直接交给 AI 了。比如我会问它“帮我看看现在持仓里 NVDA 是赚是亏”，它就去调用对应命令把结果整理出来。再复杂一点，也可以让它做组合层面的事，比如统计美股持仓的行业分布、汇总这周的持仓变化，或者盯着 TSLA 的盘前价格到某个阈值时提醒我。说到底，这套玩法最吸引我的地方不是“AI 会下单”，而是它终于把查数据、整理数据、准备动作这几个步骤收进了同一个界面里。
Longbridge Terminal CLI，也就是 longbridge-terminal，是 [[Longbridge]] 官方出的命令行工具。它覆盖的范围很广，基本把 Longbridge OpenAPI 里常用的能力都搬到了命令行上，行情、账户、订单、公告、财务数据这些都在里面。项目本身是 [[Rust]] 写的，更新也比较勤。对我来说，最重要的不是它是不是“AI-native”这种标签，而是它从一开始就把命令行输出做得比较规整，很多命令都能直接吐 JSON，这样 AI 才有东西可读。
它能做的事其实不少。查报价、五档、逐笔、K 线、盘中分时、财务报表、机构持仓、历史分红、账户余额、持仓、订单记录，这些都能直接拉。你如果只是把它当一个终端版行情工具来用，也已经够值了。更重要的是，它和 Skill 机制很搭，因为 Skill 最怕的不是能力少，而是底层工具输出不稳定、不好解析。Longbridge CLI 在这一点上做得还不错。
我自己比较常用的一块是期权链。以前在 App 里来回切期权到期日和行权价，总觉得差点意思。换成 CLI 之后，像 longbridge option chain AAPL.US --date 2024-01-19 这种命令，一次就能把完整链条拉出来。做策略筛选的时候，这种效率差别是很明显的。
认证流程走的是 OAuth 2.0 device flow，这一点我也挺喜欢。跑 longbridge login 之后，终端会给你一个地址和验证码，你拿任何一台能开浏览器的设备去授权就行。对远程服务器或者没有图形界面的环境特别友好，也省掉了把账号密码塞进脚本里的坏习惯。
OpenClaw 这边关键的就是 Skill。一个 Skill 说穿了就是一个目录，里面放一个 SKILL.md，再带上一些脚本、模板或者参考文件。SKILL.md 负责把规则讲清楚：什么场景该触发、该调用哪个底层命令、输出怎么处理。AI 依赖的是这层说明，不是凭空猜测。
OpenClaw 启动时会扫一遍 skills 目录，把这些描述加载起来。等你提问题时，它再去判断要不要用某个 Skill。这个设计我一直挺喜欢，因为它比把所有说明都硬塞进 system prompt 要节省得多，也更容易维护。你哪条规则写得不顺手，改 Skill 就行，不用去碰更底层的配置。
现在社区里已经有人把 Longbridge OpenAPI 做成了现成 Skill，发布在 OpenClaw Skills Marketplace 上，名字是 openclaw-skills-longbridge-openapi。它把行情、K 线、账户、订单这些常用动作都封装好了，所以第一次接的人不用从零自己写。
不过这里还是要区分一下 CLI 和 Skill 的职责。CLI 是干活的，Skill 是教 AI 怎么叫人干活的。没有 CLI，Skill 只是空说明；没有 Skill，AI 又不一定知道该在什么场景下调哪条命令。我的做法是尽量让 CLI 保持“纯工具”，把“用户问到行情时优先用 longbridge quote”“用户问到 K 线时用 longbridge kline”这种映射写进 Skill。这样出问题的时候也比较好查，到底是工具坏了，还是规则写得不够清楚。
整个流程其实就三步：装好 Longbridge CLI、完成登录、再把 Skill 接进 OpenClaw。下面按顺序展开。
CLI 的安装非常简单。在 macOS 上推荐使用 [[Homebrew]]：
brew install --cask longbridge/tap/longbridge-terminal
如果你不想用 Homebrew，或者在 Linux 上使用，可以直接运行官方的安装脚本：
curl -sSL https://open.longbridge.com/longbridge/longbridge-terminal/install | sh
Windows 用户可以通过 [[Scoop]] 或者 PowerShell 脚本安装：
iwr https://open.longbridge.com/longbridge/longbridge-terminal/install.ps1 | iex
安装完成后运行 longbridge --version 确认安装成功。在 macOS 和 Linux 上，二进制文件会被放到 /usr/local/bin/longbridge；在 Windows 上则是 %LOCALAPPDATA%\Programs\longbridge\longbridge.exe。
安装完 CLI 之后第一件事就是登录。运行：
longbridge login
终端会输出一段类似下面的信息：
Visit https://open.longbridge.com/activate
And enter the code: ABCD-1234
打开浏览器访问那个 URL，登录你的 [[Longbridge]] 账户，输入终端给出的 code 并点击授权，几秒之后 CLI 那边就会显示登录成功，token 会被自动保存到本地配置目录（macOS 上通常是 ~/.config/longbridge/）。这种 device flow 的好处是你不需要在终端里输入用户名密码，token 也是按设备颁发的，可以随时通过 longbridge logout 注销。
如果你在远程服务器上部署，整个流程也是一样的。即便服务器上没有浏览器，CLI 给出的 URL 你也可以在本地电脑或手机上打开完成授权，授权信息会通过 Longbridge 的服务端同步给 CLI。
OpenClaw 的 Skill 默认安装位置是 ~/.openclaw/skills/。从 OpenClaw Skills Marketplace 安装 Longbridge OpenAPI Skill 有几种方式。最简单的是通过 OpenClaw 的命令行工具：
openclaw skill install openclaw-skills-longbridge-openapi
这条命令会从 Marketplace 下载 Skill 包并解压到 ~/.openclaw/skills/longbridge-openapi/ 目录。安装完成后，你可以查看里面的 SKILL.md 文件，了解 Skill 的具体描述和使用方式。
如果你倾向于手动管理，也可以直接从 GitHub 仓库 openclaw/skills 的 skills/genkin-he/longbridge-openapi/ 路径下克隆 Skill 文件夹，放到本地的 skills 目录即可。手动安装的好处是可以根据自己的需要修改 SKILL.md，比如调整某些命令的默认参数、添加自己常用的工作流模板等。
安装完成后需要在 OpenClaw 的配置文件 ~/.openclaw/openclaw.json 里启用这个 Skill。OpenClaw 使用 JSON5 格式（支持注释和尾随逗号），配置示例如下：
{
// 启用本地 skills 目录
"skills": {
"enabled": true,
"paths": ["~/.openclaw/skills"]
},
// 为 Longbridge skill 设置环境变量（如果需要）
"env": {
"LONGBRIDGE_APP_KEY": "your_app_key",
"LONGBRIDGE_APP_SECRET": "your_app_secret",
"LONGBRIDGE_ACCESS_TOKEN": "your_access_token"
}
}
需要注意的是，如果你已经通过 longbridge login 完成了 CLI 端的 OAuth 登录，那么 Skill 中可以直接调用 CLI 命令，无需再单独配置环境变量；但如果你的 Skill 是直接调用 Longbridge OpenAPI（绕过 CLI），那么 App Key、Secret、Access Token 是必须的。这两种调用方式各有优缺点，下面会详细说。
我配置好之后，先拿最基础的查询试了一圈。比如问它“帮我看一下 NVDA 现在的报价和今天涨跌”，OpenClaw 就会去跑 longbridge quote NVDA.US，再把结果整理成我看得懂的格式。这个场景听起来不复杂，但一旦你真的开始这么用，就会发现它很顺手，因为你不用再自己记命令、切窗口、抄代码。
我后来用得最多的是组合查询。比如我会直接问“把 AAPL、NVDA、TSLA、META 今天的表现按涨跌幅排一下”。它会一次把几只股票的报价拉回来，排好序，再给个简单总结。手动做当然也不是不行，但你很难说服自己每天都愿意重复敲这一串。
K 线和财务数据也是类似。我会让它拉 BABA 过去 30 天的日 K，再顺手看看波动区间和最近走势；或者让它把 TSLA 最新一个季度的营收、净利润变化提出来，先做个粗筛。这里 AI 最有用的地方，不是它分析得多深，而是它把“拿数据”和“先整理一遍”这两步顺手做掉了。很多时候我只是想先看个大概，判断值不值得再往下研究，这种轻量整理就很够用了。
至于交易，我目前还是很保守。我只拿小金额做过测试，也只在自己明确下指令的时候才让它准备订单。Longbridge CLI 本身在 buy、sell、cancel 这类操作上会有确认提示，这已经能挡掉不少误操作，但我还是建议在 Skill 里再写死一条规则：除非用户明确要求，否则不要主动下单。行情和分析可以放开一些，交易动作还是得把最后一道闸门握在自己手里。
第一个坑是 token 的管理。Longbridge CLI 的 token 默认存储在本地，但 token 是有有效期的，过期之后需要重新登录。如果你在自动化脚本里调用 CLI，建议增加一个 token 刷新的检测逻辑，或者在 Skill 的初始化部分加上 token 校验。我自己写了一个简单的 wrapper 脚本，每次执行 CLI 命令前先检查 token 是否有效，无效时自动触发 longbridge login 流程。
第二个坑是 Skill 的描述精度。OpenClaw 的 AI Agent 是根据 Skill 的描述来判断是否调用的，如果描述写得太模糊，AI 可能在不该调用的时候调用，或者在该调用的时候漏掉。我的建议是在 Skill 的 description 字段里明确列出触发关键词，比如「股票」「行情」「报价」「持仓」「订单」等中文词汇，以及对应的英文词汇，提高匹配准确率。
第三个坑是市场代码的格式。Longbridge 使用统一的代码格式，港股是 XXX.HK，美股是 XXX.US，A 股是 XXX.SH 或 XXX.SZ。但 AI 有时候会忘记加这个后缀，比如直接说 NVDA 而不是 NVDA.US。在 Skill 里我加了一段说明，要求 AI 在调用 CLI 之前必须把股票代码补全成完整格式，否则 CLI 会报错。
第四个坑是数据频率的限制。Longbridge OpenAPI 对实时行情订阅有 QPS 限制，免费用户和付费用户的额度不一样。如果你让 AI 短时间内查询大量股票，可能会触发限流。建议在 Skill 里加上「同时查询不要超过 N 只股票」之类的约束，避免触发限流导致整个流程失败。
第五个坑是 CLI 与 Skill 的职责划分。我一开始尝试让 Skill 直接调用 Longbridge OpenAPI 的 Python SDK，结果发现需要管理一堆环境变量和 Python 依赖，反而比调用 CLI 更复杂。后来我把所有调用都改成走 CLI，Skill 只负责描述「什么时候用什么命令」，整个架构清爽了很多。所以如果你也是新手，建议优先走 CLI 路线，等熟练之后再考虑直接调用 SDK。
跑通基础流程之后，我开始把它往更像“日常助手”的方向调。第一个比较实用的是盘前简报。我在 OpenClaw 里做了一个 /morning-brief，让它每天早上把持仓报价、主要指数、当天财报、我关注股票的公告拉一遍，再汇总成一份 Markdown 放进 [[Obsidian]]。这个东西不花哨，但我现在真的会用，因为它把原来散落在几个地方的信息收拢到了一起。
第二个我常用的是价格提醒和持仓监控。我会让它定时跑 longbridge positions 和 longbridge quote，算一下当前盈亏比例。如果到达我预设的止损或止盈区间，就通过 [[Telegram]] 发个提醒。这个工作流没有自动交易那么刺激，但对我来说更实用，也更安心。
财报季的时候，这套东西也特别顺手。我会让它盯住几家公司，在财报出来之后立刻拉一遍关键数据，先看营收、净利润和市场预期差多少。很多时候我并不需要第一分钟就做交易决策，但我确实想第一时间知道“这份财报大概好还是坏”。AI 在这里扮演的更像一个替我做初筛的研究助理。
期权筛选也是类似。结合 longbridge option chain 和 longbridge calc-index，它可以先把满足条件的合约挑出来，我再去看有没有值得进一步研究的标的。这个过程以前不是不能做，只是太碎了。现在我愿意更频繁地试，是因为入口变低了。
如果要说我对这些玩法最看重什么，不是“自动化程度很高”，而是它把很多重复、枯燥、但规则又很明确的工作替我先做了。真正要拍板的时候，还是我自己来。
虽然这套工作流很好玩，但只要碰到真实账户，安全和合规就不能只当免责声明看。最先要管好的还是凭证。无论是 CLI 的 OAuth token，还是 Longbridge OpenAPI 的 App Secret，都别出现在公开仓库、shell 历史或者日志里。我自己的做法是交给 macOS Keychain 管，再用一层很薄的 shell 脚本在运行时注入。
第二个问题是权限边界。就算 OpenClaw 跑在本地，我也不会把下单权限无条件交给 AI。在我的 Skill 里，buy、sell、cancel、replace 这类写操作都要求人工确认。这样做当然没那么“全自动”，但我宁愿慢一点，也不想哪天因为一句模糊指令真的打出一笔错误订单。
我还给这些调用加了日志。每次 AI 跑 Longbridge CLI，我都会把命令和结果记到一个本地 JSONL 文件里。平时可能感觉不到用处，但一旦哪天你发现账户里有个奇怪动作，这份记录会很值钱。
最后还是合规问题。Longbridge 对自动化交易不是完全没边界的，尤其是频率和方式上都有条款。我的使用频率很低，基本还是以辅助分析和准备动作为主，但这件事每个人都最好自己读一遍相关规定。别等真踩线了，才发现自己之前只是想当然。
把 Longbridge CLI 接到 OpenClaw 之后，我最直接的感受其实不是“好先进”，而是顺手了很多。以前我要在 App、浏览器、终端之间来回切，很多本来值得随手查一眼的数据，最后因为嫌麻烦就算了。现在这些动作被收进了同一个对话界面里，至少我真的更愿意去查、去比、去整理了。
从工具层面看，我也越来越觉得 CLI 很适合拿来给 AI 调。它的输入输出足够规整，错误也比较直白，不像 GUI 那样充满隐含状态。对 Longbridge 这种本来就有丰富数据能力的服务来说，先把 CLI 做好，再让 Skill 去接，反而比硬塞一个“大而全的 AI 功能”靠谱得多。
如果你本来就习惯在终端里工作，又刚好在用 [[Longbridge]] 和 [[OpenClaw]]，这套配置值得自己动手试一次。真正花时间的不是安装，而是后面慢慢把 Skill 调成适合自己习惯的样子。对我来说，最值钱的也正是这一点：让 AI 去接那些重复的数据整理和信息搬运，而我自己把注意力留给判断和决策。
2026-04-05 13:00:00
[[Anthropic]] 在 2026 年 2 月把 [[Claude Code]] Agent Teams 作为实验性能力推了出来。前两天我第一次写这篇文章的时候，更多还是从“概念上很酷”这个角度在理解它；但把官方那篇专门的 Agent Teams 文档完整看了一遍之后，我发现这个功能真正有意思的地方不只是“多个 Agent 并行”，而是它开始提供一套接近真实团队协作的运行机制：共享任务列表、队友之间直接通信、Lead 统一协调、以及在终端里把整个团队真正跑起来的显示模式。
这次我把文章重新补了一轮，尤其把之前略写带过的部分补实了：什么时候该用 Agent Teams，什么时候还是该用 Subagent；如何指定显示模式；tmux 在 split-pane 模式里到底扮演什么角色；以及实验性阶段那些容易踩坑的限制。如果你已经在用 [[Claude Code]]，这几个细节其实决定了 Agent Teams 到底是“炫技功能”，还是能稳定进入你工作流的工具。
Agent Teams 的基本结构并不复杂：一个主会话充当 Team Lead，负责创建团队、拆分任务、分配工作、汇总结果；其他会话作为 Teammate 独立运行，每个 Teammate 都是一个完整的 Claude Code 会话，拥有自己的上下文窗口、自己的工具调用过程、自己的中间推理轨迹。它们不是附着在 Lead 身上的轻量线程，而是真正意义上的多个并行 Claude Code 实例。
这个设计带来的变化是，团队成员之间不必凡事都经由 Lead 中转。官方文档明确提到，Teammate 可以直接互相发消息，共享同一份任务列表，并且根据任务依赖关系自主管理工作顺序。某个任务完成之后，依赖它的任务会自动解锁；某个队友空闲之后，也可以去认领下一个未被阻塞的任务。这套机制已经很接近一个小型工程团队，而不再只是“主 Agent 派几个 helper 去跑腿”。
另外一个很重要的点是，用户也可以直接和某个 Teammate 对话，而不一定每次都要通过 Lead。这一点把 Agent Teams 和传统的“主会话下面挂几个不可见 worker”拉开了距离。它不只是系统内部的并行化技巧，而是把并行工作的控制权开放给了用户。
官方把适用场景总结得很清楚，我觉得基本可以照着理解。Agent Teams 最适合那些“并行探索本身就能带来价值”的任务，而不是所有复杂任务都值得上团队模式。研究和审查类工作是最典型的场景：安全、性能、测试覆盖、可维护性，本来就是几条天然可以并行推进的线，让几个 Teammate 同时看，最后由 Lead 汇总，通常比一个 Agent 按顺序轮着看要快。
另一个很适合的场景是新模块或新功能的拆分实现。前端、后端、测试、文档，如果边界清楚，本来就可以由不同人各自负责，Agent Teams 在这种情况下会非常自然。再往前一步，对抗性调试也很适合团队模式。官方文档里专门强调了“用竞争性假设并行排查 bug”，我非常认同，因为单个 Agent 很容易在第一个看起来合理的解释上停下来，而多个 Teammate 被要求互相质疑时，反而更容易逼近真正的根因。
但反过来说，顺序性很强的任务、多人会频繁碰同一文件的任务、或者大量步骤互相依赖的任务，通常不值得上 Agent Teams。因为团队模式本身就有协调成本，而且每个队友都是独立上下文，Token 消耗也会显著上升。官方文档对此说得很坦率：如果任务本质上不能独立并行，单会话甚至 Subagent 往往更高效。
很多人第一次看到这个功能，直觉都会问一句：这不就是 Claude Code 版的 Subagent 吗？但从官方定义看，这两者其实不是同一个抽象层。
| 维度 | Subagent | Agent Teams |
|---|---|---|
| 上下文 | 独立上下文，但结果回到主会话 | 完全独立上下文，彼此平行存在 |
| 通信 | 只能向主 Agent 汇报 | 队友之间可以直接发消息 |
| 协调 | 主 Agent 全程控制 | 共享任务列表，自主认领与协作 |
| 适用场景 | 结果导向、短平快的委派 | 需要讨论、质疑、协同推进的复杂任务 |
| Token 成本 | 较低 | 较高 |
如果你要的是“帮我查一下这个 API 文档”或者“帮我验证一个猜想”，Subagent 通常更合适，因为它便宜、快，而且结果只要回传给主会话就够了。但如果任务本身要求多个角色互相分享发现、挑战彼此结论，或者协同推动一张带依赖关系的任务列表，那就已经进入 Agent Teams 的适用范围了。
我自己的判断标准很简单：如果工作成果只需要回到主线程，那就用 Subagent；如果工作过程本身需要队友之间发生互动，才值得动用 Agent Teams。
Agent Teams 目前仍是实验性能力，默认关闭，而且要求 [[Claude Code]] 版本至少是 v2.1.32。第一步永远应该先确认版本：
claude --version
然后再打开实验开关。官方文档给了两种方式，一种是放到 settings.json 里，让它成为长期配置：
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
另一种是直接在 shell 环境里临时打开：
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
claude
打开之后，不需要你手工去创建某个固定格式的 team 配置。Agent Teams 的入口仍然是自然语言。你直接告诉 Claude 你想创建一支团队，并且说明任务目标和希望的团队结构，它会自己去建 team、拉起队友、创建共享任务列表，再协调大家开始干活。
比如官方文档里的示例就很典型：
我在设计一个帮助开发者追踪代码库 TODO 注释的 CLI 工具。
请创建一个 Agent 团队：一个队友负责 UX，一个负责技术架构，
一个负责扮演反对者找潜在问题，最后由你整合结果。
这个例子为什么好用，是因为三条线相对独立，互相之间不需要频繁等待。Claude Code 可以让三个 Teammate 同时探索，再把结果收回来综合。官方也提到，除了你主动要求创建团队之外，Claude 在判断任务适合并行时也可能主动建议你建 team，但不会在没征求同意的情况下擅自创建。
团队创建出来之后，Lead 仍然是总控入口。你跟 Lead 用自然语言交流，它去完成协调、委派、审批和综合，但这并不意味着你不能更细粒度地控制整个团队。官方文档其实给了不少可操作的细节，这部分比我一开始想象得完整。
Agent Teams 有两种显示模式。一种是 in-process，也就是所有 Teammate 都运行在当前终端内部。你可以用 Shift+Down 在各个队友之间循环切换，按 Enter 进入某个队友会话，按 Escape 中断当前 turn，按 Ctrl+T 切换共享任务列表。这种模式不依赖额外软件，任何终端都能跑，是最稳妥的默认选择。
另一种是 split-pane，也就是每个 Teammate 占据一个独立 pane。它的优势不是功能更多，而是可见性更好。你可以同时看到所有队友的输出，哪个人在跑测试、哪个人在改文件、哪个人在空闲，一眼就能看出来。对三人以上的团队来说，这种可视化监控会比 in-process 模式舒服得多。
默认的 auto 会在检测到你已经处在 tmux 会话中时优先使用分栏，否则回到 in-process。如果你想长期固定某个模式，可以在全局配置 ~/.claude.json 里设置：
{
"teammateMode": "in-process"
}
如果只是某一次会话想临时覆盖，也可以直接用：
claude --teammate-mode in-process
Claude 会根据任务自动决定团队规模，但你也完全可以自己指定。比如你可以明确要求“创建 4 个队友并行重构不同模块”，或者指定全部使用 Sonnet。这个能力很实用，因为很多时候问题不在于 Claude 会不会建团队，而在于它是否恰好建出了你心里想要的角色结构。
对我来说，最稳的用法是直接在 prompt 里写清楚每个队友的职责，比如 researcher、reviewer、devil’s advocate、test owner，而不是只说“建一个团队”。角色越清楚，后面的任务划分和结果整合就越稳定。
官方文档还专门提到一个很有用的控制手段：你可以要求某个 Teammate 先进入 plan mode，在 Lead 审批通过之前不允许直接改代码。这个机制对高风险改动特别重要，比如认证模块重构、数据库结构调整、跨服务接口改造。它让团队模式不至于一上来就变成几个人同时往仓库里乱写，而是先把方案拿出来过一遍。
如果你想把这个原则说得更严格，还可以在 prompt 里告诉 Lead 自己的审批标准，例如“只有包含测试覆盖的方案才批准”或者“会改动数据库 schema 的计划一律驳回”。Lead 会按照你给的标准做判断，这一点其实比单纯说“谨慎一点”有用得多。
这也是 Agent Teams 最像“真实团队”的部分。你不是只能跟 Lead 聊，你也可以直接给某个 Teammate 发消息，追问他为什么这么判断、要求他换个方向、或者让他补某个缺掉的验证。in-process 模式下用 Shift+Down 切换过去直接输入；split-pane 模式下则是点进那个 pane，像操作一个独立的 Claude Code 会话一样操作它。
这一点会显著改变使用体验。很多时候 Lead 的总结已经足够，但一旦你感觉某个队友的方向特别关键，能够直接把手伸进去微调，会比反复要求 Lead 转述高效很多。
Agent Teams 的共享任务列表是整个协作机制的中轴。任务有 pending、in progress、completed 这些状态，还可以声明依赖关系。Lead 可以显式把任务分配给某个队友，也可以让队友在完成当前任务之后自己去认领下一个可执行任务。官方文档提到，它底层用了文件锁来避免两个队友同时抢到同一个任务，这说明这套共享任务机制不是“UI 上看起来像有列表”，而是真的拿本地状态在做协调。
等某个队友不再需要时，可以让 Lead 去请求它 shutdown。等整个团队收尾时，再让 Lead 去执行 cleanup。这里有一个官方特别强调的点：清理动作一定要通过 Lead 做，不要让某个 Teammate 自己去跑 cleanup，因为它手里的 team context 可能不完整，容易把团队状态留在半残状态。
这是一个很容易被忽略但其实很强的点。官方文档说，Agent Teams 可以结合 Hooks 做质量闸门，比如在 Teammate 即将 idle 时跑 TeammateIdle，在任务创建和完成时跑 TaskCreated、TaskCompleted。如果 hook 返回特定退出码，还可以阻止任务创建或阻止任务被标记为完成，并把反馈送回给团队。
这意味着你完全可以给 Agent Teams 叠上一层团队规则，比如“测试没跑不准收工”“任务标题不符合格式不准创建”“没有写验证步骤不准标记完成”。一旦这些规则开始稳定，你会发现 Agent Teams 就不只是并行跑多个 Claude，而是在流程层面越来越接近一个真正能被治理的小团队。
官方文档里对 split-pane 模式说得不算少，但如果你本来不常用 tmux，很可能还是会觉得它只是“为了把屏幕分开看看”。其实在 Agent Teams 里，tmux 的价值远不止分屏这么简单。它提供的是一个持久的终端多路复用层，让每个 Teammate 都有独立 pane，输出互不覆盖，会话在网络抖动或窗口关闭之后也更容易被重新接回去。
官方的建议也很明确：split-pane 模式需要 tmux 或 [[iTerm2]]，而 tmux -CC 配合 iTerm2 是推荐入口。-CC 的意思是让 tmux 通过控制模式把 pane 和 window 映射到 iTerm2 的原生界面上。这样你既能享受 tmux 的会话管理能力，又不用完全退回纯字符界面的 pane 管理体验。对 macOS 用户来说，这个组合确实是目前最舒服的入口。
如果你只是想快速试试，可以先装好 tmux：
brew install tmux
然后在 iTerm2 里这样启动一个专门给 Agent Teams 用的 session：
tmux -CC new -s claude-team
claude
如果你不用 iTerm2，只想走普通终端，也可以直接：
tmux new -s claude-team
claude
接着再把 teammateMode 设成 "tmux"，或者在已经处于 tmux 会话里的情况下直接用默认的 auto。这样一来，当 Claude Code 创建 team 时，就会优先为各个 Teammate 分配 pane，而不是都塞进同一个进程内视图。
tmux 在这里还有一个很现实的好处：排障方便。官方文档专门提到，团队结束后有时会遗留 orphaned tmux session，这时候直接列出并删除即可：
tmux ls
tmux kill-session -t claude-team
如果会话还在，但你只是断开了当前终端，也可以随时接回去：
tmux attach -t claude-team
这个工作流非常适合长任务。比如你让一个团队去做多角度代码审查，自己中途需要切走去回消息或者关掉终端，tmux 会比纯 in-process 模式让人安心很多。
当然，官方也提醒了兼容性问题。tmux 在某些操作系统上有已知限制，而且 split-pane 模式并不是每个终端都支持得很好。文档里明确点名，VS Code 集成终端、Windows Terminal、Ghostty 目前都不支持这套 split-pane 体验。所以如果你想稳定玩 Agent Teams 的可视化分栏，我自己的建议也和文档一致：macOS 下优先 iTerm2 + tmux -CC。
Agent Teams 并不是“临时内存里跑几个角色”这么简单，它会在本地维护团队状态。官方文档给出的路径是：
~/.claude/teams/{team-name}/config.json
~/.claude/tasks/{team-name}/
这些文件不只是记录一下名字，而是持有运行时状态，比如 session ID、tmux pane ID、当前成员列表等。官方明确建议不要手工编辑这些文件，因为 Claude Code 在下一次状态更新时会直接覆盖。你真正应该自定义的，不是 team config，而是 subagent definitions、CLAUDE.md、权限策略、MCP 与 skills 这类可复用配置。
另一个很关键的机制是上下文加载。Teammate 在启动时会像普通 Claude Code 会话一样加载项目里的 CLAUDE.md、MCP servers 和 skills，但不会继承 Lead 已经聊过的全部对话历史。这个行为非常合理，因为它保证每个队友的上下文都是干净、独立的，但也意味着你不能假设“Lead 已经知道的东西，队友天然都知道”。任务特定的上下文，还是要在 spawn prompt 里讲清楚。
官方还提到一个高级用法：你可以把某个 subagent definition 作为 teammate 角色复用，比如 security-reviewer 或 test-runner。不过当它作为 teammate 运行时，subagent definition 里的 skills 和 mcpServers frontmatter 不会被套进来，Teammate 仍然使用项目和用户级的 skills、MCP 设置。这一点很容易踩坑，尤其是你以为自己给 subagent 配的 MCP 会自动带到 teammate 身上时。
官方把限制写得挺直白，我觉得这反而是好事。首先，in-process teammates 目前不能被 /resume 和 /rewind 正常恢复；恢复会话之后，Lead 有可能还试图给已经不存在的队友发消息。其次，任务状态有时会滞后，某些任务明明做完了却没被正确标成 completed，从而把后续依赖链堵住。再者，队友关闭时不会立刻停下，而是会先完成当前请求或当前工具调用，所以 shutdown 可能比你预期更慢。
还有几个边界也值得记住。一个 Lead 一次只能管理一支团队，不能在团队里再嵌套创建新团队；Lead 身份固定，不能把某个 Teammate 提升成新的 Lead；所有 Teammate 默认继承 Lead 的权限模式，也就是说如果 Lead 用了 --dangerously-skip-permissions，整个团队都会跟着放开权限。这些限制共同说明了一点：Agent Teams 已经能用，但还远远没到可以把一切都交给它自动运转的程度。
结合官方建议和我自己的感受，我现在的使用方法会保守一些。团队规模优先控制在 3 到 5 人，这样并行收益和协调成本最平衡；任务尽量切到每个队友各自拥有清晰的文件域，不让两个人碰同一个文件；如果看到 Lead 开始自己上手实现，而不是等队友先做完，我会直接告诉它“先等 teammates 完成当前任务再继续”；如果是第一次尝试 Agent Teams，我也会优先用研究、审查、排障这类边界更清楚的任务，而不是一上来就让它并行改核心代码。
我现在对 Agent Teams 的看法，比第一次接触时更务实了一点。它当然不是“多开几个 Claude”这么简单，因为真正有价值的是那套协作机制：共享任务列表、队友直连通信、Lead 统一协调、计划审批、清理与关停、以及基于 tmux 或 iTerm2 的可视化分栏运行方式。这些东西加在一起，才让它像一个团队，而不是像一堆孤零零的并行会话。
但它也确实还在实验阶段，文档里写出来的限制几乎都是真限制，不是那种可有可无的免责声明。对我来说，最合适的姿势不是把它当万能生产机器，而是把它放进那些天然适合并行探索和多视角审查的任务里。用对场景，它会非常亮眼；用错场景，协调成本和 Token 开销会立刻反噬你。尤其如果你准备认真用 split-pane 模式，我会建议你顺手把 tmux 这一课补上，因为这层终端基础设施，会直接决定你对 Agent Teams 的第一印象到底是“真能用”，还是“看起来很先进但操作起来很乱”。
2026-04-05 13:00:00
这一年我试过不少语音转文字工具。最开始只是想少打一点字，后来发现问题没那么简单。真正拖慢我的，不只是键盘输入本身，而是在 [[Slack]]、邮件、[[Obsidian]]、浏览器输入框之间来回切换时，那种不断被打断的感觉。
[[Speakly]] 是最近让我比较愿意持续打开的一款。它不是我用过最完美的一个，但它确实有几个点做对了，所以我还是想单独记一笔。
我现在越来越觉得，语音输入迟迟没有真正普及，问题不完全在识别率。主流模型把字听对，已经不算太难了。真正卡人的，是两件事。
一件是口语和书面语根本不是一回事。人讲话的时候会有很多停顿、重复、口头禅，思路也经常是边说边改。原样转成文字，大概率还是要自己再清一遍。
另一件是使用摩擦。很多工具在单独的 App 里很好用，一旦切回邮件、聊天窗口、代码编辑器，就又断了。你得切窗口、找按钮、重新开始。来回几次之后，人还是会乖乖回到键盘。
所以现在我看语音输入工具，主要就盯两件事：它能不能把我说的话整理成能直接发出去的文字，以及它能不能在任何输入框里都足够顺手。
[[Speakly]] 是 [[Genspark]] 推出的一款系统级语音输入工具。它不只是逐字转录，而是会顺手帮你做一轮整理，比如去掉口头禅、补标点、把明显的病句修顺一点。有些场景下，它还会按上下文帮你组织格式。你在写邮件时，它输出的内容会更像一封邮件。你在说一串条目时，它也会更像列表。
我更看重的是它的全局调用。默认双击右 Alt 键就能开始说，结果直接落在当前光标的位置。这个设计看上去没什么新鲜的，但只要它足够稳定，你就会很自然地在 Gmail、[[Slack]]、WhatsApp、[[Notion]]、代码编辑器这些地方都用起来，而不是把它当成一个偶尔打开的演示工具。
另外一个对我有吸引力的点是混语场景。平时写东西时，我经常会中英文夹着来，偶尔还会掺一些日语名词。能不能自动识别语种、不要把专有名词搞得太离谱，这件事很影响长期体验。[[Speakly]] 在这方面至少让我愿意继续用下去。
我主要拿它做三类事情，写邮件和消息回复、记录碎片想法、在笔记里口述一段草稿。
邮件场景最能看出差别。以前我要先在脑子里过一遍措辞，再慢慢敲，最后还得回头修语气。现在可以先把意思说出来，让 [[Speakly]] 帮我落成一版文字，再改细节。它不是每次都写得刚刚好，但至少能把最烦的第一稿先铺出来。
记录想法也很好用。我经常是在走路、洗碗、或者随手整理东西的时候冒出一个点子。等坐回电脑前，脑子里的句子已经散掉一半。现在可以直接唤起 [[Speakly]]，把那一段先吐出来，再丢进 [[Obsidian]]。这件事本身就值回不少时间。
写笔记时我也会用它先口述段落，再手工修一遍。这个流程比从零开始敲字轻松不少，尤其是当我已经知道自己想表达什么，只是不想再花力气一个字一个字打出来的时候。
当然，它也不是没有问题。我遇到过激活后短暂卡一下的情况，切换输入设备时也碰到过一次识别断开。只不过这些问题还没有频繁到让我直接卸载。对一个我愿意放进日常工作流的工具来说，这已经算不错了。
翻了一下我自己过去写过的笔记和文章，这一类工具其实已经很多了。[[Speakly]] 并不是孤例，它最接近的也不是语音笔记类产品，而是 系统级语音输入 + AI 润色 这一条线里的几款工具。
把这些工具放在一起看，我自己的判断很简单。[[Speakly]] 和 [[Typeless]] 最像，都是想把“语音输入”往“语音起草”推进一步。[[Aqua Voice]] 偏助手，[[Spokenly]] 偏本地离线，[[Voicenotes]] 偏语音笔记。你先想清楚自己要解决的是哪一个问题，再去选工具，反而比较不容易踩坑。
平台支持方面，[[Speakly]] 覆盖 macOS（M1 芯片及以上，macOS 12.0+）、Windows、iOS 和 Android，也有 Chrome 扩展，基本上主流平台都涵盖了。
我现在对语音输入工具的判断标准已经很现实了。不是看它 demo 有多惊艳，也不是看宣传里说自己比打字快几倍，而是看它会不会让我真的多用几次。[[Speakly]] 至少做到了这一点。我会在邮件、聊天窗口、[[Obsidian]] 里反复把它叫出来，这就说明它已经过了“能看”和“能用”之间的那条线。
如果你之前试过语音输入，但总觉得差一点，[[Speakly]] 可以试一下。尤其是你已经不满足于“识别成字”这件事，而是希望它顺手把话整理成人能直接用的文字。
如果你刚好想试，可以走我的邀请链接，我们双方都能拿到一点免费权益：
https://www.genspark.ai/speakly/invite/NTAxZjQ3YzNMOTk5Y0wzN2M0TDBmOGIyNDFhYzQ2YUw1NmQy
