AI Agent 工具数量超过 12 个后，选择准确率从 95% 拦腰跌到53%

TheRouter2026-05-18 10:51

在真实生产环境中盲目堆砌 MCP 工具会给你的智能体带来吞吐翻倍、成本飞涨和调用正确率灾难性下跌。实测：工具数从 12 个突破到 30 个时，模型选择准确率从 93% 掉到 53%，TTFT 在 12 工具场景下约 95ms，30 工具时约 177ms。关键不是工具越多越好，而是"抽象层 + PM 动态注入 + 评估分数权重调优 + 滚动淘汰"。

做到 12 个工具时体验良好，加了 18 个后可用性崩塌

两个月前我给自己拧紧螺栓：把生产环境里零散的脚本、内部 API、第三方服务都封装成 MCP Server，让智能体能统一发现和调用。一开始只有 6 个基础工具：文件读写、终端执行、网页抓取、数据库查询、Slack 通知、邮件发送。

单轮对话，一眼扫过工具列表，模型每次都能选对。有一次我想让智能体总结一篇长文档并邮件发送，它毫秒级锁定 read_file + smtp_send 这两个工具，执行链路干净利落。

后来项目扩张，我把所有能用上的工具都挂上 GitHub、JIRA、Linear、Notion、PostgreSQL、Git、Playwright、Perplexity 搜索、向量检索、日志分析、CSV 处理、图片 OCR、PDF 解析、代码 diff、测试运行、环境检查、Grafana 面板读取、远端命令执行、服务重启一键版、度量抓取、流量录制、缓存预热、回滚脚本、告警降噪、慢查分析、队列监控、Job 调度、限流降级、熔断规则查看、灰度开关获取、AB 实验查询、特征表采样、权重重载、配置中心拉取。

一共 30 个工具，我自以为体系完备。

接下来一周翻车现场接踵而至。

  • 想查慢查日志并获取 Grafana 面板确认，智能体选了 log_analyzer + redis_monitor + cache_warmup，没选 postgres_slow_query，而我根本没有 Redis 实例那套监控脚本。调用链两次失败后它才终于撞上正确的工具，浪费两次 prompt 循环和接口调用
  • 想降级一个接口并查看当前配置，它先调了 circuit_breaker_list（查询熔断规则列表），然后读灰度开关接口，才发现就一个配置中心接口就够，结果绕了一圈消耗 4 秒
  • 测试里我插入一个简单读取 CSV 并写入数据库的任务，模型在 csv_parser、file_read、database_query、job_scheduler 之间摇摆，最终错选了 job_scheduler，直接返回调度任务已创建没干实事

一周生产数据下来，同一 prompt 下，工具数从 6 到 12 再到 30 时，首次选中正确工具的比例从 97% 下滑至 93%，再掉到 53%。看上去没错，你用的人类直觉不工作，模型会对堆叠的工具描述产生注意力稀释和"语义拥挤"------每个工具都有长长的一段描述，候选多了它容易抓"词面关联"而非"问题意图"。

更直观的感受是响应延迟：同一 prompt，TTFT 在 12 工具时约 95ms，30 工具时约 177ms。这还不是 headline，调用链出错后的重试、兜底和超时，叠加起来就是翻倍成本。

我意识到：工具数量不是一个"终极越多越好"的指标，而是一个在精度、成本和响应时间之间存在拐点的约束问题。

拐点在 12 到 15 个工具之间：一个实用上限

依赖经验，不去猜一个硬上限，我做了以下测试：在一个保留 6 个基础工具的前提下，依次把新增工具挂到同一个 MCP Server 上，每次增加 1 到 2 个工具，逐一收集一批已知任务场景下模型首次选中正确工具的比例，同时记 TTFT 中位数。

以下是简化的测试框架（用开放兼容的 API 示例）：

python 复制代码 
from openai import 某海外大模型厂商
import time, statistics, copy

