从 CC Switch、Claude Code 到 MCP、RAG：串透 AI 开发整条技术链路

helloLeila
4 阅读25分钟

最近把自己的零散笔记重新顺了一遍，整理出来这篇内容，可以按三层来看：

  1. 工具层：cc switch、Claude Code 这类 agent 工具怎么配、怎么用。
  2. 协议层：MCP（接口协议，统一对话规则）怎么把 agent 和外部工具连起来。
  3. 检索生成层：RAG（检索增强生成，先找再答）、BM25、双塔、Cross-Encoder、LambdaMART 怎么配合，把结果做得更让大模型生成想要的。

作为初学者，我们先把工具用顺，再把协议看懂，最后把检索和生成链路串起来。关于大模型的完整版本的架构图如下，本文先挑出来一部分重点讲解，后面会持续更新的！

image.png

一、CC switch

（解决模型中转配置痛点）

  1. 配合coding plan（GLM 每天上午10点/火山引擎/minimax在ccswitch的github首页九折）或者中转2. claude code/codex等多种agent，
  2. 管理不同agent的skills，目前还加入了很火的hermes

cc switch 下载sourceforge.net/projects/cc…

一方面，它解决模型中转配置痛点。你同时用 Claude Code、Codex、Gemini CLI、各种中转站，最麻烦的往往不是模型本身，而是配置散在不同地方：有的改环境变量，有的改配置文件，有的改 provider，有的还要单独挂 MCP。

另一方面，cc switch 可以把不同 agent 的配置放到一个地方统一管理。先统一入口 → 再统一 provider → 最后统一 skills 和外接能力。整套链路集成后，换模型、换中转、换 agent，不用每次都从头配一遍。

image.png

二、Claude Code 常用使用

常用的几个命令

  1. /init 初始化项目 生成一个文件
  2. /model切换模型
  3. /doctor
  4. /export 导出
  5. /debug 调试日志
  6. /plugin 查看安装等技能

第一类是官方内置命令。
按 Anthropic 官方文档，/init、/model、/doctor、/mcp、/agents、/memory 这些是官方明确提供的。

第二类是环境相关命令。
像 /export、/debug、/plugin 这种，在不同环境里可能有，也可能没有；有时是团队自己加的命令，有时来自插件、封装脚本，不能默认每个 Claude Code 环境都一样。

所以实操时最稳的顺序是先 /help 看当前环境支持什么 → 再按命令作用去用。

1. /init 初始必备

/init 初始化项目 生成一个文件

