跨产品 Agent 系统的参考架构

30 秒电梯版

五层 agent stack 干净地拆成两块：共享底座（Memory、Agents 框架、Skill 引擎、Rules+Hooks、协议适配器）和产品特定顶层（每个 产品定义自己的 personas、specialists、skills）。底座变成内部 SDK， 每个产品 import 它，加自己的顶层。这一篇展示 Amber、Mumu 和元系统 都坐在同一个底座上——以及到达这里的迁移路径。

为什么这件事重要

五层栈 作为思考工具有用—— 告诉你 agent 系统需要哪些层。但描述一个产品的实现不等于 给你所有 未来产品的架构。

真正可复用的设计把五层拆成两个区域：

┌─────────────────────────────────────────────────┐
│ 产品特定顶层                                       │
│  - Personas（你的视角）                            │
│  - Specialists（你的执行者）                       │
│  - Skills（你的用户可调用操作）                     │
└─────────────────────────────────────────────────┘
                       ↑ import
┌─────────────────────────────────────────────────┐
│ 共享底座（内部 SDK）                                │
│  - Memory 架构（6 子层）                            │
│  - Persona/Specialist 框架                         │
│  - Skill 引擎（LangGraph + LangFuse）              │
│  - Rules + Hooks 机制                              │
│  - 协议适配器（MCP、A2A）                          │
└─────────────────────────────────────────────────┘

底座跨产品相同。顶层产品特定。这一刀把”我建了一个有意思的 agent 系统”变成”我有一个可复用的 agent 平台”。

共享底座，详细

我未来每个 AI 产品都会继承的五件事：

1. Memory 架构

Memory as Foundation 里完整的 6 子层：

• 类型化存储（semantic / episodic / procedural）
• 原子事实抽取（命题粒度检索）
• 带 result 字段的情景记录
• 温度模型（hot / warm / cool / frozen）
• 知识图谱（基于 wikilink 的关系）
• 概念层（用户行为模式）

实现：D1 存结构化、R2 存大文件、KV 做缓存、Vectorize 做 embedding。 作为 MCP server 暴露——任何产品的 agent 都能消费，不需要重新实现。

2. Persona/Specialist 框架

这一刀 作为原语：

• Persona 类：从 markdown 加载，包含反谄媚规则，产出立场
• Specialist 类：从 YAML schema 加载，强制质量门，产出物件

每个产品定义自己的 personas 和 specialists，但用同一个框架定义。

3. Skill 引擎

LangGraph 做 DAG 编排，LangFuse 做 trace，D1 做 checkpoint。包在 一个薄的 SkillRunner 类里，让框架选择藏在稳定接口后面。

4. Rules + Hooks 机制

Rules：路径/事件触发的行为（“写到 ideas/ → 抽取原子事实”）。Hooks： 生命周期绑定（会话开始/结束、部署前后）。实现通过 Cloudflare Workers triggers + Claude Code hooks。机制是共享的，具体规则是产品定义的。

5. 协议适配器

MCP（记忆/工具接口）和 A2A（跨 agent 通信）作为底座的内置能力。 任何用底座的产品免费拿到 MCP-server 和 A2A-task 端点。

产品特定顶层，应用

三个具体例子。

Amber（AI 面试教练）

Personas（教练推理用的视角）：

• coach_persona — 核心教练声音；问”什么会改变我对这个用户准备程度 的判断”
• interviewer_persona — mock interview 模式用；对抗性、怀疑
• realist_persona — reality check；标记教练过于温和的时刻

Specialists（实际工作单元）：

• scoring_specialist — 输入：用户答案 + 技能维度；输出：分数 + 结构 化反馈；质量门：必须 ground 在前序 snapshot 上
• question_generator_specialist — 输出：匹配用户弱点的问题；质量门： 不重复
• debrief_specialist — 输入：mock 笔录；输出：结构化复盘；质量门： 对照目标岗位评分而非过去自己

Skills（LangGraph DAG）：

• start_practice — 诊断弱点 → 生成题 → 评分 → 反馈 → 更新记忆
• run_mock — 赛前 pep talk → 30 分钟面试 → 冷却 → 触发复盘
• give_debrief — 综合笔录 → 识别模式 → 写报告

Rules（自动触发）：

• mock 完成后 → 写带 result 字段的 episodic 记录
• 同一技能上 5 次 partial → 触发模式提炼

Hooks：

• SessionStart → 加载用户当前状态 → 设 tone（encourage / balanced / confront）
• SessionEnd → 写进步快照

底座提供其他一切。Amber 就是”底座 + 这些顶层定义”。

