当团队开始共享自己搭建的 Agent，第一个冒出来的麻烦就是版本管理。我们在构建 NewMax Agent-im 时得出的判断是：「Agent 的 GitHub」一定会出现，但它的形态会更接近 Docker Registry、可分支数据库、企业身份系统和 CI 的组合，因为 Agent 里最难管的 memory、secret 和权限，都超出了文本 diff 能处理的范围。本文记录这套思考：Agent 该怎么拆、哪些部分 link 哪些部分 fork、memory 怎么合并、企业需要怎样的「Agent Resource」基础设施，以及这件事为什么应该做成开放协议。
共享 Agent 时，版本问题从哪里来
一个能干活的 Agent 远不止一段提示词。它至少包含：
- 系统配置：system prompt、描述人格与原则的 soul.md
- 能力依赖：调用的 Skill、CLI、Connector 和各种 Tools（这几个概念的区别可以参考 MCP、Skill、连接器、CLI、Tool Call 有什么区别）
- 访问边界：在本机或云端能读写哪些资源
- 密钥：调用外部服务要用的 secret key
- 持续演化的状态：Agent 在每一轮 Loop 中会更新自己的 memory，甚至改写 system prompt
memory 本身还分两类。以剪辑 Agent 为例，剪辑美学、节奏感、基础剪辑能力属于共性 memory，任何剪辑 Agent 都用得上；专做游戏解说、专做混剪、专做鬼畜的 Agent，各自积累的专业知识属于特性 memory，彼此差别很大。
一个人用的时候，这些东西混在一起问题不大。一旦多人、跨团队协作，问题就集中爆发：基础能力升级了，下游怎么同步？我改了一条 memory，要不要推给别人？两个团队各自 fork 后又想合回来，diff 怎么 merge？我的密钥会不会跟着 Agent 一起被分享出去？
把 Agent 拆成四类东西，分别管理
用同一套 fork/link 规则去管整个 Agent，一定会出问题，因为它的各个组成部分性质完全不同：
| 类别 | 包含 | 性质 | 适合的管理方式 |
|---|---|---|---|
| 定义 | system prompt、soul.md、编排逻辑 | 人写的、确定的文本 | Git 式管理，可以 diff |
| 依赖 | Skill、CLI、Connector、Tools | 外部能力包 | 包管理器方式：link + 锁定版本（semver + lockfile） |
| 状态 | 共性 memory、特性 memory、会话 memory | 机器写的、持续增长、合并要靠语义判断 | 数据版本管理：分层、可分支、记录来源 |
| 环境绑定 | secret、权限范围、本机/云端 | 跟部署环境走，与 Agent 本身无关 | 不进版本库，只声明需求，由环境授予 |
其中最关键的一条原则：secret 和权限永远不该被 fork。 这一点可以借鉴 12-Factor App 的配置分离和 Android 的权限模型。Agent 包里只写「我需要一个对剪辑素材库有只读权限的凭证」，团队里谁装上这个 Agent，就由谁的环境把自己的凭证绑上去。光靠这一条，就能消掉一大半协作冲突。
Link 与 Fork 的分界：分层叠加
整体复制一份 Agent 再各改各的，很快就会失控。更好的模型是 Docker 镜像式的分层：
graph BT A["基础层：剪辑通用能力<br/>美学/节奏/剪辑基础"] --> B1["专长层：游戏解说"] A --> B2["专长层：混剪"] A --> B3["专长层：鬼畜"] B1 --> C["团队层：某工作室风格"] C --> D["实例层：个人记忆+凭证"]分层之后，规则就清楚了：
- 下层 link，上层 fork。 基础层对下游只读，上游更新后下游自动继承，相当于
FROM editor-base:2.x。 - 解析顺序参考 CSS 层叠规则。 越上层优先级越高。鬼畜层可以声明「允许打破节拍规则」，覆盖基础层默认规则，基础层本身一个字都不用改。
- 会话 memory 和个人 memory 不参与共享。 它们只存在于实例层，既涉及隐私，也容易污染别人的上下文。
落到各个组成部分，默认策略如下：
| 组成部分 | 默认策略 | 说明 |
|---|---|---|
| soul / 人格 | fork | 继承后允许覆盖 |
| Skill / CLI / Tools | link + 锁版本 | 不锁版本的话，上游一升级，所有下游行为都会悄悄改变 |
| Connector | 定义 link，凭证本地绑定 | 共享接入方式，不共享身份 |
| 共性 memory | link | 下游想改就给上游提 PR，禁止就地修改 |
| 特性 memory | fork | 归各专长层或团队所有 |
最难的部分：memory 怎么合并
代码冲突是字面冲突，memory 冲突是语义冲突。一个分支写「转场要卡在节拍上」，另一个分支写「纪录片避免卡点」，文本 diff 看不出任何问题，实际上两条规则互相矛盾，只是适用范围不同。要让 memory 可合并，需要在设计上做三件事。
1. 把 memory 原子化、结构化
一整篇 memory.md 没法 review，也没法回滚。每条 memory 应该是一个可寻址的单元，带上元数据：
id: mem_8f3ascope: specialty/game-commentary # 所属层source: loop#1243, task:剪辑《黑神话》P3 # 来源，可追溯author: agent | human:aliceconfidence: 0.7supersedes: mem_2c1e有了 scope 和 supersedes，合并就从「文本合并」变成「集合运算 + 冲突检测」：可以拆解、可以逐条审核，也可以精确回滚。
2. Loop 中的自我更新等于自动 commit，不能直写主干
Agent 每轮 Loop 产生的更新，先落到自己的实例分支，再沿晋升链路逐层上行：
实例分支 → 团队层（团队 owner 审核）→ 专长层 → 基础层（证明能泛化，才算共性知识）
把特性经验提炼成共性能力的这一步，需要人或者专门的 Agent 来做，本质上是一条知识蒸馏工作流。
3. 用评测集拦住合并
代码 PR 有 CI 测试兜底，Agent 的 PR 需要评测集兜底。每一层维护一组 golden set，memory 或 prompt 的任何变更都要先跑回归，确认「游戏解说层的改动没有拖垮基础剪辑能力」才能合并。所以「Agent 的 GitHub」最核心的资产会是评测集，diff 视图反倒是次要的。
Agent Resource：企业需要怎样的基础设施
企业有 HR 管人，Agent 多了以后，也需要一套 Agent Resource（AR）来管 Agent。把 HR 的职能逐项映射过来，基本就能推导出需要哪些基础设施：
| HR 职能 | AR 对应 | 需要的 infra |
|---|---|---|
| 工号 / 身份 | Agent 有独立身份，不借用人的账号 | Agent IAM：工作负载身份、短期凭证、委托链（代表谁在做事） |
| 入职 / 离职 | 开通权限、签发凭证；离职时吊销凭证、交接 memory | 凭证生命周期管理、memory 归档与脱敏 |
| 汇报线 | 每个 Agent 都有负责的人类 owner | 组织目录，相当于 Agent 版 LDAP |
| 绩效考核 | 成功率、返工率、成本、事故数 | 可观测性 + 持续评测 |
| 薪酬 / 预算 | token 成本、调用配额 | 计量、预算控制、限流 |
| 岗位调动 | 换团队 = fork 一份，并清洗不能带走的 memory | memory 数据分级与权限标签 |
| 合规审计 | 访问过什么数据、执行过什么操作 | 不可篡改的行为日志 |
| 内部人才市场 | 按能力检索、复用已有 Agent | Registry，附签名与来源证明 |
| 开除 | 紧急熔断 | 一键停用 + 全局吊销凭证 |
其中「汇报线」和「谁说了算」在多人共用 Agent 时尤其容易出问题，多人共用 AI Agent 为何失灵？ 专门讨论过决策权的设计。
从底向上看，AR 的基础设施大致分七层：
- 身份与凭证层：最底层，也是企业安全团队最先卡住的一层
- 打包规范层：类似
Agentfile的声明式描述 - Registry 层：分层存储、签名、版本解析
- 状态层：可分支、可追溯来源的 memory 存储
- 评测层：合并前的回归测试，也是晋升链路的关卡
- Runtime 与策略层：沙箱和执行权限策略
- 观测与治理层：审计、成本、目录，也就是 AR 的控制台
为什么要做成开放协议
如果这套东西只给 NewMax 自己用，真正的风险在于用户不敢把资产放进来。团队花几个月训练出来的 Agent 和 memory，如果只能在一个产品里运行，企业采购时会直接把它当成锁定风险。格式开放了，用户才愿意把最有价值的 memory 存进来。
现有标准已经覆盖了一部分
截至 2026 年，Agent 生态里已有不少标准在推进（部分信息来自社区资料，细节以各项目官方规范为准）：
| 层 | 现状 |
|---|---|
| Skill 格式 | Agent Skills（SKILL.md）已是开放规范，归 Linux Foundation 下的 AAIF（Agentic AI Foundation）管理 |
| 工具接入 | MCP，事实标准 |
| Agent 间通信 | A2A，同样归 AAIF |
| 项目说明 | AGENTS.md |
| 能力打包 | Agent Plugins 1.0（OpenAI 牵头，Working Draft），用 plugin.json 把 skills 和 mcp.json 打成一个包 |
| Agent 定义 | Oracle 的 Open Agent Spec、社区的 ADP 等提案，尚未形成共识 |
| Memory | 没有标准，Mem0、Letta、Zep 各用各的 schema |
对照前面的四类划分：依赖层基本已标准化，定义层有人在抢，状态层（memory）和环境层的声明方式仍是空白。团队协作中最痛的版本问题，恰好集中在这块空白上。
协议只做最薄的一层
值得写进协议的只有三样，并且尽量薄：
- Agent 组合清单（Agentfile）：
from继承、分层、lockfile、requires_secrets、权限声明、评测集位置。Skill 和 Connector 部分直接引用 Agent Skills、Agent Plugins、MCP，不重复定义。 - Memory 原子格式：id、scope、source、author、confidence、supersedes 和来源追溯。
- 层叠解析规则：多层冲突时谁覆盖谁。这一条必须写成确定规则，否则同一个包在不同 runtime 上会跑出不同行为。
一个 Agentfile 的样子大致如下：
# Agentfilefrom: newmax/editor-base@^2.1soul: ./soul.mdskills: - newmax/beat-sync@1.4.2connectors: - feishu-drive: { scope: read }requires_secrets: [FEISHU_TOKEN] # 只声明，不存值permissions: { fs: ./footage/**, network: [api.feishu.cn] }memory_layers: [base, specialty/game-commentary]evals: ./evals/memory 的语义合并算法不进协议。协议只规定数据长什么样、冲突怎么标记，合并得好不好留给各家实现去竞争。
开放与保留的分界
| 开放（协议） | 保留（产品能力） |
|---|---|
| Agentfile schema、lockfile | Loop 中的自动晋升与蒸馏 |
| Memory 原子格式 + 来源追溯 | memory 语义合并与冲突解决的质量 |
| 层叠解析规则 | 评测流水线、晋升审批流 |
| 权限和 secret 的声明方式 | 托管 Registry、企业版 AR 控制台（身份、审计、预算） |
Docker 把镜像格式捐给 OCI，收入来自 Hub 和企业版；Git 是开放的，GitHub 靠 PR、Actions 和协作体验赚钱；Hugging Face 的模型格式开放，平台成了默认去处。三者走的是同一条路。
标准的胜负看采用量
一家公司单方面宣布的「通用协议」，大多没人用。比较现实的路径分三步：
graph LR A["1. 内部格式<br/>按开放标准设计"] --> B["2. 公开规范<br/>+ 导入导出工具"] B --> C["3. 提交 AAIF<br/>或做成 Plugins 扩展"]- 先在内部按开放规范设计：schema 带版本号，核心字段不放专有内容，专有字段统一收进
x-newmax.*命名空间；Skill 直接用 SKILL.md，工具直接用 MCP。 - 产品验证后公开规范：开源规范和参考 CLI（
agent pack / diff / promote），同时支持从 Claude Code、Codex、Cursor 导入导出。能一键迁进来，比能迁出去更能带来用户。 - 有了采用量再推标准化：以 Agent Plugins 扩展或 AAIF 提案的形式推出，让参考实现成为别人绕不开的那一份。
小结
Agent 的版本管理问题，根源在于它把四种性质不同的东西装在了一起。拆开之后，各用各的工具：定义层用 Git 管，依赖层用包管理器管，状态层用数据库管，环境层用 IAM 管，合并统一靠评测拦住。 企业侧再往上叠一层 Agent Resource，负责身份、预算、审计和熔断。
对 NewMax Agent-im 来说，最大的优势是 Loop 本身就跑在自己的 runtime 里，memory 的每一次改写都发生在这里，这是纯存储平台拿不到的位置。接下来要落地的几件事很具体：定义 Agent 包格式、memory 原子化并加上 scope、生成 lockfile、在 Loop 中为高置信度 memory 自动生成「建议晋升」PR 并附评测结果、分享时自动剥离 secret 和实例层 memory。
最终想做到的是：别人的 Agent 都能在 NewMax 里跑，NewMax 的 Agent 也能导出去跑，而 Agent 在 NewMax 里会越用越聪明。