用MCP把脑电波接入Claude：实时感知专注度的实践指南

标题里的结构其实很直白：bci-mcp 这个项目，就是把脑电设备（EEG）采集到的实时脑状态信号，通过 MCP（Model Context Protocol）协议，流式地送进 Claude，让 AI 不再只盯着你敲的文本，而是能感知你当下的专注度、放松度、认知负荷。拆开看就是 Brain-Computer Interface 和 Model Context Protocol 的组合：一套采集，一套解析，一套接入。我把它完整跑通之后，最强烈的感受是：消费级脑电套装到 Claude 之间，差距真的没有想象中那么大——但中间要踩的坑，也真的不少。

这篇文章不是项目说明书，更像是我把 bci-mcp 从零到一折腾出来的全过程记录。里面有完整的架构拆解、关键代码、配置方式、排坑记录，还有我实测下来真正能玩的场景。适合两类人看：一类是玩过 EEG 头环但不知道怎么跟 AI 应用打通的人；另一类是熟 Claude、MCP，但完全没碰过脑电信号的新手。两头我都会尽量照顾到。

1. 项目拆解：bci-mcp 到底在做什么

1.1 三块拼图先各自说清楚

第一块是 EEG 采集。脑电设备这块，消费级市场其实已经很成熟了，Muse、NeuroSky MindWave、Emotiv 这些都是拿来即用的东西。它们通过干电极或者半干电极贴在头皮上，采集大脑皮层神经元的电活动，经过放大、滤波、模数转换后，以几十到上百 Hz 的采样率输出原始波形。以 Muse 2 为例，它有四个通道（AF7、AF8、TP9、TP10），采样率 256 Hz，通过蓝牙低功耗（BLE）把数据发到电脑或手机。原始数据长什么样？一秒钟 256 个点，每个点大概是一个微伏级别的电压波动，肉眼看起来就是一条噪声很大的曲线。

第二块是脑状态解析。原始 EEG 波形本身没什么直接用途，真正的信息藏在频域里。把一段 EEG 信号做傅里叶变换，就能拆出不同频段的功率：Delta（0.5-4 Hz）对应深睡，Theta（4-8 Hz）对应放松和灵感状态，Alpha（8-13 Hz）对应闭眼放松，Beta（13-30 Hz）对应主动思考和专注，Gamma（30-45 Hz）对应高阶认知加工。bci-mcp 要做的，就是把这些频段功率实时计算出来，再聚合成"专注度""放松度"这种 AI 能直接消费的指标。

第三块是 MCP 接入。MCP 是 Anthropic 推出的开放协议，核心作用是把 AI 应用和外部工具、数据源解耦。你可以把它想成 AI 世界的 USB-C 接口——统一了插口标准之后，任何支持 MCP 的客户端（Claude Desktop、Claude Code）都能即插即用地连接任意 MCP 服务端。在 bci-mcp 这个项目里,EEG 数据的采集和处理逻辑整体封装成一个 MCP Server，对外暴露"查询脑状态"这类工具，Claude 随时可以调用。

1.2 这套链路解决了什么核心问题

过去想做"AI 感知人类生理状态"这件事，通常要自己写一套 WebSocket 服务、定义一套私有协议、再给 Claude 写一堆工具调用的胶水代码。问题是这套东西每换一个客户端就要重写一遍，而且 Claude 本身无法主动感知外部数据的变化——它只能在你把信息塞进对话上下文之后才知道。

bci-mcp 的价值在于把"实时生理数据"变成了 Claude 语境里的"一等公民"。通过 MCP 的工具（Tool）和资源（Resource）机制，Claude 可以在对话过程中随时调用get_brain_state这类工具，实时拿到当前脑状态指标；也可以在配置资源订阅之后，让数据增量地推送进来。这意味着 AI 可以有上下文地使用生理信息：你正在写一段复杂算法时，它知道你在高专注状态；你已经开始走神了，它能识别出来并调整交互节奏。

