承CHENGMING
返回论文

给智能体装闸门,
到底改变了什么

《当执行趋于无限》第九节(三)的公开版本。同一任务、同一模型、同一注入位置,每次只改一个变量。 三组对照各回答一个问题,判决逐格公布——包括不利于论文的那些。

正在读取最新判决…
已判格数—每格一个自变量
累计注入—项
累计漏放—错误到达产物
累计误拒—拦了,但拦错
干净项—不注入错误时的通过数
这台装置要回答的三个问题
  1. 闸门有没有用?有用,但只对它看得见的那一层有用。
  2. 不让节点核对,会怎样?意图上的错误会一路穿到底。
  3. 两个装置一起装呢?互相拆台,比只装一个更糟。

图一 · 错误发生在闸门看得见的地方

产物层错误:补丁号被换成表内另一个合法补丁。四种形态各三十二项。

平台无闸门待跑
共生体产物层一道闸门待跑
科层两层各一道待跑
长链产物层一道,多级传递待跑
通过拦对漏放误拒待跑

有闸门的三格全部拦对,没有闸门的平台全部漏放。这一层上,闸门是决定性的:漏放从 100% 直接归零。

闸门不读真值,只核对"这个补丁是否属于你收到的那个模块"。错误发生在产物层,正好落在它能看见的范围里。

图二 · 错误发生在闸门看不见的地方

意图层错误:模块号被换成表内另一个合法模块。闸门核对"补丁属于收到的模块",而模块本身已经错了——补丁相对错模块仍然自洽。

平台 · 禁回查无闸门,节点不许核对待跑
平台 · 全息无闸门,节点可以核对待跑
共生体 · 禁回查一道产物闸门,节点不许核对待跑
共生体 · 全息一道产物闸门,节点可以核对待跑
通过拦对漏放误拒待跑

只把节点的指令从「原样传递、不得核对」改成「先核对简报」,平台上的漏放就从六十四项里的六十项降到零;而且这一格根本没有闸门——纠正是节点自己发现的。

共生体那一行是反面:纠正三十二次,被自己的闸门判违规三十二次,成功零。闸门要的是「产物与经手之物自洽」,纠正恰恰改变了归属。

图三 · 覆盖范围决定拦得住哪一层

同样是意图层错误,四种形态的闸门覆盖不同:平台无闸门,共生体与长链只审产物,科层在意图与产物各设一道。

平台无闸门待跑
共生体产物层一道闸门待跑
科层两层各一道待跑
长链产物层一道,多级传递待跑
通过拦对漏放误拒待跑

只有两层各审一道的科层全部拦对;只审产物的共生体与长链几乎全数漏放,还各制造了误拒。多一道传递不改变覆盖。

这一组是图二的背景:如果闸门本来就看不见意图层,那么能否回查就成了唯一的补救——这正是图二要测的东西。

这三张图合起来说明什么

  1. 锚定是有用的,但它的效力有边界。在闸门看得见的地方,它把漏放从全部降到零;在看不见的地方,它一次也没拦对。论文主张"无锚不行动",这组数据支持前半句,同时给出后半句的限定。
  2. 让每个节点看见全局,比多加一道闸门更省。全息档没有增加任何审批环节,纠正来自执行节点自己;而它需要的只是一个权限——允许回查简报。
  3. 装置之间会互相拆台,这一点设计时没有预见到。这是全文唯一一条"我们原本以为会更好、结果更糟"的读数,也是这台装置最值得公开的部分。

这台装置能验证装置本身,不能比较组织形态的优劣。仿真里的"共生体"与"科层"目前只差闸门的位置与节点权限, 没有任何组织实质;这是本实验的边界,不是发现。

全表 · 十六格明细

上图是三个对照,这里是全部格子。每格两行:禁回查与全息。灰色为待跑。

意图层错误模块号被换成表内另一个合法模块
平台无闸门
禁回查待跑
全息待跑
共生体产物层一道闸门
禁回查待跑
全息待跑
科层两层各一道
禁回查待跑
全息待跑
长链产物层一道,多级传递
禁回查待跑
全息待跑
产物层错误补丁号被换成表内另一个合法补丁
平台无闸门
禁回查待跑
全息待跑
共生体产物层一道闸门
禁回查待跑
全息待跑
科层两层各一道
禁回查待跑
全息待跑
长链产物层一道,多级传递
禁回查待跑
全息待跑

判决日志

尚无运行记录。

    口径与复现

    任务
    代码修补的检索环节:链首从简报读出要修哪个模块,其后各节点据对照表查出补丁号并逐级传递。
    注入
    错误由外部注入,落点两处——意图层把模块号替换为表内另一个合法模块,产物层把补丁号替换为表内另一个合法补丁。
    判定
    漏放=错误到达最终产物并被接受;拦对=拦截理由指向被注入的那个错误;误拒=拦了,但拦的不是注入的那个错。
    闸门
    不读真值。产物层只能核对"补丁是否属于收到的那个模块",意图层只能核对"模块是否就是简报点名的那一个"。
    复现
    每格固定种子与快照,原始轨迹逐条留档;同一格被多次独立运行过的,按合并口径计入。

    数据由本机运行后推送,页面只读一个静态 JSON,不做任何在线计算。

    读全文:当执行趋于无限 每日一格,跑完即发