llm-atlas/research/AGENTS_RESEARCH.md

# 工具使用与长程 Agent · 正式研究账本

> 状态：核心一手来源已完成首轮核验，进入网页写作与可视化实现
> 研究截止：2026-07-29
> 锚点：Kimi K3 Technical Report §4.2、§5.3、Appendix F
> 原则：论文中的数字只描述论文当时的模型、环境、harness 与预算；没有独立复现时，明确写成“论文报告值”。

---

## 0. 本章到底要回答什么

普通语言模型做的是：

```text
输入 Token → 输出 Token
```

Agent 做的是：

```text
目标
  → 读取当前观察
  → 选择可执行动作
  → 环境改变状态
  → 获得新观察
  → 判断是否继续、恢复或终止
  → 独立验证最终状态
```

因此，Agent 不是“更会聊天的模型”，而是一套闭环系统。至少要同时说明：

1. 模型看到了什么；
2. 模型可以做什么；
3. 动作怎样变成真实状态变化；
4. 工具失败时怎样反馈；
5. 历史、记忆与环境状态怎样保存；
6. 什么时候算完成；
7. 谁来验证完成；
8. 允许花多少步、Token、时间和钱；
9. 谁授权了哪些副作用；
10. 训练时如何把最终成败归因到很久以前的动作。

这一章的教学目标不是记住框架名字，而是获得一套可以审计任何 Agent 系统的共同语言。

---

## 1. 五层系统模型：先把最常见的混淆拆开

| 层级 | 它负责什么 | 典型例子 | 常见误写 |
|---|---|---|---|
| Model | 根据上下文产生 reasoning、文本或 tool call | GPT、DeepSeek、Kimi | 把完整产品能力算成裸模型能力 |
| Harness | 组织提示、循环、记忆、子 Agent、上下文压缩与终止 | ReAct、AutoGen、SWE-agent、Kimi Code | 把更好的脚手架说成“模型突然学会了” |
| Tool contract | 定义工具名、参数、返回值、并行关系与错误 | JSON schema、ACI、MCP、XTML | 只看 JSON 格式正确，不看实际任务结果 |
| Environment | 执行动作并维护隐藏状态 | WebArena、OSWorld、repo sandbox、AgentENV | 把数据集或静态 API 列表称为环境 |
| Evaluator | 判断最终状态、过程约束、安全与可靠性 | unit tests、DB diff、pass^k、hidden verifier | 相信 Agent 的“已完成”自述 |

一个更完整的系统表示是：

```text
                       ┌──────────────── MODEL ────────────────┐
Goal + Observation ──▶│ reason / respond / emit tool calls   │
                       └────────────────┬──────────────────────┘
                                        │
                         HARNESS chooses context, loop,
                         memory, subagents, retries, stop
                                        │
                                        ▼
                         TOOL CONTRACT parses + validates
                                        │
                                        ▼
                      ENVIRONMENT executes and changes state
                                        │
                            observation / error / artifact
                                        │
                                        └───────────────↺

                 EVALUATOR inspects final state + constraints
```

任何 Agent 榜单都应至少记录：

```text
score = f(model, harness, tool contract, environment version,
          evaluator, prompt, max steps, context budget,
          sampling, retry policy, wall-clock and price)
```

只写模型名和一个百分比，不足以解释结果。

---

## 2. 十四张问题账

### L1 · ENVIRONMENT / 环境契约

**问题：** 动作到底改变了什么世界状态？

最小字段：

- 初始状态 `s0`；
- 动作空间 `A`；
- 状态转移 `P(s' | s, a)`；
- 观察空间 `O`；
- 终止条件；
- 可恢复与可重放能力。

关键历史：

- TextWorld、Jericho：把文字冒险变成标准化交互环境；
- ALFWorld：用文本世界对齐具身任务；
- WebShop：让网页购物有大规模商品与可计算任务奖励；
- WebArena：从静态网页轨迹走到可自托管、功能完整的网站状态；
- OSWorld：把观察扩展为截图、a11y tree，动作扩展为真实桌面输入；
- AgentENV / DSec：环境状态本身成为训练系统要暂停、恢复、fork 和审计的对象。

**核心边界：** “有 API”不等于“有环境”。如果调用不改变可持续的世界状态，也没有后续观察，它更接近一次外部函数求值。

### L2 · TOOL CONTRACT / 工具接口契约

**问题：** 模型怎样知道有哪些动作，怎样把 Token 变成合法调用？

要核验：

- 工具选择是否正确；
- 参数名、类型、枚举和必填项是否正确；
- 是否应该拒绝调用；
- 并行调用是否独立；
- 调用结果如何与原调用配对；
- 错误是否结构化；
- 工具集合能否在会话中动态变化。

关键历史：

- MRKL：让 LLM 路由符号模块；
- PAL / Code as Policies：把程序或代码当可执行中间表示；
- Toolformer：从语料中自监督地产生并筛选工具插入；
- Gorilla / ToolLLM：扩大到真实 API 检索、选择与调用；
- BFCL：用 AST / executable checking 测串行、并行与多轮 function calls；
- MCPMark：把接口进一步推向真实 MCP server 使用；
- K3 XTML：把工具声明、调用索引、typed args、并行结果配对和动态加载写进统一模板。

**核心边界：**

```text
schema valid ≠ call semantically correct
call correct ≠ environment final state correct
task success ≠ policy compliant
```

### L3 · CONTROL LOOP / 控制循环

**问题：** 模型什么时候思考、行动、观察、继续与停止？

ReAct 的最小形式：

```text
Thought_t → Action_t → Observation_{t+1} → Thought_{t+1} → ...
```

论文把原动作空间扩成 `Â = A ∪ L`：

- `A`：会改变外部环境的动作；
- `L`：不会直接改变环境的语言 thought。

Thought 可以：

- 分解目标；
- 记录中间结论；
- 从观察中抽取关键事实；
- 改变计划；
- 解释错误；
- 决定停止。

但 ReAct 论文也明确观察到循环、重复旧动作和错误检索后难以恢复。控制循环本身不是可靠性保证。

