LeanClaw：构建安全高效的本地AI助手运行时架构与实践-深圳市維司達科技有限公司

1. 项目概述：一个为本地高效执行而生的AI助手运行时

如果你和我一样，对市面上那些动辄要求云端API调用、资源占用巨大、安全边界模糊的AI助手框架感到厌倦，那么今天要聊的这个项目——LeanClaw，可能会让你眼前一亮。这是一个用TypeScript构建的高效、安全优先的AI助手运行时，核心目标就三个：快速本地执行、低资源消耗、通过受限的工具访问实现可靠的自动化。简单来说，它让你能在自己的机器上，用一个可控、安全的方式，运行一个功能强大的AI助手，并且能通过插件扩展其能力。

LeanClaw的设计理念非常务实：它不试图重新发明轮子，而是巧妙地融合了已有项目的精华。你可以把它看作是NanoClaw的容器隔离与可审计代码库，和OpenClaw的网关协议与插件架构的一次“强强联合”。最令人印象深刻的是，如此丰富的功能，其核心实现被浓缩在了大约3500行TypeScript代码里，这本身就体现了“Lean”（精益）的哲学。

这个项目适合谁呢？首先是开发者和运维工程师，你们需要一个能集成到本地开发流水线、CI/CD流程中的自动化AI伙伴，用于代码审查、脚本生成或系统监控。其次是注重隐私和安全的技术团队，希望AI能力在完全受控的本地环境中运行，避免数据外泄。最后，任何对构建可扩展、企业级AI应用感兴趣的工程师，都能从LeanClaw清晰的架构和严格的安全模型中汲取灵感。

2. 核心架构与设计哲学解析

LeanClaw的架构设计处处体现着“约束即自由”的思想。它不是提供一个无所不能的“上帝模式”AI，而是通过精心设计的边界，让AI在安全、可控的范围内发挥最大效用。这种设计对于生产环境至关重要。

2.1 融合式架构：NanoClaw与OpenClaw的精华

理解LeanClaw，最好从它的两个“前辈”说起。NanoClaw强调极致的轻量和隔离，通常通过容器化技术将每个AI代理（agent）封装在独立的环境中运行，确保任何单点故障或安全漏洞都不会波及其他部分。OpenClaw则定义了一套标准的网关协议和插件体系，旨在解决不同AI助手运行时之间的互操作性问题，让生态工具能够通用。

LeanClaw的聪明之处在于，它没有二选一，而是做了个“嫁接”。它继承了NanoClaw的容器隔离和安全审计基因，确保每个任务都在一个短暂的Docker容器中执行，任务结束容器即销毁，文件系统相互隔离。同时，它完整实现了OpenClaw Protocol v3的WebSocket + HTTP网关以及插件架构。这意味着，所有遵循OpenClaw标准的客户端工具、管理界面都能无缝接入LeanClaw，而LeanClaw的插件也能在兼容OpenClaw的其他运行时上运行（理论上）。这种兼容性极大地降低了生态锁定的风险。

2.2 安全第一的多层防御模型

安全是LeanClaw的立身之本，其安全模型是层层递进的，我称之为“洋葱模型”。

最外层：网络与认证网关。所有请求必须通过统一的网关（默认ws://127.0.0.1:18789）进入。网关支持API密钥认证，如果未设置LEANCLAW_GATEWAY_API_KEY，则网关完全开放（仅建议用于本地开发）。这层控制了“谁可以敲门”。
中间层：请求与访问控制。网关内部实现了基于IP、发送者（sender）和群组（group）的滑动窗口速率限制，防止滥用。同时，可以通过sender-allowlist.json配置白名单，精确控制哪个用户或系统可以访问哪个聊天频道。这层控制了“谁能进来，以及能以多快的频率行动”。
核心层：运行时隔离与资源控制。这是最关键的一层。每个AI代理的任务执行都在一个全新的Docker容器中进行。这个容器：
- 文件系统隔离：默认无法访问宿主机任何文件。
- 挂载白名单：只有明确配置在mount-allowlist.json中的目录，才能被挂载到容器内供AI操作。这就像给AI划定了一个“工作区”。
- 凭证隔离：API密钥（如Anthropic、GitHub Token）通过环境变量在容器启动时注入，绝不会写入容器的磁盘。同时，容器内的.env文件会被覆盖为/dev/null，防止敏感配置泄露。
- 模式拦截：自动阻止挂载包含.ssh,.aws,.kube等敏感凭证的路径。
- 资源限制：可以设置容器的最大并发数、硬超时和空闲超时，防止失控的AI任务耗尽系统资源。
内核层：审计与钩子。所有关键操作，如容器启停、配置变更、权限访问，都会被记录到SQLite审计日志中，做到所有行为可追溯。此外，还提供了RBAC（基于角色的访问控制）钩子和预运行脚本钩子（pre-run hooks），允许你在任务执行前进行自定义验证（例如，检查当前系统负载，或确认用户余额）。

