Agent Context Layer
- 2026.06.13
最近在使用不同的 Agent 工具，或为团队成员制作 Skill 时，我反复遇到几类问题：
- CLI Agent 的 Session 对用户不透明，除非进入本地目录查找，否则很难追踪和管理；
- 单个 Agent 很难从历史会话中提取有效上下文；
- 多个 Agent 之间缺少稳定的上下文共享机制；
- Skill 与 MCP 配置分散在全局和各个项目中；
- Skill 完成后，团队缺少持续补充 gotchas 的共同机制；
- 通用 Skill 的版本和更新难以统一管理。
代码仓库内的 Skill 可以随项目一起用 Git 管理。但 PPTX、D2C 等通用 Skill 不属于某个仓库，也就缺少自然的归属。
一个人同时使用多个 Agent，已经带来持续的摩擦。不同工具的 Skill 路径和 MCP 配置并不相同；在 Codex 中说明过的事项，Claude 并不知道；Claude 生成的 Plan，也可能需要复制到 Codex 中审查。
当多人协作时，上下文不统一就不再只是使用上的不便，而会成为治理问题：某个 Skill 能用于哪些项目，谁可以修改；一条 Rule 是团队共识，还是个人偏好。
我曾在 X 上转发 Linear 新增的项目文档功能，并写道：“Linear 正在成为 Agent 的 Context Layer。”除 Linear 外，已经有一些工具在处理类似问题，只是各自覆盖其中一部分：
| 工具/技术 | 功能 |
|---|---|
| Linear, Multica | 把 Plan、项目文档变成 Agent 的 Context |
| tape.systems/Bub | 把历史抽象成 append-only 事实日志，支持按需装配 |
| CC Switch、aghub | 统一管理 Skill 与 MCP 配置 |
| Raft（原 Slock） | 在多个 Agent 与人之间共享上下文 |
这些问题指向同一件事：Session、Plan、Memory、Skill 和 MCP 不应继续作为几类分散的配置存在，而应被视为一个整体。
这里所说的 Context Layer 不是某个具体产品，而是一层独立于 Agent 的基础设施。Claude Code、Cursor 或其他 Agent 工具，都可以基于这一层工作。
过去，这些内容通常由每个工具自己的 dotfiles 管理。但它们需要从单个 Agent 中独立出来：一方面降低 vendor lock-in，另一方面与 Codebase 保持适当距离。
完整链路可以写成：
Harness → Context Layer → Project / Codebase
Context Layer 与 Harness 的边界是：
Context Layer 保存跨 Session 持续存在的内容；Harness 负责单个 Session 内的临时编排。
一个完整的 Context Layer 管理工具，至少应包含：
- 统一管理 Session、Plan、Rule、Skill 和 MCP 配置；
- 把 Context 作为协作空间，支持权限管理和共享；
- 提供历史会话的管理与检索；
- 统一管理 Skill 与 MCP 的版本和权限；
- 支持 Session / Plan blame，让 Agent 理解代码修改背后的对话和原因；
- 定期从会话中提取可复用的 Pattern，经审查后沉淀为 Skill 或 Memory；
- 使用 Git 一类的版本管理工具保存 Context。
这一层既是未来 Session 的输入，也是过去 Session 的存档。Harness 存在于单次 Session 中，负责如何使用这些 Context；Context Layer 则负责让它们持久、可查和可共享。
根据 Token 成本，Context Layer 可以分成三类：
| 类型 | 内容 | 使用方式 | 原因 |
|---|---|---|---|
| 能力 | Skill、MCP | MCP Tools 在 Session 开始时 push；Skill 元数据 push，正文按需 pull | 体积小，且通常相关 |
| 规范 | Rule、CLAUDE.md、AGENTS.md | Session 开始时 push | 体积小，用于约束如何工作 |
| 记录 | Session、Plan | 通过 blame 或 search 按需 pull | 体积大，通常只需读取其中一部分 |
把三类内容放在同一层，不只是为了协作。它们之间还会互相转化。例如，从 Session 中提取 Pattern 并形成 Skill，就是记录向能力的转化。
Session blame 是另一个例子。要理解一段代码为什么这样修改，需要同时找到当时的对话、对应代码，以及 Agent 所依赖的规范。
Git blame 可以把一行代码定位到 Commit，但 Session 与 Commit 没有天然的一一对应。Agent 生成的改动可能被人工编辑后提交，也可能拆成多个 Commit。要让 blame 稳定，需要在 Commit 上添加明确的 Session 锚点，例如在 Commit Message 的 Trailer 中写入 Session-id。这样，Commit 才能回链到对应会话。
但锚点本身还不够。如果 Session 只保存在每个人的本地 Harness 中，即使 Commit 中存在 Session ID，也没有统一、持久且可共享的存储可以查询完整对话。
因此，Session blame 不是一个可以独立存在的功能。它依赖 Context Layer。
Context Layer 最终会以什么形态出现，目前还不确定。它可能是 MCP、CLI、桌面应用，也可能是 Web App 与 Daemon 的组合。Linear、Multica 和 Raft 也可能继续向这个方向演化。