企业官网建设流程全解析

• 后端
• 前端
• 协同办公
• 即时通讯
• 企业应用

本指南面向 DooTask 系统管理员，围绕「接入 AI 后到底花了多少钱、谁在用、能不能给用户限额」这一核心问题展开。文章完整讲解 DooTask 接入外部大模型供应商后的 token 计费逻辑、三种用量查询手段与五类成本控制手段，并结合 app/Module/AI.php、app/Models/Setting.php、config/ai.php 等源码验证底层实现，帮助你在不改造代码的前提下把 AI 成本管住、管细、管到可解释的程度。

问题背景：管理员需要回答的三个问题

DooTask 的 AI 能力由独立的ai 插件（dootask-ai容器）提供，主程序自身不内置任何大模型。因此当系统内出现「AI 助手」「任务智能拆解」「AI 报告」「自动总结」等能力时，管理员最关心的三件事是：

1. 接入 AI 后每月到底会产生多少费用？
2. 这些费用分别由哪些场景、哪些模型产生？
3. 能不能对单个用户设置每日调用次数上限、按部门分摊账单？

本文档（来自知识库 ai-token-cost.md，校验版本 v1.7.90）给出的核心结论是：DooTask 本身不收费，费用直接产生在所配置供应商账户上；系统当前没有内置按用户分摊与按用户限流能力，但可以通过供应商侧硬上限 + 模型选型 + 场景裁剪把成本控制在预期范围内。

计费逻辑：DooTask 免费，成本在供应商侧

谁在收费，谁不收费

• DooTask 主程序与 ai 插件本身不向用户收费，它们只负责转发请求、组装上下文与展示结果。
• 每次 AI 回复的实际费用，直接产生在所配供应商的账户余额上：OpenAI（OpenAI Platform）、Anthropic（Claude）、阿里云通义（Qwen）、豆包、智谱（BigModel）、DeepSeek、Google Gemini、xAI Grok、百度文心等，均可作为文本模型供应商接入。

一次回复的 token 由什么构成

每次回复消耗的 token 可用以下公式概括：

消耗 token = 输入 token（系统提示 + 会话上下文 + 用户问题 + 知识库检索结果） + 输出 token（模型生成文本）

其中几个容易忽略、却是成本大头的关键点：

1. 工具调用结果回灌也计费：DooTask 的 AI 助手支持执行工具（如doo页面操作、search_help_docs知识库检索，见 app/Module/AI.php 中createStreamKey透传的doo_enabled、rag_enabled参数）。模型先读工具结果、再基于结果生成回复，结果文本会计入下一次请求的输入 token。工具返回越长，二次输入开销越大。
2. 多轮会话越长，输入越大：对话模式下，模型每次请求携带的输入 = 整段历史上下文（输入 = 整段历史），而不是只发最后一句话。会话轮数线性增长时，每轮输入 token 也在累加，成本呈超线性增长。
3. 知识库检索（RAG）会放大输入：当启用了 RAG（帮助知识库检索）时，检索命中的文档片段会被拼进 prompt。检索结果条数与片段长度直接决定输入规模。

源码侧的佐证

从源码可以印证上述计费逻辑的实现路径：

• app/Module/AI.php 的request()方法将messages数组整体 POST 到${base_url}/chat/completions，base_url默认https://api.openai.com/v1，即主程序完整转发 OpenAI 兼容格式的请求，token 统计完全由供应商侧完成。
• 同文件的invoke()方法构造payload时仅含model与messages两个字段，messages即「系统提示 + 上下文 + 用户问题」的全部内容；该方法还会对相同消息做Cache::remember1 小时缓存，命中缓存时不会重复计费（调用方$noCache为 false 时）。
• config/ai.php 定义了 RAG 总开关rag_enabled与 canary 白名单rag_canary_userids，说明知识库检索是插件侧按开关挂载search_help_docs工具的，开启后检索结果会进入上下文。
• 语音转写与翻译等能力同样按供应商计费：transcriptions()走/audio/transcriptions，固定使用gpt-4o-mini-transcribe模型。

