终端智能体搭建教程:AI编程工具选型与配置实战

一、教程目标

面向2026年的AI编程工具选型,市场已不再只有“代码补全”一种形态。围绕开发全流程,业界大致形成六类形态:终端智能体、编辑器内置助手、网页端智能体、代码平台内置助手、流水线内置智能体、自建智能体平台。其中终端形态智能体(命令行智能体)是最适合在真实代码仓库中自主执行任务的一类。

本教程要帮助你完成四件事:

1. 选型:理解六类形态的能力边界与共性能力,建立可复用的评估清单;
2. 搭建:在一台开发机上,从零完成一款终端形态智能体的安装、认证、配置与扩展;
3. 使用:通过计划模式、子代理、多智能体并行、技能与钩子机制,把它变成可稳定复用的工程流程;
4. 治理:能够验证效果、定位故障,并从成本、安全与可维护性角度持续优化。

二、适用读者与使用场景

适用读者:

• 开发者:希望让智能体在终端中读取代码、修改文件、运行测试并提交变更;
• 运维与平台工程师:需要在开发环境统一部署终端智能体,并管控权限与密钥;
• 技术负责人与企业用户:需要为团队建立选型标准,评估落地收益、安全与合规风险;
• 初学者:可从第二章的概念和第五章的步骤逐步上手,再按需查阅其余章节。

适用场景:

• 代码理解与定位:梳理陌生项目的架构,定位缺陷成因,解释历史代码;
• 功能开发与重构:按需求文档实现功能,批量重命名或迁移过时写法;
• 测试与缺陷修复:补充单元测试,分析失败的测试用例并修复;
• 工程自动化:生成配置、脚本与文档,排查构建错误,批量清理代码规范问题。

终端形态智能体由开发者自主触发、直接面对完整仓库与终端环境,因此特别适合复杂、多文件、需要反复验证的工程任务。

三、原理基础:终端智能体的工作方式

3.1 基本循环:感知—规划—执行—验证

理解其工作机制,才能安全、高效地配置它。主流终端智能体都遵循同一基本循环:

1. 感知:读取项目文件、终端输出、报错信息,以及截图、设计稿等多模态材料;
2. 规划:将目标拆解为若干步骤,形成计划;
3. 执行:按权限策略调用工具,如读写文件、执行命令、检索代码、联网查询;
4. 验证:运行测试或编译,检查执行结果,发现问题后修正并重试。

这一循环与开发者手写代码的流程高度相似,差异在于循环速度更快、单轮改动范围更大。因此,计划是否合理、权限是否可控、验证是否充分,决定了智能体的输出质量。

3.2 上下文机制

大语言模型的单次输入长度有限,而真实代码仓库往往有数十万甚至上百万行代码。终端智能体通常采用以下方式组织上下文:

• 仓库索引:通过代码检索定位相关文件,只把与任务有关的代码片段提供给模型;
• 规则文件:从项目根目录或配置目录加载项目级规则,如编码规范、目录约定、禁止改动的文件;
• 子目录记忆:在子目录放置说明文件,让智能体进入该目录时自动获取局部约定;
• 会话历史:保留当前任务中已经执行过的步骤与结果,避免重复劳动。

配置得当,智能体在动手前就能掌握项目约定;配置不当,则容易产生“不了解项目风格”的改动。

3.3 扩展机制:四层扩展体系

终端智能体通常通过“四层扩展”增强能力,各层定位如下:

层级	作用定位	典型用途
技能层	按需加载的知识与操作手册,为智能体提供领域知识和标准操作流程	API设计规范、部署手册、缺陷排查手册
钩子层	在工具调用前后自动执行校验动作	代码格式检查、危险命令拦截、测试前自动构建
协议接入层	通过标准化的模型上下文协议,连接外部工具与数据源	数据库查询、内部文档检索、研发平台数据查询
插件层	对前三者进行打包分发与版本管理	团队内部统一分发同一套规范与工具

四层扩展由内到外、逐层封装:技能是“知识”,钩子是“规则执行点”,协议接入是“能力入口”,插件是“分发单元”。先把单点能力配置正确,再通过插件打包分发,是团队协作的常见做法。

四、AI编程工具六大形态与选型评估

4.1 六大形态概览

