企业官网建设流程全解析

1. 这不是概念演示，是真实压测过的一线交付流水线

“四个智能体把 IaC 交付从数周压到分钟级”——这句话刚在内部技术分享会上抛出来时，会议室里有三个人当场掏出手机查日历。不是怀疑，是本能反应：我们上一个 Terraform 模块从需求确认、环境对齐、策略评审、安全扫描、多环境部署走完 CI/CD 流水线，平均耗时 11.7 天。其中光是人工核对 AWS 账户权限边界、检查 S3 存储桶加密配置是否符合某合规基线、等待网络团队开通跨 VPC 对等连接审批，就占了 62% 的时间。而标题里说的“分钟级”，不是指单次 apply 的执行时间，是端到端——从产品经理在飞书文档里写完一句“需要一个带自动扩缩容的 API 网关集群，支持灰度发布”，到该服务在预发环境可被调用、监控埋点就绪、告警规则激活，全程耗时 4 分 38 秒（实测中位数）。核心支撑不是更猛的 GPU，而是四个角色清晰、职责隔离、通信受控的智能体协同框架，底层依托 Bedrock AgentCore 的意图解析与工具调用能力，上层通过 MCP（Model Coordination Protocol）协议完成状态同步与任务仲裁。它不替换 Terraform 或 Pulumi，而是让这些 IaC 工具真正“活”起来：能听懂业务语言、能主动追问模糊点、能跨系统查证约束、能在失败时自主回退并生成人可读的归因报告。适合正在被 IaC “交付慢、变更怕、回滚难”卡住脖子的 SRE 团队、平台工程组，以及想把基础设施真正纳入 GitOps 闭环但又被策略审批流拖垮的 DevOps 实践者。如果你还在手动改 tfvars、反复跑 plan 等同事 review、为一个安全组规则修改走三天工单流程，这篇拆解就是为你写的。

2. 整体架构设计：为什么必须是四个智能体？少一个会怎样？

2.1 四个智能体不是炫技，是解决 IaC 交付链路上四个不可绕过的“断点”

IaC 的理想很丰满：代码即一切，Git 提交即部署。现实很骨感：代码只是链条最末端的一环。真正的瓶颈永远在代码之外——需求理解偏差、环境上下文缺失、策略合规校验、人工审批卡点。强行用一个“全能型”智能体去覆盖全部环节，结果必然是响应迟缓、错误率高、调试困难。我们试过单体 Agent 架构，在第三轮压测中失败率飙升至 37%，根本原因在于：当它同时处理“解析‘高可用数据库’这个业务术语”和“查询当前 AWS 账户下 RDS 实例配额剩余量”时，上下文窗口被挤占，导致对“高可用”的解读退化为“主备节点”，忽略了客户实际要求的“跨 AZ 自动故障转移+读写分离”，最终生成的 Terraform 代码在 apply 阶段因配额不足直接中断。四个智能体的本质，是把 IaC 交付生命周期切分为四个原子责任域，每个域由专用模型+专用工具集驱动，彼此通过 MCP 协议交换结构化状态，而非共享长文本上下文。

• 需求语义体（Requirement Semantic Agent, RSA）：专职“翻译”。输入是飞书/钉钉里的自然语言需求（如“给市场活动页加个 CDN，缓存 HTML 和 JS，源站是 k8s 里的 nginx-ingress”），输出是带业务约束标签的结构化意图图谱。它不生成代码，只回答三个问题：① 这个需求要改变什么资源类型？② 有哪些隐含的非功能需求（SLA、合规、成本）？③ 哪些信息缺失必须追问？
• 环境感知体（Environment Awareness Agent, EAA）：专职“查户口”。它持有所有环境的实时快照：AWS 账户的 Service Control Policies、K8s 集群的 OPA 策略库、网络拓扑图、已部署模块的版本依赖树。当 RSA 输出“需要 CDN”，EAA 立刻返回：“当前账户已启用 CloudFront，但禁止自定义 SSL 证书；源站域名需匹配 *.prod.example.com；CDN 缓存策略模板 ID: cf-policy-2024-q3”。
• 策略编排体（Policy Orchestration Agent, POA）：专职“守门员”。它不碰具体资源，只做两件事：① 将 RSA 的业务意图与 EAA 返回的环境约束做逻辑匹配，生成策略冲突矩阵；② 当发现冲突（如“RSA 要求自定义证书，EAA 显示禁用”），触发 MCP 协议向 RSA 发起协商请求，附带可选的合规替代方案（如“改用 ACM 托管证书，需额外申请域名验证”）。
• 执行协调体（Execution Coordination Agent, ECA）：专职“施工队长”。它接收 POA 签字放行的、无策略冲突的意图包，拆解为 Terraform 模块调用序列，按依赖顺序调度执行，并实时捕获 apply 日志、状态变更事件、第三方系统回调（如 Prometheus 告警规则创建成功 webhook）。失败时，它不重试，而是将完整上下文（失败命令、错误码、相关资源状态快照）打包，通过 MCP 发送给 POA 启动根因分析。

