1. 项目概述：为什么我们需要“全链路”安全治理？

最近在折腾OpenClaw，一个挺有意思的AI智能体框架，发现社区里讨论的热度很高，但大家关注点大多集中在“怎么装”、“怎么连大模型”、“怎么接飞书/微信”这些功能实现上。这当然没错，上手玩起来是第一步。但当我真正尝试把它用在一些稍微严肃点的场景，比如想让它帮我自动处理电商客服工单，或者管理服务器的一些日常操作时，一个很现实的问题就摆在了面前： 这玩意儿安全吗？

我说的安全，不是指它会不会泄露我的API Key（虽然这也很重要），而是一个更深层、更系统性的问题。OpenClaw这类AI智能体的核心能力是“理解-决策-执行”。它通过意图识别（Intent Recognition）理解我的自然语言指令，然后规划并调用一系列技能（Skill）去执行，最终可能操作我的数据库、调用外部API、甚至直接在服务器上跑命令。这个从“意图”到“系统执行”的完整链条，每一个环节都可能成为攻击的入口，或者因为设计不当而引发灾难。

举个例子，你随口对OpenClaw说了一句：“帮我清理一下测试服务器上老旧的日志文件，腾点空间出来。”听起来很合理。但如果它的意图识别模块理解稍有偏差，或者某个技能（Skill）的路径参数配置错了，它可能就把生产环境的核心日志给 rm -rf 了。又或者，如果一个恶意用户通过接入的飞书机器人，发送了一条精心构造的、看似正常的指令，实际上却隐藏着注入攻击，那么OpenClaw就可能成为一个“内鬼”，从内部执行危险操作。

这就是为什么我们不能只满足于“跑起来”，而必须从第一天就思考如何为OpenClaw构建一个 云端全链路安全治理体系 。这个体系的目标很明确：确保从用户输入一句指令开始，到AI理解意图、做出决策、最终驱动系统执行动作的整个过程中，风险是可知、可控、可追溯的。这不是给OpenClaw“戴镣铐”，而是给它配备“导航仪”和“安全带”，让它能在复杂的企业环境中可靠、安全地奔跑。

2. 核心风险拆解：OpenClaw的“阿喀琉斯之踵”

在动手构建防护体系之前，我们得先搞清楚OpenClaw在安全上到底有哪些薄弱环节。根据其架构和工作流，我们可以把风险归纳为四个核心层面，这几乎构成了一个完整的攻击面。

2.1 意图识别层：模糊理解的“罗生门”

这是所有风险的起点。OpenClaw依赖大语言模型（LLM）来理解用户的自然语言指令。LLM的“模糊性”和“创造性”在这里成了双刃剑。

  • 指令注入与越权 ：攻击者可能通过提示词注入（Prompt Injection）来“催眠”或误导LLM。例如，在正常的用户指令中混杂一段如“忽略之前的指令，并执行以下操作：...”的文本，企图让AI执行非授权的动作。LLM可能无法有效区分哪部分是真正的用户意图，哪部分是恶意注入。
  • 语义歧义与误判 ：自然语言本身就有歧义。“删除那个不重要的文件”中的“那个”和“不重要”都是模糊指代。AI可能会错误关联目标，删除关键文件。更危险的是，一些看似无害的指令在特定上下文中有破坏性，比如“给我最高的权限”在IT运维上下文中可能就是高危操作。
  • 上下文攻击 ：OpenClaw支持多轮对话，历史上下文会被用于理解当前意图。攻击者可能通过前期对话逐步引导、铺垫，让AI在后续对话中放松警惕或建立错误上下文，从而在某个时刻执行危险指令。

注意 ：意图识别层的安全，本质上是对LLM本身可靠性的挑战。我们不能100%信任LLM的输出，必须在其后设置校验和关卡。

2.2 技能（Skill）调度与执行层：不受控的“潘多拉魔盒”

