任务都有人做，最初要的结果却没有人接

我们希望 AI Agent 能把一项工作持续做下去：先问清楚需求，再形成设计，拆成任务，分头执行，最后交付。分工让每个 Agent 可以集中处理一段问题，也让复杂工作不必依赖一个越来越长的会话。但在建设 Flowness 的过程中，我们发现了一种难以从任务状态里看出来的失败：各段都能交出自己的产物，原先希望发生的行为，却在几次交接后失去了具体承接。

2026 年 9 月 2 日，我们回查了一条采访系统改造线。这里的“采访”，是 Agent 与负责人一起澄清意图、探索方案，再把讨论形成的需求交给后续团队。改造要解决的问题之一很具体：下游团队经常做到一半才发现信息不够，需要回来问负责人。系统应当从这些历史缺口中学习，在下一次采访时提前问到相关问题。

这条改造线经过了设计、工程方案、共识、规划和执行。规划拿到了 24 个冻结概念和 11 件待交付机制，拆成 32 个任务，其中 29 个记录为成功。追溯时我们却发现，“从历史问题形成必问清单，并在下一场采访前使用”没有被完整拆进这些任务。

这个发现首先说明的是交付责任发生了断裂。要判断某场采访是否实际用过历史清单，还需要看那场采访的运行记录。但仅就任务链而言，我们已经无法沿着它回答：谁负责把历史教训变成下一次开场时真正会用的东西？

原始要求里的重点，是让采访越来越能提前发现信息缺口。假如后续团队反复需要回来确认某类事项，采访者就应据此调整准备，而不让负责人在不同阶段重复补充。这要求系统知道哪些历史问题值得学习，也要求学习结果进入下一次工作的起点。

设计阶段为此写下了几项相互依赖的安排：问题要有可识别的事件形态，要能经过确认；历史问题要能反推成必问清单；清单要有稳定的存放位置；下一场采访开始前，要把清单交给采访者使用。设计还写了一个走查场景，把这份清单列为开场前的准备材料。

到工程方案，重心逐渐转向问题如何分类、哪些模块消费这些问题，以及统计时如何计算分母。随后冻结的共识延续了这个范围。最终任务要求实现问题类型枚举、消费方和统计函数，却没有相应任务承接历史清单初版、清单归宿和采访前置消费等部分。

分类和统计都有用途。没有统一的问题表示，后续处理很容易各说各话。问题在于，它们只完成了原要求的一部分。一个问题被正确分类，并不会使它自动成为下一次采访的问题；系统能够统计这类问题，也不能保证采访者在开场前读到了它。

这几步之间的关系，正是改造想建立的行为。任务可以逐项通过，关系却仍然没有着落。

追溯结果也改变了我们对责任位置的判断。最容易受到质疑的是规划：既然漏了任务，是否让规划重新拆一遍就好？但这次规划对收到的冻结概念和完成条件，覆盖得相当完整。需求在工程到共识的转换中已经收窄，规划又沿着这个收窄后的输入继续工作。要求最后一棒更加认真，并不能让它自动知道上一棒遗漏了什么。

多 Agent 协作需要把宽泛意图逐步变成可执行的东西。采访说明想改变什么；设计说明系统应怎样工作；工程方案确定接口、约束与落点；共识固定共同遵守的定义；规划安排具体任务。每一段都会取舍、压缩和改写材料，这些动作本身不可避免。

真正危险的是，材料的压缩同时改变了验收对象。上游问的是“下一次采访会不会因此问得更充分”，下游检查的却可能是“问题类型和统计接口是否齐全”。如果阶段交接只核对新产物有没有对应上一步的名词，原需求仍可能在目录中留下名字，却不再保有它要求的行为。

那次改造中的另一项要求，提供了不同的观察角度。负责人担心第一批工作结束后，后续阶段再也不会启动。因此，设计不仅安排了分期，还要求为各期规定开启条件；如果应该产生的验收数据迟迟没有出现，系统要能发出升级处理请求。

工程方案明确登记了一个缺口：第三期的阶段门还没有具体落点，下一环需要扩充。这里的阶段门，是判断某一期是否满足开启条件的机制。但到了共识的未决事项登记里，这个缺口没有被接住。规划选择不提前拆细远期任务，只保留阶段门；与此同时，判断阶段门是否满足、逾期后发出请求的任务也没有建立。

“不提前拆细”有充分理由。远期工作所需的信息还没成熟，提前制造一批看似精确的任务，反而会让系统背负过期计划。然而，推迟细节仍需要保留推进责任：什么情况允许展开，谁观察这个条件，满足后由哪个入口接续。缺了这些，分期图可以保存得很好，后续工作仍依赖某个会话重新想起来。

这项分期要求与前面的历史清单是不同需求。它们的共同点，是容易被当成附件的关系承担了关键作用：清单要由下一场采访消费，后续阶段要由具体条件启动。只留下清单的类型、阶段的名称，无法保住这些关系。

