在大型公司里，制作演示文稿意味着每周都要重复数小时的手工工作。在我工作的冶金公司，这项工作现在由我构建的产品完成。它接收文本，按照公司视觉风格生成演示文稿，并输出可编辑的 PowerPoint。产品运行在企业内网和公司的内部模型上。目前它正在逐步覆盖约 5 万名员工，为公司节省数千万卢布。
产品有两个界面。用户在第一个界面输入主题或最多 15,000 个字符的原始文本，并选择样式、文本改写程度以及每页的信息密度。系统提供两种模式：自动选择模板，或由用户为每一页指定模板。生成开始后会打开预览界面：左侧是页面列表，中间是当前页面，下方是评分和问题标签。最多 20 页的演示文稿可以下载为可编辑的 PPTX。
一切始于一次选择。公司考察过俄罗斯现成的解决方案，但没有一个完全合适：有些解决的是另一类问题，有些价格太高。于是我在两周内做出了自己的版本。原型使用 n8n 完成，这是一个由模块和连线组成流程的低代码平台。上下文放在 Google 表格里，模板提前准备好。两周后，这个结果已经可以和供应商方案放在一起比较，公司决定继续自主开发。
之后工作按照月度迭代进行。每次迭代的结果要么是新的架构，要么是一轮用户测试。大部分代码由智能体、Claude Code 和 Codex CLI 编写。我负责设计系统、提出任务并验收结果。
产品本身也是一个智能体：它完成演示文稿设计师的工作。我是在另一个智能体的帮助下构建一个智能体。这类工作可以称为 Agentic Experience，类似于 User Experience。它有两个方面：为智能体设计清晰的工作环境，以及设计人与智能体协作的方式。本文讨论这两方面。
第一版：Python 和一个智能体
第一版使用 Python 编写。服务器使用 FastAPI，界面是普通 JavaScript，部分流程运行在 n8n 中。Python 和 Bash worker 负责启动 Claude CLI 并生成演示文稿。
这一版中，Claude 同时负责工作和管理流程：读取文本、规划页面、选择模板、完成排版，并决定何时结束。它需要知道的一切都放在一个提示词里。每增加一条规则，提示词就会变得更大。
有时生成的演示文稿很好，有时运行半小时后结果仍然很差，而我无法判断问题出在计划、模板选择还是排版。提示词中的新规则可能修好一处，又破坏另一处。有一次，智能体在指令文件和模板检索都被关闭的情况下运行，但结果没有体现出来。
第二版：六个步骤
我按照设计师的工作方式拆分了智能体：规划、选择模板、填充页面、截图与检查、组装、保存。每一步都有自己的小提示词、输入和输出、超时设置以及失败重试机制。
第二版使用 TypeScript 构建。Next.js 负责界面和服务器基础，Payload CMS 提供管理后台、身份验证以及 PostgreSQL 数据库连接。Puppeteer 为检查页面生成截图。放弃 Python 有两个原因：前方要做一个复杂的在线编辑器，界面和服务器使用同一种语言更方便；另外，Python 中组件之间通过字典传递数据，智能体很容易在一处使用 slide_id，在另一处使用 slideId，用户最后只会看到空白页面。TypeScript 只声明一次数据结构，发生不一致时项目无法构建。
Temporal 是流程编排引擎，负责协调这些步骤。它启动步骤、重试失败任务、限制运行时间，并保存每次运行的历史。流程用代码描述，而智能体擅长编写和阅读代码。如果使用可视化模块，就必须手工组装整套流程。
第一次运行用 36 分钟生成了六页，评分为 4 到 8 分。Temporal 的时间线显示了时间消耗在哪里。页面之间互不依赖，因此我把填充过程拆成并行任务，并限制每个阶段最多同时运行十二个 worker。
我通过 Claude 和 Codex CLI 运行生成，也测试了本地小模型：Gemma 4 26B 通过 Ollama 可以完成任务，但生成八页需要约 45 分钟。后来模型通过 OpenRouter 接入。
当错误被定位到具体步骤后，修复就有了明确位置。有一次生成步骤写出了“传统方案 35%，新方案 92%”，但原文中并没有这些数字。我只在这一步的提示词里加入“数字只能来自原文”的规则，其他步骤没有改动。
给开发智能体的外部上下文
开发智能体每次会话都从零开始。以前我需要重复讲述决策，偶尔忘记某件事，它就会把我们一周前放弃的方案重新写回代码。
我把上下文从代码仓库移到了另一台服务器上的任务追踪器。那里保存任务、决策、架构、项目规则和会话历史。智能体通过 API 读取结构化文本，我则在看板和架构图上看到同样的数据。每次会话开始时，智能体会读取规则、任务卡、相邻任务、相关架构切片和过去的会话记录；结束时记录结果和提交。
旧决策不会被删除，而是标记为“已替换”并链接到新决策。失败方案也会保留，并记录原因。智能体变多后，每个任务都使用独立的 git worktree。一个智能体执行任务，另一个负责检查，最终由我做决定。
模板选择
为页面选择模板是最困难的部分。
我先整理了模板库：把 282 个零散模板合并成 132 个规范化的 HTML 模板，并为每个模板写下用途、使用场景和同义词。这些描述被转换为 embedding，存入 Qdrant 向量数据库。查询由页面规划生成。
语义搜索能按主题找到模板，却不了解容量。五个要点可能会被放进只有三个卡片的位置。于是模型根据 HTML 和 PNG 预览，为每个模板生成结构化 JSON 描述：网格、插槽及嵌套关系、重复分组、最小和最大数量、典型数量、固定元素以及溢出时的行为。
如何结合意义与结构并不清楚，所以我做了六种流程变体，每一种都是独立的 Temporal workflow。最终主要模式采用重复选择：先选模板，再按照模板改写文本，然后重新选择。其他方案带着失败原因保留在追踪器里。
原生 PowerPoint：模型决定什么，代码决定什么
用户需要可编辑的 PowerPoint。HTML 转换会丢失细节，因此我评估了大约十种方案，最后通过一个库直接生成 PPTX，并把它做成独立 workflow。
责任边界被划分得更清楚。模型返回 JSON 格式的内容规格，代码从中提取特征，排除注册表中不合适的形态，再按照记录数量、字段、容量以及是否能够实际生成页面来评分。坐标由代码根据设计 token 计算，模型不负责定位。
如果注册表里没有合适的形态，composer 就用基础元素组装一个新形态。区域由 Yoga 这个 flexbox 布局引擎计算。composer 成为主要路径，新形态在我手工确认之前不会开放给用户。
有一次团队页面上的文字都在，但角色被放到了错误的姓名下面：分页时不同记录的字段混在了一起。后来每条记录都有稳定 ID，并检查字段是否仍属于同一条记录。代码将数字与原文对比，布局回归则通过 LibreOffice 渲染七个基准案例，并以 1.5% 为阈值比较。
用户测试
进入企业内网前，我们进行了两轮用户测试。用户可以在每页下方评分并标记问题：格式错误、排版损坏、编造数字或文本丢失。评分和标签进入分析面板，可以按生成、页面、用户和模板查看。我用这些数据比较流程变体、发现缺陷，再把修复写入提示词和代码。模型不会因为评分而自动改变。
一位测试者说服务不适合他。交流后发现，他需要一页复杂的甘特图。我在一天内增加了手动模式：用户为每页指定模板和文本，跳过自动选择，系统只负责填充和组装。第二天他确认问题解决了。
运行与封闭环境
有一次生成因为服务器内存不足而停止了大约两个小时。之后我增加了部署和回滚脚本、健康检查、备份，以及独立的开发和生产环境。
模型地址和模型选择被移入环境变量。产品调用兼容 OpenAI 的 API，不依赖具体供应商。封闭环境中没有外部模型，迁移时只需要更改配置。
首先需要把质量和 PowerPoint 导出做好，让客户试用。准备迁移时，我制作了离线部署包，包括 Docker 镜像、脚本和初始数据。试点环境运行在 Astra Linux 上，包含应用、worker、PostgreSQL、Qdrant、Temporal 和 embedding 服务。为了通过信息安全审核，我准备了 C4 图和数据流说明，检查了 SAST 与 SCA 结果。
生产平台
为了服务所有员工，产品需要部署到企业 Kubernetes 上。我没有足够经验审核智能体写出的配置，因此开发团队加入了项目。他们将代码重写到公司标准技术栈：服务器使用 Java 和 Spring Boot，界面使用 React。系统增加了 Keycloak 企业登录、内部模型网关、用 PostgreSQL 实现的步骤队列以及 S3 兼容存储。生成仍然分为同样的步骤。
我保留了产品逻辑、场景、需求、质量、优先级和验收。给团队提任务的方式与给智能体提任务一样：目标、上下文、验收标准和结果检查。
十月，产品通过验收。在一次阶段性调查中，97% 的参与者表示愿意使用它。现在访问权限正在逐步开放给所有员工。
我的理解
大型任务应该拆开交给智能体，每一部分都有自己的输入、输出和提示词。必须让智能体的工作可见，否则只能靠猜测修复错误。开发智能体的上下文应该存在于会话和人的记忆之外，并保留决策与失败方案。模型适合处理内容，而几何和事实检查交给代码更可靠。用户反馈要收集成数据，并快速验证其中的假设。
整个项目始终围绕一个想法：我们需要看见智能体的工作。n8n 中的模块高亮、Temporal 的轨迹、任务看板和架构图都在做同一件事。未来会有更多智能体彼此协作，人们需要一种看见这些工作的方式，而这正是我接下来想继续做的事情。