形态	主要载体	核心能力特点	适用场景	主要局限
终端智能体	命令行工具	自主规划、多步执行、多文件改动,可扩展子代理	复杂重构、缺陷修复、工程自动化	需要权限管控与人工审查
编辑器内置助手	编辑器插件	实时补全、选中代码对话、即时修改	日常编码、局部函数改写	仓库级多步任务能力有限
网页端智能体	浏览器页面	代码库导入分析、对话式问答,多端一致	代码理解、跨端快速查阅	难以直接执行本地命令与测试
代码平台内置助手	代码托管平台功能	评审建议、提交摘要、变更说明	代码评审、变更管理	与本地执行环境隔离
流水线内置智能体	持续集成流水线	自动构建修复、测试失败定位	持续集成稳定性治理	需在流水线内限定权限
自建智能体平台	开放接口与软件开发工具包	模型、工具、流程均可定制	企业私有化、数据不出域	建设与运维成本较高

需要说明两点:

• 终端智能体通常同时具备命令行、编辑器插件、网页端等多种入口。这里的“形态”指的是开发者与智能体交互的主要方式,而非互斥的产品类别。
• 实际选型往往是组合使用:用终端智能体完成重构,用编辑器助手补全细节,用流水线智能体维护构建健康。

4.2 选型评估维度

以终端形态为例,可从八个维度评估:

• 推理能力:面对多文件、长链路任务时,能否正确理解需求,推理过程是否可追溯;
• 执行闭环:能否自主读取代码、修改文件、运行命令,并依据执行结果自我修正;
• 工作流机制:是否支持“先计划、后执行”,计划能否人工确认;
• 并行能力:能否派生子代理或将任务分配给多个智能体并行处理,并在完成后汇总结果;
• 上下文管理:上下文窗口大小、自动压缩能力,以及对大型仓库的检索效率;
• 扩展性:是否支持技能、钩子、标准化协议接入与插件分发;
• 入口与模型:是否同时提供命令行、编辑器插件、网页端入口,是否支持多种主流大模型并按任务切换;
• 安全与成本:权限策略是否细粒度,工具调用是否可审计,计费方式是否透明。

五、前置准备

5.1 基础环境

• 操作系统与终端:Linux、macOS、Windows 均可,建议使用支持多标签、分屏与多会话的现代终端。同时开启多个终端会话,便于并行执行测试、查看日志和运行智能体;
• 命令行基础:熟悉文件路径、目录切换、管道与重定向、环境变量、进程管理等基础操作;
• 版本控制与脚本能力:能够使用版本控制客户端执行克隆、查看差异、创建分支、提交与回滚。这是保障改动可回退的前提;
• 运行时环境:依据项目技术栈准备对应运行时。若涉及依赖安装与本地开发服务,还需要相应的包管理工具与容器运行环境。

5.2 账号、权限与凭据

• 服务账号:在对应产品中注册账号,并确认具备调用额度;
• 模型访问凭据:通过服务创建机构建,准备好访问密钥,并确定计费模式(订阅制或按用量计费);
• 权限边界:只授予智能体完成任务所必需的最小权限,并明确哪些目录、哪些操作属于禁止范围;
• 网络条件:若通过云服务创建机构建,确认命令行所在网络能够访问对应服务地址;若位于企业内网,提前向网络与运维团队报备出口策略。

5.3 代码仓库准备

• 使用测试分支或独立工作副本,不要在未经保护的主干分支上直接让智能体修改;
• 清理与任务无关的未提交改动,避免改动内容混杂、难以审查;
• 确认仓库中已有可运行的测试或构建命令,为智能体提供客观的验证手段;
• 准备一份简要的项目说明(目录结构、关键模块、运行与测试方式),便于后续转化为项目规则文件。

5.4 安全注意事项

• 凭据隔离:使用环境变量或系统密钥管理服务保存密钥,不要写入代码仓库或项目配置;
• 仓库扫描:接入前确认仓库内不存在误提交的私钥、令牌等敏感信息;
• 风险告知:接入团队仓库前,向仓库管理者说明智能体的权限范围与审计方式;
• 数据合规:如项目涉及敏感业务数据,先确认服务方的数据处理条款以及所在组织的合规要求。

六、实施步骤:从安装到多智能体协作

步骤一:安装并验证命令行智能体

做什么:按照所选终端智能体在其官方文档中给出的方式安装命令行程序,可选用独立安装脚本或包管理器方式。

