守株阁

AI Coding 产品常被放进一张“功能对比表”，但模型、API、Harness 和最终产品并不在同一层。把 Kimi 模型和 Claude Code 的本地文件扫描放在一起比较，或者用 API 的 Prompt Cache 解释 CLI 的 Skill 热更新，都会制造错误结论。 更稳定的比较单位是 Coding Harness：它位于模型与代码仓库之间，负责发现指令、装配上下文、暴露工具、执行 Hook、派生子 Agent，并在长会话里处理压缩与恢复。 核验日期：2026-07-17。表格只记录官方文档和官方更新日志能够支持的事实。未公开的实现统一标成“未知”，不根据相似产品补齐。 先确定比较层级 层级 主要职责 不应混入的结论 模型 推理、上下文容量、工具调用格式、多模态能力 不负责扫描本地 SKILL.md API / Provider 请求协议、鉴权、缓存计费、托管工具 不等于 CLI 每轮如何装配上下文 Coding Harness 指令发现、Skill 目录、工具运行、compact、Hook、子 Agent 本文的主要比较对象 能...

Skill 加载看起来像一个文件读取问题，实际包含两条不同的链路： 宿主进程何时扫描、解析并缓存 SKILL.md Skill 内容何时进入模型可见的上下文 两条链路可能一早一晚。OpenCode 会在宿主侧初始化 Skill registry，但模型仍要调用 skill 工具才会看到正文；Claude Code、Codex、Cursor 和 Kimi Code 也都把轻量目录与完整说明分开处理。用“启动时有没有读文件”判断是否按需加载，很容易得出相反结论。 更准确的问题有三个：模型启动时看到了什么，正文以什么形式进入会话，长会话压缩后哪些内容能够恢复。 核验日期：2026-07-17。产品实现会持续变化。正文把官方公开契约、源码观察和未知行为分开标注，不用一个产品的行为推断另一个产品。 比较对象必须处在同一层 模型、API、Harness 和最终产品经常共用一个名字，但它们负责的事情不同。 层级 负责什么 例子 模型 上下文上限、推理、工具调用能力、多模态 Claude、GPT、Kimi K2 API / Provider 请求协议、缓存计费、Too...

Coding Agent 的上下文并不是一份不断增长的聊天记录。模型每次决策前看到的输入，来自项目指令、Rules、Skill、工具定义、会话历史、外部记忆和运行时事件。它们由不同组件保存，在不同时间进入工作窗口，也由不同机制负责恢复。 如果不先划清组件边界，几个常见问题会混成一团：AGENTS.md 和 Skill 谁优先，MCP 与 Tool Search 是否相同，Hook 算不算上下文，Subagent 是工具还是新会话，compact 后恢复的是历史还是外部材料。 这套系统更接近一台上下文操作系统。模型只处理当前工作集；Harness 负责装配、换页、执行、隔离和验证。 核验日期：2026-07-17。本文讲稳定组件和边界。各产品的版本差异集中在实现图谱中维护。 上下文系统的五类组件 同一个 Markdown 文件可能同时带有说明、脚本入口和资源链接，但在运行时仍可以按职责拆成五类。 组件类别 主要对象 回答的问题 内容源 System prompt、AGENTS.md、CLAUDE.md、Rules、Skill、Memory、文件 有哪些材料可以进...

