SanityHarness：为AI代码智能体设计的标准化评估系统

1. 项目概述：一个为代码智能体设计的“高考考场”

如果你正在开发或使用一个AI编程助手（比如Claude Code、GitHub Copilot、或者任何能写代码的AI Agent），你肯定想知道：这家伙到底靠不靠谱？它写的代码是能直接跑起来，还是充满了隐藏的Bug？面对不同语言、不同难度的任务，它的表现稳定吗？

这就是SanityHarness要解决的问题。你可以把它理解为一个专为“代码智能体”设计的标准化“高考考场”。它不是一个简单的单元测试框架，而是一个完整的、隔离的、可复现的评估系统。它的核心目标很简单：给任何声称能写代码的AI Agent出一套公平、全面、有挑战性的“试卷”，然后在一个绝对干净、受控的环境里批改打分，最后给你一份详尽的“成绩单”。

我花了相当长的时间去研究和使用各种AI编程工具，发现一个普遍痛点：评估标准太主观了。有人说“这个Agent帮我写了个函数”，但没人知道这个函数在边缘情况下的表现，或者换一种语言它是否还能胜任。SanityHarness通过一套精心设计的任务集（目前涵盖Go、Rust、TypeScript等6种语言，26个任务），将主观评价变成了客观数据。每个任务都运行在独立的Docker容器中，确保环境一致；它使用加权评分系统，根据任务难度调整分值，让结果更具可比性；甚至还有密码学完整性校验（BLAKE3哈希），防止结果被篡改，确保评估的公正性。

无论你是AI Agent的开发者，想量化自己产品的进步；还是最终用户，想挑选最适合自己技术栈的编程助手；亦或是研究者，需要一套可靠的基准来对比不同模型，SanityHarness都提供了一个现成的、开箱即用的解决方案。它轻量、高效，并且设计上力求与任何遵循命令行接口规范的代码智能体兼容。接下来，我就带你深入这个“考场”的内部，看看它是如何工作的，以及如何用它来获得真正有说服力的评估结果。

2. 核心设计思路：为什么是“隔离容器”与“加权评分”？

在构建一个评估系统时，首要任务是保证公平性和可重复性。SanityHarness的设计哲学紧紧围绕着这两个核心原则展开，其架构选择背后有非常实际的工程考量。

2.1 基于Docker的绝对环境隔离

为什么不用虚拟机、Kubernetes Pod，或者干脆在宿主机上跑？Docker容器在这里是一个平衡了隔离性、启动速度和资源开销的完美选择。

隔离性的必要性：AI Agent在生成代码时，其行为是不可预测的。一个任务中的代码可能会意外修改系统文件、安装全局依赖，或者留下一些残留进程，从而污染环境并影响后续任务的评估。例如，一个Go任务可能通过go get安装了某个特定版本的库，如果下一个Rust任务也依赖系统路径，就可能产生冲突。Docker容器为每个任务提供了一个从文件系统到进程空间完全独立的沙箱，确保每个任务都从一张“白纸”开始。

“Sleep Infinity”容器策略：SanityHarness采用了一个巧妙的优化。它并非为每次测试运行都启动和销毁一个容器，而是先启动一个执行sleep infinity命令的基础容器。当需要运行测试命令（如go test）时，它使用docker exec在这个“长眠”的容器内执行命令。这样做的好处是：

1. 极速复用：避免了每次运行都承受完整的容器启动（拉镜像、创建网络、初始化等）开销，对于需要多次尝试（max_attempts）的任务，速度提升非常明显。
2. 状态保持：虽然工作目录（/workspace）是每次挂载的，但容器内部的语言工具链缓存（如Go的GOCACHE）可以得以保留，进一步加速构建过程。
3. 资源管理：单个长期存在的容器比频繁创建销毁多个容器更容易管理，也减少了Docker守护进程的负担。

用户权限映射：这是一个容易被忽略但至关重要的细节。默认情况下，Docker容器内以root用户运行，这会导致在宿主机上生成的文件所有权为root，引发权限问题。SanityHarness在运行容器时，会通过-u参数将宿主机当前用户的UID和GID映射到容器内，这样在/workspace中创建的所有文件，其所有者都是你本人，避免了恼人的sudo chown操作。

2.2 精心设计的任务体系与加权评分

评估不是跑通几个“Hello World”就完事了。SanityHarness的任务库是其价值的核心。

