A5 · Runtime 平台化与 framework exit drill

本模块产出：五 Runtime 全集、Adapter Capability Matrix、一次完整 exit drill · 对应总课表：第 17 周全集

学前自测

1. Control Plane 和 Data Plane 分别管什么？为什么要分开？

Control Plane 管定义与策略：Agent Definition、版本、Policy、配额、路由规则。Data Plane 管执行：真正跑 Agent、调模型、执行工具。分开的理由是两者的可用性要求和伸缩特征完全不同。Control Plane 挂了不应该影响正在跑的任务，Data Plane 需要按负载水平扩展而 Control Plane 不需要。

2. 五个 Runtime 的能力不一样，平台怎么处理这种差异？

用 Capability Matrix 显式声明每个 Adapter 支持什么，请求进来先做能力协商。关键原则是能力不足要显式失败，不能静默改变语义。比如某个 Adapter 不支持中途取消，就必须在接受请求时拒绝，而不是接受了然后取消时假装成功。静默降级是平台最难排查的一类问题。

3. 什么是 framework exit drill？为什么要定期演练而不是等真要换的时候再说？

模拟某个框架必须被移除的场景（停止维护、License 变更、严重漏洞、性能不达标），实际执行一次移除并验证平台仍然运转。定期演练的理由和消防演习一样：真到那天再发现抽象漏了，代价是几个月的迁移工作。演练把这个风险提前暴露成几天的修复工作。

4. 多租户场景下，一个租户的 Agent 疯狂调用会怎么影响其他租户？怎么防？

不防的话会挤占共享的模型配额、连接池、Worker 槽位，形成噪声邻居。防的手段是租户级配额加并发上限加公平调度。注意光有配额不够，还要有公平性：一个租户即使没超配额，也不该在突发时把队列占满让其他租户饿死。

学习目标

从 Agent 平台最小实现升级到五 Runtime 全集，并建立框架依赖的退出能力。

这个模块是整个程序员进阶版最能体现 Staff 级视野的地方：你交付的不是一个能跑的系统，而是一个不被任何单一框架绑架的平台。

课程内容

程序员基础版已完成 Agent Registry / Run API 的最小实现（Native / Mastra 两种 Runtime）。程序员进阶版补齐：

1. Pi、LangGraph、LangChain Runtime Adapter，形成五类 Adapter 全集
2. Control Plane 与 Data Plane 分离
3. Adapter Capability Matrix 与版本协商
4. Tenant Quota、Concurrency、Rate Limit 与 Fairness 的平台化策略
5. Feature Flag、fallback 与 framework exit drill

平台分层

实施任务

• 把 A1 的 pi-adapter、A3 的 langgraph-adapter、A4 的 langchain-adapter 全部注册进 Agent Registry
• 建立 Capability Matrix：每个 Adapter 声明支持的能力（流式、取消、审批、checkpoint、事件完整度）
• 拆分 Control Plane 与 Data Plane，验证 Control Plane 重启不影响在跑任务
• 实现租户配额、并发上限与公平调度
• 每个框架 Adapter 挂 Feature Flag，可独立关闭并 fallback 到 Native
• 执行一次完整的 framework exit drill

动手挑战

抽签决定砍掉哪个框架，然后当天砍掉它。

这是 exit drill 的正式做法，关键在于不能提前准备：把五个 Runtime 写在纸条上随机抽一个（Native 除外，它是基线），然后限时一天完成：

1. 关掉这个 Adapter 的 Feature Flag，跑全量测试，记录失败数
2. 物理删除这个 Adapter 包和依赖，再跑一遍
3. 检查四件事是否仍然完好：核心 Agent Definition、Dataset、Trace、Web Console UI
4. 用 Native 或其他 Adapter 承接被砍框架原本负责的场景，验证业务不中断
5. 记录总耗时、改动文件数、以及无法承接的能力缺口

第 5 条最有价值。有些能力就是没法承接，比如砍掉 LangGraph 之后 time travel 调试能力就没了。诚实记录这些缺口，它们是「这个依赖的真实价值」的量化答案，比任何主观评价都可信。

Agent OS 里程碑

Agent Registry 支持五类 Runtime，Control / Data Plane 分离，Capability Matrix 可查询。

验收标准

• 可选择 Native / Pi / LangChain / LangGraph / Mastra 五种 Runtime
• Adapter 能力不足时显式失败，不能静默改变语义
• 关闭任一框架 Adapter 后，核心 Agent Definition、Dataset、Trace 与 UI 无需迁移
• 完成一次 Mastra 或 LangGraph 的 framework exit drill

学后自测

1. 五个 Adapter 的 Capability Matrix 里，差异最大的是哪一项？

通常是事件完整度和取消语义。有的 Adapter 能给出细到工具参数级的事件，有的只有开始和结束。这张矩阵本身就是一份很有分量的技术资料，因为它是实测出来的而不是抄文档的。

2. Control Plane 挂了十分钟，正在跑的一千个任务会怎样？

正确答案是继续跑完。已经启动的任务所需的定义和策略应该在启动时就快照到 Data Plane，不依赖 Control Plane 在线。做不到这一点说明两个平面没真正分开，只是代码分了目录。

3. exit drill 里哪个能力缺口最难承接？你打算怎么办？

答案因人而异，但必须有答案，而且要有应对方案：接受缺口、自己实现、还是换另一个框架补。「没想过」是这题唯一的错误答案，因为它意味着你的依赖风险是不可控的。

本模块作业

1. Agent Registry 扩展：五类 Runtime Adapter 注册与选择
2. docs/capability-matrix.md：五个 Adapter 的实测能力矩阵
3. Control / Data Plane 分离，含 Control Plane 停机测试
4. 租户配额、并发与公平调度实现
5. docs/exit-drill-report.md：抽签演练报告，含耗时、改动面、能力缺口清单

面试考点

这个模块对应面试里的平台架构与技术风险管理，是 Staff 级面试的核心区。

• 「你怎么保证不被某个框架绑架？」：这是这个模块的招牌题。答 Adapter 加 Capability Matrix 加定期 exit drill，然后拿抽签演练的数据说话。绝大多数候选人只能答「我们做了抽象层」，你能报出实测耗时和能力缺口。
• 「Control Plane 和 Data Plane 为什么要分？」：答可用性要求和伸缩特征不同，举 Control Plane 停机十分钟在跑任务不受影响的例子。
• 「多租户怎么防噪声邻居？」：答配额加并发上限加公平调度三层，强调光有配额不够还要有公平性。这题从传统平台工程迁移过来，答得好说明你有基础设施背景。
• 「不同框架能力不一样怎么办？」：答显式失败不静默降级。展开讲静默降级为什么是平台最难排查的问题类型。
• 「你觉得这套多 Runtime 架构值得吗？」：诚实答。适合的场景是平台服务多个团队、各团队技术栈不统一；不适合的是单团队单产品，那种情况下五个 Adapter 就是过度设计。能主动划边界，比坚持自己的方案更能拿分。

复习与延伸

本仓库对应源码

• packages/contracts/src/agent.ts：AgentDefinition，Runtime 无关的核心类型
• packages/harness-native/、packages/harness-pi/、packages/adapter-langchain/、packages/adapter-langgraph/、packages/adapter-mastra/：五个 Adapter 的起点，注意它们都只依赖 @agent-os/contracts
• packages/tool-runtime/：五个 Runtime 共用的工具执行层，这是能跨 Runtime 统一策略的原因

相关模块

• A1、A3、A4 提供三个 Adapter
• 附录 C 的贯穿式对照实验在这五个 Runtime 上运行

下一步：A6 · Multi-Agent 设计