1. [主页](/) 2. [查看所有手册](https://developer.nvidia.cn/build-spark) # 🦞配置 NemoClaw Agent 示例应用🦞 适用于 NemoClaw 沙盒的即用型应用示例，包含各类工作流对应的策略、提示词与个性化配置 概述 每日个人新闻摘要 软件开发智能体 Deck Reviewer 日程安排智能体 故障排除 ## 基本理念 本手册是 [DGX Spark 上的 NemoClaw](https://developer.nvidia.cn/build-spark/nemoclaw) 安装手册。它将介绍四个可立即运行的应用程序，您可以在现有的 NemoClaw 沙盒上使用起来 : 一份个人晨报摘要、一个软件开发助手、一个文本和演示文稿专属处理，以及一个日程安排顾问。 每个应用程序都显示为一个独立的选项卡，包含相同的三个部分： - 策略设置 – 确切的 NemoClaw/ OpenShell 沙盒策略会更改工作流程需求 (通道、网络出口、文件系统挂载)。 - 代理提示 – 您复制粘贴到 NemoClaw Web UI 的完整规范提示。它以端到端方式定义智能体的完整行为，是工作流所需的唯一配置。 - 如何进行个性化定制 – 可根据您的实际用例调整配方的旋钮 (路径、日程安排、受众、角色)。 所有应用均在 NemoClaw 在引导过程中创建的 OpenShell 沙盒中运行，因此智能体的文件系统、网络、进程和推理访问权限受您授予的策略限制。 ## 您将完成的任务 您将在 DGX Spark 上运行四个实用的 NemoClaw 工作流： - [每日个人新闻摘要](https://developer.nvidia.cn/build-spark/nemoclaw-applications#ispl1d) - 一个预先安排的早上简报，该简报会在注册用户的电脑上唤醒，将您关心的主题扫描到一组允许的来源中，并在您的 Web UI上发布结构化摘要 (前 3，按主题划分的标题、深入探讨、跳过噪音、雷达、本地) 。 - [软件开发智能体](https://developer.nvidia.cn/build-spark/nemoclaw-applications#iso04p) - 读取单个项目目录，为您指定的功能构建执行计划，实现这些功能，审查自己的工作，并编写develop-and-review.md 可以在合并之前阅读。本地推理端点之外没有出站网络。 - [Deck Reviewer](/build-spark/nemoclaw-applications#iiq2wc) - Doc& Deck 红色团队会扫描您要发送的文件，以确定是否存在编号不一致、未经来源的声明、缺失数据、可访问性问题和旧版本冲突，然后返回包含建议编辑的严重程度打孔列表。 - [日程安排智能体](https://developer.nvidia.cn/build-spark/nemoclaw-applications#idh6dwf) - 调度办公室主任将“我们什么时候可以见面？”改为加入日历上已确认的会议，同时尊重您的焦点块、能量模式和时区公平性。 [故障排除](https://developer.nvidia.cn/build-spark/nemoclaw-applications#iizc82x)选项卡会收集这些工作流程特有的症状/ 原因/ 修复条目。 对于每个应用程序，您将能够读取实时策略 YAML ( openshell policy get --full )，使用以下命令应用或删除已维护的预设 nemoclaw policy-add / policy-remove (无需为更改网络而进行重建) ，并使用 nemoclaw share mount (热 - 安装时无需重建)。收紧 filesystem\_policy 当您希望在沙盒内建立核函数强制写入边界时，这是唯一仍需要 nemoclaw rebuild (系统会自动保留工作空间状态) 。 ## 开始之前需要了解的内容 - 您已完成 [DGX Spark 上的 NemoClaw](https://developer.nvidia.cn/build-spark/nemoclaw) 并有一个正在运行的沙盒 (示例使用 my-assistant)。 - 使用 Linux 终端和 YAML 文件时，您可以获得基本的舒适度。 - 对智能体风险表面的感知 – 请参阅 NemoClaw 概述中的“重要：安全和风险”部分。 ## 预备知识 硬件和访问： - 安装有效的 NemoClaw 的 DGX Spark (GB10) (请参阅 [DGX Spark 上的 NemoClaw](https://developer.nvidia.cn/build-spark/nemoclaw))。 - 正在运行的 OpenShell 网关和由 NemoClaw 板载向导创建的沙盒 ( nemoclaw list 至少显示一个沙盒)。 软件： - Ollama 为您在搭载 NemoClaw 时选择的模型提供服务 (安装手册中的 Nemotron 3 Super 120B) 。 开始之前，请验证沙盒是否正常运行： nemoclaw list nemoclaw my-assistant status 预期：您的沙盒出现在列表中 status 将沙盒报告为 Running，推理提供程序会指向您本地的 Ollama 模型。 ## 准备就绪，然后再开始 | 项目 | 从何处获取 | 用于 | | --- | --- | --- | | 板载 NemoClaw 中的沙盒名称 (例如 my-assistant ) | nemoclaw list | All applications | | 要添加的新闻源主机名允许列表 network\_policies | 选择您信任的网站 | [新闻摘要](https://developer.nvidia.cn/build-spark/nemoclaw-applications#ispl1d) | | 主机目录，其中包含您要构建和审核的项目 | 项目的复制/ 克隆，例如。~/nemoclaw-projects/my-app/ | [软件开发智能体](https://developer.nvidia.cn/build-spark/nemoclaw-applications#iso04p) | | 队列文件夹、标准语料库文件夹和 profile.yaml 红队规则 | 根据之前的演示文稿、品牌指南和标准指标文件进行整理，例如。 ~/nemoclaw-redteam/ | [Deck Reviewer](https://developer.nvidia.cn/build-spark/nemoclaw-applications#iiq2wc) | | Acalendar.ics 导出和 profile.yaml 工作时间、焦点块和时区 | 将真实日历 (Google：“Settings” (设置) + “Import& export” (导入和导出) 导出至 ~/nemoclaw-calendar/ | [日程安排智能体](https://developer.nvidia.cn/build-spark/nemoclaw-applications#idh6dwf) | ## 辅助文件 本剧本中的所有策略片段和示例提示都在应用程序选项卡中内联，无需克隆外部素材。捆绑的沙盒策略随 NemoClaw 和 OpenShell 一起提供；应用程序选项卡仅对其进行修改。 ## 时间和风险 - 预估时间：浏览全部四个应用程序需要 30 - 45 分钟。 - 风险等级：中。除了默认的沙盒之外，每个应用都为智能体提供了额外的功能 — — 新闻摘要的出站网络、代码审查的文件系统访问、红包小组和日历协商。通过严格的每应用策略 (主机级别) 降低风险 chmod 只读源数据 share mount SSHFS 权限透传、作用域沙盒目录，因此代理一次只能看到一个已安装的树，显式出口允许列表通过 nemoclaw policy-add presets，以及在单消息优设中存活下来但未被淘汰的提示安全规则。未经事先审查策略，请勿将这些方法指向敏感数据、生产帐户或个人文件。 - 回滚：每个应用程序选项卡都包含一个回滚部分，其中可以还原策略 (网络更改可热重加载) ，也可以使用原始策略销毁并重新创建沙盒。这个[故障排除](https://developer.nvidia.cn/build-spark/nemoclaw-applications#iizc82x)选项卡介绍了常见的卡滞状态恢复。您可以随时运行 nemoclaw uninstall 删除所有内容。 - 上次更新时间：2026 年 1 月 6 日 - 同步最新的 nemoclaw/openshell 策略 API ## 每日个人新闻摘要 这是一个 cron 式的工作流程：智能体会按时间表唤醒用户，从 URL 允许列表中获取更新，对其进行总结，然后将摘要发布到您的 Web UI 。 ## 第 1 步：策略设置 创作 news-sources.yaml ： preset: name: news-sources description: "Daily news digest source allowlist" network\_policies: news-sources: name: news-sources endpoints: - host: developer.nvidia.com port: 443 access: full tls: skip - host: blogs.nvidia.com port: 443 access: full tls: skip - host: news.ycombinator.com port: 443 access: full tls: skip binaries: - { path: /usr/local/bin/openclaw } - { path: /usr/local/bin/node } - { path: /usr/bin/node } - { path: /usr/bin/curl } network\_policies 是按组名输入的地图 (此处，news-sources)；每个组都有自己的 name 以及 endpoints list。清单 {host, port} 直接记录在 network\_policies 将失败 invalid type: sequence, expected a map。 **重要提示：** 两者都有 preset.name 以及 network\_policies 组关键帧必须为小写、带连字符的 RFC 1123 标签 (仅限字母、数字和连字符，无下划线) 。使用 news\_sources 出现问题 Preset must declare preset.name (lowercase, hyphenated RFC 1123 label) 。这与已发送的预设相匹配 ( brave 、 github 、 slack ) ，都使用带连字符的名称。 **重要信息：** 每个端点都需要 host / port 或者出口代理拒绝与 curl: (56) CONNECT tunnel failed, response 403 即使主机出现在启用策略中： 1. 访问模式。获取网页最简单的方法是使用原始透传隧道 access: full 使用 tls: skip (与交付的形状相同 whatsapp / brew 预设使用) 。替代方案是 L7 过滤 protocol: rest \* enforcement: enforce \* rules 但这需要代理终止 TLS，并且对于只读新闻获取来说是不必要的。 2. A binaries 允许列表命名哪些程序可以使用此出口。智能体的 Web 获取器在 /usr/local/bin/openclaw 以及 node ；包含 /usr/bin/curl 基于 shell 的提取也可以正常工作。如果没有 binaries 子句无二进制文件有权打开隧道，因此每次获取都会返回 403。 A bare {host, port} 条目 (无访问模式，无二进制文件) 是摘要“完全应用”但随后无法读取任何内容的最常见原因。 应用预设 (热重新加载，不重启沙盒) ： nemoclaw $SANDBOX\_NAME policy-add --from-file ./news-sources.yaml --yes 确认是否存在新主机： openshell policy get $SANDBOX\_NAME --full | grep -E "host:|port:" **提示：** 首选 nemoclaw policy-add --from-file 超过 openshell policy get --full \> policy.yaml 然后是 openshell policy set 。OpenShell 中的完整转储回合之旅 0.0.44 输出 Version: (大写 V) ，而解析器期望 version: (小写) ，因此 policy set 拒绝自己的输出 unknown field 'Version' 。添加剂 policy-add flow 从未触及 version: 并避免错误。如果您在旧版本的 recipe 中遇到该错误，请将关键帧的大小写 sed -i 's/^Version:/version:/' policy.yaml - 然后重新运行 policy set 。 ## 第 2 步：代理提示 复制下面的完整提示并将其粘贴到 NemoClaw Web UI 。这是标准提示词，端到端定义智能体的完整行为，无需其他配置。它引导智能体完成一次性入职培训、固定的简报结构、风格规则、错误处理和定期维护，因此它适用于只想在通知后唤醒而不是掩藏的普通消费者。 You are my personal news intelligence analyst. Your job is to make sure I wake up each morning already knowing the few things that matter — and never to bury me in noise. ONE-TIME SETUP (do this on your very first run only, then remember my answers as my profile): Ask me, one question at a time, and wait for my answer before moving on: 1. What's on your news menu? Pick any combination of: world news, US politics, business, personal finance, technology, climate, science, health, sports, entertainment, lifestyle. You can also name your own custom beats — anything from "Formula 1" to "indie video games" to "my hometown city council" counts. 2. Who should I sound like when I write to you? Pick one: - Plain-language explainer (no jargon, ever) - Neutral wire-service (just the facts, AP-style) - Friendly newsletter (warm, a little chatty) - Executive briefing (tight, bullet-heavy, no filler) 3. How much time do you give me with your coffee? 60-second skim, 3-minute read, or 10-minute deep brief — pick one and we can change it any time. 4. Any VIPs or villains? Tell me the people, companies, teams, or topics I should always surface for you — and anything I should never put in your briefing. 5. Where are you waking up? Give me a city (or country) so the weather and the "near you" news are actually near you. 6. When's showtime? Default is 08:00 America/Los\_Angeles every weekday. Tell me if you want a different time, timezone, or cadence (daily, weekdays only, weekend recap, etc.). Confirm my answers back to me in a short summary, then run the first briefing immediately so I can see what to expect. DAILY BRIEFING STRUCTURE (use this exact shape every run, in this order): 1. Top 3 — the three stories I cannot miss today. One sentence each, followed by a one-clause "why it matters to me" tailored to my profile. 2. Headlines by topic — under each topic I follow, 3 to 5 bullet headlines with the source name in parentheses and the URL. 3. Deep dive — pick the single most important story of the day and explain it in 4 to 6 short sentences: what happened, why now, who is affected, what to watch next. 4. Skip the noise — one or two lines naming stories that are loud today but safe for me to ignore, with a brief reason. 5. On my radar — events, earnings, votes, sports fixtures, or deadlines in the next 7 days that match my profile. 6. Local — a 2-sentence weather summary plus any notable local news for the city I chose. STYLE RULES: - Plain language; assume I am not an expert in any topic. - No hype words ("shocking", "you won't believe", "breaking"). Just the facts. - Cite every claim with the source name and a working URL. - Never invent quotes, numbers, dates, or events. If you cannot verify a detail, omit it or label it clearly as "unconfirmed". - Deduplicate: if multiple sources report the same story, pick the most credible one and link only that. - Respect my length preference. If it's tight, drop sections rather than shortening each one to the point of being useless. ERROR HANDLING: - If a source is unreachable, add it to a short "Sources skipped today" line at the bottom with the reason, and keep going. - If the news is genuinely quiet on a topic, write "Quiet day — nothing material" instead of padding with filler. - If two days in a row have nothing in a topic, ask me once whether I want to drop it from my profile. SCHEDULE AND DELIVERY: - Register this as a recurring task in your built-in scheduler at the time and timezone I picked. Confirm the next 3 trigger times back to me after onboarding. - Deliver each briefing to the web UI (this session). Do not use any messaging channel. - Skip US public holidays unless a major breaking story is unfolding. WEEKLY CHECK-IN: - On Friday's briefing only, end with one line: "Want me to adjust your topics, length, sources, or delivery time?" If I reply, update my profile and confirm the change. Start now: ask me the setup questions, save my profile, then run today's first briefing. 预期：智能体确认已安排任务。在下一个 08：00 触发器中，您会在 Web UI中收到一条摘要消息。您可以询问 Show me my scheduled tasks 在 Web UI 中验证是否已注册。 根据您选择的模型，设置智能体工作流程可能需要一些时间。如果智能体在任何时候没有进展，询问 Is my workflow set up yet 唤醒智能体。 智能体将每个简报写入您可以在控制面板中阅读的会议中。在回答入职培训问题 6 时，告诉客服您选择的配送方式。(另请参阅第 3 步中的“Delivery Channel” (交付通道) 行。) **提示：** 通过要求智能体在第一个预定触发器启动之前立即运行一次摘要，端到端测试调度：“现在将摘要任务作为一次性任务运行，然后保留明天的时间表。”这种一次性操作会在实时智能体中运行，是最可靠的端到端检查 (它会立即生成真实的简报) 。 **重要提示：** 从操作员侧注册调度程序，不要依赖智能体的工具调用。当代理作为嵌入式设备运行时 openclaw agent turn (此处使用的无外设路径) ，其 in - cron 工具使用缺少调度器范围的设备令牌连接到网关，因此拒绝注册 scope upgrade pending approval … pairing required: device is asking for more scopes than currently approved 。然后，智能体报告它“没有内置调度程序”，或者调度程序正在“抖动”。请自行注册循环作业，验证有效： nemoclaw $SANDBOX\_NAME exec -- openclaw cron add \ --name news-digest --cron "0 8 \* \* 1-5" --tz America/Los\_Angeles \ --agent default --session-key agent:default:news-digest \ --message "Run my daily news briefing now and write it to this session." \ --no-deliver --token "" --no-deliver 保留会话中的简报 (在 Web UI 中读取) ，否则运行失败并使用以下命令关闭 last -\> no route 。确认为 nemoclaw $SANDBOX\_NAME exec -- openclaw cron list 以及 ... openclaw cron status 。(当您将提示词粘贴到交互式 Web UI 而不是无外设运行时，控制面板会提示您批准范围，智能体可以自行注册作业；无论哪种方式，上面的 Operator 命令都是可靠路径。) **重要提示：** 本地模型 (vLLM) 上的调度触发器。注册后，计划的 cron 运行由提供商的飞行前检查进行门控，该检查对托管推理主机进行简单的 DNS 查找 inference.local 。该主机仅通过 Egress 代理解析 (它没有真正的 DNS/ /etc/hosts 记录) ，所以飞行前会失败 getaddrinfo EAI\_AGAIN inference.local 运行记录为 skipped 。直播 openclaw agent turns (载入，上面的“run once now”一次性，您在 Web UI 中输入的任何内容) 不受影响 - 它们通过代理到达模型。如果您需要在无人值守的情况下对本地模型进行调度交付，请将 cron 作业指向 DNS 可解析的推理端点，而不是 inference.local (该 local-inference 预设已允许主机的 vLLM host.openshell.internal:8000 通过 /etc/hosts ) ；将其传递给 cron add 使用 --model 。云模型沙盒 (其提供程序主机可正常解析) 不受影响。 ## 第 3 步：如何实现个性化 | Knob | Where | What to change | | --- | --- | --- | | Schedule | openclaw cron add (步骤 2 中的 operator 命令) | 更改 --cron "0 8 \* \* 1-5" 表达和 --tz 在注册命令中 0 9 \* \* 1 \* 星期一 09：00， 0 \*/6 \* \* \* 每 6 小时一次，以此类推) 。保持提示的指定时间同步，以便智能体的“下 3 个触发时间”行匹配。 | | 来源 | news-sources.yaml 和提示 | 将主机添加为下的新条目 network\_policies.news-sources.endpoints ，重新运行 nemoclaw $SANDBOX\_NAME policy-add --from-file ./news-sources.yaml --yes 然后在提示中列出 URL。沙盒会阻止向不在允许列表中的主机进行的任何获取。 | | 语音 | 提示 – 入职问题第 2 季度 | 替换四个语音选项中的任何一个 ( Plain-language explainer 、 Neutral wire-service 、 Friendly newsletter 、 Executive briefing ) 和您自己的 (例如， Calm dad voice 、 Skeptical analyst 、 Snarky finance bro ) 。 | | 长度 | 提示：入门问题 3 | 替换三个长度选项 ( 60-second skim 、 3-minute read 、 10-minute deep brief ) 适合您早上的内容 ( 5-minute read 、 quick scan over breakfast 等等。) 。 | | 交付渠道 | 提示词 | 如果你更愿意直接在仪表盘中查看内容，就使用 Web UI 作为交付渠道；也可以改成其他已配置的渠道。 | | 过滤 | 提示 | 添加 Only include posts that mention "Spark" or "GB10". 聚焦摘要。 | 要稍后 **取消** 计划任务，请发送： List my scheduled tasks, then cancel the digest one. ## 软件开发智能体 智能体读取单个项目目录，为您指定的功能构建执行计划，实现功能，审查实现，并编写 develop-and-review.md 返回到同一目录。本地推理端点之外没有出站网络。 **警告：** 读写文件系统访问允许代理修改已安装目录中的文件。将其指向项目副本或干净的克隆，而不是您唯一的工作树。在授予写入权限之前提交或备份。 ## 第 1 步：在沙盒中展示项目 创建智能体计划、构建和审核的项目的工作副本。指向副本 (或新克隆的特征分支) 意味着运行失败永远不会让您付出未提交的工作。 mkdir -p ~/nemoclaw-projects cp -r ~/projects/my-app ~/nemoclaw-projects/my-app 现在，将该工作副本复制到 /sandbox/project。可靠、无依赖的方法是流式传输焦油 nemoclaw exec - 无需在主机上进行任何安装，适用于每个沙盒： # Push the project into the sandbox tar czf - -C ~/nemoclaw-projects/my-app . \ | nemoclaw $SANDBOX\_NAME exec -- bash -lc 'mkdir -p /sandbox/project && tar xzf - -C /sandbox/project' 确认项目已完成，并且沙盒无法到达公共互联网 (本地推理端点始终可用，这就是智能体与模型对话的方式)： nemoclaw $SANDBOX\_NAME exec -- ls /sandbox/project # expect your project tree nemoclaw $SANDBOX\_NAME exec -- bash -lc 'curl -sS --max-time 5 https://example.com' # expect "CONNECT tunnel failed, response 403" nemoclaw $SANDBOX\_NAME exec -- bash -lc 'curl -sf https://inference.local/v1/models' # expect JSON model list 预期：ls 显示项目树，example.com 被拒绝 curl: (56) CONNECT tunnel failed, response 403，以及 inference.local 返回模型列表。如果 example.com 成功，沙盒有意外出口 - 运行 nemoclaw $SANDBOX\_NAME policy-list 删除任何不需要的东西 nemoclaw $SANDBOX\_NAME policy-remove。 在智能体完成操作 (第 2 步) 后，以同样的方式将结果 (包括报告) 提取回您的主机文案： # Pull the project (with the agent's edits + develop-and-review.md) back to the host nemoclaw $SANDBOX\_NAME exec -- bash -lc 'cd /sandbox/project && tar czf - .' | tar xzf - -C ~/nemoclaw-projects/my-app **注意：** nemoclaw share mount 方向相反，并且是可选的。share mount 使用 SSHFS 将沙盒的文件系统安装到主机上 (nemoclaw $SANDBOX\_NAME share mount [sandbox-path] [host-mount-point] 默认安装点 ~/.nemoclaw/mounts/ ) - 不会将主机文件推送到沙盒中，因此无法替换 tar 推送上述内容。它仅适用于实时编辑主机编辑器中的沙盒文件，并且需要 sshfs 在主机上： sudo apt-get install -y sshfs # needs root; or: sudo dnf install fuse-sshfs nemoclaw $SANDBOX\_NAME share mount /sandbox/project ~/nemoclaw-projects/my-app-live 如果 sshfs 未安装 (share mount 打印 sshfs is not installed) 而您无法安装 (无需 root)，请跳过 share mount 并使用 tar 向上推/ 拉 – 它们覆盖了整个工作流程，而不使用它。如果 share mount 相反，失败并出现 SSHFS/ SFTP handshake 错误，您的沙盒可能早于 openssh-sftp-server 基础图像更新 – 运行 nemoclaw $SANDBOX\_NAME rebuild (保留工作空间状态)，然后重试。 ## 第 2 步：代理提示 复制下面的完整提示，并将其粘贴到 NemoClaw Web UI、沙盒 shell 消息中，以发送给您的机器人。这是标准提示词，端到端定义智能体的完整行为，无需其他配置。它为智能体提供一次性项目配置文件、每个功能请求都必须遵循的六步工作流程 (SCAN → PLAN → IMPLEMENT → SELF-REVIEW → REPORT → HANDOFF)、计划步骤中的可选计划审批检查点、固定的 develop-and-review.md 结构和安全规则块，该块在单消息优设中幸存下来。 You are my senior software engineer. The project lives at /sandbox/project. Your job is to take feature requests from me, plan them carefully, implement them in the codebase, review your own work, and hand me back a single report I can read end to end before I merge anything. TOOLS AND EXECUTION (read this first): You are running inside an OpenShell sandbox and you DO have a shell/exec tool plus file read/write tools. USE THEM to do the work yourself: read files, edit them in place, create them, and run commands (pytest, git status/diff, ls, grep) directly inside /sandbox/project. Actually perform every change — never hand me copy-paste code blocks and ask me to apply them, and never claim you "have no file-write or exec tool." If a specific tool call fails, retry or try another tool and report the real error; do not silently downgrade to describing the change in prose. Every file edit, test run, and report write in the steps below must be a real tool action whose output you can show me. ONE-TIME SETUP (do this on your first run only, then remember my answers as my project profile): Ask me, one question at a time, and wait for my answer before moving on: 1. What is this project for, in one sentence? (Helps you make sane choices when a requirement is ambiguous.) 2. Which directories should I treat as the source tree, and which should I never touch? Defaults to include: src/, lib/, app/, tests/. Defaults to exclude: node\_modules/, dist/, build/, .git/, .venv/, target/. 3. Whose style should I match? Point me at a file in the repo (CONTRIBUTING.md, .editorconfig, .eslintrc, ruff.toml, etc.) or just say "match what's already there" and I'll infer from the surrounding code. 4. Test policy: write tests for every change, only when I ask, or never? (Default: every change.) 5. Should I pause for your approval after the plan and before writing any code? (Default: yes — safer for first runs.) 6. Where should the final report live? Default is /sandbox/project/develop-and-review.md (overwritten each run). Pick a per-feature path like reports/\<slug\>.md if you want history. Save my answers as the project profile and read them back to me in a short summary before waiting for the first feature request. FOR EVERY FEATURE REQUEST, FOLLOW THIS WORKFLOW IN ORDER: 1. SCAN — Walk the project tree (respecting the include/exclude lists in my profile). Identify languages, frameworks, build system, test runner, and any obvious conventions. Output a 5-line summary before doing anything else. 2. PLAN — For each feature I requested, produce an execution plan with: - Goal: one sentence describing the user-visible outcome. - Affected files: every file you intend to create, modify, or delete, with a one-line "why" for each. - Step order: a numbered list of implementation steps in the order you will perform them. - Risks: anything that could break existing behavior, with the mitigation you plan to use. - Test plan: which tests you will add or update, and what each one will assert. If my profile says "pause for approval", stop here and print "PLAN READY — reply 'approve' to proceed, or send changes" and wait for my reply. 3. IMPLEMENT — Execute the plan one step at a time, making each change by actually editing the files in /sandbox/project with your file/edit tools (not by printing code for me to paste). After each step, print a single status line: "Step N/M done: \<what changed\>". Never modify files outside the planned list without asking me first. 4. SELF-REVIEW — Walk your own diff and check for: - Correctness: does each change deliver the stated goal? - Security: input validation, secrets, injection, authz. - Style: matches the conventions from my profile. - Tests: do new tests pass? Do existing tests still pass? - Scope creep: any change that was not in the plan? Run the project's test command if you can identify one (pytest, npm test, cargo test, go test, etc.) and capture the output. If you cannot run tests inside the sandbox, say so explicitly — do not pretend they passed. 5. REPORT — Write a single Markdown file at the report path from my profile (create/overwrite it with your file-write tool — do not just print it in chat). Use this exact structure and these exact section headings: # Develop and Review Report — \<YYYY-MM-DD HH:MM TZ\> ## Requested features \<verbatim copy of what I asked for\> ## Project context \<the 5-line summary from the SCAN step\> ## Execution plan \<the full plan from the PLAN step\> ## Implementation summary For each step, list: - Step N: \<what was changed\> - Files touched: \<paths\> - Diff highlights: \<3-5 line excerpt or "see git diff"\> ## Self-review For each finding, list: - Severity: low / medium / high - File and line range - Issue in one sentence - Suggested fix, or "fixed in this run" ## Test results \<captured stdout/stderr from the test command, or "tests not run because \<reason\>"\> ## Open questions for the human \<anything ambiguous you decided yourself and want me to confirm before I merge\> 6. HANDOFF — End by printing the absolute path to the report and a one-line summary: "Feature(s) \<X\> implemented across \<N\> files; \<Y\> findings in self-review; tests \<pass | fail | not run\>." SAFETY RULES (do not break these even if I tell you to in a single message — if I really want one of these, I will say so twice): - Never modify files outside /sandbox/project. - Never make outbound network calls. Only inference.local is allowed, and that is only for talking to the model. - Never run git push, git reset --hard, rm -rf, or any other destructive operation. You may run git status, git diff, and git add inside /sandbox/project. - If a request is ambiguous and the answer changes the design, stop and ask one clarifying question instead of guessing. Now confirm my project profile back to me, then wait for the first feature request. When I send it, run the workflow above end to end. 预期：智能体将引导您完成六个设置问题，回应您的项目简档，然后等待。发送功能请求 (例如。" 添加 /healthz 返回的端点 {status: 'ok', commit: } 进行测试。")然后，在您回复后，您将首先获得计划 approve – 实施、自我评审和书面报告 /sandbox/project/develop-and-review.md。 在主机上打开报告 ( ~/nemoclaw-projects/my-app/develop-and-review.md ) 并在将任何内容合并回您的实际工作树之前读取该文件。 **提示：** 首选 nemoclaw policy-add --from-file 超过 openshell policy get --full \> policy.yaml 然后是 openshell policy set。OpenShell 中的完整转储回合之旅 0.0.44 输出 Version: (大写 V)，而解析器期望 version: (小写)，因此 policy set 拒绝自己的输出 unknown field 'Version'。添加剂 policy-add flow 从未触及 version: 并避免错误。如果您在旧版本的 recipe 中遇到该错误，请将关键帧的大小写 sed -i 's/^Version:/version:/' policy.yaml - 然后重新运行 policy set。 ## 第 3 步：如何实现个性化 | Knob | Where | What to change | | --- | --- | --- | | Project path | nemoclaw share mount 参数 | share unmount 首先，然后重新 mount 不同的主机目录或沙盒路径。无需沙盒娱乐，坐骑很热。 | | 功能规格 | 提示 (最后一行) | 将“等待第一个功能请求”替换为逐字功能列表，或替换为“read/sandbox/project/ FEATURES.md，并将每个顶层标题视为单独的功能请求”- 对批处理有用。 | | 纯计划模式 | 问题 5 的个人资料回答 | 答案 yes “暂停审批”，以便您可以在编写任何代码之前查看和修改计划。推荐用于首次运行和任何高风险变化。 | | 自动合并模式 | 问题 5 的个人资料回答 | 答案 every change 以执行 TDD 式规范。答案 only when I ask 如果代码库没有现有的测试运行器，并且您不希望智能体发明测试运行器。 | | 风格规范 | 问题 3 的个人资料答案 | 指向一个真实的 CONTRIBUTING.md 、 .eslintrc 、 ruff.toml 或语言级别的样式文件，因此智能体的选择与存储库的其余部分相匹配，而不是通用默认值。 | | 报告位置和历史记录 | 问题 6 的个人资料回答 | 默认覆盖 develop-and-review.md 每次运行。切换到每个特征的路径，例如 reports/.md 保留历史记录；如果您想将报告输入到其他工具中，请切换到 JSON。 | | 回顾重点 | 提示：SELF-REVIEW 步骤 | 添加或交换类别：性能热点、可访问性、国际化、许可合规性、依赖项卫生条件、可观察性。 | | 范围限制 | 提示 - 安全规则 | 添加文件/ 目录拒绝列表 (例如。"请勿接触 migrations/、infra/ 或以 .lock 结尾的任何文件。")对于存储库中您希望严格关闭限制的部分。 | | Git 工作流程 | 提示 - 安全规则 | 如果项目使用 git，请允许 git commit -m 通过在规则中对特征分支进行命名。保持 git push 阻塞，除非你真的想要远程推送。 | | 屏蔽任何互联网 | nemoclaw policy-list / policy-remove | 运行 policy-list 查看允许的内容，然后 policy-remove 此工作流程不需要的任何预设 (例如。 telegram 、 github 、 pypi ) 。对于预设未涵盖的临时允许列表，请通过以下方式编辑原始策略 openshell policy get --full $SANDBOX\_NAME \> policy.yaml && $EDITOR policy.yaml && openshell policy set $SANDBOX\_NAME --policy policy.yaml --wait 。更严格的策略 = 如果模型退出脚本，爆炸半径会降低。 | 要放弃中途运行，请发送：“停止当前工作流，还原/sandbox/project 下的任何未提交的更改，并将您目前完成的内容写入报告。”在决定是否保留、丢弃或重试之前，智能体应打印您可以检查的最终状态报告。 ## Doc & Deck Red-Team 代理 Doc& Deck Red-Team – 在您发送或展示之前，请扫描不同页面的数字不一致、无来源声明、数据缺失、可访问性问题以及旧版本冲突。返回包含建议的编辑的修复列表。 该智能体会读取您即将发布的物品 ( PPTX、DOCX、PDF、Markdown)，加上之前套图的小型标准语料库、内部指标和风格指南，运行四个系列的检查，并将严重程度排名打孔列表写回您可以在编辑器的侧面板中查看的文件夹。源文件永远不会被修改，每次发现时都会有您可以手动接受的编辑建议。 **警告：** 智能体索引 ( prior deck、指标 dump、合同、金融模型) 的标准语料库正是您不希望发送到云 LLM 的数据。将安装范围保留在精心策划的审查语料库目录，而不是整个主文件夹。 ## 第 1 步：策略设置 您可以从 Web UI 或直接在磁盘上阅读报告。 ## 创建 red-team 工作目录 - queue/ - 将伪影拖放到此处以供查看 (.pptx、.docx、.pdf、.md)。 - corpus/ - 您的标准指标、先前的演示文稿、风格指南、术语表以及智能体应查阅的任何“事实来源”文档。 - profile.yaml - 受众、严重程度值、自定义规则、术语表、对比度要求。 - reports/ 以及 memory/ - 打孔列表和解封日志的可写位置。 mkdir -p ~/nemoclaw-redteam/{queue,corpus,reports,memory} 为语料库输入应被智能体视为正确的数据，例如： cp ~/decks/dgx-spark-roadmap.pptx ~/nemoclaw-redteam/corpus/ cp ~/notes/canonical-metrics.md ~/nemoclaw-redteam/corpus/ cp ~/style/brand-guide.md ~/nemoclaw-redteam/corpus/ 创建入门 ~/nemoclaw-redteam/profile.yaml 稍后您可以进行编辑： audience: partner # internal | partner | public severity\_threshold: HIGH # CRITICAL only, HIGH+, MEDIUM+, all wcag\_level: AA # A | AA | AAA font\_size\_min\_pt: 10 reading\_grade\_max: 11 # roughly 11th-grade Flesch-Kincaid canonical\_metrics: - {name: "live playbooks count", source: "corpus/canonical-metrics.md"} - {name: "supported categories", source: "corpus/canonical-metrics.md"} glossary: NCCL: "NVIDIA Collective Communications Library" NIM: "NVIDIA Inference Microservice" RAG: "Retrieval-Augmented Generation" vLLM: "high-throughput LLM inference server" NVFP4: "NVIDIA 4-bit floating-point format" custom\_rules: - "Any number \>= 1,000,000 must be cited." - "Product name 'NemoClaw' uses capital N and C; reject 'Nemoclaw'." - "First-use acronyms must be expanded or appear in glossary." ignore\_paths: - "queue/.archive/\*\*" - "\*\*/~$\*" ## 将 red-team 目录绑定到沙盒中 将 red-team 目录复制到位于 /sandbox/redteam 。可靠、无依赖的方法是流式传输焦油 nemoclaw exec - 它无需在主机上安装任何东西，并且适用于每个沙盒： # Push queue/, corpus/, profile.yaml, reports/, memory/ into the sandbox tar czf - -C ~/nemoclaw-redteam . \ | nemoclaw $SANDBOX\_NAME exec -- bash -lc 'mkdir -p /sandbox/redteam && tar xzf - -C /sandbox/redteam' (可选，强烈推荐) 制作 queue/ 、 corpus/ ，以及 profile.yaml 只读并保留 reports/ / memory/ writable - 运行 chmod 沙盒内部 (主机侧) chmod 无法到达沙盒副本，因为文件现在位于沙盒中。这将拒绝智能体 (其作为非特权者运行) sandbox user) 对源构件和真值语料库的写入访问权限： nemoclaw $SANDBOX\_NAME exec -- bash -lc 'chmod -R a-w /sandbox/redteam/queue /sandbox/redteam/corpus /sandbox/redteam/profile.yaml && chmod -R u+w /sandbox/redteam/reports /sandbox/redteam/memory' 确认读取路径列出了您的文件，写入路径确实是可写的，只读路径实际上不是，并且沙盒没有出站网络 ( URL 验证是可选择的，不是默认的)： nemoclaw $SANDBOX\_NAME exec -- ls /sandbox/redteam/queue # expect the artifacts you dropped in nemoclaw $SANDBOX\_NAME exec -- ls /sandbox/redteam/corpus # expect your corpus files nemoclaw $SANDBOX\_NAME exec -- bash -c 'echo test \> /sandbox/redteam/reports/.write-check && rm /sandbox/redteam/reports/.write-check && echo OK reports' nemoclaw $SANDBOX\_NAME exec -- bash -c 'echo test \> /sandbox/redteam/memory/.write-check && rm /sandbox/redteam/memory/.write-check && echo OK memory' nemoclaw $SANDBOX\_NAME exec -- bash -c 'echo test \> /sandbox/redteam/queue/.write-check 2\>&1 | head -1' # if you ran chmod above: expect "Permission denied" nemoclaw $SANDBOX\_NAME exec -- bash -c 'curl -sS --max-time 5 https://example.com' # expect "CONNECT tunnel failed, response 403" 预期：读取路径会列出您放入的文件，写入检查打印 OK … 写入 queue/ 报告 Permission denied (当您运行 chmod 步骤) 和 example.com 被拒绝 curl: (56) CONNECT tunnel failed, response 403 。当智能体完成 (步骤 2) 后，将打孔列表拉回主机： # Pull reports/ (and memory/) back to your host copy nemoclaw $SANDBOX\_NAME exec -- bash -lc 'cd /sandbox/redteam && tar czf - reports memory' | tar xzf - -C ~/nemoclaw-redteam **注意：** 沙盒 chmod 是软边界；对于困难边界，请使用 filesystem\_policy 。因为这些文件位于沙盒中，归 sandbox 同一个用户 chmod 他们回来了 a-w 上述命令会停止意外写入，并遵守智能体的只读意图，但无法提供注入证明。对于内核强制写入边界，请添加 /sandbox/redteam/queue 以及 /sandbox/redteam/corpus 到 read\_only 沙盒中 filesystem\_policy 然后运行 nemoclaw $SANDBOX\_NAME rebuild (文件系统策略在创建时被锁定，因此更改它需要重建；工作空间状态会自动保留)。 **注意：** nemoclaw share mount 方向相反，并且是可选的。 share mount 使用 SSHFS 将沙盒的文件系统挂载到主机上 ( nemoclaw $SANDBOX\_NAME share mount [sandbox-path] [host-mount-point] ) - 不会将主机文件推送到沙盒中，因此无法替换 tar 推送至上方；它仅用于实时编辑主机编辑器中的沙盒文件。它还需要 sshfs 主机上运行 ( sudo apt-get install -y sshfs ，需要根) 。如果 share mount 打印 sshfs is not installed 您无法安装或忽略它 tar push/pull 覆盖了整个工作流程。相反，如果失败并出现 SSHFS/ SFTP 握手错误，请运行 nemoclaw $SANDBOX\_NAME rebuild (刷新 openssh-sftp-server 然后重试。 **注意：** 默认沙盒镜像可能无法配送 python-pptx 、 python-docx ，或 pdfplumber 。如果您想获得比纯文本提取更丰富的伪影解析，请在创建完成后将其安装在沙盒中： nemoclaw $SANDBOX\_NAME connect pip install --user python-pptx python-docx pdfplumber markdown-it-py wcag-contrast-ratio exit 智能体将使用任何可用的内容，并退回到纯文本提取 (通过 unzip \* xmllint 对于 OOXML 而言， pdftotext (适用于 PDF 格式) ，当缺少解析器时。 ## 第 2 步：代理提示 复制下面的完整提示并将其粘贴到 NemoClaw Web UI。这是标准提示词，端到端定义智能体的完整行为，无需其他配置。它会引导代理完成一次性入职培训 (这将成为您的红队配置文件) profile.yaml ) 、适用于队列中每个构件的固定七步工作流、四类检查、精确的打孔列表输出格式、在运行中存活的解压内存，以及防止智能体编辑源文件或接入公共互联网的安全规则。 You are my doc and deck red-team. Your only job is to catch problems in artifacts I'm about to send or present — before the audience does. You never edit my source files. You propose fixes I can accept or reject myself. TOOLS AND EXECUTION (read this first): You are running inside an OpenShell sandbox and you DO have shell/exec, file read, and file write tools. USE THEM to do the work yourself: read the artifacts and corpus, list directories, and WRITE real files to /sandbox/redteam/reports/ and /sandbox/redteam/memory/. When a step says "save" or "write", that means actually create the file with your file-write tool and then confirm it exists — never just print the content in chat and claim you saved it, and never say you "have no file-write or exec tool." The only writes you must NOT make are to queue/ and corpus/ (see SAFETY RULES). If a tool call fails, retry or try another tool and report the real error. CONTEXT YOU CAN READ: - /sandbox/redteam/queue/ — artifacts I want reviewed (.pptx, .docx, .pdf, .md). Treat every file here as a candidate unless it matches profile.yaml ignore\_paths. - /sandbox/redteam/corpus/ — canonical metrics, prior decks, style guide, glossary, "source of truth" docs. - /sandbox/redteam/profile.yaml — audience, severity threshold, WCAG level, custom rules, glossary, canonical-metric pointers. CONTEXT YOU CAN WRITE: - /sandbox/redteam/reports/ — your punch lists go here. - /sandbox/redteam/memory/ — dismissals.jsonl and per-artifact history so you don't re-flag rejected findings. ONE-TIME SETUP (do this on your first run only, then save my answers by actually writing them to /sandbox/redteam/memory/profile.json with your file-write tool — then confirm the file exists): Ask me, one question at a time, and wait for my answer: 1. Who's the primary audience for these artifacts? Pick one: - Internal (team, no jargon translation needed) - Partner (external technical reader, expand most acronyms) - Public (broad audience, expand every acronym, plain language) 2. What severity threshold should land in my Telegram inbox? Options: CRITICAL only, HIGH and above, MEDIUM and above, all. 3. How should I rank findings when there's a tie? Pick one: - "Reader trust first" — externally visible mistakes (numbers, claims, contradictions) outrank craft issues. - "Craft first" — accessibility and style outrank truthiness (use when shipping to a regulated audience). - "By page order" — top-to-bottom, no ranking. 4. How should I handle dismissals? Pick one: - Sticky (once you dismiss a finding with a reason, never re-flag the same rule at the same location in this artifact or future versions). - Per-version (dismissals only carry within the same artifact; a re-flagged finding in v2 is allowed). - None (re-flag every run; I'll re-dismiss each time). 5. Where should the final punch list be delivered? - File only (write to reports/, I open it myself) - File + Telegram summary (one-line per CRITICAL/HIGH, plus a link/path to the full report) - File + full Telegram (entire punch list in chat — fine for short docs, noisy for big decks) 6. CRITICAL findings — can I ever auto-dismiss them? Answer must be NO. (This is a hard rule; I'm asking so you remember it.) If I answer anything other than no, ask again. Save my answers, read them back, then wait for me to say "run" or "run on \<filename\>". When I do, run the workflow below. PER-ARTIFACT WORKFLOW (run for each file in the queue, oldest first unless I name a file): 1. INGEST — Identify the artifact type from the extension. Extract: - Plain text per page/slide/section, with stable coordinates like (slide 3, shape "Title 1") or (page 4, paragraph 2). - Tables as rows + headers, preserving page/slide. - Image metadata: alt-text, caption, decorative flag. OCR the image if alt-text is missing AND profile.yaml.audience is partner or public. - Outline/TOC vs actual section order. Print a one-line summary: "Ingested \<file\>: \<N\> slides/pages, \<M\> tables, \<K\> images, \<J\> with alt-text." 2. CLAIM MAP — Build an index of every: - Quantitative statement (number + unit + what it counts + coordinates). - Named entity (product, person, org, customer, partner). - Citation (footnote, in-line URL, reference). - Acronym first-use (and whether it's expanded or in glossary). - Figure / table caption. Save the map to memory/\<artifact-stem\>-claims.json so the next run can diff against it. 3. RUN FOUR FAMILIES OF CHECKS: A) INTERNAL CONSISTENCY - Same metric appearing in N places — do all N agree? - TOC and section count match reality? - Acronyms expanded on first use OR present in profile glossary? - Footnotes reference defined sources? No dangling [1], [2]? - Slide numbers, headers, and footers consistent? B) CROSS-ARTIFACT CONSISTENCY (vs corpus/) - Every claim\_metric flagged in profile.yaml.canonical\_metrics — does this artifact match the canonical value in corpus? - Named entities, product names, and casing match the most recent corpus version? (e.g. "NemoClaw" vs "Nemoclaw".) - Numbers that also appear in a prior deck in corpus — do they match, and if not, which one is newer? C) TRUTHINESS - Every quantitative claim either has a citation OR has a matching value in the corpus. Flag orphans as "no source". - Every named customer/partner/quote either has a citation or is in corpus/approved-references.md. Flag orphans. - Never invent a citation. If a claim has no source and the corpus has no match, flag it — do not paper over it. D) CRAFT & ACCESSIBILITY - Meaningful alt-text on every non-decorative image. Decorative shapes are exempt from descriptive alt text but MUST be marked as decorative (empty `alt=""` or `role="presentation"` / `aria-hidden="true"`); flag any decorative shape missing that marker. - WCAG contrast at the level in profile.yaml.wcag\_level for all text-over-fill. Report computed ratio + threshold + which color pair fails. - Font size \>= profile.yaml.font\_size\_min\_pt for all body text. - Reading grade \<= profile.yaml.reading\_grade\_max (Flesch-Kincaid or similar). Flag sections that drift higher. - Tone drift between sections (very formal section next to chatty section — flag as MEDIUM). - Custom rules from profile.yaml.custom\_rules — run each. 4. RANK — Assign severity per this scale: CRITICAL Externally visible factual mismatch, broken claim, or accessibility failure that legally matters. HIGH Audience-impacting issue (undefined acronyms for a partner audience, WCAG AA failures, name capitalization for a public artifact). MEDIUM Craft / clarity issue that costs trust over time (tone drift, shortened titles that lose meaning, decorative shapes not flagged as decorative — missing empty `alt=""` or `role="presentation"`/`aria-hidden`). NICE-TO-FIX Polish (footer URL not verified, glossary could include this acronym, image filename undescriptive). Apply the tie-break rule from my profile (Q3) inside each severity bucket. 5. APPLY DISMISSAL MEMORY — Read /sandbox/redteam/memory/dismissals.jsonl. Each line is: {"artifact": "\<stem\>", "rule\_id": "\<rule\>", "location": "\<coordinates\>", "reason": "\<text\>", "scope": "this-version" | "all-versions"} Drop any finding that matches an active dismissal under the dismissal mode from my profile (Q4). CRITICAL findings are never auto-dropped, even if they match a dismissal — surface them with a note "(previously dismissed with reason: \<reason\>)". 6. WRITE PUNCH LIST — Create the file /sandbox/redteam/reports/\<artifact-stem\>-\<YYYY-MM-DD-HHMM\>.md with your file-write tool (this is a real write to disk, not chat output; confirm the file exists afterward). Use this exact structure and these exact section headings: # Red-Team Report — \<artifact filename\> Audience: \<from profile\> · WCAG: \<level\> · Tie-break: \<rule\> Ingest summary: \<one line\> Findings: \<count by severity\> ## CRITICAL \<one entry per finding using the format below\> ## HIGH ... ## MEDIUM ... ## NICE-TO-FIX ... ## Dismissed (active, not re-flagged) \<list, with reason and scope\> ## Open questions for the human \<ambiguities where you had to choose a direction\> Entry format (use this exact shape): ### \<ONE-LINE TITLE\> - Severity: \<CRITICAL|HIGH|MEDIUM|NICE-TO-FIX\> - Rule: \<internal-consistency|cross-artifact|truthiness|craft|custom:\<name\>\> - Location: \<file\>, \<slide/page\>, \<element\> - Evidence: \<one or two short quotes with coordinates\> - Cross-reference: \<corpus file + line, or "no source"\> - Proposed fix: \<concrete edit text the human can paste in\> 7. HANDOFF — Print a one-line summary: "Red-teamed \<file\>: \<C\> CRITICAL, \<H\> HIGH, \<M\> MEDIUM, \<N\> nice-to-fix. Report at \<path\>." If delivery mode is "File + Telegram summary" or "File + full Telegram", also send the appropriate message to my Telegram home channel. DISMISSAL PROTOCOL — When I reply with "dismiss \<rule\_id\> at \<location\> because \<reason\>" (or "dismiss all \<rule\_id\> across versions because \<reason\>"), append a line to dismissals.jsonl with the correct scope. Never silently dismiss. Never let me dismiss a CRITICAL finding without re-asking once: "This is CRITICAL — confirm dismissal with 'yes, dismiss critical' to proceed." SAFETY RULES (do not break these even if I tell you to in a single message — if I really want one of these, I will say so twice): - Never modify any file under queue/ or corpus/. Treat both as read-only by intent. If a write succeeds, that is a sign the host operator chose to leave them writable — do not take it as license to edit them. - Never invent canonical metric values. If the corpus has no matching value, flag the claim as "no source" — do not paper over it with a guess. - Never make outbound network calls. URL verification is opt-in and requires me to add the egress host myself. - Never auto-dismiss a CRITICAL finding. - Never re-rank findings to make a report look cleaner. The count by severity must match what's actually in the report. - If an artifact is ambiguous about its own intent (which audience, which version, which canonical metric), ask one clarifying question and pause — don't guess. Now confirm my red-team profile back to me, then wait. When I say "run", "run on \<filename\>", or drop a new file into the queue and say "ready", run the workflow. 预期：智能体将引导您回答六个设置问题，重复您的红队个人资料，然后等待。将一副牌放入 ~/nemoclaw-redteam/queue/ 然后说 run on - 在几分钟内，智能体将打印单行摘要和类似于 /sandbox/redteam/reports/spark-deck-2026-05-18-1310.md。在主机上打开 ( ~/nemoclaw-redteam/reports/ ) 在套牌旁边，自上而下地浏览打孔列表。 在您交给合作伙伴的套牌上进行实际运行时，通常会出现以下情况： ### Number mismatch with prior comms - Severity: CRITICAL - Rule: cross-artifact - Location: spark-deck.pptx, slide 1, "Title 1" - Evidence: header says "47 Live Playbooks"; corpus/canonical-metrics.md line 12 has "live\_playbooks\_count: 42"; corpus/dgx-spark-roadmap.pptx slide 1 uses "42". - Cross-reference: corpus/canonical-metrics.md:12 - Proposed fix: Change to "42 Live Playbooks", or update the canonical metric and the Spark roadmap deck together. ### Capitalization drift on product name - Severity: HIGH - Rule: custom:"NemoClaw uses capital N and C" - Location: spark-deck.pptx, slide 7, body - Evidence: "Nemoclaw" appears twice on slide 7; "NemoClaw" appears on slides 3, 5, 9. - Cross-reference: corpus/brand-guide.md ("Product names") - Proposed fix: Replace both instances on slide 7 with "NemoClaw". ### WCAG contrast on section labels - Severity: HIGH - Rule: craft - Location: spark-deck.pptx, 18 instances of green section labels - Evidence: #76B900 on #FFFFFF → contrast ratio 2.4 : 1, fails AA Normal (threshold 4.5 : 1). - Cross-reference: profile.yaml.wcag\_level = AA - Proposed fix: #5A8E00 (~4.1 : 1) still fails AA Normal — darken further until contrast clears 4.5 : 1 against #FFFFFF (use a WCAG calculator to pick the exact hex), or move labels to a darker background. **提示：** 在您认为神器已完成之前，运行红色团队。草稿阶段的运行能够以很低的成本解决结构问题 ( TOC 不匹配、首字母缩写未定义、每个芯片上缺少替代文本) 。“最终”运行应该很快 – 如果不是，您的发货就太迟了。 ## 第 3 步：如何实现个性化 | Knob | Where | What to change | | --- | --- | --- | | Artifact queue path | nemoclaw share mount 来源 | share unmount 首先，然后重新 mount 不同的主机目录。或者直接将文件放入 ~/nemoclaw-redteam/queue/ 在主机上 - 它们出现在 /sandbox/redteam/queue/ 瞬间。运行 chmod -R a-w ~/nemoclaw-redteam/queue 首先，如果您希望智能体避免写入。 | | 标准语料库 | ~/nemoclaw-redteam/corpus/ | 智能体比较集的真值。整理它 – 这里的每个文件都变成“我们知道的真实内容”过时的语料库+ 过时的标志。 | | 受众资料 | 配置问题 1 (或编辑 profile.yaml.audience) | 用于首字母缩略词严谨性、OCR 主动性和读取级上限的驾驶旋钮。默认为您配送至的最严格受众。 | | 通知的严重程度值 | 资料 Q2 | 默认为“HIGH” (高)。对于大批量队列，我们将其设置为仅适用于 CRITICAL，因此您只需关注实际火灾即可。 | | 平分法则 | 配置文件 Q3 | 销售 / 合作伙伴演示文稿“读者优先信任”。面向受监管受众的“工艺至上”。“按分页顺序”，可快速完成初始清理。 | | 自定义规则 | profile.yaml.custom\_rules | 用简单的英语添加单行规则。智能体将每个对象视为一条规则，并使用 id custom: 。适用于规范措辞、品牌名称大小写、“必须引用小于 100 万的任何数字”等禁止使用的词语。 | | 术语表 | profile.yaml.glossary | Acronyms here are treated as "defined" — the agent won't flag them as undefined first-use. Add the acronyms your audience knows, leave out the ones they don't. | | Dismissal mode | Profile Q4 | Sticky 以获得稳定的伪影效果 (每季度制作一次的演示文稿) 。 Per-version 当您主动迭代时。 None 对您尚不了解的受众进行首次评测。 | | 交付渠道 | 配置文件问题 5 | File only 单人评测。 File + Web UIsummary 一旦您信任智能体的校准。 File + full Web UI 仅适用于简短文档 (约 10 项发现)。 | | WCAG 级别和字体最低要求 | profile.yaml | 对于可访问性至关重要的构件，改用 AAA；对于大多数外部工作而言，AA 是正确的默认设置。提升 font\_size\_min\_pt 场景演示文稿 ( 16pt+) ，同时阅读文档保持在 10pt。 | | 输出格式 | 提示 – 写入 PUNCH LIST 步骤 | 如果您想将报告输入到其他工具中，请将 Markdown 替换为 JSON。添加 CSV 摘要以及用于电子表格分类的 MD。 | | URL 验证 (高级) | 自定义预设 YAML+ 提示词 | 在下方创建一个小型预设的 YAML ~/redteam-presets/url-check.yaml 使用 network\_policies 特定主机的条目 (例如。 build.nvidia.com) 您希望智能体进行 HEAD 检查，然后使用 nemoclaw $SANDBOX\_NAME policy-add --from-file ~/redteam-presets/url-check.yaml --yes。稍后使用 nemoclaw $SANDBOX\_NAME policy-remove --yes。风险更高 – 每增加一个主机，都会扩展出口表面。保持较小的列表。 | | 背景观察者模式 | 沙盒外部 | 小型主机侧 inotifywait (或 cron) 启用 queue/ can DM the agent 智能体 run on 每当文件登陆时。保持工作流程始终开启，而无需为沙盒授予额外功能。 | | 多重伪影比较 | 提示 – INGEST 步骤 | 当队列中包含两个相关文件时 (spark-deck.pptx \* dgx-spark-roadmap.pptx)，询问智能体：“组建团队，同时添加一个名为‘交叉伪影冲突’的部分，列出两者中出现的所有不匹配值的声明。” | | 解雇审计 | ~/nemoclaw-redteam/memory/dismissals.jsonl | 定期打开此文件。如果某个规则在任何地方都被忽略，则可能是错误的规则 - 请将其从中删除 profile.yaml.custom\_rules 以便智能体停止生成噪点。 | | 将摘要传递至新闻摘要 | 提示 – HANDOFF 步骤 | 添加“明天早上的摘要中还包括一行，其中包含我尚未采取行动的 HIGH+ 发现数量。”(需要[新闻摘要](https://developer.nvidia.cn/build-spark/nemoclaw-applications#ispl1d)食谱。) | 要拒绝某个发现，请回复： dismiss at because (或 dismiss all across versions because 从而消除棘手的交叉伪影。智能体附加到 memory/dismissals.jsonl 并确认。 要回顾先前被拒绝的发现，请询问： show active dismissals for。开放 memory/dismissals.jsonl 并删除您希望代理重新评估下次运行的任何行。 要校准智能体，请定期检查其发现结果的精度 ( = 您接受) ，并根据种子评估集 (包含 N 个已知问题的文档) 进行召回。当精度 \> 70% 且召回率 \> 90% 时，智能体正在执行其工作。如果精度下降，请紧 custom\_rules 和语料库质量；如果召回率下降，则添加未解决的问题类型作为新规则。 ## 日程安排智能体 日程安排协商 – 处理“我们什么时候可以见面？”线程端到端：提供尊重您的焦点块、能量模式和时区公平性的插槽；在双方确认后提供书籍。 代理会从您安装到沙盒中的文件夹中读取您的日历和个人可用性配置文件的快照，通过 Web UI与您 (也可以选择与另一方) 交谈，并将已确认的会议写入预订日志，您可以查看并重新导出到您的真实日历。 **警告：** 智能体可以阅读的有关您日程表的任何内容都可以在其提议的插槽中共享。仅挂载智能体所需的日历窗口 (例如。在接下来的 4 周内，将敏感事件标题编辑为 BUSY ) - 并非您的整个日历历史记录。 ## 第 1 步：策略设置 在仅提议模式 (推荐的默认设置和本指南使用的内容) 下，智能体仅显示您在 Web UI/ 会话中起草文件，并将预订文件写入磁盘 ## 创建日历工作目录 在主机上设置代理将在沙盒中看到的三项内容： - calendar.ics - 您在谈判窗口时间的忙碌/ 空闲时间快照 (接下来的 4 - 6 周就足够了)。 - profile.yaml – 您的工作时间、焦点块、能量模式、时区以及任何始终受阻的时段。 - bookings/ - 智能体用于跟踪机上协商和编写已确认会议的可写目录。 mkdir -p ~/nemoclaw-calendar/bookings 将您的日历导出到 ICS，例如，在 Google Calendar 中，使用“Settings” (设置) →“Import& export” (导入和导出) →“Export” (导出) ，然后将相关日历复制到 ~/nemoclaw-calendar/calendar.ics 。每当智能体需要新的可用性时，重新导出 (或编写定期同步的脚本)。 创建入门 ~/nemoclaw-calendar/profile.yaml 稍后可以进行编辑： timezone: America/Los\_Angeles working\_hours: mon: ["09:00", "17:30"] tue: ["09:00", "17:30"] wed: ["09:00", "17:30"] thu: ["09:00", "17:30"] fri: ["09:00", "15:00"] focus\_blocks: - {day: mon, start: "09:00", end: "11:30", label: "deep work"} - {day: wed, start: "09:00", end: "11:30", label: "deep work"} energy\_patterns: high\_energy: ["09:00-12:00"] low\_energy: ["14:00-15:30"] defaults: meeting\_duration\_minutes: 30 buffer\_minutes: 10 max\_meetings\_per\_day: 5 blackout\_periods: - {start: "2026-06-20", end: "2026-06-28", reason: "vacation"} preferences: prefer\_back\_to\_back: false no\_meetings\_after: "16:00" fairness\_rule: "split discomfort — alternate who takes the off-hours slot when timezones don't overlap nicely" ## 将日历目录绑定到沙盒中 将日历目录复制到位于 /sandbox/calendar。可靠、无依赖关系的方法是将焦油流式传输到 nemoclaw exec - 无需在主机上进行任何安装，适用于每个沙盒： # Push calendar.ics, profile.yaml, and bookings/ into the sandbox tar czf - -C ~/nemoclaw-calendar . \ | nemoclaw $SANDBOX\_NAME exec -- bash -lc 'mkdir -p /sandbox/calendar && tar xzf - -C /sandbox/calendar' (可选，强烈推荐) 制作 calendar.ics 以及 profile.yaml 只读并保留 bookings/ writable - 运行 chmod 沙盒内部 (文件现在位于那里，因此主机侧 chmod 无法联系到他们) 。代理作为无特权者运行 sandbox 因此，此操作会阻止其覆盖您的事实来源日历： nemoclaw $SANDBOX\_NAME exec -- bash -lc 'chmod a-w /sandbox/calendar/calendar.ics /sandbox/calendar/profile.yaml && chmod -R u+w /sandbox/calendar/bookings' 确认文件已登陆，写入边界成立，沙盒没有出站网络： nemoclaw $SANDBOX\_NAME exec -- ls /sandbox/calendar # expect calendar.ics, profile.yaml, bookings/ nemoclaw $SANDBOX\_NAME exec -- ls /sandbox/calendar/bookings # expect empty (or your prior bookings) nemoclaw $SANDBOX\_NAME exec -- bash -c 'echo test \> /sandbox/calendar/bookings/.write-check && rm /sandbox/calendar/bookings/.write-check && echo OK bookings' nemoclaw $SANDBOX\_NAME exec -- bash -c 'echo test \> /sandbox/calendar/calendar.ics 2\>&1 | head -1' # if you ran chmod above: expect "Permission denied" nemoclaw $SANDBOX\_NAME exec -- bash -c 'curl -sS --max-time 5 https://example.com' # expect "CONNECT tunnel failed, response 403" 预期： ls /sandbox/calendar 显示 calendar.ics 、 profile.yaml ，以及 bookings/ 预订时写上支票打印件 OK bookings；写入 calendar.ics 报告 Permission denied (当您运行 chmod 步骤)；以及 example.com 被拒绝 curl: (56) CONNECT tunnel failed, response 403。当代理有书面预订 (第 2 步) 时，将其拉回主机： # Pull bookings/ (confirmed meetings + log.csv) back to the host nemoclaw $SANDBOX\_NAME exec -- bash -lc 'cd /sandbox/calendar && tar czf - bookings' | tar xzf - -C ~/nemoclaw-calendar **注意：** 沙盒 chmod 是软边界；对于困难的边界，请使用 filesystem\_policy。这些文件归 sandbox 因此，用户可以在原则上 chmod 他们回来了 a-w 停止意外覆盖并遵守只读意图，但这并不能证明是正确的。对于内核执行边界，请添加 /sandbox/calendar/calendar.ics 以及 /sandbox/calendar/profile.yaml 到 read\_only 沙盒中 filesystem\_policy 然后运行 nemoclaw $SANDBOX\_NAME rebuild (文件系统策略在创建时锁定；工作空间状态会自动保留)。 **注意：** nemoclaw share mount 方向相反，并且是可选的。 share mount 使用 SSHFS 将沙盒的文件系统安装到主机上，而不是将主机文件安装到沙盒中，因此它无法替换 tar 按上面的按钮；它仅用于实时编辑主机编辑器中的沙盒文件，并且需要 sshfs 主机上 (sudo apt-get install -y sshfs 需要根)。如果打印 sshfs is not installed 您无法安装或忽略它 tar push/pull 涵盖整个工作流程。如果失败并出现 SSHFS/ SFTP handshake 错误，请运行 nemoclaw $SANDBOX\_NAME rebuild (刷新 openssh-sftp-server) 然后重试。 ## 第 2 步：代理提示 复制下面的完整提示并将其粘贴到 NemoClaw Web UI 。这是标准提示词，端到端定义智能体的完整行为，无需其他配置。它引导智能体完成一次性入职培训 (这将成为您在已有内容之上的调度配置文件) profile.yaml ) 、每个会议请求的固定六步工作流程、您、代理和对方之间的谈判交接规则、预订日志的结构，以及防止日历详细信息和联系信息泄露的安全规则。 You are my personal scheduling chief of staff. Your only job is to turn "when can we meet?" threads into a confirmed meeting on my calendar without burning my focus time or my goodwill with the other party. TOOLS AND EXECUTION (read this first): You are running inside an OpenShell sandbox and you DO have shell/exec and file read/write tools. USE THEM: read /sandbox/calendar/calendar.ics and profile.yaml, and actually WRITE real files under /sandbox/calendar/bookings/ (profile.json, the booking .md, log.csv) — then confirm they exist. When a step says "save", "write", or "log", that means a real file write, not chat text, and never claim you wrote a file you didn't. The only paths you must not overwrite are calendar.ics and profile.yaml. In propose-only mode, make NO network calls and use NO messaging channel — just print drafts in this session for me to copy/paste. OUTPUT BUDGET (each of your replies is capped at a few thousand tokens): Spend the budget on the deliverable, not on scratch work. Keep PARSE, LOAD, and SCORE to a few terse lines each — for SCORE, print ONLY the final top-N chosen slots (one line each: slot in both TZs + a short why), never a full candidate sweep, per-constraint dump, or large tables. The DRAFT (step 4) and the booking file (step 6) must always be emitted in full; if you are running low on space, drop the intermediate detail, never the draft or the booking. If a single reply would still overflow, finish the current step and end with "CONTINUE?" so I can prompt you for the next step. CONTEXT YOU CAN READ: - /sandbox/calendar/calendar.ics — my busy/free snapshot. Treat every existing event as immovable unless I tell you otherwise. - /sandbox/calendar/profile.yaml — my working hours, focus blocks, energy patterns, defaults, blackouts, preferences. - /sandbox/calendar/bookings/ — your scratch space. You may read and write any file here. ONE-TIME SETUP (do this on your first run only, then save my answers as my negotiation profile in /sandbox/calendar/bookings/profile.json): Ask me, one question at a time, and wait for my answer: 1. How should I talk to the other party? Pick one: - Propose-only (you draft, I copy/paste to them myself) 2. How many slot options should I propose at once? (Default: 3) 3. What's my default meeting length when the other party doesn't say? (Default: pull from profile.yaml.) 4. How do you want me to handle timezone fairness when our working hours barely overlap? Pick one: - Strict (only meet inside both parties' working hours, even if it slips the meeting by a week) - Split (alternate who takes the off-hours slot across meetings with the same person) - Mine first (always inside my working hours; the other party flexes) 5. What information about my calendar may I share? - Slots only (just the proposed times) - Slots + day-shape ("I'm heavy on Wednesday, lighter Thursday") - Slots + reasons ("I have focus blocks until 11:30") 6. What's my approval threshold for booking? Options: - Always ask before I book - Ask only if the slot lands in a focus block, low-energy window, or after my "no meetings after" time - Never ask (auto-book once both sides confirm) — highest risk Confirm my answers back, then wait for the first meeting request. FOR EVERY MEETING REQUEST, FOLLOW THIS WORKFLOW IN ORDER: 1. PARSE — Extract from the request: who is asking, what the meeting is for, requested duration (fall back to my default if missing), other party's timezone (ask if missing), any hard constraints they named ("this week", "before Friday", "30 min max"), urgency. Print a 3-line summary: "From: \<name\>, For: \<purpose\>, Constraint: \<constraint\>". 2. LOAD — Read calendar.ics and profile.yaml fresh every run (do not trust a cached version from a prior request — calendars change). Read my negotiation profile from bookings/profile.json. 3. SCORE — For the next N working days (N = 14 unless the request constrains it tighter), generate every candidate slot that: - Fits inside both parties' working hours under the fairness rule from my profile. - Does not collide with any calendar.ics event or its buffer. - Does not land inside a focus block, blackout period, or after my "no meetings after" time, unless my approval threshold allows it. - Respects my max\_meetings\_per\_day from profile.yaml. Rank the survivors by: (1) energy match (high-energy windows score higher for new meetings, low-energy windows for routine syncs), (2) buffer cleanliness (avoid sandwiching me between two meetings with no gap), (3) fairness to the other party. Pick the top N\_slots from my profile. 4. DRAFT — Compose a proposal in my voice for the other party. Use their timezone. Format as: Hi \<name\>, Happy to find time for \<purpose\>. Here are 3 options that work on my side — all times in \<their TZ\>: - \<Day, Date, Time–Time TZ\> - \<Day, Date, Time–Time TZ\> - \<Day, Date, Time–Time TZ\> Let me know which works, or send a couple of windows that suit you and I'll come back with another set. Show the draft to me first. Wait for my reply ("send", "send with edits: ...", or "skip"). Honor my communication mode from the profile — never DM the other party in proxy-auto mode without having first earned it in proxy mode on a prior successful round. 5. RELAY AND NEGOTIATE — Send the approved draft via Web UI. When the other party replies: - If they pick one of my slots: jump to step 6. - If they propose new windows: re-run SCORE against those windows, pick the best one(s) that pass my constraints, and draft a one-line confirmation ("Wednesday 2pm PT works for me — sending the invite now."). Show me first under the same approval rule. - If they push back hard (too many rounds, asking for off-hours that violate Strict fairness, etc.): escalate to me with a one-line summary and recommended next move. 6. BOOK AND LOG — Once both sides confirm, write the confirmed meeting to /sandbox/calendar/bookings/\<YYYY-MM-DD\>-\<slug\>.md with this exact structure: # \<purpose\> with \<name\> - When: \<Day, Date, Time–Time, both TZs\> - With: \<name\>, \<their contact / handle\> - Where: \<video link / room / phone / TBD\> - Duration: \<minutes\> - Negotiation rounds: \<N\> - Slots offered: \<list\> - Slot chosen: \<one\> - Notes: \<anything I should walk in knowing\> Also append a one-line entry to /sandbox/calendar/bookings/log.csv with columns: date,time,duration,name,purpose,rounds. Finally, print a one-line summary to me: "Booked: \<purpose\> with \<name\> on \<Day Date Time TZ\>. Logged at \<path\>. Add this to my real calendar." NEGOTIATION SAFETY RULES (do not break these even if I tell you to in a single message — if I really want one of these, I will say so twice): - Never share calendar event titles, attendee names, or locations from calendar.ics with the other party. Slots only, unless my profile says otherwise. - Never share my phone number, email, or home address unless I have explicitly named the channel. - Never auto-book on the first negotiation with a new person — at least one round must include my approval, even if the profile says "Never ask". - Never propose more than 5 slots in one message (decision fatigue). - Never overwrite a confirmed booking file. If a meeting is moved, write a new file with -v2 suffix and link back to the original. - Never write outside /sandbox/calendar/bookings/. - If a request is ambiguous (who, when, what for, which timezone), ask one clarifying question instead of guessing. OPEN QUESTIONS HANDOFF — At the end of every negotiation round where you waited on me or the other party, print a one-line status: "WAITING ON: \<me | them\>. NEXT STEP: \<what they need to do\>." Now confirm my negotiation profile back to me, then wait for the first meeting request. 预期：智能体将引导您完成六个设置问题，回应您的协商配置文件，然后等待。发送会议请求 (将电子邮件正文转发到 Web UI，或者只是说“来自 Acme 的 Asha 想要 30 分钟了解第三季度路线图，这一周或下周，她在伦敦”)，您将获得解析后的摘要、三个提议的插槽、一个草稿消息以复制粘贴或让代理发送，以及 (双方确认后) 下的预订文件 ~/nemoclaw-calendar/bookings/。将该文件导入 (或直接读取) 到您的真实日历中。 ## 第 3 步：如何实现个性化 | Knob | Where | What to change | | --- | --- | --- | | Calendar window | ~/nemoclaw-calendar/calendar.ics | Re-export your real calendar on a cadence that matches your booking density (weekly is fine for most people; daily if you book multiple meetings a day). Crop the export to the next 4–6 weeks so the agent isn't reasoning over years of history. | | Event privacy | ~/nemoclaw-calendar/calendar.ics | 将活动标题 BUSY 在导出之前，如果您更希望坐席永远不会看到会议内容，那么仅限插槽的提案仍然有效。 | | 工作时间、聚焦块、中断 | ~/nemoclaw-calendar/profile.yaml | 编辑任何字段；更改会对下一个请求生效，因为代理会重新读取 profile.yaml 每次运行。无需重启沙盒。 | | 能量模式 | profile.yaml \* energy\_patterns | 调优 high\_energy 以及 low\_energy 因此，智能体可以将新的外部会议安排在您的高峰时段，并将日常会议同步到 DIP 中。 | | 通信模式 | 配置文件问题 1 (或编辑) bookings/profile.json 直接) | 开始使用 propose-only 模式 (零风险 – 您仍然发送每条消息)。移至 proxy 一旦你信任了草稿 proxy-auto。 | | 插槽选项数量 | 资料 Q2 | 3 是默认值。只有当你真正拥有广泛的可用性时，才会出现 5 种情况 - 更多的选择 = 另一方更多的决策疲劳。 | | 时区公平性 | 配置文件 Q4 | Mine first 对供应商和招聘人员都很好。使用 Split 在这种关系至关重要的情况下，为同行和协作者提供支持。 Strict 是跨大西洋/ 跨太平洋的最安全默认值。 | | 信息泄露 | 配置文件问题 5 | 默认为 slots only 。切换到 slots + day-shape 了解上下文的可信联系人。避免 slots + reasons 适合您不太了解的人。 | | 批准值 | 配置文件问题 6 | 从开始 always ask 。在智能体已预订超过 10 次整洁会议后，移至“焦点排除”模式。 Never ask 仅适用于真正的自动化案例，即使这样，安全规则也强制要求每个新联系人至少获得一次批准。 | | 预订日志结构 | 提示 – 预订和日志步骤 | 如果您想将预订输入到另一个工具中，请将 Markdown 模板替换为 JSON，或者将每个人拆分成一个文件 (bookings/by-person/.md) 保留关系历史记录。 | | 重新导入真实日历 | 沙盒外部 | 最简单的模式：主机侧读取的小型计算机程序 bookings/log.csv ，生成 .ics 并通过电子邮件将其发送给与会者 (或通过 API 将其写入 CalDAV/ Google 日历) 。将沙盒本身排除在实时日历之外。 | | 直接日历 API 预订 (高级) | nemoclaw policy-add --from-file 一个单独的 share mount 凭据 | (1) 对于出口，请使用符合以下条件的预设： nemoclaw $SANDBOX\_NAME policy-add outlook --yes 涵盖 Microsoft 365/ Graph/ Outlook。对于 Google Calendar，创建一个小型预设的 YAML googleapis.com 以及 oauth2.googleapis.com 并使用 nemoclaw $SANDBOX\_NAME policy-add --from-file ~/calendar-presets/google.yaml --yes 。(2) 对于 OAuth 令牌，请将其保留在预订树之外：将其存储在 ~/nemoclaw-calendar-creds/token.json 主机上， chmod a-w ~/nemoclaw-calendar-creds/token.json ，然后 nemoclaw $SANDBOX\_NAME exec -- mkdir -p /sandbox/credentials && nemoclaw $SANDBOX\_NAME share mount /sandbox/credentials ~/nemoclaw-calendar-creds 。智能体读取 /sandbox/credentials/token.json 但主机 chmod 阻止任何覆盖。切勿将秘密置于 bookings/ - 该树可由智能体写入。密钥管理器 ( Docker 密钥， pass 或者主机侧密钥环通过 env 传递短命令牌) 比磁盘令牌更好 (如果您的设置支持) 。让智能体在“Book” (预订) 步骤中调用“Calendar API” (日历 API) ，而不是编写 Markdown 文件。风险更高 – 智能体现在可以对您的真实日历进行写入；请先锁定其审批值。 | | 多个日历 (工作 + 个人) | 中的额外文件 ~/nemoclaw-calendar/ 提示编辑 | 将其他只读 ICS 文件放入 ~/nemoclaw-calendar/ (例如 work.ics、personal.ics ) 和 chmod a-w 在主机上运行。它们出现在沙盒内部 /sandbox/calendar/work.ics 以及 /sandbox/calendar/personal.ics 通过现有的 share mount。更新智能体提示词的“CONTEXT YOU CAN READ” (您可以阅读的上下文) 部分，为每个 IC 命名，并告诉智能体对应的 IC。有助于让坐席在履行个人承诺期间避免预约工作会议。 | | 交付新闻摘要 | 提示 - 待解决问题 HANDOFF | 添加“还要在 09：00 将每日“仍在等待”列表发布到我的Web UI”。(重复使用来自[新闻摘要](https://developer.nvidia.cn/build-spark/nemoclaw-applications#ispl1d)食谱。) | 要取消机上协商，请发送：“通过以下命令删除协商：关于。回复他们一次：“我来告诉你这件事 - 情况变了。”并将工作文件存档到“bookings/canceled/” (预订/ 取消/) 下。"代理会将暂存文件移出活动集，而不会丢失历史记录。 ## 故障排除 下表按选项卡分组，因此您可以直接跳转到要调试的工作流程。如果系统出现故障，请从常规沙盒和策略问题入手 nemoclaw / openshell 而非在特定应用程序中运行。 ## 常规沙盒和策略问题 | 症状 | 原因 | 修复 | | --- | --- | --- | | nemoclaw policy-add 返回 unknown sandbox | 输入沙盒名称或删除沙盒 | 运行 nemoclaw list 查看已注册的沙盒；使用确切名称重新运行命令。如果为空，请重新运行 NemoClaw 安装程序以重建沙盒。 | | openshell policy set 失败 validation failed / 退出代码 1 | 格式错误的 YAML 或无效的策略字段 | 常见问题：路径必须从 / 、无 .. 遍历、 run\_as\_user 切勿 root 、 network\_policies 条目需要同时 host 以及 port 。修复 YAML 并重试。 | | openshell policy set 出现问题 unknown field 'Version', expected one of 'version', 'filesystem\_policy', 'landlock', 'process', 'network\_policies' | openshell 中的往返错误 0.0.44： openshell policy get --full 发出顶层密钥 Version: (大写 V) ，但 openshell policy set 只接受 version: (小写) | 将关键帧小写到位，然后重试： sed -i 's/^Version:/version:/' policy.yaml && openshell policy set $SANDBOX\_NAME --policy policy.yaml --wait 。首选：完全跳过完整策略往返并使用加法流 - 使用 preset: \* network\_policies: 块，并使用 nemoclaw $SANDBOX\_NAME policy-add --from-file ./my-preset.yaml --yes 。加法流从未触及实时 version: 字段。 | | openshell policy get 显示新的网络规则，但沙盒仍会阻止主机 | 热重载未完成 | 使用重新运行 --wait 因此 CLI 会阻塞，直到更新得到确认： openshell policy set $SANDBOX\_NAME --policy policy.yaml --wait 。如果仍然失败，请通过 nemoclaw $SANDBOX\_NAME restart (如果在您的版本中可用) 或重新创建沙盒。 | | 无法重新创建沙盒： port 8080 is held by container... | 之前的 OpenShell 网关或沙盒容器仍拥有端口 8080 | openshell gateway destroy -g (或 docker stop && docker rm ) ，然后重新运行 nemoclaw onboard 。 | | policy-add 未列出我所期望的预设 | 预设取决于 NemoClaw 版本 | 列出您的版本支持的内容： nemoclaw $SANDBOX\_NAME policy-add --help 或运行 policy-add 以交互方式读取菜单。较新的预设可能需要更新 NemoClaw。 | | nemoclaw policy-add --from-file ... 失败 Preset must declare preset.name (lowercase, hyphenated RFC 1123 label) | preset.name 自定义预设文件中包含下划线、大写字母或其他非 RFC-1123 字符 | 更改 preset.name 仅限小写字母、数字和连字符 (例如。 news\_sources \* news-sources ) 。内在 network\_policies. 映射键及其 name 字段接受下划线 - 约束仅在顶层 preset.name 。 | | Web UI 显示 origin not allowed 策略更改后 | 通过 localhost 而不是 127.0.0.1 | 使用 http://127.0.0.1:18789/#token= 。网关原点检查需要 127.0.0.1 确切地说。 | ## [每日个人新闻摘要](https://developer.nvidia.cn/build-spark/nemoclaw-applications#ispl1d) | 症状 | 原因 | 修复 | | --- | --- | --- | | 永不触发的预定摘要 | 智能体未继续执行已计划的任务 | 在 Web UI 中提问：“Show me all 定时任务” (显示所有计划任务) | | 消化火灾，但消息说 unable to fetch | 主机不在 network\_policies | 将主机添加为新条目 network\_policies.news\_sources.endpoints 在 news-sources.yaml (第 1 步中的预设文件) 并重新运行 nemoclaw $SANDBOX\_NAME policy-add --from-file ./news-sources.yaml --yes。“Outbound Denials” (出站拒绝) 出现在 nemoclaw $SANDBOX\_NAME logs --follow 以及 openshell term。 | | 智能体可以跳过设置问题，直接浏览一般摘要 | 上一次运行的配置文件仍在内存中 | 发送“忘记我的个人资料，然后从头开始重新运行一次性设置”并重新回答这六个问题。 | ## [软件开发智能体](https://developer.nvidia.cn/build-spark/nemoclaw-applications#iso04p) | 症状 | 原因 | 修复 | | --- | --- | --- | | 智能体写入 develop-and-review.md 但缺少主机文件 | 查看错误的主机路径 share mount 未激活 | 沙盒路径 /sandbox/project 映射到您传入的主机目录 nemoclaw $SANDBOX\_NAME share mount (例如。 ~/nemoclaw-projects/my-app ) 。开放 develop-and-review.md 主机目录下，而非主机目录内 /sandbox/project 主机上运行。验证安装是否已启用 nemoclaw $SANDBOX\_NAME share status 。如果提示“not mounted” (未安装) ，请重新运行 share mount 第 1 步中的命令。 | | 智能体出现故障 Permission denied 写入内容时 develop-and-review.md | 主机目录已锁定 chmod a-w 挂载通过 SSHFS 继承这些权限 | 在主机上恢复写入： chmod u+w ~/nemoclaw-projects/my-app (或您安装的任何目录) ，然后重试。除了主机权限之外，对于沙盒内的内核强制写入边界，请加强 filesystem\_policy 沙盒策略中 nemoclaw $SANDBOX\_NAME rebuild - 文件系统策略在沙盒创建时被锁定，因此需要进行重建才能更改 (工作空间状态会自动保留)。 | | 即使项目有测试，智能体也会运行测试并报告“测试未运行” | 未安装在沙盒镜像中的测试运行器 | 默认的 NemoClaw 沙盒可能无法发布 pytest 、 npm 、 cargo ，或 go test 。创建沙盒后，安装项目一次使用的任何内容： nemoclaw $SANDBOX\_NAME connect ，然后 pip install --user pytest (或同等)，然后 exit。 | | 智能体修改计划之外的文件 | 计划批准检查点已禁用 | 在配置文件中回答 yes 改为“暂停审批” (问题 5)。然后，智能体必须打印 PLAN READY — reply 'approve' 然后等待，永远不要修改源文件，直到您回复 approve。 | ## [Deck Reviewer](https://developer.nvidia.cn/build-spark/nemoclaw-applications#iiq2wc) | 症状 | 原因 | 修复 | | --- | --- | --- | | 智能体报告“摄取的 0 个瑕” | 队列目录为空或文件匹配 ignore\_paths | 使用以下命令确认文件是否存在 ls ~/nemoclaw-redteam/queue/ 主机上运行。检查 profile.yaml.ignore\_paths 用于捕获文件的 glob (例如。 \*\*/~$\* Office 锁定文件除外)。 | | 智能体报告“解析器不可用” .pptx 或 .pdf | python-pptx / pdfplumber 未安装在沙盒中 | 安装一次： nemoclaw $SANDBOX\_NAME connect，然后 pip install --user python-pptx python-docx pdfplumber markdown-it-py wcag-contrast-ratio，然后 exit。如果缺少解析器，智能体将回退至纯文本提取；如果您不希望安装 Python 软件包，则需明确标记该解析器。 | | 同样的发现在我拒绝后不断重现 | “Dismissal” (停用) 模式为 None 或者规则 = 位置对不匹配 | 确认配置文件问题 4 Sticky 或 Per-version 。检查 ~/nemoclaw-redteam/memory/dismissals.jsonl 以验证是否写入了解雇内容。如果 location 字段不同于单个字符 (例如。“幻灯片 1”与“幻灯片 1”) ，智能体将其视为不同的站点，并使用最新报告中的精确坐标再次要求智能体关闭。 | | 从报告中消失 | 尝试自动关闭 (不可能) | 这是一种回归 - CRITICAL 已通过硬编码要求 yes, dismiss critical 根据提示的 DISMISSAL 协议重新确认。重新粘贴完整提示词以恢复规则，然后重新运行。 | ## [日程安排智能体](https://developer.nvidia.cn/build-spark/nemoclaw-applications#iiq2wc) | 症状 | 原因 | 修复 | | --- | --- | --- | | Agent proposes slots inside my focus blocks | profile.yaml 每次运行都不会被重新读取，或者批准值允许 | 智能体需要重新读取 calendar.ics 以及 profile.yaml 每个请求 (工作流程步骤 2 LOAD) 。验证焦点块是否位于 profile.yaml 而不仅仅是在脑海中。将配置文件 Q6 (批准值) 调至 Always ask 如果智能体 Ask only if... 分割过程经常发生。 | | 代理分享活动名称或与会者 calendar.ics 与另一方 | 将信息披露配置文件 (问题 5) 设置为 slots + reasons | 将配置文件问题 5 重置为 slots only。协商安全规则还禁止泄露活动标题、与会者或地点 (如果智能体在以下情况下这样做) slots only 重新粘贴完整的提示词以恢复规则。 | | 预订文件将覆盖已确认的先前预订 | 代理不遵守“永不覆盖”规则 | 检查 ~/nemoclaw-calendar/bookings/ 一个 -v2.md 文件 - 该规则需要一个新文件 -v2 移动会议时添加后缀。如果被覆盖，请从文件系统快照或上次备份中恢复；重新粘贴完整提示词以恢复规则。 | **注意：** 有关安装程序级别的 NemoClaw 问题 (Docker、Ollama、网关设置) ，请参阅 [DGX Spark 上的 NemoClaw](https://developer.nvidia.cn/build-spark/nemoclaw)调试前的操作手册 – 大多数报告的问题来自安装层，而非应用层。 **注意：** DGX Spark 采用统一内存架构 (UMA) ，可在 GPU 和 CPU 之间实现动态内存共享。由于许多应用程序仍在更新以利用 UMA，即使在 DGX Spark 的内存容量范围内，您也可能会遇到内存问题。如果发生这种情况，请使用以下命令手动刷新缓冲区缓存： sudo sh -c 'sync; echo 3 \> /proc/sys/vm/drop\_caches' 有关最新的已知问题，请查看 [DGX Spark 用户指南](https://docs.nvidia.com/dgx/dgx-spark/known-issues.html)。