1. 从“思考”到“行动”：AI智能体中的Skills究竟是什么？

在机器人、AI智能体这些领域里混久了，你会发现一个核心问题：一个聪明的“大脑”如果只有想法，却动不了手，那它基本就是个摆设。这就像你设计了一个能规划最优路径的自动驾驶算法，但它没法控制方向盘、油门和刹车，那这个算法再精妙也毫无意义。 Skills（技能） ，就是解决这个“最后一公里”问题的关键。它不是什么高深莫测的概念，你可以把它理解为AI智能体的“肌肉记忆”和“工具箱”。当智能体通过大语言模型（LLM）进行思考、规划，决定要做什么之后，Skills就是它具体执行动作的那一套标准化指令集。

简单来说， Skills是连接AI智能体“认知世界”与“物理世界”或“数字世界”的桥梁 。没有Skills，智能体就是一个空谈的战略家；有了Skills，它才真正成为一个能落地、能解决问题的实干家。无论是让一个机器人手臂抓取物体，还是让一个软件智能体自动处理Excel表格、发送邮件，背后都是一个个具体的Skill在起作用。对于嵌入式、物联网、工业控制这些软硬件结合的领域来说，理解Skills尤为重要，因为这直接关系到如何将一个智能的决策核心，与真实的传感器、执行器、通信模块对接起来，让想法变成现实。

2. Skills的本质：结构化、可调用的能力单元

2.1 核心定义与类比

抛开那些花哨的术语，我们可以从几个角度来理解Skills的本质：

首先，Skills是标准化的接口。 在软件工程里，我们讲究高内聚、低耦合。一个设计良好的Skill也是如此。它应该像一个封装好的函数或API：有明确的输入（Input）、明确的处理逻辑、以及明确的输出（Output）。例如，一个 read_temperature_sensor(sensor_id) 的Skill，输入是传感器ID，内部逻辑是驱动特定总线（如I2C、SPI）去读取数据并做校准转换，输出就是一个浮点型的温度值。智能体的大脑（规划模块）不需要知道这个温度值是怎么从芯片引脚上读出来的，它只需要调用这个Skill，并相信它能返回正确的结果。

其次，Skills是领域知识的载体。 一个用于工业质检的视觉AI智能体，它的Skills可能包括 capture_image() 、 preprocess_image() 、 inspect_defect() 。这些Skill里封装了如何控制工业相机触发、如何做图像降噪和增强、如何运行特定的缺陷检测模型等一系列专业知识。智能体规划时，只需组合这些Skills，而无需从头学习计算机视觉的每一个细节。

再者，Skills是安全与可控的边界。 这是在实际部署中至关重要的一点。你不会允许一个智能体随意调用格式化工控机硬盘的Skill，或者让机器人以最大功率挥动手臂。因此，Skills的设计往往包含了权限控制、参数校验和安全边界。例如，一个 move_robot_arm(position, speed) 的Skill，内部一定会对 speed 参数进行限幅，确保它不会超过机械结构的安全阈值。

注意：在设计Skill时，一定要把“安全第一”作为铁律。特别是在控制硬件、涉及系统关键操作的Skill中，必须加入充分的错误处理、超时保护和状态回滚机制。一个失控的Skill可能导致物理损坏或安全事故。

2.2 Skills的典型形态与实现

在技术实现上，Skills通常表现为以下几种形态，我们可以结合嵌入式/物联网的场景来理解：

  1. 本地函数/方法 ：这是最简单直接的形式。在智能体运行的主机或微控制器（MCU）上，直接以代码函数的形式实现。例如，在基于Python的智能体框架中，一个Skill可能就是一个用 @tool 装饰器标记的Python函数。在资源紧张的嵌入式C环境中，它可能就是一个精心编写的、接口清晰的C函数。

    # 一个简单的Python Skill示例：读取GPIO状态
