NautilusTrader AI Agent 开发贡献指南工作规则、质量闸门与 PR 就绪流程【免费下载链接】nautilus_traderProduction-grade Rust-native trading engine with deterministic event-driven architecture项目地址: https://gitcode.com/GitHub_Trending/na/nautilus_trader本篇指南以 NautilusTrader 仓库根目录的 AGENTS.md 为骨架面向使用 AI 辅助工具参与该开源交易平台开发的贡献者尤其是 Agent 驱动的开发流程系统讲解仓库要求的工作规则、本地验证闸门、Git 交互边界与 AI 披露规范。读完本文你将掌握一套可直接落地的 Agent 贡献工作流在改动真实资金可触达的交易代码前如何约束行为、如何用make format/make pre-commit/make pre-flight把变更打磨到可评审状态以及如何在不越界、不伪造测试的前提下提交一个评审就绪的 Pull Request。为什么 NautilusTrader 需要一份面向 Agent 的指令文档NautilusTrader 是一个生产级的 Rust 原生交易引擎采用确定性事件驱动架构。仓库 README.md 与 CONTRIBUTING.md 反复强调一句核心事实NautilusTrader 可以执行涉及真实资金的实盘交易任何错误都可能造成财务损失。因此项目对正确性、可靠性、测试性、清晰度和可维护性设置了极高的标准并要求所有贡献无论是否使用 AI都达到同等质量。AGENTS.md 正是这一标准的制度化表达。它开篇要求任何改动前先阅读 AI_POLICY.md 与 CONTRIBUTING.md并遵守 docs/developer_guide/coding_standards.md 以及所改动领域对应的开发者指南。文档共分四大部分Working rules工作规则、Pull request readinessPR 就绪、Git and public interactionGit 与公共交互、Disclosure and attribution披露与归属。Working rulesAgent 的硬性工作纪律AGENTS.md 的第二部分列出所有贡献者必须遵守的底层规则这些规则约束的是改代码之前和改代码过程中的行为。先读代码、再提方案在提出或实施任何改动之前必须阅读受影响的代码并搜索仓库中已有的模式existing patterns。每个改动必须聚焦于请求的结果requested outcome发现无关问题时记录下来Note而不是顺手修复避免顺带重构drive-by refactors污染提交。这一规则与 CONTRIBUTING.md 的Start with an issue精神一致重大改动新特性、新集成、设计变更需要先在 issue 中与维护者达成一致只有类型、文档修正、范围明确的 bug 修复这类小而自包含的改动可以免于事先沟通。风格与依赖沿用既定模式匹配现有风格使用已确立的函数、类型、命名和依赖不引入自创抽象。具体风格细节缩进、命名、术语、提交信息格式以 docs/developer_guide/coding_standards.md 为准例如全部使用空格而非制表符、行宽一般不超过 100 字符、Rust 文档注释使用陈述语气indicative mood、错误变量统一命名为单字母eErr(e)/except SomeError as e:。uv 项目环境只用python/.venv仓库明确规定必须使用 uv 管理的 Python 项目环境位置固定为python/.venv禁止创建或使用根目录的.venv。运行 uv 项目命令时要么在python/目录下直接执行要么在仓库根目录加--project python参数。这与 docs/developer_guide/environment_setup.md 的环境布局完全对应uv 环境的默认项目布局就放在python/pyproject.toml旁边的python/.venvMake 目标和 CI 会自动选择该项目。如果旧 checkout 曾使用根目录.venv需要从 shell 启动文件和当前 shell 中移除任何UV_PROJECT_ENVIRONMENT导出因为该覆盖项优先于 uv 的项目发现。精确算术价格、数量与金额绝不容忍浮点误差对价格、数量、货币金额及其他离散数值必须保留精确算术使用项目的领域类型domain types或Decimal。这是交易系统的命脉。从源码结构看crates/model 中的Price、Quantity、Money等类型以及Decimal承担了这一职责Makefile 中专门设置了标准精度64-bit与高精度high-precisionu128宽度两条测试通道cargo-test-standard-precision与cargo-test-sim会在两种精度宽度下分别验证代码路径可见精度在项目中被当作一等公民对待。测试纪律不弱化、不绕过、不重写不得仅为通过测试而向生产代码添加仅测试用的行为、分支、属性或接口。不得削弱、移除、绕过或重写测试及其保护的行为来换取通过结果必须修复根本问题并保留测试要保护的既有行为。仅当任务有意改变所需行为、或你能独立验证测试本身有误时才允许修改测试。这条规则的仓库侧支撑来自 docs/developer_guide/testing.md项目的自动化测试被视作交易平台的可执行规格executable specifications测试与运行时契约构成同一套设计系统。Rust 测试统一使用#[rstest]包括非参数化用例Python 测试使用 pytest 风格的自由函数与 fixtures全量 Rust 套件依赖 cargo-nextest 的按测试进程隔离per-test process isolation来保证消息总线、日志等进程级/线程级状态的确定性因此不能用普通的cargo test --workspace作为全量套件闸门——这是仓库特有的、Agent 很容易踩错的点。最小公开 API 与生成产物只暴露最小的公开 API保持补丁聚焦避免与贡献无关的重构、重命名和抽象。生成产物generated artifacts必须通过其源与生成器来修改严禁手工编辑。典型例子是 PyO3 的类型桩stubspython/nautilus_trader/下的.pyi文件由python/generate_stubs.py生成改动 Rust 绑定后需运行make py-stubs并提交生成结果CI 会检测漂移drift并失败详见 docs/developer_guide/rust.md 的Generated Python artifacts一节。维护者专属路径不修改RELEASES.md由维护者维护以避免频繁的合并冲突。不修改.github/workflows或.github/actions这些路径仅限维护者操作。提交信息与 PR 标题不得使用 Conventional Commits 语法如feat(bybit): ...也不得在主题行中包含 issue/PR 编号——squash 合并会自动追加编号手动书写反而重复issue 引用应放在提交正文中如Resolves #4534。提交信息的具体格式在 docs/developer_guide/coding_standards.md 中有完整示例主题行以大写祈使动词开头Add、Fix、Improve、Refine、Update、Remove、Refactor、Standardize命名受影响表面目标 60 字符以内且不以句号结尾。Pull request readiness打开 PR 之前的本地验证闸门AGENTS.md 的核心要求是在打开 PR 之前准备一个完整、可评审的变更而不是把 PR 当作开发工作区。开发期的最小反馈回路开发过程中先运行最小的相关测试the smallest relevant test而不是等整个套件。打开或更新 PR 前先按 CONTRIBUTING.md 建立开发环境见 docs/developer_guide/environment_setup.md然后依次运行make format make pre-commitmake format同时格式化 Rustcargo nightly fmt与 Pythonruff formatmake pre-commit通过prek run --all-files运行仓库配置的全部 pre-commit 钩子。prekpre-commit runner在提交前执行文件检查并校验提交信息格式安装方式为prek install详见 docs/developer_guide/environment_setup.md。随后运行与改动相关的全部测试并确认通过。如果某项必需检查无法运行必须如实报告限制不得宣称变更已就绪并遵循 PR 模板撰写描述。把验证当作针对精确变更的证据验证validation是对精确的被测变更的证据。任何后续编辑或 rebase 之后都必须重新运行受影响的检查。需要更高保障时可运行make pre-flight——项目的宽泛本地验证套件。从 Makefile 的pre-flight目标定义可见它会依次执行sync→format→test-scripts-quiet→check-code含capnp,hypersync→check-code-sim→cargo-test-sim→cargo-test-extras→cargo-test-postgres-changed→build-debug→check-generated-drift→pytest→pytest-doctest ty→pytest-isolated→security-audit。这是一个全链路闸门覆盖格式化、Rust/Python 测试、生成产物漂移检查与供应链安全审计。注意make pre-flight不会取代make pre-commit。CI 的定位确认而非开发循环项目 CI 是对已在本地验证过的变更的确认不是开发循环也不能替代本地算力。每次 push 都会触发一轮 CI 运行频繁增量 push 消耗算力、取消进行中的任务并使 Actions 历史难以阅读。收到评审反馈后把相关修复批量合并为一个连贯更新本地重跑相关检查再 push。若平台、权限或本地资源限制导致某检查无法执行先与维护者讨论限制并在 PR 中明确说明。Git and public interaction公共交互的边界贡献者的工作基于develop分支PR 也面向develop。除非用户明确要求不得 commit、amend、push 或更改远程状态不得打开、编辑、评论、评审 GitHub issue 或 PR。所有公共交互由人类贡献者控制并对最终沟通负责。AI 可以协助起草文本但贡献者必须理解文本并核验其准确性起草时保留贡献者自己的选择与语气voice而不是用泛化的散文替换。Disclosure and attributionAI 披露与归属规范这一部分定义了 AI 辅助贡献的合规边界核心要点如下NautilusTrader不强制要求披露 AI 辅助AI_POLICY.md 不覆盖贡献者或提交材料所适用的任何法律、合同或许可证义务。若选择在提交信息中披露措辞保持通用例如Developed with assistance from AI.。项目在 AI 实验室、厂商、模型和工具之间保持中立不得在提交信息、PR 标题或 PR 描述中指名或推广特定 AI 工具作为归属。不得将 AI 工具或模型列为作者、共同作者或贡献者不得添加Co-authored-by:尾注不得在提交信息或 PR 文本中添加品牌页脚如Generated with ...。更深层的责任界定在 AI_POLICY.md人类贡献者对提交的每个 issue、变更、评审和评论负责提交前必须完整审阅、验证并理解每一部分——不仅要理解改动如何工作还要理解它为何契合项目架构与维护范围完全自主无意义的人类指导和评审的 Agent 贡献不被接受。AI 也不得代人类接受贡献者许可协议CLA、认证作者身份或许可权利。支撑这套流程的仓库基础设施要真正执行上述规则需要理解仓库的工具链与验证设施它们共同构成了 AGENTS.md 规则得以落地的土壤版本与工具链钉定pinningrust-toolchain.toml 固定 Rust 工具链为1.98.0。tools.toml 钉定本地工具版本如 docs.rs 的nightly-2026-08-21、Miri 的nightly-2026-08-23、pypi-attestations等共享工具目录在.nautilus-engineering/tools.toml。make install-tools一次性安装全部钉定开发工具cargo-audit、cargo-deny、cargo-edit、cargo-llvm-cov、cargo-nextest、cargo-vet、cargo-codspeed、cargo-fuzz、cargo-hawk、cargo-machete、cbindgen、flamegraph、lychee、prek、osv-scanner 等前置条件是一次性安装cargo-binstall。测试矩阵make cargo-test运行 Rust 全量测试基于 cargo-nextestmake pytest运行 Python 测试会先构建扩展与桩。单 crate 测试make cargo-test-crate-nautilus-model。可选特性make cargo-test EXTRA_FEATUREScapnp hypersync。DST 确定性仿真make cargo-test-simcfg madsimsimulationfeature覆盖 nautilus-common、event-store、network、execution 等 crate并在标准精度与high-precision两档下分别运行见 docs/developer_guide/testing.md 与 docs/concepts/dst.md。未定义行为检测make cargo-miriMiri 下运行 nautilus-core / nautilus-model / nautilus-plugin 的库测试proptest 用例数默认下调至 4。环境变量Linux/macOS uv 安装的 Pythonexport PYO3_PYTHON$PWD/python/.venv/bin/python PYTHON_LIB_DIR$($PYO3_PYTHON -c import sysconfig; print(sysconfig.get_config_var(LIBDIR))) export LD_LIBRARY_PATH$PYTHON_LIB_DIR${LD_LIBRARY_PATH::$LD_LIBRARY_PATH} export PYTHONHOME$($PYO3_PYTHON -c import sys; print(sys.base_prefix))其中PYTHONHOME在运行make cargo-test时必需否则依赖 PyO3 的测试可能无法定位 Python 运行时。一份可复用的 Agent 贡献检查清单将 AGENTS.md 的全部规则压缩为动手前的清单动手前阅读 AI_POLICY.md 与 CONTRIBUTING.md阅读受影响代码并搜索既有模式重大改动先在 issue 中与维护者对齐。开发中聚焦请求结果沿用既有风格与依赖只用python/.venv离散数值用领域类型或Decimal不向生产代码添加仅测试用的行为最小化公开 API不手改生成产物。验证先跑最小相关测试PR 前运行make format与make pre-commit重跑受影响检查需要更高保障时运行make pre-flightCI 只作确认不作开发循环。Git 与沟通基于develop分支未经用户明确要求不 push、不交互 GitHub不用 Conventional Commits提交主题不带 issue/PR 编号PR 描述准确、具体、易评审。AI 归属不强制披露若披露保持通用措辞不指名推广具体 AI 工具不添加 AI 作者/共同作者尾注或品牌页脚人类贡献者对全部内容负责并保持自己的声音。对于任何参与 NautilusTrader 开发的 AI Agent 或使用 AI 辅助的贡献者而言这份指南既是行为规范也是质量保证体系——它把涉及真实资金的代码必须严谨这一最高原则落实为一条条可执行、可验证、可评审的具体操作。【免费下载链接】nautilus_traderProduction-grade Rust-native trading engine with deterministic event-driven architecture项目地址: https://gitcode.com/GitHub_Trending/na/nautilus_trader创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
NautilusTrader AI Agent 开发贡献指南：工作规则、质量闸门与 PR 就绪流程
NautilusTrader AI Agent 开发贡献指南工作规则、质量闸门与 PR 就绪流程【免费下载链接】nautilus_traderProduction-grade Rust-native trading engine with deterministic event-driven architecture项目地址: https://gitcode.com/GitHub_Trending/na/nautilus_trader本篇指南以 NautilusTrader 仓库根目录的 AGENTS.md 为骨架面向使用 AI 辅助工具参与该开源交易平台开发的贡献者尤其是 Agent 驱动的开发流程系统讲解仓库要求的工作规则、本地验证闸门、Git 交互边界与 AI 披露规范。读完本文你将掌握一套可直接落地的 Agent 贡献工作流在改动真实资金可触达的交易代码前如何约束行为、如何用make format/make pre-commit/make pre-flight把变更打磨到可评审状态以及如何在不越界、不伪造测试的前提下提交一个评审就绪的 Pull Request。为什么 NautilusTrader 需要一份面向 Agent 的指令文档NautilusTrader 是一个生产级的 Rust 原生交易引擎采用确定性事件驱动架构。仓库 README.md 与 CONTRIBUTING.md 反复强调一句核心事实NautilusTrader 可以执行涉及真实资金的实盘交易任何错误都可能造成财务损失。因此项目对正确性、可靠性、测试性、清晰度和可维护性设置了极高的标准并要求所有贡献无论是否使用 AI都达到同等质量。AGENTS.md 正是这一标准的制度化表达。它开篇要求任何改动前先阅读 AI_POLICY.md 与 CONTRIBUTING.md并遵守 docs/developer_guide/coding_standards.md 以及所改动领域对应的开发者指南。文档共分四大部分Working rules工作规则、Pull request readinessPR 就绪、Git and public interactionGit 与公共交互、Disclosure and attribution披露与归属。Working rulesAgent 的硬性工作纪律AGENTS.md 的第二部分列出所有贡献者必须遵守的底层规则这些规则约束的是改代码之前和改代码过程中的行为。先读代码、再提方案在提出或实施任何改动之前必须阅读受影响的代码并搜索仓库中已有的模式existing patterns。每个改动必须聚焦于请求的结果requested outcome发现无关问题时记录下来Note而不是顺手修复避免顺带重构drive-by refactors污染提交。这一规则与 CONTRIBUTING.md 的Start with an issue精神一致重大改动新特性、新集成、设计变更需要先在 issue 中与维护者达成一致只有类型、文档修正、范围明确的 bug 修复这类小而自包含的改动可以免于事先沟通。风格与依赖沿用既定模式匹配现有风格使用已确立的函数、类型、命名和依赖不引入自创抽象。具体风格细节缩进、命名、术语、提交信息格式以 docs/developer_guide/coding_standards.md 为准例如全部使用空格而非制表符、行宽一般不超过 100 字符、Rust 文档注释使用陈述语气indicative mood、错误变量统一命名为单字母eErr(e)/except SomeError as e:。uv 项目环境只用python/.venv仓库明确规定必须使用 uv 管理的 Python 项目环境位置固定为python/.venv禁止创建或使用根目录的.venv。运行 uv 项目命令时要么在python/目录下直接执行要么在仓库根目录加--project python参数。这与 docs/developer_guide/environment_setup.md 的环境布局完全对应uv 环境的默认项目布局就放在python/pyproject.toml旁边的python/.venvMake 目标和 CI 会自动选择该项目。如果旧 checkout 曾使用根目录.venv需要从 shell 启动文件和当前 shell 中移除任何UV_PROJECT_ENVIRONMENT导出因为该覆盖项优先于 uv 的项目发现。精确算术价格、数量与金额绝不容忍浮点误差对价格、数量、货币金额及其他离散数值必须保留精确算术使用项目的领域类型domain types或Decimal。这是交易系统的命脉。从源码结构看crates/model 中的Price、Quantity、Money等类型以及Decimal承担了这一职责Makefile 中专门设置了标准精度64-bit与高精度high-precisionu128宽度两条测试通道cargo-test-standard-precision与cargo-test-sim会在两种精度宽度下分别验证代码路径可见精度在项目中被当作一等公民对待。测试纪律不弱化、不绕过、不重写不得仅为通过测试而向生产代码添加仅测试用的行为、分支、属性或接口。不得削弱、移除、绕过或重写测试及其保护的行为来换取通过结果必须修复根本问题并保留测试要保护的既有行为。仅当任务有意改变所需行为、或你能独立验证测试本身有误时才允许修改测试。这条规则的仓库侧支撑来自 docs/developer_guide/testing.md项目的自动化测试被视作交易平台的可执行规格executable specifications测试与运行时契约构成同一套设计系统。Rust 测试统一使用#[rstest]包括非参数化用例Python 测试使用 pytest 风格的自由函数与 fixtures全量 Rust 套件依赖 cargo-nextest 的按测试进程隔离per-test process isolation来保证消息总线、日志等进程级/线程级状态的确定性因此不能用普通的cargo test --workspace作为全量套件闸门——这是仓库特有的、Agent 很容易踩错的点。最小公开 API 与生成产物只暴露最小的公开 API保持补丁聚焦避免与贡献无关的重构、重命名和抽象。生成产物generated artifacts必须通过其源与生成器来修改严禁手工编辑。典型例子是 PyO3 的类型桩stubspython/nautilus_trader/下的.pyi文件由python/generate_stubs.py生成改动 Rust 绑定后需运行make py-stubs并提交生成结果CI 会检测漂移drift并失败详见 docs/developer_guide/rust.md 的Generated Python artifacts一节。维护者专属路径不修改RELEASES.md由维护者维护以避免频繁的合并冲突。不修改.github/workflows或.github/actions这些路径仅限维护者操作。提交信息与 PR 标题不得使用 Conventional Commits 语法如feat(bybit): ...也不得在主题行中包含 issue/PR 编号——squash 合并会自动追加编号手动书写反而重复issue 引用应放在提交正文中如Resolves #4534。提交信息的具体格式在 docs/developer_guide/coding_standards.md 中有完整示例主题行以大写祈使动词开头Add、Fix、Improve、Refine、Update、Remove、Refactor、Standardize命名受影响表面目标 60 字符以内且不以句号结尾。Pull request readiness打开 PR 之前的本地验证闸门AGENTS.md 的核心要求是在打开 PR 之前准备一个完整、可评审的变更而不是把 PR 当作开发工作区。开发期的最小反馈回路开发过程中先运行最小的相关测试the smallest relevant test而不是等整个套件。打开或更新 PR 前先按 CONTRIBUTING.md 建立开发环境见 docs/developer_guide/environment_setup.md然后依次运行make format make pre-commitmake format同时格式化 Rustcargo nightly fmt与 Pythonruff formatmake pre-commit通过prek run --all-files运行仓库配置的全部 pre-commit 钩子。prekpre-commit runner在提交前执行文件检查并校验提交信息格式安装方式为prek install详见 docs/developer_guide/environment_setup.md。随后运行与改动相关的全部测试并确认通过。如果某项必需检查无法运行必须如实报告限制不得宣称变更已就绪并遵循 PR 模板撰写描述。把验证当作针对精确变更的证据验证validation是对精确的被测变更的证据。任何后续编辑或 rebase 之后都必须重新运行受影响的检查。需要更高保障时可运行make pre-flight——项目的宽泛本地验证套件。从 Makefile 的pre-flight目标定义可见它会依次执行sync→format→test-scripts-quiet→check-code含capnp,hypersync→check-code-sim→cargo-test-sim→cargo-test-extras→cargo-test-postgres-changed→build-debug→check-generated-drift→pytest→pytest-doctest ty→pytest-isolated→security-audit。这是一个全链路闸门覆盖格式化、Rust/Python 测试、生成产物漂移检查与供应链安全审计。注意make pre-flight不会取代make pre-commit。CI 的定位确认而非开发循环项目 CI 是对已在本地验证过的变更的确认不是开发循环也不能替代本地算力。每次 push 都会触发一轮 CI 运行频繁增量 push 消耗算力、取消进行中的任务并使 Actions 历史难以阅读。收到评审反馈后把相关修复批量合并为一个连贯更新本地重跑相关检查再 push。若平台、权限或本地资源限制导致某检查无法执行先与维护者讨论限制并在 PR 中明确说明。Git and public interaction公共交互的边界贡献者的工作基于develop分支PR 也面向develop。除非用户明确要求不得 commit、amend、push 或更改远程状态不得打开、编辑、评论、评审 GitHub issue 或 PR。所有公共交互由人类贡献者控制并对最终沟通负责。AI 可以协助起草文本但贡献者必须理解文本并核验其准确性起草时保留贡献者自己的选择与语气voice而不是用泛化的散文替换。Disclosure and attributionAI 披露与归属规范这一部分定义了 AI 辅助贡献的合规边界核心要点如下NautilusTrader不强制要求披露 AI 辅助AI_POLICY.md 不覆盖贡献者或提交材料所适用的任何法律、合同或许可证义务。若选择在提交信息中披露措辞保持通用例如Developed with assistance from AI.。项目在 AI 实验室、厂商、模型和工具之间保持中立不得在提交信息、PR 标题或 PR 描述中指名或推广特定 AI 工具作为归属。不得将 AI 工具或模型列为作者、共同作者或贡献者不得添加Co-authored-by:尾注不得在提交信息或 PR 文本中添加品牌页脚如Generated with ...。更深层的责任界定在 AI_POLICY.md人类贡献者对提交的每个 issue、变更、评审和评论负责提交前必须完整审阅、验证并理解每一部分——不仅要理解改动如何工作还要理解它为何契合项目架构与维护范围完全自主无意义的人类指导和评审的 Agent 贡献不被接受。AI 也不得代人类接受贡献者许可协议CLA、认证作者身份或许可权利。支撑这套流程的仓库基础设施要真正执行上述规则需要理解仓库的工具链与验证设施它们共同构成了 AGENTS.md 规则得以落地的土壤版本与工具链钉定pinningrust-toolchain.toml 固定 Rust 工具链为1.98.0。tools.toml 钉定本地工具版本如 docs.rs 的nightly-2026-08-21、Miri 的nightly-2026-08-23、pypi-attestations等共享工具目录在.nautilus-engineering/tools.toml。make install-tools一次性安装全部钉定开发工具cargo-audit、cargo-deny、cargo-edit、cargo-llvm-cov、cargo-nextest、cargo-vet、cargo-codspeed、cargo-fuzz、cargo-hawk、cargo-machete、cbindgen、flamegraph、lychee、prek、osv-scanner 等前置条件是一次性安装cargo-binstall。测试矩阵make cargo-test运行 Rust 全量测试基于 cargo-nextestmake pytest运行 Python 测试会先构建扩展与桩。单 crate 测试make cargo-test-crate-nautilus-model。可选特性make cargo-test EXTRA_FEATUREScapnp hypersync。DST 确定性仿真make cargo-test-simcfg madsimsimulationfeature覆盖 nautilus-common、event-store、network、execution 等 crate并在标准精度与high-precision两档下分别运行见 docs/developer_guide/testing.md 与 docs/concepts/dst.md。未定义行为检测make cargo-miriMiri 下运行 nautilus-core / nautilus-model / nautilus-plugin 的库测试proptest 用例数默认下调至 4。环境变量Linux/macOS uv 安装的 Pythonexport PYO3_PYTHON$PWD/python/.venv/bin/python PYTHON_LIB_DIR$($PYO3_PYTHON -c import sysconfig; print(sysconfig.get_config_var(LIBDIR))) export LD_LIBRARY_PATH$PYTHON_LIB_DIR${LD_LIBRARY_PATH::$LD_LIBRARY_PATH} export PYTHONHOME$($PYO3_PYTHON -c import sys; print(sys.base_prefix))其中PYTHONHOME在运行make cargo-test时必需否则依赖 PyO3 的测试可能无法定位 Python 运行时。一份可复用的 Agent 贡献检查清单将 AGENTS.md 的全部规则压缩为动手前的清单动手前阅读 AI_POLICY.md 与 CONTRIBUTING.md阅读受影响代码并搜索既有模式重大改动先在 issue 中与维护者对齐。开发中聚焦请求结果沿用既有风格与依赖只用python/.venv离散数值用领域类型或Decimal不向生产代码添加仅测试用的行为最小化公开 API不手改生成产物。验证先跑最小相关测试PR 前运行make format与make pre-commit重跑受影响检查需要更高保障时运行make pre-flightCI 只作确认不作开发循环。Git 与沟通基于develop分支未经用户明确要求不 push、不交互 GitHub不用 Conventional Commits提交主题不带 issue/PR 编号PR 描述准确、具体、易评审。AI 归属不强制披露若披露保持通用措辞不指名推广具体 AI 工具不添加 AI 作者/共同作者尾注或品牌页脚人类贡献者对全部内容负责并保持自己的声音。对于任何参与 NautilusTrader 开发的 AI Agent 或使用 AI 辅助的贡献者而言这份指南既是行为规范也是质量保证体系——它把涉及真实资金的代码必须严谨这一最高原则落实为一条条可执行、可验证、可评审的具体操作。【免费下载链接】nautilus_traderProduction-grade Rust-native trading engine with deterministic event-driven architecture项目地址: https://gitcode.com/GitHub_Trending/na/nautilus_trader创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
