子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）

大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

很多人第一次跑通 OpenClaw，都会有一种“已经可以用了”的错觉：

• 工具能调用
• 任务能执行
• 效果还不错

于是下一步自然就是：

把它接到真实环境里试一试

但问题往往就出在这里：

默认配置，几乎从来不是“安全配置”。

甚至可以更直白地说：

默认配置的目标是“让你跑起来”，而不是“让你安全运行”。

默认配置的本质：偏向“可用性”，而不是“安全性”

任何一个开源 Agent 系统（包括 OpenClaw），在设计默认配置时，都会优先考虑一件事：

降低上手门槛

这意味着：

• 权限默认放开
• 工具默认可用
• 限制尽可能少

否则用户第一步就跑不起来，但这也带来一个隐含前提：

默认配置 ≠ 生产可用配置

短板一：工具权限“默认信任”

最常见的一个问题是：

工具一旦注册，就默认可以被调用

例如：

{
  "tools": [
    "file_system",
    "browser",
    "shell"
  ]
}

看起来只是“能力列表”，但实际上等价于：

• 可读写本地文件
• 可访问外部网站
• 可执行系统命令

这已经接近“本地操作系统权限”

风险在哪里？

模型并不会理解：

• 哪些目录是敏感的
• 哪些操作是危险的

于是可能出现：

• 删除重要文件
• 读取配置文件
• 执行危险命令

正确思路：默认拒绝，而不是默认允许

allowedTools = ["read_only_notes"];

逐步开放：

• 先只读
• 再有限写
• 最后高权限

权限必须是“加法”，而不是“减法”

短板二：参数缺乏边界控制

很多工具在默认实现中，只校验“参数格式”，不校验“参数范围”。

例如：

{
  "action": "read_file",
  "path": "/"
}

如果没有限制：等价于读取整个文件系统

更隐蔽的问题

即使你限制了路径：

"/user/data/"

但如果允许：

• 递归读取
• 大文件读取
• 批量操作

依然可能：

一次请求拖垮系统，或泄露大量数据

正确思路：参数必须“可控 + 可预测”

if (!path.startsWith("/safe_dir/")) {
  throw Exception("Forbidden");
}

if (fileSize > 1MB) {
  throw Exception("Too large");
}

参数控制，本质是“限制影响范围”

短板三：缺乏执行边界

默认配置中，很多 Agent 是这样运行的：

while (!taskDone) {
  think();
  act();
}

看起来合理，但问题是：

没有“停止条件”

可能出现：

• 无限循环调用工具
• 在错误路径上不断重试
• Token 消耗爆炸

真实后果

• 成本失控
• 服务阻塞
• 系统资源耗尽

正确思路：强制加“刹车”

maxSteps = 8;
timeout = 20s;
maxTokens = 3000;

Agent 可以失败，但不能“无限尝试”

短板四：上下文无隔离

默认情况下，Agent 往往会：

把所有上下文拼在一起喂给模型

包括：

• 用户输入
• 历史对话
• 工具返回

问题在于：

这些数据的“敏感级别”是不一样的

风险场景

• A 用户的数据被带入 B 用户上下文
• 内部信息被模型“意外引用”
• 敏感字段被拼进 Prompt

本质是：

上下文没有边界

正确思路：上下文分层

例如：

context = {
  "user_input": ...,
  "safe_memory": ...,
  "restricted_data": filtered(...)
}

敏感信息：

• 不进入模型
• 或只提供摘要

模型看到的，不应该是“全部数据”

短板五：缺乏审计与回溯能力

默认运行时，很多系统只输出：

Task completed successfully

但当出问题时：

你根本不知道发生了什么

关键缺失

• 没有工具调用记录
• 没有决策过程
• 没有参数日志

这会导致：

问题无法复现，更无法追责

正确思路：构建“可审计链路”

至少要记录：

{
  "thought": "...",
  "action": "delete_file",
  "params": {...},
  "result": "success"
}

Agent 系统必须“可追溯”，否则不可上线

短板六：默认没有“人类兜底机制”

默认配置通常是：

Agent 自动执行一切

但现实中，有一类操作必须谨慎：

• 删除
• 支付
• 外部调用

风险本质

模型可能“合理地做错事”

例如：

“清理无用文件” → 删除了用户重要数据

正确思路：关键操作必须“人工确认”

if (isHighRisk(action)) {
  requireHumanApproval();
}

自动化 ≠ 无人监管

一个关键认知：默认配置，是“最危险的起点”

回头看这些问题，会发现一个共同点：

默认配置假设环境是“安全的”，但现实不是

默认配置适用于：

• Demo
• 学习
• 本地测试

但一旦进入：

• 真实用户
• 真实数据
• 真实系统

风险会被指数级放大

总结

OpenClaw 的默认配置，最大的问题不在于“做错了什么”，而在于：

它默认你不会在生产环境直接使用它

但现实往往是：

很多人就是这么做的

其核心安全短板可以总结为：

• 工具权限默认放开
• 参数缺乏边界控制
• 执行没有限制
• 上下文没有隔离
• 缺乏审计能力
• 没有人类兜底

最终可以用一句话总结：

在 Agent 系统中，默认配置不是“起点”，
而是你必须尽快摆脱的“危险状态”。