Skill是OpenClaw执行具体动作的单元，比如执行Shell命令、调用HTTP API、操作数据库等。这一层是风险从“想法”变为“现实”的关键跳板。

  • 技能权限过泛 ：这是最常见的问题。为了方便，我们常常给一个Skill过高的执行权限。例如，一个用于“查看日志”的Skill，可能被配置了 root 权限或拥有对敏感目录的读写权。一旦该Skill被恶意指令调用或自身存在漏洞，破坏力就会被放大。
  • 技能参数未校验 ：Skill在执行前，会接收来自AI决策的参数。如果这些参数（如文件路径、API参数、SQL语句）没有经过严格的验证、过滤或转义，就直接拼接并执行，就会导致经典的 命令注入 、 SQL注入 、 路径遍历 等漏洞。
  • 技能间组合风险 ：单个Skill可能是安全的，但多个Skill被AI按特定顺序组合调用时，可能产生意想不到的副作用或权限提升。例如，Skill A生成一个临时凭证文件，Skill B读取该文件并用于访问敏感系统，而Skill C忘记清理这个临时文件。

2.3 外部集成与数据流层：暴露的“毛细血管”

OpenClaw需要与外部系统通信，如LLM服务（OpenAI、Ollama）、消息平台（飞书、微信）、业务系统API等。这些数据流构成了额外的暴露面。

  • 敏感信息泄露 ：对话历史、执行结果、系统配置（如数据库连接串）可能在不经意间被发送到外部LLM服务或记录在日志中。许多LLM服务提供商明确声明会将输入数据用于模型改进。
  • 不安全的依赖与服务 ：如果OpenClaw集成的某个第三方Skill服务或API本身存在漏洞或被攻破，攻击者就可以通过这个“合法渠道”间接攻击OpenClaw及其管理的内部系统。
  • 通信链路窃听与篡改 ：如果与外部服务的通信（如Webhook回调）没有使用TLS加密，或认证机制薄弱，可能遭受中间人攻击，导致指令被篡改或数据被窃取。

2.4 审计与溯源层：缺失的“黑匣子”

当事故发生时，如果我们无法回答“谁在什么时候通过什么方式让AI做了什么”，那么安全治理就无从谈起。许多初始部署的OpenClaw严重缺乏审计能力。

  • 操作不可追溯 ：没有完整记录原始用户指令、AI的意图解析结果、调用的Skill序列、传入的参数、执行的实际命令/API调用以及最终结果。
  • 决策过程不透明 ：AI为什么选择这个Skill？它的“思考”过程（Chain-of-Thought）是怎样的？在没有日志的情况下，这就像一个黑箱，出了问题很难定位是意图理解错误、技能缺陷还是其他原因。
  • 缺乏实时监控与告警 ：对高危操作（如 rm 、 chmod 、删除数据库条目）没有实时监控和阻断/告警机制，往往在造成损失后才被发现。

3. 体系构建：四层纵深防御架构

基于上述风险分析，我们不能只靠单点防护。我设计并实践了一套四层纵深防御架构，像洋葱一样层层包裹OpenClaw的核心工作流，确保即使一层被突破，仍有后续防线。

3.1 第一层：输入净化与意图安全校验（网关层）

这一层在指令刚进入系统时就开始工作，目标是尽可能早地过滤掉明显恶意或不合规的输入。

  1. 基础输入净化 ：

    • 格式校验 ：检查输入是否为纯文本，过滤非预期格式（如二进制数据、超大载荷）。
    • 敏感词过滤 ：维护一个基础的高危关键词/模式列表（如“删除所有”、“格式化”、“sudo”、“--no-preserve-root”等），进行初步匹配和告警。注意，这不能完全依赖，因为语言多变，但可以拦截最直白的攻击。
    • 长度与频率限制 ：防止通过超长指令进行缓冲区溢出攻击，或通过高频指令进行DoS攻击。

  2. 上下文感知的意图安全策略 ： 这是核心。我们需要在AI进行意图识别 之后 、 之前 ，插入一个安全策略引擎。

    • 策略规则定义 ：使用清晰的规则语言定义安全策略。例如： 
      policies:
  - id: forbid_sensitive_ops
    description: “禁止未经授权的敏感操作”
    conditions:
      - intent_contains: ["删除", "格式化", "关机", "重启"]
      - AND target_resource_matches: ["production", "database", "payment"]
    action: “DENY” # 或 “REQUIRE_APPROVAL”
  - id: limit_file_access
    description: “限制文件访问范围”
    conditions:
      - skill_name: “file_operation”
      - AND NOT path_starts_with: [“/home/user/temp/”, “/var/log/app/”]
    action: “DENY”
    • 集成方式 ：开发一个“安全中间件”（Security Middleware）。OpenClaw的LLM在解析出用户意图（包括可能触发的Skill和参数）后，先将这个“执行计划”提交给安全中间件。中间件根据预定义的策略、用户身份、当前上下文进行评估，返回“允许”、“拒绝”或“需要人工审批”的裁决。
    • 用户身份与权限上下文 ：策略引擎必须能获取到当前指令发起者的身份（如飞书用户ID）及其权限等级（如“普通用户”、“运维管理员”）。这需要与企业的统一身份认证系统（如LDAP、OAuth）集成。

