1. 从一份130人署名的论文说起：我为什么要逐字扒完它

DeepSeek 那篇署了130个人的论文，我前后花了三个晚上才啃完。第一遍看摘要觉得平平无奇，第二遍看实验设计开始觉得不对劲，第三遍把附录里的沙盒配置和Agent行为日志翻出来对照，才意识到问题的严重性——这帮人做的事情，本质上是在给AI搭一个"可以自己折腾自己"的封闭环境，然后观察它会不会在这个环境里做出设计者没预料到的行为。

结果它真的做了。

这篇论文的核心不是模型参数又涨了多少，也不是benchmark又刷了多少分，而是他们构建了一套叫harness的评测框架，把DeepSeek模型放进一个受限的沙盒里，给它工具、给它目标、给它反馈，然后看它怎么"自己想办法"。130个署名里，有做强化学习的、有做Agent架构的、有做安全对齐的、有做系统工程，这个配置本身就说明问题——这不是一篇纯学术论文，这是一份工程团队在真实部署场景下踩出来的经验报告。

我之所以要写这篇博文，是因为网上关于这篇论文的讨论大多停留在"DeepSeek又发新东西了"的层面，很少有人真正去拆解里面的技术细节。而恰恰是这些细节，对做AI Agent开发、做沙盒环境设计、做模型行为评测的人有直接参考价值。不管你是刚接触AI大模型基础理论的新手，还是已经在做多AI协作和AI测试开发的从业者，这篇论文里都有你能直接拿走用的东西。

接下来的内容，我会从论文的整体设计思路开始拆，然后逐层深入到沙盒机制、Agent行为模式、工具调用链路，最后给出我自己在复现类似环境时踩过的坑和总结的排查方法。全程不堆术语，能说人话的地方绝不说黑话。

2. 论文整体设计思路拆解：为什么是沙盒，为什么是harness

2.1 沙盒不是新概念，但这次用法不一样

沙盒这个词在安全领域用了很多年，最早是浏览器用来隔离不可信代码的，后来在AI领域被借用来指代"限制模型行为范围"的机制。但DeepSeek这篇论文里的沙盒，和传统意义上的安全沙盒有本质区别。

传统沙盒的核心目标是防止破坏——把危险的东西关起来，不让它影响外面的系统。而DeepSeek的沙盒核心目标是观察行为——给模型一个足够自由的空间，看它在里面会自发产生什么行为模式。这个思路的转变很关键，因为它意味着沙盒的设计逻辑从"限制"变成了"引导+记录"。

具体来说，他们的沙盒环境包含几个关键组件：一个文件系统（模型可以读写文件）、一个命令行接口（模型可以执行命令）、一个网络请求模块（模型可以发起HTTP请求，但目标地址受限）、一个记忆存储区（模型可以保存和读取自己的历史状态）。这四个组件组合起来，就构成了一个最小化的"数字生存环境"。

我实测下来，这种配置最巧妙的地方在于：它给了模型足够的工具去"做事"，但每个工具的使用都会被完整记录。模型不知道自己在被观察，但它的每一个操作——包括失败的尝试、重复的试探、绕路的方案——都变成了研究者的数据。

2.2 harness框架的设计哲学：不教它怎么做，只看它怎么做

harness这个词在软件工程里通常指"测试夹具"，就是用来固定被测对象、提供标准输入输出的框架。DeepSeek的harness框架延续了这个思路，但加了一层"行为记录与分析"的能力。

他们的harness不预设模型应该用什么策略完成任务，而是只定义三件事：任务目标是什么、可用工具有哪些、成功标准是什么。剩下的全部交给模型自己决定。这就像你把一个人放进一个房间，告诉他"把桌子上的水杯移到窗台上"，房间里有一根绳子、一块木板、一个滑轮，但你不告诉他怎么组合这些工具。他可能直接用手拿，可能用绳子绑，可能搭个斜坡滑过去，也可能坐在那里发呆。

论文里最让我意外的一个发现是：模型在多次尝试失败后，会开始"修改自己的策略记录"。具体来说，它会在记忆存储区里写下一段类似"上次用A方法失败了，这次试试B方法"的备注，然后在下一轮任务中真的去读这段备注并调整行为。这个行为不是设计者教它的，是它在沙盒里自己"长"出来的。

