Engineering

148 篇内容

技术文章Phil Eaton - databases

Let's build a distributed Postgres proof of concept

本文通过约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

Exploring PL/pgSQL part two: implementing a Forth-like interpreter

文章详细展示了如何在 PostgreSQL 的 PL/pgSQL 中从头实现一个类似 Forth 的栈式解释器。作者首先介绍 Forth 语言的基本概念,然后逐步实现数据栈、程序计数器、条件分支(IF/THEN)、内建指令(DUP、SWAP、算术运算等)以及函数定义(DEF)和调用(CALL)机制,并通过 hstore 扩展存储函数入口位置,使用返回指针栈处理嵌套调用。最终通过运行递归斐波那契函数验证了解释器的正确性。文章还指出了实现中的一些 PL/pgSQL 特性限制,如数组长度处理、NULL hstore 合并等问题。该实现仅为 Forth 的子集,未涉及完整 Forth 的诸多特性,但足以展示在受限的数据库过程语言中构造解释器的可行方法。

推荐收录,因为文章提供了一个完整可运行的 PL/pgSQL 解释器实现,包含逐步代码解释、设计取舍和实际运行验证,不是简单的语法介绍或新闻转述。适合对 PostgreSQL 内部过程语言、解释器构造或栈机器实现感兴趣的读者。其可迁移价值在于展示了在资源受限且语法特殊的嵌入式语言中实现编程语言核心机制的方法,对理解解释器原理和数据库编程均有启发,技术主题长期有效。

工程实践Phil Eaton - databases

Writing a minimal in-memory storage engine for MySQL/MariaDB

文章记录了作者在一周黑客活动中探索 MariaDB 内部机制并实现一个 218 行 C++ 的最小内存存储引擎的全过程。作者从构建调试版 MariaDB 开始,发现存储引擎插件必须放在源码树内而非独立仓,并实现了 handler 子类的 create、write_row、rnd_next、rnd_init 等关键方法。文中解释了 MySQL 的固定字节行格式和全局内存表结构,同时坦诚该引擎仅支持 INTEGER 字段、单数据库、非线程安全且不支持 NULL。作者还将 MySQL 与 Postgres 的存储引擎 API 进行对比,认为基于单行传递的设计限制了列存压缩和向量化的收益。最终通过 SQL 查询验证了引擎功能,并指出这类最小项目可作为探索其他存储后端的起点,适合作为学习数据库存储层原理的入门材料。

本文是难得的数据库存储引擎实战教程,作者以最小可行方式展示了如何从零接入 MariaDB 存储接口,代码完整且步骤清晰,并诚实标注了线程安全、数据类型等局限。适合对数据库内核、存储引擎或后端系统感兴趣的开发者阅读,可迁移价值在于理解存储引擎接口的设计约束以及如何快速验证自定义存储方案,同时避免被过度简化的示例误导。

技术文章Phil Eaton - databases

Exploring a Postgres query plan

文章记录作者在探索 Postgres 查询执行钩子时的学习过程,目标是从 QueryDesc 计划对象重建原始 SQL 字符串。作者搭建了带共享库的调试环境,通过 ExecutorRun_hook 拦截查询,并逐步解释 Plan 节点、范围表、OpExpr、Const、Var 等关键结构。文中给出完整 C 扩展代码,示范如何查找关系名、操作符名和列名。最终实现对简单 SELECT 的 SQL 重建,验证了 a > 1、a + 1 和常数比较等场景。该方法仅覆盖顺序扫描、整型常量与基础 Vars,尚未处理连接、聚合、子查询和别名等复杂计划,且依赖特定版本 Postgres 内部 API。

推荐收录,因为这是一篇可复现的数据库内核级工程笔记,而非泛泛介绍:作者提供了完整 hook 代码、构建方式,并逐步验证从计划树重建 SQL 的能力。适合数据库内核、Postgres 扩展开发者以及对查询计划内部表示感兴趣的后端工程师。其可迁移价值在于展示如何遍历计划节点、解析表达式并访问系统目录,但注意依赖特定版本内部 API,升级时可能变化。

技术文章Phil Eaton - databases

Writing a storage engine for Postgres: an in-memory Table Access Method

文章围绕Postgres 12引入的可插拔表访问方法(Table Access Method)API,通过实现一个内存存储引擎原型系统介绍了其工作机制。作者从Postgres调试构建和扩展基础设施开始,逐步探索TableAmRoutine结构体中必需的回调函数,通过日志和断言定位到slot_callbacks、scan_begin、getnextslot等关键方法。文章详细记录了如何在C扩展中管理表结构、存储行数据、处理插入和扫描,并解决slot填充、扫描状态管理等实际问题。最终原型支持创建内存表、插入整数和执行简单SQL查询,展示了复用Postgres上层SQL、协议和生态的潜力。作者明确说明这是原型质量代码,尚未实现索引、删除、更新等完整功能,适合作为进一步探索的基础。

推荐收录,因为文章填补了Postgres表访问方法缺乏最小实现教程的空白,以逐层调试和可运行代码展示了从扩展骨架到内存存储引擎的完整过程。适合数据库内核开发者、Postgres扩展作者和想理解可插拔存储引擎的读者,文中的调试方法、API使用陷阱和原型边界具有直接参考价值。

技术文章Phil Eaton - databases

A write-ahead log is not a universal part of durability

文章围绕持久性与预写日志(WAL)展开,作者通过伪代码逐步演示:内存数据库先写全量 B 树到磁盘并 fsync,虽然可实现持久性但效率很低;随后引入 group commit 摊销 fsync 成本,但每次仍写全量结构。作者指出更优做法是先写客户端请求到只追加日志并 fsync,即可安全返回,主数据结构延迟写入,启动时重放日志,这就是 WAL。文章还讨论了 fsync 失败处理、磁盘/文件系统损坏时 checksum 的作用、CDC 与 WAL 的关系,并强调多数数据库默认配置在安全与性能间权衡。最后总结持久性首先取决于向客户端返回成功前是否已落盘,WAL 是低成本实现手段。文章以浅显代码示例搭建直觉,适合理解存储持久性机制,但不涉及具体数据库生产实现细节。

推荐收录,因为文章以清晰的伪代码推演解释了 WAL 并非持久性唯一手段,而是针对全量写盘低效的优化方案。它把 fsync、group commit、checksum 和日志重放等概念串联起来,有助于读者建立数据库持久性的正确心智模型。适合后端工程师、数据库学习者和对存储系统感兴趣的人阅读。需要注意的是,文中为教学目的做了简化,不能直接等同于生产级实现。

技术文章Phil Eaton - databases

Implementing MVCC and major SQL transaction isolation levels

文章用约 400 行 Go 代码实现了一个内存键值数据库,并基于 MVCC 和乐观并发控制支持五种 SQL 事务隔离级别:读未提交、读已提交、可重复读、快照隔离和可串行化。作者从多版本数据结构和可见性规则开始,逐步实现不同隔离级别下的读写逻辑,并通过读写集合在提交时进行写-写冲突或读-写冲突检测。文中用带注释的测试展示并发事务行为差异,同时讨论真空清理、版本存储放大等现实约束,并指出教学实现的局限,如未处理范围查询、子事务和保存点。

推荐收录,因为它以可运行的最小实现和测试清晰地解释了数据库事务隔离级别的核心机制,而非停留在概念罗列。适合数据库初学者、后端工程师或需要理解事务可见性和并发异常的读者;文中展示的版本可见性规则和冲突检测思路可以迁移到实际数据库选型与事务调试中。主要局限是教学简化,未覆盖生产级范围查询等细节。

工程实践LinkedIn Engineering - Architecture

Rebuilding messaging: How we designed our new system

文章复盘LinkedIn消息系统从邮件式单体架构到全新架构的设计阶段。旧系统最初使用单一Oracle数据库和分片复制,消息量五年增长四倍后,产品向聊天体验演进但代码复杂度剧增,导致开发效率下降。作者提出产品与工程需求,特别强调迁移自定义业务逻辑需要近60个转换器,并决定将数据持久化拆分到多个服务以独立扩展,同时接受分布式事务代价。团队通过高层架构文档、设定设计原则和赋权技术负责人并行推进,制定正确性优先、构建正确、再求快等原则。文章还总结了迁移策略、异步处理、团队结构和项目组织方面的经验教训,但未深入具体实现细节。

推荐收录:这是LinkedIn真实消息系统重构的工程案例,包含从单体到分片再到新架构的演进、明确需求和设计原则,以及迁移与团队组织的教训。适合架构师、后端工程师和技术负责人参考大型系统重新设计、跨团队协作和数据迁移的可迁移方法。

工程实践LinkedIn Engineering - Architecture

How we reduced latency and cost-to-serve by merging two systems

本文介绍 LinkedIn 将身份服务中的 midtier 和 data service 两层合并为一个服务的实践。原架构中 data service 仅提供数据验证和 Espresso 存储访问,业务逻辑薄弱但维护成本高,且增加网络跳数。团队在保持对外 API 不变的前提下,先将 data service 的 REST API 作为本地库嵌入 midtier,随后通过 T-REX 框架逐步灰度、下线旧服务并清理技术债。性能测试使用 Dark Canary 复制生产流量对比,结果显示 p50、p90、p99 延迟分别降低 14%、6.9%、9.6%,内存分配率下降 28.6%。最终下线整个 data service 集群,节省超过 12000 核和 13000GB 内存。文章强调这是针对特定场景的权衡,并非所有微服务都应合并。

推荐收录,因为文章提供了完整的工程案例:从问题动机、架构决策、灰度实施到性能验证,数据详实。直接证据包括 p50/p90/p99 延迟改善、内存分配下降和资源节省。适合关注微服务粒度、性能优化和成本控制的架构师与后端工程师。可迁移价值在于展示了当数据服务逻辑薄弱时合并服务的考量方法,以及利用灰度发布和流量镜像降低高风险变更的实践。

工程实践LinkedIn Engineering - Architecture

Costwiz: Saving cost for LinkedIn enterprise on Azure

LinkedIn 工程团队开发 Costwiz 以控制 Azure 云成本。系统摄取 Azure Advisor 的优化建议,通过状态机管理工单生命周期,并利用可插拔框架和工作流实现自动化。数据平台基于 ETL 架构,采用 Azure Data Factory、Databricks 和多种存储,支持资源所有权识别与清理沙箱资源。关键设计包括逐级升级机制、所有权识别模块和基于 TTL 的沙箱清理。实践表明,约 36% 的建议资源被回收,沙箱订阅成本占比从 45% 降至 5%。文章还指出,真正的挑战在于推动工程师采取行动而非仅生成建议,并总结了权限识别和数据水印等方案取舍。

推荐收录。文章详细还原了 LinkedIn 在 Azure 上构建 Costwiz 的全过程,包括工作流状态机、可插拔框架、数据平台、资源所有权识别和升级机制,并给出了成本节省的具体数据(沙箱成本从 45% 降至 5%)。其适用于云基础设施团队、SRE 和成本管理人员,其中关于责任落实、自动化清理和渐进式升级的设计具有跨云平台的可迁移价值。

工程实践LinkedIn Engineering - Architecture

Unifying Messaging Experiences across LinkedIn

本文介绍LinkedIn如何通过内部Messenger SDK统一旗舰、Recruiter、Sales Navigator等多个应用的消息体验。文章回顾了后端消息平台的建立,指出前端开发因缺少共享UI和数据层而困难。作者详细说明了SDK架构:API库(messenger-api)提供GraphQL抽象、错误检查和回调接口定制;客户端库(messenger-data)采用事件驱动数据层,包含Store、Mailbox API、Reactive Adapter、Realtime Manager和API连接层,实现本地数据同步和响应式更新。文中以InCareers为例,展示SDK节省40+开发周、代码量降至1/8的收益。最后总结迁移成果并规划可复用UI组件。文章主要呈现LinkedIn内部平台化实践,未深入底层实现或失败教训,但提供了可借鉴的架构思路。

推荐收录,因为文章不是泛泛介绍,而是给出了完整的SDK架构设计、数据同步机制、回调扩展点以及真实项目收益数据。适合架构师、跨平台开发者和平台工程团队参考,其‘薄层应用+平台库’的模式可迁移到多应用共享核心能力的场景,对大型组织统一前端能力和提升开发效率有长期借鉴价值。

工程实践LinkedIn Engineering - Architecture

Navigating the transition: adopting Azure Linux as LinkedIn’s ...

本文复盘了 LinkedIn 将服务器、虚拟机和容器从 CentOS 7 迁移到 Azure Linux 的完整历程,包括动机、规划、实施、挑战和效果。迁移核心动因是 CentOS 7 生命周期结束和业务对现代安全、性能及 AI 功能的需求,同时考虑了成本、合规和供应商支持。实施过程涵盖基础设施准备、容器镜像构建、开发者 VM 改造、配置管理适配和自动化迁移,重点解决了 XFS 文件系统调优、硬件驱动签名和开发者远程环境等难题。迁移后引导时间从1小时缩短至10-30分钟,安全性、部署速度和系统可靠性显著提升,文章还讨论了监控体系升级和反馈闭环。该案例适用于大型企业基础设施现代化场景,文中经验和方法具有可迁移性。

本文提供了大型互联网公司操作系统迁移的第一手工程实践,详细描述了从需求评估、试点到全量迁移的完整路径,包含具体技术挑战和解决方案(如容器镜像兼容、驱动签名、开发者环境),对于负责基础设施升级、云计算平台迁移或 DevOps 实践的工程师极具参考价值。适合企业架构师、SRE、系统管理员和云平台团队借鉴其迁移策略和自动化方法。

工程实践LinkedIn Engineering - Architecture

Journey of next generation control plane for data systems

文章介绍LinkedIn数据基础设施控制平面Nuage的演进,从1.0单体自服务、2.0去中心化SDK到3.0以Nuage Resource Manager为中心的架构。3.0将横向控制平面能力与资源提供方业务逻辑解耦,通过API与数据模型契约、RBAC、搜索缓存、审计、异步工作流等实现统一治理。文中详述客户端交互、请求路由、数据治理与MCE联动、监控告警以及横向服务。并给出性能提升(如Espresso读P90从10秒降至3秒以下)、安全改善和MySQL接入成本降低70%等量化结果。适用边界是LinkedIn内部多平台环境,偏重架构与运营模式,未涉及具体代码实现。

推荐收录,因为文章不是概念介绍,而是完整呈现从单体到去中心化再到集中式资源管理器的工程演进,包含明确的架构约束、安全与性能权衡,以及70%接入成本降低、P90延迟改善等可验证数据。适合平台工程、数据基础设施和SRE团队参考,其资源提供者契约、RBAC、审计与异步工作流设计可迁移到类似控制平面系统,主要风险是LinkedIn内部细节较多,需结合自身规模判断。

工程实践LinkedIn Engineering - Scalability

Pursuit of universal ownership at LinkedIn

文章介绍了 LinkedIn 为应对超大规模基础设施中“谁拥有什么资产”问题而设计的 Crews 所有权模型。作者首先分析了规模庞大、组织演进、人员流动、技术依赖复杂和多组织对齐等挑战,然后提出以稳定的团队 Crew 作为资产所有者的核心思路。该模型要求每个 Crew 有明确的责任经理、团队化所有权和唯一资产归属,并支持资产分组、Conventional/Virtual Crew 以及单树层级来保障升级路径。文中还讨论了推动落地的技术集成、组织对齐、数据质量策略和强制政策,并给出已覆盖 15 万关键资产、减少数万运维工单等效果。该方案更适合大型平台型组织,需要较强领导层推动和持续数据治理。

推荐收录,因为这是一线工程组织在超大规模场景下解决资产所有权问题的完整实践案例,提供了清晰的模型设计、实施约束和量化收益,而非泛泛的管理理念。适合平台工程负责人、基础设施团队和大型组织架构师借鉴;其将资产归属从个人转向稳定团队、用单树层级兜底升级的思路具有可迁移价值,但落地时需结合组织授权和数据治理能力。

工程实践SelectDB 技术分享

秒级弹性、最高降本 70%:SelectDB Serverless 如何重塑云数仓资源效率 阿里云 SelectDB Serverless 可实现资源按需供给与按使用量计费,在负载高峰时补齐资源,...

文章讨论云数仓资源管理中长期存在的矛盾:业务负载波动大,固定规格资源常按峰值锁定,导致平均利用率低;传统存算分离架构弹性慢,扩容伴随缓存预热和数据重分布,容易引发查询延迟抖动。作者提出 SelectDB Serverless 的解决方案,通过计算、缓存、存储三层独立解耦,支持秒级原地纵向伸缩,单集群最高16倍弹性区间,并采用“扩快缩慢”策略——CPU 5秒均值或内存瞬时利用率超过60%触发扩容,CPU与内存同时低于30%且持续1分钟才渐进缩容,同时引入AI辅助决策。文章还给出选型参考:峰谷特征明显、可释放计算资源超过28%时Serverless才具成本优势;纵向弹性有16倍边界,极端场景需横向伸缩约3分钟。内容主要基于产品设计与机制说明,缺少独立用户验证数据。

推荐收录,因为它不只是产品宣传,而是提供了具体的弹性架构设计:三层资源解耦、扩缩容触发阈值、原地纵向伸缩机制和选型成本阈值,对云数仓、Serverless 或弹性架构设计的读者有直接参考价值。可迁移的是“扩快缩慢”的弹性策略和计算/缓存/存储解耦思路;需注意其厂商视角,部分性能数据未经独立验证。

工程实践TiDB 社区博客 - 实践案例

稳住大考阅卷高并发!学科网数据库架构的平滑演进与实践

文章复盘学科网阅卷系统从 MySQL 迁移到 TiDB 的实践,背景是业务具有峰谷特征、单机 MySQL 主备集群出现容量与性能瓶颈,同时研发资源有限无法改造代码。作者详细说明选型 TiDB 的关键理由:高度兼容 MySQL 实现零代码迁移、在线 DDL 不阻塞业务、弹性扩缩容适配流量波动、Raft 多副本保证数据强一致。迁移采用分批策略,优先将大表和主从延迟严重的表迁入,收益包括缓解并发压力、消除切换数据不一致风险、节省磁盘空间并避免分库分表改造。文中还总结了扩容规划、小表热点处理、低峰版本升级和索引优化等运维经验。该方案尤其适合教育行业等需要兼容 MySQL 且短时高并发的场景,但需注意跨 AZ 缩容的数据分布和热点小表的处理。

推荐收录,因为文章提供了真实业务约束下的数据库选型、迁移和运维全过程,包含零代码改造、在线 DDL、强一致、扩容规划、小表热点等具体细节,不是泛泛的技术宣传。适合数据库架构师、SRE 以及教育行业技术负责人参考,其“先兼容迁移、争取时间”的平滑演进思路可迁移到其他受限于 MySQL 单机瓶颈且短期无法大改代码的团队。

工程实践JuiceFS 工程技术

GPFS vs. Alluxio vs. JuiceFS: Architecture and Use Cases Compared

本文系统比较了GPFS、Alluxio和JuiceFS三种存储系统在AI工作负载下的架构与适用场景。作者首先梳理了自动驾驶、LLM训练、多模态、计算平台、量化金融和AI代理等场景的I/O特征与存储挑战。随后深入分析GPFS的元节点和分布式令牌锁机制,说明其强一致性与高性能依赖稳定网络和硬件,运维复杂;JuiceFS采用元数据与数据分离架构,结合对象存储实现弹性和成本优势。性能测试显示GPFS在高并发随机读写和顺序写方面领先,JuiceFS在低深度随机读和写回缓存下有竞争力。对Alluxio与JuiceFS的比较则突出透明缓存层与完整文件系统的定位差异。文章来自JuiceFS官方,存在厂商视角,但提供了具体测试数据和架构权衡,适合存储选型参考。

推荐收录,因为文章详细对比三种主流AI存储系统,包含具体性能测试数据和架构机制解析,而非单纯产品宣传。适合从事AI基础设施、存储选型、分布式系统设计的工程师和架构师参考。可迁移价值在于提供了评估存储系统的维度:I/O模式、一致性、缓存策略、成本与运维;主要风险是厂商立场可能对自家产品有所偏重,阅读时需结合独立评估。

工程实践TiDB 社区博客 - 实践案例

关于TiDB集群(TiKV数据留存)的恢复策略

文章围绕TiDB集群在元数据和管理信息完全丢失、仅保留TiKV数据文件情况下的恢复策略展开。作者以测试环境模拟案件取证场景,先通过TiKV日志提取原集群的Cluster ID,然后销毁原有集群与tiup元数据,重新部署相同版本TiDB集群,并将TiKV数据目录指向物理拷贝路径。随后修改last_tikv.toml中的日志、数据、raft等路径,使用pd-recover工具重置Cluster ID,最后启动集群并验证各组件状态。该方法适用于TiDB v6.1.0环境且TiKV数据完整、PD元数据不可恢复的场景。文章给出了具体命令和配置修改项,但未深入解释pd-recover原理、数据一致性验证细节及操作风险,整体更偏向可复现的操作记录。

推荐收录,因为文章提供了一个具体且可复现的TiDB灾难恢复案例,尤其适合运维人员或数据库管理员在元数据丢失时参考。文中的操作步骤、配置修改和Cluster ID恢复方法具备可迁移性,但需注意版本差异和数据一致性风险,建议结合官方文档使用。

工程实践Grab Tech

Grab Bench: Evaluating AI on Grab-shaped production work

文章介绍 Grab 内部构建的 AI 评估框架 Grab Bench,用于在 Grab 业务形态的生产任务上评估模型能力。作者首先指出公开榜单无法捕捉“看似合理实则错误”的失败模式,如 SQL 指标漂移、工具参数错误、证据引用过度和只通过表面测试的代码补丁。框架通过 YAML 配置、任务插件和行级记录,将 SQL 生成、工具调用、多模态判断、乘客画像推理和编码代理等任务纳入统一评估。设计上强调使用合成或脱敏数据保护生产隐私,采用确定性评分器与 LLM 评判结合,并设置反捷径基线、隐藏测试和认证集防止过拟合。文章最后总结失败分类比总分更重要,并指出合成评估不能直接证明生产收益,需结合线上证据。