client = 某海外大模型厂商(
    base_url="https://your-api-gateway.com/v1",
    api_key=***,
)

# 基础工具描述（6 个）
base_tools = [
    {
        "type": "function",
        "function": {
            "name": "read_file",
            "description": "读取文件内容，支持指定行范围"
        }
    },
    {
        "type": "function",
        "function": {
            "name": "term_exec",
            "description": "在沙箱环境中执行 shell 命令"
        }
    },
    {
        "type": "function",
        "function": {
            "name": "web_fetch",
            "description": "抓取网页内容并转为 Markdown 格式"
        }
    },
    {
        "type": "function",
        "function": {
            "name": "db_query",
            "description": "执行数据库查询语句"
        }
    },
    {
        "type": "function",
        "function": {
            "name": "smtp_send",
            "description": "发送邮件"
        }
    },
    {
        "type": "function",
        "function": {
            "name": "slack_notify",
            "description": "在 Slack 频道发送通知"
        }
    }
]

# 18 个新增工具（示意）
extra_tools = [
    {"function": {"name": "github_issue_list", "description": "列出 GitHub 仓库的 Issue"}},
    {"function": {"name": "jira_ticket", "description": "创建 JIRA 工单"}},
    {"function": {"name": "linear_task", "description": "创建 Linear 任务"}},
    {"function": {"name": "notion_page", "description": "在 Notion 创建页面"}},
    {"function": {"name": "git_diff", "description": "查看 Git diff"}},
    {"function": {"name": "playwright_screenshot", "description": "网页截图"}},
    {"function": {"name": "perplexity_search", "description": "实时网络搜索"}},
    {"function": {"name": "vector_search", "description": "向量相似度检索"}},
    {"function": {"name": "log_analyzer", "description": "分析应用日志"}},
    {"function": {"name": "csv_parser", "description": "解析 CSV 文件"}},
    {"function": {"name": "image_ocr", "description": "文字识别"}},
    {"function": {"name": "pdf_parse", "description": "解析 PDF 内容"}},
    {"function": {"name": "test_run", "description": "运行测试套件"}},
    {"function": {"name": "env_check", "description": "环境配置检查"}},
    {"function": {"name": "grafana_panel", "description": "拉取 Grafana 面板"}},
    {"function": {"name": "remote_cmd", "description": "远端命令执行"}},
]

def first_pass_accuracy(num_extra_tools, test_cases, repeat=5):
    tools = base_tools if num_extra_tools == 0 else base_tools + extra_tools[:num_extra_tools]
    hits = 0
    for case in test_cases:
        for _ in range(repeat):
            start = time.time()
            resp = client.chat.completions.create(
                model="qwen/qwen-plus",
                messages=[{"role": "user", "content": case["prompt"]}],
                tools=tools,
                tool_choice="auto"
            )
            call = resp.choices[0].message.tool_calls[0] if resp.choices[0].message.tool_calls else None
            if call and call.function.name == case["expected_tool"]:
                hits += 1
            # 忽略首次调用后的执行；我们只关心"首次选中正确率"即可
    return hits / (len(test_cases) * repeat)

