商业客户端Harness资产管理与应用实践

导读

多产品线、多 Agent、多设备，商业客户端的 Rules、Skills 等 Harness 资产散落部署，配置漂移、规则冲突渐成隐性技术债。本文复盘了 ACX 资产部署从单文件同步到仓库整体插件化的四阶段演进，提出「ACX 唯一事实源 + 三层资产治理 + 每日自动同步」的工程实践，为规模化落地 Agent 研发模式提供了可复制的资产管理范式。

01 背景：商业客户端为什么需要 Harness 资产管理

商业客户端面对的并不是单一仓库、单一 IDE 或单一 Agent 的局部问题，而是多产品线、多端、多 Agent、多台 Mac 本地部署，以及 Rules、Skills、Hooks、MCP、配置文件、提示词模板等多种 Harness 资产长期并存的系统性治理难题。不同业务的技术栈、研发流程、权限边界和发布节奏各不相同，各类 Agent 与 IDE 的能力和配置格式也存在差异；同时，本地环境分散在大量开发设备上，极易出现版本不一致、配置漂移、重复建设、资产失效和规则冲突等问题。一项资产从创建、评审、发布、分发到升级、回滚和下线，往往涉及复杂的依赖关系与适用范围，既要保证统一规范、安全合规和变更可追溯，又要为各产品线保留必要的定制空间。因此，商业客户端需要建立统一的资产目录、版本管理、兼容性校验、灰度分发、效果度量和生命周期治理机制，否则 Harness 资产规模越大，维护成本和协作复杂度越高，并最终演变为难以识别和治理的隐性技术债。

1.1 挑战：多维度与高复杂度

• NAD是Native Ad的缩写，表示原生广告客户端；
• ACX是AI Coding Extension的缩写，也是商业客户端Harness资产git仓库的名字，本文中的"ACX资产"与"商业客户端Harness资产"是等价概念。

1.1.1 多产品线与多端形态

商业客户端覆盖手百、好看、贴吧、SDK 等多产品线，同时涉及 Android、iOS、HarmonyOS、跨端模板、广告 SDK、业务知识库、日志规范、计费链路、组件化约束等多类上下文资产。

这些资产具有几个典型特点：

• 通用规范与端侧规范并存：例如通用代码规范、日志/计费规范、组件化规范，与 Android Activity、iOS 页面、HarmonyOS 能力适配等端侧规范并存。
• 业务知识与工程流程并存：既有产品形态、广告样式、MRD 解读、测试说明，也有 Git、CR、发版、回归、开源、证书配置等研发流程。
• 规则更新频繁：广告产品与研发工具链持续变化，规范和 skill 需要每日或高频同步。
• 适用范围不同：有些规则需要全局生效，有些只应在特定文件、特定端、特定 skill 被触发时进入上下文。

如果把所有内容都递归加载到模型上下文，会带来 token 污染、规则冲突、误触发；如果只靠人工复制，又会导致漏装、过期和多端不一致。

1.1.2 多 Agent 并存

商业客户端当前至少要兼容 Claude Code、Codex 等研发 Agent。问题在于：不同 Agent 对"规则"和"技能"的定义并不一致。

