一张蓝图讲清 AI Agent 方案的八个部分

很多人写 Agent 方案，会写成这样：

做一个会议纪要 Agent。
功能包括：总结会议、提取任务、生成邮件、提醒负责人、分析风险。

这只是功能清单，只说明了想要什么结果。一份方案要能执行、能检查，还得回答功能背后的依据、流程、边界和评估。

这篇用“会议纪要跟进 Agent”做完整例子，把任务说明、资料、工具、状态、流程、防护栏和评估放进同一张蓝图里，检查各部分能否共同支持同一个目标。

一份方案要能落地，得顺着功能往后一层层追问：依据从哪来，由谁执行、怎么执行，在哪里停下，结果交给谁，错了怎么发现。这些问题答完，就得到八个部分：目标、任务说明、资料、工具、状态、流程、防护栏和评估。

会议纪要跟进 Agent 的目标，不能只是“总结会议”，要落成两个能检查的结果，任务表和邮件草稿；中途截止时间改了，还得看任务表和邮件会不会跟着一起变，各部分接不接得上，到这时才看得出来。

01 蓝图比功能清单多什么

要让方案能够执行和检查，至少还要回答这些问题：

会议记录从哪里来？
任务负责人不明确怎么办？
哪些内容不能编造？
是否能自动发邮件？
提醒负责人前是否要确认？
结果好不好怎么判断？

一个最小 Agent 蓝图至少要包含八项：

目标
任务说明
输入资料
工具
记忆或状态
流程步骤
防护栏和确认点
评估方式

沿着一项功能继续问：依据从哪来，怎样执行，在哪里停下，结果交给谁，错误怎么发现？这些问题把功能、依据、流程、边界和评估接在一起，蓝图才有了检查可行性的作用。

02 目标、任务说明和资料

“总结会议”太笼统。更具体的目标是：

把会议记录整理成可执行任务表，并生成会后跟进邮件草稿。

这个目标给出了两项可检查的结果：任务表和邮件草稿。接下来写任务说明：

这个 Agent 负责读取会议记录，提取已确定行动项、负责人、截止时间、风险和待确认问题。它不能把讨论建议写成已确定任务，不能猜负责人和截止时间，不能自动发送邮件。输出包括任务表、待确认项和邮件草稿。

这段说明把目标、职责、边界和输出放在一起，资料和工具的选择也就有了依据。资料至少包括会议记录全文、参会人名单、项目背景资料和历史任务表。资料出现缺口时，要明确缺少什么、影响哪个结果、需要谁来补充。

参会人名单说明谁参会，负责人以记录里的明确指派为准。记录写着“下周完成接口改造”，却没写负责人，任务表就如实填“负责人未明确”。之后用户确认由小陈负责，再把这条确认记为补充依据：

会议原文：负责人未明确
用户后来确认：小陈负责（记录确认来源和修改对象）

这两条要分开记录，让读者看得出哪一条是会后确认的。

03 工具和状态，按需设计

会议纪要 Agent 是否需要工具，取决于任务范围。本例只交付任务表和邮件草稿：已有完整会议记录，就可以直接处理文本；需要补查背景和历史任务时，才接入只读工具。创建待办、保存草稿到邮箱、发送邮件都涉及外部写入，本例只交付文本，暂不接入。增加执行能力时，要同时修改任务说明、工具权限和确认流程。

状态则让后一步接住前一步的结果。这个 Agent 至少要记录：

当前会议是哪一次
已提取哪些行动项
哪些负责人或时间不明确
用户确认了哪些修改
邮件草稿是否已确认

这些状态能避免重复提取、遗漏已确认事项，也能防止 Agent 把待确认内容写进正式邮件。用户只确认了部分负责人，接下来怎么办？先保留尚未补齐的状态，把已确认内容交付，并在草稿里列出剩余缺口。工具和状态都会增加维护成本：会议纪要只用于个人整理时，保留“生成任务表”和“生成邮件草稿”就够；进入团队协作流程，再接入任务系统、邮件工具和历史任务表。

Anthropic 的 Agent 设计文章也从检索、工具和记忆这些基础能力讲起，建议先采用满足当前任务的简单方案。

04 流程和检查点

把会议纪要 Agent 拆成流程：

步骤 1：读取会议记录，识别明确行动项。
步骤 2：提取负责人、截止时间和依据原文。
步骤 3：标出风险和待确认问题。
步骤 4：生成任务表。
步骤 5：让用户确认不明确事项。
步骤 6：基于确认后的任务表生成跟进邮件草稿。
步骤 7：交付任务表、待确认项和邮件草稿，由有权限的人员决定后续发送或录入。

在高风险步骤前设置检查点，让人先核对依据，再决定是否继续。这个 Agent 至少需要三个：

05 防护栏和评估

会议纪要 Agent 的防护栏可以这样写：

只基于会议记录和已提供资料生成结论。
负责人或截止时间不明确时，写“未明确”。
不能把建议、猜测、待讨论内容写成已确定任务。
不能自动发送邮件。
涉及承诺、预算、合同、上线时间的内容必须人工确认。

每条规则都对应一个具体风险和一个处理动作，拿来就能执行。评估方式也要简单可检查：

这些评估问题把“效果好不好”变成看得见的通过条件和失败原因。比如会议记录写着“也许请小陈周五交初稿，等她确认”：记录里有“也许、等确认”，期望输出保留“待确认”；记录明确写“小陈周五交”，期望输出写成确定任务。测试时两种记录都放进去，全都标“待确认”或全都写成确定任务，都算失败。

具体评估可以参照 Claude 文档里的成功标准与测试方法，先把目标写成明确、可衡量的条件，再设计对应测试。

06 检查各部分是否衔接

用户把截止时间从周五改到下周一，任务表也更新了，邮件却还写着周五。问题就出在表格与草稿之间：确认后的新信息没有传过去。可以用这条变化检查蓝图中的各部分是否衔接：

1. 根据确认记录更新任务表。
2. 在状态中记录当前版本。
3. 用这一版本生成草稿。
4. 交付前核对任务表与邮件中的时间是否一致。

再看组件之间的五条连线：

任务说明 ---> 决定了资料和工具的选择？
每个工具 ---> 出现在流程的具体步骤里？
状态     ---> 记下各步产出、撑得起下一步？
检查点   ---> 落在有真实后果的步骤之前？
评估     ---> 对着目标定义的结果？

如果某个环节接不上，就要检查对应的设计是否缺失或多余。最后，把会议纪要 Agent 的完整蓝图收在一张表里：

写完蓝图后，再按控制方式选择实现：

粘贴文本、按固定步骤出草稿        -> 普通助手或固定工作流就够
要按资料缺口决定补查、澄清、推进  -> 才需要 Agent

这一步，正好回到怎么判断一个产品是不是真 Agent里的那个问题。以后学 Agent SDK、RAG、Function Calling、Evals，可以随时回到这张图上，看看它们各自支持哪个环节，也可以回看前面各篇：任务说明怎么写、怎么给 Agent 配工具、怎么设防护栏。