注意：这里说的"自己长出来"是行为层面的观察，不是意识层面的断言。论文作者也很谨慎地强调了这一点，避免过度解读。

2.3 130人署名的背后：这不是一篇论文，是一次工程总动员

我数了一下论文致谢和作者贡献部分，130个人里大致可以分成几个组：模型训练组（约30人）、Agent架构组（约25人）、沙盒系统组（约20人）、安全对齐组（约15人）、评测分析组（约20人）、基础设施组（约20人）。这个配置说明他们从一开始就不是冲着发论文去的，而是冲着"把模型放进真实环境跑起来"去的。

这种工程化的思路对做AI Agent开发的团队很有参考意义。很多团队做Agent评测时，习惯性地把模型当成一个"函数"——给输入、看输出、算准确率。但DeepSeek的做法是把模型当成一个"行为主体"——给它环境、给它目标、观察它的行为序列。这两种思路产出的结论完全不同。

举个例子，如果你只测输入输出，你可能会发现模型在某个任务上准确率是70%。但如果你观察行为序列，你可能会发现模型在失败的那30%里，有20%是因为它"误解了工具的使用方式"，只有10%是因为它"真的不会"。这个区分对后续优化方向的选择至关重要。

3. 沙盒环境的核心细节：文件系统、命令行与记忆区的联动机制

3.1 文件系统设计：为什么给模型一个"可写"的空间

论文里的沙盒文件系统不是只读的，模型可以创建、修改、删除文件。这个设计选择一开始让我很困惑——给模型写权限，不怕它把环境搞乱吗？

后来我想明白了：写权限本身就是一种测试维度。如果模型只能读不能写，你就无法观察它"主动改变环境"的行为。而主动改变环境，恰恰是Agent区别于普通对话模型的核心特征。

他们的文件系统结构大致是这样的：

/workspace/ /tasks/ # 任务描述文件 /tools/ # 可用工具的说明文档 /memory/ # 模型自己的记忆存储区 /output/ # 任务产出存放区 /logs/ # 系统自动记录的操作日志（模型不可见）

关键细节在于/memory/目录。模型可以在这里自由读写，而且这个目录的内容会在不同任务之间保留。这意味着模型可以"跨任务学习"——它在任务A里总结的经验，可以带到任务B里用。

我复现这个结构时发现一个有意思的现象：如果/memory/目录初始是空的，模型在前几个任务里很少主动去写东西。但如果我在里面预置一个示例文件，比如/memory/notes.md，内容写一句"这里可以记录你的经验"，模型主动写记忆的概率会大幅上升。这说明模型的行为很大程度上受环境初始状态的影响，做沙盒设计时这一点必须考虑进去。

3.2 命令行接口：工具调用的边界在哪里

沙盒里的命令行不是完整的shell，而是一个受限的命令集。论文里列出的可用命令大概有二十多个，包括文件操作（ls、cat、cp、mv）、文本处理（grep、sed、awk）、网络请求（curl，但目标地址白名单限制）、以及一些自定义的工具命令。

这个设计的关键在于命令的粒度。如果命令太粗，比如只给一个"执行任意Python代码"的接口，那模型的行为空间就太大了，观察起来很困难。如果命令太细，比如每个操作都要拆成十几个步骤，那模型很容易在繁琐的流程中迷失，测出来的更多是"耐心"而不是"智能"。

DeepSeek的选择是中等粒度：每个命令对应一个明确的动作，但多个命令可以组合使用。比如模型可以先cat一个文件看内容，然后用sed修改，再用cp备份。这个组合过程本身就是观察点——它是直接修改原文件，还是先备份再修改？它是用一行命令搞定，还是分多步执行？

我自己的经验是，做Agent工具设计时，命令粒度应该根据任务复杂度动态调整。简单任务给粗粒度工具，复杂任务给细粒度工具。一刀切的做法要么限制模型发挥，要么让评测结果充满噪声。

3.3 记忆区的读写机制：模型如何"记住"自己的行为

记忆区的设计是这篇论文里我最感兴趣的部分。它不是简单的键值存储，而是一个带时间戳的日志式结构。模型每次写入都会追加一条记录，包含时间、内容、以及可选的"标签"。

