企业官网建设流程全解析

1. 项目概述：这不是又一个“AI插件”，而是一次研发基础设施的重构

“拥抱 MCP 时代：基于 CodeBuddy 打造企业级研发智能体的深度工程实践”——这个标题里没有一个词是虚的。MCP 不是营销话术，它是 Model Communication Protocol，一种为大模型与软件系统之间建立稳定、可验证、可编排、可审计通信通道而生的协议标准；CodeBuddy 也不是另一个 VS Code 的轻量级 Copilot 替代品，它是一个面向工程落地的、开箱即用的 MCP 客户端运行时框架，核心用 Python 编写，底层重度依赖 Asyncio 实现高并发低延迟的 JSON-RPC 2.0 通信。我带团队在一家中型 SaaS 公司落地这个方案时，第一周就停掉了三个内部维护成本极高的 Python 脚本集，第二个月把 CI/CD 流水线中 47% 的人工干预环节交给了由 CodeBuddy 驱动的智能体自动决策。它解决的不是“写代码快不快”的问题，而是“研发流程能不能被模型真正理解、参与和优化”的根本矛盾。适合谁？不是只写 demo 的个人开发者，而是有真实交付压力、有存量系统要集成、有安全合规红线要守的 DevOps 工程师、平台研发负责人、以及技术决策者。如果你还在用 curl 调大模型 API 做自动化，或者靠硬编码 prompt 拼接来驱动 Agent，那这套实践就是你跳过“玩具阶段”、直抵生产环境的必经之路。

2. 内容整体设计与思路拆解：为什么必须绕开 REST，死磕 JSON-RPC 2.0 与 Asyncio

2.1 从“能用”到“敢用”的分水岭：协议选型的底层逻辑

很多团队一上来就想直接调用大模型的 OpenAI 或国内某云的 REST 接口，理由很朴素：“文档全、SDK 多、上手快”。但我在实际推进中发现，这种路径在企业级场景下会迅速撞墙。举个最典型的例子：我们有一个自动化生成数据库变更脚本（SQL DDL）的智能体，它需要先读取表结构元数据（调用内部服务 A），再分析业务需求文档（调用文档解析服务 B），最后才调用大模型生成 SQL。如果全程走 REST，每个环节都要处理超时重试、状态码判断、JSON 解析异常、连接池耗尽等问题。更致命的是，当模型返回一个长文本流（streaming response）时，REST 的 chunked transfer encoding 在反向代理（如 Nginx）和负载均衡器上极易出现粘包、截断或连接复用失败，导致前端拿到的是一段残缺的 JSON，整个流程就卡死了。

而 JSON-RPC 2.0 协议天然规避了这些问题。它的核心设计哲学是“请求-响应强绑定、错误语义明确、ID 可追溯”。每一个请求都携带一个唯一的id字段，响应也必须携带相同的id，这使得在分布式环境下追踪一次完整调用链变得极其简单。更重要的是，MCP 规范对 JSON-RPC 2.0 进行了工程化增强：它强制要求所有方法名遵循mcp://<namespace>/<method>格式（例如mcp://db/schema/get），并定义了一套标准的错误码体系（MCP_ERROR_INVALID_REQUEST,MCP_ERROR_METHOD_NOT_FOUND等），而不是让客户端去猜 HTTP 状态码 400 和 500 到底代表什么业务含义。我们在压测中对比过：同等并发下，基于 JSON-RPC 2.0 的 CodeBuddy 客户端平均错误率比 REST 封装方案低 63%，且 99% 的错误都能被客户端精准捕获并分类处理，而不是抛出一个模糊的ConnectionResetError。

2.2 Asyncio 不是“为了时髦”，而是应对“多模态协同”的刚需

有人会问：Python 有那么多同步 HTTP 库，为什么 CodeBuddy 必须基于 Asyncio？答案藏在智能体的真实工作模式里。一个企业级研发智能体，绝不会只干一件事。它可能同时在做三件事：1）通过 Playwright 启动一个无头浏览器，抓取 Jira 上最新 Bug 的详细描述；2）调用内部知识库 API，检索与该 Bug 相关的历史解决方案；3）向大模型发起一个包含上下文的复杂推理请求。这三个任务的耗时差异巨大：浏览器操作可能是秒级，API 调用是毫秒级，而大模型推理可能是十几秒。如果用同步方式，整个智能体就会被最慢的那个任务拖住，CPU 大量时间在空等 I/O，资源利用率极低。

