ENZOMEGA.
Wiki 实体

Claude Code 多 Agent 与自主执行

Created: 2026-07-03 Updated: 2026-07-05
#claude-code #multi-agent #agent-view #goal #loop-engineering

本页从 [[wiki/entities/Claude Code]] 拆出，覆盖 Agent View、/goal、Agent Teams、Loop Engineering、嵌套子代理与并行开发机制。

Agent View：从结对编程到团队管理（2026-05 新增）

Claude Code v2.1.139 引入 Agent View——统一仪表盘，将所有并行会话按”等待输入/工作中/已完成”三栏呈现，支持 peek 就地回复、attach/detach 进出、后台持久化。被工程 lead Thariq 比喻为”给 Claude Code 的 tmux”。

核心转变：从一对一结对编程变为一对多团队管理。“你变成了项目经理，手下有一个 AI 团队。“每个会话的状态摘要由轻量 AI 模型（Haiku）每 15 秒重新生成——管理面板本身也是 AI 驱动的。

关键概念区分：subagent（单 session 内帮手）、agent team（固定协作组）、Agent View（人类跨 session 面板）是三个完全不同层面的东西。

花叔 4 个月数据：131 亿 token、606 个独立会话、38 个项目、活跃日日均同时开 7 个 session。重要警告：别因为派活变简单就一次派 8 件——AI 派任务的边际成本是 0，你 review 的边际成本不是。[[raw/2026-05-12/花叔/Claude Code发布Agent View，多任务流的ADHD患者有救了.md|来源: 花叔 Agent View]] [[raw/2026-05-12/J0hn/Claude Code 推出 Agent View 功能，一键管理所有会话.md|来源: J0hn Agent View]] [[raw/2026-05-15/金先森是朝鲜族阿/Claude Code 的 Agent View，让我看到 AI 编程真正麻烦的地方.md|来源: 金先森 Agent View]]

Agent View 深度体验（来自 Guide）

  • 黄色(Needs Input)/旋转(Working)/蓝色(Completed)三色状态
  • /bg后台化、claude —bg启动后台、Peek & Reply空格预览不切换直接回复、claude respawn重启保对话
  • Mitchell Hashimoto模式：目标10-20%时间有后台Agent在跑，每天最后30分钟布置任务
  • 硬约束：本机运行关机中断、40%上下文使用率开始质量下降
  • 来源：[[raw/2026-05-18/Guide/Claude Code 终于能管好多个 Agent 了！Agent View 用下来真香。.md|来源: Agent View体验]]

/goal 命令：设目标、喝咖啡、等结果

/goal 解决了 AI 编程最大瓶颈不是”能不能写代码”而是”要不要人看着”的问题。通过 Ralph Loop（干活→检查是否达标→未达标继续→再检查），可设定可度量条件（如”所有测试全绿”），Claude 自动迭代直至达标。配合 auto mode 可实现真正”设好条件撒手不管”。[[raw/2026-05-14/AI兴观点/Claude Code 深夜上新！一条 -goal 命令把 AI 编程变成「设目标、喝咖啡、等结果」.md|来源: /goal 命令]]

/goal 机制深度分析（来自 邵猛）

  • Codex /goal(契约式) vs Claude Code /goal(评估器驱动)对比
  • Claude Code评估器：默认Haiku独立评判、不用工具、只依据transcript判断、条件最长4000字符
  • 执行/评判分离避免自我评估偏差（类似GAN架构）
  • 两种死法：模糊指令→过早放弃/永不停止。解法：量化指标+约束条件
  • Chris Hayduk三原则：目标可度量、验证可执行、状态可外化。三份外部文件：PLAN.md/EXPERIMENTS.md/EXPERIMENT_NOTES.md
  • 来源：[[raw/2026-05-18/邵猛/-goal 理论和实践全解 - 让 Codex 和 Claude Code 连续跑数小时直到完成目标的自主任务模式怎么用好？.md|来源: /goal全解]]

/goal 模板模式与实践精要（2026-06 新增）

