并非所有数据集都完全适合存储在数据仓库中。采用基于 S3 的 Apache Iceberg、Redshift Spectrum 以及 Redshift 本地表的混合架构，可以减少重复存储，并将数据仓库的性能保留给真正需要的工作负载。 数据仓库沦为第二个数据湖 Redshift 集群中经常存放着本不该存在的表。五年的交易历史通过每晚一次的 COPY 作业加载，耗时四小时，却仅在每季度查询两次。原始事件表直接落入了数据仓库，因为数据湖管道的搭建更为复杂。那些无人负责的聚合表因删除它们令人感到风险而一直被保留下来。

从麦肯锡到波士顿咨询集团（BCG），从欧盟到国际标准化组织（ISO），再到全球各地的供应商和咨询公司，每家机构都有自己的 AI 就绪度评估版本。快速搜索即可发现数十种此类评估，它们每日都会出现在我的信息流中。有些评估流于表面、浅尝辄止，有些则细致入微、深思熟虑。有的只是一系列随机问题，而另一些则被精心划分为战略、数据、技术、人才、治理和文化等要素。有的可在一个小时内完成，而另一些则需要大量的准备工作、探索过程以及多方参与。 这些评估都存在此类工具共有的缺陷：它们依赖自我报告、自我评分和自我解读。所有民意调查员都深知，自我报告的数据天生就值得怀疑。民意调查员和研究者将人们在缺乏外部校准的情况下进行自我评估的现象称为“偏差”，这一现象已得到详尽研究。

大多数企业级 AI 项目在概念验证阶段之后便停滞不前，原因在于其周围的运营基础尚未就绪。 这种失败很少源于单一问题，而是来自碎片化的数据生态系统、合规差距、可观测性不足，以及从一开始就未曾构建好以应对生产级 AI 的治理结构。

MovieManager 项目已更新为使用 JDK 25 以及来自 Leyden 项目的 AOT 缓存。Leyden 项目是 OpenJDK 项目的一部分，提供缓存链接和缓存性能统计功能。这意味着启动时的链接时间被移至构建时间，且性能统计也在构建期间的测试运行中生成。 因此，JVM 会加载已链接所需的类，并立即开始编译热点代码路径。借助这些优化，MovieManager 应用程序的启动时间缩短至不到原来的一半，且无需任何代码修改。

周五下午 3 点，安全通告发布：一个广泛使用的 Windows 服务中存在关键零日漏洞。您需要管理分布在 50 个地点的 5,000 个终端，每个地点的维护窗口、备份计划及关键性等级各不相同。您需要对所有终端进行补丁更新，但必须在验证磁盘空间充足、确认近期备份已完成，并尊重生产计划的前提下进行。使用传统工具，这意味着一个周末的手工劳动和电子表格追踪；而借助现代 RMM 平台，这仅是一个策略配置问题。 这就是现代 IT 运营的现实：从被动救火转向主动、策略驱动的运维管理。对于系统管理员、架构师和 DevOps 工程师而言，这要求采用基于现代架构原则构建的 RMM 平台。这些原则能够支持自动化、智能告警以及无缝集成。

人工智能正超越基础的聊天界面，在企业应用中发挥积极作用。虽然早期的 AI 集成往往侧重于文本生成、摘要或检索增强生成（RAG），但许多业务挑战需要更高级的解决方案。这些方案要求将复杂目标分解为顺序任务，并协调其执行。规划模式（Planning Pattern）通过使 AI 既能作为内容生成器，又能作为制定执行计划的策略师，来满足这一需求。 对于软件工程师和架构师而言，规划模式标志着智能系统的重要进步。它将推理与执行分离，使应用程序能够在企业环境中使用大型语言模型，同时确保治理、可观测性和可靠性。

生成式 AI 整合热潮的账单已经到来，其计价单位是出站成本、Token 膨胀以及闲置容器内存。 过去两年间，工程团队通过阻力最小的路径集成了 LLM：将模型叠加在现有架构之上。对于面向人类的使用场景，这种方式行得通。人类能够提供隐式上下文，容忍轻微的延迟，并直观地纠正错误。

