大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



嗨，我是 Lena。几个月前我在看一个 agent 跑代码库，它就……一直跑。不停，不问。它改了三个我根本没提到的文件，然后还贴心地建议说可以顺便再改四个。代码倒也不能说有错，但就是不是我想要的那个"对"。

那一刻起，我开始更认真地观察这些 agent 到底是怎么被"管住"的——不是它能不能做某件事，而是你怎么告诉它该做什么。更重要的是，你怎么告诉它哪些事绝对不能自作主张。

大家聊 agent 工作流里的"超能力"，其实这个词挺容易让人误解的。超能力不是原始能力有多强，而是你能不能让那个能力按你的意思来——稳定地、可重复地、每次会话都一样地执行。

我老看到有人把"超能力"拿来形容功能：代码执行、网页搜索、tool call。这么理解也不是不行。但我观察那些真正在生产环境里跑 agent 的人，他们聊的几乎都是另一件事。

他们聊的是约束系统。

问题不是"这个 agent 能做什么？"而是"我怎么拦住它不干我不想让它干的事，同时还让它把我想让它干的事干好？"这本质上是治理问题。治理需要的是被稳定执行的规则——不是你贴到 prompt 里然后祈祷它能遵守的那种提示。

我很早就注意到一件事：没有行为约束的 agent 不是不好用，是不可预测。一半时候给你对的结果，另一半时候突然来个完全意想不到的操作——不是模型坏了，而是没有任何东西把它的行为锚定到你的标准上。

工具给 agent 延伸范围。约束给 agent 方向感。

大部分团队都是撞上了才明白这个区别。先加工具，看 agent 跑起来，被它的某个自主决策吓一跳，然后才开始写规则。失败模式反过来教你该约束什么。

在我看来，Claude Code 对这个问题的处理是最结构化的。核心机制是 SKILL.md 文件——一个带 YAML frontmatter 的 markdown 文件，把指令、脚本和参考资料打包成一个整体，Claude 在需要的时候可以动态加载。

让我觉得真正有意思的是 Anthropic 所说的"渐进式披露"。会话开始时，Claude 只加载每个已安装 skill 的名字和描述——不是完整内容。完整指令只有当 Claude 判断这个 skill 跟当前任务相关时才会加载。正如官方 agent skills 文档里描述的：skill 就像给新员工准备的入职指南，agent 只读它需要的章节。

还有 CLAUDE.md——一个放在项目根目录的持久化文件，整个会话期间都会携带常驻指令。跟 skill 不同，它始终存在。你可以把它理解成基线契约：你的架构决策、文件规范、那些你永远不想让 agent 自行假设或跳过的东西。

权限作用域是在工具层面工作的。你在 skill 的 YAML frontmatter 里定义 allowed-tools，来限制这个 skill 能调用哪些 bash 命令、文件操作或 API。这个细节我花了一段时间才真正理解。它管的不只是 agent 知道什么——而是 agent 被允许碰什么。

有一点我到现在还没完全想明白：当会话变长、上下文窗口开始压缩的时候，这些约束还能撑住吗？Claude Code 文档提到自动压缩会保留已调用的 skill，但如果一个会话里加载了太多 skill，较早的可能会被丢弃。我注意到过一些行为漂移，可能跟这个有关。也许是我想多了，但它不像是随机的。

Cursor 走的是分层路线。你有三层：User Rules（全局的，作用于一切）、Project Rules（版本控制的，放在 .cursor/rules/ 里），以及老版本的项目根目录下的 .cursorrules 文件。截至 2026 年初 .cursorrules 格式还能用，但 Cursor 官方文档说得很明确，它已经被废弃了——推荐的路径是迁移到 .mdc 项目规则系统，以获得更好的作用域和控制能力。

.mdc 格式增加了一层 .cursorrules 没有的元数据：你可以设置一条规则是 alwaysApply、绑定到特定文件 glob，还是只在 agent 判断相关时才加载。最后这个选项——agent 主动请求的规则——比听起来有意思得多。它意味着规则系统可以是上下文敏感的：前端规则不会在后端文件里加载，支付服务的约束不会泄漏到不相关的模块里。

我深入研究之后发现：最管用的规则是具体的、命令式的，而不是模糊的、愿景式的。"所有新文件用 TypeScript"——能管住。"写干净、可维护的代码"——啥也没说。你对想要的东西描述得越精确——或者你明确不想要的东西越清楚——agent 的遵守就越稳定。

Cursor 现在还有 AGENTS.md，对于不需要完整元数据开销的项目来说，是一个纯 markdown 的替代方案。更简单，灵活性略低。

OpenAI 的 Codex CLI 有一套干净的指令层级体系，我觉得值得了解一下。会话开始时，Codex 会构建它文档里所说的"指令链"——先读全局的 ~/.codex/AGENTS.md，然后从项目根目录一路往下走到你的当前目录，沿途拾取所有 AGENTS.md 文件。离你当前目录越近的文件优先级越高。

根据 Codex 自定义指令文档，你还可以在任何层级放置 AGENTS.override.md 文件来明确覆盖意图。对于有 monorepo 或者子服务需求差异很大的团队来说——比如支付团队和数据分析团队——这意味着你可以有共享的基线规则和服务级别的专属约束，而且它们永远不会意外地互相串扰。

Codex 最近也采用了同样的 SKILL.md 模式。Codex skills 文档描述了相同的渐进式披露方式：先加载 skill 元数据，完整指令只在 skill 被调用时才载入。整个生态正在朝着一种共同的设计语言收敛，即使跨越了不同的厂商。

