跨Agent统一配置：一套规则驱动Claude Code、Codex与Pi

多Agent时代的新痛点：规则碎片化

当你在终端里只使用一个AI编程助手时，一切都很简单——设定好规则和技能，它便会照做。但现实是，越来越多的开发者同时使用多个Agent：Claude Code、Codex、Pi、OpenCode、OpenClaw^广告、Hermes……每一个都强大，但每一个都需要独立配置规则与技能。

这种多Agent并存的局面并非偶然。Claude Code是Anthropic推出的终端原生AI编程助手，擅长深度代码推理和系统级操作；Codex是OpenAI的编程Agent，拥有强大的代码生成和图像生成能力；Pi则定位为更轻量级的交互式助手，对某些文件格式有更好的自动识别能力。每个工具都在特定领域有独到优势，因此开发者往往不会"忠于"某一个工具，而是根据任务类型灵活切换——这也正是配置碎片化问题的根源所在。

这正是这期B站教程试图解决的核心问题。视频作者用一个直观的演示揭示了矛盾：他在左侧终端输入以FastPath开头的查询，Agent毫无反应；而在右侧另一个Agent中，同样的指令却成功地在根目录创建了一个以当日日期命名的Markdown文件。差异的根源在于——规则只对配置过的那个Agent生效，其他Agent则"失明"。

随着项目增多、技能累积，各个Agent之间会逐渐"不同步"。为每个Agent重复维护同一套指令，既繁琐又极易出错。视频提出的方案是：让所有Agent共用一份配置文件，一次定义，处处生效。

Agent的两大核心要素：记忆与肌肉

在讲解具体设置前，作者先厘清了两个基础概念，并用了一个生动的比喻来帮助理解。

记忆 = 规则（Rules）

所谓"记忆"（Memory），就是每次开启新会话时，Agent都应当知道的信息。用更技术性的术语说，这就是"规则"（Rules）。规则从Agent启动的第一刻起就存在，是一种全局性的、持续生效的约束。

从技术实现层面来看，规则的本质是系统提示词（System Prompt）的扩展注入。当Agent启动一个新会话时，它会在加载核心系统提示词之后、接收用户输入之前，自动读取配置文件中定义的规则，并将其作为上下文的一部分注入到对话的开头。这意味着规则对Agent的每一轮推理都有持续影响，相当于为Agent建立了一套"底层认知框架"。典型的规则内容包括：代码风格偏好（如"始终使用TypeScript而非JavaScript"）、安全约束（如"永远不要在代码中硬编码密钥"）、输出格式要求（如"回答使用中文"）等。

肌肉 = 技能（Skills）

而"肌肉"（Muscle）则对应"技能"（Skills）。技能是随着你不断使用Agent而逐渐建立起来的能力集合——它是一组规则、工作流程与能力的打包，只在特定条件满足时才会被触发。

技能与规则的关键区别在于触发机制。规则是"始终在场"的约束，而技能采用条件匹配的模式——只有当用户输入中包含特定关键词、文件类型或操作意图时，Agent才会激活对应的技能。这种设计借鉴了软件工程中"事件驱动"的思想：与其让Agent始终背负所有能力的上下文开销，不如按需加载，既节省了Token消耗，也避免了不同技能之间的指令冲突。一个技能定义通常包含三个部分：触发条件（什么情况下激活）、执行步骤（具体做什么）、输出规范（结果以什么形式呈现）。

作者举了个实用的例子：假如你每周都要按固定格式制作周报表格，而原始数据由另一个团队导出、格式混乱，那么你可以创建一个专门"清理乱表格"的技能。他还给出了一条实用的经验法则：如果你发现自己需要让Agent做某件事三四次，那么就值得为它创建一个技能。

核心机制：一份AGENTS.md统一多个AI助手

整套多Agent统一配置方案的技术核心，是一个被多个Agent共同读取的配置文件。

之所以选择Markdown（.md）作为配置文件格式而非JSON或YAML，背后有深思熟虑的技术考量。Markdown是一种轻量级标记语言，既能被人类直接阅读编辑，也能被大语言模型（LLM）精确解析——这一点至关重要，因为Agent本质上是通过LLM来"理解"配置内容的。相比结构化的JSON，Markdown允许使用自然语言描述复杂的规则逻辑，降低了编写门槛；而相比纯文本，Markdown的标题层级（#、##）和列表结构又提供了足够的组织性，让Agent能准确区分不同规则和技能的边界。此外，Markdown文件在GitHub上可以直接渲染为美观的文档页面，这对于分享和协作尤为友好。