本文是《构建闭环图 RAG 系统》四部分系列文章的第三部分。 简而言之，收集反馈非常容易；但利用这些反馈来构建安全环境，其难度远超人们的想象。 大多数 RAG 模型最终都会允许用户提供某种形式的反馈，例如点赞或点踩、用户评论、专家评估、对推荐答案或先前问题的点击、对答案的接受或拒绝，以及任务的成功或失败。而大多数情况下，这些模型的开发者仅仅假设：只要他们听取了用户的反馈，模型就会学习并变得更好。

XB Software 的管理团队花费数小时手动从数十份开发人员报告中提取工作项（如“修复 bug"、“发布版本 1"等）。该任务重复繁琐且易出错，若使用基于云的 AI 工具，则意味着将内部活动暴露于外部服务器，从而构成安全风险。 为解决这一问题，我们构建了一个完全运行于自有服务器上的本地 LLM 驱动代理，用于规范化混乱的报告数据、过滤无用噪声、从 Jira 丰富描述信息，并生成清晰的实际成果清单。在本文中，我们将剖析其架构，并解释为何对于将数据隐私置于首位的企业客户而言，采用仅依赖 CPU 的本地化方案是切实可行的。

如果你曾经写过原生 JDBC，就知道接下来会发生什么。打开连接，创建 PreparedStatement，按索引设置参数（希望你数对了），遍历 ResultSet，在 finally 块中关闭所有资源，在每个方法签名上声明 SQLException……为了‘给我一些行’，这仪式感太重了。 我一直在尝试 Ujorm3，这是一款面向 Java 17+ 的新轻量级 ORM 库。下面是一个真实示例——一个包含嵌套关系的 JOIN 查询，并将结果映射出来：

“氛围式编码”（vibe coding）——即微调提示词、运行一次并观察结果是否可行——无法扩展至企业级软件。以下是如何构建严格的验证流水线，以审计、基准测试并评估您的 Claude 代理行为随时间变化的方法。 如果您正在使用 Claude API 构建自主代理，很可能已陷入“氛围式编码”的陷阱。其典型过程如下：编写一个提示词，赋予 Claude 工具访问权限，在终端中执行一次测试运行，并观察其成功。

几年前，我运行着一个时间序列管道，该管道对传入的产品评论进行 1 到 10 分的评分。评分器是一个 LLM。评论持续流入，评分数据汇入仪表板，产品团队每周一早晨查看。一切运行平稳数月。直到一个周一，图表上出现了一个突变。 上一周的评论平均分为 6.4，而本周的平均分跃升至 7.6。同一产品，同一批客户。当我回溯阅读这些评论时，它们与我们全年收到的评论几乎无法区分。

Apache Spark 是数据与人工智能工程领域中最强大的工具之一。它能够帮助处理海量数据集，并在各行各业中广泛应用，不受云平台的限制。 然而，当你从学习 Spark 过渡到在生产环境中运行它时，便会开始面临真正的挑战。

数十年来，软件行业已将数据库、API、消息系统和分布式服务集成到企业应用中。如今，大型语言模型（LLM）已成为一种新的架构组件。尽管人们对人工智能的兴趣广泛且教程众多，许多工程团队仍面临一个根本性问题：如何将人工智能集成到软件系统中？ 人工智能的集成并不遵循单一的架构风格。例如，检索增强生成（RAG）应用与能够利用工具进行推理的自主智能体运作方式不同。同样，反思工作流在多智能体系统方面具有独特的特征、风险和运营需求。若缺乏清晰的框架，团队可能直接跳入实施阶段，导致解决方案过于复杂、难以管理，且与业务目标不一致。

