ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Multica 怎么把本地目录作为项目资源,并用 worktree 模式让任务并行

Multica 怎么把本地目录作为项目资源,并用 worktree 模式让任务并行 Multica 怎么把本地目录作为项目资源并用 worktree 模式让任务并行【免费下载链接】multicaMake humans and AI agents work as one team — open-source and self-hostable.项目地址: https://gitcode.com/GitHub_Trending/mu/multica如果你有一个已经 checkout 到本地的代码仓库典型场景是几十 GB 的大仓库每次运行都重新 clone 不现实希望 Multica 的 agent 直接在这个目录上干活同时又担心多个 issue 的运行互相排队、或者污染你正在编辑的工作区——那么正确做法是把这个本地目录作为项目资源local_directory链接到项目上并把执行模式设为worktreeDesktop 界面里叫Parallel。这样每个运行都拿到独立的 git worktree 并行执行结果以分支形式交回你的仓库而不是串行等待、也不是直接改你当前的分支。本文基于仓库文档 Project resources 和 Using the CLI覆盖从添加目录、选择模式到验证并行结果的完整操作。准备条件添加本地目录资源的前提来自文档界面入口只在 Desktop 端浏览器无法在电脑上选择文件夹所以“添加本地目录”的 UI 是 Desktop-only 的。Desktop 支持 macOS、Windows、Linux安装后登录即会自动启动内置 daemon见 Desktop app。当然用 CLI 添加不需要 Desktop。目录必须通过校验绝对路径、已存在、当前 daemon 对其有读写权限。以下路径会被拒绝系统根和盘符根/、C:\、主目录本身及其父目录如/Users、/home、/root、以及/etc、/var、/tmp、/usr、/opt等系统目录。如果路径是符号链接会先解析到真实路径再按同样规则校验串行锁也作用在真实路径上。每个项目在每个 daemon 上最多链接一个本地目录。团队里不同的电脑可以为同一个项目各自链接自己的目录本地目录只对绑定它的那个 daemon 生效其他机器继续用项目的 GitHub 仓库或 workspace 仓库。要启用 worktree 模式目录必须是一个 git 仓库且至少有一个 commit并且那台机器上的 runtime 在连接时声明了支持该模式Multica 以能力声明为准而不是版本号。这个能力会被检查两次保存资源时runtime 未声明就会拒绝保存并提示更新那台机器上的 app每次运行被 runtime 认领时再检查一次——如果资源保存后机器被降级运行会带着原因被取消而不是悄悄改在原地执行。添加本地目录作为项目资源方式一Desktop 界面确认 Desktop 的本地 daemon 在线可在 Desktop 的设置中查看 runtime 状态和日志。打开项目的Resources或在创建项目对话框的Local directory标签里操作——项目还没建好时也能先选。选择 Add local directory然后挑选要使用的文件夹。选择运行方式——Directin_place或Parallelworktree。Desktop 会在该文件夹是 runtime 能隔离的 git 仓库时预选Parallel否则预选Direct可以当场改也可以之后在Resources里用目录旁的铅笔图标修改。注意预选只针对你正在链接的目录。之前链接过的目录保持它当初保存的模式已有的配置不会被悄悄切换。方式二CLI# 链接本地目录到某个 daemon默认 in_place 模式 multica project resource add project-id \ --type local_directory \ --local-path /absolute/path/to/repo \ --daemon-id daemon-id # 链接本地 git 仓库并让各运行在自己的 worktree 里并行执行 multica project resource add project-id \ --type local_directory \ --local-path /absolute/path/to/repo \ --daemon-id daemon-id \ --execution-mode worktreeproject-id与daemon-id需要替换为实际 IDlist类命令通常打印可复制的短 ID并支持--full-id。确认资源已添加multica project resource list project-id已有目录之后想切换模式multica project resource update project-id resource-id --execution-mode worktree multica project resource update project-id resource-id --execution-mode in_place资源变更只影响之后创建的运行不会改写已经结束的运行的记录。worktreeParallel模式下发生什么文档对两个模式的定义in_placeDirect默认agent 直接在你的目录里工作运行一次只跑一个。两个运行命中同一个真实目录时后一个进入waiting_local_directory状态等前一个释放目录后继续通过不同符号链接到达同一目录的两种路径也这样串行。等待不会修改目录等待中的运行可以取消。worktreeParallel每个运行获得你仓库的独立 git worktree创建在 runtime 自己的工作区目录里。同一目录上的运行并发执行互不等待也都不写你的工作副本。如果目录不是满足条件的 git 仓库运行会带着明确错误失败而不是悄悄退回串行。worktree 模式下 agent 看到的和你拿到的agent 从“你现在看到的”开始而不是从HEAD。你的未提交修改和未跟踪文件会被重放replay进 worktree你自己的工作副本、索引和 stash 列表绝不被触碰。如果状态无法忠实复现——包括未跟踪内容超出重放覆盖范围2000 个文件 / 200 MiB——运行会失败而不是从一个你不认识的树开始。常见解法是把没被忽略的构建产物加进.gitignore或清理掉。结果是你仓库里的一个分支按 issue 而不是按运行命名agent/agent/issue聊天会话是agent/agent/chat-session。运行的Run details面板会显示分支名可复制也可以用git branch找到它用git log/git diff审查然后自己 merge 或 cherry-pick。Multica 从不替你合并。中途失败的运行也会报告它的分支因为它把 agent 产出的内容提交了。后续评论接着上一次停下的地方继续。同一 issue 的下一条评论会再检出那个分支agent 站在它刚交付的工作上而不是带着别的分支上的改动从HEAD重新开始只有你自上次运行以来在自己目录里改的内容会被叠加重放。分支合并后下一次运行又从你的HEAD开始。同一 issue 上两个运行重叠时第二个会从第一个的工作分叉到agent/agent/issue-task因为 git 允许一个分支只对应一个 worktree。你的修改与 agent 冲突时由 agent 去解决。如果你改写了 agent 改过的同一批行运行会启动在一个带冲突的 worktree 上并被要求先完成合并——该 worktree 里git status会列出未合并的路径。只要还有文件未合并运行就交付不了任何东西它失败、保留 worktree下一次运行再次提供同样的编辑你的改动不会被悄悄丢掉。只有 Multica 拥有所有权的分支才会被继续。是否继续由所有权记录决定而不是分支名你自己建的、恰好叫agent/agent/issue的分支永远不会被检出或当作之前的运行读取。每个分支以自己的一个基线 commit 开头标记第一次运行开始时的树——git diff baseline..branch恰好就是 agent 的工作。没有东西被悄悄丢弃。agent 留下的未提交内容包括运行中途失败时会在 worktree 移除前被提交到那个分支。极端情况下例如仓库设了commit.gpgSign而 runtime 没有可用的签名密钥这个提交做不出来时worktree 会被故意保留运行报失败此时你仓库里的git worktree list指向放着这些工作的目录。worktree 位于 runtime 的工作区目录按正常清理周期回收。你的仓库里持久存在两样东西那个分支以及每个分支在refs/multica/local-state/下的一个隐藏 ref记录所有权和你上次继续时目录的样子。隐藏 ref 不会出现在git branch里用git for-each-ref refs/multica可以列出。Multica 会随分支一起删除它们并在下次该仓库有运行时清掉那些你已自行删除分支的孤儿 ref——或者一次性手动移除git for-each-ref --format%(refname) refs/multica | xargs -n1 git update-ref -d这条命令会删除当前仓库中所有refs/multica下的 ref执行前确认你确实不再需要这些所有权记录。验证并行与结果按下面的顺序核对判断设置是否真正生效不再出现waiting_local_directory。该运行状态的含义是“目标本地目录正被另一个运行占用等待目录锁释放”见 Tasks。文档明确指出这种等待只存在于in_placeDirect模式目录是 git 仓库时把资源切到worktreeParallel就彻底去掉队列——每个运行有独立 worktree把工作以分支交回谁也不用等谁见 Troubleshooting。Run details 面板显示分支名在你的仓库里git branch能看到agent/agent/issue用git log/git diff baseline..branch审查 agent 的改动。git for-each-ref refs/multica能列出对应分支的隐藏所有权 ref说明 worktree 运行确实按机制落地了。审查通过后自行 merge 或 cherry-pick 分支合并之后下一次运行会重新从你的HEAD开始。排错与限制怀疑锁状态异常时in_place的目录互斥锁在 daemon 内存里没有锁文件写到磁盘无需手动删除。multica daemon restart即可释放。自托管运维注意文档中的警告worktree 模式的隔离由服务端强制执行保存时 runtime 认领每次运行时。没被兜住的组合是——把服务端回滚到早于该特性的版本而仍有未实现该模式的 runtime 连接着老服务端没有这道门这类 runtime 会忽略execution_mode并直接在原地执行运行。只要还存在worktree资源不要把服务端回滚到该版本之前除非相关机器上的 runtime 都已更新到位。非 git 目录只能串行。worktree 模式只覆盖 git 仓库普通非 git 目录仍然是in_place的用途场景。重放上限未跟踪内容超过 2000 个文件 / 200 MiB 时运行直接失败处理方式是 gitignore 或清理未忽略的构建产物。运行期间写入的辅助文件除 agent 的代码改动外runtime 可能把当前 AI 编码工具需要的指令文件以及.multica/project/resources.json写进目录不想入库就加进.gitignore。Multica 在清理运行环境时从不删除被链接的本地目录agent 对该目录的改动与你自己在终端里跑 AI 编码工具的改动同级需要同样的审查。下一步想了解项目上下文、进度与负责人见 Projects。想知道运行会被哪台电脑认领见 Daemons and runtimes。运行状态包括waiting_local_directory的完整说明见 Runs。【免费下载链接】multicaMake humans and AI agents work as one team — open-source and self-hostable.项目地址: https://gitcode.com/GitHub_Trending/mu/multica创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表