
老李 · AI 架构师视角 · 架构探讨稿

不识庐山真面目,只缘身在此山中。
业务侧常问:「你们怎么把大模型接到业务里?」答「接了 API、做了知识库、挂了几个 Tool」。听起来热闹,一上线就露馅。
老李踩过三坑:
DigitalHuman 早期 ASR→LLM→TTS 卡在约 2s;HeroDash 客服上量后,并发和口径一起爆。问题不在模型不够聪明,在调用边界没画清。先定「什么时候不该调模型」。
名不正,则言不顺。

横向对比:LangChain / LangGraph 给编排与状态机抽象;AgentX 用 DAG 编排 + MCP 工具调用 + 多模型 LLM API对齐能力,但不绑死框架。讲清「节点是什么、失败怎么回滚」,比背框架名管用。

LLM 负责说;RAG 负责有据;Agent 负责做事。Prompt 钉成可测契约。
纸上得来终觉浅,绝知此事要躬行。

为什么不全上 Agent?因为客服主路径往往是「查得到就答、查不到就转人工」——RAG + 拒答更稳、更便宜。为什么不全靠 RAG?因为改配置、拉监控、跑流水线带工具副作用,这时才上 Agent。
反直觉一句:Agent 越多,越要先砍 Agent。先证明直调或 RAG 不够,再加规划器。
善战者,求之于势。

边界规则老李常压成三句:
DigitalHuman 把 ASR/TTS 与 LLM 解耦,LiveKit 扛实时,延迟 2s→500ms。HeroDash 知识库与客服策略拆开,600+ 并发下可换模型供应商而不改业务协议。
工欲善其事,必先利其器。
用 Claude Code / Cursor 搭骨架时,固定顺序:
llm/ rag/ agent,写进配置,不写死在 Prompt。
操千曲而后晓声。
HeroDash 客服口径要求「有出处」。最小可测链路:
文档 → 按标题+语义块切分 → 向量召回 TopK
→ 交叉重排 → score < τ 则拒答
→ 否则:答案 + 引用片段 ID
Prompt 只许引用检索片段,禁止「根据常识补充」。评测不靠自建垂直评测平台——用黄金问答集 + 人工抽检 + 线上拒答率/转人工率。诚实讲:没有「幻觉评测中台」,有的是可回归用例与指标。
AgentX:规划器出 DAG;节点绑 MCP;短期记忆只存本轮状态与工具回执。对齐 LangGraph 状态机:失败可重试或转人工,禁止无限 ReAct。
同一意图至少两套 Prompt 并行;黄金集断言引用/拒答/禁字段。DigitalHuman 私有化时 Prompt 与路由进配置包,KA 可换模型不改契约。
实战分数看:能否复现一次拒答、一次工具失败恢复。
博观而约取,厚积而薄发。
换更强模型,不如先把「事实/行动/闲聊」分流做对。HeroDash 多模型(Llama3/Azure/Google)能扛 500 万+ 用户,靠的是协议稳定,不是单模型神话。

召回率好看没用,业务要的是「答错不如不答」。重排阈值与拒答文案,是客服可信度的一半。
可版本、可 diff、可黄金集回归。AgentX 把 Prompt 与 DAG/MCP 同库管理;别只聊「我调了温度参数」。

凡是过往,皆为序章。
一句话:LLM 生成,RAG 供据,Agent 行事;Prompt 写成可测契约,拒答与审计守住幻觉。
证据链:DigitalHuman 2s→500ms、99.9%、兴业/国泰/瑞众私有化;HeroDash 600+ 并发、500 万+ 用户;AgentX 用 DAG + MCP + 多模型,而不是无限聊天。

下次设计先画一张「意图路由图」,再钉一个拒答案例、一个工具失败恢复。能把这两刀讲清楚,比堆十个框架名更像架构师。