Claude Code、Pi、OpenCode……为什么顶流 AI 编程 Agent 全是 JS/TS 写的？

周立志
周立志

ubuntu

2026年7月26日 14:10
河北

在小说阅读器读本章

去阅读

Claude Code、Pi、OpenCode……为什么顶流 AI 编程 Agent 全是 JS/TS 写的？

阅读时长：12 分钟

Anthropic 的 Claude Code（51 万行 TypeScript）、Mario Zechner 的 Pi（71K Star）、社区驱动的 OpenCode（180K Star）——三个出身截然不同的项目，技术上却高度收敛到了同一个选择。Python 不是 AI 的主场吗？这背后是五个跑不掉的工程取舍。

先看三个你可能天天用、或者至少听说过的 AI 编程工具：

三个项目出身完全不同——一个大厂官方、一个独立开发者、一个纯粹社区驱动——但技术栈惊人地统一：全是 TypeScript + Node.js。

而这只是冰山一角。拉出整个 AI 编码 Agent 的 GitHub Star 排行榜，前十名里九个是 TypeScript，零个 Python：

这就有点反常识了——Python 不是 AI 的主场吗？难道不应该用 Python 写 AI 工具？

但三个完全不同背景的团队，Claude Code 的 Anthropic、Pi 的 Mario、OpenCode 的社区贡献者，在不到一年内不约而同选了同一个栈。这不是抄袭，是被同一个工程现实推到了同一个选项上。

本文以这三个标杆项目为锚点，沿着五个技术取舍，拆解这场\"无声选型统一\"背后的底层逻辑。

一、取舍一：事件循环和 ReAct 循环是结构同构的

这是所有 JS Agent 选型的最底层理由。说人话就是：

Node.js 的事件循环（Event Loop）和 AI Agent 的 ReAct 推理循环（Reason + Act），在结构上根本是同一种东西的两种叫法。

Node.js 事件循环：  事件队列 → 回调执行 → 异步 I/O → 回到事件队列
                    ↑                                         │
                    └──────────── 永不阻塞 ──────────────────┘

Agent ReAct 循环：  Observe → Think (LLM) → Act (Tool) → Observe
                    ↑                                       │
                    └────────── 永不等待 ───────────────────┘

这不是文字游戏。看一个真实的 Agent 循环就清楚了：

// Pi 的 Agent Loop 核心逻辑（简化自 @earendil-works/pi-agent-core）
async function* agentLoop(context: AgentContext): AsyncGenerator {
  while (true) {
    // ① 组装上下文 → 调用 LLM（异步 I/O，事件循环不阻塞）
    const stream = await model.stream(context)

    // ② 逐 chunk 消费 SSE 流
    for await (const event of stream) {
      if (event.type === 'tool_use') {
        // ③ 模型想调工具 → 执行（bash/read/write/edit）
        const result = await executeTool(event.toolCall)

        // ④ 工具结果压入消息队列，循环继续
        context.messages.push({ role: 'tool', content: result })
      }
    }

    // ⑤ 模型自然结束 → 退出循环，等待用户下一轮输入
    if (stream.final.stop_reason !== 'tool_use') break
  }
}

这个代码片段里藏着三个关键映射：

Claude Code 泄露的 51 万行源码里印证了同一件事——它的核心就是一个 query() 异步生成器，用 while(true) + await 驱动的无限循环。没有任何复杂的状态机，没有多线程调度。

Python 也能写 async for，但体验差距在于——Python 的 asyncio 是\"后来加的\"，Node.js 的事件循环是\"生来如此\"。在 Python 里你要考虑 httpx.aiter_lines() 的类型转换、要小心阻塞 await 不会卡住整个事件循环——这些心智负担在 Node.js 里不存在。

架构师视角：选型最怕的就是运行时模型和业务模型对不上。Java 的线程池模型擅长 CPU 密集型同步任务，Python 的 GIL 在 IO 密集场景里要靠 asyncio 重构整个调用栈。而 Node.js 的事件循环天然就是为\"等 LLM 回复 → 处理回调 → 触发下一个工具调用\"这种业务节奏而生的。这不是性能差异，是结构性优势。

二、取舍二：流式输出是 Node.js 的绝对主场

现代 LLM 全部用 SSE（Server-Sent Events）流式返回——用户不必等整个回答生成完才看第一个字。

在 Node.js 里，消费流式输出就像呼吸一样自然：

// OpenClaw 中消费 Anthropic 流式响应的真实逻辑（简化）
const stream = await anthropic.messages.stream({
  model: 'claude-sonnet-4-6',
  messages: [{ role: 'user', content: userPrompt }],
})

for await (const event of stream) {
  if (event.type === 'content_block_delta') {
    // 逐字输出到终端——用户立即看到
    process.stdout.write(event.delta.text)
  }
  if (event.type === 'content_block_start') {
    // 提前拿到工具调用 block 的元信息
    handleToolStart(event.content_block)
  }
}

// 流结束后，如果模型要调工具，从 finalMessage 里取
const msg = await stream.finalMessage()

for await...of 是 ES2018 原生语法，ReadableStream 是 Node.js 内置 API。不需要任何第三方库，不需要手动处理 chunk 拼接，不需要担心内存泄漏。

Python 那边要用 async for + httpx.aiter_lines() + 手动 JSON 解析 + 手动类型转换。能写，但体验差距肉眼可见：

