企业官网建设流程全解析

1. 这不是“算账”，而是让 Agent 真正跑得稳、用得起的关键动作

“Agent 的任务成本，如何管理？”——这问题最近在多个技术社区高频出现，背后不是空泛的理论探讨，而是大量团队把 Agent 落地到真实业务场景后，被账单和响应延迟“打醒”的切肤之痛。我接触过某电商中台团队，他们上线了一个商品智能导购 Agent，初期测试时响应快、体验好，但上线两周后发现单次对话平均耗时从800ms飙升到3.2秒，API调用费用环比涨了470%；还有某教育类 SaaS 公司，用 Agent 做课后作业批改，结果发现一个初中数学题的推理链平均触发7次大模型调用，其中3次是重复确认同一参数，单题处理成本比人工还高。这些都不是模型能力不行，而是任务成本失控——就像给一辆高性能跑车装上没标刻度的油表，踩油门很爽，但不知道下一公里会不会抛锚。

所谓“Agent 的任务成本”，绝非简单等同于“调用了几次大模型”。它是一个多维复合体：包含计算资源消耗（token 占用、推理时长、并发等待）、外部服务依赖成本（知识库检索、函数调用、数据库查询）、时间成本（用户等待感知、任务超时重试），甚至隐含维护成本（调试难度、链路不可见、异常归因困难）。很多团队一上来就盯着“每次调用多少钱”，却忽略了：一次看似便宜的 500 token 调用，如果因为提示词设计缺陷导致失败重试3次，实际成本就是1500 token + 3次网络开销 + 工程师15分钟排查时间。真正有效的成本管理，不是抠单次调用，而是构建可度量、可干预、可优化的任务生命周期闭环。这篇文章面向的是已经跑通第一个 Agent Demo、正准备推进规模化落地的工程师、技术负责人和产品架构师——你不需要从零学 LLM 原理，但必须能看懂自己 Agent 的“心电图”，知道哪根线异常了、为什么异常、怎么调回来。下面所有内容，都来自我们过去18个月在6个不同行业 Agent 项目中的实操沉淀，没有PPT式概括，只有带参数、带日志、带决策依据的硬核拆解。

2. 成本失控的三大典型病灶，90%的团队都踩过至少两个

要管成本，先得看清病在哪。我们把过去所有成本异常案例归为三类根本性病灶，不是表面现象，而是系统性设计缺陷。它们往往相互嵌套，单独修复一个，另一个马上冒头。识别它们，是成本管理的第一步。

2.1 病灶一：任务边界模糊——Agent 不知道自己该“干到哪一步为止”

这是最隐蔽也最致命的问题。很多团队把 Agent 当成“万能胶水”，只要用户一句话，就启动一整套推理链：查知识库→调工具→生成→验证→再查→再生成……直到“感觉差不多了”才停。但大模型本身没有内置的“完成感”，它的停止信号完全依赖提示词里的约束或系统层的 timeout 设置。我们复盘过一个客服 Agent 的日志：用户问“我的订单#12345为什么还没发货？”，Agent 按标准流程先查订单状态，返回“已支付，待发货”，本该结束。但它接着又去查物流接口（返回空）、查库存接口（返回缺货）、调用内部风控API（验证是否异常订单），最后才生成回复。整个链路消耗2100 token，耗时2.8秒，而核心信息仅需320 token、0.4秒就能给出。

提示：任务边界模糊的本质，是把“用户意图识别”和“任务执行策略”混在同一个推理循环里。正确做法是分两层：第一层用轻量级分类器（甚至规则引擎）快速判定任务类型与终止条件（如“查订单状态”属于原子任务，查完即止）；第二层才调用大模型执行。我们实测用一个500行的 FastAPI 分类服务，能把70%的简单查询拦截在大模型之外，平均 token 节省率达63%。

2.2 病灶二：工具调用失焦——不是“能不能调”，而是“该不该调、调几次、调哪个”

工具调用（Function Calling）常被当作 Agent 的“超能力”，但现实是：它极易成为成本黑洞。我们统计过12个生产环境 Agent 的工具调用日志，发现三个共性：

• 冗余调用：同一工具被连续调用2次以上，且输入参数几乎不变（占比38%）；
• 错位调用：本可用缓存或本地计算解决的问题，强行调用远程 API（如用天气 API 查“今天北京温度”，而城市ID和日期都是固定值，应预置）；
• 试探性调用：因参数不全或格式错误，反复尝试不同参数组合直到成功（最极端案例：一个地址解析任务平均调用高德API 5.7次才返回有效结果）。

