GSD三大内置子代理揭秘：Scout侦察、Researcher研究、Worker执行的上下文工程之道-平芜编程栈

GSD三大内置子代理揭秘：Scout侦察、Researcher研究、Worker执行的上下文工程之道

【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址: https://gitcode.com/gh_mirrors/gs/gsd-2

GSD（spec-driven development 系统）内置了三款开箱即用的子代理——Scout 侦察、Researcher 研究、Worker 执行。它们各自拥有独立的上下文窗口与精简工具集，是 GSD 让 AI 智能体长时间自主工作而"不迷路"的上下文工程核心。本文面向新手，用通俗语言带你读懂这三位"专职员工"的分工之道。

为什么需要子代理：上下文工程的第一课

想象一位工程师同时负责：翻遍整个代码库、上网查最新资料、动手写代码。他很快会"大脑过载"——对话越长，AI 的上下文窗口越满，注意力被无关信息稀释，产出质量随之下降。

GSD 的答案是分而治之：主会话（父代理）不亲自干活，而是把有边界的工作委派给子代理。每个子代理：

🪟独立上下文窗口——只装载完成任务必需的信息；
🧰精简工具集——Scout 只能读和搜，Worker 才有完整能力；
📬结构化回报——最终答案、用量数据、可复查的运行记录交回父会话。

子代理的运行状态会被持久化到本地 JSON 记录，即使中途中断也能status查看、resume续接，详见官方文档 subagents.md。

上图是 GSD 在 VS Code 中的实际工作画面：右侧 Chat 面板里，GSD Agent 正以结构化表格汇报项目进度——这正是子代理协作成果的"最后一公里"。

三位子代理的"简历"一览

子代理	定位	工具权限	典型任务
Scout	快速代码库侦察	read、grep、find、ls、bash（只读为主）	找出与任务相关的文件与关键代码
Researcher	网络信息研究员	联网搜索、bash、记忆查询	搜索并综合最新资料，附来源引用
Worker	全能执行者	全部工具	在隔离上下文中完成实现类任务

它们都定义在项目的 agents 目录下：scout.md、researcher.md、worker.md。用/subagent命令可随时列出当前会话可用的所有代理。

Scout 侦察代理：给下一个代理"压缩过的地图"

Scout 的系统提示一句话点题："你的输出将交给一个从未看过这些文件的代理"（scout.md）。

这正是最精髓的上下文工程思维——侦察成果必须自包含、可压缩、可直接交接：

三档侦察深度：Quick（只查关键文件）、Medium（顺藤摸瓜看关键片段）、Thorough（追全部依赖并核对测试）；
固定输出结构：## Files Retrieved（精确到行号的文件清单）→## Key Code（关键类型与函数）→## Architecture（组件如何连接）→## Start Here（从哪个文件入手，为什么）。

为什么强调行号与"Start Here"？因为下一个代理拿到这份"地图"后，无需重复全库扫描，直接跳到要害位置——上下文从"整个代码库"压缩为"一份带坐标的简报"。

Researcher 研究代理：只讲有出处的信息

当项目涉及外部知识（最新 API、框架新版本、行业最佳实践）时，Researcher 上场。它的策略在 researcher.md 中写得非常克制：

用 2–3 个精准查询获取广度；
综合成连贯的摘要；
每条关键结论都附来源 URL。

输出严格遵循## Summary（2–3 句概览）→## Key Findings（带来源的要点）→## Sources（编号来源列表）。它还有一条铁律："Be factual. Do not speculate beyond what the sources say."（只陈述来源所支持的事实，冲突信息要如实标注）。这种"事实锚定"让研究报告可以放心地进入下游规划上下文，而不污染后续推理。

Worker 执行代理：全能，但绝不越权

Worker 是三者中唯一拥有完整工具能力的子代理，在隔离的上下文窗口里自主完成实现、测试、修复等实际编码工作。

它的设计亮点是明确的权力边界（见 worker.md）：

❌ 不得擅自启动子代理或扮演编排者；
❌ 若任务看起来像 GSD 编排、侦察或并行派发，应立即停止并上报，提示父级改用专职代理；
✅ 完成后按## Completed/## Files Changed/## Notes结构汇报，交接时附上精确文件路径与触碰的关键函数。

一句话：Worker 是执行者而非指挥官。这种"能力全开 + 职权收紧"的组合，让主会话的编排上下文永远干净，不被执行细节淹没。

链式协作：Scout → Researcher → Worker 的上下文流水线

GSD 的subagent工具支持三种调用形态：单发（single）、并行（parallel，最多 8 个任务）、链式（chain）。链式模式用{previous}占位符把上一步输出注入下一步任务，天然构成一条上下文流水线：

{ "chain": [ { "agent": "scout", "task": "Map the checkout flow." }, { "agent": "researcher", "task": "Research current best practices for {previous}" }, { "agent": "worker", "task": "Implement the plan based on: {previous}" } ] }

三个上下文模式细节值得新手留意（subagents.md）：

参数	作用
`context: "fresh"`（默认）	子代理从"零"开始，只带自身提示词与任务——上下文最干净
`context: "fork"`	从父会话分叉，继承完整对话状态——适用于需要先前决策的任务
`isolated: true`	在 git worktree 隔离区执行，改动以补丁形式合并回主检出

在 GSD 的 auto 模式（自动驾驶）中，这条流水线被自动化了：规划阶段被策略锁定为只读侦察类代理（scout、planner、researcher 等），实现类工作则留给 Worker 单元执行——读写分离由运行时策略硬性保证，而非仅靠提示词约束（auto-mode.md）。