AI 大模型概念梳理 2
一、Claude Code
1.1 概述
Claude Code 是 Anthropic 官方推出的命令行 AI 编程助手（CLI Agent），运行在终端中，直接操作本地代码仓库，理解整个项目上下文、执行自然语言指令并完成复杂的软件工程任务。
与聊天式 AI 不同，Claude Code 是一个可行动的 Agent——它不只是回答问题，而是直接执行操作：读写文件、运行命令、创建提交、发起 PR。
1.2 核心能力架构
┌────────────────────────────────────────────────────────┐
│ 用户交互层 │
│ 终端 CLI / IDE 插件 (VS Code/JetBrains) │
├────────────────────────────────────────────────────────┤
│ 任务理解与规划层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ 对话上下文 │ │ Plan模式 │ │ Brainstorming │ │
│ │ 管理 │ │ 设计架构 │ │ 需求探索 │ │
│ └──────────┘ └──────────┘ └──────────────────┘ │
├────────────────────────────────────────────────────────┤
│ 执行引擎层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ 工具调用 │ │ Agent调度 │ │ Task管理 (Todo) │ │
│ │ (Bash/Edit│ │ (子Agent) │ │ 依赖编排 │ │
│ │ Read/Write│ │ │ │ │ │
│ └──────────┘ └──────────┘ └──────────────────┘ │
├────────────────────────────────────────────────────────┤
│ 扩展与集成层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ MCP协议 │ │ Skills │ │ Hooks (钩子系统) │ │
│ │ 外部工具 │ │ 技能插件 │ │ 事件响应 │ │
│ └──────────┘ └──────────┘ └──────────────────┘ │
├────────────────────────────────────────────────────────┤
│ 基础设施层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ Git集成 │ │ 上下文压 │ │ 权限与安全 │ │
│ │ Worktree │ │ 缩 │ │ │ │
│ └──────────┘ └──────────┘ └──────────────────┘ │
└────────────────────────────────────────────────────────┘1.3 关键特性
|
特性 |
说明 |
|---|---|
|
终端原生 |
直接在终端运行，操作本地文件系统和 Shell |
|
工具调用 |
Bash、Read、Write、Edit、Glob、Grep、Agent 等全套工具 |
|
Agent 子代理 |
通过 Agent 工具派生子代理执行独立任务（并行/串行） |
|
Plan 模式 |
先探索代码库设计架构方案，经用户审批后再实施 |
|
Task 管理 |
结构化 Todo 任务追踪，支持依赖关系和状态流转 |
|
Skills 系统 |
模块化技能插件，按需加载领域知识和工作流 |
|
MCP 协议 |
通过 Model Context Protocol 接入外部工具和数据源 |
|
Hooks 钩子 |
事件驱动机制，在工具调用前后等时机自动触发操作 |
|
Git Worktree |
隔离工作区支持，并行处理多个分支任务 |
|
Memory 记忆 |
持久化跨会话记忆（用户偏好、项目上下文、反馈） |
|
权限系统 |
分层权限模型，高危操作需用户确认 |
1.4 工作流程
用户输入自然语言指令
│
▼
意图理解 → 匹配相关 Skills
│
▼
探索代码库 (Glob/Grep/Read)
│
▼
[Plan模式] → 设计执行方案 → 用户审批
│
▼
创建 Task 列表 (含依赖关系)
│
▼
执行任务 (Bash/Edit/Write/Agent...)
│ ├─ 独立任务并行执行 (多 Agent)
│ └─ 依赖任务串行执行
▼
验证结果 (Bash运行测试/lint/启动服务)
│
▼
完成 → 触发 Hooks → 保存 Memory1.5 与其他工具对比
|
维度 |
Claude Code |
GitHub Copilot |
Cursor |
Windsurf |
|---|---|---|---|---|
|
形态 |
CLI 终端 |
IDE 插件 |
IDE (独立编辑器) |
IDE (独立编辑器) |
|
交互模式 |
对话式指令 |
内联补全 + Chat |
Tab 补全 + Chat |
补全 + Agent 模式 |
|
自主程度 |
高（可自主执行多步操作） |
中（补全+问答） |
中高（Agent模式） |
高（Cascade模式） |
|
工具调用 |
完整（Shell/文件/Git/MCP） |
有限 |
有限 |
中 |
|
多 Agent |
原生支持 |
不支持 |
不支持 |
有限 |
|
Skill 扩展 |
完整 Skills 生态 |
扩展有限 |
扩展有限 |
扩展有限 |
|
适用场景 |
复杂工程任务、自动化 |
日常编码补全 |
日常编码 |
中大型项目 |
二、OpenClaw（小龙虾）
2.1 概述
OpenClaw（昵称"小龙虾"/"龙虾"）是由 PSPDFKit 创始人 Peter Steinberger 主导开发的开源 AI 智能体执行框架（Agent Runtime），2025 年 11 月发布，GitHub 星标数已突破 28.5 万，被英伟达 CEO 黄仁勋称为"迄今发布过的最重要软件"。
核心隐喻：龙虾会脱壳蜕皮、持续进化 → OpenClaw 让 AI 从"对话工具"蜕变为能直接操作电脑的"数字员工"。
2.2 五层技术架构
┌──────────────────────────────────────────────────────────┐
│ 第 1 层：用户接口层 (Interface Layer) │
│ ┌────────┬──────────┬───────────┬──────────────────┐ │
│ │ CLI │ Web UI │ WebSocket │ IM通道 │ │
│ │ 终端 │ 可视化面板│ 实时通信 │ (飞书/钉钉/微信/QQ) │ │
│ └────────┴──────────┴───────────┴──────────────────┘ │
├──────────────────────────────────────────────────────────┤
│ 第 2 层：Gateway 核心层 (Runtime Governance) │
│ ┌──────────┬────────────┬───────────┬──────────────┐ │
│ │ 连接管理 │ 配置热加载 │ 健康监控 │ 权限控制 │ │
│ │ 7×24 常驻 │ 无需重启 │ 自愈 │ 细粒度鉴权 │ │
│ └──────────┴────────────┴───────────┴──────────────┘ │
├──────────────────────────────────────────────────────────┤
│ 第 3 层：消息处理层 (Message Processing) │
│ ┌──────────┬────────────┬───────────┬──────────────┐ │
│ │Agent执行器│ 路由系统 │ 会话管理 │ 出站投递 │ │
│ │任务调度 │ 智能分派 │ 跨会话状态 │ 多渠道推送 │ │
│ └──────────┴────────────┴───────────┴──────────────┘ │
├──────────────────────────────────────────────────────────┤
│ 第 4 层：扩展与插件层 (Extension Layer) │
│ ┌──────────┬────────────┬───────────┬──────────────┐ │
│ │ 通道插件 │ Skills系统 │ 多Agent │ ACP 协议 │ │
│ │ 接入各IM │ 2000+技能包 │ 分工协作 │ Agent间通信 │ │
│ └──────────┴────────────┴───────────┴──────────────┘ │
├──────────────────────────────────────────────────────────┤
│ 第 5 层：基础设施层 (Infrastructure) │
│ ┌──────────┬────────────┬───────────┬──────────────┐ │
│ │ 配置管理 │ 日志系统 │ 记忆检索 │ 沙箱安全 │ │
│ │ YAML/JSON │ 全链路追踪 │ 向量+混合 │ 执行隔离 │ │
│ └──────────┴────────────┴───────────┴──────────────┘ │
└──────────────────────────────────────────────────────────┘2.3 核心特性
|
特性 |
说明 |
|---|---|
|
多模型对接 |
ChatGPT、Claude、Gemini、DeepSeek、Kimi、阿里云百炼等主流模型 |
|
系统级操作 |
读写文件、运行代码、操控浏览器、调用系统 API |
|
IM 原生集成 |
通过微信、飞书、钉钉、QQ、Telegram 等直接交互 |
|
多 Agent 协作 |
多个独立 Agent 各有专属工作区、权限和记忆，专业分工 |
|
三层记忆体系 |
工作记忆（当前对话）→ 会话记忆（跨对话持久化）→ 长期记忆（向量检索） |
|
Skills 生态 |
2000+ 社区技能包（ClawHub），覆盖办公/开发/生活全场景 |
|
工程化治理 |
消息去重、并发车道、上下文压缩、故障转移、认证轮换 |
|
ACP 协议 |
Agent Communication Protocol，打通多 Agent 通信调度 |
2.4 Claude Code vs OpenClaw 对比
|
维度 |
Claude Code |
OpenClaw（小龙虾） |
|---|---|---|
|
定位 |
AI 编程助手（专用） |
AI 智能体执行框架（通用） |
|
开源性 |
闭源（Anthropic 官方） |
开源（Apache 2.0） |
|
模型绑定 |
绑定 Claude 系列 |
多模型自由切换 |
|
运行模式 |
CLI 终端交互 |
后台常驻 + 多渠道 |
|
适用场景 |
代码开发、调试、重构 |
办公自动化、运维、生活助手、开发 |
|
IM 集成 |
无 |
微信/飞书/钉钉/QQ/Telegram |
|
多 Agent |
子 Agent 机制 |
完整多 Agent 协作体系 |
|
社区生态 |
Skills + MCP |
2000+ ClawHub 技能包 |
|
部署方式 |
本地安装 |
本地 / 阿里云一键部署 |
2.5 风险与挑战
- Token 消耗大：复杂任务 Token 消耗是普通对话的 10-20 倍，月费可能超过 100 美元
- 安全隐患：需授予系统级权限，存在隐私泄露、文件误删风险
- 使用门槛高：需具备代码基础，部署维护有复杂度
- 竞品涌现：HzClaw（汇智大龙虾）、CoPaw、QClaw、ArkClaw 等
三、Skills 技能系统
3.1 概述
Skills 是 AI Agent 领域的模块化能力扩展机制——将特定领域的知识、工作流程和工具使用规范封装成可复用的"技能包"，Agent 在需要时按需加载。
类比：Skills 之于 AI Agent，如同插件之于 IDE、App 之于手机——让通用 Agent 瞬间获得专业领域能力。
3.2 Skills 的工作原理
用户请求："帮我查看这周的飞书日程"
│
▼
Agent 意图识别 → 匹配 "lark-calendar" Skill
│
▼
加载 Skill 内容：
├── 领域知识（飞书日历 API 结构）
├── 工作流程（查询日程的步骤）
├── 最佳实践（用什么参数、如何处理边界）
└── 安全检查（需用户确认的操作）
│
▼
Agent 按 Skill 指导执行操作 → 返回结果3.3 Skills 的核心要素
|
要素 |
说明 |
示例 |
|---|---|---|
|
name |
唯一标识 |
|
|
description |
触发条件描述 |
"当用户需要飞书日历时使用" |
|
triggers |
何时激活 |
关键词、Intent、URL 模式 |
|
domain_knowledge |
领域专业知识 |
API 参数结构、业务规则 |
|
workflows |
标准化操作流程 |
1. 鉴权 → 2. 查询 → 3. 格式化输出 |
|
tools |
该领域使用的工具集 |
专用 CLI、API 调用、SDK |
|
references |
详细参考文档 |
API 手册、格式规范、模板 |
|
constraints |
安全与规范约束 |
写操作必须确认、不输出敏感信息 |
3.4 Skills 的类型
流程型 Skills（Rigid）
定义严格的操作流程，Agent 必须按步骤执行：
TDD Skill:
Step 1: 编写失败的测试
Step 2: 运行测试确认失败
Step 3: 编写最简实现代码
Step 4: 运行测试确认通过
Step 5: 重构优化知识型 Skills（Flexible）
提供领域知识和最佳实践，Agent 自行决策如何应用：
飞书日历 Skill:
- API 端点列表
- 参数格式说明
- 身份认证方式
- 常见错误及处理编排型 Skills
协调多个 Agent/工具完成复杂多步任务：
会议纪要工作流 Skill:
1. 查询指定时间范围的会议列表 (lark-vc)
2. 逐一下载会议纪要
3. 汇总整理为结构化报告
4. 创建飞书文档发布3.5 Skills 生态对比
|
平台 |
Skills 机制 |
规模 |
开放性 |
|---|---|---|---|
|
Claude Code (Superpowers) |
本地 Skill 文件（Markdown） |
30+ 内置 |
社区贡献 |
|
OpenClaw (ClawHub) |
NPM 包分发 |
2000+ |
完全开放 |
|
Cursor |
Rules (.cursorrules) |
自定义 |
本地配置 |
|
GitHub Copilot |
Custom Instructions |
自定义 |
本地配置 |
|
Windsurf |
Rules + Memories |
自定义 |
本地配置 |
3.6 Skills vs MCP vs Hooks
|
机制 |
定位 |
作用方式 |
|---|---|---|
|
Skills |
知识 + 流程扩展 |
Agent 决策时加载，指导"怎么想、怎么做" |
|
MCP (Model Context Protocol) |
工具 + 数据扩展 |
Agent 需要时调用，提供"能做什么、能看什么" |
|
Hooks |
事件 + 自动化 |
工具调用前后触发，实现"在什么时候自动做什么" |
四、Spec 架构
4.1 概述
Spec 架构（Specification-Driven Architecture） 是一种以规格说明文档驱动 AI Agent 行为的架构模式。核心理念：在动手写代码之前，先用结构化的 Spec 文档描述"做什么"和"怎么做"，Agent 严格按 Spec 执行。
4.2 Spec 架构的核心思想
传统模式：用户说需求 → AI 直接写代码 → 反复改
Spec 模式：用户说需求 → 生成 Spec → 用户审批 → AI 按 Spec 执行 → 验收为什么需要 Spec？
|
问题 |
Spec 如何解决 |
|---|---|
|
AI 理解偏差 |
Spec 作为"合同"，锁定需求细节 |
|
需求变更频繁 |
Spec 是可追溯的变更依据 |
|
大任务不可控 |
Spec 拆分为可验证的子任务 |
|
质量无保证 |
Spec 定义验收标准和测试用例 |
|
多人协作冲突 |
Spec 作为协作的"唯一真相来源" |
4.3 Spec 文档的典型结构
# project.spec.yaml
project: 用户管理系统
version: 1.0
requirements: # 需求描述
- id: REQ-001
description: 用户可以通过邮箱和密码注册
priority: P0
architecture: # 架构设计
frontend: React + TypeScript
backend: Node.js + Express
database: PostgreSQL
modules: # 模块划分
- name: auth # 认证模块
files: [login.ts, register.ts, middleware.ts]
dependencies: [database, email]
tasks: # 执行计划
- id: TASK-001
module: auth
description: 实现邮箱注册接口
acceptance: 能成功注册并收到确认邮件
test: auth.test.ts
conventions: # 编码规范
naming: camelCase
format: prettier
comments: JSDoc for public API4.4 Spec 架构的实现模式
模式一：CLAUDE.md / AGENTS.md
在项目根目录放置 CLAUDE.md 或 AGENTS.md 作为持久化 Spec：
# CLAUDE.md
## 项目概述
这是一个电商后台管理系统...
## 技术栈
- 前端：Vue 3 + Element Plus
- 后端：Spring Boot + MySQL
## 编码规范
- 默认使用 TypeScript
- 测试框架：Vitest
- 不写多余注释
## 架构约束
- 不允许引入新的第三方依赖
- API 统一使用 /api/v1 前缀模式二：Plan 模式
Claude Code 的 Plan 模式：先进入探索规划阶段，产出 Spec 计划，用户审批后执行。
User: "帮我实现用户权限系统"
→ [EnterPlanMode]
→ 探索代码库 → 设计架构 → 拆分子任务
→ 输出 Plan 文档
→ 用户审批
→ 按 Plan 逐步实施模式三：Spec-First Development
每个功能开发前先写 Spec 文件：
features/
├── user-auth/
│ ├── spec.md ← 实现规格说明
│ ├── plan.md ← 执行计划
│ └── tasks.md ← 任务清单4.5 Spec 架构的优势与挑战
|
优势 |
挑战 |
|---|---|
|
需求明确，减少返工 |
前期投入时间较多 |
|
可追溯、可审计 |
简单任务可能过度设计 |
|
多 Agent 协作有统一依据 |
Spec 维护本身有成本 |
|
质量可度量 |
Spec 粒度的把握需要经验 |
五、SSD 架构（Sub-agent Driven Development）
5.1 概述
SSD（Sub-agent Driven Development / 子代理驱动开发） 是一种将大型开发任务分解为独立子任务，各自派发给专门子 Agent 并行/串行执行，最终合并结果的开发架构模式。
核心思想：不让一个 Agent 扛下所有，而是像工程团队一样分工协作——一个人负责数据库层、一个人负责 API 层、一个人负责 UI 层。
5.2 SSD 架构原理
┌─────────────────────┐
│ 主控 Agent │
│ (Orchestrator) │
│ │
│ 1. 解析 Spec/Plan │
│ 2. 拆分子任务 │
│ 3. 分配子 Agent │
│ 4. 汇总结果 │
│ 5. 集成验证 │
└──────┬──────────────┘
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 子 Agent A │ │ 子 Agent B │ │ 子 Agent C │
│ (数据库层) │ │ (API 层) │ │ (前端组件) │
│ │ │ │ │ │
│ - 建表迁移 │ │ - 接口实现 │ │ - 表单组件 │
│ - DAO 层 │ │ - 路由配置 │ │ - 列表页面 │
│ - 测试 │ │ - 中间件 │ │ - 状态管理 │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
└────────────────┼────────────────┘
│
▼
┌─────────────┐
│ 集成验证 │
│ Agent │
│ │
│ - 端到端测试│
│ - 代码审查 │
│ - 合并代码 │
└─────────────┘5.3 SSD 的执行模式
模式一：并行执行（独立任务）
tasks:
- id: T1
agent: "db-specialist"
description: "创建用户表和订单表"
- id: T2
agent: "api-specialist"
description: "实现用户注册 API"
- id: T3
agent: "ui-specialist"
description: "实现注册页面组件"
execution: parallel # T1, T2, T3 同时进行，互不依赖模式二：串行执行（有依赖关系）
tasks:
- id: T1
agent: "db-specialist"
description: "创建数据库表"
- id: T2
agent: "api-specialist"
description: "实现 API 接口"
depends_on: [T1] # 必须先有表结构
- id: T3
agent: "ui-specialist"
description: "实现前端页面"
depends_on: [T2] # 必须先有 API模式三：混合执行（DAG 有向无环图）
tasks:
T1: [db] ──────┬──→ T3: [api-auth] ──→ T5: [integration-test]
│
T2: [config] ──┘ T4: [ui-common] ──→ T6: [ui-auth]
(T4 与 T3 并行)5.4 SSD 的关键设计决策
|
决策点 |
选项 |
适用场景 |
|---|---|---|
|
Agent 粒度 |
细粒度（一个 Agent 一个函数） |
复杂逻辑，需要专注 |
|
|
粗粒度（一个 Agent 一个模块） |
关联性强的代码 |
|
隔离模式 |
共享工作区 |
需要同步修改同一文件 |
|
|
Worktree 隔离 |
防止冲突，各自独立分支 |
|
知识传递 |
通过 Spec 传递 |
标准化、可追溯 |
|
|
通过对话传递 |
灵活、快速 |
|
错误处理 |
失败即停止 |
强依赖关系 |
|
|
部分成功继续 |
可降级的任务 |
5.5 SSD vs 传统开发模式
|
维度 |
传统单人开发 |
单一 Agent |
SSD 多 Agent |
|---|---|---|---|
|
执行方式 |
顺序开发 |
顺序执行 |
并行 + 串行 |
|
专注度 |
高（单人专注） |
中（上下文稀释） |
高（各 Agent 专注自己领域） |
|
速度 |
慢 |
中 |
快（并行加速） |
|
一致性 |
好 |
逐渐变差（上下文遗忘） |
好（各 Agent 独立上下文） |
|
可审查性 |
好 |
一般 |
好（每个子任务独立 review） |
|
适用规模 |
小型 |
中小型 |
中大型 |
5.6 SSD 在 Claude Code 中的实践
# 场景：实现一个「用户管理」CRUD 模块
# 主 Agent 分解任务后，并行派发
Agent("实现 User 实体和 Repository", agent_type="implementer")
Agent("实现 UserController REST API", agent_type="implementer")
Agent("实现用户列表和表单页面", agent_type="implementer")
# 三个子 Agent 完成后，主 Agent 汇总
# → 运行集成测试
# → 修复集成问题
# → 提交代码六、多 Agent 协同
6.1 概述
多 Agent 协同（Multi-Agent Collaboration） 是指多个 AI Agent 在同一任务或系统中有组织地协作，各自承担不同角色、负责不同子域，通过通信和协调共同完成复杂目标。
核心理念：借鉴人类团队协作模式——一个团队有架构师、开发工程师、测试工程师、DevOps 工程师等不同角色，各司其职，通过会议、文档、代码评审等方式协同。
6.2 多 Agent 协同模式
模式一：层级式（Hierarchical）
┌─────────────┐
│ 总控 Agent │ ← 任务分解、分配、汇总
│ (Manager) │
└──────┬──────┘
┌──────────────┼──────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 开发Agent│ │ 测试Agent│ │ 文档Agent│
└──────────┘ └──────────┘ └──────────┘特点：单一控制点，职责清晰，适合结构化的工程项目。
模式二：对等式（Peer-to-Peer）
┌──────────┐ ┌──────────┐
│ Agent A │◄───►│ Agent B │
│ (前端) │ │ (后端) │
└──────────┘ └──────────┘
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ Agent C │◄───►│ Agent D │
│ (数据库) │ │ (部署) │
└──────────┘ └──────────┘特点：去中心化，Agent 之间直接通信协商，适合复杂动态场景。
模式三：流水线式（Pipeline）
输入 → [Agent A] → [Agent B] → [Agent C] → 输出
需求分析 架构设计 代码实现特点：每个阶段有明确的输入/输出，类似工厂流水线，适合阶段分明的工作流。
模式四：辩论式（Debate/Ensemble）
┌──────────┐
│ Agent A │ → 方案 1
│ (方案A) │
└──────────┘
问题 ──→ → [仲裁Agent] → 最优方案
┌──────────┐
│ Agent B │ → 方案 2
│ (方案B) │
└──────────┘特点：多个 Agent 独立生成方案后，由仲裁 Agent 或投票机制选出最优解。适合需要多角度分析的问题。
模式五：专家协作式（Specialist Collaboration）
┌─────────────┐
│ Agent │
│ (Code │ ← 代码审查
│ Reviewer) │
└─────────────┘
▲
│ 审查意见
▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 安全Agent│ ←→ │ 架构Agent│ ←→ │ 性能Agent│
└──────────┘ └──────────┘ └──────────┘特点：各 Agent 是特定领域的"专家"，从各自专业角度评审或增强产出的质量。
6.3 协同通信机制
|
机制 |
说明 |
示例 |
|---|---|---|
|
共享文件系统 |
通过读写同一代码仓库通信 |
子 Agent 创建文件，主 Agent 读取验证 |
|
消息传递 |
Agent 之间直接发送消息 |
Agent A 调用 Agent B 的 API 接口 |
|
共享内存/状态 |
公共的状态存储 |
Redis 存储共享任务队列 |
|
事件驱动 |
发布-订阅模式 |
"代码已提交"事件触发测试 Agent |
|
Spec/Plan 文档 |
通过结构化文档传递意图 |
主 Agent 写 Plan → 子 Agent 按 Plan 执行 |
6.4 多 Agent 协同的核心挑战
|
挑战 |
说明 |
解决思路 |
|---|---|---|
|
上下文一致性 |
各 Agent 对需求理解可能不一致 |
统一 Spec 文档作为 Single Source of Truth |
|
任务边界划分 |
如何合理拆分任务 |
按模块/层次/功能域划分，最小化耦合 |
|
合并冲突 |
多个 Agent 修改同一文件 |
Worktree 隔离 + Code Review + 合并策略 |
|
通信开销 |
Agent 间协调消耗 Token |
减少不必要的通信，异步化 |
|
质量参差 |
各 Agent 产出质量不一致 |
独立 Review Agent + 自动化验证 |
|
死锁与阻塞 |
循环依赖导致等待 |
依赖分析 + 超时机制 |
|
责任归属 |
出问题时谁负责 |
子任务级别追踪，每个子任务有所有者 |
6.5 实际案例：OpenClaw 多 Agent 配置
# openclaw config
agents:
- id: code-architect
name: 代码架构师
model: deepseek-v4
system_prompt: "你是一个资深的软件架构师..."
skills: [design-patterns, system-design]
- id: frontend-dev
name: 前端开发
model: claude-opus-4
system_prompt: "你是前端开发专家，精通 React/Vue..."
skills: [react, vue, css]
- id: backend-dev
name: 后端开发
model: claude-opus-4
system_prompt: "你是后端开发专家，精通 Java/Go..."
skills: [spring-boot, mysql, docker]
- id: qa-engineer
name: 测试工程师
model: claude-sonnet-4
system_prompt: "你是资深 QA 工程师，擅长测试设计..."
skills: [unit-testing, e2e-testing]
collaboration:
mode: hierarchical
orchestrator: code-architect
workers: [frontend-dev, backend-dev, qa-engineer]七、Harness Engineering（驾驭工程）
7.1 概述
Harness Engineering（驾驭工程） 是 AI Agent 时代的核心工程学科——研究如何设计、构建和维护驾驭 AI 智能体的框架、基础设施和治理体系。
隐喻来源："Harness"（马具/缰绳）→ 如同人类驯服野马后，用缰绳（Harness）将马的力量引导为可控制的生产力。Harness Engineering 就是将 AI Agent 的"智能"转化为可控制、可预测、可治理的"生产力"。
7.2 Harness Engineering 的核心问题
AI 能力的三大特征
┌──────────┬──────────┬──────────┐
│ 强大 │ 不确定 │ 不可靠 │
│ (Powerful)│(Stochastic)│(Fallible)│
└──────────┴──────────┴──────────┘
│
▼
Harness Engineering 要解决的问题：
❓ 如何让 AI 的创造力不变成破坏力？
❓ 如何让 AI 的自主性不失控？
❓ 如何让 AI 的效率提升不带来质量下降？
❓ 如何让多个 AI 协作而非互相冲突？
❓ 如何让 AI 的行为可预测、可审计、可治理？7.3 Harness Engineering 的框架模型
┌─────────────────────────────────────────────────────────────┐
│ Harness Engineering 框架 │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ 指令驾驭层 │ │ 流程驾驭层 │ │ 安全驾驭层 │ │
│ │ (Directive) │ │ (Process) │ │ (Security) │ │
│ │ │ │ │ │ │ │
│ │ • Spec/Plan │ │ • Workflow │ │ • 权限控制 │ │
│ │ • Prompt工程 │ │ • Task编排 │ │ • 沙箱隔离 │ │
│ │ • Skills系统 │ │ • 状态机 │ │ • 审计日志 │ │
│ │ • 知识注入 │ │ • 检查点 │ │ • 输入校验 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ 质量驾驭层 │ │ 效能驾驭层 │ │ 协作驾驭层 │ │
│ │ (Quality) │ │ (Efficiency) │ │ (Collab) │ │
│ │ │ │ │ │ │ │
│ │ • 自动化测试 │ │ • Token 优化 │ │ • 多Agent调度 │ │
│ │ • Code Review│ │ • 缓存策略 │ │ • 任务分配 │ │
│ │ • 验证机制 │ │ • 并行执行 │ │ • 冲突解决 │ │
│ │ • 回归检查 │ │ • 上下文管理 │ │ • 知识共享 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 治理驾驭层 (Governance) │ │
│ │ • 策略管理 (Policy as Code) • 合规审计 │ │
│ │ • 成本追踪 (Cost Tracking) • 版本管理 │ │
│ │ • 监控告警 (Monitoring) • 灾备恢复 │ │
│ └──────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘7.4 驾驭工程的核心组件
组件一：指令驾驭（Directive Harness）
让 AI 准确理解意图，按人类期望行事。
Spec/Plan → 约束 AI 的行为边界
Skills → 注入领域知识和标准流程
Prompt 工程 → 精确引导模型输出组件二：流程驾驭（Process Harness）
让 AI 的执行过程可控、可预测。
Workflow → 定义标准化的执行步骤
Task 编排 → 拆解和调度子任务
检查点 → 关键节点暂停、等待人工确认
状态机 → 管理任务状态的流转组件三：安全驾驭（Security Harness）
防止 AI 越权操作或产生破坏。
权限控制 → 分层授权，高危操作需确认
沙箱隔离 → 限制 AI 的执行环境
审计日志 → 记录所有操作，可追溯
输入校验 → 防止 prompt injection 等攻击组件四：质量驾驭（Quality Harness）
确保 AI 的产出达到质量标准。
自动化测试 → 代码级验证
Code Review → 独立的 AI 或人工审查
验证机制 → 功能级验证（运行服务、点击测试）
回归检查 → 确保新改动不破坏已有功能组件五：效能驾驭（Efficiency Harness）
优化 AI 的资源消耗和响应速度。
Token 优化 → 减少不必要的上下文、使用缓存
并行执行 → 独立任务同时进行
上下文管理 → 摘要压缩、选择性加载
模型分级 → 简单任务用小模型，复杂任务用大模型组件六：协作驾驭（Collaboration Harness）
管理多 Agent 之间的协调。
任务分配 → 哪个 Agent 做什么
冲突解决 → Agent 之间的操作冲突处理
知识共享 → 跨 Agent 的信息传递
结果汇总 → 多 Agent 产出的合并与验证组件七：治理驾驭（Governance Harness）
持续运营和优化 Agent 体系。
策略管理 → 管理 AI 行为的规则和约束
成本追踪 → 监控每个 Agent/任务的 Token 消耗
监控告警 → 异常行为自动告警
版本管理 → Skills、Prompts、Configs 的版本控制7.5 Harness Engineering 的成熟度模型
|
级别 |
名称 |
特征 |
|---|---|---|
|
L0 |
无驾驭 |
直接对话式使用 AI，无系统性控制 |
|
L1 |
基础驾驭 |
有 Prompt 模板、基本的权限控制 |
|
L2 |
流程化驾驭 |
有 Spec/Plan、Skills、Task 管理 |
|
L3 |
自动化驾驭 |
多 Agent 协作、自动化验证、CI/CD 集成 |
|
L4 |
智能化驾驭 |
Agent 自我优化、自适应策略、智能路由 |
|
L5 |
自治驾驭 |
Agent 体系自我治理、持续学习、无需人工干预 |
7.6 实际案例：Harness Engineering 在 Claude Code 中的体现
|
Harness 层 |
Claude Code 的对应能力 |
|---|---|
|
指令驾驭 |
CLAUDE.md、Plan 模式、Skills 系统、Brainstorming |
|
流程驾驭 |
Task 管理（Todo + 依赖关系）、Plan 模式审批 |
|
安全驾驭 |
权限分层模型、高危操作确认门禁（--dry-run） |
|
质量驾驭 |
verification-before-completion 流程、Code Review Agent |
|
效能驾驭 |
MCP 缓存、上下文压缩、并行 Agent 调度 |
|
协作驾驭 |
Sub-agent 机制、Worktree 隔离、Dispatch Parallel Agents |
|
治理驾驭 |
Memory 持久化、Hooks 事件系统、Settings 配置管理 |
八、概念关系全景图
Harness Engineering
（驾驭工程 — 统御全局）
┌─────────────────────┼─────────────────────┐
│ │ │
▼ ▼ ▼
Spec 架构 SSD 架构 多Agent协同
(定方向) (定方法) (定协作)
│ │ │
└─────────────────────┼─────────────────────┘
│
▼
Skills 系统
（可复用的能力单元）
│
┌───────────┼───────────┐
│ │
▼ ▼
Claude Code OpenClaw(小龙虾)
(Anthropic 专用Agent) (开源通用Agent框架)七者关系解读
- Harness Engineering 是顶层哲学：定义了"如何驾驭 AI"的整体框架和方法论
- Spec 架构是方向舵：确保 AI 向正确的方向前进（做什么、如何验证）
- SSD 架构是加速器：通过并行和分工让 AI 更快地完成复杂任务
- 多 Agent 协同是组织力：让多个 AI 像团队一样高效协作
- Skills 系统是工具箱：为 Agent 提供可复用的专业能力
- Claude Code 是精品武器：Anthropic 精心打造的编程专用 Agent
- OpenClaw 是通用平台：开源社区打造的开放 Agent 运行框架
一句话总结：Harness Engineering 告诉我们"如何驾驭"，Spec 架构告诉我们"往哪走"，SSD 架构告诉我们"怎么拆"，多 Agent 协同告诉我们"如何配合"，Skills 告诉我们"用什么工具"，Claude Code 和 OpenClaw 是这套体系的具体实现。