AI Coding Agent 每次调用模型，都要临时拼出一份工作集。系统指令、用户需求、仓库规则、Skill、工具定义、检索结果、历史消息和外部记忆，经过筛选和排序后进入模型上下文。工具返回的新事实又会写回消息历史或外部状态，供下一轮使用。

这套机制分散在 Harness 的多个组件里，却承担着类似操作系统的职责：发现信息源，解析作用域和优先级，分配有限的 token 空间，调度外部能力，保存执行状态，在压缩或换会话后恢复工作集。

AI Coding Agent 上下文操作系统的组件与生命周期

“上下文操作系统”是一个分析框架，不对应某个产品里的单一模块。它把 Coding Agent 中所有影响模型可见内容的机制放在同一张图上，便于讨论组件边界、运行时生命周期和故障位置。

上下文操作系统管理六类动作

上下文管理可以拆成六类相互独立的动作：

  • 发现：扫描仓库指令、Skill、工具、插件和可检索的数据源。
  • 裁决：按照来源、作用域和优先级解决指令冲突。
  • 选择：从候选信息里挑出本轮需要的内容。
  • 编排：把内容放进 system、tools、messages 或外部引用的合适位置。
  • 改写：追加、截断、裁剪、压缩、外置或重放历史。
  • 持久化：把任务状态、证据和检查点保存到上下文窗口之外。

这六类动作覆盖了从会话启动到任务结束的主要变化。具体产品可以采用不同文件名、角色映射和加载时机，但都绕不开同一组资源约束：有限窗口、指令冲突、信息时效、工具副作用和验证成本。

组件结构

flowchart TB
    subgraph Sources["上下文来源"]
        I["系统与项目指令"]
        U["用户意图"]
        K["Skill 目录与正文"]
        M["外部记忆与检索索引"]
        T["工具 / MCP / 插件能力目录"]
    end

    subgraph Harness["Harness 控制面"]
        P["作用域与优先级解析器"]
        R["能力路由与检索器"]
        A["Context Assembler"]
        C["缓存、裁剪与压缩器"]
        S["会话状态与检查点"]
    end

    subgraph Runtime["模型与执行循环"]
        L["LLM API"]
        G["Agent Loop"]
        E["工具执行环境"]
        V["测试、权限与验收门"]
    end

    I --> P
    U --> P
    K --> R
    M --> R
    T --> R
    P --> A
    R --> A
    C <--> A
    S <--> A
    A --> L
    L --> G
    G --> E
    E --> V
    V -->|"结果与证据"| A
    G -->|"进度与决策"| S

这张图划出了三个边界。上下文来源负责保存候选信息；Harness 控制面决定本轮模型能看到什么；执行循环负责调用模型和工具，并把结果送回控制面。工具的 schema 可以进入上下文，工具本身仍在外部环境执行。外部记忆也不会自动影响模型，只有被检索和装配的片段才会进入本轮工作集。

组件职责

组件 负责的问题 常见故障
作用域与优先级解析器 哪条指令生效，冲突时听谁的 规则互相覆盖、目录作用域误判
能力路由与检索器 本轮需要哪个 Skill、工具或记忆片段 能力未发现、描述误触发、召回噪声
Context Assembler 哪些内容以什么顺序进入模型调用 重复注入、重要信息落入低利用区
会话状态 保存消息、任务进度和当前决策 历史膨胀、旧假设长期滞留
缓存与压缩器 控制成本，并在窗口不足时重写工作集 缓存失效、摘要丢约束、恢复不完整
外部状态 保存可跨压缩、跨会话读取的事实和检查点 状态过期、来源不明、无法追溯
工具执行环境 读取文件、运行命令、调用外部系统 权限越界、副作用不可回滚
验收门 用测试、规则和审批拒绝错误结果 验证缺失、检查结果未回灌

一次任务的上下文生命周期

flowchart LR
    D["发现<br/>指令、Skill、工具、记忆"] --> P["解析<br/>作用域与优先级"]
    P --> A["装配<br/>稳定前缀与本轮工作集"]
    A --> L["模型调用"]
    L -->|"需要外部能力"| E["加载 Skill 或执行工具"]
    E --> W["写回<br/>结果、证据、进度"]
    W --> A
    L -->|"形成候选结果"| V["验证"]
    V -->|"继续迭代"| A
    V -->|"阶段完成"| X["外置检查点"]
    A -->|"窗口或成本触发"| C["裁剪 / Compact"]
    C --> H["重建工作集"]
    H --> A

