duvo-cli

Duvo CLI

duvo 是 Duvo 公共 API 的官方命令行界面。它以 @duvoai/cli 的形式发布到 npm： 这是一个单一二进制文件，提供按资源分组的子命令（duvo agents …、 duvo runs …、duvo cases …、……），以及一个低级别的 duvo api <method> <path> 备用入口，可用于调用尚未提供专用命令的端点。

当用户想要自动化或编写脚本来使用 Duvo 时，请使用 CLI。 如果用户想通过网页界面交互操作，https://app.duvo.ai 是合适的选择；如果他们 询问 shell 片段、定时任务、CI 步骤，或“如何在不打开浏览器的情况下完成 X”， 那么就该使用 duvo。这两种界面都调用同一个公共 API — 无需改用 curl 来弥补任何功能差距。

托管会话与手动设置

在托管会话中，主机运行时指令决定传输方式、设置、参考资料查找和作用范围。 请先遵循这些指令，再参考本独立指南。当主机说明 CLI 已安装并配置完毕时， 请勿检查安装情况、登录、查看凭据、更改配置文件或切换传输方式。执行命令前， 请先阅读主机指定的参考资料。以下安装、身份验证和配置文件管理步骤仅适用于手动独立设置。

安装（手动设置）

npm install -g @duvoai/cli
duvo --version

需要 Node.js ≥ 22.22.0。无需全局安装，也可以使用 npx @duvoai/cli <cmd>。

身份验证（手动设置）

duvo 会将凭据作为命名配置文件保存在磁盘上。每个 （团队、环境）对应一个配置文件。添加的第一个配置文件会成为默认配置文件；此后， 除非另行指定，否则每条命令都会使用默认配置文件。

duvo login                       # OAuth flow — opens your browser
duvo login --name acme           # name the profile up front
duvo login --api-key <key>       # skip OAuth and store an API key directly
duvo whoami                      # confirm who's signed in

duvo login 默认使用浏览器，通过 OAuth 登录 Duvo 生产租户。传入 --api-key <key> 可改为存储长期有效的 API 密钥（可从 https://app.duvo.ai/settings/api-keys 获取）。

在配置文件之间切换：

duvo profiles list               # show all profiles; `▶` marks the default
duvo profiles use                # interactively pick the default profile
duvo profiles use acme           # set a named profile as the default
duvo --profile acme whoami       # one-off override for a single command

解析优先级（以第一个匹配项为准）：

• 配置文件：--profile <name> 标志 → DUVO_PROFILE 环境变量 → 配置中的 defaultProfile。
• 凭据：DUVO_API_KEY 环境变量（绕过对配置文件中已存储凭据的查找）→ 配置文件中已存储的凭据。
• 基础 URL：DUVO_API_BASE_URL 环境变量 → 配置文件中的 apiBaseUrl → https://api.duvo.ai。
• 团队：--team <id> 标志 → DUVO_TEAM_ID 环境变量 → 配置文件中的 defaultTeamId → 从当前凭据推导出的团队。团队范围的 API 密钥会拒绝不同的 --team；用户范围的密钥可以选择该用户有权访问的任意团队。

阅读帮助信息

阅读 references/commands.md 了解命令语法。每条命令也支持 --help；在托管会话中，仅当主机运行时允许时才使用此选项。 在独立使用时，这些帮助命令会介绍已安装的二进制文件：

duvo --help                      # global help, lists every top-level group
duvo agents --help               # subcommand group
duvo agents create --help        # exact flags for one command

如果二进制文件拒绝某个文档中记载的标志，其帮助信息会说明已安装的 版本。不要猜测标志，也不要将独立帮助示例当作检查托管会话的指令。

输出模式

每条命令会根据返回内容选择默认输出格式：

• 单个资源（duvo agents get <id>、duvo runs get <id>）→ 人类可读的键值文本。
• 集合（duvo agents list、duvo runs list）→ 按资源固定列集显示的表格。
• 以上任一命令使用 --json → 将原始 JSON 输出到 stdout。这是脚本的稳定契约 — 表格和文本格式可能会 在不同版本之间变化，而 JSON 可以安全地通过管道传给 jq 或 yq。

