Codex 架构全景：本地运行、云端长任务与多层 Loop
Codex 的架构需要同时回答两个问题：一次编码请求怎样完成，以及请求结束以后，什么状态还能保留、谁会再次启动工作。前一个问题涉及模型、工具和 Harness；后一个问题涉及会话、目标、执行环境、调度和身份。 “Codex 在本地运行”通常表示工作区和工具在本机，模型推理仍可以发生在 OpenAI 的服务器。“Desktop 连 Remote”通常表示客户端通过 SSH 控制远端 App Server；“Cloud 长期运行”则包含托管执行环境及其生命周期。这些模式可以共享执行框架，却承担着不同的运行责任。 本文以 2026 年 10 月 15 日读取的官方产品文档和 Codex rust-v0.162.1 源码为基线，并在 2026 年 10 月 23 日复核 Remote、App Server 与 Code Mode host 的公开边界。源码固定在 092d3acd6bec3e3a14bdc7e7a2810ab628ab759d，提交日期为 2026 年 10 月 9 日；本地 codex --version 为 codex-cli 0.162.1。文中的拓扑是根据公开接口...
Flink 生产部署拓扑与组件职责
Flink 作业能从 Kafka 读到数据，并不意味着它已经具备生产恢复能力。任务运行在什么进程、状态存在哪里、谁负责申请资源，以及故障后从哪个位置继续处理，需要在部署时分别确定。 本文以 Apache Flink 2.3 文档为基线，讨论有状态流作业的生产拓扑。图中的连接区分任务调度、记录传输与状态持久化；对象存储、Kafka 和 Kubernetes 都是外部系统，不属于 TaskManager 内部组件。批处理的调度与 shuffle 策略另有配置，不能把下面的持续流水线直接套用到所有有界作业。 集群内外的职责 JobManager 负责协调执行，TaskManager 执行 source、转换和 sink。业务记录通常在 TaskManager 及外部系统之间流动，不需要经过 JobManager 转发。客户端负责提交；作业以 detached 方式启动后，客户端退出并不等于作业结束。 图 1：Flink 控制连接、业务数据与快照存储的边界 flowchart TB C["客户端"] -.->|"提交"| JM["...
Kafka 生产部署拓扑与组件职责
Kafka 的部署单元包括控制器、保存分区副本的 Broker，以及运行生产者、消费者和数据管道的应用进程。三类进程承担不同负载，扩容和故障恢复也有不同边界。只画几个 Broker，容易漏掉元数据多数派、客户端网络地址和内部主题这些影响可用性的条件。 本文以 Apache Kafka 4.3 文档中的 KRaft 部署为参照。Kafka 4.0 起不再支持 ZooKeeper 模式；旧集群迁移需要经过兼容的 3.x 版本。图中的三控制器、三 Broker 是解释故障域的示例，不是所有业务的容量配置。 控制面与数据面 控制器维护 Broker 注册、主题和分区元数据，决定分区领导者等集群状态。Broker 保存业务日志副本并响应生产和消费请求。业务消息无需经过控制器转发，控制器的副本数也不决定业务主题的副本数。 图 1：KRaft 控制面与业务数据面的部署边界 flowchart TB subgraph CP[控制面：独立控制器进程] C1[Controller 1] --- C2[Controller 2] C2 --- C3[Controller 3] ...
Kubernetes 生产部署拓扑与组件职责
Kubernetes 的对象模型只有放进真实的生产拓扑里，组件职责和故障边界才会变得清楚。控制面负责接受期望状态、保存状态并作出调度与调谐决策；节点侧负责把已经绑定到本节点的 Pod 变成容器、网络和存储挂载。两侧通过 API 对象协作，而不是彼此直接调用全部内部组件。 本文集中画出生产环境里最容易混淆的十四条关系：控制面与工作节点、API 请求、控制器、调度器、节点执行、服务流量、存储与网络插件、探针、滚动发布、节点故障、etcd 仲裁、备份恢复和多可用区部署。图中的路径采用 Kubernetes 官方文档当前公开的稳定机制；具体版本的 feature gate、默认值和版本偏斜范围仍应以目标版本文档为准。 控制面与工作节点 图 1：Kubernetes 控制面与工作节点的生产拓扑 flowchart TB U[kubectl / CI / Controller] --> LB[API Server 负载均衡入口] LB --> A1[kube-apiserver A] LB --> A2[kube-apiserver B] L...
深入 Elasticsearch（19）：生产部署拓扑与节点角色划分
三节点实验集群能验证发现、选举和分片复制，但不能直接推导出生产拓扑。生产设计必须同时回答四个问题：哪些节点参与控制面，哪些节点承担数据面，故障域如何隔离，以及任一节点或可用区退出后，剩余容量能否继续承载业务。 本文面向自建 Elasticsearch 8.x/9.x 集群，给出从小型混合角色集群到分层数据节点集群的参考拓扑。具体节点数、分片数和硬件规格仍应以目标版本和真实负载压测为准；Elastic Cloud Serverless 的资源模型不适用这里的自建配置。 先选拓扑，再写配置 生产集群没有一套固定节点清单。轻负载可以让节点混合承担 master、data 和 ingest；规模扩大后，再把控制面和高消耗的数据处理职责拆开。角色拆分的目标是隔离资源竞争和故障影响，不是让节点名字更多。 图 1：从实验集群到分层生产集群的演进路径 flowchart LR A[单节点开发环境<br/>全部默认角色] --> B[三节点小型生产集群<br/>master + data + ingest] B --> C[控制面分离<br/&g...
Jev 为什么像 BERT 又像 LLM：决策模型的创新与旧谱系
“虽然等了很久，但客服已经补发，先不用退款。”判断这句话的情绪，和判断用户是否要求退款，是两个任务。传统情感分类器的任务在训练时已经确定；自然语言任务接口则允许每次请求指定判断标准。 Jev 引人关注，正因为它提供了这样的接口，同时把答案限制在给定范围内：不生成一段回答，而是针对 Choice、Score、Noul 这类类型化问题返回概率结果。“像 BERT 又像 LLM”首先描述的是这种能力组合。 这种组合已有多年的技术积累。理解 Jev 的新意，需要区分自然语言怎样定义任务，以及模型怎样输出答案。 BERT 与常见 LLM 的区别 BERT 和 LLM 不是严格互斥的两个集合。BERT 本身就是语言模型，也可以做得很大。日常语境里的“BERT 类模型”通常指 encoder-only、双向注意力、以表示学习和判别任务为主的模型；“LLM”则常被用来指 decoder-only、因果注意力、逐 token 生成的大模型。 真正有区分力的是三个维度： 维度 BERT 类 encoder 常见 decoder-only LLM 注意力 token 可同时看左右文 当...
Perl：Getopt::Long 怎样区分缺参数、零值与业务错误
命令行工具的边界从参数开始。最低耗时 0 是合法筛选条件，缺少这个选项表示不筛选耗时；--min-duration -1 则违反业务规则。三种情况不能都用变量真假判断。参数解析器负责识别选项形状，应用负责定义值的含义，最后还要把失败落实到退出码和输出流。 本篇对应原定 25，使用新版 bin/logtool。原 bin/logtool.pl 的位置参数仍用于旧四字段实验。新入口采用 Getopt::Long，支持 import、query、report 三个子命令；--version 单独给出工具版本与实际解释器版本。命令例必须使用冻结解释器或明确标注本机差异，不能把环境中的第一个 perl 自动当成 5.38.2。 先选子命令，再解析它允许的选项 Getopt::Long 不会自动知道某个选项属于哪个子命令。本工具先取出命令名，为该命令构造允许的选项集合，之后调用 GetOptionsFromArray。import 允许 input、output、rejects；query 允许 input、level、min-duration、contains；report 允许 inpu...
Perl：JSON Lines 怎样保留数字、缺失值与原始消息
日志进入交换文件后，字段仍须保持原来的含义。耗时为零是一条已完成的观测，耗时缺失表示没有这个观测；消息为空仍然是一条记录。若把三者都写成空字符串，后续查询无法恢复它们的区别。JSON Lines 给每条记录独立的 JSON 文本，但行格式本身不保证类型、字段集合、排序或错误策略，这些都需要由工具定义。 本篇补齐原定课程 28，并作为 00、10、13、25、38、39 的累计数据契约。工程有两个明确入口：bin/logtool.pl 使用旧四字段 TSV，保留原系列实验；bin/logtool 使用五字段输入与 JSONL 交换。两个文件格式分别验证，不能把旧版三条记录的通过当成新版导入已经完成。完整实现位于 lib/LogTool/Course.pm，断言位于 t/course-core.t，命令重放位于 tools/replay.pl。 字段契约先于序列化 五字段顺序为 UTC 时间、等级、服务标识、毫秒耗时、消息。字段之间只有实际 TAB；消息中的 TAB、LF、反斜杠分别用 \t、\n、\\ 表达。空耗时映射到 undef，非空耗时只接受不带符号、不带前导零、最多九位的十...
Perl 原定 E08：遗留代码迁移先守住行为
遗留 Perl 常见问题不是语法旧，而是依赖藏得太深：全局路径、全局文件句柄、二参数 open、隐式 $_ 都会让调用者难以判断输入从哪里来、输出写到哪里去。迁移的第一步不是重写成新风格，而是先写出旧行为的最小回归，再把隐式依赖改成显式参数。 累计实验 examples/perl-language/experiments/course-legacy.pl 先保留一个小的 legacy 计数器：它读取全局 $CURRENT_PATH，使用全局 FH 和二参数 open，统计一行输入。迁移版本改成 migrated_count($file)，使用三参数 open my $fh, '<', $file 和词法文件句柄。TAP 断言旧版计数和新版计数都是 1，同时断言三项迁移事实：全局路径由参数替代，二参数 open 由三参数 open 替代，全局文件句柄由词法文件句柄替代。 12345678sub migrated_count { my ($file) = @_; open my $fh, '<', $file or die &qu...
Perl 原定 E07：SV、AV、HV 与 op tree 只能作诊断证据
Perl 代码里的标量、数组引用和哈希引用，在解释器内部分别会落到 SV、AV、HV 等结构；表达式会编译成 op tree。B 和 Devel::Peek 能把这些诊断信息打印出来，但它们不是跨版本 API。课程可以用它们解释“为什么引用只是指向内部值的句柄”，不能把某一行 dump 当成业务契约。 累计实验 examples/perl-language/experiments/course-internals.pl 用 B::svref_2object 查看 INFO、[1,2]、{INFO=>2}，得到 PV、AV、HV 一类名称；再用子进程执行 Devel::Peek::Dump 保存真实输出，检查其中含 PV 与 REFCNT。另一个子进程运行 B::Concise -exec 解释 my ($x, $y) = (1, 2); print $x + $y，证据文件保存完整 op tree。 123454 <$> const(IV 1) s5 <$> const(IV 2) s6 <0> padrange[$x:1,2; $...