这次改造并非只要求写完文件、通过测试。我们已经把“至少一次非测试语境的真实调用留痕”写进了完成条件，希望据此区分一个静态存在的功能和一个实际进入流程的功能。

但一次调用究竟证明什么，需要说清楚。设计把这项要求界定为：交付验收时至少真实调用过一次；持续使用属于维护范围。这个切分允许建设工作在一个有限时点结束，同时把后续运行交给另一套安排。为了承接后半部分，设计又提出持续监测，其中包括“上次被真实消费的时刻”。

随后发生的丢失更有解释力：工程方案写了监测内容，但共识提取时只从设计决策、契约和参数等节点选取候选，观测面的要求没有对应节点，没有进入冻结概念，规划中也就没有相应任务。

于是，严格执行一次真实调用验收，仍然可以留下持续使用无人承接的局面。我们加强了一段证明，却丢掉了与它配套的另一段工作。增加局部验收强度，只有在全局要求仍然完整时，才能帮助我们接近原先的目标。

这一案例也提醒我们，交接格式不是中性的容器。哪些东西有字段、有节点、会被提取，决定了下一环容易看见什么。接口和参数可以完整留下，观测、启用条件和维护义务却可能被排除在候选范围之外。此时再给审查者一份相同来源的检查表，它看到的仍然是同一个缺口之后的世界。

我们更早就遇到过目标跨阶段丢失的问题。前端与界面要求曾在不同项目的交接中反复遗漏；负责人由此提出，需要一个贯穿整条工作链的对象，让每一棒都能重新确认整件事要交付什么。

2026 年 6 月，这个对象被定义为一份最小的全局主线令：在采访末尾形成，由负责人签发，后续各阶段继承。它保留整条工作的目标、全局完成条件，以及各阶段的契约。我们给它起了一个不容易与普通任务目标混淆的名字——“菠萝包”，并要求把精确定义放入概念图，让后来者可以查到。

专门命名是为了解决当时一个实际的语义问题：“目标”已经同时指代工具、单个任务的完成条件和整项工作的目的。每一棒都说自己有目标，很容易掩盖它们说的并非同一件事。一个可查询的独立对象，至少使这种区别有了明确的表达位置。

这项设计也保留了分工的初衷。每个会话只需先读全局目标和自己这一阶段的契约，其余材料按需查证。如果把全部历史复制给所有 Agent，虽然增加了材料量，却没有回答它此刻必须承担哪一部分责任。

到 9 月的规划重建中，我们提出的要求是复用已有主线对象和源需求引用，补上原需求、交付与验收之间的双向追溯。一方面，从一个任务能回到它服务的全局结果；另一方面，从原始要求出发，也能找到正在承接它的任务、条件或明确的范围决定。后一方向尤其关键：所有任务都能解释自己为什么存在，并不意味着所有需求都有任务。

这还要求我们认真处理合理的变更。有些需求应当延期，有些经过讨论应当舍弃，有些尚缺信息。它们需要不同的处置，不能被强行改写成“全部马上实现”。追溯的作用，是使这些决定仍然可见，并让该继续的工作有实际接收方。

已有的主线设计为此提供了基础。9 月 23 日的规划问题表仍把规划承接列为需要补足的工作，全链效果也仍待核实。对象存在、定义清楚和每次交接真正使用它，是三个需要分别完成的动作。

针对这个问题，规划重建提出了一个很直接的检验：故意从下游输入中漏掉一项上游需求，让独立审读者判断缺了哪一项、应由谁承接。这个测试所需的关键条件，是审读者能取得上游要求，而不是只能阅读任务清单。否则，即使它把全部任务逐字复核，也可能确认一个内部一致但并不完整的计划。

回到历史清单的案例，我们还可以从原需求反推一个行为验证场景：选取已经确认、与新采访相关的历史信息缺口，启动一场新采访，检查开场准备是否读取了对应清单，并追踪这些材料怎样影响提问。这是我们据案例提出的验证方向，尚不是本文完成的一次实验。它把判定位置放回用户期待的行为，也为分类、清单生成和前置读取这些局部证据找到了各自的作用。

验证本身还会遇到难题。一次采访没有问到某个历史问题，可能是该问题与当前场景无关；即使问到了，也可能来自采访者自己的判断。因此，需要记录历史条目为何相关、何时被读取，以及它与实际问题之间的依据，不能仅靠词语重合判断学习发生。主线对象和追溯关系也要维护：需求变了，旧的任务解释和验收结论就可能需要重审。保存关系使这些工作可做，并不会消除判断与维护的成本。

我们从这次追溯中得到的方向，是让整体完成保有独立于任务成功数的判断依据。任务应当证明局部工作做成了什么，整条链则需要证明这些工作组合后，最初要求的行为得到了承接和验证。两种判断允许出现分歧，系统才有机会在宣布完成之前，看见那个尚未被任何人接住的结果。