能力边界与应用架构

• 理解四类问题的本质差异
• 理解各自不同的缓解手段
• 能分类治理

四类问题本质不同：幻觉——模型生成与事实不符的内容（无证据的编造），缓解靠 RAG 证据约束、约束解码、证据校验、拒答阈值；知识过期——模型知识截止时点早于当前，缓解靠注入最新知识（RAG/实时检索）、标注知识时间、回退到检索；引用失真——模型引用了不存在的来源或断章取义，缓解靠强制引用校验（引用必须来自提供证据）、来源可信度排序、引用匹配检测；采样不稳定——同一输入多次输出不同（随机性），缓解靠降低 temperature、固定 seed、缓存可复现结果、规则后处理。诊断方法：先判断"内容是否与给定证据一致"（幻觉/引用失真），再判断"是否因知识时点"（过期），最后判断"是否因随机采样"（不稳定）。核心是"按根因分类，再对症下药"。

四类问题经常被混为一谈，但缓解手段完全不同。幻觉靠证据约束，过期靠最新知识注入，引用失真靠引用校验，不稳定靠采样控制。先诊断根因再治理。

• 理解确定性任务与概率性任务的本质差异
• 理解划界原则
• 能设计划界与兜底

划界原则：凡是有明确、可验证、不可出错的计算规则（订单金额、税费、权限、日期换算、单位换算）必须用确定性代码实现，绝不能交给模型——因为模型是概率性的，会出错且无审计保证。而意图分类、文案生成、语义理解这类"没有唯一正确答案、需要理解"的任务才适合模型。判断标准：一是是否有确定性算法（有则用代码）；二是是否可自动验证（金额可校验则用代码）；三是错误的代价（财务/权限错误不可接受则用代码）。模型只用于"开放性、无精确解"的部分。划界后：即便模型参与，也要在确定性结果上做代码兜底校验（如模型提取金额后由代码做算术与格式校验）。核心是"确定性优先代码，模型只做开放性任务，且确定性结果由代码兜底"。

划界的本质是"错误成本"与"确定性"。金额、权限错误成本高且可精确计算，绝不能依赖模型。模型只用于开放性问题，且关键结果用代码校验。

• 理解高风险决策的边界
• 理解人工审批与责任
• 理解可解释性要求

绝不能由模型独立完成的决策：涉及重大财务后果（大额转账、自动扣款、放贷）、法律效力的决定（合同签署、法律文书）、人身安全（医疗诊断、自动驾驶决策、安全拦截）、对用户的重大影响（账号封禁、征信、信用评估）、以及监管要求强制人工审批的领域。这些决策必须：一是人工签字——设置"模型建议 + 人工审批"流程，模型输出作为建议，必须由有权限的人确认才生效；二是可解释日志——记录模型的输入、输出、置信度、依据、人工审批人、时间，形成完整审计链；三是责任归属——人机责任边界明确，模型负责"建议"，人负责"决策"。核心是"高风险决策保留人工审批 + 完整可解释日志 + 责任归属"。

模型是概率性的，不能承担不可逆、高风险、强监管的决策责任。凡是后果严重、需要追责的决策，必须有人工签字环节，且日志要可解释可审计。

• 理解 PoC 与生产的差异
• 理解迁移中的变更管理
• 能设计评审与降级

PoC 目标是"验证可行性"，生产目标是"稳定、可观测、可审计"。迁移设计：模型替换——PoC 用示例模型，生产必须选型（质量/成本/延迟），用评估卡对比并灰度切换；Prompt 重写——PoC 的 prompt 通常粗糙，生产要结构化（system 指令、护栏、输出格式契约束），并做契约测试与缓存友好调整；能力降级——生产必须定义降级路径（模型故障、超限、低置信时降级到备用模型/缓存/人工），PoC 不可用报错即可；评审制度——生产上线需评审：数据合规、安全护栏、成本预算、可观测性、人工兜底、责任边界。迁移通常分阶段：PoC -> 影子 -> 灰度 -> 全量，每阶段有门禁。核心是"生产化四要素：模型选型、Prompt 结构化、降级路径、评审门禁"。

