Vedaksha

Vedaksha：Rust 星历与吠陀占星（Jyotish）引擎

面向开发 kundli（kundali）应用、panchang 日历和 AI Agent 的开发者。 计算本命盘、dashas、vargas、shadbala 和 panchanga，采用与 JPL Horizons 平均黄经误差仅 0.096″ 的星历；支持 Rust、Python 和 WebAssembly，并提供 17 个 MCP 工具。洁净室实现：每种算法均可追溯到原始资料。采用 BUSL-1.1 许可，可获取源代码，无 AGPL 义务；每个版本发布四年后转为 Apache-2.0。

网站 · 文档 · 演练场 · API 参考 · 博客

洁净室实现 · 与 JPL Horizons 的平均黄经误差为 0.096″ · 1,603 项测试（每次推送）+ 24,350 条基准行 · 原生支持 MCP · BUSL-1.1 → Apache 2.0

安装 · 快速开始 · 准确度 · 包含内容 · MCP + 属性图 · 来源 · 常见问题 · 许可

---

安装

平台	安装	备注
Rust	cargo add vedaksha	完整处理流程
Python	pip install vedaksha	引擎通过 WebAssembly 运行，py3-none-any，Python ≥ 3.9——无需 Rust 工具链
WASM	npm install vedaksha-wasm	浏览器和边缘环境，无需数据文件
MCP	cargo install vedaksha-mcp	stdio + HTTP（Bearer 身份验证）
Docker	docker run -e VEDAKSHA_MCP_TOKEN=… -p 3100:3100 ghcr.io/arthiqlabs/vedaksha-mcp	多架构（amd64 + arm64）

使用精度优于角秒的星历（JPL DE440s/DE441，与 Horizons 的最坏误差为 0.272″），或不含数据文件的 VSOP87A + ELP/MPP02 系列（1900–2025 年间平均误差为 0.160″，最坏误差为 1.473″），计算 janam kundali（本命盘）、panchanga、dashas、nakshatras、vargas、shadbala、ashtakavarga、muhurta 和 transits/gochara。

flowchart LR
  K["JPL DE440s / DE441<br/>SPK kernel, ~31 MB"] --> E
  V["VSOP87A + ELP/MPP02<br/>compiled to constants,<br/>no data files"] --> E
  E["Ephemeris core<br/>precession · nutation<br/>light-time · deflection · ΔT"] --> W["Western<br/>houses · aspects<br/>dignities"]
  E --> J["Jyotish<br/>nakshatras · dashas · vargas<br/>panchanga · shadbala · muhurta"]
  W --> C["ComputedChart"]
  J --> C
  C --> G["Property graph<br/>Cypher · SurrealQL<br/>JSON-LD · RAG text"]
  C --> M["MCP server<br/>17 tools · stdio + HTTP"]
  C --> S["Rust · Python · WASM"]

快速开始

Python（pip install vedaksha）：恒星黄道（Lahiri）整宫制星盘，即 kundli。

from vedaksha import Vedaksha

vk = Vedaksha()
chart = vk.natal_chart(julian_day=2451545.0, latitude=28.6139, longitude=77.2090,
                       ayanamsha="IndianOfficial", house_system="WholeSign")
print(chart["houses"]["asc"], [(p["name"], p["sign"]) for p in chart["planets"]])

Rust（cargo add vedaksha）：

use vedaksha::prelude::*;

fn main() {
    // 2024-03-20 12:00 UT1. The day is a fraction: noon on the 20th is 20.5.
    let jd = calendar_to_jd(2024, 3, 20.5);
    let moon = apparent_position(&AnalyticalProvider, Body::Moon, jd).expect("in range");
    println!("Moon {:.4}°", moon.ecliptic.longitude.to_degrees());
}

包含宫位和恒星黄道的完整星盘，是 crates/vedaksha/src/lib.rs 中编译的 doctest。

浏览器中的 JavaScript（npm install vedaksha-wasm；无需数据文件）：

import init, { compute_natal_chart } from "vedaksha-wasm";

await init();
const chart = JSON.parse(compute_natal_chart(JSON.stringify({
  year: 2024, month: 3, day: 20, hour: 12, minute: 0,   // UTC
  latitude: 28.6139, longitude: 77.2090,
  ayanamsha: "IndianOfficial", house_system: "WholeSign",
})));

