将工作委派给智能体

本指南介绍如何把工作从你手上交到智能体手上，以及智能体之间相互传递工作时会发生什么。

把工单交给智能体

创建工单，标题和描述要足够精确，能据此开展工作。
把它的负责人设为该智能体，让归属记录在案。
打开（或创建）一个空间，并 @提及该智能体。
在消息中用 # 提及引用这张工单——输入框会自动补全工作区工单——并说明你想让它做什么。

智能体会从对话中接手这项工作。它的进度会流式输出到该空间中。

智能体会收到什么

你的消息，包括你标记的工单引用。
用于工作和汇报的空间。
从工作区已关联仓库检出的隔离工作树。
空间的模式，它决定本次运行的工具面。

模式是空间的属性，而不是工单的属性——工单没有模式。因此同一个智能体可以在一个空间里处于 chat，在另一个空间里处于 plan。你可以从输入框的模式下拉菜单中选择它（Agent、Plan 或 Orchestrate）；review 由 PR 审查空间设置，不可选择。参见模式。

要求结构化结果

输出契约声明在派发上，而不是工单上：expected_output_schema 加上 output_contract_mode（默认为严格模式）。智能体通过调用 submit_output 来满足它，该调用会依据 schema 校验载荷，并拒绝不符合规范的载荷。

被接受的输出和所有被拒绝的输出都会记录在智能体运行日志上。工单自身的状态不受影响——契约失败不会让工单失败。

监控进度

空间——实时的智能体活动，主要视图。
工单——它的状态由改动它的人设置。
可观测性 → 实时（/workspaces/<workspace-id>/observability）——实时的智能体名册。
可观测性 → 洞察——运行日志，含费用与耗时。

没有仪表盘页面；直接访问工作区 URL 会跳转到收件箱。

让智能体相互委派

遇到子问题的智能体会用 delegate_task MCP 工具进行委派。它会创建一张分配给另一个智能体的子工单，并且——当你传入 parent_ticket_id 时——记录这条链，好让保护机制能看到它。

有两项结构性保护始终在工单收口点运行，而不是靠提示词指令：

深度上限——深度超过 3 跳的链条会被拒绝。
循环检测——跳回链中已有智能体的跳转会被拒绝。

当你传入 from_agent_id 时，还会运行另外两项保护（生产环境始终会提供解析器端口）：

自主程度上限——被委派方在空间中的有效级别不得超过委派方。
预算额度——委派会从委派方剩余的硬性停止预算中扣减，且无法凭空增加。没有策略，或策略不设上限，都会通过。

拒绝是明确的：工具会原样返回保护机制给出的原因，因此发起委派的智能体能确切看到原因。delegatedByAgentId 字段记录是谁发起的委派，从而构成一棵委派树。

委派深度上限 3 与内置执行框架的子智能体嵌套上限 2 是不同的限制——一个约束智能体之间的工单，另一个约束单次运行内部的子智能体。

让多个智能体参与同一张工单

把它们作为协作者添加到工单上（角色：assignee、collaborator、reviewer）。这是一份名册——记录谁参与其中——本身不授予任何权限。

要真正把多个智能体放进同一个对话，请从空间头部把它们添加为参与者。之后它们就可以在那里相互 @提及。参见使用空间。

自动创建工单

流水线面板中没有任何节点会创建工单，因此流水线无法把工作拆分成已分配的工单。

确实存在的路径是编排：批准一份提案会创建一个项目和一个团队，把提案的子工单 DAG 编译成一个流水线模板（每个子工单一个 promptAgent 步骤，而不是每个子工单一行 Ticket），并启动该次运行。参见运行编排。