助手越多，我越像它们的传话人。

研究助手找到了资料，写稿的助手却看不到。你把结果复制过去，补一句“第二条只是猜测，不要写成事实”；稿子完成，再复制给校对助手。原本希望多几个助手分担工作，最后每一步交接都得由你盯着。哪次忘了带上一个条件，后面的工作就可能全部白做。

如果这几步都能在同一个工具里完成，用它已有的工作流就够了。问题在于，你确实想保留不同地方已经调好的方法：研究程序在服务器上，写作流程由另一位同事维护，校对还要查公司的资料。要求所有人搬到一个平台，未必比手工传话更省事。

可以先把交接缩小到一篇稿件。研究程序接收主题与时间范围，返回带来源的结论、尚有争议的判断和缺失材料；写作程序接收这份结果与读者要求，交回稿件。EasyRemote 能把这些已有程序接成函数入口，EasyNet 负责把请求送到提供方；研究和写作本身仍由各自程序完成。

这里值得花时间约定的不是角色名字，而是下一位实际会收到什么。原文只对研究者开放时，不能把私人文件路径交给写作者就算完成；应提供获准的摘录，或另行授权可访问的材料。稿件中的结论也要保留来源标识，校对才能找到依据，而不是只能核对上一位助手的语气。

把两个入口连起来之后，还需要一段明确的流程代码保存中间结果。写作失败时重新写稿，不要重新付费研究；来源缺失时停下来问人，不要让下游猜。谁负责重试、多久算超时、最终稿放在哪里，都要在这段流程里处理，函数能够互相调用并不会自动做好这些安排。

先让同一份研究结果进入一次写作，再故意中断写作服务，检查恢复后是否仍使用原来的证据。这个小试验成立，你省掉的才是传话工作：已经完成的研究能交给下一步继续使用，你只在需要判断的时候介入，而不是在每个窗口之间搬运文字。