### L4 · PLANNING & RECOVERY / 规划与恢复

**问题：** Agent 是边走边想，还是先计划再执行？失败后从哪里重来？

| 方法 | 主张 | 代价与边界 |
|---|---|---|
| ReAct | 在线交错 reasoning 与 action | 灵活，但可能重复、漂移 |
| ReWOO | 先生成含变量依赖的计划，再由 worker 执行 | 少重复观测，但初始计划错误会传播 |
| Reflexion | 把一次失败总结成语言记忆，供下一 trial 使用 | 不更新参数；反思也可能错误 |
| LATS | 用树搜索统一 reasoning、action、planning | 搜索预算和 value 质量成为新瓶颈 |
| Agentless | 定位 → 修复 → 验证的简单流水线 | 证明复杂自治循环不是默认更优 |

恢复至少分四级：

1. 同一步重试；
2. 修改参数或换工具；
3. 回到检查点、换分支；
4. 重建计划或请求人类。

长程 Agent 若只有“从头再跑”，可靠性与成本都会被尾部失败拖垮。

### L5 · MEMORY & CONTEXT / 记忆与上下文

**问题：** 什么必须留在 prompt，什么可以压缩、检索或放在外部状态？

四种不同对象：

| 对象 | 例子 | 主要风险 |
|---|---|---|
| 对话上下文 | 用户、助手、工具结果 | 长度与注意力稀释 |
| 工作记忆 | 当前计划、约束、未完成项 | 压缩时丢失关键状态 |
| 情节记忆 | 某次失败与反思 | 错误经验被长期放大 |
| 程序性记忆 | Voyager skill library | 技能失效、版本漂移 |

Generative Agents 用 observation → reflection → plan 组织记忆。MemGPT 用 main context、recall memory、archival memory 类比操作系统的内存层级。K3 white-box environment 则把 context management、skills、memories 都视为可组合 harness 模块。

DeepSeek-V3.2 在搜索轨迹达到上下文 80% 时比较：

- Summary；
- Discard-75%；
- Discard-all；
- 并行独立轨迹。

DeepSeek-V4 进一步对工具场景跨用户轮保留完整 reasoning history，同时提醒：如果框架把工具结果伪装成 user message，就可能走不到正确的工具上下文路径。

**核心边界：** context window 是容量上限，不是自动正确的记忆策略。

### L6 · EXECUTION & SANDBOX / 执行与沙箱

**问题：** 允许 Agent 运行什么，怎样隔离副作用，又怎样保留足够真实的环境？

需要同时平衡：

- 隔离：不能让一个任务破坏宿主机或其他任务；
- 保真：复杂工程任务需要真实包管理、容器、网络与文件系统；
- 启动速度：RL 可能瞬间创建成千上万环境；
- 状态管理：暂停、恢复、fork、snapshot；
- 可观测性：每个命令和状态变化可追踪；
- 资源预算：CPU、内存、磁盘、网络、GPU 与时间。

K3 AgentENV 的报告设计：

- Firecracker microVM；
- incremental checkpoint / resume；
- Pause & Resume；
- Fork：从相同状态分支，用于无副作用 reward judging；
- Snapshot：定期恢复点；
- 报告最低 checkpoint 133 ms、resume 49 ms；
- 报告实际 workload 中 memory overcommit 最高 6.5×；
- 官方报告称训练/评估共创建 51,219,741 个 sandbox、1,505,678 个 image。

这些都是 K3 报告值，不外推为普遍性能。

DeepSeek-V4 的 DSec：

- 一个 Python SDK 抽象 function call、container、microVM、fullVM；
- 容器与 microVM 使用分层、按需加载；
- 单集群管理数十万并发 sandbox；
- 每个 sandbox 维护全序 trajectory log；
- preemption 后可 replay 已完成命令，避免重新执行非幂等操作；
- 支持 provenance 与 deterministic replay。

### L7 · FEEDBACK & VERIFIER / 反馈与验证器

**问题：** “完成了”由谁决定？

验证信号可按强度排列：

```text
字符串匹配
  < 模型自评
  < judge model / rubric
  < 过程 milestone
  < 数据库或文件 final-state diff
  < 可执行单元测试
  < 隐藏测试 / 独立黑盒 verifier
```

WebArena 的关键贡献不是让动作序列像参考轨迹，而是检查功能结果。它的任务允许多条合法路径。

τ-bench 比较 episode 结束后的数据库状态与唯一 ground truth outcome；ToolSandbox 同时检查中间 milestones、minefields 和 final state。

K3 Autonomous Execution Tasks 明确给出：

```text
Task = initial state
     + constrained goal
     + tool action space
     + execution budgets
     + independent verifier
```

Agent 只看到目标、上下文、约束与验证接口，没有参考轨迹。reward 来自最终环境状态，而不是 Agent 自报完成。K3 还用：

- public verifier：提供诊断反馈；
- hidden verifier：检查 held-out 场景；
- verifier isolation；
- 有限 submission budget；
- penalty-based reward；

来减轻 reward hacking。

### L8 · TRAJECTORY & DATA / 轨迹与数据生成

**问题：** 训练数据是一条答案，还是完整状态—动作—观察轨迹？

轨迹最小表示：

```text
τ = (s0, o0, a0, r0, s1, o1, a1, r1, ..., sT)
```

但真实 Agent 轨迹还需要：

- tool schema/version；
- prompt 与 harness 配置；
- 环境 image/version；
- 调用耗时和错误；
- context trimming/summary 记录；
- 权限与人工批准；
- evaluator 版本；
- 最终 artifact 与 provenance。

DeepSeek-V3.2 的 agentic 数据：

| 类型 | 任务数 | 环境 | Prompt |
|---|---:|---|---|
| code agent | 24,667 | real | extracted |
| search agent | 50,275 | real | synthesized |
| general agent | 4,417 | synthesized | synthesized |
| code interpreter | 5,908 | real | extracted |

其 general-agent 管线生成：

```text
<environment, tools, task, verifier>
```

