> ## Documentation Index
> Fetch the complete documentation index at: https://java.agentscope.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 控制台创建 Issue 与分派任务

<Note>
  此为预览文档，正式版本尚未发布。
</Note>

Issue 保存一项工作的目标、负责人、讨论、执行记录和交付物。即使执行失败或服务重启，工作本身仍有可追踪的记录。用 Issue 管理“整理报告”“修复缺陷”这类需要完成和验收的任务。

## 界面导览

<Frame caption="当前控制台截图，使用固定演示数据。">
  <img src="https://mintcdn.com/agent-scope/4R9NIhaVf45l0an9/imgs/service/issues.png?fit=max&auto=format&n=4R9NIhaVf45l0an9&q=85&s=11f48098377a0b0ae64596615540ddf5" alt="Issue 列表中的优先级、负责人和状态" width="1440" height="960" data-path="imgs/service/issues.png" />
</Frame>

先通过 **Active**、**In review** 或 **Done** 缩小范围，再查看每行的优先级、负责人和状态。点击标题进入讨论与结果页面；新工作从右上角 **New issue** 开始。

## 创建第一项工作

打开 **WORK → Issues → New issue**。填写有明确结果的标题，例如“分析示例日志并输出错误分类报告”，在说明中给出输入位置、任务边界和期望交付物。

选择 **Sharing**：Private 仅自己可见；Namespace members 面向空间成员。创建后可添加单独协作者。共享范围包含执行记录和附件，因此应在提交资料前确认。

负责人可选 Agent、Team 或 Human，也可选择 Workflow 作为执行目标。选择 Workflow 会使用最新已发布 revision，并把实际版本记录到执行中；没有发布版本时应先完成发布。负责人可以稍后补充。创建后检查 **Executions**，确认是否已产生执行，而不是以 Issue 创建成功推断 Agent 已开始工作。

## 把验收标准写清楚

在详情中补充 Acceptance criteria，例如：

```text theme={null}
- 读取指定的 sample.log，不访问生产日志。
- 交付 report.md，包含错误类型、数量与三条带行号的证据。
- 对无法确认的原因标记“待确认”，不要当作事实。
```

优先级表达重要程度，Due date 表达截止时间；它们不能代替任务说明。大型任务可创建子 Issue，分别明确负责人和交付物，在父 Issue 汇总验收。

## 讨论、文件与跟进

在评论中补充信息、回复线程或提及需要参与的 Agent。检查路由结果或执行记录，确认消息是否产生后续工作。解决一个评论线程表示该讨论已处理，不代表整个 Issue 验收通过。

上传文件作为 Artifact，便于其他参与者查看交付物。Subscribe 用于接收更新；订阅不会扩大对私有工作的访问权限。来源区域记录关联的 Chat、Channel 或其他入口。

## 理解状态

| 状态 | 用户应关注什么 |
| - | - |
| Backlog / Todo | 需求是否完整，负责人是否已安排 |
| In progress | 最新执行、讨论和产物是否在推进目标 |
| Blocked | 缺少的信息、授权或依赖是什么 |
| In review | 按验收标准检查结果及子 Issue |
| Done | 已按该 Issue 的完成策略完成 |
| Cancelled | 工作已取消，保留原因供后续查询 |

一次 Run 成功不等于 Issue 已验收。`review` 策略需要人工确认；`automatic` 策略允许按自动完成规则收敛；`external` 由相应外部流程管理。以详情中的 Policy 和 Issue 当前状态为准。

## 验收或要求修改

在 **Inbox** 的 Review result 中查看最新结果、文件和子 Issue，点击 **Accept result** 将 Issue 完成；或 **Request changes** 写明缺失项，让 Issue 回到 In progress。退回会记录反馈，但不会自动启动下一次执行，需要继续派发或跟进。详见 [Inbox](/v2/zh/service/inbox)。

运行失败时先查看对应 Execution 的节点、Attempt 和错误，再决定重试。重新执行创建新的执行记录，不抹掉失败证据。已经 Done 的工作可按需要重新打开；归档用于收纳历史。

## 先对话再派发

Chat 适合先澄清需求；Issue 用于安排负责人、跟踪协作和验收。下面保留从对话开始的完整操作，你也可以直接按上文创建 Issue。

### Chat 界面导览

<Frame caption="当前控制台截图，使用固定演示数据。">
  <img src="https://mintcdn.com/agent-scope/4R9NIhaVf45l0an9/imgs/service/chat.png?fit=max&auto=format&n=4R9NIhaVf45l0an9&q=85&s=2fd8214fe126bd8a93c13b3186b3a331" alt="Chat 对话与工作转换入口" width="1440" height="1120" data-path="imgs/service/chat.png" />
</Frame>

左侧列表用于找回和整理历史对话；中间 **Conversation** 阅读回复，**Events** 查看执行事件。需要把讨论交付给负责人时，使用右上角 **Create issue**，再补充目标与验收要求。

### 开始一段对话

1. 打开 **WORK → Chat**，点击 **New chat**。
2. 选择 Agent。列表只提供当前可用于 Chat 的 Agent；不可用提示用于解释运行时或会话能力问题。
3. 输入一个小请求，例如“请先介绍你的职责，暂时不要修改文件”，发送并等待回复。
4. 在同一 Chat 继续追问。刷新页面后从左侧列表重新打开，检查历史是否保留。

模型和工具运行在 Agent 绑定的环境中。上传或引用文件前，确认它属于 Agent 能访问的 Workspace；浏览器所在电脑的路径不会自动成为 Agent 的文件。

### 阅读执行过程

消息区显示回复和运行时提供的工具事件。遇到确认请求时，先核对操作对象、命令或参数，再在对话内作出决定。长任务可能持续产生事件；连接暂时中断时，先重新打开已有 Chat 查看状态，避免重复发送同一个执行请求。

Chat 是用户对话，Session 是支撑它的运行上下文。有运维权限时可通过执行诊断追查 Session，但日常交流直接使用 Chat。运行时是否支持持续会话、恢复和工具确认，以所选 Agent 的能力为准。

### 从讨论转为工作

点击 **Create issue**，检查预填的标题和说明，补充目标、交付物与验收要求，选择负责人和共享范围后创建。新 Issue 保存 Chat 来源引用；你仍需要把关键结论写进工作说明，不能假设整个私人对话已向所有协作者公开。

例如，Chat 中讨论了发布说明的结构后，创建“整理本周发布说明” Issue，并写清输入版本、输出文件及事实核对要求。

### 管理历史

| 操作 | 结果 |
| - | - |
| Pin / Unpin | 固定常用对话或取消固定 |
| Archive | 移入 Archived；恢复后可继续对话 |
| Delete chat | 移入 Deleted；可用 Restore chat 恢复，执行诊断仍保留 |

归档和删除是历史管理动作，不要把它们当作取消正在运行的任务。

### 没有回复时

先确认 Agent 仍可选，再检查模型凭据、Environment 或 Runtime Host 在线状态。已有对话打不开时检查当前账号与空间；新配置没有生效时用新 Chat 验证。向管理员提供 Chat ID、发生时间和页面错误，不要发送访问令牌。

下一步：[Team 协作](/v2/zh/service/team-collaboration) · [执行与会话参考](/v2/zh/service/sessions)。

完整输入与验收要求见[研发闭环案例](/v2/zh/service/cases/sdlc-team)，其中把 GitHub 需求、目标分支、测试要求、PR 和合并范围关联到同一项工作。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.