还有一个被忽略的点：MCP 让"流式"这件事有了标准答案。传统 API 对接里，"流式传输"往往要靠 Server-Sent Events 或者 WebSocket 自己搭。但 MCP 的资源更新机制和工具轮询机制，在设计上就支持持续性的数据交换。bci-mcp 里脑状态数据本来就是不断变化的流，用 MCP 来承载这种流动数据，比写私有协议要优雅得多。

2. 技术架构与方案选型：为什么是 EEG + MCP

2.1 端到端的数据链路怎么画

整体链路分成四层：物理采集层、信号处理层、MCP 服务层、AI 消费层。

物理采集层负责从 EEG 设备拿原始波形。以 Muse 2 为例，设备通过 BLE 广播，电脑端用 BLE 客户端连接后订阅 EEG 特征值（GATT Characteristic），数据以 JSON 格式的字符串包不断推送过来。每个数据包包含 12 个通道样本（Fp1 参考修正前的 4 个原始通道），外加时间戳。

信号处理层是整条链路的关键。原始脑电信号经过带通滤波（0.5-45 Hz）去除工频干扰和直流漂移，再用滑动窗口做快速傅里叶变换（FFT），计算各频段功率。窗口长度一般取 2-4 秒，太短了频域分辨率不够，太长了实时性就差。这里有一个微妙的设计权衡：脑状态本身是一个慢变量，Alpha/Beta 功率在几秒尺度上才会发生显著变化，所以 4 秒滑动窗口、每秒刷新一次，是一个实测效果不错的折中。

MCP 服务层做的事情很收敛：把信号处理层吐出的状态字典封装成工具和资源。工具用于 Claude 主动查询，资源用于订阅推送。服务层还负责管理设备生命周期——重连、断电、阻抗检测都要在这里兜底。

AI 消费层就是 Claude Desktop 或 Claude Code。它们读取 MCP 配置，启动 fastmcp 服务端 (stdio 传输)，然后在对话进程中按需调用工具。整个链路从物理信号到 AI 上下文，端到端延迟实测可以压到 1 秒以内，对"感知脑状态"这个场景来说已经足够。

2.2 为什么选 MCP 而不是自己写一个 API

我最早其实打算自己写一个 REST 接口，让 Claude 通过 HTTP 工具调用取数据。试完才发现这个方案有三个问题没法绕开。

第一是握手成本。Claude 调用 HTTP 工具需要配置 OpenAPI schema、处理鉴权、管理并发连接，Claude Code 对本地 HTTP 服务的支持也不如对 MCP 原生协议那么顺滑。MCP 只需要在配置文件里声明command: python xxx.py，客户端直接拉起子进程，用 stdio 通信，完全不需要管网络端口和鉴权。

第二是实时性语义。REST 是典型的请求-响应模型，Claude 必须显式去轮询才能拿到新数据。MCP 的资源订阅机制允许服务端主动推送更新，工具调用的上下文隔离也更清晰。对 EEG 这种持续产生的生物信号来说，订阅推送比轮询省事也省算力。

第三是生态复用。MCP 已经是 Anthropic 生态里的标准协议，Claude Desktop、Claude Code 全都原生支持。你写一次 MCP Server，整套 Anthropic 工具链都能用。如果哪天想换到其他支持 MCP 的客户端，配置改一行就行，比死磕私有 API 好太多。

2.3 EEG 信号处理管道设计：不是越复杂越好

信号处理这块我踩过不少坑，核心原则其实是"给 AI 消费的数据，先问清楚它要什么"。Claude 不需要看到原始波形，也不需要知道每个频段的绝对功率值——它只需要一个能理解的状态描述。所以我最终设计的特征集是：四个频段功率的相对占比、一个 0-100 的专注度评分、一个 0-100 的放松度评分、以及一个设备信号质量标记。