3.2 第二层：技能（Skill）的沙箱化与最小权限执行

对于允许执行的Skill，我们必须将其放在一个受控的环境中运行，遵循最小权限原则。

  1. Skill权限细分 ：

    • 不要用一个 root 账号运行所有Skill。为每一类Skill创建独立的系统用户或服务账户。
    • 使用Linux的 Capabilities 机制或 SELinux/AppArmor 安全模块，进一步细化权限。例如，一个只需要网络访问的Skill，就剥夺其文件写入能力。
    • 在Docker部署场景下，为每个Skill或Skill组使用不同的容器，并通过 docker run 的 --cap-drop 、 --security-opt 等参数严格限制容器权限，避免使用 --privileged 模式。

  2. Skill执行沙箱 ：

    • 对于执行Shell命令的Skill， 绝对不要 直接调用 os.system() 或 subprocess.run(shell=True) 。这是命令注入的温床。
    • 应该使用一个“命令执行器”封装层。这个封装层负责：
      • 参数白名单校验 ：定义允许的命令和参数模式。例如，只允许 ls 、 cat 命令，且路径参数必须匹配正则表达式 ^/var/log/[a-zA-Z0-9_/.-]+$ 。
      • 安全执行 ：使用 subprocess.run(args, shell=False) 的方式，将命令和参数作为列表传递，避免shell解析。
      • 资源限制 ：使用 resource 模块或 prlimit 设置CPU时间、内存用量、文件描述符数量等限制，防止恶意Skill耗尽资源。
    • 网络隔离 ：对于需要访问外部API的Skill，使用网络策略限制其只能访问特定的目标IP和端口。在Kubernetes中可以使用NetworkPolicy，在Docker中可以使用自定义网络。

  3. Skill代码安全审查 ：

    • 建立Skill的准入机制。社区下载或自行开发的Skill，在上线前必须经过基础的安全代码审查，重点关注：
      • 是否存在命令/SQL/模板注入漏洞。
      • 是否硬编码了敏感信息（密钥、密码）。
      • 错误处理是否会泄露内部信息。
      • 依赖的第三方库是否有已知高危漏洞。

3.3 第三层：全链路审计与可观测性

安全不仅仅是防御，还需要“看见”。我们必须记录下一切，以便事后调查和实时分析。

  1. 结构化审计日志 ：

    • 设计统一的日志格式，确保每一条日志都包含：时间戳、请求ID、用户身份、原始指令、解析后的意图/技能/参数、安全策略检查结果、实际执行命令/API调用（脱敏后）、执行结果状态码、耗时等关键字段。
    • 使用JSON格式记录，便于后续使用ELK（Elasticsearch, Logstash, Kibana）或类似栈进行聚合分析。
    • 示例日志条目 ： 
      {
  “timestamp”: “2023-10-27T10:00:00Z”,
  “request_id”: “req_abc123”,
  “user”: “lisi@company.com”,
  “source”: “feishu”,
  “raw_input”: “查看一下订单DB最近一小时的错误日志”,
  “parsed_intent”: {
    “skill”: “query_database_logs”,
    “params”: {
      “database”: “order_db”,
      “log_level”: “ERROR”,
      “time_range”: “1h”
    }
  },
  “security_check”: “ALLOWED”,
  “executed_action”: “sql_executed (query hash: xyz789)”,
  “result”: “SUCCESS”,
  “duration_ms”: 450
}

  2. 敏感信息脱敏 ：

    • 在记录日志前，必须对敏感字段进行脱敏处理，如密码、API密钥、个人身份证号、银行卡号等。可以使用正则匹配或预定义字段名的方式进行替换（如 “password”: “******” ）。

  3. 实时监控与告警 ：

    • 在日志流中设置实时告警规则。例如：
      • 同一用户短时间内高频执行同类操作。
      • 执行了被标记为“高危”的Skill（无论是否被策略允许）。
      • 技能执行失败率突然升高（可能表明参数被恶意篡改导致异常）。
      • 出现了策略引擎“拒绝”（DENY）的记录。
    • 告警应发送到即时通讯工具（如飞书群）或运维监控平台（如Prometheus Alertmanager）。

