DZone.com Feed 中文 关注 DZone是一个全面的在线平台，专注于技术和编程的多个方面。该网站提供了关于不同编程语言、技术、框架和工具的大量信息。该网站的一些主要特点和资源包括：关于技术领域最新趋势和更新的新闻和文章、学习不同编程技能的多种资源和教程、一个社区让用户可以与他人互动、分享经验和知识。此外，DZone还提供了技术专业人士的招聘信息，为对技术和编程感兴趣的人们提供了有用的资源。 DZone.com Feed dzone.com RSS feeds.dzone.com DZone.com Feed 中文 RSS thenote.app
停止手动滚动聊天 UI：将流式 LLM 令牌无缝集成到 React Native，避免卡顿 聊天界面看起来像是一个周末项目：一串气泡列表和一个固定在底部的文本输入框。在 React Native 中，这是最难完美交付的功能之一，因为它叠加在移动开发中最具挑战性的两个层面之上：软件键盘和在你注视时尺寸不断变化的滚动列表。如今，我们正将大语言模型（LLM）集成到各种应用中，但针对 React Native 仍缺乏一个优质的即插即用式聊天视图。你要么拼凑一个观点鲜明却日渐陈旧的库，要么从头手写。我选择了手写。随后，我让 LLM 逐 token 流式输出回复，结果整个系统彻底崩溃，而理解这一崩溃竟耗费了一周时间。 Stop Hand-Rolling Chat UIs: Streaming LLM Tokens Into React Native Without the Jank dzone.com +1
你不必是管理者也能成为领导者：为何领导力对软件工程师至关重要 许多人认为，软件工程领域的领导力始于停止编码并转为管理者之时。我曾也持有这种观点，以为与技术协作相比，与人共事更为复杂。那是一个早期的误解。虽然可以将职业生涯专注于代码、架构、数据库及其他技术领域，但随着时间的推移，塑造你影响力的挑战将逐渐从技术层面转向其他维度。即使是最优的架构决策，若他人不信任、不理解或不支持，其价值也微乎其微。这并不意味着每位经验丰富的软件工程师都应成为管理者。在技术轨道上，领导力同样至关重要。资深独立贡献者，如 Staff Engineer、架构师和 Principal Engineer，被期望在其自身代码之外影响决策。正如 Will Larson 在《Staff Engineer》一书中所探讨的，超越高级工程师阶段的核心在于技术领导力，而非人员管理。要提升你的技术影响力，他人必须倾听你的想法、信任你的判断、将你纳入关键讨论，并采纳你的建议。你可以选择不管理他人，但回避领导力最终会限制你作为软件工程师的成长。 You Don’t Need To Be a Manager To Lead: Why Leadership Matters for Software Engineers dzone.com +1
停机意味着前门未锁 任何长期背负寻呼机的人都会产生一种职业性的麻木。队列堆积，p99 指标超出预算，部署在 40% rollout 阶段就出现了愚蠢的错误。你修复它，写下报告，然后继续睡觉。赌注是真实却抽象的：每分钟收入、SLA 信用、某人电子表格上的流失率数字。这种麻木感无法在与人们赖以保障安全的产品的接触中存活。 When Downtime Means an Unlocked Front Door dzone.com +1
AWS Bedrock 与 Vertex AI 及 Azure Foundry：别再比较基准测试，转而提出这个问题” 每隔几周，我的团队成员或客户会议中就会有人问我同一个问题：“我们的 AI 工作负载应该使用哪家云？”我在企业集成领域已有超过十四年的经验，最近大部分时间都投入到基于这些平台的 RAG 管道、向量数据库以及智能体编排上。因此，我频繁收到这个问题，而坦率地说，并没有唯一正确的答案。合适的云取决于您的数据当前所在位置、合规团队可接受的范围，以及您的架构实际需要的模型。在本文中，我将深入探讨三大主要玩家：AWS Bedrock、Google Vertex AI 和 Microsoft Azure AI Foundry，并分享我在真实企业环境中与这些平台合作所获得的经验，而不仅仅是基于阅读营销页面。 AWS Bedrock vs Vertex AI vs Azure Foundry: Stop Comparing Benchmarks, Start Asking This Instead dzone.com +1
提示、微调或编译：构建人工智能的三种方式 它始于我在埋头构建代理式 AI 系统时闪过的一念：在“直接调用 API"与“训练自己的模型”之间，我们悄然形成了三种截然不同的解决方案来应对同一问题。大多数团队将其视为一个一次性决策，在早期做出后便不再回顾。事实并非如此。这是一个需要贯穿产品全生命周期进行管理的组合。 Prompt, Fine-Tune, or Compile: The Three Ways to Build Anything in AI dzone.com +1
AI 如何真正改变 SRE 工具，第二部分：IT 运维、混沌工程及其他工作范畴” 在第一部分中，我探讨了人工智能如何改变事件响应流程：从 BigPanda 等关联引擎以及 PagerDuty 的 AIOps 功能，到一类更新的专用 AI SRE 代理（如 Traversal、Resolve.ai 和 Cleric），它们不再仅仅对您已收集的告警进行聚类，而是自主调查事件。事件响应之所以备受关注，是因为它是工作中最响亮、最显眼的部分。但如果您实际追踪 SRE 一周的时间分配，会发现很大一部分工作并非“救火”。它包括 ITOps 工单、混沌测试、SLO 计算、值班排班，以及撰写和维护那些直到凌晨 3 点才有人阅读的运维手册的漫长过程。第二部分将探讨人工智能在上述所有领域的应用，遵循我在第一部分中采用的同一原则：厂商公布的数据将被明确标注为“厂商报告”，并且我会坦率指出，无论工具多么先进，某些领域的采用率仍然较低。 How AI Is Actually Changing SRE Tools, Part 2: ITOps, Chaos Engineering, and the Rest of the Job dzone.com +1
为何 DAST 发现难以修复以及如何使其可操作 动态测试至关重要，因为它能揭示运行中应用程序的漏洞。然而，由于 SAST（静态应用安全测试）具有左移特性且修复相对直接，往往更受关注；而 DAST（动态应用安全测试）则常积压在待办事项中。应用安全测试通常分为两种方法。SAST（静态分析）在代码运行之前扫描源代码，在开发人员仍在编辑文件时即可发现问题，因此修复通常进行得很快。此时，开发人员正在修改自己刚编写的代码，对代码的功能和目的拥有完整上下文。DAST（动态分析）则采用不同的方式：它在应用程序运行时进行测试，向真实端点发送实际请求，以观察哪些功能失效，这与攻击者从外部探测系统的方式相同。 Why DAST Findings Are Hard to Fix and How to Make Them Actionable dzone.com +1
保障 AI 检索管道安全，并在 RAG 系统中添加身份感知访问控制 大多数 RAG 教程都聚焦于相关性——分块策略、嵌入模型以及混合搜索融合。它们很少涉及安全性。在生产环境中，检索管道会从具有不同访问级别、敏感等级分类和监管要求的数据源中拉取数据。支持代理不应仅因向量相似度得分较高就查看高管薪酬数据；处理客户查询的 AI 代理也不应返回内部审计发现，仅因为其词汇与问题相似。本文填补了这一空白。它介绍了如何在现有 RAG 管道中添加基于身份的访问控制，作为一层轻量级安全机制：在检索前对每个分块执行权限强制、提示注入扫描、为语言模型构建安全上下文，以及用于合规的审计日志记录。每一步都会生成一个可适配的具体工件。所有示例均使用纯 Python。 Securing AI Retrieval Pipelines and Adding Identity-Aware Access Controls to RAG Systems dzone.com +1
在 Databricks 上部署带有 RAG、MLflow、向量搜索和模型服务的企业级 LLM 聊天机器人 演示总是能成功。有人在笔记本中将向量索引连接到基础模型，就员工手册提出三个问题，得到三个清晰的回答，全场点头认可。随后需求变为“部署给 4000 名员工”，而那个笔记本便悄然失效。没有端点、没有身份验证、没有版本历史、无法查看特定回答为何出错，当法务询问如何回滚那个开始引用 2019 年 PTO 政策的提示词时，你也无法给出任何解释。我曾目睹多个团队在此处碰壁。RAG 部分——分块、嵌入、检索、填充上下文、生成——他们理解得相当透彻。他们缺失的是枯燥的一半：如何将运行在笔记本单元格中的链式流程，转化为一个受管制的、可版本控制的、可监控的 REST 端点，供聊天界面调用；使其能在凌晨三点的紧急呼叫中依然稳定运行；并能在下个月进行 A/B 测试而无需重新部署整个系统？本文正是关于这一枯燥的一半。我们将假设您已在概念上理解 RAG，并完整走通 Databricks 的路径：编写链式流程、将其日志记录至 MLflow、注册到 Unity Catalog、部署到模型服务端点、追踪每一次检索与生成，并在上线后对其进行运维。 Deploying an Enterprise LLM Chatbot on Databricks With RAG, MLflow, Vector Search, and Model Serving dzone.com +1
Docker 如何演变为人工智能开发平台 “当我们的入职文档变短而非变长时，它就不再仅仅是一个打包工具了。在新机器学习平台岗位入职三周后，我问一位同事，为什么‘入门指南’里有一节叫‘如果 conda 坏了，试试替代方案’。他笑了一下，那笑容告诉我这并非玩笑。每一位新入职的员工在前两天都要与 Python 版本、CUDA 驱动不匹配以及某个在 2022 年本地安装后无人敢动的向量数据库搏斗。我们团队有四名成员，各自拥有不同的工作配置，“在我机器上能运行”不再只是一个笑料，而是我们每日站会上的常规议题。” How Docker Is Becoming an AI Development Platform dzone.com +1
为什么智能体卡片很重要？ 让我们从智能体（AI agent）的定义开始。智能体是代表用户或其他程序自主执行任务的软件实体。换句话说，智能体能够感知环境、进行思考并采取行动，以最小的人类干预实现特定目标。关键在于“行动”。 Why Is the Agent Card Important? dzone.com +1
《Chrome 扩展 Manifest V3 声明式网络请求 API 开发者指南》 Google 从 Manifest V2 向 Manifest V3 的过渡，是浏览器扩展开发历史上最重要的架构重构之一。对于构建广告拦截器、隐私防护工具或开发者工具的开发者而言，最大的影响是 chrome.webRequest API 的拦截能力已被弃用。取而代之的是 chrome.declarativeNetRequest（DNR）API。浏览器不再允许扩展实时拦截和检查网络流量，而是由扩展使用声明式规则代表浏览器执行过滤。 A Developer's Guide to Chrome Extension Manifest V3 Declarative Net Request API dzone.com +1
容器化大语言模型：基于 Docker 的 AI 工作负载最佳实践 第一次为客户的内部搜索工具容器化一个微调后的 Llama 模型时，构建完成后的镜像大小达到了 38 GB。我记得盯着终端屏幕，心想这肯定不对。但事实确实如此：该镜像包含了 CUDA 基础镜像、编译了所有后端的 PyTorch、将模型权重直接烘焙到层中，以及一个未清理的 pip 缓存。将该镜像推送到我们的注册表，在连接良好的情况下耗时 11 分钟。而在自动扩缩容事件中将其拉取到全新节点时，耗时更长；等到 Pod 就绪时，它本应处理的流量峰值早已过去。那一刻，我停止将 LLM 容器当作普通应用容器来处理，因为它们根本不是同一类事物。 Containerizing LLMs: Best Practices for Docker-Based AI Workloads dzone.com +1
Docker Swarm 中不同 Docker Engine 版本如何导致部分流量不可用” Docker Engine 版本不一致会导致 Swarm 集群中出现微妙的流量降级问题。该问题在一台管理节点上表现为 Traefik 报告某服务不可用。怀疑原因是 Docker 版本 28.1.1 与 28.2.2 之间的 iptables 规则和 overlay 网络存在差异。该具体问题发生于 2025 年 6 月 22 日某大型公共交通应用的生产环境中。该应用支持约 200 万用户，日活跃用户达数万人，系统处理 1000 至 1600 次每秒的庞大请求负载。单个入口点的部分流量问题显著影响了高流量区段。若未能及时定位，此类降级可能损害 SLA 指标。该场景凸显了在 production Swarm 环境中保持 Docker Engine 版本一致性的重要性。维持版本统一可避免隐藏的性能问题，并确保大规模用户群的服务稳定性。 How Different Docker Engine Versions Led to Partial Traffic Unavailability in Docker Swarm dzone.com +1
解决企业级规模下模型上下文协议（Model Context Protocol）服务器的会话持久性问题 在开发环境中运行完美的 Model Context Protocol (MCP) 服务器，一旦部署到负载均衡器后方的多个副本中，便可能出现间歇性故障。故障表现为随机出现的“会话未找到”错误流，其根本原因在于某些 MCP 传输层保持会话状态的方式与负载均衡器分发请求的方式不匹配。本文解释了该问题产生的原因、适用场景，以及如何使用共享会话存储来解决这一问题的具体模式。该问题在早期开发中极易被忽视，因为它仅在存在多个服务器实例时才会显现。单实例部署将所有会话保存在本地内存中，因此每个请求自然都能找到其对应的会话。一旦添加副本，这一假设便会悄然失效。 Solving Session Persistence for Model Context Protocol Servers at Enterprise Scale dzone.com +1
多智能体软件工程：AI 团队能否构建生产级系统？ 大型语言模型已从简单的聊天界面演变为能够规划、推理并与外部工具交互的自主系统。这一演进的下一阶段是多智能体软件工程，即由专用 AI 智能体协作以解决复杂的业务流程，而非依赖单一单体模型。规划智能体可分解任务，研究智能体检索企业知识，编码智能体生成实现，评审智能体验证输出，执行智能体则实施已批准的操作。尽管该架构看似诱人，但生产环境部署表明，协调多个智能体更像是在构建分布式系统，而非编写提示链。主要挑战并非模型智能，而是系统可靠性。每增加一个智能体，就会引入新的幻觉、上下文丢失、延迟、重试和级联故障的风险。一个包含五个智能体的工作流，即使每个智能体单独具有高准确率，仍可能产生不一致的结果，因为每一次交接都会成为不确定性的新来源。因此，工程挑战已从提示工程转向编排、状态管理、弹性与可观测性。 Multi-Agent Software Engineering: Can AI Teams Build Production Systems? dzone.com +1
设计面向可解释企业决策的本地优先风险检测流程 企业风险问题往往始于数据平台层面的问题。挑战包括信号碎片化、定义不一致、上下文缺失、血缘关系薄弱以及告警不及时。无论是评估交易、支持消息、图像还是指标，核心问题在于：如何将不完美的证据转化为可解释、可辩护的决策？黑客松的观察揭示了数字安全项目中反复出现的设计压力。本地语言与上下文显著影响结果。网络访问往往不可靠。单一检测器不足以应对。缺乏明确依据的风险评分难以解读。尽管这些见解并非通用解决方案，但它们支持一条实用准则：保持决策路径具备本地化、模块化及可审计性。 Designing a Local-First Risk Detection Pipeline for Explainable Enterprise Decisions dzone.com +1
基于 Kafka 和 Neo4j 的实时供应链事件流处理 在上一篇文章中，我们使用 Apache Spark 在 Neo4j 中构建了一个静态供应链图谱，其中供应商、仓库、配送中心和零售商通过运输路线相互连接。这为我们提供了某一时间点的网络快照。在本文中，我们将添加流处理层：货运事件实时流经 Confluent Cloud Kafka，作为增强的图谱属性落地到 Neo4j，同时一个实时仪表板会随着事件的到达动态更新网络健康状态。 Real-Time Supply Chain Event Streaming With Kafka and Neo4j dzone.com +1
Java 企业版已为人工智能时代做好准备 人工智能正在改变软件工程，影响自动化、用户交互、数据分析以及应用开发。开发人员正在评估其技术栈如何适应这些变化。对于企业环境中的 Java 开发者而言，一个核心问题是：Java 企业生态系统是否已为人工智能做好准备。简短的回答是肯定的。您无需放弃 Java，也无需等待新平台即可构建具备人工智能功能的应用程序。Java 已拥有成熟的 AI 库、模型提供商、API 及集成模式生态系统。Jakarta EE 提供了在当前生产级企业系统中部署这些技术所需的能力。 Java Enterprise Is Already Ready for the AI Era dzone.com +1
Arm64 不再是边缘情况” Arm64 作为计算未来赌注的时代已 definitively 结束。Arm64 已从嵌入式和以研究为导向的架构，转变为 Linux 中的主流、一等平台。这一转变在 Ampere Computing 的 Dave Neary 与 Linux 内核维护者 Greg Kroah-Hartman 的对话中得到凸显。Kroah-Hartman 的 Linux 职业生涯始于 20 世纪 90 年代末的嵌入式系统，他观察到 Linux 开发者社区已显著成熟。起初，Linux 开发者大量借鉴 Unix 等其他操作系统以实现功能。随着时间的推移，Linux 从模仿走向创新，引领自身发展。这一进步意味着开发者不再复制现有模式，而是构建新的基础设施、接口和可扩展流程。重点已从“让事物运行”转向“按最高标准构建”。这使得 Arm64 成为当前 Linux 开发、部署和维护策略中的关键组成部分。因此，Arm64 现已成为 Linux 生态系统中核心且完全支持的架构。 Arm64 Is No Longer the Edge Case dzone.com +1
在 Kubernetes 上构建内部开发者平台：无人提醒你的抽象问题 引言改变平台团队方向的会议并非技术会议，而是一次与一位产品工程师的对话。该工程师入职公司八个月，此前从未在无需平台团队成员协助的情况下成功将代码部署至生产环境。这并非因为她缺乏技能。她聪慧、经验丰富，曾在两份前工作中成功上线过生产系统，但将可运行的服务部署到生产环境，意味着需要处理分布在四个仓库中的十五个不同的配置文件，厘清 Helm 值文件与 Kustomize 覆盖层如何协同工作，并依据服务是否需要边车（sidecar）、作业调度器（job scheduler）或两者皆不需要，从三个 CI 流水线模板中选择正确的一个。 Building Internal Developer Platforms on Kubernetes: The Abstraction Problem Nobody Warns You About dzone.com +1
构建数据管道：Palantir Foundry 所做的令我惊讶之事。 资深数据工程师被训练要对专有平台持怀疑态度。当我参加 Palantir Foundry 培训训练营时，我原本期望发现一种缓慢且昂贵的替代方案，用来替代我在 AWS 和 Azure 上熟悉的成熟工具。然而，我发现的却是一个为截然不同的用户群体构建的平台：那些无法编写 SQL 但急需答案的用户。我打算诚实地撰写我所观察到的内容，包括我认为 hype（炒作）合理之处与不合理之处，因为我所看到的绝大多数 Foundry 内容要么来自 Palantir 自身的营销，要么来自那些已深度嵌入该平台、以至于忘记了初次接触时感受的从业者。我在此撰写此文时，仍保有那种清晰的视角。 Building Data Pipelines: Here's What Palantir Foundry Did That Surprised Me. dzone.com +1
MCP 与 A2A 及 ACP：AI 智能体如何相互通信” 大多数协议图将 Model Context Protocol（MCP）、Agent2Agent（A2A）协议和 Agent Communication Protocol（ACP）并列置于三个等宽的栏目中。我认为这种框架导致了半数以上的困惑。它们并非三种可互换的代理通信方式。MCP 解决的是能力访问问题，A2A 解决的是委托问题，ACP 则探索了以 REST 为优先的代理通信版本。一旦厘清这些边界，架构便更容易理解。 MCP vs A2A vs ACP: How AI Agents Talk to Each Other dzone.com +1
向量数据库索引解析：为何其重要性超越嵌入本身 大多数关于向量数据库的讨论都始于并终于嵌入（embeddings）。讨论通常围绕它们的生成方式、由哪个模型生成以及它们携带的维度数量展开。嵌入获得了所有关注，但它们并非决定您的 AI 搜索、RAG 管道或推荐引擎在生产环境中是瞬间响应还是 painfully slow 的关键因素。这取决于索引（indexing）。 Vector Database Indexing Explained: Why It Matters More Than the Embeddings Themselves dzone.com +1
会员风采：Pavan Belagatti 与社区建立联系是我工作中最喜爱的部分之一！因此，我们的团队推出了“成员风采”系列，以进一步凸显 DZone 开发者的独特之处。本系列的第一位是 Pavan Belagatti。在将近十年的 DZone 贡献之后，我花时间深入了解文章背后的那个人——从最初激发他对科技兴趣的契机，到他如何保持知识更新以及工作之外的兴趣爱好。 Member Spotlight: Pavan Belagatti dzone.com +1
您选择的嵌入模型比您的 LLM 更为重要 《令人不适的真相》你已花费数日对大语言模型进行提示工程优化，对比评测了 Claude 与 GPT，甚至争论是否应采用 Mixtral。然而，你的检索增强生成（RAG）流水线仍在返回垃圾答案，而你却归咎于错误的组件。大语言模型的效果仅取决于其接收到的上下文质量，而上下文质量完全由检索环节决定。检索质量则完全取决于你的嵌入模型。修复底层，顶层便会随之改善。 The Embedding Model You Choose Matters More Than Your LLM dzone.com +1
按审计就绪设计：将数据血缘、时间点重建与不可变性融入数据架构 许多数据平台将审计就绪视为开发后的次要问题，优先构建管道和仪表板，而后才考虑监管要求。这往往导致被动应对方案，例如搜索备份或从日志中重构数据。有时，必要的历史数据甚至完全缺失。这种模式体现了一种“合规勾选框”架构。另一种选择是“设计即审计就绪”，将三个属性视为基本约束：数据血缘、时间点重构和不可变性。从一开始就将这些属性作为架构约束加以实施至关重要。与后期附加的脚本不同，架构约束在压力下不易被忽视。这种前瞻性设计确保了真正的可审计性。 Audit-Ready by Design: Building Lineage, Point-in-Time Reconstruction, and Immutability Into Data Architecture dzone.com +1
面向未来的 JWT 安全：密码学敏捷性、后量子签名与身份与访问管理迁移 如今，应用程序围绕身份系统构建。所有 API 网关、微服务、移动后端以及单点登录流程都需要某种形式的身份验证和授权。在许多系统中，这种信任通常通过 JSON Web Token（JWT）来传递。其紧凑性、可移植性以及在分布式系统中易于验证的特性使其广受欢迎。服务可以接收令牌，验证其签名，验证令牌的声明（过期时间、受众、主题和签发者），并确定是否应接受该请求。 Future-Proofing JWT Security: Crypto-Agility, Post-Quantum Signatures, and IAM Migration dzone.com +1
“工程即服务”是当你让“氛围编程”获胜时发生的事。 "Vibe coding"并非一种编程技术，而是一场被包装成技术活动的组织事件。2021 年 GitHub Copilot 推出时，叙事是"AI 作为结对程序员”；当 ChatGPT 出现后，转变为"AI 作为初级开发者”；等到 Cursor、Windsurf 和 Devin 登场时，目标线已移动得如此遥远，以至于我们不再察觉它们原本的位置。该术语本身——由 Andrej Karpathy 于 2025 年初提出——描述了通过描述需求并迭代 AI 输出直至其看起来正确的方式来编写软件。无需预先设计架构，无需深入理解内部机制。只需提示、审查、调整、发布。这个名字几乎刻意地随意。Vibe。仿佛整个过程都是低风险的一样。 Engineering as a Service Is What Happens When You Let Vibe Coding Win dzone.com +1
从敏捷到产品运营模式 TL; DR：“敏捷转向产品运营模式”调查结果2026 年 8 月 2 日至 8 月 10 日期间，共有 48 名从业者参与了由我发起的“敏捷转向产品运营模式（POM）”调查，旨在揭示实际正在发生的变化。现将调查结果总结如下：报告中的转型对决策的影响小于 Cagan 框架所预期的程度。在受访者报告的改进方面，主要体现在交付与协作层面，而非业务成果。遗憾的是，转型过程中涉及人的方面是回答中最令人沮丧的部分。 From Agile to the Product Operating Model dzone.com +1
为什么分布式数据库在协调边界处会失败 分布式数据库通常通过熟悉的技术维度进行评估：复制因子、一致性模型、分区策略、吞吐量、延迟和恢复时间。这些特性固然重要，但并不能完全解释为何在组件层面看似健康的系统仍会遭遇严重的生产故障。在许多情况下，存储引擎并非架构中最薄弱的环节。故障往往发生在协调边界处。 Why Distributed Databases Fail at Coordination Boundaries dzone.com +1
您的 AI Agent 是一个分布式系统，而非聊天机器人 大多数团队仍在构建类似聊天机器人的 AI 代理。这对于演示来说是可以接受的，但对于生产环境则不可行。聊天机器人回答问题，而企业级 AI 代理执行工作。这一区别看似微小，却彻底改变了整体架构。 Your AI Agent Is a Distributed System, Not a Chatbot dzone.com +1
使用 AIDLC 构建文档（而不仅仅是代码） 我在为知识转移包回答需求问题时，AI 突然卡住了。我选择的输出格式是“幻灯片”。在随后的两个问题中，我将图表的渲染方式选为“原生网页渲染”。AI 没有猜测我的意图，而是直接停止了工作流： Using AIDLC to Build Documents (Not Just Code) dzone.com +1
构建生产级 AI 质量系统的六种模式 1. 为何大多数 AI 测试工具在生产环境中失败这一模式已屡见不鲜：团队将大语言模型（LLM）集成到其测试流程中，演示效果令利益相关者印象深刻，但三个月后该工具便被悄然弃用。其生成的测试用例需要人工清理。根本原因分析往往泛泛而谈，适用于任何失败案例。数据准备导致环境状态不一致。当值工程师不再信任该工具，转而回归手工操作。问题通常不在于模型本身，而在于围绕模型构建的工程实践。生产级 AI 系统需具备与其他软件同等严格的工程标准：质量门禁、受控的失败模式、可审计的输出，以及关于系统自主行为边界（即系统能做什么、不能做什么）的明确契约。大多数 AI 测试集成方案完全跳过这些环节，仅封装一个提示词（prompt）便匆忙上线，随后又对采用率停滞感到困惑。 Six Patterns for Building Production-Grade AI Quality Systems dzone.com +1
5 保护AI代理的基础设施控制 NVIDIA 的 AI 红队于 2026 年对企业级 AI 代理进行了为期六个月的评估审查。审查发现，失败的 AI 代理主要源于四个原因，包括缺乏访问控制以及无法执行任意代码的能力。这些代理在出站网络方面没有任何限制，也未实现隔离，且明文密钥可供其访问。此类 AI 代理的问题本质上属于架构层面，导致难以防范其失效。由于模型控制平面具有统计特性，其并非可靠的防御机制；依赖控制平面的防御手段可通过三种主要方式被绕过：其一，将恶意活动伪装成合法活动；其二，通过逐步升级对话，积累足够历史以确立命令的合法性；其三，将代码执行嵌入合法行为中，例如安装软件包。审查结果凸显了需要更强大的安全措施以防止 AI 代理失效。总体而言，这些漏洞的发现强调了纠正 AI 代理架构缺陷的重要性，以确保其安全、可靠地运行。 5 Infrastructure Controls for Securing AI Agents dzone.com +1
代码生成已解决；信任才是瓶颈 你有一个结账流程。你有 40 个测试用例，它们都是绿色的。现在：当用户在取消后收到支付回调时，会发生什么？当重试请求落在已过期的会话上时，会发生什么？当自动续期关闭且周期边界已过时，第四次重试失败会发生什么？ Code Generation Is Solved; Trust Is the Bottleneck dzone.com +1
从原始清单到自助式 Kubernetes 应用：构建企业级就绪的开放平台 赞助商：Nutanix 以下内容由赞助商提供，可能不代表我们编辑团队的观点。无人谈论的 Kubernetes 扩展难题企业平台团队反复遇到相同的模式：Kubernetes 平台表现尚可，因此无人愿意对其进行更改。这种情况是随着团队做出合理的技术选择而逐渐形成的：选择不同的入口控制器、密钥管理工具、持续交付平台或可观测性软件。单独来看，这些决策本身并无问题。然而数月之后，它们却构建了一个只有少数人能够理解的 Kubernetes 环境。一旦这唯一掌握情况的人生病或离开公司，维护或改进该平台便会变得愈发困难。 From raw manifests to self-service Kubernetes apps: creating enterprise-ready open platforms dzone.com +1
基于 Spring AI 的 AI 驱动 API 开发 人工智能已迅速成为现代软件开发的核心能力。对于 Java 开发者而言，将这些能力集成到现有的企业应用中，不再需要学习全新的框架或直接与复杂的 AI API 交互。Spring AI 通过提供熟悉的 Spring 编程模型，实现了与来自 OpenAI、Google Gemini 等提供商的大语言模型（LLM）的交互，从而弥合了这一差距。在本文中，我们将使用 Spring Boot 和 Spring AI 构建一个简单的 AI 驱动 REST API，同时探索有助于超越概念验证实现、迈向生产就绪企业应用的实践方法。 AI-Powered API Development With Spring AI dzone.com +1
多云环境中的可靠性挑战：为何双云往往比单云更难 多云架构的提案听起来总是很完美：避免供应商锁定，根据任务需求选择成本最低的提供商来运行工作负载以优化成本，并通过在独立的故障域之间分布来提升韧性。从纸面上看，这是一个极具说服力的案例。然而在实践中，那些实际运营多云部署的团队往往描述的是截然相反的情况：运维复杂度翻倍，可观测性减半，以及一类仅因存在两朵云而非一朵云而特有的可靠性问题。我曾密切合作的一个团队，因当时 GPU 可用性和定价更优，将工作负载迁移至 AWS，同时将机器学习推理流水线部署在 GCP，随后花了接下来的八个月时间处理一类他们未曾预料到的故障：这些故障既非应用程序所致，也非任一云服务商的责任，而是存在于两者之间的边界地带。仅在负载下才会显现的数据传输延迟尖峰；仅在跨云调用时才会触发的认证令牌过期边缘情况；以及那些在预生产环境中通过所有测试，却在凌晨三点的生产环境中失败的网络安全策略交互。这些问题单独来看并不棘手，之所以棘手，是因为每朵云的诊断工具都指向内部，而故障恰恰存在于这两类工具均未覆盖的空间之中。 Reliability Challenges in Multi-Cloud Environments: Why Two Clouds Are Often Harder Than One dzone.com +1
如何在 C# 中提取 PDF 及其他文档中的表格 商业文档很少将其最有用的信息以方便的数据库记录或 JSON 对象形式存储。发票将明细行存储在表格中，财务报告按期间组织数据，检验表单按类别分组发现结果，而电子邮件中的报表通常以附件或消息文件的形式到达。在应用程序能够验证、比较、搜索或存储这些信息之前，必须以某种方式恢复行、列、标题和值之间的关系。 How to Extract Tables from PDFs and Other Documents in C# dzone.com +1
关于开发 A(ccelerated) I(nference) 的思考 "AI" 是人工智能（artificial intelligence）的缩写，但我更倾向于 Venkat Subramaniam 博士在一次演讲中使用的术语：加速推理（Accelerated Inference）。在我看来，这一表述更为准确，因此我已采纳。而“加速”正是关键所在。借助 AI，代码生成已变得廉价，不再成为软件开发的瓶颈。真正变得昂贵、且本文真正探讨的，是围绕其的一切：使结果与意图保持一致、对交付的内容负责，以及行使任何加速手段都无法替代的判断力。 Thoughts on Developing With A(ccelerated) I(nference) dzone.com +1
图工程：循环工程之后的下一层 几个月前，我曾撰写过关于“循环工程：提示、上下文与驾驭层之后的下一层”的文章，论证道：一旦你的提示经过调优、上下文已组装、驾驭层已连接，真正决定智能体能否成功的关键在于其所运行的循环：它如何决定继续、停止、重试或移交。在那篇文章发布后，几位读者提出了一个合理的后续问题：循环究竟针对什么？当一项工作不再能由单个循环完成时，会发生什么？这个问题最终得到了答案，而在我着手寻找时，AI 工程界早已在酝酿这一答案。2026 年 7 月中旬，X 平台上围绕此议题爆发了一场迅速而喧嚣的辩论，由 OpenClaw 创建者彼得·斯坦伯格（Peter Steinberger）提出的一个问题所引发：对话是否已经超越了循环，进入了图（graph）的范畴。短短几天内，这一概念便有了正式名称：图工程（graph engineering）。我想梳理其实际含义，探讨它与循环工程的重叠之处，并指出我认为那场辩论中持怀疑态度的一方所提出的合理观点。 Graph Engineering: The Layer After Loop Engineering dzone.com +1
使用 Snowflake Cortex 和 RAG 构建企业级 AI 数据工程 数据究竟在哪里我与每一家企业协作时，都会遇到同样的瓶颈：海量数据堆积如山。数据仓库、工单系统、PDF 文件、旧邮件归档……其中大部分数据尚未准备好供 AI 使用。管理层希望部署一个能回答政策与产品规格问题的聊天机器人，但无人知晓数据存放何处，更不知如何将其准备就绪。升级模型无法解决这一问题，唯有通过数据工程才能化解。反复出现的模式聊天机器人直接连接基础模型，完全缺乏检索层。它仅凭记忆作答，导致细节错误。 文档分散在五个不同的系统中，且治理方式各不相同。 嵌入向量仅在系统启动时计算一次，此后从未更新。 构建 RAG 流水线时，无人核查谁拥有源文档的写入权限。问题从来不出在模型本身，而在于模型见到问题之前所发生的一切。 Enterprise AI Data Engineering With Snowflake Cortex and RAG dzone.com +1
为什么你的统一API策略会崩溃 每个 B2B SaaS 产品团队都经历过这样的时刻：你正试图敲定一笔交易，而客户却说：“我们只需要你们与我们的 CRM 同步。还有我们的 HRIS。哦，还有这三款其他工具。你们能做到吗？”你的路线图因此受阻，工程待办事项一夜之间翻倍。最终，有人问道：“那统一的 API 呢？” Why Your Unified API Strategy Will Break dzone.com +1
LocalStack 与 Terraform：本地 AWS 环境搭建指南 在本地运行 AWS 资源是提升工程速度、优化成本以及增强开发者自主性的变革之举。传统上，测试云基础设施需要直接部署到预发布或沙箱 AWS 账户。这种工作流程引入了令人痛苦的摩擦点：等待缓慢的云资源供应周期、追踪导致月度账单膨胀的孤儿资源，以及需要持续的高速互联网连接。LocalStack 通过在本地机器上的 Docker 容器中模拟核心 AWS 服务（如 S3、SQS、DynamoDB 及其他服务）来解决这一问题。当与 Terraform 配合使用时，您可以安全地针对此本地模拟器编写、规划并应用基础设施即代码（IaC）配置蓝图。 LocalStack and Terraform: A Clean Local AWS Setup Guide dzone.com +1
在同一代理图（Agent Graph）上基准测试 LangGraph、Strands、OpenAI Agents 和 Google ADK Agent 框架之争大多基于直觉。一位工程师坚信 LangGraph 更快，另一位则偏爱 OpenAI Agents SDK，还有人因 Google ADK 感觉更具前瞻性而青睐它。团队选定一种框架，将其工作流接入对应 SDK，选择便由此固化。日后若要更换框架，意味着需拆除原有 SDK 的接线，并在另一框架上重新构建工作流，这是一项代价高昂的重构，鲜有团队愿意承担。本教程使该决策可逆，并以数据定夺。你将 Agent 图部署于 LaunchDarkly，在相同拓扑上运行四种框架（LangGraph、Strands、OpenAI Agents SDK 和 Google ADK），并固定模型，使框架成为唯一变量。LaunchDarkly 实验将依据图延迟和 Token 用量对它们进行排名，并由 LLM 裁判保障质量。结果表将告诉你，哪种框架能在不降低性能的前提下，最快地运行你的图。 Benchmark LangGraph, Strands, OpenAI Agents, and Google ADK on the Same Agent Graph dzone.com +1
AI 辅助与 AI 完成：当今大多数 AI 工作流中的真实差距” 几周前，我参加了一场为期 24 小时的 AI 黑客马拉松，我们利用 AI 构建了一款产品。必要的工具已提供，众多工程师踊跃参与，也有几位业务人员加入，旨在将他们的想法转化为基于 AI 的实体产品。在头脑风暴阶段，大家绘制了端到端的流程架构图，随即开始开发工作，利用当时所有可用的最新模型和平台来构建产品。当开发时间窗口结束时，到了展示环节。在观看各团队展示成果时，我注意到他们无法实现端到端的自动化流程。头脑风暴期间所规划的方案，最终并未形成完整、端到端的产品。大多数解决方案遵循相同的模式：在一个产品中完成某项操作，将输出传递到另一个产品，而该产品的输出又被送往其他地方以完成闭环。 AI Assist vs AI Complete: The Real Gap in Most AI Workflows Today dzone.com +1
在无事件或上下文丢失的情况下编排小型语言模型 小型语言模型（SLM）的可靠编排依赖于稳健的事件流与状态管理。所提出的架构采用具有最小本地状态的小型模型实例。Kafka 作为事件骨干，确保高吞吐交付及分区内顺序性。Temporal 作为编排层，负责管理持久化状态并在故障后重放执行。在此设计中，模型调用被视为可重放的副作用。Temporal 的工作流事件历史（Workflow Event History）作为对话进展的权威记录。尽管 Kafka 在其自身事务边界内提供强一致性保证，但与外部系统的交互需要不同的方法。与外部系统交互的正确性依赖于幂等性、去重、序列检查以及对账。全局精确一次语义无法在所有组件间实现。该设计优先考虑持久性与可重放性，以实现稳定的编排。 Orchestrating Small Language Models Without Losing Events or Context dzone.com +1
为何 AWS 与 Azure 对数据边界的管理方式不同 AWS 若未在网络层实施拒绝策略，可能会将审计日志发送至攻击者的账户，而 Azure 则完全不记录网络阻断请求。 “数据边界”（data perimeter）这一概念由 AWS [1] 推广，旨在围绕身份、资源和网络建立组织边界。简而言之，AWS 提供访问控制，以确保可信身份能够从预期网络访问可信资源，同时阻止所有外部访问。 Why AWS and Azure Handle Data Perimeter Differently dzone.com +1
Kubernetes 中的区域感知路由：降低延迟、提升韧性并减少云成本 本指南从 Kubernetes 优先的视角解释区域感知路由。内容包括： Zone-Aware Routing in Kubernetes: Reducing Latency, Improving Resilience, and Lowering Cloud Costs dzone.com +1