推荐收录,因为文章展示了真实工程团队如何构建内部 AI 评估系统,从问题定义、任务契约设计、评分策略到数据安全和可复现性均有具体实现和边界讨论。对需要建立模型上线前评估、避免“看似正确”的失败模式或设计 eval harness 的工程师和团队具有直接参考价值,尤其是确定性评分、反作弊基线和失败分类的思路可迁移到多种 AI 产品场景。

工程实践美团技术团队

Agent评测漫谈 —— 由浅入深讲解Agent评测

文章系统介绍Agent评测的概念、目的与方法论,强调Agent评测是“观测+评测=持续迭代”的工程实践。作者指出Agent评测需覆盖结果、过程、效率、风险四层,并从“答案评测”走向“行为评测”。核心方法论包括:建立从业务指标到模型指标的分层指标桥梁;客观评测与主观评测并行,通过“人人一致、人机一致”和二元化Rubric对齐主观标准;以Bad/Good Case驱动评测体系迭代;专家知识补充垂域能力。文章还分析了长程Agent带来的评测范式变化,从面向Query-Answer转向面向Task-defined behavior,并提出评测基础设施应具备全链路回放、沙箱、AI评测引擎等能力。全文源自美团图灵团队两年实践经验,适用于企业级Agent系统评测体系建设,但对学术评测算法探讨有限。

推荐收录,因为文章不是浅层科普,而是结合多个业务案例深入拆解了Agent评测的工程化方法论,提供了分层指标、人机对齐、二元化Rubric等可直接复用的实践策略,对正在或计划建设Agent评测体系的产研团队有显著参考价值。其“从Bad Case驱动迭代”和长程Agent评测转型的思路尤其适合当前Agent快速发展的工程需求。

工程实践GitHub Engineering

Using the GitHub Copilot SDK for Java

本文介绍 GitHub Copilot SDK for Java,一个不绑定特定框架且支持自带密钥(BYOK)的 Java AI 客户端库。作者以 Jakarta EE 11 房地产线索管理 Agent 为例,详细展示注解式(@CopilotTool)与 Lambda 式工具定义、系统消息定制、Agent 循环(sendAndWait)及事件流处理。重点说明如何通过 Jakarta Concurrency 的 ManagedThreadFactory 创建虚拟线程执行器,确保工具回调携带容器上下文,从而无缝集成 CDI、JPA 和 WebSocket。文章还涵盖生产级关注点,如工具集访问控制与权限策略,但强调当前为预览版,注解 API 需实验性编译标志,且示例中简化了权限校验。整体为 Java 服务端 AI 工程化提供了可复用的集成模式与架构取舍。

推荐收录。本文不是浅层的产品介绍,而是深入展示了 GitHub Copilot SDK 在真实企业 Java 应用中的集成细节,包括工具定义、上下文传播、并发模型与实时事件推送,具有明确的工程参考价值。其模式与约束(如虚拟线程执行器、工具集控制)可直接迁移到其他 Java 服务端 AI 集成场景,尤其适合追求框架中立和供应商中立的开发者。

技术文章知乎 - 苏剑林

简单谈谈K3的MoE和Attention

文章由苏剑林撰写,深入解析了K3模型在MoE和Attention上的设计思路与取舍。在MoE部分,作者提出Stable LatentMoE,通过SiTU‑GLU激活和关键位置的RMS Norm解决LatentMoE的稳定性问题,并引入QB分位数平衡策略,以低通信的分bin方法实现大规模专家负载均衡。在Attention部分,作者论证了在训练成本、KV Cache大小和Decoding计算量的多约束下,MLA仍是对效果与效率平衡良好的选择,结合KDA后更是可以移除RoPE,形成NoPE方案。文章还对比了DSV4的Attention设计,指出其本质是对MLA思想的极致推广而非抛弃。全文以效果、效率与稳定性的协调为主线,提供了多项有实验支撑的架构决策参考。

本文为知名研究者苏剑林对K3模型架构的深度解读,详细阐释了MoE稳定化、负载均衡和Attention选型等关键设计,并给出了明确的动机、实验依据和边界分析。适合大模型架构师、研究人员以及对大规模训练优化感兴趣的工程师,其关于训练稳定性、计算‑存储权衡和混合架构设计的方法论具有很强的可迁移价值。

工程实践知乎 - 腾讯技术工程

10万+Skill 背后:腾讯SkillHub如何帮用户找到真正好用的那20%

文章深度复盘了腾讯SkillHub平台在治理10万+AI Skills时的实践,重点解决高质量Skill发现与分发难题。作者提出TRACE质量评测体系,从可信任度、可靠性、适用性、规范性和有效性五个维度进行静态分析,并构建了并行评测流水线、内存级加载和可追踪任务系统以支撑大规模评估。随后通过云端隔离运行环境验证Skill真实执行效果,并沉淀可展示的效果案例。在分发侧,平台结合评测分数与用户行为设计推荐、飙升、下载等多维榜单,建立受控分类标签体系以降低用户筛选成本。最后,文章展示了面向Agent的find skill策略,让AI能自动理解任务意图并匹配Skill,完成从人到机器的能力索引闭环。整套体系以“信任与分发基础设施”为核心,平衡消费者、创作者与平台利益,但仍在持续迭代,依赖特定Agent生态。

推荐收录,因为它不是泛泛介绍,而是完整复盘了从质量评测、运行验证到分发治理的真实工程链条,包含并行架构、隔离环境、榜单设计等可迁移方法。对从事AI平台、内容治理或Agent系统设计的读者来说,文中TRACE框架、运行环境构建和Agent可用的find skill策略可直接启发类似系统建设,但需注意其生态依赖性。

工程实践Fzakaria Blog

nixpkgs-multiverse: every version that ever existed

文章介绍 nixpkgs-multiverse 项目,通过一个 flake 输入提供 Nixpkgs 所有历史版本的惰性访问,解决多版本依赖时需固定多个 flake 输入的性能和易用性问题。核心方法是用 revisions.json 与 versions.json 索引包版本到修订的映射,并利用 builtins.fetchTree 按需获取;数据编码仅保留每个版本的最新出现修订,将索引大小控制在 5 MB 左右。性能实验表明,相比急切获取多个 flake 输入,该方案解析开销极低且遵循按修订计费原则。项目不构建或镜像任何内容,仅是对已有 Hydra 缓存的映射层,适合需要在 Nix 生态中灵活组合不同版本包的开发或构建环境。

推荐收录,因为它展示了一个真实的工程问题(Nix flake 多版本输入的性能与可用性冲突),并给出了完整的设计方案、数据优化与性能对比,具备可迁移的工程判断和工具设计思路。对使用 Nix、关注包管理与依赖分析的读者有直接参考价值,其惰性索引与按修订计费的设计也可启发其他需要高效版本查询的系统。

工程实践TiDB 社区博客 - 实践案例

openEuler 部署 TiDB:锁索引故障 + Sysbench 实战

文章记录了在 openEuler 22.03 SP4 国产化操作系统上部署 TiDB v8.5 的完整实践过程,包括 TiUP Playground 快速测试和 TiUP Cluster 单机模拟生产两种方案。作者详细列出了与官方 CentOS/RHEL 文档差异导致的典型问题,如 bash_profile 环境变量不生效、Playground 监听 127.0.0.1、openEuler 默认 MaxSessions=10 导致 SSH 并发连接失败、禁止 root 运行 TiDB 进程、防火墙端口放行、随机密码保存等,并给出对应解决命令。随后使用 Sysbench 进行只读和读写混合压测,复现了读写混合场景下的锁等待超时故障,分析了热点索引页、乐观事务冲突等成因,并通过调整隔离级别、增加 TiKV scheduler-concurrency、使用 --skip-trx 等方法缓解。文章适用于国产化环境部署 TiDB 和初步进行基准测试与故障排查的读者,但部分建议需根据实际业务场景谨慎采用。

推荐收录,因为它是真实环境下的部署与压测案例,覆盖了国产操作系统与分布式数据库兼容性问题、SSH 并发限制、权限管理等工程约束,以及基于 Sysbench 的锁等待故障分析。适合需要在 openEuler 等信创系统上部署 TiDB 或学习分布式数据库基准测试和初步排障的工程师,文中命令和排查路径可直接迁移到类似环境。主要风险是部分优化建议如降低隔离级别需结合业务正确性验证,不宜直接照搬生产环境。

技术文章知乎 - 鹅厂架构师

能 1 小时用 AI 做出产品了,能 1 小时让 500 人用上吗?

文章系统探讨了AI大幅降低产品开发门槛后,如何高效将产品分发给用户。作者回顾了App Store和抖音的历史,指出每次创作平权后稀缺性从“创造”转向“发现”,而AI时代的分发将不会是传统的应用商店。通过分析OpenAI两次失败的尝试和当前的技术探索,文章提出未来分发平台将形成“部署即服务”“任务即调用”“内容即发现”的三层结构,每一层都在收各自的“过路费”。文章还指出,监管正从管模型转向管分发,对平台加码,而分发本质是信任问题,最可能从已积累信任的内容社区演化出分发能力。结论为:下一个分发平台不会叫应用商店,但会收取以信任和治理为代价的过路费。

推荐收录,因为文章以历史规律和实际案例(OpenAI的失败)为基础,对AI分发这一新兴议题提供了结构化和有借鉴意义的分析。文中提出的三层结构和对信任机制的强调,能为从事AI产品开发、平台设计和投资决策的读者提供长期参考,其分析框架可迁移到类似技术变革期的分发策略思考。

工程实践QuestDB Engineering

Read Streaming 500 million rows into Apache Arrow in 2.3 seconds

文章测试 QuestDB 新 QWP 协议将查询结果流式传输到 Apache Arrow 的性能,并与 ClickHouse、TimescaleDB 对比。作者用简单查询和并行读取器基准,测量 500M 行数据的导出速度。最初几轮结果受磁盘 I/O、Python GIL 等因素影响,修正后 QuestDB 达到 220M 行/秒,首批数据仅 32ms,比 ClickHouse 最快流式路径快 2.35 倍。文章还分析了每行字节数、存储占用、扩展性和协调成本,并指出测试的局限(单一 schema、低基数字符串等)。该文提供了可复现的测试方法和详实的过程反思。

推荐收录,因为它不是简单的产品宣传,而是深入的工程基准测试,展示了如何识别并消除磁盘、GIL、协调成本等测试伪影,并提供了可复现的仓库和明确的局限声明。适合数据库选型、性能评估或数据管道设计的读者,可迁移价值在于严谨的流式数据导出基准测试方法和工程分析框架。

工程实践Elastic Security Labs

The security signal log tailing can't see: tracking npm cooldown removals with Elastic Agent

本文详细介绍了在 Elastic Agent 上实现 npm min-release-age 设置移除监控的工程方案,用于提升软件供应链安全性。作者首先指出基于追加日志的 filestream 输入无法检测到 .npmrc 文件内容的删除,因此转向基于快照语义的 CEL 输入。文中提供了完整的 CEL 集成脚本和摄取管道,对比了两种方法的差异,并逐步迭代出最终的心跳式快照方案,每 6 小时重新发送文件状态以确保时间窗口看板能反映实况。此外,还讨论了身份验证令牌的代理端过滤、小文件的文件标识策略、nvm 带来的版本计数膨胀等实践细节,并给出了 Linux 和 Windows 的变体设计。该方案适用于安全团队追踪终端上供应链防御设置的采纳与移除情况,但对实时告警场景延迟较高。

推荐收录,因为文章不是简单的工具使用介绍,而是一个完整的工程案例,展示了从问题定义、方案对比、迭代优化到生产部署的全过程。对于负责端点安全监控或供应链防御的工程师,文中提供的 CEL 快照方法、秘密信息过滤技巧以及对文件监控工具选型的分析具有很高的可迁移价值,可直接应用于类似配置文件的监控需求。

技术文章知乎 - 网易易盾

拟人化互动服务安全评估看哪些维度?8项评估内容逐条拆解

文章依据《人工智能拟人化互动服务管理暂行办法》第二十三条,逐项拆解安全评估的8项内容:安全保障措施、训练数据处理、极端情境处置、用户规模结构、特殊群体保护、投诉举报处理、重大风险整改及兜底事项。对每一项说明评估关注点和企业准备要点,并给出制度、技术、运营、证据四层落地清单,将抽象法规转化为可检查、可留痕的具体动作。文章还提出将自查融入部署前、运行中、版本升级、服务终止和重大风险后全生命周期,并解答了自查节奏、风险闭环和协同角色等高频问题。该指南主要适用于在中国提供拟人化AI服务的企业,依赖特定法规,需配合政策更新使用,但方法论可迁移至其他安全合规场景。

推荐收录,因为文章将抽象法规转化为可落地的安全自查清单和四层框架,为拟人化AI服务提供者、安全工程师和合规人员提供了直接可用的操作指南。文中制度+技术+运营+证据的拆解方式和全生命周期自查节奏具有跨项目可迁移性,对安全评估实践有长期参考价值。但需留意该指南基于特定暂行管理办法,长期使用时需结合法规更新。

技术文章OpenTelemetry Blog

Metric cardinality limits in OpenTelemetry: a practical guide

文章详解 OpenTelemetry 指标 SDK 中的基数限制机制,该限制旨在防止进程因接收过多唯一属性组合而导致内存无限增长。作者说明,当指标流的属性基数超出阈值时,总量值保持正确,但按属性过滤或分组查询可能产生低估计数,影响仪表盘、SLO 和告警。文中还介绍了如何检测溢出、配置合理限制以及权衡内存安全与数据准确性的实用建议。该指南面向已经或计划在生产环境中使用 OpenTelemetry 指标的用户,提醒他们注意这一容易被忽略的行为及其对可观测性的潜在影响。

推荐收录,因为它深入解析了 OpenTelemetry SDK 中基数限制的设计原理和实际后果,为可观测性工程师提供了重要的认知模型和操作指导。文章直接揭示了一个可能被忽视的数据偏差问题,对依赖精确指标进行告警和 SLO 计算的团队具有可迁移的参考价值。

工程实践Stanford Hazy Research

Retire the Abstractions

本文以编写 CUDA megakernel 的经验为起点,提出 AI 编程智能体正在取代传统软件抽象层的认知卸载功能。作者回顾了去年依靠 C++ 抽象管理复杂性的痛苦,以及今年借助 agent 直接将不完整的提示转为优化代码的实践,由此预言 CUDA DSL 等抽象层即将退役。文章进一步讨论代码库角色的迁移:精确的代码库变得脆弱,而模糊但可传递的意图提示更适应智能执行器;信任将更多放在规约、测试和不变量等 oracle 上,而非实现细节。同时,作者也指出抽象层作为共享验证面、知识传递手段仍具价值,且专家经验在此转型中不可或缺。全文核心观点是抽象会退役,但领域知识永存。

推荐收录,因为本文不是泛泛而谈的未来预测,而是基于真实 megakernel 工程演进提出的具体论证,提供了从认知外包到代码生命周期重估的完整视角。适合关注 AI 辅助系统编程、DSL 设计与软件工程演化的研究者与工程师,可迁移的思考在于如何重新权衡代码、测试与意图描述在智能工具介入后的角色。

工程实践知乎 - 网易易盾

AI陪伴产品极端情境怎么处置?新规合规要求下的识别、安抚与干预全流程

本文围绕AI陪伴产品在极端情境下的安全处置展开,基于《人工智能拟人化互动服务管理暂行办法》的合规要求,提出从普通陪聊模式切换到安全处置模式的完整流程。核心方法包括四层风险识别机制(关键词、分类模型、大模型语义、上下文分析)及风险等级划分,安抚话术的三条红线(不角色扮演、不强化依赖、不提供危险细节),以及分级干预策略(规范安抚、转人工、应急响应)。文章还详细设计了人工接管流程的六个关键问题(触发条件、等级判断、处理时限、复核机制、结果反馈、样本回流)和记录留存复盘机制,形成闭环处置能力。结论强调用技术识别风险、人工承接高危事件,适用于需要合规的拟人化AI产品,边界在于依赖多模型与人工兜底,且需根据产品形态和风险等级动态调整。

这篇来自网易易盾实操经验的文章,提供了AI陪伴产品在极端情境下的识别、安抚、干预全流程工程方案,紧扣即将施行的监管办法,三条红线、六问人工接管等设计直接可迁移。适合AI产品安全负责人、内容审核团队及合规工程师参考,其分级处置思路和闭环优化方法对构建负责任的安全体系有长期价值。

工程实践知乎 - 网易易盾

AI陪伴的数据安全怎么做?训练数据合法性与用户隐私控制全梳理

文章围绕拟人化AI互动服务的数据安全治理,依据即将施行的《人工智能拟人化互动服务管理暂行办法》,系统梳理了训练数据来源追溯、处理流程证明、用户交互数据隐私保护、用户控制入口设计和存储访问流转安全等关键环节。作者提供了具体的合规操作清单,包括逐类说明数据来源并留存授权文件、清洗与过滤敏感语料、对敏感个人信息取得单独同意、提供会话导出和删除与关闭训练使用等入口,并强调权限分级、加密与审计。通过常见问题回应了开源数据使用、用户聊天记录训练、数据删除机制等典型困惑。文章结论强调数据治理必须实现授权、处理、控制、删除全链路可解释与可留痕,为AI陪伴产品的数据合规提供了清晰的工程实践参考。

推荐收录,因为文章不是泛泛的政策解读,而是给出了从数据来源、处理、用户控制到存储流转的完整操作清单,并直接回应了AI陪伴场景中“用户聊天记录能否训练”、“删除后数据是否真删”等关键问题。对于开发AI拟人化产品的工程团队、安全合规人员和产品经理,文中的授权记录、单独同意、最小化权限等要求可直接迁移到系统和流程设计中,具有长期参考价值。

技术文章知乎 - 网易易盾

AI陪伴产品要做安全评估吗?

本文依据《人工智能拟人化互动服务管理暂行办法》,系统阐述AI陪伴产品是否需要开展安全评估。作者从持续情感互动、角色人设、私密数据沉淀、重点人群和用户规模五类特征出发,给出企业自查清单,并列举AI恋人、虚拟伴侣、AI心理陪伴等适用产品形态。文章明确触发安全评估的量化条件(如注册用户100万或月活10万),澄清智能客服等不适用该办法,纠正“等产品做大再补材料”等常见误区,最后建议将安全评估能力前置到产品规划阶段,建立使用时长提醒、异常依赖识别和未成年人保护等机制。全文为拟人化互动服务的合规实践提供了可操作的框架,但对具体技术实现机制着墨不多。

推荐收录,因为它为AI产品团队提供了一份清晰的监管合规自查指南,将法规要求转化为可执行的设计与运营指标。读者(尤其是AI产品经理、安全工程师和合规人员)可直接借鉴五类特征对照和产品形态清单,在早期设计阶段嵌入必要的安全机制,降低后续监管风险。文章虽偏法规解读,但对AI工程化落地中的安全评估环节具有长期参考价值。

工程实践Fzakaria Blog

Super Mario Derivations

文章探索了利用Nix语言的惰性求值特性,将属性路径转化为Super Mario Bros. 3的按键输入序列。作者通过将每次按键操作定义为独立的派生(derivation),并使每个派生依赖前一帧的快照作为输入,从而实现了游戏状态的懒加载与增量构建。Nix store实际上充当了模拟器快照历史的持久层,分支或追加操作只需计算增量部分。文章还分析了递归深度限制(默认约2400次按键)、内核命令行参数长度限制(21,845次按键)以及构建时间线性增长等实际约束,并提出了通过文件输入绕过限制的方案。该工程案例展示了Nix派生机制在游戏状态机中的创意应用,但主要用于技术演示,性能开销较大。

推荐收录,因为这不是简单的技术玩梗,而是深入展示了Nix惰性求值、派生依赖和内容寻址存储的底层机制。文章提供了细致的基准测试和限制分析,对理解Nix的运行模型和扩展能力很有启发。适合对Nix或函数式构建系统感兴趣的工程师,其将输入序列拆分为可复用的派生单元的思想可迁移到其他需要增量构建或状态机复现的场景。

工程实践知乎 - SmartCode 得物技术

实战从零开始构建一个Coding Agent:Violin |得物技术

文章以从零构建Coding Agent 'Violin' 为主线,系统剖析了Agent的架构设计、核心循环、模型适配、工具系统、会话管理、上下文压缩、资源加载、事件通信和插件扩展等关键组件。作者借鉴Pi的三层分离思想,用Zig实现高性能引擎、Python搭建交互客户端,通过TCP+JSON Lines协议解耦前后端,并详细讨论了Agent Loop'问模型-执行工具'的底层原理及其在各种功能中的扩展方式。文章同时指出了该玩具项目当前的不足(如工具定义未序列化、插件无权限隔离),但强调其核心价值在于验证'理解一个coding agent就能理解所有agent'这一判断。整体展现了深度工程实现、语言选型权衡和可迁移的设计模式,为AI工程化实践提供了扎实的参考。

推荐收录,因为文章不是泛泛介绍AI agent概念,而是深入到代码级实现,包括Zig/Python语言分工、TCP通信协议设计、EventBus事件驱动和Lua插件系统等工程细节,完整呈现了从架构到落地的过程。对正在设计或实现自定义AI agent的工程师、以及对Agent内部机制有深度兴趣的读者来说,文中的分层解耦思想、循环控制模式和资源管理方法具有直接的可迁移价值。

工程实践Meta Engineering

From User Sequences to Scaling Laws: A Multi-Stage Architecture for Meta’s Ads Ranking

本文介绍了 Meta 广告排序系统在大规模序列学习上的两项架构创新:多阶段序列模型将计算密集的离线用户建模与对延迟敏感的在线排序解耦,通过异步处理长用户历史并缓存嵌入,在不线性增加服务资源的前提下提升模型容量;密集 tokenization 和目标感知多头注意力让模型直接从数据中学习稀疏特征与行为序列的交互,取代手动特征工程。该设计带来了可预测的 LLM 式扩展规律,即性能随计算量呈对数线性增长,并总结出模型形状平衡、多阶段可调性、序列组成多样性和语义特征表征四个扩展杠杆。文章给出了在 Instagram 和 Facebook 上的转化率与点击率提升数据,并指出该架构已作为 GEM 模型的核心组件,可泛化至各类广告排序任务。

