少打扰人的前提，是接手时有据可循

2026-11-01 · 当时的记录

过去讨论 Agent 通信时，容易先关注助手能否互相发消息。此前的观察已经把通信与交接区分开：发出消息只建立了联系，交接还需要任务要求、可验收的产物和责任边界。今天的材料让这个判断可以进一步落到执行中间的状态。dsh-superagent 不把会话结束直接当成工作完成，而是保留等待对象和人工接手条件；Mollick 的体验则说明，如果用户不知道助手在做什么，再多后台自动化也可能伴随持续的猜测和追问。

两边的共同机制是：下一步行动必须有可恢复的依据。迟到的 GitHub 提及若被游标跳过，任务从入口就缺了一项要求；控制者若把“文件已产出、打包失败”缩成“完成”，执行者会失去继续工作的依据。这些问题不需要假定模型普遍不可靠才能成立。即便模型每次都认真处理眼前材料，遗漏的输入、含糊的交接与过期的要求仍然会把它引向错误方向。

Memdoor 又补充了更难的一层：信息送到了，也可能是错的。经理提出反例，本来是为了纠错，却促使一个正确程序退化。因此，让另一个 Agent 审核并不自动构成独立验证；审核者的说法同样需要可执行证据。保留前一个候选、核对反例、区分“程序退出”和“业务验收”，是在不同层面保存可恢复的进展。这些措施可能增加即时步骤，却有机会减少晚些时候更昂贵的返工。

这会改变我们评估“少占用人”的方式。通知数下降，可能是系统更会处理事情，也可能是它不再暴露失败；人点确认的次数下降，也可能把工作挪到了事后排错。较有意义的比较应先固定任务和交付要求，再分别记录人的主动检查、补充输入、纠偏与恢复时间，同时检查未完成任务有没有被静默丢弃。当前几份材料没有做完这样的共同实验，不能据此宣称已经省下多少人时。

工程上可以先选一个普通长任务，故意加入迟到要求、执行中断和一条可证伪的错误质疑，观察系统留下什么，以及人接手时必须重建多少背景。它既能检验入口可靠性，也能检验验收是否只是角色之间互相认可。若系统能在这些条件下保住已有有效工作、让修订实际进入产物，再谈减少人工注意力才有具体依据。这是后续验证方案，今天并未运行。

回到当期正文 ↗

2026-10-30 · 当时的记录

知识库此前讨论 Reason Network 时，区分了消息通信和工作交接：工具可以告诉 Agent 谁在做什么，并把信息送到正确会话；这仍不能决定接手者应交付什么、怎样验收。原始设计里对会话名称、离线状态与邮件的处理，解决的是通信身份问题。本次十五助手的评论补上另一侧：任务目标、输入文件和输出格式，要成为交接内容，而不只存在于发起人的想法里。

zookmas 建议从一个协调者和两个执行者开始，Jason 也强调小团队与定标准。这类建议的可取之处，是把“敢不敢放手”拆成能够准备的条件：执行者拿到足够材料，协调者能核查依据和改动，人知道哪里仍需要决定。Davide 随后要求看实际产出，则提醒我们，这些条件是否齐备要通过一次真实交付来判断。我们尚未读到这种完整记录，不能把评论者的方案写成视频已经证明的实践。

Mollick 推荐的组织能力框架提供了更大的问题背景。团队可能因专长互补而强于单个成员，也可能因交接损失而无法扩大。把这套思路用于 Agent 时，应先问两个角色究竟贡献了什么不同信息，而不是把不同称呼当作互补。若所有执行者重复搜索同一材料，协调者再重新完成一遍任务，活动增多并没有说明交付增加。另一方面，若一个参与者确实补上另一位的盲点，已有模型能力也可能因此更有用。

早稿保留的 Rachel Laycock 案例解释了为什么这件事不能只靠组织图。频繁提交既帮助集成，也承担了传递进度的作用；降低提交频率会同时改变两项功能。因此，照搬“执行者不直接传话”也未必合适：它可能减少冲突，也可能堵住及时澄清接口的渠道。应辨认消息在当前工作里承担的作用，再选择集中汇总、直接协商或固定检查。

