核心概念

Monstrum 是一个 AI Agent 管控平台。本文解释平台的核心概念和设计理念，帮助你理解”平台在做什么”以及”为什么这样设计”。

设计理念

Bot 是行为主体，不是工具

传统的 AI 应用把大模型当工具——你输入问题，它返回答案。但在 Monstrum 中，Bot 是一个独立的行为主体：它可以自主决策、调用工具、访问外部系统、甚至委派任务给其他 Bot。

就像组织中的员工需要身份证明、行为边界、操作审计一样，Bot 作为数字世界的行为主体，也需要一套完整的治理体系：

自然人BotMonstrum 实现
身份证身份Bot 名称、描述、所属工作区
法律约束权限策略角色权限（允许的操作 + 参数范围）
工作授权资源绑定BotResource（绑定哪些系统、用什么身份）
密钥/钥匙凭据Credential（加密存储，Bot 看不到明文）
薪资预算Token 预算月度预算 + 成本追踪
行为记录审计日志全链路操作日志
经验/记忆Bot 记忆分区存储、自动提取的记忆系统

平台强制，而非 AI 自律

AI Agent 有能力但不可信——它会幻觉、会被 prompt 注入、会越权。Monstrum 的核心主张：安全由平台架构保证，不依赖 AI 的自我约束。

  • LLM 说”我不会访问那个仓库”？→ 不够。平台让它根本看不到那个仓库的工具
  • LLM 说”我不会泄露 API Key”？→ 不够。平台从不把明文凭据交给 LLM
  • LLM 说”我只操作授权范围”？→ 不够。平台在每次工具调用后校验参数是否越界

治理三原则

1. 最小权限 — 看不到 = 不存在

Bot 只能看到被显式授权的工具。未绑定的资源对 Bot 完全不可见——不是”可见但禁止调用”，而是 LLM 根本不知道它们的存在。

2. 凭据隔离 — LLM 永远碰不到密钥

凭据加密存储。执行时由平台解密注入到执行层，LLM 在整个生命周期中接触不到任何明文。即使 LLM 被 prompt injection 攻击，也无法泄露凭据。

3. Fail-Closed — 出错就停

任何环节出错，结果是”Bot 什么也做不了”，而不是”不受限制”：

  • 工具解析出错 → 返回空工具列表（Bot 没有任何工具可用）
  • 权限校验出错 → 拒绝请求
  • 事件投递前 re-check 失败 → 阻止投递

资源模型

Monstrum 的资源管理是三层抽象：声明能力 → 实例化连接 → 授权绑定。

三层结构

ResourceType（资源类型） → Resource（资源实例）+ Credential（凭据） → Bot

ResourceType（资源类型）

能力声明。定义一类集成”能做什么”。例如 SSH 类型声明了 ssh_execute 工具、主机白名单和命令白名单的权限维度、SSH Key 和密码两种认证方式。

平台内置 6 种资源类型：

资源类型用途
SSH远程服务器命令执行
MCP连接 Model Context Protocol 工具服务器
BotBot 间任务委托
Web Access网页搜索与内容抓取
Monstrum Agent本地 Agent 桥接自定义工具
Web3 (EVM)EVM 区块链操作

此外，插件市场提供更多资源类型（如 GitHub、GitLab 等）。

Resource（资源实例）

一个资源类型的具体连接。例如，你可以创建两个 SSH 类型的 Resource：“生产服务器”和”测试服务器”，各自配置不同的主机地址和凭据。

Credential（凭据）

加密存储的认证信息（API Key、SSH 密钥、OAuth Token 等）。凭据与 Resource 关联，Bot 通过 Resource 间接使用凭据——但 Bot 永远看不到凭据明文。

BotResource（资源绑定）

Bot 与 Resource 之间的授权关系。一个绑定包含：

  • 绑定哪个 Resource：Bot 可以通过这个绑定使用该 Resource
  • 使用哪个凭据：从 Resource 的凭据中选择
  • 权限约束：允许哪些操作、参数范围限制

绑定是权限的核心载体——没有绑定，Bot 就不知道这个 Resource 的存在。

权限模型

两层权限过滤

Monstrum 的权限检查分两层独立运行。任何一层都可以阻止越权行为：

第一层：Pre-LLM（工具可见性过滤）

在 LLM 推理之前，平台根据 Bot 的资源绑定过滤工具列表。LLM 只会看到 Bot 被授权使用的工具。未绑定的资源及其工具对 LLM 完全不可见。

第二层：Post-LLM（参数级权限校验）

在 LLM 返回工具调用后，平台校验调用参数是否在授权范围内。例如，Bot 虽然有 SSH 工具的调用权限，但如果它尝试连接未授权的主机，请求会被拒绝。

用户消息 → [Pre-LLM: 过滤工具列表] → LLM 推理 → [Post-LLM: 校验参数] → 工具执行

权限维度

每种资源类型声明自己的权限维度（Scope Dimension），定义”需要检查哪些参数”。例如：

资源类型权限维度含义
SSHhosts允许连接的主机（glob 匹配）
SSHcommands允许执行的命令（glob 匹配）
Web Accessdomains允许访问的域名（glob 匹配）
Web3recipients允许转账的地址
Web3contracts允许调用的合约地址
Botbots允许调用的目标 Bot

