Agent 的需求理解质量如何具体实现：从意图识别到槽位补全、追问与确认机制

疯狂成瘾者2026-04-29 20:10

文章目录

在 Agent 系统中，需求理解质量并不只是传统 NLP 里的"意图识别准确率"。一个真正可用的 Agent，不仅要知道用户大概要做什么，还要理解用户的目标、约束条件、偏好、上下文依赖、系统状态，以及当前任务还缺少哪些关键信息。

换句话说，需求理解质量衡量的是 Agent 是否能回答清楚以下几个问题：

用户到底要完成什么任务？

用户已经提供了哪些信息？

哪些信息可以从上下文、用户画像或系统状态中继承？

哪些信息可以通过默认策略合理处理？

哪些信息缺失但不影响继续执行？

哪些信息缺失且必须追问？

哪些操作在执行前必须二次确认？

这类能力不是单靠一个 Prompt 就能稳定实现的，而是需要把意图识别、槽位抽取、结构化输出、上下文管理、缺失信息判断、追问策略、工具调用和安全确认机制组合成完整链路。

一、需求理解的本质：从"识别意图"升级为"构建可执行任务"

传统聊天机器人通常会先判断用户意图，例如"订机票""查订单""修改密码""创建会议"。但 Agent 要进一步把自然语言请求转化为一个可执行任务对象。

例如用户说：

明天下午帮我约一下王总，别太晚，线上就行。

一个低质量系统可能只识别出"创建会议"意图，然后立刻追问一堆问题：

  • 会议几点？
  • 会议多久？
  • 王总是谁？
  • 会议主题是什么？
  • 用什么会议工具？
  • 是否发送邀请？

但一个更好的 Agent 应该先构建任务理解：

json 复制代码 
{
  "intent": "create_calendar_event",
  "goal": "预约与王总的线上会议",
  "participants": ["王总"],
  "date": "明天",
  "time_preference": "下午，不要太晚",
  "location_type": "online",
  "missing_fields": ["具体参会人身份或联系方式", "具体时间"],
  "can_default": {
    "duration": "30分钟",
    "meeting_tool": "默认线上会议工具"
  },
  "need_user_clarification": true,
  "clarification_reason": "无法唯一确定王总和具体会议时间"
}

这就是从"意图识别"升级为"任务建模"。OpenAI Agents SDK 对 Agent 的定义也体现了这一点：Agent 是由 LLM、指令、工具，以及可选的 handoffs、guardrails 和 structured outputs 等运行时能力组成的应用单元，不只是一个分类器。(OpenAI)

二、第一步：定义任务类型或意图模板

需求理解的第一层是定义系统支持哪些任务类型。任务类型可以来自业务场景，例如：

复制代码 
create_calendar_event     创建日程
book_flight               预订机票
query_order               查询订单
refund_order              申请退款
send_email                发送邮件
delete_file               删除文件
generate_report           生成报告
search_knowledge_base     查询知识库

每个任务类型都应该定义：

复制代码 
任务名称
任务描述
适用场景
必要槽位
可选槽位
默认策略
可继承字段
是否需要工具调用
是否属于高风险操作
执行前是否需要确认

例如"创建会议"的任务模板可以是：

json 复制代码 
{
  "intent": "create_calendar_event",
  "required_slots": [
    "participants",
    "date",
    "time"
  ],
  "optional_slots": [
    "duration",
    "title",
    "location",
    "meeting_tool",
    "description"
  ],
  "defaults": {
    "duration": "30分钟",
    "meeting_tool": "Google Meet 或系统默认会议工具"
  },
  "confirmation_required": true
}

这样做的目的，是让 Agent 不只是"理解一句话"，而是能把用户输入映射到稳定的业务结构中。

Dialogflow CX 官方文档中也有类似思想：参数用于捕获并引用终端用户在会话中提供的值，每个参数都有名称和实体类型；相比原始文本，参数是可被逻辑处理和响应生成使用的结构化数据。(Google Cloud Documentation)

三、第二步：为每类任务设计槽位 Schema

任务类型确定后，需要为每类任务设计槽位 schema。槽位可以理解为执行任务所需的结构化字段。

以"订机票"为例：

