ARTICLE · 1249289
指挥 4 个 AI 智能体干活是什么体验?
深夜十一点，你盯着终端里的 AI 编程工具一遍遍重跑同一条命令。它忘了昨天刚说过的项目约定，你第五次把同样的要求贴进对话框，顺手把「以后新会话先读一遍项目说明」也贴了进去——虽然你知道，下次开新窗口，一切还是从零开始。
单个 AI 编程工具确实猛，但所有衔接都要你来做：你派活、你验收、你审查一份自己看不太懂的 PR。用了三周后我发现，自己不是在写代码，是在当人肉调度器——而且这个调度器没有交接文档。
真正缺的不是更强的模型，是一套让「人和智能体、智能体和智能体」协作的工作方式。我用 Multica 从空工作区开始，跑完了建站、审查、组队、自动化的完整流程。这篇是实践记录。
一、先把问题看清楚
·上下文断层：每次新会话都是第一次见面，项目约定靠人肉复述，纠正十次也不会自己长进去
·单点审查：同一个模型写的代码交给同一个模型审，盲区高度重叠，查了个寂寞
·经验不留存：口头提醒不进配置，同一个错误第 11 次还会犯
·协调成本：派活、催办、验收全压在人身上，工具越强，人越像客服
问题不在模型能力，在协作基建——这句话值得写在每个自动化项目的开头。
二、连上你的电脑：智能体先要有手
下载 Multica Desktop 并登录，它会自动把这台电脑注册为运行时，并检测已安装的 AI 编程工具（Claude Code、Codex 等）。打开侧边栏底部的 配置 → 运行时，确认电脑在线，点进去能看到检测出的每一款工具。
不用 Desktop 也可以：在运行时页面点 添加电脑，按提示用命令行安装守护进程，常驻后台跑。关键是智能体用的就是你这台电脑上的工具链，文件、Git、依赖都在本地，不是云端黑盒。
三、创建智能体：先养一个不管代码的总管
打开 智能体 → 新建 → 从空白开始，填四项：名称、运行时、模型、指令。第一个智能体我建了 helper，负责工作区日常事务。指令直接决定了它的边界：
You are the helper of this workspace.You handle what members ask for in issues and chat:create or update issues, adjust statuses, answer questions.Keep replies short. Do not touch code or repositories.If a request is ambiguous, ask before acting.
第二个智能体（写代码的 Engineer）没有填表单——打开聊天跟 helper 说「在这台电脑上创建一名叫 Engineer 的智能体，模型用 Opus，负责维护个人网站」。创建这件事本身也是任务，helper 执行完回复名称和模型。心得：指令里写清不负责什么，比写负责什么更重要。
四、任务驱动：描述写意图，实现留白
按快捷键 `C` 新建任务。智能体模式下不用填标题，创建者选 Engineer，需求直接写进描述。一条合格的描述有三类信息：约束、内容要求、留白。以建摄影师网站为例：
Work in the personal-website repository.Start from a template, not from scratch:pnpm dlx shadcn@latest init --preset b5rR41Mtnc --template nextCommit the template as-is, then build on top of it.The site needs: Introduction / My work / Contact / Pricing.Design: refined and understated; never use words like"premium" or "high-end" in the copy.Open a pull request when it is ready.
提交后任务编号 MUL-1 自动生成，Engineer 立刻进入「进行中」。右侧的执行日志能看到每一步：Agent 行是它的说明，Bash、Read、Edit 是它真实运行的命令和读写的文件；点右上角 ⓘ 还能看到这次执行用的电脑、工具和工作目录。
五、交叉审查：让另一个模型找你找不到的问题
执行完，Engineer 把状态改为「审核中」，通知进收件箱。页面右下角的聊天按钮可以随时 @ 引用当前任务，让它启动本地服务、补 PR 编号。第一个坑：PR 没有自动关联到任务——标题、分支名、正文里都没有 MUL-1，编号补进标题后才关联上。引用了任务编号的 PR 才会自动关联，PR 状态和 CI 结果直接显示在任务里。
审查交给新智能体 Reviewer：Codex + GPT-5.6，和 Engineer 的工具、模型都不同，只审不改，结论写成带文件和行号的任务评论。第一轮审查 5 条发现：代码规范 3 条、需求符合度 2 条——后者正是 Engineer 自己意识不到的（把虚构价格当正式内容展示、放了没核实的链接）。评论区 @Engineer 修完，Reviewer 复查通过。不同工具、不同模型交叉审查，是性价比最高的一道质检。
六、把反馈写进指令，而不是每次口头提醒
这轮验收暴露了两个重复出现的习惯：完成后反复截图自查（占掉大量执行时间）、提交 PR 不带任务编号。两个都不是偶然失误，改的不能是这条任务，而是它的指令。在对话里让 Engineer 用 `multica agent update` 把两条规则写进自己的指令：验收在浏览器里进行，PR 分支名或标题必须带任务编号。它同时指出了代价：不再截图自查，页面视觉问题要靠你在浏览器里发现。发现重复问题 → 写进指令，这是调优智能体的基本方式。
七、小队与 Skill：把协调也交出去
MUL-1 跑通后，每次衔接仍由你发起：验收后 @Reviewer，审查后 @Engineer。协调本身成了你的工作。解法是小队（squad）：一组智能体加一名队长。Lead 负责读任务、派活、推进状态、向你汇报，自己不动手；Engineer 开发，Reviewer 审查，你做最终验收。
Skill 是可复用的方法包：一个 SKILL.md 加支持文件，符合 Anthropic Agent Skills 开放标准，挂到智能体后执行时自动同步到运行时。我给 Engineer 挂了 tdd（先写失败测试，再写恰好通过的实现），给 Lead 挂了 i-have-adhd（汇报第一行永远是可执行的下一步）——队长的产出全是发给你的汇报，这个 skill 决定你读到的样子。注意：导入第三方 skill 前先读一遍它的文件，Multica 不做沙盒隔离，内容原样交给 AI 编程工具。
八、自动化：定时开工的第四种触发
此前的触发都由你发起：分配、提及、对话。自动化按时间自动开工。配置只需一句话：告诉 helper「每周一早上九点，让 Reviewer 对代码库做一次全面检查，发现写进任务评论，不改代码」。执行模式两种：创建任务（默认，历史落看板，适合定期检查）和 仅运行（没发现就不留痕）。触发器除定时（cron + 时区）外还支持 webhook，执行者也可以指向小队。
九、四个反模式
① 把实现方式写进任务描述
命令、步骤、文件名全指定，智能体失去判断空间。写意图和边界，实现留白。
② 让同一个模型自产自审
盲区重叠，审查形同虚设。换工具、换模型，哪怕审查者只会提问题。
③ 每次口头提醒代替改指令
纠正不沉淀，第 11 次还犯。重复出现的问题必须写进指令。
④ 描述含糊又不许它问
指令里没有 ask before acting，它就猜着做，返工比询问贵得多。
十、怎么衡量有没有变好
1.你的介入次数：每条任务从 N 次衔接降到 1 次验收，小队跑通后应趋近于零
2.同类问题重复出现次数：写进指令后应归零，没归零说明规则写得不够具体
3.PR 自动关联率：编号规则落地后，关联不上的 PR 应基本消失
4.时间线完整度：任务状态、PR、CI、审查评论是否都落在同一条时间线里
图：人和智能体协作的闭环，每一环都有沉淀物
· · ·
回头看这条路径：从空工作区开始，连电脑、建智能体、跑任务、组小队、配自动化，你的参与逐级后撤，最后只剩两件事——描述需求，验收结果。你在用类似方式指挥智能体吗？评论区聊聊。
