AI 应用架构模式全景图

从 Chat、RAG、Copilot、Agent 到工作流自动化：把 AI 产品形态翻译成可落地、可观测、可治理的系统架构

阅读定位: 这一页是 AI 工程总装图和 AI 产品 UX 之间的架构模式页。它不重复讲 Transformer、模型训练或单点 Prompt 技巧，而是回答一个 AI 应用到底应该选 Chat、RAG、Copilot、Agent、Workflow 还是评测闭环架构。

一、AI 应用架构的共同骨架

入口层
UI / API

→

上下文层
Prompt / Memory

→

能力编排
RAG / Tool

→

模型路由
Gateway

→

返回体验
Stream / Verify

→

运营闭环
Trace / Eval

层级	核心问题	常见组件	失败信号
入口层	用户从哪里触发 AI，任务对象是什么	Chat UI、编辑器插件、业务按钮、API	用户不知道什么时候该用，输入上下文缺失
上下文层	模型基于什么材料和状态工作	Prompt 模板、会话状态、记忆、权限上下文	回答看似相关但脱离真实对象
能力编排	是否需要检索、工具、流程和人工确认	RAG、Tool Calling、Workflow、HITL	链路不可控、动作副作用不清
模型路由	用哪个模型、怎样降级、怎样控制成本	模型网关、缓存、Fallback、限流	贵、慢、不稳定，且无法归因
返回体验	结果怎样展示、校验、撤销和接管	流式输出、引用、Diff、确认门、重试	用户不信任，失败后不知道怎么办
运营闭环	系统怎样持续知道自己做得好不好	Trace、Eval、反馈、审计、成本归因	线上变差但团队只能凭感觉修

和“一次请求的一生”的边界

这里不是按时间顺序复述一次请求，而是在拆架构责任分层：同一条请求链路，在 Chat、RAG、Copilot、Agent 和 Workflow 中会有不同的上下文来源、编排方式、权限边界、返回体验和运营闭环。

二、架构模式如何映射到请求生命周期

模式	主要改变哪几段生命周期	架构含义	优先关注
Chat	输入、Prompt、推理、返回	核心是对话状态和输出体验，系统动作少，风险相对低	上下文窗口、停止条件、用户追问和失败提示
RAG	检索、重排、引用、不可回答	把“模型会不会”改成“证据是否足够且权限正确”	语料质量、权限过滤、引用忠实度和检索评测
Copilot	工作对象、局部建议、Diff、采纳反馈	AI 嵌在人的工作流旁边，重点不是替代用户，而是让用户可控地完成任务	上下文对象、可编辑输出、撤销和采纳率
Agent	规划、工具调用、观察、重试、审计	请求会变成多步循环，成本、权限和恢复难度显著上升	工具 schema、最小权限、最大步数、幂等和人工确认
Workflow + LLM	确定流程节点、异常分支、人工复核	让模型嵌入可控流程，而不是让模型自由决定全部路径	流程闸门、批量回滚、异常样本和审计证据
Eval Loop	Trace、反馈、坏例回流、回归闸门	把一次请求变成可学习、可复盘、可发布治理的生产资产	样本版本、指标分层、线上反馈和发布门禁

三、六类主流架构模式

模式	典型形态	适合场景	核心风险	优先下钻
Chat Assistant	用户提问，模型回答	解释、探索、通用问答、低风险生成	没有任务对象，容易变成“万能输入框”	Prompt / 上下文、AI 产品 UX
RAG 应用	检索知识后再回答	企业知识库、客服、政策问答、文档助手	错召回、漏召回、引用误导、权限穿透	RAG、Embedding / 检索
Copilot	嵌入当前工作对象旁边辅助	代码、写作、表格、设计、运营后台	上下文错位、建议难采纳、用户控制弱	AI 产品 UX、AI 编程 Agent
Agent	模型规划并多步调用工具	研究、办公自动化、编码、数据处理	步骤失控、工具越权、成本膨胀	Agent 系统、Tool Calling
Workflow + LLM	确定流程中嵌入模型判断节点	审核、分流、摘要、质检、批处理	错误规模化扩散，异常路径被忽略	AI 工作流 / HITL / 状态管理、审批流 / BPM、LLMOps
Eval / Feedback Loop	用评测、反馈和回归持续改系统	生产 AI、模型切换、Prompt 迭代、质量门禁	只看离线分数，不看真实任务价值	模型评测、LLMOps

