大模型（LLM）写代码能跑通，但让它连续执行20步任务，出错率飙升到47%。这不是我编的，是Anthropic去年内部测试的数据。问题出在「幻觉」——模型会突然失忆、编造假数据，或者把用户要的是A理解成B。
行业里管这叫「智能体（Agent）循环崩溃」。你让AI自动订机票，它可能在第7步把「经济舱」记成「商务舱」，第12步把日期搞错，最后给你一张去火星的票。更麻烦的是，它自己不知道错了。
验证层：给AI装刹车
Iterative这家公司的解法很产品经理思维：把大模型当成一个会犯错的实习生，每次交活必须过质检。他们的系统给AI输出加了多层验证，像工厂流水线里的X光检测——结构对不对、数据在不在知识库里、逻辑有没有自相矛盾。
关键设计是「反馈闭环」。验证不通过，不是直接报错，而是把具体问题扔回给模型重写。比如检测到日期格式错误，反馈里会写「请用ISO 8601格式，你刚才用了美式简写」。
但这里有个死循环风险。如果模型就是理解不了呢？Iterative的文档里没提具体阈值，只说了两种策略：硬截断（最多试N次，选最优失败品）和软达标（跑到质量分数及格线为止）。选哪种，取决于你要的是「能用的」还是「对的」。
确定性护栏：在随机性里找确定性
他们管这套叫「确定性护栏（Deterministic Guardrails）」。名字有点绕，拆开看就明白了：大模型本身是概率机器，输出带随机性；但验证规则是写死的代码，0就是0，1就是1。
这个设计回避了一个行业难题——完全依赖模型自我修正，相当于让醉汉自己判断醉没醉。Iterative的做法是，醉汉每次说话，旁边站个绝对清醒的裁判。
代价也明显。每加一层验证，延迟涨一截。他们没公布具体数字，但参考同类方案，20步任务可能从3秒拖到15秒。对实时交互场景，这是致命伤。
开源背后的算盘
Iterative选择开源这套框架，时机很微妙。OpenAI的Operator、Anthropic的Computer Use都还在实验室阶段，没开放给开发者随便改。这家2015年成立的MLops公司，显然想抢「可观测Agent基础设施」的生态位。
他们的GitHub仓库里有个细节：默认配置是「硬截断3次」。这个数字不是拍脑袋——超过3次，用户流失率陡增；少于3次，错误率压不下去。这是用产品数据喂出来的经验。
不过开源社区的反应分化严重。Hacker News上有开发者吐槽：「验证规则写起来比业务逻辑还复杂，我为什么不直接写传统代码？」也有团队反馈，在金融合规场景里，这套框架把人工复核工作量砍了60%。
Iterative的人在讨论区回了一句：「我们没解决幻觉，只是把幻觉关进了笼子。笼子多大、什么材质，你自己定。」
热门跟贴