> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/openclaw_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/openclaw_guide/di-si-bu-fen-shi-zhan-yu-you-hua-shen-du-zhi-nan/14_performance_cost/14.2_latency_throughput.md).

# 14.2 延迟与吞吐优化

本节从**形式化的延迟模型**与**成本模型**出发，帮你理解 OpenClaw 系统的性能瓶颈与优化杠杆。与其凭感觉调参，不如先建立清晰的模型，再精准优化。

首先，一次完整的 Agent 请求处理延迟可以分解为四个不可约的部分：

```
总延迟 (E2E) = LLM 推理延迟 + 工具 I/O 延迟 + 沙箱执行延迟 + 编排器开销
```

## 14.2.1 形式化延迟模型

下面对每个延迟分量逐一拆解。

### 1. LLM 推理延迟（$T\_{llm}$）

$$T\_{llm} = T\_{ttft} + T\_{tokens} \times k$$

其中：

* $T\_{ttft}$：首 Token 时间（Time To First Token）。通常 30-150ms，取决于模型与供应商
* $T\_{tokens}$：平均每个 Token 的生成时间。通常 20-50ms
* $k$：输出 Token 数量

**优化杠杆**：

* 选择低延迟模型（如 Claude Haiku 4.5 的 $T\_{ttft}$ 显著低于 Claude Opus 4.6）
* 减少输出 Token（通过系统提示精简指令、使用结构化输出限制长度）
* 启用流式返回，让用户看到“正在思考”的反馈，而不是死等

### 2. 工具 I/O 延迟（$T\_{tool}$）

串行工具调用的耗时可近似为：

$$T\_{tool,serial} = \sum\_{i=1}^{n} (T\_{latency\_i} + T\_{processing\_i})$$

并行工具调用更接近关键路径上最慢的工具加协调开销：

$$T\_{tool,parallel} = \max\_i(T\_{latency\_i} + T\_{processing\_i}) + T\_{coordination}$$

其中：

* $T\_{latency\_i}$：第 i 个工具的网络往返延迟（通常 10-500ms）
* $T\_{processing\_i}$：该工具的处理时间（取决于工具本身）
* $n$：工具调用数量，是否并行取决于模型计划、工具依赖和运行时调度

**关键优化**：

* **并行化**：如果多个任务互不依赖，优先使用 `sessions_spawn` / 后台任务做并行，或通过 Gateway 队列并发配置（如 `agents.defaults.maxConcurrent`）控制整体并发，而不是假设存在统一的 `tools.parallel.max_concurrent`
* **缓存**：对同一查询的重复工具调用，缓存结果以避免重复延迟
* **超时与降级**：按具体层面设置超时，例如 agent 级 `agents.defaults.timeoutSeconds`、cron job 的 `timeoutSeconds`、插件自身 timeout 或单次工具调用参数；超时则返回预设回答而不是无限等待

并行调用可将串行 800ms 降至 500ms（37.5% 提升）。

### 3. 沙箱执行延迟（$T\_{sandbox}$）

$$T\_{sandbox} = T\_{startup} + T\_{execution} + T\_{teardown}$$

其中：

* $T\_{startup}$：启动沙箱容器（通常 100-500ms）
* $T\_{execution}$：运行用户代码的实际时间
* $T\_{teardown}$：清理与销毁沙箱

**优化策略**：

* **沙箱复用**：对同一 Agent 的多次执行，复用沙箱实例而不是每次新建（可省 200-300ms）
* **预热**：在空闲时提前启动常用沙箱，降低 $T\_{startup}$
* **镜像优化**：使用最小镜像减少启动时间

### 4. 编排器开销（$T\_{orchestrator}$）

$$T\_{orchestrator} = T\_{queue} + T\_{dispatch} + T\_{serialization} + T\_{context\_loading}$$

其中：

* $T\_{queue}$：请求在队列中的等待时间（取决于并发度）
* $T\_{dispatch}$：将请求路由到目标 Agent 的时间（通常 1-5ms）
* $T\_{serialization}$：序列化上下文、提示词的时间
* $T\_{context\_loading}$：从存储加载会话上下文的时间

**优化杠杆**：

* **减少上下文加载**：通过 `contextPruning` 和 `compaction` 减少加载数据量
* **异步调度**：对非关键路径使用异步调度，不阻塞主路径
* **预缓存**：将热点会话的上下文预加载到内存

## 14.2.2 多智能体场景的延迟累积

$$T\_{total} = \sum\_{i=1}^{N} T\_{base\_i} + T\_{routing} + T\_{context\_transfer}$$

**关键观察**：

* 每多一个 Agent 跳转，就新增 10-50ms 的上下文转移与路由开销
* 深层编排（如 Agent A → Agent B → Agent C → Agent D）可能比单 Agent 方案慢 50-200ms
* **优化建议**：倾向于宽而浅的编排（并行 Agent）而不是深而窄的串联

## 14.2.3 结构化成本模型

```
单次请求总成本 = LLM 成本 + 工具成本 + 存储成本 + 基础设施成本
```

### 1. LLM 成本（$C\_{llm}$）

$$C\_{llm} = n\_{input} \times P\_{input} + n\_{output} \times P\_{output}$$

若需要折算为本地币种，再把上式得到的美元成本乘以对应汇率。

**例子**（Claude Sonnet 4.6，2026 年 4 月价格快照；2026-05-16 后请以 Anthropic 官方 Pricing 页复核）：

* 输入 Token：$3/1M
* 输出 Token：$15/1M
* 假设平均 2000 输入 + 500 输出 Token

$$C\_{llm} = (2000 \times 0.000003 + 500 \times 0.000015) = 0.006 + 0.0075 = $0.0135 \text{ per request}$$

