企业官网建设流程全解析

CopilotKit Built-in Agent 与 LangGraph-Python 参考集成的 Parity 对账指南

【免费下载链接】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

本文基于 CopilotKit 仓库中 PARITY_NOTES.md 编写，系统梳理 Built-in Agent（BIA）showcase 集成在迁移到Option A（前端字节级对齐 LangGraph-Python 参考集成）后，与参考实现之间所有"有意的适配、分歧与待修复差距"。读完本文，你将理解 BIA 的命名 Agent 注册机制、D6 探针与 harness 的正确对账方式、已知隔离（quarantine）项及解除条件、aimock fixture 的作用域陷阱，以及一份面向真实 LLM 的后端审计修复清单——这些知识对参与该集成开发、编写 harness、维护 D6 探针或移植 demo 的工程师都有直接价值。

为什么需要 Parity Notes：审计者先读这份文件

built-in-agent（BIA）是 CopilotKit 的 showcase 集成，采用factory 模式：Agent 以BuiltInAgent进程内方式运行在 Next.js API 路由处理器中，不需要独立的 Agent 服务器进程。它的对账基准是LangGraph-Python（LGP）参考集成（showcase/integrations/langgraph-python）。

PARITY_NOTES 的存在意义在于：审计者、harness 作者和 D6 探针维护者在"标记缺失的对账项"之前，必须先查阅这份文件——因为 BIA 与 LGP 之间的差异大部分是有意为之（比如 import 分组、命名 Agent 约定），只有一小部分是真实的待修复缺陷。若不了解这些约定，很容易把"预期的 drift"误报为回归。

Option A：前端与 LGP 字节级一致