json 复制代码 
{
  "intent": "book_flight",
  "slots": {
    "departure_city": {
      "type": "string",
      "required": true,
      "source": ["user_input", "user_profile", "context"]
    },
    "arrival_city": {
      "type": "string",
      "required": true
    },
    "departure_date": {
      "type": "date",
      "required": true
    },
    "return_date": {
      "type": "date",
      "required": false
    },
    "passengers": {
      "type": "array",
      "required": true
    },
    "cabin_class": {
      "type": "enum",
      "values": ["economy", "premium_economy", "business", "first"],
      "default": "economy"
    },
    "price_preference": {
      "type": "string",
      "required": false
    },
    "time_preference": {
      "type": "string",
      "required": false
    }
  }
}

这样 Agent 才能判断：

  • "明天"应该解析成具体日期。
  • "上海到北京"对应出发地和目的地。
  • "别太晚"是时间偏好，不是具体时间。
  • "便宜点"是价格偏好，不是严格预算。
  • "帮我订"属于高风险动作，最终下单前必须确认。

Rasa 官方文档也把 slot 描述为助手收集或推断出的有状态 key-value 信息；Collect step 用于请求用户提供信息并填充 slot，直到该 slot 被填充后才继续执行后续流程。(rasa.com)

四、第三步：用结构化输出承接模型理解结果

在大模型 Agent 中，不能只让模型自由输出一段自然语言解释，而应该让模型按照 schema 输出结构化结果。这样后端才能稳定判断下一步是执行、追问、确认还是拒绝。

OpenAI Structured Outputs 官方文档说明，结构化输出可以确保模型响应符合开发者提供的 JSON Schema，避免模型遗漏必填 key 或生成无效枚举值。(OpenAI开发者)

例如可以让模型输出：

json 复制代码 
{
  "intent": "book_flight",
  "confidence": 0.91,
  "slots": {
    "departure_city": "上海",
    "arrival_city": "北京",
    "departure_date": "2026-04-28",
    "return_date": null,
    "passengers": null,
    "cabin_class": "economy",
    "price_preference": "尽量便宜",
    "time_preference": "不要太晚"
  },
  "missing_required_slots": [
    "passengers"
  ],
  "ambiguous_slots": [
    {
      "slot": "time_preference",
      "value": "不要太晚",
      "interpretation": "优先选择18:00前到达或出发的航班"
    }
  ],
  "can_proceed_with_defaults": false,
  "need_clarification": true,
  "clarification_questions": [
    "请问乘机人是谁？"
  ],
  "need_confirmation_before_action": true,
  "risk_level": "high"
}

这里的重点不是让模型"回答用户"，而是先让模型"生成一个可执行的任务理解对象"。后端可以基于这个对象继续做业务判断。

五、第四步：意图识别、槽位抽取和参数解析分层处理

一个稳定的实现通常不会把所有事情都交给模型一次性完成，而是分层处理：

复制代码 
用户输入
  ↓
意图识别
  ↓
槽位抽取
  ↓
参数标准化
  ↓
上下文继承
  ↓
缺失信息判断
  ↓
追问或执行

1. 意图识别

判断用户要做什么，例如：

json 复制代码 
{
  "intent": "create_calendar_event",
  "confidence": 0.88
}

如果置信度较低，可以进入澄清流程：

你是想创建一个日程，还是只是查询王总的空闲时间？

2. 槽位抽取

从用户输入中抽取任务参数：

json 复制代码 
{
  "participants": ["王总"],
  "date_text": "明天",
  "time_preference": "下午，别太晚",
  "location_type": "online"
}

3. 参数标准化

把自然语言表达转成系统可处理格式：

json 复制代码 
{
  "date": "2026-04-28",
  "time_window": {
    "start": "13:00",
    "end": "17:30"
  },
  "location_type": "video_meeting"
}

这一步非常关键。用户说的"明天""下周五""月底前""别太晚""便宜点""附近""尽快"，都不能直接丢给业务系统，而要转成可执行约束。

4. 参数校验

检查参数是否合法：

复制代码 
日期是否在未来
邮箱格式是否正确
金额是否超过限制
用户是否有权限操作目标资源
订单是否属于当前用户
删除对象是否存在

OpenAI 的 function calling 文档说明，函数工具可以通过 JSON Schema 定义，让模型与应用提供的数据和动作连接；模型可以决定调用哪些函数以及使用什么参数。(OpenAI开发者) 但参数是否真正合法、是否有权限执行，仍然应该由后端校验。

六、第五步：优先从上下文、用户画像和系统状态中补全信息

好的 Agent 不应该一缺信息就追问。追问会打断任务流，降低用户体验。更合理的策略是：

复制代码 
先看当前用户输入有没有
再看当前会话上下文有没有
再看用户画像或长期偏好有没有
再看系统状态有没有
再看是否可以使用默认值
最后才判断是否必须追问

例如用户说：

还是发给上次那个客户吧。

如果上下文中刚刚提到"上次那个客户"是 alice@example.com，Agent 可以继承这个对象，而不是机械追问"请问客户是谁"。

又如用户说：

明天早上继续安排那个会议。

Agent 需要从上下文中继承"那个会议"的主题、参会人、会议方式，然后只补齐日期和时间。

一个后端状态对象可以这样设计：

json 复制代码 
{
  "session_context": {
    "last_task": "create_calendar_event",
    "last_participants": ["alice@example.com"],
    "last_topic": "项目评审",
    "last_location_type": "online"
  },
  "user_profile": {
    "default_meeting_duration": "30分钟",
    "work_hours": {
      "start": "09:00",
      "end": "18:00"
    },
    "preferred_meeting_tool": "Google Meet"
  },
  "system_state": {
    "calendar_available": true,
    "timezone": "Asia/Tokyo"
  }
}

然后由补全器生成：

json 复制代码 
{
  "participants": {
    "value": ["alice@example.com"],
    "source": "session_context",
    "confidence": 0.86
  },
  "duration": {
    "value": "30分钟",
    "source": "user_profile",
    "confidence": 0.95
  },
  "timezone": {
    "value": "Asia/Tokyo",
    "source": "system_state",
    "confidence": 1.0
  }
}

Rasa 的 slot 机制也体现了类似思想：slot 是助手持有的状态信息，可以表示用户已经提供或助手已经推断出的值。(rasa.com)

七、第六步：判断哪些信息可以默认，哪些必须追问

需求理解质量的关键，不在于"发现缺失信息"，而在于"判断缺失信息是否真的需要问"。

可以把槽位分成四类：

类型 示例 处理方式
可直接解析 "明天""下周五""三点后" 转成具体日期或时间范围
可默认处理 "别太晚""别太贵""随便找个会议链接" 使用业务默认策略
可继承处理 "还是发给他""继续上次那个" 从上下文或用户画像继承
必须追问 出发地、乘客、收件人、付款方式 合并追问

例如：

复制代码 
"明天" → 可以转成具体日期
"别太晚" → 可以转成时间偏好
"便宜点" → 可以转成排序策略
"从这里出发" → 如果有定位权限可继承，否则追问
"给王总发邮件" → 如果联系人唯一可继承，否则追问
"帮我下单" → 执行前必须确认

追问策略应该遵循一个原则：只问影响下一步执行的关键信息，并尽量合并问题。

不好的追问：

请问出发地是哪里？

请问目的地是哪里？

请问日期是哪天？

请问乘客是谁？

请问舱位是什么？

更好的追问：

我还需要确认两项信息：从哪里出发，以及乘机人是谁？舱位我可以先按经济舱处理。

这样既减少打断，又保持任务可执行。

八、第七步：为模糊偏好设计默认策略

用户经常不会给出精确参数，而是使用偏好表达：

复制代码 
别太晚
别太贵
尽快
附近
安静一点
正式一点
简单一点
性价比高
不要太复杂

这些表达不应该一律追问，而应该转成默认策略。

例如订票场景：

json 复制代码 
{
  "preference": "别太晚",
  "policy": {
    "type": "time_preference",
    "default_interpretation": "优先选择18:00前到达",
    "strict": false
  }
}

餐厅推荐场景：

json 复制代码 
{
  "preference": "别太贵",
  "policy": {
    "type": "price_preference",
    "default_interpretation": "优先选择中低价位，人均不超过默认预算",
    "strict": false
  }
}

会议安排场景：

json 复制代码 
{
  "preference": "别太晚",
  "policy": {
    "type": "time_preference",
    "default_interpretation": "优先安排在工作时间内，且不晚于17:30开始",
    "strict": false
  }
}

这里要注意，偏好不是硬约束。Agent 可以先按默认策略执行搜索或规划，然后把解释带给用户：

我按"不要太晚"理解为优先选择 18:00 前到达的航班，先帮你筛选这一类。

这种做法比直接追问"别太晚是什么意思"更自然。

