亚马逊AWS官方博客

OpenClaw + Amazon Bedrock + Amazon EKS联动实践：打印机包装质检助手实战

摘要：随着打印机出厂包装质检工作量的增长，产线质检员每天需要目视比对大量包装图片，判断泡沫托盘中每个槽位的配件是否齐全。传统方式准确率和效率难以保障。希望借助 AI Agent 将领域专家的判断规则固化下来，同时保持快速迭代能力。

1、前言

OpenClaw是一款面向个体开发者与企业的开源 Agentic IDE/CLI，支持 TUI、飞书/Lark、Slack 等多种 Channel 接入，可以将用户意图转化为自动化工作流，配合 Skill 机制把领域知识直接注入 Agent。

Amazon Bedrock是亚马逊云科技提供的企业级托管大模型服务，通过统一 API 即可调用 Anthropic Claude、Meta Llama、Amazon Nova等主流基础模型，无需管理模型基础设施，天然支持私有网络、IAM 细粒度授权和审计合规。

Amazon EKS Auto Mode是 Amazon Elastic Kubernetes Service 的托管模式，节点、存储、网络、自动扩缩容均由 AWS 全权管理，用户只需关注应用本身，大幅降低Kubernetes运维复杂度。

随着打印机出厂包装质检工作量的增长，产线质检员每天需要目视比对大量包装图片，判断泡沫托盘中每个槽位的配件是否齐全。传统方式准确率和效率难以保障。希望借助 AI Agent 将领域专家的判断规则固化下来，同时保持快速迭代能力。

2、业务背景与客户痛点

2.1 客户场景介绍

客户是国内领先的打印机制造商，其国际事业部负责打印机的出厂质量管理。随着海外订单量快速增长，出厂前的包装质检成为瓶颈环节。目前客户采用人工目视的方式对照《出厂配件清单》，逐一核对每台机器包装盒中的配件：一台打印机的包装箱内配件包括：通讯线袋、测试耗材、料架支撑、显示器、缓冲器、工具包、电源线等7类；每个配件固定放入黑色泡沫托盘的专属凹槽内。质检员需要比对”正常样例图”和”异常样例图”（如缺缓冲器时的包装图），判断待检件是否齐全。判断规则相对复杂：

  1. 槽位识别：泡沫托盘分左右两块，每个凹槽有特定形状（矩形、圆形、L 形、条形）；
  2. 异色判断：有配件时槽内应能看到异于黑色泡沫的物体（银白、透明、金属光泽等）；
  3. 遮挡处理：工具包可能遮挡缓冲器槽，需要人工复核；
  4. 空槽识别：空槽的泡沫形状轮廓容易被误判为”有配件”；

2.2 核心痛点分析

通过和客户相关人员的深度访谈和场景调研，我们识别出以下核心痛点：

1、人工目检效率低下

  • 每台机器包装入库需要拍照 + 人工比对，单次平均 30 秒
  • 每天上百台机器的峰值产能下，质检员累计工时按小时计
  • 临近下班疲劳度高，漏检率明显上升

2、判断标准依赖个人经验

  • 新员工需要数周跟老师傅学习才能独立判断
  • 不同质检员对”拿不准”的模糊案例判断不一致
  • 缺少标准化的输出报告用于追溯

3、企业内部沟通基础设施已有

  • 产线 QA 工作全部通过飞书群沟通
  • 希望 AI 助手直接接入现有飞书工作流，不再增加额外的操作工具

4、私有化/合规要求

  • 包装图可能涉及产品外观设计，不希望上传到公网 SaaS
  • 要求模型推理在 AWS 账户内闭环，走 VPC Endpoint 访问 Bedrock5、迭代频率高
  • 配件清单会随产品迭代变化（比如下个月新增一款配件盒）
  • 要求业务侧可以在不发版的情况下自行更新判断规则

2.3 技术方案选型

基于客户的实际情况和业务诉求，我们选择了Amazon EKS Auto Mode + Amazon Bedrock + OpenClaw的组合方案。