多个来源独立提炼出高度一致的 goal 设计模式，形成了可复用的模板规范。 [[raw/2026-06-19/万物构想/让你的 CC - Codex 无人值守：6 个可直接复用的 -goal 模板.md|来源: Goal 模板]] [[raw/2026-06-20/陈蛋黄/当我跨过沉沦的代码：Codex Goal 模式生存指南.md|来源: Goal 生存指南]] [[raw/2026-06-20/科技巫师的魔法书/Codex 三种工作模式使用指南.md|来源: Codex 三种模式]]

通用模板结构（六个字段）：title（目标标题）、inputs（输入参数）、success_criteria（可验证的成功标准）、common_failure_modes（已知踩坑清单——比成功条件更有实战价值）、short_test（声明完成前的快速验证 shell 命令）、deliverables（交付物清单）。

好 Goal 四要素（扩展了之前的三要素模型）：

  1. 目标要硬——具体的 outcome 而非模糊任务
  2. 证据要严谨——验收标准必须可独立验证
  3. 边界是枷锁——显式限制 Agent 的活动范围
  4. 停止条件是缰绳——“相同 blocker 连续出现两次就停”等硬性终止规则

执行前要求模式：让 Agent 先读文档和 AGENTS.md，输出理解确认后才开始执行——防止误解的预检机制。长任务结束时必须最终审计：强制重新读文档、逐条对齐验收、git status 为证。社区报告 audit 退化问题——agent 随上下文压缩弱化原始 Goal 中的 audit 要求。 [[raw/2026-06-20/陈蛋黄/当我跨过沉沦的代码：Codex Goal 模式生存指南.md|来源: 陈蛋黄 预检与审计]]

跨平台链式工作流：Claude Code /plan + Codex /goal 形成互补——先用 CC 的 /plan 盘清需求、做方案分析、识别风险，再让 Codex 的 /goal 加载计划执行。两个工具不再竞争，而是互为上下游。 [[raw/2026-06-20/陈蛋黄/当我跨过沉沦的代码：Codex Goal 模式生存指南.md|来源: 陈蛋黄 跨平台链式]]

Goal 的哲学视角：它是人与机器之间的一纸契约，不是下达指令——目标是验收标准不是任务描述。Goal 的本质是长期任务控制机制，不是普通模式的加强版。四个不默认用 Goal 的原因：无完成条件不可用、增强自主推进倾向带来不可预测性、占用更多上下文、授权边界需要显式声明。 [[raw/2026-06-20/科技巫师的魔法书/Codex 三种工作模式使用指南.md|来源: Codex 三种模式 Goal 哲学]]

矛盾：Good goal 三要素（具体的 outcome、可衡量的成功标准、明确的边界条件） vs 四要素（增加了停止条件作为独立维度）来自 [[raw/2026-06-20/陈蛋黄/当我跨过沉沦的代码：Codex Goal 模式生存指南.md|来源: 陈蛋黄]]

Agent Teams 完整参考（2026-05 补充）

Agent Teams 与 Subagents 的本质区别不在能力强弱，而在”协作路径”：Subagents 适合执行链（主代理拆→子代理执行→主代理汇总），Agent Teams 适合协作链（负责人定目标→多队友并行探索→中途互相校验→负责人收敛）。

环境变量：CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1。触发关键词必须有 agent team / teammate。团队规模 3-5 人最佳。判断是否真创建的硬标准：~/.claude/teams/config.json 是否存在。

成本优化：CLAUDE_CODE_SUBAGENT_MODEL 环境变量让 teammates 自动用 Sonnet——专注型任务上与 Opus 差异很小但 Token 成本大幅降低。

TeammateIdle / TaskCreated / TaskCompleted 是新 hook 事件。

[[raw/2026-05-26/Claude Code + Agent Teams，并行任务的最佳实践.md|来源: Agent Teams实践]] [[raw/2026-05-26/90% 的人在用 Claude Code 单打独斗。7 步组建你的 Agent 战队，5 个任务同时并行.md|来源: 7步组建Agent战队]]

Loop Engineering：从写 Prompt 到写循环（2026-06 新增）

