Agent = Model + Harness：语义也需要一道闸门

当 Agent 的输出最终呈现为界面时，语义层的缺失会让后端所有规矩在前端失效。真正的可信是端到端的——从决策到呈现，每一层都有约束、每一层都可审计。

1. Agent = Model + Harness：约束不是可选项，是必选项

阿里云原生在拆解 Agent 底座时，给了一个等式：

Agent = Model + Harness

Model 是大脑，Harness 是缰绳。没有 Harness 的 Agent 是脱缰的——它能跑，但不知道往哪跑，更不知道什么不能跑。

这比"安全对齐"（Safety Alignment）更诚实。安全对齐试图让模型"自己知道什么该做、什么不该做"，但概率性生成的不确定性决定了，模型不可能 100% 自律。Harness 不依赖模型的自律，它在外部给模型套上一层规矩——你不需要懂为什么，你只需要按规矩执行。

Harness 的核心是约束基建（Constraint Infrastructure）。规矩必须可审计、可进化：

• 可审计：规矩写了什么、什么时候改的、谁改的，有迹可循
• 可进化：业务变了，规矩跟着变，版本化管理，Diff 可见

阿里云在业务逻辑层和数据层做了这件事。但当 Agent 的输出流向界面时，约束链断了。

2. 约束链的断层：后端有规矩，前端没语义

想象一条流水线：

数据层定义了字段语义 → 业务层定义了规则语义 → 策略层定义了模型标签语义
    ↓
Agent 生成了一段文案、一个按钮、一个错误提示
    ↓
用户看到了

数据层有约束：字段 status_code=500 映射到"服务器错误"。业务层有约束："服务器错误"需要值班员立即响应。策略层有约束：模型输出"Critical"时，情绪权重最高。

但到生成界面这一步，约束链断了。Agent 把 status_code=500 渲染成界面时，可能写成"Something went wrong"（语义降级），可能把按钮做成蓝色实心（样式错误），可能把四种错误全部用红色（分级缺失）。

后端的规矩再严密，前端的语义没有约束，等于零。

这不是前端的锅。前端按设计稿实现了，设计稿按规范画了，但规范写在文档里，Agent 生成内容时没读。Agent 按概率生成，每次输出的文案、颜色、样式可能不同——语义在生成过程中漂移了。

约束链止于业务逻辑层，语义层是空白。这是端到端可信的缺口。

3. 端到端可信：从决策到呈现，每一层都有约束

真正的可信不是"后端很严、前端很松"，是从决策到呈现，每一层都有约束、每一层都可审计。

┌─────────────────────────────────────────┐
│  数据层：字段语义约束                      │
│  status_code=500 → "服务器错误"          │
│  可审计：数据血缘、schema 版本             │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│  业务层：规则语义约束                      │
│  "服务器错误" → 值班员立即响应            │
│  可审计：规则引擎版本、变更日志            │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│  策略层：模型标签语义约束                  │
│  "Critical" → 情绪权重最高                │
│  可审计：模型版本、训练数据版本            │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│  语义层：界面生成语义约束 ← 缺口在这里      │
│  "Critical" → 文案必须用"Critical"      │
│  "删除" → 按钮必须是红色空心 + 二次确认   │
│  可审计：YAML 契约版本、Git Diff          │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│  呈现层：用户看到的界面                    │
│  每一层约束的终点，语义一致性的起点       │
└─────────────────────────────────────────┘

语义层的约束基建，补的就是这个缺口。它不做业务逻辑，不做数据清洗，不做模型训练——它做语义映射的约束：

• 数据层的 status_code=500 映射到语义层的 error_severity: fatal
• 业务层的"立即响应"映射到语义层的 user_action: ["刷新页面", "导出历史"]
• 策略层的"Critical"映射到语义层的 color_token: status.critical + motion_token: pulse.red

每一层都有约束，每一层都可审计。语义层不是替代其他层，是在约束链上增加一个节点——让 Agent 的输出在到达用户之前，过一次语义闸口。

4. 语义闸口：在转换链条中插入受控的规范层

《Specification-Based Code-Text-Code Reengineering》在代码层验证了一件事：在转换链条中插入一层受控的规范层，把意思和语法解耦。我在语义层做同样的事。

论文的链条是：源代码 → 中性文本规范 → 目标代码。源代码和目标代码的语法完全不同，但中性文本规范把"意思"固定下来——无论怎么转换，意思不会漂移。

我的链条是：设计意图 → 语义契约 → AI 生成界面。

设计意图是设计师脑子里的"这个场景下不能做什么"——删除账户必须是红色空心、必须二次确认、文案必须说明不可恢复。AI 生成界面时，样式可以变，框架可以变，但语义必须先被规范锁住。

两者都在做同一件事：在生成之前，先把意思固定下来。

论文用自然语言规范来解耦代码语法和代码语义。我用 YAML 语义契约来解耦界面样式和界面语义。样式可以变，但语义必须被规范锁住。Critical 不能变成严重，删除不能变成确认，四种错误不能共用同一种红色。

这个解耦方法在语义层有三个实现环节：

发现意思在哪里可能跑偏——模式库。

不是截图记笔记，是按组件类型做结构化归档。Alert、Button、Modal、Progress——每个组件类型在概率性生成中，语义一致性如何被显化、度量和约束。当 AI 生成的输出与组件手册中的语义定义出现偏差时，记录为模式。

把意思写成机器能懂的规矩——契约库。

规矩不是写在文档里让人读，是写在代码里让机器执行。YAML 契约文件基于组件手册的 Props 定义，叠加语义层。删除按钮的 type 必须是 primary，danger 必须是 true，ghost 必须是 true——这些不是建议，是约束。契约买的不是"生成能力"，是"可审查性"。

证明意思没有被跑偏——验证工具集。

输入一段文案或界面描述，自动判断是否符合契约，给出通过/不通过。不是人眼走查，是机器自动审查；不是"感觉好多了"，是有明确的测试标准和通过准则。单元测试、集成测试、回归测试——产品开发级别的三级标准。

三个环节叠加，形成语义层的 Harness：

• 发现漂移（模式库）→ 锁住漂移（契约库）→ 证明锁住（验证工具集）

意思在生成之前被固定，样式在规范之内被允许漂移。这才是端到端可信——从决策到呈现，每一层都有约束、每一层都可审计。

5. 为什么现在必须做

以前界面是人画的，设计师画什么，前端做什么，语义不会变。现在界面是 Agent 生成的，同一个需求，Agent 每次生成的文案、颜色、样式可能不同——语义一致性从"确定性"变成了"概率性"。

传统设计系统管的是像素级一致性——颜色、字体、间距。但 Agent 生成时，像素对了，语义可能错了：

• Critical 写成 严重——情绪权重降级
• 删除 做成蓝色实心按钮——操作风险隐藏
• 四种错误全部用红色——后果差异消失

这些不是视觉回归能捕获的问题。视觉回归检查"长什么样"，语义闸口检查"意味着什么"。

Agent 时代，约束基建必须从业务逻辑层延伸到语义层。否则后端的规矩再严密，前端的语义没有闸口，用户看到的仍然是"意思跑偏了"的界面。

6. 一句话

Agent = Model + Harness。Harness 不能只套在业务逻辑层，必须延伸到语义层——从决策到呈现，每一层都有约束、每一层都可审计。Schema-As-Code 在语义层建立三道闸门：模式库发现漂移、契约库锁住漂移、验证工具集证明锁住。这才是端到端的可信。