任务设计理念：这里的任务不是简单的算法题（如LeetCode）。它们更贴近真实的工程场景，例如：

• Go/bank-account：模拟一个银行账户系统，需要处理并发存款、取款和余额查询，考验对Go协程和锁的正确使用。
• Rust/parser-combinator：实现一个简单的解析器组合子库，涉及复杂的泛型和生命周期，是检验Rust掌握程度的试金石。
• TypeScript/react-hook：实现一个自定义的React Hook，需要理解闭包、状态管理和副作用清理。

这些任务被分为不同的层级（Tier）（如core,extended）和难度（Difficulty）（如Hard,Expert）。core层级的任务是评估一个Agent是否“合格”的基础，而extended层级则用于挑战其上限。

加权评分系统：这是实现“公平比较”的关键。不同任务的难度天差地别。让一个Agent在简单的字符串处理任务上得满分，和在复杂的并发任务上得满分，其含金量是不同的。SanityHarness为每个任务赋予一个难度权重因子。这个因子是基于经验（可能是维护者社区的共识或历史数据）得出的。最终得分不是简单的(通过测试数 / 总测试数)，而是Σ(任务得分 * 难度权重)。这意味着，一个在少数高难度任务上表现优异的Agent，其总分可能超过一个在大量简单任务上表现平平的Agent，这更符合我们对“能力强”的直观认知。

隐藏测试（Hidden Tests）：这是防止Agent“过拟合”或“死记硬背”答案的重要机制。在任务初始化时，Agent只能看到一部分公开的测试用例。还有另一部分“隐藏测试”在评估时才被动态注入到测试环境中。这确保了Agent必须生成真正通用、健壮的解决方案，而不是仅仅针对已知的测试用例进行特化编码。--legacy模式就是为了兼容早期一个让隐藏测试意外暴露的Bug而存在的，用于复现或对比历史评估数据。

2.3 对Agent的严格沙箱化

sanity eval命令的核心是自动化地驱使AI Agent去完成任务。为了防止Agent“作弊”或产生副作用，SanityHarness构建了双重隔离防线。

第一道防线：临时工作空间隔离。在执行eval时，Agent并非直接在结果目录（eval-results/）下运行。系统会为它在/tmp下创建一个临时的、独立的工作空间。Agent在这个沙箱中读写文件、执行命令。任务完成后，系统才将相关文件复制回最终的eval-results/目录进行验证。这彻底杜绝了Agent偷看其他任务答案、查阅自己之前的日志（agent.log）或利用兄弟任务解决方案的可能性。

第二道防线：Bubblewrap进程沙箱。这是更底层的隔离。如果系统安装了bubblewrap，SanityHarness会用它来启动Agent进程。Bubblewrap利用Linux命名空间（namespace）技术，可以：

• 将Agent的$HOME目录设置为只读。
• 通过配置（shared_readwrite_dirs,shared_readonly_dirs）严格限制Agent可以访问的宿主目录。
• 使用--tmpfs /tmp为Agent提供一个内存临时文件系统，进一步隔离。
• 屏蔽（mask）非允许的敏感路径（如/proc,/sys中的特定部分）。

这意味着，即使Agent被恶意提示或自身存在缺陷，试图执行rm -rf /或读取敏感配置文件，也会被限制在沙箱内，无法对宿主机造成影响。你可以通过--no-sandbox禁用此功能，但在进行自动化或不可信Agent评估时，强烈建议保持开启。

实操心得：隔离的价值：在一次内部测试中，我们用一个早期版本的Agent（没有沙箱）评估多个任务。这个Agent有个坏习惯：会在工作目录外创建一个.cache文件夹。在连续评估几个任务后，这个.cache被后续任务读到，导致了一些诡异的、依赖缓存的状态问题，使得结果不可靠。启用工作空间隔离和Bubblewrap后，这类“交叉污染”问题被彻底根除，每次评估都像是Agent的“第一次”尝试，数据纯净度大大提升。

3. 从零开始：安装、配置与初体验

理论说得再多，不如亲手运行一次。让我们一步步搭建起SanityHarness环境，并完成第一次评估。

3.1 环境准备与安装

系统前提：你需要一个运行Linux或macOS（通过Docker Desktop）的系统。Windows用户可以通过WSL2获得完整体验。

核心依赖：