默认收紧审批和沙箱权限才是对的——只在你清楚影响范围的特定工作流里才放宽。

这是我反复回到的工作流模式。结构是：把一个 agent 任务拆成不同阶段，每个阶段由不同的 skill 来管。

一个 brainstorming skill 打开问题空间、生成选项、暴露边界情况。不写代码。然后一个 planning skill 接管——结构化方案、要动哪些文件、先写什么测试。只有方案确定后，executing skill 才开始真正改代码。

这就是 GitFlow + TDD + code review 的镜像——只是 agent 一个人扮三个角色，每个角色有不同的行为画像。brainstorming skill 可以天马行空，executing skill 被约束到只能按审批通过的方案执行。

为什么这样能减少失败：每个阶段的成功标准更窄了。一个在"brainstorming"的 agent 不会不小心写出生产代码。一个在"executing"的 agent 不会在实现过程中突然重新设计架构。

我开始用这个模式，是因为看到一个 agent 在重构的时候转了四十分钟的圈——它不停地推翻自己的决定。把阶段分开并没有让 agent 变聪明，而是让整个过程变稳定了。

这里有一个我一直注意到的缺口，说实话我自己也还没完全想清楚该怎么看。

我前面说的所有约束系统都是会话范围的。它们是本地的——活在文件里，会话开始时被加载，会话结束时就重置。对于已知的代码库、已知的团队、已知的标准集，它们非常好用。

但它们解决不了另一类问题：一个 agent 在整个生命周期里的行为该怎么管？你怎么知道三个月前有效的约束在底层模型升级后还适用？你怎么把经过验证的行为模式传播到不共享代码库的 agent 上？

文件级约束回答不了这些问题。它们本来也不是为此设计的。这就是治理——不只是规则——开始变重要的地方。本地约束是第一步。但治理意味着追踪约束是否还在起作用，并且有一种机制来把更新传播到整个 agent 网络，而不是一次只管一个项目。

这块在实践中该怎么做，我还在摸索。

约束告诉 agent 该怎么做。但它不会告诉你 agent 事后到底做对了没有。这是两个不同的问题。

我最常见到的失败模式不是 agent 无视规则，而是 agent 完美地遵守了规则——但在一个规则没覆盖到的场景里。规则是对的，只是规则没写到那个新情况。

规则会过时。六个月前完全正确的规则，现在可能就微妙地偏了——模型的默认行为变了、代码库变了、或者规则引用的标准上游更新了。

没有哪个规则文件能自我维护。Claude Code、Cursor 和 Codex 的约束系统共享同一个盲区：没有机制来检测一条规则已经过时了。它只是悄悄地不再按预期工作。Cursor 的文档和各路实践者都推荐定期做规则审计——不是因为规则本身脆弱，而是因为规则周围的环境在不断变化。

这是我反复想的一点。

每次会话都是从零开始。CLAUDE.md 被重新读取。AGENTS.md 被重新读取。Skills 被重新发现。Agent 对上次什么管用、哪里有微妙的失败模式、你花三周调试学到了什么——毫无记忆。

你可以把那些经验编码到规则文件里——也确实应该这样做。但编码是手动的。约束系统本身不会学习。是你在学习，然后你把学到的东西写下来，然后约束系统才反映出来。

这是一个真实的局限。我不确定在当前架构下能不能解决。但值得把它说清楚。

• AI agent 工作流里的"超能力"指什么？

  不是功能——是约束系统。也就是定义一致的行为规则、权限作用域和阶段化指令的能力，让 agent 在每次会话里都遵守。

• 怎么在 Claude Code 里设置行为约束？

  通过 SKILL.md 文件（YAML frontmatter + markdown 指令，存放在 .claude/skills/）和一个用于常驻指令的 CLAUDE.md 文件。工具级权限写在 allowed-tools 字段里。Anthropic 官方 skills 仓库里有真实案例。

• .cursorrules 和 CLAUDE.md 有什么区别？

  它们属于不同工具。.cursorrules（已废弃，推荐迁移到 .cursor/rules/*.mdc）是 Cursor 的格式；CLAUDE.md 是 Claude Code 的持久化指令文件。两者都会在会话中携带常驻规则，但作用域机制不同。

• Agent 约束能跨会话持久化吗？

  原生不支持。规则文件在每次会话开始时重新读取。Agent 对之前的会话没有记忆。你可以手动把学到的行为编码进那些文件——这确实是正确的做法——但约束系统本身不会积累经验。

• brainstorming-writing-executing skill 模式是什么？

  一种不同 skill 管不同阶段的工作流：brainstorming 打开问题空间但不写代码；planning 产出结构化方案；executing 按审批通过的方案实施。每个阶段的成功标准更窄，从而减少循环和实现中途的架构变更。

我大概会继续观察这些东西的演进。约束系统在变得越来越精细，跨工具朝 SKILL.md 作为共享格式收敛这件事我想更密切地跟踪。但会话范围的局限性感觉像一道天花板，现有的工具都还没想出怎么突破。这里面有什么东西在发生——我只是还没完全看清。

• 理解 agent 系统背后更深层的技术栈
• 看看记忆系统和约束系统在实践中的区别
• 了解 Claude Code skills 底层到底怎么工作的
• 手把手教你构建和组织可复用的 Claude Code skills
• 理解 skill 文件和真正的 agent 能力之间的区别