2.3.1 AI 能力以 Skill 形式交付，而非微调

打印机包装判断属于典型的**规则化视觉判断**任务：判据（哪个槽有什么、如何辨认有无）可以用自然语言清晰描述，但配件清单会随产品迭代。Fine-tune 成本高、迭代慢、绑死模型；RAG 不擅长结构化判断步骤；而 **OpenClaw 的 Skill 机制** 把 SKILL.md + 参考样例图打包成一个资源包，Agent 在识别到触发条件时自动加载并按步骤执行，迭代规则只需改一个 markdown 文件，几秒内生效。

2.3.2 Bedrock 支持私有化多模态调用

Claude Sonnet 4.6 原生支持图片输入 + 文本输出，通过 Bedrock 调用可以：- 在客户 AWS 账户 VPC 内部，走 VPC Endpoint，数据不出账户- 使用 IAM 或 Long-term API Key 做细粒度授权- CloudTrail 全量审计，满足合规要求- 成本按 Token 实际用量计费，无最低消费

2.3.3 Amazon EKS Auto Mode 降低运维负担

OpenClaw 需要长驻 gateway 进程（Channel 接入、TUI、Session 管理），天然适合容器化部署。Amazon EKS Auto Mode 自动管理节点、存储卷、扩缩容、安全补丁，运维团队不需要关心 Node 层的维护。Pod 使用 EFS 做持久化存储，自定义 Skill 和 Agent 记忆跨 Pod 重启不丢失。

2.3.4 飞书 Channel 作为用户入口

客户已经全员使用飞书进行内部沟通。OpenClaw 提供开箱即用的飞书 Channel，通过 WebSocket 与飞书开放平台连接，质检员在飞书中 @机器人并上传包装图片即可触发质检，结果以标准化报告形式在飞书消息中返回。无需额外部署 Web UI、移动端或小程序。

3、系统架构详细设计

系统整体架构如下图所示：

[图1：架构图]

整体包括以下三个部分。第一部分是：使用 CloudFormation 完成 EKS Auto Mode + OpenClaw 的生产级部署；第二部分是：将领域知识打包成 OpenClaw Skill 注入 workspace；第三部分是：通过飞书 Channel 接入现有工作流，质检员用自然对话方式完成包装质检。

3.1 基于 CloudFormation 的 EKS + OpenClaw 部署

传统的 Kubernetes 集群部署需要手写 Terraform/CloudFormation，处理 VPC、子网、节点组、IAM、CNI、CSI、Ingress 等大量模板，对于只想跑一个 Agent 的场景非常重。借助 Amazon EKS Auto Mode + AWS 托管节点，我们能将整个部署收敛到 9 个嵌套 CloudFormation 模板，覆盖网络、安全、存储、集群、认证、Ingress、监控、租户资源。部署命令只有两条：`aws cloudformation package` + `aws cloudformation deploy`。

3.1.1 OpenClaw 在容器中的启动流程

OpenClaw 本身是一个 Node.js 单体应用，启动后开启 Gateway（默认端口 18789），向 WebSocket Channel 维持长连接，并提供 TUI/HTTP 双重访问入口。我们把它部署为 Kubernetes Deployment，1 个副本，使用两层存储：

目录 存储类型 保留策略 用途
/home/node emptyDir Pod 重启丢 Session 历史、临时缓存
/home/node/.openclaw/workspace EFS PVC 持久化 Skill、AGENTS.md、长期记忆

initContainer 的职责：Pod 每次启动时一次性把 Gateway 的必备配置写齐，避免主进程读到半成品配置：

initContainers:
  - name: init-config
    image: ghcr.io/openclaw/openclaw:2026.4.15
    args:
      - |
        set -e
        export HOME=/home/node
        mkdir -p /home/node/.openclaw
        openclaw config set gateway.mode local
        openclaw config set gateway.bind lan
        openclaw config set gateway.port 18789
        openclaw config set gateway.auth.mode token
        openclaw config set gateway.auth.token "<token>"
        openclaw config set gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback true
        openclaw config set gateway.controlUi.allowedOrigins '["http://localhost:18789","http://127.0.0.1:18789"]'
        openclaw models set amazon-bedrock/us.anthropic.claude-sonnet-4-6
        openclaw plugins enable amazon-bedrock || true

