从 Prompt Engineering 到 Harness Engineering：一个运维的 AI 驾驭实践
这是「AI运维实验室」的第四篇文章。前三篇讲了 Meetup 见闻、OpenClaw 企业部署和 Redis 巡检实战，这一篇聊聊方法论——怎么驾驭多个 AI 工具协同工作。
Prompt Engineering 已经不够了
2024 年，大家都在学怎么写 Prompt。写好一个提示词，AI 就能给你一个好答案。
2026 年，情况变了。我每天要用的不是一个 AI，而是多个：一个帮我分析问题，一个帮我写代码，一个帮我生成文档，一个帮我跟同事沟通。光会写 Prompt 不够了，你得学会驾驭它们。
在养虾社北京 Meetup 上，OPC 创始人王晓妍老师提出了一个概念：Harness Engineering——驾驭工程。
这个词精准地描述了我每天在做的事。
什么是 Harness Engineering
Prompt Engineering Harness Engineering
━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━
写好一个提示词 驾驭多个 AI 协同工作
关注单次对话质量 关注整体工作流效率
一个 AI 一个任务 多个 AI 各司其职
人在操作 人在决策
核心区别：
Prompt Engineering = 怎么跟 AI 说话
Harness Engineering = 怎么让 AI 替你干活
打个比方：Prompt Engineering 是学会骑一匹马，Harness Engineering 是驾驭一支马队——每匹马跑不同的路线，你负责规划路线、分配任务、验收结果。
我的 Harness 架构
我不会编程，但我同时驾驭着多个 AI 工具：
┌─────────────────────────────────────────────────────┐
│ 我（决策层） │
│ │
│ 判断该不该做 → 选择用哪个工具 → 验收结果 │
└──────────┬──────────────────┬───────────────────────┘
│ │
┌─────▼─────┐ ┌────▼──────┐
│ Kiro CLI │ │ OpenClaw │
│ (执行层) │ │ (交互层) │
├───────────┤ ├──────────┤
│• 问题分析 │ │• 飞书对话 │
│• 代码生成 │ │• 日常助手 │
│• 文档生成 │ │• 信息查询 │
│• 系统操作 │ │• 方案讨论 │
│• 安全巡检 │ │ │
└─────┬─────┘ └────┬──────┘
│ │
┌─────▼──────────────────▼──────┐
│ 输出层 │
│ │
│ Wiki 文档 │ 知识库 │ 报告 │
└────────────────────────────────┘
两个 AI 的分工很明确：
- Kiro：重活。分析告警、排查故障、生成运维文档、执行系统命令
- OpenClaw：轻活。日常沟通、方案讨论、信息查询
不是哪个更强的问题，是各自擅长的场景不同。
一个真实的工作流
以一次 Redis 巡检为例，看看 Harness Engineering 在实际工作中是怎么运转的：
09:00 收到告警：Redis 内存使用率 85%
│
▼
09:01 【决策】需要做一次全面巡检，用 Kiro
│
▼
09:02 【Kiro 执行】
│ ├── 连接 Redis 集群
│ ├── 扫描大 Key（SCAN + MEMORY USAGE）
│ ├── 分析内存分布
│ ├── 生成 Top 20 大 Key 报告
│ └── 输出巡检文档（Markdown）
│
▼
09:08 【我验收】
│ ├── 检查报告是否合理
│ ├── 确认大 Key 归属哪个业务
│ └── 判断是否需要清理
│
▼
09:10 【Kiro 执行】生成 Wiki 格式文档
│
▼
09:12 【上传 Wiki】团队可查阅
│
▼
09:13 【OpenClaw】在钉钉群通知相关研发
│
▼
完成。从告警到处置，13 分钟。
整个过程中，我做了三件事：决策、验收、判断。AI 做了剩下所有的事。
这就是 Harness Engineering 的核心：人负责方向，AI 负责执行。
驾驭的关键不是技术，是判断力
很多人以为驾驭 AI 需要很强的技术能力。不是的。
驾驭 AI 需要的不是编程能力，而是判断力：
1. 知道该做什么
收到一个告警，我知道该查什么、查到什么程度、结果意味着什么。这是 10 年运维经验给的，AI 给不了。
2. 知道该用哪个工具
分析问题用 Kiro（需要执行命令），通知同事用 OpenClaw（需要发消息）。选错工具，效率减半。
3. 知道结果对不对
AI 生成的报告不一定 100% 准确。我能看出来哪些数据合理、哪些有问题，因为我见过太多真实的故障场景。
AI 的能力边界：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AI 能做的 AI 做不了的
───────── ──────────
执行命令 判断该不该执行
生成报告 判断报告对不对
写代码 判断代码该不该上线
分析数据 判断数据意味着什么
给出方案 判断方案适不适合当前场景
→ AI 是手脚，你是大脑
从 Human in the Loop 到 Human on the Loop
王晓妍老师在 Meetup 上还提到了一个管理进化路径：
阶段一：Human in the Loop（人在环中）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AI 每一步都要人确认
"AI 帮我查一下" → 确认 → "再帮我分析" → 确认 → ...
效率：低
▼
阶段二：Human on the Loop（人在环上） ← 我现在在这里
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AI 自主执行，人监督和验收
"帮我做一次 Redis 巡检" → AI 自动完成 → 我验收结果
效率：高
▼
阶段三：Human out of Loop（人在环外）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AI 完全自主，人只定目标
每天自动巡检 → 自动生成报告 → 自动发布
效率：最高
我现在大部分工作处于第二阶段：给 AI 一个任务，它自主完成，我验收结果。少部分已经到了第三阶段——比如每天定时自动生成运维报告并发布，我只需要偶尔检查一下。
给想入门的人的建议
如果你也想从 Prompt Engineering 进阶到 Harness Engineering：
1. 先跑通一个完整的工作流
不要一上来就搞多个 AI 协作。先用一个工具，把一个场景从头到尾跑通。我最开始就是用 Kiro 做告警分析，跑通了再加 OpenClaw。
2. 让 AI 做重复的事，你做判断的事
把你每天重复做的事情列出来，挑一个交给 AI。你的时间应该花在判断和决策上，不是执行上。
3. 不要追求完美，追求可用
AI 生成的东西不会 100% 完美，但 80% 可用就够了。剩下 20% 你花 2 分钟修改，比你自己从头做快 10 倍。
4. 建立自己的知识库
每次 AI 帮你完成一个任务，把结果存下来。我两个多月积累了 200 多篇运维文档，这些就是我的知识库，也是 AI 下次工作的参考。
一个运维的视角
Harness Engineering 这个概念听起来很新，但本质上运维一直在做类似的事——我们驾驭的不是 AI，是各种工具和系统。以前是 Ansible、Terraform、Jenkins，现在多了 Kiro 和 OpenClaw。
工具变了，思维方式没变：选对工具、分配任务、验收结果。
唯一的区别是，以前的工具只能做你明确告诉它的事，现在的 AI 工具能理解你的意图，自主完成任务。这让运维的杠杆效应放大了很多倍——一个人，驾驭多个 AI，干以前一个团队的活。
2026 年最重要的技能不是写代码，是 Harness Engineering。
关于这个公众号
「AI运维实验室」持续分享 AI 工具在企业中的真实落地经验。不是概念，是踩过的坑和跑通的路。
往期文章：
- [一个运维去了养虾社北京 Meetup，聊聊我看到的 OpenClaw 生态]
- [把 OpenClaw 搬进公司：一个运维的企业级部署实战]
- [用 OpenClaw 做 AWS Redis 巡检：从告警到报告的全自动化]
写于 2026 年 3 月，驾驭 AI 的第三个月。
