mcpField
R
RoastPilot

RoastPilot

本地服务
github.com游戏娱乐02 周前更新
代码仓库访问官网

关于 RoastPilot

RoastPilot 是用于咖啡烘焙机控制、遥测、烘焙会话跟踪和日志导出的本地 MCP 服务，面向操作人员及 Agent 工作流。它提供安全的模拟模式，并集成 Hottop 控制和一爆检测。

主要功能

  1. 01烘焙机控制与会话事件
  2. 02实时遥测与烘焙指标
  3. 03一爆检测集成
  4. 04自动处理 T0 事件
  5. 05导出 JSONL 和 CSV 烘焙日志
  6. 06适合模拟运行的本地模式

适用场景

  1. 01控制并监测烘焙会话
  2. 02记录一爆和投豆事件
  3. 03导出烘焙遥测数据与会话摘要
  4. 04无需烘焙机硬件测试 MCP 工作流

MCP 相关

通过本地 stdio MCP 工具提供烘焙会话控制、状态与遥测、一爆事件、安全操作和日志导出。默认模拟配置可在没有烘焙机硬件、麦克风、模型文件或网络的情况下测试客户端。

配置

本地服务的配置在各客户端中通用，复制后粘贴到客户端的 MCP 配置文件即可。

mcp.json · 通用配置
{
  "mcpServers": {
    "syamaner-coffee-roaster": {
      "command": "uvx",
      "args": [
        "coffee-roaster-mcp"
      ]
    }
  }
}
启动命令uvx coffee-roaster-mcp

本地服务需要在你的电脑上安装运行环境（如 Node.js 18+）。各客户端的配置文件位置不同，请参考客户端文档。

安装包
pypicoffee-roaster-mcp0.2.4

工具

15

收录的工具列表 · 更新于 2 周前

此工具无需参数。

详细介绍

RoastPilot

RoastPilot 是一款用于咖啡烘焙机遥测和受控驱动的 MCP 服务。

软件包名称为 coffee-roaster-mcp。它已发布到生产环境 PyPI，并在 MCP Registry 中列为 io.github.syamaner/coffee-roaster-mcp。

RoastPilot 提供一个本地 MCP 运行时，用于烘焙机控制、遥测、与一爆检测集成、烘焙指标和日志导出。

状态

✅ v0.1 组件范围已完成，已发布到 PyPI 和 MCP Registry，并已在监督下通过 Agent 控制的硬件烘焙进行测试，测试截至 2026-08-16。

最新的集成证据是 2026-08-16 完成的两次 Hottop 烘焙。这两次烘焙共同涵盖了实时遥测与控制、自动 T0、一爆处理、一爆后的决策、安全评估、由顾问触发的下豆、操作员控制的冷却完成、环境感应、日志导出和双麦克风采集。Agent 账本记录了 19 次成功的顾问决策，每次都关联到一项 allow 安全评估；两次由顾问提议的下豆都已执行，且两次已完成的烘焙中均无失败的命令事件或安全警报。

这些烘焙使用的是固定版本的 coffee-roaster-mcp 0.1.13 运行时。0.1.14-0.1.16 是元数据/文档发布版本。公开的 PyPI 元数据显示版本为 0.2.3，相应的发布工作流报告称已成功发布到 PyPI 和 MCP Registry；但当前在线的 MCP Registry 条目未经独立检查。这些是对公开元数据和工作流的观察，并非对公开制品字节、内容、标签来源或已安装字节的独立验证。

仓库的 0.2.3 候选记录包含 D209 的仅适用于冷态的类型化温度与数据包投影，以及 #222 中仅适用于烘焙风扇的冷却会话 get_roast_state 观测，还有 PR #231 中已停止故障的精确会话恢复语义。#222 的观测仅报告已命令的烘焙风扇状态。D209 投影报告遥测、数据包有效性与计数器，以及原始和类型化温度信息。数据包进度筛查是 Agent 对多个观测进行比较，不是持续的新鲜度或链路监视器。这些源记录和发布观察并不能证明物理驱动、校准、准确性、持续新鲜度、链路健康状况、就绪状态或安全性。问题 #225 仍未关闭，待协调发布流程；问题 #227 已关闭，范围仅限于 D209 软件投影。

