从 OpenClaw 到 nanobot：万字深扒 AI Agent 架构的极简革命

qq_32949095

705人浏览 · 2026-03-27 21:29:40

qq_32949095 · 2026-03-27 21:29:40 发布

从 OpenClaw 到 nanobot：万字深扒 AI Agent 架构的极简革命

当一个框架用 99% 更少的代码实现同样的功能，它一定做对了什么。

00 | 写在前面

2026年2月，一个叫 OpenClaw 的开源项目在 GitHub 上爆火。

72小时内，它收获了 60,000 颗星。

一个月后，这个数字变成了 247,000。

它是 GitHub 历史上增长最快的开源项目。

为什么？

因为它做了一件很多人想做但不敢做的事：

让 AI 从"聊天工具"变成"自主代理"。

不是陪你聊天的 ChatGPT。

是能帮你发邮件、写代码、管日程、监控服务器的 AI 员工。

而今天要讲的 nanobot，是 OpenClaw 的"极简版"。

用 99% 更少的代码，实现了 OpenClaw 的核心功能。

这是怎么做到的？

它的架构有什么不同？

这篇文章会给你答案。

架构预览：OpenClaw vs nanobot

nanobot 是如何通过"路径缩短"来实现极简化的？

一眼就能看出区别：

OpenClaw 有 7 层，nanobot 只有 3 层。

但功能却差不多。

这就是"极简革命"的精髓。

01 | 先搞清楚：什么是 AI Agent？

在聊架构之前，先搞清楚概念。

AI Agent 和 Chatbot 有什么区别？

维度	Chatbot	AI Agent
交互方式	一问一答	自主执行
能力边界	只能聊天	能调用工具
记忆	无/短期	长期记忆
主动性	被动响应	主动行动
典型代表	ChatGPT	OpenClaw

举个例子：

你说"帮我订一张明天去北京的机票"。

Chatbot 会说：“好的，我建议你下载携程或去哪儿 App 进行预订。”

AI Agent 会直接打开携程，查询航班，选择合适的时间，用你的支付方式完成预订，然后把订单信息发给你。

Chatbot 是顾问，AI Agent 是助理。

这就是本质区别。

02 | OpenClaw 的五层架构

要理解 nanobot，先理解 OpenClaw。

OpenClaw 的架构分为五层：

┌─────────────────────────────────────────┐
│         Layer 1: Input Sources          │
│   Telegram / WhatsApp / Discord / CLI   │
├─────────────────────────────────────────┤
│       Layer 2: Integration Gateway      │
│     Message Routing / Session Mgmt      │
├─────────────────────────────────────────┤
│           Layer 3: Agent Core           │
│  LLM / Memory / Tools / Execution       │
├─────────────────────────────────────────┤
│       Layer 4: Output / Action          │
│      Message Delivery / HITL Gates      │
├─────────────────────────────────────────┤
│        Layer 5: External Systems        │
│    Files / APIs / Browser / Shell       │
└─────────────────────────────────────────┘

Layer 1: Input Sources（输入层）

用户从哪里和 Agent 交互？

Telegram
WhatsApp
Discord
Slack
Feishu
Email
CLI（命令行）

OpenClaw 的设计理念是：你用什么聊天，Agent 就在哪等你。

不需要打开新 App。

就像和一个真人朋友聊天一样。

Layer 2: Integration Gateway（网关层）

这一层负责：

消息路由：把用户消息转发给 Agent Core
会话管理：记住你是谁，聊到哪了
权限控制：谁能和 Agent 交互

关键设计：多通道统一。

不管你从 Telegram 还是 WhatsApp 发消息，Agent Core 只看到一个统一的输入流。

Layer 3: Agent Core（核心层）

这是整个系统的心脏。

包含四个子模块：

模块	职责
LLM Engine	调用大模型（Claude/GPT/DeepSeek…）
Memory	存储对话历史、用户偏好、任务状态
Tools	文件操作、Shell 命令、API 调用
Execution Loop	感知 → 推理 → 行动 → 反馈