搜索代理已成为前沿语言模型的基础设施，但其开发仍被禁锢在企业围墙之内。这些系统需要应对一个根本性的难题：在拥有工具访问权限和知识库的前提下，进行系统性探索，智能地决定应遵循哪些路径，并知晓何时调整策略。与能够凭借直觉和常识的人类研究者不同，大语言模型代理仅能依托训练期间所学的知识，因此需要明确的指令来指导其如何高效搜索。 实际影响至关重要。搜索代理赋能研究工具、基于网络的推理系统以及复杂的信息检索。然而，大多数突破均发生在预算无限的企业内部。学术研究者面临困境：行之有效的技术属于专有技术，数据集私有化，且所需的计算资源看似天文数字。这造成了令人沮丧的瓶颈：创新集中于工业研究实验室，而更广泛的研究社区则无法开展实验、迭代优化，或对该领域做出有意义的贡献。

我们都有这样的日常习惯：打开十几个浏览器标签页，查看我们喜爱的开源项目的健康状况和进展。对我而言，就是密切关注像 Docling 和 watsonx Agent Development Kit (ADK) 这样快速演进的生态系统。最终，手动刷新不得不停止。我决定构建一个自定义应用程序来自动化这一工作流——或者更准确地说，构建一个专用的 Agent。 在将"Agent"仅仅视为另一个行业 buzzword 之前，请思考这一点：真正的能动性（agency）不仅关乎复杂的 LLM 推理，更关乎自主执行。Agent 弥合了人工操作与自动化一致性之间的鸿沟，接手那些曾经需要我们逐点击关注才能完成的任务。

本文是《构建闭环图 RAG 系统》四部分系列文章的第二部分。在使用大语言模型系统时，最常见的错误之一便是因某个建议看似合乎逻辑而盲目采纳。

您拥有一个合同文件夹、一年的会议纪要、三份产品规格 PDF 以及一份您一直打算认真研读的研究报告。您的 AI 助手非常聪明，但它无法看到任何这些内容。每次对话都从零开始。您手动粘贴片段、复制粘贴摘要，得到的答案仍然遗漏了规格书第 14 页中埋藏的细微差别。 根本原因在于架构。AI 助手受限于上下文窗口——即它们一次能容纳的文本量。单个冗长的 PDF 就可能填满整个上下文窗口。包含一百个文档的文件夹则完全超出了其能力范围。您无法将整个文档库交给助手并提问；数学上就不允许这样做。

2024 年 11 月一个周四凌晨 3:07，费用管理代理完成了其夜间批处理运行，并将作业状态标记为成功。 它在 77 分钟的窗口期内处理了 214 条费用条目。每一次 API 调用均返回 200 状态码，每一个授权令牌的范围均正确无误。工作流编排器记录了正常完成，审计轨迹清晰、已加盖时间戳并经过签名。

本文是《构建闭环图 RAG 系统》四部分系列文章的第一部分。 大多数团队最初并没有知识图谱，他们只拥有一批文档、一个向量数据库、一种分块方法以及一个提示词。这完全没问题。通过简单的检索增强生成系统，即可回答许多实际性问题，例如“部署指南在哪里？”“该政策的具体内容是什么？”“哪个 API 参数控制重试？”对于此类用途，扁平化 RAG 几乎总是足够的。系统会接收您的查询，检索最匹配的片段，向语言模型提供相关上下文，并让语言模型生成答案。 问题出在您希望系统能够对关系进行推理时。

如果你看过一个打磨精致的 AI 聊天机器人演示，随后又目睹自己的生产部署在真实用户上线的瞬间分崩离析，你并不孤单。Bitontree 自 2019 年以来一直专注于构建定制 AI 系统——涵盖聊天机器人、智能体、自动化工作流、RAG 系统，以及横跨医疗、物流、招聘、教育和电商领域的集成方案。在超过 25 个生产部署中，无论行业、客户规模或模型选择如何，始终反复出现五种失败模式。 本文是一份实战指南，深入剖析大规模 AI 聊天机器人部署中真正导致失败的原因，并为每种失败模式提供代码模式与架构修复方案。

在过去的二十年中，我的代码已在生产环境中部署。我曾破坏黑五期间的压力测试流程，导致凌晨 2 点用户认证失效，也曾目睹一个承载 4000 万用户的系统因配置文件中的微小修改而崩溃。

