Unified Runtime Streaming Refactor Plan

这个计划是要让三个不同的“运行时”（你可以把它们想成三个负责送信的小朋友，名字分别叫 main、subagent 和 acp）用上同一条“送信流水线”。这样，他们送出的信（也就是文字、工具调用结果这些）格式、分块、顺序，还有摔倒后怎么爬起来继续送，就全都一模一样了，不会再乱。

为什么需要这个呢？因为现在这三个小朋友各有各的送信小路，一条路上修好的bug，另外两条路可能还有。而且，要保证信不送重复、顺序不乱，现在想清楚可太难了。

他们打算怎么建这条新的大河呢？想法是这样的：

1. 首先，让三个小朋友都按照同一个“标准事件清单”来报告。这个清单就像一份固定的“送信纸条模板”，上面只能写规定好的几种事，比如“我开始说话了”、“我说了一个字”、“我用完了一个工具”等等。
2. 然后，有一个“共享的拼装员”来把这些小纸条拼成完整的句子或工具块。
3. 接着，一个“共享的打包员”会根据要把信送到哪里（比如Discord频道），把拼好的内容分成合适的小包裹。
4. 再然后，一个“共享的记账本”会记下每个包裹的“发送编号”，确保同一个编号的包裹只送一次，就算中途摔倒重来也不会送重复。
5. 最后，由专门的“送货员”把包裹送出去，并在记账本上打个勾，表示“已送出”。

大人们把这个大计划分成了几个小任务来做：

1. 制定标准纸条：先严格规定好“标准事件清单”里到底能写哪几种事，并写好检查规则。每个送信小朋友（运行时）都必须通过考试，证明自己会按这个清单写纸条。
2. 建造共享拼装员：把原来三个小朋友各自拼装纸条的小工具扔掉，换成一个大家共用的、更聪明的“共享拼装员”。它负责把零碎的字拼成句子，在适当的时候把句子送走，或者把太长的句子切成几段。
3. 建造共享打包员：把原来针对不同送信地点（比如Discord）的特殊打包规则，都放到这个“共享打包员”里。这样，前面的流水线就只管内容，不用管最后送到哪儿。
4. 建造记账本和重送机制：给每个包裹一个唯一的“发送编号”。送之前记一笔，成功送出后再记一笔。如果送信小朋友中途摔倒了，重启后只要看看记账本，把没打勾的包裹再送一次就行，因为有编号，所以不会送重复。
5. 搬家！：他们不会一下子就把旧路拆掉。会分三步走：
   • 第一步：让新流水线在“影子模式”下运行，就是它也算出包裹，但还用旧路送，同时比较新旧两个包裹是不是一样。
   • 第二步：一个一个小朋友地切换，先让风险最小的 acp 用新路，再 subagent，最后 main。
   • 第三步：等所有小朋友都用上新路并且没问题了，就把他们各自的旧送信小路全部拆掉。

有些事情，这个计划是故意不做的哦：

• 不会去改变 acp 的权限规则。
• 除了让打包兼容不同送信地点，不会增加新的、针对某个地点的特殊功能。
• 不会重新设计整个送信的底层系统。

可能会遇到什么麻烦呢？大人们也想到了：

• 麻烦：新的送信方式让 main 或 subagent 小朋友的行为出错了。
  • 解决办法：用“影子模式”仔细对比，并且让每个小朋友都必须通过标准纸条的考试，还要对每个送信地点做完整的发送测试。
• 麻烦：摔倒重启后，同一个包裹送了两次。
  • 解决办法：靠牢固的“发送编号”和记账本里“只送一次”的重送规则。
• 麻烦：过段时间，三个小朋友的送信纸条又不统一了。
  • 解决办法：要求所有小朋友以后都必须定期参加标准纸条的考试，不通过就不让送信。

怎么才算成功了呢？要满足这些条件：

• 三个小朋友都通过了标准纸条的考试。
• 往Discord送很短的信时，三个小朋友送出的效果（比如空格、分段）要一模一样。
• 摔倒重启后，同一个“发送编号”的包裹绝对没有送两次。
• 原来 acp 专用的那条旧送信小路被彻底拆掉了。
• 所有送信相关的设置规则，都由一个大家共享的工具来决定，不再各自为政。