Execution Loop 是核心中的核心。

while True:
    message = receive_message()      # 感知
    thought = llm.think(message)     # 推理
    action = decide_action(thought)  # 决策
    result = execute(action)         # 执行
    send_response(result)            # 反馈

这个循环不断运行，Agent 就"活"了。

Layer 4: Output / Action（输出层）

Agent 决定要做什么之后，这一层负责执行：

发消息回用户
写入文件
调用外部 API
触发工作流

关键设计：Human-in-the-Loop（HITL）

敏感操作（发邮件、删文件、转账）需要人工确认。

Agent 先起草，人审核，再执行。

Layer 5: External Systems（外部系统）

Agent 能访问什么？

文件系统：读/写本地文件
Shell：执行命令行
浏览器：自动化网页操作
API：调用任何 HTTP 接口

这就是 OpenClaw “能做事” 的原因。

它不是被困在聊天窗口里的 AI。

它是能操作你电脑的 AI。

03 | nanobot 的极简革命

现在问题来了：

OpenClaw 有 10 万行代码。

nanobot 只有 1000 行。

它是怎么做到的？

核心思路：删掉一切"不必要"的

OpenClaw 的设计目标是"功能全面"。

nanobot 的设计目标是"刚好够用"。

功能	OpenClaw	nanobot
多通道支持	10+	10+
MCP 协议	✅	✅
记忆系统	复杂	简化
子代理	✅	✅
定时任务	✅	✅
代码行数	~100,000	~1,000

nanobot 的哲学：

如果一个功能可以用 10 行代码实现，就不要写 100 行。

架构对比

OpenClaw 的架构：

Channel Adapter → Message Bus → Session Manager → Agent Loop → Tool Executor
                      ↓
                 Memory System (复杂)
                      ↓
                 Skill System (复杂)
                      ↓
                 Subagent Orchestrator

nanobot 的架构：

Channel Adapter → Agent Loop → Tool Executor
                      ↓
                 Memory (简化)
                      ↓
                 Skills (简化)

区别在哪？

去掉 Message Bus：直接在 Channel Adapter 里调用 Agent Loop
简化 Memory：用文件存储，不用向量数据库
简化 Skills：用约定代替配置
去掉复杂的编排层：让 LLM 自己决定要不要调用子代理

nanobot 的核心代码结构

nanobot/
├── agent/          # 核心逻辑（~300行）
│   ├── loop.py     # Agent Loop
│   ├── context.py  # Prompt 构建
│   ├── memory.py   # 记忆管理
│   └── tools/      # 内置工具
├── channels/       # 通道适配器
├── providers/      # LLM 提供商
└── cli/            # 命令行

核心代码就这么多。

剩下的都是配置和工具。

04 | Agent Loop：AI 的"心跳"

Agent Loop 是整个系统的心脏。

让我们看看 nanobot 是怎么实现的。

Agent Loop 逻辑流

伪代码

async def agent_loop(user_message, context):
    # 1. 构建上下文
    prompt = build_prompt(user_message, context)
    
    # 2. 调用 LLM
    response = await llm.chat(prompt)
    
    # 3. 解析响应
    if response.has_tool_call():
        # 4. 执行工具
        tool_result = await execute_tool(response.tool_call)
        
        # 5. 把结果喂回 LLM
        return await agent_loop(tool_result, context)
    else:
        # 6. 返回最终答案
        return response.content

关键点：

循环执行：如果 LLM 决定调用工具，执行完后继续调用 LLM
上下文传递：每次循环都带上之前的对话历史
工具调用：LLM 决定调用什么工具，Agent Loop 负责执行

为什么这么简单？

因为复杂的推理工作交给 LLM 了。

Agent Loop 只负责三件事：

把信息喂给 LLM
执行 LLM 的指令
把结果喂回去

这就是"智能"的来源。

LLM 是大脑，Agent Loop 是手脚。