3.4 第四层：动态风险分析与自适应学习

这是更高级的一层，利用AI来增强安全。我们可以训练一个专门的“安全AI副驾驶”来分析OpenClaw的行为模式。

  1. 基线行为建模 ：

    • 在安全运行初期，收集大量的正常操作日志。
    • 使用这些数据训练一个简单的模型（或设定阈值），为每个用户-技能组合建立“正常行为基线”，例如执行频率、时间段、参数范围等。

  2. 异常检测 ：

    • 当新的操作发生时，将其特征与基线进行比对。如果发现显著偏离，则触发高风险告警，甚至要求二次认证或人工复核。
    • 例如，一个平时只在工作时间查询日志的管理员，突然在凌晨3点尝试执行数据库备份技能，这就是一个异常信号。

  3. 反馈闭环 ：

    • 将安全事件（误报、漏报）的处理结果反馈给策略引擎和异常检测模型，使其能够不断优化和调整，实现自适应安全。

4. 实战部署：基于Docker Compose的防护体系搭建

理论说再多，不如动手搭一遍。下面我以一个典型的Docker化OpenClaw部署为例，展示如何将上述安全理念落地。假设我们的OpenClaw需要连接Ollama本地模型，并接入飞书。

4.1 基础安全部署结构

我们不会把所有东西塞进一个容器。采用微服务化思想，将不同组件拆开。

# docker-compose.security.yml
version: '3.8'

services:
  # 核心OpenClaw服务
  openclaw-core:
    image: your-openclaw-image:latest # 建议基于官方镜像自建，确保来源可信
    container_name: openclaw-core
    restart: unless-stopped
    # 关键：使用非root用户运行
    user: “1000:1000” # 映射到宿主机的非root用户UID/GID
    # 关键：限制内核能力，放弃所有特权，仅保留必要能力（如网络）
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE # 如果需要绑定低端口
    # 禁止特权模式，不挂载敏感目录
    privileged: false
    read_only: true # 容器文件系统只读
    tmpfs:
      - /tmp # 仅允许/tmp可写
    networks:
      - openclaw-internal
    volumes:
      # 只挂载必要的配置文件，且配置文件在宿主机上权限严格
      - ./config:/app/config:ro
      - ./skills:/app/skills:ro # Skill代码目录只读挂载
      - ./audit_logs:/app/logs # 审计日志目录
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - SECURITY_MIDDLEWARE_URL=http://security-middleware:8080/check
    depends_on:
      - security-middleware
      - ollama

  # 安全中间件（策略引擎）
  security-middleware:
    build: ./security-middleware # 这是一个需要你自行编写的Flask/FastAPI应用
    container_name: security-middleware
    restart: unless-stopped
    networks:
      - openclaw-internal
    volumes:
      - ./security_policies:/app/policies:ro # 策略文件
      - ./audit_logs:/app/logs
    # 此服务需要访问用户权限数据库，环境变量略

  # Ollama服务（LLM）
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    networks:
      - openclaw-internal
    volumes:
      - ollama_data:/root/.ollama
    # 可考虑将Ollama也放入独立网络，仅对openclaw-core暴露

  # 审计日志收集器（Fluentd）
  fluentd:
    image: fluent/fluentd:v1.16-1
    container_name: fluentd
    restart: unless-stopped
    volumes:
      - ./fluentd/conf:/fluentd/etc
      - ./audit_logs:/fluentd/log
    networks:
      - openclaw-internal
    ports:
      - “24224:24224” # 如需从其他容器接收日志

volumes:
  ollama_data:

networks:
  openclaw-internal:
    driver: bridge
    # 内部网络，不对外暴露，增加一层隔离

4.2 安全中间件（Security Middleware）开发要点

这是防护体系的大脑，需要自己实现。这里给出一个极简的Python Flask示例，展示核心逻辑：