作者在设置阶段建立了AGENTS.md文件，并关联了各Agent与CLAUDE.md文件。关键在于：你只看到一份文件，但它是多个Agent协同工作的统一标准。 当你使用Claude Code并修改了它的指令或记忆文件时，它会自动同步更新AGENTS.md，让规则在任何新会话中都能保留。

视频中演示了各Agent对该文件的读取行为，其中一个重要发现值得注意：

• Pi 会自动读取CLAUDE.md文件，即使你没有专门设置Agent文件；
• Codex 则不会自动读取，需要显式配置。

这种差异反映了各Agent厂商在"配置兼容性"设计上的不同策略。Pi之所以能自动读取CLAUDE.md，是因为其开发团队在文件扫描逻辑中内置了对多种常见配置文件名的识别——这是一种"约定优于配置"（Convention over Configuration）的设计哲学。而Codex采取的是更保守的策略，要求用户显式声明配置文件路径，虽然多了一步操作，但避免了误读错误配置的风险。理解这些细节能帮你避免踩坑。而这套方案的价值就在于——修改任意一处，改动会传递给其他所有Agent，所有智能体读写同一份文件，任何地方都不存在第二份副本。

Git与GitHub：为Agent配置建立"检查点"系统

要让配置能够随时间演进、又能随时回退，视频引入了Git与GitHub作为基础设施，并特别澄清了一个常见误区。

Git和GitHub是两个独立的工具

很多人把Git和GitHub混为一谈，但它们其实是两件事：

• Git 由Linux之父Linus Torvalds于2005年创建，是版本控制工具本身；
• GitHub 始于2008年，是托管Git项目并支持协作的网站，2018年被微软以75亿美元收购。

Git的核心工作原理值得稍作展开，因为它直接关系到Agent配置管理的可靠性。与许多人直觉中的"Git保存文件差异"不同，Git实际上采用的是快照（Snapshot）模型：每次提交（commit）时，Git会对项目中所有文件的当前状态拍一张"快照"，而不仅仅记录"改了什么"。如果某个文件没有变化，Git只会存储一个指向上次快照的引用，而非重复保存文件内容——这使得存储效率极高。Git的工作流包含三个区域：工作区（你正在编辑的文件）、暂存区（Staging Area）（准备提交的文件）和仓库（Repository）（已保存的历史快照）。理解这三个区域的关系，能帮你更好地掌握下文提到的那些Git命令的含义。

GitHub并没有发明Git，但它把Git带到了互联网上。理解这段历史，有助于你在日常的编程与非编程项目中更从容地使用它们。

常用Git命令与快捷方式

作者演示了一套手动操作流程，并配合了此前设置好的快捷别名：

• git clone — 把现有项目下载到本地（本质上是将远程仓库的完整历史和文件复制到你的机器上）
• git init — 为项目创建检查点与历史记录（在当前目录下生成一个隐藏的.git文件夹，这个文件夹包含了Git所需的所有元数据和对象数据库）
• gs（git status）— 查看改动状态（展示哪些文件在工作区被修改、哪些已进入暂存区、哪些尚未被Git跟踪）
• gea — 将未跟踪文件加入保存点（对应git add，将文件从工作区移入暂存区）
• gc — 提交并附上信息（对应git commit，将暂存区的内容保存为一个永久快照）
• gp — 把改动推送到云端（对应git push，将本地仓库的提交上传到GitHub等远程托管平台）

他还删除了项目的.git文件（rm -rf）来"清空记忆"、重新开始，随后用git init建立全新的检查点。这种手动操作虽然琐碎，但作者强调，理解底层机制后，对于小改动，手动往往比让Agent代劳更快。

仓库安全：务必设为私有

视频反复强调了一个关键的安全原则：创建仓库时务必设为私有（Private），除非你明确想要公开。 否则任何人都能看到你的代码、脚本，如果里面含有API密钥等敏感数据，就会造成泄露。这一点在Agent配置场景中尤为重要——配置文件中可能包含你的工作流偏好、内部项目结构描述、甚至自动化脚本中的环境变量路径，这些信息一旦暴露，不仅涉及个人隐私，还可能成为社工攻击的切入点。所幸如果你使用较智能的模型来创建项目，它通常会主动提醒你这一点。

全局配置vs项目配置：分层管理的艺术

这套多Agent统一配置方案最精妙的设计，是配置的分层机制。

