夜雨聆风
成本高到离谱，安全形同虚设，它为什么还敢说自己是“AI Agent”？
在讨论 OpenClaw 之前，我们需要先搞清楚一个容易混淆的概念。
很多人把 OpenClaw 这类项目叫做“AI Agent”，但更准确地说，它是一个Harness（智能体脚手架），而不是 Agent 本身。它们的关系是：
AI Agent = 大模型（Model） + 脚手架（Harness）
大模型负责“思考”——理解指令、做出决策、生成文本。
脚手架负责“环境”——管理工具、路由消息、维护会话、执行命令。
OpenClaw 就是后者：一个纯粹的脚手架。它本身不含任何 AI 能力，而是把外部大模型（Claude、GPT 等）“套”进自己搭建的运行环境里，让 AI 能够接入 WhatsApp、Telegram 等消息渠道，并调用 Bash、浏览器等系统工具。
围绕这个“脚手架”的工程实践，业界正在形成一个新兴领域——Harness Engineering（智能体脚手架工程）。
Harness Engineering（智能体脚手架工程）是指“塑造 AI 智能体周围环境，以确保它们能够可靠工作”的工程实践。
它位于多个领域的交叉点：
| 领域 | 在脚手架中的体现 |
|---|---|
| 上下文工程（Context Engineering） | 如何构建、裁剪、缓存发送给大模型的提示词 |
| 系统评估（Evaluation） | 如何判断 Agent 的输出是否正确、任务是否完成 |
| 可观测性（Observability） | 如何追踪每一轮对话、每次工具调用的中间状态 |
| 流程编排（Orchestration） | 如何自动规划多步骤任务的执行顺序 |
| 安全自治（Safe Autonomy） | 如何在授予 AI 系统权限的同时防止它搞破坏 |
| 软件架构（Software Architecture） | 如何设计可扩展、可维护的运行时框架 |
它的核心目标不是训练或微调底层模型，而是通过构建强大的外围环境，解决模型在实际工作流中容易出现的 “上下文丢失”、“产生幻觉”、“陷入死循环” 等可靠性问题。
理解了这个背景，我们就可以用 Harness Engineering 的视角，来审视 OpenClaw 这个脚手架的设计缺陷了。
在成熟的脚手架中，技能应该被编程化地注入上下文——系统根据任务类型自动挂载对应的执行逻辑和精简的上下文片段。但 OpenClaw 在上下文工程上只做了最基础的一步。
它把每个技能写成一个普通的 Markdown 文档（SKILL.md）。当用户发来任务时，系统会在提示词里告诉 AI 有哪些技能可用，然后附上一条指令（源码 system-prompt.ts）：
“如果恰好有一个技能明确适用：用 read 工具读取它的 SKILL.md，然后照着做。”
AI 每次接到新任务，都要先“翻说明书”学一遍，然后才能开始干活。 就像你雇了一个工人，他每天上班第一件事是从头到尾把《操作手册》读一遍，才知道怎么用扳手。
这种设计缺陷在实际使用中已经导致了大量“低效翻车”。 据阿里云开发者社区一位开发者的分享，他在使用 OpenClaw 进行自动化任务处理时，发现 AI 在处理复杂项目时出现了“严重的上下文断裂”，开始生成“虚拟的抽象框架代码”——明明双方刚刚共同确认了文件树结构，AI 却转头将其视为外部既成事实，完全丢失了刚刚达成的共识。这位开发者最终被迫总结出一套“长程项目交互生存指南”，核心原则是：永远不要假设模型记得半小时前达成的共识，必须“不厌其烦地提供上下文”。
OpenClaw 确实有 sessions_spawn（子代理委派）这样的多代理协作雏形，但整体编排仍高度依赖大模型自己的“随机应变”，而非确定性的流程引擎。每一步是否正确、会不会跑偏，完全取决于 AI 那一刻的“脑回路”。这正是 Harness Engineering 里流程编排（Orchestration）维度的明显缺失。
在 Harness Engineering 中，安全自治（Safe Autonomy） 是最关键的一环——如何在赋予 AI 行动能力的同时，防止它造成不可逆的损害？OpenClaw 在这方面做了一些基本功，但远远不够。
❌ 沙箱默认关闭
OpenClaw 的安全哲学叫做 “受信任操作者模型”（Trusted Operator Model）。代码里明确写着（SECURITY.md）：
agents.defaults.sandbox.mode 默认值为 off。
这意味着 AI 调用命令行工具（如 Bash）时，默认拥有和你本人一样的系统权限——它能读写你的文件、安装软件、执行任意命令。
这种“裸奔”权限已经在真实场景中酿成事故。据报道，一位 AI 算法工程师周先生本想用 OpenClaw 帮女友自动整理发票，在提示词中输入“整理桌面的发票照片，按月份分类”，女友补充了一句“格式不对的删掉”。几分钟后，电脑桌面上整个发票文件夹被清空——好在提前做了备份。周先生事后分析认为，核心原因是工具的权限过高，可对所有文件进行读写删除操作，且涉及大量删除操作时未设置用户确认环节。
类似的“数据浩劫”并不少见。朋友圈里就有一位被龙虾背刺了，丢失了一百G的视频。
✅ 有一层审批弹窗，但不是安全边界
公平地说，OpenClaw 有 exec approvals（执行审批） 机制——AI 要执行某些命令时，系统可以弹出确认界面。但 OpenClaw 在安全文档里坦率承认：
“执行审批是操作者级别的安全护栏（guardrails），不是多租户的授权边界。”
翻译成大白话：这只是一个“你确定要这样做吗？”的弹窗，不是一堵真正的防火墙。 在自动化场景或跳过确认的情况下，AI 可以直接操作文件系统。
⚡ 超长提示词 × 弱沙箱 = 幻觉陷阱
OpenClaw 把所有的规则、工具列表、技能描述、安全注意事项全塞进系统提示词里。系统甚至内置了 /context detail 命令来查看提示词有多长——因为它确实太长了。
大模型的一个已知弱点是：上下文越长，注意力越容易“分散”，越容易产生幻觉。当提示词膨胀到数千甚至上万 token 时，AI 对关键指令的遵循程度会明显下降。在没有强沙箱兜底的情况下，如果 AI 因为“走神”而曲解了命令，后果可能是灾难性的。
最典型的案例来自 Meta 内部。 据中国指挥与控制学会报道，Meta AI 安全与对齐负责人 Summer Yue 授权 OpenClaw 整理邮件，明确下达指令：“分析我的收件箱并建议可以删除的邮件，但在我批准前严禁执行。”结果 AI 因邮件太多、信息量过载触发了所谓的“上下文压缩”，直接无视“批准前严禁执行”的指令，开始疯狂删除重要邮件，任凭 Summer Yue 连下三条“停止”指令也无济于事。
更严重的是，这种安全风险已经引发国家级预警。 2026 年 3 月，国家网络与信息安全信息通报中心发布通报指出，OpenClaw 在架构设计、默认配置、漏洞管理、插件生态、行为管控等方面存在较大安全风险。通报特别提到：OpenClaw 默认绑定 0.0.0.0:18789 地址并允许所有外部 IP 访问，远程访问无需账号认证，公网暴露比例高达 85%；历史披露漏洞多达 258 个，其中超危漏洞 12 个、高危漏洞 21 个。
有专家更是一针见血地指出：OpenClaw“具有自主决策和调用系统资源等高权限特点，加之系统信任边界模糊，且技能包市场目前缺乏严格的安全审核，内部潜藏着诸多隐患”，即使更新到最新版本，“也并不意味着安全风险被彻底消除”。
这是 OpenClaw 作为脚手架最直观的痛点——Token 消耗惊人。
原因一：单步循环，走一步看一步
OpenClaw 的核心执行引擎是标准的 ReAct 循环（Tool Calling Loop）：AI 每一步只做一个决策、调用一个工具，看到结果后再决定下一步，直到没有更多工具需要调用：
| 轮次 | AI 动作 | 工具调用 |
|---|---|---|
| 第 1 轮 | 分析需求 | read读取参考文件 |
| 第 2 轮 | 规划方案 | bash创建目录 |
| 第 3 轮 | 编写代码 | write写入文件 |
| 第 4 轮 | 检查结果 | read验证文件 |
| 第 5 轮 | 汇报完成 | （无工具调用，循环结束） |
一个简单任务就要 5 轮。复杂任务 10–20 轮甚至更多。
原因二：每一轮都要“背一遍课本”
大模型是无状态的——没有持久记忆。每一轮都要把完整的系统提示词重新发送，包括：
基础人设和行为规则
所有可用工具的 JSON Schema 定义
所有已加载技能的描述和路径
项目上下文文件内容（AGENTS.md、SOUL.md、TOOLS.md）
所有历史对话记录
打个比方：指挥工人砌墙，他每搬一块砖，你都要把整本《施工手册》从头念一遍给他听。5000 字的手册 × 10 块砖 = 念 5 万字，其中 4.5 万字是完全重复的。
Token 消耗是 N 轮 × 系统提示词长度 的线性倍增。当系统提示词本身就很庞大（工具定义 + 技能列表 + 多个文件内容），这个倍乘效应就非常可怕了。
这种“Token 燃烧器”效应已经在用户中引发账单恐慌。有深圳程序员分享经历：“安装 OpenClaw 第三天，凌晨收到账单——API 密钥被盗，3 天消耗了 1.2 万元 Token 费用。”另一位大数据工程师一个晚上用 OpenClaw 闲聊了几句和查了下数据，100 万 Token 就没了还欠费了，“如果不是邮件提醒我就要破产了。”
猎豹移动 CEO 傅盛也公开了他的“养虾”账单：他养的高配版“龙虾”在高频调度下，每天成本约 1000 多元，一个月下来接近 3 万元。他在 14 天里发了 1157 条消息、22 万字对话。有海外重度用户月度 Token 消耗达 1.8 亿，预估月成本约 3600 美元。
甚至有人实测，执行一次复杂的程序调试任务，一天就能烧掉 10 亿个 Token，成本达数万元。市场流传着“月薪两万，养不起一只龙虾”的说法——对于绝大多数日常工作量不饱和的用户而言，这种“养殖”持续性开支，已远超其能带来的效益。
OpenClaw 有 compaction（上下文压缩）机制和 /compact 命令来压缩历史对话。但这只能压缩对话部分，系统提示词本身每轮必须完整发送，这个根本问题无法通过压缩解决。
成熟的脚手架正在探索Prompt Caching（提示词缓存）和增量上下文更新等技术来解决这个问题，但 OpenClaw 目前还没有在架构层面实现这些优化。
| Harness Engineering 维度 | OpenClaw 现状 | 成熟脚手架的做法 |
|---|---|---|
| 上下文工程 | 全靠 AI 运行时读 .md 文件，已出现“上下文断裂”生成虚拟框架代码的案例 | 编程化技能注入 + Prompt Caching |
| 流程编排 | 无确定性流程引擎，靠 AI 随机应变 | DAG / 状态机 / 多代理协同调度 |
| 安全自治 | 沙箱默认关闭，仅有审批弹窗，已出现误删文件夹、Meta 高管邮件被删等失控事件 | 多层沙箱 + 权限最小化 + 强制隔离 |
| 可观测性 | 基础日志 + /context 命令 | 全链路 Trace + 中间状态快照 |
| 系统评估 | 基本无内建评估机制 | 自动回归测试 + 输出校验管线 |
| 软件架构 | 单体 TypeScript 项目，近期升级“翻车”导致大量插件瘫痪 | 模块化插件 + 分层运行时 |
OpenClaw 的价值在于：它率先打通了让 AI 接触真实系统的渠道，并且生态铺得很广（20+ 消息渠道、跨平台客户端）。 但从 Harness Engineering 的视角看，它在六个核心维度中的大多数都只做了最基本的实现。它更像是一个 “最小可用脚手架”（Minimum Viable Harness），而不是一个生产级的智能体运行环境。
这也恰恰说明了 Harness Engineering 的难度——搭一个能跑的脚手架不难，搭一个可靠、安全、经济的脚手架，才是真正的工程挑战。
