polyphony

polyphony 技能概览

polyphony 是一个多智能体编排技能，用于在容器隔离的工作空间里并行运行 agent 任务。每个会话都会获得自己的 Docker 容器和 git 分支，因此当你需要并发执行，又不想遇到分支冲突、共享状态 bug 或杂乱的清理工作时，它会很有用。

polyphony 适合做什么

当任务比单次提示词更复杂，但仍然适合结构化分派时，就该用 polyphony 技能：并行功能开发、隔离验证、问题分诊，或让多个 agent 路径同时作用于同一个代码库。它面向的是那些重视干净执行、可复现任务路由，以及更安全的多智能体协作的用户。

polyphony 的突出之处

polyphony 的核心差异在于它采用了“先隔离，再执行”的工作流设计。它不会简单地让一个 agent “把所有事情都做完”，而是把任务发现、路由、资源准备、运行时执行和验证拆开，让每个 worker 都在受控工作区里运行。这样一来，当你需要独立测试和更干净的落地行为时，polyphony for Multi-Agent Systems 这种方式会更实用。

最佳适用场景与取舍

如果你的环境已经支持 Docker 或 OrbStack，并且你想要的是默认启用的编排能力，而不是一次性的提示词模式，那么 polyphony 最合适。它不太适合只需要单次聊天回答、无法运行容器，或者希望几乎零配置、也不依赖仓库感知工作流的场景。

如何使用 polyphony 技能

安装并加载 polyphony

先把 polyphony 技能安装到你的 skills 目录里，然后通过支持技能加载的宿主工作流来使用它。仓库说明写明，只要容器隔离可用，它就会被设计为自动加载，而且 /spawn-team 默认使用它。如果你的环境不同，在依赖该技能之前，请先确认 Docker 访问、分支创建和工作区挂载都可用。

从正确的文件开始看起

使用 polyphony 时，先从 skills/polyphony/SKILL.md 开始，然后按技能内部的使用顺序阅读同一文件里链接或提到的上下文：任务生命周期、架构、前置条件、配置，以及文件中嵌入的任何仓库特定引用。因为这个仓库没有辅助脚本或额外的参考目录，核心行为都写在技能文件本身里，所以仔细读它很重要。

把粗略目标改写成可用提示词

一个好的 polyphony 提示词应包含：目标 repo、你希望并行的 agent 数量、每个 agent 负责的工作类型、分支或 PR 预期，以及对测试、凭据或清理的任何限制。例如，不要只说“修复这个项目”，而要明确要求“把这个问题拆成三个隔离的 agent 任务：复现、修补、验证，分别使用独立的 Docker 工作区，并按分支汇报落地状态”。

想要更好输出，需要说明什么

给技能更具体的路由信号：任务优先级、依赖关系、是否必须先只读分析、哪些环境适合预配，以及什么算验证。这样可以帮助编排器选择更合适的 RunSpecs，也能减少无谓的容器启动。对于 polyphony 指南来说，最有价值的输入不是更长的描述，而是更清晰的任务边界。

polyphony 技能常见问题

polyphony 只适用于 Docker 环境吗？

是的，实际使用上基本如此。polyphony 技能默认容器隔离可用，所以 Docker 或 OrbStack 支持是它能否落地的主要门槛。如果你无法预配容器，这个工作流的大部分价值都会消失。

polyphony 和普通提示词有什么不同？

有区别。普通提示词只是让 agent 去执行；polyphony 定义的是多个 agent 运行如何被认领、路由、预配、验证以及落地。尤其当你更看重独立分支和干净执行，而不是单纯追求速度时，这种结构正是 polyphony 技能的核心价值。

初学者可以用 polyphony 吗？

可以，只要你已经能运行容器并读懂技能文件。主要的学习曲线不在于提示词怎么写，而在于理解 polyphony 预期你先拆解任务、并准备好环境。初学者通常从一个小任务和一个明确的验证目标开始，效果会更好。

什么情况下不该用 polyphony？

不要把 polyphony 用在临时的快速问答、轻量编辑，或者没有 Docker 的环境里。当任务本身很模糊、你还没有明确每个 agent 应该负责什么时，它也不合适，因为编排开销可能会超过收益。

如何改进 polyphony 技能

给路由器更清晰的任务边界

在 polyphony 里，最大的质量提升通常来自更清楚的任务拆分。要明确哪些工作是探索性的，哪些工作会改代码，哪些工作只负责验证。如果你想并行，就要把分工直接写出来，而不是让系统从含糊的目标里自己推断。

补充会影响工作区行为的约束

说明分支命名规则、网络限制、测试耗时预期，以及是否需要 secrets 或挂载身份。因为 polyphony 使用的是隔离容器和独立分支，这些约束会直接影响资源预配，以及一次运行能否在不人工介入的情况下完成。

要求验证，不要只要求实现

常见失败模式是停在“代码已经改了”。更好的 polyphony 用法会为每条 agent 路径要求复现步骤、测试命令和落地标准。尤其在多个 worker 可能收敛到不同方案时，这一点非常重要，因为你需要可靠的合并决策依据。

第一次运行后继续迭代

如果第一次输出太宽泛，就收窄任务，并带着单一成功标准重新运行。如果结果太碎片化，就减少并行 agent 数量，并在各阶段之间加更强的依赖关系。对于 polyphony 来说，改进通常来自更精准的编排输入，而不是更长的提示词。