🧬 碰撞后的重新定位

五维度框架是分析 Agent 质量的正确语言。但分析工具 ≠ 交付保证——需要补充维度交互面管理和 Agent 基础设施。

⚖️ 碰撞后重评：五维度的新定位

维度一「架构设计」→ Survives as Analysis Tool, NOT as Delivery Guarantee

• SKILL-as-Function、MCP 标准化、编排层——这些架构概念是 durable 的。它们描述了 Agent 能力应该如何被组织。
• 但 MAST 暴露了一个关键修正：架构设计必须包含「边界定义」——不仅定义 Agent 能做什么，还必须定义 Agent 不能做什么、和谁不交互。没有负空间定义的架构是危险的。
• 修正后的架构设计 = 能力定义 + 边界定义 + 交互协议。三个缺任何一个，MAST 的规约歧义就会出现。

维度二「数据分层」→ Survives, Enhanced

• 四层数据模型（事实/规则/经验/元认知）经受住了碰撞。MAST 的验证缺失问题恰恰说明「事实层」需要独立于 Agent 的验证机制——不是 Agent 自己检查数据是否正确，是外部系统验证。
• 新增要求：事实层必须有版本号和过期时间。Agent A 使用的 Schema v3 和 Agent B 使用的 Schema v2 之间的同步问题，是协调崩溃的主要来源。

维度三「测试体系」→ Survives, Needs Model-Agnostic Anchor

• L1/L2/L3 分层测试是正确的。但反题篇暴露了一个脆弱性：测试结果可能是模型版本的函数。
• 修正：Golden Dataset 不是「精选的正确用例集」——它是「独立于模型版本的验证基准」。它的价值不在于覆盖面，在于稳定性：它必须在 Sonnet 3.7 和 Sonnet 4 下产生相同的 pass/fail 判断。

维度四「稳定性」→ Survives, Needs Cross-Agent Extension

• Reflection/Plan-Solve/Tool-Use 等模式是 durable 的。但它们是为单 Agent 设计的。
• MAST 的协调崩溃说明多 Agent 系统需要一个独立的稳定性层——不是每个 Agent 各自 Reflection，而是一个跨 Agent 的状态一致性校验层。

维度五「产品」→ Survives as North Star, Needs Infrastructure Telemetry

• 混合交互/渐进式信任/成本分离——这些产品原则是 durable 的。
• 但反题篇表明：如果基础设施（隔离/供应/回滚）没搭好，「渐进式信任」会在第一次生产故障后不可逆地归零——信任不是函数，是状态机，一旦进入「不信」状态，退出条件极高。

🕳️ 框架遗漏的两个维度：交互面 + 基础设施

碰撞后，五维度框架需要补充两个不在原框架中的关注面： 关注面一：维度交互面管理。五个维度不是独立的——它们是互相耦合的。每两个维度的交界处都是一个潜在的故障点。新的工程实践是在维度对之间定义同步契约：「架构←→数据」的同步频率、「测试←→稳定性」的模型版本独立性、「产品←→架构」的信任状态机。这些不属于任何单一维度——它们是维度之间的胶水。 关注面二：Agent 基础设施（Infrastructure-as-a-Dimension）。BunnyShell 的四条铁律应该作为框架的第六个维度嵌入——不是可选的最佳实践，是和架构设计、数据分层平级的硬性要求。没有隔离执行环境 → 不能上线。没有 <100ms 环境供应 → 编排的价值被延迟吃掉。没有自愈验证 → 每次故障需要人工介入。没有回滚机制 → 修复成本是回滚成本的 3-5 倍。

🧬 合题公式

_{方法层 · 第三篇 | dialectical position: Synthesis | next: Application}