开源AI智能体编排平台Mission Control：轻量部署与生产级管理实践

1. 项目概述：一个为AI智能体打造的“任务控制中心”

如果你正在或计划使用AI智能体（Agent）来完成工作，无论是代码生成、数据分析还是自动化流程，你迟早会面临一个现实问题：如何有效地管理和协调这些“数字员工”？当你的智能体从一个变成五个、十个，甚至更多时，你会发现，单纯通过命令行调用或者零散的脚本，很快就会陷入混乱。任务状态不明、成本失控、智能体之间缺乏协作、安全审计缺失……这些问题会迅速消耗掉AI带来的效率红利。

这正是Mission Control要解决的核心痛点。它不是一个全新的AI框架，而是一个开源的、自托管的智能体编排与控制面板。你可以把它想象成一个为AI智能体团队打造的“任务控制中心”或“数字作战室”。它的目标很明确：让你在一个统一的界面里，清晰地看到所有智能体的状态、任务队列、执行成本、安全态势，并能像管理一个项目团队一样，对它们进行任务派发、流程编排和质量审查。

我最初接触这类工具，是因为团队内部同时运行着基于不同框架（如LangChain、CrewAI）开发的多个智能体。每个智能体都有自己的日志、状态文件和调用方式，跨智能体的任务流转全靠人工在聊天记录里复制粘贴，成本统计更是无从谈起。Mission Control的出现，相当于为这个混乱的战场提供了一个清晰的指挥视图和标准化的操作流程。

2. 核心设计理念与架构解析

Mission Control的设计哲学非常务实，可以概括为“轻量、自治、可观测”。这三点直接决定了它的技术选型和功能边界，理解这些对于后续的部署和使用至关重要。

2.1 为什么选择“零外部依赖”与SQLite？

在项目介绍中，“zero external dependencies, powered by SQLite”这句话非常醒目。这并非为了技术上的标新立异，而是为了解决智能体编排工具在实际部署中的最大障碍：复杂性。

许多类似的编排系统或监控面板，动辄要求搭配Redis、PostgreSQL、消息队列等一整套中间件。对于个人开发者、小团队或只是想快速验证一个工作流的场景来说，这无异于一道高墙。你需要考虑数据库的安装、配置、备份、网络连通性，以及这些组件本身的资源消耗。

Mission Control反其道而行之，将SQLite作为唯一的数据存储。SQLite是一个进程内的库，无需单独的服务进程。这意味着：

1. 部署极致简化：整个系统就是一个Next.js应用。你只需要Node.js环境，运行pnpm start，它就带着自己的数据库一起启动了。没有额外的服务需要维护。
2. 数据本地化与隐私：所有数据（任务、日志、成本、配置）都存储在你服务器本地的一个.db文件中。这对于处理敏感数据或需要在隔离网络环境中运行的用户来说，是巨大的优势。
3. 降低运维心智负担：你不需要成为DBA。备份？复制那个.db文件即可。迁移？把文件带走就行。对于大多数智能体工作流来说，其数据量和并发访问模式，SQLite完全能够胜任。

当然，这也有取舍。SQLite在高并发写入场景下可能存在瓶颈。但Mission Control的定位很聪明：它主要服务于中小规模的智能体团队管理和观测，而非超大规模、毫秒级响应的交易系统。对于绝大多数自动化、分析、内容生成类任务，这个架构是完美匹配的。

注意：虽然SQLite简化了部署，但在生产环境多实例部署时，需要小心处理数据库文件共享和锁的问题。官方推荐的Docker部署或单实例部署是更稳妥的方式。

2.2 整体架构：一个中心化的SPA指挥台

Mission Control采用了典型的现代Web应用架构，但每个模块都紧密围绕智能体管理的核心需求构建。