关键在于，工具调用成本 ≠ API 费用。它还包括：网络延迟（平均120ms）、序列化/反序列化开销（约80ms）、失败重试的指数退避等待（首次失败后等1s，再失败等2s……）。一次失败的工具调用，实际拖慢整个任务链路的时间，可能远超其自身API费用。

注意：不要迷信“自动工具选择”。我们在金融风控 Agent 中对比过两种方案：一种用 LLM 动态选工具（准确率82%，平均调用1.8次），另一种用预定义决策树（准确率94%，平均调用1.1次）。后者不仅成本低，更重要的是可预测、可审计、可压测。对于核心业务路径，确定性永远优于灵活性。

2.3 病灶三：上下文膨胀失控——把“记忆”当“档案馆”，越堆越重

Agent 需要记忆用户历史、任务上下文，但很多实现方式是“来者不拒”：把整个对话历史、所有工具返回结果、甚至中间思考步骤，一股脑塞进下一轮 prompt。我们抓取过一个医疗咨询 Agent 的典型请求：用户第5轮提问，prompt 中携带了前4轮全部对话（2300 token）、3次工具返回的JSON（1800 token）、以及2次内部反思日志（900 token），总输入达5000 token。而实际生成回复只需关注最后一轮问题和最新检查报告（<800 token）。多余上下文不仅浪费 token，更严重的是稀释关键信息权重，导致模型忽略真正重要的诊断线索。

更危险的是“伪记忆”：有些 Agent 把用户说过的话原样存入向量库，下次检索时返回大段无关文本。我们曾发现一个法律咨询 Agent，用户问“离婚财产怎么分”，它从向量库召回3年前另一用户咨询“婚前房产归属”的全文（2100字），并作为背景喂给大模型，结果生成的回复完全偏离当前问题焦点。

实操心得：上下文管理不是“删减”，而是“结构化注入”。我们强制要求所有 Agent 实现三层上下文：

• 元上下文（Meta Context）：固定模板，含角色定义、任务约束、输出格式（≤200 token）；
• 动态上下文（Dynamic Context）：仅保留与当前任务强相关的前1-2轮对话+最新工具结果摘要（≤600 token）；
• 可检索上下文（Retrievable Context）：存入向量库，但只在明确需要历史参考时（如用户说“按上次说的办”）才触发检索，且强制限制返回片段数≤2、总长度≤300 token。

3. 四层成本度量体系：从“看不见”到“看得清”，再到“管得住”

没有度量，就没有管理。但多数团队只盯着最表层的“总 token 数”，这就像只看汽车仪表盘的“总油耗”，却不管转速、水温、胎压。我们构建了一套四层穿透式度量体系，每层对应不同决策主体和优化手段，数据全部来自真实 Agent 请求链路的埋点日志（非估算）。

3.1 L1 层：原子操作成本（工程师视角）

这是最细颗粒度，直接映射到代码行和配置项。我们要求每个 Agent 组件必须暴露以下6个核心指标（单位统一为毫秒/ms 和 token）：

关键实践：这些指标不能只存在监控大盘里。我们在 CI/CD 流程中加入“成本门禁”：任何新提交的提示词或工具集成，必须通过本地压测，确保llm_input_tokens增幅不超过5%，chain_retry_count不新增。未达标则阻断合并。这倒逼团队在开发早期就建立成本意识。

3.2 L2 层：任务链路成本（技术负责人视角）

L1 是零件，L2 是整机。它把一次用户请求拆解为可追踪的完整链路，用 OpenTelemetry 标准格式记录每个环节耗时与资源消耗。我们定义一个标准任务链路包含5个必埋点阶段：

1. Intent Recognition（意图识别）：从原始输入到任务类型判定
2. Context Assembly（上下文组装）：加载历史、检索知识、构造 prompt
3. LLM Execution（大模型执行）：含实际调用与输出解析
4. Tool Orchestration（工具编排）：含调用、等待、结果处理
5. Response Rendering（响应渲染）：格式化、安全过滤、流式封装

每个阶段必须记录start_time、end_time、error_code、cost_metrics（关联L1指标）。这样，当发现某类任务整体超时，就能精准定位是卡在“Context Assembly”（说明知识库检索慢），还是“Tool Orchestration”（说明某个第三方API不稳定）。

