为什么我们禁止 LLMs 在 Runtime 中运行 — 我们改为怎么做
发布: (2026年2月26日 GMT+8 02:51)
6 分钟阅读
原文: Dev.to
Source: Dev.to
请提供您希望翻译的正文内容，我将按照要求进行简体中文翻译并保留原有的格式。
运行时的 LLM 问题
大多数 AI 后端工具在运行时使用 LLM。每一次 API 调用都会触发模型推理，而每一次响应都是概率性的。当 LLM 在运行时处理你的 API 请求时，你会遇到：
| 问题 | 描述 |
|---|---|
| 非确定性 | 相同请求 → 每次得到不同的响应。 |
| 延迟 | 每个请求 800 ms – 3 s，取决于模型负载。 |
| 成本 | 随流量线性增长的每次推理费用。 |
| 安全性 | 每个端点都有提示注入风险。 |
| 可审计性 | “为什么 API 返回这个结果？” → “模型自行决定。” |
对于原型来说这可以接受，但对于处理支付、预订和用户数据的生产后端而言，这是一种结构性风险。
我们的方案：Design‑time AI
Fascia 在 设计时 独占使用 AI。您用自然语言描述业务，AI 生成 结构化规范（而非代码）。这些规范定义：
- Entities – 具有字段、关系、状态机和不变式的业务对象。
- Tools – 带有类型化输入/输出、触发类型和流程图的 API 端点。
- Policies – 在部署前阻止不安全模式的设计时规则。
在运行时，确定性执行器（使用 Go 编写，在 Cloud Run 上冷启动约 50 ms）读取规范并执行。没有 LLM 推理，也没有变动性。
运行时执行流程
每个 API 端点遵循相同的确定性顺序：
- Validate input – 根据规范中的 JSON Schema 验证输入。
- Authorize – 验证 JWT、检查 RBAC 角色、行级所有权。
- Check policies – 设计时规则的确定性强制执行。
- Start transaction – 显式边界，未启用自动提交。
- Execute flow graph – 由类型节点（Read、Write、Transform、If/Switch）组成的有向无环图。
- Enforce invariants – 在提交前检查业务规则。
- Commit or rollback – 全部提交或全部回滚，绝不出现部分状态。
- Write audit log – 追加式、无条件、记录每一次执行。
- Return typed response – 与规范中的输出 schema 相匹配。
没有捷径。没有“此端点特殊”的说法。刚性正是其特性。
Safety Agent (Design‑time)
Safety Agent 在设计阶段运行并执行：
- 多模型交叉检查 – Claude + GPT‑4（不同模型家族）。
- 流图的静态分析，用于检测不安全模式。
- 风险分类 – 绿（安全），黄（警告），红（阻止）。
- 根据规范不变式生成测试用例。
红色风险会阻止部署，且无法覆盖；必须修复设计。
红色模式示例
| 模式 | 被阻止的原因 |
|---|---|
| 在事务边界内调用支付 | 如果事务回滚，支付无法撤销。 |
UPDATE 未带 WHERE 子句 | 可能影响意外的行。 |
| 写操作未使用事务边界 | 失败时导致状态部分提交。 |
| 硬删除而非软删除 | 不可逆的数据丢失。 |
设计时约束
所有智能必须在设计时的规范中捕获。运行时不能“思考”。这意味着：
- 复杂的条件逻辑 → 以流程图分支的形式建模。
- 自定义业务规则 → 用受限的 Value DSL 表达（不允许任意代码）。
- 外部 API 调用 → 使用带有重试/超时配置的显式节点。
这些约束是有意为之；它们使生产后端 可证明，而非概率性的。
指标比较
| 指标 | 运行时 LLM | 规范驱动 (Fascia) |
|---|---|---|
| 响应时间 | 800 ms – 3 s（可变） | 12 – 50 ms（稳定） |
| 确定性 | 否 | 是 |
| 提示注入风险 | 每个端点 | 零（运行时无提示） |
| 每请求 LLM 成本 | 有 | 零 |
| 审计追踪 | “模型决定” | 规范版本 + 执行日志 |
路线图
我们正在公开构建 Fascia。预发布阶段，单创始人，已有 150 多个 PR。
本系列的下一篇: 风险引擎 – 我们如何将绿色、黄色和红色进行分类。