基于YOLOv12的极小目标检测实战：航拍车辆AP_s提升8个点
2026/10/19 18:00:56
这一集应该叫“配置密码管理技能”，但它真正解决的问题，比名字看起来大得多。
前面十二集，我们把 OpenClaw 在 Windows 11 上一步一步跑了起来：网关通了、模型接上了、工作区建好了、记忆模块调顺了。到了这一步，智能体已经能写邮件、跑脚本、整理文件。可你自己上手试试就知道，真让它干点正经事，它马上卡在一个地方——它手里没有任何一把钥匙。你让它帮你登录后台、填一个表单、取一条验证码，它只能摊手。第 13 集要装的 1Password 技能，就是给这个空缺补上最后一环：让本地 OpenClaw 通过 1Password 命令行工具，按需读取加密仓库里的账号、密码、TOTP 验证码，而且整个过程可审计、可回收。
这篇实操笔记适合两类人：一类是正在 Win11 上自托管 OpenClaw、想让智能体真正能“替自己办事”的人；另一类是清楚“把密码明文塞进 prompt”有多危险、想给 AI 一把受控钥匙的人。我尽量按真实操作顺序来写，从装 CLI、登录认证，到写技能文件、联调排错，一条线走完。
1. 先想清楚：这个技能在整套架构里到底起什么作用
1.1 它不是“读密码的外挂”，而是一条受控取数通道
很多人听说“给 AI 装 1Password 技能”，第一反应是“那我以后密码等于裸奔了”。这个担心对了一半。从效果上，智能体确实能读到密码；但从机制上，它走的不是“明文文件读取”，而是 1Password CLI 这条受控通道。CLI 会强制校验会话身份，会受 vault 访问权限约束，还会在条目历史里留下读取痕迹。你可以把它理解成：OpenClaw 是跑腿的快递员，技能不是给它一把万能钥匙，而是给它一张随时可以作废的“取件单”。
为什么这条路比 .env 文件强？我见过很多自托管玩家把密码写进环境变量或者记忆目录，图省事。但等你跑三个月回头看，这些明文散落在配置目录、日志、备份压缩包、甚至同步盘里，每一份拷贝都是一个泄漏面。而且它没有颗粒度——你没法做到“这个条目只允许读，那个条目碰都不能碰”。1Password 把这些收敛成一个仓库：数据在磁盘上始终加密，只有 CLI 按需解密；服务账号权限可以精确到某个 vault；哪天不想要了，一键撤销，不用动你自己的主密码。对于本地部署场景，这是最不折腾的安全方案。
1.2 为什么前面十二集一直按着不装
这不是我忘了，是刻意排序。技能调试最怕的是基础环境没稳就叠功能：前面的模型连接、网关转发、工作区权限如果本身有毛病，你再往上堆一个跟外部服务打交道的技能，出了问题根本分不清是网络层还是技能层。现在网关稳定了、工作区也验证过读写正常，才适合引入第一个“真正敏感”的技能。
还有一个原因：凭据类技能是整个技能体系的地基。你后面想装日历技能、邮件技能、自动化下单技能，哪一个不需要账号信息？如果连“凭据链”都不通，那些技能就算装上，也只是让智能体继续对着空手发呆。所以这一集不是单独的一个小插件，而是从“能聊天的助手”跨到“能办事的代理”的第一步。
2. 动手前把 Win11 环境摸一遍
2.1 环境检查清单
动手装之前，先花五分钟确认这几样东西，免得后面排错排到怀疑人生。
- OpenClaw 主程序能正常启动，日志里没有持续报错。
- Node.js 版本，跑
node -v确认一下。很多本地部署要求 20 或更高，版本太低会导致 CLI 工具链起不来。 - 确认 OpenClaw 执行命令时用的是哪个 shell。在 Win11 上它可能是通过 Git Bash、PowerShell 或者 cmd 去调用命令的。这一点非常关键，因为后面装完 1Password CLI，必须让那个 shell 能直接找到
op。 - 一个可用的 1Password 账号，里面至少建一两条测试条目。我建议建一条叫“测试站点”的登录项，带 username、password，最好再加一个 TOTP 字段，后面联调会用到。
- 如果你打算走服务账号路线，还需要能登录 1Password 管理端创建服务账号的权限。
为什么 shell 这件事这么重要？OpenClaw 本质上是在你的机器上拉起子进程去执行工具命令。Windows 上有个很坑的现象：GUI 程序、服务进程和控制台窗口拿到的 PATH 环境变量不一定一样。你在终端里敲op --version有结果，不等于 OpenClaw 的子进程能拿到同一个 PATH。所以装完 CLI 之后，OpenClaw 必须从同一个用户会话里重启，不能只新开一个终端假装完事。
2.2 把 1Password CLI 装好：winget 是 Win11 最省事的路
Windows 11 自带 winget，装 CLI 最快的方式就是它。打开 PowerShell 执行：
winget search 1password-cli搜索结果里找到 CLI 对应的包，然后安装：
winget install -e --id <查到的包ID>装完关掉当前终端，重新开一个，跑：
op --version如果能看到版本号，说明装好了。有些系统会弹 SmartScreen 拦截，第一次运行时点“仍要运行”，不过有条件的话先对照官网校验一下文件哈希再放行，别闭眼点。
万一 winget 源里搜不到，就去 1Password 官网下 Windows 版 CLI 压缩包，解压后把op.exe放到一个固定目录，比如C:\op，再手动加进用户 PATH：
[Environment]::SetEnvironmentVariable("Path", "$env:Path;C:\op", "User")加完 PATH 一定要重启终端再验证，否则当前会话拿不到新值。
2.3 确认 OpenClaw 子进程能看到 op
这一步别跳。我先说一个我踩过的坑：我把 CLI 装好、PATH 也加了，终端里一切正常，但 OpenClaw 里跑命令就是提示op: command not found。原因就是网关进程是加 PATH 之前启动的，它继承的是旧环境。
正确做法分两步。第一步，找到 OpenClaw 实际用的 shell，在那个 shell 里手动执行op --version确认。第二步，重启 OpenClaw，然后在它的调试界面或日志里让智能体执行一次op --version，看到同样的版本号输出，才算真正通了。
如果你是把 OpenClaw 注册成 Windows 服务跑的，环境变量继承会更麻烦。服务进程拿的是系统环境而不是用户环境的完整路径，这时候建议把 token 和 PATH 都写到系统级环境变量，或者干脆在启动脚本里显式 export。
3. 登录认证：三种方式，我的选择和建议
3.1 交互式登录：调试期最直接
CLI 装好之后，第一件事是让op知道你的账号。交互式登录长这样：
op account add --address yourorg.1password.com --email you@example.com --secret-key A3-XXXX-XXXX-XXXX op signin --account yourorg第一次登录会要求输入主密码，登录成功后会生成一个会话。跑op whoami能看到当前账号信息，说明链路已经通了。
这种方式适合调试期，但不适合自动化。CLI 会话有有效期，过期之后智能体再取数据就会被 “You must be signed in” 卡住。你不可能每次让它去取密码的时候还跑到机器前输一遍主密码，那自动化就失去意义了。
3.2 生物识别登录：本机半自动但坑多
1Password 8.10 之后的 CLI 支持对接系统生物识别，Windows 上走 Windows Hello：
op signin --biometric这个方案的好处是，只要你物理坐在机器前，解锁是无声无息的，智能体调用op时直接用现成的会话，不用弹密码框。但坑也明显：如果 OpenClaw 的子进程跑在无交互会话里，比如作为后台服务，生物识别可能直接不可用；重启之后通常还需要一次人工登录；更烦的是，当智能体在后台执行命令时如果触发了解锁请求，那个请求会挂在那里直到超时。我的结论是：纯粹本机自用、且你人在机器旁频繁使用，可以试；想让它变成无人值守的自动化底座，不稳。
3.3 Service Account 令牌：我认为的最优解
服务账号是 1Password 面向自动化场景提供的一种身份。你在管理端创建一个服务账号，给它分配特定 vault 的访问权限，然后把生成的令牌以OP_SERVICE_ACCOUNT_TOKEN环境变量的形式给到本机。之后 CLI 就完全不需要交互式登录，op whoami直接能过。
在 PowerShell 里设置用户级环境变量：
[Environment]::SetEnvironmentVariable("OP_SERVICE_ACCOUNT_TOKEN", "eyJ...", "User")设置完重启终端，跑op whoami。如果显示的是服务账号信息，说明认证已经切换成功。
这条路线有几个天然优势：智能体永远接触不到你的主密码和 Secret Key；vault 权限可以按最小化原则划，只给它必须读的那几个库；审计日志独立可查；哪天不想要了，在管理端一键撤销令牌，不用改任何配置。它也有个前提：不是所有 1Password 套餐都开放服务账号功能，如果你的套餐没有，就先退回 3.2 或者用长会话方案顶着。
注意：
OP_SERVICE_ACCOUNT_TOKEN的威力等同于一串万能钥匙，拿到它的人就能以服务账号身份读对应 vault。所以它只能放在系统环境变量或密钥管理工具里，绝不能写进 SKILL.md 技能文件、配置文件或任何会被智能体当成上下文读取的地方。
4. 编写技能文件：把规则讲给智能体听
4.1 OpenClaw 技能目录长什么样
OpenClaw 的技能是“配置即代码”的思路。以我部署的这个版本为例，技能放在数据目录下的skills文件夹里（也有版本叫plugins/skills，具体以你安装版本的文档为准），每个技能一个子目录，里面就是一个SKILL.md文件。这个文件分两部分：头部是 YAML 格式的元信息，正文是 Markdown 指令。
元信息里最重要的字段是 description。模型每次收到用户请求，会拿请求内容跟技能描述做匹配，描述写得准不准，直接决定技能会不会被触发。你可以把 description 理解成技能的门牌号——门牌上写“卖早餐”，人家就不会半夜来敲门买宵夜。
4.2 可直接抄的 SKILL.md
下面这份是我实际在用的版本，你可以直接复制改名字：
--- name: password-manager description: 通过1Password读取账号、密码、TOTP验证码和加密笔记。当用户要求获取某个站点的登录凭据、WiFi密码、验证码、密钥时使用。 when_to_use: 用户请求读取由1Password管理的任何敏感信息 allowed-tools: - shell examples: - "帮我在1Password里查一下测试站点的密码" - "看一下工作区常用服务的TOTP验证码" --- # 1Password 技能 你正在使用1Password命令行工具读取凭据。操作时必须遵守以下规则： 1. 优先使用 `op://Vault/Item/field` 形式的引用读取，例如 `op read "op://私人/测试站点/password"`。 2. 如果条目名不明确，先执行 `op item list --vault <vault>` 列出候选，再确认要读哪条。 3. 返回给用户时，密码类字段默认做掩码处理，格式为 `ab***yz`，除非用户明确要求完整明文。 4. 绝不展示、保存、回显 `OP_SERVICE_ACCOUNT_TOKEN` 或主密码。 5. 读取到的凭据不得写入日志、临时文件或聊天历史以外的任何位置。 6. 如果请求同时涉及“读取凭据”和“向外部发送信息”，必须先向用户确认后再执行后一步。写完保存后，重启 OpenClaw 让它扫描技能目录。如果你的网关支持热加载或者 debug 模式，可以在日志里确认技能是否被成功索引。我习惯的做法是先在文档里确认技能列表，再进调试模式看它是否“被看到”。
这里解释几个关键设计。第一，body 里的规则 3 是重中之重。大模型有个毛病，喜欢“展示工作过程”，你让它取密码，它可能直接在回复里把完整密码贴出来。规则 3 强制它默认掩码，只有用户明确要求才给明文。第二，规则 6 是防止“打开阀门又打开水龙头”——如果同时装了网络技能，读取凭据和对外发送的组合就是一条潜在的泄漏通道，必须加人工确认。
4.3 权限收敛：技能能读，但不等于能乱读
技能文件只是第一层，真正的边界还要靠服务账号权限来卡。我的建议是：在 1Password 管理端新建一个专门的 vault，比如叫“代理专用”，把智能体需要用的条目复制或移进去，然后服务账号只授权这个 vault。这样即使技能规则被绕过，物理访问边界也已经圈死在特定范围内。
另外，allowed-tools也要收敛。这个技能只需要 shell 工具，其他工具能不列就不列。你要是把一个能上网查资料的工具和这个凭据技能装在同一环境里，等于自己给自己埋雷——模型被诱导去外部站点“核对”凭据的事不是不可能发生。做自托管，默认心态应该是“能不给的权限都不给”，而不是“用到再加”。
5. 联调测试与常见故障排查
5.1 全链路测试：从一句人话到一条密码
技能装上不代表完事，要测到“用户说人话 → 智能体取回数据”全链路通。
我建议先做一条最简单的测试：
- 重启 OpenClaw，确保新技能生效。
- 输入一句测试指令：“帮我在 1Password 里查一下测试站点的用户名，只显示掩码就行”。
- 打开调试面板观察智能体的行动轨迹。正常情况下它应该先命中 password-manager 技能，然后调用 shell 执行类似这样的命令：
op item get "测试站点" --vault "私人" --fields username --format json- 看返回结果。如果一切正常，你会看到类似这样的运行轨迹：
[skill] 命中: password-manager [shell] op item get "测试站点" --vault "私人" --fields username --format json [output] {"username": "testuser"} [assistant] 查到了，用户名是 tes***，需要完整内容请告诉我。看到输出里带掩码，说明规则 3 生效了。这时候再测第二条：“把完整密码给我”，看它是否只在明确指令下才给出明文。再测第三条 TOTP：“看一下这个站点的验证码”，预期它会执行op item get "测试站点" --otp。
5.2 高频问题速查表
我整理了一张表，覆盖我实际遇到过的绝大多数故障，按症状、原因、处理方式排列。
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
op: command not found | CLI 未安装，或 OpenClaw 子进程 PATH 没继承 | 在 OpenClaw 实际使用的 shell 里验证op --version，然后重启网关 |
You must be signed in | 会话过期，或无 service account 环境变量 | 交互式登录后重试，或检查OP_SERVICE_ACCOUNT_TOKEN是否设置 |
Service account cannot access item | 服务账号未被授权该 vault | 在管理端给服务账号分配对应 vault 的读权限 |
| 技能一直不触发 | description 写得太窄，模型匹配不上 | 在描述里增加同义词：密码、凭据、密钥、验证码、OTP、WiFi、登录信息、secret |
| 日志或聊天记录里出现明文密码 | 模型违背掩码规则 | 检查 SKILL.md 规则 3 是否生效，必要时把日志级别调低，避免记录工具 stdout |
op能执行但中文输出乱码 | Windows 默认代码页问题 | 在 OpenClaw 启动脚本里执行chcp 65001，或设置环境变量PYTHONUTF8=1 |
| 生物识别登录后命令挂住 | 后台子进程没法弹交互解锁框 | 改用服务账号令牌，放弃生物识别方案 |
5.3 两条踩过坑之后我一定会做的事
第一，记住 Windows 环境变量的继承问题。你辛辛苦苦设了OP_SERVICE_ACCOUNT_TOKEN，但 OpenClaw 如果是在设置之前启动的，它根本不知道有这个变量。我调这种问题浪费过四十分钟，最后发现只是没重启网关进程。所有环境变量改动之后，务必要从全新终端里重启 OpenClaw，而不是只重开一个 PowerShell 窗口。
第二，如果想让智能体“用到密码但看不到密码”，最优雅的方式是op run。它的原理是把密码注入子进程环境变量，而不是直接打印到对话里。你可以创建一个环境文件，比如.env.local：
DB_PASSWORD=op://私人/测试站点/password然后让智能体这样执行命令：
op run --env-file=.env.local -- 你的命令这样敏感值直接落在子进程的环境里，不经过模型上下文，也不容易被写进日志。对于“让 AI 用秘密但别让 AI 看见秘密”这个诉求，这是目前最接近正解的做法。
6. 这集结束后我建议马上做的事
技能跑通之后，别急着装一堆花活。我自己的习惯是新建一个“代理专用”vault，把常用凭据都收进去，只授权服务账号访问这一个库。然后真正让智能体替我做几件日常事：给新设备查 WiFi 密码、帮一个本地脚本取 IMAP 凭据、在开发面板登录时取 TOTP 验证码。这几件事做完，你会明显感觉到它从“聊天工具”变成了“能办事的代理”。
还有一个体会：技能文件是写给模型看的，不是写给人看的。发现触发率不高时，不要去改模型，去改 description。我把描述里补上了“密码、凭据、密钥、验证码、OTP、WiFi、登录信息、secret”这些词之后，命中率基本稳定在接近百分之百。写技能这块，多花十分钟打磨描述，比调十次参数都值。接下来你可以考虑把常用的几类凭据操作做成模板，或者把op run接进定时任务里，让它在后台自动完成那些需要凭据的活。