[连续对话判断]:完成自动持续对话和播报打断,包含回复意图判断、免唤醒追问和打断回归测试

This commit is contained in:
mkbk
2026-06-18 12:08:41 +08:00
parent 1e956f5eb6
commit 7519725321
16 changed files with 1059 additions and 119 deletions
@@ -135,6 +135,52 @@ The system SHALL provide a deterministic simulated microphone acceptance command
- **WHEN** the simulated microphone transport runs out of frames before the expected turn completes
- **THEN** the command SHALL fail with a structured error instead of waiting indefinitely
### Requirement: Automatic continuous dialog decision
The live runtime SHALL automatically decide after each assistant reply whether to continue listening for a direct follow-up answer or to end the continuous session and return to wake standby.
#### Scenario: Assistant asks the user a direct follow-up question
- **WHEN** an assistant reply clearly asks the user a question, requests missing information, asks the user to choose among options, or otherwise waits for the user's next answer
- **THEN** the continuation decision SHALL be `continue` with confidence at or above the configured threshold
- **AND** the runtime SHALL enter follow-up listening after playback without requiring the wake word again
#### Scenario: Assistant completes the answer
- **WHEN** an assistant reply only provides an answer, reports a result, refuses, reports an error, ends a greeting, or is ambiguous about needing more user input
- **THEN** the continuation decision SHALL be `standby`
- **AND** the runtime SHALL return to wake standby after playback
#### Scenario: Hybrid decision falls back to an LLM classifier
- **WHEN** deterministic rules cannot decide continue or standby
- **THEN** the hybrid provider SHALL call the configured cloud LLM with a classifier prompt that can only resolve to `continue` or `standby`
- **AND** a low-confidence, malformed, timed-out, or failed classifier result SHALL be treated as `standby`
#### Scenario: Follow-up answer arrives in the listening window
- **WHEN** the decision is `continue` and the user starts speaking within `OWNER_FOLLOWUP_LISTEN_TIMEOUT_MS`
- **THEN** the runtime SHALL capture, realtime-transcribe, final-transcribe, send to LLM, synthesize, and play the answer without local wake detection and without the wake acknowledgement phrase
#### Scenario: Follow-up listening times out
- **WHEN** the decision is `continue` but no user speech is detected before `OWNER_FOLLOWUP_LISTEN_TIMEOUT_MS`
- **THEN** the runtime SHALL emit `followup_timeout`
- **AND** it SHALL emit `continuous_session_ended`
- **AND** it SHALL return to wake standby
### Requirement: Barge-in playback interruption
The live runtime SHALL support a first-version barge-in path that can stop assistant playback when the user starts a valid new utterance during TTS playback.
#### Scenario: Echo guard suppresses early playback echo
- **WHEN** TTS playback starts and microphone input appears before `OWNER_BARGE_IN_ECHO_GUARD_MS`
- **THEN** the runtime SHALL NOT treat that input as a user barge-in
#### Scenario: Valid user speech interrupts playback
- **WHEN** TTS playback has passed the echo guard, VAD observes at least `OWNER_BARGE_IN_MIN_SPEECH_MS` of user speech, and realtime STT produces a valid partial transcript
- **THEN** the runtime SHALL emit `barge_in_detected`
- **AND** it SHALL stop remaining playback chunks and emit `playback_interrupted`
- **AND** it SHALL process the user's new utterance as the next input without requiring wake
#### Scenario: Interrupted assistant context is partial
- **WHEN** playback is interrupted before the full assistant reply is spoken
- **THEN** the process-local conversation context SHALL append only the assistant text that had been fully spoken before interruption
- **AND** unspoken assistant text SHALL NOT be appended to the session history
### Requirement: Real provider live fixture acceptance
The system SHALL support scripted full-chain acceptance that drives the live pipeline with generated microphone PCM while using real local speech providers, the configured cloud LLM, and local TTS/playback capability.