这种分层思想在软件工程中有着悠久的传统。操作系统的环境变量分为系统级和用户级；CSS样式表有浏览器默认样式、全局样式和组件样式的层叠关系；Nginx等Web服务器的配置也区分全局块、服务器块和位置块。这些分层设计背后的核心原则是相同的：通用的配置上提以减少重复，特殊的配置下沉以保持灵活。在Agent配置管理中，同样的原则被巧妙地应用——全局规则定义你作为开发者的普遍偏好，项目规则则适配特定项目的独特需求，两者叠加而非替换。

全局规则与全局技能

在"Agent主页"目录中，存放着全局项目规则与全局技能库。这些配置对所有项目、所有Agent生效。视频演示中，作者让Pi创建了一个使用yt-dlp命令行工具获取YouTube视频摘要的全局技能——一旦设置，任何Agent拿到YouTube链接都能自动总结成Markdown文档，并存入Obsidian笔记库。

yt-dlp是一个值得了解的开源命令行工具，它是已停止维护的youtube-dl项目的活跃分支，由社区维护并持续更新。yt-dlp不仅能下载YouTube视频和音频，还支持提取字幕、元数据、缩略图等信息，并兼容上千个视频平台。在这里的应用场景中，Agent实际上是调用yt-dlp来抓取视频的字幕或描述信息，然后利用LLM的语言理解能力将其压缩为结构化的摘要。这种"命令行工具 + LLM理解力"的组合，是当前AI自动化工作流中非常典型的模式。

项目级规则与项目技能

但并非所有规则都该全局生效。作者接着在某个具体项目仓库内创建了"仅限此处使用"的项目技能：只有在这个项目里粘贴YouTube链接时，才会自动生成带日期标题的摘要文件。

关键原则是：项目规则不会取代全局规则或技能，两者都会被Agent读取。 这在技术上意味着Agent在加载配置时会执行一个"合并"操作——先读取全局配置，再读取当前项目目录下的配置，最终形成一个合并后的完整规则集。如果两个层级的规则存在冲突，项目级规则通常具有更高的优先级（类似CSS中"更具体的选择器优先"的原则）。这样你就能灵活配置——有些规则适用于所有项目，而特定规则和技能只服务于YouTube项目或工作项目。

跨Agent技能共享实战

作者还展示了跨Agent的技能共享：让Codex调用其原生的图像生成能力，同时让Claude Code和Pi也能通过统一技能调用同样的图像生成功能。无论在哪个Agent里，只要明确要求"生成AI图像"，它都能执行。这种跨Agent的技能共享之所以可行，是因为技能定义中不仅描述了"做什么"，还可以包含具体的工具调用指令——例如调用某个API端点或执行某段Shell命令。不同Agent虽然内部架构各异，但它们都能解析Markdown中的指令描述，并映射到各自的工具调用能力上。

让配置随你持续成长

这套体系的最终形态，是一个可持续演进的"共享大脑"。

从网上下载的技能可以自定义，保存到你的私有GitHub账户中，让它随你一起成长。借助Git的检查点机制，如果某个技能改坏了，你随时能回退到之前运行更好的版本——在Git中，这可以通过git log查看提交历史，再使用git checkout或git revert回到指定的快照，整个过程不会丢失任何中间状态。作者还提到可以使用GitHub研究技能，让Agent去网上搜索现成的技能作为灵感，再根据自己的工作流修改定制。

作者特别指出：别人的技能未必完全适合你——"我的一些技能可能并不完全适合你"——所以删除、添加、定制是常态。这套方案的本质，不是给你一份标准答案，而是给你一个可以持续打磨、跨越所有Agent共享的配置框架。从更宏观的角度来看，这种"个人化的Agent配置库"正在成为AI时代开发者的新型"工具箱"——就像过去程序员会精心维护自己的dotfiles（配置文件集合）、Vim插件列表或Shell别名一样，未来每个深度使用AI的人都会拥有一套不断迭代的Agent配置集，它既是个人经验的结晶，也是生产力的倍增器。

总结

随着AI编程助手进入"多Agent并存"的时代，配置的碎片化正成为效率杀手。这期教程给出的解法清晰而实用：以AGENTS.md为统一入口，配合Git/GitHub做版本管理，再通过全局与项目的分层机制精细控制规则与技能的作用范围。

对于同时驾驭Claude Code、Codex、Pi等多个工具的开发者而言，"一次定义、处处生效"不仅省去了重复劳动，更让你的AI工作流具备了可维护、可回溯、可成长的工程化能力。当所有智能体共享同一个大脑，你才真正拥有了一套属于自己的AI生产力系统。

核心要点