AI 系统落地，工程重点在模型之外

AI 功能能演示，不代表能在公司里长期运行。作者的判断是：模型只是系统中间的一个组件，真正决定产品能否上线、出了问题能否收住的，是请求前后的数据处理、权限、评估和监控。

这篇文章值得读的地方，是它把「选哪个模型」换成了一个更实际的工程问题：哪些错误代价最高，又最难在上线后补救？不过，文中的「90%」没有完整工时统计支撑，应当看作作者对投入重心的经验概括。

模型之外，到底还有哪些工作

作者所说的流水线（pipeline），指请求进入到答案离开的整个过程，扣除模型执行推理的那一步。

输入首先要被接收、解析和标准化。真实业务不会保证每次都送来格式正确、字段完整的数据。接着，系统要决定哪些信息允许进入模型，以及当前用户允许访问哪些资源。答案生成后，还需要日志、评估、监控，以及发现问题后的处置机制。

这里有两个容易混在一起的边界：

• 脱敏边界决定模型可以看到什么，例如自由文本里的个人身份信息（PII）是否需要遮蔽。
• 授权边界决定助手可以访问什么，而且访问权应继承当前用户，而不是给助手单独配置一套更大的权限。

大白话解释：用户自己打不开的资料，不该因为通过 AI 提问就能拿到；不该送进模型的敏感信息，也不能寄希望于模型「自觉保密」。

作者还要求为实验预先登记 kill-gate，也就是在实验开始前写清楚，什么结果出现时就判定失败或停止继续。它解决的是评估纪律问题，避免看到结果后再调整合格标准。

流水线的价值，是把模型能力放进明确的数据、权限和运行边界里。

为什么作者认为模型更容易换，边界更难补

作者坚持把开放模型放在统一接口后面，避免供应商锁定。在他的描述里，这个组件的接口可以简化为「文本输入，文本输出」，上下游不应该跟某个模型绑死。

因此，作者认为：如果换模型就导致整个系统损坏，说明原来的解耦没有做好。相比之下，脱敏、权限和监控往往贯穿整个请求过程，等业务跑起来再补，改动范围更大。

支撑这个判断的直接经验有三项。作者称，在他今年构建和测量的系统里，设计脱敏边界花的时间，比开发受它保护的 AI 功能还长；自由文本检测存在真实漏检和误检，必须测量；让助手继承用户权限，则完全是一项基础设施工作，不需要模型参与。

但原文没有列出具体工时、样本量和实体级检测结果。「昂贵的 90% 都是管道工程」表达了投入重心，并不能当作一般团队的预算比例。

作者还引用了一项 2026 年研究框架：除预测表现外，同时考察工作流完成度、产物可追溯性、部署就绪度、可复现性和漂移恢复能力。漂移可以理解为系统面对的数据或环境变了，原来可用的表现开始失效。

这个评价方向有现实意义。单次回答再漂亮，也回答不了「整个任务有没有完成」「用了哪些输入」「质量变差后怎么恢复」这些上线问题。

多加 Agent 和编排，为什么未必更可靠

作者引用的另一项 2026 年研究，把 LLM Agent 的失败集中在工具调用、约束条件下的规划，以及长任务协调等环节。它们都发生在模型与业务系统协作的过程中。

原文同时指出，额外的编排并不总能提高可靠性。把更多步骤、角色和协调逻辑叠上去，不能自动解决边界不清、评估缺失的问题。

作者给了两个很实用的检查问题：收到格式错误的输入时怎么办？输出质量悄悄下降时，谁会收到告警？

这比问团队用了哪个模型，更容易看出系统是否具备运行机制。答案应该能落到输入校验、质量信号和责任人，而不是一个模型名字。

这套思路与 MLOps 有重叠。按作者的区分，MLOps 通常围绕训练和部署工具展开，而这里还包括脱敏与授权。这两项既是运行问题，也是安全决策。

向业务争取预算时，作者建议说明它们避免了什么损失：脱敏失败可能导致数据泄露，权限缺失会放大提示注入的影响，没有预先登记的 kill-gate 则让指标难以取信。那些五分钟演示里看不到的工作，决定了系统能不能经受普通工作日的使用。

我的判断

我赞同文章对工程优先级的提醒，尤其是会读取内部资料、调用工具的助手。权限和敏感数据处理一旦遗漏，很难靠换一个更强的模型补齐。

但「换模型几乎没变化」有明显前提。接口能替换，不代表行为可以无成本替换。新模型是否稳定遵守输出格式、是否正确调用工具，仍然需要回归验证。文章用「文本输入，文本输出」解释解耦很直观，却没有充分展开这些行为差异。

同样，把工具调用和规划失败全部归到流水线，也有些绝对。问题发生在工具调用处，不能直接证明模型能力与失败无关。更合理的排查方式，是分别检查模型决策、工具契约和编排逻辑。

证据也需要分层看。脱敏开发耗时来自作者自述；生命周期评价和 Agent 失败分类来自他引用的两项研究。原文没有展示研究的实验设置、对照结果和适用范围，所以「普通模型加严谨流水线通常更长寿」仍应视作经验判断，不能当作已验证的普遍结论。

与持续追逐榜单相比，我更认可先把边界补齐；如果当前瓶颈已经明确是模型理解或推理能力不足，升级模型依然合理。两类投入要根据实际失败记录分配。

能拿来做什么

• 给现有 AI 接口画出请求经过的步骤，标出输入校验、脱敏、用户授权、模型调用和日志记录的位置，并检查格式错误的输入会在哪一步被拦住。
• 如果 Node 服务里的助手会读取内部资料或调用工具，让每次访问都携带当前用户身份并执行权限校验，避免只在前端隐藏入口。
• 下次比较模型或调整提示词之前，先写下评估样本、通过标准和停止条件，再运行实验，减少看到结果后修改口径的空间。
• 为上线功能定义一个能发现质量下降的信号，并明确告警交给谁；准备替换模型时，用已有业务样本验证完整任务是否仍能完成。