实测案例：某政务咨询 Agent 平均响应超时率12%。通过 L2 链路分析，发现92%的超时发生在Tool Orchestration阶段，进一步下钻发现是社保查询接口平均耗时2.1秒。解决方案不是优化Agent，而是推动对接方提供异步回调接口，并在 Agent 层实现“先返回预计处理时间，再推送结果”的用户体验降级方案，超时率降至0.3%。

3.3 L3 层：业务单元成本（产品负责人视角）

这是连接技术成本与商业价值的桥梁。我们按业务维度聚合成本，定义“业务单元”为具有相同用户目标、相同价值交付的最小任务集合。例如：

• 电商场景：订单查询、物流跟踪、退换货申请各为一个业务单元
• 教育场景：题目解析、知识点推荐、学习计划生成各为一个业务单元

对每个业务单元，计算三个核心 KPI：

• Cost per Unit (CPU)：该单元平均单次任务成本（token/ms）
• Value Density (VD)：该单元带来的业务价值（如：退换货申请成功提交=1次GMV保全，可折算为金额）
• ROI Ratio：VD / CPU，即单位成本创造的价值

关键洞察：我们发现 ROI Ratio 低于0.8 的业务单元，80%存在“功能过度设计”。例如某理财 Agent 的基金定投建议单元，CPU 高达4200 token，但VD仅为“用户点击确认”，ROI 仅0.15。重构后，改为只提供3个预设策略（激进/平衡/稳健）供选择，CPU 降至680 token，VD 不变（用户仍需点击），ROI 升至0.92。成本管理的终极目标不是压低成本，而是提升价值密度。

3.4 L4 层：系统承载成本（CTO 视角）

这是全局视角，回答“我们的 Agent 架构，到底能支撑多少业务量”。它不看单次任务，而看系统级资源水位与弹性：

• Concurrency Cost Curve：并发请求数 vs 平均响应耗时曲线（非线性，通常在并发>50时陡升）
• Token Throughput Ceiling：系统每秒可处理的最大 token 数（受GPU显存、KV Cache 效率制约）
• Failure Cascade Index：单个组件故障引发连锁失败的概率（如知识库宕机导致80%任务降级为LLM兜底，成本翻倍）

我们用混沌工程方法定期压测：模拟知识库延迟增加300ms，观察LLM Execution阶段的output_tokens是否异常增长（说明模型在补偿信息缺失），并触发熔断机制。L4 层的目标是让成本管理从“被动救火”变为“主动规划”——比如根据下季度营销活动预估流量峰值，提前扩容 GPU 资源或启用更经济的量化模型。

4. 六种经过实战验证的成本优化策略，附具体参数与效果

度量只是眼睛，优化才是手脚。以下六种策略，全部来自真实项目，有明确适用条件、实施步骤、参数配置和效果数据。不是“理论上可行”，而是“我们已跑通”。

4.1 策略一：Prompt 分层压缩——用“指令+变量”替代“全文本拼接”

适用场景：上下文主要由固定模板+动态变量构成（如客服话术、报告生成）
原理：避免将大段固定文本重复注入每次 prompt，改用结构化指令引导模型“按模板填空”。
实操步骤：

1. 将 prompt 拆分为template（纯指令，不含变量）和variables（JSON 格式动态数据）；
2. 在 template 中用占位符标记变量位置，如"客户姓名：{{customer_name}}，订单号：{{order_id}}"；
3. Agent 执行时，先解析 variables，再用字符串替换生成最终 prompt。

关键参数：

• template_token_count：必须 ≤300 token（我们实测超过此值，模型对占位符理解准确率下降）
• variables_json_size：单次 variables JSON 字符串 ≤1500 字符（过大易触发模型解析错误）

效果：某保险 Agent 将理赔说明生成 prompt 从1820 token 压缩至410 token，llm_input_tokens降低77%，响应耗时从1.9s 降至0.6s。

注意：此策略对需要模型深度理解上下文语义的任务（如法律条款推理）不适用，会损失关键信息。

4.2 策略二：工具调用预检——在 LLM 调用前，用轻量规则拦截无效请求

适用场景：工具参数有明确格式、范围或依赖关系（如日期格式、ID 长度、状态机流转）
原理：不让 LLM 为明显错误的参数“白忙一场”，用确定性规则提前校验。
实操步骤：

1. 为每个工具定义precheck_rules（正则、范围检查、依赖校验）；
2. Agent 在生成function_call前，先运行 precheck_rules；
3. 若校验失败，直接返回结构化错误（如{"error": "date_format_invalid", "suggestion": "请使用YYYY-MM-DD格式"}），不调用 LLM。

关键参数：

