解决方案架构与技术取舍

架构从约束出发

先记录用户规模、峰值任务量、可接受等待、数据位置、权限和运维能力。选择足够解决当前问题的最小结构；只有出现明确扩展或隔离需求时再拆分服务。

贯穿案例的逻辑组件

浏览器工作台调用后端服务；后端验证用户和工单所属租户，查询工单数据库与授权知识索引，调用模型生成草稿，最后保存草稿和审计事件。原始资料保存在受控文档存储，浏览器只能通过授权链接查看。

组件	责任	不应承担
工作台	输入、引用、进度与复核	保存模型服务密钥
业务服务	权限、状态、配额与编排	让模型决定访问范围
检索服务	按版本和权限找证据	用相似度代替授权
模型适配层	超时、预算、输出校验	直接执行高风险动作
异步任务	文档解析与索引更新	静默吞掉失败文件

这是一张逻辑架构，可在单体应用中实现，不要求每个组件独立部署。

技术取舍的决策记录

用 ADR 模板记录背景、候选、证据、决定、代价和重审条件。首期选择“只读检索 + 人工审核”，因为自动发送增加错误传播和外部动作风险。若将来增加写入，需要重新评估权限、幂等、批准和恢复。

部署方式不能只比较模型费用。还要比较数据流向、日志保留、网络可达性、运行人员与升级成本。自建服务带来更多控制，也带来容量、可用性和补丁维护责任。

故障与降级设计

模型不可用时保留普通搜索与人工回复；索引更新失败时保留上一完整版本并报告新鲜度；资料被撤权时应立即停止使用对应内容，不能为了可用性继续服务旧缓存。业务状态和模型草稿分离，避免模型超时影响工单读取。

练习与完成标准

提交组件图、数据流、信任边界、三个关键 ADR 和依赖故障表。让另一位工程师沿一次查询指出身份在哪里验证、证据如何选择、失败如何处理。下一步阅读接口契约。

参考阅读与使用边界

• OpenAPI 官方规范：相关概念与方法的延伸阅读，访问核验日期 2026-10-14。本站练习、流程与指标为自主编排，不属于来源机构认证。
• 学习路线 · 项目实战 · 可下载模板

本页为基础指南；生产操作需结合实际版本、授权环境与审核证据验证。