Boris Cherny 在多个场合强调同一个转变：“我不再手动给 Claude 写提示了。我跑着几个循环，由它们去给 Claude 发提示、决定做什么。我的活儿是写循环。” 这与 Peter Steinberger（OpenClaw 创始人）的判断完全一致——“你不该再去给编程智能体写提示词了，你应该去设计那些替你给智能体写提示词的循环。” [[raw/2026-06-06/朗朗晴空/从 Prompt 到 Loop：AI 编程进入新阶段.md|来源: Loop 基本概念]] [[raw/2026-06-09/ChallengeHub/Loop Engineering 来了：你不再亲手写 Prompt，而是写-循环-.md|来源: Loop Engineering 详解]]

一个完整的 Agentic Loop 由五步构成：Plan（AI 写步骤清单）→ Execute（写代码、运行命令）→ Verify（跑测试、检查输出）→ Iterate（出错自动修复）→ Schedule（定时重复）。Boris 的数据表明，加入反馈循环后输出质量可提升 2-3 倍。

六个组件（Codex 和 Claude Code 现已全部支持）：

  1. Automations：按计划自动触发，自己完成发现和分类筛选
  2. Worktrees：让并行 Agent 不会互相踩脚
  3. Skills：把项目知识写下来，避免 Agent 瞎猜
  4. Plugins/Connectors：把 Agent 接到已有工具上
  5. Sub-agents：一个出主意，一个来检查
  6. Memory：独立于对话之外的持久化状态（磁盘上的 markdown 或看板）

范式意义：一年前要跑循环得写一堆 bash 脚本并永远维护；现在这些零件直接内置在产品里。Steinberger 列的那张清单几乎能一一对应到 Codex 上，又几乎原封不动地对应到 Claude Code 上。一旦你发现两边的形态其实是一样的，你就不会再纠结到底该用哪个工具——你只管设计一个在哪个工具里都能跑的循环。

Prompt Engineering vs Loop Engineering 核心对比：

维度Prompt EngineeringLoop Engineering
关注点单次提示词效果持续任务闭环
典型问题怎么问 AI 更准确如何让 AI 可靠推进一组任务
输出形态回答、建议、代码片段自动化流程、协作链路、可验证结果
人类角色提问者、修正者流程设计者、约束制定者、审查者
风险控制依赖提示词约束依赖权限、验证、反馈、人工门禁

传统 Prompt Engineering 解决”修复一个 bug”，Loop Engineering 解决”每天早上读取 CI 失败和反馈→找高优 bug→创建隔离工作区→生成修复→跑测试→失败继续修正→通过后生成 PR→无法处理的写入待办”。前者是一条指令，后者是一套系统。 [[raw/2026-06-12/兔兔AGI/一文看懂 AI 编程智能体工程化新范式：Loop Engineering.md|来源: Loop Engineering 核心对比]]

Loop 的四个风险：① Token 成本——Automation、sub-agents、长上下文、反复验证快速放大消耗，没有清晰触发和停止条件会在低价值任务上烧资源；② 无人值守错误——Loop 的”done”只是声明不等于代码可靠；③ 理解债——AI 帮你写得越快你越来不及理解系统发生了什么；④ 认知投降——Loop 足够顺滑时人容易从”设计系统”退化成”按下启动”。Loop 是杠杆不是替身——它能放大一个工程师的判断，也会放大一个工程师的缺席。 [[raw/2026-06-12/兔兔AGI/一文看懂 AI 编程智能体工程化新范式：Loop Engineering.md|来源: Loop 四风险]]

Loop 深度解剖：组件、模式与风险（2026-06 新增）

梦朝思夕将 Loop Engineering 定位为第四次抽象跃迁：Prompt Eng → Context Eng → Harness Eng → Loop Eng，认为 Harness 仍是脚本思维而 Loop 是系统思维。 [[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: 梦朝思夕 Loop 工程]]

五要素模型：

  1. Automations（启动）——定时或事件触发
  2. Worktrees（隔离）——并行 Agent 不互相踩脚
  3. Skills（知识固化）——可复用的程序化知识
  4. Connectors（行动能力）——MCP、API、CLI 工具
  5. Sub-agents（质检）——隔离验证链
  • 第六要素 Memory（持久状态）