用户浏览器 (访问 localhost:3000) | v [Next.js 16 应用服务器] <--- (WebSocket/SSE 实时推送) | | | | v v [业务逻辑层] [实时事件层] (Zustand状态管理) (处理智能体心跳、任务更新) | | (所有数据操作) v [数据访问层] (better-sqlite3驱动) | v [SQLite数据库文件] (.data/mission-control.db)

前端（SPA Shell）：基于Next.js 16的App Router和React 19构建的单页应用。它包含了多达32个功能面板（Panels），从任务看板、智能体状态到安全审计、成本图表，所有功能都集成在一个无需刷新页面的应用内。这种设计提供了类似桌面软件的操作体验，非常适合需要频繁切换视图的操作员。

后端（API Routes）：Next.js的API Routes承载了全部101个RESTful端点。这里处理所有核心业务：智能体注册、任务创建与派发、技能管理、安全扫描、成本计算等。由于是单体应用，前后端通信没有跨域烦恼，部署简单。

实时通信（WebSocket + SSE）：这是控制面板的“生命线”。智能体的状态（在线、离线、忙碌）、任务的进度更新、新的日志信息，都需要实时推送到前端。Mission Control混合使用了WebSocket（用于双向高频通信，如聊天）和Server-Sent Events（用于服务器向客户端的单向流式更新，如日志尾随），确保了仪表盘数据的“零陈旧”。

数据层（SQLite + better-sqlite3）：使用better-sqlite3这个同步驱动（配合WAL模式），提供了简单高效的数据访问。所有表结构通过一个包含39个迁移文件的系统进行版本管理，保证了升级时的数据平滑迁移。

状态管理（Zustand）：在前端，使用Zustand来管理复杂的应用状态。相比于Redux，Zustand的API更简洁，很好地管理了如当前选中的智能体、任务过滤器、面板布局等全局状态。

2.3 安全与多租户设计思路

作为一个可能管理着敏感任务和数据的控制中心，安全不是可选项。Mission Control在安全设计上采用了“默认安全”和“深度防御”的策略。

1. 基于角色的访问控制（RBAC）：这是权限管理的基石。系统预定义了三种角色：

   • 查看者（Viewer）：只能看，不能动。适合给项目经理或利益相关者提供只读视图。
   • 操作员（Operator）：可以执行绝大多数日常操作，如创建任务、分配任务、与智能体聊天、安装技能。这是大多数团队成员的角色。
   • 管理员（Admin）：拥有最高权限，可以管理用户、修改系统设置、执行危险操作（如重置数据库）。这个角色必须严格控制。

2. 双重认证机制：

   • 会话Cookie：用于Web UI交互，提供7天的持久登录体验。
   • API密钥：用于自动化脚本、CI/CD流水线或其他程序调用。每个密钥可以绑定到特定角色，并且可以在UI中随时吊销。

3. 安全事件与信任评分：这不是一个简单的日志系统。它会主动分析智能体的行为，例如：

   • 秘密检测：扫描智能体输入/输出中是否意外包含了API密钥、密码等敏感信息。
   • MCP工具调用审计：记录智能体通过Model Context Protocol调用了哪些外部工具，参数是什么。
   • 注入尝试跟踪：监测是否有潜在的提示词注入攻击模式。 基于这些事件，系统会为每个智能体计算一个动态的“信任评分”（0-100分），为操作员提供直观的风险评估。

4. 钩子配置文件：安全策略不能一刀切。Mission Control允许你为不同严格级别的环境设置“钩子配置文件”：

   • 最小化（Minimal）：仅记录安全事件，不阻断。适用于高度信任的内部开发环境。
   • 标准（Standard）：对高风险操作（如执行shell命令、访问网络）进行询问或记录。适用于大多数生产前环境。
   • 严格（Strict）：对任何可疑操作都进行阻断，并立即告警。适用于处理极高敏感数据的环境。

