这是什么

源头数据库有 50 条记录，真正进入大模型的只有 20 条——开发者最近排查了一个「看着成功实际失败」的 Agent（能自主调用工具完成任务的 AI 助手）案例：剩下 30 条没有任何报错地消失了，模型却基于残缺输入给出了逻辑通顺但事实不全的总结。 麻烦在于，传统运维只看「有没有报错」，而 Agent 的数据截断发生在报错体系之外。文本格式正常，模型也没出现幻觉，系统日志一片绿色——但「事实覆盖已经不完整」。 作者的修复思路是：在送入模型前，由系统显式记录几个字段——本次请求多少条、实际加载多少条、是否被条目上限或字节限制截断、过滤掉了多少。一旦 inputComplete=false，后面的回答就不能继续假装基于全集。 更进一步，「完整」被拆成三层：源集合是否定义完整、目标数据是否完整进入模型、最终回答是否正确覆盖数据，三者不能混为一谈。光看数量还不够——如果源端是 A B C D E，中间层拿到 A B C D D，数量仍是 5，但 E 已经丢了，需要用 ID 集合或哈希对账才能发现。

行业怎么看

技术社区的主流反应是「这不新鲜」——任何做过数据管道的人都见过静默丢数据，本质上和分页接口只返回前 100 条是一回事。套到 Agent 上，只是换了个壳。 但另一种声音更值得我们注意：Agent 正在从「玩具」变成「业务系统」。当 AI 替企业处理客户名单、订单流水、合规文档时，「流程跑完了」不等于「事情做对了」。传统运维盯的是错误率和延迟，Agent 时代还需要一个新的指标——「输入完整率」。 风险在于，多数企业目前根本没有这个监控维度。模型答错了容易被发现，模型答得「看起来对但基于残缺数据」，往往要等到业务结果出问题才暴露。

对普通人的影响

对企业 IT：需要从「系统报错」转向「数据落点」监控，关键链路至少要记录「源头几条、模型收到几条、回答覆盖几条」三个数。 对个人职场：用 AI 助手处理客户清单、财报摘要、会议纪要这类任务时，遇到「看着很顺」的结论要警惕，必要时要求 AI 列出原始条数做交叉验证。 对消费市场：AI 客服、AI 投顾、AI 体检报告等产品可能正在基于不完整数据做推荐，保持一份「它不一定看全了」的怀疑，比相信一个漂亮答案更安全。