这三条不是功能列表，是我们在架构上做出的取舍。
Postgres 同时承担数据存储、任务队列与跨进程消息通道，不使用 Redis。 对需要部署到客户内网、走安全评审、运维人力有限的场景， 每少一个中间件，就少一轮评审、少一份运维手册、少一个故障点。
Agent 不会直接执行不可逆的业务动作。以创建工单为例， Agent 只能拟定工单，必须由人工确认后才会真正创建。 会话中也可以随时转人工接管。
Agent 配置采用草稿 / 发布 / 回滚三态，可对比版本差异； 模型调用有配额与计量，运行有完整事件日志，操作有审计记录。
以下按使用者的关注点组织，而非按系统模块划分。
配置并发布 Agent，通过异步 ReAct 循环完成推理与工具调用，支持最大轮次与工具数量限制。
接入文档、配置分片、预览内容、构建向量索引，并测试检索效果。
管理 Chat、Embedding、Rerank 等模型的连接与版本化方案，支持任意 OpenAI 兼容服务。
注册业务 API，管理调用凭据、参数校验与执行权限，支持只读与写入两类副作用。
会话接管、工单拟定与确认，让需要后续处理的问题进入服务流程。
通过嵌入组件、渠道接口与开放平台 API，把客服能力接入业务系统。
查看执行记录、工具调用与评估结果，辅助排查问题与持续改进。
多租户隔离、角色权限、模型调用配额与用量计量、敏感词审核。
应用与密钥管理、签名 Webhook 与重试、幂等键、SSE 流式输出、调用日志。
我们更希望你早点知道它不适合你，而不是部署完才发现。
| 维度 | NexusDesk | 通用 LLM 应用平台 | 知识库问答平台 | 开源客服工单系统 |
|---|---|---|---|---|
| 定位 | 客服与服务协同 | 通用应用编排 | 知识库问答 | 人工客服工单 |
| 工单与人工接管闭环 | 内置 | 需自行搭建 | 需自行搭建 | 内置 |
| 写操作需人工确认 | 内置 | 需自行实现 | 需自行实现 | 不适用 |
| Redis 是否必需 | 不需要 | 需要 | 需要 | 需要 |
| Agent 版本化与回滚 | 内置 | 部分支持 | 部分支持 | 不适用 |
| 模型调用配额与计量 | 内置 | 部分支持 | 部分支持 | 不适用 |
| 许可证 | Apache-2.0 | 见各自仓库 | 见各自仓库 | 见各自仓库 |
同类项目的信息以其官方文档为准，建议自行核对；本表仅用于说明设计取向的差异，不构成对任何产品的评价。
我们还没有可以署名的客户案例，所以不打算用「行业领先」这类词。 能提供的是另一件事：全部代码公开、可审计、可自行部署验证。 架构是否合理、有没有暗中收费的依赖、数据会不会离开你的网络 —— 都可以自己确认。
关于项目现状，需要如实说明：
项目处于持续开发阶段，已具备可运行的客服核心流程，但 尚未达到「开箱即用的生产可用」程度。 知识检索质量、大文档处理、任务恢复能力等仍在验证中； 可观测性、备份恢复与容量验证也还在完善。
我们会把功能现状与规划分开说明，不把路线图当作已交付能力。 部署验证范围见仓库中的验证记录。
遇到问题欢迎直接提问。 无论是部署卡住、能力判断，还是「这个场景你们能不能做」， 都可以通过 联系我们 提出。