我用 Python 和 Rust 构建过 AI Agent，但只有一个做好了生产准备
这是高级工程师们心照不宣的残酷真相。
当下，几乎所有构建 AI Agent 的人都在使用 Python。
Python 是 AI Agent 诞生的地方，而 Rust 才是它们在生产环境中生存的土壤。
我完全理解。Python 拥有完善的生态、LangChain 和海量教程。你只需一个 pip install 和一段充满灵感的 prompt，就能在 20 分钟内跑起一个 Agent。
但后来，我用 Rust 重写了我的 Agent，并且再也回不去了。
这并不是因为 Rust 很酷（虽然它确实酷），也不是因为我想炫耀（好吧，可能有一点点）。真正的原因是，当我在大规模构建生产级 AI Agent 之后，我发现 Python 已经不再适用了。
这些 Agent 需要管理内存、调用工具、在目标循环中运行，并且要保证 7x24 小时全天候运转。
这些隐患在第一天并不明显。 它们往往在凌晨 3 点爆发：当你的内存层在并发工具调用下发生数据损坏，而你正盯着 Python 的 GIL 根本无法挽救的竞态条件发呆时。
我多希望在将第一个 Agent 推向生产环境之前，有人能对我说出这番话。
暴论：Python 适合做 AI 原型，但对 AI Agent 来说是负债
在喷我之前先声明：我并不是说 Python 不好。我想强调的是，那些让 Python 在数据科学和快速原型设计中大放异彩的特性，恰恰是让它在构建 Agent 时变得危险的致命伤。
这里有一个至关重要的区别：
AI 原型通常只运行一次，在 Notebook 里验证概念。如果失败了，你可以直观地看到报错并重启。
而 AI Agent 则需要持续运行，跨越多个回合管理状态，调用外部工具，自主处理故障，并且期望它能够自我恢复，而不是直接崩溃。
这是两种完全不同的运行时要求。然而，我们却在用一种为前者优化过的语言，去构建后者。
我用 Python 构建 Agent 时反复遇到的三个坑
现代 Agent 并不是顺序执行的。一个复杂的 Agent 会在并行中管理多个工具调用——查询数据库、调用 API、检查缓存——与此同时，内存层也正在被不断地读取和写入。
Python 的全局解释器锁（GIL）会给你一种虚假的安全感。它根本无法保护你免受异步代码中的逻辑竞态条件。
我就曾踩过这个坑：当时我的 Agent 正在跨并行工具调用管理对话上下文。两个工具几乎同时更新了内存存储，导致合并结果出错。最终，Agent 基于损坏的上下文给出了“自信满满”的错误回答。
在生产环境中，无声的错误回答比响亮的崩溃可怕得多。
而在 Rust 中，借用检查器（borrow checker）让这类 Bug 在编译阶段就变得不可能存在。你无法同时对同一份数据拥有两个可变引用。编译器会在你发布代码前就拦截错误，而不是等到凌晨 3 点，你的 Agent 产生幻觉时才发现。
Python 的垃圾回收器（GC）是为吞吐量优化的，而不是为管理有限状态的长时间运行进程优化的。一个运行了几个小时的 Agent 会积累大量对象引用，而 GC 不会按照你期望的时间表去清理它们。
我曾观察过一个 Python Agent，在 6 小时的运行中，其 RSS 内存占用从 180MB 飙升到了 1.4GB。这甚至不是什么明显的内存泄漏，仅仅是中间对象的自然累积、异步回调中的闭包引用，以及 Python 对象模型本身的开销。
但在 Rust 中，你需要多少就分配多少，用完立即释放。我的 Agent 内存层在 Rust 中的内存占用，在几个小时的运行中波动范围可以精确预测到几 MB 以内。
对于生产级 Agent 来说，这种可预测性不是奢侈品，而是刚需。
Python 的异常处理是一种“可选的自律”。你可以处理异常，但你不是必须处理。在项目截止日期的压力下，你往往不会去处理。
结果是，Agent 里的 try/except 块可能会悄悄吞掉错误，将其记录到毫无用处的地方，然后让 Agent 在它自己都不知道的降级状态下继续运行。
相反，Rust 的 Result<T, E> 让错误处理变成了强制性的。你不能调用一个可能失败的函数却无视这个失败，编译器绝对不会放过你。每一个错误路径都是显式的，每一种失败模式要么被处理，要么被明确地向上传递。
对于一个需要推理自身工具调用失败的 Agent 来说（比如重试逻辑、降级策略、问题升级），这绝不是书呆子气，而是它赖以生存的基石。
我重写了 Agent 的内存层，包括：对话历史管理、语义分块、检索索引，以及决定在每次 LLM 调用中包含哪些上下文的状态机。
这个模块的 Python 版本大约有 800 行。它虽然能跑，但也包含 3 个我已经标记为 TODO 的已知竞态条件，2 个我打算“以后再修”的内存泄漏模式，以及让我感到汗颜的错误处理逻辑。
而 Rust 版本只有大约 420 行。它有 0 个已知竞态条件（借用检查器在编译时就把它们扼杀了）；内存占用极其稳定；所有的错误路径都得到了妥善处理。
这次重写花了我一个周末的时间。最终的结果是：以仅 40% 的内存消耗，处理了 3 倍的并发会话。 这不是瞎猜，我跑了基准测试的。
这也是我在 O'Reilly 的《Agent Memory Essentials》课程中教授的核心内容：不是为了学 Rust 而学 Rust，而是因为 Agent 内存的特殊需求在呼唤 Rust。
所有权（Ownership）的语义与 Agent 中内存管理的语义完美契合，这绝非巧合。
有人会说：“Rust 的生态还没跟上呢。”
确实。LangChain、LlamaIndex、Hugging Face 等工具链目前都是 Python 的天下。几乎所有主流 LLM 提供商的 SDK 也都是优先发布 Python 版本。
这是客观存在的阻力，我无意掩饰这一点。
但情况正在发生变化：Agent 的编排层和基础设施层正在解耦。
你可以继续用 Python 编写工具定义、提示词模板和 LLM 调用。但是，你应该用 Rust 来编写你的内存层、状态机、并发工具执行运行时，并通过 FFI 或微服务的方式暴露给 Python。
这是我目前正在采用的架构，也是我认为未来 18 个月内严肃的生产级 Agent 技术栈的演进方向：Python 作为上层编排器，Rust 作为底层可靠引擎。
早日想通这一点的团队，将拥有真正能在生产环境中稳定运行的 Agent；而想不通的团队，只会在凌晨 3 点继续苦逼地调试 Python async 代码中的竞态条件。
如今 AI Agent 领域发展实在太快，以至于大家形成了一种默契：把原型系统打上“生产可用”的标签就万事大吉了。
我们在发布能够管理真实状态、做出真实决策、调用真实 API 的 Agent 时，却完全没有应用我们在构建其他持续运行、管理关键数据的系统时应有的严谨态度。
Rust 无法解决 LLM 的可靠性问题，它不能让你的提示词变得更好，也不能消除大模型的幻觉。
但是，它能让你的基础设施变得诚实。 它强迫你处理每一个错误，在并发 Bug 进入生产环境之前将其拦截，并为你提供一个清晰可测的内存占用。
对于理应具备自主性、可靠性和长期运行能力的 AI Agent 来说，基础设施的诚实绝不是可选项。
Python，是你探索 Agent 应该做什么的地方。
Rust，是你让 Agent 真正可靠运转的底座。