Mumu（视频生成）

Personas（大多不需要——Mumu 是任务驱动）：

• director_persona — 仅在用户要求脚本反馈时触发；不在主视频生成路径

Specialists：

• video_generator_specialist — 输入：脚本 + 风格；输出：视频 URL； 质量门：符合时长规格
• video_reviewer_specialist — 输入：视频 URL；输出：质量分；质量门： 必须查 brand_guide

Skills：

• submit_video_task — 用底座的 A2A 状态做提交+轮询
• review_video — 完成后自动审查

Memory 使用：每次视频生成 episodic 记录。同一根因 5 次失败 → 模式提炼。

Mumu 继承底座的任务生命周期（提交+轮询），加自己两个 specialist， 情景学习免费拿到。

茶会（元系统）

Personas：7 个（架构师 / pm / 务实工程师 / 未来学家 / 增长 / steve-jobs / ux）

Specialists：7 个团队（dev / qa / design / devops / product / marketing / research）

Skills：/sprint、/roundtable、/review

茶会是底座的一等消费者，不是独立系统。同一个 SDK、同一个 MCP server、同一个 skill 引擎。唯一差异是它的顶层 persona 比 specialist 多（因为它的目的是多视角审议），而 Mumu 反过来（任务驱动）。

为什么茶会是验证场

三个理由先迁移茶会（在 Amber、Mumu 采用 SDK 之前）：

1. 最复杂用例。多 persona 圆桌 + 多 phase sprint + 并行 reviewer。 茶会能跑，简单产品能跑。
2. 失败成本最低。仅个人使用——没有付费用户受影响。Amber/Mumu 重写有真实风险。
3. 迁移产生 SDK。把茶会 skills port 到 LangGraph 的过程，强制把 抽象从茶会特定代码里逼出来，进入可复用层。茶会迁移完成后， Amber 和 Mumu 可以 import。

迁移路径（六阶段）

Phase 1 — 骨架（1-2 天）

建 skills-engine/ 目录。装 LangGraph + LangFuse。写 SkillRunner 接口，镜像现有 markdown skill 的输入输出形态。

Phase 2 — /review PoC（半天）

迁移最简单的 skill。4 个并行检查 → 综合。验证：并行执行、state reducer、LangFuse trace。

Phase 3 — /roundtable（2-3 天）

迁移 persona-based skill。验证：persona 定义可以被 LangGraph 节点 host、反谄媚规则在迁移中保留。

Phase 4 — /sprint（1 周）

迁移最复杂的 skill。验证：并行 reviewer、条件重试、checkpoint、 人工审批的 interrupt。

Phase 5 — 稳定化（1-2 周）

新旧并行跑。新版稳定后切换默认。

Phase 6 — 抽 SDK + Amber/Mumu 采用

茶会迁移稳定后，抽象是真实的。把它们提到独立的 @teaparty/agent-sdk 包。Amber 和 Mumu import。从此每个新产品免费拿到架构。

这改变你怎么做产品

之前：

• 每个 AI 产品重新实现 memory、agent loop、重试逻辑
• 每个新产品在产品特定工作之前要花 2-4 周搭建
• 架构学习不在产品间转移

之后：

• 每个产品从底座 SDK 开始
• 产品特定工作只是 personas + specialists + skills
• 架构改进（更好的 trace、更好的 checkpointer）所有产品同时受益

这是**“跑多个 AI 产品”和”跑一个 AI 产品平台”的差别**。

哪里会出错

两件事要看：

1. 过早抽象。不要在茶会迁移稳定前抽 SDK。迁移过程中发现的 抽象和预先猜的抽象是不一样的。

2. SDK 变成上帝类。底座只能装真正共享的东西。如果 Amber 特定 逻辑爬进底座，SDK 就和 Amber 耦合，对 Mumu 没用。残忍地把产品 特定行为推回顶层。

我会怎么在面试里讲这个

“你怎么为多个 AI 产品做架构？“——越来越多公司在问这个问题。

我把架构分成共享底座（memory、agent 框架、skill 引擎、rules+hooks、 协议适配器）和产品特定顶层（personas、specialists、skills）。底座 跨产品相同；顶层是每个产品定义的。这意味着新产品 90% 时间花在让它 不同的事上，不是重建 agent loop。底座随时间变好，每个产品同时受益 ——这是只在你承诺共享层时才有的飞轮。

这个答案表明平台思维，不只是产品思维。大多数候选人按产品思考。 门槛不高。

诚实评估这套架构的局限，见 一个 Agent 架构的诚实评估。