PoC 求"能用"，生产求"可靠"。迁移不是改配置，而是引入工程成熟度：模型可替换、Prompt 可维护、能力可降级、评审可追溯。阶段化 + 门禁是关键。

• 理解同步与异步的适用场景
• 理解异步任务的要素
• 能设计转换决策

同步等待：请求耗时短（如秒级以内）、结果即时、用户需要即时反馈、交互式（聊天、流式补全）时用同步；异步任务：请求耗时长（如几秒到几分钟）、结果不确定、无法忍受长时间占用连接、需要后台执行（批量、长文生成、复杂工具链）时用异步。异步任务要素：状态查询（task_id + pending/running/succeeded/failed）、通知（完成回调/Webhook/轮询）、取消（可中止并停计费）。转换决策依据：预计耗时（P99 是否超交互预算）、是否阻塞关键路径、用户是否需要等待结果操作。对"可能快也可能慢"的请求，可先同步快速路径，超时则转异步。核心是"按耗时与交互性选择同步/异步，异步需给状态查询、通知、取消三能力"。

同步 vs 异步本质是"延迟预期 vs 交互需求"。耗时短且需即时用同步，耗时长则转异步并补齐状态/通知/取消。关键是给异步任务完整操作能力。

• 理解四类异常的处理差异
• 理解分层回退策略
• 能设计人工审核流程

四类异常策略：低置信——输出置信度低于阈值时，先尝试增强（更强模型、更多证据），仍低则转人工审核并提示不确定性；无证据——模型无法从证据支撑回答时，拒答或要求澄清，而非硬编，重要决策转人工；模型超时——重试（谨慎）后仍超时，降级到备用模型/缓存结果，或返回部分结果并提示；Provider 故障——断路器熔断后降级到备用 Provider，备用也失败则返回错误并排队/告知。分层回退：按"增强 -> 降级 -> 人工 -> 拒答"分层，先尝试低成本恢复，再降级，最后人工兜底。人工审核用于高风险、低置信、无证据的决策。核心是"分层回退 + 人工兜底，异常按类型差异化处理"。

四类异常性质不同：低置信/无证据是"质量不足"，超时/故障是"可用性不足"。质量不足转人工或拒答，可用性不足降级或排队。分层回退让恢复路径有序。

• 理解影子流量与灰度放量
• 理解特性开关与自动回滚
• 能设计发布流程

发布流程：一是影子流量——生产流量复制到新模型/Prompt，不返回给用户，用于对比质量、延迟、成本，评估行为差异；二是特性开关——把新模型/Prompt 的启用做成开关（feature flag），可随时开启/关闭，不依赖代码发布；三是灰度放量——按租户/流量百分比逐步把流量切到新版本，监控指标；四是自动回滚——设置质量/错误率/延迟阈值，超阈值自动切回旧版本，或关闭特性开关。发布顺序：影子评估 -> 灰度 1% -> 10% -> 50% -> 100%，每阶段有门禁与回滚阈值。核心是"影子验证 + 开关可逆 + 灰度渐进 + 自动回滚"。

模型/Prompt 变更是高风险变更，必须可回滚。特性开关解决"可逆"，影子解决"预验证"，灰度解决"渐进"，自动回滚解决"出事兜底"。四者构成安全发布。

• 理解分级审计的层次
• 理解白名单/灰名单/黑名单的判定
• 能设计审计流程

分级审计：白名单——低风险、高确定性、结果可自动校验的输出直接自动通过（如常见分类、格式转换），不加人工；灰名单——中风险或低置信的输出进入人工抽检，按比例/信号抽样审核；黑名单——高风险或触发规则（敏感、财务、法律）的输出必须人工审批才能放行。判定依据：风险等级（影响范围）、置信度、是否可自动验证、是否触发敏感规则。管理：白名单可自动校验（schema 校验、规则校验）来决定是否放行；灰名单用抽样（如 5% 或按置信度分层抽样）结合人工复审；黑名单强制人工。审计链要完整记录每类输出的判定依据与审核人。核心是"按风险分层，白名单自动、灰名单抽检、黑名单强制人工"。

