【免费下载链接】firstmateTalk to one agent. Ship with a crew.项目地址https://gitcode.com/gh_mirrors/fi/firstmate点击查看免费下载这篇技术指南完整记录 firstmate 如何把 Atlassian Rovo CLIrovo版本 202609.1.2接入其 crewmate/scout 派发体系涵盖检测、启动、忙碌判定、中断、OAuth、工作区文件访问授权与多后端活跃性验证。读完本文你将掌握 rovo 适配器的完整接入形态bare launch-then-send、其底层 gate 函数的工作机制、allowedExternalPaths工作区外文件访问授权的精确配置方法以及该适配器当前已知的限制与后续验证手段。验证主体与范围这份记录在验证什么docs/verification/rovo.md是 firstmate 为 rovo 适配器建立的经验性证据记录Active empirical evidence它不负责定义操作事实本身操作事实由技能树根节点.agents/skills/harness-adapters/references/harness/rovo.md维护而是记录这些事实是如何被建立、哪些仍未被证明。字段值版本Rovo CLI: 202609.1.2验证时间2026-09-02herdr 后端活跃性于 2026-09-03 补充二进制形态~/.local/bin/rovo是一个 bash 包装器exec 一个位于~/.local/share/rovo/active/下的 PyArmor 混淆 PyInstaller bundle平台macOS arm64Darwin 25.6.0验证采取了两步策略先由早期的 scout 任务fm-rovo-smoke-s1用手写 PTY VT 模拟器建立基线经验事实无适配器代码、无派发接线再由本任务把可执行的所有者落地到这些事实上并实时复验其中承重的事实——包括 scout 无法测试的两项过期 access token 下的认证刷新以及工具调用中途的 Escape 中断。文中的每条命令都在非沙箱环境下运行因为 rovo 的 OAuth 凭据存放在 macOS 钥匙串中沙箱 shell 无法读取。检测环境变量 marker 与祖先进程回退rovo 的检测入口是bin/fm-harness.sh。代码先测试ATLASSIAN_AGENT_TYPErovo与ROVODEV_CLI1在CLAUDECODE行之前否则回退到祖先进程匹配commrovo# bin/fm-harness.sh [ ${ATLASSIAN_AGENT_TYPE:-} rovo ] { echo rovo; return; } [ ${ROVODEV_CLI:-} 1 ] { echo rovo; return; } # ... 其后才是 comm 回退分支rovo) echo comm rovo; return ;;从 fm-harness.sh 的注释可以看到设计动机rovo 会在其工具子进程上设置ATLASSIAN_AGENT_TYPErovo、ROVODEV_CLI1和AGENTrovodev_cli但它不会清洗继承下来的CLAUDECODE——这意味着从一个 claude 会话里手工启动的 rovo worker 可能同时携带外部 marker。marker 优先级顺序因此被钉死rovo 自己的 marker 胜过继承的CLAUDECODE同时bin/fm-spawn.sh在启动边界额外清除外部 marker 作为纵深防御issue #3517 标记了同一类排序风险cursor 文档也有类似记录。tests/fm-rovo-harness.test.sh用伪造的ps输出钉住了两层行为marker 优先顺序rovo marker 胜过继承的CLAUDECODE以及无 marker 时的祖先回退。注意该测试套件本身先unset CLAUDECODE PI_CODING_AGENT FM_PI_HARNESS GROK_AGENT CURSOR_AGENT CURSOR_INVOKED_AS避免宿主环境残留 marker 干扰伪造祖先的排序验证。启动bare launch-then-sendkimi 形状bin/fm-spawn.sh的 rovo 启动模板fm-spawn.sh构造的是BARE 启动——不带任何位置参数 briefrovo) printf %s env -u CLAUDECODE -u PI_CODING_AGENT -u GROK_AGENT -u FM_PI_HARNESS __ROVOBIN__ run --yolo __MODELFLAG____ROVOCONFIGOVERRIDE__ ;;即env -u CLAUDECODE -u PI_CODING_AGENT -u GROK_AGENT -u FM_PI_HARNESS rovo-bin run --yolo model/effort flags再由所有非 cursor 适配器共享的外层包装统一补上env -u CURSOR_AGENT -u CURSOR_INVOKED_AS前缀。brief 是在 TUI 起来之后才敲进去的——这正是 kimi 使用的 launch-then-send 形状走同一套共享读取函数fm_backend_capture、fm_backend_composer_state、fm_backend_send_text_submit就绪门rovo_wait_for_readyfm-spawn.sh轮询捕获的 pane主信号是Welcome to Rovo!ASCII 横幅弱回退是 composer-empty 判定更弱的原因见下文 composer ghost text 缺口。轮询默认FM_ROVO_READY_POLLS60次、间隔FM_ROVO_POLL_INTERVAL0.5秒。键入指针通过fm_backend_send_text_submit提交Read the brief at absolute-path and follow it exactly.投递确认门rovo_wait_for_deliveryfm-spawn.sh要求 composer 为空且满足二选一——pane 中出现回显的Read the brief at文本或Context:百分比已离开零值。真实 footer 形如Context: ▎ 3.3% 30.1K/922Kfm-spawn.sh 中的正则context:[^%]*[1-9][^%]*%容忍栏位字形与冒号后任意空白[^%]*但锚定在%之前的数字上因此分母.../922K中永远非零的总量不可能伪装成非零使用百分比。每个 gate 若迟迟不解析都会在任务状态文件中写入failed:行并大声失败——一个 never-ready 或静默丢弃投递的 pane 会成为可见的 spawn 失败而不是一个半接线的半死 pane。为什么不能使用位置参数 brief位置参数 brief 是落地即死rovo run --yolo brief只会加载一个 spinner从不进入工作状态、不打印任何回复约 10–15 秒后掉回空 idle shell 提示符。这在原始 PTY 上独立复现了四次变化TERM、窗口尺寸、工作区、60–150 秒窗口又在真实 tmux 3.6a 下用fm-spawn.sh精确的 send-keys 形状新窗口、send-keys -l整条启动行、再Enter复现了一次。--startup-receipt也无法挽救这个形状——它在启动前就与任何消息一起被拒绝$ rovo run --startup-receipt receipt.json --yolo Reply with PONG Invalid value: --startup-receipt requires prompt-free interactive mode in a terminal所以它只能门控 bare无消息启动而这个适配器总是要投递消息故不用它。launch-then-send 形状的端到端实时确认在原始 PTY 上驱动的 barerovo run --yolo被确认渲染Welcome to Rovo!就绪横幅接受键入的指针并按之行动一份指示真实sleep 25bash 工具调用的 brief 驱动出Rovo is thinking忙碌行接受工具调用中途的 Escape 并打印Agent cancelled见中断小节/exit干净退出并提示Run rovo --restore id to resume your conversation。tests/fm-rovo-signals-live-e2e.test.sh 就是这条端到端守卫。可移植半部由 tests/fm-rovo-harness.test.sh 用有状态假tmux与假rovo二进制钉住无真实网络与凭据启动命令是 bare 的run --yolo无位置 brief、无--startup-receipt就绪后键入的指针精确为Read the brief at absolute-path and follow it exactly.投递通过 context 百分比或指针回显确认never-ready 假屏幕大声失败drop-submit 假屏幕大声失败model/effort 标志、marker 清除、缺二进制时在任何 pane 存在前就拒绝、以及 crew/scout-only 的 secondmate 拒绝均成立。忙碌状态Rovo is thinking 渲染文本回退实时原始 PTY 下提交一个运行真实sleep 25bash 工具调用的提示会渲染出忙碌行与 footer⬢ Rovo is thinking... Enter to queue, CtrlEnter to steerfm_busy_rovo_tail_busyfm-busy-lib.sh精确匹配这段渲染文本grep -qiE ${FM_BUSY_ROVO_REGEX:-Rovo is thinking}fm_busy_classify被实时与可移植地确认将其判读为busy rovo-regex无忙碌行的 idle footer 判读为idle rovo-regex。这是渲染文本回退与 Grok 完全同类而非语义源rovo 的eventHooks~/.rovo/config.yml只在工具粒度触发on_tool_start/on_tool_end从不在 turn-end 触发因此没有 writer 可武装、也没有 writer 被播种。Grok 曾是重新设计的忙碌契约允许的唯一渲染文本臂本任务把同一文档化例外扩展到 rovo作用域精确到harnessrovo正如 Grok 精确到harnessgrok两者互不误判tests/fm-rovo-harness.test.sh的隔离用例。这也意味着 rovo 没有 turn-end hook没有任何主监督协议与 muse 同类——因此fm-spawn.sh对KINDsecondmate HARNESSrovo直接大声拒绝fm-spawn.shsecondmate 是需要主监督的 firstmate 实例rovo 无钩子面可武装其 watch 周期。Composer 幽灵文本已测量、刻意保留未修实时 idle-composer 捕获在原始 PTY 上定位到了内联占位 chip——它位于实际的边框内容行内而不是下方建议列表里row 10 ╭──────────────────────────────────────╮ row 11 │ Summarize my open tasks │ fg 38;2;162;163;165 (luminance ~163) row 12 ╰──────────────────────────────────────╯同一行中真实键入的文本另行捕获渲染为38;2;206;207;210luminance ~207。两个值都高于bin/fm-composer-lib.sh的默认FM_COMPOSER_GHOST_LUMA_MAX128所以fm_composer_strip_ghost不去除该占位符全新 rovo composer 可能被误判为pending而非empty。提高共享默认值曾被考虑并否决muse 自己的、绝不能剥离的真实提示字形测得 luminance 约 149.9见 docs/verification/muse.md低于 rovo 幽灵的 ~163因此不存在一个单一全局阈值能同时保住 muse 的真实字形、又去掉 rovo 的幽灵 chip。此事记为已知缺口而非打补丁安全修复需要一个共享 composer 分类器今天不携带的 harness 作用域信号而阈值改动可能在 rovo 作用域修复中回归 muse 已被凭据背书的行为。爆炸半径被限定在 composer-emptiness 消费者如 steering 投递非empty读到时它会沿 doorbell 阶梯重试。它不阻塞就绪就绪以Welcome to Rovo!横幅打头幽灵 chip 从不是那里的决定信号。但投递要求 composer-empty 作为一个合取项与指针回显或非零Context:百分比并列在 herdr 后端上该合取项可能在轮询窗口内无法稳定下方实时 herdr 运行中即使 mid-turn composer 读也非空所以rovo_wait_for_delivery可能在彼处失败门控并拆除 pane。tmux 投递被单独验证为可用见后端活跃性小节。这是记录在案的已知限制修复作为独立 follow-up 跟踪不在本次改动中解决。中断真实 tmux 下确认的 Escape 与Agent cancelledfm-rovo-smoke-s1scout 报告记录了单次 Escape 在运行中的工具调用期间打印Agent cancelled使用其自研 PTY VT 模拟器。真实 tmux 3.6a 下的后续实时检查复现了 scout 的精确发现在真实 mid-flight bash 工具调用期间发送单个 Escape捕获 pane 中打印出Agent cancelled——发生在隔离的tmux -L private-socket会话/窗口中而非共享 fleet 会话。launch-then-send 实时守卫tests/fm-rovo-signals-live-e2e.test.sh也在原始 PTY 上复现它早期单个固定定时器 Escape 在那里落点不可靠bare PTY 上中断送达的精确时刻是时间敏感的单个固定 Escape 可能落在状态之间因此守卫现在在整个实时sleep 25工具调用窗口内持续发送 Escape直到 cancel 渲染。这在每次运行都复现出Agent cancelled通常在前几次尝试内、工具调用约 8 秒处稳定落点一个从不渲染 cancel 的会话会耗尽所有尝试并失败。会话从未被卡死Escape 之后紧接的/exit仍干净退出并提示Run rovo --restore id to resume your conversation。bin/fm-control-lib.sh 把 rovo 的fm_control_interrupt_ack_source记录为none——与 claude、codex、grok、kimi、cursor 已做的保守选择相同这是控制面事实与渲染是否恰好出现无关因为对这五个适配器控制面都不依赖渲染确认。Escape 是记录的 interrupt key其渲染证据现在在真实 tmux 与原始 PTY 两处都被证实而非与代码相互矛盾。OAuth token 生命周期与静默刷新captain 纠正了本任务最初把约 1 小时 access-token 生命周期当作硬性 mid-task 阻塞的简报本任务自身的实时证据确认了纠正后的模型$ rovo auth status authenticated — Access token expired (2026-09-02 13:39:55 UTC), but a refresh token is present. $ rovo run --yolo --output-file out.json Reply with exactly the single word PONG and nothing else. Run rovo --restore session-id to resume your conversation $ cat out.json PONG $ rovo auth status authenticated — Access token valid, expires in 3574s (2026-09-02 15:15:40 UTC).第一次与第二次rovo auth status之间没有浏览器提示、没有交互步骤、没有可见中断中间那次rovo run从存储的 refresh token静默刷新了 access token。要把约 1 小时 access-token 生命周期当作普通运维事实而非不可协商的安全阻塞rovo auth login交互式浏览器 OAuth只在约四周闲置或 refresh token 失效后才需要而不是 mid-task。这也意味着 rovo 的 crewmate 不需要为存活该周期而刻意缩短任务切片。Effort 与模型agent.efficiencyLevel接受low|medium|high|max通过--config-override实时生效请求不支持的xhigh会记录进任务元数据但从该 JSON 对象中省略——两者都在假二进制套件中验证。关键坑在于--config-override是单值的第二次出现会静默丢弃第一次而非合并通过反转两个--config-override标志的顺序并观察先者的效果消失而实时确认。因此fm-spawn.sh的rovo_config_override_flag把agent.efficiencyLevel折叠进与强制allowedExternalPaths授权同一个 JSON 对象而不是发出两个标志假二进制套件钉住恰好一次--config-override出现同时携带两者。模型发现是按账户的/models或 ACPsession/new观察到的实时列表GPT-5.6 Terra/Sol/Luna、GPT-5.5、GPT-5.4、若干 Claude Sonnet/Opus/Haiku id、Gemini 3 id记录在.agents/skills/harness-adapters/references/harness/rovo.md中绝不能硬编码。工作区限制与 allowedExternalPaths 修复标准 crewmate 流程需要 rovo worker 读取自己的 brief 与 steering 消息并写入状态与报告——这些文件都在 firstmate home 中位于任务的 git worktree之外。默认情况下 rovo 把每个文件工具操作open_files、create_file、grep、expand_folder……都限制在启动它的工作区内且其 bash 工具独立拒绝同样的外部路径无论是否授权。这在隔离 scratch 工作区内用裸rovo run --yolo实时确认$ cat $LAB/outside/secret.txt OUTSIDE_SECRET_TOKEN_12345 $ rovo run --yolo Use your file-opening tool (not bash) to open and read the file $LAB/outside/secret.txt, then report its exact contents. --output-file out.txt $ cat out.txt Sorry, I cant access or read files outside the current workspace, including that temporary-system path. If you copy the file into the workspace or paste its contents here, I can help inspect it. $ rovo run --yolo Run this exact bash command and nothing else: cat $LAB/outside/secret.txt --output-file out.txt $ cat out.txt Captain, I cant run that command because it attempts to read a file outside the workspace, which Im not permitted to access. Would you like to provide the files contents here instead?toolPermissions.allowedExternalPaths~/.rovo/config.yml默认[]是唯一的提升手段且必须在启动时通过--config-override授予进程已在运行后没有实时升级。授权后同一文件、同一文件工具实时确认$ rovo run --yolo --config-override {toolPermissions:{allowedExternalPaths:[$LAB/outside]}} \ Use your file-opening tool (not bash) to open and read the file $LAB/outside/secret.txt, then report its exact contents. --output-file out.txt $ cat out.txt OUTSIDE_SECRET_TOKEN_12345授权只提升文件工具。rovo 的 bash 工具无论授权如何都保持 worktree 限制同一授权仍生效时实时确认$ rovo run --yolo --config-override {toolPermissions:{allowedExternalPaths:[$LAB/outside]}} \ Run this exact bash command: echo hello $LAB/outside/status.txt --output-file out.txt $ cat out.txt I cant run that command because it modifies a file outside the workspace. If you provide a workspace-relative path, I can run the equivalent command there - would you like to do that?这之所以重要是因为标准 crewmate 契约的字面状态行就是一条 bashecho ... status_file命令。面对这条精确字面指令rovo 通过自行回退到原生文件工具做同样的追加而自愈成功且保留文件既有内容$ echo existing: prior $LAB/outside/status2.txt $ rovo run --yolo --config-override {toolPermissions:{allowedExternalPaths:[$LAB/outside]}} \ Report status by appending one line: echo working: test line $LAB/outside/status2.txt --output-file out.txt $ cat out.txt Appended working: test line to status2.txt. What would you like to do next? $ cat $LAB/outside/status2.txt existing: prior working: test line同一授权在目录粒度上还覆盖列目录、读取其中文件、以及把文件移动而非复制进handled/子目录——这正是 steering-inbox 确认契约bin/fm-task-inbox-lib.sh需要的精确形状针对预先存在的inbox/handled/目录一次实时确认$ rovo run --yolo --config-override {toolPermissions:{allowedExternalPaths:[$LAB/outside]}} \ List the directory $LAB/outside/inbox for *.msg files, read 001.msg, then move it into $LAB/outside/inbox/handled/001.msg (a rename/move, not a copy-and-delete you narrate but dont do). --output-file out.txt $ ls $LAB/outside/inbox/handled 001.msgfm-spawn.sh的rovo_config_override_flagfm-spawn.sh为每次 rovo 启动构建一个合并 JSON 对象为何必须是一个见上文 Effort总是为精确三个真实symlink 解析后、作用域到本任务的路径授予toolPermissions.allowedExternalPathsbrief 目录data/id/覆盖brief.md/launch-brief.md/report.mdsteering inbox 目录state/id.inbox/覆盖每条 steer 及其handled/确认status 文件本身state/id.status。代码通过cd $data_dir pwd -P解析真实路径与BRIEF_REAL的解析保持一致。tests/fm-rovo-signals-live-e2e.test.sh把这一形状端到端扩展进 launch-then-send 实时守卫用生产--config-override授权启动的真实 rovo 进程读取外部 brief 并追加外部 status 文件保留既有内容同一 brief 与 status 文件在无授权启动时保持原封不动、而转录显示 rovo 自己的拒绝——证明该修复关闭了缺口而不只是加了未测试的标志。tests/fm-rovo-harness.test.sh在假二进制套件中钉住可移植半部三个路径出现在每次 rovo 启动中包括请求的 effort 不支持而被省略时且恰好一次--config-override出现。后端活跃性tmux 已实时验证herdr 已实时验证但存在 herdr 侧 agent 检测缺口tmux 3.6a 现已安装并在隔离的tmux -L private-socket会话中实时演练因此 tmux pane 活跃性完全验证而非待定。bin/fm-agent-process-lib.sh的fm_agent_process_classify_name当时仍在bin/backends/tmux.sh内把*rovo*与其他 glob 化的 harness 名并列匹配因此 rovo pane 判为agent而非other。两个独立名称源按设计工作#{pane_current_command}报告截断的磁盘二进制名atlassian_cli_r——macOS 15 字符comm截断把atlassian_cli_rovodev恰好在rovo子串开始前切断与 docs/verification/runtime-backends.md 已为 codex/kimi 自身 patch-release 名称漂移记录的截断易变类相同——而前台基于ps的comm正确报告rovofm_backend_tmux_agent_state通过该主源正确返回alive。双独立名称源设计正是截断怪癖不破坏判定的原因。tmux capture-pane在真实sleep型 bash 工具调用运行期间正确渲染 box composer 与Rovo is thinking...忙碌行fm_busy_rovo_tail_busy判为 busy工具调用完成、回复落定后判为 idle。中断小节的 Escape/Agent cancelled证据正是捕获于同一实时 tmux 会话。/exit干净关闭 tmux 窗口fm_backend_tmux_agent_state随即报告missing——干净、无歧义的退出判定。完整fm-spawn.sh --backend herdr放置无法从本机驱动到底本任务自身的 agent 进程运行在共享生产 Herdr 会话内因此fm-spawn.sh的跨会话 launcher 身份守卫正确地拒绝从该环境父身份向任何其他会话放置 worker pane而强制放入共享default会话被判定为对实时、人工观察的 fleet 的不可接受干扰。该守卫只作用于fm-spawn.sh自身的任务/worktree 编排不作用于其调用的底层原语因此本任务改为直接在由bin/fm-herdr-lab.sh创建的隔离非default会话上驱动这些原语fleet-state tripwire 确认实时default会话前后未变herdr workspace create/pane list用于放置从fm-spawn.sh逐字提取的rovo_capture/rovo_wait_for_ready/rovo_delivery_is_confirmed/rovo_wait_for_deliverygate 函数以及来自bin/fm-backend.sh与bin/backends/herdr.sh的fm_backend_capture/fm_backend_send_text_submit/fm_backend_agent_state$ herdr workspace create --label rovo-verify --cwd ~/.fm-herdr-rovo-verify-scratch --no-focus --session fm-lab-... {result:{root_pane:{pane_id:w1:p1,...},workspace:{workspace_id:w1,...},...}} $ herdr pane list --workspace w1 --session fm-lab-... {result:{panes:[{pane_id:w1:p1,cwd:/Users/.../.fm-herdr-rovo-verify-scratch,...}]}}rovo pane 被放进该隔离工作区以 bare 启动上面记录的同一env -u ... rovo run --yolo模板rovo_wait_for_ready在Welcome to Rovo!横幅上返回成功。键入的指针Read the brief at path and follow it exactly.回显进 panerovo 读取一份平凡 no-op brief、运行真实sleep 15bash 工具调用、回复PONG——同一 launch-then-send 形状已在 tmux 与原始 PTY 验证现又在 Herdr 上实时确认。fm_backend_herdr_capture在工具调用期间正确渲染Rovo is thinking...忙碌行fm_busy_rovo_tail_busy匹配该捕获文本工具调用结束后 pane 读为 idle 且可见PONGrovo_wait_for_delivery自身的 composer-empty 合取项未在轮询窗口内稳定——与下方已记录的 composer-ghost-text 缺口一致而非新缺陷。fm_backend_agent_state是本运行中唯一被证伪而非证实的信号它在就绪横幅、mid-tool-call busy、idle-with-PONG全程报告dead——尽管 rovo 全程明显活着并在响应。原因在 Herdr 侧而非 firstmate 侧fm_backend_herdr_pane_agent_state调用herdr agent get pane对活 rovo pane 返回{error:{code:agent_not_found,message:agent target w1:p1 not found}}因为herdr integration status列出的已知集成里根本没有rovo安装的 Herdr build 只认识pi、omp、claude、codex、copilot、devin、droid、kimi、opencode、kilo、hermes、qodercli、qwen、cursor、mastracode、antigravity-cli、grok。Herdr 尚未为 rovo 提供 agent 检测因此恢复逻辑依赖的分类器fm_backend_agent_state的alive/dead区分以及fm_backend_herdr_tab_is_husk对它的复用目前无法在 herdr 后端区分活 rovo pane 与空 pane放在backendherdr上的活 rovo worker 有被任何信任该分类器的恢复路径误判为无 agent husk 的风险。这记为已知 Herdr 侧集成缺口而非 firstmate bug并在本处刻意不修补在未冒给某个无关 idle shell 制造假阳性alive判定风险的情况下没有安全的 herdr 作用域 workaround因此backendherdr对启动 rovo crewmate/scout仍可用但在 Herdr 发布 rovo 检测或bin/backends/herdr.sh像bin/backends/tmux.sh那样获得独立基于进程的回退之前对自动 dead/husk 恢复未验证。/exit把 pane 还给 idle shell 提示符而非关闭它不同于关闭整个窗口的 tmux因此退出后fm_backend_agent_state读dead对无 agent 但存在的 pane 是文本上正确的判定真正的发现只是 rovo 实际运行期间的 ready/busy/idle 误分类。Skill 加载互操作缺口已记录未修复⚠ Invalid skill definition in .../.agents/skills/bootstrap-diagnostics/SKILL.md: metadata - internal: Input should be a valid stringrovo 的 skill 加载器拒绝每一个 firstmate skill因为 firstmate frontmatter 里的metadata.internal是布尔值而 rovo 的 schema 要字符串。这阻塞了 rovo worker 内的/no-mistakes及所有其他 firstmate skill 调用直到 firstmate 的SKILL.mdfrontmatter 改为 rovo 兼容——一个独立延期的 follow-up牵涉每个 skill 文件与安装器契约.agents/skills/firstmate-coding-guidelines/SKILL.md。no-mistakes模式的 rovo ship crewmate 被此缺口阻塞不调用任何 skill 的 rovo scout 不受影响。quota-axi provider 映射未建立bin/fm-quota-choose.sh的provider_for_harness没有rovo条目。rovo 通过 Atlassian 自家账户路由到多个不同的底层模型族OpenAI、Anthropic、Gemini而本任务没有发现quota-axi如何或是否建模这一关系的实时证据。与其猜测 provider 族并冒错误配额判定的风险rovo保持缺席于该映射——因此配额平衡派发数组中的rovo候选以unknown harness: rovo失败关闭fails closed而不是被静默误判建立真实映射是 follow-up 工作不属于本适配器。刷新这份记录任何 rovo 升级后都要运行可移植套件与实时守卫因为进程名、marker 集合、渲染的忙碌/中断文本都是厂商控制的表面bin/fm-test-run.sh tests/fm-rovo-harness.test.sh FM_ROVO_SIGNALS_LIVE1 bin/fm-test-run.sh tests/fm-rovo-signals-live-e2e.test.sh实时守卫需要真实的、已认证的rovo二进制但通过原始 PTY 而非 tmux 驱动它因此可在未安装 tmux 的主机上运行tmux 与 herdr 的 pane 放置和活跃性都在实时隔离会话中单独验证见后端活跃性小节其中 herdr agent-state 分类器对 rovo 的盲区被记录为需跟踪的 Herdr 侧集成缺口而非此刷新命令需关闭的实时守卫覆盖缺口。快速参考rovo 适配器操作事实一览结合.agents/skills/harness-adapters/references/harness/rovo.md与本文验证记录可直接引用的关键事实事实值二进制解析resolve_rovo_binaryfm-spawn.sh先解析PATH再回退$HOME/.local/bin/rovo两者都不可执行则拒绝启动启动形状barerovo run --yolo无位置 briefWelcome to Rovo!就绪门 → 键入绝对 brief 指针 → 投递确认门退出命令/exit也支持/quit、idle 单次 Ctrl-C打印Run rovo --restore session-id to resume your conversation中断键单个 Escape打印Agent cancelledack_source记录为none忙碌判定渲染文本Rovo is thinking回退fm_busy_rovo_tail_busy因eventHooks仅工具粒度触发环境 markerATLASSIAN_AGENT_TYPErovo最特异与ROVODEV_CLI1不清洗继承的外部 marker进程名commrovo包装器 exec 世代rovoshimargv[0] 保持rovo磁盘二进制为atlassian_cli_rovodev文件访问默认 worktree 限制allowedExternalPaths仅提升文件工具bash 工具始终受限Effortagent.efficiencyLevellow\|medium\|high\|max默认medium经单值--config-override与授权合并注入此外.agents/skills/harness-adapters/references/harness/rovo.md还记录了一个未来升级路径rovo acpAgent Client Protocol与rovo serve --non-interactive暴露完全结构化、机器可读的 turn 生命周期session/prompt返回真实{stopReason:end_turn}session/cancel是协议原生中断——这是比当前任何适配器更干净的 done 信号但消费它意味着 firstmate 要运行 JSON-RPC 客户端并自持会话生命周期是新的 backend 形状表面而非即插即用 TUI 适配器因此明确属于本 TUI 路径适配器之外、作为 rovo-as-structured-backend follow-up 的刻意未来升级。赞分享【免费下载链接】firstmateTalk to one agent. Ship with a crew.项目地址https://gitcode.com/gh_mirrors/fi/firstmate点击查看免费下载相关推荐firstmate 接入 Atlassian Rovo CLI面向 crewmate/scout 的 TUI 适配器实战指南firstmate 接入 Atlassian Rovo CLI面向 crewmate/scout 的 TUI 适配器实战指南 导读 本文基于 firstmat在 Rovo Dev CLI 中安装与配置 GitHub MCP Server托管远程服务器接入实战指南在 Rovo Dev CLI 中安装与配置 GitHub MCP Server托管远程服务器接入实战指南 本篇指南面向使用 Rovo Dev CLI基于 a后端MCP 服务AI 应用在 Rovo Dev CLI 中安装 GitHub MCP Server远程托管服务接入指南在 Rovo Dev CLI 中安装 GitHub MCP Server远程托管服务接入指南 本指南以 Klavis 开源仓库中 GitHub MCP SerAI 应用LLM 网关MCP 服务工具调用上一篇Vibe Kanban贡献指南如何参与开源项目开发和贡献代码下一篇Arduino WebSocket终极指南打造实时物联网应用的完整教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
firstmate 的 rovo 适配器深度验证指南：Atlassian Rovo CLI 作为 crewmate/scout 的接入实录
【免费下载链接】firstmateTalk to one agent. Ship with a crew.项目地址https://gitcode.com/gh_mirrors/fi/firstmate点击查看免费下载这篇技术指南完整记录 firstmate 如何把 Atlassian Rovo CLIrovo版本 202609.1.2接入其 crewmate/scout 派发体系涵盖检测、启动、忙碌判定、中断、OAuth、工作区文件访问授权与多后端活跃性验证。读完本文你将掌握 rovo 适配器的完整接入形态bare launch-then-send、其底层 gate 函数的工作机制、allowedExternalPaths工作区外文件访问授权的精确配置方法以及该适配器当前已知的限制与后续验证手段。验证主体与范围这份记录在验证什么docs/verification/rovo.md是 firstmate 为 rovo 适配器建立的经验性证据记录Active empirical evidence它不负责定义操作事实本身操作事实由技能树根节点.agents/skills/harness-adapters/references/harness/rovo.md维护而是记录这些事实是如何被建立、哪些仍未被证明。字段值版本Rovo CLI: 202609.1.2验证时间2026-09-02herdr 后端活跃性于 2026-09-03 补充二进制形态~/.local/bin/rovo是一个 bash 包装器exec 一个位于~/.local/share/rovo/active/下的 PyArmor 混淆 PyInstaller bundle平台macOS arm64Darwin 25.6.0验证采取了两步策略先由早期的 scout 任务fm-rovo-smoke-s1用手写 PTY VT 模拟器建立基线经验事实无适配器代码、无派发接线再由本任务把可执行的所有者落地到这些事实上并实时复验其中承重的事实——包括 scout 无法测试的两项过期 access token 下的认证刷新以及工具调用中途的 Escape 中断。文中的每条命令都在非沙箱环境下运行因为 rovo 的 OAuth 凭据存放在 macOS 钥匙串中沙箱 shell 无法读取。检测环境变量 marker 与祖先进程回退rovo 的检测入口是bin/fm-harness.sh。代码先测试ATLASSIAN_AGENT_TYPErovo与ROVODEV_CLI1在CLAUDECODE行之前否则回退到祖先进程匹配commrovo# bin/fm-harness.sh [ ${ATLASSIAN_AGENT_TYPE:-} rovo ] { echo rovo; return; } [ ${ROVODEV_CLI:-} 1 ] { echo rovo; return; } # ... 其后才是 comm 回退分支rovo) echo comm rovo; return ;;从 fm-harness.sh 的注释可以看到设计动机rovo 会在其工具子进程上设置ATLASSIAN_AGENT_TYPErovo、ROVODEV_CLI1和AGENTrovodev_cli但它不会清洗继承下来的CLAUDECODE——这意味着从一个 claude 会话里手工启动的 rovo worker 可能同时携带外部 marker。marker 优先级顺序因此被钉死rovo 自己的 marker 胜过继承的CLAUDECODE同时bin/fm-spawn.sh在启动边界额外清除外部 marker 作为纵深防御issue #3517 标记了同一类排序风险cursor 文档也有类似记录。tests/fm-rovo-harness.test.sh用伪造的ps输出钉住了两层行为marker 优先顺序rovo marker 胜过继承的CLAUDECODE以及无 marker 时的祖先回退。注意该测试套件本身先unset CLAUDECODE PI_CODING_AGENT FM_PI_HARNESS GROK_AGENT CURSOR_AGENT CURSOR_INVOKED_AS避免宿主环境残留 marker 干扰伪造祖先的排序验证。启动bare launch-then-sendkimi 形状bin/fm-spawn.sh的 rovo 启动模板fm-spawn.sh构造的是BARE 启动——不带任何位置参数 briefrovo) printf %s env -u CLAUDECODE -u PI_CODING_AGENT -u GROK_AGENT -u FM_PI_HARNESS __ROVOBIN__ run --yolo __MODELFLAG____ROVOCONFIGOVERRIDE__ ;;即env -u CLAUDECODE -u PI_CODING_AGENT -u GROK_AGENT -u FM_PI_HARNESS rovo-bin run --yolo model/effort flags再由所有非 cursor 适配器共享的外层包装统一补上env -u CURSOR_AGENT -u CURSOR_INVOKED_AS前缀。brief 是在 TUI 起来之后才敲进去的——这正是 kimi 使用的 launch-then-send 形状走同一套共享读取函数fm_backend_capture、fm_backend_composer_state、fm_backend_send_text_submit就绪门rovo_wait_for_readyfm-spawn.sh轮询捕获的 pane主信号是Welcome to Rovo!ASCII 横幅弱回退是 composer-empty 判定更弱的原因见下文 composer ghost text 缺口。轮询默认FM_ROVO_READY_POLLS60次、间隔FM_ROVO_POLL_INTERVAL0.5秒。键入指针通过fm_backend_send_text_submit提交Read the brief at absolute-path and follow it exactly.投递确认门rovo_wait_for_deliveryfm-spawn.sh要求 composer 为空且满足二选一——pane 中出现回显的Read the brief at文本或Context:百分比已离开零值。真实 footer 形如Context: ▎ 3.3% 30.1K/922Kfm-spawn.sh 中的正则context:[^%]*[1-9][^%]*%容忍栏位字形与冒号后任意空白[^%]*但锚定在%之前的数字上因此分母.../922K中永远非零的总量不可能伪装成非零使用百分比。每个 gate 若迟迟不解析都会在任务状态文件中写入failed:行并大声失败——一个 never-ready 或静默丢弃投递的 pane 会成为可见的 spawn 失败而不是一个半接线的半死 pane。为什么不能使用位置参数 brief位置参数 brief 是落地即死rovo run --yolo brief只会加载一个 spinner从不进入工作状态、不打印任何回复约 10–15 秒后掉回空 idle shell 提示符。这在原始 PTY 上独立复现了四次变化TERM、窗口尺寸、工作区、60–150 秒窗口又在真实 tmux 3.6a 下用fm-spawn.sh精确的 send-keys 形状新窗口、send-keys -l整条启动行、再Enter复现了一次。--startup-receipt也无法挽救这个形状——它在启动前就与任何消息一起被拒绝$ rovo run --startup-receipt receipt.json --yolo Reply with PONG Invalid value: --startup-receipt requires prompt-free interactive mode in a terminal所以它只能门控 bare无消息启动而这个适配器总是要投递消息故不用它。launch-then-send 形状的端到端实时确认在原始 PTY 上驱动的 barerovo run --yolo被确认渲染Welcome to Rovo!就绪横幅接受键入的指针并按之行动一份指示真实sleep 25bash 工具调用的 brief 驱动出Rovo is thinking忙碌行接受工具调用中途的 Escape 并打印Agent cancelled见中断小节/exit干净退出并提示Run rovo --restore id to resume your conversation。tests/fm-rovo-signals-live-e2e.test.sh 就是这条端到端守卫。可移植半部由 tests/fm-rovo-harness.test.sh 用有状态假tmux与假rovo二进制钉住无真实网络与凭据启动命令是 bare 的run --yolo无位置 brief、无--startup-receipt就绪后键入的指针精确为Read the brief at absolute-path and follow it exactly.投递通过 context 百分比或指针回显确认never-ready 假屏幕大声失败drop-submit 假屏幕大声失败model/effort 标志、marker 清除、缺二进制时在任何 pane 存在前就拒绝、以及 crew/scout-only 的 secondmate 拒绝均成立。忙碌状态Rovo is thinking 渲染文本回退实时原始 PTY 下提交一个运行真实sleep 25bash 工具调用的提示会渲染出忙碌行与 footer⬢ Rovo is thinking... Enter to queue, CtrlEnter to steerfm_busy_rovo_tail_busyfm-busy-lib.sh精确匹配这段渲染文本grep -qiE ${FM_BUSY_ROVO_REGEX:-Rovo is thinking}fm_busy_classify被实时与可移植地确认将其判读为busy rovo-regex无忙碌行的 idle footer 判读为idle rovo-regex。这是渲染文本回退与 Grok 完全同类而非语义源rovo 的eventHooks~/.rovo/config.yml只在工具粒度触发on_tool_start/on_tool_end从不在 turn-end 触发因此没有 writer 可武装、也没有 writer 被播种。Grok 曾是重新设计的忙碌契约允许的唯一渲染文本臂本任务把同一文档化例外扩展到 rovo作用域精确到harnessrovo正如 Grok 精确到harnessgrok两者互不误判tests/fm-rovo-harness.test.sh的隔离用例。这也意味着 rovo 没有 turn-end hook没有任何主监督协议与 muse 同类——因此fm-spawn.sh对KINDsecondmate HARNESSrovo直接大声拒绝fm-spawn.shsecondmate 是需要主监督的 firstmate 实例rovo 无钩子面可武装其 watch 周期。Composer 幽灵文本已测量、刻意保留未修实时 idle-composer 捕获在原始 PTY 上定位到了内联占位 chip——它位于实际的边框内容行内而不是下方建议列表里row 10 ╭──────────────────────────────────────╮ row 11 │ Summarize my open tasks │ fg 38;2;162;163;165 (luminance ~163) row 12 ╰──────────────────────────────────────╯同一行中真实键入的文本另行捕获渲染为38;2;206;207;210luminance ~207。两个值都高于bin/fm-composer-lib.sh的默认FM_COMPOSER_GHOST_LUMA_MAX128所以fm_composer_strip_ghost不去除该占位符全新 rovo composer 可能被误判为pending而非empty。提高共享默认值曾被考虑并否决muse 自己的、绝不能剥离的真实提示字形测得 luminance 约 149.9见 docs/verification/muse.md低于 rovo 幽灵的 ~163因此不存在一个单一全局阈值能同时保住 muse 的真实字形、又去掉 rovo 的幽灵 chip。此事记为已知缺口而非打补丁安全修复需要一个共享 composer 分类器今天不携带的 harness 作用域信号而阈值改动可能在 rovo 作用域修复中回归 muse 已被凭据背书的行为。爆炸半径被限定在 composer-emptiness 消费者如 steering 投递非empty读到时它会沿 doorbell 阶梯重试。它不阻塞就绪就绪以Welcome to Rovo!横幅打头幽灵 chip 从不是那里的决定信号。但投递要求 composer-empty 作为一个合取项与指针回显或非零Context:百分比并列在 herdr 后端上该合取项可能在轮询窗口内无法稳定下方实时 herdr 运行中即使 mid-turn composer 读也非空所以rovo_wait_for_delivery可能在彼处失败门控并拆除 pane。tmux 投递被单独验证为可用见后端活跃性小节。这是记录在案的已知限制修复作为独立 follow-up 跟踪不在本次改动中解决。中断真实 tmux 下确认的 Escape 与Agent cancelledfm-rovo-smoke-s1scout 报告记录了单次 Escape 在运行中的工具调用期间打印Agent cancelled使用其自研 PTY VT 模拟器。真实 tmux 3.6a 下的后续实时检查复现了 scout 的精确发现在真实 mid-flight bash 工具调用期间发送单个 Escape捕获 pane 中打印出Agent cancelled——发生在隔离的tmux -L private-socket会话/窗口中而非共享 fleet 会话。launch-then-send 实时守卫tests/fm-rovo-signals-live-e2e.test.sh也在原始 PTY 上复现它早期单个固定定时器 Escape 在那里落点不可靠bare PTY 上中断送达的精确时刻是时间敏感的单个固定 Escape 可能落在状态之间因此守卫现在在整个实时sleep 25工具调用窗口内持续发送 Escape直到 cancel 渲染。这在每次运行都复现出Agent cancelled通常在前几次尝试内、工具调用约 8 秒处稳定落点一个从不渲染 cancel 的会话会耗尽所有尝试并失败。会话从未被卡死Escape 之后紧接的/exit仍干净退出并提示Run rovo --restore id to resume your conversation。bin/fm-control-lib.sh 把 rovo 的fm_control_interrupt_ack_source记录为none——与 claude、codex、grok、kimi、cursor 已做的保守选择相同这是控制面事实与渲染是否恰好出现无关因为对这五个适配器控制面都不依赖渲染确认。Escape 是记录的 interrupt key其渲染证据现在在真实 tmux 与原始 PTY 两处都被证实而非与代码相互矛盾。OAuth token 生命周期与静默刷新captain 纠正了本任务最初把约 1 小时 access-token 生命周期当作硬性 mid-task 阻塞的简报本任务自身的实时证据确认了纠正后的模型$ rovo auth status authenticated — Access token expired (2026-09-02 13:39:55 UTC), but a refresh token is present. $ rovo run --yolo --output-file out.json Reply with exactly the single word PONG and nothing else. Run rovo --restore session-id to resume your conversation $ cat out.json PONG $ rovo auth status authenticated — Access token valid, expires in 3574s (2026-09-02 15:15:40 UTC).第一次与第二次rovo auth status之间没有浏览器提示、没有交互步骤、没有可见中断中间那次rovo run从存储的 refresh token静默刷新了 access token。要把约 1 小时 access-token 生命周期当作普通运维事实而非不可协商的安全阻塞rovo auth login交互式浏览器 OAuth只在约四周闲置或 refresh token 失效后才需要而不是 mid-task。这也意味着 rovo 的 crewmate 不需要为存活该周期而刻意缩短任务切片。Effort 与模型agent.efficiencyLevel接受low|medium|high|max通过--config-override实时生效请求不支持的xhigh会记录进任务元数据但从该 JSON 对象中省略——两者都在假二进制套件中验证。关键坑在于--config-override是单值的第二次出现会静默丢弃第一次而非合并通过反转两个--config-override标志的顺序并观察先者的效果消失而实时确认。因此fm-spawn.sh的rovo_config_override_flag把agent.efficiencyLevel折叠进与强制allowedExternalPaths授权同一个 JSON 对象而不是发出两个标志假二进制套件钉住恰好一次--config-override出现同时携带两者。模型发现是按账户的/models或 ACPsession/new观察到的实时列表GPT-5.6 Terra/Sol/Luna、GPT-5.5、GPT-5.4、若干 Claude Sonnet/Opus/Haiku id、Gemini 3 id记录在.agents/skills/harness-adapters/references/harness/rovo.md中绝不能硬编码。工作区限制与 allowedExternalPaths 修复标准 crewmate 流程需要 rovo worker 读取自己的 brief 与 steering 消息并写入状态与报告——这些文件都在 firstmate home 中位于任务的 git worktree之外。默认情况下 rovo 把每个文件工具操作open_files、create_file、grep、expand_folder……都限制在启动它的工作区内且其 bash 工具独立拒绝同样的外部路径无论是否授权。这在隔离 scratch 工作区内用裸rovo run --yolo实时确认$ cat $LAB/outside/secret.txt OUTSIDE_SECRET_TOKEN_12345 $ rovo run --yolo Use your file-opening tool (not bash) to open and read the file $LAB/outside/secret.txt, then report its exact contents. --output-file out.txt $ cat out.txt Sorry, I cant access or read files outside the current workspace, including that temporary-system path. If you copy the file into the workspace or paste its contents here, I can help inspect it. $ rovo run --yolo Run this exact bash command and nothing else: cat $LAB/outside/secret.txt --output-file out.txt $ cat out.txt Captain, I cant run that command because it attempts to read a file outside the workspace, which Im not permitted to access. Would you like to provide the files contents here instead?toolPermissions.allowedExternalPaths~/.rovo/config.yml默认[]是唯一的提升手段且必须在启动时通过--config-override授予进程已在运行后没有实时升级。授权后同一文件、同一文件工具实时确认$ rovo run --yolo --config-override {toolPermissions:{allowedExternalPaths:[$LAB/outside]}} \ Use your file-opening tool (not bash) to open and read the file $LAB/outside/secret.txt, then report its exact contents. --output-file out.txt $ cat out.txt OUTSIDE_SECRET_TOKEN_12345授权只提升文件工具。rovo 的 bash 工具无论授权如何都保持 worktree 限制同一授权仍生效时实时确认$ rovo run --yolo --config-override {toolPermissions:{allowedExternalPaths:[$LAB/outside]}} \ Run this exact bash command: echo hello $LAB/outside/status.txt --output-file out.txt $ cat out.txt I cant run that command because it modifies a file outside the workspace. If you provide a workspace-relative path, I can run the equivalent command there - would you like to do that?这之所以重要是因为标准 crewmate 契约的字面状态行就是一条 bashecho ... status_file命令。面对这条精确字面指令rovo 通过自行回退到原生文件工具做同样的追加而自愈成功且保留文件既有内容$ echo existing: prior $LAB/outside/status2.txt $ rovo run --yolo --config-override {toolPermissions:{allowedExternalPaths:[$LAB/outside]}} \ Report status by appending one line: echo working: test line $LAB/outside/status2.txt --output-file out.txt $ cat out.txt Appended working: test line to status2.txt. What would you like to do next? $ cat $LAB/outside/status2.txt existing: prior working: test line同一授权在目录粒度上还覆盖列目录、读取其中文件、以及把文件移动而非复制进handled/子目录——这正是 steering-inbox 确认契约bin/fm-task-inbox-lib.sh需要的精确形状针对预先存在的inbox/handled/目录一次实时确认$ rovo run --yolo --config-override {toolPermissions:{allowedExternalPaths:[$LAB/outside]}} \ List the directory $LAB/outside/inbox for *.msg files, read 001.msg, then move it into $LAB/outside/inbox/handled/001.msg (a rename/move, not a copy-and-delete you narrate but dont do). --output-file out.txt $ ls $LAB/outside/inbox/handled 001.msgfm-spawn.sh的rovo_config_override_flagfm-spawn.sh为每次 rovo 启动构建一个合并 JSON 对象为何必须是一个见上文 Effort总是为精确三个真实symlink 解析后、作用域到本任务的路径授予toolPermissions.allowedExternalPathsbrief 目录data/id/覆盖brief.md/launch-brief.md/report.mdsteering inbox 目录state/id.inbox/覆盖每条 steer 及其handled/确认status 文件本身state/id.status。代码通过cd $data_dir pwd -P解析真实路径与BRIEF_REAL的解析保持一致。tests/fm-rovo-signals-live-e2e.test.sh把这一形状端到端扩展进 launch-then-send 实时守卫用生产--config-override授权启动的真实 rovo 进程读取外部 brief 并追加外部 status 文件保留既有内容同一 brief 与 status 文件在无授权启动时保持原封不动、而转录显示 rovo 自己的拒绝——证明该修复关闭了缺口而不只是加了未测试的标志。tests/fm-rovo-harness.test.sh在假二进制套件中钉住可移植半部三个路径出现在每次 rovo 启动中包括请求的 effort 不支持而被省略时且恰好一次--config-override出现。后端活跃性tmux 已实时验证herdr 已实时验证但存在 herdr 侧 agent 检测缺口tmux 3.6a 现已安装并在隔离的tmux -L private-socket会话中实时演练因此 tmux pane 活跃性完全验证而非待定。bin/fm-agent-process-lib.sh的fm_agent_process_classify_name当时仍在bin/backends/tmux.sh内把*rovo*与其他 glob 化的 harness 名并列匹配因此 rovo pane 判为agent而非other。两个独立名称源按设计工作#{pane_current_command}报告截断的磁盘二进制名atlassian_cli_r——macOS 15 字符comm截断把atlassian_cli_rovodev恰好在rovo子串开始前切断与 docs/verification/runtime-backends.md 已为 codex/kimi 自身 patch-release 名称漂移记录的截断易变类相同——而前台基于ps的comm正确报告rovofm_backend_tmux_agent_state通过该主源正确返回alive。双独立名称源设计正是截断怪癖不破坏判定的原因。tmux capture-pane在真实sleep型 bash 工具调用运行期间正确渲染 box composer 与Rovo is thinking...忙碌行fm_busy_rovo_tail_busy判为 busy工具调用完成、回复落定后判为 idle。中断小节的 Escape/Agent cancelled证据正是捕获于同一实时 tmux 会话。/exit干净关闭 tmux 窗口fm_backend_tmux_agent_state随即报告missing——干净、无歧义的退出判定。完整fm-spawn.sh --backend herdr放置无法从本机驱动到底本任务自身的 agent 进程运行在共享生产 Herdr 会话内因此fm-spawn.sh的跨会话 launcher 身份守卫正确地拒绝从该环境父身份向任何其他会话放置 worker pane而强制放入共享default会话被判定为对实时、人工观察的 fleet 的不可接受干扰。该守卫只作用于fm-spawn.sh自身的任务/worktree 编排不作用于其调用的底层原语因此本任务改为直接在由bin/fm-herdr-lab.sh创建的隔离非default会话上驱动这些原语fleet-state tripwire 确认实时default会话前后未变herdr workspace create/pane list用于放置从fm-spawn.sh逐字提取的rovo_capture/rovo_wait_for_ready/rovo_delivery_is_confirmed/rovo_wait_for_deliverygate 函数以及来自bin/fm-backend.sh与bin/backends/herdr.sh的fm_backend_capture/fm_backend_send_text_submit/fm_backend_agent_state$ herdr workspace create --label rovo-verify --cwd ~/.fm-herdr-rovo-verify-scratch --no-focus --session fm-lab-... {result:{root_pane:{pane_id:w1:p1,...},workspace:{workspace_id:w1,...},...}} $ herdr pane list --workspace w1 --session fm-lab-... {result:{panes:[{pane_id:w1:p1,cwd:/Users/.../.fm-herdr-rovo-verify-scratch,...}]}}rovo pane 被放进该隔离工作区以 bare 启动上面记录的同一env -u ... rovo run --yolo模板rovo_wait_for_ready在Welcome to Rovo!横幅上返回成功。键入的指针Read the brief at path and follow it exactly.回显进 panerovo 读取一份平凡 no-op brief、运行真实sleep 15bash 工具调用、回复PONG——同一 launch-then-send 形状已在 tmux 与原始 PTY 验证现又在 Herdr 上实时确认。fm_backend_herdr_capture在工具调用期间正确渲染Rovo is thinking...忙碌行fm_busy_rovo_tail_busy匹配该捕获文本工具调用结束后 pane 读为 idle 且可见PONGrovo_wait_for_delivery自身的 composer-empty 合取项未在轮询窗口内稳定——与下方已记录的 composer-ghost-text 缺口一致而非新缺陷。fm_backend_agent_state是本运行中唯一被证伪而非证实的信号它在就绪横幅、mid-tool-call busy、idle-with-PONG全程报告dead——尽管 rovo 全程明显活着并在响应。原因在 Herdr 侧而非 firstmate 侧fm_backend_herdr_pane_agent_state调用herdr agent get pane对活 rovo pane 返回{error:{code:agent_not_found,message:agent target w1:p1 not found}}因为herdr integration status列出的已知集成里根本没有rovo安装的 Herdr build 只认识pi、omp、claude、codex、copilot、devin、droid、kimi、opencode、kilo、hermes、qodercli、qwen、cursor、mastracode、antigravity-cli、grok。Herdr 尚未为 rovo 提供 agent 检测因此恢复逻辑依赖的分类器fm_backend_agent_state的alive/dead区分以及fm_backend_herdr_tab_is_husk对它的复用目前无法在 herdr 后端区分活 rovo pane 与空 pane放在backendherdr上的活 rovo worker 有被任何信任该分类器的恢复路径误判为无 agent husk 的风险。这记为已知 Herdr 侧集成缺口而非 firstmate bug并在本处刻意不修补在未冒给某个无关 idle shell 制造假阳性alive判定风险的情况下没有安全的 herdr 作用域 workaround因此backendherdr对启动 rovo crewmate/scout仍可用但在 Herdr 发布 rovo 检测或bin/backends/herdr.sh像bin/backends/tmux.sh那样获得独立基于进程的回退之前对自动 dead/husk 恢复未验证。/exit把 pane 还给 idle shell 提示符而非关闭它不同于关闭整个窗口的 tmux因此退出后fm_backend_agent_state读dead对无 agent 但存在的 pane 是文本上正确的判定真正的发现只是 rovo 实际运行期间的 ready/busy/idle 误分类。Skill 加载互操作缺口已记录未修复⚠ Invalid skill definition in .../.agents/skills/bootstrap-diagnostics/SKILL.md: metadata - internal: Input should be a valid stringrovo 的 skill 加载器拒绝每一个 firstmate skill因为 firstmate frontmatter 里的metadata.internal是布尔值而 rovo 的 schema 要字符串。这阻塞了 rovo worker 内的/no-mistakes及所有其他 firstmate skill 调用直到 firstmate 的SKILL.mdfrontmatter 改为 rovo 兼容——一个独立延期的 follow-up牵涉每个 skill 文件与安装器契约.agents/skills/firstmate-coding-guidelines/SKILL.md。no-mistakes模式的 rovo ship crewmate 被此缺口阻塞不调用任何 skill 的 rovo scout 不受影响。quota-axi provider 映射未建立bin/fm-quota-choose.sh的provider_for_harness没有rovo条目。rovo 通过 Atlassian 自家账户路由到多个不同的底层模型族OpenAI、Anthropic、Gemini而本任务没有发现quota-axi如何或是否建模这一关系的实时证据。与其猜测 provider 族并冒错误配额判定的风险rovo保持缺席于该映射——因此配额平衡派发数组中的rovo候选以unknown harness: rovo失败关闭fails closed而不是被静默误判建立真实映射是 follow-up 工作不属于本适配器。刷新这份记录任何 rovo 升级后都要运行可移植套件与实时守卫因为进程名、marker 集合、渲染的忙碌/中断文本都是厂商控制的表面bin/fm-test-run.sh tests/fm-rovo-harness.test.sh FM_ROVO_SIGNALS_LIVE1 bin/fm-test-run.sh tests/fm-rovo-signals-live-e2e.test.sh实时守卫需要真实的、已认证的rovo二进制但通过原始 PTY 而非 tmux 驱动它因此可在未安装 tmux 的主机上运行tmux 与 herdr 的 pane 放置和活跃性都在实时隔离会话中单独验证见后端活跃性小节其中 herdr agent-state 分类器对 rovo 的盲区被记录为需跟踪的 Herdr 侧集成缺口而非此刷新命令需关闭的实时守卫覆盖缺口。快速参考rovo 适配器操作事实一览结合.agents/skills/harness-adapters/references/harness/rovo.md与本文验证记录可直接引用的关键事实事实值二进制解析resolve_rovo_binaryfm-spawn.sh先解析PATH再回退$HOME/.local/bin/rovo两者都不可执行则拒绝启动启动形状barerovo run --yolo无位置 briefWelcome to Rovo!就绪门 → 键入绝对 brief 指针 → 投递确认门退出命令/exit也支持/quit、idle 单次 Ctrl-C打印Run rovo --restore session-id to resume your conversation中断键单个 Escape打印Agent cancelledack_source记录为none忙碌判定渲染文本Rovo is thinking回退fm_busy_rovo_tail_busy因eventHooks仅工具粒度触发环境 markerATLASSIAN_AGENT_TYPErovo最特异与ROVODEV_CLI1不清洗继承的外部 marker进程名commrovo包装器 exec 世代rovoshimargv[0] 保持rovo磁盘二进制为atlassian_cli_rovodev文件访问默认 worktree 限制allowedExternalPaths仅提升文件工具bash 工具始终受限Effortagent.efficiencyLevellow\|medium\|high\|max默认medium经单值--config-override与授权合并注入此外.agents/skills/harness-adapters/references/harness/rovo.md还记录了一个未来升级路径rovo acpAgent Client Protocol与rovo serve --non-interactive暴露完全结构化、机器可读的 turn 生命周期session/prompt返回真实{stopReason:end_turn}session/cancel是协议原生中断——这是比当前任何适配器更干净的 done 信号但消费它意味着 firstmate 要运行 JSON-RPC 客户端并自持会话生命周期是新的 backend 形状表面而非即插即用 TUI 适配器因此明确属于本 TUI 路径适配器之外、作为 rovo-as-structured-backend follow-up 的刻意未来升级。赞分享【免费下载链接】firstmateTalk to one agent. Ship with a crew.项目地址https://gitcode.com/gh_mirrors/fi/firstmate点击查看免费下载相关推荐firstmate 接入 Atlassian Rovo CLI面向 crewmate/scout 的 TUI 适配器实战指南firstmate 接入 Atlassian Rovo CLI面向 crewmate/scout 的 TUI 适配器实战指南 导读 本文基于 firstmat在 Rovo Dev CLI 中安装与配置 GitHub MCP Server托管远程服务器接入实战指南在 Rovo Dev CLI 中安装与配置 GitHub MCP Server托管远程服务器接入实战指南 本篇指南面向使用 Rovo Dev CLI基于 a后端MCP 服务AI 应用在 Rovo Dev CLI 中安装 GitHub MCP Server远程托管服务接入指南在 Rovo Dev CLI 中安装 GitHub MCP Server远程托管服务接入指南 本指南以 Klavis 开源仓库中 GitHub MCP SerAI 应用LLM 网关MCP 服务工具调用上一篇Vibe Kanban贡献指南如何参与开源项目开发和贡献代码下一篇Arduino WebSocket终极指南打造实时物联网应用的完整教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