关键点：plugins enable amazon-bedrock必须放在initContainer里，否则TUI状态栏会显示 model: unknown（Gateway 启动时没拿到 provider 元数据）。

3.1.2 OpenClaw 调用 Bedrock 的两种认证方式

OpenClaw的amazon-bedrock插件支持两种调用凭据：

方式 机制 适用场景
IRSA SigV4 通过 ServiceAccount 绑定 IAM Role，OpenClaw 用 STS 换短期 Token 生产环境首选，满足最小权限
Long-term API Key Bedrock 控制台创建持久 Key，注入AWS_BEARER_TOKEN_BEDROCK环境变量 POC、快速验证

本次 POC 使用 Long-term API Key 方案，配合 Kubernetes Secret 注入：

# 创建 Bedrock API Key Secret
kubectl create secret generic bedrock-api-key \
  --from-literal=AWS_BEARER_TOKEN_BEDROCK='<your-bedrock-api-key>' \
  -n openclaw-default
# 通过 Deployment patch 注入为环境变量
kubectl patch deployment openclaw -n openclaw-default --patch-file k8s-manifests/bedrock-env-patch.yaml

生产环境我们推荐切换到 IRSA，trust policy 必须包含sts:TagSession（EKS Auto Mode 要求），IAM Policy 只授予 bedrock:InvokeModel针对特定 Model ARN。

3.1.3 VPC Endpoint 打通私有网络

为了保证数据不出 AWS 账户，并且 Pod 在私有子网内也能访问所有必需服务，CloudFormation 模板创建了 4 个 VPC Endpoint：

Endpoint 用途 Security Group 放行
com.amazonaws.us-east-1.bedrock-runtime Bedrock API 调用 VPC CIDR ingress 443
com.amazonaws.us-east-1.s3 Gateway 接口/日志 VPC CIDR ingress 443
com.amazonaws.us-east-1.sts IRSA Token 换发 VPC CIDR ingress 443
EFS Mount Target EFS PVC 持久化 VPC CIDR ingress 2049

关键点：EKS Auto Mode 创建的 Pod SG 不固定，VPC Endpoint SG 必须放行整个 VPC CIDR 段，否则 Bedrock/EFS/STS 调用全部超时。

[图2：EKS 控制台 Pod Running 截图]

[图3：CloudFormation9个嵌套 Stack 部署完成截图]

3.2 自定义 Skill 开发与部署

3.2.1 什么是 OpenClaw Skill

Skill是OpenClaw中用于向 Agent 注入领域知识的轻量机制。一个 Skill 是一个目录，包含：1、SKILL.md必需，定义触发条件、执行步骤、输出格式；2、任意参考资源（样例图、模板、JSON 规则表等）。

Agent在接收到用户消息时，会根据SKILL.md头部的description做语义匹配，一旦命中则自动加载SKILL.md并按步骤执行。相比RAG（不擅长结构化步骤），Skill 在规则化垂直任务上迭代速度最快、可解释性高。

3.2.2 Skill 包结构

本次 POC 使用的质检 Skill 目录结构如下：

creality***-packaging-inspection/
├── SKILL.md           (5.5 KB) — Skill 入口文档
├── 正常.jpeg          (5.2 MB) — 基准图：所有配件齐全
├── 异常.jpeg          (4.5 MB) — 基准图：缺缓冲器
├── 料架支撑.jpeg
├── 测试耗材.jpeg
├── 通讯线.jpeg
├── 工具包.jpeg
├── 显示器.jpeg
├── 电源线.jpeg
└── 缓冲器.jpeg

SKILL.md采用YAML Front Matter + Markdown 正文的结构：

