每个智能体系统都面临着同样的棘手权衡。你想要一个深度、组织良好的知识库，能够经受住代码审查和 Git 历史的考验。但同时，你也需要运行时保持快速且专注。这两者是背道而驰的。你保留的指令越多，就越容易产生一种冲动：把所有指令都一股脑塞进提示词里，然后听天由命。而这种“听天由命”的代价是非常昂贵的。
在 Agent Project Context 生态系统中，这种张力被清晰地划分到了两个层级。APC 负责持久性，APX 负责速度。理解它们如何交互——以及为什么 APX 拒绝预加载每一个技能定义——能让你对提示工程的理解比大多数优化指南都要深刻。
存档与引擎
APC 的职责是持久化。它将可复用的技能文件以纯 Markdown 文档的形式存储在 .apc/skills/ 目录下。因为这些文件存在于你的代码库中，它们会随版本控制一起移动。你可以发起一个更改部署流程的 pull request。你可以对比六周前的安全策略回滚。你可以精确审计智能体当时应该知道什么，以及是什么时候知道的。当错误的部署上线或合规审计员开始询问时，这种可审查性至关重要。
另一方面，APX 活在当下。它管理着你与模型之间的实际对话。它的目标不是存档知识，而是精准地使用知识。当 APX 将技能视为永久性的负担时，整个系统就会变慢。上下文窗口会被填满，Token 成本会攀升。更糟糕的是，模型的注意力会分散到与当前请求毫无关系的指令上。
这就是为什么技能主体是按需加载的。
臃肿提示词的真实代价
大多数团队都明白 Token 是要花钱的。但很少有团队意识到，无关的 Token 会消耗准确性。
当 APX 将每个可用的技能都注入到每一轮对话中时，提示词就会变得嘈杂。模型会同时接收到部署运行手册、安全指南、API 风格参考、测试清单和入门 FAQ。即使拥有巨大的上下文窗口，当模型必须先从噪声中筛选信号时，其推理质量也会下降。它可能会在回答关于本地测试设置的问题时，错误地抓取了针对生产部署的安全要求；或者在处理简单的错误修复时，将发布清单中的步骤幻觉出来。每一段无关的文本都是一个潜在的干扰项。
逻辑很简单。大多数轮次的对话并不需要大多数技能。如果你只是在请求对错误日志进行快速修复，你并不需要完整的部署运行手册或安全加固指南。你需要的是模型能看到错误、理解你的项目规范并编辑正确的文件。加载无关的技能主体对模型完成这些任务毫无帮助。它迫使模型在开始处理实际问题之前，必须先过滤掉无用数据。
按需加载的工作原理
这一机制简单但经过深思熟虑。APC 继续持有事实依据（ground truth）。你的技能定义依然留在它们该在的地方：.apc/skills/<name>.md。
APX 并不会将这些文件镜像到活动内存中。相反，它会编译一个精简的技能名称注册表。模型可以看到这个列表，并理解存在一个目录。如果它需要浏览或确认有哪些可用能力，它可以调用 list_skills。这让它在不增加数据量的情况下获得了可见性。
当任务确实需要技能文件中编码的精确语法、详细步骤或特定约束时，模型会调用 load_skill。就在那时，且仅在那时，APX 会从 APC 获取完整的 Markdown 主体并将其注入上下文。指令是“热加载”的，仅为预定目的使用一次，系统从而避免了将其作为累赘随身携带。
想想“导入一个库”与“将每个函数定义都粘贴到主文件中”之间的区别。前者让你的代码库保持可导航性，而后者则会制造出一团乱麻，只能靠运气才能编译通过。
当技能冲突时，谁胜出
当 APX 加载技能时，它还会执行清晰的优先级顺序。并非所有环境都是相同的，通用建议绝不应覆盖本地知识。
项目技能具有最高优先级。这些文件存放在当前仓库的 .apc/skills/ 目录下。它们记录了团队特定的规范、自定义封装、遗留命名标准以及特定的工具链。如果你的项目定义了处理数据库迁移的自有方式，则以该定义为准。
其次是全局技能。当项目本身没有定义相关内容时，全局技能将作为组织范围内的通用模式发挥作用。它们充当标准库。
内置运行时技能位于底层，作为兜底方案。它们处理每个智能体（agent）都应理解、但没有特定项目专门重新定义的通用能力。
这种分层方法意味着你的仓库可以控制自身的行为。全局或内置技能不会意外劫持你的团队刻意定制的工作流。
实际应用场景
想象一个典型的维护任务。队友在聊天中粘贴了一段错误日志。回溯信息指向工具模块中的一个空引用。修复方法可能只需要两行防御性代码。
在一个没有按需加载机制的系统中，APX 会将它所知道的所有技能都塞进上下文中。在处理那两行代码之前，模型需要考虑长达 40 页的文本。它看到了发布清单，并纠结是否应该提升版本；它看到了安全指南，并考虑是否要在仅需空检查的函数上进行输入验证；它看到了部署手册，并开始思考分阶段环境。模型开始偏移，响应时间变长，Token 消耗飞速增长。
凭借 APX 的按需设计，模型只能看到名称。它知道存在 [release-checklist]、[security-guide]、[deployment-runbook] 和 [error-handling]。它忽略了前三个。如果你的项目对空安全有特定规范，它可能会加载 [error-handling]。它修复了 Bug。无关的技能从未进入上下文窗口。由于提示词保持简洁，模型始终保持专注。
当任务确实变得复杂时，同样的逻辑依然适用。如果你稍后要求智能体准备生产环境部署，它可以在这些步骤变得相关时，准确地加载部署手册、查阅安全指南并遵循发布清单。知识一直都在，只是在等待合适的时机。
将提示词规范视为架构
APC 与 APX 之间的分离不仅仅是一个实现细节。它是一种提示词规范（prompt discipline）的哲学。APC 永久保存知识，使其可审查、可版本化且安全；而 APX 则决定这些知识中有多少能在当前活跃的上下文中占有一席之地。
丰富的技能目录是一项资产，而臃肿的提示词则是负担。目标是在不让其始终处于活跃状态的前提下，保持上下文的可移植性。你的仓库应该包含团队编写过的每一条指令，但智能体应该只读取那些对当前任务有帮助的指令。
如果你的系统强迫模型在每一轮对话中都携带所有技能的具体内容，那么你构建的就不是智能助手，而是一个在每个参考台问题面前都拖着整个档案馆的图书管理员。存储一切，按需加载。这才是保持智能体快速、上下文整洁且推理敏锐的方法。