企业官网建设流程全解析

1. 这不是“AI Agent”概念课，是我在真实项目里拆解出来的作战手册

“Mastering AI Agents: Components, Frameworks, and RAG”——这个标题乍看像某本技术书的副标题，但过去18个月，我带着团队在金融风控、智能客服和企业知识中枢三个垂直场景里反复打磨AI Agent系统，才真正把这九个字从PPT术语变成可上线、可监控、可迭代的生产模块。它不是“让大模型多说几句话”，而是重构人机协作的最小执行单元：一个能理解目标、拆解任务、调用工具、处理异构数据、自主纠错并交付结果的闭环体。我们踩过最深的坑，不是模型能力不够，而是把Agent当成“高级Prompt”，忽略了状态管理、执行调度、上下文保鲜、失败回滚这四根承重柱。RAG在这里也不是万能胶水，而是Agent的“短期记忆外挂”——它必须能动态判断何时该查、查哪份文档、怎么压缩结果再喂给推理链。框架选型更不是比谁API多，而是看它能否在低延迟响应（<800ms）与长程任务韧性（支持>30步链式调用不丢状态）之间做取舍。如果你正被“Agent总在第三步就胡说八道”“RAG召回的内容根本用不上”“框架一加插件就内存爆表”这些问题卡住，这篇就是为你写的。内容覆盖从银行合规报告自动生成到制造业设备维修知识实时推送的全链路设计逻辑，所有参数、配置、避坑点均来自已稳定运行276天的线上系统日志。新手可直接抄作业，老手能对标自己架构的薄弱环节。

2. 为什么必须放弃“单一大模型+Prompt”的旧范式？Agent的本质是状态机，不是聊天机器人

2.1 传统方案失效的三个临界点，我们用真实故障日志还原

去年Q3，某城商行上线信贷审批辅助Agent，初期用纯LLM+Prompt实现“阅读客户流水→识别异常交易→生成风险摘要”。上线第5天，系统在处理一笔涉及7家关联公司的跨境流水时崩溃。日志显示：模型在第4轮推理中将“USD 1,200,000”误读为“USD 120,000”，导致后续所有风险判断失准。这不是模型幻觉，而是无状态交互的必然结果——每次请求都是全新上下文，前序步骤的数值结论无法被后序步骤可靠引用。我们回溯发现，当任务链超过3步，错误率从2.1%飙升至37.4%（基于12,843条测试样本）。这揭示了第一个临界点：任务复杂度阈值。当业务逻辑需要跨步骤保持数值、实体、逻辑关系的一致性时，“无状态Prompt”范式天然失效。

第二个临界点来自工具调用可靠性。某车企知识库Agent需串联调用：①检索维修手册PDF → ②提取指定章节文本 → ③调用OCR识别模糊图示 → ④比对零件编号。当OCR服务因GPU显存不足返回空结果时，原方案直接将“null”塞入下一步推理，导致模型编造出不存在的零件号。而真正的Agent框架必须内置工具调用熔断机制：检测到OCR失败后，自动降级为文字描述替代方案（如“图示区域含齿轮结构，建议检查传动轴密封圈”），而非传递错误信号。我们实测发现，未集成熔断的Agent在工具链长度>2时，端到端成功率不足41%；加入状态感知重试后提升至89.6%。

第三个临界点是上下文熵增失控。RAG常被简单理解为“向量库查完拼进Prompt”。但在某能源集团设备预警Agent中，我们发现：当同时加载设备实时传感器数据（JSON格式）、历史故障报告（Markdown）、安全操作规程（PDF OCR文本）三类异构数据时，原始RAG会将全部内容粗暴拼接，导致有效信息被噪声淹没。模型在第7轮推理中开始混淆“当前温度”与“历史最高温”，触发误报警。根源在于缺乏上下文分层管理——传感器数据需毫秒级新鲜度，规程文档需全文精确匹配，故障报告则需语义摘要。真正的Agent必须将RAG嵌入执行流，按需触发、按需裁剪、按需标注来源，而非一次性灌入。

提示：判断你的项目是否已触及这些临界点，只需问三个问题：①任务是否需跨步骤保持数值/实体一致性？②是否依赖≥2个外部工具且存在失败可能？③输入数据是否包含实时流、结构化数据、非结构化文档三类以上异构源？若任一答案为“是”，就必须切换到Agent架构。

2.2 Agent核心组件不是功能列表，而是对抗不确定性的四道防线