1. Go 1.25+：SanityHarness本身是用Go编写的。安装最新稳定版的Go即可。
2. Docker Daemon：确保Docker服务正在运行，并且当前用户有权限执行docker命令（通常需要加入docker用户组）。
3. Bubblewrap（可选但推荐）：用于增强的Agent沙箱。在Ubuntu/Debian上可通过sudo apt install bubblewrap安装。

安装SanityHarness： 最直接的方式是从源码构建，这能确保你获得最新特性。

# 1. 克隆仓库 git clone https://github.com/lemon07r/sanityharness.git cd sanityharness # 2. 安装开发工具（首次运行） make tools # 这个命令会安装golangci-lint、staticcheck等代码质量工具。 # 3. 构建CLI make build # 编译成功后，当前目录下会生成名为 `sanity` 的可执行文件。

现在，你可以运行./sanity version来验证安装是否成功。

3.2 配置文件解析：sanity.toml

虽然SanityHarness有合理的默认值，但通过配置文件./sanity.toml可以精细控制其行为。理解每个配置项的作用，能帮你更好地定制评估流程。

# 示例配置文件 (sanity.toml) [harness] # 每个任务的最大尝试次数。Agent如果第一次失败，可以基于错误信息重试。 max_attempts = 10 # 单个任务运行的超时时间（秒）。超时则任务失败。 default_timeout = 60 # 存放每次 `sanity run` 详细结果的目录。 session_dir = "sessions" [docker] # 各语言对应的Docker镜像。你可以指向自定义镜像以预装特定工具。 go_image = "ghcr.io/lemon07r/sanity-go:latest" rust_image = "ghcr.io/lemon07r/sanity-rust:latest" typescript_image = "ghcr.io/lemon07r/sanity-node:latest" # 是否在启动时自动拉取最新镜像。关闭可以加速启动，但可能使用旧镜像。 auto_pull = true [agents] # 这里可以定义或覆盖内置Agent的配置。 [agents.my-gemini] # 自定义Agent的命令行。`{prompt}` 是占位符，会被实际的任务描述替换。 command = "my-gemini-cli" args = ["--temperature", "0.2", "{prompt}"] # 指定模型参数的标志。 model_flag = "--model" # 环境变量，常用于传递API密钥。 env = { API_KEY = "${GEMINI_API_KEY}" } # 支持从Shell环境变量读取 [sandbox] # Bubblewrap沙箱配置。 # Agent可以读写哪些宿主机目录。 shared_readwrite_dirs = ["/tmp/sanity-shared"] # Agent可以只读访问哪些宿主机目录。 shared_readonly_dirs = ["/usr/share/common-data"] # 在沙箱内额外创建的可写目录（位于沙箱内部）。 writable_dirs = ["/scratch"] # 明确屏蔽哪些敏感路径，即使它们在默认允许范围内。 readable_denylist = ["/etc/passwd", "/home/user/.ssh"]

配置加载顺序：SanityHarness会按顺序查找以下位置的配置文件，后加载的会覆盖先加载的同名配置项：

1. ./sanity.toml（项目根目录）
2. ~/.sanity.toml（用户家目录）
3. ~/.config/sanity/config.toml（用户配置目录）

这个设计非常灵活。你可以在项目目录放一个针对特定评估活动的配置，而在家目录放一个包含通用API密钥的全局配置。

3.3 初体验：手动运行一个任务

在让AI Agent上场前，我们先手动“扮演”一次Agent，理解任务是如何被执行的。这有助于后续调试Agent行为。

# 1. 列出所有可用的任务，看看有什么 ./sanity list # 使用过滤器 ./sanity list --language go --tier core # 2. 初始化一个任务的工作空间 ./sanity init go/bank-account -o ./my-bank-task cd ./my-bank-task

初始化后，你会看到类似如下的目录结构：

my-bank-task/ ├── README.md # 任务描述、要求、示例（公开测试） ├── go.mod # Go模块文件 └── account.go # 一个空的或只有签名的实现文件（需要你填充）

任务描述（README.md）是关键：它详细说明了需要实现什么功能，包含函数签名、示例输入输出，以及一些约束条件（如必须使用通道、禁止使用全局变量等）。AI Agent（或你）将主要依据这个描述来编写代码。