推荐收录,因为文章不仅公开了关键技术细节(离线/在线解耦、密集 tokenization、目标感知注意力),还系统论证了在广告推荐领域建立起可预测扩展规律的方法与实验证据。对于推荐系统、广告架构及大规模模型服务的工程师和研究者,文中分离建模阶段以平衡复杂度与延迟的思路具有很强的可迁移性,而扩展规律的识别路径可为探索其他大规模机器学习系统提供参考。

个人心得ACM Queue Articles

Where to Draw the Line

文章基于对深度使用AI的团队的观察,提出当模型代写代码成为常态时,软件工程的核心不再是编写代码,而是决定构建什么、判断结果是否满足目标以及在未满足时如何应对。作者描绘了一种新兴的工程纪律,它建立在行为规范、工程化的异见和持续仪表化监督之上,而非代码创作者的权威。文章也直面了一个令人不安的后果:我们正在要求资深判断力,却同时淘汰了产生这种判断力的工作。最后,作者主张存在一类即使机器看似胜任也不应委托给它的判断。

收录理由:本文不是浅层的AI趋势报道,而是对软件工程职业本质的一次深刻反思,提出了可操作的工程纪律框架(行为规范、异见设计、持续监督),为从业者在AI时代重新定位自身角色提供了思想锚点。适合技术领导者、资深工程师及关注工程文化演变的读者反复阅读,其见解具有超越具体工具的长期参考价值。

工程实践Trail of Bits Blog

A few notes on AWS Nitro Enclaves: KMS integration

文章系统分析了AWS Nitro Enclaves与KMS集成时的安全威胁与防护策略。作者从被动攻击和主动攻击两个维度出发,详细梳理了数据交换攻击、CMK替换、重放攻击等具体场景,并给出了包含加密上下文、密钥承诺、CMK硬编码、TLS通道等在内的防护检查清单。此外,文章还讨论了KMS策略配置的常见错误、PCR绑定方法、端到端验证的挑战以及操作层面的风险(如密钥轮换、区域性故障、计费问题)。文末指出AWS官方SDK存在漏洞,并建议替代方案。整体内容根植于真实工程约束,但部分防护依赖于AWS内部实现细节,不完全适用于非AWS环境。

推荐收录,因为文章不是浅层介绍,而是对Nitro Enclaves与KMS结合时的攻击面进行了系统性威胁分类,并提供了可落地的安全检查清单。内容来自专业安全公司,具有较高的工程参考价值,适合从事云安全、机密计算或基础设施安全的工程师阅读。其威胁建模方法和防护清单设计思路可迁移到其他TEE或云服务安全评估中。

工程实践知乎 - 千问云

让 Agent 越用越准、成本越来越低:AgentLoop 的 Agent 经验自进化闭环

本文介绍 AgentLoop 的 Agent 经验自进化闭环,旨在解决生产环境中 Agent 不确定性带来的质量与成本问题。文章从 Agent 执行轨迹入手,提出将高噪音 Trace 清洗为标准化 Trajectory,再从多轨迹中自动挖掘有效路径、失败模式和恢复策略,生成结构化经验。运行时通过 Skill 与 CLI 将相关经验注入 Agent 上下文,缩小无效探索空间,实现从观测、挖掘到召回的自动飞轮。文中给出了运维、工具使用、软件工程等多个 Bench 的质量与 Token 实验数据,并讨论了与 Memory、RAG、微调等技术的差异。该方法不修改模型权重,经验可跨模型与框架复用,适合需要持续提升 Agent 成功率、稳定性和成本效率的企业场景。

推荐收录,因为文章不是泛泛的产品介绍,而是提供了从 Trace 接入、轨迹清洗、经验挖掘到运行时召回的完整工程方案,并附有可复现的 Bench 数据与成本分析。对负责 Agent 生产化、稳定性建设和成本优化的团队而言,文中的架构设计、经验注入策略和效果评估方法具有直接参考价值,可迁移至其它 Agent 系统的持续优化中。

工程实践GitHub Engineering

Turn one giant AI-generated pull request to a reviewable stack

文章针对AI生成代码导致大规模Pull Request难以审查的问题,提出使用堆叠式Pull Request(Stacked PRs)将特性分解为逻辑分层、独立可审查的多个小PR。通过一个购物助手添加产品搜索的完整案例,展示了如何从数据模型、API、对话接驳到UI层逐步构建堆栈,并利用`gh stack`等GitHub原生工具实现分支管理、审查和修复。文章强调了自底向上审查、上下文传递和自动同步的优势,也指出了Web端rebase会重置提交者等实践边界,为接受AI代理产出的开发团队提供了可操作的工程化流程。

推荐收录,因为它直面AI辅助开发时代代码审查的新痛点,提供了具体且可复现的工程解决方案,而非空谈原则。案例细节丰富,包含分支结构、代理分工、审查顺序和错误处理,对正在引入AI编码代理的团队有直接的迁移价值,长期参考意义明确。

工程实践知乎 - 鹅厂架构师

从0到1搭建 AI Agent 可操作的团队知识管理体系

文章记录了腾讯云团队从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工具,治理机制部分仍有待完善。

工程实践知乎 - 千问云

从 Prompt 到 Harness:企业级 Agent 工程的完整演进之路

本文系统复盘了企业级 AI Agent 平台从 Prompt 工程、Context 工程到 Harness 工程的完整技术演进路径。作者从大模型的上下文窗口稀缺、注意力稀释、数据搬运谬误和无状态缺陷四大先天约束出发,阐述了为何需要工程化基础设施。文章重点介绍了四层上下文防线(工具结果压缩、语义压缩、对话压缩、数据总线)与三层记忆(State、Working Memory、Transcript)的组合设计,以及基于 PERO 编排、断点续传、知识体系、自进化引擎和 Capability Runtime 的 Agent 运行时架构。最终提出五层 Agent OS 架构和双 Agent 平台方案,强调从防御到赋能的设计哲学转变。内容覆盖了真实工程约束、架构权衡与失败教训,适合关注大规模 Agent 系统工程化的团队参考,但对具体实现细节的验证边界和性能量化指标披露有限。

推荐收录,因为这篇长文提供了从第一性原理出发的工程演进实录,非单纯概念介绍。文中关于上下文管理分层防御、有状态执行引擎、跨 Agent 协调及知识体系的设计决策,直接源于生产环境踩坑,可迁移性强。适合后端架构师、AI 平台工程师及技术管理者系统理解 Agent 运行时治理方案,尤其对面临长链路推理质量退化和上下文膨胀的团队具有高参考价值。

工程实践Elastic Security Labs

Agents vs. agents: how we triage HackerOne reports for $2 each, 85% as well as a human

本文详细介绍了Elastic Security Labs如何构建一套AI驱动的漏洞报告分类系统,以应对因LLM生成报告激增而导致的Bug Bounty人力瓶颈。系统采用两阶段架构:分析阶段运行在临时VM上,通过八步流水线和对抗性审查对报告进行有效性、可利用性、CVSS评分等评估;复现阶段仅在必要时启动,在沙盒环境中自动化验证漏洞。系统基于3300+历史报告迭代校准,与人工分类一致率达85%,单次分类成本约2美元。文章还深入讨论了对抗性审查、针对Elastic产品的特定分类规则、完整的安全威胁模型与纵深防御设计,以及从工程实践中获得的经验教训,如报告框架偏见、数据校准关键性和复现的决策价值。

推荐收录,因为它提供了一个从问题定义、架构设计、校准迭代到生产部署的完整工程案例,包含详尽的技术细节、安全防御策略和可复现的实验数据。适合安全工程师、漏洞管理负责人和AI工程化团队参考,其多阶段分析流程、对抗性审查机制和沙盒复现的隔离架构可在其他自动化分类或安全评审场景中迁移复用。

工程实践GitHub Engineering

Don’t stop early: Case-folding source code at memory speed

文章介绍了 GitHub 代码搜索引擎中实现高速 Unicode 大小写折叠(case‑folding)的技术方案。核心优化是在 ASCII 路径中去除提前退出分支,采用无分支循环配合自动向量化,使纯 ASCII 折叠速度超过 45 GiB/s。对于 Unicode,设计了一种仅 1776 字节的紧凑查找表,结合页位图、区间编码与字节级差值运算,避免码点解码而直接在字节空间完成折叠,将非 ASCII 路径开销降到最低。该方案在常见输入上显著超越其他实现,且已开源为 Rust crate casefold。文章还详细讨论了分支消除、向量化、内存带宽等权衡,以及该方法依赖小端字节序和合法 UTF‑8 的边界条件。

推荐收录,因为文章深入剖析了大规模文本处理中的极致性能优化方法,从分支消除、向量化到创新的字节空间 Unicode 折叠,展示了完整的工程决策过程和量化对比。对于从事搜索、编译、系统编程或性能优化的读者,文中的无分支循环设计、紧凑查找表结构和“一次扫描检测+转换”等技巧具有直接的可迁移价值,是真实的工程案例而非泛泛调参记录。

工程实践Netflix TechBlog

GenRec: Towards LLM-Native Recommendation at Netflix

文章介绍了 Netflix 的 GenRec,一个基于内部基础 LLM 并经过后训练的推荐排序模型。它将用户历史、物品元数据和上下文通过“上下文工程”转化为自然语言提示,添加目录感知的评分头,并采用奖励加权的多目标损失(排序、语言建模、与长期满意度对齐)进行训练。在离线评估和大规模在线 A/B 测试中,GenRec 在仅使用少量 Phase-2 标注数据和输入信号的情况下,超越了成熟的生产级排序器,并在短期和长期指标上取得统计显著提升。该工作展示了从特征工程到上下文工程、从定制架构到共享基础骨架的范式转变,以及通过预填充推理和上下文压缩控制服务成本的方法。文章还讨论了数据与模型缩放规律、各训练阶段的贡献以及上下文长度优化,为大规模个性化推荐系统提供了可迁移的设计思路和工程权衡。

强烈推荐收录,因为本文提供了真实生产环境中将 LLM 应用于推荐排序的端到端工程案例,覆盖架构设计、训练策略、成本优化和实验验证,并揭示了从特征工程到上下文工程的范式转变。适合推荐系统工程师、ML 架构师和关注 LLM 工程化的读者,文中关于数据效率、缩放定律和上下文压缩的实践经验具有高迁移价值。

工程实践Crunchy Data Blog

Hybrid Search Patterns with Postgres and pgvector

文章系统探讨了在PostgreSQL和pgvector中实现混合搜索(向量相似度加标量过滤)的工程模式。首先阐述了pgvector迭代索引扫描如何平衡召回与性能,然后分析了向量优先和标量优先两条路径各自的适用场景与局限。作者进一步提供了三种实用工作区:为低基数过滤构建部分HNSW索引;通过过采样再过滤应对高基数或临时过滤器;以及利用缓存加速重复查询。文中给出了过采样的估算公式、查询计划诊断方法以及各方案的决策指南,并强调了每种模式在召回率、性能和维护成本之间的权衡。

推荐收录,因为本文是针对Postgres+pgvector混合搜索问题的实战指南,从问题根源到四种解决方案给出了完整的权衡分析、代码示例和调优公式,远超简单教程。适合正在构建带标量过滤的向量搜索系统的工程师,文中部分索引、过采样和缓存等模式可直接应用于生产环境,决策树和EXPLAIN诊断方法具有跨场景的可迁移价值。

工程实践Blender Developers Blog

Geometry Nodes Physics

本文介绍了Blender 5.2 LTS中基于几何节点(Geometry Nodes)的新头发与布料动力学系统。核心实现采用声明式XPBD仿真框架,通过内置XPBD求解器节点处理多种约束类型,并提供Cloth Dynamics和Hair Dynamics两种易用资产。系统允许通过效应器(Effector)扩展行为,包括碰撞体、自定义力和自定义效应器,并支持标签过滤机制。文章还回顾了当前状态、实验性限制,并展望了未来支持刚体、软体和流体的多求解器统一框架,以及模态节点工具在交互式编辑中的应用。新系统目前仍为实验性,设计可能调整,且缺少现成的力场资产,需要用户自定义。

推荐收录,因为文章详细解析了Blender新一代基于节点的物理模拟架构,从整体框架到XPBD求解器、效应器扩展和求解器统一设计,展示了图形学工程实践中系统设计与可扩展性的权衡。对计算机图形学工程师、动画工具开发者及关注实时模拟的读者,本文提供了可迁移的架构思路和实现细节,尤其适合理解如何将物理仿真集成到节点式工作流中。

工程实践Trail of Bits Blog

Building secure Uniswap v4 hooks

文章聚焦Uniswap v4 hooks的安全开发,强调其灵活性将部分安全责任转移至应用代码。作者基于Trail of Bits的审计实践及Cork、Bunni等真实攻击案例(损失超2000万美元),提炼出七种重复出现的失败模式:包括未校验调用者、信任任意池、自定义会计泄漏价值、钩子逻辑错放、地址位权限不匹配、非必要代码阻塞核心操作以及回调间状态变更。文章先阐述PoolManager的协议保证与结算机制,明确安全边界,然后逐条分析每种模式的成因、风险与修复方案,并提供面向开发者的八项安全检查清单和面向审计者的七个审查问题。内容面向构建安全DeFi应用的开发者与审计者,具有长期参考价值,但需注意其建议主要针对Uniswap v4生态,部分安全模式可能随协议升级而演进。

本文基于真实安全事件与审计经验,系统梳理了Uniswap v4钩子开发中的七类典型安全缺陷,并给出可操作的预防清单,直接证据清晰。适合所有在v4生态上构建或审计智能合约的工程师和安全研究员,其防御模式可迁移至其他DeFi协议或智能合约设计。帮助读者从已知陷阱中学习,避免重复高额损失。

工程实践Fzakaria Blog

Guix by Nix

文章展示了“Guix by Nix”项目,通过 guix-transfer 工具将 Guix 的软件包派生图翻译为 Nix 派生,并利用 Nix 守护进程构建了一个可启动的虚拟机镜像。该镜像以 Guix 的 Linux-libre 为内核,用户空间全部来自翻译后的 Guix 软件包,并以 GNU Shepherd 作为 init 系统,完全排除了 systemd 和 D-Bus。作者提供了自动化审计机制,验证所有可执行文件和脚本解释器均源自 Guix 输出,确保无 Nixpkgs 组件混入。文章还讨论了与 Nixpkgs 混合、构建非 systemd 系统等潜在拓展,但明确当前仅为最小演示,不适合生产环境。该案例对理解构建系统互操作、可重现系统构建和 init 系统替换具有参考价值。

推荐收录,因为它不是简单的工具使用,而是展示了将 Guix 生态翻译到 Nix 构建系统的完整工程方案,并附带了可验证的审计链。这对研究构建系统、操作系统定制或探索 Nix 作为通用构建语言的读者有直接启发,文中跨生态翻译、派生图转换和自证明验证方法均可迁移到类似项目。

工程实践知乎 - SmartCode 得物技术

AI Native 交易核心系统的研发范式|得物技术

文章分享了得物技术团队在订单系统完成稳定性改造后,面对AI编码带来的代码量激增与质量挑战,如何重构研发流水线以适配AI Native范式。核心思路是将传统流程升级为五道标准化关口:需求澄清阶段通过BDD场景与知识库对齐,锁定业务验收标准;技术方案阶段以五段式模块拆解将设计决策前置,并拉取历史约束规约;编码执行阶段引入TDD的RED-GREEN循环,保证代码可测试、可追溯;门禁卡控阶段由多个审查Agent并行审核,确保阶段产物合规;全流程埋点监控则量化研发过程,驱动持续改进。文章以出海礼品卡需求为例贯穿全文,展示了从需求到代码的完整证据链,为交易核心系统在AI辅助下的稳定性治理提供了可落地的工程实践。

本文系统性地记录了AI编码引入核心系统后的稳定性治理实践,将BDD、TDD、知识库校验与门禁流水线相结合,形成从需求到验证的闭环。其五道关口设计、增量代码体检和全链路埋点等方法,对面临AI辅助开发挑战的高可靠性系统团队具有直接参考价值,可迁移到类似交易、金融等核心链路的研发流程优化中。

工程实践知乎 - 鹅厂架构师

内核全栈诊断工具:一体化解锁稳定性与性能

文章介绍了 TencentOS 内核全栈诊断工具的设计理念、功能组成和定制方法。工具覆盖 fs/io、网络、内存、KVM 等领域,沉淀了超过 20 个子工具,已在线上部署并解决上百例稳定性与性能问题。核心能力包括函数级时延分析(支持 running 时延、block 时延以及多函数横向时延追踪)、稳定性问题检查(如页缓存扫描、内存踩踏、挂载数量检测等),以及通过修改 scene_template.c 模板快速定制诊断逻辑的机制。文章详细说明了积木式组合和槽位填空式架构,使已有工具可自由组装,也允许在预留槽位中插入新函数,极大降低了定制门槛。文中给出具体代码示例和命令行接口,展示了从定位时延瓶颈到沉淀子工具的完整工程实践路径。该工具依赖 TencentOS 内核特性,需安装专用 rpm 包和内核开发包,定制需具备内核代码理解能力。

推荐收录,因为文章不是简单的工具使用手册,而是系统阐述了内核诊断工具的整体设计思路、定制框架和工程落地经验,并提供真实代码与线上案例。对内核开发者、SRE 及从事操作系统性能与稳定性优化的工程师具有直接参考价值,其积木式、槽位式的可扩展架构设计可迁移至其他内核可观测性系统的建设中。

技术文章Kubernetes Blog

How the controller-runtime Cache Actually Works, and Why Your Controller Does Not Crash the API Server

本文深入剖析了 controller-runtime 缓存的内部机制,解释了为何控制器不会压垮 API 服务器。核心原理是:r.Get 和 r.List 并非直接查询 API 服务器,而是读取由 Reflector 通过 list+watch 构建、存储于 Indexer 的本地内存副本;写操作则直接发往 API 服务器,并通过 watch 异步反馈到缓存。文章详细拆解了 DeltaFIFO 的有序分组与去重、workqueue 的 key 级合并、索引器如何提供类 SQL 的快速查询、选择性缓存及 Transform 等内存优化策略,并列举了读后写期待、共享对象突变、resync 误解等常见误区。全文基于 client-go 原语,提供了从启动阶段到生产调优的完整心智模型,适用于已经编写 Go 控制器但希望深入理解其行为以避免生产意外的工程师。

推荐收录。文章深入揭示了 controller-runtime 缓存的底层模型和常见误区,为 Kubernetes 控制器开发者提供了可迁移的内部视角和防错指南。内容覆盖了从原理、设计取舍到实战优化的完整链路,长期计算参考价值显著,尤其适合需要在高负载集群下保障控制器稳定性和性能的工程团队。

工程实践GitHub Engineering

Tame Dependabot: Group your updates, slow the cadence, keep security fast

文章以 Microsoft 的 GCToolkit 项目为例,分析 Dependabot 每日单独提 PR 导致的维护噪音问题,并给出三处关键配置修改:使用 groups 通配符将所有更新合并为一个 PR,将调度间隔从 daily 改为 monthly,以及为每个实际使用的生态添加独立更新条目。作者进一步解释了 Dependabot 安全更新不受版本更新调度影响、默认三天的冷却期可防御供应链攻击等机制,以及 monorepo 场景下按目录分组的选项。文中还给出了从通用配置到精细拆分、冷却期调节及不同项目类型间隔选择的实践建议,强调了在降低噪音的同时不延误紧急安全修复的核心理念。

本文基于真实开源项目的维护经验,将 ‘Dependabot 噪音’ 这一普遍问题转化为具体、可复制的配置模式,且对安全更新的安全边际说明清晰,消除了 ‘减速即风险’ 的常见顾虑。适合所有使用 Dependabot 的仓库维护者,文中的分组、减速、冷却期组合方案可直接迁移,对提升依赖管理效率和安全性有长期参考价值。

工程实践Cloudflare Blog

Post-quantum authentication to origins is now supported

本文详细记录了 Cloudflare 为源站连接部署后量子认证的工程实践。文章首先说明后量子认证的必要性和源站连接的独特需求,然后介绍如何在 Custom Origin Trust Store 和 Authenticated Origin Pulls 中配置 ML-DSA 证书,并强调避免降级攻击的关键步骤。接着深入控制面和数据面的实现细节:控制面服务用 Go 编写,通过 Cloudflare 的 CIRCL 库补丁来解析 ML-DSA 证书;数据面服务 Pingora Origin 在停滞四年后更新 BoringSSL,但因 KeyUsage 检查导致了一次线上事故,回滚后修复。最后简述了后量子迁移的整体路线图和生态系统进展。该案例展示了真实系统中的升级权衡、库依赖管理和事故响应,对计划向 PQC 迁移的团队具有直接的参考价值。

这是一份高价值的工程案例,全面覆盖了后量子认证从需求分析、配置实践到底层实现和事故复盘的全过程。对于负责基础设施安全、TLS 运维或正在规划后量子迁移的工程师,文中的配置步骤、降级防护策略、库升级经验以及事故处理细节均可直接迁移。它不局限于产品公告,而是提供了可复用的工程判断和操作指南,适合长期参考。

工程实践知乎 - 千问云

从超级个体到超级组织:1688 数据中心 Multi-Agent 研发小队实录

文章分享了1688数据中心在数据研发领域构建Multi-Agent系统的完整实践。核心通过知识工程KST三层架构(领域知识、行为规范、工作流配置)解决语义资产沉淀与Agent行为可预期性问题,并借助Harness Engineering为NL2SQL流水线增加工程约束,配合Loop Engineering实现全自动冒烟测评驱动的知识回流与飞轮迭代。在宙斯AperCoop平台之上,通过可fork的研发小队市场模式降低Multi-Agent冷启动成本,使个体经验沉淀为组织能力。文中展示了实际需求交付案例、安全网设计及度量数据,也坦诚讨论了知识冷启动最后一公里、AI能力悬崖等未解挑战。该实践虽聚焦数据研发,但其知识分治、约束编码、闭环自治的方法论对AI工程化、Agent协作等领域具有可迁移的长期参考价值。