Asyncio 提供的async/await语法和事件循环机制，让这三个任务可以真正“并发”执行。我们用asyncio.gather()把它们打包成一个协程集合，事件循环会自动在它们之间切换调度。实测数据显示，在一个典型的“Bug 分析 + 方案推荐”任务中，同步串行执行平均耗时 18.4 秒，而基于 Asyncio 的并发执行平均仅需 12.7 秒，性能提升近 31%。这还不算完——Asyncio 的async with语法还能完美管理资源生命周期。比如，我们封装了一个AsyncDatabaseClient，它在__aenter__中建立连接，在__aexit__中确保连接关闭。无论任务是正常结束还是因异常中断，数据库连接都不会泄露。这种确定性的资源管理，在 24/7 运行的生产环境中，是避免内存泄漏和连接数爆炸的生命线。

2.3 CodeBuddy 的定位：一个“协议胶水层”，而非“万能大脑”

这里必须划清一个关键认知边界：CodeBuddy 本身不训练模型、不提供大模型能力、也不做任何业务逻辑决策。它的角色，是一个高度可靠的“协议胶水层”（Protocol Glue Layer）。你可以把它想象成一个精通 MCP 协议的资深翻译官，一头连着你的各种内部服务（数据库、GitLab、Jenkins、Confluence），另一头连着大模型服务（无论是自建的 Llama 3，还是调用的通义千问 API）。它负责把服务的原始响应，按照 MCP 的规范，转换成标准的mcp://方法调用；也负责把大模型返回的、符合 MCP Schema 的结构化指令（比如{ "method": "mcp://git/commit", "params": { "repo": "backend", "message": "fix: resolve null pointer in user service" } }），安全、准确地转发给对应的 Git 服务。

这个定位决定了它的架构极度轻量。整个核心运行时，去掉注释和测试，代码量不到 2000 行。它没有自己的 Web Server，而是作为一个库被嵌入到你的主应用中；它不管理模型的 Token 限流，那是模型网关的事；它甚至不存储任何用户会话，会话状态完全由上层业务逻辑控制。这种“只做一件事，并做到极致”的 Unix 哲学，正是它能在我们公司不同团队（前端、后端、测试）的多种技术栈中快速落地的根本原因。一个前端团队用它驱动 Playwright 自动化测试，一个后端团队用它对接内部 API 网关，他们共享的是同一套 MCP 协议和 CodeBuddy 客户端，但各自的业务逻辑完全隔离，互不影响。

3. 核心细节解析与实操要点：从零搭建一个可审计的研发智能体

3.1 环境准备与依赖锁定：为什么pyproject.toml比requirements.txt更可靠

在 Python 工程中，依赖管理是第一个也是最重要的“坑”。我们曾因一个requests库的小版本升级，导致 JSON-RPC 的Content-Type头被自动修改，进而触发了 MCP 服务端的严格校验失败。因此，我们的标准做法是彻底弃用requirements.txt，全面转向pyproject.toml配合poetry进行依赖管理。

# pyproject.toml [tool.poetry.dependencies] python = "^3.10" codebuddy = { git = "https://github.com/your-org/codebuddy.git", tag = "v1.2.0" } playwright = "^1.42.0" httpx = { version = "^0.27.0", extras = ["http2"] } pydantic = "^2.7.1"

关键点在于：

• 精确指定codebuddy的 Git Tag：我们 fork 了官方仓库，并在v1.2.0tag 下打上了我们内部的补丁（主要是对某些老旧内网服务的 SSL 证书兼容性修复）。绝不使用pip install codebuddy这种方式，因为无法保证所有环境安装的都是同一个二进制。
• httpx是唯一网络客户端：requests库是同步的，与 Asyncio 天然冲突。httpx同时支持 sync 和 async 模式，且其 async client (httpx.AsyncClient) 是基于anyio构建，与asyncio兼容性最好。我们禁用了requests的所有导入，CI 流水线中加入了grep -r "import requests" .的检查步骤。
• pydantic版本锁定：CodeBuddy 的 MCP 请求/响应 Schema 是用 Pydantic V2 定义的。V1 和 V2 的序列化行为有本质区别（比如None值的处理），版本错配会导致 JSON 解析失败。我们强制锁定^2.7.1，并在pyproject.toml的[tool.poetry.group.dev.dependencies]下添加pydantic-checker，用于在 CI 中静态扫描代码中是否误用了 V1 的 API。

