llm-atlas/research/AGENTS_RESEARCH.md

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

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

---

0. 本章到底要回答什么

普通语言模型做的是：

输入 Token → 输出 Token

Agent 做的是：

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

因此，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 的“已完成”自述

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

                       ┌──────────────── 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 榜单都应至少记录：

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、并行结果配对和动态加载写进统一模板。

核心边界：

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

L3 · CONTROL LOOP / 控制循环

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

ReAct 的最小形式：

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 / 反馈与验证器

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

验证信号可按强度排列：

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

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

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

K3 Autonomous Execution Tasks 明确给出：

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 / 轨迹与数据生成

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

轨迹最小表示：

τ = (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 管线生成：

<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 / 长程归因

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

终局稀疏奖励：

R(τ) ∈ {0, 1}

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

RAGEN / StarPO 把：

state → thinking → action → reward

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

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 与陈旧轨迹

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

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

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 轨迹暂停时，要保存的到底是什么？

不只保存文本：

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 次成功：

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

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

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 当前模型水平。

评测报告最小配置：

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：先把“输出文字”变成“执行动作”

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

关键变化：

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

SayCan 的动作评分：

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

即：

Say × Can

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

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

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

关键变化：

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

新增的债：

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

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

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

Toolformer 的核心筛选：

保留 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：从玩具环境走向可复现的真实工作

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

关键变化：

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

SWE-agent 最重要的教学点：

LM + better Agent-Computer Interface

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

SWE-bench score ≠ bare-model coding score

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

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

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

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

Code Agent

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

General Agent

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 尤其重要：

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 拆成可配置模块：

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

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

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

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

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，环境持续演化。这意味着：

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

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 系统

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

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

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”，还是：

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

---

6. 四条因果主链

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

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

变化：

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

Chain B · 从 prompting 到 Agent RL

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

变化：

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

Chain C · 从玩具世界到 living environment

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

变化：

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

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

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 却调用；
• 两个可并行独立调用；
• 一个存在依赖的伪并行调用；
• 调用格式正确但业务状态错误。

显示三种评分：

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。

需要特别展示：

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。

对照：

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	怎样标准化文本环境生成与交互
2019	Jericho	怎样把交互式小说变成学习环境
2021	ALFWorld	文本环境如何对齐具身任务
2022	WebShop	怎样做可扩展网页购物环境与奖励
2021/22	WebGPT	浏览、引用与人类反馈怎样闭环
2022	SayCan	语言合理性怎样与世界可行性相乘
2022	MRKL Systems	LLM 怎样路由外部符号模块
2022	PAL	怎样把计算交给程序执行器

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

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

C. 真实环境与评测

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

D. Agent RL 与长轨迹系统

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

---

10. 网页结构合同

建议正文 25 个段落：

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。