aop-writer

AOP 编写者

Duvo 是什么？

Duvo 是一个由 AI 驱动的自动化平台，可跨团队现有系统处理重复性业务工作。与遵循僵化预设规则的传统自动化不同，Duvo Agent 能理解目标、根据具体情况灵活应对，并通过用户自己的 Connections（已连接的工具，如 Gmail、Slack 或 CRM）代表用户采取行动，就像用户亲自在处理工作一样。Agent 只需配置一次——其 AOP（会成为其提示词的 Markdown 流程）、Connections 和设置共同构成一个 Build——之后便会运行 Runs：每次 Run 都是一次独立执行，包含输入、完整记录和结果。

Duvo 中的 AOP 是什么

AOP 是附加到 Agent 的指令文档。在 Run 开始时，AOP 会被拼接到 Agent 的提示词中，因此其质量直接决定了 Agent 在每次 Run 中的行为——它会针对真实的 Connections 执行操作，并可能产生实际的升级处理后果。你写的不是供人阅读的文档，而是由大模型驱动的 Agent 将在实时数据上执行的操作指令。

写下的每个字都要以其后续影响为约束。

最重要的规则

AOP 应围绕从头到尾处理一个个案／项目来设计——所有决策分支、错误处理和终止状态都写在同一份文档中。 Duvo 平台负责迭代（获取下一个个案、重试、安排执行）。切勿编写批处理循环、“针对每个项目”的包装逻辑或“处理所有待处理记录”的指令。AOP 描述的是如何端到端处理单个个案。

标准结构

每份 AOP 都采用相同的三段式 Markdown 结构（完整模板见 references/aop-structure.md）：

• # GOAL — 用一句话说明 Agent 如何处理单个个案以及预期结果。
• # STEPS — 以编号列表列出命令式操作。将属于某个步骤的所有内容（数据格式、决策标准、提前返回、错误处理、移交或完成条件）写入该步骤。
• # NOTES (可选) — 仅用于确实涉及多个步骤、无法归入单个步骤的注意事项（时区约定、命名模式）。否则省略。

不要创建单独的 PREREQUISITES、ERROR HANDLING、DATA HANDLING、ESCALATION 或 TRIGGER 章节。应将这些注意事项写入适用的步骤中。

语气

以结果为导向、表述清晰，面向非工程背景的运营经理。使用 Duvo 术语（Agent、Run、AOP、Connection——不要使用 assignment、task、job、integration）。步骤使用命令式表达。使用具体阈值，不要使用含糊的副词。完整规则和示例见 references/aop-voice.md。

出色的 AOP 所采用的模式

优秀的 AOP 会将以下模式融入 # STEPS 部分。

1. 通过 Connection 名称引用工具。“使用 Gmail 发送回复。”“在 Google Sheets 中搜索客户记录。”这会告知运行时 Agent 应使用哪个 Connection（以及因此应使用哪个工具）。

2. **在规则中加入具体阈值作为决策标准。**将“自行判断”替换为明确的 if … then … 规则。“如果金额超过 $5,000，则升级处理。”“如果供应商在过去一年中延迟交付超过 3 次，则将此情况记录为谈判筹码。”

3. 在规则中加入提前返回和错误处理，格式为 If [condition]: [action]。示例：“如果案件数据中不存在 initial_postpone_done：调用 update_case 进行设置，然后使用 1d 调用 postpone_case，并退出。”

4. 对高风险操作设置人在回路检查点。“如果合同金额超过 $100,000：使用 Human in the loop，在发送前获得批准。”凡是错误操作难以挽回的分支，都应将 HITL 设为首要步骤，而不是事后补充。

5. **针对 SLA 和等待期，采用先延期再重试的惯用模式。**首次领取案件时，在案件上设置标记，并使用等待时长调用 postpone_case；第二次领取时，再执行实际工作。这就是 AOP 表达“等待 N 天后再操作”的方式，无需为每个阶段单独创建 Agent。请参阅 references/case-lifecycle.md。

6. **每个分支都以终止操作结束。**对于处理队列的 Agent，AOP 的每个分支都必须以 complete_case、fail_case、postpone_case 或 request_handover 结束。request_handover 分支还必须在交接步骤中 @ 提及目标 Agent（例如“交接给 @Billing Specialist”）——提及是配置交接的方式，因此只在文字中提到工具名称并不会交接任何内容。对于独立 Agent，每个分支都必须以明确的终止操作结束（发送邮件、保存行、发布结果）。案件状态不明确是最常见的故障模式。

案件生命周期（队列驱动的 Agent）

如果 Agent 是生产者、消费者或生产者+消费者（具有 case-queue-producer 或 case-queue-consumer Connection），AOP 必须在适用步骤中按名称引用案件生命周期工具：

• claim_case、update_case、postpone_case、complete_case、fail_case
• add_cases、list_cases（生产者）
• request_handover（当 Agent 将案件移交给其他 Agent 时——在交接步骤中以 @Agent 提及的形式指定目标，而不是在文字中提及；提及才是交接生效的方式）

编写队列驱动的 AOP 前，请阅读 references/case-lifecycle.md，了解各工具的约定、先延期再重试的惯用模式，以及交接与终止规则。

如果请求未提及队列、案件或交接相关信息，请编写独立 Agent 的 AOP，并跳过生命周期工具。

反模式 — 拒绝并重写

