Agentic Loop 设计

Simon Willison 2025-09-30 提出 "Designing agentic loops" 是工程师必须掌握的新技能。一句话总结：LLM Agent = 在 loop 里跑工具来达成目标，用得好的关键是精心设计这个 loop 和它能用的工具。本篇是这套设计学的工程化指南。

学前说明

你可能已经在用 Claude Code 或 Codex CLI，但用法常停在"对话级"——一问一答，问题大就拆开问。这种用法没释放 Coding Agent 的全部威力。

真正释放威力的方式：把问题转化成"明确目标 + 可迭代的工具集"，让 Agent 在 loop 里暴力求解。Simon Willison 的原话：

Coding Agent 是暴力求解编码问题的工具。如果你能把问题简化成清晰目标 + 一组能朝目标迭代的工具，coding agent 经常能暴力求解出有效方案。

5-6 第二章讲了 Agent Loop 的基础机制（perceive/think/act/observe）。本篇讲作为人类工程师，怎么设计这个 loop 才能最大化产出。

学习目标

• 判断什么问题适合用 agentic loop（vs 直接对话）
• 为 loop 安全开启 YOLO 模式（Docker / Codespaces / Anthropic Safe YOLO）
• 为 loop 设计正确的工具集（shell > MCP 的判断标准）
• 用 AGENTS.md / CLAUDE.md 高效喂工具说明
• 发放最小权限凭证（临时账户 + 预算限制）
• 设计 loop 的成功判定与终止条件
• 应用 Anthropic 的 plan / execute / verify / reflect 模式

与现有知识的衔接

• 5-6 第二章：Agent Loop 基础（前置）
• 04 Lethal Trifecta：YOLO 的安全边界
• 05 Parallel Agents：并行多个 loop
• 06 Agentic Engineering：loop 设计是 Agentic Engineering 的核心子技能

---

第一章：什么是 Agentic Loop

1.1 重新定义 Agent

Simon Willison 的精确定义（2025-09-18）：

An LLM agent is something that runs tools in a loop to achieve a goal.

把这句话拆开：

元素	含义	例子
LLM	决策的大脑	Claude Sonnet 4.5、GPT-5
tools	Agent 能调用的能力	shell、edit_file、run_tests
in a loop	反复迭代直到成功	不是一次输出
achieve a goal	有明确终止条件	"测试通过"、"延迟 < 100ms"

少任何一个就不算 Agent。最常见的混淆：把"Chatbot"叫 Agent——chatbot 没有 loop，没有 goal。

1.2 暴力求解的本质

Coding Agent 的工作模式像暴力搜索 + 反馈剪枝：

为什么称"暴力"：

• LLM 不像传统算法那样"算出答案"
• 它不断尝试，根据反馈调整
• 每次失败都是新信息
• 能看到的反馈越多，最终方案越好

这意味着：反馈质量决定最终质量。这是 loop 设计的核心。

1.3 适合 loop 的问题特征

Simon 列出的典型场景：

问题	为什么适合 loop
调试失败的测试	跑测试 = 即时反馈
SQL 查询性能优化	EXPLAIN + 计时 = 可量化反馈
升级一堆依赖	测试套件 = 完整验证
优化 Docker 镜像大小	docker images + 测试 = 双重反馈

共同点：

明确的成功标准 + 可能需要繁琐的试错

如果你心里浮起："呃，我得试一堆变体" —— 这就是 agentic loop 的强烈信号。

1.4 不适合 loop 的问题

• 没有明确成功标准：写一篇博客，what is "done"？
• 反馈不可自动化：UI 美观度、文案风格
• 试错成本太高：操作生产数据库、发邮件给真实客户
• 目标本身需要协商：架构选型，需要人类判断

这些场景应该用 chat 模式或 architect → implementor 模式（参考 05）。

---

第二章：YOLO 模式的安全运行

2.1 为什么必须 YOLO

Claude Code 默认每个 shell 命令都问你确认。这看起来安全，但代价是：

• 每次都打断你的注意力
• Agent 不能"暴力试错"——你不可能批准 50 次试探
• loop 失去 brute-force 价值

YOLO 模式（--dangerously-skip-permissions）让 Agent 自动批准所有操作，回归暴力求解的本来面目。

但 Simon 引 Solomon Hykes 的精彩定义：

An AI agent is an LLM wrecking its environment in a loop.