MCP（Claude Desktop 的 claude_desktop_config.json、Cursor 的 .cursor/mcp.json，或任何 stdio MCP 客户端）：

{
  "mcpServers": {
    "vedaksha": {
      "command": "docker",
      "args": ["run", "--rm", "-i", "ghcr.io/arthiqlabs/vedaksha-mcp", "--stdio"]
    }
  }
}

不使用 Docker 时，可运行 cargo install vedaksha-mcp，并设置 "command": "vedaksha-mcp"，不带参数；也可运行 pip install vedaksha，并以相同方式使用 vedaksha-mcp。

公共接口中的所有 Julian Day 均为 UT1，不是 TT，也不是 TDB。引擎会在内部转换为 TT 以计算动力学项，并使用 UT1 计算地球自转，从而确定上升点、MC 和全部十二个宫头。传入 TDB Julian Day 会增加 ΔT 对应的自转量，而不是将其扣除——以当前 ΔT ≈ 69 s 计，每个宫头都会偏差 0.289°（17.3′）。有两个例外，其名称明确标示了这一点：直接索引内核的原始 SPK 查询（state_vector）使用 TDB；Python 绑定的 analytical_position(body, julian_day_tt) 使用 TT。

准确度

这些数值可复现，并非凭空声称：vedaksha-parity 是一个独立的测试工具（由本引擎的同一批作者维护），任何人都可以用它针对自己持有的参考内核副本运行测试，核验下文公布的数值。

每个数值都由一个具名测试打印。运行 bash scripts/download_de440s.sh，然后运行 cargo test -p vedaksha-ephem-core --release -- --include-ignored --nocapture，即可复现星历表；岁差章动交角数值来自 cargo test -p vedaksha-astro sidereal，而使用 cargo test -p vedaksha-astro --test ayanamsha_fixture，可对照同一组主要数值的独立 Python 推导结果。

标题中的 0.096″ 精确衡量什么。 它是平均地心视黄经残差，并非一般的位置精度数值：夹具还包含 ref_latitude、ref_distance 和 ref_speed，但 oracle_comparison.rs 将它们标记为 dead_code，三者都不计入此数值。它涵盖 1900–2025 年的记录，每个天体有 1,535 次比较（10 个天体共 15,350 次）。覆盖 1900–2100 年的完整网格共 24,350 条记录，平均值为 0.088″，且最差记录相同（见下文）；保留 1900–2025 年这个范围，是为了不改变已发布的数量和定义。此外，比较对象是行星系统质心，而非行星的物理中心，这与 DE440s 内核存储的内容以及 SpkReader 返回的结果一致；若改为查询行星中心，外行星会产生约 0.1″ 的虚假偏移（scripts/generate_horizons_oracle.py）——这与标题中的平均值本身处于同一量级。这些信息也作为数据发布在 metrics.json 的 accuracy 区块中（quantity、era、targetConvention），因此网站会直接呈现这些信息，无需任何人手动复制这段文字。

SpkReader 与 JPL Horizons（DE441）的对比——oracle_comparison.rs，24,350 条已提交记录（10 个天体 × 2,435 个日期，1900–2100 年）。Horizons 使用 DE441，因此此项测试衡量的是我们的 DE440s 流程与独立内核之间的差异。

年代	比较次数	平均值	最大值
1900–2025	15,350	0.096″	0.272″（月球，1962-01-06）
1900–2100（全部）	24,350	0.088″	0.272″（月球，1962-01-06）

24,350 次比较的差异均小于 1 角秒。1900–2025 年各天体的平均值在 0.092″（月球）至 0.100″（冥王星）之间，每个天体的最差记录都在 0.243″ 至 0.272″ 之间。

时间尺度。 1962-01-20 之前，Horizons 的时间标签采用 UT1；从该日起改用 UTC。与 Horizons 自身的处理方式一样，oracle 会根据闰秒数量将 UTC 标签转换为 TT，并以 TT 读取引擎，因此这些记录的残差不涉及 ΔT 或 UT1 − UTC，oracle 在此也不说明 ΔT；更早的记录则经过引擎的 ΔT 处理。2026 年及之后的记录也采用相同方式进行比较，差异均小于 0.189″（月球，2099-10-04）。2033.75 之后以 UT1 表示的儒略日依赖外推的 ΔT（delta_t.rs）；ΔT 每偏差 1 秒，月球位置就会移动约 0.55″。

