确定性机制和概率性智能，应该在哪里交界？

做 AI 工具时，我越来越需要区分两种“应该”：模型应该理解人的意思，和系统应该拒绝一个没有权限的动作。前者可以通过上下文、提示和实际评估改善；后者若只能寄希望于模型记得约定，就没有真正形成边界。

Praxis 的环境设计原则已经提到这一点。这篇把问题收窄到我的几个具体工程选择：文件什么时候可以被替换，晚到响应什么时候还能生效，检查结构通过之后究竟还缺什么。它们让我看到，概率性判断和确定性约束需要在明确的位置交接。

安装器不该猜文件是不是可以删

codex-auto 的安装与卸载，需要判断已有内容是否属于自己、是否被用户修改。这里“看起来像我生成的”不够。当前实现用安装清单和内容哈希记录受管文件，遇到未知或修改过的内容就拒绝静默替换、删除，并保留原有内容。

这不是对用户意图的完整理解。哈希只能说明文件与记录是否相同，不能判断改动是否重要、该不该合并。确定性机制负责拦住未经明确处理的覆盖；如何保留、合并或调整，仍需要结合实际意图判断。

如果把这个边界交给一段“卸载前请小心”的提示，调用者变了、上下文丢了，保护就可能不再发生。相反，工具在操作文件的地方检查所有权，可以让不同调用方式共享同一个最低保障。相关测试能检查拒绝行为，却不能替用户选择修改后的内容。

异步结果的有效性，不靠文字说服

Elosay 的实验里，模型负责提出文字候选；请求身份和当前状态负责决定这个结果是否还能进入候选区。取消之后晚到的响应，不能因为内容很好就重新获得写入资格。用户没有采用的候选，也不能偷偷成为已采用历史。

这里最重要的不是某个具体状态名称，而是状态变化发生在控制写入的位置。界面显示“已取消”，后端却仍把结果提交，保护就只完成了一半。同样，重试必须说清楚是重复原快照的请求，还是按新稿重新生成，否则请求身份与人的意图会混淆。

手稿与候选的文章讨论人的编辑权；我在这里得到的工程判断是，必须保证的写入条件，应由程序实际检查。模型可以解释为什么建议采用，但不能自己绕过采用动作。

Schema 能拒绝坏结构，不能认证好判断

StorySprout 的 Critic 实验给了我另一个方向的提醒。程序检查输出字段、状态一致性和引用是否来自原文。它能拒绝不完整的诊断，却不能仅凭这些规则知道故事因果是否连贯。极简探针全部结构有效时，关键人工问题仍然漏检。

如果因为结构校验稳定，就把质量判断一并当成确定性保证，会制造一种错误安全感。结构机制应当保留，但语义部分要由相应的能力证据支撑。没有成立的检查能力，不应继续驱动自动改写或质量放行。

这也是我不想把规则引擎越做越大的原因。把文学问题或沟通里的条件关系穷举成字段，可能让工程表面上更可控，却没有证明它抓住了真正的问题。需要理解的部分仍然需要理解，需要验证的部分仍然需要真实样本。

重试和超时会改变现实后果

另一个具体边界是请求结果未知。调用超时，可能只是客户端没等到回复，不等于服务端没有处理或计费。自动再来一次，可能重复副作用。StorySprout 的实验约定因此区分技术失败与答案不满意，不允许为了更好看的结果反复调用。

预算上限、关闭的实验轮次和已有结果保护，可以由实际执行工具落实；至于下一次实验是否值得做、该改变哪个假设，则仍是判断问题。限制调用次数不会让答案变正确，但能让错误和不确定性留在一个可承受的范围。

删除也是类似的问题。程序能限制受管范围、避免删除未知文件，却不能自动知道现实后果是否可接受。备份是否可用、是否存在其它依赖、用户是否已经授权，仍需要对应事实。确定性保护很重要，但它也有适用范围。

我现在怎么画这条线

我会先问：这里需要的是更好的选择，还是任何情况下都不能被跳过的条件？理解目标、区分解释、选工具和权衡代价，优先交给 Agent；权限、结构契约、请求有效性和删除保护，则尽量复用真实执行边界上的机制。

两边都不能冒充另一边。模型说“我会遵守”不构成强制限制；检查器说“字段合法”也不构成语义可靠。若较轻的现有工具已经足够，我不会为了完整再建一个 Runtime。当前这些选择来自有限项目实践，没有证明存在一条对所有 AI 系统都最优的分界线。

我更愿意保留这种可以逐项检查的交接：系统说明哪些动作被允许，Agent 在其中判断做什么；结果经过必要的结构与状态验证，再由现实证据判断是否达到了目标。每一层负责自己真正能保证的事情，剩下的缺口继续明确摆着。