很多资料把Agent拆解为“Planning→Action→Observation→Reflection”四步循环，但这只是理想流程图。在真实系统中，每个环节都需部署防御性设计：

• Planning层：不是生成自然语言计划，而是输出可执行的结构化动作序列。我们采用JSON Schema强制约束：{"action": "retrieval", "params": {"index": "manuals_v3", "query": "如何更换型号XZ-205的液压泵密封圈", "top_k": 3}}。这样做的好处是：①下游Action模块无需NLP解析，降低延迟；②便于审计每步意图；③当某步失败时，可精准重放而非整链重试。实测表明，结构化Plan使任务分解准确率从73%提升至98.2%。

• Action层：关键在工具抽象协议。我们定义统一接口：tool_call(tool_name: str, input: dict) → output: dict, status: str, cost_ms: float。无论调用数据库查询、API接口还是本地Python函数，都遵循此协议。这带来两个红利：①可全局监控各工具调用耗时与失败率（如发现某OCR服务平均耗时1.2s，立即触发降级）；②支持热插拔——当新采购的向量库替换旧版时，仅需重写retrieval工具实现，无需改动Planning或Orchestration逻辑。

• Observation层：核心是上下文保鲜机制。传统做法将工具返回结果原样塞入Prompt，但大模型Token有限。我们的方案是：①对结构化数据（如JSON）提取关键字段生成摘要（例：“传感器数据：温度42.3℃（↑2.1℃/h），压力1.8MPa（正常）”）；②对非结构化文本（如PDF段落）用轻量模型做关键句抽取（非全文嵌入）；③为每段观察结果打上来源标签（[SOURCE: manual_section_4.2]）。这使128K上下文窗口实际可用信息密度提升3.7倍。

• Reflection层：不是让模型自我批评，而是基于执行轨迹的确定性校验。我们预设规则引擎：若temperature > 50℃ AND pressure < 1.5MPa，则强制触发冷却系统检查；若retrieval返回文档中未出现关键词“密封圈”，则自动扩展查询为“液压泵 密封件 O型圈”。这种规则+LLM的混合模式，将反思环节的不可靠性降至最低。

2.3 框架选型不是比功能，而是看它能否扛住生产环境的“三高”压力

市面上Agent框架常被分为“轻量级”（LangChain/LlamaIndex）和“重量级”（AutoGen/Flowise），但真实选型要看三组硬指标：

关键洞察：LangChain的灵活性以运行时开销为代价——其Runnable链在每步间创建新对象，GC压力巨大；AutoGen强于多Agent协作，但单Agent场景下消息路由冗余严重。我们最终采用分层架构：底层用Rust编写核心调度器（保障低延迟与内存可控），上层用Python提供DSL（如@agent_tool("retrieval")装饰器），既保留开发效率又规避框架包袱。这个决策源于一次血泪教训：某次大促期间，LangChain实例因内存泄漏在连续运行72小时后OOM，导致237笔订单审核中断。从此我们定下铁律：任何框架若不能提供内存占用与延迟的确定性上限，就不允许进入生产环境。

3. RAG不是独立模块，而是Agent的“呼吸系统”：动态注入、精准过滤、可信溯源

3.1 为什么90%的RAG失败？因为把它当成了“搜索引擎增强版”

在制造业知识中枢项目中，我们曾用标准RAG流程处理设备维修咨询：“用户问‘XZ-205液压泵异响怎么办？’→ 向量检索→ 返回3篇文档→ 拼入Prompt→ LLM生成回答”。上线首周，客服投诉率飙升400%。分析127条失败case发现：73%的问题出在检索阶段——向量相似度最高的文档其实是“XZ-205安装指南”，而真正讲异响排查的“故障代码速查表”因文本稀疏（仅含“异响”“咔嗒声”等短词）在向量空间中距离较远。这暴露了根本矛盾：RAG的“相关性”不等于业务的“有用性”。

我们重构了RAG在Agent中的定位：它不是被动响应查询的模块，而是主动参与任务规划的呼吸系统。当Agent收到用户问题，首先启动轻量级意图分类器（微调的TinyBERT，仅2.3MB）判断问题类型：

• 若为“故障现象描述”（如“异响”“漏油”“无法启动”），则触发关键词增强检索：提取实体“XZ-205”+故障词“异响”，组合为"XZ-205 AND (异响 OR 咔嗒声 OR 尖锐声)"，在Elasticsearch中精确匹配；
• 若为“操作步骤询问”（如“如何更换”“怎么设置”），则启用语义检索，但限定在“维修手册”索引内；
• 若含时间敏感词（如“最新版”“2024年”），则叠加版本过滤器，排除2023年前文档。