相较于公开的当前标签源代码 3e40487686880825f93ae2015cc4253d9183623b，0.2.4 中唯一新增的运行时内容是 S1 延后导入本地 SciPy 对称 Hann 窗。数值输出和接口均未改变。版本字符串、wheel 名称或声明的命令行摘要，均不能证明预期的解释器会导入哪些字节。验证已安装字节是一个单独的、须经操作员授权的关卡；本文档不会执行此操作，也不会声称已对任一发行包执行此操作。0.2.4 的准备工作仅在已合并的主线提交和成功完成的非发布演练范围内完成；创建标签、批准受保护的 release 环境、发布以及在线制品验证仍须由人工操作员执行。这并不授权使用硬件或咖啡豆，也不构成就绪声明。 合并后必须记录一次成功的非发布演练；本文不声称已有待处理的演练成功记录。

此打包版 README 的状态是准备期间的快照。它记录了上述当前源代码和公开元数据观察，不对 0.2.4 作出当前发布声明。 D191 批准的限值仍为 N = 1 和 X = 200 ms；生产环境中的致命错误连续次数仍为 30。D190 是仅针对 MCP 组件的表征测试，使用了人工音乐：未观察到溢出并不能证明其他条件下有余量，也不能证明非零容许值是必要的；经过脱敏的审查没有重新核验私有证据，而且它不属于检测器、实时烘焙、全栈或组合验收。D192 全栈 30+30 测试，以及单独进行的受监督、时长至少 20 分钟的实时烘焙，仍未完成。#157 和 #194 仍处于开放状态。发布仍仅限操作员执行，且须在合并、成功完成发布工作流试运行并获准进入受保护环境之后进行。请参阅2026-08-16 Agent 烘焙验证报告，了解权限台账、会话、环境音和采集证据，包括其中说明的来源限制。

最初的已发布软件包基线仍是 2026-06-07 的验证结果：

通过 MCP Registry 的 uvx 路径将已发布的 coffee-roaster-mcp 0.1.3 软件包安装到 Warp Agent 后，它在连接的 Hottop KN-8828B-2K+ 上完成了两次受监督的完整烘焙，未出现串行、控制或遥测故障：

验证项结果
安装路径在真实 MCP 客户端（Warp）中通过 uvx 安装 PyPI 上已发布的 0.1.3 版本
硬件控制通过由驱动支持的 MCP 工具实时控制加热、风扇、下豆和冷却
自动 T0根据豆温下降检测到 beans_added（source: auto_t0）
一爆检测通过真实 USB 麦克风实时检测音频；使用已发布的 INT8 ONNX 模型进行滑动窗口确认，置信度为 0.907，高于 0.6 阈值，且 5/5 个窗口均为阳性
安全操作当天执行的防护式 hottop-validate 测试通过全部 8/8 个步骤，包括下豆和紧急停止
日志导出生成包含完整一爆和自动 T0 元数据的 roast.jsonl、roast.csv 和 summary.json

证据：

有关计划和状态历史，请参阅 v0.1 总体计划 和项目状态注册表。

相关项目产物

当前的 coffee-roaster-mcp 软件包是对原型的整合式重建，吸收了经验教训，并将其汇集到一个确定性的本地 MCP 服务中，采用保守的硬件边界和可发布的软件包元数据。

RoastPilot 是什么

RoastPilot 是面向用户的产品名称。coffee-roaster-mcp 是用于仓库、Python 包和已发布发行版的基础设施与打包名称。

v0.1 的范围是一个本地 stdio MCP 服务，负责：

  • 烘豆机控制
  • 烘焙会话计时与事件
  • 一爆检测集成
  • 衍生烘焙指标
  • 烘焙日志导出

所有 MCP 组件 v0.1 史诗均已完成并通过线上验证。包脚手架、配置加载、本地开发命令、拉取请求 CI、stdio MCP 入口点、烘焙会话工具界面、Hottop 驱动程序、音频一爆运行时、自动 T0 路径、指标与日志导出、发布工作流以及 MCP Registry 元数据均已就绪；并且已通过已发布的包，在连接的 Hottop 硬件和真实麦克风上验证了完整的端到端流程（E7-S6）。

