夜雨聆风Cursor Agent把我的D盘删光之后，我用两周时间系统性地设计并搭建了一套 AI Agent 执行护栏——四个工作模式、四层防护机制、一套最小可行安全架构。本文是给正在 Vibe Coding 的一人公司的完整框架参考。
一条命令Agent执行了 9 秒，D 盘全部内容消失。上一篇写了那次事故的完整经过Cursor+Sonnet一起把我的D盘删了。
这篇讲下，痛定思痛，我如何结合自己的 OPC 业务场景，给 AI 搭建了一套安全护栏。
如果你也在做 OPC，这套 Harness 安全护栏模板可以拿走直接套用。
一、OPC 用 AI，就像給马车上了涡轮增压
一人公司（OPC）用 AI Agent，和大公司用，风险结构完全不同——不是程度差异，是有没有兜底机制的结构差异。
大公司有 IT 部门、有审计流程、有多人 Review、有备份 SLA。一个 Agent 搞砸了，有人兜底。
OPC 没有。
你一个人同时是开发者、运维者、系统管理员、数据负责人。 Agent 出了问题，没有人在你的工作上面再加一层检查。
更关键的是：涡轮增压意味着什么——同排量榨出更大马力。 进气加压之后，少量燃油也能烧出更大的劲。AI Agent 同理：它让你在同一个肉身和时间预算里，输出逼近一个小团队；管道一旦漏气或爆震，灾难抵达的速度也比徒手操作快得多。
我的事故就是这样：一条命令、9 秒、整盘内容消失。Agent 的执行速度比任何人工敲命令都快；没有护栏时，涡轮增压只是在放大失控。
那时候我纯跑在 Windows 上，Cursor 直接在 Windows 环境里执行命令。Windows 本身没有多用户权限隔离、没有文件不可变属性——出了事，操作系统这层根本拦不住越权的命令。
喆哥的判断：对 OPC 来说，引入 AI Agent 而不配套安全架构，等价于给自己的发动机装上涡轮却没有油路保护和泄压阀——马力上来了，爆缸也会更快。效率是真的，9 秒删光 D 盘也是真的。
二、我的 OPC 业务场景
在讲护栏设计之前，先把我的业务背景交代清楚。同一套护栏，不同的业务场景，风险的优先级截然不同。
我做的是一家 AI-native 的一人培训咨询公司。 通过个人 IP 获客，面向企业提供两类服务：SDD（规格驱动开发）研发转型，以及 AI-native 产品转型咨询。
整个业务模型按三个层次运转：
获客层：公众号深度文章 + 短视频 + 微信社群，个人 IP 驱动，不做广告投放。读者认同我的方法论，自然成为潜在客户。
产品漏斗：从免费引流课开始，逐步进入线上系统课、线下工作坊、企业内训和长期咨询陪跑，同一套方法论按深度分层变现。
工具底座：Obsidian 知识库 + MCP 服务编排 + Claude / Cursor + SDD 规格驱动——公司本身就是我在教的方法论的实际运行实例，我不只是在讲 SDD，我自己就是用 SDD 构建的 AI-native 企业。
这个业务结构决定了我同时在操作的东西非常多：知识库、代码仓库、客户内容、云凭证、第三方 API——全在一台机器上，全在同一个 Windows 用户权限范围内，没有任何隔离。
一旦 Agent 越权，没有任何公司级流程帮我拦截。这不是夸张，是结构性事实。这也是为什么护栏要系统性地装，而不是"感觉不会出事"就算了。
三、四类工作场景，四类风险
事故之后我做的第一件事，不是马上动手装护栏，而是把自己的工作场景梳理清楚。
不同的场景，Agent 能造成的伤害完全不同。搞清楚这个，护栏才能装在对的地方。
我把日常工作分成四类：
T0 护栏维护：改安全规则本身。这是最危险的场景——Agent 有可能趁机删掉约束自己的规则。
T1 编程开发：日常写代码、改配置、装依赖。频率最高，误删文件、读取凭证、供应链攻击，风险都在这里。
T2 知识加工：抓文章、整理知识库、调用 AI API 处理内容。操作的是知识库而不是代码，但一旦越权写入，破坏同样严重。
T3 日常办公：没有 Agent 参与，人工操作。风险最低，但自动备份仍是必要的兜底。
每个场景的核心风险是什么？
这个场景矩阵是整套 Harness 工程的设计起点。 先有场景，再有风险，再有对应的护栏机制。
把它放回系统架构里看：T1/T2 的 Agent 在 agent-user 域运行，凭证和 Vault 在 mount 用户域——这是 Harness 工程建立的双用户隔离结构，不是原有的 Windows 环境。为什么选 WSL2 而不是纯 Windows 来做这件事，在下一节权限层里解释。
场景分析完了，护栏就有了设计依据：每个场景面对的风险不同，对应的控制手段也不同——这也是为什么护栏要分层设计，而不是一套规则通吃所有场景。
四、四层防护架构
把场景和风险梳理清楚之后，护栏设计就有了方向。我把整套 Harness 工程分成四层，每层对应一类控制手段：
第一层：规则层（声明性约束）
这是 Agent 最先看到的约束——写在 .cursor/rules/safety.mdc 和 CLAUDE.md 里的行为规则。
规则层的作用是声明意图：告诉 Agent 什么能做、什么不能做。比如：
含中文字符的路径，执行删除前必须先打印完整解析路径 git push前必须显示最近 5 条 commit 摘要，等待人工确认npm install必须附加--ignore-scripts参数禁止读取 ~/.aws、~/.gcloud、~/.credentials/目录
规则层有一个根本局限：它是软约束，是建议，不是物理屏障。
我在上一篇提到的 Replit 事故，用户明确告诉 Agent "不要动生产数据库"，Agent 还是动了。规则层拦不住一个"决定要动"的 Agent。
所以规则层的定位是：第一道警示，不是最后一道防线。
第二层：Hook 拦截层（程序化阻断）
规则层是文字声明，Hook 层是可执行代码。两者的本质区别在于：规则可以被 AI 无视，Hook 的拦截逻辑会真的运行。
Claude Code 提供了 Hook 机制——在工具调用前（PreToolUse 事件）触发 Shell 脚本。如果脚本退出码为 2，工具调用被物理阻断，AI 无法绕过。
我在 .claude/settings.json 里配置了 network-guard.sh，它会在 Agent 执行以下命令时强制暂停并要求人工确认：
curl/wget（外部内容下载）npm install/pip install（依赖安装）任何含 --ignore-scripts=false的 npm 调用
这和规则层写"npm install 必须加 --ignore-scripts"有什么区别？ 规则层靠 AI 自觉遵守；Hook 层是 AI 没得选——脚本直接卡住，不等到人确认就不放行。
Cursor 侧有类似的机制：终端命令执行默认开启人工审批模式，Agent 写出来的命令需要你主动点"Run"才会跑。这个审批模式不依赖 Cursor Rules，是工具本身的安全设计。
喆哥的判断：规则层告诉 AI 该怎么做，Hook 层确保它真的这么做——或者暂停等你决定。两者都需要，但当你想让 AI 在后台跑任务时，靠的是 Hook，不是规则。
第三层：权限层（OS 级硬约束）
这是整套架构的核心，也是我事故之后投入最多精力设计的部分。
权限层的逻辑很简单：不依赖 Agent 是否遵守规则，而是从操作系统层面让危险的事物理上不可能发生。
在动手之前，有一个执行层的基础决策要先做：纯 Windows 没有这些工具。 Windows 缺少多用户文件系统隔离，没有 chattr 这类文件不可变机制，沙箱方案也不成熟——要落地 OS 级硬约束，纯 Windows 环境里很难实现。
最直接的解法是另购一台 Linux / MAC机器。但我暂时不想新增硬件和维护成本，也不想让工作流变得太割裂。于是选择了 Windows + WSL2 的方案：Windows 侧继续跑 Cursor IDE 和 Obsidian，WSL2 承载所有 Agent 执行和权限管控。代价是多一套环境配置，换来的是完整的 Linux 权限工具集。
① Linux 双用户隔离
Cursor 以 agent-user 身份连接 WSL2，而不是用拥有完整权限的主用户。agent-user 可以读写项目代码目录，但无法访问 /home/mount/（主用户 home 目录，700 权限）。即使 Agent 被 Prompt Injection 完全控制，它物理上也读不到 ~/.aws、~/.gcloud、.env 里的任何内容。agent-user 没有 sudo 权限——这一点接下来会解释为什么关键。
② chattr +i 文件不可变属性
对关键文件（harness 脚本、Cursor 规则文件、.gitignore）设置 Linux 的不可变属性：
chattr +i .cursor/rules/safety.mdcchattr +i harness/backup/git-autocommit.shchattr +i 之后，即使文件所有者也无法修改或删除这个文件——解除不可变属性需要 sudo chattr -i，而 agent-user 没有 sudo 权限。这才是真正的物理约束。 Agent 无论被指示做什么，都改不了这些文件。
③ Windows 盘只读挂载
在 /etc/wsl.conf 里配置 options = ro，所有 Windows 磁盘在 WSL2 里以只读模式挂载。这直接解决了我的事故根因：即使 Agent 生成了指向 D:\ 的删除命令，在 WSL2 里执行也会直接报 Read-only file system。
④ 凭证统一隔离
所有云凭证（AWS、GCP、API Keys）集中存放在主用户的 ~/.credentials/ 目录，权限 700，agent-user 物理不可见。工具默认路径（~/.aws、~/.gcloud）通过符号链接指向这个统一目录——一次 chattr +i 保护全部。
⑤ 命令与脚本沙箱
仅有「低权限用户」还不够：T1 里跑 npm install 等外部命令，走 Bubblewrap，把网络和文件系统视图收窄；T2 里跑知识加工脚本，用 t2-bwrap.sh 做选择性挂载——在脚本眼里，spec/、harness/、apps/ 可以根本不存在。这是命名空间级的第二道沙子，和双用户隔离是乘法关系。
五项机制共同构成操作系统级的防御纵深：即使 Agent 完全失控，物理上也无法触及凭证、无法写入 Windows 盘、无法篡改护栏脚本。
第四层：恢复层（兜底用）
前三层出了漏洞，第四层兜底。
核心只有一件事：备份必须与 Agent 的操作范围物理隔离。
我的事故中，bak\ 目录和主目录放在同盘同路径。备份和数据一起消失了。这个备份从设计上就是无效的。
有效的恢复层设计：
自动 git commit：cron 每小时触发一次，有变更就 commit，记录工作区快照 每日 push 到 GitHub：本地 git 被意外删了，GitHub 还有 备份在 Agent 权限范围之外：agent-user 的写权限边界内不包含备份目录
备份的有效性有一个验证标准：你能不能在 30 分钟内从备份完整恢复？ 如果从来没演练过，备份的价值是未知的。
五、经典安全原则在 AI Harness场景的应用
我设计这套架构时，严格遵循了两条经典信息安全原则。
最小权限原则（Principle of Least Privilege）
给任何主体只赋予完成工作所需的最小权限，不多给一分。你不会给一个只需要读数据库的服务账号分配 DROP TABLE 权限。
同样的逻辑用到 AI Agent 上： 一个负责写 apps/ 目录代码的 Agent，不应该能读写 ~/.aws/、不应该能执行 D 盘根目录的删除操作、不应该能修改 Cursor 安全规则。
PocketOS 的事故里，Railway 平台给 Agent 分配的 Token 是全量权限——读写、开发环境和生产环境、单条记录和整个数据库，是同一把钥匙。最小权限原则被违反，9 秒删库是必然的结果，只是时间问题。
纵深防御（Defense in Depth）
不要把所有力量集中在一条防线，而是建立多条独立的控制，每层失效时下一层仍然有效。
我的四层 Harness 架构就是纵深防御的直接实现：
规则层失效（Agent 无视 CLAUDE.md）→ Hook 层仍然拦截危险命令 Hook 层被绕过（脚本配置有误）→ 权限层仍然生效 权限层配置错误（agent-user 意外获得额外权限）→ 恢复层仍然能恢复数据 四层全部失效 → 损失被控制在可恢复范围内（最坏情况：丢失最近一小时的工作）
喆哥的判断：把这两个原则用在 AI Agent 上，不是在做"AI 安全研究"，而是在做最基础的工程卫生。你给数据库账号分最小权限、你给系统做多层备份——给 AI Agent 做同样的事，只是把同一套常识用到了Agent开发环境上。
六、这套OPC安全护栏框架是开放可复用的
我把这套架构的设计文档、决策过程、验收标准全部记录在了项目的 spec/harness/ 目录里——从需求分析到技术决策到实施手册，完整的六阶段文档体系。
这不是一个"我自己用"的方案。它是按照"可以被别人复用"的标准设计的，包含：
场景矩阵：T0/T1/T2/T3 四个工作模式，对应的风险和护栏机制 技术决策记录（ADR）：每个设计选择背后的理由和权衡 验收标准：每条护栏对应一个可执行的命令，验证是否生效 实施顺序：按优先级分步推进，一人公司可独立完成
如果你想要这套框架的完整设计文档，以及实施过程中那些容易踩坑的细节——比如 WSL2 双用户怎么配置不踩坑、chattr +i 在什么情况下会失效、Hook 脚本怎么调试——可以直接联系我获取。
👉 扫描文末二维码，加喆哥微信，备注「Harness 方案」
三个洞察
一、护栏不是限制 AI，是让 AI 可以放心用。 没有护栏时，每次让 Agent 执行破坏性操作你都在赌。有了护栏，你才真正敢踩油门——AI Agent 像涡轮增压，管路和泄压到位，马力才算是你的。
二、规则、Hook、权限、恢复，四道门要装齐，不能只靠 AI 自觉。 规则层是意图声明，Hook 层是程序化阻断，权限层是 OS 级物理屏障，恢复层确保最坏情况损失可控——四层各司其职，缺任何一道链条就断了。
三、OPC 的 Harness 工程不需要大公司的复杂度。 双用户隔离 + 文件不可变属性 + Hook 拦截 + 自动备份，总成本：零，只需要几小时的一次性配置。这是一人公司能做到的最高性价比安全投资。
关注「喆哥AI原生产品转型」，获取 AI-native 产品战略的深度分析。加喆哥微信，进"AI原生产品转型"交流群，和行业专家、AI 原生产品经理一起讨论 AI 原生时代的产品机会。
