会议里出现“可以下周看看”，不等于已经形成一项有负责人和截止日期的任务。Agent 将纪要转成行动项时，应区分建议、决定、承诺与待确认信息，避免把讨论中的可能性直接变成执行要求。
先判断句子承担什么作用
“建议测试新模板”是提议；“决定本周采用新模板”是决定；“我来完成测试”是责任承诺；“测试后再决定”则仍有前置条件。它们可能围绕同一事项连续出现，不能只抽取一个动词就认定行动项已经成立。
整理时保留原始记录位置和必要上下文，说明结论依据哪段讨论。如果记录中没有明确负责人，就标记待确认，而不是把发言者自动设为负责人。提出问题、转述安排和接受任务是不同的行为。
行动项至少表达五件事
| 字段 | 需要回答的问题 |
|---|---|
| 具体动作 | 要完成什么可观察结果 |
| 责任人 | 谁已接受执行责任 |
| 时间 | 何时完成，依据是否明确 |
| 前置条件 | 什么条件满足后才能开始 |
| 依据与状态 | 来自哪里，目前是否已确认 |
“优化体验”过于宽泛，可以作为议题，但如果会议没有定义具体交付物，就不应由 Agent 自行补成“周五完成三版设计”。可以把缺少验收条件作为待补信息展示，让后续负责人明确，而不是伪造一个看似完整的任务。
相对日期需要会议上下文
“下周三”应根据会议日期和约定时区解析，不能根据 Agent 今天运行的时间计算。跨午夜会议、补录纪要或旧会议回放，都容易让日期错位。无法确定时保留原始表达和待确认状态，不要默默选择一个日期。
任务工具的输入 Schema 可以约束日期和责任人字段的格式，却无法证明会议真的作出了这些决定。工具前的语义核对与工具后的结构校验是不同环节。一个格式完整的任务，也可能建立在错误解读之上。
从候选清单到实际任务要有对应关系
先生成候选行动项，记录哪些已明确、哪些仍待补充。进入业务系统后保存真实任务 ID，并读回标题、负责人和时间。若用户调整了行动项，应更新原任务或建立明确修订关系，避免每次重跑纪要都创建一套重复任务。
特别注意“已提取”“已建任务”和“负责人已确认”是三个不同状态。工具调用成功通常只证明系统记录已经建立，不能推导出对方已经看到或接受。自动化报告应使用准确状态，帮助团队知道下一步缺的是信息、写入还是责任确认。
本文给出的是会议行动项整理方法，不假定任何产品自动识别责任或自动获得协作者同意。把讨论证据、任务字段和实际执行状态连接起来，才能让纪要真正服务协作，而不是制造更多需要澄清的待办。
在企业文档中验证
如果要把本文方法用于企业文档，可预约演示，结合实际资料核对协作、权限与集成方式。
需要在自己的环境中验证时，可先了解私有化部署方案，再确定试用范围与验收要求。