Token导航 LogoToken导航

MCP Server · AI代理

Task Orchestrator

MCP任务编排工具是一款为AI代理提供服务器强制执行工作流规范的工具,确保任务依赖关系、文档要求和行动者追溯性得到严格遵守,适用于多代理协作场景。

未说明官方级别未说明来源级核验工具 38
KotlinClaudeAI代理

快速开始

公开资料没有提供安装命令,按仓库或官方文档接入。
作者 / 组织
jpicklyk
提供方
jpicklyk

工具数量

38

来源目录标注

资源数量

0

来源目录标注

提示词数量

0

来源目录标注

GitHub Star

183

仓库热度

收录来源

2 个

MCP World

选型结论

Task Orchestrator 属于AI代理类 MCP Server,公开资料标注 38 个工具,通过传输方式未标注接入,适配 Claude,没有现成的安装命令;接入前要先准备 会话凭据。

分类

AI代理

传输方式

未说明

认证方式

会话凭据

部署方式

公开资料未说明

安装与配置

公开目录没有给出安装命令,需要按仓库 README安装;下面按同类条目的通用流程说明。

公开命令不是通用的启动方式,拼不出可靠配置示例;请在客户端 MCP 配置里按官方文档填写 command 和 args。

上手步骤

  1. 1

    先确认运行方式

    公开资料没有标注传输方式,先看仓库 README,确认是本地进程还是远程地址。

  2. 2

    获取服务

    公开目录没有给出安装命令,按仓库 README里的步骤安装或获取服务。

  3. 3

    写入客户端配置

    在客户端的 MCP 配置里填启动命令和参数,保存后完全退出客户端再打开,让新配置生效。

  4. 4

    验证是否可用

    连接成功后客户端会列出 38 个工具,随便调一个只读工具确认能返回结果。

接入前确认

不要直接授予不必要的文件、网络或账号权限;先核对安装命令和配置内容。

公开资料仍需确认:安装命令

详细介绍

MCP任务编排器

服务器强制的人工智能代理工作流规则。

基于提示的框架希望LLM遵循指示。如果没有,这个会阻止呼叫。

______________________________________________________________________

问题

多代理工作流需要模型没有提供的基础设施。当编排器跨会话分派子代理时,没有内置的方法来强制执行工作开始前必须存在的文档,跟踪哪个代理进行了哪些更改,或保证工作分解中的依赖关系顺序。这些是结构性问题——它们属于服务器,而不是提示。

一种不同的方法

任务编排器是 MCP服务器 --不是提示层。它提供了13个工具,为任何兼容MCP的AI代理提供持久的工作项图 服务器强制质量门执行发生在工具级别:如果未填写所需的设计说明, advance_item 返回错误。如果依赖关系未得到满足,则转换将被阻止。如果启用了参与者身份验证,但代理没有识别自己,则调用在到达服务器之前会被拒绝。

规则存在于服务器中,而不是对话中。

这在实践中意味着什么:

  • 如果不填写所需的规范注释,代理就无法开始实现
  • 在上游依赖关系完成之前,子代理无法推进被阻止的任务
  • 每次转换和注释记录 *谁* 做出了改变(演员归因)
  • 审核模式阻止代理未标识自身的任何写入操作
  • 一个新的会话恰好从上一个会话中断的地方开始——持久状态,而不是会话回放
  • 工作流模式是YAML配置,而不是硬编码的提示——在不更改代码的情况下更改规则

______________________________________________________________________

这有什么不同

||基于提示的框架|任务编排器| |--|------------------------|-------------------| | 执行 |代理应遵循的说明|如果不符合规则,服务器将阻止调用| | 坚持 |基于文件的状态|带结构化查询的SQLite数据库| | 问责 |不知道哪个代理做了什么|使用可插拔验证(JWKS)的参与者归因| | 依赖关系排序 |按提示约定排序|服务器在允许转换之前验证依赖关系图| | 会话连续性 |对话历史或文件重建| get_context() 在一次调用中返回完整状态| | 可移植性 |绑定到一个AI客户端|适用于任何兼容MCP的客户端|