审计成本与风险需要平衡。白名单省人工，灰名单平衡成本，黑名单保安全。分层依据是"风险 + 置信 + 可校验性"，让人工聚焦高风险。

• 理解应用层幻觉治理手段
• 理解各手段的适用场景与组合
• 能设计组合策略

应用层手段（不重训）：证据校验——要求模型输出附带证据，用检索/知识库校验输出中的事实是否被支持，不支持的给出标记或修正；拒答阈值——设置置信度/证据覆盖阈值，低于阈值时拒答或声明不确定，而非硬编；约束解码——用结构化输出/grammar 约束模型只能生成合法格式（如 JSON），减少格式类幻觉；二次校验——用另一个模型/规则对输出做一致性复核；人工复核——对高风险、低置信输出人工审核。组合策略：用约束解码保证格式，用证据校验保证事实，用拒答阈值处理不确定，用人工复核兜底高风险。按"风险等级"动态组合：低风险走约束+证据校验，高风险加人工。核心是"证据校验管事实、拒答阈值管不确定、约束解码管格式、人工复核管兜底"。

幻觉无法靠提示词根除，但应用层可组合治理。证据校验是核心（绑定来源），拒答阈值处理"不知道"，约束解码处理"格式乱"，人工复核处理"高风险"。四者按风险组合。

• 理解两种集成方式的本质差异
• 理解 SLA、责任、定价、可观测性的差异
• 能选择集成方式

"模型即产品"：模型被封装为面向用户的产品功能，平台对模型输出质量、准确性、用户体验负全责，SLA 覆盖端到端（含 prompt、网关、模型），定价打包进产品（订阅/按次），可观测性由平台自建（质量、延迟、成本全链路）。"模型即服务"：平台只提供模型调用能力（API），责任边界到"模型调用成功/失败"为止，输出质量由调用方负责，SLA 只覆盖模型可用性（如 99.9% 调用可用），定价按 token 计费，可观测性由 Provider 提供 usage 而业务侧由调用方自建。区分要点：模型即产品=平台对最终结果负责，模型即服务=平台只对调用负责。选择：产品型（承担质量、端到端 SLA）vs 服务型（透明 token 计费、调用方自担质量）。

两种模式的差异在"责任止于何处"。模型即产品把质量责任与定价包装进产品，模型即服务把责任边界收敛到调用层并按 token 计价。SLA 与可观测性随之不同。

• 理解确定性/概率性路径的划分
• 理解架构标注与故障隔离
• 能设计独立恢复

标注：架构图中用明确符号/颜色区分两类路径——确定性路径（规则引擎、数据库、计算）用实线/固定色，概率性路径（模型调用、RAG、生成）用虚线/不同色，并在图上标注"任一路径不可用时另一路径的降级行为"。故障演练按路径独立恢复：确定性路径故障（DB 挂、规则引擎挂）与概率性路径故障（模型超时、Provider 故障）是不同故障，应分别演练——确定性路径故障演练"缓存/副本/降级规则"，概率性路径故障演练"降级备用模型/缓存结果/拒答"。设计上把两路径解耦：确定性路径不依赖模型，模型路径不阻塞确定性操作，失败时各自独立降级。核心是"图面清晰标注两类路径 + 故障按路径独立设计与演练"。

确定性路径与概率性路径的可靠性特性不同，故障模式也不同。架构图标注让"谁依赖谁"清晰，故障演练按路径隔离，保证一条路径故障不影响另一条。

• 理解三种手段的适用场景
• 理解决策信号
• 能建立选型决策树

