尧图网页设计 
CopilotKit × Google ADK 集成Tool Rendering 功能 QA 验证指南与 useRenderTool 源码剖析【免费下载链接】CopilotKitThe Frontend Stack for Agents Generative UI. React, Angular, Mobile, Slack, and more. Makers of the AG-UI Protocol项目地址: https://gitcode.com/GitHub_Trending/co/CopilotKit本指南以showcase/integrations/google-adk/qa/tool-rendering.md为骨架结合该演示场景的前后端源码与端到端测试系统讲解「如何验证 Google ADK Agent 的工具调用在 CopilotKit 聊天界面中被渲染为 React 组件卡片」。读完本文你将掌握 tool-rendering 演示的完整验收流程含前置条件、建议按钮、天气卡片、错误处理与预期指标并能对照源码理解useRenderTool/useDefaultRenderTool的渲染原理与测试自动化方案。一、场景定位QA 文档覆盖的 tool-rendering 演示在 CopilotKit 的 Google ADK 集成示例中tool-rendering演示展示的核心能力是后端 Agent 的工具调用tool call不再以晦涩的 JSON 文本形式出现在聊天记录里而是被前端渲染成品牌化的 React 组件卡片例如天气卡片、航班列表卡片、股票卡片与骰子卡片。从 演示页面源码 顶部注释可以看到这是「三阶段递进」系列中最完整的一个变体get_weather→WeatherCard /专用渲染器search_flights→FlightListCard /专用渲染器get_stock_price→StockCard /专用渲染器roll_d20→D20Card /专用渲染器其余任何工具 →CustomCatchallRenderer /通配兜底同一目录下还并存tool-rendering-custom-catchall、tool-rendering-default-catchall、tool-rendering-reasoning-chain三个变体它们的后端工具面完全相同见 tool_rendering_common.py 注释差异仅在前端接线方式。QA 文档qa/tool-rendering.md正是针对「基本变体」的验收脚本本文将其逐条展开并下沉到源码层解释「为什么这样验证」。二、前置条件PrerequisitesQA 文档要求验证前满足两个硬性前提Demo 已部署且可访问tool-rendering 演示需要完整的前后端栈Next.js 前端 Google ADK Python Agent 服务都已拉起并对外暴露页面路由Agent 后端健康通过GET /api/health确认后端服务正常。在源码中健康检查路由由 health 路由 提供而 Agent 服务则由 agent_server.py 启动并托管所有注册的 Agent包括ToolRenderingAgent。建议在实际执行 QA 前先执行curl demo-host/api/health确认返回正常后再进入功能验证避免把「后端未就绪」误判为前端渲染缺陷。三、基础功能验证Basic FunctionalityQA 文档将第一层验收定义为「页面能加载、聊天能用」共 4 个检查点导航到 tool-rendering 演示页面验证聊天界面以居中全高布局加载验证聊天输入框占位符Type a message可见发送一条基础消息验证 Agent 能正常回复「居中全高布局」在源码中有明确对应page.tsx 中ToolRenderingDemo将根容器设置为flex justify-center items-center h-screen w-full内部再由max-w-4xl约束聊天宽度这正是 QA 期望的「垂直水平居中、占满视口高度」的布局结构。占位符Type a message由CopilotChat组件CopilotChat agentIdtool-rendering classNameh-full rounded-2xl /默认提供端到端测试也以该占位符作为页面加载完成的信号见下文第七节。四、功能专项检查Feature-Specific Checks4.1 建议按钮SuggestionsQA 文档列出三个必须可见的天气建议按钮Weather in San Francisco建议按钮可见Weather in New York建议按钮可见Weather in Tokyo建议按钮可见点击天气建议后验证其内容填充输入框或直接发送消息需要说明的是建议按钮清单在不同迭代中可能演进。当前仓库源码 suggestions.ts 通过useConfigureSuggestions注册了 5 个建议Weather in SF、Find flights、Stock price、Roll a d20、Chain toolsavailable: always表示建议始终展示。对应的 e2e 测试 tool-rendering.spec.ts 也断言了这 5 个data-testidcopilot-suggestion建议按钮。因此 QA 执行时应以部署版本实际配置的建议列表为准——如果按 QA 文档逐一核对三个城市按钮而当前部署版本未配置应视为「配置差异」而非渲染缺陷。建议按钮的交互语义由 CopilotKit 运行时保证点击建议会将其message字段填入输入框或直接触发发送Weather in SF对应的实际消息是Whats the weather in San Francisco?。4.2 天气卡片渲染useRenderTool这是整个 QA 文档的核心检查项围绕「输入城市 → 调用get_weather工具 → 前端渲染 WeatherCard」的完整链路输入Whats the weather in San Francisco?验证加载状态显示Retrieving weather...并带 spinner验证WeatherCard渲染data-testidweather-card且包含城市名data-testidweather-city摄氏与华氏两种温度湿度百分比data-testidweather-humidity风速mphdata-testidweather-wind体感温度data-testidweather-feels-like天气描述文本与对应天气图标sun/rain/cloud验证卡片背景色与天气条件主题一致天气条件期望主题色晴朗Clear/Sunny#667eea蓝紫降雨/雷暴Rain/Storm#4A5568深灰多云Cloudy#718096中灰降雪Snow#63B3ED浅蓝QA 清单与当前源码的差异核对执行验证时务必对照部署版本确认加载文案QA 清单期望Retrieving weather...而当前 weather-card.tsx 在loading为 true 时渲染的是Fetching weather...温度单位QA 清单期望「摄氏度 华氏度」双单位展示当前源码仅渲染华氏度{temperature}°F见 weather-card.tsx且没有weather-feels-like的 testid 挂载点体感温度由后端返回feels_like字段但当前卡片未消费它背景主题色QA 清单期望按天气条件切换四种背景色当前源码的卡片背景是固定浅色#EDEDF5见 weather-card.tsx天气差异体现在**图标emoji**而非背景色上——conditionsEmoji函数将sun/clear → ☀️、rain/storm → ️、cloud → ☁️、snow → ❄️见 weather-card.tsx。出现这类差异时QA 结论应写为「以部署版本实际行为为准」并可将差异作为待办反馈给维护者确认是功能迭代还是回归。4.3 多次天气查询Multiple Weather Queries询问第二个城市的天气验证第二个WeatherCard正常渲染且不影响第一个卡片验证每张卡片显示各自正确的城市名该检查点验证的是useRenderTool的多实例渲染能力每一次工具调用都会独立挂载一张卡片卡片之间互不覆盖。源码中useRenderTool的 render 回调直接返回WeatherCard loading{loading} location{...} ... /见 page.tsx渲染器是无状态的纯函数组件天然支持每个调用各自产生独立卡片。roll_d20的渲染器注释也明确写道「Each tool call mounts its own card so e2e tests can count them」page.tsx说明这正是设计意图。五、错误处理验证Error Handling发送空消息应被优雅处理不报错、不产生异常界面正常使用过程中控制台无报错空消息的拦截发生在聊天输入层CopilotChat组件对空输入不会发起请求因此验证点应关注「点击发送按钮或回车时页面行为是否稳定」。控制台检查建议在整个验证流程中持续开启 DevTools Console重点关注前端渲染异常React 告警、运行时fetch失败可配合 Network 面板交叉确认是否后端超时、以及useRenderTool渲染回调抛出异常导致的卡片崩溃。六、预期结果汇总Expected ResultsQA 文档给出了 5 条量化验收指标执行时逐条打勾指标阈值聊天界面加载3 秒内Agent 首次响应10 秒内天气卡片渲染所有数据字段齐全天气图标与主题色与天气条件匹配UI 质量无错误、无布局破损这些时间阈值直接对应 e2e 测试中的超时配置页面加载断言使用SUGGESTION_TIMEOUT 1500015 秒比 3 秒阈值宽松以容纳 CI 冷启动工具卡片断言使用TOOL_TIMEOUT 6000060 秒覆盖 Agent 后端工具调用耗时见 tool-rendering.spec.ts。人工 QA 采用更严格的 3s/10s 指标自动化测试则用更宽松的超时换取稳定性两者互补。七、源码级剖析从 QA 用例反推实现原理QA 文档的验收点并非凭空而来每一处都与实现细节一一对应。以下按「前端 → 后端 → 兜底 → 自动化」四条链路拆解。7.1 前端useRenderTool 注册「工具名 → 卡片」映射useRenderTool接受一个配置对象核心字段为name要拦截的工具名、parameterszod schema声明参数结构和render回调返回 React 节点。render 回调接收{ parameters, result, status }其中status用于区分工具调用的执行阶段。以天气为例page.tsxuseRenderTool( { name: get_weather, parameters: z.object({ location: z.string() }), render: ({ parameters, result, status }) { const loading status ! complete; const parsed parseJsonResultWeatherResult(result); return ( WeatherCard loading{loading} location{parameters?.location ?? parsed.city ?? } temperature{parsed.temperature} humidity{parsed.humidity} windSpeed{parsed.wind_speed} conditions{parsed.conditions} / ); }, }, [], );要点解读status ! complete即加载态工具调用在途时status为inProgress/executing此时 WeatherCard 只渲染城市名与「Fetching weather...」占位不渲染数据字段——这正是 QA 文档「验证加载状态」一节的实现基础parameters?.location ?? parsed.city优先取前端声明的参数值结果回包中的city作为兜底保证城市名即使参数丢失也能正确显示parseJsonResultresult在管道中可能是字符串parse-json-result.ts 负责将其安全解析为结构化对象。同类渲染器还包括search_flights → FlightListCard、get_stock_price → StockCard、roll_d20 → D20Card全部集中在 page.tsx 中与 QA 文档「Feature-Specific Checks」的验证对象一一对应。7.2 后端Google ADK Agent 与工具定义QA 文档要求验证的「Agent 能响应」「天气数据字段齐全」其数据源头在 tool_rendering_agent.pytool_rendering_agent LlmAgent( nameToolRenderingAgent, modelget_model(), instructionTOOL_RENDERING_INSTRUCTION, tools[get_weather, search_flights, get_stock_price, roll_d20], after_model_callbackstop_on_terminal_text, )get_weather等四个工具在 tool_rendering_common.py 中定义签名与返回字段直接决定了前端 WeatherCard 能渲染什么def get_weather(tool_context: ToolContext, location: str) - dict: Get the current weather for a given location. return { city: location, temperature: 68, humidity: 55, wind_speed: 10, conditions: Sunny, }返回的city / temperature / humidity / wind_speed / conditions与前端WeatherResult接口page.tsx字段完全对齐这就是 QA 文档要求核对「城市名、湿度、风速、天气描述」的原因。search_flights、get_stock_price、roll_d20同样遵循「返回结构化 dict → 前端按字段渲染」的模式。系统提示词TOOL_RENDERING_INSTRUCTION还约定了 Agent 行为如「航班只给目的地时默认出发地 SFO」「一轮可调用多个工具」这解释了 QA 文档中「Chain tools」与多次查询场景为何能稳定触发多个工具调用。7.3 兜底渲染器useDefaultRenderTool 与 CustomCatchallRendererQA 文档虽未直接涉及兜底渲染但它与tool-rendering变体「每个有趣工具都有专属卡片」的设计是一体的。未被useRenderTool认领的工具调用会落入useDefaultRenderTool注册的 CustomCatchallRenderer见 page.tsx它以通用卡片展示工具名、状态徽章streaming / running / done、美化打印的参数与 JSON 结果。这套「每工具专属渲染 通配兜底」的组合保证了任何工具调用都不会以裸 JSON 泄露给用户这也是该演示区别于默认 JSON 渲染的核心价值。7.4 E2E 自动化把 QA 用例固化为 Playwright 测试QA 文档的手工检查项在 tool-rendering.spec.ts 中被自动化文件头注释明确标注了与 QA 文档的对应关系// QA reference: qa/tool-rendering.md。六个测试用例覆盖页面加载与建议按钮断言Type a message占位符与 5 个建议按钮可见天气卡片点击Weather in SF建议断言weather-card、weather-city含San Francisco、weather-humidity55%、weather-wind10——数值与get_weather的固定返回完全一致实现确定性的数据断言航班卡片断言flights-card的出发/到达地SFO/JFK与至少 2 条航班行股票卡片断言 AAPL 的确定价格与涨跌幅由get_stock_price的可选参数注入确定性值d20 多次调用断言恰好渲染 5 张d20-card且最后一张值为 20前 4 张非 20直接验证「多次工具调用各自挂载独立卡片」链式调用断言同一轮内 weather flights d20 三种卡片同时出现。这套测试以data-testid为稳定锚点配合 aimock 确定性夹具位于showcase/aimock目录锁定工具调用序列使得 QA 文档中的每一项功能检查都能在 CI 中自动回归。手工 QA 与自动化测试互为印证手工版关注视觉细节主题色、图标、布局自动化版关注结构契约testid、字段值、数量。八、结语如何把本文落地为可执行的 QA 流程综合 QA 文档与源码完整的 tool-rendering 验证流程可以沉淀为三步环境确认页面可访问 /api/health健康检查通过对应第二节前置条件逐项执行按第三节基础功能、第四节功能专项建议按钮 → 天气卡片 → 多次查询、第五节错误处理的 checklist 顺序执行以data-testid定位元素对照第六节指标记录耗时差异与回归将手工 QA 与tool-rendering.spec.ts自动化结果并排对照——若 QA 清单与当前源码存在出入如加载文案、温度单位、主题背景色应如实标注「部署版本实际行为」并推动更新 QA 文档或实现保持两者同步。该 QA 方法论同样适用于同目录下的tool-rendering-custom-catchall、tool-rendering-default-catchall、tool-rendering-reasoning-chain三个变体它们共享同一后端工具面只需将验证重点从「WeatherCard 专属渲染」切换到「兜底渲染器形态」与「工具链推理链」即可相关 setup 细节可进一步参考 frontend-tools-setup.mdx 与 manifest.yaml 中的演示元数据。【免费下载链接】CopilotKitThe Frontend Stack for Agents Generative UI. React, Angular, Mobile, Slack, and more. Makers of the AG-UI Protocol项目地址: https://gitcode.com/GitHub_Trending/co/CopilotKit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CopilotKit × Google ADK 集成：Tool Rendering 功能 QA 验证指南与 useRenderTool 源码剖析
CopilotKit × Google ADK 集成Tool Rendering 功能 QA 验证指南与 useRenderTool 源码剖析【免费下载链接】CopilotKitThe Frontend Stack for Agents Generative UI. React, Angular, Mobile, Slack, and more. Makers of the AG-UI Protocol项目地址: https://gitcode.com/GitHub_Trending/co/CopilotKit本指南以showcase/integrations/google-adk/qa/tool-rendering.md为骨架结合该演示场景的前后端源码与端到端测试系统讲解「如何验证 Google ADK Agent 的工具调用在 CopilotKit 聊天界面中被渲染为 React 组件卡片」。读完本文你将掌握 tool-rendering 演示的完整验收流程含前置条件、建议按钮、天气卡片、错误处理与预期指标并能对照源码理解useRenderTool/useDefaultRenderTool的渲染原理与测试自动化方案。一、场景定位QA 文档覆盖的 tool-rendering 演示在 CopilotKit 的 Google ADK 集成示例中tool-rendering演示展示的核心能力是后端 Agent 的工具调用tool call不再以晦涩的 JSON 文本形式出现在聊天记录里而是被前端渲染成品牌化的 React 组件卡片例如天气卡片、航班列表卡片、股票卡片与骰子卡片。从 演示页面源码 顶部注释可以看到这是「三阶段递进」系列中最完整的一个变体get_weather→WeatherCard /专用渲染器search_flights→FlightListCard /专用渲染器get_stock_price→StockCard /专用渲染器roll_d20→D20Card /专用渲染器其余任何工具 →CustomCatchallRenderer /通配兜底同一目录下还并存tool-rendering-custom-catchall、tool-rendering-default-catchall、tool-rendering-reasoning-chain三个变体它们的后端工具面完全相同见 tool_rendering_common.py 注释差异仅在前端接线方式。QA 文档qa/tool-rendering.md正是针对「基本变体」的验收脚本本文将其逐条展开并下沉到源码层解释「为什么这样验证」。二、前置条件PrerequisitesQA 文档要求验证前满足两个硬性前提Demo 已部署且可访问tool-rendering 演示需要完整的前后端栈Next.js 前端 Google ADK Python Agent 服务都已拉起并对外暴露页面路由Agent 后端健康通过GET /api/health确认后端服务正常。在源码中健康检查路由由 health 路由 提供而 Agent 服务则由 agent_server.py 启动并托管所有注册的 Agent包括ToolRenderingAgent。建议在实际执行 QA 前先执行curl demo-host/api/health确认返回正常后再进入功能验证避免把「后端未就绪」误判为前端渲染缺陷。三、基础功能验证Basic FunctionalityQA 文档将第一层验收定义为「页面能加载、聊天能用」共 4 个检查点导航到 tool-rendering 演示页面验证聊天界面以居中全高布局加载验证聊天输入框占位符Type a message可见发送一条基础消息验证 Agent 能正常回复「居中全高布局」在源码中有明确对应page.tsx 中ToolRenderingDemo将根容器设置为flex justify-center items-center h-screen w-full内部再由max-w-4xl约束聊天宽度这正是 QA 期望的「垂直水平居中、占满视口高度」的布局结构。占位符Type a message由CopilotChat组件CopilotChat agentIdtool-rendering classNameh-full rounded-2xl /默认提供端到端测试也以该占位符作为页面加载完成的信号见下文第七节。四、功能专项检查Feature-Specific Checks4.1 建议按钮SuggestionsQA 文档列出三个必须可见的天气建议按钮Weather in San Francisco建议按钮可见Weather in New York建议按钮可见Weather in Tokyo建议按钮可见点击天气建议后验证其内容填充输入框或直接发送消息需要说明的是建议按钮清单在不同迭代中可能演进。当前仓库源码 suggestions.ts 通过useConfigureSuggestions注册了 5 个建议Weather in SF、Find flights、Stock price、Roll a d20、Chain toolsavailable: always表示建议始终展示。对应的 e2e 测试 tool-rendering.spec.ts 也断言了这 5 个data-testidcopilot-suggestion建议按钮。因此 QA 执行时应以部署版本实际配置的建议列表为准——如果按 QA 文档逐一核对三个城市按钮而当前部署版本未配置应视为「配置差异」而非渲染缺陷。建议按钮的交互语义由 CopilotKit 运行时保证点击建议会将其message字段填入输入框或直接触发发送Weather in SF对应的实际消息是Whats the weather in San Francisco?。4.2 天气卡片渲染useRenderTool这是整个 QA 文档的核心检查项围绕「输入城市 → 调用get_weather工具 → 前端渲染 WeatherCard」的完整链路输入Whats the weather in San Francisco?验证加载状态显示Retrieving weather...并带 spinner验证WeatherCard渲染data-testidweather-card且包含城市名data-testidweather-city摄氏与华氏两种温度湿度百分比data-testidweather-humidity风速mphdata-testidweather-wind体感温度data-testidweather-feels-like天气描述文本与对应天气图标sun/rain/cloud验证卡片背景色与天气条件主题一致天气条件期望主题色晴朗Clear/Sunny#667eea蓝紫降雨/雷暴Rain/Storm#4A5568深灰多云Cloudy#718096中灰降雪Snow#63B3ED浅蓝QA 清单与当前源码的差异核对执行验证时务必对照部署版本确认加载文案QA 清单期望Retrieving weather...而当前 weather-card.tsx 在loading为 true 时渲染的是Fetching weather...温度单位QA 清单期望「摄氏度 华氏度」双单位展示当前源码仅渲染华氏度{temperature}°F见 weather-card.tsx且没有weather-feels-like的 testid 挂载点体感温度由后端返回feels_like字段但当前卡片未消费它背景主题色QA 清单期望按天气条件切换四种背景色当前源码的卡片背景是固定浅色#EDEDF5见 weather-card.tsx天气差异体现在**图标emoji**而非背景色上——conditionsEmoji函数将sun/clear → ☀️、rain/storm → ️、cloud → ☁️、snow → ❄️见 weather-card.tsx。出现这类差异时QA 结论应写为「以部署版本实际行为为准」并可将差异作为待办反馈给维护者确认是功能迭代还是回归。4.3 多次天气查询Multiple Weather Queries询问第二个城市的天气验证第二个WeatherCard正常渲染且不影响第一个卡片验证每张卡片显示各自正确的城市名该检查点验证的是useRenderTool的多实例渲染能力每一次工具调用都会独立挂载一张卡片卡片之间互不覆盖。源码中useRenderTool的 render 回调直接返回WeatherCard loading{loading} location{...} ... /见 page.tsx渲染器是无状态的纯函数组件天然支持每个调用各自产生独立卡片。roll_d20的渲染器注释也明确写道「Each tool call mounts its own card so e2e tests can count them」page.tsx说明这正是设计意图。五、错误处理验证Error Handling发送空消息应被优雅处理不报错、不产生异常界面正常使用过程中控制台无报错空消息的拦截发生在聊天输入层CopilotChat组件对空输入不会发起请求因此验证点应关注「点击发送按钮或回车时页面行为是否稳定」。控制台检查建议在整个验证流程中持续开启 DevTools Console重点关注前端渲染异常React 告警、运行时fetch失败可配合 Network 面板交叉确认是否后端超时、以及useRenderTool渲染回调抛出异常导致的卡片崩溃。六、预期结果汇总Expected ResultsQA 文档给出了 5 条量化验收指标执行时逐条打勾指标阈值聊天界面加载3 秒内Agent 首次响应10 秒内天气卡片渲染所有数据字段齐全天气图标与主题色与天气条件匹配UI 质量无错误、无布局破损这些时间阈值直接对应 e2e 测试中的超时配置页面加载断言使用SUGGESTION_TIMEOUT 1500015 秒比 3 秒阈值宽松以容纳 CI 冷启动工具卡片断言使用TOOL_TIMEOUT 6000060 秒覆盖 Agent 后端工具调用耗时见 tool-rendering.spec.ts。人工 QA 采用更严格的 3s/10s 指标自动化测试则用更宽松的超时换取稳定性两者互补。七、源码级剖析从 QA 用例反推实现原理QA 文档的验收点并非凭空而来每一处都与实现细节一一对应。以下按「前端 → 后端 → 兜底 → 自动化」四条链路拆解。7.1 前端useRenderTool 注册「工具名 → 卡片」映射useRenderTool接受一个配置对象核心字段为name要拦截的工具名、parameterszod schema声明参数结构和render回调返回 React 节点。render 回调接收{ parameters, result, status }其中status用于区分工具调用的执行阶段。以天气为例page.tsxuseRenderTool( { name: get_weather, parameters: z.object({ location: z.string() }), render: ({ parameters, result, status }) { const loading status ! complete; const parsed parseJsonResultWeatherResult(result); return ( WeatherCard loading{loading} location{parameters?.location ?? parsed.city ?? } temperature{parsed.temperature} humidity{parsed.humidity} windSpeed{parsed.wind_speed} conditions{parsed.conditions} / ); }, }, [], );要点解读status ! complete即加载态工具调用在途时status为inProgress/executing此时 WeatherCard 只渲染城市名与「Fetching weather...」占位不渲染数据字段——这正是 QA 文档「验证加载状态」一节的实现基础parameters?.location ?? parsed.city优先取前端声明的参数值结果回包中的city作为兜底保证城市名即使参数丢失也能正确显示parseJsonResultresult在管道中可能是字符串parse-json-result.ts 负责将其安全解析为结构化对象。同类渲染器还包括search_flights → FlightListCard、get_stock_price → StockCard、roll_d20 → D20Card全部集中在 page.tsx 中与 QA 文档「Feature-Specific Checks」的验证对象一一对应。7.2 后端Google ADK Agent 与工具定义QA 文档要求验证的「Agent 能响应」「天气数据字段齐全」其数据源头在 tool_rendering_agent.pytool_rendering_agent LlmAgent( nameToolRenderingAgent, modelget_model(), instructionTOOL_RENDERING_INSTRUCTION, tools[get_weather, search_flights, get_stock_price, roll_d20], after_model_callbackstop_on_terminal_text, )get_weather等四个工具在 tool_rendering_common.py 中定义签名与返回字段直接决定了前端 WeatherCard 能渲染什么def get_weather(tool_context: ToolContext, location: str) - dict: Get the current weather for a given location. return { city: location, temperature: 68, humidity: 55, wind_speed: 10, conditions: Sunny, }返回的city / temperature / humidity / wind_speed / conditions与前端WeatherResult接口page.tsx字段完全对齐这就是 QA 文档要求核对「城市名、湿度、风速、天气描述」的原因。search_flights、get_stock_price、roll_d20同样遵循「返回结构化 dict → 前端按字段渲染」的模式。系统提示词TOOL_RENDERING_INSTRUCTION还约定了 Agent 行为如「航班只给目的地时默认出发地 SFO」「一轮可调用多个工具」这解释了 QA 文档中「Chain tools」与多次查询场景为何能稳定触发多个工具调用。7.3 兜底渲染器useDefaultRenderTool 与 CustomCatchallRendererQA 文档虽未直接涉及兜底渲染但它与tool-rendering变体「每个有趣工具都有专属卡片」的设计是一体的。未被useRenderTool认领的工具调用会落入useDefaultRenderTool注册的 CustomCatchallRenderer见 page.tsx它以通用卡片展示工具名、状态徽章streaming / running / done、美化打印的参数与 JSON 结果。这套「每工具专属渲染 通配兜底」的组合保证了任何工具调用都不会以裸 JSON 泄露给用户这也是该演示区别于默认 JSON 渲染的核心价值。7.4 E2E 自动化把 QA 用例固化为 Playwright 测试QA 文档的手工检查项在 tool-rendering.spec.ts 中被自动化文件头注释明确标注了与 QA 文档的对应关系// QA reference: qa/tool-rendering.md。六个测试用例覆盖页面加载与建议按钮断言Type a message占位符与 5 个建议按钮可见天气卡片点击Weather in SF建议断言weather-card、weather-city含San Francisco、weather-humidity55%、weather-wind10——数值与get_weather的固定返回完全一致实现确定性的数据断言航班卡片断言flights-card的出发/到达地SFO/JFK与至少 2 条航班行股票卡片断言 AAPL 的确定价格与涨跌幅由get_stock_price的可选参数注入确定性值d20 多次调用断言恰好渲染 5 张d20-card且最后一张值为 20前 4 张非 20直接验证「多次工具调用各自挂载独立卡片」链式调用断言同一轮内 weather flights d20 三种卡片同时出现。这套测试以data-testid为稳定锚点配合 aimock 确定性夹具位于showcase/aimock目录锁定工具调用序列使得 QA 文档中的每一项功能检查都能在 CI 中自动回归。手工 QA 与自动化测试互为印证手工版关注视觉细节主题色、图标、布局自动化版关注结构契约testid、字段值、数量。八、结语如何把本文落地为可执行的 QA 流程综合 QA 文档与源码完整的 tool-rendering 验证流程可以沉淀为三步环境确认页面可访问 /api/health健康检查通过对应第二节前置条件逐项执行按第三节基础功能、第四节功能专项建议按钮 → 天气卡片 → 多次查询、第五节错误处理的 checklist 顺序执行以data-testid定位元素对照第六节指标记录耗时差异与回归将手工 QA 与tool-rendering.spec.ts自动化结果并排对照——若 QA 清单与当前源码存在出入如加载文案、温度单位、主题背景色应如实标注「部署版本实际行为」并推动更新 QA 文档或实现保持两者同步。该 QA 方法论同样适用于同目录下的tool-rendering-custom-catchall、tool-rendering-default-catchall、tool-rendering-reasoning-chain三个变体它们共享同一后端工具面只需将验证重点从「WeatherCard 专属渲染」切换到「兜底渲染器形态」与「工具链推理链」即可相关 setup 细节可进一步参考 frontend-tools-setup.mdx 与 manifest.yaml 中的演示元数据。【免费下载链接】CopilotKitThe Frontend Stack for Agents Generative UI. React, Angular, Mobile, Slack, and more. Makers of the AG-UI Protocol项目地址: https://gitcode.com/GitHub_Trending/co/CopilotKit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考