两天之内，AWS、微软研究院、JetBrains 和一家新公司先后开源了各自的编程智能体方案，从编排层、模型权重到 IDE 一起放开。这些动作指向同一个判断：智能体的竞争重点正在从”谁的模型更强”，转向”谁的运行时更开放、更好组合”。
三天里发生了什么
10 月 24 日，微软研究院开源了多智能体编程框架 Agensh；同一天，JetBrains 发布开源智能体 IDE ThinkRail。10 月 25 日，AWS 以 Apache 2.0 协议开源异步编程智能体的编排层 Kiro Crew。再往前几天，前 Meta 研究员田渊栋创立的 Recursive 开源了 400 亿参数的编程模型 Flint。
四件事看起来分散，实际上覆盖了智能体落地的四个层次：模型（Flint）、宿主环境（ThinkRail）、编排层（Kiro Crew）、协同框架（Agensh）。过去这四层大多由同一家厂商打包提供，现在每一层都出现了可替换的开源选项。
这对使用者的直接影响是选型逻辑变了。以前问”哪家的编程智能体最好用”，现在要拆开问：模型的推理能力够不够、编排层能不能接进自己的工单系统、工具链是否锁定在某家云上。
AWS Kiro Crew：把编排层交出去换生态
Kiro Crew 的定位是”面向异步编程智能体的持久化编排层”。通俗地说，它解决的是”任务交给智能体之后，人去睡觉了，第二天回来活儿干完了没有”这个问题。
它支持的长周期任务包括事故排查、工单分诊、代码迁移和 PR 监控——共同点是需要跨越多轮对话、跨越数小时甚至数天，中间还要等人审批。传统的一次性对话式编程工具在这种场景下会断掉上下文，Kiro Crew 的做法是把任务状态持久化，让智能体可以中断、恢复、被调度。
更值得看的是开源前的内部数据：据公开报道，这套东西在亚马逊内部不到六个月覆盖了约 3.9 万名开发者。这个量级的企业内部验证数据，在多智能体协同领域相当少见。
商业结构上，AWS 选择开源编排层、保留推理引擎（Kiro CLI 与 Bedrock）闭源。这套”下层开放换生态、上层闭源收钱”的组合，可能成为智能体平台的默认形态。对选型团队的含义很直接：要分清哪些部分是可以随时替换的，哪些一旦接入就被锁定。
微软 Agensh：去掉”总包工头”的 1024 个智能体
主流的多智能体框架都采用”编排者—执行者”结构：一个主智能体负责规划、分派、合并，其他智能体干活。问题在于，当执行者数量上去之后，主智能体本身成了瓶颈——它要处理所有汇报、做所有决策，规模越大越慢。
Agensh 的思路是把这层去掉。每个工作智能体自己从任务池里领取子任务，通过聊天频道和一块共享的”发现板”同步进展，完成后直接把代码合并进公共 Git 仓库，不需要中枢批准计划。
论文给出的数据来自 ProgramBench 的 200 个编程实例，重点测试了其中最难的五项（FFmpeg、gromacs、pandoc、PHP-src、ctags）。在 GPT-5.6-sol 上，智能体数量从 1 个扩到 128 个，五项平均通过率从 19.31% 升到 28.78%；pandoc 这一项在六小时预算内，从单智能体的 33.89% 提升到 1024 个智能体的 55.06%。
也有需要冷静看的地方。项目 README 提到，在使用更新的 GPT-6.1-sol 时，32 个智能体在 pandoc 上就达到 79.59% 的通过率——但这个数字没有写进论文，属于项目自述。另外，团队没有公布 1024 个智能体跑一轮的 Token 成本；按每个工作智能体 27.2 万 Token 输入、12.8 万 Token 输出的上限估算，这个量级并不便宜。
这引出一个更实际的问题：多智能体的收益是否随规模线性增长？论文自己的数据并不支持这个假设——五项平均分在 128 个智能体时只有 28.78%，说明大多数任务并不能靠”堆人头”解决。规模效应对某些任务成立，对另一些无效。
Recursive Flint：400 亿参数塞进笔记本
Flint 是这批发布里唯一的模型。400 亿总参数的 MoE 架构，每个 Token 激活约 25 亿参数，支持最高 51.2 万 Token 上下文。官方给出的数据是：MacBook Pro 上大约 125 tokens/s，SWE-bench Verified 74.2%。
后一个数字需要打折看——它是厂商自报，没有经过独立复测。但前一个数字的意义可能更大：一个能干编程活儿的模型，能在笔记本上以可接受的吐字速度跑起来，意味着”数据不出本地的离线编程智能体”从概念变成了选项。对金融、医疗、政务这类不能把代码传到云上的场景，这是硬需求。
另一个细节是训练方式。团队称 Flint 只用了四个月，借助自动化的 AI 研究系统从零训完。如果这个说法成立，它说明造模型的成本曲线正在被 AI 自己压扁——这比模型本身的分数更值得关注。
对照国内进展，月之暗面 10 月 24 日发布的 Kimi K3.1 Pro 走的是另一条路：3 万亿参数、100 万上下文、主打云端长程任务。两条路线并不冲突，一个拼本地可用性，一个拼云端上限。
JetBrains ThinkRail：为智能体重做一个 IDE
ThinkRail 是 JetBrains 创新中心做的一个开源智能体 IDE，Apache 2.0 协议，支持 macOS（Apple Silicon）、Windows x64 和 Ubuntu 24.04 以上，可以本地跑也可以用浏览器访问。
它解决的是一个很具体的冲突：智能体大改代码时，会把人正在工作的目录搅乱。ThinkRail 的解法是用 git worktree 给每个智能体或每个任务开一个物理隔离的工作区，AI 的改动落在独立分支和独立目录里，主工作区保持干净。
第二个设计是”规格优先”。项目用一组互相连接的 SPEC.md 文件作为智能体的事实依据，而不是只靠对话提示。这相当于把需求写成结构化的规格图，让智能体按图改代码，减少长会话里常见的跑偏和幻觉。
架构上它把自己定位成”薄宿主”，模型、技能和会话状态由内嵌的 pi 编程智能体管理。这种解耦对行业的意义在于：IDE 和智能体引擎可以分开演进，不必绑死。
如果你是刚接触这一层的读者，建议先看AI 编程工具的完整流程，理解需求、生成、评审、合并这几个环节分别由谁负责，再判断这些开源件该放在哪一格。真正决定产出质量的仍然是任务描述，编程提示词的三段式写法在这个阶段比工具选型更管用。
结语
把这四件事放在一起看，会发现一条清晰的线：智能体的基础设施正在被拆成可替换的零件，并且逐层开源。编排层开放、模型可本地部署、IDE 与引擎解耦，最终受益的是那些不想被单一厂商锁定的团队。
但也别把开源等同于”拿来就能用”。Agensh 的成本没公开，Flint 的成绩是自报，ThinkRail 还是创新中心的实验项目，Kiro Crew 目前和 AWS 生态绑得比较紧。现阶段更合理的做法是：先在一个小项目上验证某一层的替换是否真的带来收益，再考虑扩大范围。规模从来不是免费的。