本文并非泛泛介绍Agent概念,而是提供了从超级个体到超级组织的工程化落地实录,详细拆解了知识工程分治、Harness约束编码、Loop闭环测评等可复用方案,并附有真实数据与反思,对正在探索Multi-Agent生产化、数据平台智能化或AI工程化的团队极具启发性。其KST体系与Harness分离的设计原则,以及通过平台化实现经验回流的思路,可直接迁移至其他领域的AI协作系统建设。

工程实践知乎 - 千问云

数据研发Multi-Agent架构的Harness工程实践

本文从数据研发场景出发,指出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系统。

工程实践Simon Willison

An Inside Look at the Relay Market Powering Token Resellers and Fraud

文章深入调查了一个围绕低价转售 LLM token 的市场生态,主要通过中国活跃的代理和开源工具 one-api/new-api 实现。该市场利用免费试用、未受保护的支持机器人接口、盗用信用卡或退款攻击等方式积聚 API 密钥,再以折扣价格转售给寻求低成本 token、绕过地域限制或收集数据用于模型蒸馏的用户。作者同时指出,这种生态导致开发者面临未受保护端点被滥用的风险,并呼吁 LLM 厂商提供更严格的 API 消费上限。文章基于 Matt Lenhard 的调查和中文论坛线索,提供了具体的开源工具和操作细节,展现了完整的滥用链条和对抗措施。

推荐收录,因为它不是简单新闻,而是对 LLM token 黑市的系统性剖析,揭示了工程安全与 API 设计的现实威胁,并提供了可操作的开源工具背景。适合关注 AI 工程化、API 安全、成本控制以及反滥用架构的开发者阅读,其中的威胁模型和开源代理设计思路对构建安全网关或审计 API 使用具有参考价值。

工程实践LWN.net

De Vlieger: The Fedora 45 sausage factory

本文是 Fedora 贡献者 Simon de Vlieger 对 Fedora 45 发行版构建过程的详细走查。从打包者提交 git 推送开始,文章逐步剖析了源代码与软件包如何被转化为最终发布产物,包括 ISO、云镜像、容器镜像和 OSTree 部署。作者解释了编译、打包、组合等阶段所使用的工具链与基础设施,并说明该流程会随版本迭代不断变化,本文意在为每个或每几个发布周期提供一份可追溯的历史记录。该走查为理解 Fedora 的发布工程提供了内部视角,但其具体实现绑定于 Fedora 45 和时间点,不一定适用于其他发行版或未来版本。

推荐收录,因为它提供了大型 Linux 发行版发布工程的稀缺内部视角,详细展示了从代码提交到最终制品的实际流水线,对负责构建系统、CI/CD 或发行版维护的工程师具有可迁移的参考价值。适合对开源基础设施和发布管理感兴趣的读者。

技术文章OpenTelemetry Blog

Lambda-powered functions land in OTTL

文章介绍了 OpenTelemetry Collector Contrib v0.157.0 为 OTTL(OpenTelemetry 转换语言)引入的 lambda 表达式能力。此前,处理集合操作需要为每个用例硬编码专用函数,而 lambda 让用户能够将内联逻辑传入通用高阶函数,从而以更可复用且简洁的方式实现复杂的数据转换。文中列出了随版本发布的八个新函数:Filter、MapEach、MapKeys、Any、All、Find、Reduce 和 When。这一增强标志着 OTTL 向函数式范式的转变,有助于简化遥测管道的配置与维护,但文章未详细讨论 lambda 在此场景下的性能开销或适用边界。

文章介绍了一项 OTTL 语言级别的重大增强,通过 lambda 和高阶函数提供了更通用的集合转换能力,对构建和维护复杂遥测管道的工程师具有直接参考价值。其所展示的函数式抽象思路可迁移至其他管道工具或 DSL 设计,适合可观测性实践者和平台工程师阅读,但读者需注意文中可能未涉及生产环境下的性能影响等边界讨论。

工程实践Blender Developers Blog

Remote Asset Libraries

文章详细介绍了 Blender 5.2 LTS 引入的远程资产库系统,它允许 Blender 从远程服务器发现并下载资产,同时保持完整的离线使用能力。系统采用静态 HTTP 服务器和 JSON 列表文件的设计,无需动态后端,降低了部署和维护成本;资产必须自包含在单个 .blend 文件中,且不支持外部依赖。作者还讨论了版本兼容性处理、未来对多文件资产与授权钩子的改进方向,以及该方案适用于小团队和个体的边界。全文展示了从需求到架构取舍、实现细节和局限性的完整工程思路。

该文来自 Blender 官方开发者博客,系统阐述了远程资产库的架构设计、限制与未来规划,不是简单的功能介绍。其“离线优先、无动态服务器”的设计哲学对开源图形工具的资源管理有很高参考价值,适合 Blender 用户、工具开发者以及关注资产管线工程化的读者,可以迁移到类似的静态资源分发场景中。

工程实践知乎 - PENG Bo

分享RWKV-7迄今的训练记录,从1B到13B

文章记录了RWKV-7系列六个dense模型(0.1B到13B)的训练过程,展示了所有模型的Loss曲线,强调训练稳定无spike,且曲线中的阶梯变化均源于有原因的操作。作者指出数据量从3T tokens增长到21T tokens,依赖开源数据、蒸馏和合成。训练由单人完成,体现了“One Person Train”模式。文中对比了不同规模模型的训练方法:1B和3B采用常规策略,而7B和13B采用了更高效的方法,收敛速度和数据效率显著更高,当前在各基准上已表现出竞争力。作者还认为数据效率仍有优化空间,提出即使现有架构,若使用最优策略,训练几T tokens即可达到充分效果,并展望了AI自动化训练的未来。文章以实际工程经验为主,提供了大模型训练中数据工程、训练策略选择和效率优化的直观案例。

文章提供了大规模语言模型训练的第一手工程记录,包含训练稳定性、数据规模扩展、不同训练策略的收敛效率对比,以及单人训练模式的可行性验证,对从事大模型训练的工程师和独立研究者具有直接参考价值。读者可从中获得关于训练效率优化、低成本训练路径和训练过程管理的启发,适合关注AI基础设施和训练实践的开发者。虽然细节有限,但经验和观点可迁移至类似项目。

工程实践知乎 - 千问云

Code is cheap. Don't write any.——AI Native,程序员如何提升五倍coding效率

文章提出了一套名为 Harness 的 AI Native 编程方法论,核心是“人定方向,模型推进”。作者从大模型的两个底层事实(概率生成器与上下文宝贵)出发,发展出水流理论(协作姿态:定边界、设 checkpoint、走安全通道)和最小混沌单元(任务粒度:小到可检查、大到可自治),并以 spec、codemap、new-chat 作为上下文管理三件套。通过两个真实案例(0→1 新项目与 1→N 存量治理)详细演示了起手、落 spec、do it、checkpoint、转向和五层 safety net 验收的全流程。最终观点为代码廉价化导致工程师价值结构上移,从写代码迁移到设定目标、切分任务、审阅证据和风险控制,并给出了可操作的团队模板与卡片。适用边界在于低风险、可灰度回滚的项目;高风险核心系统仍需更多人工介入。

推荐收录。文章并非简单的工具教程,而是基于作者大量真实实践的系统性方法论,清晰拆解了让 AI 自主推进编程任务的控制点与验收体系。案例详实、可迁移性强,对试图将 AI 深度集成到研发流程的工程师和团队管理者有直接参考价值。文中的水流理论、最小混沌单元、多层 safety net 等概念提供了可复用的工程思维,风险在于方法依赖特定工具链,但核心协作模式易于在其他工具上落地。

工程实践Dropbox Tech

How our universal content processing platform Riviera evolved for AI and beyond

文章回顾了 Dropbox 内部内容处理平台 Riviera 近十年的演进历程。平台最初为解决多文件格式预览需求而设计,关键思路是将每项任务拆解为可复用的转换片段(如 PowerPoint→PDF→图像),从而避免为每个产品单独构建管道。架构上采用中心调度器与插件化后端 worker 分离的模式,中心负责请求验证、缓存与编排,worker 按转换类型独立扩展,现已支持 300+ 文件格式与 100 多种转换能力,每秒处理数十万请求。随着产品线扩展,Riviera 被搜索、视频审阅、电子签名及 AI 产品 Dash 等团队复用,为 AI 模型统一提供文档提取与格式转换。文章最后说明了平台向外部开发者开放 API 和 MCP 工具的策略,体现了“一次构建、多方受益”的平台工程价值。文章侧重于架构决策与规模效益,未深入具体实现细节或失败案例。

推荐收录。文章提供了真实的大型内容处理平台从单点服务到多产品基座的演进案例,清晰展示了复用、分离关注点和插件化架构如何支撑规模增长与业务扩展。适合平台工程、基础设施设计以及需为 AI 准备非结构化数据的工程师参考,其架构思维和平台化策略具有直接迁移价值。不足之处在于缺少性能瓶颈、失败处理或维护成本的讨论,但整体工程经验仍具有长期参考意义。

工程实践Alex Chan

Fixing a bug with byte order marks

作者在整理本地媒体库字幕并统一为WebVTT格式时,遇到UTF-8字节顺序标记(BOM)导致SRT转换异常的bug。文章先解释BOM的原理及其在UTF-8编码中的具体字节序列,然后展示BOM与序列号混合导致解析失败的现象。修复方案从最初手动检测和移除,优化为利用Python的encoding="utf-8-sig"自动跳过BOM,使转换代码回归纯净。对于已经生成的错误文件,作者使用ripgrep结合字节模式(?-u:\xEF\xBB\xBF)搜索文件中的BOM,并通过脚本批量清理,最后用ripgrep和Git仓库双重验证修复结果。整个过程串联了字符编码知识、工具选择和验证手段,是典型的文本处理工程调试案例。

推荐收录,因为该案例通过一个真实的文本编码陷阱,展示了从原理理解到优雅修复的完整路径。文中提供的utf-8-sig编码技巧和ripgrep字节搜索模式可直接迁移到其他处理多编码文件的场景,尤其适合需要处理外部数据来源的开发者。同时,它强调了理解底层细节对快速定位问题的重要性,对提升工程调试能力有实际参考价值。

工程实践LWN.net

Building an Arch Linux aarch64 port for Holo Core (Collabora blog)

本文概述了 Collabora 与 Valve 合作将 Arch Linux 移植到 aarch64 架构的工作,目标是为 Valve 的 64 位 Arm 蒸汽框架游戏系统提供操作系统。核心内容包括从零开始构建可重复的编译基础设施,生成源码、二进制包和容器镜像,并规划了能持续跟踪上游 Arch Linux 开发的 CI 系统。文章还讨论了移植过程中的挑战,如从第一性原理构建至特定快照,以及如何在此基础上实现自动化可重复构建。此外,提供了在 x86_64 主机上创建和测试 aarch64 构建容器的指导,以便没有 64 位 Arm 设备的用户参与。该工作尚在初期阶段,下一步是与上游合作完善移植并建立持续集成,其经验适用于操作系统移植和嵌入式构建场景。

推荐收录,因为文章记录了将 Arch Linux 移植到 aarch64 架构的真实工程过程,包括从零构建基础设施、实现可重复自动化构建,以及规划持续集成系统,这些经验对操作系统移植、构建系统和 CI/CD 的实践者具有直接的参考价值。同时,文中提供的跨架构测试方法也可迁移到其他类似项目。

个人心得GitHub Engineering

The cost of saying yes has changed

文章反思了AI时代小型需求决策的成本变化:过去编写初始代码是昂贵步骤,现在最耗时的往往变成了需求讨论会议。作者提出,对于边界明确、不改变产品契约的轻量变更,与其在争论中消耗数天,不如用AI快速生成一个补丁作为‘探针’,将范围讨论从抽象猜测转为对具体diff的审查。文章重点区分了‘生成廉价’和‘拥有廉价’:代码生成成本降低,但人类审核与长期维护成本并未减少,因此仅当变更可被自信地审查和认领时才真正便宜。最终建议工程师应将部分范围控制从实施前移至代码审查阶段,用低成本尝试替代无休止的辩论,并培养快速定价不确定性的能力。

推荐收录,因为文章提供了AI辅助开发时代务实且可迁移的工程决策框架。它没有停留在口号层面,而是通过具体场景对比(如last_active_at字段)说明了‘尝试即探测’的策略,并明确指出了所有权成本这一关键陷阱。适合正在引入AI协作的工程团队和个人阅读,其关于‘将范围控制移至审查阶段’和‘以证据代替直觉争论’的方法可直接应用于日常开发流程。

工程实践知乎 - 腾讯技术工程

驾驭AI Coding:一份面向团队的 Harness Engineering 落地规范

本文系统介绍了 Harness Engineering 理念及其在团队 AI 编码中的落地规范。文章从 Harness 的 6 大支柱(上下文管理、工具系统、执行编排、状态记忆、评估观测、约束恢复)出发,将其映射为 CodeBuddy 工具链的具体实践,并提出了包含 Rules、Skills、MCP、知识库、Spec 驱动开发在内的完整规范体系。作者给出了三阶段实施路线图、详细配置步骤、日常开发 SOP、反模式总结,以及基于自研 Skill 的自动化合规审计方法。核心结论是:通过将“好代码”标准写入系统,让 AI 在约束下自主工作,实现从“人驱动 AI”到“AI 自驱动”的转变。文章适用于已有一定工程基础的团队,但部分工具生态可能依赖特定平台,方法论本身可迁移。

本文提供了可落地的 AI 辅助开发团队规范,不再停留于工具功能介绍,而是系统整合约束、流程、工具链和审计,形成一套完整方法论。适合希望规范化 AI 编码实践的工程团队,其分阶段路线图、反模式清单和自动化检查模式可直接迁移到不同技术栈和工具生态,具备长期参考价值。

技术文章知乎 - 网易易盾

Agent行为安全怎么管?大模型从说话到做事的安全边界

文章聚焦大模型应用从对话式向执行式转型带来的 Agent 行为安全新挑战,系统对比了内容安全与 Agent 安全的本质差异,将风险归纳为越权操作、远程操控与间接攻击、自动化规模攻击三类,并提出行为围栏、权限管控、监控熔断三层防护体系。行为围栏涵盖意图识别、行为分级和操作序列审计;权限管控基于最小权限原则实行数据分级访问、API 白名单和上下文感知权限;监控熔断则通过频率检测、路径异常检测和熔断机制兜底。文章还给出了从行为围栏切入、逐步完善权限与监控的建设路径,并回答了常见治理问题,整体侧重框架性方法论,未深入代码或具体实现细节。

文章为 Agent 安全这一新兴领域提供了清晰的风险分类和防护框架,三层围栏模型可直接迁移到实际系统设计中,适合安全工程师、架构师作为入门参考。内容虽有产品推广语境,但核心方法论具备通用性,对构建大模型应用安全防线有启发价值。

工程实践Julia Evans

Learning a few things about running SQLite

Julia Evans 分享了她近期在 Django 网站中使用 SQLite 时积累的几个运维经验。她首先发现对 4000 行的表使用 FTS5 全文搜索耗时 5 秒,运行 ANALYZE 后降至毫秒级,推测是查询计划不佳所致。清理大量行时,删除操作超过 5 秒会导致其他工作线程写入超时崩溃,她通过小批量处理来规避。备份方面,最初使用 sqlite3 VACUUM INTO 加上 restic 上传到 S3,但偶尔 OOM 并产生锁问题;近期改用 Litestream 进行增量备份。她还提到拆分多个数据库文件有助于管理。文章基于个人小型项目,作者坦言若需要多写入支持可能得迁移到 PostgreSQL。

本文来自真实工程实践,详细记录了 ANALYZE 优化查询、批量清理避免写入冲突以及两种备份方案的具体步骤,对使用 SQLite 搭建个人或小型 Web 应用的开发者有直接参考价值。虽然深度有限,但作者的反思和解决方案具有可迁移性,适合作为入门级运维经验收录。

技术文章Crunchy Data Blog

Postgres 19 Compression: from pglz to LZ4

Postgres 19计划将默认TOAST压缩算法从pglz切换为LZ4。本文追溯了从Postgres 7.0引入lztext到7.1实现TOAST与pglz的历史,解释了pglz设计的取舍:速度优先、极小内存占用、快速终止和零外部依赖。然后对比了LZ4的优势:更快的压缩速度(测试中提速约8倍)、更大的滑动窗口带来更好的压缩率,并保留了快速终止特性。文章详细说明了变长类型的varlena格式、EXTENDED/PLAIN/EXTERNAL/MAIN四种存储策略,以及写入时的压缩决策树:行大小超过约2KB阈值时,依次压缩前列大对象或移入TOAST表。此外,还介绍了B树索引中机会主义压缩的机制:当键值超过510字节时尝试压缩,并举例说明可压缩与不可压缩数据对索引的影响。整体内容既包含机制解析也包含实践测试,展示了Postgres团队在压缩演进上的谨慎策略。边界在于测试非科学化,且未深入LZ4算法内部细节。

本文系统梳理了Postgres压缩框架的历史、原理与决策路径,并结合代码示例和对比数据说明LZ4替代pglz的收益。适合需要理解Postgres存储优化、TOAST机制或索引限制的DBA与开发者,可迁移的价值在于掌握如何诊断压缩效果、选择存储策略以及评估算法升级对性能的影响。内容详实且有长期参考价值。

工程实践Salesforce Engineering

Using Claude to Build an AI Knowledge Base in 30 Minutes

本文介绍了如何利用Claude Code在30分钟内构建一个衍生的AI知识库,通过将团队散乱的设计文档、Slack讨论等原始资料交由代理生成干净、互链的概念笔记和人员笔记,形成既可供人类浏览又可供AI代理快速检索的结构化Markdown集合。文章详细说明了文件夹结构、两条自定义技能‘/ingest-doc’和‘/refine’的设置与使用,并通过实例演示了从摄入文档、推导笔记到迭代精炼的完整流程。最后讨论了成本控制、可信任边界和随时可重建的灵活性,并指出该模式已在作者团队持续运行超过6个月,适用于代码仓库、客户记录等多种知识密集型场景。

推荐收录。文章提供了真实团队长期使用AI代理构建和维护知识库的工程案例,步骤清晰、可直接复现,且揭示了推导、精炼等核心设计原则,可迁移到任何需要管理技术文档或组织知识的场景,对AI工程实践者和团队负责人有较高参考价值。

工程实践LWN.net

[$] Lockless MPSC FIFO queues for io_uring

文章介绍了 Linux 7.2 内核中 io_uring 子系统将工作项跟踪机制从标准链表替换为无锁多生产者单消费者(MPSC)队列的工程实践。作者逐步解释了无锁队列的设计原理,包括原子操作、内存顺序和使用场景,并展示了该变更带来的显著性能提升。文章还讨论了无锁算法在正确性与性能之间的权衡,以及该实现为何适用于 io_uring 的特定工作负载。内容聚焦于真实工程问题、具体实现取舍和可验证的效果,为理解内核并发优化提供了清晰的案例。

推荐收录,因为该文不仅报告了性能提升结果,更深入解析了无锁 MPSC 队列在内核中的具体设计和正确性保障,展示了从问题识别到算法选择、验证的全过程。对从事内核开发、高性能系统设计或对无锁编程感兴趣的读者有直接参考价值,其设计思路和分析方法可迁移至其他并发场景。

技术文章Eli Bendersky

Notes on the Fourier Transform

本文从傅里叶级数出发,通过让周期趋于无穷大,逐步推导出傅里叶变换,重点演示了非周期函数如何从离散频率系数过渡到连续频率函数。作者以一个奇三角脉冲为例进行计算,展示变换的复数结果及其幅度和相位,并讨论频率域表示的意义。文章还阐述了傅里叶变换的存在条件(绝对可积)、以及线性、缩放、时移、导数和卷积等关键性质,最后给出卷积定理。内容偏向工程实用,对数学严谨性有所取舍,假设函数在无穷远处趋于零,适合信号处理等领域的入门学习。

推荐收录,因为本文以清晰、有层次的推导讲解了傅里叶变换的核心概念,并提供了可交互的直观演示(文字描述)和具体计算示例。适合计算机专业学生、信号处理或相关领域的工程师作为理解频域分析的基础参考,其从级数到变换的推导思路也具有可迁移的学习价值。

工程实践知乎 - NGINX洪志道

09 | AI太擅长写业务了

文章以 Nginx 上 Lua Web API 的开发为例,介绍了如何利用 AI 辅助编程实现 Request、Response 和 Headers 对象。核心方法是统一对象模型的设计模式:通过 create(创建骨架)、get(取出 C 结构体)和 fill(填充数据)三个独立职责,解耦对象定义、数据来源和跨语言访问,确保 Lua 与 C 两侧的一致性。作者强调 AI 更适合在清晰的设计约束下快速复制正确模式,而人负责确定模型和边界。文章还讨论了 AI 在加速理解系统和生成代码方面的价值,以及如何在迭代中提升代码质量。结论是“人设计,AI 实现”能平衡效率与质量,但需要较强的设计能力来引导,且 AI 初始输出需人工审校。适用场景包括跨语言系统开发、嵌入式脚本扩展等,不足在于对设计者能力要求较高。

推荐收录,因为文章不仅展示了 Nginx/Lua 跨语言对象管理的具体工程实现,还提炼出可复用的 create/get/fill 设计模式,并提供了人机协作的实践边界。对于需要开发嵌入式脚本接口、处理跨语言对象生命周期,或希望利用 AI 提升编码效率的工程师,文中模式可以直接迁移,协作理念也具有长期参考价值。

工程实践知乎 - SmartCode 得物技术

得物推荐系统诊断 Agent:从 “调接口” 到 “会思考”|AICon 演讲整理

本文详细介绍了得物推荐系统诊断Agent“推查查”的设计与工程实践。针对推荐系统异常排查中人工依赖高、经验难沉淀的痛点,设计了一种混合智能体架构:Highway模式通过预编排的Story标准化流水线快速处理80%常见问题,ATV模式基于ReAct循环自主推理解决20%长尾复杂问题,中间由智能调度器无缝切换。技术实现上,通过插件化Skill工具集、Story编排、ReAct约束机制以及结合OpenViking与Graphify的知识库,保障了诊断的确定性与可扩展性。进化层从排查记录中自动提炼通用方法并生成新Story,实现系统自进化。实战案例验证了方案的有效性,也指出了知识检索触发策略等现有局限。

