QQ delivers emoji messages as opaque <faceType=..,faceId="..",ext="..">
markup fragments (the ext field holds a base64 JSON blob with the face
name, e.g. {"text":"吃瓜"}). Without translation, the Harness receives
only this unusable tag and loses what the sender actually meant.
Register the SDK's contentSanitizer({ parseFaceTags: true }) middleware,
mirroring tencent-connect/dsh-qqbot, so C2C and group inbound messages
surface as e.g. 【表情: 吃瓜】 instead of the raw tag.
- qq-runtime.mjs: register contentSanitizer before the typing indicator
- runtime.test.mjs: assert sanitizer registration and update middleware order
- lib/index.js: regenerated host bundle
Real agent turns invoke tools constantly; one 'Tool call X' message
per call flooded the chat with near-zero information. Tool frames now
only flush the pending interim explanation text; successful tool
results stay silent, and failures still push the tool name with the
error detail.
Resolve qq-bridge.mjs by keeping the inbound-file support (hasFiles,
files passthrough) and dropping the upstream stream session, which
this branch replaces with the discrete turn-feed notices.
Show what the agent is actually doing during a turn, the way Claude
Code does: interim explanation text, every Tool call, and the error
detail when a tool fails, each as its own pushed message before the
final markdown answer.
- HarnessReplyTracker.consume now returns every frame of a polling
batch in order (same-batch text frames collapse to the latest)
instead of dropping all but the last event, which silently ate
tool-call frames that shared a batch with their result
- tool frames carry callId; status frames carry the correlated
toolName and a flattened error text parsed from the tool/result
error payload (message, or name: code)
- the QQ bridge holds interim step text until the next tool call
(or the end of the turn) pushes it, emits 'Tool call <name>' per
call, emits 'Tool call <name>\nError: <reason>' for failures, and
skips re-sending interim text that already equals the final answer
Other channels keep their existing behaviour: the status frame still
reads '正在整理结果…' and they ignore the new optional fields.
Replace the in-place streaming reply (openStream replace-mode frames)
with discrete pushed messages, so the chat no longer flickers while
the turn is running:
- each tool call pushes one notice message (正在使用X…); status frames
such as '正在整理结果…' and per-token text frames are not pushed
- the final answer arrives as one new markdown message
- a stopped turn still announces '已停止。'; no stream session is
created, so there is nothing to cancel or finalize
The shared Harness client emits a '正在整理结果…' status update after
every tool/result. Pushing each one into the QQ stream message made
multi-tool turns repeatedly flash that notice instead of showing real
progress. Skip status frames in the QQ onUpdate handler so the stream
keeps the last meaningful frame (tool name or generated text), which
matches the official dsh-qqbot behaviour of not pushing tool-noise.
Deliver final Harness answers to QQ as msg_type=2 markdown so bold,
headings, code blocks, lists, and tables render natively in QQ.
- add markdown-reply.mjs: chunk long answers at code-fence/table
boundaries (4500-char limit) and send each chunk with a unique
msg_seq to avoid passive-reply dedup (40054005)
- fall back to plain text per chunk when the platform rejects
markdown, so bots without markdown capability keep working
- route the non-stream final answer path in qq-bridge through the
markdown sender; streaming replies already use markdown content
type, and command/notice texts stay plain
