企业官网建设流程全解析

1. 项目概述：为什么“跑得起来”只是万里长征第一步

“开源雷达周刊，Agent 跑得起来，不等于管得住”——这个标题一出来，我就在好几个技术群看到有人截图转发，配文是“太真实了”。它精准戳中了当前AI工程落地中最隐蔽、也最危险的一个认知盲区：我们花了大量精力让一个Agent在本地demo里流畅调用天气API、解析PDF、生成周报，甚至能连上数据库查数据；但只要把它丢进真实业务流里跑三天，问题就不是“能不能动”，而是“动得对不对”“动得稳不稳”“动得有没有数”。这里的“管得住”，不是指权限管控那种行政意义上的管理，而是指可观测、可干预、可回溯、可审计、可降级这五项硬能力。它背后对应的是生产环境里最基础的SRE（站点可靠性工程）思维，而绝大多数开源Agent项目，从设计第一天起就没把这五条写进需求清单。

我参与过三个不同规模的Agent落地项目，最小的是某高校实验室的科研助手，最大的是某金融后台的自动化报告生成系统。它们无一例外，在第一版上线后都遭遇了同一种“静默崩塌”：Agent没报错，日志里全是200，但生成的周报里关键数字被四舍五入错了两位；或者它在凌晨三点自动重试失败任务时，把同一份合同发给了五个不同部门；最离谱的一次，是它根据模糊指令“整理上月所有客户反馈”，把三年前归档的投诉邮件也翻了出来，还按时间倒序塞进了当周简报。这些都不是代码bug，而是“失控”——系统在无人监督的状态下，以符合逻辑的方式，做出了完全违背业务意图的行为。所以这篇内容，不讲怎么搭一个酷炫的Agent链，也不讲LangChain和LlamaIndex哪个更好用，就专注拆解“管得住”这三个字到底要落在哪几块砖上：监控埋点怎么设才不漏关键路径，人工干预的入口藏在哪才不耽误事，历史轨迹怎么存才能秒级定位问题源头，审计日志要记到什么颗粒度才算合规，以及——当一切开始滑向不可控时，那个一键熔断的开关，你真的测试过它吗？适合谁看？如果你正在用开源Agent框架搭建内部工具、客服机器人或自动化流程，哪怕只是个人开发者想把GPT-4接入自己的笔记系统，只要你的Agent要“持续运行”，而不是“点一下、出个结果、关掉完事”，那这篇就是为你写的。

2. 核心设计思路：从“功能正确”到“行为可信”的范式迁移

2.1 为什么传统软件工程方法在Agent场景下会失效

要理解“管得住”的设计逻辑，得先看清它和传统Web服务、微服务的根本差异。一个REST API，它的输入输出是强契约的：你传JSON，它返JSON，字段类型、必填项、错误码都有OpenAPI明确定义。而一个Agent的核心工作流，本质是非确定性决策链。它接收自然语言指令，调用多个工具（可能包括搜索、计算、调用外部API、读写文件），每一步的执行结果又会影响下一步的决策。这个链条里没有固定的“接口契约”，只有LLM基于上下文的概率性判断。这就导致三个致命问题：

第一，路径不可穷举。你无法像测试一个登录接口那样，穷举所有用户名密码组合。Agent的执行路径取决于用户提问的措辞、历史对话状态、工具返回的实时数据，甚至模型温度参数的微小变化。我在某次压测中发现，同样问“帮我总结Q3销售数据”，当把问题改成“Q3卖得最好的产品是什么”，Agent会跳过数据聚合步骤，直接调用BI系统的TopN查询接口——这个分支，我们在设计阶段根本没画进流程图。

第二，状态不可见。传统服务里，你可以通过数据库查订单状态、通过Redis看缓存命中率、通过Prometheus看QPS。但Agent的“决策状态”是什么？是它当前相信的用户意图？是它对某个工具返回结果的置信度？还是它在多步推理中积累的中间假设？这些都没有标准存储位置，更不会自动上报。我们曾遇到一个案例：Agent反复给用户推荐同一款已下架产品，排查三天才发现，它在第一步搜索时就把“库存为0”误读为“库存充足”，这个错误判断像幽灵一样贯穿了后续所有步骤，但没有任何日志记录它“为什么这么认为”。

