Task Orchestrator

MCP任务编排器

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

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

](https://github.com/jpicklyk/task-orchestrator/releases)   

______________________________________________________________________

问题

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

一种不同的方法

任务编排器是 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

它补充了什么：

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

______________________________________________________________________

13 MCP工具

每个工具都支持短十六进制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.

______________________________________________________________________

文档

______________________________________________________________________

技术栈

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

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

______________________________________________________________________

许可证

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