上传的文件越来越多，但你还在用“文档数量 × 单价”估算预算，结果上线后模型调用、索引重建、沙箱和运维费用一起失控。
最快解法：把 WeKora 知识库成本拆成数据处理、索引与存储、问答模型、Agent 工具调用、沙箱执行和运维六类，再按查询量、并发、更新频率和失败重试持续修正。
这篇文章适合企业知识库负责人、产品工程师和 AI 平台负责人：你需要为 RAG 与 Agent 项目建立可解释的预算模型，判断文档上传、检索、工具调用和自动 Wiki 哪些环节最消耗资源，也希望在上线前估算云端工作区与长期运行开销。
预算边界
WeKnora 官方项目名为 WeKnora，官方仓库已经把能力边界扩展到 RAG 问答、Agent 推理、MCP 工具、自动 Wiki、技能沙箱和长期记忆等模块。它不是“上传文件后调用一次模型”的单体服务，预算至少要分成三层：
- 一次性部署成本：镜像拉取、环境配置、数据库与对象存储初始化、模型接入、权限和网络设置。
- 持续运行成本：应用服务、文档解析、数据库、向量检索、对象存储、日志、监控、备份和安全维护。
- 业务增长成本：文档增量同步、向量重建、问答调用、重排、Agent 多步工具调用、网页搜索、沙箱执行和 Wiki 更新。
官方中文说明显示，项目包含 Docker Compose 快速启动方式，并提供多个可选组件，例如知识图谱、对象存储和链路追踪。是否启用这些组件，会直接改变你的基础设施账单与运维工作量。具体部署入口可参考官方中文项目说明。
部署 WeKora（WeKnora）时，预算应该从哪些部分开始拆？
至少要记录这六类变量，而不是只记录“用了多少 GB 文件”：
- 文档原始大小、文件数量、格式和扫描件比例；
- 解析、OCR、摘要和多模态处理的任务量；
- 分块数量、嵌入次数、索引更新次数和存储副本；
- 用户查询量、上下文长度、检索次数和重排次数；
- Agent 每个任务的工具调用、网页搜索、失败重试和沙箱执行；
- 服务常驻时间、监控日志、备份、权限审计和人工维护时间。
文档处理与索引
首次导入、增量同步和大批量重建，应该使用三套不同的估算公式。
首次导入适合这样计算：
首次处理成本 = 解析任务量 + OCR / VLM 任务量 + 分块数量 × 嵌入调用 + 初次索引写入 + 原始文件存储
如果文档是普通文本或结构清晰的办公文件，主要变量通常是解析和嵌入；如果是扫描 PDF、图片表格或复杂版式，OCR、页面渲染和视觉模型可能成为主要成本来源。官方 DocReader 说明中，gRPC 工作线程默认值为 4，扫描 PDF 默认渲染 DPI 为 200，JPEG 质量默认值为 85；这些不是你的最终配置，而是估算解析并发与临时文件处理资源时可以核对的基准变量。详见官方 DocReader 环境变量说明。
增量同步不能按全量导入计算。你需要单独记录：
增量处理成本 = 新增文件 + 被修改文件 + 删除与回收任务 + 受影响分块的重新嵌入 + 索引更新
如果一个知识库每天只有少量文档变化，定时增量同步通常比频繁全量重建更容易控制预算；如果分块规则、嵌入模型或元数据过滤条件发生变化，则可能需要重建更大范围的索引。版本回滚也不是“零成本操作”，因为回滚后可能仍需重新生成分块和索引。官方项目说明已经包含分块编辑、版本历史、差异比较和索引重建能力，因此预算中应预留维护操作，而不是只计算首次上传。
大批量重建应使用峰值预算：
重建峰值资源 = 同时处理的文件数 × 单文件解析资源 + 批处理嵌入请求 + 索引写入峰值 + 临时存储空间
你可以把任务拆成低峰运行，并限制解析并发；否则应用问答与索引任务会争用 CPU、内存、磁盘 I/O 和模型调用额度。项目的 .env.example 还区分了数据库、Redis、对象存储、向量库、知识图谱、模型和文档解析等配置组，说明这些资源不能被合并成一个模糊的“服务器成本”。可进一步核对官方环境变量模板。
RAG 问答与检索
如何为 WeKnora 的 RAG 知识库建立预算模型？
先把一次问答拆成请求链，而不是只看最后一次生成：
单次 RAG 成本 = 查询嵌入 + 关键词检索 + 向量检索 + 重排 + 上下文拼接 + 生成模型 + 日志与追踪
向量检索本身可能没有独立的模型调用费用，但会消耗数据库 CPU、内存、磁盘和网络；如果同时使用语义检索与关键词检索，还要承担更多索引、查询和结果融合工作。混合检索的基本逻辑是同时使用语义向量和词法匹配，再合并候选结果，具体机制可参考向量检索官方混合搜索文档。
重排也需要单独计入。较稳妥的做法是先用较快的检索方式取得候选集，再对较小候选集进行更深层排序，而不是让昂贵模型扫描整个知识库。官方重排示例明确展示了密集向量、稀疏向量和后续重排的多阶段流程。
你至少要为每种业务场景记录以下变量：
- 每日查询次数
Q； - 平均输入上下文长度
T_in； - 平均输出长度
T_out； - 每次查询的检索路数
R； - 重排候选数量
K； - 并发峰值
C； - 失败重试率
F； - 需要引用原文、图片或附件的比例。
因此，模型调用部分可以写成：
月度模型消耗 = Q ×（输入上下文 + 输出内容）× 重试修正系数
而向量数据库部分更适合写成：
检索资源 = 查询量 × 检索路径数 + 写入量 × 索引更新开销 + 存储容量 × 副本与备份系数
不要直接把向量维度、文档数量或 Top-K 当成固定价格。它们只能作为容量估算变量，实际账单还取决于数据库部署方式、索引策略、过滤字段和副本配置。生产环境前，应使用自己的问题集评估混合检索是否真的提高命中率，因为重排会增加计算开销。生产检查说明也建议在容量规划中单独考虑重排向量的磁盘与内存占用。
Agent、MCP 与自动 Wiki
Agent 的成本通常高于普通 RAG 问答，因为一次用户请求可能变成多轮推理和多次工具调用。
建议使用这个公式：
单个 Agent 任务成本 = 基础推理 + 工具调用次数 × 工具平均消耗 + 沙箱执行时间 + 失败重试 + 最终总结生成
你可以把任务分成三档：
- 平均任务：检索知识库、读取少量文档、生成一次答案；
- 复杂任务：多次检索、调用 MCP、访问外部数据、整理多个来源；
- 失败任务：工具超时、权限不足、返回格式错误或模型重复尝试。
自动 Wiki 还会增加结构化整理、页面生成、交叉链接和后续更新成本。它更像一个持续运行的内容生产任务，而不是一次性导入动作。若文档频繁变化，Wiki 生成与版本维护可能重复消耗模型和检索资源。
沙箱需要单独做安全和容量预算。官方 Compose 配置说明特别提示，Docker 沙箱默认关闭，因为暴露宿主机 docker.sock 等同于给予宿主机级别的高风险权限；启用沙箱前，你必须单独设计网络策略、文件挂载、凭据注入、超时和清理机制。官方沙箱文档还说明了空间级、个人级变量和技能变量的不同作用范围。
模型调用、向量检索和存储资源应该怎样分别记账？
把模型和存储分开记账：
- 模型部分按输入、输出、嵌入、重排、OCR、VLM 和失败重试记录；
- 向量部分按原始文件、解析中间产物、分块文本、向量、元数据、索引、副本和备份记录；
- Agent 部分再增加 MCP、搜索、沙箱和人工复核；
- 运维部分记录日志保留、监控、告警、升级、备份恢复和权限审计。
这样即使更换模型供应商或数据库，也不会推倒整个预算模型。
本地、云端与混合部署
选择内网、本地、云端还是混合架构时，应该看哪些条件？
你可以按三个条件做判断，而不是简单选择“便宜的一边”。
✅ 若数据敏感度高、团队规模小、并发较低，先选本地或内网部署。优点是数据边界清晰、试验成本容易控制；缺点是你要自己负责模型接入、备份、升级、监控和故障恢复。
✅ 若需要远程访问、持续运行、多人协作或 Agent 长任务，选择云端常驻环境。优点是访问稳定、扩容更直接；缺点是常驻计算、网络流量、日志和外部模型调用会持续产生开销。
✅ 若原始文档必须留在内网，但产品需要云端推理或远程工作区，选择混合架构。此时要重点预算跨网络传输、鉴权、缓存、脱敏、连接稳定性和故障回退。
官方项目支持 Docker Compose，也提供独立服务与可选组件配置；但“能启动”不等于“适合生产”。你还需要验证对象存储、数据库、向量索引、外部模型、MCP 服务和沙箱是否位于同一信任边界。官方 Docker Compose 配置适合用来核对服务组成，不应被当成固定生产规格。
如果你要先做小规模验证，可以使用本地环境跑通文档导入、检索、引用和权限链路，再根据实际查询日志迁移到云端。需要远程 Mac 或云端开发工作区时，可先阅读 Macstripe 帮助中心，确认远程访问、环境交付和使用边界，再决定是否把开发验证环境与生产知识库分开。
上线前的预算护栏
上线前建议先写死这些限制：
- 每个用户或团队的每日查询配额；
- 单次问答最大上下文长度；
- 单个 Agent 任务允许的最大工具调用次数；
- 网页搜索、MCP 和沙箱是否默认开启；
- 沙箱最大执行时间、最大文件大小和网络访问范围；
- 失败重试次数与指数退避规则；
- 自动 Wiki 的生成频率和人工审核节点；
- 日志、原始文件和临时产物的保留周期；
- 文档删除后的索引清理与备份回收策略。
每周复盘一次，至少保留以下字段：
文档新增量｜修改量｜分块数量｜嵌入调用量｜查询量｜平均上下文｜平均工具调用｜失败率｜重试量｜沙箱执行时间｜存储增长｜人工处理时间
当查询量增长但文档量不变，优先检查问答模型、上下文长度、重排和重试；当存储增长但查询量不变，优先检查版本保留、临时文件、索引副本和 Wiki 快照；当 CPU 峰值只出现在同步时段，则优先调整批处理窗口，而不是立刻扩大常驻机器。
若满足以下条件，则可以先本地验证，否则回退到云端或混合部署：
- 若数据不出内网、并发可控、团队有人维护 Docker 和备份，则先本地部署；
- 若需要多人远程访问、持续运行和 Agent 长任务，则选云端常驻；
- 若敏感文档不能离开内网，但外部模型或远程工作区不可避免，则选混合部署；
- 若你还没有可观测性和失败回放能力，不要直接开启自动 Wiki、MCP 写操作和高权限沙箱；
- 若每周查询、文档更新和失败率都没有记录，先补日志和变量表，再讨论扩容。
你可以把这套变量复制到项目评审文档中，并结合Macstripe 配置与下单页面评估临时开发环境是否需要独立隔离。这里的重点不是提前猜出一个固定金额，而是让每个金额都能追溯到具体任务、资源和使用量。
如果你当前采用的是一台长期闲置的本地机器，常见缺点是远程访问不稳定、扩容需要重新采购、环境交付依赖人工，而且 Agent 沙箱和多服务并行会与日常开发争抢资源。直接租用一套 Mac 工作区并不适合所有生产场景，尤其不适合需要长期稳定重负载或物理接口的部署；但对于短期验证、模型接入、RAG 调试、远程协作和 WeKnora 的云端 Agent 运行，Macstripe 的临时环境通常比维护一台闲置机器更容易按项目周期控制成本。