九、第八步：高风险操作必须执行前确认

需求理解质量还包括一个重要能力：判断哪些动作不能直接执行。

以下操作通常需要确认：

复制代码 
下单
支付
退款
删除
发送邮件
发送消息
提交表单
修改生产数据
取消订单
公开发布内容
授权第三方访问

例如用户说：

帮我把这封邮件发给客户。

如果邮件内容已经生成，Agent 不应该直接发送，而应该确认：

我已准备好邮件，收件人是 alice@example.com，主题是"项目报价确认"。确认后我再发送。

再如用户说：

把这些旧文件都删掉。

Agent 必须明确列出将删除的对象，并让用户确认：

我找到 12 个符合条件的文件。删除后可能无法恢复，请确认是否删除这 12 个文件。

OpenAI Agents SDK 的 guardrails 文档说明，护栏可以在工作流不同阶段运行：输入护栏用于第一个 Agent，输出护栏用于最终输出 Agent，工具护栏会在每次自定义函数工具调用时运行，并可在执行前后检查工具输入与输出。(OpenAI)

因此，在实现上可以把高风险确认设计成工具调用前的 guardrail：

json 复制代码 
{
  "tool": "send_email",
  "risk_level": "medium",
  "requires_confirmation": true,
  "confirmation_summary": {
    "to": "alice@example.com",
    "subject": "项目报价确认",
    "body_preview": "Alice 您好，以下是本次项目报价..."
  }
}

只有用户确认后，后端才真正调用发送工具。

十、第九步：后端编排需求理解流程

一个比较完整的后端实现可以拆成以下模块：

复制代码 
Intent Router             意图路由
Slot Extractor            槽位抽取器
Normalizer                参数标准化器
Context Resolver          上下文补全器
Profile Resolver          用户画像补全器
Default Policy Engine     默认策略引擎
Missing Slot Analyzer     缺失信息分析器
Clarification Planner     追问规划器
Risk Classifier           风险分类器
Confirmation Manager      确认管理器
Tool Executor             工具执行器
Guardrail Engine          护栏引擎
Evaluation Logger         评估日志器

整体链路可以是：

复制代码 
用户输入
  ↓
识别任务类型
  ↓
抽取槽位
  ↓
标准化参数
  ↓
从上下文 / 用户画像 / 系统状态补全
  ↓
判断缺失字段
  ↓
判断是否可以默认处理
  ↓
判断是否需要追问
  ↓
判断是否高风险
  ↓
执行工具或请求确认
  ↓
记录理解结果和评估数据

对应伪代码如下：

python 复制代码 
def understand_user_request(user_input, session_context, user_profile, system_state):
    # 1. 意图识别
    intent_result = classify_intent(user_input)

    # 2. 加载任务 schema
    task_schema = load_task_schema(intent_result.intent)

    # 3. 槽位抽取
    extracted_slots = extract_slots(user_input, task_schema)

    # 4. 参数标准化
    normalized_slots = normalize_slots(
        extracted_slots,
        timezone=system_state.timezone,
        locale=user_profile.locale
    )

    # 5. 上下文补全
    resolved_slots = resolve_from_context(
        normalized_slots,
        session_context,
        user_profile,
        system_state,
        task_schema
    )

    # 6. 默认策略补全
    resolved_slots = apply_default_policies(
        resolved_slots,
        task_schema.defaults
    )

    # 7. 缺失信息分析
    missing_analysis = analyze_missing_slots(
        resolved_slots,
        task_schema.required_slots
    )

    # 8. 风险判断
    risk = classify_risk(
        intent=intent_result.intent,
        slots=resolved_slots,
        task_schema=task_schema
    )

    # 9. 追问或确认
    if missing_analysis.must_ask:
        return build_clarification_response(missing_analysis)

    if risk.requires_confirmation:
        return build_confirmation_response(intent_result.intent, resolved_slots)

    # 10. 可以执行
    return build_executable_task(intent_result.intent, resolved_slots)

十一、第十步：把追问也做成可评估对象

很多 Agent 的问题不在于不能追问，而是追问质量差。常见问题包括：

复制代码 
问了不必要的问题
一次只问一个问题，导致多轮打断
重复询问已经提供的信息
没有解释为什么要问
没有区分可选信息和必填信息
没有利用上下文继承

因此追问本身也应该结构化：