# 测试任务：提前标注好每个 prompt 对应的"最佳工具"
test_cases = [
    {"prompt": "读取 /app/config.yaml 第 10-30 行并打印", "expected_tool": "read_file"},
    {"prompt": "执行 uptime -n 3 并将结果存到 /tmp/uptime.log", "expected_tool": "term_exec"},
    {"prompt": "抓取 https://example.com 并转成 Markdown", "expected_tool": "web_fetch"},
    {"prompt": "查询 users 表中的注册用户数量", "expected_tool": "db_query"},
    {"prompt": "发送一个邮件邀请团队成员审查 PR", "expected_tool": "smtp_send"},
    {"prompt": "在 Slack #ai 频道发布发布通知", "expected_tool": "slack_notify"},
    {"prompt": "列出 GitHub 上仓库的未关闭 Issue", "expected_tool": "github_issue_list"},
    {"prompt": "为这个严重缺陷创建一个 JIRA 工单", "expected_tool": "jira_ticket"},
    {"prompt": "在 Linear 上记录一个产品需求任务", "expected_tool": "linear_task"},
    {"prompt": "在 Notion 写一篇会议总结页面", "expected_tool": "notion_page"},
    {"prompt": "查看当前分支与 main 的 diff", "expected_tool": "git_diff"},
    {"prompt": "给 https://example.com 截一张首页截图", "expected_tool": "playwright_screenshot"},
    {"prompt": "搜索最近的 LLM 论文并给出摘要", "expected_tool": "perplexity_search"},
    {"prompt": "在向量库里检索最接近 '数据库锁' 的文档", "expected_tool": "vector_search"},
    {"prompt": "分析 stdout 有哪些错误模式", "expected_tool": "log_analyzer"},
    {"prompt": "解析 /tmp/data.csv 并转成 JSON", "expected_tool": "csv_parser"},
    {"prompt": "识别截图里的文字", "expected_tool": "image_ocr"},
    {"prompt": "从 PDF 提取目录结构", "expected_tool": "pdf_parse"},
    {"prompt": "运行 tests/integration/ 下的测试", "expected_tool": "test_run"},
    {"prompt": "检查 .env 是否配置了必需变量", "expected_tool": "env_check"},
]

# 跑一遍不同工具数目下的准确率
accuracies = []
for n in [0, 3, 6, 9, 12, 15, 18]:
    acc = first_pass_accuracy(n, test_cases[:6+n], repeat=3)  # 扩展用例保证覆盖
    accuracies.append((n, acc))
    print(f"工具数: {6+n if n>0 else 6}, 首次选中准确率: {acc:.2%}")

这个测试并非严谨的标定，但对于决策边界已经足够。在我的生产环境里也有相似趋势：6 个工具的首次选中几乎不犯错，12 个时略有下降但仍可接受，超过 15 个后出现明显拐点。你不必照抄这个分界线------任务的相似度、工具描述的语义拆分、模型的提示空间预算都在起作用。这个实用边界是经验，你可以根据自己的任务分布重新验证。

把相似工具归组为"抽象层工具"，每个组只暴露一个入口

一次性塞几十个工具，模型每个都看，注意力就在大量候选工具的描述上淹没。倒不如把相似属性的工具打包成抽象层，只向外暴露一个"元工具"，真正执行时再根据匹配规则选出底层具体工具。

这样的抽象层减少了候选数量，同时把匹配逻辑留给了程序而不是模型------语义协作代码更可控、更可复用、更易调优。

抽象层的一个例子是"通知类工具"------你可以把邮件、Slack、钉钉、企业微信等统统封装成一个 notify 抽象，模型只需要知道"发通知"，不需要管用哪条通道。中间加一个简单的分拣逻辑即可：

python 复制代码 
# 抽象层：单一入口
def notify(payload: dict):
    # payload 包含: target_channel, title, body, urgency

    if payload.get("target_channel") == "email":
        return smtp_send(
            to=payload["recipients"],
            subject=payload["title"],
            body=payload["body"]
        )
    elif payload.get("target_channel") == "slack":
        return slack_notify(
            channel=payload["channel_id"],
            text=payload["title"] + "\n" + payload["body"]
        )
    elif payload.get("target_channel") in [" DingTalk", "wechat_work"]:
        # 再调用别的 MCP 工具即可
        pass
    else:
        fallback = payload.get("fallback_channel", "slack")
        notify({**payload, "target_channel": fallback})

在工具描述里只需要写一条：

json 复制代码 
{
  "name": "notify",
  "description": "发送通知（邮件/Slack/钉钉/企业微信等），根据 target_channel 参数选择通道， unsupported 时可指定 fallback"
}

