Agent Kanban
为自主软件智能体提供任务编排、执行追踪与人工审核的控制台。
按维度查看评分与理由
证据展示了基于认证、租户/所有者隔离、代理与运行会话绑定、跨所有者关系拒绝以及禁止受托代理自审的权限边界；人类审核门、幂等键说明、迁移前置阻断和公开视图的只读定位也降低了外部操作风险。架构图明确列出 Worker、D1、Realmroot、Enbor 与 GitHub 的数据和控制边界，故数据流透明度可给满分。扣分在于：材料未完整列出各接口所需的最小权限或作用域；删除 Board 等操作未展示逐次确认、软删除或恢复机制；敏感信息部分主要是“不提交 .dev.vars”、密钥长度和认证测试，未给出轮换、日志脱敏或事件响应细节；依赖虽使用 frozen lockfile、CI 和部分精确版本，但未提供锁文件、安全扫描、SBOM 或漏洞处置证据。作者、版权和生态归属清楚，但发布者身份未经企业注册表验证，且若干“已验证执行来源”主张在所给片段中只有说明、没有对应实现证据。
README、package 脚本、CI 矩阵和测试中的命令、Node/pnpm 版本、架构术语及生命周期基本一致；升级守卫测试还验证了清晰的阻断信息，因此自洽性充分。依赖安装使用 frozen lockfile，运行要求也具体，但完整登录和代理流程依赖外部 Realmroot、Enbor、GitHub 与 Cloudflare 服务，材料没有展示服务不可用时的降级、重试上限或恢复策略。已见 401、not-found、升级阻断及全部阻塞任务 ID 等失败行为，但缺少覆盖普通 API、流连接、外部适配器和部署失败的统一错误消息规范。
材料清楚区分 worker、maintainer、单任务操作和多任务规划四种代理角色，并覆盖创建、认领、执行、观察、审核、依赖和公开视图等场景。Agent Kanban、Enbor 与 Realmroot 的职责边界明确；生命周期、授权审查规则以及技能的自动或显式触发方式均有具体说明，因此场景、边界和触发精度证据充分。环境适配扣分是因为部署明显绑定 Cloudflare Worker、D1、Wrangler 及 Realmroot/Enbor，虽然本地启动要求写得清楚，却未展示替代数据库、离线模式或其他云环境的适配路径。
README 提供清晰的文档索引、目录职责、架构分层、生命周期、开发命令、部署流程和贡献入口；安装步骤、版本要求、密钥格式及远程迁移顺序足够具体。产品名称、资源命名和命令形式在材料中稳定，许可证全文也与 package 元数据和徽章一致，故这些项目可给满分。扣分在于没有独立 FAQ 或丰富的故障排查示例；已知限制主要散见于外部服务要求、Cloudflare 约束和 v1→v2 迁移门，未形成完整限制清单；标签发布会自动生成 changelog，但未提供实际 changelog、兼容性政策或版本演进记录；作者、贡献指南和发布路径可见，但维护团队、支持渠道、响应承诺和安全报告责任并不完整。
资源式命令、JSON 输出、实时事件流、OpenAPI 作为接口真源、任务依赖、审查门和执行来源绑定，使产物具备较强的代理可用性。相较普通人类看板，将代理身份、认领、运行绑定、任务通信与独立审核纳入数据模型，展示了明确的增量价值。扣分在成本收益：系统要求 Node 24、pnpm、Wrangler、D1，以及多个外部身份和执行服务及相应密钥；材料未量化部署成本、运维负担、吞吐限制或相对于较简单工作流的收益边界。
README 把产品行为指向 spec/*.feature，并说明测试使用 [spec: capability/scenario] 标记；所给 SSE 与升级测试确实包含这种标记，CI 又按集成、迁移、适配器、核心等套件执行，形成了较强的声明—规范—测试—CI 交叉印证。仓储隔离、认证和迁移阻断也有具体测试佐证，因此可追踪性和跨来源印证充分。扣分在事实与推断分离：诸如“Verified execution provenance”“safe lifecycle transitions”和“source of truth”等表述较为确定，但提供的代码片段没有逐项证明其实现或安全属性；静态材料也不能独立确认徽章状态、线上服务或测试实际通过。
- 这是低置信度静态审查；没有执行构建、测试、迁移、部署或外部服务集成，不能把 CI 配置和测试文件等同于测试已通过。
- 在采用前核查依赖锁文件和漏洞扫描结果，并验证 Realmroot、Enbor、GitHub 与 Cloudflare 的可用性、权限范围、数据保留及故障恢复行为。
- 重点验证删除 Board/Task 等破坏性操作是否要求确认、是否级联删除，以及是否存在软删除、备份和恢复路径。
- 确认公开 Board、SSE、任务 Notes、执行会话和 GitHub 集成不会跨租户泄露敏感数据，并审查密钥轮换、日志脱敏与撤销流程。
- FSL-1.1-ALv2 在转换日前限制竞争性商业用途；应根据具体版本发布日期确认允许用途及转为 Apache-2.0 的日期。
这个 Agent 能做什么，适合哪些场景？
Agent Kanban 是面向自主软件智能体的任务看板，将智能体、任务认领、执行来源、依赖关系和审核流程作为核心产品模型。它由 React 与 Vite 单页应用、Hono HTTP API、领域规则、应用用例以及 D1 和外部服务适配器组成，并以单个 Cloudflare Worker 部署。智能体通过 Realmroot Toolbox 和实时 OpenAPI 契约发现并操作看板、任务、认领记录与备注；Enbor 则负责项目、运行环境、调度和会话。任务从分配、认领、执行、提交审核到完成或驳回均有明确状态约束，且受托智能体不能审核自己的提交。系统还提供任务依赖校验、已签名会话绑定、实时活动流、只读公开看板以及 GitHub App 集成。它适合已经采用或愿意采用 Cloudflare、Realmroot 和 Enbor 体系，并希望减少人工盯守但保留最终审核权的软件团队。
用户或智能体创建 Board 和 Task，把任务分配给 Agent，并可关联租户内的 Repository。受派智能体从已验证的 Enbor Session 创建 Task Claim，执行工作、记录 Note，并将任务连同 pullRequestUrl 等结果更新为 in-review。另一名获授权参与者随后接受或驳回 Review Submission；系统禁止受派者审核自己的提交。任务可声明对其他任务的依赖，系统会拒绝循环依赖和跨租户关系。Agent Kanban 通过 Realmroot 的 OIDC、Agent actor chain、Toolbox 访问与委托令牌交换验证操作，并记录绑定中的具体运行时和 Enbor Session。浏览器可以观察任务活动和绑定会话，但不会因此获得运行时控制；公开看板则提供与认证工作区隔离的只读视图。应用通过 Hono API 和发布的 OpenAPI 文档暴露资源、模式、权限范围、分页与生成命令，并将状态持久化到 Cloudflare D1。
- 维护多个代码仓库的平台团队，用看板把任务分派给不同软件智能体，并集中观察任务状态、会话来源和仓库上下文。
- 要求职责分离的工程团队，让智能体提交工作后由另一名获授权参与者接受或驳回，避免执行者自行批准结果。
- 需要编排多步骤改动的项目负责人，通过任务依赖关系控制执行顺序，并由系统拒绝循环依赖和跨租户依赖。
- 希望降低人工盯守成本但不放弃治理权的团队，让智能体通过 Toolbox 和 OpenAPI 自主认领、更新和等待任务，同时保留人工审核门禁。
- 需要向外部观察者展示进展的项目，发布只读公开看板，而不暴露已认证工作区或赋予运行时控制权。
- 已经运行 Realmroot、Enbor 和 Cloudflare 基础设施的组织，将身份、执行会话与任务协调连接成一套可审计流程。
这个 Agent 有哪些优点和局限？
- 将 Agent 作为一等参与者，任务认领、执行来源、依赖、备注、通信和审核不是附加约定，而是领域模型的一部分。
- 内建职责分离的审核门禁：提交必须由受派者之外的获授权参与者接受或驳回。
- Task Claim 绑定已验证的具体运行时和 Enbor Session，为执行提供可检查的来源记录。
- 实时 OpenAPI 契约和 Realmroot Toolbox 提供机器可发现的资源、模式、权限范围、分页及幂等操作。
- 同时支持认证工作区内的实时观察和隔离的只读公开看板。
- React 前端、Hono API 与 D1 持久层作为单个 Cloudflare Worker 交付，部署边界清晰。
- 核心身份与执行流程依赖 Realmroot 和 Enbor，完整本地体验不能只靠仓库本身运行。
- 部署绑定 Cloudflare Workers、D1 和 Wrangler；迁移到其他云或数据库没有文档化的即用路径。
- 运行环境要求 Node.js 24 或更高版本和 pnpm 10，可能高于现有项目的工具链版本。
- v2 迁移会在任何 v1 任务仍处于 todo、in_progress 或 in_review 时停止，需要先人工处理旧状态。
- GitHub App 流程需要额外 webhook 密钥和私钥，完整认证还需要多项 OIDC 与签名密钥配置。
- 许可证是 Functional Source License 1.1，并在每次发布两年后转换为 Apache 2.0；采用者需要核对其许可用途及竞争性使用条款。
如何安装或部署这个 Agent？
前置条件是 Node.js 24 或更高版本、pnpm 10，以及作为项目依赖安装的 Wrangler 4。执行：
git clone https://github.com/saltbo/agent-kanban.git
cd agent-kanban
pnpm install --frozen-lockfile
pnpm db:migrate
pnpm dev开发服务器运行于 http://localhost:6265。完整登录、Agent、Machine、Session 和 GitHub 流程还需要可访问的 Realmroot 与 Enbor 服务，并在 .dev.vars 中配置 OIDC_WEB_CLIENT_SECRET、OIDC_SERVICE_CLIENT_SECRET、AK_SESSION_ENCRYPTION_KEY 和 AK_SIGNING_KEY。后两个值必须是规范 Base64 编码且解码后恰好为 32 字节。GitHub App 开发还需 GITHUB_APP_WEBHOOK_SECRET 和 GITHUB_APP_PRIVATE_KEY；不得提交 .dev.vars。远程部署前配置 wrangler.toml 所述绑定和密钥，然后运行 pnpm db:migrate:remote 与 pnpm deploy。
如何使用这个 Agent？
安装 Realmroot Toolbox 0.5.0 或更高版本并完成所需身份验证后，可先列出看板：
realmroot toolbox get agent-kanban/boards --json按看板查询任务：
realmroot toolbox get 'agent-kanban/tasks?boardId=<board-id>' --json使用 JSON 文件创建任务：
realmroot toolbox post agent-kanban/tasks --content-type application/json @task.json --json受派智能体认领任务：
realmroot toolbox post agent-kanban/tasks/<task-id>/claims --json读取任务及关联内容：
realmroot toolbox get agent-kanban/tasks/<task-id> --include --json完成工作后提交审核状态和拉取请求地址：
realmroot toolbox patch agent-kanban/tasks/<task-id> --content-type application/merge-patch+json '{"status":"in-review","pullRequestUrl":"https://github.com/owner/repo/pull/123"}' --json等待指定状态：
realmroot toolbox agent-kanban task wait <task-id> in-review --wait-seconds 25 --json普通资源使用通用的动词优先命令；task wait 是唯一生成的资源优先便捷命令。Toolbox 会生成幂等键，并在瞬时重试时复用它。
这个 Agent 与同类方案有什么区别？
与传统项目管理看板相比，Agent Kanban 不仅展示人工维护的卡片，还把智能体身份、任务认领、已验证执行会话、依赖校验和独立审核写入系统规则。与单一聊天窗口相比，它面向跨仓库的持久工作，提供明确所有权、生命周期状态、可观察执行和可追踪审核；代价是必须接入 Realmroot、Enbor 与 Cloudflare 运行栈。
常见问题
能否只在本机运行完整系统？
pnpm dev 运行，但完整登录、Agent、Machine、Session 与 GitHub 流程还需要已配置的 Realmroot、Enbor 及相应密钥。