开发者

为知识系统建立稳定的边界。

Jonex 把浏览器访问、共享治理、业务能力、领域编排和原子引擎分离开，让每一层都能以清晰的契约演进。

查看 GitHub

快速上手路径

走一遍完整的知识工作流。

代码仓库是安装配置和当前实现细节的事实来源。下面这个顺序展示了各个产品组件如何连接。

运行平台

启动所需的 Docker Compose profile，并检查网关和能力健康检查。

定义领域

创建或选择一个领域空间，然后创建知识库并选择它的解析器画像。

连接数据源

上传文件，或配置受支持的 REST API、MinIO 或 S3 数据源、带签名的入站推送。

编译知识

在文档生命周期中跟踪解析和本体编译进度。

搜索与复核

查询一个或多个知识库，检查结构化引用并记录反馈。

请求路径

唯一的公共 API 界面，背后是受治理的能力。

浏览器停留在前端源站，网关和治理层保护内部服务边界。

01 / 浏览器

前端网关

提供外壳和应用，并只通过 /api/v1/** 发送业务请求。

02 / 路由

API 网关

聚合 HTTP 路由并转发调用，不接管业务编排。

03 / 治理

Sidecar

处理认证、租户上下文、内部身份、计量、限流、弹性和调用。

04 / 执行

能力服务

通过服务和仓储应用业务规则，数据按租户隔离。

05 / 编排

领域与原子客户端

在稳定边界之后组合检索、解析、本体、语言和其他技术引擎。

有据可查的响应

证据是契约的一部分。

本体感知搜索位于 POST /api/v1/knowledge-base/search/ontology。知识响应可以携带结构化引用数据，让消费方应用展示答案的来源。

示意性响应结构application/json

{
  "answer": "...",
  "references": [
    {
      "doc_id": "document-id",
      "file_name": "policy-manual.pdf",
      "media_type": "pdf",
      "raw_url": "signed-source-url",
      "locations": [
        { "type": "page", "page_no": 48 }
      ]
    }
  ]
}

实现规则

让系统保持一致的契约。

业务 API 使用统一的版本化浏览器前缀。
租户身份来自可信的认证上下文，而不是任意请求体。
网关路由与能力的业务规则保持分离。
服务拥有业务决策；仓储拥有持久化访问。
来源文件使用抽象化的对象存储，配合受控访问 URL。
检索路径一致地返回结构化引用。