展示了一个推荐系统智能诊断系统的完整工程落地过程,包含架构设计、关键技术实现和进化机制,对于从事推荐系统、AI工程化或系统可靠性的工程师具有可迁移的参考价值。文章细节丰富,从问题定义到方案权衡再到验证,体现了工程实践的深度,值得收录。

工程实践知乎 - 千问云

Harness 工程之道:Skill 原理与最佳实践

文章系统讲解Agent Skills的概念、结构和触发机制,围绕渐进性披露设计,将领域知识封装为可移植的模块化能力,实现按需加载。文中以真实项目trade-ab-skill为例,详细介绍SKILL.md的路由表设计、知识分层策略、工具隔离安全实践、脚本增强和参数传递等最佳实践。文章指出Skill能有效降低上下文成本、提升Agent协作效率,但编写质量和触发描述至关重要。该实践适用于需要为AI Agent扩展特定工作流的工程场景,可帮助团队构建可维护、可复用的Agent能力。

文章提供了完整的工程案例和最佳实践总结,从概念到落地步骤,内容详实具体,适合AI Agent开发、AI工程化或DevOps工程师。其模块化组织、渐进加载和安全隔离的设计原则可迁移至其他Agent平台或工具扩展,具有长期参考价值。

工程实践Yelp Engineering

Training Orchestrator: Unifying Model Training at Yelp

本文介绍了Yelp为统一机器学习模型训练而构建的Training Orchestrator系统。面对多团队使用各自Spark训练脚本、配置分散、代码重复和维护成本高的问题,Yelp核心ML团队在已有特征存储、统一训练库、MLflow等工具的基础上,设计了一套标准化的训练编排层。该平台提供了统一的作业调度、工作流执行和监控机制,将模型训练任务抽象为可复现的流水线,并与Spark和MLflow无缝集成。文章还讨论了系统架构的权衡、对团队效率的提升以及适用范围(主要服务于基于Spark的训练场景)。

推荐收录,因为该文不是泛泛的MLOps概念介绍,而是基于Yelp真实工程需求,详细展示了从分散脚本到统一训练平台的架构演进。文中对训练编排、与现有ML基础设施集成的设计权衡,以及规模化运营的考量,对正在构建或优化内部ML平台的数据与工程团队具有直接参考价值。其可迁移经验包括如何通过平台化手段降低维护成本、提升模型训练的一致性,但需注意其方案强绑定Spark生态。

工程实践Netflix TechBlog

Building Service Topology at Scale: Architecture, Challenges, and Lessons Learned

本文详细介绍了Netflix构建实时服务拓扑系统的完整工程历程,涵盖架构设计、生产环境挑战与持续优化。系统采用流式优先的三阶段分布式聚合流水线,结合反向压力、动态一致性哈希和时间窗口聚合器,实现了对网络流日志、IPC指标的高吞吐处理与历史拓扑查询。文章重点分析了Kafka消费滞后、热点节点、内存与GC压力、响应式流复杂性等关键问题,并通过重分布、使用可变数据结构替代不可变对象、更换通信协议等务实手段解决。作者强调,在超大规模下测量驱动迭代优化比遵循教条更重要,同时也指出了响应式流心智模型的高成本。该案例为构建大规模分布式数据流水线提供了可迁移的架构模式与性能调优经验,但部分技术选型需结合自身场景评估。

本文收录理由在于它提供了从0到1构建大规模服务拓扑系统的完整工程案例,而非浅层介绍。作者坦诚分享了架构权衡、失败教训和优化方法论,对分布式系统、流处理和可观测性领域的工程师有直接参考价值。可迁移的核心经验包括多阶段重分布解决数据倾斜、背压实现优雅降级以及性能优化时的务实取舍,但采用时需结合自身规模与技术栈做适配。

工程实践Meta Engineering

Modernizing the Meta Ads Service With an Open-Source Kernel Scheduler

文章介绍 Meta 广告服务在 Linux 内核升级至 6.9 时遭遇 EEVDF 调度器导致的延迟回归,影响广告排序。团队利用开源的 sched_ext(BPF 扩展调度框架)构建了面向广告交付的自定义调度策略,通过将 CPU 软分区为延迟关键池和非关键池,并根据负载动态调整池大小,显著提升最后一级缓存局部性。初始部署在最大广告服务器上后,广告检索的 p99 延迟降低 28%,功耗节省 3.28 兆瓦,加权广告排名提升 1.1%,后续两次用户空间策略更新进一步降低延迟并减少超时错误。该方案将调度优化从依赖内核发版的路径中解耦,使迭代周期从数月缩短至数天,并将 sched_ext 从短期修复发展为持续优化平台,同时已上游化至 Linux v6.12。文章未探讨该策略对其他混部负载的公平性影响,且定制策略需依工作负载特性重新设计。

推荐收录,因为它提供了一个完整的高负载服务调度优化工程案例,从问题诊断、基于 sched_ext 的自定义策略实现到量化效果验证,证据充分。适合基础设施、后端性能优化和 SRE 读者,文中展示的软分区、缓存局部性利用以及借助 BPF 快速迭代的方法可迁移至其他延迟敏感系统。

工程实践Cloudflare Blog

Introducing Precursor: detecting agentic behavior with continuous client-side signals

文章介绍了 Cloudflare 推出的 Precursor 功能,一种基于客户端行为信号的会话级机器人检测系统。Precursor 通过动态注入 JavaScript 持续收集鼠标移动轨迹、键盘节奏、页面焦点变化等交互数据,并在边缘服务器上对行为模式进行交叉验证和聚合评估。系统强调隐私优先,仅采集时序和节奏特征而非实际按键内容,同时将会话级检测整合进现有的 Bot 管理框架,防止自动化工具通过刷新页面重置行为指纹。这种持续性观测能有效分辨短期看似合理、长期却难以伪装的自动化行为,提高检测精度并降低对合法用户的摩擦。文章还概述了系统架构、评估层设计及配套的会话分析仪表板,目前作为 Enterprise Bot Management 的附加功能发布。不足之处在于缺乏大规模部署的效能数据和对抗演进的长期验证。

本文详细阐述了一个真实的工程案例:如何设计一套隐私保护、持续运行的客户端行为检测系统来对抗复杂机器人。文中对信号采集、边缘评估、会话上下文和隐私权衡的讨论具体且可迁移,适合 Web 安全、反爬虫和风控工程师参考。其设计思路和架构权衡可应用于其他需要区分人类与自动化流量的安全系统,具有长期的工程参考价值。

工程实践知乎 - 严格鸽

从leetgpu的一道题目到CUB中的Decoupled look-back

本文以LeetGPU上的一道stream compaction题目为切入点,记录了从基础的多kernel前缀和实现到借鉴CUB的Decoupled look-back算法的完整优化过程。作者首先解释了题目要求和并行化思路,然后逐步融合算子、调整tile大小,最终引入基于状态的look-back机制,将全局扫描的读写复杂度降至2N。文章详细展示了tile状态机的设计、warp级扫描与lookback_sum的实现,以及针对写回路径的shared memory/global memory双路径优化。此外,还涵盖union复用shared memory、 sleep等待策略等工程技巧,并对比了Thrust和手写CUDA的性能差异。整体呈现了一个从简单到高性能的实战优化路径,适用于单GPU上的稳定stream compaction,但算法思想可迁移到其他并行扫描场景。

收录理由:本文不是单纯的代码片段或性能报告,而是展示了从算法选型到微观工程优化的完整决策链,包括对Decoupled look-back原理的剖析、状态机设计、warp级协同和硬件调优。对学习CUDA性能优化、并行扫描算法以及从CUB源码借鉴实践的读者具有直接参考价值,文中的look-back模式、shared memory复用和双路径写回策略均可迁移到类似的高性能GPU编程场景。

工程实践知乎 - 鹅厂架构师

从智能体开发到日常构建:Harness Engineering思维的跨界思考

文章系统阐述了Harness Engineering(驭缰工程)这一AI时代工程范式,提出“智能体=模型+驭缰系统”核心公式,并拆解了执行运行时、上下文管理、能力层、治理层、可观测性五层生产级架构。作者深入解读了六条源自实战的方法论,包括先磨设计规格文档、优先补齐关键规则、将高频动作下沉为Skill、按认知负载拆分多Agent等,强调了渐进式复杂度管理和约束先行的构建哲学。结合OpenAI、Stripe等案例验证了约束系统对AI应用成功的关键作用,并将该方法论跨界迁移至个人小程序、团队网页协作、Demo原型等日常开发场景,展示了其作为通用构建哲学的潜力。文章以方法论和思维启发为主,对工程实践中的边界设计与增长节奏给出了可操作建议,但缺少底层技术实现细节,更适合中高级开发者或技术管理者作为架构决策参考。

本文不是浮于表面的AI工具介绍,而是从Harness Engineering这一前沿概念出发,提炼出可跨领域迁移的构建哲学。它既有Mitchell Hashimoto等人的原始洞见作为依据,又通过OpenAI、Stripe等业界案例提供了实证支撑,更难得的是将抽象方法论落地到小程序、网页等日常开发中,展示了清晰的迁移路径。适合正在构建复杂系统或希望提升工程思维的技术负责人和开发者阅读,文中‘约束即赋能’、‘按认知负载拆分’等思想能有效指导实际项目中的架构边界与增长节奏控制。

工程实践知乎 - NGINX洪志道

08 | 开发最核心的fetch功能

文章记录了在 NGINX 环境下从零实现 fetch(独立 HTTP 客户端功能)的完整过程。作者以异步连接为起点,逐步加入请求发送、响应读取、Stream 流式处理、keepalive 连接池、DNS 解析和 HTTPS 等能力,每次迭代都先保证核心设计合理,再让 AI 实现具体代码并即时 review。文中还深入讨论了为何将所有实现放在单个 fetch.c 文件中符合高内聚原则,并指出过度拆分文件反而会增加不必要的边界复杂度。方法的核心是将复杂功能拆解为可验证的最小单元,由人把控理解、设计和拆解,AI 负责实现与测试,从而兼顾开发效率和代码质量。该案例适用于需要自行实现异步网络功能或探索人机协作开发的工程师,但要求开发者自身有扎实的编程和设计判断力。

推荐收录,因为它不是一个简单的功能实现记录,而是展示了从核心到外围的功能拆解策略、与 AI 协作的迭代方法,以及基于高内聚原则的文件组织决策。这些方法对需要做复杂功能开发的工程师具有直接借鉴意义,所讨论的 AI 编程边界、设计复杂度控制和代码结构选择都是长期有效的工程议题,可迁移到类似的网络服务或基础设施开发场景。

工程实践NVIDIA Technical Blog

Reducing High-Bandwidth Memory Bottlenecks in JAX-Based LLM Training with Host Offloading

本文针对大型语言模型训练中 GPU 高带宽内存(HBM)容量不足的瓶颈,提出并详细讲解了基于 JAX 的主机内存卸载方案。作者将模型参数、梯度、优化器状态等张量通过 JAX 的分片与异步传输机制卸载到主机内存,结合激活重计算进一步降低 HBM 占用,同时利用主机内存带宽和传输隐藏策略减少吞吐损失。文章给出了完整的代码示例与性能分析,在 LLaMA 风格模型上实测了显著的 HBM 节省效果,并讨论了该方案适用的模型规模、序列长度及通信环境约束。

推荐收录,因为文章不是简单的 API 介绍,而是深入剖析了 LLM 训练的内存瓶颈,并提供了一套可复用的主机卸载方案,包含具体实现、性能数据和工程取舍。对从事大模型训练、GPU 内存优化或 JAX 框架开发的工程师和研究者有直接的参考价值,其中的异步卸载策略和内存–计算权衡思路可迁移到其他框架和硬件平台。

工程实践知乎 - 腾讯技术工程

凌晨3点,我的AI军团还在替我交付

本文是腾讯技术工程团队基于开源项目Multica构建多Agent协作工作流的工程实践。文章围绕“如何让一组Agent围绕目标协作完成一段工作”展开,核心方法是扩展Multica形成三根骨架:将分散Agent接入为统一调度能力池、将人类流程经验沉淀为可编排工作流、建立外部系统交接协议以实现工作进出闭环。在此基础上,补充了准出字段与Verdict、并行与收敛、验收与返工、自愈与显式阻塞、错误诊断、运行指标等复杂能力,使系统真正可用。第一阶段在标准需求、Bug修复、平台自我迭代、历史问题池等场景中跑通了从输入到验收的完整链路,验证了“把人类流程Agent化”的可行性,并沉淀了关键判断:一段工作可由系统推进、多个Agent可按流程协作、上下文可在系统内传递、异常可暴露、交付可闭环。文章最后指出人的位置从处理单点任务上移到设计机制,并提出下一阶段从“人类流程Agent化”走向AI原生工作流,探索更适合AI协作的组织方式。当前方案适用于边界清晰、目标明确、结果可验收的工作,强依赖人工定义流程边界和验收标准,尚不能处理高度模糊或创造性任务。

本文不是简单的Agent应用介绍,而是展示了一套多Agent协作系统的完整工程设计与真实运行经验,涵盖架构设计、关键能力补全、失败路径处理与持续改进,具有高度的可迁移价值。适合从事AI工程化、平台建设、自动化协作研究的工程师或技术管理者,能为其提供从单点Agent到组织级协同的实践路径与工程决策参考。

工程实践Grab Tech

Scaling Grab's Data Lake: Our journey to Apache Iceberg adoption

文章详细介绍了 Grab 从 Hive Parquet 向 Apache Iceberg 迁移数据湖的完整工程实践。首先分析了原始架构在目录延迟、小文件碎片、运维负担和信息一致性上的瓶颈,然后说明了选择 Iceberg 的决策依据。迁移采用按表优先级逐步推进的策略,在导航数据集上通过 Z-ordering 获得约 10 倍查询性能提升,并在运营表上节省了 95% 的 S3 API 成本。为应对 Iceberg、Delta、Hudi 等多格式共存的开发体验问题,团队自研并开源了 UnifiedSparkCatalog,透明路由不同表格式操作。文中还分享了 Hive 锁竞争、时间戳兼容性、存储层级成本等实际坑位和解决方案。案例适合大型数据平台的可扩展存储架构改造,迁移策略和工具设计具有较高的可迁移性。

本文提供了从中型数据湖到现代表格式转型的完整路线图,包含明确的性能与成本量化证据、自研工具的架构取舍和开源发布,以及生产环境踩坑经验。适合数据平台工程师和架构师参考,尤其对计划从 Hive 迁往 Iceberg、需要多格式兼容的团队有直接借鉴价值。

工程实践Salesforce Engineering

How Informatica Reduced Data Integration Pipeline Development from Days to Minutes

本文以Informatica Copilot为例,介绍如何通过自然语言生成数据集成管道,将开发时间从数天缩短到数分钟。文章回顾了从微调模型转向OpenAI的架构决策、应对模型快速演进的测试策略,以及通过提示工程、上下文增强和验证层提升准确性的方法。客户已生成约10,000条管道,表达式自动生成采纳率约60%,表明AI辅助显著提升效率。核心结论是生成式AI的准确性更依赖上下文与防范机制而非模型规模,并提出未来将支持代码优先和代理式工作流。案例局限于数据集成领域,但工程思路具有可迁移性。

推荐收录,因为文章提供了从模型迁移、非确定性系统测试到提示调优与验证的完整工程案例,并附有客户采纳数据作为证据。适合正在构建AI特性尤其是LLM集成的工程师阅读,可借鉴其迭代适应基础模型、通过验证层保障准确性的实践。主要迁移价值在于揭示了提升AI系统精度不依赖更大模型,而在于上下文设计与保护机制。

工程实践GitHub Security Lab

How GitHub gave every repository a durable owner

文章讲述了 GitHub 如何为内部组织超过 1.1 万个无主仓库建立持久所有权。面对秘密扫描修复等安全工作中找不到仓库负责人的痛点,GitHub 设计了基于自定义属性(ownership‑type 和 ownership‑name)的所有权模型,区分服务目录、团队和个人三类。通过同步服务目录获得初始覆盖后,利用 GitHub App 和 Kubernetes CronJob 推出自动化执行:新仓库创建时强制声明所有权,已有仓库则创建 issue 并给予 30 天宽限期,逾期未声明的仓库被归档。过程中因缺少直接通知和外部数据源异常导致两次小型事故,随即引入 @提及通知、低水位阈值等保护措施。最终归档约 8000 个仓库,所有活跃仓库均具备持久所有者,并维持实时检查以防漂移。文章提供了可迁移的实践步骤,强调自动化操作必须预设数据失效和通知缺失的防护。

本文是一个完整的工程实践案例,从问题定义、模型设计、自动化推出到异常处理形成闭环,真实呈现了大规模组织内部推行仓库所有权管理的取舍和教训。对于需要治理海量代码仓库、提升安全响应速度或满足合规要求的平台工程团队、DevOps 或安全工程师,文中的自定义属性方案、可逆归档策略和边缘防护思路具有直接可迁移价值,同时也提醒了自动化操作中必须提前防御数据可靠性和通知失效问题。

个人心得知乎 - NGINX洪志道

聊聊编程中的原创能力

作者结合在NGINX社区的真实经历,分享了对编程原创能力的思考。文章从一次设计任务讲起:当被要求实现文件服务时,借鉴 NGINX 现有方案的提议被同事否决,从而引导作者反思“对成熟系统祛魅”的必要性,并认识到原创能力源于对问题的深入理解和摆脱定式思维。接着以自主开发的 NGINX Lua Web 运行时项目为例,展示了如何在长期理解系统的基础上,设计出更符合当前目标的脚本化方案。文章还讨论了 AI 在加速原型验证和理解过程中的作用,但强调理解本身不可被跳过。最后提出提升原创能力的建议:在思维上保持开放、接纳多元设计;在技术上通过实践自己关心的项目,并在过程中不断追问核心价值和设计取舍。不足在于缺乏量化实验和具体的技术实现细节,更多是个人感悟与心态总结。

推荐收录。文章不是空泛的鸡汤,而是基于作者在 NGINX 社区的实际经历和亲手开发的项目,完整展现了从“尊崇已有设计”到“独立思考重新设计”的认知转变,并具体定义了编程原创能力的内涵。适合对软件设计进阶、突破思维惯性感兴趣的开发者阅读,可迁移价值在于帮助读者反思自身对既有方案的依赖,并提供了在个人项目中刻意训练原创能力的实践思路。

工程实践知乎 - SmartCode 得物技术

得物 OceanBase 落地实践

文章详细记录了得物将 OceanBase 作为多模数据库引入的完整工程实践。面对 MySQL 在 TP/AP 混合负载下性能瓶颈、存储成本高和运维复杂等问题,DBA 团队从选型对比、性能压测、复杂 SQL 优化到业务迁移全流程展开验证。通过计划缓存、分区裁剪、列存索引、并行执行和 Hint 干预等五步优化,将两类聚合查询的执行时间分别从 1.3s 和 3.9s 降至 0.01s 和 0.02s,并获得与 DuckDB、StarRocks 对比的详细性能数据。在真实业务迁移中,SQL 平均耗时下降 88.3%,存储压缩率超过 80%,总体降本 43%,并消除了异构数据同步和手动分流风险。文章同时总结了迁移中遇到的实时物化视图与 DDL 冲突、SQL 语法兼容等具体问题及应对方案,并规划了运维体系转型和团队能力建设路径。该实践适用于有 TP/AP 混合负载、追求成本与可用性平衡的场景,但需注意新功能边界和版本限制。

推荐收录。文章不是泛泛的产品介绍,而是提供了从选型对比、性能压测到生产迁移的完整技术链条,包含具体的 SQL 优化思路、量化收益(近 200 倍提升、43% 降本)和踩坑记录,对考虑 OceanBase 落地或从 MySQL 迁移到分布式数据库的架构师、DBA 有直接可复用的参考价值。文中的五步优化法、物化视图使用约束和运维体系转型经验均具备可迁移性,风险提示也较为坦诚。

工程实践GitHub Engineering

Automating cross-repo documentation with GitHub Agentic Workflows

文章来自GitHub工程博客,详细介绍了Aspire团队如何利用GitHub Agentic Workflows实现跨仓库(microsoft/aspire到microsoft/aspire.dev)的文档自动生成。核心方法是在特性PR合入后触发工作流,通过里程碑自动解析目标文档分支,由LLM代理阅读代码diff和关联issue,判断是否需要文档并起草MDX内容,最终以草稿PR形式提交并指定特性工程师为审核人。安全模型通过safe-outputs契约将代理的写入能力严格限定在指定仓库、分支和受保护文件之外,使用GitHub App令牌实现最小权限。文中给出了30天运行数据:396次运行生成82个文档PR,中位合并时间44.8小时,合并率100%,并总结了里程碑映射、草稿+专人审核、令牌作用域等成功经验,以及初版门控过宽、大diff预算爆炸等改进。该方案显著降低了文档的‘逆向工程税’,使文档作者转向更高价值工作,但要求项目已有清晰里程碑与发布分支映射,且需要预处理大尺寸PR。

这是一篇高质量的工程实践案例,完整呈现了跨仓库文档自动化的真实挑战、方案设计、安全权衡与效果验证。文中对安全约束的细致设计(如safe-outputs、GitHub App最小权限)和过程数据极具参考价值,可直接指导类似场景下AI驱动工作流的落地。适合负责DevOps、平台工程或需要提升文档效率的团队阅读,其中的里程碑映射、草稿+专家审核模式以及安全思维均可迁移至其他自动化项目。

工程实践Armin Ronacher

Better Models: Worse Tools

文章复盘了一个真实的 LLM 工具调用故障:较新的 Claude 模型在 Pi 的编辑工具上,会在本应只有 oldText/newText 的嵌套 edits 数组里额外发明字段,导致 schema 校验失败,而旧模型反而没有这个问题。作者将其归因于模型在 Claude Code 这类“宽容的”闭源 harness 上继续训练后,学会了某种特定编辑工具形状,却也学会了容忍未知键、别名和自动修复,因此在不同 schema 上出现迁移退化。文章进一步对比了自由采样与 grammar/strict constrained decoding,指出严格约束能消除这类错误,但可能带来复杂度限制与质量权衡。核心结论是:工具 schema 不是中性的抽象契约,模型对特定 harness 的适配会显著影响可移植性。其不足在于论证主要来自观察与推断,缺少系统化实验和公开训练细节验证。

