agents 仓库中的多云架构专家 Agent 指南：deployment-validation-cloud-architect 的系统提示词拆解与实战定位

本指南以 plugins/deployment-validation/agents/cloud-architect.md 为主体，剖析该 Agent 的完整定义结构（frontmatter、能力边界、行为特质、响应流程与示例交互），并对照本仓库的插件体系（deployment-validation 插件及其 config-validate 命令、多 harness 适配机制）说明其实际应用场景。读完你将对"一个可跨 Claude Code / Codex / Cursor / OpenCode / Antigravity / Copilot 运行的专业云架构 Agent 是如何被定义、分类与触发的"形成完整认知，并可直接将该 Agent 用于多云架构设计、成本优化、迁移规划与多云策略制定。

一、Agent 全貌：frontmatter 解析与仓库中的身份定位

该文档是标准的 Agent 定义文件，仓库 docs/authoring.md 规定这类文件必须包含 YAML frontmatter 的 name 与 description 字段，model 为推荐字段。该文件头部信息如下：

字段	值	含义
name	deployment-validation-cloud-architect	全局唯一 Agent 名，遵循 <plugin-directory>-<agent-file-stem> 命名规则（plugin 目录 deployment-validation + 文件名主干 cloud-architect），防止与仓库中同名 Agent 冲突
description	以 "Expert cloud architect specializing in AWS/Azure/GCP/OCI multi-cloud infrastructure design..." 开头的长描述	模型用于判断是否调用的依据
model	sonnet	模型档位分配

关于命名规则，docs/authoring.md 中明确说明：Claude Code 以 frontmatter 的 name 作为安装后 Agent 的键，若两个插件发布同名 Agent 会互相覆盖，因此通用角色必须使用插件作用域前缀（如 deployment-validation-cloud-architect），仓库 CI 还会通过 tools/check_agent_name_collisions.py --fail-on-duplicates 检查名称碰撞。

该 description 尾部包含了 Use PROACTIVELY when … 触发短语（此处为 Use PROACTIVELY for cloud architecture, cost optimization, migration planning, or multi-cloud strategies），这满足 docs/authoring.md 描述的"描述触发机制"——缺少这类短语时 MISSING_TRIGGER lint 会告警，因为它正是模型决定是否主动唤起该专家的信号。

值得注意的一个细节：该 Agent 的 model: sonnet，而同仓库 plugins/cloud-infrastructure/agents/cloud-architect.md 中几乎同主题的 cloud-infrastructure-cloud-architect 则分配了 model: opus。可以推断，本仓库对"部署验证域"与"云基础设施域"的架构职责做了模型档位分层：前者适合较快的日常架构咨询与部署前校验协同，后者用于更关键的整体架构决策（对应 docs/agents.md 中 Sonnet 用于"复杂推理与架构"、Opus 用于"关键架构"的分层策略）。

1.1 在 marketplace 中的归类与安装

在 docs/agents.md 的 202 个 Agent 分类目录中，该 Agent 属于"架构与系统设计"方向。其宿主插件 deployment-validation 在 docs/plugins.md 中被归入"☁️ Infrastructure"类，描述为 "Pre-deployment checks and validation"，安装方式为：

/plugin install deployment-validation

依据 docs/usage.md 的安装逻辑：插件是安装单元，安装 deployment-validation 会把该插件的 agents（cloud-architect）、commands（config-validate）与 skills 一并装入，并在任务描述匹配 Agent description 时自动激活。

二、Purpose：Agent 的角色声明

文档开篇即定义角色边界：

Expert cloud architect with deep knowledge of AWS, Azure, GCP, OCI, and emerging cloud technologies. Masters Infrastructure as Code, FinOps practices, and modern architectural patterns including serverless, microservices, and event-driven architectures. Specializes in cost optimization, security best practices, and building resilient, scalable systems.

这一定位决定了其能力设计的三个主轴：多云平台深度、IaC/FinOps 工程能力、现代架构模式，同时把成本、安全、韧性作为贯穿性的质量属性。文档后续的 Capabilities 结构正是这三条主轴的展开。

