用途
Excalidraw 子代理委派技能用于在涉及 Excalidraw 图表文件时，将操作委派给子代理，避免主代理直接读取文件。触发条件包括：文件路径包含 .excalidraw 或 .excalidraw.json；用户请求解释、更新或创建图表、展示架构、可视化流程；用户提及流程图、架构图、Excalidraw 文件；涉及视觉产物的架构或设计文档任务。
核心原则
主代理绝不直接读取 Excalidraw 文件，始终委派给子代理以隔离上下文消耗。Excalidraw 文件是 JSON 格式，token 成本高但信息密度低。单个文件范围从 4k 到 22k tokens（最大的可能超过读取工具限制）。读取多个图表会迅速耗尽上下文预算（7 个文件 = 67k tokens = 预算的 33%）。
问题背景
Excalidraw JSON 结构特点：每个形状有 20 多个属性（x、y、width、height、strokeColor、seed、version 等）；大多数属性是视觉元数据（定位、样式、粗糙度）；实际内容为文本标签和元素关系（不到文件的 10%）；信噪比极低。示例：14 个元素的图表 = 596 行，16K，约 4k tokens；79 个元素的图表 = 2,916 行，88K，约 22k tokens（超过读取限制）。
何时使用
对以下任一情况触发：文件路径包含 .excalidraw 或 .excalidraw.json；用户请求“解释/更新/创建图表”、“展示架构”、“可视化流程”；用户提及“流程图”、“架构图”、“Excalidraw 文件”；涉及视觉产物的架构/设计文档任务。即使对于“小”文件（最小的也是 4k tokens，仍然显著）、“快速检查”（检查组件名称仍会加载完整 JSON）、单文件操作（隔离防止上下文污染）、修改（不需要在主上下文中完全理解格式），也应使用委派。
委派模式
主代理职责：绝不使用 Read 工具读取 *.excalidraw 文件；绝不在主上下文中解析 Excalidraw JSON；绝不加载多个图表进行比较；绝不检查文件以“理解格式”。始终将所有 Excalidraw 操作委派给子代理；向子代理提供清晰的任务描述；请求纯文本摘要（而非原始 JSON）；保持图表分析与主工作隔离。
子代理任务模板
读取/理解操作：任务为提取并解释 [file.excalidraw.json] 中的组件。方法：读取 Excalidraw JSON；仅提取文本元素（忽略定位/样式）；识别组件之间的关系；总结架构/流程。返回：带描述的组件/服务列表；连接/依赖关系；关于架构的关键见解；不要返回原始 JSON 或冗长的元素细节。
修改操作：任务为向 [file.excalidraw.json] 添加 [component]，连接到 [existing-component]。方法：读取文件以识别现有元素；找到 [existing-component] 及其位置；为 [component] 创建新元素 JSON；添加箭头元素以建立连接；写入更新后的文件。返回：所做更改的确认；新元素的位置；所创建元素的 ID。
创建操作：任务为创建新的 Excalidraw 图表，展示 [description]。方法：为 [number] 个组件设计布局；创建带文本标签的矩形元素；添加箭头显示关系；使用一致的样式（颜色、字体）；写入 [file.excalidraw.json]。返回：文件已创建的确认；所包含组件的摘要；文件位置。
比较操作：任务为比较 [file1] 与 [file2] 中的架构方法。方法：读取两个文件；从每个文件中提取文本标签；识别结构差异；比较组件关系。返回：架构中的关键差异；每种方法独有的组件；关系/流程差异；不要返回两个文件的完整元素细节。
常见借口（应停止并委派）
“直接读取最高效”——不必要地消耗 4k-22k tokens，应委派给子代理。“直接读取更省 token”——基线测试显示使用了 9-45% 的预算，应始终委派。“这对一次性分析最优”——“一次性”仍会污染主上下文，应使用子代理隔离。“JSON 很直接”——简单不等于 token 高效，仍应委派。“我需要理解格式”——主代理不需要理解格式，子代理处理格式。“在合理范围内”（18k tokens）——“合理”是主观借口，硬性规则：委派。“只是快速检查组件”——“快速检查”仍会加载完整 JSON，通过子代理提取文本。“文件很小（16K）”——4k tokens 并不小，大小阈值无关紧要。
危险信号——停止并委派
当发现自己即将：对 .excalidraw 文件使用 Read 工具；“快速检查”存在哪些组件；在修改前“理解结构”；加载文件以“看看有什么”；并排比较多个图表；解析 JSON 以“仅提取文本”。所有这些都意味着：改用 Task 工具与子代理。
快速参考
理解图表：主代理操作——使用“提取并解释”模板委派；子代理返回——组件列表 + 关系。修改图表：主代理操作——使用“添加 [X] 连接到 [Y]”模板委派；子代理返回——确认 + 所做更改。创建图表：主代理操作——使用“创建展示 [description]”模板委派；子代理返回——文件位置 + 摘要。比较图表：主代理操作——使用“比较 [A] 与 [B]”模板委派；子代理返回——关键差异（非原始 JSON）。
Token 分析（为何重要）
来自基线测试的真实数据：单个大文件——无委派 22k tokens（45% 预算），有委派约 500 tokens（子代理摘要），节省 98%。两文件比较——无委派 18k tokens（9% 预算），有委派约 800 tokens（差异摘要），节省 96%。修改任务——无委派 14k tokens（7% 预算），有委派约 300 tokens（确认），节省 98%。上下文污染影响：读取所有 7 个项目图表：67k tokens（200k 预算的 33%）；使用委派：约 2k tokens（隔离在子代理中）；节省：保留 97% 上下文预算。
实现示例
错误（直接读取）：用户：“detailed-architecture.excalidraw.json 中展示了什么架构？”代理：让我读取该文件……[将 22k tokens 读入主上下文]。正确（子代理委派）：用户：“detailed-architecture.excalidraw.json 中展示了什么架构？”代理：我将使用子代理提取架构细节。[使用通用子代理分派 Task 工具] 任务：提取并解释 .ryanquinn3/ticketing/detailed-architecture.excalidraw.json 中的组件。[接收约 500 token 的摘要，包含组件列表和关系] [向用户回复架构解释，主上下文得以保留]。
为何“直接的 JSON”无关紧要
代理常辩解：“格式很简单，我可以直接读取。”问题不在于复杂性，而在于冗长：简单结构但每个元素有 20 多个属性；重复的元数据（seed、version、nonce、roughness）；定位数据（x、y、width、height）在语义上无用；视觉样式（strokeColor、opacity、fillStyle）与内容无关。Token 成本来自数量，而非复杂性。即使“直接”的 JSON 也会消耗 4k-22k tokens，因为：79 个元素 × 约 280 tokens/元素 = 22k tokens；大多数 tokens 是元数据噪声；只有文本标签和关系重要（约 10% 的内容）。
铁律
主代理绝不读取 Excalidraw 文件。没有例外。不适用于：“快速检查”、“小文件”、“理解格式”、“一次性分析”、“最优效率”。始终委派。通过子代理隔离是免费的。