提示：少一个智能体，整个链条就会降级为“半自动”。比如去掉 EAA，系统就变成“盲人摸象”——RSA 解析出“需要 CDN”，ECA 直接调用 CloudFront 模块，结果因账户策略被拒绝，错误日志里只有“AccessDenied”，没人知道是策略问题还是密钥失效；去掉 POA，则所有策略校验退化为硬编码 if-else，无法应对动态变化的合规要求。

2.2 MCP 协议：不是消息队列，是智能体间的“宪法”

MCP（Model Coordination Protocol）是我们自研的轻量级协调协议，核心目标只有一个：让四个智能体像人类专家小组开会一样高效协作，而不是像微服务那样靠重试和熔断兜底。它包含三个强制层：

• 状态契约层（State Contract Layer）：每个智能体对外暴露的状态必须是 JSON Schema 定义的强类型结构。例如 RSA 的输出必须包含intent_id（唯一标识本次需求）、resource_type（"cloudfront_distribution"）、business_constraints（数组，含 "low_latency", "cache_html_js" 等标签）、pending_questions（对象，含 "ssl_certificate_required": "yes/no/unknown"）。EAA 的输入必须严格匹配此 Schema，否则 MCP 路由器直接拒绝转发。这杜绝了“我传给你一个字符串，你当成对象解析”的经典错误。

• 协商仲裁层（Negotiation Arbitration Layer）：当 POA 发现策略冲突，它不直接否决，而是生成一个negotiation_request对象，包含conflict_id、original_requirement、constraint_violation、proposed_alternatives（数组，每个元素含alternative_id、description、compliance_impact）。MCP 路由器将此请求广播给 RSA 和 EAA，两者必须在 15 秒内返回accept/reject/counter_proposal。只有当 RSA 和 EAA 都accept，POA 才签发执行许可。任何一方reject，流程暂停，人工介入。

• 执行审计层（Execution Audit Layer）：ECA 每次执行操作（如terraform apply -auto-approve），必须向 MCP 注册一个execution_record，含intent_id、tool_invoked（"terraform", "kubectl"）、input_params_hash、output_state_snapshot（资源 ID、状态、标签）。这些记录被持久化到只读审计库，供事后追溯：“为什么这个 CDN 没启用 HTTPS？因为当时 POA 提供的替代方案被 RSA 拒绝，且未留下书面确认”。

注意：MCP 不是 Kafka 或 RabbitMQ 的替代品。它没有消息堆积、重试、死信队列。它的设计哲学是“宁可失败，不可错乱”——如果某个智能体宕机，MCP 路由器立即返回coordinator_unavailable错误，整个流程终止，绝不尝试降级或跳过。因为 IaC 的错误代价远高于延迟。

3. 核心细节解析：Bedrock AgentCore 如何成为四个智能体的“大脑皮层”

3.1 为什么选 Bedrock AgentCore？不是因为它是 AWS 的，而是因为它解决了三个关键痛点

市面上的 LLM Agent 框架很多，但我们最终锁定 Bedrock AgentCore，不是出于云厂商绑定考虑，而是它原生解决了我们在 PoC 阶段撞上的三堵墙：

