10 月 3 日，T3 Code 的 nightly 版本放出 Orchestrator V2，核心是一句话：跨框架委派。它的 delegate_task 能在任意 provider 或模型上起一个子 agent，父 agent 可以选择等它回来，也可以继续干自己的事；每个子 agent 有独立线程、provider 原生的历史、自己的模型和选项。内置的 MCP 让 agent 跨项目起线程、彼此通信、fork 上下文。官方注册表里 Devin、Cline、Kimi、Droid 等都能即装即用。一句话概括：编排不再绑死某一家 harness。
这套设计解决的是真实痛点。过去你想让多个智能体协作，往往被锁在某一个编码平台里，换模型要改一整套胶水代码。Orchestrator V2 的思路是：父任务只管拆和派，子任务交给当下最合适的执行方，失败或超限的运行还能 fork 出来继续干，不用从头再来。对想混用多家模型的人，这等于把「选模型」从架构早期决策，降级成运行时的调度策略——哪个便宜用哪个，哪个强用哪个，按需组合。
但官方也老实写了跨 provider 切换的坑：换 provider 时，新的一方只拿到「预算选出来的对话片段」，原先的推理过程、工具调用、工具结果和附件都不带走。被省略的内容仍可在别处查，但上一家的运行状态不会自动迁移。这意味着跨框架委派不是无损的——上下文会断层，需要下游自己补救。另外移动端还要 beta app 才能连 V2 服务器，当前商店 app 连不上；agent 即便有了线程管理权限，也不能自己批准自己的权限请求。这些都是生产前要想清楚的边界。
把它和近期的其他动向连起来看更有意思：Claude Code 用 Mods 把单框架变成可编程平台，T3 Code 用 Orchestrator V2 把多框架连成可委派网络。两条线一个向内开放、一个向外连通，共同指向同一个结论——智能体的竞争正从「单个 agent 多强」转向「编排与互联多顺」。对开发者，接下来值得盯的不是哪家模型又刷了分，而是谁的编排层能让你少写胶水、跨框架不丢上下文。Orchestrator V2 把方向指了出来，但「跨 provider 历史断层」也提醒我们：连通容易，保真难。
对想混用多模型的团队，Orchestrator V2 指明了一条少写胶水的路，但别被「跨框架」四个字冲淡了警惕。上下文断层意味着，你把子任务派给另一家模型时，它看不到前一家是怎么想的、调了什么工具、得了什么结果——它只能基于你挑出来的片段继续。这在简单任务上无妨，在长链路、强依赖的任务上可能悄悄丢信息。实操建议是：把需要连续上下文的子任务留在同一 provider，只在真正独立、可自包含的子任务上做跨框架委派。连通是手段，保真才是目的，顺序不能乱。先把上下文保住，再谈跨框架的灵活，才是稳妥的落地节奏。编排的灵活，永远要让位于结果的可靠；跨框架再省胶水，也不能以丢上下文为代价。少写胶水不等于不写胶水，跨框架省下的是重复劳动，省不下的是对上下文的责任。把这一点刻进编排设计，智能体网络才既灵活又可信；否则表面上是千军万马，背地里却各说各话、谁也接不上谁的话。灵活和可靠之间，永远先保可靠，编排才有意义；丢了上下文的跨框架，只是把麻烦搬了地方。上下文保不住，再花哨的编排都是空中楼阁。跨框架的灵活若以丢上下文为代价，就是捡了芝麻；把保真放在编排设计的首位，智能体网络才站得稳。编排设计的首要原则，永远是可靠，灵活只是它的副产品。顺序不能反。