Tessl 编程智能体护栏将代码仓库文件转化为控制层

尽管对托管模型的依赖日益加深，Tessl 发布了一套由四部分组成的框架，让团队能够通过自己拥有的文件来控制编程智能体。Tessl 编程智能体护栏将持久化指令、路径特定规则、可复用能力和自动化钩子区分开来。这一区分至关重要，因为书面请求和可强制执行的限制并不能提供同等程度的保护。

该框架使用 CLAUDE.md、.claude/rules/、.claude/ 下的能力文件，以及通过 Claude Code 配置连接的钩子。每一层负责处理智能体工作流中的不同环节。它们共同将操作知识从临时对话转移到受版本控制的代码仓库资产中。

核心矛盾并非 Tessl 与其他开发者工具之间的竞争，而是建议性上下文与确定性执行机制之间的差异。模型可能误解或忽略文字说明，而钩子可以在某项操作执行前将其拒绝。团队如今需要决定：哪些预期应写入提示词，哪些则需要可执行的控制措施。

Tessl 编程智能体护栏将一条提示词划分为四个层次

Tessl 的关键做法，是按照加载时机、控制对象以及智能体能否忽略，将指导内容分离开来。

这套四文件框架从 CLAUDE.md 开始。这个代码仓库文件为 Claude Code 提供持久化的项目上下文。适合放入其中的内容包括构建命令、架构边界、目录约定和测试预期。

这一层应描述智能体在许多任务中都需要了解的事实。它可以说明某项服务使用特定的包管理器，或数据库迁移只能追加、不能修改。它也可以指出用于验证改动是否有效的命令。

第二层将聚焦规则放在 .claude/rules/ 中。规则可以包含路径模式，用于确定其指令何时进入活跃上下文。例如，API 验证策略只会在智能体触及 API 处理程序时出现。

路径范围限定解决了大型指令文件带来的实际问题。处理文档的智能体无需在上下文中载入每一条后端约定。加载无关内容会消耗 token，并与当前任务真正重要的指令争夺注意力。

第三层将可复用能力存放在 .claude/ 下。技能是包含 SKILL.md 文件、指令、脚本和支持资源的文件夹。它们将智能体或开发者可在相关情境下调用的流程打包起来。

发布检查清单说明了其中的区别。代码仓库概览可以说明发布如何进行，但完整步骤应归入发布技能。这样可以避免在日常编程会话中加载冗长的流程。

第四层使用钩子来处理应在既定生命周期事件中触发的操作。钩子可以检查拟议的工具调用、在编辑后运行格式化工具，或阻止危险命令。其配置通常位于设置或相关项目文件中。

这种分离改变了“智能体指令”的含义。这些文件不再构成一条要求模型记住所有内容的大型提示词，而是成为具有不同加载和执行行为的独立控制措施。

Anthropic 自身的引导指南也支持这种分配方式。该指南区分了始终加载的上下文、路径范围规则、按需流程、隔离的子智能体和生命周期自动化。

Tessl 则将这一更广泛的工具组合聚焦为一个关于代码仓库所有权的论点。模型提供商仍负责模型和智能体运行时，而开发团队拥有那些规定智能体应如何在其代码库中运行的文件。

这种所有权让控制层可被审查。团队可以通过拉取请求审核改动、比较版本、指定维护者，并回滚有害规则。聊天记录很少能提供同样清晰的操作视角。

这些文件也可以随项目一起流转。新贡献者克隆代码仓库时即可获得共享约定。全新的智能体会话也能恢复同样的指令，无需依赖他人此前的对话。

该框架并未消除模型的不确定性。它将不确定性组织为团队可以独立测试的不同层次。这才是更重要的变化。

压力落在将 CLAUDE.md 当作策略引擎的团队身上

一份冗长的指令文件可以引导智能体，但无法可靠地充当访问控制系统。

许多团队从一个 CLAUDE.md 开始，因为它会立即带来改进。智能体不再猜测常用命令，能遵循既定命名模式，也获得了代码仓库的基本地图。这些好处使得该文件很容易被过度延展。

当每个例外都变成又一段文字时，问题便会出现。安全要求、发布流程、前端约定、数据库限制和个人偏好都堆积在同一份文档里。于是每个会话都要承担上下文成本。

Anthropic 建议将根文件视为概览或索引。其现行指南建议将 CLAUDE.md 控制在 200 行以内，指定负责人，并像审查代码一样审核改动。这项建议反映的是注意力问题，而不仅仅是格式偏好。

每一条始终加载的指令，都会与源文件、任务细节、工具输出和最近对话竞争。更多指导并不保证更强的遵从性。拥挤的提示词可能让真正相关的要求更难被识别。