---
name: creality***-packaging-inspection
description: Use when inspecting printer packaging photos to identify all accessories and detect missing items. Triggers on unboxing images, packaging QC tasks, or accessory verification requests.
---
# Printer Packaging Inspection
## Overview
Visually inspect packaging photos to identify all accessories and flag missing items by comparing against the standard accessory list and reference images.
## Standard Accessory List
| # | 配件 | 标识特征 |
|---|------|---------|
| 1 | 电源线 | 黑色AC线缆，一端Schuko插头，一端C13接口 |
| 2 | 料架支撑 | 黑色L形金属支架，带横向圆管 |
| 3 | 缓冲 | 黑色矩形透明塑料盒，内有弹簧/缓冲结构 |
| 4 | 工具包 | 透明密封袋，内含内六角扳手、螺丝刀等工具 |
| 5 | 测试耗材 | 品牌PLA线材卷，带黑色注意标签 |
| 6 | 通讯线袋 | 透明袋，内含说明卡和485通讯线（45cm+100cm各一） |
| 7 | 说明书 | 纸质快速入门指南，装于透明袋 |
## Reference Images
**正常包装（所有配件齐全）：**
![正常包装](正常.jpeg)
泡沫格布局：
- 左上：说明书袋
- 左下：测试耗材线材卷
- 右上：料架支撑（L形支架）
- 右中上：工具包（透明工具袋）
- **右中：缓冲器（黑色矩形透明盒）← 关键检测点**
- 右中条形槽：导轨/横梁配件
- 右下：电源线 + 通讯线袋
---
**异常包装（缺少缓冲器）：**
![缺少缓冲器](异常.jpeg)
缺陷特征：右中泡沫凹槽为**空**，正常情况下应有黑色矩形透明缓冲盒。
## Component Reference
| 配件 | 参考图 |
|------|--------|
| 测试耗材 | ![](测试耗材.jpeg) |
| 电源线 | ![](电源线.jpeg) |
| 工具包 | ![](工具包.jpeg) |
| 缓冲器 | ![](缓冲器.jpeg) |
| 料架支撑 | ![](料架支撑.jpeg) |
| 通讯线袋 | ![](通讯线.jpeg) |
## Inspection Steps
1. **定位泡沫格布局** — 识别俯视开箱图中各凹槽区域
2. **逐项对照** — 按标准配件列表逐一确认是否可见
3. **重点检查右中凹槽** — 缓冲器是高频漏放配件，该槽为空即判定漏放
4. **输出报告** — 使用下方格式
## Output Format
```
 ****包装质检报告
━━━━━━━━━━━━━━━━━━━━━━
 图像：俯视开箱图 / 识别到 X 个配件
✅ 已确认配件：
• 料架支撑 ✓
• 工具包 ✓
• 测试耗材 ✓
• 电源线 ✓
• 通讯线袋 ✓
• 说明书 ✓
❌ 漏放配件：
1. 【高】缓冲器 — 右中泡沫凹槽为空
⚠️ 需人工复核：
• （如有遮挡或不确定项）
 漏放位置：右侧泡沫格中部凹槽
```
## Priority Classification
- **高优先级**：缓冲器、工具包、料架支撑（功能性配件）
- **中优先级**：电源线、测试耗材、通讯线袋
- **低优先级**：说明书
## Common Mistakes
| 错误 | 处理 |
|------|------|
| 缓冲器被工具包遮挡 | 标记"⚠️ 需复核"，不直接判漏放 |
| 图片角度不佳看不清右中槽 | 要求补拍该区域特写 |
| 工具包透明袋内容物不清 | 只需确认袋子存在，不需清点袋内工具 |

设计亮点：

  1. description写得极其具体：`Use when` + 触发词（unboxing images / packaging QC / accessory verification）。Agent 匹配 Skill的唯一依据就是这段；
  2. 强制先读基准图：用”在回复用户任何内容之前，必须”这类强约束词，避免Agent上来就猜；
  3. 拿不准就停：CRITICAL JUDGMENT RULE 显式告诉 Agent “不要猜测为’有'”，这是减少幻觉的最简单也最有效的手段；
  4. 相对路径 + base_dir：SKILL.md 不硬编码绝对路径，OpenClaw 会在 Agent 上下文注入 `base_dir`，跨环境部署无需修改；

