尧图网站建设 
GPT-Researcher 自动化测试实战用 GitHub Actions Docker pytest 守护研究 Agent 质量【免费下载链接】gpt-researcherAn autonomous agent that conducts deep research on any data using any LLM providers项目地址: https://gitcode.com/GitHub_Trending/gp/gpt-researcherGPT-Researcher 是一个基于任意 LLM 提供商的自主研究 Agent。本篇技术指南将完整讲解该项目的自动化测试体系如何通过一条 docker-compose 命令在容器中运行测试、如何为 GitHub Actions 配置测试环境与密钥、以及仓库中 pytest 与 CI 工作流的具体实现细节。读完本文你将能够在本仓库中独立复现整套测试流程并理解其离线测试、多版本矩阵等工程化设计的底层原理。自动化测试体系概览GPT-Researcher 仓库的自动化测试代码围绕三个核心部分组织测试用例集合集中在仓库根目录的tests/目录下包含针对检索器如 test_brave_retriever.py、test_serper_retriever.py、爬虫、LLM 成本统计、向量存储、WebSocket 管理器、多 Agent 编排等模块的测试另有两个脚本型测试 tests/report-types.py 与 tests/vector-store.py。测试运行器通过pytest模块执行相关配置声明在 pyproject.toml 的[tool.pytest.ini_options]中。CI 触发机制通过 GitHub Actions 工作流 .github/workflows/tests.yml 在 Pull Request 与推送时自动运行。文档明确指出这套自动化测试最终在Docker 容器中由pytest执行从而保证运行环境与本地开发环境隔离、结果可复现。方式一通过 Docker 命令运行测试仓库的 docker-compose.yml 中专门定义了一个测试服务gpt-researcher-tests它被挂载到testprofile 下默认不会随其他服务一起启动。其完整定义如下gpt-researcher-tests: image: gptresearcher/gpt-researcher-tests build: ./ environment: OPENAI_API_KEY: ${OPENAI_API_KEY} OPENAI_BASE_URL: ${OPENAI_BASE_URL} TAVILY_API_KEY: ${TAVILY_API_KEY} LANGCHAIN_API_KEY: ${LANGCHAIN_API_KEY} LOGGING_LEVEL: INFO profiles: [test] command: /bin/sh -c pip install pytest pytest-asyncio faiss-cpu python -m pytest tests/report-types.py python -m pytest tests/vector-store.py 可以看到该服务复用仓库根目录 Dockerfile基于python:3.12-slim-bookworm构建镜像启动时先补装pytest、pytest-asyncio与faiss-cpu然后依次运行两个脚本型测试。在仓库根目录执行文档提供的官方命令即可运行docker-compose --profile test run --rm gpt-researcher-tests参数说明--profile test显式激活testprofile否则gpt-researcher-tests服务不会被创建run仅启动该服务执行其command不启动其他服务--rm容器退出后自动清理避免残留。与普通docker-compose up不同使用run时服务依赖的OPENAI_API_KEY、TAVILY_API_KEY等环境变量会自动从宿主机的 shell 环境或根目录.env文件中读取对应docker-compose.yml中的${VAR}语法无需手动export。方式二通过 GitHub Actions 自动运行当你在仓库中打开 Pull Request、或向已有 PR 提交新 commit 时GitHub Actions 会自动触发测试。触发规则定义在 .github/workflows/tests.yml 中name: Tests on: pull_request: push: branches: [main, master] concurrency: group: tests-${{ github.workflow }}-${{ github.ref }} cancel-in-progress: trueconcurrency段保证同一分支上新的运行会自动取消仍在执行的旧运行避免资源浪费。工作流内部还声明了GPTR_BLOCK_NETWORK: 1环境变量强制整套测试离线运行后文详述。CI 工作流的三阶段设计当前的tests.yml将流水线拆成三个 Job每一层都对应一条历史教训imports导入检查在 Python 3.11 / 3.12 / 3.13 / 3.14 四个版本的矩阵上依次执行import gpt_researcher、遍历导入gpt_researcher下所有子模块、再导入 ASGI 应用backend.server.app。工作流注释提到v0.16.0 曾因“typing 导入出现在首次使用之后”而在除 3.14 之外的解释器上崩溃这个 Job 就是为了在跑完整测试套件之前以最低成本捕获此类回归。collect收集检查在 Python 3.12 上执行python -m pytest tests/ --collect-only -q。注释指出一个无法导入的测试模块会让整个套件的收集阶段静默失效tests/test_security_fix.py曾因此让pytest tests/数月未真正生效因此必须对收集错误单独设卡。unit单元测试依赖前两个 Job 成功后在 4 个 Python 版本矩阵上安装pip install -e .[test]安装 WeasyPrint 所需的系统库libpango、libharfbuzz 等预热 tiktoken 编码缓存最后运行python -m pytest tests/ \ --forked \ --timeout60 \ -p no:warnings \ --deselect tests/test_researcher_logging.py \ --deselect tests/test_logging_output.py \ --deselect tests/test_mcp.py--forked每个测试在独立进程中运行。工作流注释说明当前测试套件存在跨模块的全局状态泄漏单独运行每个文件时能通过、合并运行时却失败--forked保证了结果不受收集顺序影响--timeout60单个测试超时 60 秒即失败--deselect剔除三个依赖真实 OpenAI 客户端或真实联网搜索的用例如test_mcp.py会执行“NBA 季后赛最新动态”的真实研究任务它们属于需要密钥的“live suite”不应出现在离线 CI 中。本地直接运行 pytest如果不使用 Docker也可以在本机直接运行完整测试套件。先安装包与测试依赖pip install -e .[test][test]依赖组定义在 pyproject.toml 中包含pytest8.0、pytest-asyncio0.24、pytest-timeout2.3、pytest-forked1.6等。随后运行python -m pytest tests/pytest 的默认行为由 pyproject.toml 中的[tool.pytest.ini_options]控制[tool.pytest.ini_options] asyncio_mode auto addopts -v testpaths [tests] python_files test_*.py asyncio_fixture_loop_scope functionasyncio_mode autoasync 测试函数无需显式加装饰器即可被自动识别执行addopts -v默认输出详细结果testpaths [tests]未显式指定路径时默认收集tests/目录python_files test_*.py只收集以test_开头的 Python 文件。配置 GitHub 测试环境与密钥文档要求在使用 GitHub Actions 前先在仓库层面完成以下配置否则依赖外部服务的测试将无法通过Step 1进入仓库的Settings标签页。Step 2在左侧Environments中创建一个名为tests全小写的新环境。Step 3进入该tests环境添加以下两个环境级 SecretsOPENAI_API_KEY用于调用 OpenAI 的 LLM 接口TAVILY_API_KEY用于调用 Tavily 搜索 API。环境变量由 docker-compose.yml 中gpt-researcher-tests服务的environment段透传进容器同样被传递的还有OPENAI_BASE_URL可对接 OpenAI 兼容网关与LANGCHAIN_API_KEYLangSmith 追踪这两项按需配置即可。配置正确后当你新建 PR 或向已有 PR 提交代码时仓库页面的 Checks 区域会出现名为Tests的 GitHub Action 检查项等待其运行完毕后即可看到 imports / collect / unit 各阶段的通过或失败状态。PR 的 CI 检查在全部通过前会保持失败状态作为合并前的质量闸门这一约定也与 CONTRIBUTING.md 中“确保改动通过全部测试后再提交 PR”的贡献流程一致。离线测试保障GPTR_BLOCK_NETWORK 网络开关为了让 CI 中的“离线套件”真正离线而非“假设离线”仓库在 tests/conftest.py 实现了一个网络级 kill-switch当环境变量GPTR_BLOCK_NETWORK1时pytest 会在pytest_configure阶段替换socket.socket.connect拦截所有非回环地址127.0.0.1、::1、localhost的出站连接并抛出NetworkBlocked异常。其设计意图非常明确一个悄悄访问真实搜索或 LLM 端点的测试既不稳定、又会产生真实账单与其让它“慢慢通过并扣费”不如在 PR 阶段就大声失败。这也意味着需要真实密钥的用例如 OpenAI、Tavily 集成测试应通过 mock 客户端或归入单独的 live suite而不是混入离线套件本地调试时若未设置该变量网络开关不会生效测试可正常访问外网。编写与调试测试的实用建议结合本仓库的实践可以沉淀出几条可复用的经验优先保证测试可离线运行凡是会触网搜索或调用 LLM 的用例要么 mock 掉客户端要么显式跳过否则在GPTR_BLOCK_NETWORK1的 CI 中会直接失败注意全局状态隔离套件内多个模块存在全局状态泄漏时可像本仓库一样使用--forked保证进程级隔离并将“去掉该参数”作为后续技术债清理目标为慢速用例设置超时用pytest-timeout的--timeout防止用例无限挂起如真实联网研究任务用--collect-only单独校验收集阶段避免某个模块导入失败导致整批测试被静默跳过而不自知跨解释器验证导入将“导入即成功”作为最廉价的冒烟测试能最快捕获 typing 引用顺序、可选依赖缺失等跨版本回归仓库的importsJob 正是这一思路的产物。结语从一条docker-compose --profile test run --rm gpt-researcher-tests命令到三阶段的 GitHub Actions 流水线GPT-Researcher 的自动化测试体系覆盖了容器化运行、密钥管理、离线网络闸门与多 Python 版本矩阵等完整工程细节。理解这套体系不仅能让你的 PR 顺利通过 CI 检查更能为自建 LLM 应用的质量保障提供一套可复制的参考模板。【免费下载链接】gpt-researcherAn autonomous agent that conducts deep research on any data using any LLM providers项目地址: https://gitcode.com/GitHub_Trending/gp/gpt-researcher创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GPT-Researcher 自动化测试实战：用 GitHub Actions + Docker + pytest 守护研究 Agent 质量
GPT-Researcher 自动化测试实战用 GitHub Actions Docker pytest 守护研究 Agent 质量【免费下载链接】gpt-researcherAn autonomous agent that conducts deep research on any data using any LLM providers项目地址: https://gitcode.com/GitHub_Trending/gp/gpt-researcherGPT-Researcher 是一个基于任意 LLM 提供商的自主研究 Agent。本篇技术指南将完整讲解该项目的自动化测试体系如何通过一条 docker-compose 命令在容器中运行测试、如何为 GitHub Actions 配置测试环境与密钥、以及仓库中 pytest 与 CI 工作流的具体实现细节。读完本文你将能够在本仓库中独立复现整套测试流程并理解其离线测试、多版本矩阵等工程化设计的底层原理。自动化测试体系概览GPT-Researcher 仓库的自动化测试代码围绕三个核心部分组织测试用例集合集中在仓库根目录的tests/目录下包含针对检索器如 test_brave_retriever.py、test_serper_retriever.py、爬虫、LLM 成本统计、向量存储、WebSocket 管理器、多 Agent 编排等模块的测试另有两个脚本型测试 tests/report-types.py 与 tests/vector-store.py。测试运行器通过pytest模块执行相关配置声明在 pyproject.toml 的[tool.pytest.ini_options]中。CI 触发机制通过 GitHub Actions 工作流 .github/workflows/tests.yml 在 Pull Request 与推送时自动运行。文档明确指出这套自动化测试最终在Docker 容器中由pytest执行从而保证运行环境与本地开发环境隔离、结果可复现。方式一通过 Docker 命令运行测试仓库的 docker-compose.yml 中专门定义了一个测试服务gpt-researcher-tests它被挂载到testprofile 下默认不会随其他服务一起启动。其完整定义如下gpt-researcher-tests: image: gptresearcher/gpt-researcher-tests build: ./ environment: OPENAI_API_KEY: ${OPENAI_API_KEY} OPENAI_BASE_URL: ${OPENAI_BASE_URL} TAVILY_API_KEY: ${TAVILY_API_KEY} LANGCHAIN_API_KEY: ${LANGCHAIN_API_KEY} LOGGING_LEVEL: INFO profiles: [test] command: /bin/sh -c pip install pytest pytest-asyncio faiss-cpu python -m pytest tests/report-types.py python -m pytest tests/vector-store.py 可以看到该服务复用仓库根目录 Dockerfile基于python:3.12-slim-bookworm构建镜像启动时先补装pytest、pytest-asyncio与faiss-cpu然后依次运行两个脚本型测试。在仓库根目录执行文档提供的官方命令即可运行docker-compose --profile test run --rm gpt-researcher-tests参数说明--profile test显式激活testprofile否则gpt-researcher-tests服务不会被创建run仅启动该服务执行其command不启动其他服务--rm容器退出后自动清理避免残留。与普通docker-compose up不同使用run时服务依赖的OPENAI_API_KEY、TAVILY_API_KEY等环境变量会自动从宿主机的 shell 环境或根目录.env文件中读取对应docker-compose.yml中的${VAR}语法无需手动export。方式二通过 GitHub Actions 自动运行当你在仓库中打开 Pull Request、或向已有 PR 提交新 commit 时GitHub Actions 会自动触发测试。触发规则定义在 .github/workflows/tests.yml 中name: Tests on: pull_request: push: branches: [main, master] concurrency: group: tests-${{ github.workflow }}-${{ github.ref }} cancel-in-progress: trueconcurrency段保证同一分支上新的运行会自动取消仍在执行的旧运行避免资源浪费。工作流内部还声明了GPTR_BLOCK_NETWORK: 1环境变量强制整套测试离线运行后文详述。CI 工作流的三阶段设计当前的tests.yml将流水线拆成三个 Job每一层都对应一条历史教训imports导入检查在 Python 3.11 / 3.12 / 3.13 / 3.14 四个版本的矩阵上依次执行import gpt_researcher、遍历导入gpt_researcher下所有子模块、再导入 ASGI 应用backend.server.app。工作流注释提到v0.16.0 曾因“typing 导入出现在首次使用之后”而在除 3.14 之外的解释器上崩溃这个 Job 就是为了在跑完整测试套件之前以最低成本捕获此类回归。collect收集检查在 Python 3.12 上执行python -m pytest tests/ --collect-only -q。注释指出一个无法导入的测试模块会让整个套件的收集阶段静默失效tests/test_security_fix.py曾因此让pytest tests/数月未真正生效因此必须对收集错误单独设卡。unit单元测试依赖前两个 Job 成功后在 4 个 Python 版本矩阵上安装pip install -e .[test]安装 WeasyPrint 所需的系统库libpango、libharfbuzz 等预热 tiktoken 编码缓存最后运行python -m pytest tests/ \ --forked \ --timeout60 \ -p no:warnings \ --deselect tests/test_researcher_logging.py \ --deselect tests/test_logging_output.py \ --deselect tests/test_mcp.py--forked每个测试在独立进程中运行。工作流注释说明当前测试套件存在跨模块的全局状态泄漏单独运行每个文件时能通过、合并运行时却失败--forked保证了结果不受收集顺序影响--timeout60单个测试超时 60 秒即失败--deselect剔除三个依赖真实 OpenAI 客户端或真实联网搜索的用例如test_mcp.py会执行“NBA 季后赛最新动态”的真实研究任务它们属于需要密钥的“live suite”不应出现在离线 CI 中。本地直接运行 pytest如果不使用 Docker也可以在本机直接运行完整测试套件。先安装包与测试依赖pip install -e .[test][test]依赖组定义在 pyproject.toml 中包含pytest8.0、pytest-asyncio0.24、pytest-timeout2.3、pytest-forked1.6等。随后运行python -m pytest tests/pytest 的默认行为由 pyproject.toml 中的[tool.pytest.ini_options]控制[tool.pytest.ini_options] asyncio_mode auto addopts -v testpaths [tests] python_files test_*.py asyncio_fixture_loop_scope functionasyncio_mode autoasync 测试函数无需显式加装饰器即可被自动识别执行addopts -v默认输出详细结果testpaths [tests]未显式指定路径时默认收集tests/目录python_files test_*.py只收集以test_开头的 Python 文件。配置 GitHub 测试环境与密钥文档要求在使用 GitHub Actions 前先在仓库层面完成以下配置否则依赖外部服务的测试将无法通过Step 1进入仓库的Settings标签页。Step 2在左侧Environments中创建一个名为tests全小写的新环境。Step 3进入该tests环境添加以下两个环境级 SecretsOPENAI_API_KEY用于调用 OpenAI 的 LLM 接口TAVILY_API_KEY用于调用 Tavily 搜索 API。环境变量由 docker-compose.yml 中gpt-researcher-tests服务的environment段透传进容器同样被传递的还有OPENAI_BASE_URL可对接 OpenAI 兼容网关与LANGCHAIN_API_KEYLangSmith 追踪这两项按需配置即可。配置正确后当你新建 PR 或向已有 PR 提交代码时仓库页面的 Checks 区域会出现名为Tests的 GitHub Action 检查项等待其运行完毕后即可看到 imports / collect / unit 各阶段的通过或失败状态。PR 的 CI 检查在全部通过前会保持失败状态作为合并前的质量闸门这一约定也与 CONTRIBUTING.md 中“确保改动通过全部测试后再提交 PR”的贡献流程一致。离线测试保障GPTR_BLOCK_NETWORK 网络开关为了让 CI 中的“离线套件”真正离线而非“假设离线”仓库在 tests/conftest.py 实现了一个网络级 kill-switch当环境变量GPTR_BLOCK_NETWORK1时pytest 会在pytest_configure阶段替换socket.socket.connect拦截所有非回环地址127.0.0.1、::1、localhost的出站连接并抛出NetworkBlocked异常。其设计意图非常明确一个悄悄访问真实搜索或 LLM 端点的测试既不稳定、又会产生真实账单与其让它“慢慢通过并扣费”不如在 PR 阶段就大声失败。这也意味着需要真实密钥的用例如 OpenAI、Tavily 集成测试应通过 mock 客户端或归入单独的 live suite而不是混入离线套件本地调试时若未设置该变量网络开关不会生效测试可正常访问外网。编写与调试测试的实用建议结合本仓库的实践可以沉淀出几条可复用的经验优先保证测试可离线运行凡是会触网搜索或调用 LLM 的用例要么 mock 掉客户端要么显式跳过否则在GPTR_BLOCK_NETWORK1的 CI 中会直接失败注意全局状态隔离套件内多个模块存在全局状态泄漏时可像本仓库一样使用--forked保证进程级隔离并将“去掉该参数”作为后续技术债清理目标为慢速用例设置超时用pytest-timeout的--timeout防止用例无限挂起如真实联网研究任务用--collect-only单独校验收集阶段避免某个模块导入失败导致整批测试被静默跳过而不自知跨解释器验证导入将“导入即成功”作为最廉价的冒烟测试能最快捕获 typing 引用顺序、可选依赖缺失等跨版本回归仓库的importsJob 正是这一思路的产物。结语从一条docker-compose --profile test run --rm gpt-researcher-tests命令到三阶段的 GitHub Actions 流水线GPT-Researcher 的自动化测试体系覆盖了容器化运行、密钥管理、离线网络闸门与多 Python 版本矩阵等完整工程细节。理解这套体系不仅能让你的 PR 顺利通过 CI 检查更能为自建 LLM 应用的质量保障提供一套可复制的参考模板。【免费下载链接】gpt-researcherAn autonomous agent that conducts deep research on any data using any LLM providers项目地址: https://gitcode.com/GitHub_Trending/gp/gpt-researcher创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考