这种设计意味着，即使AI模型被诱导尝试执行危险操作（比如“请读取我的SSH私钥”），它也会在多层防御下碰壁，从根本上降低了“提示词注入”攻击的风险。

2.3 效率优化：避免浪费的智能调度

除了安全，LeanClaw在效率上也做了细致考量。我特别欣赏其“心跳-定时任务冲突避免”机制。AI助手通常需要定期执行心跳检测以保持活跃，同时也可能有用户设定的定时任务（Cron）。LeanClaw可以配置（LEANCLAW_HEARTBEAT_SKIP_WHEN_BUSY=true）在定时任务执行期间，自动跳过不必要的心跳检测。这避免了计算资源的无意义争用，在资源受限的边缘设备上尤其有用。

另一个亮点是基于关键词的零成本消息路由。你可以在配置中定义规则，例如：消息中含有“code review”或“PR”关键词，就自动路由给GitHub Copilot模型；含有“research”就路由给Gemini模型。这个决策发生在调用任何LLM之前，仅进行字符串匹配，零额外成本。这让你能根据任务类型智能分配最合适的模型，而无需编写复杂的决策逻辑或支付额外的分类API调用费用。

3. 从零开始部署与深度配置指南

纸上得来终觉浅，绝知此事要躬行。让我们动手，把一个LeanClaw实例从零搭建起来，并深入每一个配置细节。我假设你已经在开发机上准备好了Node.js环境（建议v18+）和Docker守护进程。

3.1 基础环境搭建与启动

首先，获取项目代码。由于这是一个开源项目，你可以直接从GitHub仓库克隆。

# 克隆仓库 git clone https://github.com/scottgl9/leanclaw.git cd leanclaw # 安装依赖 npm install

接下来是配置环节。项目根目录下有一个.env.example文件，这是所有环境变量的模板。我们需要复制它并填写自己的值。

# 复制环境变量模板 cp .env.example .env

现在，用你喜欢的编辑器打开.env文件。这里面的每一个变量都至关重要，我来逐一拆解：

# 网关配置：这是LeanClaw对外的门户 LEANCLAW_GATEWAY_PORT=18789 LEANCLAW_GATEWAY_HOST=127.0.0.1 # 生产环境建议改为 0.0.0.0 并搭配防火墙 LEANCLAW_GATEWAY_API_KEY= # 留空则网关无需认证（仅限本地开发！） # LLM供应商配置：至少配置一个，LeanClaw才能工作 LEANCLAW_ANTHROPIC_API_KEY=sk-ant-xxx... # 你的Anthropic Claude API密钥 LEANCLAW_GITHUB_TOKEN=ghp_xxx... # 你的GitHub Personal Access Token (需 Copilot 权限) LEANCLAW_DEFAULT_PROVIDER=anthropic # 默认使用的供应商 # 容器运行时配置：控制AI代理的执行环境 LEANCLAW_CONTAINER_IMAGE=leanclaw-agent:latest # 代理使用的Docker镜像 LEANCLAW_MAX_CONCURRENT_CONTAINERS=5 # 最大并发容器数，根据CPU核心数调整 LEANCLAW_CONTAINER_TIMEOUT=1800000 # 容器硬超时30分钟（毫秒） LEANCLAW_IDLE_TIMEOUT=1800000 # 容器空闲超时30分钟 # 系统行为配置 LEANCLAW_HEARTBEAT_INTERVAL=60000 # 心跳间隔1分钟 LEANCLAW_HEARTBEAT_SKIP_WHEN_BUSY=true # 启用心跳-定时任务冲突避免

实操心得一：关于API密钥的安全永远不要将真实的API密钥提交到版本控制系统（如Git）。.env文件已经被包含在.gitignore中。对于团队协作，可以考虑使用dotenv-vault或类似的加密秘密管理工具。另外，LEANCLAW_GATEWAY_API_KEY在生产环境中必须设置，否则你的LeanClaw网关将对网络上的任何人开放。