为什么做:命令行形态是本教程所有能力的基础。插件与网页端通常依赖同一套配置与扩展体系,先跑通命令行,后续配置可复用。

注意什么:

• 只从官方文档提供的来源获取安装包,并校验版本号与安装完整性;
• 团队统一安装时,锁定同一版本并记录安装方式,避免成员之间因版本差异导致行为不一致;
• 安装完成后,在终端输入版本查询命令,确认返回的版本号与官方发布一致,并确认命令可正常调用(例如帮助命令能输出用法说明)。

若失败:检查路径变量是否包含安装目录,确认命令名称拼写正确,以及是否存在多个同名版本。

步骤二:完成身份认证与凭据配置

做什么:首次运行时,智能体一般会引导完成登录或凭据配置,有两种常见方式:

• 浏览器授权:在终端确认登录指令后,系统打开授权页面,授权完成后回写凭据到本地配置目录;
• 环境变量注入:将访问密钥配置到终端的环境变量中,或在项目级的本地环境文件中声明(该文件必须加入忽略列表,禁止提交)。

为什么做:终端智能体每次工具调用都会消耗模型额度。正确配置认证既能保证调用稳定,也便于用量统计与成本归因。

注意什么:

• 认证凭据保存在用户级配置目录,不要与项目文件混放;
• 团队环境下建议集中管理密钥,并为每个人分配独立凭据,便于审计;
• 如果使用企业自建网关或代理服务,提前设置对应的代理环境变量,避免直连失败。

步骤三:初始化项目级规则与记忆

做什么:在项目根目录创建规则说明文件(纯文本或 Markdown 格式),内容包括:

• 项目简介与技术栈;
• 目录结构与关键模块职责;
• 代码风格约定(命名、注释、目录放置、禁止引入的依赖);
• 构建、测试、代码检查命令;
• 需要特别保护、禁止修改的文件或目录。

可在子目录再放置局部规则文件,用于说明该目录的特殊约定。

为什么做:规则文件是智能体的“项目说明书”,它能显著减少不符合项目风格的改动,并降低重复提问带来的额度消耗。

注意什么:

• 规则要具体、可执行,例如“提交前必须运行单元测试并通过”,而不是笼统的“注意代码质量”;
• 规则文件应纳入版本管理,随项目演进而更新;
• 不要把密钥、内网地址等敏感信息写入规则文件。

示意性规则文件片段:

# 项目说明
- 技术栈:后端服务 + Web 前端,采用分层架构
- 目录:api(接口层)、service(业务层)、repository(数据层)、web(前端)
# 编码约定
- 新增接口必须同时补充单元测试
- 禁止在控制器层直接访问数据库
- 禁止使用已在依赖清单中标记为弃用的组件
# 验证命令(由项目统一封装,实际以项目脚本为准)
- 单元测试:执行项目脚本中的 test 命令
- 静态检查:执行项目脚本中的 lint 命令
- 构建打包:执行项目脚本中的 build 命令

步骤四:配置权限策略,建立安全边界

做什么:在用户级或项目级配置中定义权限规则,明确哪些操作自动允许、哪些需要人工确认、哪些一律禁止。常见规则维度:

• 读取:通常默认允许读取项目内文件,对项目外敏感目录设为禁止;
• 写入:限定可修改的目录范围,禁止修改构建产物与锁文件;
• 执行:区分安全的构建测试命令与高危命令(强制推送、删除分支、改写历史、系统级安装等),后者必须人工确认或直接禁止;
• 网络:限定可访问的域名或外部服务范围。

为什么做:终端智能体具有真实的文件系统与命令执行能力,权限策略是防止误操作的第一道防线。

注意什么:

• 遵循最小权限原则,任务完成后可收紧或撤销授权;
• 权限配置文件应纳入版本管理,并由技术负责人审核;
• 生产环境及承载敏感数据的主机上,默认禁止智能体具备自动执行权限。

步骤五:接入四层扩展,增强领域能力

按以下顺序逐层接入:

1. 技能层:在项目的技能目录中按统一格式编写技能说明文件(名称、适用场景、操作步骤、注意事项)。例如编写“新增接口开发流程”技能,规定接口定义、参数校验、单元测试与接口文档的完成顺序;
2. 钩子层:配置工具调用前后的自动动作,例如编辑文件后自动格式化、执行命令前校验命令是否在白名单内、提交前自动运行静态检查;
3. 协议接入层:通过标准化的模型上下文协议接入外部数据源,如内部文档库、任务管理系统、数据库只读查询工具等,让智能体能获取仓库之外的信息;
4. 插件层:将技能、钩子、协议配置打包为插件,在团队内统一下发与升级。

为什么做:通用模型不了解企业内部规范。四层扩展把“团队知识”转化为智能体可执行的规则与工具,这是从“个人玩具”走向“工程基础设施”的关键一步。

注意什么:

• 技能文件数量不宜过多,应按主题拆分,按需加载;
• 钩子中的脚本必须经过审查,禁止在其中执行下载执行、写入凭据等高风险操作;
• 协议接入的外部工具应遵循只读优先原则,并设置超时与重试上限。

示意性配置结构(仅示意层级关系,字段名称以实际产品配置格式为准):

项目根目录/
├── 项目规则说明文件            # 步骤三创建,供智能体自动加载
├── config/
│   ├── permissions             # 权限策略:allow / ask / deny
│   ├── hooks                   # 钩子:编辑后格式化、执行前校验、提交前检查
│   └── tools                   # 外部工具接入:名称、启动方式、参数、超时
└── skills/
    ├── feature-development     # 技能:功能开发标准流程
    ├── code-review             # 技能:代码评审要点
    └── release-checklist       # 技能:发布检查清单

步骤六:使用计划模式,先规划后执行

做什么:对于涉及多个文件或业务流程的任务,先启用计划模式,让智能体输出实施计划,再决定是否进入执行。

计划通常包含:需求理解、影响范围分析(涉及哪些文件与模块)、实施步骤、验证方案、风险点。

为什么做:计划阶段不修改任何文件,成本极低,却能提前暴露理解偏差,避免“改了一大片、方向全错”的高额返工。

注意什么:

• 计划要逐条确认:步骤不合理时直接提出修改意见,要求智能体重新规划;
• 对于边界模糊的需求,要求智能体先列出假设与待确认问题,再由人回答;
• 计划确认后,可要求智能体在执行前再次列出“本次将修改的文件清单”,作为执行的最后一道检查。

步骤七:使用子代理,拆分并隔离子任务

做什么:将复杂任务拆分为可由子代理独立完成的子任务,例如:

• 调研类:梳理某个模块的调用链与依赖关系;
• 检索类:在大型仓库中定位所有相关实现位置;
• 验证类:运行测试套件并分析失败原因。

主智能体负责拆解、派发与汇总,子代理在独立上下文中完成子任务后,只向主智能体返回结论。

为什么做:

• 上下文隔离:大量中间搜索结果不会占用主任务的上下文;
• 职责专注:每个子代理只关注单一目标,输出更稳定;
• 并行加速:多个互不依赖的子任务可同时推进。

注意什么:

• 子任务之间要避免文件写入冲突,写入型任务尽量串行执行;
• 子代理继承的权限不应超出主任务范围,尤其是执行与网络权限;
• 子代理返回结果需附带关键证据(文件路径、行号、命令输出),便于主智能体验证。

步骤八:多智能体并行与团队协作

做什么:在任务相互独立且可并行验证时,启用多智能体并行模式,将任务分配给多个智能体实例同时执行。例如:一个负责后端接口改造,一个负责前端页面适配,一个负责补充测试用例。

为什么做:缩短整体交付时间,并在同一基线上并行比较不同方案的实现质量。

注意什么:

• 并行前确保所有实例基于同一代码基线(同一次提交);
• 每个实例使用独立分支或工作副本,避免直接写入同一工作目录;
• 并行结果合并前必须统一运行一次完整测试,防止集成问题;
• 并行会成倍增加额度消耗,建议仅在任务规模足够大时启用。

步骤九:多入口协同与多模态输入

做什么:根据场景切换入口:

• 命令行:执行多步、自动化、可脚本化的任务;
• 编辑器插件:在编写代码过程中即时提问、选中代码改写;
• 网页端:分享会话记录、进行代码库级的分析讨论。

同时,对界面设计稿、报错截图、日志截图等材料,以图片形式提供给智能体进行分析。

为什么做:多入口共享同一套规则与扩展配置,可以在不同工作场景中保持一致的上下文与规范,避免重复配置。

