如何从零开始实现一个 AI Agent 框架 - 理论篇

关注

原创最新推荐文章于 2026-04-18 21:25:57 发布 979 阅读 AI 写同款· GEO 优化 ›

如何从零开始实现一个 AI Agent 框架本文介绍了一个基于大语言模型(LLM)的AI Agent框架实现方案。该框架采用模块化设计，包含感知、记忆、规划、工具和行动等核心组件。文章详细阐述了整体架构设计，包括Agent主控制器、Planner决策模块、Memory记忆系统、Tool工具集和Environment环境交互层。通过抽象基类定义了各模块接口，并实现了基于OpenAI的LLMPlanner决策模块、SimpleMemory短期记忆系统以及示例CalculatorTool计算工具。该框架遵循ReAct范式，支持Agent循环进行" 阅读详情

最近，越来越多的朋友（包括一些传统行业的朋友）来问，“什么是AI Agent 智能体”、“OpenClaw牛在哪里”、“AI Agent框架到底选哪个”，甚至有许久没联系的大学好友也发来OpenClaw链接"快来研究研究"。毫无疑问，年初火爆现在热度依旧持续的OpenClaw为AI Agent带来了新的想象

如果说2025是AI Agent智能体元年，想必2026将会是AI Agent商用化的元年。而AI Agent商用化的前提是各行各业开始落地实际商业业务的AI Agent。

作为一名程序员/工程师，思考的更多的可能是如何将AI Agent落地实现的层面。工程框架往往是工程应用实现的基石，框架选型也是架构师们设计与实现一个AI Agent智能体的首要工作。作为一篇"深度"文章，依旧是先理论分析（第1章、第2章），然后代码实践（第3章）。由于篇幅过长，本文将分文两个部分来写：理论篇与实践篇

本文目录结构：

1、AI Agent 主流框架分析
2、AI Agent 框架的核心
3、从零开始实现一个 AI Agent 框架 -> 见实践篇

注：实践派们可以直接跳转到第3节。实践派可以直接阅读实践篇。

1、AI Agent 主流框架分析

1.1 Agent = Reasoning + Acting

AI 智能体是使用 AI 来实现目标并代表用户完成任务的软件系统。其表现出了推理、规划和记忆能力，并且具有一定的自主性，能够自主学习、适应和做出决定。

Google Cloud

关于AI Agent这里引用了Google Cloud的定义，言简意赅，Agent主要功能是推理（Reasoning）与执行（Acting）。

推理：依赖LLM，核心思想是CoT（Chain of Thought）
执行：指外部工具的执行，具体依赖宿主机的执行环境与应用场景

现在主流的Agent框架虽然有各种演绎与变形（如Plan&Execute以及Reflection模式），但核心思想仍是ReAct：将推理与执行结合起来

LLM中的Agent是指利用LLM的模型处理能力，创建能自主执行任务的智能体。在当前LLM-based的Agents智能体中，最具有基础性与代表性的要数ReAct框架，它是Yao等人于2022年在《ReAct: Synergizing Reasoning and Acting in Language Models》论文中提出，核心思想将推理（Reasoning）和行动（Acting）相结合。CoT提升的是LLM的推理能力，但它的缺点在于缺少与外部世界的交互从而缺少外部反馈来拓展自身的知识空间，ReAct弥补了这一缺陷。

yabohe，公众号：yablog降低LLM幻觉的通用工程技术框架：从RAG到Agent，从MCP到A2A

1.2 主流 AI Agent 框架对比

当前主流Agent框架主要包含以下几种：

LangChain - 最成熟和流行的框架之一，提供丰富的工具链和集成，适合快速构建复杂的AI应用。支持多种LLM、向量数据库和工具调用，有完善的文档和社区支持。
LlamaIndex - 专注于数据索引和检索，特别擅长RAG（检索增强生成）场景。提供高效的文档处理和查询能力，适合知识密集型应用。
AutoGPT/AutoGen - 微软推出的多Agent协作框架，支持多个Agent之间的对话和协作，可以处理更复杂的任务分解和执行。
CrewAI - 专注于角色扮演型Agent的协作框架，每个Agent有明确的角色和目标，适合模拟团队协作场景。
LangGraph - LangChain团队开发的状态图框架，提供更精细的流程控制，适合构建复杂的、需要明确状态管理的Agent应用。
Semantic Kernel - 微软的轻量级框架，与Azure服务集成良好，支持多种编程语言，强调插件化设计。

个人选择建议

如果是想快速出Agent原型，可以试试LangChain；
如果是构建RAG应用，则强烈建议LlamaIndex；
如果业务场景为多Agent协作，推荐AutoGen或CrewAI，它们是专为多智能体协作而生的；
如果业务中涉及复杂的流程控制，建议使用LangGraph，通用性好，基于状态管理的workflow灵活性高；
如果工作环境围绕.NET生态展开的，那搭配Semantic Kernel是最佳选项。

