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

在 AI 应用落地过程中，很多团队一开始会把注意力放在“能不能跑起来”，但真正进入业务场景后，很快就会遇到一个现实问题：成本越来越高。

尤其是使用 Coze 搭建智能体、工作流、知识库问答、客服机器人、内容生成工具时，如果没有做好模型选择、调用控制、缓存策略和部署优化，成本很容易失控。

本文将从实战角度出发，系统讲解 Coze 如何降低成本，并附上常用的完整命令，方便你直接复制使用。

一、Coze 成本主要花在哪里？

在优化之前，必须先知道钱花在了哪里。

使用 Coze 构建 AI 应用时，成本通常来自以下几个方面：

1. 大模型调用成本

   • 输入 Token
   • 输出 Token
   • 多轮对话上下文
   • Workflow 中多节点重复调用模型

2. 知识库检索成本

   • 文档切片
   • 向量化 Embedding
   • 向量数据库存储
   • 检索召回与重排

3. 插件 / API 调用成本

   • 外部搜索接口
   • 数据库查询
   • 第三方 SaaS API
   • 自建服务接口

4. 部署和服务器成本

   • Coze Studio 服务
   • 数据库
   • Redis
   • 向量数据库
   • 对象存储
   • 日志监控

5. 无效调用成本

   • 用户重复提问
   • Bot 频繁兜底回答
   • Prompt 太长
   • Workflow 设计不合理
   • 每次请求都调用大模型

所以，降低 Coze 成本不是简单地“换一个便宜模型”，而是要从 模型、Prompt、Workflow、缓存、知识库、部署架构 多方面一起优化。

二、成本优化的核心思路

降低 Coze 成本，可以遵循一个原则：

能不用大模型就不用大模型；
能用小模型就不用大模型；
能缓存就不要重复生成；
能规则判断就不要让模型判断；
能本地化部署就减少外部依赖。

具体可以拆成以下几类：

三、优先使用模型分层策略

很多人在 Coze 中搭建 Bot 时，会默认给所有任务都配置一个强模型，例如 GPT-4、Claude 3.5、豆包 Pro、DeepSeek-R1 等。

这会导致一个问题：

无论用户问的是简单问题还是复杂问题，都会走高成本模型。

更好的做法是模型分层。

1. 简单任务使用低成本模型

适合低成本模型的任务包括：

• 意图识别
• 分类判断
• 文本改写
• 简单 FAQ
• 格式转换
• 标签提取
• 简单摘要

例如：

用户问题：帮我把这句话改得更正式一点
用户问题：判断这句话是售前还是售后
用户问题：提取下面内容中的手机号和邮箱

这些任务不需要强推理模型，使用轻量模型即可。

2. 复杂任务再使用高能力模型

适合强模型的任务包括：

• 多步骤推理
• 复杂代码生成
• 法律、金融、医疗类严肃分析
• 长文档综合总结
• 多工具协同决策
• 高质量内容创作

3. 在 Coze Workflow 中做路由

你可以在 Workflow 中先增加一个“意图识别节点”，判断任务类型，然后分流到不同模型。

示例逻辑：

用户输入
  ↓
意图识别节点
  ↓
如果是 FAQ → 知识库检索 / 缓存返回
如果是简单改写 → 低成本模型
如果是复杂分析 → 高能力模型
如果是无关问题 → 直接拒答

这样可以显著降低模型调用成本。

四、精简 Prompt，减少输入 Token

在 Coze 中，很多成本浪费都来自 Prompt 过长。

例如，有些 Bot 的角色设定会写成几千字：

你是一个非常专业、非常耐心、非常友好、非常有责任心的智能助手……

看似专业，实际上每次请求都会把这些内容带入上下文，导致输入 Token 增加。

优化前

你是一名拥有十年以上经验的资深电商客服专家，你非常熟悉售前咨询、售后处理、物流查询、退款退货、商品推荐、会员权益、优惠券使用等所有场景。你需要用亲切、耐心、专业、温暖、积极、礼貌的语气回答用户问题，并且在回答时要结合品牌调性，不要使用冷冰冰的话术……