推荐收录,因为文章给出了具体故障现象、复现条件、对比实验和对 strict/constrained decoding 的直接判断,不是泛泛而谈。适合做 LLM 工具调用、代理框架和 schema 设计的参考,尤其能提醒读者警惕“在一个 harness 上变强,却在另一个 harness 上变差”的迁移风险。

工程实践知乎 - NGINX洪志道

07|变化是复杂度的帮凶

这篇文章复盘了作者在 NGINX/Lua 项目中实现 Stream、并为后续 fetch 做铺垫的工程拆解过程。作者先把 fetch 分解为 Request、Response、Headers、URL、URLSearchParams 和 Stream,指出真正的复杂度主要集中在 body 的异步流转,以及 C 与 Lua 两套执行模型的衔接。为了避免 AI 一次生成过大的、难以重构的方案,他没有让模型直接实现完整 Stream,而是先压缩需求,只做异步核心,并把 handler 的输入输出临时改成 Stream。随后在这个更大的边界上补齐同步能力,使设计保持一致,代码增量主要是追加而非推翻重写。文章最后给出当前实现状态:请求体可作为异步 Stream 被 Lua 读取,Lua 可创建同步 Stream,响应体也能被 NGINX 消费;fetch 仍是后续更复杂的目标。

推荐收录,因为它不是泛泛谈“用 AI 写代码”,而是给出了真实项目里如何拆分复杂异步接口、如何设定最小可行边界、如何审阅 AI 方案的具体做法。适合做大型功能设计、AI 辅助开发和异步抽象设计的参考,尤其对需要在 C/Lua 或类似双模型系统间做桥接的工程场景很有迁移价值。

工程实践Grab Tech

Migrating Counter Service storage: Design choices and learnings

文章复盘了 Grab 将 Counter Service 从宽表数据库迁移到 Aerospike 的全过程,核心不是简单换存储,而是先重构读写分层,再按访问模式重新设计数据模型。读路径上,作者把存储访问从业务逻辑中抽出,采用带枚举分发的 facade,并通过 shadow read、split traffic 和配置切换实现无停机、可回滚迁移。写路径上,团队尝试了按桶存行、Secondary Index 和 BatchGet,最终选择“单 counter 单记录 + 有序 map”的结构,用原子 MapIncrement 和显式清理旧桶来降低索引和磁盘占用。文中还记录了 Rust 客户端不成熟、DNS 解析和 NVMe 索引实验带来的问题与回退原因。最终系统在读延迟、成本和存储 footprint 上都有明显收益,但这些收益主要来自 schema 与架构重构,而非数据库替换本身。

推荐收录,因为文章给出了迁移前后的存储分层、影子流量、逐步切流、数据建模和回退验证等完整证据,而不是泛泛谈“换数据库”。适合做存储迁移、在线系统无停机改造和性能/成本权衡的参考,尤其对需要处理高 QPS 计数服务的工程师有直接迁移价值。

工程实践知乎 - SmartCode 得物技术

AI UITester:AI Native 的 UI 自动化测试新范式|得物技术

文章介绍得物团队的 AI UITester:一种面向移动端 UI 自动化测试的 AI Native 方案,目标是解决传统脚本用例迁移、调试和三端维护成本高的问题。作者给出了从用例平台 JSON 到可执行脚本的自动化 Pipeline,包括树结构展平、去重、LLM 增强、版本归档等阶段,并强调通过 Wiki 知识注入提升步骤生成准确性。执行层采用 VLM 驱动的“截图-理解-执行”闭环,配合失败分类器、置信度阈值和自愈机制,实现业务失败的自动诊断与修复。文章还对比了 Appium/XCUITest 等元素定位方案与 AI 辅助方案,指出 AI Native 的核心变化是从“维护定位器”转向“理解界面与流程”。其边界也很明确:Wiki 质量会直接影响诊断效果,复杂流程变更仍需要人工确认。

推荐收录,因为文章给出了可落地的 UI 自动化架构:用例转化 Pipeline、VLM 执行闭环、失败分类、自愈和置信度控制都有明确设计细节。适合做移动测试、AI 工程化和自动化平台建设的参考,但也要注意它对知识库质量和阈值校准依赖较强,复杂场景仍需人工兜底。

工程实践知乎 - NGINX洪志道

05|NGINX 脚本化历史,以及为什么选择官方 Lua

文章梳理了 NGINX 脚本化能力的演进脉络:从早期 Perl、SSI,到作者参与的 njs、QuickJS,再到自己尝试的 nginx-lua-web,说明 NGINX 一直在扩展可嵌入脚本运行时。核心论点是,这个新项目不想让用户直接面对 NGINX 的 body filter 等内部概念,而是提供更接近纯 Web 运行时的编程体验。作者进一步比较了 OpenResty 常用的 LuaJIT 与官方 Lua,认为后者在当前版本中性能、GC、稳定性和工程可用性已经足够,且更适合做 C 程序的嵌入式胶水语言。为提升易用性,文章还借鉴了 JS Web APIs,强调用 fetch 等标准接口降低脚本门槛。整体更像一次结合 AI 编程实践的工程选型记录,但其中部分关于版本演进和生态判断带有作者经验视角,适合与实际需求一起审视。

文章直接给出了 NGINX 脚本化路线、官方 Lua 选型和 Web API 设计的工程理由,不是泛泛而谈。适合做嵌入式脚本运行时、Nginx/OpenResty 生态或 AI 辅助开发实践的读者参考;但其中对 LuaJIT/官方 Lua 的结论带有作者立场,具体迁移前仍需结合基准测试验证。

工程实践MaskRay

A deep dive into SmallVector::push_back

这篇文章围绕 LLVM SmallVector 的 push_back 热路径优化展开,分析了约 trivially copyable 元素在容量不足时为何会把本应只发生在慢路径的状态保存,意外带到快路径上。作者通过 clang、GCC 和不同库实现的汇编对比指出,fast/slow 合流会迫使 this 和元素值占用被调用者保存寄存器,shrink wrapping 无法消除这些开销。随后提出把 grow-and-store 拆成独立的尾调用慢路径,让快路径只保留一次比较、一次存储和一次递增,从而显著缩短指令序列并减少寄存器压力。文章还验证了 libc++、libstdc++、Boost small_vector 的类似问题,并说明这个改动对二进制体积、编译时指令数和少数内联阈值敏感点的影响。其边界在于慢路径会更慢且 noinline 很关键,但由于扩容本就要搬移元素,额外一次调用的代价通常可接受。

收录依据很明确:文章给出了汇编、shrink-wrap 诊断和编译时统计,证明问题出在快慢路径合流导致的寄存器溢出,而非简单的代码风格差异。适合做 C++ 标准库、LLVM/编译器后端和性能优化的参考,尤其对需要理解尾调用、内联与寄存器分配权衡的读者可迁移价值很高。

工程实践知乎 - TencentDB腾讯云数据库

「腾讯云 NoSQL」技术之 Redis 篇:针对集群选举投票冲突的优化方案

文章系统剖析了 Redis/Valkey Cluster 在自动故障转移中的三段流程:PFAIL/FAIL 判死、故障副本拉票选举、以及新主广播后刷新路由,并解释了 currentEpoch、configEpoch、auth_timeout、auth_retry_time 和 data_age 的相互作用。作者指出,多个主节点同时故障时,多个副本会在同一 epoch 里并发拉票,因“每个 voter 同 epoch 只能投一票”而发生选票瓜分,导致 5 分片甚至 128 分片集群都可能长期无法自愈。腾讯云在 Valkey PR #1018 中引入 failed_primary_rank,以 shard_id 字典序为故障分片排序,在原有副本内排序基础上再叠加分片间错峰延迟,把抢票改成排队选举。文章还补充了 PR #1009 的快速失败兜底与 PR #762 的分片内错峰,说明这些优化都不改变一票一 epoch 的防脑裂原则,只是降低冲突概率并缩短恢复窗口。其价值在于把协议层的随机恢复,推进为大规模云环境下更确定的自愈流程;边界则是仍依赖 gossip 一致性,极端时序竞争下仍需快速失败兜底。

推荐收录,因为文章给出了从协议机制到线上故障现象的完整链路证据,并明确指出多主同时故障下的选票瓜分是 Cluster 自愈失败的根因。适合做 Redis/Valkey 高可用、分布式选举和故障转移设计的长期参考,尤其对云数据库和大规模集群运维很有迁移价值。

工程实践知乎 - TencentDB腾讯云数据库

腾讯云 NoSQL 技术之 MongoDB 篇:物理备份磁盘膨胀率减少 90% 的内核优化实践

文章围绕 MongoDB 基于 WiredTiger 的物理备份在 hidden 节点上持续膨胀的问题展开,指出根因是 backup cursor 将历史 checkpoint 持续 pin 住,导致旧 extent 不能回收,新写入只能不断追加到文件尾部。作者进一步分析了 oplog.wt 在备份期既最容易膨胀、又几乎没有回档价值的特点,并给出按表级粒度释放 checkpoint 的内核接口 `WT_CONNECTION::backup_release_checkpoint`,让旁路备份服务在拷完单表后即时通知引擎恢复空间回收。针对 oplog,则在备份开始即释放并跳过拷贝,同时配合元数据处理避免恢复失败。文章还补充了 crash recovery 场景下的 sentinel 文件方案,用于区分备份中断与备份完成,避免错误进入 hot backup restore 路径。实测显示,在多表场景下备份耗时约减半,hidden 节点峰值占用和物理膨胀率显著下降,但方案强依赖 MongoDB/WiredTiger 备份与恢复语义。

推荐收录,因为文章给出了从根因分析、内核改造到恢复语义兜底的完整闭环,并用线上实测数据证明了膨胀率和回档成本的下降。适合做数据库存储引擎、备份系统和稳定性优化的参考,尤其对需要处理 checkpoint、快照一致性和 crash recovery 的读者有直接迁移价值。

工具笔记Armin Ronacher

The Coming Loop

这篇文章围绕“coding agents 外再套一层 harness loop”的工作方式展开,讨论人们如何用队列、评测器、子代理和持续会话去驱动模型反复迭代。作者一方面肯定这种循环在代码迁移、性能探索、安全扫描和实验自动化中的高效性,另一方面也警惕它在长期维护代码时会放大局部修补、削弱可理解性,并让团队逐步依赖机器来完成判断与解释。文章的核心结论不是简单支持或反对,而是认为循环式自动化会成为未来常态,关键问题转向如何保留人类监督、让系统可理解、并把这种能力约束在可控边界内。

推荐收录,因为它不只是讨论某个工具,而是提炼了 AI 辅助开发正在形成的新工作范式:由模型执行、由外层系统判定、由人类设定边界。文章对哪些任务适合循环、哪些任务不适合、以及这种模式对代码可维护性的影响,都给出了具有迁移价值的判断。

工程实践知乎 - 孔某人

主流Agent Harness实现对比——Goal命令

文章围绕主流 Agent Harness 中的 Goal 机制展开,对 Claude Code、Codex、Kimi Code、OpenClaw、Hermes 等实现做了并列比较,重点分析它们在长程任务中的自动续跑、目标达成判定、token 预算、blocked/complete 状态和 Hook 触发方式。作者通过双语 Prompt、状态机结构和工具说明,解释了 Goal 本质上是在模型停下时自动发起“继续/复核”回合,用来缓解模型过早停工或自我判断不完整的问题,同时也指出它不是万能方案,仍受当前上下文判断偏差和额外回合开销的限制。

推荐收录,因为它不是泛泛介绍“Agent 功能”,而是基于实际版本和逆向分析,给出了 Goal 机制的实现差异、状态设计与提示词细节,具有很强的一手参考价值。对做 LLM 工程、Agent 框架设计和自动化任务编排的读者来说,文章能直接迁移为状态机设计、结束判定和预算控制的实现思路。

工程实践Crunchy Data Blog

British Columbia, Time Zones, and Postgres

文章以不列颠哥伦比亚省时区规则变更为例,讨论了 PostgreSQL 中时间存储的核心陷阱:把未来的“本地意图”仅用 timestamptz 保存,会因 tzdata 更新而在查询时还原出错误的本地时间。作者进一步提出双列模式,将 local_time 和 timezone_name 作为事实源,再用触发器计算并维护 starts_at_utc,以同时满足本地语义、UTC 索引与约束检查的需求。文中还说明了这种方案的适用边界、tzdata 变更后的重算策略,以及 RFC 9557 目前并不能解决这类未来本地时间问题。

推荐收录,因为文章围绕真实的时区规则变更给出了可直接迁移到数据库设计中的方案,不只是泛泛讲时间处理。它对预约、日程、法务截止时间等需要保留未来本地意图的系统尤其有参考价值,也明确提醒了哪些场景仍应继续使用 plain timestamptz。

工程实践Jane Street Tech Blog

Using OxCaml to implement type-safe reference counting between OCaml and Python

这篇文章讨论了 Jane Street 如何利用 OxCaml,在 OCaml 与 Python 之间实现类型安全的引用计数与对象共享机制。文章聚焦跨语言互操作中的内存管理、所有权和生命周期约束,核心价值在于把“容易出错的运行时协议”提升为可由类型系统约束的工程方案。它特别适合关注多语言系统、FFI 设计、运行时安全和高可靠工程实践的读者。

推荐收录,因为它不是泛泛介绍 OCaml 或 Python,而是围绕跨语言内存管理这一高风险工程问题给出可复用的方法。文章的价值在于展示如何借助类型系统降低引用计数和对象互操作中的错误概率,对做 FFI、运行时或系统语言工程的人都有参考意义。

职业经验Simon Willison

Why AI hasn’t replaced software engineers, and won’t

这篇文章围绕“AI是否会取代软件工程师”展开,核心观点是否定的:作者认为,现有证据并不支持“AI能力达到某个阈值就会引发大规模裁员”的叙事,尤其在软件工程这样监管壁垒较低的行业里,这一判断更具代表性。文章引用纽约州 WARN 通知中的 AI 披露数据,指出首个完整年度里提交的 160 多家公司没有一家勾选 AI 相关裁员原因,说明至少在公开就业数据上还看不到明显替代效应。作者进一步分析开发工作并不主要耗费在“把代码打进电脑”这一环节,而在于决定要做什么、验证交付是否正确并承担责任,以及对代码库、业务和运行环境的深层理解。文章因此强调,AI 更像是在加速部分执行步骤,而不是消除软件工程师的核心价值。其局限在于它是基于现有数据和定性分析的论证,不等同于对未来长期就业趋势的严格预测。

推荐收录,因为文章直接给出了可核查的证据链:就业数据、任务拆解调查和对工程师工作的定性分析,共同支撑“AI尚未替代软件工程师”的判断。适合关注职业规划、团队管理和 AI 时代工程角色变化的读者阅读;它的可迁移价值在于帮助读者把注意力从“写代码速度”转向需求定义、验证与领域理解,但需要注意它不是严格实验结论,而是基于现有证据的论证。

技术文章知乎 - 孔某人

主流Agent Harness实现对比——SubAgent与MultiAgent

这篇文章系统对比了主流 Agent Harness 中 SubAgent、Agent as Tool 与 Multi-Agent 的实现差异,重点分析了 Claude Code、Codex、OpenAI Agents SDK 和 OpenCode 在上下文继承、Fork、Coordinator、Teammate/Swarm、Handoff 等机制上的设计取舍。作者结合逆向分析、版本差异和实际使用体验,指出当前主流实现更偏向 SubAgent/Agent-as-Tool,而不是传统对等 Multi-Agent;其核心价值在于既能解决长上下文任务,又能引入旁观者视角与并行子任务能力,但相关结论受版本与灰度状态影响,边界条件需要注意。

推荐收录,因为它不是泛泛而谈“多智能体很强”,而是把不同产品的 Agent 编排机制拆开比较,能帮助读者理解 Agent Harness 的真实工程权衡。对做 AI 工程、开发 CLI/IDE 代理、或设计多阶段任务编排系统的人,都有较强的迁移价值。

工程实践Datadog Engineering

From single pull requests to full software packages: Detecting malicious code at scale

这篇文章讲述 Datadog Engineering 如何把恶意代码检测从单个 pull request 扩展到依赖包级别,并在规模化过程中同时控制准确率与成本。核心方法是把分层的 LLM 评估与工具驱动的调查流程结合起来,让模型负责初筛和推理,外部工具负责补充证据与验证,从而提升对可疑代码的判定能力。文章的重点不只是“用了 LLM”,而是说明了如何在安全检测场景里把自动化调查、证据链和成本约束组织成可落地的工程流程。

推荐收录,因为它讨论的是一个真实、长期存在的工程问题:如何在代码和依赖包海量增长的情况下做可靠的恶意代码检测。文章的价值在于给出了可迁移的系统设计思路,包括分层评估、工具增强和成本控制,而不是停留在概念展示。

技术文章知乎 - 鹅厂架构师

AI软件工程范式革命的思考

这篇文章试图从工程史与控制论角度重新定义“AI软件工程”:作者认为过去五十年的软件工程主要是在管理人的不确定性,并未真正实现工程化;大模型首次让“能源换高阶认知”成为可能,因此软件开发有机会从“人为中心 + AI 辅助”转向“AI 为中心 + 人工辅助”。文章进一步提出,真正可靠的 AI 软件产线必须依赖确定性裁判(如编译、测试、监控、契约验证)形成闭环,并通过分治结构、分工协调总线、场景驱动的隐性知识蒸馏来让 AI 从局部写代码工具升级为可被组织化运营的认知产线。适用边界上,文章更多是范式推演和组织设计蓝图,强于方向判断与框架抽象,弱于实证数据与可验证案例。

推荐收录,因为它不是单纯的工具使用经验,而是从工程机制、验证闭环和组织形态三个层面讨论 AI 如何重构软件生产,具有较强的迁移价值。虽然部分论断偏宏观和前瞻,但对关注 AI 代码生成、工程自动化和研发组织变革的读者,能提供一套可继续讨论和拆解的框架。

工程实践知乎 - 鹅厂架构师

QQ音乐Harness Engineering实践

文章系统介绍了腾讯音乐在大仓多服务场景中落地 Harness Engineering 的实践,核心目标是把 AI 编程从“对话式生成”升级为“可控、可审计、可复用”的工程流程。作者提出用上下文工程、流程门禁、服务矩阵、三层知识体系、Skill/Agent/Command 三件套和 Self-Refinement 机制,把需求、设计、开发、验证和经验沉淀串成一条可追溯的链路,从而降低 AI 生成代码在生产环境中的漂移和返工。文章也明确给出适用边界:它不是替代 IDE 或通用 AI 编程工具,而是位于执行层之上的治理层,尤其适合跨服务、跨仓库、强契约约束的企业研发场景。

推荐收录,因为它不是泛泛谈“AI 提效”,而是把 AI 协作中的真实工程矛盾拆成了可落地的治理方案,包含流程、知识、契约和审计等多个层面。对正在探索 AI 编程工程化、Monorepo 微服务协作和团队级 AI 治理的读者,这篇文章有很强的迁移价值。

工程实践知乎 - TencentDB腾讯云数据库

腾讯云Agent Memory节省61% Token提升52%成功率的诀窍:Mermaid无限画布×上下文卸载

文章围绕 Agent 长任务中的短期记忆压缩问题,提出“上下文卸载 + Mermaid 无限画布”的组合方案:将完整工具结果、网页正文和日志等原始信息卸载到外部文件系统,同时用 Mermaid Flowchart 维护任务结构、状态与索引,使上下文只保留高密度摘要和可恢复入口。作者还系统比较了 Flowchart 与 StateDiagram、上下文卸载与画布的分工边界,以及从 raw 原文到 JSONL、MMD、metadata 的分层折叠/恢复路径。文章给出多组长 Session 实验结果,在 SWEbench、Toolathlon、WideSearch、AA-LCR 等场景中实现了最高 61.38% 的 Token 节省,并在部分任务上提升通过率/准确率,说明该方案更适合长任务、多工具调用和反复迭代的 Agent 场景,但对摘要质量与外部索引设计仍有依赖。

推荐收录,因为它不是泛泛介绍“省 Token”的产品稿,而是把 Agent 记忆管理拆成了可复用的工程机制:信息卸载、结构化画布、分层恢复与实验验证。对于做 LLM Agent、工具链、长上下文管理或记忆系统设计的读者,这篇文章能直接迁移其分层存储和任务状态外化思路。

工程实践知乎 - 千问云

Harness Engineering实践,做了一个平台让AI一晚上自动评测和优化你的系统

文章介绍作者基于 AI Agent 搭建的一套自动评测平台,目标是让 AI 自主创建评测任务、生成评测集、执行评测并提交报告,甚至在读完报告后继续反向优化系统,形成闭环迭代。文中分别展示了无 UI 的工具/MCP 测试、带浏览器 UI 的内容与功能评测,以及三轮自动优化的实践结果,并说明了评分稳步提升的过程。文章最后也给出了适用前提:系统要有较好的 UI 规范和自动化基础设施,且被测系统本身需要具备较高的 AI Coding 含量,否则 Agent 容易在复杂老系统里失效。

推荐收录,因为它不是泛泛讲“AI 能测试”,而是给出了从任务定义、评测集生成、执行、报告到自动优化的完整工程闭环,具有很强的可迁移性。对于做 AI 工程、测试平台、Agent 工作流和自动化质量保障的人,这篇文章能直接提供流程设计和落地边界的参考。

工程实践知乎 - 鹅厂架构师

Elasticsearch 实战 | 客户的 ES 2.4 集群跑了 10 年没动,这次我们把它搬上腾讯云了

这篇文章复盘了一个真实的 Elasticsearch 迁移项目:将客户长期运行的 ES 2.4、Solr 5.3.1 以及相关业务索引,迁移到腾讯云 ES 7.14.2,并覆盖了全量/增量同步、灰度切流和回滚双写等完整链路。作者重点讲解了跨 5 个大版本迁移中遇到的关键问题与处理方式,包括多 type 合并到单 type、字段类型一旦落地不可修改、_id 元数据与 source 字段冲突、ngram 分词导致索引膨胀、默认模板影响全文检索,以及按月拆索引配合 index sorting 提升范围查询性能等。