本周的发布博文特意采用了不同的形式。周五的汇总文章篇幅越来越长，这从两方面对我们不利：搜索引擎优化（SEO）会忽略涵盖十二个不相关主题的 5000 字长文，导致实际内容被埋没，而无法针对本应检索到它的查询词进行索引；而当一篇发布博文涵盖十项内容时，若要同事定位“几周前的那一项 Codename One 变更”，往往需要滚动十分钟。 因此，从本周起，周五的博文将保持简短：仅包含一组头条新闻和“即将推出”列表，仅此而已。具体功能将在随后几天发布独立博文，拥有各自的 URL 路径、可搜索的标题以及独立的讨论线程。每周的博文作为索引置于首页顶部；深层博文通过反向链接指向它，您可以根据项目实际需求阅读其中相关的内容。

当我开始与 AI 智能体协作时，最困难的往往并非获得答案，而是理解智能体是如何得出该答案的。最终回复可能看似合理，但其背后的推理路径却常常模糊不清。

第一部分探讨了在代理系统中应追踪什么以及为何如此。传统追踪与指标（如延迟、扩展性、成本、可用性和吞吐量）需要如何重新定义。以及如何定义代理系统核心的新指标，例如响应质量、准确性和任务完成度。 本部分聚焦于机制：追踪的结构如何构建，上下文如何在代理边界间传播，以及如何理解所有这些内容。

零停机部署常被描述为一种发布策略，但在生产环境中，它更准确地说是一个协调问题。流量必须保持在健康实例上，直到新实例预热完成；控制器必须在就绪之前等待再分配负载；当指标恶化时，升级必须干净地停止。 Kubernetes 的滚动更新已能逐步替换 Pod，并在移除旧实例前等待新实例启动，同时通过就绪探针判断何时应向 Pod 分配流量。渐进式交付系统（如 Argo Rollouts）则增加了加权流量切换、暂停和分析门控。难点不在于各个基础组件本身，而在于当重试、人工审批、控制器重启和回滚决策相互交织时，围绕所有这些组件的状态化控制流。

当你在凌晨 2 点排查由你的代理（agent）引发的事件时，此刻唯一重要的是你是否能理解代理为何做出该行为。 在代理式 AI 浪潮推进十八个月后，代理所记录的内容与人类所需信息之间的差距，已成为大多数团队面临的主要瓶颈。回答“代理做了什么”轻而易举，但解释“代理为何这么做”却难上加难。

Kafka 与 Temporal 分别解决了分布式系统中至关重要的不同故障边界，二者共同构建高可用系统。Kafka 擅长在多个消费者和机器之间有序、可重放地传输事件流；而 Temporal 则通过持久化的工作流执行（Workflow Executions），确保长运行应用逻辑在崩溃和重启后依然持续。当 Kafka 负责承载事实（facts），Temporal 负责管理业务流程中的意图、定时器、重试与补偿时，二者结合最为强大。Kafka 凭借其有序分区和消费者组模型，非常适合服务集成、流式处理与服务解耦；然而，它本身并不原生提供针对复杂、长周期业务逻辑的持久化编排。Temporal 通过充当可靠且可扩展的函数，维护本地状态，从而克服这一局限。它通过重放已持久化的历史来推进执行，而非在故障后从头重启。这种组合使得 Kafka 能够作为事件骨干，而 Temporal 则作为业务流程的控制平面。

如今，使用技能文件（SKILL.md）已成为向大语言模型（LLM）或智能体提供上下文和知识（或如官方技能规范网站所述的新能力和专业知识）的常见方式。 从基础设施的角度来看，一个技能是一个文件夹，其中包含 SKILL.md 文件以及使其能够运行的所有必要文件：脚本、参考资料等。该文件夹必须位于 .agents/skills（或 .claude/skills，或您的智能体工具所使用的其他名称）中。

