Pursers

聊天会结束，任务板不会。

不只是另一个 MCP。它是 AI Agent 工作的操作系统。

一个本地任务板即可管理整个 Agent 集群——支持任意模型和任意 MCP 客户端。 协调者与你一起制定计划，工作者并行构建，独立审核者依据证据把关每项更改，而聊天结束后，一切都不会丢失。

快速开始 · 工单如何流转 · 包含内容 · 升级到 5.2.1 · 文档 · pursers.app

_{main: 5.2.1}

重要

Pursers 由它自己的 Agent 集群构建而成。 从首次提交到将 5.0.0 发布到 PyPI 和 MCP Registry，只用了 27 天。任务板上的 542 张工单由 37 个工作者席位和 19 个审核者席位处理；审核者在批准前将工作退回 575 次；每次推送发布都必须通过 2,660 项测试的关卡。由一位人类确定方向并作出决策。

工单如何流转

sequenceDiagram
    autonumber
    actor You
    participant C as Coordinator
    participant B as Board (Central)
    participant W as Worker
    participant R as Reviewer
    You->>C: intent
    C->>B: ticket_create
    B-->>W: offer — wakes the waiting seat
    W->>B: ticket_claim — lease starts
    Note over W: builds in its own checkout,<br/>renews the lease
    W->>B: ticket_submit — commit, files, test output
    B-->>R: review offer
    alt evidence holds
        R->>B: approve
    else evidence falls short
        R->>B: reject with fix instructions
        B-->>W: back to the same worker
    end
    B-->>You: approved work, ready to merge

真实产品录制——Fleet 仪表板在一次性任务板上跟踪一张工单，从提交到独立批准：

它为何有效

1. Worker ↛ Reviewer — 构建和把关由不同主体负责。所有反馈都通过看板，因此无法在私聊中协商审批结果。
2. 持久化看板 — Central 将工单、记忆和事件日志提交到 SQLite。记录的生命周期比任何聊天、崩溃和上下文压缩都更长。
3. 唤醒，不轮询 — 等待中的席位会阻塞在日志上，并从同一游标恢复。席位空闲时不会消耗模型轮次，直到有工作分配给它。

从零开始，调度一支团队投入生产

将能力最强的模型分配给协调员席位，并为 Worker 席位选择规模适当的模型。Claude Desktop、Claude Code、Codex、Goose、Cursor、通过 ACP 连接的 IDE、无头 API 循环，都共用同一个看板。

快速开始

python3 -m venv .venv && . .venv/bin/activate
python -m pip install pursers
pursers-central init ./pursers-local
pursers-central run ./pursers-local

将任意 Streamable HTTP MCP 客户端连接到 http://127.0.0.1:8766/mcp——先使用 admin.jwt 创建看板，再使用 worker.jwt 创建 Worker 席位。 init 只会打印凭据路径，不会显示凭据值。打包版 Central 快速开始指南介绍了每个生成文件。 如需添加第二个 Worker、独立 Reviewer 或协调员，请参阅 向看板添加 Agent。

提示

不止一台机器？ 使用 --tls-certfile、--tls-keyfile 和 --allowed-host 运行 Central（例如，使用 Tailscale MagicDNS 名称）。 在 macOS 上使用 Claude Desktop？ pursers-personal setup 会为你配置好——先预览计划，再添加 --apply --activate。

说明

请在独立的虚拟环境中运行 Pursers。它使用 MCP v2；仍需要 MCP v1 的应用无法与它共用环境。

在 Zed 中使用 Pursers

通过安全保管凭据的本地中继，将 Zed 的 Agent 面板连接到一个 Pursers 看板。按照首张工单操作指南创建并跟进一张工单，其中包括明确说明何时需要由操作人员管理的工作者／审核者团队；或者参阅 Zed 参考指南，了解安装、设置、全部五条看板命令、可选的 ACP 线程以及故障排查。

开箱即用

以下所有内容均位于 main 分支，并纳入测试门禁。预览表示相关部分已通过测试，但尚未针对所有实际主机或提供商完成验证。

Board Butler 的作用

Board Butler 是协调器侧的观察者，只有两项范围有限的安全操作；它不是自主舰队操作员。

• **监控：**每次进行有界刷新时，它都会为 project_registry 中的每个活跃看板运行真实的协调器推导流程，并刷新该看板的发现结果。它会忽略非活跃的注册表项目（实现中的 CentralBackend.refresh_registry_findings，并在测试中通过两个看板进行验证）。
• **起草并升级处理：**它通过日志推送流监听协调器问题，检查当前产品或代码库证据，并存储受频率限制的草稿、持久化挂起记录和评估记录。审批或决策问题、范围变更、关卡豁免、发布操作、成员资格或注册表变更，以及不完整的证据，都由人工处理。Butler 会记录升级处理的原因，但不会发送答复（实现中的 process_question 和 classify_question，以及测试对升级处理情形和不提供答复路径的强制验证）。
• **影子模式与主动模式：**影子模式是默认模式，不执行任何票据操作。主动模式还要求单独提供由当前用户拥有、模式为 0600 的授权，至少指定一个 --act-on-board，目标看板在注册表中处于活跃状态，操作类别已启用，并且存在尚未被否决、且将在到期时失效的持久化挂起记录。只有满足这些条件后，它才可以在连续多个周期出现 no_live_candidates 且不存在 can_work=true 的活跃席位时，将开放票据搁置；也可以在提议的升级处理目标缺失或无法工作的情况下，添加拒绝注释。它既不会取消票据，也不会指派目标（实现中的 plan_mechanical_actions 和 refresh_registry_findings，由机械操作测试覆盖）。
• **绝不执行：**它不会合并或推送 main、标记或发布版本、变更成员资格或项目注册表、认领／指派／提交工作，也不会回答受阻席位的问题。这些是操作员或协调器的职责；测试套件明确拒绝认领、指派、提交和回答问题的路径（测试）。