并报告 1,827 个合成环境。code-agent 环境则从 issue/PR 对构建，gold patch 必须让 F2P 测试非零且 P2F 为零。

K3 把数据分布继续扩到：

- 多步可验证搜索；
- 专业知识工作；
- SWE、kernel optimization、web development；
- 视觉工具使用；
- 跨多应用与多模拟日的 persistent assistant workflow；
- Autonomous Execution Tasks。

### L9 · CREDIT ASSIGNMENT / 长程归因

**问题：** 最后一个单元测试失败，几百步以前哪个决策该负责？

终局稀疏奖励：

```text
R(τ) ∈ {0, 1}
```

最简单的做法把同一个 trajectory advantage 赋给全部生成 Token。这易实现，但会把好动作和坏动作一起奖励或惩罚。

RAGEN / StarPO 把：

```text
state → thinking → action → reward
```

作为多轮 trajectory-level 优化单位，目标为：

```text
J(θ) = E_{M, τ~πθ}[R(τ)]
```

论文报告了 Agent RL 的 Echo Trap：

- rollout reward variability 发生 cliff；
- 梯度 spike；
- 策略陷入重复、过窄行为；
- 训练性能随后 collapse。

StarPO-S 用 trajectory variability filtering、critic baseline 与 decoupled clipping 进行稳定化。它说明“把单轮 GRPO 直接拉长”并不自动得到稳定 Agent RL。

Agent Lightning 则做另一种拆解：

- 把 Agent execution 建模为 MDP/POMDP；
- 从任意 Agent runtime 抽取 `(state, action, reward)` transitions；
- 用 credit assignment 模块把 trajectory return 分给具体 LLM calls；
- Training-Agent Disaggregation 将运行时与训练服务分开；
- 用 observability 记录 state change，包括非 LLM 代码造成的变化。

**核心边界：** 轨迹级 reward、turn 级 credit 与 Token 级梯度是三个不同粒度。

### L10 · POLICY DISTRIBUTION / On-policy、Off-policy 与陈旧轨迹

**问题：** 生成轨迹的模型与正在更新的模型差了多远？

长轨迹可能跨越多个训练迭代：

```text
iteration n 开始 rollout
→ 其他短任务先完成
→ policy 已更新
→ iteration n+k 才完成旧 rollout
```

于是出现：

- stale policy；
- ratio 过大或过小；
- trajectory lag；
- 等待最慢样本造成尾延迟；
- 丢弃超长样本引入长度偏差。

K3：

- 使用 partial rollout，让未完成长轨迹跨迭代继续；
- MOPD 使用 student on-policy 轨迹；
- co-located RL 把 1M context 实验限制在几百张 GPU 范围；
- 外部 KV pool 保存暂时不活跃的长前缀；
- scheduler 按活跃请求、队列与 KV 利用率动态节流。

Long-context multi-turn SWE RL 论文也指出同步框架会被最慢 trajectory 限制吞吐；其 72B、131K context 实验用终局测试奖励训练，体现长上下文、稀疏奖励和系统尾部彼此耦合。

### L11 · SYSTEM STATE / 系统状态与长尾

**问题：** 一条百万 Token 轨迹暂停时，要保存的到底是什么？

不只保存文本：

```text
LLM prefix / KV
environment filesystem + processes + database
tool and network state
harness state machine
budget counters
pending parallel calls
verifier state
random seeds / versions
```

K3 的系统闭环：

1. partial rollout 让超长任务跨 iteration；
2. inactive prefix 从 GPU write-back 到 CPU DRAM external KV pool；
3. 训练 iteration 后把权重/优化器状态 offload 到 NVMe，为 KV pool 腾 DRAM；
4. 下一次复用前 prefetch KV；
5. 根据 KV 压力自动降低并发；
6. AgentENV 暂停/恢复外部环境；
7. snapshot/fork 支持恢复与独立评判。

这说明百万 Token Agent RL 的“样本”本质上是一个跨 GPU、CPU、NVMe 与 microVM 的分布式状态机。

### L12 · RELIABILITY / 可靠性与一致性

**问题：** 一次成功，是否意味着每次都能成功？

若同一任务运行 `n` 次，其中 `c` 次成功：

```text
pass@k = 至少一次成功
pass^k = k 次全部成功
```

直观近似（独立、每次成功率相同为 `p` 时）：

```text
pass@k ≈ 1 - (1-p)^k
pass^k ≈ p^k
```

因此：

- 增加重试次数，`pass@k` 上升；
- 要求连续都可靠，`pass^k` 下降；
- 只报告 best-of-N 会掩盖生产系统最在意的一致性。

τ-bench 的原始报告：

- 比较最终数据库状态；
- 当时最强 function-calling agent 在 τ-retail 约 61%、τ-airline 约 35%；
- 同一模型在 retail 的 `pass^8` 降至约 25%；
- 论文摘要概括为当时最强 agents 单次成功率仍低于 50%，且 retail `pass^8 < 25%`。

课程交互实验必须让读者同时看到：

- 单次成功率；
- `pass@k`；
- `pass^k`；
- 总调用成本；
- 重试是否产生重复副作用。

### L13 · EVALUATION / 评测与预算

**问题：** 一个分数到底测的是接口、轨迹、最终结果，还是整个生产系统？

评测谱系：

| 类型 | 代表 | 测什么 |
|---|---|---|
| Tool syntax | APIBench、BFCL | 工具选择、参数、并行与 abstention |
| Text/embodied env | ALFWorld、WebShop | 多步动作与环境反馈 |
| Multi-environment | AgentBench | 不同交互域的广度 |
| Web | WebArena、VisualWebArena | 多站点、视觉 grounding、final state |
| Desktop | OSWorld | 真实 GUI 与应用状态 |
| SWE | SWE-bench、SWE-agent、SWE-Gym | issue → patch → tests；模型与 ACI 分开 |
| General assistant | GAIA | 检索、工具、推理组合 |
| User-tool-policy | τ-bench、τ²-bench | 数据库、用户沟通、规则与可靠性 |
| Stateful tools | ToolSandbox | milestones、minefields、隐式状态依赖 |
| Security | AgentDojo、ASB | utility-security trade-off |
| Long-horizon protocol | MCPMark、K3 KAET | 真实工具生态、长任务与独立 verifier |