推荐收录,因为它不是泛泛而谈的迁移宣讲,而是把真实生产环境里最容易踩坑的 ES 迁移、建模和性能优化问题逐一拆开,给出了可复用的定位思路和配置方案。对做搜索系统迁移、索引设计、同步链路和线上切流的工程师来说,这篇文章具有很强的迁移价值和实战参考意义。

工程实践知乎 - 千问云

从玩具到生产力:用真实项目讲透 AI Agent 的 Harness Engineering

文章围绕 AI Agent 在企业工程环境中的落地,提出“Harness Engineering”这一控制面概念,核心是用外部状态、能力边界、沙盒验证、checkpoint 和回写机制,把大模型这种非确定性引擎纳入可交付的工程体系。作者结合 Aegis 内部项目的真实推进过程,详细说明了从目标收敛、Spec/Handoff 持久化、Capability 路由,到测试前置、日志反咬、审批门禁等一整套落地方法。文章的结论是:模型能力本身已足够参与交付,但只有先建立 Harness,Agent 才能从“高级玩具”变成可持续协作的研发协作者,同时工程师的角色也会从亲手写代码转向目标定义、节奏控制和结果验收。

推荐收录,因为文章不是泛泛谈 Prompt,而是从真实项目出发,系统拆解了 AI Agent 进入生产环境时必须面对的状态管理、执行边界、验证闭环和故障恢复问题。它对想把大模型真正接入研发流程、并思考人机分工变化的工程师具有很强的可迁移价值。

工程实践Lyft Engineering

How We Built a Smarter Pickup Experience for Gated Communities

这篇文章复盘了 Lyft 如何改善封闭社区内的叫车接送体验。作者先指出两个核心问题:默认选点会把乘客引到围栏内,而上车说明只能临时聊天补充,导致司机找不到入口、等待和取消率上升。为此,团队把门禁社区编码进地图数据,生成门区边界,并在乘客端提供“门内/门外”两类更贴近真实行为的上车点建议。随后又在路由中加入经过大门的中间停靠点,并在司机接近门口时及时展示简洁的门禁说明,同时加入可删除、不可跨行程保留等隐私保护。上线实验显示该流程未显著增加下单流失,且降低了取消、缩短了等待,说明把现实约束显式纳入地图、推荐、路由和交互链路是可复用的工程方法;但当前覆盖仍依赖地图数据完整性,且多入口社区的最优选门仍有改进空间。

收录价值在于它给出了一个完整的工程闭环:从地图建模、路径改造到交互时机和隐私控制,并用实验和指标验证效果。适合做地图、出行、位置服务或复杂前端/后端协同系统的参考,但也要注意其方案强依赖本地地理数据质量与覆盖。

工程实践Yelp Engineering

How Yelp Keeps Server-Driven UI Consistent Across Four Platforms

文章接着前文介绍 Yelp 的 server-driven UI 框架 CHAOS,重点讲它如何与跨平台设计系统 Cookbook 以及自动生成的桥接库 Konbini 协同工作。作者先说明 Yelp 与 Yelp for Business 在 Web、iOS、Android 上存在多套界面变体,导致视觉与交互一致性难以维护。随后描述如何把设计系统组件抽象成可复用的 SDUI 组件,并通过桥接层把同一套定义映射到不同平台渲染实现。文章也讨论了自动生成桥接代码在减少重复劳动、降低差异漂移方面的作用。它更适合已有多端应用和设计系统的团队参考,但前提是组件边界清晰、平台能力差异可被抽象,否则一致性和灵活性仍会冲突。

推荐收录,因为正文直接围绕 CHAOS、Cookbook 和 Konbini 的集成展开,讨论了如何在 Web、iOS、Android 多端保持界面一致,并用自动生成桥接层降低实现分叉。适合做多端产品、设计系统或 SDUI 落地的团队参考;可迁移价值在于组件抽象、跨平台映射和减少重复代码,但也依赖平台差异可被稳定封装。

工程实践OpenTelemetry Blog

How Skyscanner scales OpenTelemetry: managing collectors across 24 production clusters

文章介绍 Skyscanner 在 24 个生产 Kubernetes 集群中规模化管理 OpenTelemetry collectors 的实践。作者以平台工程团队视角切入,说明由 6 名工程师组成的 Hubble 团队如何承担 collector 的主要运维责任,并服务于公司以 Java 为主、超过 1000 个微服务的计算平台。内容的重点不是 OpenTelemetry 基础概念,而是多集群环境下 collector 的部署、管理与组织分工问题。它反映出观测栈在大规模微服务组织中会逐渐平台化,需兼顾统一治理、团队协作与运维可持续性。适用边界也较明确:更适合已经有 Kubernetes 和 observability 基础、正在做平台化整合的团队参考。

推荐收录,因为标题和导语直接给出了真实规模与场景:24 个生产集群、1000+ 微服务、平台团队统一管理 collectors。对做可观测性平台、Kubernetes 运维或 OpenTelemetry 落地的读者,这类跨集群治理与组织分工经验具有较强迁移价值。

工程实践Datadog Engineering

Steganography at scale: Embedding share URLs in Datadog widget screenshots

文章介绍了 Datadog 如何在 widget 截图中嵌入分享 URL 和相关元数据,把原本静态的图片变成“自描述”的可追溯对象。核心做法是使用不可见但具有一定抗损坏能力的水印式编码,让截图在分享、存储和传播后仍能恢复出处信息,从而把可视化内容和其上下文绑定起来。作者讨论了这类方案在大规模生成场景下的工程约束,包括既要肉眼不可见,又要尽量抵抗压缩、缩放和常见转发处理。文章的价值在于展示了图像元数据传递与可观测性产品结合时的系统设计思路,但它主要适用于受控的截图流水线,不适合任意被裁剪或深度编辑后的图片。

收录价值明确:标题和摘要直接表明它解决的是“截图如何携带可恢复的来源信息”这一真实工程问题,并且强调 invisible、resilient、at scale 这些可迁移约束。适合做报表分享、可追溯图片和可观测性产品设计的读者参考,但需要注意水印方案对裁剪、重编码等处理的边界。

工程实践Amazon Science

Verifying and optimizing post-quantum cryptography at Amazon

文章介绍 Amazon 围绕后量子密码 ML-KEM(原 Kyber)构建高保障实现 mlkem-native 的工程实践。作者将前端高层逻辑与面向不同架构的性能后端拆分,前端保留可维护性,后端针对 AArch64、x86_64、RISC-V64 做汇编/内建优化。为同时保证安全与性能,团队用 CBMC 为 C 代码添加可机检契约,证明内存安全和整数边界安全;对关键汇编则结合 SLOTHY、HOL Light 和 s2n-bignum 做形式化正确性证明,并尽量让证明对指令调度和寄存器分配不敏感。文章还专门说明了形式化验证的可信边界,公开 SOUNDNESS.md 记录假设、残余风险和缓解措施。该实现已集成进 AWS-LC,并在 c7i/c7g 上相对参考实现取得明显吞吐提升,但文章也强调验证仍依赖模型、工具链和人工桥接,不能被理解为绝对无风险。

收录价值明确:文章给出了从参考实现到高性能、可验证生产代码的完整链路,且用 CBMC、HOL Light、SLOTHY 等工具说明了具体做法。适合密码工程、系统安全和高性能基础设施读者,尤其可迁移到需要同时兼顾正确性、性能与可维护性的关键代码场景。

工程实践Anthropic Engineering

Harness design for long-running application development

这篇文章系统介绍了 Anthropic 在长时运行应用开发中的 harness 设计演进:先用“生成器+评估器”的双代理结构改进前端设计,再将同样思路扩展到多小时的自动编码任务。作者指出,长任务的主要失效来自上下文窗口膨胀导致的连贯性下降、模型接近上下文上限时的“context anxiety”,以及生成器自评过于宽松,因此需要上下文重置、结构化交接和独立 QA。前端部分通过将“设计质量、原创性、工艺、功能性”拆成可打分标准,并让评估器用 Playwright 直接操作页面,显著提升了生成结果的审美和可用性。完整应用开发则采用 planner、generator、evaluator 三代理:planner 把简短需求扩成规格,generator 分 sprint 实现,evaluator 通过浏览器测试和硬阈值验收,能抓出接口路由、交互和逻辑缺陷。文章最后比较了 Opus 4.5 与 4.6 下不同 scaffold 的必要性,强调 harness 不是固定模板,而应随着模型能力提升持续删减或补充负载组件,但代价是更高的编排复杂度、延迟和 token 成本。

推荐收录,因为文章给出了可复用的代理式 harness 设计:上下文重置、结构化交接、独立评估器、sprint contract 和浏览器级 QA 都有明确实现细节与实验对比。适合做 AI 应用工程、长任务 agent 编排和自动化测试的参考,但也要注意其效果依赖具体模型能力,且成本与时延较高。

工程实践Amazon Science

Formally verified AES-XTS: The first AES algorithm to join s2n-bignum

这篇文章介绍了 Amazon 将 Arm64 汇编实现的 AES-XTS 加密/解密加入 s2n-bignum,并用 HOL Light 对其做形式化验证的过程。作者先从 AWS-LC 的现有实现出发,重整了原本为避免 buffer overread 而非常复杂的 5x 展开循环,把轮密钥常驻寄存器、拆分尾块处理,以便 SLOTHY 进一步优化指令调度。随后,他们依据 IEEE 1619 写出可测试的规格,再证明汇编代码与规格一致,并补充常量时间与内存安全性质。文章还说明了用 CI 持续约束证明、用硬件随机测试校验指令模型的做法。结果是在部分 Arm 核心上获得小幅性能收益,同时把高风险密码实现纳入可维护、可复用的证明框架。

推荐收录,因为它直接给出了“优化汇编 + 形式化证明 + CI 持续约束”的完整证据链,且落地在真实的 AES-XTS 密码库实现上。适合密码工程、系统安全和形式化验证读者参考,尤其对需要兼顾性能与正确性的底层实现有可迁移价值。

工程实践Stanford Hazy Research

ThunderKittens 2.0: Even Faster Kernels for Your GPUs

这篇文章发布了 ThunderKittens 2.0,一个面向 GPU 的 CUDA 内嵌 DSL,并顺带给出一篇面向 Blackwell 的内核优化复盘。新版增加了 MXFP8/NVFP4 支持、调度与 tensor memory 控制能力、简化的构建结构,并把多个示例内核升级到更现代的 API。技术部分重点解释了为何原先放在 GEMM 路径中的两类 fence 实际上并非必需,作者通过 PTX 的因果顺序与 proxy 规则证明共享内存和 tensor memory 的可见性已被保证,去掉后带来约 20 TFLOP/s 的收益。文章还分析了 tcgen05.cp 与 tcgen05.mma 的隐式流水、PTX assembler 对单线程指令的保守串行化、cluster size 对占用率的影响,以及 tensor memory 触发的单 SM occupancy 限制。最后给出较完整的 GPU kernel benchmark 规范,强调输入分布、L2 冷热状态、warmup 和温度稳态都会显著影响 TFLOPs。整体内容适用于做 Blackwell/CUDA 内核、性能分析和基准设计的人,但结论主要建立在特定硬件与 PTX 行为之上,跨架构迁移时需要重新验证。

推荐收录,因为文章不是单纯发布稿,而是给出了 Blackwell GPU 内核优化的具体证据:PTX 因果/代理模型、assembler 生成差异、cluster 占用率和基准方法都配有可验证的观察。适合做 CUDA 内核、性能调优和基准设计的读者参考,但其结论强依赖 Nvidia 新架构与特定指令语义,迁移到其他 GPU 时需重新实测。

工程实践Datadog Engineering

How we reduced the size of our Agent Go binaries by up to 77%

文章复盘 Datadog Agent 的 Go 二进制体积膨胀问题,目标是在不牺牲功能的前提下显著缩小分发包。作者先用依赖图和链接器输出定位体积占比最高的模块,区分出业务依赖、重复引用和可裁剪的标准库/第三方包。随后通过移除冗余依赖、按平台或功能拆分构建、调整编译与链接参数等手段,把不可见但昂贵的体积成本逐步压缩。最终部分目标二进制缩小最多 77%,同时验证启动、发布和维护流程没有被破坏。文章也说明这类优化强依赖 Go 项目结构与构建链,若程序本身耦合过深或功能必须全量打包,收益会明显下降。

收录,因为文章给出了从体积测量、依赖分析到构建裁剪的完整路径,并用“最多 77%”的结果证明优化有效。适合维护 Go CLI、agent、sidecar 或容器镜像的工程师参考;但许多手段依赖项目结构和构建链,迁移时要先做体积画像。

工程实践Blender Developers Blog

Winter of Quality 2026

这篇文章回顾了 Blender 在 2025—2026 冬季进行的“质量季”工作,重点不是新功能,而是围绕稳定性、缺陷修复、测试补强和技术债清理展开。两个月内修复了 350+ 个用户报告的问题,并按动画、建模、节点、渲染、界面、视口等模块给出分布,说明质量投入是按子系统推进的。正文还列出多项结构性工作,例如将代码从旧式 C 接口迁移到更现代的 C++ 风格、补充自动化测试、优化性能、完善文档,以及完成 Mesh 属性存储格式切换等。文章也展示了缺陷分流和 triage 的进展,未分配问题显著下降,说明质量治理不仅是修 bug,也包括流程改进。其边界在于这是项目回顾而非深入技术复盘,很多条目只给出结果和方向,缺少实现细节与量化对比,但仍适合作为开源大型工程做稳定性治理的参考案例。

推荐收录,因为它明确给出了 350+ 缺陷修复、自动化测试补强、代码现代化和 triage 流程改进等直接证据,体现了大型开源项目如何系统性提升质量。适合做开源维护、稳定性治理和技术债清理的参考,但读者需注意它偏项目总结,细节深度有限。

工程实践Lyft Engineering

Trusting the Untestable: Validation and Diagnostics for the Doubly Robust Models

文章介绍 Lyft 如何在无法做随机 A/B 测试时,用 AIPW 这类双重稳健模型评估因果影响,并把“可验证性”作为平台能力来建设。作者重点说明两类输入约束:必须显式选择大量混杂变量,且其数据必须来自首次曝光前,以避免泄漏;同时对下采样带来的倾向得分和结果权重偏差做了校正。文中还给出两类核心诊断:倾向分数重叠/共同支持检验,以及调整前后协变量平衡检查,来判断估计是否可信。为了验证方法本身,作者用周度 ride challenge 的实验数据作 ground truth,与观测数据上的 AIPW/ATET 结果对照,发现观测估计通常偏低,主要原因是 trim 后分析样本不再代表总体。基于这一发现,团队新增了隐藏混杂敏感性分析和 trimmed vs. untrimmed 协变量对比,用于识别外部有效性和未观测偏差的风险边界。

推荐收录,因为文章不仅讲 AIPW 原理,还给出混杂变量管理、共同支持、协变量平衡、敏感性分析等可落地诊断流程,并用实验对照验证偏差来源。适合做因果推断、实验平台和数据科学平台建设参考,尤其对需要在非随机场景下建立可信度的团队很有迁移价值。

职业经验Brendan Gregg

Why I joined OpenAI

这篇文章是 Brendan Gregg 解释自己加入 OpenAI 的个人职业选择与工作动机,核心围绕 AI 数据中心在成本、能耗和规模上的压力,以及性能工程在其中的价值。作者结合与多位从业者、朋友和普通用户交流的经历,说明 ChatGPT 已经成为大众高频工具,这种真实使用场景改变了他对 AI 落地的判断。他还回顾了自己从少年时期想做“Orac”式对话系统,到后来从事数据中心性能工作的长期兴趣脉络,强调自己希望把性能优化方法直接用到 ChatGPT 性能团队。文中也交代了他在 OpenAI 的岗位、远程办公地点、初始项目方向,以及会继续使用 eBPF、Ftrace、PMCs 等手段寻找更大优化空间。整体属于职业决策与岗位展望,而非系统化技术教程,技术细节主要停留在方法与方向层面。

推荐收录,因为文章直接给出了顶级性能工程师选择 AI 公司与岗位的依据:真实用户规模、算力/能耗压力、团队能力和个人兴趣的交汇。适合关注 AI 基础设施、性能工程或职业转型的读者参考,但需要注意它是带强烈个人色彩的叙述,不是可复用的完整方法论。

工程实践Anthropic Engineering

Building a C compiler with a team of parallel Claudes

文章复盘了 Anthropic 研究员用 16 个并行 Claude 实例,从零实现一个 Rust 版 C 编译器的过程。核心不是“让模型写代码”本身,而是设计一个能长期自治的 harness:用无限循环驱动任务推进、通过 git 文件锁避免重复劳动,并让不同代理分工处理测试、文档、性能和代码去重。作者强调,真正决定成败的是高质量测试、可自动判错的日志、以及把问题拆成可并行的小任务;当 Linux 内核编译这种“单大任务”卡住时,又引入 GCC 作为在线 oracle 和抽样测试来恢复并行性。最终产物可编译 Linux 6.9 及多个大型项目,但仍存在 16 位 x86、汇编器/链接器、代码质量和性能不足等边界,说明当前自治编程仍远未“全能”。

有直接工程证据:并行代理、任务锁、测试 harness、GCC oracle 和 CI 共同构成了可复用的方法论。适合做 AI 编程代理、自动化测试与编译器工程的参考,但也明确暴露了自治开发在正确性、效率和边界处理上的风险。

工程实践Yelp Engineering

How Yelp Built a Back-Testing Engine for Safer, Smarter Ad Budget Allocation

文章介绍 Yelp 为广告预算分配系统搭建回测引擎的实践,用于在正式上线前评估调参或策略变更是否会影响广告展示、预算消耗和广告主收益。作者指出该系统存在明显的反馈回路,单点改动可能放大成系统级波动,因此仅看离线指标或局部测试并不足以判断安全性。回测引擎的目标是在历史数据和既有行为假设下重放预算分配过程,尽量提前暴露收益、投放结构和边界条件上的风险。文章强调这种方法适合复杂的广告/推荐类分配系统,但其结论仍依赖历史分布与建模假设,不能完全替代线上实验。

推荐收录,因为标题和导语直接给出了“back-testing engine”和“safer, smarter ad budget allocation”,说明它不是泛泛介绍功能,而是在解决带反馈回路的系统变更评估问题。适合做广告系统、推荐分流或其他预算/流量分配场景的工程参考,尤其可迁移其离线评估与上线风险控制思路。

技术文章Max Bernstein

A multi-entry CFG design conundrum

文章讨论 ZJIT 在编译 Ruby 字节码时遇到的多入口控制流图设计难题。由于 Ruby 默认参数在调用时求值,编译器需要把默认参数逻辑放在被调函数内部,并同时支持解释器入口、JIT 入口和若干默认参数入口。作者展示了这种 HIR 设计如何让 SSA、RPO 遍历和 Cooper 风格支配树算法都变得别扭,因为图里不再存在唯一的起始块。文中系统比较了三种方案:保留特殊处理、合成超级入口块、或按入口复制整张 CFG,并说明复制方案虽然简单但会带来代码膨胀。最终更新里给出团队选择了 superblock/EBB 方案,接受了更复杂的 dominator 与 predecessor 处理,以换取更清晰的入口模型。文章的边界也很明确:结论主要适用于多入口 IR 设计,后续复杂分析仍需继续验证。

收录价值在于它不是泛泛谈“编译器设计”,而是拿真实的多入口函数 IR、支配树失配和三种可选方案做了具体权衡。适合编译器、语言运行时和 IR 设计读者参考,尤其是需要处理入口分裂、默认参数或多返回点的实现者。

职业经验Anthropic Engineering

Designing AI-resistant technical evaluations

文章回顾了 Anthropic 性能工程团队如何设计并多次重做 take-home 面试,以在 AI 辅助普及后仍能区分候选人。原题是模拟加速器上的树遍历优化,要求候选人逐步完成并行化、SIMD/VLIW 利用、调试和工具构建,因此在早期能有效筛出强工程师,也确实招到了多位高绩效员工。随着 Claude Opus 4 和 4.5 在两小时约束内逐步追平甚至超过优秀人类,作者不得不把题目改成更陌生、更受限的谜题式优化问题,并减少那些模型已经轻松掌握的维度。文章总结出评估设计应兼顾真实工作、高信号、足够深度以及对 AI 的开放使用,但也承认越强调“抗模型”越容易牺牲岗位真实性和可解释性。最后作者公开了原始题目作为挑战,并用成绩对比说明人类在无限时间下仍有优势,但在短时约束下可区分性正在迅速下降。

推荐收录,因为文中给出了清晰的直接证据:原始 take-home 曾有效招人,但已被 Claude Opus 4/4.5 在 2 小时约束内追平甚至超越,迫使团队重设评估方式。适合负责面试设计、技术招聘和 AI 时代能力评估的人阅读,可迁移价值在于如何构造高信号任务与识别失效边界。

工程实践Crunchy Data Blog

Postgres Serials Should be BIGINT (and How to Migrate)

这篇文章讨论了 Postgres 中自增主键从 SERIAL/INT 升级到 BIGINT 的必要性,核心理由是 INT 只有约 21 亿上限,而 BIGINT 基本不会溢出。作者进一步说明 BIGINT 在很多行布局下并不比 INT 更占空间,因为 PostgreSQL 的行对齐和填充会抵消所谓的 4 字节节省,因此用 BIGINT 的长期成本通常很低。文章还对比了 UUID 的适用场景,认为跨系统或需要公开暴露 ID 的场景可以选 UUID,但纯数据库序列号未必需要放弃整数。随后给出了一套可在线执行的迁移方案:新增 BIGINT 列、触发器同步、分批回填、定期 VACUUM、并发建唯一索引、处理外键引用表,再在一个短事务里完成 atomic swap。文中也强调了边界条件:需要预留短暂排它锁、先在非生产环境验证批次大小和回填策略,并确保序列、外键和主键约束在切换后都能正确接管。

推荐收录,因为文章直接给出了从 INT 到 BIGINT 的完整 PostgreSQL 迁移链路,包含分批回填、NOT VALID 外键、并发建索引和原子切换等可复用证据。适合负责数据库演进、线上改表或容量规划的后端/DBA 读者,主要价值是把一次高风险 schema 变更拆成可验证的操作步骤。

