bytedance/blocking-io-guard

确保可能阻塞 asyncio 事件循环的后端异步路径代码在 tests/blocking_io/ 中由经过“牙齿”验证的运行时锚点加以保护。在以下情况使用：修改 backend/app/、packages/harness/deerflow/ 或 scripts/ 下的后端 Python 代码；对整个仓库进行阻塞 IO 分类排查；或审阅者/CI 要求提供阻塞 IO 覆盖。该技能运行确定性扫描（变更行或全量仓库），对每个候选项进行路由分派，撰写/扩展锚点，并证明当阻塞 IO 回退时该锚点会失败。

编程协作开发 Agent Agent 技能写测试调研仓库问答异步阻塞检测运行时防护测试后端代码审查回归验证脚本 CI 阻断守护

技术栈: cursor8.1万+许可证: MIT开发者: bytedance

Skill 介绍Skill 文件

重要提示：本站仅作 Skill 资源导航与收录，正文以 GitHub 原仓库为准，版权归原项目所有。

在 GitHub 查看 ↗

原文译文

以下为摘要预览，完整内容请查看 GitHub 原文。

Blocking-IO Guard Skill

Help a contributor ship backend async changes together with the runtime anchor that lets DeerFlow's blocking-IO CI gate actually see the new code. The dynamic detector only catches blocking IO on paths a test executes — this skill closes that gap, either for your own diff or for a repo-wide triage round.

Read references/good-anchor-rules.md before writing any anchor. Only read references/sop-skeleton.md when generalizing this SOP to another detector domain — it is not needed to execute the steps below.

When to use

Your change touches Python under backend/app/, backend/packages/harness/deerflow/, or backend/scripts/ and may run on the async event loop (Mode A). If unsure, run Step 0 — it answers deterministically.
You are doing a maintenance triage round over the existing codebase (Mode B).

SOP (router)

Step 0 — Scope (deterministic)

Mode A — your own diff (default, pre-PR). From repo root:

uv run --project backend python scripts/scan_changed_blocking_io.py --base origin/main

Lists blocking-IO candidates your change introduces: findings on lines the diff added, plus findings that are new versus th…

以下为摘要预览，完整内容请查看 GitHub 原文。

Blocking-IO Guard Skill

帮助贡献者在提交后端异步改动时，一并交付能让 DeerFlow 的阻塞 IO CI 关卡真正看到这些新代码的运行时锚点。动态检测器只能捕获测试执行路径上的阻塞 IO —— 本技能弥补这一缺口，无论是你自己的 diff，还是全仓库的分类排查。

在编写任何锚点之前，请先阅读 references/good-anchor-rules.md。仅在将此 SOP 推广到其他检测器领域时，才阅读 references/sop-skeleton.md —— 执行下方步骤并不需要它。

适用时机

你的改动触及 backend/app/、backend/packages/harness/deerflow/ 或 backend/scripts/ 下的 Python 代码，并且可能运行在异步事件循环上（Mode A）。如有疑问，请运行 Step 0 —— 它会以确定性方式给出答案。
你正对已有代码库进行维护性分类排查（Mode B）。

SOP（路由器）

Step 0 — 范围界定（确定性）

Mode A — 你自己的 diff（默认，提交 PR 前）。在仓库根目录下执行：

uv run --project backend python scripts/scan_changed_blocking_io.py --base origin/main

列出你的改动所引入的阻塞 IO 候选项：diff 新增行上的发现，加上相对于 merge base 新增出来的发现 —— 后者会捕获一种情况：新的异步调用方暴露了某个旧同步辅助函数，其阻塞行并不在 diff 中。diff 的范围是 <base>...HEAD，因此请先提交你的工作 —— 未提交的代码行不会被纳入。

如果列表为空，那么本次改动并未引入静态检测器在变更文件中能看到的阻塞 IO 面。但仍有一个残留盲点：可达性仅限同一文件，因此当一个新的异步调用方调用了定义在另一个文件中的同步辅助函数时，两种选择都会对其视而不见。如果你的 diff 在某处新增了对外部辅助函数的异步调用，请在停止前通过 codegraph 或 git grep 手动检查该辅助函数。

Mode B — 全仓库分类排查。 在仓库根目录下执行：