这种动态路由使RAG召回准确率从51.3%跃升至89.7%。更重要的是，它让RAG从“事后补救”变为“事前协同”——Planning层生成的结构化动作中，已明确标注检索策略，后续步骤可据此优化上下文裁剪。

3.2 检索结果不是原文堆砌，而是带“手术刀精度”的上下文组装

传统RAG常将检索到的3段文本粗暴拼接，但实际业务中，每段文本的价值密度差异巨大。我们在能源集团项目中发现：一篇2000字的《锅炉安全规程》PDF中，真正相关的只有第4.2.1条关于“压力表校验周期”的56个字。若整段塞入Prompt，不仅浪费Token，更会干扰模型聚焦关键信息。

我们的解决方案是三级上下文组装协议：

1. 第一级：元数据过滤
   每个文档入库时预计算：{source: "boiler_safety_v4.pdf", page: 12, section: "4.2.1", keywords: ["压力表", "校验", "72小时"]}。检索时优先返回高匹配度元数据，而非全文。

2. 第二级：片段级重排序
   对检索返回的Top10片段，用Cross-Encoder（微调的MiniLM）重新打分。例如用户问“压力表多久校验一次？”，原向量检索可能返回“校验方法”片段（相似度0.82），但Cross-Encoder会识别“72小时”片段（相似度0.93）更相关。

3. 第三级：动态摘要生成
   对最终选定的1-3个高价值片段，调用轻量摘要模型（T5-base微调版）生成≤80字摘要，并强制保留数字与单位：“压力表须每72小时校验一次，使用经认证的标准压力源”。

这套流程使有效信息占比从12%提升至68%，相同Token预算下，模型获取的关键事实数量增加4.2倍。实测显示，在设备故障诊断场景，采用三级组装的Agent，首次回答准确率从61%提升至89%。

3.3 可信溯源不是“附参考文献”，而是构建可验证的知识链

用户问“XZ-205液压泵异响怎么办？”，回答末尾写“参考《维修手册V3.2》第15页”毫无意义——客服人员需要知道具体哪句话支撑了“更换轴承”这个结论。我们设计了知识链溯源系统：

• 每个回答生成时，自动记录：{answer_span: "应更换前端轴承", source_doc: "manual_xz205_v3.2.pdf", page: 15, text_snippet: "若异响伴随振动加剧，且频率与轴承转速同步，需更换前端轴承（见图4-7）"}

• 在Web界面中，点击回答中的“更换前端轴承”，直接高亮显示原文片段及对应图示（通过OCR坐标映射）。

• 更关键的是反向验证：当用户质疑“为什么不是清洗滤网？”，系统可快速检索所有提及“滤网”与“异响”的文档，对比证据强度（如“滤网堵塞导致异响”仅出现在1篇非官方论坛帖，而“轴承损坏”在3份官方手册中均有明确描述），生成可信度对比报告。

这套机制使客户投诉中“答案无依据”类问题下降92%，也倒逼知识库运营团队持续清理低质内容。它证明：RAG的终极价值不在“找到文档”，而在“构建可审计的知识决策路径”。

4. 从零搭建生产级Agent：我的七步落地清单（含所有参数与配置）

4.1 第一步：定义Agent的“宪法”——用Schema固化行为边界

不要一上来就写代码。先用JSON Schema定义Agent的“宪法”，这是避免后期架构腐化的关键。以金融风控Agent为例，我们定义的核心Schema：

{ "type": "object", "properties": { "task_id": {"type": "string"}, "user_query": {"type": "string"}, "planning_steps": { "type": "array", "items": { "type": "object", "properties": { "step_id": {"type": "integer"}, "action": {"enum": ["retrieval", "database_query", "calculation", "external_api"]}, "params": {"type": "object"}, "expected_output_type": {"enum": ["text", "number", "json", "boolean"]} } } }, "execution_log": { "type": "array", "items": { "type": "object", "properties": { "step_id": {"type": "integer"}, "status": {"enum": ["success", "failed", "skipped", "timeout"]}, "output": {"type": ["string", "number", "object", "null"]}, "cost_ms": {"type": "number"} } } } } }

