Greenlight Financial 每月面对最多 4,000 个安全与风险案例，其中超过 90% 无需人工干预即可解决——这组数字来自 AWS 机器学习博客发布的客户案例。Luna，这套构建在 Amazon Bedrock AgentCore 上的自治安全运营中心（SOC），用分层监督多 Agent 架构和情景记忆，在秒级完成暗网泄露卡告警、身份异常和金融风险事件的分诊。

一个必要的前置说明：本文的核心数据——包括 4,000 个月度案例、90% 自动解决率、个位数秒的分诊时间——均来自 AWS 官方客户案例博客。此类内容本质上是云服务商与客户联合发布的营销材料，存在选择性披露的固有倾向：成功指标被突出展示，而整体误报率、漏报率和部署成本等数据未被提及。截至本文发布时，笔者未找到 Greenlight Financial 官方独立发布的技术声明，也未找到独立安全媒体对该案例的第三方报道。读者在评估以下数据时，应将这一来源局限性纳入考量。

尽管如此，对于一家处理敏感金融数据、受银行级监管约束的金融科技公司而言，这套系统的设计逻辑和工程取舍，比最终的自动化比率本身更值得拆解。

告警洪流：每月 4,000 个案例背后的人力瓶颈

Greenlight Financial 为家庭提供金融产品：借记卡、储蓄工具，以及 Family Hub 和 Pet Tracker 等联网设备。据 AWS 博客原文描述，该公司在与大型银行相同的监管要求下大规模处理敏感金融数据。

Luna 诞生的直接原因是告警量与人力之间的数学关系彻底失衡。Greenlight 的 SOC 每月从 4 个主要向量接收 3,000 至 4,000 个安全与风险告警：

暗网泄露卡告警——Card Network 和内部威胁情报标记出出现在暗网上的 Greenlight 客户卡片。仅这一类，Greenlight 每天就收到数百条暗网卡通知。身份与访问异常——来自 Identity Provider（IdP）和内部系统的异常登录模式、权限提升和策略违规。基础设施告警——来自 EDR（端点检测与响应）、SIEM（安全信息与事件管理）、资产清单及其他可观测性工具的信号。金融风险事件——来自卡处理系统的可疑交易模式、合规触发器和欺诈指标。

每一条告警都要求交叉引用多个数据源后才能做出判定。AWS 博客给出了一个具体的工作流描述：单条暗网泄露卡通知需要检查卡片是否仍处于活跃状态、与先前通知去重、审查客户会话数据、检查未关闭的客服工单。这套流程在人工分析师手中需要 15 至 30 分钟。

据 AWS 博客描述，按每月 4,000 个案例、每个案例 15 至 30 分钟计算，每月仅分诊就需要约 1,000 至 2,000 小时的分析师工时。Luna 上线后，据 Greenlight 测算，每月可避免约 900 至 1,800 小时的常规人工工作。

据 AWS 博客描述，Greenlight 对 Luna 提出了 4 项核心要求：以机器速度自主分诊和解决常规案例；将复杂案例连同完整上下文升级给人类分析师；从解决模式中学习以持续提升准确性；在金融服务合规护栏内运行。

这 4 项要求中，前两项是效率问题，第三项是系统演进问题，第四项是准入门槛。在受监管行业，第四项往往决定了前三项的实现方式——自动化程度必须与审计可追溯性共存。

架构拆解：分层监督多 Agent 系统的运行逻辑

Luna 的架构被描述为分层多 Agent 系统（hierarchical multi-agent system），构建在 Amazon Bedrock AgentCore 之上。据 AWS 博客原文，该架构遵循分层监督模式（tiered supervisor pattern），镜像了人类 SOC 团队的运作方式：L1 处理数量，L2 处理复杂度。

Tier 1 Supervisor：高容量分诊层

Tier 1 Supervisor 使用通过 Amazon Bedrock 提供的高级语言模型，运行在 Amazon VPC 内的 Amazon Bedrock AgentCore runtime 上。AgentCore runtime 使用私有子网，通过 ZIP 文件和 Amazon S3 进行直接代码部署。这一层编排超过 30 个专用 Agent，处理传入案例的初始分诊。

案例通过 3 条路径进入 Luna：Tines SOAR（主要的自动化告警摄入来源，也是案例量的主要来源）；Security、Risk 和 ProdOps 工程师通过 Amazon API Gateway 直接调用 Luna Queue API 和 Model Context Protocol（MCP）端点；以及 Claude Desktop extension，供值班工程师通过聊天界面与 Luna 交互，Luna 在该界面中携带完整工具权限进行深度调查。Supervisor 根据告警类型决定调用哪些专用 Agent，综合其发现并做出判定。据 AWS 博客描述，常规案例的中位分诊时间为个位数秒。