剩余 0.096″ 的来源。 1962 年之后，各天体的平均值在 0.047″ 至 0.054″ 之间，最大值不超过 0.062″；1962 年之前，各天体的平均值在 0.138″ 至 0.146″ 之间。所有天体都存在这一偏移：它来自 Horizons 使用的 IAU 1976/1980 岁差和章动模型与本引擎使用的 IAU 2006/2000B 模型之间的差异。这是约定上的差异，本引擎不会模拟它。最差记录是 1962-01-06 的月球，时间上位于两个节点之间：1962-01-01，本引擎的 ΔT 从 SMH2016 样条切换到 USNO 记录；以及 1962-01-20，Horizons 从 1962 年之前的序列切换到其地球定向文件。这两套序列在切换期间相差 0.371 秒，相当于月球黄经的 0.2″（delta_t.rs）。目前已计入太阳对行星造成的光线偏折；计入之前，最差记录为 1.187″（天王星，距太阳 0.36°）。 AnalyticalProvider 与 JPL Horizons 对比 — analytical_oracle.rs，1900–2025 年：总体平均误差 0.160″，最差情况 1.473″（海王星，2025-09-02）；月球通过 ELP/MPP02 得出的平均误差为 0.094″（1962 年后为 0.055″）。1900–2025 年间对 9 个天体进行了 13,815 次比较（每个天体 1,535 个日期）；详见 metrics.json 中的 accuracy.analytical 块。同一轮测试覆盖至 2100 年的全部 21,915 次比较，平均误差为 0.251″，最差情况为 2.248″（海王星，2078-01-27）；metrics.json 未发布这组数据。

按天体列出，因为平均值掩盖了一种值得了解的规律，选用此提供程序前应留意：

天体	平均误差″	天体	平均误差″
太阳	0.094	木星	0.148
月球	0.094	土星	0.159
水星	0.094	天王星	0.257
金星	0.094	海王星	0.410
火星	0.090

太阳、月球和内行星的误差集中在 0.090″ 至 0.094″ 的窄幅区间，之后误差随距离增大。以 1962-01-20 为界，此前九个天体的平均误差均在 0.131″ 至 0.153″ 之间，与 SPK 路径显示的框架偏移相同。此后，太阳和内行星的误差为 0.038″ 至 0.039″，月球为 0.055″，木星、土星、天王星和海王星则分别为 0.165″、0.165″、0.365″ 和 0.660″。

误差增大源于理论本身，而不是表格的截断方式。scripts/generate_vsop87a.py 会丢弃绝对振幅低于统一阈值 1e-7 AU 的项，但对完整、未截断的 VSOP87A 级数进行求值，所得外行星残差与已提交的表格结果在小数点后四位相同（在 1900–2100 年间，以 DE440s 为基准，对几何日心矢量进行测量；表格见 crates/vedaksha-ephem-core/src/analytical/mod.rs 中 VSOP87A_TO_EQUATORIAL 的注释）。该理论的作者是基于 JPL 积分 DE200 拟合的，而非 DE440（vsop87.doc 中的 “PRECISION” 部分），残差反映的正是这一点。如果需要外行星的误差低于 0.1″，请使用 SpkReader；此时外行星的误差不比内行星高：木星和土星对比同一参照数据的平均误差为 0.096″，与其他所有天体 0.092″ 至 0.100″ 的误差区间相当。

在 2026-08-20 之前，这些数据是平均误差 2.06″、最差情况 24.22″；本 README 将差距归因于 VSOP87A 是一种截断理论。这种说法并不正确，而且掩盖了我们的缺陷：分析提供程序对 EarthMoonBarycenter 的响应使用了 VSOP87A 的地心级数，导致观测者偏离 4,671 km；此外，earth_state 将相对于地月质心的月球位置除以 1 + EMRAT，而不是 EMRAT，又造成了 56.8 km 的偏差。两处问题均已修复。第二处修复也影响了 SPK 路径，误差从 0.106″ 降至 0.103″。

在 v10.0.0 中，SPK 平均误差从 0.103″ 降至 0.096″，最差行从 1.187″ 降至 0.272″；分析路径的平均误差从 0.239″ 降至 0.160″，最差行从 1.896″ 降至 1.473″；分析路径的月球误差从 0.169″ 降至 0.094″。有一个天体的最大误差变大：分析路径的天王星，从 1.111″ 升至 1.201″。原因详见 CHANGELOG-v10.0.0.md：根据测量值和已发布的预测值读取 ΔT、修正 30 行章动数据、计算太阳对行星的光偏折、按照 VSOP87A 作者发布的矩阵旋转 VSOP87A，以及用一个按 TT 时制比较 Horizons UTC 标记的参照程序。

