为什么 Kiro 现在有两种按需加载上下文的方法
首先从构建 powers 旨在解决的问题开始。Kiro 的文档用两句话说明了这一点：“没有框架上下文，智能体就会靠猜。”以及“上下文过多，智能体就会变慢。”连接多个 MCP 服务器意味着在任何工作开始之前，必须预先加载每个工具定义。
Powers 通过激活来解决这个问题。“Powers 不是一次性加载所有 MCP 工具，而是根据您对话中的关键词动态激活。”当任务开始时，Kiro 会“读取任务描述”、“评估已安装的 powers 是否与任务匹配”，并“仅将相关的 powers 加载到上下文中”。而且它们还会再次关闭：Kiro 自己的例子是，当您从支付工作转向数据库工作时，“Supabase power 激活，而 Stripe 停用”。
A power 是一个包。它遵循 Agent Plugins 规范，包含一个必需的 plugin.json 清单，以及可选的 skills/、mcp.json 和用于“Kiro 特定扩展（如 steering 文件）”的 dev.kiro/ 文件夹。清单的 keywords 字段是触发器：一个“触发激活的字符串数组。使用与开发人员讨论您的工具时相匹配的术语。”
Steering 的工作原理则不同。Kiro 将其描述为通过 markdown 文件赋予智能体“关于您项目的持久知识”，它现在支持四种包含模式。“始终包含”（Always included）是默认模式，用于“应该影响所有代码生成的底层标准”。条件包含（Conditional inclusion）“仅在处理与指定模式匹配的文件时”加载文件。手动包含（Manual inclusion）在您在聊天中引用它时加载。而自动包含（Auto inclusion）则在“您的请求与描述匹配时”加载，Kiro 指出这“工作原理类似于 skills”。
因此，两者都有仅在相关时才加载的方法。Kiro 的文档在名为“Powers 与 skills 和 steering 的区别”的章节中明确阐述了预期的划分：
“Powers 是将 MCP 工具、skills 和知识打包到单个可安装包中的插件。它们根据上下文动态激活。适用于既需要工具又需要指南的集成。”
“Steering 是塑造智能体行为的 Kiro 特定上下文。它支持 always、auto、fileMatch 和 manual 模式。适用于项目标准和规范。”
还有一个对比中没有说明但安装页面写得很清楚的区别：它们各自存放的位置。Steering 存在于代码仓库中——“智能体自动在您仓库根目录的 .kiro/steering/ 文件夹中寻找 steering 文件。”而 Powers 是通过 powers 面板从注册表、GitHub URL 或本地文件夹安装的。旧版格式的 power 会“在您的 ~/.kiro/settings/mcp.json 配置文件中”注册其 MCP 服务器，而 Agent Plugins 格式的 power 的服务器“由 Kiro 内部管理”。无论哪种方式，power 都是您个人配置的一部分，而不是代码仓库的一部分。
人们尝试的其他替代方法
将所有内容都放在始终启用的 steering 中。 这确实可行，但每个任务都要为此付出代价。当您在修复 README 中的拼写错误时，一大段关于支付 API 的说明也会被加载。Kiro 自身对于重度上下文材料的建议是使用更窄的模式。
将团队规范变成一个 power。 Power 是按个人安装的。如果您的团队错误处理规则存在于您安装的 power 中，那么未安装它的同事在工作时就没有这些规则，而且代码仓库也不会显示缺少任何内容的迹象。
依赖关键词来获取项目事实。 关键词适用于集成，因为人们在处理集成时自然会说 “Stripe” 或 “database”。项目规范很少会带有一个能可靠地出现在请求中的词。
将自动 steering 和 powers 视为同一种东西。 两者都根据相关性激活。但只有一个会自带 MCP 工具，且只有一个会随代码仓库一起移动。
假设包含模式在每个界面上的行为完全相同。 Kiro 的 steering 页面目前在这里有两种说法。其功能表将“包含模式（always、fileMatch、manual）”标记为在 IDE、CLI、Web 和移动端上均受支持。然而，同一页面还包含一条注释：“在 Kiro CLI 上，目前不支持包含模式。.kiro/steering/ 目录中的所有 steering 文件都会自动加载。”在这两者达成一致之前，请自行在 CLI 上验证其行为，而不是盲目相信其中任何一种说法。之前关于为 IDE 和 CLI 拆分 Kiro steering 的指南就是围绕第二种说法撰写的。
解决方案：根据谁需要以及何时适用，来路由每部分上下文
路由归结为针对每部分上下文的两个问题：在这个仓库中工作的每个人都需要它吗？以及什么应该触发它？
步骤 1：按受众和触发器对每部分上下文进行分类
列出您的智能体目前知道的内容，包括来自 steering 文件以及您在提示词中重复的任何内容。对于每个项目，写下两件事。
受众：这对于在仓库中工作的每个人都适用，还是关于某些人使用的工具？错误处理规范、目录布局和测试命令是团队事实。如何使用正确的幂等性模式调用特定供应商的 API 则是工具专业知识。
触发器：它应该在什么时候加载？始终加载、当某些文件打开时、当请求与描述匹配时，还是仅在有人要求时加载？
这会产生一个简单的网格。带有任何触发器的团队事实都归入 steering。随工具附带的工具专业知识归入 power。不带工具的工具专业知识（例如某个库的使用说明）可以归入两者之一，而受众问题通常可以解决这一归属。
步骤 2：将团队规范保留在 steering 中，并使用仍能触发的最窄模式
对于每个团队事实，选择在它适用时精确加载它的包含模式。
真正通用的标准保持为 “always”。Kiro 对该模式的示例是“您的技术栈、编码规范和基本架构原则”。
与代码库某部分绑定的规范将通过文件模式获得条件包含，以便在处理组件文件时加载组件规则。
仅对某些请求重要的较长指南将获得自动包含，并带有 Kiro 可以匹配的 name 和 description。Kiro 推荐的自动模式用途是“仅在相关时才应加载的重度上下文指南”。
您偶尔运行的流程（如迁移清单、故障排除指南）将获得手动包含，Kiro 推荐将其用于“仅偶尔需要的专业工作流、故障排除指南、迁移流程或重度上下文文档”。
每一个模式都必须遵守一个结构性规则：“包含配置必须是文件中的第一个内容——前面不能有空行或内容。”空行之后的 front-matter 块就不是 front-matter 块。
如果您使用自定义智能体，也请检查它们的配置。Kiro 指出：“使用自定义智能体时，不会自动包含 steering 文件。您必须显式将它们添加到智能体的 resources 配置中以加载 steering 上下文。”
步骤 3：将工具专业知识移入 powers，检查关键词，然后在每个界面上进行验证
对于集成，请安装 power，而不是在 steering 中重建其指南。如果您的团队使用私有工具， Kiro 支持构建一个：包含清晰 description 和 keywords 的 plugin.json，外加 skills 和可选的 MCP 配置。
阅读您安装的每个 power 的关键词。它们决定了它何时激活，并且它们是针对开发人员通常讨论该工具的方式编写的，这可能与您团队的习惯不符。
然后进行验证。启动一个应该触发 power 的任务和一个不应该触发的任务，并确认工具的出现和消失。启动一个涉及条件包含区域的任务，并确认 steering 已加载。鉴于 steering 页面上的冲突注释，请在 IDE 以及 CLI（如果您使用的话）中执行此操作。如果 powers 是您团队工作方式的一部分，请写下是哪些，以便新同事可以安装相同的一套。
在 MemoryLake 中进行设置
步骤 1 产生了一份团队事实列表，无论加载了哪个智能体、界面或插件，这些事实都是成立的。MemoryLake 是保存该列表的地方，因此它不依赖于某一个工具的文件夹布局或包含模式。
您可以用自己的语言亲自编写这些条目。不会从 .kiro/steering、您安装的 powers 或任何供应商的存储中读取、写入或删除任何内容。
步骤 1：创建 API 密钥
登录并从控制面板生成一个密钥。该密钥允许智能体（无论是在 Kiro 还是在团队中的任何其他工具中）读取您编写的条目。
步骤 2：上传您的第一批记忆
添加步骤 1 中的团队事实，每个条目一条，并附带每个规范存在的原因。这个原因可以让人们在以后决定该规则应该移动、更改还是保留。
步骤 3：连接您的 AI 和智能体
将您的智能体指向该工作区。这样，无论队友碰巧使用哪个界面或插件集，都可以使用相同的规范。
这在实践中带来了什么改变
第一个区别是更小的基线。随 power 加载的集成指南不需要在每个任务上都占用空间。更广泛的一点是——更大的窗口改变的是能容纳什么，而不是应该容纳什么——这也是为什么长上下文不是记忆背后的核心观点。
第二个区别是团队知识留在团队中。steering 中的规范存在于代码仓库中，经过评审并共享。而 Powers 仍然是每个人个人配置的事情，这对于工具来说是正确的，但对于每个人都必须遵守的规则来说则是错误的。
第三个区别是上下文成本变得清晰可见。当始终启用的 steering 仅包含通用事实时，每个请求的固定部分就很小且已知。追踪记忆如何减少 Token 使用量的团队通常会发现，节省的成本来自于他们停止每次都发送的内容，这一点在Token 成本节省来自何处中也有所阐述。
第四个区别是对长会话的韧性。按需加载的上下文在会话压缩时也可能会丢失；了解哪些事实必须保留是决定在 Kiro 压缩中保留什么所要解决的问题。
Kiro powers 和 steering 的最佳实践
首先按受众进行路由。 如果仓库中的每个人都需要它，它就属于 steering。如果它随某些人使用的工具一起提供，它就属于 power。
使用仍能触发的最窄包含模式。 始终（Always）用于通用标准，文件模式（fileMatch）用于特定区域的规则，自动（auto）用于重度指南，手动（manual）用于偶尔的流程。
将 front matter 放在最前面。 包含设置只有作为文件中的第一个内容时才起作用。
阅读每个 power 的关键词。 它们决定了激活，并且它们是针对普通开发人员而不是针对您团队的词汇编写的。
保留一份您团队所依赖的 powers 列表。 在一台机器上安装的 power 对代码仓库以及下一个克隆它的人来说是不可见的。
在每个界面上进行验证。 Kiro 的 steering 页面目前对 CLI 上的包含模式给出了两种不同的说法。请进行测试而不是凭空假设，并将 MCP 服务器视为整体图景的一部分——只有当工具背后的事实也被保存在某个地方时，MCP 才是缺失的记忆层。如果您以后迁移工具，从 Kiro 迁移到 Codex 展示了哪些部分可以转移。
结论
Kiro 的 powers 和 steering 在不同的地方解决相关的问题。Powers 将集成的工具和指南结合在一起，并随对话开启和关闭。Steering 保存了仓库自身的标准，并具有四种包含模式来控制每个文件的加载时间。
Kiro 的文档直接说明了这一划分：powers“适用于既需要工具又需要指南的集成”，steering“适用于项目标准和规范”。需要从安装页面补充的一点是，steering 随仓库移动，而 powers 随个人移动。
按受众和触发器对每部分上下文进行分类，将团队事实保留在 steering 中并使用能触发的最窄模式，让 powers 承载工具专业知识，并在您使用的每个界面上进行验证。将团队的规范记录在不依赖于这些机制中任何一个的某个地方。