# 同样的逻辑在 Python 里长这样
async with httpx.AsyncClient() as client:
    async with client.stream(\"POST\", url, json=payload, headers=headers) as response:
        async for line in response.aiter_lines():
            if line.startswith(\"data: \"):
                data = json.loads(line[6:])  # 手动解析
                if data.get(\"type\") == \"content_block_delta\":
                    print(data[\"delta\"][\"text\"], end=\"\")  # 逐字输出

关键差异不在于\"能不能写\"，而在于 for await...of + SSE 是内置范式，而不是后来拼上去的。Claude Code 的 cli.js.map 里可以看到，它的流式逻辑只有不到 50 行——因为 Node.js 把最重的活干了。

三、取舍三：npm 生态在消息平台 SDK 上是降维优势

这是 OpenClaw 能在几周内集成 50+ 消息平台的根本原因。

这些平台本质上都是事件驱动、长连接、JSON 消息为核心的应用——和 Node.js 的核心范式完全对味，所以官方倾向于先做 Node SDK。

Pi 的 pi-mom（Slack 机器人）只是一行 import { App } from '@slack/bolt' 就完成了通道接入。在 Python 生态里，同样的集成需要三倍代码量、处理各种回调地狱。

架构师视角：选型时，生态成熟度的权重远高于语言性能。一个语言要在某领域成为标配，必须有官方 SDK 厚度、活跃维护节奏、社区代码案例三件套同时具备。Node.js 在消息平台这块刚好都有。

四、取舍四：TypeScript 已经是 LLM 的\"母语\"

这是一个自我强化的循环，而且滚起来就停不下：

互联网上 JS/TS 代码量最大（GitHub Octoverse 连续多年第一）
    ↓
LLM 训练数据里 JS/TS 占比最高
    ↓
LLM 写 TypeScript 的准确率天然最高
    ↓
用 TypeScript 构建 AI 工具 → AI 能更好地辅助开发
    ↓
更多 TypeScript 代码流入互联网 → 循环加速

这意味着什么？

看 Pi 的核心哲学——\"Ask Pi to build the feature you are missing, and it writes it.\" 你用 Pi 让它给自己写一个扩展，它生成的 TypeScript 代码大概率一次就跑通。

// Pi 的扩展系统——TS 类型安全保证了 AI 生成的代码质量
export default function (pi: ExtensionAPI) {
  pi.registerTool({
    name: 'deploy',
    description: 'Deploy current project to staging',
    // TypeBox schema → JSON Schema 自动生成 → 喂给 LLM
    parameters: Type.Object({
      environment: Type.Union([
        Type.Literal('staging'),
        Type.Literal('production')
      ]),
      branch: Type.Optional(Type.String())
    })
  })
}

TypeScript 的静态类型让 tool 的 schema 在编译时就能检查正确性。一个 schema 写错，LLM 就会被错误信息带偏——这在 Agent 这种\"工具调用密集型\"应用里是致命的。Python 的 duck typing 要到运行时才能发现 bug，而那时 Agent 可能已经跑了几十轮调用、烧了几块钱 token。

Claude Code 的 cli.js.map 泄露也证实了这一点——Anthropic 自己选择用 TypeScript 来写 Claude Code，尽管他们的核心模型是 Python 训练的。这说明了一件事：当 LLM 自己擅长写某种语言时，你用这种语言搭工具，AI 的辅助质量真的会高一档。

五、取舍五：import() 动态导入 = 真正的热插拔

Pi 最亮眼的用户体验之一是\"扩展即装即用\"：

$ pi install npm:@foo/pi-tools
# 安装完成，立即生效，无需重启
$ pi
> 扩展已加载：@foo/pi-tools

背后的技术原理是 Node.js ESM 的 import() 动态导入：

// OpenClaw 的插件热加载（真实逻辑简化）
async function loadExtension(packageName: string) {
  // 动态 import：不阻塞主循环，不影响已加载的扩展
  const module = await import(packageName)  // ← 这一行就是全部魔法

  module.register(gateway)  // 注册后立即生效
  console.log(`✅ 扩展已加载：${packageName}`)
}

Java 阵营要做到同等效果得搬出 OSGi 或自定义 ClassLoader 才能搞，复杂度直线飙升。Python 的 importlib 能动态加载但缺乏作用域隔离——两个扩展如果有命名冲突，无解。

Node.js 在这件事上是少有的默认行为就足够好的语言。这就是为什么 Pi 的生态能在一年内长出 2000+ 个社区扩展——低门槛的插件机制催生了爆炸式增长。

六、什么情况不该选 Node.js？——五种例外

架构师的本职是知道工具的边界。以下是五种\"反而该选别的\"的情况：

现代 AI 系统的常态不是单一语言统治一切，而是多语言协同：

用户消息 ─▶ OpenClaw Gateway (Node.js)
                │
                ├─▶ Anthropic / OpenAI API（普通 Agent 任务）
                ├─▶ Python FastAPI 微服务（数据分析、RAG）
                └─▶ Rust 原生库（向量计算、文件搜索）

Node.js 在前端接入和编排层，Python/Rust/Go 在后端计算层。分清边界，比强求统一栈更重要。

七、这场选型趋同不是巧合

总结一下。

Anthropic 的 Claude Code、Pi、OpenClaw——三个完全独立的团队，在一年内把 Agent 的技术栈收敛到了同一个选项：TypeScript + Node.js。

背后的推手不是社区情绪，不是\"前端工程师多\"，而是五个铁板钉钉的工程取舍：

这是一场无声的\"选型统一战争\"，而战斗已经接近尾声。

💡 iTalks | 聚焦前端 · 探索 AI 应用 · 输出成熟技术方案
🐧 关注我们，获取更多技术深度解读和前沿工程分析
💬 你觉得 Agent 项目统一到 JS/TS 是必然还是阶段性的？评论区聊聊。