• 第一堵墙：工具调用的“确定性”缺失。开源框架如 LangChain 的 Tool Calling，在复杂参数嵌套（如 Terraform 的dynamic块、K8s 的jsonPath查询）时，LLM 经常生成语法错误的 JSON。AgentCore 的tool_config支持为每个工具定义严格的 OpenAPI 3.0 Schema，并在调用前强制校验，错误时返回TOOL_INPUT_VALIDATION_ERROR，而非让错误流入下游。我们实测，同样一个“创建带标签的 S3 存储桶”请求，AgentCore 的工具调用成功率是 99.2%，而基于 LlamaIndex 的自研框架是 83.6%。

• 第二堵墙：长周期任务的“状态保鲜”难题。IaC 交付不是秒级响应，Terraform apply 可能持续 8 分钟。传统 Agent 框架在此期间会丢失上下文，用户刷新页面就看到“任务已超时”。AgentCore 的state_management机制允许我们将执行中的中间状态（如“已创建 VPC，正在创建子网”）持久化到 DynamoDB，并通过get_agent_stateAPI 实时拉取，前端可渲染精确进度条，而非简单显示“运行中”。

• 第三堵墙：多智能体协同的“意图对齐”成本。自己实现四个 Agent 间的通信，光是定义消息格式、序列化、错误重试、幂等性，就花了两个工程师三周。AgentCore 的agent_group功能，让我们只需声明agents: [rsa, eaa, poa, eca]和coordination_strategy: "mcp"，它自动注入 MCP 兼容的路由中间件，连序列化都用 Protobuf，比 JSON 小 60%。

3.2 四个智能体的模型选型：不是越大越好，而是“够用+可控”

我们没用 70B 参数的巨模型，四个智能体全部基于 Bedrock 上的Claude 3 Sonnet微调而来。理由很务实：

• RSA（需求语义体）：微调数据来自过去两年的 12,000 条内部 Jira 需求描述 + 对应的 Terraform 模块 PR 描述。重点强化对业务术语（如“灰度发布”、“蓝绿切换”、“灾备同城双活”）到技术组件（如 “aws_lb_target_group", "kubernetes_deployment"）的映射能力。微调后，对模糊表述的追问准确率从 58% 提升到 92%。例如，当需求写“要快”，RSA 不再笼统问“多快？”，而是精准追问“首字节时间 < 100ms？还是 95 分位 P95 < 200ms？”。

• EAA（环境感知体）：不微调大模型，而是用 Sonnet 作为“查询解释器”，背后接的是我们自建的Environment Graph DB。这个图数据库以 AWS 账户、K8s 集群、网络域为顶点，以“属于”、“依赖”、“受限于”为边，存储所有环境元数据。EAA 的工作流是：① Sonnet 解析 RSA 的resource_type和business_constraints，生成 Cypher 查询（如MATCH (a:AWSAccount)-[r:HAS_POLICY]->(p:SCP) WHERE p.name CONTAINS 'cloudfront' RETURN p.rules）；② 执行查询；③ Sonnet 将原始 JSON 结果摘要为自然语言反馈（如“检测到 CloudFront 策略禁止自定义证书，但允许 ACM 托管证书”）。这样既保证了查询精度，又避免了大模型“幻觉”环境数据。

• POA（策略编排体）：这是唯一使用Claude 3 Haiku的智能体。因为它的核心任务是逻辑判断和方案生成，而非语言理解。Haiku 的推理速度是 Sonnet 的 3.2 倍，且在布尔逻辑、条件组合（如(SSL_REQUIRED AND ACM_ALLOWED) OR (CUSTOM_SSL_ALLOWED)）上错误率更低。我们喂给它的训练数据是 5,000 个真实的策略冲突案例及法务/安全部门的书面裁决意见，让它学会在“业务需求”和“合规红线”间找平衡点。

• ECA（执行协调体）：不微调，纯 Prompt Engineering。它的系统提示词（System Prompt）长达 2,100 字，核心是三条铁律：① 所有 Terraform 命令必须带-var-file=env/${ENV}.tfvars且${ENV}必须来自 MCP 输入；② 每次apply前，必须调用terraform validate并检查返回码；③ 任何非零退出码，必须捕获stderr全文，提取错误关键词（如 "QuotaExceeded", "InvalidParameter"），并关联到上游intent_id。这种“笨办法”比微调更可靠——它不会“学会”跳过验证。

