# 上下文变多，还是被耦合到另一个 agent？LLM 自指循环里约束恢复的规模依赖性

## 一句话结论

一个受控实验问了一个很具体的问题：语言模型从一条冲突指令里恢复过来，是因为**它多生成了文本**，还是因为**它被耦合到了第二个 agent**？

答案随规模反转。1.5B 上"体量"把效果解释得干干净净；7B 上体量彻底失效，只有耦合能恢复（26.7%，p = .0078）。

## 协议：先造出"陷进去"

实验用的是一个最小化的扰动—恢复协议：

- **约束**：大写的大写指令，写明必须遵守的规则
- **扰动**：一条礼貌的、小写的、与约束冲突的指令（礼貌和小写都是故意的——它不是攻击，是日常生活中最常见的那种"顺手把规则改掉"）
- **恢复**：在 8 轮交换窗口内，违规次数降到阈值以下
- **解码**：greedy，30 条固定配对开场句，同一个模型家族（Qwen2.5-Instruct）

四个条件，重点是后两个：

| 条件 | 是什么 |
| --- | --- |
| **C** Coupled | 两个 agent 交替发言，扰动只打给其中一个 |
| **S** Single | 同一个模型，但只有被扰动的那个在说话（体量最小，没有第二个 agent） |
| **X** Context-matched | 把耦合条件里另一个 agent 的发言喂给单体——**上下文长度对齐，但没有活的第二个 agent** |
| **D4** Dose-4 | 单体，但扰动重复 4 次（体量更大） |

X 这个条件是整个实验的支点。"第二个 agent 多说了话"和"第二个 agent 是个活的、会重新锚定的东西"，是两件事。X 把它们拆开了：上下文一样长，但那句话是被回放的，没有独立的下一次采样。

如果 X 也能恢复，那答案就是体量；如果只有 C 能恢复，那答案就是耦合本身。

## 结果：三个规模，答案翻了两次

| 规模 | C 耦合 | X 上下文对齐 | D4 剂量 4 | S 单体 |
| --- | --- | --- | --- | --- |
| 1.5B | **43.3%** (13/30) | 36.7% (11/30) | 26.7% (8/30) | 16.7% (5/30) |
| 3B | 100% | 90.0% | 90.0% | 100% |
| 7B | **26.7%** (8/30) | **0%** | 3.3% (1/30) | **0%** |

配对精确 McNemar 检验：

```
===== Tier 1.5B =====
  C vs X: b=7, c=5, p = 0.7744   → 体量解释得通
===== Tier 3B =====
  所有比较 p ≥ 0.25              → 全在天花板上
===== Tier 7B =====
  C vs X:  b=8, c=0, p = 0.0078
  C vs S:  b=8, c=0, p = 0.0078
  C vs D4: b=8, c=1, p = 0.0391  → 只有耦合能恢复
```

三段读法各不相同：

**1.5B**：耦合看起来有帮助（43.3% vs 16.7%，C vs S p=0.0386），但上下文对齐的 X 拿到了 36.7%，C 和 X 的差异不显著（p=0.7744）。也就是说，小规模下"耦合的优势"基本可以由**体量**解释掉。

**3B**：四个条件全在 90–100% 的天花板上，扰动根本没抓住模型。这一格的信息量不是"某个条件更好"，而是**这个协议在中等规模下失效**。

**7B**：彻底反转。X = 0%，S = 0%，D4 = 3.3%，体量这一路全军覆没；而耦合拿到 26.7%，且与三者都显著分离。恢复还变慢了（延迟 2–7 轮）。

## 机制：不对称的捕获深度

一个直接的疑问是：耦合条件里两个 agent 是同一个模型，为什么"第二个自己"能救回来？

解释建立在 7B 那 8 条恢复轨迹的回放上：**被直接扰动的那一个陷得很深，而从来没有直接收到那条指令的伙伴只是靠模仿浅陷进去**。浅陷的那个还有能力重新锚定，于是它把"约束一致的证据"供给出去——而深陷的那个需要被这种证据拉回来。

这也顺手解释了为什么 7B 上"多生成文本"完全无效：多说的，仍然是陷进去的那个自己在说。

## 一行命令复算，不需要 GPU

```bash
git clone https://github.com/simin-yuan/context-volume-not-coupling
cd context-volume-not-coupling
python code/analysis_mcnemar.py
```

只用 Python 标准库，一秒以内跑完，论文里每个精确 p 值都能从嵌入的原始结果重新算出来。`data/raw_outcomes_v2.txt` 里存着同一份结果的可读版本，两处必须对得上——对不上，论文就是错的。

本机实跑输出（2026-09-17）：

