用GitHub Copilot智能体把会议记录变成项目计划

在技术咨询和交付领域，从客户沟通到可执行的项目计划之间，往往横亘着大量重复性的内部对齐工作。在微软 MVP 访谈节目《MVP Unplugged》的一期中，Azure 解决方案负责人 Mahmoud Atallah 展示了一套基于 GitHub Copilot 的"Delivery Factory"智能体工作流，能够把一段杂乱的会议转录或技术方案 PDF，直接转化为结构化的项目计划、任务清单、风险识别乃至追加销售机会。

这不是简单的"提示词魔法"，而是一套结合了多技能智能体、MCP 服务器与标准化模板资产的系统设计。本文梳理其核心思路与实现要点。

问题起点：非结构化输入到可执行交付的鸿沟

Mahmoud 从自己作为交付负责人的日常痛点切入。他每天接收的提案往往包含工作范围、需求、项目时间线、工作量估算等信息，但这些内容大多以非结构化方式散落在文档或转录里。即便是结构化文档，也只是"写出来了"，离可执行的任务拆解还有很大距离。

主持人 Justin Garrett 结合自己早年在技术咨询行业的经历补充道，从"想法"到"落地"的时间如果能够压缩，本身就是一种竞争优势。他回忆过去手工制作一份客户简报"literally 要花一整天"，而现在用这套智能体只需几分钟。

智能体要解决的，正是把 PDF、文档、简报或转录这类原始输入，自动转化为 runbook、任务列表和风险清单的过程。

工作流拆解：从识别源到并行产出

Mahmoud 把整个智能体流程拆成了几个清晰的阶段，每个阶段对应一个独立的技能（skill）。

第一步：识别并归一化输入

智能体首先判断输入源的类型。由于模型处理 Markdown 远比处理 PDF 高效，无论输入是 PDF 还是纯文本转录，智能体都会先将其转换为结构化的 Markdown 文件，作为后续处理的统一基础。

第二步：提取关键需求

在 Markdown 就绪后，智能体调用第二个技能，提取范围、涉及的服务、时间线等关键组件。这里 Mahmoud 引入了一个关键设计——把智能体接入了 Azure MCP Server 和 Microsoft Learn MCP。

作为遵循 Well-Architected Framework 的交付架构师，他需要确保方案范围与微软标准对齐。通过 MCP，智能体可以实时核对范围、规范化数据，并引入微软官方的最新实践建议。他举了一个例子：在一次安全差距分析中，工具通过 Microsoft Learn 发现了他本人都尚未知晓的新安全标准，额外给出了上百条建议。

Justin 对此评价说，在 AI 和技术快速迭代的当下，没有任何个人能跟上所有变化，让工具自动溯源最新文档既是好的业务实践，也是好的客户服务。

MCP（Model Context Protocol） 是 Anthropic 于2024年底提出并开源的一套开放协议，旨在为 AI 模型提供标准化的"工具调用"接口，使其能够安全、可控地连接外部数据源和服务。类比于 USB-C 接口统一了硬件连接方式，MCP 为 AI 智能体与各类系统（数据库、API、文档库）之间的交互提供了统一规范。Azure MCP Server 是微软基于该协议实现的服务端，允许智能体调用 Azure 资源与配置信息；Microsoft Learn MCP 则使智能体能够实时检索微软官方技术文档。这种设计的核心价值在于：智能体不再依赖训练数据中的静态知识，而是能在推理时主动拉取最新的权威内容，有效解决大模型知识截止日期带来的信息滞后问题。

第三步：双轨并行产出

到了第四、五阶段，工作负载被分成两条并行轨道：一条面向交付/执行团队，另一条面向项目经理。左侧生成项目计划、客户启动会议所需的关键问题、以及可直接呈现给客户的一页纸执行摘要；同时附带来自微软的架构框架与补充建议。

为什么不是"一个提示词"就能搞定

这是整期节目中最值得技术读者关注的一点。Mahmoud 强调，这套系统之所以能每次产出标准一致的文件，关键在于智能体背后连接了资产（assets）——包含关键值和结构化数据的 JSON 文件。

如果仅靠系统提示词（system prompt），不可能保证每次都生成符合标准实践的产物。更进一步，他把大量原本需要调用模型和 LLM 的动作，改写成了读取原始 JSON 文件和执行 PowerShell / Bash 脚本的方式。

