Monstrum — AI Agent 治理平台一种新型的 Agent 治理工程范式：平台强制执行权限，而不是靠 AI 自律。项目概述当 AI Agent 能调用工具、访问 API、操作链上资产时，一个根本性问题浮现：谁来约束 Agent 的行为？传统做法是在 prompt 里写"不要做 X"——这是靠 AI 自律，本质上不可靠。Monstrum 提出了一种新的范式：治理工程化——把权限控制、凭证隔离、审计追踪从应用层下沉到平台层，用工程手段而非语言约束来管理 Agent 行为。Monstrum 是一个 AI Agent 管控平台，提供：操作级权限隔离：Agent 只能看到被授权的工具，未授权工具在 LLM 上下文中根本不存在凭证托管：API Key、私钥等敏感凭证由平台加密保管（AES-256），Agent 永远接触不到明文多 Agent 协作治理：Bot-to-Bot 委派时，调用方的约束决定被调用方的有效权限完整审计链路：每次工具调用记录执行者、参数、结果、时间戳插件体系：声明式清单定义工具和权限维度，平台自动驱动 UI 渲染、工具索引、权限检查治理工程范式AI Agent 应用正在从"对话助手"演化为"能操作外部系统的自主体"——它能调 API、发交易、操作数据库。但当 Agent 获得执行能力后，安全问题的性质发生了根本变化：不再是 AI 说了什么，而是 AI 做了什么。目前行业的主流做法是在 prompt 中写约束（"你不能调用支付接口"、"转账超过 100 元需要确认"），本质上是靠 AI 的语义理解来自我约束。这种方式有三个结构性缺陷：不可靠：Prompt 是自然语言，LLM 可能误解、忽略、或被注入攻击绕过不可审计：没有独立于 AI 的执行记录，出了问题无法追溯不可组合：多 Agent 协作时，每个 Agent 的 prompt 约束互相独立，无法形成统一的权限链Monstrum 提出的范式是把这三层问题从应用层下沉到平台层，用工程机制替代语言约束：Pre-LLM 工具过滤——在调用 LLM 之前，平台根据 Bot 的资源绑定和权限配置，过滤出它能看到的工具列表。未授权的工具不会出现在 LLM 的上下文中，AI 无法调用一个它不知道存在的工具。这是物理隔离，不是语义隔离。Post-LLM 参数校验——LLM 选择了工具并生成参数后，平台在执行前对参数做声明式校验（地址白名单、金额上限、操作范围等）。校验规则定义在资源类型的 ScopeDimension 中，与 prompt 完全解耦。凭证注入——Agent 永远接触不到 API Key、私钥等敏感凭证。凭证由平台加密保管，仅在工具执行瞬间解密注入，执行完毕即销毁。即使 Agent 被提示注入攻击，也无法泄露凭证。委派约束——多 Agent 协作时，调用方的绑定配置决定被调用方的有效权限。即使 Payment Agent 本身有全部链上操作权限，当客服 Bot 委派它时，平台会根据客服 Bot 的 DelegateConstraints 收窄 Payment Agent 的可用工具范围。权限链条是平台强制执行的，不依赖任何 Agent 的"自觉"。完整审计——每次工具调用由平台独立记录：谁调用了什么工具、传入了什么参数、返回了什么结果、什么时间执行的。审计日志独立于 AI 的对话历史，是不可篡改的第三方记录。这套机制的核心思想是：Agent 的行为边界不应该由 Agent 自己决定，而应该由平台从外部强制划定。 就像操作系统不会让应用程序自己决定能不能访问内核，Agent 的工具权限也应该由一个独立的、不可被 AI 操控的层来执行。Demo：AI 支付服务我们用一个链上支付场景来展示 Monstrum 的治理能力。三个 Bot 组成一套智能支付系统，处理 Sepolia 测试网上的真实 ETH 链上交易。Demo 原理Payment Gateway 是一个 Monstrum 插件，包含声明式清单和执行器。清单定义了 6 个工具、权限维度、凭证和配置的 schema；平台根据清单自动完成工具注册、UI 渲染、权限检查——插件开发者只写业务逻辑，不写平台代码。Demo 中的订单数据是 mock 的，模拟第三方订单系统的接入。链上交易是真实的——每次退款都是 Sepolia 测试网上的真实 ETH 转账，可在 Etherscan 上验证。生产环境中只需将 mock 数据源替换为真实的订单系统 API，插件代码和平台配置无需改动。插件中订单数据退款地址为 mock 客户地址。订单 1-4 为已支付可退款订单，其中订单 2-4 可重复退款，方便评审体验。订单 5为待支付状态。所有操作行为均受平台策略强制约束，LLM 只负责决策，保证交易过程的安全性。在线体验地址：https://app.monstrumai.com账号：ripatest@monstrumai.com密码：ZCrNGB8CyXZ3Xrqn9zzC测试钱包交易信息: https://sepolia.etherscan.io/address/0x111755d2683342F16CecEaeDe1b9a939Ec974034Monstrum官网: https://www.monstrumai.com注册地址: https://app.monstrumai.com/register👏欢迎各位前来体验！当前项目仍处于内部测试当中，可通过邀请码注册体验！L3Sv1xolcM7ZFLmj Un25nA56ndiKXlRB h4667svd_PxDXwfq 6kTHKzFHmpFCvUEH qEAWmbv2oPT3ZGrX v-aY3GntyLr3e_20 44UrHR9Vo5PDNIeH M3nlBQvQ5Qr5USSV sP-7Z4I__U3J8Sbz Y-3HkdX_yzpCWFGP登录后在 Bots 页面找到三个 Bot，通过 Web Chat 直接对话体验。三个 Bot，各司其职Customer Service Bot（客服 Bot）——面向终端客户。客户通过 Discord 或 Web 联系客服 Bot，查询自己的订单、申请退款。客服 Bot 可以查看订单列表和详情，但没有任何链上操作权限。当客户要求退款时，客服 Bot 将退款操作委派给 Payment Agent。Operations Bot（运营 Bot）——面向内部运营人员。运营人员通过它查看订单状态、查询支付钱包余额、核查链上交易记录。它同样没有直接的链上操作权限，查余额和查交易需要委派给 Payment Agent。Payment Agent Bot（支付 Bot）——纯后端执行层，不直接面向任何人。它只接受客服 Bot 和运营 Bot 的委派调用，负责所有链上操作：退款转账、查询余额、查询交易状态。它持有支付钱包的凭证（私钥由平台加密托管，Agent 本身看不到）。权限矩阵三个 Bot 共享同一个 Payment Gateway 资源，但权限完全不同：Bot面向直接权限委派权限Customer Service终端客户查询订单退款、查余额、查交易Operations内部运营查询订单查余额、查交易（不能退款）Payment Agent不面向人所有链上操作—同一个 Payment Agent，被客服 Bot 委派时可以退款，被运营 Bot 委派时只能查询。权限由调用方的委派约束决定，不是由 Payment Agent 自身决定。演示流程场景一：客户退款（Customer Service Bot）第 1 步：客户查询订单客户对客服 Bot 说："I'd like to check my orders"客服 Bot 调用 pg_list_orders，返回订单列表，包含客户名、服务项目、金额（ETH）、状态。第 2 步：客户申请退款（链上真实转账）客户说："I want a refund for ORD-003"客服 Bot 先调用 pg_get_order 查看订单详情，确认该订单状态为 paid（可退款）。然后客服 Bot 自动委派给 Payment Agent 执行退款。Payment Agent 调用 pg_refund_order，向客户的钱包地址发起一笔真实的 Sepolia ETH 转账，返回交易哈希和 Etherscan 链接。客户点击链接即可在区块浏览器上验证退款交易。第 3 步：确认退款到账客户说："Can you check the transaction status?"委派给 Payment Agent，调用 pg_get_tx_status，返回交易的上链状态和区块确认信息。场景二：运营查账（Operations Bot）第 1 步：查看待处理订单运营人员对运营 Bot 说："Show me all pending orders"运营 Bot 调用 pg_list_orders，返回待处理订单列表。第 2 步：查看钱包余额运营人员说："Check wallet balance"运营 Bot 委派 Payment Agent 调用 pg_get_balance，返回当前钱包 ETH 余额。第 3 步：核查交易记录运营人员说："Check the status of transaction 0x..."运营 Bot 委派 Payment Agent 调用 pg_get_tx_status，返回交易详情。场景三：权限隔离验证在 Monstrum 管理后台分别查看三个 Bot 的工具列表：Customer Service Bot 只有 pg_list_orders、pg_get_order 两个直接工具Operations Bot 同样只有查单的直接工具，委派只能查余额和交易，无法触发退款Payment Agent Bot 拥有所有链上工具这是平台级的工具可见性过滤和委派约束，不依赖 prompt。场景四：审计日志在管理后台的 Audit Logs 页面，可以看到每一次操作的完整记录：哪个 Bot 执行了什么工具、传入了什么参数、返回了什么结果、什么时间执行的。退款的链上交易哈希都被记录在案。核心机制权限隔离这不是通过 prompt 实现的"请不要调用支付工具"。Monstrum 在 LLM 调用之前，就通过 ToolResolver 过滤了工具列表——Customer Service Bot 和 Operations Bot 的 LLM 上下文中根本不存在 pg_refund_order 这个工具，所以它们在技术层面就不可能直接发起链上交易。委派约束当客服 Bot 需要执行退款时，它通过平台的 Bot-to-Bot 委派机制调用 Payment Agent。委派绑定上配置了 DelegateConstraints，限制 Payment Agent 在此次委派中能使用的工具范围。即使 Payment Agent 本身有所有链上操作权限，委派约束也会收窄它的有效权限。这防止了 Confused Deputy 攻击——即使客服 Bot 被恶意指令操控，它能委派的操作范围也被平台锁死。凭证安全支付钱包的私钥存储在 Monstrum 的凭证保险库中，Agent 永远看不到明文私钥。每次 Agent 调用支付工具时，平台从保险库解密私钥，注入到执行上下文中完成链上签名，签名完成后私钥即销毁。即使 Agent 被提示注入攻击，也无法泄露私钥。真实区块链集成Demo 中的订单数据是 mock 的（模拟第三方订单系统），但链上交易是真实的。每次退款都是 Sepolia 测试网上的真实 ETH 转账，可在 Etherscan 上验证。在生产环境中，订单数据对接真实的订单系统即可，插件代码只需替换数据源。技术栈层技术平台后端Python 3.10 / FastAPI / SQLAlchemy Async / PostgreSQL平台前端React 18 / Ant Design 5 / TypeScript / Vite插件 SDKPython / Web3.py / httpx区块链EVM (Sepolia Testnet)部署GCP Cloud Run / Cloud SQL安全凭证加密 / JWT / 三层权限模型Payment Gateway 只是 Monstrum 的一个示例插件。平台已内置 SSH、MCP、Web 搜索、Web3 等资源类型，并支持通过声明式插件扩展任意工具集成，亦可通过远程Agent客户端将用户设备桥接至平台以达到类似OpenClaw一样的体验。无论是调用第三方API、操作数据库、管理云基础设施，还是跨 Agent 协作编排——只要 AI Agent 需要"做事"而不只是"说话"，Monstrum 都能提供操作级权限隔离、凭证托管和完整审计，确保 Agent的行为边界由平台强制划定，而非依赖 prompt 自律。赛道对标Track 1 — 支付基础设施AI Agent 可调用的链上支付工具真实 EVM 区块链结算（非模拟）插件架构可扩展到任意 EVM 兼容链凭证托管确保私钥安全Track 2 — Agent 共生体操作级权限隔离：不同 Bot 看到不同工具集凭证托管：Agent 无法接触明文密钥委派约束：调用方决定被调用方的有效权限完整审计：每次操作可追溯