Agent 开发总览：从 “会回答” 到 “能完成任务”

# Agent 开发总览：从 “会回答” 到 “能完成任务”

本篇目标

先建立 Agent 的整体心智模型，再理解一次运行如何形成闭环，以及怎样把一个 Agent 做得可靠。学完后，你应该能够用自己的话解释核心原理，并应对相关面试追问。

理解 Agent 本质讲清运行闭环区分相关概念掌握工程与面试表达

# 先记住一句话

Agent 是一个以模型作为决策核心的任务执行系统：它围绕目标获取上下文、选择并调用工具、观察真实结果、更新任务状态，重复这个过程，直到完成任务、确认失败或请求人工介入。

用户目标
  ↓
读取上下文与当前状态
  ↓
模型判断下一步
  ├─ 已满足完成条件 → 返回最终结果
  └─ 需要继续行动
       ↓
     选择工具并生成参数
       ↓
     宿主应用校验权限并执行工具
       ↓
     获得真实结果并更新状态
       ↓
     ↺ 回到 “模型判断下一步”

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

这里最重要的不是 “调用了大模型”，而是形成了一个可受控的闭环：决策 → 行动 → 观察 → 再决策。

面试主线

判断一个系统是不是 Agent，不要只看它会不会聊天或调用 API，而要看三个问题：模型能否根据当前状态决定下一步？能否通过工具影响外部环境？能否根据行动结果继续调整，直至满足停止条件？

# 为什么普通 LLM 还不够

LLM 擅长根据已有上下文生成内容，但它本身并不会读取你的数据库、创建工单或运行测试，也不知道这些操作是否成功。

例如，用户说 “修复项目中的登录问题并验证”：

普通聊天模型可以告诉你排查思路；
带 RAG 的模型可以检索项目文档后给建议；
带 Tool Calling 的模型可以请求读取代码或执行测试；
Agent 会根据每一步结果继续决定：定位文件、修改代码、运行测试、分析失败、再次修正，最后在达到验收条件时停止。

所以，模型负责判断，宿主应用负责执行和控制。这里的宿主应用是承载 Agent 的后端或 Agent Runtime。工具不是由模型直接运行的：模型只产生结构化的调用意图，宿主应用还要校验参数、权限和风险，真正执行工具，再把结果作为新的上下文交回模型。

# 通用运行链路：一次 Agent 运行经历什么

下面描述的是不绑定 Mastra、LangGraph 或 OpenAI Agents SDK 的通用链路。不同框架的 API 和组件名称会变化，但都要解决目标输入、上下文组装、模型决策、工具执行、状态更新与停止判断这些问题。

# 1. 接收目标，而不是只有一句问题

一个好目标至少包含任务、约束和完成标准。例如：

任务：根据我的笔记生成 10 道 Agent 面试题
约束：只能使用指定知识库；每题都要标注依据；不要重复
完成标准：覆盖基础概念、工程可靠性和项目设计三个层级

1
2
3

“帮我准备面试” 过于模糊，Agent 很难判断什么时候算完成。

# 2. 组装本轮上下文

上下文是模型在当前这次调用中能够看到的信息，通常包括系统指令、用户目标、历史消息、检索结果、工具说明和当前任务状态。

上下文窗口是有限的。把全部历史和全部资料都塞进去，不仅成本高，还会让真正重要的信息被噪声淹没。工程上需要检索、摘要、裁剪和优先级管理。

# 3. 模型决定下一步

模型可能选择：

直接回答；
调用某个工具；
把任务拆成若干步骤；
请求用户补充信息或确认高风险操作；
判断目标已经完成并停止。

这一步具有不确定性，因此模型的输出不能直接被当作可信命令。

# 4. 宿主应用执行工具并返回观察结果

宿主应用根据工具的输入 Schema 校验参数，再执行数据库查询、搜索、代码运行或第三方 API 调用。工具返回的是observation（观察结果），而不是一句 “应该成功了”。

例如，Agent 不能因为自己生成了修改代码的动作，就声称问题已经解决；它还需要观察文件 diff、测试结果或线上状态。

# 5. 更新状态并决定是否继续

宿主应用记录已经完成的步骤、工具结果、失败原因和剩余目标。模型结合这些状态重新判断，直到出现明确的停止条件：

