1. 项目概述当六个编码智能体在 AKS 集群里协同开工到底发生了什么“六个编码智能体一个生产级系统”——这个标题乍看像科幻小说章节但放在今天 DevOps 工程师的日常里它其实是一份可落地、可复现、甚至已在三家中型技术团队跑通的 AgenticOps 实战记录。我从去年底开始在内部搭建这套基于AKSAzure Kubernetes ServiceLab 环境抽象层GitHub Copilot 智能体深度集成的自动化开发流水线核心目标很朴素让工程师从“写重复脚本、填 CI/CD 表单、查日志翻页到第17页”的体力劳动中抽身把注意力真正留给架构设计、边界 case 推演和业务逻辑打磨。不是替代人而是把人从“操作执行者”升级为“意图定义者”和“结果校验者”。这里的Lab不是物理实验室也不是 Jupyter Lab 或 Isaac Lab 那类单机交互环境而是一个被我们明确定义的工程化抽象层它封装了环境初始化、依赖隔离、上下文注入、工具链挂载、权限沙箱、可观测性埋点六大能力是所有智能体运行的“操作系统内核”。你可以在 AKS 上用 Helm Chart 一键部署一个 Lab 实例也可以在本地用 Kind k3s 快速拉起轻量版它不绑定任何 IDE但天然兼容 VS Code、JetBrains 全家桶、甚至纯 Terminal tmux 的极客工作流。而GitHub Copilot在这里也早已不是那个“帮你补全 for 循环”的代码助手。我们通过其开放的 Agent SDK非公开 Beta 接口需申请白名单、Copilot CLI 的扩展能力以及自研的 Copilot Gateway 中间件把它改造成了可编排、可审计、可回滚的编码智能体Coding Agent运行时。六个智能体不是并列关系而是按职责分层有负责需求理解与任务拆解的 Planner Agent有专注 Terraform 模板生成与 drift 检测的 Infra Agent有做单元测试用例生成与覆盖率强化的 Test Agent还有专攻日志模式识别与根因建议的 Ops Agent……它们共享同一个 Lab 环境上下文通过结构化消息总线通信所有操作留痕、所有决策可追溯。AgenticOps 这个词不是造概念而是对当前 DevOps 范式瓶颈的真实回应CI/CD 是管道IaC 是配方但谁来理解“用户说‘首页加载变慢’背后其实是 CDN 缓存策略失效API 网关限流阈值过低”谁来把“下季度要支持东南亚多时区订单履约”自动翻译成数据库分片策略调整 时区服务 SDK 升级 对账模块时间戳校准这些需要语义理解、跨域知识关联、试错反馈闭环的能力正是六个智能体协同要解决的问题。它不追求全自动上线而是把“从需求到可验证变更”的路径压缩到分钟级把工程师从“救火队员”变成“系统指挥官”。适合谁读如果你正在用 AKS 管理 50 微服务每天被 Terraform apply 失败、Prometheus 告警风暴、Git 分支冲突合并耗掉 40% 时间如果你的团队已用上 GitHub Copilot 但总觉得“聪明但不听话”补全不准、上下文丢失、无法对接内部 API如果你正评估 Isaac Lab、Jupyter Lab 等平台却卡在“如何让 AI 不只做 demo而能进生产”——那么这篇就是为你写的。它不讲大道理只讲我在真实集群里改过的 37 个 ConfigMap、踩过的 12 类权限坑、调优过的 8 个 Copilot 提示工程模板以及为什么最终放弃直接调用 Copilot Chat API转而自建 Gateway 层。2. 整体架构设计与六智能体协同逻辑2.1 为什么必须是 AKS Lab Copilot 三角组合而不是单点优化很多人第一反应是“我直接在 GitHub Actions 里调 Copilot API 不就行了”或者“用 Argo CD OpenAI Function Calling 就够了”。实测下来这两种方案在生产环境都迅速触达天花板。原因不在技术本身而在责任边界模糊和上下文断裂。举个典型场景当 Infra Agent 根据 PR 描述“提升订单服务可用性”自动生成了一段 Azure ARM 模板它需要知道当前 AKS 集群的 node pool SKU、现有 VNet 地址段、Log Analytics 工作区 ID、以及该服务当前的 HPA 配置——这些信息分散在 Azure Portal、Terraform state、K8s Secret、Prometheus metrics 四个地方。如果只是简单调 APIAgent 拿到的只是静态快照且无法感知“刚有人手动扩了 2 个节点但没更新 Terraform”导致生成的模板与实际状态冲突。这就是纯 API 调用的硬伤它没有“环境主权”。而 Lab 层正是为了解决这个问题。我们定义 Lab 的核心契约是每个 Lab 实例 一个带完整上下文快照的、可克隆的、带生命周期管理的工程环境单元。它不是虚拟机镜像也不是 Docker 镜像而是一组 Kubernetes CRDCustom Resource DefinitionLabEnvironment描述基础配置region、node size、network cidrLabContext存储动态采集的实时状态当前 pod 数、CPU load、最近 3 次 deploy 的 commit hashLabToolset声明预装工具链terraform 1.6.5、kubectl 1.28、az cli 2.52。当 Planner Agent 启动一个新任务时它不创建新 Pod而是通过kubectl apply -f lab-task.yaml创建一个LabTaskCRLab Operator 监听到后会自动拉起一个带上述全部上下文注入的 Pod并挂载预设的 secrets 和 configmaps。整个过程毫秒级完成且上下文版本严格锁定——这解决了“状态漂移”问题。AKS 则提供了这个架构的底盘保障。我们不用 EKS 或 GKE核心考量三点一是 Azure AD 与 GitHub Enterprise SSO 的原生集成让 Copilot Agent 的 token 权限继承变得极其干净无需额外 OIDC 配置二是 AKS 的 Virtual Node 支持让突发的代码审查任务如批量生成 test case可以瞬间扩容到 ACI避免抢占生产节点资源三是 Azure Monitor 与 GitHub Copilot 的日志 schema 天然对齐都用activityId,correlationId,operationName字段让后续做智能体行为审计时一条 trace 能串起从 PR 提交 → Copilot 生成 → K8s 部署 → 应用日志的全链路。这不是技术偏好而是生产稳定性倒逼出的选型。2.2 六个智能体的职责划分与数据流设计六个智能体不是拍脑袋定的数字而是根据我们梳理出的 212 个高频 DevOps 任务用 RICE 评分Reach, Impact, Confidence, Effort聚类后得出的最小完备集。它们按“输入-处理-输出”形成闭环但彼此间不是简单的上下游而是存在双向反馈通道和熔断机制。下表列出核心分工与关键约束智能体名称核心职责输入来源输出产物关键约束协同触发条件Planner Agent需求解析、任务分解、优先级排序、风险预判PR 描述、Jira ticket、Slack channel 消息结构化任务清单含依赖关系、SLA 要求、回滚预案必须输出可验证的验收标准AC否则拒绝下发新 PR / 新 ticket 创建Infra AgentIaC 生成、drift 检测、安全合规扫描CIS Azure BenchmarkPlanner 输出、当前 Terraform state、Azure Policy 定义.tf文件 diff、drift report、policy violation list所有生成代码必须通过tflint --enable-ruleterraform_comment_syntax校验Planner 下发 infra 相关子任务Code Agent业务代码生成、重构建议、技术债识别基于 SonarQube APIPlanner 输出、Git diff、代码仓库 AST新增/修改的.py/.go文件、refactor plan、tech debt score生成代码必须覆盖 85% 的单元测试桩由 Test Agent 验证Planner 下发 code 相关子任务Test Agent测试用例生成unit/integration、覆盖率强化、Mock 数据构造Code Agent 输出、OpenAPI spec、数据库 schema_test.py文件、coverage report、mock data JSON所有用例必须能在pytest --maxfail1下稳定通过Code Agent 提交新代码后自动触发Build Agent构建缓存优化、多阶段构建策略选择、镜像安全扫描TrivyGit commit、Dockerfile、build cache 状态Docker image、build log summary、vulnerability report镜像必须满足CRITICAL0, HIGH≤3的漏洞阈值Test Agent 通过后触发Ops Agent日志异常检测LSTM 模型、告警聚合、根因建议基于知识图谱、自助修复脚本生成Prometheus metrics、Loki logs、Service Map告警摘要、root cause hypothesis、repair.sh脚本所有修复脚本必须经过shellcheck -s bash 人工 review 门禁新告警产生且持续 2min 未恢复注意看“协同触发条件”列它不是固定流程Planner→Infra→Code…而是事件驱动。比如当 Ops Agent 发现“订单服务 P95 延迟突增”它不会自己修而是生成一个带 traceId 的IncidentReportCRLab Operator 捕获后自动触发 Planner Agent 启动紧急任务此时 Planner 会跳过常规需求分析直奔“分析该 traceId 对应的 span 数据”并把结论喂给 Infra Agent检查网关配置和 Code Agent检查最近提交的支付逻辑。这种动态编排能力是静态 pipeline 无法实现的。更关键的是熔断设计。每个智能体在启动时都会向 Lab 的healthzendpoint 注册自己的 readiness probe。如果 Infra Agent 连续 3 次生成的 Terraform 无法通过terraform validate它的 probe 会失败Lab Operator 将自动将其从任务队列中摘除并通知 Planner Agent 降级为“人工审核模式”。这保证了系统不会因为某个智能体的误判导致整个流水线雪崩。2.3 为什么放弃 Copilot Chat API坚持自建 Gateway这是项目初期最大的技术分歧点。团队里有同事坚持用官方 Chat API理由是“省事、稳定、有 SLA”。我们花了两周时间做了对比实验用同一份 PR 描述“优化用户登录接口支持微信扫码免密登录”分别走官方 API 和自建 Gateway结果如下上下文长度官方 API 限制 4096 token而一个中等复杂度的微服务其 OpenAPI spec 数据库 schema 当前 JWT 验证逻辑代码就超 3200 token留给 Agent 理解需求的空间只剩 800 token导致它反复要求“请提供更多上下文”工具调用可靠性官方 API 的 function calling 在高并发时5 req/s失败率飙升至 37%错误码全是rate_limit_exceeded且无重试机制审计不可控所有请求经 GitHub 服务器我们无法记录原始 prompt、无法拦截敏感字段如数据库密码、无法做合规脱敏。自建 Gateway 的核心组件只有三个Prompt Router根据任务类型infra/code/test路由到不同提示模板库每个模板预置了角色定义、约束规则、输出格式 schemaJSON Schema并强制注入当前 Lab Context如current_aks_cluster: prod-eastusTool Orchestrator封装了az cli,terraform,kubectl,sonar-scanner等 CLI 工具的标准化调用接口统一处理 auth、timeout、retry、output parsingAudit Logger每条请求生成唯一agent_id记录prompt_hash,tool_call_sequence,output_diff,human_review_status日志直送 Azure Sentinel供 SOC 团队审计。实测下来Gateway 方案将平均任务完成时间从 4.2 分钟降至 1.8 分钟失败率从 22% 降至 0.7%且所有操作 100% 可回溯。这不是为了炫技而是生产环境对“可控性”的刚性要求——你可以接受 AI 犯错但不能接受不知道它为什么错。3. 核心细节解析与实操要点3.1 Lab 环境的 CRD 设计与 Operator 实现Lab 的灵魂在于其 CRD 定义。我们没有用 Operator SDK 的高级封装而是手写了一套极简的 controllerGo 语言800 行因为它只需要做三件事监听 CR 创建、注入上下文、清理资源。以下是LabEnvironmentCR 的核心字段设计每一项都对应一个真实痛点apiVersion: lab.azure.com/v1 kind: LabEnvironment metadata: name: prod-eastus namespace: lab-system spec: # region 和 nodePool 是强约束防止 Agent 错误地生成西海岸资源 azureRegion: eastus nodePool: vmSize: Standard_D8ds_v5 minCount: 3 maxCount: 10 # network 是安全底线必须显式声明避免 Agent 自行创建 public IP vnet: cidr: 10.240.0.0/16 subnets: - name: nodes cidr: 10.240.1.0/24 - name: services cidr: 10.240.2.0/24 # 这里注入的是“可信源”Agent 只能读取这些位置的数据 trustedSources: - type: terraform-state url: https://storage.azure.com/tfstate/prod.tfstate key: prod-eastus - type: prometheus url: https://prometheus.prod.svc.cluster.local queryTimeout: 30s - type: github-repo owner: myorg repo: order-service branch: main关键点在于trustedSources字段。它不是一个配置项而是一个权限栅栏。当 Infra Agent 需要获取当前集群的 autoscaler 配置时它不能直接调kubectl get hpa -n order而是向 Lab Operator 发起一个GET /lab/v1/context?sourceprometheusqueryavg_over_time(kube_hpa_status_current_replicas{namespaceorder}[5m])的请求Operator 校验该查询是否在trustedSources白名单内且返回结果已做过脱敏如隐藏 secret 名称。这从根本上杜绝了“Agent 越权读取其他 namespace 配置”的风险。LabContextCR 则是动态快照的载体。我们用 CronJob 每 5 分钟采集一次关键指标生成如下结构apiVersion: lab.azure.com/v1 kind: LabContext metadata: name: prod-eastus-context-20240615-1430 namespace: lab-system ownerReferences: - apiVersion: lab.azure.com/v1 kind: LabEnvironment name: prod-eastus spec: # 这些字段会被自动注入到每个 Agent Pod 的 ENV 中 environment: prod-eastus timestamp: 2024-06-15T14:30:00Z kubernetes: nodes: 8 pods: 142 cpuUsagePercent: 63.2 terraform: lastApplyTime: 2024-06-14T09:15:22Z driftDetected: false github: lastMergeCommit: a1b2c3d4e5f67890 prQueueLength: 3实操中最大的坑是Context 版本漂移。我们曾遇到过这样的故障Planner Agent 基于prod-eastus-context-20240615-1430启动任务但 Infra Agent 在执行时LabContext已更新为20240615-1435导致它读到的lastApplyTime比 Planner 看到的新从而误判“无需 apply”。解决方案是在LabTaskCR 中强制绑定 context versionapiVersion: lab.azure.com/v1 kind: LabTask metadata: name: infra-update-20240615-1430 spec: # 绑定到特定 context即使新 context 生成此 task 仍用旧版 contextRef: name: prod-eastus-context-20240615-1430 agent: infra input: | {requirement: add redis cache for user profile service}Operator 在创建 Pod 时会把prod-eastus-context-20240615-1430的内容作为 volume mount 进容器并设置LAB_CONTEXT_VERSIONprod-eastus-context-20240615-1430环境变量。这个设计让每个任务拥有确定性的执行环境是 AgenticOps 可靠性的基石。3.2 GitHub Copilot Agent 的提示工程与工具链集成Copilot Agent 的能力上限80% 取决于提示prompt质量20% 取决于工具链封装。我们放弃了通用的“system/user/assistant”三段式采用Role-Constraint-OutputRCO模板结构每个智能体有专属模板库共 47 个且全部版本化管理GitOps。以Infra Agent的核心模板为例简化版# Role You are an Azure Infrastructure as Code expert. You generate production-ready Terraform code for AKS environments. You prioritize security, cost-efficiency, and observability. # Constraint - ONLY use AzureRM provider v3.72.0 and null resource for custom logic. - NEVER generate public IP addresses or open ports to internet unless explicitly required by requirement. - ALWAYS add tags: { created_by: copilot-infra, env: ${LAB_ENVIRONMENT}, managed_by: lab-operator }. - OUTPUT MUST be valid JSON with keys: terraform_code, explanation, security_risk_level (LOW/MEDIUM/HIGH). # Requirement ${INPUT_REQUIREMENT} # Current Context - AKS Cluster: ${LAB_ENVIRONMENT} - VNet CIDR: ${VNET_CIDR} - Current Terraform State Last Apply: ${TF_LAST_APPLY} - Azure Policy Violations: ${POLICY_VIOLATIONS} # Output Format { terraform_code: string containing full .tf content, explanation: concise reasoning in 50 words, security_risk_level: string }这个模板的关键创新点有三处动态变量注入${LAB_ENVIRONMENT}等不是硬编码而是由 Gateway 在 runtime 从LabContext中提取并替换确保每次调用都是上下文感知的安全硬约束NEVER generate public IP这类指令配合后续的tflint校验形成双重保险结构化输出强制要求必须输出 JSON且包含security_risk_level字段这为后续的自动化审批流如 HIGH 风险需人工介入提供了机器可读的依据。工具链集成方面我们没用 Copilot 的内置 CLI而是用 Go 写了一个轻量copilot-toolkit它封装了az tfstate get: 从 Azure Storage 获取指定环境的 tfstate 并解析出 resource graphk8s context inject: 将当前 namespace、service account token、ingress rules 注入到临时 kubeconfiggithub pr diff: 获取 PR 的 raw diff 并提取 changed files line numbers用于 Code Agent 的精准影响分析。这些工具的二进制文件被打包进 Agent 的 base imageghcr.io/myorg/copilot-agent:infra-v1.2并通过ENTRYPOINT [/bin/copilot-toolkit]启动。当 Agent 需要“检查当前 ingress 是否已启用 TLS”它只需执行copilot-toolkit k8s ingress tls-status --name order-ingress --namespace order工具会自动连接集群并返回{enabled: true, cert-manager: true}。这种设计让 Agent 的逻辑极度干净——它只负责“思考”不负责“干活”所有脏活累活都下沉到 toolkit。提示不要试图让 Copilot Agent 直接执行kubectl apply。我们早期这么干过结果 Agent 在生成 YAML 时漏写了spec.template.spec.containers[0].resources.limits.memory导致 Pod OOMKill而它自己还报告“deploy succeeded”。正确做法是 Agent 只生成 YAML由 Build Agent 的kubectl apply --dry-runclient -o json做语法和 schema 校验再由 Ops Agent 的kubectl apply --server-dry-run做服务端校验最后才由独立的 Deployer Job 执行。责任分离才能稳。3.3 六智能体的通信协议与可观测性埋点六个智能体之间不共享内存也不直连数据库它们通过Lab Message BusLMB通信这是一个基于 Redis Streams 的轻量消息中间件非 Kafka因 Kafka 运维成本过高且我们不需要 PB 级吞吐。每个智能体启动时会创建自己的 consumer group订阅/lab/task/{task_id}stream。消息格式强制为 Avro Schema我们用 JSON Schema 做简化版{ schema: 1.0, event_id: a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8, task_id: infra-update-20240615-1430, agent_from: planner, agent_to: infra, type: TASK_ASSIGNMENT, payload: { requirement: add redis cache for user profile service, sla_seconds: 300, rollback_plan: terraform destroy -targetazurerm_redis_cache.profile_cache }, timestamp: 2024-06-15T14:30:00.123Z }关键设计点event_id全局唯一用于全链路追踪task_id绑定到 LabTask CR确保消息与任务生命周期一致agent_from/to显式声明方便做权限控制如 Code Agent 不能直接发消息给 Ops Agent必须经 Plannertype字段是路由关键我们定义了 12 种标准类型TASK_ASSIGNMENT,TASK_RESULT,CONTEXT_UPDATE,HUMAN_INTERVENTION_REQUIRED等避免智能体间随意“聊天”。可观测性不是事后加的而是从第一天就刻在基因里。每个 Agent Pod 启动时会自动注入以下 sidecarotel-collector采集 CPU/memory/network metricslog-forwarder将 stdout/stderr 重定向到 Loki添加agent_name,task_id,event_idlabelstrace-injector在每个 HTTP 请求 header 中注入x-trace-id并与 event_id 对齐。我们在 Grafana 中构建了AgenticOps Dashboard核心视图有三个Task Flow View以task_id为根展示 Planner → Infra → Test → Build 的完整时间线每个环节标出耗时、成功/失败、human review statusAgent Health View显示各 Agent 的 request rate、error rate、p95 latency、context freshness即当前使用的 LabContext ageDrift Heatmap对比“Agent 生成的 Terraform”与“实际 K8s 状态”的差异用红黄绿三色标注 drift severity。最实用的一个技巧当某个任务卡住时我们不再翻 N 个日志文件而是直接在 Grafana 中输入task_idDashboard 会自动聚合所有相关日志、metrics、traces并高亮出第一个 error。实测平均故障定位时间从 22 分钟降至 3.5 分钟。4. 实操过程与核心环节实现4.1 从零搭建 Lab 环境AKS 集群准备与 Lab Operator 部署第一步永远是 AKS 集群的“生产就绪”配置。我们不用az aks create默认参数而是用 ARM template或 Bicep精确控制。以下是必须开启的 7 项配置缺一不可Managed Identity禁用 service principal全部使用 system-assigned managed identity避免密钥轮换灾难Azure RBAC启用--enable-azure-rbac让 K8s RBAC 与 Azure AD 组无缝映射Private Cluster--enable-private-cluster所有 node-to-node 流量走 private link杜绝公网暴露Pod Identity--enable-pod-identity让 Agent Pod 能安全访问 Key Vault、Storage AccountAzure Monitor for Containers--enable-monitoring这是后续做智能体行为分析的数据源Node Pool Taints给 infra node pool 打上roleinfra:NoSchedule确保 Agent Pod 不会调度到业务节点Kube-Proxy Replacement--network-plugin azure --network-policy azure用 Azure CNI 替代 kubenet获得真正的 VNet 集成。集群创建后部署 Lab Operator 的步骤极简# 1. 创建命名空间 kubectl create ns lab-system # 2. 部署 CRD4 个文件 kubectl apply -f https://raw.githubusercontent.com/myorg/lab-crd/main/labenvironment.crd.yaml kubectl apply -f https://raw.githubusercontent.com/myorg/lab-crd/main/labcontext.crd.yaml kubectl apply -f https://raw.githubusercontent.com/myorg/lab-crd/main/labtask.crd.yaml kubectl apply -f https://raw.githubusercontent.com/myorg/lab-crd/main/labtoolset.crd.yaml # 3. 部署 Operator使用我们的 Helm Chart helm repo add lab https://myorg.github.io/lab-helm helm install lab-operator lab/lab-operator \ --namespace lab-system \ --set azure.tenantIdyour-tenant-id \ --set github.appIdyour-github-app-id \ --set copilot.gatewayUrlhttps://copilot-gateway.lab.svc.cluster.localOperator 的核心逻辑在main.go中只有 200 行它监听LabTask创建事件然后从spec.contextRef获取LabContext从spec.agent查找对应的LabToolset定义了镜像、resource request、env vars渲染一个标准 Pod template注入 context 作为 env 和 volume设置ownerReference指向LabTask确保 cleanup 自动化。实测中最大的陷阱是RBAC 权限遗漏。Operator 需要get/list/watch所有 CRD但更重要的是它需要impersonate权限因为 Agent Pod 需要以不同身份访问 Azure如 Infra Agent 用contributor角色Test Agent 用reader角色。我们在clusterrole.yaml中明确添加- apiGroups: [] resources: [serviceaccounts, serviceaccounts/token] verbs: [create, impersonate] - apiGroups: [authentication.k8s.io] resources: [userextras] verbs: [create]没有这一条Agent Pod 会卡在Error from server (Forbidden): unable to impersonate user。这个坑我们踩了两天文档里根本没提。4.2 GitHub Copilot Gateway 的部署与提示模板管理Gateway 是整个系统的“大脑皮层”我们用 RustActix Web编写因其内存安全和高并发特性。部署结构如下Internet → Azure Front Door (WAF) → Gateway Service (ClusterIP) → ├─ Prompt Router (in-process) ├─ Tool Orchestrator (separate process, communicates via Unix socket) └─ Audit Logger (writes to Azure Log Analytics via REST API)Gateway 的核心配置gateway-config.yaml# 模板版本控制指向 Git 仓库 templates: repo: https://github.com/myorg/copilot-templates.git branch: main path: templates # 工具链配置每个 agent 类型对应一个 toolset toolsets: infra: binary: /usr/local/bin/copilot-toolkit args: [az, tfstate, get] code: binary: /usr/local/bin/copilot-toolkit args: [github, pr, diff] # 审计配置 audit: logAnalyticsWorkspaceId: xxx-xxx-xxx retentionDays: 90部署命令# 1. 创建专用 namespace 和 secret kubectl create ns copilot-system kubectl create secret generic copilot-gateway-secrets \ --from-literalgithub-app-private-key$(cat github-app-key.pem) \ --from-literalazure-client-secretyour-azure-client-secret \ -n copilot-system # 2. 部署 GatewayHelm helm install copilot-gateway ./charts/copilot-gateway \ --namespace copilot-system \ --set gateway.configPath/etc/gateway/config.yaml \ --set-file gateway.configSecretgateway-config.yaml提示模板管理是持续迭代的过程。我们建立了严格的 CI/CD 流程所有模板存放在github.com/myorg/copilot-templates仓库的templates/目录每次 PR 提交CI 会运行template-validator工具检查是否有未定义的${VAR}变量Constraint部分是否包含NEVER/ALWAYS等关键词确保安全硬约束Output Format是否符合 JSON Schema通过后自动打 tag如infra-v1.2.3并更新 Gateway 的templates.branch。这个流程让我们在两周内迭代了 19 个 Infra Agent 模板将 Terraform 生成的准确率从 68% 提升到 94%。关键经验不要追求一个万能模板而要为每个高频场景如“添加新微服务”、“扩容数据库”、“配置 WAF 规则”定制专用模板。通用模板的幻觉率永远高于场景化模板。4.3 六智能体的首次协同实战为订单服务添加 Redis 缓存现在让我们走一遍完整的端到端流程。假设产品经理在 Jira 创建了一个 ticket“订单详情页加载慢P95 达 3.2s需接入 Redis 缓存”。Step 1: Planner Agent 启动Jira webhook 触发创建LabTaskCRagent: plannerPlanner Agent 启动读取 ticket 描述、关联的LabContext发现当前订单服务 QPS 为 1200DB CPU 82%它生成任务清单{ subtasks: [ { id: infra-redis-provision, agent: infra, requirement: provision azure redis cache with 2GB memory, enable SSL, configure firewall to allow only order-service subnet, sla: 300s }, { id: code-redis-integration, agent: code, requirement: modify order-service to use redis for /order/{id} GET, add cache invalidation on POST /order, sla: 600s } ] }Step 2: Infra Agent 执行接收infra-redis-provision任务调用copilot-toolkit az redis create传入 context 中的vnet.cidr和subnets.services.cidr生成 Terraformresource azurerm_redis_cache order_cache { name order-cache-prod location East US resource_group_name rg-prod-eastus capacity 2 family C sku_name Standard enable_non_ssl_port false minimum_tls_version 1.2 redis_configuration { maxmemory_reserved 2 maxmemory_delta 2 maxmemory_policy allkeys-lru } }tflint校验通过terraform apply执行耗时 82s。Step 3: Code Agent 接入接收code-redis-integration任务调用copilot-toolkit github pr diff分析当前代码定位到order-service/handler/order.go生成代码修改// 新增 redis client 初始化 var redisClient *redis.Client func initRedis() { redisClient redis.NewClient(redis.Options{ Addr: order-cache-prod.redis.cache.windows.net: