Coze 如何降低成本｜附完整命令

Coze（扣子）是一个非常适合快速搭建 AI Bot、工作流、知识库问答和自动化应用的平台。它的优势是上手快、集成能力强、适合产品原型和业务场景落地。但当 Bot 从“测试阶段”进入“真实业务使用阶段”后，很多团队会遇到一个共同问题：成本增长速度远快于预期。

尤其是以下几类场景：

• 用户量增长后，对话次数持续增加；
• Bot 每轮都调用大模型，且上下文很长；
• 知识库检索返回内容过多，导致 token 消耗高；
• 工作流中多个节点重复调用模型；
• 没有缓存，相同问题被反复请求；
• 使用高规格模型处理所有任务，没有做模型分层；
• 日志、监控和成本统计不清晰，无法定位浪费点。

本文将从产品设计、Prompt 优化、知识库配置、工作流结构、模型路由、缓存网关、限流监控等多个角度，系统讲解 Coze 如何降低成本，并附上可直接使用的完整命令，帮助你搭建一个更可控、更低成本的 AI 应用体系。

一、先理解 Coze 成本主要花在哪里

在优化之前，需要先明确成本来源。Coze 相关成本通常来自以下几部分：

1. 大模型调用成本

这是最主要的成本来源。

大模型成本通常与以下因素有关：

• 输入 token 数量；
• 输出 token 数量；
• 模型单价；
• 调用次数；
• 是否启用长上下文；
• 是否重复调用模型。

例如一个 Bot 每轮对话都携带大量历史消息、知识库内容和系统 Prompt，就会导致每次请求输入 token 很高。

如果用户问一个简单问题，却调用了高规格模型，也会造成明显浪费。

2. 知识库检索成本

知识库问答通常包括：

1. 用户问题改写；
2. 向量检索；
3. 召回多个文档片段；
4. 将片段拼接进 Prompt；
5. 调用大模型生成回答。

如果知识库切片过大、召回数量过多、相似度阈值过低，就会把大量无关内容塞进上下文。

结果是：

• 回答质量未必提升；
• 输入 token 明显增加；
• 响应速度变慢；
• 成本持续上升。

3. 工作流节点成本

很多人在 Coze 工作流中会设计多个 LLM 节点，例如：

• 一个节点做意图识别；
• 一个节点做信息抽取；
• 一个节点做知识库问答；
• 一个节点做文案润色；
• 一个节点做总结输出。

如果每个节点都调用大模型，而且都使用高规格模型，那么一次用户请求可能会触发 3 到 5 次模型调用。

这类成本往往不容易被发现，因为用户看起来只问了一次，但后台已经调用了很多次模型。

4. 重复问题成本

很多业务场景中，用户问题高度重复，例如：

• “怎么退款？”
• “怎么开票？”
• “物流多久发货？”
• “课程在哪里看？”
• “账号登录不了怎么办？”

如果没有缓存机制，这些问题每次都重新进入模型推理，就会浪费大量成本。

对于标准问答、客服 FAQ、售后政策、固定流程说明等场景，缓存可以显著降低成本。

二、第一步：减少无效 token

降低 Coze 成本最直接的方法，就是减少无效 token。

1. 精简系统 Prompt

很多 Bot 的系统 Prompt 写得很长，包含大量重复描述，例如：

你是一个专业、耐心、友好、严谨、认真、细致、善于沟通的客服助手……

这些形容词并不会显著提升效果，却会在每次调用中重复消耗 token。

建议将系统 Prompt 改成结构化版本：

你是某品牌客服助手。
目标：根据用户问题提供准确、简洁、可执行的回答。
规则：
1. 优先根据知识库回答；
2. 不确定时说明无法确认，不编造；
3. 回答不超过 300 字；
4. 涉及售后、退款、发票问题时，按流程说明。

这样既清晰，又节省 token。

2. 限制输出长度

很多成本并不只来自输入，也来自输出。

如果没有限制，模型可能生成很长的回答。对于客服、FAQ、工具助手类 Bot，大多数回答不需要太长。

建议在 Prompt 中明确规定：

回答要求：
- 默认不超过 300 字；
- 使用分点说明；
- 如果用户没有要求详细解释，不展开背景知识；
- 不输出与问题无关的内容。

如果是工作流中的中间节点，更要严格限制输出格式，例如：

