COHAO 原本已经有一个自研的创世申请工作台，但它不具备完整内容社区所需的账号、主题、回复、搜索、通知、举报和审核体验。继续从零开发，会把时间花在重复建设基础能力，而不是内容与关系。 因此我们选择 NodeBB 作为当前社区底座，并保留旧工作台、SQLite 数据、备份和发布目录作为回滚与运营资料。 当前采用的版本与部署 NodeBB v4.14.10，核验日期 2026-08-15。 PostgreSQL 单机数据库，NodeBB 单实例运行。 应用只监听服务器回环地址，由现有 Nginx 和 TLS 对外提供服务。 开放注册，不强制邮箱；新账号第一次内容进入人工审核。 暂时关闭私聊、私有群组和 ActivityPub，降低创世期审核面。 为什么适合现在 已有成熟的主题、回复、标签、搜索、书签、关注、通知、举报和审核队列。 Node.js 技术栈与现有项目接近，4 核、约 4GB 内存的服务器可以承载早期单实例。 REST API 和插件机制允许 Agent 以后通过窄接口辅助整理，但不需要给它数据库或管理员权限。 中文界面已经包含在官方发行版中。 当前限制 尚未配置 SMTP，所以邮件验证、通知和自助找回密码暂不可用。 首帖审核需要真人及时处理，不能靠 Agent 自动放行。 单实例适合创世期；扩容、多节点缓存和搜索增强要由真实负载触发。 选择成熟引擎不是把社区交给软件决定。栏目、文化、内容质量、权限和收入分配仍然由 COHAO 的公开制度负责。 参考： https://github.com/NodeBB/NodeBB/releases/tag/v4.14.10 https://docs.nodebb.org/ 编辑说明：2026-08-15，本文记录 COHAO 的真实技术选择；AI 协助起草，项目负责人复核。

RAG 项目常常一开始就选择向量数据库，但很多知识库问题其实来自分段、权限、版本和答案评测，而不是缺少一种更强的检索算法。 三种路径 关键词检索 适合错误码、型号、文件名、专有名词和精确短语。优点是可解释、成本低；缺点是对同义表达和自然语言问题不够敏感。 向量检索 适合语义相近但用词不同的内容。优点是召回更灵活；缺点是可能召回“主题相近但答案不对”的片段，也需要嵌入版本、索引和阈值管理。 混合检索 把关键词与向量结果合并，再用规则或重排模型排序。通常更稳，但系统复杂度、延迟和调试成本更高。 先做这四件事 建立真实问题集，并标注应该命中的文档和答案。 给文档加版本、生效时间、所有者、权限和来源元数据。 设计分段，使每个片段足够独立，又保留标题和上下文。 分别测召回、最终答案和拒答，不用“找到了相似内容”代替正确回答。 一个实用默认值 从关键词检索加少量语义召回开始；只有真实问题集证明召回不足时，再增加复杂重排。任何检索都必须在查询前做权限过滤或在可靠的安全边界内过滤，不能先把不该看的内容交给模型再要求它忘记。 编辑说明：2026-08-15，COHAO 编辑部依据 RAG 工程通用实践整理；AI 协助起草，项目负责人复核。

本地模型和托管 API 经常被写成价值观选择，实际系统更适合按任务和数据分层。 维度 本地模型 托管 API 混合架构 数据控制 可完全留在自有环境 取决于服务条款与配置 敏感任务本地，其余托管 前期投入 硬件、部署和运维较高 接入快，按用量付费 需要路由与两套运维 峰值弹性 受本地容量限制 通常更容易扩缩 可把峰值溢出到托管端 模型更新 自己决定升级节奏 能力更新快但可能变化 需要持续兼容性评测 故障类型 显存、驱动、量化与容量 限流、网络、区域与服务变化 路由错误和结果不一致增加 先按任务分类 固定格式抽取、分类和低风险批处理，可能适合本地小模型。 复杂推理、图像或最新能力，可能适合托管 API。 含高敏感数据且不能脱敏的任务，应先满足数据和合规边界，再比较质量。 关键业务不应只看平均质量，还要测试超时、限流、降级和人工接管。 混合架构最容易被低估的成本 同一任务在不同模型间的行为、格式和安全边界可能不一致。路由器需要版本化策略、回归评测、结果标记和失败回退，不能只依据“哪个便宜”随机切换。 结论不是三选一，而是给每类任务找到可解释的执行路径，并保留替换能力。 编辑说明：2026-08-15，本文是架构比较框架，不代表对任何具体服务的价格或能力作实时断言。AI 协助起草，项目负责人复核。

“哪个 Agent 框架最好”通常不是一个能脱离任务回答的问题。先把下面八个问题写清楚，候选范围往往会自动缩小。 任务是一次性编排还是长期状态机？ 一次调用几个工具与运行数小时、可暂停恢复的任务，需要的基础设施不同。 哪些动作有副作用？ 只读检索和付款、删除、公开发布不能使用同一权限模型。 是否需要人工确认与接管？ 确认必须能绑定对象和版本，并在恢复后继续。 状态保存在哪里？ Prompt、内存、数据库和事件日志分别承担什么角色。 怎样测试？ 能否替换模型、模拟工具超时、固定随机性并运行回归集。 怎样观测？ 是否记录每步输入摘要、工具调用、延迟、成本、错误和最终责任人。 部署约束是什么？ 语言、云、本地、数据边界、并发、冷启动和团队已有能力。 退出成本多大？ 工作流、工具协议和业务状态是否被锁在框架私有格式中。 一个保守的选择顺序 先用普通函数和明确状态完成单步工具调用。 确实需要循环、分支和恢复时，再引入图或工作流框架。 需要跨系统、跨团队协作时，优先使用开放接口封装工具与消息，不把业务对象塞进框架内部状态。 评测框架时，用同一组真实任务比较完成率、人工接管、重复执行、调试时间和迁移难度。演示代码短不等于生产总成本低。 编辑说明：2026-08-15，本文提供中立选型维度，不构成对某个具体框架的当前排名。AI 协助起草，项目负责人复核。