理解AI智能体领域格局
尽管我们看到许多智能体技术栈和市场分布图，但我们倾向于不认同它们的分类方式，并发现这些分类很少能真实反映开发者实际使用的工具。过去几个月，AI智能体软件生态系统在记忆能力、工具调用、安全执行和部署等方面取得了显著进展。基于我们在开源AI领域一年多的实践经验和七年以上的AI研究积累，我们决定分享自己构建的"智能体技术栈"，以呈现更贴合行业实践的技术全景。
从大型语言模型到智能体的演进
2022至2023年间，我们见证了LangChain（2022年10月发布）和LlamaIndex（2022年11月发布）等LLM框架和SDK的崛起。与此同时，通过API调用LLM服务的标准化平台逐渐成熟，自主部署LLM推理的技术（如vLLM和Ollama）也形成了稳定生态。
进入2024年，行业关注点显著转向AI"智能体"及更广义的复合系统。尽管"智能体"作为强化学习领域的概念已存在数十年，但在ChatGPT时代，它被重新定义为一种由LLM驱动、能自主输出行动指令（工具调用）的系统。这种结合工具调用、自主运行和记忆能力的范式，标志着从基础LLM向智能体的跨越，也催生了新一代智能体技术栈的兴起。
智能体技术栈的独特之处是什么？与基础的LLM聊天机器人相比，智能体是一个显著更复杂的工程挑战，因为它们需要状态管理（保留消息/事件历史、存储长期记忆、在智能体循环中执行多次LLM调用）和工具执行（安全执行LLM输出的动作并返回结果）。因此，AI智能体技术栈与标准LLM技术栈截然不同。让我们从底层的模型服务层开始拆解当今的AI智能体技术栈：
模型服务层（Model Serving）
在AI智能体的核心是大型语言模型（LLM）。要使用LLM，需要通过推理引擎部署模型，最常见的方式是付费API服务。
闭源API模型推理服务商： OpenAI和Anthropic凭借其私有尖端模型（如GPT-4、Claude 3）处于领先地位。
开源模型API服务商： Together.AI、Fireworks和Groq等平台通过付费API提供开源权重模型（如Llama 3）的托管服务。
本地模型推理引擎：
业余爱好者（"AI发烧友"）：Ollama和LM Studio是两大热门工具，支持在个人电脑（如M系列苹果MacBook）上本地运行模型。
生产级GPU部署：vLLM是生产环境中基于GPU部署的主流选择，SGLang则是面向类似开发者群体的新兴项目。
本地个人设备运行。
存储层
存储是智能体（具有状态）的基础构建模块——智能体的核心特征在于其持久化状态，包括对话历史、记忆以及用于RAG的外部数据源。
向量数据库： Chroma、Weaviate、Pinecone、Qdrant和Milvus等向量数据库被广泛用于存储智能体的"外部记忆"，使智能体能够利用远超上下文窗口容量限制的数据源和对话历史。
传统数据库的向量扩展： Postgres（诞生于80年代的关系型数据库）通过pgvector扩展支持向量搜索。基于Postgres的公司如Neon（无服务器Postgres）和Supabase，也为智能体提供嵌入向量搜索与存储服务。
工具与库层
标准AI聊天机器人与AI智能体的核心区别在于，智能体具备调用"工具"（或"函数"）的能力。在大多数情况下，这种操作的机制是LLM生成结构化输出（例如JSON对象），指定要调用的函数及其参数。关于智能体工具执行的一个常见误解是：工具执行并非由LLM提供商完成——LLM仅负责选择要调用的工具和提供参数。支持任意工具或任意参数的智能体服务必须使用沙箱（如Modal、E2B）来确保安全执行。
所有智能体都通过OpenAI定义的JSON Schema调用工具——这意味着不同框架的智能体和工具实际上可以互相兼容。例如Letta的智能体可以调用LangChain、CrewAI和Composio的工具，因为它们都遵循相同的Schema规范。因此，针对常见工具的供应商生态正在快速成长：
通用工具库：Composio作为热门通用工具库，还提供授权管理功能
垂直专用工具：
Browserbase（网页浏览专用工具）
Exa（网络搜索专用工具）
随着更多智能体的开发，我们预计工具生态将持续扩展，并为智能体提供身份验证、访问控制等新功能。
智能体框架
智能体框架负责编排LLM调用并管理智能体状态。不同框架在以下方面存在设计差异：
智能体状态管理
状态序列化： 多数框架引入了状态"序列化"概念（如将状态保存为JSON或字节流），允许通过加载序列化文件恢复智能体的对话历史、记忆和执行阶段。
数据库持久化： Letta等框架将所有状态存储在数据库（消息表、智能体状态表、记忆块表）中，无需显式序列化。这种设计支持直接查询状态（例如按日期检索历史消息），并影响系统的扩展性（处理长对话历史或多智能体场景）和状态修改灵活性。
上下文窗口结构
每次调用LLM时，框架会将智能体状态"编译"到上下文窗口中。不同框架以不同方式组织上下文窗口内的数据（如指令、消息缓冲区），这直接影响智能体性能。建议选择能透明化上下文窗口管理的框架，以便精确控制智能体行为。
3. 多智能体通信
消息队列： Llama Index通过消息队列实现智能体通信。
显式抽象层： CrewAI和AutoGen提供专门的多智能体抽象接口。
直接调用机制： Letta和LangGraph支持智能体直接互相调用，允许集中式（通过监督智能体）或分布式通信。
兼容性趋势： 多数框架现已同时支持单智能体与多智能体场景，因为设计良好的单智能体系统应能轻松扩展为协作系统。
ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 0.034em;background-color: transparent;">4. 内存管理方法
为突破LLM上下文窗口限制，各框架采用不同内存管理技术：
基于RAG的记忆： CrewAI和AutoGen完全依赖检索增强生成技术。
高级记忆技术： phidata和Letta集成自编辑记忆（如MemGPT）、递归摘要等创新方法。
自动化工具： Letta提供内置记忆管理工具，支持按文本/数据搜索历史消息、写入记忆、编辑上下文窗口。
5. 开源模型支持
模型提供商的隐式优化： 主流模型提供商通过重采样输出、提示词工程（如"请输出JSON"）等技巧确保工具调用格式正确。
框架适配挑战： 支持开源模型需要框架自行处理上述问题，因此部分框架仅限支持主要模型提供商。
选择框架的关键考量
当前构建智能体时，框架选择应基于具体需求：
应用类型：对话型智能体 vs 工作流自动化
运行环境：Notebook实验 vs 生产级服务
模型支持：对开源权重模型的需求
未来框架的核心差异将体现在部署流程中，状态/内存管理和工具执行的设计决策将更具决定性。
智能体托管和服务
当前大多数智能体框架的设计仍局限于Python脚本或Jupyter Notebook的本地运行环境。但我们认为，未来的智能体应被视为可部署到本地或云端基础设施的服务，通过REST API访问。正如OpenAI的ChatCompletion API成为LLM服务的行业标准，我们预计未来会出现统一的智能体API标准——尽管目前这一领域尚未形成明确领导者。
部署智能体服务的核心挑战
与部署LLM服务相比，智能体服务的部署复杂性显著增加，主要源于：
状态管理：
应用可能需要运行数百万个智能体，每个智能体的对话历史、记忆和执行状态持续增长。
从原型到生产环境时，智能体状态需经过数据规范化（如结构化存储、索引优化），而非简单的临时存储。
ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 0.034em;background-color: transparent;">工具执行安全：
工具依赖（如Python包版本、系统环境）需显式存储在数据库中，以便服务重建运行时环境。
需隔离执行环境（例如通过Docker容器或安全沙箱），防止恶意代码渗透。
ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 0.034em;background-color: transparent;">API标准化：
智能体交互必须通过严格定义的REST API接口实现，而非脚本内直接调用。
需支持异步通信、超时重试、速率限制等生产级API特性。
当前实践与未来趋势
现状： 开发者通常自行组合FastAPI（构建API层）、Postgres（状态存储）、Modal/E2B（安全执行）等技术栈，但这一过程重复且易出错。
框架演进方向：
内置生产化能力： 主流框架（如LangChain、CrewAI）正逐步集成数据库连接器、API生成器和部署工具。 例如LangChain近期推出的langserve模块可自动将智能体转换为REST API。
状态管理抽象化： 框架可能引入声明式状态定义（类似Django模型），自动处理序列化、版本迁移和查询优化。
混合部署模式： 支持智能体在本地（调试模式）与云端（生产模式）的无缝切换，类似PyTorch的train/eval模式切换。
关键决策点
选择智能体托管方案时需评估：
状态存储成本：向量数据库（如Pinecone）与关系型数据库（如Postgres）的成本权衡
执行环境隔离：轻量级沙箱（如E2B）与完整容器化（如Kubernetes）的安全性与开销平衡
API治理需求：是否需要集成身份验证（OAuth）、审计日志、 SLA监控等企业级功能
未来，智能体框架的竞争焦点将从"原型构建能力"转向"生产就绪性"，而部署工作流的成熟度将成为核心差异化因素。
| 欢迎光临 链载Ai (https://www.lianzai.com/) | Powered by Discuz! X3.5 |