在大多数金融机构中，项目文件评估是一项后期活动。架构团队设计数字银行服务。安全团队将在几周后对其进行审查。风险团队在部署决策锁定几个月后进行评估。当首席风险官看到风险报告时，架构已经修复，风险无法量化，补救措施也很昂贵。
各司法管辖区的金融监管机构有着共同的期望：在设计阶段评估风险，而不是在部署之后评估风险。无论是通过运营弹性框架、信息安全标准还是技术风险指南，监管信息都是一致的。机构必须在部署新系统之前识别和管理风险。评估必须结构化、可追溯且与变更的实质性成比例。
在这篇文章中，我们介绍了 Assess Workbench，这是一种开源解决方案，用于协调可配置的人工智能代理以进行结构化文档评估。该系统以架构、风险、安全和合规代理作为起点，但无需更改代码即可通过管理界面对其进行编辑。它处理需要结构化评估的文档，从技术架构文件和概念文件到业务政策、委员会章程、风险登记册和董事会文件。它会根据每个文档调整其工作流程，并在 3-8 分钟内完成评估，而不是几周。我们使用 Strands 代理、Amazon Bedrock AgentCore 和 A WS Step Functions 构建了评估工作台。
挑战：孤立的顺序评估
当今金融服务业的评估过程遵循可预测的顺序。架构团队设计云工作负载。几周后，一个安全团队根据控制框架对其进行了审查。几周后，风险小组进行评估。最后，合规性功能根据审慎标准对输出进行验证。这个连续的过程带来了四个问题：
延迟可见性：架构决策锁定后，数据主权遭到侵犯或缺失加密表面等风险。此阶段的补救会导致延迟，并且成本可能比设计时高得多。
丢失的背景：团队之间的每次交接都会失去细微差别。风险团队看不到架构的理由。架构团队看不到其设计选择的监管影响。任何参与者都无法同时查看所有域的全貌。
语言不一致：架构团队使用组件和数据流说话。安全团队谈论控制和漏洞。风险团队以可能性和监管资本敞口说话。没有任何一份文件可以将这些观点联系成高管和监管机构可以遵循的连贯观点。
速度降低：顺序过程成为瓶颈。跨多个部门管理数百个云工作负载的机构无法扩展逐个工作负载的手动评估。团队排队等候审阅者空闲时间。截止日期推迟。接受风险成为阻力最小的途径。
解决方案：映射到您的组织的可配置代理
我们没有构建单一的 AI 系统，而是设计了一个多智能体架构，其中每个代理都反映了组织中的一个角色。该系统附带了四个代理作为工作示例：
这些是起点，不是唯一的配置。团队可以：
-编辑现有代理：更新提示、调整严重性阈值、更改知识库参考信息
-删除代理：删除与您的组织无关的代理
-创建新代理：为任何评估领域添加专家审阅者
我们见过团队构建的配置示例：内部审计代理，根据知识库中加载的内部政策对文档进行审计。董事会治理代理人，负责根据组织的董事会章程和委员会职权范围评估文件。AI/ML 治理文档的模型风险代理。该架构故意是通用的，任何受益于专业知识和一致方法的结构化评估领域都是代理的候选对象。
每个代理都归其所代表的团队所有。安全团队无需向工程团队提交票证即可更新其代理的控制映射。随着指导方针的发展，合规团队在其代理人的知识库中添加了新的监管机构评论。这反映了监管机构对机构本身的期望，即分布式所有权和集中监督。
关键架构见解：这些代理无法取代人工审阅者。它们提供了结构化的 “第一关”，用于识别问题并将其映射到标准和框架。然后，人类专家审查、质疑和批准调查结果，将时间花在判断而不是发现上。这种人性化设计符合监管部门的期望，即决策责任仍由合格的专业人员承担，而不是自动化系统。
图 1：具有可配置专业代理的多智能体架构。每个代理都在 Amazon Bedrock AgentCore 上运行，都有自己的提示、工具和知识库访问权限。AWS Step Functions 根据 AI 生成的计划协调执行。
架构概述
评估 Workbench 完全在您的 AWS 账户内的部署。文档、调查结果和代理输出旨在保留在您的环境中，这对于数据主权不可谈判的受监管行业至关重要。
该系统在 AWS 云上使用无服务器架构：
-代理运行时：Strands Agent 在 Amazon Bedrock AgentCore Runtime 上运行，使用 Claude Sonnet 4 作为基础模型。每个代理都有自己的系统提示、工具配置和结构化输出架构。
-编排：AWS Step Functions 执行人工智能生成的审查计划，其中包含重试语义、进度跟踪和人工在环审批门
-知识基础：Amazon Bedrock 知识库为您的标准、政策和监管框架编制索引，因此代理基于权威来源材料而不是模型训练数据进行评估
-共享语义内存：Amazon Bedrock AgentCore Memory 为所有审查结果提供基于向量的存储。发现结果按项目和域写入内存命名空间。聊天代理通过语义搜索检索相关发现，无需显式数据传递即可实现跨代理上下文。
-文档分析：PymuPDF 提取文本，通过两轮图像分析管道进行分类，然后深度分析架构图和数据流
-数据层：Amazon DynamoDB 存储项目、审查和调查结果；Amazon S3 存储上传的文档和生成的报告
-身份验证：亚马逊 Cognito 为 HTTP API 和 WebSocket 连接提供基于 JWT 的身份验证
-实时更新：WebSocket 连接会在代理执行时直播实时进度，包括质量分数和指导迭代
-基准测试：使用自动质量评分并排比较模型和配置，以优化成本和质量权衡
-基础设施：Terraform 模块管理所有资源；AWS SSM 参数存储区保存运行时配置
-可观测性：亚马逊 CloudWatch、AWS X-Ray 和 AgentCore OpenTelemetry 集成提供从文档上传到寻找交付的端到端跟踪
自适应工作流程
大多数多智能体系统使用 Orchestrator 代理，即决定调用哪些代理以及按什么顺序调用的 LLM。这适用于简单案例，但会造成大规模问题。管弦乐器不透明。它无法重试单个代理。用户无法看到正在发生的事情，也无法在代理运行之前进行干预。
我们将协调分为两个阶段：智能规划和确定性执行。
第 1 阶段：AI 规划师
当团队上传文档时，人工智能规划师会使用 Amazon Bedrock Converse API 对其进行分析。规划者确定文件类型、复杂程度和相关的评估领域。它生成一个结构化的 JSON 执行计划，指定要调用的代理、顺序、深度和重点领域。
计划员为每份文件做出四个明智的决策：
-代理选择：对于简单的 API 规范，它仅选择架构代理。对于处理银行卡数据的支付系统，它会调用所有已配置的代理，包括合规性。
-执行顺序：架构和安全性并行运行（它们是独立的）。风险紧随其后（需要他们的发现作为化合物风险识别的背景）。
-深度校准：快速扫描低复杂度文档。对包含敏感数据或跨境问题的复杂分布式系统进行全面分析。
-特定文档指南：该计划包括量身定制的分析说明，其中引用了本文档特有的技术、模式和问题。
在开始执行之前，该计划将提交给用户进行审查和批准。用户添加代理、移除代理、调整深度或修改焦点区域。这提供了人工监督，无需人工努力来制定计划。
{“document_type”：“微服务架构”，“复杂性”：“高”，“理由”：“具有 PII 处理和多区域部署的分布式事件驱动系统。架构和安全并行运行；风险紧随其后。“，“群组”：[{“group_id”：“初始评论”，“标签”：“初始审查”，“执行”：“并行”，“代理”：[{“代理类型”：“架构”，“深度”：“彻底”，“焦点区域”：[“事件驱动模式”，“数据流”，“扩展策略”]，“提示_附录”：“支付注意 Kafka 管道中的事件排序保证和消息丢失场景。”}，{“代理类型”：“安全”，“深度”：“彻底”，“焦点区域”：[“身份验证”，“个人身份信息处理”，“加密”]，“提示_附录”：“此系统处理与医疗保健相关的数据。评估 HIPAA 的影响。”}}，{“group_id”：“informed_risk”，“标签”：“风险评估”，“执行”：“顺序”，“代理”：[{“代理类型”：“风险”，“深度”：“彻底”，“依赖关系”：[“架构”，“安全”]，“重点领域”：[“运营风险”，“供应商锁定”、“灾难恢复”]、“prompt_addendum”：“考虑架构和安全发现中复杂的风险。”}]}图 2：人工智能规划器生成的执行计划示例。计划者选择代理、确定执行顺序和并行度、校准深度并提供特定文档的分析指导，所有这些都采用 Step Functions 直接使用的结构化 JSON。
第 2 阶段：确定性执行器
AWS Step Functions 执行批准的计划。状态机是固定的，它在评论之间不会改变。但是该计划控制着运行的内容，使每一次执行都适应特定的文档。
图 3：Step Functions 状态机执行流程。外部 Map 按顺序遍历计划组。在每个组中，代理按计划规定并行或按顺序执行。质量评委对每位经纪人的输出进行评分，并在需要时触发反复指导。
执行器的核心是嵌套的 Map 状态。外部 Map 按顺序遍历计划的各个组。对于每个小组，内部地图会根据计划平行或按顺序向其中的代理商扇出。
“ExecuteGroups”：{“类型”：“地图”，“项目路径”：“$.plan.groups”，“ItemSelector”：{“group.$”：“$.Map.Item.Value”，“project_id.$”：“$review_id”}，“迭代器”：{“startAt”：“ExecuteAgentsInGroup”，“States”：{“组内执行代理”：{“类型”：“地图”，“项目路径”：“$.group.agents”，“ItemSelector”：{“agent.$”：“$$.Map.Item.Value”，“project_id”：“$project_id”，“review_id.$”：“$review_id”，“s3_bucket.$”：“$s3_bucket”}，“maxConconcurrencyPath”：“$.group.max_concurrency”，“迭代器”：{“startAt”：“invokeAgent”，“状态”：{”类型”：“任务”，“资源”：“arn: aws: states::: lambda: invoke”，“下一步”：“CoachJudge”}，“CoachJudge”：{“...”：“质量评分和重试逻辑”}}，“结束”：true}}，“下一步”：“聚合”}图 4：maxConcurrencyPath 字段是关键：当计划指定 “执行”：“并行” 时，该字段解析为 0（无限并发）。对于 “顺序”，它解析为 1。相同的固定状态机处理两种模式，计划数据控制执行行为。
这种分离有四个好处：
-可观察性：用户通过 WebSocket 实时查看哪些代理正在运行、哪些已完成以及哪些处于待处理状态
-部分恢复：如果风险代理在架构和安全性完成后出现故障，则只有风险代理会重新运行。已完成的作品将被保留。
-Human-in-the-Loop：用户在执行任何代理之前批准计划。没有不透明的自主决策。
-确定性保证：Step Functions 提供 LLM 无法保证的重试语义、超时和错误处理
质量判断和指导循环
每位代理完成后，质量评委会在三个维度上对输出进行评分：完整性、特异性和可操作性。每个维度获得从 0 到 1 的分数。
如果综合分数低于可配置的阈值（默认值：0.7），则可选的指导循环会向代理提供结构化反馈。教练会确定哪些调查结果缺乏特异性，哪些领域漏掉了，哪些建议需要更多细节。然后，该代理将根据该反馈生成修订后的评估。前端实时可视化这个循环，用户可以并排看到分数、教练反馈和改进后的输出。
无码代理定制
添加新的专业代理人、合规审计师、模型风险代理人、内部审计审查员或董事会治理评估员无需使用 Python 代码。每个代理都完全在 YAML 配置文件中定义：
# agents/au_fsi_compliance_review/agent.yaml 注册表：代理类型：au_fsi_compliance 显示_名称：澳大利亚 FSI 合规性描述：“评估澳大利亚审慎标准的遵守情况...” 模型_id：us.anthropic.claude-sonnet-4-6 finding_schema：严重程度_级别：[严重、高、中、低] 严重性_来源：直接字段：监管 _reference：类型：str 必填项：真实描述：“特定监管参考” 义务_类型：类型：str 必填项：true 枚举：[强制性、指导性、最佳实践] compliance_gap：类型：str 必填项：true 枚举：[非合规，部分合规，证据不足]单个通用运行时读取此配置并使用 pydantic.create_model () 动态构建 Pydantic 模型。它通过 Strands 代理的 structured_output_model 参数将模型的 JSON 架构传递给基础模型。基础模型返回经过验证的键入结果，而不是需要解析的自由格式文本。
风险代理展示了高级架构功能。其严重性不是由 LLM 直接指定的。相反，代理提供可能性和后果评级。YAML 中定义的 5×5 矩阵会自动推导严重程度：
严重性_来源：派生的严重性_推导：输入：[可能性，后果] 矩阵：“几乎可以肯定，灾难性”：严重 “可能，严重”：高 “可能，中等”：中等 “罕见，微不足道”：低这意味着该机构控制的是风险偏好校准，而不是基础模型。不同的部门定义不同的矩阵，以反映其特定的风险偏好，同时使用相同的代理运行时间和评估方法。
管理 UI 将这些 YAML 配置显示为可编辑表单。合规官员通过浏览器更新监管参考资料、调整严重程度阈值或添加新的发现字段。无需部署代码。不依赖工程团队。
组织中的接地代理
Assess Workbench 为代理提供两种机制来为组织特定知识奠定基础：上下文文档和标准知识库。这些共同确保评估反映了您机构的实际情况，而不是通用培训数据。
上下文文档
上下文文档是 Markdown 文件，可在运行时为代理提供组织基础。他们对人工评估员将带给审查、风险偏好、技术标准、监管环境和团队会议的信息进行编码。
可以将上下文设置为三个级别：
-组织层面：企业范围的风险偏好声明、公司价值观、战略技术方向、总体政策
-业务部门层面：特定部门的风险承受能力、团队惯例、当地监管环境、特定业务限制
-项目层面：特定的项目限制、相关的先前决定、先前的评估、已知的例外情况或可接受的风险
原则：只要人类评估人员有特定的风险偏好或特定背景，就将其添加为背景信息。零售银行部门提供了其具体的风险偏好声明。全球市场部门提供其市场风险容忍度。相同的代理，相同的评估方法，不同的组织背景推动不同的校准。
上下文文档通过应用程序上传并作为动态文档进行管理。随着监管指导的演变或内部政策的变化，团队可以直接更新其背景文件，无需重新部署。
标准知识库
标准知识库（存储库中的标准/文件夹）使代理可以访问基础模型在培训期间可能没有遇到的权威参考资料。它接受：
-内部标准和政策：贵组织自己的控制框架、风险管理政策、技术标准和操作程序
-特定法规：与您的司法管辖区相关的审慎标准、立法和行业规范
-新信息：基金会模型培训截止后发布的监管机构指导意见、演讲、咨询文件和行业评论
这对于评估质量至关重要。监管指导的发展速度比基础模型训练周期更快。监管机构在行业会议上的讲话、新的咨询文件或有关现有标准的最新常见问题解答都可以添加到知识库中，并立即影响代理商评估。
代理没有直接访问互联网的权限。这是经过深思熟虑的设计选择，而不是限制。评估完全基于精选、经批准的原始资料、您的标准知识库和背景文档。这样可以确保调查结果可以追溯到您的机构已审查和接受的权威来源，而不是未经审查的网站内容。如果您的用例需要互联网接入，则可以将其添加为代理工具，但对于受监管的评估工作流程，通常首选精选知识。
组织控制的代理所有权
每个代理的提示、架构和知识库访问权限可以归其所服务的团队所有：
-安全团队维护安全代理的控制映射和漏洞分类
-随着新指南的发布，合规团队会更新其代理人的监管参考资料
-风险团队调整其代理人的严重程度矩阵以反映当前的风险偏好
-董事会秘书处根据其委员会的职权范围设立和维护一个治理机构
这种分布式所有权模式可确保领域专业知识留给领域专家。没有一个单一的中央团队会阻碍代理人的进化。各团队按照其域名需求的节奏对代理人的行为进行迭代，每周进行一次积极的监管咨询，每季度进行稳定的国际标准。
可追溯性：可供检查的输出
该系统得出的每一项发现都可以追溯到三个来源：
-文档部分：上载文档中触发调查结果的特定段落、图表或数据流
-标准或政策：从知识库中检索的具体条款或要求
-代理推理：代理用来将文档内容与需求联系起来的逻辑链
这种三点可追溯性意味着监管机构或内部审计师可以通过遵循从结论到来源的证据链来验证任何发现。代理配置为包含特定引文，而不是诸如 “不符合合规要求” 之类的通用陈述，而是对相关标准或政策条款的精确引用。
任何审查完成后，用户可以直接与每个专业代理聊天。架构代理解释了为什么它标记了设计模式。风险代理人讨论可能性评级并提出治疗策略。每个聊天代理通过语义搜索从 AgentCore Memory 中检索其域名调查结果，从而保持对审查上下文的完全访问权限。对话持续不断，随着设计的发展，对话可以持续进行。
分析仪表板跟踪评估、覆盖矩阵、按严重程度划分的分布情况、用户反馈分数和模型比较数据中的质量趋势，为监管机构预期的方法有效性提供持续证据。
结果
在对具有代表性的金融服务文件进行测试时，我们观察到四个可衡量的结果：
速度：完整的多视角评估、架构、安全性、风险和合规性将在 10-15 分钟内完成。等效的手动流程需要 2-6 周，具体取决于团队的可用性和文档的复杂性。这意味着从 10-30 个工作日缩短到 20 分钟以下。
一致性：每项评估都使用相同的方法、相同的参考语料库和相同的质量阈值。今年的第 200 次评估与第一次评估一样严格。不同的部门通过代理配置，而不是通过可变的分析师判断或可用性获得针对其特定职责的评估。
连续性：由于评估需要几分钟而不是几周，因此机构会在每次设计迭代时进行评估，而不是在部署之前进行一次。风险识别从定期的门控审查转变为持续的设计时反馈。团队收到风险信号，但他们仍然可以以低成本对这些信号采取行动。
考试准备情况：当监管机构问 “你是如何评估这次部署的风险的？”，该机构提供了一整套证据。该套餐包括人工智能生成的计划、人工批准记录、带引文的个体代理调查结果、质量分数以及任何指导迭代。该审计记录满足了监管部门对材料技术变更进行结构化、可追溯评估的期望。
成本效率：每次评估的 AWS 服务费用约为 1.00 美元至 1.25 美元（发布时为美元），具体取决于文档的复杂程度和调用的代理数量。有关更多信息，请参阅我们的定价页面。
分四个步骤开始
评估 Workbench 部署到您自己的 AWS 账户中的情况。克隆存储库并在不到 30 分钟的时间内运行一个工作实例：
第 1 步：克隆和配置
git clone https://github.com/aws-samples/sample-assess-workbench.git cd sample-assess-workbench cp .env.example .env编辑 .env：设置 AWS_REGION 和 PROJECT_NAME
第 2 步：部署
该项目使用 Task 作为其运行器。一条命令即可提供完整的堆栈、AgentCore 代理、知识库、Terraform 基础设施和托管前端：
任务部署这将注册四个示例审查代理（架构、安全性、风险和合规性），加载示例标准语料库，并预置一个 S3 + CloudFront 前端，所有这些都在您的账户中。
第 3 步：创建用户并登录
任务部署:用户 # 提示输入电子邮件、密码和群组使用任务部署结束时打印的 CloudFront 网址打开应用程序。
第 4 步：进行第一次评估
创建项目，上传设计文档，然后单击 “开始审阅”。AI 计划员会分析您的文档，制定执行计划供您批准，然后 Step Functions 执行器运行评估。调查结果将在 3-8 分钟内出现。
有关先决条件（Python 3.13+、Node.js 18+、Terraform、AWS CLI、AgentCore CLI）和详细配置，请参阅安装指南。
结论
监管机构希望在设计阶段进行结构化评估。手动顺序流程无法跟上现代部署速度。Assess Workbench 提供了一种不同的方法：可配置的人工智能代理，每个代理均由其服务的团队拥有，以组织的标准和政策为基础，而不是通用培训数据。
自适应计划员确保每项审查都针对特定文档量身定制。无代码代理定制意味着新的专业代理、内部审计、董事会治理、模型风险或任何其他领域都需要配置，而不是工程工作。组织控制的背景文件和精心策划的知识库是对您机构现实情况的评估。通过将每项发现与文件部分和权威来源联系起来，可随时进行审查的可追溯性可以满足监管机构的需求。
虽然这篇文章演示了金融服务背景下的模式，但 Assess Workbench 可以针对任何行业和地理位置进行配置。标准知识库接受任何监管框架、国际标准或公司政策。代理架构、具有特定领域架构和精心策划的知识库的专家审阅者适用于需要结构化文档评估的任何地方。我们已经看到各团队对其进行了调整，以适应 ESG 报告评估、健康和安全文件审查以及董事会治理评估。
源代码可在 GitHub 上找到。我们欢迎有关您如何在组织中应用这种模式的贡献、反馈和故事。