只输出 JSON，不要解释，不要 Markdown，不要额外文本。

示例：

{
  "intent": "refund",
  "confidence": 0.92
}

这样可以减少输出 token，也方便后续节点解析。

3. 减少历史上下文

Coze Bot 在多轮对话中可能会携带历史记录。历史越长，输入 token 越高。

建议：

• 只保留最近 3 到 5 轮关键对话；
• 对长期上下文做摘要；
• 不要把完整聊天记录全部传入模型；
• 对无状态 FAQ 类 Bot，尽量减少上下文依赖。

可以设计一个“会话摘要”字段，只保存用户需求、关键参数和未完成任务。

示例：

会话摘要：
用户想申请退款，订单号为 20240501001，商品已签收，正在确认是否符合七天无理由。

比起携带几十轮历史消息，这种方式成本低很多。

三、第二步：优化知识库配置

知识库是 Coze 应用中非常常见的能力，但也是 token 浪费的高发区。

1. 控制文档切片大小

如果切片太大，每次检索都会带入大量内容；如果切片太小，语义不完整，回答质量下降。

一般建议：

• FAQ 类知识库：每个问题和答案作为一个片段；
• 政策说明类文档：每段 300 到 600 中文字；
• 技术文档类：按标题层级切分；
• 不建议整篇文档作为一个片段。

错误示例：

把一整份 8000 字的售后政策作为一个知识片段。

优化示例：

1. 退款条件
2. 退款时效
3. 运费承担规则
4. 特殊商品说明
5. 发票处理方式

每个片段独立、清楚、可检索。

2. 减少召回数量

如果每次知识库检索返回 8 到 10 个片段，输入 token 会快速增加。

建议根据场景设置：

多数客服场景中，召回 2 到 3 个高相关片段已经足够。

3. 提高相似度阈值

相似度阈值过低，会召回大量不相关内容。模型看到无关知识后，不仅成本变高，还容易答偏。

建议：

• 初始阈值设置为 0.65 到 0.75；
• 观察命中效果后再调整；
• 对 FAQ 类知识库可以设置更高阈值；
• 对开放式文档问答可以适当降低。

4. 知识库内容要“短、准、结构化”

知识库不是资料仓库，不是把所有文档原样塞进去就好。

高质量知识片段应该具备：

• 标题明确；
• 内容短小；
• 一个片段只讲一个主题；
• 尽量使用问答格式；
• 删除广告语、寒暄语、重复说明；
• 删除对回答无帮助的背景介绍。

示例：

标题：退款多久到账？

内容：
退款审核通过后，原路退回支付账户。
通常到账时间：
1. 微信支付：1-3 个工作日；
2. 支付宝：1-3 个工作日；
3. 银行卡：3-7 个工作日。
如超过 7 个工作日未到账，请联系人工客服。

这种内容对模型友好，对检索友好，也更省 token。

四、第三步：工作流节点降本

Coze 工作流非常强大，但如果节点设计不合理，成本会被放大。

1. 能用规则判断，就不要用大模型

例如判断用户是否输入了订单号，不需要调用大模型，可以用正则。

订单号识别示例：

\d{8,20}

手机号识别示例：

1[3-9]\d{9}

邮箱识别示例：

[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}

这些判断用代码、条件节点或正则即可完成，不必交给 LLM。

2. 意图识别尽量轻量化

如果只是判断用户属于哪类问题，可以使用较低成本模型，或者用关键词规则先过滤。

示例：

退款、退货、不要了、不想要 → refund
发票、抬头、税号、开票 → invoice
物流、快递、发货、单号 → logistics
登录、密码、验证码、账号 → account

只有规则无法判断时，再调用模型做意图识别。

3. 合并不必要的 LLM 节点

有些工作流会这样设计：

1. 第一个 LLM 节点总结问题；
2. 第二个 LLM 节点判断意图；
3. 第三个 LLM 节点生成回答；
4. 第四个 LLM 节点润色语气。

这会产生多次模型调用。

很多情况下可以合并为一个节点：

请完成以下任务：
1. 判断用户意图；
2. 根据知识库内容回答；
3. 如果无法回答，返回转人工建议；
4. 输出简洁自然的中文。

节点越少，成本越低，延迟也越低。

五、第四步：搭建缓存网关降低重复调用成本

