AWS 发布了一套基于 Amazon Quick 的参考设计，用于处理大型租约库中的合规问题。它的一个实用理念是严格交接：聊天模型选择固定工具并解释其回复；另一个独立的规则引擎则定义审查范围并作出每项判定。10 月 2 日的文章和示例代码仓库都将其描述为教学用概念验证，而非经过验证的法律合规服务。

对于工程师或合规负责人而言，需要判断这一职责边界是否适合正在审查的决策。该示例使用合成租约、虚构规则和引文。示例总数只展示预期输出格式，并不能说明系统对真实合同或法律的准确性。

重大变化

  • 变化内容：AWS 的示例将 AI 设为固定审查工具的受控接口。规则引擎针对明确列出的租约范围作出判定。
  • 为何重要：有版本记录的规则和证据回执，让审查人员能够在聊天界面之外查看系统如何评估所选记录。
  • 关注事项：回执无法验证租约清单、信息提取或法律规则。采用方必须自行检查这些输入、用户身份归属，以及系统在自身数据上的表现。

先确定数据范围，再编写提示词

用户可以询问 Quick：在某个指定日期，德克萨斯州哪些租约违反了滞纳金规则。Quick 会将请求路由至sweep_compliance，即六种具名 MCP 操作之一。操作会依据指定司法管辖区和日期，筛选数据范围及适用的版本化规则。模型既不编写 SQL，也不判断条款是否合规。规则引擎使用固定比较运算符作出判定，规则值则作为参数传入。AWS 表示，正式的全量扫描不调用模型。AWS 在此解释操作契约；代码仓库介绍了具体实现。

其他工具各有更窄的用途。simulate_rule_change可为拟议值提供探索性计数，但不会记录判定结果。explore_clauses会按语义相似度对筛选样本排序，无法回答“有多少个？”get_finding会检索一条证据链；list_rules显示某个日期生效的规则；check_connection用于检查服务连通性。这个区分很重要，因为相关条款的样本并不等于对全部记录进行审查。

全量扫描会生成一份回执，将每条已扫描记录归入四类之一：合规、违规、含糊不清或无法读取。提交前，规则引擎会断言这四类计数之和与扫描总量相等。Quick 可以显示各类数量和少量样本；Quick Sight 仪表板则从同一 Aurora 数据库读取完整结果。每项判定都包含条款文本、提取值与预期值、规则版本和引文。这些是 AWS 示例的设计属性，并不意味着 BIG CHANGE 运行或独立验证过相关结果。

回执能说明所选数据范围的处理情况，却不能证明源清单包含全部租约、信息提取正确捕获了所有相关条款，或某项规则反映了现行法律。这些问题需要分别进行清单核对、提取审核和法律批准。如果“所有德克萨斯州租约”所对应的分母并不确定，即使计数精确，描述的仍可能是错误范围。

你需要搭建什么

该示例架构在 Amazon Quick 聊天智能体前端设置一个部署在 AWS Lambda 上的 MCP 服务器。Amazon Cognito 签发服务令牌，API Gateway 负责校验。Lambda 通过 RDS Data API 对 Aurora Serverless v2 执行读写。Quick Sight 通过 VPC 连接访问同一数据库。AWS 将 Bedrock 嵌入模型和语言模型用于探索式条款搜索工具；正式全量扫描仍采用确定性处理。

已发布示例包含一个由合成数据构成的 50,000 份租约库、一套版本化规则手册，以及一份验收脚本；AWS 称该脚本会对已部署的系统执行 28 项检查。代码仓库明确警告：代码尚未达到生产就绪状态，法律内容为虚构，真实租户数据还需接受额外安全测试和独立法律验证。我们检查了文档和仓库说明，但没有部署系统、运行这些检查，或测试聊天智能体的工具路由。

若要改造这套系统，应先确定权威记录清单和精确的成员判定规则。接着明确哪些字段能可靠提取、哪些规则比较确实可以机械化执行，以及由谁批准每个规则版本。应保留源文本、提取状态、规则版本、操作人员、对比值、日期和判定 ID，让审查人员能够还原结果；并在聊天回复之外核对回执与原始清单。这些设计检查依据的是示例公布的保证与限制，并非我们测试过的步骤。

AWS 表示，其 Cognito 客户端凭证令牌用于标识 Quick 应用，而非聊天提问者本人。该示例通过关联扫描 ID、时间和 Quick 审计层来识别用户；AWS 建议传递并存储最终用户 ID，以便在合规数据库中记录该身份。如果团队要求每项判定本身都能作为审计记录，就应在部署前敲定这一设计。

访问条件、限制和成本

AWS 的操作指南假定用户拥有 AWS 账号、已配置 AWS CLI v2 凭证、安装了 Python 和用于 CDK 的 Node 24，可访问us-east-1中的模型，并配备含 MCP 连接器和 Quick Sight 的 Amazon Quick 环境。文章写的是 Python 3.12，链接的 README 则写 Python 3.9 或更新版本。选择本地环境时，应检查仓库当前要求。示例说明将 CDK CLI 固定为 2.261.0；该版本号是示例依赖，并非通用 AWS 要求。

当前的Quick MCP 指南为每项操作设定固定的 60 秒超时；每个服务器连接最多允许 100 个工具，并且不会传送自定义 HTTP 标头。对大型扫描任务而言，这一期限需要通过负载测试确认：即使数据库作业本身正确，只要超过连接器限制，就无法作为同步 Quick 操作完成。该指南称，自定义连接器的工具列表可通过Sync更新。而 AWS 博客和示例 README 则要求工具变更后删除并重新创建集成。当前连接器配置应以实时 Quick 文档为准，并在自己的环境中核验已注册的工具列表和路由方式。

这是一个由多项服务组成的系统，因此已发布材料无法支持可信的单一“每次扫描价格”。AWS 的Quick 定价页面将订阅和智能体使用时长分别计费，并列出部分功能涉及的额外 Quick Sight 费用。Aurora 定价取决于容量、存储和 I/O 配置；该示例将 0.5 ACU 设为活动状态下限，而非暂停至零。API Gateway、Lambda 和任何探索式 Bedrock 调用也都需要纳入负载估算。仓库建议评估完成后销毁系统栈，以免持续产生费用。本文没有创建任何 AWS 资源。

决策检查清单

只有在团队能够根据自身数据和控制措施回答以下问题后，才应采用这种模式：

  • 你能否使用经过审核且稳定的筛选条件枚举完整范围，并将结果与权威清单核对？
  • 规则是否为机械比较，并具有获批的版本、生效日期和引文？哪些案例必须保留为含糊情况，交由人工审查？
  • 提取失败和无法读取的文档能否被计数，而不是被悄然排除？
  • 每项判定是否保留源条款、对比值和规则版本？你能否在聊天界面之外取得完整证据集？
  • 全量扫描能否在 Quick 操作超时前结束？你将如何追溯结果到提出请求的人员？
  • 团队是否已按预期用量估算订阅、数据库和服务费用，并使用许可数据测试系统表现和结果质量？

如果任务需要法律解读，或需要判断开放式标准，确定性的通过/失败标签可能掩盖真正需要人工判断的问题。如果团队只需要具有代表性的示例，语义检索更简单。如果已有经审核的规则引擎和仪表板服务于明确负责的用户，那么对话界面并非必需。这些替代方案来自 AWS 文章自身关于“错误选择”的讨论，以及其合成示例的局限。

资料来源与延伸阅读