给现有应用接入 AI 助手的架构清单

给现有应用接一个 AI 助手，难点往往不在聊天窗口，而在它能看到什么、能执行什么，以及失败后怎么收场。原文的核心主张是：模型负责提出答案和操作建议，应用后端负责决定权限与执行结果。

这是一套围绕内部文档、客服和订单业务展开的架构建议，没有性能实测，也不是可直接上线的完整实现。对准备把 LLM 接进现有产品的前端和全栈开发者，它最有用的地方，是把容易被一个聊天界面掩盖的工程责任逐项摊开。

登录成功，为什么还不能直接把数据交给模型

原文建议把模型放在现有应用后端之后。浏览器发送请求，后端依次处理身份认证、权限校验、输入限制、资料检索、LLM API 调用和工具执行，同时承担日志与监控。

这样安排，首先能避免在浏览器代码中暴露高权限 API 凭据，更关键的是保留一个统一入口：哪些资料可以进入模型、哪些操作允许执行，都由现有应用判断。

身份认证（Authentication）回答「你是谁」，授权（Authorisation）回答「你能访问什么」。助手可以复用应用已有的登录机制，但每次访问具体资源时，仍要结合当前用户的角色、所属组织和访问范围做判断。

比如员工要求总结某个客户最新的客服记录，后端应该先确定他能访问哪些记录，再获取内容。不能先把所有匹配记录交给模型，让模型自行挑选。资料已经进入模型上下文，权限边界就已经越过去了。

系统提示词里的保密要求，不能替代服务端权限校验。

这条规则同样适用于检索增强生成（RAG）。它可以理解为：回答前先查业务资料，把相关内容交给模型作为依据。原文没有要求必须上向量数据库，关键词搜索、向量相似度或混合检索，都应根据内容、查询习惯、延迟要求和结果质量选择。

检索层还要做好几件事：在查询时过滤访问范围，保留来源标识，限制上下文大小，并明确文档更新、删除和权限变更如何同步到索引。索引建好了，不代表访问规则可以省掉。

没有找到合适资料时，助手应承认依据不足。资料支持、资料未覆盖、资料互相冲突，也应该在回答中有所区分。否则，一个流畅的答案很容易让用户误以为系统已经查证。

工具调用为什么必须重新经过业务后端

查文档和修改客户记录，承担的责任不同。助手一旦能调用工具，就开始介入真实业务流程。

原文建议只暴露范围明确的操作，不给模型开放整个数据库或通用执行环境。下面这段示意定义，把能力限制为查询当前用户有权访问的订单状态：

{
  "name": "get_order_status",
  "description": "Retrieve the status of an order the current user may access",
  "parameters": {
    "order_id": "string"
  }
}

要注意 order_id 这一行：参数是字符串，只说明输入形状符合约定，不能证明用户有权访问对应订单。这也只是架构示例，不是某家模型服务可直接使用的完整工具定义。

模型请求调用后，后端还需要验证工具名和参数结构，拒绝额外字段与非法标识，独立解析用户权限，执行限定范围的查询，并只返回任务需要的字段，最后按审计策略记录结果。

模型发起工具调用，只能算操作申请，不能算授权通过。

对于只读操作，通过权限检查可能就够了。涉及修改数据、发送消息或产生财务、业务承诺的动作，则可能需要用户明确确认、幂等控制和结果核对机制。

幂等控制解决的是同一请求重复到达的问题。例如写入请求超时，客户端并不知道后端是否已经执行成功。此时直接重试，可能造成重复操作。原文建议先核实结果，再决定是否重新写入；底层操作支持时，可以使用幂等键。

因此，失败处理不能统一成一个「重试」按钮。认证失败应在检索前拒绝；证据不足应解释限制或请求澄清；模型 API 超时可以在限定次数内重试；输出格式错误必须验证后再使用；工具权限不足则不执行。

流式输出也有边界。提前显示部分文字能改善等待体验，却不能证明完整答案已经通过检查。涉及实际业务动作，必须等相应校验完成后再执行。

怎样证明它可用，而不只是 API 调通了

原文把日志、评估和人工接手放进同一套交付责任里：出错时能查原因，改动后能发现退化，解决不了时能交给人继续处理。

日志可以记录请求或关联 ID、模型与应用版本、检索来源及相关性、工具名与执行状态、延迟、token 用量和服务商错误类别。但不应默认无限期保存完整提示词、文档片段和回答，因为这些内容可能包含客户信息或商业资料。

保留多久、谁能查看、哪些字段要脱敏、哪些数据会发送给外部模型服务，都需要明确。日志应帮助排障，而不是再造一个缺少控制的客户资料库。

评估也不能只看接口是否成功返回。原文建议在扩大使用范围前，准备包含正常任务和边界情况的评估集：

• 文档能够直接回答的问题，以及证据缺失或冲突的问题。
• 用户无权访问的记录，以及检索内容中夹带的提示词注入。
• 非法工具参数、重复调用，以及应该转交人工的请求。

答案正确性、证据支持程度、检索相关性、权限执行、工具调用准确性、延迟和成本，需要分别观察。一个总分容易掩盖关键问题：回答质量不错，不代表越权请求一定会被拦住。

对于有实际后果的动作，要测完整流程。模型生成了正确的调用参数，后端仍可能因为校验错误而执行不该执行的操作。模型、提示词、检索流程、工具或权限逻辑变化后，都应重新运行回归用例。

人工接手同样需要设计。转交时保留用户原始请求、相关且已授权的来源、尝试过的操作和升级原因即可。应用尚未确认执行成功，就不能告诉用户「已经完成」；结果不确定时，应明确说明并提供状态查询路径。

我的判断

我赞同原文把权限和执行权留在可信业务代码中。对于已有账户、订单和工单系统的团队，这能让助手继续遵守现有业务约束，也方便逐步定位故障。

不过，这是一份架构检查思路，不是经过对照实验验证的方案。作者没有提供实际团队的上线结果，没有给出检索质量、延迟、成本或错误率数据，也没有证明某种检索方式优于其他方式。关于技术选型和推进顺序，应把它看作工程建议。

它还有一个重要前提：现有应用的权限模型足够清楚。如果业务接口原本就缺少资源级授权，给助手复用登录态并不能补上缺口。日志保留策略、索引更新机制和写入结果核对，也都需要结合现有系统继续落地。

原文给出的 Stage 1 到 Stage 4，依次是只读回答、受控工具、确认后执行动作、扩大使用范围。这种拆分有助于降低首次上线的复杂度，但不是固定排期，也不是每个产品都必须走完的路线。若需求只是查制度，停在只读阶段就可能足够。

能拿来做什么

• 如果正在给前端应用增加聊天面板，先画出浏览器到后端再到 LLM API 的请求路径，确认凭据放在哪里、用户范围在哪里解析、哪些资料最终会进入模型。
• 如果用 Node 后端接工具调用，先挑一个范围明确的只读接口，补齐参数校验、资源授权和返回字段限制，再考虑让模型触发写入。
• 如果助手需要回答内部文档问题，先用现有搜索能力验证代表性问题，并补上无证据、证据冲突和来源引用的展示，再判断是否需要引入向量检索。
• 如果已经接通模型，把越权查询、提示词注入、工具重复调用和写入超时加入回归用例，并让界面清楚区分「正在处理」「已确认完成」与「结果待核实」。