嵌套指令文件有助于将部分知识本地化。根据官方项目记忆文档，工作目录下的文件可以在 Claude 访问树状结构的相应部分时加载。这支持在单体仓库中为团队设置特定约定。

对于横跨多个部分的关注点，路径范围规则提供了更直接的选择。一条规则可以针对多个文件模式，而无需在多个目录中重复指令。它可以覆盖所有迁移文件，或分布于不同包中的每个 API 处理程序。

这种区别迫使工程负责人对要求进行分类。编程约定应属于上下文，因为判断仍有价值。可重复的工作流应属于技能，因为它需要有序步骤。被禁止的命令则需要更强的屏障。

如果不进行这种分类，CLAUDE.md 就会变成非正式的策略数据库。开发者可能认为写下“绝不修改生产配置”就建立了可靠边界。但事实并非如此。

智能体会在不断变化的上下文中解释文字。长会话、模糊指令、相互冲突的文件和提示词注入，都可能削弱遵从性。即便是能力强大的模型，在这些条件下也可能作出错误判断。

这一局限也会影响审计。审查者可以确认某个句子存在，却无法推断其实际执行率。规则可能被正确加载，却仍会在更直接的指令面前失效。

采用自主或无人值守工作流的团队面临的压力最大。受监督编程时遗漏一项约定，只会增加审查工作；而无人值守执行时遗漏一项安全限制，则可能修改文件、暴露数据或调用不希望执行的命令。

因此，该框架要求团队停止以文档大小衡量治理水平。更好的问题是：每项要求是否在正确的时刻以足够的权威性传达给智能体。

这个问题不局限于 Claude Code。其他编程智能体也以不同名称支持代码仓库指令文件、可复用工作流或基于事件的控制机制。具体路径各不相同，但设计问题始终一致。

代码仓库需要简洁的上下文、选择性流程、有限权限和可执行的边界。将这些功能混合在一条提示词中，会掩盖它们之间的差异。

建议性指令与确定性钩子并不等价

决定性的边界在于：是由模型自行选择遵从，还是由运行时阻止不遵从。

CLAUDE.md 中的声明会影响模型的下一次决策。规则文件也能发挥相同作用，只是目标定位更精准。技能提供可复用流程，但智能体仍需自行解释并执行该流程。

钩子则在另一层运行。Claude Code 会在定义的事件发生时触发它们，例如工具请求、文件编辑、会话开始或尝试完成任务。运行时会主动启动钩子，而不是等待模型记起它。

PreToolUse 钩子可以在命令执行前检查拟议命令。如果命令违反策略，命令钩子可以返回阻止结果。智能体随后会收到原因，并必须选择另一条路径。

官方钩子指南介绍了几种处理程序类型。命令处理程序执行脚本，而提示词和智能体处理程序则依靠模型判断。这一区别很重要，因为并非每个钩子都完全具有确定性。

始终会启动的钩子，在触发层面是确定性的。但如果由 LLM 评估请求，其决策仍可能是概率性的。团队应将基于命令的检查保留给软件可以直接评估的条件。

设想一个禁止修改生成文件的代码仓库。一条文字指令要求智能体避免修改它们。一条路径规则会在相关文件出现时重申这一预期。钩子则可以检查写入目标并拒绝该操作。

这些层次可以协同工作。指令说明代码仓库的设计，而钩子则防止已知的失效模式。智能体既获得上下文，也面对可执行的边界。

同样的模式也适用于命令。团队可以在技能中描述部署流程，然后通过权限或钩子阻止直接执行生产环境命令。技能提供获批路径，而控制措施防止走捷径。

编辑后钩子服务于不同目的。它们可以在智能体修改文件后运行格式化、代码检查或有针对性的验证。这种自动化减少了对智能体记住另一项检查清单条目的依赖。

完成钩子可以在智能体停止前测试必要检查是否已通过。不过，它们需要防止循环。一个反复要求智能体继续执行的失败停止钩子，可能消耗时间却无法改善结果。

钩子也将可执行代码引入控制平面。有缺陷的脚本可能阻止合法工作、泄露信息，或为每个匹配事件增加延迟。团队必须以审查构建和部署自动化时同等的谨慎程度审核钩子改动。

“你拥有的文件”这一说法因此有两层含义。它描述了可移植性和治理，但也意味着责任归属。团队必须维护这些文件、测试其效果，并保护它们免遭未经授权的修改。

这也是权限依然重要的原因。Anthropic 的权限控制支持针对工具和命令设置允许与拒绝规则。拒绝规则优先于匹配的允许规则。

