使用和切换 Agent

内置 Agent 全景图

Nexus v1.1.3 内置了 16 种 Agent，大致分为四类。

Agent 生态分层

在理解 Nexus 的 Agent 分类前，先了解 2026 年 Agent 工具的生态分层：

层级	代表	与 Nexus 的关系
SDK 层	OpenAI Agents SDK / Claude Agent SDK / Google ADK	用 SDK 组装定制 Agent，Nexus 可通过 Installed Agent 适配
框架层	LangGraph / CrewAI / AutoGen / PydanticAI	编排逻辑，Nexus 不在这一层竞争
评测/训练层	Nexus / OpenHands / verl	Nexus 的核心层——评测 + 训练一体化

Nexus 的 Installed Agent 模式的独特价值在于：在评测框架的沙箱内原样运行生产 Agent，只代理 LLM 请求。这使得 Nexus 可以用统一的轨迹采集和评分体系来比较任何 Agent——无论是自研的还是第三方的。

第一类：通用 Tool-Calling Agent

这类 Agent 自己实现推理循环，通过 LLM + 工具调用迭代完成任务。

Agent	注册名	定位	适合场景
Main Agent	main_agent	通用 tool-calling 循环	大多数任务的默认选择
Demo Agent	demo_agent	教学示例	学习框架用
ToolCall Agent	toolcall_agent	基于 base 框架的 tool-calling	自定义工具组合

main_agent 是最常用的。它的核心参数：

agent_name: "main_agent"
agent_config:
  system_prompt: "You are a helpful assistant."
  max_iterations: 30
  tools:
    - "str_replace_editor"        # 文件编辑
    - "python_code_interpreter"   # Python 执行
    - "google_search"             # 网页搜索
  parallel_tool_calls: false      # 是否允许并行工具调用
  tool_output_truncation: 10000   # 工具输出截断长度
  observation_time_timeout: 300   # 单次工具执行超时（秒）
  inference_time_timeout: 120     # 单次 LLM 推理超时（秒）

tools 列表决定了 Agent 可以使用哪些工具。不在列表里的工具不会出现在 LLM 的 function schema 中。

第二类：代码修复 Agent

专为代码修复/生成任务设计，带有领域特定的工具和 prompt 工程。

Agent	注册名	定位	典型搭配 Task
SWE Agent	swe_agent	SWE-bench 风格的代码修复	swe_task
CodeAct Agent	codeact	基于 CodeAct 范式（代码作为 action）	swe_task、terminal_task