ELP/MPP02 月球 — lunar_horizons.rs：J2000 时为 0.015″，公元 1500–2500 年间为 0.020–0.053″。

未测量的内容

• 宫位 cusp 未根据任何外部参考进行验证。
• 没有将任何一个 ayanamsha 与另一种实现进行验证，这是有意为之。 这 11 种方法都是从一手来源推导出来的——章节、委员会、提案者自己的论文或星表——并且每种方法都能以 1e-9° 的精度复现其自身基准；若其一手资料记载了零年，也会复现该零年。我们并未声称与其他人的数值一致：拿来比较会重蹈逆向工程，而本次重新推导正是为了摆脱这种做法。参见 docs/audit/2026-08-17-ayanamsha-cleanroom/。
• Dasha、nakshatra 和 shadbala 测试核验的是文本自身的规则，而不是与外部结果进行比较：它们验证 BPHS 常数之和为 120 年、边界能够铺满整个圆周，以及手工计算 shadbala 各部分时，结果符合经文给出的公式。没有将任何 dasha 周期或 shadbala 数值与另一种实现的输出进行比较。
• 该库的粗略 shadbala 形式并不完整。 compute_shadbala_full 包含 Sthana Bala 五个部分中的四个（Uchcha、Ojhayugma、Kendradi 和 Drekkana，不含 Saptavargaja），以及 Kala Bala 中的 Nathonnata 和 Paksha，并以 0 或 30 为步进；其 Cheshta、Dig 和 Drik 等级并非经文所述。完整形式 compute_shadbala_complete（BPHS 27，逐部分计算，并在文本未明确参数时提供选项）由 MCP compute_shadbala 工具和 WASM 导出提供。

技术报告

有关两条星历计算流水线、测量精度以及每种算法的洁净室来源的完整说明：docs/paper/main.tex（使用 make -C docs/paper pdf 构建，需要 tectonic）。

报告的内容远超上述摘要，并披露了其他地方均未提及的几项内容：

• 与两个国家机构的星历进行交叉验证，由同一批作者维护的独立校验工具进行测量（并非第三方工具）；数据来自两个不同机构（JPL DE440 和 IMCCE INPOP21a），而不只是与 JPL 的结果进行比对。
• 1550–2650 CE 期间分析路径的精度，按天体和距 J2000 的世纪区间分别报告；比较双方均采用 TT，从而消除时间尺度差异，避免 ΔT 偏差影响残差。
• SPK 读取器的组件级验证，将其与另一种实现对可比内核的读取结果进行比对，从而将 DAF/SPK 解析器和 Chebyshev 计算与其上层的视位置流水线区分开来。
• 关于可复现性的方法说明：位级输出受架构限制，因为 SIMD 三角函数内核在一种 AVX2 寄存器上运行，而在 NEON 上则使用两个寄存器。但精度不受影响——两种架构上的测量结果均精确到毫角秒。（自 v10.0.0 起，只有月球级数不再调用该内核，因此在两种架构上的结果位级一致；整个分析型提供器仍不一致。）
• 明确说明未验证的内容，包括宫位 cusp、真交点和所有 ayanamsha。

状态：未经同行评审，也未向任何机构投稿。 这是一份技术报告，而非预印本。报告中的每项测量数据都仅适用于其标题页所注明的引擎版本。

内容

两个星历提供程序。 SpkReader 读取 JPL DE440s（约 31 MB），用于亚角秒级计算。AnalyticalProvider 将 VSOP87A + ELP/MPP02 编译为常量，无需数据文件，适用于 WASM、边缘环境和 Cloudflare Workers。ChebyshevProvider 是可选提供程序，按分段用切比雪夫多项式拟合相同的级数（在整个范围内，月球误差不超过 0.1 m，行星误差不超过 3 m），适用于需要计算许多相近时刻的工作负载；AnalyticalProvider 仍使用精确级数。