**过期日志发现：**报告中提到的 butler.out.log 过期，是旧文件名不匹配，而非存活状态缺陷。当前启动任务和已签入的服务模板都会将两个输出流写入 board-butler.log；在 2026-09-22，这个配置的日志文件和 runtime.json 同步更新，而 butler.out.log 没有更新。在将旧文件名视为服务状态依据之前，请检查已安装任务的 StandardOutPath。runtime.json 会报告 PID、模式、启动时间和最近活动；如Board Butler 运行手册所述，Fleet 还会验证 pidfile 锁和进程是否正在运行。

Board Butler 行为检查清单

1. **过时问题协调：**在影子模式和主动模式下，若后续决策明确提及某个未解决的协调员问题，则报告该问题以供协调员协调。按时间顺序出现但未关联的决策会报告缺失的关联信息，而不会被臆测为答案。管家不会回答或关闭该问题。
2. **暂缓决策的传递：**在两种模式下，若有一项具有约束力的决策，随后又出现工作邀约或广播，则会在其他席位重新推导门槛之前将其呈现出来。管家不会认领、分配或释放工作。
3. **常设规则的再次出现：**在两种模式下，多个席位提出的问题若重复使用同一个在看板上可见的标识符，就会关联到该常设决策。管家不会根据自由文本相似度推断匹配，也不会在席位上强制执行该决策。
4. **决策范围偏移：**在两种模式下，若某项决策要求更改的文件超出工单声明的相关文件范围，则会报告该情况以供预检协调。管家不会修改工单范围或代码库。
5. **范围受限，故障时默认拒绝：**优先显示关键协调员警报；当前观察结果只会在 50 行、4,800 个字符的限制内取代较旧的非关键行。问题或工单投影不完整时会发出覆盖范围警告，绝不会报告为没有问题。
6. **不增加权限：**在影子模式和主动模式下，所有观察器均为只读。主动模式仍仅增加上述两项分别授权的安全操作。管家绝不会删除文件或看板数据、调度清理任务、合并或推送 main、打标签或发布、更改成员资格或注册表，也不会代替操作者行事。

软件包

源代码树中协调发布的各个组件目前绑定到 pursers==5.2.1、pursers-personal==5.2.1、 pursers-personal-import==5.0.0、pursers-central==0.1.8、 pursers-client==0.1.9、pursers-wait-bridge==0.1.7 和 pursers-acp==0.1.9。

架构

flowchart LR
    subgraph Seats
      C[Coordinator]
      W1[Worker]
      W2[Worker]
      R[Reviewer]
    end
    C & W1 & W2 & R -- "MCP + JWT" --> Central[("Central<br/>SQLite board + journal")]
    Bridge[Wait bridge] -- "subscriptions/listen" --> Central
    W1 & W2 & R -. "block until offered" .-> Bridge
    Central --> Dash[Fleet dashboard]
    Central --> Personal[Personal MCP App]
    W1 & W2 -- "commits" --> Git[(Git)]
    R -- "verifies" --> Git

Central 是事实来源。席位通过 MCP 使用签名 JWT 连接到 Central；等待桥接会跟踪其日志，让席位休眠直至收到邀约；Fleet 仪表板和 Personal 应用会呈现相同状态；Git 仍是经过审查的交付边界。完整的组件、信任、传输和生命周期图，请参阅架构。

• 入门指南
• 将 Agent 添加到看板 — 添加第二个工作 Agent、独立审查者和协调者
• 连接 MCP 客户端 — Claude Code、Codex、Cursor、Goose、Claude Desktop、Zed、API 循环
• 在 Zed 中完成第一个工单 — 叙述式演练和录制镜头清单
• 在 Zed 中使用 Pursers — 安装、配置、看板命令、ACP 线程、故障排除
• 运行多 Agent 集群 — 从头到尾介绍协调者、工作 Agent 和审查者
• 运维 Central — 作为服务运行、备份和恢复、升级、日志、保留策略
• 集群仪表板和 Board Butler — 安装、各个页面、席位向导、门
• 故障排除和常见问题 — 将真实错误消息对应到解决方法
• 参考资料：保留设置 · 自动生成的 MCP 工具、CLI 和环境变量
• 架构
• 安全指南 — 信任模型、凭据、远程访问、泄露事件响应
• 无停机轮换颁发者密钥
• 与其他 Agent 框架的比较
• 参与贡献 · 安全政策 · 更新日志

当前限制

Central 默认通过回环地址绑定纯 HTTP。远程使用时，操作人员需要自行提供 TLS 和允许的主机。存储使用 SQLite，看板通过邀请接纳 Agent。此版本已在 macOS 上测试；Central、Client 和 Wait Bridge 也会在 CI 中于 Linux 上运行测试套件，而 Personal 仅支持在 macOS 上设置。主机集成仍需针对其确切主机构建版本进行验收。Pursers Personal 仪表板为只读，其应用标题为 Pursers Personal。

Pursers 是 On Board v4（onboard-memory-mcp 4.0.4）的后继版本。它是独立的软件包，不会修改 v4 安装；迁移需要显式执行单向导入，而非自动同步。

许可证

Apache License 2.0