前言
在大模型应用开发中，我们讨论了众多功能模块与范式。但在生产环境中，如何设计一个完整的、通用的、可不断优化迭代的全局视角架构至关重要。
架构图解
整个大模型应用系统通常分为三层：应用层、服务层、模型层。
- 应用层：直接接入大模型能力的具体业务应用。
- 服务层：提供核心能力的中间层。
- Core（核心应用）：包含 Agent、Workflow、CoT 等原子功能。
- Scene（场景）：基于原子能力搭建的定制化功能服务。
- BaaS：将能力以 API 形式开放，提供工程化支持。
- WebUI：提供界面交互，包含调试、流程搭建、评测及应用市场等功能。
- 模型层：负责数据清洗、模型训练、微调及基座模型管理。
最佳实践
1. 原子功能的界定
在功能划分上，核心功能被视为原子功能，代表它们地位对等，但不一定是物理上的不可分割。 例如，Agent 可以挂载 Workflow，Workflow 也可以包含 Agent，二者地位对等。但从应用角度看，Agent 或 Workflow 内部可能包含多个子功能，因此并非绝对原子。这里的'原子'主要指业务逻辑上的最小可用单元。
2. 对外服务的 BaaS 模式
从市场格局来看，能提供底层大模型能力的公司有限，多数企业聚焦于应用层。因此，大模型应用平台应以 BaaS（Backend as a Service）方式提供 LLM 能力和应用能力较为合理。
实际场景中，端云协同方案常采用 Agent SDK + SLM + CloudService 模式。
3. 场景层级的定位
场景功能放在服务层而非应用层，是为了降低应用接入复杂度。若仅提供 原子功能 + 流程编排，虽然保持了开放性，但会导致业务重复搭建类似流程，接入难度过高。在开放性与易用性之间保持平衡，提供相对开放的场景功能十分必要。
4. lmOps 下沉的重要性
不建议将 lmOps（大模型运维）功能集成到服务层，以防止因频繁微调导致成本失控。服务层的定位是为应用服务，而非为模型服务。若自研模型效果不佳，应直接切换更优模型，而非死磕微调。与低效模型做隔离是成本控制的关键。
5. 场景与范式的选择
两者皆需，但场景优先。如果纠结于提供通用范式还是特殊场景，建议先做场景。场景积累多了，自然能抽象出通用范式。
6. 推动架构落地的策略
大模型应用方向较新，产品经理往往缺乏分层架构概念。若团队地位较高，可强推落地；若处于执行层，建议分模块从应用侧入手，逐步沉淀，遵循结构化迭代原则（S-B-P-D）。此外，产品团队常缺乏 AI 评测指标认知，技术人员需反推产品需求，引导其理解技术亮点与价值。
7. 通用技术架构实现
针对服务层功能繁杂的问题，以下提供一个通用的技术架构参考，可根据实际情况调整：
7.1 核心组件
- API 网关：统一入口，处理鉴权、限流、路由。
- 编排引擎：负责 Workflow 的执行调度，支持状态机管理。
- 向量数据库：存储知识库嵌入，支持 RAG 检索。
- 模型注册中心：管理不同版本模型的元数据与路由策略。
- 监控告警系统：追踪 Token 消耗、延迟、错误率等关键指标。
7.2 扩展能力
- 安全过滤层：输入输出内容审核，防止敏感信息泄露。
- 缓存机制：对高频 Prompt 结果进行缓存，降低推理成本。
- 多模态支持：集成图像、语音处理能力，丰富应用场景。
7.3 部署建议
建议采用微服务架构，各组件独立部署，便于弹性伸缩。模型推理服务可单独集群管理，利用 GPU 资源池化技术提升利用率。
总结
大模型应用架构设计需要兼顾灵活性、成本与稳定性。通过清晰的层级划分、合理的原子功能定义以及工程化的 BaaS 支持，可以有效支撑复杂业务场景的快速迭代。技术团队应主动引导产品方向，注重评测体系的建设，确保技术投入转化为实际业务价值。
未来，随着端侧模型能力的增强，混合云架构将成为主流，开发者需持续关注 SLM（小语言模型）与云端大模型的协同优化。
