Human task board for my agents 这个名字看起来像是一个小工具但它对应的是一类真实问题AI Agent 自动化执行任务时如何在关键节点引入人类判断。无论是让 Agent 写代码、处理工单还是执行数据分析完全放权都很危险。缺少人工审批、人工反馈、中断机制Agent 一旦走错方向错误会被放大。这里要实现的就是一个面向 Agent 的“人类任务看板”Agent 通过 API 上报任务和请求人类通过网页看板查看、批准、拒绝、中断或补充信息Agent 再通过轮询拿到最新指令继续执行。落地方案使用 Node.js Express SQLite前端用原生 HTML/JavaScript通过 Server-Sent Events 做状态推送。后面会完整给出数据模型、API 设计、后端代码、看板页面、Agent 接入示例以及常见故障的排查链路。1. 先理解 Human task board 解决什么问题1.1 为什么 Agent 需要人工介入在真实的 Agent 工作流里单纯把任务抛给 Agent 然后等待结果往往不能直接上线。Agent 能连续执行多步操作但它在判断目标是否合理、是否有权限、是否应该花这笔钱、生成的方案是否可接受等问题上仍然缺少人类掌握的业务上下文。比如一个自动化运维 Agent 发现磁盘占用率过高它可以清理日志但清理哪些目录、保留几天、是否影响正在运行的服务这些决策需要人来确认。又比如一个 AI 编程 Agent 准备批量修改代码改动范围大应该先让人类审核变更计划而不是直接提交。因此Agent 工作流里需要一类“人类介入点”。这些介入点不是打断流程的故障而是流程的正式组成部分。Agent 执行到介入点时应该暂停、提交上下文、等待人类决定然后根据决定继续、修改或停止。这种设计模式通常被称为 human-in-the-loop人在回路。它的价值不是降低自动化率而是让自动化在可接受的边界内运行。Human task board for my agents 这个项目本质上就是把这类介入点集中到一个可操作的界面上人类不用直接读 Agent 日志不用在多个终端之间切换打开看板就能看到所有 Agent 需要决策的任务。1.2 Human task board 的职责和核心概念Human task board 要承担的职责和普通项目管理看板并不一样。普通看板关注“任务分配给谁、做到哪一步”人类任务看板关注的是“Agent 需要人类做什么、人类是否已给出决定、Agent 是否已收到决定”。核心概念包括这几个TaskAgent 通过 API 创建的一个工作单元记录标题、描述、来源 Agent、优先级、当前状态。Review任务创建后进入待审批状态人类批准或拒绝后 Agent 才能继续。Interrupt执行过程中的中断信号人类可以随时要求 Agent 暂停或改变方向。Request InputAgent 在运行中请求人类补充必要信息例如确认某个参数、选择方案 A 还是方案 B。Event所有状态变更、审批动作、中断动作都记录为事件方便回溯。这五个概念构成看板的基础模型。代码实现时任务表保存最新状态事件表保存完整变化历史。二者配合既能应对看板页面的实时展示也能支撑审计排查。1.3 与普通任务看板的关键差异很多团队用过 Trello、Jira 或自建看板但把“Human task board for Agent”直接套到通用看板工具上很快就会发现问题通用看板没有 Agent API没有轮询指令接口也没有自动状态流转。差异可以用一张表来说明维度普通任务看板Human task board for my agents任务创建者人类手动创建Agent 通过 API 自动创建任务执行者人类Agent 进程状态流转人工拖拽或手动更新API 事件驱动 人工审批组合人工介入方式分配、评论、拖动审批、拒绝、中断、补充信息是否需要 API通常不需要必须Agent 需要编程访问实时性要求较低较高Agent 等待指令时需要及时感知审计要求一般强需要记录每一步事件这张表也说明了设计上的取舍如果只是做一个给人类看的静态列表那没有意义必须同时提供“Agent 读取人工指令”的通道才叫面向 Agent 的 Human task board。这也是后面 API 设计要分成 Agent 侧和人类侧的根本原因。2. 技术选型与数据模型设计2.1 选型原则轻量、易接入、可实时选型时没有追求复杂框架。第一看板是基础工具要能快速跑起来后端使用 Express 就能满足。第二Agent 接入端要用 HTTP JSON因为几乎所有 Agent 框架都支持。第三人类页面要能实时看到状态变化这里选择 Server-Sent EventsSSE。SSE 比 WebSocket 更简单并且场景是“服务端向浏览器单向推送状态”不需要浏览器向服务端实时发消息因为人类操作本身通过普通 POST 提交。数据库选择 SQLite本地文件存储示例项目不需要单独安装数据库服务。生产环境如果要多人并发、高写入、多实例部署再替换为 PostgreSQL 或 MySQL接口层不需要大改。注意示例代码为演示方便任务状态全部存在 SQLite但 SSE 长连接状态放在内存中进程重启后浏览器需要重新连接。生产环境要用 Redis 做事件分发或使用成熟的消息队列。2.2 数据模型任务表与事件表最小模型只需要两张表。任务表保存每个任务的当前状态和最新人工指令事件表保存每次状态变化和操作记录。CREATE TABLE tasks ( id TEXT PRIMARY KEY, title TEXT NOT NULL, description TEXT, agent_name TEXT NOT NULL, priority TEXT DEFAULT normal, status TEXT NOT NULL DEFAULT pending_review, human_instruction TEXT, instruction_payload TEXT, created_at TEXT NOT NULL, updated_at TEXT NOT NULL ); CREATE TABLE events ( id INTEGER PRIMARY KEY AUTOINCREMENT, task_id TEXT NOT NULL, event_type TEXT NOT NULL, payload TEXT, created_at TEXT NOT NULL );状态机设计如下pending_reviewAgent 创建任务后等待人类审批。approved人类批准Agent 继续执行。rejected人类拒绝Agent 不应继续。runningAgent 开始执行。waiting_humanAgent 执行中请求人工输入等待补充。interrupted人类发出中断Agent 应停止或进入人工干预流程。completedAgent 正常结束。failedAgent 执行失败。这里有一个容易忽略的点approved和running是分开的。Agent 轮询到 approved 后再启动执行避免出现“人类还没有批准Agent 已经开始跑”的竞态。如果 Agent 在批准前就运行审批就失去了意义。human_instruction字段保存最新一条人工指令approve、reject、interrupt、respond。Agent 轮询这个字段获取决定。instruction_payload保存额外内容比如 respond 时人类填写的文本。2.3 API 设计Agent 侧与人类侧分离Agent 侧接口方法和路径功能请求方POST /api/agent/tasks创建任务AgentPATCH /api/agent/tasks/:id/status更新任务状态AgentGET /api/agent/tasks/:id/instruction获取人工指令AgentGET /api/agent/tasks/:id/events获取任务事件Agent人类侧接口| 方法和路径 | 功能 |