上下文管理全景：Agentic Coding 工具操纵 Messages 数组的六种策略
一个常见的直觉是：agentic coding 工具会"偷偷"管理对话历史。MCP 工具在第一轮取回了一大段数据库查询结果，模型分析完毕，过了十轮对话之后，工具应该已经悄悄把那段原始数据替换成了一句"此前查询了一段数据"。输入 token 因此减少，成本随之下降。 实际情况并非如此。不开 compact 或 prune，messages 数组就原封不动地增长。那段数据库查询结果会从第一轮一直带到第一百轮，每次 API 调用都完整发送，按全价计费。 这引出了一个工程问题：面对一个只增不减的数组，各家 agentic coding 工具到底有哪些操纵手段？这些手段如何与 prompt cache 机制交互？不同选择会导致怎样的成本和信息保真度差异？ 本文是对 Claude Code 源码深度解析 和 Agentic Coding 深度解析 的差异化补位。前两篇分别覆盖了 Claude Code 的五级压缩流水线和 messages 数组的五维操纵模型（注入 / 定位 / 保护 / 清理 / 重复）。本文专注于跨工具的策略全景，以 prompt ...
NRW 仲裁参数——分布式副本读写的数值问题
问题 分布式系统把数据复制到 N 个节点上。写入时让 W 个节点确认，读取时查询 R 个节点。W 和 R 取多少，才能保证读到最新写入的数据？ "取多数派"是工程师最常见的直觉回答，但"多数"到底是多少——N 的一半多一个？还是 N 的三分之二？这两个数字分别在什么条件下出现，背后的推导和权衡，远比"取多数派"三个字复杂。 起源：Gifford 加权投票（1979） NRW 模型的源头是 David K. Gifford 在 1979 年 SOSP 会议上发表的论文 Weighted Voting for Replicated Data。Gifford 的模型比今天常见的等权版本更一般化：每个副本节点被分配一个投票权重 wᵢ，所有节点的总票数 V = Σwᵢ。读仲裁所需票数 Vr 和写仲裁所需票数 Vw 必须满足两个约束： 12约束 1：Vr + Vw > V约束 2：Vw > V / 2 约束 1 保证任何一次读操作至少触碰到一个持有最新版本的节点——读集合和写集合必然有交集。约束 2 保证任何两次写操作至...
共识算法推导——从鸽巢原理到 Paxos、ZAB 与 Raft
问题 三台服务器要对"当前值是什么"达成一致。任何一台随时可能宕机，网络消息可能延迟或丢失。怎样设计一套协议，使得所有正常运行的节点最终看到同一个结果？ 这就是分布式共识问题。Paxos、ZAB、Raft 用不同的方式回答了这个问题，但背后的数学内核只有一个——鸽巢原理推出的多数派交叉。 唯一需要的数学工具 鸽巢原理 鸽巢原理（抽屉原理）是高中数学竞赛的常客：n+1 只鸽子飞进 n 个巢，至少有一个巢里有两只鸽子。 多数派一定交叉 设集群有 N = 2f + 1 个节点，f 是允许同时宕机的节点数。多数派（quorum）的大小是 f + 1。 任取两个多数派 Q₁ 和 Q₂： 1|Q₁| + |Q₂| = (f+1) + (f+1) = 2f+2 > 2f+1 = N 元素总数超过了全集大小，鸽巢原理给出结论：Q₁ ∩ Q₂ ≠ ∅，至少有一个节点同时属于两个多数派。 这条性质是 Paxos、ZAB、Raft 共同的地基。后面的推导都建立在它之上。 从零推导 Paxos 单提案者：没有任何困难 集群里只有一个提案者（proposer），问题极其简单： ...
英语语法的骨架：时态、从句和修饰语怎么连起来
学英语语法最容易乱，不是因为术语太多，而是因为很多术语根本不在同一层。时态属于谓语系统，从句属于句子嵌套，修饰语属于短语或句子的依附关系，中心语属于短语内部结构，同位语又是一种“重新命名”的关系。把它们平铺背下来，会像把城市、街道、门牌号和交通规则放在同一张清单里。 更稳的顺序是：先抓句子骨架，再看谓语怎样表达时间和状态，再看名词短语怎样扩张，最后处理从句、非限定动词和省略结构。 mindmap root((英语语法总图)) 句子层 主句 从句 并列 从属 谓语层 限定动词 时态 体 进行 完成 情态 语态 短语层 中心语 补足语 修饰语 嵌套层 名词性从句 关系从句 状语从句 压缩层 V-ing V-ed to do 省略 be 信息层 已知信息 ...
OpenAI Beneficial RL 论文解读：对齐的本质是人格而非规则
OpenAI 于 2026 年 6 月发布论文《Reinforcement Learning Towards Broadly and Persistently Beneficial AI》，提出一个核心命题：对齐的有效单位不是规则（rule），而是特质（trait）。只需在 5% 的训练数据中强化有益行为特质，模型即可在从未见过的领域、任务和评估场景中展现一致的对齐改善——甚至同时获得能力增益。 这一结论如果成立，将从根本上改变对齐研究的工程路径：穷举场景写规则这条路走不远，但塑造人格特质或许可以 scale 到超级智能。 方法论：15 种特质 × 12 个领域 论文定义了 15 种有益行为特质（beneficial behavioral traits），覆盖认知诚实和社会伦理两个维度： 认知维度：truthfulness（事实诚实）、epistemic humility（认知谦逊）、metacognitive transparency（能解释自己的推理过程）、corrigibility（可纠正性）、calibrated uncertainty（校准不确定性）。 社会维度：ris...
Kafka 与 RocketMQ：两种消息系统的设计选择
上一篇解决了生产运维中的集群扩缩与故障排查。这一篇进入对比视角。 两套系统面对同一类问题——高吞吐消息传递——各自作出了一组互斥的选择，这些选择决定了各自擅长什么、在什么场景下会出现明显短板。 架构差异速览 12345678910111213141516Kafka RocketMQ───────────────────────── ──────────────────────────────存储: partition 文件 存储: CommitLog (单文件) + 每个 partition 独立段 ConsumeQueue (消费索引)控制: ZooKeeper (旧) 控制: NameServer (轻量) KRaft (自 Kafka 2.8 起)消费: consumer group + partition 消费: consumer group + queue 静态/动态分配 ...
生产运维：集群扩缩、监控指标与故障排查
上一篇解决了安全体系的认证、授权与加密。这一篇进入生产运维。 生产运维容易被理解为"改配置 + 重启"。更准确的说法是：Kafka 集群的运维本质上是对分布式日志的分区所有权、副本状态和元数据的受控迁移，每一步操作都在改变哪些 broker 持有哪些 partition 的哪个角色。 本文只抓三个问题：如何安全地扩缩 broker，应该盯哪些 JMX 指标，以及遇到常见故障时从哪里开始排查。 集群扩缩容模型 Kafka 集群的 broker 状态可以用一个简化模型描述： 123456789101112当前集群: [broker-0, broker-1, broker-2]partition 分布: topic-A-0 -> leader=0, follower=[1,2] topic-A-1 -> leader=1, follower=[0,2]加 broker-3 后: broker-3 加入集群，无 partition -> 手动触发 partition reassignment topic-A-0 -> leader=0...
安全体系：认证、授权与加密
上一篇分析了性能模型。这一篇进入生产环境的另一个关键维度：安全。 Kafka 早期版本没有内置安全机制——客户端连上 broker 就能读写任意 topic。自 0.9 版本起，Kafka 逐步引入了认证、授权和加密三层安全能力。这三层各自解决一个问题：认证确认身份，授权控制权限，加密保护传输通道。 本文只抓一个问题：Kafka 的安全体系如何分层工作，每一层的配置和机制是什么。 三层安全模型 1234567891011Client Broker | | |--- TLS handshake ------------>| Layer 3: Encryption |<-- certificate exchange ------| (通道加密) | | |--- SASL authentication ----->| Layer 1: Authentication |<...
性能模型：吞吐、延迟与调优思路
前面的文章覆盖了 Kafka 的核心机制和生态组件。这一篇回到工程视角：Kafka 的性能模型到底长什么样。 性能调优容易变成一张参数清单。更有效的方式是先建立一个吞吐-延迟的基本模型，再用这个模型解释每个参数的作用方向和代价。 本文只抓一个问题：Kafka 的吞吐和延迟分别由哪些因素决定，调节一个参数时另一端会发生什么变化。 性能基础：四个底层机制 Kafka 的高吞吐不是来自某个单一优化，而是四个机制叠加的结果。 1234567891011Producer Broker Consumer | | | |-- batch N records ---->| | | (linger.ms window) |-- sequential append --> | | | (page cach...
Schema Registry 与数据治理：给消息加上契约
上一篇解决了数据管道的标准化。这一篇解决管道里的数据该长什么样——消息的 schema 治理。 消息格式的约定容易被忽视。producer 和 consumer 对消息格式的理解仅靠代码约定和口头沟通时，任何一方的字段变更都可能在运行时导致反序列化失败。Schema Registry 的目标是把这种隐式约定变成显式的、可验证的契约。 本文只抓一个问题：Schema Registry 如何通过版本化 schema 和兼容性检查，在不停机的情况下实现消息格式的安全演进。 没有 Schema 治理时的问题 12345678910Producer v1 Consumer v1{name: "alice"} → 解析 {name} ✓Producer v2 (加字段) Consumer v1 (未升级){name: "alice", → 解析 {name, age} ？ ...