json 复制代码 
{
  "need_clarification": true,
  "missing_slots": [
    {
      "slot": "passengers",
      "reason": "订票必须知道乘机人",
      "priority": "high"
    },
    {
      "slot": "departure_city",
      "reason": "当前上下文无法确定出发地",
      "priority": "high"
    }
  ],
  "optional_slots_not_asked": [
    {
      "slot": "cabin_class",
      "default": "economy",
      "reason": "可以默认经济舱"
    }
  ],
  "question": "我还需要确认两项信息：从哪里出发，以及乘机人是谁？舱位我可以先按经济舱处理。"
}

这样可以避免 Agent 机械地逐字段追问。

十二、第十一步：需求理解质量如何评估

需求理解质量最终要靠评估体系衡量，而不是只看模型回答是否"看起来合理"。

可以从以下维度评估：

1. 意图识别准确率

Agent 是否正确判断用户要做什么。

复制代码 
用户要创建会议，是否误判为查询日程？
用户要退款，是否误判为查询订单？
用户只是询问信息，是否误判为执行操作？

2. 槽位抽取准确率

Agent 是否正确抽取任务参数。

复制代码 
"明天下午三点"是否正确解析为日期和时间？
"发给王总"是否正确识别为收件人？
"上海到北京"是否正确识别出发地和目的地？

3. 参数标准化准确率

自然语言是否被转成系统可执行格式。

复制代码 
"明天" → 具体日期
"下周五" → 具体日期
"别太晚" → 时间偏好
"便宜点" → 排序策略

4. 上下文继承准确率

Agent 是否正确使用历史信息。

复制代码 
是否继承了上一次提到的客户？
是否错误继承了过期上下文？
是否把"他"解析成了正确联系人？

5. 缺失信息判断准确率

Agent 是否知道什么还缺。

复制代码 
是否发现缺少乘客信息？
是否发现缺少收件人？
是否发现缺少具体执行对象？

6. 追问必要性判断

Agent 是否只问必须问的问题。

复制代码 
是否没有追问可默认处理的信息？
是否追问了影响执行的关键信息？
是否合并追问，减少多轮打断？

7. 高风险确认准确率

Agent 是否在关键操作前请求确认。

复制代码 
发送前是否确认？
支付前是否确认？
删除前是否确认？
提交前是否确认？

8. 任务可执行率

最终生成的任务对象是否能被后端直接执行。

复制代码 
schema 是否完整
参数是否合法
权限是否可校验
工具调用是否明确
风险状态是否清晰

十三、一个完整示例：订机票需求理解流程

用户输入：

帮我订明天下午从上海到北京的机票，别太晚，便宜点。

1. 初步理解

json 复制代码 
{
  "intent": "book_flight",
  "slots": {
    "departure_city": "上海",
    "arrival_city": "北京",
    "departure_date": "2026-04-28",
    "time_preference": "下午，别太晚",
    "price_preference": "便宜点"
  }
}

2. 参数标准化

json 复制代码 
{
  "departure_city": "上海",
  "arrival_city": "北京",
  "departure_date": "2026-04-28",
  "departure_time_window": {
    "start": "12:00",
    "end": "18:00"
  },
  "sort_policy": [
    "price_ascending",
    "arrival_before_20:00"
  ]
}

3. 缺失信息判断

json 复制代码 
{
  "missing_required_slots": [
    "passengers"
  ],
  "defaulted_slots": {
    "cabin_class": "economy"
  },
  "need_clarification": true
}

4. 合并追问

Agent 不应该问：

你要什么舱位？

你能接受多少钱？

你几点出发？

乘客是谁？

更好的回答是：

我可以先按经济舱、价格优先，并优先筛选明天下午出发且不太晚到达的航班。还需要确认乘机人是谁？

5. 用户补充

就我自己。

系统从用户画像中补全乘机人信息：

json 复制代码 
{
  "passengers": [
    {
      "name": "当前用户",
      "source": "user_profile"
    }
  ]
}

6. 搜索航班

Agent 可以调用航班搜索工具，但不能直接下单。

json 复制代码 
{
  "tool": "search_flights",
  "arguments": {
    "departure_city": "上海",
    "arrival_city": "北京",
    "departure_date": "2026-04-28",
    "time_window": {
      "start": "12:00",
      "end": "18:00"
    },
    "passengers": 1,
    "cabin_class": "economy",
    "sort": "price_ascending"
  }
}