swe_agent 自带一套针对代码仓库操作优化的工具（str_replace_editor、search_stateful/*），prompt 经过精心调优。如果你要跑 SWE-bench，首选这个。

codeact 实现了 CodeAct 论文的范式——Agent 用 Python 代码作为 action，而不是预定义的工具调用。它自带的 codeact_tools.py 有 39KB，包含了文件操作、搜索、终端控制等全套实现。

第三类：Installed Agent（外部 Agent 适配器）

这类 Agent 在 Runtime 沙箱内安装和运行第三方 Agent 系统，通过 LLM Proxy 将 API 请求转发回 Host。

Agent	注册名	底层系统	安装方式	关键演进
Claude Code	claude_code	Anthropic Claude Code CLI	npm install	v2.1.202 引入 Dynamic Workflow Size；v2.1.206 /doctor 诊断、MCP timeout 修复；v2.1.170 Fable 5 访问；v2.1.197 Sonnet 5 默认模型；v2.1.198 Background Subagents（多 Agent 并行）；v2.1.207 Bedrock/Vertex/Foundry 默认解锁 Auto Mode；v2.1.212 /fork→后台会话 + /subtask 子代理 + MCP 自动后台化（>2min）；v2.1.223 多步任务 Agent + 内置 Grep + 多 Agent 协作 + 修复制表符/Unicode 权限绕过；v2.1.224 self-hosted-runner + zip 插件安装 + 跨会话权限 + subagent 取消数量上限；v2.1.225 gateway spend-limit 可视化 + claude agents 工作区信任提示；v2.1.239–270（2026-08-21~09-12，官方 changelog 记录 23 个版本条目）：promptCacheTtl/subagentPromptCacheTtl（243）、agent frontmatter experimental.cacheTtl（248）、foreground subagent 工具调用实时流式到 Remote Control（251）、CLAUDE_CODE_SUBAGENT_MODEL_FORCE（257）、nested background subagent 结果写入父 transcript（259）、subagent 触及 maxTurns 返回 partial（246）、/tasks 按 subagent 显示 model + effort（243）、CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS（1–256，269）；v2.1.271–287（2026-09-14~10-01，官方 changelog 收录 16 个版本块，其中 2.1.279 未发布）：遥测开关不再能从项目级设置下发（282）、LLM 网关提示头与 x-claude-code-prompt-id（273/283）、原始请求体落盘并与 transcript 消息双向对齐（274）、五条子代理结果静默丢失修复（273/275/280）、未知模型 ID 下 Explore 子代理偷偷换模型（284）、沙箱设置不可被项目级放宽（285）、workflow 默认尺寸下调（271）、后台命令硬超时（285）、子代理结果加来源标记（277）、Claude Mods 插件可改更深行为（287）—— 逐条见下方「多 Agent 拓扑对 Installed Agent 适配的影响」与「Docker Runtime 安全注意事项」两节

📌 本表 Claude Code 侧版本基线（2026-10-02 更新）：最新已核版本 v2.1.287（发布 2026-10-01，核于 2026-10-02，源 registry.npmjs.org dist-tags + time 字段）。上一版基线为 v2.1.270（2026-09-12）——两者相隔 19 天、16 个版本块（271–278、280–287；2.1.279 在 npm versions 与 changelog 中均不存在）。⚠️ 凡”某日止于某版本”的写法都有一个内置的过期时钟，改本表时请连同本行一并更新。 | Codex | codex | OpenAI Codex CLI | npm install | Cognition 收购后推出 2.0，SWE-1.5 推理模型 | | Gemini CLI | gemini_cli | Google Gemini CLI | npm install | Google Agent 生态入口，支持 A2A 协议 | | OpenClaw | openclaw | 腾讯 OpenClaw Agent | pip install | ⚠️ 2026.05-06 多个 CVE（提权 + 命令注入），见下方安全说明 |

⚠️ 以上 Agent 版本更新频繁，以实际安装版本为准。

这种模式的核心思想：不重新实现这些 Agent 的逻辑，而是在 Nexus 的沙箱里原样运行它们，只代理 LLM 请求。 这意味着你可以用 Nexus 的批量执行、轨迹采集、评分体系来跑这些 Agent，而不需要修改它们的代码。

agent_name: "claude_code"
agent_config:
  user_prompt: "Fix the bug described above"
  working_dir: "/workspace/repo"
  timeout: 3600

Installed Agent 的工作流程（第 18 章会详细拆解）：

1. 在 Runtime 内安装 Agent CLI
2. 启动 LLM Proxy Server（监听本地端口）
3. 设置环境变量让 Agent CLI 的 API 请求指向 Proxy
4. 运行 Agent CLI
5. Proxy 将请求转发给 Host 侧的 OpenAI Client，实现 token 计数和轨迹采集

⚠️ MCP 超时注意：Claude Code v2.1.206 修复了 request_timeout_ms 被静默忽略的 bug——此前所有 MCP 工具调用被强制 60 秒超时。但 v2.1.212 新增 MCP 自动后台化特性（>2 分钟的 MCP 调用自动转入后台），可通过 CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS 调整或禁用。如果你的 Installed Agent 使用长时间运行的 MCP 工具，需注意后台化可能导致 Nexus 的 agent_config.timeout 被绕过。

⚠️ 多 Agent 拓扑对 Installed Agent 适配的影响： Claude Code v2.1.223 引入多步任务 Agent、内置 Grep 与多 Agent 协作，v2.1.224 进一步取消 subagent 数量上限。这意味着单个 Installed Claude Code 实例内部的 Agent 拓扑从”单主 Agent + 有限子代理”演变为”任意深度的多 Agent 协作图”。对 Nexus 的 Installed Agent 适配有三点影响：(1) 资源配额假设失效——原先按”单个 Agent 进程”估算的 CPU/内存/时间预算，需改为按”Agent 拓扑规模”动态估算；(2) token 计数粒度变粗——子代理的 LLM 请求也经过 LLM Proxy，但归属关系更复杂，token_counter 需要能区分”主 Agent vs 子代理”的 token 归属；(3) 轨迹采集需要捕获子代理的完整上下文，否则训练数据的因果链断裂。

⭐ 上面三点在 v2.1.239–270 区间已被官方逐条兑现，本段的写法应从”我们需要 X”改为”官方已提供 X，应这样对接”：

(1) 资源配额已有可配置量纲：v2.1.269（2026-09-11）新增 CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS，取值 1–256，用于提升 Workflow 工具每轮的并发 agent 上限（官方用例写作 inference-bound fan-outs）。这给出两个此前只有定性判断的事实：拓扑规模有上限，不是无界增长；官方默认值不足以支撑推理受限的扇出场景。Nexus 侧的资源预算可直接对齐到「并发 agent 数」这一维度估算（例如 N_agents × (单 agent 峰值内存 + 单 agent 超时)），而不是笼统地按”拓扑规模”打折。建模公式为编辑建议，非官方表述。

⚠️ 1–256 是取值域，不是默认值（2026-10-02 补）：v2.1.271 起，dynamic workflow 的默认尺寸在 Pro 计划上为 small，且 medium 的尺寸指南从 15 降到 10 agents。按 256 或 15 做预算会严重高估。 公式中”单 agent 超时”一项此前没有官方默认值；v2.1.285 起后台 Bash/PowerShell 命令有了硬超时——run_in_background 的 timeout，默认 30 分钟、上限 2 小时，超时会停止并通知 Claude。可作为该项的官方锚点。 另有一条可用性改进：v2.1.271 起 dynamic workflows 在触及用量上限时暂停并在重置后自动继续，而不是丢弃受影响的 agent——批量评测不必再为”跑一半撞上限”单独设计重试。

(2) token 归属维度官方已做出，可对齐而不必自研：v2.1.243 起 /tasks 与 agent 详情框按 subagent 显示其运行的 model 与 effort level；v2.1.257 起 background subagent 与 teammate 的 token counter 在流式响应时实时更新（此前切换 subagent transcript 后计数器会卡住或变慢）；v2.1.267 起 subagent 与 --system-prompt 启动的会话，其 system prompt 与工具定义只记录一次（不再每轮重新渲染）。建议 Nexus 的 token_counter 直接采用「(agent_id, model, effort)」三元组作为归属键，与官方字段同名。

⭐ v2.1.273 起，这些归属维度从”UI 显示”下沉到了”请求头”（2026-10-02 补）：开启 CLAUDE_CODE_GATEWAY_HINT_HEADERS=1 后，每一个发给 LLM 网关的请求都带 x-claude-code-request-class、x-claude-code-agent-type、x-claude-code-compaction、x-claude-code-context-compacted；v2.1.283 再加 x-claude-code-prompt-id，用于把”服务同一个用户 prompt 的多次请求”归为一组。由于 Nexus 的 Installed Agent 本就经过自己的 LLM Proxy，这些头可以直接在代理侧采集，无需改动 Claude Code。

对归属键的直接影响：prompt-id 提供了三元组表达不了的粒度——「一道题的一次尝试」。批量评测中计费与归因的自然单位往往是这个，而不是”一次 API 调用”。建议归属键改为 (prompt_id, agent_id, model, effort)，其中 prompt_id 取自 x-claude-code-prompt-id，其余三项沿用官方字段。

另：v2.1.273 起 OTEL_LOG_TOOL_DETAILS=1 的 cost/token 指标会带上真实的 agent / skill / plugin / MCP server 名称（此前只有泛化名），工具级归因首次可行。

⭐ 另有一条对评测框架特别有用的开关：v2.1.257 新增 CLAUDE_CODE_SUBAGENT_MODEL_FORCE——强制所有 subagent 使用同一模型（忽略 per-spawn 与 agent-definition 的模型覆盖）。批量评测时开启它，可消除”子代理悄悄换成别家模型”这一混淆变量，让分数差异只来自被测对象。对以可复现为生命的评测框架，这一项应写进 Installed Agent 的默认配置模板。

⚠️ 该开关不是这一类问题的完整解——还有一个前置条件是”模型 ID 被 Claude Code 识别”（2026-10-02 补）。v2.1.284 修的正是一个反例，官方原文：

Fixed the Explore subagent switching to Opus on the Claude API when the session runs a model ID Claude Code doesn’t recognize, such as a custom model behind a proxy; Explore now inherits that model

v2.1.274 另修了 Bedrock / Vertex / Foundry 上 model: "opus" 子代理在模型 ID 无可识别 family 时离开会话模型的问题。

这两条都点名了 Nexus 的运行形态（自定义模型 + 代理）。落到默认配置模板上，除了 CLAUDE_CODE_SUBAGENT_MODEL_FORCE，还应校验会话模型 ID 落在 Claude Code 可识别的 family 内；若使用自定义 ID，须确认 Claude Code 版本 ≥ 2.1.284，否则 Explore 子代理仍会换模型，且换模型这件事不会体现在分数报告里。

(3) 轨迹采集已有官方落盘机制：v2.1.259（2026-09-02）起，nested background subagent 的结果会保存到父 subagent 的 transcript，恢复的 subagent 能保留这些结果、共享 transcript 也能看到投递记录（v2.1.260 另修了 in-process teammate 的 transcript 在长时间 API 重试期间丢消息/变空白的问题）。Nexus 的轨迹采集应优先对接这一层，而不是自行重放。

⭐ v2.1.274 起，原始请求体可落盘并与轨迹消息双向对齐（2026-10-02 补）：OTEL_LOG_RAW_API_BODIES=file:<dir> 会生成 index.jsonl，并用 request_body_id 与 message.id 两个事件属性把每个响应关联到它的请求文件与 transcript 消息。这补上了此前”有 transcript 无请求体 / 有 OTel 指标无原始 body”的缺口。v2.1.283 起 OTEL_LOG_TOOL_CONTENT=1 还会把 MCP 工具、WebFetch、WebSearch 的输出写进 tool.output span 事件。

🔴 v2.1.282 起，项目级与 local 设置里的遥测开关被忽略（2026-10-02 新增，本轮最容易被漏掉的一条）。官方原文：

Changed project and local settings to ignore OpenTelemetry variables that turn on export, set its endpoint, or capture content, like CLAUDE_CODE_ENABLE_TELEMETRY and OTEL_LOG_*

对 Nexus 的直接后果：把遥测开关写进评测仓库的 .claude/settings.json 或项目配置，在新版本上会静默失效且不报错。遥测开关必须由管理态设置（managed settings）或进程环境变量下发。

配套的反向能力是 v2.1.274 新增的 claude_code.managed_settings_resolved OTel 事件——它记录管理态设置的来源与策略助手状态（OTEL_LOG_MANAGED_SETTINGS=1 时输出脱敏后的设置与摘要），可用于核对”实际生效的是哪一份策略”。

这条属于操作化退化型风险：配置项写对了位置，但位置本身在新版本被剥夺了效力，且失败是静默的。若仍按旧方案在项目配置里开遥测，现象会是”什么都没发生”，而不是报错。

⚠️ 一条关键限定：v2.1.251 的实时流式只覆盖 foreground subagent——官方原文写明 background subagent（默认）「still show status only」。第 5 章的训练数据生产通常跑 batch/background，实时流式对该场景不适用，只能依赖 transcript 落盘。引用此条时须带上该限定，否则会误导。

⭐ 一个值得接入 Filter 的数据质量信号：v2.1.246 起，subagent 触及 maxTurns 上限时返回结果被标记为 partial（并提示可用 SendMessage 续跑），而非静默结束。被截断的轨迹应在 Filter 阶段识别并剔除或标记，否则会作为”失败轨迹”污染 RL 数据——这与第 5 章的 Filter 模块直接相关。

⚠️ 比”被截断”更危险的是”被丢掉且不报错”（2026-10-02 新增）。v2.1.271–280 区间官方修了至少五条静默丢失路径，全部落在 headless / SDK / --output-format stream-json 这三种集成方式上——正是 Installed Agent 的接入方式：

1. v2.1.273：子代理在回合中途被转入后台后，其剩余消息与最终报告被 stream-json / SDK 输出丢弃
2. v2.1.273：最终流式回复缺 token usage 或没有 model id 时，子代理与后台 agent 被报为 failed，且结果永不投递
3. v2.1.275：--forward-subagent-text 下，context: fork 技能派生的子代理消息被丢弃
4. v2.1.280：headless 与 SDK 会话中，发给正在收尾的后台子代理的消息被静默丢弃
5. v2.1.280：启动子代理的会话在报告被读取前发生 compaction，则该报告丢失

对评测框架的后果：第 2 条会让成功的子代理被记成失败——分数被系统性低估，而输出里看到的只是一条正常的 “failed”，没有任何异常信号。这与 v2.1.246 的 partial 标记性质相反：partial 是看得见的失败，上面五条是看不见的失败。Filter 阶段无法用”剔除”来处理，只能靠版本基线 + 结果对账（例如统计 failed 比例在跨版本间的跳变）。

第 5 条与本章已写的 v2.1.259/260/267 正面相接：批量评测是最容易触发 compaction 的场景，故”在 compaction 前读取子代理报告”应作为 Runner 的一条时序约束。

第四类：专用 Agent

针对特定任务类型优化的 Agent。

Agent	注册名	定位
BrowserGym Agent	browser_gym_agent	浏览器操作（WebArena/BrowseComp）
Search Agent	search_agent	信息搜索和检索
MM Search Agent	mm_search_agent	多模态搜索（图片+文本）
Science Agent	science_agent	科学研究任务
Terminus2	terminus2	终端操作（XML 解析范式）
Rondo Agent	rondo_agent	Rondo 范式
Single Turn	single_turn	单轮 LLM 调用（无工具）

browser_gym_agent 是处理网页任务的主力。它实现了复杂的 DOM 压缩、增量观察、站点感知过滤等优化，详细配置：

agent_name: "browser_gym_agent"
agent_config:
  max_iterations: 30
  observation_type: "axtree"           # axtree / html / screenshot
  viewport_width: 1280
  viewport_height: 720
  action_type: "bid"                   # bid / coordinate / code
  use_delta_observation: true          # 增量 DOM 更新（节省 token）
  use_task_aware_filter: true          # 任务感知的 DOM 过滤

Docker Runtime 安全注意事项

Nexus 的 Docker Runtime 是默认沙箱运行环境，但 2026 年 5-6 月披露了多个与 Docker 沙箱和 Agent 运行时相关的严重 CVE：

CVE	影响	严重性
CVE-2026-2287（CrewAI RCE）	远程代码执行漏洞，影响所有使用 CrewAI 框架的 Agent	🔴 严重
CVE-2026-27002（OpenClaw 提权）	OpenClaw 沙箱内特权提升，逃逸到宿主机	🔴 严重
CVE-2026-34040（Docker AuthZ 绕过）	CVSS 8.8（HIGH，NVD）。用特制的 API 请求可让 daemon 把请求转发给 AuthZ 插件时不带 body，插件看到空 body 于是放行，而 daemon 照常处理完整请求。对 OPA、Prisma Cloud、Casbin 及所有自研 AuthZ 插件一视同仁；是 CVE-2024-41110 的不完整修复（同根因第三次迭代）。修复于 Docker Engine 29.3.1（2026-03-25，改为 fail-closed）。⚠️ 官方公告原话：不使用 AuthZ 插件的部署不受影响；官方并自评「被利用的基础可能性为低」	🟠 高
CVE-2026-24763（OpenClaw 命令注入）	通过环境变量注入执行任意命令	🔴 严重

对 Nexus 用户的直接影响：如果在 Docker Runtime 中运行第三方 Installed Agent（特别是 OpenClaw），将面临提权和命令注入风险。

⭐ CVE-2026-34040 对 Installed Agent 场景的特殊性： 安全研究方 Cyera Research 明确警示过一个场景：AI coding agent 可能自主发现并利用该漏洞。典型路径是——一个被派去调试 K8s 问题的 agent 想挂载宿主目录，被 AuthZ 拒绝；它拿着 Docker API 访问权限，也理解 HTTP，于是自己构造一个 padding 超过 1 MB 的请求绕过限制。Cyera 的表述是：这个 CVE 不需要任何利用代码、特权或特殊工具，只是一个带额外 padding 的 HTTP 请求，任何能读懂 Docker API 文档的智能体都能构造出来。另一条路径是提示词注入：agent 克隆含恶意指令的仓库后被诱导构造该请求，从而逃出沙箱。

这让上面那句偏抽象的风险论断有了具体的、已披露的实现路径：不是”Docker 有个洞，agent 可能会踩到”，而是”agent 会在完成合法任务受阻的过程中自己找到这个洞”。对 Nexus 的推论是——给 Installed Agent 的 Docker API 权限，等价于给它绕过 AuthZ 的能力；权限边界必须在 Agent 拿不到 Docker socket 的层面划定。

⚠️ 需与官方口径一并阅读：Moby 官方公告只确认了”特制请求可绕过 AuthZ 插件”（未给出 1 MB 阈值，也未提及 AI agent 场景），并把利用的基础可能性评为低。1 MB 阈值、AI agent 自主利用路径、以及下面的 rootless 缓解建议均来自 Cyera Research，属研究方结论，引用时应区分。

⚠️ 权限绕过案例延伸： Claude Code v2.1.223 修复了制表符/Unicode 权限绕过漏洞——此前攻击者可通过在文件路径/命令中嵌入制表符或特殊 Unicode 字符，绕过 Claude Code 的文件操作权限检查。这与上表 CVE 属同一主题：Agent 在受控环境中的越权风险。对 Nexus 的启示是：Installed Agent 的权限边界不能只依赖 Agent 自身的权限检查（它可能被字符编码绕过），而应在沙箱层（Docker/Nix）做独立的能力裁剪作为第二道防线——这正是下面第 3 条”能力裁剪”措施的意义所在。

第三个案例（v2.1.268，2026-09-10）：官方修了一个被 respawn 的进程内 teammate 从你未标记为信任的目录中同名 agent 文件里加载 tools 与 system prompt 的问题。前两个案例的问题是”Agent 自身的检查可被绕过”，这个案例更进一步——风险来自 Agent 从哪里加载配置。对 Nexus 的额外推论：Installed Agent 的 agent 文件发现路径必须显式白名单化（与第 6、7 章的模块发现机制同一套信任模型），否则”目录里多放一个同名文件”就能改变 Agent 的工具集与系统提示。

第四个案例（v2.1.277，2026-09-18）——这一类不是”检查被绕过”，而是”来源被伪造”（2026-10-02 新增）。官方改为让子代理结果以标记为 subagent output 的 header 送达主 agent 并将内容缩进，使子代理结果里的文本不能冒充会话自身的指令；同一版本还把 workflow 脚本计算出的 agent() prompt 以”脚本撰写文本”的框架送达，使安全分类器不把它读成用户指令。

对 Nexus 的数据侧意义：训练数据生产时，“指令”与”子代理产出”现在有了官方的结构性区分（header + 缩进），可用于 Filter 阶段识别注入样本——这比事后用启发式猜要可靠。

⚠️ 一条反向的供应链信号（v2.1.287，2026-10-01）：官方新增 Claude Mods——插件现在可以修改更深的行为。这把上面”agent 文件发现路径必须显式白名单化”的推论推进一步：信任边界从”加载哪些文件”扩大到”插件能改到多深”。对 Installed Agent 适配的推论是：插件来源与插件能力应纳入同一套白名单模型，而不只是文件路径。

相关的一条降噪能力：v2.1.271 起 agent frontmatter 支持 omitClaudeMd，可让自定义/插件子代理不加载 user/project/local CLAUDE.md（管理策略文件仍加载）——批量评测中可一并减少噪声与注入面。

建议的安全缓解措施：

1. microVM 隔离：对高风险 Agent，使用 Firecracker/gVisor 等 microVM 替代纯 Docker 隔离
2. 网络策略：限制 Docker 容器的网络访问，禁止容器间通信
3. 能力裁剪：使用 --cap-drop=ALL + 按需 --cap-add 最小化容器能力
4. 版本锁定：确保 OpenClaw 升级到修补 CVE-2026-27002 和 CVE-2026-24763 的版本
5. rootless 模式：针对 CVE-2026-34040，Cyera 给出的效果最直接——rootless 模式下即便特权容器的 root 也映射到宿主的非特权 UID，爆炸半径从”整台宿主失陷”降为”一个非特权用户失陷”
6. --userns-remap：无法全量 rootless 时的同类 UID 映射替代
7. 限制 Docker socket 暴露，并在反向代理层限制请求体大小（如 512 KB）：后者是本 CVE 的定向缓解，无需改动 daemon

⚠️ 上表中需要”改沙箱配置”的措施（1 / 3 / 5 / 6），在存在管理态策略的机器上只能往更严的方向改（2026-10-02 新增，是对前 7 条适用条件的说明，不是第 8 条措施）：v2.1.285 起，项目设置不能放宽或关闭 admin-required sandbox、不能替换 managed deny list 之后的 proxy、不能扩展 strict allowlist、不能重开 managed read-denies；v2.1.282 起，项目/local 的 sandbox.excludedCommands 在管理态设置 allowUnsandboxedCommands: false 或 allowManagedDomainsOnly: true 时被忽略。

对 Nexus 的推论：共享评测集群上，沙箱策略必须由管理态统一下发，不能依赖每份 YAML 的项目级配置——这与上面”agent 文件发现路径必须显式白名单化”是同一个方向（信任边界上移）。另有一条可用的新管理态能力：v2.1.285 的 allowedProviders，可直接限定机器可用的 API provider 列表。

配置书写面上还需注意两个已被修掉的匹配坑：v2.1.277 之前，excludedCommands 的一个 glob 只要匹配复合命令的一部分就会整体豁免；v2.1.281 之前，它匹配不到 git rev-parse --git-dir、与 shell 内建同名的程序，以及含 [WIP] 或 # 行的 commit message。

排查命令（针对 CVE-2026-34040）：docker version --format '{{.Server.Version}}'（低于 29.3.1 即受影响）、docker info --format '{{.Plugins.Authorization}}'（返回插件名才有风险，空则不受影响）、journalctl -u docker | grep "Request body is larger than"。

🔗 详见 Ch10-Runtime 的沙箱架构讨论和 Ch11-Nix 注入的安全防护机制。

Installed Agent 生态动态

2026 年 Q2，Installed Agent 领域有几个值得关注的动态：

Agent SDK 三强竞争：OpenAI Agents SDK、Claude Agent SDK、Google ADK 形成三强格局，各自定义 Agent 的安装、运行和通信规范。对 Nexus 的影响：

• 不同 SDK 的 Agent 安装方式可能不兼容，Nexus 的 Installed Agent 适配器可能需要为每个 SDK 维护独立的安装脚本
• A2A 协议（Google）vs MCP 协议（Anthropic）vs 函数调用协议（OpenAI）的竞争，可能影响 Agent 间通信的标准化

mini-swe-agent 取代 SWE-agent：Princeton 官方推荐 mini-swe-agent（约 100 行 Python），SWE-agent 进入维护模式。DeepSWE 和 ProgramBench 均使用 mini-swe-agent 作为统一评测脚手架。对 Nexus 的影响：

• swe_agent 的底层脚手架可能需要迁移到 mini-swe-agent 的接口规范
• 统一脚手架使得不同基准间的结果更具可比性

同一 Task 切换 Agent

切换 Agent 只需要改 YAML 的两个字段：

# 方案 A：用 main_agent + 自选工具
agent_name: "main_agent"
agent_config:
  tools: ["str_replace_editor", "python_code_interpreter"]
  max_iterations: 20

# 方案 B：用 swe_agent
agent_name: "swe_agent"
agent_config:
  max_iterations: 30

# 方案 C：用 claude_code
agent_name: "claude_code"
agent_config:
  timeout: 3600

Task 本身不关心用的是哪个 Agent——它通过 WithAgentRunner Mixin 拿到的 run_agent() 函数是由 Runner 注入的工厂函数，内部会根据 agent_name 找到并调用对应的 Agent。

这种解耦的好处：你可以在同一个 benchmark 上对比不同 Agent 的表现，只需要改配置文件。 批量执行时甚至可以在 Generator 里为不同实例分配不同 Agent。

Agent 配置的层级

Agent 配置有两个来源，后者覆盖前者：

1. YAML 的 agent_config：静态配置，对所有实例生效
2. Task 通过 run_agent() 传入的参数：动态配置，每个实例可以不同

例如 swe_task 会这样调用 Agent：

agent_output = await task_input.run_agent(
    user_prompt=instance.problem_statement,
    working_dir="/workspace/repo",
)

user_prompt 和 working_dir 来自 Task，max_iterations 和 tools 来自 YAML 的 agent_config。两者合并后传给 Agent。

工具可用清单

Agent 可以使用的工具取决于两个因素：

1. 已安装的 Tool 模块（通过 nexus modules 查看）
2. Agent 配置中的 tools 列表（仅 main_agent 需要显式指定）

内置的 34 个 Tool 按类型分：

类别	Tool 名	执行位置	说明
浏览器	browser/goto, browser/click, browser/fill 等 20 个	RUNTIME	Playwright 浏览器操作
代码执行	python_code_interpreter, safe_python_code_interpreter	RUNTIME	Python 代码执行
代码执行	jupyter_code_interpreter, jupyter_with_image	RUNTIME	Jupyter notebook
文件编辑	str_replace_editor	RUNTIME	精确文件编辑
搜索	google_search, google_serper_search, hunyuan_search	LOCAL	网页搜索
搜索	visit, image_visit	LOCAL	访问网页/图片
搜索	text_to_image_search, image_to_image_search	LOCAL	图片搜索
代码搜索	search_stateful/find, search_stateful/search, search_stateful/open	RUNTIME	带状态的代码搜索

注意 LOCAL 和 RUNTIME 的区别：LOCAL Tool 在 Host 进程执行（因为需要 API Key 等），RUNTIME Tool 在沙箱里执行（因为操作文件系统/浏览器）。