人工智能大模型AI AgentAgent 框架多智能体工具调用MCP 服务【免费下载链接】harness-sdkBuild an agent harness and control it end-to-end. Open-source SDK for production AI agents in Python TypeScript - any model, any cloud.项目地址https://gitcode.com/GitHub_Trending/sdkpython13/harness-sdk点击查看免费下载本文围绕 harness-sdk 仓库中test-infra/目录的 CDK 栈展开它是一套面向“基础设施依赖型集成测试”的 AWS 资源供给栈Bedrock 知识库、SSM-only EC2 沙箱等绝大多数开发者无需触碰但当你需要本地迭代 KB 摄取、SSH 沙箱相关测试或要在全新 AWS 账号中独立跑完整测试套件时它就是必经之路。读完本文你将掌握该栈的部署时机判断、feature 化裁剪部署、SSM 参数解析机制、内部模式的危险边界以及如何按约定新增一个测试 feature。先认清定位这套栈服务的是“少数测试”test-infra是一个用 AWS CDK 编写的独立栈为harness-sdk仓库中一小部分集成测试提供共享 AWS 资源Bedrock 知识库、EC2 实例等。它服务的是那些依赖具体基础设施的功能测试——典型如 RAG 知识库KB 摄取和 SSH 沙箱相关测试。绝大多数测试包括大多数集成测试不依赖这套资源。test-infra/AGENTS.md开篇就给出了一句核心指引“You almost certainly do not need to deploy or modify this stack.”你几乎肯定不需要部署或修改这个栈。这是理解整个目录的基调——它不是通用 CI 组件而是按需供给的资源层。什么时候才需要部署只有以下两类场景才需要亲自部署正在修改测试基础设施的 CDK 代码本身即test-infra/下的栈定义正在迭代那些依赖本栈 SSM 参数的特定测试KB 摄取、SSH 沙箱需要在本地反复运行它们。什么时候明确不要部署运行单元测试任意包的npm test运行大多数集成测试它们不依赖预置基础设施审查或修改 SDK 代码、文档、工具或 CLI提交 PR 时——CI 会自动针对团队预先置备的资源运行依赖基础设施的测试你完全不需要本地部署。换句话说“开一个 PR让 CI 替你跑”是绝大多数贡献者的正确路径无需 AWS 账号即可完成全部集成测试验证。红线永不设置STRANDS_TEST_INFRA_INTERNALtruetest-infra/AGENTS.md用加粗强调了一条铁律Never setSTRANDS_TEST_INFRA_INTERNALtrue。原因在于该开关会为测试角色附加一份宽泛的内部 IAM 策略并配置 GitHub OIDC 信任关系。这些配置只在 Strands 团队自己的测试账号中有意义。在任意其他账号中开启它会创建一个拥有“并不存在的资源”权限的角色——既无意义也存在安全风险。源码印证了这一点在 integ-test-role.ts 中internal模式通过addLegacyBasePolicy()附加了覆盖 Bedrock 模型调用、知识库管理、Secrets Manager、AOSSOpenSearch Serverless、S3、CloudWatch 等一大批权限的宽松策略同时要求必须显式设置STRANDS_TEST_INFRA_PRIVATE_REPOS、STRANDS_TEST_INFRA_BUCKET_NAMES、STRANDS_TEST_INFRA_PERSISTENT_BUCKET_NAMES、STRANDS_TEST_INFRA_SECRET_NAMES等环境变量requiredInternalEnv未设置即抛错。这套策略是与内部账号的存量资源绑定的社区部署永远不该触碰。快速开始从零部署一套测试基础设施部署步骤本身非常简单默认的npx cdk deploy即可覆盖绝大多数场景。完整命令流如下。前置条件Node.js 22package.json的engines字段明确要求node 22已为目标账号配置好 AWS CLI 凭证目标账号/区域已完成 CDK bootstrapnpx cdk bootstrap。安装与部署cd test-infra npm install npx cdk deploy默认部署全部 feature并创建一个你所在账号可担任的测试角色。账号与区域从你的 AWS CLI profile 自动推断详见下文“账号/区域解析”。只部署单个 featurenpx cdk deploy -c testFeaturesbedrock-knowledge-base通过 CDK context 参数testFeatures可以精确裁剪部署范围支持逗号分隔多个值如-c testFeaturesbedrock-knowledge-base,ssh-ec2。未设置时默认部署全部。显式指定账号/区域export STRANDS_TEST_INFRA_DEPLOYMENT_ACCOUNT123456789012 export STRANDS_TEST_INFRA_DEPLOYMENT_REGIONus-east-1 npx cdk deploy类型检查与单元测试npm run build # 仅类型检查noEmit npm test # 15 条断言覆盖全部 feature、feature 切换、IAM 策略销毁npx cdk destroy得益于全局 DESTROY 移除策略一条命令即可完整清理不留孤儿资源、不产生命名冲突。配置参考feature 与输入参数总表输入通道用途默认值testFeaturesCDK context-c testFeaturesa,b指定要置备的 feature 子集allSTRANDS_TEST_INFRA_INTERNAL环境变量true时生效附加内部遗留策略 GitHub OIDC 信任falseSTRANDS_TEST_INFRA_DEPLOYMENT_ACCOUNT环境变量目标 AWS 账号从 CLI profile 推断STRANDS_TEST_INFRA_DEPLOYMENT_REGION环境变量目标 AWS 区域从 CLI profile 推断账号/区域的解析顺序源码视角bin/test-infra.ts 给出了精确的解析逻辑账号优先级STRANDS_TEST_INFRA_DEPLOYMENT_ACCOUNT→CDK_DEFAULT_ACCOUNT→AWS_ACCOUNT_ID区域优先级STRANDS_TEST_INFRA_DEPLOYMENT_REGION→CDK_DEFAULT_REGION→AWS_REGION两者均无法确定时直接抛错并提示配置 AWS CLI 凭证或显式设置上述环境变量。同时testFeaturescontext 在入口处就做合法性校验非VALID_TEST_FEATURES中的值会立即抛出Unknown test feature错误并列出合法值。feature 清单栈会置备什么Feature置备的资源写入的 SSM 参数bedrock-knowledge-baseBedrock 知识库 S3 Vectors 索引 S3 与 CUSTOM 两类数据源 源数据桶/strands/test-infra/bedrock-knowledge-base/{knowledge-base-id, s3-data-source-id, custom-data-source-id, s3-source-bucket-name}ssh-ec2t4g.nano EC2 实例私有、仅 SSM 访问 VPC 接口终端节点 ED25519 密钥对/strands/test-infra/ssh-ec2/{instance-id, private-key-parameter-name}两个 feature 相互独立、可分别开关栈级开关逻辑见 test-infra-stack.ts 中的enabled()判断selected.includes(all) || selected.includes(feature)。核心机制SSM 参数路径解析测试如何拿到资源 ID这是整套设计最值得称道的部分。Bedrock 知识库 ID、数据源 ID、EC2 实例 ID 等都是部署时由 AWS 服务动态生成的无法预先硬编码。test-infra的解法是部署时把动态 ID 写入SSM Parameter Store的稳定路径测试代码只硬编码稳定路径运行时执行一次GetParameter解析出真实 ID不扫描名称、不节流、无硬编码漂移。路径的单一事实来源是 constants.tsexport const SSM_PARAMETER_NAMESPACE /strands/test-infra; export function ssmParameterPath(feature: TestFeature, ...segments: string[]): string { return [SSM_PARAMETER_NAMESPACE, feature, ...segments].join(/); }写入方construct和读取方集成测试都通过同一个ssmParameterPath()派生路径从根本上避免路径漂移。测试侧用法README 给出的示例import { ssmParameterPath } from test-infra/lib/constants; const kbId await ssm.getParameter({ Name: ssmParameterPath(bedrock-knowledge-base, knowledge-base-id) });该设计意味着同一套测试可以跑在任意一个已部署的栈实例上无需任何硬编码 ID。架构速览从入口到构造test-infra/README.md给出了清晰的目录架构bin/test-infra.ts Entry point, env resolution, feature validation lib/ constants.ts TestFeature type, VALID_TEST_FEATURES, ssmParameterPath() stacks/test-infra-stack.ts Thin orchestrator: feature gating role constructs/ test-feature-construct.ts Base class: ssmPath() grantSsmParameterRead() integ-test-role.ts Shared test role (OIDC trust in internal mode) bedrock-knowledge-base-test-resources KB S3 Vectors data sources SSM grants ssh-ec2-test-resources.ts EC2 VPC endpoints key pair SSM grants test/test-infra.test.ts 15 unit tests (CDK assertions)分层职责bin/test-infra.ts入口点解析 context 与环境变量、校验 feature 合法性、确定账号/区域test-infra-stack.ts薄编排层创建共享测试角色并按enabled()判断是否实例化各 feature constructtest-feature-construct.ts所有 feature 的抽象基类提供ssmPath()和grantSsmParameterRead(role)授予对自身命名空间下全部参数的ssm:GetParameter/ssm:GetParameters读取权integ-test-role.ts共享测试角色。社区模式信任当前账号主体AccountPrincipal内部模式则信任 GitHub Actions OIDC 联邦主体限定repo:strands-agents/*下的公开仓库列表以及STRANDS_TEST_INFRA_RUNNER_ROLES指定的角色最大会话时长 1 小时并始终附带sts:GetCallerIdentity。每个 feature construct 会把自身范围内的最小权限以增量方式附加到共享角色上——栈不做全局授权权限与资源一一对应。深入 feature 一Bedrock 知识库RAG 集成测试bedrock-knowledge-base-test-resources.ts 置备的是一个由 S3 Vectors 索引支撑的 Bedrock 知识库同时提供 S3 与 CUSTOM 两类数据源分别对应 Bedrock 支持的两条直接摄取direct-ingestion路径S3 数据源先在源数据桶中放置对象再通过 S3 URI 触发摄取CUSTOM 数据源不经任何存储直接通过 API 内联推送文档内容。几个关键实现细节均有测试断言佐证向量索引参数使用 Amazon Titan Text Embeddings v21024 维、float32、cosine 距离S3 Vectors 索引必须与之一致——DataType: float32、Dimension: 1024、DistanceMetric: cosine非过滤元数据键AMAZON_BEDROCK_TEXT与AMAZON_BEDROCK_METADATA是 Bedrock 写入每条向量的保留键必须排除在可过滤键之外否则摄取会失败服务角色防混淆代理confused deputyBedrock 服务角色通过aws:SourceAccount与本账号相等、aws:SourceArn限定本账号知识库 ARN 的双重条件把信任边界锁死在本账号最小化摄取授权grantUsage()仅授予bedrock:Retrieve与直接摄取 APIIngestKnowledgeBaseDocuments等刻意排除bedrock:StartIngestionJob——因为相关测试只验证同步直接摄取接口。对应用例可见 test-infra.test.ts断言了向量索引的 1024 维/cosine/float32 配置、知识库使用 S3_VECTORS 存储与 Titan v2 嵌入、两类数据源均带DataDeletionPolicy: DELETE、以及服务角色只能被本账号 Bedrock 担任。深入 feature 二SSH EC2SSH 沙箱集成测试ssh-ec2-test-resources.ts 置备的是一个最小的可达 Linux 实例专供 SSH 沙箱集成测试连接使用。它的网络设计极其克制t4g.nano当前最便宜的新一代 burstable 实例ARM64 Amazon Linux 2023开箱即带 sshd无公网 IP、无任何入站安全组规则测试通过 SSM Session Manager 端口转发aws ssm start-session --document AWS-StartPortForwardingSession访问 sshd唯一的入站通道是 SSM Agent 的出站链路完全隔离的 VPC单可用区、无 NAT 网关、仅 PRIVATE_ISOLATED 子网配合3 个 SSM 接口终端节点SSM、SSM Messages、EC2 Messages——这是 Session Manager从而端口转发所需的最小集合ED25519 密钥对CDK 自动把私钥写入 SSM Parameter StoreIMDSv2 强制启用并附加AmazonSSMManagedInstanceCore托管策略。测试角色侧grantUsage()授予的权限精确对应连接路径ssm:StartSession限定实例与AWS-StartPortForwardingSession文档、ssmmessages:OpenDataChannel与ssm:TerminateSession限定session/${aws:userid}-*即仅本人会话、私钥参数读取以及命名空间内 SSM 参数读取。单元测试对此的断言包括实例为 t4g.nano 且无公网 IP、VPC 恰好有 3 个接口终端节点且无 NAT 网关、授予的 action 集合、以及安全组无任何 22 端口入站规则。通过 CDK 断言验证行为15 条单元测试test-infra/test/test-infra.test.ts使用aws-cdk-lib/assertions对合成后的 CloudFormation 模板做断言无需真正部署即可验证基础设施定义的正确性覆盖KB 配置向量索引规格、嵌入模型 ARN、存储类型、两类数据源、服务角色信任条件SSH 配置实例类型、接口终端节点数量、无 NAT、无 22 端口入站、IMDSv2角色策略内部模式 OIDC 信任 vs 社区模式账号主体信任、RUNNER_ROLES的 AssumeRole、内部策略包含 Bidi 测试所需权限如polly:SynthesizeSpeech、Nova Sonic 模型调用、社区模式不附加宽泛遗留策略feature 切换只选 KB 时 EC2 资源数为 0只选 SSH 时 KB 资源数为 0默认all两者各 1SSM 参数逐一断言 4 个 KB 参数与 2 个 SSH 参数的完整路径如/strands/test-infra/bedrock-knowledge-base/knowledge-base-id。运行方式即前文提到的npm testJest见 package.json。扩展指南如何新增一个测试 featuretest-infra/README.md给出了标准的七步流程配合本文的源码分析可以更清楚地理解每一环在lib/constants.ts的TestFeature类型与VALID_TEST_FEATURES数组中添加 feature 名类型由该 const 数组自动推导在lib/constructs/新建一个继承TestFeatureConstruct的 construct声明readonly featureName your-feature as const它是 SSM 路径与开关判断的依据通过this.ssmPath(param-name)把部署期生成的 ID 发布为 SSM 参数实现grantUsage(role)并在方法末尾调用this.grantSsmParameterRead(role)这样读取方只需一次性获得本 feature 命名空间的参数读权限在lib/stacks/test-infra-stack.ts中以if (enabled(your-feature))接入在test/test-infra.test.ts中添加 CDK 断言测试。这套模式保证每个新 feature 自带独立的 SSM 命名空间、精确到自身资源的权限授权、可独立裁剪部署并且与既有测试完全解耦。必须遵守的约定一律 DESTROYtest-infra/AGENTS.md的最后一条约定是硬性要求栈内所有资源必须指定removalPolicy: cdk.RemovalPolicy.DESTROYL1 构造则调用applyRemovalPolicy(DESTROY)严禁使用 RETAIN。理由很直白这是测试基础设施必须能在cdk destroy时干净利落地整体拆除不留孤儿资源也不在重复部署时产生命名冲突。这一约定贯穿全部构造——源数据桶并配autoDeleteObjects: true、S3 Vectors 桶与索引、知识库、两类数据源、实例与密钥对全部遵循单元测试也通过AWS::SSM::Parameter的路径断言间接锁定了资源命名空间的可预测性。总结test-infra/是一个“按需供给、用完即毁”的 AWS 测试基础设施栈绝大多数人不必碰它但当你需要本地迭代 KB 摄取、SSH 沙箱测试或要在一个全新 AWS 账号里独立支撑完整测试套件时npx cdk deploy-c testFeatures... SSM 参数路径解析这套组合就是你与基础设施依赖型测试之间的最短路径。记住两条红线绝不在外部账号设置STRANDS_TEST_INFRA_INTERNALtrue所有资源一律 DESTROY。若你打算扩展新 featureTestFeatureConstruct基类 七步流程提供了高度一致的模板让新资源可以无缝融入既有的参数解析与最小权限体系。赞分享人工智能大模型AI AgentAgent 框架多智能体工具调用MCP 服务【免费下载链接】harness-sdkBuild an agent harness and control it end-to-end. Open-source SDK for production AI agents in Python TypeScript - any model, any cloud.项目地址https://gitcode.com/GitHub_Trending/sdkpython13/harness-sdk点击查看免费下载相关推荐aws-doc-sdk-examples 测试基础设施部署指南基于 AWS CDK 的多账户集成测试编排aws doc sdk examples 测试基础设施部署指南基于 AWS CDK 的多账户集成测试编排 导读 本文面向需要在真实 AWS 环境中验证 SDK示例工程教程后端使用 AWS CDK 部署 Amazon ECR Public Repositories 栈为 AWS SDK 示例镜像构建测试自动化基础设施使用 AWS CDK 部署 Amazon ECR Public Repositories 栈为 AWS SDK 示例镜像构建测试自动化基础设施 导读 本文围绕示例工程教程后端使用 AWS CDK 部署 ECR Images 堆栈aws-doc-sdk-examples 多语言测试自动化中的镜像基础设施使用 AWS CDK 部署 ECR Images 堆栈aws doc sdk examples 多语言测试自动化中的镜像基础设施 导读 本文围绕 aws do示例工程教程后端上一篇Paper2Slides完整教程5分钟学会AI幻灯片制作和文档转换下一篇部署fullstack-graphql-airbnb-clone到生产环境Docker与云服务配置教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/28 2:28:27 · 阅读 1.2k harness-sdk 测试基础设施 CDK 栈（test-infra）实战指南：部署、配置与扩展
人工智能大模型AI AgentAgent 框架多智能体工具调用MCP 服务【免费下载链接】harness-sdkBuild an agent harness and control it end-to-end. Open-source SDK for production AI agents in Python TypeScript - any model, any cloud.项目地址https://gitcode.com/GitHub_Trending/sdkpython13/harness-sdk点击查看免费下载本文围绕 harness-sdk 仓库中test-infra/目录的 CDK 栈展开它是一套面向“基础设施依赖型集成测试”的 AWS 资源供给栈Bedrock 知识库、SSM-only EC2 沙箱等绝大多数开发者无需触碰但当你需要本地迭代 KB 摄取、SSH 沙箱相关测试或要在全新 AWS 账号中独立跑完整测试套件时它就是必经之路。读完本文你将掌握该栈的部署时机判断、feature 化裁剪部署、SSM 参数解析机制、内部模式的危险边界以及如何按约定新增一个测试 feature。先认清定位这套栈服务的是“少数测试”test-infra是一个用 AWS CDK 编写的独立栈为harness-sdk仓库中一小部分集成测试提供共享 AWS 资源Bedrock 知识库、EC2 实例等。它服务的是那些依赖具体基础设施的功能测试——典型如 RAG 知识库KB 摄取和 SSH 沙箱相关测试。绝大多数测试包括大多数集成测试不依赖这套资源。test-infra/AGENTS.md开篇就给出了一句核心指引“You almost certainly do not need to deploy or modify this stack.”你几乎肯定不需要部署或修改这个栈。这是理解整个目录的基调——它不是通用 CI 组件而是按需供给的资源层。什么时候才需要部署只有以下两类场景才需要亲自部署正在修改测试基础设施的 CDK 代码本身即test-infra/下的栈定义正在迭代那些依赖本栈 SSM 参数的特定测试KB 摄取、SSH 沙箱需要在本地反复运行它们。什么时候明确不要部署运行单元测试任意包的npm test运行大多数集成测试它们不依赖预置基础设施审查或修改 SDK 代码、文档、工具或 CLI提交 PR 时——CI 会自动针对团队预先置备的资源运行依赖基础设施的测试你完全不需要本地部署。换句话说“开一个 PR让 CI 替你跑”是绝大多数贡献者的正确路径无需 AWS 账号即可完成全部集成测试验证。红线永不设置STRANDS_TEST_INFRA_INTERNALtruetest-infra/AGENTS.md用加粗强调了一条铁律Never setSTRANDS_TEST_INFRA_INTERNALtrue。原因在于该开关会为测试角色附加一份宽泛的内部 IAM 策略并配置 GitHub OIDC 信任关系。这些配置只在 Strands 团队自己的测试账号中有意义。在任意其他账号中开启它会创建一个拥有“并不存在的资源”权限的角色——既无意义也存在安全风险。源码印证了这一点在 integ-test-role.ts 中internal模式通过addLegacyBasePolicy()附加了覆盖 Bedrock 模型调用、知识库管理、Secrets Manager、AOSSOpenSearch Serverless、S3、CloudWatch 等一大批权限的宽松策略同时要求必须显式设置STRANDS_TEST_INFRA_PRIVATE_REPOS、STRANDS_TEST_INFRA_BUCKET_NAMES、STRANDS_TEST_INFRA_PERSISTENT_BUCKET_NAMES、STRANDS_TEST_INFRA_SECRET_NAMES等环境变量requiredInternalEnv未设置即抛错。这套策略是与内部账号的存量资源绑定的社区部署永远不该触碰。快速开始从零部署一套测试基础设施部署步骤本身非常简单默认的npx cdk deploy即可覆盖绝大多数场景。完整命令流如下。前置条件Node.js 22package.json的engines字段明确要求node 22已为目标账号配置好 AWS CLI 凭证目标账号/区域已完成 CDK bootstrapnpx cdk bootstrap。安装与部署cd test-infra npm install npx cdk deploy默认部署全部 feature并创建一个你所在账号可担任的测试角色。账号与区域从你的 AWS CLI profile 自动推断详见下文“账号/区域解析”。只部署单个 featurenpx cdk deploy -c testFeaturesbedrock-knowledge-base通过 CDK context 参数testFeatures可以精确裁剪部署范围支持逗号分隔多个值如-c testFeaturesbedrock-knowledge-base,ssh-ec2。未设置时默认部署全部。显式指定账号/区域export STRANDS_TEST_INFRA_DEPLOYMENT_ACCOUNT123456789012 export STRANDS_TEST_INFRA_DEPLOYMENT_REGIONus-east-1 npx cdk deploy类型检查与单元测试npm run build # 仅类型检查noEmit npm test # 15 条断言覆盖全部 feature、feature 切换、IAM 策略销毁npx cdk destroy得益于全局 DESTROY 移除策略一条命令即可完整清理不留孤儿资源、不产生命名冲突。配置参考feature 与输入参数总表输入通道用途默认值testFeaturesCDK context-c testFeaturesa,b指定要置备的 feature 子集allSTRANDS_TEST_INFRA_INTERNAL环境变量true时生效附加内部遗留策略 GitHub OIDC 信任falseSTRANDS_TEST_INFRA_DEPLOYMENT_ACCOUNT环境变量目标 AWS 账号从 CLI profile 推断STRANDS_TEST_INFRA_DEPLOYMENT_REGION环境变量目标 AWS 区域从 CLI profile 推断账号/区域的解析顺序源码视角bin/test-infra.ts 给出了精确的解析逻辑账号优先级STRANDS_TEST_INFRA_DEPLOYMENT_ACCOUNT→CDK_DEFAULT_ACCOUNT→AWS_ACCOUNT_ID区域优先级STRANDS_TEST_INFRA_DEPLOYMENT_REGION→CDK_DEFAULT_REGION→AWS_REGION两者均无法确定时直接抛错并提示配置 AWS CLI 凭证或显式设置上述环境变量。同时testFeaturescontext 在入口处就做合法性校验非VALID_TEST_FEATURES中的值会立即抛出Unknown test feature错误并列出合法值。feature 清单栈会置备什么Feature置备的资源写入的 SSM 参数bedrock-knowledge-baseBedrock 知识库 S3 Vectors 索引 S3 与 CUSTOM 两类数据源 源数据桶/strands/test-infra/bedrock-knowledge-base/{knowledge-base-id, s3-data-source-id, custom-data-source-id, s3-source-bucket-name}ssh-ec2t4g.nano EC2 实例私有、仅 SSM 访问 VPC 接口终端节点 ED25519 密钥对/strands/test-infra/ssh-ec2/{instance-id, private-key-parameter-name}两个 feature 相互独立、可分别开关栈级开关逻辑见 test-infra-stack.ts 中的enabled()判断selected.includes(all) || selected.includes(feature)。核心机制SSM 参数路径解析测试如何拿到资源 ID这是整套设计最值得称道的部分。Bedrock 知识库 ID、数据源 ID、EC2 实例 ID 等都是部署时由 AWS 服务动态生成的无法预先硬编码。test-infra的解法是部署时把动态 ID 写入SSM Parameter Store的稳定路径测试代码只硬编码稳定路径运行时执行一次GetParameter解析出真实 ID不扫描名称、不节流、无硬编码漂移。路径的单一事实来源是 constants.tsexport const SSM_PARAMETER_NAMESPACE /strands/test-infra; export function ssmParameterPath(feature: TestFeature, ...segments: string[]): string { return [SSM_PARAMETER_NAMESPACE, feature, ...segments].join(/); }写入方construct和读取方集成测试都通过同一个ssmParameterPath()派生路径从根本上避免路径漂移。测试侧用法README 给出的示例import { ssmParameterPath } from test-infra/lib/constants; const kbId await ssm.getParameter({ Name: ssmParameterPath(bedrock-knowledge-base, knowledge-base-id) });该设计意味着同一套测试可以跑在任意一个已部署的栈实例上无需任何硬编码 ID。架构速览从入口到构造test-infra/README.md给出了清晰的目录架构bin/test-infra.ts Entry point, env resolution, feature validation lib/ constants.ts TestFeature type, VALID_TEST_FEATURES, ssmParameterPath() stacks/test-infra-stack.ts Thin orchestrator: feature gating role constructs/ test-feature-construct.ts Base class: ssmPath() grantSsmParameterRead() integ-test-role.ts Shared test role (OIDC trust in internal mode) bedrock-knowledge-base-test-resources KB S3 Vectors data sources SSM grants ssh-ec2-test-resources.ts EC2 VPC endpoints key pair SSM grants test/test-infra.test.ts 15 unit tests (CDK assertions)分层职责bin/test-infra.ts入口点解析 context 与环境变量、校验 feature 合法性、确定账号/区域test-infra-stack.ts薄编排层创建共享测试角色并按enabled()判断是否实例化各 feature constructtest-feature-construct.ts所有 feature 的抽象基类提供ssmPath()和grantSsmParameterRead(role)授予对自身命名空间下全部参数的ssm:GetParameter/ssm:GetParameters读取权integ-test-role.ts共享测试角色。社区模式信任当前账号主体AccountPrincipal内部模式则信任 GitHub Actions OIDC 联邦主体限定repo:strands-agents/*下的公开仓库列表以及STRANDS_TEST_INFRA_RUNNER_ROLES指定的角色最大会话时长 1 小时并始终附带sts:GetCallerIdentity。每个 feature construct 会把自身范围内的最小权限以增量方式附加到共享角色上——栈不做全局授权权限与资源一一对应。深入 feature 一Bedrock 知识库RAG 集成测试bedrock-knowledge-base-test-resources.ts 置备的是一个由 S3 Vectors 索引支撑的 Bedrock 知识库同时提供 S3 与 CUSTOM 两类数据源分别对应 Bedrock 支持的两条直接摄取direct-ingestion路径S3 数据源先在源数据桶中放置对象再通过 S3 URI 触发摄取CUSTOM 数据源不经任何存储直接通过 API 内联推送文档内容。几个关键实现细节均有测试断言佐证向量索引参数使用 Amazon Titan Text Embeddings v21024 维、float32、cosine 距离S3 Vectors 索引必须与之一致——DataType: float32、Dimension: 1024、DistanceMetric: cosine非过滤元数据键AMAZON_BEDROCK_TEXT与AMAZON_BEDROCK_METADATA是 Bedrock 写入每条向量的保留键必须排除在可过滤键之外否则摄取会失败服务角色防混淆代理confused deputyBedrock 服务角色通过aws:SourceAccount与本账号相等、aws:SourceArn限定本账号知识库 ARN 的双重条件把信任边界锁死在本账号最小化摄取授权grantUsage()仅授予bedrock:Retrieve与直接摄取 APIIngestKnowledgeBaseDocuments等刻意排除bedrock:StartIngestionJob——因为相关测试只验证同步直接摄取接口。对应用例可见 test-infra.test.ts断言了向量索引的 1024 维/cosine/float32 配置、知识库使用 S3_VECTORS 存储与 Titan v2 嵌入、两类数据源均带DataDeletionPolicy: DELETE、以及服务角色只能被本账号 Bedrock 担任。深入 feature 二SSH EC2SSH 沙箱集成测试ssh-ec2-test-resources.ts 置备的是一个最小的可达 Linux 实例专供 SSH 沙箱集成测试连接使用。它的网络设计极其克制t4g.nano当前最便宜的新一代 burstable 实例ARM64 Amazon Linux 2023开箱即带 sshd无公网 IP、无任何入站安全组规则测试通过 SSM Session Manager 端口转发aws ssm start-session --document AWS-StartPortForwardingSession访问 sshd唯一的入站通道是 SSM Agent 的出站链路完全隔离的 VPC单可用区、无 NAT 网关、仅 PRIVATE_ISOLATED 子网配合3 个 SSM 接口终端节点SSM、SSM Messages、EC2 Messages——这是 Session Manager从而端口转发所需的最小集合ED25519 密钥对CDK 自动把私钥写入 SSM Parameter StoreIMDSv2 强制启用并附加AmazonSSMManagedInstanceCore托管策略。测试角色侧grantUsage()授予的权限精确对应连接路径ssm:StartSession限定实例与AWS-StartPortForwardingSession文档、ssmmessages:OpenDataChannel与ssm:TerminateSession限定session/${aws:userid}-*即仅本人会话、私钥参数读取以及命名空间内 SSM 参数读取。单元测试对此的断言包括实例为 t4g.nano 且无公网 IP、VPC 恰好有 3 个接口终端节点且无 NAT 网关、授予的 action 集合、以及安全组无任何 22 端口入站规则。通过 CDK 断言验证行为15 条单元测试test-infra/test/test-infra.test.ts使用aws-cdk-lib/assertions对合成后的 CloudFormation 模板做断言无需真正部署即可验证基础设施定义的正确性覆盖KB 配置向量索引规格、嵌入模型 ARN、存储类型、两类数据源、服务角色信任条件SSH 配置实例类型、接口终端节点数量、无 NAT、无 22 端口入站、IMDSv2角色策略内部模式 OIDC 信任 vs 社区模式账号主体信任、RUNNER_ROLES的 AssumeRole、内部策略包含 Bidi 测试所需权限如polly:SynthesizeSpeech、Nova Sonic 模型调用、社区模式不附加宽泛遗留策略feature 切换只选 KB 时 EC2 资源数为 0只选 SSH 时 KB 资源数为 0默认all两者各 1SSM 参数逐一断言 4 个 KB 参数与 2 个 SSH 参数的完整路径如/strands/test-infra/bedrock-knowledge-base/knowledge-base-id。运行方式即前文提到的npm testJest见 package.json。扩展指南如何新增一个测试 featuretest-infra/README.md给出了标准的七步流程配合本文的源码分析可以更清楚地理解每一环在lib/constants.ts的TestFeature类型与VALID_TEST_FEATURES数组中添加 feature 名类型由该 const 数组自动推导在lib/constructs/新建一个继承TestFeatureConstruct的 construct声明readonly featureName your-feature as const它是 SSM 路径与开关判断的依据通过this.ssmPath(param-name)把部署期生成的 ID 发布为 SSM 参数实现grantUsage(role)并在方法末尾调用this.grantSsmParameterRead(role)这样读取方只需一次性获得本 feature 命名空间的参数读权限在lib/stacks/test-infra-stack.ts中以if (enabled(your-feature))接入在test/test-infra.test.ts中添加 CDK 断言测试。这套模式保证每个新 feature 自带独立的 SSM 命名空间、精确到自身资源的权限授权、可独立裁剪部署并且与既有测试完全解耦。必须遵守的约定一律 DESTROYtest-infra/AGENTS.md的最后一条约定是硬性要求栈内所有资源必须指定removalPolicy: cdk.RemovalPolicy.DESTROYL1 构造则调用applyRemovalPolicy(DESTROY)严禁使用 RETAIN。理由很直白这是测试基础设施必须能在cdk destroy时干净利落地整体拆除不留孤儿资源也不在重复部署时产生命名冲突。这一约定贯穿全部构造——源数据桶并配autoDeleteObjects: true、S3 Vectors 桶与索引、知识库、两类数据源、实例与密钥对全部遵循单元测试也通过AWS::SSM::Parameter的路径断言间接锁定了资源命名空间的可预测性。总结test-infra/是一个“按需供给、用完即毁”的 AWS 测试基础设施栈绝大多数人不必碰它但当你需要本地迭代 KB 摄取、SSH 沙箱测试或要在一个全新 AWS 账号里独立支撑完整测试套件时npx cdk deploy-c testFeatures... SSM 参数路径解析这套组合就是你与基础设施依赖型测试之间的最短路径。记住两条红线绝不在外部账号设置STRANDS_TEST_INFRA_INTERNALtrue所有资源一律 DESTROY。若你打算扩展新 featureTestFeatureConstruct基类 七步流程提供了高度一致的模板让新资源可以无缝融入既有的参数解析与最小权限体系。赞分享人工智能大模型AI AgentAgent 框架多智能体工具调用MCP 服务【免费下载链接】harness-sdkBuild an agent harness and control it end-to-end. Open-source SDK for production AI agents in Python TypeScript - any model, any cloud.项目地址https://gitcode.com/GitHub_Trending/sdkpython13/harness-sdk点击查看免费下载相关推荐aws-doc-sdk-examples 测试基础设施部署指南基于 AWS CDK 的多账户集成测试编排aws doc sdk examples 测试基础设施部署指南基于 AWS CDK 的多账户集成测试编排 导读 本文面向需要在真实 AWS 环境中验证 SDK示例工程教程后端使用 AWS CDK 部署 Amazon ECR Public Repositories 栈为 AWS SDK 示例镜像构建测试自动化基础设施使用 AWS CDK 部署 Amazon ECR Public Repositories 栈为 AWS SDK 示例镜像构建测试自动化基础设施 导读 本文围绕示例工程教程后端使用 AWS CDK 部署 ECR Images 堆栈aws-doc-sdk-examples 多语言测试自动化中的镜像基础设施使用 AWS CDK 部署 ECR Images 堆栈aws doc sdk examples 多语言测试自动化中的镜像基础设施 导读 本文围绕 aws do示例工程教程后端上一篇Paper2Slides完整教程5分钟学会AI幻灯片制作和文档转换下一篇部署fullstack-graphql-airbnb-clone到生产环境Docker与云服务配置教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考