【review】AlgorithmScheduler 作为本 PR 的核心新增组件（225 行），缺少独立的单元测试

• 问题：当前测试仅覆盖了 prepare_tensor、get_relative_err 等工具函数和各 builtin 算法的 compare 函数，但 AlgorithmScheduler 类本身（单例、模块加载、列名去重校验、返回值校验、自定义算法注册、异常回退路径）没有任何测试覆盖
• 风险：_validate_column_names 重复列名检测、_validate_return_value 对非法返回值的拦截、_call_algorithm 异常时返回 "unsupported"、_get_module 导入失败等关键路径未经验证，回归风险高
• 改进方案：新增 test_algorithm_scheduler.py，至少覆盖：
  1. get_instance 单例行为（多次调用返回同一实例）
  2. builtin 算法自动发现和 column_name 去重校验
  3. _validate_return_value 对非法返回值（非 tuple、元素数不对、类型不符）的拦截
  4. _call_algorithm 异常时返回 "unsupported" 的行为
  5. 自定义算法目录加载（含空目录、非法文件名跳过场景）

【review】sys.path.append 污染全局模块搜索路径，存在模块名冲突风险

• 问题：将 os.path.dirname(__file__) 追加到 sys.path 后，importlib.import_module("builtin_algorithm.alg_xxx") 依赖此全局副作用。若运行环境中存在其他同名顶层包 builtin_algorithm 或 custom_algorithm，会导入到错误的模块
• 改进方案：使用绝对导入路径，无需修改 sys.path：

# _get_module 中改为：
if algorithm_name in self.custom_support_algorithm:
    module_name = f"msprobe.core.compare.algorithm.custom_algorithm.alg_{algorithm_name}"
elif algorithm_name in self.build_in_support_algorithm:
    module_name = f"msprobe.core.compare.algorithm.builtin_algorithm.alg_{algorithm_name}"

这样与项目其他模块的导入方式保持一致，且避免全局副作用

【review】init 中 _validate_column_names 会触发全部算法模块的导入，与 _algorithm_cache 的懒加载设计意图矛盾

• 问题：_validate_column_names 遍历所有算法并调用 _get_module，后者执行 importlib.import_module 并写入 _algorithm_cache。初始化完成后缓存已全部填充，后续 _call_algorithm 不会再触发懒加载
• 影响：若 custom_algorithm 目录存在大量自定义算法，单例初始化耗时增加；且 _algorithm_cache 命名暗示"按需加载"，实际为 eager 加载，语义不符
• 改进方案（二选一）：
  1. 若需保持懒加载：将 column_name 校验改为约定式（如 column_name == 文件名去 alg_ 前缀），延迟到 _call_algorithm 时才导入模块
  2. 若 eager 加载可接受：将 _algorithm_cache 重命名为 _module_cache 并补充注释说明初始化时全量加载，避免后续维护者误解

【review】使用 co_argcount 校验入参数量，无法正确处理带默认参数、*args 或装饰器的 compare 函数

• 问题：compare_func.__code__.co_argcount 对 def compare(a, b, c=1) 返回 3（会被拦截），但对 def compare(a, b, **kwargs) 返回 2（会通过，可能不符合预期）；对被装饰器包装的 compare 函数，co_argcount 反映的是 wrapper 的代码对象而非原始函数，可能导致误判
• 改进方案：使用 inspect.signature 进行更健壮的校验：

import inspect
sig = inspect.signature(compare_func)
required_params = [
    p for p in sig.parameters.values()
    if p.default is inspect.Parameter.empty
    and p.kind in (inspect.Parameter.POSITIONAL_ONLY, inspect.Parameter.POSITIONAL_OR_KEYWORD)
]
if len(required_params) != self.ARG_COUNT:
    raise ValueError(f"{self.COMPARE_FUNC_NAME} in {algorithm_name} must have {self.ARG_COUNT} positional arguments.")

【review】_call_algorithm 捕获所有 Exception 并统一返回 "unsupported"，会掩盖算法实现中的真实 bug

• 问题：算法内部任何异常（包括 AttributeError、TypeError、逻辑 bug）都会被吞掉，调用方只看到 "unsupported" 和错误消息字符串。虽然 logger.error 记录了原始异常，但在多进程场景下日志容易被淹没，排查困难
• 改进方案：区分"算法不支持当前数据类型"（预期异常）和"算法执行错误"（非预期异常）：

except (ValueError, TypeError) as e:
    # 数据类型不支持等预期异常
    logger.warning(f"Algorithm [{algorithm_name}] unsupported for this input: {e}")
    return "unsupported", str(e)
except Exception as e:
    # 非预期异常不应被吞掉，避免将代码 bug 误判为"不支持"
    logger.error(f"Algorithm [{algorithm_name}] internal error: {e}", exc_info=True)
    raise

这样在保持容错的同时，让真正的实现 bug 能被及时发现