• 在 Claude Code 里，CLAUDE.md / .claude/rules/*.md 是模型行为上下文，.claude/skills/<skill>/SKILL.md 是按需加载的能力包。
• 在 Codex 里，AGENTS.md 是 instruction discovery 的核心入口；官方 ~/.codex/rules/*.rules 是命令执行策略，不是 Markdown 行为规范。
• 在 Codex skills 里，SKILL.md 的 YAML frontmatter 负责 name / description，UI、策略、依赖等更多元信息在 agents/openai.yaml。
• 在 Claude Code skills 里，SKILL.md 的 description 影响触发，allowed-tools 在 CLI 里可生效，但在 Agent SDK 中不生效，SDK 需要用 allowedTools 控制。

因此，ACX 资产管理要解决的不只是"文件放哪里"，而是"同一份资产如何被不同宿主按正确语义加载"。

1.1.3 跨 Mac电脑本地部署

商业客户端同学通常在本地 Mac电脑上使用 Agent。每台机器都有自己的：

• ~/.claude、~/.codex 配置目录；
• SSH、Git、iCode 权限；
• sandbox / permissions / hooks 配置；
• 本地安装过的第三方 skill、系统 skill、用户自定义 rule。

这要求部署链路具备：

• 低成本初始化：新机器、新 Agent、新 profile 下能快速安装；
• 可重复执行：每天首次会话自动更新，重复运行不会无限追加配置；
• 迁移保护：不能粗暴覆盖用户已有 rules/skills；
• 兼容多宿主语义：团队内 Harness 资产跨 Agent 生效，非团队资产保留宿主差异化配置；
• 可诊断可恢复：本地仓库脏状态、manifest 错误、注册失败、软连接迁移失败都要能明确中止。

02 多agent的rules、skills管理差异

2.1 Codex 的 rules、skills 与上下文进入方式

参考：

• OpenAI Codex AGENTS.md：https\://developers.openai.com/codex/guides/agents-md
• OpenAI Codex rules：https\://developers.openai.com/codex/rules
• OpenAI Codex skills：https\://developers.openai.com/codex/skills

2.1.1 AGENTS.md：Codex 的行为指令入口

Codex 会在任务开始前构建 instruction chain，主要来自全局与项目内的 AGENTS.md 类文件。

关键机制：

• 全局范围 ：默认从 ~/.codex 读取；如果设置 CODEX_HOME，则使用对应目录。AGENTS.override.md 优先于 AGENTS.md。
• 项目范围：从项目根目录一路扫描到当前工作目录；越靠近当前目录的文件越后进入上下文，优先级更高。
• 同目录选择 ：通常按 AGENTS.override.md、AGENTS.md、配置的 fallback 文件名顺序选择，同一目录最多纳入一个文件。
• 容量限制：项目 instruction discovery 有默认字节上限，内容过大时会停止继续纳入。
• 变更生效：修改配置或 instruction discovery 相关文件后，通常需要新 session 或重启 Codex 才能稳定验证。

对 ACX 的启示：Codex 的 Markdown 行为规范入口应是 AGENTS.md 或 Codex 插件机制暴露出的 instruction 入口，不是官方 ~/.codex/rules。

2.1.2 Codex rules：命令策略，不是 Markdown 行为规范

Codex 官方 rules 用于控制 Codex 在沙箱外可以运行哪些命令。它的典型形态是：

• 存放在配置层旁边的 rules/ 目录；
• 文件扩展名是 .rules；
• 使用 Starlark 语法；
• 通过 prefix_rule() 等规则匹配命令参数前缀；
• 决策结果可以是 allow、prompt、forbidden；
• 多条命中时取更严格结果。

这类 rules 不会作为普通 Markdown 指令进入模型上下文，而是在 Codex 准备执行命令时被客户端策略层评估。

因此，ACX 文档里必须明确区分：

• ~/.codex/rules/*.rules：Codex 命令执行策略；
• ACX 仓库内 rules/**/*.md：商业客户端 Markdown 行为规范；
• Codex 插件壳或 AGENTS.md bridge：让 Codex 按 ACX 规则语义理解 Markdown 行为规范。

2.1.3 Codex skills：渐进式加载

Codex skill 是一个目录，核心是必需的 SKILL.md：

my-skill/  SKILL.md  scripts/        # 可选  references/     # 可选  assets/         # 可选  agents/    openai.yaml   # 可选

SKILL.md 至少包含：

---name: skill-namedescription: 说明何时触发、何时不触发---具体执行说明。

Codex skills 的上下文加载是渐进式的：

1. 初始上下文只包含 skill 的名称、描述、路径；
2. 当 Codex 判断某个 skill 与任务相关，或用户显式触发时，才读取完整 SKILL.md；
3. 初始 skills 列表有上下文预算限制，skill 太多时会压缩描述或省略部分；
4. agents/openai.yaml 可用于 UI 展示、调用策略、工具/MCP 依赖等配置，例如 allow_implicit_invocation。

对 ACX 的启示：skills 应保持 description 短而准；复杂材料放到 references/scripts，不要把全部知识塞进 SKILL.md 的描述区。

2.2 Claude Code 的 memory/rules、skills 与上下文进入方式

参考：

• Claude Code memory：https\://code.claude.com/docs/en/memory
• Claude Agent SDK skills：https\://code.claude.com/docs/en/agent-sdk/skills

2.2.1 CLAUDE.md 与 memory：启动时进入上下文

Claude Code 使用 CLAUDE.md 承载持久行为指令。官方文档强调：CLAUDE.md 是上下文，不是强制执行配置；如果要阻断工具行为，应使用 hooks 或 settings。

