尧图网页设计 
CopilotKit 推理链路实战在 CrewAI Crews 集成中构建、定制与 QA 验证 Agent 的 Agentic Reasoning 展示【免费下载链接】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/crewai-crews/qa/agentic-chat-reasoning.md这份 QA 清单为骨架完整拆解 CopilotKit 与 CrewAICrews集成中Agentic Chat Reasoning推理能力的端到端实现从前端如何挂载reasoningMessage槽位渲染推理卡片、Agent 后端如何通过 CrewAI Flow 桥接 OpenAI Responses API 的推理流再到 Playwright 测试如何把推理展示固化进 QA 流程。读完本文你将掌握 CopilotKit v2 中推理消息Reasoning Message这一一等公民消息类型的完整调用链、默认与自定义两种渲染方案的取舍以及写出一条可复现的 agentic-chat-reasoning 验收路径。一、QA 文档定位这份清单在验证什么仓库中的showcase/integrations/crewai-crews/qa/agentic-chat-reasoning.md是一份面向CrewAI Crews 集成中的 Agentic ChatReasoning演示的功能验收清单共五个勾选项进入/demos/agentic-chat-reasoning演示页面发送一个复杂提示例如带我走一遍你下个月如何规划一个三城之旅验证自定义ReasoningBlock卡片data-testidreasoning-block出现在最终答案之上并带有 Reasoning 徽标验证流式输出时标签显示 Thinking...验证最终助手文本出现在推理内容之后。这份清单看起来只有短短五步但它点出了三条贯穿前后端的主线前端存在一个自定义ReasoningBlock组件通过data-testidreasoning-block暴露给 E2E 测试运行时推理内容必须先于最终答案到达并渲染且流式过程要有Thinking... 状态后端存在一条能把复杂问题 → 推理流 → 最终答案完整串起来的 Agent 链路。下面逐一深入这条链路在仓库中的真实实现。二、前端落地ReasoningBlock自定义槽位渲染器2.1 推理消息是 CopilotKit v2 中的一等公民在 CopilotKit 前端 v2 架构中消息列表会按message.role reasoning对消息做判别并将这类消息交给messageView.reasoningMessage槽位渲染其默认组件是CopilotChatReasoningMessageThinking… / Thought for X 头部 可展开内容区。这一设计在 reasoning-custom/page.tsx 的头部注释中明确指出并指向源码 CopilotChatMessageView.tsx 作为判别与分发的实现位置。QA 文档所验证的ReasoningBlock正是通过槽位覆盖slot override替换默认渲染器的产物其实现位于 reasoning-block.tsxexport function ReasoningBlock({ message, messages, isRunning, }: { message: ReasoningMessage; messages?: Message[]; isRunning?: boolean; }) { const isLatest messages?.[messages.length - 1]?.id message.id; const isStreaming !!(isRunning isLatest); const hasContent !!(message.content message.content.length 0); return ( div >const AGENT_ID reasoning-custom; export default function ReasoningCustomDemo() { return ( CopilotKit runtimeUrl/api/copilotkit agent{AGENT_ID} div classNameflex justify-center items-center h-screen w-full div classNameh-full w-full max-w-4xl Chat / /div /div /CopilotKit ); } function Chat() { useReasoningCustomSuggestions(); return ( CopilotChat agentId{AGENT_ID} classNameh-full rounded-2xl messageView{{ reasoningMessage: ReasoningBlock as unknown as typeof CopilotChatReasoningMessage, }} / ); }要点拆解CopilotKit runtimeUrl/api/copilotkit agent{AGENT_ID}前端通过/api/copilotkit运行时与 Agent 后端建立 AG-UI 连接agent指定要路由的 Agent 名messageView.reasoningMessage是公开且稳定的定制入口类型上要求与CopilotChatReasoningMessage兼容因此代码里做了一次显式类型断言该组件接收ReasoningMessage来自ag-ui/core并可选接收完整消息列表与运行状态——messages用于判断当前推理消息是否是最新一条isRunning用于流式状态判定。2.3 对照组默认渲染器与零配置路径为了让用户直观对比默认 vs 自定义仓库在 reasoning-default/page.tsx 提供了完全相同的后端与运行时 URL、但不做任何槽位覆盖的对照组const AGENT_ID reasoning-default; export default function ReasoningDefaultDemo() { return ( CopilotKit runtimeUrl/api/copilotkit agent{AGENT_ID} div classNameflex justify-center items-center h-screen w-full div classNameh-full w-full max-w-4xl Chat / /div /div /CopilotKit ); } function Chat() { useReasoningDefaultSuggestions(); return CopilotChat agentId{AGENT_ID} classNameh-full rounded-2xl /; }两个演示共享同一个reasoning_agent后端 Flow/reasoning端点与同一个/api/copilotkit运行时唯一区别就是是否覆盖messageView.reasoningMessage槽位。这意味着默认路径是零配置体验只要后端按 AG-UI 协议发出推理生命周期事件前端开箱即可渲染自定义路径则完全接管推理卡片的视觉与交互适合需要把思考过程做成品牌化 UI 的场景。2.4 提示词设计为什么必须给具体问题仓库在 reasoning-custom/suggestions.ts 里埋了一个非常关键的工程坑OpenAI 推理模型如 gpt-5.4只有在面对具体问题需要多步思考时才会发出response.reasoning_summary_text.delta事件。如果用户发的是请逐步展示你的推理这类元提示模型会将其识别为要求暴露思维链chain-of-thought而拒绝结果是一条普通文本回复、推理槽位永远不点亮。因此演示建议语被设计成一个真正需要多步推理的具体问题Explain step by step why the sky appears blue during the day but red at sunset.这也解释了 QA 文档为何特意给出Walk me through how youd plan a 3-city trip next month这类复杂提示——没有具体问题就没有推理流QA 的第 3、4 步就无从验证。三、后端链路CrewAI Flow 如何产出推理流3.1 路由注册agentic-chat-reasoning映射到/reasoning在 route.ts 中推理类 Agent 名称被集中注册并统一指向/reasoning后端端点const reasoningAgentNames [ reasoning-default, reasoning-custom, reasoning-default-render, agentic-chat-reasoning, ]; // ... for (const name of reasoningAgentNames) { agents[name] createAgent(/reasoning); }createAgent基于ag-ui/client的HttpAgent构造把请求代理到独立的 Agent 进程默认http://localhost:8000可用AGENT_URL环境变量覆盖。也就是说QA 文档第 1 步访问的/demos/agentic-chat-reasoning页面其前端agent名对应的是后端/reasoning端点。3.2 Flow 实现把 Responses 推理流翻译为 AG-UI 生命周期核心实现位于 reasoning_flow.py。ReasoningFlow是一个原生 CrewAI FlowFlow[CopilotKitState]它自身不发射任何协议事件而是依赖 CrewAI 桥接层ag_ui_crewai把 OpenAI Responses API 的推理摘要与答案流翻译成 AG-UI 的 reasoning / text 生命周期start() async def chat(self) - None: captured ResponsesReasoningCapture( await copilotkit_responses( modelfopenai/{REASONING_MODEL}, messages[ {role: system, content: SYSTEM_PROMPT}, *[ message for message in self.state.messages if not ( isinstance(message, dict) and message.get(role) reasoning ) ], ], reasoning{effort: medium, summary: detailed}, ) ) response await copilotkit_stream(captured) reasoning .join(captured.reasoning_parts) if reasoning: self.state.messages.append( {id: str(uuid.uuid4()), role: reasoning, content: reasoning} ) self.state.messages.append(response.choices[0].message)链路要点模型选择默认模型来自OPENAI_REASONING_MODEL环境变量回退值为gpt-5.4以openai/前缀传给 LiteLLM 风格的copilotkit_responses历史消息过滤把 state 中角色为reasoning的旧消息剔除后再发给模型避免把历史推理内容回灌给模型推理配置reasoning{effort: medium, summary: detailed}请求模型产出详细推理摘要结果落盘把捕获到的推理文本拼成一个{role: reasoning, content: ...}的消息追加进状态再追加最终的response.choices[0].message——这就是前端能收到推理消息 → 答案消息顺序的根本保证系统提示约束SYSTEM_PROMPT明确要求使用私有推理、只暴露安全的高层思路、绝不泄露隐藏思维链这与前端 suggestions 中的提示词设计互相呼应。3.3 推理捕获器为什么流不能被打散responses_reasoning.py 里的ResponsesReasoningCapture是这条链路的粘合剂。它是一个透明的异步迭代器在透传每个流式事件的同时把两类推理增量事件记录下来_REASONING_DELTA_TYPES { response.reasoning_summary_text.delta, response.reasoning_text.delta, } class ResponsesReasoningCapture: def __init__(self, source: Any): self._iterator source.__aiter__() self._process_chunk source._process_chunk self.reasoning_parts: list[str] [] # ...注释揭示了一个关键的兼容性细节ag-ui-crewai通过是否具备私有_process_chunk能力来识别 LiteLLM 的 Responses 流。ResponsesReasoningCapture镜像这一能力让流保持在 SDK 的 Responses 解码器上而不是被误判成普通 chat 流。同时它把推理增量文本累积到reasoning_parts供 Flow 后续拼装成一条完整的reasoning消息。3.4 服务装配Flow 端点如何挂到 FastAPI 上Agent 进程把ReasoningFlow挂到/reasoning端点相关装配见 agent_server.pyfrom agents.reasoning_flow import reasoning_flow # noqa: E402 # ... add_crewai_flow_fastapi_endpoint(app, reasoning_flow, /reasoning)这样完整调用链为浏览器 /demos/agentic-chat-reasoning → Next.js /api/copilotkitCopilotRuntime, single-route 模式 → AG-UI HttpAgent → http://localhost:8000/reasoning → ReasoningFlowCrewAI Flow→ copilotkit_responsesgpt-5.4 → ResponsesReasoningCapture 捕获推理增量 → 推理消息 答案消息写回 state → AG-UI 生命周期回流前端 → messageView.reasoningMessage 槽位 → ReasoningBlock 渲染四、QA 验证把推理展示固化为 E2E 断言4.1 Playwright 测试钩子仓库在 agentic-chat-reasoning.spec.ts 中为这个演示建立了 Playwright 冒烟测试先导航到/demos/agentic-chat-reasoning并断言聊天输入框可见import { test, expect } from playwright/test; test.describe(Agentic Chat (Reasoning), () { test.beforeEach(async ({ page }) { await page.goto(/demos/agentic-chat-reasoning); }); test(chat input is visible, async ({ page }) { await expect(page.getByPlaceholder(Type a message)).toBeVisible(); }); });这验证了页面可正常加载、聊天输入可用。而 QA 清单第 35 步的完整验收reasoning-block出现于答案之前、流式中显示 Thinking...、答案在推理之后需要结合data-testidreasoning-block这一稳定测试钩子来做断言——这正是ReasoningBlock组件特意打上该 testid 的原因。仓库中还有配套的 reasoning-custom.spec.ts 与 tool-rendering-reasoning-chain.spec.ts共同覆盖推理展示的多个变体。4.2 与 QA 清单的逐条对应QA 清单步骤仓库依据说明1. 访问/demos/agentic-chat-reasoningagentic-chat-reasoning.spec.tsPlaywright 直接 goto 该路由2. 发送复杂提示三城之旅reasoning-custom/suggestions.ts 的注释推理模型只对具体问题产出推理摘要3.reasoning-block卡片 Reasoning 徽标reasoning-block.tsxdata-testid与徽标均为显式 DOM 元素4. 流式时显示 Thinking...reasoning-block.tsxisStreaming isRunning isLatest5. 最终答案出现在推理之后reasoning_flow.py先 append 推理消息再 append 答案消息五、运行与验证指引5.1 前置条件后端 Agent 进程CrewAI Flow FastAPI默认监听localhost:8000需要OPENAI_API_KEY并通过OPENAI_REASONING_MODEL默认gpt-5.4指定推理模型前端 Next.js 应用通过/api/copilotkit运行时把请求代理到 Agent 进程AGENT_URL环境变量可覆盖后端地址默认http://localhost:8000页面加载前可通过/api/copilotkit的 GET 健康探针查看agent_status与环境变量是否就绪该探针实现见 route.ts。5.2 验收执行路径启动后端 Agent 进程与前端应用确认健康探针返回agent_status: reachable打开/demos/agentic-chat-reasoning发送一个具体、需要多步推理的复杂问题如三城旅行规划或解释为什么白天天空是蓝色而日落是红色观察顺序推理卡片含 Reasoning 徽标先行出现 → 流式过程中标签为 Thinking... → 推理正文填充 → 最终答案出现在推理之后运行npx playwright test或 CI 中对应的 e2e 任务验证 agentic-chat-reasoning.spec.ts 等用例通过。5.3 常见问题排查推理卡片从不出现先确认提示词是具体问题而非展示你的推理元提示再确认后端模型确实支持并配置了reasoning参数reasoning{effort: medium, summary: detailed}推理与答案顺序颠倒或丢失检查是否误把reasoning角色的历史消息回灌给模型正确做法是先过滤见 reasoning_flow.py默认渲染器不显示确认走的是reasoning-default这类零覆盖路径且后端确实经由/reasoning端点而不是回落到了普通 chat 端点。六、延伸阅读推理默认渲染器与自定义渲染器的对比入口reasoning-default/page.tsx 与 reasoning-custom/page.tsx推理槽位在消息视图中的判别与分发源码CopilotChatMessageView.tsx推理消息的 AG-UI 类型定义可追溯ag-ui/core中的ReasoningMessage与Message类型同一集成中还提供推理 工具渲染链路示例 tool-rendering-reasoning-chain适合进一步理解推理消息与工具调用卡片在同一个消息流中的共存方式。【免费下载链接】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 推理链路实战：在 CrewAI Crews 集成中构建、定制与 QA 验证 Agent 的 Agentic Reasoning 展示
CopilotKit 推理链路实战在 CrewAI Crews 集成中构建、定制与 QA 验证 Agent 的 Agentic Reasoning 展示【免费下载链接】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/crewai-crews/qa/agentic-chat-reasoning.md这份 QA 清单为骨架完整拆解 CopilotKit 与 CrewAICrews集成中Agentic Chat Reasoning推理能力的端到端实现从前端如何挂载reasoningMessage槽位渲染推理卡片、Agent 后端如何通过 CrewAI Flow 桥接 OpenAI Responses API 的推理流再到 Playwright 测试如何把推理展示固化进 QA 流程。读完本文你将掌握 CopilotKit v2 中推理消息Reasoning Message这一一等公民消息类型的完整调用链、默认与自定义两种渲染方案的取舍以及写出一条可复现的 agentic-chat-reasoning 验收路径。一、QA 文档定位这份清单在验证什么仓库中的showcase/integrations/crewai-crews/qa/agentic-chat-reasoning.md是一份面向CrewAI Crews 集成中的 Agentic ChatReasoning演示的功能验收清单共五个勾选项进入/demos/agentic-chat-reasoning演示页面发送一个复杂提示例如带我走一遍你下个月如何规划一个三城之旅验证自定义ReasoningBlock卡片data-testidreasoning-block出现在最终答案之上并带有 Reasoning 徽标验证流式输出时标签显示 Thinking...验证最终助手文本出现在推理内容之后。这份清单看起来只有短短五步但它点出了三条贯穿前后端的主线前端存在一个自定义ReasoningBlock组件通过data-testidreasoning-block暴露给 E2E 测试运行时推理内容必须先于最终答案到达并渲染且流式过程要有Thinking... 状态后端存在一条能把复杂问题 → 推理流 → 最终答案完整串起来的 Agent 链路。下面逐一深入这条链路在仓库中的真实实现。二、前端落地ReasoningBlock自定义槽位渲染器2.1 推理消息是 CopilotKit v2 中的一等公民在 CopilotKit 前端 v2 架构中消息列表会按message.role reasoning对消息做判别并将这类消息交给messageView.reasoningMessage槽位渲染其默认组件是CopilotChatReasoningMessageThinking… / Thought for X 头部 可展开内容区。这一设计在 reasoning-custom/page.tsx 的头部注释中明确指出并指向源码 CopilotChatMessageView.tsx 作为判别与分发的实现位置。QA 文档所验证的ReasoningBlock正是通过槽位覆盖slot override替换默认渲染器的产物其实现位于 reasoning-block.tsxexport function ReasoningBlock({ message, messages, isRunning, }: { message: ReasoningMessage; messages?: Message[]; isRunning?: boolean; }) { const isLatest messages?.[messages.length - 1]?.id message.id; const isStreaming !!(isRunning isLatest); const hasContent !!(message.content message.content.length 0); return ( div >const AGENT_ID reasoning-custom; export default function ReasoningCustomDemo() { return ( CopilotKit runtimeUrl/api/copilotkit agent{AGENT_ID} div classNameflex justify-center items-center h-screen w-full div classNameh-full w-full max-w-4xl Chat / /div /div /CopilotKit ); } function Chat() { useReasoningCustomSuggestions(); return ( CopilotChat agentId{AGENT_ID} classNameh-full rounded-2xl messageView{{ reasoningMessage: ReasoningBlock as unknown as typeof CopilotChatReasoningMessage, }} / ); }要点拆解CopilotKit runtimeUrl/api/copilotkit agent{AGENT_ID}前端通过/api/copilotkit运行时与 Agent 后端建立 AG-UI 连接agent指定要路由的 Agent 名messageView.reasoningMessage是公开且稳定的定制入口类型上要求与CopilotChatReasoningMessage兼容因此代码里做了一次显式类型断言该组件接收ReasoningMessage来自ag-ui/core并可选接收完整消息列表与运行状态——messages用于判断当前推理消息是否是最新一条isRunning用于流式状态判定。2.3 对照组默认渲染器与零配置路径为了让用户直观对比默认 vs 自定义仓库在 reasoning-default/page.tsx 提供了完全相同的后端与运行时 URL、但不做任何槽位覆盖的对照组const AGENT_ID reasoning-default; export default function ReasoningDefaultDemo() { return ( CopilotKit runtimeUrl/api/copilotkit agent{AGENT_ID} div classNameflex justify-center items-center h-screen w-full div classNameh-full w-full max-w-4xl Chat / /div /div /CopilotKit ); } function Chat() { useReasoningDefaultSuggestions(); return CopilotChat agentId{AGENT_ID} classNameh-full rounded-2xl /; }两个演示共享同一个reasoning_agent后端 Flow/reasoning端点与同一个/api/copilotkit运行时唯一区别就是是否覆盖messageView.reasoningMessage槽位。这意味着默认路径是零配置体验只要后端按 AG-UI 协议发出推理生命周期事件前端开箱即可渲染自定义路径则完全接管推理卡片的视觉与交互适合需要把思考过程做成品牌化 UI 的场景。2.4 提示词设计为什么必须给具体问题仓库在 reasoning-custom/suggestions.ts 里埋了一个非常关键的工程坑OpenAI 推理模型如 gpt-5.4只有在面对具体问题需要多步思考时才会发出response.reasoning_summary_text.delta事件。如果用户发的是请逐步展示你的推理这类元提示模型会将其识别为要求暴露思维链chain-of-thought而拒绝结果是一条普通文本回复、推理槽位永远不点亮。因此演示建议语被设计成一个真正需要多步推理的具体问题Explain step by step why the sky appears blue during the day but red at sunset.这也解释了 QA 文档为何特意给出Walk me through how youd plan a 3-city trip next month这类复杂提示——没有具体问题就没有推理流QA 的第 3、4 步就无从验证。三、后端链路CrewAI Flow 如何产出推理流3.1 路由注册agentic-chat-reasoning映射到/reasoning在 route.ts 中推理类 Agent 名称被集中注册并统一指向/reasoning后端端点const reasoningAgentNames [ reasoning-default, reasoning-custom, reasoning-default-render, agentic-chat-reasoning, ]; // ... for (const name of reasoningAgentNames) { agents[name] createAgent(/reasoning); }createAgent基于ag-ui/client的HttpAgent构造把请求代理到独立的 Agent 进程默认http://localhost:8000可用AGENT_URL环境变量覆盖。也就是说QA 文档第 1 步访问的/demos/agentic-chat-reasoning页面其前端agent名对应的是后端/reasoning端点。3.2 Flow 实现把 Responses 推理流翻译为 AG-UI 生命周期核心实现位于 reasoning_flow.py。ReasoningFlow是一个原生 CrewAI FlowFlow[CopilotKitState]它自身不发射任何协议事件而是依赖 CrewAI 桥接层ag_ui_crewai把 OpenAI Responses API 的推理摘要与答案流翻译成 AG-UI 的 reasoning / text 生命周期start() async def chat(self) - None: captured ResponsesReasoningCapture( await copilotkit_responses( modelfopenai/{REASONING_MODEL}, messages[ {role: system, content: SYSTEM_PROMPT}, *[ message for message in self.state.messages if not ( isinstance(message, dict) and message.get(role) reasoning ) ], ], reasoning{effort: medium, summary: detailed}, ) ) response await copilotkit_stream(captured) reasoning .join(captured.reasoning_parts) if reasoning: self.state.messages.append( {id: str(uuid.uuid4()), role: reasoning, content: reasoning} ) self.state.messages.append(response.choices[0].message)链路要点模型选择默认模型来自OPENAI_REASONING_MODEL环境变量回退值为gpt-5.4以openai/前缀传给 LiteLLM 风格的copilotkit_responses历史消息过滤把 state 中角色为reasoning的旧消息剔除后再发给模型避免把历史推理内容回灌给模型推理配置reasoning{effort: medium, summary: detailed}请求模型产出详细推理摘要结果落盘把捕获到的推理文本拼成一个{role: reasoning, content: ...}的消息追加进状态再追加最终的response.choices[0].message——这就是前端能收到推理消息 → 答案消息顺序的根本保证系统提示约束SYSTEM_PROMPT明确要求使用私有推理、只暴露安全的高层思路、绝不泄露隐藏思维链这与前端 suggestions 中的提示词设计互相呼应。3.3 推理捕获器为什么流不能被打散responses_reasoning.py 里的ResponsesReasoningCapture是这条链路的粘合剂。它是一个透明的异步迭代器在透传每个流式事件的同时把两类推理增量事件记录下来_REASONING_DELTA_TYPES { response.reasoning_summary_text.delta, response.reasoning_text.delta, } class ResponsesReasoningCapture: def __init__(self, source: Any): self._iterator source.__aiter__() self._process_chunk source._process_chunk self.reasoning_parts: list[str] [] # ...注释揭示了一个关键的兼容性细节ag-ui-crewai通过是否具备私有_process_chunk能力来识别 LiteLLM 的 Responses 流。ResponsesReasoningCapture镜像这一能力让流保持在 SDK 的 Responses 解码器上而不是被误判成普通 chat 流。同时它把推理增量文本累积到reasoning_parts供 Flow 后续拼装成一条完整的reasoning消息。3.4 服务装配Flow 端点如何挂到 FastAPI 上Agent 进程把ReasoningFlow挂到/reasoning端点相关装配见 agent_server.pyfrom agents.reasoning_flow import reasoning_flow # noqa: E402 # ... add_crewai_flow_fastapi_endpoint(app, reasoning_flow, /reasoning)这样完整调用链为浏览器 /demos/agentic-chat-reasoning → Next.js /api/copilotkitCopilotRuntime, single-route 模式 → AG-UI HttpAgent → http://localhost:8000/reasoning → ReasoningFlowCrewAI Flow→ copilotkit_responsesgpt-5.4 → ResponsesReasoningCapture 捕获推理增量 → 推理消息 答案消息写回 state → AG-UI 生命周期回流前端 → messageView.reasoningMessage 槽位 → ReasoningBlock 渲染四、QA 验证把推理展示固化为 E2E 断言4.1 Playwright 测试钩子仓库在 agentic-chat-reasoning.spec.ts 中为这个演示建立了 Playwright 冒烟测试先导航到/demos/agentic-chat-reasoning并断言聊天输入框可见import { test, expect } from playwright/test; test.describe(Agentic Chat (Reasoning), () { test.beforeEach(async ({ page }) { await page.goto(/demos/agentic-chat-reasoning); }); test(chat input is visible, async ({ page }) { await expect(page.getByPlaceholder(Type a message)).toBeVisible(); }); });这验证了页面可正常加载、聊天输入可用。而 QA 清单第 35 步的完整验收reasoning-block出现于答案之前、流式中显示 Thinking...、答案在推理之后需要结合data-testidreasoning-block这一稳定测试钩子来做断言——这正是ReasoningBlock组件特意打上该 testid 的原因。仓库中还有配套的 reasoning-custom.spec.ts 与 tool-rendering-reasoning-chain.spec.ts共同覆盖推理展示的多个变体。4.2 与 QA 清单的逐条对应QA 清单步骤仓库依据说明1. 访问/demos/agentic-chat-reasoningagentic-chat-reasoning.spec.tsPlaywright 直接 goto 该路由2. 发送复杂提示三城之旅reasoning-custom/suggestions.ts 的注释推理模型只对具体问题产出推理摘要3.reasoning-block卡片 Reasoning 徽标reasoning-block.tsxdata-testid与徽标均为显式 DOM 元素4. 流式时显示 Thinking...reasoning-block.tsxisStreaming isRunning isLatest5. 最终答案出现在推理之后reasoning_flow.py先 append 推理消息再 append 答案消息五、运行与验证指引5.1 前置条件后端 Agent 进程CrewAI Flow FastAPI默认监听localhost:8000需要OPENAI_API_KEY并通过OPENAI_REASONING_MODEL默认gpt-5.4指定推理模型前端 Next.js 应用通过/api/copilotkit运行时把请求代理到 Agent 进程AGENT_URL环境变量可覆盖后端地址默认http://localhost:8000页面加载前可通过/api/copilotkit的 GET 健康探针查看agent_status与环境变量是否就绪该探针实现见 route.ts。5.2 验收执行路径启动后端 Agent 进程与前端应用确认健康探针返回agent_status: reachable打开/demos/agentic-chat-reasoning发送一个具体、需要多步推理的复杂问题如三城旅行规划或解释为什么白天天空是蓝色而日落是红色观察顺序推理卡片含 Reasoning 徽标先行出现 → 流式过程中标签为 Thinking... → 推理正文填充 → 最终答案出现在推理之后运行npx playwright test或 CI 中对应的 e2e 任务验证 agentic-chat-reasoning.spec.ts 等用例通过。5.3 常见问题排查推理卡片从不出现先确认提示词是具体问题而非展示你的推理元提示再确认后端模型确实支持并配置了reasoning参数reasoning{effort: medium, summary: detailed}推理与答案顺序颠倒或丢失检查是否误把reasoning角色的历史消息回灌给模型正确做法是先过滤见 reasoning_flow.py默认渲染器不显示确认走的是reasoning-default这类零覆盖路径且后端确实经由/reasoning端点而不是回落到了普通 chat 端点。六、延伸阅读推理默认渲染器与自定义渲染器的对比入口reasoning-default/page.tsx 与 reasoning-custom/page.tsx推理槽位在消息视图中的判别与分发源码CopilotChatMessageView.tsx推理消息的 AG-UI 类型定义可追溯ag-ui/core中的ReasoningMessage与Message类型同一集成中还提供推理 工具渲染链路示例 tool-rendering-reasoning-chain适合进一步理解推理消息与工具调用卡片在同一个消息流中的共存方式。【免费下载链接】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），仅供参考