Agentsview 深度解析让 VS Code 1.132 Copilot 会话恢复结构化工具调用的响应项解析设计【免费下载链接】agentsviewLocal-first session search, analytics, insights, and token use statistics for coding agents, supporting Claude Code, Codex, and more than 20 other agents.项目地址: https://gitcode.com/GitHub_Trending/ag/agentsview本文围绕 Agentsview 仓库中的设计规格 2026-08-12-vscode-copilot-response-items-design.md剖析 VS Code 1.132 改变 Copilot 会话持久化形状后Agentsview 的 VS Code Copilot 解析器如何通过“schema 容错 双位置命令提取 内联引用转写”恢复出结构化工具调用与可读的文件引用。读完本文你将理解该解析器的数据流、错误策略、回归测试构造方式以及设计决策在源码 internal/parser/vscode_copilot.go 中的落点。背景VS Code Copilot 会话文件与响应项VS Code Copilot 将聊天会话持久化为chatSessions/uuid.json快照或 JSONL 操作日志。顶层结构包含sessionId、creationDate、lastMessageDate、customTitle和requests数组每个request是一个回合用户提示 响应其中response字段是一个有序的响应项数组这是还原“助手到底做了什么”的唯一权威来源。在 Agentsview 中这一解析由 internal/parser/vscode_copilot.go 承担。入口parseSession根据扩展名分流.jsonl文件先经reconstructJSONL回放操作日志重建完整 JSON再交给parseVSCodeCopilotData。值得注意的是该函数注释明确说明它“同时被 VSCode Copilot 和 Positron 解析器使用因为两种格式完全相同”——Positron 复用了同一套响应项解析逻辑因此本次 schema 修复对两个数据源同时生效。JSONL 回放本身也是一个精巧的机制日志中每条记录是一个jsonlOpkind取值 0/1/2/3 分别表示 Initial 快照、Set、Push、Delete解析器按 key 路径回放这些变更重建出与快照等价的会话 JSON并带有 128 MiB 的单条记录安全上限。这意味着 1.132 会话无论是以紧凑快照还是操作日志形式落盘都进入同一条解析路径。问题VS Code 1.132 的三种新形状导致工具调用被静默丢弃设计文档的 Problem 一节列出了 1.132 引入的三处持久化形状变化以及它们如何破坏旧解析器isConfirmed从布尔值变为对象。旧解析器把每个响应项整体 unmarshal 进一个带bool类型isConfirmed字段的 Go 结构体。一旦该字段是对象如{type:1}整项 unmarshal 失败解析器静默跳过整个工具调用——不是报一个字段错而是丢失整个toolInvocationSerialized项。终端命令下沉嵌套。旧版本中命令位于toolSpecificData.command1.132 改为toolSpecificData.commandLine.original旧代码读不到命令。文件引用变为inlineReference项。文件引用不再内嵌于文本而是作为独立的inlineReference项穿插在文本项之间。旧解析器刻意跳过这类项导致相邻文本被直接拼接被引用的文件名从展示内容中消失。设计文档特别指出旧行为的后果链“对象值让该 unmarshal 失败于是解析器静默跳过整个工具调用”并且“刻意跳过内联引用把周围文本拼在一起却没有被引用的文件名”。这三点正是回归测试必须钉住的契约。设计决策权威数据源、schema 容错与引用转写设计部分给出四条核心决策每一条都对应一个可验证的实现约束以request.response为唯一权威来源最终request.response数组是有序响应的权威表示。文档明确反对从result.metadata.toolCallRounds恢复工具调用理由是同一批调用在两种表示中都出现若做对账reconciliation会引入重复计数路径。因此 1.132 的形状变化只能在 response 数组内部消化而不是跨数据源拼接。未使用字段保持 schema 容错“对不用于构造解析输出的字段让它在 schema 上保持容错使任何新的表示都无法使一个响应项的其余部分失效。” 落地的做法是把生产者形状多变的字段声明为原始 JSON 值jsontext.Value而非固定标量类型。实现中vscodeCopilotResponseItem结构体即按此设计type vscodeCopilotResponseItem struct { Kind string json:kind,omitempty Value string json:value,omitempty ToolID string json:toolId,omitempty ToolCallID string json:toolCallId,omitempty InvocationMessage jsontext.Value json:invocationMessage,omitempty PastTenseMessage jsontext.Value json:pastTenseMessage,omitempty ToolName string json:toolName,omitempty InlineReference jsontext.Value json:inlineReference,omitempty ToolSpecificData jsontext.Value json:toolSpecificData,omitempty }见 internal/parser/vscode_copilot.go。isConfirmed这类状态字段干脆不再进入结构体——encoding/json会忽略未声明字段于是无论它取布尔值还是对象都不会影响kind、toolId等稳定字段的解码。这正是实施计划 2026-08-12-vscode-copilot-response-items.md 中“移除未使用的布尔型IsConfirmed/IsComplete字段”一步的直接动机。内联引用转写为行内代码文本inlineReference项被保留为包含文件路径的行内代码反引号包裹的 inline-code 文本。设计文档解释了为什么不直接输出file://链接这样“引用在其精确位置保持可见而不会暴露一个仅本地可用、对远端查看者无效的file://链接”。实现见extractVSCodeInlineReferenceinternal/parser/vscode_copilot.gofunc extractVSCodeInlineReference(raw jsontext.Value) string { var ref vscodeCopilotInlineReference if err : json.Unmarshal(raw, ref); err ! nil { return } path : ref.FSPath if path { path ref.Path } if path { path strings.TrimPrefix(ref.External, file://) } if path { return } return path }路径解析优先级为fsPath→path→ 去掉file://前缀的external三者皆空则返回空串——即“畸形的内联引用不贡献任何文本”与文档约定的错误策略一致。终端命令的双位置读取命令从两个受支持位置读取toolSpecificData.command既有会话文件的扁平形状toolSpecificData.commandLine.originalVS Code 1.132 的嵌套形状。实现上vscodeCopilotToolData同时声明了扁平与嵌套两种字段internal/parser/vscode_copilot.go而extractVSCopilotInputJSON遵循“优先非空的Command其次CommandLine.Original统一写入既有command键”的规则internal/parser/vscode_copilot.go。设计文档要求“把恢复出的命令填入工具调用输入使结构化调用与其渲染块都显示该命令”——渲染侧由formatVSCodeCopilotToolCalls与extractVSCopilotToolBody完成若输入 JSON 中有command工具块正文渲染为$ 命令否则回退到message文本internal/parser/vscode_copilot.go。数据流从原始项到一条助手消息设计文档的 Data Flow 一节描述了逐项处理策略与实现一一对应。parseVSCodeCopilotResponseinternal/parser/vscode_copilot.go遍历 response 数组按kind分派项类型处理说明空kind追加value无 kind 的项即 markdown 文本inlineReference经extractVSCodeInlineReference追加反引号路径畸形项不贡献文本toolInvocationSerialized生成一个ParsedToolCall无toolId则不生成调用prepareToolInvocation跳过真正的调用项随后出现undoStop/codeblockUri/textEditGroup跳过非文本项未知 kind尝试提取value尽力而为取不到则丢弃其中toolInvocationSerialized项会提取toolId作为ToolName、toolCallId作为ToolUseID并经normalizeVSCodeToolNameNormalizeToolCategory归一化出分类——这一步“保留既有的工具名归一化与展示格式”是设计文档的显式要求。归一化映射表覆盖文件读取copilot_readFile→read_file、编辑、终端run_in_terminal→shell、搜索、glob、网页等类别见 internal/parser/vscode_copilot.go未知工具名原样透传。整体错误策略保持与解析器现状一致畸形或未知响应项继续被跳过畸形内联引用不贡献文本无工具 ID 的调用不产出工具调用。每个 request 最终产出一条助手消息携带工具调用列表与有序展示文本若存在工具使用渲染后的工具块文本会置于正文之前无正文时工具文本即全部展示内容。回归测试手工裁剪的 1.132 JSONL 夹具设计文档的 Test Strategy 要求添加一个“手工裁剪的 JSONL 夹具”数值取自 issue 会话但只保留回归所需的响应形状。仓库中的实现是 internal/parser/vscode_copilot_test.go 的TestParseVSCodeCopilotSession_VSCode132ResponseItems。夹具是一个两行的 JSONL 文件第一行kind:0初始快照第二行kind:2向requests追加一个 request其 response 数组恰好覆盖设计文档要求的四类形状——两个copilot_readFile调用与一个run_in_terminal调用均带对象值的isConfirmed:{type:1}终端命令位于toolSpecificData.commandLine.original值为uname -a同时含forDisplay字段两条inlineReference项fsPath/path/external齐备穿插在Ill read 、 first. 与 contains the command.等文本片段之间。断言钉住了公共解析契约require.Len(t, msgs, 2, user and assistant messages) assistant : msgs[1] assert.True(t, assistant.HasToolUse) require.Len(t, assistant.ToolCalls, 3) // 顺序copilot_readFile, copilot_readFile, run_in_terminal assert.JSONEq(t, {command:uname -a,message:Running uname}, assistant.ToolCalls[2].InputJSON, ) assert.Contains(t, assistant.Content, Ill read /workspace/test.txt first.) assert.Contains(t, assistant.Content, /workspace/test.txt contains the command.)文档说明了该测试的失效条件若对象值状态字段再次使项解码失效工具调用数变 0、嵌套命令提取被移除InputJSON缺command、或文件引用被丢弃正文缺反引号路径测试即失败。配套的TestNormalizeVSCodeToolName与TestExtractVSCopilotInputJSONinternal/parser/vscode_copilot_test.go则分别验证归一化映射与输入 JSON 构造其中后者显式覆盖了“字符串形态调用消息”“对象形态调用消息”“优先 pastTenseMessage”“扁平终端命令”四种分支确保旧形状兼容性不被新逻辑破坏。复现验证可以运行只读视角下为查看性命令go test ./internal/parser -run TestParseVSCodeCopilotSession_VSCode132ResponseItems -count1 go test ./internal/parser -run TestParseVSCodeCopilotSession|TestExtractVSCopilotInputJSON|TestPositron -count1格式证据与数据版本联动设计文档的最后一条要求是更新会话格式清单。docs/internal/session-format-sources.md 中 VS Code Copilot 条目现已记录2026-08-12 基于 issue #1351 的 VS Code 1.132 JSONL 工件复核确认“已完成工具可持久化对象值的isConfirmed、终端命令位于toolSpecificData.commandLine.original、存在有序inlineReference响应项”并且“Agentsview 消费最终 response 数组同时保留展示顺序而非result.metadata.toolCallRounds下的重复工具调用”。这是“观察到的 1.132 形状 issue 工件作为实现证据”的落点。另一条联动来自实施计划的 Task 3修改解析器后需要提升dataVersion使未变更的已归档会话经由既有的非破坏性全量重同步full-resync路径重新解析。internal/db/db.go 中dataVersion常量驱动该机制——数据库user_version低于当前dataVersion时dataStale被置位触发重同步重建。当时该变更把版本推进到 86 并记录“版本 86 重新解析 VS Code Copilot 与 Positron 会话以恢复响应项”当前仓库中该常量已演进到更高的值说明后续解析器变更继续通过同一机制滚动生效而本设计的重同步语义保持不变。小结这篇设计文档的价值在于一个典型的“上游格式漂移”应对范式且每个决策都有可检验的实现与测试锚点单一权威源只在request.response内解析拒绝toolCallRounds对账路径杜绝重复计数容错解码稳定字段强类型、易变字段保留原始 JSONisConfirmed形状漂移从此无法击穿整项解码位置兼容终端命令同时支持command与commandLine.original新旧会话文件均可解析可移植展示文件引用转写为反引号行内代码在远端查看者视角依然可见可用契约级回归测试手工裁剪夹具 公共结果断言三条失败路径状态字段击穿、嵌套命令丢失、引用丢弃全部被钉死。对阅读 Agentsview 源码的工程师而言这条链路的阅读顺序建议是先读 设计规格 与 实施计划 对齐意图再看 internal/parser/vscode_copilot.go 的响应项分派与提取函数最后用 internal/parser/vscode_copilot_test.go 的 1.132 回归测试验证行为辅以 docs/internal/session-format-sources.md 的格式证据条目完成证据闭环。【免费下载链接】agentsviewLocal-first session search, analytics, insights, and token use statistics for coding agents, supporting Claude Code, Codex, and more than 20 other agents.项目地址: https://gitcode.com/GitHub_Trending/ag/agentsview创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Agentsview 深度解析：让 VS Code 1.132 Copilot 会话恢复结构化工具调用的响应项解析设计
Agentsview 深度解析让 VS Code 1.132 Copilot 会话恢复结构化工具调用的响应项解析设计【免费下载链接】agentsviewLocal-first session search, analytics, insights, and token use statistics for coding agents, supporting Claude Code, Codex, and more than 20 other agents.项目地址: https://gitcode.com/GitHub_Trending/ag/agentsview本文围绕 Agentsview 仓库中的设计规格 2026-08-12-vscode-copilot-response-items-design.md剖析 VS Code 1.132 改变 Copilot 会话持久化形状后Agentsview 的 VS Code Copilot 解析器如何通过“schema 容错 双位置命令提取 内联引用转写”恢复出结构化工具调用与可读的文件引用。读完本文你将理解该解析器的数据流、错误策略、回归测试构造方式以及设计决策在源码 internal/parser/vscode_copilot.go 中的落点。背景VS Code Copilot 会话文件与响应项VS Code Copilot 将聊天会话持久化为chatSessions/uuid.json快照或 JSONL 操作日志。顶层结构包含sessionId、creationDate、lastMessageDate、customTitle和requests数组每个request是一个回合用户提示 响应其中response字段是一个有序的响应项数组这是还原“助手到底做了什么”的唯一权威来源。在 Agentsview 中这一解析由 internal/parser/vscode_copilot.go 承担。入口parseSession根据扩展名分流.jsonl文件先经reconstructJSONL回放操作日志重建完整 JSON再交给parseVSCodeCopilotData。值得注意的是该函数注释明确说明它“同时被 VSCode Copilot 和 Positron 解析器使用因为两种格式完全相同”——Positron 复用了同一套响应项解析逻辑因此本次 schema 修复对两个数据源同时生效。JSONL 回放本身也是一个精巧的机制日志中每条记录是一个jsonlOpkind取值 0/1/2/3 分别表示 Initial 快照、Set、Push、Delete解析器按 key 路径回放这些变更重建出与快照等价的会话 JSON并带有 128 MiB 的单条记录安全上限。这意味着 1.132 会话无论是以紧凑快照还是操作日志形式落盘都进入同一条解析路径。问题VS Code 1.132 的三种新形状导致工具调用被静默丢弃设计文档的 Problem 一节列出了 1.132 引入的三处持久化形状变化以及它们如何破坏旧解析器isConfirmed从布尔值变为对象。旧解析器把每个响应项整体 unmarshal 进一个带bool类型isConfirmed字段的 Go 结构体。一旦该字段是对象如{type:1}整项 unmarshal 失败解析器静默跳过整个工具调用——不是报一个字段错而是丢失整个toolInvocationSerialized项。终端命令下沉嵌套。旧版本中命令位于toolSpecificData.command1.132 改为toolSpecificData.commandLine.original旧代码读不到命令。文件引用变为inlineReference项。文件引用不再内嵌于文本而是作为独立的inlineReference项穿插在文本项之间。旧解析器刻意跳过这类项导致相邻文本被直接拼接被引用的文件名从展示内容中消失。设计文档特别指出旧行为的后果链“对象值让该 unmarshal 失败于是解析器静默跳过整个工具调用”并且“刻意跳过内联引用把周围文本拼在一起却没有被引用的文件名”。这三点正是回归测试必须钉住的契约。设计决策权威数据源、schema 容错与引用转写设计部分给出四条核心决策每一条都对应一个可验证的实现约束以request.response为唯一权威来源最终request.response数组是有序响应的权威表示。文档明确反对从result.metadata.toolCallRounds恢复工具调用理由是同一批调用在两种表示中都出现若做对账reconciliation会引入重复计数路径。因此 1.132 的形状变化只能在 response 数组内部消化而不是跨数据源拼接。未使用字段保持 schema 容错“对不用于构造解析输出的字段让它在 schema 上保持容错使任何新的表示都无法使一个响应项的其余部分失效。” 落地的做法是把生产者形状多变的字段声明为原始 JSON 值jsontext.Value而非固定标量类型。实现中vscodeCopilotResponseItem结构体即按此设计type vscodeCopilotResponseItem struct { Kind string json:kind,omitempty Value string json:value,omitempty ToolID string json:toolId,omitempty ToolCallID string json:toolCallId,omitempty InvocationMessage jsontext.Value json:invocationMessage,omitempty PastTenseMessage jsontext.Value json:pastTenseMessage,omitempty ToolName string json:toolName,omitempty InlineReference jsontext.Value json:inlineReference,omitempty ToolSpecificData jsontext.Value json:toolSpecificData,omitempty }见 internal/parser/vscode_copilot.go。isConfirmed这类状态字段干脆不再进入结构体——encoding/json会忽略未声明字段于是无论它取布尔值还是对象都不会影响kind、toolId等稳定字段的解码。这正是实施计划 2026-08-12-vscode-copilot-response-items.md 中“移除未使用的布尔型IsConfirmed/IsComplete字段”一步的直接动机。内联引用转写为行内代码文本inlineReference项被保留为包含文件路径的行内代码反引号包裹的 inline-code 文本。设计文档解释了为什么不直接输出file://链接这样“引用在其精确位置保持可见而不会暴露一个仅本地可用、对远端查看者无效的file://链接”。实现见extractVSCodeInlineReferenceinternal/parser/vscode_copilot.gofunc extractVSCodeInlineReference(raw jsontext.Value) string { var ref vscodeCopilotInlineReference if err : json.Unmarshal(raw, ref); err ! nil { return } path : ref.FSPath if path { path ref.Path } if path { path strings.TrimPrefix(ref.External, file://) } if path { return } return path }路径解析优先级为fsPath→path→ 去掉file://前缀的external三者皆空则返回空串——即“畸形的内联引用不贡献任何文本”与文档约定的错误策略一致。终端命令的双位置读取命令从两个受支持位置读取toolSpecificData.command既有会话文件的扁平形状toolSpecificData.commandLine.originalVS Code 1.132 的嵌套形状。实现上vscodeCopilotToolData同时声明了扁平与嵌套两种字段internal/parser/vscode_copilot.go而extractVSCopilotInputJSON遵循“优先非空的Command其次CommandLine.Original统一写入既有command键”的规则internal/parser/vscode_copilot.go。设计文档要求“把恢复出的命令填入工具调用输入使结构化调用与其渲染块都显示该命令”——渲染侧由formatVSCodeCopilotToolCalls与extractVSCopilotToolBody完成若输入 JSON 中有command工具块正文渲染为$ 命令否则回退到message文本internal/parser/vscode_copilot.go。数据流从原始项到一条助手消息设计文档的 Data Flow 一节描述了逐项处理策略与实现一一对应。parseVSCodeCopilotResponseinternal/parser/vscode_copilot.go遍历 response 数组按kind分派项类型处理说明空kind追加value无 kind 的项即 markdown 文本inlineReference经extractVSCodeInlineReference追加反引号路径畸形项不贡献文本toolInvocationSerialized生成一个ParsedToolCall无toolId则不生成调用prepareToolInvocation跳过真正的调用项随后出现undoStop/codeblockUri/textEditGroup跳过非文本项未知 kind尝试提取value尽力而为取不到则丢弃其中toolInvocationSerialized项会提取toolId作为ToolName、toolCallId作为ToolUseID并经normalizeVSCodeToolNameNormalizeToolCategory归一化出分类——这一步“保留既有的工具名归一化与展示格式”是设计文档的显式要求。归一化映射表覆盖文件读取copilot_readFile→read_file、编辑、终端run_in_terminal→shell、搜索、glob、网页等类别见 internal/parser/vscode_copilot.go未知工具名原样透传。整体错误策略保持与解析器现状一致畸形或未知响应项继续被跳过畸形内联引用不贡献文本无工具 ID 的调用不产出工具调用。每个 request 最终产出一条助手消息携带工具调用列表与有序展示文本若存在工具使用渲染后的工具块文本会置于正文之前无正文时工具文本即全部展示内容。回归测试手工裁剪的 1.132 JSONL 夹具设计文档的 Test Strategy 要求添加一个“手工裁剪的 JSONL 夹具”数值取自 issue 会话但只保留回归所需的响应形状。仓库中的实现是 internal/parser/vscode_copilot_test.go 的TestParseVSCodeCopilotSession_VSCode132ResponseItems。夹具是一个两行的 JSONL 文件第一行kind:0初始快照第二行kind:2向requests追加一个 request其 response 数组恰好覆盖设计文档要求的四类形状——两个copilot_readFile调用与一个run_in_terminal调用均带对象值的isConfirmed:{type:1}终端命令位于toolSpecificData.commandLine.original值为uname -a同时含forDisplay字段两条inlineReference项fsPath/path/external齐备穿插在Ill read 、 first. 与 contains the command.等文本片段之间。断言钉住了公共解析契约require.Len(t, msgs, 2, user and assistant messages) assistant : msgs[1] assert.True(t, assistant.HasToolUse) require.Len(t, assistant.ToolCalls, 3) // 顺序copilot_readFile, copilot_readFile, run_in_terminal assert.JSONEq(t, {command:uname -a,message:Running uname}, assistant.ToolCalls[2].InputJSON, ) assert.Contains(t, assistant.Content, Ill read /workspace/test.txt first.) assert.Contains(t, assistant.Content, /workspace/test.txt contains the command.)文档说明了该测试的失效条件若对象值状态字段再次使项解码失效工具调用数变 0、嵌套命令提取被移除InputJSON缺command、或文件引用被丢弃正文缺反引号路径测试即失败。配套的TestNormalizeVSCodeToolName与TestExtractVSCopilotInputJSONinternal/parser/vscode_copilot_test.go则分别验证归一化映射与输入 JSON 构造其中后者显式覆盖了“字符串形态调用消息”“对象形态调用消息”“优先 pastTenseMessage”“扁平终端命令”四种分支确保旧形状兼容性不被新逻辑破坏。复现验证可以运行只读视角下为查看性命令go test ./internal/parser -run TestParseVSCodeCopilotSession_VSCode132ResponseItems -count1 go test ./internal/parser -run TestParseVSCodeCopilotSession|TestExtractVSCopilotInputJSON|TestPositron -count1格式证据与数据版本联动设计文档的最后一条要求是更新会话格式清单。docs/internal/session-format-sources.md 中 VS Code Copilot 条目现已记录2026-08-12 基于 issue #1351 的 VS Code 1.132 JSONL 工件复核确认“已完成工具可持久化对象值的isConfirmed、终端命令位于toolSpecificData.commandLine.original、存在有序inlineReference响应项”并且“Agentsview 消费最终 response 数组同时保留展示顺序而非result.metadata.toolCallRounds下的重复工具调用”。这是“观察到的 1.132 形状 issue 工件作为实现证据”的落点。另一条联动来自实施计划的 Task 3修改解析器后需要提升dataVersion使未变更的已归档会话经由既有的非破坏性全量重同步full-resync路径重新解析。internal/db/db.go 中dataVersion常量驱动该机制——数据库user_version低于当前dataVersion时dataStale被置位触发重同步重建。当时该变更把版本推进到 86 并记录“版本 86 重新解析 VS Code Copilot 与 Positron 会话以恢复响应项”当前仓库中该常量已演进到更高的值说明后续解析器变更继续通过同一机制滚动生效而本设计的重同步语义保持不变。小结这篇设计文档的价值在于一个典型的“上游格式漂移”应对范式且每个决策都有可检验的实现与测试锚点单一权威源只在request.response内解析拒绝toolCallRounds对账路径杜绝重复计数容错解码稳定字段强类型、易变字段保留原始 JSONisConfirmed形状漂移从此无法击穿整项解码位置兼容终端命令同时支持command与commandLine.original新旧会话文件均可解析可移植展示文件引用转写为反引号行内代码在远端查看者视角依然可见可用契约级回归测试手工裁剪夹具 公共结果断言三条失败路径状态字段击穿、嵌套命令丢失、引用丢弃全部被钉死。对阅读 Agentsview 源码的工程师而言这条链路的阅读顺序建议是先读 设计规格 与 实施计划 对齐意图再看 internal/parser/vscode_copilot.go 的响应项分派与提取函数最后用 internal/parser/vscode_copilot_test.go 的 1.132 回归测试验证行为辅以 docs/internal/session-format-sources.md 的格式证据条目完成证据闭环。【免费下载链接】agentsviewLocal-first session search, analytics, insights, and token use statistics for coding agents, supporting Claude Code, Codex, and more than 20 other agents.项目地址: https://gitcode.com/GitHub_Trending/ag/agentsview创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考