常见加载范围包括：

• 组织托管策略：macOS /Library/Application Support/ClaudeCode/CLAUDE.md 等；
• 用户级：~/.claude/CLAUDE.md；
• 项目级：./CLAUDE.md 或 ./.claude/CLAUDE.md；
• 本地项目偏好：./CLAUDE.local.md。

加载顺序通常从广到窄、从上层目录到当前目录；越靠近工作目录的内容越后进入上下文。CLAUDE.md 支持 @path/to/file 导入，但导入内容同样会占用上下文。

2.2.2 .claude/rules/*.md：可模块化、可路径限定

Claude Code 支持在 .claude/rules/ 中放置多份 Markdown rules。

关键机制：

• .claude/rules/ 下的 .md 文件会被发现；

• 没有 path-scoped frontmatter 的规则会在启动时进入上下文；

• 带 YAML frontmatter 的路径规则可以只在 Claude 处理匹配文件时进入上下文；

• 官方示例字段是 paths，例如：

  ---paths: - "src/api/**/*.ts"---# API Development Rules

• 用户级规则可放在 ~/.claude/rules/，项目规则可放在项目 .claude/rules/；

• 大仓库可通过排除配置避免不相关规则递归进入上下文，降低上下文污染。

2.2.3 Claude Code / Agent SDK skills：发现 metadata，触发后加载全文

Claude skills 也是文件系统资产，核心是 .claude/skills/<skill>/SKILL.md。

官方 Agent SDK 文档描述的机制是：

• skills 从文件系统发现，受 settingSources / setting_sources 控制；
• 默认会发现用户级、项目级、插件提供的 skills；
• 启动时发现 skill metadata，触发后加载完整内容；
• 模型根据 description 自主选择是否调用；
• SDK 的 skills 选项只是上下文过滤，不是 sandbox；未列出的 skill 对模型不可见，但文件仍在磁盘上；
• allowed-tools frontmatter 只在 Claude Code CLI 中支持，SDK 场景要通过主请求的 allowedTools 控制。

当前 ACX nad-acx-init 的 SKILL.md 采用标准 YAML frontmatter，并声明 name、description、allowed-tools、autoInstall、autoUpdate、localDebug 等字段。其中前三类字段面向宿主/skill 触发，后三类是 ACX 安装器自定义的资产安装策略。

2.3 Claude Code 与 Codex 对 frontmatter/meta 的关键差异

这里的 frontmatter/meta 可以分成四类，不能混用。

几个容易踩坑的点：

1. Codex rules 不是 Claude rules 的等价物Codex 官方 rules 是命令策略，不会自动把 Markdown 规范塞进模型上下文。ACX 必须通过 Codex 可识别的 instruction/plugin 入口暴露 Markdown 行为规则。
2. description是 skill 触发质量的核心字段 Claude Code 和 Codex 都会使用 description 做 skill 发现与隐式匹配。过宽会误触发，过窄会漏触发。
3. allowed-tools 不是跨宿主通用 meta Claude Code CLI 支持 allowed-tools frontmatter；Claude Agent SDK 不支持；Codex 也不应把它理解为同一套权限系统。权限应交给宿主 settings、rules、hooks 或安装器处理。
4. ACX 自定义安装字段不是模型行为字段 autoInstall、autoUpdate、localDebug 是 nad-acx-init 的安装控制字段，脚本读取它们决定是否安装或覆盖文件，不要指望模型直接因为这些字段改变行为。
5. root-level 与子目录 rules 要分层root-level rules 适合做全局入口和强约束；子目录 rules 更适合由具体 skill 或文件场景按需加载。插件化后，分层关系应体现在 manifest 分类、宿主加载入口和 skill 触发策略里，而不是靠共享目录全量递归。

03 ACX 资产部署方案演进

nad-acx-init 是ACX资产本地部署初始化/更新的skill，部署方案的演进，可以理解为nad-acx-init skill的演进：从"帮一个 Agent 装一组文件"的工具，逐步升级为"把 ACX 仓库注册成多 Agent 可识别插件源"的插件化入口。

3.1 第一阶段：单 Agent 文件同步

早期部署方式面向单 Agent、单目录：用户选择 Android / iOS / HarmonyOS，Agent 通过 iCode MCP、iCode skill 或 icode-cli clone 获取仓库资产，再写入本地 ~/.claude/rules 和 ~/.claude/skills。后续引入 git sparse-checkout + cp -rf，把远程逐文件读取收敛为本地批量复制。