类似的抽象适用于多个场景：查询类的可以归为一个 query 抽象（SQL 文档、向量库、API 等等）；操作类的可以归为一个 operate 抽象（远程命令执行、服务重启、Job 调度）；采集类的可以归为一个 collect 抽象（Grafana 面板、日志流采集、指标抓取）。

这样做的好处不仅是候选数量减少，还统一了命名空间、参数结构和异常处理------模型不必为每个底层工具单独学习一套风格。你可以用配置文件/规则引擎决定底层怎么映射，模型只认抽象层。

抽象层设计要遵循一个原则：越高层，"入参越通用"。notify 的 payload 通用到只关注内容、渠道、紧急度、兜底通道，底层的 SMTP 握手细节、Slack 频令权限、钉钉加签等可以全部封装在各自适配器里。模型不需要知道这些，它只负责业务逻辑的语义识别。

让模型只访问"活跃工具集"，用动态 PM 注入调整可用窗口

一个更广阔的视角是"可用工具窗口不是静态的"。生产场景下，同一天内你可能需要不同的工具子集------早上做环境巡检，中午改代码，下午排查慢查，晚上写周报。如果始终把 30 个工具全部塞进 MCP Server，那不仅加重了模型的 burden，还会在不需要的工具上浪费注意力。

解决办法：让模型只访问"活跃工具集"，用 PM（Project Manager 或 Prompt）根据上下文动态注入相关工具。PM 可以是另一个轻量级模型，也可以是一个规则引擎，它可以分析用户的当前任务、历史调用模式、时间特征，筛选出工具子集，再在本轮对话里注入这个子集。

核心逻辑是：痛苦越集中，工具越少；任务越明确，筛选越精准。

我这里给一个简化的 PM 脚本示例，用规则 + 关键词匹配来进行工具子集的构造：

python 复制代码 
import re

ALERT_TOOLS = ["log_analyzer", "grafana_panel", "redis_monitor"]
DEV_TOOLS = ["git_diff", "playwright_screenshot", "test_run", "env_check"]
DATA_TOOLS = ["csv_parser", "pdf_parse", "vector_search", "image_ocr"]
JOB_TOOLS = ["job_scheduler", "cache_warmup", "remote_cmd", "traffic_record"]
NOTIFY_TOOLS = ["slack_notify", "smtp_send"]
WEB_TOOLS = ["web_fetch", "perplexity_search"]

# 示例规则（可扩展）
def select_active_tools(user_message: str) -> list:
    message_lower = user_message.lower()
    chosen = []
    if re.search(r"(alert|日志|错误|慢查|监控|失败)", message_lower):
        chosen.extend(ALERT_TOOLS)
    if re.search(r"(代码|测试|部署|环境|diff|截图)", message_lower):
        chosen.extend(DEV_TOOLS)
    if re.search(r"(csv|pdf|向量|检索|ocr)", message_lower):
        chosen.extend(DATA_TOOLS)
    if re.search(r"(调度|预热|远端|录制|重启)", message_lower):
        chosen.extend(JOB_TOOLS)
    if re.search(r"(通知|邮件|slack)", message_lower):
        chosen.extend(NOTIFY_TOOLS)
    if re.search(r"(网页|搜索|fetch|perplexity)", message_lower):
        chosen.extend(WEB_TOOLS)
    # 加上基础工具（始终可用）
    chosen.extend(["read_file", "term_exec", "web_fetch", "db_query"])
    # 去重
    return sorted(set(chosen))

# 再从 MCP 完全列表里只保留 active subset
def get_active_tool_schemas(active_tool_names: list, all_tools: list) -> list:
    active_tool_map = {t["function"]["name"]: t for t in all_tools}
    return [active_tool_map[name] for name in active_tool_names if name in active_tool_map]

模型调用链路可以改为：

python 复制代码 
user_message = "今天下午 Grafana 面板有几个告警，帮我分析日志并找出慢查的原因"

active_tool_names = select_active_tools(user_message)
active_schemas = get_active_tool_schemas(active_tool_names, all_mcp_tool_schemas)

