// 专家评审决策系统。当面临重要决策、方案选择、风险评估时触发。完整的专家评审流程包括：多位专家独立评审 → 作者回应与修改 → 至少一轮交叉审阅，最多三轮收敛结论或呈报用户裁决。
当用户要查找路由器/AP/有线中继/桥接模式下的管理地址，尤其是校园网、宿舍网、墙上网口接路由器、多人各自认证登录、改成 AP/有线中继后不知道后台 IP、想扫描当前网段里的路由器后台、小米/TP-Link/OpenWrt 管理页时使用。也适用于验证默认私网管理地址是否失效，以及安全地通过常见管理端口识别候选后台。
复现开源代码仓库时自动配置 Python/C++/PyTorch/CUDA/MMCV 等技术栈的 conda 环境，先产出 requirements.txt 和安装方案，再通过 tmux 串行执行 conda/pip/编译命令，适用于视觉、三维重建、自动驾驶等仓库。
按照下面的要求审阅/评审某篇指定论文
按照下面的要求为用户讲解/解读某篇指定论文
| name | expert-review |
| description | 专家评审决策系统。当面临重要决策、方案选择、风险评估时触发。完整的专家评审流程包括：多位专家独立评审 → 作者回应与修改 → 至少一轮交叉审阅，最多三轮收敛结论或呈报用户裁决。 |
借鉴学术期刊审稿流程的多角色决策系统。每位专家是独立的 subagent，拥有独立 context，互不污染。
核心流程对照：
按需选人，每次 3-5 位。
| 角色 | 代号 | 立场 | 适用场景 |
|---|---|---|---|
| 🛡️ 风控官 | RiskGuardian | 专门泼冷水，找风险、漏洞 | 方案评估、部署决策 |
| 🔥 激进派 | Innovator | 推动大胆方案，找突破口、找机会 | 科研方向、技术选型 |
| 🤔 质疑者 | Skeptic | 质疑假设，挑战"理所当然"，故意站对立面压力测试 | 所有场景（建议必选） |
| 📚 历史学家 | Historian | 翻旧账，搜索记忆和知识库，调取历史经验 | 有历史教训可参考时 |
| ⚖️ 务实派 | Pragmatist | 关注资源约束、时间成本、可操作性 | 资源有限时（如算力、时间） |
可根据具体场景临时定义领域型角色，类似期刊审稿中视情况引入新审稿人。预设角色是"态度型"的，领域型角色往往更贴合具体议题。根据议题的复杂度和风险性调整选人数量
subagent task 模板：
你是专家评审的 [角色名]（[代号]）。
你的立场：[立场描述]
你的行为准则：
- 基于事实和逻辑发言，不要空泛
- 明确表达你的立场，不要和稀泥
- 如果你反对某个观点，直接说为什么
- 发言控制在 300-500 字（后续轮次 200-300 字），精炼有力
- [角色特有指令]
议题：[决策问题]
背景信息：[详细背景]
请从以下维度分析：[具体维度列表]
中文输出。
第一轮评审结束后，主 Agent 作为"作者"：
这一步是第一轮和第二轮之间的桥梁，确保第二轮有增量信息可以讨论，而不是各说各话。
在作者回应之后，主 Agent 评估分歧程度：
注意：当所有专家意见高度一致（如全部反对某方案）时，作者不能单方面否决，必须如实呈报用户。
## 📋 专家评审结论
**议题：** [决策问题]
**评审专家：** [角色列表]
**轮次：** [N 轮]
### 结论
[最终结论或分歧报告]
### 各方核心观点
[列出每位参与专家的最终立场，不遗漏]
### 分歧摘要（必须保留少数派观点）
[即使达成多数共识，也要列出少数派的核心论点和理由，不抹平分歧]
### 风险评级变化（如适用）
| 维度 | 第一轮 | 最终 | 说明 |
|------|--------|------|------|
| ... | ... | ... | ... |
memory_search 和 qmd 搜索相关历史