3.3 让 Agent “知道”Skill 存在

装好 Skill 后，我们立刻在飞书上验证——上传一张包装图，只说一句”帮我检查下”：

机器人回复： 我没有叫creality***-packaging-inspection的技能——我的可用技能列表里没有这个。

但 openclaw skills list 明明显示✓ ready。遇到了OpenClaw一个很关键的设计点：Skill 不会自动加载进 Agent 的 Context。查workspace里的 AGENTS.md（Agent的基础 System Prompt），关于Skill的部分只有一句：

Skills provide your tools. When you need one, check its SKILL.md.

“你要用的时候自己去 skills /目录翻一下”。但 LLM 不会”自己翻”——它只会基于当前 Context 里看到的信息做决策。这本质上和RAG的召回问题一样：没被放进Context的东西，LLM 永远”不存在”。我们修改下将Skill清单追加到 AGENTS.md 末尾：

kubectl exec -n openclaw-default $POD -c openclaw -- \
  sh -c 'cat >> /home/node/.openclaw/workspace/AGENTS.md <<EOF

##  Available Workspace Skills

These skills are installed in ~/.openclaw/workspace/skills/. When a
user request matches a skill trigger, read its SKILL.md first, then
follow its steps.

- **creality***-packaging-inspection** — Use when inspecting Creality***
  printer packaging photos to identify all accessories and detect
  missing items. Triggers: unboxing images, packaging QC, accessory
  verification, 包装质检, 配件检查, 缺件识别.
  - Read: ~/.openclaw/workspace/skills/creality***-packaging-inspection/SKILL.md

When users upload images related to printer packaging, you MUST
invoke the creality***-packaging-inspection skill.
EOF'

开新会话再测试，Agent 正常触发。我们用两个极端样例来验证 Skill 的实际判断能力。

场景 1：空托盘（所有配件都漏放）

质检员拍一张只有黑色泡沫托盘、没有任何配件的照片发给飞书机器人：

[图4]

用户上传一张没有任何配件的空泡沫托盘图，机器人正确识别为「已确认配件 0 件 / 漏放配件 7 件」，逐槽给出漏放项，并在结论中明确标注”这是一个空托盘”。每个漏放项都带优先级标签（高/中），便于后续处理排序。

场景 2：配件基本齐全但缺显示器（真实产线常见缺件场景）

质检员拍一张 6 件配件到位、但显示器忘放（右中矩形槽空）的照片：

[图5]

用户上传一张”看起来基本齐全”的包装图，机器人仍然准确识别出右中矩形槽缺少显示器，并标记为「高优先级」漏放项。整判断耗时约 5 秒，与资深质检员的目检结果完全一致。

这就是 Skill 方法论的核心价值：把资深质检员的判断规则（”空槽要看见黑色泡沫底”、”显示器槽要看到银色铝箔反光”）固化到 SKILL.md，让每个新员工都能输出资深水准的质检报告。不需要跟师傅学几周，不需要记住 7 个槽位的细节特征——规则都在 Skill 里，Agent 负责执行，人类负责复核高风险项。

4. 4 经验总结

在将OpenClaw部署到Amazon EKS Auto Mode并对接Bedrock + 飞书的过程中，我们遇到了一些典型问题。本节将这些经验整理成最佳实践，帮助开发者少走弯路。

4.1 EKS Auto Mode 部署经验

问题 1：EKS Auto Mode节点创建失败，Pod一直 Pending。

原因：EKS Auto Mode要求Cluster IAM Role 的Trust Policy必须包含sts:TagSession权限，这和传统EKS的要求不同。

解决方案：CloudFormation模板中显式添加：

ClusterRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
        - Effect: Allow
          Principal:
            Service: eks.amazonaws.com
          Action:
            - sts:AssumeRole
            - sts:TagSession    # EKS Auto Mode 必须