配置完成后，编译并运行：

# 编译TypeScript代码 npm run build # 启动LeanClaw服务 npm start

如果一切顺利，你将在终端看到类似LeanClaw gateway listening on ws://127.0.0.1:18789的日志。恭喜，LeanClaw核心服务已经跑起来了！

对于开发阶段，更推荐使用热重载模式，这样修改代码后会自动重启：

npm run dev

3.2 高级配置详解：消息路由与安全策略

基础服务跑通后，我们来配置两个高级功能，它们能极大提升使用体验和安全性。

1. 智能消息路由配置

这个功能让你能“看人下菜碟”。创建配置文件~/.config/leanclaw/config.json（如果目录不存在请手动创建）。

{ "messageRouting": { "rules": [ { "match": ["code review", "PR", "diff", "refactor", "bug fix"], "model": "github-copilot" }, { "match": ["explain", "concept", "theory", "how does"], "model": "anthropic/claude-3-5-sonnet-20241022" }, { "match": ["translate", "summarize", "rewrite"], "model": "anthropic/claude-3-haiku-20240307" } ], "default": "anthropic/claude-3-5-sonnet-20241022" } }

规则顺序至关重要：LeanClaw采用“首次匹配即胜出”的策略。所以要把最具体、最常用的规则放在前面。例如，关于“代码”的规则应置于“解释概念”的规则之前。
匹配是大小写不敏感的：无需担心用户输入的是“Code Review”还是“code review”。
default字段是安全网：如果用户的消息不匹配任何规则，将使用这里指定的默认模型。如果不设置，则回退到环境变量LEANCLAW_DEFAULT_PROVIDER指定的供应商的默认模型。

2. 文件系统挂载白名单

这是安全模型的核心之一。默认情况下，AI代理在容器内无法访问宿主机的任何文件。你需要明确告诉LeanClaw哪些目录是“可信任工作区”。

创建文件~/.config/leanclaw/mount-allowlist.json：

[ { "hostPath": "/home/yourname/development/projects", "containerPath": "/workspace", "readOnly": false }, { "hostPath": "/home/yourname/Downloads", "containerPath": "/downloads", "readOnly": true }, { "hostPath": "/var/log/myapp", "containerPath": "/logs", "readOnly": true } ]

hostPath: 宿主机上的绝对路径。
containerPath: 该路径在容器内部映射的位置。
readOnly: 是否为只读挂载。对于源代码目录，通常设为false以允许AI修改；对于日志、下载目录等，设为true更安全。
绝对路径的必要性：使用相对路径或~（家目录）符号可能导致不可预期的行为，务必使用绝对路径。

实操心得二：最小权限原则在配置挂载白名单时，务必遵循“最小权限原则”。只挂载AI完成任务所必需的目录，并且尽可能使用readOnly: true。例如，如果你只希望AI读取某个配置模板然后输出建议，就没有必要给它可写权限。每次新增挂载项时，都要问自己：这个目录里有没有敏感文件？AI真的需要写权限吗？

3.3 插件系统初探：扩展你的AI助手

LeanClaw本身不捆绑任何插件，它的能力边界由你添加的插件定义。这保持了核心的精简。插件可以添加新的技能（Skills）、频道（Channels）或工具（Tools）。

假设我们想添加一个简单的“天气查询”插件。

创建插件目录结构：

mkdir -p ~/leanclaw-plugins/weather-plugin cd ~/leanclaw-plugins/weather-plugin

创建插件清单leanclaw.plugin.json：

{ "id": "weather-plugin", "name": "Weather Fetcher", "version": "0.1.0", "main": "dist/index.js", "channels": ["weather-channel"], "skills": ["skills/"] }

编写插件主逻辑src/index.ts：