# 3. 手动实现功能。打开 account.go，根据README.md的提示完成代码。 # （这里假设你完成了编码） # 4. 运行测试，验证你的实现 ./sanity run go/bank-account -w ./ # `-w ./` 指定当前目录为工作空间。如果不指定，默认是当前目录。

sanity run会启动Docker容器，将你的代码挂载进去，运行测试，并输出结果。如果测试失败，日志会详细指出哪个用例没通过。你可以反复修改代码并运行，直到所有测试通过。

注意事项：理解“公开测试”与“评估”的区别：sanity run运行的是公开测试，即README.md中描述的测试。而真正的sanity eval在运行公开测试后，还会运行隐藏测试。所以，你的代码通过了sanity run，只意味着它满足了基本要求，不代表能在最终评估中拿满分。隐藏测试往往会覆盖更多的边界情况和极端场景。

4. 核心实战：配置与运行自动化评估

现在，让我们进入正题：如何用SanityHarness自动化地评估一个AI编程助手。

4.1 配置你要评估的Agent

SanityHarness内置了19种常见Agent（如Gemini, Claude, OpenCode等）。你只需要提供相应的API密钥或命令行工具路径。假设我们要评估Google的Gemini。

首先，确保你的Gemini CLI可用。这里假设你有一个叫gemini-cli的命令行工具，它接受提示词并返回代码。如果没有，你可能需要根据Agent的文档进行安装和配置。

然后，在sanity.toml中配置或确认Agent。内置Agent通常已有默认配置，但你可能需要设置环境变量。

# 在 sanity.toml 中，你可以覆盖内置Agent的默认行为 [agents.gemini] # 如果内置的gemini命令不对，可以在这里指定 # command = "/usr/local/bin/my-gemini-wrapper" env = { GOOGLE_API_KEY = "${GEMINI_API_KEY}" } # 你可以固定使用某个模型 model = "gemini-2.0-flash"

更常见的做法是通过命令行参数指定模型，这样更灵活。

4.2 执行一次完整的评估

评估命令sanity eval是核心。让我们分解一个复杂的例子：

./sanity eval \ --agent gemini \ # 指定要评估的Agent --model gemini-2.0-flash-exp \ # 指定模型（如果Agent支持） --tier core \ # 只评估核心层级的任务 --parallel 4 \ # 同时运行4个任务（加速评估） --timeout 120 \ # 每个任务超时时间设为120秒 --keep-workspaces # 保留临时工作空间（用于调试）

这个命令会做以下几件事：

1. 解析任务：根据--tier core筛选出所有核心任务。
2. 为每个任务创建隔离环境：在/tmp下为每个任务创建独立目录，复制任务文件。
3. 串行/并行执行：默认串行执行。使用--parallel N时，会启动一个工作池，同时处理N个任务，极大缩短总评估时间。但请注意，并行运行会消耗更多内存和CPU，因为同时有多个Docker容器在运行。
4. 调用Agent：对于每个任务，在对应的隔离工作空间中，调用geminiAgent，并将任务描述（README.md）作为提示词（prompt）传递给它。
5. 接收并写入代码：Agent生成的代码会被写入到工作空间的目标文件（如account.go）中。
6. 运行验证：系统执行测试（先公开，后隐藏），并记录结果。
7. 收集与清理：将结果（日志、最终代码）复制到eval-results/<timestamp>-gemini/目录下。除非指定了--keep-workspaces，否则临时工作空间会被删除。

4.3 解读评估报告

评估完成后，进入结果目录查看：

ls -la eval-results/2025-04-10T143022-gemini/

你会看到以下关键文件：

• summary.json:最重要的文件。包含每个任务的详细结果：通过/失败的测试列表、得分、权重、加权后得分、执行时间、尝试次数等。JSON格式便于程序分析。
• report.md: 人类可读的总结报告。包含总分、各语言得分柱状图、任务完成情况表格。可以直接分享给团队。
• submission.json: 符合SanityHarness排行榜（leaderboard）格式的数据。如果你想将结果提交到公共排行榜进行比较，就需要这个文件。
• attestation.json: 包含所有输出文件的BLAKE3哈希值。用于验证结果在传输或存储后是否被篡改。你可以用./sanity verify <eval-dir>命令进行验证。
• run-config.json: 本次评估的完整配置。用于--resume功能。

如何阅读summary.json：