专注度和放松度的计算公式并不神秘，本质上就是 Beta 和 Alpha 频段功率的归一化比值。关键是要做平滑：原始比值波动极大，眨眼、咬牙、转头都会造成瞬时尖峰，直接送给 Claude 会导致它判断混乱。我用了指数滑动平均（EWMA），时间常数设 3 秒左右，既不丢失状态变化的趋势，又能滤掉生理伪迹。

另外一个细节是基线校准。每个人的脑电绝对值差异巨大——有人 Alpha 功率天生偏低，有人 Beta 偏高。如果你直接把绝对功率比值送给 Claude，它无法区分"这个人本来就这样"和"这个人现在状态异常"。所以我在服务启动后先采集 60 秒静息态数据做基线，所有后续指标都以相对基线的变化量来输出。这也是脑电消费级应用里很成熟的做法。

3. 核心实现：从脑电波到 Claude 可读的脑状态

3.1 硬件采集层：Muse 2 为主的设备选型

设备选型这件事，直接决定了你后面所有的调试体验。我实测过的三条路线可以做个简单对比：

我最终选了 Muse 2，原因很现实：它有现成的 Python 解析库，BLE 协议被社区彻底逆向过了，甚至可以直接拿到原始波形；而且 4 通道的布局覆盖了额叶和前额叶，这正是专注度和认知负荷研究最常关注的脑区。如果你手里只有 MindWave 也别慌，它的 Attention/Meditation 两个指标在简单场景下完全够用，接入逻辑更简单，只是拿不到原始频谱。

硬件连接这里有个重要的实操提示：Muse 的 BLE 服务在连接后会以固定的特征值推送数据，你用bleak库就可以直接订阅。但别忘了处理重连逻辑——BLE 连接非常容易被人体阻挡或环境干扰打断，实测连续跑 2-3 小时后掉线是常态，服务端必须能自动重连。

3.2 信号预处理与特征提取的实现细节

信号处理的代码不算长，但每行都有讲究。我直接贴核心逻辑。

import numpy as np from scipy import signal class EEGProcessor: def __init__(self, sample_rate=256, window_sec=4): self.sample_rate = sample_rate self.window_size = sample_rate * window_sec self.window = np.zeros(self.window_size) # 0.5 Hz 高通，去掉直流漂移 self.b_high, self.a_high = signal.butter( 4, 0.5 / (sample_rate / 2), btype='high' ) # 45 Hz 低通，去掉高频肌电噪声 self.b_low, self.a_low = signal.butter( 4, 45 / (sample_rate / 2), btype='low' ) def update(self, samples): # 把新样本推入环形窗口 self.window = np.roll(self.window, -len(samples)) self.window[-len(samples):] = samples return self.compute_state() def compute_state(self): # 级联滤波 data = signal.filtfilt(self.b_high, self.a_high, self.window) data = signal.filtfilt(self.b_low, self.a_low, data) # FFT 与频段功率 freqs = np.fft.rfftfreq(self.window_size, 1 / self.sample_rate) power = np.abs(np.fft.rfft(data * np.hanning(self.window_size))) ** 2 bands = { 'delta': (0.5, 4), 'theta': (4, 8), 'alpha': (8, 13), 'beta': (13, 30), 'gamma': (30, 45) } result = {} for name, (lo, hi) in bands.items(): mask = (freqs >= lo) & (freqs < hi) result[name] = float(np.nanmean(power[mask])) total = sum(result.values()) + 1e-10 result['alpha_ratio'] = result['alpha'] / total result['beta_ratio'] = result['beta'] / total # 专注度 = Beta / (Alpha + Beta) 的经验公式 result['focus_raw'] = result['beta'] / (result['alpha'] + result['beta'] + 1e-10) return result

这段代码有四个关键点，我各自说一句为什么。