第三，失败不可分类。传统错误有明确code：401 Unauthorized, 503 Service Unavailable。Agent的失败是渐变的：可能是工具调用超时（硬失败），也可能是返回数据格式错乱导致LLM解析失败（软失败），还可能是LLM生成了语法正确但事实错误的回答（幻觉失败）。这三类失败的处理方式天差地别——超时要重试，格式错乱要清洗，幻觉则需要人工复核。但开源框架默认只给你一个笼统的“ExecutionError”，就像医生只告诉你“身体不舒服”，却不分是感冒、骨折还是肿瘤。

所以，“管得住”的设计，本质是一场范式迁移：从关注“功能是否实现”，转向关注“行为是否可信”。它要求我们在架构层面就预设Agent是一个会思考、会犯错、需要被监护的数字同事，而不是一个只会执行命令的机械臂。

2.2 “可观测性”不是加几个Metrics，而是重建数据采集坐标系

很多人以为给Agent加个Prometheus exporter，再在关键函数里打几行log，就算可观测了。这是最大的误区。真正的可观测性，必须覆盖Agent决策链的三个核心维度：输入层、决策层、输出层，且每个维度的数据必须能相互关联、交叉验证。

• 输入层：不仅要记录原始用户指令（text），更要捕获指令的元信息。比如，这条指令来自哪个渠道（Web表单/Slack bot/Email）、触发时间戳（精确到毫秒）、用户身份标识（脱敏后的ID）、会话上下文ID（用于串联多轮对话）、以及最重要的——指令的语义指纹。我们用一个轻量级的Sentence-BERT模型对指令做向量化，存入向量库。这样当某类问题频繁出错时，不用翻日志大海捞针，直接用异常样本去相似度检索，就能快速定位是“价格相关提问”还是“时效性提问”这个语义簇出了问题。

• 决策层：这是最难也最关键的。我们放弃了在LLM调用处简单打log的方案，转而采用结构化决策快照（Decision Snapshot）。每次Agent做出关键决策（如选择调用哪个工具、决定是否需要追问用户、判定任务是否完成），就生成一个JSON快照，包含：决策依据（引用了哪些上下文片段）、备选方案（LLM生成的其他可能性）、置信度分数（由另一个小型分类器评估）、以及决策耗时。这些快照不走常规日志管道，而是写入专用的ClickHouse表，因为它的高吞吐和实时分析能力，能支撑我们做“决策健康度”实时看板——比如监控“置信度低于0.6的决策占比”，一旦超过阈值就自动告警。

• 输出层：不能只存最终结果。我们强制要求所有Agent输出必须经过一个输出校验网关（Output Validation Gateway）。它不修改内容，只做三件事：1）用正则和规则引擎检查关键字段（如金额、日期、邮箱）的格式合法性；2）调用轻量级事实核查模型（比如针对金融数据，用FinBERT判断数值是否与上下文矛盾）；3）生成输出指纹（SHA256），并与输入指纹、决策快照ID绑定存储。这样，当用户投诉“周报里销售额写错了”，运维人员30秒内就能从输入指纹反查到是哪次调用、哪个决策节点、哪条工具返回数据被误读。

这套设计的代价是增加了约15%的平均响应延迟，但换来的是问题定位时间从小时级降到秒级。某次线上事故中，我们从收到用户反馈，到定位到是天气API返回的“体感温度”字段名变更导致解析错误，全程只用了47秒——而传统方式，光日志grep就得花二十分钟。

2.3 “可干预性”不是加个Admin后台，而是设计人机协作的自然接口

很多团队做的“人工审核开关”，就是一个后台页面，上面列着待审任务，管理员点“通过”或“驳回”。这在低频场景下可行，但在高频Agent场景里，它制造了新的瓶颈：管理员成了新的单点故障。我们见过最夸张的案例，一个电商客服Agent每天处理8000+咨询，人工审核队列峰值积压到1200条，审核员盯着屏幕看“是否需要转人工”按钮看了整整两天，最后靠写脚本批量放行才救回来。

真正的可干预性，必须嵌入到Agent的工作流本身，成为它决策逻辑的一部分。我们的方案叫动态干预策略（Dynamic Intervention Policy），它有三个层级：

• L1 自动干预：基于预设规则，Agent自己触发。比如，当检测到用户指令包含“紧急”“立刻”“马上”等关键词，且当前负载高于阈值时，Agent会自动跳过耗时长的工具链，直接调用缓存中的模板化应答，并在回复末尾标注“【已启用极速模式】”。这个策略不需要人参与，但所有动作都会记录在决策快照里，供事后审计。