注意什么:

• 多端使用时确认会话记录与凭据的同步范围,避免敏感对话外泄;
• 截图可能包含用户信息或内网地址,提供前应做脱敏处理。

七、配置说明:关键配置项的作用与风险

配置项	作用	常见取值逻辑	配置风险
默认模型	决定推理能力与单次调用成本	复杂推理任务用能力更强的模型,简单编辑用轻量模型	一律使用最强模型会显著增加成本
上下文窗口	单次可处理的文本长度	大型仓库任务选较大窗口,并配合子代理隔离上下文	窗口过小导致频繁截断、遗漏关键信息
上下文压缩	长任务中自动摘要历史内容	长会话默认开启,关键结论要求单独记录	压缩过度可能丢失早期决策依据
权限策略	控制读写、执行、网络行为	读取放宽、写入限定目录、高危操作一律人工确认	过宽导致误删误改,过严导致频繁中断
扩展加载	决定技能与钩子是否生效	按需启用,按主题组织	加载过多扩展会稀释注意力,增加消耗
计划模式	执行前输出方案供确认	多文件任务默认开启	关闭后容易出现大范围错误改动
并发数量	同时运行的智能体或子代理数量	依据额度、机器资源与任务独立性设定	过高引发资源争抢与写入冲突
超时与重试	命令执行与外部调用的容错	构建类命令设置较长超时,查询类设置较短超时	无限重试会放大成本与故障影响

八、完整任务示例:修复缺陷并补充测试

以一个通用缺陷修复任务为例,完整流程如下:

1. 描述问题与期望:向智能体说明缺陷现象、复现条件与期望结果,并附上报错截图或日志片段;
2. 只读排查:要求智能体在计划模式下先阅读相关代码、搜索调用点,输出根因假设与验证方式,此阶段不修改任何文件;
3. 确认计划:人工核对根因分析与改动范围,确认补充或调整测试用例的方案;
4. 授权执行:进入执行阶段,由子代理运行现有测试套件,复现失败用例并定位到具体断言;
5. 实施修复:智能体修改代码并补充测试用例,钩子自动执行格式化与静态检查;
6. 结果汇总:智能体输出变更文件清单、测试结果摘要与剩余风险;
7. 人工审查:开发者逐文件审查差异,在分支上再次运行完整测试与构建;
8. 提交合并:审查通过后提交变更并合并,若出现问题则基于版本控制快速回滚。

# 流程示意(非具体产品命令)
任务输入:缺陷现象 + 复现条件 + 期望结果
  ↓ 计划模式:输出根因假设、改动范围、验证方案
人工确认计划
  ↓ 派发子代理:运行测试套件 → 复现失败 → 定位断言
  ↓ 修改代码 + 补充测试用例(钩子自动格式化与静态检查)
  ↓ 运行完整测试与构建
输出:变更清单 + 测试结果 + 剩余风险
  ↓ 人工审查差异 → 提交 → 合并

九、结果验证:如何判断配置成功

按由浅入深的顺序验证:

1. 认证验证:发起一次最小请求(例如询问当前目录下的文件数量),能正常返回即说明认证与网络通路正常;
2. 上下文验证:询问项目的目录结构与测试命令,若回答与实际一致,说明项目规则与仓库索引已正确加载;
3. 权限验证:分别尝试读取项目内文件、修改项目内文件、执行禁止项(如强制推送),预期结果应为前两项成功、第三项被拒绝;
4. 扩展验证:触发一次技能调用,观察是否按技能定义的步骤执行;修改一个文件,检查钩子是否自动运行格式化;
5. 外部工具验证:请求一次外部数据源查询,确认能返回预期结果且耗时在合理范围内;
6. 端到端验证:用步骤八的缺陷修复流程完成一次完整任务,确认变更可审查、测试全部通过、构建成功。

建议在团队内建立一份接入检查清单,把上述六项作为新成员接入终端智能体的验收标准。

十、常见问题与排查

