大模型、智能体和 Skills：用比特币语音提醒看懂它们的分工

你对 AI 说：“帮我盯着比特币，到了设定价格就用手机语音提醒我。”这句话很短，背后却需要几种能力配合。

大模型负责理解和推理；智能体负责组织任务、调用工具并检查结果；Skills 提供可复用的做事方法。 行情接口、服务器调度和手机播报，再把这个要求变成真正能运行的服务。

1. 大模型：理解你想做什么

大模型擅长理解自然语言、分析信息、生成文字，以及在支持工具调用的系统中提出下一步操作。

例如，“比特币涨到八万美元叫我”需要变成明确的要求：是美元还是 USDT？采用哪个行情来源？价格一开始就超过目标时，是否立即提醒？提醒一次后结束，还是继续监控？模型可以发现这些歧义，帮你把条件说明白。

最新价格必须来自实际查询。 模型训练中学过的价格、聊天里以前出现的数字，都不能代替当前行情。即使模型支持联网，价格也来自它调用的数据工具，而不是模型凭空知道。

模型也不会因为回复“我会帮你盯着”，就自动在后台运行一天。持续工作需要真正的运行环境和任务调度。

2. 智能体：把要求组织成一次行动

本文所说的智能体，是围绕模型搭建的任务执行系统。它把用户目标、模型、上下文、工具和运行规则组织起来，根据工具返回的结果决定下一步。固定的流程也可以交给预先写好的工作流完成。智能体与工作流的官方说明 ↗

在价格提醒中，智能体需要核对方案、调用实际可用的监控工具、保存任务，并把创建结果反馈给你；发生错误时，要说明卡在哪一步。

模型能提出“查询价格”这个操作，实际发请求的是工具；模型能建议“每分钟检查”，真正持续计时的是服务器上的调度服务。智能体负责把这些环节接起来。

3. Skills：把可靠的方法装进工具包

一个 Skill 通常包含任务说明，也可以附带脚本、参考资料和模板。兼容的智能体按需要读取并使用它，而不是每次从头摸索。Agent Skills 格式说明 ↗

假设有一个合适的“价格监控”Skill，它可以约定：如何读取行情、检查数据时间、比较阈值、避免重复提醒，以及记录失败原因。脚本负责精确计算，说明文件告诉助手何时使用、如何解释结果。

Skill 不会把一个新大模型装进手机，也不会自动增加账户权限。 它的运行仍依赖实际存在的工具、软件和授权。如果智能体已有完整的价格监控能力，这个任务也可以不额外安装 Skill；Skill 的价值在于让方法更容易复用和检查。

4. 一个完整例子：比特币达到条件后语音提醒

下面是一份用于理解分工的需求示例。80,000 美元是演示阈值，不是当前报价或买卖建议。 是否能直接创建，要以当前工作区支持的行情来源、监控规则和实际返回结果为准。

帮我监控比特币的美元价格，采用 CoinGecko 的 BTC/USD 报价，每 60 秒检查一次。未来 24 小时内，当一次有效采样低于 80,000 美元、之后一次有效采样达到或超过 80,000 美元时，用 MochiBot 中文语音提醒我一次，然后结束。先给我确认方案；如果开始时已达到目标，先问我要不要立即提醒。不要下单交易。

先形成可核对的方案

助手需要明确币种、来源、计价单位、条件、检查周期、有效期、重复规则和接收手机。有效期应显示具体结束时间与时区；行情接口是否可用、是否需要另外配置，也应在创建前说明。

这里的 BTC/USD 不能悄悄换成某交易所的 BTC/USDT。不同来源的价格可能不同。以 CoinGecko 为例，其价格接口可以返回报价及更新时间，用于判断数据是否过旧。价格接口与更新时间说明 ↗

核对方案后，再按当前提醒流程回复“确认”。只有实际创建成功、能查到已启用任务，才算进入监控。 方案文本本身只是待办的说明。

再由服务器持续检查

服务器按计划取价，程序检查来源、数值和时间，再执行比较。例如，两次有效采样分别为 79,980 与 80,020 美元，就满足这个示例的跨越条件。

取价失败或数据过旧时，应记录异常并重试，不能把空值当作零，也不能把旧价格当作新变化。每 60 秒采样可能漏掉两次检查之间短暂发生的越线，因此它不是逐笔行情监控。

对于这种已经明确的数值条件，可以用程序取价、比较和去重，不必每分钟重新问一次大模型。如果还要求“结合新闻解释原因”，才涉及额外的数据查询和模型分析，耗时与用量也会不同。

最后由手机接收并播报

条件满足后，服务端生成提醒事件，通过已接入的通道送到手机。MochiBot 收到后，再根据提醒开关、系统权限和手机状态进行通知及语音播报。

所以，模型负责理解“提醒我”，手机上的语音功能负责真正“说出来”。把通知发出去、手机收到通知、手机实际播报，是三个需要分别核对的结果。

5. 两个“60 秒”，分别在做什么？

服务器检查行情的周期，决定多久取一次新价格。手机接收提醒的连接方式，决定已产生的提醒如何到达手机。两者可以分别配置，不能混为一个计时器。

当前 Android 提醒接收方案采用最长约 60 秒的长轮询等待：有事件时，服务端可以提前返回，并不意味着每条提醒都必须再等满 60 秒。网络、系统后台限制和手机状态仍会影响到达时间。

长轮询只是一种接收方式，不能绕过手机系统的后台限制。正式使用前，应在自己的手机上验证锁屏接收与播报。

6. 自建服务器和托管工作区，谁负责哪一段？

两种方式的分工相同，主要区别在于运行环境由谁维护。

• 自建服务器：你负责服务器在线、更新、网络、行情工具与任务运行；模型可以是已配置的云端 API，也可以是运行环境支持的本地模型。
• 托管工作区：平台维护运行环境；你使用自己的工作区，并按方案配置模型。是否支持某个行情源或监控规则，仍以实际能力为准。
• MochiBot：提供聊天、查看任务、接收提醒和手机语音等入口。更换聊天入口时，要另行核对那个入口的通知与语音能力。

服务器持续监控，不需要把聊天页面一直停在屏幕上；手机及时播报，则需要它保持联网并允许提醒接收。iPhone / iPad：开发中。

7. 怎样判断这件事真的安排好了？

不要只看助手是否说“好的”，要能核对以下结果：

1. 方案明确：来源、单位、阈值、重复规则和结束时间说清楚了。
2. 任务存在：确认后能看到已启用任务，以及实际支持的运行状态。
3. 监控有记录：能核对取价时间、条件判断或失败原因。
4. 提醒能到达：先做一次普通语音测试，再验证条件触发；取消后也应停止后续检查或触发。

大模型让你用自然语言提出需求，智能体把能力组织起来，Skills 把做法沉淀下来，工具与运行服务完成实际操作。它们配合得好，你才可以从“反复打开行情软件”，变成“让系统按确认的条件留意，需要时再告诉我”。

接下来可以阅读 MochiBot 语音提醒：方案、确认、查看与取消，或到 Skills 目录 查看每个技能实际提供的能力。