• L2 协作干预：当Agent对某个决策置信度低于阈值（如0.4），它不会直接报错，而是生成一个结构化追问卡片（Structured Clarification Card），推送给用户。这张卡片不是问“您想表达什么？”，而是给出2-3个具体选项：“A. 您想了解XX产品的最新价格？B. 您想查询XX产品的历史价格走势？C. 您想对比XX与YY两款产品的价格？”——选项背后是Agent对用户意图的三种概率性解读。用户点选后，Agent立即基于新信息继续执行。这既降低了幻觉风险，又把“澄清成本”从管理员转移到了用户端，且整个过程对用户透明、无感。

• L3 专家接管：这才是传统意义上的“人工审核”。但它被严格限制在L1和L2都无法解决的场景，比如涉及法律条款解释、大额资金操作确认。此时，Agent会冻结当前会话，生成一个接管请求包（Takeover Request Package），包含：完整对话历史（脱敏）、所有决策快照、工具调用原始返回数据、以及Agent自动生成的“接管理由摘要”（如“因用户提及‘解除合同’，需法务专家确认条款适用性”）。这个包直接推送到指定专家的钉钉/企业微信，专家点开就能看到全部上下文，无需再手动翻日志。我们统计过，L3接管请求只占总任务量的0.3%，但99%的问题都在L1/L2层被消化了。

这种分层设计，让“干预”不再是打断流程的负担，而成了Agent提升自身可靠性的主动学习机会。每次L2追问被用户选择，都是一次对意图识别模型的隐式训练；每次L3接管，都会触发一个“接管后复盘”任务，自动生成改进建议（如“建议在‘合同’相关指令中增加法务知识库检索步骤”）。

3. 核心实操环节：从零搭建“管得住”的Agent基础设施

3.1 环境准备与依赖选型：为什么我们放弃LangChain，选择自研编排层

市面上主流的Agent框架，LangChain、LlamaIndex、Semantic Kernel，它们在“跑得起来”这件事上做得非常出色：封装了LLM调用、工具注册、记忆管理，让你十分钟就能搭出一个能聊天的Agent。但当我们开始构建“管得住”的基础设施时，这些框架的抽象层反而成了障碍。LangChain的CallbackHandler虽然能捕获事件，但它把所有事件（on_llm_start, on_tool_start, on_chain_end）混在一个回调流里，无法区分“这是用户输入”还是“这是工具返回的中间数据”；LlamaIndex的Observability模块只提供基础指标，不支持决策快照这种深度结构化数据。

所以我们做了个看似“倒退”的决定：放弃高层框架，基于OpenAI SDK和Requests库，从零构建一个极简的Agent编排层（Orchestrator）。这个决定背后的计算很实在：LangChain的抽象层带来了约22ms的额外CPU开销（实测），而我们要注入的可观测性钩子（决策快照、输出校验）本身就需要IO操作。如果再叠加上框架自身的调度开销，端到端延迟很容易突破500ms，影响用户体验。自研编排层让我们能把延迟控制在300ms以内，且所有钩子都精准插在业务逻辑的关键切点上。

核心依赖只有四个，全部选型基于“可控、可调试、无黑盒”原则：

• LLM客户端：openai>=1.0.0（官方SDK，文档全，错误码清晰，避免任何第三方封装）
• 向量存储：chromadb==0.4.22（轻量、纯Python、支持内存模式，开发调试零配置）
• 时序数据库：clickhouse-driver==0.2.7（专为分析优化，插入吞吐达50万行/秒，比PostgreSQL快17倍）
• 配置中心：pydantic-settings==2.2.1（用Pydantic V2的Settings模型管理所有配置，支持环境变量、.env文件、代码默认值三级覆盖）

安装命令极其简单：

pip install openai chromadb clickhouse-driver pydantic-settings

提示：不要用pip install langchain来替代。LangChain的依赖树里包含tenacity（重试库）、aiohttp（异步HTTP）、jsonpatch（JSON补丁）等十几个间接依赖，其中tenacity的重试策略与我们的熔断机制冲突，曾导致一次线上雪崩。自研编排层让我们能精确控制每一个依赖的版本和行为。

3.2 决策快照（Decision Snapshot）的完整实现与存储设计

决策快照是“管得住”的心脏，它必须轻量、结构化、可索引。我们定义了一个Pydantic模型，确保类型安全和序列化一致性：