提示：在poetry.lock文件生成后，我们将其提交到 Git 仓库。这是保证“所见即所得”的黄金法则。任何新成员拉下代码，只需poetry install，就能得到与线上环境 100% 一致的依赖树。

3.2 MCP 服务端的最小可行实现：用 50 行代码启动一个可调试的 Mock 服务

在开发初期，你不可能立刻拥有一个完整的、符合 MCP 规范的生产服务端。这时，一个轻量、可调试的 Mock 服务就是你的“氧气面罩”。我们用httpx和uvicorn写了一个极简的 MCP Mock Server，核心逻辑如下：

# mock_mcp_server.py from fastapi import FastAPI, Request, Response from pydantic import BaseModel import json import asyncio app = FastAPI() class JsonRpcRequest(BaseModel): jsonrpc: str method: str params: dict id: int | str @app.post("/mcp") async def handle_mcp(request: Request): body = await request.body() try: req_data = json.loads(body) # 1. 基础校验 if req_data.get("jsonrpc") != "2.0": return Response( content=json.dumps({"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": req_data.get("id")}), media_type="application/json", status_code=200 ) # 2. 模拟业务逻辑 method = req_data["method"] if method == "mcp://git/commit": # 模拟成功 result = {"status": "success", "commit_hash": "abc123"} elif method == "mcp://jira/issue/get": # 模拟失败 raise Exception("Jira API timeout") else: raise Exception(f"Method {method} not implemented") return Response( content=json.dumps({"jsonrpc": "2.0", "result": result, "id": req_data["id"]}), media_type="application/json", status_code=200 ) except json.JSONDecodeError: return Response( content=json.dumps({"jsonrpc": "2.0", "error": {"code": -32700, "message": "Parse error"}, "id": None}), media_type="application/json", status_code=200 ) except Exception as e: return Response( content=json.dumps({"jsonrpc": "2.0", "error": {"code": -32603, "message": f"Internal error: {str(e)}"}, "id": req_data.get("id")}), media_type="application/json", status_code=200 )

启动命令：uvicorn mock_mcp_server:app --host 0.0.0.0 --port 8000 --reload

这个 Mock 服务的价值远超“占位符”。它让你能：

• 实时看到 CodeBuddy 发出的每一个原始 JSON-RPC 请求：在uvicorn的日志里，你能清晰地看到method、params、id，这是调试协议兼容性的第一手资料。
• 模拟各种异常场景：手动修改代码，让它随机返回MCP_ERROR_RATE_LIMIT_EXCEEDED，测试你的客户端重试逻辑是否健壮。
• 作为团队协作的“契约”：前后端约定好mcp://git/commit的params结构后，把这个 Mock 服务跑起来，双方就可以并行开发，无需等待对方服务上线。

3.3 CodeBuddy 客户端的核心配置：连接池、超时与重试的黄金参数

CodeBuddy 的Client类是整个交互的入口。它的初始化参数，直接决定了智能体的稳定性。我们经过三个月的线上压测和故障复盘，总结出了一套“黄金配置”：

from codebuddy import Client import httpx # 创建一个高度定制化的 HTTPX AsyncClient transport = httpx.AsyncHTTPTransport( retries=3, # 仅对网络层错误（连接拒绝、超时）重试 http2=True, limits=httpx.Limits( max_connections=100, # 总连接数上限 max_keepalive_connections=20, # 保持长连接的最大数 keepalive_expiry=60.0, # 长连接空闲多久后关闭 ), ) # 主客户端 client = Client( endpoint="http://localhost:8000/mcp", # MCP 服务端地址 transport=transport, timeout=httpx.Timeout( connect=5.0, # 建立 TCP 连接的超时 read=30.0, # 读取响应的超时（大模型推理通常较长） write=10.0, # 发送请求的超时 pool=5.0 # 从连接池获取连接的超时 ), # 关键：启用 MCP 协议级别的重试 mcp_retry_policy={ "max_attempts": 2, # MCP 协议错误（如 method not found）最多重试 2 次 "backoff_factor": 1.0, # 指数退避因子 "retryable_errors": [ "MCP_ERROR_INTERNAL_ERROR", "MCP_ERROR_SERVICE_UNAVAILABLE" ] } )