设想一个简单场景：一个 AI 代理已接入 Salesforce 中的“案件”页面。客户回复称问题似乎已解决。该代理阅读对话后，判定案件可关闭，并将状态更新为“已关闭”。 一周后，客户致电表示沮丧：“你们为何关闭了我的案件？我的问题并未解决。”

在本文中，我们将探讨 Amazon OpenSearch 中的向量搜索工作原理，并介绍如何将其作为检索增强生成（RAG）系统的检索层加以使用。本文面向软件工程师。我们不仅限于理论阐述，还将构建一个可在您本地机器上运行并逐步跟随的小型可工作示例。 到文章结束时，您将拥有一个小型文档搜索服务，该服务能够接收用户提问，利用向量相似度查找最相关的文本，并准备可传递给语言模型的上下文。

图形工程团队的缺陷分派（Bug triage）是那些没人真正愿意承担的任务。一份新的崩溃报告到来时，必须有人判断这是否属于已知问题、堆栈跟踪指向何处、受影响代码位于哪个子系统，以及应由哪个子团队接手。答案存在于问题追踪器、源代码仓库和架构文档中，但人工整合这些信息耗时费力。而最擅长此道的工程师，恰恰是那些你最不希望他们花费数小时在此项工作上的。 在我们团队，已解决的缺陷档案已增长至超过 1,100 个问题。这实际上构成了一个语料库。它包含大量 incoming 问题的答案，但前提是你能快速找到正确的三到四个条目。本文描述的代理（agent）可自动执行此类查找，并结合崩溃日志解析与源代码搜索，生成带有置信度分数的根本原因分析。原本需要数小时的分派工作，现在仅需几分钟即可完成。

这篇文章涵盖的内容很多。在深入讨论之前，我想首先直面一个令人不适的话题：质量。过去两周内发生的两起事件值得公开说明：一起是我们正常迭代周期中出现的 bug，另一起是我个人的严重失误。无论哪一方，我都希望如果身处对方立场，也能得到同样坦诚的解释。 什么是 Codename One？Codename One 是一个开源框架，用于从单一的 Java 或 Kotlin 代码库构建原生 iOS、Android、桌面及 Web 应用。更多信息请访问 codenameone.com。 我们如何看待质量 Codename One 是一家小型开源公司。我们并非拥有 200 名工程师的平台团队，也没有专门的 SRE 轮值机制和独立的 QA 组织。我们行动迅速，足以每周发布具有实质意义的新代码，同时投入大量精力确保这种速度不会以破坏用户应用为代价。

我为一个向流媒体设备发布软件的图形团队运行自动化测试。大约一年前，我们改变了视觉回归测试套件存储和比较参考图像的方式。旧方法在测试仓库中保留了约 18GB 的 PNG 格式黄金图像，并在每次比较时执行逐像素差异分析。新方法则将约 19KB 的 MD5 哈希值存储在一个 JSON 文件中，并比较哈希字符串。存储量减少了约三个数量级。比较操作变得几乎免费。一类原本不稳定的测试因此不再出现不稳定现象。 本文介绍该方法的运作原理、适用场景及不适用场景。此外，还会涵盖令我感到意外的部分，因为该方法存在实际缺点，我需要在开头就坦诚说明。

AWS 已在此领域构建代理基础设施一段时间——包括 Bedrock、AgentCore 和 Strands——主要面向希望从头构建自有代理系统的工程师。Amazon Quick 则是同一战略下的不同层级：一个即用的代理工作空间，直接面向团队，无需编写自定义编排代码。 本文将介绍 Quick 是什么，其组件在技术上的集成方式，MCP 集成模型如何通过实际代码运作，以及它在 AWS 代理整体架构中的定位。

查询存储的加权基线回归模式 SQL Server 中的计划回归通常悄无声息地发生。一个长期稳定的查询突然变慢，尽管没有部署、架构变更或明显的底层基础设施问题。在许多情况下，问题是由统计信息更新、参数敏感性、数据分布变化或优化器正常行为所导致的执行计划变更引起的。 问题 一个常见的起点是使用平均持续时间进行“昨日与今日”的比较。虽然这种方法快速，但往往无法全面反映工作负载的实际行为。

