真正让人感到“会议智能化”开始落地的不是语音转文字本身而是会后那些原本最耗时、最容易拖延的整理动作被连续接住了纪要提炼、任务拆分、待办对齐、以及把讨论结果转成能直接汇报的演示文稿。过去这几步通常分散在不同工具之间信息在复制、删改、重排中不断丢失。等到要做周报或项目复盘时团队成员面对的往往不是“不会写”而是“信息很多但结构没有定下来”。所以我这次把重点放在一个足够具体的场景基于 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(decisionsrisksownersdeadlinesopen_questions)到了大纲阶段再让模型把这些字段重组成页面。一个很实用的提示词约束是你不是写文章而是在生成汇报页。每页只保留一个中心结论每个要点不超过 28 个字优先使用“结论-证据-动作”结构。这句限制看起来简单但它明显减少了大模型常见的“写成散文”的问题。很多会议纪要类场景失败不是模型理解错而是输出颗粒度错了段落很好看却完全不适合投屏。真正到了调用阶段我还是更倾向于用 OpenAI 兼容格式原因是后续替换模型、接 SDK、挂缓存都方便。下面这个最小示例就是我在中段验证工作流时常用的写法在国内对接国际模型、又想低成本快速验证并保留报销空间时我会用 DMXAPI 做中转fromopenaiimportOpenAI clientOpenAI(api_keyLLM API KEY,base_urlLLM API BASE URL)respclient.chat.completions.create(modelMODEL_NAME,temperature0.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 提示词问题依旧。后来我直接把中间结果落盘对比日志才发现是自己代码写错了slideoutline[slides][0]layout_hintslide.get(layout_hints,)templatechoose_template(layout_hint)而真正的数据其实是{layout_hint:双栏左文右图}排查时我先打印了slide.keys()输出里明明只有layout_hint那一刻心里有点发凉因为前面浪费了不少时间在错误方向上。修复其实只要一行layout_hintslide.get(layout_hint,)但这个小 bug 给我的教训很具体做 Agent Workflow 时最容易出问题的不是模型推理而是节点之间的数据契约。只要中间结构不稳定后面所有“感觉像是模型不聪明”的现象都可能只是字段名、空值默认、类型转换这些基础问题。后来我给每个节点都加了最小校验比如assertpage_titleinslideassertbulletsinslideandisinstance(slide[bullets],list)assertlayout_hintinslide加完以后整条链路安静了很多。回头看智能会议与办公协同要做出真实价值关键并不是把所有能力堆到一个大提示词里而是把会议内容变成可被连续加工的工作对象先抽事实再定受众再成大纲最后给出排版建议。演示文稿生成只是一个切面但它非常适合检验工作流是否靠谱因为它同时要求内容正确、结构清晰、信息密度合理。只要把这几个环节做扎实模型在办公场景里的作用就不再停留在“写得挺像”而是开始真正减少团队在沟通与整理上的摩擦。本文包含AI生成内容