钩子可以评估更丰富的条件，而权限则提供更直接的访问边界。若后果严重，二者都不应替代操作系统级隔离。

容器、受限凭据、分支保护和只读挂载仍是更强有力的控制手段。仓库文件位于这一更大防御体系之中。它们应当降低风险，但不应假装能够取代基础设施安全。

核心结论很简单：如果某项要求写的是“优先”，它可以作为指导；如果写的是“绝不能”，团队就应寻找可强制执行的控制措施。

Skills 将重复的 Agent 工作转化为可审查的仓库资产

Skills 之所以重要，是因为它们能将临时的提示习惯转化为团队可检查、测试和复用的流程。

开发者通常通过反复尝试发现有用的 agent 工作流。最终提示可能包含诊断命令、决策标准、格式要求和验证步骤。如果没有共享文件，这些知识就会消失在一次对话之中。

一个 skill 会将工作流保存在具名目录中。其 SKILL.md 包含元数据和说明，旁边的脚本或参考资料则为流程提供支持。仓库可以对整个包进行版本管理。

Claude Code 起初只加载 skill 的名称和描述。当该 skill 变得相关，或有人调用它时，完整内容才会进入上下文。官方 skill 文档 将这种行为定位为把冗长流程写入 CLAUDE.md 的替代方案。

这种加载模型带来了成本优势。详细的发布、迁移、审查和事故处理流程可以保持可用，而不会给每次会话增加负担。上下文从永久存在变为按需加载。

它也提升了可发现性。新工程师可以查看 skills 目录，了解团队已将哪些工作流正式化。这些文件揭示了组织对人类和 agents 的共同期望。

可审查性同样重要。聊天中被修改的提示难以审计，而被修改的 skill 会产生 diff。审查者可以在其进入日常使用前发现被移除的安全检查或新增的命令。

Skills 可以为确定性子任务包含脚本。迁移 skill 可以调用仓库自有的验证器，而不是要求模型重新实现验证逻辑。agent 负责判断，代码负责可重复的计算。

不过，skill 本质上仍是一套流程。它的存在并不能证明 agent 会在正确时机调用它。描述必须清晰说明该 skill 的适用场景，团队也需要测试来验证触发行为。

对于敏感操作，手动调用可以减少歧义。开发者可以明确请求发布审查，而不是依赖自动匹配。随后，skill 会提供一致的工作流。

能力也带来维护义务。命令名称、架构或部署系统变化时，流程会过时。可靠的 skill 需要负责人、示例和审查周期。

团队应警惕权威来源重复。如果同一要求同时出现在 CLAUDE.md、三条规则和两个 skills 中，后续修改就可能造成矛盾。agent 随后会收到所谓事实的多个版本。

更好的安排是让每项事实只有一个主要归属。根文件可以指向某项能力，而无需复制其完整内容。路径规则可以增加局部约束，而 skills 则负责多步骤流程。

这类似于普通软件设计。职责明确的小模块比一个全局配置对象更易于修改。agent 控制层同样受益于这种分离。

这种方法还可以保留组织知识。构建恢复、依赖升级和安全审查往往依赖少数资深工程师。将这些工作流编码后，未来会话也可以使用这些知识。

当技术证据分散在多个文档中时，这种关联尤其重要。可搜索的工程知识库可以支撑源材料，而 skills 则定义 agents 如何使用它。

两套系统解决的问题不同。知识存储保存事实和决策；skills 则将选定的知识转化为操作流程。

实际优势并不在于 agent 会突然变得毫无差错，而在于团队可以检查它期望 agent 遵循的流程。

文件所有权无法消除安全缺口

由仓库控制的护栏能够提升问责性，但仍容易受到冲突、篡改和执行不完整的影响。

第一个不确定性涉及指令优先级。项目可能包含根级指导、嵌套指导、路径规则、skill 指令、用户偏好和受管理的组织设置。这些层级可能彼此冲突。

团队可能认为仓库表达了一项政策，而开发者的个人配置却改变了实际行为。相反的问题也可能发生：中央政策可能阻止仓库所预期的本地工作流。

因此，配置可见性至关重要。开发者需要能够查看加载了哪些文件、匹配了哪些规则，以及哪些权限影响了一项决策。否则，失败看起来会像是随机发生的。

第二个不确定性涉及可变性。如果 agent 可以编辑约束自身的文件，控制平面就与普通代码共享同一信任边界。一项任务在修改邻近配置时，可能意外削弱某条规则。

关键控制措施应获得更强的保护。代码所有权、强制审查、受保护分支和只读执行环境可以增加未经授权修改的难度。敏感 hooks 不应依赖 agent 的善意。

