从单个AI代理到多代理系统：真实场景部署
开发者最初使用Claude Code自动化生产服务器上的任务。挑战在于，文件和网络操作频繁触发权限请求。虽然--dangerously-skip-permissions标志能暂时绕过问题，但代理仍无法自主修改配置。
通过tmux保持会话、systemd实现自动启动，实现了真正的自主运行。systemd服务文件确保故障后自动重启，并从文件加载上下文信息：
[Unit]
Description=Claude Code Agent
After=network.target
[Service]
Type=simple
User=ubuntu
ExecStart=/usr/local/bin/claude --dangerously-skip-permissions ...
Restart=always
RestartSec=5权限受限的代理成功处理博客任务，同时保持独立运行。
代理协作突破限制瓶颈
部署两个Claude Code实例，解决了确认流程的卡点：一个负责发起动作，另一个通过tmux进行确认。这种方式彻底摆脱了人工审批和API密钥依赖。Claude Max订阅可覆盖使用上限，且不消耗API调用令牌。
与Telegram集成时出现冲突：官方MCP服务器不支持主动推送消息，Telethon则引发轮询问题。解决方案是构建基于tmux的消息总线，利用send-keys命令和直接执行claude {text}指令来发送提示。
消息总线：系统扩展的核心基础
基于Bun + Hono + Redis Streams构建的消息总线，通过消费者组实现至少一次投递。每个代理拥有独立消费组，消息在被确认前持续保留。
安全机制：
- 管理员令牌用于系统控制。
- 每个代理专属操作令牌。
- 邀请令牌有效期1小时，仅限一次性使用。
路由方式：
- 直接发送 — 发往特定代理。
- 广播发送 — 推送至所有代理。
- 角色路由 — 按角色分发。
支持SSE实时更新、基于主题通道的发布/订阅模式，以及通过共享存储传递附件。from字段由令牌自动填充。
借鉴《火影忍者》角色设定分配代理职责
为明确角色并区分于人类操作员，代理以《火影忍者》人物命名：
- 鸣人：协调者，负责任务分配。
- 佐助：Telegram用户账号，监控群组动态。
- 鼬：基于WSL的命令行版Claude Code，处理复杂任务。
- 鹿丸：在Claude Desktop Opus上担任战略顾问。
基础设施代理：
- 卡卡西（Sonnet）：团队负责人。
- 凯：处理快速响应任务。
- 信：质量保障主管。
- 雏田：执行测试。
- 伊比里：安全审计。
- 犬冢+阿夸马鲁：系统监控。
- 米拉：接入外部系统。
- 自来也：日志管理与知识库维护。
集成系统：Yonote、Yandex Tracker、Yandex日历、Bitrix24。
多代理环境中的任务委派训练
初期代理各自为战，忽视委派机制。通过迭代式提示工程逐步培养委派能力：
- 鸣人会在分配任务前检查团队状态。
- 卡卡西将简单任务交由凯处理。
行为模式贴近人类管理逻辑：委派需要显式训练，因为对大模型而言，自行执行始终是最省力的选择。
最终架构与现存局限
系统共包含12个代理，配备网页管理面板，支持日志查看、告警通知、消息检索与提醒功能。整个系统一周内自研完成，共提交67次代码。
尚未实现的功能：电话通信、绕过验证码、视频通话虚拟形象。
核心启示：
- 多代理系统应源于真实问题的解决，自然演进。
- tmux + send-keys方案优于传统MCP协议。
- 代理间相互确认机制可完全消除人工干预。
- Claude Max订阅显著降低API成本。
- 委派能力需持续训练——如同人类管理者一样。
— Editorial Team
暂无评论。