优点

• 初期实现简单，适合快速验证 rules/skills 的价值；
• 可以按端选择，避免一次安装太多内容；
• sparse checkout 后安装效率显著提升，Tool calls 明显减少。

问题

• 安装结果只面向 ~/.claude，无法天然兼容 Codex；
• 用户需要选择端，跨端任务容易漏装；
• 资产越多，复制和冲突处理成本越高；
• Agent 逐文件或半自动操作失败后，恢复路径不稳定。

迭代理由

商业客户端资产数量增长后，逐文件复制不可持续；安装逻辑必须从模型操作收敛为可重复、可诊断的脚本。

3.2 第二阶段：脚本化安装与动态资产同步

这一阶段把安装逻辑独立为 install.sh，SKILL.md 只保留触发说明与执行入口。脚本负责 sparse clone、动态扫描 rules/*/ 与 skills/*/、root-level rules 安装、skill 扁平化、同名 skill 冲突检测、自更新和每日自动 init。

代表性能力包括：

• 单次 Bash 完成 clone、安装、校验；
• 规则后缀统一为 .md，贴近 Claude/Codex Markdown 生态；
• root-level rules 作为全局入口，子目录 rules 用于端侧或专项场景；
• autoInstall、autoUpdate、localDebug 控制 skill 是否安装、是否覆盖、是否保留本地调试版本；
• 每日首次会话自动执行 nad-acx-init，成功后写入日期标记，失败则下次重试。

优点

• 安装动作从多次工具调用收敛为一个确定性脚本；
• 新增目录无需改脚本，适合 common、android、ios、harmony、tools 等分类持续扩展；
• 自更新机制保证用户本地脚本可以跟随仓库升级；
• 安装控制字段保护本地调试和灰度能力。

问题

• 本质仍是"复制仓库资产到用户目录"；
• 本地存在两份 ACX 资产：仓库一份，~/.acx 或宿主目录一份；
• rules/skills 的"安装"与"进入上下文"仍容易被混淆；
• 多 Agent 接入时，不同宿主的目录语义开始互相牵连。

迭代理由

需要解决多 Agent 共享、宿主差异、上下文污染和本地双份资产的问题。

3.3 第三阶段：~/.acx 中枢与多 Agent 软连接

随后 nad-acx-init 使用 ~/.acx 作为统一中枢目录，Claude Code / Codex 通过软链接接入：

~/.claude/skills --symlink--> ~/.acx/skills~/.claude/rules  --symlink--> ~/.acx/rules~/.codex/skills  --symlink--> ~/.acx/skills~/.codex/AGENTS.md  --bridge--> ~/.acx/rules

同时，脚本维护两类兼容配置：