def read_gpio_status(pin_number: int) -> str:
    """
    读取指定GPIO引脚的电平状态。
    参数:
        pin_number: GPIO引脚编号。
    返回:
        'HIGH' 或 'LOW'。
    """
    # 这里隐藏了具体的硬件操作细节，可能是调用WiringPi、RPi.GPIO或自家SDK
    value = hardware_gpio_read(pin_number)
    return 'HIGH' if value == 1 else 'LOW'

  2. 远程API调用封装 ：当Skill依赖的功能不在本地，而在网络另一端时。例如，智能体需要查询天气，它调用的 get_weather(location) Skill，内部实现其实是向气象服务商的RESTful API发起一个HTTP请求，并解析返回的JSON数据。在物联网场景中，一个 control_smart_light(device_id, brightness) 的Skill，可能就是封装了向家庭物联网云平台或本地MQTT broker发送控制协议的过程。

  3. 命令行工具封装 ：许多现有能力是通过命令行工具提供的。一个Skill可以封装对这类工具的调用。比如， git_commit() Skill可能内部就是执行 git add . && git commit -m “...” 命令。在嵌入式开发中， build_firmware() Skill可能封装了调用 make 或 cmake 的流程。

  4. 与其他智能体/服务的交互接口 ：在更复杂的多智能体系统中，一个智能体的Skill可能是向另一个 specialized 的智能体发起请求。例如，一个“总控”智能体拥有 delegate_coding_task(requirement) Skill，这个Skill的实现是将需求发送给一个专门的“编码专家”智能体，并等待其返回结果。

实操心得： 在定义Skill的输入输出时，强烈建议使用强类型（如Python的Type Hints）或结构化的数据格式（如JSON Schema）。这不仅能减少调用时的错误，还能让智能体的规划模块更准确地理解这个Skill能处理什么、会返回什么。例如，与其让Skill返回一段自由文本“温度是25.3度”，不如让它返回一个结构体 {“value”: 25.3, “unit”: “celsius”, “timestamp”: “2023-10-27T10:00:00Z”} 。后者对于后续的Skill（比如 decide_ac_action() ）来说，更容易被理解和处理。

3. Skills与Tools、Plugins的辨析：为何要区分？

在日常交流中，Skill（技能）、Tool（工具）、Plugin（插件）甚至Action（动作）这些词经常被混用。但在架构设计时，厘清它们的细微差别有助于构建更清晰的系统。

Skill（技能） ：这个词更侧重于智能体 自身所具备的能力 。它是一种“内化的本领”。就像一个人学会了“骑自行车”，这个技能是属于他自身的。在智能体语境下，Skill是智能体代码库或知识体系的一部分，是它可以直接调用和执行的内在能力。它的生命周期和智能体绑定。

Tool（工具） ：这个词更侧重于 外部提供的、用于完成特定任务的器具 。工具是外在于使用者的。比如，螺丝刀是一个工具。在AI中，一个外部提供的、需要通过特定API（如OpenAI的Function Calling）去调用的服务，常被称为Tool。Tool可能由第三方提供，智能体只是“使用”它，而不“拥有”它。

Plugin（插件） ：这个词强调 可插拔的扩展模块 。插件通常遵循一定的标准接口，可以在主体程序运行时被动态加载或卸载，以扩展其功能。一个Skill可以通过插件机制来实现，但并非所有Skill都是插件。插件更强调模块化和动态性。

Action（动作） ：这是最原子化的一个词，指 一次具体的、底层的操作 。一个Skill可能由一系列有序的Actions组成。例如， pick_up_object() 这个Skill，可能分解为 move_arm_to_position() , close_gripper() , lift_arm() 等多个Actions。

在实际的AI智能体框架（如LangChain、AutoGPT、CrewAI等）中，这些概念常常被等价处理，都映射为可供LLM调用的“工具”。但从设计哲学上看， 当你把某个功能看作智能体核心能力的延伸时，用“Skill”更贴切；当你把它看作外部可利用的资源时，用“Tool”更合适 。对于一个旨在解决特定领域问题（如自动化测试、设备监控）的智能体，我们更倾向于将它的核心能力设计为Skills，因为它们是与智能体目标紧密耦合的“看家本领”。

4. Skills在智能体工作流中的核心作用：规划与执行的枢纽

理解了Skills是什么，我们再来看看它在智能体完整的工作流中扮演什么角色。一个典型的基于LLM的智能体工作流可以简化为“感知-规划-执行”循环，而Skills是“执行”环节的唯一出口。