如果你的 Coze 应用会调用外部接口、私有模型、OpenAI 兼容模型或自建中间层，可以在 Coze 和模型之间增加一层 LLM 网关。

它可以实现：

• 相同问题直接返回缓存；
• 统一记录 token 用量；
• 根据任务选择不同模型；
• 设置限流；
• 控制最大输出长度；
• 分析高成本请求。

下面给出一个基于 Docker、Redis 和 LiteLLM 的示例方案。

说明：如果你完全使用 Coze 官方托管模型，不能直接修改底层模型调用链，那么可以重点使用前面提到的 Prompt、知识库、工作流优化方法。下面的命令更适合：自建服务、Coze Studio、外部 API 节点、私有模型网关、企业内部二次封装场景。

六、完整命令：部署一个带缓存的 LLM 网关

1. 创建项目目录

mkdir -p ~/coze-cost-gateway
cd ~/coze-cost-gateway

2. 创建 LiteLLM 配置文件

cat > config.yaml <<'EOF'
model_list:
  - model_name: cheap-model
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

  - model_name: strong-model
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

litellm_settings:
  set_verbose: false
  cache: true
  cache_params:
    type: redis
    host: redis
    port: 6379
    namespace: coze-cost-cache
    ttl: 86400
EOF

这里定义了两个模型：

• cheap-model：用于 FAQ、分类、摘要等低复杂度任务；
• strong-model：用于复杂推理、长文生成、高价值场景。

缓存 TTL 设置为 86400 秒，也就是 1 天。对于 FAQ 类问题，可以设置更长。

3. 创建 Docker Compose 文件

cat > docker-compose.yml <<'EOF'
services:
  redis:
    image: redis:7-alpine
    container_name: coze-cost-redis
    restart: always
    command: redis-server --appendonly yes
    volumes:
      - ./redis-data:/data

  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    container_name: coze-cost-litellm
    restart: always
    depends_on:
      - redis
    ports:
      - "4000:4000"
    environment:
      OPENAI_API_KEY: ${OPENAI_API_KEY}
      LITELLM_MASTER_KEY: ${LITELLM_MASTER_KEY}
    volumes:
      - ./config.yaml:/app/config.yaml
    command:
      - "--config"
      - "/app/config.yaml"
      - "--port"
      - "4000"
EOF

4. 创建环境变量文件

cat > .env <<'EOF'
OPENAI_API_KEY=替换成你的模型服务API_KEY
LITELLM_MASTER_KEY=sk-coze-gateway-demo-key
EOF

请将：

替换成你的模型服务API_KEY

改成真实 API Key。

5. 启动服务

docker compose up -d

查看容器状态：

docker compose ps

查看日志：

docker compose logs -f litellm

6. 测试网关调用

curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer sk-coze-gateway-demo-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "cheap-model",
    "messages": [
      {
        "role": "system",
        "content": "你是一个简洁的客服助手。"
      },
      {
        "role": "user",
        "content": "退款多久到账？"
      }
    ],
    "temperature": 0.2,
    "max_tokens": 300
  }'

再次执行同样的请求：

curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer sk-coze-gateway-demo-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "cheap-model",
    "messages": [
      {
        "role": "system",
        "content": "你是一个简洁的客服助手。"
      },
      {
        "role": "user",
        "content": "退款多久到账？"
      }
    ],
    "temperature": 0.2,
    "max_tokens": 300
  }'

如果缓存命中，第二次响应通常会更快，也能减少重复模型推理成本。

七、完整命令：增加 Nginx 限流保护

对于公开服务，建议增加限流，避免被恶意刷接口或异常流量打爆成本。

1. 安装 Nginx

Ubuntu / Debian：

sudo apt update
sudo apt install -y nginx

CentOS / Rocky Linux：

sudo yum install -y nginx

2. 创建 Nginx 配置

sudo tee /etc/nginx/conf.d/coze-cost-gateway.conf > /dev/null <<'EOF'
limit_req_zone $binary_remote_addr zone=coze_limit:10m rate=5r/s;

server {
    listen 8080;
    server_name _;

    client_max_body_size 10m;

    location / {
        limit_req zone=coze_limit burst=10 nodelay;

        proxy_pass http://127.0.0.1:4000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 300s;
    }
}
EOF

3. 检查并重启 Nginx

sudo nginx -t
sudo systemctl restart nginx
sudo systemctl enable nginx

