agy-staff

Google 自家的编码 agent 就是 Antigravity CLI，这个项目把它雇了下来：一个伴随脚本把 agy 包起来，交给 Claude Code、Codex 或 Pi 当作一位可以派活的同事。五个 persona 分工——ask 负责无工具的一次性问答，staffer 接一般委托，另有 researcher、reviewer（代码与方案两种）和 implementer——每一个都固定在 Gemini 3.8 Flash 的某一档推理强度上；再有一个 lead 技能告诉宿主 agent 哪些交出去、哪些自己留着。只有 ask 在同一次调用里给答案，另外四个返回一个 job id 和一条 wait 命令，跑在独立的 worker 进程里，把 spec、日志、结果与终态都留在仓库的 .agy-staff/ 下。它在 2026-08-18 出现，随后一个月里发了十二个版本，MIT 许可，到 9 月底有 696 个星和两个未关的 issue。

谁做的仓库背后的账号 2022-04-18 注册，31 个公开仓库，147 个关注者，签名写着「think twice」，公司一栏填的是 Google，个人站点是 lastwhisper.dev。该仓库 52 次提交里有 50 次来自这个账号，且分散在两个作者名下——pkuwkl 39 次、LastWhisper 11 次。另外两位 Shen-18 与 solitudealma 各贡献一次提交。

1. 01

   一个月，十二个版本，一份真的做完的清单

   仓库建于 2026-08-18，标着「first public release」的 v0.3.0 当天下午就发了；到 2026-09-15 的 v0.7.3 为止一共十二个版本，中间还有一个从未变成 release 的 v0.3.1 标签，而 release notes 只覆盖了其中十一个。这一个月里有 52 次提交——八月 40 次、九月 12 次——版本标题读起来像一份被做完的计划，而不是流水账：personas、implementer continuation、opaque task text、换默认模型、防误报崩溃、流式观察与恢复、带工作区挂载的恢复补丁、用 AGY 做任务编排，最后连着三个版本处理 Windows。最早的一次提交甚至早于仓库的创建日期，正是它把项目开了头：一个把 agy 包成单一大脑、带模式、任务与 setup 的包装脚本。技术栈是 JavaScript，除 Node 标准库外没有运行时依赖，MIT 许可；到九月底是 696 个星、46 个 fork、1 个 watcher 和两个未关的 issue——一个想接入第二种宿主 CLI，一个提议给员工开一个能在会话结束后留下结论的频道。42 条提交带共同作者尾注，其中 40 条写的是 Claude——37 条 Fable 5、3 条 Fable 5.1；提交过的三个账号里，有两个各只贡献了一次。

2. 02

   两个 agent 之间真正传递的东西

   没有共享内存，没有请求—响应式的 API，也没有守护进程：两个 agent 之间真正传递的是一条 shell 命令、一个文件和一个 id。那些 persona 技能是写给宿主 agent 的说明，由宿主自己拼出并执行 node companion/agy-companion.mjs <mode> --prompt …。伴随脚本只按 shell 交付的原样解析一次 argv，不重新切分、不解释引号、不检查任务文本的任何一个字节，于是一句提到 git diff --check 的任务会逐字节送到 agy，而不会被当成伴随脚本的选项——这正是 v0.4.5 删掉位置参数式任务文本、改为只接受 --prompt、--prompt-file、--stdin 三者之一的原因。后台模式里，伴随脚本先写一份 job spec，再把自己以分离进程的形式起成 _worker <job-id>；这个 worker 拉起 agy 子进程，持续读它的 stream-json 输出，并把事件解析成有上限的进度快照。它还会用 --add-dir <repoRoot> 挂上工作区，而这一点在受限路径上曾经是缺的：修之前，每一次受限运行都以成功状态和一句空回复收场。什么给调用者看、什么是机器细节分得很干净：结果与工作树告警走 stdout，带模式、权限档、模型、耗时、token 数与 conversation id 的遥测行走 stderr 和任务日志。跨轮次的连续性挂在 agy 自己的 conversation id 上，记录在仓库的 .agy-staff/state.json 里，continue 与 restart 之后复用的就是它。