AI Agent 就是一个 LLM 在 loop 里搞破坏它的环境。

YOLO 模式的危险：

1. 错误的 shell 命令：删除或损坏你重要的东西
2. 数据外泄攻击：Agent 把源码或环境变量里的密钥发出去
3. 代理攻击：你的机器被用来攻击别的目标（DDoS、隐藏来源）

2.2 三种安全策略

Simon 列的三选项，按推荐度：

选项 1：用别人的电脑（推荐）

• GitHub Codespaces：浏览器里的完整容器，免费额度够用
• Codex Cloud / Claude Code for web：云端异步 Agent
• 出问题最坏只是某台 Azure 机器烧 CPU

选项 2：本地 Docker 沙箱（次推荐）

按 Anthropic 官方 Safe YOLO mode 的建议：

# 用 Anthropic 官方 dev container 模板
git clone https://github.com/anthropics/claude-code
# 看 .devcontainer/ 目录的 Dockerfile + init-firewall.sh
# 用 VS Code Dev Container 启动

关键安全约束：

• 文件系统：只能写 /workspace
• 网络：白名单（只允许 anthropic.com、npmjs.org 等可信源）
• 资源：限制 CPU/内存

# init-firewall.sh 关键部分（节选）
ALLOWED_DOMAINS=(
    "registry.npmjs.org"
    "api.anthropic.com"
    "github.com"
    "objects.githubusercontent.com"
)
# 其他域名全部拒绝 → 防止 exfiltration

选项 3：冒险模式（不推荐但常见）

• 在你的开发机直接 YOLO
• 尽量避免接触不可信内容（参考 04 Lethal Trifecta）
• 祈祷 Agent 不出大问题

Simon 的诚实评价：

大多数人选择选项 3。

2.3 三种策略的选择决策表

你的处境	推荐策略
处理开源代码、可重做	选项 3（冒险）
处理私有 repo 但任务低风险	选项 2（Docker）
处理含密钥、生产数据	选项 1（云端隔离）
处理不可信外部内容	必须选项 1 或 2

2.4 内置 sandbox 是否够用

Coding Agent 自身也实现了 sandbox（Claude Code、Codex CLI）。Simon 谨慎评价：

我目前没看到足够说服我去信任它们的文档。

实际经验：内置 sandbox 是深度防御的一层，但不能作为唯一防线。Docker / Codespaces 仍是更稳的兜底。

---

第三章：为 Loop 设计工具

3.1 Shell vs MCP

很多人先想到给 Agent 加 MCP Server，但 Simon 的判断：

你可以把 MCP 加进来，但我发现用 shell 命令思考通常更高效。Coding Agent 真的很擅长跑 shell 命令。

为什么 shell 优于 MCP：

维度	Shell	MCP
工具数量	几乎无限（任何 CLI）	你装了多少就多少
学习成本（对 LLM）	训练时见过百万次	需要 schema 描述
错误恢复	shell 错误信息丰富	取决于 MCP 实现
灵活性	任意管道、组合	受限于工具签名
网络/包管理	npm/pip install	通常无法动态扩展

实战案例：

# Simon 处理截图任务的做法
# 1. 装 CLI 工具
npm install -g shot-scraper

# 2. 在 AGENTS.md 写一条
echo "To take a screenshot: shot-scraper <url> -w 800 -o file.jpg" >> AGENTS.md

# 3. 启动 Agent
claude

然后在 Claude 里直接说："帮我截 https://example.com 的图存到 example.jpg"。

Agent 看到 AGENTS.md 就知道怎么用，不需要 MCP wrapping。

3.2 何时该用 MCP

不是所有场景 shell 都赢：

场景	推荐
复杂私有系统（公司 CRM、内部 API）	MCP（详见 5-7）
跨设备共享的能力（团队都要用）	MCP
需要原生流式、双向通信	MCP
一次性脚本、本机工具	shell
任意命令组合	shell
探索性试错	shell

3.3 AGENTS.md / CLAUDE.md 的角色

Agent 不会"无中生有"知道你装了什么工具。把它们告诉 Agent 是你的工作。

AGENTS.md 是 agents.md 倡议的统一文件名，Claude Code 用 CLAUDE.md，Cursor 用 .cursorrules——本质都是同一类东西。

在你的项目根放一个：

# AGENTS.md