问题 2：VPC Endpoint不通，Pod访问Bedrock/EFS/STS全部超时。

原因：EKS Auto Mode自动创建的Pod Security Group没有固定ID，VPC Endpoint 的SG无法精确放行。

解决方案：VPC Endpoint SG放行整个VPC CIDR段：

VPCEndpointSG:
  Type: AWS::EC2::SecurityGroup
  Properties:
    SecurityGroupIngress:
      - IpProtocol: tcp
        FromPort: 443
        ToPort: 443
        CidrIp: !Ref VpcCidr   # 10.0.0.0/16，覆盖所有 Pod

问题 3：Port-forward不稳定，kubectl port-forward经常broken pipe。

解决方案：直接kubectl exec进Pod跑TUI比port-forward稳定得多，并且免公网暴露：

POD=$(kubectl get pod -n openclaw-default -l app=openclaw \
       -o jsonpath='{.items[0].metadata.name}')
kubectl exec -it -n openclaw-default $POD -c openclaw -- \
  env HOME=/home/node openclaw tui

4.2 OpenClaw 版本选型

问题 1：OpenClaw 2026.5.2 飞书插件死循环重启，日志持续报 __dirname is not defined in ES module scope。

原因：这是OpenClaw上游2026.5.x系列的已知打包bug，feishu插件在 ESM 模式下触发__dirname 未定义。容器内 /app/dist/ 是overlay层，任何in-place patch都会在重启后被还原。

解决方案：回滚到社区验证过的 2026.4.15 稳定版本：

kubectl set image deployment/openclaw -n openclaw-default \
  openclaw=ghcr.io/openclaw/openclaw:2026.4.15 \
  init-config=ghcr.io/openclaw/openclaw:2026.4.15

建议：生产环境严禁使用:latest tag，必须固定到社区验证过的具体版本。

问题 2：Pod 重启后TUI状态栏显示model: unknown。

原因：initContainer的openclaw config set每条都是独立进程重写config 文件，Gateway主进程启动时读到某一个中间态 config。

解决方案：initContainer内必须一次性完整写齐所有配置，包括：

openclaw config set gateway.mode local
openclaw config set gateway.bind lan
openclaw config set gateway.port 18789
openclaw config set gateway.auth.mode token
openclaw config set gateway.auth.token "<token>"
openclaw config set gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback true
openclaw config set gateway.controlUi.allowedOrigins '["http://localhost:18789","http://127.0.0.1:18789"]'
openclaw models set amazon-bedrock/us.anthropic.claude-sonnet-4-6
openclaw plugins enable amazon-bedrock || true    # 关键：不加这行 TUI 拿不到 model 元数据

5、成本分析

场景：POC日均200次质检请求 × 2张图片，月运行30天 × 24小时。

序号 费用类别 实际运行资源 月用量 官方单价（us-east-1） 月费用（USD）
1 Amazon EKS Auto Mode 1 个 EKS 集群 730 h $0.10/h $73
2 Amazon EC2（计算节点） c6a.large 730 h $0.0765/h $55.85
3 Amazon Bedrock(Claude Sonnet 4.6) 200 次/天 × 30 天 × 7004 tokens = 42.024M input:42.024M tokensoutput:3.6M tokens input:$3/1Moutput:$15/1M $180
4 NAT Gateway（2 个，跨 AZ 高可用） 2 × us-east-1a/b 2 × 730 h $0.045/h  $0.045/GB $65.70
5 VPC 4 个 × 2 AZ 8 × 730 h $0.01/h  $0.01/GB $58
6 EFS Skill 资源 $0.30/GB-月 $0.01
合计 $438.56

后续降本建议

  • 非工作时段 scale 到 0：kubectl scale deployment openclaw --replicas=0，只保留 EFS（几乎免费）
  • 生产量大时切换到 Claude Haiku 4 完成图片识别的第一道筛查，复杂判断才升级到 Sonnet 4.6
  • Cluster 跨多个租户共享 Pod（OpenClaw 支持多租户命名空间）