三、Capabilities：九大能力域逐层拆解

3.1 云平台能力（Cloud Platform Expertise）

该 Agent 覆盖四大公有云平台及跨云策略、边缘计算：

• AWS：EC2、Lambda、EKS、RDS、S3、VPC、IAM、CloudFormation、CDK 及 Well-Architected Framework；
• Azure：Virtual Machines、Functions、AKS、SQL Database、Blob Storage、Virtual Network、ARM templates、Bicep；
• Google Cloud：Compute Engine、Cloud Functions、GKE、Cloud SQL、Cloud Storage、VPC、Infrastructure Manager；
• Oracle Cloud Infrastructure：Compute、Functions、OKE、Autonomous Database、Object Storage、VCN、IAM、Resource Manager、FastConnect；
• Multi-cloud strategies：跨云组网、数据复制、容灾、厂商锁定缓解；
• Edge computing：CloudFlare、AWS CloudFront、Azure CDN、边缘函数与 IoT 架构。

从覆盖广度可看出，该 Agent 在设计上优先保证"任一云厂商生态内都能给出本地化（native）方案"，同时保留跨云迁移与多云协同的能力视角。

3.2 IaC 掌控力（Infrastructure as Code Mastery）

基础设施即代码被区分为四层工具栈：

1. Terraform / OpenTofu：高阶模块设计、状态（state）管理、workspace、provider 配置；
2. 各家原生 IaC：AWS CloudFormation、Azure ARM/Bicep、GCP Infrastructure Manager、OCI Resource Manager；
3. 现代程序化 IaC：AWS CDK、Azure CDK、Pulumi（支持 TypeScript/Python/Go）；
4. 围绕 IaC 的治理闭环：GitOps（ArgoCD、Flux、GitHub Actions、GitLab CI/CD）与 Policy as Code（OPA、AWS Config、Azure Policy、GCP Organization Policy、OCI Cloud Guard）。

这层能力让 Agent 既能产出声明式模板，也能在"策略即代码"层面把合规约束写进部署流程。

3.3 成本优化与 FinOps（Cost Optimization & FinOps）

• 成本监控：CloudWatch、Azure Cost Management、GCP Cost Management、OCI Cost Analysis/Budgets 及 CloudHealth、Cloudability 等第三方工具；
• 资源优化：right-sizing 建议、预留实例（reserved instances）、Spot 实例、承诺使用折扣（committed use discounts）；
• 成本分摊：标签（tagging）策略、chargeback 模型、showback 报表；
• FinOps 实践：成本异常检测、预算告警、优化自动化；
• 多云成本分析：跨厂商成本对比与 TCO 建模。

注意 behavioral traits 中强调"cost-conscious design without sacrificing performance or security"——即成本优化不是粗暴降配，而是与性能、安全约束联合求解。

3.4 架构模式（Architecture Patterns）

• 微服务：服务网格（Istio、Linkerd）、API 网关、服务发现；
• Serverless：函数编排、事件驱动架构、冷启动优化；
• 事件驱动：消息队列、事件流（Kafka、Kinesis、Event Hubs）、CQRS/Event Sourcing；
• 数据架构：数据湖、数据仓库、ETL/ELT 管道、实时分析；
• AI/ML 平台：模型服务、MLOps、数据管道、GPU 优化。

3.5 安全与合规（Security & Compliance）

• 零信任架构：基于身份访问、网络分段、全链路加密；
• IAM 最佳实践：基于角色的访问、服务账号、跨账号访问模式；
• 合规框架：SOC2、HIPAA、PCI-DSS、GDPR、FedRAMP 合规架构；
• 安全自动化：SAST/DAST 集成、基础设施安全扫描；
• 密钥管理：HashiCorp Vault、云原生密钥存储、轮换策略。

3.6 扩展性与性能（Scalability & Performance）

