fix(harness): normalize ToolMessage structured content in serialization

[mvanhorn]

Summary

When models return ToolMessage content as a list of content blocks (e.g., [{"type": "text", "text": "..."}]), the UI displays the raw Python repr string instead of the extracted text.

Why this matters

• #1149 reports text display abnormality when qwen3-max returns structured tool responses
• The same normalization pattern was already applied to titles in PR #1155, but the main message serialization path was not updated

Changes

Two call sites in client.py used str(msg.content) for ToolMessage content when it isn't a string. Replaced both with the existing _extract_text() helper, which already handles string content, list-of-blocks content, and other types:

1. _serialize_message() (L242) - used in values events
2. stream() (L348) - used in messages-tuple events

Added test_serialize_message_content.py with 6 regression tests covering string, list-of-blocks, mixed, and empty content.

Testing

cd backend && PYTHONPATH=. uv run pytest tests/test_serialize_message_content.py -v  # 6 passed
cd backend && PYTHONPATH=. uv run pytest tests/test_client.py -v                     # 81 passed (no regressions)
cd backend && uvx ruff check .                                                        # clean

Fixes #1149

This contribution was developed with AI assistance (Claude Code).

[Copilot]

Pull request overview

Normalizes LangChain ToolMessage structured content (list-of-blocks) to plain text during backend serialization so the frontend doesn’t display Python repr(...) strings for tool results.

Changes:

• Replace str(msg.content) with _extract_text(msg.content) for ToolMessage serialization in both _serialize_message() and stream().
• Add regression tests covering _serialize_message() behavior for tool message content variants.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
backend/packages/harness/deerflow/client.py	Uses _extract_text() to normalize ToolMessage content for values and messages-tuple streaming events.
backend/tests/test_serialize_message_content.py	Adds regression tests to ensure _serialize_message() extracts plain text from ToolMessage list/block content.

[WillemJiang]

@mvanhorn, thanks for your contribution. The user shows the content in the issue #1149 comes from the browser, but your patch is for the DeerFlow Client. I don't think your PR can fix the issue.

[mvanhorn]

@WillemJiang - good question. The abnormal text the user sees in the browser originates from the backend serialization. When qwen3-max returns structured ToolMessage content (a list of content blocks), str(msg.content) in client.py sends the Python repr string [{'type': 'text', 'text': '...'}] to the frontend, which renders it literally.

This is the same pattern that was fixed for titles in PR #1155 - this PR extends _extract_text() to the two remaining serialization paths in _serialize_message() and stream().

If there's also a separate frontend rendering issue, this PR wouldn't cover that - but the backend producing clean text instead of Python repr strings should address the reported symptom. Happy to close if you've already fixed this elsewhere.