4.1 工作流拆解

  1. 任务接收与解析 ：用户用自然语言提出请求，如“检查一下3号生产线传感器数据，如果温度连续5分钟超过阈值，就发告警邮件给值班工程师。”
  2. 规划生成 ：智能体的“大脑”（LLM）结合自身的Skills清单（一个所有可用Skill的名称、描述、参数格式的列表）进行思考。它会将复杂任务分解为一系列可执行的步骤。这个过程可能借助Chain-of-Thought（思维链）或更复杂的规划算法。
    • 大脑思考 ：“要完成这个任务，我需要：1. 获取3号生产线的传感器数据（需要一个数据查询Skill）。2. 分析数据，判断是否有连续超温（需要一个数据分析Skill，或者用代码解释器Skill写段小程序）。3. 如果满足条件，需要发送邮件（需要一个邮件发送Skill）。”
  3. Skill调度与执行 ：规划器（可能是LLM本身，也可能是一个专门的模块）按照规划好的步骤，依次调用对应的Skill，并传入具体参数。
    • 调用 ： sensor_data = fetch_production_line_data(line_id=3, duration_minutes=10)
    • 调用 ： over_temp_flag = analyze_temperature_trend(sensor_data, threshold=85.0, window_minutes=5)
    • 判断与调用 ：如果 over_temp_flag 为真，则调用 send_email(to=“engineer@company.com”, subject=“高温告警”, body=“3号生产线温度异常...”)
  4. 结果观察与循环 ：每个Skill执行后返回结果。智能体观察这些结果，决定是继续执行下一个步骤，还是因为遇到错误需要重新规划。这就构成了一个闭环。

4.2 关键设计考量：如何让智能体更好地使用Skills？

要让这个流程顺畅，Skills本身的设计和提供给LLM的“技能清单”至关重要。

首先，Skill的描述必须清晰、无歧义。 LLM是根据自然语言描述来决定使用哪个Skill的。一个糟糕的描述会导致误调用。对比以下两种描述：

  • 差描述： 处理数据 。这太模糊了，LLM不知道它能处理什么数据，怎么处理。
  • 好描述： 计算一组温度读数的移动平均值。输入：一个浮点数列表 data_list ，一个整数窗口大小 window 。输出：移动平均后的新列表。 这样的描述明确了功能、输入和输出格式。

其次，需要管理Skill的复杂性与粒度。 是把一个“巡检整个工厂”做成一个巨无霸Skill，还是拆分成“读取A区传感器”、“读取B区传感器”、“生成报告”等多个小Skill？通常， 单一职责原则 在这里同样适用。一个Skill最好只做一件事，并把它做好。细粒度的Skill更灵活，更容易被组合复用，也更容易调试和维护。但粒度过细会增加LLM规划的复杂度。需要在灵活性与易用性之间取得平衡。

实操心得： 在实际项目中，我通常会建立两个层级的Skills。一层是 原子Skill ，如 read_sensor() , write_database() , http_post() 。另一层是 组合Skill 或 流程Skill ，它内部按固定逻辑调用多个原子Skill，但对LLM呈现为一个更高级别的能力，如 daily_inspection_report() 。这样，既保持了底层操作的灵活性，又为常见复杂任务提供了开箱即用的高级接口，降低了LLM规划的负担。

5. 实战：为嵌入式设备监控智能体设计Skills

让我们以一个具体的场景来贯穿上述理论：设计一个用于监控嵌入式设备集群状态的AI智能体。这个智能体需要能回答诸如“哪台设备最近错误日志最多？”、“给所有CPU温度超过70度的设备发个重启指令”等问题。

5.1 技能清单设计

我们需要为这个智能体装备以下核心Skills：

