编程智能体正在悄悄换一种活法：从「一个助手帮你写代码」，变成「一组角色分工协作」。9 月 8 日，AI Agent Store 的每日资讯把两条相关动态放在了一起——GitHub 把 Copilot 从一个对话助手拆成了并行工作的「编程小队」，而开源侧的 OpenHands 则把自治编程 Agent 推到了 1.0 的生产可用门槛。这两条线合起来，勾勒出工程团队使用编程 Agent 方式的一次微妙转向。
一、Copilot Workspace：把代码库拆给多个 Agent 同时干
GitHub Copilot Workspace 现在支持多个专职 Agent 在同一代码库的不同部分并行工作：有的负责实现，有的负责测试，有的负责文档，它们通过一个共享的上下文窗口保持对同一项目状态的认知。换句话说，过去你面对的是一个「会补全的伙伴」，现在你面对的是一支「有分工的班组」——每个角色专注一类任务，但所有人都看着同一份项目事实。
二、OpenHands 1.0：开源自治编程 Agent 走到生产可用
同一天进入视野的还有 OpenHands 1.0。这个开源自治编程 Agent 带来了生产级 Docker 沙箱隔离、内置安全策略、资源限制与插件系统；其基准显示，约 68% 的 SWE-bench Verified 任务可以自主完成。强隔离加资源控制的意义在于：让 Agent 真正去执行代码这件事变得「可放行」——更多原本靠人工手工完成的集成与重构，有望转为受监督的自动化工作流。
三、为什么「编排团队」比「更强单人」更关键
对工程负责人而言，真正的价值不只是某个 Agent 更聪明，而是可以把代理型编程工具当作一支编排团队来用：把不同职责委派出去，同时让所有 Agent 都锚定在同一个项目上下文里。当「执行代码」这件事有了可靠的隔离与资源边界，把集成、测试、文档这类链路交给多 Agent 协同，风险才真正可控。这比单纯追求单个模型跑分，更接近工程落地的本质。
四、落地的现实建议
比较稳妥的起步方式是：挑一个非关键服务，先用 GitHub 的多 Agent Workspace 跑一遍，再在预发环境配一个 OpenHands 沙箱对照，度量缺陷率、评审开销与交付速度，确认收益后再向生产扩张。把「多 Agent 协作」先当受控实验，而不是一次性全员替换，是这波能力最该有的打开方式。