{ "agent": "gemini", "model": "gemini-2.0-flash-exp", "total_weighted_score": 85.5, "tasks": [ { "id": "go/bank-account", "passed": true, "score": 1.0, "weight": 1.5, "weighted_score": 1.5, "attempts": 2, "duration_seconds": 45.2, "public_tests": { "total": 5, "passed": 5 }, "hidden_tests": { "total": 3, "passed": 3 }, "error": null }, { "id": "rust/parser-combinator", "passed": false, "score": 0.4, "weight": 2.0, "weighted_score": 0.8, "attempts": 10, "duration_seconds": 112.7, "public_tests": { "total": 8, "passed": 8 }, "hidden_tests": { "total": 5, "passed": 2 }, "error": "timeout after 112 seconds" } ] }

从这个例子可以看出，go/bank-account任务得了满分（1.0），权重1.5，加权得分1.5。而rust/parser-combinator任务虽然公开测试全过，但隐藏测试只过了2/5，得分0.4，权重2.0，加权得分0.8。这清晰地展示了隐藏测试如何暴露了Agent解决方案的局限性。

4.4 高级用法与技巧

恢复中断的评估：评估一整套任务可能耗时很长。如果中途被中断（Ctrl+C），SanityHarness会保存进度并打印出恢复命令。

# 假设中断后提示： # Interrupted. To resume, run: ./sanity eval --resume ./eval-results/2025-04-10T143022-gemini ./sanity eval --resume ./eval-results/2025-04-10T143022-gemini

恢复功能会读取run-config.json，跳过已完成的任务，继续执行未完成的任务。

干跑模式（Dry Run）：在不实际运行任务的情况下，预览评估计划。

./sanity eval --agent gemini --tier all --dry-run

这会列出所有将要执行的任务，检查配置和依赖，但不调用Agent或Docker。用于验证配置是否正确。

使用自定义任务目录：如果你想测试自己设计的任务，或者使用社区的非官方任务。

./sanity eval --agent gemini --tasks-dir ./my-custom-tasks

只需将任务按照<language>/<task-slug>/的目录结构放置即可。

调整Agent的“推理努力”：一些高级Agent（如droid）支持不同的推理模式。

./sanity eval --agent droid --reasoning high

这可能会让Agent进行更深入的思考，生成更可靠的代码，但也会显著增加响应时间。

实操心得：并行与超时的权衡：--parallel能大幅提升评估速度，但副作用也很明显。首先，大量并发容器可能压垮系统内存。其次，网络I/O（如果Agent调用云端API）可能成为瓶颈，导致排队。我的经验法则是：对于调用云端API的Agent，并行数不要超过你的网络连接池大小（通常2-4个）；对于本地运行的Agent，可以设置为CPU核心数。同时，合理设置--timeout。对于复杂任务，默认60秒可能不够，需要延长。观察第一次评估的duration_seconds，将其最大值乘以一个安全系数（如1.5），作为后续评估的超时时间。

5. 问题排查与性能优化实录

在实际使用中，你可能会遇到各种问题。以下是我在长期使用中积累的一些常见问题及其解决方法。

5.1 常见错误与排查

问题1：Docker守护进程未运行或权限不足

• 症状：Error: Cannot connect to the Docker daemon at unix:///var/run/docker.sock.
• 解决：
  1. 确保Docker服务已启动：sudo systemctl start docker(Linux)。
  2. 将当前用户加入docker组：sudo usermod -aG docker $USER，然后退出并重新登录。

问题2：Agent调用失败（API密钥错误、网络超时）

• 症状：任务结果中error字段显示Agent执行失败，查看具体的agent.log文件会发现HTTP错误码或连接超时。
• 解决：
  1. 检查sanity.toml或环境变量中的API密钥配置是否正确。
  2. 尝试手动运行Agent命令，看是否能正常响应。例如：gemini-cli "Write a hello world in Go."
  3. 如果是网络问题，考虑为eval命令设置HTTP代理环境变量，或在配置中为Agent命令增加超时参数。

问题3：任务超时（Timeout）

• 症状：任务状态为failed，错误信息是timeout after X seconds。
• 解决：
  1. 首先检查agent.log，看Agent是否在最后时刻还在输出。可能是Agent生成代码太慢，或者生成的代码陷入了死循环。
  2. 增加--timeout参数值。对于复杂的Rust或Zig编译任务，可能需要180秒甚至更多。
  3. 检查是否是特定任务超时。如果是，可能是该任务对当前Agent来说过于复杂。你可以考虑暂时将其从评估集中排除（通过--tasks参数指定任务列表）。

