把四个组件串成一个系统：后端 Agent 决策
属于 S6 Agent Backend · 特色篇 上一篇：场景题（下）
前面五篇分别吃透了 MySQL、Redis、Kafka、微服务和场景题。这一篇是收尾——把这些组件放进一个真实的问题场景里：一个"后端 Agent 决策"系统。这既是四大组件的综合演练，也是你面试时区别于普通后端候选人的特色。
问题：Agent 决策系统里的四个角色
想象一个系统：接收用户任务（比如"帮我搜索资料并整理"），Agent 做决策，调用工具链执行，返回结果。这个流程里，四个中间件各管一段：
| 中间件 | 角色 | 解决什么问题 |
|---|---|---|
| MySQL | 状态与结果落库 | 任务状态、工具结果、审计记录的持久化 |
| Redis | 会话记忆 + 上下文缓存 | Agent 多轮对话记忆，低延迟读取 |
| Kafka | 异步任务分发 | 任务削峰、工具调用解耦、失败重试 |
| Go 微服务 | 工具链编排 | 每个"工具"是一个 gRPC 服务，独立扩缩容 |
选型的理由能自圆其说，是这个模块的价值所在：
- 记忆为什么用 Redis 不用 MySQL？ Agent 记忆是高频读、短生命周期的上下文，Redis 内存读延迟低；MySQL 存长期结果和审计，各管一段。
- 任务为什么走 Kafka？ 工具调用可能很慢（调外部 API），用 Kafka 削峰解耦、失败可重试，避免同步阻塞。
- 工具为什么是微服务？ 每个工具独立部署、独立扩缩容，gRPC 强类型契约。
架构：一条任务怎么流转
用户 → 网关（限流鉴权）
├─ 写 Redis：session:{task_id} = 上下文
└─ 投 Kafka：task topic = {task_id, 内容}
Worker 消费 Kafka
├─ 读 Redis 上下文
├─ 决策（if-else 模拟）
├─ 调 gRPC 工具服务
├─ 写回 Redis（更新记忆）
└─ 写 MySQL（结果落库）这条链路把前面学的全用上了：网关限流（S5）、Redis 做记忆（S2）、Kafka 削峰解耦（S3）、gRPC 工具服务（S4）、MySQL 持久化（S1）。
面试怎么讲
一句话串起来：
"后端 Agent 决策系统的核心是把'决策'和'执行'拆开：网关接收任务后，用 Kafka 削峰解耦投递；Worker 消费任务时用 Redis 低延迟读会话记忆做决策；决策出的工具调用通过 gRPC 微服务执行，每个工具独立扩缩容；最终结果用 MySQL 持久化、状态可审计。四个中间件各管一段——Redis 管'快'，Kafka 管'稳'，微服务管'分'，MySQL 管'久'。"
被追问"QPS 翻 10 倍怎么办"，可以分层回答：入口网关限流扩容 → Kafka 分区扩容 + Worker 扩容（≤分区数）→ 工具微服务独立扩容 + 熔断降级。
全模块收官
到这里，S1 到 S6 走完了一条核心能力链：从单机的存储引擎、事务、索引，到缓存、消息、微服务，最后在高并发场景题里综合运用，收尾在 Agent Backend 的特色系统。面试时，你既有"逐层深挖"的功底，又有"串成系统"的视野。下一站 S7（工程化底座 K8s），负责把这套系统搬上集群：自动扩缩容、故障自愈、发布不宕机。