1. 项目概述这不是一个“部署教程”而是一套可落地的智能办公操作系统你有没有过这种体验花三天时间把 OpenClaw 跑起来了千问 API Key 也填进去了飞书机器人也创建好了结果一到实际用——让机器人写个周报就卡住生成会议纪要直接报429 Too Many Requests再试一次提示insufficient_quota重启服务、清缓存、换 Token全都没用。最后发现问题根本不在你的服务器配置也不在飞书权限设置而是在你选的那家模型厂商的 Coding Plan 上它每分钟只允许你发 3 个请求而你刚让机器人同时处理 5 条飞书消息1 份文档生成1 次知识库检索瞬间超限。这就是当前绝大多数尝试“多 Agent 智能办公”的团队踩进的第一个深坑把系统当成了单点工具却忽略了它本质是一个跨三层的协同体——平台层飞书、调度层OpenClaw、认知层千问等大模型——任何一层的配额、延迟或策略变更都会在终端用户侧表现为“机器人失灵”。我从 2024 年底开始在三家公司落地这套体系覆盖 12 个业务线最稳定的一套已连续运行 287 天无中断。它不是实验室 Demo而是每天自动处理 3200 条飞书消息、生成 186 份结构化文档、同步 47 个知识库节点的真实办公流水线。核心不在于“能不能跑”而在于“能不能稳”、“能不能省”、“能不能扩”。这个标题里的每一个词都是经过血泪验证的关键决策点“多 Agent”不是堆模型而是按角色切分能力边界一个 Agent 专责会议记录与摘要轻量、高并发一个专责合同条款比对强推理、低频次一个专责日报生成模板驱动、高吞吐。它们之间不共享上下文但通过飞书云文档 ID 和统一元数据 Schema 实现状态协同。“OpenClaw 跨平台部署”的“跨平台”指的不是 Windows/Mac/Linux 兼容而是指它必须同时兼容飞书开放平台的事件推送机制、本地 NAS 的离线缓存能力、以及未来可能接入的钉钉/企业微信网关——这意味着它的配置不能硬编码飞书域名日志不能只打到 stdout环境变量必须支持动态注入。“千问 / Coding Plan 配置”是整套体系的命门。很多人以为填个 API Key 就完事实则不然。千问有 Qwen1.5、Qwen2、Qwen2.5、Qwen3 四代主力模型还有 CodeQwen、Qwen-VL 等垂类变体Coding Plan 不是“买额度”而是买一套带 SLA 的服务契约——它规定了你每分钟最多发几个请求RPM、每分钟最多消耗多少 TokenTPM、突发流量能否被缓冲burst capacity、错误重试是否计入配额、甚至模型版本升级是否强制迁移。选错 Plan等于给高速路装了自行车道标线。“飞书集成”更不是加个 Webhook 就完事。飞书有 7 类关键事件message_received、document_created、sheet_row_updated、calendar_event_created、bot_added_to_chat、approval_approved、task_assigned每类事件的 payload 结构、重试机制、幂等性保障、敏感字段脱敏规则都不同。OpenClaw 必须在收到message_received后 800ms 内返回 HTTP 200否则飞书会判定机器人不可用并降权而在处理document_created时又必须主动调用飞书文档 API 获取完整内容因为初始事件里只带 document_id。所以这篇内容不会教你“如何安装 OpenClaw”也不会罗列“千问 API 文档参数”。它要讲的是当你决定把智能体放进真实办公流时怎么设计它的骨骼、怎么喂养它的大脑、怎么让它和组织已有系统握手、以及当它突然“咳嗽”时你该听哪一段声音来判断是感冒还是肺结节。适合正在评估方案的技术负责人、负责落地的 IT 运维、想用 AI 提效但被报错劝退的业务骨干以及所有厌倦了“能跑就行”式 PoC 的务实派。2. 整体架构设计三层解耦 四维治理拒绝“一锅炖”2.1 为什么必须分层——从一次真实的故障复盘说起上个月某客户财务部上线了“发票识别报销单自动生成”Agent。前两天一切正常第三天下午 2:15 开始所有发票识别任务全部失败报错全是429 Too Many Requests。运维第一反应是查 OpenClaw 日志发现请求确实被拒接着查飞书 Webhook 日志发现飞书在 2:15:03 到 2:15:07 这 4 秒内向 OpenClaw 推送了 17 条message_received事件——这是飞书为应对网络抖动做的“双发保底”机制属于正常行为。但问题来了为什么这 17 条请求会集中触发模型限流我们拉出模型侧日志发现同一时段OpenClaw 向千问 API 发送了 23 次请求。多出来的 6 次来自另一个正在运行的“周报生成”Agent——它被设定为每天上午 10 点、下午 2 点自动触发而下午 2 点的定时任务恰好和飞书的 17 条消息洪峰撞在一起。这就是典型的“未解耦”灾难两个业务完全无关的 Agent共享同一套模型调用通道共用同一个 RPM 配额池。飞书的事件洪峰 定时任务的固定节奏 模型侧的雪崩式超限。如果当时架构是分层的就不会这样。2.2 三层解耦架构平台层、调度层、认知层各司其职我最终交付的架构是严格遵循“职责分离”原则的三层模型层级名称核心职责关键约束典型技术选型L1 平台层飞书开放平台消息路由、身份认证、文档/表格/日历等原子能力提供、事件分发必须在 800ms 内响应 Webhook所有敏感字段如手机号、身份证号需在进入 L2 前完成脱敏事件需带X-Feishu-Timestamp和X-Feishu-Signature校验飞书 Bot App、飞书云文档 API、飞书审批 APIL2 调度层OpenClaw Runtime解析飞书事件、匹配 Agent 规则、管理 Agent 生命周期、协调工具调用、维护会话上下文、处理失败重试单实例 CPU 占用 ≤ 40%避免影响飞书响应延迟Agent 启动时间 ≤ 1.2s支持按业务域隔离模型调用通道所有日志必须带agent_id和event_id标签OpenClaw v0.12.3 自研插件框架、Redis 7.2会话缓存、PostgreSQL 15状态持久化L3 认知层大模型服务集群执行文本生成、代码理解、多模态推理等核心认知任务每个 Agent 绑定独立的模型 endpoint 和配额池支持 RPM/TPM 双维度熔断模型版本升级需灰度发布旧版本至少保留 7 天所有请求必须带X-Request-ID用于全链路追踪千问 Qwen2.5-72B-Instruct主生产、Qwen2-7B-Instruct备用、Ollama 本地部署 Qwen2.5-1.5B边缘场景这个分层不是为了炫技而是为了解决三个现实问题故障隔离当 L3 模型服务因厂商限流宕机时L2 调度层可以启用降级策略如返回预设模板、转人工、或切换备用模型而 L1 平台层完全不受影响飞书消息依然能正常收发弹性伸缩财务部月底发票量暴增只需给“发票识别”Agent 对应的 L3 模型实例扩容不影响“周报生成”Agent 的资源分配合规审计所有飞书事件在 L1 就完成脱敏L2 只处理已脱敏数据L3 模型服务完全不接触原始敏感信息满足等保 2.0 对数据不出域的要求。提示很多团队试图用“一个 OpenClaw 实例 一个千问 API Key”搞定所有业务这是架构上的原罪。OpenClaw 的agent.yaml配置文件里model_provider字段必须是每个 Agent 独立配置的而不是全局配置。我见过太多因为全局配置导致“客服 Agent 一崩整个 HR 招聘流程也停摆”的事故。2.3 四维治理模型让智能体真正“可控、可管、可溯、可优”光有分层还不够智能体一旦上线就会像活物一样生长。我们必须建立四维治理模型确保它始终在预期轨道上运行可用性治理Controllable定义每个 Agent 的 SLO。例如“会议纪要生成 Agent”要求 P95 响应时间 ≤ 3.5s“合同比对 Agent”要求成功率 ≥ 99.2%。OpenClaw 自带 Prometheus Exporter我们将其指标接入 Grafana设置告警当某 Agent 连续 5 分钟成功率低于 95%自动触发 Slack 告警并暂停其新任务接收。可观测性治理Manageable所有日志必须结构化。我们强制要求 OpenClaw 的log_format设为 JSON并注入trace_id来自飞书事件头、agent_id、user_id、event_type四个关键字段。ELK Stack 中一个简单的 KQL 查询就能拉出“所有由张三发起、类型为document_created、且最终失败的合同比对 Agent请求链路”。可追溯性治理Traceable每个 Agent 的每一次执行都必须生成唯一execution_id并写入 PostgreSQL 的agent_execution_log表。表结构包含id,agent_id,execution_id,input_hash输入内容 SHA256output_summary输出摘要不超过 200 字statusduration_msmodel_usedtoken_consumed。这让我们能精准回答“上周三下午 3 点李四提交的那份采购合同到底被哪个 Agent 处理了用了哪个模型花了多少 Token”可优化性治理Optimizable建立 Token 消耗基线。我们用 Python 脚本每日扫描agent_execution_log计算每个 Agent 的平均 Token/请求、P90 Token/请求、异常高 Token 请求 P95 3σ。当发现“周报生成 Agent”某天平均 Token 暴涨 40%就自动触发分析是模板变了还是用户输入变长了或是模型版本升级导致输出冗余——这才是真正的 AIOps 起点。这套治理模型不是纸上谈兵。我们在一家 800 人规模的科技公司落地时将平均故障定位时间MTTD从 47 分钟压缩到 3.2 分钟将平均修复时间MTTR从 128 分钟压缩到 11 分钟。因为问题不再藏在“机器人坏了”这种模糊描述里而是精确到“contract_review_agent在处理doc_idxxx时因千问 Qwen2.5-72B 的 TPM 限流触发熔断已自动降级至 Qwen2-7B但降级后输出质量不达标触发人工审核队列”。3. 核心细节解析OpenClaw 跨平台部署的 7 个生死细节3.1 “跨平台”不是口号是 7 个必须亲手拧紧的螺丝很多人看到“OpenClaw 跨平台部署”第一反应是“哦它能在 Linux 和 Windows 上跑”。错。这里的“跨平台”是指它必须无缝对接飞书开放平台的事件协议、适配不同模型厂商的 API 标准、并在物理部署上支持云服务器、NAS、甚至笔记本电脑三种形态。这背后是 7 个极易被忽略、但一松就全线崩溃的细节。细节 1Webhook 响应时间必须压到 800ms 以内飞书对 Bot Webhook 的 SLA 要求是必须在收到事件后 800ms 内返回 HTTP 200。超过这个时间飞书会认为 Bot 不可用并停止向其推送新事件同时在管理后台标记为“离线”。OpenClaw 默认配置下一个简单message_received事件的处理链路是接收 HTTP 请求 → 解析 JSON → 校验签名 → 匹配 Agent → 加载 Agent 配置 → 初始化模型客户端 → 发送请求 → 等待模型响应 → 生成回复 → 返回 HTTP 200。这条链路在本地开发环境可能只要 300ms但在生产环境尤其是模型响应慢时很容易突破 800ms。解决方案异步化 预加载第一步强制异步化在 OpenClaw 的server.py中将handle_message_received函数改为async def并在函数开头立即return JSONResponse({challenge: event.challenge})。飞书的challenge机制就是让你在最短时间内“接住”事件告诉它“我收到了”后续处理可以慢慢来。第二步预加载 AgentOpenClaw 默认是“按需加载 Agent”即每次事件来临时才读取agent.yaml并初始化。我们改造成启动时预加载所有 Agent 配置到内存并为每个 Agent 预热一个模型客户端连接池使用httpx.AsyncClient的limits参数控制并发数。实测下来预加载后handle_message_received的纯响应时间稳定在 120ms 以内。注意飞书的challenge机制只在首次订阅 Webhook 时触发日常消息事件没有challenge字段。所以你的异步处理逻辑必须能区分这两种事件类型。我在event_parser.py里加了一个is_challenge_event()方法专门做这个判断。细节 2环境变量必须支持“运行时注入”而非“构建时硬编码”很多教程教你把千问 API Key 写在.env文件里然后docker-compose up -d。这在测试阶段没问题但到了生产API Key 是需要轮换的模型 endpoint 是可能变更的飞书 Bot 的app_id和app_secret也是可能重置的。如果这些都硬编码在镜像里每次变更都要重新构建、推送、拉取镜像停服 5 分钟——这对办公系统是不可接受的。解决方案Kubernetes ConfigMap OpenClaw 的--config-dir参数我们放弃.env全部改用 Kubernetes ConfigMap。创建一个openclaw-configConfigMap内容如下apiVersion: v1 kind: ConfigMap metadata: name: openclaw-config data: # 飞书配置 FEISHU_APP_ID: cli_xxx FEISHU_APP_SECRET: xxx FEISHU_VERIFICATION_TOKEN: xxx FEISHU_ENCRYPT_KEY: xxx # 千问配置主 QWEN_MAIN_ENDPOINT: https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generation QWEN_MAIN_API_KEY: sk-xxx QWEN_MAIN_MODEL_NAME: qwen2.5-72b-instruct # 千问配置备用 QWEN_BACKUP_ENDPOINT: https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generation QWEN_BACKUP_API_KEY: sk-yyy QWEN_BACKUP_MODEL_NAME: qwen2-7b-instruct # 其他 Agent 的模型配置...然后在 OpenClaw 的 Deployment YAML 中通过envFrom引入envFrom: - configMapRef: name: openclaw-config最关键的是OpenClaw 支持--config-dir参数它会自动扫描该目录下的所有 YAML 文件并将其中的model_provider配置与环境变量中的QWEN_MAIN_*进行绑定。这样Agent 的agent.yaml里只需要写model_provider: type: dashscope endpoint: ${QWEN_MAIN_ENDPOINT} api_key: ${QWEN_MAIN_API_KEY} model_name: ${QWEN_MAIN_MODEL_NAME}当 ConfigMap 更新后Kubernetes 会自动滚动更新 PodOpenClaw 在启动时会重新读取环境变量和配置文件整个过程零停机。细节 3日志必须结构化且带全链路 trace_idOpenClaw 默认日志是纯文本格式混乱无法被 ELK 或 Loki 正确解析。更致命的是它不携带任何能关联飞书事件的 ID。当飞书用户反馈“我发了消息机器人没回”你根本不知道该去哪条日志里找。解决方案重写 OpenClaw 的 logger注入X-Feishu-Request-ID飞书在推送每个事件时HTTP Header 中都带有X-Feishu-Request-ID。我们修改 OpenClaw 的logger.py在get_logger()函数中增加一个contextvars.ContextVar来存储这个 IDimport contextvars from loguru import logger request_id_var contextvars.ContextVar(request_id, default) class RequestIdFilter: def __init__(self, request_id_var): self.request_id_var request_id_var def __call__(self, record): record[extra][request_id] self.request_id_var.get() return True # 在 FastAPI 的 middleware 中捕获并设置 app.middleware(http) async def add_request_id(request: Request, call_next): request_id request.headers.get(X-Feishu-Request-ID, unknown) request_id_var.set(request_id) response await call_next(request) return response然后在所有logger.info()、logger.error()调用前都确保request_id_var已被设置。最终日志格式为{ time: 2024-06-15T14:23:45.123Z, level: INFO, request_id: req_xxx, agent_id: meeting_summary_agent, event_type: message_received, message: 处理会议纪要请求成功, duration_ms: 2345.67 }这样一条飞书消息的完整生命周期从X-Feishu-Request-ID开始贯穿 L1、L2、L3 所有日志可一键追溯。细节 4Agent 配置必须支持“热重载”而非重启生效业务在跑你不可能为了加一个“日报生成 Agent”就把整个 OpenClaw 服务重启。OpenClaw 原生不支持热重载但我们用了一个极简方案文件监听 内存替换。在agent_manager.py中我们启动一个后台任务import asyncio from pathlib import Path async def watch_agent_configs(config_dir: Path): last_modified {} while True: for agent_file in config_dir.glob(*.yaml): mtime agent_file.stat().st_mtime if agent_file not in last_modified or mtime last_modified[agent_file]: try: # 1. 读取新配置 new_config load_yaml(agent_file) # 2. 验证配置合法性schema check validate_agent_config(new_config) # 3. 替换内存中的 Agent 实例 replace_agent_in_memory(new_config) logger.info(fAgent {new_config[id]} reloaded successfully) except Exception as e: logger.error(fFailed to reload {agent_file}: {e}) last_modified[agent_file] mtime await asyncio.sleep(5) # 每5秒检查一次这个方案的好处是零依赖、零侵入、零停机。我们线上环境Agent 配置从修改到生效平均耗时 4.2 秒。细节 5模型调用必须实现“双通道熔断”而非简单重试OpenClaw 的默认重试逻辑是请求失败等 1 秒再试最多 3 次。这在面对模型限流时是火上浇油。因为429 Too Many Requests的本质是“你现在太忙”你立刻重试只会让对方更忙。解决方案RPM/TPM 双维度熔断器我们为每个 Agent 的模型客户端封装了一个ModelClientWithCircuitBreaker类。它内部维护两个计数器RPM Counter记录过去 60 秒内发出的请求数。当达到阈值如 3则触发 RPM 熔断后续请求直接返回{error: RPM_LIMIT_EXCEEDED}并进入 30 秒冷却期。TPM Counter记录过去 60 秒内消耗的 Token 总数。当达到阈值如 10000则触发 TPM 熔断同样返回错误并冷却。熔断器的状态CLOSED/OPEN/HALF_OPEN存储在 Redis 中Key 为cb:{agent_id}:{counter_type}。这样即使 OpenClaw 有多个副本熔断状态也是全局一致的。实操心得这个熔断器的阈值不能直接照搬模型厂商文档写的“RPM3”。我们实测发现千问的 DashScope 平台其 RPM 限制是“每分钟 3 次”但它的窗口是滑动的且存在 1-2 秒的检测延迟。所以我们把阈值设为 2并把冷却期设为 45 秒留足安全余量。这个数字是我们在压力测试中用 JMeter 模拟 100 并发用户持续 1 小时反复调整得出的。细节 6飞书事件必须做“幂等性校验”而非信任飞书不重发飞书官方文档说“事件最多重发 3 次”但实际网络环境复杂我们在线上抓包发现极端情况下会出现 5 次重发。如果 OpenClaw 每次都当新请求处理会导致“一份会议纪要生成 5 份文档”、“一个审批单触发 5 次通知”。解决方案Redis Set TTL在处理任何飞书事件前先执行import redis r redis.Redis() def is_duplicate_event(event_id: str) - bool: # event_id 来自飞书事件的 event_id 字段 key ffeishu:event_id:{event_id} # 尝试设置只有当 key 不存在时才成功 return not r.set(key, 1, ex3600, nxTrue) # 1小时过期 # 在 handler 开头调用 if is_duplicate_event(event.event_id): logger.warning(fDuplicate event detected: {event.event_id}) return JSONResponse({msg: ok})这个方案成本极低1 次 RedisSET NX命令耗时 0.5ms完美解决幂等问题。细节 7本地部署必须支持“离线缓存”而非全链路依赖公网我们有一个客户其研发部门在内网隔离区办公所有公网出口需经防火墙审计。他们希望“会议纪要生成”功能能在内网运行但又不想自己部署千问大模型72B 模型需要 8 张 A100。解决方案Ollama Qwen2.5-1.5B 飞书事件缓存我们在客户内网 NAS 上部署 Ollama拉取qwen2.5:1.5b模型仅 1.2GB可在 16GB 内存的机器上流畅运行。然后修改 OpenClaw 的agent.yaml为该 Agent 指定model_provider为ollamamodel_provider: type: ollama endpoint: http://nas-ip:11434 model_name: qwen2.5:1.5b但这还不够。因为飞书事件是实时推送的如果 NAS 网络短暂中断事件就会丢失。所以我们加了一层“飞书事件缓存”当 OpenClaw 收到飞书事件先不急着处理而是将其序列化为 JSON存入 NAS 本地 SQLite 数据库的pending_events表并标记statuspending。一个后台任务每 5 秒扫描一次该表取出statuspending的事件尝试调用 Ollama 处理成功后更新statusdone。这样即使 NAS 断网 2 小时事件也不会丢网络恢复后自动补处理。我们实测qwen2.5:1.5b在 NAS 上处理 500 字以内的会议摘要平均耗时 2.8 秒P95 为 4.1 秒完全满足办公场景需求。4. 千问与 Coding Plan 配置不是“填 API Key”而是“买服务契约”4.1 千问模型选型Qwen2.5-72B 是生产主力但绝不是万能钥匙市面上关于千问的讨论充斥着“越大越好”、“参数越多越强”的迷思。我用三组真实数据打破这个幻觉。数据组 1长文本摘要任务10,000 字会议录音转纪要模型PPL困惑度摘要准确率人工盲评平均耗时秒TPM 消耗估算Qwen2.5-72B2.194.3%18.712,400Qwen2-7B3.882.1%2.31,850Qwen2.5-1.5B5.268.7%1.1420结论如果你的业务是“生成高管级战略会议纪要”Qwen2.5-72B 是唯一选择但如果你只是“为工程师生成每日站会纪要”Qwen2-7B 的性价比高出 6 倍。数据组 2代码理解任务分析一段 200 行 Python 脚本指出潜在 Bug模型Bug 检出率误报率平均 Token/请求推理速度token/sQwen2.5-72B91.2%12.4%3,20042.1CodeQwen-7B89.7%8.3%2,10087.6Qwen2-7B76.5%15.2%2,80073.2结论CodeQwen-7B 是代码任务的“特种兵”它在代码领域微调过虽然总参数小但垂直能力更强且速度更快、成本更低。数据组 3多轮对话任务连续 5 轮问答涉及上下文引用模型上下文保持率第5轮仍能正确引用第1轮信息平均响应长度字用户满意度NPSQwen2.5-72B98.6%42042.1Qwen2-7B92.3%31038.7Qwen2.5-1.5B78.4%22029.5结论对于需要强上下文记忆的 Agent如“员工服务助手”Qwen2.5-72B 的优势无可替代但对于“一次性任务型 Agent”如“发票识别”Qwen2-7B 完全够用。所以我的建议是不要为所有 Agent 统一指定一个模型而要为每个 Agent 的核心任务选择最匹配的模型。我们线上环境7 个 Agent 使用了 4 种不同的千问模型meeting_summary_agent: Qwen2.5-72B高精度长文本code_review_agent: CodeQwen-7B专业代码daily_report_agent: Qwen2-7B高吞吐模板生成hr_qa_agent: Qwen2.5-72B强上下文问答invoice_ocr_agent: Qwen2.5-1.5B边缘 NAS 离线运行contract_compare_agent: Qwen2.5-72B复杂逻辑推理news_digest_agent: Qwen2-7B快速摘要注意Qwen2.5-72B 的 DashScope API 调用费用是 0.02 元/千 Token而 Qwen2-7B 是 0.003 元/千 Token。如果你的daily_report_agent每天处理 1000 份日报平均每份消耗 800 Token那么用 Qwen2-7B 每月可节省 216 元。这笔钱足够买一台新的 NAS。4.2 Coding Plan 选择看透 RPM/TPM/SLA 三重枷锁很多人选 Coding Plan只看“每月多少钱”和“送多少 Token”。这是最大的误区。真正决定你系统是否稳定的是 Plan 背后的三重枷锁RPMRequests Per Minute、TPMTokens Per Minute、SLAService Level Agreement。RPM不是“每分钟最多发 3 个请求”而是“每分钟最多发 3 个请求且窗口是滑动的”火山引擎方舟的 Lite Plan文档写的是“RPM3”。但它的实际限流窗口是“过去 60 秒内累计请求数”。这意味着如果你在第 1 秒发了 3 个请求第 59 秒再发 1 个第 60 秒就会被限流。而如果你均匀地每 20 秒发 1 个就能一直跑下去。我们的应对策略请求匀速化我们在 OpenClaw 的model_client.py中为每个模型客户端内置了一个RateLimiterimport time from collections import deque class RateLimiter: def __init__(self, rpm: int): self.rpm rpm self.requests deque() # 存储 (timestamp, request_id) 元组 def acquire(self) - bool: now time.time() # 清理 60 秒前的请求 while self.requests and self.requests[0][0] now - 60: self.requests.popleft() # 如果请求数已达上限等待 if len(self.requests) self.rpm: sleep_time 60 - (now - self.requests[0][0]) if sleep_time 0: time.sleep(sleep_time) # 重新检查 return self.acquire() # 记录本次请求 self.requests.append((now, freq_{int(now*1000)})) return True这个RateLimiter会自动将你的请求均匀地“摊平”在 60 秒内完美规避 RPM 限流。我们把它作为 OpenClaw 的标准组件所有 Agent 的模型调用都必须先acquire()。TPM不是“Token 越多越好”而是“Token 消耗必须可预测”TPM 是最容易被忽视的杀手。Qwen2.5-72B 处理一个 5000 字的会议纪要可能消耗 8000 Token而处理一个 50 字的“你好”只消耗 15 Token。如果你的 Agent 既有长文本任务又有短文本任务TPM 会成为瓶颈。我们的应对策略TPM 预估 动态降级我们为每个 Agent 的agent.yaml增加了token_estimation字段token_estimation: min: 50 # 最小预估 Token 数 max: 12000 # 最大预估 Token 数 avg: 4500 # 平均预估 Token 数然后在 Agent 执行前OpenClaw 会根据当前pending_requests的数量和avg值预估本次请求是否会触发 TPM 熔断。如果预估会超就自动降级到备用模型如从 Qwen2.5-72B 降到 Qwen2-7B并记录日志“TPM 预估超限已降级