import { PluginSDK } from 'leanclaw/plugin-sdk'; export default function (sdk: PluginSDK) { // 注册一个天气技能 sdk.skills.register('get-weather', { description: 'Get current weather for a city', parameters: { city: { type: 'string', description: 'City name' } }, execute: async (params: { city: string }) => { // 这里应该是调用真实天气API的逻辑 // 例如：const data = await fetch(`https://api.weatherapi.com/v1/current.json?key=YOUR_KEY&q=${params.city}`); return `The weather in ${params.city} is sunny and 22°C. (This is a mock response)`; } }); sdk.logger.info('Weather plugin loaded'); }

编译并配置：

# 在插件目录内 npm init -y npm install typescript @types/node --save-dev npx tsc --init # 修改tsconfig.json，设置 "outDir": "./dist" npx tsc

最后，告诉LeanClaw插件在哪里。在你的LeanClaw主项目.env文件中添加：
```
LEANCLAW_PLUGIN_DIR=/home/yourname/leanclaw-plugins
```
重启LeanClaw服务，它就会自动发现并加载weather-plugin。之后，AI助手就可以在对话中使用get-weather这个技能了。

4. 网关API实战：连接、通信与管理

LeanClaw的网关是控制一切的枢纽。它同时提供HTTP和WebSocket两种接口。HTTP用于健康检查、就绪探针和指标拉取；WebSocket则用于实时的、双向的指令与消息流，遵循OpenClaw Protocol v3。

4.1 HTTP端点：健康状态与监控

这些端点对于将LeanClaw集成到Kubernetes、Docker Swarm等编排系统，或使用Prometheus进行监控至关重要。

GET /health：存活探针。只要LeanClaw进程在运行，就返回200 OK。用于告诉负载均衡器或编排系统“我还活着”。
GET /ready：就绪探针。检查更深层次的依赖状态，如数据库连接、Docker守护进程是否可达、消息通道是否正常。全部通过才返回200 OK。用于判断服务是否真的准备好接收流量。
GET /metrics：指标端点。返回一个JSON对象，包含丰富的运行时指标，例如：
```
{ "containers": { "active": 2, "max": 5, "totalSpawned": 45 }, "memory": { "heapUsed": 123456789, "rss": 234567890 }, "uptime": 3600, "tokens": { "usedToday": 15000, "budgetDaily": 50000 } }
```
你可以编写一个简单的脚本，定期抓取/metrics，将数据发送到时序数据库（如InfluxDB、TimescaleDB），从而监控LeanClaw的资源使用情况和任务负载。

4.2 WebSocket协议：与AI助手实时对话

真正的交互发生在WebSocket连接上。我们使用wscat这个命令行工具来模拟客户端，进行一场实战。

建立连接：

# 安装wscat npm install -g wscat # 连接到LeanClaw网关（如果设置了API_KEY，需要在连接头中提供） wscat -c ws://127.0.0.1:18789

连接成功后，服务器会立即发送一个connect.challenge事件，其中包含一个随机数（nonce）。

握手认证：客户端需要回应一个connect请求。如果网关设置了API_KEY，需要在这里提供。
```
{ "jsonrpc": "2.0", "method": "connect", "params": { "version": "3.0", "client": "MyClient/1.0", "auth": { "type": "api_key", "key": "your_gateway_api_key_here" // 如果.env中未设置，此项可省略 } }, "id": 1 }
```
服务器验证通过后，会回复hello-ok，其中包含服务器支持的功能列表和策略（如速率限制）。
发送聊天消息：握手成功后，就可以开始聊天了。假设我们配置了Anthropic Claude。
```
{ "jsonrpc": "2.0", "method": "chat.send", "params": { "channel": "default", // 聊天频道 "messages": [ {"role": "user", "content": "请用Python写一个函数，计算斐波那契数列的第n项。"} ], "model": "anthropic/claude-3-5-sonnet-20241022" // 可覆盖默认模型 }, "id": 2 }
```
LeanClaw会处理这条消息：检查路由规则（可能根据“Python”关键词路由）、进行权限和速率限制检查、然后启动一个Docker容器，在容器内调用Claude API，并将流式或非流式的响应通过WebSocket返回给客户端。
管理任务：查询与中止：你可以在另一个终端用wscat连接，执行管理操作。
- 列出会话：{"jsonrpc":"2.0","method":"sessions.list","id":3}
- 获取系统状态：{"jsonrpc":"2.0","method":"status","id":4}
- 中止一个正在进行的聊天：{"jsonrpc":"2.0","method":"chat.abort","params":{"sessionId":"some-session-id"},"id":5}

实操心得三：WebSocket连接的管理在生产环境中，直接使用wscat是不现实的。你需要编写一个稳定的客户端。重点处理好以下几点：1)断线重连逻辑，网络波动是常态；2)心跳保活，虽然LeanClaw服务端可能配置了心跳，但客户端也应定期发送ping或空帧防止连接被中间设备断开；3)请求去重与序列化，确保异步消息的发送顺序和响应匹配。可以考虑使用像rpc-websockets这样的库来简化JSON-RPC over WebSocket的实现。

