针对代理创建的类型检查器抑制的棘轮检查
允许编码代理编辑生产代码的团队，可以为 # pyrefly: ignore 这类抑制写法添加棘轮检查。该检查把当前数量作为上限；代理新增实例时检查失败；是否提高上限交给有更多上下文的规划代理或人工评审者决定。
这是低成本防护，因为它避开了冗长的风格提示，也不需要 LLM 裁判。它适合那些少数情况下快速抑制可能有效、但默认使用会带来损害的场景。小规模试验可以从 CI 中的一条规则开始，报告当前数量，并且只阻止代理编写分支上的新增实例。
摘要
大量使用代理的开发需要把控制放进日常工作流：禁止代码模式的计数器、并行代理会话的持久视图，以及面向需要 lookaround 的 Rust 规则扫描器的窄范围正则引擎测试。
研究想法
面向并行编码代理会话的持久终端工作区
同时运行多个编码代理 CLI 的开发者，可以测试一个全屏终端工作区，把每个代理、shell、打开的文件和工作树 diff 放在同一处可见。采用测试很直接：让两三个代理处理不同任务，在会话中重启 UI，然后检查操作员能否重新连接，且不丢失进程状态或文件变更线索。
Workbench 是这一模式的具体例子。它使用私有 tmux 服务器来持久化代理和终端窗格，支持 Claude Code、Gemini、Goose、OpenCode 和 Cursor，并为每个工作区添加只读文件查看器和实时 git diff。现有证据提供的是产品细节，没有任务成功率基准，所以第一轮检查应衡量操作员可见的失败：会话丢失、错误工作区编辑、遗漏 diff，以及在工具之间切换所花的时间。
资料来源
面向需要 lookaround 的 Rust 规则扫描器的 Resharp 基准测试
基于 Rust 的规则扫描器维护者，在正则规则需要 lookaround 时，可以做一次范围受控的 Resharp 评估，尤其适用于通过 AST 查询难以表达的注释风格检查。测试应使用项目的真实规则，记录绝对运行时间、规则数量、硬件和多次运行的方差，并纳入兼容性失败，因为 Ratchets v0.4.0 是一次破坏性的引擎变更。
Ratchets 报告提供了一个有用起点：作者将 Rust 的 regex crate 替换为 Resharp 后，在 Sculptor 代码库上看到约 15% 的速度提升，并且没有报告其他代码变更。更可靠的测试理由是功能覆盖，因为最初的缺口是对基于正则的规则提供 proper lookaround 支持。