安装

当前用于本地开发：

python3.11 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -e . --group dev

面向用户的安装目标是已发布的 coffee-roaster-mcp 包：

python -m pip install coffee-roaster-mcp

有关操作员设置，包括模拟安装、Hottop 配置、Hugging Face 模型配置、离线模型路径和日志输出路径，请参阅安装与硬件设置指南。

本地开发

设置

使用安装部分中的命令，然后继续执行以下检查。

测试
python -m pytest
覆盖率
python -m pytest --cov=coffee_roaster_mcp --cov-report=term-missing:skip-covered --cov-report=html:htmlcov --cov-report=json:coverage.json
python .github/scripts/write_coverage_summary.py coverage.json

拉取请求 CI 会在 Checks 作业摘要中发布 Markdown 覆盖率摘要，并将 html-coverage-report 上传为工作流构件，以便逐文件深入查看。

代码检查
python -m ruff check .
格式检查
python -m ruff format --check .
类型检查
python -m pyright
CLI 冒烟测试
coffee-roaster-mcp --help
coffee-roaster-mcp --version
硬件与音频检查

两项明确的烘焙前检查可验证已配置的麦克风和独立的多设备录音路径，不会启动烘焙：

coffee-roaster-mcp mic-check --config coffee-roaster-mcp.yaml
coffee-roaster-mcp record-check --config coffee-roaster-mcp.yaml

mic-check 会报告所选输入是否包含真实信号，并可写入一条简短的 JSON 证据记录。record-check 会将每个已配置的录音设备录制到临时目录或指定输出目录，并报告结果。录制的音频可能包含周围的对话，不得提交。

本地模拟运行

默认的本地路径经过特意设计，可安全用于模拟：

  • 默认烘豆机驱动程序：mock
  • 默认一爆模式：disabled
  • 无需烘豆机硬件
  • 无需麦克风
  • 无需下载模型

RoastPilot 现已提供本地 stdio MCP 服务入口点，并带有可安全用于模拟的烘焙会话工具界面。默认配置允许 MCP 客户端启动烘焙、调整控制项、读取当前设备和会话状态、记录明确的覆盖事件、将豆子投入冷却，并导出快照日志，无需烘豆机硬件、麦克风输入、模型文件或网络访问。

启动本地 MCP 服务
coffee-roaster-mcp serve

当前 MCP 工具界面包括：

  • get_server_info
  • get_runtime_config
  • start_roast_session
  • get_roast_state
  • set_heat
  • set_fan
  • mark_beans_added
  • mark_first_crack
  • drop_beans
  • start_cooling
  • stop_cooling
  • export_roast_log
  • emergency_stop
  • set_recording_metadata
  • finalise_cold_characterisation_session
每轮轮询的冷态特性分析观测值

get_roast_state.cold_characterisation_observation 仅对 purpose="cold_characterisation" 会话有意义；使用方必须根据 session_purpose 进行筛选。它以带类型、只读的观测值形式报告指令设定的烘焙风扇级别。它不能证明物理状态、连接状态或数据新鲜度，也不与 device_state 保持原子一致；它不会重复提供加热、主风扇或冷却状态。

冷态表征收尾

finalise_cold_characterisation_session 是一款不会触发执行操作的拆卸工具，适用于使用 purpose="cold_characterisation" 启动的最新活动会话；不适用于正常烘焙。它仅接受已知的、已连接且处于安全零位的驱动器证据，然后停止采样和捕获，验证录制产物，并断开连接。 clean 表示所有阶段均已完成（或不适用）、已确认断开连接，且最终驱动器证据仍处于安全零位。partial 和 disconnect_indeterminate 会保留证据以供之后重试；这并不代表任何就绪状态声明。 D195 完整安全零位范围仅用于收尾。 终止收尾不会改变会话阶段；使用方必须依据 active 和 session_active_after，而不是根据阶段推断是否完成。 completed_not_clean 不代表就绪或安全已确认：开始任何新会话前都应先调查此状态。