窗口加汉宁窗（Hanning）是为了减少 FFT 的频谱泄漏，不加的话频段功率会有明显的旁瓣干扰。用nanmean而不是mean是因为 Muse 的信号偶尔会出现 NaN 丢包，直接mean会把整个窗口污染掉。4 秒窗口配 256 Hz 采样率就是 1024 个点，FFT 之后频率分辨率大约是 0.25 Hz，足够把 Delta 和 Theta 分开了。最后那个1e-10是防除零，生物信号处理里这个宏非常常见，别偷懒不写。

3.3 MCP Server 与 EEG 分析器对接

MCP 服务端我直接用官方 Python SDK 里的 FastMCP 封装，代码量小到令人意外。核心思路是让整个 EEG 分析器作为一个后台单例，MCP Server 的所有工具都读取这个单例的最新状态。

from mcp.server.fastmcp import FastMCP from eeg_processor import EEGProcessor from muse_client import MuseClient import threading mcp = FastMCP("bci-mcp", instructions="提供实时脑电状态查询能力") processor = EEGProcessor() muse = MuseClient() spinning_lock = threading.Lock() latest_state = {} def _loop(): global latest_state # Muse 连接回调里不断把原始样本写入 processor for sample in muse.stream(): with spinning_lock: latest_state = processor.update([sample]) @mcp.tool() def get_brain_state() -> dict: """获取当前脑状态：返回各频段功率占比、专注度、放松度""" with spinning_lock: return latest_state @mcp.tool() def get_focus_score() -> int: """获取 0-100 的专注度评分，适合快速判断当前是否在深度工作""" with spinning_lock: focus = latest_state.get('focus_raw', 0) return int(max(0, min(100, round(focus * 100)))) @mcp.resource("brain://current_state") def brain_state_resource() -> dict: """以资源形式暴露当前完整脑状态，支持订阅更新""" with spinning_lock: return latest_state if __name__ == "__main__": thread = threading.Thread(target=_loop, daemon=True) thread.start() mcp.run()

这里有三个实现上的心得。

第一个是线程模型：MCP 服务端运行在 stdio 事件循环里，而 BLE 数据流是独立线程。所以我用一个threading.Lock保护共享状态，所有工具函数都通过锁读取最新快照。这个方案虽然简单，但实测不会丢数据，因为 EEG 本来就是以 4 秒窗口为准的，瞬时锁冲突造成的延迟完全可以接受。

第二个是工具粒度：get_brain_state返回完整字典，信息量大但 Claude 上下文占用也大；get_focus_score只返回一个 0-100 整数，适合在对话流程里高频查询。把工具设计成"一个准，一个快"，Claude 会在不同场景自动选择，这是我调了几轮之后才顿悟的。

第三个是资源暴露：brain://current_state这种资源路径，既能让 Claude Desktop 在界面上直接查看，也能配合 MCP 的订阅机制做增量推送。如果你想让 Claude 在对话中"持续感知"脑状态变化，资源订阅比反复调用工具要自然得多。

3.4 Claude 侧接入配置：Desktop 和 Code 两种方式

Claude Desktop 的接入是在claude_desktop_config.json里注册 MCP Server。这个文件的路径在 macOS 上是~/Library/Application Support/Claude/claude_desktop_config.json，在 Windows 上是%APPDATA%\Claude\claude_desktop_config.json。注意如果你装了 Claude Code，两者不是同一个文件，别搞混。

{ "mcpServers": { "bci": { "command": "python", "args": ["/absolute/path/to/bci_mcp_server.py"] } } }

如果你是 Claude Code 用户，更推荐用命令行注册，这样热更新不需要重启整个桌面应用：

claude mcp add bci -- python /absolute/path/to/bci_mcp_server.py claude mcp list # 确认已注册

注册之后有个小验证技巧：在 Claude Code 里直接问"你有哪些工具可以用"，它会列出 MCP 工具列表，如果看到bci_get_brain_state之类的方法就说明握手成功。别急着做高级功能，先跑通这条路。

4. 实操过程：完整跑通一次实时脑状态传输

4.1 环境准备与依赖安装

整个项目依赖我用 Python 3.10+，虚拟环境是刚需，别偷懒。依赖包按作用分三组：