```
===== Tier 7B =====
  C: 8/30  (26.7%)     X: 0/30  (0.0%)
  D4: 1/30 (3.3%)      S: 0/30  (0.0%)
  C vs S:  b=8, c=0, exact McNemar p=0.0078
  C vs X:  b=8, c=0, exact McNemar p=0.0078
  C vs D4: b=8, c=1, exact McNemar p=0.0391
```

## 确定性是设计进去的，不是声明出来的

复现类工作常见的问题是"我声称它可复现"。这个实验把确定性做进了协议：

- greedy 解码，30 条固定配对开场句
- **无扰动对照组**：5 个开场句 × 6 轮交换，违规率全程 0.000——说明基线本身干净，后面的恢复是真的恢复
- 8 条恢复的 7B 耦合轨迹全部回放，**回放延迟与记录延迟 8/8 一致**
- STABLE / TRANSIENT 的分类规则在查看结果之前就定死，事后按规则分出 5 稳 / 3 暂
- 4-bit 量化被明确排除，因为它会混淆规模之间的比较

## 削弱自己结论的那条结果，留在仓库里

v1 的结论是：1.5B 上耦合的优势完全由生成体量解释。这条对论文自己的故事不利——它把标题里"耦合"那一半否掉了。

仓库的处理方式是：v1 的代码、数据、图、PDF 全部保留，与 v2 并存。文件命名区分版本（v1 无后缀，v2 带 `_3B` / `_7B` / `_scale` / `_traj`），Zenodo 有版本化 DOI，v1 到 v2 的轨迹可以逐文件对照。

所以这篇文章标题里的"Volume or Coupling"不是一个修辞。它是 v1 结论（Volume）和 v2 结论（Coupling，且只在 7B 成立）的关系本身。

## 边界与不确定的地方

- 单一模型家族，三个规模，每格 30 条样本。7B 的 26.7% 只来自 8 条成功轨迹，机制解释建立在轨迹回放上，样本很小。
- 3B 落在天花板（90–100%），扰动在中等规模下抓不住——这一格没法用来支持任何关于规模效应的论证。
- "不对称捕获深度"是从轨迹里读出来的解释，不是被单独操纵的变量。要真正验证它，需要人为控制两个 agent 的捕获深度再跑一遍。
- 论文本身是预印本，v1 在投，v2 作为替换版本准备中。

## 想接着往下做的话

实验脚本按规模拆开，都很短：1.5B 那套能跑在免费的 Colab T4 上（3 GPU 小时以内），3B 和 7B 需要 L4（合计约 5 GPU 小时）。要复现一个新规模，主要成本是显存，不是工程。

真正值得抄的是这个协议的形状：**想区分"多说了话"和"被另一个主体影响"时，做一个上下文对齐的单体条件。**上下文长度是可以对齐的，独立的下一跳不能。把这两件事拆开，结论才站得住。

---

**仓库**：`github.com/simin-yuan/context-volume-not-coupling`（CC BY 4.0，完整复现包）

**DOI**：10.5281/zenodo.21200851（v2）· concept DOI 10.5281/zenodo.21157628

**复现**：文中全部恢复率与 p 值均为 2026-09-17 本机重跑所得，命令与输出原样保留。

**说明**：论文作者为 Simin Yuan；本文由 AI 协作者（时晴）整理撰写，作者审阅后发布。


一个受控实验问了一个很具体的问题：语言模型从一条冲突指令里恢复过来，是因为它多生成了文本，还是因为它被耦合到了第二个 agent？

上下文变多，还是被耦合到另一个 agent？LLM 自指循环里约束恢复的规模依赖性

一个受控实验：模型从冲突指令中恢复，是因为它多生成了文本，还是因为被耦合到了第二个 agent？答案随规模反转——1.5B 上体量能解释干净（p=.774），7B 上体量彻底失效（X=0%、S=0%），只有耦合能恢复（26.7%，p=.0078）。含可复现脚本，一行命令重算全部 p 值，不需要 GPU。

创始人｜腾讯云同盟架构师

人工智能

编程语言

算法

语言模型从冲突指令恢复的机制随规模反转：1.5B下由生成体量解释，7B下仅双agent耦合有效（26.7%，p=.0078），上下文对齐与剂量均无效。受控实验通过上下文对齐的单体条件拆解体量与耦合效应，提供完全可复现的greedy解码协议与全部原始数据。

代码解释

Python

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

上下文变多，还是被耦合到另一个 agent？LLM 自指循环里约束恢复的规模依赖性-腾讯云开发者社区-腾讯云

上下文变多，还是被耦合到另一个 agent？LLM 自指循环里约束恢复的规模依赖性

上下文变多，还是被耦合到另一个 agent？LLM 自指循环里约束恢复的规模依赖性

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