______________________________________________________________________

核心能力

工作流执行

模式定义了代理在每个阶段必须生成什么——服务器会阻止进度,直到完成为止。但模式所做的不仅仅是门转换。他们设置了一个 规划楼层:当代理进入计划模式时,模式告诉它在开始实现之前必须存在哪些文档,从而形成计划结构本身。

# .taskorchestrator/config.yaml
work_item_schemas:
  feature-task:
    notes:
      - key: requirements
        role: queue
        required: true
        description: "Acceptance criteria before starting"
        guidance: "Cover: problem statement, acceptance criteria, alternatives considered, test strategy."
        skill: "spec-quality"
      - key: implementation-notes
        role: work
        required: true
        description: "What was built and why"

advance_item(trigger="start") 从队列需要 requirements 待填充。没有异常,没有依赖于提示的合规性——服务器返回一个错误,其中确切地缺少了哪些注释。

这 guidance 字段提供在适当的时刻出现的创作指令——当代理即将填写该注释时, get_context 返回指导作为 guidancePointerThe skill field更进一步:它引用了代理在填写注释之前必须调用的特定技能,提供了一个确定性的评估框架,而不是自由形式的散文。它们共同创建了在YAML中配置的结构化代理行为,而不是在提示中硬编码。

可组合特征

特征为任何模式添加了交叉注释要求,而不会重复定义。定义一次特征,将其应用于任何项目类型:

traits:
  needs-security-review:
    notes:
      - key: security-assessment
        role: review
        required: true
        description: "Security review of auth, data handling, and access control"
        skill: "security-review"

work_item_schemas:
  feature-task:
    default_traits:
      - needs-security-review
    notes:
      # ... base notes

每 feature-task 项自动继承 security-assessment 注意要求。特征也可以通过以下方式应用于每个项目 traits 参数打开 manage_items --一个涉及身份验证的任务 needs-security-review 而CSS清理则不会。

持久工作项图

一切都是 工作项 在层次图中。项目嵌套高达4层,由类型化的依赖边连接。以原子方式创建整个工作分解:

create_work_tree(
  root={ "title": "User Authentication" },
  children=[
    { "ref": "schema", "title": "Database schema" },
    { "ref": "api",    "title": "Login API" },
    { "ref": "tests",  "title": "Integration tests" }
  ],
  deps=[
    { "from": "schema", "to": "api" },
    { "from": "api",    "to": "tests" }
  ]
)

当 schema 到达终端, api 自动解锁。当所有子节点都完成时,父节点会级联到终端。依赖关系排序是由服务器强制执行的——在结构上,而不是按照惯例。

演员归因与审计

每 advance_item 过渡与 manage_notes upstart接受可选的actor声明:

{
  "actor": {
    "id": "impl-agent-42",
    "kind": "subagent",
    "parent": "orchestrator-1"
  }
}

在配置中启用参与者身份验证以要求它:

actor_authentication:
  enabled: true

启用后,没有actor声明的调用在到达服务器之前会被阻止。查询响应包括完整的委托链——哪个编排器分派了哪个子代理,谁写了哪个注释,谁进行了哪个转换。尸检调试变成了一种数据查询,而不是对话考古练习。

会话连续性

没有上下文重建。一个调用可以恢复全貌:

get_context(since="2025-01-15T09:00:00Z", includeAncestors=true)

返回活动项目、最近的转换(带有演员归因)、被阻止的项目、缺少注释的停滞项目和完整的祖先链。新会话在单个响应中具有完整状态。

作为结构化上下文的注释

注释提供了附在工作项上的有针对性的、特定阶段的文档。实现代理阅读一份针对其任务的简明需求说明,而不是扫描更广泛的项目上下文。

注释是键控的、角色范围的和可查询的:

query_notes(itemId="", role="work", includeBody=false)

仅元数据查询(includeBody=false)让代理检查存在的内容,而无需支付读取每个注释体的令牌成本。

设计理念

