为聊天界面提供代码模式下的工具子调用渲染能力，将每个子调用以…

# 电商客服机器人多层级工具调用调试指南

一、问题定位

你看到的“嵌套调用不展示”，通常是这三种原因之一：

• 代理模式下嵌套调用被折叠：Agent 框架（如 LangChain、Coze、Dify）在中间层发起的子调用，默认只在控制台记录，不回传给前端
• 消息协议未传递层级信息：前端只收到最终文本流，中间的 tool_call 事件没透传
• 流式事件未区分类型：3 层调用（客服机器人→订单查询→物流接口）混在一条消息里，前端无法按“原生工具行”渲染

二、后端改造要点

• 透传工具事件：在流式响应（SSE/WebSocket）中，把每一层 on_tool_start / on_tool_end 事件单独推送，不要只在内部日志打印
• 携带层级元数据：每个事件附带 parent_call_id 和 call_id，前端靠它构建树形结构
• 保证 trace 透传：订单查询工具内部调用物流接口时，需把外层的 call_id 作为参数传入（或用 context 变量），否则物流调用会被识别为孤立调用

三、前端渲染要点

• 按消息协议渲染工具行：主流格式（如各家的 Tool Use 块）中，tool_use / tool_result 类型应渲染为原生工具卡片行，而非文本
• 实现缩进树展示：根据 parent_call_id 缩进，形成：

• 🛠 订单查询工具
• 🔗 物流接口调用
• 📦 物流详情返回

• 状态标识：调用中（转圈）、成功（✓）、失败（✗ + 错误摘要），失败时可展开查看原始入参/出参

四、调试建议

• 先抓协议：用浏览器开发者工具的 Network 面板过滤 SSE 流，确认后端是否发出了 3 组 tool 事件
• 分层排查：若事件缺失，问题在后端/框架配置；若事件有但渲染错，问题在前端解析逻辑
• 善用框架调试模式：LangSmith、Dify 日志等可直接看到调用树，先验证逻辑正确再调前端

五、常见坑

• 嵌套调用在异步任务里执行，事件推送顺序错乱 → 用 call_id 排序而非时间戳
• 物流接口调用若非标准工具注册（如直接 HTTP 请求），不会被识别为工具行 → 需包装成标准 tool

需要的话我可以基于你用的具体框架（Coze/Dify/LangChain/自研）给出更细的配置方案。