活动策划多智能体系统
由五个专业智能体协作生成场地、预算、餐饮、天气和日程方案。
各专员仅配置领域相关工具，测试还确认预算代理只有代码解释器，最小权限处理较充分，但未给出 Azure 资源角色、网络权限或工具级授权清单。README 明示人工审批与反馈以及可暂停并保存状态，支持用户确认，但未证明日历创建、搜索或部署等每项外部操作都必须确认。架构、工具分配、服务托管会话、遥测和 .env 生成均有披露，然而具体发送字段、保存期限和第三方数据去向不明。敏感数据处理仅体现 GitHub Secrets、.env 和安全报告渠道，缺少密钥轮换、日志脱敏、个人数据和会话保留规则。依赖大多设置版本范围，关键框架精确固定，并记录 a2a-sdk 兼容性；同时使用预发布组件，且 pip-audit 被设为失败后继续，因此未满分。外部效果（Azure 资源配置、网页搜索、天气查询、日历生成、遥测）有列举，但副作用边界和同意机制不完整。仅说明工作流状态保存，没有部署回滚、日历撤销或数据删除方案。仓库、包作者、版权、许可证和安全报告路径一致且清楚，来源归属充分。
README、包配置、CI 和测试对入口点、工作流标识及主要依赖基本一致，并有依赖注入隔离测试；但“production-ready”等宽泛表述缺乏相应证据，且 README 要求 Python 3.11+、包元数据却允许 3.10。依赖安装、Azure 前置条件和版本约束较明确，CI 覆盖 Python 3.11/3.12，但依赖 Azure 服务、测试版框架和外部 API，离线或降级可用性没有说明。现有材料没有展示面向用户的异常分类、重试、超时、配额或恢复消息，因此失败消息仅有薄弱证据。
目标场景、示例人数、预算、地点、饮食和天气需求清晰，适合教学及企业活动规划，但其他受众与场景覆盖有限。五个代理和各自工具边界明确，仍未记录不支持的任务、日期/地点限制或安全边界。Pydantic 的 next_agent 路由和协调器拓扑为触发精度提供结构，但路由提示词、歧义处理和终止规则未提供。提供 Azure 部署、控制台和 DevUI 两种运行方式，并列明先决条件；不过没有非 Azure 后端、受限网络、区域差异或无云环境的适配说明。
README 的架构、功能、快速开始、目录、开发、资源、贡献和许可证组织完整，信息架构可评为充分。安装与运行命令可直接理解，但主要依赖 azd 自动生成配置，详细环境变量、权限和手工故障排查未包含在所给材料中。包名、脚本入口和工作流 ID 基本稳定，但项目仍为 0.0.1，描述中“Spec-to-Agent”与仓库复数命名略有差异。提供一个具体输入和预期阶段，也有测试命令，但没有完整输出样例或 FAQ。已知限制只通过测试版依赖兼容性注释间接体现，缺少专门限制说明。MIT 文本完整且元数据一致，许可证满分。只有 0.0.1 版本，未见发布策略或 changelog。Microsoft 组织、作者邮箱、贡献说明和 SECURITY.md 给出明确维护与报告路径，维护责任证据充分。
系统承诺综合活动计划，结构化路由、专员分工、控制台和图形界面提升结果可用性，但没有实际输出样例、导出格式或质量约束，故不满分。将搜索、预算计算、餐饮、天气、日历和汇总组合起来，相比单一聊天代理有明确增量价值；不过材料未比较基线或证明各代理确实改善结果。成本收益说明薄弱：README 列出多个 Azure、模型、搜索、容器和遥测资源，却没有费用估算、资源规模、限额、关闭资源方法或低成本配置。
多项具体声明可追溯到包配置、CI 和少量单元测试，例如入口点、依赖、工作流 ID 与预算代理工具；但“production-ready”“one-click”和完整人工审批等主张未被所给测试充分覆盖。README、pyproject、CI 与测试对核心技术栈和运行方式形成一定交叉印证，但缺少工作流端到端测试、提示词、工具实现和基础设施文件，交叉验证有限。事实与推断区分不足，营销性能力陈述没有显式标注为目标、示例或未经运行验证的主张。
- 该评估仅基于所给文件，未执行代码、测试、部署或依赖审计。
- 部署会配置多个可能计费的 Azure 资源；在运行 azd up 前应核对订阅、区域、配额、RBAC、预算告警和清理方式。
- 服务托管会话、Application Insights、网页搜索及外部天气服务可能传输或保留活动与参与者信息；投入真实数据前应确认字段、日志脱敏、保留期和区域合规。
- 日历操作和其他外部副作用的逐项确认、幂等性、撤销及失败恢复没有在证据中建立。
- 核心 Agent Framework 包为测试版，安全审计又允许失败后继续；发布使用前应执行阻断式依赖审计并验证锁文件。
这个 Agent 能做什么，适合哪些场景？
这是一个基于 Microsoft Agent Framework 的活动策划示例，将 Semantic Kernel 的企业级编排与 AutoGen 的多智能体模式结合起来。系统采用以 Event Coordinator 为中心的星形拓扑，协调场地、预算、餐饮和物流等五个专业智能体，并汇总为完整活动方案。它提供 `uv run console` 交互式命令行和 `uv run app` DevUI 两种入口，工作流支持人工审批、反馈以及状态保留。专业智能体可调用 Bing Grounding、Python REPL、Open-Meteo、iCalendar 和 MCP Sequential Thinking。项目通过 `azd up` 部署到 Azure，核心运行依赖 Microsoft Foundry、Azure OpenAI 和其他 Azure 资源，因此更适合作为 Azure 技术栈中的参考实现，而不是可直接迁移到任意平台的成品。
用户通过交互式控制台或 DevUI 提交人数、日期、地点、预算、饮食限制和天气需求等活动说明。Event Coordinator 在星形工作流中把任务路由给专业智能体：Venue Specialist 通过 Bing Grounding 搜索场地，Budget Analyst 使用 Code Interpreter 的 Python REPL 计算预算，Catering Coordinator 搜索餐饮选项，Logistics Manager 调用 Open-Meteo 并使用 iCalendar 工具处理天气与日程。所有智能体均可使用 MCP Sequential Thinking；它们以带 next_agent 字段的 Pydantic 模型返回结构化路由结果。工作流通过 ctx.request_info() 暂停并收集人工审批或反馈，同时依靠 store=True 和 Azure AI Service 管理对话历史，最后由协调器综合各部分输出完整活动方案。
- 采用 Microsoft Agent Framework 的开发团队，需要参考五个专业智能体如何通过中心协调器完成动态路由和结果汇总。
- 企业内部活动团队希望验证一个可人工审批的活动策划原型，覆盖场地、预算、餐饮、天气和日历安排。
- Azure 架构师需要演示 Microsoft Foundry、Azure OpenAI、Bing Grounding、Application Insights 与容器资源的联合部署。
- 智能体工程师希望研究
ctx.request_info()的人工介入流程、store=True的服务托管会话以及 Pydantic 结构化路由。 - 培训讲师需要一个同时展示 Web 搜索、Python 计算、天气 API、iCalendar 和 MCP 推理的多智能体实验项目。
这个 Agent 有哪些优点和局限？
- 以 Event Coordinator 为中心协调五个专业智能体，并使用带
next_agent的 Pydantic 输出实现明确的动态路由。 - 内置框架级人工介入机制，
ctx.request_info()可暂停工作流、收集审批或反馈并保留状态。 - 示例覆盖 Bing Grounding、Python REPL、Open-Meteo、iCalendar 和 MCP Sequential Thinking，工具分工清晰。
- 提供控制台与 DevUI 两种运行入口，并可通过
azd up自动配置 Azure 资源、环境变量和依赖。 store=True利用 Azure AI Service 托管对话历史，减少应用侧手工维护消息状态的工作。
- 核心运行方式绑定 Microsoft Foundry、Azure OpenAI 和 Azure AI Service，资料没有说明其他云或本地模型的替代路径。
- 采用前需要 Azure 订阅，并安装 Python、
uv、Azure CLI 和 Azure Developer CLI，基础设施门槛较高。 - 场地与餐饮搜索依赖 Bing Grounding，天气查询依赖 Open-Meteo；网络或外部服务故障会影响对应步骤。
- 资料没有给出资源定价、预算上限、速率限制或生产环境故障恢复策略，实际运营成本与韧性需要另行评估。
- 展示范围集中在活动策划，未提供证据表明其专业智能体和提示词可以不经修改地覆盖其他业务流程。
如何安装或部署这个 Agent？
前置条件是 Python 3.11+、uv、Azure CLI、Azure Developer CLI 和有效的 Azure 订阅。执行：
git clone https://github.com/microsoft/spec-to-agents.git
cd spec-to-agents
az login
azd auth login
azd upazd up 会配置 Microsoft Foundry 与 OpenAI 模型、生成包含连接信息的 .env，并通过 uv sync 安装 Python 依赖。部署还会配置 Bing Search，并可配置容器注册表、容器应用和 Application Insights。
如何使用这个 Agent？
部署完成后，推荐启动交互式控制台：
uv run console也可以启动可视界面：
uv run app随后打开终端显示的地址，默认是 http://localhost:8080。首次可提交类似请求：为 50 人策划一场 2025 年 12 月 6 日在西雅图举行、预算 5,000 美元的企业节日派对，并要求提供场地、兼顾饮食限制的餐饮方案以及天气预报。运行测试使用：
uv run pytest这个 Agent 与同类方案有什么区别？
该项目明确结合 Semantic Kernel 的企业级编排方式与 AutoGen 的多智能体模式，而不是只采用其中一种思路；资料未提供性能、成本或质量方面的对照测试。
常见问题
运行它需要哪些云账户或凭据？
az login 和 azd auth login 登录。azd up 随后配置 Microsoft Foundry、Azure OpenAI、Bing Search 等资源并生成 .env。可以完全离线运行吗？
人工可以在智能体执行过程中干预吗？
ctx.request_info() 暂停执行以请求用户审批或反馈，并自动保留状态。