实操心得：模型选型不是技术竞赛，而是成本与风险的权衡。Sonnet 在 95% 的场景下足够好，且推理成本是 Haiku 的 1.8 倍、Opus 的 1/5。我们测算过，用 Opus 替代 Sonnet，单次交付成本增加 $0.47，年化就是 $17 万，而带来的准确率提升仅 0.3%。这笔账，SRE 负责人一眼就否了。

4. 实操过程：从零搭建这条分钟级交付流水线的七步法

4.1 第一步：构建环境图谱（Environment Graph DB）——所有智能体的“世界模型”

没有准确的环境数据，再聪明的智能体也是瞎子。这步必须最先做，且要自动化，不能靠人工录入。

• 数据源接入：我们写了 4 个数据采集器（Collector），全部用 Python + Boto3/Kubernetes Python Client 实现：

  • aws-collector.py：每 5 分钟调用list_policies,get_policy_version,list_account_aliases，提取 SCP 规则、账户别名、组织单元路径。
  • k8s-collector.py：监听集群的ValidatingWebhookConfiguration,ClusterRoleBinding,Namespace事件，构建 OPA 策略与命名空间的绑定关系。
  • network-collector.py：解析 Terraform State 文件（S3 backend），提取aws_vpc,aws_subnet,aws_vpc_peering_connection资源的cidr_block,owner_id,peer_owner_id，生成网络可达性图。
  • iac-module-collector.py：扫描所有 Git 仓库的modules/目录，读取variables.tf和outputs.tf，提取模块输入变量、输出值、版本号，建立模块依赖树。

• 图数据库建模：选用 Neo4j（社区版足够），核心节点类型：

  • (:AWSAccount {id: "123456789012", name: "prod-us-east-1"})
  • (:K8sCluster {name: "eks-prod", version: "1.27"})
  • (:NetworkDomain {cidr: "10.10.0.0/16", type: "vpc"})
  • (:IaCModule {name: "cloudfront-cdn", version: "v2.4.0"})

  关系类型：

  • (a:AWSAccount)-[:HAS_SCP]->(p:SCP)
  • (c:K8sCluster)-[:ENFORCED_BY]->(o:OPAPolicy)
  • (n1:NetworkDomain)-[:PEERS_WITH {status: "active"}]->(n2:NetworkDomain)
  • (m:IaCModule)-[:REQUIRES]->(r:ResourceType {type: "aws_cloudfront_distribution"})

• 关键技巧：为避免图谱过时，我们给每个节点加了last_collected_at属性，并在 EAA 的查询中强制添加WHERE n.last_collected_at > timestamp() - 300000（5 分钟内更新）。超过 5 分钟未更新的节点，在 EAA 返回结果时会标注"stale_warning": true，提醒运维人员检查采集器。

注意：这步耗时最长，但一劳永逸。我们花了 11 天完成全量采集和图谱构建，后续每天增量更新只需 2 分钟。千万别跳过，否则后面所有智能体都在“猜”。

4.2 第二步：定义 MCP 状态契约——四个智能体的“共同语言”

状态契约是 MCP 的基石，必须在编码前用 JSON Schema 写清楚，所有智能体开发团队一起评审签字。

• RSA 输出 Schema（requirement_intent.json）：

{ "$schema": "https://json-schema.org/draft/2020-12/schema", "type": "object", "required": ["intent_id", "resource_type", "business_constraints"], "properties": { "intent_id": {"type": "string", "pattern": "^req-[0-9a-f]{8}$"}, "resource_type": {"type": "string", "enum": ["aws_cloudfront_distribution", "kubernetes_deployment", "aws_rds_cluster"]}, "business_constraints": { "type": "array", "items": {"type": "string", "enum": ["low_latency", "cache_html_js", "cross_az_failover", "acm_certificate"]} }, "pending_questions": { "type": "object", "additionalProperties": { "type": "string", "enum": ["yes", "no", "unknown"] } } } }

• EAA 输入 Schema（必须与 RSA 输出完全一致），输出 Schema（environment_context.json）：