优化后

你是电商客服助手。
要求：
1. 简洁、礼貌、专业；
2. 优先解决售前、售后、物流、退款问题；
3. 不确定时引导用户提供订单号或联系人工客服。

优化后的 Prompt 更短，但控制效果并不会明显下降。

Prompt 优化原则

1. 删除重复形容词；
2. 删除不影响结果的背景描述；
3. 用规则列表代替长段落；
4. 把固定知识放进知识库，而不是 Prompt；
5. 把复杂任务拆到 Workflow，而不是全部塞进系统提示词。

五、限制输出长度，避免模型“话太多”

输出 Token 也是成本的重要组成部分。

如果 Bot 每次都输出 800 字，而用户其实只需要一个简单答案，成本就会被浪费。

可以在 Coze 的提示词中加入输出约束：

回答要求：
1. 默认不超过 150 字；
2. 用户要求详细解释时，再展开说明；
3. 优先使用要点列表；
4. 不要重复用户问题；
5. 不要输出无关背景知识。

如果是客服场景，可以进一步压缩：

回复要求：
1. 每次回复控制在 80 字以内；
2. 先给结论，再给操作步骤；
3. 如果需要订单信息，只询问必要字段；
4. 不主动输出营销话术。

对高频 Bot 来说，输出长度控制通常能带来非常明显的成本下降。

六、用缓存减少重复调用

很多用户会重复问相同或相似的问题：

怎么退款？
如何申请退款？
退款流程是什么？
退货退款怎么操作？

如果每次都调用大模型，就会造成浪费。

对于高频 FAQ，可以做缓存：

• 问题标准化；
• 相似问题归一；
• 命中缓存直接返回；
• 未命中再调用模型。

如果你是自建 Coze Studio 或者在 Coze 外层接入网关，可以用 Redis 做缓存。

七、Redis 缓存完整命令

以下以 Ubuntu 服务器为例。

1. 安装 Redis

sudo apt update
sudo apt install -y redis-server

2. 启动 Redis

sudo systemctl enable redis-server
sudo systemctl start redis-server

3. 查看 Redis 状态

sudo systemctl status redis-server

4. 测试 Redis 是否可用

redis-cli ping

正常返回：

PONG

5. 设置缓存示例

redis-cli SET "faq:refund" "您可以在订单详情页点击申请退款，按页面提示提交原因和凭证。"

6. 读取缓存示例

redis-cli GET "faq:refund"

7. 设置带过期时间的缓存

redis-cli SETEX "faq:shipping" 3600 "物流信息可在订单详情页查看，如超过48小时未更新，建议联系人工客服。"

8. 查看所有 FAQ 缓存 Key

redis-cli KEYS "faq:*"

生产环境不建议频繁使用 KEYS，可以使用：

redis-cli SCAN 0 MATCH "faq:*" COUNT 100

八、使用本地模型进一步降低成本

如果你的业务场景对模型能力要求不是特别高，可以把部分任务迁移到本地模型，例如：

• 分类
• 摘要
• 文本改写
• 意图识别
• FAQ 初筛
• 数据抽取

常见方案包括：

• Ollama
• vLLM
• LM Studio
• llama.cpp
• 本地部署 Qwen、DeepSeek、Llama 等开源模型

其中 Ollama 最适合快速测试。

九、Ollama 本地模型部署完整命令

1. 安装 Ollama

curl -fsSL https://ollama.com/install.sh | sh

2. 查看 Ollama 版本

ollama --version

3. 拉取轻量模型

例如拉取 Qwen2.5 7B：

ollama pull qwen2.5:7b

如果服务器配置较低，可以使用更小模型：

ollama pull qwen2.5:3b

4. 运行模型

ollama run qwen2.5:7b

5. 测试本地 API

Ollama 默认 API 地址是：

http://localhost:11434

使用 curl 测试：