任务编排器强制执行工作流结构,而不强制实施方法。服务器拥有护栏——角色转换、依赖关系排序、门强制和问责制。代理人拥有其他一切。没有强制性的规划仪式,没有规定的开发流程,也没有关于代理人如何实施的意见。模式、特征和参与者身份验证是可选择的层,通过以下方式与团队的开发策略集成 .taskorchestrator/config.yaml随着模型获得新的功能,线束不会妨碍,而不是限制代理可以做什么。

______________________________________________________________________

快速开始

先决条件: 码头工人 安装并运行。

1.拉取图像

docker pull ghcr.io/jpicklyk/task-orchestrator:latest

2.向您的MCP客户注册

克劳德代码(推荐):

claude mcp add-json mcp-task-orchestrator '{
  "command": "docker",
  "args": [
    "run", "--rm", "-i",
    "-v", "mcp-task-data:/app/data",
    "ghcr.io/jpicklyk/task-orchestrator:latest"
  ]
}'

任何MCP客户端 --添加到 .mcp.json 在项目根目录中:

{
  "mcpServers": {
    "mcp-task-orchestrator": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-v", "mcp-task-data:/app/data",
        "ghcr.io/jpicklyk/task-orchestrator:latest"
      ]
    }
  }
}

重新启动客户端。服务器在第一次运行时自动初始化,不需要设置。

3.启用工作流模式(可选)

安装项目的配置以激活门强制:

{
  "mcpServers": {
    "mcp-task-orchestrator": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-v", "mcp-task-data:/app/data",
        "-v", "${workspaceFolder}/.taskorchestrator:/project/.taskorchestrator:ro",
        "-e", "AGENT_CONFIG_DIR=/project",
        "ghcr.io/jpicklyk/task-orchestrator:latest"
      ]
    }
  }
}

没有模式,所有13个工具都以无模式工作——没有门,没有必需的注释。在需要强制执行时添加模式。

______________________________________________________________________

Claude代码插件

该插件在MCP服务器之上添加了工作流自动化——技能、钩子和编排器输出样式。

安装:

/plugin marketplace add https://github.com/jpicklyk/task-orchestrator
/plugin install task-orchestrator@task-orchestrator-marketplace

它补充了什么:

层它做什么
技能为常见工作流添加大量命令-- /task-orchestrator:create-item, /task-orchestrator:manage-schemas, /task-orchestrator:quick-start
钩子会话开始时的自动上下文注入、计划模式集成、子代理上下文切换、参与者归因执行
输出风格工作流编排器模式——Claude计划、委托给子代理并跟踪进度,而无需直接编写代码

MCP服务器在没有插件的情况下工作。该插件使其与Claude Code无缝衔接。

______________________________________________________________________

13 MCP工具

类别工具目的
图manage_items, query_items, create_work_tree, complete_tree构建和查询工作项层次结构
备注manage_notes, query_notes持续的阶段范围文档
依赖项manage_dependencies, query_dependencies带图案快捷键的打字边(线性、扇出、扇入)
工作流程advance_item, get_next_status, get_context, get_next_item, get_blocked_items, claim_item基于触发器的转换,具有门强制、依赖验证和原子查找和声明(选择器模式),适用于多代理车队

每个工具都支持短十六进制ID前缀-- advance_item(itemId="a3f2") 而不是完整的UUID。

______________________________________________________________________

它在实践中是什么样子的

Morning — new session, new agent, zero context:

Agent: get_context(since="2025-01-14T17:00:00Z")
       → 2 items in work, 1 blocked, 1 stalled (missing implementation-notes)
       → Recent transitions show orchestrator-1 dispatched 3 sub-agents yesterday
       → Full ancestor chains: "Auth Feature > Login API > Input validation"

Agent: advance_item(trigger="start", itemId="a3f2",
         actor={ id: "morning-agent", kind: "subagent", parent: "orchestrator-1" })
       → Error: "Gate check failed: required notes not filled for queue phase: requirements"

Agent: manage_notes(upsert, itemId="a3f2", key="requirements",
         body="Validate email format, enforce password complexity...",
         actor={ id: "morning-agent", kind: "subagent" })
       → Upserted. guidancePointer: null, noteProgress: { filled: 1, remaining: 0, total: 1 }