• Claude Code ：通过排除配置避免 ~/.acx/rules/*/*.md 这类子目录 rules 全量递归进入上下文；
• Codex ：通过 AGENTS.md bridge 让 Codex 理解 ACX Markdown rules，而不是误用官方 .rules 命令策略。

优点

• 一份本地安装资产，多 Agent 共享；
• 用户不用分别维护 ~/.claude 和 ~/.codex；
• Codex 的 Markdown 行为规范通过 bridge 进入上下文；
• 子目录 rules 默认不自动加载，降低 token 污染。

问题

• 多 Agent 的 rules、skills 目录仍然容易混用；
• ~/.acx 中既可能有 ACX 仓库资产，也可能有非 ACX 技能，边界不清；
• ACX 仓库与 ~/.acx 形成双份资产，修改、调试、更新链路不统一；
• 软连接不是插件生命周期，无法表达"插件身份、来源、版本、启用状态、分类、更新策略"；
• 新增宿主时还要继续补一套目录映射和 bridge 逻辑。

迭代理由

软连接方案解决了"多 Agent 能看到资产"，但没有解决"宿主按插件身份管理资产"。最终形态应让 ACX 仓库本身成为插件源，而不是把仓库内容复制到共享目录。

3.4 第四阶段：ACX 仓库整体插件化

最新版本不是新增一个独立插件目录，而是把ACX git仓库整体改造成 Claude Code 与 Codex 都能识别的本地插件源。迭代完成后，ACX 不再表现为散落在用户目录里的 rules/skills 文件集合，而是一个具备明确插件身份、宿主加载边界和自动更新闭环的团队 Harness 资产包。

迭代后的核心效果

1. ACX 仓库成为唯一事实源，rules、skills、manifest、init 脚本都在 ACX 仓库内迭代。用户本地不再长期维护一份从仓库复制出来的 ACX 资产目录，减少"仓库已经更新但本地资产没同步""本地改了但不知道源头在哪"的割裂。
2. Claude Code 与 Codex 都按插件身份识别 ，ACX仓库根目录提供 .claude-plugin/plugin.json 与 .codex-plugin/plugin.json，两个 manifest 分别适配宿主插件协议。宿主看到的是 acx 插件，而不是一批没有来源信息的 Markdown 文件和 skill 目录。
3. 团队资产与个人资产边界更清晰，ACX 仓库内的 rules/skills 代表团队 Harness 资产，适合跨 Claude Code 与 Codex 生效；用户个人安装的第三方 skill、个人 rule 和本地偏好留在对应宿主自己的默认目录里。这样既能统一团队规范，又不会把个人资产混进 ACX 发布链路。
4. 加载方式从目录复用升级为宿主原生插件机制 ，Claude Code 侧通过 marketplace/settings 发现并启用 acx@acx；Codex 侧通过 personal marketplace 识别本地 acx 插件源。宿主各自按自己的插件协议处理发现、展示、启用和后续加载，减少软连接方案下的目录语义混用。
5. 每日自动更新从"复制文件"升级为"更新插件源" ，nad-acx-init 保留每日自动更新入口，但更新对象变成完整 ACX 仓库与插件注册状态：仓库可更新，插件壳可校验，宿主注册可幂等维护。用户仍然获得无感更新体验，但资产来源更明确，问题诊断也更集中。
6. 后续扩展有统一落点，新增 rule、skill、分类、宿主适配字段时，都优先落在 ACX 仓库和插件 manifest 中，而不是继续扩展散落的用户目录脚本。未来如果新增其它 Agent，也应按"新增宿主插件壳/注册入口"的方式接入，而不是继续共享一套全局软连接目录。

架构收益

• 从"文件同步"升级为"插件源治理"；
• 从"多宿主共用目录"升级为"多宿主各自按插件协议加载"；
• 从"仓库资产与本地资产双份维护"升级为"ACX 仓库唯一事实源"；
• 从"规则是否进入上下文靠目录副作用"升级为"manifest、宿主加载入口和 skill 描述共同决定"；
• 从"安装脚本负责搬文件"升级为"nad-acx-init 负责仓库更新、插件壳校验与注册状态维护"。

约束

• ACX 插件源必须指向本地完整 ACX 仓库，不能使用 /tmp sparse clone 作为长期插件源；
• 插件 manifest schema 以 Claude Code 与 Codex 的真实校验为准；
• nad-acx-init 只维护 ACX 插件相关配置，不覆盖用户已有 hooks、permissions、sandbox、model、env 等宿主配置；
• Codex 侧保持注册插件源，不在每日自动更新中执行可能触发交互的插件安装命令。

3.5 版本演进总表

04 ACX 插件化后的架构现状

插件化后的目标不是让所有宿主继续共享同一份 ~/.acx 目录，而是让 ACX 仓库作为团队 Harness 资产源，被不同宿主以插件方式识别。

acx├── .claude-plugin/│   └── plugin.json├── .codex-plugin/│   └── plugin.json├── rules/│   ├── *.md│   └── <category>/*.md├── skills/│   └── <category>/<skill>/SKILL.md└── skills/common/nad-acx-init/    ├── SKILL.md    └── install.sh~/.claude/plugins/marketplaces/acx/acx -> $ACX_REPO~/plugins/acx                         -> $ACX_REPO

4.1 ACX 仓库是唯一事实源

研发同学在 ACX 仓库中迭代 rules、skills、manifest 和 init 脚本。每日 init 只负责更新这份仓库并注册插件源，不再把 ACX 资产复制成另一份长期运行目录。

4.2 宿主按插件机制接入

Claude Code 与 Codex 各自通过自己的 marketplace / plugin 配置发现 ACX。这样可以让宿主看到"这是 acx 插件"，而不是只看到一批散落在全局目录下的 Markdown 和 skills。

4.3 团队资产与个人资产分离

ACX 仓库内的 rules/skills 属于团队 Harness 资产，应跨 Claude Code 与 Codex 生效；不属于 ACX 仓库的 skill、rule、个人偏好，保留在对应宿主默认目录，由宿主差异化管理。

4.4 nad-acx-init保留自动更新价值

nad-acx-init 不再只是"复制 rules/skills"，而是承担：

• 发现或引导准备本地完整 ACX 仓库；
• 检查工作区是否干净；
• git pull --rebase 更新仓库；
• 检测自身脚本 hash 并 exec 新版本；
• 校验 .claude-plugin / .codex-plugin manifest；
• 幂等维护 Claude Code / Codex 插件源注册状态。

05 实践经验

5.1 三类资产

商业客户端 Harness 资产建议分三层治理：

1. 行为规范层 ：CLAUDE.md、AGENTS.md、.claude/rules/*.md、ACX Markdown rules。目标是影响模型怎么思考、怎么编码、怎么汇报。
2. 能力执行层 ：SKILL.md、scripts、references、assets。目标是把可重复流程固化成可调用能力。
3. 宿主集成层：plugin manifest、marketplace、settings、permissions、hooks。目标是让宿主知道资产来源、启用状态、加载边界和更新路径。

nad-acx-init 的最终角色是把前两层资产注册到第三层宿主集成体系中。

5.2 自动更新rule + skill实现每日主动同步

自动更新rule + skill实现每日主动同步

• 【rule】nad-acx-auto-daily-init：每日首次会话自动执行 nad-acx-init skill，保持本地 Rules、Skills 和 Plugins 最新；
• 【skill】nad-acx-init：同步配置、本地部署初始化/更新skill。

rule自动加载、skill被动触发，两者结合实现hook效果，完成每日自动更新。

5.3 agent主动汇报生效的rules、skills

• 【rule】nad-acx-report-active-rules-skills：要求 Agent 在任务结束时汇报实际生效的 Rules 和 Skills。

通过rule要求agent每次对话主动汇报生效的rules和skills，直观了解rules、skills的生效情况是否符合预期。

5.4 渐进式加载，优化资产对上下文的占用

• Claude Code
• rules：默认只会加载\~/.claude/rules根目录下的md文件，不会递归加载子目录；
• skills：默认只会加载\~/.claude/skills根目录下的skills，不会递归加载子目录；
• plugin：可以指定生效的skills目录；

Codex

• AGENTS.md：不会递归加载子目录内容，桥接哪些内容则生效哪些内容；
• skills：默认只会加载\~/.codex/skills根目录下的skills，不会递归加载子目录；
• plugin：可以指定生效的skills目录；

结合rules、skills不会递归加载的特性，对于必要的rules、skills，可以将放到根目录，实现agent自动加载，占用少量上下文；对于非必要、仅在特定条件、特定时机有意义的rules、skills，可以放到子目录，避免被agent主动加载。

非必要的rules、skills，如何被合理加载到上下文？商业客户端结合日常迭代的五大维度给出了解决方案。将日常开发工作按照：

• 端（Android、iOS、鸿蒙）
• 产品线（手百、手百Lite、好看、贴吧、SDK等）
• 场景（主feed、短小融合视频流、激励视频等）
• 需求类型（新增请求参数、新增物料解析、新增广告模块、UE样式升级等）
• 交付阶段（需求评审、技术方案设计、Coding、联调、测试、上车等）

五大维度进行标记，并为所有的rules、skills标记五大维度的适用范围，日常开发过程中，story-pilot skill流转并按照五大维度查表匹配，精准加载适合当前工作的rules、skills。

06 总结

综上，商业客户端 Harness 资产管理的核心，不是简单复制 Rules 或 Skills，而是建立覆盖资产创建、评审、发布、分发、更新与下线的完整治理体系。文档梳理了 ACX 从单 Agent 文件同步、脚本化安装、\~/.acx中枢软连接到仓库整体插件化的演进，明确以 ACX 仓库作为唯一事实源，由 Claude Code、Codex 等宿主按原生插件机制加载，并分离团队资产与个人资产。实践上，应将资产划分为行为规范、能力执行和宿主集成三层，通过每日自动更新、规则与技能生效汇报、渐进式加载及多维度匹配，兼顾规范统一、上下文效率和可追溯性。后续需完善 Comate 等宿主适配，推进非必要 Skills 按需加载，并加强版本、兼容性、权限和效果度量，形成可持续演进的 Harness 工程体系。