4.3 令牌预算管理：控制你的AI花销

对于按Token收费的模型（如Claude），成本控制是必须的。LeanClaw内置了基于群组（Group）的令牌预算管理。

配置位于数据库或通过管理API设置。其逻辑是：

你可以为不同的“组”（可以是部门、团队、项目）设置每日和每月的令牌使用上限。
当使用量达到上限的80%时，系统会发出警告日志。
当达到100%时，该组的所有LLM请求将被阻塞，直到下一个周期重置。

这个功能对于企业多团队共享一个LeanClaw实例，并需要分摊成本的情况非常有用。它从系统层面防止了某个团队的失控脚本或高频请求耗尽全部预算。

5. 生产环境部署、运维与故障排查

将LeanClaw用于个人项目和学习是一回事，将其部署到生产环境服务团队则是另一回事。这里分享一些我从测试到准生产环境部署中积累的经验和踩过的坑。

5.1 容器镜像定制与优化

LeanClaw默认使用leanclaw-agent:latest这个镜像来运行AI代理。你需要构建自己的镜像，这是一个优化性能和安全的绝佳机会。

Dockerfile示例：

# 使用轻量级基础镜像 FROM node:18-slim # 安装仅运行所需的系统依赖，例如某些插件可能需要python或git RUN apt-get update && apt-get install -y --no-install-recommends \ ca-certificates \ git \ python3 \ && rm -rf /var/lib/apt/lists/* # 创建一个非root用户运行应用，增强安全性 RUN useradd --create-home --shell /bin/bash leanclaw USER leanclaw WORKDIR /home/leanclaw # 复制预装的工具脚本或依赖（可选） # COPY --chown=leanclaw:leanclaw tools/ /home/leanclaw/tools/ # 设置容器启动命令（LeanClaw运行时会在容器内启动一个Agent进程） # 这个命令通常由LeanClaw主服务通过`docker run`传递，这里可以是一个简单的等待脚本或具体的agent入口 CMD ["sleep", "infinity"]

构建与推送：

docker build -t your-registry/leanclaw-agent:v1.0 . docker push your-registry/leanclaw-agent:v1.0

然后，在LeanClaw的.env文件中更新镜像地址：

LEANCLAW_CONTAINER_IMAGE=your-registry/leanclaw-agent:v1.0

避坑指南一：镜像大小与启动速度不要忽视镜像大小。一个臃肿的镜像会拖慢容器启动速度，尤其是在快速创建销毁的场景下。node:slim比node:latest小得多。仔细评估apt-get install的每一项。如果某些工具不常用，可以考虑在插件中按需动态安装，而不是打包进基础镜像。

5.2 系统服务化与高可用考虑

在Linux服务器上，我们通常使用systemd来管理LeanClaw服务，确保其开机自启和故障重启。

创建服务文件/etc/systemd/system/leanclaw.service：

[Unit] Description=LeanClaw AI Assistant Runtime After=network.target docker.service Requires=docker.service [Service] Type=simple User=leanclaw # 专门为LeanClaw创建一个系统用户 Group=leanclaw WorkingDirectory=/opt/leanclaw EnvironmentFile=/opt/leanclaw/.env # 将你的.env文件放在这里 ExecStart=/usr/bin/npm start Restart=on-failure RestartSec=10 StandardOutput=journal StandardError=journal # 安全强化 NoNewPrivileges=true PrivateTmp=true ProtectSystem=strict ReadWritePaths=/opt/leanclaw/data /home/leanclaw/.config/leanclaw # 仅允许写入必要路径 [Install] WantedBy=multi-user.target

关键配置说明：

After=... docker.service：确保Docker服务先启动。
User/Group：使用非root用户运行，这是安全最佳实践。
EnvironmentFile：集中管理所有环境变量。
Restart=on-failure：进程异常退出时自动重启。
ProtectSystem=strict和ReadWritePaths：利用systemd的沙盒功能，严格限制服务可访问的文件系统路径，这是对LeanClaw自身容器隔离的又一重加固。

高可用架构：对于关键业务，单点部署是不够的。你可以考虑：

