Opik Python SDK 开发规范全解目录结构、构建测试命令与 E2E 隔离契约【免费下载链接】comet-llmDebug, evaluate, and monitor your LLM applications, RAG systems, and agentic workflows with comprehensive tracing, automated evaluations, and production-ready dashboards.项目地址: https://gitcode.com/GitHub_Trending/co/comet-llmOpik 是 Comet 出品的开源 LLM 可观测性平台支持对 LLM 应用、RAG 系统和 Agent 工作流进行全链路追踪、自动化评测与生产级监控。本文以 Opik 单仓库中 sdks/python/AGENTS.md 这份 Python SDK 专属开发规范为骨架结合src/opik、tests/与根级 AGENTS.md 的实际源码系统讲解 Python SDK 的目录组织、构建与测试命令、编码风格约定以及最关键的 E2E 测试隔离契约。读完本文你将能够按官方规范在sdks/python下编写符合要求的代码、运行分层测试并理解pytest-xdist并行模式下资源命名必须遵循的铁律。一、文档定位与继承关系sdks/python/AGENTS.md是 Opik 单仓库monorepo体系下的模块级module-level指南。它遵循一个明确的分工原则本文件只承载 Python SDK 特有内容——目录结构、测试命令、编码风格、E2E 隔离契约共享的工作流、PR 与安全策略统一由根级 AGENTS.md 定义各模块AGENTS.md只保留模块特有指引并引用根级文件避免多份重复指令互相漂移。这种「根级共享 模块级专用」的分层约定在仓库中贯彻得很彻底根级AGENTS.md声明了 Java 后端apps/opik-backend、React 前端apps/opik-frontend、文档站apps/opik-documentation、三个 SDKsdks/python、sdks/typescript、sdks/opik_optimizer、部署与测试套件deployment、tests_end_to_end、tests_load的主分区而 Python SDK 专属细节全部沉淀在sdks/python/AGENTS.md中供在该目录下工作的开发者与 Agent 使用。二、Python SDK 目录结构与模块组织SDK 全部代码位于仓库根目录的sdks/python下规范文件中明确了各子目录的职责目录职责src/opik/Python 包源码即 SDK 的主体实现tests/测试套件按unit/、integration/、e2e/、e2e_library_integration/、e2e_smoke/分层组织examples/可运行的集成示例与使用配方如openai_integration_example.py、langchain_integration_example.py等design/与outputs/设计文档资产与生成产物README.mdSDK 概览与贡献者入口从实际目录看src/opik/包含 1600 个 Python 文件涵盖api_objects客户端与 API 对象、configurator配置引导、cli命令行工具、message_processing消息流式处理、evaluation评测、integrations框架集成等核心子包tests/下则有unit/约 395 个文件、e2e/65 个文件等规模与文档描述一致。三、构建、测试与开发命令规范要求所有命令默认在sdks/python目录下执行除非另有说明核心命令如下# 1. 安装测试依赖并运行标准测试unit integration e2e pip install -r tests/test_requirements.txt pytest tests/unit tests/integration tests/e2e # 2. 运行更高成本、跨系统集成的覆盖率 pytest tests/e2e_library_integration tests/e2e_smoke # 3. 在仓库根目录运行 pre-commit 钩子格式化、lint、mypy仅检查相对 origin/main 变更的文件 cd $(git rev-parse --show-toplevel) make precommit # 4. 本地/开发环境下的 SDK 配置 opik configure --use_local # 或云端配置 opik configure其中opik configure --use_local是本地自托管部署的标准配置方式。查看 configurator/configure.py 的源码可以发现use_local参数会直接决定 SDK 指向的默认基地址本地模式使用OPIK_BASE_URL_LOCAL云端模式使用OPIK_BASE_URL_CLOUD若同时指定了url参数则优先采用用户提供的地址。整个配置流程由 cli/configure.py 中的 Click 命令驱动交互式地写入本地配置文件。根级 AGENTS.md 还补充了跨模块的开发入口./opik.sh用 Docker 一键拉起本地全栈--build重建镜像、--verify健康检查、--stop停止服务scripts/dev-runner.sh则用于 BEFE 的快速本地进程模式。四、编码风格与命名约定sdks/python/AGENTS.md对 Python 代码风格做了明确约束这些约束在仓库配置文件中都有落地证据Python 版本目标版本与pyproject.toml声明的模块支持版本一致当前为 3.10。证据pyproject.toml 中[tool.mypy]的python_version 3.10.ruff.toml 中target-version py310。缩进与行宽4 空格缩进、行宽 88。证据.ruff.toml 中indent-width 4、line-length 88。静态检查工具以ruff和ruff format为主配置在 .ruff.tomlmypy通过 pre-commit 运行。ruff默认启用E4、E7、E9、FPyflakes规则子集格式层面采用与 Black 一致的双引号字符串、空格缩进、保留魔法尾逗号策略。命名倾向显式命名、避免缩写不要创建utils.py/helpers.py这类「杂物箱」文件新代码倾向模块级导入import module而非单名导入from module import name仅当名字不在模块外使用时才加_前缀保持私有。注释聚焦意图why不机械描述机制what。这些约定保证了 SDK 在多人/多 Agent 协作下保持一致的代码形态也让make precommit根级.pre-commit-config.yaml驱动可以无痛地统一校验。五、测试分层策略规范给出了清晰的测试层级选择原则可以概括为一张决策表变更类型首选测试层级说明行为逻辑变化tests/unit成本最低、反馈最快触及后端或集成行为tests/integration需要真实依赖时使用跨系统端到端流程tests/e2e成本最高最后兜底外部框架集成tests/e2e_library_integration与 e2e 并列的专项目录同时强调提交 PR 前优先跑聚焦的测试套件不要只用大而全的 e2e 覆盖单元测试就能解决的问题文件命名统一为tests/category/下的test_*.py。测试基础设施在 tests/conftest.py 中提供了大量可复用 fixturefake_backend将 streamer 替换为后端模拟器把 span/trace 树构建在内存中以供断言、shutdown_cached_client_after_test测试后重置全局缓存客户端、random_chars生成随机资源后缀、skip_local_configuration_file把OPIK_CONFIG_PATH指向不存在的文件避免全局配置污染项目名断言等。六、E2E 测试隔离契约核心E2E 套件运行在pytest-xdist的--distloadfile模式下每个测试文件被分派给一个 worker多个文件并行跑在同一个共享后端上。这意味着资源名绝对不能跨文件冲突——这是整个契约的前提。sdks/python/AGENTS.md为遵守这一前提规定了五条铁律下面逐条结合源码解析。6.1 项目名单一事实来源PROJECT_NAME常量测试模块的后端项目名来自generate_project_name(e2e, __name__)helper 位于 tests/testlib/project_naming.py从tests.testlib再导出。需要引用项目名的文件如 verifier fallback、search_traces等在模块顶部声明from ..testlib import generate_project_name PROJECT_NAME generate_project_name(e2e, __name__)规范强调测试体内直接引用PROJECT_NAME不要引入project_name PROJECT_NAME这类间接赋值。原因在于 autouse 的configure_e2e_tests_envfixture 会从每个测试模块读取PROJECT_NAME并 patchOPIK_PROJECT_NAME环境变量常量即唯一事实来源SDK 写入时使用的环境变量与测试断言时引用的常量永远不会漂移。不引用项目名的文件无需声明常量fixture 会自动从模块名推导一个。从实现看tests/e2e/conftest.pyconfigure_e2e_tests_env是module 作用域的 autouse fixture它在模块内所有测试期间把OPIK_PROJECT_NAMEpatch 为PROJECT_NAME且通过testlib.patch_environ在 yield 后自动还原。注释还点出了一个关键机制Opik(...)只在构造时读取一次OPIK_PROJECT_NAME并缓存为self._project_name因此 patch 之所以生效依赖opik_clientfixture 每个测试新建客户端以及 function 作用域的 autouse fixtureshutdown_cached_client_after_test重置全局缓存客户端而opik.track是在调用时通过get_client_cached()惰性解析客户端不存在 import 期捕获问题。6.2 项目名生成器为什么用secrets而非random查看 project_naming.py 的实现generate_project_name会把每个前缀缩减到最后一个点号分段例如tests.e2e.test_dataset→test_dataset拼上 6 位随机字符得到e2e-file-random形式的名称。随机部分刻意使用secrets.token_hex而非tests/conftest.py中的random_chars后者基于random.choice(string.ascii_letters)原因有二避免循环导入project_naming.py若从conftest.py导入random_chars会形成循环依赖conftest 本身会导入 testlib对抗 seed 干扰secrets的随机性与环境种子无关即使测试环境里出现random.seed(...)或固定PYTHONHASHSEED各 worker 计算出的名称依然唯一——这对 xdist 隔离契约是「load-bearing」承重的。6.3 禁止在 parametrize 装饰器中内嵌generate_project_name这是最容易踩的坑。规则project_name覆盖路径的测试即「替代项目」场景不得把generate_project_name(...)直接作为pytest.mark.parametrize的装饰器值使用。因为每个 worker 都会收集每个 parametrize id而generate_project_name每次进程返回不同值导致不同 worker 的收集 id 不一致触发 xdist 的collection-consistency check 失败。正确姿势是对布尔值 parametrize在测试体内计算项目名pytest.mark.parametrize(override_project_name, [True, False]) def test_xxx(opik_client, override_project_name): project_name ( generate_project_name(e2e, anonymization, override) if override_project_name else None ) ...之所以可行是因为每个 CI job 拥有独立的后端栈且--distloadfile保证每个文件只在一个 worker 上执行不同 worker 算出的不同名字在实践中不构成冲突。6.4 优先使用命名 fixture禁止硬编码资源名数据集、实验、提示词、临时项目等按测试独立的资源已经由 e2e conftest 提供了注入随机后缀的命名 fixture直接使用即可不要自创 per-test 名字。从 tests/e2e/conftest.py 可以看到这些 fixture 的实现模式dataset_name/experiment_name/prompt_name生成e2e-tests-type-random_chars()形式的唯一名称temporary_project_name生成唯一项目名并在 teardown 中尽力清理通过rest_client.projects.retrieve_projectdelete_project_by_id对未创建或已删除的项目静默容忍ApiErrorenvironment_name同样在 teardown 删除环境——因为环境有工作区数量上限默认 20泄漏会快速打满容量。其余约束禁止裸调random_chars()作为项目名只在需要非项目资源名且无对应 fixture 时才能使用tests/e2e/**下任何位置禁止出现裸硬编码的项目/数据集/实验/提示词/套件/标注队列/优化名称。由唯一 fixture 派生的字符串如ftest_optimization_{dataset_name}是允许的因为dataset_name已注入随机后缀。代码评审时若发现硬编码资源名按「缺失 teardown」同等级别视为缺陷。6.5configure_e2e_tests_env的作用域与 xdist 类不要收窄configure_e2e_tests_env的作用域它是 autouse 且 module 作用域。xdist 下若收窄为 function 作用域teardown 顺序会导致 flaky 测试。--distloadfile下测试类不跨 worker 拆分文件内所有测试包括class Test…中的都在同一 worker 上运行因此模块级常量和 module 作用域 fixture 同时覆盖该文件内的模块级测试与类内测试。如果某个文件切换为--distloadscope需要重新审视作用域契约。七、Agent 贡献工作流与 PR 规范Python SDK 属于 Opik monorepo 的一部分Agent/开发者遵循根级 AGENTS.md 中定义的共享工作流再叠加本模块要求改动前先阅读根级 CONTRIBUTING.md 与 PR 模板在请求评审前针对 Python SDK 变更运行本文档列出的格式化与测试命令PR 标题与首个提交采用语义化风格并带工单前缀[OPIK-1234] [COMPONENT] feat|fix|refactor|docs: short summaryPython SDK 专属惯例适用时使用 SDK 前缀标题如[OPIK-####] [SDK] ...PR 描述应包含变更摘要、测试覆盖情况和关联 issue 引用Resolves #...。八、安全与配置建议安全策略方面模块级规范在根级 AGENTS.md 的基础上增加了一条 Python SDK 专属红线凭据一律通过opik configure或环境变量配置绝不硬编码进源码。根级指南进一步建议密钥与 API key 不得进入版本控制使用本地.env或 shell 变量保存本地自托管测试需先配好 MySQL、ClickHouse、Redis 等依赖跑本地部署上的 SDK 示例优先使用opik configure --use_local。这一原则在仓库中体现为一致的架构SDK 的基地址、API key、workspace、项目名OPIK_PROJECT_NAME等均通过环境变量或opik configure写入的本地配置文件解析参见 configurator/configure.py 与 api_objects/helpers.py 中对环境变量的引用测试代码也大量借助testlib.patch_environ以环境变量注入方式隔离配置——从根源上杜绝密钥泄露与配置污染。结语sdks/python/AGENTS.md虽是一份面向贡献者的规范文件但它浓缩了 Opik Python SDK 工程化的全部关键决策模块化的目录组织、分层测试策略、ruff/mypy 强制的代码风格以及围绕pytest-xdist并行执行设计的资源隔离契约。理解这份契约你不仅能规范地在仓库中贡献代码更能读懂 e2e 套件中每个PROJECT_NAME常量与命名 fixture 背后的并发安全考量——这正是大型开源项目把「测试可并行、可重跑」落到实处的典型范本。【免费下载链接】comet-llmDebug, evaluate, and monitor your LLM applications, RAG systems, and agentic workflows with comprehensive tracing, automated evaluations, and production-ready dashboards.项目地址: https://gitcode.com/GitHub_Trending/co/comet-llm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Opik Python SDK 开发规范全解：目录结构、构建测试命令与 E2E 隔离契约
Opik Python SDK 开发规范全解目录结构、构建测试命令与 E2E 隔离契约【免费下载链接】comet-llmDebug, evaluate, and monitor your LLM applications, RAG systems, and agentic workflows with comprehensive tracing, automated evaluations, and production-ready dashboards.项目地址: https://gitcode.com/GitHub_Trending/co/comet-llmOpik 是 Comet 出品的开源 LLM 可观测性平台支持对 LLM 应用、RAG 系统和 Agent 工作流进行全链路追踪、自动化评测与生产级监控。本文以 Opik 单仓库中 sdks/python/AGENTS.md 这份 Python SDK 专属开发规范为骨架结合src/opik、tests/与根级 AGENTS.md 的实际源码系统讲解 Python SDK 的目录组织、构建与测试命令、编码风格约定以及最关键的 E2E 测试隔离契约。读完本文你将能够按官方规范在sdks/python下编写符合要求的代码、运行分层测试并理解pytest-xdist并行模式下资源命名必须遵循的铁律。一、文档定位与继承关系sdks/python/AGENTS.md是 Opik 单仓库monorepo体系下的模块级module-level指南。它遵循一个明确的分工原则本文件只承载 Python SDK 特有内容——目录结构、测试命令、编码风格、E2E 隔离契约共享的工作流、PR 与安全策略统一由根级 AGENTS.md 定义各模块AGENTS.md只保留模块特有指引并引用根级文件避免多份重复指令互相漂移。这种「根级共享 模块级专用」的分层约定在仓库中贯彻得很彻底根级AGENTS.md声明了 Java 后端apps/opik-backend、React 前端apps/opik-frontend、文档站apps/opik-documentation、三个 SDKsdks/python、sdks/typescript、sdks/opik_optimizer、部署与测试套件deployment、tests_end_to_end、tests_load的主分区而 Python SDK 专属细节全部沉淀在sdks/python/AGENTS.md中供在该目录下工作的开发者与 Agent 使用。二、Python SDK 目录结构与模块组织SDK 全部代码位于仓库根目录的sdks/python下规范文件中明确了各子目录的职责目录职责src/opik/Python 包源码即 SDK 的主体实现tests/测试套件按unit/、integration/、e2e/、e2e_library_integration/、e2e_smoke/分层组织examples/可运行的集成示例与使用配方如openai_integration_example.py、langchain_integration_example.py等design/与outputs/设计文档资产与生成产物README.mdSDK 概览与贡献者入口从实际目录看src/opik/包含 1600 个 Python 文件涵盖api_objects客户端与 API 对象、configurator配置引导、cli命令行工具、message_processing消息流式处理、evaluation评测、integrations框架集成等核心子包tests/下则有unit/约 395 个文件、e2e/65 个文件等规模与文档描述一致。三、构建、测试与开发命令规范要求所有命令默认在sdks/python目录下执行除非另有说明核心命令如下# 1. 安装测试依赖并运行标准测试unit integration e2e pip install -r tests/test_requirements.txt pytest tests/unit tests/integration tests/e2e # 2. 运行更高成本、跨系统集成的覆盖率 pytest tests/e2e_library_integration tests/e2e_smoke # 3. 在仓库根目录运行 pre-commit 钩子格式化、lint、mypy仅检查相对 origin/main 变更的文件 cd $(git rev-parse --show-toplevel) make precommit # 4. 本地/开发环境下的 SDK 配置 opik configure --use_local # 或云端配置 opik configure其中opik configure --use_local是本地自托管部署的标准配置方式。查看 configurator/configure.py 的源码可以发现use_local参数会直接决定 SDK 指向的默认基地址本地模式使用OPIK_BASE_URL_LOCAL云端模式使用OPIK_BASE_URL_CLOUD若同时指定了url参数则优先采用用户提供的地址。整个配置流程由 cli/configure.py 中的 Click 命令驱动交互式地写入本地配置文件。根级 AGENTS.md 还补充了跨模块的开发入口./opik.sh用 Docker 一键拉起本地全栈--build重建镜像、--verify健康检查、--stop停止服务scripts/dev-runner.sh则用于 BEFE 的快速本地进程模式。四、编码风格与命名约定sdks/python/AGENTS.md对 Python 代码风格做了明确约束这些约束在仓库配置文件中都有落地证据Python 版本目标版本与pyproject.toml声明的模块支持版本一致当前为 3.10。证据pyproject.toml 中[tool.mypy]的python_version 3.10.ruff.toml 中target-version py310。缩进与行宽4 空格缩进、行宽 88。证据.ruff.toml 中indent-width 4、line-length 88。静态检查工具以ruff和ruff format为主配置在 .ruff.tomlmypy通过 pre-commit 运行。ruff默认启用E4、E7、E9、FPyflakes规则子集格式层面采用与 Black 一致的双引号字符串、空格缩进、保留魔法尾逗号策略。命名倾向显式命名、避免缩写不要创建utils.py/helpers.py这类「杂物箱」文件新代码倾向模块级导入import module而非单名导入from module import name仅当名字不在模块外使用时才加_前缀保持私有。注释聚焦意图why不机械描述机制what。这些约定保证了 SDK 在多人/多 Agent 协作下保持一致的代码形态也让make precommit根级.pre-commit-config.yaml驱动可以无痛地统一校验。五、测试分层策略规范给出了清晰的测试层级选择原则可以概括为一张决策表变更类型首选测试层级说明行为逻辑变化tests/unit成本最低、反馈最快触及后端或集成行为tests/integration需要真实依赖时使用跨系统端到端流程tests/e2e成本最高最后兜底外部框架集成tests/e2e_library_integration与 e2e 并列的专项目录同时强调提交 PR 前优先跑聚焦的测试套件不要只用大而全的 e2e 覆盖单元测试就能解决的问题文件命名统一为tests/category/下的test_*.py。测试基础设施在 tests/conftest.py 中提供了大量可复用 fixturefake_backend将 streamer 替换为后端模拟器把 span/trace 树构建在内存中以供断言、shutdown_cached_client_after_test测试后重置全局缓存客户端、random_chars生成随机资源后缀、skip_local_configuration_file把OPIK_CONFIG_PATH指向不存在的文件避免全局配置污染项目名断言等。六、E2E 测试隔离契约核心E2E 套件运行在pytest-xdist的--distloadfile模式下每个测试文件被分派给一个 worker多个文件并行跑在同一个共享后端上。这意味着资源名绝对不能跨文件冲突——这是整个契约的前提。sdks/python/AGENTS.md为遵守这一前提规定了五条铁律下面逐条结合源码解析。6.1 项目名单一事实来源PROJECT_NAME常量测试模块的后端项目名来自generate_project_name(e2e, __name__)helper 位于 tests/testlib/project_naming.py从tests.testlib再导出。需要引用项目名的文件如 verifier fallback、search_traces等在模块顶部声明from ..testlib import generate_project_name PROJECT_NAME generate_project_name(e2e, __name__)规范强调测试体内直接引用PROJECT_NAME不要引入project_name PROJECT_NAME这类间接赋值。原因在于 autouse 的configure_e2e_tests_envfixture 会从每个测试模块读取PROJECT_NAME并 patchOPIK_PROJECT_NAME环境变量常量即唯一事实来源SDK 写入时使用的环境变量与测试断言时引用的常量永远不会漂移。不引用项目名的文件无需声明常量fixture 会自动从模块名推导一个。从实现看tests/e2e/conftest.pyconfigure_e2e_tests_env是module 作用域的 autouse fixture它在模块内所有测试期间把OPIK_PROJECT_NAMEpatch 为PROJECT_NAME且通过testlib.patch_environ在 yield 后自动还原。注释还点出了一个关键机制Opik(...)只在构造时读取一次OPIK_PROJECT_NAME并缓存为self._project_name因此 patch 之所以生效依赖opik_clientfixture 每个测试新建客户端以及 function 作用域的 autouse fixtureshutdown_cached_client_after_test重置全局缓存客户端而opik.track是在调用时通过get_client_cached()惰性解析客户端不存在 import 期捕获问题。6.2 项目名生成器为什么用secrets而非random查看 project_naming.py 的实现generate_project_name会把每个前缀缩减到最后一个点号分段例如tests.e2e.test_dataset→test_dataset拼上 6 位随机字符得到e2e-file-random形式的名称。随机部分刻意使用secrets.token_hex而非tests/conftest.py中的random_chars后者基于random.choice(string.ascii_letters)原因有二避免循环导入project_naming.py若从conftest.py导入random_chars会形成循环依赖conftest 本身会导入 testlib对抗 seed 干扰secrets的随机性与环境种子无关即使测试环境里出现random.seed(...)或固定PYTHONHASHSEED各 worker 计算出的名称依然唯一——这对 xdist 隔离契约是「load-bearing」承重的。6.3 禁止在 parametrize 装饰器中内嵌generate_project_name这是最容易踩的坑。规则project_name覆盖路径的测试即「替代项目」场景不得把generate_project_name(...)直接作为pytest.mark.parametrize的装饰器值使用。因为每个 worker 都会收集每个 parametrize id而generate_project_name每次进程返回不同值导致不同 worker 的收集 id 不一致触发 xdist 的collection-consistency check 失败。正确姿势是对布尔值 parametrize在测试体内计算项目名pytest.mark.parametrize(override_project_name, [True, False]) def test_xxx(opik_client, override_project_name): project_name ( generate_project_name(e2e, anonymization, override) if override_project_name else None ) ...之所以可行是因为每个 CI job 拥有独立的后端栈且--distloadfile保证每个文件只在一个 worker 上执行不同 worker 算出的不同名字在实践中不构成冲突。6.4 优先使用命名 fixture禁止硬编码资源名数据集、实验、提示词、临时项目等按测试独立的资源已经由 e2e conftest 提供了注入随机后缀的命名 fixture直接使用即可不要自创 per-test 名字。从 tests/e2e/conftest.py 可以看到这些 fixture 的实现模式dataset_name/experiment_name/prompt_name生成e2e-tests-type-random_chars()形式的唯一名称temporary_project_name生成唯一项目名并在 teardown 中尽力清理通过rest_client.projects.retrieve_projectdelete_project_by_id对未创建或已删除的项目静默容忍ApiErrorenvironment_name同样在 teardown 删除环境——因为环境有工作区数量上限默认 20泄漏会快速打满容量。其余约束禁止裸调random_chars()作为项目名只在需要非项目资源名且无对应 fixture 时才能使用tests/e2e/**下任何位置禁止出现裸硬编码的项目/数据集/实验/提示词/套件/标注队列/优化名称。由唯一 fixture 派生的字符串如ftest_optimization_{dataset_name}是允许的因为dataset_name已注入随机后缀。代码评审时若发现硬编码资源名按「缺失 teardown」同等级别视为缺陷。6.5configure_e2e_tests_env的作用域与 xdist 类不要收窄configure_e2e_tests_env的作用域它是 autouse 且 module 作用域。xdist 下若收窄为 function 作用域teardown 顺序会导致 flaky 测试。--distloadfile下测试类不跨 worker 拆分文件内所有测试包括class Test…中的都在同一 worker 上运行因此模块级常量和 module 作用域 fixture 同时覆盖该文件内的模块级测试与类内测试。如果某个文件切换为--distloadscope需要重新审视作用域契约。七、Agent 贡献工作流与 PR 规范Python SDK 属于 Opik monorepo 的一部分Agent/开发者遵循根级 AGENTS.md 中定义的共享工作流再叠加本模块要求改动前先阅读根级 CONTRIBUTING.md 与 PR 模板在请求评审前针对 Python SDK 变更运行本文档列出的格式化与测试命令PR 标题与首个提交采用语义化风格并带工单前缀[OPIK-1234] [COMPONENT] feat|fix|refactor|docs: short summaryPython SDK 专属惯例适用时使用 SDK 前缀标题如[OPIK-####] [SDK] ...PR 描述应包含变更摘要、测试覆盖情况和关联 issue 引用Resolves #...。八、安全与配置建议安全策略方面模块级规范在根级 AGENTS.md 的基础上增加了一条 Python SDK 专属红线凭据一律通过opik configure或环境变量配置绝不硬编码进源码。根级指南进一步建议密钥与 API key 不得进入版本控制使用本地.env或 shell 变量保存本地自托管测试需先配好 MySQL、ClickHouse、Redis 等依赖跑本地部署上的 SDK 示例优先使用opik configure --use_local。这一原则在仓库中体现为一致的架构SDK 的基地址、API key、workspace、项目名OPIK_PROJECT_NAME等均通过环境变量或opik configure写入的本地配置文件解析参见 configurator/configure.py 与 api_objects/helpers.py 中对环境变量的引用测试代码也大量借助testlib.patch_environ以环境变量注入方式隔离配置——从根源上杜绝密钥泄露与配置污染。结语sdks/python/AGENTS.md虽是一份面向贡献者的规范文件但它浓缩了 Opik Python SDK 工程化的全部关键决策模块化的目录组织、分层测试策略、ruff/mypy 强制的代码风格以及围绕pytest-xdist并行执行设计的资源隔离契约。理解这份契约你不仅能规范地在仓库中贡献代码更能读懂 e2e 套件中每个PROJECT_NAME常量与命名 fixture 背后的并发安全考量——这正是大型开源项目把「测试可并行、可重跑」落到实处的典型范本。【免费下载链接】comet-llmDebug, evaluate, and monitor your LLM applications, RAG systems, and agentic workflows with comprehensive tracing, automated evaluations, and production-ready dashboards.项目地址: https://gitcode.com/GitHub_Trending/co/comet-llm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