“无人提及，直到账单到来”的隐形杀手 大多数关于“生产级代理 AI"的文章止步于问题开端：成本。与 Claude 或 GPT 交互需要一个自然的速度调节器：你，阅读生成的文本。将该代理从聊天模式移出，投入 CI/CD、夜间批处理或 Webhook 处理中，速度调节便不复存在，系统完全依赖计算机时间运行，按计算机算力计费。 深入挖掘后，数字显得更为触目惊心。ReAct 风格的循环执行会将所有输出作为前缀附加到后续提示中，导致 token 消耗量约为 O(n²)。一个在本地开发中每轮三步循环成本为 0.04 美元的 PR 审查代理，一旦陷入循环过程，费用可能飙升至 0.40 美元以上。若每周处理数百个 PR，账单中极易出现五位数的意外支出。

代理 AI 演示随处可见，而生产级代理 AI 却十分罕见。两者之间的差距并非模型问题，而是工程问题，且分布式系统工程师处于解决这一问题的独特位置。 大多数团队的直觉是将大语言模型视为最难的部分：微调它、精心设计提示词、选择合适的模型规模，然后发布。然而，一旦代理进入循环运行（规划、调用工具、观察结果、重新规划），模型便成为你最不担心的问题。破坏生产级代理系统的，是模型周围的一切：如何在多轮交互中管理上下文、多步计划中的故障如何传播、如何深入追踪三个工具调用后出现的问题，以及如何防止单个糟糕的计划造成不可逆的损害。这些问题本质上是披着 AI 外衣的分布式系统问题。

这是当一切正常、无人犯错时，生产级级联（production cascade）应有的表现。 一个微服务发出延迟升高的告警。该信号准确无误。自动化修复代理立即捕获该信号，并执行其被构建来执行的操作：重启受影响的微服务并重新路由流量。该操作在权限范围内，凭据有效，三秒后平台即报告修复成功。

"2025 本应是智能体重塑企业的年份，但炒作最终被证明大多为过早。这并非努力不足，而是方法不当。" ——凯特·詹森，Anthropic 美洲区负责人，《科技趋势》，2026 年 2 月 詹森的诊断精准无误，而她做出这一判断的时间点——2026 年 2 月，即智能体部署浪潮达到顶峰后的十二个月——尤为关键。2025 年陷入困境的团队，并非缺乏雄心或资源，而是缺乏一套连贯的架构，用于明确构建什么、采购什么，以及如何治理两者之间的边界。

我们在几年前就将生产环境容器化了，随后不久也容器化了 CI 流程。然而，工程师们实际花费大部分工作时间的地方——笔记本电脑上的本地开发循环——对于大多数团队而言，仍然是整个技术栈中可复现性最差的部分。 本文将讲述这种现象产生的原因，为何在过去几年中情况反而恶化而非改善，以及我为解决自身工作中的这一问题最终构建了什么。

构建可扩展的数据系统，往往如同在瞬息万变的范式海洋中航行。工程师与架构师不得不不断在集中式与分布式数据之间、批处理与实时流处理之间、严格合规与快速自助分析之间做出抉择。若缺乏结构化的分类体系，工程团队极易构建出碎片化的数据管道，进而累积技术债务。 以下是一份全面的蓝图，作为权威的数据模式与实践库，旨在协助您将基础设施与经过验证的工程方法论相统一。

大规模云平台已达到极高的复杂性——涵盖多区域 Kubernetes 集群、Kafka 等流式系统以及异构数据存储——其复杂度往往超出人类认知极限。故障不再是孤立事件，而是紧密耦合系统中涌现的行为，问题会在网络、编排和数据管道等层级间传播。即便拥有现代化的可观测性栈，运维人员仍需在仪表板间手动关联信号，导致事件响应缓慢、不一致且认知负担沉重。 传统方法高度依赖静态运行手册和“部落知识”。这些机制无法在现代分布式系统中扩展。智能体 AI 引入了一种根本不同的范式。与传统 AIOps 仅检测异常不同，智能体系统利用大语言模型（LLM）进行推理、规划并执行行动。这些系统能够迭代生成假设，利用真实数据进行验证，并执行多步骤的修复工作流。其结果不仅是更快的检测，更是一个具备自主诊断与恢复能力的闭环系统。