决策信号：该用 RAG 的信号——任务依赖"外部/动态/私有知识"（时效性、领域知识、企业数据），模型已知信息不足，需要"最新或特定来源"支撑，此时应检索增强；该优化提示词的信号——任务知识充分、仅是表达/格式/指令不清晰，模型已懂但输出不符合要求，此时优化 prompt（结构化指令、few-shot、输出约束）；该用应用内置能力/代码的信号——任务有确定性规则、可精确计算、或不该由模型承担（金额、权限、格式转换），此时用代码/规则实现，模型只做"理解"部分。决策树：先问"是否有确定性算法"→是则用代码；再问"是否依赖外部/动态知识"→是则 RAG；再问"是否只是表达/格式问题"→是则优化 prompt。核心是"按信号分流：确定性→代码、外部知识→RAG、表达问题→Prompt"。

选型先排除确定性（代码），再按"知识来源"（RAG）与"表达/指令"（Prompt）分流。RAG 解决"知识不足"，Prompt 解决"表达不对"，代码解决"确定性计算"。

• 理解概率性输出的风险沟通
• 理解把不确定转化为指标
• 能设计可验收指标

解释：向产品方说明模型输出是概率性的，同一输入可能不同结果，存在错误率、幻觉率、不一致率，不能当作确定性系统。把"不确定"转化为可验收指标：定义质量指标——准确率、错误率、幻觉率、指令遵循率、置信度分布、不一致率；给定验收阈值（如"分类准确率 ≥ 95%"、"关键字段错误率 ≤ 1%"）；用评估集持续度量并给出波动范围。把"模糊的担忧"变成"可测量的目标"，让产品方验收有依据。同时说明缓解手段带来的指标提升（RAG 降低幻觉率、人工兜底覆盖高风险）。核心是"把概率性风险翻译成量化指标 + 给出验收阈值 + 提供缓解提升"。

产品方怕"不确定"，与其空谈风险，不如把不确定变成可测指标与阈值。量化错误率、给出验收标准、展示缓解效果，把焦虑转为可管理目标。

• 理解确定性方案的适用场景
• 理解生成模型的开销与风险
• 能判断何时不用模型

应直接使用确定性方案而不引入生成模型的场景：数据可精确查询（用数据库/SQL 直接取，无需模型）；规则可明确表达（用规则引擎/代码，如打折、权限、路由）；需要精确匹配/检索（用搜索/嵌入式向量检索，而非生成）；结果必须可复现、可校验、低延迟低成本（确定性方案满足）；错误不可接受（模型会错，代码不会）。判断标准：一是答案是否"存在且可精确获取"（是则查询）；二是规则是否可枚举（是则规则引擎）；三是是否需要"理解/生成新内容"（才用模型）。模型只应在"需要理解语义、生成、开放问答"时引入。核心是"能精确/确定完成的任务用代码/查询/规则，模型只做需要理解与生成的部分"。

生成模型是"理解+生成"方案，开销大、有幻觉、难审计。凡能精确查询、规则表达、确定匹配的任务，用确定性方案更可靠、更便宜、更可审计。

• 理解统一保险 Prompt 的弊端
• 理解护栏设计的原则
• 能设计分层护栏

弊端：统一加"保险 Prompt"对所有请求一视同仁，导致——低风险简单任务也被施加强约束（冗余、延迟、成本上升）；不同任务无从区分，"谨慎"在不同场景语义不同，反而引入不一致；且依赖"模型自觉遵守一句话"，无法保证强约束场景真的被约束。正确护栏设计：按场景/风险分层——高风险任务用强约束（结构化输出、拒答阈值、人工审批、内容过滤），低风险任务用轻约束（轻提示）；用"声明式护栏"而非"解释性提示"——用 schema、规则、工具、内容过滤、敏感词、人工审批等硬约束，而非仅靠提示词；把护栏做成可配置的防护层，按任务风险动态启用。核心是"按风险分层护栏，用硬约束代替解释性保险 Prompt"。

统一保险 Prompt 是"一刀切"，违背"按风险差异化"的护栏原则。正确设计是分层 + 硬约束（schema、过滤、审批），而非依赖一句"请谨慎"。

• 理解如何量化不稳定
• 理解分层兜底机制
• 能设计回应与改进

