本文章依旧沿用作者推特学习项目。
完整项目源码：https://github.com/twitter-learn-cloud-development/backend-services
该篇文章单独讲开发规划。
🚀 推特 AI Agent 项目架构与演进规划
📌 项目定位
以 Go 高并发为底座、MCP 为工具协议、ReAct 为决策引擎的多 Agent 推文运营平台——Research / Style / Writer 三智能体并发协作，配合四层记忆体系与 Hybrid RAG 召回。
一、核心决策与定位
开发策略：不另起炉灶，在现有推特 Go 微服务架构上扩展，新建独立微服务agent-service，与已有的user/tweet等服务平级。
交互协议：采用 MCP（Model Context Protocol）行业标准，将发推、查询等操作封装成 AI 可调用的 Tools。
核心差异化：用 Go 实现 ReAct 循环与多 Agent 并发，几乎所有同类项目都是 Python LangGraph，Go 实现本身即是降维打击。
二、Agent 核心双模型场景
场景一：智能查询与推荐（Search & Recommend Agent）
业务表现：用户输入「我最近迷上了健身，推荐三个博主」或「帮我找找最近很火的 XX 事件」。
底层逻辑：
- AI 解析用户意图，提取语义标签（如：健身）
- 结合用户画像，调用后端 ES 检索工具
- 将返回的博主列表、推文进行提炼，返回灵活的 UI 数据结构供前端渲染（"不定式" UI）
场景二：内容创作与执行（Write & Execute Agent）
业务表现：用户发送图片、思路碎片，AI 润色出多版推文供选择，并直接完成发布。
底层逻辑：
- 基于多模态大模型理解图片和文本输入
- 利用 ReAct 循环（思考 → 找工具 → 执行 → 确认）驱动整个流程
- 用户确认后，Agent 调用 MCP 接口（
twitter-mcp-server）自动完成发推，实现全自动闭环
三、ReAct 决策引擎（核心工程亮点）
为什么这是亮点：当前大多数 Agent 项目是「用户问 → 单次 RAG → 返回」，本质是带 LLM 的搜索系统，与 LangChain 教程无异。ReAct 让 Agent 真正自主规划多步任务。
示例流程：用户说「帮我分析最近科技圈热点然后用我的风格写一篇推文」→ Agent 自主规划：
Step 1: 调 ES 搜科技热词 Step 2: 搜对应推文 & 目标作者风格样本 Step 3: 调写作 Tool 生成草稿 Step 4: 调发布 Tool（可选，用户确认后）
核心工程难题（面试叙事点）：
| 问题 | 解决方案 |
|---|---|
| 防止无限循环 | Max Steps 上限 + 超时熔断（context deadline） |
| Tool 调用失败 | Retry 策略 + Fallback 降级处理 |
| 中间状态持久化 | 每步状态写入 Redis，支持断点续跑 |
| 结构体定义 | ThoughtActionObservation三段式结构体 |
四、多 Agent 并发协作架构
为什么升级：单个 LLM 调用的「协作写推文」在面试官眼里一眼看穿，真正的多 Agent 才有工程深度。
架构设计：
用户请求 ↓ Orchestrator Agent（Go 主协程，负责调度与故障隔离） ├── Research Agent → ES 检索热点推文（并发） ├── Style Agent → 分析目标作者写作风格（并发） └── Writer Agent → 综合输入，生成草稿 + Self-Reflection（串行，依赖前两者）
关键工程决策（面试叙事点）：
| 问题 | 解决方案 |
|---|---|
| 并发 vs 串行 | Research + Style 用errgroup并发；Writer 依赖两者结果串行等待 |
| Agent 间消息传递 | 内存 channel（单机）/ Redis 消息队列（分布式扩展） |
| 故障隔离 | 某个 sub-agent 超时不能卡死主流程，Orchestrator 设置独立 deadline |
| Go 优势体现 | 并发模型天然比 Python async/await 更优雅，goroutine + channel 是最佳载体 |
五、四层记忆体系
这是与所有 LangChain 同类项目拉开差距的核心系统性亮点。
| 记忆类型 | 实现方案 | 项目对应场景 |
|---|---|---|
| 短期记忆 | Redis Session 滑动窗口截断 | 单次对话上下文历史 |
| 长期记忆 | MongoDB 存对话关键事件摘要 | 用户偏好、历史操作记录 |
| 语义记忆 | ES kNN 向量检索 | 相似推文 / 作者风格样本库 |
| 程序性记忆 | 固化为 MCP Tool | 发推、搜索等标准化技能 |
六、基础设施升级（用户画像 & 数据流）
① 搜索引擎升级（ES + Canal）
- 痛点：MySQL
LIKE查询慢且无语义理解能力 - 方案：引入 Elasticsearch，配置 IK 中文分词器；使用 Canal 监听 MySQL binlog，实现推文数据实时增量同步
- 在 Agent 中的作用：作为 RAG（检索增强生成）的数据源，为 Prompt 提供精准上下文；同时存储 kNN 向量用于语义推荐
② 用户画像分层存储
| 存储层 | 存储内容 | 技术选型理由 |
|---|---|---|
| MySQL | 静态画像（性别、地区、注册时间等基础信息） | 结构固定、变更少，关系型存储最合适 |
| MongoDB | Agent 历史对话记录 | 对话记录是嵌套结构，Schema 自由，天然适合文档型存储，省去 JSON 字段的拆解成本 |
| Redis | 近期活跃行为 + 搜索词（ZSet + TTL） | 高频读写，TTL 自动过期，做短期记忆 |
| Elasticsearch | 用户偏好向量（kNN 字段） | 语义级推荐匹配 |
③ RAG 增强召回（Hybrid RAG）
- ES 全文检索（BM25）+ kNN 向量检索双路并行
- 在 Agent 中将检索结果封装入 Prompt，提供精准上下文
- RAG 前置加 Query Rewriting（调小模型扩写用户 Query，提升召回质量）
七、社交图谱与进阶推荐（Neo4j 引入计划）
定位：第二阶段目标，解决复杂关系网查询。
为什么用 Neo4j：MySQL 找「朋友的朋友」（二度/三度人脉）需要多层 JOIN，性能极差。Neo4j 采用 Index-Free Adjacency（无索引邻接）底层设计，通过指针直连沿关系查询，速度是 MySQL 的指数级倍数。
应用场景：
- 维护用户间复杂社交网络（节点：用户、话题；边：关注、点赞）
- 实现基于关系的精准好友推荐（PersonalRank / 共同关注算法）
- 快速检索「跟我兴趣相同且在社交距离内的人」
九、面试叙事要点总结
把这几个核心矛盾讲清楚，任何同类项目都没有这个系统性。
- Go 实现 ReAct：几乎所有教程是 Python，Go 实现本身是差异化，把 goroutine 并发优势和 Agent 工程难题绑定讲
- 多 Agent 并发：errgroup 并发 + channel 消息传递，讲清楚为什么 Research/Style 并发而 Writer 串行
- 四层记忆体系：Redis / MongoDB / ES-kNN / MCP Tool 各司其职，画出来就是亮点
- 工程挑战：Max Steps 熔断、Tool 失败 Fallback、Redis 断点续跑——这才是 AI 工程深度，不是堆 API 调用