这里的架构选择揭示了几个关键设计决策。首先，Luna 使用 AgentCore runtime 托管 agent 代码，使用 AgentCore memory 支撑分层系统——AWS 博客明确指出这”避免了自建和运维这些能力的需要”。对于一家金融科技公司而言，将 Agent 运行时的基础设施运维外包给云服务商，同时保持代码逻辑的自主控制权，是一个典型的”买基础设施、建业务逻辑”的分工模式。

其次，30 多个专用 Agent 的设计意味着 Greenlight 选择了细粒度的职责分离，而非少数通用 Agent。每个 Agent 专注于特定告警类型或数据源的查询与判定，由 Supervisor 负责编排。这种设计的优势在于：单个 Agent 的提示词和工具调用链可以针对特定场景高度优化，降低单次推理的复杂度；同时，新增告警类型时只需增加新的专用 Agent，无需修改现有 Agent 的逻辑。

Tier 2 Supervisor：深度调查层

据 AWS 博客描述，Tier 2 处理的是那 10% 需要多步推理的案例。Tier 2 使用具有扩展推理能力的高级基础模型（advanced foundation model on Amazon Bedrock with extended reasoning capabilities），对升级案例进行更深层的跨源关联重新调查。具体而言，Tier 2 通过 boto3 调用专用 Agent 并使用扩展上下文窗口，在 3 至 5 个数据源之间链式推理以建立因果关系，最终产出包含证据链的详细调查报告供人工复核。

在运行模式上，Tier 2 采用定时与按需相结合的方式：通过 Amazon EventBridge 定时触发和 Amazon SNS 队列完成通知来批量处理升级案例，同时对 Tier 1 升级的紧急案例提供按需处理。

这种 L1/L2 分层的设计直接映射了 SOC 的传统运作模式：L1 分析师处理大量标准化告警，L2 分析师处理需要经验判断的复杂案例。Luna 将这一人类组织模式编码为 Agent 架构，笔者判断其核心优势在于成本控制——高级推理模型的调用成本和延迟远高于标准模型，将大部分案例在 Tier 1 解决意味着只有少数案例需要消耗高级推理资源。

暗网泄露卡处理链：一个具体的 Agent 协作流程

AWS 博客对暗网泄露卡这一告警类型给出了最详细的处理流程描述，可以作为理解 30 多个专用 Agent 如何协作的窗口。

据原文描述，当威胁情报来源（Mastercard 和内部来源）报告暗网泄露卡时，处理链依次展开：首先查询 Galileo（Greenlight 的卡处理系统），确认该卡是否为 Greenlight 发行的卡、是否仍处于活跃状态、近期交易情况；然后在 DynamoDB 中与历史通知去重；接着检查 Mixpanel 中的客户会话数据是否存在异常、Zendesk 中是否有未关闭的客服工单，以及内部欺诈评分。最终，低风险案例记录并监控，中风险案例标记复核，高风险案例连同完整证据链升级给人类分析师。

仅这一个告警类型就涉及 Galileo、DynamoDB、Mixpanel、Zendesk 和内部欺诈评分系统等多个数据源的交叉查询，需要多个专用 Agent 协作完成。其他 3 类告警（身份异常、基础设施告警、金融风险事件）各自也有类似的多源查询链。

情景记忆与 Case-Learnings Pipeline：从无状态工具到持续学习系统

AWS 博客明确指出，记忆层是”将 Luna 与无状态分诊工具区分开来的关键”（”This layer is what separates Luna from a stateless triage tool”）。Luna 的记忆体系建立在 AgentCore memory 之上，分为短期情景记忆和长期记忆两个层次。

情景记忆：30 天滚动窗口

Luna 的情景记忆采用 30 天滚动窗口，存储近期事件与处理结果。据 AWS 博客描述，当新告警到来时，系统会检查”过去 30 天是否见过这个模式？结论是什么？是否应加入白名单？”

AWS 博客给出了一个具体的例子：某基础设施角色每周二凌晨 3 点执行计划维护，产生固定的访问模式。有了情景记忆后，Luna 在第一次处理这类告警后就学会这是预期行为，并自动将其加入白名单。这类场景在传统 SOC 中是典型的”分析师疲劳”来源——同一个已知安全的模式反复触发告警，消耗人工分析时间却不产生安全价值。

长期记忆：超出 30 天窗口的语义偏好与处理模板