7. 下单前确认

如果用户选择某个航班并说"就这个"，Agent 仍然需要确认：

确认预订：4 月 28 日上海飞北京，经济舱，乘机人为你本人，票价 980 元。确认后我再下单。

这就是需求理解质量在真实任务中的体现：能执行，但不越权；能默认，但不乱猜；能追问，但不打断过度。

十四、工程实现建议

如果要在项目中落地，可以按以下优先级实现。

第一阶段，先建立任务 schema。

不要一开始就追求通用智能体，先把核心业务任务定义清楚，包括必填槽位、可选槽位、默认值、风险等级和确认策略。

第二阶段，使用结构化输出。

让模型输出稳定 JSON，而不是自然语言。后端只消费结构化结果。

第三阶段，实现上下文补全。

把当前会话、历史任务、用户画像和系统状态统一成 context object，供模型和后端补全槽位。

第四阶段，实现缺失信息分析器。

不是缺什么就问什么，而是判断哪些必须问、哪些可以继承、哪些可以默认、哪些可以稍后再问。

第五阶段，实现确认与护栏。

对高风险工具调用设置确认机制，对工具输入输出做 guardrail 校验。

第六阶段，建设评估集。

收集真实用户请求，标注 intent、slots、missing slots、default policy、clarification question 和 confirmation requirement，用于持续评估 Agent 需求理解质量。

十五、结论：好的 Agent 不是"多问"，而是"会判断"

需求理解质量的核心，不是 Agent 能不能识别出一个意图，而是它能否把用户的自然语言请求转化为一个安全、完整、可执行的任务对象。

一个高质量 Agent 应该做到：

复制代码 
能判断用户要做什么
能抽取用户已经提供的信息
能把自然语言参数标准化
能从上下文、用户画像和系统状态中补全信息
能区分硬约束和软偏好
能合理使用默认策略
能只追问真正影响执行的关键信息
能在高风险操作前请求确认
能把最终任务交给后端稳定执行

因此，需求理解质量不是单点能力，而是一套完整工程链路。它由任务 schema、槽位抽取、结构化输出、上下文管理、默认策略、追问规划、确认机制和护栏系统共同构成。真正优秀的 Agent，不是机械预设一堆问题，也不是遇到缺失信息就打断用户，而是能在"理解、补全、追问、确认、执行"之间做出合理判断。

相关推荐
北京软秦科技有限公司1 小时前
资料验收报告审核再升级，IACheck与AI报告审核共同开创新标准
人工智能
Zzj_tju1 小时前
视觉语言模型技术指南：图像是怎么“接入”语言模型的？视觉编码器、投影层与对齐机制详解
人工智能·语言模型·自然语言处理
Fullde福德负载箱厂家1 小时前
负载箱的日常运维与故障处置：用户应知的设备保养与异常应对
人工智能·制造
jinanwuhuaguo1 小时前
OpenClaw工程解剖——RAG、向量织构与“记忆宫殿”的索引拓扑学（第十三篇）
android·开发语言·人工智能·kotlin·拓扑学·openclaw
大龄程序员狗哥1 小时前
第44篇：命名实体识别（NER）实战——从文本中提取关键信息（项目实战）
人工智能
lpfasd1232 小时前
2026年第17周GitHub趋势周报：AI代理工程化与端侧智能加速落地
人工智能·github
nervermore9902 小时前
2.人工智能学习-环境搭建
人工智能
Flying pigs~~2 小时前
LoRA 面试完全指南：低秩分解原理 + Transformer 应用
人工智能·深度学习·lora·大模型·微调·transformer
大橙子打游戏2 小时前
薅满火山引擎每天数百万免费 Tokens：我写了一个自动轮换代理
人工智能
热门推荐
01GitHub 镜像站点02近期有什么ai的新消息，新动态？ 2026.4月03Codex 接入 DeepSeek API 完整配置文档042026年4月AI大事件深度解读：大模型竞争进入“深水区“052026年AI编程工具终极横评：Cursor vs Claude Code vs Copilot06【AI】2026 年具身智能模型和世界模型总结07在Windows 11上安装Docker的踩坑记录08零基础教你claude code 接入 deepseek V409VSCode + Copilot下：配置并使用 DeepSeek10实测可用｜小米 MiMo 百万亿 Token 免费领，开发者速冲