5. 多租户工作区：通过/api/super/*接口，管理员可以创建完全隔离的工作区（租户）。每个工作区拥有自己独立的数据库环境、状态目录和网关配置。这使得Mission Control可以作为一个SaaS平台的核心，或者在一个组织内为不同部门/项目组提供完全隔离的沙箱环境。

3. 核心功能深度剖析与实操指南

Mission Control的功能面板多达32个，但核心围绕几个关键工作流。下面我将拆解最重要的几个功能，并附上从零开始的实操步骤和避坑指南。

3.1 智能体（Agents）管理：从注册到退休的全生命周期

智能体是Mission Control管理的核心单元。它可以是任何能够通过API报告状态和接收任务的AI程序。

3.1.1 智能体注册的三种模式

1. 手动注册（最直接）：通过Dashboard UI或调用/api/agents/registerAPI。你需要提供智能体的基本元数据，如名称、角色描述、支持的模型、能力标签等。注册后，系统会为该智能体生成一个唯一的ID和认证令牌。

2. 本地自动发现：这是非常方便的功能。Mission Control会扫描本地几个标准目录来发现智能体：

   • ~/.agents/(通用目录)
   • ~/.codex/agents/(针对Claude Code的智能体)
   • ~/.claude/agents/(针对Claude Desktop的智能体) 对于遵循这些目录结构的智能体项目，它们会在Mission Control启动后自动出现在“未注册智能体”列表中，你只需点击“批准”即可完成注册。

3. 通过网关框架适配器注册：这是为集成现有生态而设计。Mission Control内置了针对流行框架的适配器：

   • OpenClaw：如果设置了OPENCLAW_STATE_DIR环境变量，Mission Control会自动连接到OpenClaw网关，并将其管理的所有智能体同步过来。
   • CrewAI / LangGraph / AutoGen：通过框架特定的适配器，可以将这些框架中定义的“Agent”角色注册到Mission Control，实现统一监控。
   • Claude SDK：直接注册通过Claude官方SDK创建的智能体。

实操步骤：通过API注册一个研究型智能体假设我们有一个用Python写的、专门进行网络调研的智能体research_bot.py，我们需要让它向Mission Control报到。

# 1. 首先，从Mission Control获取一个API密钥（在Settings面板） # 假设我们拿到了密钥：mc_sk_1234567890abcdef # 2. 在research_bot.py的启动逻辑中，添加注册代码 import requests import json MC_BASE_URL = "http://localhost:3000" API_KEY = "mc_sk_1234567890abcdef" registration_payload = { "name": "deep-researcher", "role": "高级网络研究员", "capabilities": ["web_search", "summarization", "fact_checking"], "model": "claude-3-5-sonnet-20241022", "metadata": { "version": "1.0", "author": "你的团队" } } headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } try: response = requests.post( f"{MC_BASE_URL}/api/agents/register", headers=headers, data=json.dumps(registration_payload) ) if response.status_code == 200: agent_info = response.json() agent_id = agent_info['id'] agent_token = agent_info['token'] # 保存这个token，用于后续心跳和任务拉取 print(f"智能体注册成功！ID: {agent_id}") else: print(f"注册失败: {response.status_code}, {response.text}") except Exception as e: print(f"注册请求异常: {e}")

3.1.2 智能体SOUL系统与心跳

注册成功后，智能体需要定期向Mission Control发送“心跳”以表明自己在线。心跳间隔建议在30-60秒。如果超过一定时间（如90秒）未收到心跳，该智能体在面板上的状态将变为“离线”或“失联”。

更高级的是SOUL（State Of Unified Lifecycle）系统。它允许智能体将其工作区（代码、配置文件、记忆文件）的状态与Mission Control的数据库进行双向同步。这意味着：

• 你在Mission Control上为智能体安装一个新技能，该技能文件会自动同步到智能体本地的技能目录。
• 智能体在本地生成了一份记忆文件，Mission Control的“记忆浏览器”能立即索引并展示其内容。 这个功能通过lib/skill-sync.ts和文件系统监听器实现，确保了控制面板与智能体本地环境的一致性。

避坑指南：心跳丢失的常见原因

1. 网络问题：确保智能体所在机器能访问Mission Control服务器的/api/agents/[id]/heartbeat端点。
2. 防火墙/代理：如果Mission Control部署在Docker内，而智能体在宿主机，需要使用host.docker.internal作为主机名，并确保端口映射正确。
3. 智能体进程卡死：在智能体代码中做好异常捕获，确保即使主任务失败，心跳线程也能继续运行。
4. 时钟不同步：如果服务器和智能体机器时间相差太大，可能导致会话过期等问题。确保使用NTP同步时间。

3.2 任务（Tasks）看板：像管理项目一样管理AI工作流

任务系统是Mission Control最直观的功能。它采用看板（Kanban）视图，将任务流程分为六个清晰的状态列，完美契合了从创建到完成的完整生命周期，尤其是加入了“质量审查”这一关键环节。

3.2.1 任务状态流与质量门禁（Quality Gates）

1. 收件箱（Inbox）：新创建的任务默认进入这里。它还没有被分配给任何智能体。
2. 已分配（Assigned）：操作员或将来自动化规则将任务分配给了某个智能体。任务进入该智能体的专属队列。
3. 进行中（In Progress）：智能体通过API认领了任务并开始执行。此时任务会显示执行者信息和开始时间。
4. 审查（Review）：智能体标记任务为“完成”，但需要人工或另一个“审查者”智能体进行结果复核。这是防止AI“胡言乱语”或跑偏的第一道防线。
5. 质量审查（Quality Review）：这是可选的、更严格的门禁。任务必须经过内置的Aegis审查系统检查。Aegis可以根据预定义的规则（如代码规范检查、事实准确性核对、敏感信息过滤）自动评分，低于阈值则打回。这个环节确保了输出符合生产标准。
6. 已完成（Done）：通过所有审查，任务正式关闭。所有相关的输入、输出、日志、耗时和Token消耗都会被归档，供后续审计和分析。

实操步骤：创建一个需要质量审查的代码生成任务假设我们需要让一个智能体生成一个Python数据清洗函数，并要求通过代码风格检查。

# 使用CURL通过API创建任务 curl -X POST "http://localhost:3000/api/tasks" \ -H "Authorization: Bearer mc_sk_1234567890abcdef" \ -H "Content-Type: application/json" \ -d '{ "title": "生成用户数据清洗函数", "description": "请生成一个Python函数，名为`clean_user_data`，接收一个包含`name`, `email`, `age`字段的字典列表，进行以下处理：1. 姓名去除首尾空格并首字母大写；2. 邮箱转为小写并验证格式；3. 年龄转换为整数，无效值设为None。返回清洗后的列表。", "assigned_to": "code-specialist", # 指定给编码专家智能体 "priority": "high", "project": "data-pipeline", "metadata": { "require_quality_gate": true, "quality_gate_rules": ["code_style_python", "no_hardcoded_secrets"] } }'

创建后，你可以在Dashboard上拖拽任务卡片在不同列之间移动。当code-specialist智能体完成任务后，它会调用API将任务推进到“审查”列。此时，Aegis系统会自动运行配置的代码风格检查规则。如果代码中有不符合PEP 8的地方或疑似硬编码的密码，Aegis会拒绝通过，并将任务打回“进行中”并附上失败原因。只有所有检查通过，任务才能进入“已完成”。

3.2.2 自然语言定时任务

这是提升自动化程度的一个亮点功能。你不再需要记忆cron语法。例如，你可以创建一个任务，标题为“每日早报生成”，并在描述中写上“schedule: every weekday at 8:30am”。Mission Control的后台调度器会解析这个自然语言字符串，将其转换为标准的cron表达式（如30 8 * * 1-5），并创建一个任务模板。

当调度时间触发时，系统会自动从这个模板克隆出一个新的、带有当日日期的具体任务（如“每日早报生成 - 2024-01-15”），并将其放入收件箱。这非常适合需要定期执行的报告生成、数据同步、系统健康检查等场景。

实操心得：高效使用任务看板

• 利用标签和项目：为任务添加标签（如bug,feature,urgent）和归属项目，可以在看板顶部进行快速过滤，在任务量大的时候非常有用。
• 设置自动分配规则：在“设置”->“编排规则”中，可以配置基于任务标签、标题关键词或项目自动分配给特定智能体的规则。例如，所有标签包含research的任务自动分配给deep-researcher智能体。
• 关注活动流：每个任务卡片的历史记录和右侧的全局活动流面板，能让你清晰看到谁在什么时候做了什么，对于团队协作和问题追溯至关重要。

3.3 技能（Skills）中心：安全地扩展智能体能力

智能体的能力由其“技能”定义。一个技能本质上是一个可执行的模块，它告诉智能体如何调用一个特定的工具或API（例如，搜索网络、查询数据库、发送邮件）。

3.3.1 技能的生命周期管理

Mission Control的“技能中心”面板提供了一个集中的技能市场和管理界面。

1. 浏览与发现：技能中心会从多个源获取技能列表：
   • 本地目录：扫描~/.agents/skills,~/.codex/skills等路径。
   • 远程注册中心：内置支持从ClawdHub和skills.sh这样的公共技能注册中心拉取技能列表。你可以像浏览应用商店一样浏览可用的技能。
2. 安全扫描（核心安全特性）：在安装任何技能（尤其是来自远程源）之前，Mission Control会启动一个内置的安全扫描器。这个扫描器会检查技能文件的以下风险：
   • 提示词注入：技能描述或系统提示中是否包含可能劫持主提示词的恶意内容。
   • 凭证泄露：代码中是否硬编码了API密钥、密码等。
   • 数据外泄：技能是否包含将数据发送到外部不可信域名的代码。
   • 混淆代码：代码是否被故意混淆以隐藏其真实意图。
   • 危险命令：是否包含执行rm -rf /、格式化磁盘等危险Shell命令。 扫描结果会以风险评分的形式展示，只有低风险或经你确认的技能才能被安装。
3. 安装与同步：点击安装后，技能文件会被下载并存储到本地对应的技能目录。同时，技能元数据（名称、描述、版本、参数）会被记录到Mission Control的数据库中。通过SOUL系统，这个新技能会自动同步给所有配置了相应技能目录的智能体。
4. 更新与卸载：你可以查看已安装技能的版本，检查更新，或一键卸载。卸载操作会同时从磁盘和数据库中移除该技能。

3.3.2 创建一个自定义技能

假设我们想为智能体添加一个“查询内部知识库”的技能。

1. 创建技能文件：在~/.agents/skills/目录下创建一个JSON文件，例如query_wiki.json。

{ "name": "query_internal_wiki", "version": "1.0.0", "author": "Your Team", "description": "根据关键词查询团队内部知识库，返回相关文档摘要。", "input_schema": { "type": "object", "properties": { "keyword": { "type": "string", "description": "搜索关键词" }, "max_results": { "type": "number", "description": "最大返回结果数", "default": 5 } }, "required": ["keyword"] }, "handler": { "type": "http", "method": "POST", "url": "https://your-internal-wiki-api.com/search", "headers": { "Authorization": "Bearer ${env:WIKI_API_KEY}" } } }

2. 将其放入技能目录：Mission Control会在下次扫描时发现它。
3. 在Dashboard中批准：进入“技能中心”->“本地技能”，你会看到这个新技能。点击“扫描”，安全扫描器会分析它。由于它调用了外部API，扫描器会提示“存在网络调用”，你需要确认这个API端点是否可信。批准后，技能状态变为“可用”。
4. 分配给智能体：在智能体管理面板，编辑deep-researcher智能体，在“技能”选项卡中勾选query_internal_wiki。保存后，该智能体就具备了查询知识库的能力。

注意事项：技能安全是重中之重

• 严格审核第三方技能：永远不要盲目安装来自不明来源的技能。充分利用内置的安全扫描，并仔细阅读技能的源代码（如果是开源的）。
• 管理环境变量：像上面例子中的${env:WIKI_API_KEY}，技能会从智能体的运行环境中读取变量。确保这些环境变量中存储的是最小权限的密钥，并定期轮换。
• 限制网络访问：对于在严格安全环境下运行的Mission Control，可以考虑在网络层面限制智能体容器或进程的出口流量，只允许访问必要的技能API端点。

3.4 成本追踪（Cost Tracking）：让AI开销一目了然

使用大模型API，成本是绕不开的话题。Mission Control的成本追踪面板通过聚合所有智能体的Token使用情况，提供了多维度的开销分析。

3.4.1 数据来源与计算原理

成本数据主要来自两个方面：

1. 智能体主动上报：当智能体调用大模型API（如OpenAI、Anthropic）后，它需要在向Mission Control发送的心跳或任务完成报告中，附带本次调用的input_tokens、output_tokens和model名称。
2. Claude Code集成：如果连接了Claude Code，Mission Control会自动从~/.claude/projects/目录下的会话文件中读取Token使用数据。

系统内部维护了一个模型价格表（例如：claude-3-5-sonnet输入$3/百万Token，输出$15/百万Token）。当收到Token数据后，它会实时计算成本：成本 = (输入Token数 * 输入单价 + 输出Token数 * 输出单价) / 1,000,000

3.4.2 面板功能解读

成本面板通常包含以下几个视图：

• 总览仪表盘：显示今日、本周、本月的总成本、总Token消耗量、以及环比变化。
• 按模型分布：一个饼图或条形图，清晰展示哪个模型最“烧钱”。这能帮助你优化策略，例如，是否可以将一些对质量要求不高的任务切换到更便宜的模型。
• 按智能体分布：查看每个智能体的开销，找出“成本大户”。也许某个智能体的任务设计有问题，导致了不必要的长文本生成或重复调用。
• 按项目分布：如果将任务关联到不同项目，这里可以核算每个项目的AI成本，便于向客户或内部部门进行成本分摊。
• 时间趋势图：折线图展示成本随时间的变化，帮助你发现使用高峰，并评估扩容或优化措施的效果。

实操步骤：让自定义智能体上报成本你需要修改智能体的代码，在调用LLM API后，将用量数据发送给Mission Control。

# 假设使用OpenAI API from openai import OpenAI import requests client = OpenAI(api_key=os.environ["OPENAI_API_KEY"]) def ask_llm(prompt): response = client.chat.completions.create( model="gpt-4", messages=[{"role": "user", "content": prompt}] ) # 从响应中获取Token用量 input_tokens = response.usage.prompt_tokens output_tokens = response.usage.completion_tokens model_used = response.model # 上报成本数据到Mission Control mc_cost_url = f"{MC_BASE_URL}/api/agents/{agent_id}/report_tokens" cost_data = { "input_tokens": input_tokens, "output_tokens": output_tokens, "model": model_used, "task_id": current_task_id # 如果关联了任务 } requests.post(mc_cost_url, json=cost_data, headers={"Authorization": f"Bearer {agent_token}"}) return response.choices[0].message.content

避坑指南：成本追踪的准确性

• 模型价格更新：Mission Control内置的模型价格表可能滞后于API提供商的最新价格。对于成本敏感的项目，建议定期检查并手动在设置中更新模型单价。
• 缓存的影响：如果使用了具有缓存功能的LLM服务（如某些Azure OpenAI配置），实际消耗的Token和产生的成本可能低于API返回的用量。需要根据服务商账单进行校准。
• 非LLM成本：目前主要追踪LLM API成本。如果智能体还调用了其他付费API（如搜索引擎、数据库），这部分成本需要自行通过其他方式监控。

4. 生产环境部署与安全加固实战

将Mission Control用于个人项目可以快速开始，但用于团队或生产环境，则必须考虑安全性和可靠性。以下是一套从零开始的、加固的生产部署方案。

4.1 部署方式选择与配置

方案一：Docker Compose（推荐）这是最简洁、可重现的部署方式。项目根目录下的docker-compose.yml已经提供了基础配置。

# docker-compose.yml (官方精简版) version: '3.8' services: mission-control: image: ghcr.io/builderz-labs/mission-control:latest container_name: mission-control restart: unless-stopped ports: - "3000:3000" environment: - AUTH_USER=admin # 建议通过secret管理 - AUTH_PASS=${ADMIN_PASSWORD} # 使用强密码，并通过.env文件传入 - MISSION_CONTROL_DATA_DIR=/data - OPENCLAW_STATE_DIR=/path/on/host/.openclaw # 挂载宿主机上的OpenClaw状态目录 volumes: - mission-control-data:/data - /path/on/host/.openclaw:/path/on/host/.openclaw:ro # 只读挂载，防止容器篡改 networks: - mc-network volumes: mission-control-data: networks: mc-network: driver: bridge

运行：ADMIN_PASSWORD=your_strong_password_here docker-compose up -d

方案二：使用加固配置文件项目还提供了一个docker-compose.hardened.yml，它叠加了额外的安全限制：

• 只读根文件系统：防止攻击者在容器内写入恶意文件。
• 能力降级：移除容器内不必要的Linux内核能力（如SYS_ADMIN）。
• 无特权运行：不以root用户运行。
• 安全配置：设置更严格的环境变量。

运行：docker-compose -f docker-compose.yml -f docker-compose.hardened.yml up -d

方案三：直接部署在VPS如果你不想用Docker，可以在Ubuntu 22.04 LTS服务器上直接部署。

# 在VPS上 # 1. 安装依赖 sudo apt update && sudo apt install -y nodejs npm git sudo npm install -g pnpm # 2. 克隆项目 git clone https://github.com/builderz-labs/mission-control.git cd mission-control # 3. 安装依赖并构建 pnpm install pnpm build # 4. 配置环境变量 cp .env.example .env.production # 编辑 .env.production，设置强密码、API_KEY，以及 MC_ALLOWED_HOSTS # 5. 使用PM2等进程管理器运行 sudo npm install -g pm2 pm2 start pnpm --name "mission-control" -- start pm2 save pm2 startup # 设置开机自启

4.2 关键安全配置详解

1. MC_ALLOWED_HOSTS(必须配置)：这是防止主机头攻击的关键。在生产环境中，务必设置此变量为你的域名。例如：MC_ALLOWED_HOSTS=mission.yourcompany.com。如果通过IP访问，也要加上IP。
2. 使用反向代理和TLS：永远不要将Mission Control直接暴露在公网。使用Nginx或Caddy作为反向代理，并配置HTTPS。

   # Nginx 配置示例 (部分) server { listen 443 ssl http2; server_name mission.yourcompany.com; ssl_certificate /path/to/fullchain.pem; ssl_certificate_key /path/to/privkey.pem; # ... 其他SSL优化配置 ... location / { proxy_pass http://localhost:3000; # 指向Mission Control容器或进程 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; # 支持WebSocket proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 设置安全头部 add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Content-Type-Options "nosniff" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; } }

3. 修改默认凭证：安装后第一件事就是在Web UI中修改默认的admin密码，并生成新的、复杂的API密钥，删除安装时生成的默认密钥。
4. 配置防火墙：在VPS或主机防火墙上，只允许443端口（HTTPS）入站，3000端口仅允许本地（127.0.0.1）访问。
5. 定期备份数据目录：定期备份Docker volume或MISSION_CONTROL_DATA_DIR指向的目录，其中包含SQLite数据库文件。

4.3 网关连接与网络隔离

如果你的智能体运行在Mission Control所在服务器之外的其他机器上，就需要配置网关连接。

典型问题：Docker容器内的Mission Control如何连接宿主机上的OpenClaw网关？在.env或docker-compose.yml中，设置：

OPENCLAW_GATEWAY_HOST=host.docker.internal

host.docker.internal是Docker提供的一个特殊域名，指向宿主机。确保宿主机上的OpenClaw网关服务端口（通常是8181）对Docker网络是可达的。

更安全的网络模式：创建一个自定义的Docker网络，将Mission Control容器和运行智能体的容器都加入这个网络。这样它们可以通过容器名进行通信，完全与宿主机网络隔离。

# docker-compose.yml 部分 services: mission-control: networks: - agent-network my-ai-agent: image: your-agent-image networks: - agent-network networks: agent-network: driver: bridge

然后在Mission Control配置中，将OPENCLAW_GATEWAY_HOST设置为my-ai-agent（容器名）和对应的端口。

5. 故障排查与性能优化实录

在实际使用中，你可能会遇到一些问题。以下是我在部署和运维过程中积累的一些常见问题与解决方法。

5.1 常见问题排查表

5.2 性能优化建议

1. 数据库优化：

   • 启用WAL模式：SQLite的Write-Ahead Logging模式可以显著提升并发读性能。Mission Control默认已启用。
   • 定期清理：对于长期运行的系统，可以定期归档或清理旧的activities（活动日志）和agent_heartbeats（心跳记录）表中的数据，这两个表增长最快。可以通过设置任务，定期执行DELETE FROM activities WHERE created_at < date('now', '-30 days')。
   • 考虑SSD：将.data目录放在SSD磁盘上，能极大提升数据库IO性能。

2. 前端优化：

   • 控制活动流数量：在“活动流”面板，设置一个合理的默认时间范围过滤器（如“最近24小时”），避免一次性加载海量历史数据。
   • 按需加载面板：Mission Control的32个面板是懒加载的。只有当你点击或需要时，才会加载对应的代码和初始数据。无需担心一次性加载所有功能。

3. 智能体集成优化：

   • 批量上报：如果智能体执行大量短任务，频繁调用report_tokensAPI可能会产生开销。可以考虑在智能体端缓存Token数据，每分钟或每完成10个任务后批量上报一次。
   • 错误处理与重试：在智能体与Mission Control的通信代码中，务必加入健壮的错误处理和指数退避重试机制，避免因网络瞬时波动导致任务状态不一致。

5.3 高可用性考量

Mission Control本身设计为轻量级单实例应用，其SQLite后端意味着它并非一个分布式高可用系统。对于要求极高的生产环境，可以考虑以下策略：

1. 冷备份：定期（如每小时）使用sqlite3 .data/mission-control.db ".backup backup.db"命令进行在线备份，并将备份文件传输到异地。
2. 热备（主动-被动）：部署两个Mission Control实例，共享一个网络存储（如NFS）上的数据库文件。使用负载均衡器将流量指向主实例。如果主实例故障，手动将负载均衡器指向备用实例。注意：SQLite不支持多进程同时写入，因此同一时间只能有一个实例处于活跃写入状态。
3. 职责分离：将Mission Control的核心功能（任务调度、状态管理）与数据存储分离的架构变更是一个复杂的工程。如果团队有强烈的高可用需求，可能需要考虑将其数据层迁移到PostgreSQL，但这超出了当前项目的范围，需要深度定制。

我个人在管理一个约15个智能体的中型项目时，采用单实例Docker部署配合每日备份的策略，运行半年多来非常稳定。它的轻量化和“开箱即用”的特性，使得运维负担极低，让我们能更专注于智能体业务逻辑本身，而不是基础设施的维护。对于绝大多数AI自动化项目来说，Mission Control提供的可靠性和功能已经绰绰有余。