如果把知识库只看成 RAG，Claude 的位置通常会被放在最后：检索拿到片段，模型生成答案。

工程上这当然能跑。但从架构评审的角度看，这个方案少了一层很关键的东西：知识资产的加工层。

没有这层，系统会变成“把脏数据检索出来，再期待强模型把它讲清楚”。这不是架构，是碰运气。

先看一个反例

很多团队的第一版知识库大概长这样：

问题不在 Claude，而在向量库到检索之间太薄了。

文档切块如果只按字数来做，标题、条件、版本、例外、业务对象都会混在一起。后面检索命中了一个片段，也不一定命中了真正能回答问题的知识。

这时把 Claude 放在 E，只是在最后补救。

我更推荐的分层

更合理的设计是把知识库拆成两条链：一条离线加工链，一条在线问答链。

Claude 更适合放在知识块/规则/标签/摘要和高风险复核，而不是只放在回答模型。

为什么不是全链路 Claude

因为知识系统里有很多任务不值得用高能力模型。

比如去页眉、去空行、统一 Markdown、普通短文本分类、低风险问答，这些任务用便宜模型或者规则就够了。Claude Opus 4.7、Claude Sonnet 4.6 这种模型，应该留给需要长上下文理解和复杂判断的步骤。

Anthropic 官方文档里，Opus 4.7 和 Sonnet 4.6 都支持 1M token 上下文。这个能力真正值钱的地方，不是“把更多内容塞进 prompt”，而是让模型在加工阶段理解完整文档结构，再输出更可控的中间结果。

路由应该按节点写

一个更工程化的路由配置可以长这样：

routes:
  normalize_markdown:
    model: low_cost
    retry: 1

  build_knowledge_card:
    model: claude-sonnet-4-6
    output: json_schema

  extract_policy_exception:
    model: claude-opus-4-7
    output: json_schema

  simple_qa:
    model: fast_model

  answer_risk_review:
    model: claude-opus-4-7
    trigger:
      - legal
      - finance
      - customer_commitment

这里的关键是：模型策略跟业务节点绑定，而不是跟“知识库”这个大词绑定。

接口别散在业务代码里

按节点路由之后，另一个问题会自然出现：模型入口会越来越多。

今天前处理用 Claude，明天普通问答换成更快的模型，后天高风险复核加一层 fallback。如果每个节点都自己写接口，后面查日志、控成本、换模型都会变成重复劳动。

所以这里需要一个稳定的模型出口。团队可以自建网关，也可以直接用 147AI 这类聚合平台，把 GPT、Claude、Gemini 等模型先收在一层。它对工程侧比较实际的价值，不是“模型列表更长”，而是三件事：OpenAI 兼容接口能减少迁移成本；路由、fallback 和日志可以集中处理；文本、图像、音频等多模态能力后续也能走同一个入口。

这句话听起来像基础设施问题，但它会直接影响知识系统能不能长期维护。模型会换，路由策略会改，业务代码最好少跟着动。

结论

Claude 在知识链路里最适合接两段：

第一段是离线知识加工，把文档变成更干净的知识资产。第二段是高风险复核，避免模型把不确定内容说死。

如果只把 Claude 放在问答出口，它会很忙，但未必最有价值。