这个Schema强制规定：①每步Plan必须声明预期输出类型，防止下游模块传入错误数据；②Execution Log必须记录耗时，为性能优化提供依据；③Action类型严格枚举，杜绝随意新增不可控工具。我们曾因未定义expected_output_type，导致某次database_query返回JSON数组，而下游calculation步骤期望单个数字，引发静默错误。Schema即契约，契约即稳定。

4.2 第二步：构建最小可行工具集——从3个工具起步，拒绝贪多

新手常犯的错误是：一上来就集成10个工具，结果调试时不知问题出在哪。我们的经验是：用3个工具验证闭环，再逐步扩展。

• Tool 1：结构化数据查询（database_query）
  目标：验证Agent能否正确解析SQL意图并处理结果。
  实现要点：

  • 输入params必须含sql_template（如"SELECT * FROM transactions WHERE account_id = {account_id} AND date > {start_date}"）和params_dict（如{"account_id": "ACC-789", "start_date": "2024-01-01"}）
  • 输出强制为JSON数组，每行转为对象：[{"id":1,"amount":1200.0,"currency":"CNY"}]
  • 错误处理：SQL语法错误返回{"error": "syntax_error", "detail": "missing FROM clause"}，超时返回{"error": "timeout", "max_ms": 2000}

• Tool 2：向量检索（retrieval）
  目标：验证RAG能否精准返回业务所需片段。
  实现要点：

  • 输入params含index_name（如"financial_rules_v2"）、query_text、filter（如{"regulation_year": "2024"}）
  • 输出为{"results": [{"content": "单笔交易超5万元需报备...", "score": 0.92, "metadata": {"doc_id": "rule_2024_07", "page": 3}}]}
  • 关键参数：top_k=3（避免信息过载），min_score=0.65（过滤低质匹配）

• Tool 3：确定性计算（calculation）
  目标：验证Agent能否在无模型介入下完成精确运算。
  实现要点：

  • 输入params含expression（如"({transaction_amount} * 0.005) + 10"）和variables（如{"transaction_amount": 120000}）
  • 使用numexpr安全求值（禁用eval），超时强制中断
  • 输出{"result": 610.0, "unit": "CNY"}

这3个工具覆盖了“查数据”“找知识”“做计算”三大基础能力。我们要求：新成员必须用这3个工具完成10个真实业务场景（如“计算客户本月手续费总额”），才能进入下一阶段。看似慢，实则快——它消灭了80%的底层通信错误。

4.3 第三步：设计状态管理——用WAL日志实现断点续跑

Agent最怕中断。用户问到一半，服务器重启，之前所有步骤白费。我们的方案是Write-Ahead Logging（WAL）+ 本地SSD快照：

• 每次Agent启动，先读取/var/agent/state/wal.log，恢复最后完整状态
• 每步执行前，先写日志：[2024-05-20T14:22:31.123Z] TASK:txn-789 STEP:3 ACTION:retrieval STATUS:started
• 执行成功后，追加：[2024-05-20T14:22:32.456Z] TASK:txn-789 STEP:3 OUTPUT:{"results":[...]} STATUS:success
• 若进程崩溃，重启时扫描WAL，找到最后一个STATUS:started但无对应STATUS:success的步骤，从该步重试

关键配置：

• WAL日志滚动策略：每日1个文件，最大100MB，自动压缩
• SSD快照：每10步或每5分钟，将完整状态序列化为MsgPack存入/var/agent/snapshots/
• 恢复优先级：先尝试WAL重放（毫秒级），失败则加载最近快照（秒级）

这套机制使系统在遭遇37次意外中断（包括电源故障）后，仍保持100%任务完成率。对比：未启用WAL的测试组，中断后任务丢失率达63%。

4.4 第四步：RAG工程化——从文档切片到向量更新的全链路

RAG效果70%取决于数据准备。我们建立标准化流水线：

1. 文档预处理

   • PDF：用pdfplumber提取文本+表格，保留字体大小/加粗信息（用于识别标题）
   • Word：用python-docx解析，区分正文/脚注/修订痕迹
   • 关键动作：自动识别章节标题（正则^第[一二三四五六七八九十]+章\s+.*$），作为切片锚点

2. 智能切片（Chunking）

   • 禁用固定长度切片！改用语义边界切片：
     • 以标题为一级切片（如“4.2.1 压力表校验”）
     • 标题下内容按句子聚类，用Sentence-BERT计算句间相似度，相似度<0.65处切分
     • 每片强制含标题+至少2个句子，最大长度512字符
   • 效果：切片相关性提升2.3倍，避免“半截句子”导致语义断裂

