Scout 是一个研究型技能，用于在一个能力被实现之前或之后，查明外部世界是否已经有人交付了同样的东西。它把这种做法比作面向产品与工程工作的“有没有现成的 AI”，但强调以证据而非感觉为依据。
用途 当代码、计划或 diff 已存在、可能正在重复发明已有能力时，Scout 用于识别被（重新）构建的东西是什么，找到现有方案，并判断应该采用还是继续自建。当问题是开放式的，例如“X 有什么现成的”“X 有没有新工具”“现在人们怎么做 X”时，Scout 用于梳理整个领域，呈现值得注意的和近期出现的方案，让使用者自行选择。输入已经明显指向某一种意图时，不需要再询问用户属于哪一类：diff 或提案属于拦截式，单纯的能力问题属于探索式。
主要能力 Scout 的核心规则是搜索能力，而不是搜索名词。因为直接拿用户自己的词汇去搜索，往往只能找到博客文章；而把实现翻译成行业使用的标准术语后，才能找到整个类别。例如“表里存行 + 轮询 worker + 重试计数”应翻译为“job queue、background jobs、durable task execution”；“带处理器注册表的事件总线”对应“pub/sub、message broker、event bus”；“手写的带抖动重试包装”对应“retry library、resilience/backoff library”；“自建角色/权限匹配器”对应“authorization / policy engine、RBAC / ReBAC”；“类似 cron 的 setInterval + 锁文件”对应“job scheduler、distributed cron、workflow orchestration”；“向导用的 diff-and-apply 状态机”对应“state machine library、workflow engine”；“自定义 CSV/Excel 导出写入器”对应“spreadsheet / serialization library”。如果不确定标准术语，第一步搜索就是“what is it called when …”，先把词汇搞对，再展开。
使用方式 工作流包含六个步骤。第一步是命名能力：用一行说明它做什么，去掉本地实现，列出 2–5 个标准搜索词和明显的同义词，并在展开前展示给用户，因为能力名错了整个搜索就白费。第二步是先读地面实况：查语言与运行时、清单文件（package.json、requirements.txt/pyproject.toml、go.mod、Cargo.toml、Gemfile、pom.xml）里已有什么、已付费的基础设施（云厂商、Postgres/Redis/Kafka、账上已有的供应商）、硬性约束（只能自托管、数据驻留、许可政策、气隙环境、不新增供应商、预算）、规模现实（每天 100 个任务和每秒 10 万个任务不会选出同一批工具）。已经安装的候选，或已经被现有付费服务覆盖的候选，优于其他所有候选，要先找这些。第三步是并行展开多条研究通道：每个通道一个子代理，各自运行多次网络搜索。通道包括 Canon（类别的标准名称以及每篇对比都会列出的 3–8 个选项）、Ecosystem（本项目语言下的库和开源项目）、Commercial（托管服务、开发工具、SaaS、云原生能力，包括没人提的枯燥云方案）、Already yours（藏在现有依赖、框架标准库或已在账单上的供应商里的能力，价值最高、成本最低）、Verdicts（从业者实际怎么说，HN/Reddit 讨论、“我们从 X 迁移走了”、事后复盘）、Counter-case（为什么自己动手有时是对的，以及现有方案的已知失败模式）。探索式意图还要增加 Frontier 通道，查看过去 6–12 个月发布的内容，因为模型记忆在这里最容易过时。通道数量按风险规模决定：3 条用于“有没有重试库”，全部 6 条用于“我们该不该自建编排器”。不要为每个网站开一条通道。用户提供了种子名称、来源或“也查一下 X”时，把这些放进专用通道，而不是稀释其他通道。
第四步是归并：合并所有通道的候选行，杀掉未经验证的内容（没有活的 URL 就不是候选），杀掉已死的项目（约 18 个月没有发布或没有有意义的提交、仓库已归档、有下线通知、公司已不存在），跨品牌更名、fork、包装和不同通道命名的同一产品去重，按方法而不是按名称聚类（例如托管服务 vs 自托管 broker vs 在数据库内的库），按第二步的约束、采用度、成熟度排序，流行度只做平局判定，绝不是标准。
第五步是交付候选清单和判断，上限为 3–6 个候选，二十个的列表是研究倾倒而不是推荐。每一行都必须能追溯到本次运行中捕获的来源 URL。示例表格结构包含“选项”“类型”“为什么合适”“成本”“放弃什么”“采用成本”等列，并补充“你技术栈里已有的”“没有任何选项能给你的”“什么情况下自己动手仍然更好”等信息。然后通过 ask_question 把决定交给用户，选项包括：采用推荐方案并移除手写版本；采用，但为没有覆盖的部分保留自定义层；保留自定义实现（记录原因）；进一步研究——不同约束或更多选项。Scout 绝不自行拆除能工作的代码，只报告和建议，由用户做主。
第六步是交接：采用时交给 8020 找最小集成路径，或如果替换会重塑设计则交给 pre-plan；继续自建时继续推进，并留下一条类似 smart-comments 的 WHY 注释，记录评估和拒绝了什么，使下一个 agent 不会重新争论；需要本身现在看起来不可靠时回到 distill-need；候选需要在承诺前压力测试时交给 consult。
适用场景 适合在准备引入“后台任务”这类能力时，先确认 BullMQ、Trigger.dev、Cloud Tasks 或 package.json 里已有的队列库是否已经存在；适合对某个能力做开放式调研；适合在代码审查只问“我们代码里有没有”之外，补上外部世界已经交付了什么。
限制 Scout 不发明功能，不编造候选包，不估计版本号、价格、限制或许可条款，这些必须从来源引用或省略。所有候选必须经过实时网络搜索验证，带有本次运行中出现的 URL 和存活信号（最近发布、最近提交或当前的定价/文档页）。仅凭记忆想起但未验证的名称必须标记，并在进入候选清单前确认。它不会仅因为某个方案更流行就替换能工作的代码，也不会每次都得出“用库”的结论；如果自己动手确实更简单，它会如实说明。报告中缺少可信内容的通道会如实呈现。它不负责审计仓库内部重复和死代码（那是 prune 的职责），不负责质疑需求是否真实（那是 distill-need 的职责），也不负责为某个方向挑刺（那是 challenge 的职责）。