from datetime import datetime from typing import List, Optional, Dict, Any from pydantic import BaseModel, Field class DecisionSnapshot(BaseModel): snapshot_id: str = Field(..., description="UUIDv4，全局唯一") session_id: str = Field(..., description="会话ID，用于串联多轮") step_id: int = Field(..., description="当前步骤序号，从1开始") decision_type: str = Field(..., description="e.g., 'tool_selection', 'intent_classification', 'output_validation'") input_context: List[str] = Field(default_factory=list, description="引用的上下文片段列表") candidates: List[Dict[str, Any]] = Field(default_factory=list, description="备选方案及置信度") confidence_score: float = Field(ge=0.0, le=1.0, description="主决策置信度") decision_reason: str = Field(..., description="LLM生成的决策理由文本") tool_call: Optional[Dict[str, Any]] = Field(default=None, description="若调用工具，记录工具名和参数") execution_time_ms: float = Field(..., description="从决策开始到结束的毫秒数") created_at: datetime = Field(default_factory=datetime.utcnow)

关键在于如何在Agent执行流中无侵入地注入这个快照。我们采用装饰器+上下文管理器双保险模式：

import time import uuid from contextlib import contextmanager from clickhouse_driver import Client # 全局ClickHouse客户端 ch_client = Client(host='localhost', port=9000, database='agent_observability') @contextmanager def capture_decision(session_id: str, decision_type: str, input_context: List[str]): """决策快照上下文管理器""" start_time = time.time() snapshot_id = str(uuid.uuid4()) try: yield snapshot_id except Exception as e: # 异常时也记录快照，标记为failed snapshot = DecisionSnapshot( snapshot_id=snapshot_id, session_id=session_id, step_id=get_next_step_id(session_id), decision_type=decision_type, input_context=input_context, candidates=[], confidence_score=0.0, decision_reason=f"Exception: {str(e)}", execution_time_ms=(time.time() - start_time) * 1000, ) # 异步写入ClickHouse（避免阻塞主流程） ch_client.execute( "INSERT INTO decision_snapshots VALUES", [snapshot.dict()] ) raise else: # 正常结束，记录完整快照 end_time = time.time() snapshot = DecisionSnapshot( snapshot_id=snapshot_id, session_id=session_id, step_id=get_next_step_id(session_id), decision_type=decision_type, input_context=input_context, candidates=get_candidates_from_context(), # 伪代码，实际从LLM响应中提取 confidence_score=calculate_confidence(), # 伪代码，实际用小型分类器 decision_reason=get_decision_reason(), # 伪代码，实际从LLM响应中提取 tool_call=get_tool_call_if_any(), # 伪代码 execution_time_ms=(end_time - start_time) * 1000, ) ch_client.execute( "INSERT INTO decision_snapshots VALUES", [snapshot.dict()] ) # 在Agent核心逻辑中使用 def select_tool_for_query(user_query: str, available_tools: List[Tool]) -> Tool: with capture_decision( session_id="sess_abc123", decision_type="tool_selection", input_context=[user_query] + get_relevant_knowledge(user_query) ) as snapshot_id: # 这里是你的LLM调用逻辑，生成tool_name和args tool_name, args = llm_call_to_select_tool(user_query, available_tools) selected_tool = find_tool_by_name(tool_name, available_tools) return selected_tool

注意：ClickHouse的execute是同步阻塞的，但我们用的是clickhouse-driver的原生客户端，它底层是TCP长连接，单次插入延迟稳定在3-5ms。对于高并发场景，我们会把这个写入操作放到一个独立的线程池里，用concurrent.futures.ThreadPoolExecutor管理，确保不影响主Agent线程。实测表明，即使在1000 QPS下，快照写入成功率仍保持99.99%，丢失的数据会被补偿任务定时拉取。

3.3 输出校验网关（Output Validation Gateway）的三层防御体系

输出校验不是简单的“检查字符串里有没有敏感词”，它是一个分层过滤系统，每一层解决一类风险：

L1层最简单也最重要。我们为常见输出类型定义了Pydantic模型，比如周报输出：