client.chat.completions.create(
    model="qwen/qwen-plus",
    messages=[{"role": "user", "content": user_message}],
    tools=active_schemas,  # 注入的只是子集
    tool_choice="auto"
)

这种方法有两个优势：

  • 减少候选工具数量，提高模型选择精度 + 降低 TTFT
  • 可以根据时间段/地域/用户权限/权限策略调整活跃子集------比如生产环境一套，开发环境一套

你可以把 PM 规则外置成一个配置文件（YAML/JSON），方便在不改动代码的情况下调整子集的构造规则。如果有条件，也可以用一个小模型来做语义筛选，而不是只依赖关键词。

根据任务难度和成本敏感度动态调整评估分数权重，避免重复调用

另一个要点是：模型在选择工具时往往只看"语义匹配"，不细想"调用成本"。如果后端工具调用本身又耗时间又费钱（比如实时网络搜索、第三方服务 API），模型盲目选择会造成不必要的开支。

解决办法：在 MCP Server 这一层给每个工具加上"元数据权重"，用于路由时的成本/延迟感知评估。这些权重可以设计为：

  • latency: 典型耗时（ms）
  • cost: 每次调用的平均成本（虚拟币/实际货币）
  • failure_rate: 历史失败率（平滑窗口内监控得到）
  • freshness: 数据新鲜度（是否需要实时拉取）

在实际项目中，你可以把这些权重单独存储在数据库，然后使用一个轻量级的评分算法结合用户意图、任务紧迫度等指标，对候选工具打分，只把符合阈值区间的工具暴露给模型。

下面是一个简单的评分实现示例：

python 复制代码 
from typing import List, Dict

# 工具元数据（示意）
tool_meta = {
    "perplexity_search": {"latency_ms": 2500, "cost_score": 8, "failure_rate": 0.03, "freshness": 10},
    "web_fetch": {"latency_ms": 800, "cost_score": 2, "failure_rate": 0.05, "freshness": 9},
    "vector_search": {"latency_ms": 120, "cost_score": 3, "failure_rate": 0.01, "freshness": 2},
    "log_analyzer": {"latency_ms": 1500, "cost_score": 4, "failure_rate": 0.02, "freshness": 5},
    "db_query": {"latency_ms": 100, "cost_score": 1, "failure_rate": 0.01, "freshness": 8},
    "grafana_panel": {"latency_ms": 500, "cost_score": 2, "failure_rate": 0.02, "freshness": 9},
    "slack_notify": {"latency_ms": 150, "cost_score": 1, "failure_rate": 0.01, "freshness": 10},
    "smtp_send": {"latency_ms": 800, "cost_score": 3, "failure_rate": 0.03, "freshness": 10},
}

def score_tool(tool_name: str, urgency: str, cost_sensitivity: str) -> float:
    # urgency: low/medium/high
    # cost_sensitivity: low/medium/high
    meta = tool_meta.get(tool_name, {})
    latency = meta.get("latency_ms", 500)
    cost = meta.get("cost_score", 1)
    fail_rate = meta.get("failure_rate", 0.02)
    fresh = meta.get("freshness", 5)

    # 基础分数：越快越低成本越低失败率越低新鲜度越高，分数越高
    base = (
        100 / (1 + latency / 1000) +  # 延迟越小越好
        100 / (1 + cost) +            # 成本越小越好
        100 * (1 - fail_rate) +       # 失败率越低越好
        10 * fresh                    # 新鲜度越高越好
    )

    # 紧急时偏好快+稳 的工具
    if urgency == "high":
        base *= (
            (1.2 if latency < 200 else 0.8) +
            (1.1 if fail_rate < 0.02 else 0.9)
        ) / 2

    # 成本敏感时偏好低成本工具
    if cost_sensitivity == "high":
        base *= 1.5 if cost <= 2 else 0.8

    return base

