--- title: "有状态 LLM 平台的生产化架构" canonical: https://wavect.io/zh/blog/stateful-llm-platform-production-architecture/ language: zh description: "有状态 LLM 平台生产化实战：持久化、租户访问、后台长任务、API、部署回滚与持续 QA。" image: "https://wavect.io/img/blog/headers/header_stateful-llm-platform-production-architecture.png" --- [**返回**](/zh/blog/overview/) [![Christof Jori](/img/team/christof.webp)](/zh/team/christof-jori/) [Christof Jori](/zh/team/christof-jori/) https://linkedin.com/in/jocr77 10 分钟 阅读 · 2026年8月14日 最近审核 2026年8月14日 [**下一篇**](/zh/blog/fintech-architecture-remediation-without-rewrite/) # 如何在不重写产品的前提下把有状态 LLM 平台推向生产 要点速览 有状态 LLM 平台的生产化，核心并不是模型服务本身，而是把状态、身份、长时间工作、外部访问、部署和恢复变成明确的系统边界。在这个匿名实战项目中，Wavect 保留了已经有效的产品逻辑，并按依赖顺序加固基础：先定义受控运行范围，再将权威运行状态迁移到 PostgreSQL，集中处理租户级和对象级授权，把昂贵的 LLM 工作放入有归属且具备幂等性的后台任务，分别保护 API 与 MCP 访问，以基础设施即代码、依赖感知健康检查和回滚机制部署，最后把自动化测试与反复浏览器 QA 组成统一发布系统。结果是一个可信的受控试点，而不是对高可用性的过度承诺。生产就绪代表有证据、有残余风险说明的运行边界，不只是绿色构建或精致界面。 **有状态 LLM 平台的生产架构，是一组让 AI 应用能够面向多个用户持续、安全运行的系统边界。**它涵盖权威数据、身份、对象访问、昂贵的后台工作、外部接口、部署、恢复和验证。模型调用只是这个运行系统中的一个组件。 本文只回答一个明确问题：如何把功能丰富、原本用于本地研究的有状态 LLM 应用，转变为可控的共享试点？是否需要知识图谱，由我们的 [AI 智能体图工程决策指南](/zh/blog/graph-engineering-ai-agents/) 负责回答。通用的 [从原型到生产指南](/zh/software-development-guide/vibe-coded-prototype-to-production/) 也拥有独立搜索意图。本文关注的是一套已经包含有价值产品逻辑的平台，应当按照什么依赖顺序完成生产化。 **匿名边界：**这是来自 Wavect 交付记录的真实项目，不是拼接案例。我们省略客户名称、产品类别、所在地区、内部功能名称、生产主机名、精确拓扑以及尚未解决的安全细节。技术类别、生产化顺序、故障模式和权衡均来自真实工作，但不代表任何客户结果或行业基准。 ## 有状态 LLM 应用与演示版有什么不同？ 演示版可以把上下文留在浏览器会话里，从文件重新加载样例数据，并同步等待模型响应。共享平台不能依赖这些假设。用户会期待数据在部署后仍然存在，权限在所有接口上保持一致，长时间操作在超时、刷新或失败之后仍然能够被理解和恢复。 本项目的起始应用已经包含结构化领域数据、图操作、文档摄取、有依据的对话、访谈、模拟和评估等大量产品逻辑。缺口并不在功能清单，而在于连接这些功能的各条路径缺少明确的运行责任。 | 适合研究的假设 | 共享平台的要求 | 保持隐式时的故障 | | --- | --- | --- | | 文件就是实时状态 | 单一权威事务存储 | 部署或并发用户产生不一致数据。 | | 只有一个可信操作者 | 服务端验证身份和对象访问 | 合法用户可以访问他人的数据。 | | 请求一直等待模型 | 有归属、可观察、可恢复的任务 | 超时看起来像失败，重试会重复工作。 | | 浏览器是唯一客户端 | 浏览器、API 和 MCP 使用同一策略 | 新接口绕过只存在于 UI 的规则。 | | 进程运行就代表健康 | 依赖感知的就绪检查和回滚 | 流量进入无法给出正确结果的应用。 | | 手工测试证明可发布 | 自动检查加代表性流程 QA | 跨层回归在每次变更后重复出现。 | ## 按七层依赖顺序完成生产化 顺序至关重要。先打磨界面再解决持久化和访问控制，只会让不稳定行为更容易展示。先开放外部 API 再统一授权，则会制造第二套安全模型。因此，每一层基础都要先获得稳定责任人，之后才能扩大上层能力。 ### 1. 先定义运行边界，再选择基础设施 目标是受控初始发布，而不是宣称拥有全球冗余的企业基础设施。这个目标给出了直接验收标准：可重复的 HTTPS 部署、持久数据、受控入驻、可恢复发布、可用日志，以及一份明确的后续扩展与可用性工作清单。 准确描述边界可以避免架构表演。对于设计合作伙伴试点，单个应用任务和单可用区数据库可能合理，前提是故障模式、备份和升级路径已经记录。但这并不等于高可用。明确边界之后，团队可以在真实使用量值得投入时购买下一层可靠性。 ### 2. 将权威运行状态迁移到 PostgreSQL 应用原本拥有便于携带的种子文件和本地数据流，这些设计在研究阶段很有用。Wavect 保留文件作为受控启动材料，同时把领域对象、本体、用户、组织、访问授权、会话和机器凭据迁移到 PostgreSQL 支持的存储层。 关键选择是所有权，而不是数据库品牌。每个领域都获得存储或仓储契约、连接池和明确的增删改查行为。启动时仍可确定性地初始化空环境，但运行中的容器不再把可变文件视为事实来源。数据库集成测试随后验证了共享部署实际使用的持久化行为。 ### 3. 集中管理身份、租户成员关系和对象授权 身份验证只能证明请求是谁发出的，不能证明此人可以打开某个对象、图或任务。因此，平台把可撤销的服务端浏览器会话、管理员角色、组织成员关系和用户级对象授权统一到一条访问决策路径。浏览器路由、JSON API 与外部客户端都必须询问同一个问题。 [OWASP API1:2023 对象级授权失效](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/) 描述的正是这条边界：每个接收对象标识符的端点，都必须验证已登录用户是否有权对该对象执行请求操作。UUID、有效 JWT 或隐藏按钮都不能替代授权检查。 实用测试矩阵需要交叉覆盖角色、组织、对象和传输方式。普通用户不能通过修改标识符获得访问权。组织管理员必须被限制在自己的组织内。会话或 API 密钥被撤销后，应当立即失效，而不是等待下一次部署。 ### 4. 把长时间 LLM 工作视为有归属的任务 文档提取、访谈、画像生成和模拟可能持续超过普通 HTTP 请求。单纯延长 Web 服务器超时只能缓解一个症状，无法回答任务属于谁、重试是否安全，以及用户如何知道真实状态。 Wavect 引入了与后端实现无关的任务契约，包括类型化状态、处理器注册、用户级并发限制、幂等键、协作取消、结果与错误存储、完成任务过期以及优雅关停。轮询端点提供简单基线，Server-Sent Events 提供应用进度和心跳，同时不让浏览器连接成为任务本身的所有者。 | 任务属性 | 必须回答的问题 | 发布证据 | | --- | --- | --- | | 归属 | 哪个已认证用户可以查看或取消？ | 跨用户访问测试默认拒绝。 | | 幂等性 | 同一操作提交两次会怎样？ | 重复请求对应一次预期执行。 | | 进度 | 能否区分运行、停滞、失败和完成？ | 轮询与事件路径显示相同状态。 | | 取消 | 昂贵工作能否在安全边界停止？ | 处理器配合取消并记录最终状态。 | | 关停 | 部署期间会发生什么？ | 队列完成排空或标记未完成工作以便恢复。 | 进程内执行器是试点阶段的有意权衡，而不是最终扩展方案。任务契约让系统以后可以迁移到持久队列，而无需重写每个产品流程。重点在于把任务生命周期与最初执行它的后端分离。 ### 5. 为浏览器、API 与 MCP 明确定义安全契约 外部 API 被重组为模块化路由组，共享依赖、标准错误、范围检查、对象授权和限流。用户会话、JWT 和哈希 API 密钥服务不同客户端，但最终都进入同一领域权限体系。管理员还可以针对特定对象关闭外部访问，而不是默认暴露全部能力。 MCP 同样需要这些纪律。工具调用不会因为由智能体发起就自动可信。标识符验证、读写范围分离、速率限制和错误清理仍然必要。当前的 [Model Context Protocol 授权规范](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) 要求授权请求绑定目标资源，并验证令牌受众。新集成应遵循当前协议，不能复制旧实现的会话或传输假设。 ### 6. 让部署健康反映用户真正依赖的服务 基础设施即代码定义网络、容器服务、私有数据库、负载均衡、TLS、DNS、镜像仓库、日志与权限。工作流从提交构建带版本镜像，更新服务并等待稳定。应用健康端点还检查数据库连接，所以一个无法访问权威存储的活进程不会被视为就绪。 部署控制必须包含失败动作。 [AWS 文档说明了部署熔断器与 CloudWatch 告警](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-failure-detection.html) ，它们可以检测失败的 ECS 部署并回滚到上一个已知正常状态。在本项目中，基于健康状态的部署和回滚属于发布设计，而不是运维人员临时补救。 ### 7. 将自动化测试与反复浏览器 QA 结合 单元测试分别覆盖图存储、检索、依据、安全和任务行为。独立集成测试轨道使用真实 PostgreSQL，验证持久化、身份验证、API 与 MCP。这样既保留快速反馈，又没有模拟掉共享环境中最容易失败的边界。 自动化不能替代探索式 QA。反复浏览器测试发现了登录过期、选择状态、长任务进度、图编辑、计算、主题同步、错误和加载行为中的交互问题。每个缺陷都在最低且稳定的责任层修复，并在可行时加入回归测试。 这种按风险排序的方法与 [NIST 安全软件开发框架](https://csrc.nist.gov/projects/ssdf) 一致。该框架将安全开发分为组织准备、软件保护、安全软件生产以及对残余漏洞的响应。NIST 明确把它定位为可调整的风险改进基础，而不是适用于所有项目的固定清单。 ## 哪些证据能让受控试点可信？ 生产就绪不是代码仓库的二元属性，而是需要在运行边界内用证据支持的发布主张。对于这类平台，最低有效证据集如下： | 边界 | 发布前证据 | 需要说明的残余风险 | | --- | --- | --- | | 数据 | 针对 PostgreSQL 的持久化和种子测试，以及备份恢复流程 | 迁移与恢复成熟度 | | 访问 | 会话和令牌客户端的角色、租户与对象测试 | 管理员滥用与未来策略增长 | | LLM 任务 | 重复、取消、超时、错误与关停行为 | 进程内队列的持久性与容量 | | 外部接口 | 范围、限流、无效输入和清理后错误测试 | 协议演进与第三方客户端行为 | | 部署 | 健康感知发布、可观察失败和已测试回滚 | 单任务与单可用区的可用性 | | 用户流程 | 包含过期或部分状态恢复的代表性浏览器路径 | 大型交互界面中未覆盖的组合 | ## 为什么渐进式生产化优于重写 现有应用已经编码了来之不易的产品行为。重写会把可见技术债换成隐藏的产品回归风险。更快的路径是保留已验证流程，在其下方建立稳定责任边界，再基于新基础修复缺陷。 这不代表保留所有旧选择。文件不再是权威运行状态，访问检查离开单独路由，长任务不再属于某个请求，API 依赖变得明确，共享界面模式替代局部修补。渐进式生产化是带证据链的选择性替换，不是无限打补丁。 如果你的产品也有类似结构，Wavect 的 [AI 赋能与架构服务](/zh/services/ai-enablement/) 覆盖评估、系统边界、生产加固与交接。匿名的 [分析平台案例](/zh/case-studies/bond-analytics/) 提供了另一个不公开客户名称的复杂数据产品稳定化实例。若要决定保留还是重建，请使用 [从原型到生产指南](/zh/software-development-guide/vibe-coded-prototype-to-production/) ，或带上当前运行限制 [申请生产架构评审](/zh/contact/) 。 ## 有状态 LLM 平台生产架构常见问题 ### 什么是有状态 LLM 平台？ 它是一类 AI 应用，其跨请求价值依赖持久领域数据、用户或租户身份、权限、任务状态、历史或关联记录。模型只是一个组件，平台还必须负责持久化、访问、执行和恢复。 ### LLM 应用应当先生产化哪一部分？ 先定义运行边界，再建立权威持久化和统一授权路径。后台任务、外部 API、部署自动化和更广泛的界面 QA 都依赖这些基础，过早实施会制造重复的状态与策略模型。 ### 长时间 LLM 工作应当留在 HTTP 请求中吗？ 如果工作可能超过普通请求时间、需要重试或取消，或者刷新后仍需查看，通常不应留在请求中。应使用有归属的任务，明确状态、幂等性、进度、取消、结果存储和关停行为。 ### MCP 服务器应如何访问平台数据？ 把 MCP 视为另一种外部接口。验证标识符和客户端，把令牌绑定到目标资源，执行对象权限与读写范围，限制调用并清理错误。服务端策略不能依赖智能体或客户端界面。 ### 成功试点是否代表高可用？ 不是。受控试点可以在更窄可用性目标下接近生产并创造价值。应记录任务数量、数据库拓扑、队列持久性、备份恢复、回滚和事故责任，再按这个运行边界描述发布。 ### 什么时候值得重写？ 当核心数据模型无法表达产品、安全共存不可行，或替换基础的成本低于反复适配时，重写才有依据。除非证据表明无法安全运行，否则应保留有价值的产品逻辑和用户流程。 ## 最终思考 当每个重要状态和权限都有明确责任人时，有状态 LLM 平台才真正可运营。PostgreSQL 负责持久运行数据，中央策略负责租户与对象访问，任务层负责昂贵工作，API 与 MCP 路由复用这些决定，部署健康反映真实依赖，测试与浏览器 QA 提供发布证据。 保留用户已经认可的产品行为，替换无法支持共享运行的基础。最重要的是诚实命名运行边界。一个明确说明权衡的受控试点，比含糊的生产就绪声明更能体现工程质量。 ## 你可能也喜欢.. [**无需重写的金融科技架构修复** 另一个匿名实战案例，讲解如何为金融产品安排架构、授权、持久化和发布门禁。](/zh/blog/fintech-architecture-remediation-without-rewrite/) [**上线前软件 QA 清单** 把生产就绪转化为可用于发布决策的实际证据清单。](/zh/software-development-guide/software-qa-checklist-before-launch/) 架构与平台 ## 继续浏览此集群 对长期交付产生影响的框架、平台与系统设计选择。 [从核心文章开始**智慧城市软件架构：MQTT、LoRaWAN、Kubernetes 与 Terraform**](/zh/blog/smart-city-architecture-best-practices-2026/) - [食品零售 AI：MPREIS 机会地图](/zh/blog/mpreis-ai-grocery-retail-opportunity-map/) - [Tirol Kliniken（TILAK）：数字化运营机会图](/zh/blog/tirol-kliniken-digital-opportunity-analysis/) - [TIWAG 数字能源机会图：软件、AI 与自动化](/zh/blog/tiwag-digital-energy-services-opportunity-map/) - [AI 生成 3D 游戏模型：2026 工具与质量指南](/zh/blog/ai-3d-model-generators-game-development-2026/) - [不彻底重写，如何修复金融科技系统架构](/zh/blog/fintech-architecture-remediation-without-rewrite/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) [![Christof Jori](/img/team/christof.webp)](/zh/team/christof-jori/) [Christof Jori](/zh/team/christof-jori/) https://linkedin.com/in/jocr77 10 分钟 阅读 · 2026年8月14日 最近审核 2026年8月14日 [**下一篇**](/zh/blog/fintech-architecture-remediation-without-rewrite/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/stateful-llm-platform-production-architecture/#webpage", "@type": "WebPage", "dateModified": "2026-08-14", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-14", "url": "https://wavect.io/zh/blog/stateful-llm-platform-production-architecture/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "有状态 LLM 平台的生产化，核心并不是模型服务本身，而是把状态、身份、长时间工作、外部访问、部署和恢复变成明确的系统边界。在这个匿名实战项目中，Wavect 保留了已经有效的产品逻辑，并按依赖顺序加固基础：先定义受控运行范围，再将权威运行状态迁移到 PostgreSQL，集中处理租户级和对象级授权，把昂贵的 LLM 工作放入有归属且具备幂等性的后台任务，分别保护 API 与 MCP 访问，以基础设施即代码、依赖感知健康检查和回滚机制部署，最后把自动化测试与反复浏览器 QA 组成统一发布系统。结果是一个可信的受控试点，而不是对高可用性的过度承诺。生产就绪代表有证据、有残余风险说明的运行边界，不只是绿色构建或精致界面。", "articleBody": " 博客概览/交付与 QA/架构与平台 如何在不重写产品的前提下把有状态 LLM 平台推向生产 要点速览 有状态 LLM 平台的生产化，核心并不是模型服务本身，而是把状态、身份、长时间工作、外部访问、部署和恢复变成明确的系统边界。在这个匿名实战项目中，Wavect 保留了已经有效的产品逻辑，并按依赖顺序加固基础：先定义受控运行范围，再将权威运行状态迁移到 PostgreSQL，集中处理租户级和对象级授权，把昂贵的 LLM 工作放入有归属且具备幂等性的后台任务，分别保护 API 与 MCP 访问，以基础设施即代码、依赖感知健康检查和回滚机制部署，最后把自动化测试与反复浏览器 QA 组成统一发布系统。结果是一个可信的受控试点，而不是对高可用性的过度承诺。生产就绪代表有证据、有残余风险说明的运行边界，不只是绿色构建或精致界面。 有状态 LLM 平台的生产架构，是一组让 AI 应用能够面向多个用户持续、安全运行的系统边界。它涵盖权威数据、身份、对象访问、昂贵的后台工作、外部接口、部署、恢复和验证。模型调用只是这个运行系统中的一个组件。 本文只回答一个明确问题：如何把功能丰富、原本用于本地研究的有状态 LLM 应用，转变为可控的共享试点？是否需要知识图谱，由我们的AI 智能体图工程决策指南负责回答。通用的从原型到生产指南也拥有独立搜索意图。本文关注的是一套已经包含有价值产品逻辑的平台，应当按照什么依赖顺序完成生产化。 匿名边界：这是来自 Wavect 交付记录的真实项目，不是拼接案例。我们省略客户名称、产品类别、所在地区、内部功能名称、生产主机名、精确拓扑以及尚未解决的安全细节。技术类别、生产化顺序、故障模式和权衡均来自真实工作，但不代表任何客户结果或行业基准。 有状态 LLM 应用与演示版有什么不同？ 演示版可以把上下文留在浏览器会话里，从文件重新加载样例数据，并同步等待模型响应。共享平台不能依赖这些假设。用户会期待数据在部署后仍然存在，权限在所有接口上保持一致，长时间操作在超时、刷新或失败之后仍然能够被理解和恢复。 本项目的起始应用已经包含结构化领域数据、图操作、文档摄取、有依据的对话、访谈、模拟和评估等大量产品逻辑。缺口并不在功能清单，而在于连接这些功能的各条路径缺少明确的运行责任。 适合研究的假设共享平台的要求保持隐式时的故障 文件就是实时状态单一权威事务存储部署或并发用户产生不一致数据。 只有一个可信操作者服务端验证身份和对象访问合法用户可以访问他人的数据。 请求一直等待模型有归属、可观察、可恢复的任务超时看起来像失败，重试会重复工作。 浏览器是唯一客户端浏览器、API 和 MCP 使用同一策略新接口绕过只存在于 UI 的规则。 进程运行就代表健康依赖感知的就绪检查和回滚流量进入无法给出正确结果的应用。 手工测试证明可发布自动检查加代表性流程 QA跨层回归在每次变更后重复出现。 按七层依赖顺序完成生产化 顺序至关重要。先打磨界面再解决持久化和访问控制，只会让不稳定行为更容易展示。先开放外部 API 再统一授权，则会制造第二套安全模型。因此，每一层基础都要先获得稳定责任人，之后才能扩大上层能力。 1. 先定义运行边界，再选择基础设施 目标是受控初始发布，而不是宣称拥有全球冗余的企业基础设施。这个目标给出了直接验收标准：可重复的 HTTPS 部署、持久数据、受控入驻、可恢复发布、可用日志，以及一份明确的后续扩展与可用性工作清单。 准确描述边界可以避免架构表演。对于设计合作伙伴试点，单个应用任务和单可用区数据库可能合理，前提是故障模式、备份和升级路径已经记录。但这并不等于高可用。明确边界之后，团队可以在真实使用量值得投入时购买下一层可靠性。 2. 将权威运行状态迁移到 PostgreSQL 应用原本拥有便于携带的种子文件和本地数据流，这些设计在研究阶段很有用。Wavect 保留文件作为受控启动材料，同时把领域对象、本体、用户、组织、访问授权、会话和机器凭据迁移到 PostgreSQL 支持的存储层。 关键选择是所有权，而不是数据库品牌。每个领域都获得存储或仓储契约、连接池和明确的增删改查行为。启动时仍可确定性地初始化空环境，但运行中的容器不再把可变文件视为事实来源。数据库集成测试随后验证了共享部署实际使用的持久化行为。 3. 集中管理身份、租户成员关系和对象授权 身份验证只能证明请求是谁发出的，不能证明此人可以打开某个对象、图或任务。因此，平台把可撤销的服务端浏览器会话、管理员角色、组织成员关系和用户级对象授权统一到一条访问决策路径。浏览器路由、JSON API 与外部客户端都必须询问同一个问题。 OWASP API1:2023 对象级授权失效描述的正是这条边界：每个接收对象标识符的端点，都必须验证已登录用户是否有权对该对象执行请求操作。UUID、有效 JWT 或隐藏按钮都不能替代授权检查。 实用测试矩阵需要交叉覆盖角色、组织、对象和传输方式。普通用户不能通过修改标识符获得访问权。组织管理员必须被限制在自己的组织内。会话或 API 密钥被撤销后，应当立即失效，而不是等待下一次部署。 4. 把长时间 LLM 工作视为有归属的任务 文档提取、访谈、画像生成和模拟可能持续超过普通 HTTP 请求。单纯延长 Web 服务器超时只能缓解一个症状，无法回答任务属于谁、重试是否安全，以及用户如何知道真实状态。 Wavect 引入了与后端实现无关的任务契约，包括类型化状态、处理器注册、用户级并发限制、幂等键、协作取消、结果与错误存储、完成任务过期以及优雅关停。轮询端点提供简单基线，Server-Sent Events 提供应用进度和心跳，同时不让浏览器连接成为任务本身的所有者。 任务属性必须回答的问题发布证据 归属哪个已认证用户可以查看或取消？跨用户访问测试默认拒绝。 幂等性同一操作提交两次会怎样？重复请求对应一次预期执行。 进度能否区分运行、停滞、失败和完成？轮询与事件路径显示相同状态。 取消昂贵工作能否在安全边界停止？处理器配合取消并记录最终状态。 关停部署期间会发生什么？队列完成排空或标记未完成工作以便恢复。 进程内执行器是试点阶段的有意权衡，而不是最终扩展方案。任务契约让系统以后可以迁移到持久队列，而无需重写每个产品流程。重点在于把任务生命周期与最初执行它的后端分离。 5. 为浏览器、API 与 MCP 明确定义安全契约 外部 API 被重组为模块化路由组，共享依赖、标准错误、范围检查、对象授权和限流。用户会话、JWT 和哈希 API 密钥服务不同客户端，但最终都进入同一领域权限体系。管理员还可以针对特定对象关闭外部访问，而不是默认暴露全部能力。 MCP 同样需要这些纪律。工具调用不会因为由智能体发起就自动可信。标识符验证、读写范围分离、速率限制和错误清理仍然必要。当前的Model Context Protocol 授权规范要求授权请求绑定目标资源，并验证令牌受众。新集成应遵循当前协议，不能复制旧实现的会话或传输假设。 6. 让部署健康反映用户真正依赖的服务 基础设施即代码定义网络、容器服务、私有数据库、负载均衡、TLS、DNS、镜像仓库、日志与权限。工作流从提交构建带版本镜像，更新服务并等待稳定。应用健康端点还检查数据库连接，所以一个无法访问权威存储的活进程不会被视为就绪。 部署控制必须包含失败动作。AWS 文档说明了部署熔断器与 CloudWatch 告警，它们可以检测失败的 ECS 部署并回滚到上一个已知正常状态。在本项目中，基于健康状态的部署和回滚属于发布设计，而不是运维人员临时补救。 7. 将自动化测试与反复浏览器 QA 结合 单元测试分别覆盖图存储、检索、依据、安全和任务行为。独立集成测试轨道使用真实 PostgreSQL，验证持久化、身份验证、API 与 MCP。这样既保留快速反馈，又没有模拟掉共享环境中最容易失败的边界。 自动化不能替代探索式 QA。反复浏览器测试发现了登录过期、选择状态、长任务进度、图编辑、计算、主题同步、错误和加载行为中的交互问题。每个缺陷都在最低且稳定的责任层修复，并在可行时加入回归测试。 这种按风险排序的方法与NIST 安全软件开发框架一致。该框架将安全开发分为组织准备、软件保护、安全软件生产以及对残余漏洞的响应。NIST 明确把它定位为可调整的风险改进基础，而不是适用于所有项目的固定清单。 哪些证据能让受控试点可信？ 生产就绪不是代码仓库的二元属性，而是需要在运行边界内用证据支持的发布主张。对于这类平台，最低有效证据集如下： 边界发布前证据需要说明的残余风险 数据针对 PostgreSQL 的持久化和种子测试，以及备份恢复流程迁移与恢复成熟度 访问会话和令牌客户端的角色、租户与对象测试管理员滥用与未来策略增长 LLM 任务重复、取消、超时、错误与关停行为进程内队列的持久性与容量 外部接口范围、限流、无效输入和清理后错误测试协议演进与第三方客户端行为 部署健康感知发布、可观察失败和已测试回滚单任务与单可用区的可用性 用户流程包含过期或部分状态恢复的代表性浏览器路径大型交互界面中未覆盖的组合 为什么渐进式生产化优于重写 现有应用已经编码了来之不易的产品行为。重写会把可见技术债换成隐藏的产品回归风险。更快的路径是保留已验证流程，在其下方建立稳定责任边界，再基于新基础修复缺陷。 这不代表保留所有旧选择。文件不再是权威运行状态，访问检查离开单独路由，长任务不再属于某个请求，API 依赖变得明确，共享界面模式替代局部修补。渐进式生产化是带证据链的选择性替换，不是无限打补丁。 如果你的产品也有类似结构，Wavect 的AI 赋能与架构服务覆盖评估、系统边界、生产加固与交接。匿名的分析平台案例提供了另一个不公开客户名称的复杂数据产品稳定化实例。若要决定保留还是重建，请使用从原型到生产指南，或带上当前运行限制申请生产架构评审。 有状态 LLM 平台生产架构常见问题 什么是有状态 LLM 平台？ 它是一类 AI 应用，其跨请求价值依赖持久领域数据、用户或租户身份、权限、任务状态、历史或关联记录。模型只是一个组件，平台还必须负责持久化、访问、执行和恢复。 LLM 应用应当先生产化哪一部分？ 先定义运行边界，再建立权威持久化和统一授权路径。后台任务、外部 API、部署自动化和更广泛的界面 QA 都依赖这些基础，过早实施会制造重复的状态与策略模型。 长时间 LLM 工作应当留在 HTTP 请求中吗？ 如果工作可能超过普通请求时间、需要重试或取消，或者刷新后仍需查看，通常不应留在请求中。应使用有归属的任务，明确状态、幂等性、进度、取消、结果存储和关停行为。 MCP 服务器应如何访问平台数据？ 把 MCP 视为另一种外部接口。验证标识符和客户端，把令牌绑定到目标资源，执行对象权限与读写范围，限制调用并清理错误。服务端策略不能依赖智能体或客户端界面。 成功试点是否代表高可用？ 不是。受控试点可以在更窄可用性目标下接近生产并创造价值。应记录任务数量、数据库拓扑、队列持久性、备份恢复、回滚和事故责任，再按这个运行边界描述发布。 什么时候值得重写？ 当核心数据模型无法表达产品、安全共存不可行，或替换基础的成本低于反复适配时，重写才有依据。除非证据表明无法安全运行，否则应保留有价值的产品逻辑和用户流程。 最终思考 当每个重要状态和权限都有明确责任人时，有状态 LLM 平台才真正可运营。PostgreSQL 负责持久运行数据，中央策略负责租户与对象访问，任务层负责昂贵工作，API 与 MCP 路由复用这些决定，部署健康反映真实依赖，测试与浏览器 QA 提供发布证据。 保留用户已经认可的产品行为，替换无法支持共享运行的基础。最重要的是诚实命名运行边界。一个明确说明权衡的受控试点，比含糊的生产就绪声明更能体现工程质量。 你可能也喜欢.. 无需重写的金融科技架构修复 另一个匿名实战案例，讲解如何为金融产品安排架构、授权、持久化和发布门禁。 上线前软件 QA 清单 把生产就绪转化为可用于发布决策的实际证据清单。 架构与平台 继续浏览", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/" }, "citation": [ { "@type": "WebPage", "name": "OWASP API1:2023 对象级授权失效", "url": "https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/" }, { "@type": "WebPage", "name": "Model Context Protocol 授权规范", "url": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization" }, { "@type": "WebPage", "name": "AWS 文档说明了部署熔断器与 CloudWatch 告警", "url": "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-failure-detection.html" }, { "@type": "WebPage", "name": "NIST 安全软件开发框架", "url": "https://csrc.nist.gov/projects/ssdf" } ], "dateModified": "2026-08-14", "datePublished": "2026-08-14", "description": "有状态 LLM 平台的生产化，核心并不是模型服务本身，而是把状态、身份、长时间工作、外部访问、部署和恢复变成明确的系统边界。在这个匿名实战项目中，Wavect 保留了已经有效的产品逻辑，并按依赖顺序加固基础：先定义受控运行范围，再将权威运行状态迁移到 PostgreSQL，集中处理租户级和对象级授权，把昂贵的 LLM 工作放入有归属且具备幂等性的后台任务，分别保护 API 与 MCP 访问，以基础设施即代码、依赖感知健康检查和回滚机制部署，最后把自动化测试与反复浏览器 QA 组成统一发布系统。结果是一个可信的受控试点，而不是对高可用性的过度承诺。生产就绪代表有证据、有残余风险说明的运行边界，不只是绿色构建或精致界面。", "headline": "有状态 LLM 平台的生产架构", "image": "https://wavect.io/img/blog/headers/header_stateful-llm-platform-production-architecture.svg", "inLanguage": "zh", "keywords": "LLM 工程, 软件架构", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/stateful-llm-platform-production-architecture/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/stateful-llm-platform-production-architecture/", "wordCount": 277 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/delivery-qa/", "name": "交付与 QA", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/architecture-platforms/", "name": "架构与平台", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/stateful-llm-platform-production-architecture/", "name": "有状态 LLM 平台的生产化架构 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "它是一类 AI 应用，其跨请求价值依赖持久领域数据、用户或租户身份、权限、任务状态、历史或关联记录。模型只是一个组件，平台还必须负责持久化、访问、执行和恢复。" }, "name": "什么是有状态 LLM 平台？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "先定义运行边界，再建立权威持久化和统一授权路径。后台任务、外部 API、部署自动化和更广泛的界面 QA 都依赖这些基础，过早实施会制造重复的状态与策略模型。" }, "name": "LLM 应用应当先生产化哪一部分？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "如果工作可能超过普通请求时间、需要重试或取消，或者刷新后仍需查看，通常不应留在请求中。应使用有归属的任务，明确状态、幂等性、进度、取消、结果存储和关停行为。" }, "name": "长时间 LLM 工作应当留在 HTTP 请求中吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "把 MCP 视为另一种外部接口。验证标识符和客户端，把令牌绑定到目标资源，执行对象权限与读写范围，限制调用并清理错误。服务端策略不能依赖智能体或客户端界面。" }, "name": "MCP 服务器应如何访问平台数据？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不是。受控试点可以在更窄可用性目标下接近生产并创造价值。应记录任务数量、数据库拓扑、队列持久性、备份恢复、回滚和事故责任，再按这个运行边界描述发布。" }, "name": "成功试点是否代表高可用？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "当核心数据模型无法表达产品、安全共存不可行，或替换基础的成本低于反复适配时，重写才有依据。除非证据表明无法安全运行，否则应保留有价值的产品逻辑和用户流程。" }, "name": "什么时候值得重写？" } ] } ```