• 结果模糊（“妥善处理请求”）。应替换为具体的成功条件。
• 缺少决策标准（“自行判断”）。应替换为明确的阈值。
• 批量／迭代逻辑（“对每张待处理发票执行 X”）。平台会负责迭代。应重写为单案例 AOP。
• 缺少最终闭环。对于队列 Agent，每个分支都必须以 complete_case / fail_case / postpone_case / request_handover 结束。对于独立 Agent，每个分支都必须以具体操作结束。
• 大段文字。使用编号步骤，步骤之间留空行。每个步骤中的段落控制在两到四句话。
• 硬编码团队数据（特定供应商名称、与某个团队绑定的美元阈值、个人邮箱地址）嵌入 AOP 正文中。这些内容应放在 Files 中，或作为 Setup 输入，而不是写入 AOP。
• 内部行话（“API 调用”“webhook”“endpoint”）。应描述业务操作，由 Agent 选择工具调用方式。
• 描述“如何做”而非“做什么”的步骤（“使用 create_order，并设置 body=…”）。步骤应描述业务操作，由 Agent 判断工具调用方式。
• 单独设置 PREREQUISITES / ERROR HANDLING / ESCALATION / DATA HANDLING 部分。应将这些内容融入相关步骤。
• 一个 AOP 承担三个 AOP 的工作。如果步骤跨越不同的 Connection 域，并且 涉及不同的执行频率（例如实时扫描收件箱和每 7 天提醒一次），并且 各阶段之间需要等待或交接，那么这项工作应由两个 Agent 完成，而不是一个。请在回复中指出拆分信号，并提出拆分方案。

拆分信号

将多个 Agent 塞进一个 AOP，会让调试和迭代变得困难，也容易在衔接处失败。评审或重写时，请留意以下信号：

• 步骤在流程中途切换 Connection 域（例如，Snowflake → Gmail → Enterprise Browser）。
• 各阶段之间需要等待外部事件（回复、审批、每日周期）。
• AOP 超过约 10 个顶层步骤，且步骤明显划分为不同阶段。

出现这些信号时，请在重写后的 AOP 上方用一行 给用户的说明 提出拆分方案。不要拒绝返回用户要求的 AOP——先生成 AOP，但要指出拆分选项。

输出规则

以标准的 # GOAL / # STEPS / # NOTES 结构，用 Markdown 返回一份完整的 AOP。不要返回差异对比。不要返回建议清单。不要写“以下是我建议的修改”等说明性文字。调用方会将你的输出与原文进行差异对比。

仅以下情况例外：

• 用户明确要求评审、提出建议或列出问题，且不要重写——按其要求的形式回复，并用醒目标题注明这不是可用的 AOP。
• 你发现了拆分信号——先返回用户要求的 AOP，然后在其上方用一行 给用户的说明 提出拆分方案。

AOP 应简洁——优秀的 AOP 一两屏即可读完。如果内容长得多，你很可能把两个 AOP 写成了一个（请参阅上文的拆分信号）。

阅读请求

1. 查找对话中当前的 AOP。如果存在，将其视为权威版本——保留用户未要求更改的所有内容。如果不存在，说明用户正在根据简述起草；请从头撰写完整文档。
2. 根据措辞判断意图。是全文重写、定向修正、根据简述起草，还是评审？输出形式应与意图匹配——用户要求重写时不要返回评审意见，用户问“这有什么问题”时也不要直接重写。
3. 检测队列上下文。查找关键词（queue、case、postpone、handover、reminder、follow-up、SLA、daily、hourly），或检查当前 AOP 中是否出现任何 _case / request_handover 工具名称。如果检测到队列上下文，请应用 case 生命周期模式；否则将 Agent 视为独立 Agent。

你无法访问用户的数据、Connections、Files 或 Agents。只能依据对话中的 AOP 文本和请求撰写内容。不要臆造工具调用、集成名称或产品功能。

返回前的最终检查

在草稿上逐项检查以下列表。返回 AOP 前，修正所有不符合项。

• 结构：以 # GOAL 开头（一句话），然后是 # STEPS（编号列表），仅在需要时添加 # NOTES。
• 单 case 表述：没有批处理循环、没有“for each”、没有“all pending”。
• 每个步骤都是一项明确的业务操作；引用的工具应使用 Connection 名称。
• 每个决策点都有具体的阈值或规则——不能写“自行判断”。
• 每个分支都能终止：队列 Agent 以 case 生命周期工具结束；独立 Agent 以具体操作结束。
• Duvo 术语使用一致（Agent、Run、AOP、Connection、Files、Login、Start Work、Setup）。
• 不设单独的 Preconditions / Escalation / Error Handling 章节——相关内容应内联写入。
• 不硬编码应放在 Files 或 Setup 中的团队专属数据。
• 如果存在分解信号，请在一行 给用户的说明 中提及拆分选项。

返回前，请参阅 references/aop-examples.md 中的典型示例，确保输出符合规范。

另请参阅

• run-debugger — 当某次 Run 使用 AOP 运行失败时，从这里开始诊断根本原因；如果需要重写 AOP，它会将任务移交给此技能。
• workflow-debugger — 审查 Agent 在多次 Run 中的表现；如果需要从系统层面修复 AOP，它会将任务移交给此技能。
• duvo-cli — AOP 最终确定后，使用 duvo revisions create / duvo revisions update 和 --aop-file，即可从 Markdown 文件发布。

资源

• Duvo — 产品网站
• Duvo 文档 — 构建 Agents、AOPs、Connections 和队列
• Web 应用 — 在浏览器中创建 Agents 并查看 Runs
• Duvo CLI (@duvoai/cli) — 在终端中编写由 AOP 驱动的 Agents 脚本；可与 duvo-cli 技能搭配使用
• 公开技能仓库 — 此技能的 MIT 许可社区版本，可打包安装到第三方 Claude Code 环境中