四、架构选型：先看任务，不先看模型

知识型任务

问题核心是“答案是否基于正确材料”
优先 RAG、引用、权限过滤和检索评测
不要用更大模型掩盖知识来源混乱

协作型任务

问题核心是“用户能不能采用和接管”
优先 Copilot、Diff、编辑、撤销和版本回退
结果不一定要完全自动完成，先让人更快完成

执行型任务

问题核心是“动作有没有副作用”
优先工具 schema、最小权限、确认门和审计
自治程度要随风险逐步放开

运营型任务

问题核心是“系统能否长期稳定变好”
优先 Trace、评测集、反馈闭环和成本归因
上线不是结束，而是数据飞轮开始

五、模式组合：真实产品通常不是单一模式

组合	结构	适合	关键控制点
Chat + RAG	聊天入口 + 检索证据 + 引用返回	知识助手、政策问答、客服助手	权限过滤、引用可信度、拒答边界
Copilot + RAG	当前工作对象 + 相关资料召回 + 局部编辑	写作、代码、合同、报告	上下文对象、Diff 体验、用户采纳反馈
Workflow + LLM	确定流程节点 + 模型分类 / 摘要 / 建议	审核、分流、批处理、质检	异常兜底、人工复核、批量回滚
Agent + Workflow	Agent 负责探索，工作流负责边界和审批	办公自动化、研究、运维辅助	最大步数、确认门、幂等与补偿
RAG + Eval Loop	检索链路 + 坏例回流 + 回归评测	知识库长期运营	检索评测、重排、语料刷新和版本管理
Gateway + Policy	统一模型入口、路由与 Fallback、限流、安全策略	多团队、多模型、多租户平台	租户隔离、成本预算、审计证据

5.1 组合案例：企业知识工单助手的一次请求

请求阶段	参与的架构模式	系统动作	关键证据
用户提问	Chat / Copilot	从工单侧边栏触发，带入用户角色、当前客户、产品版本、工单历史和可见知识域。	entrypoint、tenant_id、role、ticket_id、context_object_id
知识召回	RAG	按用户权限检索制度、历史工单、产品文档和变更记录，做重排、去重和引用候选。	index_id、doc_ids、chunk_ids、source_versions、acl_decision
外部系统接入	MCP / Connector	通过连接器读取 CRM 客户状态、产品订阅、最近故障公告和工单 SLA，不把全部系统数据散装塞进 Prompt。	connector_id、resource_uri_hash、auth_scope、resource_snapshot
行动建议	Agent / Tool Calling	模型生成处理计划，必要时调用只读查询工具；涉及改状态、发邮件、退款或升级时进入确认门。	tool_name、arguments_hash、permission_decision、approval_required
流程推进	Workflow + HITL	低风险回答直接建议给客服；高风险操作进入人工复核；外部系统失败时挂起任务并保留恢复点。	workflow_state、checkpoint_id、reviewer_id、retry_lineage
回答与引用	Grounded Answer	返回可编辑建议、引用来源、不可回答说明和下一步动作；用户可以采纳、改写、拒绝或转人工。	claim_ids、citation_check_status、final_output_hash、acceptance_signal
运营闭环	Eval / Feedback Loop	把失败样本、低采纳回答、引用冲突和人工改写沉淀为评测集，进入下一次发布门禁。	feedback_label、failure_tag、eval_case_id、release_version

这个案例想说明什么

真实 AI 应用很少只是“Chat、RAG 或 Agent”三选一。更常见的形态是：Chat 负责入口，RAG 负责证据，连接器负责外部系统，Agent 负责有限行动，Workflow 负责边界和恢复，Eval Loop 负责持续变好。架构评审时要问清每一层的责任和证据，而不是把所有复杂性都交给模型。

5.2 架构选型到生产证据

