开发者热议：AI能否取代API？合同保障与概率不确定性的博弈

5 月 2 日，Naval 在 X 上发布了一条简短的观点：

「AI 将取代 UI 和 API。」

这一说法听起来颇具前瞻性，然而开发者 Jake（@JustJake）却对此表示强烈反对，他在原帖中回复道：

「这观点完全错误且极其危险。」

▲ Jake 的回怼引起了广泛关注，收获近 5000 次点赞和 22 万次浏览，并引发了 201 条评论。

Jake 提出了他的核心论点：

「API 的核心在于确保每一次操作都执行完全相同的任务。」

「尽管 AI 在许多方面表现出色，但可复现性并非其强项。」

这条推文获得了近 5000 个点赞和超过 22 万的浏览量，评论区也因此热闹非凡。

许多人将 API 理解为「指示机器如何执行任务的接口」，认为既然 AI 也能处理输入和输出，那么 API 自然会被取代。

然而，这种理解存在根本性的偏差。

在实际的生产环境中，API 实际上扮演着一套完整的工程合同的角色：

正如一位开发者在评论区中精准地指出：

「API 的本质在于其契约性。一旦被 AI 取代，虽然调用形式可能保留，但其保障性将荡然无存。」

另一位开发者则更为直接地表达：

「API 的设计初衷就是确定性的。相同的输入，必然产生相同的输出，且每一次都是如此。」

或许有人会提出疑问：通过设置 temperature 为 0 并固定 seed，不就能实现稳定性吗？

然而，OpenAI 官方文档对此给出了明确的否定答案。

▲ OpenAI 官方 Cookbook 探讨了如何使用 seed 参数来提升输出的一致性。

OpenAI Cookbook 中明确写道：

「Chat Completions 和 Completions API 默认情况下是非确定性的。」

即使设置了 seed、锁定了参数，甚至检查了 system_fingerprint，OpenAI 仍然强调：

「确定性无法得到绝对保证。」

请注意其措辞——即便是「大部分一致」（mostly identical）也仅是「尽力而为」（best effort）。一旦后端配置发生变动或模型进行更新，之前所依赖的「稳定性」可能瞬间消失。

ML6 的技术分析进一步阐述了其中的原因：在采样机制中，即使 temperature 设置为 0，等概率 token 之间的随机选择、数值精度的细微差异，以及后端基础设施的变动，都可能导致无法消除的输出漂移。

▲ ML6 的技术文章指出，即使 temperature=0 也无法保证完全的确定性。

他们的结论非常明确：

「缺乏种子控制，就意味着没有确定性。」

设想一下支付系统：同一个请求，可能一会儿扣款成功，一会儿失败，一会儿支付金额的解释也不同。这如何向用户交代？

再看身份鉴权：如果权限边界依赖于「模型大概率的正确理解」，一旦概率稍有偏差，就可能导致数据泄露。

对于数据库写操作：如果写入行为缺乏幂等性、回滚机制或审计功能，一旦出现问题，责任的划分将变得异常困难。

在运维事故响应中：如果让 AI agent 执行 runbook，它可能会「创造性地」跳过关键步骤，导致 P2 级别的事故瞬间升级为 P1。

开发者 Jai Jalan 在评论区一针见血地指出：在事件响应中，runbook 本质上也是一种 API——而一个会「创造性跳步」的 agent，完全有能力将 P2 事故升级为 P1。

Brock Herion 补充道：在银行、金融、医疗、法律等行业，可复现性和稳定行为是基本要求，不容妥协。

Jake 在后续的补充帖子中清晰地阐述了他的立场——他并非反对 AI 在软件系统中的应用：

「AI 可以用于迭代和演化离散的逻辑（即代码）。」

「然而，将不一致性直接暴露给终端用户，只会给所有人都带来不便和痛苦。」

评论区中 Kaps 的观点显得更为均衡：API 作为一种确定性的契约将继续存在，而 AI 更可能取代的是围绕 API 的文档、SDK 以及集成所需的“胶水代码”；最终的接口仍将返回确定的 JSON 数据。

Tushar Khairnar 的补充也值得关注：AI 之所以真正变得实用，恰恰是因为 API 世界为其提供了结构化的输出接口——例如 JSON 模式（JSON mode）这类约束能力的出现，使得许多应用得以从「猫鼠游戏」式的不可靠走向可用。

AI 的能力越强大，就越需要确定性的边界来承接其输出。

这场争论仍在继续，但工程界早已不再仅仅停留在口头讨论。

Hacker News 上出现了关于确定性 LLM 输出和可复现 agent 系统的深入探讨。

▲ Hacker News 上的讨论聚焦于为什么从 LLM 获取确定性输出近乎不可能。

▲ Hacker News 另一篇讨论则关注如何构建具有严格确定性保证的可复现 LLM agent。

在 GitHub 上，一些开发者已经将这些理念付诸实践。一个名为 deterministic-agent-system 的项目，集成了 bounded tool loops、trace hash、replay bundle、capability-driven selection 等机制，并将其打包成了一个可运行的框架。

▲ GitHub 上的 deterministic-agent-system 项目，提供了一个可审计、可回放、可约束的 agent 执行系统。

该项目的 README 中有一句话尤为有力：

「集成边界是真实存在的。」

这个项目表明，如果 AI 要真正融入系统边界，其途径绝不是直接用聊天输出去硬碰硬。它必须首先将自身封装成一种新型的执行系统，具备 trace、可回放、可约束和可验证的能力。

公平地说，另一方也存在合理的观点。

HN 上有评论指出：如果使用的是本地模型、固定的权重和环境，并且没有人在后台进行偷偷的更新，那么相同的输入确实可以获得更稳定的输出。问题的很大一部分源于 SaaS 提供商不断更新后端服务——这与「模型本身永远无法稳定」是两个不同的概念。

还有人提出了一个更深层次的问题：确定性（determinism）并不等同于正确性（correctness）。一个系统即使每次都输出完全相同的结果，也可能是在稳定地犯错。因此，将「可复现性」视为唯一的衡量标准，同样可能产生误导。

这两点反驳都有其道理。但从系统工程的角度来看，可复现性仍然是正确性的基础——没有稳定的行为，就无法有效地复现 bug、进行回归测试、实施审计和划分责任。

Naval 那句「AI 替代 API」在公众语境中听起来像是高瞻远瞩。但在开发者听来，它的含义却是：用概率分布来接管系统的合同边界。

这就是近 5000 人点赞支持 Jake 的根本原因。

AI 能够替代的，是用户界面、使用说明以及连接不同组件的“胶水层”。而短期内难以替代的，是合同边界——那些要求可复现、可回放、可审计的系统核心。

未来如果 AI 真的能够继续深入技术栈，其第一步必然是先将自身包裹在更严格的执行协议之中——拥有 trace、约束、回放和验证能力。直接取代 API？这条路行不通。

正如那个 GitHub 项目的 README 所言：

集成边界是真实存在的，不是一句口号就能抹平的。

— END —