在 LLM 应用的技术演进中，Andrej Karpathy 最近提出了一个引人深思的概念：Claws。这一概念指向了 AI 技术栈中尚未被明确定义的第三层 —— 一个位于 LLM Agent 之上的持久化基础设施层。本文将深入解析这一架构的设计理念、分层职责，并给出可落地的工程参数与实现路径。
从模型调用到 Agent 再到 Claws：三层技术栈的演进
理解 Claws 的定位，需要回顾 AI 应用开发范式的演进过程。最初，开发者直接调用 LLM 的 chat completion API，仅利用模型的下一个 token 预测能力生成文本。这一阶段的特征是：无状态、单轮交互、每次请求都需要携带完整的上下文。
随后，LLM Agent 的出现改变了这一局面。Agent 本质上是一个循环结构，它维护工作上下文（包括 system prompt、scratchpad 和短期记忆），在每一次迭代中执行「思考→行动→观察」的闭环。Agent 能够调用外部工具 —— 无论是 API、代码执行器、搜索引擎还是数据库查询 —— 来实现更复杂的目标。这种架构使得 AI 从被动响应转向主动规划与执行。
然而，Karpathy 敏锐地观察到，仅有 Agent 仍然不够。当我们需要构建「个人数字助手」类型的应用时 —— 它们需要全天候运行、能够通过多种渠道（Slack、Discord、Email、Webhook）与人交互、需要跨会话保持状态、需要调度定时任务 —— 原有的 Agent 架构就显得力不从心。这正是 Claws 层的价值所在：它位于 Agent 之上，提供持久化、编排、调度和工具路由的能力，让 Agent 能够像后台服务一样可靠运行。
工具调用究竟属于哪一层：澄清一个关键误解
在理解 Claws 架构时，一个常见的混淆是：工具调用（tool calling）本身究竟属于 Agent 层还是 Claws 层？根据 Karpathy 的定义，工具调用发生在 Agent 层，而非 Claws 层。
具体而言，Agent 循环负责决定何时调用工具、调用哪个工具、以及传递什么参数。这些决策基于 Agent 的内部推理和目标分解。Claws 层则聚焦于 Agent 循环之外的一切：启动和停止 Agent 实例、在多个 Agent 之间路由消息和事件、序列化和恢复 Agent 状态以实现断点续传、管理跨会话的队列和并发保证、以及处理外部集成的安全边界和通道规范化。
这种职责划分具有重要的工程意义：它保持了 Agent 的「大脑」轻量且可移植，同时将可靠性、正常运行时间和生态系统集成的复杂性隔离到独立的 Claws 层中处理。
Claws 层的核心职责：四个关键维度
根据 OpenClaw 参考实现和社区讨论，Claws 层承担以下核心职责：
第一，调度与编排。 Claws 负责管理一个或多个 Agent 的生命周期，包括定时任务（类似 cron 的工作流）、多 Agent 通信和状态转换。它可以是单实例运行，也可以是多租户集群部署。
第二，长上下文与记忆管理。 Claws 维护跨会话的持久状态：对话历史、日志、向量存储的记忆、以及文件类型的 Artifacts。这使得 Agent 能够在重启后恢复之前的工作上下文，实现真正的「持久化」。
第三，工具接线与路由。 虽然工具调用的执行逻辑在 Agent 内部，但 Claws 负责工具的注册、版本管理、路由和安全边界。它可以动态加载或卸载工具集合，适应不同任务的工具需求。
第四，多渠道集成。 Claws 作为统一的网关，接收来自 Slack、Telegram、Email、Webhook 等不同渠道的请求，将其规范化为统一的内部事件格式，然后路由到合适的 Agent 实例处理。
OpenClaw 的四层架构启示
OpenClaw 作为这一概念的先行实现，提供了具象化的架构参考。它采用网关（Gateway）、执行（Execution）、集成（Integration）和智能（Intelligence）四层结构，围绕现有的 Agent 运行时构建。
网关层处理连接、认证和消息路由；执行层负责任务排序和并发管理（通过 Lane Queue 实现会话级别的串行执行，保证安全）；集成层负责平台规范化，将外部事件转换为内部统一格式；智能层定义 Agent 的行为模式、技能和可用工具。这种分层方式清晰地划定了各层的职责边界，为工程实现提供了可操作的参考模型。
可落地的工程参数与设计建议
如果读者希望基于这一架构设计自己的系统，以下是可参考的关键参数和设计要点：
状态持久化策略。 建议采用双层存储：短期状态（如 Agent 运行时上下文）使用内存或 Redis 缓存，配合定期快照到磁盘；长期记忆（如向量数据库中存储的用户偏好和知识）使用专门的向量存储服务。状态序列化的频率可根据业务对断点续传的需求程度调整，通常建议每完成一个完整的 Agent 循环或每 5 分钟执行一次持久化。
并发控制参数。 为了避免多线程环境下的状态竞争，建议对每个用户会话使用独立的执行队列。并发数的上限可根据后端 LLM 的速率限制和资源预算设定，常见值为 5 到 20 个并发任务。背压（backpressure）策略可采用任务排队加超时放弃的模式，超时阈值建议设置为 120 秒到 300 秒。
工具集成的安全边界。 Claws 层应当作为内部 Agent 与外部系统的防火墙。所有外部工具调用都应经过 Claws 的代理，并实施权限检查和调用审计。建议为敏感工具（如数据库写操作、支付接口）配置额外的确认机制。
多渠道消息的规范化格式。 建议定义统一的内部消息 Schema，包含来源渠道、原始消息内容、时间戳、用户标识和会话标识等字段。Claws 的集成层负责将各渠道的消息格式转换为这一统一格式。
监控与可观测性。 建议采集以下核心指标：Agent 循环的迭代次数和平均耗时、工具调用的成功率与平均延迟、Claws 层的请求吞吐量和队列深度、以及各渠道的消息分布。日志应当包含请求链路追踪，便于排查跨层问题。
结语
Claws 架构的提出，为 LLM Agent 的工程化落地提供了一层清晰的基础设施抽象。它并非要替代 Agent，而是补足了构建生产级、持久化、多渠道 Agent 应用所需的基础能力。随着 NanoClaw（约 4000 行代码的可审计实现）等项目的探索，这一层的实现路径也日益清晰。对于希望在生产环境中部署 AI Agent 的团队而言，理解并合理引入 Claws 层的职责，将是提升系统可靠性和可维护性的关键一步。
参考资料
- Andrej Karpathy 关于 Claws 的原始推文（2026 年 2 月）
- Simon Willison 对 Claws 概念的解读与分析