Agent: advance_item(trigger="start", itemId="a3f2",
         actor={ id: "morning-agent", kind: "subagent" })
       → queue → work. No context rebuilding. No conversation replay.
       → Actor recorded. Traceable. Accountable.

______________________________________________________________________

文档

资源有什么
快速入门指南第一个工作项的完整设置演练
API 参考所有13个工具——参数、响应形状、参与者归因
工作流程指南模式、阶段门、依赖关系、生命周期模式
船队部署多代理运营商:身份策略、SQLite调优、容量规划、索赔披露
维基完整的文档中心
更新日志发布历史
贡献开发人员设置和贡献过程

______________________________________________________________________

技术栈

  • Kotlin 2.2.0 使用Coroutines
  • SQLite+暴露的ORM --零配置持久存储
  • Flyway迁移 --版本化模式管理
  • MCP-SDK 0.9.0 --STDIO和HTTP传输
  • 码头工人 --一次指挥部署

干净的架构(域>应用程序>基础架构>接口),具有全面的测试覆盖率。

______________________________________________________________________

许可证

MIT许可证 --个人和商业用途免费。

工具与能力

工具数量

38

资源数量

0

提示词数量

0

能力标签

Kotlin本地部署工作流编排AI代理管理任务依赖执行文档强制要求行动者追溯

支持客户端

Claude

数量来自来源目录的标注,具体工具清单以官方文档为准。

典型使用场景

多步任务编排

把拆解、检索、执行串成一条链,模型按步骤调用工具。

长期上下文

把会话、笔记和知识放到外部存储,换个会话还能接着做。

接自有流程

把内部系统和模型连起来,让助手调用已有的工作流。

选择建议

值得选的地方

  • 工具数量 38 个,一次接入能覆盖的操作比单点工具更全。
  • 公开说明写得比较完整,接入前能看清能力边界。

先想清楚的地方

  • 公开资料没有可直接复制的安装命令,第一次接入要自己找入口。
  • 需要自备会话凭据,没有凭据没法直接试。
  • 第三方目录整理,版本更新和行为细节以官方仓库为准。

更适合

  • 需要在AI代理场景里让模型直接调用外部能力的人。
  • 已经在用 Claude 的用户,接入路径最短。
  • 愿意照着官方文档一步步配环境的人。

不太适合

  • 暂时拿不到会话凭据的人。
  • 希望一条命令就装好、不想看文档的人。
  • 需要厂商级 SLA 和技术支持的生产环境。

同类对比

5 个同类
MCP Server工具数传输方式安装命令收录来源最后核验
Task Orchestrator

MCP World · 本页

38未说明未标注2 个2026-05-17
Everything Claude Code

MCP World

0stdio有1 个2026-05-17
Filesystem 560c4363

MCP World

13未说明未标注2 个2026-05-17
Time 7365cb6d

MCP.so

2SSE有2 个2026-05-17
Server Everything (everything)

MCP World

11stdio有1 个2026-05-17

按同分类和工具数量挑出最接近的几条,字段以各自详情页为准。

常见问题

5 条

Task Orchestrator 怎么安装?

公开目录没有给出可以直接复制的安装命令,需要按仓库 README里的步骤安装;装好后写进客户端的 MCP 配置再重启。

Task Orchestrator 怎么在 Claude Desktop、Cursor 里配置?

它是传输方式未标注,客户端配置里要写启动命令和参数,运行环境是 未标注;保存后完全退出客户端再打开,配置才会生效。

Task Orchestrator 收费吗?

本站只整理公开资料,不代收费用,也没有标注具体价格。是否收费取决于服务本身和背后的接口额度,正式使用前按官方说明确认。

Task Orchestrator 需要 API Key 吗?

公开资料标注的认证方式是会话凭据,也就是要先拿到凭据才能连上;凭据只填在自己本地的配置里,不要写进公开仓库。

Task Orchestrator 支持哪些客户端?

公开资料标注支持 Claude;其他客户端只要能配置 MCP Server,也能用同样的命令或地址接入。

来源信息

继续浏览同类 MCP