多 Agent 持续协作，哪些问题会在交接中反复出现

让几个 Agent 同时完成任务，并不难开始。困难往往在工作持续数周以后才显出来：一个工具已经造好，后来者却不知道怎么用；每一阶段都交了报告，最初要交付的东西却没有被完整承接；同一种失败被写进复盘，下一批执行者还是照旧行动。

我们在建设 Flowness 时持续记录了这些问题。Flowness 是我们自己开发的 Harness 项目，用来组织多个 AI Agent 持续协作，管理任务、上下文、工具调用与工作记录。这个系列关注的是多个会话、角色和组件之间怎样保留工作所需的关系：谁能做什么，为什么做，已经知道什么，以及凭什么相信结果。

2026 年 9 月，我们把此前的调查整理成两份给研究者阅读的材料：一份包含 43 个通用问题条目，一份包含 59 个规划专题条目。两份材料有交叉，条目也处在不同层级。这些数字表示整理范围，不能相加成为 102 种独立故障，更不是一次统一实验的样本量。

首期选择其中五个问题，重新回到历史案例、需求追溯和独立复核，展开说明。我们希望读者能看到当时遇到了什么，已经试过的办法为何有限，以及哪些问题仍值得设计实验。

第一篇从一个告警检查展开：命令已经实现，调用代码已经进入仓库，实际部署却仍运行旧版。调查进一步发现，功能清单的计数单位、技能入口的搜索方法、事件记录的身份，都可能影响系统对自身能力的判断。

《Agent 知道工具的名字，为什么仍不知道自己能做什么》讨论能力表征应当包含哪些关系。它把“实现存在”继续追到具体角色、入口、部署与可观察结果，也解释了为什么盘点 Agent 自己会漏掉已有能力。

第二篇关心工作从需求走向设计、规划和执行时发生的变化。一项要求可以在上游被理解得很完整，到下游只剩可以实现、可以局部验收的部分。每位执行者都完成了自己拿到的任务，整条链仍可能没有保存原来的完成条件。

《任务都有人做，最初要的结果却没有人接》沿真实需求追溯展开，区分“构建一套可用机制”与“在后续真实任务中证明它产生预期结果”。文章也讨论远期工作和持续监测义务如何在拆分时失去承接。这里的研究对象，是全局目标怎样在局部任务中持续可见、可核对。

第三篇追踪一位协调 Agent 多次记录相同交付问题的过程。它调整自己的轮询方式，却没有改变继续复制给执行者的派发说明。另一组材料则显示，即使执行者读到了共享教训，也可能没有权限修改造成问题的派发安排。

《协调者记住了教训，为什么下一批 Agent 还会重犯》讨论教训如何到达能够改变行为的位置。把知识存下来、让人读到、提供动作入口，以及观察后续效果，是几件需要分别完成的事。文中也保留一个操作说明更新的正向尝试，继续追问它是否改变了后续运行。

第四篇从同一会话中的两个问题入手：一个具体程序错误进入了最终报告，一段接近两小时的顾问等待却没有被同样呈现。回读过程记录，能够看到自我汇报遗漏了什么，也能看到我们无法仅凭沉默判断什么。

《Agent 报告了代码错误，却漏掉近两小时中断：监督信息怎样丢失》把监督信号的缺口分成不同环节：执行者能否观察到问题，报告结构能否表达它，以及已经表达的不确定性会不会改变后续判断。增加字段可能帮助其中一环，却不能代替对其他环节的检查。

第五篇回到一次通信失败调查。复核抽查的十四处引文全部准确，但回读此前没有检查的父会话后，对失败原因的关键判断发生了变化。原先被归咎的顾问和催报行为，需要放回异步交付方式与角色权限中重新理解。

《十四处引文核验通过，为什么“谁导致了交付失败”仍然判反了》讨论一个复合结论需要怎样的证据。原话核对解决了“是否这样说过”，却没有自动解决“是谁导致结果”“哪个角色具备完成动作的权限”。文章保留复核仍不能覆盖的部分，避免在推翻旧结论时过度确信新结论。

这五篇有一个共同观察：系统里常常已经有了信息，但信息与下一步工作的关系没有保住。功能说明可能失去实际入口，需求可能失去最终验收，教训可能失去行动者，过程代价可能失去报告位置，引用可能失去它能够支持的结论范围。

这个观察为研究提供了方向，但还不能代替因果解释。遗漏可能来自工具权限、上下文装载、任务拆分、记录方式，也可能来自某次具体判断错误。不同原因需要不同干预；把它们统称为“Agent 不可靠”，很难决定下一步应该测什么。

因此，我们希望后续验证能落在具体动作上：改变一条能力入口后，新接手的 Agent 能否察觉；故意漏掉一项全局要求，独立检查能否找到承接缺口；把教训接入正确的派发位置，类似任务的行为是否改变；报告新增代价字段后，遗漏是否减少；把引文和因果关系分别复核后，哪些结论会被修正。

这些文章记录的是我们走到研究问题之前的工程事实与推理过程。历史调查已经发现了一些缺口，局部修订也已经发生；长期、多轮协作是否因此改善，需要继续取得运行证据。