调用链显示成功，为什么Agent还是修错了页面？

给Agent一张页面截图，让它修复布局；上传一张报错图片，让它判断原因。在多模态交互里，图片早就不是"补充材料"，而是模型理解任务的一部分。

问题也随之变得更具体：当Agent的回答不符合预期，开发者怎么确认它到底看到了什么？调用链显示成功，耗时和Token消耗也正常，但排查时如果只能看到附件ID或一段不可读的编码内容，就很难判断偏差究竟发生在输入、模型理解，还是后续工具执行环节。

火山引擎日志服务TLS AgentLoop在会话与调用链观测的基础上，进一步支持多模态内容展示。开发者可以在对应的消息和调用节点中直接查看图片，并把图片与提示词、模型输出、工具结果放在同一条链路里分析。

只看执行记录，回答不了"基于什么内容"

传统调用链能回答"任务如何执行"：哪些步骤被触发、每个阶段耗时多少、错误出现在哪个节点。对纯文本任务来说，这通常已经足够定位大部分问题。

多模态任务还要回答另一个问题：这次执行是基于什么内容发生的。

以"根据截图修复页面"为例，模型调用和代码修改都可能显示成功，但页面效果仍不符合预期。此时开发者需要核对上传的截图是否正确、关键区域是否清晰、提示词是否准确描述预期，以及模型输出和工具修改是否对应截图中的问题。

如果日志里只有附件ID，就要另找原始文件；如果图片独立存放，又难以对应具体会话和轮次；如果把大段Base64写入日志，记录虽完整，阅读和检索效率却很低。对业务方来说，还存在三个现实问题：

• 数据完整性：多模态文件以Base64混入日志或Trace数据，可能导致一条日志或Trace Span超长被截断，造成数据不完整，影响观测数据的可用性，视频、音频等多模态文件尤其明显。
• 成本较高：多模态内容以Base64混入Trace Span或日志中，作为通用Trace或日志字段进行索引和存储，成本较高。
• 使用低效：多模态文件的阅读、管理与Trace、日志的关联效率低。

媒体回到会话和调用链里

TLS AgentLoop沿用已有的Session、Trace和Span结构：Session串联多轮会话，Trace表示一次请求或一轮任务，Span记录模型调用、工具执行等具体阶段。多模态内容出现在对应的消息和调用节点中，而不是被放进孤立的附件列表。

列表发现环节，在Trace、Session列表中，包含多模态内容输入的记录会显示媒体标识。开发者可以结合状态、耗时、Token等已有信息，快速筛出需要进一步检查的记录。进入详情后，左侧调用树会继续标识包含媒体的Span或Trace。即使一次任务包含多轮交互和多个执行步骤，也能沿着原有浏览路径定位到相关内容。

原位预览环节，在支持输入、输出的格式化视图中，图片可以直接预览并按需放大；对于已提供且受支持的媒体数据场景，前端也支持音频、视频播放。文字与媒体保留在同一条消息上下文中，开发者可以对照提示词、模型回答和执行信息阅读，不必在截图、日志和调用链之间来回拼接。

会话复盘环节，在Session详情中，多轮任务可以连续查看各轮输入、输出，再进入关联的Trace检查执行细节。媒体属于哪一轮交互、与哪段文字对应，都能在会话中保留下来。对团队协作来说，这也减少了反复转发截图、粘贴日志、补充背景的时间成本，大家围绕同一条会话和调用链讨论，信息口径更容易对齐。

一次图文请求的排查路径

当一条包含图片的Agent任务结果不符合预期时，可以沿着"输入—执行—反馈"三个步骤排查。

第一步是核对输入。展开相关模型调用，在输入区域直接查看采集的截图及文字要求，重点看三件事：截图是否为预期图片；关键区域是否清晰；提示词是否明确说明期望结果。如果输入本身有缺失或歧义，应优先检查输入组织和提示词，而不是将问题直接归因于模型能力。

第二步是对照执行。如果输入符合预期，再检查模型输出、工具参数和工具结果。模型给出的修改方向是否对应截图中的问题？工具修改的文件是否正确？执行过程中是否出现异常？后续调用是否根据工具结果继续处理？图片提供任务背景，Trace提供执行步骤，两者结合，排查才不会只停留在"结果不对"的判断上。

第三步是追踪反馈。对于需要多次补充要求的任务，可以回到Session视图，查看用户后续反馈是否出现在对应轮次，模型是否据此调整回答。

这里要保留一个判断边界：某条记录未显示图片，不等于模型一定没有收到图片。媒体是否可见，还受采集开关、插件覆盖范围、上传结果、访问权限和网络条件影响。

媒体引用替代Base64的实现思路

不同团队的多模态数据来源并不相同：来自Agent运行时附件；已存放在客户自有TOS桶中的媒体文件；直接使用公开可访问的图片、音频或视频链接。TLS AgentLoop的多模态观测能力围绕这些场景提供接入方式，让媒体内容能回到对应的Session、Trace和Span中，成为可查看、可关联的调用上下文。

对于Agent运行过程中产生或接收的本地附件，TLS插件或SDK可以在采集阶段识别多模态内容，并完成媒体读取、上传授权、对象存储和引用上报。

以DSH（DeepSeek Harness）图片采集为例，插件会识别模型输入中的图片附件，读取文件内容，并获取MIME类型、文件大小、内容摘要等信息。随后，插件通过TLS附件能力申请上传地址，取得对象存储TOS对象标识和临时上传地址，再将图片文件上传至TOS。Trace上报时，插件不会把大段Base64写入日志，而是在原消息位置写入媒体引用。引用包含对象位置、媒体类型、大小、摘要等元数据，TLS负责记录Trace、消息结构和媒体引用，TOS负责保存图片等二进制内容。这种方式适合希望由采集插件或SDK托管媒体处理链路的客户。

如果客户已将图片、音频、视频等多模态资源存储在自有TOS中，TLS AgentLoop也支持将这些资源与调用过程关联，无需业务侧重复上传文件。在这种模式下，业务系统或采集SDK可以在上报Trace时携带媒体对象的引用信息，例如TOS对象位置、媒体类型、文件大小、内容摘要等。TLS保存的是"这条消息关联了哪一个媒体对象"，而非媒体文件本身。当开发者在AgentLoop中查看会话或Trace详情时，前端会根据媒体引用申请临时访问地址，再从TOS读取对应内容并完成预览。这样既保留了客户对私有媒体资源的存储与权限管理方式，也让媒体内容能够回到调用链中。

多模态可观测的价值，不只在于"日志中能看图"，还在于让媒体内容成为可查看、可关联的调用上下文。一次图文请求，从"执行过"变成"看得清"，排查才有落脚点。