duvo agents list --team <target-team-id> --json | jq '.agents[].id'

编写脚本时，请在命令参考列出 --json 的地方使用此选项并解析响应。不要 解析表格输出 — 列宽和截断阈值 不属于公共契约。不同端点的封装键各不相同 — agents list 返回 .agents[]，queues list 返回 .queues[]，runs list 返回 .data[]，agents create 返回 .agent.id。硬编码 jq 路径前，请先通过一次性调用 --json 检查数据结构。

duvo api 兜底入口

公共 API 中的任何端点都可以通过 duvo api <METHOD> <path> 访问，其设计直接参考了 gh api。在以下情况下使用：

• 新的公共端点已经发布，但还没有专用的 duvo 命令。
• 你需要一种高层命令未提供的精确查询字符串或请求体格式。
• 你正在调试——duvo api 会原样显示 API 的返回结果，不做任何格式处理。

duvo api 会原样传递路径——它不像高层命令那样解析 --team/DUVO_TEAM_ID/配置文件中的默认值，因此请明确写出端点本身的路径。 不同资源的路由结构各不相同：有些集合限定于团队 （/v2/teams/<team_id>/agents），有些则是扁平路径（/v2/artifacts）， 还有一些按 ID 查询的路由仍限定于团队（/v2/teams/<team_id>/invites/<id>）。 请从 GET /v2/documentation/json（原始 OpenAPI 文档；/v2/documentation 是 Swagger UI HTML）中获取确切路径，不要自行推断。

duvo api GET "/v2/teams/$TEAM_ID/agents" -F limit=20 -F offset=0
duvo api POST "/v2/teams/$TEAM_ID/agents" -f name="Ops bot" -F [email protected]
duvo api POST "/v2/teams/$TEAM_ID/agents" --input body.json
cat body.json | duvo api POST "/v2/teams/$TEAM_ID/agents" --input -

-f 会将值作为字符串发送；-F 会将其解析为带类型的值 （布尔值、数字、JSON null，或通过 @file 从磁盘加载 JSON）。完整的标志表请参阅 references/api-escape-hatch.md。

duvo agents create 之类的高层命令是对 duvo api 的便捷封装——它们共用同一个 HTTP 客户端、输出流程和退出 代码，因此脚本可以自由混用两者。

资源组

完整的命令树及标志请参阅 references/commands.md。 顶级分组如下：

• 身份验证与配置文件 — login、logout、whoami、profiles …
• 自动化 — automations …（list、create、get、current、flow、rename、duplicate、delete、add/remove agents and queues、tabs）及其 Policy：automations config-fields、add-config-field、edit-config-field、set-config-field、hide-config-field、restore-config-field、config-sections …
• Agent — agents …、agents delete、agents move、agents duplicate/clone、agents models、agents set-model、agents case-triggers …、agents schedules …、agents triggers …、agents slack-triggers …、agents memory …、agents eval-scores、agents eval-rubrics …
• 建议 — suggestions …（连接建议：list、consume、reject）
• Agent 文件夹 — agent-folders …（以树形结构整理 Agent）
• 修订版本 — revisions …、revision-integrations …（版本化配置）
• 运行 — runs …（start、get、message、stop、respond to HITL、evaluation）
• 队列与案例 — queues …、queues eval-rubrics …、queues aggregations …（对类型化 Case 数据进行 Cube 风格的聚合）、queue-labels …、cases …、cases search
• 通知 — notifications …（list、get、feed、get-batch、counts、unread-count、mark-read、mark-batch-read、mark-all-read、dismiss、delete-read、delete-all）
• 文件与沙箱 — files …、sandboxes …
• 连接与集成 — integrations …、connections …、oauth …
• 密钥与凭据 — secrets …（环境变量密钥）、credentials …（浏览器登录）、revision-secrets …、revision-logins …
• Clarity — clarity …（流程搜索、版本、捕获记录、缺口、证据、分面、导出、生成、推广、工件导入、邀请链接、doctor、流程全景、流程链接、流程标签、流程摘要）
• Pulse — pulse …（create、get、list、send message、attach files、refresh、stop、rename、share、duplicate、move to another team、pdf/snapshot export、version history、restore、messages、answer HITL、connections、comment threads、delete Pulse dashboards、使用 pulse data … 连接/断开队列数据源）
• 技能与插件 — skills …、plugins …
• 团队 — team current、team get、team members、team set-role、team remove-member、team leave、team use、teams list、teams org、teams orgs、teams create-org-team、teams create-workspace、teams org-agents、teams org-insights、teams org-metrics、teams org-runs、teams org-usage
• 邀请 — invite list、invite create、invite bulk、invite update、invite resend、invite delete、invite org-member、invite link get|create|delete
• 内置指南 — guide …（与版本匹配的 CLI 指南，供 AI Agent 使用）
• 自更新 — update（将已安装的 CLI 更新到最新版本）
• 底层接口 — api <method> <path>

