一、引言：谁来指挥 AI Agent 军团？
当 Harness Engineering 规模化应用时，一个核心问题浮现出来：
如何同时管理成百上千个 AI Agent，确保它们高效协作、不冲突、不失控？
这就是**控制平面（Control Plane）**的使命。它是 Harness 的"大脑"和"神经系统"，负责调度、监控、协调所有 Agent 的活动。
本文将深入探讨控制平面的架构设计和实现模式。
二、控制平面的核心职责
2.1 控制平面的定义
控制平面是 Harness 的管理中枢，负责任务调度、资源分配、状态监控、故障处理和人工协作，确保 AI Agent 的执行可控、可观测、可干预。
┌─────────────────────────────────────────────────────────┐
│ 控制平面在 Harness 中的位置 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ │
│ │ 人类工程师 │ │
│ │ （监督和决策） │ │
│ └──────┬──────┘ │
│ │ │
│ ┌──────┴──────┐ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────┐ ┌─────────┐ │
│ │ 控制平面 │ │ 知识库 │ │
│ │(Control)│ │(Knowledge)│ │
│ │ │ │ │ │
│ │• 调度 │ │• 规范 │ │
│ │• 监控 │ │• 示例 │ │
│ │• 协调 │ │• 文档 │ │
│ └────┬────┘ └─────────┘ │
│ │ │
│ ┌─────────┼─────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │ Agent 1│ │ Agent 2│ │ Agent N│ ... │
│ │(执行者) │ │(执行者) │ │(执行者) │ │
│ └────────┘ └────────┘ └────────┘ │
│ │
│ 控制平面是连接人类和 Agent 的桥梁， │
│ 也是管理 Agent 集群的中枢。 │
│ │
└─────────────────────────────────────────────────────────┘
2.2 四大核心职责
职责
说明
关键能力
调度（Scheduling）
决定什么任务由什么 Agent 执行
优先级、负载均衡、依赖管理
监控（Monitoring）
实时掌握所有 Agent 的状态
指标采集、异常检测、可视化
协调（Coordination）
处理 Agent 间的协作和冲突
锁机制、事务、一致性
干预（Intervention）
支持人工介入和异常处理
审批、暂停、回滚、调试
三、控制平面架构设计
3.1 整体架构
┌─────────────────────────────────────────────────────────┐
│ 控制平面架构 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ API 网关层 │ │
│ │ • 任务提交接口 │ │
│ │ • 状态查询接口 │ │
│ │ • 管理操作接口 │ │
│ │ • 认证和授权 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 核心控制层 │ │
│ │ │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ 调度器 │ │ 监控器 │ │ 协调器 │ │ │
│ │ │Scheduler│ │ Monitor │ │Coordinator│ │ │
│ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │
│ │ └─────────────┴─────────────┘ │ │
│ │ │ │ │
│ │ ┌─────┴─────┐ │ │
│ │ │ 状态管理器 │ │ │
│ │ │State Manager│ │ │
│ │ └───────────┘ │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 数据存储层 │ │
│ │ • 任务队列（Redis/RabbitMQ） │ │
│ │ • 状态存储（PostgreSQL） │ │
│ │ • 指标存储（InfluxDB/Prometheus） │ │
│ │ • 事件日志（Kafka/ClickHouse） │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Agent 执行层 │ │
│ │ • Agent 池管理 │ │
│ │ • 健康检查 │ │
│ │ • 负载均衡 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
3.2 核心组件详解
调度器（Scheduler）
┌─────────────────────────────────────────────────────────┐
│ 调度器架构 │
├─────────────────────────────────────────────────────────┤
│ │
│ 输入：任务队列 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 任务1: 重构登录模块 (优先级: High) │ │
│ │ 任务2: 优化查询性能 (优先级: Medium) │ │
│ │ 任务3: 修复 Bug #123 (优先级: Critical) │ │
│ │ ... │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ 调度策略 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 1. 优先级调度 │ │
│ │ Critical > High > Medium > Low │ │
│ │ │ │
│ │ 2. 资源匹配 │ │
│ │ 任务需求 ←→ Agent 能力 │ │
│ │ (内存、CPU、技能、负载) │ │
│ │ │ │
│ │ 3. 依赖管理 │ │
│ │ 检测任务依赖关系，确保顺序执行 │ │
│ │ │ │
│ │ 4. 负载均衡 │ │
│ │ 均匀分配任务，避免单点过载 │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ 输出：任务分配 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Agent-A ← 任务3 (Critical) │ │
│ │ Agent-B ← 任务1 (High) │ │
│ │ Agent-C ← 任务2 (Medium) │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
监控器（Monitor）
┌─────────────────────────────────────────────────────────┐
│ 监控器架构 │
├─────────────────────────────────────────────────────────┤
│ │
│ 数据采集 │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ 性能指标 │ │ 业务指标 │ │ 日志数据 │ │ 事件流 │ │
│ │ │ │ │ │ │ │ │ │
│ │• CPU │ │• 成功率 │ │• 应用日志│ │• 任务事件│ │
│ │• 内存 │ │• 吞吐量 │ │• 系统日志│ │• 错误事件│ │
│ │• 网络 │ │• 延迟 │ │• 审计日志│ │• 状态变更│ │
│ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │
│ └─────────────┴─────────────┴─────────────┘ │
│ ↓ │
│ 处理和分析 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ • 实时聚合（窗口计算） │ │
│ │ • 异常检测（阈值/机器学习） │ │
│ │ • 关联分析（链路追踪） │ │
│ │ • 预测预警（趋势分析） │ │
│ └─────────────────────────────────────────────────┘ │
│ ↓ │
│ 输出和告警 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ • 仪表盘（Grafana） │ │
│ │ • 告警通知（PagerDuty/Slack） │ │
│ │ • 自动响应（扩缩容、重启） │ │
│ │ • 报告生成（日报/周报） │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
协调器（Coordinator）
┌─────────────────────────────────────────────────────────┐
│ 协调器架构 │
├─────────────────────────────────────────────────────────┤
│ │
│ 协调场景 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 场景1：资源共享 │ │
│ │ ├── 多个 Agent 需要修改同一文件 │ │
│ │ ├── 协调器分配锁，确保串行修改 │ │
│ │ └── 避免冲突和覆盖 │ │
│ │ │ │
│ │ 场景2：依赖执行 │ │
│ │ ├── 模块 B 依赖模块 A 的接口 │ │
│ │ ├── 协调器确保 A 完成后再执行 B │ │
│ │ └── 管理复杂的依赖图 │ │
│ │ │ │
│ │ 场景3：分布式事务 │ │
│ │ ├── 跨多个服务的操作需要一致性 │ │
│ │ ├── 协调器管理事务状态 │ │
│ │ └── 失败时协调回滚 │ │
│ │ │ │
│ │ 场景4：结果合并 │ │
│ │ ├── 多个 Agent 分别生成代码片段 │ │
│ │ ├── 协调器合并结果，解决冲突 │ │
│ │ └── 确保最终一致性 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 协调机制 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ • 分布式锁（Redis/Zookeeper） │ │
│ │ • 事务管理（Saga/TCC 模式） │ │
│ │ • 一致性协议（Raft/Paxos） │ │
│ │ • 消息队列（事件驱动协调） │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
四、关键设计模式
4.1 任务调度模式
模式1：优先级队列
python
复制
class PriorityScheduler:
def __init__(self):
self.queues = {
'critical': PriorityQueue(),
'high': PriorityQueue(),
'medium': PriorityQueue(),
'low': PriorityQueue()
}
def submit_task(self, task):
"""提交任务到对应优先级队列"""
priority = task.priority
self.queues[priority].put(task)
def get_next_task(self, agent_capabilities):
"""获取下一个可执行任务"""
# 按优先级顺序检查
for priority in ['critical', 'high', 'medium', 'low']:
queue = self.queues[priority]
if not queue.empty():
task = queue.get()
# 检查资源匹配
if self.matches_capabilities(task, agent_capabilities):
return task
else:
# 放回队列，等待合适的 Agent
queue.put(task)
return None
def matches_capabilities(self, task, capabilities):
"""检查任务需求和 Agent 能力是否匹配"""
return (
capabilities.memory >= task.required_memory and
capabilities.cpu >= task.required_cpu and
all(skill in capabilities.skills for skill in task.required_skills)
)
模式2：工作窃取（Work Stealing）
python
复制
class WorkStealingScheduler:
"""负载均衡调度：空闲 Agent 从繁忙 Agent 窃取任务"""
def __init__(self, num_agents):
self.agent_queues = {i: deque() for i in range(num_agents)}
self.agent_loads = {i: 0 for i in range(num_agents)}
def submit_task(self, task):
"""提交任务到负载最轻的 Agent"""
lightest_agent = min(self.agent_loads, key=self.agent_loads.get)
self.agent_queues[lightest_agent].append(task)
self.agent_loads[lightest_agent] += task.estimated_effort
def get_task(self, agent_id):
"""Agent 获取任务，本地没有则窃取"""
# 先检查自己的队列
if self.agent_queues[agent_id]:
return self.agent_queues[agent_id].popleft()
# 本地没有，尝试从负载最重的 Agent 窃取
heaviest_agent = max(self.agent_loads, key=self.agent_loads.get)
if heaviest_agent != agent_id and self.agent_queues[heaviest_agent]:
stolen_task = self.agent_queues[heaviest_agent].popleft()
self.agent_loads[heaviest_agent] -= stolen_task.estimated_effort
return stolen_task
return None
4.2 状态管理模式
模式：事件溯源 + CQRS
python
复制
class AgentStateManager:
"""使用事件溯源管理 Agent 状态"""
def __init__(self, event_store):
self.event_store = event_store
self.state_cache = {}
async def apply_event(self, agent_id, event):
"""应用事件，更新状态"""
# 持久化事件
await self.event_store.append(agent_id, event)
# 更新缓存状态
if agent_id not in self.state_cache:
self.state_cache[agent_id] = self.create_initial_state()
self.state_cache[agent_id] = self.evolve_state(
self.state_cache[agent_id],
event
)
def evolve_state(self, state, event):
"""根据事件演化状态"""
handlers = {
'AgentStarted': self.handle_started,
'TaskAssigned': self.handle_task_assigned,
'TaskCompleted': self.handle_task_completed,
'AgentFailed': self.handle_failed,
'AgentRecovered': self.handle_recovered
}
handler = handlers.get(event['type'])
if handler:
return handler(state, event)
return state
async def get_state(self, agent_id):
"""获取当前状态（支持从事件重建）"""
if agent_id in self.state_cache:
return self.state_cache[agent_id]
# 从事件存储重建
events = await self.event_store.get_events(agent_id)
state = self.create_initial_state()
for event in events:
state = self.evolve_state(state, event)
self.state_cache[agent_id] = state
return state
# 查询优化（CQRS）
async def get_agent_summary(self):
"""聚合查询，直接读取物化视图"""
return await self.query_store.get_agent_summary()
4.3 人机协作模式
python
复制
class HumanInTheLoop:
"""人机协作控制器"""
def __init__(self):
self.approval_rules = {}
self.pending_approvals = {}
def require_approval(self, task_type, condition):
"""配置需要人工审批的场景"""
self.approval_rules[task_type] = condition
async def check_approval(self, task):
"""检查是否需要人工审批"""
if task.type not in self.approval_rules:
return True # 无需审批
condition = self.approval_rules[task.type]
if condition(task):
# 需要审批
approval_id = await self.request_approval(task)
return await self.wait_for_approval(approval_id)
return True
async def request_approval(self, task):
"""发送审批请求"""
approval_id = generate_id()
# 通知相关人
await self.notify_approvers(task, approval_id)
# 记录待审批
self.pending_approvals[approval_id] = {
'task': task,
'status': 'pending',
'requested_at': time.now()
}
return approval_id
async def approve(self, approval_id, approver, decision):
"""处理审批决策"""
if approval_id not in self.pending_approvals:
raise ApprovalNotFound()
self.pending_approvals[approval_id]['status'] = decision
self.pending_approvals[approval_id]['approver'] = approver
self.pending_approvals[approval_id]['decided_at'] = time.now()
# 通知等待的 Agent
await self.notify_agent(approval_id, decision)
async def wait_for_approval(self, approval_id, timeout=3600):
"""等待审批结果"""
start = time.now()
while time.now() - start < timeout:
if approval_id in self.pending_approvals:
status = self.pending_approvals[approval_id]['status']
if status in ['approved', 'rejected']:
return status == 'approved'
await asyncio.sleep(1)
# 超时
raise ApprovalTimeout()
五、控制平面的可观测性
5.1 关键指标
类别
指标
说明
告警阈值
调度
队列深度
等待调度的任务数
> 100
调度
调度延迟
任务提交到分配的时间
> 30s
调度
匹配成功率
任务与 Agent 成功匹配率
< 95%
监控
数据采集延迟
指标从产生到可见的延迟
> 10s
监控
告警准确率
真实问题 / 总告警数
< 80%
协调
锁等待时间
获取分布式锁的平均时间
> 100ms
协调
事务失败率
分布式事务失败比例
> 1%
整体
控制平面可用性
API 成功率
< 99.9%
5.2 监控仪表盘设计
┌─────────────────────────────────────────────────────────┐
│ 控制平面监控仪表盘 │
├─────────────────────────────────────────────────────────┤
│ │
│ 系统概览 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 活跃 Agent │ │ 运行中任务 │ │ 等待中任务 │ │
│ │ 127 │ │ 89 │ │ 23 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ 调度状态 │
│ 队列深度: [████████░░░░░░░░░░] 45/100 │
│ 平均调度延迟: 12s │
│ 匹配成功率: 98.5% │
│ │
│ Agent 状态分布 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 空闲 [████████░░░░░░░░░░] 38 (30%) │ │
│ │ 工作中 [████████████████░░] 89 (70%) │ │
│ │ 故障 [░░░░░░░░░░░░░░░░░░░░] 0 (0%) │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 最近事件 │
│ 10:05:32 Agent-42 完成任务 task_1234 │
│ 10:05:28 Agent-15 开始执行任务 task_1235 │
│ 10:05:15 新任务提交 task_1236 (优先级: High) │
│ 10:05:10 Agent-08 健康检查通过 │
│ │
│ 告警 │
│ ⚠️ 队列深度接近阈值 (45/100) │
│ │
└─────────────────────────────────────────────────────────┘
六、实践案例：OpenAI 的控制平面
6.1 设计要点
根据 OpenAI 公开的实践，其控制平面的关键设计：
设计
说明
效果
任务分级
Critical/High/Medium/Low 四级优先级
确保关键任务优先处理
资源预留
为重要任务预留专用资源
避免资源争抢
动态扩缩容
根据负载自动调整 Agent 数量
高效利用资源
故障自动恢复
Agent 故障自动检测和替换
高可用性
人工升级机制
复杂问题自动升级给人类
质量保证
6.2 性能数据
- 调度延迟：平均 < 10 秒
- 任务吞吐量：峰值 1000+ 任务/小时
- Agent 利用率：平均 75%
- 故障恢复时间：< 30 秒
七、技术选型建议
7.1 开源方案
组件
推荐方案
适用场景
任务队列
Redis / RabbitMQ / Apache Kafka
小到大规模
状态存储
PostgreSQL / etcd
强一致性要求
配置中心
Consul / etcd / Nacos
动态配置管理
监控
Prometheus + Grafana
指标采集和可视化
链路追踪
Jaeger / Zipkin
分布式追踪
日志
ELK Stack / Loki
日志聚合和分析
7.2 云服务方案
组件
AWS
GCP
Azure
任务队列
SQS / SNS
Pub/Sub
Service Bus
状态存储
DynamoDB
Firestore
Cosmos DB
监控
CloudWatch
Cloud Monitoring
Monitor
编排
Step Functions
Workflows
Logic Apps
八、设计原则与最佳实践
8.1 核心原则
原则
说明
高可用
控制平面故障不应影响已运行的 Agent
低延迟
调度和监控响应要快，不成为瓶颈
可扩展
支持 Agent 数量从 10 到 10000 的扩展
可恢复
控制平面自身故障可快速恢复
可观测
所有决策和操作可追溯
8.2 最佳实践
-
分离控制平面和数据平面
- 控制平面故障不影响正在执行的任务
- Agent 可以短暂脱离控制平面独立运行
-
异步优先
- 使用消息队列解耦组件
- 避免同步调用导致的阻塞
-
幂等设计
- 所有操作支持重试
- 重复执行不产生副作用
-
优雅降级
- 部分功能故障时，核心功能可用
- 自动切换到备用方案
九、结语：控制是释放的前提
控制平面是 Harness Engineering 的"大脑"，它让成百上千的 AI Agent 能够有序、高效、可靠地工作。
控制不是限制，而是释放。只有建立了强大的控制能力，我们才能放心地释放 AI 的潜力。
这是 Harness Engineering 的管理艺术，也是规模化应用 AI 的必备能力。
参考与延伸阅读
- Kubernetes Control Plane - K8s 控制平面设计
- Distributed Systems Design - Maarten van Steen
- Designing Data-Intensive Applications - Martin Kleppmann