# EEG 采集 pip install bleak numpy scipy # MCP 服务端 pip install "mcp[cli]" # 可选：数据分析/调试 pip install matplot lib jupyter

这里有一个容易踩的版本坑：mcp包升级频繁，API 变化不小。我踩过最疼的一次是FastMCP的初始化参数从name改成了位置参数，导致老代码直接抛 TypeError。锁定版本是个好习惯，至少把它写进requirements.txt：

mcp==1.x.x bleak==0.21.1 numpy==1.26.4 scipy==1.12.0

4.2 硬件连接与数据校验

连接 Muse 2 之前，先确认三件事：设备电量充足（低于 20% 时信号质量明显下降）、电极和皮肤接触良好（干电极不需要导电膏，但需要微微湿润）、周围没有强 WiFi 信号干扰（2.4 GHz 频段和 BLE 容易打架）。

首连建议用现成的工具脚本验证。Muse 官方社区有一个muse-lsl项目，可以直接把 Muse 数据流转发到 Lab Streaming Layer 管道，我在正式接入 MCP 之前先跑它确认数据通路。如果你不想上 LSL，也可以直接照我前面的bleak写法订阅数据，打印前几包看看 JSON 格式。

实测提醒：Muse 的 EEG 数据包长这样——{"topic":"/muse/eeg","data":[1.2,-0.8,...],"timestamp":1620000000.123}——每个包有 12 个样本值。注意它不是标准的 BLE 数值格式，而是 JSON 字符串放在特征值的 value 字段里，这个细节我一开始被坑了半小时，解析时别按普通 bytearray 处理。

4.3 核心代码逐步实现：Muse 采集与 MCP 服务

完整代码我拆成两个文件，结构更清晰。第一个是muse_client.py，负责 BLE 通信和原始数据回调。

import json import asyncio from bleak import BleakClient MUSE_EEG_UUID = "295e566b-515c-1c72-ceee-1b2f3a6846b7" class MuseClient: def __init__(self, address): self.address = address self._handler = None def on_sample(self, callback): self._handler = callback async def connect(self): self.client = BleakClient(self.address) await self.client.connect() # 订阅 EEG 特征 await self.client.start_notify(MUSE_EEG_UUID, self._notify) # 先发一条控制命令开启脑电数据流 await self.client.write_value( bytearray([1]), "273e1111-5056-4d5c-82d1-d2b6f7b6e9b5" ) def _notify(self, _handle, data): payload = json.loads(bytes(data).decode("utf-8")) if "data" in payload and self._handler: for sample in payload["data"]: self._handler(sample)

第二个是 MCP 服务端，这里我借用了前面 3.3 节的bci_mcp_server.py，只是把 MuseClient 接进去。有一个关键细节：_loop()里用了同步的set_latest_state()回调，本质上是把muse.stream()由异步生成器包装成同步接口，避免在 MCP 的工具函数里出现异步地狱。

import asyncio import threading from muse_client import MuseClient # ... MCP 部分同 3.3 # 全局状态和锁 latest_state = {} state_lock = threading.Lock() def _on_sample(sample): global latest_state # 把频带状态更新逻辑放进 EEGProcessor with state_lock: latest_state = processor.update([sample]) def _run_muse(): client = MuseClient("AA:BB:CC:DD:EE:FF") client.on_sample(_on_sample) asyncio.run(client.connect()) # 保持事件循环运行 asyncio.get_event_loop().run_forever() if __name__ == "__main__": threading.Thread(target=_run_muse, daemon=True).start() mcp.run()

4.4 联调验证：从指标到对话上下文

服务跑起来之后，验证分三步走。

第一步验证 MCP 服务本身是否正常。在 Claude Code 里调用get_brain_state工具，如果返回值里有alpha_ratio: 0.32, beta_ratio: 0.18之类的数值，说明信号解析链路没问题。此时如果你闭上眼睛放松，Alpha 占比应该明显上升——这个生理反应可以作为端到端正确性的对比参照。

