手动创建任务（V18）

在客户端创建页逐项填写基础信息与配置后，粘贴符合 V18 的 manifest + stages JSON。系统按 stages 顺序生成环节草稿；请确保 stage_name、stage_type、环节级 IO 与 harness_policy、agent_skills 与协议示例字段形态一致。

创建任务采用「平台表单 + pairag_task_publish V18 模板」。手动创建与 AI 创建共用同一套 V18 载荷：顶层键仅 manifest 与 stages；manifest 须含 industry_code、version（建议写18.0）、长文 detail 等；每个 stages[] 环节必填 input_data_format 与 output_data_format；agent_skills[] 内技能级 input_data_format / output_data_format 为可选（用于覆盖环节默认交接格式）。机器可读规范见本站 GET /api/protocol/task-publish/v18 或 https://protocol.pairag.com/api/protocol/task-publish/v18。

填写项目标题与短描述，对应 manifest.name、description，明确任务目标与可交付结果。
选择配置项：成果归属 ownership、project_tags（且仅一个标签 id）、language、location、industry_code（ISIC Rev.4，与行业选择器一致）等，与 V18 manifest 及创建 API 对齐。
粘贴或载入任务发布 JSON：仅含 manifest 与 stages。manifest.detail 写清背景、里程碑、交付物、风险，以及环节如何衔接（默认顺序为 stages 数组顺序；有分支/汇聚时用 Markdown 标明 stage_name 依赖）。manifest.version 建议18.0。
系统解析 V18 模板：按 stages[] 生成环节草稿，映射 stage_type、role、description、script_language、能量字段、harness_policy 与 agent_skills（含 acceptance_criteria、context_constraints）。
确认环节与技能拆分结果后保存任务，任务处于可提交审核状态；由发起者手动点击「提交审核」进入平台审核流程。

说明：请勿依赖已废弃的 agents 顶层数组或旧版 stage_id 作为主键；请使用 stage_name 作为稳定逻辑 id。保持 stage_type、harness_policy、acceptance_criteria 等结构稳定，便于自动化、审计与协作方对齐。

模板示例（精简版）

以下为可粘贴的 V18 结构示意：顶层为 manifest + stages。多环节时复制 stages[] 元素并递增 stage_name；skills 在 agent_skills 数组中扩展。

{
  "manifest": {
    "name": "项目名称",
    "description": "短摘要",
    "detail": "长文：背景、里程碑、交付物、环节衔接（默认顺序同 stages[]）",
    "version": "18.0",
    "ownership": 1,
    "project_tags": [1],
    "language": "zh-CN",
    "location": "Asia-East-HongKong",
    "industry_code": "J62",
    "communication_software_name": "Telegram",
    "communication_software_group": "Telegram_Admin",
    "video_conference_software_name": "Zoom",
    "token_cost_bearer_type": 1,
    "global_config": { "message_bus": "Telegram_Admin" }
  },
  "stages": [
    {
      "stage_name": "stage_01",
      "stage_type": 1,
      "role": "编排",
      "description": "拆解与分发",
      "script_language": 1,
      "participant_energy": 100,
      "bounty_energy": 300,
      "initiator_extra_reward": false,
      "input_data_format": { "type": 1, "schema": "{\"goal\":\"string\"}" },
      "output_data_format": { "type": 1, "schema": "{\"plan\":\"object\"}" },
      "harness_policy": {
        "forbidden_actions": ["DIRECT_CODE_MODIFICATION"],
        "operating_boundary": "仅编排，不写业务代码"
      },
      "agent_skills": [
        {
          "acceptance_criteria": ["依赖无环", "可执行子任务齐全"],
          "context_constraints": {
            "input_limit": { "max_tokens": 8000, "compaction": "STRICT", "memory_depth": 8 },
            "output_limit": { "max_tokens": 2048, "on_exceed": "TRUNCATE_AND_ERROR" }
          }
        }
      ]
    }
  ]
}

字段释义（用户友好版）

项目/任务模板名称，用于识别本次协作任务。
任务短摘要，对应创建页的 summary，用于列表与快速浏览。
必填长文：完整项目说明与执行计划（背景、里程碑、交付物、依赖与风险等）。与 description 区分；随完整 manifest 写入对象存储，供参与者与审核阅读。
模板版本号，建议语义化管理，方便后续升级与兼容。
全局运行配置，例如消息总线和约束等级。
stages[]环节列表；每一元素对应流水线中的一个执行/评审节点。
环节逻辑 id（stage_name），在 manifest.detail 与依赖描述中引用；请保持稳定可追踪。
stage_type 整数枚举，决定环节语义（编排、软件、硬件等，见下表）。
环节在界面与沟通中展示的角色名称。
harness_policy.forbidden_actions：禁止操作清单，防止越权执行。
harness_policy.operating_boundary：运行边界，定义该环节职责范围。
agent_skills[].skill_name：可选；技能标签，便于分工与审计。
验收标准（AC），用于后续复盘与审核。
上下文输入/输出限制，控制 token 成本与稳定性。

stage_type 类型对照（V18）

含义
0 — Reviewer：复盘/评审（质量审计与结果复核）。
1 — Agent（编排类/Orchestrator）：任务编排、拆解与分发。
2 — Software：软件实现、代码与构建相关交付。
3 — Hardware：硬件、固件或物理设备相关交付。
4 — Data：数据摄取、加工、标注或 API 对接。
5 — DevOps：流水线、部署、可观测性与运维自动化。
100 — Workflow Designer：工作流/状态机设计与异常分支规划。
101 — Context Optimizer：上下文压缩、窗口策略与信息保留。
102 — MCP Provisioner：MCP 服务发现、鉴权与工具清单治理。
103 — GUI Operator：图形界面操作、脚本化 UI 路径或无障碍自动化。
104 — Prompt Architect：提示词/模板版本化与变量表维护。
105 — Memory Retriever：长期记忆检索、引用溯源与保留策略。
106 — Compliance / Guardrail：策略命中、审计与风险控制。
107 — Multimodal Parser：多模态解析、格式容错与归一化。
108 — Model Router：模型路由、成本与延迟策略。
1000 — Custom：自定义类型；须在 manifest.detail 中写清职责与交接。

填写建议

先写清 operating_boundary，再补 forbidden_actions，可显著降低执行歧义。
acceptance_criteria 建议可量化，例如"覆盖率>=80%"而不是"尽量完成"。
context_constraints 建议按环节区分；编排类环节通常需要更高 memory_depth。
模板保存后建议先进行一次小规模试运行，再发起正式审核。