怎样让 Android 助手完成“连接耳机，再播放音乐”？

标准回答

我会把这个需求拆成“理解目标、检查能力、执行步骤、核实结果”四部分。模型负责把自然语言转成结构化意图，例如目标耳机和播放内容；真正操作 Android 的是应用里的工具实现。不会让模型生成一段任意代码直接执行。

执行前先读取蓝牙状态、可用设备和权限。耳机名称不唯一就请用户选择；当前版本或应用身份不支持某项操作，就引导用户完成必要步骤。普通应用和经过授权的系统应用能做的事情不同，不能默认任意应用都能静默开蓝牙、连接指定音频设备、控制其他播放器。

确定能力后，由状态机按依赖执行：确认蓝牙已开启，再连接目标耳机，等待连接和音频路由就绪，最后通过可用的媒体控制接口播放。每步都有超时、取消入口和明确状态。接口返回成功往往只表示请求已接受，还要通过回调或查询确认目标状态。

如果耳机连接失败，我会停在连接这一步，告诉用户具体原因，而不是继续播放并从扬声器出声。整个任务用 taskId 串联模型请求、工具调用和设备事件，最终只根据实际执行结果汇报。固定的设备操作流程优先由程序编排，只有需要动态选择下一步时才引入模型规划。

用户说“连接我的耳机”。工具发现两个同名设备时返回需要选择；用户选定后保存本次任务的设备标识。后续连接成功但媒体会话不可控，就明确显示“耳机已连接，请选择播放器”，不把整个任务标记为完成。

不一定。步骤固定、条件清楚的操作适合状态机或工作流，行为更可控，也更容易测试。我会用模型解决表达多样、意图理解和动态选择的问题，再让程序保证依赖、权限和结果校验。只有任务确实需要多步探索时，才扩大模型的自主规划范围。

我会为每个工具定义可观察的完成条件。连接耳机要核对目标设备的连接状态，播放音乐要核对可用媒体会话的播放状态；不能只看调用没有抛异常。等待期间显示执行中，超时但无法确定结果时显示待核实，再查询状态，不让模型自行猜测。

蓝牙开关、配对、Profile 连接、音频路由和媒体控制不是同一个能力。以目标系统实际提供的接口和授权为准，不能把系统内部能力当作普通应用通用 API。