05 | Memory：AI 的"记忆"

没有记忆的 Agent，每次对话都是新的。

它不知道你昨天说了什么。

它不知道你的偏好。

它不知道之前做了什么。

Memory 是 Agent 从"工具"变成"伙伴"的关键。

Memory 的三个层次

层次	名称	存什么	存多久
1	工作记忆	当前对话	会话内
2	情景记忆	具体事件	跨会话
3	语义记忆	用户偏好、知识	长期

OpenClaw 的 Memory 设计

OpenClaw 使用了复杂的记忆系统：

向量数据库：存储和检索语义相似的记忆
分层存储：短期记忆在内存，长期记忆在磁盘
自动摘要：定期把对话压缩成摘要

nanobot 的 Memory 设计

nanobot 选择了极简方案：

用 Markdown 文件存储记忆。

~/.nanobot/workspace/
├── MEMORY.md        # 长期记忆
├── memory/          # 每日笔记
│   ├── 2026-03-27.md
│   └── 2026-03-26.md

MEMORY.md 示例：

# MEMORY.md - 长期记忆

## 用户偏好
- 喜欢简洁的回复
- 工作时间：9:00-18:00
- 时区：Asia/Shanghai

## 重要事件
- 2026-03-01：开始使用 nanobot
- 2026-03-15：配置了 Telegram 通道

nanobot 为什么放弃向量数据库？

2026 年，当 Claude 和 Gemini 的上下文窗口轻松处理 200 万 token 时，RAG（检索增强生成）在个人助理场景下变得不再是"刚需"。

nanobot 敏锐地抓住了这一点：

既然用户一年的聊天记录和笔记加起来也不到 50 万字，为什么不直接让 LLM 自己去"翻" Markdown 文件呢？

这种"回归原始"的背后，是对模型推理能力的极度自信。

为什么这样设计？

简单：不需要数据库，不需要向量检索
可读：人可以直接查看和编辑
长文本红利：2026 年大模型长文本能力的普惠，让直接塞进上下文成为可能

代价是什么？

不能做语义搜索（但 LLM 可以自己"翻"文件）
记忆多了会变慢（但个人场景下通常不会超过 50 万字）
不适合大规模部署（但 nanobot 的目标用户是个人，不是企业）

所以这个 trade-off 是合理的。

nanobot 的极简记忆方案得益于 2026 年大模型长文本能力的普惠，既然能直接塞进上下文，何必再搞复杂的向量检索？

06 | Tools：AI 的"手脚"

没有工具的 Agent，只能聊天。

有了工具，它能：

读写文件
执行命令
搜索网页
调用 API
发送消息

Tool 的本质

Tool 就是一个函数。

LLM 决定调用哪个函数，传什么参数。

Agent Loop 负责执行，把结果返回给 LLM。

示例：

@tool
def read_file(file_path: str) -> str:
    """读取文件内容"""
    with open(file_path, 'r') as f:
        return f.read()

@tool
def write_file(file_path: str, content: str) -> str:
    """写入文件"""
    with open(file_path, 'w') as f:
        f.write(content)
    return f"已写入 {file_path}"

LLM 看到的：

{
  "name": "read_file",
  "description": "读取文件内容",
  "parameters": {
    "type": "object",
    "properties": {
      "file_path": {
        "type": "string",
        "description": "文件路径"
      }
    },
    "required": ["file_path"]
  }
}

LLM 的响应：

{
  "tool_call": {
    "name": "read_file",
    "arguments": {
      "file_path": "/home/user/notes.md"
    }
  }
}

Agent Loop 执行这个调用，把文件内容返回给 LLM。

nanobot 的内置工具

工具	功能
`read`	读取文件
`write`	写入文件
`edit`	编辑文件
`exec`	执行命令
`web_search`	搜索网页
`web_fetch`	获取网页内容
`browser`	浏览器自动化
`message`	发送消息

MCP：工具协议的标准化