export_roast_log 会为当前进程内会话写入 roast.jsonl、roast.csv 和 summary.json 文件。烘焙期间，运行时事件和采样遥测数据也会追加到 roast.jsonl。

开始录制烘焙前，set_recording_metadata 会保存用于捕获文件名和会话侧车文件的豆子产地 slug 与烘焙编号。它不会发送硬件命令，也不会提供通用文件写入或工具执行接口。

MCP 操作流程

适用于模拟环境的 Claude/操作员流程如下：

  1. 调用 start_roast_session，创建唯一的活动烘焙会话并连接已配置的驱动程序。
  2. 根据操作需要调用 set_heat 和 set_fan。这些工具会经过已配置的 RoasterDriver 边界；默认模拟驱动程序会在本地运行，并保持确定性。
  3. 调用 get_roast_state，读取权威会话状态和当前已配置设备的状态。响应包含驱动程序 ID、连接状态、可用时的豆温/环境温度、火力/风扇档位、冷却状态、安全的原始诊断信息、T0 状态、一爆状态，以及投豆、一爆、下豆、开始冷却和停止冷却的生命周期时间戳。
  4. 使用 drop_beans 作为常规下豆命令。对于模拟路径和 Hottop 复合下豆路径，该命令会记录 beans_dropped；如果驱动程序报告冷却已启动，还会记录 cooling_started；随后关闭火力、将风扇设为 100%，并进入冷却阶段。
  5. 冷却完成后，使用 stop_cooling。start_cooling 仍可用作显式的高级/手动恢复工具，但不是调用 drop_beans 后常规烘焙流程的一部分。 经过加热的模拟演练接下来必须在空锅下豆/冷却/停止冷却流程后调用 set_fan(0)，才能安全地完成归零。

mark_beans_added 和 mark_first_crack 是显式覆盖工具。它们仍可用于操作员恢复和受控手动运行。主要自动运行路径在内部执行：启用 session.auto_t0_detection_enabled 后，自动 T0 检测可记录 beans_added；而在明确配置 first_crack.mode: audio 后，由会话拥有的一爆运行时负责通过音频确认一爆。

默认情况下，自动 T0 处于禁用状态。启用后，get_roast_state 会读取已配置的驱动程序，跟踪 T0 前的最高豆温，并在当前豆温从该最高值下降 session.auto_t0_drop_threshold_c 时记录 beans_added。自动 T0 记录事件时，get_roast_state.t0_status 会显示已配置的阈值、跟踪到的投豆温度、当前温降以及检测到的豆温。

默认情况下，可选的环境传感和烘焙录音也处于禁用状态。明确启用后，get_roast_state 会显示容错的 Yoctopuce 环境读数，以及实时麦克风/溢出状态；录音运行时则可将一个或多个独立麦克风流录制到会话专属目录中。录音使用一爆音频捕获运行时，因此需要设置 first_crack.mode: audio。实时烘焙录音还要求 audio.source: microphone，并将 recording.enabled 和 recording.autocapture 均设为 true。设置 recording.devices 时，其第一项必须与 audio.input_device 匹配：检测器会捕获该音频流，并将其转接到第一个 WAV 文件，而不会单独打开该设备。任何其他项都会作为独立录音流打开。这些路径已在 2026 年 8 月的硬件烘焙测试中共同验证，详情见当前验证报告。

get_roast_state.first_crack_status.status 的值包括：

  • disabled：一爆检测已禁用，且不存在一爆事件。
  • manual：已配置手动一爆模式，且可使用覆盖工具。
  • pending：已配置音频检测，正在等待确认事件。
  • detected：权威会话时间线中存在一爆事件。
  • faulted：检测器运行时或会话发生故障。
  • unavailable：配置、工件、音频捕获或手动覆盖设置导致一爆检测不可用。
Mock 安全启动冒烟测试

通过此 Mock 安全启动冒烟测试，确认从一个保证为空的临时目录启动时，默认本地路径仍然无需硬件或模型：

python -c "import os, tempfile; from coffee_roaster_mcp.config import load_config; tmp = tempfile.TemporaryDirectory(); os.chdir(tmp.name); c = load_config(environ={}); print(c.roaster.driver, c.first_crack.mode, c.first_crack.precision); tmp.cleanup()"