curl http://localhost:11434/api/generate \
  -d '{
    "model": "qwen2.5:7b",
    "prompt": "请用一句话解释什么是意图识别",
    "stream": false
  }'

6. 让 Ollama 监听公网或内网地址

编辑 systemd 服务：

sudo systemctl edit ollama

加入：

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

重新加载并重启：

sudo systemctl daemon-reload
sudo systemctl restart ollama

查看监听端口：

ss -lntp | grep 11434

注意：如果开放公网访问，请务必加网关鉴权，不要直接暴露 Ollama API。

十、通过 API 网关控制调用成本

如果你把 Coze、Workflow 或外部系统接入了自建模型服务，建议加一层 API 网关。

API 网关可以做：

1. 请求鉴权；
2. 限流；
3. 缓存；
4. 日志统计；
5. 模型路由；
6. 黑名单；
7. 成本审计。

最简单的方式是用 Nginx 做反向代理。

十一、Nginx 反向代理完整命令

1. 安装 Nginx

sudo apt update
sudo apt install -y nginx

2. 新建配置文件

sudo nano /etc/nginx/sites-available/ollama.conf

写入：

server {
    listen 80;
    server_name your-domain.com;

    location / {
        proxy_pass http://127.0.0.1:11434;
        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;

        client_max_body_size 20m;
        proxy_read_timeout 300s;
    }
}

3. 启用配置

sudo ln -s /etc/nginx/sites-available/ollama.conf /etc/nginx/sites-enabled/ollama.conf

4. 测试配置

sudo nginx -t

5. 重启 Nginx

sudo systemctl reload nginx

6. 使用域名测试

curl http://your-domain.com/api/generate \
  -d '{
    "model": "qwen2.5:7b",
    "prompt": "你好，请介绍一下你自己",
    "stream": false
  }'

十二、给 API 增加简单鉴权

直接暴露模型服务非常危险，建议至少增加 Basic Auth。

1. 安装 htpasswd 工具

sudo apt install -y apache2-utils

2. 创建账号密码

sudo htpasswd -c /etc/nginx/.htpasswd cozeuser

根据提示输入密码。

3. 修改 Nginx 配置

sudo nano /etc/nginx/sites-available/ollama.conf

在 location / 中加入：

auth_basic "Restricted API";
auth_basic_user_file /etc/nginx/.htpasswd;

完整示例：

server {
    listen 80;
    server_name your-domain.com;

    location / {
        auth_basic "Restricted API";
        auth_basic_user_file /etc/nginx/.htpasswd;

        proxy_pass http://127.0.0.1:11434;
        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;

        client_max_body_size 20m;
        proxy_read_timeout 300s;
    }
}

4. 测试并重载

sudo nginx -t
sudo systemctl reload nginx

5. 使用账号密码请求

curl -u cozeuser:你的密码 http://your-domain.com/api/generate \
  -d '{
    "model": "qwen2.5:7b",
    "prompt": "请判断：用户想申请退款。这属于售前还是售后？",
    "stream": false
  }'

十三、优化知识库，减少无效检索

Coze 的知识库能力非常适合客服、内部问答、产品助手等场景。但知识库如果设计不好，也会增加成本。

常见问题包括：

1. 文档太长，切片混乱；
2. 重复上传相同文档；
3. 无效内容过多；
4. FAQ 和制度文档混在一起；
5. 检索结果不准确，导致模型需要额外解释；
6. 每次都进行多轮检索和重排。

知识库优化建议

1. 删除无效内容

例如：

• 页眉页脚；
• 公司介绍；
• 重复免责声明；
• 无意义目录；
• 过期政策；
• 图片 OCR 噪声。

2. 用 FAQ 格式组织高频问题

推荐格式：

## 问题：如何申请退款？

答案：
用户可以在订单详情页点击“申请退款”，选择退款原因并提交。
如商品已发货，需要先申请退货退款。

3. 控制切片长度

切片过短会导致上下文不完整，切片过长会增加 Token 消耗。

一般建议：

单个切片：300～800 中文字
重叠长度：50～100 中文字

