开放金融接入最耗时的部分，往往不是把一个 API 请求发送出去，而是确认接口是否符合 Financial Data Exchange（FDX）标准、补齐证据、解释差异，并在安全与合规约束下反复沟通。Ninth Wave 构建的 Compass 将这套流程交给运行在 Amazon Bedrock AgentCore 上的多智能体助手处理，把原本以周计算的入驻周期压缩到分钟级，同时将 SOC 2 和 PCI DSS 要求纳入设计边界。
多智能体的价值不只是“并行调用模型”
Compass 的关键思路，是把开放金融入驻拆成职责清晰的任务，而不是让一个大模型同时阅读规范、检查接口、判断合规并生成最终报告。
一个可落地的职责划分可以是：
- 资料接收智能体：读取 OpenAPI 文档、认证说明、错误码约定和测试环境信息，发现缺失材料。
- FDX 检查智能体：将接口路径、字段、分页、认证和响应语义与 FDX 要求进行对照。
- 证据智能体：保存每项判断对应的规范条款、接口片段和测试结果，避免只有结论没有依据。
- 评分智能体：按预先定义的权重汇总通过项、缺失项和阻塞项。
- 报告智能体：把技术差异转换成银行、集成团队和审计人员都能理解的整改清单。
这种分工有两个直接收益。一方面，每个智能体的输入更窄，提示词更稳定；另一方面，错误更容易定位。例如，路径不存在属于确定性验证失败，不应被模型“解释”为基本符合。
Amazon Bedrock AgentCore 在这里承担的是智能体运行与编排基础设施的角色。真正决定系统是否可靠的，仍然是任务边界、工具权限、证据链和失败处理，而不是智能体数量。
把确定性验证放在模型之外
FDX 合规检查包含两类任务：
- 可以机械判断的规则，例如是否存在指定路径、是否声明认证机制、错误响应是否完整。
- 需要语义判断的规则，例如字段含义是否与标准一致、扩展字段是否改变了原有语义、文档是否足以支持第三方集成。
第一类规则应由普通代码、JSON Schema、OpenAPI 校验器或契约测试完成。大模型更适合解释结果、关联证据并生成整改建议。这样既降低幻觉风险，也让评分可以重复执行。
下面是一个可以直接运行的简化示例。它不是官方 FDX 校验器，只演示如何把确定性检查和评分从智能体中分离出来。运行前可将 SPEC 替换成实际解析后的 OpenAPI 文档。
cat > validator.py <<'PY'
import json
SPEC = {
'openapi': '3.0.3',
'paths': {
'/accounts': {
'get': {
'responses': {
'200': {'description': 'Account list'},
'429': {'description': 'Rate limited'}
}
}
},
'/transactions': {
'get': {
'responses': {
'200': {'description': 'Transaction list'},
'429': {'description': 'Rate limited'}
}
}
}
},
'components': {
'securitySchemes': {
'bearerAuth': {
'type': 'http',
'scheme': 'bearer'
}
}
}
}
def has_rate_limit_response(spec):
operations = []
for path_item in spec.get('paths', {}).values():
for method, operation in path_item.items():
if method.lower() in {'get', 'post', 'put', 'patch', 'delete'}:
operations.append(operation)
return bool(operations) and all(
'429' in operation.get('responses', {})
for operation in operations
)
checks = [
{
'id': 'openapi-version',
'passed': str(SPEC.get('openapi', '')).startswith('3.'),
'evidence': SPEC.get('openapi')
},
{
'id': 'accounts-endpoint',
'passed': '/accounts' in SPEC.get('paths', {}),
'evidence': '/accounts'
},
{
'id': 'transactions-endpoint',
'passed': '/transactions' in SPEC.get('paths', {}),
'evidence': '/transactions'
},
{
'id': 'authentication-and-throttling',
'passed': (
'bearerAuth' in SPEC.get('components', {}).get('securitySchemes', {})
and has_rate_limit_response(SPEC)
),
'evidence': 'bearerAuth and HTTP 429 responses'
}
]
score = round(100 * sum(item['passed'] for item in checks) / len(checks))
report = {
'score': score,
'status': 'ready-for-semantic-review' if score == 100 else 'changes-required',
'checks': checks
}
print(json.dumps(report, indent=2, ensure_ascii=False))
PY
python3 validator.py
在真实项目中，应把检查项放进带版本号的规则包，并为每个规则记录：
- 规则标识与适用的 FDX 版本；
- 输入来源，例如 OpenAPI 路径、测试响应或银行提交的说明；
- 原始证据及其哈希值；
- 评分权重和阻塞级别；
- 执行器版本与执行时间。
这样，当标准、接口或评分策略变化时，团队可以重新运行评估，而不必依赖模型复述上一次结论。
让模型输出“带证据的判断”
语义审查仍然适合交给智能体，但提示词必须限制其权限。下面的模板可以用于 FDX 检查智能体；字段名称和输出结构需要按照实际系统调整。
你是开放金融 API 审查智能体。
输入：
- 适用的 FDX 规则片段
- OpenAPI 接口片段
- 确定性校验结果
- 已脱敏的测试响应
任务：
1. 只根据输入证据判断规则是否满足。
2. 每个结论必须引用规则标识和接口证据。
3. 证据不足时输出 needs_review，不得猜测。
4. 不得把建议描述为正式的 SOC 2、PCI DSS 或法律认证结论。
输出 JSON，包含：
- rule_id
- status: pass、fail 或 needs_review
- evidence
- explanation
- remediation
- confidence
评分也不应简单等于模型置信度。更稳妥的方式是由代码应用固定权重：关键认证失败可以直接阻塞入驻，文档措辞不完整则只扣少量分。模型负责分类和解释，评分服务负责执行组织批准过的政策。
SOC 2 与 PCI DSS 是系统边界，不是提示词
Compass 需要满足 SOC 2 和 PCI DSS 要求，这意味着安全控制必须覆盖整个数据流，而不只是模型调用。
实施时应重点检查：
- 数据最小化：只向智能体提供完成审查所需的字段，不发送真实卡号、访问令牌或客户身份数据。
- 脱敏与日志控制：在进入提示词和遥测系统之前清除敏感值，避免调试日志形成新的数据副本。
- 最小权限：每个智能体只获得必要工具和资源权限；报告智能体通常不需要调用银行测试 API。
- 证据可审计：保存规则版本、工具执行结果和审批动作，但为日志设置明确的保留期限。
- 人工关卡：高风险例外、低置信度判断和生产凭证变更必须由授权人员确认。
- 网络与密钥隔离：测试环境、生产环境和模型运行环境使用独立凭证，并通过集中式密钥管理完成轮换。
尤其要避免让大模型直接处理完整支付卡数据。声称“模型不会记住”不能替代 PCI DSS 范围分析、访问控制和数据保留策略。
从试点到生产的采用清单
团队可以先选择一组稳定、低风险的 FDX 规则做试点，而不是一开始就自动化所有入驻判断：
- 固化一套带版本的确定性规则和评分权重。
- 选择过去的入驻案例，比较人工结论与智能体结论。
- 统计误报、漏报、
needs_review比例和单次评估成本。 - 要求每个结论都能追溯到规则、输入和工具输出。
- 将生产凭证操作、合规豁免和最终批准保留给人工。
- 在 FDX 版本、模型版本或提示词变化后执行回归测试。
Ninth Wave 的 Compass 展示了多智能体系统在开放金融中的一个务实方向：它不是用模型替代标准、审计或安全控制，而是把资料收集、规则验证、证据整理和整改沟通串成一条更快的流水线。真正能够把数周缩短到分钟的，不只是生成式 AI，而是确定性工具、受约束的智能体、可追溯证据与人工审批共同组成的工程系统。