## 项目环境
- Node 22.x，pnpm 9
- TypeScript 5.x
- Vitest 测试，Playwright e2e

## 常用命令
- `pnpm test` — 单元测试
- `pnpm test:e2e` — E2E 测试
- `pnpm typecheck` — 类型检查
- `pnpm lint:fix` — 修 lint
- `pnpm build` — 构建

## 项目特有工具
- `shot-scraper <url> -w 800 -o file.jpg` — 截图
- `pnpm db:reset` — 重置开发数据库
- `pnpm seed:demo` — 灌测试数据

## 关键约定
- 所有 API 路由必须在 `src/api/` 下
- 状态管理用 Zustand
- 不要直接用 fetch，用 `lib/api-client.ts`

## 验证方式
改完任何代码必须按顺序跑：
1. `pnpm typecheck`
2. `pnpm lint:fix`
3. `pnpm test`

3.4 Agent 自动学习已有工具

好消息：现代 LLM 见过大量 CLI 工具的用法。如果你说：

> 用 playwright python 自动化登录这个网站

模型大概率知道怎么用。Loop 的好处：即使第一次 syntax 错了，Agent 跑一下看错误信息，自己就能改对。

不需要详尽教学，只需要：

1. 工具确实装了
2. 给一个最小例子
3. 让 loop 跑

3.5 工具集的 minimum viable design

设计 loop 时问自己：

问题	例子
Agent 怎么知道是否成功？	pnpm test 退出码
Agent 怎么探索代码库？	grep, cat, find
Agent 怎么修改代码？	edit_file 工具
Agent 怎么尝试新方案？	git worktree / temp branch
Agent 怎么撤销错误？	git reset / git stash

如果某项没有，loop 会卡。

---

第四章：发放最小权限凭证

4.1 凭证的两条铁律

Simon 列的两条核心建议：

1. 优先给 staging / test 环境的凭证

   • 在 staging 搞坏了，不影响真实用户
   • 容易重置

2. 凭证如果能花钱，必须设预算上限

   • Cloud API 凭证、付费 API token
   • 设硬上限（不是告警，是阻断）

4.2 实战案例：Fly.io 性能调试

Simon 给的真实例子。任务：调试 Fly.io 上 scale-to-zero 应用的冷启动延迟。

需要 Agent 能：

• 改 Dockerfile
• 部署到 Fly
• 测启动时间
• 反复迭代

风险：Agent 在主账户乱搞可能搞挂生产服务、烧钱。

解法：

# 1. 在 Fly 创建专门的 organization
fly orgs create agent-experiments

# 2. 设置预算上限
fly orgs billing set-limit agent-experiments --monthly 5

# 3. 创建只能操作这个 org 的 API key
fly tokens create deploy-token --org agent-experiments

# 4. 把这个 token 给 Agent
export FLY_API_TOKEN="..."
claude --yolo
> 调试冷启动延迟：尝试不同的 Dockerfile 优化，每次部署测启动时间，
> 找出最快的方案。预算 $5。

最坏情况：烧 $5 没结果。但如果 Agent 找到了好方案，价值远超 $5。

4.3 通用模式

// 任何要给 Agent 凭证的场景，都套这个模式
interface AgentCredential {
  scope: string;          // 资源边界（org / project / sandbox）
  permissions: string[];  // 最小操作集
  budget?: number;        // 硬上限（如果能花钱）
  ttl: number;            // 凭证有效期（小时）
  audit_log: boolean;     // 记录所有调用
}

// 反例：直接把你的主 API key 给 Agent
const danger = process.env.MAIN_API_KEY;  // ❌

// 正例：临时受限凭证
const safe: AgentCredential = {
  scope: 'project: agent-sandbox-2025-10',
  permissions: ['compute:create', 'compute:read', 'compute:delete'],
  budget: 5,
  ttl: 24,
  audit_log: true,
};

4.4 团队级凭证策略

公司里推 agentic loop 工作流时：

• 不允许任何工程师把生产凭证给 Agent
• 提供"sandbox 凭证池"，工程师按需申请
• 每个 sandbox 凭证自动设预算 + TTL
• 审计所有 Agent 调用，定期 review

参考 6-7 企业 AI 集成与落地。

---

第五章：Plan / Execute / Verify / Reflect 模式

Anthropic 在 Building Effective Agents 中总结的核心 loop 模式。

