为 agent 配置做版本管理：不要把指令当作一次性消耗品

Nobody versions their agent configs, and everybody pays for it. The config files that steer AI agents in your repos are infrastructure: they change behavior, they break silently, and they interact with external tools whose formats move. Infrastructure without versioning means every incident is an archaeology project. Here is the minimal discipline that fixes it. Why configs specifically need this Three properties make agent configs version-critical in a way ordinary docs are not: They cause behavior. A config change is a behavior change across every future agent session. "Just tweak the rules" deserves the same review as "just tweak the retry logic." Their semantics are set externally. Claude Code's import rules, Cursor's frontmatter schema, Copilot's instruction handling, these evolve upstream. Your file can break without your repo changing. They are shared. The moment a team relies on them, "works on my machine" extends to "works with my uncommitted local edits." The four artifacts 1: Semver on the config set One version for the whole config set, bumped on every deliberate change: Major: a rule changed that agents were relying on, expect behavior differences (conventions overhaul, removed rule). Minor: new rules, new scoped files, new coverage, additive. Patch: fixes that do not change intent, typo, broken glob, budget trim. Where the version lives: a header comment in AGENTS.md and a VERSION entry in the changelog. One grep finds it. 2: A changelog with behavior-level entries Not "updated rules", the entry says what an agent will do differently: ## [2.1.0], 2026-09-14 ### Added - Migration safety rules: forward-only, expand/contract, batch backfills. ### Changed - Test naming rule now scoped to test globs (was always-on), always-on budget drops ~15 lines. ### Fixed - 20-testing.mdc frontmatter had `alwaysApply: true` defeating the glob. Enter fullscreen mode Exit fullscreen mode Six months later, "why does the agent stop-and-plan now?" has a greppable answer. 3: A compatibility record One line per release: which upstream tool documentation the configs were validated against, dated. When Cursor changes frontmatter semantics and your rules misbehave, the compatibility record tells you whether your files predate the change. This is the artifact nobody keeps and everyone eventually needs. 4: An update procedure The update path matters more than the version number: Config changes arrive as PRs, reviewed like code. A validation gate runs structural checks (files present, budgets intact, frontmatter parses) before merge. Local, uncommitted config edits are treated as suspect, either promoted into the versioned set or deleted. Shadow configs are how teams end up with five different conventions again. The versioned-kit pattern Once configs have versions, changelogs, compatibility records, and an update procedure, they have become.. packages. The logical endpoint is to consume them like packages: versioned kits, installed per repo, updated by deliberate bump, local customizations living in a documented layer. That is the model AgentConfig Studio ships, semver releases, a changelog with behavior-level entries, a COMPATIBILITY.md matrix per release, and an idempotent installer so the update is one command and the rollback is a re-install of the previous version. If you'd rather not assemble this by hand: AgentConfig Studio on Gumroad ships this as version-pinned, validator-tested kits for 12 stacks. The complete Next.js/TypeScript kit is free (MIT) if you want to inspect the structure first.