端到端操作示例（创建 Agent → 启动运行 → 响应 HITL；管理队列及其案例；上传文件以供沙箱运行； 授权自定义 MCP 服务）请参阅 references/workflows.md。

自动化

在已迁移到自动化的团队中，每个 Agent 和队列都属于一个自动化：这是 Web 应用中显示的单个流程容器。

• duvo automations create --name <name> 会创建自动化及其首个 Agent。--json 响应包含 automation.id 和 first_agent_id。请配置这个首个 Agent，而不是再创建一个。
• duvo queues create 必须提供 --automation-id <id>。若未提供，API 会返回 409：“此团队已迁移到自动化，因此必须在自动化中创建新的 Agent 或队列。”
• duvo agents create 接受相同的 --automation-id。若未提供，后端会创建一个以 Agent 命名的新自动化，因此请传入此标志，让同一流程的所有 Agent 都归属同一个自动化。
• duvo automations list 会提供 ID；duvo automations current <id> 会显示此自动化当前运行的 Agent、队列、触发器和计划。

在尚未迁移的团队中，automations 命令会返回 403（“此团队尚未迁移到自动化，因此没有可供操作的自动化。”），创建 Agent 和队列时无需传入此标志。

建议的构建顺序

通过 CLI 构建流程时，请按以下顺序操作。每一步都依赖前一步。

1. 连接。 对于 Agent 使用的每项服务，请检查 duvo connections list --team <target-team-id> --type <slug>。先连接缺失的服务（参见下文“原生 OAuth 提供商密钥”）。不存在的连接之后无法固定。
2. 自动化。 duvo automations create --name <name> --json。保留 automation.id 和 first_agent_id。
3. 队列、架构、标签。 执行 duvo queues create --name <name> --automation-id <id>，然后，对于类型化案例，执行 duvo queues schema create <queue-id> --file schema.json --name <name>，接着执行 duvo queue-labels create。架构规则和示例见 references/workflows.md 中的工作流 4。
4. Agent。 使用 --automation-id 创建其余 Agent，附加集成，为每个 OAuth 或用户提供的插槽固定一个连接，并使用 duvo queues link-agent 连接队列（对于消费者，请使用 --enable-trigger；否则其案例触发器默认关闭）。回答 Agent 会读取的所有 Policy 问题（参见下文“Policy（配置字段）”）。继续之前，请完成 references/workflows.md 中工作流 4 的设置检查清单。
5. 开启案例触发器。 duvo agents case-triggers list <consumer-agent-id> --json 必须显示 enabled: true。如果显示 false 且已设置 pending_change，说明团队会将自动化更改保存为草稿：只有有人在 Duvo 应用的自动化标题栏中点击 Make active 后，触发器才会开启；CLI 没有对应命令。请让用户执行此操作；在此之前，测试案例会保持 Pending。
6. 测试运行。 执行 duvo runs start --agent <id>，或向队列添加一个测试案例，然后使用 duvo runs get <run-id> 查看结果。
7. 创建计划并保持暂停。 明确传入用户的 IANA 时区：

   duvo agents schedules create <agent-id> --frequency workday --time 07:30 \
     --timezone Europe/Prague --disabled
   duvo agents schedules update <agent-id> <schedule-id> --enable   # after the test run is right
   

   创建计划的人会收到该 Agent 的审批请求（参见下文“审批会发送给运行的发起者”）。

