使用 Okou 创建工作流指令

你不需要从空白页开始编写工作流指令。先与你的智能体一起完成一项真实任务。等结果有用后，再让智能体把你们共同开发的方法整理成可复用的工作流。

智能体会生成第一稿。你的职责是审查它的假设，并决定工作流在哪些地方需要更清晰的约束，这样其他队友才能获得可靠结果。

在 My Okou 中，个人指令（Instructions）保存每位成员的偏好；工作区工作流保存可重复的流程和团队标准。私人工作流归当前用户所有，公开工作流则在工作区内共享。执行时使用的是执行该运行成员的个人指令（Instructions）、记忆、账户和权限。在 旧版智能体（Legacy Agents） 中，工作流仍然附属于某个智能体。请参阅Instructions and experience modes。

从一次成功运行开始

在智能体已经见过任务、源材料、你的反馈以及可接受结果之后，创建工作流会更容易。

1. 给智能体一个真实任务以及它实际需要的输入。
2. 审查结果，并纠正缺失的上下文、薄弱的推理或错误的格式。
3. 当结果足够好时，让智能体提炼出可复用的方法。
4. 让智能体起草工作流名称、描述、指令，以及它建议的任何参考文件。
5. 在将工作流公开之前，先一起审查草稿。

你可以这样问：

把我们刚才做的事整理成一个团队可复用的工作流。请起草名称、描述和指令。把可复用的方法与只适用于这个案例的细节分开。在我们最终定稿之前，请列出我应该审查的假设和约束。

这让智能体负责起草，也让你负责决定哪些部分必须受控。

指令是放置约束的常见位置

工作流指令会随工作流一起流转，并在每次运行时生效。因此，它是定义约束的最常见位置之一，例如所需输入、已批准来源、输出格式、质量标准，以及需要确认的操作。

但它并不是唯一的控制层：

不要把指令文本当作访问控制的替代品。如果某项操作在技术上必须受限，请同时使用实际的连接器授权、具名权限以及清晰的指令。

审查智能体的第一稿

你不需要重写每一句话。把审查重点放在那些对团队真正重要的决定上。

应该在什么时候使用？

• 应该由哪种请求或哪种情境来选择这个工作流？
• 在什么情况下智能体不应该使用它？
• 这个描述是否足够具体，能够把它与相似工作流区分开？

需要什么输入？

• 同事在工作开始前必须提供什么？
• 哪些缺失的输入应该让智能体提出问题？
• 哪些细节应该属于每次运行，而不是永久指令？

哪些来源和规则优先？

• 哪个是事实来源系统？
• 哪个附加文件包含已批准的评分标准或模板？
• 如果两个来源冲突，哪个优先？
• 对于无法验证的事实，智能体应如何标注？

输出应该是什么样子？

• 需要哪些部分或字段？
• 什么样的细节程度才有用？
• 输出是否需要引用、链接或置信度标签？
• 当提供了目标位置时，结果应该放到哪里？

智能体必须在哪些地方停下？

• 哪些操作需要确认？
• 智能体应该创建草稿，而不是发送或发布吗？
• 哪些数据不能出现在公开工作流或共享结果中？

这些就是值得明确写出的约束。让智能体负责措辞，然后确认这些措辞确实反映了你的决定。

一种可一起审查的结构

智能体可以使用下面的结构来起草第一版。把它当作审查框架，而不是你必须自己填写的表单：

# Goal
State the single outcome this workflow must produce.

# Use this workflow when
Describe when to use it and any important exclusions.

# Required inputs
- List the information needed for a reliable result.
- Explain what to do when an input is missing.

# Sources and tools
- Name authoritative systems, documents, or attached files.
- Explain which source wins if information conflicts.
- Define how to handle facts that cannot be verified.

# Procedure
1. Verify the inputs and scope.
2. Gather the required evidence.
3. Apply the team's rules or rubric.
4. Produce the deliverable.
5. Check it against the quality bar.

# Output
Define the required sections, fields, format, and destination.

# Quality bar
- State what must be accurate, cited, complete, or consistent.
- Define what counts as done.

# Approval boundaries
- List actions that require confirmation.
- Specify when to create a draft instead of taking the final action.

简单的工作流可能只需要几个部分。高风险工作流可能需要更明确的来源、验证和审批规则。请智能体把指令写得尽可能简短，但不能隐去团队依赖的任何决定。

示例：共同创建线索资格判断工作流

假设你让智能体调研一条入站线索并起草回复。在运行过程中，你更正了公司规模，说明 CRM 是事实来源系统，应用了团队的 ICP 评分标准，并要求邮件更简短。

在结果获得批准后，让智能体把这段对话整理成一个工作流。智能体会起草流程。然后你补充那些应该超越这条线索、继续保留下来的约束：

• 在进行公开调研之前先检查 CRM；
• 评分时使用附带的 ICP 评分标准；
• 对公司规模、地点和当前职位引用来源；
• 将无法验证的必需事实标注为 Unknown；
• 返回 Account summary、Evidence、ICP score、Risks、Recommended next step 和 Reply draft；
• 创建邮件草稿，且未经确认绝不发送。

现在智能体可以把这些决定纳入指令中。你不需要规定每一个调研步骤。你需要让团队的来源、输出契约和审批边界清晰明确。

用通俗语言反馈约束

你可以通过告诉智能体必须改变什么来收紧草稿：

• “如果缺少 CRM 记录，就先索取后再开始。”
• “当公司名称冲突时，将 CRM 视为事实来源系统。”
• “简报中的每一条事实性主张都需要一个来源链接。”
• “把回复控制在 150 个词以内，但语气要适应入站消息。”
• “把邮件创建为草稿。绝不要自动发送。”
• “这个工作流不应在已有商机上运行。”

让智能体更新工作流，并概述每一处更改对应的是哪条约束。这样更容易发现被误解或放在错误部分的规则。

把合适的内容留在指令之外

有些信息不应成为永久性的工作流文本：

• 客户名称、一次性截止日期和特定案例的目标位置应放在运行请求中；
• 密码、令牌和私密凭据不应放在指令或附加文件中；
• 日程和事件应放在自动化中；
• 技术访问边界应属于连接器授权和具名权限；
• 只适用于某个结果的个人反馈可以留在那段聊天中。

指令应承载可复用的方法和行为约束，而不是与工作相关的所有细节。

一起测试并改进

至少用两个现实输入运行该工作流，最好再加上一位队友。每次运行后都问：

• 工作流是否针对正确的任务被触发？
• 它是否请求了所需的输入？
• 它是否遵循了预期的来源优先级？
• 输出是否一致，同时又没有变得僵硬？
• 它是否在要求的审批边界处停止？
• 这个问题是否可重复，还是只适用于这个案例？

让智能体为可重复的缺口修改指令。把一次性的更正保留在运行中。当这种方法对除最初创建者以外的人也奏效时，与团队共享该工作流。