• precheck_overhead_ms：单次预检耗时必须 <5ms（我们用 Rust 编写核心校验模块）
• rule_coverage_rate：预检规则需覆盖85%以上的常见错误类型（基于历史错误日志统计）

效果：某物流 Agent 的运单查询工具，预检拦截了63%的格式错误请求，tool_call_latency平均下降41%，chain_retry_count从1.8降至0.3。

实操心得：预检规则必须和业务方共同制定，我们曾因忽略一个“特殊渠道订单号含字母”的例外，导致上线后误拦截12%的有效请求。现在所有规则变更必须同步更新业务文档。

4.3 策略三：知识库分层检索——用“粗筛+精排”替代“全量向量搜索”

适用场景：知识库规模大（>10万文档）、查询精度要求高
原理：向量检索耗时与库大小正相关，先用低成本方法（关键词、元数据）快速缩小候选集，再对小集合做向量相似度计算。
实操步骤：

1. 对知识库文档建立两级索引：
   • Level 1（关键词索引）：提取标题、标签、首段关键词，构建倒排索引；
   • Level 2（向量索引）：仅对 Level 1 返回的 Top-50 文档做向量检索；
2. 用户查询时，先走 Level 1，若无匹配则降级为全量向量检索。

关键参数：

• level1_recall_rate：Level 1 必须保证 ≥70% 的有效文档被召回（否则精排失去意义）
• level2_candidate_count：Level 2 向量检索的候选集严格限制为 ≤50（实测超过此数，精度提升微弱但耗时剧增）

效果：某高校科研问答 Agent，知识库含23万篇论文，分层检索使retrieval_tokens从平均1200降至320，retrieval_latency从850ms 降至110ms。

提示：Level 1 的关键词提取不能简单用jieba分词。我们针对学术文献，定制了“标题实体+期刊缩写+研究方法”三元组提取规则，召回率提升22%。

4.4 策略四：LLM 推理链剪枝——用“早停机制”替代“全链路执行”

适用场景：任务存在明确的中间成功判定点（如查到订单状态即可返回，无需继续查物流）
原理：在推理链的每个关键节点后，插入一个轻量级“是否终止”判断，满足条件则立即返回，跳过后续步骤。
实操步骤：

1. 定义early_stop_conditions（如：“订单状态字段存在且不为空”、“工具返回code=200”）；
2. 在每个工具调用或 LLM 生成后，用一个小型分类模型（<10MB）判断条件是否满足；
3. 若满足，直接组装响应，终止链路。

关键参数：

• early_stop_model_size：分类模型必须 ≤10MB（确保可部署在边缘节点）
• condition_accuracy：早停判断准确率 ≥99.2%（低于此值，误停会导致用户投诉）

效果：某酒店预订 Agent，用户问“帮我订明天北京的酒店”，传统链路需查价格→比价→选房→确认，平均耗时3.2秒；启用早停后，查到首个符合预算的酒店即返回，平均耗时降至0.9秒，llm_output_tokens减少68%。

注意：早停条件必须业务强相关，不能是“模型置信度>0.8”这类模糊指标，否则不可控。

4.5 策略五：响应流式分级——用“渐进式交付”替代“全量等待”

适用场景：用户对响应实时性敏感，且任务可分阶段交付（如长文档总结、多步骤分析）
原理：不等整个任务完成，而是将中间结果分块、分阶段推送给前端，降低用户感知延迟。
实操步骤：

1. 将 Agent 输出结构化为stages（如：["summary", "key_points", "action_items"]）；
2. 每个 stage 生成后，立即通过 SSE（Server-Sent Events）推送；
3. 前端按 stage 渲染，未完成 stage 显示加载态。

关键参数：

• stage_count：严格控制 ≤3 个 stage（过多增加前端复杂度，且用户注意力有限）
• stage_latency_target：每个 stage 生成耗时目标 ≤800ms（超过则需优化该 stage 的 prompt 或工具）

效果：某法律文书分析 Agent，全文总结从平均4.1秒降至“首屏0.7秒显示摘要，2.3秒完成全部”，用户放弃率下降58%。

实操心得：流式交付必须配套“降级兜底”。我们约定：若任一 stage 超时1.5秒，则跳过该 stage，直接进入下一个。确保用户不会卡在某个环节无限等待。

4.6 策略六：成本-质量动态权衡——用“可配置滑块”替代“一刀切策略”

适用场景：同一 Agent 需服务不同优先级用户或场景（如VIP用户 vs 普通用户，核心交易 vs 辅助查询）
原理：不追求绝对最优，而是根据业务权重，动态调整成本与质量的平衡点。
实操步骤：