Policy（配置字段）

自动化的 Policy 保存类型化答案，例如阈值、邮箱和发件人列表。应将需要人员调整的值放在这里，而不是 AOP 文本中。当 Agent 的 AOP 中包含 <DUVO:CONFIG key="<key>" name="<label>"> 时，它会读取相应字段；每次运行都会获取当前答案，因此更改答案无需新版本。若 Agent 读取的字段没有答案，运行将被拒绝。

Agent 无法写入 Policy。 值可在 Policy 页面中更改，也可使用 duvo automations set-config-field，或根据用户指示通过 Ask Duvo 更改。Agent 在运行过程中学到的规则应保存在文件或 Agent 记忆中。命令、答案类型、值格式、--fill-mode 和 --binding 的说明见 references/commands.md 中的“Policy（配置字段）”。

邀请他人参加 Clarity 面试

对于多个面试邀请对象，优先使用 duvo clarity interview-invites send <process-id>，并重复使用 --invitee 标志；每批最多 25 位不同的邀请对象。invite bulk 仅供团队使用；对于 --no-interview 或 --process-role，请使用 invite create。 请阅读面试邀请工作流， 了解如何选择邀请对象和处理发送事宜；避免逐个循环发送。

可在所有命令中依赖的约定

这些约定适用于每个命令组，因此在介绍 CLI 时说明即可，无需在各命令中重复：

• --profile <name> 是全局标志，可覆盖本次调用的默认 配置文件。
• --team <id> 是全局标志，可覆盖使用请求团队范围的命令所解析出的 团队。在托管会话中，对于这些命令，即使目标团队与配置的默认团队一致，也始终 明确传入目标团队。请遵循宿主说明来选择目标。 资源 ID 命令可能会忽略此标志；原始 API 路径不会被重写。 命令本地的所有权标志（包括 landscape propose-process --team） 用于指定所有者，不应机械地传入默认团队。组织 命令按文档使用 --org 或位置参数形式的组织 ID。OAuth 和用户范围的 API 密钥配置文件可以选择有权访问的团队；团队范围的 API 密钥 配置文件会拒绝不同的团队。
• 几乎所有会调用 API 的命令都支持 --json，脚本应使用此输出格式。只有当命令的帮助信息或命令 参考文档列出此标志时才能使用；绝不臆造不受支持的标志，也不要解析表格输出。
• 破坏性操作（duvo logout、duvo profiles remove、 duvo runs stop、duvo agents delete、duvo agents move、 duvo agent-folders delete、 duvo cases delete、duvo cases clear、duvo cases bulk-delete、 duvo cases bulk-reprocess、duvo cases bulk-update-status、 duvo cases bulk-update-priority、 duvo skills delete、duvo skills revisions delete、 duvo queues delete、duvo secrets delete、 duvo automations delete、duvo automations remove-agent、 duvo automations remove-queue、 duvo credentials delete、duvo revision-secrets detach、 duvo revision-logins detach、duvo revision-integrations remove、 duvo revision-integrations connections unpin、 duvo agents schedules delete、duvo agents case-triggers delete、 duvo agents triggers delete、duvo agents slack-triggers delete、 duvo agents eval-rubrics remove、duvo agents eval-rubrics replace、 duvo queues eval-rubrics remove、duvo queues eval-rubrics replace、 duvo connections delete、duvo queue-labels delete、 duvo queues aggregations delete、 duvo integrations custom delete、duvo clarity process-labels delete、 duvo suggestions reject、duvo files delete、 duvo pulse delete、duvo pulse move、 duvo notifications delete-read、duvo notifications delete-all、 duvo team remove-member、duvo team leave，……） 会在 TTY 中请求确认；当 stdin 不是 TTY 时则会拒绝执行。传入 -y / --yes 可跳过提示——绝不要将 yes 通过管道传给 CLI 来绕过提示；CLI 会明确拒绝根据管道输入推断用户已同意。
• 退出代码：0 成功，1 通用错误，2 身份验证错误（缺少 或密钥无效、未知配置文件），3 未找到。适用于需要根据失败模式 分支处理的 CI 脚本。
• ID 会直接输出（不带引号），方便复制到 shell 管道和 $() 替换中：

  agent=$(duvo agents create --team <target-team-id> --name "Ops bot" --input "What to do" --json | jq -r .agent.id)
  duvo runs start --agent "$agent"
  