无状态水平扩展：将LeanClaw网关部署在多个节点上，前面用负载均衡器（如Nginx, HAProxy）分发WebSocket和HTTP流量。由于会话（Session）和容器状态是保存在每个实例本地的，这种模式适合任务彼此独立、无需共享状态的场景。
共享存储：如果需要跨实例管理任务状态，可以将审计日志数据库（SQLite）替换为PostgreSQL或MySQL，并让所有LeanClaw实例连接同一个数据库。但这需要修改LeanClaw的db.ts模块，复杂度较高。目前更推荐将LeanClaw作为“边缘计算节点”，每个节点负责特定类型的任务。

5.3 常见问题与故障排查实录

即使设计再精良的系统，在实际运行中也会遇到问题。下面是我遇到的一些典型问题及解决方法。

问题1：容器启动失败，日志显示“Cannot connect to the Docker daemon”

现象：LeanClaw日志报错，无法创建Agent容器。
排查：
1. 检查Docker服务是否运行：sudo systemctl status docker。
2. 检查运行LeanClaw的用户（如leanclaw）是否在docker用户组中：groups leanclaw。如果没有，添加：sudo usermod -aG docker leanclaw，然后需要重新登录该用户。
3. 如果使用systemd服务，确保服务文件中有Requires=docker.service。
解决：通常是权限问题。确保服务用户有权限访问Docker socket。

问题2：AI代理执行超时，任务被强制终止

现象：一个长时间运行的任务（如处理大型文件）在未完成时被中断，日志显示Container timeout。
排查：
1. 检查任务本身是否确实需要更长时间。
2. 查看.env中的LEANCLAW_CONTAINER_TIMEOUT和LEANCLAW_IDLE_TIMEOUT设置。默认30分钟可能不够。
3. 检查宿主机资源（CPU、内存）是否充足。Docker容器可能因资源不足而被OOM Killer终止。
解决：
- 对于已知的长任务，适当增加LEANCLAW_CONTAINER_TIMEOUT的值。
- 监控宿主机资源，必要时升级配置或优化任务。
- 考虑将大任务拆分为多个小任务。

问题3：消息路由未按预期工作，总是使用默认模型

现象：即使消息中包含配置的关键词，也没有被路由到指定的模型。
排查：
1. 确认配置文件~/.config/leanclaw/config.json的路径和格式正确。
2. 检查JSON语法，特别是逗号和括号。
3. 查看LeanClaw启动日志，确认配置文件是否被成功加载。
4. 最重要的一步：检查路由规则的顺序。LeanClaw是“首次匹配即胜出”。如果你的第一条规则是match: ["test"]，而第二条才是match: ["code"]，那么一条包含“test code”的消息会匹配第一条规则，而不是“code”规则。
解决：调整规则顺序，将最具体、最希望匹配的规则放在前面。可以使用更精确的关键词组合。

问题4：插件加载失败，功能不可用

现象：自定义插件没有被加载，相关技能或频道无法使用。
排查：
1. 确认LEANCLAW_PLUGIN_DIR环境变量指向了正确的插件父目录。
2. 检查插件目录中是否存在有效的leanclaw.plugin.json或openclaw.plugin.json文件。
3. 查看LeanClaw日志，通常会有详细的插件加载错误信息，如“Cannot find module”。
4. 确保插件的主文件（如dist/index.js）存在且可执行。如果是TypeScript插件，确认已编译。
解决：根据日志错误信息修复插件代码或配置。一个简单的调试方法是，在插件主文件开头加一句console.log，看是否执行。

问题5：令牌预算不准确或未生效

现象：设置了每日令牌限制，但似乎没有被计数或阻塞。
排查：
1. 确认使用的LLM供应商支持并正确配置了Token计数功能。LeanClaw的token-counter.ts模块可能依赖于供应商API返回的usage数据。
2. 检查数据库（默认为SQLite文件）中令牌计数表的数据是否在更新。
3. 令牌预算是基于“组”的。确认发送请求时指定的group参数与预算配置中的组名一致。
解决：查阅对应LLM供应商的API文档，确认其响应中是否包含usage字段。对于不支持Token计数的供应商（或某些特殊模型），此功能可能失效，需要回退到基于请求次数的简单限流。

经过以上步骤，你应该已经拥有了一个运行稳定、配置得当、安全可控的本地AI助手运行时。LeanClaw的魅力在于它在强大功能与简洁设计之间取得的平衡。它没有试图解决所有问题，而是通过清晰的边界和可扩展的架构，为你提供了一个构建专属AI自动化工作流的坚实基座。无论是用于个人效率提升，还是作为团队内部的生产力工具，它都值得你投入时间深入探索。