AutoGen .NET dev-team 示例入门指南从零跑通事件驱动的 GitHub AI 开发团队gh-flow【免费下载链接】autogenA programming framework for agentic AI项目地址: https://gitcode.com/GitHub_Trending/au/autogenAutoGen 仓库的dev-team示例又名gh-flow用事件驱动的多 Agent 系统模拟一支完整的 AI 开发团队Product Manager 生成 README、Developer Lead 拆解开发计划、Developer 产出代码全部通过 GitHub Issue 与人类协作完成。本文基于仓库中的入门文档 github-flow-getting-started.md 展开结合 GithubOptions.cs、AzureOptions.cs、seed-memory/Program.cs 等源码完整讲清 GitHub App 注册、本地调试、Azure 部署与向量库初始化的每一步操作与底层机制读完即可把这套 Agent 团队接入自己的仓库。一、这套方案是如何工作的先建立整体图景后面的配置才有意义。整个流程由 GitHub 事件触发详见 README.md用户在 GitHub 仓库创建一个 Issue用自然语言描述要做什么ProductManagerAgent 响应产出 README 草案用户通过 Issue 评论迭代反馈批准后关闭 IssueREADME 被提交进 PRDeveloperLeadAgent 生成拆解后的开发计划同样可迭代批准后按计划为每个子任务创建新的 Dev IssueDeveloperAgent 产出代码批准后提交 PR代码同时会存入 Blob 存储并在沙箱中运行验证。事件流转由HubberAgent 协调创建 Issue、分支、PRAzureGenie负责存储与沙箱调度Sandbox轮询运行结果。这些 Agent 的注册发生在后端入口 Program.csbuilder.AddGrpcAgentWorker(builder.Configuration[AGENT_HOST]!) .AddAgentWorker() .AddAgentAzureGenie(nameof(AzureGenie)) .AddAgentHubber(nameof(Hubber)) .AddAgentDev(nameof(Dev)) .AddAgentProductManager(nameof(ProductManager)) .AddAgentDeveloperLead(nameof(DeveloperLead));可以看到整个系统构建在 AutoGen 的Microsoft.AutoGen.Core与Microsoft.AutoGen.Core.Grpc之上见 DevTeam.Backend.csproj 中的 ProjectReference文档中提到的“依赖 Orleans 的 Agents 实现”即来源于此——Agent 作为 Grpc Agent Worker 运行因此还带有 Orleans Dashboard 可观测能力。二、前置条件在动手之前你需要准备四样东西一个可用的 gpt3.5-turbo 或 gpt4 模型访问权限推荐 gpt4一个按本文配置注册并安装好的GitHub App一套通过 azd 供应好的Azure 资源沙箱、文件存储等一组用于路由的Issue 标签Labels。注册并配置 GitHub App按文档要求注册一个 GitHub App关键选项如下名称与描述任意填写Homepage URL 可填任意值例如仓库地址Webhook URL 先填一个占位值本地跑起来配好隧道后再回填设置一个 Webhook Secret后面要填入appsettings.json的WebhookSecret属性Repository 权限设置为Contents — 读写Issues — 读写Metadata — 只读Pull requests — 读写订阅事件Issues与Issue comment允许任意用户或组织安装该 App。App 创建完成后立即生成一枚 Private Key——它是后端从应用身份调用 GitHub API 的凭证。后端如何用这些配置Program.cs 中GithubAuthService用GithubOptions构造 GitHub 客户端Program.cs 中endpoints.MapGitHubWebhooks(secret: ghOptions.WebhookSecret)表明WebhookSecret会被用于校验每个入站 Webhook 请求的签名因此这个值必须与 App 后台配置完全一致。创建路由标签Labels系统靠 GitHub Issue 上的Label来决定“该和哪个技能/人格说话”。默认的技能与人格对应以下四个标签PM.ReadmeDo.ItDevLead.PlanDeveloper.Implement这些标签不会自动出现在你的仓库中需要手动添加。之后每扩展一个自定义技能别忘了同步添加对应标签。三、本地运行使用 Codespaces仓库为本地调试预置了 Codespaces 环境个人账户有免费额度。在 GitHub 页面上为你的仓库创建一个 CodespaceCodespace 中已装好 azd 等工具并且本地版Qdrant也已就绪这一点在向量库初始化章节会用到。配置 appsettings.json文档指出示例文件夹下提供两个模板appsettings.azure.template.json部署到 Azure 用与appsettings.local.template.json本地运行用。按你的运行环境选用其一重命名为appsettings.json并填写其中的值。当前仓库中的 appsettings.Development.json 只包含日志级别配置业务配置正是通过下面两个配置节绑定进类型化 Options 的。GitHubOptions 配置项对应源码 GithubOptions.cs四个属性均带[Required]校验ValidateOnStart()会在启动时强制检查见 Program.cs配置项类型获取方式AppKeyPrivateKeystring注册 App 时生成的密钥。若当时没保存去 App 设置页“Private keys”处点Generate a new private key会下载一个.pem文件把-----BEGIN RSA PRIVATE KEY-----与-----END RSA PRIVATE KEY-----之间的全部内容在一行内粘贴进来AppIdintApp 设置页顶部的 App IDInstallationIdlong打开该 App 的某个安装页URL 形如https://github.com/settings/installations/installation-id末尾的数字即是WebhookSecretstring注册 App 时在 Webhooks 设置的 Secret 值AzureOptions 配置项对应源码 AzureOptions.cs同样全部必填配置项说明SubscriptionId要使用的 Azure 订阅 IDLocation资源所在区域ContainerInstancesResourceGroup沙箱容器实例Container Instances部署所在的资源组FilesAccountNameAzure Storage 账户名FilesShareName文件共享File Share名称FilesAccountKey存储账户密钥SandboxImage沙箱使用的容器镜像启动应用并暴露 Webhook在 VS Code 的资源管理器中找到解决方案对后端项目文档中称gh-flow项目对应仓库里的 DevTeam.Backend右键选择Debug → Start new instance即可调试启动。启动后必须把本地应用暴露给 GitHub App 的 Webhook。文档以 DevTunnels 为例ngrok 等同类工具同样可行。下面两条命令分别用于一次性创建持久隧道和转发端口TUNNEL_NAME_name_your_tunnel_here_ devtunnel user login devtunnel create -a $TUNNEL_NAME devtunnel port create -p 5244 $TUNNEL_NAME隧道建好后日常只需执行转发命令devtunnel host $TUNNEL_NAME复制得到的本地地址形如https://your_tunnel_name.euw.devtunnels.ms在末尾追加/api/github/webhooks用它更新 GitHub App 的 Webhook URL。这就是后端MapGitHubWebhooks监听的入站端点至此本地链路已经打通。顺带一提Orleans Dashboard由于 Agent 运行时基于 Orleans隧道地址下还提供一块 Dashboardhttps://your_tunnel_name.euw.devtunnels.ms/dashboard上面有运行中 Agent 的有用指标与统计信息调试事件流转时非常实用。四、用 azd 部署 Azure 侧资源示例使用 azdAzure Developer CLICodespace 中已预装管理 Azure 资源。整体流程登录 Azureazd auth login创建新环境并供应资源ENVIRONMENT_name_of_your_env azd env new $ENVIRONMENT azd provision -e $ENVIRONMENT供应完成后查看环境输出值azd env get-values -e devazd 的具体行为由 azure.yaml 定义应用名为ai-dev-team唯一的服务gh-flow指向 DevTeam.AppHost.NET Aspire 主机工程宿主类型为containerappAzure Container Apps。这也解释了前面文档中“在 Azure 上运行时 Qdrant 被部署到 ACA”的说法。五、把 WAF 文档载入向量库seed-memory这是开工前最后一步也是文档反复强调的收尾动作。本地运行时Qdrant 已经在 Codespace 中就绪部署到 Azure 时Qdrant 随 ACA 一起部署。加载器是samples目录下的 seed-memory 项目。操作步骤把config文件夹中的 appsettings.template.json 复制/重命名为appsettings.json填入OpenAI 详情与Qdrant 端点然后执行dotnet run模板文件的字段与 KernelSettings.cs 的JsonPropertyName一一对应如下{ serviceType: AzureOpenAI, serviceId: , deploymentOrModelId: , embeddingDeploymentOrModelId: , endpoint: , apiKey: , qdrantEndpoint: }从源码看seed-memory/Program.cs它用 Semantic Kernel 的MemoryBuilder构建了一个1536 维的 Qdrant 内存存储并绑定 Azure OpenAI 嵌入模型随后逐页解析azure-well-architected.pdf把每页文本以新 GUID 为 ID 写入名为waf的集合collection作为 Agent 团队可检索的“架构知识库”。所以这一步的本质是把 Azure Well-Architected 框架文档向量化入库供后续 Agent 做 RAG 检索。配置加载逻辑同样值得注意KernelSettings.LoadSettings() 优先读取config/appsettings.json找不到时回退到 user secrets两者都缺才会抛出带提示的异常。六、WIP使用 user-secrets 的本地配置方式文档末尾还保留了一段标注为 WIP进行中的本地配置方式通过dotnet user-secrets写入密钥注意这里的键前缀是OpenAI:与Github:顶层键而非AzureOptions/GitHubOptions节dotnet user-secrets set OpenAI:Key your_key dotnet user-secrets set OpenAI:Endpoint https://your_endpoint.openai.azure.com/ dotnet user-secrets set Github:AppId gh_app_id dotnet user-secrets set Github:InstallationId gh_inst_id dotnet user-secrets set Github:WebhookSecret webhook_secret dotnet user-secrets set Github:AppKey gh_app_key官方推荐的完整路径仍是第三节的appsettings.json模板方式user-secrets 方式仅作为过渡手段。七、快速自检清单按顺序核对以下要点即可确认整条链路就绪GitHub App 已注册权限、事件Issues / Issue comment与 Webhook Secret 配置完毕Private Key 已生成仓库中已添加PM.Readme、Do.It、DevLead.Plan、Developer.Implement四个标签appsettings.json中GithubOptions与AzureOptions两组必填值全部填好缺一会在启动校验时失败隧道已指向https://tunnel/api/github/webhooks并回填到 GitHub App 的 Webhook URLazd provision供应的 Azure 资源输出值已核对azd env get-values -e envseed-memory已成功把 WAF 文档写入 Qdrant 的waf集合打开隧道地址下的/dashboard能看到 Orleans 中注册的 Agent 指标。满足以上条件后就可以在仓库中创建带标签的 Issue观察 ProductManager → DeveloperLead → Developer 的整条事件链了。【免费下载链接】autogenA programming framework for agentic AI项目地址: https://gitcode.com/GitHub_Trending/au/autogen创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
AutoGen .NET dev-team 示例入门指南：从零跑通事件驱动的 GitHub AI 开发团队（gh-flow）
AutoGen .NET dev-team 示例入门指南从零跑通事件驱动的 GitHub AI 开发团队gh-flow【免费下载链接】autogenA programming framework for agentic AI项目地址: https://gitcode.com/GitHub_Trending/au/autogenAutoGen 仓库的dev-team示例又名gh-flow用事件驱动的多 Agent 系统模拟一支完整的 AI 开发团队Product Manager 生成 README、Developer Lead 拆解开发计划、Developer 产出代码全部通过 GitHub Issue 与人类协作完成。本文基于仓库中的入门文档 github-flow-getting-started.md 展开结合 GithubOptions.cs、AzureOptions.cs、seed-memory/Program.cs 等源码完整讲清 GitHub App 注册、本地调试、Azure 部署与向量库初始化的每一步操作与底层机制读完即可把这套 Agent 团队接入自己的仓库。一、这套方案是如何工作的先建立整体图景后面的配置才有意义。整个流程由 GitHub 事件触发详见 README.md用户在 GitHub 仓库创建一个 Issue用自然语言描述要做什么ProductManagerAgent 响应产出 README 草案用户通过 Issue 评论迭代反馈批准后关闭 IssueREADME 被提交进 PRDeveloperLeadAgent 生成拆解后的开发计划同样可迭代批准后按计划为每个子任务创建新的 Dev IssueDeveloperAgent 产出代码批准后提交 PR代码同时会存入 Blob 存储并在沙箱中运行验证。事件流转由HubberAgent 协调创建 Issue、分支、PRAzureGenie负责存储与沙箱调度Sandbox轮询运行结果。这些 Agent 的注册发生在后端入口 Program.csbuilder.AddGrpcAgentWorker(builder.Configuration[AGENT_HOST]!) .AddAgentWorker() .AddAgentAzureGenie(nameof(AzureGenie)) .AddAgentHubber(nameof(Hubber)) .AddAgentDev(nameof(Dev)) .AddAgentProductManager(nameof(ProductManager)) .AddAgentDeveloperLead(nameof(DeveloperLead));可以看到整个系统构建在 AutoGen 的Microsoft.AutoGen.Core与Microsoft.AutoGen.Core.Grpc之上见 DevTeam.Backend.csproj 中的 ProjectReference文档中提到的“依赖 Orleans 的 Agents 实现”即来源于此——Agent 作为 Grpc Agent Worker 运行因此还带有 Orleans Dashboard 可观测能力。二、前置条件在动手之前你需要准备四样东西一个可用的 gpt3.5-turbo 或 gpt4 模型访问权限推荐 gpt4一个按本文配置注册并安装好的GitHub App一套通过 azd 供应好的Azure 资源沙箱、文件存储等一组用于路由的Issue 标签Labels。注册并配置 GitHub App按文档要求注册一个 GitHub App关键选项如下名称与描述任意填写Homepage URL 可填任意值例如仓库地址Webhook URL 先填一个占位值本地跑起来配好隧道后再回填设置一个 Webhook Secret后面要填入appsettings.json的WebhookSecret属性Repository 权限设置为Contents — 读写Issues — 读写Metadata — 只读Pull requests — 读写订阅事件Issues与Issue comment允许任意用户或组织安装该 App。App 创建完成后立即生成一枚 Private Key——它是后端从应用身份调用 GitHub API 的凭证。后端如何用这些配置Program.cs 中GithubAuthService用GithubOptions构造 GitHub 客户端Program.cs 中endpoints.MapGitHubWebhooks(secret: ghOptions.WebhookSecret)表明WebhookSecret会被用于校验每个入站 Webhook 请求的签名因此这个值必须与 App 后台配置完全一致。创建路由标签Labels系统靠 GitHub Issue 上的Label来决定“该和哪个技能/人格说话”。默认的技能与人格对应以下四个标签PM.ReadmeDo.ItDevLead.PlanDeveloper.Implement这些标签不会自动出现在你的仓库中需要手动添加。之后每扩展一个自定义技能别忘了同步添加对应标签。三、本地运行使用 Codespaces仓库为本地调试预置了 Codespaces 环境个人账户有免费额度。在 GitHub 页面上为你的仓库创建一个 CodespaceCodespace 中已装好 azd 等工具并且本地版Qdrant也已就绪这一点在向量库初始化章节会用到。配置 appsettings.json文档指出示例文件夹下提供两个模板appsettings.azure.template.json部署到 Azure 用与appsettings.local.template.json本地运行用。按你的运行环境选用其一重命名为appsettings.json并填写其中的值。当前仓库中的 appsettings.Development.json 只包含日志级别配置业务配置正是通过下面两个配置节绑定进类型化 Options 的。GitHubOptions 配置项对应源码 GithubOptions.cs四个属性均带[Required]校验ValidateOnStart()会在启动时强制检查见 Program.cs配置项类型获取方式AppKeyPrivateKeystring注册 App 时生成的密钥。若当时没保存去 App 设置页“Private keys”处点Generate a new private key会下载一个.pem文件把-----BEGIN RSA PRIVATE KEY-----与-----END RSA PRIVATE KEY-----之间的全部内容在一行内粘贴进来AppIdintApp 设置页顶部的 App IDInstallationIdlong打开该 App 的某个安装页URL 形如https://github.com/settings/installations/installation-id末尾的数字即是WebhookSecretstring注册 App 时在 Webhooks 设置的 Secret 值AzureOptions 配置项对应源码 AzureOptions.cs同样全部必填配置项说明SubscriptionId要使用的 Azure 订阅 IDLocation资源所在区域ContainerInstancesResourceGroup沙箱容器实例Container Instances部署所在的资源组FilesAccountNameAzure Storage 账户名FilesShareName文件共享File Share名称FilesAccountKey存储账户密钥SandboxImage沙箱使用的容器镜像启动应用并暴露 Webhook在 VS Code 的资源管理器中找到解决方案对后端项目文档中称gh-flow项目对应仓库里的 DevTeam.Backend右键选择Debug → Start new instance即可调试启动。启动后必须把本地应用暴露给 GitHub App 的 Webhook。文档以 DevTunnels 为例ngrok 等同类工具同样可行。下面两条命令分别用于一次性创建持久隧道和转发端口TUNNEL_NAME_name_your_tunnel_here_ devtunnel user login devtunnel create -a $TUNNEL_NAME devtunnel port create -p 5244 $TUNNEL_NAME隧道建好后日常只需执行转发命令devtunnel host $TUNNEL_NAME复制得到的本地地址形如https://your_tunnel_name.euw.devtunnels.ms在末尾追加/api/github/webhooks用它更新 GitHub App 的 Webhook URL。这就是后端MapGitHubWebhooks监听的入站端点至此本地链路已经打通。顺带一提Orleans Dashboard由于 Agent 运行时基于 Orleans隧道地址下还提供一块 Dashboardhttps://your_tunnel_name.euw.devtunnels.ms/dashboard上面有运行中 Agent 的有用指标与统计信息调试事件流转时非常实用。四、用 azd 部署 Azure 侧资源示例使用 azdAzure Developer CLICodespace 中已预装管理 Azure 资源。整体流程登录 Azureazd auth login创建新环境并供应资源ENVIRONMENT_name_of_your_env azd env new $ENVIRONMENT azd provision -e $ENVIRONMENT供应完成后查看环境输出值azd env get-values -e devazd 的具体行为由 azure.yaml 定义应用名为ai-dev-team唯一的服务gh-flow指向 DevTeam.AppHost.NET Aspire 主机工程宿主类型为containerappAzure Container Apps。这也解释了前面文档中“在 Azure 上运行时 Qdrant 被部署到 ACA”的说法。五、把 WAF 文档载入向量库seed-memory这是开工前最后一步也是文档反复强调的收尾动作。本地运行时Qdrant 已经在 Codespace 中就绪部署到 Azure 时Qdrant 随 ACA 一起部署。加载器是samples目录下的 seed-memory 项目。操作步骤把config文件夹中的 appsettings.template.json 复制/重命名为appsettings.json填入OpenAI 详情与Qdrant 端点然后执行dotnet run模板文件的字段与 KernelSettings.cs 的JsonPropertyName一一对应如下{ serviceType: AzureOpenAI, serviceId: , deploymentOrModelId: , embeddingDeploymentOrModelId: , endpoint: , apiKey: , qdrantEndpoint: }从源码看seed-memory/Program.cs它用 Semantic Kernel 的MemoryBuilder构建了一个1536 维的 Qdrant 内存存储并绑定 Azure OpenAI 嵌入模型随后逐页解析azure-well-architected.pdf把每页文本以新 GUID 为 ID 写入名为waf的集合collection作为 Agent 团队可检索的“架构知识库”。所以这一步的本质是把 Azure Well-Architected 框架文档向量化入库供后续 Agent 做 RAG 检索。配置加载逻辑同样值得注意KernelSettings.LoadSettings() 优先读取config/appsettings.json找不到时回退到 user secrets两者都缺才会抛出带提示的异常。六、WIP使用 user-secrets 的本地配置方式文档末尾还保留了一段标注为 WIP进行中的本地配置方式通过dotnet user-secrets写入密钥注意这里的键前缀是OpenAI:与Github:顶层键而非AzureOptions/GitHubOptions节dotnet user-secrets set OpenAI:Key your_key dotnet user-secrets set OpenAI:Endpoint https://your_endpoint.openai.azure.com/ dotnet user-secrets set Github:AppId gh_app_id dotnet user-secrets set Github:InstallationId gh_inst_id dotnet user-secrets set Github:WebhookSecret webhook_secret dotnet user-secrets set Github:AppKey gh_app_key官方推荐的完整路径仍是第三节的appsettings.json模板方式user-secrets 方式仅作为过渡手段。七、快速自检清单按顺序核对以下要点即可确认整条链路就绪GitHub App 已注册权限、事件Issues / Issue comment与 Webhook Secret 配置完毕Private Key 已生成仓库中已添加PM.Readme、Do.It、DevLead.Plan、Developer.Implement四个标签appsettings.json中GithubOptions与AzureOptions两组必填值全部填好缺一会在启动校验时失败隧道已指向https://tunnel/api/github/webhooks并回填到 GitHub App 的 Webhook URLazd provision供应的 Azure 资源输出值已核对azd env get-values -e envseed-memory已成功把 WAF 文档写入 Qdrant 的waf集合打开隧道地址下的/dashboard能看到 Orleans 中注册的 Agent 指标。满足以上条件后就可以在仓库中创建带标签的 Issue观察 ProductManager → DeveloperLead → Developer 的整条事件链了。【免费下载链接】autogenA programming framework for agentic AI项目地址: https://gitcode.com/GitHub_Trending/au/autogen创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考