《TypeScript Agent 开发（Mastra）》写到第 14 篇，收官。前 13 篇从脚手架一路讲到数据分析实战，每篇解决一个具体问题；但真到立项选栈时，没人会按系列顺序重读 13 篇——你面对的永远是一个具体处境：团队写什么语言、Agent 嵌不嵌产品、类型安全是不是刚需、生态依赖压在哪边。参照《上下文工程》第 18 篇、《评测驱动开发》第 14 篇与《本地大模型部署》第 16 篇的手册化收官，本篇不再引入新知识，把 13 篇浓缩成一套可随身查阅的选型手册。
手册七件套：一条主线回顾、一张症状处方速查表、一棵四问决策树、一张 14 篇知识地图、一幅六系列版图，外加两栈共存的心法和三件立刻可做的事。可以通读一遍，更建议把速查表与决策树收进书签，立项时按图索骥。本文按"主线 → 速查 → 决策树 → 地图 → 版图 → 心法 → 行动 → 总结"组织全文。
1、系列主线回顾
先回答总问题：这 13 篇到底在讲什么？一句话——验证"全栈 TS 团队不为 Agent 养第二个技术栈，也能走到生产"这件事是否成立。第 1 篇立论：Python 微服务换来的是两套依赖、两套 CI 和一条类型断裂的序列化边界；其余 12 篇是一条环环相扣的链，全貌如下：
这张图自上而下是搭建顺序，也是排障顺序。前六篇把单 Agent 的五脏配齐——能跑（工具）、能编排（工作流）、能记（记忆）、能连（MCP）、能测（评测）；第 8 篇的工作台把它们变成可观测的整体；第 9 篇是链上的关节：前八篇攒下的体感在那里换成与 LangGraph 的明确判断，后四篇（RAG、部署、Next.js、实战）都是判断之后的工程落地。
跳步是最常见的返工原因。没过第 5 篇的双层标识就做聊天产品，threadId 管理会乱到重写；没在 Studio 里把工具链路调干净就上部署（第 11 篇），线上排障等于闭眼开车；没对过第 9 篇三问就动手迁框架，编排与记忆两层全部重写——第 9 篇第 7 节的迁移账单早就把这笔钱开出来了。
2、症状处方速查表
第一个随身工具解决"出了状况翻哪篇"。以症状为索引、处方为行，出处一列就是该翻的那篇：
| 症状 | 首选处方 | 出处 |
|---|---|---|
| 全栈 TS 团队要上 Agent，不想养第二个栈 | create-mastra 起步，七大件一体化 |
第 1 篇 |
| 模型传参靠肉眼对，改一端忘另一端 | Zod schema 一份两用：校验加类型推导 | 第 3 篇 |
| 流程中途要等人审批，脚本接不上 | Workflow 的 suspend 与 resume |
第 4 篇 |
| Agent 每轮失忆，跨会话一张白纸 | resourceId 加 threadId 配 Memory |
第 5 篇 |
| 同一套工具 Python 与 TS 各写一份 | 工具沉到 MCP server，两边作 client 接 | 第 6 篇 |
| 改了 instructions，不知变好还是变坏 | scorer 随行打分，用例进 vitest | 第 7 篇 |
| 模型为何调那个工具，全靠 console.log 猜 | mastra dev 起 Studio 看 trace |
第 8 篇 |
| LangGraph 还是 Mastra，立项会吵不出结果 | 三问定夺：语言、任务形态、第二栈 | 第 9 篇 |
| RAG 答案不引用原文，检索像抽奖 | 切分、topK、重排三个旋钮逐个拧 | 第 10 篇 |
| Agent 要见真实用户，不知从哪部署起 | mastra build 出 Hono 服务，Docker 托管 |
第 11 篇 |
| 前端接流式输出，消息乱序丢历史 | 只发增量，Memory 管全量，parts 渲染 | 第 12 篇 |
| serverless 冷启动，记忆数据全清零 | Memory 的 storage 外置 Turso 或 Postgres | 第 12 篇 |
用表两条纪律。其一，处方按出处叠加而非单选：失忆加乱序的症状，第 5 篇与第 12 篇要一起翻。其二，改完必须回第 8 篇的工作台验证——凭体感放行的改动，会在两周后以更隐蔽的方式复发。
3、TS 栈决策树
速查表治已病，决策树防未病。立项时按四个问题自上而下走，每一问都在收窄答案，走到底就是结论。四问依次是团队语言、Agent 形态、类型刚需、生态依赖：
三句话划重点。第一，第一问就是淘汰赛：主力语言不是 TS，后面三问都不必问，本系列的价值退化为"知道对面在做什么"。第二，"嵌进产品"是甜区的核心特征——第 12 篇的一个仓库、一次部署、类型从 Zod schema 直穿 React props，是 Python 栈结构性给不了的体验。第三，第四问的答案不是二选一：MCP 协议让两栈共享同一层工具（第 6 篇），编排各守甜区即可。
4、十四篇知识地图
第二个随身工具是全系列索引：每篇一行，第三列写"何时回头查"。用法不是通读，是定位。
| 篇 | 主题 | 何时回头查 |
|---|---|---|
| 1 | Mastra 全景与 TS 栈立论 | 给团队定调、讲为什么时 |
| 2 | 环境搭建与第一个 Agent | 新人入项目、换机配环境时 |
| 3 | Zod 类型化工具 | 写新工具、定输入输出契约时 |
| 4 | Workflows 图式编排 | 流程确定、要挂起审批重试时 |
| 5 | Memory 与存储 | 做多轮对话、跨会话画像时 |
| 6 | MCP 集成 | 接外部工具、跨栈共享工具时 |
| 7 | 内置 evals | 提示词要回归、评测进 CI 时 |
| 8 | Mastra Dev 工作台 | 排查模型决策、调工具链路时 |
| 9 | 与 LangGraph 对比 | 立项选型、框架摇摆时 |
| 10 | RAG in Mastra | 建知识库问答、拧检索旋钮时 |
| 11 | 生产化部署 | 上线、打镜像、守护进程时 |
| 12 | Next.js + Mastra | Agent 长进产品、前端接线时 |
| 13 | 数据分析 Agent 实战 | 要看完整系统怎么拼时 |
| 14 | 本篇选型手册 | 不知道从哪开始、翻哪篇时 |
5、六系列知识版图
收官时把已发的五个系列放回一张图。本站 Agent 工程知识体系至此 92 篇：
| 系列 | 篇数 | 层 | 核心问题 |
|---|---|---|---|
| AI Agent 开发 | 30 | 应用层（Python） | 系统怎么搭：规划、工具、RAG、多 Agent |
| 上下文工程 | 18 | 信息层 | 每步喂给模型什么：窗口账、压缩、缓存 |
| 评测驱动开发 | 14 | 质量层 | 到底好不好：数据集、门禁、监控、红队 |
| 本地大模型部署 | 16 | 基础设施层 | 模型在哪跑：显存、引擎、量化、多机 |
| TypeScript Agent 开发 | 14 | 应用层（TS） | 产品怎么长上 Agent：类型直穿、一体化交付 |
Mastra 系列与四个前作的咬合点在原文里都有接口。工具层沉到 MCP，Python 侧《AI Agent 开发》第 19～21 篇的 Server 与本系列第 6 篇的 client 接的是同一份协议（第 6 篇）；《本地大模型部署》第 13 篇的 OpenAI 兼容层让 Mastra 的 provider 一个字符串指向本地 Ollama 或 vLLM；《评测驱动开发》的方法论在本系列第 7 篇落地成 scorer；Memory 则是《上下文工程》第 11 篇记忆分层的框架代管版。合起来一句判断：应用层定能力，信息层定质量下限，质量层定可信度，基础设施层定成本——TS 这条腿定的是交付速度。
这张版图还差最后两块：《多模态开发实战》12 篇与《后训练入门》8 篇已在排队，拼完这两块，112 篇的知识地图合拢。
6、两栈选择与共存心法
系列最后校正一个容易被带偏的叙事：TS 栈不是 Python 栈的替代，Mastra 也不是 LangGraph 的死刑判决。第 9 篇八个维度比完的结论依然成立——LangGraph 用样板换控制权，Mastra 用约定换速度，两边各有一副付不起的代价。所以心法是按团队画像选栈，而不是按框架榜单选栈：
- 全栈 TS 产品团队：Next.js 加 Node，Agent 是产品能力位——Mastra
- Python 算法团队：数据栈厚、任务像状态机——LangGraph 主场
- 双栈团队：编排各守甜区，工具层沉 MCP 统一
第三种画像正在成为常态。工具的 JSON Schema 只写一份放在 MCP server 里，Python 侧的 LangGraph 与 TS 侧的 Mastra 作为 client 各自接入——框架换血时工具层零成本，这正是第 9 篇迁移账本里"把工具层从账本里划掉"的解法。跨栈成本被压到协议层之后，选型就从"站队"降级成了"分工"。
别问"Python 会不会被 TS 取代"，问"这个团队、这个产品，哪条栈最快交付"。
7、三件立刻可做的事
手册的最后是行动清单。三件事按顺序做，合计一天以内，分别对应第 2 篇、第 9 篇与本篇第 3 节。
**第一件：create-mastra 五分钟起步。**一条命令拉起项目并进入工作台：
npm create mastra@latest hello-agent
cd hello-agent
npx mastra dev
验收标准：浏览器打开 http://localhost:4111，在 Mastra 官方文档所说的 Studio 里选中默认 Agent 对话，右侧能看到完整 trace——注册账号、配置上报一概不存在，此刻你已经在 TS 栈里了。动手前若想核对最新版本，GitHub 仓库 的 changelog 是唯一权威。
**第二件：对照第 9 篇做一次选型决策，半小时。**拿手头真实项目过三问：主力语言是不是 TS；任务形态是数据流主导还是控制流主导；团队养不养得起第二个技术栈。再套本文第 3 节的决策树走一遍，产出三行结论写进立项文档。写不出结论本身就是信号——回第一件事再玩半天，体感比论证快。
**第三件：把现有 TS 项目的 Agent 需求用 Mastra 试做，半天。**挑项目里一个现成函数——查询接口、报表计算都行——包成 Mastra 工具：
import { createTool } from '@mastra/core/tools'
import { z } from 'zod'
import { getRevenue } from '@/lib/report' // 项目里已有的函数
export const revenueTool = createTool({
id: 'get-revenue',
description: '查询指定月份的营收数据',
inputSchema: z.object({ month: z.string() }),
execute: async ({ context }) => getRevenue(context.month),
})
解读：业务函数原样复用，schema 是唯一的新增物，context.month 由 Zod 推导为 string。把它挂到 Agent 的 tools 里，进 Studio 用自然语言问一句"上个月营收多少"，看模型正确传参、调通、组织回答。这一步做完，第 9 篇的一切对比都有了第一手体感，TS 栈适不适合你的团队，答案自己会浮出来。
8、总结
14 篇收束成一句话：TS 栈成立（第 1 篇）；工具的类型货币是 Zod（第 3 篇）；确定性流程交给 Workflow、记忆交给 Memory、外部世界交给 MCP（第 4～6 篇）；评测与调试台白拿（第 7、8 篇）；选型三问定生死（第 9 篇）；RAG、部署、Next.js、实战把链走完（第 10～13 篇）。两栈心法只有一句：按团队画像选，用 MCP 让它们共存。速查表、决策树、知识地图——这三张图就是整个系列留给你的行囊。
本系列之后，版图只剩最后两块：先上《多模态开发实战》12 篇——视觉理解、图像生成、语音双向、实时对话，给 Agent 装上眼睛与嘴巴；随后《后训练入门》8 篇——SFT、LoRA、DPO，把模型本身变成可调的变量。对于跟着走完全程的读者，建议今天就把第 7 节的第一件事做掉——npx mastra dev 回车的那一刻，你已经站在 TS 栈上了。
