架构分层与模型选型

核心概念

将应用分成入口与身份、业务编排、资料检索、模型调用、工具执行及日志评测几层。分层的目的，是让错误可定位、组件可替换。模型负责理解与生成候选内容；身份校验、可访问资料、字段规则和执行授权由确定性的系统规则落实。

选型从任务约束开始：输出质量、响应时间、资源消耗、数据处理边界和维护成本。使用固定任务集、相同资料和相同评分标准比较候选方案，记录配置与失败。不能只依据一个演示结果或厂商宣传决定。

情境拆解

虚构企业的问答路径是身份确认、按权限检索、生成带依据的答复；建单路径还需要字段校验、用户确认与 mock API 执行。模型可以提出工具调用，但不能通过改写提示词获得另一门店的资料或绕过确认。

练习时可用两个离线脚本模拟不同模型输出，先检验比较方法。模拟结果不说明真实模型性能。

常见误区

把所有逻辑塞进提示词，容易让权限和动作控制依赖模型是否听话。换模型后只检查正常回答，也可能漏掉拒答、结构输出和工具调用的变化。

先在图上标出责任

模拟系统有六层：身份、流程编排、检索、模型、工具接口，以及日志与评测。模型可以生成内容；身份范围、工具权限和状态验证应由应用与业务服务检查。

动手：比较两个候选设计

1. 画出六层架构，在连线上写数据与信任来源，标记哪些会读取或改变状态。
2. 设计两个候选方案，例如固定检索流程与带二次检索的受限流程。
3. 用相同的 12 个合成任务比较，固定资料、权限和模拟接口结果。
4. 记录正确行为、失败路径和额外调用。没有真实模型调用时，结论只能说明设计或模拟行为，不能声称某模型更强。

候选方案：
输入样本与固定版本：
每层负责什么：
权限检查位置：
预期 / 实际行为：
增加的调用与故障点：
继续、修改或放弃的理由：

检查产物

任意一条“已完成”回复，都能沿图追到状态证据。改用不同模型后，权限和确认规则仍保持不变。架构图不需要复杂，但不能遗漏这些检查。