cua-sandbox-apps 的 Agent 编排设计Python 外循环 Creator/Auditor 双 Agent 模式【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cuaAGENT_DESIGN.md 是cua-sandbox-apps子项目的核心设计文档它规定了如何用Python 外层循环 双 AgentCreator 生产 / Auditor 审计 单一提交工具的模式批量为任意软件生成可在沙箱中验证的 install/launch 脚本。本文完整继承该设计文档中的模式代码、8 条设计规则与 7 类反模式并结合 creator_agent.py、orchestrator.py 等源码实现讲清这套模式如何落地为可运行的 agent 流水线读完可以掌握如何把批量环境生成任务拆成确定性的 Python 控制流与有限职责的 Agent 会话。1. 背景cua-sandbox-apps 在做什么cua-sandbox-apps 的 README 将其定位为CUA 沙箱的通用应用目录与安装器流水线目标是 Gym-Anything 风格的环境生成发现软件、创建安装/启动脚本然后在沙箱中用截图验证。其使用方式非常直接from cua_sandbox import Image, Sandbox # Build an image with an app pre-installed image Image.linux().app_install(godot-engine) async with Sandbox.ephemeral(image) as sb: await sb.apps.launch(godot-engine) screenshot await sb.screenshot()而生成这些安装器本身就是一个需要大规模并行的 Agent 任务目录中每个 app × OS 组合都要独立完成调研 → 写脚本 → 沙箱内执行 → 截图验证 → 提交这一整套流程。这个子项目的 apps 目录 里已经沉淀了 ansible、godot-engine、postgresql、nmap、wireshark 等几十个应用的产出物每个应用目录下都有按 OS 划分的install.sh/launch.sh/extract_metadata.sh/metadata.json例如 ansible 的 linux 产物。要稳定地批量产出这类结果靠的不是一个全能 Agent而是AGENT_DESIGN.md所规定的这套编排纪律。2. 核心模式Python 外循环驱动双 Agent2.1 模式代码设计文档给出的参考模式如下这是整篇文章的骨架for item in items: session_id None for attempt in range(3): # Creator agent: sandbox tools ONE submit tool creator_result await run_agent(item, session_id, creator_tools) session_id creator_result.session_id # Auditor agent: sandbox tools ONE submit_audit tool checklist audit await run_agent(creator_result.submission, auditor_tools) # Python: extract bools, calculate score, decide score sum(c[passed] for c in audit.checklist) / len(audit.checklist) if score threshold: break # else: creator retries with session continuation auditor feedback逐句拆解这个模式的设计意图for item in itemsPython 持有全部工作项这里是 app × OS 对Agent 永远只处理一个 item。这样每个 Agent 会话的职责边界、失败隔离、并发调度都由确定性代码掌控。session_id的传递重试时把上一轮 Creator 的session_id传回使 Creator 在同一会话上下文中继续工作而不是失忆后从零开始。源码中 Creator 会话确实会捕获session_id并用于导出会话转录见下文 creator_agent.py 中_save_transcript的逻辑。Auditor 独立于 Creator验证由另一个 Agent或验证机制基于提交物独立执行杜绝自己写、自己验收。Python 从布尔清单算分score sum(c[passed] ...) / len(...)。Agent 只回答这一条过没过分数计算、阈值判定、是否重试全部在 Python 里完成。2.2 模式在当前仓库中的落地形态需要说明实现现状设计文档描述的是通用模式而当前代码库中 Creator 侧已完整实现审计职责则以提交工具内嵌验证的形式体现——submit_result工具在接收提交时执行截图视觉核验、元数据检查、静态 lint 和全新沙箱重跑等硬性校验见 creator_agent.py 的 _make_submit_tool。也就是说Auditor 用清单逐项给 bool的思想被落实为工具侧确定性的逐项失败清单任何一项不过就返回CRITERIA NOT MET并列出全部未过项要求 Agent 修复后重新提交失败清单生成与返回。外层 Python 循环则由 run_orchestrator 实现检测宿主机能加速运行哪些 OS 沙箱detect_supported_os支持 linux/windows/macos/android 四种类型从 discovery 目录的 JSONL 加载条目跳过 webapp 与 library 类型这些不是可安装运行的终端软件用_already_created扫描 apps 目录跳过已有install.*或result.json的 app/OS 对天然支持断点续跑通过asyncio.Semaphore(concurrency)控制并发asyncio.gather汇总每个 pair 的成功/失败。这正是Python loops over items — never the agent规则的执行体Agent 从不感知自己处理的是第几个 item更不参与 item 之间的调度。3. 八条设计规则Rules设计文档的 8 条规则是整套模式的纪律约束逐条说明如下并给出源码印证。Python loops over items — never the agentPython 遍历工作项绝不交给 Agentorchestrator.py 中tasks [_run_one(entry, os_type) for entry, os_type in work]就是这条规则的直接体现工作队列在 Python 里构建每个任务由独立 Agent 会话消费。Two agents per item — creator does work, auditor verifies independently每个 item 两个 AgentCreator 干活Auditor 独立验证验证独立性的工程化手段是提交校验不信任 Agent 的自述。例如 submit_result 的截图检查 会用 Bedrock 上的 haiku 视觉模型对截图逐张核验应用窗口是否真实可见只有回复以PASS开头才算通过即使 Agent 声称应用已打开截图只有桌面也照样被打回。One submit tool per agent — no get_next, no submit_results, no update_and_submit每个 Agent 只有一个提交工具工具命名与语义收敛到单个submit_result工具定义。allowed_tools白名单中提交类工具仅此一个工具白名单Agent 不存在再交一次另一个版本的歧义路径。Auditor uses a checklist — returns[{item, passed: bool}], never a score审计用清单只返回布尔项绝不给分提交校验返回的失败清单正是布尔项列表failures: list[str]逐项累积截图缺失、metadata 缺binary_path、install 脚本缺 fail-fast 头、fresh-sandbox 重跑失败……最后一次性渲染成清单返回Check 1–4 的累积逻辑。Python calculates scores — from checklist bools, never ask agent for a number分数由 Python 从布尔项算出永远不让 Agent 报数字校验结论verification_passed是布尔值由工具端代码直接赋值result[verification_passed] True通过路径全程没有请给这次提交打分的提示。Session continuation on retry — passsession_idso creator keeps context重试时传递 session_id 保留上下文Creator 会话通过async for msg in query(...)流式捕获session_id并在结束后用claude-code-transcripts把会话 JSONL 转成 HTML 转录存档到logs/install-transcript/_save_transcript 与 调用处。会话可追溯、可续接是重试不丢上下文的基础设施。Pre-boot sandbox in Python — agents never waste turns on setupPython 预先准备环境Agent 不为搭环境烧回合当前实现中沙箱创建被封装成create_sandboxMCP 工具sandbox_tools.pyAgent 一次调用即获得可用 VM而更彻底的预启动体现在审计/验证路径strict 验证沙箱verify-{name}完全由 Python 侧代码创建、重跑、销毁fresh-sandbox 重跑Agent 全程不触碰。Action-script prompts — numbered steps with exact tool calls, not open-ended提示词写成动作脚本编号步骤 精确工具调用而非开放式描述CREATOR_SYSTEM_PROMPT 就是典型动作脚本WORKFLOW 一节列出 12 个编号步骤每步指明调用哪个工具、产出什么文件、JSON 字段的确切 schemabinary_path、display_name、icon_paths、version等。早期退出条件无公开下载 / library / webapp也写成了精确到字段取值的提交模板如install_exit_code: -1, app_type_detected: library。4. 七类反模式Anti-Patterns及成因设计文档的反模式清单与上述规则一一对应构成为什么不能这么做的对照表反模式后果原文设计上的对策Agent loops over items1-2 个 item 后就耗尽 turnsPython 外循环Agent 单 item 单会话Agent self-verifies自我确认偏差独立 Auditor / 工具侧独立核验视觉模型看截图而非 Agent 自述Multiple submit toolsAgent 选错工具、行为混乱每个 Agent 仅一个 submit 工具Auditor gives scores打分随意、不可复现只回布尔清单分数由 Python 计算Fresh agent on retry丢失上下文重复劳动重试传递session_id续接会话Agent boots sandbox浪费回合在环境准备上Python 侧预建/代管沙箱生命周期Open-ended promptsAgent 去探索而不是执行编号动作脚本提示词精确到工具调用其中Agent loops over items → runs out of turns是批量 Agent 任务最常见的死法一个会话的上下文窗口与 turn 上限是有限资源让它串行处理 N 个 item 意味着把调度压力堆到了最不适合做调度的组件上。5. 源码纵深Creator 侧如何把规则变成代码5.1 工具面Agent 没有 Bash只有沙箱sandbox_tools.py 的模块注释开门见山Creator agents get these tools instead of Bash. All execution happens inside ephemeral cua_sandbox VMs — nothing runs on the host. 六个工具构成完整的沙箱操作面create_sandbox(os)按 OS 枚举创建 VM支持 linux/windows/macos/android返回os-8位hex形式的名字sandbox_run(name, command)沙箱内执行 shell 命令返回 exit code / stdout截断 10000 字节/ stderr截断 5000 字节默认超时 120 秒sandbox_runsandbox_write / sandbox_read向 VM 写文件heredoc 方式可选 chmod x与读文件默认最多 200 行sandbox_screenshot(name)截取 VM 显示画面存为 JPEG 到证据目录quality85delete_sandbox(name)销毁 VM。隔离性由每 Agent 一个独立 registry保证make_sandbox_tools(evidence_dir, sandbox_registry)中每个 Creator 会话持有自己的my_sandboxes字典create_app_installer 中的初始化跨 Agent 互不干扰会话结束包括异常路径在finally里强制销毁该 Agent 名下所有残留沙箱强制清理。5.2 提交核验四层检查的布尔清单submit_result的核验链把清单审计执行得相当彻底顺序如下Check 1–4截图核验在证据目录找{sandbox_name}.jpg/.png交给 haiku 视觉模型回答应用是否可见CLI 类应用is_cli: true放宽为终端中有工具输出/版本信息也算 PASS核验提示词。元数据核验metadata必须包含binary_path与display_name且extract_metadata_script会再经视觉模型评审一次确认它是真正动态探测安装产物而不是把路径写死_verify_metadata_script。install 脚本静态 lint 全新沙箱重跑正则拒绝|| true、|| :、|| echo 等错误吞噬写法_ERROR_MASK_RE 与 _lint_error_masking检查头部 20 行是否具备set -euo pipefail_lint_fail_fast在strict_install_verify开启时默认开启还会在全新沙箱里把提交的 install 脚本原样重跑一遍最长等 30 分钟专治交互调试留下的状态让脚本看起来能跑的问题。早期退出通道download_available: false或install_exit_code -1直接记录结果落盘如 adobe-photoshop 的 result.json不进入沙箱流程。任何一项失败都会把全部失败原因拼成CRITERIA NOT MET清单一次性返回让 Agent 在一个回合内看到所有缺口而非逐条挤牙膏。5.3 动作脚本提示词的结构CREATOR_SYSTEM_PROMPT 除 12 步 WORKFLOW 外还内嵌了平台细节Linux VM 自带 XFCE 桌面与 display server禁止再装 xvfbmacOS 首次启动的 Apple Account 弹窗用key code 53Esckillall Setup Assistant处理以及FAIL FAST / NO ERROR MASKING / IDEMPOTENT三条脚本质量铁律——与第 5.2 节的 lint 检查一一对应提示词负责事前约束lint 负责事后兜底双保险。5.4 跨 Agent 经验沉淀文件式共享记忆shared_memory.py 实现了memory/目录下的按 OS 文件general.md linux/windows/macos/android.mdorchestrator 启动时init_memory写入种子经验如 Ubuntu 24.04 上 libasound2 → libasound2t64、winget 静默安装要带-hAgent 结束后可append_learning追加带时间戳的新经验后续 Agent 通过read_memory读取。这是Python 外循环红利之一——跨会话的知识传递必须由确定性代码中转Agent 会话本身是短命的。6. 使用方式与产物布局通过 cli.py 的 Click 入口可以驱动整条流水线discover onet静态加载 O*NET 职业分组→discover software并行 Agent 发现软件目录默认目标 5 万条、22 并发→discover enrich元数据补全→ 安装器创建对应 orchestrator 的run_orchestrator支持--os过滤、--limit、--concurrency等参数。CLI 启动时会自动加载包根目录的.env注入 Bedrock/API 配置cli.py 头部截图视觉核验依赖AWS_REGION默认us-east-1。产物目录约定对应当前仓库中的真实结构apps/app_id/ app.json # 应用级元数据跨 OS 共享 os/ install.sh | install.ps1 launch.sh | launch.ps1 extract_metadata.sh metadata.json # binary_path / display_name / icon_paths / version logs/ # 会话 JSONL、HTML 转录、install-result.json、截图证据例如 godot-engine 的 linux 产物 与 README 中的消费方式Image.linux().app_install(godot-engine)首尾呼应Agent 流水线产出的脚本最终变成cua-sandbox的一等构建能力。7. 小结这套模式的可迁移价值AGENT_DESIGN.md的核心主张可以浓缩为一句话让 Agent 做它擅长的单点任务让确定性代码做一切需要复现性和状态管理的事。具体到三条可迁移经验职责切分批量调度、重试计数、分数计算、资源清理全部放在 PythonAgent 会话保持单 item、单提交工具、有限上下文的最小形态验证独立化验收标准实现为布尔清单 确定性工具侧检查视觉核验、脚本 lint、干净环境重跑分数与决策权永远不在 Agent 手里状态显式化重试靠session_id续接跨会话知识靠文件式共享记忆中转会话转录落盘可审计。仓库中 pipeline 目录 下的orchestrator.py、creator_agent.py、sandbox_tools.py、shared_memory.py、prompts.py五个文件与 AGENT_DESIGN.md 相互印证构成了一份设计文档 参考实现的完整样本适合作为构建其他批量 Agent 任务时的架构参照。【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cua创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 cua-sandbox-apps 的 Agent 编排设计：Python 外循环 + Creator/Auditor 双 Agent 模式
cua-sandbox-apps 的 Agent 编排设计Python 外循环 Creator/Auditor 双 Agent 模式【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cuaAGENT_DESIGN.md 是cua-sandbox-apps子项目的核心设计文档它规定了如何用Python 外层循环 双 AgentCreator 生产 / Auditor 审计 单一提交工具的模式批量为任意软件生成可在沙箱中验证的 install/launch 脚本。本文完整继承该设计文档中的模式代码、8 条设计规则与 7 类反模式并结合 creator_agent.py、orchestrator.py 等源码实现讲清这套模式如何落地为可运行的 agent 流水线读完可以掌握如何把批量环境生成任务拆成确定性的 Python 控制流与有限职责的 Agent 会话。1. 背景cua-sandbox-apps 在做什么cua-sandbox-apps 的 README 将其定位为CUA 沙箱的通用应用目录与安装器流水线目标是 Gym-Anything 风格的环境生成发现软件、创建安装/启动脚本然后在沙箱中用截图验证。其使用方式非常直接from cua_sandbox import Image, Sandbox # Build an image with an app pre-installed image Image.linux().app_install(godot-engine) async with Sandbox.ephemeral(image) as sb: await sb.apps.launch(godot-engine) screenshot await sb.screenshot()而生成这些安装器本身就是一个需要大规模并行的 Agent 任务目录中每个 app × OS 组合都要独立完成调研 → 写脚本 → 沙箱内执行 → 截图验证 → 提交这一整套流程。这个子项目的 apps 目录 里已经沉淀了 ansible、godot-engine、postgresql、nmap、wireshark 等几十个应用的产出物每个应用目录下都有按 OS 划分的install.sh/launch.sh/extract_metadata.sh/metadata.json例如 ansible 的 linux 产物。要稳定地批量产出这类结果靠的不是一个全能 Agent而是AGENT_DESIGN.md所规定的这套编排纪律。2. 核心模式Python 外循环驱动双 Agent2.1 模式代码设计文档给出的参考模式如下这是整篇文章的骨架for item in items: session_id None for attempt in range(3): # Creator agent: sandbox tools ONE submit tool creator_result await run_agent(item, session_id, creator_tools) session_id creator_result.session_id # Auditor agent: sandbox tools ONE submit_audit tool checklist audit await run_agent(creator_result.submission, auditor_tools) # Python: extract bools, calculate score, decide score sum(c[passed] for c in audit.checklist) / len(audit.checklist) if score threshold: break # else: creator retries with session continuation auditor feedback逐句拆解这个模式的设计意图for item in itemsPython 持有全部工作项这里是 app × OS 对Agent 永远只处理一个 item。这样每个 Agent 会话的职责边界、失败隔离、并发调度都由确定性代码掌控。session_id的传递重试时把上一轮 Creator 的session_id传回使 Creator 在同一会话上下文中继续工作而不是失忆后从零开始。源码中 Creator 会话确实会捕获session_id并用于导出会话转录见下文 creator_agent.py 中_save_transcript的逻辑。Auditor 独立于 Creator验证由另一个 Agent或验证机制基于提交物独立执行杜绝自己写、自己验收。Python 从布尔清单算分score sum(c[passed] ...) / len(...)。Agent 只回答这一条过没过分数计算、阈值判定、是否重试全部在 Python 里完成。2.2 模式在当前仓库中的落地形态需要说明实现现状设计文档描述的是通用模式而当前代码库中 Creator 侧已完整实现审计职责则以提交工具内嵌验证的形式体现——submit_result工具在接收提交时执行截图视觉核验、元数据检查、静态 lint 和全新沙箱重跑等硬性校验见 creator_agent.py 的 _make_submit_tool。也就是说Auditor 用清单逐项给 bool的思想被落实为工具侧确定性的逐项失败清单任何一项不过就返回CRITERIA NOT MET并列出全部未过项要求 Agent 修复后重新提交失败清单生成与返回。外层 Python 循环则由 run_orchestrator 实现检测宿主机能加速运行哪些 OS 沙箱detect_supported_os支持 linux/windows/macos/android 四种类型从 discovery 目录的 JSONL 加载条目跳过 webapp 与 library 类型这些不是可安装运行的终端软件用_already_created扫描 apps 目录跳过已有install.*或result.json的 app/OS 对天然支持断点续跑通过asyncio.Semaphore(concurrency)控制并发asyncio.gather汇总每个 pair 的成功/失败。这正是Python loops over items — never the agent规则的执行体Agent 从不感知自己处理的是第几个 item更不参与 item 之间的调度。3. 八条设计规则Rules设计文档的 8 条规则是整套模式的纪律约束逐条说明如下并给出源码印证。Python loops over items — never the agentPython 遍历工作项绝不交给 Agentorchestrator.py 中tasks [_run_one(entry, os_type) for entry, os_type in work]就是这条规则的直接体现工作队列在 Python 里构建每个任务由独立 Agent 会话消费。Two agents per item — creator does work, auditor verifies independently每个 item 两个 AgentCreator 干活Auditor 独立验证验证独立性的工程化手段是提交校验不信任 Agent 的自述。例如 submit_result 的截图检查 会用 Bedrock 上的 haiku 视觉模型对截图逐张核验应用窗口是否真实可见只有回复以PASS开头才算通过即使 Agent 声称应用已打开截图只有桌面也照样被打回。One submit tool per agent — no get_next, no submit_results, no update_and_submit每个 Agent 只有一个提交工具工具命名与语义收敛到单个submit_result工具定义。allowed_tools白名单中提交类工具仅此一个工具白名单Agent 不存在再交一次另一个版本的歧义路径。Auditor uses a checklist — returns[{item, passed: bool}], never a score审计用清单只返回布尔项绝不给分提交校验返回的失败清单正是布尔项列表failures: list[str]逐项累积截图缺失、metadata 缺binary_path、install 脚本缺 fail-fast 头、fresh-sandbox 重跑失败……最后一次性渲染成清单返回Check 1–4 的累积逻辑。Python calculates scores — from checklist bools, never ask agent for a number分数由 Python 从布尔项算出永远不让 Agent 报数字校验结论verification_passed是布尔值由工具端代码直接赋值result[verification_passed] True通过路径全程没有请给这次提交打分的提示。Session continuation on retry — passsession_idso creator keeps context重试时传递 session_id 保留上下文Creator 会话通过async for msg in query(...)流式捕获session_id并在结束后用claude-code-transcripts把会话 JSONL 转成 HTML 转录存档到logs/install-transcript/_save_transcript 与 调用处。会话可追溯、可续接是重试不丢上下文的基础设施。Pre-boot sandbox in Python — agents never waste turns on setupPython 预先准备环境Agent 不为搭环境烧回合当前实现中沙箱创建被封装成create_sandboxMCP 工具sandbox_tools.pyAgent 一次调用即获得可用 VM而更彻底的预启动体现在审计/验证路径strict 验证沙箱verify-{name}完全由 Python 侧代码创建、重跑、销毁fresh-sandbox 重跑Agent 全程不触碰。Action-script prompts — numbered steps with exact tool calls, not open-ended提示词写成动作脚本编号步骤 精确工具调用而非开放式描述CREATOR_SYSTEM_PROMPT 就是典型动作脚本WORKFLOW 一节列出 12 个编号步骤每步指明调用哪个工具、产出什么文件、JSON 字段的确切 schemabinary_path、display_name、icon_paths、version等。早期退出条件无公开下载 / library / webapp也写成了精确到字段取值的提交模板如install_exit_code: -1, app_type_detected: library。4. 七类反模式Anti-Patterns及成因设计文档的反模式清单与上述规则一一对应构成为什么不能这么做的对照表反模式后果原文设计上的对策Agent loops over items1-2 个 item 后就耗尽 turnsPython 外循环Agent 单 item 单会话Agent self-verifies自我确认偏差独立 Auditor / 工具侧独立核验视觉模型看截图而非 Agent 自述Multiple submit toolsAgent 选错工具、行为混乱每个 Agent 仅一个 submit 工具Auditor gives scores打分随意、不可复现只回布尔清单分数由 Python 计算Fresh agent on retry丢失上下文重复劳动重试传递session_id续接会话Agent boots sandbox浪费回合在环境准备上Python 侧预建/代管沙箱生命周期Open-ended promptsAgent 去探索而不是执行编号动作脚本提示词精确到工具调用其中Agent loops over items → runs out of turns是批量 Agent 任务最常见的死法一个会话的上下文窗口与 turn 上限是有限资源让它串行处理 N 个 item 意味着把调度压力堆到了最不适合做调度的组件上。5. 源码纵深Creator 侧如何把规则变成代码5.1 工具面Agent 没有 Bash只有沙箱sandbox_tools.py 的模块注释开门见山Creator agents get these tools instead of Bash. All execution happens inside ephemeral cua_sandbox VMs — nothing runs on the host. 六个工具构成完整的沙箱操作面create_sandbox(os)按 OS 枚举创建 VM支持 linux/windows/macos/android返回os-8位hex形式的名字sandbox_run(name, command)沙箱内执行 shell 命令返回 exit code / stdout截断 10000 字节/ stderr截断 5000 字节默认超时 120 秒sandbox_runsandbox_write / sandbox_read向 VM 写文件heredoc 方式可选 chmod x与读文件默认最多 200 行sandbox_screenshot(name)截取 VM 显示画面存为 JPEG 到证据目录quality85delete_sandbox(name)销毁 VM。隔离性由每 Agent 一个独立 registry保证make_sandbox_tools(evidence_dir, sandbox_registry)中每个 Creator 会话持有自己的my_sandboxes字典create_app_installer 中的初始化跨 Agent 互不干扰会话结束包括异常路径在finally里强制销毁该 Agent 名下所有残留沙箱强制清理。5.2 提交核验四层检查的布尔清单submit_result的核验链把清单审计执行得相当彻底顺序如下Check 1–4截图核验在证据目录找{sandbox_name}.jpg/.png交给 haiku 视觉模型回答应用是否可见CLI 类应用is_cli: true放宽为终端中有工具输出/版本信息也算 PASS核验提示词。元数据核验metadata必须包含binary_path与display_name且extract_metadata_script会再经视觉模型评审一次确认它是真正动态探测安装产物而不是把路径写死_verify_metadata_script。install 脚本静态 lint 全新沙箱重跑正则拒绝|| true、|| :、|| echo 等错误吞噬写法_ERROR_MASK_RE 与 _lint_error_masking检查头部 20 行是否具备set -euo pipefail_lint_fail_fast在strict_install_verify开启时默认开启还会在全新沙箱里把提交的 install 脚本原样重跑一遍最长等 30 分钟专治交互调试留下的状态让脚本看起来能跑的问题。早期退出通道download_available: false或install_exit_code -1直接记录结果落盘如 adobe-photoshop 的 result.json不进入沙箱流程。任何一项失败都会把全部失败原因拼成CRITERIA NOT MET清单一次性返回让 Agent 在一个回合内看到所有缺口而非逐条挤牙膏。5.3 动作脚本提示词的结构CREATOR_SYSTEM_PROMPT 除 12 步 WORKFLOW 外还内嵌了平台细节Linux VM 自带 XFCE 桌面与 display server禁止再装 xvfbmacOS 首次启动的 Apple Account 弹窗用key code 53Esckillall Setup Assistant处理以及FAIL FAST / NO ERROR MASKING / IDEMPOTENT三条脚本质量铁律——与第 5.2 节的 lint 检查一一对应提示词负责事前约束lint 负责事后兜底双保险。5.4 跨 Agent 经验沉淀文件式共享记忆shared_memory.py 实现了memory/目录下的按 OS 文件general.md linux/windows/macos/android.mdorchestrator 启动时init_memory写入种子经验如 Ubuntu 24.04 上 libasound2 → libasound2t64、winget 静默安装要带-hAgent 结束后可append_learning追加带时间戳的新经验后续 Agent 通过read_memory读取。这是Python 外循环红利之一——跨会话的知识传递必须由确定性代码中转Agent 会话本身是短命的。6. 使用方式与产物布局通过 cli.py 的 Click 入口可以驱动整条流水线discover onet静态加载 O*NET 职业分组→discover software并行 Agent 发现软件目录默认目标 5 万条、22 并发→discover enrich元数据补全→ 安装器创建对应 orchestrator 的run_orchestrator支持--os过滤、--limit、--concurrency等参数。CLI 启动时会自动加载包根目录的.env注入 Bedrock/API 配置cli.py 头部截图视觉核验依赖AWS_REGION默认us-east-1。产物目录约定对应当前仓库中的真实结构apps/app_id/ app.json # 应用级元数据跨 OS 共享 os/ install.sh | install.ps1 launch.sh | launch.ps1 extract_metadata.sh metadata.json # binary_path / display_name / icon_paths / version logs/ # 会话 JSONL、HTML 转录、install-result.json、截图证据例如 godot-engine 的 linux 产物 与 README 中的消费方式Image.linux().app_install(godot-engine)首尾呼应Agent 流水线产出的脚本最终变成cua-sandbox的一等构建能力。7. 小结这套模式的可迁移价值AGENT_DESIGN.md的核心主张可以浓缩为一句话让 Agent 做它擅长的单点任务让确定性代码做一切需要复现性和状态管理的事。具体到三条可迁移经验职责切分批量调度、重试计数、分数计算、资源清理全部放在 PythonAgent 会话保持单 item、单提交工具、有限上下文的最小形态验证独立化验收标准实现为布尔清单 确定性工具侧检查视觉核验、脚本 lint、干净环境重跑分数与决策权永远不在 Agent 手里状态显式化重试靠session_id续接跨会话知识靠文件式共享记忆中转会话转录落盘可审计。仓库中 pipeline 目录 下的orchestrator.py、creator_agent.py、sandbox_tools.py、shared_memory.py、prompts.py五个文件与 AGENT_DESIGN.md 相互印证构成了一份设计文档 参考实现的完整样本适合作为构建其他批量 Agent 任务时的架构参照。【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cua创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考