首页/作品/长文结构化生成编排服务
工作流编排 · 流式交互

长文结构化生成编排服务

把一份多章节长文的生成拆成有依赖关系的节点图。每章可以单独中断、单独续写, 改动一章只连带重算它的下游——不做全量重跑。

整理中,入口稍后开放 Python · FastAPI · LangGraph Vue 3 · TypeScript

一、这是什么

用大模型生成一份多章节长文,直觉做法是「一次调用,让它写完」。这在短产出上可行, 但章节一多就会暴露三个问题:

  • 写不完上下文长度与稳定性限制了单次产出能有多长,写到后面质量会明显下滑。
  • 改不动只想改其中一章,却要整个重来,且重来的结果与上一版不一致——前面几章会跟着变。
  • 接不上中途失败就得从头开始,没有断点。

这个服务的解法是把长文视为一张有向图而不是一条长文本:章节是节点,章节间的信息传递是边。 生成被拆成逐节点的执行,每个节点可以独立完成、独立检查、独立重算。

一个必须说清的边界。需要数值计算的章节不由模型产出——数字由程序算好, 模型只负责把它写成通顺的叙述。让模型算数是不可靠的,而且算错了很难发现。

二、规模

11
章节节点
29
Prompt 资产
2
前后端
SSE
流式输出

29 个 prompt 是资产化的——独立于代码存放,可单独版本化与替换。 把 prompt 硬编码在代码里,改措辞就得改代码、走一遍发版流程,实际结果是没人愿意改。

三、结构

第 1 章 已缓存 第 2 章 已缓存 第 3 章 本轮改动 第 4 章 连带重算 第 5 章 未受影响 章节间上下文传递 改动第 3 章后的执行范围 第 1、2 章 —— 命中缓存,不重算 第 3、4 章 —— 重算(4 是 3 的下游) 重算范围随依赖图传播,与全文长度无关
失效传播:改一章只重算受影响的下游区间。这是整套设计里最省成本、也最值得讲的一个决定。

四个关键手法

  • 节点化生成每章是图上一个节点,独立执行。单章失败不影响已完成的其他章——重试的粒度是章,不是全文。
  • 检查点续写执行状态持久化,中断后从断点继续,不从头开始。长任务里这是必需的:跑一次要几分钟,中途任何抖动都不该让进度归零。
  • 上下文有向传递章节不是各写各的——后续章节能读到前面章节的产出,保证术语、口径、叙事线一致。这也是依赖图而非简单列表的原因。
  • 流式回传通过 SSE 把生成过程实时推给前端。长任务必须让用户看见进度,否则等待体验等同于卡死。

四、决策记录

为什么单章改动只重算下游,而不是全量重跑
为什么这么选
长文的价值在一致性,但一致性不等于每次都从头跑。改第 3 章时,第 1、2 章的内容没变、也没依赖第 3 章, 重新生成它们只增加成本与不确定性。重算范围应该由依赖关系决定,而不是由「保守起见」决定。
放弃了什么
绝对的一致保障。上游虽然没改,但重新生成可能会得到不同措辞,有时反而更协调。选择缓存就接受了「上游保持旧版本」这个前提。
什么条件下会失效
如果上游章节的产出本身不稳定、每次生成差异很大,缓存会造成风格割裂——旧的上游配新的下游,读起来别扭。 这种情况应该提供「强制全量重跑」的开关,而不是把策略写死。
为什么数值由程序计算、模型只写正文
为什么这么选
大模型做算术不可靠,而且它的错误是隐蔽的——算错的数字读起来同样通顺, 不会自己暴露。把数值交给确定性的程序,模型只负责把它组织成语言,各自的错误面都收窄了。
放弃了什么
端到端的简单性。需要为每个指标单独写计算逻辑,接入新指标时要改代码。
什么条件下会失效
如果任务本身不需要定量结论(纯叙述、建议类产出),这套分层就是多余的开销。判断标准是: 这个数字错了,读者能不能立刻看出来。看不出来就必须由程序算。
为什么 prompt 要抽成独立的 29 个资产,而不是写在代码里
为什么这么选
Prompt 是这个系统里变更最频繁的部分——调措辞、换风格、适配新场景,都要动它。 硬编码在代码里意味着每次调整都要走一遍发版流程。把最常改的东西放在最难改的位置,结果是没人愿意改。
放弃了什么
类型安全与静态检查。Prompt 是外部资源,写错了编译器不会告诉你,只能在运行时报错。
什么条件下会失效
如果项目规模小、prompt 数量少(三五个),外部化的管理成本会超过收益,直接放在代码里更简单。 这个做法在 prompt 数量上到两位数之后才开始划算。

五、失败与边界

  • 中断恢复的坑早期断点只记录「执行到哪一章」,没有记录该章的中间状态,恢复时那一章要重跑。后来把节点内的状态也一并持久化,才做到真正意义上的续写。
  • 上下文膨胀把所有上游章节全文塞给下游,很快撑爆上下文,且成本随章节数线性上涨。改为传递摘要加关键约束,只保留真正需要一致的信息。
  • 流式的边界SSE 在中间有反向代理时容易被缓冲住,表现为前端长时间无输出然后一次性刷出全文——看起来像卡死。需要在代理层关掉缓冲。

第三方组件的归属说明。服务里集成了成熟的定量计算组件用于部分指标计算。 这些组件是引用而非自研——页面与简历里都按「集成成熟计算组件」表述,不声称实现。

它不适合什么场景。单章节、短产出、无需反复修改的任务。这时图编排带来的复杂度(检查点、依赖管理、状态持久化)全是净成本,一次直接调用更合适。

六、链接与状态

状态整理中,可试用入口稍后开放
整理什么清理早期探索阶段的第三方引用目录、补齐文档、按技术命名重命名,然后才公开
公开前的硬前置限流与配额——公网开放等于开放一个花钱的接口,没有限流不上线

这是四项作品里唯一会开放可运行入口的一项,也是第一个挂上站的智能体。