成功：验收条件已经满足；
失败：超过重试或步数限制，或者问题不可恢复；
暂停：缺少必要信息，或敏感操作需要人工确认。

# Agent 系统的核心组成

组成	解决的问题	工程上要注意什么
模型（Model / LLM）	如何理解目标并决定下一步	能力、延迟、成本、结构化输出稳定性
指令（Instructions）	应该做什么、不能做什么	明确职责、边界、完成标准和升级规则
上下文（Context）	这次决策需要知道什么	只提供相关信息，控制长度与来源可信度
工具（Tools）	如何读取或改变外部世界	输入 Schema、权限、超时、幂等、错误信息
状态（State / Task State）	任务现在进行到哪里	由宿主应用持久化关键事实，不能只依赖对话文本
记忆（Memory）	跨轮次保留哪些有价值的信息	区分短期与长期记忆，允许纠错、过期和删除
编排（Orchestration）	谁控制流程、何时循环或停止	步数上限、重试策略、人工介入、失败恢复
安全护栏（Guardrails）	哪些输入和操作必须阻止或确认	最小权限、敏感操作审批、输入输出检查
评测与可观测性（Evaluation & Observability）	系统到底好不好、哪里出了问题	记录轨迹、指标和版本，用固定样本持续回归

这些部分不是都由模型完成。一个可靠的 Agent 往往是 “概率性的模型决策 + 确定性的工程控制” 。

这里的 Instructions 通常由 System Prompt 承载，但二者并不完全等价；Workflow 和 Agent Loop 则是 Orchestration 的常见实现方式。

# 容易混淆的概念

# Workflow 和 Agent

	Workflow	Agent
路径由谁决定	代码预先定义	模型根据状态动态决定
优势	可预测、易测试、成本和延迟稳定	能处理步骤数量和路径难以预先确定的任务
风险	遇到未设计分支时不灵活	行为不确定，成本、安全和调试难度更高
适合	审批流、固定数据处理、已知业务规则	研究、排障、编码等开放式任务

实际系统通常采用混合方式：外层 Workflow 控制关键阶段和权限，局部 Agent 处理需要动态判断的步骤。不要为了 “智能” 把本来三步就能写清楚的固定流程改成 Agent。

# Tool Calling 和 MCP

Tool Calling 是模型用结构化数据表达 “我要调用哪个工具、参数是什么” 的能力。
MCP 是连接宿主应用与外部工具、资源和提示模板的标准协议，主要解决不同客户端和服务之间如何统一发现与调用能力。

MCP 不替 Agent 做规划，也不会自动让工具安全可靠。可以把 Tool Calling 理解成 “模型如何提出调用”，把 MCP 理解成 “能力如何以统一方式接入” 。

# Agent、MCP 和 Skill

Skill 不是另一种 Agent，也不是另一种通信协议。按照 OpenAI 对 Agent Skill 的定义，Skill 会把完成某类任务所需的指令、资源和可选脚本封装成可复用的工作方法，让 Agent 能够更稳定地遵循同一套流程。

概念	它是什么	主要解决的问题	单独能否完成任务
Agent	围绕目标持续决策、行动和观察的执行系统	谁来理解目标、决定下一步并判断何时停止	可以，但通常需要工具或其他外部能力
MCP	宿主应用连接外部工具与资源的标准协议	Server 暴露的外部能力如何被统一发现、描述和调用	不可以，它不负责规划和任务闭环
Skill	指令、资源和可选脚本组成的可复用能力包	某类任务应该按照什么方法和规范完成	不可以，它需要 Agent 或宿主加载并执行

可以用一个不完全严谨但容易记忆的类比：

Agent 是员工：接收目标，判断下一步，并对任务结果负责；
Skill 是操作手册：告诉员工遇到某类任务时应该遵循什么步骤、标准和注意事项；
MCP 是标准接口：让员工能够以统一方式使用 GitHub、数据库、浏览器等外部系统。

三者可以组合：Agent 根据任务选择合适的 Skill，Skill 规定执行流程，并指导 Agent 调用 MCP Server 暴露的工具来读取或修改外部系统。Skill 提供做事方法，MCP 规范外部能力的接入方式，Agent 负责运行时决策和闭环。

面试回答

