AutoGen Python 开发指南基于 uv 工作区的多包开发、质量检查与文档构建实践【免费下载链接】autogenA programming framework for agentic AI项目地址: https://gitcode.com/GitHub_Trending/au/autogen本篇指南面向 AutoGen 项目的 Python 方向开发者与维护者系统讲解python/目录下基于uv工作区的多包开发流程如何搭建虚拟环境、运行格式化/静态检查/测试等全套质量门禁、构建并校验 Sphinx 文档以及用 cookiecutter 模板创建新的 AutoGen 生态包。读完后你可以在当前仓库源码状态下独立完成一次完整的“拉取代码 → 建环境 → 跑检查 → 改文档 → 提交 PR”的开发生命周期。Python 目录是一个 uv 工作区AutoGen 的 Python 代码集中在 python/ 目录中。该目录作为一个单一的uvworkspace统一管理与安装所有项目包而不是各自独立维护的仓库。当前工作区包含以下核心包均为 python/packages/ 下的子目录包定位当前版本autogen-core接口定义与参考实现agent runtime、model、tool、workbench、memory、tracing 等核心抽象0.7.5autogen-agentchat基于autogen-core之上的单 agent / 多 agent 工作流agents 与 teams 库0.7.5autogen-ext生态集成实现例如autogen-ext[openai]提供 OpenAI 模型客户端另有 anthropic、ollama、gemini、docker 等 extras0.7.5autogen-studio用于构建和运行 AutoGen agent 的 Web IDE包名autogenstudio—autogen-test-utils测试工具包0.0.0agbenchAutoGen 基准测试工具Benchmarking Tools—component-schema-gen为组件配置生成 JSON Schema0.1.0magentic-one-cli安装m1命令行工具的 Magentic-One 通用多 agent 系统 CLI0.2.4上述包与版本信息来自各包自己的pyproject.toml例如 packages/autogen-core/pyproject.toml。工作区的成员关系由 python/pyproject.toml 中的[tool.uv.workspace]段声明[tool.uv.workspace] members [packages/*] exclude [packages/autogen-magentic-one]即packages/下所有目录都是工作区成员但autogen-magentic-one被显式排除在同步范围之外。同时[tool.uv.sources]段把autogen-core、autogen-agentchat、autogen-ext、autogenstudio、agbench、component-schema-gen、magentic-one-cli、autogen-test-utils都标记为{ workspace true }意味着包之间的相互依赖例如autogen-ext依赖autogen-core0.7.5在本地开发时会解析为工作区内的源码包而不是从 PyPI 拉取——这正是“基于当前目录状态安装包”的关键机制。autogen-ext采用“核心零依赖 extras 按装”的结构基础依赖只有autogen-core而openai、anthropic、ollama、gemini、docker、graphrag、chromadb、grpc、docker-jupyter-executor等都定义在[project.optional-dependencies]中见 packages/autogen-ext/pyproject.toml。这也是后文uv sync --all-extras命令存在的意义所在。从 0.2.x 迁移而来如果你还在使用 AutoGen Python 0.2.x 的旧 API需要先阅读迁移指南将代码迁移到 0.4.x 及之后的新架构即当前autogen-core/autogen-agentchat/autogen-ext三层结构。迁移指南位于 migration-guide.md。快速开始TL;DR完整走一遍所有检查只需三步在python/目录下执行uv sync --all-extras source .venv/bin/activate poe check三条命令分别完成同步并安装全部包含可选依赖到虚拟环境 → 激活虚拟环境 → 运行整套质量检查格式化、lint、类型检查、测试、文档与示例校验详见下文“常用任务”。环境搭建安装 uvuv是负责创建开发环境并安装包的 Python 包管理器。首先按官方说明安装uv安装后如需升级到最新版运行uv self update创建虚拟环境Virtual Environment开发过程中你经常需要验证自己对任意一个包的改动。此时必须让虚拟环境中的 AutoGen 包基于当前目录的代码状态来安装即工作区内以源码方式解析而非 PyPI 上的发布版。在python/目录的根层级执行uv sync --all-extras source .venv/bin/activateuv sync --all-extras在当前层级创建.venv目录并把当前工作区里的各包packages/*连同它们各自的依赖一起安装。--all-extras标志会额外安装所有可选依赖对应上文autogen-ext等包中定义的 extras使文档构建、gRPC 生成、Docker 代码执行器等依赖可选依赖的开发任务都能运行。source .venv/bin/activate激活该虚拟环境此后的poe、pytest等命令都在其中运行。常用任务poe 质量检查体系提交 PR 前需要满足一组检查。这些检查既可以逐条运行也可以一次性全跑任务命令作用Formatpoe formatruff 格式化Lintpoe lintruff 静态检查Testpoe test运行 pytest 测试Mypypoe mypymypy 类型检查Pyrightpoe pyrightpyright 类型检查Build docspoe docs-build构建 Sphinx 文档Check docspoe docs-check带--fail-on-warning的文档构建Clean docspoe docs-clean删除构建目录与参考目录Check code blocks in API referencespoe docs-check-examples校验 API 参考中的代码块Auto rebuildserve docspoe docs-serve文档自动重建并本地服务Check samples inpython/samplespoe samples-code-check对samples/做 pyright 检查全部检查poe check依次运行上面大部分检查注意以上命令都必须在激活的虚拟环境中运行。poe check到底检查了什么这些任务定义在 python/pyproject.toml 的[tool.poe.tasks]段中其中聚合检查是check [fmt, lint, pyright, mypy, docs-mypy, test, markdown-code-lint, samples-code-check]值得注意的是fmt、lint、pyright、mypy、test这几条并不是直接执行工具而是转发给一个分发脚本fmt python run_task_in_pkgs_if_exist.py fmt lint python run_task_in_pkgs_if_exist.py lint pyright python run_task_in_pkgs_if_exist.py pyright mypy python run_task_in_pkgs_if_exist.py mypy test python run_task_in_pkgs_if_exist.py test分发逻辑由 run_task_in_pkgs_if_exist.py 实现从源码结构看它做了两件事发现项目读取根pyproject.toml的[tool.uv.workspace].members支持 glob如packages/*并应用exclude列表得到实际需要检查的包目录列表逐包转发任务对每个包解析其自身pyproject.toml中的[tool.poe.tasks]含include引用的共享任务只有当该包确实定义了同名任务时才在其目录下用 PoeThePoet 运行任何一个包执行失败返回非零整个检查即失败。各包的具体任务则来自共享定义文件 shared_tasks.toml[tool.poe.tasks] fmt ruff format lint ruff check mypy mypy --config-file $POE_ROOT/../../pyproject.toml src tests pyright pyright也就是说每个包复用了同一套 ruff / mypy / pyright 配置统一指向python/pyproject.toml的[tool.ruff]、[tool.mypy]、[tool.pyright]段而像autogen-ext还会在自身pyproject.toml中额外定义test pytest -n auto等包级任务。根配置中的工具版本与严格度同样来自 python/pyproject.toml包括ruffline-length 120、fix true目标版本py310lint 规则集E, F, W, B, Q, I, ASYNC, T20且通过banned-api明确禁止使用unittest要求“Usepytestinstead”mypystrict truepython_version 3.10并开启disallow_untyped_defs、no_implicit_optional等严格项pyrighttypeCheckingMode strict检查范围覆盖src、tests、samplespytest定义了grpcmarker“tests invoking gRPC functionality”便于筛选 gRPC 相关测试。因此一次poe check实际是ruff 格式化与 lint、pyright strict 类型检查、mypy strict 类型检查、文档 notebook 的 mypy 检查docs-mypy nbqa mypy docs/src ...、全量测试、根 README 与 docs 中 Markdown 代码块的 lintmarkdown-code-lint、以及samples/目录的 pyright 检查samples-code-check pyright ./samples。同步依赖Syncing Dependencies当你 pull 到新代码后可能需要更新虚拟环境中的依赖。确认自己已处于虚拟环境中然后在python/目录运行uv sync --all-extras该命令会按当前pyproject.toml与uv.lock的最新状态刷新虚拟环境中的依赖。构建文档Building Documentation文档源目录位于 docs/src/采用 Sphinx MyST 构建。在python/目录根下# 构建文档 poe docs-build # 本地自动重建并服务文档 poe docs-serve对应 python/pyproject.toml 中的任务定义docs-build sphinx-build docs/src docs/build docs-serve sphinx-autobuild docs/src docs/build --watch packages/ --port 8000 --jobs auto docs-check sphinx-build --fail-on-warning docs/src docs/build docs-check-examples sphinx-build -b code_lint docs/src docs/build docs-clean rm -rf docs/build docs/src/referencedocs-serve会同时监视packages/目录源码或文档字符串一有改动即自动重建并热更新。当你修改了 docstring 或新增模块后API 参考页可能需要刷新——先清理再重建poe docs-clean # 删除构建目录 docs/build 和参考目录 docs/src/reference poe docs-build # 从零重建整个文档API 参考的目录结构由脚本自动生成generate_api_reference.py 会扫描autogen_core、autogen_agentchat、autogen_ext三个包的模块为 API 文档的index.md生成 toctree 条目因此新增公开模块后“clean build”流程尤为重要。撰写文档docstring 规范新增公开类或函数时必须补充 docstring。docstring 遵循 Google 风格布局与 Sphinx RST 格式应包含紧跟之后的简短描述必要时的长描述说明用途与用法Args小节列出每个参数名、类型与简述Returns小节返回值及其类型无返回值可省略Raises小节可选但推荐函数可能抛出的异常及说明Examples小节使用示例用.. code-block:: python指令书写可选地用.. code-block:: text附上输出。文档给出了McpWorkbench的完整示例其核心用法是作为上下文管理器包裹 MCP 会话class McpWorkbench(Workbench, Component[McpWorkbenchConfig]): A workbench that wraps an MCP server and provides an interface to list and call tools provided by the server. ... Examples: Here is a simple example of how to use the workbench with a mcp-server-fetch server: .. code-block:: python import asyncio from autogen_ext.tools.mcp import McpWorkbench, StdioServerParams async def main() - None: params StdioServerParams( commanduvx, args[mcp-server-fetch], read_timeout_seconds60, ) # You can also use start() and stop() to manage the session. async with McpWorkbench(server_paramsparams) as workbench: tools await workbench.list_tools() print(tools) result await workbench.call_tool(tools[0][name], {url: https://github.com/}) print(result) asyncio.run(main()) 三条配套规则代码块会被静态检查。.. code-block:: python中的代码块由docs-check-examples任务sphinx-build -b code_lint交给 Pyright 校验代码必须可类型检查通过作者建议“把示例当脚本跑一遍并用 pyright 检查”来确保正确性。交叉引用使用 Sphinx 指令。引用类、方法或函数时必须用:class:、:meth:、:func:指令建立链接且始终写包含包名的全限定名并用~前缀缩短渲染效果。例如引用autogen-agentchat包中的AssistantAgent类应写作:class:~autogen_agentchat.AssistantAgent。公开数据类包括 Pydantic 模型的每个字段也要写 docstring。编写测试Writing Tests新增公开类或函数时必须同时补充测试项目跟踪测试覆盖率目标是新改动不降低覆盖率。规范要点统一使用pytest并始终使用 fixtures来组织测试依赖使用 mock 对象模拟依赖避免在测试中发起真实 API 调用或数据库查询可参考 packages/autogen-core/tests/ 等目录下既有测试的写法对模型客户端使用autogen_ext.models.replay.ReplayChatCompletionClient作为模型客户端的“直接替换件”drop-in replacement通过回放预设响应来模拟 LLM无需真实 API 调用。该客户端的实现位于 packages/autogen-ext/src/autogen_ext/models/replay/确实需要真实模型 API 或外部服务的测试必须配置成“服务不可用时跳过”。例如测试依赖 OpenAI API key 的模型客户端时可用pytest.mark.skipif装饰器在环境变量API key未设置时跳过该测试。创建新的 AutoGen 包要创建一个与autogen-core、autogen-agentchat同级的新包使用仓库自带的 cookiecutter 模板uv sync --python 3.12 source .venv/bin/activate cookiecutter ./templates/new-package/模板位于 templates/new-package/由 cookiecutter.json 驱动交互输入项包括package_name默认my-project新包名version默认0.1.dev0版本号description包描述depends_on_core默认false是否依赖autogen-core__final_destination固定为../packages即生成的包会直接落在packages/下自动成为 uv 工作区成员。生成出的包骨架{{cookiecutter.package_name}}/目录包含pyproject.toml、README.md、LICENSE-CODE、src/与tests/。生成的pyproject.toml有两个值得注意的继承设计[tool.ruff] extend ../../pyproject.toml [tool.pyright] extends ../../pyproject.toml [tool.poe] include ../../shared_tasks.toml [tool.poe.tasks] test pytest -n auto即新包自动复用工作区根部的 ruff/pyright 严格配置与共享的fmt/lint/mypy/pyright任务并自带并行测试任务pytest -n auto——创建完成后无需额外配置poe check的分发脚本就会把新包纳入整套检查范围。小结一次完整开发循环把上文串起来在 AutoGen 的 Python 侧维护一个特性或修一个缺陷的完整闭环是uv sync --all-extras source .venv/bin/activate建立/刷新工作区环境pull 新代码后重复执行在packages/对应包中修改代码补写符合 Google 风格 Sphinx RST 的 docstring并编写基于 fixtures 与 mock模型场景用ReplayChatCompletionClient的 pytest 用例poe check一次性通过 fmt / lint / pyright / mypy / docs-mypy / test / markdown-code-lint / samples-code-check 全套门禁若涉及公开 API 变动poe docs-cleanpoe docs-build刷新 API 参考poe docs-serve本地审阅新增独立包时用cookiecutter ./templates/new-package/生成骨架后同样纳入上述检查循环。以上流程的每一项都能在当前仓库中找到对应依据工作区声明与任务定义在 python/pyproject.toml任务分发逻辑在 python/run_task_in_pkgs_if_exist.py共享任务在 python/shared_tasks.toml包清单在 python/packages/文档源在 python/docs/src/新包模板在 python/templates/new-package/。【免费下载链接】autogenA programming framework for agentic AI项目地址: https://gitcode.com/GitHub_Trending/au/autogen创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
AutoGen Python 开发指南：基于 uv 工作区的多包开发、质量检查与文档构建实践
AutoGen Python 开发指南基于 uv 工作区的多包开发、质量检查与文档构建实践【免费下载链接】autogenA programming framework for agentic AI项目地址: https://gitcode.com/GitHub_Trending/au/autogen本篇指南面向 AutoGen 项目的 Python 方向开发者与维护者系统讲解python/目录下基于uv工作区的多包开发流程如何搭建虚拟环境、运行格式化/静态检查/测试等全套质量门禁、构建并校验 Sphinx 文档以及用 cookiecutter 模板创建新的 AutoGen 生态包。读完后你可以在当前仓库源码状态下独立完成一次完整的“拉取代码 → 建环境 → 跑检查 → 改文档 → 提交 PR”的开发生命周期。Python 目录是一个 uv 工作区AutoGen 的 Python 代码集中在 python/ 目录中。该目录作为一个单一的uvworkspace统一管理与安装所有项目包而不是各自独立维护的仓库。当前工作区包含以下核心包均为 python/packages/ 下的子目录包定位当前版本autogen-core接口定义与参考实现agent runtime、model、tool、workbench、memory、tracing 等核心抽象0.7.5autogen-agentchat基于autogen-core之上的单 agent / 多 agent 工作流agents 与 teams 库0.7.5autogen-ext生态集成实现例如autogen-ext[openai]提供 OpenAI 模型客户端另有 anthropic、ollama、gemini、docker 等 extras0.7.5autogen-studio用于构建和运行 AutoGen agent 的 Web IDE包名autogenstudio—autogen-test-utils测试工具包0.0.0agbenchAutoGen 基准测试工具Benchmarking Tools—component-schema-gen为组件配置生成 JSON Schema0.1.0magentic-one-cli安装m1命令行工具的 Magentic-One 通用多 agent 系统 CLI0.2.4上述包与版本信息来自各包自己的pyproject.toml例如 packages/autogen-core/pyproject.toml。工作区的成员关系由 python/pyproject.toml 中的[tool.uv.workspace]段声明[tool.uv.workspace] members [packages/*] exclude [packages/autogen-magentic-one]即packages/下所有目录都是工作区成员但autogen-magentic-one被显式排除在同步范围之外。同时[tool.uv.sources]段把autogen-core、autogen-agentchat、autogen-ext、autogenstudio、agbench、component-schema-gen、magentic-one-cli、autogen-test-utils都标记为{ workspace true }意味着包之间的相互依赖例如autogen-ext依赖autogen-core0.7.5在本地开发时会解析为工作区内的源码包而不是从 PyPI 拉取——这正是“基于当前目录状态安装包”的关键机制。autogen-ext采用“核心零依赖 extras 按装”的结构基础依赖只有autogen-core而openai、anthropic、ollama、gemini、docker、graphrag、chromadb、grpc、docker-jupyter-executor等都定义在[project.optional-dependencies]中见 packages/autogen-ext/pyproject.toml。这也是后文uv sync --all-extras命令存在的意义所在。从 0.2.x 迁移而来如果你还在使用 AutoGen Python 0.2.x 的旧 API需要先阅读迁移指南将代码迁移到 0.4.x 及之后的新架构即当前autogen-core/autogen-agentchat/autogen-ext三层结构。迁移指南位于 migration-guide.md。快速开始TL;DR完整走一遍所有检查只需三步在python/目录下执行uv sync --all-extras source .venv/bin/activate poe check三条命令分别完成同步并安装全部包含可选依赖到虚拟环境 → 激活虚拟环境 → 运行整套质量检查格式化、lint、类型检查、测试、文档与示例校验详见下文“常用任务”。环境搭建安装 uvuv是负责创建开发环境并安装包的 Python 包管理器。首先按官方说明安装uv安装后如需升级到最新版运行uv self update创建虚拟环境Virtual Environment开发过程中你经常需要验证自己对任意一个包的改动。此时必须让虚拟环境中的 AutoGen 包基于当前目录的代码状态来安装即工作区内以源码方式解析而非 PyPI 上的发布版。在python/目录的根层级执行uv sync --all-extras source .venv/bin/activateuv sync --all-extras在当前层级创建.venv目录并把当前工作区里的各包packages/*连同它们各自的依赖一起安装。--all-extras标志会额外安装所有可选依赖对应上文autogen-ext等包中定义的 extras使文档构建、gRPC 生成、Docker 代码执行器等依赖可选依赖的开发任务都能运行。source .venv/bin/activate激活该虚拟环境此后的poe、pytest等命令都在其中运行。常用任务poe 质量检查体系提交 PR 前需要满足一组检查。这些检查既可以逐条运行也可以一次性全跑任务命令作用Formatpoe formatruff 格式化Lintpoe lintruff 静态检查Testpoe test运行 pytest 测试Mypypoe mypymypy 类型检查Pyrightpoe pyrightpyright 类型检查Build docspoe docs-build构建 Sphinx 文档Check docspoe docs-check带--fail-on-warning的文档构建Clean docspoe docs-clean删除构建目录与参考目录Check code blocks in API referencespoe docs-check-examples校验 API 参考中的代码块Auto rebuildserve docspoe docs-serve文档自动重建并本地服务Check samples inpython/samplespoe samples-code-check对samples/做 pyright 检查全部检查poe check依次运行上面大部分检查注意以上命令都必须在激活的虚拟环境中运行。poe check到底检查了什么这些任务定义在 python/pyproject.toml 的[tool.poe.tasks]段中其中聚合检查是check [fmt, lint, pyright, mypy, docs-mypy, test, markdown-code-lint, samples-code-check]值得注意的是fmt、lint、pyright、mypy、test这几条并不是直接执行工具而是转发给一个分发脚本fmt python run_task_in_pkgs_if_exist.py fmt lint python run_task_in_pkgs_if_exist.py lint pyright python run_task_in_pkgs_if_exist.py pyright mypy python run_task_in_pkgs_if_exist.py mypy test python run_task_in_pkgs_if_exist.py test分发逻辑由 run_task_in_pkgs_if_exist.py 实现从源码结构看它做了两件事发现项目读取根pyproject.toml的[tool.uv.workspace].members支持 glob如packages/*并应用exclude列表得到实际需要检查的包目录列表逐包转发任务对每个包解析其自身pyproject.toml中的[tool.poe.tasks]含include引用的共享任务只有当该包确实定义了同名任务时才在其目录下用 PoeThePoet 运行任何一个包执行失败返回非零整个检查即失败。各包的具体任务则来自共享定义文件 shared_tasks.toml[tool.poe.tasks] fmt ruff format lint ruff check mypy mypy --config-file $POE_ROOT/../../pyproject.toml src tests pyright pyright也就是说每个包复用了同一套 ruff / mypy / pyright 配置统一指向python/pyproject.toml的[tool.ruff]、[tool.mypy]、[tool.pyright]段而像autogen-ext还会在自身pyproject.toml中额外定义test pytest -n auto等包级任务。根配置中的工具版本与严格度同样来自 python/pyproject.toml包括ruffline-length 120、fix true目标版本py310lint 规则集E, F, W, B, Q, I, ASYNC, T20且通过banned-api明确禁止使用unittest要求“Usepytestinstead”mypystrict truepython_version 3.10并开启disallow_untyped_defs、no_implicit_optional等严格项pyrighttypeCheckingMode strict检查范围覆盖src、tests、samplespytest定义了grpcmarker“tests invoking gRPC functionality”便于筛选 gRPC 相关测试。因此一次poe check实际是ruff 格式化与 lint、pyright strict 类型检查、mypy strict 类型检查、文档 notebook 的 mypy 检查docs-mypy nbqa mypy docs/src ...、全量测试、根 README 与 docs 中 Markdown 代码块的 lintmarkdown-code-lint、以及samples/目录的 pyright 检查samples-code-check pyright ./samples。同步依赖Syncing Dependencies当你 pull 到新代码后可能需要更新虚拟环境中的依赖。确认自己已处于虚拟环境中然后在python/目录运行uv sync --all-extras该命令会按当前pyproject.toml与uv.lock的最新状态刷新虚拟环境中的依赖。构建文档Building Documentation文档源目录位于 docs/src/采用 Sphinx MyST 构建。在python/目录根下# 构建文档 poe docs-build # 本地自动重建并服务文档 poe docs-serve对应 python/pyproject.toml 中的任务定义docs-build sphinx-build docs/src docs/build docs-serve sphinx-autobuild docs/src docs/build --watch packages/ --port 8000 --jobs auto docs-check sphinx-build --fail-on-warning docs/src docs/build docs-check-examples sphinx-build -b code_lint docs/src docs/build docs-clean rm -rf docs/build docs/src/referencedocs-serve会同时监视packages/目录源码或文档字符串一有改动即自动重建并热更新。当你修改了 docstring 或新增模块后API 参考页可能需要刷新——先清理再重建poe docs-clean # 删除构建目录 docs/build 和参考目录 docs/src/reference poe docs-build # 从零重建整个文档API 参考的目录结构由脚本自动生成generate_api_reference.py 会扫描autogen_core、autogen_agentchat、autogen_ext三个包的模块为 API 文档的index.md生成 toctree 条目因此新增公开模块后“clean build”流程尤为重要。撰写文档docstring 规范新增公开类或函数时必须补充 docstring。docstring 遵循 Google 风格布局与 Sphinx RST 格式应包含紧跟之后的简短描述必要时的长描述说明用途与用法Args小节列出每个参数名、类型与简述Returns小节返回值及其类型无返回值可省略Raises小节可选但推荐函数可能抛出的异常及说明Examples小节使用示例用.. code-block:: python指令书写可选地用.. code-block:: text附上输出。文档给出了McpWorkbench的完整示例其核心用法是作为上下文管理器包裹 MCP 会话class McpWorkbench(Workbench, Component[McpWorkbenchConfig]): A workbench that wraps an MCP server and provides an interface to list and call tools provided by the server. ... Examples: Here is a simple example of how to use the workbench with a mcp-server-fetch server: .. code-block:: python import asyncio from autogen_ext.tools.mcp import McpWorkbench, StdioServerParams async def main() - None: params StdioServerParams( commanduvx, args[mcp-server-fetch], read_timeout_seconds60, ) # You can also use start() and stop() to manage the session. async with McpWorkbench(server_paramsparams) as workbench: tools await workbench.list_tools() print(tools) result await workbench.call_tool(tools[0][name], {url: https://github.com/}) print(result) asyncio.run(main()) 三条配套规则代码块会被静态检查。.. code-block:: python中的代码块由docs-check-examples任务sphinx-build -b code_lint交给 Pyright 校验代码必须可类型检查通过作者建议“把示例当脚本跑一遍并用 pyright 检查”来确保正确性。交叉引用使用 Sphinx 指令。引用类、方法或函数时必须用:class:、:meth:、:func:指令建立链接且始终写包含包名的全限定名并用~前缀缩短渲染效果。例如引用autogen-agentchat包中的AssistantAgent类应写作:class:~autogen_agentchat.AssistantAgent。公开数据类包括 Pydantic 模型的每个字段也要写 docstring。编写测试Writing Tests新增公开类或函数时必须同时补充测试项目跟踪测试覆盖率目标是新改动不降低覆盖率。规范要点统一使用pytest并始终使用 fixtures来组织测试依赖使用 mock 对象模拟依赖避免在测试中发起真实 API 调用或数据库查询可参考 packages/autogen-core/tests/ 等目录下既有测试的写法对模型客户端使用autogen_ext.models.replay.ReplayChatCompletionClient作为模型客户端的“直接替换件”drop-in replacement通过回放预设响应来模拟 LLM无需真实 API 调用。该客户端的实现位于 packages/autogen-ext/src/autogen_ext/models/replay/确实需要真实模型 API 或外部服务的测试必须配置成“服务不可用时跳过”。例如测试依赖 OpenAI API key 的模型客户端时可用pytest.mark.skipif装饰器在环境变量API key未设置时跳过该测试。创建新的 AutoGen 包要创建一个与autogen-core、autogen-agentchat同级的新包使用仓库自带的 cookiecutter 模板uv sync --python 3.12 source .venv/bin/activate cookiecutter ./templates/new-package/模板位于 templates/new-package/由 cookiecutter.json 驱动交互输入项包括package_name默认my-project新包名version默认0.1.dev0版本号description包描述depends_on_core默认false是否依赖autogen-core__final_destination固定为../packages即生成的包会直接落在packages/下自动成为 uv 工作区成员。生成出的包骨架{{cookiecutter.package_name}}/目录包含pyproject.toml、README.md、LICENSE-CODE、src/与tests/。生成的pyproject.toml有两个值得注意的继承设计[tool.ruff] extend ../../pyproject.toml [tool.pyright] extends ../../pyproject.toml [tool.poe] include ../../shared_tasks.toml [tool.poe.tasks] test pytest -n auto即新包自动复用工作区根部的 ruff/pyright 严格配置与共享的fmt/lint/mypy/pyright任务并自带并行测试任务pytest -n auto——创建完成后无需额外配置poe check的分发脚本就会把新包纳入整套检查范围。小结一次完整开发循环把上文串起来在 AutoGen 的 Python 侧维护一个特性或修一个缺陷的完整闭环是uv sync --all-extras source .venv/bin/activate建立/刷新工作区环境pull 新代码后重复执行在packages/对应包中修改代码补写符合 Google 风格 Sphinx RST 的 docstring并编写基于 fixtures 与 mock模型场景用ReplayChatCompletionClient的 pytest 用例poe check一次性通过 fmt / lint / pyright / mypy / docs-mypy / test / markdown-code-lint / samples-code-check 全套门禁若涉及公开 API 变动poe docs-cleanpoe docs-build刷新 API 参考poe docs-serve本地审阅新增独立包时用cookiecutter ./templates/new-package/生成骨架后同样纳入上述检查循环。以上流程的每一项都能在当前仓库中找到对应依据工作区声明与任务定义在 python/pyproject.toml任务分发逻辑在 python/run_task_in_pkgs_if_exist.py共享任务在 python/shared_tasks.toml包清单在 python/packages/文档源在 python/docs/src/新包模板在 python/templates/new-package/。【免费下载链接】autogenA programming framework for agentic AI项目地址: https://gitcode.com/GitHub_Trending/au/autogen创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考