事项与人工协作

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

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

选择事项入口

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

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

在业务 Bundle 中创建 ISSUE_DEFINITION，声明输入、输出和处理规则。完整作者定义、版本创建、安装和示例见人工事项定义开发。

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

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

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

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

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

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

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