1. 项目背景与核心思路
作为一名长期从事AI自动化开发的工程师，我最近在探索一个有趣的应用场景：如何让AI系统实现自我监督。这个想法的诞生源于日常工作中频繁遇到的痛点——当我们需要同时管理多个AI任务时，人工监督不仅效率低下，还容易遗漏关键节点。
在这个项目中，我设计了一个双AI协作系统：
- 执行AI（Worker Agent）：负责实际的内容创作、网页操作和发布工作
- 监督AI（Supervisor Agent）：负责任务分配、进度跟踪和异常预警
这种架构最大的优势在于职责分离。就像建筑工地上，工头不需要亲自砌砖，但需要确保每个工人按计划施工。通过飞书消息作为通信桥梁，两个AI角色各司其职，形成了完整的任务闭环。
2. 系统架构设计解析
2.1 核心组件交互
系统采用典型的发布-订阅模式：
code复制[Supervisor] --(任务指令)--> [消息队列] --> [Worker]
[Worker] --(状态更新)--> [飞书webhook] --> [Supervisor]
这种设计有三大好处：
- 解耦：监督和执行完全分离，可以独立升级维护
- 可观测性：所有关键节点都有明确的消息记录
- 容错：单点故障不会导致整个系统崩溃
2.2 通信协议设计
消息格式采用结构化JSON：
json复制{
"task_id": "uuidv4",
"type": "status_update",
"payload": {
"stage": "publishing",
"estimate": 15,
"metadata": {
"article_url": "https://example.com"
}
}
}
这种设计比纯文本消息更易于解析和处理，也为后续的监控分析打下了基础。
3. 关键问题与解决方案
3.1 日志监控的局限性
最初尝试通过解析Worker的日志来监控进度，但很快发现了几个致命问题：
- 日志层级错位：系统日志记录的是底层通信事件（如WebSocket连接），而非业务事件
- 信息不完整：关键业务节点可能不会记录到日志中
- 解析困难：日志格式变化会导致监控规则失效
实践建议：业务状态监控应该基于专门设计的API或消息协议，而非依赖系统日志这种副产品。
3.2 主动汇报机制设计
最终采用的解决方案是"任务合约"模式，在给Worker的prompt中明确要求：
code复制当任务开始时，立即发送飞书通知：
"🚀 任务[ID]启动 | 预计耗时[X]分钟"
当遇到阻塞时，发送：
"⚠️ 任务[ID]受阻 | 原因：[Y] | 需要：[Z]"
当任务完成时，发送：
"✅ 任务[ID]完成 | 结果链接：[URL]"
这种设计带来了显著改进：
- 实时性：状态变化立即通知
- 可靠性：信息来自业务逻辑本身
- 可追溯性：完整的任务生命周期记录
4. 提示词工程实践
4.1 避免任务中断的prompt技巧
早期版本曾遇到一个问题：当要求Agent"先预估时间再执行"时，它会把时间预估当作任务终点。这是因为大多数对话系统将单轮响应视为任务完成。
优化后的prompt结构：
code复制你的任务是连续完成以下步骤：
1. 发送启动通知（含时间预估）
2. 执行核心任务
3. 发送完成通知
不要在任何步骤后停止，除非收到明确的终止指令。
4.2 多阶段任务管理
对于复杂任务，采用checkpoint机制：
code复制完成每个阶段后必须发送：
"🔖 阶段完成：[阶段名] | 耗时：[X]m"
收到确认后才继续下一阶段：
"⏭ 继续执行下一阶段"
这种方法既保证了任务连续性，又提供了足够的监督粒度。
5. 运维与监控实践
5.1 命令验证流程
所有关键操作必须经过验证阶段：
bash复制# 测试消息通道
openclaw message send --channel feishu --test
# 发布流程试运行
openclaw publish --dry-run --url "https://example.com"
5.2 进程守护方案
推荐使用systemd管理守护进程：
ini复制# /etc/systemd/system/ai-supervisor.service
[Unit]
Description=AI Supervisor Daemon
[Service]
ExecStart=/usr/bin/python3 /opt/ai/supervisor.py
Restart=always
User=aiuser
[Install]
WantedBy=multi-user.target
管理命令：
bash复制sudo systemctl enable ai-supervisor
sudo systemctl start ai-supervisor
journalctl -u ai-supervisor -f # 查看日志
6. 性能优化经验
6.1 消息去重机制
为避免消息风暴，实现了几种过滤策略：
- 时间窗口去重：30秒内相同内容只发一次
- 状态变化检测：只有状态真正改变时才通知
- 重要度分级：普通更新聚合发送，关键更新立即发送
6.2 异步处理模式
将耗时操作异步化：
python复制async def handle_task(task):
await asyncio.gather(
execute_workflow(task),
send_notification(task)
)
这种模式可以显著提高系统吞吐量。
7. 安全最佳实践
7.1 权限控制方案
实施最小权限原则：
- Worker：只能访问特定网站和API
- Supervisor：只能发送特定格式的消息
- 通信通道：使用TLS加密+签名验证
7.2 审计日志设计
记录完整的操作轨迹：
sql复制CREATE TABLE audit_log (
id BIGSERIAL PRIMARY KEY,
timestamp TIMESTAMPTZ NOT NULL,
actor TEXT NOT NULL,
action TEXT NOT NULL,
target TEXT,
metadata JSONB
);
8. 异常处理机制
8.1 超时管理
每个任务设置三级超时：
- 启动超时（1分钟）：未收到启动通知
- 进度超时（预估时间×1.5）：未收到进度更新
- 完成超时（预估时间×2）：未收到完成通知
8.2 自动恢复流程
设计状态机实现自动恢复：
code复制[超时] -> [重试3次] -> [仍失败] -> [通知人工介入]
9. 监控指标体系
建议监控这些关键指标：
- 任务成功率 = 成功数 / (成功数 + 失败数)
- 平均延迟 = 总耗时 / 任务数
- 通知及时率 = 按时通知数 / 应通知总数
使用Prometheus+Granafa构建监控看板：
yaml复制# prometheus.yml
scrape_configs:
- job_name: 'ai_supervisor'
static_configs:
- targets: ['localhost:9091']
10. 扩展与演进
这套系统后续可以扩展为：
- 多Worker负载均衡
- 基于优先级的任务调度
- 自动扩缩容机制
- 跨平台适配（支持企业微信、钉钉等）
在实际部署中，这套架构已经稳定运行了6个月，平均任务完成率达到98.7%，比人工监督时期提升了40%的效率。最关键的是，它释放了开发者持续监控的负担，让我们可以专注于更重要的业务逻辑开发。