Symphony 如何实现每个 Issue 独立工作区隔离AI 智能体自主执行环境设计深度剖析【免费下载链接】symphonySymphony turns project work into isolated, autonomous implementation runs, allowing teams to manage work instead of supervising coding agents.项目地址: https://gitcode.com/gh_mirrors/symphony7/symphonySymphony 是一款将项目任务Issue转化为隔离、自主实施运行的 AI 智能体编排工具它为每个 Issue 创建独立工作区隔离环境让多个编码智能体并行执行而互不干扰。工程师只需管理工作而不用监督每一个智能体。本文带你完整剖析 Symphony 的独立工作区隔离机制、安全防线与生命周期管理。为什么每个 Issue 需要一个独立工作区 想象这样的场景你让 10 个 AI 智能体同时处理 10 个 Issue。如果它们共享同一个代码目录会发生什么智能体 A 正在重构的文件被智能体 B 改坏了一个 Issue 的脏构建产物污染了另一个 Issue 的测试两个智能体对同一个依赖版本各改各的互相冲突Symphony 的答案是一个 Issue 一个专属目录。每个智能体在自己的房间里工作房间之间完全隔离互不可见。这就是 SPEC.md 中定义的核心运行模型之一。隔离目录是如何创建的核心流程拆解工作区的全部创建逻辑集中在 workspace.ex 模块中入口是create_for_issue/2函数。它的工作流程可以概括为 4 步生成防冲突的目录名通过workspace_key函数把 Issue 标识符如MT-725清洗成安全文件名。若标识符包含特殊字符比如AB/12和AB-12清洗后可能撞名Symphony 会自动追加一段 16 位的 SHA-256 短哈希保证目录名永不冲突拼接并规范化路径在配置的工作区根目录下拼出完整路径再经过 path_safety.ex 的canonicalize处理逐级解析软链接得到真实的规范路径创建目录若目录已存在则复用若是普通文件则先清除再重建运行after_create钩子这是开箱即用的关键——你可以在钩子里执行git clone让全新工作区自动获得完整代码副本。若钩子失败Symphony 会清理掉这个半成品目录避免残留垃圾。配置上只需在 WORKFLOW.md 中声明工作区根目录即可workspace: root: ~/code/symphony-workspaces hooks: after_create: | git clone --depth 1 https://example.com/your-org/your-repo.git .未配置时根目录默认为系统临时目录下的symphony_workspaces见 schema.ex 中的workspace.root默认值。安全防线三重机制防止智能体越界隔离不只是各占一个目录Symphony 还从三层保证了智能体无法逃出自己的工作区第一层路径校验。validate_workspace_path会强制检查工作区必须位于根目录之内且不能等于根目录本身若发现软链接指向根目录之外会直接以符号链接逃逸为由拒绝。第二层Codex 线程沙箱。Codex 的thread_sandbox默认值为workspace-write即智能体只能对自己工作区有写权限其他路径只读。第三层逐回合沙箱策略。turn_sandbox_policy默认为workspaceWrite类型且writableRoots精确锁定到当前 Issue 的工作区——即使智能体在同一台机器上它也被物理性地限制在自己的房间里连读别的 Issue 工作区都做不到。横向扩展SSH Worker 上的远程工作区单机不够用时Symphony 支持把工作区创建到远程机器上。在 agent_runner.ex 中每次运行会先选择一个 worker 主机本地或配置的worker.ssh_hosts之一然后本地执行直接在根目录下mkdir创建远程执行通过 SSH 下发一段脚本在远端完成目录创建并用一个特殊标记行回传是否新建 真实路径Symphony 解析后继续后续流程。所有 SSH 操作都带超时保护超时即终止防止远端卡死拖垮整个编排器。配合agent.max_concurrent_agents与worker.max_concurrent_agents_per_host你可以精确控制每台机器上的并发智能体数量。完整生命周期从创建到自动清理工作区不是建完就不管了它围绕 Issue 的状态走完整生命周期四个钩子覆盖每个关键节点钩子触发时机典型用途after_create工作区首次创建后git clone拉取代码、安装依赖before_run智能体启动前环境检查、预热构建缓存after_run智能体运行结束后上传产物、备份日志before_remove目录删除前归档 diff、提取统计数据其中after_create失败会阻断本次运行并清理现场其余钩子失败只记录告警不影响主流程。清理环节由 orchestrator.ex 负责当被认领的 Issue 进入终态Done、Closed、Cancelled等编排器会调用remove_recorded只删除运行时记录的那个精确路径且删除前仍要再次通过路径安全校验——即使记录被篡改指向别处也不会误删。启动时还会做一次终态工作区清扫清掉上次异常退出遗留的目录。快速上手三步配置你的隔离环境 想在自己的项目里体验这套机制克隆仓库git clone https://gitcode.com/gh_mirrors/symphony7/symphony进入elixir/目录准备工作流文件把仓库中的 WORKFLOW.md 拷到你的代码库修改workspace.root指向一个专用目录并在hooks.after_create里写上你的git clone命令启动 Symphony按 elixir/README.md 说明用mise安装依赖后执行./bin/symphony ./WORKFLOW.md可选加--port启动 Web 面板实时观察各智能体的工作区状态。小结Symphony 的每 Issue 独立工作区设计本质上是一套面向并行的智能体隔离方案✅一 Issue 一目录防冲突、可追溯目录名自带哈希防撞✅纵深安全路径规范化 沙箱策略双保险智能体无法越界✅钩子化生命周期创建、运行、清理全程可定制✅弹性扩展本地与 SSH 远程工作区统一抽象天然支持水平扩容理解了这套机制你就能把监督智能体升级为管理工作——这正是 Symphony 想要带来的工作方式变化。【免费下载链接】symphonySymphony turns project work into isolated, autonomous implementation runs, allowing teams to manage work instead of supervising coding agents.项目地址: https://gitcode.com/gh_mirrors/symphony7/symphony创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考