5.1 四阶段拆解

阶段	输入	输出	LLM 调用次数
Plan	目标	步骤列表	1 次（重型）
Execute	当前步骤	工具调用结果	N 次（轻量）
Verify	结果	是否符合标准	1 次（中型）
Reflect	失败原因	修订的计划	1 次（重型）

5.2 各阶段的实现

// 简化版 Anthropic 风格 loop
class AgenticLoop {
  async run(goal: string): Promise<Result> {
    let attempt = 0;
    let plan = await this.plan(goal);
    
    while (attempt < this.MAX_ATTEMPTS) {
      // Execute：按 plan 跑工具
      const results = await this.execute(plan);
      
      // Verify：检查是否达标
      const verdict = await this.verify(goal, results);
      
      if (verdict.success) {
        return { success: true, results, attempts: attempt + 1 };
      }
      
      // Reflect：分析失败，重新规划
      plan = await this.reflect({
        original_plan: plan,
        results,
        why_failed: verdict.reason,
      });
      
      attempt++;
    }
    
    return { success: false, reason: 'max_attempts_exceeded' };
  }
  
  // Plan：用强模型，分析问题，生成步骤
  async plan(goal: string) { /* ... Claude Opus / Sonnet */ }
  
  // Execute：用快模型 + 工具，机械执行
  async execute(plan: Plan) { /* ... Claude Haiku，可并行 */ }
  
  // Verify：用强模型，严格判断
  async verify(goal: string, results: any) { /* ... Sonnet */ }
  
  // Reflect：用强模型，深度反思
  async reflect(context: any) { /* ... Sonnet */ }
}

关键点：

• Plan 和 Reflect 用强模型（推理重）
• Execute 用快模型（可能调用很多次）
• Verify 用强模型（标准要严）

成本结构：

• 90% 调用是 Execute（便宜）
• 10% 调用是 Plan/Reflect/Verify（贵但少）
• 总成本远低于全用 Sonnet

5.3 Verify 的关键

很多 loop 失败的根因是 Verify 太宽松——LLM 倾向于"看起来对就 OK"。

不要：

// ❌ 反模式：让 LLM 自己说"完成了吗"
const verdict = await llm.ask("Has the goal been achieved?");

要：

// ✅ 正例：用确定性方法验证
async function verify(goal: TestGoal, results: any) {
  // 1. 跑实际测试
  const testResult = await exec("pnpm test");
  if (testResult.exitCode !== 0) {
    return { success: false, reason: testResult.stderr };
  }
  
  // 2. 检查具体指标
  if (goal.maxLatency && results.latency > goal.maxLatency) {
    return { success: false, reason: `latency ${results.latency} > ${goal.maxLatency}` };
  }
  
  // 3. 只在确定性检查通过后，才让 LLM 做"主观"判断
  const subjective = await llm.evaluate(goal.description, results);
  return subjective;
}

Verify 应该尽量是机械的、可复现的。让 LLM 判断作为最后一层。

5.4 Reflect 的写法

Reflect 不是 "再来一次"。它需要从失败中提取结构化信息：

const reflectPrompt = `
原始目标：${goal}

之前的计划：
${JSON.stringify(plan, null, 2)}

执行结果：
${JSON.stringify(results, null, 2)}

为什么没达成目标：
${verdict.reason}

请分析：
1. 计划中哪一步出了问题？
2. 是计划设计错了，还是执行环境的问题？
3. 修订的计划应该是什么？

输出 JSON：
{
  "diagnosis": "问题诊断",
  "root_cause": "根因",
  "revised_plan": [...步骤列表...]
}
`;

不要让 LLM 一句话说"换个方法试试"。让它结构化诊断。

---

第六章：Loop 终止条件

6.1 三种合理的终止

每个 loop 必须有清晰终止条件，否则会无限烧 token：

终止类型	触发	处理
Success	Verify 通过	返回结果
Max attempts	达到尝试上限	返回最佳尝试 + 失败原因
Budget exhausted	超过 token / 时间 / 金钱预算	立即停止

6.2 常见反模式

反模式 1：无限重试

while (true) {  // ❌
  const result = await tryAgain();
}

反模式 2：成功标准模糊

if (await llm.ask("done?") === "yes") break;  // ❌ LLM 会说 yes

反模式 3：只看 LLM 输出