4. 按业务拆分知识库

不要把所有内容放进一个知识库。

可以拆成：

• 售前知识库；
• 售后知识库；
• 物流知识库；
• 产品知识库；
• 内部制度知识库。

这样可以先做意图识别，再检索对应知识库，减少无效召回。

十四、用 Workflow 减少模型调用

很多人设计 Workflow 时，会把每一步都交给大模型。

例如：

节点1：判断用户意图
节点2：总结用户问题
节点3：检索知识库
节点4：判断检索结果是否可用
节点5：生成回答
节点6：润色回答

这样一次请求可能调用 4～5 次模型。

优化后可以变成：

节点1：规则判断关键词
节点2：知识库检索
节点3：模型生成最终回答

对于客服类场景，很多判断其实不需要模型。

例如：

如果用户问题包含“退款、退货、退钱、取消订单”，归类为售后；
如果包含“多少钱、价格、优惠、活动”，归类为售前；
如果包含“快递、物流、发货、到哪了”，归类为物流。

这些可以通过代码节点或条件节点完成。

十五、关键词意图识别示例代码

如果你在 Coze Workflow 中使用代码节点，可以参考类似逻辑：

async function main({ input }) {
  const text = input || "";

  const intents = [
    {
      name: "after_sale",
      keywords: ["退款", "退货", "售后", "取消订单", "退钱", "换货"]
    },
    {
      name: "pre_sale",
      keywords: ["多少钱", "价格", "优惠", "活动", "怎么买", "下单"]
    },
    {
      name: "logistics",
      keywords: ["物流", "快递", "发货", "到哪", "单号", "配送"]
    }
  ];

  for (const item of intents) {
    if (item.keywords.some(k => text.includes(k))) {
      return {
        intent: item.name,
        confidence: 0.9
      };
    }
  }

  return {
    intent: "unknown",
    confidence: 0.3
  };
}

这种方式虽然简单，但对于高频业务问题非常有效，成本几乎可以忽略。

十六、部署 Coze Studio 降低长期平台成本

如果你有私有化、内网使用、数据安全或长期成本控制需求，可以考虑部署开源版 Coze Studio。

说明：不同版本的 Coze Studio 部署方式可能会变化，实际命令请以官方仓库文档为准。下面给出常见 Docker Compose 部署思路。

1. 安装基础依赖

sudo apt update
sudo apt install -y git curl wget vim ca-certificates gnupg lsb-release

2. 安装 Docker

curl -fsSL https://get.docker.com | sudo bash

3. 启动 Docker

sudo systemctl enable docker
sudo systemctl start docker

4. 安装 Docker Compose 插件

sudo apt install -y docker-compose-plugin

5. 查看版本

docker version
docker compose version

6. 克隆 Coze Studio 仓库

git clone https://github.com/coze-dev/coze-studio.git
cd coze-studio

7. 查看项目文件

ls -la

8. 查找 Docker Compose 文件

find . -name "docker-compose*.yml" -o -name "docker-compose*.yaml"

9. 根据官方示例复制环境变量

如果项目提供 .env.example，可以执行：

cp .env.example .env

如果在 docker 目录下：

cp docker/.env.example docker/.env

10. 编辑环境变量

vim .env

或：

vim docker/.env

重点检查：

DATABASE_URL=
REDIS_URL=
MINIO_ENDPOINT=
OPENAI_API_KEY=
MODEL_PROVIDER=

11. 启动服务

如果 compose 文件在当前目录：

docker compose up -d

如果 compose 文件在 docker 目录：

cd docker
docker compose up -d

12. 查看容器状态

docker compose ps

13. 查看日志

docker compose logs -f

指定服务查看日志：

docker compose logs -f 服务名

14. 停止服务

docker compose down

15. 更新代码

git pull
docker compose pull
docker compose up -d

如果需要重新构建：

docker compose up -d --build

十七、数据库和日志也要控成本

很多团队只关注模型成本，却忽略了日志和数据库成本。

