我一开始以为，做 agentic coding 最烦的是模型会不会理解项目上下文。后来发现，更麻烦的问题其实是：你到底让它在什么边界里动手。

上下文不够，最多是改不对；运行边界不清，才会把事情真的搞乱。尤其是当工具开始能主动跑命令、改文件、串联多步操作以后，“权限提示太频繁”并不只是体验问题，它其实在提醒你：这件事本来就不该被轻易跳过。

为什么我觉得 Claude Code 这波变化值得警惕着看

Anthropic 今年 3 月和 4 月连续放出了几篇很关键的工程文章：一篇讲 Claude Code auto mode 怎么在更少权限打断的情况下工作，一篇讲长时间应用开发的 harness 设计，一篇讲 managed agents 如何把“脑”和“手”解耦。这几篇放在一起看，信号很明确：大家都在往更自治、更少人工确认的方向推，但平台自己也知道，自治能力一上来，最先失控的不是模型智力，而是执行边界。 citeturn219854search4turn690268search12

这也是我为什么不愿意把“自动跳过权限”理解成纯粹的效率升级。它更像是把原来由弹窗承担的一部分风险控制，转移到了 harness、策略文件、目录限制和环境隔离上。你如果没把这层补上，少点几次确认框，不是更顺滑，是更危险。

权限提示减少，不等于权限问题消失

很多人会把权限提示看成一种烦人的 UI 摩擦，但工程上它其实对应三类真实风险：

• 命令执行风险：例如脚本误删、误装、误改本地环境；
• 文件改动风险：例如越过目标目录，改到不该碰的配置和脚手架；
• 状态串联风险：前一步生成的错误假设，被后续步骤继续放大。

这三类风险有个共同点：一旦发生，不一定马上报错。很多时候你是在 20 分钟后、一次测试失败后、或者一次部署异常后，才意识到前面某一步越界了。也就是说，真正贵的不是“它点错了一次”，而是“你最后得追一串链路去找它到底从哪里开始偏”。

我更在意的是 harness，而不是权限弹窗数量

Anthropic 这几篇文章里，真正值得开发者学的不是产品界面，而是 harness 这个思路：不要把 agent 想成一个无边界的智能体，而要把它放进一个被明确约束的执行容器里。容器不一定非得是虚拟机，它可以是你定义出来的一组硬规则：

runtime_policy:
  allowed_paths:
    - src/features/billing
    - tests/billing
  blocked_paths:
    - infra/
    - migrations/
    - .github/workflows/
  allowed_commands:
    - pnpm test billing
    - pnpm lint src/features/billing
  blocked_commands:
    - rm -rf
    - docker compose up
    - git push
  requires_human_review:
    - schema_change
    - dependency_change
    - env_file_change

这套约束一点都不性感，但它决定了 agent 到底是在替你干活，还是在替你制造排障工单。

个人开发者最容易忽略的，是本地环境比仓库更脆弱

团队环境至少还有 CI、代码评审、部署流程这些缓冲层。个人开发者经常直接在本地仓库里跑 agent，权限边界如果没收好，本地环境就是第一受害者。比如：

• 临时脚本把开发数据库清了；
• agent 误改 shell 配置或环境变量文件；
• 一个为了“修测试”而加的 hack，被你自己忘了，最后带进生产；
• 在主工作目录反复试错，导致 git 历史和工作树越来越乱。

这些都不是模型能力问题，而是运行制度问题。很多人高估了“我会盯着它”的作用，低估了多步骤自动执行一旦开始以后，人其实很难一直保持高质量监督。

我会怎么把边界写死

如果我是个人开发者，我会优先做这四件事，而不是先追求更高自治：

• 所有 agent 任务默认在独立 worktree 或临时分支执行；
• 默认只开放白名单目录和白名单命令；
• 把“永远不能自动做”的事情写成硬规则；
• 每次任务结束必须输出改动摘要、执行命令、失败点和未确认项。

git worktree add ../task-billing-alert -b task/billing-alert
cd ../task-billing-alert
# 在隔离目录里再交给 agent 继续执行

如果是小团队，我会再加两层：一层是 repo 级的策略文件，一层是 CI 级的强制拦截。前者负责告诉 agent 哪些地方别碰，后者负责就算它碰了也别让它直接混进主线。

被宣传掩盖掉的代价

“更少权限确认”听起来像更流畅，但它其实会带来一笔隐藏成本：你得把原本靠人工即时判断处理掉的风险，转成前置规则、隔离环境、日志回放和失败恢复机制。也就是说，体验越顺，前面的工程治理越不能偷。

这也是为什么我不建议个人开发者直接把 agent 接到最核心、最脆弱的项目目录上。它不是不能用，而是你至少要先给它一个护栏足够厚的跑道。

我的判断

Claude Code 这条线我会继续重度关注，因为它正在把 AI 编程从“会写代码”推进到“会执行开发任务”。但我不会把 auto mode 理解成“终于可以放心少管它了”。恰好相反，它越能自己干活，你越要先把运行边界写死。

对个人开发者来说，现在最值得投入半天时间做的，不是研究更花哨的提示词，而是把目录白名单、命令白名单、worktree 隔离和 review 触发条件先写出来。你把这些写清楚以后，agent 才是副手；不然它更像一个有执行力、但边界感不稳定的实习生。