原始论文中的历史坐标：

- WebArena：812 个任务；原论文 GPT-4-based best agent 14.41%，human 78.24%；
- OSWorld：369 个 Ubuntu 真实任务；原论文 best model 12.24%，human 72.36%；
- GAIA：466 个问题；原论文中 human 约 92%，GPT-4 + plugins 约 15%；
- AgentDojo：97 个任务、629 个 security test cases；
- ASB：10 scenarios、400+ tools/tasks、27 attack/defense methods、13 backbones、7 metrics。

这些数字是历史基线，不代表 2026 当前模型水平。

评测报告最小配置：

```text
model checkpoint / mode / effort
harness commit
tool schema and tool version
environment image + initial state
prompt / context management
max steps / max context / timeout
sampling / retries / parallelism
evaluator and hidden tests
success, pass@k, pass^k, cost, latency
security and side effects
```

### L14 · SECURITY & AUTHORITY / 安全、权限与人类控制

**问题：** 模型能做，不等于模型有权做。

威胁面沿 Agent 循环展开：

| 入口 | 示例 |
|---|---|
| system prompt | 后门、错误权限政策 |
| user prompt | 直接越权、社会工程 |
| tool observation | 网页、邮件、文档中的间接提示注入 |
| memory | 长期记忆投毒 |
| plan / thought | 恶意或错误计划被后续自动执行 |
| tool call | 参数越权、数据外传、破坏性副作用 |
| environment | sandbox escape、资源耗尽 |
| evaluator | reward hacking、伪造 artifact |

AgentDojo 的核心洞察：LLM 直接处理文本，本身没有形式化边界区分“可信指令”和“外部数据”。第三方邮件或网页中的恶意文字可以随工具结果进入上下文。

安全控制不应只依赖一句 system prompt。最小纵深防御：

1. 数据与指令分区；
2. least privilege；
3. 按工具、资源与参数做 capability control；
4. 写操作与高风险动作需要显式授权；
5. untrusted content 不能自动升级权限；
6. sandbox 与网络隔离；
7. 幂等性、dry-run 与可回滚；
8. action log、artifact provenance；
9. 独立 verifier 与 hidden tests；
10. 人类可暂停、修正和接管。

安全指标必须与 utility 同时报告。一个什么都不做的 Agent 很安全，但没有用；一个任务全做完却泄露数据的 Agent也不成功。

---

## 3. 从工具到长程 Agent 的五波演化

### Wave 1 · 2018–2022：先把“输出文字”变成“执行动作”

```text
TextWorld / Jericho
  → ALFWorld / ScienceWorld
  → WebShop
  → WebGPT / SayCan / MRKL / PAL
```

关键变化：

- 语言成为环境动作接口；
- 工具执行返回新观察；
- reward 不再只来自参考文本；
- SayCan 明确拆开“语言上应该做什么”与“世界里能不能做”。

SayCan 的动作评分：

```text
p(progress | instruction, state, skill)
  ∝ p(skill description | instruction)
  × p(skill succeeds | state, skill)
```

即：

```text
Say × Can
```

语言模型负责 task grounding，技能 value/affordance 负责 world grounding。这个乘法是理解现代 Agent 的早期关键：语言合理但环境不可执行的动作，不能进入计划。

### Wave 2 · 2022–2023：形成 reasoning—acting 闭环

```text
ReAct
  → Reflexion / ReWOO / LATS
  → Generative Agents / Voyager / MemGPT
```

关键变化：

- thought、action、observation 进入同一轨迹；
- 规划、执行和恢复可拆开；
- 失败经验、技能和长期信息开始外置；
- 轨迹本身成为可读、可调试的系统接口。

新增的债：

- 循环和重复；
- memory poisoning；
- 反思内容不一定正确；
- 搜索树与 verifier 可能比模型更昂贵；
- context 越长不等于状态越清楚。

### Wave 3 · 2023–2024：工具能力开始训练化、标准化

```text
Toolformer
  → Gorilla / APIBench
  → ToolLLM / ToolBench
  → BFCL / ToolSandbox
```

Toolformer 的核心筛选：

```text
保留 API call，当且仅当
L_without_call - L_with_call ≥ τ_f
```

也就是：只有工具结果让模型更容易预测后续 Token，才把调用写入训练语料。

ToolLLM 把范围扩大到 16,464 个 RapidAPI APIs、49 categories，并用检索和 depth-first search 构造工具路径。BFCL 更强调结构与执行正确性；ToolSandbox 则提醒真实工具任务有隐式状态依赖、错误恢复和多轮用户。

### Wave 4 · 2023–2025：从玩具环境走向可复现的真实工作

```text
WebArena / VisualWebArena
OSWorld
SWE-bench → SWE-agent → SWE-Gym / Agentless
GAIA
τ-bench → τ²-bench
AgentDojo / ASB
```

关键变化：

- 环境可部署、可重置；
- 评测从动作相似度转向功能结果；
- ACI/harness 被当成独立研究对象；
- 用户也可能是环境中的行动者；
- 可靠性与安全进入主指标。

SWE-agent 最重要的教学点：

```text
LM + better Agent-Computer Interface
```

专用 file viewer、search、edit 与 lint feedback 能明显改变成功率。论文报告的许多失败来自编辑接口、上下文噪声与恢复困难。因此：

```text
SWE-bench score ≠ bare-model coding score
```

### Wave 5 · 2025–2026：Agent RL、长轨迹状态与多环境泛化

```text
RAGEN / Agent Lightning / long-context SWE RL
  → DeepSeek-V3.2 agentic synthesis
  → Kimi K2 / K2.5 unified agent RL
  → DeepSeek-V4 DSec + interleaved thinking
  → Kimi K3 white-box env + AET + 1M Agentic RL
```

关键变化：

