一位开发者：为AI智能体构建工具，多数会失败

不要为AI智能体构建工具

很多人都在论证，我们应该停止为人类用户构建软件，转而开始为AI智能体构建软件。这在一定程度上是有道理的。例如，我的AI智能体现在使用Datadog的次数远超我自己，纯粹是因为它们运行速度更快且可以并行运行。但我认为大多数“为AI智能体构建X”的尝试都会失败。原因有三：

首先，对AI智能体好用的工具对人类同样好用。如果你拿一个流行的软件产品——比如Jira——尝试为AI智能体重新设计它，你最终得到的会和Jira非常相似。智能体使用计算机的方式与人类工程师相同，通过输入文本和调用API。它们摄取新信息的方式与人类相同，通过阅读和查看图像。它们做优先级排序、委派和分类的方式也与人类相同。这并不是AI工作方式的内在属性——我们本可以设计出更不类人的智能体——但在我们当前的世界里，类人的智能体在同等条件下更有用。

举个例子，假设人形机器人已经无处不在。你会为它们构建什么样的工具？嗯，它们的形状与人类相同，有着人类的手和四肢，所以对人类好用的工具对机器人也会很好用。这是一个自我强化的循环：如果你在构建机器人，你应该把它们做成类人的，这样它们就能完成广泛的人类任务¹，而这意味着它们最适合使用人类的工具。同样的原则也适用于AI智能体。

其次，存在于训练数据中是现有工具的巨大优势。假设你的AI智能体新工具比对应的人类软件好20%。如果智能体已经了解人类软件所带来的好处超过20%，它们就不应该使用你的新工具。这就是为什么我总是对为AI智能体开发新编程语言的计划持怀疑态度。智能体拥有数十亿乃至数千亿个token的关于现有编程语言的知识，包括它们的库、模式和惯用法。要让它们在新语言中同样高效将非常困难。

第三，我们还不知道AI智能体的理想人体工程学是什么。有很多看似合理的说法在流传（比如AI智能体偏好静态类型语言，因为反馈循环更紧凑），但当你真正去测量时，智能体用哪种工具更好似乎真的很不清楚。你可以构造出任何一个方向上的合理叙事：Golang是一种出色的智能体语言，因为它编译速度快且是静态类型的；Golang是一种糟糕的智能体语言，因为它需要大量样板代码，会堵塞上下文窗口。而且情况变化如此之快：去年，AI智能体的一个主要担忧是保持上下文窗口小巧，但近几个月压缩已经变得非常好²，以至于你可以几乎无限次地重新压缩一个272k的上下文窗口。

仍然有一些你可以而且应该采取的方式来让你的工具可供AI智能体使用。提供一种以纯文本或Markdown暴露信息的方式、构建功能性的API、实现MCP服务器或CLI等等：这些都让当前的AI更容易使用你的工具。但这些都只是边际上的改进，不是产品的基础性重新设计。眼下，“为AI智能体构建”仅仅意味着“我们在优先考虑API而非UI”。而且甚至不清楚这是否是一个持久的策略。既然GPT-6-Astra在计算机使用方面已经变得非常擅长，面向AI的工具与面向人类的工具之间的差距正在缩小。

¹ 让它们类人的另一个原因是，你可以从人类行为中获取它们的训练数据，这与AI智能体为何也是类人化的原因完全类似。

² 由于压缩等同于将任务移交给一个新的AI实例，它会随模型质量而扩展。我预计压缩会稳步改进，直到我们触及给定上下文窗口所能容纳的信息密度的字面极限。