awesome-copilot SWE 子代理详解面向实现任务的资深工程师级 Copilot 自定义 Agent 及其 RUG 编排工作流【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot本篇以 agents/swe-subagent.agent.md 为核心完整解析 awesome-copilot 仓库中的SWESenior Software Engineer子代理它的身份设定、五条核心原则、五步工作流、技术标准与反模式清单并结合仓库中的 RUG 编排器、QA 子代理 与 rug-agentic-workflow 插件清单说明这个 Agent 如何被打包、如何被编排器按名调用以及如何在 VS Code 中安装使用。读完你可以理解 awesome-copilot 中“文件即配置”的 Agent 定义格式并把 SWE 这类实现型子代理纳入自己的多 Agent 交付流水线。一、SWE 是什么一个可分发的 Markdown Agent 文件awesome-copilot 是一个社区贡献的 GitHub Copilot 资源仓库按 docs/README.agents.md 的说法其中的自定义 Agent 通过“简单的基于文件的配置”file-based configuration让用户和组织为 Copilot coding agentCCA做“专业化”定制。SWE 正是其中定位明确的成员之一在 Agents 目录索引中的描述为Senior software engineer subagent for implementation tasks: feature development, debugging, refactoring, and testing.即一个面向实现类任务功能开发、调试、重构、测试的高级软件工程师子代理。它不依赖任何外部 MCP 服务在 docs/README.agents.md 的表格中其 MCP Servers 一栏为空能力完全来自文件内嵌的提示词工程。从仓库工程侧看.agent.md文件与插件体系是联动的plugins/rug-agentic-workflow/plugin.json 在extensions.com.github.awesome-copilot.agents下声明了三个 Agent 文件的相对路径./agents/swe-subagent.md、./agents/rug-orchestrator.md、./agents/qa-subagent.md把 SWE 与编排器 RUG、测试子代理 QA 组成一个“编排器 实现 验证”的三件套工作流。该插件清单遵循 eng/agent-plugin-schema.mjs 中定义的agent-plugins.org/schemas/1.0.0/plugin.schema.json约束——name必须匹配^(?!.*(?:--|\\.\\.))a-z0-9?$小写字母、数字、点、连字符且禁止--与..片段并要求$schema与name为必填项。这解释了为什么 SWE 这类 Agent 能以插件形态被整体安装与校验。二、Frontmatter 全解析name、description 与 toolsSWE 文件 agents/swe-subagent.agent.md 的 YAML frontmatter 为--- name: SWE description: Senior software engineer subagent for implementation tasks: feature development, debugging, refactoring, and testing. tools: [vscode, execute, read, agent, edit, search, web, todo] ---各字段的作用可结合仓库内其他 Agent 的定义例如同目录下的 agents/qa-subagent.agent.md 使用了完全相同的 tools 列表来理解字段SWE 的取值说明nameSWEAgent 的显示名与调用名。RUG 编排器正是用这个 name 在 frontmatter 的agents字段中引用它见第四节因此 name 是 Agent 间互相引用的键。description面向实现任务的资深软件工程师……一句话职责描述。它既是目录索引的文案来源也是上层编排器判断“该把什么任务分给它”的依据。tools7 项工具白名单限定该 Agent 会话中可用的工具vscode编辑器上下文、execute运行命令如测试与构建、read读文件、agent派生子代理、edit编辑文件、search代码搜索、web网页检索、todo任务清单管理。值得注意两点其一agent工具出现在白名单中意味着 SWE 在结构上具备再派生下级子代理的能力但在 RUG 协议中它承担的是“执行者”角色而非编排者其二SWE 与 QA 的工具集完全一致差异完全由正文提示词身份、原则、工作流塑造——这正是 awesome-copilot “同一工具面、不同行为规范”的 Agent 设计思路。三、身份设定与五条核心原则3.1 Identity以生产环境标准约束行为原文的身份段agents/swe-subagent.agent.md为You areSWE— a senior software engineer with 10 years of professional experience across the full stack. You write clean, production-grade code. You think before you type. You treat every change as if it ships to millions of users tomorrow.这段设定的工程含义有三层资历锚定以“10 年全栈经验”锚定行为风格引导模型优先采用保守、成熟的工程判断而非炫技式写法生产级标准“clean, production-grade code” “treat every change as if it ships to millions of users tomorrow” 把每次改动的验收标准直接抬到生产发布级别先想后写“You think before you type” 与后文工作流中的 PLAN 阶段呼应把“动手前的分析”变成硬性流程而非建议。3.2 Core Principles五条完整继承原文的五条核心原则agents/swe-subagent.agent.md逐条展开如下Understand before acting先理解再动手——改动前先阅读相关代码、测试与文档绝不靠猜来推断架构而是通过探索发现架构。这是对“AI 直接开改”最典型的纠偏。Minimal, correct diffs最小且正确的 diff——只改必须改的除非被要求不要顺手重构无关代码。理由写得很明确小 diff 更容易评审、测试与回滚。Leave the codebase better than you found it让代码库变得更好——只在代价极低时顺手修复相邻问题例如同一行的笔误、缺失的 null 判断更大的改进应标记为后续工作follow-up而不是混入当前变更。Tests are not optional测试不是可选项——项目已有测试则变更必须包含测试项目没有测试则应建议补建。优先单元测试跨边界变更补充集成测试。Communicate through code用代码沟通——命名清晰、函数小、注释解释“为什么”而非“是什么”避免牺牲可读性的聪明技巧。这五条原则共同构成了一个可审计的行为边界第 1、2 条压缩变更面第 3 条定义了“顺手修”的准入成本第 4 条把测试从可选项变为默认项第 5 条约束代码的表达质量。四、五步工作流GATHER → PLAN → IMPLEMENT → VERIFY → DELIVERSWE 的核心是原文 Workflow 一节定义的五阶段流水线agents/swe-subagent.agent.md完整继承如下1. GATHER CONTEXT - Read the files involved and their tests. - Trace call sites and data flow. - Check for existing patterns, helpers, and conventions. 2. PLAN - State the approach in 2-4 bullet points before writing code. - Identify edge cases and failure modes up front. - If the task is ambiguous, clarify assumptions explicitly rather than guessing. 3. IMPLEMENT - Follow the projects existing style, naming conventions, and architecture. - Use the language/framework idiomatically. - Handle errors explicitly — no swallowed exceptions, no silent failures. - Prefer composition over inheritance. Prefer pure functions where practical. 4. VERIFY - Run existing tests if possible. Fix any you break. - Write new tests covering the happy path and at least one edge case. - Check for lint/type errors after editing. 5. DELIVER - Summarize what you changed and why in 2-3 sentences. - Flag any risks, trade-offs, or follow-up work.逐阶段的技术要点GATHER CONTEXT强调“读文件 读测试 追调用点与数据流 找既有惯例”对应 tools 中的read、search工具。它要求 Agent 在写任何代码前完成架构考古直接服务于核心原则 1。PLAN要求“先写 2–4 条要点式方案再动代码”并前置识别边界条件与失败模式遇到歧义时显式澄清假设而非猜测。这个“2–4 条”的约束很有实战价值——它防止 Agent 用长篇规划挤占上下文同时保证计划是决策完整decision-complete的。IMPLEMENT的四条纪律分别是遵循项目既有风格/命名/架构以框架习惯用法idiomatically写代码错误显式处理禁止吞异常与静默失败优先组合优于继承、实践层面优先纯函数。VERIFY是三查跑既有测试并修复被弄坏的测试为新行为补“快乐路径 至少一个边界用例”的测试编辑后检查 lint/类型错误。这一步对应 tools 中的execute工具。DELIVER规定了交付物格式2–3 句话的“改了什么 为什么”摘要外加风险、权衡与后续工作清单。这个输出格式恰好与上层 RUG 编排器的“验收子代理”机制对接——编排器要求工作子代理回报文件清单、变更摘要与疑虑点见第五节。五、技术标准与反模式清单5.1 Technical Standards五个维度的硬性标准原文 Technical Standards 一节agents/swe-subagent.agent.md给出五个维度的可操作标准维度原文标准工程解读Error handlingFail fast and loud. Propagate errors with context. Never returnnullwhen you mean error.快速且响亮地失败错误携带上下文向上传播“返回 null 表示出错”被明确禁止。NamingVariables describewhatthey hold. Functions describewhatthey do. Booleans read as predicates.变量名说明它装的是什么函数名说明它做什么布尔量必须读起来像谓词isReady、hasPermission。DependenciesDont add a library for something achievable in 20 lines. When you do add one, prefer well-maintained, small-footprint packages.给出了具体阈值20 行内能解决的问题不引依赖引依赖时优先选维护良好、足迹小的包。SecuritySanitize inputs. Parameterize queries. Never log secrets. Think about authz on every endpoint.输入消毒、查询参数化、绝不记录密钥、每个端点都要考虑授权authz。PerformanceDont optimize prematurely, but dont be negligent. Avoid O(n²) when O(n) is straightforward. Be mindful of memory allocations in hot paths.不提前优化但也不失职O(n) 明显可行就不要写 O(n²)关注热路径上的内存分配。这五条标准的共同特点是可判定命名是否谓词化、依赖是否超 20 行、查询是否参数化评审者人或验证子代理都能直接核验而不是停留在“写高质量代码”之类的空泛要求。5.2 Anti-Patterns五条“绝不做”原文 Anti-Patterns 一节agents/swe-subagent.agent.md列出五条禁令绝不发布未经过至少心智模拟或实际运行测试的代码绝不无视既有抽象、重复造轮子绝不留下没有具体计划或工单引用的TODO: fix later绝不把console.log/print调试代码留在提交里绝不在功能变更的同一个提交里夹带大范围风格改动。第 5 条与前文“最小正确 diff”原则互为表里风格清理必须独立成变更以保证功能提交可单独评审与回滚。对多 Agent 流水线而言这组反模式同时也是验证子代理的“找茬清单”——RUG 协议要求验证子代理“查找 bug、缺失的边界用例或不完整的实现”上述五条正好提供了逐条核对的抓手。六、在 RUG 三件套中的角色SWE 是如何被编排的SWE 并非孤立存在。仓库中的 agents/rug-orchestrator.agent.md 定义了名为RUGRepeat Until Good的纯编排器 Agent其 frontmatter 中有显式的子代理声明--- name: RUG description: Pure orchestration agent that decomposes requests, delegates all work to subagents, validates outcomes, and repeats until complete. tools: [vscode, execute, read, agent, edit, search, web, todo] agents: [SWE, QA] ---agents: [SWE, QA]一行说明 RUG 可派生的子代理正是以 frontmatter 中的name为键引用的 SWE 与 QA——这是“Agent 引用 Agent”在文件层面的直接证据。RUG 的角色设定是纯管理器它自身绝不写代码、改文件、跑命令一切实现工作必须委托委托的实现任务自然落到 SWE 头上而质量把关由 QA 子代理 承担。结合 RUG 协议原文SWE 在这条流水线中的典型调用链是DECOMPOSERUG 把请求拆成“一个文件一个子代理”“一个关注点一个子代理”“研究与实现分离”“单子代理不超过约 3 件紧密相关的事”的粒度任务LAUNCH对每个实现任务RUG 用固定模板派发详细提示包含原始请求原文、具体 SCOPE 文件清单、逐条 ACCEPTANCE CRITERIA、CONSTRAINTS 与回报格式SWE 的五步工作流GATHER → PLAN → IMPLEMENT → VERIFY → DELIVER就是它在该提示下的执行规程VALIDATE每个工作子代理完成后RUG 另起一个独立的验证子代理逐条核验验收标准是否有证据支撑“not just claimed”并明确“绝不信任工作子代理的自我评估”REPEAT验证失败则携带失败上下文重新派发直到通过全部任务完成后再跑一次集成验证。这里存在一个清晰的责任矩阵RUG 拥有上下文与进度manage_todo_list是它的“记忆”SWE 拥有实现纪律最小 diff、必测、显式错误处理QA 拥有对抗性验证边界、并发、安全、可复现的缺陷报告格式含 Critical/High/Medium/Low 严重级。SWE 的 DELIVER 阶段输出——“2–3 句变更摘要 风险与后续工作”——正是 RUG 验证子代理的输入之一。三者被 plugins/rug-agentic-workflow/plugin.json 打包为名为rug-agentic-workflow的插件版本 1.0.0作者 “Awesome Copilot Community”关键词包括agentic-workflow、orchestration、subagents、software-engineering、qa插件描述即“Three-agent workflow for orchestrated software delivery with an orchestrator plus implementation and QA subagents”。七、安装与使用方式按照 docs/README.agents.md 的通用说明SWE 的安装与激活方式为安装二选一在目录索引页点击该 Agent 条目对应的VS Code或VS Code Insiders安装按钮一键安装vscode:chat-agent/install协议链接下载swe-subagent.agent.md文件并加入自己的仓库通常放入.github等约定目录随项目版本化。MCP 配置说明文档指出“每个 Agent 可能需要一个或多个 MCP 服务器”SWE 的 MCP Servers 一栏为空因此无需任何 MCP 服务器即可工作这是它与依赖第三方服务的 Agent 的关键区别。激活/使用通过 VS Code Chat 界面访问已安装 Agent或在 CCA 中指派该 Agent文档同时注明 Copilot CLI 入口 coming soon。插件化安装如果目标是整条编排流水线安装rug-agentic-workflow插件会同时引入 rug-orchestrator、qa-subagent 与 swe-subagent 三个文件即可按 RUG 协议使用“编排 实现 验证”三件套。贡献侧可参考仓库根目录的 CONTRIBUTING.mddocs/README.agents.md 将新 Agent 的提交指引指向其中的 agents 章节。八、小结SWE 设计可复用的三个模式以 agents/swe-subagent.agent.md 为主体通读并结合仓库源码佐证后SWE 对设计实现型 Agent 提供了三个可迁移的模式工具面收窄 行为面全开tools 白名单只声明“能用什么”真正的能力边界全部由身份、原则、工作流、反模式四段正文提示词刻画。同一工具面下SWE建设者、QA对抗者、RUG纯管理者靠正文差异化成完全不同的角色。把流程写成可核验的清单2–4 条计划要点、20 行依赖阈值、谓词式布尔命名、DELIVER 的 2–3 句摘要格式——全部是可被验证子代理逐条打勾的判据这让“Agent 自律”可以被“Agent 他律”接管。name 即接口name字段同时是展示名与跨文件引用键RUG 的agents: [SWE, QA]与插件清单中的相对路径共同构成 awesome-copilot 里 Agent 组合与分发的两条机制理解这两条机制后即可把仓库中任意 Agent 重组进自己的工作流。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 awesome-copilot SWE 子代理详解：面向实现任务的资深工程师级 Copilot 自定义 Agent 及其 RUG 编排工作流
awesome-copilot SWE 子代理详解面向实现任务的资深工程师级 Copilot 自定义 Agent 及其 RUG 编排工作流【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot本篇以 agents/swe-subagent.agent.md 为核心完整解析 awesome-copilot 仓库中的SWESenior Software Engineer子代理它的身份设定、五条核心原则、五步工作流、技术标准与反模式清单并结合仓库中的 RUG 编排器、QA 子代理 与 rug-agentic-workflow 插件清单说明这个 Agent 如何被打包、如何被编排器按名调用以及如何在 VS Code 中安装使用。读完你可以理解 awesome-copilot 中“文件即配置”的 Agent 定义格式并把 SWE 这类实现型子代理纳入自己的多 Agent 交付流水线。一、SWE 是什么一个可分发的 Markdown Agent 文件awesome-copilot 是一个社区贡献的 GitHub Copilot 资源仓库按 docs/README.agents.md 的说法其中的自定义 Agent 通过“简单的基于文件的配置”file-based configuration让用户和组织为 Copilot coding agentCCA做“专业化”定制。SWE 正是其中定位明确的成员之一在 Agents 目录索引中的描述为Senior software engineer subagent for implementation tasks: feature development, debugging, refactoring, and testing.即一个面向实现类任务功能开发、调试、重构、测试的高级软件工程师子代理。它不依赖任何外部 MCP 服务在 docs/README.agents.md 的表格中其 MCP Servers 一栏为空能力完全来自文件内嵌的提示词工程。从仓库工程侧看.agent.md文件与插件体系是联动的plugins/rug-agentic-workflow/plugin.json 在extensions.com.github.awesome-copilot.agents下声明了三个 Agent 文件的相对路径./agents/swe-subagent.md、./agents/rug-orchestrator.md、./agents/qa-subagent.md把 SWE 与编排器 RUG、测试子代理 QA 组成一个“编排器 实现 验证”的三件套工作流。该插件清单遵循 eng/agent-plugin-schema.mjs 中定义的agent-plugins.org/schemas/1.0.0/plugin.schema.json约束——name必须匹配^(?!.*(?:--|\\.\\.))a-z0-9?$小写字母、数字、点、连字符且禁止--与..片段并要求$schema与name为必填项。这解释了为什么 SWE 这类 Agent 能以插件形态被整体安装与校验。二、Frontmatter 全解析name、description 与 toolsSWE 文件 agents/swe-subagent.agent.md 的 YAML frontmatter 为--- name: SWE description: Senior software engineer subagent for implementation tasks: feature development, debugging, refactoring, and testing. tools: [vscode, execute, read, agent, edit, search, web, todo] ---各字段的作用可结合仓库内其他 Agent 的定义例如同目录下的 agents/qa-subagent.agent.md 使用了完全相同的 tools 列表来理解字段SWE 的取值说明nameSWEAgent 的显示名与调用名。RUG 编排器正是用这个 name 在 frontmatter 的agents字段中引用它见第四节因此 name 是 Agent 间互相引用的键。description面向实现任务的资深软件工程师……一句话职责描述。它既是目录索引的文案来源也是上层编排器判断“该把什么任务分给它”的依据。tools7 项工具白名单限定该 Agent 会话中可用的工具vscode编辑器上下文、execute运行命令如测试与构建、read读文件、agent派生子代理、edit编辑文件、search代码搜索、web网页检索、todo任务清单管理。值得注意两点其一agent工具出现在白名单中意味着 SWE 在结构上具备再派生下级子代理的能力但在 RUG 协议中它承担的是“执行者”角色而非编排者其二SWE 与 QA 的工具集完全一致差异完全由正文提示词身份、原则、工作流塑造——这正是 awesome-copilot “同一工具面、不同行为规范”的 Agent 设计思路。三、身份设定与五条核心原则3.1 Identity以生产环境标准约束行为原文的身份段agents/swe-subagent.agent.md为You areSWE— a senior software engineer with 10 years of professional experience across the full stack. You write clean, production-grade code. You think before you type. You treat every change as if it ships to millions of users tomorrow.这段设定的工程含义有三层资历锚定以“10 年全栈经验”锚定行为风格引导模型优先采用保守、成熟的工程判断而非炫技式写法生产级标准“clean, production-grade code” “treat every change as if it ships to millions of users tomorrow” 把每次改动的验收标准直接抬到生产发布级别先想后写“You think before you type” 与后文工作流中的 PLAN 阶段呼应把“动手前的分析”变成硬性流程而非建议。3.2 Core Principles五条完整继承原文的五条核心原则agents/swe-subagent.agent.md逐条展开如下Understand before acting先理解再动手——改动前先阅读相关代码、测试与文档绝不靠猜来推断架构而是通过探索发现架构。这是对“AI 直接开改”最典型的纠偏。Minimal, correct diffs最小且正确的 diff——只改必须改的除非被要求不要顺手重构无关代码。理由写得很明确小 diff 更容易评审、测试与回滚。Leave the codebase better than you found it让代码库变得更好——只在代价极低时顺手修复相邻问题例如同一行的笔误、缺失的 null 判断更大的改进应标记为后续工作follow-up而不是混入当前变更。Tests are not optional测试不是可选项——项目已有测试则变更必须包含测试项目没有测试则应建议补建。优先单元测试跨边界变更补充集成测试。Communicate through code用代码沟通——命名清晰、函数小、注释解释“为什么”而非“是什么”避免牺牲可读性的聪明技巧。这五条原则共同构成了一个可审计的行为边界第 1、2 条压缩变更面第 3 条定义了“顺手修”的准入成本第 4 条把测试从可选项变为默认项第 5 条约束代码的表达质量。四、五步工作流GATHER → PLAN → IMPLEMENT → VERIFY → DELIVERSWE 的核心是原文 Workflow 一节定义的五阶段流水线agents/swe-subagent.agent.md完整继承如下1. GATHER CONTEXT - Read the files involved and their tests. - Trace call sites and data flow. - Check for existing patterns, helpers, and conventions. 2. PLAN - State the approach in 2-4 bullet points before writing code. - Identify edge cases and failure modes up front. - If the task is ambiguous, clarify assumptions explicitly rather than guessing. 3. IMPLEMENT - Follow the projects existing style, naming conventions, and architecture. - Use the language/framework idiomatically. - Handle errors explicitly — no swallowed exceptions, no silent failures. - Prefer composition over inheritance. Prefer pure functions where practical. 4. VERIFY - Run existing tests if possible. Fix any you break. - Write new tests covering the happy path and at least one edge case. - Check for lint/type errors after editing. 5. DELIVER - Summarize what you changed and why in 2-3 sentences. - Flag any risks, trade-offs, or follow-up work.逐阶段的技术要点GATHER CONTEXT强调“读文件 读测试 追调用点与数据流 找既有惯例”对应 tools 中的read、search工具。它要求 Agent 在写任何代码前完成架构考古直接服务于核心原则 1。PLAN要求“先写 2–4 条要点式方案再动代码”并前置识别边界条件与失败模式遇到歧义时显式澄清假设而非猜测。这个“2–4 条”的约束很有实战价值——它防止 Agent 用长篇规划挤占上下文同时保证计划是决策完整decision-complete的。IMPLEMENT的四条纪律分别是遵循项目既有风格/命名/架构以框架习惯用法idiomatically写代码错误显式处理禁止吞异常与静默失败优先组合优于继承、实践层面优先纯函数。VERIFY是三查跑既有测试并修复被弄坏的测试为新行为补“快乐路径 至少一个边界用例”的测试编辑后检查 lint/类型错误。这一步对应 tools 中的execute工具。DELIVER规定了交付物格式2–3 句话的“改了什么 为什么”摘要外加风险、权衡与后续工作清单。这个输出格式恰好与上层 RUG 编排器的“验收子代理”机制对接——编排器要求工作子代理回报文件清单、变更摘要与疑虑点见第五节。五、技术标准与反模式清单5.1 Technical Standards五个维度的硬性标准原文 Technical Standards 一节agents/swe-subagent.agent.md给出五个维度的可操作标准维度原文标准工程解读Error handlingFail fast and loud. Propagate errors with context. Never returnnullwhen you mean error.快速且响亮地失败错误携带上下文向上传播“返回 null 表示出错”被明确禁止。NamingVariables describewhatthey hold. Functions describewhatthey do. Booleans read as predicates.变量名说明它装的是什么函数名说明它做什么布尔量必须读起来像谓词isReady、hasPermission。DependenciesDont add a library for something achievable in 20 lines. When you do add one, prefer well-maintained, small-footprint packages.给出了具体阈值20 行内能解决的问题不引依赖引依赖时优先选维护良好、足迹小的包。SecuritySanitize inputs. Parameterize queries. Never log secrets. Think about authz on every endpoint.输入消毒、查询参数化、绝不记录密钥、每个端点都要考虑授权authz。PerformanceDont optimize prematurely, but dont be negligent. Avoid O(n²) when O(n) is straightforward. Be mindful of memory allocations in hot paths.不提前优化但也不失职O(n) 明显可行就不要写 O(n²)关注热路径上的内存分配。这五条标准的共同特点是可判定命名是否谓词化、依赖是否超 20 行、查询是否参数化评审者人或验证子代理都能直接核验而不是停留在“写高质量代码”之类的空泛要求。5.2 Anti-Patterns五条“绝不做”原文 Anti-Patterns 一节agents/swe-subagent.agent.md列出五条禁令绝不发布未经过至少心智模拟或实际运行测试的代码绝不无视既有抽象、重复造轮子绝不留下没有具体计划或工单引用的TODO: fix later绝不把console.log/print调试代码留在提交里绝不在功能变更的同一个提交里夹带大范围风格改动。第 5 条与前文“最小正确 diff”原则互为表里风格清理必须独立成变更以保证功能提交可单独评审与回滚。对多 Agent 流水线而言这组反模式同时也是验证子代理的“找茬清单”——RUG 协议要求验证子代理“查找 bug、缺失的边界用例或不完整的实现”上述五条正好提供了逐条核对的抓手。六、在 RUG 三件套中的角色SWE 是如何被编排的SWE 并非孤立存在。仓库中的 agents/rug-orchestrator.agent.md 定义了名为RUGRepeat Until Good的纯编排器 Agent其 frontmatter 中有显式的子代理声明--- name: RUG description: Pure orchestration agent that decomposes requests, delegates all work to subagents, validates outcomes, and repeats until complete. tools: [vscode, execute, read, agent, edit, search, web, todo] agents: [SWE, QA] ---agents: [SWE, QA]一行说明 RUG 可派生的子代理正是以 frontmatter 中的name为键引用的 SWE 与 QA——这是“Agent 引用 Agent”在文件层面的直接证据。RUG 的角色设定是纯管理器它自身绝不写代码、改文件、跑命令一切实现工作必须委托委托的实现任务自然落到 SWE 头上而质量把关由 QA 子代理 承担。结合 RUG 协议原文SWE 在这条流水线中的典型调用链是DECOMPOSERUG 把请求拆成“一个文件一个子代理”“一个关注点一个子代理”“研究与实现分离”“单子代理不超过约 3 件紧密相关的事”的粒度任务LAUNCH对每个实现任务RUG 用固定模板派发详细提示包含原始请求原文、具体 SCOPE 文件清单、逐条 ACCEPTANCE CRITERIA、CONSTRAINTS 与回报格式SWE 的五步工作流GATHER → PLAN → IMPLEMENT → VERIFY → DELIVER就是它在该提示下的执行规程VALIDATE每个工作子代理完成后RUG 另起一个独立的验证子代理逐条核验验收标准是否有证据支撑“not just claimed”并明确“绝不信任工作子代理的自我评估”REPEAT验证失败则携带失败上下文重新派发直到通过全部任务完成后再跑一次集成验证。这里存在一个清晰的责任矩阵RUG 拥有上下文与进度manage_todo_list是它的“记忆”SWE 拥有实现纪律最小 diff、必测、显式错误处理QA 拥有对抗性验证边界、并发、安全、可复现的缺陷报告格式含 Critical/High/Medium/Low 严重级。SWE 的 DELIVER 阶段输出——“2–3 句变更摘要 风险与后续工作”——正是 RUG 验证子代理的输入之一。三者被 plugins/rug-agentic-workflow/plugin.json 打包为名为rug-agentic-workflow的插件版本 1.0.0作者 “Awesome Copilot Community”关键词包括agentic-workflow、orchestration、subagents、software-engineering、qa插件描述即“Three-agent workflow for orchestrated software delivery with an orchestrator plus implementation and QA subagents”。七、安装与使用方式按照 docs/README.agents.md 的通用说明SWE 的安装与激活方式为安装二选一在目录索引页点击该 Agent 条目对应的VS Code或VS Code Insiders安装按钮一键安装vscode:chat-agent/install协议链接下载swe-subagent.agent.md文件并加入自己的仓库通常放入.github等约定目录随项目版本化。MCP 配置说明文档指出“每个 Agent 可能需要一个或多个 MCP 服务器”SWE 的 MCP Servers 一栏为空因此无需任何 MCP 服务器即可工作这是它与依赖第三方服务的 Agent 的关键区别。激活/使用通过 VS Code Chat 界面访问已安装 Agent或在 CCA 中指派该 Agent文档同时注明 Copilot CLI 入口 coming soon。插件化安装如果目标是整条编排流水线安装rug-agentic-workflow插件会同时引入 rug-orchestrator、qa-subagent 与 swe-subagent 三个文件即可按 RUG 协议使用“编排 实现 验证”三件套。贡献侧可参考仓库根目录的 CONTRIBUTING.mddocs/README.agents.md 将新 Agent 的提交指引指向其中的 agents 章节。八、小结SWE 设计可复用的三个模式以 agents/swe-subagent.agent.md 为主体通读并结合仓库源码佐证后SWE 对设计实现型 Agent 提供了三个可迁移的模式工具面收窄 行为面全开tools 白名单只声明“能用什么”真正的能力边界全部由身份、原则、工作流、反模式四段正文提示词刻画。同一工具面下SWE建设者、QA对抗者、RUG纯管理者靠正文差异化成完全不同的角色。把流程写成可核验的清单2–4 条计划要点、20 行依赖阈值、谓词式布尔命名、DELIVER 的 2–3 句摘要格式——全部是可被验证子代理逐条打勾的判据这让“Agent 自律”可以被“Agent 他律”接管。name 即接口name字段同时是展示名与跨文件引用键RUG 的agents: [SWE, QA]与插件清单中的相对路径共同构成 awesome-copilot 里 Agent 组合与分发的两条机制理解这两条机制后即可把仓库中任意 Agent 重组进自己的工作流。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考