系列文章
本篇是 Claude Code 系列的第 8 篇（完结篇）。系列将从安装入门到高级实战，由浅入深地拆解这个终端原生 Coding Agent 的每一个能力。
入门篇
- Claude Code 是什么？从安装到第一次对话
- 日常开发工作流：用 Claude Code 重塑你的编码习惯
核心篇
3. 内置命令全解：从 /compact 到 /doctor 的实战指南
4. CLAUDE.md：项目上下文工程的艺术
进阶篇
5. 多文件重构与复杂任务实战
6. Hooks、MCP 与能力扩展
高级篇
7. Headless 模式与 CI/CD 集成
8. 多 Agent 协作：从 Claude Code 到 Codex（本文）
一、从单兵作战到团队协作
在前七篇文章中，我们一直在和一个 Claude Code 实例对话。它能读代码、改文件、跑测试、调用 MCP 工具——能力很强，但始终是”一个 Agent 干所有活”。
这在日常开发中完全够用。但当任务复杂度超过某个阈值时，单 Agent 模式开始力不从心：
1
2
3
4
5
6
| 场景：重构一个微服务的认证模块
├── 需要修改 15 个文件
├── 涉及 Spring Security 配置、JWT 工具类、Filter 链、Controller 层
├── 还要同步更新单元测试和集成测试
├── 中间可能触发多次 /compact 来压缩上下文
└── 总 Token 消耗：~200K，耗时 45 分钟
|
一个 Agent 串行处理 15 个文件，每一步都依赖前一步的结果。上下文窗口不断膨胀，/compact 压缩又会丢失细节。这不是效率问题——这是架构问题。
2025-2026 年，Coding Agent 领域最重要的范式转移就是：从单 Agent 到多 Agent 协作。
本文将深入对比两个最具代表性的实现——Anthropic 的 Claude Code 和 OpenAI 的 Codex CLI——它们各自如何解决”多个 AI Agent 如何协同工作”这个问题。
二、Claude Code 的多 Agent 架构
2.1 SDK 模式：编程式编排
Claude Code 提供了 TypeScript SDK（@anthropic-ai/claude-code），让你可以用代码编排多个 Agent 实例：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| import { claude } from '@anthropic-ai/claude-code';
const results = await Promise.all([
claude({
prompt: '重构 src/auth/ 下的认证逻辑，从 Session 迁移到 JWT',
cwd: './project',
allowedTools: ['Edit', 'Write', 'Bash'],
maxTurns: 20,
}),
claude({
prompt: '根据 src/auth/ 的变更，更新对应的单元测试',
cwd: './project',
allowedTools: ['Edit', 'Write', 'Bash'],
maxTurns: 15,
}),
claude({
prompt: '分析 src/auth/ 的变更，生成 CHANGELOG 和迁移指南',
cwd: './project',
allowedTools: ['Read', 'Glob'],
maxTurns: 10,
}),
]);
|
这里的关键设计决策是：每个 Agent 实例拥有独立的上下文窗口。Agent 1 不需要知道测试长什么样，Agent 3 不需要理解 JWT 的实现细节。它们通过文件系统这个共享状态来协调——Agent 1 改完代码后写入磁盘，Agent 2 读取变更后的文件来更新测试。
这和微服务的哲学完全一致：通过共享存储解耦，而不是通过消息传递耦合。
2.2 Headless 模式的管道编排
在第七篇中我们详细介绍了 Headless 模式。这里要展示的是如何用 Unix 管道将多个 Claude Code 实例串联：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| #!/bin/bash
ANALYSIS=$(claude -p "分析 GitHub Issue #42 的内容，输出需要修改的文件列表和修改方案" \
--output-format json \
--max-turns 5)
FILES=$(echo "$ANALYSIS" | jq -r '.result' | grep -oP 'src/\S+\.java')
for FILE in $FILES; do
claude -p "根据以下方案修改 $FILE: $(echo $ANALYSIS | jq -r '.result')" \
--allowedTools Edit,Read \
--max-turns 10 &
done
wait
claude -p "运行 mvn test，如果有失败的测试，分析原因并修复" \
--allowedTools Bash,Edit,Read \
--max-turns 15
|
这段脚本体现了管道模式：分析 → 拆解 → 并行执行 → 验证。每个阶段是一个独立的 Agent 实例，通过 shell 变量传递上下文。
2.3 Agent SDK：构建自定义多 Agent 系统
2026 年 Anthropic 推出的 Agent SDK 把多 Agent 协作推向了新高度。它不再是”启动多个 Claude Code 实例”，而是让你能构建自定义的 Agent 编排系统：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| import { Agent, Orchestrator } from '@anthropic-ai/agent-sdk';
const architectAgent = new Agent({
name: 'architect',
model: 'claude-sonnet-4-20250514',
systemPrompt: '你是架构师，负责分析需求、设计方案、拆解任务。',
tools: ['Read', 'Glob', 'Grep'],
});
const coderAgent = new Agent({
name: 'coder',
model: 'claude-sonnet-4-20250514',
systemPrompt: '你是高级开发，负责根据架构方案编写代码。',
tools: ['Edit', 'Write', 'Bash'],
});
const reviewerAgent = new Agent({
name: 'reviewer',
model: 'claude-sonnet-4-20250514',
systemPrompt: '你是代码审查者，负责检查代码质量、安全性和测试覆盖。',
tools: ['Read', 'Glob', 'Grep', 'Bash'],
});
const orchestrator = new Orchestrator({
agents: [architectAgent, coderAgent, reviewerAgent],
workflow: 'sequential',
});
|
这种模式的精髓在于关注点分离。每个 Agent 只需要理解自己的角色，不需要具备全部能力。架构师不需要会写代码（它只需要 Read），审查者不需要会写文件（它只需要 Read 和分析）。
2.4 Claude Code 的子 Agent 生成
在交互模式下，Claude Code 也能动态生成子 Agent。当你给它一个复杂任务时，它会自动拆解并委派：
1
2
3
4
5
6
7
8
9
10
11
| 你> 重构整个认证模块，从 Session 迁移到 JWT，同时保持向后兼容
Claude Code> 我来分析这个任务，需要：
1. 先分析现有的 Session 认证实现
2. 设计 JWT 方案
3. 逐步迁移每个组件
[启动子任务 1: 分析 src/auth/ 下的 Session 实现]
[启动子任务 2: 分析 src/config/ 下的 Security 配置]
[综合分析结果，制定迁移方案]
[开始执行迁移...]
|
这种”主 Agent + 子 Agent”的模式在复杂任务中特别有效。主 Agent 负责全局规划和协调，子 Agent 负责具体的局部任务。
三、OpenAI Codex CLI：另一种路径
3.1 Codex CLI 是什么
2025 年 4 月，OpenAI 开源了 Codex CLI——一个运行在终端的 Coding Agent。它的定位和 Claude Code 高度重叠：读代码、改文件、跑命令，但在架构设计上有显著差异。
1
2
3
4
5
6
|
npm install -g @openai/codex
codex "解释这个项目的架构"
codex "修复 src/api/handler.ts 中的错误处理"
|
3.2 核心架构差异
Codex CLI 和 Claude Code 的根本差异在于安全模型和执行模型：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| ┌─────────────────────────────────────────────────────────────────┐
│ Claude Code vs Codex CLI │
├──────────────────────┬──────────────────────────────────────────┤
│ 维度 │ Claude Code │ Codex CLI │
├──────────────────────┼──────────────────────┼────────────────────┤
│ 执行沙箱 │ 直接操作文件系统 │ Docker 容器沙箱 │
│ 权限模型 │ 逐次确认 / YOLO 模式 │ 三级：suggest/auto │
│ │ │ /full-auto │
│ 文件修改方式 │ 直接写入磁盘 │ 沙箱内修改后 diff │
│ 多模型支持 │ Claude 系列 │ GPT-4o / o3 / o4-mini│
│ 上下文管理 │ /compact 手动压缩 │ 自动滑动窗口 │
│ MCP 支持 │ 原生支持 │ 不支持 │
│ 多 Agent 原生支持 │ SDK + 子 Agent │ 无原生支持 │
│ 子进程管理 │ Bash tool 直接执行 │ 沙箱内受限执行 │
└──────────────────────┴──────────────────────┴────────────────────┘
|
最核心的差异是执行沙箱。Codex CLI 默认在 Docker 容器中运行所有命令，你看到的是它在沙箱内执行后的 diff 输出。这意味着：
1
2
3
4
5
| Codex CLI 的工作流：
1. 读取你的代码（从宿主机复制到沙箱）
2. 在沙箱内执行修改和命令
3. 生成 diff，展示给你
4. 你确认后，diff 应用到宿主机
|
1
2
3
4
5
| Claude Code 的工作流：
1. 直接读取你的代码
2. 直接修改文件（需要权限确认）
3. 直接在你的终端执行命令
4. 即时反馈
|
Codex CLI 的沙箱模型更安全（Agent 无法意外删除你的文件），但灵活性更低（无法访问宿主机的网络、环境变量、Docker daemon 等）。
3.3 Codex CLI 的权限三级模型
Codex CLI 的权限设计比 Claude Code 更细粒度：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| suggest 模式（默认）：
├── Agent 提出建议
├── 每个操作都需要你手动批准
└── 最安全，适合探索性任务
auto 模式：
├── Agent 自动执行文件读写
├── 但命令执行仍需确认
└── 适合日常开发
full-auto 模式：
├── Agent 完全自主执行
├── 仅在沙箱内操作
├── 网络访问受限
└── 适合自动化流水线
|
对比 Claude Code 的权限模型：
1
2
3
4
5
| Claude Code：
├── 默认模式：逐次确认（文件写入、命令执行）
├── --allowedTools：预授权特定工具
├── --dangerously-skip-permissions：跳过所有确认
└── 没有中间态——要么全部确认，要么全部跳过
|
Codex CLI 的 auto 模式是一个巧妙的中间态：它让你信任文件操作（低风险），但保留对命令执行的审批权（高风险）。这种”分级信任”的设计理念，比 Claude Code 的二元选择更细腻。
3.4 Codex CLI 的局限
Codex CLI 在多 Agent 场景下有几个明显的短板：
没有原生的多 Agent 编排。你无法像 Claude Code SDK 那样在代码中启动多个 Codex 实例并行工作。要实现多 Agent 协作，你只能用 shell 脚本拼接多个 codex 调用——这和用 claude -p 管道编排类似，但缺少 SDK 级别的抽象。
沙箱限制了 Agent 间通信。在 Docker 沙箱内运行的 Agent 无法直接访问宿主机的文件系统，这意味着多个 Codex 实例无法像 Claude Code 那样通过共享文件来协调工作。
模型选择受限于 OpenAI 生态。你无法在 Codex CLI 中使用 Claude 或 Gemini 模型，而 Claude Code 的 SDK 理论上可以通过 API 代理接入不同模型。
四、多 Agent 协作的设计模式
理解了两个工具的架构差异后，我们来总结几种实用的多 Agent 协作模式。
模式一：主管-工人（Orchestrator-Worker）
这是最常见的模式。一个”主管” Agent 负责分析任务、拆解子任务、分配给”工人” Agent、最后汇总结果。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| #!/bin/bash
PLAN=$(claude -p "
分析这个 Spring Boot 项目的认证模块。
输出一个 JSON 格式的重构计划，包含：
1. tasks: 需要修改的文件列表和修改内容
2. dependencies: 任务间的依赖关系
3. test_files: 对应的测试文件
" --output-format json --max-turns 8)
TASKS=$(echo "$PLAN" | jq -r '.result' | jq -c '.tasks[]')
echo "$TASKS" | while read -r TASK; do
FILE=$(echo "$TASK" | jq -r '.file')
ACTION=$(echo "$TASK" | jq -r '.action')
claude -p "修改 $FILE: $ACTION" \
--allowedTools Edit,Read \
--max-turns 5 &
done
wait
claude -p "运行 mvn test，分析失败的测试并修复" \
--allowedTools Bash,Edit,Read \
--max-turns 15
|
适用场景：大规模重构、多文件变更、需求分析与执行分离。
设计要点：主管 Agent 用 JSON 输出结构化计划，工人 Agent 用 --allowedTools 限制权限（只允许读写，不允许跑命令），验证 Agent 拥有完整权限。
模式二：流水线（Pipeline）
多个 Agent 按顺序执行，每个 Agent 的输出是下一个 Agent 的输入：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| #!/bin/bash
ANALYSIS=$(claude -p "分析 src/ 下的代码质量，输出问题列表" \
--output-format json --max-turns 5)
FIXES=$(claude -p "根据以下问题列表生成修复方案：$ANALYSIS" \
--output-format json --max-turns 8)
claude -p "根据以下方案执行修复：$FIXES" \
--allowedTools Edit,Write,Bash --max-turns 20
REVIEW=$(claude -p "审查刚才的修改，检查是否有遗漏或引入新问题" \
--output-format json --max-turns 10)
echo "$REVIEW"
|
适用场景：CI/CD 流水线中的自动化代码审查、渐进式重构。
设计要点：每个阶段的 Agent 上下文窗口是独立的，不会因为前一阶段的大量 Token 而溢出。代价是上下文传递依赖 JSON 序列化，可能丢失细节。
模式三：辩论-共识（Debate-Consensus）
两个 Agent 对同一问题给出不同方案，第三个 Agent 做最终决策：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| #!/bin/bash
SOLUTION_A=$(claude -p "
分析 src/auth/ 的认证问题。
推荐使用 Spring Security OAuth2 方案。
输出：方案描述、优缺点、实现步骤。
" --output-format json --max-turns 10)
SOLUTION_B=$(claude -p "
分析 src/auth/ 的认证问题。
推荐使用自定义 JWT + Filter 方案。
输出：方案描述、优缺点、实现步骤。
" --output-format json --max-turns 10)
DECISION=$(claude -p "
对比以下两个方案，从安全性、可维护性、团队熟悉度、迁移成本四个维度评估。
选择更优方案，并说明理由。
方案 A：$SOLUTION_A
方案 B：$SOLUTION_B
" --output-format json --max-turns 8)
|
适用场景：技术选型、架构决策、方案评审。
设计要点：这种模式的核心价值是避免单一 Agent 的偏见。不同 Agent 可能因为上下文窗口中先看到的信息不同而倾向于不同方案，通过”辩论”可以暴露各自的盲点。
模式四：审查-修复循环（Review-Fix Loop）
一个 Agent 写代码，另一个 Agent 审查，循环直到审查通过：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| #!/bin/bash
MAX_ITERATIONS=5
for i in $(seq 1 $MAX_ITERATIONS); do
echo "=== 迭代 $i ==="
claude -p "实现用户注册接口，包含邮箱验证和密码加密" \
--allowedTools Edit,Write,Read,Bash \
--max-turns 15
REVIEW=$(claude -p "
审查 src/ 下最近修改的代码。
检查：安全性、代码风格、异常处理、测试覆盖。
如果没有问题，输出 'PASS'。
如果有问题，输出具体的问题列表和修复建议。
" --output-format json --max-turns 8)
if echo "$REVIEW" | grep -q "PASS"; then
echo "审查通过！"
break
fi
echo "发现问题，继续修复..."
done
|
适用场景：高质量代码生成、安全敏感模块的开发。
设计要点：审查 Agent 必须和写代码的 Agent 使用不同的 system prompt——审查者需要的是”挑毛病”的视角，不是”实现功能”的视角。用 /compact 无法达到这种分离效果，因为它们共享上下文。
五、生产级多 Agent 方案
5.1 成本控制
多 Agent 意味着多倍的 Token 消耗。在生产环境中，成本控制是第一优先级：
1
2
3
4
5
6
7
8
9
10
11
| 单 Agent 处理 15 个文件的重构：
├── 总 Token: ~200K（上下文不断膨胀）
├── 成本: ~$3.00
└── 耗时: 45 分钟
多 Agent（主管 + 5 个工人）处理同样任务：
├── 主管 Token: ~20K（只分析，不写代码）
├── 每个工人 Token: ~30K（独立上下窗，不膨胀）
├── 总 Token: ~170K（反而更少！）
├── 成本: ~$2.55
└── 耗时: 15 分钟（并行执行）
|
多 Agent 不一定更贵。由于每个 Agent 的上下文窗口独立，避免了单 Agent 的上下文膨胀问题，总 Token 消耗可能反而更低。
5.2 错误处理与回滚
多 Agent 系统的错误处理比单 Agent 复杂得多：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| #!/bin/bash
ROLLBACK_SHA=$(git rev-parse HEAD)
if ! run_multi_agent_refactor; then
echo "任务失败，回滚到 $ROLLBACK_SHA"
git reset --hard "$ROLLBACK_SHA"
exit 1
fi
if ! mvn test -q; then
echo "测试失败，回滚到 $ROLLBACK_SHA"
git reset --hard "$ROLLBACK_SHA"
exit 1
fi
|
关键原则：在启动多 Agent 任务前创建 git 快照，任何阶段失败都回滚到快照。
5.3 日志与可观测性
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| #!/bin/bash
LOG_DIR="logs/multi-agent/$(date +%Y%m%d-%H%M%S)"
mkdir -p "$LOG_DIR"
claude -p "重构认证模块" \
--output-format json \
--max-turns 20 \
> "$LOG_DIR/agent-auth.json" 2>&1 &
claude -p "更新测试" \
--output-format json \
--max-turns 15 \
> "$LOG_DIR/agent-test.json" 2>&1 &
wait
echo "=== 多 Agent 执行报告 ===" > "$LOG_DIR/summary.txt"
echo "总 Agent 数: 2" >> "$LOG_DIR/summary.txt"
echo "总 Token: $(cat $LOG_DIR/agent-*.json | jq -s 'map(.usage.total_tokens) | add')" >> "$LOG_DIR/summary.txt"
echo "总耗时: $SECONDS 秒" >> "$LOG_DIR/summary.txt"
|
六、横向对比：Coding Agent 全景
2026 年的 Coding Agent 市场已经形成了清晰的梯队：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| ┌─────────────────────────────────────────────────────────────┐
│ 2026 年 Coding Agent 全景对比 │
├─────────────┬───────────┬──────────┬──────────┬─────────────┤
│ 维度 │ Claude │ Codex │ GitHub │ Cursor │
│ │ Code │ CLI │ Copilot │ Agent │
├─────────────┼───────────┼──────────┼──────────┼─────────────┤
│ 运行环境 │ 终端/IDE │ 终端 │ IDE/PR │ IDE │
│ 模型 │ Claude │ GPT/o3 │ GPT-4o │ 多模型 │
│ 执行方式 │ 直接执行 │ Docker │ 云端 │ 直接执行 │
│ 多 Agent │ SDK 原生 │ 无 │ 有限 │ 有限 │
│ MCP 支持 │ 原生 │ 无 │ 无 │ 部分 │
│ 自动化 │ Headless │ CLI │ Actions │ 无 │
│ 开源 │ SDK 开源 │ 完全开源 │ 闭源 │ 闭源 │
│ 价格 │ API 计费 │ API 计费 │ $10/月 │ $20/月 │
│ 适合场景 │ 全栈开发 │ 安全敏感 │ PR 审查 │ IDE 深度用户│
└─────────────┴───────────┴──────────┴──────────┴─────────────┘
|
Claude Code 的优势：MCP 生态、SDK 级多 Agent 编排、CLAUDE.md 上下文工程、Headless 模式的自动化能力。
Codex CLI 的优势：Docker 沙箱的安全性、完全开源、分级权限模型、OpenAI 模型生态。
选择建议：
1
2
3
4
5
6
| 如果你是... 推荐选择
├── 需要深度自定义的多 Agent 系统 → Claude Code SDK
├── 安全敏感的企业环境 → Codex CLI（沙箱）
├── 已在 VS Code 生态中 → Cursor Agent
├── 需要 PR 自动审查 → GitHub Copilot
└── 终端原生 + MCP 工具链 → Claude Code
|
七、系列回顾与学习路线
知识图谱
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| Claude Code 系列知识架构
│
├── 入门篇（第 1-2 篇）
│ ├── 安装与配置
│ ├── 第一次对话
│ └── 日常开发工作流
│
├── 核心篇（第 3-4 篇）
│ ├── 内置命令体系
│ └── CLAUDE.md 上下文工程
│
├── 进阶篇（第 5-6 篇）
│ ├── 多文件重构
│ └── Hooks / MCP / Skills
│
└── 高级篇（第 7-8 篇）
├── Headless 模式与 CI/CD
└── 多 Agent 协作 ← 你在这里
|
学习路线推荐
快速上手路线（1-2 天）：
- 第 1 篇：安装到第一次对话 — 安装、配置、基础用法
- 第 2 篇：日常开发工作流 — 融入日常编码节奏
- 第 3 篇：内置命令全解 — 掌握常用命令
完成后：你能在日常开发中高效使用 Claude Code，替代大部分 ChatGPT/Copilot 的场景。
深度定制路线（3-5 天）：
4. 第 4 篇：CLAUDE.md — 让 Claude Code 理解你的项目
5. 第 6 篇：Hooks、MCP 与能力扩展 — 扩展工具链
6. 第 5 篇：多文件重构 — 处理复杂任务
完成后：你能为项目定制专属的 Claude Code 工作流，让它像团队成员一样理解项目规范。
自动化与规模化路线（5-7 天）：
7. 第 7 篇：Headless 模式与 CI/CD — 自动化流水线
8. 第 8 篇：多 Agent 协作 — 多 Agent 编排（本文）
完成后：你能构建自动化的代码审查、重构、测试流水线，让 Coding Agent 成为团队的虚拟成员。
技术选型速查表
| 需求 |
Claude Code 方案 |
替代方案 |
| 代码补全 |
Claude Code 内联建议 |
GitHub Copilot |
| 代码审查 |
Headless + GitHub Actions |
Codex CLI + Docker |
| 多文件重构 |
SDK 多 Agent 并行 |
Cursor Agent 模式 |
| 技术选型 |
辩论-共识模式 |
人工评审 |
| 自动化流水线 |
Headless -p 模式 |
Codex CLI –full-auto |
| 安全敏感场景 |
–allowedTools 细粒度控制 |
Codex CLI Docker 沙箱 |
八、展望：Coding Agent 的下一步
2026 年下半年，Coding Agent 领域有几个值得关注的趋势：
Agent-to-Agent 协议标准化。当前各厂商的多 Agent 编排都是私有实现。Google 推出的 A2A（Agent-to-Agent）协议和 Anthropic 的 MCP 正在尝试建立 Agent 间通信的标准。想象一下：Claude Code 作为主 Agent，调用一个专门做安全扫描的 Agent（可能是其他厂商的），再调用一个做性能分析的 Agent——通过标准协议无缝协作。
从编码到工程的全链路覆盖。Coding Agent 不再只写代码。它们开始参与需求分析（解析 Jira Issue）、架构设计（生成 C4 图）、测试规划（生成测试矩阵）、部署验证（检查 Kubernetes 配置）。Claude Code 的 MCP 生态已经为这种全链路覆盖提供了基础。
本地模型 + 云端大模型的混合架构。用本地小模型（如 Qwen 2.5 Coder 7B）处理简单的代码补全和格式化，用云端大模型（Claude Sonnet 4、GPT-4o）处理复杂的推理和重构。这种混合架构能在控制成本的同时保持质量。
九、总结
本系列的八篇文章，从安装入门到多 Agent 协作，完整覆盖了 Claude Code 作为终端原生 Coding Agent 的全部能力。回顾核心收获：
- Claude Code 不是聊天机器人——它是一个有文件系统访问权、能执行命令的 Agent
- CLAUDE.md 是上下文工程的核心——好的项目文档 = 好的 AI 协作
- Headless 模式打通了自动化的最后一公里——从手动对话到 CI/CD 集成
- 多 Agent 协作是复杂任务的解法——拆解、并行、验证，而不是一个人扛
最后，Coding Agent 的价值不在于”AI 写了多少代码”，而在于开发者能把注意力放在哪里。当 AI 处理了重构、测试、文档这些重复性工作，你就有更多时间思考架构设计、用户体验、业务逻辑——这些真正需要人类智慧的部分。
系列完结。如果你从第 1 篇一路读到这里，恭喜——你已经掌握了 2026 年 Coding Agent 的完整知识体系。接下来要做的，是打开终端，输入 claude，开始你自己的 Agent 之旅。
