Agent 持久化工作流如何写进简历和面试？

好了，到这里，第七章就全部结束了。

这一章和前面几章有一个很明显的区别。

前面的案例，大多数都可以在一次 Agent Run 中完成。模型分析问题、调用 Tool、拿到结果，最后生成回答，整个任务就结束了。

但是，真实的企业任务经常会持续很长时间。

比如咱们这一章实现的 AI 演示文稿制作 Agent。用户先提交制作要求，系统生成大纲，接着等待用户审核。大纲通过以后，系统还要逐页生成内容、处理失败页面、接受局部修改，最后才能导出 PPTX 文件。

中间任何一个环节，都可能遇到用户暂时离开、服务重启、模型调用失败或者需求发生变化。

所以，这一章真正学习的是：如何让一项包含 AI 生成、业务规则和人工参与的长任务，能够暂停、恢复、修改，并且可靠地执行到最后。

最后这一小节，咱们先把整章内容重新梳理一遍，再看看这些能力怎样写进简历，以及面试时可能会被问到什么。

第七章都学了啥

01-让 Agent 完成一项可以暂停、修改和继续的制作任务

第一小节先确定了整章要解决的问题。

一次模型调用通常只能完成一个相对独立的动作。但是，一项完整的演示文稿制作任务会跨越多个步骤，还会多次等待用户参与。

如果应用程序只在内存中记录进度，服务一旦重启，系统就不知道任务已经执行到了哪里。

如果每次恢复都从头执行，已经生成成功的内容会被重复生成，模型调用成本也会继续增加。

因此，企业 Agent 需要管理的不只是本轮模型输入和输出，还包括任务进度、业务状态、人工审核、页面版本以及已经产生的文件。

这一节建立了后续几篇文章的主线：使用 DDD 管理业务规则，使用 LangGraph 编排执行流程，再通过 Checkpointer 把任务执行状态持久化。

02-Agent 业务建模与 DDD

第二小节讲了 DDD，也就是领域驱动设计。

DDD 关注的是如何把业务中的对象、状态、操作和规则，整理成程序可以长期维护的领域模型。

咱们从演示文稿制作需求中，找到了需要长期管理的内容：制作要求、大纲版本、页面任务、页面产物和导出记录。

随后，又把“生成大纲”“批准大纲”“修改页面”和“导出文件”等动作，整理成领域模型能够执行的业务行为。

最后，再由领域模型保证确定性的业务规则

在 Agent 项目中，大模型适合处理内容生成、意图理解和修改要求分析。领域对象则使用普通 TypeScript 代码保存业务状态，并校验这些确