预期输出：

mock disabled int8

这确认启动默认设置仍与 Mock 纵向切片计划一致。

Hottop 配置与验证

简明的设置步骤请参阅 安装与硬件设置指南；本节概述受保护的验证工作流。

Hottop 支持通过 RoasterDriver 抽象层提供。该驱动支持生命周期、命令循环、数据包、控制状态和温度单位，并已在连接的硬件上通过完整的受保护验证（包括卸豆和紧急停止）——最近一次是在 2026-06-07，使用已发布的 0.1.3 PyPI 软件包进行验证，随后通过 MCP 工具界面完成了两次完整的监督式现场烘焙。在操作任何新的硬件配置之前，必须执行受保护的手动验证流程。

配置位于 coffee-roaster-mcp.yaml 中。除非有意验证已连接的 Hottop 硬件，否则本地开发应使用 Mock 驱动：

roaster:
  driver: mock
  port: null
  baudrate: 115200
  temperature_unit: celsius
  command_interval_seconds: 0.3

进行受保护的硬件验证时，将 driver 切换为 hottop_kn8828b_2k_plus，明确设置串口，并运行验证工具，同时指定证据输出路径：

coffee-roaster-mcp hottop-validate \
  --config coffee-roaster-mcp.yaml \
  --output docs/validation/hottop-e3-s9-non-destructive.json \
  --i-understand-this-controls-hardware

不可逆操作和安全操作检查需显式选择启用：

coffee-roaster-mcp hottop-validate \
  --config coffee-roaster-mcp.yaml \
  --output docs/validation/hottop-e3-s9-full.json \
  --i-understand-this-controls-hardware \
  --include-drop \
  --include-emergency-stop

此处的硬件安全至关重要：在将 Hottop 路径视为可供发布之前，必须在有人监督的烘豆机上验证命令循环节奏、数据包处理、温度单位、卸豆行为、冷却行为、紧急停止和清理流程。当前的 MCP 烘焙会话工具会调用已配置的驱动边界，因此除非明确计划执行受保护的 Hottop 验证，否则正常开发应使用 Mock 驱动。

可选的 Hottop MCP 现场验证属于受门控的手动操作。只有在有人监督烘豆机、明确配置 hottop_kn8828b_2k_plus、串口已知且停止计划明确时，才运行该验证。通过验证的预期证据包括：MCP 客户端可以启动一个会话、设置热量和风扇、读取已连接设备的状态及合理的温度、调用 drop_beans 触发卸豆和冷却、从 get_roast_state 读取 beans_dropped 和 cooling_started 时间戳、在烘豆机报告冷却已关闭时停止冷却，并将任何故障保留为故障事件。任何串口、遥测、命令循环或安全方面的不确定性都应视为验证失败，且正常 CI 不应要求此项验证。

配置

RoastPilot 默认从当前目录中的 coffee-roaster-mcp.yaml 加载配置。如果该文件不存在，则使用 Mock 安全默认设置，因此本地开发无需烘豆机硬件、音频硬件或下载模型。

有关 Mock 安装、Hottop 配置、Hugging Face 模型配置、离线模型路径和日志输出路径等设置示例，请参阅安装与硬件设置指南。

transport:
  type: stdio

roaster:
  driver: mock
  port: null
  baudrate: 115200
  temperature_unit: celsius
  command_interval_seconds: 0.3

first_crack:
  mode: disabled
  repo_id: syamaner/coffee-first-crack-detection
  revision: null
  precision: int8
  local_model_dir: null
  onnx_threads: 2
  confidence_threshold: 0.9
  min_positive_windows: 1
  confirmation_window_seconds: 20.0
  allow_manual_override: true

audio:
  source: microphone
  input_device: null
  sample_rate: 16000
  wav_path: null
  replay_mode: realtime
  window_seconds: 1.0
  overlap: 0.0
  hop_seconds: null

ambient:
  mode: disabled
  device: null
  poll_interval_seconds: 30.0

recording:
  # Recording runs through the audio first-crack capture runtime.
  # Live capture also requires first_crack.mode: audio and audio.source: microphone.
  enabled: false
  autocapture: false
  export_location: null
  sample_rate: null
  # When set, the first entry must match audio.input_device.
  devices: null