如果你记录了完整请求、完整 Prompt、完整上下文、完整输出，那么日志量会快速增长。

建议：

1. 日志脱敏；
2. 只保留必要字段；
3. 大文本不要长期保存；
4. 设置日志轮转；
5. 定期清理历史会话；
6. 对高频 Bot 单独统计成本。

十八、日志轮转完整命令

1. 查看日志目录大小

du -sh /var/log/*

2. 查看 Docker 日志大小

sudo du -sh /var/lib/docker/containers/*

3. 配置 Docker 日志限制

编辑 Docker 配置：

sudo nano /etc/docker/daemon.json

写入：

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}

重启 Docker：

sudo systemctl restart docker

4. 清理无用 Docker 资源

docker system prune -f

如果确认不需要未使用镜像：

docker system prune -a -f

清理未使用 volume 要谨慎：

docker volume prune -f

十九、建立成本监控表

降低成本不能靠感觉，必须有数据。

建议至少统计以下字段：

如果暂时没有完整系统，也可以先用 CSV 记录。

示例表头：

time,user_id,bot_id,model,input_tokens,output_tokens,total_tokens,cost,cache_hit,intent

有了统计以后，你就能发现：

• 哪个 Bot 最烧钱；
• 哪个 Workflow 调用最多；
• 哪类问题最适合缓存；
• 哪个模型性价比最低；
• 哪些 Prompt 太长；
• 哪些用户存在异常调用。

二十、推荐的 Coze 降本方案组合

如果你的目标是快速见效，可以按以下顺序执行。

第一阶段：无需改架构

1. 精简 Bot Prompt；
2. 限制默认输出长度；
3. 删除无用知识库内容；
4. Workflow 减少模型节点；
5. FAQ 问题直接固定回复。

第二阶段：轻量改造

1. 增加意图识别；
2. 简单问题走便宜模型；
3. 高频问题加 Redis 缓存；
4. 日志统计 Token；
5. 对异常用户做限流。

第三阶段：深度优化

1. 部署本地模型；
2. 自建 API 网关；
3. 私有化 Coze Studio；
4. 向量库分业务拆分；
5. 建立模型路由系统；
6. 建立成本看板。

二十一、一个实际降本示例

假设一个客服 Bot 每天有 10,000 次请求。

优化前：

• 每次都走高能力模型；
• 平均输入 2,000 Token；
• 平均输出 500 Token；
• 每次 Workflow 调用 3 次模型。

那么每天 Token 消耗大约是：

10,000 × (2,000 + 500) × 3 = 75,000,000 Token

优化后：

• 40% FAQ 命中缓存；
• 30% 简单问题走小模型；
• 20% 知识库问答走中等模型；
• 10% 复杂问题走强模型；
• 平均 Prompt 压缩 40%；
• Workflow 从 3 次模型调用减少到 1～2 次。

实际成本通常可以下降 50%～80%。

这也是为什么 Coze 降本的关键，不是单点优化，而是组合优化。

总结

Coze 降低成本的关键，不是盲目追求最便宜的模型，而是建立一套完整的成本控制体系。

你可以从以下几个方面入手：

1. 模型分层：简单任务用小模型，复杂任务才用强模型；
2. Prompt 精简：减少无效输入 Token；
3. 输出控制：避免模型生成过长内容；
4. Workflow 优化：减少重复模型调用；
5. 知识库治理：提高检索质量，减少无效上下文；
6. 缓存机制：高频问题直接返回；
7. 本地模型：用 Ollama、vLLM 等承接低复杂度任务；
8. API 网关：实现鉴权、限流、缓存和日志；
9. 自托管部署：适合长期、私有化、规模化使用；
10. 成本监控：用数据持续优化。

如果你刚开始做 Coze 降本，建议先从 Prompt 压缩、输出限制、Workflow 减节点、FAQ 缓存 这四件事开始，投入小、见效快。

当请求量上来之后，再考虑本地模型、网关、私有化部署和成本看板。这样既能保证 AI 应用效果，又能把长期运行成本控制在可接受范围内。