Plate Compound Engineering Tree为编辑器 monorepo 裁剪的 Agent 工作流树实战解析【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate导读本文基于 Plate 仓库中的docs/analysis/compound-engineering-tree.md分析文档完整还原 Plate 如何从EveryInc/compound-engineering-plugin插件库中挑选出 21 个 CE Agent并将它们分别接入task常规任务与major-task重量级任务两条工作流通道。读完本文你将掌握 Plate 的 Agent 树裁剪方法论、每个已安装 Agent 的职责与触发条件、被拒绝 Agent 的拒绝理由以及这套精简严肃研究脊柱 条件化评审模式在编辑器 monorepo 中的落地方式。一、背景CE 插件是什么Plate 为什么需要裁剪Compound EngineeringCE是一套面向 Agent 工作流的复合工程插件体系包含大量承担研究、评审、文档评审、工作流编排等角色的 Agent。Plate 并未照单全收而是基于自身实际情况做了一份Plate 专属的 CE Agent 树精简版Plate CE set。这份精简树有四个事实锚点全部可以在仓库中找到skiller-lock.json记录了 Plate 实际从EveryInc/compound-engineering-plugin安装的 21 个 Agent 及其源码相对路径.agents/rules/task.mdc默认任务通道lean lane.agents/rules/major-task.mdc重量级架构/对比/基准/提案通道.agents/rules/agent-browser-issue.mdc浏览器并列升级通道AGENTS.md显式排除清单Plate-specific CE exclusions。正如原文档所言这不是整个插件动物园而是 Plate 实际保留的那一片、它被接在哪里、以及为什么其余部分保持停用。理解这份树关键在于理解 Plate 的取舍逻辑——它是框架/编辑器 monorepo不是部署密集、数据迁移密集的产品应用因此 CE 中偏向数据面与运维面的 Agent 被整体排除。二、Plate 实际保留的 Agent 树全貌原文档给出了一棵完整的树形结构这是整篇文章的骨架。Plate CE set 由三条通道组成task lane、major-task lane、major-task 条件化文档评审通道。Plate CE set ├── task lane │ ├── ce:brainstorm │ ├── learnings-researcher │ ├── framework-docs-researcher (conditional, second-pass only) │ ├── risky-change review lane │ │ ├── ce-review │ │ ├── correctness-reviewer │ │ ├── maintainability-reviewer │ │ ├── project-standards-reviewer │ │ └── code-simplicity-reviewer │ └── agent-native parity lane │ └── agent-native-reviewer ├── major-task lane │ ├── ce:plan │ ├── learnings-researcher │ ├── repo-research-analyst │ ├── architecture-strategist │ ├── pattern-recognition-specialist │ ├── framework-docs-researcher (conditional, after local clone/source pass) │ ├── best-practices-researcher (conditional) │ ├── performance-oracle │ ├── spec-flow-analyzer │ └── issue-intelligence-analyst / git-history-analyzer (conditional) └── major-task conditional document-review pass ├── coherence-reviewer ├── feasibility-reviewer ├── scope-guardian-reviewer ├── product-lens-reviewer └── adversarial-document-reviewer从 skiller-lock.json 可以看到这 21 个 Agent 全部来自EveryInc/compound-engineering-plugin分别落在插件的agents/research/、agents/review/、agents/workflow/、agents/document-review/四个子目录中。这也印证了树的结构划分研究类、评审类、工作流类、文档评审类。三、已安装的 21 个 CE Agent 分类清单原文档按四个分类完整列出了所有已安装 Agent。下面按分类整理并标注其在skiller-lock.json中的 sourceRelPath 以作佐证Research研究类6 个Agentskiller-lock.json 中的 sourceRelPathbest-practices-researcheragents/research/best-practices-researcher.mdframework-docs-researcheragents/research/framework-docs-researcher.mdgit-history-analyzeragents/research/git-history-analyzer.mdissue-intelligence-analystagents/research/issue-intelligence-analyst.mdlearnings-researcheragents/research/learnings-researcher.mdrepo-research-analystagents/research/repo-research-analyst.mdReview评审类8 个AgentsourceRelPathagent-native-revieweragents/review/agent-native-reviewer.mdarchitecture-strategistagents/review/architecture-strategist.mdcode-simplicity-revieweragents/review/code-simplicity-reviewer.mdcorrectness-revieweragents/review/correctness-reviewer.mdmaintainability-revieweragents/review/maintainability-reviewer.mdpattern-recognition-specialistagents/review/pattern-recognition-specialist.mdperformance-oracleagents/review/performance-oracle.mdproject-standards-revieweragents/review/project-standards-reviewer.mdWorkflow工作流类1 个AgentsourceRelPathspec-flow-analyzeragents/workflow/spec-flow-analyzer.mdDocument Review文档评审类5 个AgentsourceRelPathadversarial-document-revieweragents/document-review/adversarial-document-reviewer.mdcoherence-revieweragents/document-review/coherence-reviewer.mdfeasibility-revieweragents/document-review/feasibility-reviewer.mdproduct-lens-revieweragents/document-review/product-lens-reviewer.mdscope-guardian-revieweragents/document-review/scope-guardian-reviewer.md注意spec-flow-analyzer是唯一一个 workflow 分类的 Agent它在skiller-lock.json中对应agents/workflow/spec-flow-analyzer.md。这 21 个 Agent 合计构成了 Plate 的完整 CE 保留集。四、task 通道默认任务的精简研究脊柱与条件化评审.agents/rules/task.mdc 是 Plate 的默认任务通道它直接引用了 6 个 CE Agent。原文档逐条给出了每个 Agent 的触发条件这是理解何时加载谁的关键CE 引用触发条件ce:brainstorm当任务在读完 truth source 和邻近代码后仍然糊mushy时使用即需求仍不清晰、需要发散收敛时learnings-researcher默认早期通道用于重复领域repeated domains、既有解决方案挖掘、非平凡工作framework-docs-researcher仅条件触发。必须在完成 AGENTS 要求的本地 clone/源码/docs 通道之后当第三方行为仍不清晰、不熟悉或版本敏感时使用ce-review风险变更评审通道成员correctness-reviewer同上maintainability-reviewer同上project-standards-reviewer同上code-simplicity-reviewer同上——这五者构成 risky-change review lane不是默认仅保留给高风险、大型、面向用户或架构敏感的工作agent-native-reviewer独立的条件通道。仅用于.agents/**、.claude/**、AI/工具面、命令或用户操作并列user-action parity工作配套规则agent-browser-issue.mdcCE 树之外还有一个配套规则 .agents/rules/agent-browser-issue.mdc当浏览器/工具自动化暴露出可复用的操作并列action-parity缺口时它会指示任务流加载agent-native-reviewer并把这个缺口作为真正的后续事项记录以 GitHub issue 形式打上agent:browser标签而不是一笑了之。该规则的 issue 模板要求捕获 URL、Action、Block、Expected、Actual、Repro 六个最小字段并明确排除 auth/SSO、人工关卡、站点产品 bug 和无法最小复现的一次性 flaky 噪音。task 通道不做什么原文档明确强调了 task 通道的边界这与 .agents/rules/task.mdc 的 Skill Diet 一节相互印证不默认加载完整的 CE 评审动物园不默认加载文档评审角色document-review personas不默认做架构研究除非 intake 升级到major-task。换句话说task的默认姿态是从 truth source 出发、只加载真正值得的技能、验证后再收尾评审与架构研究都是显式、条件化的。五、major-task 通道重量级工作的研究脊柱与对比边界.agents/rules/major-task.mdc 用于架构/公共 API 重设计、破坏性变更、跨包大重构、基准测试、框架对比、迁移分析、RFC/提案等框架错了代价很高的工作。它对 CE Agent 的引用同样是条件化的CE 引用触发条件ce:plan重量级工作的主规划脊柱learnings-researcher早期仓库记忆通道当历史决策有影响时使用repo-research-analyst主要工作的默认仓库扎根助手repo-grounding helperarchitecture-strategist公共 API、分层、所有权、抽象清理、跨包重构pattern-recognition-specialist仓库级模式提取、重复坏味道检测、跨包一致性分析framework-docs-researcher仅条件二次通道。本地 clone 和源码阅读优先遵循 AGENTS当官方文档是裁定第三方行为或诚实对比竞品框架的唯一途径时才介入best-practices-researcher仅当官方文档仍留缺口或任务确实需要更广的领域模式时performance-oracle显式性能/优化通道基准设计、可扩展性分析、热路径权衡、编辑器/运行时对比策略spec-flow-analyzerRFC、提案、验收标准、上线、完整性压力测试issue-intelligence-analyst或git-history-analyzer仅当 issue 波动、历史回归或设计历史影响决策时对比工作被框住而非发散major-task还把编辑器框架分析指向 docs/analysis/editor-architecture-candidates.md 作为候选地图这一设计在原文档中被明确点出这让对比工作保持有界而不是扩大成随意的框架旅游framework tourism。在major-task.mdc的 Framework Comparison 与 Performance 执行路径中同样以docs/analysis/editor-architecture-candidates.md为起点。major-task 文档评审通道条件化而非仪式化原文档强调这五个文档评审 Agent 不再是仅手工的它们被条件化地接入 major-task。关键触发规则coherence-reviewerfeasibility-reviewer显式 plan/RFC/proposal/spec 评审的默认组合scope-guardian-reviewer当抽象数量、上线形态或范围漂移嗅起来膨胀时添加product-lens-reviewer当文档包含产品框架、价值、路线图或我们是否在解决正确问题的断言时添加adversarial-document-reviewer当文档足够大、假设密集、架构密集或高风险值得对前提做压力测试时添加。规则是选择性的——major-task不会因为存在一份文档就加载全部评审者。这与 .agents/rules/major-task.mdc 中 Document Review 执行路径的第 6 条一致Keep this pass selective. Most docs should not load every reviewer.性能与对比通道证据优先原文档称这是 major-task 中最锋利的分支用于 Plate 特有的框架工作其方法论五条先定义工作负载workload把实测证据measured evidence与假设hypothesis分开对比等价工作负载而不是vibes先从仓库约束出发再谈网络观点编辑器框架性能问题的选型顺序优先Plate vs Slate直接继承压力用ProseMirror和Lexical深挖运行时或架构方向用Tiptap更多评估产品层/打包成本而非原始引擎性能用Pretext和Premirror处理分页、排版与布局感知编辑问题。在major-task.mdc中还可以看到补充项涉及 schema/profile 设计、行为编写、可移植性或行为测试标准时使用Portable Text。六、被拒绝或延期的 Agent五类理由全解原文档用五个分类解释了哪些 CE Agent 没有进入 Plate以及为什么。这是整份树最有方法论价值的部分可以看作一份负向选型清单。1. Wrong repo shape仓库形态不符6 个data-integrity-guardian、data-migration-expert、data-migrations-reviewer、schema-drift-detector、deployment-verification-agent、api-contract-reviewer理由Plate 是框架/编辑器 monorepo不是迁移密集或部署密集的产品应用这些 Agent 偏向数据面data-plane或运维关注点在 Plate 不是核心。2. Wrong stack技术栈不符3 个dhh-rails-reviewer、kieran-rails-reviewer、kieran-python-reviewer理由语言家族不符Rails/Python 评审者与 TS/React 编辑器无关装上只会增加噪音和虚假的 sophistication。3. Workflow noise工作流噪音4 个previous-comments-reviewer、pr-comment-resolver、figma-design-sync、bug-reproduction-validator理由PR 线程回放、Figma 同步和额外的浏览器验证编排不属于 Plate 的默认执行模型Plate 已有自己的 task、review 和 browser 流程。4. Overkill for default Plate use对默认使用过度9 个security-lens-reviewer、design-lens-reviewer、security-reviewer、security-sentinel、reliability-reviewer、performance-reviewer、adversarial-reviewer、julik-frontend-races-reviewer、kieran-typescript-reviewer理由其中一些确实正当legit但不足以证明默认安装的合理性Plate 想要一套精简、能自我证明价值的集合。Add one later on proof, not because the catalog exists.——日后凭证据添加而不是因为目录里存在就装。5. Orphan / not first-class yet孤儿/尚未一等公民3 个design-implementation-reviewer、ankane-readme-writer、cli-agent-readiness-reviewer理由在当前 CE 树中没有强的一等父技能不值得仅仅因为躺在那儿就把它们拉进 Plate。七、与 AGENTS.md 显式排除清单的呼应这套拒绝清单与仓库根目录 AGENTS.md 中的 Plate-specific CE exclusions 一节完全一致。AGENTS.md 明确写道不要默认安装或引用这些data-integrity-guardian、data-migration-expert、data-migrations-reviewer、schema-drift-detector、deployment-verification-agent、dhh-rails-reviewer、kieran-rails-reviewer、kieran-python-reviewer、previous-comments-reviewer、pr-comment-resolver、figma-design-sync。理由Plate 是框架/编辑器仓库数据迁移、Rails、部署、PR 线程和 Figma 工作流 Agent 大多是过度设计或形态不符。注意 AGENTS.md 的排除清单与compound-engineering-tree.md中Wrong repo shape Wrong stack Workflow noise三类存在重叠但不完全一致——AGENTS.md 收录的是前两类与 PR 线程/Figma 类共 11 个而分析文档进一步把bug-reproduction-validator、安全/可靠性评审者、孤儿 Agent 也纳入了Rejected Or Deferred的完整图景。这说明分析文档是 AGENTS.md 排除项的补充论证与扩展。八、为什么是这种形状双通道设计哲学原文档在末尾给出了 Plate 的形状设计逻辑这是整份树的为什么task保持精简用于常规 issue 执行major-task处理架构、对比、基准与提案工作而不把每个任务都变成研究马戏团。由此推导出的六条落地原则保留一条小而严肃的研究脊柱small serious research spine保留一条小而严肃的风险变更评审脊柱risky-change review spine把文档评审 Agent 条件化接在major-task之后让性能/对比工作保持显式且证据优先evidence-first拒绝数据/部署/Rails/Figma/PR 线程类sludge沉淀物结论这就是当前对 Plate 最适配的 CE 切片current best-fit CE slice。九、如何在自己的仓库复现这套裁剪如果你也想为自己的仓库做类似的 CE 裁剪可以从 Plate 的实践提炼出可操作步骤以 lockfile 为事实锚点先看安装清单Plate 中是 skiller-lock.json明确实际安装了哪些 Agent避免以为装了与实际装了的偏差以规则文件为接线图逐一核对.agents/rules/*.mdc中对每个 Agent 的引用位置与触发条件确保每个 Agent 都有明确的何时加载、何时不加载为每个通道写明不做什么Plate 在task.mdc中明确列出了三条 not-defaults这种负向声明比正向清单更能约束 Agent 的行为建立负向选型清单并给理由按仓库形态/技术栈/工作流噪音/过度设计/孤儿五个维度归档被拒绝的 Agent每条都给出可复述的理由把排除清单写进 AGENTS.md让约束成为仓库规则的一部分对应 Plate 的 Plate-specific CE exclusions而不仅仅停留在分析文档里遵循凭证据添加原则任何被拒 Agent 未来都可以在证明其价值后再引入而不是因为目录里存在就默认安装。十、延伸阅读compound-engineering-tree.md本文所依据的原始分析文档skiller-lock.json21 个 CE Agent 的安装来源与哈希记录.agents/rules/task.mdctask 通道完整规则含 Skill Diet、Review And Risk Gates.agents/rules/major-task.mdcmajor-task 通道完整规则含性能对比选型顺序.agents/rules/agent-browser-issue.mdc浏览器并列升级配套规则AGENTS.mdPlate-specific CE exclusions 显式排除清单editor-architecture-candidates.mdmajor-task 编辑器框架对比的边界地图。【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考