> **关于 Claude Opus 4.7 的成本估算**：如果使用 Opus 4.7（[Anthropic 发布说明](https://www.anthropic.com/news/claude-opus-4-7)中的 $5/$25/1M 价格），同样 2000 输入 + 500 输出 token 的基础成本为 `2000 × 0.000005 + 500 × 0.000025 = $0.0225`。若新 tokenizer 让输入 token 最多增加 35%，则约为 `$0.026`，还未计入 Adaptive Thinking 产生的额外思考 token。该段是估算模板，模型能力、价格与折扣应按当前官方 Pricing 页复核。

**优化杠杆**：

* 选择更便宜的模型用于低复杂度任务（如 Haiku 而不是 Sonnet）
* 减少每个请求的输入 Token（精简系统提示、压缩上下文）
* 批处理请求以摊销上下文成本

### 2. 工具成本（$C\_{tool}$）

$$C\_{tool} = \sum\_{i=1}^{n} (\text{API 单价}\_i \times \text{调用次数}\_i + \text{数据量}\_i \times \text{单价}\_i)$$

**例子**：

* Google Search API：$5 per 1000 queries
* PostgreSQL 读：$0.25 per million requests
* S3 读取：$0.0004 per 10K requests

**优化**：

* 缓存热点数据
* 用 GraphQL 替代 REST API 减少往返
* 优化查询计划减少数据扫描

### 3. 存储成本（$C\_{storage}$）

$$C\_{storage} = \text{活跃会话数} \times \text{平均状态大小} \times \text{存储单价} + \text{审计日志大小} \times \text{单价}$$

**优化**：

* 使用 `agents.defaults.compaction` 减少发送给模型的上下文体积；如需控制活跃 transcript 大小，再配置 `truncateAfterCompaction` 与 `maxActiveTranscriptBytes`
* 定期清理过期会话
* 用冷存储（Glacier）存档旧日志

### 4. 基础设施成本（$C\_{infra}$）

编排器、网关、计算资源的运行成本。

| 规模                   | 模式              |
| -------------------- | --------------- |
| 小规模（<100 req/day）    | 云 SaaS，按调用付费    |
| 中规模（100-10K req/day） | 自托管 + 预留实例      |
| 大规模（>10K req/day）    | 专用基础设施 + 成本优化合同 |

## 14.2.4 实战成本分析示例

假设运营一个企业级客服 Agent：

* 日均 5000 条消息（月均 15 万条）
* 平均每条消息 2000 输入 + 500 输出 Token（沿用 14.2.2 的假设）
* 平均 2 个工具调用/消息
* 会话保留 30 天
* 使用 Claude Sonnet 4.6

**月成本分解**：

| 维度                 | 单价        | 数量          | 月成本          |
| ------------------ | --------- | ----------- | ------------ |
| LLM（输入）            | $3/1M     | 300M tokens | $900         |
| LLM（输出）            | $15/1M    | 75M tokens  | $1125        |
| API 调用             | $5/1000   | 300K calls  | $1500        |
| 存储（状态）             | $0.023/GB | 75GB        | $1.7         |
| 计算（t3.xlarge 2 实例） | $0.1664/h | 1460 h      | $243         |
| **总计**             |           |             | **$3769.70** |

**优化方案**：

1. 对简单问题（80%）用 Haiku（按输入/输出单价分别粗算）→ 约省 $1080
2. 启用 `agents.defaults.compaction`（减少活跃上下文体积）→ 省 $120
3. 实施工具缓存（减少 API 调用 40%）→ 省 $600
4. 优化实例规格（用 t3.small 2 实例替代 t3.xlarge）→ 约省 $212.6

**优化后月成本**：约 $1757（比优化前降低约 53%）

## 14.2.5 性能与成本的取舍

在实际优化中，常常面临**性能 vs 成本**的权衡：

| 优化方向     | 性能影响   | 成本影响 | 建议场景             |
| -------- | ------ | ---- | ---------------- |
| 使用更快的模型  | ↑ 快    | ↑ 贵  | 延迟敏感（客服、实时对话）    |
| 使用更便宜的模型 | ↓ 慢    | ↓ 便宜 | 非实时任务（数据处理、异步任务） |
| 启用并行工具   | ↑ 快    | ↔ 不变 | 总是推荐             |
| 压缩上下文    | ↓ 略慢\* | ↓ 便宜 | 长会话应用            |
| 启用缓存     | ↑ 快    | ↓ 便宜 | Win-win          |

\*压缩上下文可能导致回答质量下降 1-5%，需 A/B 测试验证。

## 14.2.6 性能诊断工具链

OpenClaw 提供多种内置工具帮助你诊断瓶颈：

**1. 打开工具与插件 trace**

```bash
/trace on
```

开启后，相关工具与插件诊断会进入当前会话和结构化日志。可用日志流回放具体请求链路：

```bash
openclaw logs --follow --json
```

示意性分析输出：

```
[0ms]     请求到达
[2ms]     认证与路由
[150ms]   LLM 推理开始
[2850ms]  LLM 返回（工具调用决定）
[2860ms]  API 调用开始
[3200ms]  API 返回（340ms I/O）
[4050ms]  LLM 再次推理开始
[5100ms]  最终回答返回（1050ms 推理）
---
总耗时：5100ms；其中 LLM 推理约 3750ms，工具 I/O 约 340ms，编排与等待间隙约 1010ms，主要瓶颈仍在模型推理。
分解：LLM 3.75s + 工具 0.34s + 编排/等待 1.01s = 5.10s
瓶颈：LLM 推理占约 74%
```