第一代 AI 开发者 CLI 给你一个 chat 循环加上 tool-use。第二代正围绕下一个具体原语收敛——子 agent。Claude Code 今年早些时候发布了它的 Agent 工具，带 markdown 加 YAML 配置、通过 tool-calling 语法显式委派、并行调用，以及隔离上下文。Google 的 Gemini CLI 现在也发布了实质相同的原语。InfoQ 有报道，形态接近到 Claude Code 用户一眼就能认出来。
Gemini CLI 里的子 agent 定义在带 YAML frontmatter 的 markdown 文件里，指定角色、工具和行为准则。这和 Claude Code 用户已经在 `.claude/agents/` 下使用的模式一致。委派是显式的：用户通过 prompt 语法把任务指派给特定 agent，镜像 Claude Code 调用 Agent 工具的方式。支持并行执行。Google 的例子包括分析代码库的不同部分或同时跑多个研究任务，InfoQ 指出了明显风险：并发请求导致的代码改动冲突和用量上限上升。每个子 agent 在隔离环境中运行，并向主会话返回汇总结果，这和 Claude Code 保持父上下文精简所用的架构一致。Gemini CLI 开箱就提供三个内置子 agent：通用助手、CLI 帮手，和代码库调查 agent。
这不是巧合的收敛——是问题本身强加的形态。一旦你构建过需要做长时研究、代码调查或批量文件修改的 agentic CLI 会话，你很快会撞上两个约束：父上下文预算和并行度。markdown 加 YAML 配置处理「这个 agent 应该怎么行为」那个轴。带汇总返回的隔离环境处理上下文预算那个轴。通过 prompt 语法显式委派让编程模型对那些不想要完整编排框架的 CLI 用户保持简单。Gemini CLI 落地这个原语意味着这个模式现在是 agentic 开发者工具的行业标准，不再是 Claude Code 的特立独行。
如果你在两款 CLI 任一之上构建 agent 工具，实际含义是你的子 agent 配置可以写一次，在两者之间几乎完全复用。schema 差异可控；心智模型一致。值得一提：两方都警告并行子 agent 会产生冲突的编辑，这在理论上是已解决的问题（版本控制、写前检查、合并）但在 UX 上是未解决的问题。谁先搞定「起五个子 agent 同改一个 repo 然后干净合并」的流程，谁就会有真正的差异化。在那之前，收敛原语已经在这里了，你的 agent 打法可以针对它来写，不管你团队用的是哪款 CLI。