现象	可能原因	排查思路
认证失败或额度提示	凭据过期、额度耗尽、计费方式不匹配	重新完成授权,查看服务端账户用量与计费说明
命令被拒绝执行	权限策略限制或钩子拦截	查看拒绝原因日志,按需调整权限或修正命令
改动方向偏离需求	计划未确认、规则文件缺失或冲突	先确认计划再执行;检查规则文件是否明确、是否存在互相矛盾的条目
大型仓库任务效果下降	上下文被大量无关内容占用	使用子代理隔离检索过程;缩小任务范围;启用上下文压缩
子代理结果不可靠	子任务定义模糊、缺少验证标准	明确输入、输出格式与验收条件,要求返回证据
并行任务改动冲突	多个实例写入同一目录	为每个实例分配独立分支或工作副本,串行合并
扩展未生效	文件位置或格式不符、未启用	核对目录层级与文件格式,重新加载配置并查看加载日志
调用缓慢或超时	模型排队、网络不稳定、命令本身耗时过长	切换轻量模型,设置合理超时与重试上限,拆分长任务

通用排查方法:保持“一次只改一个变量”,从最小可复现任务入手,并始终保留版本控制记录,确保任何异常改动都能快速回退。

十一、优化建议

11.1 性能

• 分层使用模型:规划与复杂推理使用能力更强的模型,格式化、重命名等机械操作使用轻量模型;
• 缩小任务粒度:把大任务拆成可在一次会话内完成的子任务,减少无效上下文;
• 善用子代理:将检索、测试分析等“读多写少”的工作交给子代理,保持主上下文精简;
• 脚本化重复流程:把高频操作固化为项目脚本或技能,减少每次重新描述的成本。

11.2 安全

• 最小权限:默认只读,写入限定目录,高危操作必须人工确认;
• 钩子前置拦截:通过钩子在执行前校验命令,例如拦截强制推送、历史改写、生产环境直连;
• 凭据隔离:使用环境变量或密钥管理服务,禁止将密钥写入仓库与规则文件;
• 脱敏处理:提交给智能体的日志、截图应移除用户信息、令牌与内网地址;
• 变更可审计:所有改动经版本控制提交,保留智能体会话记录以便追溯。

11.3 稳定性

• 为命令执行设置超时与有限重试,避免无限循环消耗额度;
• 建立“执行—测试—回滚”闭环,确保任何自动化流程都可回退;
• 定期回归验证:每月用固定的基准任务集检查智能体输出质量是否随模型或版本升级而退化。

11.4 可维护性与团队协作

• 配置即代码:权限、钩子、技能、插件全部纳入版本管理,通过合并请求评审后生效;
• 统一分发:以插件形式向团队下发规范与工具,版本统一升级,减少个体配置差异;
• 文档化:维护一份团队级使用规范,明确适用场景、禁止事项与审查要求;
• 沉淀最佳实践:把高频且效果稳定的任务模式固化为技能模板。

11.5 成本与可观测性

• 统计各成员、各项目的模型调用量与费用,识别异常消耗;
• 将智能体的运行日志、工具调用记录接入云服务提供的日志服务与监控告警等通用能力,集中检索与留存,并设置异常用量告警;
• 对高频简单任务优先使用本地工具或脚本完成,把模型能力集中在真正需要推理的环节。

十二、总结

本教程以终端形态智能体为主线,完成了从选型到落地的完整闭环:

• 选型层面:理解了六大形态的能力边界,以及推理、执行闭环、计划模式、子代理、上下文管理、四层扩展、多入口、安全成本这八个评估维度;
• 实施层面:按安装认证、规则初始化、权限策略、四层扩展、计划模式、子代理、多智能体并行、多入口协同的顺序逐步搭建;
• 治理层面:给出了六步验证方法、常见问题排查表,以及性能、安全、稳定性、可维护性和成本五方面的优化建议。

核心思路可以概括为一句话:让智能体在清晰的规则与权限边界内,先规划、再执行、必验证、可回滚。

后续可继续关注三个方向:

1. 子代理与多智能体的编排策略,研究如何在更多并行场景下避免冲突;
2. 团队级扩展体系的建设,把内部规范沉淀为可版本管理的技能与插件;
3. 终端智能体与持续集成流水线的联动,把代码评审、构建修复等环节纳入自动化治理。

对于企业用户,如需使用云上模型服务,可结合百度智能云的大模型服务平台千帆及其兼容主流开放接口的服务方式统一接入与计费;需要集中留存运行日志时,可结合百度智能云日志服务百度日志服务(BLS)等产品能力。实际产品能力与计费规则,请以百度智能云官方文档为准。