AI Coding Agent 的能力加载，已经从「启动时读几份规则文件」发展成一套完整的上下文控制面。 这套控制面要处理发现、触发、注入、隔离、压缩恢复、权限和分发。Skill 只是其中一个可复用单元，不等于整个上下文系统。 事实核验截止日期：2026-07-17。文中版本与日期均链接到官方 Changelog、官方文档或官方仓库；living docs 没有发布日期时，只按本次访问结果描述当前行为。 先把四个层次分开 不少比较把模型、API、Agent Harness 和最终产品混在一起，结论因而从起点就错位。 模型层决定上下文窗口、注意力分布、推理能力和工具调用能力。 API 层提供 instructions、tools、input items、prompt cache、compaction 等原语。 Harness 层扫描规则与 Skill，组装上下文，调度工具、子 Agent 和压缩流程。 产品层再叠加编辑器、CLI、插件市场、权限界面、团队策略和云端执行。 flowchart TB M["模型层<br/>窗口、注意力、推理、工具调用&...

测试夹具这个中文词带着工业感，让第一次听到它的开发者往往去搜索"是不是翻译错了"。词源确实如此：fixture 来自机械加工，后来进入电子测试领域，再由 Kent Beck 引入软件测试框架里。这个词在软件工程里覆盖的范围，也远比"单元测试"要宽。 从车间到代码 fixture 这个词在机械加工里有精确含义：在 CNC 车床或焊接台上，fixture 是一种工装，把工件固定在已知位置，让每次加工操作都从相同的起点开始。与 jig（引导刀具路径的夹具）不同，fixture 的职责只有一件事——把工件钳牢，消除定位误差。 词源上，fixture 来自拉丁语 figere（刺入、固定），经 fixura（固定物）演变为英语词汇，约在 16 世纪末进入法律语言，最初指"永久附着于不动产的动产"——嵌入墙体的管道、固定在地板上的书架，那些不能随意拆走的东西。 电子测试领域用法相似：一块 PCB 插入测试夹具后被固定在已知电气状态，探针才能重复施加相同的激励、在相同节点读取信号，排除接触不稳定的干扰。 三种用法的共同语义：将某个对象...

上一篇解决了 Spark 的性能诊断方法。这一篇进入设计对比——Spark 和 Flink 两种计算引擎的架构选择。 这不是一个"谁更好"的问题。Spark 和 Flink 从不同的起点出发，做了不同的设计取舍，各自在擅长的场景中有结构性优势。Spark 从批处理出发，用 micro-batch 扩展到流处理；Flink 从流处理出发，把批看作有界流。两条路线在功能上逐步趋同，但底层架构的差异导致了性能特性和适用场景的持久分化。 本文只抓一个问题：两个引擎在执行模型、状态管理、容错机制和延迟特性上的具体差异及其设计原因。 执行模型对比 Spark 的执行模型是 Stage-based DAG：把计算图按 Shuffle 边界切成 Stage，每个 Stage 包含一组可以 pipeline 执行的窄依赖变换。Stage 之间是全局同步点——上游 Stage 的所有 Task 必须全部完成后，下游 Stage 才能启动。 1234567891011Spark 执行模型: Stage 0: [Task 0] [Task 1] [Task 2] 全部完成 ...

上一篇解决了动态资源分配和调度策略。这一篇进入性能诊断——当 Spark 作业慢了，怎么找到瓶颈。 性能调优的第一步不是改配置，是定位问题。Spark UI 提供了五个关键页面（Jobs、Stages、Storage、Environment、Executors），每个页面指向不同类型的性能问题。Event Log 提供了离线分析的完整数据。 本文只抓一个问题：面对一个慢作业，如何从 Spark UI 的指标出发，沿着诊断路径找到根因。 Spark UI 五个页面 1234567891011121314151617181920212223Jobs 页面 → 每个 Action 对应一个 Job → 关注: Job Duration、Failed Tasks 数量 → 入口: 找到最慢的 Job，点击进入 Stage 详情Stages 页面 → 每个 Stage 的 Task 统计 → 关注: Task Duration 分布、Shuffle Read/Write、GC Time → 核心: 这里是定位性能问题的主战场Storage 页面 → 缓存的 RDD/DataF...

上一篇解决了 Spark 在 YARN 和 K8s 上的部署模式。这一篇进入资源调度——在多个作业共享集群时，Spark 如何动态分配和回收资源。 默认情况下，一个 Spark 应用在启动时申请固定数量的 Executor，作业结束前一直占用。这在单用户开发环境下可以接受，在多租户生产集群中会造成严重的资源浪费——一个空闲的 Spark 应用占着 100 个 Executor 不释放，其他作业排队等待。 本文只抓一个问题：动态资源分配如何按需申请和释放 Executor，以及 FAIR 调度器如何在多个作业之间公平分配资源。 动态资源分配（DRA） Dynamic Resource Allocation（DRA）允许 Spark 应用根据工作负载动态增减 Executor 数量：有 pending Task 时申请新 Executor，Executor 空闲超时后释放。 12345678910111213141516作业生命周期中的 Executor 数量变化: Executor 数量 8 │ ┌────┐ 6 │ ┌────┤ ├──...

上一篇解决了流处理的时间语义。这一篇进入部署架构——Spark 如何在不同的集群管理器上运行。 Spark 的一个设计决策是把计算引擎和资源管理解耦。SparkContext 通过 SchedulerBackend 接口与集群管理器交互，不绑定任何特定的资源管理系统。这让同一份 Spark 代码可以运行在 Standalone、YARN、Kubernetes 或 Mesos 上，只需要切换启动参数。 本文只抓一个问题：Client Mode 和 Cluster Mode 的区别，以及 YARN 和 Kubernetes 两种主流部署模式各自的架构特点。 Driver 和 Executor 的角色 123456789101112131415┌──────────────────────────────────────────────────┐│ Driver (SparkContext 所在进程) ││ ├── DAGScheduler: RDD → Stage ││ ├── TaskScheduler...

上一篇解决了 Structured Streaming 的基本模型。这一篇进入时间语义——事件时间、水位线和状态管理。 流处理中的"时间"不是一个简单的概念。一条消息有两个时间戳：事件时间（Event Time，事件实际发生的时间）和处理时间（Processing Time，Spark 收到消息的时间）。两者可能差距很大——网络延迟、消费积压、跨时区传输都会导致消息乱序到达。 本文只抓一个问题：Watermark 如何告诉 Spark “多晚的数据还值得等”，以及 State Store 如何持久化窗口状态。 事件时间 vs 处理时间 123456789101112事件发生 网络传输 Spark 收到 t=10:00:01 ~~~延迟 3s~~~ t=10:00:04 (Processing Time) t=10:00:02 ~~~延迟 1s~~~ t=10:00:03 t=10:00:03 ~~~延迟 8s...