过去，Backlog 只是你和几个团队成员从中领取任务的列表。你阅读顶部的条目，理解它，然后完成它。分类分流（Triage）很快，因为唯一的问题是“谁有时间？”现在，其中一些条目可以由 coding agent 代替人工来领取，原本平静的队列突然变成了产生昂贵小失误的源头：一个 agent 开始执行一个还没写完的任务，两个 agent 抓取了重复重叠的工作，而“已完成（Done）”列则填满了根本没人要求的产出。
问题不在于 agent，而在于原本为人类设计的 Backlog 默默改变了它的职责。它不再仅仅是一个待办事项列表，而是变成了一个能够直接触发执行的调度队列（dispatch queue）。一旦列表中的条目能够触发实际工作，移动任务和确定责任人的时刻就具备了前所未有的后果。
这正是 HiFox 所在的层级。你可能已经拥有了 coding agent；HiFox 通过赋予 Backlog 共享的语义，将它们凝聚成一个团队。Task（任务）是主要的工作单元，Backlog 是未提交工作等待的地方，而 Triage 是一个专门的入口接收队列，新进条目会在其中等待决策。本文将详细探讨如何对人类与 Agent 混合的 Backlog 进行 Triage（分类分流），避免这些队列沦为混乱，最后提供了一份你可以立即使用的核对清单。
当 Agent 能够执行工作时，Backlog 和 Triage 意味着什么
这里有两个核心定义非常关键，我们需要准确界定它们。
Backlog 是未提交工作的集合：即已经存在但尚未有人决定开始的任务。Triage 是对新条目或模糊条目做出的入口决策：接受、拒绝、标记为重复或暂缓处理。人类一直都在非正式地做这两件事。变化在于，在人与 Agent 协作的团队中，Triage 的结果现在包含了“由哪个 Agent 运行此任务”，而提交任务的操作本身就可以启动一次运行（Run）。
这是最容易让人栽跟头的地方：在 Backlog 中给任务分配一个 Agent 并不会启动它。Backlog 是一个暂存区，工作在执行前在这里进行准备。只有当任务离开 Backlog 变为可工作的准备就绪状态，且有可用的 Computer 和 Runtime 时，运行才会真正开始。因此，“指派 Agent”和“启动 Agent”是两个独立事件，Backlog 状态作为门控（gate）介于两者之间。
还有一个值得明确指出的界限：Agent 不会维护私有的 Backlog。不存在一个让 Agent 自行处理的隐藏队列。Agent 所触及的每一个条目都记录在共享看板上，这也是让 Triage 成为可实施流程而非盲目猜测的原因。
自建（DIY）方案在何处遭遇瓶颈
一张电子表格加上看板和几个终端窗口，对于单人和两个 Agent 来说运行得很好。但在一些可以预测的节点上，这种自建方案会停止扩展，并且每一个节点都会表现为具体的失效模式。
状态列对 Agent 没有任何意义。 在手动看板上，将卡片移动到“进行中（In Progress）”只是给队友的一个通知，不会触发任何执行。因此看板与实际工作脱节：卡片显示“进行中”，而 Agent 一小时前就已经完成了；或者卡片显示“待办（To Do）”，但因为有人在终端里启动了它，Agent 已经提交了三次 Commit。没人再信任看板，因此也没人使用它。
Triage 决策只停留在某个人的脑子里。 负责处理新请求的人记得某个 Bug 已经被报告过、某个功能在上一季度被拒绝过，或者某个任务需要先有设计输入。当那个人休假或不在时，重复任务就会被创建，Agent 就会开始执行本应在入口处拒绝的工作。队列本身没有记忆。
指派和范围界定在仓促间同时做出。 当人类领取任务并提出疑问时，模糊的范围是可以接受的。但 Agent 不会暂停询问；它会根据你给它的任何内容直接运行，并返回一个自信但错误的结果。不严谨的 Triage 的成本从“队友短暂地感到困惑”变成了“Agent 在错误的事情上白白消耗了一次运行和审核周期”。
逐步对混合 Backlog 进行 Triage
以下是保持人类-Agent 混合 Backlog 可靠可信的具体步骤。每一步都指出了它所防止的失效场景。
1. 在动 Backlog 之前先清空入口队列。 新请求会落入 Triage 中，而不是直接进入 Backlog。通过四种决策之一处理每个条目：接受（accept）、拒绝（decline）、标记重复（mark duplicate）或暂缓（snooze）。Triage 是一个入口队列，既不是预设过滤器，也不是表单构建器，因此决策是明确且被记录的。防范的失效： 被拒绝或重复的工作悄悄变成真实任务，随后被 Agent 领取。
2. 在任务具备交由 Agent 执行资格前对其进行雕琢（Shape）。 被接受的条目会成为一个 Task，但在你编写验收标准（Acceptance Criteria）、关联代码仓库并注明约束条件时，它依然停留在 Backlog 中。这是人们在时间紧迫时容易跳过的步骤。防范的失效： Agent 仅凭一行标题运行，返回的结果字面上符合描述但完全脱离了真实意图。
3. 决定负责人，并将“选择哪个 Agent”视为真正的决策。 有些任务需要人类处理。有些需要 Agent，而在不同的 Agent 之间，选择哪一个取决于任务性质：重构、编写测试和更新文档并不是同一种工作。深思熟虑地进行路由分发，而不是默认选择任何处于空闲状态的 Agent。我们的 Coding Agent 路由选择指南介绍了如何做出这一决策。防范的失效： 不合适的 Runtime 费劲地处理一项它根本不擅长的任务。
4. 在真正准备就绪前，将其保留在 Backlog 中。 这是控制关口。一个任务可以被完全指派，但依然停留在 Backlog 中而不启动运行。善用这一机制。在工作范围明确且你确实希望工作开始之前，不要将其移出。防范的失效： 因为有人将卡片拖到了错误的列中，导致一个只写了一半的任务启动了运行。
5. 提交（Commit）任务，启动运行。 将任务移至 Ready 状态，或者将其拉入 Sprint 中。当带指派 Agent 的任务离开 Backlog，且相应的 Computer 和 Runtime 可用时，执行即刻开始。此时，状态更改与实际工作合二为一，这正是核心所在。
对于按周期运行的团队，人机协作团队的 Sprint 规划指南展示了相同的 Commit 步骤如何对时间盒（Time box）而非单个任务界定范围。
Backlog 状态成为执行关口
心态上的转变在于：在人类看板上，状态是描述现实的标签。而在人机协作看板上，状态是改变现实的杠杆。将任务移出 Backlog 就是启动 Agent 的操作，因此你的 Triage 规范如今成了你的安全机制。
这个关口也是“人类-Agent 契约”所在之处。Agent 负责调研、执行、测试和汇报；人类负责决定什么进入 Backlog、什么被提交（Commit）以及什么发布交付。自动化止于需要团队主观判断的地方。Plan 视图将 Backlog、Sprint 和 Project 集中于一处，使得提交决策清晰可见，而不是被埋在终端窗口中；同时，执行过程、阻碍因素、结果和评审都会沉淀回 Task，而不是散落于私有会话中。
这就是为什么在引入 Agent 后，Backlog 的整洁规范变得更加重要，而非相反。混乱的人类 Backlog 只是杂乱无章；而混乱的 Agent Backlog 则是偶然会自我运行的杂乱无章。看板在从接收到发布的整个过程中，始终保持上下文、所有权、进度、结果和人工评审透明可见——这就是“你管理的队列”与“管理你的队列”之间的本质区别。当评审过程发生积压而非入口处积压时，那是另一个瓶颈，我们在为什么人工评审才是真正的瓶颈一文中做过专门探讨。
如果你的任务量较小，可以通过电子表格和人工纪律来运行这套流程。如果你已经在处理稳定的入口需求并运行着多个 Agent，HiFox 能为你提供 Triage 队列、Backlog 关口和统一的共享看板，让这些决策不再仅停留在你的脑海中。要进一步了解该工作流的全局视图，请参阅我们的 AI Agent 任务管理指南以及 Triage 与个人 Inbox 的区别。
你今天就可以使用的 Triage 核对清单
用这份清单核对你目前的看板。每一个“否（No）”都是 Agent 可能给你带来“意外惊喜”的隐患点。
- 新请求是否在进入 Backlog 之前有暂存落脚点？ 如果接收到的需求直接进入“To Do”，你就缺少了接受/拒绝/标记重复的步骤，重复工作将不可避免。
- Backlog 中每个任务的范围界定是否清晰到足以交给一个陌生人？ 如果对新员工来说都不够清晰，那对 Agent 来说也绝不够清晰。
- 移动任务卡片是否能真正触发某些操作？ 如果你的状态变更仅仅是标签，看板与实际工作就会发生脱节。
- 指派是否是一项经过认真思考的决策（包括选择哪个 Agent）？ 默认指派给空闲的 Agent 并不是真正的路由。
- 你现在能否清晰地知道每个 Agent 正在处理什么、以及有哪些工作在等待评审？ 如果答案只储存在某人的记忆中或终端的滚动记录里，那么 Triage 就缺乏共享的单一事实来源。
- 完成的工作是否沉淀回 Task 之中，而不是停留在私有会话里？ 结果、阻碍因素和代码 Diff 都应当记录在共享记录中，以便评审有据可依。
在扩大 Agent 规模之前，先解决前两项问题。干净清晰的入口步骤和切实明确的任务范围能防止大多数代价高昂的失败；其余的一切，都是在已经具备明确语义的 Backlog 基础上的细化与完善。
扫一扫
217
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