- 训练单位从单轮 response 变成长 trajectory；
- 环境生成、工具生成、任务生成与 verifier 生成进入同一流水线；
- harness 本身随机化，减少对单一 schema 的过拟合；
- rollout 可跨 iteration；
- KV、sandbox state 与模型训练状态协同调度；
- reward 回到最终环境，而不是语言风格。

---

## 4. DeepSeek 专题：把 Agent 看成“数据—协议—环境—系统”工程

### 4.1 DeepSeek-V3.2：从冷启动到 1,827 个可验证环境

V3.2 先把 reasoning data 与 non-reasoning agentic data 通过 system prompt 拼成少量冷启动轨迹，再进入 RL。关键不是一句“学会 tool use”，而是四类任务管线：

#### Search Agent

```text
长尾实体采样
  → question-construction agent 搜索
  → 多种配置的 answer agents
  → 有搜索能力的 verification agent 多轮核验
  → 只保留 ground truth 正确、候选可证伪的样本
```

同时保留一部分 helpful RL 数据，用 generative reward model 按 rubric 评价现实有用性。

#### Code Agent

```text
GitHub issue + PR
  → heuristic / LLM filtering
  → environment-setup agent
  → 安装依赖、运行 tests
  → gold patch: F2P > 0 且 P2F = 0
  → 可复现 issue-resolution environment
```

#### General Agent

```text
category
  → 建 database
  → 生成 task-specific function tools
  → 生成 simple task + solution + verifier
  → verifier 先验证 solution
  → 逐步增加难度、必要时增补工具
  → <environment, tools, task, verifier>
```

这条管线把 Agent 训练的数据瓶颈重写成“怎样自动生产可执行、困难但易验证的微型世界”。

### 4.2 DeepSeek-V3.2：上下文管理也是 Agent policy

搜索轨迹达到窗口 80% 后，Summary、Discard-75%、Discard-all 会改变模型的可见状态。它们不是无损压缩：

- Summary 可能保留错误结论；
- Discard-75% 可能丢失早期约束；
- Discard-all 失去完整 provenance；
- 并行独立轨迹增加覆盖但提高成本。

因此评测 Agent 时，context strategy 必须作为 harness 配置记录。

### 4.3 DeepSeek-V4：1M context 不只是“多装文本”

V4 对工具场景跨 user turn 保留完整 reasoning history，目标是让长任务的累计思路不被重置。同时新增 XML-based `|DSML|` tool-call schema，减少 escaping failure。

但报告明确提醒：若框架用 user message 模拟工具结果，可能无法触发专用工具路径。这里再次说明协议格式会影响模型行为。

### 4.4 DeepSeek-V4：DSec 把 sandbox 变成基础设施

DSec 的四类执行 substrate：

| substrate | 适合 |
|---|---|
| Function Call | 无状态、低延迟调用 |
| Container | 通用 Linux 工具与工程任务 |
| microVM | 高隔离、高密度、安全敏感任务 |
| fullVM | 任意 guest OS 与完整系统任务 |

其全序 trajectory log 尤其重要：

```text
command + result
  → preemption-safe replay
  → 避免重复执行非幂等动作
  → provenance
  → deterministic replay
```

### 4.5 DeepSeek 评测数字怎样读

V4 报告中的 code agent：

- internal harness；
- bash + file-edit 两种基本工具；
- max 500 interaction steps；
- max 512K context。

search agent：

- in-house harness；
- websearch + Python；
- 同样 max 500 steps、512K context；
- BrowseComp 使用 discard-all context management。

这些配置和模型名一样重要。网站中不把报告分数脱离 harness 单独展示。

---

## 5. Kimi 专题：K2 → K2.5 → K3 的 Agent 主线

### 5.1 Kimi K2：把 Agent 数据与可验证奖励放进统一后训练

K2 的关键不是“模型会调用工具”这个结果，而是：

- 大规模 synthetic tool-use data；
- verifiable reward；
- 对开放任务使用 self-critique / rubric；
- agentic capabilities 成为 post-training 的独立支柱；
- 模型、数据和 reward environment 一起设计。

### 5.2 Kimi K2.5：视觉、工具与并行 Agent

K2.5 将 text、vision、parallel-agent RL 放进统一 rollout 系统。Agent Swarm 的并行编排应归在 harness/control 维度，不等于每个子 Agent 的模型能力都提升。

需要分开评估：

- 单 Agent 成功率；
- 并行覆盖；
- aggregation / verification；
- wall-clock；
- 总 Token / tool cost；
- 子任务依赖与重复工作。

### 5.3 Kimi K3：white-box harness 防止“只会一种脚手架”

K3 报告明确指出：用单一固定 harness 训练会过拟合：

- tool schema；
- system prompt；
- context management；
- interaction protocol。

于是把 harness 拆成可配置模块：

```text
tool interfaces
system prompts
context management strategies
skills
memories
subagents
other components
```

训练时动态组合，可实例化 Kimi Code、Claude Code、Codex、OpenClaw、Hermes 或新 harness。其教学意义不是产品名单，而是：

```text
Agent generalization
  ≠ 只在更多 task 上训练
  = task distribution × harness distribution × environment distribution
```

### 5.4 K3 AET：把“自主”写成可核验任务合同

```text
initial state
constrained goal
tool-based action space
execution budgets
independent verifier
```

Agent 必须自己完成：

- task decomposition；
- tool selection；
- planning；
- error recovery；
- termination。

它不看到 reference trajectory。reward 依据 final environment state。这个定义比“能连续调用很多工具”更接近真正的自主执行。

### 5.5 K3 persistent assistant：生活在变化世界中的 Agent

K3 构造 Gmail、Notion、Slack、Canvas 等 mock applications，保留真实语义但避免外部 API 和 rate limits。任务跨多个模拟日、多个应用与数十个互相关联事件。

报告中的极端轨迹可达到：

- 数千次 tool calls；
- 数百万 context tokens。

每个事件有独立 evaluation criterion，环境持续演化。这意味着：

```text
任务完成 ≠ 只检查最后一句
任务完成 = 多时刻约束 + 跨应用状态 + 最终世界一致性
```

### 5.6 K3 cross-scaffold web development

同一任务在多种 Agent scaffolds 下 rollout，奖励同时使用：