查询用量：三条路径各有分工

当前版本查询 AI 用量没有统一的聚合界面，管理员可按以下三条路径组合使用：

1. 供应商开发者后台（最权威）

登录对应供应商的开发者后台查看月度账单，例如 OpenAI Platform → Usage（用量页）。这是金额的唯一事实来源，因为计费完全发生在供应商侧。账单可以按 API Key、按模型、按日期维度查看，能直接回答「这个月花了多少钱、哪些模型占了大头」。

2. ai 插件容器日志（可统计调用次数）

dootask-ai容器日志包含每次调用的调用记录，可用于统计调用次数与时间分布：

docker logs dootask-ai # 或按关键字过滤 docker logs dootask-ai 2>&1 | grep -i "usage\|token\|error"

容器名可通过docker ps | grep dootask-ai确认。此路径能回答「调用频率」问题（例如哪个时段调用密集），但日志中一般不会包含精确的美元金额，需要与供应商账单交叉比对。

3. Web 界面分摊（当前不存在）

暂无 web 界面按 DooTask 用户分摊成本。也就是说，管理员无法在系统内直接看到「张三本月用了多少 token、折合多少钱」。若需要精确到人的成本统计，只能依赖供应商侧按 API Key 拆分 + 日志分析自行实现。

控制成本：五类可落地的实操手段

手段一：选轻量模型（性价比最高的一招）

在「系统设置 → AI 机器人 → 默认模型」中，将默认模型选为轻量档位：GPT-4 mini 系列、Claude Haiku、Qwen-turbo、deepseek-chat 等。轻量模型相对顶级模型的单价通常便宜 10–100 倍，而任务管理场景（总结、拆解、生成描述）对模型能力要求并不高，性价比优势明显。

源码侧事实：默认模型由Setting::AIBotModels2Array()解析（见 app/Models/Setting.php），模型列表支持两种写法：

• 新 JSON 数组格式：[{"id":"gpt-4o-mini","name":"GPT-4o mini","thinking":"off"}, ...]，id为模型 ID、name为展示名、thinking为思考档位（off|low|medium|high，默认off）；
• 旧字符串格式：每行一个id|name。

主程序默认 OpenAI 模型常量为gpt-5.1-mini（见 app/Module/AI.php 的OPENAI_DEFAULT_MODEL），且resolveOpenAITextModel()会优先返回用户模型列表中命中默认值的模型。此外，Setting对temperature参数会归一化到0–1区间、默认0.7，更低温度可减少冗余输出 token。

手段二：限制上下文长度

通过修改插件配置，在插件层裁剪最大对话轮数，避免多轮会话把整段历史无限带入输入。由于「输入 = 整段历史」，轮数上限是控制输入 token 最直接的手段。注意：主程序不提供面向管理员的上下文长度开关，此项需要修改插件配置，属于"需自研/改配置"类操作。

手段三：关闭高频自动调用

「自动总结报告」「自动智能拆解」等按需触发的 AI 能力，如果长期开启，会在无人感知时持续消耗 token。建议在系统设置中改为手动触发，或评估后关闭。

源码侧事实：任务侧自动分析由 app/Tasks/AiTaskAnalyzeTask.php 驱动，它会逐类处理ProjectTaskAiEvent事件（描述生成、子任务生成、负责人建议、相似任务推荐）。而 app/Module/AiTaskSuggestion.php 的shouldExecute()定义了各事件的实际触发条件：

可以看到，shouldExecute本身已经做了条件过滤（不满足条件会markSkipped），但只要事件产生且条件满足，就会产生一次模型调用。管理员应结合业务节奏评估这类自动能力的开关策略。

手段四：供应商侧设硬上限（兜底手段）