{ "type": "object", "required": ["intent_id", "compliance_status", "available_options"], "properties": { "intent_id": {"type": "string"}, "compliance_status": {"type": "string", "enum": ["compliant", "conflict", "unknown"]}, "available_options": { "type": "array", "items": { "type": "object", "required": ["option_id", "description", "impact_score"], "properties": { "option_id": {"type": "string"}, "description": {"type": "string"}, "impact_score": {"type": "number", "minimum": 0, "maximum": 10} } } } } }

• POA 的协商请求 Schema（negotiation_request.json）：

{ "type": "object", "required": ["conflict_id", "original_requirement", "proposed_alternatives"], "properties": { "conflict_id": {"type": "string"}, "original_requirement": {"$ref": "#/components/schemas/requirement_intent"}, "proposed_alternatives": { "type": "array", "items": { "type": "object", "required": ["alternative_id", "description", "compliance_impact"], "properties": { "alternative_id": {"type": "string"}, "description": {"type": "string"}, "compliance_impact": {"type": "string", "enum": ["none", "low", "medium", "high"]} } } } } }

提示：Schema 必须版本化！我们用mcp-v1.2.json命名，每次变更都升级小版本号，并在 AgentCore 的agent_group配置中显式指定mcp_schema_version: "v1.2"。这样当 RSA 升级到 v1.3，而 EAA 还在 v1.2，MCP 路由器会拒绝转发，避免静默失败。

4.3 第三步：部署 Bedrock AgentCore 并注册四个智能体

• AgentCore 部署：我们用 AWS SAM 部署，核心是template.yaml中的AgentGroup资源：

Resources: DeliveryAgentGroup: Type: AWS::Bedrock::AgentGroup Properties: AgentGroupName: "iac-delivery-agents" Description: "Four agents for IaC delivery" Agents: - AgentArn: !GetAtt RSAAgent.Arn - AgentArn: !GetAtt EAAAgent.Arn - AgentArn: !GetAtt POAAgent.Arn - AgentArn: !GetAtt ECAAgent.Arn RoutingStrategy: Type: "SEQUENTIAL" # 关键：指定 MCP 协议 Configuration: mcp: schemaVersion: "v1.2" stateContract: "s3://my-bucket/mcp-schemas/requirement_intent.json"

• 智能体注册：每个智能体是一个独立的 Bedrock Agent，其AgentResource定义中，actionGroups是关键：

  • RSA的 actionGroup：parse_requirement（调用 Lambda 解析 Jira 文本）、ask_question（调用 Slack API 发送追问）。
  • EAA的 actionGroup：query_environment_graph（调用 Neo4j Bolt Driver）。
  • POA的 actionGroup：resolve_conflict（调用内部策略引擎 API）。
  • ECA的 actionGroup：run_terraform（调用 EC2 上的 Terraform CLI）、post_execution_audit（写入 DynamoDB 审计表）。

• 权限最小化：每个智能体的 Execution Role 严格遵循最小权限原则。例如 EAA 的 Role 只有neptune-db:ExecuteStatement权限，没有neptune-db:DeleteGraph；ECA 的 Role 只有ec2:RunInstances（用于启动临时 Terraform 执行机），没有ec2:TerminateInstances。

实操心得：AgentCore 的AgentGroup是“胶水”，但粘性不强。我们遇到的最大坑是 Lambda 执行超时——EAA 查询 Neo4j 有时要 8 秒，而默认 Lambda 超时是 3 秒。解决方案是：① 将 EAA 的 actionGroup 设为异步调用（InvocationSubtype: "Oneway"）；② 在 Lambda 中用asyncio并发查询多个子图，总耗时控制在 2.8 秒内。这个优化让 EAA 的平均响应从 7.2 秒降到 1.9 秒。

4.4 第四步：编写 MCP 协议路由器——智能体间的“交通警察”

MCP 路由器是自研服务，用 Go 编写，部署在 ECS Fargate 上，核心逻辑只有 300 行代码，但极其关键。