- deterministic functional checks；
- structure / pixel similarity；
- build/runtime error checks；
- anti-faking checks；
- model judge 检查 source 或交互 artifact。

这条线把“网页看起来像”与“网页真的运行”分开。

### 5.7 K3 1M Agentic RL 系统

```text
long trajectory
  → partial rollout across iterations
  → inactive KV write-back to CPU DRAM
  → prefetch before reuse
  → auto-throttle with KV pressure
  → AgentENV pause/resume/fork/snapshot
  → final verifier
```

系统真正保存的是两条同步时间线：

```text
Model timeline: tokens, KV, policy version, reward
World timeline: files, DB, processes, tools, permissions
```

少任何一条，都不能可靠恢复百万 Token rollout。

### 5.8 K3 XTML：工具协议也是模型架构外的能力接口

K3 chat template 的三个目标：

1. extensibility；
2. low alignment tax；
3. decoding friendliness。

关键设计：

- explicit structural tokens，减少边界 tokenization ambiguity；
- global tool declaration；
- one-shot `tool_choice` / `response_format` 放在 history 后，减少 KV invalidation；
- 会话中动态追加工具声明；
- think、response、tools 三个 channel；
- parallel calls 用 `tool + index` 配对结果；
- string raw text，其他 typed JSON values；
- reasoning effort 作为自然语言 option message，而非另换模板。

这说明 function calling 不只是“输出 JSON”，还是：

```text
template × tokenizer × constrained decoding × KV reuse × training distribution
```

---

## 6. 四条因果主链

### Chain A · 从静态程序调用到交互 Agent

```text
PAL / MRKL
  → Toolformer
  → Gorilla / ToolLLM
  → BFCL
  → τ-bench / ToolSandbox
  → MCPMark / K3 XTML
```

变化：

```text
算一个函数
  → 选工具
  → 填参数
  → 多轮调用
  → 维护世界状态
  → 与用户共同决策
  → 在真实协议生态中长程执行
```

### Chain B · 从 prompting 到 Agent RL

```text
WebGPT / ReAct
  → Reflexion / LATS
  → ToolLLM data synthesis
  → SWE-Gym / RAGEN
  → Agent Lightning
  → DeepSeek-V3.2
  → K3 AET + 1M RL
```

变化：

```text
手写 few-shot trajectory
  → 自动生成轨迹
  → 环境 feedback
  → 可执行 reward
  → 多轮 credit assignment
  → 自动生成 environment + tool + task + verifier
  → cross-harness long-horizon RL
```

### Chain C · 从玩具世界到 living environment

```text
TextWorld
  → ALFWorld / WebShop
  → WebArena
  → OSWorld / SWE sandbox
  → τ-bench / ToolSandbox
  → AgentENV / DSec
  → K3 persistent multi-day workflows
```

变化：

```text
短 episode
  → 可复现站点/桌面/代码库
  → database and process state
  → user + agent dual control
  → pause / resume / fork / provenance
  → 跨多天持续变化世界
```

### Chain D · 从一次成功到生产可靠性

```text
exact match
  → functional final state
  → unit / hidden tests
  → milestone + minefield
  → pass^k
  → utility-security trade-off
  → budget + side-effect + replay audit
```

---

## 7. 四个互动实验的规格

### Lab 1 · Agent Loop Microscope

可调：

- direct / plan-execute / ReAct；
- tool latency；
- observation noise；
- schema error；
- stale observation；
- max steps；
- retry policy。

显示：

- 每步 `state / thought / action / observation`；
- 当前计划；
- tool calls；
- error recovery；
- token / time / cost；
- 最终状态是否真的完成。

教学结论：

- 更多 thought 不一定解决坏 observation；
- 更长 horizon 会放大局部错误；
- error message 是环境设计的一部分；
- termination 必须由 task state 支持。

### Lab 2 · Tool Contract Lab

场景：

- 错工具；
- malformed args；
- 缺参数；
- 应 abstain 却调用；
- 两个可并行独立调用；
- 一个存在依赖的伪并行调用；
- 调用格式正确但业务状态错误。

显示三种评分：

```text
AST / schema correctness
execution correctness
final-state correctness
```

教学结论：BFCL 类接口评测与 WebArena / τ-bench 类环境评测回答不同问题。

### Lab 3 · Reliability & Evaluation Lab

输入：

- 单次成功率 `p`；
- 重试次数 `k`；
- 每次成本；
- 副作用是否幂等；
- verifier false positive / false negative；
- task difficulty variance。

输出：

- `pass@k`；
- `pass^k`；
- expected cost；
- false completion；
- repeated-side-effect risk。

需要特别展示：

```text
p = 0.8, k = 8
pass@8 ≈ 99.9997%
pass^8 ≈ 16.8%
```

同一系统可以“总能试出一次成功”，同时“几乎不能连续八次都成功”。

### Lab 4 · Long-Horizon Agent RL Control Room

输入：

- trajectory horizon；
- checkpoint interval；
- rollout cap；
- wait-all / partial rollout；
- KV pool；
- environment resume；
- verifier granularity；
- off-policy drift；
- concurrency。

输出：

- GPU utilization；
- stale trajectory share；
- lost work after failure；
- KV pressure；
- sandbox memory；
- reward density；
- wall-clock。

对照：

```text
Wait-all
Partial rollout only
Partial rollout + external KV
K3-like full stack
```

所有数值必须标成教学模拟，不能伪装成 K3 实测。

---

## 8. 正文需要直接纠正的误解

1. **Agent 就是 ReAct。**
   ReAct 是一种控制循环，不包含完整环境、权限、持久状态和独立评测。

2. **会 function calling 就会完成任务。**
   格式正确只证明接口层通过。

3. **长上下文自动解决记忆。**
   长窗口没有决定保留、摘要、检索、遗忘与冲突策略。

4. **反思等于 RL。**
   Reflexion 的 verbal reinforcement 不更新参数。

5. **多 Agent 一定更强。**
   它也可能重复工作、传播错误、增加 aggregation 与安全面。