技能名称 (函数名) 描述 输入参数 返回结果 实现要点
get_device_list 获取当前管理的所有设备ID及基本信息。 filter_by_status (可选): 在线、离线、故障 设备列表，每项含 id , name , ip , status 从设备管理数据库或注册中心查询。
get_device_metrics 获取指定设备的实时性能指标。 device_id : 设备ID
metric_names : 指标名列表，如[“cpu_temp”, “mem_usage”]		 指标键值对字典，如{“cpu_temp”: 65.2, “mem_usage”: 45.8} 通过设备上的Agent或SNMP等协议实时抓取。需处理超时和网络异常。
get_device_logs 获取指定设备最近一段时间的日志。 device_id : 设备ID
log_level (可选): 错误、警告、信息
time_range_minutes : 时间范围		 结构化日志条目列表，含时间、级别、内容。 从集中式日志服务器（如ELK）查询。注意时间同步和日志量过大问题。
analyze_logs_for_errors 分析日志，统计错误频率或提取关键错误模式。 log_entries : 日志条目列表
pattern (可选): 需要关注的关键词正则		 分析报告，如{“total_errors”: 5, “most_common_error”: “Timeout”, “suggestions”: “检查网络连接”} 可以集成简单的文本分析，或调用更专业的日志分析API。
send_device_command 向指定设备发送控制命令。 device_id : 设备ID
command : 命令字符串，如“reboot”, “update_firmware”
parameters : 命令参数		 命令执行结果状态，如{“success”: true, “message”: “Reboot command sent”} 安全重地！ 必须做严格的设备ID、命令白名单校验。命令最好异步执行，立即返回“已接收”。
generate_summary_report 基于当前数据生成一份文本摘要报告。 device_ids : 设备ID列表
report_type : 日报、周报、健康检查		 一份结构化的Markdown格式报告文本。 利用LLM的文本生成能力，将其他Skill获取的数据组织成易读的报告。

5.2 一个完整任务流的Skill调用序列

假设用户提问：“ 帮我查一下设备‘gateway-01’过去一小时的错误日志，如果错误数超过10次，就让它重启。 ”

智能体的规划与执行序列可能如下：

  1. 规划分解 ：LLM理解任务后，生成计划：①获取设备ID（可能名称到ID的映射需要另一个Skill或已在上下文中）；②获取该设备过去一小时的日志；③分析日志中的错误数量；④如果数量>10，则发送重启命令。
  2. Skill调用链 ：
    • device_info = get_device_list(filter_by_status=“online”) （假设从列表中找到 gateway-01 对应ID为 dev_123 ）
    • logs = get_device_logs(device_id=“dev_123”, log_level=“error”, time_range_minutes=60)
    • analysis = analyze_logs_for_errors(log_entries=logs) （或者直接由LLM计数，这里用专门Skill更可靠）
    • if analysis[“total_errors”] > 10: send_device_command(device_id=“dev_123”, command=“reboot”)

这个例子展示了Skills如何将模糊的自然语言指令，转化为一系列精确、可执行的操作。

5.3 嵌入式场景下的特殊挑战与Skill设计应对

在嵌入式/物联网环境中设计Skills，会遇到一些通用AI应用中没有的挑战：

  • 资源受限 ：设备端可能无法运行完整的LLM和智能体框架。解决方案是采用 云端智能体+边缘轻量级Skill执行器 的模式。云端智能体负责规划，将规划好的Skill调用序列下发给设备端的执行器，执行器只负责运行那些需要本地操作的原子Skill（如读取某个GPIO），并将结果上报。Skill的实现需要跨云端和边缘协同设计。
  • 实时性与确定性 ：控制类Skill对时延有要求。 send_device_command 这类Skill的实现，不能是简单的异步消息发出就不管了。可能需要设计带超时和确认机制的命令通道，Skill内部需要轮询或等待命令执行结果，确保操作的确定性。
  • 网络不可靠 ：Skills必须具备强大的容错和重试机制。例如， get_device_metrics Skill在发现设备无响应时，不应直接抛出异常导致整个任务链崩溃，而是应返回一个带有“离线”状态的特殊结果，让上游的规划逻辑（LLM）来决定下一步是重试、标记故障还是执行备用方案。
  • 安全与权限 ：如前所述，控制类Skill是安全关键点。除了白名单校验，还应结合设备认证、操作审计等功能。一个重要的设计模式是 审批链Skill ：对于危险操作（如固件升级、配置重置）， send_device_command Skill并不直接执行，而是生成一个待审批的工单，调用另一个 create_approval_ticket() Skill。只有经过人工或其他权威智能体审批后，命令才会真正下发。

注意：在工业物联网场景中，为控制类Skill设计“模拟执行”或“干跑”模式非常有用。即Skill接受一个 dry_run=True 的参数，当设置时，Skill只打印出将要执行的操作和参数，而不实际执行。这为测试和验证智能体的规划逻辑提供了安全沙箱。

6. 构建与优化Skills体系的最佳实践

设计几个能用的Skill不难，但要构建一个健壮、可扩展、易维护的Skills体系，则需要一些工程化的思考。

6.1 技能发现与注册：让智能体知道自己能做什么