启动阶段建立能力目录和基础约束。每轮调用前，Assembler 读取当前任务状态，把稳定指令、最近消息和按需材料组合起来。模型需要外部信息时，Harness 加载 Skill 正文或执行工具；返回结果进入消息历史，同时把长期有效的事实写到外部状态。

消息增长到预算边界后，裁剪或 compact 会重写历史。恢复质量取决于检查点是否包含未完成目标、关键约束、已有证据、当前进度和下一步验证方式。缺少其中任意一项，压缩后的 Agent 都可能继续执行，却已经偏离原任务。

阶段完成时还要决定继续同一会话、compact、委托子 Agent，还是从 checkpoint 启动新会话。《Agent 会话边界设计》专门讨论 durable session、active context、工作阶段和 Agent 边界怎样组合。

哪些内容进入模型调用

信息类型 默认位置 生命周期
基础行为与安全约束 稳定指令前缀 会话内长期存在
仓库和目录规则 按作用域选出的指令区 随工作目录变化
工具定义与能力目录 tools 或能力索引 随启用能力变化
用户需求与近期交互 messages 尾部 持续追加，可能被压缩
Skill 正文与参考资料 按需加载区 任务需要时进入，可再次加载
检索结果与工具输出 tool result 或等价消息 短期有效，适合裁剪或外置
计划、证据与检查点 外部状态，需要时重新读取 跨压缩、跨会话保存

同一份信息可以在不同产品里映射到不同协议位置。稳定的分析单位应当是“来源、作用域、注入位置、存活时间和恢复方式”，具体字段名和目录名放在带版本日期的实现文章中维护。

五个工程问题

指令怎样解决冲突

系统级约束、用户需求、项目规则、目录规则和 Skill 指令可能同时出现。优先级只解决一部分问题，作用域和时效同样重要。离当前文件最近的规则未必拥有最高协议权重；协议位置更高的规则也可能因为过于宽泛而缺少执行细节。

这部分需要同时观察静态文件继承关系和最终 API 请求。只读配置文件无法确认实际注入位置，只抓请求也无法解释规则从哪个目录被选中。

能力怎样从目录变成工作集

Skill、工具和 MCP server 都有“目录规模大于本轮需求”的问题。能力目录负责发现，路由器负责缩小候选集，加载器负责取回正文或 schema，执行器负责产生结果。把完整能力池长期塞进 prompt 会挤占任务空间；只保留名字又可能让路由失去判断依据。

可调试的实现需要记录候选能力、命中原因、实际加载内容和执行结果。没有这条证据链，Skill 未生效时很难区分发现失败、路由失败、加载失败和执行偏差。

历史怎样增长和收缩

消息数组同时承担对话记录、工具轨迹和短期工作记忆。追加对结构影响最小，但历史会持续膨胀；截断成本低，却可能破坏依赖；裁剪工具输出适合可重复获取的数据；compact 能释放大块空间，但摘要会丢失细节；外置和重放把状态移到窗口之外，恢复时必须重新取数。

Prompt cache 又给这组操作增加了一层成本约束。稳定前缀有利于复用，频繁改写前部内容会扩大缓存失效范围。缓存、注意力和信息完整性需要分开衡量。

状态怎样跨越 Compact 和会话

对话历史适合保存近期因果，外部文件和存储适合保存长期事实。任务计划、关键决策、证据来源和验收结果都应有明确的写入位置。外部记忆如果没有来源、更新时间和淘汰规则，会把旧结论重新带回工作集。

恢复过程应重新读取事实源，并检查检查点是否仍然成立。摘要负责缩短历史，不能替代事实数据库、代码仓库和测试结果。

执行怎样形成闭环

模型输出只是候选动作。权限系统限制副作用，工具执行产生事实，测试和静态检查判断结果，日志记录每次装配与调用。验证结果必须回到上下文，Agent 才能依据失败证据调整下一轮动作。

这条闭环决定 Harness 是否可调试。一次执行至少要能追溯本轮注入了什么、为何选择这些内容、调用了哪些外部能力、压缩时丢弃了什么，以及哪个验证器接受或拒绝了结果。

文章矩阵

系列按“稳定机制”和“实现快照”分开。稳定机制文章解释长期不变的组件与操作；实现文章记录具体产品在某个版本里的目录、协议位置和加载时机。

