本文章依旧沿用作者推特学习项目。

完整项目源码：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 / 共同关注算法）
• 快速检索「跟我兴趣相同且在社交距离内的人」

---

九、面试叙事要点总结

把这几个核心矛盾讲清楚，任何同类项目都没有这个系统性。

1. Go 实现 ReAct：几乎所有教程是 Python，Go 实现本身是差异化，把 goroutine 并发优势和 Agent 工程难题绑定讲
2. 多 Agent 并发：errgroup 并发 + channel 消息传递，讲清楚为什么 Research/Style 并发而 Writer 串行
3. 四层记忆体系：Redis / MongoDB / ES-kNN / MCP Tool 各司其职，画出来就是亮点
4. 工程挑战：Max Steps 熔断、Tool 失败 Fallback、Redis 断点续跑——这才是 AI 工程深度，不是堆 API 调用