2026年，Anthropic 推出了 MCP（Model Context Protocol）。

这是一个标准化的工具协议。

为什么重要？

以前，每个 Agent 框架都有自己的工具格式。

LangChain 有 LangChain 的格式。

AutoGPT 有 AutoGPT 的格式。

OpenClaw 有 OpenClaw 的格式。

MCP 统一了这一切。

现在，你可以用同一套工具配置，在 Claude、OpenClaw、nanobot 里使用。

示例配置：

{
  "tools": {
    "mcpServers": {
      "filesystem": {
        "command": "npx",
        "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"]
      }
    }
  }
}

nanobot 原生支持 MCP。

这意味着你可以直接复用 Claude Desktop 的工具生态。

07 | Multi-Agent：递归式协作

nanobot 怎么处理多 Agent 协作？

答案是：递归式调用。

主 Agent 把子 Agent 当成一个特殊的 Tool 来调用。

递归式协作的设计

主 Agent
    ↓ 调用 subagent tool
子 Agent A（搜索专家）
    ↓ 返回结果
主 Agent
    ↓ 调用 subagent tool
子 Agent B（写作专家）
    ↓ 返回结果
主 Agent
    ↓ 整合输出
最终答案

伪代码：

@tool
async def spawn_subagent(task: str, agent_type: str) -> str:
    """生成子 Agent 执行任务"""
    sub_agent = Agent(
        model="claude-sonnet",
        tools=get_tools_for_agent(agent_type)
    )
    result = await sub_agent.run(task)
    return result

为什么这样设计？

简单：不需要复杂的编排引擎
灵活：LLM 自己决定要不要调用子 Agent
统一：子 Agent 就是一个 Tool，和其他 Tool 没区别

代价是什么？

没有显式的协作协议
子 Agent 之间不能直接通信
依赖 LLM 的推理能力来协调

但 nanobot 的哲学是：相信 LLM。

如果 LLM 足够聪明，它会自己决定怎么协调。

08 | Skills：AI 的"技能包"

Tool 是原子能力。

Skill 是组合能力。

举个例子：

read_file 是 Tool
write_file 是 Tool
exec 是 Tool

但"帮你写一篇公众号文章"是 Skill。

它需要：

搜索资料（web_search）
整理思路（LLM 推理）
写成文章（LLM 生成）
保存文件（write_file）

Skill 执行树

nanobot 的 Skill 系统

Skill 就是一个目录：

skills/
└── article-writer/
    ├── SKILL.md      # 技能说明
    ├── references/   # 参考资料
    └── scripts/      # 辅助脚本

SKILL.md 示例：

# Article Writer Skill

## 触发条件
用户要求写文章时

## 执行步骤
1. 搜索相关资料
2. 列出大纲
3. 逐节写作
4. 保存到指定位置

## 输出格式
Markdown 文件，保存到 ~/articles/

Agent 怎么用 Skill？

读取 SKILL.md
把内容加入 Prompt
LLM 按照指引执行

就这么简单。

没有复杂的编排引擎。

LLM 自己会理解指令并执行。

08 | Channels：AI 的"触角"

Agent 要能和人交互，就需要接入各种聊天平台。

这就是 Channel 的作用。

nanobot 支持的通道

通道	协议	特点
Telegram	Bot API	最简单，推荐入门
Discord	Bot API	适合社区
WhatsApp	Baileys	需要扫码绑定
Feishu	WebSocket	国内友好
Slack	Socket Mode	企业友好
Email	IMAP/SMTP	传统但通用
QQ	Bot API	国内生态
Matrix	Client-Server	去中心化

Channel Adapter 的设计

每个 Channel 都有一个 Adapter：

class TelegramAdapter:
    async def start(self):
        # 启动 Telegram Bot
        self.bot = Bot(token=self.config.token)
        await self.bot.start()
    
    async def on_message(self, update):
        # 收到消息时
        message = self.parse_message(update)
        response = await self.agent_loop(message)
        await self.send_response(response)
    
    async def send_response(self, response):
        # 发送回复
        await self.bot.send_message(
            chat_id=self.chat_id,
            text=response
        )