超出 30 天滚动窗口的长期记忆保存语义偏好与处理模板。据 AWS 博客描述，Greenlight 的历史案例数据显示”来自某个特定暗网来源的卡片历史误报率为 73%”——这类长期统计结论被编码为处理模板，指导系统在遇到同一来源的告警时优先执行去重操作。

Case-Learnings Pipeline：83% 到 90% 的跃升

Luna 的持续学习能力不仅依赖 AgentCore memory 的通用情景记忆机制，还通过一条专门的 case-learnings pipeline 实现。据 AWS 博客描述，这条 pipeline 的工作流程如下：Lambda 函数从 Tines 事件中抓取每次案例的处理结果；DynamoDB 存储处理模式并去重，当同一种处理方式出现 3 次时，即被记录为 confirmed pattern（已确认模式）；Lambda 将新经验整理为推理时供 Supervisor 使用的上下文，反馈回 Tier 1。

这条 pipeline 的效果有明确的数据支撑。据 AWS 博客描述，Luna 的自主解决率从仅 Tier 1 时的 83% 提升到 Tier 1 + Tier 2 + learnings 综合后的 90% 以上。运行 6 个月后，Luna 积累的机构知识据 AWS 博客描述”一个新的人类分析师需要数月才能建立”。

AgentCore 情景记忆的通用机制

作为背景补充，AWS 于 2026 年 1 月发布的 AgentCore episodic memory 技术博客介绍了情景记忆的通用工作机制：提取（分析进行中的 episode，判断是否完成）、合并（将提取结果合并为单个结构化 episode）、反思（跨 episode 生成洞察，识别可泛化的模式）。该技术博客指出，语义记忆帮助 Agent 记住它知道什么，而情景记忆记录的是它如何到达那里：目标、推理步骤、行动、结果和反思。Luna 的 30 天滚动窗口和长期记忆正是这套通用机制在 SOC 场景中的具体应用。

从 SOC 到金融风险分诊：两个月内完成的架构扩展

据 AWS 博客描述，Greenlight 在 SOC 部署后两个月内将 Luna 扩展到金融风险评估领域。这次扩展的改动是新增专用 Agent 和一个 risk-domain supervisor，同时复用了已有的 Datadog、Zendesk、Mixpanel 等 Agent，新增了 Galileo 和 fraud scoring 等领域 Agent。据 AWS 博客描述，风险域的全面覆盖”正在进行中，约一个月前启动”。

这种扩展的可行性来自分层监督架构的模块化特性。新增金融风险类型的处理，只需在 Supervisor 的路由逻辑中增加新的告警类型识别，并部署对应的专用 Agent。Supervisor 的编排逻辑、Tier 1/Tier 2 的升级机制、情景记忆的学习流水线都可以复用。

从商业角度看，SOC 和金融风险分诊共享大量基础数据源——客户账户信息、交易记录、会话数据、身份验证日志。将两类分诊统一在同一平台上，避免了数据管道的重复建设和维护。同时，某些案例本身就横跨安全和金融风险两个领域——例如暗网泄露卡告警既是安全事件，也可能触发欺诈风险评估——统一架构使这类跨领域案例的处理更加自然。

受监管行业的落地取舍：自动化程度与合规审计的共存

Luna 运行在金融服务合规护栏内，这一约束条件深刻影响了其架构设计的多个层面。

基础设施隔离

据 AWS 博客描述，AgentCore runtime 运行在 Amazon VPC 内，使用私有子网。这意味着 Luna 的 Agent 代码和模型推理在网络层面与公共互联网隔离，敏感金融数据不会离开受控的网络边界。代码通过 ZIP 文件和 Amazon S3 直接部署，避免了依赖外部代码仓库的供应链风险。

人机协作边界

据 AWS 博客描述，Tier 2 处理需要多步推理的 10% 案例，产出包含证据链的详细调查报告供人工复核。更关键的是，AWS 博客明确指出，Greenlight 将 Luna 设计为”分诊和推荐”（triage and recommend），而非在没有明确策略批准的情况下自主执行处置动作。实际的处置由人类分析师或已批准的自动化策略授权执行。

这一设计选择在受监管行业中至关重要。完全自主的安全运营在金融服务中面临监管审查风险——监管机构通常要求关键安全决策具有人类可追溯的审批链。Luna 的分层架构提供了一个清晰的人机边界：Tier 1 处理标准化、高置信度的常规案例；Tier 2 处理复杂案例并在必要时升级给人类。这种设计使 Greenlight 能够在监管审查中展示”人类始终在环中”的治理模式，同时将人类分析师的时间集中在真正需要判断力的案例上。

案例摄入的三条路径