回应：一是把"不稳定"量化——定义并在评估集上持续测量准确率、错误率、波动范围、置信度分布，展示"哪些场景稳定、哪些波动"，把主观质疑转成数据；二是说明波动来源——采样随机、模型版本、上下文变化，并展示已做的缓解（降 temperature、固定 seed、缓存）；三是分层兜底——对高风险/关键业务加人工审批、二次校验、规则校验，把"不稳定"隔离在可接受范围；四是持续改进——用评估集跟踪，按数据优化 prompt、加 RAG、调阈值，展示指标趋势。核心是"用量化指标回应主观质疑 + 分层兜底隔离风险 + 持续改进趋势"。

业务方质疑"不稳定"是合理但不精确。工程团队应把"不稳定"翻译成可测量的指标与风险控制，并展示兜底机制与改进趋势，把抱怨变成协作。

• 理解收益的量化维度
• 理解 A/B 与基线对比
• 能设计收益度量

衡量前先定义基线（引入 AI 前的指标）与处理口径（是否含人工成本、延迟、错误成本）。收益维度：节省时间——AI 完成单位任务耗时 vs 人工耗时，乘以任务量算节省总工时；提升准确率——AI 的准确率 vs 基线准确率，算错误率下降带来的价值（如减少返工、客服成本）；转化——对业务漏斗指标（如 AI 客服的解决率、推荐的点击/转化）做 A/B 实验对比。方法：A/B 测试（实验组用 AI，对照组基线，比较关键指标）+ 成本核算（AI 的 token/算力成本 vs 人工/替代方案成本）+ 边际分析（"多投入一单位 AI 带来多少收益"）。核心是"基线对比 + A/B + 全成本核算，算边际收益而非总收入"。

边际收益要"对比基线"且"算清成本"。A/B 测转化、工时测量省时间、错误率测量准确率，三者结合并扣除 AI 成本，才能得出真实边际收益。

• 理解 AI 可观测性的难点
• 理解跨团队协作需求
• 能设计指标约定

更难的原因：传统服务观测"请求是否成功、延迟、错误"，AI 应用还要观测"质量"（输出是否正确、是否幻觉、是否一致）、"成本"（token 用量、缓存命中）、"上下文"（prompt 长度、截断）、"模型版本"（漂移）——这些是多维、动态、主观的。跨团队协作：数据团队提供"质量评估"（评估集、标注、指标）、平台团队提供"基础设施观测"（延迟、错误、成本、模型调用 trace）、业务团队定义"业务指标"（转化、准确率阈值、验收标准）。指标约定：统一约定指标口径（准确率怎么算、错误如何归类、成本口径）、统一埋点（usage span、质量标签、版本号）、统一看板（按租户/任务/模型聚合）。核心是"AI 可观测需三方协作，统一指标口径与埋点"。

AI 可观测性难在"质量是主观、多维、动态的"，且跨数据/平台/业务。三方协作的关键是统一指标口径、统一埋点、统一看板，否则各说各话。

• 理解证据保留与隐私的平衡
• 理解脱敏与引用
• 能设计证据策略

原则：证据用于"事后审计、追溯、调试"，但原始敏感内容（PII、密钥、隐私数据）不能直接落日志。做法：一是脱敏——日志中只记录脱敏后的输入（掩码手机号/身份证、哈希化内容、保留格式），而非原文；二是引用而非复制——敏感内容存安全的存储（加密、权限受限），日志只记录内容 id/引用，需要时按权限取用；三是摘要/指纹——记录内容哈希或摘要，用于比对"是否同一内容"而不暴露原文；四是分级——按敏感级别决定日志粒度，高风险内容只记录"处理结果与元数据"，不记录正文；五是审计权限——访问证据需授权，日志本身加密。核心是"脱敏 + 引用 + 指纹 + 分级 + 权限，证据可追溯但不落敏感原文"。

证据与隐私的平衡在于"可追溯但不暴露原文"。用脱敏、引用、指纹让证据服务于审计，同时保护敏感内容。关键是把"内容"与"内容引用"分离。

• 理解阻断信号的类别
• 理解人工审批触发条件
• 能设计阻断流程

