🔶 不要为 AI Agent 专门构建工具

许多 人 主张，我们应当停止为人类用户构建软件，转而开始为 AI Agent 构建软件。这种说法在一定程度上是有道理的。比如，我的 AI Agent 使用 Datadog 的频率现在远高于我本人，纯粹是因为它们运行速度快得多，而且能够并行工作。但我认为，大多数构建“面向 AI Agent 的 X”这一类产品的尝试都会失败。原因有三：

首先，对 AI Agent 有利的工具，对人类通常也有利。如果你拿一款流行软件产品——比如 Jira——尝试将其重新设计为面向 AI Agent 的产品，最终得到的东西会与 Jira 非常相似。Agent 使用计算机的方式与人类工程师相同：输入文本、发起 API 调用。它们获取新信息的方式也与人类相同：阅读内容、查看图像。它们进行优先级排序、委派任务和分类的方式同样如此。这并非 AI 工作方式的内在必然结果——我们或许可以设计出更不像人类的 Agent——但在当前世界中，类人 Agent 在同等投入下更有用。

举例来说，假设人形机器人已经无处不在。你会为它们构建什么样的工具？它们拥有人类的形状、人类的手和四肢，因此，对人类很好的工具对机器人也同样很适用。这是一个自我强化的循环：如果你在制造机器人，就应当把它们设计成人形，以便完成广泛的人类任务；而这意味着，它们最适合使用人类工具。同样的原则也适用于 AI Agent。

第二，出现在训练数据中，会给现有工具带来巨大优势。假设你的新工具对 AI Agent 而言，比人类使用的同类软件好 20%。如果 Agent 已经了解人类软件 所带来的收益超过 20%，那么它们就不应使用你的新工具。这也是为什么我始终对“为 AI Agent 开发一种新编程语言”的计划持怀疑态度。Agent 对现有编程语言拥有数十亿、数十亿 Token 的知识，其中包括其库、模式和惯用写法。要让它们在一种全新的语言中达到同样的效率，将会非常困难。

第三，我们尚不清楚 AI Agent 的理想人机工效学是什么。目前流传着很多事后合理化故事（例如，AI Agent 偏好静态类型语言，因为反馈循环更紧密），但当你实际测量时，Agent 究竟更擅长使用哪些工具，似乎仍然非常不明确。你可以朝任意方向构造一个看似合理的论述：Golang 是优秀的 Agent 语言，因为它编译快且是静态类型；Golang 是糟糕的 Agent 语言，因为它需要大量样板代码，会挤占上下文窗口。情况变化也非常快：去年，AI Agent 的一个主要担忧还是如何保持上下文窗口足够小；但近几个月，压缩技术已经变得如此出色，以至于你几乎可以无限次重新压缩一个 272k 的上下文窗口。

你仍然可以、也应该通过一些方式，让自己的工具更便于 AI Agent 使用。例如，提供以纯文本或 Markdown 暴露信息的方式，构建功能完善的 API，实现 MCP Server 或 CLI，等等：这些都能让当前的 AI 更容易使用你的工具。但这些都只是边际改进，而不是对产品进行根本性重新设计。现在，“为 AI Agent 构建”只意味着“我们优先考虑 API 而不是 UI”。而且，甚至不清楚这是否是一项持久有效的策略。随着 GPT-6-Astra 在计算机使用方面变得非常出色，面向 AI 的工具与面向人类的工具之间的差距正在缩小。

下面是另一篇带有相同标签的相关文章预览。

他们真的认为 AI 可能杀死所有人

Anthropic 一名研究员最近发布的一则离职推文，再次让所有人开始讨论 AI 末日论。除其他内容外，他表示：

构建 AI 的人真诚地相信，到这个十年结束时，它可能会杀死我们所有人。

许多人很难相信 AI 研究人员会以这种方式思考。一些人将其解释为推动 AI 监管的公关活动，或是自我宣传，又或是推高 AI 公司股价的一种手段。另一些人认为这一定不可能是真的，因为如果你真的相信这一点，你应该去轰炸数据中心，而不是在 Twitter 上发帖。
继续阅读……

Lots of people are making the case that we should stop building software for human users and start building it for AI agents. This kind of makes sense. For instance, my AI agents now use Datadog way more than I use it myself, purely by virtue of them moving much more quickly and running in parallel. But I think most attempts to build “X for AI agents” are going to fail. Here are three reasons why:

First, tools that are good for AI agents are also good for humans. If you took a popular software product — say, Jira — and tried to redesign it for AI agents, you would end up with something very similar to Jira. Agents use a computer in the same way human engineers do, by entering text and making API calls. They ingest new information in the same way humans do, by reading and viewing images. They prioritize and delegate and categorize in the same way humans do. This isn’t intrinsic to how AI works — we could potentially design agents that are more inhuman — but human-like agents are pound-for-pound more useful in our current world.

As an example, let’s imagine that humanoid robots have become ubiquitous. What kind of tools would you build for them? Well, they’re shaped like humans, with human hands and limbs, so tools that are great for humans will also be great for robots. It’s a self-reinforcing cycle: if you’re building a robot, you should make them humanoid so they can do a wide range of human tasks, and that means they’ll be best suited to use human tools. The same principle applies to AI agents.

Second, being in the training data is a huge advantage for existing tools. Suppose your new tool for AI agents is 20% better for them than the equivalent piece of software for humans. If the benefit of the agent already knowing the human software is greater than 20%, they shouldn’t use your new tool. This is why I’m always suspicious of plans to develop a new programming language for AI agents. The agents have billions and billions of tokens of knowledge about existing programming languages, including their libraries, patterns, and idioms. It is going to be very hard for them to be as effective in a brand-new language.

Third, we don’t yet know the ideal ergonomics for AI agents. There are lots of just-so stories floating around (like that AI agents prefer statically-typed languages because the feedback loop is tighter), but when you actually measure it seems really unclear which tools agents use better. You can construct a plausible story in either direction: Golang is a great agent language because it compiles quickly and is statically typed; Golang is an awful agent language because it requires extensive boilerplate which clogs the context window. It’s also changing so quickly: last year, one primary worry with AI agents was keeping the context window small, but in recent months compaction has become so good that you can re-compact a 272k context window almost unlimited times.

There are still some ways you can and should position your tool to be usable by AI agents. Having a way to expose information in plain text or Markdown, building a functional API, implementing MCP servers or CLIs, and so on: these all make it easier for current AIs to use your tool. But these are all improvements on the margin, not fundamental redesigns of the product. Right now, “building for AI agents” just means “we’re prioritizing the API over the UI”. And it’s not even clear that that’s a durable strategy. Now that GPT-6-Astra is getting really good at computer use, the gap between tools-for-AIs and tools-for-humans is closing.

Here's a preview of a related post that shares tags with this one.

They really do think AI might kill everyone

A recent resignation tweet from an Anthropic researcher has everyone talking about the AI apocalypse again. Among other things, he said:

The people building AI earnestly believe that it could kill us all by the end of the decade.

Many people found it hard to believe that AI researchers think this way. Some explained it as a PR campaign to promote AI regulation, or as self-promotion, or as a way to boost AI company stock prices. Others felt it had to be impossible, because if you really believed this you’d be bombing datacenters instead of posting on Twitter.
Continue reading...