关键设计：

所有 Adapter 都遵循同一个接口。

Agent Loop 不需要知道消息来自哪个 Channel。

它只处理统一的消息格式。

09 | Provider：AI 的"大脑"

Agent 需要调用 LLM 才能"思考"。

Provider 就是 LLM 的适配器。

nanobot 支持的 Provider

Provider	特点
OpenRouter	推荐，支持所有模型
Anthropic	Claude 直连
OpenAI	GPT 直连
DeepSeek	国产，便宜
Gemini	Google 出品
Qwen	阿里出品
Ollama	本地运行
vLLM	本地运行

Provider 的设计

class Provider:
    async def chat(self, messages: list[Message]) -> Response:
        # 调用 LLM API
        response = await self.client.chat(messages)
        return Response(
            content=response.content,
            tool_calls=response.tool_calls
        )

关键设计：

所有 Provider 都遵循同一个接口。

Agent Loop 不需要知道用的是哪个模型。

它只关心"给我一个响应"。

Provider Registry

nanobot 使用 Provider Registry 来管理所有 Provider。

PROVIDERS = {
    "openrouter": ProviderSpec(
        name="openrouter",
        env_key="OPENROUTER_API_KEY",
        litellm_prefix="openrouter",
    ),
    "deepseek": ProviderSpec(
        name="deepseek",
        env_key="DEEPSEEK_API_KEY",
        litellm_prefix="deepseek",
    ),
}

添加新 Provider 只需要两步：

在 Registry 里加一条记录
在 Config Schema 里加一个字段

不需要改任何业务代码。

11 | Heartbeat：AI 的"主动性"

普通的 Chatbot 是被动的。

你不找它，它不找你。

但 Agent 应该是主动的。

它应该能：

定时检查任务
主动提醒你
自动执行计划任务

这就是 Heartbeat 的作用。

nanobot 的 Heartbeat 设计

Gateway 每 30 分钟唤醒一次
        ↓
检查 HEARTBEAT.md
        ↓
有任务？执行并发送结果
        ↓
无任务？返回 HEARTBEAT_OK

HEARTBEAT.md 示例：

## 定时任务

- [ ] 检查天气预报
- [ ] 扫描邮箱紧急邮件
- [ ] 检查服务器状态

执行流程：

Gateway 唤醒
读取 HEARTBEAT.md
对每个任务，调用 Agent Loop
把结果发送到最近活跃的聊天通道

这样，Agent 就能"主动"做事了。

12 | 安全：AI 的"笼子"

让 AI 能操作你的电脑，是一件危险的事。

如果 AI 被黑客控制了呢？

如果 AI 误删了重要文件呢？

如果 AI 执行了危险命令呢？

nanobot 的安全设计

机制	说明
`allowFrom`	白名单，只允许指定用户
`restrictToWorkspace`	限制只能操作工作目录
HITL	敏感操作需要人工确认
API Spending Limit	限制 API 调用费用
Shadow Mode	影子运行，只打印日志不实际执行

Shadow Mode：调试神器

什么是 Shadow Mode？

Agent 执行动作但不实际生效，只打印日志供用户查看。

这是极简框架中非常实用的调试功能。

示例：

{
  "tools": {
    "shadowMode": true
  }
}

效果：

[SHADOW] Would execute: write_file("/home/user/notes.md", "Hello World")
[SHADOW] Would execute: exec("git commit -m 'update'")
[SHADOW] Would execute: send_email("boss@company.com", "Report attached")

用途：

调试：看看 Agent 会做什么，再决定要不要让它真的做
审计：记录 Agent 的所有操作意图
教学：学习 Agent 是怎么"思考"的

其他安全机制

示例配置：