速度。 在一台 Apple M5 Pro 上（Criterion 中位数，v10.0.0）：解析月球计算耗时 56 µs，九个天体的视位置星盘耗时 0.97 ms，太阳计算耗时 2.9 µs；分别比 v9.4.1 快 3.3、3.8 和 2.1 倍。通过 MCP 执行 20 次为期 30 天的 muhurta 搜索和 5 次为期一年的行运扫描耗时 0.46 s，而 v9.4.1 耗时 17.5 s。级数均经过完整求值，唯一的插值路径（扫描读取的遍历结果）与直接计算的误差小于 5e-5″；计算方式和完整表格见 CHANGELOG-v10.0.0.md。

源自原始文献的 Jyotish。 27 个 nakshatra，包含 pada 和主星 · 8 种 dasha 系统（Vimshottari、Ashtottari 和 Yogini，后者可运行超过首轮；以及 Chara、Narayana、Sthira、Niryana Shoola 和 Maheshwara 等 rashi dasha）· 全部 16 个 varga（D-1 → D-60）· BPHS 27 的完整 shadbala，包含 Ishta/Kashta phala、bhava bala（27.26 至 31）和 vimshopaka bala（全部四种方案）· 11 种 ayanamsha，均可追溯至某一章节、恒星或委员会 · panchanga 的五个部分，vara 按当地日出计算，Rahu/Gulika Kalam 作为实际时间窗口处理 · 按 BPHS 第 26 章计算分级且按度数细分的（sputa）drishti · 四个 upagraha（Kala、Mrityu、Ardhaprahara、Yamaghantaka）· 平均、真值和密切节点，均以日期对应的黄道面为基准；J2000 变体与 DE441 的 OM 一致，误差为 0.6″（可用于 KP 副主星）。

天空事件，位于 vedaksha-vedic crate 中。 日食和月食、指定范围内 graha 的每次入宫和逆行转折、依据 Surya Siddhanta 的 kalamsha 计算的偕日升和偕日落、包含 adhika 和 kshaya 的 amanta 与 purnimanta 太阴月，以及按 Julian Day 分辨率计时的 tithi、nakshatra、karana、yoga 结束时刻和 sankranti。长时间扫描会从插值遍历中读取月球和太阳（walk::BodyWalk、vedaksha_vedic::walked::WalkedSky），与直接计算相比，月球误差小于 5e-5″，太阳误差小于 1e-5″；行星不使用遍历。

西方占星：计算，而非解读。 10 种宫位系统、带顺行／分离运动的主要相位、基本尊贵度、合盘和组合盘。ChartConfig 默认采用热带黄道。没有西方占星解读层，也不与 Jyotish 功能对等。

Crate，同步发布到 crates.io：vedaksha（总入口，支持 7 种语言环境）· -math · -ephem-core · -astro · -vedic · -graph · -mcp。

MCP + 属性图

17 个工具，可通过一次 tools/list 发现。目录由 Rust 定义生成，并通过快照测试锁定，因此不会在代码发生变化时悄然偏离。compute_dasha 支持上述八种大运系统。compute_shadbala 接收一个时间和地点（julian_day、latitude、longitude 和一个恒星 ayanamsha），自行排盘，并返回七颗 graha 的 BPHS 27 全部组成部分。

compute_natal_chart · compute_dasha · compute_vargas · compute_karakas · compute_combustion · compute_shadbala · compute_ashtakavarga · compute_transit · compute_gochara · search_transits · search_muhurta · compute_panchanga · compute_drishti · compute_bhavas · compute_synastry · compute_composite · emit_graph

任何星盘都可以通过 emit_graph 或 vedaksha_graph::chart_to_graph 转换为属性图，并输出 Cypher、SurrealQL、JSON-LD、JSON 或 RAG 嵌入文本。Agent 随后可以通过图查询询问“哪些行星与第 7 宫宫主成相位？”，而无需重新实现星盘逻辑。计算本身返回类型化结构体；图则是按需生成的投影。

**星盘实际生成的内容：**本体的 9 种节点类型中有 4 种（Chart、Planet、Sign、House），12 种边类型中有 7 种。Nakshatra、Pada、Pattern、DashaPeriod 和 FixedStar 在 vedaksha_graph::ontology 中有定义，但不会从 ComputedChart 构建，因为其中不包含它们所需的数据。请通过各自的 API 进行计算。

VEDAKSHA_MCP_TOKEN=… vedaksha-mcp --http --port 3100