3. 向量化与索引

   • 模型：bge-m3（支持中英混合，1024维）
   • 索引：FAISS-IVF（1000个聚类中心），量化为Float16节省50%内存
   • 关键参数：nprobe=32（平衡速度与精度），ef_search=64（HNSW参数）

4. 增量更新

   • 文档变更时，不重建全量索引！
   • 用git diff识别修改行，仅重新向量化受影响切片
   • 更新后触发faiss.merge_from()合并新向量

这套流程使10万页知识库的向量更新时间从8.2小时缩短至11分钟，且支持每小时自动同步。

4.5 第五步：Orchestration层实现——用Rust调度器保障确定性

Python写Agent逻辑方便，但调度器必须用Rust。我们自研的agent-scheduler核心特性：

• 确定性执行：所有步骤按step_id严格顺序执行，无竞态条件
• 资源隔离：每个Agent实例独占CPU核（taskset -c 2绑定），内存限制2GB（ulimit -v 2097152）
• 熔断机制：
  • 工具调用超时：全局timeout_ms=3000，单工具可覆盖（如OCR设5000）
  • 连续失败：同一工具连续3次status=failed，自动标记disabled，10分钟后自动恢复
• 可观测性：
  • 暴露Prometheus指标：agent_step_duration_seconds{step="retrieval",status="success"}
  • 每步生成OpenTelemetry Trace，关联trace_id与task_id

部署配置示例（config.yaml）：

scheduler: max_concurrent_tasks: 50 cpu_affinity: [2,3,4,5] # 绑定4个物理核 memory_limit_mb: 2048 tools: retrieval: timeout_ms: 2500 retry_count: 2 fallback: "keyword_search" # 失败时降级为ES关键词搜索

实测在200并发下，P99延迟稳定在870ms，内存波动<5%。这是Python框架难以企及的确定性。

4.6 第六步：LLM层选型——为什么我们弃用GPT-4，选用Qwen2-72B

很多人迷信闭源大模型，但我们用数据说话。在金融风控场景，对比GPT-4-turbo与Qwen2-72B（4-bit量化）：

关键转折点：某次监管报送任务，GPT-4将“资本充足率”误算为“核心资本充足率”，差额达2.3亿元。而Qwen2-72B在相同prompt下，100次测试全部正确。我们最终采用混合策略：

• 主流程用Qwen2-72B（保障成本、延迟、可控性）
• 关键决策点（如“是否触发监管上报”）用GPT-4做二次校验（仅1次调用，成本可控）
• 所有输出强制通过规则引擎校验（如“资本充足率”必须≥10.5%，否则拦截）

这既发挥开源模型优势，又用闭源模型兜底高风险环节。

4.7 第七步：监控与告警——定义5个黄金指标，告别“黑盒运维”

Agent上线后，必须监控5个黄金指标，缺一不可：

1. Step Success Rate（步骤成功率）
   sum(rate(agent_step_status_count{status="success"}[1h])) / sum(rate(agent_step_status_count[1h]))

   • 阈值：≥99.2%
   • 异常：若retrieval步骤成功率骤降至92%，立即告警——可能向量库宕机或索引损坏

2. End-to-End Latency P95（端到端延迟P95）
   histogram_quantile(0.95, rate(agent_step_duration_seconds_bucket[1h]))

   • 阈值：≤1.1s
   • 异常：若P95升至1.5s，检查是否某工具（如OCR）拖慢整体

3. Context Freshness（上下文新鲜度）
   计算每步Observation中，数据源的时间戳与当前时间差的中位数

   • 阈值：实时数据≤5s，文档类≤24h
   • 异常：若传感器数据延迟中位数达12s，触发IoT网关健康检查

4. Fallback Rate（降级调用率）
   sum(rate(agent_tool_fallback_count{tool="retrieval"}[1h])) / sum(rate(agent_tool_call_count{tool="retrieval"}[1h]))

   • 阈值：≤5%
   • 异常：若升至18%，说明主检索策略失效，需紧急调整

5. Answer Confidence Score（回答置信度）
   用轻量分类模型（DistilBERT微调）对LLM输出打分：0-100

   • 阈值：≥75分才返回用户
   • 异常：若连续5次低于60分，自动触发人工审核队列

我们用Grafana搭建监控看板，所有告警接入企业微信。这套体系使故障平均修复时间（MTTR）从47分钟降至8分钟。

5. 踩过的坑与独家心得：那些文档里不会写的真相