智能体如何知道它有哪些Skills可用？这就需要一套 技能发现与注册机制 。通常，在一个框架中，你会通过装饰器或配置文件声明一个Skill，框架会自动将其收集到一个“技能库”或“工具包”中。当智能体启动或规划任务时，它会从这个库中获取所有Skill的描述列表，并将其作为上下文提供给LLM。

# 示例：使用装饰器注册Skill
skill_registry = []

def register_skill(func):
    """一个简单的Skill注册装饰器"""
    skill_registry.append({
        "name": func.__name__,
        "description": func.__doc__,  # 使用函数文档字符串作为描述
        "function": func
    })
    return func

@register_skill
def ping_device(device_ip: str) -> dict:
    """检查设备网络连通性。参数：设备IP地址。返回：包含‘alive’（布尔值）和‘latency_ms’（毫秒）的字典。"""
    # ... 实现ping逻辑 ...
    return {"alive": True, "latency_ms": 10.5}

# 智能体规划时，可以将skill_registry中每个技能的name和description提供给LLM。

在更复杂的系统中，技能库可能是动态的，支持热插拔。这对于需要扩展功能的系统尤为重要。

6.2 技能组合与编排：超越单一技能

真正的威力来自于Skills的组合。智能体通过规划，可以将多个Skills像乐高积木一样组合起来，解决复杂问题。这就涉及到 技能编排 。除了依赖LLM的自主规划，有时我们也需要预设一些常用的、固定的工作流。

  • 顺序组合 ：如前文的设备检查例子，Skills按顺序执行，前一个的输出作为后一个的输入。
  • 条件分支 ：根据某个Skill的结果，决定执行哪条分支的Skills。这需要LLM或规划器具备逻辑判断能力。
  • 循环迭代 ：对一组数据（如所有设备）反复执行同一个或同一组Skill。例如，“检查所有设备的健康状态”。

我们可以创建一些 高阶Skill 或 流程模板 来封装这些固定模式。例如，创建一个 batch_check_devices(device_ids, check_skill_name) 的Skill，它内部负责循环调用指定的检查类Skill。

6.3 技能的性能、监控与维护

Skills作为智能体的执行单元，其本身的健康度和性能直接影响整个系统的可靠性。

  • 性能监控 ：记录每个Skill的执行耗时、成功/失败率。对于耗时较长的Skill（如文件处理、大数据量查询），可以考虑设计成异步模式，立即返回一个任务ID，允许智能体后续通过另一个Skill来查询结果。
  • 错误处理与重试 ：Skill内部应有完善的异常捕获机制。对于因网络抖动等临时性问题导致的失败，应设计指数退避等重试策略。错误信息应结构化地返回给调用者，以便智能体理解错误原因并决定下一步行动（例如，重试、跳过、上报人工）。
  • 版本管理 ：当Skill的实现逻辑更新时（比如调用的API版本升级），需要有版本管理，避免对现有智能体任务流造成破坏性影响。可以在Skill描述或注册信息中加入版本号。
  • 依赖管理 ：某些Skill可能依赖特定的软件包或环境。需要在Skill的描述或部署说明中清晰定义，避免运行时缺失依赖。

实操心得： 为每个Skill编写详尽的单元测试和集成测试至关重要。特别是对于控制硬件、涉及金融交易等关键操作的Skill，测试用例要覆盖正常流程、边界情况和各种异常场景。测试脚本本身也可以被做成一个 test_skill(skill_name) 的Skill，供智能体在部署前进行自检。

7. 常见问题与排查技巧实录

在实际开发和运维AI智能体及其Skills的过程中，你会遇到各种各样的问题。下面记录了一些典型问题及其解决思路。

7.1 LLM拒绝调用或错误调用Skill

  • 问题现象 ：智能体规划时，明明有合适的Skill，但LLM生成的计划里就是不调用，或者调用了错误的Skill，参数也不对。
  • 排查思路 ：
    1. 检查Skill描述 ：这是最常见的原因。描述是否清晰、无歧义？是否准确反映了Skill的功能和输入输出格式？尝试用更精准的语言重写描述，并确保关键词突出。
    2. 提供示例 ：在给LLM的Skill描述中，加入1-2个调用示例（Example）。LLM通过示例学习的效果往往比纯文字描述更好。
    3. 调整上下文 ：LLM可能因为上下文过长或无关信息干扰而“遗忘”或“混淆”某些Skill。尝试精简提供给LLM的上下文，只保留与当前任务最相关的Skills描述。
    4. 温度参数 ：如果LLM的“创造力”太强（温度参数过高），它可能会天马行空地自己编造一个不存在的步骤。对于需要严格按步骤执行的任务，尝试降低温度参数，使其输出更确定、更遵循指令。