from pydantic import BaseModel, Field, validator from datetime import date class WeeklyReportOutput(BaseModel): week_start: date = Field(..., description="周报起始日期") week_end: date = Field(..., description="周报结束日期") total_revenue: float = Field(..., ge=0.0, description="总收入，必须>=0") new_customers: int = Field(..., ge=0, description="新增客户数，必须>=0") top_product: str = Field(..., min_length=1, max_length=100, description="爆款产品名称") @validator('total_revenue') def revenue_must_be_positive(cls, v): if v < 0: raise ValueError('revenue cannot be negative') return v # 在Agent输出后，强制校验 try: validated_output = WeeklyReportOutput.parse_obj(agent_raw_output) except ValidationError as e: # 记录L1失败，返回友好提示 log_validation_failure("L1_format", str(e)) return {"error": "输出格式错误，请检查输入数据"}

L2层的事实校验，我们用一个微调过的FinBERT模型。训练数据来自历史周报和对应的财务系统真实数据，标签是“一致”或“矛盾”。模型很小，只有12MB，可以加载到内存里，单次推理只要18ms。它不判断“对错”，只判断“是否与已知事实矛盾”。比如，当周报里写“Q3销售额1200万”，而财务系统里Q3实际是1150万，模型会输出“矛盾”，但不会告诉你应该是多少——那是L3人工复核的事。

L3层的合规校验，我们用Drools规则引擎。规则文件compliance.drl示例：

rule "Block SSN in Output" when $output: String() from entry-point "outputStream" eval( $output.matches(".*\\b\\d{3}-\\d{2}-\\d{4}\\b.*") ) then System.out.println("SSN detected in output!"); // 触发脱敏动作 modify($output) { /* replace SSN with *** */ } insert(new AuditLog("SSN_DETECTED", $output)); end

所有校验层的结果，都会生成一个ValidationResult对象，与决策快照ID绑定，存入ClickHouse的output_validations表。这样，当你在看板上看到某次输出校验失败时，可以一键下钻，看到完整的输入、决策链、工具返回数据，形成闭环。

3.4 熔断与降级：那个“一键开关”背后的真实逻辑

“一键熔断”听起来很酷，但现实中，一个粗暴的kill -9进程，只会让问题更糟。真正的熔断，必须是有状态、可感知、可恢复的。我们的熔断系统叫Circuit Breaker Orchestrator (CBO)，它不是一个独立服务，而是嵌入在Agent编排层里的一个状态机。

CBO有三个核心状态：

• CLOSED（闭合）：正常流量通过，所有功能启用。
• OPEN（开启）：检测到连续N次失败（如决策置信度<0.3超过5次），自动切换至此状态。此时，所有新请求不再执行完整Agent链，而是直接路由到降级策略（Fallback Strategy）。
• HALF_OPEN（半开启）：在OPEN状态持续T秒后，自动进入此状态。此时，只放行1%的随机请求走完整链路，其余99%仍走降级。如果这1%的请求全部成功，则切回CLOSED；如有失败，则重置计时器，继续OPEN。

降级策略不是简单的“返回抱歉”，而是分场景的智能兜底：

• 工具调用失败降级：当某个工具（如天气API）超时，Agent会尝试调用备用工具（如本地缓存的天气数据），若无备用，则用LLM基于历史数据生成合理估算，并在回复中标注“【数据为估算值】”。
• LLM响应失败降级：当LLM调用超时或返回空，Agent会从向量库中检索最相似的历史成功响应，稍作改写后返回，并标注“【基于历史案例生成】”。
• 全链路失败降级：当CBO处于OPEN状态，所有请求都走一个极简的静态响应模板，比如“系统正在维护，您的请求已记录，稍后将人工处理”，同时自动创建一个工单。

CBO的状态持久化到Redis，确保集群中所有Agent实例共享同一熔断状态。我们用Redis的INCR和EXPIRE命令实现计数器和超时：

import redis import json r = redis.Redis(host='localhost', port=6379, db=0) def check_circuit_breaker(session_id: str) -> str: """检查熔断器状态，返回 'CLOSED', 'OPEN', or 'HALF_OPEN'""" # KEY: cb:state state = r.get("cb:state") if not state: return "CLOSED" state_data = json.loads(state) if state_data["status"] == "OPEN": # 检查OPEN状态是否超时 open_until = state_data.get("open_until", 0) if time.time() > open_until: # 切换到HALF_OPEN r.setex("cb:state", 300, json.dumps({"status": "HALF_OPEN", "last_check": time.time()})) return "HALF_OPEN" return "OPEN" return state_data["status"] def record_failure(): """记录一次失败，触发熔断逻辑""" # KEY: cb:failure_count count = r.incr("cb:failure_count") r.expire("cb:failure_count", 300) # 5分钟窗口 if count >= 5: # 触发OPEN状态，持续300秒 r.setex("cb:state", 300, json.dumps({ "status": "OPEN", "open_until": time.time() + 300, "triggered_at": time.time() }))

