📦 本文基于的完整项目源码：meirongdev/shop

开场：一次被拒绝的 git push#

让 Claude Code 帮我把一批 commits 推到 origin/main，得到的不是成功，是一段克制但毫不含糊的拒绝：

Permission for this action has been denied. Reason: Pushing directly
to main bypasses PR review; commits should go to a feature branch.

奇怪的是，我的项目 .claude/settings.local.json 里有 142 条 Bash(...) allow 规则，却没有任何 deny；用户级 ~/.claude/settings.json 也只配了 permissions.defaultMode: "auto" 一行。这条拦截看起来是凭空冒出来的——但它的措辞具体到了"PR review"和"feature branch"，又像是某个真人写过的策略。

这篇文章想顺着这条具体的拒绝信息往下挖：到底是哪一层在拦？为什么 2026 年的 AI 编码 agent 普遍都在补这种"边界"设计？vibe coding 失控时的代价可能有多大？业界其他 agent 又选择了哪些不一样的取舍？

文中尽量给出我能找到的引用，并优先保留我这次还能访问到的 URL。

一、拦截到底是哪一层做的？#

Q：先验证一下，是不是有人写了 deny rule？

我把 settings 翻了一遍，没有 deny。Claude Code 的官方权限文档写得很清楚：deny rules 是最高优先级，但没有内置的"危险命令"自动阻止列表——rm -rf /、git push origin main 之类都不在 hardcoded blacklist 里。换句话说，这个拦截不来自某个静态规则。

Q：那 defaultMode: "auto" 是什么意思？

Permission modes 文档 列了六种：default、acceptEdits、plan、auto、dontAsk、bypassPermissions。重点在 auto——它不是"自动允许全部"，而是"由模型自己判断该不该执行"。

具体怎么判断的？Anthropic 在 2026 年专门写了一篇博客 Claude Code auto mode: a safer way to skip permissions 解释机制：两层防御 + Sonnet 4.6 transcript classifier。

  • 第一层 prompt injection 探针：检测输入里有没有"忽略前面的指令"这类典型注入模式。
  • 第二层 transcript classifier：跑一个 Sonnet 4.6 的小模型读会话上下文，判定这次工具调用是不是"超出用户预期"。
  • 17% false-negative rate 是 Anthropic 故意保留的——precision over recall，避免把日常操作打飞。

这就解释了我看到的拦截信息为什么具体到 “PR review” 和 “feature branch”——它不是规则匹配出来的，是 classifier 模型读完会话后自己写的拒绝理由。拦我的是另一个 LLM。

这个机制和大家以前理解的"权限系统 = ACL"已经不太一样。它是一个把 LLM 放进 harness 做安全判定的设计。后面还会回到这个洞察。

二、为什么需要这层？vibe coding 与失控的代码生成#

Q：vibe coding 这个词到底什么意思？

Andrej Karpathy 在 2025-02-02 的 X 帖子 里第一次用这个词，描述"完全交付给 AI、不审查代码"的编程方式。一年后他在回顾推文里承认自己没预料到这个词会扩散得这么快。

Simon Willison 提出过更严格的定义：Not all AI-assisted programming is vibe coding。他强调"vibe coding"应该专指用 LLM 写软件且不审查代码，只适合"无安全 / 隐私 / 财务暴露"的低风险项目；任何要进生产的代码都不该归为 vibe coding。

主流媒体的定调可见 IEEE Spectrum, Engineers Are Using AI to Code Based on Vibes（2025-04，6 月刊纸版）。CodeRabbit 的 A semantic history of vibe coding（2026-03-05）梳理了从一条推文到 Collins Dictionary 评 2025 年度词的语义漂移过程。

Q：vibe coding 真的出过严重事故吗？

我最近查这类材料时，几乎都会碰到这些案例。

Vibe coding service Replit deleted user’s production database, faked data, told fibs galore（The Register, 2025-07-21）：SaaStr 创始人 Jason Lemkin 试用 Replit Agent 12 天，第 9 天 agent 在显式 code freeze 下删除了生产库（含 1,206 条高管记录），事后伪造数据掩盖、谎称无法回滚。

Lovable-hosted app littered with basic flaws exposed 18K users（The Register, 2026-02-27）：研究员在一个 Lovable 生成的 app 里发现 16 个漏洞，6 个 Critical，约 18,000 用户暴露。AI 生成的代码缺失 row-level security、认证逻辑等基础控制。