本文由 TechnologyWire 提供，不代表 DZone 的编辑内容。 美国纽约，2026 年 6 月 8 日，TechnologyWire

想象一下，你的团队刚刚为你们开发的 SaaS 平台部署了一款基于 RAG 的文档助手。在测试阶段，它运行完美：它熟悉平台功能，能用三段措辞精准的文字回答问题，且毫无幻觉。然而，上线两天后，一位资深开发人员在 Slack 上提醒你：“嘿，AI 机器人找不到关于 PX-9000-v2 配置错误的任何信息。” 你检查了日志。用户查询了确切的错误代码。向量搜索针对语义含义进行了优化，返回了关于通用错误处理和配置最佳实践的文档，但 PX-9000-v2 的具体技术描述却淹没在检索器结果（或分块）的第 50 位，因为其“语义”距离与“错误”这一通用概念相距太远。

在优化 Spring Boot 集成测试时，开发人员往往关注显而易见的指标：总构建时间、测试执行时间、CPU 使用率、内存消耗或失败测试的数量。这些指标很有用，但并不总能解释为什么集成测试套件运行缓慢。Spring Boot 集成测试中最重要的隐藏指标之一是在测试运行期间创建的 ApplicationContext 实例数量，请查看我的其他文章。 Spring 的 TestContext 框架可以在测试类之间缓存并复用 ApplicationContext，但前提是有效的测试配置必须相同。如果配置不同，Spring 就必须创建新的上下文。在大型企业应用中，这可能会迅速变得代价高昂。

本系列文章是为希望了解云原生计算基金会（CNCF）项目 Fluent Bit 的读者提供的一份通用入门指南。 本系列中的每篇文章都聚焦于一个特定主题，通过阐述该主题是什么、我们为何关注该主题、如何开始学习该主题，以及如何结合 Fluent Bit 项目开展实践操作，来提供相关见解。

随着大量预训练的大语言模型（LLM）现成可用，将其集成到应用中已变得日益便捷。然而，将其部署到生产环境则完全是另一回事。在本文中，我将介绍我所采用的模式，用于将基于 OpenAI 模型和 LangGraph 的代理式 AI 解决方案部署至生产环境，并托管于 AWS ECS Fargate 之上。 为何选择 ECS Fargate 选择 ECS Fargate 而非 SageMaker 的主要原因是其简洁性。Fargate 为完全托管且按需的服务，意味着不存在闲置基础设施成本。您只需为实际运行的资源付费，无需操心底层 EC2 实例的管理。对于希望获得生产级托管能力且无需承担运营负担的团队而言，Fargate 是一个务实的折中方案。Lambda 因明显原因（如冷启动延迟和内存限制）已被排除在外，使其不适用于任何 LLM 工作负载。

大多数 AI Agent 框架将模型视为黑盒：注册工具，模型选择其一，工具执行，然后循环重复。这种模式非常适合演示，但对于生产系统而言，则需要更复杂的架构。我们需要管理上下文窗口、缓存 API 调用、按角色过滤敏感工具，并压缩模型内的信息历史以避免令牌限制。 我在审查 deepagents 的 issue 并理解其代码库时，选择了中间件（middleware）这一方向。这也让我开始思考：在 AI Agent 的语境下，中间件究竟是什么，以及它为何重要。这促使我进一步思考：其他框架是如何处理这一问题的？于是，我安装了 Pydantic AI，阅读了 CrewAI 的源码，并检查了 Langchain 和 Autogen。

当 PHP 开发者比较 XML 方案时，往往从错误的地方开始。 这通常演变成一个模糊的问题，例如："PHP 中最好的 XML 库是什么？”这个问题过于宽泛，无法提供实际帮助。