Task Orchestrator：把 AI agent 的工作流纪律放进 MCP server
AI coding agent 做小改动时，问题往往不在“能不能改”，而在“改动过程有没有留下足够清楚的状态”。
一个 agent 接手 bug，先看日志，再拆任务，再改文件，再跑测试。中间如果换了模型、换了 session，或者另一个 agent 接着做，最容易丢的不是代码本身，而是这些过程信息：当前工作项是什么、谁已经做过什么、哪个步骤被哪个检查挡住、哪些任务必须先完成、最终交付物有没有符合团队约定。
今天想记下的 jpicklyk/task-orchestrator，切的就是这个缝隙。它不是新的 agent runtime，也不是 project management SaaS，而是一个 MCP server：把 work item、dependency graph、quality gate、schema enforcement、actor attribution 和持久化状态放在 server 侧，让任何 MCP-compatible client 都必须按同一套工作流推进。
按 GitHub repository page、README、Releases page、Tags page、公开 commit history、LICENSE、version.properties 和本地 git clone 在 2026-07-17 能核验的公开信息，jpicklyk/task-orchestrator 当前有 196 stars、22 forks。仓库主语言是 Kotlin，GitHub language breakdown 显示 Kotlin 98.7%、JavaScript 1.2%。许可证是 MIT。公开 Git 历史起点是 2025-05-22 19:59:19 UTC，首个提交为 3b257e8。GitHub search 在候选抓取时记录的最近 push 是 2026-07-16 16:01:27 UTC；默认分支 main 的最新提交是 c91a823，提交时间 2026-07-16 16:01:25 UTC。GitHub Releases 当前 latest release 是 v3.11.0，release page 标记发布时间为 2026-07-15 14:47；对应 tag commit 是 2420456，提交时间 2026-07-15 14:11:07 UTC。version.properties 中的版本也是 3.11.0。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | jpicklyk/task-orchestrator |
| 定位 | 用 MCP server 执行 AI agent 工作流纪律 |
| Stars | 196 |
| Forks | 22 |
| 主语言 | Kotlin |
| 许可证 | MIT |
| 公开 Git 历史起点 | 2025-05-22 19:59:19 UTC，首个提交 3b257e8 |
| 最近 push | 2026-07-16 16:01:27 UTC |
| 最新 main 提交 | c91a823，2026-07-16 16:01:25 UTC |
| Latest GitHub release | v3.11.0，2026-07-15 14:47 |
| 版本文件 | 3.11.0 |
| 关键词 | MCP、workflow discipline、quality gates、schemas、agent attribution |
不再只靠 prompt 约束 agent
很多团队现在约束 agent 的方式，还是在系统提示或 AGENTS.md 里写规则：先列计划、先跑测试、不要跳过验证、输出总结。这个办法有用，但它本质上是软约束。agent 可以遵守，也可以忘记；一个 session 里遵守了，另一个 session 未必知道前面的状态。
Task Orchestrator 的思路更像把这些约束搬到协议边界。README 里列出的能力包括持久化任务存储、任务依赖、质量门禁、schema-driven artifacts、角色归属、上下文恢复、状态审计和搜索。agent 不是随口说“我完成了”，而是要通过 MCP 工具提交结构化状态；server 再根据当前任务、依赖和 schema 判断下一步能不能走。
这类工具的价值不在于让 agent 更聪明，而在于让 agent 更难把过程弄乱。尤其是长任务、多 session、多人或多 agent 协作时，状态边界比单次回答的漂亮程度更重要。
Quality gate 是核心角度
Task Orchestrator 最值得看的地方，是它把 quality gate 做成 server-enforced 的工作流节点。
普通 todo list 只能记录“做了什么”。但 agent 场景里，更关键的问题经常是“现在能不能进入下一步”。比如实现前必须先拆出任务；代码修改后必须附带测试证据；交付前必须满足某个 artifact schema；被阻塞的任务不能假装完成；有依赖的任务不能越过前置项。
README 里提到的 schema 和 gate 机制，就是为这种情况准备的。团队可以要求 agent 在某些步骤产生特定结构的 artifact，而不是自由文本。这样做会增加一点流程成本，但换来的是可检查、可恢复、可审计的状态。
对 coding agent 来说，这一点很现实。人类 reviewer 不一定想读完整对话，但会想知道：这个 agent 到底改了哪一块，依据是什么，测试证据在哪里，哪些条件还没满足。如果这些信息在 server 侧有结构，后续接手的人或 agent 就不用从聊天记录里考古。
MCP server 是合理位置
把这件事做成 MCP server，而不是单独 app，也有它的工程意义。
MCP 已经是很多 agent client 接工具的共同层。Task Orchestrator 放在这里，就可以服务多个 client：Claude Desktop、Claude Code、Cursor、Windsurf、Copilot、Gemini CLI，或者自定义 agent runner。它关注的是“任务状态和工作流规则”，不是 UI 本身。
README 显示项目用 Kotlin、SQLite、Exposed ORM、Flyway migrations、MCP SDK、Docker image、shell installer 和多种 client 配置示例来交付。这个组合看起来偏后端：一个本地或容器里的 stateful service，承担工作流状态的真实来源。
这比把约定散落在每个 agent client 的 prompt 里更稳。prompt 可以继续写风格、偏好和项目上下文，但任务状态、依赖关系和 gate 结果应该有一个更硬的地方保存。
适合什么场景
第一类场景，是长任务。比如迁移模块、修复跨文件 bug、做安全加固、补一组测试。这类任务很容易在中途换上下文，Task Orchestrator 可以让下一次接手时看到可恢复的工作项。
第二类场景，是多 agent 协作。一个 agent 做代码搜索，一个 agent 改实现，一个 agent 跑验证。如果没有共同状态，每个 agent 都会各自维护一份世界观。用 server 侧任务图至少可以让它们围绕同一个 work item 集合推进。
第三类场景，是团队想把交付格式标准化。比如每个 bugfix 都必须有 root cause、changed files、test evidence、risk note；每个 refactor 都必须有 dependency impact 和 rollback note。把这些要求变成 schema，比反复提醒 agent 更可靠。
第四类场景，是需要审计 agent 行为的环境。actor attribution 和状态历史不能替代代码审查，但能让“哪个 agent 在什么时候做了什么”更容易回放。
需要注意的地方
第一，Task Orchestrator 解决的是工作流纪律，不是安全隔离。v3.11.0 release note 里也明确把 project-root scoping 描述为协作与上下文分区能力，而不是安全边界。不要把它当 sandbox。
第二，它会引入额外状态。只要有状态，就有备份、迁移、清理和团队约定问题。对一次性小任务来说，直接用 issue 或本地 checklist 可能更轻。
第三，schema gate 的质量取决于团队设计。schema 太宽，约束不住；schema 太细，agent 会花很多时间满足格式而不是解决问题。需要从少数关键 gate 开始。
第四，项目虽然已经有 v3.11.0 和较多 releases，但仍然是一个围绕 AI agent 工作流快速演进的工具。引入到关键流程前，最好先用非关键仓库跑一段时间。
总结
Task Orchestrator 有意思的地方，是它没有继续堆一个“更会聊天”的界面，而是把 AI agent 工作中最容易散掉的部分拿出来做成 server 侧约束：任务、依赖、证据、门禁和归属。
如果你只让 agent 改一个小 typo，它可能显得有点重。但如果你的 agent 任务已经跨 session、跨工具、跨人，jpicklyk/task-orchestrator 值得观察。它提醒我们一件事：agent workflow 的下一步，不一定是更长的 prompt，也可能是更硬的状态机。