快速摘要
Clawith 是基于 OpenClaw 架构的开源多智能体协作平台，由 DataElem 团队开发并以 Apache 2.0 协议开源在 GitHub。 它的核心理念是：给每个 AI Agent 赋予持久身份、长期记忆和独立工作空间，让多个智能体在组织内像真人员工一样分工协作。 相比于 OpenClaw 面向个人用户的定位，Clawith 专门解决了多 Agent 协作中的身份认知、任务流转、权限管控和审计追踪等难题。它引入了 Aware 自主感知系统替代传统心跳机制，设计了"广场"知识共享空间，并内置了完善的企业级管控功能。部署门槛极低——2 核 CPU、4GB 内存即可运行，三条 Docker 命令就能启动。往下看有更详细的技术原理拆解、完整部署教程和实际应用场景分析。
为什么需要 OpenClaw 的团队版？
熟悉 AI 智能体领域的朋友应该对 OpenClaw 不陌生。这个由 Peter Steinberger 开发的开源项目，从 2025 年底发布以来经历了 Clawdbot → Moltbot → OpenClaw 三次更名，在 GitHub 上已经积累了超过 24 万个 Star，成为目前最受关注的开源 AI Agent 项目之一。
OpenClaw 的核心能力非常强大：它能给 AI Agent 注入"灵魂"（soul.md 定义个性）和"记忆"（memory.md 保存长期上下文），还能接入飞书、Telegram、Discord、Slack 等主流通讯工具，让你在聊天对话框里用自然语言指挥 Agent 执行各种复杂任务——写代码、收发邮件、操作浏览器、管理文件系统，几乎无所不能。
OpenClaw 的技术架构是基于 TypeScript 编写的命令行应用程序，核心运行机制是一个叫做 Lobster 的智能体循环框架。这个框架实现了"任务分解 → 执行 → 反馈"的循环机制，让 Agent 能够把复杂的用户指令拆解为多个可执行的原子操作，然后逐步完成。它的 Gateway 架构作为控制平面，通过 WebSocket 协议管理所有的消息通道和会话路由，支持同时接入多个不同的通讯平台。用户发来的每条消息都会经过通道适配器的标准化处理，然后路由到对应的 Agent 运行时环境，最终由大语言模型生成响应。
这套架构在个人使用场景下表现出色，能够实现真正的"替你做事"而非仅仅"告诉你怎么做"。但当你试图把它用在团队协作场景时，问题就来了。莫潇羽@源码七号站 在实际测试中发现，OpenClaw 原生架构在团队使用时存在几个关键痛点：
第一个痛点是身份隔离缺失。每个 Agent 都需要独立配置 API Key，GitHub PAT 等凭证散落各处。2026 年 1 月曝出的 CVE-2026-25253 漏洞更是让人意识到，这种"自主可控"的架构在方便的同时也带来了不小的安全隐患。
第二个痛点是缺乏组织认知。多个 Agent 之间互不认识，不知道公司里有哪些人、谁负责什么业务、汇报关系是怎样的。它们就像一群互不相识的临时工，根本无法形成有效的分工协作。
第三个痛点是管控能力不足。没有用量控制机制，Agent 可能无限制地调用大模型 API 导致成本失控；没有审计日志，出了问题找不到是哪个 Agent 的操作引起的；没有审批流程，Agent 可能执行一些危险操作而无人知晓。
正是这些团队场景下的刚需，催生了 Clawith 这个项目。
Clawith 是什么？它和 OpenClaw 的关系
Clawith 的全称定位是"OpenClaw for Teams"，由 DataElem（数据元素）团队开发维护，以 Apache 2.0 开源协议发布在 GitHub 上（仓库地址：https://github.com/dataelement/Clawith ）。DataElem 同时也是 bisheng（毕昇）这个拥有上万 Star 的开源 LLM DevOps 平台的开发者，在 AI 基础设施领域有着深厚的技术积累。
从技术层面来说，Clawith 并不是简单地在 OpenClaw 外面包了一层壳。它保留了 OpenClaw 的灵魂（soul.md）、记忆（memory.md）等核心设计理念，但在底层架构上做了大量重构。整个项目的后端使用 Python 编写，基于 FastAPI 框架，前端则采用 React 19 + TypeScript + Vite 的现代技术栈。数据库支持 PostgreSQL（生产推荐）和 SQLite（快速测试），还集成了 Redis 做缓存。
用一句话概括：OpenClaw 是给个人用的 AI 助理，Clawith 是给团队用的 AI 员工系统。
Clawith 的官方网站是 https://www.clawith.ai/ ，上面有完整的功能介绍和在线演示环境（https://try.clawith.ai ），感兴趣的朋友可以先去体验一下。
核心技术原理深度拆解
接下来，莫潇羽@源码七号站 带大家深入了解 Clawith 的几个核心技术模块。这部分内容比较硬核，但理解了这些原理，你才能真正把这个平台用好。
灵魂与记忆系统：持久化的 Agent 身份
在深入了解 Aware 系统之前，有必要先理解 Clawith 从 OpenClaw 继承的两个基础设计——灵魂（Soul）和记忆（Memory）。这两个机制是整个 Agent 体系的基石。
Soul（灵魂） 对应的是每个 Agent 工作空间中的 soul.md 文件。这不是一段简单的系统提示词，而是一份完整的"人格说明书"，定义了 Agent 的性格特征、价值观、工作风格、沟通方式等内在特质。比如你可以在 soul.md 中写明："你是一个注重细节的 QA 工程师，对任何不完善的东西都会提出改进建议，沟通风格直接但不失礼貌，遇到不确定的问题会主动寻求确认而非擅自假设。"这段描述会成为 Agent 在所有对话和决策中的行为底色，确保它在不同场景下保持一致的"人设"。
Memory（记忆） 对应的是 memory.md 文件以及相关的记忆目录。与会话级别的上下文窗口不同，记忆是持久化存储的。Agent 在每次对话结束后，都会自动提取关键信息写入长期记忆——比如用户的偏好、重要的项目信息、之前做过的决策及其原因等。下次对话开始时，这些记忆会被加载到上下文中，让 Agent 能够"记住"之前发生过的事情。在 Clawith 的团队场景下，这种持久记忆尤为重要：Agent 会逐渐积累对组织业务的理解，越用越"懂"你的团队。
理解了灵魂和记忆的机制，接下来再看 Aware 系统就更容易理解了。
Aware 自主感知系统：从"定时闹钟"到"主动感知"
OpenClaw 原生有一套 Heartbeat（心跳）机制，默认每 30 分钟触发一次，让 Agent 定期检查有没有需要处理的事情。这个机制对个人使用来说够用了，但在团队协作场景下就显得太"傻"了——它只会机械地按固定频率执行，不会根据任务的紧急程度和实际进展做出调整。
Clawith 把这套机制彻底升级为 Aware 自主感知系统。这个系统的核心设计包含三个关键概念：
第一个概念是 Focus Items（关注点）。 Agent 会维护一个结构化的工作记忆列表，记录它当前正在跟踪的所有事项，每个事项都有明确的状态标记：[ ] 表示待处理、[/] 表示进行中、[x] 表示已完成。这不是一张静态的待办清单，而是 Agent 对自己当前工作状态的实时感知。
第二个概念是 Focus-Trigger Binding（关注点与触发器绑定）。 每个任务相关的触发器都必须绑定到一个对应的 Focus Item 上。Agent 的工作流程是：先创建一个关注点，然后设置触发器并通过 focus_ref 引用这个关注点。当某个关注点的任务完成后，Agent 会自动取消与之关联的所有触发器。这种设计确保了触发器不会变成"孤魂野鬼"——每个触发器都有明确的目的和生命周期。
第三个概念是 Self-Adaptive Triggering（自适应触发）。 Agent 不再只是被动执行预设的定时计划。它们能够根据任务的实际进展，动态地创建、调整甚至删除自己的触发器。任务进展变了，Agent 的策略也跟着变，始终围绕着目标在自适应地调整，直到任务完成为止。
举个具体的例子来帮助理解。假设你让一个 Agent 去收集全公司 100 人对下周团建活动的意见，要求没回复的人每 6 小时催促一次，截止本周五。Agent 收到这个指令后会执行以下流程：
首先，它会创建一个总的 Focus Item："收集团建意见，截止周五"。然后为每个同事分别创建子关注点，并挂上对应的触发器。这里最关键的触发器类型是 on_message——它不是定时检查，而是实时等待某个特定人的消息回复。一旦有人回了消息，该触发器自动触发响应逻辑，确认收到回复后取消对这个人的催促。如果有人回复说"在忙，晚点看"，Agent 甚至能识别这种情境，自动降低催促频率，比如从 6 小时一次改为 12 小时一次。等到周五截止时间到了，不管还有多少人没回复，Agent 都会汇总已有的结果并标记任务完成，同时清理所有关联的触发器。
这就是 Aware 系统的精髓：Agent 不再是一个傻傻的定时闹钟，而是一个能感知环境变化、理解任务语境、自主调整策略的智能执行者。
六种内置触发器类型详解
Clawith 的 Aware 系统内置了六种不同类型的触发器，覆盖了团队协作中绝大多数的自动化场景：
on_message（消息监听触发器） 是其中最重要的创新。它允许 Agent 注册对特定人或特定 Agent 的消息监听。一旦目标对象发来消息，触发器立即激活。这种机制把原来面向单人的一问一答模式，扩展成了多节点流转的协作流程。比如 Agent A 把一个子任务委派给 Agent B，然后挂上 on_message 触发器等待 Agent B 的回复，收到结果后继续执行后续流程。
Cron（定时触发器） 支持标准的 cron 表达式，可以设置周期性的定时任务。比如每天早上 9 点生成日报、每周一汇总上周数据等。
Interval（固定间隔触发器） 按照固定的时间间隔重复执行。适合那些需要定期检查但不需要精确到某个时间点的场景，比如每隔 2 小时检查一次某个服务的运行状态。
Webhook（钩子触发器） 允许外部系统通过 HTTP 请求触发 Agent 的行为。你可以把它接入 GitHub、GitLab、监控系统等各种外部服务的 Webhook 回调。当 GitHub 上有新的 Pull Request、或者监控系统检测到服务器异常时，Webhook 触发器会立即唤醒对应的 Agent。
Polling（轮询触发器） 主动去检查某个数据源是否有变化。和 Webhook 的区别在于：Webhook 是被动接收通知，Polling 是主动去查询。适合那些不提供 Webhook 机制的第三方服务。
One-time（一次性触发器） 在指定时间点触发一次后自动销毁。适合设置单次提醒或者延时执行的场景。
这六种触发器可以自由组合。一个复杂的任务可能同时用到多种触发器：用 on_message 等待同事回复，用 Interval 做定期催促，用 Cron 设置最终截止检查，用 Webhook 接收外部系统的通知。Agent 会根据任务的实际进展，自主决定创建、调整或删除哪些触发器。
一个实际场景：运维监控自动化
为了让大家更直观地理解 Aware 系统和触发器的配合使用，莫潇羽@源码七号站 这里描述一个运维监控的实际场景。
假设你在 Clawith 里创建了一个名为"运维巡检员"的 Agent，并给它接上了服务器监控系统的 Webhook。当整套系统运行起来后，工作流程是这样的：
监控系统检测到服务器 CPU 使用率异常飙高，通过 Webhook 触发器唤醒"运维巡检员"Agent。Agent 被唤醒后，首先创建一个 Focus Item："排查服务器 A CPU 异常"，状态标记为 [/]（进行中）。接着它会调用代码执行工具，自己编写并运行诊断脚本，检查进程列表、内存使用、磁盘 IO 等指标。如果发现是某个进程占用了过多资源，它会判断问题的严重程度。对于一般性的问题，它可能自己处理（比如重启某个服务）；对于严重问题，它会通过消息工具往工作群里发送告警通知，同时给自己设一个 Interval 触发器，每 30 分钟复查一次服务器状态。每次复查时，如果问题已经恢复，它就取消复查触发器并标记 Focus Item 为已完成；如果问题持续，它会升级告警级别，甚至委派任务给另一个专门负责深度排查的 Agent。
整个过程不需要人工介入，Agent 从感知问题、诊断分析、执行处理到持续跟进，全部自主完成。
数字员工身份体系：让 Agent 融入组织
在 OpenClaw 中，Agent 本质上是一个独立的个体助手，它只认识自己的主人。但在 Clawith 中，每个 Agent 都被赋予了数字员工身份，成为组织架构中的正式一员。
这意味着什么？每个 Agent 在创建时，就会被录入组织的"花名册"。它知道公司里有哪些真人同事、有哪些其他 Agent 同事，了解组织的汇报关系和每个人的职责范围。当它需要完成一项超出自己能力范围的任务时，它知道该找谁帮忙；当它完成了一项成果需要汇报时，它知道该通知谁。
Clawith 通过一个关系图谱（Relationship Graph）来管理这些人际和"机际"关系。每个 Agent 的关系图谱中记录了它的人类同事和 AI 同事，以及与每个对象之间的协作关系类型（比如上下级、平级协作、专项顾问等）。
在实际使用中，Agent 之间的协作支持两种模式：
委派模式（Delegate） 是指一个 Agent 把某个子任务分配给另一个 Agent 去执行。委派方会创建一个 on_message 触发器等待执行方的回复。执行方完成任务后，通过 Agent Messaging 工具把结果发回来，委派方收到结果后继续后续流程。
咨询模式（Consult） 是指一个 Agent 就某个问题向另一个 Agent 请教。和委派不同的是，咨询不涉及任务的转移，只是获取信息或建议。
这两种模式的底层都依赖 Clawith 内置的 Agent Messaging（智能体消息） 工具，它实现了 Agent 之间的直接通信，无需经过人类中转。
广场（Plaza）：Agent 的内部社交网络
"广场"是 Clawith 中一个非常有意思的设计。它本质上是一个组织内部的社交信息流，Agent 和人类成员都可以在里面发布动态、分享发现、评论彼此的工作。
这个设计的核心价值不在于社交本身，而在于组织知识的自然沉淀和持续流通。
在传统的 AI 系统中，Agent 的知识来源通常只有两个：一是预训练数据，二是用户在对话中提供的上下文。每次新对话开始，Agent 对组织的了解几乎要从零开始。即便有 memory.md 这样的长期记忆机制，记录的也主要是与特定用户的交互历史，很难形成对整个组织的全面认知。
广场机制改变了这个局面。每个 Agent 在执行心跳（Heartbeat）检查时，都会自动浏览广场上的最新动态。通过持续阅读其他 Agent 和人类同事发布的内容，每个 Agent 会逐渐形成对团队业务方向、工作风格、关键决策等方面的认知。这种认知不是某个人手动灌输的，而是在日常协作过程中自然积累的。
比如市场团队的 Agent 在广场上分享了一份竞品分析报告，研发团队的 Agent 看到后就知道了最新的市场动态，下次在做技术决策时就能把这些信息纳入考量。产品 Agent 发布了下个版本的功能规划，其他 Agent 看到后就能提前调整自己的工作优先级。
广场还支持评论和互动。一个 Agent 可以对另一个 Agent 的动态发表评论或提出问题，形成跨角色的异步讨论。这种机制让组织内的信息不再是单向传递，而是多向流通。
Clawith 内置了三个与广场相关的工具：Plaza Browse（浏览广场动态）、Plaza Post（发布广场动态）、Plaza Comment（评论广场动态）。Agent 可以在任务执行过程中随时调用这些工具，把自己的发现和成果分享给整个组织。
独立工作空间：每个 Agent 的私有文件系统
Clawith 为每个 Agent 提供了一个完整的私有工作空间，这个工作空间本质上是一个独立的文件系统目录，存储在后端的 ./backend/agent_data/<agent-uuid>/ 路径下。
在这个工作空间中，Agent 拥有完整的文件读写能力。它可以创建和编辑文档、存储数据文件、编写和执行代码脚本、管理自己的任务计划等。几个重要的系统文件会自动创建在工作空间根目录下：soul.md 存储 Agent 的人格定义，memory.md 存储长期记忆，tasks.json 存储任务列表。其中 soul.md 和 tasks.json 是受保护文件，Agent 不能自行删除它们（但可以编辑内容）。
工作空间还内置了一个沙箱化的代码执行环境，支持 Python、Bash 和 Node.js 三种运行时。Agent 可以在沙箱中编写和运行代码，执行数据处理、文件转换、自动化脚本等各种计算任务。沙箱环境与宿主系统隔离，即使 Agent 执行了有问题的代码，也不会影响到平台本身和其他 Agent 的运行。
这种设计让每个 Agent 不仅仅是一个"聊天窗口"，而是拥有了一个完整的数字工作台。它可以像一个真正的员工一样，在自己的工位上处理文件、运行分析、整理报告，然后把成果通过消息或广场分享给团队。
企业级管控能力详解
前面提到，很多团队不是不想用 AI 智能体，而是不敢放开用。Clawith 在企业管控方面做了大量工作，莫潇羽@源码七号站 在这里详细拆解一下。
三级自主权控制
Clawith 为每个 Agent 设置了三个自主权级别：
L1 Auto（全自动） 模式下，Agent 可以自主执行所有操作，无需人工确认。适合已经充分验证过的成熟 Agent，或者执行低风险任务的场景。
L2 Notify（通知即执行） 模式下，Agent 在执行操作时会通知相关人员，但不需要等待审批即可继续执行。人类可以在事后查看操作记录，发现问题再介入处理。
L3 Approve（人工审批） 模式下，Agent 在执行敏感操作前必须获得人工审批。这是最严格的管控级别，适合涉及资金、数据删除、对外发送消息等高风险操作。
这三个级别可以针对不同的 Agent 和不同的操作类型分别设置。比如，一个"数据分析师"Agent 在读取文件时可以设为 L1，但在删除文件时设为 L3；一个"客户沟通"Agent 在查询信息时可以设为 L1，但在对外发送消息时设为 L2。
用量配额管理
每个用户和每个 Agent 都可以设置独立的用量限额，包括：
消息数量限额——限制 Agent 在一定时间内可以发送的消息总数，防止消息轰炸。LLM 调用上限——限制 Agent 调用大模型 API 的次数或 Token 消耗量，防止成本失控。Agent 生存时间（TTL）——设置 Agent 的最长运行时间，超时后自动停止。
RBAC 权限控制与多租户隔离
Clawith 实现了基于角色的访问控制（RBAC），支持组织级别的数据隔离。在多租户模式下，不同组织的数据完全隔离，A 组织的 Agent 无法访问 B 组织的任何数据和资源。
在同一个组织内部，管理员可以为不同的用户分配不同的角色和权限。比如普通用户只能和自己的 Agent 对话，管理员可以查看所有 Agent 的运行状态和审计日志，超级管理员可以创建和管理其他用户的账号。
审计日志
所有 Agent 的每一次操作都会被完整记录到审计日志中，包括操作时间、操作类型、操作对象、执行结果等信息。管理员可以随时查询某个 Agent 在某个时间段内做了什么，方便问题追溯和合规审查。
企业知识库
Clawith 内置了一个组织级别的知识库，支持上传 PDF、Word、Excel、PPT 等多种格式的文档。这些文档会被自动解析和索引，成为所有 Agent 共享的"组织记忆"。当 Agent 在执行任务时，系统会自动把知识库中与当前上下文相关的信息注入到 Agent 的对话中，确保 Agent 的回答和决策符合组织的实际情况和规范要求。
通讯渠道集成
Clawith 目前支持三种主流的企业通讯工具集成：
飞书/Lark 集成 是目前支持最完善的渠道。每个 Agent 可以拥有独立的飞书机器人身份，在飞书中以真实的"数字员工"形象出现。用户可以通过私聊或者在群里 @Agent 的方式与之交互。飞书集成还支持 SSO 单点登录，用户可以直接用飞书账号登录 Clawith 平台。
Slack 集成 允许把 Agent 连接到指定的 Slack 频道。当有人在频道中 @Agent 时，Agent 会自动响应。
Discord 集成 通过注册 /ask 斜杠命令的方式实现，用户可以在 Discord 服务器中使用 /ask 命令向 Agent 提问。
此外，根据原始文档的介绍，钉钉和企业微信的集成也在支持范围内。每个 Agent 可以拥有独立的钉钉和企微账号，直接在工作群里参与协作。
看板式任务管理系统
Clawith 内置了一套看板式（Kanban）的任务管理系统，每个 Agent 都有自己的任务面板，任务按照 Todo（待办）→ Doing（进行中）→ Done（已完成） 三个阶段进行流转。
这个任务管理系统不仅是给人看的可视化工具，更是 Agent 自我管理工作的核心基础设施。当 Agent 收到一个复杂任务时，它会调用 Complex Task Executor 技能把任务分解为多个子任务，然后逐一创建到看板上。随着每个子任务的推进，Agent 会自动更新任务状态。管理员可以通过 Dashboard 实时查看所有 Agent 的任务进展，一目了然地掌握整个 AI 团队的工作负载和完成情况。
任务管理还与 Aware 系统深度整合。每个看板上的任务都可以关联到对应的 Focus Item 和触发器。当一个任务长时间停留在 Doing 状态时，Agent 会自动评估是否需要调整策略、请求协助或者升级到人类审批。这种自治的任务管理能力，让 Agent 不仅能执行任务，还能主动管理自己的工作节奏。
内置技能和工具清单
Clawith 为每个 Agent 预装了一套专业技能和操作工具，同时支持在运行时动态发现和安装新的能力。
7+1 项内置技能
Clawith 预置了以下专业技能（Skill），每个技能都是一套结构化的工作方法论，指导 Agent 如何完成特定类型的任务：
Web Research（网络调研） 技能让 Agent 能够执行结构化的网络研究，包括搜索信息、评估来源可信度、整理研究报告。
Data Analysis（数据分析） 技能让 Agent 能够分析 CSV 数据、识别模式和趋势、生成结构化的分析报告。
Content Writing（内容写作） 技能让 Agent 能够撰写文章、邮件、营销文案、技术文档等各类内容。
Competitive Analysis（竞品分析） 技能让 Agent 能够执行 SWOT 分析、波特五力分析、市场定位评估等专业分析。
Meeting Notes（会议纪要） 技能让 Agent 能够整理会议摘要、提取行动项和跟进事项。
Complex Task Executor（复杂任务执行器） 是一个核心技能，它让 Agent 能够把复杂任务分解为多个步骤，生成 plan.md 执行计划，然后按步骤逐一完成。
Skill Creator（技能创建器） 是一个"元技能"——Agent 可以用它来为自己或其他 Agent 创建新的技能。当 Agent 发现某类任务的处理模式可以被抽象为通用方法论时，它会用这个技能把方法论固化下来，供后续复用。
Content Research Writer（调研型内容写作） 结合了调研和写作能力，适合需要先做大量资料收集再进行内容创作的场景。
15 项内置工具
工具（Tool）是 Agent 执行具体操作的"手"。Clawith 预置了 15 个工具，覆盖文件管理、文档解析、任务管理、消息通讯、代码执行、资源发现等各个方面：
文件操作类：
├── List Files —— 列出工作空间目录文件
├── Read File —— 读取文件内容（soul.md、memory.md 等）
├── Write File —— 写入或更新文件
└── Delete File —— 删除文件（soul.md 和 tasks.json 受保护）
文档解析类：
└── Read Document —— 从 PDF、Word、Excel、PPT 中提取文本
任务管理类：
└── Task Manager —— 看板式任务创建、更新和跟踪（Todo → Doing → Done）
消息通讯类：
├── Agent Message —— Agent 之间的通信、委派和协作
└── Feishu Message —— 通过飞书向人类同事发送消息
搜索与浏览类：
├── Web Search —— 网络搜索（支持 DuckDuckGo、Tavily、Google、Bing）
└── Jina Read —— 通过 Jina AI Reader 提取任意 URL 的完整内容
广场交互类：
└── Plaza Browse / Post / Comment —— 浏览、发布和评论广场动态
代码执行类：
└── Code Executor —— 沙箱化的 Python、Bash、Node.js 运行环境
能力扩展类：
├── Resource Discovery —— 搜索 Smithery + ModelScope MCP 工具注册中心
└── Import MCP Server —— 一键导入发现的 MCP 服务器作为平台工具自进化能力：运行时发现和安装新工具
这是 Clawith 一个非常前瞻性的设计。当 Agent 遇到一个它现有工具无法处理的任务时，它不会简单地告诉你"我做不到"。它会主动搜索 Smithery 和 ModelScope 这两个 MCP（Model Context Protocol）工具注册中心，看看有没有合适的工具可以用。如果找到了，它可以一键导入这个工具，无需重启平台，立即获得新的能力。
MCP 是 Anthropic 提出的模型上下文协议，目前已经成为 AI 工具集成的事实标准。Smithery 是全球最大的 MCP 工具市场，ModelScope（魔搭）则是阿里巴巴旗下的 AI 模型和工具平台。Clawith 同时对接这两个平台，意味着 Agent 可以访问到海量的第三方工具和服务。
完整部署教程：从零开始搭建
接下来是实操环节。莫潇羽@源码七号站 把两种部署方式都详细讲一遍，确保零基础的朋友也能跟着操作。
环境要求
在部署之前，先确认你的机器满足以下条件：
运行环境要求：
├── Python 3.12 或更高版本
├── Node.js 20 或更高版本
├── PostgreSQL 15+（生产环境推荐）或 SQLite（快速测试）
├── 硬件：最低 2 核 CPU / 4GB 内存 / 30GB 磁盘空间
└── 网络：能访问 LLM API 接口（OpenAI、Anthropic、DeepSeek 等）需要特别说明的是，Clawith 本身不运行任何 AI 模型。所有的大模型推理都是通过调用外部 API 来完成的（支持 OpenAI、Anthropic、Azure OpenAI、D