层次 主读文章 解决的问题
总入口 本文 组件、边界、生命周期与阅读顺序
上下文栈 《AI Coding Agent 的上下文栈：组件边界与装配顺序》 指令、能力目录、消息、运行时状态的边界与装配关系
能力演变 《从 Rules 到 Agent Skills：能力加载机制的演变》 Rules、Commands、Skills、Hooks、Plugins 的边界与时间线
动态消息 《Agentic Coding 上下文管理全景：Messages 数组的六种操纵策略》 append、truncate、prune、compact、externalize、replay
Skill 生命周期 《AI Coding Agent 的 Skill 加载机制深度解析》 发现、路由、加载、执行与恢复
会话边界 《Agent 会话边界设计：Session、Context Window 与工作状态转移》 阶段退出、状态转移契约、reset、compact 与 Agent 边界
Context Paging 《上下文换入换出：下一代 Scaling》 工作集、compact 和重建
外部记忆 《智能体外部记忆的文件标准与用途全景》 持久化层次、生命周期和治理
Turn 生命周期 《一次 AI Coding Agent Turn 的上下文生命周期》 装配、工具循环、Hook、权限、Compact 和 Subagent
外部协议 《Agent 互操作协议全景》 MCP、A2A、AG-UI 与 Runtime 的边界
产品实现 《2026 Coding Harness 实现图谱》 Claude Code、Codex、OpenCode、Cursor 与 Kimi Code 的版本化事实表

Skill 与项目规则

《Anthropic Skill 半年演化史》记录 Skill 标准、渐进披露和评测方法。《Superpowers Skill 体系》展示流程型 Skill 怎样改变 Agent 行为。《如何写好 AGENTS.md》讨论常驻项目地图的内容边界和治理方式。跨工具载体分类统一放在《上下文栈：组件边界与装配顺序》。

Skill 的生产与分发属于另一条链路。《从一个 Git 仓到 Skill Hub》讨论镜像、索引、原子同步和部署，不与运行时加载混在一起。

产品和生态案例

《Claude Code 源码深度解析》覆盖 prompt、cache、compact、tools、MCP、Skills 和 memory。《OpenCode 自研 SDD 流程注入方案》展示不同协议位置怎样影响指令强度。《OMC vs OmO 深度对比》记录 session、fork、memory、Skills 和 MCP 的生态差异。

这些文章适合回答“某个实现如何工作”，不适合承担永久规范。目录路径、默认加载时机、注入角色、token 数字和缓存策略都可能随版本变化。

上下文隔离

《子 Agent 的本质：上下文隔离与专门化》解释独立工作集的价值。《Agent Teams 为什么有效》讨论任务拆分、信息隔离和合并成本。《Multi-Agent 架构深度解析》补充拓扑、通信和编排结构。

阅读路径

  • 排查“规则为什么没生效”：上下文栈 → 能力演变 → Skill 生命周期 → 对应产品实现。
  • 排查“长任务为什么失忆”：Messages 六策略 → 会话边界 → Context Paging → 外部记忆 → 子 Agent 上下文隔离。
  • 设计工具和插件：组件结构 → Hook Loop → Agent 互操作协议 → Context7 MCP Server 深度解析。
  • 建设长程 Harness：会话边界 → Context Paging → 《Harness 的本质》 → Hook Loop → Spec 与测试体系。

原路线图的外围工程

原来的 Harness 路线仍然保留，只是不再与上下文机制挤在同一条主线里。

《裸模型为什么像抽卡》解释概率输出和验证边界。《环境可供性：智能的一半是取到正确数据》讨论检索、工具和数据入口。《Harness 的本质：把随机模型锁进可验证的箱体》连接 Spec、测试、权限和循环。《AI 不会吞掉软件，只会吞掉入口》把 Agent 放回软件入口的演化中。

工程手册仍可参考 《Harness Engineering 完整指南》和 《Harness Engineering：长程 Agent 的工程化底座》。流程与验收层可继续阅读 《SDD 与超级个体》和 《OpenSpec 实战指南》。

稳定结论与版本事实

适合长期保留在总入口里的内容包括组件职责、信息生命周期、上下文操作类型和验证闭环。具体产品的目录、字段、默认行为、模型窗口、token 成本和缓存实现属于版本事实，应在实现文章里标注验证日期和证据来源。

这种分层可以减少两类维护问题：产品升级不会迫使整组原理文章一起改动；同一个机制也不必在多篇产品文章里重复解释。总入口负责坐标系，机制文章负责原理，实现文章负责事实快照，案例文章负责工程取舍。