Luna 的 3 条案例摄入路径——Tines SOAR、API Gateway 直接调用、Claude Desktop extension——覆盖了不同的使用场景。Tines SOAR 承载主要的自动化告警量；API 接口供工程师程序化提交案例；Claude Desktop extension 则为值班工程师提供了一个交互式深度调查界面。三条路径的并存意味着 Luna 既是一个自动化分诊引擎，也是一个可供人类分析师按需调用的调查工具。

MCP 协议的角色

Luna 的架构中，Tier 1 Supervisor 通过 API Gateway 暴露 MCP 端点。

生产指标的解读与局限

AWS 博客提供了几个关键的生产指标，但同样重要的是理解这些指标没有告诉我们什么。

已知指标（均来自 AWS 客户案例博客）：每月最多 4,000 个安全与风险案例；每天数百条暗网卡通知；超过 90% 无需人工干预即可解决（其中仅 Tier 1 的自主解决率为 83%，加上 Tier 2 和 case-learnings pipeline 后提升至 90% 以上）；Tier 2 处理 10% 需要多步推理的案例；常规案例的中位分诊时间为个位数秒；人工处理单个暗网泄露卡通知需要 15 至 30 分钟；使用 30 多个专用 Agent；系统已运行 6 个月；来自特定暗网来源的卡片历史误报率为 73%；每月避免约 900 至 1,800 小时的常规人工工作。

未公开的指标：截至本文发布时，AWS 博客未提供 Luna 的整体误报率（false positive rate）和漏报率（false negative rate）、Tier 2 升级案例中最终需要人类介入的比例，以及 Luna 的部署成本与等效人力成本的对比。

笔者判断，在受监管金融行业，整体误报率和漏报率是比自动化比率更关键的指标。90% 的自动解决率如果伴随着较高的漏报率（将真正的安全威胁错误地标记为安全），其风险远大于收益。AWS 博客虽然给出了单一暗网来源 73% 误报率的数据点，但未提供系统整体的误报和漏报表现。作为 AWS 官方客户案例博客，其内容经过供应商和客户双方的审核，倾向于展示积极成果，这是此类来源的固有特征，读者应据此校准对数据的信任度。

此外，”个位数秒”的中位分诊时间与人工 15 至 30 分钟的对比，虽然在速度上差距显著，但速度本身在安全运营中并非唯一价值维度。更关键的价值在于一致性——30 多个专用 Agent 按照确定性的逻辑执行交叉查询和判定，消除了人类分析师因疲劳、经验差异和注意力分散导致的判定不一致性。在每月 3,000 至 4,000 个案例的规模下，这种一致性的价值可能比速度提升更为显著。

自治 SOC 的可行边界

从更广泛的行业视角看，Luna 的架构模式——分层监督 + 专用 Agent + 情景记忆——并非 SOC 特有。任何面临高容量、多类型、需要交叉验证的案例分诊场景（合规审查、客服升级、供应链风险评估）都可能适用类似架构。关键约束在于：场景是否具有足够的结构化程度，使得 Agent 的判定逻辑可以被明确定义和验证；以及行业监管是否允许在特定决策环节实现自动化。

笔者判断，Luna 案例中真正的护城河在于 Greenlight 对自身业务场景的深度理解——30 多个专用 Agent 各自处理哪些告警类型、Tier 1/Tier 2 的升级阈值如何设定、哪些案例模式可以自动闭环而哪些必须人类介入，这些领域知识无法从通用平台中直接获取，需要安全运营团队和 Agent 工程团队的深度协作。据原文，case-learnings pipeline 推动自主解决率从 83%（仅 Tier 1）提升到 90% 以上（Tier 1、Tier 2 加上 learnings），这条 pipeline 的设计——3 次出现即确认模式、Lambda + DynamoDB 的轻量实现——体现的是工程务实性而非技术复杂性。

在受监管行业，自治 Agent 的可行边界不在于技术能力的上限，而在于组织对”哪些决策可以自动化”这一问题的清晰回答。Greenlight 的回答是”分诊和推荐可以自动化，处置执行必须经过人类或已批准策略的授权”——这个边界的划定方式，对同类受监管行业的 Agent 部署具有参考价值。但这个答案的完整性，仍有待独立来源的验证和更长时间维度的生产数据检验。

参考资料

  1. How Greenlight Financial built an autonomous SOC solution on Amazon Bedrock AgentCore — AWS Machine Learning Blog, 2026-11-06
  2. Build agents to learn from experiences using Amazon Bedrock AgentCore episodic memory — AWS Machine Learning Blog, 2026-01-21
  3. Episodic memory strategy - Amazon Bedrock AgentCore Developer Guide — AWS Documentation, 日期未知

主题分类：企业AI落地