if (response.includes("complete")) break;  // ❌

6.3 工程化的终止设计

class LoopController {
  constructor(
    private maxAttempts: number = 10,
    private maxTokens: number = 100_000,
    private maxTime: number = 30 * 60_000,  // 30 min
    private maxCost: number = 5  // $5
  ) {}
  
  shouldContinue(state: LoopState): boolean {
    if (state.success) return false;
    
    if (state.attempts >= this.maxAttempts) {
      throw new Error('max_attempts_exceeded');
    }
    
    if (state.tokensUsed >= this.maxTokens) {
      throw new Error('token_budget_exceeded');
    }
    
    if (Date.now() - state.startTime >= this.maxTime) {
      throw new Error('time_budget_exceeded');
    }
    
    if (state.estimatedCost >= this.maxCost) {
      throw new Error('cost_budget_exceeded');
    }
    
    return true;
  }
}

关键：每个限制都是硬上限，不是建议。超出立即停止。

6.4 失败也要有产出

loop 失败不应该是空手而归：

interface LoopResult {
  success: boolean;
  
  // 即使失败，也提供这些
  best_attempt: any;          // 最接近目标的尝试
  attempts_log: AttemptLog[]; // 所有尝试的详细记录
  diagnosis: string;          // 失败原因分析
  recommended_next_steps: string[];  // 建议下一步（人工接手）
}

这样人类接手时能立刻基于"已经探索过的空间"继续，而不是从头开始。

---

第七章：何时设计 Agentic Loop

7.1 触发信号

Simon 给出的核心信号：

当你心里浮起 "呃，我得试一堆变体" —— 这是 agentic loop 的强烈信号。

具体场景：

场景	为什么 loop 适合
调试失败的测试	跑测试 = 即时反馈，可能要试多次
性能优化	测延迟 = 量化反馈，需要 A/B/C 比较
升级一堆依赖	每个依赖一次小循环
优化镜像大小	试不同 base image、试不同 RUN 顺序
找最优 SQL 索引	EXPLAIN 是直接反馈
修一类 lint 错误	修一个验证一个

7.2 不该用 loop 的场景

场景	原因	替代
写新功能（无现成测试）	没有 verify 标准	先写规范 + 测试，再 loop
重构架构	需要人类决策	architect 模式（参考 05）
改用户体验细节	主观、不可自动测	自己改 + AI 辅助
写文档	没有 verify	chat 模式
一次性脚本	loop 开销太大	直接 prompt

7.3 决策流程

新任务来了
  ↓
有明确的成功标准吗？
  ↓ 否 → 不要用 loop
  ↓ 是
能用代码 / 命令验证吗？
  ↓ 否 → 不要用 loop
  ↓ 是
单次解决能行吗？
  ↓ 是 → 用普通 prompt（不需要 loop）
  ↓ 否（需要试错）
  → 设计 agentic loop

7.4 把"不适合 loop"的问题转化

很多问题表面不适合 loop，但稍加改造就行：

例 1：UI 美观度

• 表面：主观，不可测
• 改造：加 visual regression test (Percy / Chromatic) → 可测了

例 2：API 设计

• 表面：风格问题
• 改造：写一份"API 设计 spec"，让 loop 验证实现是否合规

例 3：写新功能

• 表面：没有现成测试
• 改造：先用 loop 让 AI 根据需求生成测试，review 测试，再用 loop 写实现

---

第八章：实战例子

8.1 例：debug 失败的 e2e 测试

# 准备
git checkout -b debug-flaky-test
docker run -d ...  # 启动测试环境

# 启动 loop（在 Docker 沙箱里 YOLO）
claude --dangerously-skip-permissions

> 任务：
> tests/e2e/checkout.spec.ts 在 CI 一直失败但本地不复现。
> 
> 工具可用：
> - pnpm test:e2e:checkout（跑这个测试）
> - git diff main..（看最近改了什么）
> - docker logs（看后端日志）
> 
> 成功标准：
> 1. 找到失败根因
> 2. 给出修复方案（可能是测试问题，也可能是代码问题）
> 3. 修复后跑 pnpm test:e2e:checkout 10 次都通过
> 
> 限制：
> - 最多迭代 15 次
> - 最多 1 小时
> - 不修改其他测试文件

Agent 在这个 loop 里：

