想做一个自研项目，不知道合不合理？

标题:大三，想做个C++高性能LLM网关当求职项目，思路推演了一轮，求各位指点下有没有走偏 背景:大三在读，之前做过两个个人项目(epoll+Reactor的RPC框架、类Redis内存KV存 储)，有一段支付后端实习(MySQL/FastAPI)。秋招想投C++后端/基础架构方向，打算把两 个旧项目合并升级成一个有真实场景的项目。 推演过程(这个是和AI讨论的结果)1.最初想做"多智能体消息总线”，研究了一圈发现站不住:Claude Code、Codex、OpenClaw的agent通信都停在应用层，因为真实瓶颈是LLM推理延迟，不是消息传输一-高性能总线是伪需求; Python字典就够了; 2.又想退回到”LLM结果缓存"，发现更站不住:缓存查找相对LLM调用是零头，GPTCache一个 3.最后落在"LLM网关”:网关自己不跑模型，全部工作就是hold万级SSE流式长连接+转发纯I0密集，epoll对口;缓存降级为网关的一个功能(省token是真实需求);主流开源方案one-api是Go、LiteLLM是Python且高并发下有性能争议，有真实的对标对象。 计划的功能边界:SSE流式转发、多上游路由、结果缓存、限流;压测方案是和LiteLLMproxy跑 同样的流式并发，比P99延迟、内存占用、长连接上限。 项目：高性能C++RPC框架(个人项目) 2025.03-2025.06 C++/RPC/epoll/Reactor/线程池/自定义二进制协议 基于Linux epol+Reactor实现非阻塞网络通信层，采用ET模式处理并发连接，完成连接生命周期管理与事件分发。设计RPC请求响应处理链路和自定义二进制协议，协议包含魔数、版本、消息类型、数据长度和消息体，实现消息编解码与请求分 发。 实现固定大小线程池和生产者-消费者任务队列，使用 std:mutex+ std:condition_variable保证并井发安全;使用 shared_ptrlunique_pt 管理连接与任务对象。 类Redis 内存键值存储系统(C++) C++/哈希表/RESP/对象模型/内存管理 2025.09-2025.12 ·内存索引:手写链地址法哈希表，支持冲突处理与动态扩容;设计统一对象模型管理字符串、列表等数据类型的生命周期。 协议解析:实现RESP协议解析与封装，支持字符串、数组和整数等标准格式，可与兼容客户端进行命令交互。 想请教各位: 1.这个选型逻辑有没有明显的漏洞? 2.对本科生来说，难度是否过大? 3.功能边界有没有该砍或该加的?