工程架构

任务编排为什么要放后端：让流程可控、可变、可回放 副标题 / 摘要 在多步骤、可中断、可回放的业务流程中，把“流程顺序与状态机”放在后端，是系统长期可演进的关键。本文从真实工程痛点出发，解释为什么前端不应硬编码流程顺序，并给出一套可落地的后端 Pipeline 编排思路与最小实现。 目标读者 正在设计多步骤流程 / 向导式产品的后端工程师 需要支撑 Web / App / Admin 多端一致流程的技术负责人 在 AI / LLM 产品中处理“模型自动 + 人工确认”混合流程的团队 背景 / 动机：问题通常是怎么爆出来的？ 很多系统一开始都很简单： 前端：第 1 步 → 第 2 步 → 第 3 步 后端：校验 + 存数据 但随着业务演进，以下需求几乎一定会出现： 步骤 变多：从 3 步变成 10+ 步 步骤 可选：根据条件跳过 / 插入新步骤 步骤 可中断：需要用户确认、补充信息、人工审核 步骤 可重试 / 可回放：失败后从中间继续，而不是全部重来 步骤 多端一致：Web / App / 内部工具共享同一流程 如果此时流程顺序仍然写在前端： 每次流程变更 = 多端发版 出问题时无法准确回答：现在卡在哪一步？ 想加监控、审计、回放，发现无从下手 根因只有一个： ...

摘要 很多团队做 AI 应用时会陷入一种痛苦：业务逻辑写了一堆，却始终看不到“算法到底抽出了什么”。根因往往不是代码能力，而是把算法阶段的探索，过早塞进业务工程。本文用“投标写作工具里的事实抽取（FactMention）”作为例子，讲清楚算法与业务的边界、如何用 JupyterLab 快速验证、以及何时进入工程化。 目标读者 正在做 LLM/RAG/信息抽取的工程师（初级到中级） 负责 AI 产品落地的技术负责人 / 架构师 经常在“写了半天流程，结果不知道抽取效果如何”的同学 背景与动机：为什么这个问题重要？ 在传统系统里，大家习惯把“算法”理解为一个函数或模型文件，把“业务”理解为接口与流程。但在 LLM 时代，这个界限变得更模糊： 算法不仅是模型，还包括 prompt、schema、抽取策略、规则归一、置信度与去重策略 算法输出往往是 不确定、需要人类直觉评估 的 如果你把这些“不确定”的东西直接嵌进业务链路（router/service/db/cache），你会遇到： 调试成本爆炸：只看到最后 response，不知道中间发生了什么 逻辑迭代极慢：改一行抽取策略，要跑完整流程 团队协作困难：大家在黑箱里争论“到底准不准” 因此，需要一个更清晰的边界：算法负责收敛中间态，业务负责稳定交付。 核心概念：算法与业务到底分别是什么？ 1）算法（Algorithm）的工程定义 算法负责把“模糊世界”压缩成“可用的结构化中间态”。 关键词：不确定性、探索、需要“看结果”、需要收敛。 在投标写作场景中，算法阶段的问题长这样： LLM 抽取出来的 payload 字段应该有哪些？ norm_key 怎么设计才代表“同一事实”？ 同一人多条命中（mentions）要不要合并？ confidence 到底有没有意义？怎么校准？ 这些问题的共同特点是：你必须看中间结果才能判断对不对。 2）业务（Business）的工程定义 业务负责在中间态稳定之后，把事情编排起来：什么时候取什么数据、走哪条链路、如何返回给用户。 关键词：确定性、可维护、可测试、可复用。 在投标写作场景中，业务阶段的问题长这样： retrive_type = personnel 时走事实检索，否则走原文档检索 接口响应结构固定，前端按协议渲染 存储从 MemoryTable 换成 DB，不影响上层调用 这些问题的共同特点是：输入输出清晰，错误是边界情况，而不是“我也不知道会不会抽出来”。 一条“贴墙上”的分界线 凡是你还说不清“中间结果长什么样”的阶段 → 用 JupyterLab。 凡是你能画出输入/输出 JSON 形态并写出测试用例的阶段 → 进工程。 实践指南：什么时候用 JupyterLab，什么时候用工程代码？ 阶段 1：事实抽取建模期（强制用 JupyterLab） 适用信号： ...