3. 03

   员工的权限到哪里为止

   每个 persona 都是固定的，不能调：ask 同步且不带工具，另外四个交回一个 job id，没有任何标志能改变执行方式。推理强度同样钉死——ask 低、staffer 与 reviewer 中、researcher 与 implementer 高——所以派活的意思是挑一位同事，而不是调一个模型。职责边界写在 lead 技能里，而这个月最后一次发版正是因为边界写得不够利落：宿主可以一边把查历史派出去、一边继续自己做大量本地调查，于是用户得亲手去拨派活与等待这两件事。v0.7.3 把它换成一条通用默认——先把任务框清楚，把成块的实质工作派出去，等结果，评估，然后再跟进、接手或交付——验收则要求与任务相称的产物和证据，并保留几种例外：小而已经弄明白的活、等待期间可以做的有用工作、以及结果到手后的聚焦验证。员工能做什么由提示词而不是权限决定：四份模板默认拒绝不可逆或昂贵的动作，而同一套提示词会精确打开任务明确授权的那些。上面还压着三道 git 护栏——implement 可以在脏工作区里开工，并拿到一份有上限的、已被改动路径的摘要；research 与 review 则前后各取一次 git status --porcelain——README 用一句话给这一切划了界：这些提示词层面的指令并不提供权限隔离。

4. 04

   失败是一个待查看的状态，不是一次重试

   运行时里没有任何东西会自己重试：伴随脚本从不自动重试。跑到时间上限的任务会停在一个终态上，并带上恢复所需的元数据——requires_user_confirmation、把上一次超时翻倍且上限 120 分钟的 suggested_timeout、以及一条可以照抄的续跑命令——调用它的 agent 必须先问用户是继续还是停下。硬超时与 AGY 报出的超时被分成 reason=hard_timeout 和 reason=response_timeout 两种；只要还有已知的 conversation，两者都会变成 attention 与退出码 5，没有的话任务就停在 error。恢复是一次显式的新任务，与旧任务关联；而当要续的任务还在跑时，continue 会直接拒绝——后续不会被排队，调用方得先等或先取消。中间产物遵循同样的直觉：无告警地成功之后，原始事件流与快照会被删掉；失败、取消与硬超时则把它们留着，于是半成品可以先被查看，再决定要不要续。同一种直觉还修掉了一个从未成立过的崩溃报告：在一个沙箱环境里启动、在另一个里收取的任务，因为读它的地方看不见 worker 的 PID 而被判成崩溃；如今被误判的任务从启动它的那个环境去看时会自愈回运行中。

5. 05

   Windows 的两周，和一份被完整保留的贡献

   这个仓库此前从没在 Windows 上跑过：代码里没有任何 windowsHide，也没有任何 win32 分支，持续集成只跑 Ubuntu。有用户先尝到了后果：派一个后台任务会不停弹出控制台窗口，cancel 和关掉终端都停不下来，直到从任务管理器里杀掉那棵 node.exe。修法由一位贡献者从状态锁开始，因为在 Windows 上拿到的是 EPERM 与 EBUSY；维护者把它补完，等同一批工作又长出一个 pull request 时，他把自己那些提交推到了贡献者的分支上，好让原作者留住这个 pull request。持续集成被拆成三个作业，Windows 测试放在人工批准闸门后面，因为一次 Windows 跑很慢。最好的那个 bug 出现在最后：在 Windows 上，分离出去的 worker 会把已经退出的派发者的 PID 留作自己的父进程，而 Windows 很快复用 PID，一旦被复用，一个毫不相干的孤儿看上去就像子进程并被杀掉，只留下一个没有状态文件、日志正好 178 字节的消失任务，而任何内部错误路径都产不出这种结果。修法是只在子进程创建时间晚于父进程时才跟随这条父子链接，并让领头那个用 taskkill /PID <pid> /F，而不是 /T。参考文档至今仍把 Windows 支持称作尽力而为，并注明它还没有拿真实的 Windows agy 安装验证过。