第十七章：为一个新需求设计 Agent
读到这里，你已经能解释 Hermes 如何组织模型、工具、上下文、历史、记忆与技能，也能分析多入口、调度、委托和失败恢复。现在换一个需求，不照抄简报助手的全部功能。
一个读书小组希望有个助手：管理员上传活动通知，可能是文字、图片或文件；助手整理下周活动，发现时间冲突和缺失信息，先形成待确认的群通知，得到管理员同意后再发送。
本章的产物是一份能讲清理由的设计方案。无需安装、画专业工程图或写代码，但要能够说明一条任务如何走完，以及哪些机制现在可以省略。
17.1 先把“智能助手”改成可验收的需求
“自动帮我们安排好一切”无法确定权限和完成状态。先整理已知条件，把需要人决定的部分留下。
| 项目 | 本次练习的约定 |
|---|---|
| 输入 | 管理员提供的通知，可能包含重复版本、截图和缺项 |
| 输出 | 下周活动清单、冲突与待确认项、群通知草稿 |
| 事实规则 | 不自行编造时间、地点和活动取消；保留材料依据 |
| 权限 | 管理员确认具体草稿和目标群后才能发送 |
| 私密范围 | 报名者的私人联系方式不出现在群通知 |
| 初始规模 | 一个管理员、一个小组，按需触发 |
| 尚未确定 | 材料保存期限、多人共同管理、是否需要固定周报 |
这里的“时间冲突”还需要解释：两个活动重叠是否一定不能并存？如果不同人可以分别参加，助手应提示重叠，而不能擅自取消其中一个。找出冲突与替用户作决定，是不同职责。
先写这些边界，后面的模型、记忆和调度才有选择依据。
17.2 用六个问题检查设计是否完整
第一，什么输入算完整，什么输出算可交付？第二，哪部分需要模型判断，哪部分由工具确定执行？第三，状态存在哪里，什么时候带入？第四，谁能查看与操作？第五，怎样开始、停止与恢复？第六，用什么证据判断设计有效？
答不出的地方，先标为待定，不用“调用一个更强模型”补空白。比如没有合法接收目标，就不能从材料中随便找一个群号发送；没有活动日期，就保留待确认项。
17.3 从最小可用方案开始
可以先选择一个 Agent，一次只整理管理员明确提供的一批材料。工具负责读取文字或提取图片内容、保存草稿；模型负责比较版本、识别缺项和组织表达。最后给管理员查看，不自动安排后台任务。
把这条主流程讲完整：入口确认管理员身份并创建任务；保存材料标识；组织当前要求与可用工具；模型取材并核对；程序记录结果；生成草稿与未解决项；等待具体确认；获准后将指定版本发送到指定目标，并记录交付状态。
图片提取可能识错字。若日期看不清，就应保留图片定位并请管理员确认，不能把提取工具返回的文字无条件当作事实。它和简报中的转述 B 一样，仍然需要核对。
这个方案使用循环、工具、上下文和持久记录。它没有因为课程介绍过多 Agent、定时和长期记忆，就全部加进去。
17.4 把状态拆成四份，避免“刚才那个”
| 状态 | 谁负责保存与组织 | 何时使用 | 不能混成什么 |
|---|---|---|---|
| 原始材料与标识 | 受控资料位置与读取工具 | 核对版本、回读歧义 | 模型已经永远记住 |
| 会话与本次运行记录 | 会话持久化与运行程序 | 追问、恢复和定位阶段 | 外部消息必定已发送 |
| 草稿与版本 | 产物存储 | 预览、确认和实际发送 | 一个总被覆盖的“最新稿” |
| 批准与交付记录 | 授权及发送路径 | 核对谁批准哪版、发送到哪里 | 群消息里一句含糊的“可以” |
关键设计是确认和实际产物对应。如果管理员批准第 2 版，模型后来又修改了时间，不能继续沿用第 2 版的确认发送第 3 版。数据变化使授权条件变化，需要重新判断。
在 Hermes 上落实时，可利用已有 Profile、会话、工具和执行能力组织这些职责，但不能因此声称默认就具备“批准自动绑定任意文件版本”的业务规则。那是具体应用必须明确实现和验证的约定。
17.5 什么时候才增加记忆、技能与调度
如果管理员每次都说“群通知不要附私人电话”，可以把它写成稳定规则或适当的偏好材料；但当前这场活动的地点不宜变成长期通用事实。过期资料需要有更新或失效方式。
若活动整理反复进行，可以形成技能：读取、比较版本、列缺项、形成草稿、等待批准、核对版本后发送。技能保存方法，活动材料和具体发送许可另外管理，不能把“上次允许发送”写成所有未来任务的通行证。
只有需求变成“每周固定整理当前资料”，才引入调度。新的任务定义要能在新会话独立找到资料与方法，并说明管理员不在线时应保存草稿还是继续。创建计划不是提前获得发送许可。
只有材料规模大到存在多个可独立核对的主题，才考虑委托。子任务可以各自提取活动，不直接发送或覆盖最终稿；父任务统一比较时间与版本。这样能解释新增机制的收益，也能解释为何暂时省略。
17.6 给故障留出有依据的继续方式
阅读失败：保留已读与未读清单，不把缺材料说成没有活动。提取失败：保留歧义，不补造日期。生成失败：保留输入与已确认事实，再按预算恢复。
发送阶段则沿第十五章判断。尚未开始可以继续排队；明确拒绝可在授权仍适用时处理；结果未知先核对接收端。管理员发来新的活动版本，也可能使原待发送项失效，不能只恢复技术动作而忽略业务条件。
还要有停止方法：暂停新任务，取消尚未执行的投递，保留已完成结果与未知状态。不能把删掉聊天窗口当成撤销所有外部影响。
17.7 比较三种方案，说明为什么这样选
| 方案 | 适合的条件 | 主要代价 |
|---|---|---|
| 表单加固定工作流 | 输入字段齐全、步骤和判断规则稳定 | 不擅长解释模糊通知与相互冲突的自然语言 |
| 一个 Agent 加受控工具 | 材料多样，需要按反馈取材与核对 | 要管理上下文、判断错误、授权和恢复 |
| 多 Agent 加调度 | 多个复杂主题可独立推进，确有周期需求 | 增加交接、状态、总开销与故障面 |
本练习的初始条件适合从第二种开始，也可以进一步缩小为固定表单。如果管理员愿意把每项活动录入完整字段，许多判断就不再需要 Agent。
能指出不需要智能体的部分，是设计能力的一部分。Hermes 提供一套机制，不要求每个应用用满它们。
17.8 交一份什么样的毕业方案
提交五份相互能对上的材料：一张需求与完成标准表，一张责任图，一条包含输入与状态的任务时序，一份权限/失败恢复表，以及一组验收场景。每个模块旁边写一句采用或省略它的理由。
至少推演这些变化：通知更新后仍有人批准旧稿；截图中的日期不清；不同活动重名；普通成员要求查看私人报名资料；发送超时；管理员离线；背景任务与新消息同时到来。无需真的发送消息，也能先判断设计是否自洽。
参考方案怎样判合格？
合格的方案不要求与本章布局相同，但应满足：原材料与草稿可定位；模型判断与工具执行分开；确认对应版本与目标；缺项不编造；私人资料有访问与输出边界；恢复先核对阶段与副作用；多 Agent、调度和长期记忆都有采用或省略的理由；验收覆盖至少一个正常与多个异常场景。
如果写了“保证永不出错”，却没有证据与范围，不算更成熟。如果明确保留歧义、知道何时请管理员处理，并能说明恢复路径，反而更接近可落实的设计。
本章要点
- 从需求、事实与授权出发选择机制，不从功能清单反推需求。
- 架构图、时序与状态表应能解释同一条任务，确认还需绑定具体产物与目标。
- 用已有能力不等于自动获得所有业务约束，应用仍需落实自己的规则。
- 能解释省略某个模块的理由，并推演反例，才说明知识已经可以迁移。
理解题
1. 为什么活动地点不适合直接写成永久偏好？
它通常是某场活动、某个时间范围的事实，会失效或更新。偏好是比较稳定的表达或行为倾向。混合两者，下一场活动就可能沿用过期地点。
2. 管理员批准后模型只改了一处日期，为什么仍可能需要重新确认？
日期影响实际活动，已超出原来批准的具体产物。即使只改一个字符，也可能改变授权内容。应核对版本、变化与确认范围，而不是按修改字数判断。
3. 这个需求何时可以完全不用 Agent？
当输入已规范成字段，冲突规则可以确定计算，生成与发送步骤稳定，且例外可以交给人处理时，表单和固定工作流可能更直接。应按实际判断需求选择，而非为使用 Agent 强加复杂性。
主线到此完成。最后的对照专题用相同问题观察 Hermes 与 OpenClaw，检查我们的理解是否能跨产品成立。