附录 C · 贯穿式对照实验与实验方法全集
三组跨框架对照实验，以及能让实验结论站得住脚的统计方法
这份附录解决一个问题：你说框架 A 比框架 B 好，凭什么？
大多数技术选型文章给的是主观感受。这份附录教你把感受变成能经受质疑的数据。
三组贯穿式对照实验
第 1 组必做，第 2、3 组二选一，未选者以设计评估文档代替。第 4 组在完成 A10 之后做，它是唯一一组能检验抽象跨语言的实验。
第 1 组：同一个 Tool Calling Agent，四种实现
Native Harness、Pi Agent Core、LangChain Adapter、Mastra Agent 运行同一个 Tool Calling Agent。
第 2 组：同一个审批流程，两种编排
LangGraph 与 Mastra Workflow 运行同一个商品上架加人工审批流程。
第 3 组：统一事件流与统一验收
Native、Pi、LangGraph、Mastra 输出统一事件流，并由同一 Dataset、Policy Engine、Trace Schema 与 Eval Gate 验收。
依赖模块：A5。
第 4 组：同一份 Agent Definition，跨进程跨语言执行
前三组的实现全是 TypeScript 同进程，共用同一个 Tool Runtime。这一组把同一份 AgentDefinition 交给 Agno（Python）执行，量的是语言和进程免费兜住了多少本该由抽象承担的工作。
必须单独量化的四项，前三组的维度表在这里都要重测一遍，另外加：
| 维度 | 怎么测 | 为什么前三组测不出来 |
|---|---|---|
| 取消可靠性 | 取消一百次，统计远端真正中断的比例 | 同进程 AbortSignal 是百分之百的 |
| 事件丢失率 | 对比 AgentOS 侧记录的事件数与你收到的事件数 | 同进程直接构造对象，不会丢 |
| 策略覆盖率 | Policy Gate 实际拦住的工具调用 / 该拦的总数 | 同进程共用 Tool Runtime，这个比例恒等于 1 |
| 数据退出成本 | exit drill 里数据迁移的实际耗时 | 同进程 Adapter 不持有独立的 session 库 |
第三行是这一组的核心。 前三组无论怎么做，策略覆盖率都是 100%，因为工具执行本来就在你手里。这一组会给出一个小于 1 的数字，那个数字才是你抽象的真实边界。
顺带一组可选：三种编排范式
如果 A6 也做了，同一个多 Agent 场景可以再跑一遍显式状态图（LangGraph Subgraph）、代码编排（Mastra Workflow）、模型分派（Agno Team）的对照。重点量化模型分派的不稳定性：同一 Dataset 跑十次，统计分派路径的分布。这个数字对「要不要把编排交给模型」这个决策比任何主观评价都有用。
对照报告必须量化的维度
| 维度 | 怎么测 |
|---|---|
| 实现复杂度 | 代码行数、依赖数、新概念数量 |
| 类型安全 | 有多少处需要 any 或类型断言 |
| 恢复语义 | 服务重启后能否续跑，粒度多细 |
| 事件完整性 | 对照统一 AgentEvent 缺哪些字段 |
| 延迟 | P50 / P95 端到端，以及首 Token |
| 成本 | 单次 Run 平均 Token 与金额 |
| 可观测性 | Trace 能还原到哪一层 |
| 退出成本 | 删除该框架后的报错数与修复耗时；跨进程 Runtime 额外记数据迁移耗时 |
所有框架能力必须能通过 feature flag 关闭，以 Native Harness 作为消融基线。
实验方法全集
对应总课表第 19 周进阶档
程序员基础版第 6 周只做基本固定测试集回归，不含以下方法论。这一节是让你的数字站得住脚的关键，也是面试里被追问时不露怯的底气。
四层评测
- 确定性评测：JSON Schema、字段完整性、Tool 参数、权限、SQL 安全、引用格式
- 语义评测：Relevance、Completeness、Groundedness、Style、Compliance
- Agent 轨迹评测：Tool 选择、Tool 顺序、重复调用、步骤数、是否完成任务
- 业务评测：人工修改率、审批通过率、Listing 发布成功率、平均任务成本、平均完成时间
第 4 层最容易被跳过，也最能说服业务方。人工修改率这一个指标，比十个技术指标更能证明系统好不好用。
统计方法
- 配对样本 + Bootstrap 置信区间，报告 effect size，不只报告平均分
- 至少一次框架消融、一次 Tool / Memory 消融、一次 Prompt 扰动实验
- LLM Judge 有校准集与一致性监控，注意 Multiple Comparison 风险
- 所有对照使用同一输入、工具桩、随机种子策略与版本锁
- Simulation、User Model 与 Environment Stub（模拟真实使用场景）
- Evaluator Agreement、Bias 与 Drift 监控
为什么必须报置信区间
因为 Agent 评测的样本量通常很小（几十到几百条），而模型输出本身有随机性。平均分 82 对比 79，在 50 条样本上很可能是噪声。 报了置信区间之后，你会经常发现自己以为的提升并不显著，这个发现本身就避免了一次错误的技术决策。
配对样本的意思是同一批输入跑两个方案，而不是各跑各的。配对能消掉输入难度的差异，同样样本量下检验力高得多。
动手挑战
用统计方法推翻你自己的一个结论。
翻出你在程序员基础版或前面模块里得出的某个「A 比 B 好」的结论（比如加了 Reranker 效果更好、Mastra 比 Native 代码更少、Multi-Agent 成功率更高），然后：
- 补齐配对样本设计，重跑
- 算 Bootstrap 置信区间和 effect size
- 判断这个结论在统计上是否成立
大概率你会遇到至少一个「其实不显著」的结论。把它诚实地写进报告，并说明需要多大样本量才能检验出这个量级的差异。
这个练习的价值在于：面试官追问「这个提升是显著的吗」时，做过的人和没做过的人，反应完全不一样。
验收标准
- 第 1 组实验完成，四种实现跑同一批用例并产出八个维度的数据
- 第 2 或第 3 组择一完成，未选组提交设计评估文档
- 所有框架能力可通过 feature flag 关闭，Native 为消融基线
- 至少三次消融或扰动实验（框架、Tool / Memory、Prompt）
- 关键结论附置信区间与 effect size，不只报平均分
- LLM Judge 有校准集，一致性有监控数据
面试考点
这份附录对应面试里的数据严谨性考察，是很多技术很强的候选人反而会栽的地方。
- 「这个优化带来多少提升？」：报数字的同时报样本量和置信区间。只报一个百分比的候选人，遇到懂统计的面试官会被追问到答不上来。
- 「你怎么确定是这个改动带来的提升？」：答消融实验和配对样本。这题考的是因果推断意识，能答上来说明你不是碰运气调参。
- 「LLM Judge 靠谱吗？」：答有校准集和一致性监控，同时承认它评不了自己也答不对的题。主动说局限比声称可靠更可信。
- 「你有没有得出过和预期相反的结论？」：这题机会很大。讲你在动手挑战里推翻自己结论的经历，展示的是科学态度而不是技术能力，但恰恰是这个更稀缺。
复习与延伸
本仓库对应源码
packages/eval-kit/src/evaluate.ts：统一EvalCase/EvalResult，四层评测都从这套契约出发packages/contracts/src/eval.ts：评测契约定义- 五个 Adapter 包：对照实验的被测对象
相关页面