Anthropic 开源的 financial-services 仓库并非一个普通的 AI 助手插件集合，而是一套经过深思熟虑构建的金融工作流自动化框架。其核心价值不仅在于预置的投行分析、估值建模、KYC 筛查等垂直技能，更在于支撑这些技能安全运转的一整套合规校验基础设施。本文聚焦于该仓库的工具合规校验层设计，从工具调用的权限边界、审计日志结构与风险拦截管道三个维度，剖析其如何在保持 AI 能力上限的同时，将金融场景下的操作风险约束在可接受的范围内。
工具调用的权限边界：最小权限原则的工程实践
金融 AI 系统的第一条安全防线是工具调用的权限边界。不同于通用代码助手几乎可以调用任意工具，金融场景要求每个 AI Agent 必须被精确限定在业务所需的最小工具集内。Anthropic 的 financial-services 仓库通过三层机制实现了这一约束。
第一层是 Agent 层面的工具清单声明。在 managed-agent-cookbooks/ 目录下的每个 agent.yaml 中，开发者需要显式声明该编排 Agent 所持有的工具类型。以 GL Reconciler（总账对账机器人）为例，其编排层（orchestrator）的工具配置如下：Agent Toolset 仅启用 Read、Grep、Glob 三个读操作，而 bash 和 write 被明确设置为 enabled: false。这意味着编排 Agent 的能力被锁定在只读数据检索范围内，无法直接修改文件系统或执行操作系统命令。这种声明式配置使得安全审计人员无需阅读代码，仅通过检查 YAML 文件即可判断该 Agent 的最大权限边界。
第二层是 MCP 服务器的只读标记。GL Reconciler 配置了两个内部 MCP 服务器：internal-gl 和 subledger，分别用于访问总账和分账数据。这两个 MCP 连接虽然默认启用，但工具集在 mcp_toolset 层级被限定为只读模式。MCP（Model Context Protocol）作为连接 AI 与外部数据源的标准化协议，在 financial-services 中承担了全部数据获取职责。通过在连接配置中明确标注 enabled: true 并配合读写权限控制，仓库实现了数据源访问的可审计性 —— 管理员可以清晰地看到每个 Agent 访问了哪些 MCP 服务器，以及这些访问是读取还是写入操作。
第三层是 Subagent 级别的独立工具域。GL Reconciler 的编排层通过 callable_agents 声明了三个子 Agent：reader.yaml（文档读取）、critic.yaml（差异分析）、resolver.yaml（问题解决）。每个子 Agent 拥有自己的 manifest 文件，其中包含独立的工具配置。编排层仅持有 Read/Grep/Glob，写操作权限完全下放到专用子 Agent 中。这种设计在架构上形成了责任分离：编排层负责调度和数据聚合，但不持有破坏性工具；写入操作集中在特定子 Agent 中，便于精确定位和审计。当某个子 Agent 需要升级处理时（如发现高风险差异需要人工介入），其输出同样被路由到 escalator 子 Agent 进行格式化，而非直接写入目标系统。
KYC Screener Agent 进一步展示了这套权限模型在合规筛查场景中的应用。该 Agent 的工具声明为 Read, Grep, Glob, mcp__screening__*，明确限定了文档读取、黑名单搜索和 glob 模式匹配三个功能类别。其中 mcp__screening__* 命名空间专门对应制裁名单筛查、PEP（政治敏感人物）匹配和负面媒体扫描三个 MCP 工具，这些工具均被封装在受控的 MCP 服务器中，Agent 本身无法直接访问底层数据库或文件系统的其他部分。
审计日志结构：可追溯性的结构化设计
合规场景下的审计日志不仅是事后追溯的依据，更是实时监控和异常检测的数据源。Anthropic financial-services 仓库在日志结构设计上采用了一种 “隐式结构化” 的方法 —— 不强制要求 AI 输出特定格式的日志，而是通过工具调用的元数据和 Agent 输出模板来保证日志的可解析性。
从工具调用维度看，每次 MCP 调用都会产生结构化的元数据记录。在 agent.yaml 配置中，每个 MCP 服务器连接都携带了 name 和 type 字段，这使得系统可以按照 MCP 服务器名称对工具调用进行分类。例如，当 GL Reconciler 调用 internal-gl MCP 服务器执行账目查询时，日志中可以记录调用的源（source: internal-gl）、调用的工具名称以及返回的结果数量。虽然这些元数据最终依赖于部署层的日志采集基础设施，但 agent.yaml 中对 MCP 服务器的显式声明为日志关联提供了稳定的索引键。
从 Agent 输出维度看，KYC Screener 的设计文档明确规定了输出格式的结构化要求。该 Agent 产生四个明确的交付物：实体提取文件、规则引擎结果（包含每个 KYC/AML 规则的通过 / 失败状态及证据引用）、筛查结果（包含制裁名单匹配、PEP 匹配和负面媒体命中的匹配置信度）以及升级数据包（包含差距、命中和建议风险评级）。这种结构化输出使得下游合规系统可以通过解析 JSON 或结构化文本来自动提取关键审计字段，而无需依赖 LLM 输出的非结构化文本。
审计日志的另一个关键维度是 变更溯源。GL Reconciler 的编排层采用了一个重要的设计约束：编排器（orchestrator）永不直接读取交易对手文档，也永不持有写入工具。这一约束配合子 Agent 的独立 manifest 配置，使得系统可以精确追踪每一条数据的来源和每一次处理的路由路径。当对账结果出现问题时，审计人员可以通过日志回溯：数据由哪个子 Agent 读取、经过哪个子 Agent 处理、最终由哪个子 Agent 写入或升级。这种追踪能力对于金融监管中常见的 “模型决策可解释性” 要求至关重要。
风险拦截管道：人机协同的审批节点
金融场景的核心合规原则是 AI 不做最终决策。Anthropic financial-services 仓库通过设计明确的 “人类在回路中”（Human-in-the-Loop）节点，将高风险操作拦截在自动化流程之外。
KYC Screener 清晰地定义了 Agent 与人类合规官的职责边界。Agent 的职责范围终止于 “推荐风险评级”—— 它负责收集材料、运行规则引擎、执行筛查、识别差距，但最终的客户风险评级由合规官决定。同样地，GL Reconciler 的编排层负责发现差异、追溯根本原因并路由待处理项，但差异的批准和调整由人工操作员执行。这种职责分离在架构上防止了 AI 系统超越其辅助定位的可能。
在风险拦截的实现机制上，financial-services 仓库采用了两种互补的模式。第一种是 输出暂挂模式：所有关键输出（包括 KYC 筛查结果、对账差异报告、估值模型草稿）在到达最终用户之前都被 “暂挂” 在待审批状态。以 KYC Screener 为例，其输出被路由到 escalator 子 Agent 进行格式化，生成符合合规部门要求的升级数据包。这个数据包包含 Agent 发现的所有差距和命中、推荐的风险评级以及支持这些结论的证据，但它的定位是 “供人工审阅的输入材料”，而非可直接执行的指令。
第二种是 工具调用阻断模式。GL Reconciler 的编排层通过将 write 工具设置为 enabled: false，从根本上阻断了 AI 直接修改文件系统或账簿的可能性。任何需要写入的操作都必须通过专用的子 Agent（如 resolver）发起，而这些子 Agent 的 manifest 配置同样受到 check.py 验证脚本的约束。这种阻断不是运行时检查，而是架构层面的权限分离，使得即使 AI 模型被诱导或出现 prompt 注入攻击，写操作也无法从编排层执行。
仓库中的 check.py 验证脚本提供了额外的静态检查层。该脚本在提交前自动运行，对所有 agent.yaml 和子 Agent manifest 执行以下校验：YAML 语法正确性、JSON 配置可解析性、frontmatter 必填字段存在性、所有文件引用可解析、捆绑技能与垂直源代码一致性、marketplace 源路径可访问性。其中与安全最直接相关的是引用解析检查 —— 它确保 system.file、skills[].path 和 callable_agents[].manifest 中声明的路径都指向实际存在的文件。如果某个子 Agent 的 manifest 配置错误地引用了一个不存在的工具集，check.py 将在部署前失败，而不是将一个权限配置错误的 Agent 部署到生产环境。
工程化落地的关键参数与监控点
将上述设计原则转化为可操作的工程实践，需要关注以下几个关键参数和监控指标。
在工具权限配置层面，建议将每个 Agent 的工具清单控制在 5 个以内，超过此阈值应触发配置审查。GL Reconciler 编排层的读操作工具集（Read、Grep、Glob）恰好符合这一建议，MCP 服务器的读写状态应与业务需求明确对应 —— 金融数据访问应默认为只读，写操作需要单独配置并在日志中标记为高风险操作。
在日志采集层面，建议至少采集以下字段：调用时间戳（精确到毫秒）、Agent 标识、MCP 服务器名称、工具调用类型（读 / 写 / 执行）、输入参数哈希（用于去重但不存储敏感内容）、输出状态（成功 / 失败 / 超时）、处理耗时。这些字段构成了异常检测和合规审计的基础数据集。
在风险拦截层面，建议设置以下监控阈值：单日单 Agent 的写操作调用超过 0 次应触发告警（因为在 GL Reconciler 的设计哲学中编排层根本不应有写操作）；KYC 筛查结果的 “高风险” 命中超过 3 个应自动路由到合规官优先队列；模型输出的置信度低于 0.7 的判断应进入人工复核流程。
在验证自动化层面，check.py 应集成到 CI/CD 管线的 pre-commit 阶段，确保任何对 agent 配置的修改都经过静态验证。特别是 callable_agents 声明的子 Agent manifest 引用，应确保每个子 Agent 的工具配置与其声明的职责相符 —— 文档读取子 Agent 不应持有文件写入能力，合规筛查子 Agent 不应持有网络访问能力。
总结
Anthropic financial-services 仓库的合规校验层设计揭示了一个核心洞察：金融 AI 系统的安全不是靠单一的控制点实现的，而是通过工具权限边界、审计日志结构和风险拦截管道三个层面的协同实现的。工具权限边界通过声明式配置限制了每个 Agent 的最大能力范围；审计日志结构通过结构化输出和元数据关联保证了可追溯性；风险拦截管道通过人机协同的审批节点将最终决策权保留在人类手中。而 check.py 等验证脚本则提供了静态检查的保障，确保这些安全设计在部署前不会被配置错误绕过。
对于在金融场景中部署 AI 系统的团队而言，这套设计的核心参考价值在于：不要依赖运行时监控来解决所有安全问题，而要在架构层面通过工具配置、子 Agent 分离和验证脚本形成多层防御。只有当每个安全控制点都足够简单且可验证时，整个系统的安全性才能得到真正的保障。
资料来源：Anthropic financial-services GitHub 仓库
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。