FACET的历史与原理

Source: Dev.to

本文档的目的

本文档记录了 FACET 设计决策的历史背景、架构动机和理由。
它的存在是为了解答一个经常出现的未来问题：

为什么 FACET 会被设计成这样，而不是其他方式？

它 不是 变更日志，也 不是 路线图。
预期的受众包括：

• 未来的维护者
• 标准审查员
• 企业架构师
• AI 基础设施的历史学家

1. Pre‑FACET Era (≈ 2018–2022)

1.1 Prompt Engineering as an Anti‑Pattern

Early LLM systems treated prompts as:

• 不透明的字符串
• 可变的运行时产物
• 非正式的约定

As systems grew, prompt engineering evolved into:

• 复制粘贴模板
• 临时重试
• 基于正则的 JSON 提取
• 事后验证

Failures were handled after generation, not prevented.
This era established a false assumption:

LLM unreliability is inherent and unavoidable.

1.2 Structured Output Did Not Solve the Core Problem

Later approaches introduced:

• 在提示中使用 JSON 架构
• 函数/工具调用 API
• 类 Pydantic 的验证器

However:

• 架构仅为建议，未强制执行
• 提供商对约束的解释各不相同
• 仍会产生无效状态
• 验证在模型响应后才进行

The system still allowed invalid intermediate states. → 系统仍然允许出现无效的中间状态。

2. FACET v1.x (2022–2024)：经验教训

FACET v1.x 起源于一个 deterministic prompt templating system。它引入了：

• structured blocks
• conditional logic
• early lens pipelines
• canonical JSON output

2.1 What v1.x Got Right

• Determinism mattered
• Canonical JSON enabled caching and diffing
• Composition beat monolithic prompts

2.2 What v1.x Could Not Solve

• No type system
• No execution model
• No formal notion of invalid state
• No prevention of tool‑call failures

FACET v1.x reduced chaos, but did not eliminate it.

3. 临界点 (2024–2025)

By 2024, several systemic failures became unavoidable:

• multi‑tool agents failing nondeterministically
• provider‑specific tool‑call rules causing silent breakage
• streaming vs. non‑streaming divergence
• context truncation corrupting logic
• retries masking correctness bugs

At scale, these failures were:

• expensive
• non‑reproducible
• impossible to audit

The industry response remained reactive:

Add retries. Add validators. Add guardrails.

This approach did not converge.

4. The Core Insight

FACET v2.0 是基于一个单一的基础认识构建的：

你不能在非确定性合约之上构建可靠的系统。

问题不在于 LLM。
问题在于 缺乏合约层。

Source:

5. FACET v2.0 (2025)：结构性重置

FACET v2.0 的设计初衷是：

• 一个编译器，而非模板引擎
• 一个合约系统，而非辅助库
• 一个执行模型，而非运行时补丁

5.1 确定性作为系统属性

FACET 并不试图让模型确定化。相反：

• 在上游阻止无效状态
• 在执行前强制合约
• 对输出进行规范化

确定性是 通过架构 实现的，而不是通过概率控制。

5.2 规范化 JSON 作为中间表示

FACET 引入了 Canonical JSON 作为其 IR：

• 提供者中立
• 哈希稳定
• 易于差异比较
• 可重放

这将以下环节解耦：

• 编写
• 执行
• 提供者渲染

并防止供应商锁定。

5.3 执行阶段与 R‑DAG

FACET 将执行形式化为五个阶段：

1. 解析
2. 类型检查
3. 响应式计算（R‑DAG）
4. 布局（Token Box Model）
5. 渲染

这消除了：

• 隐式执行顺序
• 隐蔽副作用
• 运行时猜测

5.4 Token Box Model

上下文处理被重新定义为：

• 资源分配问题
• 带有显式优先级
• 确定性的压缩规则

取代了：

• 截断启发式
• “尽力而为”打包
• 静默丢失关键数据

5.5 适配器作为纯翻译器

适配器被有意限制为：

• 不含逻辑
• 不进行推理
• 不执行恢复

从而保持：

• 可审计性
• 可重放性
• 长期稳定性

6. 被设计拒绝的备选方案

FACET 明确拒绝了：

• probabilistic retries
• self‑healing prompts
• adaptive prompt rewriting
• runtime schema repair

这些技术会掩盖失败，而不是消除它。

7. 长期定位

FACET 旨在像以下技术一样长期使用：

• LLVM
• SQL
• JSON Schema

而不是：

• 代理框架
• 供应商 SDK
• 提示工具包

它的目标是保持：

• 乏味
• 严格
• 可预测

数十年之久。

8. 历史归属

FACET — 确定性合约层（自2025起）

作者：Emil Rokossovskiy (rokoss21)

核心理念早于行业共识。当确定性变得紧迫时，架构已经存在。

状态

本文档是 informative。
它不定义新的要求，但解释了这些要求存在的原因。

文档结束。