7.2 Skill执行失败或超时

  • 问题现象 ：规划正确，但调用Skill时执行失败，返回错误或长时间无响应。
  • 排查思路 ：
    1. 查看Skill日志 ：首先检查Skill函数内部的日志，定位错误发生在哪一行代码。是参数验证失败、网络连接错误，还是权限不足？
    2. 检查依赖与环境 ：Skill运行所依赖的服务（数据库、API、硬件设备）是否正常？网络是否通畅？环境变量、配置文件是否正确加载？
    3. 超时设置 ：是否为网络请求、硬件操作设置了合理的超时时间？避免一个Skill卡死导致整个任务链停滞。在Skill实现中加入超时控制，并返回明确的超时错误。
    4. 资源竞争 ：如果多个智能体实例或任务并发调用同一个Skill（特别是涉及硬件独占操作的），是否会产生资源竞争？考虑为这类Skill增加锁机制或任务队列。

7.3 智能体陷入循环或无效动作

  • 问题现象 ：智能体反复执行同一个或一组类似的Skill，无法推进任务，或者执行一些明显无用的操作。
  • 排查思路 ：
    1. 检查Skill的反馈 ：Skill返回的结果是否清晰、结构化？如果Skill返回一个模糊或错误的结果，LLM可能无法正确理解当前状态，从而做出错误的下一个决策。确保Skill返回的结果能被LLM有效解析。
    2. 引入状态记忆 ：为智能体提供短期记忆（如对话历史）和长期记忆（如任务执行状态记录），让它能记住已经做过什么，避免重复劳动。许多智能体框架都有记忆（Memory）模块。
    3. 设定执行边界 ：为任务链设定最大步数（Max Steps）限制。当智能体执行步骤超过这个限制时，强制终止任务，并反馈“任务过于复杂或陷入循环”的错误。这可以防止无限循环消耗资源。
    4. 人工干预点 ：在关键决策点设计“询问用户”的Skill。当智能体不确定或多次尝试失败后，可以调用这个Skill来获取人工指导，打破僵局。

7.4 安全问题

  • 问题现象 ：智能体执行了未授权的危险操作，如删除了重要文件，或向设备发送了错误指令。
  • 防范措施 ：
    1. 最小权限原则 ：运行智能体的进程或账户，只拥有完成其任务所必需的最小权限。不要用root或管理员账户运行。
    2. Skill沙箱化 ：对于执行代码、访问文件系统等高风险Skill，考虑在沙箱环境（如Docker容器、虚拟机）中运行，限制其能访问的资源。
    3. 输入验证与净化 ：对所有Skill的输入参数进行严格的验证和净化，防止注入攻击。特别是对于调用命令行或拼接SQL的Skill。
    4. 操作审计 ：记录每一个Skill调用的详细信息：谁（哪个智能体/用户）、何时、调用了什么Skill、输入参数是什么、返回结果是什么。这为事后追溯和安全分析提供了依据。
    5. 危险操作二次确认 ：如前所述，对于高风险操作，设计审批链或模拟执行模式。

构建一个由Skills驱动的AI智能体，是一个将抽象智能与具体行动紧密结合的系统工程。它要求我们不仅要有AI和软件工程的知识，在嵌入式、物联网等领域，还需要对硬件、通信协议、行业知识有深入理解。Skills的设计水平，直接决定了智能体能力的上限和落地的稳健性。从一个个小而美的原子Skill开始，逐步构建起一个可靠的能力矩阵，你的智能体才能真正从“纸上谈兵”的参谋，成长为“冲锋陷阵”的干将。

# AI智能体
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

深入Spring Boot生态中最核心部分 数据库交互spring-boot-starter-data-jpa和Hibernate (指南五)

avatar 亚马逊云科技技术品牌专区
cover

搜维尔科技：TESOLLO为世界机器人配备更智能的双手

avatar 亚马逊云科技技术品牌专区
cover

多模态推理的“思维之跃”：紫东太初4.0如何重塑AI认知边界

avatar 亚马逊云科技技术品牌专区