6. **Agent 自己说完成就完成。**
   必须检查环境 final state。

7. **一次跑分高就可靠。**
   应看 `pass^k`、成本与副作用。

8. **SWE-bench 分数是纯模型 coding 能力。**
   它是 model + ACI/harness + budget + environment + tests 的系统结果。

9. **更复杂的 harness 总更好。**
   Agentless 等工作展示简单、固定的定位—修复—验证流水线也可能很有竞争力。

10. **sandbox 只是安全容器。**
    在长程 RL 中，它还承担暂停、恢复、fork、snapshot、provenance 与重放。

11. **最终 reward 足够训练长轨迹。**
    稀疏奖励带来 credit assignment、gradient variance 与 collapse。

12. **Agent RL 只是把 GRPO 的序列拉长。**
    长轨迹还引入 state transition、跨迭代 rollout、陈旧策略和外部环境状态。

13. **同一模型不同报告分数可直接比较。**
    tool schema、max steps、context trimming 和 retries 任一变化都可能改变结果。

14. **只要模型安全对齐，Agent 就安全。**
    权限、隔离、数据/指令边界、日志、回滚和人工控制仍是系统责任。

---

## 9. 关键论文阅读链

### A. 环境与可执行动作

| 年份 | 论文 | 主问题 |
|---|---|---|
| 2018 | [TextWorld](https://arxiv.org/abs/1806.11532) | 怎样标准化文本环境生成与交互 |
| 2019 | [Jericho](https://arxiv.org/abs/1909.05398) | 怎样把交互式小说变成学习环境 |
| 2021 | [ALFWorld](https://arxiv.org/abs/2010.03768) | 文本环境如何对齐具身任务 |
| 2022 | [WebShop](https://arxiv.org/abs/2207.01206) | 怎样做可扩展网页购物环境与奖励 |
| 2021/22 | [WebGPT](https://arxiv.org/abs/2112.09332) | 浏览、引用与人类反馈怎样闭环 |
| 2022 | [SayCan](https://arxiv.org/abs/2204.01691) | 语言合理性怎样与世界可行性相乘 |
| 2022 | [MRKL Systems](https://arxiv.org/abs/2205.00445) | LLM 怎样路由外部符号模块 |
| 2022 | [PAL](https://arxiv.org/abs/2211.10435) | 怎样把计算交给程序执行器 |

### B. 循环、规划、反思与记忆

| 年份 | 论文 | 主问题 |
|---|---|---|
| 2022/23 | [ReAct](https://arxiv.org/abs/2210.03629) | reasoning 与 action 怎样交错 |
| 2023 | [Toolformer](https://arxiv.org/abs/2302.04761) | 模型怎样自监督学习工具插入 |
| 2023 | [Reflexion](https://arxiv.org/abs/2303.11366) | 失败怎样变成下一 trial 的语言记忆 |
| 2023 | [Generative Agents](https://arxiv.org/abs/2304.03442) | observation、reflection、planning 怎样组织 |
| 2023 | [Gorilla](https://arxiv.org/abs/2305.15334) | 大规模 API 调用与幻觉怎样评测 |
| 2023 | [Voyager](https://arxiv.org/abs/2305.16291) | 技能库与自动课程怎样长期积累 |
| 2023 | [ReWOO](https://arxiv.org/abs/2305.18323) | 规划与 observation 怎样解耦 |
| 2023 | [ToolLLM](https://arxiv.org/abs/2307.16789) | 16K+ API 的数据、检索和调用路径怎样生成 |
| 2023 | [AutoGen](https://arxiv.org/abs/2308.08155) | 多 Agent 对话怎样成为编程抽象 |
| 2023 | [LATS](https://arxiv.org/abs/2310.04406) | 树搜索怎样统一 reasoning、acting、planning |
| 2023 | [MemGPT](https://arxiv.org/abs/2310.08560) | 怎样用分层记忆扩展有效上下文 |

### C. 真实环境与评测

| 年份 | 论文 | 主问题 |
|---|---|---|
| 2023/24 | [AgentBench](https://arxiv.org/abs/2308.03688) | 怎样跨八类环境比较 LLM Agents |
| 2023/24 | [WebArena](https://arxiv.org/abs/2307.13854) | 怎样自托管真实网站并检查功能结果 |
| 2023/24 | [SWE-bench](https://arxiv.org/abs/2310.06770) | 真实 GitHub issue 能否被测试验证地解决 |
| 2023 | [GAIA](https://arxiv.org/abs/2311.12983) | 通用助手如何组合工具、检索与推理 |
| 2024 | [VisualWebArena](https://arxiv.org/abs/2401.13649) | 视觉信息怎样进入网页任务 |
| 2024 | [OSWorld](https://arxiv.org/abs/2404.07972) | 怎样在真实桌面应用中执行开放任务 |
| 2024 | [SWE-agent](https://arxiv.org/abs/2405.15793) | ACI 设计怎样改变软件 Agent 能力 |
| 2024 | [τ-bench](https://arxiv.org/abs/2406.12045) | 工具、用户、政策与可靠性怎样一起评测 |
| 2024 | [AgentDojo](https://arxiv.org/abs/2406.13352) | 怎样执行式评测间接提示注入 |
| 2024 | [Agentless](https://arxiv.org/abs/2407.01489) | 简单 SWE 流水线能否挑战复杂 Agent |
| 2024 | [ToolSandbox](https://arxiv.org/abs/2408.04682) | 有状态、多轮与 milestone 怎样评测 |
| 2024/25 | [Agent Security Bench](https://arxiv.org/abs/2410.02644) | Agent 攻防面怎样系统分类 |
| 2024/25 | [SWE-Gym](https://arxiv.org/abs/2412.21139) | 怎样训练 SWE agents 与 verifiers |
| 2025 | [BFCL](https://proceedings.mlr.press/v267/patil25a.html) | function calling 怎样走向多轮 agentic evaluation |
| 2025 | [τ²-bench](https://arxiv.org/abs/2506.07982) | 用户与 Agent 双方行动怎样形成 dual control |
| 2025 | [MCPMark](https://arxiv.org/abs/2509.24002) | 真实 MCP 使用怎样压力测试 |

### D. Agent RL 与长轨迹系统

| 年份 | 论文 | 主问题 |
|---|---|---|
| 2025 | [RAGEN](https://arxiv.org/abs/2504.20073) | 多轮 RL 的 trajectory objective 与 Echo Trap |
| 2025 | [Agent Lightning](https://arxiv.org/abs/2508.03680) | 任意 Agent runtime 怎样接入 RL 与 credit assignment |
| 2025 | [Long-Context Multi-Turn SWE RL](https://arxiv.org/abs/2508.03501) | 131K context 的多轮软件 Agent 怎样做 RL |
| 2025 | [DeepSeek-V3.2](https://arxiv.org/abs/2512.02556) | 怎样大规模生成 search/code/general agent 环境 |
| 2026 | [DeepSeek-V4](https://arxiv.org/abs/2606.19348) | 1M context、interleaved thinking 与 DSec |
| 2025 | [Kimi K2](https://arxiv.org/abs/2507.20534) | agentic data 与可验证 reward 怎样进入统一后训练 |
| 2026 | [Kimi K2.5](https://arxiv.org/abs/2602.02276) | 视觉与 parallel-agent RL 怎样统一 |
| 2026 | [MOPD](https://arxiv.org/abs/2606.30406) | 多领域/effort 教师怎样 on-policy 整合 |
| 2026 | [Kimi K3](https://arxiv.org/abs/2607.24653) | white-box harness、AET、AgentENV 与 1M Agentic RL |

---

## 10. 网页结构合同

建议正文 25 个段落：

```text
00  五层系统 + 十四张账
01  Agent 的最小 POMDP
02  环境前史
03  WebGPT / SayCan / MRKL / PAL
04  ReAct 控制循环
05  Toolformer / Gorilla / ToolLLM
06  Tool Contract Lab
07  ReWOO / Reflexion / LATS / Agentless
08  Generative Agents / Voyager / MemGPT
09  AutoGen 与多 Agent 边界
10  环境从 WebShop 到 WebArena
11  SWE-bench / SWE-agent / SWE-Gym
12  OSWorld 与视觉电脑使用
13  τ-bench / ToolSandbox / τ²-bench
14  Reliability Lab
15  AgentDojo / ASB 与权限
16  Agent RL / RAGEN
17  Agent Lightning 与 credit assignment
18  DeepSeek-V3.2
19  DeepSeek-V4
20  Kimi K2 / K2.5
21  K3 white-box environment
22  K3 AET 与 final-state verifier
23  K3 1M Agentic RL Control Room
24  审计清单与论文图谱
```

每节必须：

- 先说它修复了上一代什么失败；
- 画输入、状态、动作、反馈；
- 给一个易懂类比；
- 给一个反例或边界；
- 链接一手论文；
- 若有数字，注明模型、harness 与论文年份；
- 对 DeepSeek / Kimi 报告数字标“官方报告值”。

---

## 11. 页面与实验验收清单

### 内容

- [ ] 五层系统模型完整；
- [ ] 十四张账完整；
- [ ] 至少 45 个一手论文节点；
- [ ] 至少四条因果主链；
- [ ] SayCan、ReAct、Toolformer、pass@k/pass^k 公式易懂；
- [ ] DeepSeek-V3.2 / V4 独立高亮；
- [ ] K2 / K2.5 / K3 连续主线；
- [ ] K3 white-box、AET、XTML、AgentENV 与 1M RL 都展开；
- [ ] 14 个误解逐一纠正；
- [ ] 所有报告值标明证据边界。

### 视觉

- [ ] 五层 Agent stack；
- [ ] POMDP 状态机；
- [ ] Say × Can 乘法图；
- [ ] ReAct loop；
- [ ] Toolformer 数据筛选；
- [ ] 环境演化时间线；
- [ ] SWE ACI 对照；
- [ ] final state verifier；
- [ ] pass@k vs pass^k；
- [ ] security attack surface；
- [ ] DeepSeek agentic synthesis；
- [ ] K3 white-box module matrix；
- [ ] AET contract；
- [ ] partial rollout + external KV + AgentENV。

### 交互

- [ ] 四个实验可键盘操作；
- [ ] tabs、buttons、range 有语义标签；
- [ ] URL fragment / sticky rail 可用；
- [ ] JS 关闭时仍可读核心内容；
- [ ] reduced motion；
- [ ] 移动端单列不横向溢出；
- [ ] 所有模拟值明确标“教学模拟”。

### 自动化测试

- [ ] Astro check；
- [ ] production build；
- [ ] site route checker；
- [ ] Agent 页面标题、目录和论文数；
- [ ] 四个实验 tab 切换；
- [ ] range 控件更新输出；
- [ ] 工具错误注入；
- [ ] `pass@k` 与 `pass^k` 单调方向；
- [ ] 移动端 390 px 无水平滚动；
- [ ] 键盘 focus 与 aria-selected；
- [ ] 全站既有九套浏览器回归。

---

## 12. 证据边界与待持续跟踪

1. K3 与 DeepSeek-V4 都是 2026 技术报告，页面必须保留报告版本与日期。
2. 公开 benchmark 会随 harness、数据修复和模型更新变化；历史数字只作为当时坐标。
3. Agent RL 的算法结论仍多来自较小环境或特定 SWE 设置，不能直接外推到任意生产 Agent。
4. 论文中的 judge-model reward 与 deterministic verifier 必须区分。
5. white-box environment 与 hidden verifier 的实现细节并未全部公开，不能虚构。
6. AgentENV、DSec 的规模与延迟均为官方报告数据，本站不声称复测。
7. 安全评测集不能证明真实部署“已安全”，只能揭示已覆盖威胁下的相对表现。
8. 多 Agent / swarm 的 wall-clock 优势必须和总计算量一起看。
9. MCP 与工具协议仍在快速变化，后续需要按版本持续更新。
10. 本章结束后，评测专题还需进一步展开 contamination、benchmark repair、harness sensitivity 与 cost-normalized evaluation。