选型问题	架构选择	必须落到 Trace / 发布证据	上线前要证明
用户只是探索还是处理具体对象？	Chat 或 Copilot / Context Action	entrypoint、context_object_id、user_visible_mode、acceptance_signal	用户知道 AI 基于哪个对象工作，能编辑、撤销和反馈
答案是否必须有证据？	RAG + Citation + 不可回答策略	source_versions、chunk_ids、citation_ids、citation_check_status	引用忠实、权限正确，缺证据时不会编造
是否会调用外部系统？	Connector / MCP + Tool Runtime	connector_id、resource_uri_hash、auth_scope、tool_schema_version	连接器权限最小化，工具参数和资源版本可复盘
是否有副作用动作？	Tool Calling + Workflow + HITL	permission_decision、approval_id、idempotency_key、workflow_state	高风险动作有预览、确认、幂等、补偿和审计
是否要持续变好？	Eval Loop + Feedback Flywheel	feedback_label、failure_tag、eval_case_id、release_gate_id	坏例能回流到评测和发布闸门，而不是停在用户反馈里

架构选型要能被审计

选择 Chat、RAG、Copilot、Agent 或 Workflow，本质是在选择上下文来源、自动化程度、用户控制点和证据要求。架构评审不能只停在图上，要能落到请求字段、发布证据和失败恢复。

六、从 Demo 到生产的架构升级

阶段	主要目标	必须补的系统能力	不要过早做
原型	验证任务是否有价值	清晰场景、少量真实样本、人工核查	复杂 Agent 框架和多模型平台
内测	验证质量和体验	Prompt 版本、Trace、反馈收集、失败分类	完全自治和大规模自动执行
灰度	验证稳定性和成本	限流、缓存、评测集、告警、回滚	盲目扩大覆盖面
生产	长期可运营	模型路由、权限、审计、合规、SLO、成本归因	只靠人工观察线上表现
平台化	让多团队复用能力	统一网关、组件模板、策略中心、评测平台	把所有场景压成同一个通用助手

七、架构评审清单

问题	要看什么	风险信号
任务边界是否清楚	目标用户、输入对象、输出用途、失败成本	只说“做一个 AI 助手”
上下文从哪里来	用户输入、系统状态、知识库、权限和历史记忆	所有材料都塞进 Prompt
模型是否需要工具	只回答、查资料、改状态、发起外部动作	工具权限大于任务需要
结果怎样校验	引用、Schema、业务规则、人工确认、评测集	无法判断“答得好不好”
失败怎样恢复	重试、回滚、补偿、转人工、用户可见错误	失败只显示“请稍后再试”
权限、审计和合规怎样闭环	最小权限、操作留痕、数据来源、用户影响和合规责任；参考 AI 安全 / 护栏与 AI 治理 / 合规	没有请求级证据链，也没有责任边界
上线后怎样运营	Trace、反馈、成本、风险、版本和审计	线上变差但团队只能凭感觉修

八、常见误区

误区：先选模型，再设计架构

模型只是能力底座；真正决定产品成败的是任务边界、上下文、工具权限、体验和运营闭环。

误区：Agent 是所有 AI 应用的终局

很多场景用 Workflow + LLM 更稳，用 Copilot 更可控，用 RAG 更可解释。自治不是默认目标。

误区：RAG 等于向量库

RAG 是知识摄入、权限、检索、重排、引用、评测和反馈的完整系统，向量库只是其中一块。

误区：Demo 能跑就能上线

生产环境要面对延迟、成本、权限、错误恢复、用户信任、审计和合规，缺一块都会让系统脆弱。

九、回到 AI 主干

AI 全景 → AI 工程实战 → 一次请求的一生 → 模型路由 / Fallback → 应用架构模式 → Workflow / HITL → AI 产品 UX → RAG → Agent → LLMOps / 评测 → AI 治理 / 合规

一句话总结

AI 应用架构不是把模型 API 接上去，而是按任务风险选择 Chat、RAG、Copilot、Agent、Workflow 和 Eval Loop 的组合，并把上下文、工具、体验、成本和治理闭环一起设计。