Agent 是执行主体，Skill 是可复用的任务方法，MCP 是连接外部工具和数据的标准协议。MCP 和 Skill 都可以增强 Agent，但它们本身没有完整的目标、决策、观察和停止循环，因此不能直接等同于 Agent。

# Context、Memory 和 RAG

Context：模型当前这一轮能看到的全部信息。
Memory：系统跨步骤或跨会话保存、以后可能再次取回的信息。
RAG：根据当前问题从外部知识源检索相关资料，再放进上下文。

RAG 更像 “查资料”，Memory 更像 “记住任务和用户”。检索到的内容最终仍要进入 Context，模型才能使用。

# 评测和可观测性

评测（Eval）：回答 “结果是否足够好”，例如答案正确率、任务完成率、工具选择准确率。
可观测性（Observability）：回答 “运行时发生了什么”，例如调用链、每步输入输出、耗时、Token、错误与重试。

只有日志没有质量标准，无法判断一次运行是好是坏；只有最终分数没有过程轨迹，也很难定位问题。

# 一个最小 Agent 循环

下面是框架无关的 TypeScript 风格伪代码，重点看职责边界，而不是具体 API：

// 限制一次任务最多执行 8 轮，防止模型因判断错误而无限循环。
const MAX_STEPS = 8

// messages 是本轮 Agent 的短期上下文。
// 后面每次工具调用及其真实结果都会追加进来，供模型继续判断。
const messages = [{ role: 'user', content: goal }]

// Agent 的核心闭环：只要还没满足停止条件，就继续 “决策 → 行动 → 观察”。
for (let step = 0; step < MAX_STEPS; step++) {
  // 模型只能看到当前上下文和允许使用的工具说明。
  // decide 返回两类结果：给出最终答案，或者请求调用某个工具。
  const decision = await model.decide({
    messages,
    tools: toolRegistry.schemas
  })

  // 模型说 “完成” 不代表任务真的完成。
  // verifyCompletion 应结合测试结果、任务状态或业务规则做客观验收。
  if (decision.type === 'final') {
    return verifyCompletion(decision.answer, taskState)
  }

  // 只允许调用注册表中的工具，避免模型凭空构造不存在的能力。
  const tool = toolRegistry.get(decision.toolName)

  // 用 Schema 校验和转换模型生成的参数。
  // 参数不合法时应返回清晰错误，让模型修正，而不是带错执行。
  const args = tool.inputSchema.parse(decision.arguments)

  // 权限检查由宿主应用负责。写文件、发消息、付款等敏感动作可以在这里暂停并请求人工确认。
  await permissionPolicy.check(tool, args)

  // 真正的工具由宿主应用执行，并设置超时；模型本身不能直接访问外部系统。
  // observation 必须保留成功结果或真实错误，作为下一轮决策的事实依据。
  const observation = await runWithTimeout(() => tool.execute(args))

  // 将关键事实写入结构化任务状态，便于恢复、审计和判断完成条件。
  taskState.record(decision, observation)

  // 同时把模型的调用请求和工具结果追加到短期上下文。
  // 下一轮模型便能根据 “刚才做了什么、结果是什么” 调整计划。
  messages.push(decision.message, {
    role: 'tool',
    content: serialize(observation)
  })
}

