AI 系统主链路分层设计：从 RAG 检索到 Agent 执行的模块职责划分

问题现象长链路 AI 系统频繁出现静默失败与状态不一致在 AI 应用上线后用户反馈智能问答结果偶尔返回空值或重复内容且后台日志显示任务已提交但无执行记录。进一步排查发现RAG 检索模块与 Agent 执行模块之间存在状态流转断层任务调度器未感知下游执行结果导致部分请求被静默丢弃。更严重的是当 MCP 工具调用超时整个链路未触发超时回滚而是继续等待最终引发线程阻塞与资源耗尽。此类问题并非偶发而是在高并发场景下周期性出现且难以通过单一模块日志定位根因。用户无感知系统无告警但实际服务可用性已下降。排查顺序从用户端到后端模块的逐层追踪我们采用“端到端链路追踪 模块状态快照”的方式展开排查前端日志用户请求 ID 存在请求成功发送至网关。网关日志请求被正确路由至 AI 服务入口。.RAG 模块日志检索成功返回 Top-K 文档状态为retrieved。.Agent 模块日志接收检索结果开始执行推理状态为executing。.MCP 调用日志工具调用超时无响应但未触发超时机制。.任务调度器日志未收到 Agent 模块的最终状态回写任务状态仍为pending。关键证据出现在任务调度器的状态机设计中其仅依赖主动轮询 Agent 模块获取状态而非接收事件驱动的状态变更通知。当 Agent 模块因 MCP 调用阻塞时调度器无法感知导致任务“假死”。核心原因模块职责模糊与状态流转断层根本问题不在于某个模块的实现缺陷而在于整体架构中模块职责划分不清导致状态流转依赖隐式耦合RAG 模块仅负责检索但未定义“检索完成”的语义边界是否包含缓存写入、结果格式化等操作Agent 模块承担推理与工具调用但未明确“执行完成”的定义是否包含 MCP 调用结果回写MCP 模块作为外部工具调用层未与任务调度器建立超时联动机制。任务调度器被动轮询状态缺乏事件驱动机制无法及时响应下游异常。这种设计导致状态流转依赖模块间隐式约定而非显式契约。异常处理分散在各模块缺乏统一治理。长链路中任一环节阻塞无法向上游传递形成“黑洞请求”。实现方案四层模块拆分与显式状态契约为解决上述问题我们对主链路进行分层重构明确各模块职责与交互边界1. RAG 检索层专注语义检索与结果标准化职责接收用户 query执行向量检索、重排序、去重输出结构化文档列表。输出契约返回{ status: success | partial | failed, docs: [...], trace_id }其中partial表示部分成功如缓存失效但 DB 检索成功。边界条件不处理缓存写入、不触发后续推理仅保证结果可序列化。落地建议使用 Protobuf 定义输出格式避免 JSON 字段歧义。2. Agent 执行层负责推理与工具调用编排职责接收 RAG 结果执行 LLM 推理调用 MCP 工具生成最终响应。状态机设计pending→executing→tool_calling→success/failed每个状态变更必须通过事件总线通知调度器。超时机制MCP 调用设置独立超时如 5s超时后立即回写failed状态不阻塞主线程。落地建议使用异步任务队列如 Celery 或自研调度器避免同步阻塞。3. MCP 工具层隔离外部依赖提供统一调用接口职责封装第三方 API、数据库查询、文件操作等工具调用。设计动机避免 Agent 模块直接依赖外部服务提升可测试性与可替换性。边界条件所有调用必须设置超时与重试策略。返回结果需标准化为{ success: bool, data: any, error: string }。落地建议使用适配器模式封装不同工具支持热插拔。4. 任务调度层事件驱动的状态治理中心职责接收用户请求协调 RAG → Agent → MCP 链路监控任务生命周期。核心机制采用事件驱动架构监听各模块状态变更事件。维护全局任务状态机支持超时自动回滚、失败重试、终态巡检。状态流转示例用户请求 → 调度器创建任务pending → RAG 完成 → 事件通知 → 调度器更新为 retrieved → Agent 开始执行 → 事件通知 → 调度器更新为 executing → MCP 调用超时 → Agent 回写 failed → 调度器触发重试或降级落地建议使用 Redis Stream 或 Kafka 作为事件总线确保事件不丢失。模块协作与收益分析通过上述分层我们实现以下收益职责清晰每个模块仅关注自身核心逻辑避免功能蔓延。状态可见所有状态变更通过事件广播调度器可实时感知。异常隔离MCP 调用失败不影响 RAG 检索Agent 阻塞不导致调度器死锁。可观测性增强通过事件日志可完整还原任务生命周期便于故障排查。风险与边界事件总线成为单点需部署高可用消息中间件并设置死信队列处理异常事件。状态回写延迟网络抖动可能导致事件延迟需在调度器中设置事件超时补偿机制。模块版本兼容性各模块输出契约变更需通过版本化协议管理避免线上兼容问题。技术补丁包RAG 输出契约标准化原理通过 Protobuf 定义检索结果格式确保跨模块数据一致性。 设计动机避免 JSON 字段歧义导致下游解析失败。 边界条件不支持嵌套超过 3 层的文档结构。 落地建议在 CI 中集成契约校验阻断不兼容变更。Agent 状态机事件驱动原理每个状态变更触发事件由调度器统一处理。 设计动机解决被动轮询导致的延迟与资源浪费。 边界条件事件丢失时需依赖终态巡检兜底。 落地建议使用幂等事件处理避免重复状态更新。MCP 工具调用超时隔离原理为每个工具调用设置独立超时超时后立即返回失败。 设计动机防止外部服务慢调用阻塞 Agent 主线程。 边界条件超时时间需根据工具类型动态配置。 落地建议使用线程池隔离不同工具调用避免资源竞争。任务调度器终态巡检原理定期扫描长时间处于中间状态的任务触发重试或降级。 设计动机弥补事件驱动架构中事件丢失的盲区。 边界条件巡检频率需平衡性能与实时性。 落地建议使用 Redis 过期键通知机制触发巡检。事件总线高可用部署原理采用多副本消息中间件确保事件不丢失。 设计动机避免单点故障导致状态流转中断。 边界条件需处理网络分区下的脑裂问题。 落地建议使用 Kafka 或 Pulsar配置合理副本数与 ACK 策略。总结AI 系统主链路的设计不应仅关注“能否跑通”更需考虑“如何稳定运行”。通过将 RAG、Agent、MCP 与任务调度明确分层并定义显式状态契约与事件驱动机制我们有效解决了长链路中的静默失败与状态不一致问题。这一设计不仅提升了系统稳定性也为后续扩展如多模型路由、动态降级奠定了基础。在工程实践中模块拆分的本质是职责划分而职责划分的核心是状态流转的清晰定义。