• 弃用警告会输出到 stderr（不会污染 --json 的 stdout），且无法关闭。如果用户报告了意外警告，请检查其 @duvoai/cli 版本是否过旧。

易踩的坑和注意事项

• 配置文件与凭据。 --profile foo 会更改读取的配置文件；DUVO_API_KEY=… 会覆盖凭据，但仍使用所选配置文件的 apiBaseUrl。若要指向完全不同的环境，请同时设置 DUVO_API_KEY 和 DUVO_API_BASE_URL。
• 不带参数的 profiles use 会打开交互式选择器，且只能在 TTY 中使用。在 CI 中，始终明确传入名称。
• agents create 默认采用交互模式。 如果省略 --name 和 --input，且 stdin 是 TTY，CLI 就会提示输入。在 CI 中，请传入这两个标志（如果不想立即构建，还要传入 --no-build），避免它阻塞并等待输入。
• cases create --from-file - 会从 stdin 读取 JSON。文件（或 stdin）内容应为单个 case 对象或最多包含 100 个 case 的数组。每个 case 的格式为 { "title": "…", "data": "…", "labels": [{ "key": "…", "value": "…" }] }。没有 key 的标签仅作为标记使用。
• Sandbox 文件与团队文件。 duvo files … 管理持久化的团队文件（可在 UI 的 Files 页面中查看）；duvo sandboxes … 为单次运行暂存文件（duvo runs start --sandbox-id <id>）。请勿混用。
• Connections 与 integrations。 duvo integrations list 显示团队的集成类型目录；duvo connections list 显示用户实际连接的账户（每次 OAuth/凭据流程对应一个账户）。基于 OAuth 的连接（Gmail、Slack 等）通过 duvo oauth native start <provider> 启动，而不是通过 duvo connections create——后者仅用于用户提供的 MCP 服务。
• 空的 connections list 结果按用户和团队区分。 它会列出当前用户在所选团队中的连接，以及与该团队共享的连接。integrations list 中的行始终显示 has_oauth_tokens: false：这些是目录条目，不是账户。因此，某项集成显示 0 个连接，意味着该用户尚未在此团队中授权任何账户。在判定账户缺失之前，请检查 duvo whoami 和你传入的 --team。
• 原生 OAuth 提供商键不是集成类型。 oauth native start 接受提供商键，integrations list --json 会将其列为 oauth_provider_key（Gmail 是 google_gmail，Google Calendar 是 google_calendar，Outlook 是 microsoft_outlook）。传入类型（gmail）会返回 "Unknown OAuth provider"。键为 null 表示该集成不是原生 OAuth 集成。HubSpot、Asana、Attio、Amplitude、Supabase、Notion、Granola 和 Apify 则通过 MCP OAuth 连接；每项服务的服务 URL 和 --integration-type 均列在 references/commands.md 的 "OAuth flows" 下： duvo oauth mcp authorize --url https://mcp.hubspot.com --name HubSpot --integration-type hubspot。 其他键为 null 的集成，请在 Web 应用中连接。
• 已附加 ≠ 已连接。 revision-integrations attach 只会在修订版上创建集成插槽。对于 OAuth 和用户提供的集成（HubSpot、Gong、Slack、自定义 MCP 等），只有将某个用户连接固定到插槽后，运行才能使用它——未固定连接的已附加插槽会在运行时因"not connected"而失败，并且附加时不会发出警告。使用 duvo connections list --team <target-team-id> --type <slug> 查找连接，通过 duvo revision-integrations connections pin 固定，并使用 duvo revision-integrations connections list 验证（每个插槽应至少有 1 个条目）。默认集成（browser、Exa、human-in-the-loop、case-queue-producer/case-queue-consumer 等）无需固定，但 case-queue 插槽需要先映射队列，可通过 duvo revision-integrations case-queue-setup 验证。请参阅 references/workflows.md 中的工作流 7 和工作流 4 的设置清单。
• 没有 consumer 的队列会让其中的 case 一直处于 Pending。 没有任何组件会领取它们，因此这些 case 会一直留在那里，直到有人手动关闭（duvo cases bulk-update-status）。不要创建只由 producer 写入的“audit”或“log”队列。若要记录发生过的事情，请让 Agent 写入文件（duvo files …），或在有 consumer 的队列中为每次运行添加一个摘要 case。
• 审批会发送给 Run 的创建者。 human-in-the-loop 请求会发送给该运行所属的人：定时运行属于创建该计划的人；由 case 触发的运行则属于该 case 上一次运行的所有者，如果没有则发送给创建该 case 的人。使用 API key 创建的计划属于该密钥的用户。请求会出现在该用户的 Requests 收件箱中，因此应由负责审批的人创建计划。
• Secrets、connections 与 credentials。 这是三个独立的存储：duvo secrets 保存运行时注入到运行中的环境变量键值对；duvo credentials 保存浏览 Agent 使用的浏览器登录信息（域名 + 密码，可选 TOTP）；duvo connections 保存连接外部服务的 OAuth/API key 连接（Gmail、Slack、自定义 MCP 等）。它们互不重叠——使用 revision-secrets 附加 secrets，使用 revision-logins 附加登录信息，使用 revision-integrations connections pin 固定 connection 插槽。
• 多团队 OAuth 和用户范围的 API key 配置文件。 OAuth 登录，或未被服务端固定到单个团队的 API key（即_用户范围_的密钥），可以操作多个团队。使用 duvo teams list 查看所有团队，然后在按请求指定范围的命令中传入 --team <id>。手动设置时，可以使用 duvo team use <id> 设置配置文件默认值——这两种方式都适用于这些配置文件。_团队范围_的 API key 是唯一的例外：服务端已将其固定到一个团队，因此无法通过 --team 指定其他团队。
• 重新连接已过期的 OAuth 连接。 不要为过期连接创建新连接——将现有连接的 ID（通过 duvo connections list 获取）传入 duvo oauth native start 或 duvo oauth mcp authorize 的 --reconnect-instance-id <id>，即可原地重新授权，而不是创建重复连接。
• Clarity 同时提供读取命令和明确的写入命令。 先运行 duvo clarity overview <process-id>，然后使用 versions、current、proposal、compare、gaps、evidence、readiness 或 facets 了解流程。只有当用户确实想要更改 Clarity 状态时，才使用写入命令：生成、晋升、回退、后处理、自动化构建、额外采集 Agent、邀请链接或 Miro 工件导入。这些仅适用于 v2 的命令需要 Clarity v2 流程；旧版 v1 流程仅支持 overview、status、captures、capture 和 export。默认输出为精简模式；仅当 JSON 命令明确传入 --include-transcripts 时，才会包含转录文本和媒体 URL。
• 通知：批次与单条通知。 duvo notifications feed 返回单条通知以及按 Agent 或 Queue 分组的通知批次；get-batch 和 mark-batch-read 只接受批次 ID（来自 feed 或某条通知的 batchId），不接受单条通知 ID。在 notifications list 中，--sort importance 必须搭配 --batch 使用——如果省略 --batch，CLI 会在本地拒绝该组合。
• Clarity 工件导入在底层使用两阶段 API。 对于本地 Miro SVG、XML、PNG 或 JPEG 导出文件，请使用 duvo clarity import-artifact <process-id> <file>。此命令会创建签名 URL、上传字节并完成导入。对于自定义上传客户端或 artifact-chat 工作流，请使用 duvo api 直接调用公共路由。
• Slack 频道触发器需要先连接工作区。 除非 Slack 工作区已绑定到该 Agent，否则 agents slack-triggers create 会失败——创建前请使用 agents slack-triggers workspaces <agent-id> 检查；如果团队安装了多个工作区，还要传入 --workspace。
• 团队成员管理各命令有不同的最低角色要求。 team set-role 需要 Manager 或更高角色（只有 Owner 可以授予或移除 Owner 角色）；team remove-member 需要 Superadmin 或更高角色；任何成员都可以使用 team leave。这三个命令都会拒绝操作团队中最后一位 Owner。
• 将文件附加到 Pulse 的两种方式。 duvo pulse send-message <id> --message <text> --attach-file <path> 会一步上传并引用文件——适用于你已知道要发送的指令时。duvo pulse attach <id> <file> 只会暂存文件并输出其附件 ID，适用于指令将单独编写或发送的情况（例如从构建消息正文的脚本中操作）。两种方式都受相同限制：最多 5 个文件，每个文件不超过 25MB。