技术文章Crunchy Data Blog

PostGIS Performance: Simplification

这篇文章围绕 PostGIS 中“几何简化”展开,比较了多种常见方法在点数压缩、形状保真和有效性上的差异。作者先用 ST_Letters、ST_Segmentize 和 ST_RemoveRepeatedPoints 构造出可观察的测试图形,再依次展示 ST_Simplify(Douglas-Peucker)、ST_SimplifyVW(Visvalingam-Whyatt)、ST_SnapToGrid 与 ST_ReducePrecision 的效果。文章指出,Douglas-Peucker 更偏向折线压缩,VW 在多边形形状保留上通常更好,而简单网格吸附虽能统一精度却容易产生无效多边形。相较之下,ST_ReducePrecision 在固定精度与几何有效性之间提供了更稳妥的折中。最后还补充了 PostGIS 3.6 新增的覆盖面处理能力:先用 ST_CoverageClean 清理共享边界,再用 ST_CoverageSimplify 对相邻面集合整体简化,适用于需要边界一致性的专题图或覆盖数据。

文章直接比较了多种 PostGIS 简化函数的输出差异、有效性风险和适用场景,不是泛泛介绍 API。对做空间数据处理、地图渲染或数据库性能优化的读者很有参考价值,尤其适合需要在精度、合法性和边界一致性之间做取舍的工程场景。

个人心得Brendan Gregg

On "AI Brendans" or "Virtual Brendans"

文章围绕“AI Brendan/Virtual Brendan”这一类性能工程智能体展开,先区分两种概念:一类是基于火焰图、eBPF 指标和历史案例做模式匹配、帮助定位问题的辅助代理;另一类则是试图用作者公开的讲稿、博客和工具训练出一个“虚拟 Brendan”。作者认为前者确实有价值,能加速已见问题的分析与修复,但后者只能覆盖性能工程工作中约15%的内容,且会受到公开资料不完整、知识快速过时和无法处理未知问题的限制。文章进一步分析了商业化难点,包括按单实例收费后被复制到全机房、秘密调优会破坏变更控制、效果很难量化,以及上游修复会持续削弱产品优势。作者还回顾了从 Virtual Adrian、TuneD、bpftune 到 Granulate/Intel 的历史,认为更现实的形态是企业内部工具或开源协作,而不是“卖一个完整的人”。

推荐收录,因为文章直接给出了性能工程 AI 代理的适用边界:它们适合处理已见问题、火焰图和指标匹配,但不足以替代完整的性能工程判断。对做 AIOps、观测平台、自动调优工具和 AI 产品商业化的人尤其有参考价值,文中关于定价、变更控制和上游回流的风险分析也很可迁移。

技术文章Brendan Gregg

Third Stage Engineering

文章提出一个关于计算机性能评估的“三阶段火箭”比喻:硬件只是第一阶段,软件适配是第二阶段,真正拉开差距的是第三阶段的调优。作者指出,很多厂商和外部评测只比较裸硬件性能,却忽略了面向特定工作负载的软件栈选择、编译/运行时优化以及参数配置,这会导致对真实生产表现的误判。文中把“third-stage engineering”拆成人员、培训、工具和调优能力四部分,强调需要能做观测分析与实验验证的团队,才能把系统性能推到更高水平。其核心结论是:面向客户和生产环境的性能判断,必须同时看硬件、软件与调优三层,而不是只看单点基准。文章更偏方法论与认知框架,适合做性能评测、系统优化和硬件选型时的长期参考。

推荐收录,因为文章直接指出了“只看硬件”会导致性能评测失真,并明确给出了软件适配与第三阶段调优的分析框架。对做基准测试、平台选型、性能优化和供应商评估的读者都很有迁移价值,但它更偏观点总结,缺少具体实验案例与量化数据。

工程实践Go Blog

The Green Tea Garbage Collector

文章介绍 Go 1.25 中实验性垃圾收集器 Green Tea 的设计与落地。作者先回顾 Go 现有的标记-清扫 GC,指出其主要成本集中在标记阶段,而且大量时间浪费在指针追踪带来的随机内存访问和 CPU 缓存失配上。Green Tea 的核心改动是“按页而不是按对象”组织工作队列:在页级别积累待扫描对象,用 seen/scanned 位图在页内区分已发现和已扫描的对象,从而把零散遍历变成更连续的内存扫描。文章进一步说明它如何借助 AVX-512 和 VGF2P8AFFINEQB 等指令做位图扩展与筛选,把多个步骤压缩到寄存器内完成。实测显示,多数负载可减少约 10% 的 GC CPU 时间,部分负载可达 40%,但结构很不规则、每页常只出现单个待扫对象的场景收益会变小甚至可能回退,因此仍是一个依赖工作负载形态的优化。

推荐收录,因为文章给出了 Go 运行时 GC 的具体瓶颈、页级扫描的新算法、位图与向量化实现细节,以及在生产环境中的量化收益,证据充分且可迁移性强。适合关注运行时、性能优化、缓存友好数据布局和指令级加速的读者;同时也提醒读者该方案对负载形态敏感,实验性开关阶段仍需做基准验证。

工程实践Blender Developers Blog

Geometry Nodes Workshop: September 2025

这篇 Blender 开发者博客总结了 2025 年 9 月 Geometry Nodes 工作坊的设计讨论,重点回顾了 Blender 5.0 前后的节点系统演进。文章覆盖了 closures、bundles、列表、体积网格、UV Tangent 等已落地或实验中的能力,并说明了哪些改进已进入主线、哪些仍在设计中。核心议题集中在几类长期架构问题:如何用 bundle 表达物理世界并驱动求解器、如何把复杂结果从几何修改器输出到其他对象、以及如何改进节点编辑器在缩放和默认输入下的可读性与可组合性。文中还讨论了 XPBD 毛发/物理解算、BVH 与 SDF 碰撞取舍、默认输入可复用方案、以及面向多对象和模态节点工具的执行模型。整体上它更像一次开放式工程设计复盘,信息密度高,但不少方案仍处于原型或未定稿阶段,适合关注 Blender 节点架构与图形工具链演进的读者参考。

收录依据明确:文章直接给出 Geometry Nodes 的设计取舍、实现路径和 5.0 版本进展,而不是功能宣传。适合图形工具、DCC 插件和节点式系统设计读者,尤其可借鉴 bundle、求解器接口和节点编辑器交互的架构思路。

工程实践Blender Developers Blog

Volume Grids in Geometry Nodes

这篇文章介绍了 Blender 5.0 在 Geometry Nodes 中引入 volume grids 的设计与实现,使体数据不再只是与几何体互转的中间格式,而可以被直接编辑、采样和组合。作者解释了 grid 作为带数据类型的体素容器如何依托 OpenVDB 存储,并通过变换、背景值、active 状态和 tile 分层来兼顾稀疏性与性能。文中还说明了 fields 与 grids 的边界:field 是可在任意位置求值的函数,grid 是离散数据容器,二者通过 Field to Grid、Sample Grid 等节点互相转换。基于这一机制,Blender 5.0 可以支持 SDF 建模、布尔运算、平滑、advect、curl/gradient 等体积操作。文章也坦承这一设计经历了多年迭代,早期按命名属性访问 grid 的方案因复杂而被放弃,最终改为 grid socket,以换取更清晰的模型和更好的可扩展性。

收录价值明确:文章直接给出了体积网格的数据结构、字段求值边界、OpenVDB 稀疏存储和节点设计的具体证据,而不是只做功能宣传。适合图形学、DCC 工具和体积建模读者参考,其关于接口重设计与长期迭代取舍的经验也有较强可迁移性。

工程实践Datadog Engineering

From hand-tuned Go to self-optimizing code: Building BitsEvolve

文章介绍 Datadog 如何把 Go 热路径上的人工性能调优,抽象为一个可持续运行的自优化系统 BitsEvolve。作者围绕热点识别、候选优化生成、自动基准验证、收益评估与安全护栏,构建了 AI 辅助的连续优化流程,使性能改进不再完全依赖手工介入。文中强调,这种方法更适合重复出现、可量化收益、且回归风险可控的局部优化问题,而不是任意复杂业务逻辑。最终该系统在真实线上场景中节省了数千个 CPU core,体现出把性能优化工程化、平台化的价值。其适用边界也很明确:必须有稳定基准、可观测指标和严格回滚机制,否则自动优化可能放大风险。

收录依据很直接:标题与简介明确给出“self-optimizing code”“AI-assisted performance improvements”和“saved thousands of cores”,说明这是可落地的性能工程案例,而非概念展示。适合做 Go 服务、基础设施和成本优化的参考,尤其对需要把热点优化自动化、平台化的团队有迁移价值。

工程实践fasterthanli.me

Making our own spectrogram

文章以“自己实现一个频谱图”为目标,先说明频谱图如何把声音波形分解为不同频率,再把结果映射成随时间滚动的可视化图像。作者并没有只停留在概念层面,而是结合自己的 Rust 应用,讲解了项目由哪些 crate 组成、音频线程与图形线程如何协作,以及数据如何从采集、分析到绘制流转。文中重点不只是“怎么画出来”,还包括实时处理时的组织方式、线程分工和界面刷新策略,体现出一个可运行工具的整体结构。它更偏向具体实现与工程组装,而不是纯理论推导,因此对理解音频可视化管线很有帮助。边界在于文章主题集中在作者这套实现上,读者若要迁移到其他语言或更专业的 DSP 场景,还需要补充信号处理基础。

文中直接给出了频率提取、Rust crate 组合、音频/图形线程协作和绘制流程,证据明确,不是泛泛展示效果。适合做音频可视化、实时图形或 Rust 工程实现的参考,但迁移到更严肃的 DSP 场景时仍需补足信号处理细节。

技术文章Blender Developers Blog

Bundles and Closures

这篇文章介绍了 Blender 5.0 为 Geometry Nodes 引入的两类新 socket:Bundles 和 Closures。Bundles 用于把多个值、几何体、字段、对象等打包成一个连接,作用类似程序里的结构体,便于把复杂状态作为整体在节点组中传递。Closures 则允许把一段可注入的自定义逻辑作为参数传入节点组,例如把树木散布策略外置为可替换的分布函数,从而让高层节点工具获得更强的可组合性与声明式表达能力。文章同时说明了 pass-through、值捕获、名称同步、socket inspection 等机制,以及当前调试和多处求值带来的局限。最后还展望了这些能力向输入组件、物理模拟、着色器和合成器扩展的可能性,但也强调部分功能仍在实验中,且 inline 方案存在迭代次数等约束。

推荐收录,因为文章明确讲清了 Bundles/Closures 的设计动机、工作机制和已知限制,并给出了可扩展到物理、着色和合成器的路线。适合关注图形系统、节点式编程和声明式工具设计的读者参考,其价值在于抽象出可迁移的接口组合与可定制计算模型。

工程实践Blender Developers Blog

New Socket Shapes

这篇文章解释了 Blender 5.0 重设计 Geometry Nodes 端口形状的原因与方案。旧方案用圆形、菱形和带点菱形同时表达“单值”“字段”以及“当前链接状态”,但面对列表、体积网格等新数据结构时信息过载且含义模糊,尤其带点菱形难以理解。新设计改为让形状只表达节点“期望/生成”的数据结构:竖线表示单值,菱形表示字段,圆形表示动态类型,网格/列表形状则对应仍在开发中的新结构。文章还说明了分组输入输出可自动推断并允许覆盖,虚线链接继续表示字段传递,tooltip 用于补充默认值等细节。它承认新方案会丢失部分旧信息,但认为这是为引入 volume grids、lists 以及未来更多节点能力所必须的权衡。

推荐收录,因为文章给出了从旧交互符号到新语义映射的完整设计依据,明确展示了“信息表达能力”与“可扩展性”之间的取舍。对节点编辑器、可视化语义设计和开源产品演进的读者都有直接参考价值,尤其适合做界面符号系统和数据结构表达设计的复盘。

工程实践Blender Developers Blog

Blender for Windows on Arm

这篇文章回顾了 Blender 在 Windows on Arm(WoA)上的移植与加速进展,说明该项目在 Microsoft、Linaro 和 Qualcomm 的合作支持下,已能在 Snapdragon 等 ARM64 Windows 设备上稳定运行。文章重点介绍了从 Blender 4.3 开始的官方 WoA 支持,以及在 4.5 LTS 中引入 Vulkan 后,EEVEE 视口播放和渲染性能得到显著提升。作者还给出了针对 Adreno GPU 的基准测试,显示 Vulkan 相比 OpenGL 在不同示例场景下有明显收益,尤其是播放帧率和渲染耗时改善突出。文中进一步指出,当前优化重点仍在着色器优化、Adreno 瓦片架构利用和 UI 性能,长远目标是到 2026 年为 Snapdragon GPU 上的 Cycles 提供硬件加速光追。整体来看,这是一篇围绕跨平台图形栈迁移、驱动适配与性能验证的工程案例,但结论主要适用于具备 Vulkan 和特定 ARM GPU 支持的环境。

推荐收录,因为文章给出了 WoA 移植、Vulkan 后端切换和实际基准数据,能直接看到图形应用在 ARM Windows 设备上的性能收益与边界。适合做跨平台图形开发、GPU 适配和开源工程协作的参考,但其结论强依赖 Blender、Adreno 和 Vulkan 生态。

工程实践Datadog Engineering

How Go 1.24’s Swiss Tables saved us hundreds of gigabytes

文章介绍 Datadog 在 Go 1.24 引入 Swiss Tables 后,对内部高流量服务中的 map 内存占用和性能收益做的实测复盘。作者说明旧版 Go map 在某些业务场景下会带来较高的内存开销,而新实现通过更紧凑的布局和更高效的查找方式,能在 map 密集型工作负载中把内存使用降低最高约 70%。文中重点不是泛泛宣传新版本,而是展示他们如何用 profiling 和线上指标确认收益、识别适用场景,并把改动控制在可验证的范围内。文章也暗示这类收益依赖键值分布、访问模式和业务负载,并非所有程序都会得到同等改善。

推荐收录,因为它给出了明确的工程证据:围绕 Go 1.24 Swiss Tables 的真实工作负载剖析、内存节省幅度和性能验证,而不是停留在版本公告。适合关心 Go 运行时、服务内存优化和性能排障的工程师参考,尤其适合把“新 runtime 特性是否值得升级”转化为可测量、可回滚的决策流程。

科研议题BAIR Blog

Scaling Up Reinforcement Learning for Traffic Smoothing: A 100-AV Highway Deployment

这篇文章介绍了伯克利团队将强化学习用于“交通平滑”的研究,并把训练出的控制器部署到 100 辆车上做真实高速公路实验。作者针对 stop-and-go 交通波,先基于 I-24 实测轨迹构建数据驱动仿真,让 RL 代理在混合交通中学习控制自车速度或期望车速,以同时优化能耗、通行效率、安全与驾驶舒适性。文中重点讨论了奖励函数设计的难点:如果只追求节能,策略会产生不合理停车,因此需要动态间距约束和对周围人类车辆油耗的惩罚。随后,团队通过分层控制框架把模型接入量产车 ACC,在无显式车车通信、仅依赖本车与前车局部信息的条件下完成上路验证。实验结果显示,在最拥堵场景中,仿真可带来最高约 20% 的整体节能,实测也观察到 15% 至 20% 的能耗下降趋势;但文章也明确指出,仿真到现实的差距、更加准确的人类驾驶建模以及未来协同通信仍是后续关键问题。

收录价值在于它不仅讲 RL 原理,还给出了从数据驱动仿真、奖励设计到 100 车实车验证的完整研究链路,证据充分且可复用。适合关注强化学习落地、自动驾驶控制和 sim-to-real 研究的读者,尤其值得参考其局部观测、分层控制与安全约束的工程化思路。

工程实践Stanford Hazy Research

ThunderMittens For Your ThunderKittens

文章记录了 Stanford Hazy Research 将 ThunderKittens 这一面向 NVIDIA GPU 的 AI kernel DSL 移植到 Apple Silicon/Metal 的过程,并把新版本命名为 ThunderMittens。作者先分析了 M2 Pro 的硬件特征:内存带宽相对算力更高、共享内存收益有限、bf16 编译优化不稳定、占用率对性能影响很大,因此更适合用直接寄存器加载和更简单的 kernel 组织方式。移植时,用户侧几乎只需把基础 tile 从 16x16 改成 8x8;内部则删去 swizzling、WGMMA/TMA 和异步读写等 NVIDIA 特定机制,并通过不同寄存器布局适配 Metal 指令。文中给出 GEMM 与注意力推理 kernel 的实现片段,说明 DSL 抽象在不同硬件上基本保持稳定,但具体优化手段会随平台变化。性能上,注意力 kernel 与 MLX 相差约 ±15%,GEMM 在多数尺寸上快约 9%,同时代码行数显著减少,但作者也承认当前仍处早期阶段,且调试依赖反复试验与 Xcode GPU 工具。

收录依据很直接:文章不仅给出跨平台 kernel 迁移的设计原则,还提供了具体实现、硬件约束和性能数据,能支撑读者判断 DSL 在异构 GPU 上的适用性。适合做 AI 系统、GPU kernel 和编译/DSL 设计的长期参考,但需要注意其结论主要基于 M2 Pro 与特定 kernel,泛化到其他平台仍需验证。

工程实践Stanford Hazy Research

ECLAIR: A Treat for the Enterprise

这篇文章介绍了 Stanford Hazy Research 提出的 ECLAIR 系统,目标是用多模态基础模型自动化企业中的复杂工作流,替代传统 RPA 依赖硬编码规则、搭建成本高、易失配且维护昂贵的问题。作者将自动化流程拆成 Demonstrate、Execute、Validate 三个阶段:先通过录屏、点击和键盘轨迹以及文档学习人工经验,再在执行时依据屏幕状态和 SOP 选择动作,最后利用行动轨迹自我审计并纠错。文章以斯坦福医院 Epic 系统中的 telesitter 下单流程为真实案例,展示了从任务采集到全自动执行与验证的闭环。它强调 ECLAIR 是面向企业工作流自动化的第一步,而非最终方案,当前仍需要更好的错误处理、监控机制,以及对必须人工签署的场景引入 human-in-the-loop。整体来看,这是一篇兼具研究原型和工程落地讨论的系统介绍,适合关注 AI 工作流、RPA 演进和企业软件自动化的读者参考。

收录依据很明确:文章给出了企业工作流自动化的系统设计、真实医院场景案例,以及对 RPA 三类失败模式的具体分析,不是泛泛的产品宣传。适合做 AI Agent、企业自动化和人机协同系统设计的参考,但读者也应注意其仍是原型阶段,距离大规模企业级可靠部署还有验证和治理边界。

工程实践PlanetScale Blog

Summer 2023: Fuzzing Vitess at PlanetScale

文章记录作者在 PlanetScale 实习期间,为 Vitess 查询规划器设计随机 SQL fuzzing 的过程。团队先评估了 SQLancer,但由于 Vitess 需要尽量模拟 MySQL 且受 VSchema、分片键等约束,直接接入成本过高,最终转向自建生成器。生成器会从给定表集合中随机抽取表、列和表达式,覆盖 SELECT、WHERE、GROUP BY、ORDER BY、LIMIT 及派生表等场景,并把 Vitess 与 MySQL 的结果和错误逐条比对。作者还改造了查询简化器,使其能处理端到端测试所需的 VSchema 信息,并扩展表达式生成以支持列引用和受语义限制的聚合表达式。文章最后指出当前样例表和分片方案仍较固定,且部分已知失败查询依赖过滤开关,后续可通过随机化 schema/VSchema 和清理代码继续提升覆盖率。

收录理由明确:文章给出了在数据库查询规划器上做 fuzzing 的具体实现、与 SQLancer 的取舍、以及查询简化器和表达式生成器的改造细节。适合做数据库测试、查询优化器或模糊测试实践参考;其局限也清楚,当前覆盖仍受固定 schema 和分片模型限制。

工程实践Datadog Engineering

.NET Continuous Profiler: Exception and lock contention

文章讲解 Datadog 在 .NET 连续性能分析器中,如何识别并处理异常与锁竞争这两类对性能影响很大的运行时事件。作者先说明连续采样式 profiler 的约束:既要尽量低开销,又要在高频事件下保留足够语义,因此不能简单依赖传统的堆栈采样。随后分别讨论异常与锁竞争的采集思路、事件归因方式,以及如何把运行时信号映射成可分析的性能数据,同时避免对应用造成过多扰动。文中也强调这些机制依赖 .NET 运行时能力与事件可见性,适用于需要在线观测异常风暴、锁争用和尾延迟问题的场景,但对非 .NET 平台的直接迁移有限。整体来看,它提供的是一篇围绕真实产品实现的 observability 工程经验,而不是泛泛介绍 profiler 概念。

推荐收录,因为文章直接围绕连续 profiler 的实现细节展开,明确讨论了异常与锁竞争的采集、归因和低开销约束,属于可复用的工程方法而非产品宣传。适合做 APM、性能分析、运行时观测和 .NET 工具链设计的参考,但需要注意其方案强依赖 .NET 运行时特性,跨语言迁移时要重新评估事件模型。

工程实践Datadog Engineering

.NET Continuous Profiler: CPU and wall time profiling

这篇文章介绍了 Datadog 在 .NET 连续 профiler 中实现 CPU profiling 和 wall time profiling 的方法。作者不仅说明了两类采样各自回答的问题,也分析了它们在低开销、跨线程、跨运行时边界下的实现约束。文中重点讨论了如何持续获取调用栈、如何区分真正占用 CPU 的时间与线程阻塞或等待造成的 wall time,以及这些数据如何帮助定位性能瓶颈。文章还指出,连续剖析必须在精度、性能损耗和运行时安全之间折中,因此采样间隔、信号处理和线程状态判断都会影响结果。它更适合关注性能分析、运行时观测和 profiler 设计的读者,尤其对 .NET 服务的线上诊断有参考价值,但不适合作为通用入门教程。

文中直接讲了 .NET 连续 profiler 的 CPU 与 wall time 实现细节,不是产品介绍,而是可复用的观测与采样设计经验。适合做性能诊断、运行时工具或可观测性基础设施的读者参考,尤其能借鉴其在开销、精度和线程安全之间的取舍。