thClaws 上手：用 Rust 做一个主权 Agent 工作台

Agent 工作台开始往“一个二进制”收拢

现在的 AI 编程工具有点分裂：一个 CLI 负责聊天，一个编辑器插件负责改文件，一个 Web UI 负责看会话，一个脚本负责跑自动化。工具越多，能力越强，但状态也越散。你要换机器、换模型、换工作目录时，就会发现很多上下文其实不在项目里，而是黏在某个客户端上。

thClaws 走的是另一条路：用 Rust 做一个本地 Agent 工作台，把 GUI、CLI REPL、one-shot 模式、MCP、Skills、AGENTS.md、记忆、知识库和多 Agent 协调尽量收进同一个二进制。

这类项目值得看，因为它回答的是一个很现实的问题：Agent 能不能成为本机工作台，而不是某个云服务或插件的附属品。

三个入口，一个引擎

thClaws 的入口分成三类：

Desktop GUI：Terminal、Chat、Files，可选 Team tabs；
CLI REPL：适合 SSH、服务器、无 GUI 场景；
Non-interactive mode：一次性 prompt，跑完退出，适合脚本和 CI。

这三个入口背后是同一套配置、同一套 session、同一套工具能力。这个设计比“GUI 里又嵌一个终端”更干净，因为不同人可以选不同界面，但不需要维护多份状态。

研究人员可以用 Chat，工程师可以用 Terminal，自动化脚本可以用 one-shot。入口不同，底层一致。

从源码构建：先确认你的环境

如果直接下载 release，就按平台拿预编译包。想从源码构建，需要 Rust 1.85+、Node.js 20+、pnpm 9+：

git clone https://github.com/thClaws/thClaws.git
cd thClaws

# Build frontend，React + Vite 会被打包成单个 HTML
cd frontend && pnpm install && pnpm build && cd ..

# Build Rust，生成 CLI + GUI
cargo build --release --features gui --bin thclaws

# Run
./target/release/thclaws
./target/release/thclaws --cli
./target/release/thclaws -p "what does src/main.rs do?"

这几行也能看出它的产品判断：GUI 不是一个重型前端服务，而是打包进本地应用；CLI 也不是附属功能，而是同一个 binary 的一等入口。

第一次启动先把 provider 和密钥放对地方

进入 REPL 后，先选 secrets backend。默认更推荐 OS keychain，而不是把 key 明文写进配置文件。然后配置 provider：

thclaws

❯ /provider anthropic
❯ /model claude-sonnet-4-6

# 或者走 OpenRouter
❯ /provider openrouter
❯ /model openrouter/anthropic/claude-sonnet-4-6

thClaws 支持 Anthropic、OpenAI、Gemini、DashScope、OpenRouter、Ollama，以及 OpenAI-compatible 入口。这对自托管网关、LiteLLM、vLLM、企业代理都比较友好。

常用命令也比较直：

❯ /help
❯ /models
❯ /kms
❯ /skill install https://github.com/anthropics/skills.git
❯ /mcp add github https://mcp.github.com
❯ ! git status

注意最后这个 ! shell escape。它不走模型、不消耗 token，也不需要 Agent 往返，适合你自己手动看状态。但团队里要约定清楚：shell escape 是给人用的，不是给自动化乱开的后门。

它最值得看的不是“会写代码”，而是标准文件都认

thClaws 认这些开放约定：

AGENTS.md / CLAUDE.md        项目指令
SKILL.md                     可复用工作流
.mcp.json                    MCP server 配置
.thclaws/settings.json       项目配置
.thclaws/kms/<name>/pages/   项目知识库页面

这件事比功能清单更重要。工具会变，模型会换，但项目级说明、技能包、MCP 配置、知识库如果能留在仓库里，就不容易被某个客户端锁死。

尤其是 AGENTS.md 和 SKILL.md，现在越来越像 Agent 工程里的“基础文件”。一个项目如果已经把编码规范、测试规则、发布步骤、审查要求沉到这些文件里，换工具时成本会低很多。

KMS：别什么都上向量库

thClaws 的 knowledge bases 走的是 Karpathy 那套 LLM-wiki 思路：每个知识库有 markdown pages 和一个 index.md，Agent 每轮拿到目录，需要时再用 KmsRead / KmsSearch 工具读取。

它没有一上来就做 embedding，也没有默认把整仓库塞进向量库。这点挺克制。很多项目的“知识库”其实就是几十页高质量 markdown，用目录 + grep/read 就够了。向量库不是不能用，而是别变成默认重锤。

一个合理结构可以是：

.thclaws/kms/product/pages/pricing.md
.thclaws/kms/product/pages/onboarding.md
.thclaws/kms/product/index.md

.thclaws/kms/engineering/pages/deploy.md
.thclaws/kms/engineering/pages/testing.md
.thclaws/kms/engineering/index.md

让 Agent 先知道有哪些页，再按需读，通常比每次把一堆无关材料塞进上下文更稳。

多 Agent 协作：别只看“可以递归”

thClaws 支持通过 Task tool 把子任务委托给隔离 sub-agent，也支持 Agent Teams：多个 thClaws 进程通过共享 mailbox 和 task queue 协作，每个进程可以在独立 tmux pane 和 git worktree 里干活。

这方向很诱人，但上线时要收着用。真正稳的做法是：

一个 lead agent 负责拆任务和合并
每个 worker agent 只碰自己的 worktree
测试和 lint 作为合并闸门
共享 mailbox 只传任务和结果，不传密钥

多 Agent 不是并发越多越好。并发越多，越需要明确边界和回滚路径。

什么时候适合用 thClaws

适合：

你想要一个本机长期使用的 Agent 工作台；
你不想把全部状态锁进某个 IDE；
你已经开始用 AGENTS.md、Skills、MCP；
你需要 GUI + CLI + one-shot 三种入口；
你想在同一工具里接本地模型和云模型。

不太适合：

你只要一个轻量终端聊天器；
团队高度依赖 IDE 内联补全和复杂重构 UI；
你还没整理项目指令、权限边界和知识库。

如果你要在远程开发机或小团队共享环境里跑 CLI / one-shot 模式，建议单独准备隔离账号或测试 VPS。需要一台轻量实验机，可以看看雨云服务器方案，重点不是配置多高，而是别让 Agent 和生产密钥混住。

最后看法

thClaws 的重点，不是“Rust 写的 Agent 工具”这个标签，而是它把 Agent 工作台需要的几个长期资产都往开放文件里放：项目说明、技能、MCP、KMS、配置、记忆。

这比单纯做一个漂亮聊天窗口更有前途。Agent 工具最后拼的不是界面谁炫，而是谁能把工作流留下来、迁走、复用，还能在本机把控制权握住。