真正让人感到“会议智能化”开始落地的，不是语音转文字本身，而是会后那些原本最耗时、最容易拖延的整理动作被连续接住了：纪要提炼、任务拆分、待办对齐、以及把讨论结果转成能直接汇报的演示文稿。过去这几步通常分散在不同工具之间，信息在复制、删改、重排中不断丢失。等到要做周报或项目复盘时，团队成员面对的往往不是“不会写”，而是“信息很多，但结构没有定下来”。所以我这次把重点放在一个足够具体的场景：基于 AI 大模型做智能会议与办公协同，进一步落到“演示文稿内容生成与自动排版建议”，并且用智能体工作流把这个过程做成可以重复执行的链路，而不是一次性演示。
我在做这类原型时有个很现实的判断：先把流程跑通，比一开始追求最完美模型更重要。很多教程只教改OPENAI_API_KEY，但中转平台必须改base_url，而 DMXAPI 这类方案在国内做国际模型原型验证时会更省事，至少不会让环境问题先把开发节奏打断。真正影响体验的，通常是工作流设计是否清晰：会议记录从哪来，谁负责抽取事实，谁负责归纳观点，谁负责生成页面结构，谁再对版式提出约束建议。
我最后定下来的 Agent Workflow 很朴素，但足够稳定，一共四步。第一步是“会议事实抽取 Agent”，只保留明确结论、待办、风险、时间节点，避免把闲聊和重复表述带进后续流程。第二步是“受众适配 Agent”，根据汇报对象是老板、客户还是研发团队，重写叙述重点。第三步是“PPT 大纲 Agent”，把内容压成 6 到 10 页的页面结构，包括封面、背景、核心结论、证据页、行动项、风险页。第四步是“排版建议 Agent”，不给它直接画页面，而是让它输出可执行的版式提示，例如“本页只保留 3 个一级点”“图表优先于长段落”“结论句必须单独成行”。这样做的好处是，模型负责内容理解与布局建议，人类仍然保留最终审美控制权。
如果要把这套流程写成最小可用脚本，核心不是复杂框架，而是先定义每一步的输入输出。比如会议记录先统一为 JSON：
{"topic":"季度经营复盘","audience":"管理层","transcript":"<MEETING_TRANSCRIPT>","goal":"生成用于周一晨会汇报的演示文稿大纲"}然后每个 Agent 只做一件事。事实抽取阶段我会要求模型严格输出：
fields=("decisions""risks""owners""deadlines""open_questions")到了大纲阶段，再让模型把这些字段重组成页面。一个很实用的提示词约束是：
你不是写文章，而是在生成汇报页。每页只保留一个中心结论，每个要点不超过 28 个字，优先使用“结论-证据-动作”结构。这句限制看起来简单，但它明显减少了大模型常见的“写成散文”的问题。很多会议纪要类场景失败，不是模型理解错，而是输出颗粒度错了，段落很好看，却完全不适合投屏。
真正到了调用阶段，我还是更倾向于用 OpenAI 兼容格式，原因是后续替换模型、接 SDK、挂缓存都方便。下面这个最小示例就是我在中段验证工作流时常用的写法，在国内对接国际模型、又想低成本快速验证并保留报销空间时，我会用 DMXAPI 做中转：
fromopenaiimportOpenAI client=OpenAI(api_key="<LLM API KEY>",base_url="<LLM API BASE URL>")resp=client.chat.completions.create(model="<MODEL_NAME>",temperature=0.3,messages=[{"role":"system","content":"你是企业会议协同助手，负责将会议内容转为演示文稿页面结构与排版建议。"},{"role":"user","content":""" 请根据会议纪要生成 8 页演示文稿大纲。 要求： 1. 每页包含 title、key_message、bullets、layout_hint 2. layout_hint 必须说明是否适合双栏、时间线、对比表或大图配短句 3. 如果信息密度过高，主动建议拆页 会议纪要：<MEETING_TRANSCRIPT> """}])print(resp.choices[0].message.content)这一层跑通以后，再往前后补胶水逻辑就很自然了。前面接会议转写文本，后面接 Markdown、JSON 甚至幻灯片模板系统。我的经验是，不要急着让模型“一步到位输出最终 PPT”，而是让它先输出结构化中间结果，例如：
{"page_title":"项目推进现状","key_message":"核心里程碑达成，但上线节奏受测试资源约束","bullets":["版本开发已完成 90%","联调问题集中在权限接口","测试排期晚于预期 3 天"],"layout_hint":"左侧三点结论，右侧一张里程碑时间线"}有了这种中间层，自动排版建议就不再是空泛描述，而是能映射到具体模板规则。比如layout_hint == "对比表"时，模板引擎就选双列表格；bullets > 4时触发拆页；key_message超过 32 字就自动压缩。所谓“办公协同”真正值钱的地方，不是让模型替人写一遍，而是让信息从会议到汇报的传递损耗更低。
不过这套流程里，我也踩过一个很低级、但很典型的坑。最开始我在“受众适配 Agent”和“PPT 大纲 Agent”之间传递字段时，把layout_hint写成了layout_hints。表面看只是多了一个s，结果后面的模板选择器一直拿不到版式信息。我一开始怀疑是模型没按格式返回，盯着响应内容看了半天，还加了重试和更严格的 JSON 提示词，问题依旧。后来我直接把中间结果落盘，对比日志才发现是自己代码写错了：
slide=outline["slides"][0]layout_hint=slide.get("layout_hints","")template=choose_template(layout_hint)而真正的数据其实是：
{"layout_hint":"双栏，左文右图"}排查时我先打印了slide.keys()，输出里明明只有layout_hint，那一刻心里有点发凉，因为前面浪费了不少时间在错误方向上。修复其实只要一行：
layout_hint=slide.get("layout_hint","")但这个小 bug 给我的教训很具体：做 Agent Workflow 时，最容易出问题的不是模型推理，而是节点之间的数据契约。只要中间结构不稳定，后面所有“感觉像是模型不聪明”的现象，都可能只是字段名、空值默认、类型转换这些基础问题。后来我给每个节点都加了最小校验，比如：
assert"page_title"inslideassert"bullets"inslideandisinstance(slide["bullets"],list)assert"layout_hint"inslide加完以后，整条链路安静了很多。
回头看，智能会议与办公协同要做出真实价值，关键并不是把所有能力堆到一个大提示词里，而是把会议内容变成可被连续加工的工作对象：先抽事实，再定受众，再成大纲，最后给出排版建议。演示文稿生成只是一个切面，但它非常适合检验工作流是否靠谱，因为它同时要求内容正确、结构清晰、信息密度合理。只要把这几个环节做扎实，模型在办公场景里的作用就不再停留在“写得挺像”，而是开始真正减少团队在沟通与整理上的摩擦。
本文包含AI生成内容