{
  "channels": {
    "telegram": {
      "enabled": true,
      "token": "YOUR_BOT_TOKEN",
      "allowFrom": ["YOUR_USER_ID"]
    }
  },
  "tools": {
    "restrictToWorkspace": true
  }
}

最佳实践：

沙箱运行：用 Docker 容器隔离
专用账户：创建一个专门的 OS 用户
费用限制：设置 API 每日消费上限
人工审核：敏感操作必须确认
Shadow Mode：先调试，再上线

12 | 从 OpenClaw 到 nanobot：架构的取舍

现在我们可以总结一下：

OpenClaw 和 nanobot 的本质区别是什么？

维度	OpenClaw	nanobot
目标用户	企业/高级用户	个人/开发者
功能完整度	全面	精简
代码复杂度	高	低
学习曲线	陡峭	平缓
扩展性	强	中
部署难度	中	低

nanobot 的取舍：

放弃复杂的记忆系统 → 用简单的文件存储
放弃复杂的编排引擎 → 让 LLM 自己决定
放弃企业级功能 → 专注个人场景
放弃性能优化 → 优先代码简洁

这些取舍换来了什么？

1000 行代码：任何人都能读完
快速上手：5 分钟部署
易于定制：想改什么直接改
教学价值：学习 Agent 架构的最佳教材

13 | AI Agent 的未来

nanobot 给了我们一个启示：

Agent 不一定要复杂。

复杂的不是架构，是 LLM 的能力。

LLM 越强，Agent 的架构可以越简单。

2026 年的趋势：

协议标准化：MCP 统一工具接口
模型更强：推理能力持续提升
部署更简单：一键部署成为标配
多模态：Agent 能看能听能说

未来的 Agent 架构可能更简单：

User → LLM → Tools → Done

不需要复杂的编排。

不需要复杂的记忆。

LLM 自己会处理一切。

但今天，我们还需要 nanobot 这样的框架。

它帮我们处理了：

多通道接入
会话管理
工具调用
记忆存储

这些"脏活累活"。

14 | 写在最后

这篇文章写了 nanobot 和 OpenClaw 的架构。

但更重要的是：

它展示了如何"做减法"。

不是功能越多越好。

是刚好够用就好。

nanobot 用 1000 行代码证明：

简单的架构，也能做复杂的事。

如果你是开发者，建议去读读 nanobot 的源码。

它可能是学习 Agent 架构最好的教材。

如果你是用户，试试部署一个 nanobot。

体验一下"AI 助理"的感觉。

未来已来。

只是分布不均。

附录：快速上手 nanobot

安装

pip install nanobot-ai

初始化

nanobot onboard

配置

编辑 ~/.nanobot/config.json：

{
  "providers": {
    "openrouter": {
      "apiKey": "sk-or-v1-xxx"
    }
  },
  "agents": {
    "defaults": {
      "model": "anthropic/claude-sonnet-4-6"
    }
  }
}

运行

nanobot agent

接入 Telegram

{
  "channels": {
    "telegram": {
      "enabled": true,
      "token": "YOUR_BOT_TOKEN",
      "allowFrom": ["YOUR_USER_ID"]
    }
  }
}

nanobot gateway

就这么简单。

nanobot GitHub: https://github.com/HKUDS/nanobot

OpenClaw GitHub: https://github.com/openclaw/openclaw

MCP技术社区

欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！

更多推荐

AI Agent 第二篇：【2026零基础AI教程2】90%开发者都错了！Agent和Workflow不是对立？破除全网经典误区（大厂面试标准答案）

摒弃老旧晦涩的官方定义，给大家一套小白能懂、面试通用、落地可用的全新定义。Workflow是多智能体系统的骨架，Agent是血肉；骨架负责有序结构，血肉负责智能落地，二者共生互补，缺一不可。Workflow与Agent是共生关系，不是二选一；外层人工DAG拓扑 + 内层Agent动态决策；3. Workflow是企业落地主力，稳定可控、合规可追溯，适配90%业务；4. 纯动态Agent仅适用于少量