过去几年，整个 AI 行业似乎都在追逐同一个目标：AGI。
模型参数越来越大，推理时间越来越长，Benchmark 分数不断刷新。每隔几个月，我们都会听到类似的说法：
AGI 可能已经出现了。 下一个模型将彻底改变世界。 超级智能可能只差最后一步。
但一个更值得追问的问题是：
如果今天的 AI 已经如此聪明，为什么现实世界并没有发生与之匹配的变化？
为什么大多数企业仍然没有实现真正的自动化？为什么绝大多数 AI 产品仍然只是一个聊天窗口？为什么很多 Agent 做完演示很惊艳，一进入生产环境就问题百出？
TypeSafe AI 最近发布了一篇题为《Composable AI: Build Prod, Not God》的宣言，提出了一个非常值得讨论的判断：
今天 AI 的瓶颈，已经不再是智力不够，而是这些智力太难被可靠地使用。
我们可能已经拥有了足够强的通用智能
TypeSafe AI 认为，与其继续争论 AGI 到底什么时候到来，不如承认一个现实：
今天的大模型已经具备了创造巨大经济价值所需要的许多能力。
它们掌握了海量知识，能够跨领域推理，可以写代码、分析文件、理解合同、处理数据，也能完成很多几年前还被认为只有人类才能完成的任务。
问题是，这些能力并没有大规模转化成经济生产力。
模型很聪明，但并不稳定。
它可以在 99 次任务中表现良好，却在第 100 次任务里突然误解要求；它可以给出一份看起来非常专业的答案，却可能引用不存在的事实；它可以操作工具，也可能点错按钮、删除错误的文件，或者把不应该发送的数据发送出去。
于是，我们得到了一种很奇怪的技术：
它看起来拥有通用智能，却很难像普通软件一样被稳定调用。
因此，真正阻碍 AI 普及的可能不是模型的智力，而是自动化能力。
AI 已经会思考，但我们还不知道如何放心地把工作交给它。
今天的 AI，就像早期的“无马马车”
汽车刚刚出现时，人们并没有立即重新设计交通工具。
早期汽车仍然保留着马车的外形：高高的座椅、马车式弹簧，甚至还保留了原本用来插马鞭的位置。人们只是把马拿掉，换上了一台发动机。
这就是所谓的“无马马车”。
新技术刚出现时，人们往往会把它塞进旧产品的形状里，而不是从新技术本身出发，重新思考产品应该是什么样子。
今天的 AI 很可能也处于这个阶段。
大模型被训练成一个有礼貌、善于表达、乐于帮助人的助手。它等待用户输入问题，再用自然语言给出回答。
如果模型的另一端永远坐着一个人，这样的设计当然合理。
但它也产生了一个直接结果：
AI 仍然需要人类不断参与。
人需要给它下达指令、检查答案、纠正错误，然后决定下一步做什么。原本应该自动运行的系统，最后变成了一个需要持续监督的聊天工具。
这很可能只是 AI 时代的“无马马车”。
真正属于机器的 AI，并不一定需要一直说话，也不一定需要表现得像人。它更可能是软件系统内部的一种基础能力，在后台持续运行，在需要理解语义、判断意图或者进行模糊决策时被调用。
软件需要的不是一个“数字人”，而是一种新的基础能力
传统软件擅长精确计算。
只要输入和规则确定，同一段代码通常会得到相同的结果。每一个条件分支都可以检查，每一次状态变化都可以追踪。
但是，传统软件不擅长处理语义。
例如：
-
这封邮件是否真的表达了投诉？ -
这份合同里有没有隐藏的责任风险？ -
这个用户的操作是否符合他的真实意图？ -
这段代码修改是否可能破坏现有功能？ -
这个 Agent 即将执行的动作是否超出了授权范围？
过去，这些问题很难用一组明确的 if/else 写出来。
大模型带来的真正机会，是让软件第一次拥有基于常识、上下文和意图进行判断的能力。
代码继续负责自己最擅长的精确计算，大模型则负责语义理解和模糊判断。
这样一来，AI 就不再只是一个独立的聊天机器人，而会成为一种新的软件原语：
任何程序都可以在需要时调用一次“智能判断”。
计算机过去通过 0 和 1 进行分支。未来的软件还可以根据语义、常识和意图进行分支。
这才是机器原生的 AI 形态。
AI 需要像数据库查询一样被调用
数据库刚出现时同样非常强大，但使用起来复杂，而且不同系统之间缺少统一的操作方式。
SQL 的出现改变了这一切。
开发者不再需要关心数据具体存储在哪里、磁盘如何组织、底层索引怎样工作，只需要发出一个稳定、清晰、可验证的查询。
数据库因此从一种专业技术，变成了现代软件最重要的基础设施之一。
TypeSafe AI 认为，今天的 AI 很像 SQL 出现之前的数据库：
能力非常强，但每一次使用几乎都需要重新设计。
每个团队都在自己编写 Prompt、设计工作流、处理结构化输出、增加重试机制、检查模型幻觉，然后想办法让模型接入现有系统。
如果一次智能判断能够像数据库查询一样可靠，开发者就可以把它放进更大的软件系统里，并在它的基础上继续构建其他能力。
例如，一个系统可以先判断用户意图，再检查权限，然后制定执行计划，最后决定是否调用外部工具。
每一层只完成一个范围清晰的智能任务。多个小能力可以像普通软件模块一样被组合，最后形成复杂的 Agent 系统。
这就是所谓的 Composable AI——可组合的 AI。
安全不是最后增加的功能，而是可组合的前提
这里有一个非常重要的观点：
只有可靠的能力，才有可能被组合。
如果一个组件偶尔出错，开发者或许还能在旁边盯着它。
但如果这个组件被埋在系统第五层，作为许多上层服务共同依赖的基础能力，那么偶尔出错就会变成系统性风险。
这也是为什么传统软件需要类型系统、权限控制、自动化测试、异常处理、监控和审计。
不是因为这些东西能让软件变得更聪明，而是因为它们能让软件变得可预测、可验证、可维护。
AI 也需要类似的工程基础。
一个智能组件必须能够被：
-
检查； -
测试； -
约束； -
监控； -
授权； -
审计； -
在出错时阻断或者回滚。
开发者只有知道一个组件的能力边界，才能放心地在它上面继续构建。
因此，AI 安全并不只是防止未来的超级智能毁灭人类，也不只是给模型增加一层内容审核。
对于正在进入生产环境的 AI 来说，安全首先意味着：
让一次智能判断能够被放心地交给机器执行。
安全不是 AI 应用完成后再加上的补丁，而是 AI 能够成为基础设施的前提。
复杂智能不一定需要一个无所不能的模型
当前 AI 行业有一种很强的倾向：希望通过一个越来越大的模型解决所有问题。
它需要理解世界、制定计划、调用工具、记住上下文、遵守权限、识别风险，还要对最终结果负责。
这相当于试图建造一个无所不能的数字大脑。
但互联网并不是由一个无所不能的系统设计出来的。
数据库的创造者没有预先设计出 Google；互联网协议的设计者也没有提前规划出 Stripe。
他们真正做的，是把底层能力做得足够稳定、通用和可靠。后来的人在这些能力上不断叠加，最终形成了任何一个中心化设计者都无法提前规划的软件生态。
AI 的未来也可能遵循相同路径。
我们并不一定需要先造出一个像神一样无所不能的智能，然后再让它管理整个世界。
另一条路径是，把智能拆分成一组范围清晰、可以检查、能够约束的小型组件，让开发者像组合软件模块一样组合这些智能能力。
复杂系统由简单组件逐层生长出来。
这种系统看起来可能没有那么像“神”，但它更容易进入真实的生产环境，也更容易被人类理解和控制。
从聊天走向真正的自动化
TypeSafe AI 将这条路线分成了三个阶段。
第一步，是找到真正适合机器的可组合 AI 形态，用更低的成本提供更高密度的有效智能。
第二步，是让这些智能能力足够可靠，从“给人提建议”走向可以在真实业务中自动运行。
第三步，是形成稳定的高层智能抽象，让开发者可以在上面继续组合、封装和创新，最终推动整个智能软件生态自然生长。
这条路线追求的并不是一个能够回答所有问题的超级聊天机器人。
它追求的是：
-
AI 可以在后台长期运行； -
智能判断可以像函数一样调用； -
每个能力都有清晰边界； -
系统中的行为可以被检查和审计； -
多个智能模块能够安全地组合； -
AI 最终能够承担真实工作。
我们需要的不是更会说话的 AI
今天评价一个模型时，人们最容易关注的是它是否聪明：能不能解决更难的数学题，能不能通过更复杂的考试，能不能生成更漂亮的代码。
但进入生产环境之后，企业更关心的是另一组问题：
它是否稳定？ 能否控制它可以访问的数据？ 能否限制它能够调用的工具？ 执行重要操作前是否需要授权？ 出现异常后能否知道发生了什么？ 能否把一次成功演示变成持续运行的系统？
一个模型偶尔展现出惊人的能力，并不等于它能够成为生产力。
真正改变经济的，也不会只是模型能力排行榜上的又一次刷新，而是 AI 从一个需要人类随时照看的助手，变成一种能够被软件可靠调用的基础设施。
这也是《Composable AI》宣言最值得关注的地方。
AI 行业下一阶段最重要的问题，可能不再是：
我们什么时候能够造出一个更像人的智能？
而是：
我们什么时候能够让现有的智能变得足够可靠，让人类放心把真实工作交给它？
不要急着造“神”。
先把 AI 送进生产环境。
Build Prod, Not God.
原文：Composable AI: Build Prod, Not God — TypeSafe AI