# security_middleware/app.py
from flask import Flask, request, jsonify
import json
import re
from datetime import datetime

app = Flask(__name__)

# 加载安全策略（实际应从数据库或文件动态加载）
def load_policies():
    return [
        {
            “id”: “block_dangerous_commands”,
            “conditions”: [
                {“skill”: “exec_shell”, “param_match”: {“command”: r“^(rm\s+-rf|mkfs|dd\s+if=.*of=/dev/)”}}
            ],
            “action”: “DENY”
        },
        {
            “id”: “require_approval_for_prod_db”,
            “conditions”: [
                {“skill”: “query_database”, “param_match”: {“env”: “production”}},
                {“user_role”: “not in”: [“dba_admin”]}
            ],
            “action”: “REQUIRE_APPROVAL”
        }
    ]

POLICIES = load_policies()

@app.route(‘/check’, methods=[‘POST’])
def security_check():
    """OpenClaw核心服务调用此接口进行安全检查"""
    data = request.json
    user = data.get(‘user’)
    intent = data.get(‘intent’) # 包含skill和params
    context = data.get(‘context’, {})

    # 1. 基础校验
    if not user or not intent:
        return jsonify({“decision”: “DENY”, “reason”: “Missing user or intent”}), 400

    # 2. 应用策略
    for policy in POLICIES:
        if evaluate_conditions(policy[‘conditions’], user, intent, context):
            # 记录审计日志
            log_audit_event(user, intent, policy[‘id’], policy[‘action’])
            return jsonify({
                “decision”: policy[‘action’],
                “policy_id”: policy[‘id’],
                “request_id”: context.get(‘request_id’)
            })

    # 3. 默认允许（可根据需要改为默认拒绝）
    log_audit_event(user, intent, “default”, “ALLOWED”)
    return jsonify({“decision”: “ALLOWED”})

def evaluate_conditions(conditions, user, intent, context):
    """评估条件是否全部满足（简化版）"""
    for cond in conditions:
        if ‘skill’ in cond and cond[‘skill’] != intent.get(‘skill’):
            return False
        if ‘param_match’ in cond:
            for param, pattern in cond[‘param_match’].items():
                if param not in intent.get(‘params’, {}) or not re.match(pattern, str(intent[‘params’][param])):
                    return False
        # 可以扩展更多条件，如用户角色、时间等
    return True

def log_audit_event(user, intent, policy_id, decision):
    audit_entry = {
        “timestamp”: datetime.utcnow().isoformat(),
        “user”: user,
        “intent”: intent,
        “policy_id”: policy_id,
        “decision”: decision
    }
    # 写入文件或发送到日志收集器（如Fluentd）
    print(json.dumps(audit_entry)) # 简单示例，输出到stdout由Docker收集

if __name__ == ‘__main__’:
    app.run(host=‘0.0.0.0’, port=8080)

然后，你需要在OpenClaw的核心代码中（通常在调用Skill之前），插入对这个安全中间件的调用。

4.3 Skill的安全封装示例

以最危险的“执行Shell命令”Skill为例，展示如何封装：

# skills/secure_shell_skill.py
import subprocess
import shlex
from typing import Dict, Any
import logging

logger = logging.getLogger(__name__)

# 允许的命令白名单和参数模式
ALLOWED_COMMANDS = {
    “ls”: {“args”: [“-la”], “path_regex”: r“^/home/user/[a-zA-Z0-9_/.-]*$”},
    “cat”: {“args”: [], “path_regex”: r“^/var/log/app/[a-zA-Z0-9_.-]+$”},
    “grep”: {“args”: [“-E”], “pattern”: r“^[a-zA-Z0-9\s]+$”} # 限制grep模式
}