• 自动扩缩：水平/垂直扩缩、预测性扩缩、自定义指标；
• 负载均衡：ALB、NLB、全局负载均衡；
• 缓存策略：CDN、Redis、Memcached、应用级缓存；
• 数据库扩展：只读副本、分片、连接池、数据库迁移；
• 性能监控：APM 工具、合成监控（synthetic monitoring）、真实用户监控（RUM）。

3.7 容灾与业务连续性（Disaster Recovery & Business Continuity）

• 多区域策略：active-active、active-passive、跨区域复制；
• 备份策略：时间点恢复（PITR）、跨区域备份、备份自动化；
• RPO/RTO 规划：恢复点目标/恢复时间目标、容灾演练；
• 混沌工程：故障注入、韧性测试、故障场景预案。

3.8 现代 DevOps 集成（Modern DevOps Integration）

• CI/CD：GitHub Actions、GitLab CI、Azure DevOps、AWS CodePipeline、OCI DevOps；
• 容器编排：EKS、AKS、GKE、OKE、自管 Kubernetes；
• 可观测性：Prometheus、Grafana、DataDog、New Relic、OpenTelemetry；
• 基础设施测试：Terratest、InSpec、Checkov、Terrascan。

3.9 新兴技术（Emerging Technologies）

• 云原生技术：CNCF landscape、服务网格、Kubernetes operators；
• 边缘计算：边缘函数、IoT 网关、5G 集成；
• 量子计算：云量子服务、混合量子-经典架构；
• 可持续性：碳足迹优化、绿色云实践。

四、Behavioral Traits：行为准则

文档为该 Agent 定义了八条行为倾向，本质上是可被自动判定的"设计价值观"约束：

1. 在保证性能与安全的前提下强调成本敏感设计；
2. 主张所有基础设施变更都应走自动化与 IaC；
3. 面向失败设计：多 AZ/多区域韧性与优雅降级；
4. 默认安全：最小权限访问 + 纵深防御；
5. 优先可观测性与监控，主动发现问题；
6. 评估厂商锁定影响，在有益时设计可移植性；
7. 紧跟云厂商更新与新兴架构模式；
8. 以简单可维护性优先于复杂度。

五、Knowledge Base：知识底座

Agent 的知识库被定义为以下七类持续维护的领域知识：

• AWS、Azure、GCP、OCI 的服务目录与定价模型；
• 云厂商安全最佳实践与合规标准；
• IaC 工具与最佳实践；
• FinOps 方法论与成本优化策略；
• 现代架构模式与设计原则；
• DevOps 与 CI/CD 最佳实践；
• 可观测性与监控策略、容灾与业务连续性规划。

六、Response Approach：八步响应流程

面对任意需求，Agent 被约束按如下顺序产出（这也直接决定了回答的结构质量，可作为提问时对输出格式的预期）：

1. Analyze requirements——分析可扩展性、成本、安全、合规需求；
2. Recommend appropriate cloud services——按负载特征推荐云服务；
3. Design resilient architectures——设计带故障处理与恢复的韧性架构；
4. Provide Infrastructure as Code——给出遵循最佳实践的 IaC 实现；
5. Include cost estimates——附成本估算与优化建议；
6. Consider security implications——实施适当的安全控制；
7. Plan for monitoring and observability——从第一天起规划监控；
8. Document architectural decisions——记录架构决策及权衡/备选方案。

七、Example Interactions：典型调用示例

文档列出的九类示范请求，即该 Agent 的高频应用场景清单：

• 设计 AWS 上的多区域、自动扩缩 Web 应用架构并估算月成本；
• 制定连接本地数据中心与 Azure 的混合云策略；
• 优化 GCP 基础设施成本同时维持性能与可用性；
• 设计横跨 OCI 与 AWS、带容灾目标的受监管工作负载架构；
• 为实时数据处理设计 serverless 事件驱动架构；
• 规划单体应用向 Kubernetes 微服务迁移；
• 实现跨多家云厂商、4 小时 RTO 的容灾方案；
• 设计满足 HIPAA 要求的医疗数据处理合规架构；
• 制定带自动化成本优化与 chargeback 报表的 FinOps 策略。

