后端转 AI 的必考题：你既有 Go 业务经验又有 AI 经验，那两者怎么组织？混合架构的职责划分、通信方式、部署形态，答得清楚就是"后端经验是优势"的最佳证明。
💡 答案要点
核心认知： 企业级 AI 应用落地时，业务系统（用户、订单、权限、数据）大多在 Go/Java，AI 生态（模型 SDK、LangGraph、评测工具）在 Python。硬选一边都吃亏，混合架构是常态。
职责划分：
Go（业务底座） Python（AI 编排）
├─ 业务接口：客户/案件/合同/任务 ├─ 模型生态：OpenAI/本地模型 SDK
├─ 数据与规则：MySQL、事务、幂等 ├─ Skill：能力封装与版本管理
├─ 权限与审计：谁能调什么、留痕 ├─ Agent：LangGraph 编排、状态流转
└─ MCP 工具封装：业务能力变工具 ├─ 评测：Eval / 回归 / 灰度
└─ 运行时：流式输出、重试、熔断
一句话：Go 管"稳定"，Python 管"智能"。为什么这么分（选型理由）：
| 维度 | Go | Python |
|---|---|---|
| 业务系统 | 存量系统就是 Go/Java，重写成本极高 | 重写不现实 |
| 性能/高并发 | 高并发、低延迟、类型安全 | 不适合扛核心业务流量 |
| AI 生态 | SDK/框架少，社区滞后 | 模型、Agent、评测工具全在 Python |
| 迭代速度 | 稳定优先，变更谨慎 | AI 能力迭代快，试错成本低 |
| 风险 | 写 AI 编排生态太薄 | 写业务稳定性风险高 |
通信方式（关键设计）：
- HTTP：业务 API（前端 → Go 网关，鉴权、限流）；
- MCP 工具总线：Python Agent 通过 MCP 调 Go 封装的业务工具（客户/案件/合同/任务），工具带 JSON Schema、权限、幂等——两边通过协议解耦，AI 团队不碰业务库；
- 消息队列（规模大时）：异步任务（如质检转写、批量文书）走 MQ 削峰。
部署形态（Docker Compose 四服务）：
frontend / Nginx → 静态资源 + 反向代理
Go Backend (Gin) → 业务 API + MCP Server（工具封装）
Agent (FastAPI + MCP) → AI 编排 + Skill + 评测（内网）
MySQL → 业务数据 + 任务状态 + 审计（内网）一次完整请求的数据流：
前端 → Go 网关（鉴权/限流）→ Python Agent（规划）
→ MCP 调 Go 工具（鉴权/幂等/执行）→ MySQL
→ 结果回传 Agent 继续编排 → 流式返回前端
→ 全程 trace_id 跨语言链路（OpenTelemetry）坑与边界（加分点）：
- 跨语言链路追踪：trace_id 要在 Go/Python 间传递，统一用 OpenTelemetry，否则排查问题断链；
- 错误语义统一：Go 返回的结构化错误码，Python 侧要能理解（RETRYABLE/NON_RETRYABLE），否则 Agent 瞎重试；
- 双团队协作边界：接口契约先行（工具 Schema / API 文档），两边并行开发，联调成本才可控。
面试话术：
"我的混合架构原则是：Go 管稳定，Python 管智能。Go 负责业务接口、数据、规则和 MCP 工具封装——高并发、事务、幂等、鉴权都在这一层；Python 负责模型生态、Skill、LangGraph 编排和评测。两边通过 MCP 工具总线通信，Python Agent 自动发现 Go 封装的工具，按 Schema 调用，AI 团队全程不碰业务库。部署上 Docker Compose 四个服务：前端、Go 后端、Python Agent、MySQL。后端经验不是包袱而是地基——接口设计、权限、幂等、审计这些能力恰恰是 AI 应用最缺的。跨语言的关键是链路追踪用 OpenTelemetry 打通、错误码语义统一，这两点不解决，联调就是灾难。"
内容治理: 2026-08-18 | 新增 Q11 Go+Python 混合架构题（职责划分/MCP 工具总线/四服务部署/跨语言链路）；素材角度：企业级 AI 应用工程链路，已按仓库规范重写