---
docStatus: current
---

# 事项与人工协作

使用 IssueDefinition、事项和工作流 human 节点安排责任人、接收人工结果，并与渠道消息组合。

需要同事完成审核、补充信息或做出决定时，应建立可追踪的事项。企微消息只是提醒入口，聊天中的回复文本不会自动成为结构化业务结果。

## 选择事项入口

| 场景                    | 入口                                                       |
| --------------------- | -------------------------------------------------------- |
| 工作流必须等待人工结果           | 使用 `human` 节点，引用业务 Bundle 的精确 IssueDefinition 版本。        |
| 应用或智能体独立创建并管理待办       | 发现事项模块，读取 `createIssue`、`getIssue`、`processIssue` 等方法合同。 |
| 报告生成后主流程立即完成，人工审核独立进行 | 发布业务事件，由 Event Trigger 启动独立的人工处理流程。                      |

`human` 会创建并等待对应事项，不能为了提醒又另外调用 `createIssue` 创建一份重复待办。
独立事项方法和 `human` 作者定义属于不同合同；不要把两者的分配字段直接互换。

## 定义明确的业务结果

在业务 Bundle 中创建 `ISSUE_DEFINITION`，声明输入、输出和处理规则。完整作者定义、版本创建、安装和示例见
[人工事项定义开发](/development/bundle-development/issue-definition-development/)。

例如审核报告可以定义“是否接受”和“处理意见”，但这些是业务自己定义的结果，不能假设所有事项都有相同字段。
没有现成的通用事项定义时，应创建自己的定义；不要等待一个固定名称的系统模板。

## 由谁处理

工作流 `human` 使用候选主体入口。用户、部门、用户组和角色从组织目录选择，按工作流合同填写其准确身份。
角色定义不等于某一事项的责任分配；给成员授予角色也不会自动给他创建待办。

当前 human 合同中，仅一个明确用户时直接分配；多个用户进入同一个候选池，由其中一人领取。
这不是会签。部门、组和角色的展开与权限仍由事项能力校验。

## 与渠道消息组合

先确定事项及其合法访问入口，再向明确的处理人发送提醒。消息可说明待处理内容并附业务页面链接，
接收人打开后仍按自己的身份完成处理。

处理结果必须通过事项能力提交，且符合引用的 IssueDefinition 输出类型。工作流由对应人工处理结果继续推进，
不能把“消息已送达”“群里有人回复”或一次通用 signal 调用当作人工审批完成。

如果使用事件驱动通知，应使用已发布事件合同；不要在不清楚事件是否存在时猜测事件名称。
完整编排见[工作流](/features/workflows/)和[Event Trigger 绑定工作流与输入映射](/development/bundle-development/event-trigger-development/)。

## 验证

检查事项定义精确版本、候选主体、最终负责人、处理权限、结构化结果和工作流后续节点。
通知失败与事项处理失败分别记录；前者不应伪造后者已完成，重试通知也不应重新创建事项。