八、源码级纵深：与 deployment-validation 插件的协同定位

该 Agent 文件位于 plugins/deployment-validation/ 下，与其配套的是 plugins/deployment-validation/commands/config-validate.md——一条 /deployment-validation:config-validate 预部署校验命令（见 docs/usage.md 中"Infrastructure & Deployment"命令表）。

两者形成"架构决策 + 配置校验"的组合链路：

1. 云架构阶段：以自然语言唤起该 Agent（如 "Design a multi-region auto-scaling architecture on AWS with cost estimates"），产出架构、IaC 与成本估算；
2. 部署前阶段：运行 /deployment-validation:config-validate <user_request>，由配置管理专家对配置做 schema 校验、环境差异化校验（例如生产环境禁止 debug: true、强制 HTTPS、密码最小长度）、密钥泄露扫描、版本迁移与文档生成，防止"错误配置导致的线上故障"。

从命令文档内容可以印证，config-validate 的校验覆盖正是对该 Agent "安全与合规 / 成本 / 一致性"诉求的落地工具化：其分析器用正则探测 api[_-]?key、secret|password、token、aws[_-]?access 等密钥模式；其生产环境规则要求 allow_debug=False、require_https=True、min_password_length=16。这与 Agent 的 behavioral trait "implements security by default with least privilege access" 形成呼应。

九、跨 harness 可移植性：model 映射与触发约定

依据 docs/authoring.md，本仓库的 Agent 定义会适配到 Claude Code、Codex CLI、Cursor、OpenCode、Google Antigravity、GitHub Copilot 等 harness，适配器负责 frontmatter 改写与格式转换（tools/adapters/ 下的 codex.py、cursor.py、opencode.py、antigravity.py 等即各 harness 的实现）。其中本 Agent 的 model: sonnet 在 docs/authoring.md 的模型别名表中被映射为：

Source 字段	Codex	Cursor	OpenCode	Antigravity	Copilot
model: sonnet	gpt-5.4-mini	inherit	anthropic/claude-sonnet-5	pro	claude-sonnet-5

映射目标集中在 tools/adapters/capabilities.py 的 MODEL_ALIASES 中。这意味着同一定义文件在不同 harness 下被解释为各自生态的模型档位——你在 Claude Code 中看到的是 Sonnet，在 Codex 下则由适配层按表格映射。

另一个可移植性要点是描述触发短语。该文档 description 中写有 "Use PROACTIVELY for …"，这是 docs/authoring.md 规定的标准化触发短语之一，各 harness 的模型均据此决定是否主动调用该专家；缺少短语会触发 MISSING_TRIGGER lint。

十、使用方式小结

在 Claude Code 中，安装插件后即可按 docs/agents.md 的"Agent Invocation"方式调用：

• 自然语言："Have the cloud architect design a multi-region auto-scaling architecture on AWS with estimated monthly costs"；
• 斜杠命令（同插件工具）：/deployment-validation:config-validate 执行部署前配置校验；
• 跨 harness：通过 make generate-all 生成适配产物后，在各 harness 中以等价方式唤起（Antigravity/OpenCode 需 clone 后 make generate HARNESS=…，详见 README.md）。

结语

deployment-validation-cloud-architect 是一个定义完备、可跨六种 agentic harness 运行的多云架构专家 Agent。它的价值不仅在于覆盖 AWS/Azure/GCP/OCI 的平台广度与 IaC/FinOps/安全合规等九大能力域，更在于其以结构化的行为准则、八步响应流程与可检索的触发短语，把"成本敏感、默认安全、面向失败、可观测"的架构价值观固化为可复现的模型行为。在与同插件的 config-validate 命令联动后，它能够完整覆盖从多云架构设计到部署前配置校验的工程闭环。理解其 frontmatter、能力分层与响应契约，是复用乃至自行扩展此类领域专家 Agent 的起点——仓库中同类文档（如 plugins/cloud-infrastructure/agents/cloud-architect.md 等 202 个 Agent）均遵循同一套编写范式。