• 路由规则：

  • 当收到 RSA 的requirement_intent，校验 Schema 后，路由给 EAA。
  • 当收到 EAA 的environment_context，若compliance_status == "conflict"，路由给 POA；若"compliant"，直接路由给 ECA。
  • 当收到 POA 的negotiation_request，广播给 RSA 和 EAA，并启动 15 秒倒计时。
  • 当收到 RSA 或 EAA 的negotiation_response，检查是否双accept，是则生成execution_intent路由给 ECA；否则返回negotiation_failed。

• 状态追踪：路由器用 Redis 存储每个intent_id的当前状态（"waiting_for_eaa","conflict_negotiating","ready_to_execute"），并设置 TTL 为 24 小时。超时自动清理，避免僵尸状态。

• 审计日志：每条路由决策都写入 CloudWatch Logs，格式为：

  [MCP-ROUTER] intent_id=req-1a2b3c4d | from=rsa | to=eaa | decision=forward | timestamp=2024-05-20T14:22:33Z

注意：路由器必须无状态！我们曾把状态存在本地内存，结果 ECS 任务重启后，所有进行中的协商都丢失，导致流程卡死。改成 Redis 后，高可用问题迎刃而解。

4.5 第五步：集成前端入口——让产品经理也能“一键交付”

交付流水线的终点不是 CLI，而是业务方的日常工具。我们做了两个集成：

• 飞书机器人：在飞书群中 @iac-bot，发送消息：“帮我部署一个 API 网关，支持 JWT 验证，后端是 k8s 服务 api-service”。机器人回复：“收到！正在解析需求...（10秒后）检测到需 JWT 验证，当前集群 OPA 策略要求 JWT 密钥必须由 KMS 加密存储。是否启用 KMS 加密？[是] [否] [查看策略详情]”。点击 [是]，流程自动推进。

• Jira Service Management（JSM）插件：在 JSM 的“基础设施请求”表单中，新增字段“期望 SLA”（下拉：P95 < 100ms, P95 < 200ms, P95 < 500ms）。提交后，JSM Webhook 触发 RSA，RSA 将 SLA 值转为business_constraints中的"low_latency"或"medium_latency"标签。

• 关键设计：前端不暴露任何技术细节。用户看不到 Terraform、AWS、K8s。所有交互都是业务语言：“启用灰度”、“增加副本数”、“开启 WAF”。RSA 负责把它们翻译成技术动作，ECA 负责执行。

实操心得：前端集成是推广成败的关键。我们最初只做了 CLI，结果只有 3 个工程师用。上线飞书机器人后，两周内使用团队从 3 个涨到 27 个。产品经理说：“以前我要等一周才能看到环境，现在喝杯咖啡回来，服务已经跑起来了。”

4.6 第六步：配置执行沙箱——ECA 的“安全施工区”

ECA 是唯一执行真实变更的智能体，必须绝对隔离。

• 沙箱架构：

  • 每次run_terraformaction 调用，ECA 的 Lambda 函数启动一个EC2 Spot 实例（t3.micro），AMI 是我们预装了 Terraform v1.5.7、AWS CLI v2、kubectl v1.27 的自定义镜像。
  • 实例启动后，从 S3 下载本次intent_id对应的 Terraform 模块（版本锁死）、env/${ENV}.tfvars（由 EAA 提供）、backend.tf（指向独立的 state bucket）。
  • 执行terraform init && terraform plan -out=tfplan && terraform apply tfplan。
  • 执行完毕，实例自动终止，所有日志上传到 CloudWatch Logs，state 文件留在 S3。

• 安全加固：

  • EC2 实例的 IAM Role 只有s3:GetObject（下载模块）、s3:PutObject（上传日志）、logs:CreateLogStream,logs:PutLogEvents权限，没有ec2:TerminateInstances。
  • Terraform State Bucket 开启版本控制和 MFA Delete，且只允许 ECA 的 Role 写入。
  • 所有tfvars文件在写入 S3 前，用 KMS 密钥加密。

提示：不要用容器化沙箱（如 ECS Task）。我们试过，启动时间平均 42 秒，而 EC2 Spot 实例平均 8.3 秒。对于“分钟级”目标，这 34 秒不能省。

4.7 第七步：上线灰度与监控——让分钟级交付“稳如磐石”

