为什么不用一种语言构建整个编码代理？

因为需求是混合的。运行时关键、安全敏感和并发性强的路径受益于 Rust，而编排和迁移层通常可以更快地用 Python 表达。

Python端通常处理什么？

兼容性垫片、奇偶校验清单、报告和迁移脚手架是混合代理系统中常见的 Python 职责。

多语言堆栈是否会自动使产品变得更好？

不会。只有当边界经过深思熟虑并且职责明确分离时，它才会有帮助。

为什么 AI 编码代理同时使用 Rust 和 Python

公开的 Claw Code parity 存储库中最能揭示问题的细节之一不是基准测试或产品屏幕截图。

这是语言分裂。

该项目并不试图在一层中完成所有事情。相反，它揭示了一种更多人工智能基础设施团队可能在未来几年采用的模式：

Rust 用于运行时核心，Python 用于编排、兼容性和迁移工作。

这种分裂并不是流行的工程戏剧。

这是对一个混乱问题的实用答案。

系列地图

本文是 AI 编码代理堆栈内部 的一部分：

为什么一种语言通常会停止扩展

在原型阶段，一种语言就很方便。

在代理阶段，权衡发生了变化。

现在你需要平衡：

提示和工作流程实验
文件系统和 shell 访问
会话持续性
流式IO模型
许可执行
外部工具集成
长期运行可靠性
来自旧系统的迁移压力

尝试用一种语言来优化所有这些通常会产生一个不平衡的系统。要么运行时变得太宽松，要么迭代层变得太严格。

Claw Code 平价回购协议显示了更严格的妥协。

Rust 在堆栈中做什么

Rust 工作区是系统变得严肃的地方。

截至 2026 年 4 月 2 日，公共 Parity 存储库公开了一个 Rust 工作区，其中包含以下包：

text
api
text
commands
text
compat-harness
text
plugins
text
runtime
text
rusty-claude-cli
text
telemetry
text
tools

这准确地告诉你作者想要硬性保证的地方。

Rust 正在处理产品中可预测性最重要的部分：

CLI 二进制文件和参数解析
对话运行时间
工具定义和执行
权限模式
钩子
MCP 传输和服务器管理
OAuth 和 API 管道
使用情况跟踪和遥测

换句话说，Rust 拥有信任边界。

这是有道理的。

如果您的代理可以读取文件、编辑代码、生成进程、连接到远程服务以及恢复长期会话，那么运行时行为就不再是随意的实现细节。这是产品。

Python 在堆栈中做什么

Python 方面在精神上较小，但在战略上很重要。

它并不试图成为最终的运行时。它的作用更像是镜像和迁移层。

公共

text

src/

树包含以下命令：

text
summary
text
manifest
text
parity-audit
text
bootstrap
text
route
text
turn-loop

它还为命令和工具清单提供了快照支持的模块，以及验证 Python 工作空间形状和行为的测试。

这与 Rust 运行时的工作不同。

Python 正在做 Python 在基础代码库中通常最擅长的事情：

快速迭代
报告生成
库存和清单工作
兼容性垫片
工作流程胶水
迁移脚手架

当系统被公开重新实现或重新塑造时，这正是您想要的层。当较低级别的运行时发展时，它保留了可见性。

隐藏在众目睽睽之下的架构模式

这是构建分割的更简洁的方法：

text
Rust
  -> execution core
  -> safety and permissions
  -> sessions, hooks, MCP, CLI runtime

Python
  -> parity mapping
  -> inventories and manifests
  -> migration reports
  -> compatibility-oriented workflow logic

这种划分很有用，因为它使最安全敏感的行为接近最强的运行时保证，同时为迭代和翻译工作保留了更灵活的表面。

这种模式很可能出现在爪码之外。

我希望更多构建编码代理、安全代理和自动化代理的团队能够集中在类似的事情上：

执行内核的一种语言
另一个用于编排、实验或迁移支持

确切的一对可能有所不同。底层逻辑可能不会。

为什么这对人工智能系统特别有意义

代理产品很不寻常，因为它们生活在三个世界的交汇处：

产品迭代
运行时系统工程
迁移和兼容性

对于第一和第三点，Python 仍然表现出色。

Rust 对于第二种来说越来越优秀。

一旦你接受了这一点，混合设计就不再看起来优柔寡断，而开始看起来像是专业化的。

对于编码代理来说尤其如此，系统可以：

执行外壳命令
按顺序编辑多个文件
流工具事件
管理长时间的会话状态
强化人类信任界限

在该环境中重要的运行时错误并不是表面的。它们是产品和安全问题。

团队在哪里犯了错误

当然，多语言堆栈可能会很快变坏。

失败模式不是“语言太多”。

失败模式是归属不明。

当你出现以下情况时，你就会遇到麻烦：

两层以不同的方式实现相同的行为
边界没有记录
测试仅覆盖一侧
迁移逻辑悄然转变为生产逻辑
运行时关键代码泄漏回脚本层

这就是为什么我认为 Python 方面的奇偶校验报告风格在这里如此重要。它表明了意图。该层用于描述、镜像和帮助管理转换，而不是意外地成为第二个运行时。

更广泛的行业信号

这也符合人工智能工具中更广泛的模式。

市场正在慢慢地将“提示层”与“操作层”分开。

提示层灵活、快速。

操作层需要：

更有力的保障
更好的可观察性
更干净的并发行为
更安全的工具执行
更清晰的审计追踪

这就是为什么我们看到如此多的注意力从纯粹的模型质量转移到代理基础设施的部分原因。更深层次的价值正在转移到运行时设计，而不仅仅是令牌生成。

如果您想了解这一转变的产品角度，请将本文与我们对 OpenAI 新兴代理堆栈的看法配对。如果您想了解操作角度，请阅读我们的人工智能代理制作指南。

适合建筑商的实用模板

如果您正在设计自己的代理系统，Claw Code 模式会建议一个实用的模板：

将信任边界置于您拥有的最强运行时中。
让工具、权限和会话保持在该边界附近。
仅当第二层有明确的工作时才使用第二层。
让迁移和对等工作变得明确，而不是手动。
像测试华而不实的表面一样积极地测试“无聊”的表面。

最后一点很重要。

代理通常首先在无聊的地方失败：

会议恢复
配置合并
权限默认值
工具过滤
序列化
钩子以错误的顺序触发

这些是运行时问题，而不是提示问题。

最后拍摄

Claw Code 的真正教训不是“Rust 比 Python 更好”，也不是相反。

教训是，编码代理现在做了足够多的实际工作，团队开始按职责分配语言。

这是成熟的标志。

当系统从演示环境过渡到运行环境时，实施策略也会随之变化。

这正是这个仓库所体现的。

探索全系列

如需完整阅读路径，请访问 AI Coding Agent Stack 主题中心。它将本系列与 MCP、开发人员工具和生产型代理设计的相关报道结合在一起。

阅读下一步

工具、权限和 MCP：编码代理如何成为现实
AI 代理团队的无尘室重写和奇偶校验
【AI特工制作指南】(/blog/ai-agents-production-guide)

为什么 AI 编码代理同时使用 Rust 和 Python