测试：

curl http://localhost:8080/v1/models \
  -H "Authorization: Bearer sk-coze-gateway-demo-key"

八、完整命令：统计请求与 token 成本

如果你没有统计，就不知道钱花在哪里。下面提供一个简单脚本，用来从日志中估算请求数量和消耗。

1. 创建日志目录

mkdir -p ~/coze-cost-gateway/logs
cd ~/coze-cost-gateway

2. 创建一个简单的请求测试脚本

cat > test-request.sh <<'EOF'
#!/usr/bin/env bash

curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer sk-coze-gateway-demo-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "cheap-model",
    "messages": [
      {
        "role": "system",
        "content": "你是一个简洁的客服助手。"
      },
      {
        "role": "user",
        "content": "请用一句话说明退款多久到账？"
      }
    ],
    "temperature": 0.2,
    "max_tokens": 200
  }' | tee -a logs/response.log
EOF

chmod +x test-request.sh

运行：

./test-request.sh

3. 使用 jq 提取 usage 信息

安装 jq：

sudo apt update
sudo apt install -y jq

查看 token 用量：

cat logs/response.log | jq '.usage'

如果返回中包含 prompt_tokens、completion_tokens、total_tokens，就可以继续统计。

4. 统计总 token

cat logs/response.log \
  | jq -r 'select(.usage != null) | .usage.total_tokens' \
  | awk '{sum += $1} END {print "total_tokens=" sum}'

统计输入 token：

cat logs/response.log \
  | jq -r 'select(.usage != null) | .usage.prompt_tokens' \
  | awk '{sum += $1} END {print "prompt_tokens=" sum}'

统计输出 token：

cat logs/response.log \
  | jq -r 'select(.usage != null) | .usage.completion_tokens' \
  | awk '{sum += $1} END {print "completion_tokens=" sum}'

九、完整命令：本地估算 Prompt token

在上线前，可以先估算 Prompt 大小，避免系统 Prompt 和知识库内容过长。

1. 安装 Python 虚拟环境

mkdir -p ~/coze-token-check
cd ~/coze-token-check

python3 -m venv venv
source venv/bin/activate

pip install --upgrade pip
pip install tiktoken

2. 创建 token 估算脚本

cat > count_tokens.py <<'EOF'
import sys
import tiktoken

if len(sys.argv) < 2:
    print("Usage: python count_tokens.py ")
    sys.exit(1)

file_path = sys.argv[1]

with open(file_path, "r", encoding="utf-8") as f:
    text = f.read()

enc = tiktoken.get_encoding("cl100k_base")
tokens = enc.encode(text)

print(f"文件: {file_path}")
print(f"字符数: {len(text)}")
print(f"估算 token 数: {len(tokens)}")
EOF

3. 创建测试 Prompt 文件

cat > prompt.txt <<'EOF'
你是某品牌客服助手。
目标：根据用户问题提供准确、简洁、可执行的回答。
规则：
1. 优先根据知识库回答；
2. 不确定时说明无法确认，不编造；
3. 回答不超过 300 字；
4. 涉及售后、退款、发票问题时，按流程说明。
EOF

4. 运行估算

python count_tokens.py prompt.txt

如果系统 Prompt 超过几千 token，就应该重新整理。

十、模型分层：不要所有任务都用最贵模型

Coze 降本的关键思路之一是：不同任务使用不同模型。

推荐分层策略

不要让高规格模型处理所有请求。

一个成熟的 Coze 应用，通常会先判断问题类型，再决定是否需要调用更强模型。

例如：

如果是退款、发票、物流、账号登录等标准问题，使用 cheap-model。
如果是复杂投诉、长文本分析、合同条款解释，使用 strong-model。

这样可以在保证体验的同时，大幅降低整体平均成本。

十一、缓存策略：哪些内容适合缓存

不是所有请求都适合缓存。适合缓存的内容包括：

• FAQ 标准问题；
• 售后政策；
• 发票规则；
• 物流说明；
• 课程介绍；
• 固定产品说明；
• 营业时间；
• 门店地址；
• 操作流程；
• 常见报错解决方法。

不适合缓存的内容包括：

• 涉及用户隐私的个性化回答；
• 订单状态；
• 账户余额；
• 实时库存；
• 实时价格；
• 动态活动规则；
• 投诉处理结果。