就是：/init 会帮你初始化项目级说明文件，官方对应的是 CLAUDE.md。
CLAUDE.md 可以先理解成“这个项目的长期记忆文件”，里面通常写项目背景、代码规范、常用命令、协作约束。 `/init`` 的价值不只是“生成一个文件”，而是把项目上下文固化下来。后面 agent 再进入这个仓库时，就有地方读“这个项目到底怎么干活”。

3. /model 是做什么的

/model切换模型

这个比较直接，就是切模型。
但从系统角度看，它切的不只是“聪明程度”，还可能一起影响：
速度、价格、上下文长度、推理风格。

所以平时可以这么理解：
简单任务用轻量模型 → 复杂规划用强模型 → 长上下文任务看窗口大小。

3 . plan 和 coding

有plan和coding模式

  1. plan：先分析、先规划。
  2. coding：开始执行、开始改。

官方更明确的说法是 Plan Mode。它的价值是：先只读分析，不急着动文件。
这样在多文件改动、陌生项目探索、要先确认方案的场景里，会更稳。

社区里常把默认可执行状态顺手叫“coding 模式”。
先 plan → 再 coding。先想清楚 → 再下手。

4. /doctor 是做什么的

/doctor

/doctor 可以先理解成“安装健康检查”。
官方说明很短，核心意思是：检查 Claude Code 安装是不是正常。实际使用里，它常常是排查问题的第一步，比如：

  1. 安装方式对不对。2. 版本是不是正常。3. 本地环境有没有明显异常。

所以如果你遇到“装上了但不太对”“能启动但行为怪”“升级后出问题”这类情况，先跑 /doctor，比直接重装更省事。

5. /export、/debug、/plugin 怎么理解

/export 导出
/debug 调试日志
/plugin 查看安装等技能

这三类更适合按“用途”来记：

  1. /export：把当前结果导出去。
  2. /debug：看调试日志。
  3. /plugin：看插件、技能、扩展能力。

但要注意一点：这几个命令不一定是 Claude Code 官方通用内置命令。
所以最稳的说法是：如果你当前环境支持这些命令，它们一般就是上面这几个用途。

6. skills

skills

  1. 本质上是提示词 包含四个部分

    skills.md文件

    example

    description 搜索时会检索这里

    Reference

  2. 平时找成熟的skills网站

    github或者skills.sh

这部分建议直接按四个组件来记。

skills.md文件
这是主文件。可以理解成“技能说明书”或“工作流提示词”。
它负责告诉 agent：这个 skill 是干什么的、什么时候该用、用了以后按什么步骤做。

example
可以理解成“怎么调用、怎么落地”的样例。
它的作用不是讲概念，而是降低上手成本，让人一看就知道这个 skill 往哪种任务上套。

description 搜索时会检索这里
description 可以理解成“检索入口句”。
很多 agent 在自动匹配 skill、subagent、命令时，先看的就是这句描述。它写得越像真实任务场景，越容易被正确命中。
所以这行不要写成空话，最好直接写“什么任务该调它”。

Reference
可以理解成“补充背景和规则”。
它一般放知识背景、规范、边界条件、注意事项，不负责主流程，但能让输出更稳。

网站 github
skills 很多时候就是放在 GitHub 上管理。
先用 Markdown 维护 → 再走版本控制 → 最后方便团队共享和复用。
所以 skills 本身虽然本质上是提示词，但管理方式已经很像代码资产了。

可以记成：

  1. skills.md文件：主逻辑。
  2. example：怎么用。
  3. description：怎么被搜到。
  4. Reference：为什么这样做。

核心要素：把 skills.md文件、example、description、Reference 画成四块，旁边预留“用户总结模块”，写你自己最常用的 skill。
易懂设计建议：用“主流程 / 示例 / 检索 / 背景资料”四种颜色区分，避免把四部分都画成同一种说明框。

7. cd 和 pwd

！cd 进入目录

pwd查看当前项目目录

这两句要稍微修一下表达，逻辑会更准：

  1. 平时最常见的是先在终端里 cd 进入目录，再启动 Claude Code。
  2. pwd 用来查看当前项目目录。

如果已经在 Claude Code 会话里，官方更标准的扩目录方式是 /add-dir，不是长期依赖 !cd。
因为 ! 是 Bash mode（壳命令模式，直接跑 shell 命令），它更像“执行一条命令并把结果带回会话”，而不是总把工作目录永久切过去。

Claude Code 界面截图转存失败，建议直接上传图片文件

三、mcp理解

MCP（接口协议，统一对话规则）

包括三部分

1 host agent（如claude） 发起请求的agent

2 client 内置

3 server 比如想连接figma

还有tools request

分清“谁发起”“谁连接”“谁提供能力”。

1. host agent 是什么

host agent（如claude） 发起请求的agent

host 可以理解成“宿主应用”或“总控台”。
比如 Claude、Claude Code、桌面端 agent，它们负责承接用户请求、决定什么时候去调外部能力。

2. client 是什么

client 内置

client 可以理解成“内置连接器”。
它通常不是一个单独给用户看的大东西，而是 host 里面负责连接 MCP server 的那一层。

官方架构里更准确的说法是：
一个 host 可以创建多个 client，每个 client 对应一个 server 连接。

3. server 是什么

server figma 对方的

server 可以理解成“真正提供能力的一方”。
比如 Figma、GitHub、Notion、本地数据库、浏览器自动化服务，这些都可以通过 MCP server 把能力暴露出来给 agent 用。

4. tools request 是什么

tools request 可以理解成“工具调用请求”。
也就是 agent 不是自己会所有事，而是通过 MCP 去请求某个外部工具帮它做事，比如读设计稿、查文档、建页面、查数据库。

不过 MCP 不只有 tools。从协议能力看，常见还有：

  1. tools：工具调用，能执行动作。
  2. resources：资源读取，能拿内容。
  3. prompts：提示模板，能提供结构化提示。

5. 为什么说现在是“内置在 agent 里”

现在很多 agent 已经把 MCP client 内置进去了。\所以你看到的是“点一个工具”，背后实际发生的是：\host 发现你要外部能力 → client 去连 server → server 返回工具、资源或提示 → agent 再继续往下做。

如果这个 server 需要登录，就会触发登录认证。
尤其是远程 HTTP 型 MCP server，经常会走授权流程。按官方规范，HTTP 传输下的授权支持 OAuth 2.1（标准授权流程，统一发 token）。

一句话记住这一段：
host 管总流程，client 管连接，server 出能力，MCP 管它们怎么说话。

核心要素：画出 host、多个 client、多个 server 的连接关系，旁边预留“用户总结模块”，写你自己常连的 Figma / GitHub / Notion。
易懂设计建议：把 client 画在 host 里面，避免和 server 画成平级；箭头上直接标 tools / resources / prompts。

四、rag（检索增强生成）幻觉治理方案

RAG（检索增强生成，先找再答）是入库到检索到生成的全链路治理。

幻觉并非单纯是大模型自身的问题，而是由于RAG全链路中数据准备、检索或生成环节存在缺陷所导致的系统性偏差。是入库到检索到生成全链路治理

这一段最适合记成四个字：净、改、排、控。

1. 数据准备（净）

在数据准备阶段，必须采用语义切分（Semantic Chunking，按意思切段）替代机械切分，确保每一段知识的语义完整性，从而从源头净化语料

这里的重点是：切分不是越平均越好，而是语义越完整越好。

因为机械切分很容易把一个完整知识点截断，后面检索到了，模型也不一定能用明白。

2. 用户提问（改）

面对用户模糊的提问，通过问题重写（Query Rewriting，先把问题改清）或生成假设性答案（HyDE，先猜再找）技术，将自然语言转化为更易于被数据库理解的指令

把“人话”改成“更适合机器找资料的话”。
很多用户问题本来就很口语、很模糊，直接检索效果不稳，所以要先改写。

3. 检索优化（排）

混合检索： 检索阶段，向量空间可能混淆相似但不精准的信息， 如产品型号X2000与X1000，从top50文档中筛选出最相关的top5，过滤噪声，优化上下文纯度，大幅降低幻觉，仅靠向量检索的不足，提倡混合检索结合关键词匹配，

重排序 ：为了规避“迷失中间”现象，引入重排序（Reranking，再次精排）模型对初步召回的内容进行精炼，仅将高质量的上下文片段输入模型，

  1. 混合检索：关键词检索 + 向量检索一起上。
  2. 重排序：先召回一批 → 再从里面挑更准的。

为什么要这样做？
因为只用关键词，容易漏掉语义相关；只用向量，又可能把“看起来像但其实不是”的内容拉进来。
所以先混合召回 → 再做重排序，能把噪声压下去。

4. 生成控制（控）

生成阶段，通过Prompt约束和强制引用文档来抑制模型幻觉。提示词约束加证据引用

这一步可以理解成“最后一道闸门”。
前面找来的上下文再好，如果最后生成阶段不约束，模型还是可能顺手补一段没证据的话。
所以这里要做两件事：

  1. 提示词约束：只按资料答。
  2. 证据引用：答案能回溯到文档。

5. 输入法做了第二步问题重写

很多 AI 输入法，本质上就在做“用户提问（改）”这一步。
你说出去的是口语、碎句、半成品表达；输入法会先帮你整理、扩写、改写，再把更像“机器能理解的请求”交给下游模型或系统。

手机端：豆包输入法

电脑端： AI语音输入法

推荐：1.Typeless（www.typeless.com/zh-cn/downl…

  1. 闪电说（shandianshuo.cn/）

核心要素：按“净 → 改 → 排 → 控”画流程，并预留“用户总结模块”，

五、ChatGPT与BERT

chatgpt=gpt+RLHF（人类反馈强化学习）

ChatGPT ：预训练 GPT + SFT（监督微调，人工示范训练）+ RLHF（人类反馈强化学习，按偏好调优）。

Bert 双向读句子，擅长"理解"，不擅长"生成"。 适用于搜索引擎语义匹配、情感分析、文本分类

BERT（双向理解器，前后都看）更适合做“理解型任务”。比如语义匹配、文本分类、情感分析，它的强项是先把句子读明白。

GPT：生成文字的

单向从左往右读，擅长"生成"，不擅长双向理解。

GPT（续写模型，往后生成）更适合做“生成型任务”。
它的优势是按上下文往下写、往下接、往下回答。

这两者的区别，可以先记成一句很直白的话：
BERT 更像“看懂题的人”，GPT 更像“继续往下写的人”。

核心要素：左边画 BERT 双向读句子，右边画 GPT 从左往右生成，预留“用户总结模块”，写你自己的记忆口诀。
易懂设计建议：BERT 用双向箭头，GPT 用单向箭头，标题直接写“理解”和“生成”。

六、现代大模型通常三种都用

先学语言 → 再学回答 → 最后学偏好。

第一步：无监督预训练
  → 喂海量文本，预测下一个词，学会语言知识
  → 不需要标注，但需要巨量算力

第二步：监督微调（SFT, Supervised Fine-Tuning）
  → 人工写高质量问答对，教模型怎么回答问题
  → 需要标注，但数据量少得多

第三步：RLHF
  → 人类评分员对模型回答打分，模型学会符合人类偏好
  → 这就是 ChatGPT 比普通 GPT 更好用的原因

下面以简单的pytorch框架简单展示一下三种如何具体处理，

（一）无监督预训练

预测下一个词！！ 预训练语言模型（先大量读文本）靠这个过程把语言规律先学出来。

from transformers import GPT2LMHeadModel, GPT2Tokenizer
import torch

# 加载预训练模型（这是已经训练好的，实际预训练需要几千块GPU跑几个月）
tokenizer = GPT2Tokenizer.from_pretrained("gpt2")  # 分词器
model = GPT2LMHeadModel.from_pretrained("gpt2")

# 预训练的核心：计算下一个词的预测损失
text = "今天天气真的很"
# tensor 是pytorch专用数字容器，模型只吃tensor
inputs = tokenizer(text, return_tensors="pt")  # tensor张量（升级版数组）

# labels 就是 inputs 本身，模型预测每个位置的下一个词
outputs = model(**inputs, labels=inputs["input_ids"])

loss = outputs.loss          # 预测错误的程度
logits = outputs.logits      # 对字典里所有词的打分，每个词的概率分布

# 训练就是不断最小化这个 loss
# loss 越小 = 预测越准 = 模型越懂语言
loss.backward()              # pytorch内置方法反向传播，计算梯度
optimizer.step()             # pytorch更新模型权重工具，根据梯度更新参数

（二）高质量问答对（SFTTrainer）

SFT（监督微调，人工示范训练），“学会怎么更像人类想要的方式来回答”。

from transformers import AutoModelForCausalLM, AutoTokenizer
from datasets import Dataset

# 高质量问答对数据
sft_data = [
    {
        "prompt": "如何健康减肥？",
        "response": "健康减肥需要结合饮食控制和适量运动。建议每天保持500卡路里的热量缺口，优先选择高蛋白低脂肪食物..."
    },
    {
        "prompt": "怎么戒烟？",
        "response": "戒烟建议采用循序渐进的方式：1. 设定戒烟日期 2. 告知家人朋友获得支持 3. 可配合尼古丁替代疗法..."
    }
]

# 把问答对拼成模型输入格式
def format_prompt(example):
    return {
        "text": f"问：{example['prompt']}\n答：{example['response']}"
    }

# 用这些数据继续训练预训练模型
# 和预训练的区别：数据少但质量高，学习率更小，训练轮次少
model = AutoModelForCausalLM.from_pretrained("gpt3")

# 实际工程中用 trl 库的 SFTTrainer 更方便
from trl import SFTTrainer
trainer = SFTTrainer(
    model=model,
    # 把问答对数据注入
    train_dataset=Dataset.from_list(sft_data),
    dataset_text_field="text",
    max_seq_length=512,
)
trainer.train()

（三）RLHF（人类反馈强化学习，按偏好调优）

它解决的是“回答像不像人想要的样子”，

from trl import PPOTrainer, PPOConfig, AutoModelForCausalLMWithValueHead
from transformers import pipeline

# =======Step 1：奖励模型（人类排序数据训练出来的）=========
# 输入一段回答，输出一个分数
reward_model = pipeline("text-classification", model="reward-model")

def get_reward(response: str) -> float:
    """奖励模型给回答打分，分数越高越好"""
    result = reward_model(response)
    return result[0]["score"]

# ========Step 2：PPO 强化学习训练==========
config = PPOConfig(
    learning_rate=1e-5,
    batch_size=16,
)
# 加载
ppo_model = AutoModelForCausalLMWithValueHead.from_pretrained("sft-model")
# PPO 训练器对象：负责根据分数改模型
ppo_trainer = PPOTrainer(config, ppo_model)  # trl 库官方模板

# ！！！循环训练数据集！！！核心！！！
for batch in dataloader:  # dataloader 数据加载器
    query = batch["prompt"]  # 取出批次中用户生成的文本
    response = ppo_model.generate(query)  # trl 训练器内置生成文字方法

    # 奖励模型打分
    reward = get_reward(response)  # 自定义打分函数

    # PPO 更新：分高的回答方式被强化，分低的被抑制
    ppo_trainer.step(query, response, reward)  # trl 训练器更新模型参数 .step

# 最终得到 ChatGPT 这样符合人类偏好的模型

七、BM25、双塔、Cross-Encoder、LambdaMART 怎么串起来

1. BM25 是干什么的？

BM25 是纯关键词匹配**算法，无法理解语义，只能匹配字面词频

BM25（关键词打分，只看字面）最大的优势是快。
所以它特别适合做第一层粗排：先从海量文档里捞出一批“字面上看起来相关”的候选。

但它的问题也很明显：\它只看词，不懂意思。\所以只用 BM25，很容易出现“关键词对了，但实际不是你要的内容”。

2. 双塔模型是干什么的？

双塔模型：捕捉语义关联 进行稠密检索；两个塔”（Query 塔 + Doc 塔），规定 Query 和 Doc 分别处理，常由 BERT 或其变体（如 Sentence-BERT）实现，BERT 负责把文本转成语义向量，让双塔既能快速匹配又有一定语义精度。”

  • 早期双塔模型可能用简单的编码器（比如 Word2Vec），但现在工业界几乎都用 BERT 及其变体（RoBERTa、ALBERT），因为 BERT 能理解上下文语义（比如区分 “苹果手机” 和 “苹果水果”），让双塔的匹配精度提升一个档次；

  • 两个塔的 BERT 可以共享参数（节省训练成本），也可以独立训练（针对 Query/Doc 优化），但核心编码逻辑全靠 BERT。

双塔模型（两边各自编码）适合做稠密检索（按语义找相近内容）。
它的系统价值在于：
Doc 侧向量可以提前离线算好并存起来，线上只需要把 Query 编成向量，再去向量库里找近邻。
所以它比 Cross-Encoder 快得多，又比纯 BM25 更懂语义。

一句话记：
BM25 抓字面，双塔抓语义。

3. Cross-Encoder 为什么更准，但不能全程都用？

Cross-Encoder 需为每个 Query-Doc 对单独执行模型推理，100 个候选文档需跑 100 次模型，故速度慢。纯 Cross-Encoder 推理成本高、延迟大，高并发场景下服务器无法承载，仅适用于低并发、少量文档场景。

Cross-Encoder（拼在一起深度判断）更像“高清加工机器”。
它会把 Query 和 Doc 放到同一个模型里一起看，所以判断通常更细、更准。

但问题也在这里：
它不是一次看一库，而是一次看一对。
候选文档一多，推理成本立刻上去。
所以工业界通常不会让它负责全量召回，而是让它只处理前面已经筛出来的一小批候选。

一句话记：\

双塔适合“先筛一大片”，Cross-Encoder 适合“再认真检查一小撮”。

4. LambdaMART 到底是干什么的？

LambdaMART 是 LTR 算法的经典实现，核心目标是通过历史数据学习 “文档排序规则”。

LambdaMART 不直接运行 BM25 或 Cross-Encoder，而是将两者的输出分数作为 “特征输入”，通过 LTR 算法学习综合排序规则

LambdaMART（学习排序模型，学怎么排先后）不是自己去“查文档”，也不是自己去“做深度语义理解”。
它更像一个总排序器：
把前面各环节产出的分数、规则、特征收进来，再学出一个更稳的排序规则。

5. 请简述 LambdaMART 结合 BM25 和 Cross-Encoder 的具体流程。

① 特征收集：对粗排后的候选文档，分别计算 BM25 关键词分数、双塔模型语义相似度分数、Cross-Encoder 深度语义分数（可选 Top N 文档计算）、业务规则分数（如官方文档权重、发布时间）；

② 模型推理：将所有特征输入训练好的 LambdaMART 模型，输出每个文档的综合排序分数；

③ 结果输出：按综合分数降序排列，取 Top N 文档传给 LLM。

先收集多种分数 → 再统一交给 LambdaMART → 最后把排好的 Top N 给 LLM。

6. 为什么工业界常常是“BM25 + 双塔 + Cross-Encoder + LambdaMART”这套组合？

从系统角度看，这套组合是在平衡三件事：

  1. 速度。2. 准确率。3. 成本。

只用 BM25，快，但不够懂语义。
只用双塔，懂语义，但还不够细。
只用 Cross-Encoder，最细，但太慢。
只用 LambdaMART，也不行，因为它得先吃到前面这些特征。

所以工业界常见做法是：

  1. BM25：先抓关键词。
  2. 双塔：再补语义召回。
  3. Cross-Encoder：对小批候选做深度判断。
  4. LambdaMART：把多路分数和业务规则综合起来。

7. 落地场景：搜索引擎（百度 / 谷歌的粗排阶段）

  • 核心作用：从爬虫抓取的亿级网页中，快速筛选出和用户查询相关的 Top500 网页
  • 逻辑：先通过双塔模型做「稠密检索」（捕捉语义关联）+ BM25 做「稀疏检索」（捕捉关键词匹配），两者结果融合后，再交给 LambdaMART 或其他精排模型处理
  • 为什么不用 Cross-Encoder：亿级网页若用 Cross-Encoder 逐一对齐，单次查询需要几分钟，用户根本无法接受

BM25 / 双塔召回 → Cross-Encoder 精排 → LambdaMART 综合排序 → Top N 给 LLM

8. 未来看法

工具层、协议层、模型层这些现象，业内已经讲了很多。项目真进主流程以后，卡人的地方更硬。过去二十年，软件吃掉的是规则清楚、边界清楚、责任清楚的工作。AI 现在开始碰判断性劳动。判断性劳动里有经验、有上下文、有例外、有责任归属。企业以前把这些东西放在人身上，用会议、审批、师徒带、口头默契来维持。AI 一接进来，系统先要把这些东西写成机器能执行的对象。多数公司没有做过这一步，所以项目越往深处走，摩擦越大。

知识库为什么老出问题？
很多人说召回不准、重排不稳，这些都对，但还停在技术层。更深一层的问题在知识本身。企业文档大多不是“事实仓库”，它更像协作痕迹。很多文档写的是结论，没写判断过程；写的是标准流程，没写例外条件；写的是公开口径，没写真实取舍。人能用这些资料，是因为人脑会自动补上下文，会参考组织关系，会知道哪些话是正式表述，哪些话才是实际做法。模型拿不到这些隐含信息，系统就只能在残缺材料上继续往前推。RAG 到了这里，经常不是检索能力不够，知识对象本身就不完整。很多团队一直调 chunk、调 embedding、调 rerank，文档生产方式却没变，这样很难把质量拉上去。

权限为什么会变成更难啃的骨头?
也不只是“安全要求高”这么简单。很多业务动作以前能走通，靠的是人能承担模糊责任。老员工知道这个单子虽然流程上可以过，当前客户状态不对，先压一下；主管知道这个字段虽然能改，今晚结算批次要跑，先别动。系统权限表达的是静态授权，组织运行依赖的是情境判断。AI 要往下执行，就得把这种情境判断提前写进系统。这个活非常重，因为它要求企业把“谁在什么条件下有多大裁量空间”写明白。很多公司平时并没有把这件事说明白，它只是靠熟人网络和经验维持。agent 一进来，这个缺口马上露出来。

成本问题？
大家平时看模型单价, 真实账单不是这样来的。长链路任务一跑，费用从模型调用扩散到上下文膨胀、工具等待、重复重试、人工复核、失败补偿、审计存档。这里还有一个常被低估的点：判断性劳动的单位成本不稳定。两个看起来差不多的任务，探索深度可能差十倍，工具跳转次数可能差十倍，人工介入频率也可能差十倍。企业原来的软件预算习惯按席位、按模块、按流程节点来算，AI 这套账按任务波动来长，财务口径和技术口径很容易对不上。很多项目后面会卡在这里，不是技术跑不动，是成本解释不清。

厂商为什么都在抢 runtime、MCP、sandbox、agent framework？
原因也没有多神秘。模型层利润会压，替换速度也快。运行时、上下文、工具权限、审计日志一旦进了某个平台，迁移成本就起来了。谁握着任务状态，谁就知道系统现在做到哪一步；谁握着权限编排，谁就决定 agent 能进哪些业务环节；谁握着审计和费用流水，谁就能定义企业的接入边界。这个位置比单纯卖模型更稳，也更难替换。OpenAI 在 2025 年 5 月 把 remote MCP、内置工具、后台执行并到 Responses API，2026 年 4 月 又把 Agents SDK 往 sandbox 和长任务执行上推，2026 年 4 月 22 日 专门讲 WebSocket 优化 agent loop，这些动作都指向同一个方向：厂商在抢任务运行层，不只抢模型调用层。微软在 2026 年 2 月 把 MCP server certification 做成正式流程，也说明企业接入已经往发布者验证、认证方式、审计、遥测这些位置压了。

接下来半年到一年，项目会往两个方向分开走。
第一类项目会继续铺得很广，放在读、搜、写草稿、汇总、辅助判断这些环节。这类环节对权限和责任链的要求没那么硬，系统容易先跑起来。

第二类项目会往系统写操作、审批动作、跨系统执行这些位置试探，这类项目推进会慢很多。企业会在这些位置加人工接管点，加审计点，加回滚点。agent 能不能进主流程，团队会盯住长任务稳定性、状态一致性、费用波动、回查能力。模型答得漂不漂亮，权重会往后放。

产品层也会分得更开。能继续往企业内部走的团队，手里通常会有三样东西：系统记录入口，组织权限入口，责任链入口。谁只握模型壳，谁就容易变成替换件。

还有一个更深的变化，企业这轮接 AI其实在补过去大量靠人脑、靠习惯、靠关系运转的判断，现在要开始写进系统的旧账。这件事比换模型难得多，也慢得多。它会逼着公司把数据口径、权限边界、例外处理、责任归属重新梳一遍。谁以前这些地方就清楚，谁推进得就快；谁以前靠模糊空间运转，谁接下来就会很疼。

参考链接

  1. cc switch： GitHub ｜ SourceForge mirror
  2. Claude Code slash commands： Anthropic 官方文档
  3. Claude Code subagents： Anthropic 官方文档
  4. Claude Code interactive mode / Plan Mode： Anthropic 官方文档 ｜ Common workflows
  5. Claude Code getting started / doctor： Anthropic 官方文档
  6. MCP architecture： Model Context Protocol 官方文档
  7. MCP prompts： Model Context Protocol 官方文档
  8. MCP authorization / OAuth 2.1： Model Context Protocol 官方文档
  9. Typeless： 官网
  10. 闪电说： 官网
  11. LMSYS Projects： 官网
  12. 小米 MiMo 活动页： 官网
avatar
文章
阅读
粉丝