Agent+Mojo：构建高性能智能体的核心架构与工程实践

很多人问我“太空计划”这个项目名字是怎么来的，其实真没有那么多玄乎的东西，就是我在本地起项目仓库的时候随手敲的代号。但里面的两个关键词——agent和mojo，反而是我沉淀了大半年以后最想拿出来聊聊的东西。一个负责把复杂任务拆开、调度、决策，一个负责在底层提供高性能的计算执行力，两者结合，做出来的东西确实挺有“探索未知”的味道。

如果你最近在关注AI应用层开发，一定绕不开agent这个词。它从最初“能聊天的对话框”进化到“能自己调工具、做规划、完成多步骤任务”的智能体，从demo走向了生产环境。而mojo，则是一个年轻的、面向AI开发者的系统编程语言，兼容Python语法，又能在性能敏感的地方跑出远高于Python原生代码的速度。太空计划这个项目，本质上就是一次把“智能决策”和“高性能执行”粘在一起的技术实验。

这篇文章主要围绕三条线展开：项目核心思路、Agent框架和模块的具体落地方式、以及我在开发中踩过的坑和排查方法。不管你是正准备入门agent开发，还是已经在用LangChain、AutoGPT这类框架但又觉得控制力不够，想自己动手搭一套轻量Agent体系，相信这篇能从底到上给你一些参考。

1. 项目定位：代号“太空计划”到底想做什么

1.1 起名背后的需求：Agent要能自主走完全程

“太空计划”这个代号，其实对应的是项目里面一个非常朴素的目标：让Agent在尽可能少的人工干预下，完成一条完整的任务链路。什么才算完整？以我实际跑的一个场景为例，用户给了一堆日志文件，说“帮我分析一下异常，再画一张趋势图”。传统对话机器人能做的，是理解这句话并给出分析建议；而我要做的Agent，必须自己完成：读取文件、清洗字段、调用数据分析函数、生成图表、写总结报告，最后把结果返回给用户。整个过程不是一个函数调用，而是一整条需要规划、执行、反馈、修正的工作流。

所以我给“太空计划”定的边界不是“有多聪明”，而是“能走多远”。这让项目的架构思路从一开始就和大多数ChatBot类应用不同，我关注的不是单轮问答的准确率，而是：

• 任务能否被正确拆解成多个子步骤；
• 每一步的输入输出是否可验证；
• Agent在步骤失败时，能不能自己发现问题并调整策略；
• 多轮执行过程中，有没有办法保留“有用”的上下文，而不是把所有历史都塞给模型。

我经常用一个比喻：普通对话是让模型“说”，Agent是让模型“做”。说错了顶多纠正一次，做的时候如果第一步就错了，后面全白费。因此项目之初，我就刻意没有一上来就套某个重型Agent框架，而是先把上面四件事用最朴素的代码实现了一遍，再考虑要不要引入框架。这样踩过一遍底层逻辑以后，不管后面用LangChain还是自研链路，心里都有底。

1.2 技术选型为什么是“Agent + Mojo”

确定了要做“能自主走完全程”的Agent之后，下一个问题就是技术栈怎么选。Agent这层，市面上确定性比较高的方案是Python，因为无论OpenAI、Anthropic的SDK，还是LangChain、LlamaIndex等框架，全都是Python生态。而“Mojo”这个变量，是我在探索性能优化路径时主动加进来的。

Mojo是Modular公司推出的一门面向AI开发者的语言，它的特点很直接：语法上兼容Python，你可以写很Python风格的代码；同时它提供了值类型、自动向量化、SIMD指令和显式并行能力，在计算密集型场景下能跑到接近C/C++甚至超过C++的水平。Agent系统表面上是一个“调用模型”的过程，但实际跑起来以后，瓶颈往往出现在模型之外的代码上，比如大规模数据的预处理、向量检索、工具调度、日志解析、上下文管理。这些代码如果用纯Python写，不仅慢，而且会吃掉服务器大量CPU时间。

我当时的设计思路是“混合架构”：Agent的编排层，包括任务规划、工具调用逻辑、模型交互，放在Python里，因为它最灵活，第三方库覆盖也最全。而真正耗CPU的计算密集部分，比如处理10万行日志、批量做Embedding向量化、对中间结果做数值分析，抽出来用Mojo实现，再通过外部命令或者FFI的方式交给Python调用。这样做的好处有三个：

1. 不影响Agent生态。Python侧可以继续用PyTorch、Transformers、LangChain的一切能力。
2. 性能关键路径可优化。Mojo可以写出真正并行的代码，实测在纯计算任务上比Python单线程快一个数量级以上。
3. 技术风险可控。Mojo目前还在迭代期，我不让它成为整个Agent的骨架，只把它放在可控的工具层，出问题可以随时替换回C++或Python优化版本。

这算是“Agent + Mojo”组合的一个比较落地的解释。很多朋友看到Mojo的第一反应是“要不要把项目全面迁过去”，我的建议是：别。把Agent这种偏动态、强I/O、强生态依赖的系统全部交给一门还在发展初期的语言，是不现实的。但把它当“外挂加速器”，性价比极高。

2. Agent系统的核心模块拆解

2.1 规划模块：把大任务拆成可执行子任务

Agent和普通函数调用最大的区别，在于它具备“规划”能力。规划模块在太空计划里承担的角色，相当于团队里的项目经理——一个大任务进来，它负责拆解、排序、估算依赖关系。但这里有个非常容易被新手踩坑的点：不要让模型直接输出“我要怎么做”，而是要让模型输出一份结构化的、可被程序校验的Action Plan。

我第一版实现的时候，规划Prompt非常开放：“请分析用户需求并完成任务”。模型输出也确实看起来不错