BIA 已迁移到Option A：每一个src/app/demos/*前端都是对应 LGP 参考 demo 的逐字复制（verbatim copy），后端则是一个命名 Agent 注册表（详见下一节）。无论 LGP 渲染什么，BIA 就渲染什么——不存在需要单独对账的 BIA 专属前端 fork。

唯一的系统性差异是lint 机制层面的、而非语义层面的：

• consistent-type-importsESLint 规范化。BIA 强制执行@typescript-eslint/consistent-type-imports规则（这是 PR 变绿的前提），因此类型专用导入被拆分成import type { … }分组。约有 15 个 demo 前端与 LGP 源码的差异仅在于这种 import 分组。拆分在语义上与 DOM 输出完全一致（类型导入在构建期即被擦除），对运行时行为的影响为零。其余 demo 前端是逐字节完全相同的副本。

因此，harness 与 D6 探针应该基于能力与渲染出的 DOM来对账 BIA 与 LGP，绝不要做源码文本级比较——import type分组是预期中且唯一被允许的 drift。

Agent-id 约定：命名 Agent 取代旧的default规则

旧约定（"每个 demo 都指向字面量default"）已被取代、不再成立。不要再依赖它。

现在每个 demo 指向的命名 Agent等于其前端agent="<id>"的值。这些名字注册在共享单路由注册表 src/app/api/copilotkit/route.ts 中；需要隔离运行时（a2ui、byoc/declarative、mcp、ogui、reasoning、auth、voice、multimodal、agent-config、beautiful-chat）的 demo 则注册在专用的src/app/api/copilotkit-*路由中。

从源码看，共享路由中的注册表结构是：

const runtime = new CopilotRuntime({ agents: { // 迁移期间保留的 catch-all Agent；没有任何 demo 再指向它 default: createBuiltInAgent(), agentic_chat: createAgenticChatAgent(), "chat-customization-css": createBuiltInAgent(), "gen-ui-agent": createBuiltInAgent({ systemPrompt: GEN_UI_AGENT_PROMPT }), "gen-ui-tool-based": createBuiltInAgent({ systemPrompt: GEN_UI_TOOL_BASED_PROMPT }), subagents: createBuiltInAgent({ systemPrompt: SUBAGENTS_PROMPT }), // 推理类 demo 走专门的 reasoning 适配器工厂 "reasoning-custom": createAgenticChatReasoningAgent(), "reasoning-default": createReasoningDefaultRenderAgent(), "tool-rendering-reasoning-chain": createToolRenderingReasoningChainAgent(), // ...其余 ~20 个命名 Agent 共享 createBuiltInAgent() }, runner: new InMemoryAgentRunner(), });

Agent-id 与前端映射的典型例子（前端字面量 → 注册 Agent）：

• 遗留下划线 id（保留自字节级一致的 LGP 前端）：agentic_chat、frontend_tools、human_in_the_loop。
• 连字符 id（等于 demo slug）：hitl-in-chat、hitl-in-app、shared-state-read、shared-state-read-write、subagents、gen-ui-agent、threadid-frontend-tool-roundtrip、reasoning-custom、reasoning-default、tool-rendering-reasoning-chain等。
• 专用路由 Agent：declarative-hashbrown-demo、byoc_json_render（declarative-json-render）、a2ui-recovery、a2ui-fixed-schema、declarative-gen-ui、mcp-apps、multimodal-demo、auth-demo、agent-config-demo、voice-demo、beautiful-chat、open-gen-ui、open-gen-ui-advanced。

harness 选择器、e2e spec 与 D6 探针凡是按 Agent-id 取 key 的，必须使用 demo 自身的命名 Agent（即其前端agent值），而不是default。为向后兼容仍注册了一个通用 catch-alldefaultAgent，但没有任何 demo 指向它。这也与 manifest.yaml 中注释的迁移说明相互印证。

shared-state-streaming：无逐 token 状态增量（后端分歧）

BIA没有逐 token 的状态增量流式能力。该 demo 的前端已接线且与 LGP 字节级一致，但进程内的 TanStack 后端不会像 LGP 的shared_state_streaming.py那样发射增量STATE_DELTAtoken。它在manifest.yaml的not_supported_features中被如实标记，并渲染一个data-testid="not-supported-banner"横幅（见下文 NSF banners 一节）。

Interrupt demos：被隔离（上游 react-core RESUME-PATH bug）

gen-ui-interrupt和interrupt-headless与 LGP 字节级一致，使用相同的useInterrupt/useHeadlessInterrupt原语。它们被列入not_supported_features，原因与 LGP 将其隔离的原因完全相同：@copilotkit/react-core/v2存在一个 RESUME-PATH hook bug——后端恢复并正常流式输出（HTTP 200），但前端从不追加确认用的 assistant 气泡，导致 harness 的 DOM settle-check 超时。

修复需要改发布包（超出本集成的范围），因此这两个 demo 被标记为 not-supported（skipped-incapable 侧行——既不是绿也不是红，而非计为回归）。它们仍保持接线状态。解除隔离的时机：在同一个 bump@copilotkit/react-core的 PR 中一并解除。

Reasoning 三件套：manifest 隔离

以下三项在 manifest.yaml 中列入not_supported_features，等待一个修复同类 RESUME-PATH bug 的@copilotkit/react-core发布，以及内置 factory 的后端 reasoning 事件发射能力：

• reasoning-default-render
• agentic-chat-reasoning
• tool-rendering-reasoning-chain

其中tool-rendering-reasoning-chain仍是接线的 demo（与 LGP 字节级一致，后端由 src/lib/factory/reasoning-factory.ts 支撑），但在隔离期间被排除在features:之外——这与 interrupt demos 的"demo 存在但不是 feature"形态相同。一旦上游react-core修复落地且factory 能稳定发射REASONING_MESSAGE_*事件，就在react-corebump PR 中解除隔离。

NSF banners：graceful 的"不支持"横幅

有两个 demo 渲染带data-testid="not-supported-banner"的 graceful 横幅，让 harness 能够确定性地探测它们，而不是在缺失 UI 上超时：

• gen-ui-interrupt（隔离中，见上文）
• shared-state-streaming（无逐 token 状态增量流式）

D6 探针应把命中not-supported-banner视为 PASS-SKIPPED，而不是 FAIL。

headless-complete 的服务端工具 reprompt 循环：sequenceIndex fixture 门控

BIA 通过 TanStack 的chat()引擎将get_weather/get_stock_price/get_revenue_chart/highlight_note注册为服务端执行工具。LLM 返回工具调用后，TanStack 执行服务端工具并用结果重新提示 LLM；原始用户 pill 文本始终保留在会话历史中，因此按 userMessage 取 key 的 toolcall fixture 会在每次 reprompt 时天真地重新触发，循环永不收敛。此外，BIA 的/v1/responses端点还会把 assistant 的tool_call_id重写为运行时生成的fc-…值，破坏了在非重写后端上有效的 toolCallId-keyed narration 回退。

解决方案（#5427 后续）：d6/built-in-agent/gen-ui-headless-complete.json将每个 pill 组织成(sequenceIndex:0 emitter, narration fallback)对：

• emitter匹配该 pill 提示词的第一次请求（计数器从 0 开始）并发射工具调用；
• 随后的 BIA reprompt 迭代则穿过已耗尽的 emitter，落到 narration 回退（不再发射工具调用），循环因此收敛。

选择sequenceIndex而非hasToolResult:false的原因是：hasToolResult是跨整个线程计算的——任何更早 pill 的工具结果都会永久禁用hasToolResult:false的 emitter，从而破坏多轮会话。

该模式是 BIA 专属的，因为 LGP 将这些工具运行在 Python Agent内部并直接以 AG-UI 事件发射——没有 TanStack reprompt 循环——所以 LGP 的gen-ui-headless-complete.json保留着更简单的 userMessage-only emitter 模式。

multimodal：copilot-add-menu-button

copilot-add-menu-button这个 testid 由@copilotkit/react-core/v2的CopilotChatInput渲染，随发布包一起发布，不需要 BIA 侧的 cell 改动。multimodal demo 通过一个包装 CSS 选择器来样式化菜单按钮——可参考 LGP 的multimodaldemo 的模式（BIA 的与其字节级一致）。

threadid-frontend-tool-roundtrip：仅 feature，无 catalog demo

threadid-frontend-tool-roundtrip列在features:下——后端在 route.ts 注册了同名命名 Agent，字节级一致的前端位于src/app/demos/threadid-frontend-tool-roundtrip/。它有意不作为demos:条目：LGP 自己的 manifest 也没有 threadid demos 条目，而且增加 demos 条目会因共享的showcase/shared/constraints.yaml中constrained-explicit白名单未列出它而导致validate-constraints失败。要将其作为 catalog demo 展示，必须先把该 id 加入白名单（独立 owner），然后才能添加demos:条目。

已知问题：下游 Renderer / 状态订阅差距（后续 PR）

剩余的 A2UI 失败位于集成层下游——即 A2UI renderer host。修复属于上游包（@copilotkit/react-core、A2UI renderer host），已在后续 PR 中跟踪。集成层 diff（源码级 testid、aimock fixtures、factory 后端接线）是正确的。

a2ui-fixed-schema — RED（testid 从不挂载）

• D6 状态：RED——a2ui-fixed-cardtestid 从不出现在 DOM 中。
• 集成层正确：源码 testid ✓；aimock fixture 已创建并被消费 ✓；a2ui-fixed-schema-factory.ts 发射格式良好的 v0.9 A2UI op 信封，display_flight工具正常触发 ✓。
• 缺失项：A2UI renderer host 尽管收到了合法信封，却没有把 Card 投影进 DOM。在 host 渲染之前，任何集成层改动都无法满足 testid 预期。
• 疑似修复位置：A2UI renderer host 包，在后续 PR 中跟踪。

declarative-gen-ui — RED（testids 从不挂载）

• D6 状态：RED——declarative-card和declarative-metrictestid 从不出现。
• 集成层正确：源码 testid ✓；aimock fixture 已创建并被消费（三段式序列工作 ✓）；a2ui-factory.ts 的generate_a2ui正确触发 ✓。
• 缺失项：与a2ui-fixed-schema同类的 renderer-host 失败——host 未挂载投影的组件，尽管生成流合法。
• 疑似修复位置：A2UI renderer host 包，与a2ui-fixed-schema的 renderer-host 修复一起打包。

注意：declarative-gen-ui与mcp-apps在manifest.yaml中被标记为PENDING D6 CONFIRMATION候选 NSF（并行 Agent 正在确认它们是下游-RED 而非已支持）。在 orchestrator 定案前，它们仍保留在features:中。

gen-ui-agent — GREEN（已收回；react-core 前提已过时）

• D6 状态：GREEN——端到端通过 D6 探针。此前关于@copilotkit/react-core存在STATE_DELTA → useAgent状态订阅差距的说法已过时，被本地 D6 运行证伪。
• 为什么能工作：后端set_steps服务端工具结果在 tanstack-factory.ts 中被转换为STATE_DELTA（[{op:"add", path:"/steps", value:steps}]，set_steps分支）。故意使用add而非replace，是为了让 patch 即使在/steps尚不存在时也能落地，且@ag-ui/client@0.0.57不会把它当作OPERATION_PATH_UNRESOLVABLE吞掉。接线在发布版 kit 中已完成——无需 react-core 改动。
• 行动：无——完全支持并计入。

本地 D6 环境阻塞：aimock:latest缺少上下文作用域

有四个 cell 在本地变 RED，原因是部署的ghcr.io/copilotkit/aimock:latest镜像没有实现context/x-aimock-contextfixture 作用域（其 CLI 没有--context-field标志，matchFixture也不做上下文检查）。aimock 把所有 slug 的 fixtures 扁平加载，按userMessage子串匹配，先加载先命中（d4/*在d6/*之前；d6内部ag2在built-in-agent之前）。因此，对于userMessage跨 slug 共享的 pill，更早加载的 fixture（如d6/ag2/*或d4/*）会遮蔽built-in-agent 自己的 fixture。这些遮蔽 fixture 使用toolCallId门控的 narration，永远匹配不上 BIA/v1/responses重写后的fc-*tool-call id，于是 reprompt 循环永不收敛。

受影响的 cell（BIA fixtures 本身是正确的，在上下文感知的 aimock 下能收敛——已在过时镜像下验证为惰性/无效）：

• tool-rendering-custom-catchall（已重写为 BIA 的sequenceIndexemitter + narration 回退模式 + 4 个 LGP UI pills，上下文重写）
• headless-complete（正确的sequenceIndexfixture 被遮蔽）
• gen-ui-agent（正确的竞品set_stepsfixture 被一个通用的{userMessage:"summarize"}d4条目遮蔽——与 STATE_DELTA add-op 无关；factory 的add /steps没问题）
• frontend-tools（正确的sequenceIndexemitter + 收尾 narration，被d6/ag2/frontend-tools.json遮蔽）

修复（基础设施，非 BIA）：用一个包含context匹配的 aimock 构建重新部署showcase-aimock（aimockorigin/main已具备）。运行上下文感知 aimock 的 CI/staging 会显示这些 cell 为 GREEN。

declarative-gen-ui 与 mcp-apps：已解决为 GREEN（非 NSF）

两者此前被怀疑为下游 host RED；基于上下文作用域 aimock 的逐 demo 探针证明了相反结论——两者都是 GREEN：

• declarative-gen-ui—无改动即为 GREEN。此前的 RED 纯粹是跨 slug fixture 遮蔽（见 aimock 一节）；a2ui-fixed-schema在同一个 A2UI renderer host 上通过，说明 host 从来不是问题。全部四个 pill 都渲染出其 catalog testid，断言通过。
• mcp-apps— fixture 修复后为 GREEN。根因：excalidraw 的 MCPcreate_view工具在其inputSchema中把elements参数声明为字符串（JSON 编码的数组），但 fixtures 发射的是原始 JSON数组。BIA 通过jsonSchemaToZod→z.string()本地声明注入的 MCP 工具，因此数组参数未通过输入校验、工具从未对 excalidraw 执行、没有ACTIVITY_SNAPSHOT触发、iframe 从未挂载。修复：把elements作为 JSON 字符串发射（在tool-rendering-reasoning-chain.json的create_view条目与mcp-apps.json的 flowchart 条目中）。外部 MCP 服务器从 demo 容器是可达的——不是外部阻塞。

这里涉及的jsonSchemaToZod位于 tanstack-factory.ts 中，是一个浅层 JSON Schema → Zod 转换器（覆盖{ type: "object", properties: {...} }常见形态，对string/number/integer/boolean/array做基本映射）。它的设计意图（代码注释中已说明）是仅供 LLM 工具调用声明使用，不做运行时校验。

Real-LLM 后端审计：针对真实 OpenAI 验证过的修复

有一轮审计让 demos 面向真实OPENAI_API_KEY（无 aimock，OPENAI_BASE_URL未设置）运行，暴露了 aimock fixtures 掩盖的后端 bug。以下每项都已修复，并在浏览器中端到端重验（渲染 testids + assistant 文本）。这些与上面的 aimock/D6 备注正交。

cvdiag 的.js导入扩展名——仅开发环境的/api/copilotkit500（BLOCKER）

src/cvdiag/*.ts用显式.js扩展名导入兄弟模块（如from "./schema.js"）。在next dev --turbopack+moduleResolution: bundler下这些 specifier 无法解析，导致开发环境中每个请求到/api/copilotkit都返回 500。生产next build则能容忍。修复方式：去掉schema.ts、edge-headers.ts、emit.ts、pb-writer-fetch.ts、cvdiag-emitter.ts中相对兄弟导入的.js扩展名。

shared-state-read / shared-state-read-write —— UI 状态从未到达后端

根因是demo 前端的客户端播种竞态，而非转换器问题：seed effect 以[]依赖运行，因此它播种的是useAgent返回的临时agent，而此时运行时/info同步仍在飞行中。当真实的运行时同步 agent 换入时（新的引用），[]-deps effect不会再跑，于是真正被runAgent序列化进input.state的 agent 携带的是state: {}，模型回答"我没看到菜谱"。（运行时的convertInputToTanStackAI已经把input.state正确注入系统提示词。）修复方式：两个 demo 页面均改为在[agent]依赖上播种，并用现有的!recipe/!preferences检查保护，避免用户编辑被覆盖。已验证：模型能读到播种的 recipe/preferences。

shared-state-read-write ——set_notes结果未转为状态

set_notes是服务端工具（server-tools.ts），返回{ notes }，但tanstack-factory.ts的convertStream只把AGUISendStateSnapshot/AGUISendStateDelta/set_steps翻译为 STATE 事件。现已新增set_notes→STATE_DELTA add /notes分支（与set_steps相同的 RFC-6902add-而非-replace理由）。已验证：让 Agent "记住"某事会填充notes-list/note-item。

declarative-gen-ui / a2ui-recovery —— 次级 A2UI LLM 输出空字符串

a2ui-factory.ts的generate_a2ui此前传了modelOptions.response_format: { type: "json_object" }。TanStack 的openaiText面向 OpenAIResponsesAPI，而 Responses API不接受Chat-Completions 的response_format参数——传入该参数会让次级调用返回空字符串（已验证），surface 因此从不绘制。修复方式：移除response_format（JSON-only 输出改由系统提示词强制，与 byoc factories 一致），外加防御性的stripJsonFences解包（该工具函数在 a2ui-factory.ts 中实现，负责剥掉次级 LLM 可能加上的json …围栏）。已在真实 OpenAI 上验证：declarative-gen-ui与a2ui-recovery的 heal 回合会绘制declarative-metric/declarative-pie-chart/declarative-bar-chart。（a2ui-recovery的exhaust/失败卡片路径由确定性 aimock fixtures 驱动——强制每个校验回合失败；真实 LLM 会产出合法 surface，因此失败卡片按设计无法在真实 key 下复现。）

Reasoning 三件套 —— 经 Responses API 的真实推理轨迹

真实 OpenAI chat-completions不流式reasoning_content（只有 aimock 流式），因此此前的 chat-completionsextractReasoning适配器在真实 key 下产不出任何轨迹。reasoning-factory.ts现在改用openaiText（Responses API，与其它所有 demo 相同的传输层），搭配modelOptions.reasoning = { effort: "high", summary: "auto" }和一个type: "custom"转换器，把 Responses-API 的 thinking STEP 块（STEP_STARTEDstepType:"thinking"+STEP_FINISHEDdeltas）映射为REASONING_MESSAGE_*AG-UI 事件。已在真实 OpenAI 上验证：reasoning-custom渲染reasoning-block，reasoning-default渲染内置的 "Thought for …" 块，tool-rendering-reasoning-chain同时渲染推理块和工具卡片（无 tool-render 回归）。

从源码看，其实现细节如下（reasoning-factory.ts）：

• 模型默认为gpt-5.2，可通过REASONING_MODEL环境变量切换为其它 Responses-API 推理模型（如o3、gpt-5-thinking）。
• 推理强度默认为high，可通过REASONING_EFFORT覆盖。
• 自定义转换器维护REASONING_START → REASONING_MESSAGE_START → REASONING_MESSAGE_CONTENT* → REASONING_MESSAGE_END → REASONING_END生命周期，一旦出现文本或工具调用立即关闭推理块；文本与工具调用事件像tanstack-factory的转换器一样做了多轮重宣告去重。

已记录的非阻塞注意点：

• 推理摘要要求effort: "high"；在low/medium下，真实 OpenAI 经常在短提示词上完成回合而不发射摘要 part。
• OpenAI 的提示词缓存意味着相同提示词被反复询问可能返回缓存完成（无新推理摘要）——首次/新鲜的询问可靠地产出。
• 该改动把推理 demos 的传输层从 chat-completions 切换到 Responses API。文本 + 工具调用行为不变（已验证）；如果 aimock D6 推理 fixtures 是为 chat-completions 的reasoning_content形态录制的，需要为 Responses-API 推理摘要重新录制。manifest.yaml的not_supported_features条目保持不动（此处无法在无 aimock 的情况下验证）。

auth + voice 的[[...slug]]路由——仅开发服务器 500，生产不受影响

/api/copilotkit-auth/*与/api/copilotkit-voice/*（仅有的两个 catch-all[[...slug]]路由；其余路由都是单一route.ts）会在请求时崩溃开发服务器的路由 worker——next dev --turbopack下经由 PostCSS/worker panic，普通next dev（webpack）下则经由被掩盖的 "Jest worker encountered … child process exceptions"WorkerError。崩溃发生在 handler 之下（路由内的 try/catch 从不触发），并且不会在生产中复现：next build+next start之后，auth /info在带合法 token 时返回 200、不带时 401，auth 聊天端到端运行（assistant 回复、所有/info+/run响应 200、零控制台错误），voice /info返回 200。这是 catch-all API 路由 + V2 运行时 handler 在next dev下的 dev-server 限制，不是集成 bug——无需代码改动。生产不受影响。

逐 demo system prompt —— 命名 Agent 注册表并非提示词中立

LGP 给每个 demo 各自的 graph以及各自的 system prompt（langgraph.json中有 28 个 graph）。BIA 的注册表曾让约 20 个 demo 指向一个无提示词的createBuiltInAgent()，其理论是"逐 demo 行为由 aimock fixture 驱动"。这在 D6 下成立，但面对真实 LLM 会失败，因为 fixture 回答的是一道模型从未被问过的问题。有五个 demo 在 D6 全绿的情况下实况是坏的：

这些提示词现在集中存放在 src/lib/factory/demo-prompts.ts，通过createBuiltInAgent({ systemPrompt })传入。从 LGP 移植 demo 时，务必连它的 graph 提示词一起移植——fixture 不会告诉你它丢了。

以GEN_UI_TOOL_BASED_PROMPT为例，它明确要求："如果用户命名了图表主题但未提供具体数字（例如'展示一个按来源划分的网站流量饼图'），不要向他们索要数据。自己构想合理的示例值，立即调用合适的render_*工具，并在后续回复中简要注明这些值是示例。每个value必须是非零数字，绝不要发射占位零。"——这正是修复"图表画全零"症状的关键。

state.<slot>需要转换器分支——没有按 Agent 的状态 schema

tanstack-factory.ts的convertStream是唯一发射 Agent 状态的地方。subagents曾发布了一个读取agent.state.delegations的前端，但没有任何东西发射该 slot——于是子 Agent 工具正常执行、聊天正常填充、左侧日志却永远为空。现在它在每个子 Agent 结果上发射一个/delegationsdelta（LGP 用operator.addreducer 声明同一 slot），并移植了 LGP 的_MAX_CRITIQUE_ITERATIONS = 1上限，防止 supervisor 堆叠重复的 critique 行。由 tanstack-factory.test.ts 钉住。从源码看，转换器维护了delegations数组，对research_agent/writing_agent/critique_agent（SUBAGENT_TOOL_NAMES）的结果逐条 push 并整数组add到/delegations，还会从累积的TOOL_CALL_ARGS中抽取task文本（args 流式分片到达，解析失败时回退为空字符串）。

a2ui-recovery 只在 aimock 下演示恢复

heal / recovery-exhausted 分支需要一个能按需发射非法 surface 的设计师 LLM。面对真实 LLM，次级设计师第 1 次尝试就成功，所以实况下 demo 只画出一张普通卡片、看不到恢复过程；SINGLE_CALL_ADDENDUM提示词（"每个用户请求恰好调用一次generate_a2ui……即使结果看起来不对也绝不再调用第二次"）的存在是为了阻止 supervisor 重调工具画出重复卡片。要让该循环在实况可复现，需要刻意注入故障——做一个故意失败的 demo。这被推迟为产品决策，而非疏忽。

何时更新这份文件

维护纪律明确如下（与文件末尾一致）：

• 新增相对 LGP 的逐 demo 能力分歧 → 记录其理由。
• 解除manifest 隔离 → 删除上面对应条目，并在同一提交中翻转manifest.yaml的not_supported_features。
• 新增NSF banner → 在此列出 demo + testid。

总结：对账的黄金法则

把 PARITY_NOTES.md 浓缩为三条可直接执行的原则：

1. 对账目标永远是"能力 + 渲染 DOM"，而非源码文本——import type分组是唯一允许的 drift。
2. Agent-id 一律使用 demo 自身的命名 Agent（前端agent值），旧default约定已废弃；命中not-supported-banner视为 PASS-SKIPPED。
3. 本地 RED 不等于集成 bug——先排除 aimock:latest的跨 slug fixture 遮蔽，再对照本文件的已知下游（renderer-host）项与真实 LLM 审计结论，最后才判定为回归。

这份 Parity Notes 的价值正在于把"预期差异、待解除的隔离、下游缺陷与已修复的实况 bug"分层归档，让后续每个接手者都能在对账时把火力集中在真正的问题上。

【免费下载链接】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