对于动态内容，建议缓存基础解释，但实时数据必须调用业务系统接口。

十二、输出格式越稳定，成本越低

模型输出越发散，越容易产生长回答，也越难被后续节点处理。

建议在 Coze 工作流中为中间节点统一 JSON 输出格式。

示例：

请判断用户意图，只输出 JSON：
{
  "intent": "refund | invoice | logistics | account | other",
  "confidence": 0到1之间的小数,
  "need_human": true或false
}
不要输出解释。

这样有三个好处：

1. 输出更短；
2. 后续节点更容易解析；
3. 可以减少模型重复解释。

十三、设置兜底规则，减少无意义消耗

有些用户会输入无效内容，例如：

哈哈哈哈
你是谁
测试
123
随便聊聊

如果每次都进入完整知识库检索和大模型问答流程，成本会被浪费。

建议设置前置判断：

• 输入少于 2 个有效字符，直接提示重新输入；
• 明显闲聊走轻量模型；
• 敏感或违规问题直接拒答；
• 与业务无关问题不检索知识库；
• 低置信度问题建议转人工。

示例回复：

我暂时没有理解你的问题。你可以补充说明想咨询退款、发票、物流还是账号问题。

这种兜底回复不需要复杂模型。

十四、建立成本告警机制

当 Bot 进入生产环境后，一定要设置成本阈值。

建议关注以下指标：

• 每日请求量；
• 每日 token 总量；
• 平均每次请求 token；
• 缓存命中率；
• 单用户平均请求次数；
• 高成本请求 Top 10；
• 知识库召回平均片段数；
• LLM 节点平均调用次数；
• 失败重试次数。

如果发现某一天 token 暴涨，通常是以下原因：

• 被刷接口；
• 某个工作流死循环；
• 知识库召回异常；
• Prompt 被改得过长；
• 用户上传了超长内容；
• 模型输出没有长度限制；
• 某个节点重试次数过多。

十五、上线前成本检查清单

在发布 Coze Bot 前，可以按以下清单检查：

• [ ] 系统 Prompt 是否控制在合理长度；
• [ ] 是否限制最大输出字数；
• [ ] 是否减少无用历史上下文；
• [ ] 知识库切片是否合理；
• [ ] 知识库召回数量是否过高；
• [ ] 是否设置相似度阈值；
• [ ] 工作流是否存在多个不必要的 LLM 节点；
• [ ] 意图识别是否可以用规则替代；
• [ ] 是否区分低成本模型和高规格模型；
• [ ] 高频 FAQ 是否有缓存；
• [ ] 是否设置接口限流；
• [ ] 是否有 token 统计；
• [ ] 是否有异常成本告警；
• [ ] 是否对无效输入做了前置拦截；
• [ ] 是否对高风险问题设置人工兜底。

十六、一个推荐的低成本 Coze 架构

比较理想的架构如下：

用户
 ↓
Coze Bot
 ↓
前置规则判断
 ↓
意图识别
 ↓
低成本路径 / 高价值路径
 ↓
知识库检索
 ↓
缓存网关
 ↓
模型调用
 ↓
结构化回答
 ↓
用户

核心原则是：

能不用模型就不用模型；
能用小模型就不用大模型；
能用缓存就不用重复推理；
能短回答就不长回答；
能规则判断就不做模型判断；
能结构化输出就不自由发挥。

总结

Coze 降低成本不是单靠某一个技巧，而是一套系统工程。

最有效的几个方向是：

1. 减少 token：精简 Prompt、限制输出、压缩上下文；
2. 优化知识库：合理切片、减少召回、提高相关性；
3. 简化工作流：减少不必要的 LLM 节点；
4. 模型分层：简单任务用低成本模型，复杂任务再用高规格模型；
5. 增加缓存：高频 FAQ 和标准问答直接复用结果；
6. 设置限流：防止异常流量造成成本失控；
7. 建立统计：持续观察 token、请求量、缓存命中率和高成本请求。

如果你只是做个人 Demo，可能不需要这么复杂；但如果 Coze Bot 已经服务真实用户，或者接入了客服、销售、运营、知识库问答等业务场景，那么成本控制必须从一开始就设计进去。

一句话总结：

Coze 降本的本质，不是简单“少用 AI”，而是让 AI 只在真正需要的地方发挥价值。