尧图网页设计 
面向 Claude Code 的 AI 系统集成研究 Agent拆解 GSD 的 gsd-ai-researcher 与 AI-SPEC 设计合约机制【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done在 spec-driven development 的 get-shit-doneGSD方法论中凡是涉及构建 AI 系统的阶段都会被要求先产出一份名为AI-SPEC.md的“AI 设计合约”把框架选型、实现指引、领域上下文与评测策略在规划任务之前一次性锁定。gsd-ai-researcher正是这套流水线中承担“研究选型框架官方文档、写出可直接落地的实现指导”的专职 Agent。本文将基于 agents/gsd-ai-researcher.md 的完整定义结合其上游编排工作流、决策矩阵参考文件与 AI-SPEC 模板讲解它的角色定位、输入契约、文档研究方法、执行流程与质量关卡让读者理解如何复用一个“可重复、可验证的 AI 框架调研 Agent”。一、角色定位回答“如何用选定框架正确实现这套 AI 系统”gsd-ai-researcher是 GSD 体系中的一名子 Agentsubagent其 frontmatter 定义如下name:gsd-ai-researcherdescription: 研究所选 AI 框架的官方文档产出可直接落地的实现指导——为具体使用场景提炼最佳实践、语法、核心模式与坑点撰写AI-SPEC.md的 Framework Quick Reference 与 Implementation Guidance 部分tools: Read, Write, Bash, Grep, Glob, WebFetch, WebSearch,mcp__context7__*color:#34D399用于流水线界面中标识该步骤它的核心问题role只有一个How do I correctly implement this AI system with the chosen framework?职责被严格收敛为写入AI-SPEC.md的第 3、4、4b 三节。它不负责选框架那是gsd-framework-selector的事、不负责研究业务领域那是gsd-domain-researcher的事、也不负责设计评测那是gsd-eval-planner的事。在 AI 设计合约流水线中的位置gsd-ai-researcher由/gsd:ai-integration-phase编排命令触发对应 commands/gsd/ai-integration-phase.md。整条流水线是四步顺序执行Select Framework → Research Docs → Research Domain → Design Eval Strategy → Done gsd-framework-selector → gsd-ai-researcher → gsd-domain-researcher → gsd-eval-planner编排器在执行时会先展示“◆ Step 2/4 — Researching {framework} docs AI systems best practices...”的进度横幅然后以objective、files_to_read与input三段式消息把gsd-ai-researcherspawn 出来。其中files_to_read固定包含已初始化的{ai_spec_path}即AI-SPEC.md与可选的 CONTEXT.md让研究员在动手前能感知当前阶段的整体目标与既有约束。四名 Agent 在AI-SPEC.md上写的是互不重叠的区段framework-selector提供决策依据Section 2ai-researcher写实现侧内容Sections 3/4/4bdomain-researcher写领域上下文Section 1beval-planner写评测侧内容Sections 5–7。二、输入契约与必读资料gsd-ai-researcher通过input接收六个结构化字段全部由编排器从上游framework-selector的输出解析而来输入字段含义示例来源framework已选定框架名与版本LlamaIndex v0.10.xsystem_type系统类型枚举RAG / Multi-Agent / Conversational / Extraction / Autonomous / Content / Code / Hybridmodel_provider模型厂商承诺OpenAI / Anthropic / Model-agnosticai_spec_pathAI-SPEC.md的目标路径{phase_dir}/{padded_phase}-AI-SPEC.mdphase_context阶段名与目标Phase 3: ... — ...context_path存在的 CONTEXT.md 路径可选值得注意的强制约束一旦 prompt 中出现required_readingAgent 必须在做任何其他事之前读完全部列出的文件。对gsd-ai-researcher而言必读文件是~/.claude/get-shit-done/references/ai-frameworks.md安装仓库中位于 get-shit-done/references/ai-frameworks.md要求先了解各框架画像与已知坑点再去拉取文档。对应地测试体系如 agent-required-reading-consistency.test.cjs会守护这类“必读引用”的完整性。必读参考AI Framework Decision Matrixai-frameworks.md 是供gsd-framework-selector与gsd-ai-researcher共享的决策矩阵提炼自官方文档、基准测试与开发者报告。研究员在写 “Common Pitfalls” 与选型背景时会引用其中的画像。例如 Quick Picks 一表给出了场景到框架的最短映射场景推荐最快跑通 AgentOpenAI 侧OpenAI Agents SDK最快跑通 Agent模型无关CrewAI生产级 RAG / 文档问答LlamaIndex复杂有状态、带分支的工作流LangGraph角色明确的多 Agent 团队CrewAI代码感知的自主 AgentAnthropicClaude Agent SDK“还不清楚需求”LangChain受监管、需要审计轨迹LangGraph企业 Microsoft/.NET 栈AutoGen/AG2Google Cloud / Gemini 团队Google ADK需显式控制的纯 NLP 管线Haystack该参考文件同时给出反模式清单例如“用 LangChain 做简单聊天机器人”“在简单线性流程上强上 LangGraph”“无视厂商锁定”等 8 条与多框架组合玩法如LangGraph LlamaIndex做带 RAG 的有状态 Agent这些内容会被ai-researcher吸收进 AI-SPEC 的 pitfalls 与集成判断中。三、文档查询方法论Context7 MCP 优先CLI 兜底这是gsd-ai-researcher最具工程特色的机制文档查询不允许因为工具缺失而跳过。查询顺序如下。1. Context7 MCP首选如果环境中存在mcp__context7__*工具按两步使用解析库 IDmcp__context7__resolve-library-id参数libraryName拉取文档mcp__context7__get-library-docs参数context7CompatibleLibraryId与topic2. CLI 回退必选兜底当 Context7 MCP 不可用时——文档明确指出这是上游 buganthropics/claude-code#13898会从带tools:frontmatter 限制的 Agent 身上剥离 MCP 工具所致——必须改用 Bash 执行ctx7CLI且输出与 MCP 等价# Step 1 — 解析库 ID npx --yes ctx7latest library name query # Step 2 — 拉取文档 npx --yes ctx7latest docs libraryId querynpx --yes ctx7latest的写法保证临时拉取最新版 CLI无需全局安装。方法论上的硬性规定是不要因为 MCP 不可用就跳过文档查询。3. 官方文档来源总表gsd-ai-researcher内置一张受支持框架的官方文档地址表documentation_sources作为 WebFetch 回退与 URL 校验的依据框架官方文档CrewAIdocs.crewai.comLlamaIndexdocs.llamaindex.aiLangChainpython.langchain.com/docsLangGraphlangchain-ai.github.io/langgraphOpenAI Agents SDKopenai.github.io/openai-agents-pythonClaude Agent SDKdocs.anthropic.com/en/docs/claude-code/sdkAutoGen / AG2ag2ai.github.io/ag2Google ADKgoogle.github.io/adk-docsHaystackdocs.haystack.deepset.ai四、执行流程四步拆解gsd-ai-researcher的执行体是一个严格的四步execution_flow每一步都有明确的产物与边界。Step 1 — fetch_docs深度优先、限量抓取规则是最多只抓 2–4 个页面优先深度而非广度典型页面组合为quickstart、与当前system_type匹配的模式页、最佳实践/坑点页。要求从中提取 6 类信息安装命令关键 import面向system_type的最小入口示例3–5 个框架抽象abstractions3–5 个坑点优先取自 GitHub issues 而非文档正文推荐目录结构Step 2 — detect_integrations识别配套依赖根据system_type与model_provider推导出所需的支撑类库并为其抓取简短的 setup 文档。例如RAG 型 → 向量数据库、embedding 模型通用 → 可观测性/tracing 工具通用 → 评测库eval library这一步决定了 Section 4 的 “Tool Use” 小节要写什么。Step 3 — write_sections_3_4写 Quick Reference 与 Implementation Guidance写入方式有铁律修改AI-SPEC.md一律使用 Write 工具创建文件绝不允许用Bash(cat EOF)或 heredoc 创建/覆盖文件且当与兄弟 Agent 共享同一文件时须只用 Edit见下文编排纪律。Section 3 — Framework Quick Reference必须包含真实安装命令、真实 import、对system_type可用的入口模式、3–5 行抽象表、附“为什么是坑”说明的坑点列表、目录结构以及带 URL 的 Sources 小节。Section 4 — Implementation Guidance需要落实到具体型号与参数指定具体模型如claude-sonnet-4-6、gpt-4o及参数核心模式写成带行内注释的代码片段并交代工具使用配置、状态管理方式与上下文窗口策略。这两节的结构化骨架在 AI-SPEC 模板中已有占位参见 get-shit-done/templates/AI-SPEC.md 的 “## 3. Framework Quick Reference” 与 “## 4. Implementation Guidance”。模板将 Section 4 细分为 Model Configuration / Core Pattern / Tool Use / State Management / Context Window Strategy 五个槽位要求研究员逐项填满。Step 4 — write_section_4bAI Systems Best PracticesSection 4b 被定义为与框架选择无关、任何构建 AI 系统的开发者都需要的横切模式但其中的示例必须绑定具体framework system_type绝不允许写成泛泛而谈。它固定包含五个子节4b.1 Structured Outputs with Pydantic—— 用 Pydantic 模型定义输出 schemaLLM 输出必须校验或重试。示例要点为当前用例写一个 Pydantic 输出模型说明框架如何集成LangChain 的.with_structured_output()、直连 API 用instructor、LlamaIndex 的PydanticOutputParser、OpenAI 的response_format重试逻辑重试几次、记什么日志、何时向上暴露错误4b.2 Async-First Design—— 讲清该框架中 async 的工作方式强调那个最常见错误例如在事件循环里调用asyncio.run()区分 streaming 与 await 的适用场景stream 服务 UXawait 服务于结构化输出校验。4b.3 Prompt Engineering Discipline—— system 与 user prompt 分离few-shot 用内联还是动态检索生产中max_tokens必须显式设定绝不无界。4b.4 Context Window Management—— 按系统类型给策略RAG 超出窗口做 rerank/截断多 Agent/对话式做摘要模式自主 Agent 依赖框架自身的 compaction 处理。4b.5 Cost and Latency Budget—— 按预期量级估算单次调用成本精确匹配缓存 语义缓存对子任务分类、路由、摘要路由到更便宜的模型。五、并发安全为什么 Step 7 与 Step 8 必须顺序执行gsd-ai-researcher与相邻的gsd-domain-researcher虽然写AI-SPEC.md的不同区段但编排工作流明确要求二者必须串行Step 7 完成后才能 spawn Step 8。原因是工具级别的 last-writer-wins 竞态两名 Agent 对共享文件修改时只能用 Edit 工具永远不能用 Write——Write 会整文件覆盖静默抹掉对方工作Edit 只改相关行。编辑前必须确认要写的区段仍是模板占位符防止重复写入。工作流中记录了问题编号 #3096对应测试 bug-3096-ai-integration-phase-parallel-race.test.cjs用于守护该“并行派发约 40% 命中率”的竞态不再复发。这一纪律对整个 Agent 编排体系通用凡是兄弟 Agent 共享文件先写后读、Edit 优先、Write 受限、区段互不重叠。六、质量关卡quality_standards 与 success_criteriaQuality Standards写代码的标准所有代码片段必须对抓取到的那个版本语法正确import 必须匹配真实包结构不允许“近似”坑点必须具体——像 “use async where supported” 这类空话被明确判为无效入口模式必须是可复制即运行copy-paste runnable禁止臆造 API 方法——不确定时标注 “verify in docs”Section 4b 示例必须对framework system_type具体化而非通用模板Success Criteria自检清单抓取官方文档 2–4 页不只首页安装命令对应当前最新稳定版入口模式能跑通对应system_type结合用例给出 3–5 个抽象给出 3–5 个带说明的具体坑点Section 3、4 已写且非空Section 4b 含该框架 system_type 的 Pydantic 示例Section 4b 覆盖 async 模式、prompt 纪律、上下文管理、成本预算Section 3 中列出 Sources这套标准与模板末尾的 16 项 Checklist如 “Framework quick reference written (install, imports, pattern, pitfalls)”形成双层校验Agent 自检是一层编排器的第 10 步 “Validate AI-SPEC Completeness” 是第二层——后者会检查 Section 3 有非空代码块、Section 4b 有 Pydantic 示例等硬性条件不满足时询问用户是否重跑特定步骤。七、把它接回更大的闭环gsd-ai-researcher的价值只有在其上下游完整运行时才最大化上游衔接commands/gsd/ai-integration-phase.md 会先执行gsd-sdk query系列命令解析阶段目录、模型解析与配置开关若配置中workflow.ai_integration_phase为 false 则直接退出随后framework-selector见 agents/gsd-framework-selector.md用一次 ≤6 问的访谈打分产出primary_framework / system_type / model_provider / eval_concerns这些正是研究员input的来源。落地产物写满的AI-SPEC.md最终被/gsd:plan-phase的规划器消费模板头部注明 “Consumed by gsd-planner and gsd-eval-auditor”把设计合约翻译成任务完成后若commit_docs开启编排器会执行git add与一次docs({phase_slug}): generate AI-SPEC.md风格的提交。测试护栏仓库在 tests/ 下有大批针对 Agent 契约的回归测试例如守护必读引用一致性、技能感知与尺寸预算的 agent-required-reading-consistency.test.cjs、agent-skills-awareness.test.cjs编排流水线本身也有 ai-evals.test.cjs 与 bug-3096-ai-integration-phase-parallel-race.test.cjs 等守护。若想观察研究员的下游评测设计可对照其兄弟 Agent agents/gsd-eval-planner.md 与参考文件 get-shit-done/references/ai-evals.md。八、小结从这份 Agent 定义可以看出 GSD 对待 “AI 系统开发” 的核心立场框架选型与评测绝不能靠事后补救。gsd-ai-researcher通过强制的文档查询路径Context7 MCP → ctx7 CLI → WebFetch、深度优先的限量抓取2–4 页、结构化的输出槽位Section 3/4/4b以及 4b 的五项横切最佳实践把“研究官方文档”这种原本模糊的活动压缩成了一条可审计、可验收、防幻觉 API 的固定流程。配合只允许 Edit 的共享文件纪律与编排器的事后完整性校验它让 AI-SPEC 从“模板占位”演变为“可直接指导 Planner 拆任务的实现契约”——这正是 spec-driven development 在 AI 工程侧最有价值的一环。【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 面向 Claude Code 的 AI 系统集成研究 Agent：拆解 GSD 的 gsd-ai-researcher 与 AI-SPEC 设计合约机制
面向 Claude Code 的 AI 系统集成研究 Agent拆解 GSD 的 gsd-ai-researcher 与 AI-SPEC 设计合约机制【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done在 spec-driven development 的 get-shit-doneGSD方法论中凡是涉及构建 AI 系统的阶段都会被要求先产出一份名为AI-SPEC.md的“AI 设计合约”把框架选型、实现指引、领域上下文与评测策略在规划任务之前一次性锁定。gsd-ai-researcher正是这套流水线中承担“研究选型框架官方文档、写出可直接落地的实现指导”的专职 Agent。本文将基于 agents/gsd-ai-researcher.md 的完整定义结合其上游编排工作流、决策矩阵参考文件与 AI-SPEC 模板讲解它的角色定位、输入契约、文档研究方法、执行流程与质量关卡让读者理解如何复用一个“可重复、可验证的 AI 框架调研 Agent”。一、角色定位回答“如何用选定框架正确实现这套 AI 系统”gsd-ai-researcher是 GSD 体系中的一名子 Agentsubagent其 frontmatter 定义如下name:gsd-ai-researcherdescription: 研究所选 AI 框架的官方文档产出可直接落地的实现指导——为具体使用场景提炼最佳实践、语法、核心模式与坑点撰写AI-SPEC.md的 Framework Quick Reference 与 Implementation Guidance 部分tools: Read, Write, Bash, Grep, Glob, WebFetch, WebSearch,mcp__context7__*color:#34D399用于流水线界面中标识该步骤它的核心问题role只有一个How do I correctly implement this AI system with the chosen framework?职责被严格收敛为写入AI-SPEC.md的第 3、4、4b 三节。它不负责选框架那是gsd-framework-selector的事、不负责研究业务领域那是gsd-domain-researcher的事、也不负责设计评测那是gsd-eval-planner的事。在 AI 设计合约流水线中的位置gsd-ai-researcher由/gsd:ai-integration-phase编排命令触发对应 commands/gsd/ai-integration-phase.md。整条流水线是四步顺序执行Select Framework → Research Docs → Research Domain → Design Eval Strategy → Done gsd-framework-selector → gsd-ai-researcher → gsd-domain-researcher → gsd-eval-planner编排器在执行时会先展示“◆ Step 2/4 — Researching {framework} docs AI systems best practices...”的进度横幅然后以objective、files_to_read与input三段式消息把gsd-ai-researcherspawn 出来。其中files_to_read固定包含已初始化的{ai_spec_path}即AI-SPEC.md与可选的 CONTEXT.md让研究员在动手前能感知当前阶段的整体目标与既有约束。四名 Agent 在AI-SPEC.md上写的是互不重叠的区段framework-selector提供决策依据Section 2ai-researcher写实现侧内容Sections 3/4/4bdomain-researcher写领域上下文Section 1beval-planner写评测侧内容Sections 5–7。二、输入契约与必读资料gsd-ai-researcher通过input接收六个结构化字段全部由编排器从上游framework-selector的输出解析而来输入字段含义示例来源framework已选定框架名与版本LlamaIndex v0.10.xsystem_type系统类型枚举RAG / Multi-Agent / Conversational / Extraction / Autonomous / Content / Code / Hybridmodel_provider模型厂商承诺OpenAI / Anthropic / Model-agnosticai_spec_pathAI-SPEC.md的目标路径{phase_dir}/{padded_phase}-AI-SPEC.mdphase_context阶段名与目标Phase 3: ... — ...context_path存在的 CONTEXT.md 路径可选值得注意的强制约束一旦 prompt 中出现required_readingAgent 必须在做任何其他事之前读完全部列出的文件。对gsd-ai-researcher而言必读文件是~/.claude/get-shit-done/references/ai-frameworks.md安装仓库中位于 get-shit-done/references/ai-frameworks.md要求先了解各框架画像与已知坑点再去拉取文档。对应地测试体系如 agent-required-reading-consistency.test.cjs会守护这类“必读引用”的完整性。必读参考AI Framework Decision Matrixai-frameworks.md 是供gsd-framework-selector与gsd-ai-researcher共享的决策矩阵提炼自官方文档、基准测试与开发者报告。研究员在写 “Common Pitfalls” 与选型背景时会引用其中的画像。例如 Quick Picks 一表给出了场景到框架的最短映射场景推荐最快跑通 AgentOpenAI 侧OpenAI Agents SDK最快跑通 Agent模型无关CrewAI生产级 RAG / 文档问答LlamaIndex复杂有状态、带分支的工作流LangGraph角色明确的多 Agent 团队CrewAI代码感知的自主 AgentAnthropicClaude Agent SDK“还不清楚需求”LangChain受监管、需要审计轨迹LangGraph企业 Microsoft/.NET 栈AutoGen/AG2Google Cloud / Gemini 团队Google ADK需显式控制的纯 NLP 管线Haystack该参考文件同时给出反模式清单例如“用 LangChain 做简单聊天机器人”“在简单线性流程上强上 LangGraph”“无视厂商锁定”等 8 条与多框架组合玩法如LangGraph LlamaIndex做带 RAG 的有状态 Agent这些内容会被ai-researcher吸收进 AI-SPEC 的 pitfalls 与集成判断中。三、文档查询方法论Context7 MCP 优先CLI 兜底这是gsd-ai-researcher最具工程特色的机制文档查询不允许因为工具缺失而跳过。查询顺序如下。1. Context7 MCP首选如果环境中存在mcp__context7__*工具按两步使用解析库 IDmcp__context7__resolve-library-id参数libraryName拉取文档mcp__context7__get-library-docs参数context7CompatibleLibraryId与topic2. CLI 回退必选兜底当 Context7 MCP 不可用时——文档明确指出这是上游 buganthropics/claude-code#13898会从带tools:frontmatter 限制的 Agent 身上剥离 MCP 工具所致——必须改用 Bash 执行ctx7CLI且输出与 MCP 等价# Step 1 — 解析库 ID npx --yes ctx7latest library name query # Step 2 — 拉取文档 npx --yes ctx7latest docs libraryId querynpx --yes ctx7latest的写法保证临时拉取最新版 CLI无需全局安装。方法论上的硬性规定是不要因为 MCP 不可用就跳过文档查询。3. 官方文档来源总表gsd-ai-researcher内置一张受支持框架的官方文档地址表documentation_sources作为 WebFetch 回退与 URL 校验的依据框架官方文档CrewAIdocs.crewai.comLlamaIndexdocs.llamaindex.aiLangChainpython.langchain.com/docsLangGraphlangchain-ai.github.io/langgraphOpenAI Agents SDKopenai.github.io/openai-agents-pythonClaude Agent SDKdocs.anthropic.com/en/docs/claude-code/sdkAutoGen / AG2ag2ai.github.io/ag2Google ADKgoogle.github.io/adk-docsHaystackdocs.haystack.deepset.ai四、执行流程四步拆解gsd-ai-researcher的执行体是一个严格的四步execution_flow每一步都有明确的产物与边界。Step 1 — fetch_docs深度优先、限量抓取规则是最多只抓 2–4 个页面优先深度而非广度典型页面组合为quickstart、与当前system_type匹配的模式页、最佳实践/坑点页。要求从中提取 6 类信息安装命令关键 import面向system_type的最小入口示例3–5 个框架抽象abstractions3–5 个坑点优先取自 GitHub issues 而非文档正文推荐目录结构Step 2 — detect_integrations识别配套依赖根据system_type与model_provider推导出所需的支撑类库并为其抓取简短的 setup 文档。例如RAG 型 → 向量数据库、embedding 模型通用 → 可观测性/tracing 工具通用 → 评测库eval library这一步决定了 Section 4 的 “Tool Use” 小节要写什么。Step 3 — write_sections_3_4写 Quick Reference 与 Implementation Guidance写入方式有铁律修改AI-SPEC.md一律使用 Write 工具创建文件绝不允许用Bash(cat EOF)或 heredoc 创建/覆盖文件且当与兄弟 Agent 共享同一文件时须只用 Edit见下文编排纪律。Section 3 — Framework Quick Reference必须包含真实安装命令、真实 import、对system_type可用的入口模式、3–5 行抽象表、附“为什么是坑”说明的坑点列表、目录结构以及带 URL 的 Sources 小节。Section 4 — Implementation Guidance需要落实到具体型号与参数指定具体模型如claude-sonnet-4-6、gpt-4o及参数核心模式写成带行内注释的代码片段并交代工具使用配置、状态管理方式与上下文窗口策略。这两节的结构化骨架在 AI-SPEC 模板中已有占位参见 get-shit-done/templates/AI-SPEC.md 的 “## 3. Framework Quick Reference” 与 “## 4. Implementation Guidance”。模板将 Section 4 细分为 Model Configuration / Core Pattern / Tool Use / State Management / Context Window Strategy 五个槽位要求研究员逐项填满。Step 4 — write_section_4bAI Systems Best PracticesSection 4b 被定义为与框架选择无关、任何构建 AI 系统的开发者都需要的横切模式但其中的示例必须绑定具体framework system_type绝不允许写成泛泛而谈。它固定包含五个子节4b.1 Structured Outputs with Pydantic—— 用 Pydantic 模型定义输出 schemaLLM 输出必须校验或重试。示例要点为当前用例写一个 Pydantic 输出模型说明框架如何集成LangChain 的.with_structured_output()、直连 API 用instructor、LlamaIndex 的PydanticOutputParser、OpenAI 的response_format重试逻辑重试几次、记什么日志、何时向上暴露错误4b.2 Async-First Design—— 讲清该框架中 async 的工作方式强调那个最常见错误例如在事件循环里调用asyncio.run()区分 streaming 与 await 的适用场景stream 服务 UXawait 服务于结构化输出校验。4b.3 Prompt Engineering Discipline—— system 与 user prompt 分离few-shot 用内联还是动态检索生产中max_tokens必须显式设定绝不无界。4b.4 Context Window Management—— 按系统类型给策略RAG 超出窗口做 rerank/截断多 Agent/对话式做摘要模式自主 Agent 依赖框架自身的 compaction 处理。4b.5 Cost and Latency Budget—— 按预期量级估算单次调用成本精确匹配缓存 语义缓存对子任务分类、路由、摘要路由到更便宜的模型。五、并发安全为什么 Step 7 与 Step 8 必须顺序执行gsd-ai-researcher与相邻的gsd-domain-researcher虽然写AI-SPEC.md的不同区段但编排工作流明确要求二者必须串行Step 7 完成后才能 spawn Step 8。原因是工具级别的 last-writer-wins 竞态两名 Agent 对共享文件修改时只能用 Edit 工具永远不能用 Write——Write 会整文件覆盖静默抹掉对方工作Edit 只改相关行。编辑前必须确认要写的区段仍是模板占位符防止重复写入。工作流中记录了问题编号 #3096对应测试 bug-3096-ai-integration-phase-parallel-race.test.cjs用于守护该“并行派发约 40% 命中率”的竞态不再复发。这一纪律对整个 Agent 编排体系通用凡是兄弟 Agent 共享文件先写后读、Edit 优先、Write 受限、区段互不重叠。六、质量关卡quality_standards 与 success_criteriaQuality Standards写代码的标准所有代码片段必须对抓取到的那个版本语法正确import 必须匹配真实包结构不允许“近似”坑点必须具体——像 “use async where supported” 这类空话被明确判为无效入口模式必须是可复制即运行copy-paste runnable禁止臆造 API 方法——不确定时标注 “verify in docs”Section 4b 示例必须对framework system_type具体化而非通用模板Success Criteria自检清单抓取官方文档 2–4 页不只首页安装命令对应当前最新稳定版入口模式能跑通对应system_type结合用例给出 3–5 个抽象给出 3–5 个带说明的具体坑点Section 3、4 已写且非空Section 4b 含该框架 system_type 的 Pydantic 示例Section 4b 覆盖 async 模式、prompt 纪律、上下文管理、成本预算Section 3 中列出 Sources这套标准与模板末尾的 16 项 Checklist如 “Framework quick reference written (install, imports, pattern, pitfalls)”形成双层校验Agent 自检是一层编排器的第 10 步 “Validate AI-SPEC Completeness” 是第二层——后者会检查 Section 3 有非空代码块、Section 4b 有 Pydantic 示例等硬性条件不满足时询问用户是否重跑特定步骤。七、把它接回更大的闭环gsd-ai-researcher的价值只有在其上下游完整运行时才最大化上游衔接commands/gsd/ai-integration-phase.md 会先执行gsd-sdk query系列命令解析阶段目录、模型解析与配置开关若配置中workflow.ai_integration_phase为 false 则直接退出随后framework-selector见 agents/gsd-framework-selector.md用一次 ≤6 问的访谈打分产出primary_framework / system_type / model_provider / eval_concerns这些正是研究员input的来源。落地产物写满的AI-SPEC.md最终被/gsd:plan-phase的规划器消费模板头部注明 “Consumed by gsd-planner and gsd-eval-auditor”把设计合约翻译成任务完成后若commit_docs开启编排器会执行git add与一次docs({phase_slug}): generate AI-SPEC.md风格的提交。测试护栏仓库在 tests/ 下有大批针对 Agent 契约的回归测试例如守护必读引用一致性、技能感知与尺寸预算的 agent-required-reading-consistency.test.cjs、agent-skills-awareness.test.cjs编排流水线本身也有 ai-evals.test.cjs 与 bug-3096-ai-integration-phase-parallel-race.test.cjs 等守护。若想观察研究员的下游评测设计可对照其兄弟 Agent agents/gsd-eval-planner.md 与参考文件 get-shit-done/references/ai-evals.md。八、小结从这份 Agent 定义可以看出 GSD 对待 “AI 系统开发” 的核心立场框架选型与评测绝不能靠事后补救。gsd-ai-researcher通过强制的文档查询路径Context7 MCP → ctx7 CLI → WebFetch、深度优先的限量抓取2–4 页、结构化的输出槽位Section 3/4/4b以及 4b 的五项横切最佳实践把“研究官方文档”这种原本模糊的活动压缩成了一条可审计、可验收、防幻觉 API 的固定流程。配合只允许 Edit 的共享文件纪律与编排器的事后完整性校验它让 AI-SPEC 从“模板占位”演变为“可直接指导 Planner 拆任务的实现契约”——这正是 spec-driven development 在 AI 工程侧最有价值的一环。【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考