第五周：Google ADK、A2A、Strands 与 Pydantic AI
Strands、Pydantic AI、Microsoft Agent Framework、Agno、Mastra——一周过六个框架，真正学到的应该是那条不变的东西，不是六套 API。
这一周走马观花过六个框架。一周学六套 API 是学不完的，也不该学 —— 该学的是它们的共同结构，以及它们在哪些维度上做了不同的选择。
它们都在同一个循环外面包东西
先把第一周那十几行拿回来：模型选工具 → 代码执行 → 结果塞回对话 → 再问模型。
每一个框架都是在这个循环外面包一层，差别只在包了什么、包得多厚：
| 维度 | 问题 |
|---|---|
| 语言 | Python 为主，Mastra 是 TypeScript 原生 |
| 厚薄 | 薄的只给循环和工具，厚的连角色和记忆都替你定义好 |
| 结构化输出 | 靠 Pydantic 这类还是自己解析 |
| 多 agent | 有没有一等公民的编排原语 |
| MCP | 支不支持外接工具协议 |
| 可观测 | trace 是内建的还是要自己接 |
选框架的判据不是「哪个功能多」，是「哪一层我不想自己写」。 而这个答案取决于你的项目，不取决于框架的排行榜。
几个真正的分歧点
厚 vs 薄。 薄框架（只给循环和工具）灵活但要自己补很多；厚框架（连角色、记忆、流程都有主张）上手快但它的意见可能不是你的。这个选择没有对错，只有匹不匹配。
Python vs TypeScript。 这一格常被忽略：如果你的产品是 Node 服务，为了用一个 Python 框架而多养一个运行时，成本不只是部署，还有类型和调试链的割裂。Mastra 这类 TypeScript 原生的存在理由就在这儿。
云厂商绑定。 Strands 背后是 AWS 和 Bedrock，Microsoft Agent Framework 背后是 Azure 那套。它们的价值是和已有基础设施打通，代价是迁移成本。
多框架并行的那个项目
这一周收尾是让六个框架并行去做同一件事，然后看结果。
这个练习的真实价值不是「比出谁最强」—— 那种比较几乎必然不公平（提示词、模型、工具都会有差异）。它的价值是让你看到同一个任务在六种抽象下长什么样，从而分辨出：哪些是这个问题本身固有的，哪些只是某个框架的说法。
而这里有一条方法论上的警告值得记住：有一篇讲 agent 评测的论文提出，长时程任务上 harness 引起的方差可以超过模型引起的方差，甚至让模型排名反转。同理，框架引起的方差也可能盖过任务本身的难度 —— 所以「六个框架跑同一个任务」得出的排名，可信度比看起来低得多。
那到底怎么选
我的判断是按这个顺序问：
- 语言 —— 和你的服务同一个运行时，除非有强理由
- 可观测 —— trace 是不是内建。没有 trace 的框架，出了问题你只能重跑猜
- 结构化输出 —— 有没有一等公民的 schema 支持，这决定了 agent 之间怎么传递信息
- 逃生舱 —— 能不能在必要时绕过框架直接调模型。这一条之所以重要，是因为那十几行循环本来就写得出来：绕过去的成本远比被卡住低。框架最危险的时刻是你需要它没提供的东西
- 最后才是多 agent、MCP 这些
注意「功能多」不在前四位。
边界与代价
六个框架一周过完，等于每个都只碰到皮。 这类巡览课的真实产出是词汇表：以后看到 handoff、crew、graph、workflow 这些词，知道它们大致指什么。别把它当成「我会用这六个框架了」。
框架会过期，循环不会。 这一周里有几个框架可能一年后就没人提了，而第一周那十几行不会变。把时间按这个比例分配。
换框架的成本主要不在代码。 提示词要重调、trace 要重接、团队的直觉要重建。所以「先都试试再定」这个策略在真实项目里往往比「先定一个用深」更贵。