理解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服务。
存储层
存储是智能体（具有状态）的基础构建模块——智能体的核心特征在于其持久化状态，包括对话历史、记忆以及用于RAG的外部数据源。
工具与库层
标准AI聊天机器人与AI智能体的核心区别在于，智能体具备调用”工具”（或”函数”）的能力。在大多数情况下，这种操作的机制是LLM生成结构化输出（例如JSON对象），指定要调用的函数及其参数。关于智能体工具执行的一个常见误解是：工具执行并非由LLM提供商完成——LLM仅负责选择要调用的工具和提供参数。支持任意工具或任意参数的智能体服务必须使用沙箱（如Modal、E2B）来确保安全执行。
所有智能体都通过OpenAI定义的JSON Schema调用工具——这意味着不同框架的智能体和工具实际上可以互相兼容。例如Letta的智能体可以调用LangChain、CrewAI和Composio的工具，因为它们都遵循相同的Schema规范。因此，针对常见工具的供应商生态正在快速成长：
随着更多智能体的开发，我们预计工具生态将持续扩展，并为智能体提供身份验证、访问控制等新功能。
智能体框架
智能体框架负责编排LLM调用并管理智能体状态。不同框架在以下方面存在设计差异：
每次调用LLM时，框架会将智能体状态”编译”到上下文窗口中。不同框架以不同方式组织上下文窗口内的数据（如指令、消息缓冲区），这直接影响智能体性能。建议选择能透明化上下文窗口管理的框架，以便精确控制智能体行为。
3. 多智能体通信
4. 内存管理方法
为突破LLM上下文窗口限制，各框架采用不同内存管理技术：
5. 开源模型支持
选择框架的关键考量
当前构建智能体时，框架选择应基于具体需求：
未来框架的核心差异将体现在部署流程中，状态/内存管理和工具执行的设计决策将更具决定性。
智能体托管和服务
当前大多数智能体框架的设计仍局限于Python脚本或Jupyter Notebook的本地运行环境。但我们认为，未来的智能体应被视为可部署到本地或云端基础设施的服务，通过REST API访问。正如OpenAI的ChatCompletion API成为LLM服务的行业标准，我们预计未来会出现统一的智能体API标准——尽管目前这一领域尚未形成明确领导者。
部署智能体服务的核心挑战
与部署LLM服务相比，智能体服务的部署复杂性显著增加，主要源于：
状态管理：
工具执行安全：
API标准化：
Agent 智能体当前实践与未来趋势
关键决策点
选择智能体托管方案时需评估：
未来，智能体框架的竞争焦点将从”原型构建能力”转向”生产就绪性”，而部署工作流的成熟度将成为核心差异化因素。
发布者：Ai探索者，转载请注明出处：https://javaforall.net/245049.html原文链接：https://javaforall.net
