开源 AI Agent Runtime：会议记录怎样变成行动清单会议结束后，真正耗时的不是记录，而是把讨论变成可执行的下

产品例会结束后，会议记录通常包含大量背景、不同意见和临时决定。真正需要跟进的人却只想知道三件事：决定了什么、谁来做、什么时候给结果。让 Agent 直接“总结会议”，往往会得到一段顺畅但无法执行的文字；更稳的做法，是把记录转换为带来源的结构化行动清单。

这个场景适合用 ZGI 设计一条从文件输入到人工确认的运行链路。公开资料中，ZGI 支持文件输入、模型调用、分支、代码、用户问题、审批和结构化输出查看。下面的字段和提示词是可落地的示例，需要使用自己的会议记录验证，不代表任何固定模板。

先确定会议范围。一次运行只处理一场会议，输入包括录音转写稿、共享文档和会前议程；文件名带日期和会议名称，旧版本放在独立目录。没有日期、参与范围或明显缺页的记录先标记为待补充，不能让模型靠上下文猜出缺失内容。

先把会议内容分成四类

行动清单的第一步不是提取任务，而是判断句子属于哪一类。结论是已经达成的决定，任务是需要有人继续完成的动作，问题是尚未解决的疑问，背景是帮助理解但不需要执行的内容。四类混在一起，后续就会把讨论意见误当成承诺。

输出可以固定为以下字段：类别、事项、负责人、截止时间、交付物、依赖条件、原文片段、来源位置和确认状态。负责人没有明确说出时填“待确认”，日期只出现“下周”而没有会议日期时也先保留原文，不能擅自换算成具体日期。

例如“下次把新手引导再看一遍”更像建议，不应直接生成任务；“小李周五前更新引导并发到评审群”才具备负责人、时间和动作。Agent 需要说明判断依据，让主持人能快速修改，而不是只给出一个看似确定的结果。

在 Agent 配置里先写清楚边界：只依据输入材料，不补写没有说过的负责人和日期，不把建议改成承诺，不替团队安排优先级。第一步读取记录并按段落分组，第二步提取四类内容，第三步检查字段完整性，第四步输出行动清单和待确认列表。

模型适合理解自然语言，规则节点适合做确定性检查。可以用代码步骤检查任务是否缺少事项、负责人或交付物；用分支判断截止时间是否来自原文；用去重规则合并同一任务的重复表述。发现冲突时，不要让模型自行选择，而是把两处原文一起交给主持人确认。

提示词可以这样写：“仅依据会议材料提取；每条任务必须保留原文片段；没有明确负责人就填写待确认；没有明确日期就保留原文；将建议、问题和决定分开；不要推测优先级，不要替团队创建新的任务。”明确的负面边界，比一句“帮我整理得专业一些”更容易验收。

如果会议记录超过一次模型适合处理的长度，可以按议程章节分段，再合并结构化结果。合并时按事项和来源去重，保留来自不同段落的冲突信息。不要为了得到一张漂亮的表格而删除不确定项，不确定项正是主持人最需要看到的地方。

行动清单不是生成后自动发送的通知。主持人先核对决定是否准确，再补齐负责人和时间，最后确认哪些项目需要进入后续系统。Agent 可以准备草稿和问题清单，但不应擅自代表团队改变任务状态。

复核界面至少要同时展示三部分：结构化事项、原文依据和待确认原因。某条任务被标记为“缺少负责人”时，主持人点击即可回到对应段落；某个日期出现两种写法时，界面应并排列出两处来源，而不是只显示模型选择后的结果。

运行记录能帮助排错。若清单漏掉一项，先查看文件是否完整，再看段落切分和字段提取；若任务被错误合并，检查去重条件；若原文引用不准确，检查解析结果和来源位置。把问题定位到具体步骤，比重新修改一整段提示词更省时间。

准备六份脱敏样本：任务明确的例会、只有建议的讨论、负责人缺失、日期模糊、同一事项重复出现、两段记录互相矛盾。逐项检查四类内容是否分开、原文是否可定位、缺失信息是否进入待确认、冲突是否停在人工环节。

验收不要只看文字是否通顺，还要看行动清单能否被主持人直接修改。可以记录每份样本的漏项、误合并和错误补全次数，但不要在没有统一样本和方法时宣称准确率。先从一种固定会议类型开始，确认字段稳定后，再扩展到跨部门会议。

在这个场景里，Runtime 的价值不是替主持人开会，而是把一份长记录变成可核对的执行材料。它把文件、模型、规则、人工确认和运行记录放在同一条链路里，让每一条行动都能回答“从哪里来、谁确认、下一步是什么”。