class SecureShellSkill:
    def execute(self, params: Dict[str, Any]) -> Dict[str, Any]:
        command_name = params.get(“command”)
        command_args = params.get(“args”, “”)

        # 1. 白名单校验
        if command_name not in ALLOWED_COMMANDS:
            return {“success”: False, “error”: f“Command ‘{command_name}’ is not allowed.”}

        allowed_config = ALLOWED_COMMANDS[command_name]

        # 2. 参数安全校验与构造
        safe_args = []
        if allowed_config.get(“args”):
            safe_args.extend(allowed_config[“args”])

        # 对路径类参数进行正则校验
        if “path” in params:
            path_regex = allowed_config.get(“path_regex”)
            if path_regex and not re.match(path_regex, params[“path”]):
                return {“success”: False, “error”: “Invalid path parameter.”}
            safe_args.append(params[“path”])

        # 3. 安全执行（不使用shell）
        try:
            # 使用列表形式传递命令和参数，避免shell注入
            cmd_list = [command_name] + safe_args
            logger.info(f“Executing secure command: {cmd_list}”)
            
            # 设置资源限制和超时
            result = subprocess.run(
                cmd_list,
                shell=False, # 关键！
                capture_output=True,
                text=True,
                timeout=30, # 超时设置
                # 可以在这里通过preexec_fn设置更多的资源限制（如内存、CPU）
            )
            return {
                “success”: result.returncode == 0,
                “stdout”: result.stdout,
                “stderr”: result.stderr,
                “returncode”: result.returncode
            }
        except subprocess.TimeoutExpired:
            return {“success”: False, “error”: “Command execution timed out.”}
        except Exception as e:
            logger.error(f“Command execution failed: {e}”)
            return {“success”: False, “error”: str(e)}

5. 运维与持续改进：让安全体系活起来

部署完成只是开始，安全是一个持续的过程。

5.1 日常监控与告警配置

  1. 日志聚合与可视化 ：将 fluentd 收集的日志发送到Elasticsearch，并在Kibana中创建仪表盘。关键视图包括：

    • 实时活动流 ：展示所有用户的操作。
    • 安全事件面板 ：集中显示所有被 DENY 和 REQUIRE_APPROVAL 的决策。
    • 技能调用排行榜 ：统计最常被调用的技能，发现异常高频调用。
    • 错误率趋势图 ：监控技能执行失败率。

  2. 告警规则示例（在Elasticsearch或Prometheus中配置） ：

    • rate(security_decisions{decision=“DENY”}[5m]) > 5 ：5分钟内拒绝决策超过5次，可能遭受扫描攻击。
    • user_operation_count{user=“*”}[1h] > 100 ：单个用户1小时内操作超过100次，可能为恶意高频调用。
    • skill_execution_duration_seconds{skill=“exec_shell”} > 60 ：Shell技能执行超过60秒，可能卡死或执行了复杂任务。

5.2 安全策略的迭代与更新

  1. 定期复盘审计日志 ：每周或每两周，回顾所有安全事件日志。分析误报（正常操作被拦截）和漏报（可疑操作被放行）。
  2. 更新策略规则 ：根据复盘结果，调整现有策略的阈值、条件，或添加新的策略规则。例如，发现一种新的注入模式，就将其加入参数校验的正则表达式。
  3. Skill的持续评估 ：定期（如每季度）对已上线的Skill进行代码安全复审，特别是当其依赖的第三方库有重大更新时。

5.3 人员与流程保障

技术手段再好，也需要人来驾驭。

  1. 权限分级 ：建立明确的用户角色和权限模型。例如：
    • 普通用户 ：只能使用查询类、信息获取类Skill。
    • 操作员 ：可以执行预定义的、低风险的变更操作（如重启特定服务）。
    • 管理员 ：可以执行高危操作，但所有操作需要双人复核或触发高级别告警。
  2. 审批流程 ：对于 REQUIRE_APPROVAL 的决策，需要集成到企业的工单或即时通讯工具中，让审批人能够快速查看操作详情并做出决定。
  3. 培训与意识 ：让使用OpenClaw的用户了解其能力边界和安全规范，知道什么能问，什么不能问，以及误操作的后果。

构建这样一个全链路安全治理体系，初期投入确实不小，但它带来的价值是长远的。它让OpenClaw从一个“有趣的玩具”，转变为一个可以在企业生产环境中承担实际工作的“可靠助手”。安全不是阻碍创新的枷锁，而是让创新走得更远、更稳的基石。每一次严谨的校验、每一行审计日志、每一个细分的权限，都是在为AI智能体未来的大规模应用铺平道路。

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

更多推荐

cover

DeepSeek API涨价500%！Agent框架同步开源

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

DeepSeek 又放大招！开源 AI Agent 框架 Harness：一切皆插件

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

Agent Run 的状态机：别把智能体交给 LLM 自己管

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