Zui近这段时间，技术圈子里Zui火的话题莫过于 OpenClaw 了。说实话，我也没Neng免俗，第一时间就去凑了个热闹。kan着 GitHub 上那飙升的 Star 数，还有社区里热火朝天的讨论，谁不想赶紧把这个强大的 Agent 框架弄到手，跑两个 Demo 炫耀一下呢？

但是当你真的把代码 Clone 下来配好那一堆让人眼花缭乱的环境变量，kan着终端里终于跑出第一行 Log 时心里除了那一瞬间的兴奋，是不是还夹杂着一种莫名的空虚？这就好比你刚买了一辆顶配的法拉利，引擎轰鸣声确实好听，但Ru果有人问你这辆车的 V12 引擎进气歧管为什么这么设计，涡轮迟滞是怎么优化的，你只Neng挠挠头说：“因为说明书上这么写的。”

这就是我想和大家探讨的核心问题：我们到底是在使用一个工具，还是在理解一项技术？

与其费劲心思去维护一个庞大且复杂的“黑盒”，不如换个思路，咱们从零开始，亲手造一个轻量级的轮子。我给它取了个名字，叫 LiteClaw。这可不是 OpenClaw 的什么 Fork 版本，也不是为了省事而Zuo的精简版。它geng像是一场实验，一次对 Agent 本质的探索之旅。我们的目标hen明确：用 TypeScript，一步步复刻 OpenClaw 的那些核心Neng力，但每一步dou要走得明明白白，每一行代码dou要经过我们的大脑。

别Zuo“调包侠”，Zuo架构师

hen多人在搭建系统时容易陷入一种“拿来主义”的陷阱。kan到现成的库就想直接用，结果就是业务代码和第三方库的耦合度极高，一旦需要升级或者替换，整个系统就像推倒多米诺骨牌一样崩溃。

在构建 LiteClaw 的过程中，我深刻体会到了“依赖抽象，不依赖实现”的重要性。举个Zui简单的例子，我们在处理对话存储时不应该直接把 Redis 或者 Map 的 API 写死在业务逻辑里。

来kankan这段代码，虽然简单，却蕴含了架构设计的精髓：

interface ConversationStore {
  // 获取历史对话上下文
  getConversation: Promise;
  // 追加新的交互记录
  appendExchange: Promise;
  // 重置会话状态
  resetConversation: Promise;
  // 这里还Ke以
geng多Neng力...
}

你kan，业务代码只需要盯着这个接口kan。至于底层到底是用简单的内存 Map 来存数据，还是为了持久化上了 Redis，甚至未来要换成 MySQL，对上层业务来说完全是个黑盒，是透明的。这种设计思想在 OpenClaw 中肯定也有体现，但Ru果你只是去跑它的 Demo，你hen难感同身受这种解耦带来的灵活性。只有自己亲手把接口定义出来你才会真正明白什么叫“高内聚、低耦合”。

拒绝“一口吃成胖子”，分阶段进化

现在的开源项目，动不动就追求大而全，恨不得把所有功Nengdou塞进第一个版本里。这对于学习者来说简直是灾难。你还没搞懂它是怎么接收消息的，它就Yi经开始Zuo复杂的任务规划了。

LiteClaw 的设计哲学完全不同：不一口气Zuo完，而是分 Phase 递进。

我们把整个构建过程拆解成了若干个阶段，每个阶段只解决一个核心问题，而且每个阶段结束后的产物，dou是Ke以独立运行、kan得见摸得着的。

Phase 1：让消息“活”起来

这一步的目标非常朴素，甚至有点“原始”：验证消息Neng进来、模型Neng调用、结果Neng回去。

别小kan这一步。hen多新手在搭建 Agent 时往往在第一步就被各种复杂的中间件和配置劝退了。在这个阶段，我们不需要考虑什么复杂的记忆管理，也不需要工具调用。我们只需要一个Zui简单的闭环：用户发一句话，我们的系统Neng接住扔给大模型，再把大模型的废话还回去。

当你完成 Phase 1 之后你手里握着的就不再是一堆乱码，而是一个真正Neng在飞书上跟你插科打诨的机器人了。这种即时反馈的成就感，是驱动你继续下去的Zui大动力。

Phase 2：从“单轮对话”到“多步任务”

这是 Agent Zui关键的一次跃迁。Phase 1 完成后LiteClaw 还只是一个有点智障的“聊天机器”，但到了这一步，它要进化成Neng自主决策并执行动作的 Agent 了。

这里的核心设计就是 Agent Loop。以前我们写代码，可Neng习惯手写一个 `while` 循环，然后在里面判断什么时候该停。但在 LiteClaw 中，我选择了geng现代的方案——利用 Vercel AI SDK 的Neng力。

通过 `generateText` 配合 `stopWhen)`，我们Ke以非常优雅地控制多轮循环，而不需要去写那些容易出错的底层控制逻辑。同时我们依然保留了自己的 Tool Registry，通过一个 `toAISDKTools` 的桥接层，把我们的工具格式转换成 AI SDK Neng听懂的语言。

这个过程就像教孩子Zuo事。一开始他只Neng听懂指令，现在他学会了思考步骤，甚至自己决定先迈左脚还是先迈右脚。

Phase 3：补齐完整 Agent Neng力

到了这个阶段，我们的目标就变了：从“Neng跑的 demo”升级成“可持续迭代的服务底座”。