在创建资源绑定时，你可以为每个维度设置约束值（如 hosts: ["10.0.*", "prod-*"]），平台会自动校验每次工具调用的参数是否符合约束。

委派权限（Delegate Scope）

当 Bot A 将任务委托给 Bot B 执行时，可以为委托设置约束：

  • 工具白名单：限制 Bot B 在执行委托任务时可以使用哪些工具
  • 参数约束：进一步限制 Bot B 的参数范围

Bot B 执行委托任务时的有效权限 = Bot A 的委派约束 ∩ Bot B 的自身权限。权限只会缩小，不会放大。

角色（Role）

角色是预设的权限模板。你可以创建角色（如”只读运维”、“仓库管理员”），定义允许的操作和参数约束，然后在创建资源绑定时快速应用。角色支持继承，子角色在父角色基础上进一步限制权限。

详见 角色与权限。

两类工具

Bot 的工具分为两类，平台对它们的治理策略截然不同：

外部资源工具

Bot 代表用户访问外部系统——就像员工用公司账号访问 GitHub。

  • 需要通过 Resource + Credential 绑定
  • Pre-LLM 层根据绑定过滤工具可见性
  • Post-LLM 层通过权限维度校验调用参数
  • 例子：SSH 命令执行、MCP 工具调用、Bot 间委托、Web 搜索

Bot 自有能力工具

Bot 操作自己的数据——就像员工在自己的笔记本上写备忘。

  • 不需要 Resource 绑定，由 Bot 运行时配置开关控制
  • 不走权限维度校验（数据归 Bot 自己所有，所有权天然保证安全）
  • 例子：记忆读写、创建定时任务、管理工作流、向渠道发送消息

判断标准：数据归谁所有？操作的是 Bot 自己的数据 → 自有能力；操作的是外部系统或其他 Bot → 外部资源。

工具发现模式

不同资源类型的工具以不同方式被发现：

模式说明代表类型
静态工具在资源类型中预定义，不会变化SSH、Bot、Web3
动态工具在运行时自动发现（连接后探测）MCP、Monstrum Agent
配置式工具定义固定，行为由配置决定Web Access（搜索引擎可选）

对于动态发现类型，Bot 绑定资源时使用工具 glob 模式（如 list_*、get_menu）来控制可用工具，而非操作名。

Bot vs Agent vs LLM

这三个概念容易混淆，需要区分：

概念是什么
LLM大语言模型，纯推理引擎。接收 prompt 和工具定义，返回文本或工具调用。自身不执行任何操作。
BotMonstrum 平台上的受管 AI 实体。拥有身份、权限、资源绑定、记忆、预算。它使用 LLM 作为”大脑”，但 Bot ≠ LLM。
Agent用户在本地运行的程序，通过 WebSocket 接入平台，将本地工具桥接到平台。

简单来说：LLM 是引擎，Bot 是平台管控的实体，Agent 是本地工具的桥梁。

会话与任务

Bot 有两种执行模式：

会话模式（Session）

用户通过 IM 渠道（Slack、飞书、Telegram 等）或 Web 对话与 Bot 交互。

  • 多轮对话，保持上下文
  • 空闲 30 分钟自动回收
  • 支持会话持久化（下次创建时恢复历史）
  • 超过 80 条消息时自动压缩（LLM 总结旧消息，保留最近 50 条）

任务模式（Task）

通过 API、定时调度、Bot 间委托或事件触发的单次执行任务。

  • 独立上下文，执行完毕即结束
  • 支持进度上报和 checkpoint（断点恢复）
  • 适合批量操作、定时任务等场景

工作区（Workspace）

工作区是 Monstrum 的租户隔离单元。所有实体（Bot、Resource、审计日志等）按工作区隔离。

  • 一个用户可以属于多个工作区
  • 工作区成员有 4 种角色：所有者 > 管理员 > 成员 > 访客
  • 每个工作区有独立的 LLM Provider 配置、提示词模板、Bot 和资源

事件系统

平台内部有完整的事件发布/订阅体系，覆盖全生命周期：

事件类型示例
任务事件task.completed、task.failed
工作流事件workflow.completed、workflow.failed
调度事件schedule.fired
会话事件session.created、session.expired
自定义事件custom.deploy_done（Bot 发布的自定义事件）

Bot 可以订阅事件（使用 fnmatch 模式匹配），在事件触发时自动执行指定指令。事件也可以触发工作流执行。

详见 工作流自动化。

记忆系统

Bot 的记忆按作用域分区管理，决定记忆在什么场景下可见：

作用域可见范围
全局记忆所有场景
频道记忆特定 IM 频道的会话
任务记忆特定任务执行期间
资源记忆绑定了特定 Resource 的场景

记忆有两种来源：

  • 手动添加：用户在 Bot 详情页手动创建的记忆条目
  • 自动提取：任务完成或会话过期时，LLM 分析对话内容自动提取重要信息

详见 记忆系统。

提示词管理

平台的提示词按三层优先级解析：

Bot 级自定义 > 工作区级模板 > 系统默认值

你可以在工作区级别定制所有 Bot 共用的提示词模板，也可以在单个 Bot 级别覆盖特定提示词。

详见 提示词模板。

下一步

在 GitHub 上编辑此页