技术文章 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 对比部分存在产品宣传倾向。