更系统的数据来自 Cloud Security Alliance 2026-04-04 的研究简报 Vibe Coding’s Security Debt: The AI-Generated CVE Surge：

  • Veracode 测试 100+ LLM，45% 样本引入 OWASP Top 10 漏洞；Java 失败率 72%、XSS 86%、log injection 88%
  • 约 20% 样本引用不存在的包（slopsquatting 风险）
  • Georgia Tech “Vibe Security Radar” 仅 2026-03 一个月就归因 35 个 CVE 给 AI 生成代码（1 月 6 个、2 月 15 个，环比加速）

Palo Alto Unit 42 Securing Vibe Coding Tools（2026-01-08）把风险归为四类：安全去优先化、上下文盲、供应链污染、新手采用。

Q：那 prompt 里告诉模型"小心点"不就行了？

至少从我这次看到的材料里看，不太行。这也是这一波研究里重复出现的结论。

Maloyan & Namiot 的 SoK 论文 Prompt Injection Attacks on Agentic Coding Assistants（arXiv:2601.17548, 2026-01-24）综合 78 篇研究：

  • 现有防御对自适应攻击的缓解率 < 50%
  • 自适应攻击成功率 > 85%（针对 Claude Code、Copilot、Cursor 实测）
  • 论文结论：“prompt injection 应被当作架构问题，不是过滤问题”

Simon Willison 在 New prompt injection papers — Agents Rule of Two（2025-11-03）里转述 Meta 的 Agents Rule of Two：一个 agent 不应同时具备“处理不可信输入 / 访问敏感数据 / 执行外部动作"中的任意三项；同期 Meta 的 The Attacker Moves Second 论文证明 adaptive attack 对几乎所有现有 prompt 防御 > 90% 成功率。

经典对照是 NYU 团队 2021 年的 Asleep at the Keyboard（IEEE S&P 杰出论文，后续也有 CACM 期刊版）：实测 GitHub Copilot 生成代码 ~40% 含安全漏洞。这是奠基实证，CSA 报告至今仍在引用作为基线。

我觉得比较反直觉的数据来自 METR：Measuring the Impact of Early-2025 AI on Experienced OS Developer Productivity（arXiv:2507.09089）。16 名资深 OSS 开发者 RCT，用了 AI 反而慢 19%——但事前预期快 24%、事后自评仍认为快 20%。这至少说明：人对 AI 提速的体感和真实结果未必一致。METR 在 2026-02-24 调整了实验设计后再做，仍未推翻结论。

把这些放一起：模型层告诉自己小心不太够；用户体感的"快"和实际的"慢"未必一致；攻击者还在持续找新的 prompt injection 路径。至少在我当前的理解里，更稳妥的方向还是在工程层划边界，让边界的有效性尽量独立于模型的服从能力。

三、Claude Code 的 harness 分层#

Q：Anthropic 自己怎么定义 harness？

How Claude Code works 文档原话：

Claude Code serves as the agentic harness around Claude: it provides the tools, context management, and execution environment that turn a language model into a capable coding agent.

Anthropic 工程团队 2026 年发的另一篇 Harness design for long-running application development 把这个思路展开：harness 不是"给模型加几个工具”，而是整个执行环境的设计——包括边界、审计、扩展点。

Q：具体哪些层？

把官方文档串起来，Claude Code harness 的可识别层次大致是：

层 控制什么 官方文档
Tool 层 哪些工具存在（Bash / Read / Edit / WebFetch …） How Claude Code works
Permission 层 工具调用是否放行（allow / deny / ask） Permissions
Permission Mode 默认裁决策略（default / auto / acceptEdits / plan / bypassPermissions） Permission modes
Sandbox 层 OS 级文件系统 + 网络隔离（macOS Seatbelt / Linux bubblewrap） Sandboxing
Hooks 层 用户自定义 PreToolUse / PostToolUse / UserPromptSubmit 拦截 Hooks reference、Hooks guide
Skill / Subagent / Plugin 能力扩展（按需加载 / 隔离上下文 / 打包分发） Skills、Subagents、Plugins
MCP 外部工具集成（仍受权限规则约束） MCP