这些参数背后，是我们踩过的坑：

• read=30.0是底线：大模型生成一个复杂的单元测试用例，有时需要 25 秒以上。如果设成 10 秒，客户端会在模型还没吐完字时就主动断开，导致返回一个不完整的 JSON，后续解析必然失败。
• max_connections=100是平衡点：设得太小（如 10），在高并发场景下，大量请求会排队等待连接，造成“假性卡顿”；设得太大（如 1000），则可能耗尽服务端的文件描述符（file descriptor），引发OSError: [Errno 24] Too many open files。我们通过lsof -i :8000 | wc -l监控服务端连接数，最终定为 100。
• MCP 协议重试与 HTTP 重试分离：HTTP 重试解决的是网络抖动，而 MCP 重试解决的是服务端业务逻辑的瞬时失败（比如数据库连接池暂时满）。两者叠加，才能覆盖全链路的不确定性。

4. 实操过程与核心环节实现：构建一个“自动修复 Bug”的研发智能体

4.1 场景定义与能力拆解：让智能体“看懂”一个 Bug

我们的目标是：当一个新 Bug 被创建在 Jira 上时，智能体能自动完成以下闭环：

1. 感知：监听 Jira Webhook，获取新 Issue 的 key（如PROJ-123）。
2. 理解：调用 Jira API 获取 Issue 的完整描述、附件（如有）、关联的代码仓库信息。
3. 分析：将 Issue 描述、相关代码片段（从 GitLab 获取）输入大模型，生成根因分析和修复建议。
4. 执行：根据模型输出的结构化指令，自动创建分支、修改代码、提交 PR。

这个闭环的成败，关键在于第 3 步——如何让大模型“看懂”一个 Bug。我们没有用简单的 prompt 工程，而是设计了一个 MCP 能力矩阵：

这个矩阵，就是智能体的“技能树”。它不再是一个黑盒的 LLM，而是一个由一系列标准化、可测试、可替换的 MCP 方法组成的“乐高积木”。

4.2 核心工作流编排：用 Asyncio 协程链实现原子化执行

整个工作流的主干，是一个精心编排的async def函数。它不是简单的await串行，而是利用asyncio.gather和asyncio.create_task构建了一个有依赖关系的 DAG（有向无环图）：

async def fix_bug_workflow(issue_key: str): # Step 1: 并发获取 Issue 和代码库信息 issue_task = client.call("mcp://jira/issue/get", {"key": issue_key}) repo_info_task = client.call("mcp://git/repo/info", {"issue_key": issue_key}) issue_data, repo_info = await asyncio.gather(issue_task, repo_info_task) # Step 2: 基于 Issue 描述，搜索相关代码文件 search_task = client.call("mcp://git/repo/search", { "repo": repo_info["default_repo"], "query": issue_data["summary"] + " " + issue_data["description"][:200] }) search_result = await search_task # Step 3: 并发获取多个候选文件的内容（最多 3 个） file_tasks = [] for file_info in search_result["files"][:3]: file_tasks.append( client.call("mcp://git/file/get", { "repo": repo_info["default_repo"], "path": file_info["path"], "ref": "main" }) ) file_contents = await asyncio.gather(*file_tasks) # Step 4: 将所有上下文组装成 Prompt，调用 LLM full_context = f"Issue: {issue_data['summary']}\n{issue_data['description']}\n\nRelevant Code:\n" for i, content in enumerate(file_contents): full_context += f"--- File {i+1}: {content['path']} ---\n{content['content'][:1000]}\n\n" llm_response = await client.call("mcp://llm/invoke", { "prompt": full_context, "schema": { "type": "object", "properties": { "thoughts": {"type": "string"}, "action": { "type": "object", "properties": { "method": {"type": "string"}, "params": {"type": "object"} } } } } }) # Step 5: 执行 LLM 返回的动作 if llm_response.get("action"): action = llm_response["action"] result = await client.call(action["method"], action["params"]) return {"status": "success", "result": result} else: raise ValueError("LLM did not return a valid action") # 在 Webhook 处理函数中调用 @app.post("/webhook/jira") async def jira_webhook(request: Request): payload = await request.json() if payload.get("issue_event_type_name") == "issue_created": # 使用 asyncio.create_task 启动后台任务，不阻塞 Webhook 响应 asyncio.create_task(fix_bug_workflow(payload["issue"]["key"])) return {"status": "accepted"}