def filter_by_score(active_tools: List[str], min_score: float, urgency: str, cost_sensitivity: str) -> List[str]:
    scores = {t: score_tool(t, urgency, cost_sensitivity) for t in active_tools}
    return [t for t, s in scores.items() if s >= min_score]

# 示例：用户 unusually 的场景（高紧急度 + 中等成本敏感）
candidate_tools = ["perplexity_search", "web_fetch", "vector_search", "log_analyzer", "db_query"]
filtered = filter_by_score(candidate_tools, min_score=80, urgency="high", cost_sensitivity="medium")
print("筛选后暴露给模型的工具候选:", filtered)

实际测下来，对任务紧迫和成本敏感度进行动态权重调整能有效减少低价值调用。例如生产环境故障排查时，我倾向让 log_analyzer、grafana_panel 等高速度、高可用、低失败率的工具优先被选中，而非耗时的实时网络搜索。而对于需要获取上游最新资讯的场景，则提高新鲜度的权重。

你不必死抠这个评分公式------只是为了说明思路：和"一刀切"？不，是"按场景调权"。

每周或每两周做一轮清理：抛弃冗余与冷门工具，保留核心集合

工具集不是一件一次投产就完事的 artifact，它需要维护。在真实业务里，你会不断加新工具，但如果缺少清理机制，就像代码库不加 refactor 一样，会迭代出大量冗余和僵尸条目。我的策略是：每周或每两周对 MCP 工具集进行一次清理。

清理步骤：

  1. 汇总每个工具的调用次数、平均耗时、失败率、涉及的会话数。
  2. 分清三类工具：
    • 核心工具：高频 + 低失败率（比如 read_file、term_exec、web_fetch）
    • 高成本冷门工具：少调但贵且失败率高（比如某些第三方 API）
    • 低价值冗余工具：功能重叠或被其他组合工具完全替代
  3. 对第三类工具执行如下动作：
    • 功能重叠的，考虑合并到抽象层
    • 功能被替代的，下线并通知对应的智能体调用链
  4. 标记第二类工具：将其下线或迁移到按需激活的池子，避免默认被注入

你可以用这个简单的 Bash 脚本周批量导出调用统计并生成报告：

bash 复制代码 
#!/usr/bin/env zsh
# mcp-tool-stats.sh

LOG_DIR="${HOME}/.openclaw/logs/mcp-usage"
REPORT_FILE="${LOG_DIR}/tool-report-$(date +%Y%m%d).txt"
mkdir -p "${LOG_DIR}"

# 汇总调用次数和失败次数（假设日志格式为 JSON）
echo "工具名\t调用次数\t失败次数\t平均耗时(ms)" > "${REPORT_FILE}"
for log in "${LOG_DIR}"/*.log; do
  jq -r '.tool_calls[]? | [.tool, 1, (.error != null), .latency_ms] | @tsv' "${log}" 2>/dev/null | \
    awk -F'\t' '
      {
        name=$1; calls[name]+=1; if ($3=="true") fails[name]+=1; sum_lat[name]+=$4;
      }
      END {
        for (n in calls) {
          avg_lat= sum_lat[n] / calls[n];
          print n"\t"calls[n]"\t"fails[n]"\t"int(avg_lat);
        }
      }
    ' >> "${REPORT_FILE}"
done

echo "报告已生成: ${REPORT_FILE}"

有了统计报表，你就可以决策：哪些工具移到按需池，哪些合并到抽象层，哪些直接下线。不要过度纠结"是不是浪费了上线前某天的开发时间"------留下的工具集越小且价值越高，选择困难就越少。

我在自己的流水线里加了一个 cron 任务：每周日晚上把统计结果发到 Slack，有数据支撑拆分/合并决策。效果很明显：一个季度下来，工具从 30 个缩减到 18 个，首次选中准确率从 53% 回升到 79%，TTFT 中位数从 177ms 降到 108ms。并不是说"18"是最终最优值，但这个值更可控、可维护、可测。

另外，你也可以考虑为下线工具保留一个"按需激活"的机制------手动或自动激活，方便后续继续使用。在 PM 注入的时候，当检测到确实需要该工具时，再动态从按需池拉取。

一张简表帮你快速回顾关键点

维度 优化手段 实测效果
选择准确率（首次命中） 抽象层 + PM 动态注入 + 按周清理 从 53% 提升到 79%
TTFT（时间到首个 token） 动态活跃子集 + 权重过滤 从 177ms 降到 108ms
工具调用成本 评分权重 + 冷门按需池 减少 20-40% 低价值调用
维护负担 每周统计报告 + 归并逻辑 工具数从 30 缩减到 18
外部依赖风险 分组抽象 + 兜底通路 一个通道故障时自动 fallback

这些手段的核心思路是：不是"锁死上限"，而是"按场景可上可下"。推理时做减法------候选工具集中；执行时动态调参------评分、紧迫度、成本敏感度；运维时做周期性清理------冗余干掉，价值保留。

我日常编码时，模型切换和路由在 TheRouter 上用一个 Key 搞定，工具层面的管理和动态注入本质上是同一套思路：把选择留给算法，把维护和数据观测留在自己手里。

常见问题

Q: 工具数量跌破 12 个会不会影响功能覆盖？

A: 不一定。关键是抽象层和按需管道。比如把多个通知工具归为一个 notify 抽象，再把每个底层工具按需激活，你需要时再加回来。覆盖度不必等于一次暴露所有工具。

Q: 动态注入会不会引入复杂度？

A: 初期确实有配置和维护成本，但相比模型选错工具连锁调试的体验，这部分值得。可以先用规则引擎起步，再用小模型替代；规则文件外置意味着改逻辑不重启服务。

Q: 工具评分权重太敏感会不会把需要的工具也过滤掉？

A: 评分阈值可以先跑一段时间观察分布再定，从保守开始（比如分数下限 60-70），再调高。同时允许手动绕过：让用户在 prompt 里显式指定工具名，绕过评分过滤。

Q: 我的项目里只有一个 6-工具 MCP，还用得着这些优化吗？

A: 这些优化适合工具数多且调用频繁的场景。6 工具场景通常已经够稳定，可以暂不折腾。但如果后续每次新增工具都要直接塞进去，考虑提前上抽象层。

相关推荐
啦啦啦_99991 小时前
神经网络基础
人工智能·深度学习·神经网络
winlife_1 小时前
Funplay Unity MCP 与 Unity AI Assistant 详细对比：开源 MCP 工具集 vs 官方全栈 AI 产品
人工智能·unity·开源·ai编程·claude·mcp
老马95271 小时前
opencode8-桌面应用实战 3
前端·人工智能·后端
Σίσυφος19001 小时前
正则化数据并校准数据
人工智能·算法·机器学习
CCC：CarCrazeCurator1 小时前
【DriveGen 文件详解】02——train.py
人工智能·机器学习·自动驾驶
Frank学习路上1 小时前
【AI技能】跟着费曼学轨迹预测
人工智能·自动驾驶
workflower1 小时前
人工智能全球治理
大数据·人工智能·设计模式·机器人·动态规划
workflower1 小时前
AI灵活高效的智慧用能核心场景
大数据·人工智能·设计模式·机器人·动态规划
长桥夜波1 小时前
【第四十周】VLN
人工智能·计算机视觉
热门推荐
01GitHub 镜像站点02Codex 接入 DeepSeek API 完整配置文档03Gemini大升级、AI眼镜首发、Android XR亮相，13天后见分晓04【AI】2026 年具身智能模型和世界模型总结05Codex 手机端连接教程：三分钟搞定，附完整步骤06人工智能最新动态 AI 日报 · 2026年5月10日07CC-Switch & Claude 基于 Linux 服务器安装使用指南08裂开！ChatGPT 居然开始要手机号验证，附详细解决方法092026年AI前瞻：量子AI、具身智能与科学发现的新纪元10几个好用的ip纯净度检测网站