6、结论

本文展示了如何基于OpenClaw + Amazon EKS Auto Mode + Amazon Bedrock的组合，在客户AWS账户内部署一个完整的视觉质检AI Agent。覆盖了从CloudFormation基础设施自动化、OpenClaw容器化、自定义 Skill 开发与安装、飞书Channel 接入、Agent 架构选型到成本优化的完整实施路径。

核心贡献

  1. 方法论创新：验证了OpenClaw Skill机制在垂直规则化判断任务上的性价比优势——相比Fine-tune和RAG，Skill 的迭代速度（改 Markdown立即生效）、调试友好度（人可读）、跨模型迁移性（无状态）都是碾压级别。
  2. 架构优势：Amazon EKS Auto Mode + Amazon Bedrock VPC Endpoint 的组合，让客户既享受了Kubernetes的编排能力和模型的私有化推理，又避免了传统Kubernetes的运维复杂度和自建模型的资源投入。
  3. 业务价值：打印机出厂包装质检从”人工看 30 秒 + 经验判断”升级为”发图 5 秒出标准化报告”，准确率对齐资深质检员，通过已有的飞书入口触达产线员工，无需学习新系统。

Skill vs Fine-tune vs RAG 选型建议

维度 Skill Fine-tune RAG
1 准备成本 几小时写 SKILL.md 几千到几万条标注数据 建索引 + 切分 + 嵌入
2 迭代速度 改 Markdown 立即生效 重训几小时到几天 重建索引几分钟到几小时
3 适合场景 SOP 类、规则清晰 通用能力提升、风格固化 大量事实性知识检索
4 跨模型迁移 ✅ 无状态 ❌ 绑死模型版本 ✅ 无状态
5 调试友好度 ✅ 人可读 ❌ 黑盒 ⚠️ 看召回结果

Skill 适用的三个前提

  1. 任务有明确的步骤化判断规则（SOP 类、质检类）
  2. 可以用参考样本锚定特征（如本文的正常/异常对比图）
  3. 用户场景可以按业务分群（为多 Agent 扩展留空间）

实践价值：如果您面临类似的”规则化视觉判断”、”标准化流程自动化”等场景，希望减少人工重复劳动、降低新员工培训成本、建立可追溯的数字化记录，本文的OpenClaw + Bedrock 方案可以作为快速启动模板：

  • 快速上线：从零到能跑，CloudFormation + 一键脚本，1-2 天内完成 POC
  • 零 Node 运维：EKS Auto Mode 托管节点、存储、扩缩容、补丁更新
  • 成本可控：按 Pod 运行时间 + Bedrock Token 实际用量计费，闲时 Scale 到 0
  • 隐私合规：数据全程在VPC Endpoint 内闭环，不出AWS 账户
  • 业务自主迭代：规则变更只需改 SKILL.md，不依赖研发发版

随着大模型能力持续提升和企业 AI 落地场景不断扩展，基于Agent + Skill的轻量化领域知识注入模式，将成为垂直行业数字化转型的重要支撑。我们相信通过持续打磨Skill设计方法论和部署工程实践，能为更多制造、质检、巡检类场景提供高效、精准、可快速迭代的智能化解决方案。

➡️ 下一步行动：

相关产品：

相关文章：

7. 参考文档

  1. OpenClaw 官方文档
  2. Amazon Bedrock 用户指南
  3. Amazon EKS Auto Mode
  4. Claude on Bedrock
  5. OpenClaw Feishu Channel 文档
  6. Amazon EKS VPC Endpoint 配置
  7. Amazon EFS CSI Driver
  8. blog参考源码

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

田培军

亚马逊云科技解决方案架构师，加入亚马逊云科技前主要从事智慧城市、智慧教育系统架构设计和研发团队管理工作，拥有15年以上的研发设计和管理经验。在web开发、微服务架构设计、系统架构设计和集成等方向有丰富的实战经验。

亚马逊云科技中国峰会

开发者挑战赛现场开启，基于真实业务场景亲手构建 Agent。