DZone.com Feed 中文 关注 DZone是一个全面的在线平台，专注于技术和编程的多个方面。该网站提供了关于不同编程语言、技术、框架和工具的大量信息。该网站的一些主要特点和资源包括：关于技术领域最新趋势和更新的新闻和文章、学习不同编程技能的多种资源和教程、一个社区让用户可以与他人互动、分享经验和知识。此外，DZone还提供了技术专业人士的招聘信息，为对技术和编程感兴趣的人们提供了有用的资源。 DZone.com Feed dzone.com RSS feeds.dzone.com DZone.com Feed 中文 RSS thenote.app
人工智能辅助产品发现 TL; DR：代码不再构成约束后，“决定构建什么”已成为新的核心工作。代理式编程（Agentic coding）消除了过去阻碍产品团队同时追逐所有创意的成本门槛，而约束已转移至产品判断力：即辨别哪些值得构建的能力。AI 辅助的产品发现能够通过阅读远超任何产品人员所能处理的客户证据来培养这种判断力。此类发现代理会分析三大类来源、检查八种模式，并对您当前的方向既提出反对意见也提供支持。A3 框架为这项工作赋予了名称：Assist（代理负责分析与准备），人类负责决策。该框架还通过 A3 交接画布（A3 Handoff Canvas）帮助界定代理的边界——明确代理做什么、人类做什么、使用哪些数据等——并在首次运行前，通过 AI 完成定义（AI Definition of Done）明确高质量 AI 输出“应具备何种形态”。 AI-Assisted Product Discovery dzone.com +1
选择BBD框架 几年前，我参加了一次冲刺评审会，一位产品经理和一位资深开发人员就工单中的一行内容争论了二十分钟：“用户可以重置密码。”开发人员已按此实现。产品经理期望在三次失败尝试后触发账户锁定，并包含邮件确认及一小时过期的链接。双方都没有错，只是脑海中各自有不同的图景，而工单从未迫使任何人将其画在纸上。正是人们所言与所意之间的这种差距，催生了行为驱动开发（BDD）。这也说明，选择 BDD 工具并非主要关乎功能特性，而更多关乎团队如何沟通。 Choosing a BBD Framework dzone.com +1
你需要了解的关键机器学习分类指标 准确性是许多初学者在构建机器学习模型时首要关注的指标。试想一个用于检测皮肤病的模型：测试数据集包含 10,000 名患者，其中仅 100 人患病，其余均为健康。该模型最终将所有患者预测为健康，从而得出 99% 的准确率，听起来令人印象深刻，但却未能识别出任何一名患病患者。现在，设想在真实世界中部署该模型，却盲目信赖其准确率，这将导致灾难性后果，因为在测试阶段它甚至未能识别出一名患病者。这就是为什么模型即使在测试阶段表现出令人印象深刻的准确率，仍可能在真实世界中失效的原因。要真正理解模型在现实生活中的行为，我们需要关注超越准确率的指标。 Key ML Classification Metrics You Need to Understand dzone.com +1
控制器与数据访问：通过抽象与封装理解两层架构 并非所有现实世界的应用都需要完整的整洁架构，包括其多层结构、依赖倒置和严格的领域边界。许多生产系统——尤其是内部企业应用，如人力资源管理系统（HRMS）和薪酬平台——能够在更简单、更务实的两层架构上成功运行：控制器层（Controller layer）和数据访问层（Data Access layer）。理解这种更简单的结构为何有效，以及它如何与整洁架构背后的相同面向对象原则相关联，有助于我们在任一类代码库中更自信地开展工作。 Controller and Data Access: Understanding Two-Layer Architecture Through Abstraction and Encapsulation dzone.com +1
为热键设计：当分布式系统停止分布时 分布式系统通常通过对键进行哈希并将数据分散到各个节点，以确保没有单个节点承担全部负载。热点键打破了这一假设。热点键是指在给定时间段内，其访问量远超其他键的键。全局视图计数器或热门物品标识符每秒可能承受数百万次读或写请求。即使集群其余部分仍有空闲容量，每个请求仍会指向同一个分区。其结果是负载不均。某个节点可能达到其 CPU、网络、线程或连接限制，而其他节点却利用率不足。增加节点并不能解决问题，因为流量仍会解析到同一个分区。过载的分片将成为本应分散工作的系统的瓶颈。 Designing for Hot Keys: When Distributed Systems Stop Distributing dzone.com +1
从数据库变更到大规模实时操作：Oracle GoldenGate 与 Java DB 变更可通过 Oracle GoldenGate 以实时流方式传输。Java 应用程序可消费这些变更，从而在不轮询数据库的情况下验证/响应/路由事件。目标：监听数据库中的实时事务，对事务内的所有操作执行相应动作，并维持接近实时的 SLA 以保障事务边界。 From Database Changes to Real-Time Actions at Scale: Oracle GoldenGate and Java dzone.com +1
AI 并未取代软件工程，而是改变了瓶颈” AI 已大幅降低了代码生成的成本。但软件工程不仅仅是代码生成。随着实现速度的提升，真正的瓶颈已转移至规划、架构设计、评审、测试、部署以及长期维护。那些仍仅以编码速度为优化目标的团队，最终会发现自己在修复本可预防的问题上花费了更多时间。速度改变了工程时间的分配方式历史上，与变更和软件重构相关的成本极为高昂。然而，AI 使组织能够以惊人的速度推进。在数量级上，工程工作此前所需的努力远超软件开发生命周期（SDLC）的任何其他阶段。但 AI 创造了一种新现实：工程师能够快速构建，从而降低了部分变更成本。 AI Didn't Replace Software Engineering; It Changed the Bottleneck dzone.com +1
7 个 Swift 功能，让你明天就能删除代码 每年，Apple 的"What's new in Swift"环节都会推出三十分钟的新语言特性，而每年的回顾文章都会按照它们在舞台上出现的顺序列出。这种排序是为了 keynote 优化，而非为了你的冲刺。本次排序有所不同。对每个特性的追问只有一个：它距离我明天就能打开的 diff 有多远？其中一些只是一行改动，能删除你自 2021 年以来一直心怀歉意的 hack；另一些则功能强大、设计精良，但不会在一年内触及你的应用代码。两者都值得理解，但只有一个值得创建工单。 7 Swift Features That Will Let You Delete Code Tomorrow dzone.com +1
2026 年使用机器学习检测重复项：从字符串度量到嵌入和大型语言模型 数据公司收集的客户、产品及代码数据越多，重复信息就越会不断累积，令依赖这些数据的团队感到困惑。人们不会手动处理数百万条记录，因此去重如今已成为一个机器学习问题。本文探讨了当前机器学习系统中重复检测的现状：哪些传统技术依然有效，以及嵌入表示和大语言模型带来了哪些新进展。机器学习系统如何检测重复项？人类可以查看两张图片或两个字符串，并判断它们是否相同。但要教会机器做同样的事，却会引发诸多难题。什么是“相似”？相似度是有程度之分的。那么，“Jon Smith, 12 Oak St.”与"Jonathan Smith, 12 Oak Street"算不算同一位客户？ Detecting Duplicates With Machine Learning in 2026: From String Metrics to Embeddings and LLMs dzone.com +1
静默失败的公共数据摄入：来自 TypeScript 与 Cloudflare Workers 管道的模式分析 摘要公共统计数据集极少真正报错。当出现问题时，它们往往返回一个看似合理的数值、一个状态为成功的 HTML 页面，或是一个已悄然停止更新的时间序列。本文描述了一个住宅混凝土成本估算器的数据摄入管道，该管道整合了四个公共数据集：年度职业工资调查、月度生产者价格指数、2022 年材料价格行业基准，以及邮政编码至都市区映射表。针对每个数据集，我记录了实际观察到的故障模式、相关证据，以及将其转换为显式状态的 TypeScript 代码。核心主张是：每一次静默故障都应转化为一个带类型的值，并伴随数值一路传递至用户界面。该管道在本地 CLI 和定时调度的 Cloudflare Worker 上运行，写入 Cloudflare D1，并托管静态网站。 Ingesting Public Data That Fails Silently: Patterns From a TypeScript and Cloudflare Workers Pipeline dzone.com +1
使用 Foundry、Azure AI Search 和 Cosmos DB 构建基于上下文的搜索代理，并通过 Docker 进行容器化部署，利用 Grafana 进行观测 为何“搜索”已不再足够一个简单的 RAG 流水线——对查询进行嵌入、检索向量索引、将前 k 个片段填入提示词——对于单轮 FAQ 机器人而言尚能胜任。但一旦需要以下能力，该方案便会失效：多轮对话记忆（例如“上个季度怎么样？”需要系统理解“上个季度”的具体指代） 是否执行搜索的决策（某些问题属于结构化数据查询，而非文档检索） 用户可验证的引用来源本文构建了一个虽小但完整的基于事实的搜索智能体：通过 Microsoft Foundry 调用 Azure OpenAI 以决定何时调用搜索工具，何时调用结构化数据工具；Azure AI Search 负责在非结构化文档上执行检索与语义排序；Azure Cosmos DB 则用于存储对话状态及结构化订单/客户元数据。该智能体利用 OpenAI 函数调用机制在两个数据源之间进行路由，并始终返回引用来源。 Building a Grounded Search Agent With Foundry, Azure AI Search, and Cosmos DB, Containerized With Docker and Observed With Grafana dzone.com +1
使用自定义 SOAP 处理器在 JAX-WS 服务调用之间保持 Cookie 持久性 《永不返回的 Cookie》第一次调用成功验证了用户身份。第二次调用却失败了。我正在集成一个由客户提供的 SOAP 服务，该服务通过单个 WSDL 暴露，并使用 IBM Rational Application Developer 根据 WSDL 及其 XSD 生成的 JAX-WS 客户端类。第一次调用验证了用户身份，并返回了 Set-Cookie 响应头。随后的每一次调用都需要该 Cookie。然而，生成的客户端并未携带任何 Cookie。每次调用都表现为一次独立的会话，导致工作流在第二步中断。没有抛出异常，也没有发出警告。服务器只是忘记了你是谁。 Persisting Cookies Across JAX-WS Service Calls Using a Custom SOAP Handler dzone.com +1
使用 Angular、Spring Boot、SSO 和 MFA 构建企业级身份认证 在企业级应用中，尤其是使用 Angular 和 Spring Boot 等框架时，认证并非简单的附加功能，而是根本性的架构考量。实现单点登录（SSO）和多因素认证等功能会显著影响整个应用的工作方式。SSO 看似简单，却要求前端适配新的认证流程。应用必须引入路由守卫，以确保在组件加载前用户已获得授权。处理与身份提供商之间的重定向需要维护应用的预期状态。此外，前端必须优雅地处理令牌过期，将其视为一种标准且预期的情况，而非异常。这些复杂性表明，认证决定了核心前端架构，影响路由管理和状态处理。它从根本上改变了应用内部的工作机制，而不仅仅局限于登录界面。因此，认证应在开发初期阶段进行集成，而非作为事后补充。 Building Enterprise Authentication with Angular, Spring Boot, SSO, and MFA dzone.com +1
三大世界之最：用 Rust 和 Java 编写的 AI 代理击败了 C 语言库 任何接受照片上传的应用迟早都会遇到 HEIC 格式。iPhone 默认以该格式保存。Java 和 Rust 均无法原生读取 HEIC，而通常的解决方案 libheif 是一个 C 库：需要在每个容器镜像中集成原生包，构建环境中需包含 C 工具链，并由 C 编写的解析器去读取陌生人上传的文件。我曾两次遇到这个问题，一次在 Java 产品中，另一次在 Rust 项目中。因此我采取了另一种方案：用目标语言本身编写解码器，由 AI 编码代理构建并优化，由我来把控方向。以下是具体过程。 Best of Three Worlds: AI Agents Writing In Rust and Java Beat the C Library dzone.com +1
LLM 提示缓存，第三部分：模型端缓存与生产部署 回顾：本系列内容的定位本系列第一部分介绍了精确匹配缓存，第二部分介绍了语义缓存。两者均位于模型之前，命中时可直接跳过模型调用。本文探讨那些仍到达模型的请求如何处理：复用已计算的模型状态，无论是在您自己的推理引擎中，还是在 API 提供商的系统内，同时涵盖将缓存方案转化为团队可实际运行并信赖的生产环境所需的关键细节。第 3 层和第 4 层是同一基本理念的两个版本，即复用已计算的模型状态，区别在于由谁运行模型服务器。如果您自行运行 GPU，则适用第 3 层；如果您调用托管 API，则适用第 4 层。对于同一模型调用，通常无需同时使用这两层。 Prompt Caching for LLMs, Part 3: Model-Side Caching and Production Rollout dzone.com +1
为什么刮除管道会在生产中中断 生产代码会接受审查。构建过程会被监控，库文件会检查是否存在已知漏洞，且当服务在夜间发生故障时，总有人需要负责。而负责拉取外部数据的工作通常能逃避所有这些审查。它最初只是一个快速脚本，随后被调度运行，此后便无人触碰。它没有测试用例，唯一的错误处理机制是一个捕获所有异常的块，而其作者可能早已离开团队。 Why Scraping Pipelines Break in Production dzone.com +1
带有 Microsoft Fabric Eventhouse、KQL、Docker 和 Grafana 的 Microsoft Foundry Agent 调试仪表板 在 Microsoft Foundry 中构建的代理（agent）在单次运行中会做出多项决策：调用模型、选择工具、读取工具结果，并再次调用模型。当回答缓慢或错误时，问题根源往往隐藏在该序列的某个环节之中，而最终响应无法提示具体是哪一步失败。Foundry 将该序列记录为 OpenTelemetry 追踪（traces）。默认情况下，托管代理会将这些追踪发送至 Application Insights，这是一个良好的起点。然而，对于每天构建代理的团队而言，仍存在两个缺口。第一个缺口出现在开发阶段：开发者在修改提示词（prompt）或工具后，希望在本地笔记本电脑上，无需部署项目，即可在数秒内查看该单次运行的跨度（spans）。第二个缺口出现在部署之后：代理所有者需要一个共享仪表板，展示运行次数、延迟百分位、令牌用量、工具延迟及错误信息，并希望能使用与其余数据相同的语言查询原始跨度。 Microsoft Foundry Agent Debugging Dashboard with Microsoft Fabric Eventhouse, KQL, Docker and Grafana dzone.com +1
EKS 上的 Kafka 消费者：设计一个能够重启消费者组的平台 这些是真正会触发告警的故障模式，以及能够阻止它们的枯燥修复方案。Kafka 消费者是一种基于成员协议构建的状态化客户端。它加入一个组，接受分区分配，按序处理记录，并通过固定频率的心跳和轮询调用证明其仍然存活。组所提供的每一项保证——有序处理、负载均衡、每个分区恰好有一个所有者——都依赖于在数据流经该组的过程中，成员关系保持稳定。 Kafka Consumers on EKS: Designing for a Platform That Restarts Your Consumer Group dzone.com +1
Gitember：构建超越提交、推送和拉取的 Git 客户端” Git 在现代软件开发中发挥着关键作用。然而，大多数 Git 图形界面工具仍侧重于相同的基本操作：暂存、提交、分支、合并、拉取和推送。这些操作固然重要，但它们仅涵盖了开发者日常工作中的一部分。 Gitember: Building a Git Client Beyond Commit, Push, and Pull dzone.com +1
如何（以及为什么）构建动态数据管道 AI 正在改变我们的编码方式。上周，一位朋友告诉我，他完成了一个向表中添加新列的用户故事，并在不到一小时内完成了测试。上游团队现在能在几天内交付曾经需要数月的变更。对于这些位于快速移动系统下游的数据管道，这种速度构成了新的设计约束。一种潜在的解决方案是构建能够跟上节奏的动态数据管道。 How (and Why) to Build Dynamic Data Pipelines dzone.com +1
将网页抓取工具视为生产服务 大多数团队将损坏的网络爬虫视为一项繁琐任务：有人发现数据异常，在浏览器中打开页面，修补选择器，然后重新部署。当只有一个爬虫且有人每日查看其输出时，这种方式可行；但当爬虫数量达到十几个，而损坏在一周后才以下游报告中出现的异常数值形式暴露时，它便不再奏效。在本文中，我将介绍如何构建可被编目、健康检查、追踪和修复的网络爬虫，使其如同其他生产级服务一样运作，其中由大语言模型（LLM）提出修复方案，由纯 Python 代码决定是否发布这些修复。该项目源于 WeMakeDevs 黑客马拉松，并荣获第一名。产品本身规模较小：它从三家流媒体提供商中抓取约十二天的电视指南数据，排名前十的即将上映电影和前十的即将播出剧集，并允许用户通过一次点击在 Philo 上录制任意内容。我将略过产品本身，专注于底层架构：漂移规则、状态模型、验证器以及各组件背后的代码。这些模块可迁移至任何运行爬虫的团队，或任何允许大语言模型修改实时系统的团队。 Treating Web Scrapers Like Production Services dzone.com +1
Kubernetes 滚动更新正在欺骗你——而你的用户正在为此买单 在滚动更新过程中，曾有一刻一切看似正常。旧 Pod 正在排空，新 Pod 正在启动，就绪探针通过，部署控制器感到满意。你在终端观察副本数变化，认为这正是按设计预期的工作方式。 Kubernetes Rolling Updates Are Lying to You — and Your Users Are Paying for It dzone.com +1
LLM 提示缓存第二部分：生产环境中的语义缓存 回顾：本系列内容的定位本系列第一部分介绍了精确匹配缓存：对完整请求进行哈希，当新请求与旧请求完全一致时返回已存储的响应。该层速度快且安全，但仅在输入完全匹配时有效，这在模板化流量中很常见，而在开放对话中则较为罕见。本文介绍填补这一差距的层级：语义缓存。第三部分将探讨请求实际到达模型后发生的情况：自托管 KV 缓存复用和提供商前缀缓存，以及生产环境中的细节：监控指标、核算成本，并提供一份完整清单。 Prompt Caching for LLMs, Part 2: Semantic Caching in Production dzone.com +1
构建生产就绪的 AI 手机代理：基础设施、模型与电话通信 引言：从语音 AI 原型到生产级电话代理语音 AI 演示由模型、麦克风和扬声器组成。而电话代理是一个分布式系统。音频通过 SIP 中继线从运营商传来，线路不佳时来电者会中断通话，后端可能出现超时，模型提供商的计费时段可能异常，且一旦出现问题，来电者希望立即转接至人工。本文展示如何为牙科诊所构建一个 AI 前台接待员。该系统会接听诊所的电话号码，通过来电者 ID 查询患者信息，调用后端 API 查询并预约就诊，并在需要人工介入时将通话转接至前台。该系统基于 LiveKit Agents 构建，这是专为 Python 和 Node.js 设计的开源框架。日志中标注了哪些功能需要 LiveKit Cloud 支持。每个代码片段均源自一个可运行的项目，每个输出均展示该项目实际打印的内容。 Build Production-Ready AI Phone Agents: Infrastructure, Models, and Telephony dzone.com +1
何时使用 AMQP、JMS、Kafka 或 MQTT：权衡取舍，而非胜负 AMQP、JMS、Kafka 和 MQTT 常被并列比较，仿佛只需择一即可一劳永逸。然而，这种对比大多属于范畴错误。这一错误如今更易犯，因为各工具间的功能重叠已远超往昔。Kafka 通过共享组（Share Groups）引入了队列语义；RabbitMQ 增加了日志功能；AMQP 标准委员会在沉寂数年后重新召集，聚焦于代理式人工智能（agentic AI）；MQTT 已确立 5.0 版本为边缘计算场景的默认标准；而 JMS 作为成熟的例外，因已能正常工作而保持现状。这些工具正相互借鉴彼此的功能，但其底层模型及随之而来的权衡取舍并未融合。 When to Use AMQP, JMS, Kafka, or MQTT: Trade-Offs, Not a Winner dzone.com +1
Kafka 与 Flink 与 Spark：你真的需要实时处理吗？ “实时”是数据基础设施中被过度使用的词汇。在 Kafka 与 Flink 与 Spark 的争论中，每家厂商都以此为首要卖点。毫秒级延迟、更快的引擎、展示其产品获胜的基准测试图表。推销话术始终如一，并利用了人们的恐惧：在延迟上落后，就意味着在业务上落后。 Kafka vs Flink vs Spark: Do You Really Need Real-Time? dzone.com +1
用Neo4j和Feast打造特色商店 特征存储解决了机器学习模型训练与推理之间特征不一致的关键问题。Feast 是一个开源解决方案，旨在通过管理特征注册表、特征物化以及在线检索来弥合这一差距，从而确保模型在生产环境中能够与训练期间一致地访问相同的数据。虽然该方案常与关系型数据库或云数据仓库配合演示，但本文探讨了一种替代方案：利用 Neo4j Desktop 作为特征计算引擎。其中五个特征涉及简单的聚合操作，可通过 Cypher 查询轻松实现；第六个特征为“客户社区 ID"，是通过图算法推导得出的。这些算法利用图数据科学（Graph Data Science）中的节点相似度识别具有相似购买模式的客户，随后通过 Louvain 社区检测将这些相似客户分组。Feast 随后摄入全部六个特征，并将其物化到 SQLite 在线存储中，以实现推理阶段的高效服务。该过程同时也确保了训练数据的时点正确性（point-in-time correctness）。 Building a Feature Store With Neo4j and Feast dzone.com +1
One Identity 推出 Active Roles 8.6，增强安全与管理功能” Alisa Viejo, California, 2026 年 11 月 10 日，CyberNewswireActive Roles 8.6：累积性安全、功能和管理升级” One Identity Unveils Active Roles 8.6 with Enhanced Security and Administration dzone.com +1
测试自动化中的智能体框架、记忆索引与人工智能治理 软件团队正比以往任何时候更快地采用 AI 代理来编写、运行和修复测试。突破点通常不在于模型本身。ChatGPT 和 Cursor 可能共享相同的底层智能，但前者给人的感觉像是一个复制粘贴助手，而后者则像是一位能够编辑文件、执行命令并持续迭代直至任务完成的队友。差异在于代理框架（agent harness）：这是一层编排层，它将模型与指令、工具、上下文和护栏相结合，使原始推理转化为可靠的操作。在测试自动化领域，这一差距尤为重要。一个失败的测试场景可能产生数千行 Playwright 输出，涉及页面对象、步骤定义、测试数据和多个环境。若将所有内容一次性投入单个长对话中，模型响应会变慢，成本上升，且决策噪声增加。设计良好的代理框架将模型视为规划者，而非垃圾车。它会对代码库建立索引，使代理能够提出结构性问题，而非读取整个文件。它将测试执行和文件生成委托给更小、更隔离的 worker，这些 worker 返回紧凑的摘要。在运行开始前，它会验证凭据、环境配置和参考夹具，从而尽早捕获失败，而非将其误标为“定位器损坏”。而当确实出现故障时，它会通过受控路径处理失败：诊断、修复、审查补丁、仅重新运行变更部分，并以人类可采取行动的形式报告结果。 Agent Harness, Memory Indexing, and AI Governance in Test Automation dzone.com +1
管道失败了，但基础设施发生了变化 大多数基础设施流水线将操作简化为两个事实：执行的命令及其退出码。 这足以判断进程是否完成，但不足以说明基础设施发生了什么。 The Pipeline Failed, But the Infrastructure Changed dzone.com +1
LLM 提示词缓存，第一部分：生产环境中的精确匹配缓存 为什么提示词缓存对 LLM 应用至关重要？现代 LLM 应用经常多次接收到相同或几乎相同的提示词。这种情况常见于表单提交、常见问题解答（FAQ）、代理工具调用，或用户用不同措辞询问同一内容。若无缓存机制，这些重复请求均需支付全额 Token 成本、承受完整延迟，并给您的速率限制带来不必要的压力。目前生产环境中已采用四种缓存方法。本文是该三篇系列文章的第一部分，介绍第一种也是最基础的方法：精确匹配缓存。第二部分将涵盖语义缓存，适用于含义相同但措辞不同的请求。第三部分将探讨模型服务层本身的内容：自托管 KV 缓存复用与提供商前缀缓存，以及每个团队最终都需要掌握的生产细节：监控指标、核算成本，以及一份完整的检查清单。 Prompt Caching for LLMs, Part 1: Exact-Match Caching in Production dzone.com +1
用 rce-path 追踪危险的 Python 代码路径 在 Python 代码库中找到 eval() 调用很容易，但理解其参数的来源却需要更多工作。同样的问题也出现在 shell 命令上。扫描器可以指向 subprocess.run()，但审查者仍需追踪该命令经过的赋值、字符串格式化以及分支逻辑。随之而来的更棘手的问题是：是否有人能在预期的信任边界之外控制该输入？ Tracing Dangerous Python Code Paths With rce-path dzone.com +1
AI辅助精炼准备 准备待办事项细化会议可能是一项耗时且重复的任务。人工智能在处理此类繁琐工作方面表现出色，例如审查所有待办事项及团队评论。然而，当让 AI 代理承担“协助细化”的任务时，会出现显著风险：该代理可能无意中使对话偏离团队。即使不编写验收标准，该代理也可能建议关闭、合并、拆分待办事项或创建新的待办事项。这相当于预先回答了本应在细化过程中由团队探讨的问题。为缓解此风险，在使用代理前必须明确界定边界。代理的职责应是识别证据并 formulation 问题；产品负责人则负责审查这些问题并制定实际细化会议的议程。团队随后依据该议程开展细化工作。将这些边界记录在 A3 交接画布中，可进一步明确代理的职责，并使产品负责人能够确保其得到遵守。 AI-Assisted Refinement Preparation dzone.com +1
使用 Anthropic 评估工具检查 Claude Code 插件的效率 Claude Code 技能”是一份 Markdown 文档，当任务与其描述匹配时，助手会加载该文档。技能、代理和钩子的集合可以打包为插件，并通过市场进行分发。自 2026 年夏季以来，我的开发环境一直依赖这样一个用于 Java 工作的插件，其中包含一组 Spring Boot、Quarkus、Apache Camel 和 Jakarta EE 代理与技能。该集合最初仅由少量工件组成，但逐步扩展后，经过数月时间，最终包含 43 个文件和 17,338 行代码。这引发了一个明确的问题：该插件提供的技术栈约定是否真正对最终结果产生了可衡量的贡献，还是说模型凭借其内在的通用知识，可以用更少的 token 推断出相同的结果？ Using the Anthropic Evaluation Tool to Check the Claude Code Plugin Efficiency dzone.com +1
构建多轨道支付故障切换机制，以消除延迟尖峰和重复扣款 为何单网关支付管道在高并发下会失效在构建企业级零售与 commerce 平台时，许多工程团队将支付处理视为标准的 REST API 调用。POS 终端发起结账请求，应用层将载荷发送至支付服务提供商（PSP），随后网络响应（200 OK、402 Declined 或 504 Gateway Timeout）决定订单是否完成。这看似简单，但在高交易流量场景下，存在三个需要特别关注的系统性弱点： Building Multi-Rail Payment Failover to Stop Latency Spikes and Double Debits dzone.com +1
每笔收购都承诺只产生一家公司，但结果往往是两家。 在一个大多数人闻所未闻的公司里，周一早晨，一封全员会议邀请落入了 200 人的日历。没有议程，只有时间和视频链接。人们期待的是产品更新，然而等来的却是面带微笑的 CEO 说出那句被绝大多数被收购公司员工最终都会听到的话：“我们很高兴地宣布，我们现在已成为一个更大大家庭的一员。”在另一栋完全不同的建筑里，不远处，一个规模小得多的团队正在庆祝。香槟已开启，握手正在进行，一笔电汇刚刚到账。对他们而言，这一天是明确的胜利。而对于那 200 位参会者来说，这一天，他们的组织架构图、他们的直属经理、他们使用的工具，有时甚至他们的职位名称，都不再完全由他们自己决定。 Every Acquisition Promises One Company. Most Deliver Two. dzone.com +1
当功能开关演变为工作流：配置多租户状态机 某雇主的注册截止日期发生变更。另一雇主增加了文档要求。第三家雇主需要让未完成申请的员工与从未开始申请的员工获得不同的体验。每一项需求听起来都像是配置。然而，实现它们往往需要修改后端服务、通知处理器和前端组件中的条件逻辑。设置位于应用程序之外，但连接这些设置的代码却分散各处。 When Feature Flags Become Workflows: Configuring Multi-Tenant State Machines dzone.com +1
手动在生产环境中扩展车队带来的三个可衡量结果 每一个 GitOps 部署都会遇到同样的时刻：某处出了问题，有人对生产环境执行了 kubectl scale，修复生效了。接下来会发生什么，取决于两个在事故发生前很少被检查的设置：GitRepo 上的自愈（self-healing），以及集群上的暂停（pause）。我在 Rancher 2.15.1 的实验室环境中运行了全部三种组合，使用了 Fleet（存在偏见，我在 SUSE 工作）。三个 EKS 集群：开发和测试环境运行在 Kubernetes 1.36，生产环境运行在 1.35。案例 1 和案例 2 使用了来自公共 rancher/fleet-examples 仓库的 guestbook 应用，前端 Deployment 副本数为 3。案例 3 使用了来自我自有仓库的 podinfo Helm Chart。每一次手动变更都通过 Rancher UI 中的 scale 按钮进行，该按钮会向 Deployment 的 scale 子资源发送 PATCH 请求，这与 kubectl scale 发出的请求相同。 Three Measured Outcomes of Manually Scaling Fleet in Prod dzone.com +1
为何成功的技术转型始于目标明确 每一代技术的到来都伴随着同样的期望：这一次，组织将成功转型、吸收新技术并从中获益。有时它们确实做到了。然而，经过数十年的技术进步，一种模式始终如一：组织继续投入宝贵的资源和资金于未能实现预期成果的技术项目。其失败原因在于，组织试图自动化那些它们尚未理解的内容。 Why Successful Tech Transformation Starts With Clarity dzone.com +1
超越状态一致性：防止 AI 代理系统中的过时决策 AI 代理（AI agents）和代理系统（agentic systems）正被迅速应用于长运行系统和工作流中。它们正在演进，以提供超越短请求 - 响应交互的支持，转而支持持续的过程，包括检索信息、调用工具、与其他代理协调、等待外部事件，并最终在真实系统中执行操作。这种扩展引入了一个新挑战：基于变化输入的可信决策。当代理根据系统或组件状态做出决策时，它们能够观察、推理并产生富有洞察力的决策。然而，在快速变化的环境中，某些决策背后的触发条件可能在执行前发生变化。其结果是出现一种看似矛盾的状态：系统在执行政策时，其状态是新鲜的，但所执行的决策却是过时的。 Beyond State Consistency: Preventing Stale Decisions in AI Agent Systems dzone.com +1
工程数据可观测性：检测模式漂移、数据漂移与静默管道故障 现代数据平台正越来越多地承担为关键决策、应用程序、分析系统和 AI 工作负载提供动力的职责。随着组织将更多业务流程迁移至数据驱动架构，数据管道的可靠性已与应用服务的可靠性同等重要。明显失败的管道通常易于诊断：失败的作业、损坏的依赖项或不可用的服务通常会生成警报，并将工程师引导至具体问题。而更棘手的问题则是那些完全未中断执行的管道。管道可能成功完成，却输出了错误、不完整或具有误导性的数据。 Engineering Data Observability: Detecting Schema Drift, Data Drift, and Silent Pipeline Failures dzone.com +1
你无需博士学位即可成为人工智能工程师：必备技能栈 今年，领英发布的美国增长最快的职业榜单上发生了一些奇怪的事情。榜首并非护理专家或可再生能源技术员，而是一个在 2023 年之前几乎不存在的职位名称：AI 工程师，该职位已连续两年位居第一。紧随其后的最常见技能包括 LangChain、检索增强生成（retrieval-augmented generation）和 PyTorch，这些技能在典型的计算机科学课程中均未见踪影。我花了 20 多年时间构建那些不容出错的系统，其中包括一个贷款会计平台，其输出数据直接汇入美国主要银行向美国证券交易委员会（SEC）报告的数字；以及以 Kafka 为核心、事件驱动的架构平台，用于处理跨越 29 种语言的产品数据。我所指导的、在 AI 工程师岗位上表现出色的工程师，往往并非数学背景最深者。他们懂得学习的正确顺序，并理解这一顺序为何至关重要。 You Do Not Need a PhD to Become an AI Engineer: The Essential Skill Stack dzone.com +1
两个 AI 智能体，一个数据库：使用乐观锁解决并发更新问题 AI 智能体正超越简单的聊天界面，成为真实应用工作流的一部分。在现代分布式系统中，一个智能体可能处理客户退款，另一个管理库存，而后台进程在同一时间更新相同的数据。主要问题并不总是智能体做出了错误决策。真正的挑战在于，两个智能体可能基于相同的数据做出有效决策，却在不知数据已发生变化的情况下相互覆盖彼此的更改。 Two AI Agents, One Database: Solving Concurrent Updates With Optimistic Locking dzone.com +1
首 token 时间：大型模型开始响应需要多长时间？ 在使用大语言模型时，我们通常对“速度”有两种感知：一是提出问题后第一个字符出现所需的时间；二是响应开始后生成的文本是否流畅。这类似于与人的对话：你提出问题后，对方可能会在开口前停顿。首字延迟（Time to First Token, TTFT）衡量的是这种“开口前的等待时间”。我们可以从以下三个角度对此进行清晰阐释。 Time to First Token: How Long Does It Take for a Large Model to Start Responding? dzone.com +1
混沌工程与 Kafka 实战：主题级幂等性与重试检查 如今，人人都在急于构建 AI 代理，但 GenAI 的集成实际上只是让稳健的系统设计和后端可靠性更加凸显。AI 代理完全依赖于其底层的 API 和数据管道。如果后端在网络波动时丢失事件或重复处理支付，即使是最优秀的代理也只会更快地执行一个有缺陷的工作流。要构建具有弹性的系统，你必须观察它们是如何失效的。阅读 Kafka 关于容错的文档固然有益，但有意引入网络混乱，才能真正揭示底层机制的实际行为。 Chaos Engineering and Kafka In Action: Topic Level Idempotence and Retry Check dzone.com +1
构建用于弹性 SSH SOCKS 代理和选择性浏览器路由的 Windows 应用 完整的 VPN 并非总是必需的。此外，由于本地或国家互联网服务提供商施加的限制，VPN 连接可能无法使用。出于同样的原因，直接连接到外部 SOCKS 代理也可能无法工作。有时，并非整个系统，甚至整个浏览器，而是仅针对特定地址需要替代的网络路由：外部 API、管理面板、文档、注册表、测试环境或其他无法通过常规路由访问的资源。在本文中，我们将探讨一种更窄范围的方法来解决这一问题： Building a Windows App for a Resilient SSH SOCKS Proxy and Selective Browser Routing dzone.com +1
会员聚焦：斯里尼瓦斯·奇帕吉里 您是否思考过未来几年定义性的基础设施挑战是什么？如果没有，我与 Srinivas Chippagiri 的访谈或许能促使您更深入地思考人工智能将如何改变基础设施的管理方式，以及这对构建可靠、安全的系统意味着什么。但在深入探讨这些内容之前，我通常喜欢先更多地了解专家背后的人物。那么，让我们从 Srinivas 的旅程起点开始吧！ Member Spotlight: Srinivas Chippagiri dzone.com +1
为限流 API 设计不丢失数据的轮询管道 任何从他人 API 摄取数据的系统，最终都会编写一个轮询器。它最初只是 cron 任务中的十五行代码：访问端点，与上次时间戳对比，插入新增数据。它一开始就能正常工作，而这恰恰是问题所在——它在开始丢失记录后，仍看似持续运行了相当长一段时间。我维护着一层持续轮询公开讨论类 API 的数据摄取层，而“轮询器正在运行”与“轮询器数据正确”之间的差距，比我预期的要长得多。以下内容是造成真实数据丢失的四种故障模式，以及修复它们的模式。 Designing a Polling Pipeline for Rate-Limited APIs Without Losing Data dzone.com +1
发明硒的人同时也制造了它的替代品 有一种特定的可信度，源于某人亲手摧毁了自己的创造物。Jason Huggins 于 2004 年构建了 Selenium。它成为整个行业的基础；他所参与建立的 WebDriver 协议至今仍是 W3C 标准，并在二十年后支撑着全球大部分测试自动化工作。因此，当 Huggins 亲自引领 Vibium AI 的推进——这是一个基于“我们已不再需要编写测试脚本”这一前提构建的框架——时，值得予以关注。这并非因为它注定会获胜，而是因为最清楚 Selenium 究竟存在哪些问题的人，正是提出这一观点的人。 The Man Who Invented Selenium Also Built Its Replacement dzone.com +1
大规模诊断测试失败：在临时运行器之间关联执行证据 在分布式 CI/CD 环境中，间歇性的测试失败会拖慢开发进度，并使故障排查更加困难。当自动化测试套件在本地开发或预发布机器上失败时，工程师可以查看本地日志、附加调试器，或手动追踪状态变更。然而，当测试在临时容器、AWS Lambda 或无代理运行器中执行时，事后调试的复杂度显著增加。在传统配置下，构建失败仅显示通用的断言错误（如 504、ElementNotFoundException 等）。工程师可能需要手动在 CloudWatch 日志组中筛选近似时间戳、查询 Splunk，或推理下游微服务之间的状态变更，以理解测试失败的原因。一旦日志保留期过期，或者执行过程未共享可识别的相关 ID，工程师便无法获取关于失败原因的进一步信息。 Diagnosing Test Failures at Scale: Correlating Execution Evidence Across Ephemeral Runners dzone.com +1