第二步验证流式推送。用brain://current_state资源订阅，然后在 Claude Code 里发起一次长对话，让它每 30 秒汇报一次你的专注度变化。实测这个场景下 Claude 会自己决定调用资源还是工具，说明 MCP 的上下文管理在起作用。

第三步是真实场景验证。我设置了一个小实验：连续写代码 40 分钟，期间每 5 分钟记录 Claude 判断的专注度，再和我自己的主观感受做对照。结果整体趋势一致——进入深工作状态时 Beta 占比上升，中间拿起手机刷了三分钟时 Alpha 占比明显回升。差异主要在前 5 分钟，因为刚戴上头环时电机接触还没稳定，这个我后面排查问题会细说。

5. 常见问题与排查实录：掉线、伪迹与工具失效

5.1 设备连接类问题

症状一：BLE 连接建立后，Muse 数据流不来。十有八九是控制命令没发对。Muse 的 EEG 流需要在连接后向特定的写入特征发送[1]来开启，这个[1]不是随意定的，而是它的固件协议里定义的 command code。忘发以后订阅了 GATT notify 通道也不会有数据。解决方案就是检查client.write_value那步是否执行成功。

症状二：运行十几分钟后就掉线。BLE 和 2.4GHz WiFi 的干扰是最大元凶，尤其是你电脑同时连着 2.4G WiFi 时。我的实测数据：在 WiFi 干扰严重的环境下，Muse 掉线时间从平均 30 分钟降到 8 分钟。建议用 5G WiFi 或把 Muse 信号源靠近电脑一米以内，同时加一段自动重连逻辑——重连时回退到扫锚点、重新配对，别指望一次连上。

症状三：Muse 的电极阻抗过高，数据周期性跳变。干电极靠压力和皮肤湿润度维持信号，头发油多、额头干燥、佩戴偏移都会让阻抗飙升。处理办法很土但很有效：佩戴前用湿纸巾擦一下电极接触位置的额头皮肤，佩戴后用手掌轻压头环 10 秒让它贴合。阻抗问题在数据上的典型特征是波形突然变成平坦方块状。

5.2 脑电数据质量问题

问题一：FFT 频谱里 50/60 Hz 工频干扰巨大无比。这是最常见的电源噪声，解决办法不是硬滤波，而是采样前确认设备本身已经做了模拟滤波。如果还是干扰，可以在数字端加一个 48-52 Hz 的陷波滤波器，scipy.signal.iirnotch一行搞定。

问题二：眨眼和咬牙产生的伪迹把整个窗口污染。眨眼会制造一个幅度奇高的瞬态尖峰，咬牙更夸张——咀嚼肌的肌电信号幅度能盖过脑电信号一个数量级。这个问题的处理方案我做了一个妥协：不做在线伪迹剔除，只识别并标记。具体做法是计算窗口内信号的峰值幅度，如果超过正常脑电幅度的 3 倍，就认为这段数据是伪迹污染，把signal_quality字段标记为degraded，同时让get_brain_state返回一个警告字段。Claude 看到警告后会自动意识到当前状态不可靠，不会误判为高专注或低放松。

问题三：专注度评分乱跳，没有趋势。多半是忘记做基线校准。绝对 Beta/Alpha 比值在个体间差异极大，同一个 bci-mcp 服务，戴在 A 头上专注度基准是 0.7，戴在 B 头上可能是 0.3。四秒窗口的数据本身也有方差。我的解决办法是：服务启动后静默采集 60 秒静息态作为基线，之后输出的专注度 = 当前值相对于基线的变化量，再把这个变化量映射到 0-100 的稳定区间。实测映射后的数值波动小得多。

5.3 MCP 配置与工具调用问题