1. 定义quality_level参数（1-5级），1级为极速响应（允许部分信息缺失），5级为最高质量（穷尽所有工具）；
2. 在 Agent 配置中心设置每个业务单元的默认 quality_level；
3. 用户请求时，可携带quality_hint（如VIP用户默认为4），覆盖默认值。

关键参数：

• quality_cost_ratio：每提升1级 quality，预估成本增幅 ≤40%（我们通过历史数据建模得出）
• level_mapping_rules：明确每级对应的策略（如 level=2：禁用向量检索，只查缓存；level=4：启用全量工具链）

效果：某金融客服 Agent，将普通用户默认 quality_level 设为2，VIP用户为4，整体 token 成本下降31%，VIP用户满意度维持在98.7%。

提示：quality_level 不是越多越好。我们测试过7级，发现3-5级之间成本差异微小但质量提升趋缓，最终收敛为5级，兼顾区分度与管理成本。

5. 成本异常的七类高频问题与现场排查手册

再好的设计，也会遇到突发异常。以下是我们在生产环境中高频遭遇的七类问题，附带真实日志片段、根因分析和一键修复命令（适配主流 Agent 框架）。这不是教科书式罗列，而是“你打开监控看到这个，下一步该做什么”的实战指南。

5.1 问题一：llm_input_tokens突然暴涨200%，但 prompt 模板未变更

典型日志：

[2024-06-15 14:22:31] INFO task_abc123: input_tokens=4280, prev_avg=1420 [2024-06-15 14:22:31] DEBUG context_assembly: retrieved_docs=12, total_chars=18420

根因分析：知识库检索返回文档数暴增，且单文档字符数超标。常见于：

• 新增了未切片的大文档（如PDF全文导入）；
• 检索相似度阈值设得过低（如0.2），召回大量低相关文本。

排查命令（以 ChromaDB 为例）：

# 查看最近1小时召回最多的文档ID chroma query --collection "faq" --n_results 10 --where "timestamp > '2024-06-15T13:00:00'" | jq '.documents | map(length) | sort | last' # 检查相似度阈值配置 grep "similarity_threshold" config.yaml # 应为0.5~0.7，若为0.2则立即修改

修复动作：

1. 立即在知识库管理后台，对retrieved_docs > 5的文档执行“强制重切片”；
2. 将similarity_threshold从0.2调至0.55；
3. 临时启用retrieval_candidate_limit=3（限制最多召回3篇）。

注意：不要直接删除文档！先切片再清理，避免影响正在运行的任务。

5.2 问题二：chain_retry_count持续≥3，且错误码集中为TOOL_EXECUTION_TIMEOUT

典型日志：

[2024-06-15 15:03:44] ERROR task_xyz789: retry=3, error="TOOL_EXECUTION_TIMEOUT", tool="weather_api" [2024-06-15 15:03:44] DEBUG tool_orchestration: timeout_ms=1000, actual_latency=2400

根因分析：工具调用超时设置（timeout_ms）远低于实际网络延迟，导致频繁重试。根本原因常是：

• 第三方 API 服务商近期升级，响应变慢；
• Agent 部署节点与工具服务跨地域（如Agent在华东，工具API在华北）。

排查命令：

# 测试工具API真实延迟（绕过Agent） curl -w "@curl-format.txt" -o /dev/null -s "https://api.weather.com/v3/weather/forecast?locationKey=12345" # 查看Agent节点与工具服务的网络延迟 mtr --report-cycles 10 api.weather.com # 关注Loss%和Avg列

修复动作：

1. 将weather_api的timeout_ms从1000调至3000；
2. 在tool_call_latency监控中，为该工具添加“P95延迟 > 2500ms”告警；
3. 若网络延迟持续>200ms，申请在工具服务侧部署就近代理节点。

实操心得：所有工具的 timeout_ms 必须设为“P95延迟 × 1.5”，而非拍脑袋定值。我们有个脚本每天自动计算并更新。

5.3 问题三：llm_output_tokens异常高，且返回内容包含大量重复句式

典型日志：

[2024-06-15 16:11:22] INFO task_def456: output_tokens=2850, response="...因此，综上所述，可以得出结论...因此，综上所述，可以得出结论..."

根因分析：模型陷入“重复幻觉”，常见于：

• 提示词中存在矛盾指令（如既要求“简洁”，又要求“详细解释每个步骤”）；
• 上下文包含大量相似语义的冗余信息，干扰模型聚焦。