// 达到执行上限是一种可预期的 “未完成” 状态，不等于系统发生故障。
// 返回中间结果供上层展示，并允许用户选择继续、调整目标或转人工处理。
return {
  status: 'incomplete',
  reason: 'max_steps',
  message: '本次任务尚未完成，已达到最大执行轮数',
  partialResult: taskState.summary(),
  canContinue: true
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

这段代码体现了六个关键点：

模型只能在注册过的工具中选择；
参数必须通过 Schema 校验；
权限、超时和步数由宿主应用控制；
工具结果会成为下一轮决策依据；
最终答案仍要依据任务状态验证，不能只相信模型的自我判断。
达到最大轮数时返回可识别的未完成状态，而不是伪装成功或继续无限循环。

# 达到最大轮数后怎样返回

MAX_STEPS 是 Agent 的安全边界。达到这个上限只说明本次运行没有在预算内完成目标，不一定代表程序异常，因此不应该把原始异常或 500 错误直接展示给用户。

推荐把 Agent 的运行结果设计为明确的状态：

状态	含义	前端处理
`completed`	已通过完成条件验证	展示最终结果
`incomplete`	达到步数、时间或费用上限，但仍有可能继续	展示当前进度，并提供继续执行、调整目标或转人工入口
`requires_action`	缺少信息，或敏感操作需要用户确认	告诉用户需要补充或确认什么
`failed`	发生不可恢复的工具错误或系统异常	展示友好错误和重试入口，同时在服务端记录详细错误

上层 API 收到 incomplete 后，可以向前端返回结构化结果：

{
  status: 'incomplete',
  message: '本次任务尚未完成，已达到处理上限',
  partialResult: '已经完成的步骤和当前结论',
  canContinue: true
}

1
2
3
4
5
6

前端只展示用户能够理解和处理的信息，不应泄露异常堆栈。服务端则要保存任务状态、已执行步骤和工具结果，使下一次运行可以从安全检查点继续，而不是从头重复。对于真正的代码异常、服务不可用或数据损坏，才进入 failed 分支并执行告警、重试或故障恢复。

Mastra、LangGraph、OpenAI Agents SDK 等框架主要是在帮助实现这些通用能力。后续学习 Mastra 时，要把它的 Agent、Tool、Memory、Workflow、Eval 映射回这套模型，而不是只记 API。

# 贯穿后续学习的项目：笔记与面试助手

为了避免每个概念各写一个孤立 Demo，后续可以围绕同一个项目演进：

根据个人笔记回答技术问题，指出知识缺口，生成追问并评价回答；涉及写入学习记录或调用外部服务时，先取得授权。

第一版可以采用下面的边界：

Workflow 固定 “识别意图 → 检索笔记 → 组织回答 → 质量检查” 四个阶段；
Agent 在检索和追问阶段动态选择搜索、读取笔记、生成题目等工具；
RAG 提供知识依据，Memory 只保存用户确认过的学习进度和薄弱点；
回答必须附来源，找不到依据时明确说不知道；
修改笔记、发送消息等写操作必须二次确认；
用一组固定问题评测答案正确性、引用质量和追问覆盖度。

这个项目能自然覆盖 Tool Calling、RAG、Memory、MCP、Workflow、Eval、可观测性和前后端交付，也是面试时更容易讲清楚的完整项目。

# 什么时候应该使用 Agent

比较适合 Agent 的任务通常同时满足：

达成目标需要多步操作；
下一步依赖上一步的真实结果；
路径或步骤数量难以提前完全写死；
有工具可以提供环境反馈；
成功标准可检查，风险也能被权限和人工审核约束。

以下情况优先使用普通代码、单次 LLM 或 Workflow：

规则和步骤已经明确固定；
一次生成或一次检索就能解决；
没有可验证的完成标准；
操作不可逆且无法人工审批；
对延迟和成本要求非常严格；
错误后果远高于 Agent 带来的效率收益。

# 常见失败与应对

现象	常见根因	应对方式
一直循环	目标或停止条件不清楚	设置完成标准、最大步数和重复动作检测
选错工具	工具命名和描述含糊、能力重叠	缩小工具集，写清适用条件与反例，加入选择评测
参数错误	Schema 过于宽松	使用结构化类型、枚举和业务校验，返回可操作的错误
工具失败后乱猜	错误信息丢失或没有失败策略	保留真实错误，区分可重试、需换方案和需人工介入
声称完成但实际没完成	只相信模型输出	用测试、状态查询或结果读取建立客观验收证据
成本和延迟失控	上下文过长、循环过多、模型选择不当	裁剪上下文，限制预算，简单步骤使用更小模型或代码
越权执行敏感操作	权限直接交给模型	最小权限、读写分离、危险操作二次确认并保留审计记录
被外部内容诱导	把网页或文档内容当成系统指令	标记不可信数据，隔离指令与内容，限制工具权限和输出去向

# 高频面试题与回答

回答顺序：先说结论，再解释原因，最后补一个例子或工程边界。不要逐字背诵，记住这条表达主线即可。

1. 30 秒回答：什么是 Agent参考答案

可以直接回答：

Agent 可以理解为一个 “会根据结果继续做事的大模型系统”。它先接收目标和上下文，再选择工具执行动作，然后根据工具返回的真实结果决定下一步，直到任务完成、失败或需要人工处理。它和普通聊天模型的区别是会行动，和固定 Workflow 的区别是路径不一定预先写死。为了让它可靠运行，还要由程序限制权限、步数、时间和费用，并记录整个执行过程。

2. 2 分钟回答：你会怎样设计 Agent参考答案

我一般会分五步设计：

先判断是否真的需要 Agent：固定流程优先写成 Workflow，只把开放式决策交给模型；
定义目标和边界：明确输入、成功标准、最大步数、失败和人工升级条件；
设计工具：工具职责单一，参数有 Schema，读写权限分离，结果和错误都可被模型理解；
管理状态与上下文：关键状态由宿主应用保存，按需检索知识，长期记忆只存值得复用且经用户确认的信息；
建立安全和质量闭环：敏感操作审批，记录完整轨迹，用固定任务集评测完成率、工具选择、成本和延迟。

项目例子（完成对应实战后可直接复述）：

我做了一个个人笔记与面试助手。它解决的问题是技术资料比较分散，普通搜索只能找到文章，单次 LLM 问答又无法持续追问、验证回答并记录薄弱点，所以我把它设计成了 Workflow 和 Agent 结合的系统。

外层 Workflow 固定为意图识别、检索笔记、生成回答和质量检查四个阶段，保证主流程可预测；在检索和模拟面试阶段使用 Agent，让模型根据当前问题动态选择搜索笔记、读取原文、生成追问和评价回答等工具。知识内容通过 RAG 按需进入 Context，任务进度由宿主应用保存，Memory 只记录用户确认过的薄弱知识点，避免把全部聊天历史都当成长久记忆。

在可靠性上，我给工具定义了明确的输入 Schema，并把读写权限分开；回答必须附上笔记来源，证据不足时明确返回不知道；写入学习记录前需要用户确认，同时限制最大执行步数和工具超时。最后我用固定的面试问题集评测答案正确性、引用质量和工具选择，并记录每一步调用、耗时和错误，方便定位一次失败到底来自检索、模型决策还是工具执行。

这个项目真正体现的不是我会使用某个框架，而是我能讲清楚：为什么这里需要 Agent、哪些流程不能交给模型、状态和权限由谁管理，以及我怎样证明它确实有效。

3. 项目表达模板参考答案

不要只说 “我接入了某某框架”，可以按以下顺序讲：

用户原来遇到了什么问题；
为什么普通代码、单次 LLM 或 RAG 不够；
哪些步骤固定，哪些决策交给 Agent；
Agent 有哪些工具，状态和权限怎样管理；
最容易失败的路径是什么，你如何验证和恢复；
用什么指标证明改造有效；
如果重新设计，会减少什么复杂度。

4. Agent 和 Workflow 怎么选择，为什么经常采用混合架构？参考答案

我先看执行步骤能不能提前写清楚。能写成固定步骤的，就用 Workflow，因为更稳定、更容易测试；只有下一步必须根据现场结果判断时，才用 Agent。实际项目常把两者组合起来：外层 Workflow 控制流程、权限和高风险操作，Agent 只处理检索、排障、追问这类开放环节。这样既保留灵活性，又不会把整个系统都变成不可预测的模型决策。

5. 为什么 “能调用工具” 不等于 “是 Agent”？参考答案

因为调用工具只代表模型会发出一次调用请求，并不代表它能独立完成一项任务。一个完整的 Agent 还要有目标、任务状态和停止条件，并且能读取上一步的真实结果，再决定下一步做什么。比如模型调用一次天气接口后直接结束，这只是 Tool Calling；如果它会根据天气结果继续调整行程，直到形成可用方案，才形成了 Agent 的任务闭环。

6. Agent、MCP、Skill 与 Tool Calling 分别解决哪一层问题？参考答案

可以按四层来理解：Agent 负责把任务做完，是最外层的执行主体；Tool Calling 负责让模型用结构化方式提出工具调用；MCP 负责用统一协议接入外部工具和资源；Skill 则把某类任务的做法、资料和脚本整理成可复用能力。它们可以组合使用，例如 Agent 加载一个 Skill，再通过 Tool Calling 调用 MCP Server 提供的工具，但 MCP 或 Skill 本身都不是完整的 Agent。

7. 怎样减少 Agent 幻觉？参考答案

核心思路是 不要让模型只凭记忆回答，也不要让它自己证明自己正确。关键事实要来自检索、数据库或工具结果，完成状态要用测试或业务查询验证；证据不足时允许回答不知道或转人工。输入输出还要做 Schema 和业务校验，并用固定任务集长期评测。Prompt 可以提醒模型谨慎，但不能单独解决幻觉。

8. 怎样防止 Agent 无限循环？参考答案

我会同时做三层限制：先定义什么算完成，再限制最大步数、时间和费用，最后检测相同工具或相同错误是否反复出现。错误也不能一律重试，要区分为可以重试、应该换方案和必须转人工。达到上限时要保留当前进度并返回 incomplete，不能为了结束循环假装任务已经完成。

9. Memory 是不是保存全部聊天记录？它与 RAG、Context 怎样协作？参考答案

不是。Context 是模型这一轮实际看到的信息；RAG 负责从外部知识库查资料；Memory 只保存以后仍有价值的信息，例如用户稳定偏好或已确认的学习薄弱点。RAG 查到的资料和 Memory 取出的记忆，都必须放进当前 Context，模型才能使用。完整聊天记录可以留作历史，但不应该不加筛选地全部变成长久记忆。

10. Agent 循环中的 observation 为什么重要？参考答案

Observation 就是 Agent 执行动作后拿到的真实反馈，例如 API 返回值、测试结果或数据库状态。它告诉 Agent 刚才到底有没有成功，以及下一步该继续、改方案还是停止。没有这一步，模型很容易把 “我准备做” 误当成 “我已经做完”，也容易反复调用同一个工具。

11. 哪些状态应该由宿主应用保存，而不是只放在消息历史里？参考答案

凡是任务恢复和业务判断真正依赖的信息，都应该由宿主应用结构化保存，包括目标、完成条件、当前步骤、工具结果、重试次数、预算、审批状态和生成产物。聊天历史只是给模型理解对话用的，可能被裁剪或摘要，不能作为唯一状态源。否则页面刷新、进程重启或上下文压缩后，任务就可能丢失或判断错误。

12. 你会如何验证 Agent 真的完成了任务？参考答案

我不会因为模型说 “完成了” 就直接结束，而会在开始前先定义可验证的验收条件。比如代码任务要检查实际 diff 并运行测试，数据任务要查询最终状态，内容任务要检查引用和格式。只有外部证据通过后才标记 completed；否则就继续处理，或明确返回 incomplete、requires_action、failed。

13. 如果 Agent 可以发邮件或转账，需要增加哪些控制？参考答案

这类高风险操作不能由模型直接决定并执行。服务端要采用最小权限，分开读写工具，对收件人、金额等参数做 Schema 和业务校验；执行前展示预览并要求用户确认。还要用幂等键防止重复发送或重复扣款，设置金额和频率上限，保留审计日志，并尽量提供撤销、补偿或人工审批机制。

14. 怎样评估一次 Agent 改造是否值得增加的成本和复杂度？参考答案

我会先问：不用 Agent 能不能解决？先用普通代码、单次 LLM 或 Workflow 做一个基线，再拿同一组真实任务比较完成率、质量、人工介入、延迟、费用和故障率。只有 Agent 带来的自动化或质量提升明显大于额外的成本、安全风险和维护复杂度，改造才值得。如果流程本来就固定，加入 Agent 往往只是增加不确定性。

15. 用自己的项目讲一遍 Agent 的决策、行动、观察和停止闭环。参考答案

以笔记与面试助手为例：它先判断用户是要直接问知识、搜索笔记，还是开始模拟面试，这是决策；接着调用搜索、读取原文或生成追问工具，这是行动；工具返回的文档、匹配结果和用户回答就是观察。它再根据这些反馈决定要不要继续查资料或调整问题。答案有来源并通过检查后才停止；证据不足就明确说明，需要用户确认就返回 requires_action，超过上限则保留进度并返回 incomplete。

# 接下来学什么

下一篇学习 Prompt 与 Instructions，重点理解怎样把模型的职责、决策边界、工具策略和完成标准组织成可执行、可评测的契约。

# 参考资料

YOLO 视觉模型训练 Prompt 与 Instructions

首页

Choose mode