HTTP 模式要求每个 POST 请求都包含 Authorization: Bearer <token>，并且在未设置 VEDAKSHA_MCP_TOKEN 时拒绝启动，除非你使用 --insecure-no-auth 并运行于可信网络中。/health 和提供信息的 GET 请求保持开放。

洁净室溯源

每个已实现的算法都带有 // Source: 文档注释，注明其主要论文或论著——VSOP87A、ELP/MPP02、IAU 标准、BPHS、Jaimini。两个子系统在有记录的隔离环境中根据一手资料重新推导，并各自附带审计目录：月球理论（2026-05-09）和恒星表面（2026-08-17）。每个目录都记录了原始资料、流程、检索和排除的内容，以及一个可重新推导数值的生成器，因此可以重新验证这项声明，而非盲目信任。另请参阅 DATA_PROVENANCE.md。这是 BUSL-1.1 被许可方可审计的证据。

已投入生产

产品	介绍
kundalimcp.com	面向 Agentic-AI Jyotish 的 MCP，提供完整计算套件。直接基于 vedaksha-* crate 构建。
kundali.live	面向消费者的服务端点——提供聊天式解读和自助 PDF 报告。

常见问题

Vedaksha 是什么？

一个用于天文星历和吠陀占星术（Jyotish）的 Rust 引擎，提供 Python 和 WebAssembly 绑定，以及一个包含 17 个工具、供 AI Agent 使用的 MCP 服务。它可计算行星位置、本命星盘、panchanga、大运、分盘和 shadbala。

它能计算 kundli（kundali、janam kundali）吗？

可以。传入恒星黄道 ayanamsha，例如 IndianOfficial（Lahiri），并搭配一种宫位系统，例如 WholeSign。MCP 工具和 Python 绑定默认使用回归黄道，因此计算 kundli 时必须指定 ayanamsha；WASM compute_natal_chart 默认使用 IndianOfficial。

使用免费吗？它采用 AGPL 许可吗？

它不采用 AGPL，也不包含任何 AGPL 代码。它采用 BUSL-1.1 提供源代码：非商业用途免费；商业用途（向外部客户提供可产生收入的产品或服务）需要支付一次性许可费，每个组织 USD $500，涵盖该版本及后续所有版本。每个版本在发布四年后转换为 Apache-2.0。BUSL 不是 OSI 开源许可证。

需要星历数据文件吗？

不需要。AnalyticalProvider 会计算编译进二进制文件的 VSOP87A 和 ELP/MPP02，WASM 包和 MCP 服务都使用这些数据。SpkReader 会读取 JPL DE440s 内核（约 31 MB，由 scripts/download_de440s.sh 获取），以实现最高精度。

精度如何？

与 1900 至 2025 年间的 JPL Horizons 数据相比，在视地心黄经方面，SPK 路径的平均误差为 0.096″，最差为 0.272″；分析路径的平均误差为 0.160″，最差为 1.473″。宫头尚未与外部参考数据进行验证；请参阅精度。

支持哪些 ayanamsha 和 dasha 系统？

支持 11 种各自源自主要来源的 ayanamsha，以及 8 种 dasha 系统：Vimshottari、Ashtottari、Yogini、Chara、Narayana、Sthira、Niryana Shoola 和 Maheshwara。

AI Agent 可以使用它吗？

可以。MCP 服务通过 stdio 或 HTTP 运行，并已列入官方 MCP Registry，名称为 io.github.arthiqlabs/vedaksha-vedic-astrology。客户端配置请参阅快速入门。

许可证

Business Source License 1.1 — SPDX BUSL-1.1，crates.io、PyPI 和 npm 上显示的许可证。

• 非商业用途 — 免费（个人、研究、教育、内部工具）。
• 商业用途 — 每个组织一次性收费 $500。产品和席位数量不限，永久有效，涵盖您获得许可的版本及之后发布的所有版本——后续版本无需再次付费。购买 →
• 每个版本发布四年后，转换为 Apache 2.0。该未来许可证 文本保存在 CHANGE-LICENSE.txt 中——根据 BUSL 条款，它是变更许可证，而非您现在可以选择的许可证。

请参阅 LICENSE、SECURITY.md、CONTRIBUTING.md 和 MAINTENANCE.md。

---

版权所有 © 2026 ArthIQ Labs LLC · 依据 Business Source License 1.1（BUSL-1.1）授权。