本周发布了什么
Agent Plugins 1.0.0 于 2026 年 8 月 6 日正式落地，并在 Google Developers Blog 上公布。这是一种打包格式，它将 Agent Skills 和 MCP 服务器捆绑到一个具有固定位置的可移植目录结构中。支持该格式的成员名单非常引人注目：Amazon、Cursor、Microsoft、OpenAI 和 Vercel，Google 也作为核心维护者（Core Maintainer）加入其中。支持范围已涵盖 Agents CLI（包括 Antigravity、Gemini CLI、Claude Code 和 Cursor）以及 Data Agent Kit，兼容客户端列表在 agent-plugins.org 上维护。
它解决的问题在公告中写得很清楚：“插件作者不应该在触达每个客户端与利用每个客户端的优势之间做出妥协。” 其目标是让插件的组件能够“在任何兼容的客户端之间可移植地使用。”
接下来是对于任何思考记忆问题的人来说至关重要的一句话。该规范划定了自己的界限：Agent Plugins v1 “仅仅是一种打包格式，别无其他。它没有定义安装机制、分发协议、权限模型、沙箱要求、信任或来源验证，也没有定义用户体验。”
这并不是批评——紧凑的范围正是规范得以发布的原因。但看看那些超出范围的列表，注意有什么甚至根本没有出现在上面。记忆和持久状态并没有被排除在外，因为它们从未进入过讨论。该格式标准化了能力层，而能力层与你积累的上下文是完全不同的两码事。
相关研究也指向了同一个方向。一篇名为《SkillOpt: Executive Strategy for Self-Evolving Agent Skills》（arXiv 2605.23904，于 2026 年 5 月 22 日提交，并在 8 月 5 日的行业报道中被提及）的预印本论文将技能文档视为冻结智能体的可训练外部状态：优化器模型将评分的 rollout 转化为对单个技能文件的有界添加/删除/替换编辑，并且只有在严格提高留出验证集分数时，编辑才会被接受。在 6 个基准测试、7 个目标模型和 3 个执行环境（直接对话、Codex 和 Claude Code）中，作者报告称他们的方法在所有 52 个评估单元（模型、基准、环境）中均名列第一或并列第一，使 GPT-5.5 在直接对话中的平均无技能准确率提升了 +23.5 个百分点，在 Codex 循环中提升了 +24.8 个百分点，在 Claude Code 中提升了 +19.1 个百分点。
值得关注的一点是迁移结果：经过优化的技能伪影在跨模型规模、在 Codex 和 Claude Code 执行环境之间移动，以及迁移到邻近的数学基准测试时，无需进一步优化即可保留其价值。在一个环境中训练的程序在另一个环境中依然有效。
在得出结论之前，有两个注意事项。这是一篇预印本，并非同行评审的工作。而且这篇论文发表于 2026 年 5 月——8 月是报道流传的时间，而不是研究出现的时间。本周真正新颖的是打包标准；SkillOpt 则是证明被标准化的东西确实具有可迁移性的证据。
为什么技能不等于记忆
一个是通用的，另一个是你的
技能编码了一个可重复的程序。这正是它能够迁移的原因：在“如何审计电子表格中的损坏引用”中，没有任何内容取决于具体的电子表格、公司或季度。剥离掉具体细节，你就得到了可以发布的东西——这正是打包格式假设你所拥有的。
记忆则是具体细节。你的会计科目表、你强制执行的命名规范、其 API 在失败时仍返回 200 的供应商、你在 3 月份做出的决定及其背后的原因。这些内容对其他人毫无用处，也无法一次性编写并安装。它必须从你的工作中捕获，并且会不断增长。
一个是编写的，另一个是累积的
你刻意编写一个技能，它就会保持不变。你可以审查它、对其进行版本控制、发布 1.1 版本。它是一个有作者的产物。
记忆没有特定的编写时刻。它是工作的副产品——这里的一次修正、那里的一项决定、下午 6 点发现的一个限制。这意味着它们的失败模式完全不同：技能的失败在于出错，而记忆的失败在于根本没有被记录下来。打包格式无法解决第二个问题，因为还没有任何东西可以打包。
技能告诉智能体“如何做”；只有记忆能告诉它“这里的情况”
这就是混淆付出高昂代价的地方。在你的智能体中安装一个经过高度优化的代码审查技能，它会很好地审查代码——但只是泛泛地审查。它会标记缺失的空值检查，却忽略了你的团队因为上游的奇特行为而故意在适配器层允许这种模式。程序是优秀的，但上下文缺失了。
团队会将这种结果解读为“技能需要微调”并对技能进行迭代。技能其实没问题。缺失的是那个能够说明“在这里，我们是这样做的，原因如下”的层级——这也是为什么检索你的文档不等于记忆：找到一份提到适配器层的文档，并不等同于智能体知晓现行的决定。
可移植性让差距更加明显，而不是更小
这是一个有点反直觉的后果。在 Claude Code、Cursor、Codex 等工具之间迁移技能变得越容易，你实际迁移的频率就会越高——而每次迁移都会将知识端重置为零，而能力端则完好无损地到达。该标准消除了半个技术栈的摩擦。而它没有触及的那一半，正是你花了六个月时间积累起来的那一半。
人们尝试过的方法
将项目上下文放入技能中。 这是显而易见的操作，在失效之前确实管用。但现在你让这个技能变得无法发布、无法跨项目进行版本控制，并且一旦决定发生变化就会立即过时。你也无法分享它，而分享本是打包格式的初衷。
把所有东西都塞进指令文件中。 AGENTS.md、CLAUDE.md、.cursor/rules——这些确实是存放现行规则的正确场所，Cursor 自己的文档也出于充分的理由建议将规则保持在 500 行以内。指令文件在每个任务中都会加载，因此它们是每次请求的开销。它们是为规则准备的，而不是为累积的记录准备的。
每个客户端一个庞大的插件。 一些团队通过维护一个内置了上下文的、针对每个工具的捆绑包来解决可移植性问题。这会导致同一份知识出现三个逐渐产生偏差的副本，这比一份谁也无法移动的副本还要糟糕。
在每次会话开始时重新解释。 这种方法很普遍，但效果会逐渐变差——你在周四输入的版本会比周一的更短，因为你是凭记忆进行总结，而排除的内容往往是枯燥的部分。
让每个工具的内置记忆来处理。 这很合理，在存在该功能的地方也值得启用。问题在于，这些存储是针对每个工具的，通常是针对每台机器的，并且无法导出，因此它们重现了插件规范旨在解决的完全相同的问题——只是在更低的一个层级，而那里目前还没有任何标准。
解决方案：交付技能，保留上下文
有意识地分离这些层级，并为每个层级提供其应有的存储空间。
技能放入插件中。编写干净且通用的技能，确保其中不包含任何能识别你的代码库或客户的信息，对其进行版本控制，并让新格式将它们带到你本季度使用的任何环境中。这就是它的用途，而且现在已经可以正常工作了。
上下文则放入一个独立于任何单一工具、且每个工具都能读取的记忆层中。这不是一个更大的指令文件，而是一个保存你工作产生的文档、决定和限制的存储库，在相关时进行检索，而不是在每次请求时都全部加载。MemoryLake 正是为这种分离而设计的：一个你的智能体可以通过 MCP 或 API 读取的统一存储库，因此切换环境只需更改配置项，而无需重新初始化你的机构知识。
一个客观的界限：记忆层并不能强迫智能体遵循它所读取的内容——注意力和指令遵循是模型行为，没有任何存储层能保证合规性。它改变的是，相关的上下文在关键时刻是可用且简短的，而不是缺失或埋在一个不断增长的文件中，以至于模型不再关注其中间部分。
步骤 1：创建 API 密钥
生成密钥并在大约 30 秒内发出你的第一次请求。将其保存在你的环境变量或机密管理器中——请注意，Agent Plugins v1 明确定义没有权限模型，因此打包标准中的任何内容都无法保护你写入捆绑包中的凭据。
步骤 2：上传你的第一批记忆
放入保存具体细节的文档、图像和文件：架构决策、带有原因的规范文档、客户简报、事后分析。尽可能上传源文件而不是摘要。这正是无法放入可分享插件中的材料，也是为什么它需要自己的归宿。
步骤 3：连接你的 AI 和智能体
让 Claude、Codex、OpenClaw 和其他 AI 智能体通过 MCP 或 API 访问记忆。由于插件已经将 MCP 服务器与固定的配置位置捆绑在一起，记忆层可以无缝接入你技能所使用的相同线路——能力层和知识层通过同一扇门，来自不同的存储库。
这在实践中带来了什么改变
你安装的技能开始表现得就像是你的团队编写的一样。相同的通用程序，现在应用于一个其规范和异常均可检索的代码库——因此代码审查技能不再标记你团队故意允许的适配器层模式。
工具切换在两个方向上都变得非常廉价。技能之所以能迁移，是因为格式支持迁移；上下文之所以能迁移，是因为它从未存在于工具内部。这是智能体设置的两半部分首次同时具备可移植性，也是并排运行 Codex 和 Claude Code不再需要维护两份相同规范副本的实际原因。
你的指令文件会变小。一旦累积的记录有了存放的地方，AGENTS.md 就会重新变回一个简短的现行规则列表，而不是一个不断增长的归档文件——这有利于降低成本，也有利于提高合规性，因为模型对 500 行规则文件的关注度往往是不均匀的。
而且技能变得可以分享。如今大多数团队无法发布他们的内部技能，因为上下文与技能紧密焊接在一起。分离这些层级，技能在构建上就具备了可发布性。
将技能与记忆分离的最佳实践
应用“竞争对手能用这个吗？”测试
编写一个技能，然后问问你所在行业的其他公司是否可以原封不动地安装并从中受益。如果是，它就是技能——保持其通用性并进行打包。如果否，你写的就是披着技能外衣的上下文，它属于记忆层，可以在不发布新版本的情况下进行更新。
保持指令文件用于规则，而非记录
任何在每次请求时加载的内容都应该是简短、命令式且稳定的。决策、历史和参考材料属于按需查询的存储库。将它们混在一起，会导致你得到一个在每个任务中都开销巨大、却依然不包含你所需内容的文件。
对技能进行版本控制，对记忆标注日期
技能拥有语义版本，因为它们是编写的产物。记忆条目拥有生效日期，因为它们是决策的记录——而且被取代的决策必须保持可读，否则你将无法解读上个季度的工作。针对不同的失败模式采用不同的存储规范。
不要等待记忆标准
MCP 标准化了智能体如何访问工具；Agent Plugins 标准化了能力如何打包。目前还没有针对可移植用户记忆的同等协议，而且插件规范本身的作用域声明也明确表明它并不打算尝试制定一个。选择一个任何客户端都可以通过 MCP 或 API 读取的存储库是目前可行的解决方案，并且无论最终出现什么标准，这种方案都能适用。
结论
8 月 6 日是一个真正的里程碑：六家厂商就技能和 MCP 服务器的统一打包格式达成一致，这是生态系统不再局限于单一工具的开端。而规范本身关于界限的声明是公告中最有用的一句话——它仅仅是一种打包格式，别无其他，这意味着保存你具体细节的层级从未在讨论范围内。
因此，将它们视为两个问题。编写干净且通用的技能，让标准来承载它们。将累积的记录——决策、规范、原因——保存在你的智能体可以读取且你可以编辑的存储库中，这样它的寿命就会比你碰巧使用的环境更长。能力层刚刚实现了可移植。让知识层实现可移植仍然取决于你的选择，而这正是你花了六个月时间构建的那一半。