logging:
  log_dir: ./logs
  sample_interval_seconds: 5.0
  export_formats:
    - jsonl
    - csv
    - summary

session:
  auto_t0_detection_enabled: false
  auto_t0_drop_threshold_c: 25.0
  ror_window_seconds: 60
  ror_min_sample_seconds: 10

支持的环境变量覆盖项：

  • COFFEE_ROASTER_MCP_CONFIG
  • COFFEE_ROASTER_DRIVER
  • COFFEE_ROASTER_PORT
  • COFFEE_ROASTER_TEMP_UNIT
  • COFFEE_FIRST_CRACK_MODE
  • COFFEE_FIRST_CRACK_REPO_ID
  • COFFEE_FIRST_CRACK_REVISION
  • COFFEE_FIRST_CRACK_PRECISION
  • COFFEE_FIRST_CRACK_LOCAL_MODEL_DIR
  • COFFEE_FIRST_CRACK_ONNX_THREADS
  • COFFEE_FIRST_CRACK_CONFIDENCE_THRESHOLD
  • COFFEE_FIRST_CRACK_MIN_POSITIVE_WINDOWS
  • COFFEE_FIRST_CRACK_CONFIRMATION_WINDOW_SECONDS
  • COFFEE_AUDIO_SOURCE
  • COFFEE_AUDIO_INPUT_DEVICE
  • COFFEE_AUDIO_SAMPLE_RATE
  • COFFEE_AUDIO_WAV_PATH
  • COFFEE_AUDIO_REPLAY_MODE
  • COFFEE_AUDIO_WINDOW_SECONDS
  • COFFEE_AUDIO_OVERLAP
  • COFFEE_AUDIO_HOP_SECONDS
  • COFFEE_AMBIENT_MODE
  • COFFEE_AMBIENT_DEVICE
  • COFFEE_AMBIENT_POLL_INTERVAL_SECONDS
  • COFFEE_RECORDING_ENABLED
  • COFFEE_RECORDING_AUTOCAPTURE
  • COFFEE_RECORDING_EXPORT_LOCATION
  • COFFEE_RECORDING_SAMPLE_RATE
  • COFFEE_RECORDING_DEVICES
  • COFFEE_ROAST_LOG_DIR
  • COFFEE_AUTO_T0_DROP_THRESHOLD_C
  • HF_HOME

audio.source 可以设为 microphone 或 wav。麦克风采集使用由 PortAudio 驱动的 sounddevice 流，并将配置的设备标识保留在音频输入边界内， 以支持 macOS、Linux 和 Raspberry Pi 主机。WAV 回放使用 PCM .wav 文件， 将各声道转换为与麦克风采集相同的单声道浮点采样格式，并要求文件采样率与 audio.sample_rate 一致。WAV 回放默认使用后台 realtime 采集 流水线。对于本地带标签样例验证，请设置 audio.replay_mode: detector_paced，并设置与检测器兼容的 audio.window_seconds，以及 audio.overlap 或 audio.hop_seconds， 这样每个完整的 WAV 窗口都会在检测器／运行时就绪后立即处理， 不需要按真实时间等待，也不会出现正常的队列丢弃。

仓库通常不会提交音频。目前唯一的例外是 tests/fixtures/audio/ 下小型的派生 E7-S5a 带标签回放样例，该样例经过裁剪、 重采样、重置时间戳，并附有清单文档。 原始录音、大规模训练／评估音频、模型文件、烘焙日志 和串口采集内容仍会从 git 中排除。

已发布模型的带标签回放验证为可选／本地操作，不属于默认 CI 套件：

./.venv/bin/python scripts/validate_first_crack_wav_replay.py

该脚本会使用固定的 INT8 Hugging Face 文件和检测器驱动的 WAV 回放， 在模拟烘焙机上启动 stdio MCP 服务，然后使用公开 MCP 工具， 根据样例标签验证一爆检测，并导出 roast.jsonl、roast.csv 和 summary.json。