实操心得：熔断阈值不能拍脑袋定。我们通过分析三个月的线上日志，发现当“置信度<0.3”的失败率超过1.2%时，后续10分钟内的幻觉率会飙升到37%。所以最终把熔断阈值设为“连续5次置信度<0.3”，这个数字是数据驱动的，不是经验主义。

4. 常见问题与实战排障：那些文档里不会写的坑

4.1 问题速查表：高频故障现象、根因与修复方案

4.2 那些踩过的坑：血泪教训总结

坑一：在决策快照里存LLM的原始响应文本，导致ClickHouse磁盘爆满

我们最初为了“全量保留”，把LLM的每一次response.choices[0].message.content都存进了快照。结果两周后，decision_snapshots表暴涨到2TB，ClickHouse磁盘使用率98%。紧急扩容后，我们意识到：决策快照要存的是“决策的证据”，不是“决策的全文”。现在的规范是：只存response.choices[0].message.content的前200字符（用于快速预览），以及一个SHA256哈希值。完整响应文本，只在llm_responses表里存，且设置TTL为7天。

坑二：用datetime.utcnow()生成快照时间戳，导致跨时区服务时间错乱

Agent部署在Kubernetes集群，Pod分布在不同可用区，有的用UTC，有的用CST。utcnow()在不同节点上生成的时间戳有毫秒级偏差，导致在ClickHouse里用created_at排序时，决策链顺序错乱。解决方案是：所有时间戳统一用time.time()（Unix时间戳，浮点秒），并在应用层转换为ISO格式。time.time()是系统级单调时钟，不受时区影响，精度更高。

坑三：把“可干预性”做成后台管理界面，结果审核员成了新瓶颈

前面提过，我们曾用一个Django Admin后台做人工审核，结果审核队列积压。后来我们彻底重构，把审核入口直接集成到用户聊天界面里。当Agent发起L3接管时，它不是生成一个后台链接，而是向用户发送一条特殊消息：“【法务专家正在接入】请稍候，或点击此处查看问题详情并自助处理”。消息里嵌了一个按钮，点开就是精简版的上下文摘要和两个快捷操作：“我同意”、“我需要修改”。审核员只在真正需要深度介入时才出现。这个改动，让L3接管的平均处理时间从42分钟降到3.7分钟。

坑四：熔断器只监控“失败”，却忽略了“慢成功”

有一次，天气API没挂，但响应时间从300ms涨到3秒。CBO没触发，因为没失败。但用户已经流失了。我们增加了性能熔断：监控P95响应时间，当连续5分钟P95 > 1500ms，自动进入HALF_OPEN状态。这个指标比单纯的错误率更能反映用户体验。

4.3 性能压测实录：从50 QPS到5000 QPS的平滑演进

我们用Locust对整套“管得住”基础设施做了阶梯式压测。关键结论不是“最大能扛多少”，而是“在什么负载下，各组件开始成为瓶颈”。

• 50 QPS：一切平稳。决策快照写入延迟<5ms，ClickHouse CPU<20%，Redis内存占用<1GB。这是中小团队的安全线。
• 500 QPS：ClickHouse的Merge线程开始排队，system.merges表显示is_merging=1的记录增多。解决方案：将decision_snapshots表的index_granularity从默认的8192调大到16384，减少索引碎片。
• 2000 QPS：Redis的INCR命令出现超时（TimeoutError），熔断计数器不准。解决方案：将Redis连接池大小从10提升到50，并启用连接池的max_idle_time参数，避免连接老化。
• 5000 QPS：LLM调用成为绝对瓶颈（OpenAI API限流），但我们的CBO成功将99%的请求降级到缓存响应，整体P95延迟稳定在420ms，未出现雪崩。这证明，“管得住”的基础设施，其价值不仅在于发现问题，更在于优雅地承受问题。

压测报告里最值得分享的不是峰值数字，而是一张“资源利用率热力图”。它清晰显示：在5000 QPS下，CPU最忙的是LLM客户端（78%），其次是ClickHouse（45%），Redis只有22%。这告诉我们，优化方向应该聚焦在LLM调