金融安全运营如何用多 Agent 自动分流

Greenlight Financial 把每月 3,000–4,000 起安全与风险案例交给 Luna 分诊，报告称超过 90% 无需人工介入，常规案例的分诊中位耗时降到个位数秒。它依靠分层主管、30 多个专用 Agent，以及持续回流的处理记录完成判断。

这套系统值得看的地方，是它怎样把调查流程拆成可复用的能力，同时保留人工处置边界。不过，自动解决率并不等于判断准确率，从 83% 提升到超过 90% 的效果，也不能全部归功于记忆。

为什么先让 Agent 分诊，再让人决定怎么处置

Greenlight 为家庭提供借记卡、储蓄工具及 Family Hub、Pet Tracker 等设备，处理敏感金融数据。它收到的告警来自四类来源：暗网泄露卡、身份与访问异常、基础设施告警，以及金融风险事件。

难点在于核对上下文。一张卡出现在暗网上，分析师需要确认卡是否有效、是否重复上报，再查客户会话和客服工单。原文测得，这类人工调查每起需要 15–30 分钟。

Luna 接手的是收集证据、关联信息和作出分诊结论。复杂案例带着完整上下文升级，高风险案例交给人工分析师。真正的补救处置，则由人工或经过批准的自动化策略授权并执行。

自动关闭一条调查案例，与自主执行补救操作，是两种不同的权限。

这个区别决定了如何理解「超过 90% 自动解决」。它表示大量案例无需人工参与即可完成分诊，不能据此推导 Luna 可以自行冻结账户、修改权限或执行其他高影响操作。原文没有给出这些能力。

两层主管怎样协调 30 多个专用 Agent

Luna 使用 Amazon Bedrock AgentCore runtime 托管 Agent 代码，运行环境位于 Amazon VPC 的私有子网，通过 ZIP 文件和 Amazon S3 直接部署。AgentCore memory 承担记忆能力，团队因此不用自行建设和运维这两部分基础设施。

Tier 1 主管负责高吞吐分诊。它按告警类型调用 30 多个专用 Agent，汇总结果并给出结论，常规案例的分诊中位耗时为个位数秒。

案例有两条主要接入路径：Amazon API Gateway 暴露 Luna Queue API 和 Model Context Protocol（MCP）端点；Tines SOAR 自动送入告警。安全、风险和 ProdOps 工程师也可以直接请求 API，值班工程师则能通过 Claude Desktop extension 用聊天发起调查。

Tier 2 主管负责需要更复杂推理的约 10% 案例。它使用 Amazon Bedrock 上具备扩展推理能力的基础模型，通过 boto3 调用专用 Agent，关联 3–5 个数据源，生成带证据链的调查报告。原文没有披露两层具体使用的模型名称。

Tier 2 既接受紧急按需调查，也通过 Amazon EventBridge rate triggers 和 Amazon SNS 队列完成通知批量处理升级案例。这样的分工把快速判断与深入调查拆开，避免每条常规告警都走最重的流程。

暗网泄露卡流程最能说明专用 Agent 的价值：先接收 Mastercard 等情报源的通知，再向 Galileo 核实卡归属、有效状态和近期交易；用 DynamoDB 查重，然后交叉查询 Mixpanel 会话、Zendesk 工单及内部欺诈评分，最后按风险分级处理。

真正可复用的是这些取证能力。SOC 部署后两个月内，团队把 Luna 扩展到金融风险，只增加专用 Agent 和风险领域主管，继续复用 Datadog、Zendesk、Mixpanel 等已有能力。

记忆怎样进入下一次判断

Luna 的情景记忆（episodic memory）保留最近 30 天的事件和处理结果。新告警到来时，系统会检查是否见过相似模式、之前怎样结案，以及它是否属于已确认的正常行为。

原文举例：某基础设施角色每周二凌晨 3 点执行维护，产生固定访问模式。首次确认正常后，Luna 可以记住并自动加入允许列表，避免每周重新调查。

超过 30 天仍有价值的内容，会作为长期语义偏好和处理模板保留。例如，Greenlight 的历史记录显示，某个暗网来源的卡片通知有 73% 的误报率，于是系统应优先查重。这个比例属于该来源的历史表现，不能套到所有暗网告警上。

记忆也有明确的数据管道：

1. AWS Lambda 从 Tines 事件捕获每次结案结果。
2. DynamoDB 保存处理模式并去重，同类案例连续采用相同方式解决三次后，记录为确认模式。
3. 另一个 Lambda 将新经验整理成主管在推理时可消费的上下文。
4. 这些上下文反馈给 Tier 1，影响后续首次分诊。

这里的「学习」是更新检索上下文和处理经验，原文没有说重新训练模型。运行 6 个月后，团队称系统已经积累了大量机构知识。

他们报告，Tier 1 单独运行时自动解决率为 83%，加入 Tier 2 和经验回流后超过 90%。这是完整系统升级后的结果，不能单独量化记忆层贡献了多少。

我的判断

我更认可它对工作流和权限的拆分。数据源查询、重复检测、证据整理，本来就是安全调查中可以标准化的部分；把复杂判断升级给另一层，再保留处置授权，比直接追求全流程无人参与更容易审查。

但原文没有提供与固定规则、传统 SOAR 剧本或单 Agent 方案的对照。为什么需要 30 多个 Agent，各自怎样划分职责，是否比更少的 Agent 更省钱、更可靠，都没说清。这些架构选择有生产经验支撑，还算不上通用最优解。

超过 90% 是自动解决覆盖率，原文没有同时给出误判率、漏报率和人工复核结果。

允许列表尤其需要谨慎。连续三次采用相同结论，可以确认系统处理的一致性，却不能单凭这一点证明结论正确。原文没有解释错误经验如何撤销、正常维护模式变化后如何失效，这会直接影响长期可靠性。

收益数字也要按口径理解。每月 4,000 起案例，每起 15–30 分钟，对应约 1,000–2,000 小时人工工作；按超过 90% 自动解决估算，可避免约 900–1,800 小时常规处理。这是依据案例量和人工耗时推算的结果，不是披露出来的实际工时核算。

此外，原文同时写了每天数百条泄露卡通知与每月 3,000–4,000 起总案例，却没有说明通知如何去重、合并成案例，不能直接混用两个口径。

后续能力也要与生产结果分开：完整风险覆盖仍在推进，相关风险能力被描述为约一个月前上线；Product operations、自动化 Well-Architected reviews 仍在探索。AWS DevOps Agent、custom agents、skills 和 MCP 集成也是后续方向，文中提到的脚本执行限制为 90 秒，不能当成 Luna 已经具备的完整运维闭环。

能拿来做什么

• 为 Node 服务或内部运维平台设计 AI 调查助手时，可以先选一个边界清楚的告警类型，列出必须查询的数据源、结案条件和升级条件，把是否正确分诊作为首轮验收目标。
• 将日志、工单、资产信息等查询能力封装成可复用工具，让安全调查与风险调查共用同一套接口；是否需要独立 Agent，应按职责和维护成本决定。
• 建立结案反馈时，同时保留证据来源、适用范围和有效期。借鉴 30 天滚动记忆与长期模板的分层方式，并补上错误经验撤销机制。
• 给 AI 调查界面明确展示证据链、推荐结论和待授权操作，并分别统计自动解决率、复核准确率、漏报情况及单案成本，避免用一个覆盖率数字替代系统质量。