这样做带来两个直接收益：一是节省 token，二是大幅缩短耗时。他透露，最初端到端生成全套交付物需要 15 到 30 分钟，而通过预生成文件和脚本化执行，现场演示中仅用三五分钟就完成了全部产出。

智能体在产出前还会先检查本地文件夹结构，查找是否存在与该客户（如演示中的"Company X"）相关的历史文件，进行信息关联与增量更新，而非每次都从零生成——该加则加，该删则删。

这里涉及 AI 工程领域的一个核心权衡：LLM 调用 vs. 确定性执行。每次调用大语言模型都会消耗 token（直接对应 API 费用），且输出具有一定随机性，难以保证格式完全一致。而读取预先生成好的 JSON 文件或执行 Shell 脚本，速度快、成本几乎为零、结果完全可预测。这种"能用脚本做的就不用模型做"的原则，是生产级 AI 系统工程化的关键思路之一——将 LLM 的使用范围严格限定在真正需要语言理解与生成的环节，其余环节回归传统的确定性计算。Mahmoud 的优化使端到端耗时从15-30分钟压缩到几分钟，本质上是把大量"格式填充"类工作从模型推理转移到了文件读写层。

实际演示：转录与 PDF 两种输入

演示中，Mahmoud 先后用了两类输入。一是非结构化的会议转录（含"70 台服务器、20 个 Oracle、6 个 MySQL、400 用户"等关键细节），二是一份标准技术方案 PDF。

他的操作极其简单：切换到 Delivery Factory 智能体模式，附上文件路径即可，几乎不需要额外写提示词，因为智能体本身已内置了路由逻辑，能自动识别这是交付类需求并调用对应技能。

最终产出中，Mahmoud 最满意的是任务序列表：每个任务标注所属阶段、并直接分配给团队成员，甚至可以生成 Asana 导入文件。Justin 指出，如果把团队人员及其角色作为上下文传入，这类计划的实用性会进一步增强。

智能体的角色化与开源共享

在 VS Code 中，Mahmoud 维护着多个各司其职的智能体——Principal Architect、SaaS Architect、Microsoft Learn Contributor、Senior Architect 等，每个都有独立的目标、技能集和脚本。

这些智能体采用不同的角色人格（persona），使得生成的计划和文档能够根据角色与底层技能自适应调整。更重要的是，他已将整套结构发布到 GitHub 仓库：每个智能体都有 Markdown 说明用于克隆复用，content 文件夹下分别存放指令、提示词和脚本，社区成员可以直接贡献，也能基于 Terraform 等技能进一步扩展。

在 GitHub Copilot 的扩展生态中，自定义智能体（Custom Agent / Copilot Extensions） 允许开发者为特定场景定义独立的指令集、工具调用权限和人格设定（persona）。每个智能体通过 Markdown 文件描述其目标与能力边界，配合 instructions、prompts 和 scripts 三类资产组织内容。这种模块化设计的好处是：不同角色的智能体可以共享底层工具（如同一套 MCP 连接），却产出风格和侧重点不同的交付物——Principal Architect 会更关注架构合规性，而 SaaS Architect 则侧重云原生服务选型。将这些定义文件开源到 GitHub，本质上是在共享一套"智能体配置即代码"（Agent-as-Code）的实践范式，社区成员 fork 后只需替换自己的资产文件即可快速复用。

从 Vibe Coding 到多智能体编排

谈到未来，Mahmoud 坦言自己并非开发者出身。过去尝试 vibe coding 时，结果常常达不到预期，反复让智能体重做、消耗大量 token。而现在，"我脑子里想的，基本都能直接实现"。

他认为真正改变的不只是 AI 本身，而是整个工作方式：作为 IT 从业者，他不写代码、不手动调用 API，却能熟练借助智能体完成 Git 版本管理、MCP 调用等工作。下一步，他看好多智能体编排（multi-agent orchestrator）——事实上他已经在社区运营、活动管理、营销、沟通等场景中部署了各自分工的智能体。

这个案例的价值不在于某个具体工具，而在于展示了一种可复制的方法论：用标准化资产约束输出质量、用 MCP 溯源权威知识、用脚本化执行控制成本，把 AI 从"不稳定的创意助手"变成"可靠的交付工厂"。对于咨询、交付类团队而言，这是一条值得借鉴的落地路径。