上周的订单扫描有个问题只要有一条记录格式不对整个租户的所有订单都读不出来。好的坏的一起被挡住了。这轮的改动正好从这里开始。101天系统开始明白一件事单个错误不应该让整个任务失效。一、一条坏记录不再拖垮全部订单之前订单库中只要有一条记录不符合契约整个扫描任务就会失败导致同一租户的其他正常订单也无法被读取。这是一个典型的“全有或全无”设计——为了保护数据质量代价是牺牲了可用性。这轮改成了“按记录隔离”发现不合规记录后将其放入专门的不合规清单同时继续扫描其他文件和记录。返回结果中增加了合规订单数量、不合规数量、总记录数等信息统计真实完整。只有在“没有任何合规记录、但存在不合规记录”时才将整个任务判定为契约级失败。写入侧仍然保持严格校验不合规数据不能上传或补丁写入。系统不再因为一条坏记录就拒绝服务其他正常的请求。二、知识库名称不存在时告诉你“那看看这些”过去模型使用一个已经被删除的知识库名称时系统通常只返回“知识库不存在”。模型不知道有哪些是存在的只能继续用同一个名称反复尝试最终耗尽轮次。这轮改了错误结果会携带当前可用的知识库清单、清单总数以及结构化的下一步操作建议。只有一个可用知识库时直接提示其名称有多个候选时只提供候选不擅自替模型选择当前没有任何可用知识库时明确要求停止尝试而不是继续猜名称。对知识库文件读取、修改、导入和订单列表等多个入口都统一了这种返回格式。同时增加了重复失败保护当同一个工具、同一组参数、同一种结构化失败原因连续出现时会提示更换参数或终止操作避免无效重试。这个保护只依赖结构化错误码不依赖错误文案——文案变了保护依然有效。错误信息不只是告诉你“错了”还告诉你“下一步该怎么做”。三、工具被过滤了日志会记下来不会静默消失之前搜索结果中用户明确点名的工具可能因为通用关键词命中数量较多被其他无关工具挤到后面模型看到前几项后可能误以为该工具不存在。这轮改了匹配优先级只要查询中出现完整工具名就会给予最高优先级让被点名的工具直接排在前面。工具列表被截断时会保留明确的截断标记。工具因为组织权限或可见性被过滤时日志会记录工具名称、来源、所属组织和过滤原因不再静默跳过。运行时目录里有什么、为什么没有现在都能查到了。四、证据账本写满时不崩溃只停止收录证据账本是用来记录“系统完成某件事的证据”的。但当证据太多时——条数超过上限或字节数超过上限——之前会直接抛异常而且是在模型调用开始前发生每一轮都可能失败用户只能看到“请重试”但重试仍然会在相同位置失败。这轮改了超限后不再抛异常而是停止收录超出的证据并写入饱和标记和归因日志。系统会区分是条数达到上限还是字节容量达到上限——两者对应的解决办法不同。保留策略采用“保留前面已有的证据、丢弃最新证据”这样多轮重复扫描时结果稳定不会因为反复淘汰和重新加入导致证据集合来回变化。容量也提高了能满足一次任务需要收集几十条工具证据的场景。饱和标记使用与证据收据相同的签名和编码机制并随可信上下文传递给后续流程。Hook能区分“候选没有取证”和“证据账本已经饱和但部分证据未被收录”——不过饱和标记本身不参与授权判断不能绕过证据门禁。证据太多不会让系统崩溃只会让收集器停止工作并告诉你原因。五、技能正文写入超限就整体回滚技能正文写入入口补齐了大小限制避免过大的正文绕过部分入口限制直接进入系统。更关键的是原子性保证如果最终校验失败之前已经写入的内容会整体回滚不会留下半截正文或部分更新状态——用户不会看到“技能保存了一半”这种状态要么完整成功要么原样退回。技能写入不会留下一半的内容要么完整进来要么完整退回去。101天系统不再因为一条坏记录而拖垮全部不再因为知识库名称写错就无限重试不再因为工具被过滤就静默消失不再因为证据太多就抛异常不再因为技能写入失败就留下半截内容。在101天系统终于学会了隔离错误而不是扩散错误。这是第101天。《从0到1企业级AI项目迭代日记》记录一个企业级 AI 项目从创意、架构到落地的真实过程。不讲神话只记录进化。如果你也在做企业 AI 落地欢迎留言来聊。或者把这篇转发给一个正在踩同样坑的朋友。