让几个 Agent 同时完成任务，并不难开始。困难往往在工作持续数周以后才显出来：一个工具已经造好，后来者却不知道怎么用；每一阶段都交了报告，最初要交付的东西却没有被完整承接；同一种失败被写进复盘，下一批执行者还是照旧行动。
我们在建设 Flowness 时持续记录了这些问题。Flowness 是我们自己开发的 Harness 项目，用来组织多个 AI Agent 持续协作，管理任务、上下文、工具调用与工作记录。这个系列关注的是多个会话、角色和组件之间怎样保留工作所需的关系：谁能做什么，为什么做，已经知道什么，以及凭什么相信结果。
2026 年 9 月，我们把此前的调查整理成两份给研究者阅读的材料：一份包含 43 个通用问题条目，一份包含 59 个规划专题条目。两份材料有交叉，条目也处在不同层级。这些数字表示整理范围，不能相加成为 102 种独立故障，更不是一次统一实验的样本量。
首期选择其中五个问题，重新回到历史案例、需求追溯和独立复核，展开说明。我们希望读者能看到当时遇到了什么，已经试过的办法为何有限，以及哪些问题仍值得设计实验。
Agent 知道工具的名字，为什么仍不知道自己能做什么 ↗
命令已经实现，仓库已经接入，后台服务也在运行，为什么具体检查仍没有生效？一次能力调查让我们发现，多 Agent 系统缺少的常常是实现、角色入口、部署版本与运行证据之间可核对的关系。
任务都有人做，最初要的结果却没有人接 ↗
一条采访系统改造线拆出32个任务，29个记录成功，但“让历史问题改变下一次采访”的要求没有得到完整承接。我们沿需求、设计、工程和任务回查，发现局部定义可以完整保留，真正产生效果的生成、消费与持续使用关系却会逐步丢失。文章说明这些交接为何各自合理、全局主线需要保存什么，以及怎样检验任务成功是否真的通向最初的结果。
协调者记住了教训，为什么下一批 Agent 还会重犯 ↗
协调者三天五次认出“干完不交卷”，却没有修改下一批 Agent 的派发说明。另一条工作线里，教训已经进入共享日志、被后来者读到，重复派发仍未停止。我们沿真实案例追问：经验存在哪里，谁会在行动前遇到它，谁能据此改变下一步，以及怎样验证改变真的发生。
Agent 报告了代码错误，却漏掉近两小时中断：监督信息怎样丢失 ↗
一次 Agent 任务如实报告了独立复查故障，却漏掉同一会话近两小时的中断。我们沿运行记录和独立复核还原两条路径，区分看不见、未进入报告，以及说出不确定却不改变判断三种监督缺口，讨论怎样让过程事实成为可检查、可处置的反馈。
十四处引文核验通过，为什么“谁导致了交付失败”仍然判反了 ↗
一次 Flowness 历史调查中，十四处证据抽验都能对上，核心归因却被接收方记录推翻：子会话写完了报告，主会话并没有收到。本文沿原分析与独立复核，解释启动模式、工具权限与派发说明怎样错配，以及为什么引文准确、计时准确，都不能替尚未核实的因果关系担保。
这些文章记录的是我们走到研究问题之前的工程事实与推理过程。历史调查已经发现了一些缺口，局部修订也已经发生；长期、多轮协作是否因此改善，需要继续取得运行证据。