Loop 解剖六大组件：Goal（目标定义）、Tools（工具集）、Context（上下文管理）、Termination（终止逻辑）、Error Recovery（错误恢复）、Guardrails（护栏）。护栏的关键二分：资源类护栏（应焊死）vs 认知类护栏（应可插拔）——前者保护系统资源，后者保留人类判断空间。 [[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering.md|来源: 梦朝思夕 六组件]]

四种常见 Loop 模式及核心陷阱：

  1. Retry Loop——重试失败任务，陷阱：无限重试不降级
  2. Plan-Execute-Verify——规划→执行→验证，陷阱：自欺欺人（AI 验证 AI）
  3. Explore-Narrow——广度探索→聚焦收敛，陷阱：探索不足就过早收敛
  4. Human-in-the-Loop——关键节点等人审批，陷阱：人成为瓶颈

三大风险：

  • Comprehension Debt（理解债务）——AI 写得越快，人越来不及理解系统发生了什么
  • Cognitive Surrender（认知投降）——Loop 足够顺滑时人从”设计系统”退化成”按下启动”
  • Verification Gap（验证缺口）——Loop 自称”done”不等于代码可靠

所有 Loop 陷阱的根源：Loop 在没有人类判断的情况下做了不该做的事。 [[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering.md|来源: 梦朝思夕 陷阱]]

Loop 成本公式：实际月成本 = 基础成本 × Thrashing 系数。试点阶段与规模化阶段成本结构显著不同——在小规模上验证通过的 Loop，放大时可能因 Thrashing 系数非线性增长而失控。 [[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering.md|来源: 梦朝思夕 成本公式]]

内层循环 vs 外层循环：内层循环 = Agent 自己的推理→行动→观察（Agent Loop），外层循环 = 调度系统唤醒→分配→验证→记录（Engineering Loop）。两者需要明确区分——内层由 Agent 自行驱动，外层由工程系统控制。 [[raw/2026-06-17/Guide/面试官：“你说你懂 Loop Engineering，那 Claude Code 的 -loop 和 -goal 区别是什么？“我：“这是啥？“.md|来源: Guide 内外循环]]

/loop vs /goal 机制对比：/loop = 时间驱动轮询（下次什么时候醒），/goal = 目标驱动完成（什么时候算做完）。状态文件模板（YAML 格式含 evidence/attempts/stop_condition）是连接内层与外层循环的持久化状态。 [[raw/2026-06-17/Guide/面试官：“你说你懂 Loop Engineering，那 Claude Code 的 -loop 和 -goal 区别是什么？“我：“这是啥？“.md|来源: Guide loop vs goal]]

L0-L4 安全权限分级框架：只读摘要 → 本地复现 → 草稿修复 → 创建 PR → 自动合并。实操建议：第一版从只读 triage 开始，不要直接上无人值守自动修复。 [[raw/2026-06-17/Guide/面试官.md|来源: Guide L0-L4]]

矛盾：Loop Engineering 是第四次抽象跃迁，Harness 仍是脚本思维而 Loop 是系统思维（梦朝思夕”真突破”立场） vs Loop Engineering 是”新瓶装旧酒”——循环本身不新，新鲜的是名字，能力早就在往这个方向走了（Guide 怀疑视角）来自 [[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering.md|来源: 梦朝思夕]] [[raw/2026-06-17/Guide/面试官.md|来源: Guide]]

嵌套子代理：5 层递归外包（2026-06 新增）

Boris Cherny 在 6 月初确认 Claude Code 已正式上线 嵌套子代理（Nested Sub-agents），一个代理可以自己再召唤出别的代理，最多嵌套到 5 层深。v2.1.172 版本进一步巩固了这一能力。 [[raw/2026-06-09/朗朗晴空/让 AI 自己给自己派活：Claude Code 的嵌套子代理到底在干什么？.md|来源: 嵌套子代理]] [[raw/2026-06-15/扶苏/Claude Code v2.1.172- 子代理可以嵌套了，最多 5 层.md|来源: v2.1.172 嵌套子代理]]