第三个不确定性是可移植性。CLAUDE.md 获得了广泛认可，但 rules、skills、agents 和 hooks 的目录结构仍具有工具特异性。支持多个编程 agents 的仓库可能积累并行配置。

Tessl 有动力减少这种碎片化，因为其产品管理可复用的 agent 上下文和规范。因此，它的框架既反映了一种通用设计模式，也反映了特定的工具环境。

团队应将这两种主张区分开来。分层模型适用于不同的编程 agents；但具体文件路径和加载行为仍须针对每个运行时进行验证。

第四个不确定性涉及虚假的信心。一个 hook 可以拦截已知的命令模式，却可能遗漏等效操作。禁止某条 shell 命令的规则，未必涵盖能产生同样效果的脚本、包任务或外部工具。

控制措施需要对抗性测试。团队应通过替代语法、间接脚本和不同工具尝试执行被禁止的操作。只能通过原始示例测试的护栏仍然脆弱。

正当工作同样需要测试。过于宽泛的拦截可能阻止无害命令，或中断常见工作流。开发者随后可能请求例外、绕过控制，或彻底禁用它。

延迟带来了另一项权衡。每次编辑后运行格式化工具或许可以接受，但每次文件变化后都运行完整测试套件，会让 agent 无法使用。控制措施应与事件的成本和后果相匹配。

快速检查应贴近每次编辑执行。较大型的验证可以在提交前或完成前运行。昂贵的安全分析可能更适合专门的 skill、持续集成任务或隔离的审查 agent。

提示注入仍是严肃问题。agent 可能读取不受信任的 issue 文本、文档、生成产物或依赖内容。这些输入中的恶意指令可能与仓库指导相冲突。

确定性的权限和隔离执行可以减少潜在损害。仅靠提示指令无法建立安全边界，因为同一个模型同时解释可信与不可信文本。

因此，对 Tessl 提案最安全的解读应比其标题更为收敛。文件可以创建可维护的控制层，但它们本身无法保证安全自治。

三个信号将表明该框架是否站得住脚

下一项检验在于，团队能否衡量遵循度、可移植性和执行效果，而不是仅仅不断累积配置文件。

第一个信号是面向仓库指令的更好评估工具。团队需要可重复的任务，用于揭示 agent 是否遵循了规则、调用了正确的 skill，以及尊重了边界。

有用的评估应从干净环境开始。在多次运行中呈现相同任务，记录加载的配置，并比较产生的行动。这将暴露一次成功演示所掩盖的概率性失败。

如果评估成为常规，Tessl 的所有权论点就会更有说服力。仓库文件将更像可测试的软件资产。如果团队无法衡量结果，该框架就可能沦为效果不确定的提示文档。

第二个信号是围绕可移植能力格式的趋同。Skills 已经类似于跨工具打包标准，因为它们结合了元数据、指令和支持文件。Rules 和 hooks 的一致性仍然较弱。

可移植性将减少 Claude Code、Codex、Cursor 和其他 agents 之间的重复维护。它还让组织能够审查一个控制定义，而不是协调多个近似副本。

不过，表面上的可移植性并不足够。共享文件格式必须保留触发、权限、路径匹配和执行语义。相同的 Markdown 并不保证相同的行为。

如果 agent 供应商公布精确的加载和优先级规则，该框架将更值得信赖。如果每个运行时都以不同方式静默解释相同文件，仓库所有权就无法解决操作上的歧义。

第三个信号是指导与硬性政策之间更强的分离。Anthropic 已经区分面向模型的指令与 hooks、权限、受管理设置和系统隔离。团队现在需要让这种区别可见的工具。

政策界面应标识哪些控制措施只是建议、哪些始终触发，以及哪些实际会阻止操作。审计日志应显示为何允许或拒绝某条命令。

如果开发者能够将每项重要限制追溯到可强制执行的层级，这一信号将强化该框架。如果敏感政策仍埋藏在散文中，该框架就会被削弱。

工程团队眼下的行动并不是一次性创建全部四层。他们应盘点现有指令，并按功能对每项陈述进行分类。

项目事实和常用命令应放入简洁的持久上下文。文件特定约定应放入作用域规则。重复流程应放入 skills。被禁止的操作应放入权限、hooks 或更强的系统控制中。

这种分类为 Tessl 编程 agent 护栏提供了一个实用测试：另一位工程师能否检查仓库，并解释什么在指导 agent、什么按需激活，以及什么无法被绕过？

如果答案不明确，仓库还没有控制层，它只有一组提示。两者之间的区别将决定编程 agents 是成为可靠的协作者，还是仅仅成为更快的审查工作来源。