这时候，我们才开始引入真正的记忆机制。之前的“记忆”可Neng只是Zui近 N 轮对话的简单数组，真正的 Agent 需要geng长久、geng结构化的存储。我们开始关注 RAG，开始关注如何让 Agent 准确地调用外部 API。

工具：Agent 的双手

一个只会聊天的 AI 是无聊的，一个Neng干活的 AI 才是 Agent。在 LiteClaw 中，新增工具的流程被我简化到了极致，目的就是让你把注意力集中在工具本身的逻辑上，而不是配置文件上。

你只需要三步，就Neng赋予 Agent 一项新技Neng。咱们来kankan这段 TypeScript 代码，感受一下这种丝滑的开发体验：

// 1. 创建工具文件 src/services/tools/my-tool.ts
import { z } from "zod";
import type { LiteClawTool } from "../tools.js";
export const myTool: LiteClawTool = {
  name: "my_tool",
  description: "工具描述",
  parameters: z.object({
    query: z.string.describe
  }),
  async run {
    // 在这里写你的业务逻辑，查数据库、调接口随便你
    return { text: "这是工具执行的结果" };
  }
};
// 2. 在 tools.ts 中注册，就像把新武器放进军火库
// 3. 搞定。模型会自动发现并使用新工具，无需额外配置

想象一下这样的场景：用户问“现在北京几点了？”

系统内部会立刻发生一连串化学反应：

LLM 判断这小子想知道时间，我需要调用 current_time 工具。

Runtime 执行立刻调度 current_time。

工具返回拿到结果 "2023-10-27 14:30:00"。

LLM 组织语言基于这个结果，生成自然的回复：“现在是北京时间下午两点半。”

这一切发生得行云流水，而你作为开发者，只需要定义好工具的“说明书”和“动作”。

技术栈：老炮儿们的选择

在构建 LiteClaw 时对于技术栈的选择，我可是相当挑剔的。毕竟我们的目标是“理解”，而不是“凑合”。下面这张表列出了我的选择和理由，你Ke以kankan是不是也戳中了你的痛点：

技术领域	选择方案	为什么选它？
开发语言	TypeScript	类型安全是大型项目的基石，前后端统一语言Neng减少认知负担，别再为类型转换头疼了。
运行环境	Node.js + Hono	Node.js 成熟稳定，生态无敌；Hono 极其轻量，性Neng爆表，特别适合Zuo这种对响应速度要求高的 Agent runtime。
AI SDK	Vercel AI SDK	内置了强大的 tool calling 和 agent loop 支持，省去了我们造轮子的时间，专注于业务逻辑。
模型适配	OpenAI-compatible	灵活！太灵活了！无论是 Qwen、DeepSeek 还是其他本地模型，只要接口对得上，douNeng无缝切换。
数据校验	Zod	工具参数验证的神器，而且和 AI SDK 原生支持，配合起来简直天衣无缝。
平台集成	飞书长连接	零公网依赖，在本地就Neng联调，这对于开发体验的提升是巨大的，不用每次dou部署到云端测。
存储方案	Memory / Redis	可切换设计。开发时用内存图个快，上线时切 Redis 图个稳，渐进式引入，不折腾。

别光kan，动手试试

说了这么多，不如代码来得实在。LiteClaw 的所有代码douYi经托管在 GitHub 上了每个 Phase dou有独立的技术文档，哪怕你是刚入门的小白，也Neng照着猫画虎。

Ru果你想快速体验一下只需几行命令：

# 1. 把代码拉下来
git clone https://github.com/WarrenJones/liteClaw.git
cd liteClaw
# 2. 装个依赖
pnpm install
# 3. 配置一下环境变量
cp .env.example .env.local
# 记得把你的飞书 App ID/Secret 还有本地模型地址填进去
# 4. 启动服务
pnpm dev
# 5. 打开飞书，给机器人发个消息试试水
# "现在几点了？"  → kankan它会不会自动调用 current_time 工具
# "/status"       → 查kan运行时状态，监控它的“心跳”
# "/tools"        → 查kan它现在手里dou有哪些“武器”

后续的征途

Phase 1 完成后LiteClaw Yi经具备了 Agent 的核心骨架，但这只是开始。真正的 Agent 不只是“Neng回复消息”，它还需要geng广阔的视野。

后续我们还有三个大方向要去探索：

geng深度的记忆如何让 Agent 记住你上周说过的话？如何从海量文档中提取关键信息？这需要引入向量数据库和 RAG 技术。

geng复杂的规划现在的 Agent 可Neng只Neng处理简单的任务，未来我们要让它Neng拆解复杂的目标，比如“帮我策划一次旅行并预订机票”，这需要强大的任务拆解Neng力。

geng人性化的交互不仅仅是文字，未来Neng不Neng支持图片、语音？甚至主动发起对话？

写在Zui后

大家dou在忙着装 OpenClaw，但我选择自己实现一个。这并不是因为 OpenClaw 不好，相反，它非常优秀。我只是觉得，只有当你亲手造过一遍之后你才真正拥有它。

你会发现，当你走完所有 Phase 之后你手上拥有的不仅仅是一个Neng跑的 Agent，而是一个你理解每一行代码、每一个设计决策的系统。那种掌控全局的感觉，是任何现成的框架dou给不了的。

所以别再犹豫了。与其 clone 一个跑不起来的庞然大物，不如从零造一个真正理解的 Agent。哪怕一开始它hen简陋，hen笨拙，但那是你亲手赋予的生命。欢迎来 GitHub 上 Star、Fork，或者提 Issue 咱们一起聊聊。让我们一起，把 Agent 的黑盒，变成透明的玻璃房子。

---