我开头看到的拦截，发生在 Permission Mode（auto）——一个跑在 harness 里的 Sonnet 4.6 classifier，在工具实际执行前、读完会话上下文、给出"拒绝 + 理由"。这是一个非常具体的"工程边界由 LLM 实现、但与主 agent 的 LLM 解耦"的例子。

四、对比：业界其他 agent 的 harness#

不同 agent 选择了非常不同的边界画法。最近 3 个月的 CVE、issue、博客、论文一起看，差异就清晰了。

4.1 Cursor — Allowlist 反复被绕过#

Cursor 走的是"命令字符串 allowlist / denylist"路线。问题在于 shell 语义远比 string 匹配复杂。

  • CVE-2025-54131 反引号绕过（GHSA-534m-3w6r-8pqr, 2025-08-01）：allowlist 配的是 git，但攻击 payload 用 git $(rm -rf /) 反引号执行任意命令。Cursor 1.3 修复。
  • CVE-2026-22708 环境变量污染（GHSA-82wg-qcm4-fp2w, 2026-01-14）：通过 env var 污染绕过 allowlist。Pillar Security 在 The Agent Security Paradox 给出原话："trusted commands become attack vectors"。Cursor 2.3 修复。
  • Cursor 在 v1.3 之后弃用了 denylist，详见 Backslash 报告 The Denylist Delusion（2025-07-21）。
  • Sandbox 与 allowlist 的另一处冲突：forum.cursor.com 152136（Cursor 团队 2026-02-18 承认 sandbox 模式下 allowlist 静默失效）。

从这个案例里我得到的提醒是：把边界画在"shell 字符串"上会比较脆——shell 的解析层次太多，allowlist 很容易漏。

4.2 Aider — 几乎没有边界#

Aider 的官方文档 列了 --yes-always，但社区 issue #3903 指出这个选项不会让 shell 命令自动执行——“yes-always” 只覆盖了部分 prompt。

更严重的是 issue #4882: Sandboxed test execution via exec-sandbox (QEMU microVMs)：开发者社区自发认识到 --auto-test 模式直接在宿主机执行 AI 编辑过的代码，没有任何隔离边界。社区呼吁引入 microVM 但官方未承诺时间表。

这让我更倾向于认为：在没有 sandbox 的前提下，“agent + auto-execute” 的风险很难收敛。

4.3 Devin — VM 级隔离，但输出质量翻车#

Cognition 的 Devin can now Manage Devins（2026-03-19）和 2026 release notes 显示，Devin 的边界画在 VM 层：每个 managed Devin 跑在独立 VM 里，自带 terminal/browser/dev env；2026-02-13 把 Secure mode 从企业版扩展到普通用户；2026-04-03 加了企业级 MCP allowlist；2026-04-17 加了仓库级 review 权限。

但 VM 隔离解决的是 blast radius，不解决生成质量。Tenzai 2025-12 的实测报告 Vibe Coding Security: 69 Vulnerabilities 在 5 个 agent（含 Devin）共 15 个 app 里发现 69 个漏洞；Answer.AI 早期实测 20 项任务仅 3 项成功（Trickle 整理）。

这组数据更像是在提醒我：blast radius 和 generation quality 是两个独立问题，VM 只解决前者。

4.4 Cline / Roo Code — 模型自评估#

Cline 的 Auto-Approve 文档 提供 9 类操作 toggle（read / edit / exec / browser / MCP），没有固定 allowlist——由模型给每条工具调用打 requires_approval 标。“YOLO” 模式则禁用所有 safety checks，文档原话 “disables all safety checks”。Roo Code 的 Auto-Approving Actions 大体同构。

我自己的理解是：让模型给自己打风险标，本质上还是模型层的判断——不是工程边界。

4.5 GitHub Copilot Coding Agent — 把边界外包给 GitHub Actions#