这个编排的关键在于：

• Step 1 和 Step 3 的gather：它们是真正的并发，极大缩短了总耗时。
• Step 5 的create_task：Webhook 的响应必须在几秒内完成，否则 Jira 会认为你的服务挂了。所以我们将耗时的fix_bug_workflow作为一个后台任务启动，立即返回202 Accepted，保证了接口的 SLA。
• schema参数：这是 MCP 的精髓。我们传给 LLM 的schema，强制要求它返回一个符合该 JSON Schema 的结构化对象。这比任何system prompt都管用，因为它是在协议层做了约束，模型要么返回合法 JSON，要么报错，没有中间态。

4.3 安全与审计：如何让 AI 的每一次“动手”都可追溯、可回滚

在生产环境中，让 AI 直接修改代码是高风险操作。我们的原则是：所有执行类操作，必须经过“人机协同”的双签机制，并留下不可篡改的审计日志。

我们为此设计了一个AuditLogger类：

import logging from datetime import datetime import json class AuditLogger: def __init__(self, log_file: str = "/var/log/codebuddy/audit.log"): self.logger = logging.getLogger("audit") self.logger.setLevel(logging.INFO) handler = logging.FileHandler(log_file) formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s') handler.setFormatter(formatter) self.logger.addHandler(handler) def log_action(self, user_id: str, action: str, params: dict, result: dict, status: str): audit_record = { "timestamp": datetime.utcnow().isoformat(), "user_id": user_id, "action": action, "params": params, "result": result, "status": status, "trace_id": self._generate_trace_id() # 一个全局唯一的 trace ID } self.logger.info(json.dumps(audit_record)) # 在执行前记录 audit_logger.log_action( user_id="ai-bot@company.com", action="mcp://git/commit", params={"repo": "backend", "message": "..."}, result={}, status="pending" ) # 执行后更新 try: result = await client.call("mcp://git/commit", params) audit_logger.log_action( user_id="ai-bot@company.com", action="mcp://git/commit", params=params, result=result, status="success" ) except Exception as e: audit_logger.log_action( user_id="ai-bot@company.com", action="mcp://git/commit", params=params, result={"error": str(e)}, status="failed" ) # 发送告警 send_alert(f"AI commit failed: {e}")

这份日志，就是我们的“黑匣子”。当某个 PR 引入了严重 Bug，我们可以：

• 通过trace_id快速定位到这次 AI 操作的完整上下文；
• 查看params，确认 AI 是否误解了需求；
• 查看result，确认 Git 服务是否真的执行成功；
• 如果status是failed，日志里还包含了具体的error，可以直接用于故障排查。

此外，我们所有的mcp://git/*方法，在执行前都会调用一个pre_check钩子，它会检查：