在 OpenAI 控制台等供应商后台设置monthly budget cap（月度预算上限），超额后供应商自动停止服务。这是唯一能在 DooTask 侧不配合的情况下强制断流的兜底手段，建议作为必选项开启。

手段五：多供应商负载分流

DooTask 支持同时配置多个供应商（见 app/Module/AI.php 的TEXT_MODEL_PRIORITY常量，顺序为openai → claude → deepseek → gemini → grok → ollama → zhipu → qianwen → wenxin → dooai），resolveTextProvider()会按此优先级选择第一个配置完整的厂商，buildProviderConfig()从aibotSetting中读取各厂商的key / base_url / agency / model字段。

可以据此把成本不同的模型分给不同场景：高价值对话场景用强模型，批量/自动场景（如翻译、标题生成、笑话生成）用低成本模型，甚至通过base_url指向本地 Ollama 实现零 API 费用。主程序的invoke()、translations()、generateTitle()等通用调用都会复用同一个resolveTextProvider()，因此切换默认模型会全局生效，规划模型分配时需注意这一点。

明确不支持的能力（边界说明）

在规划成本治理方案前，请先确认以下能力当前版本不存在，避免在错误预期上投入改造：

• 没有内置「单用户每天 N 次」配额：无法在系统设置中限制单个用户每日 AI 调用次数；
• 没有「按部门分摊账单」表：无法生成部门维度的用量报表；
• 不能在 DooTask 内冻结单个用户的 AI 使用：无法针对个别高耗用户单独停用 AI 能力。

若确需上述能力，只能自研代理层（在 ai 插件前加一层网关做配额与计量）或依赖供应商侧的 API Key 级拆分。

推荐做法：分阶段成本管理路线

根据试用期、重度使用期、长期运营三个阶段给出落地建议：

1. 试用阶段：使用便宜模型 + 设置小额预算。验证 AI 功能在业务中的真实价值，同时把试错成本压到最低。
2. 重度场景：在供应商账户设置硬性月度上限。确认核心场景稳定后再放量，预算封顶防止失控。
3. 长期运营：定期监控供应商发票；出现不合理涨幅时，让团队复盘高耗用户与高频场景，结合「关闭自动调用」「调整默认模型」等手段治理。

相关配置入口与源码索引

• 供应商与模型配置：系统设置 → AI 模型 / AI 机器人（管理员），对应接口为 app/Http/Controllers/Api/SystemController.php 的setting__aibot()（仅管理员 + 需安装 ai 插件），保存时受dootask.system_setting环境开关约束；
• RAG 灰度与紧急关停：RAG_ENABLED/RAG_CANARY_USERIDS环境变量，见 config/ai.php，紧急关停流程为「改 envRAG_ENABLED=false→./cmd php restart让 Swoole 重读配置 → ai 插件收到rag_enabled=0后跳过 RAG hint 注入与工具挂载」；
• ai 插件内网地址：AI_HOST（默认ai）与AI_PORT（默认5001），见 config/dootask.php，向量化接口/embeddings由插件免费向量模型提供，文本会先截断至约 30K 字符（见AI::getEmbedding()），Embedding 结果缓存 7 天，不会重复计费；
• 容器排查：docker ps | grep dootask-ai、docker logs dootask-ai（参考知识库 ai-no-models.md 中的容器异常排查思路，AI 依赖问题可对照阅读）；
• 自动分析任务事件定义与重试策略：见 app/Models/ProjectTaskAiEvent.php 与 app/Tasks/AiTaskAnalyzeTask.php。

结语

DooTask 的 AI 成本管理本质上是**「供应商侧预算 + 模型选型 + 场景裁剪」的组合拳**：主程序不收费、也不内置配额，管理员应把预算上限、轻量默认模型、自动调用开关作为三个必配项，再辅以容器日志与供应商账单做周期性的用量审计。本文所涉及的配置入口、源码路径与触发条件均来自当前仓库，可据此在部署环境中逐项核对落实。

• 后端
• 前端
• 协同办公
• 即时通讯
• 企业应用