问题4：完整性校验失败（Integrity Violation）

• 症状：结果目录下出现了integrity.json、integrity-files/和integrity-diff/文件夹。
• 原因：Agent在测试运行期间，修改了不应该修改的文件（例如，测试文件*_test.go或任务描述README.md）。这是被严格禁止的，因为这会改变评估的前提条件。
• 排查：查看integrity-diff/中的差异文件，了解Agent具体修改了什么。这有助于你判断是Agent行为不端，还是你的沙箱配置（writable_dirs）过于宽松，让Agent误写了文件。

问题5：Bubblewrap沙箱导致Agent无法访问所需资源

• 症状：Agent报告“文件未找到”或“权限被拒绝”，即使文件看似存在。
• 解决：
  1. 使用--no-sandbox暂时禁用沙箱，看问题是否消失。如果消失，则是沙箱配置问题。
  2. 检查sanity.toml中的[sandbox]部分，确保Agent需要访问的目录（例如，某些Agent需要读取~/.config下的配置文件）已添加到shared_readonly_dirs或shared_readwrite_dirs中。
  3. 查看Agent的文档，了解其运行依赖哪些文件和目录。

5.2 性能优化技巧

评估耗时是个现实问题。以下方法可以帮你提升效率：

1. 利用持久化缓存（.sanity-cache/）SanityHarness会在项目根目录创建.sanity-cache/目录，并将语言特定的编译缓存（如Go的GOCACHE、Rust的CARGO_TARGET_DIR）挂载到容器中。确保这个目录在多次评估间得以保留，可以避免重复下载依赖和重复编译标准库，对Rust这种编译较慢的语言效果尤其显著。

2. 预拉取Docker镜像在开始大规模评估前，手动拉取所有需要的镜像：

docker pull ghcr.io/lemon07r/sanity-go:latest docker pull ghcr.io/lemon07r/sanity-rust:latest # ... 拉取其他语言镜像

或者，在sanity.toml中设置auto_pull = false，并确保本地已有镜像，可以避免每次启动容器时的网络延迟。

3. 选择性评估不要每次都跑全部任务。利用过滤器进行针对性评估：

# 只评估Go语言的核心任务 ./sanity eval --agent gemini --language go --tier core # 只评估难度为“专家”级的任务 ./sanity eval --agent gemini --difficulty expert # 评估指定的几个任务 ./sanity eval --agent gemini --tasks go/bank-account,rust/parser-combinator

4. 并行执行的资源管理如前所述，合理设置--parallel。监控系统资源使用情况（htop,docker stats）。如果评估的是本地大模型，并行数受GPU内存限制；如果是云端API，则受限于API的速率限制（Rate Limit）。

5. 使用更快的存储如果可能，将SanityHarness的工作目录（包含sessions和eval-results）放在SSD硬盘上。Docker的卷操作和大量的文件读写会因此受益。

5.3 调试Agent的生成过程

当Agent表现不佳时，你需要深入查看它到底做了什么。

保留工作空间：使用--keep-workspaces参数。评估结束后，在eval-results/<run-id>/下的每个任务目录里，会保留一个指向临时工作空间的符号链接或副本。你可以直接检查Agent生成的原始代码，与最终提交的代码进行对比。

分析日志：每个任务目录下的agent.log记录了Agent的所有输出（包括思考过程，如果Agent支持）。validation.log记录了测试运行器的完整输出。仔细阅读这些日志，尤其是错误信息，是诊断问题的第一步。

手动复现：将Agent生成的最终代码（位于工作空间的workspace/子目录或保留的工作空间中）复制出来，手动运行sanity run，观察是否出现同样的错误。这能帮你确定问题是出在Agent的代码生成上，还是SanityHarness的测试环境上。

踩坑记录：隐式的环境依赖：有一次评估一个自定义Agent，它在本地需要读取~/.netrc文件来获取认证。我忘了在sandbox.shared_readonly_dirs中添加这个文件路径，导致Agent在沙箱内运行时认证失败，所有任务都挂了。症状就是agent.log里满是网络401错误。解决方法很简单，把~/.netrc加入只读目录列表。这个教训是：务必清楚你的Agent需要哪些环境资源，并在沙箱配置中显式声明。