为什么多模态是 Agent 的未来？
传统的文本交互在面对复杂数据时往往不够直观。例如在做性能调优时，一段关于“请求延迟在 14:00 出现尖峰”的文字描述，远不如一张折线图来得清晰明了。
MCP 协议规范原生支持 image 类型的 content block。在工具执行返回时，除了返回文本日志，还可以返回 base64 编码的 PNG 图片或 SVG 矢量图。支持富媒体渲染的客户端可以直接在聊天界面呈现图表，为用户带来绝佳的交互体验。
多模态返回的协议形态
图像在 MCP 里不是附件，而是工具返回内容数组中的一个 content block，与文本块并列。这样设计的好处是「结论 + 证据」可以一次返回：先给一段文字摘要，再给一张图，客户端按顺序渲染即可。
{
"content": [
{ "type": "text", "text": "近 24 小时延迟分布，峰值出现在 14:00 前后。" },
{ "type": "image", "data": "<base64 字符串>", "mimeType": "image/png" }
]
}
字段名以协议文档为准：data 放的是不含 data:image/...;base64, 前缀的裸 base64，mimeType 必须与图片实际编码一致。写完先用 MCP Inspector 看原始报文，确认客户端拿到的是合法图片而不是被截断的字符串（排查手法见 使用 MCP Inspector 本地调试工具：抓包分析 JSON-RPC 报文与 Schema 验证）。
三类能力的落地选型
| 能力 | 本地实现 | 云端 API | 取舍要点 |
|---|---|---|---|
| 图像处理 / 截图 | 无头浏览器截图、图像缩放与格式转换 | 云端视觉理解与编辑 | 本地可控、无出境风险；云端能力强但受配额限制 |
| 图表生成 | 服务端绘图库出 PNG，或生成 SVG 直出 | 托管图表服务 | SVG 体积小、可缩放，但并非所有客户端都渲染 |
| 音频转写 | 本地模型转写，按分段并发 | 云端语音识别 | 本地适合会议纪要常驻；云端适合长音频与多语种 |
经验上优先级是这样排的：先做图表生成（输出确定、不依赖外部配额、演示效果最直接），再做截图类图像处理（业务价值明显但要管好权限与磁盘），最后做音频转写（链路最长，涉及上传、排队、进度回传）。
工程细节决定体验
体积。base64 会让原始字节膨胀约三分之一，一张两 MB 的截图进报文就是近三 MB。做法是先按客户端常见显示尺寸把长边压到千像素级、转成压缩格式，再决定是否内联；超过阈值时改为返回资源引用（把图落到可访问路径，用 Resource 或 URL 指过去），别让工具一次吐出几十张原图。
时延与进度。渲染一张图或转写一段音频通常远超模型的等待耐心，应拆成「提交任务 + 查询状态」两个工具，或在流式返回里持续推送进度文本，让模型有东西可以复述给用户。
可复现。把生成参数（时间范围、聚合粒度、分辨率）写进返回的文本块里，否则用户过五分钟再问同一张图，会得到一张「看起来不一样」的图。
落地示例：性能诊断图表工具
一个可复现的完整链路：工具接收 metric、start、end 三个参数；内部拉取时序数据后用服务端绘图库出图；按 1200px 长边导出 PNG 并转 base64；返回一个文本块（峰值、均值、异常区间）加一个 image 块。验收标准是三条：客户端能直接看到图；文本结论中的数字与图上曲线一致；同样参数重复调用得到视觉上相同的图。
常见故障速查
| 现象 | 原因 | 处理 |
|---|---|---|
| 客户端只显示文字不显示图 | 客户端不支持 image 块渲染 | 降级为文件路径或可访问 URL |
| 图片打不开 / 花屏 | base64 带了 data URI 前缀或被截断 | 只传裸 base64，校验长度与 mimeType |
| 一次调用耗时过久被中断 | 同步等渲染或转写完成 | 拆成提交 + 轮询，或提高超时并推进度 |
| 报文体积过大 | 直接内联原始截图 | 先缩放压缩，超阈值改走资源引用 |
| 图表与文字结论对不上 | 取数窗口与聚合粒度不一致 | 把参数回显进文本块，统一口径 |
小结
判断多模态工具是否达到可用状态，用三个可检查的条件：同一组参数重复调用，图与数字保持稳定；报文体积在客户端可接受范围内（大图走引用而不是内联）；文字结论能独立成立，即使客户端不渲染图片，用户也能看懂结果。三条里有一条不满足，就先把该能力的范围缩小，而不是继续加功能。