工程实践 Cloudflare Blog 2026/09/22
文章介绍 Cloudflare 在 Cache Rules 中支持 HTTP Vary 的工程方案。Vary 让源站声明可能影响响应的请求头，但缓存无法判断差异是否真的影响响应，高基数、格式差异和 q 值会产生大量等价却无法复用的变体，降低缓存命中率。Cloudflare 把决策拆成两步：源站声明 Vary 字段，Cache Rule 决定每个字段用 normalize、passthrough 还是 bypass。normalize 对 Accept、Accept-Language、Accept-Encoding 做小写并按 q 值排序收敛到配置集合，passthrough 保留精确差异，bypass 绕过缓存，Vary:* 始终绕过。文章还说明缓存查找、变体存储和清除边界，并指出源站必须一致返回 Vary，方案仍需手工配置语言与格式。
推荐收录：文章并非单纯产品发布稿，而是围绕 HTTP Vary 的缓存语义、基数爆炸和变体归一化展开技术权衡，并给出 normalize、passthrough、bypass 的边界与 API 示例。对 CDN、缓存策略和 Web 性能工程师而言，其“源站声明差异、缓存判断差异是否重要”的设计思路和变体键管理方法可迁移到自建缓存或边缘场景；风险是带有 Cloudflare 产品语境，细节需结合文档验证。
工程实践 ScyllaDB Engineering 2026/09/22
本文复盘 ScyllaDB 用自研 C#-Rust FFI 框架重写 C# 驱动的实践，目标是在保持原 DataStax C# 驱动 API 基本不变的前提下复用 Rust 驱动的性能与正确性。作者利用 .NET 5 的改进互操作特性降低跨语言开销，并桥接 .NET 与 Tokio 异步运行时以避免阻塞线程。文章详述了序列化放在 C# 侧、以 RWLock 解决会话关闭的 TOCTOU/UAF 竞争、用 trait 映射错误、以原子快照管理元数据、转发 Rust 日志等取舍。基准显示新驱动在所有场景不慢于原驱动，高并发下约快一倍。当前开发暂停，功能完整性与维护仍待完善。
推荐收录：文章完整呈现 C#-Rust FFI 框架设计、TOCTOU/UAF 竞争修复、元数据快照与错误映射等关键取舍，并附可复现基准（高并发下约为原驱动两倍、接近 Rust 驱动）。对从事跨语言互操作、数据库驱动或高性能客户端开发的工程师有直接参考价值，会话生命周期管理、内存引用计数等模式可迁移。项目开发暂停是主要风险。
工程实践 TigerBeetle Blog 2026/09/17
文章以经典银行存取款 OLTP 负载为例，说明从通用 SQL 数据库迁移到 TigerBeetle 时，逐行照搬模型会严重损失性能。核心建议有三条：用双式记账转账和聚合账户替代多行更新与历史表；利用客户端自动批处理合并请求（最多 8189 条操作）；用近似单调递增的 TBID 替代随机 UUID 以加速幂等检查。文中称单客户端大 batch 可达约 45.4 万事务/秒（90.9 万转账/秒），而关系数据库存储过程约 7000 事务/秒，差距来自避免行锁、批处理与服务端并行 I/O。作者也说明对比仅为数量级参考，且方案依赖应用与数据库协同设计。
推荐收录。文章不是泛泛介绍产品，而是给出可验证的数据建模、自动批处理和单调 ID 三条具体优化手段，并用约 45 万 TPS 对比 7 千 TPS 说明高竞争 OLTP 的架构差异；适合后端、数据库和系统设计读者理解批处理、幂等键与应用/数据库协同设计。需注意基准来自厂商且调优经验不对等，但技术取舍和性能分析仍可迁移。
工程实践 Oxide Public RFDs
该 RFD 为 Oxide 云平台上的虚拟机实例提出身份与远程证明方案：目标是把测量链从平台 RoT 扩展到实例的启动盘摘要、UUID 与配置，向 guest 暴露证明接口，并把实例持有的临时公钥绑定到平台证明。方案用 qualifying data 把 nonce 或附加数据混入签名，propolis 作为 VM Instance RoT 将 JSON 格式的实例日志经哈希后交给 Oxide Platform RoT 签名，从而在 propolis 无签名密钥时仍能绑定实例信息。通信通道选择 vsock，采用 JSONL 协议和单一 attest 命令，32 字节 qdata 可扩展为 digest(nonce|key_pub) 以完成密钥绑定。性能测试显示平台 RoT 是瓶颈，attest 平均约 104 ms，证书链约 120 ms。当前实现只覆盖 Oxide 平台 RoT，对可变启动盘、非开源组件和 API 向后兼容性有明确限制。
推荐收录：该 RFD 系统性地给出 VM 身份与证明设计，包括 qdata 绑定、测量链扩展、vsock/JSONL 接口、SPDM 对比和 gimlet 时延基准，证据具体。适合云平台、虚拟化安全、远程证明与机密计算方向的工程师阅读；其中 nonce 加日志哈希绑定、无签名 RoT 委托签名模式和接口取舍可迁移。风险是早期设计，初始 API 可能破坏兼容且未覆盖全部 RoT/闭源组件。
工程实践 Oxide Public RFDs
本文是 Oxide 工程经验 RFD，记录控制平面 Omicron 使用分布式 Saga（Steno）执行实例启动、磁盘创建、区域替换等流程时的问题。作者指出 Saga 要求动作幂等、未定错误必须重试、永久错误不可重试、补偿不可失败，这些约束难以编码和验证；静态 DAG 与软件升级强耦合，卡住或废弃的 Saga 无法自动恢复，更新可能阻塞或冒险恢复。文章比较背景任务/协调器模式：周期性重取状态、每次只决定下一步，并用事务、声明式 API 和 generation 号保证并发安全，使错误可由软件更新修复且不阻塞升级。结论是新增工作应优先考虑背景任务，选择 Saga 必须规划废弃与修复；但作者并未主张完全移除 Saga，部分场景改写仍有挑战。
推荐收录：该 RFD 以 Oxide 生产系统为证据，系统梳理了分布式 Saga 在幂等、未定错误、补偿失败、升级和废弃恢复上的具体故障模式，并给出 reconciler/background task 的替代设计与并发安全手段。对构建控制平面、工作流引擎、分布式事务或可靠性系统的工程师与研究者有很高迁移价值，可帮助在 Saga 与协调器模式间做架构取舍；需注意其结论绑定 Oxide 的 Omicron/Steno 场景，并非通用定论。
工程实践 Oxide Public RFDs
RFD 373 讨论控制平面中的可靠持久工作流（RPW）：持续将数据库期望状态与 DNS、VPC、软件更新等目标的运行时状态对齐，而非一次性 saga。文章提出三条约束——目标最终获知更新、所有目标按同一顺序收敛、单目标离线不阻塞其他目标，并比较周期激活、全量/增量更新、generation number、目标驱动与 Nexus 驱动等模式。文中否定在 API 请求内联更新、按变更创建 saga 或使用队列，指出会导致顺序错乱、无界积压或惊群；也讨论分布式互斥难题，倾向让目标串行化请求。结论是将 RPW 作为一等抽象并从 DNS 落地迭代；但多数设计未实现，部分示例仍需验证。
推荐收录。该文档不是泛泛介绍，而是给出 RPW 的明确约束、generation number、全量/增量传播、目标驱动与 Nexus 驱动、互斥与队列等模式的逐项取舍，并系统分析内联更新、滥用 saga/队列等反模式；适合构建控制平面、分布式协调、Kubernetes 控制器或自愈系统的工程师。其 reconciliation、激活模型和可观测性设计可直接迁移到类似场景，但部分章节作者自述不确定，落地前需结合实现验证。
工程实践 Oxide Public RFDs
本文是 Oxide Computer 的公开 RFD 419，探讨如何为分布式 saga 编写正确的节点。文章首先定义正确 saga 节点需满足的四个属性：补偿动作应尽量回滚前向动作或使系统保持一致、前向动作必须幂等、原子性（避免多步状态变更）以及必须得到已知结果。随后列举常见陷阱，包括在参数中使用名称引发 TOCTOU、动态状态变更的循环、无补偿动作的节点、中间状态可见导致并发 saga 冲突，以及删除与创建 saga 交错执行。文章强调 saga 并非事务，节点执行间隔可能很长，作者必须考虑重复执行、并发执行和跨时间重复的“企鹅”问题，并建议通过软删除和幂等端点来支持重试。最后指出这些约束需扩展到被调用的守护进程及其嵌套路径，但未给出强制机制，依赖代码作者和评审者的纪律。
推荐收录。本文系统总结了分布式 saga 节点正确性的四个核心属性（补偿、幂等、原子、已知结果），并列举了大量来自 Oxide 真实工程（如磁盘删除、快照创建、NIC 附加）的陷阱与应对模式，如避免参数用名、处理动态步数、防范并发 saga 交错。对设计分布式任务编排、微服务补偿流程或需要保证最终一致性的后端工程师极具参考价值，可直接迁移其检查清单。主要不足是缺少自动化强制手段，依赖作者与评审者纪律。
工程实践 Oxide Public RFDs
RFD 357 提出 Oxide MVP 的外部 DNS 方案：运维方委派一个子域，并提供 2 个以上（建议 3-10 个）客户网络 IP，由 Oxide 运行独立于内部 DNS 的权威外部 DNS 服务器。每个 Silo 获得 $silo.sys.$delegated_domain 主机名，指向同时服务控制台与 API 的 Nexus 实例，更新时采用蓝绿部署并动态迁移固定 IP 来提升可用性。TLS 证书在 MVP 中倾向通过 API 管理，因为客户环境常不暴露公网，难以使用 ACME 公网挑战。文章还讨论 DNS 最终一致性、扩展性、Cookie 作用域和备选方案，但安全考虑尚未展开，且不覆盖通用递归 DNS 与实例 DNS。
推荐收录：该 RFD 不是泛泛介绍 DNS，而是给出可执行的系统设计决定，包括委派域、外部权威 DNS 服务器、按 Silo 命名、蓝绿更新与固定 IP 迁移，并系统比较证书管理和多种备选方案。适合基础设施、网络、控制平面和系统架构读者，可迁移到多租户平台、客户自管 DNS 域名和 TLS 证书自动化等场景。主要风险是内容面向 Oxide MVP，安全考虑尚未展开，且部分细节标记为待定。
工程实践 Oxide Public RFDs
本文是 Oxide 机架控制平面的 RFD 457，定义物理 sled/磁盘与控制平面 sled/磁盘两类对象及其生命周期。作者先区分 in_service、quiesced、failed、expunged 与 graceful removal，再围绕 sled 和 physical_disk 表设计 policy 与 state，规定添加、优雅移除和 expunge 在分配、信任仲裁、电源、实例迁移、Crucible region 替换和 Omicron zone 重建上的差异。文章用 blueprint planner/executor 流程说明 sled/磁盘的添加与 expunge 顺序，并强调 expunge 必须由运维触发，避免把瞬时故障误判为永久移除。对于 expunged sled 如何确保不再启动，文中比较 Ignition 断电、服务处理器 A2 与 trust quorum，指出仍有开放问题；磁盘误拔重插则要求 Sled Agent 重新建立服务并告警。边界是 quiesce、临时维护和优雅移除细节不在本文范围，部分流程仍为 TBD，且实现与 Oxide 架构强绑定。
推荐收录：该 RFD 给出了 policy/state 分离的硬件生命周期模型，以及 blueprint planner/executor 在 add、graceful remove、expunge 时对分配、信任仲裁、数据重建和电源控制的具体处理，属于可迁移的系统设计证据。适合分布式系统、存储、可靠性与基础设施工程师阅读，尤其可借鉴优雅移除与永久移除的区分、运维触发 expunge 的风险取舍。主要风险是内容高度绑定 Oxide 控制平面，且若干流程仍为 TBD 或超出范围。
工程实践 Oxide Public RFDs
该 RFD 提出 illumos 的 GPIO 框架设计，目标是为内核和用户态提供统一管理与消费方式。文章梳理 GPIO 在 Gimlet 上的用途，并对比多种 SoC 与 GPIO 扩展器属性，论证抽象必须保留设备特定性。方案包括内核 GPIO 框架与 provider API、控制器字符设备、gpioadm 工具，以及把受约束 GPIO 定义为 DPIO，通过 /dev/gpio/:name 提供 open/read/write/poll 语义。文章还讨论 I/O muxing、策略、中断与持久化难题，并列出内核框架、AMD Milan provider、仿真驱动和用户态命令等首批交付物。边界是不支持高速 bit-banging，muxing、中断与持久化仍属探索阶段。
推荐收录：这是 Oxide 公开的工程 RFD，直接给出内核 GPIO 框架、provider API、DPIO 与 gpioadm 的设计，并逐项比较 AMD Milan、Intel C620、ST H753 等控制器差异，证据密度高。适合操作系统、驱动开发、平台固件/硬件抽象相关读者，可迁移其属性建模、DPIO 约束和 I/O muxing 数据表方法；主要风险是部分设计仍为探索阶段，不能当作最终 API 规范。
工程实践 Oxide Public RFDs
本文是 Oxide 关于虚拟机热迁移单调时间处理的公开 RFD，核心是 x86 TSC。文章说明 guest 要求 TSC 单调、恒频且启动归零，而跨主机迁移使 bhyve 传统偏移算法失效。作者结合 AMD SVM 与 Intel VMX 的 TSC 缩放/偏移机制，推导 guest TSC、offset 与频率倍率公式，并用四个场景演算。随后分析定点表示导致的溢出与精度限制，提出最大倍率上限，并讨论向下倍率漂移和 NTP 误差边界。最后列出误差建模、机架频率差异、跨迁移墙钟同步等开放问题，部分内核实现仍处原型阶段。
推荐收录：这是一份面向真实热迁移需求的系统设计 RFD，直接给出 TSC offset/倍率公式、AMD/Intel 定点表示、溢出边界和倍率取舍，证据充分而非泛泛介绍。适合虚拟化、hypervisor、OS 时间子系统与云基础设施工程师阅读，可迁移到跨主机迁移的时间一致性与数值边界验证；不足是墙钟同步、误差建模和内核接口仍留作开放问题。
工程实践 Oxide Public RFDs
本文是 Oxide 的 RFD 404，定义边界隧道路由问题并提出基于 ddm 路由协议分发隧道路由的解决方案。问题在于实例/服务发往外部上游网络的包需经 Geneve 封装到 IPv6 underlay，封装器 OPTE 需知道可用网关、如何选择多个网关以及路由变化如何传播。方案让交换机上的 mgd/ddmd 将上游前缀与边界隧道端点 IPv6 ULA 通过 ddm 通告并传播到各 sled，ddmd 再把隧道路由写入 OPTE 新增的 V2B 表，并用 metric、ECMP 哈希和路径向量协议能力处理多网关与故障。文中还给出协议对象、指标设计、与纯控制面/对称交换机配置等替代方案对比，以及安全与开放问题。边界是当前仍处讨论阶段，可扩展性、路由剪枝和 mgd 健康监控等未完全验证，主要适用于 Oxide 的 underlay/overlay 边界路由。
推荐收录，因为这是一份真实基础设施系统的设计文档，完整展示了从问题定义、路由协议选型、OPTE V2B 表设计到替代方案、指标与安全风险权衡的推理链条。适合网络、基础设施和分布式系统工程师阅读，可迁移到多机架网关路由、overlay 路由传播和故障收敛等场景；风险是仍处讨论阶段且若干可扩展性与实现细节未定。
工程实践 Oxide Public RFDs
Oxide RFD 250 讨论管理网络拓扑与“本体感知”：控制平面 MGS 如何发现 SP、推断机架位置，并让 SP 获知自身位置。文章先确立 L2 网络、SP 间隔离、每交换机隔离、VSC7448/Tofino 端口一一对应等原则，再提出用 VLAN 标签实现隔离：MGS 到 VSC7448 按目标端口打标签，KSZ8463 到 SP 用 0x301/0x302。随后说明 MAC 从 FRU EEPROM 分配、以 EUI-64 生成 IPv6、用多播和 NDP 发现地址，并通过向确定端口发探测消息判断 Sidecar A/B 位置。文章还列出备选方案、开放问题和安全考量，指出恶意 Sidecar 可重配 VSC7448 等边界。
推荐收录：这是一份公开的机架管理网络设计文档，给出了 VLAN 隔离、地址发现、位置推断和安全威胁模型的完整取舍，并包含备选方案与开放问题。适合做数据中心网络、带外管理、嵌入式 SP 通信或 L2 隔离设计的读者参考，其中“用拓扑约束替代额外硬件或协议”的思路可迁移到类似系统。
工程实践 Oxide Public RFDs
本文是 Oxide Omicron 控制面数据库的设计 RFD，围绕强一致性与可扩展性，给出多租户 API 资源（Project、Instance、VPC 等）的建模与查询模式。作者采用 UUID 主键、身份元数据、按父作用域与 name 的唯一部分索引，支持分页、重命名和软删除，并避免显式外键。文章用条件 UPDATE、CTE、generation number 与 rcgen 处理并发更新和检查-使用竞态，也比较事务、CTE、saga 的适用场景。最后分析读-改-写、长事务、双管理员并发及集合删除/创建竞态，并指出实现尚不完整、方案依赖 CockroachDB SERIALIZABLE 与具体 API 约束。
推荐收录。文章不是泛泛介绍数据库范式，而是给出可核验的表结构、唯一部分索引、条件 UPDATE/CTE、rcgen 和 saga 选择规则，并明确 CockroachDB SERIALIZABLE、软删除与双管理员并发下的边界。适合控制面、分布式数据库和后端架构读者，其中的并发控制与一致性模式可迁移到多租户 API 设计；风险是方案与 Oxide/CockroachDB 强耦合且实现未完成。
工程实践 Oxide Public RFDs
RFD 297 讨论 Oxide 系统中 Silo（多租户隔离单元）与 API 资源之间的关系，明确将资源划分为 siloed 与 non-siloed 两类。Organizations、Projects、Instances、VPC、用户等在每个 Silo 内被虚拟化，不能跨 Silo 共享甚至无法互相引用；而 Racks、Sleds、Silos、全局镜像等在所有 Silo 中保持一致。作者给出三种典型部署形态（单一 Silo、运维+终端用户两 Silo、运维+多终端 Silo），并对比它们在身份管理、IdP 审计、误操作隔离和复杂度上的取舍。文章还列出当前已实现与规划中的资源分类，讨论“运维 Silo”标记、是否生成独立 OpenAPI 规格、禁用端点应返回 404 还是 403 等开放问题，以及细粒度访问控制与灵活协作之间的安全平衡。
推荐收录，因为这是真实系统的多租户设计文档，清晰划分 siloed 与 non-siloed 资源，并以三种部署形态说明身份、审计与隔离之间的具体权衡，还保留了替代方案和开放问题。它适合负责多租户平台、API 资源层级与访问控制的设计者，“资源作用域与身份作用域分离”的思路可迁移到类似云平台或 SaaS 系统。
工程实践 Oxide Public RFDs
本文是 Oxide 的 RFD 223，讨论 Web Console 的客户端-服务端架构，并将其从 RFD 169 的认证议题中拆出。核心决定是：为避免在机架内引入 Node.js 和 npm 生态风险，Console 先做成由 Nexus 托管的静态 JS bundle，直接在浏览器调用 Nexus，并由 Nexus 接受会话 Cookie。文章对比浏览器单端、带/不带数据库连接的 Console 服务以及独立数据库方案，并分析 DDoS 缓解与 Node 依赖树风险。作者还评估 Deno、V8 Rust 绑定等服务端 JS 路径，以及共享校验、加载 spinner、SSR、Server Components、Remix 的收益与复杂度。结论是当前采用浏览器单端，后续加服务端集成不会丢弃代码；是否重启该决定取决于 UX 收益能否显著超过风险。
推荐收录：这是一份完整的架构决策记录，直接给出浏览器单端方案、会话 Cookie 认证、Node/npm 风险、DDoS 缓解和多种备选架构的取舍证据，而非泛泛介绍。适合前端架构、平台工程、控制面/基础设施开发者阅读，可迁移到 BFF 取舍、控制台认证、依赖治理和渐进式 SSR 决策。主要限制是结论高度依赖 Oxide 的 Rust 栈与安全约束，其他团队需重新评估。
工程实践 Oxide Public RFDs
这份 RFD 定义 Oxide 服务器机箱管理的职责分配架构，重点划分主机处理器与服务处理器（SP）之间的数据和控制路径。作者提出单一事实源、单一执行点、库存与健康监测合一、复杂行为自托管及 Sidecar/Gimlet/PSC 对等等原则，并据此分配热环路、DIMM SPD、电源控制、FRU 库存与错误/性能遥测。热与电源安全控制归 SP，带内设备库存和主机侧遥测归主机；DIMM SPD 比较多种方案后倾向在 EVT1 验证 SP 代理。文档还覆盖安全考量与开放问题，并声明除 DIMM SPD 等未决项外，分配结论对当前及后续产品具有规范性。
推荐收录：该文档不是泛泛介绍，而是给出可执行的机箱管理职责矩阵、原则和 DFD，包含热环路、DIMM SPD、电源与遥测等真实取舍。适合服务器硬件、固件、带外管理和系统架构读者，其“单事实源/单执行点/对等分配”方法可迁移到类似平台。需注意 DIMM SPD 最终方案仍待 EVT1 验证，部分安全与开放问题尚未闭合。
工程实践 Oxide Public RFDs
这是 Oxide 公开 RFD 82，讨论机架硬件相关的 Operator Facilities 设计动机、原则与需求。文章将运维场景分为容量规划、产品生命周期、基本产品运行、运维硬件故障和未知问题调查五类，并提出对齐客户业务、一致性、无意外、有意义的差异四项原则。作者通过故障风扇、无法上电的 U.2 NVMe、新增网络 uplink、容量评审等案例，提炼识别、诊断、上报、派单、维修、验证与 RCCA 等信息需求。文档还列出组件电源控制、诊断重启与崩溃转储、固件升级、健康状态等需求，并强调现场技术人员可能无法访问控制平面。适用边界是 Oxide 机架和控制平面的设计共识，不包含完整架构实现或实验结果。
推荐收录。该 RFD 不是泛泛的产品愿景，而是用 CP/PL/BPO/OHF/IUP 分类、故障更换 walkthrough 和容量规划问题清单，把硬件运维需求结构化，并给出一致性、无意外等可验证的设计原则。适合基础设施、SRE、硬件控制平面与系统设计读者，可迁移到故障管理、容量规划和现场可服务性设计；局限是高度绑定 Oxide 机架及产品假设。
工程实践 Oxide Public RFDs
本文是 Oxide Computer 的 RFD 169，讨论 Web Console 以静态 JS 包由 Nexus 提供后，浏览器直接调用 API 时的认证与会话管理。方案采用随机串 session cookie，服务端 sessions 表关联用户，并配置 Secure、HttpOnly、SameSite=Lax 以及空闲和绝对超时。为缓解 CSRF，文章在 SameSite 之外叠加会话级 CSRF token 与自定义请求头，借同源策略和 CORS 预检阻止第三方构造请求；HttpOnly 用于降低 XSS 窃取会话的风险。文中还描述登录 OAuth 流程、未认证时 API 返回 401 而页面重定向、过期会话硬删除和登录后回跳等取舍，并指出浏览器兼容、子域不可信和 token 生命周期等边界。适合设计 SPA 控制台、API 认证与 Web 安全机制的后端/安全工程师参考。
推荐收录：这是 Oxide 公开 RFD，正文给出可验证的会话 cookie 属性、SameSite+CSRF token/自定义头组合、过期策略和 OAuth 登录流程，不是泛泛的安全清单。对构建 SPA 控制台、API 网关或需要兼顾 CSRF/XSS 的 Web 后端读者，可直接迁移其威胁模型、属性配置和取舍思路；需注意方案绑定 Nexus 与 Oxide 环境，具体 TTL、CORS 和清理作业仍待实现确定。
工程实践 Oxide Public RFDs
Oxide 的 RFD 161 定义了整个机架指标数据的建模方式，并确定在 ClickHouse 时序库中存储与查询这些数据。文章先提出数据模型目标——表达力、可操作性、可扩展性、效率与强类型，并借用 Google Monarch 的术语定义 target、metric、timeseries、field 与 metric type。随后用服务请求延迟、虚拟机 CPU 利用率、磁盘温度三个例子给出 target/metric schema 与 timeseries key 的构造方式，并列举代表性查询。核心内容是两种数据库组织方案的对比：字段展开（元数据表加大量 join）与动态表（按 target-metric 对建表，更少 join 但需管理数千张表）。最终决定采用字段展开模型，并列出 pre-quorum 数据、不同时间尺度字段的存储、日志与分布式追踪未覆盖等开放问题。
这是 Oxide 公开的真实架构决策文档，给出两种时序数据建模方案的具体 schema、示例查询与权衡：join 成本对比建表和 schema 管理复杂度，并指出 ClickHouse 数千表下的性能未知，最终明确选定字段展开方案。对设计指标/可观测性平台、在 ClickHouse 等列存库上建模时序数据的工程师有直接参考价值和可迁移的取舍方法。
工程实践 Oxide Public RFDs
本文是 Oxide 的公开 RFD 162，描述机架内指标采集系统的架构与设计。文章统一 target、metric、timeseries、measurement、producer、collector 等术语，比较 push/pull 采集模型后确定当前采用 pull 模式，由 Nexus 将 producer 分配给 oximeter 实例并按间隔轮询。设计包括 producer/collector 注册、数据模型校验、oximeter 本地缓存、同一 producer 多 collector 写入不同 ClickHouse 以保证可用性，以及 Nexus、producer、oximeter 三类接口。文末列出对 Nexus/CockroachDB 的依赖、quorum 前遥测、外部查询、schema 更新和访问控制等开放问题。该文接口与取舍清晰，但仍属早期设计，查询实现和落地验证不在范围，部分关键问题未有定论。
推荐收录。该 RFD 给出了指标采集系统从术语、pull/push 取舍、Nexus 分配到 oximeter API 的完整设计链，并明确缓存、多 collector 冗余和开放问题，对构建可观测性平台或理解控制平面指标采集的读者有可迁移价值。风险在于它仍是早期设计文档，查询路径和实现验证缺失，使用时需结合后续实现与数据模型文档判断。
工程实践 Oxide Public RFDs
该 RFD 讨论 Oxide 控制平面中的 Workflows Engine，用于编排复杂、可能长时间运行的任务，如 VM 创建、SSD 固件升级、虚拟机迁移和故障服务器替换。作者先以 Terraform 类比解释期望状态、当前状态与 workflow 的关系，再调研 Airflow、Argo、Cadence、Conductor、Prefect、Zeebe 等开源引擎，比较语言、执行语义、部署、失败恢复与人工介入等设计维度。文章将工作流分为一次性、可靠一次性、可靠持久三类，提出用 distributed sagas 处理需要完整完成或回滚的控制平面操作，并讨论 exactly-once、超时、通知和用户可见服务等难点。最终决定优先实现内部 saga 引擎，暂缓可靠持久工作流与客户可见服务，Nexus 中已有用于实例创建的原型。
推荐收录：这是一份真实控制平面系统设计的 RFD，给出了工作流分类、开源引擎横向调研、distributed sagas 的取舍以及明确非目标，证据密度高。适合做基础设施、分布式系统、控制平面或云平台架构的读者参考，其中状态/期望态分离、失败回滚与人工介入边界可直接迁移。风险是它绑定 Oxide 内部场景，读者需自行判断适用范围。
工程实践 Oxide Public RFDs
本文是 Oxide 公开的 RFD 63，系统阐述单机架到多机架的网络架构设计。文档先给出七项设计目标（低延迟体验、无单点故障、可扩展、兼容客户网络、实例可任意迁移、简化管理、可演进），继而提出物理层采用基于 IPv6 的 L3 + ECMP 架构并把路由决策下推到主机，虚拟层用 Geneve 封装实现 VPC，每台主机运行可编程的 OPTE 完成路由、NAT、防火墙等转换，边界服务则通过 BGP 与客户网络对接。文中以物理转发、内部 DNS、实例互通、出站 NAT、浮动 IP 入站等五条报文流程推演实现路径，并对比 VL2、Ananta、VFP、Andromeda 与 Joyent Fabrics 的经验教训。文档同时声明其边界：不解决信任问题，且为初期产品做了取舍，诸多细节留待后续 RFD 完善。
推荐收录：该 RFD 不是概念宣传，而是给出明确的七项设计目标、L3+ECMP 物理架构，以及 Geneve 之上由 OPTE 承担 L3 转换的完整方案，并用五条报文流程逐步推演，还复盘了 VL2、Ananta、VFP、Andromeda 与 Joyent Fabrics 的取舍和失败教训。对从事云网络、VPC 虚拟化、多租户隔离或数据中心架构的读者，其“目标—决策—权衡”链条极具可迁移价值；需注意它是尚未完全定稿的设计文档，明确不覆盖信任模型，部分细节待后续补充。
工程实践 Oxide Public RFDs
本文是 Oxide 的 RFD 0052，定义机架/云平台配额策略的设计。与 IAM 关注“谁可以访问什么”不同，配额策略关注项目或组织可消费的资源数量，只能挂载在组织或项目上，并默认沿资源层级继承，区域策略未显式覆盖时继承全局策略。创建资源时先做 IAM 鉴权，再检查项目配额，不足时返回明确 API 错误；文中还描述通过 UI/CLI/API 申请更多配额、配额将耗尽告警，以及 CPU、磁盘、IP、VPC、VM 类型等配额维度和示例 JSON 语法。边界是初期配额先在第一机架全局设置，多区域后续支持；示例中的 VM 类型配额仍是占位，文档偏设计规范，缺少实现与验证细节。
推荐收录，因为该 RFD 直接给出配额策略的归属层级、继承与区域覆盖规则，以及 IAM 检查顺序、API 错误返回、资源维度和 JSON 示例，属于可复用的平台设计证据。适合云基础设施、API 设计、多租户资源治理方向的读者；其继承模型和告警/申请流程可迁移到类似平台，但实现细节和 VM 类型定义仍需后续文档补全。
工程实践 Oxide Public RFDs
RFD 56 设计 Oxide 的 Billing API，目标是支持客户对其内部组织、项目和用户做资源计费与 chargeback/showback。文档定义了 /system/billing、组织和项目计费汇总等端点，允许按资源类型配置按秒、分或日计价，并考虑按区域定价和 standard/spot 实例服务等级。价格变更只影响当前及未来账期，v1 不追溯历史账单、不删除计费项，但保留未来定价生效时间和历史调整的扩展空间。计费流程涵盖组织默认 billing account、项目切换账单账户、月度发票、历史发票、第三方集成、信用额度及未使用配额展示。它还描述了预算告警与邮件通知，但属于设计提案，缺少实现验证和长期运营数据。
推荐收录。该 RFD 提供了完整的 Billing API 端点、计价粒度、组织/项目账单账户、发票、信用额度和第三方集成设计，并明确 v1 不追溯历史账单、不删除计费项等边界。适合云平台/基础设施开发者、API 设计者及多租户计费系统设计者参考，可迁移到 chargeback、预算告警和账单集成场景；风险是它属于设计提案，尚未展示实现与运营验证。
工程实践 Oxide Public RFDs
本文是 Oxide Rack 控制平面需求型 RFD，界定数据平面与控制平面边界，并列出开发者 API、运维 API、生命周期、远程支持和指标采集等功能。作者主张控制平面状态为权威状态并尽量同步传播到数据平面，提出可用性、持久性、强一致性、可扩展性和安全性等非功能要求。存储部分比较 FoundationDB/CockroachDB、PostgreSQL 复制与 Raft 加本地存储等方案，并强调逻辑复制价值。迁移部分区分计划内 live migration 与非计划迁移，讨论自动恢复的分裂脑、故障放大和资源耗尽风险。多机架控制平面被推迟，许多细节仍开放，故本文更像需求与设计取舍清单。
推荐收录。文中以明确的需求条目和设计取舍讨论了控制平面 API、权威状态、同步/异步传播、可用性与持久性目标、存储选型及自动迁移风险，证据密度高。适合云基础设施、分布式系统和控制平面架构读者作为需求清单与风险检查表；但它是需求型 RFD，很多实现细节与多机架方案仍 TBD，使用时需结合后续 RFD 与实现验证。
工程实践 Oxide Public RFDs
RFD 45 定义 Oxide 机架面向运维人员的系统级 API，提供跨项目/虚拟机的全局指标与硬件库存视图。指标 API 覆盖 CPU、内存、存储和网络的容量、利用率或收发计数，规定 60 秒采样且最长 240 秒后才可见，并支持按项目、服务器、机架等维度查询。库存 API 通过 Component、Firmware 等模型描述组件健康、错误、保修、固件历史和设置，用于盘点和告警。文中还提出 SQL 查询与自定义仪表盘，但后者推迟到 MVP 之后。整体是讨论阶段的 API 设计草案，查询语义和实现边界尚未完全确定。
推荐收录：该 RFD 给出了可落地的系统级 API 端点、OpenAPI 数据模型和指标采样语义，并系统梳理了运维人员关心的容量、利用率、库存、固件与健康问题。适合平台工程、基础设施、监控/可观测性和 API 设计读者参考，其按资源维度聚合与库存建模思路可迁移到类似管理平面。需注意它仍是讨论阶段草案，部分接口和实现边界未定，不能当作最终规范直接照搬。
工程实践 Oxide Public RFDs
本文是 Oxide 的 RFD 58，围绕机架交换机（rack switch）的需求与设计空间展开，系统梳理控制面、块存储与应用三类流量对交换机的功能要求。作者讨论双交换机冗余、Tofino 2 与 Tomahawk 3 的 ASIC 选型、外部 PCIe 连接、热插拔、带外管理与 NC-SI/专用管理网络等关键取舍，并以可证明固件完整性和无单点故障为目标。最终计划采用 Tofino 2 作为交换 ASIC，并选择专用管理网络而非 NC-SI，同时说明升级到 200G、QSFP28 光模块管理和多机架组网等扩展方向。该文档面向机架级基础设施设计，很多结论绑定 Oxide 的硬件形态与供应链约束，偏架构决策记录而非通用教程。
推荐收录：该 RFD 不是产品宣传，而是从需求分类、ASIC 选型、PCIe 热插拔到带外管理网络的一手架构决策记录，包含明确约束、备选方案与取舍理由。适合做机架级网络、数据中心硬件、系统可靠性或基础设施架构的读者参考，其冗余设计、固件 attestation、管理面与数据面隔离等思路可迁移到类似系统。风险是结论高度依赖 Oxide 的供应链和硬件形态，需结合自身平台重新评估。
工程实践 Oxide Public RFDs
本文是 Oxide 的 RFD 79，讨论控制平面软件在 Rust 中应选择 async/await 事件驱动还是同步多线程（threaded）方案。作者从内存占用、线程池规模设定、病态场景行为、编程模型易用性与可调试性五个维度逐项对比，并用权衡表和风险表量化两种方案的优劣、发生概率与缓解手段。核心结论是：在能够按需投入可调试性建设（自定义 executor、动态追踪、指标采集等）的前提下，建议继续沿用基于 async/await 的事件驱动方案。文章还讨论了不使用 async/await 的事件方案与 channel 通信的取舍，以及该决策难以低成本回退的边界。
推荐收录，因为它把一次真实且代价高昂的并发模型选型拆解为内存、线程池调优、病态故障、编程模型和可调试性等可验证维度，并给出风险概率、严重度与缓解措施。对负责 Rust 后端、控制平面或高可用服务的工程师，文中关于线程池设置、超时与并发上限、异步调试取舍的分析可直接迁移到类似系统设计中。
工程实践 Oxide Public RFDs
该 RFD 定义 Oxide Rack 的用户网络 API，覆盖 VPC、子网、路由表、Internet Gateway、浮动/临时 IP、DNS、防火墙与 VPC Peering 等核心模型。文档用三层博客架构示例说明浮动 IP、负载均衡、子网路由、NAT 网关和数据库间的流量路径，并给出最长前缀匹配、自定义路由优先、防火墙优先级与状态化规则等关键行为。它还描述默认规则、IP 保留、DNS 命名方案、VPC 隔离/对等约束及 VNIC/DHCP 表现。内容偏重平台网络 API 与架构设计，含未来方向与开放问题，适合云网络和基础设施工程师参考，但并非通用实现教程，且部分 API 端点细节未完整展开。
推荐收录：该文档以真实产品 RFD 形式给出 VPC、路由、NAT、浮动 IP、DNS 和安全组/防火墙的完整设计模型与示例，包含可验证的规则优先级、默认行为和边界条件，而不是泛泛介绍。适合云网络、基础设施、API 设计工程师在规划多租户网络、隔离、对外暴露和排障规则时迁移参考；风险在于它绑定 Oxide 的特定实现，部分端点与未来方向仍在讨论中。
工程实践 Oxide Public RFDs
本文是 Oxide 计算机公司发布的 RFD 4，关于用户面向 API 的早期设计草图。文章系统阐述了云平台 API 的设计原则：采用 OpenAPI 规范生成多语言客户端与静态文档，追求极简、直观并优先满足 Terraform、Kubernetes 等上游集成需求。核心设计包括异步操作返回 operationId、用 Etags 做条件请求与并发控制、PUT 整体替换资源、暂不支持 PATCH、以及 Stripe 式版本迁移策略；同时覆盖认证（OAuth2、SSH 密钥、2FA）、资源模型（Projects、Instances、Tags）和身份元数据等。作者明确 GraphQL 不是优先项，并强调 API 需保持向后兼容。该文档注明具体 API 已过时，应参考后续 RFD 322 和实际 OpenAPI 描述，但其原则仍具参考价值。
推荐收录。该 RFD 并非产品发布稿，而是公开的 API 设计决策记录，完整呈现了云平台 API 在 OpenAPI 客户端生成、异步操作、Etags 并发控制、版本迁移、认证与资源建模上的取舍与理由。对从事云基础设施、API 平台、系统设计的读者有直接可迁移价值。需注意文档自述具体 schema 已过时，应结合后续 RFD 和实际 OpenAPI 描述阅读。
技术文章 知乎 - 鹅厂架构师 2026/09/15
文章介绍 2026 年兴起的 Graph Engineering，澄清它并非知识图谱工程，而是面向多智能体协作的编排工程。作者提出 Prompt、Context、Harness、Loop、Graph 五层工程栈，说明图工程让智能体组织可编程，并用组织图与工作图分别管理稳定角色和动态任务。文中对比 Loop 串行重试与 Graph 并行拓扑，给出从单 Agent Loop、角色拆分到双图架构的三步落地路线，以及“80% 靠 Harness、15% 靠 Loop、5% 才需 Graph”的判断法则。作者也列出不适合用图的场景，强调先跑透单 Agent、监控瓶颈再决定是否上图。局限在于偏概念综述，缺少实验或真实生产数据，工具生态仍处早期。
推荐收录：文章给出了 Graph Engineering 的明确定义、五层工程栈、双图架构、Loop/Graph 拓扑对比，以及三步落地路线和“5% 才需图”的边界判断，信息密度高于一般热点解读。适合 AI 工程、架构和多智能体系统开发者用来建立概念框架、评估是否引入图编排。主要风险是术语较新、缺少生产案例与实验数据，读者应把它当作选型参考而非已验证结论。
工程实践 Greptime 技术 2026/09/15
文章提出在 GreptimeDB 上构建统一可观测性平台的参考架构，将指标、日志和追踪汇入同一数据库，同时保留现有采集器协议。作者以 OpenTelemetry Astronomy Shop 为验证环境，用单个 GreptimeDB 实例替换 Jaeger、OpenSearch 和 Prometheus，详述写入端点、按信号分表、Flow 物化视图、TTL/WAL、查询接口及三档集群拓扑。核心决策包括按信号分表、按量分区、用 Flow 隔离仪表盘告警热路径，并展示基于 trace_id 的跨信号 SQL 关联与延迟自连接分析。边界是 Loki 仅兼容写入、Elasticsearch 开源版仅 _bulk，亚毫秒指标查询弱于 VictoriaMetrics，部分隔离与告警属企业版。验证以单机演示和有限基准为主，生产需按自身负载验证。
推荐收录：文章给出可直接复用的参考架构、写入端点表、表设计、Flow/TTL/WAL 与三档拓扑，并用 OTEL Demo 实际数据展示跨 trace_id 日志关联和延迟自连接，工程证据具体。适合负责可观测性平台、数据库选型和 SRE/平台工程落地的读者。需注意来源为厂商博客且验证以单机演示和厂商基准为主，大规模生产收益应结合自身负载验证。
工程实践 Salesforce Engineering 2026/09/14
文章以 Q&A 介绍 Salesforce 如何用 Data 360 data graphs 为 AI Agent 提供可信客户上下文。核心是在上游连接身份、账户、产品、权益、合同与订单等关系并执行业务逻辑，再用分区架构隔离客户数据，仅向 Agent 暴露过滤后的客服视图。为应对不可预测提问，方案按访问模式拆分多图、建立索引并支持语义/关键词检索，使 P50 延迟从约 400ms 降至 200ms 以下；同时通过自动化部署和可复用校验，在六个月内交付五个数据图。局限是来自厂商访谈，缺少 schema、失败案例和成本细节，适合作为 Agent 上下文与数据图谱架构参考。
推荐收录：文章给出了 Agent 可信上下文落地的具体工程证据，包括按访问模式拆分多图、分区隔离身份数据、语义/关键词检索，以及 P50 延迟低于 200ms 的指标，并总结六个月交付五个数据图的可复用实践。适合 AI Agent、客户数据平台、数据图谱和低延迟服务的设计者参考，可迁移到上下文供给、数据隔离与性能取舍；但来自厂商访谈，缺少 schema、成本与失败细节，落地前需验证。
工程实践 Salesforce Engineering 2026/09/11
文章以问答形式复盘 Salesforce 团队如何在 iOS、Android、React Native 和 Flutter 四套技术栈上构建实时移动个性化架构。核心矛盾是跨端渲染与生命周期差异、跨渠道身份拼接、隐私与同意、有限屏幕空间内的动态原生渲染，以及营销活动变更不应触发 App 重新发版。团队通过统一 schema、事件语义和 SDK API、桥接层复用原生能力，并把身份解析与决策保留在服务端，移动 SDK 只接收决策并渲染开发者注册的原生组件。同时将应用埋点与体验配置分离，用 content zones、模板和 CDN 下发配置，并提供二维码预览与模拟器注入真实画像来验证定向和布局。结论是“一次埋点、营销可配置、服务端决策、动态渲染原生组件”，但文章偏经验总结，缺少具体性能数据、失败案例和实现细节。
推荐收录，因为文章给出了跨 iOS、Android、React Native 和 Flutter 的实时移动个性化架构取舍：统一 SDK 与桥接层、服务端身份解析与决策、content zones/模板分离配置与代码、CDN 下发、二维码预览等。适合移动端、平台工程和个性化系统架构读者，可迁移到多端 SDK、跨渠道身份和低代码配置场景；但属于厂商经验总结，落地细节与失败边界有限，需结合自身约束验证。
工程实践 知乎 - SmartCode 得物技术 2026/09/10
文章介绍得物基于 AgentScope Java 的企业级 MultiAgent 平台，聚焦复杂任务如何规划、拆解并由主子 Agent 协作执行。平台采用 Plan-and-Execute，把计划操作注册成工具，注入 Hint 软约束，持久化计划状态并支持断点幂等恢复，同时通过 SSE 推送 CHAT/PROCESSING/ERROR 事件。主子 Agent 以声明式配置拆分职责、工具和权限，支持同步、异步、并行调用与协作式中断；A2A 协议借助 Agent Card、JSON-RPC 和 contextId 实现跨服务会话协作。企业级保障涵盖 ORM 多租户隔离、统一认证、调用树追踪、工具超时重试和 ReAct 迭代上限。方案适合大型企业 Agent 平台落地，但依赖 AgentScope Java 与自研基础设施，且隐去了具体组织信息。
推荐收录：文章给出了 Plan 全生命周期、主子 Agent 声明式配置、A2A 跨服务调用和 SSE 可观测性的具体机制，并明确多租户隔离、断点恢复、中断传播等生产约束。适合设计企业级 Agent 平台、MultiAgent 编排或 AI 基础设施的工程师与架构师参考，计划持久化、异步任务管理和调用树追踪可迁移到类似系统。风险是方案与 AgentScope Java 及得物自研基础设施耦合，且隐去组织环境细节，落地需重新评估。
工程实践 vLLM Blog 2026/09/10
文章系统介绍了 vLLM 中的分层 KV 缓存卸载框架，核心设计是所有 KV 数据经由主机内存流转：卸载时先异步拷贝到主机并立即释放加速器内存，再由主机异步写入文件系统、对象存储或远端 P2P 节点；重载时从主机缓存或次级层按序加载，实现即时分配与整合 I/O。该框架通过规范化内存布局保证跨节点、跨并行配置直接共享 KV 数据，并透明支持全注意力、滑动窗口、MLA、Mamba 等混合模型。文章还描述了可扩展的次级层接口、KV 事件与可观测性，并给出性能测试：并发会话超过 128 时，存储层卸载仍能维持高命中率，吞吐量比无卸载方案翻倍以上，但存储延迟使其无法达到峰值吞吐。
推荐收录，因为文章来自 vLLM 官方博客，深入剖析了分层 KV 缓存卸载的主机中心设计、规范化内存布局、次级层抽象与 KV 事件机制，并给出可复现的性能基准，展示了从 HBM 到 CPU 再到存储的完整数据流与权衡。对从事 LLM 推理服务、缓存系统或高性能基础设施的工程师而言，其设计原则（即时分配、整合 I/O、跨节点共享）可直接迁移，具有长期参考价值；风险是部分实现细节绑定 vLLM。
工程实践 vLLM Blog 2026/09/07
该文介绍 vLLM TT Plugin，通过 vLLM 的树外平台插件机制将 Tenstorrent 加速器接入 LLM 推理服务，并保持 OpenAI 兼容 API 不变。文章重点分析 Tenstorrent mesh 架构与 GPU 栈的本质差异：跨芯片并行被编译进单个 traced program，因此没有 TP/PP rank，调度器须将每个步骤严格拆为 prefill-only 或 decode-only。为支持 Galaxy 上的单执行模型，作者采用单进程 lane 数据并行（TTLaneCoordinator 管理独立调度器与 KV cache），避免多进程 scatter/gather 开销；同时实现按批次回退的 on-device sampling 和基于异步 readback 的 decode overlap。文末列出当前限制，如暂不支持投机解码、LoRA、prompt logprobs 和多主机服务，这些多属运行时实现约束而非硬件极限。
推荐收录，因为它不是硬件发布稿，而是详细复盘了非 GPU 架构下 LLM 推理服务的设计取舍：插件边界、阶段化调度、单进程 lane DP、异步 readback 等均有明确动机、代价与验证。适合 LLM 推理基础设施、异构加速器和 vLLM 插件开发者阅读，其“将设备差异封装在插件内、不 fork 上游”的方法可直接迁移到其他新加速器适配场景。
技术文章 Phil Eaton - databases
本文通过约600行Go代码构建了一个分布式Postgres概念验证，解释了CockroachDB背后的核心组件：Postgres线协议、SQL解析、Raft共识和存储层。作者使用pgproto3、pg_query_go、Hashicorp Raft和bbolt，实现了CREATE TABLE、INSERT通过Raft复制到各节点，SELECT在任意节点本地执行。文章演示了多节点启动、通过HTTP手动加入集群、故障切换和重启后数据一致性。同时指出方案仅支持少量SQL、快照被禁用、日志重放效率低、JSON存储不高效，并且只实现了复制而非分片或跨分片事务。这个教程展示了如何将成熟库组合成可运行的分布式系统骨架，适合理解分布式数据库基础结构。
推荐收录，因为文章以可运行代码完整演示了分布式Postgres的核心机制：用Raft复制写操作、本地执行读操作，并明确说明了简化与局限。适合想理解CockroachDB等NewSQL系统底层组成或动手实现分布式数据库原型的读者。其将成熟库组合为可扩展骨架的思路、无快照设计取舍和故障切换验证过程具有可迁移价值，但需注意SQL支持和性能远非生产级。
技术文章 Phil Eaton - databases
文章系统介绍键值数据库（嵌入式如 RocksDB、LevelDB、PebbleDB，分布式如 FoundationDB、TiKV）在当代数据库系统中的重要性。作者从数据库可扩展性切入，解释存储引擎可替换如何帮助优化分析型或写密集型负载，并详细说明将 SQL 行映射为键值对的具体编码方法，包括表标识、主键和行标识组合及高效前缀扫描。文章梳理了可靠存储、嵌入式部署、高效前缀扫描等关键特性，并列举构建在这些存储上的多种数据库实例。最后区分了嵌入式与分布式键值数据库的架构差异，并指出非数据库开发者或非大规模场景可忽略存储层细节。
推荐收录，因为文章清晰梳理了键值存储在现代数据库架构中的核心作用，提供了 SQL 到 KV 映射的具体思路和真实数据库案例，适合想理解数据库存储层或构建数据库系统的开发者。它作为入门导览具有较好的长期参考价值，能帮助读者建立对存储引擎选型和架构分层的整体认知。
技术文章 Phil Eaton - databases
文章旨在建立对OLTP系统中分布式共识（尤其是Raft算法）的直觉。作者先解释Raft的基本机制：领导者选举、日志复制、提交和跟随者追赶，然后阐明分布式共识通过副本提供高可用和线性一致性，同时强调其本身并不提供水平扩展，水平扩展需通过分片实现。文章讨论了添加节点对延迟和可用性的权衡，并列举了实际优化技术，包括快照、批处理、磁盘/网络优化和灵活法定人数。此外还涉及安全与测试方法，如Jepsen、确定性测试和TLA+规格验证。最后指出共识开销大，应根据一致性需求选择合适方案。文章主要适用于OLTP系统，未深入非OLTP共识算法或具体实现细节。
推荐收录，因为文章用简洁直观的方式梳理了Raft在OLTP系统中的运作机制，并纠正了分布式共识常被误解为水平扩展的问题。作者从线性一致性、可用性、节点扩展、优化和测试等多个角度展开，既有理论直觉也有工程实践视角，适合分布式系统初学者和数据库工程师建立基础框架，同时为进阶读者提供了丰富的进一步阅读线索。
技术文章 Phil Eaton - databases
文章以 Delta Lake 论文和协议为蓝本，用约 500 行 Go 零依赖代码实现了一个受 Delta Lake 启发的 serverless ACID 数据库。核心是利用对象存储的原子 putIfAbsent 语义，通过不可变数据文件和带事务 ID 的元数据日志实现快照隔离。文中详细演示了基于 POSIX link 的文件系统原子写入、事务动作、内存行缓冲、数据对象刷新和扫描迭代器，并用两个并发测试验证写冲突与读快照行为。作者明确指出该实现仅支持建表、插入和全表扫描，未覆盖更新、删除、日志 checkpoint、压实等，且合并所有表的事务日志比 Delta Lake 更严格，带来更高写冲突。
推荐收录，因为文章不是泛泛介绍，而是给出了从对象存储原语到事务提交的完整可运行实现，并通过测试展示了并发读写的实际行为。适合想理解 Delta Lake、Iceberg 类事务机制或实现对象存储上最小 ACID 数据库的读者，其抽象接口和原子提交思路可直接迁移到教学或原型系统。主要边界是省略了更新删除等生产特性，单写者模型也限制了并发写能力。
技术文章 Phil Eaton - databases
文章提出事务并非存储系统的固有属性，而是一种可以在任意存储系统上实现的协议。作者引用 Delta Lake、Orleans 在云存储上实现事务，以及 Epoxy 在 Redis 等系统上提供事务的方案，并提到两阶段提交作为经典例子。文章进一步指出，即使 PostgreSQL、MySQL、SQLite 已内置事务，开发者也可以选择绕开并实现自己的事务层，如 Convex 所做。作者认为，在需要一致性、原子性和隔离性，尤其是跨数据系统构建应用时，应把事务协议视为系统设计工具箱中的一种工具。文章以观点阐述和文献导引为主，未深入实现细节与性能评估。
这篇短文以清晰的视角将事务定义为可移植协议，串联了多个数据库系统的实现案例，适合需要理解跨存储系统一致性或设计事务层的读者。其价值在于提供思维框架和进一步阅读线索，但内容较为概略，应作为入门索引而非实现参考。
工程实践 LinkedIn Engineering - Architecture
文章是 LinkedIn 工程师对重建消息平台时如何设计可扩展性的复盘。作者首先明确了要解决的问题：保护收件箱质量、成员隐私以及将业务逻辑从平台剥离。文章核心方法是引入插件框架，在消息和会话的生命周期中定义 pre/post 回调（如 conversationPreCreate、messagePreCreate），插件通过注册这些回调并附加自身元数据来实现定制逻辑，平台只负责存储和投递，不解析插件元数据。文中还介绍了插件失败隔离、延迟要求、安全审查和分阶段发布等稳定性措施。作者通过一个邀请功能的例子展示了插件如何快速迭代，并分享了元数据契约设计的一次教训：从允许删除改为只允许增改，以简化插件开发并降低平台风险。文章结论强调可扩展性设计需要前期分析用例、明确原则，并建议用简单和复杂两个试点来验证系统。
推荐收录，因为文章提供了一套可复用的平台扩展性设计方法：插件框架、生命周期回调、元数据隔离和失败隔离，并包含真实的契约设计教训。适合从事平台工程、消息系统或微服务架构设计的工程师参考，文中的原则和权衡可直接迁移到类似需要第三方扩展的系统设计中。
工程实践 知乎 - 孔某人 2026/08/09
文章分享了作者在构建Multi-Agent系统进行中型数学探索任务时的架构设计经验，重点涵盖Token成本优化、可并发度瓶颈分析与Worker拆分、系统迭代的持续需求与独立升级Agent设计、详细的角色划分（Merger、TaskCreater、TaskWorker、TaskReviewer、SystemUpdater、UserInterface、Reporter、Critic）、高层视角隔离以及全局状态与消息通讯的工程实现。文中还讨论了基于GitHub Issue的方案受限于性能和非结构化问题，进而转向专用全局状态Server，并介绍了Controller模型内部Master-Worker架构以隔离上下文。作者指出整个方案仍较复杂，需较长时间试运行和打磨，但提供了丰富的工程决策依据和迁移价值。
推荐收录，因为文章从真实工程探索出发，系统性地分析了Multi-Agent系统设计中的成本控制、并发瓶颈、角色分工、系统迭代和全局状态管理等关键问题，给出了具体可迁移的架构思路和教训，适合对Agent系统设计、AI工程化及复杂系统迭代有深入需求的读者参考。
技术文章 LWN.net 2026/08/06
文章介绍了 Linux 内核的 binfmt_misc 机制，该机制允许用户空间配置任意可执行文件格式的透明执行。作者分析了现有机制的局限，并重点讨论了即将引入的 BPF 支持，使内核可以通过 BPF 程序动态决定如何运行给定程序。更新旨在提升灵活性和可编程性，同时保持向后兼容。文章还涉及相关安全考量、性能影响以及潜在的实现挑战，适合关注内核运行时可扩展性的技术人员。
LWN 文章深度解析了内核二进制格式处理的演进，详细说明了 binfmt_misc 与 BPF 结合的动机、原理和设计权衡，为系统软件开发者提供了可迁移的运行时扩展思路，适合研究内核和自定义执行环境的读者，长期参考价值明确。
工程实践 知乎 - 腾讯技术工程 2026/08/04
文章深度复盘了腾讯 Omega AI BI 系统从理念到落地的完整过程。针对传统 BI 操作门槛高、ChatBI 仅能完成单次查询的局限，Omega 将 AI 重建为分析工作的协作体：由 LLM 规划指标、组织页面并生成 HTML，同时通过 QueryRegistry 数据契约和 DTBridge 运行时解耦数据查询与界面，实现页面与真实数据的持续联动。文章详细阐述了指标证据链构建、语义模型接入、筛选器依赖图、多层安全防护、运行时契约（有界、可取消、可观测、可自纠）等关键设计，并分享了模型幻觉、慢查询误杀、成本权衡等真实事故与应对。结论强调 AI 生成页面仅是第一层，系统化地保证页面第二天仍可用、分析可延续、Agent 出错可体面恢复才是产品化的核心，适用于拥有数据底座且具备一定治理水平的企业场景。
本文是一份高质量的工程复盘，不是泛泛的产品介绍，而是细致拆解了 AI BI 系统从原型到可生产产品的核心矛盾与解决方案。对负责 AI 产品化、数据工程、系统架构或安全设计的读者有极强的可迁移价值，尤其在如何用确定性系统约束 AI、如何保证数据查询与界面长期可靠联动方面提供了可复用的模式。
工程实践 知乎 - 鹅厂架构师 2026/08/04
文章记录了腾讯云团队从0到1搭建AI Agent可操作的团队知识管理体系的完整工程实践。团队借鉴外部知识沉淀思路，结合自身小型团队和通用AI工具的特点，设计了一套四层知识库（L0团队约定、L1通用技术、L2业务专属、L3项目索引）、四种知识条目类型（guideline/pitfall/pattern/decision）和三级成熟度（draft/verified/proven）的体系，并通过Git仓库实现版本管理。实施过程覆盖了冷启动时的人工高质量提炼、AI Skill的渐进式开发（检索/沉淀/更新）、项目仓库的轻量注册以及Rule触发提醒。文章详细阐述了为何选择独立知识仓库、动态目录扫描、用户确认式沉淀等核心决策，并展示了任务执行中知识自动注入和事后沉淀的闭环效果。当前工作适用于小型团队和通用AI编码工具场景，大规模团队或自研编排引擎的场景有待验证，治理机制中的衰减、孤儿检测等尚在规划。
推荐收录，因为文章不是简单的工具介绍或理念宣传，而是从真实痛点出发，给出了可落地的知识管理体系设计，包含架构分层、成熟度模型、索引机制和具体的工程实现路径。文中对设计决策的取舍理由（如人工冷启动 vs 自动化管道、轻量Rule+Skill vs 重型状态机）的说明，为类似规模的工程团队提供了直接可迁移的经验。适合AI工程化、开发者体验和团队知识管理方向的读者参考，但需注意其适用边界在于小型团队和通用AI工具，治理机制部分仍有待完善。
工程实践 知乎 - 千问云 2026/08/04
本文系统复盘了企业级 AI Agent 平台从 Prompt 工程、Context 工程到 Harness 工程的完整技术演进路径。作者从大模型的上下文窗口稀缺、注意力稀释、数据搬运谬误和无状态缺陷四大先天约束出发，阐述了为何需要工程化基础设施。文章重点介绍了四层上下文防线（工具结果压缩、语义压缩、对话压缩、数据总线）与三层记忆（State、Working Memory、Transcript）的组合设计，以及基于 PERO 编排、断点续传、知识体系、自进化引擎和 Capability Runtime 的 Agent 运行时架构。最终提出五层 Agent OS 架构和双 Agent 平台方案，强调从防御到赋能的设计哲学转变。内容覆盖了真实工程约束、架构权衡与失败教训，适合关注大规模 Agent 系统工程化的团队参考，但对具体实现细节的验证边界和性能量化指标披露有限。
推荐收录，因为这篇长文提供了从第一性原理出发的工程演进实录，非单纯概念介绍。文中关于上下文管理分层防御、有状态执行引擎、跨 Agent 协调及知识体系的设计决策，直接源于生产环境踩坑，可迁移性强。适合后端架构师、AI 平台工程师及技术管理者系统理解 Agent 运行时治理方案，尤其对面临长链路推理质量退化和上下文膨胀的团队具有高参考价值。
工程实践 Meta Engineering 2026/08/03
本文介绍了Meta如何将广告推荐基础模型GEM的训练规模提升至LLM级别，并在12个月内将端到端训练效率提升一倍至20-25%模型算力利用率（MFU），同时训练算力规模扩大4倍。文章从计算效率和扩展效率两个维度分别展开：计算效率通过定制化推荐内核库（Jagged Flash Attention、Generalized Dot-Product Attention、BlockAttention）和混合超低精度训练（MXFP8注意力与MLP）实现；扩展效率则依靠拓扑感知的5D并行策略（2D FSDP加专家并行处理稠密参数，全分片2D模型并行处理稀疏参数）配合SM-free通信、自动激活检查点及序列长度感知负载均衡。所提方案针对推荐系统特有的变长序列、非对称交互和数值敏感性等挑战进行了专门设计，其方法论和具体技术对大规模推荐模型训练具有参考价值，但部分优化（如内核定制）与特定GPU架构强相关，迁移时需适配自身硬件和数据特性。
本文是真实的工业级工程案例，完整展示了在数千GPU上训练万亿参数推荐模型的全栈优化过程，涵盖内核、精度、并行、网络和内存的协同设计，而非孤立技巧罗列。适合负责大规模深度学习训练、推荐系统基础设施或GPU性能优化的工程师，可迁移价值在于其将MFU分解为计算效率和扩展效率的分析框架，以及针对混合架构和变长数据的特定解决方案，对类似规模系统的构建与调优具有直接借鉴意义。
工程实践 Cloudflare Blog 2026/07/30
文章详细记录了 cdnjs 从旧架构（GCP Cloud Functions + GitHub 仓库 + Workers KV）迁移到 Cloudflare 全栈开发者平台（Workers、Workflows、R2、KV、Queues、Containers 等）的过程。旧架构痛点包括无共享追踪、双活存储、对象事件粘合流水线、26 个分片函数和臃肿的 GitHub 仓库；新架构以 R2 为文件单一真实源，KV 存元数据，Workers Cache 提供分层缓存，Workflows 编排流水线，并通过 Queues 和 Durable Object 实现异步阻塞。迁移中遇到字节级一致性和子请求限制等挑战，最终通过原样复制而非重新压缩解决了 SRI 哈希问题，并倒逼平台提升子请求上限至 1000 万、Workflow 步数上限至 10000 步。文章展示了该架构的弹性、可扩展性，并为未来支持 ES 模块等现代功能奠定基础，但 SRI 校验修复等遗留工作仍待完成。
这是一篇稀缺的大规模 CDN 服务迁移工程实录，直面真实约束与架构取舍，并记录了平台为适配需求而改进的共演过程。对基础设施工程师、平台架构师和 SRE 极具参考价值，可迁移经验包括可观测性设计、存储一致性保障、无服务器工作流编排及平台限制突破策略；文中的坦诚复盘（包括迁移失败回滚）使内容更可信。
工程实践 知乎 - SmartCode 得物技术 2026/07/30
文章分享了得物技术团队在订单系统完成稳定性改造后，面对AI编码带来的代码量激增与质量挑战，如何重构研发流水线以适配AI Native范式。核心思路是将传统流程升级为五道标准化关口：需求澄清阶段通过BDD场景与知识库对齐，锁定业务验收标准；技术方案阶段以五段式模块拆解将设计决策前置，并拉取历史约束规约；编码执行阶段引入TDD的RED-GREEN循环，保证代码可测试、可追溯；门禁卡控阶段由多个审查Agent并行审核，确保阶段产物合规；全流程埋点监控则量化研发过程，驱动持续改进。文章以出海礼品卡需求为例贯穿全文，展示了从需求到代码的完整证据链，为交易核心系统在AI辅助下的稳定性治理提供了可落地的工程实践。
本文系统性地记录了AI编码引入核心系统后的稳定性治理实践，将BDD、TDD、知识库校验与门禁流水线相结合，形成从需求到验证的闭环。其五道关口设计、增量代码体检和全链路埋点等方法，对面临AI辅助开发挑战的高可靠性系统团队具有直接参考价值，可迁移到类似交易、金融等核心链路的研发流程优化中。
工程实践 知乎 - 千问云 2026/07/28
本文从数据研发场景出发，指出Agent从“能跑”到“可信”的工程差距，提出Harness工程理念——LLM负责理解和创意，Harness负责约束和验证。作者回顾了AI工程从Prompt Engineering到Context Engineering再到Harness Engineering的范式演进，并基于Orchestrator+Specialist的Multi-Agent架构，详细拆解出身份层、执行层、进化层三大分层及Identity、Orchestration、Context、Gate、Recovery、Evolution六大支柱。每个支柱均给出了具体落地方法，如三层约束金字塔、Spec文件驱动、四级修改流程、状态机故障分级恢复等。最后讨论Harness可能成为AI时代DevOps标准或过渡性概念，并强调当前工程积累的价值。文章未深入特定行业合规要求，侧重通用数据平台场景。
本文不是空谈Agent概念，而是基于一线工程实践提炼出可复用的Harness设计框架，覆盖身份定义、流程编排、上下文管理、质量门禁、状态恢复与经验演进，逻辑完整且落地性强。适合AI工程化、Agent开发及系统设计方向的技术人员，文中的多层约束体系、Spec驱动协作和故障分级恢复等模式可直接迁移到其他生产级Agent系统。
工程实践 Salesforce Engineering 2026/07/27
文章以 Salesforce Agentforce Grid 为案例，深入剖析从 AI 原型转向生产系统时面临的分布式执行挑战。作者指出，生产 AI 的核心问题不是模型行为，而是如何让智能在长时运行、部分失败、部署重启、重试和输入变化中保持可靠。文章提出通过持久工作流将执行状态与工作线程生命周期解耦，并围绕可恢复的工作单元划分、执行状态持久化、重试边界对齐恢复边界、分层进度可见性等设计决策展开讨论。内部测试显示，迁移到 Temporal 后，高负载下失败率从约 90% 降至 0%，P95 完成时间缩短约 60%，验证了该架构的有效性。文章适用于涉及大规模批量推理、多步 Agent 或工具调用的 AI 工程场景，但数据来自内部环境，外部应用需独立验证。
推荐收录，因为文章基于真实生产系统，完整呈现了从问题识别到架构演进的工程决策过程，提供了可迁移的工作单元划分、状态持久化与重试设计原则。适合从事 AI 工程化、大规模分布式推理和可靠工作流编排的工程师与架构师阅读，能直接帮助读者在类似系统中避免“重跑全部任务”的陷阱，提升整体可靠性。
技术文章 知乎 - 阿里巴巴大淘宝技术 2026/07/27
文章系统阐述了AI Agent Skill系统的设计理念与工程实践，将Skill视为自包含能力包，通过SKILL.md、脚本、引用和资产将通用Agent转化为专用Agent。核心方法包括按上下文预算组织内容的三层加载机制（元数据发现、正文执行、资源按需读取），利用门控和检查表等严格约束控制Agent自由度，以及借鉴TDD思想的前向测试方法验证行为合规性。文章还讨论了跨平台适配策略，强调行为规则应稳定而平台工具可适配。最后通过反模式检查表加强Skill的交付质量。该方法适用于需要高合规性、低成本维护的AI Agent开发场景，但其有效性依赖平台对工具和子代理的支持。
文章从工程视角提供了AI Agent Skill设计的完整方法论，包括上下文经济、门控约束、前向测试等可操作实践，并点明常见反模式，对提升Agent行为稳定性和可维护性有直接指导意义。适合AI Agent开发者、平台工程师以及希望规模化使用Agent的团队参考。
技术文章 NVIDIA Technical Blog 2026/07/20
文章系统介绍了NVIDIA NVLink技术在AI工厂中的横向扩展网络角色，从第一代到第五代的演进，重点解析了第五代NVLink提供的1.8 TB/s总带宽、NVSwitch实现的GPU全互联拓扑，以及NVLink-C2C实现Grace CPU与Blackwell GPU间内存一致性的片间互连。作者结合DGX和HGX系统实例，展示了NVLink如何支撑万亿参数模型训练和实时推理，并概览了未来NVLink 6和7的性能指标。文章主要基于NVIDIA官方视角，对NVLink技术的原理、性能和系统架构提供了深入描述，但内容局限于NVIDIA生态系统，未涉及替代方案或成本权衡。
推荐收录，因为文章详细解释了NVLink的协议设计、拓扑演进和性能数据，并提供了具体的系统集成案例，对于需要理解大规模AI训练基础设施的工程师和架构师具有明确参考价值。尽管带有官方宣传色彩，但其技术深度仍可帮助读者掌握GPU互连对系统设计和可扩展性的影响，适合作为硬件架构和AI系统工程的学习材料。
工程实践 Netflix TechBlog 2026/07/17
本文详述了 Netflix 内部 LLM 服务平台的工程实践，涵盖引擎选择、模型打包、API 设计与部署策略的权衡。平台基于 vLLM 和 Triton 构建，通过 OpenAI 兼容 API 与 gRPC 统一前端，并提供了 Red-Black 与 Versioned 两种发布策略以应对接口变更。文章重点揭示了生产环境中的意外问题，如 vLLM 与 Triton 版本不匹配、冷启动延迟、指标碎片化，并深入分析了约束解码从 vLLM V0 到 V1 的性能演进与状态管理难题。这些经验对构建大规模 LLM 推理基础设施具有直接参考意义，尤其展示了从实验到生产的平滑过渡如何通过工程细节落地。
推荐收录，因为文章不是浅层的工具介绍，而是基于 Netflix 真实生产环境给出了系统性的设计取舍和踩坑记录。约束解码的缩放瓶颈、指标融合、版本协调等细节可直接帮助平台工程师避坑，适合负责 LLM 基础设施、模型部署或高性能推理系统的读者借鉴。
工程实践 知乎 - NGINX洪志道 2026/07/16
作者基于NGINX嵌入Lua开发了一个Web Runtime（nginx-lua-web），并借助AI辅助完成完整实现、自动化测试和性能对比。文章核心论点是：软件原有设计的质量决定了AI编程所能达到的天花板。项目难点在于端到端异步流式处理，涉及读、写、超时、背压等交织的复杂性，NGINX清晰的事件驱动架构、内存池、cleanup机制和模块边界为AI提供了可推理的上下文，使AI能够有效生成符合规范的C代码，并维持约7/10的代码质量和连贯设计。性能测试表明，增加Lua层后未付出失控代价。作者总结，AI加速了理解系统的过程，但理解本身才是对抗复杂性的基本能力，好的设计是AI放大的基础。文章以单个C扩展项目为案例，结论可能受限于特定技术栈，但提供了关于AI与系统设计关系的可迁移洞见。
推荐收录，因为文章结合真实工程案例和AI辅助开发经验，具体展示了软件设计如何制约AI生成代码的质量与系统复杂度管理。适合关注AI工程化、系统架构和扩展设计的读者，其分析方法、性能验证手段和设计原则可迁移至其他类似异步高并发系统的开发中。
工程实践 知乎 - 千问云 2026/07/15
本文系统阐述Agent Harness Engineering理念，从Mitchell Hashimoto的定义出发，结合LangChain、Anthropic等团队实践，提出上下文越少越好、专才优于通才、状态落盘、约束可执行四条反直觉铁律，并总结双阶段架构、工具签名即文档、Sub-Agent隔离等六大工程模式。作者通过钉钉悟空AI招聘Agent的真实案例，详细展示从全能Agent失败到2 Agent+N Skill架构的改造过程，包括分拆职责、Workspace状态管理、Linter硬护栏等，给出显著的效果提升和血泪经验。文章强调Harness是AI时代软件工程的重新发明，对从事Agent系统设计的开发者有直接参考价值，但部分数据仅限内部场景，需结合具体业务验证。
本文从理论到实践均十分深入，既有LangChain、Anthropic等行业标杆的Harness选择分析，又有钉钉AI招聘Agent从失败到成功的完整复盘，展示了真实工程约束下的架构取舍和可执行护栏设计。适合正在构建或优化Agent系统的工程师、架构师及AI工程团队阅读。文中提炼的铁律和模式，如专才Agent拆分、Workspace状态管理、硬护栏落实，具有很强的可迁移性，能直接指导生产实践，因此推荐收录。
工程实践 知乎 - 腾讯技术工程 2026/07/10
本文是腾讯技术工程团队基于开源项目Multica构建多Agent协作工作流的工程实践。文章围绕“如何让一组Agent围绕目标协作完成一段工作”展开，核心方法是扩展Multica形成三根骨架：将分散Agent接入为统一调度能力池、将人类流程经验沉淀为可编排工作流、建立外部系统交接协议以实现工作进出闭环。在此基础上，补充了准出字段与Verdict、并行与收敛、验收与返工、自愈与显式阻塞、错误诊断、运行指标等复杂能力，使系统真正可用。第一阶段在标准需求、Bug修复、平台自我迭代、历史问题池等场景中跑通了从输入到验收的完整链路，验证了“把人类流程Agent化”的可行性，并沉淀了关键判断：一段工作可由系统推进、多个Agent可按流程协作、上下文可在系统内传递、异常可暴露、交付可闭环。文章最后指出人的位置从处理单点任务上移到设计机制，并提出下一阶段从“人类流程Agent化”走向AI原生工作流，探索更适合AI协作的组织方式。当前方案适用于边界清晰、目标明确、结果可验收的工作，强依赖人工定义流程边界和验收标准，尚不能处理高度模糊或创造性任务。
本文不是简单的Agent应用介绍，而是展示了一套多Agent协作系统的完整工程设计与真实运行经验，涵盖架构设计、关键能力补全、失败路径处理与持续改进，具有高度的可迁移价值。适合从事AI工程化、平台建设、自动化协作研究的工程师或技术管理者，能为其提供从单点Agent到组织级协同的实践路径与工程决策参考。
工程实践 Cloudflare Blog 2026/07/08
这篇文章介绍了 Cloudflare 为全球 330+ 数据中心控制面状态设计的实验性一致性服务 Meerkat。作者先明确需求：既要线性一致、又要在机器宕机、链路抖动和部分数据中心失效时保持可写可读，因此传统依赖主节点和超时的 Raft 在广域网里容易因 leader 故障或误判超时而不可用。Meerkat 采用 EPFL 提出的 QuePaxa，让任意副本都能发起提议，多个副本并发提案不会像 Raft 那样互相干扰，从而在多数派可通信时维持进展。文章还用日志槽位解释了如何通过一致的决议顺序实现 linearizability，并说明读写都可能进入日志以保证一致性。它也坦陈系统的边界：共识带来多轮往返和较高延迟，因此更适合写入稀少但必须强一致的控制面场景，而不适合通用数据库或低延迟业务。
推荐收录，因为文章给出了从 Raft 痛点到 QuePaxa 选择、再到 Meerkat 架构落地的完整论证链条，并明确展示了广域网一致性系统的可用性与延迟权衡。适合做分布式系统、控制面设计和一致性协议选型的参考，但需注意它仍是实验系统，结论主要适用于多数派可达、写入较少的场景。
工程实践 知乎 - 千问云 2026/07/08
文章复盘了在 Devix 上搭建 7x24 自动化运维系统的实践，目标是让 AI Agent 接管告警诊断、分级处置和结果闭环。作者提出 Harness Engineering：让 Agent 负责语义理解和推理，脚本负责数据召回与动作执行，以确定性流程约束模型的不稳定和“没记性”。系统以钉钉、DataWorks、ODPS 为核心链路，完成告警触发、深层日志解析、案例检索、决策树分流和自动重跑、人工确认或升级处理。文中进一步设计了基于错误模式和历史成功率的置信度调整、规则库自进化机制，以及自动重跑、代码修复的多层安全防线。适用边界是故障模式较可枚举、API 和知识库完善、且允许用历史案例逐步放权的运维场景；对于高度开放或高风险动作，仍需严格人工兜底。
收录依据很明确：文章不是泛谈 Agent，而是给出了告警、诊断、决策、执行、追踪、沉淀的完整工程闭环，以及置信度分级和规则自进化的具体实现。适合做 AI 运维、自动化流程编排和生产级 Agent 设计的参考，但读者需注意它依赖清晰的业务知识库、规则库和安全兜底，不能直接照搬到开放场景。
工程实践 知乎 - 腾讯技术工程 2026/07/07
文章复盘了腾讯 TAB 大仓里一套面向 AI 研发交付的 Harness 实战方案，目标不是让模型“更聪明”，而是让它能在跨微服务、跨前端微应用的真实工程中稳定跑完需求。作者把系统拆成 Rule、Skill、Sub Agent、Workflow、Scripts、MCP 六层，并通过 13 个阶段的接力流程、4 个固定角色和 5 个人工关卡，把需求分析、方案设计、开发、测试、审查到交付收尾串成闭环。文中重点强调把可判定约束下沉为脚本、把下游修改上游的权限切断、用基线对比剥夺 AI 的解释空间，以及将集成测试前置以减少昂贵的返工。作者还复盘了 Team Mode 卡死、审批弹窗过密等踩坑，最终选择删除复杂机制、改用同步子 Agent。文章适合大仓、复杂交付链路和 AI 工程化落地场景，但也明确说明其效果依赖较完整的 PRD、较强的仓库规范和可自动化的门禁体系。
推荐收录，因为文章给出了可复用的 AI 工程化落地证据：13 阶段流程、4 类 Agent、7 道门禁脚本、基线对比和 MCP 闭环，且明确复盘了卡死与返工等失败案例。适合正在做大仓提效、AI 研发流程编排或交付自动化的团队参考，但其方法对流程规范和自动化能力要求较高。
科研议题 BAIR Blog 2026/07/07
这篇 BAIR 观点文章讨论了“智能几乎免费”后，数据系统将围绕 agents 重新定义的三类问题：为 agents 设计查询与分析接口、为 agents 构建长期运行与协作的底座、以及由 agents 反向合成可用的数据系统。作者结合已有研究指出，agentic speculation 会带来大量重复子查询，因此系统应支持共享扫描、多查询优化、近似回答、批量查询和更主动的性能反馈，而不再把 SQL 当作唯一交互形式。对于多 agent 场景，文章强调需要结构化记忆、面向任务的检索、并发编辑控制、故障恢复与协商机制，以避免上下文膨胀和 livelock 等问题。最后，作者讨论了用 agents 生成专用 OLAP 引擎、KV 存储乃至证明辅助的系统构造流程，但也指出规格不完备会导致 reward hacking，因此验证与测试是关键边界。整体上它是一篇研究路线图而非成熟方案，价值在于系统梳理了 agents 与数据系统共同演化的研究问题。
推荐收录，因为正文明确提出了“for/of/by agents”三条研究主线，并给出共享查询、结构化记忆、并发控制、系统合成与验证等可落地的技术方向。适合做数据系统、AI 基础设施和 agent 研究的选题地图，但应注意它是前瞻性观点文章，很多结论仍依赖作者正在推进的工作。
工程实践 知乎 - 腾讯技术工程 2026/07/03
文章以腾讯应用宝活动平台重构为背景，介绍团队如何从“对话式 AI Coding”升级到 Harness Engineering 的端到端工程实践。作者认为单窗口对话在上下文膨胀、业务知识缺失、无法并行和缺少自动化闭环等方面逐渐失效，因此构建了“知识库工程 + 端到端开发工程”的双层体系。知识库侧通过结构化目录、自动生成与人工补充结合、按 git hash 检测新鲜度，并用渐进式分层加载替代传统 RAG，以支撑 800+ 文档和 90+ 微服务的准确检索。开发侧用状态文件驱动流程，配合专家 Agent、DAG 并行、worktree 隔离、脚本化执行和多平台集成，把需求拆解、开发、测试、评审、发布、验证串成可中断、可恢复的流水线。文章也明确指出当前方案仍重度依赖工具链、缺少自我评估和自进化能力，属于“能跑但还需迭代”的阶段性实践。
推荐收录，因为文中给出了从单轮 AI 编码走向可编排工程系统的完整证据：知识库结构、状态文件、专家 Agent、DAG 并行和脚本化执行都落到了具体机制。适合做 AI 工程化、研发自动化和复杂业务提效的参考样本，尤其对需要把 AI 接入真实 DevOps 流程的团队有可迁移价值。
工程实践 知乎 - SmartCode 得物技术 2026/07/02
文章介绍得物团队的 AI UITester：一种面向移动端 UI 自动化测试的 AI Native 方案，目标是解决传统脚本用例迁移、调试和三端维护成本高的问题。作者给出了从用例平台 JSON 到可执行脚本的自动化 Pipeline，包括树结构展平、去重、LLM 增强、版本归档等阶段，并强调通过 Wiki 知识注入提升步骤生成准确性。执行层采用 VLM 驱动的“截图-理解-执行”闭环，配合失败分类器、置信度阈值和自愈机制，实现业务失败的自动诊断与修复。文章还对比了 Appium/XCUITest 等元素定位方案与 AI 辅助方案，指出 AI Native 的核心变化是从“维护定位器”转向“理解界面与流程”。其边界也很明确：Wiki 质量会直接影响诊断效果，复杂流程变更仍需要人工确认。
推荐收录，因为文章给出了可落地的 UI 自动化架构：用例转化 Pipeline、VLM 执行闭环、失败分类、自愈和置信度控制都有明确设计细节。适合做移动测试、AI 工程化和自动化平台建设的参考，但也要注意它对知识库质量和阈值校准依赖较强，复杂场景仍需人工兜底。
工程实践 Salesforce Engineering 2026/06/29
文章介绍 Salesforce 为 Agentforce 构建的 Unified Planner：一个统一的 AI 执行与推理运行时，用来同时支撑语音、文本、聊天以及 MuleSoft 等场景。作者解释了旧体系中 Agent Graph 与 Voice Planner 各自演进导致的能力割裂、重复实现和运维不一致，并通过将平台级职责与客户业务流程解耦来完成统一。性能上，团队把原先串行的提示注入检测、检索、校验、上下文收集等步骤改为可并行执行，并允许多工具调用并发，从而把部分响应延迟从约 20 秒降到 2.3 秒。文章还讨论了模型选择、迁移生产代理的安全验证、特性分阶段放量，以及面向视频等未来多模态交互时在表示、推理和扩展性上的新挑战。整体更偏真实平台重构与 AI 运行时设计经验，适合关注低延迟 AI 系统、统一架构和生产迁移的读者。
收录理由明确：文中给出了统一运行时、并行化执行和生产迁移验证的具体做法，并量化说明了延迟从 20 秒降到 2.3 秒。适合做 AI 平台、Agent 运行时和多模态系统设计的参考，尤其对需要在低延迟、可扩展与一致性之间做取舍的工程团队有直接迁移价值。
科研议题 知乎 - 微软亚洲研究院 2026/06/28
这篇文章是微软亚洲研究院《AI Next》播客的文字整理，核心讨论“AI 与系统如何协同进化”，以及未来“系统智能”应如何定义与落地。周礼栋从聚合通信调度、OptiFlow 自动优化等例子出发，说明传统依赖人工调参的系统方法已难以跟上 AI 规模化和动态化的发展节奏。文章进一步提出，系统智能不是简单用 AI 辅助开发，而是让 AI 负责开放空间中的探索、生成与方案搜索，让系统负责抽象、约束、验证、执行与反馈，形成可闭环、自适应、可演化的基础设施。文中还强调可信基石的重要性，主张以最小可信计算基、形式化验证、隔离、审计和回滚机制约束 AI 的不确定性，并以 Verus 等工具为例说明可验证代码与 AI 生成代码结合的可能。最后，文章讨论了模型与硬件解耦、开放多元计算生态，以及培养同时理解 AI 与系统的交叉型人才等问题。整体上它偏研究方向与方法论梳理，案例具有启发性，但更像观点访谈而非完整实验论文，适合将其视作趋势判断和系统设计思路参考。
文中直接给出 OptiFlow、最小可信计算基、Verus 等具体例子，说明“AI+系统”从理念到机制的可行路径，不是泛泛而谈。适合做系统研究、AI 基础设施和可信计算方向的趋势参考，但需注意它是访谈式观点整理，实验细节与量化评估不如论文完整。
工程实践 Cloudflare Blog 2026/06/25
文章介绍 Cloudflare Workflows 新增的 saga rollback 机制，目标是在长事务、多步骤流程中，把补偿逻辑直接和每个 step.do() 绑定，避免开发者手写复杂的 try-catch、状态跟踪和回滚顺序控制。作者用转账、库存和通知等例子说明：当某一步失败时，系统会按逆向的 step-start 顺序执行补偿，并要求 rollback 本身也具备幂等性、重试和超时配置。文章还比较了 fluent、builder 与 options 三种 API 设计，最终选择把 rollback 作为 step 元数据，以保持 step.do() 的语义、并发执行模型和可读性不变。底层实现上，Workflows 依赖持久化的 step 历史、可恢复的 rollback stub 和 replay 机制，在运行时重建补偿能力，而不会重复前向副作用。该方案适用于需要跨外部系统协调、且必须处理部分成功与恢复重试的工作流，但不解决业务层天然不可逆操作的语义复杂度。
文中明确给出了 saga rollback 的执行顺序、幂等要求、恢复机制和 API 取舍，不是简单功能公告。对做工作流引擎、分布式事务编排、可靠性设计或 SDK/API 设计的读者都有直接迁移价值。
工程实践 知乎 - SmartCode 得物技术 2026/06/25
文章复盘了得物社区活动搭建从“AI 帮填表单”演进到“两阶段 Agent + 聚合工作台”的完整过程。第一版只做字段预填，虽然缩短操作时间，但仍需运营在多个系统间手工校验，且存在黑盒等待、不可逆、无持久化等问题。第二版改为以 LangGraph 编排的 Workflow 为主，通过 interrupt/resume、能力注册表和组件模块协议，把运营角色从流程执行者变成流程监督者。第三版进一步把“从想法到策划文档”前移为只读 Skill，把写操作、构建和审核留给受控流程，并用最小权限、渐进式披露和草稿同步降低风险。文章的边界也很清楚：它偏架构与取舍总结，很多细节是面向特定业务场景的工程妥协。
文章给出了从表单辅助到流程驱动 Agent 的真实演进链路，直接包含 LangGraph、interrupt/resume、模块协议和最小权限等可复用设计。适合做企业级 AI 工作流、运营工具和人机协作架构的参考，但需注意其结论强依赖高正确率、强约束业务场景。
工程实践 PlanetScale Blog 2026/06/25
文章介绍了如何在一个 PlanetScale Postgres cluster 中承载多个应用：先用逻辑数据库把 blog、todo 等数据与 schema 分开，再通过角色与权限控制实现彼此隔离。作者重点解释了 Postgres 默认对新数据库开放 PUBLIC CONNECT、以及需要显式 REVOKE/GRANT 才能把访问收紧到指定角色，这也是多应用共享集群时最容易踩坑的部分。随后文章给出用 PlanetScale API 创建角色、再在数据库内授予 CONNECT、CREATE 和 schema 权限的完整流程，并提醒读写与迁移职责最好拆分成不同角色。最后作者把这些步骤自动化到 Pulumi/IaC 中，展示如何把新增或删除应用简化为修改配置数组并重新部署。文章也明确边界：这种共享集群方案更适合 side project 和小规模应用，增长到高并发或大量用户时仍应迁移到独立集群。
文章直接给出了 Postgres 多逻辑数据库隔离、角色权限收紧和 IaC 自动化的可执行做法，不是泛泛介绍概念。适合需要在同一集群承载多个小应用、或想把数据库权限管理流程自动化的工程读者参考；但它也明确说明了规模上来后应切到独立集群。
工程实践 Kubernetes Blog 2026/06/24
这篇文章聚焦 Kubernetes Device Management Working Group 的成立背景、职责边界和当前重点，核心是在 AI、边缘计算、通信等硬件密集型场景下，如何让 Kubernetes 更好地管理 GPU、TPU、NIC 等专用设备。文章系统解释了 Dynamic Resource Allocation（DRA）的四阶段模型——资源建模、资源请求、调度与执行，并说明 DRA 相比传统 Device Plugin API 的关键改进：从“只能申请几个设备”升级为可表达设备类型、容量、拓扑、共享和切分等更细粒度约束。文章还讨论了跨 SIG 协作、共享/可消耗容量、拓扑感知、多节点调度以及 NP-hard 的优化难题，并给出了 DRA 未来在健康监控、可观测性和更复杂硬件建模上的演进方向。
推荐收录，因为它不是单纯的产品动态，而是把 Kubernetes 在硬件管理上的核心抽象、演进路径和设计权衡讲得很清楚，适合作为理解云原生调度与设备编排的长期参考。对于做平台工程、调度系统、AI 基础设施或 Kubernetes 扩展开发的读者，这篇文章能直接提供可迁移的 API 设计和跨团队协作方法。
工程实践 Anthropic Engineering
这篇文章系统复盘了 Anthropic 在多个 Claude 产品中如何做“容器化/隔离式”约束，核心目标不是单纯让模型少犯错，而是通过环境边界、模型层防护和外部内容治理来限制 agent 的爆炸半径。文章分别讨论了 claude.ai 的临时容器、Claude Code 的人机协同沙箱、Claude Cowork 的本地 VM 三种隔离模式，并结合真实披露的漏洞与红队事件说明了信任边界、egress 控制、文件挂载、MCP 连接器、提示注入和数据外泄等关键风险。结论是：对 agent 安全而言，确定性边界比概率性监督更可靠，且隔离方案必须根据用户能否有效监督 agent 来选择，同时要警惕自研组件比成熟基础设施更容易出问题。
推荐收录，因为它不是泛泛谈“AI 安全”，而是给出了可落地的 agent containment 架构、风险分类和多次真实失误后的修正经验。对正在构建 LLM 应用、代码代理、企业知识工作代理或本地工具接入系统的工程团队，这篇文章提供了很强的可迁移参考价值。
工程实践 知乎 - 千问云 2026/06/24
文章围绕工程知识库在检索、组织和同步上的结构性瓶颈展开，系统比较了 Naive RAG、LLM Wiki、Graphify 和 GraphRAG 四种范式，并指出单纯向量检索容易出现“每次从零推导”“无法连点成线”“粒度混乱”等问题。作者进一步提出“金字塔”式知识库方案：按原则、架构、规范、实现、经验五层组织知识，用图谱关系和角色感知路由来提升上下文选择质量，并给出增量同步、审计机制和一组小规模评测结果。
推荐收录，因为这篇文章不是泛泛谈 RAG，而是围绕工程知识库的结构化组织、检索路由、同步更新和评测方法给出了一套可落地的设计框架。它对正在构建 AI 知识库、内部文档问答或 Agent-native context layer 的读者具有较强的迁移价值。
工程实践 Meta Engineering 2026/06/23
这篇文章围绕 Meta 为 AI 眼镜定制超窄钢壳电池的工程实践，解释了为什么传统软包电池难以适配眼镜镜腿这种极窄空间，以及他们如何通过改变电芯形态、极片结构和制造公差来提升可用体积与峰值供电能力。文中还讨论了双电池系统的同步、交叉充电风险、不同代际产品的容量提升与系统级续航优化，展示了硬件、固件和结构设计协同迭代的思路。
推荐收录，因为它不是单纯的产品宣传，而是给出了在极端尺寸约束下重做电池形态、降低内阻、处理双电池协同的具体工程思路。对可穿戴设备、嵌入式硬件和低功耗系统设计读者都有较强迁移价值。
工程实践 Netflix TechBlog 2026/06/19
这篇文章介绍了 Netflix 在个性化通知系统上的一次架构重构：将原本耦合的单一发送决策拆分为“慢策略”和“快策略”两层。慢层负责按周尺度为用户制定消息频率和渠道节奏等长期计划，快层负责在实时机会到来时选择具体发送内容，从而同时兼顾短期点击与长期疲劳、退订风险。文章还解释了效用函数如何把正向参与信号、负反馈信号和统一消息成本结合起来，以及如何通过 feature store 在两层之间异步传递策略状态。
推荐收录，因为它不仅讲“怎么建模”，更讲清了推荐/通知系统中长期目标与短期决策冲突的工程化解法，具有很强的可迁移性。对于做推荐系统、消息触达、AI 产品决策或策略分层架构的读者，这篇文章能直接提供可复用的设计思路和权衡框架。
工程实践 Cloudflare Blog 2026/06/18
这篇文章系统讲解了 Cloudflare 如何把“单次的安全审计技能”演化成面向整个代码仓库群的漏洞发现与验证流水线，核心思想是把模型当作可替换部件，而把持久化状态、调度、去重、交叉验证和人工复核做成稳定的基础设施。文章详细拆解了 Recon、Hunt、Validate、Dedup、Trace、Judgment、Fixing 等阶段，强调通过数据库持久化、独立验证模型、跨仓库依赖追踪、PoC 强约束和人类签核来压低误报并提升可扩展性，同时明确指出这种体系更适合大规模、长期运行的安全研究场景，而不是依赖单个提示词或单个模型会话。
推荐收录，因为它不是泛泛谈“用 AI 找漏洞”，而是给出了一套可以迁移的工程架构：如何把不稳定的模型能力包进可恢复、可去重、可验证、可审计的流水线中。对做安全自动化、LLM 编排、复杂任务代理系统和大规模人工复核流程的读者，都有很强的参考价值。
工程实践 知乎 - SmartCode 得物技术 2026/06/18
文章讲述得物技术如何把埋点与指标需求承接流程重构为一条由 Hermes Agent 驱动的可回放工作流，重点解决需求信息分散、历史口径难追溯、变更风险难暴露和生产确认成本高等问题。作者不是让 Agent 直接给最终结论，而是把流程拆成工作区、看板、规则资产、结构化工具接口、系统预演和人工确认点，让 AI 负责判断前的工程化准备，人负责业务语义、口径裁决和生产放行。文章最后还明确提出要用准备时间、交付周期、评审通过率和返工原因等指标验证这套机制的实际收益与边界。
推荐收录，因为它不是泛泛讨论“Agent 能做什么”，而是给出了数据承接场景里可落地的流程重构方案，以及对应的治理边界和确认机制。对于做数仓、数据治理、AI 工程化或内部工作流自动化的读者，这篇文章对“如何把经验沉淀成规则资产、如何把风险前置到流程中”有较强迁移价值。
工程实践 Cloudflare Blog 2026/06/17
这篇文章围绕“如何把 agent harness 变成可上线的生产系统”展开，提出了 framework、harness、runtime/platform 三层架构，并以 Flue 与 Cloudflare Agents SDK 的结合为例，解释了为什么持久化执行、沙箱代码执行、持久化文件系统和动态工作流必须由平台层提供。作者进一步说明了 Durable Object、runFiber()/stash()/onFiberRecovered()、@cloudflare/codemode、@cloudflare/shell 和 dynamic workflows 的作用，强调这些能力能让 agent 在中断、重启、长任务和工具膨胀场景下保持可恢复、可扩展和更安全的执行。
推荐收录，因为它不是单纯的产品发布，而是把“生产级 agent”需要的运行时能力拆解成了清晰的工程分层与机制说明，适合作为架构设计参考。文章对持久化执行、沙箱隔离、虚拟文件系统和动态工作流的讨论具有较强迁移性，能帮助读者理解 agent 平台化的关键约束。
工程实践 知乎 - 千问云 2026/06/17
这篇文章围绕 DeepSeek V4 的长上下文推理，系统讲解了 Tair KVCache 与 SGLang 如何通过分层缓存来同时缓解 Prefill 和 Decode 两侧的显存压力。核心思路是用 Shadow Radix 统一逻辑前缀坐标，再分别用 HiCache 处理前缀复用的多级存储回落与恢复，用 HiSparse 处理 Decode 阶段 C4 压缩历史的按需加载，从而在多轮对话场景下提升 Prefill 吞吐接近 3 倍，并在高并发下显著抬升 Decode 的 batch size 与峰值吞吐。文章也明确了这套方案的适用边界：它依赖 DeepSeek V4 的混合注意力与压缩 KV 结构，收益主要出现在长上下文、前缀复用强和并发较高的服务场景。
推荐收录，因为文章不是简单介绍一个缓存产品，而是把模型结构、推理阶段划分、KV 物理形态和缓存层级之间的关系讲清楚了，具有较强的系统设计参考价值。对于做大模型推理服务、长上下文优化和显存治理的读者，这篇内容能直接迁移为架构分析框架和实现思路。
工程实践 Dropbox Tech 2026/06/12
这篇文章介绍了 Dropbox 如何用 Dash、MCP 和大模型把设计评审中的威胁模型重新带回代码评审流程，从而弥合“设计到实现”的安全信息断层。作者给出了较完整的实证数据：在 150 份安全设计评审中，只有 12% 的实现 PR 显式回链到原始评审，但借助 Dash 的语义搜索可关联到 80% 的实现，其中大部分关系只能通过语义检索发现；同时，超过半数 PR 距离安全评审已超过一个月，说明安全意图很容易在开发过程中失去可见性。文章进一步展示了基于 MCP 的上下文桥接架构、LLM 在代码与威胁模型对照中的作用，以及对误报、过时上下文和人工最终裁决的设计边界，适用于安全、隐私、合规和平台接口变更等场景。
推荐收录，因为它不是泛泛介绍 AI 应用，而是给出了一个可落地的工程模式：用检索、上下文协议和模型推理把设计意图带回实现审查。文章还提供了内部统计、验证结果和明确的护栏设计，对做安全审查、代码评审和企业知识检索的团队都有直接参考价值。
工程实践 知乎 - SmartCode 得物技术 2026/06/11
文章介绍了一个为 Claude Code 增加“长期记忆”和“自我进化”能力的工程系统，核心由行为观测、模式提炼和记忆注入三层组成。作者通过 Hook 机制稳定采集工具调用日志，再用统计规则与模型语义分析提炼 Instinct，并结合本地 Embedding 和向量检索把项目记忆在新会话中自动注入，从而让助手跨会话保持上下文、逐步修正行为。文章还给出了数据分片、置信度衰减、去重聚合、隐私边界和效果量化等设计，说明这套方案适合需要频繁与 AI 编程助手协作的个人或团队，但更适合作为定制化工程实践而非通用产品方案。
推荐收录，因为它不是泛泛讨论“AI 记忆”的概念，而是给出了可落地的 Claude Code 工程实现：从 Hook 采集、规则提炼、向量召回到上下文注入，链路完整且有真实运行数据。对想要改造 AI 编程助手、构建个性化工作流或理解 agent 记忆系统边界的读者，都有较强的迁移价值。
技术文章 知乎 - 千问云 2026/06/10
文章围绕 Agent 技术范式的演化展开，系统梳理了从早期被动式 ReAct、到以工程约束为主的 Workflow Agent、再到具备长程规划能力的自主 Agent，以及进一步强调持续学习与沉淀的自进化 Agent 的变化路径。作者还从 Prompt、Planning、Memory、Tools、Workflow、Environment 六个维度总结了技术实现和组织方式的迁移，例如从单体 System Prompt 走向上下文工程、从 Function Call 转向 CLI/Script、从刚性编排转向 Skills 与混合架构，并强调在真实落地中应根据复杂度、稳定性和成本选择组合方案。
推荐收录，因为文章不是单纯追逐热点，而是把 Agent 的核心模块、工程取舍和架构演进串成了一条可复用的分析框架，适合想理解当下 Agent 设计思路的工程师和产品技术负责人参考。它的价值在于帮助读者判断不同范式的适用边界，避免盲目追新，尤其适合做 AI 应用落地、工作流编排和 Agent 系统设计的人群。
工程实践 知乎 - 千问云 2026/06/02
这篇文章分享了作者为 Harness 场景搭建“技能工厂”的完整工程思路：先用裸模型评估和现有 skill 匹配来判断是否真的需要生成新技能，再用测试问题驱动生成、多路并行 creator 竞赛、测试-优化-再测试的回归流程来提高首次生成成功率和交付稳定性。文章还讨论了对知流平台的生态适配，以及未来如何结合 trace 数据挖掘可复用技能、把 agent 的隐性执行经验沉淀为显性资产。
推荐收录，因为它不是单纯讲“用 AI 写代码”，而是把 agent 技能生成、自动化评测、回归优化和平台适配串成了一条可复用的工程流水线。对做 AI 应用、Agent 平台或内部知识/技能库建设的读者，这种“先评测再生成、并行探索、失败优先”的思路具有较强迁移价值。
工程实践 知乎 - 腾讯技术工程 2026/05/29
这篇文章基于 OpenClaw 与 Hermes 的源码，系统拆解了 AI Agent 平台在 Gateway 微内核、Channel 契约、Session 路由、Auth Profile、Compaction、Subagent、Sandbox 和记忆系统上的核心设计。作者不是停留在功能介绍，而是把“为什么这样设计”讲清楚：例如多协议接入如何做成插件契约、上下文与凭据如何分级降级、以及如何在单体与多 Agent、CLI/ACP/MCP/HTTP 多种暴露面之间做双向互联。全文还用实际插件开发经历串联源码细节，明确指出这些不完美背后的工程取舍与适用边界。
推荐收录，因为它提供的是一套可迁移的 Agent 系统架构分析，而不是单纯的产品演示或经验碎片。文中对协议分层、路由隔离、容错降级、安全审批和记忆管理的拆解，能够直接帮助读者理解和复用生产级 AI Agent 的设计方法。
工程实践 Cloudflare Blog 2026/05/28
这篇文章系统介绍了 Cloudflare 如何搭建统一数据平台 Town Lake，以及其上的 AI 数据代理 Skipper。核心方案是以 Trino + Iceberg + R2 构成湖仓式数据底座，再叠加 DataHub 元数据、Lifeguard 权限控制、Skimmer PII 扫描、Transformer ELT 和 Ingestion 管道，实现默认关闭、可审计、按会话授权的数据访问。文章进一步说明 Skipper 如何利用多层上下文、代码模式 MCP 接口和运行时验证，把自然语言问题转成可追溯的 SQL 查询与图表，并总结了工具设计与提示词工程的经验教训。
推荐收录，因为它不是单纯的产品宣传，而是完整讲清了超大规模企业数据平台从架构、治理到 AI 查询代理的实现方式与权衡。对做数据平台、内部分析系统、权限治理或企业级 AI Agent 的读者，都有较强的可迁移参考价值。
技术文章 知乎 - 鹅厂架构师 2026/05/28
这篇文章试图从工程史与控制论角度重新定义“AI软件工程”：作者认为过去五十年的软件工程主要是在管理人的不确定性，并未真正实现工程化；大模型首次让“能源换高阶认知”成为可能，因此软件开发有机会从“人为中心 + AI 辅助”转向“AI 为中心 + 人工辅助”。文章进一步提出，真正可靠的 AI 软件产线必须依赖确定性裁判（如编译、测试、监控、契约验证）形成闭环，并通过分治结构、分工协调总线、场景驱动的隐性知识蒸馏来让 AI 从局部写代码工具升级为可被组织化运营的认知产线。适用边界上，文章更多是范式推演和组织设计蓝图，强于方向判断与框架抽象，弱于实证数据与可验证案例。
推荐收录，因为它不是单纯的工具使用经验，而是从工程机制、验证闭环和组织形态三个层面讨论 AI 如何重构软件生产，具有较强的迁移价值。虽然部分论断偏宏观和前瞻，但对关注 AI 代码生成、工程自动化和研发组织变革的读者，能提供一套可继续讨论和拆解的框架。
个人心得 知乎 - 孔某人 2026/05/28
文章围绕“长程任务”重新审视白领工作与 Agent 能力边界，认为很多可持续 1 小时以上的任务并不是抽象的“白领任务”，而是高度专业化、强依赖上下文和质量标准的岗位流程。作者进一步讨论了任务执行中不可避免的信息获取与交付标准同步问题，提出在更高 Agent 渗透率下，组织形态可能从按岗位划分转向按工艺流程划分，并比较了类人多 Agent、中央 Agent 和质检返工机制等不同设计路径。
推荐收录，因为它不是泛泛谈“Agent 很强”，而是把长程任务拆到信息流、交付标准、组织结构和工作流单元这些更可迁移的设计层面，适合做 AI 工程与 Agent 产品设计的参考。虽然文章偏观点和反思，缺少严格实验数据，但它对理解长任务场景、团队协作与中控式 Agent 架构的权衡很有启发。
工程实践 知乎 - 哔哩哔哩技术 2026/05/27
文章分享了哔哩哔哩商业广告业务中，将大模型从“输出文本”升级为“生成可交互界面”的完整工程实践。作者基于 Google A2UI 协议，自研了 Vue 渲染器与 Agent 工具链，并重点说明了 Runtime Schema 动态装配、双重校验、SSE 双通道输出、消息幂等处理、DataModel 绑定和 Wrapper 组件体系等关键设计。
文章不仅讲清了为何模板填充式方案不够用，也交代了在多业务场景下如何通过协议标准化、白名单控制和状态机约束来提升生成式 UI 的安全性与可维护性。结论上，它适合已经在做 AI 应用落地、前后端协同和组件化渲染的团队参考，但作者也明确说明当前方案仍属于混合模式，复杂组件尚不能完全交给模型自主生成。
推荐收录，因为它不是泛泛介绍“AI 生成界面”的概念，而是给出了从协议选型、后端校验到前端渲染的完整落地链路，具有很强的工程参考价值。对于正在建设 AI 助手、低代码交互或生成式 UI 平台的团队，这篇文章的协议约束、状态管理和容错设计都可直接迁移。
工程实践 知乎 - 皮振伟 2026/05/26
文章围绕 LLM 推理部署中 KV Cache 依赖带来的扩缩容困难、命中率波动、内存冗余和成本不透明等问题，提出以 GPU 为中心、通过 GD2FS 这类分布式文件系统承载 L2 缓存的无状态化推理架构。作者进一步用 Kubernetes 的弹性调度类比互联网后端演进，说明显式 KV Cache、零拷贝数据路径、预读分层缓存和可调副本策略如何提升资源利用率、降低主机内存占用，并给出了一组 RDMA/TCP 与多节点推理测试数据作为支撑。文章的主要边界在于：它更像一篇面向落地的架构提案与实践总结，部分性能结论需要结合具体硬件、负载和实现细节理解，不能直接泛化到所有推理场景。
推荐收录，因为它不是单纯讨论 LLM 推理概念，而是把缓存层级、调度弹性、状态管理和存储协议放到同一套架构框架里分析，具备较强的工程可迁移性。对做大规模推理平台、云原生基础设施和 GPU 资源调度的读者来说，这篇文章能提供有参考价值的设计思路、性能指标视角和权衡点。
工程实践 知乎 - 鹅厂架构师 2026/05/26
文章系统介绍了腾讯音乐在大仓多服务场景中落地 Harness Engineering 的实践，核心目标是把 AI 编程从“对话式生成”升级为“可控、可审计、可复用”的工程流程。作者提出用上下文工程、流程门禁、服务矩阵、三层知识体系、Skill/Agent/Command 三件套和 Self-Refinement 机制，把需求、设计、开发、验证和经验沉淀串成一条可追溯的链路，从而降低 AI 生成代码在生产环境中的漂移和返工。文章也明确给出适用边界：它不是替代 IDE 或通用 AI 编程工具，而是位于执行层之上的治理层，尤其适合跨服务、跨仓库、强契约约束的企业研发场景。
推荐收录，因为它不是泛泛谈“AI 提效”，而是把 AI 协作中的真实工程矛盾拆成了可落地的治理方案，包含流程、知识、契约和审计等多个层面。对正在探索 AI 编程工程化、Monorepo 微服务协作和团队级 AI 治理的读者，这篇文章有很强的迁移价值。
工程实践 NVIDIA Technical Blog 2026/05/21
文章围绕 NVIDIA GB200 NVL72 这类高密度 GPU 机架如何通过 Slurm 的拓扑感知调度来提升作业性能，核心关注点是“任务如何放置”而不仅是“硬件有多快”。它强调在共享集群里，调度器需要理解节点、机架和互联拓扑，才能更好地把大模型训练或推理作业映射到合适的资源上，从而更接近整机架的性能上限。文章的适用边界主要在于面向 AI/HPC 集群管理与 Slurm 调度实践，尤其是对 NVIDIA 这类高带宽、强拓扑约束平台的资源编排问题。
推荐收录，因为它讨论的是大规模 GPU 集群中非常典型且长期存在的问题：如何通过拓扑感知调度减少性能损失、提升资源利用率。对做 AI 基础设施、HPC 集群管理和高性能作业编排的读者来说，这类经验具有较强的可迁移价值。
工程实践 Microsoft Research Blog 2026/05/21
这篇微软研究博客介绍了一个面向小模型的 agentic 系统组合：MagenticLite 作为跨浏览器和本地文件系统的应用层，MagenticBrain 负责规划、代码生成与任务委派，Fara1.5 则承担浏览器 computer-use 任务。文章重点不在单一模型能力，而在“模型、数据、工具调用格式、执行 harness、交互界面和沙箱环境”协同设计，强调小模型要想完成真实任务，关键在于分层编排、上下文管理和明确的人类审批点。作者还给出了针对网页表单、登录、长任务和文件整理等场景的评价思路，说明标准 benchmark 之外还需要场景化评测来推动迭代，但整体仍是研究发布性质，适合参考其系统设计方法而非直接当作稳定产品方案。
推荐收录，因为它不是简单的模型发布稿，而是把 agent 系统的关键问题拆成了可迁移的工程要素：任务分解、delegation、上下文裁剪、critical point、沙箱隔离和场景化评测。对于做 LLM agent、computer-use、工具调用编排和安全护栏设计的读者，这篇文章能提供一套完整的系统视角。
技术文章 知乎 - 腾讯技术工程 2026/05/19
这篇文章围绕“17种 Agent 架构演进”展开，不是简单罗列概念，而是用统一的分析框架拆解每一代架构新增了什么状态、路由逻辑和验证机制，以及它为何能比上一代解决更多问题。作者结合 agno 的 Workflow、Router、Loop、Parallel、Team 等抽象，将 Reflection、Tool Use、ReAct、Planning、PEV、多 Agent、Blackboard、Ensemble、Memory、Graph Memory、Tree-of-Thoughts、Mental Loop、Dry-Run、Metacognitive、Self-Improvement、Cellular Automata 等模式逐一落成代码，并系统说明了各自的失败模式与升级边界。文章的核心结论是：Agent 架构的本质不是 prompt 技巧，而是控制流设计；可靠系统必须显式建模状态、路由、终止条件和评估器。
推荐收录，因为它把 Agent 架构从“概念清单”提升到了“控制流与状态机”的层面，能直接指导真实系统的设计与排错。文章不仅有方法论总结，还给出可迁移的分层判断标准，适合做 Agent 工程入门到进阶的长期参考。
工程实践 Instacart Tech Blog 2026/05/14
这篇文章复盘了 Instacart 如何把原本面向自营 Marketplace 的营销自动化系统，扩展为支持多租户白标商户的个性化营销平台。核心方案包括：为每个零售商建立隔离的第三方工作区、在内部构建自助式营销工具、通过流式消费与最多 50 条的批处理提升吞吐、在 CRM 服务中做幂等控制与异步发送，并用模板自动化、IP warming、可观测性和故障隔离保障大规模稳定交付。文章还给出了平台已经达到的效果与未来可能演进到 AI 辅助内容生成、多渠道编排的方向，适合关注多租户架构、营销系统工程化与供应商抽象的读者参考。
推荐收录，因为它不是简单的产品介绍，而是完整展示了一个多租户营销平台从架构拆分、流式处理、批量发送到运维治理的落地方法。对做 SaaS、增长系统、事件驱动架构或第三方供应商集成的团队，都有很强的可迁移价值。
工程实践 知乎 - 千问云 2026/05/13
文章围绕 AI Agent 在企业工程环境中的落地，提出“Harness Engineering”这一控制面概念，核心是用外部状态、能力边界、沙盒验证、checkpoint 和回写机制，把大模型这种非确定性引擎纳入可交付的工程体系。作者结合 Aegis 内部项目的真实推进过程，详细说明了从目标收敛、Spec/Handoff 持久化、Capability 路由，到测试前置、日志反咬、审批门禁等一整套落地方法。文章的结论是：模型能力本身已足够参与交付，但只有先建立 Harness，Agent 才能从“高级玩具”变成可持续协作的研发协作者，同时工程师的角色也会从亲手写代码转向目标定义、节奏控制和结果验收。
推荐收录，因为文章不是泛泛谈 Prompt，而是从真实项目出发，系统拆解了 AI Agent 进入生产环境时必须面对的状态管理、执行边界、验证闭环和故障恢复问题。它对想把大模型真正接入研发流程、并思考人机分工变化的工程师具有很强的可迁移价值。
工程实践 知乎 - 孔某人 2026/05/11
这篇文章延续上一部分，讨论下一代 Agent 架构为什么不能只依赖单一 harness 自动生成，而需要引入更复杂的“智能 harness”或多角色协作设计。作者从长任务场景出发，系统列出当前 LLM/Agent 的一组关键问题，包括上下文窗口不足、任务中后期懒惰、奖励目标偏移、单上下文复盘失效、元认知不足以及长期任务能力薄弱，并进一步指出这些问题在 multi-agent 场景里还会叠加协作可靠性和协作规划问题。
推荐收录，因为文章不是泛泛谈“多智能体更强”，而是基于作者的原型实践，明确拆解了当前 Agent 系统的失效模式和需要补强的架构环节。对做 AI 工程、Agent 框架或长任务自动化产品的人来说，文中的问题清单、角色分工思路和边界判断都有较强迁移价值。
工程实践 知乎 - 千问云 2026/05/08
这篇文章以 Claude Code 源码为依据，系统拆解了一个成熟 Agent 产品从启动、REPL 控制面、Query Loop、Tool Runtime、权限系统、Task/多 Agent 到 MCP/Skills/Plugins 扩展层的完整运行链路。作者的核心论点是：Agent 系统真正的复杂度不在模型本身，而在于把边界、连续运行、行动协议、风险控制、并发执行和平台扩展分别放到合适的 runtime 层中，从而避免主循环被各种特判拖垮。文章最后总结出一套可迁移的方法论：先定执行边界，再把上下文治理、工具副作用、权限与任务生命周期制度化，适合做 AI Agent、研发工具链和平台架构设计的人参考。
推荐收录，因为它不是泛泛而谈 Claude Code 功能，而是从源码和系统视角提炼出可复用的 Agent 架构方法，特别适合做 AI 工程、开发者工具和平台化产品的读者。文章对启动链路、控制面、工具协议、权限和多 Agent 生命周期的拆解很具体，能直接迁移到类似系统的设计与复盘中。
工程实践 Lyft Engineering 2026/04/23
这篇文章复盘了 Lyft 如何改善封闭社区内的叫车接送体验。作者先指出两个核心问题：默认选点会把乘客引到围栏内，而上车说明只能临时聊天补充，导致司机找不到入口、等待和取消率上升。为此，团队把门禁社区编码进地图数据，生成门区边界，并在乘客端提供“门内/门外”两类更贴近真实行为的上车点建议。随后又在路由中加入经过大门的中间停靠点，并在司机接近门口时及时展示简洁的门禁说明，同时加入可删除、不可跨行程保留等隐私保护。上线实验显示该流程未显著增加下单流失，且降低了取消、缩短了等待，说明把现实约束显式纳入地图、推荐、路由和交互链路是可复用的工程方法；但当前覆盖仍依赖地图数据完整性，且多入口社区的最优选门仍有改进空间。
收录价值在于它给出了一个完整的工程闭环：从地图建模、路径改造到交互时机和隐私控制，并用实验和指标验证效果。适合做地图、出行、位置服务或复杂前端/后端协同系统的参考，但也要注意其方案强依赖本地地理数据质量与覆盖。
工程实践 NVIDIA Technical Blog 2026/04/07
文章围绕 NVIDIA GB200/GB300 NVL72 这类 rack-scale 超级计算机，说明其以 Blackwell 架构、18 个紧耦合计算托盘、GPU fabric 和高带宽网络组成统一系统。作者强调，AI 任务在这种硬件上运行时，关键不只是“把机器装进机柜”，而是要理解通信拓扑并据此做作业放置与调度。文章从硬件层次、网络/互联特性讲到 topology-aware scheduling，重点讨论如何减少跨托盘通信、匹配计算与通信密集型负载，并提升整体吞吐和资源利用。结论是，软硬件协同设计能明显改善大模型训练与推理的扩展性，但方案强依赖特定 rack-scale 平台，不宜直接照搬到普通集群。
有明确的硬件细节与调度方法，不是单纯产品介绍：文章直接讨论 rack-scale 互联结构、负载拓扑感知放置和性能收益。适合 AI 基础设施、HPC 平台和集群调度读者参考，但迁移时要注意它主要针对 NVIDIA NVL72 这类特定架构。
工程实践 Anthropic Engineering 2026/03/24
文章介绍 Anthropic 为 Claude Code 设计的 auto mode，目标是在减少频繁确认带来的“审批疲劳”的同时，避免直接开启“跳过权限”所带来的安全风险。核心方案是两层防线：输入侧用提示注入探测器检查文件、网页和工具输出中的可疑内容，输出侧用基于 Sonnet 4.6 的转录分类器对每次动作做放行或阻断判断。系统在权限上采用分层策略：安全只读工具和项目内编辑可直接执行，真正高风险的 shell、外部访问、跨信任边界操作才进入分类器。作者详细给出了威胁模型、固定分类模板与可配置策略槽位，并用真实流量、真实激进行为和合成外泄集评估效果。结果表明端到端误报率可降到 0.4%，但真实危险动作仍有 17% 漏检，说明它适合高频自动化场景，不适合作为高风险基础设施的人审替代品。
文章直接公开了 AI Agent 自动审批的系统架构、威胁模型、分类规则和评测结果，属于可迁移的工程经验，而非产品宣传。适合做代理式工具安全设计、权限分层和风险边界的参考，但需注意其对真实危险动作仍有明显漏检，不宜直接用于高风险场景。
工程实践 Yelp Engineering 2026/02/02
文章介绍 Yelp 为广告预算分配系统搭建回测引擎的实践，用于在正式上线前评估调参或策略变更是否会影响广告展示、预算消耗和广告主收益。作者指出该系统存在明显的反馈回路，单点改动可能放大成系统级波动，因此仅看离线指标或局部测试并不足以判断安全性。回测引擎的目标是在历史数据和既有行为假设下重放预算分配过程，尽量提前暴露收益、投放结构和边界条件上的风险。文章强调这种方法适合复杂的广告/推荐类分配系统，但其结论仍依赖历史分布与建模假设，不能完全替代线上实验。
推荐收录，因为标题和导语直接给出了“back-testing engine”和“safer, smarter ad budget allocation”，说明它不是泛泛介绍功能，而是在解决带反馈回路的系统变更评估问题。适合做广告系统、推荐分流或其他预算/流量分配场景的工程参考，尤其可迁移其离线评估与上线风险控制思路。
工程实践 Lyft Engineering 2026/01/06
这篇文章系统复盘了 Lyft Feature Store 的架构、演进和优化实践，重点解释了如何用统一的特征平台支撑大规模 ML 训练与在线推理。文章把系统拆成批处理、在线服务和流式三条路径：批特征由 Spark SQL+JSON 配置生成 Airflow DAG，在线侧以 DynamoDB 为持久存储、ValKey 作写穿缓存，并为 embedding 引入 OpenSearch。作者进一步说明了特征治理机制，包括版本、血缘、元数据、数据质量检查、Amundsen 可发现性，以及 Kyte 本地开发和 SDK 提升迭代效率。平台演进部分展示了从 Flyte 迁移到 Astronomer、收缩少数边缘能力、增加 staging、数据契约和实时特征抽象的取舍。性能优化则聚焦于缓存现代化、payload 精简、pod 规格调整、重试/超时策略和 TTL 管理，最终把读路径 P95 降低约三分之一。文章的边界在于大量方案高度依赖 Lyft 内部工具链与 AWS 生态，但整体方法论具有较强可迁移性。
文章给出了特征平台从架构、治理到性能优化的完整工程证据，不是泛泛介绍概念，而是包含具体存储选型、缓存策略、DAG 生成和迁移取舍。适合数据平台、ML 平台和基础设施团队参考，尤其可迁移的是“统一接口+分层存储+可观测治理+围绕 P95 做瘦身”的方法。
工程实践 Stanford Hazy Research 2025/09/28
这篇文章介绍了一个面向 Llama-70B 张量并行推理的高吞吐 megakernel，目标是在 H100 上把计算、显存带宽和 NVLink 通信尽量同时吃满。作者先回顾了此前面向低延迟的单卡 megakernel，再说明高吞吐场景下工作负载更异质：矩阵乘法偏计算、RMS norm 和 decode 偏内存、跨 GPU 交换偏通信，因此必须做分层重叠。文中提出新的指令集与解释器执行模型，把 RMS norm、QKV、Attention、O-projection、MLP 等融合为少量指令，并用分布式 transpose 代替部分 reduce-scatter，以便把通信隐藏在后续计算之后。文章还展示了三层优化：SM 内指令流水化、跨 SM 的全局 work queue 动态调度、跨 GPU 的 storer 线程通信重叠，并通过消融实验证明这些策略在大 batch 下能带来数个百分点到十几个百分点的吞吐收益。最终将 megakernel 集成到 Tokasaurus，在 ShareGPT 65,536 prompts 的端到端吞吐上比 SGLang 高约 22%，但作者也明确说明这套代码对编译器版本、GPU 配置和同步细节非常敏感，属于研究原型而非可直接落地的生产实现。
推荐收录，因为文章给出了可复现的系统设计证据：指令/解释器架构、跨 SM 全局调度、跨 GPU 通信重叠，以及对应的消融和吞吐数据。适合做大模型推理、GPU kernel 融合和多卡通信优化的参考，但需注意它是强依赖 H100 和编译环境的研究代码，不宜直接当作生产模板。
科研议题 Stanford Hazy Research 2025/02/24
文章提出 Minions 协议，探索让小型端侧模型与云端前沿模型协作，把长上下文读取、任务分解和部分推理迁移到本地，从而显著降低云端 API 成本。作者先验证了一个较朴素的 Minion 聊天式方案：它只消耗约 3.3% 的云成本，却能保留 87% 的云端性能，但会受到小模型长上下文能力弱、难以稳定执行多步指令等限制。随后 Minions 采用“分解—执行—聚合”循环，由云端模型生成切分与分解代码，本地模型并行处理子任务并筛选结果，再由云端汇总或继续迭代，在金融、医疗和论文问答任务上达到 97.9% 的云端精度，成本仅为 17.5%。文章进一步指出，3B 以下本地模型通常不足以支撑该协议，推理时扩展、细粒度分解和更多通信轮次可继续提升效果，但会带来更长时延和更高本地算力消耗。整体上，它给出了端云协同推理的一种可操作协议，而不是试图用小模型完全替代大模型。
推荐收录，因为文章给出了明确的协议设计、对照实验和成本-精度数据，而不是停留在“小模型很有潜力”的泛论。适合关注端云协同、长上下文任务和推理成本控制的研究者与工程师参考，但其收益依赖较强本地模型与特定数据密集型场景。
工程实践 PlanetScale Blog 2024/11/19
这篇文章是三部曲的收官篇，集中讨论数据库限流器的客户端识别、优先级控制和规则边界。作者提出，限流器应能区分具体作业或作业类别，否则难以做监控、审计和针对性调度；同时，真正安全的“优先级”通常不是直接放行某个客户端，而是通过对其他客户端提高拒绝率来实现。文中进一步分析了豁免、不同指标下的限流与饥饿风险，指出对某些作业单独放宽指标本质上接近豁免，可能让其他作业长期得不到执行机会。作者也强调，豁免并非绝对错误，在故障修复、系统关键内部流量或短时影响可接受时可以使用，但应设置失效时间。最后，文章对比了协作式限流与代理式强制限流，说明后者更难绕过，但也更依赖客户端/连接层暴露足够的身份信息。
文章直接给出了生产环境限流器的核心设计证据：客户端身份、优先级、豁免、饥饿风险和协作/强制两种模型的取舍。适合做数据库运维、平台工程和系统设计参考，尤其对需要控制批处理、迁移和大规模任务的场景有可迁移价值。
工程实践 PlanetScale Blog 2024/08/29
本文讨论数据库节流器（throttler）的设计原则，目标是在批量导入、ETL、在线 DDL、清理和重分片等长耗时操作中保护数据库整体健康。作者先解释节流不应只按固定速率控制，而要围绕数据库是否“健康”来判断，因此重点分析了复制延迟、threads_running、队列延迟、队列长度、Load Average 和连接池占用等指标。文章强调单一指标往往只是症状，真正有价值的是能预测 SLO 的组合指标及其阈值，并说明阈值必须结合业务、硬件和部署形态来设定。文中还指出节流系统上线后会改变系统行为，健康状态常表现为指标围绕阈值上下波动而非持续低位。最后讨论了采样间隔与指标粒度的关系，认为过慢的采样会造成滞后和突发释放，应按阈值范围进行更高频的测量；但该文只覆盖系列的第一部分，分布式节流器与节流器自身影响留待后文。
推荐收录：文章不是泛泛讲限流，而是以数据库健康为中心，系统讨论了指标选择、阈值设定、队列含义和采样粒度等可落地问题。适合做数据库平台、批处理控制和稳定性治理的参考，尤其对需要设计自适应节流机制的工程师有直接迁移价值。
技术文章 PlanetScale Blog 2024/07/23
文章系统梳理了 2024 年 MySQL 在线 schema 变更的主要方案，重点比较了原生 INPLACE、INSTANT 与第三方工具的适用边界。作者指出，INPLACE 虽然在主库上可让 DML 继续执行，但会大量消耗 CPU/IO、占用额外磁盘，并且在复制链路上会把延迟放大到不可接受的程度。INSTANT 在支持范围内几乎“瞬时”完成，且对副本友好，但它主要覆盖元数据级变更，无法处理类型修改、索引/主键/外键变更、字符集和分区调整等常见需求，删除列还带来数据丢失与查询兼容风险。对于大多数真实生产迁移，文章认为 gh-ost、pt-online-schema-change、Vitess、spirit 这类影子表方案仍是更稳妥的选择，因为它们能限速、可中断、兼容更多 DDL，并且 Vitess 还把可回滚性作为一等能力。整体结论是：能用 INSTANT 时优先用，但面向绝大多数复杂迁移，第三方在线 schema 工具仍是主流答案。
文章直接对比了 MySQL 原生 DDL 与第三方在线迁移工具的行为、成本和失败边界，给出了明确的选型依据，而不是泛泛介绍功能。适合负责数据库架构、上线变更和可靠性治理的工程师参考，尤其能迁移到“如何判断某个 schema 变更该不该用原生 DDL”的决策场景。
技术文章 PlanetScale Blog 2024/07/10
文章以一个健身应用中的 exercise_log 大表为例，解释为什么少数高增长表会先成为数据库瓶颈：写入频繁、历史数据持续被查询，最终把存储、内存和 IO 都推到极限。作者先讨论纵向扩容，即通过增加 CPU、内存和磁盘来延长单机数据库的可用寿命，但指出当数据达到多 TB 时，成本和资源争用会迅速上升。接着介绍垂直分片，把大表从主库中拆出到独立 keyspace，并借助 Vitess 的 MoveTables 平滑迁移和切流，使主业务表与日志表可以分别扩展。最后给出水平分片方案：按 user_id 做哈希分布、使用 sequence 生成全局 ID，再通过 Reshard 把单表扩到多个 shard。文章还总结了分片带来的吞吐提升、备份加速、故障隔离和成本优化，同时提醒分片键选择会直接影响查询局部性和性能。
推荐收录，因为文章明确给出了大表扩容的三级演进路径，并直接展示了 Vitess 的 MoveTables、Reshard 和分片键设计等可操作证据。适合做数据库架构、MySQL 扩容和日志/消息类大表治理的参考，但读者需要结合自身读写模式谨慎选择分片键。
工程实践 PlanetScale Blog 2024/02/15
这篇文章系统拆解了 Amazon Aurora（以 MySQL 工作负载为主）的计费构成，指出它远不只是“选个实例”这么简单，而是要同时评估实例规格、预留实例折扣、副本数量、存储模式、跨可用区/跨区域流量、备份保留、监控和代理层等多项费用。作者特别说明了 burstable 与 memory-optimized 的差异、标准存储与 I/O-optimized 的取舍，以及当 I/O 费用占比超过一定阈值时，I/O-optimized 才可能更划算。文章还把读写副本、Global Database、RDS Proxy、蓝绿部署、自动备份和 Performance Insights 逐项拆开，说明这些“高可用/可运维能力”往往会直接放大账单。最后，文章以 PlanetScale 的定价和托管能力作对比，强调其在连接池、跨区复制、变更管理和监控上的简化与打包，但整体内容对 Aurora 成本建模尤其有参考价值；局限在于只覆盖 Aurora 非 Serverless 场景，且比较部分带有明显产品立场。
推荐收录，因为它不是泛泛介绍云数据库，而是把 Aurora 的主要成本项逐条展开，给出了实例、副本、I/O、流量、备份和监控的实际计费视角。适合做数据库选型、云成本估算和高可用架构评审时参考，但读者也需注意文中 PlanetScale 对比部分存在产品宣传倾向。