深入浅出：Moltbot AI Agent 架构及其设计思想
用统一多端与多渠道；用兑现主权 AI；用把机器能力变成可编排工具面；用按需子代理 + 分层提示词 + 多层策略栈把协作做得高效且可控；用可复现的工具供应链（Nix + Skill）把生态扩张变成工程问题而非手工活。不要让模型成为系统；让系统成为模型的“可治理外骨骼”。单主 Agent + 按需子 Agent的架构平衡了资源效率和功能扩展分层提示词系统减少了 token 消耗，提高了子 Agent
Moltbot AI Agent 设计思想
Moltbot（前身 Clawdbot）乍看像“开源堆料”：一长串工具、桥接、协议与 CLI。真正拆开依赖与调用关系会发现，它不是把零件粘在一起，而是在做一件很明确的事——用一个长期运行的控制面（Gateway）把“消息入口—模型推理—工具执行—状态记忆—多端呈现”统合成一套可观测、可治理、可扩展的 Agent 系统。
它的野心也不是再做一个聊天应用，而是在推动两条反主流路线：主权 AI（Sovereign AI）与OS-as-Surface（操作系统即界面）。
1. 设计思想：从“云端助手”转向“本地控制面”
1.1 主权 AI：数据不出门，能力在你手里
Peter Steinberger 的核心判断是：真正的个人助理必须深入你的生活（通信、财务、日程、情绪），因此数据主权是架构的第一原则。这直接导向 Moltbot 的关键选择：
- Local-first：Gateway 是常驻进程，运行在你自己的硬件上（Mac mini/Mac Studio/Linux/RPi）。
- 记忆落在本地文件：长期信息用 Markdown（如
USER.md、SOUL.md）沉淀在本地文件系统，而不是托管向量库服务。 - 离线可控：身份认证与控制面逻辑下沉到 Gateway，本地网络甚至断网仍可基本运作。
结果是：它不像 SaaS 助手那样“把你接入云”，而是把云模型当成可替换的推理部件——你可以云端/本地模型混用、轮换、failover。
1.2 OS-as-Surface：把操作系统变成工具面
Moltbot 反对把能力封在浏览器插件或单一 App 沙箱里，而是把“你这台机器能做的事”抽象成工具：文件、进程、窗口、摄像头、屏幕、通知、自动化……
它极度推崇 CLI：不是因为“复古”，而是因为 LLM 天生更懂 Unix 工具链，而 CLI 的组合性（pipe、grep、jq、awk、curl、ffmpeg）天然适合 Agent 做“临场编排”。
Peter 在播客里对 MCP 的批评很尖锐：把所有工具定义常驻塞进上下文，既浪费 token，也缺乏脚本化与链式处理能力。Moltb ot 选择的路线更像：“能力以 CLI/外部工具存在，Skill 文档教模型怎么用；Gateway 负责门控、审计与编排”。
1.3 “应用消融”：Skill 取代 App 的交互层
Skill（SKILL.md）本质是标准化的“使用说明书”：用自然语言告诉模型如何调用一个 CLI 或服务完成任务。
当大量常见需求都能以“工具 + Skill”解决时，传统 App 的图形界面被“消融”为数据与操作能力，Agent 在上层统一调度——这也是 Moltbot “OS-as-Surface” 能成立的前提。
2. 一张图看清 Moltbot：Gateway 是身体，Agent Loop 是大脑
Moltbot 的“本体”是一个 Gateway 控制面守护进程，它统一接入各种消息渠道，并把多端 UI/CLI/移动节点都收敛到同一控制协议之下。
关键点：Moltbot 把复杂度压在“控制面”而不是“模型提示词”或“编排 DSL”上。
模型负责推理，Gateway 负责治理：路由、会话、权限、审计、并发、崩溃隔离、跨端同步。
3. Gateway：不是消息转发器，而是可观测的控制平面
3.1 Hub-and-Spoke：状态集中，体验才能“无缝”
Gateway 采用轮辐式拓扑：所有入口（手机、桌面、各种聊天渠道、Web 控制台）都连接到同一个 Hub。
这带来的直接好处是：对话上下文与会话状态只在 Hub 端有“唯一真相”，多端切换不会断片。
3.2 为什么用 WebSocket：Agent 需要双向、实时、可流式
Moltbot 核心通信放弃 REST，使用 WS 做全双工：
- 能推送事件流：心跳、运行状态、工具调用、压缩、权限报错等都能实时反馈。
- 支持流式块传输：把“思考/工具调用/最终回复”拆块上报，提高透明度与交互速度。
- 协议结构用 TypeBox/Schema 约束，减少运行时漂移。
3.3 Node 能力广播：工具不是“固定清单”，而是动态发现
连接建立后，节点会 主动声明能力（如 camera.snap、screen.record、notification.send）。
Gateway 维护动态路由表：当 Agent 说“拍照”，系统会把指令精确路由到那台 iPhone，而不是盲发。
3.4 远程访问：不自己造 VPN，用 Tailscale 收敛攻击面
Local-first 并不等于不能远程。Moltbot 深度集成 Tailscale：
- 不必公网开端口，Gateway 仍可绑定在安全接口上。
- 需要公网回调时用 Funnel，并加访问控制。
4. Agent Loop：工程化的“模型调用循环”，而非一次性聊天
4.1 进程隔离：让“调度层别死”
Pi Runtime（Agent 运行时）与 Gateway 通过 RPC 解耦，推理逻辑崩了，Gateway 仍然存活并能重启子进程。
这背后的工程哲学很 Erlang：把最容易出事故的部分隔离出去，核心只做监督、路由与状态。
4.2 Thinking Levels：用“认知深度”驱动模型路由与成本控制
Moltbot 把“要想多深”做成可调参数（off → xhigh），并可以按会话持久化。
这不是噱头：它允许系统在不同任务间做成本/速度/质量的动态折中，并触发不同模型策略（本地快模型 vs 强推理云模型）。
4.3 Adaptive Compaction Safeguard：把“遗忘”做成可控的内存管理
长上下文不可避免会溢出。Moltbot 的处理不是简单截断，而是：
- 动态分块与递归摘要，保留关键决策点。
- 压缩前触发钩子，把重要信息刷写到本地长期记忆文件。
- UI 显式反馈压缩状态，避免用户误以为卡死。
5. 多 Agent：单主 Agent + 按需子 Agent，而不是“预启动军团”
很多系统一上来就搞“多代理编排”。Moltbot 更像操作系统：主会话常驻，子代理按需生成、完成即回收。
5.1 用 Session Key 做“无数据库的类型系统”
Session Key 直接编码会话类型与来源，例如：
- 主会话：
agent:default:main - 子代理：
agent:default:subagent:<uuid>
好处是：日志追踪、路由、策略判断无需额外查表。
5.2 PromptMode 分层：full / minimal / none
这是 Moltbot 很“值钱”的设计：不同角色用不同系统提示词强度。
- 主 Agent（full）：包含工具、技能、记忆、消息规范、心跳、静默回复等完整“操作手册”。
- 子 Agent（minimal）：只保留完成任务所需的 tooling/workspace/runtime，避免 token 浪费与越权。
- 极简（none）：特殊场景下只保留身份声明。
5.3 子代理约束：把“越权”关在系统里，而不是靠自觉
子代理被明确告知角色边界，并在工具层硬限制：禁用 message、cron、gateway、sessions_spawn 等高风险工具。
这意味着多 Agent 协作不是“靠 prompt 讲道理”，而是prompt + policy 双保险。
5.4 结果回注：子代理完成后“自然语言汇报”
子代理结束会生成汇报包，系统把它注入主会话，让主 Agent 用 1~2 句自然语言对用户解释结果，同时隐藏 tokens、成本等技术噪音——复杂度被抹平，体验像“魔法”。
6. 工具与生态：看似“缝合”，其实是可复现的能力供应链
外界看到那串依赖列表容易误判为卷。实际上它们构成了 Moltbot 的“器官系统”：
- Peekaboo / Poltergeist：屏幕感知 + 无障碍树操作，补齐“没有 CLI 的遗留软件”能力。
- sweet-cookie + bird：继承浏览器已登录会话，让 Agent 以用户身份操作 Web 服务。
- nix-moltbot + Nix Flakes：解决“依赖地狱”，让技能工具链可复现、可部署、可审计。
重点不在“工具多”，而在于：工具以外部 CLI 形式存在，Skill 负责教会模型，Gateway 负责接入与治理。这就是“不是堆料，是地基”。
7. 安全：给 AI 系统权限，必须做纵深防御
Moltbot 的安全不是一句“请小心使用”，而是体系化门控：
- 最小权限 + macOS TCC 映射：缺权限直接返回结构化错误（如
PERMISSION_MISSING）。 - Docker 沙箱：高风险来源或不可信代码在隔离环境运行，会话结束即销毁。
- 外部渠道 DM 配对：未知私信先配对再放行，抵抗提示注入与骚扰。
8. Peter 的“Agentic Engineering”：架构为什么会长成这样
理解 Moltbot 的架构，绕不开 Peter 的工程观：
- 反“瀑布式编排”：他批评“先写大 spec 再让机器干活”的编排层，本质仍是瀑布，只会产生“精致的混乱”。
- 验证闭环优先：代码之所以适合交给 Agent，是因为可编译、可测试、可验证。Moltbot 把可观测、可测试、可回滚的工程约束放进系统设计里（会话队列、隔离、压缩、策略栈）。
- 把复杂度藏起来：用户只看到“在 WhatsApp 里和朋友聊天”，看不到背后起了多少子代理、跑了多少工具、做了多少路由与门控——这要求控制面极强。
这也解释了一个现象：为什么很多人用 Mac mini 跑 Moltbot体验最好——它并非偶然，而是工具链（大量 Swift/macOS 能力）与 OS-as-Surface 路线自然收敛的结果。
结语：Moltbot 的本质，是“AI 原生控制面”
Moltbot 真正创新之处不在某个模型、某个提示词技巧，而在于它把 Agent 做成了“系统”而不是“应用”：
- 用 Gateway-first 统一多端与多渠道；
- 用 Local-first 兑现主权 AI；
- 用 OS-as-Surface 把机器能力变成可编排工具面；
- 用 按需子代理 + 分层提示词 + 多层策略栈 把协作做得高效且可控；
- 用 可复现的工具供应链（Nix + Skill） 把生态扩张变成工程问题而非手工活。
如果要用一句话概括 Moltbot 的设计思想：
不要让模型成为系统；让系统成为模型的“可治理外骨骼”。
Moltbot AI Agent 架构设计分析
一、核心架构概览
1.1 Agent 实例数量
Moltbot 采用单主 Agent + 按需子 Agent 的架构：
┌─────────────────────────────────────────────────────────────┐
│ Gateway (网关) │
│ - 统一入口，管理所有 Agent 生命周期 │
│ - 通过 RPC 调度 Agent 运行 │
└─────────────────────────────────────────────────────────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Main │ │ Cron │ │ Subagent│
│ Agent │ │ Agent │ │ (按需) │
│ (主会话) │ │ (定时) │ │ │
└─────────┘ └─────────┘ └─────────┘
关键发现：
- 不是预先启动多个 Agent，而是按需创建
- 每个 Agent 运行是一次独立的 LLM 调用循环
- 通过
sessionKey区分不同的 Agent 实例 - 子 Agent 通过
sessions_spawn工具动态创建
1.2 Session Key 命名规范
// 主 Agent 会话
"agent:default:main"
"agent:peter:telegram:123456"
// 子 Agent 会话 (动态生成)
"agent:default:subagent:550e8400-e29b-41d4-a716-446655440000"
二、系统提示词架构
2.1 提示词模式 (PromptMode)
Moltbot 定义了三种提示词模式，这是一个精妙的设计：
type PromptMode = "full" | "minimal" | "none";
| 模式 | 用途 | 包含内容 |
|---|---|---|
full |
主 Agent | 完整系统提示词（Skills、Memory、Messaging、Voice、Docs 等） |
minimal |
子 Agent | 精简版（仅 Tooling、Workspace、Runtime） |
none |
极简场景 | 仅基础身份声明 |
设计洞察：
- 子 Agent 不需要知道如何处理用户消息、心跳、静默回复等
- 减少 token 消耗，提高子 Agent 专注度
- 避免子 Agent 越权（如直接发消息给用户）
2.2 主 Agent 系统提示词结构
┌─────────────────────────────────────────────────────────────┐
│ 身份声明: "You are a personal assistant running inside Moltbot." │
├─────────────────────────────────────────────────────────────┤
│ ## Tooling │
│ - 可用工具列表及简要说明 │
│ - 工具名称大小写敏感提醒 │
├─────────────────────────────────────────────────────────────┤
│ ## Tool Call Style │
│ - 何时需要解释，何时直接调用 │
├─────────────────────────────────────────────────────────────┤
│ ## Skills (mandatory) │
│ - 技能发现和使用指南 │
├─────────────────────────────────────────────────────────────┤
│ ## Memory Recall │
│ - 记忆检索指南 │
├─────────────────────────────────────────────────────────────┤
│ ## Workspace │
│ - 工作目录信息 │
├─────────────────────────────────────────────────────────────┤
│ ## Messaging │
│ - 消息路由规则 │
│ - 跨会话通信方式 │
├─────────────────────────────────────────────────────────────┤
│ ## Silent Replies │
│ - NO_REPLY 使用规范 │
├─────────────────────────────────────────────────────────────┤
│ ## Heartbeats │
│ - 心跳响应规范 │
├─────────────────────────────────────────────────────────────┤
│ ## Runtime │
│ - 运行时信息（agent、host、os、model、channel 等） │
├─────────────────────────────────────────────────────────────┤
│ # Project Context │
│ - 注入的上下文文件（SOUL.md、TOOLS.md 等） │
└─────────────────────────────────────────────────────────────┘
2.3 子 Agent 系统提示词
子 Agent 收到的是精简版系统提示词 + 专用上下文：
// 子 Agent 专用上下文 (extraSystemPrompt)
const subagentContext = `
# Subagent Context
You are a **subagent** spawned by the main agent for a specific task.
## Your Role
- You were created to handle: ${taskText}
- Complete this task. That's your entire purpose.
- You are NOT the main agent. Don't try to be.
## Rules
1. **Stay focused** - Do your assigned task, nothing else
2. **Complete the task** - Your final message will be automatically reported
3. **Don't initiate** - No heartbeats, no proactive actions, no side quests
4. **Be ephemeral** - You may be terminated after task completion. That's fine.
## What You DON'T Do
- NO user conversations (that's main agent's job)
- NO external messages unless explicitly tasked
- NO cron jobs or persistent state
- NO pretending to be the main agent
- NO using the \`message\` tool directly
`;
设计洞察：
- 明确告知子 Agent 它的角色边界
- 防止子 Agent 越权行为
- 强调任务完成后的生命周期
三、多 Agent 协作机制
3.1 子 Agent 生成流程
┌──────────────┐ sessions_spawn ┌──────────────┐
│ Main Agent │ ───────────────────▶ │ Gateway │
│ │ │ │
│ task: "..."│ │ 创建子会话 │
│ label: "..." │ │ 注册运行记录 │
└──────────────┘ └──────────────┘
│
▼
┌──────────────┐
│ Subagent │
│ (新 LLM 调用)│
│ │
│ 独立会话 │
│ 精简提示词 │
│ 受限工具集 │
└──────────────┘
│
│ 完成
▼
┌──────────────┐
│ Announce │
│ Flow │
│ │
│ 通知主 Agent │
│ 汇报结果 │
└──────────────┘
3.2 子 Agent 注册与追踪
type SubagentRunRecord = {
runId: string; // 运行 ID
childSessionKey: string; // 子会话 Key
requesterSessionKey: string; // 请求者会话 Key
requesterOrigin?: DeliveryContext; // 请求来源上下文
task: string; // 任务描述
cleanup: "delete" | "keep"; // 完成后处理方式
label?: string; // 可选标签
createdAt: number; // 创建时间
startedAt?: number; // 开始时间
endedAt?: number; // 结束时间
outcome?: SubagentRunOutcome; // 运行结果
archiveAtMs?: number; // 归档时间
};
3.3 结果通知机制
子 Agent 完成后，系统会：
- 构建统计信息：运行时长、token 消耗、成本估算
- 生成通知消息：
A background task "数据分析" just completed successfully.
Findings:
[子 Agent 的最终回复]
Stats: runtime 45s • tokens 2.3k (in 1.8k / out 0.5k) • est $0.02
Summarize this naturally for the user. Keep it brief (1-2 sentences).
Do not mention technical details like tokens, stats, or that this was a background task.
- 注入主 Agent 会话：通过 steering 或 followup queue
四、工具策略系统
4.1 多层工具过滤
┌─────────────────────────────────────────────────────────────┐
│ Tool Policy Stack │
├─────────────────────────────────────────────────────────────┤
│ 1. Global Policy (全局策略) │
│ └─ 所有 Agent 的基础工具集 │
├─────────────────────────────────────────────────────────────┤
│ 2. Provider Policy (提供商策略) │
│ └─ 针对特定 LLM 提供商的工具限制 │
├─────────────────────────────────────────────────────────────┤
│ 3. Agent Policy (Agent 策略) │
│ └─ 特定 Agent 的工具配置 │
├─────────────────────────────────────────────────────────────┤
│ 4. Group Policy (群组策略) │
│ └─ 基于消息来源的工具限制 │
├─────────────────────────────────────────────────────────────┤
│ 5. Sandbox Policy (沙箱策略) │
│ └─ 沙箱环境下的工具限制 │
├─────────────────────────────────────────────────────────────┤
│ 6. Subagent Policy (子 Agent 策略) │
│ └─ 子 Agent 的工具限制（如禁用 message 工具） │
└─────────────────────────────────────────────────────────────┘
4.2 子 Agent 工具限制
// 子 Agent 被禁止使用的工具
const SUBAGENT_BLOCKED_TOOLS = [
"message", // 不能直接发消息
"cron", // 不能创建定时任务
"gateway", // 不能操作网关
"sessions_spawn", // 不能再生成子 Agent
];
五、执行流程详解
5.1 单次 Agent 运行流程
async function runEmbeddedPiAgent(params: RunEmbeddedPiAgentParams) {
// 1. 解析执行通道 (lane)
const sessionLane = resolveSessionLane(params.sessionKey);
const globalLane = resolveGlobalLane(params.lane);
// 2. 解析模型和认证
const { model, authStorage } = resolveModel(provider, modelId, agentDir, config);
const apiKeyInfo = await getApiKeyForModel({ model, cfg, profileId, store, agentDir });
// 3. 构建系统提示词
const systemPrompt = buildAgentSystemPrompt({
workspaceDir,
toolNames,
promptMode: isSubagent ? "minimal" : "full",
extraSystemPrompt: subagentContext,
// ... 其他参数
});
// 4. 执行 LLM 调用循环
while (true) {
const attempt = await runEmbeddedAttempt({
prompt,
model,
tools,
systemPrompt,
// ...
});
// 5. 处理错误和重试
if (attempt.promptError) {
// 上下文溢出 → 尝试压缩
// 认证失败 → 切换 profile
// thinking 不支持 → 降级
}
// 6. 成功则返回结果
if (!attempt.error) {
return buildPayloads(attempt);
}
}
}
5.2 执行通道 (Lane) 机制
// 不同类型的执行通道
const AGENT_LANE_MAIN = "main"; // 主会话
const AGENT_LANE_CRON = "cron"; // 定时任务
const AGENT_LANE_SUBAGENT = "subagent"; // 子 Agent
const AGENT_LANE_NESTED = "nested"; // 嵌套调用
设计目的：
- 隔离不同类型的 Agent 运行
- 防止相互阻塞
- 便于资源管理和监控
六、与其他 AI 应用的差异化设计
6.1 独特设计点
| 特性 | Moltbot 设计 | 常见设计 | 优势 |
|---|---|---|---|
| Agent 实例化 | 按需创建，会话隔离 | 单例或预创建池 | 资源高效，隔离性好 |
| 提示词分层 | full/minimal/none 三级 | 统一提示词 | 减少 token，提高专注度 |
| 子 Agent 约束 | 明确角色边界，工具限制 | 无限制或简单限制 | 防止越权，行为可控 |
| 结果通知 | 自动汇报 + 自然语言总结 | 直接返回或手动查询 | 用户体验好，无缝集成 |
| 工具策略 | 6 层过滤栈 | 单层或双层 | 精细控制，安全性高 |
| 认证轮换 | 多 profile 自动切换 | 单一认证 | 高可用，限流容错 |
6.2 Session Key 设计的精妙之处
// 从 sessionKey 可以解析出：
// 1. Agent ID
// 2. 会话类型（main/subagent/cron）
// 3. 唯一标识
parseAgentSessionKey("agent:peter:subagent:uuid-123")
// → { agentId: "peter", sessionType: "subagent", sessionId: "uuid-123" }
好处：
- 无需额外数据库查询即可确定会话属性
- 便于日志追踪和调试
- 支持跨 Agent 会话管理
6.3 Steering 机制
当子 Agent 完成时，结果可以通过多种方式注入主 Agent：
type QueueMode =
| "steer" // 直接注入当前运行
| "steer-backlog" // 注入或排队
| "followup" // 排队等待下次运行
| "collect" // 收集多个结果
| "interrupt"; // 中断当前运行
七、设计权衡分析
7.1 优点
-
资源效率
- 按需创建 Agent，不占用常驻资源
- 子 Agent 使用精简提示词，减少 token 消耗
-
安全性
- 多层工具策略，精细权限控制
- 子 Agent 明确边界，防止越权
-
可扩展性
- 插件系统支持扩展工具
- 多 Agent 配置支持不同场景
-
用户体验
- 子 Agent 结果自动汇报，无缝集成
- 支持多渠道（Telegram、Discord、Slack 等）
-
容错性
- 认证 profile 自动轮换
- 模型 fallback 链
- 上下文溢出自动压缩
7.2 潜在挑战
-
复杂度
- 多层策略系统增加理解成本
- Session Key 命名规范需要严格遵守
-
调试难度
- 子 Agent 运行在独立会话，追踪链路较长
- 多层过滤可能导致工具意外不可用
-
延迟
- 子 Agent 需要完整的 LLM 调用，有额外延迟
- 结果通知需要等待子 Agent 完成
7.3 设计取舍
| 取舍点 | 选择 | 原因 |
|---|---|---|
| 子 Agent 隔离 vs 共享上下文 | 隔离 | 安全性优先，防止信息泄露 |
| 同步 vs 异步子 Agent | 异步 | 不阻塞主 Agent，支持长时间任务 |
| 统一提示词 vs 分层提示词 | 分层 | 减少 token，提高专注度 |
| 工具全开放 vs 策略限制 | 策略限制 | 安全性优先，精细控制 |
八、对 AI Agent 设计的启示
8.1 核心原则
-
最小权限原则
- 子 Agent 只获得完成任务所需的最小工具集
- 通过多层策略实现精细控制
-
职责分离原则
- 主 Agent 负责用户交互
- 子 Agent 负责具体任务
- 明确边界，防止越权
-
可观测性原则
- Session Key 包含足够信息用于追踪
- 事件系统支持全链路监控
-
容错设计原则
- 认证轮换、模型 fallback、自动压缩
- 优雅降级而非直接失败
8.2 推荐实践
-
提示词设计
- 为不同角色设计不同级别的提示词
- 子 Agent 提示词应明确其角色边界和限制
-
工具管理
- 实现多层工具策略栈
- 子 Agent 应禁用可能越权的工具
-
会话管理
- 使用结构化的会话标识（如 Session Key）
- 支持会话间的通信和结果传递
-
结果处理
- 子 Agent 结果应自动汇报给主 Agent
- 提供自然语言总结，而非原始数据
九、总结
Moltbot 的 AI Agent 架构展示了一个成熟的多 Agent 系统设计：
- 单主 Agent + 按需子 Agent 的架构平衡了资源效率和功能扩展
- 分层提示词系统 减少了 token 消耗，提高了子 Agent 专注度
- 多层工具策略 提供了精细的权限控制
- 异步子 Agent + 自动汇报 提供了良好的用户体验
这些设计为构建复杂的 AI Agent 系统提供了宝贵的参考。
附录：关键代码位置
| 功能 | 文件路径 |
|---|---|
| Agent 运行入口 | src/agents/pi-embedded-runner/run.ts |
| 系统提示词构建 | src/agents/system-prompt.ts |
| 子 Agent 生成工具 | src/agents/tools/sessions-spawn-tool.ts |
| 子 Agent 注册表 | src/agents/subagent-registry.ts |
| 子 Agent 结果通知 | src/agents/subagent-announce.ts |
| 工具策略过滤 | src/agents/pi-tools.policy.ts |
| Agent 配置解析 | src/agents/agent-scope.ts |
| 事件系统 | src/infra/agent-events.ts |
| Moltbot 工具集 | src/agents/moltbot-tools.ts |
| 配置类型定义 | src/config/types.agents.ts |
分析基于 Moltbot 代码库
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
22
0- 0
已为社区贡献4条内容
所有评论(0)