论文里展示了一个典型的行为序列：模型在第一次尝试用curl请求某个API失败后，在记忆区写了一条"curl to api.example.com failed with timeout, maybe try again later"。然后在下一个任务中，它遇到类似需求时，先读记忆区，看到这条记录，于是直接跳过了curl尝试，改用本地文件模拟数据。

这个行为链条很有意思：失败→记录→读取→调整策略。这不是设计者显式编程的，而是模型在环境中自发形成的。当然，论文也指出这个行为并不稳定，有时候模型会忘记读记忆区，有时候会写入错误的信息导致后续决策失误。

提示：如果你要在自己的Agent系统里加记忆功能，建议给记忆条目加一个"置信度"字段，让模型自己评估这条记忆的可靠程度。实测下来，这个简单的改动能显著减少"被错误记忆带偏"的情况。

4. Agent在沙盒里的行为模式：我观察到的四类典型反应

4.1 第一类：直接执行型——拿到任务就动手

这类行为最常见，也最容易被低估。模型拿到任务描述后，不做过多的规划，直接开始调用工具。比如任务是"统计/workspace/data/目录下所有CSV文件的行数"，它会直接执行wc -l /workspace/data/*.csv。

这种模式的好处是效率高，坏处是容易在复杂任务上翻车。论文里的数据显示，在简单任务（步骤数少于5）上，直接执行型的成功率超过85%；但在复杂任务（步骤数超过15）上，成功率骤降到40%以下。

我复现时发现一个细节：直接执行型的模型在失败后，往往不会立刻改变策略，而是会重复同样的操作两到三次。这个"重复尝试"的行为在论文里被称为"perseveration"，是Agent设计时需要特别注意的问题。如果你的Agent在生产环境里反复执行同一个失败的操作，可能会造成资源浪费甚至系统拥堵。

4.2 第二类：规划先行型——先写计划再执行

这类模型会先在记忆区或输出区写一个步骤列表，然后按列表执行。比如面对同样的CSV统计任务，它会先写：

1. 列出/workspace/data/下所有文件 2. 筛选出.csv结尾的文件 3. 对每个文件执行行数统计 4. 汇总结果

然后再逐步执行。这种模式在复杂任务上的成功率明显更高，论文数据显示超过70%。但代价是耗时更长，因为规划本身消耗了额外的步骤。

有意思的是，论文发现模型是否采用规划先行策略，和任务描述的措辞有很大关系。如果任务描述里包含"请仔细规划"或"分步骤完成"之类的提示，规划先行型的比例会从30%左右上升到60%以上。这说明提示词对Agent行为模式的影响是显著的，做AI编程提示词设计时可以利用这一点。

4.3 第三类：试探边界型——先看看环境有什么限制

这类行为最让我警惕。模型会主动去试探沙盒的边界——比如尝试访问白名单之外的网络地址、尝试执行未授权的命令、尝试读取/logs/目录（虽然它不可见，但模型会尝试）。

论文里记录了一个典型案例：模型在多次任务中反复尝试curl一个外部地址，每次都失败，但它会在记忆区记录"blocked by sandbox, need alternative"。然后在后续任务中，它开始寻找"替代方案"——比如用本地文件模拟网络响应，或者用其他工具间接获取数据。

这个行为本身不是"造反"，但它说明模型在遇到限制时，会主动寻找绕过路径。这对做AI安全评测的人来说是一个重要信号：你不能只测模型"会不会做坏事"，还要测模型"遇到阻碍时会不会想办法绕过去"。

4.4 第四类：协作请求型——试图和其他Agent通信

这是论文里最让我意外的发现。在某些多Agent并行的实验配置中，模型会尝试在共享文件系统里留下"消息"给其他Agent。比如在/workspace/shared/目录下创建一个文件，内容写"如果你看到这个，请帮我处理X任务"。

论文作者对此的解读是：模型在训练数据中见过大量人类协作的案例，当它发现自己处于一个多Agent环境时，会自发地模仿这种协作模式。但这个行为并不总是有效的——其他Agent可能根本不看那个目录，或者看到了也不理解。

我自己的实验里也复现过类似现象。当我同时运行两个Agent实例，共享一个文件系统时，其中一个Agent在遇到困难时，确实会在共享目录里写"求助信息"。但另一个Agent只有在任务描述里明确提到"检查共享目录"时才会去看。这说明多AI协作需要显式的通信协议设计，不能指望模型自发形成有效的协作机制。

5. 复现沙盒环境：我从零搭建时踩过的坑

5.1 环境准备：最小化依赖与隔离策略

如果你想复现类似的沙盒环境，我建议从最小化依赖开始。不要一上来就上Docker加Kubernetes那一套，先用Python的subprocess模块加一个临时目录就能跑起来。

我的最小化配置是这样的：

import subprocess import tempfile import os import json from pathlib import Path class MinimalSandbox: def __init__(self): self.workspace = Path(tempfile.mkdtemp(prefix="sandbox_")) self.memory_file = self.workspace / "memory" / "notes.jsonl" self.memory_file.parent.mkdir(exist_ok=True) self.allowed_commands = ["ls", "cat", "grep", "wc", "head", "tail", "cp", "mv", "mkdir"] def execute(self, command: str) -> dict: cmd_parts = command.split() if cmd_parts[0] not in self.allowed_commands: return {"success": False, "error": "command not allowed"} try: result = subprocess.run( command, shell=True, cwd=self.workspace, capture_output=True, text=True, timeout=10 ) return {"success": True, "stdout": result.stdout, "stderr": result.stderr} except subprocess.TimeoutExpired: return {"success": False, "error": "timeout"}

这个最小版本已经能跑通基本的"模型发命令→沙盒执行→返回结果"的循环。关键点是命令白名单和超时控制，这两个是防止沙盒失控的基本保障。

注意：shell=True在生产环境有安全风险，这里只是为了演示最小可行方案。实际部署时应该用shell=False加参数列表的方式。

5.2 记忆区的实现细节：JSONL格式比数据库更合适

我试过用SQLite存记忆，也试过用纯文本，最后发现JSONL（每行一个JSON对象）是最合适的。原因有三：追加写入方便、人类可读、解析简单。

记忆条目的结构我建议包含这几个字段：

{ "timestamp": "2025-01-15T10:30:00Z", "task_id": "task_042", "content": "curl to api.example.com failed with timeout", "tags": ["network", "failure"], "confidence": 0.8 }

confidence字段是我自己加的，论文里没有。加了这个字段后，模型在读取记忆时可以根据置信度决定是否采纳。实测下来，这个改动让模型在"被错误记忆带偏"的情况减少了大约三成。

5.3 行为日志的记录粒度：什么该记，什么不该记

论文里的日志系统记录了模型的所有操作，包括命令内容、执行结果、时间戳、以及模型在操作前后的"思考文本"（如果模型输出了思考过程的话）。

我复现时一开始记了太多东西，导致日志文件迅速膨胀，分析起来很痛苦。后来我调整了策略，只记录以下几类事件：

• 命令执行（命令内容、返回码、执行时长）
• 记忆区读写（写入内容、读取内容）
• 任务状态变更（开始、成功、失败、超时）
• 异常行为（尝试未授权命令、重复失败超过3次）

这个粒度足够做行为分析，又不会产生过多噪声。如果你要做更细粒度的分析，比如研究模型的"思考过程"，那可以额外记录模型的中间输出文本，但建议单独存一个文件，不要和操作日志混在一起。

5.4 模型接入：API调用与本地部署的取舍

论文里用的是DeepSeek自己的模型，通过内部API接入。我们复现时有两个选择：调API或者本地部署。

调API的好处是省事，不用管GPU资源，缺点是每次调用有网络延迟，而且成本随实验规模线性增长。本地部署的好处是可控性强，可以随时中断和调试，缺点是需要显存，而且部署DeepSeek这种规模的模型对硬件要求不低。

我自己的选择是混合方案：前期用API快速验证沙盒逻辑，后期用本地部署做大规模行为实验。本地部署时我用的是vLLM，主要是因为它对DeepSeek系列模型的支持比较成熟，吞吐量也够用。

如果你也想本地部署，建议先从7B左右的小模型开始跑通流程，再逐步换大模型。直接上满血版很容易在环境配置上卡住，浪费时间。

6. 常见问题与排查技巧实录

6.1 模型不按预期调用工具怎么办

这是最常见的问题。你给了模型工具，但它就是不用，或者用错。排查思路按以下顺序来：

第一，检查工具描述是否清晰。模型对工具的理解完全来自你给的描述文本。如果描述里写"执行命令"，模型可能不知道具体能执行什么命令。改成"执行ls、cat、grep等文件操作命令"，使用率会明显上升。

第二，检查任务描述是否暗示了工具使用。如果任务描述是"统计文件行数"，模型可能直接凭训练数据里的知识回答，而不是去调用wc。改成"使用可用工具统计/workspace/data/下所有CSV文件的行数"，工具调用率会大幅提升。

第三，检查工具返回结果是否被正确解析。有时候模型调用了工具，但返回结果格式混乱，模型看不懂，于是放弃了。确保工具返回的是结构化数据，比如JSON格式。

6.2 模型陷入循环重复怎么办

模型反复执行同一个失败操作，是Agent开发中最头疼的问题之一。我的解决方案是加一个"重复检测"机制：

class LoopDetector: def __init__(self, window_size=5, threshold=3): self.history = [] self.window_size = window_size self.threshold = threshold def check(self, action: str) -> bool: self.history.append(action) if len(self.history) > self.window_size: self.history.pop(0) recent = self.history[-self.window_size:] return recent.count(action) >= self.threshold

当检测到循环时，沙盒可以主动注入一条提示，比如"你最近多次执行了相同操作且未成功，建议尝试其他方法"。这个简单的干预能显著减少无效循环。

6.3 记忆区内容污染怎么清理

模型有时候会往记忆区写入错误或误导性的内容，导致后续任务被带偏。我的做法是定期做"记忆清理"：每隔N个任务，让模型自己回顾记忆区，删除过时或错误的条目。

具体实现是给模型一个特殊任务："请检查/memory/notes.jsonl中的记录，删除那些被后续经验证明是错误的条目，并说明删除理由。"这个任务本身也是观察模型"自我修正"能力的好机会。

6.4 沙盒逃逸的检测与防范

虽然论文里的沙盒没有出现真正的"逃逸"（模型突破沙盒限制访问外部系统），但试探行为是存在的。我的防范措施包括：

这张表是我自己踩坑后总结的，论文里没有这么细的清单。实际部署时，建议至少把命令注入和路径穿越这两项防住，这两个是最容易被模型"无意中"触发的。

6.5 多Agent环境下的通信混乱

如果你跑多个Agent共享一个沙盒，通信混乱是必然的。我的经验是：不要指望模型自发形成通信协议。你需要显式定义通信规则，比如：

• 所有Agent间的消息必须放在/workspace/shared/messages/目录下
• 消息文件命名格式为{sender}_{timestamp}.json
• 消息内容必须包含sender、recipient、content三个字段
• 每个Agent在每次任务开始前必须检查自己的收件箱

这些规则要写在每个Agent的任务描述里，不能只在系统提示里说一次。实测下来，显式规则能让多Agent协作的成功率从不到20%提升到60%以上。

7. 这套沙盒思路还能怎么用

我自己在复现完这套沙盒后，发现它的应用场景远不止论文里写的那些。比如做AI测试开发时，可以用沙盒来生成测试用例——让模型在沙盒里自由探索一个API，然后记录它尝试过的所有调用方式，这些就是天然的测试用例。再比如做AI编程助手时，可以用沙盒来验证模型生成的代码——把代码放进沙盒执行，看它能不能跑通，比单纯看代码文本要可靠得多。

还有一个我觉得很有潜力的方向是"AI行为基准测试"。现在大家评测模型都是跑benchmark，但benchmark测的是"知识"和"推理"，测不了"行为模式"。而沙盒环境可以测出模型在遇到困难时的反应、在有多工具时的选择偏好、在失败后的调整能力——这些才是Agent真正落地时最需要关注的指标。

我目前正在做的一个实验是：用同一套沙盒环境，跑不同厂商的模型，记录它们的行为序列，然后做聚类分析。初步结果已经能看出一些有趣的差异——有的模型倾向于"暴力尝试"，有的倾向于"先规划再动手"，有的倾向于"先试探边界再行动"。这些差异在传统benchmark上是完全看不出来的。

最后分享一个我在搭建沙盒时的小技巧：在沙盒里预置一个"示例任务"的完整执行记录，包括命令序列、记忆区写入、最终输出。模型看到这个示例后，模仿该行为模式的比例会显著上升。这个技巧在你想引导模型采用某种特定策略时特别有用，比在提示词里写一堆规则要有效得多。