看板上有一列叫 running，几乎成了标配。有人接了卡，或者团队想看到"进行中"，这一列就有用。但列本身只是对流程的一种声明，不是流程还活着的证据。

这个区别在 agent 系统里会被放大。一张卡可以停在 running，而对应的运行时会话早就结束了；反过来，agent 正在任务线程上干活，卡片却还写着 pending；人也可能出于排期考虑手动挪卡。如果仪表盘把上面任何一种情况都翻译成"工作肯定在进行"，那它报出的信心是它没挣来的。

APX 把这两个问题拆开了。任务工作流记录的是"这张打开的卡被放进了哪一列"，而它的执行视图问的是另一个问题：现在存在什么证据？

一个标签，四种现实

假设有一张卡叫"Review the authentication flow"，正躺在 running 里。至少有四种可能：

  • 一个 agent 回合此刻正在任务线程上工作。
  • 一个被关联的编码运行时会话仍然开着。
  • 被关联的会话已经结束或失败。
  • 没有任何关联的东西在活动，列是早先挪的，之后再没动过。

只有前两种支持"现在正在工作"。第三种支持的是"执行已结束"。第四种支持的是"未验证"，而不是"正在成功运行"。

这就是 APX 不把状态字段当作存活信号的原因。它的任务执行视图把几类具体证据合在一起看：当前正在运行的 agent 回合、从任务评论里显式关联出来的运行时会话，以及最近的活动，比如一条评论或会话的开始/结束。当没有任何证据还活着、而工作流列却写着 running 时，结论是 not_verified。

这个说法故意比一个绿点更让人不舒服。它告诉负责人系统知道什么，而不假装知道更多。

报告进度前，先检查任务

对 agent 来说，实用规则很简单：当标题或看板列不够用时，用 get_task。返回里带一个 execution 对象，把工作流信息和运行时信息分开。这样一份有用的进度报告就能区分下面几种情况：

  • 工作流 running，执行 working，证据是关联的运行时会话开着。
  • 工作流 running，执行 not verified，证据是没有活着的任务回合，也没有关联的打开会话。
  • 工作流 in_review，执行 ended，证据是最近关联的会话已结束。

这些不是措辞上的修饰。它们指向不同的下一步动作。"working"可能意味着等一等，或者去看看那个活着的会话。"not verified"意味着去查任务线程、问负责人，或者先搞清楚发生了什么再挪卡。"ended"意味着去读结果并评审，它不等于自动关掉任务。

尤其要注意，进程成功退出不等于业务批准。一个运行时可以在产出一份草稿、一次不完整的排查，或者一个还需要人工评审的结果之后，以退出码零结束。APX 把执行证据和任务关闭分开，这样 agent 就不能悄悄把"命令跑完了"变成"工作被接受了"。

为什么关联必须是显式的

APX 是通过带有会话身份和路径的任务评论，来找到一张任务相关的运行时会话的。这比扫描全部 agent 历史要窄。它能防止一个不相干的会话让任务看起来还在活动，也让证据留在评审者预期能找到它的那张卡上。

同样的边界也解释了 APC 的角色。APC 是可移植的项目上下文层：AGENTS.md、agent 定义、技能和长期规则跟着项目走。APX 是日常使用的运行时和工具层：它把本地会话、任务活动和执行证据放在那份可移植契约之外。

一份可移植的任务指令可以说清楚成功需要什么。但只有运行时才能说，某个具体会话是否还活着。

看板该问的更好的问题

当你看到一张卡在 running 里，别只问"它在哪一列"，要问"有什么证据说明它现在在跑"。

这一小步分离会带来更冷静的自动化。它避免对还活着的工作重复启动，在过期的卡变成虚假安慰之前把它们暴露出来，并且把批准留在它该在的地方：对实际结果的评审。

看板跟踪工作流，证据跟踪执行。可靠的 agent 运维，两者都需要。