普通子代理 vs 嵌套子代理：普通子代理就像单项外包（你让 Claude Code 喊一个审查员来干活，审查员做完退场）；嵌套子代理则是递归外包（你给顶层目标，它自己生成组长，组长判断后再临时喊来检索员、修订员、测试员配合）。普通子代理是给设计师下单；嵌套子代理是你雇了一个设计总监。

关键边界：

  • 嵌套深度硬限制 5 层，超限直接拒绝继续嵌套
  • 上下文并不共享——孙代理不会自动知道爷爷代理之前说过什么，信息必须显式传入。上层干净了，但底层容易信息断层
  • 延迟和 token 成本随层数增加累积得更快。每层都是独立调用、压缩、汇总。5 层嵌套不是把事加快五倍，而是信任链越长，失败概率也叠加

唐小胖：Claude Code 四种并行开发机制（2026-06-18 新增）

Claude Code 提供四种并行执行机制，关键原则是**「默认串行，仅在需要时才显式协作」**。 [[raw/2026-06-18/唐小胖/Claude Code 并行开发：一个人干不过来？那就多开几个「分身」！.md|来源: 唐小胖 并行开发]]

机制模式难度关键特性
Subagents「外包」——老板派活低独立上下文，只回摘要，3 个预设（Explore/Plan/General）
Agent Teams「项目组」——同侪协作高P2P 通信、持久上下文、共享任务列表+邮箱
Git Worktree「物理隔离」中同仓库、多物理目录、独立分支
Workflow Orchestration「组合拳」中Plan→Teams→并行→Subagent 审查→Worktree 合并

Agent Teams 细节：实验标志 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS: 1 开启。Lead Agent（项目经理）+ Teammates（工人）。三种协调机制：共享任务列表（待办/进行中/完成）、邮箱（单播/广播）、文件系统协调。Token 成本约为单 agent 的 7 倍。推荐 2-5 个 teammates；超过 5 个协调开销超过并行收益。

选型规则：「快活用 Subagent，难活用 Teams，冲突用 Worktree，大活用编排」。80% 的日常并行需求用 Subagents 就够了。 [[raw/2026-06-18/唐小胖/Claude Code 并行开发：一个人干不过来？那就多开几个「分身」！.md|来源: 唐小胖 选型规则]]

Claude Tag：从个人 Agent 到团队频道 Agent（2026-07 新增）

Claude Tag 把 Claude Code 的 Agent 能力从个人终端推进到团队协作现场。新资料把演进拆成三阶段：第一阶段是代码补全，AI 续写当前行；第二阶段是 Claude Code，AI 能写函数、文件和功能；第三阶段是 Claude Tag，AI 被拉进团队频道后主动跟进长期任务、记住频道规则、写 PR、排查生产问题、做数据分析，并让多人共同引导同一场会话。[[raw/2026-07-03/你说的完全正确/Claude code创始人最新揭秘：Claude Tag如何在团队内部“大杀四方”.md|来源: Claude Tag]]

关键变化不只是”更自动”，而是交互位置变了：过去 AI 工具是个人打开后单独使用，再把结果复制给团队；Claude Tag 直接运行在公开频道里，团队成员能观察别人如何提示、一起修正同一任务，Claude 也能通过记忆保留频道偏好和介入频率。产品团队中由 Claude Tag 提交 PR 的比例被描述为约 65%，这一数据如果属实，说明 Claude Code 的自主执行能力已经从个人效率工具进入组织协作结构。[[raw/2026-07-03/你说的完全正确/Claude code创始人最新揭秘：Claude Tag如何在团队内部“大杀四方”.md|来源: Claude Tag]]

Auto Mode、/goal 与 /routines：无人值守执行三件套（2026-07 新增）

