亚马逊AWS官方博客

将 Dify 工作流迁移至 Amazon Bedrock AgentCore 的实践与验证

新版 Dify 把工作流执行引擎从平台中解耦为一个独立的 Python 库 graphon。迁移一条 workflow 因此只需安装这个库并适配少数几类节点，不必搬整个平台。我们用一个 PoC 验证了这条路径。一条 20 步的 KYB（商户准入尽调）workflow，覆盖调模型、调代码、调知识库和多路判断，业务逻辑一行不改，通过自定义 node factory 部署并运行在 AgentCore Runtime 上，云端 5 条分支路径全部验证通过。同一份 DSL 还能导回 Dify 画布渲染。本文给出这条路径的做法、部署证据，以及版本风险和生产化前需要补齐的边界。

当知识可以被”编译” —— LLM Wiki 企业级实践的三道坎

传统 RAG 在每次查询时重新检索、重新拼装答案——源文档像被反复”解释执行”的脚本。LLM Wiki 换了一条路：在文档入库时预先”编译”为结构化知识页，此后持续维护、增量更新。经过四个月的实践，我们逐渐遇到了企业级落地中三个绕不开的”坎”。本文拆解这些挑战的根因，介绍基于 Amazon Bedrock、AWS Step Functions 与 Amazon S3 的解法，并给出生产环境中的量化验证。

从分钟到秒级 —— Amazon Advanced JDBC Wrapper 插件最佳实践

数据库的计划内变更（版本升级、打补丁、规格调整）和计划外故障（实例 Failover），都会让应用经历一段连接中断。多数团队会把优化目光投向数据库实例本身，却忽略了一个事实：客户端的连接行为往往是中断被放大的主因。Amazon Web Services Advanced JDBC Wrapper（下称 JDBC Wrapper）正是从这个角度切入——它包裹在现有 JDBC 驱动之外，让 Java 应用主动感知数据库拓扑变化、提前调度连接，把切换中断压到秒级。本文从原理到实测，拆解它是怎么做到的。

为游戏业务团队构建只读代码问答 Agent：架构、性能与安全实践

游戏规则、数值和活动配置最终由代码与项目配置决定。策划、测试、运营和客服在核对规则或处理玩家反馈时，往往需要研发协助定位实现，零散问题因此反复打断研发工作。为缩短这条确认链路，我们构建了一套只读代码问答 Agent：代码副本和索引集中保存在常驻服务中，会话环境只通过 HTTP 上的只读 MCP 工具查询代码和配置。本文分别从业务体验和技术实施角度，介绍方案功能、准确性机制、安全边界、性能、管理方式与成本，并结合合成样本测试和游戏客户的试用结果说明实际表现。

地理空间 AI 智能体（Code Agent）中国区部署实践

在农业遥感监测、自然资源调查、城市规划、碳汇核算、保险定损等领域，企业客户日益需要对卫星影像进行快速分析。传统工作流要求GIS专业人员编写Python代码处理遥感数据，门槛高、周期长、成本大。亚马逊云科技开源项目 sample-geospatial-code-agent（https://github.com/aws-samples/sample-geospatial-code-agent）提供了一套AI智能体方案，让非技术用户也能通过自然语言完成专业级遥感分析。该方案采用Code Agent架构——LLM直接生成Python脚本执行，中间数据留在内存不回传上下文，相比传统Tool Agent在遥感分析场景中速度更快、成本更低。但原项目基于海外区服务生态构建，其底图方案（Google/CARTO瓦片）和部分托管服务无法在中国区直接运行，需要针对中国区进行适配。

混合云架构下秒级多维网络监控方案

本文介绍一种面向混合云、跨可用区及本地数据中心网络链路的秒级主动拨测方案。方案通过部署轻量探针 Agent，在探测端使用 fping 与 nping 分别覆盖 ICMP 与 TCP SYN 场景，并结合 EC2 实例元数据、Prometheus、Grafana 与通知渠道，实现按源实例、私网 IP、可用区、目标端点和探测方式维度聚合的网络质量可观测能力。

← Older posts
Newer posts →