必须阻断并请求人工审批的信号：高置信度但内容高风险（涉及财务、法律、医疗、安全）；触发敏感规则（PII 泄露、诈骗、辱骂、越狱/注入攻击）；低置信但后果严重的决策（关键操作结果不确定）；模型表现出的不当行为（攻击性、拒绝执行 key 操作、引导违规）；涉及不可逆或有重大影响的操作（大额转账、删除、封禁）；多来源证据冲突且影响重大。阻断流程：检测到风险信号 -> 暂停执行 -> 标记"需人工审批" -> 人工审核 + 记录决策 -> 通过才执行，拒绝则终止并记录。核心是"高风险/敏感/不可逆/低置信但有重大影响的操作触发阻断 + 人工审批"。

阻断条件要看"风险等级 × 后果严重度 × 置信度"。高风险、不可逆、敏感、低置信但有重大影响的操作必须人工，防止模型自主执行造成不可挽回后果。

• 理解三类状态的表达方式
• 理解结构化表达
• 能设计统一响应契约

向下游表达应结构化、显式，而非靠文本暗示：置信边界——在响应中附带置信度字段（confidence/score）与不确定性说明（如"置信度低，建议人工复核"），让调用方决策；缺失信息——显式声明"信息缺失"（missing_fields / 未找到证据），并提供"需求澄清"的信号，而非给一个看似完整的答案；不可用状态——用结构化错误码/状态（如 degraded、unavailable、timeout）表达模型/Provider 不可用，并说明降级原因。统一响应契约：定义"结果 + 置信度 + 缺失信息 + 状态"的字段，前端据此渲染（提示复核、展示缺失、显示降级）。核心是"用结构化字段显式表达置信、缺失与不可用，避免下游误读"。

下游（前端/业务）需要知道"这个答案可不可信、缺了什么、是不是不可用"。结构化字段比文本暗示可靠，让下游能正确渲染与决策。

• 理解模型知识/缓存与业务数据的同步问题
• 理解上下文注入、缓存失效、结果校验
• 能设计一致性保障

问题：模型知识/缓存可能滞后于业务数据变更（如订单状态已更新、权限已变更，但模型上下文/缓存仍是旧值），导致"写后读"读到旧数据。保证手段：一是上下文注入——把最新业务状态显式注入当前请求上下文（覆盖模型缓存），让模型基于最新事实判断；二是缓存失效——业务数据变更时触发相关 prompt 缓存失效或刷新（如订单状态更新后该会话缓存作废），避免命中旧上下文；三是结果校验——对模型输出中的关键字段（订单状态、权限）做校验，与数据库比对，不一致则修正/重试；四是版本化——上下文带数据版本号，读时校验版本匹配。核心是"变更时注入最新值 + 失效旧缓存 + 校验结果一致性"。

模型是"有状态知识的无状态计算"，会与业务数据脱节。写后读一致性靠"注入最新上下文 + 失效缓存 + 校验结果"三管齐下，关键字段校验兜底。

• 理解隐含契约的类型
• 理解行为漂移的成因
• 能设计契约显式化

隐含契约：字段格式——模型输出与工具入参的字段结构、JSON 键名、类型（工具期望的字段名与模型输出的不一致会导致解析失败）；错误语义——工具错误返回的语义（字段名、错误码、含义）模型是否理解，若工具改了错误格式而模型未同步则误判；顺序假设——工具调用顺序、消息拼接顺序、结果回填顺序的隐含假设，若被打乱则流程错乱。显式化：把契约写成文档 + schema（工具入参出参 schema、错误码表、顺序约定）；用契约测试锁定（工具 schema 变化时模型 prompt 同步更新 + 回归）；模型 prompt 中显式声明工具契约（字段、错误、顺序）；加校验层（工具入参校验、输出 schema 校验）。核心是"把字段/错误/顺序等隐含约定写成显式契约 + schema + 契约测试"。

行为漂移常源于"模型与工具之间的隐性约定被单方面修改"。显式化是把这些约定写成 schema、错误码表、顺序文档，并用契约测试锁定，防止单方变更导致漂移。

