> **来源：[研报客](https://pc.yanbaoke.cn)** # 文档总结：我们不需要另一个智能体框架 ## 核心内容 本文探讨了在 AI 驱动开发时代，构建智能体框架的必要性与局限性。作者认为，传统的框架思维已不再适用于当前的智能体开发环境，并提出了重新定义框架的新思路，强调应关注 AI 原生开发的生态与实践。 --- ## 主要观点 1. **框架的反模式问题** 当前的智能体框架热潮是架构层面的“代码异味”，它暗示着我们正在为一个已不复存在的世界构建框架。框架的过度设计可能成为负担，而非助力。 2. **框架的重新定义** 传统框架关注的是代码抽象与基础设施，而现代智能体框架应是一个包含六个层级的完整环境，这些层级包括： - 编程语言本身 - 大语言模型 - 开发者效率工具 - 提示词包与指南 - 生态系统 API - 架构与设计模式 3. **框架的重心转移** 框架不再是代码抽象的工具，而是关于如何在智能体开发生命周期中进行管理与优化的规范。重点应放在提示词管理、生态系统集成、架构决策等更广泛的领域。 4. **AI 驱动开发的现实** AI 工具（如 Cursor、GitHub Copilot）已经能够快速生成代码，使得传统的框架抽象变得多余。开发者应专注于业务逻辑与智能体行为，而非代码结构。 5. **引擎、SDK 与平台的分工** - **引擎**：负责智能体的核心推理与执行（如 LangChain、LangGraph）。 - **SDK**：作为语言与引擎之间的桥梁，提供开发接口（如 LangChain4J）。 - **平台**：解决横向挑战的专业服务（如记忆管理、工具执行、可观测性等）。 6. **编排层的精简趋势** 随着模型推理能力的提升和专业平台的成熟，传统的编排框架正被挤压，逐渐转变为一个声明式的协调层，核心职责是定义护栏与目标，而非具体执行。 --- ## 关键信息 ### 六个层级的智能体框架 | 层级 | 内容 | |------|------| | **层级一：编程语言本身** | Java、Python、Go 等现代语言已具备足够的结构能力，无需额外框架。 | | **层级二：模型** | 选择能力强的模型（如 GPT-4、Claude 3.5、Gemini）是智能体能力上限的关键。 | | **层级三：开发者效率工具** | Cursor、Copilot 等 AI 工具正在接管代码生成，框架应与这些工具兼容。 | | **层级四：提示词包与指南** | 提示词是业务逻辑的核心，应进行版本控制、测试与治理。 | | **层级五：生态系统 API** | 与专业平台（如 Arcade、Zep、LangSmith）的 API 集成是智能体扩展能力的基础。 | | **层级六：架构与设计模式** | 架构决策应以文档形式记录，关注提示词版本、部署策略、工作流路由等。 | ### 智能体开发的可扩展路径 - **从 1 到 1000**：智能体的扩展并非依赖于框架，而是通过复用模型、架构蓝图和生态系统 API，为每个智能体定制提示词包。 - **开发工具**：Cursor 等工具能快速生成代码，使开发者能专注于架构与提示词设计。 - **架构决策记录（ADR）**：例如，使用基于向量相似度的分类路由，而非规则引擎，以适应新的查询类型。 ### 新现实下的框架定义 | 传统框架 | 新一代框架 | |----------|------------| | 定义为代码库 | 定义为跨六个层级的完整环境 | | 业务逻辑位于代码中 | 业务逻辑位于提示词与指南中 | | 关键构件为 JAR 文件 | 关键构件为提示词、上下文与 API 知识 | | 可复用性通过代码继承 | 可复用性通过架构模式与蓝图 | | 开发工具为 IDE | 开发工具为 AI 生成代码的工具（如 Cursor） | | 生态系统为自包含 | 生态系统为集成专业化平台 | | 样板代码由框架抽象 | 样板代码由 AI 工具快速生成 | --- ## 总结 在 AI 驱动开发的时代，构建智能体框架不再是首要任务。框架的定义已从“代码抽象”转变为“智能体开发生命周期的管理与优化”。真正的价值在于提示词设计、生态系统集成与架构决策，而非复杂的编排逻辑。开发者应专注于构建智能体本身，而非重复构建框架。未来的框架，是关于认知环境与操作体系的深刻理解，而非代码库的导入。我们应拥抱 AI 原生开发，将重点转向构建更高效、更灵活、更可扩展的智能体解决方案。