排查命令：

# 分析prompt中是否存在矛盾关键词 echo "$PROMPT" | grep -E "(简洁|简明|brief)|(详细|全面|complete)" | wc -l # 若>1，即存在冲突 # 检查上下文重复率 python -c "import difflib; print(difflib.SequenceMatcher(None, ctx1, ctx2).ratio())"

修复动作：

1. 重写提示词，用明确优先级替代模糊要求（如：“用不超过3句话总结，每句话≤20字”）；
2. 在Context Assembly阶段，启用“语义去重”模块（我们用 Sentence-BERT 计算相似度，>0.85 的片段只保留1个）；
3. 为 LLM 添加stop_sequences=["因此，综上所述", "总而言之"]。

提示：重复幻觉是模型能力问题，但可通过 prompt 工程大幅缓解。我们整理了27条“防幻觉prompt模板”，按场景分类，团队内共享。

5.4 问题四：state_serialization_ms突增至>50ms，且伴随内存占用飙升

典型日志：

[2024-06-15 17:05:18] WARN task_ghi789: state_serialization_ms=68, memory_used_gb=12.4/16.0 [2024-06-15 17:05:18] DEBUG state: keys=["history", "tools_cache", "user_profile", "temp_files"]

根因分析：Agent 状态中存入了大对象（如原始图片base64、未压缩的JSON数组），序列化时耗时剧增。

排查命令：

# 查看状态对象各字段大小 python -c "import pickle; print({k: len(pickle.dumps(v)) for k,v in state.items()})" # 检查是否有base64图片 echo "$STATE_JSON" | grep "data:image" | wc -l

修复动作：

1. 立即清理temp_files字段（存储临时文件路径，而非文件内容）；
2. 将user_profile中的头像等大字段，改为存储 CDN URL；
3. 在状态写入前，强制执行json.dumps(state, separators=(',', ':'))去除空格。

注意：状态序列化耗时超过20ms，必须触发告警。我们规定所有状态字段必须通过size_validator检查，单字段≤1MB。

5.5 问题五：retrieval_latency波动剧烈，P95从200ms跳至1800ms

典型日志：

[2024-06-15 18:33:01] INFO retrieval: latency_ms=1780, query="合同违约金条款", top_k=5 [2024-06-15 18:33:01] DEBUG vector_db: index_size_mb=4200, cache_hit_rate=12%

根因分析：向量索引缓存失效，导致大量磁盘IO。常见于：

• 知识库批量更新后，索引未重建；
• 缓存容量不足，热点查询被挤出。

排查命令：

# 查看索引缓存命中率 redis-cli -h vector-cache info | grep "keyspace_hits\|keyspace_misses" # 检查索引文件修改时间 ls -la /vector/indexes/ | tail -5

修复动作：

1. 立即执行redis-cli -h vector-cache FLUSHALL清空缓存，强制重建；
2. 将向量缓存内存从2GB扩容至6GB；
3. 对高频查询词（如“违约金”、“解除合同”）预热缓存：redis-cli -h vector-cache SET "query:违约金条款" "cached_result"。

实操心得：向量检索性能70%取决于缓存，而非算法。我们要求所有知识库更新后，必须运行warmup_cache.py脚本。

5.6 问题六：Intent Recognition阶段准确率骤降，大量请求被错误路由

典型日志：

[2024-06-15 19:44:55] ERROR intent_recog: confidence=0.32, predicted="refund", actual="shipping_status" [2024-06-15 19:44:55] DEBUG intent_log: text="我的快递到哪了？"

根因分析：意图识别模型未及时更新，无法覆盖新出现的用户表达（如方言、网络新词、新业务术语）。

排查命令：

# 查看最近1小时低置信度请求 grep "confidence<0.5" intent.log | tail -20 | cut -d' ' -f8- | sort | uniq -c | sort -nr # 检查模型版本 cat /models/intent/version.txt

修复动作：

1. 将低置信度样本（confidence<0.5）自动加入intent_finetune_queue；
2. 每日凌晨2点，触发增量训练（仅用新样本微调最后2层）；
3. 临时启用“fallback to LLM”：当 confidence<0.4 时，交由大模型做二次判定。

提示：意图识别必须是“活”的模型。我们设定硬性规则：每周至少用100条新样本更新，否则CI失败。

5.7 问题七：整体Cost per Unit上升，但各层指标均正常

典型日志：

[2024-06-15 20:11:00] ALERT cost_monitor: cpu_trend=+18%, l