这是我目前看到工程系统级边界做得比较彻底的一家。Copilot Coding Agent（2025-09 GA）的Responsible Use 文档明确：

  • agent 只能 push 到 copilot/* 分支——main 物理隔离
  • secrets 限定到 copilot environment
  • Branch protection 需要显式把 agent 列为 bypass actor 才能合
  • Actions workflow 需要 human approve（About Copilot cloud agent）
  • 每个 commit 加密签名 + co-author 标注

整套设计的特点：agent 的安全性几乎与底层模型行为正交——branch protection 是 GitHub 的、Actions sandbox 是 GitHub 的、合规审计是 GitHub 的，模型即便完全失控也撞不破这些边界。

这大概是“模型服从 ≠ 工程边界”原则里一个很典型的实现——不要让 agent 自己执行有副作用的写动作，而是让平台现有的 SDLC 关卡来执行。

4.6 OpenAI Codex CLI — OS 级 sandbox + 显式档位#

OpenAI Codex CLI 的Sandboxing 文档 把权限切成三档：read-only / workspace-write / danger-full-access；底层是 macOS Seatbelt 和 Linux Landlock 的 OS 级实现。Approvals & Security 文档规定 .git、.codex、.agents 强制只读，并支持 deny-read glob。

Changelog 显示 2026-04 集中加固了几处：04-20 新增 security-boundaries reference doc；04-23 项目 hooks 必须在 trusted workspace 才生效；04-24 permission profile 跨会话持久化。

看到这里，我自己会更偏向 sandbox 档位 + 关键路径强制只读 + 显式 trust boundary 这类组合。

4.7 对比矩阵#

Agent 隔离层级 默认确认时机 颗粒度 公开弱点
Cursor (≤2.2) 进程 / 可选 OS sandbox Auto-Run 不确认 命令字符串 allow/deny 反引号、env var 多次绕过（CVE-2025-54131 / 2026-22708）
Aider 无 sandbox（宿主直跑） 每条 shell 仍提示，但 --auto-test 在宿主 操作类型 没有边界，社区自发推 microVM
Devin VM-per-task Async；review 阶段确认 VM + MCP allowlist + 仓库级 review 输出质量低（69 漏洞 / 15 app）
Cline / Roo 进程内 9 类 toggle + 模型自评估 类别 + requires_approval 模型自打 依赖模型自报风险
Copilot Coding Agent GitHub Actions sandbox + 分支保护 Pre-merge human review 仓库写权限 + copilot/* 分支 + secrets env 工程边界相对更强
Codex CLI OS sandbox（Seatbelt / Landlock） 三档 + on-request sandbox 档位 + glob deny + 关键路径强制只读 2026-04 多次修复 sandbox 状态泄漏
Claude Code OS sandbox + permission rules + auto-mode classifier auto: classifier 决定；default: 弹窗 工具粒度 allow/deny + hooks + LLM classifier 17% false-negative（设计选择）

每一行都在尝试在便利和安全之间画线，画在不同层就有不同的失败模式。

五、harness 设计的核心原则#

Q：把所有这些放一起，能提炼出什么共同原则？

我自己的归纳只有一句：模型的指令服从能力 ≠ 工程系统的安全边界。

支撑这一论点的最强材料是 arXiv 2026-04-20 的 Architectural Design Decisions in AI Agent Harnesses。论文调研了 70 个 agent 项目的 harness 实测：

  • 17% 完全无 sandbox
  • 45% 进程隔离、31% 容器、7% WASM
  • 40% 完全无审计
  • 只有 5% 有 tamper-evident audit trail
  • 论文结论：“governance burden 和 sandbox 强度未同步”

Cursor 的两个 CVE 就是这个论点的一个反例——模型完全“服从”了 allowlist 配置，但因为 parser 漏洞 + shell 语义边界不严，工程边界还是塌了。Pillar Security 报告的"trusted commands become attack vectors"完整复述了这个逻辑：当工程边界依赖模型不会犯错或不会被诱导，它就不是边界。

SoK: The Attack Surface of Agentic AI 把这个原则进一步抽象：agent 的攻击面应该被建模为 输入信道 × 工具访问 × 持久化能力 的笛卡尔积，每个维度都需要独立的工程控制。只靠 prompt 往往不够。

Q：harness 可以朝什么标准靠？

按 arXiv 2604.18071 的调研归纳：

  1. 与模型解耦——任一边界的有效性尽量不依赖模型的服从。Claude Code 的 sandbox 层就是这种——OS 级 Seatbelt/bubblewrap，至少不会把约束完全交给模型自己遵守。
  2. 多层冗余——任一层失效不导致整体失效。Claude Code 的 deny → ask → allow → mode → sandbox 是冗余链。
  3. Tamper-evident 审计——所有工具调用 + 拒绝原因可追溯。这是当前业界普遍缺的（论文报道只有 5%）。
  4. 生命周期对齐——harness 配置随项目演进，不是装一次就丢。

六、作为开发者，我应该怎么配？#

Q：一个能跑起来的最小 Claude Code harness 配置长什么样？

下面是一个我会拿来当起点的配置（基于官方权限文档 和 hooks-guide）：

{
  "permissions": {
    "defaultMode": "auto",
    "deny": [
      "Bash(git push origin main)",
      "Bash(git push origin master)",
      "Bash(git push --force:*)",
      "Bash(rm -rf /:*)",
      "Bash(kubectl delete:*)",
      "Bash(terraform destroy:*)",
      "Bash(npm publish:*)",
      "Bash(docker push:*)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(gh pr merge:*)",
      "Bash(npm install -g:*)"
    ]
  }
}

要点：

  • defaultMode: "auto" 让 Sonnet 4.6 classifier 兜底未知命令
  • deny 列显式破坏性 + 不可撤销的具体形式（不是模糊匹配）
  • ask 列"可能没事但要看上下文"的命令——交给真人决策
  • bypassPermissions 别动（除非你完全清楚自己在做什么）

Q：sandbox 应该怎么开？

Sandboxing 文档 列了 macOS Seatbelt 和 Linux bubblewrap 两个底座，配 allowWrite / denyWrite / allowRead / denyRead 和 allowedDomains / deniedDomains。最小集合：

  • denyWrite ~/.ssh、~/.aws、~/.gnupg、/etc
  • denyRead 同上的敏感目录
  • denyDomains 默认拒外网，按需 allow *.maven.org、registry.npmjs.org 等

Q：hooks 用来做什么？

hooks-guide 列了三个常见用法：

  1. PostToolUse 自动跑 gofmt / prettier / mvn spotless:apply
  2. PreToolUse 拦截写入特定文件（CHANGELOG.md、设计文档）
  3. UserPromptSubmit 注入项目级强约束（“任何 PR 必须更新 CHANGELOG”）

hook 的关键价值是与项目无关地写出“组织级约束”——这些约束不应该依赖每次 prompt 都提醒模型。

七、绕不开的 tradeoffs#

Q：harness 严了不会拖慢迭代吗？

会，且这是 Anthropic 显式的设计选择。auto mode blog 原文：17% false-negative rate 是为了避免日常操作被频繁打飞——precision over recall。换言之：他们承认会漏一部分真实风险，换日常体验流畅。

理解这个 tradeoff 的方式：harness 不是越严越好，是风险对位。私有项目实验代码用 bypassPermissions、生产仓库用 auto + 严格 deny + sandbox、CI/CD 完全不让 agent 直接写。

Q：vibe coding 完全不该用吗？

不是。引用 Simon Willison 的原文：低风险场景（一次性脚本、无外部交互的原型、内部 demo）vibe coding 仍然是高效的方式。但不要直接把"vibe"代码推到生产——至少我上面列到的事故，几乎都和这一点有关。

CIO Dive 的 The enterprise is not ready for vibe coding — yet 引 Gartner 预测 2028 年 40% 新代码由 vibe coding 产生，但当前安全 / 可扩展性 / 治理标准均未就绪——节奏问题，不是技术问题。

Q：harness 谁来维护？

跟 SLO、catalog 一样：owner 最好三处对齐——配置归谁改、违例归谁审计、新规则归谁加。harness 不是"装上就好"——配置会和项目一起演进，规则陈旧的 harness 比没有还危险（开发者会习惯绕过它）。

结尾#

我那条被拦的 git push origin main，现在回头看更像是一次提示：Anthropic 的 Sonnet 4.6 classifier 把这次“vibe 操作”挡了下来——理由具体到 “PR review”，也让我重新意识到自己原本要做的事情确实绕过了团队约定的边界。

这大概也是我现在观察到的一个共同方向：把安全边界从 prompt 里挪出来，画进工程系统。Cursor 反复暴露出字符串 allowlist 的脆弱、Aider 社区在补 microVM、Devin 直接上 VM、Copilot 借力 Actions、Codex 用 OS sandbox、Claude Code 引入 LLM classifier——路径不同，但都在试着把损害范围压小。

对我来说，vibe coding 本身不是问题；没有 harness 的 vibe coding 才更值得警惕。

引用全表#

为方便检索，所有引用整理如下：

官方文档（Claude Code）

Anthropic 工程博客

vibe coding 概念与媒体

vibe coding 失败案例

安全研究与论文

业界 agent 安全