问题一：Claude Desktop 里一直提示 MCP Server 连接失败。最常见原因是路径写错。MCP 配置里的args必须是绝对路径，相对路径在很多系统下解析不到。其次是 Python 环境问题——配置里的command: "python"可能指向系统 Python，而不是你装了依赖的虚拟环境。解决办法是把 command 改成虚拟环境下 python 的绝对路径，例如/home/user/venv/bin/python。

问题二：工具能注册但调用超时。MCP Server 的 stdio 通信本质上还是通过标准输入输出传 JSON-RPC，如果你的服务端在工具函数里做了耗时操作（比如等 BLE 数据），就会让 Claude 等太久。我在实现里所有工具都只是读取latest_state快照，毫秒级返回，绝不阻塞等待采集。采集逻辑放在后台线程，这算是最关键的架构决策之一。

问题三：Claude Code 添加了 MCP 却找不到工具。从 Claude Code 1.0 的某个版本开始，新加的 MCP Server 需要重启会话或者执行/mcp命令刷新，而不是在同一个会话里热生效。另外要确认你的claude mcp add命令作用在正确的项目目录区间，claude mcp list会显示当前生效的 scope。这个问题说白了就是生态更新太快，文档跟不上，只能自己多试。

6. 应用场景与个人经验：脑状态感知能玩出什么

6.1 我实测验证过的几个玩法

第一个是深度工作助手。我设置了一个任务：让 Claude Code 在我写代码的过程中，每隔 5 分钟调用get_focus_score。评分低于 40 时它会停下来问"要休息一下吗"，高于 75 时会主动提示"当前状态适合处理复杂任务"。连续用了一周，我发现自己一天的深度工作总时长比不用的那周多了差不多 40 分钟——不是工具本身有什么魔力，而是"有人时刻在盯你的专注度"这件事建立了外部反馈循环。

第二个是冥想辅助。冥想时 Alpha 波会显著增强，我让 Claude 根据 alpha_ratio 的实时变化，在对话里反馈"你的放松度正在上升""脑波开始稳定"。效果有点像是在跟一个能看到你脑状态的教练对话，比单纯看 App 曲线有意思得多。

第三个是课堂/演示场景。教师或者演讲者戴着头环，让 Claude 实时读取现场观众（如果每个观众都有设备）的平均专注度，这玩意的应用想象空间很大，但硬件门槛还不是普通教室能承受的。单个设备的话，用来监控自己的演讲节奏倒是绰绰有余。

6.2 给后来者的几句实话

这个项目整体难度不高，但有几个认知层面的坑值得提前预期。

第一，不要追求高精度。消费级 EEG 设备四个电极，本身就不可能和医疗级 64 导联设备比精度。它的定位是"足够捕捉大趋势"，不是"精确测量脑电生理指标"。接受这一点，你会少很多挫败感。

第二，数据处理比设备更重要。同样的 Muse 2，不同人用出来完全是两个效果。基线校准、伪迹标记、滑动窗口平滑这三个环节做不做，决定你的 AI 感知是"靠谱的人体信号"还是"垃圾进垃圾出"。

第三，MCP 生态变化非常快。我写这篇文章时用的 API 接口，可能你看到的时候已经改了。所以本文代码请当作思路参考，真正实施时一定要查最新文档。不要因为 API 变化就焦虑，技术栈在快速演进说明这个方向有生命力。

第四，也是我最想强调的一点：脑状态数据是敏感的生理数据。本地处理还好，一旦要上云端或共享给第三方，一定要想清楚隐私边界。bci-mcp 这种把穿戴设备数据接入 AI 应用的模式，未来必然会遇到更严格的合规要求，提前养成数据最小化的习惯，总没错。

最后再分享一个小技巧：调试阶段别急着搞 Claude 集成，先用命令行把数据链路跑通。我一般是先python muse_client.py确认采集能出数，再独立跑 MCP Server 用mcp dev模式手动调工具，最后才接 Claude Code。分开调试比整体联调效率高一个数量级，这也是我过去几年做硬件+AI 集成项目最实用的经验。