进行麦克风采集时，audio.input_device: null 会使用系统默认输入设备。 若要指定特定麦克风，请将 audio.input_device 设为 PortAudio 可解析的设备名称或平台设备标识。在 Linux 和 Raspberry Pi 上， 使用 arecord -l 和 arecord -L 检查 ALSA 设备；由于 ALSA 可以 执行格式转换，plughw:1,0 之类的值通常比原始的 hw:1,0 更宽容。在 macOS 上，可使用系统声音设置，或在手动验证时查看 sounddevice 设备列表。 真实麦克风检查是可选的，只应在明确配置 first_crack.mode: audio 和 audio.source: microphone 时运行。

可选的真实麦克风验证属于受控的手动操作。运行前， 请配置已发布的 Hugging Face ONNX 文件或经过验证的 first_crack.local_model_dir，选择预期使用的麦克风，并确认 MCP 进程可以启动，且不会出现文件或音频采集错误。通过验证的预期证据包括： get_roast_state.first_crack_status 在受监督的烘焙或受控回放过程中从 pending 变为 detected，记录的 first_crack_detected 事件包含检测器元数据， 且正常的烘焙控制仍可使用。缺少文件、音频设备不可用和检测器故障应显示为 unavailable 或 faulted 状态，并排除在常规 CI 之外。 HF_HOME 由 Hugging Face 工具直接使用，不会复制到 RoastPilot 配置对象中。

Hugging Face 模型边界

此仓库不会训练、导出、同步或发布首爆模型。

coffee-first-crack-detection 仓库仍是以下内容的事实来源：

  • 模型训练
  • ONNX 导出
  • Hugging Face 工件发布
  • 模型卡片
  • 数据集卡片

RoastPilot 只使用 syamaner/coffee-first-crack-detection 中已发布的工件。此仓库的运行时边界是推理时配置和模型选择，而非模型生命周期管理。

当前首爆默认设置旨在确保本地开发安全：

  • mode: disabled
  • precision: int8
  • repo_id: syamaner/coffee-first-crack-detection

此默认设置可确保在有意配置音频模式之前，本地设置不会访问 Hugging Face 网络。 有意配置 first_crack.mode: audio 时，RoastPilot 会通过 ONNX Runtime 使用已发布的 ONNX 工件，并通过 MCP 自有的 NumPy/SciPy MelFrontend 使用已发布的 AST 预处理器配置；模型训练、导出和 Hub 发布仍在此仓库之外。

在音频模式下，启动烘焙会话时，会准备配置的音频采集流水线和已发布工件的检测器运行时。只有在记录 T0 且当前会话处于 roasting 状态后，才会处理检测器窗口。检测器确认输出后，会通过权威会话时间线记录一次 first_crack_detected。首爆自动记录或通过显式手动覆盖记录后，运行时会停止；下豆、冷却完成、紧急停止和进程关闭时也会停止。工件缺失、音频采集不可用和检测器错误会通过 get_roast_state.first_crack_status 显示为 unavailable 或 faulted，而不会导致常规烘焙控制崩溃。禁用和手动首爆模式不会启动音频采集或检测器运行时。

日志导出

RoastPilot 目前支持通过 export_roast_log 导出当前进程内会话的快照。

当前导出文件：

  • roast.jsonl：烘焙期间仅追加的事件和采样遥测数据行
  • roast.csv：包含遥测和事件行，使用规划中的 CSV 列，涵盖时间戳、经过秒数、阶段、温度、控制项、事件标志、发展百分比、RoR/差值指标和首爆模型元数据
  • summary.json：包含会话时间戳、烘焙总秒数、发展指标、烘焙机驱动程序和首爆模型元数据
  • 输出路径为 logs/roasts/{session_id}/

跨格式日志架构完整性测试已就绪。2026 年 6 月发布包基线和 2026 年 8 月集成式 Agent 烘焙报告记录了当前的实时验证边界；新的硬件配置仍需单独进行有人监督的验证。

评论

支持 Markdown

第一次接触 MCP？

从协议是什么，到在客户端里装上第一个服务，这几条回答覆盖了大多数入门问题。

一个开放协议，规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话，MCP 服务负责提供工具、资源和提示模板，两者通过标准消息通信，同一个服务可以被不同客户端复用。