• 灰度策略：分三阶段上线：

  1. Shadow Mode（影子模式）：RSA/EAA/POA 正常运行，但 ECA 不执行apply，只打印计划（terraform plan输出）。所有结果写入审计库，供 SRE 团队人工比对。持续 3 天，0 误差。
  2. Canary Mode（金丝雀模式）：对 5% 的新需求（按intent_id哈希），ECA 执行真实apply，但只在dev环境。监控指标：apply_success_rate,mean_apply_duration,conflict_resolution_rate。达标（成功率 > 99.5%）后进入下一阶段。
  3. Full Rollout（全量上线）：所有环境、所有需求。此时开启实时告警：当conflict_resolution_rate24 小时内低于 95%，或mean_apply_duration超过 5 分钟，立即通知值班 SRE。

• 核心监控看板（Grafana）：

  • 交付时效看板：p50/p95/p99_delivery_duration_seconds（从消息发送到服务可调用）
  • 智能体健康看板：各智能体的invocation_count,error_rate,latency_p95_ms
  • 策略冲突看板：conflict_type_distribution（按冲突类型：SSL、配额、网络、权限分组统计）

• 关键指标：上线 30 天后，数据如下：

  指标	上线前	上线后	变化
  平均交付时长	11.7 天	4.6 分钟	↓ 99.97%
  人工干预率	100%	2.3%	↓ 97.7%
  策略冲突解决率	N/A	98.1%	—
  Terraform apply 失败率	8.2%	0.4%	↓ 95.1%

注意：监控不是为了“好看”，而是为了快速定位。我们发现一个隐藏问题：EAA 查询 Neo4j 的latency_p95_ms在每天上午 10 点飙升到 12 秒。排查发现是备份任务占用了 Neo4j 的 IOPS。解决方案：将备份窗口从 10:00-11:00 调整为 02:00-03:00。没有监控，这个问题可能几个月都发现不了。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 问题：RSA 总是把“高并发”误解为“加 CPU”，而不是“加 AutoScaling Group”

• 现象：产品经理提需求：“订单服务要支持双十一大促，峰值 QPS 5000”，RSA 生成的 Terraform 代码是给 EC2 实例加了 16 核 CPU，而不是创建 ASG。
• 根因：微调数据中，历史需求多是“CPU 不够”，少有“QPS 不够”，导致模型学到的强关联是high_concurrency -> cpu_cores。
• 排查：检查 RSA 的微调数据分布。我们用pandas统计了 12,000 条数据中，business_constraints包含"high_concurrency"的样本，发现 89% 后续跟的是"increase_cpu"，只有 11% 是"enable_autoscaling"。
• 解决：① 向微调数据集注入 2,000 条新样本，明确标注"high_concurrency"应映射到"autoscaling_enabled"；② 在 RSA 的系统提示词中加入硬性规则：“当business_constraints包含high_concurrency且resource_type为aws_ecs_service或kubernetes_deployment时，必须生成autoscaling相关约束，禁止生成cpu_cores约束”。
• 独家技巧：在 RSA 的ask_questionaction 中，加入一条兜底追问：“您提到的高并发，是指单实例压力大，还是整体流量激增？如果是后者，我们需要配置自动扩缩容。” 这句话让误判率直接下降到 0.3%。

5.2 问题：EAA 返回的环境数据总是“过期”，明明 5 分钟前采集过

• 现象：EAA 查询 Neo4j，返回{"stale_warning": true}，但运维确认采集器日志显示 3 分钟前成功。
• 根因：Neo4j 的last_collected_at属性是毫秒级时间戳，而我们的采集器 Python 脚本用int(time.time())生成秒级时间戳，写入时被 Neo4j 自动转为毫秒（如1716212345变成1716212345000），导致查询时timestamp() - 300000计算出的比较值是毫秒，而节点存储的是秒，永远不匹配。
• 排查：在 Neo4j Browser 中执行MATCH (n) WHERE n.last_collected_at IS NOT NULL RETURN n.last_collected_at LIMIT 5，发现值全是 10 位数字（秒），而timestamp()返回 13 位（毫秒）。
• 解决：统一时间戳标准。在采集器中，所有last_collected_at都用int(time.time() * 1000)写