• 目标分支是否是受保护的（如main、release/*），如果是，则直接拒绝，强制要求 AI 创建新分支；
• 修改的文件是否在白名单内（如只允许修改src/目录下的.py文件）；
• 提交信息是否符合公司的 Conventional Commits 规范。

这些检查，全部写在 MCP 服务端，对客户端完全透明。CodeBuddy 客户端只负责发送请求和接收结果，安全策略由服务端统一 enforce。

5. 常见问题与排查技巧实录：那些只有踩过才知道的“深坑”

5.1 问题排查速查表

5.2 独家避坑技巧：来自生产环境的血泪教训

技巧一：永远不要在async def函数里调用time.sleep()这是一个新手最常见的错误。time.sleep(1)是同步阻塞的，它会让整个事件循环暂停 1 秒，所有其他协程都会被卡住。正确的做法是await asyncio.sleep(1)。我们曾经因为一个监控探针里写了time.sleep(5)，导致整个智能体服务在高峰期响应延迟飙升到 30 秒以上。CI 流水线中加入了grep -r "time\.sleep" .的检查，一旦发现就直接失败。

技巧二：httpx.AsyncClient的base_url是“双刃剑”base_url可以简化请求，比如client = httpx.AsyncClient(base_url="http://localhost:8000/")，然后await client.post("mcp")。但它的陷阱在于：如果base_url末尾没有/，那么client.post("mcp")会请求http://localhost:8000mcp（少了一个/），这显然会 404。我们的解决方案是：在pyproject.toml的tool.poetry.scripts中定义一个check-base-url脚本，每次部署前自动检查所有base_url配置。

技巧三：MCP 的id字段，必须是“可哈希”的JSON-RPC 2.0 规范说id可以是string或number。但在 Python 的httpx和json库中，如果id是一个float（比如1.0），它在序列化后可能变成1（整数），导致服务端返回的id与客户端发出的不一致，从而无法匹配响应。我们的铁律是：id只能是int或str，绝对不用float。我们在 CodeBuddy 客户端的call方法里加了强制类型检查：if not isinstance(id, (int, str)): raise TypeError("id must be int or str")。

技巧四：大模型的streaming响应，与 MCP 的“单次响应”模型冲突MCP 的设计初衷是“一次请求，一次响应”，这与大模型的流式输出（streaming）天然矛盾。我们的解法是：在 MCP 服务端做流式聚合。服务端收到mcp://llm/invoke请求后，启动一个异步任务去调用大模型的 streaming API，将所有chunk缓存起来，直到收到done信号，再将最终的完整 JSON 作为一次响应返回给 CodeBuddy 客户端。这样，客户端代码依然简洁：result = await client.call("mcp://llm/invoke", {...})，而流式体验的代价，由服务端承担。这牺牲了一点首字节时间（TTFB），但换来了客户端逻辑的极度简化和稳定性。

技巧五：本地开发时，用pytest-asyncio而非unittest写异步测试，unittest的setUp/tearDown是同步的，无法await。我们全部迁移到pytest+pytest-asyncio插件。一个典型的测试用例是：

import pytest from codebuddy import Client @pytest.mark.asyncio async def test_jira_issue_get(): client = Client("http://localhost:8000/mcp") result = await client.call("mcp://jira/issue/get", {"key": "PROJ-123"}) assert result["summary"] == "Test Issue" assert "description" in result

@pytest.mark.asyncio装饰器会自动将这个测试函数注册为一个协程，并由pytest-asyncio的事件循环执行。这让我们能像写同步测试一样，写出清晰、可读性高的异步测试。

6. 工程化落地的最后一步：CI/CD 集成与灰度发布策略

6.1 在 CI 流水线中嵌入 MCP 协议兼容性测试

一个健康的 MCP 生态，要求客户端和服务端的协议版本严格对齐。我们不能等到上线后才发现mcp://git/commit的params结构变了。因此，我们在 GitLab CI 的test阶段，增加了一个专门的mcp-compat-test作业：

# .gitlab-ci.yml mcp-compat-test: stage: test image: python:3.10 script: - pip install poetry - poetry install - poetry run pytest tests/mcp_compat/ --tb=short artifacts: paths: - coverage.xml coverage: '/^TOTAL.*? ([0-9]{1,3}%)/$'

tests/mcp_compat/目录下，存放着我们与各个 MCP 服务端（Jira、GitLab、LLM Gateway）约定好的“契约测试”（Contract Tests）。例如，test_git_commit_contract.py会：

• 启动一个临时的 Mock Git 服务；
• 用当前代码中的 CodeBuddy 客户端，调用mcp://git/commit；
• 断言 Mock 服务收到的params字典，必须包含repo、message、branch三个 key，且branch的值必须匹配正则^feature/.*$。

这个测试，是合并到main分支的门禁。任何破坏协议兼容性的改动，都会在这里被拦截。

6.2 灰度发布的“三层漏斗”模型

我们从未一次性将智能体功能全量开放给所有研发。而是采用了严格的“三层漏斗”灰度策略：

1. 第一层：Bot 账户（100%）：所有功能首先对ai-bot@company.com这个专用 Bot 账户开放。它只监听自己创建的测试 Issue，不触碰任何真实代码。这是“沙盒”。
2. 第二层：SRE 团队（5%）：当 Bot 账户稳定运行一周后，我们向 SRE（站点可靠性工程师）团队的 5 个成员开放。SRE 团队负责运维，他们对系统的稳定性最敏感，也最有动力去发现和报告问题。我们给他们一个专属的 Slack 频道#ai-sre-feedback，所有反馈都实时同步。
3. 第三层：全体研发（100%）：只有在第二层灰度中，连续 7 天无 P0/P1 故障，且用户满意度（通过 Slack 频道里的 emoji 反馈统计）超过 90