运行中任务列≠执行中：Agent任务系统的证据分离设计

任务看板需要一个 running 列来支撑工作流协作——有人认领了卡片，或者团队想直观看到进度。但看板列只是对流程的声明，而不是流程仍然活跃的证据。这个区分在 agent 系统中尤其关键。

任务在运行时会话结束后可能依然停留在 running 列；agent 正在任务线程上活跃，而卡片还显示 pending；人类也可以出于规划目的手动拖动卡片。如果仪表盘把上述任何一种情况都解读为"工作确实在进行"，它就在报告一种自己并未获得的置信度。

APX 的设计将这两个问题拆开：任务工作流记录开放任务被放入的列，而执行视图则回答另一个问题——现在存在什么证据？

一个标签，多种现实

假设一张名为"Review the authentication flow"的任务卡片停在 running 列。至少有四种可能的现实：

• 当前有 agent turn 正在该任务线程上工作
• 一个被链接的编码运行时会话仍然处于打开状态
• 被链接的会话已经完成或失败
• 没有任何关联活动；卡片是之前被移动的，一直没再变过

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

这正是 APX 不把状态字段当作存活信号的原因。它的任务执行视图会组合具体的证据来源：当前正在运行的 agent turn、从任务评论中显式链接的运行时会话，以及最近的活动（比如评论，或会话的开始/结束）。当没有任何证据存活、但工作流列显示 running 时，结论是 not_verified。

这个措辞刻意不如一个绿色的圆点让人安心。它告诉任务所有者系统究竟知道什么，而不假装知道更多。

not_verified 是一种刻意保守的状态语义。在监控与可观测性系统中，通常用三态模型替代二元的"健康/故障"：健康、故障、未知。把"未知"折叠进"健康"会产生虚假安心，把"未知"折叠进"故障"又会引发误报与不必要的干预。not_verified 属于第三种——它不声称任务正常，也不声称任务已经死亡，只声明系统目前掌握的证据不足以支撑任何断言。这种设计在分布式系统中被称为"fail silent vs fail loud"的权衡：一个卡在 running 列的陈旧卡片如果没有被识别为未验证，后续 agent 可能对它重复启动工作，或者人类审查者会误以为有同事正在处理而跳过它。not_verified 把这个模糊地带显式化，使自动化系统可以将它路由到人工确认或降级处理，而不是猜测。

报告进度前先检查任务

对 agent 而言，实践规则很简单：当标题或看板列不足以说明问题时，使用 get_task。返回结果包含一个 execution 对象，将工作流信息与运行时信息分开。这样一份有用的进度报告就能区分以下几种情况：

Workflow: running
Execution: working
Evidence: linked runtime session is open

Workflow: running
Execution: not verified
Evidence: no live task turn or linked open session

Workflow: in_review
Execution: ended
Evidence: latest linked session finished

这些不是措辞上的装饰性调整，它们导向不同的后续动作。"working"可能意味着等待或检查活跃会话；"not verified"意味着去检查任务线程、询问负责人，或者先搞清楚发生了什么再移动卡片；"ended"意味着去读结果并审查它——并不等于自动关闭任务。

尤其要注意，进程成功退出并不等于业务审批通过。运行时可以以退出码 0 结束，但产出的可能只是一份草稿、一次不完整的调查，或一个需要人工审查的结果。APX 将执行证据与任务关闭保持分离，从而避免 agent 悄悄地把"命令执行完毕"转译成"工作已被接受"。

为什么链接必须显式

APX 通过携带会话身份与路径的任务评论来找到某个任务相关的运行时会话。这比扫描所有 agent 历史记录要窄得多，既能防止不相关的会话让任务看起来活跃，也能让证据附着在审查者预期找到它的卡片上。

同样的边界也解释了 APC 的角色。APC 是可移植的项目上下文层：AGENTS.md、agent 定义、技能以及持久化规则随项目一起流转。APX 则是日常使用的运行时与工具层：它把本地会话、任务活动和执行证据放在这个可移植契约之外。

一条可移植的任务指令可以说明成功需要满足什么条件，但只有运行时才能说明某个具体会话是否仍然存活。

AGENTS.md 是一种面向 agent 的项目上下文约定文件，通常放在仓库根目录，用来描述项目结构、构建命令、测试方式、代码风格约束以及 agent 应该遵守的操作规则。它类似于为人类贡献者准备的 CONTRIBUTING.md，但读者是 agent。APX 与 APC 的分层思路借鉴了"配置即代码"中声明与状态分离的原则：APC 提供可移植、可版本控制、随仓库流转的指令契约，它描述"成功应该是什么样"；APX 则处理"此刻实际发生了什么"这类瞬时、本地、不可移植的运行时事实。把两者混在一起会导致指令文件被运行时噪声污染，或者运行时证据在跨环境迁移时丢失。

更好的看板提问方式

当你看到一张 running 的任务卡片时，不要只问"它在哪一列？"，而要问"有什么证据说明它现在正在运行？"

这个小小的分离会带来更冷静的自动化：避免对活跃工作重复启动，在陈旧卡片变成虚假安心之前就将其暴露出来，并且把审批权留在它应该在的地方——对实际结果的审查。

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