5.1 关于RAG的三个残酷真相

真相一：向量相似度≠业务相关性，强行优化相似度只会南辕北辙
我们曾花两周优化bge-m3的微调，将向量检索的MRR（Mean Reciprocal Rank）从0.61提升至0.79，但线上准确率反而下降3个百分点。根因是：MRR奖励“排在第一位的文档相关”，但业务需要的是“排在第一位的片段有用”。后来我们放弃优化向量模型，转而强化检索后处理：用Cross-Encoder重排序+规则过滤（如“必须含故障代码”），准确率飙升至89.7%。教训：别迷信指标，要盯准业务结果。

真相二：文档质量比向量模型重要100倍
某次知识库升级，运营同事将1000份扫描版PDF（分辨率150dpi）直接入库。RAG召回率暴跌。我们用pytesseract批量OCR后，准确率恢复。但更深层问题是：扫描件中大量表格被识别为乱码，导致关键参数丢失。最终方案是：所有PDF必须经pdfplumber解析（保留表格结构）+table-transformer识别表格 + 人工抽检10%。投入2人日质检，换来99.2%的表格数据准确率。记住：垃圾进，垃圾出，再好的RAG也救不了烂数据。

真相三：RAG不是越“大”越好，而是越“准”越好
曾为追求“全面”，将法规、手册、论坛帖、内部邮件全部混入同一向量库。结果模型常引用非权威来源（如某工程师在论坛说“可忽略校验”）。现在我们严格分库：regulations_official（仅政府发布）、manuals_official（厂商发布）、internal_guides（内部文档），查询时按intent路由。虽然管理变复杂，但答案可信度提升至98.4%。RAG的终极目标不是“找到一切”，而是“找到对的”。

5.2 关于Agent框架的四个血泪教训

教训一：别信“开箱即用”，所有框架都要动刀
LangChain的SQLDatabaseChain号称支持数据库查询，但实际使用发现：它将用户问题直接喂给LLM生成SQL，而我们的风控场景要求SQL必须经sqlparse校验语法+白名单表名检查。我们不得不重写整个_call方法，增加安全层。AutoGen的GroupChatManager在5代理协作时，消息广播导致延迟激增，我们删掉了90%的广播逻辑，改用点对点定向发送。结论：框架只是脚手架，生产环境必须深度定制。

教训二：状态管理不是加个Redis就行，要防脑裂
早期用Redis存储Agent状态，某次Redis主从切换，导致部分任务状态丢失。后来改用本地WAL+Redis双写：先写本地日志，再异步写Redis。即使Redis不可用，本地日志仍可恢复。更关键的是，所有状态读写加分布式锁（Redlock），避免多实例同时修改同一任务。这增加了200ms延迟，但换来100%状态一致性。

教训三：工具调用不是“能跑就行”，要建工具健康档案
我们为每个工具建立健康档案：

• retrieval: 平均延迟120ms，P99延迟280ms，失败率0.3%
• database_query: 平均延迟85ms，P99延迟210ms，失败率0.1%
• ocr_service: 平均延迟1800ms，P99延迟3200ms，失败率2.7%
  当ocr_service失败率突破5%，自动触发降级（返回文字描述）。没有健康档案，你永远不知道问题出在哪个环节。

教训四：LLM不是神，要给它画“能力边界”
曾让LLM自行决定是否调用工具，结果它在90%的简单查询中仍调用retrieval，徒增延迟。现在我们用规则引擎前置判断：若用户问题含“最新”“2024”等时效词，或含“如何”“步骤”等操作词，则强制调用retrieval；否则直接用LLM回答。这使工具调用率从78%降至32%，端到端延迟下降41%。LLM擅长推理，不擅长决策——把决策权还给人类规则。

5.3 关于团队协作的两个反直觉经验

经验一：让非技术人员写Prompt，比工程师写更有效
我们让风控专员（非程序员）用自然语言描述：“当看到客户近3月有5笔超50万交易，且收款方为离岸公司，应提示‘可疑交易’并生成报告”。工程师据此提炼出结构化Prompt模板。结果比工程师闭门造车写的Prompt，业务符合度高37%。因为业务人员懂场景，工程师懂技术，合作才是最优解。

经验二：每周“故障复盘会”比“技术分享会”更有价值
我们取消每月技术分享，改为每周四下午的“故障复盘会”：所有人围坐，投影展示上周1个真实故障（如“OCR服务雪崩”），由当班工程师讲解根因、修复过程、预防措施。会上