扶苏把 Claude Code 的无人值守执行拆成三件套：Auto Mode 负责在白名单权限内减少逐步确认，/goal 负责把任务写成结果契约，/routines 负责用 Cron、Webhook、文件事件或 Git Hook 触发可重复执行的智能工作流。三者合在一起后，Claude Code 不再只是被动接收单条 prompt，而是能在限定权限和失败兜底下按周期处理依赖审计、PR review 预处理、CI 修复等任务。[[raw/2026-07-03/扶苏/Claude Code 自动模式、-goal 和 -routines：如何在无人值守的情况下运行Agent.md|来源: Claude Code Auto Mode]]

这组机制的风险边界很明确：Goal 必须写成功标准、范围和禁区；Routine 必须带权限上下文；删除文件、合保护分支、外部写操作等不可逆动作不能直接放开；日志审计和测试验证不能省。也就是说，无人值守不是无限授权，而是把人工确认前移到目标、权限、触发器和失败策略的设计阶段。[[raw/2026-07-03/扶苏/Claude Code 自动模式、-goal 和 -routines：如何在无人值守的情况下运行Agent.md|来源: Claude Code Auto Mode]]

Dynamic Workflow / ultracode 高级用法（2026-07 补充）

Hunter 的实测把 Claude Code Dynamic Workflows 的生产用法压成三条：先审计 plan 再执行、逐阶段指定模型控成本、在 workflow 内调用 MCP 和 Codex 做能力扩展。新版本触发词被描述为 ultracode，核心操作不是让 workflow 直接跑，而是先要求展示 workflow plan、预计 agent 数、每阶段模型、停止条件和验收标准。[[raw/2026-07-05/Hunter/Claude Code Workflow 高级用法实战.md|来源: Claude Code Workflow 高级用法]]

X 上的官方译文补足了 Dynamic Workflows 的产品边界：它以研究预览形式面向 Claude Code CLI、桌面版、VS Code 扩展以及 API/云模型通道，适合代码库范围 bug 搜索、安全审计、大规模迁移、关键方案多角度压力测试。其工作方式是由 Claude 动态规划任务、扇出数十到数百个并行子 Agent，结果被纳入前先经过检查和反驳，最终汇总为一个协调答案。首次触发时会展示即将运行的内容并请求确认，因为 token 消耗显著高于普通 Claude Code 会话。[[raw/X/@freeman1266/(译)Claude Code 推出动态工作流：10-100 个并行子 Agent 自检后再交付.md|来源: Dynamic Workflows 官方译文]]

模型分层是 Dynamic Workflow 的关键成本杠杆：大批量初筛可用 Haiku，验证阶段用 Sonnet，最终合成留给 Opus。MCP 让每个 agent 接入代码导航或外部数据源；Codex CLI 则可作为独立 review 引擎嵌入 workflow，形成 Claude/Opus/Sonnet/Codex 的交叉验证。这里的重点不是”多开几个 agent”，而是把 plan 审计、成本分层、外部工具和多引擎对抗验证纳入同一可审查脚本。

官方 Common Workflows：日常开发操作谱系（2026-07 补充）

扶苏整理的 Claude Code 官方 Common workflows 把日常开发动作压成一套可复用操作谱系：理解陌生代码库先宽问再收窄；定位功能时先找相关文件、再解释协作关系、再走完整流程；修 bug 时提供报错和复现上下文、先要方案再让 Claude 改；重构必须小步改、步步测试；写测试先找未覆盖代码，再补边界条件并运行失败修复；创建 PR 前让 Claude 总结改动，但提交前仍要人类审查风险。[[raw/2026-07-05/扶苏/Claude Code 常用工作流程.md|来源: Claude Code 常用工作流程]]

这篇还补齐了几个容易被忽略的入口：Claude Code 可在非代码目录工作，适合管理 Markdown vault；截图、设计稿、架构图可以直接作为视觉上下文；@file、@directory、@server:resource 能显式引用文件、目录和 MCP 资源；--continue/--resume 恢复会话，--worktree 做并行开发，plan mode 在编辑前先审批方案，子代理承担大代码库调研，管道模式让 Claude 进入 CI、pre-commit 或批处理脚本。核心不是把 Claude 当 autocomplete，而是把它放进完整开发循环。

输入关键词开始搜索