1. 跑测试观察失败
2. 看 git diff 找可疑改动
3. 看 docker logs 找错误模式
4. 假设问题、加 console.log、再跑
5. 多次迭代后定位 + 修复

8.2 例：优化 Docker 镜像大小

> 任务：减小 Dockerfile 构建出的镜像大小。当前 1.2GB，目标 < 500MB。
> 
> 工具：
> - docker build -t test-image .
> - docker images test-image  # 看大小
> - dive test-image            # 分析层
> - pnpm test                  # 验证功能
> 
> 成功标准：
> 1. 镜像大小 < 500MB
> 2. pnpm test 通过
> 3. docker run test-image 能正常启动
> 
> 限制：
> - 最多迭代 10 次
> - 不能用 alpine（已知有 glibc 兼容问题）

Agent 会试：换 base image、合并 RUN 层、清理 cache、用 multi-stage build……每次试完测试 + 看大小。这是经典的"试一堆变体"场景。

8.3 例：升级所有 minor 依赖

> 任务：把 package.json 里所有依赖升级到最新 minor 版本。
> 
> 工具：
> - pnpm outdated（看哪些过期）
> - pnpm update <package> --latest（升级）
> - pnpm test（验证）
> - pnpm typecheck（验证类型）
> 
> 成功标准：
> 1. 所有依赖在最新 minor 版本
> 2. pnpm test 全过
> 3. pnpm typecheck 全过
> 
> 限制：
> - 不升级 major 版本
> - 不引入新依赖
> - 每个包升级后必须验证再升下一个（不要批量升）

经典的繁琐试错任务，loop 极其适合。

---

第九章：Loop 设计的常见错误

9.1 反模式总结

反模式	后果	修正
无限循环	烧光 token	加 max_attempts
没有 verify	Agent 自我满足	用确定性测试 verify
LLM 自我评分	100% 通过率假象	让 LLM 评分前先用代码验证
工具集太小	Agent 卡住	加 grep、find、git 等基础工具
工具集太大	Agent 选择困难	只暴露当前任务相关
凭证太宽	安全风险	临时 + 限额 + 审计
忘了 reflect	失败重复同样错误	每次失败结构化诊断
Plan 用便宜模型	计划漏洞百出	Plan 用强模型
Execute 用强模型	成本爆炸	Execute 用 Haiku

9.2 调试 loop 不工作的方法

loop 跑得不好时，按顺序检查：

1. 看 verify 标准是否真的客观可测
2. 看 plan 阶段是否真的拆出了清晰步骤
3. 看 execute 工具是否够用（Agent 卡住时常因为缺工具）
4. 看 reflect 阶段是否真的从失败学习（不是简单重试）
5. 看终止条件是否合理（提前终止 vs 应该继续）

---

第十章：未来方向

10.1 Loop 的 IDE 集成

2026 年的 IDE 开始把 loop 设计可视化：

• Loop 状态实时展示（plan / execute / verify / reflect）
• 工具调用 trace
• attempt history 和 diff
• 一键回到任意 attempt

代表：Claude Code for web、Cursor 的 Composer 模式。

10.2 多 Agent 协作 Loop

Anthropic 的 Multi-Agent Research System 论文展示了一个 Lead Agent + 多个 Subagent 的 loop：

• Lead 决定子任务、分发
• Subagent 各跑自己的 loop
• Lead 综合 Subagent 结果
• 整体也是一个大 loop

详见 5-6 第三章 Supervisor 模式。

10.3 自进化 Loop

研究方向：让 Agent 在多次 loop 后自动改进 plan 质量：

• 记录所有历史 attempt
• 学习"哪些 plan 模式更容易成功"
• 下次类似任务自动应用

还在论文阶段，但 Cursor、Codex 已经开始引入"任务记忆"。

---

权威资料

• Designing agentic loops (Simon Willison, 2025-09-30)
• I think "agent" may finally have a widely enough agreed upon definition (Simon Willison, 2025-09-18)
• Building Effective Agents (Anthropic)
• Claude Code Best Practices - Safe YOLO mode
• Claude Code Dev Container
• agents.md
• Multi-Agent Research System (Anthropic)
• 5-6 Agent 工程深度（前置）
• 04 Lethal Trifecta（YOLO 安全边界）
• 05 Parallel & Async Coding Agents
• 06 Agentic Engineering

核对日期：2026-06-12