Undo Beats IQ：将 Flamehaven 打造成受治理的 AI 运行时（不是提示应用）

Source: Dev.to

Disclosure: This article was created with the help of AI, and reviewed/verified by the author. #ABotWroteThis

大多数具备自主性的 AI 演示在沙盒中表现出色——但在生产环境中却会崩溃。

生产环境并非“仅仅是提示”。它涉及预算、事故、漂移、审计需求以及不可逆的副作用。

如果你曾经交付过真实系统，你一定见过同样的事后分析句子：

“我们无法复现发生的事情。”

这句话瞬间击碎信任。再加上无声的漂移或失控的成本，“聪明”的代理就会变成负担。

---

单人构建者约束

作为单人构建者，我无法扩展人力。团队通过流程来降低运营风险：评审、批准、运行手册、轮值值班。没有这些奢侈条件时，运行时本身必须表现得像一名有纪律的队友：

• 拒绝无效操作（受政策约束的执行）
• 记录发生的事情（可回放的追踪）
• 及早检测违规（漂移 + 预算检查）
• 优先恢复（回滚作为一等能力）

这不是愿景声明，而是设计约束。

核心原则（硬性规则，而非口号）

1. 禁用 > 捏造 – 若证据或权限不足，正确的输出是：停止。
2. 审计 > 观点 – 没有追踪的声明只是内容。
3. 撤销 > 智商 – 在生产环境中，恢复的价值高于聪明。
4. 预算化智能 – 推理必须在明确的成本/计算预算范围内进行。

这些规则把“代理魔法”转化为可工程化的操作。

架构：把执行视作编译操作

默认的代理模式通常是：

prompt → tool calls → side effects → logs (maybe)

Flamehaven 将控制点提前：

spec → policy → context → execution → trace

最小化流水线

flowchart LR
  A[Intent] --> B[SovDef Spec]
  B --> C[Policy Bind]
  C --> D[WorkingContext + context_hash]
  D --> E[Execution]
  E --> F[TraceVault ledger]
  F --> G[Drift/Budget Controller]
  G --> H[Accept / Abstain / Remediate]

SovDef：像代码一样声明边界

与其说“代理自行决定”，不如提前定义约束：

sovdef:
  objective: "Summarize incident and propose fix"
  tools:
    allowed: ["retriever", "validator", "diff", "ticket_writer"]
    forbidden: ["external_web", "send_email", "delete_data"]
  evidence:
    required: ["source_refs>=2", "validator_pass=true"]
  budgets:
    max_tokens: 6000
    max_cost_usd: 1.20
  rollback:
    required: true

这让代理行为像代码审查一样可审查：权限、证据需求、预算上限以及回滚要求。

证据包（每个发布随附的内容）

每次发布都包括：

• 仓库链接 + 提交哈希
• 最小复现步骤（可复制粘贴运行）
• 一个真实的失败案例 + 修复方案
• 追踪回放演示

示例失败模式：

无限制的工具调用 → 检测到预算超限 → 自动拒绝 + 强制回滚路径

陷阱与局限

• 某些外部变更不可逆（例如发送邮件）。→ 默认禁止，仅在显式政策 + 人工门禁下允许。
• 小样本上的漂移检测噪声大。→ 结合指标 + 阈值 + 升级门禁。
• 追踪/验证会带来额外开销（约 10–20 % token）。→ 仍比凌晨 3 点的事故和不可复现的事后分析便宜得多。

收获

Flamehaven 并不是要成为最自主的运行时。它的目标是最可生存的：审计、预算、漂移以及故障处理。

在 2026 年，差距不在于模型的智商——而在于能够证明发生了什么以及在出错时能够恢复。