可迁移的起点是检查一个接手过程：下一位需要哪些输入，能够据什么判断完成，缺少的信息由谁补回。保留输入、产物和关键改动，再观察等待、重复工作与人工修补，可以让团队知道下一次该改善哪里。这能把后续比较落在真实交付上。判断的变化在于把“协调很好”变成具体对象：接手之后，工作有没有更容易继续。

回到当期正文 ↗

2026-10-30 · 当时的记录

知识库此前讨论 Reason Network 时，区分了消息通信和工作交接：工具可以告诉 Agent 谁在做什么，并把信息送到正确会话；这仍不能决定接手者应交付什么、怎样验收。原始设计里对会话名称、离线状态与邮件的处理，解决的是通信身份问题。本次十五助手的评论补上另一侧：任务目标、输入文件和输出格式，要成为交接内容，而不只存在于发起人的想法里。

zookmas 建议从一个协调者和两个执行者开始，Jason 也强调小团队与定标准。这类建议的可取之处，是把“敢不敢放手”拆成能够准备的条件：执行者拿到足够材料，协调者能核查依据和改动，人知道哪里仍需要决定。Davide 随后要求看实际产出，则提醒我们，这些条件是否齐备要通过一次真实交付来判断。我们尚未读到这种完整记录，不能把评论者的方案写成视频已经证明的实践。

Mollick 推荐的组织能力框架提供了更大的问题背景。团队可能因专长互补而强于单个成员，也可能因交接损失而无法扩大。把这套思路用于 Agent 时，应先问两个角色究竟贡献了什么不同信息，而不是把不同称呼当作互补。若所有执行者重复搜索同一材料，协调者再重新完成一遍任务，活动增多并没有说明交付增加。另一方面，若一个参与者确实补上另一位的盲点，已有模型能力也可能因此更有用。

早稿保留的 Rachel Laycock 案例解释了为什么这件事不能只靠组织图。频繁提交既帮助集成，也承担了传递进度的作用；降低提交频率会同时改变两项功能。因此，照搬“执行者不直接传话”也未必合适：它可能减少冲突，也可能堵住及时澄清接口的渠道。应辨认消息在当前工作里承担的作用，再选择集中汇总、直接协商或固定检查。

可迁移的起点是检查一个接手过程：下一位需要哪些输入，能够据什么判断完成，缺少的信息由谁补回。保留输入、产物和关键改动，再观察等待、重复工作与人工修补，可以让团队知道下一次该改善哪里。这里提出的是待比较的方法，没有实施团队实验，也没有用短帖支持经济模型的宏观预测。判断的变化在于把“协调很好”变成具体对象：接手之后，工作有没有更容易继续。

回到当期正文 ↗

2026-10-19 · 当时的记录

一个会话能把消息送给另一个会话，减少的是人来回传话的成本。Reason Network 把人、机器、仓库和分支变成可查找的地址，还区分送达与读取状态。它让“谁在做这件事”更容易知道，但任务完成需要另一层约定：接手者要交付什么，怎样验收，改动冲突或任务中断后由谁处理。通信机制与工作约定可以配合，却不能互相替代。

0xLogicrw 的 AGPair 经历说明了后一层有多容易膨胀。接口不可靠时，他转向启动外部进程，再用状态机、重试、隔离和回执补足缺口。每个补丁都有用，累积起来却偏离了最初想要的简单协作体验。由此可以提出一个尚待验证的判断：在已有工作环境中把一次交接做清楚，可能比提前管理所有 Agent 的完整生命周期更容易产生可感知的收益。这个判断来自具体个人项目，不能推广成调度系统都没有价值。

Karri Saarinen 的文章把问题推进到产品层面。即使每个 Agent 都完成了自己的局部改动，也还需要判断这些变化是否共同服务于用户。solatic 的反驳同样成立：客户迁移成本、组织激励和功能堆积早于 AI。因而本期观察不把这些问题归罪于模型，而是把交接内容、验收责任和整体取舍作为协作系统需要显式承载的东西。后续值得看真实项目中人工传话、重复工作和失败恢复是否减少，而不只数消息量或并行任务数。

回到当期正文 ↗