CLI 不适用的情况

遇到以下情况时，引导用户使用其他界面：

• 他们想要实时读取运行事件流。 CLI 的 runs get / runs messages 只能读取某个时间点的数据。可在 runs start 中使用 --webhook-url 异步接收事件，或在 Web UI 中打开该运行。
• 他们想要交互式编辑 AOP 或 Agent 配置。 revisions create 和 revisions update 接受配置文件，但手动编写配置很麻烦。若只想更改 AOP，可改为传入 Markdown 文件并使用 --aop-file。除非只是进行小范围的定向修改，否则请引导他们使用 Web UI 中的 Agent 编辑器。
• 他们想在自己的进程中运行 Agent，而不是在 Duvo 上运行。 公共 API 不支持这种方式；CLI 是连接托管 Duvo 平台的客户端。

技能内参考资料

• references/commands.md — 按资源分组的完整命令树和标志。需要确认命令所需的具体标志时，请查阅此文档。
• references/workflows.md — 端到端操作指南（创建 Agent 并启动运行；通过 HITL 处理决策；队列和案例的生命周期、案例架构和去重；使用已上传文件运行沙盒任务；授权自定义 MCP 服务）。
• references/api-escape-hatch.md — duvo api 标志参考，包含 -f 与 -F、@file 类型化字段以及用于原始 JSON 请求体的 --input 的示例。

操作前请阅读相关命令参考；托管会话在需要回退帮助时遵循宿主运行时说明。

另请参阅

• aop-writer — 编写或重写 Build 中包含的 AOP（duvo revisions create / duvo revisions update）。
• run-debugger — 诊断失败的 Run；配合 duvo runs get、duvo runs messages 和 duvo revisions get 读取 API 模式的数据。
• workflow-debugger — 审查跨多个 Run 的 Agent 或工作流；配合 duvo runs list、duvo queues agents 和 duvo revisions get。

资源

• Duvo — 产品网站
• Duvo 文档 — 概念、构建 Agent 和 Connections
• Duvo API 参考 — CLI 封装的所有端点
• npm 上的 @duvoai/cli — 版本、安装说明和更新日志
• Web 应用 — CLI 可脚本化操作的所有功能的交互界面
• API 密钥 — 为 duvo login --api-key 创建和撤销 API 密钥
• 公开技能仓库 — 此技能采用 MIT 许可的社区发行版，可安装到第三方 Claude Code 环境中