随着Anthropic公司的Claude Cowork AI通用Agent兴起，一些基于通用Code Agent sdk（如Claude Agent SDK等）的套壳Agent也开始流行（如笔者之前分享的Multica Agent架构解析：通用Agent开源套壳应用），这些Agent的创新之处在于可以针对各类用户场景提供更好的交互设计与工作流场景解决方案。

2、AI Agent 框架的核心

虽然当前Agent发展从ReAct模式逐渐转向CodeAct模式(详见《Executable Code Actions Elicit Better LLM Agents》论文，文末有链接)，但是Agent本质的推理与执行功能并没有变化。

在工程层面来说，推理本质就是LLM Call，执行本质则是"Function" Call（即Tools），而连接这二者的上下文工程（Context Engineering）则是Agent框架的核心。

2.1 Agent 框架三大部分

下面我们来拆解一下Agent在工程上的解法，主要包括三大部分

LLM Call：这部分为API管理的范畴，通常情况下，主要工作是兼容各大LLM厂商的API实现细节以及流式输出等基础能力，为Agent框架提供一个标准化的API调用。
Tools使用：这部分主要是LLM如何使用外部工具，从最早的Function Call到后来的MCP以及当前的Skill部分内容（涉及工具调用的那部分）都属于这一范畴。当前Tools的主流形式包括文件操作、网络搜索、Bash命令以及API/MCP调用等，根据Agent具体使用场景而定，也可以后续增删改。
上下文工程：狭义的上下文工程特指提示词Prompt的工程实现（如Rules、Claude.md以及AGENTS.md等），而广义上的上下文工程其实也包含LLM使用外部工具这部分（比如Skills，它是工具与提示词结合的典范）。

以上Agent三大部分中，第1部分的LLM Call基本上没有啥工程变量，这块的工程实践中LiteLLM库（它是一个Python 库，旨在简化多种大型语言模型（LLM）API 的集成）已经是佼佼者了；第2部分的Tools使用，包含的工具列表范围也有业内最佳实践，具体取决于Agent使用的业务场景。

剩下的最大的一个变量是第3部分的上下文工程，这也是Agent智能的核心所在。OpenClaw的爆火出圈除了将手机即时应用与Agent结合这点之外，它的上下文工程的管理也非常有创新（详见：OpenClaw（原Clawdbot）是如何构建上下文工程的）。

近日，腾讯的姚顺雨（ReAct论文作者）团队在腾讯混元官网发表了一篇名为《从 Context 学习，远比我们想象的要难》的文章，提出“模型想要迈向高价值应用，核心瓶颈就在于能否用好 Context。”的观点（混元研究博客上线姚顺雨团队最新成果：从 Context 探索语言模型的范式转变）。正如文中所言"在不提供任何 Context 的情况下，最先进的模型 GPT-5.1 (High) 仅能解决不到 1% 的任务"。如果说Agent应用中，现在哪里还是低垂的果实可以摘取，那便是上下文工程（Context）。

简单总结为一句话：Agent应用中上下文工程大有可为（仍有很大优化空间）。

2.2 Agent Loop

在2.1小节中我们讨论了Agent框架的核心是上下文工程，而上下文工程的核心引擎或者称之为运行框架则是Agent Loop。

Agent Loop本质是一个While循环，每一次迭代是一次LLM推理外加工具调用和上下文处理，也就是说所有Agent行为的发生都是在这个While循环里面，直到任务完成退出。

典型的工作流程如下：

初始上下文（系统提示词+用户请求）
↓
[agent loop开始]
↓
agent读取上下文 → 思考 → 决定行动
↓
执行工具/行动 → 获得结果
↓
结果追加到上下文
↓
[循环继续或结束]

细分到While循环到每一次迭代（turn）可表示为：

初始化上下文（用户请求）
↓
┌─────────────────────────────────┐
│  Agent Loop                     │
│                                 │
│  ┌─────────────────────┐        │
│  │ Turn 1              │        │
│  │  LLM Call 推理 #1            │
│  │  → 解析LLM响应        │        │
│  │  → 执行工具1          │        │
│  │  → 返回结果，更新上下文 │        │
│  └─────────────────────┘        │
│           ↓                     │
│  ┌─────────────────────┐        │
│  │ Turn 2              │        │
│  │  LLM Call 推理 #2    │        │
│  │  → 执行工具2          │        │
│  │  → 返回结果，更新上下文 │        │
│  └─────────────────────┘        │
│           ....                  │
└─────────────────────────────────┘
↓
完成(当某一次Turn不再执行工具即表示完成，返回所有结果信息）

Agent Loop通过在每次迭代中读取、利用和更新上下文来完成任务；上下文工程则是设计如何组织、管理和优化这些上下文信息以提升Agent的决策质量和效率。

回到本篇的主题，可总结为一句话：Agent框架设计的核心就是在Agent Loop这个While循环中设计如何管理上下文。

看上去是不是很简单，实际上也确实如此。

预告一下：第二篇（实践篇）则是基于当前理论，从零开始直接上代码实现一个AI Agent框架。

References