AI Agent 任务管理：谁派活，谁验收？

写给人的任务可以只有三个字。「修登录 bug」能成立，因为对方会追问你是什么意思。写给 Agent 的任务借不到这段对话，差异会表现为白跑的执行、没人审查的结果，以及一块状态列已经不再代表大家以为的含义的看板。

AI Agent 任务管理是一套纪律：写清工作、完成指派，并由人验收 Agent 执行的结果。本文讲决定这套方法能否成立的三个部分：一个 Agent 可执行的任务包含什么、指派如何拆给人和 Agent，以及一旦有了运行，状态和审查实际会怎样运作。示例沿用 HiFox 的实现，同一套规则也适用于任何把 Agent 当执行者的系统。

太长不看

Agent 可执行的任务会写清结果、范围、上下文和完成后的审查方式。指派有两个位置：人负责结果，一个 Agent 或小组负责执行。状态分类驱动执行，所以停放的待办状态会阻止运行，移出待办可以启动运行；已取消和重复状态会停止活跃运行，完成状态则不会。任务状态和 Agent 运行状态彼此独立，审查是一个具名状态，必须真正到达某个人，而不是某人打算之后再看。

Agent 可执行的任务包含什么

描述就是接口。Agent 对你意图的全部理解都来自它，加上任务字段里携带的内容。

有用的任务会写结果，而不是只写主题；描述还要补上新来的人或 Agent 继续工作所需的信息：

• 为什么这项工作重要；
• 范围内和范围外分别是什么；
• 相关文件、链接、示例或观察到的行为；
• 约束和已经做出的决定；
• 完成后将如何审查。

最后一条比前面所有条加起来都更重要。它决定了结果是你两分钟就能验收，还是必须反向拆解才知道发生了什么。先从小处写，随着调查再补充；任务描述允许变好。

其余信息由字段承载：类型、状态、优先级、日期、标签，以及用于规划上下文的专项或冲刺。为 Agent 组装的一次运行可以包含标题和描述、当前状态和优先级、空间与冲刺上下文、近期评论（包括触发这次运行的评论）、Agent 的指令和技能、仓库、环境以及运行设置。描述太薄，再强的模型也补不回来。

指派：两个位置，不是一个

Agent 任务管理里最常见的设计错误，是只设一个负责人字段。

要把两者分开。人是为了责任而指派，一个空间可以允许一个或多个人。Agent 或小组进入执行位置，而且保持单选。一个任务可以同时有两者；改人员集合不会改执行者，指派 Agent 也不会替换人员。

回报是：没有任何任务真正归一个机器人所有。结果需要决定时，总有一个名字挂着；Agent 做错时，审查对话有一个参与者。我们关于 Claude Code 专项管理的说明，展示的是同一个任务从 issue 到合并的同一套拆分。

小组进入同一个执行位置，执行以队长为先：队长 Agent 启动，读取上下文，再按需要拉成员进来。范围清楚的工作用一个 Agent；需要协调时用小组。

状态：控制执行的那部分

一旦 Agent 参与进来，状态就不再是装饰。每个可见状态都属于一个分类，分类承载系统含义。

有两个后果值得记住。待办是真正的暂存区：准备好任务、挂上 Agent，然后什么都不发生，直到你把它移走。标记完成也不等于停止运行，所以真正想停掉运行时要取消。

第二条规则是生命周期状态和 Agent 工作状态彼此独立。任务可以停在已开始状态，同时 Agent 正在工作、等待人的回复、等待人审，或者报告错误。排队、已派发、运行中、已完成、失败和已取消这些运行状态描述执行进度，不会自动移动任务。把两者混为一谈，看板看起来就会很健康，而三个结果躺在那里没人读。

审查：把交接说清楚

Agent 结束运行后只会落在两个有用位置：带着结果，或者带着问题。两者都需要到达某个人。

等待人的回复、等待审查，以及失败或阻塞的工作，都是注意力信号。它们进入个人队列；在 HiFox 里就是 Agent 收件箱，责任人可以在那里打开任务、在上下文中回答、审查结果，或者决定重试、重新指派。

评论是任务上持久保留的对话。用它补充新上下文、审查发现和决定；把稳定的目标和验收标准留在描述里，让当前要求始终容易找到。在已绑定可用 Agent 负责人的任务上，成员评论可以把另一次运行排入队列，这正是为什么审查反馈能继续推进工作，而不是另起一个流程。提及会改变这一点：提到某个人或使用全员提及本身不会启动 Agent 运行；评论提到了其他目标但没有提到执行负责人，默认运行会被抑制。

验收前要读证据，而不只是 diff。执行日志会显示为什么排队、何时开始和结束、工具调用与 Runtime 事件、触发来源以及失败细节。验收是人判断结果是否正确，任何运行状态都替你做不了这个判断。想把这些状态串起来，而不是手工拼装，可以从 HiFox 开始。

一份值得照抄的任务模板

会写 Agent 任务的团队，最后往往会收敛到同一副骨架。把它存成片段，填进去；整个过程大约三分钟，能省掉一次白跑。

结果：<这件事完成后，什么为真>

上下文：
- 为什么现在要做
- 观察到的行为，附准确错误或复现步骤
- 相关文件、链接或示例

范围：
- 包含：<你想要的改动>
- 不包含：<Agent 不应碰的相邻工作>

约束：
- 已经做出的决定、要遵循的约定、不能改的东西

审查：
- 完成情况将如何检查，由谁检查

「不包含」这一行最快体现价值。拿到狭窄目标却没有边界的 Agent，往往会顺手改你没问的东西，而每一次顺手都要花审查时间。提前写明别碰什么，比事后审查它碰了什么更便宜。

五个值得避开的错误

• 只设一个负责人字段。责任和执行塌缩在一起，归属感也随之消失。
• 把一次完成的运行当成完成的结果。运行结束并不说明改动是否正确。
• 条件反射地重试失败运行。先打开日志。看起来相似的厂商错误，经常需要相反的处理。
• 让审查堆积。未审查的 Agent 结果是一种债，累积速度比未合并的 pull request 还快。
• 把任务写给已经知道背景的人。如果验收标准只在你的脑子里，Agent 就只能猜。

常见问题

Agent 能改任务状态吗？在限制之内可以。任务类型的工作流会约束可用状态，所以 Agent 只能选择该工作流允许的状态。

运行活跃时我评论会发生什么？符合条件的评论会排到下一个运行周期，而不是启动一个并行的重复运行；快速连续的评论会合并，避免产生重复的待处理运行。

Agent 工作需要单独的任务类型吗？通常不需要。只有当工作需要明显不同的字段集或工作流时才新建类型；只需要轻量分类时用标签。

这和普通专项管理有什么不同？基本构件一样，严格程度不一样。我们关于 AI Agent 专项管理的说明，讲了当执行者无法在走廊里追问时，每个基本构件会发生什么变化。