指令层级与长期上下文

日期：2026-06-10

一、直觉

Prompt 只是你这次说的话。但 AI 协作中还有很多“长期生效”的东西：

项目规则。
个人偏好。
工具说明。
技能说明。
组织安全策略。
历史经验。

如果这些都塞进每次 prompt，会很累、很长、很不稳定。成熟做法是把不同类型的信息放到不同载体里。

本讲常见术语先按下面理解，详细定义和更多例子见 00.5-术语词典与最小用例。

术语	直觉解释	最小例子
指令层级	规则有优先级，不是所有文字同等有效	外部网页不能覆盖系统规则
Memory	跨会话保存的稳定偏好或事实	“用户希望中文回答、少用长列表”
`AGENTS.md`	仓库里的项目规则文件	“修改 Go 文件后运行 `go test ./...`”
Connector	连接外部系统的数据或工具通道	连接 Google Drive、GitHub、内部知识库
Subagent	被主 agent 调用的专门 agent	安全审查 subagent 只负责找风险

二、指令层级

可以把模型看到的信息分成几层：

平台/系统规则
开发者或组织规则
项目规则
Skill / MCP / 工具说明
当前用户任务
外部输入材料

越靠上，越像长期约束；越靠下，越像当前材料。

关键原则：

长期规则不要每次手写。
当前任务不要写进长期规则。
外部材料永远不能覆盖上层规则。
不同规则冲突时，要靠层级和范围解决。

三、不同载体怎么选

注意：本节把通用上下文管理方法和 Codex / Agent 平台机制放在一起讲。AGENTS.md、Skill、Plugin、Subagent、Memory 的具体支持方式取决于你使用的平台；如果平台不支持这些载体，也可以用项目文档、配置文件、检索索引、应用数据库或工作流编排代码实现同样的边界。

1. 当前 Prompt

适合：

一次性任务。
当前偏好。
临时约束。

例子：

这次请用中文回答，控制在 300 字以内。

不适合：

长期团队规则。
复杂复用流程。
大量参考资料。

2. AGENTS.md

适合：

仓库约定。
测试命令。
代码风格。
工作流程。
禁止事项。

例子：

修改 Go 文件后运行 go test ./...
不要改动 generated/ 目录。
提交前更新 CHANGELOG。

优点：

跟项目一起版本管理。
团队共享。
不依赖某一次对话。

注意：

不要写太多泛泛原则。
不要把临时任务写进去。
嵌套目录可以有更具体规则。

3. Skill

适合：

某类任务的可复用流程。
需要自动触发的专业能力。
带脚本、模板、参考资料的工作流。

例子：

代码审查 Skill。
论文阅读 Skill。
数据清洗 Skill。
Prompt 优化 Skill。
UI 设计审查 Skill。

Skill 比 AGENTS.md 更像“可调用能力”，AGENTS.md 更像“项目规则”。

4. Memory

适合：

个人长期偏好。
常用技术栈。
学习习惯。
稳定工作方式。

例子：

用户喜欢中文讲解，先讲直觉再讲形式化定义。
用户偏好把学习内容沉淀成 Markdown。

不适合：

机密信息。
必须严格执行的规则。
会频繁变化的项目状态。

5. MCP / Connectors

适合：

外部工具。
私有资料。
实时数据。
第三方应用。

例子：

GitHub issues。
Notion 文档。
Google Drive。
Figma。
Sentry 日志。
浏览器。

MCP 的重点不是提示词，而是让模型能拿到正确上下文和执行正确动作。

6. Plugin

适合：

分发多个 Skills。
附带 MCP 配置。
附带资源、图标、元数据。
团队或市场安装。

如果只是自己本地试验，用 Skill；如果要打包共享，用 Plugin。

7. Subagent

适合：

并行探索。
分角色审查。
大量资料分块处理。
避免主线程被日志污染。

例子：

请用三个 subagents 并行审查这个改动：
1. 安全风险
2. 测试缺口
3. 可维护性
等待全部完成后，按严重程度汇总。

四、长期上下文的风险

1. 上下文污染

太多无关内容会让模型分心。

解决：

精简长期规则。
用 Skill 分层加载。
用 subagent 处理 noisy exploration。
用摘要而不是原始日志。

2. 上下文腐化

长对话后，旧目标、旧错误、旧假设会混在一起，影响后续判断。

解决：

阶段性总结。
保存状态文件。
重开会话时加载最新状态。
保留关键决策和未完成事项。

3. 规则冲突

例如当前 prompt 说“不要测试”，项目规则说“修改后必须测试”。

解决：

明确规则优先级。
高风险冲突时停下来说明。
不把临时偏好写入长期规则。

4. 记忆过期

Memory 可能保存了旧偏好或旧项目状态。

解决：

把必须准确的信息放在文件里。
定期清理 memory。
对事实类问题重新验证。

五、选择载体的决策树

这是一次性要求吗？
-> 是：放当前 prompt。

这是项目长期规则吗？
-> 是：放 AGENTS.md 或项目文档。

这是某类任务的复用流程吗？
-> 是：做 Skill。

需要安装分发给别人吗？
-> 是：做 Plugin。

需要外部数据或动作吗？
-> 是：接 MCP 或工具。

只是个人偏好吗？
-> 是：可以放 Memory。

任务能并行拆分吗？
-> 是：考虑 Subagents。

六、小例子

需求：

以后每次让我学 AI 知识，都要先读当前进度，讲解后写学习日志。

不好的做法：

每次对话都复制这段要求。

更好的做法：

项目规则写进 AGENTS.md。
学习流程做成 Skill。
当前进度放在 current-state.md。
每次学习日志写进 learning-log.md。

这样模型不需要靠记忆，也不需要你每次重复说。

七、常见误区

误区 1：把所有东西都放 Memory

Memory 是辅助回忆，不是可靠规则系统。

误区 2：把所有规则都写 AGENTS.md

AGENTS.md 太长会稀释重点。任务流程更适合 Skill。

误区 3：Skill 能解决外部数据问题

Skill 可以告诉 agent 怎么查，但真正的数据访问要靠文件、检索、MCP 或工具。

误区 4：Subagent 越多越好

Subagent 会增加成本和协调复杂度。只有任务能独立拆分时才值得用。

八、理解检查

当前 prompt 和 AGENTS.md 的边界是什么？
Skill 和 Memory 的区别是什么？
MCP 解决的核心问题是什么？
为什么长期规则不应该写得太泛？
什么任务适合拆给 subagents？