• 理解四类机制的适用条件
• 理解责任边界
• 能设计分层处置

责任边界：重试——处理瞬时、可恢复错误（网络、5xx、限流），在费用/延迟预算内有限次重试，不适用于不可重试错误；补偿——处理"已部分执行但失败"的事务（如多步工具调用中某步失败，需回滚或补偿已执行步骤），只针对可补偿的操作；降级——处理"可用性不足"（Provider 故障、超限），切到备用模型/缓存/简版结果，降级要明确质量降低并被接受；人工接管——处理"风险高、不可自动恢复、补偿不了"的失败（如不可逆操作、低置信高风险决策），升级给人。边界原则：重试管"瞬时故障"，补偿管"部分执行"，降级管"可用性"，人工管"不可自动处理"。每层有明确触发条件与退出条件，避免无限循环。核心是"按故障类型与可恢复性分层，职责明确不越界"。

四机制不是可选项，而是分工：瞬时→重试，部分失败→补偿，可用性→降级，不可恢复/高风险→人工。边界由"能否自动安全恢复"决定。

• 理解各层职责划分
• 理解职责边界
• 能设计分层架构

职责划分：前端——会话展示、输入采集、流式渲染、用户交互与反馈；Java 业务服务——业务逻辑、Prompt 组装、会话状态、工具编排、结果校验、成本归集、面向业务的风险控制；模型网关——统一模型入口、路由、限流、重试、熔断、计费、多 Provider 适配与可观测；知识库——文档索引、检索（向量/关键词）、RAG 证据提供；工具服务——执行模型请求的工具（查询、计算、外部 API），返回结果；审计系统——记录模型输入输出、决策依据、人工审批、成本、合规，供追溯。边界：业务服务不直接调模型（经网关），不直接查知识库（经检索服务），审计与业务解耦。核心是"各层职责单一，通过网关与服务解耦，审计独立"。

分层的关键是职责单一与解耦：前端管展示，业务服务管逻辑与编排，网关管模型，知识库管知识，工具服务管执行，审计管追溯。依赖方向清晰，审计独立。

• 理解任务维度路由
• 理解模型能力与任务的匹配
• 能设计路由策略

任务维度路由：为每个任务定义"所需能力"（如需要推理→推理模型、需要视觉→视觉模型、需要语义检索→Embedding、需要排序→重排模型），建立"任务类型 -> 模型"的路由表，按任务特征路由，而非按用户随机或固定分配。原因：不同任务能力需求不同，按任务路由能最大化质量与成本效率（简单任务用轻模型、复杂任务用强模型、视觉任务用视觉模型）。路由考虑：任务类型（意图/需求）、输入模态（文本/图像/音视频）、复杂度（是否需多步推理）、成本预算、延迟要求。加"能力矩阵 + 级联路由"：任务先按类型匹配主模型，置信度不足时升级。核心是"按任务能力需求建立路由表，模态/复杂度/预算决定模型选择"。

混部部署的价值是"各模型各司其职"。按任务能力需求路由，而非用户随机，才能让 Embedding 管检索、视觉管视觉、推理管推理，质量与成本最优。

• 理解确定性计算的错误成本
• 理解模型计算的不可靠性
• 能设计兜底校验

必须用代码的原因：金额、日期、单位换算是精确、可验证、有明确规则的确定性计算，模型是概率性的，计算可能出错（四舍五入、进位、时区、精度损失），且无审计保证。代码实现精确、可复现、可测试。模型参与时兜底校验：若模型负责"解析/提取"计算所需字段（如从文本提取金额、日期），则提取后由代码做实际计算与校验——用代码算金额、校核日期有效性、做单位换算，并对模型提取结果做格式/范围校验，不一致则修正或拒绝。核心是"模型只做提取/理解，实际计算与校验必须用代码，以代码结果为最终依据"。

确定性计算是"代码的强项、模型的弱项"。模型参与时只负责理解/提取，计算与校验交给代码，保证结果精确且可审计。