加载失败
这是一个 Show HN 帖子，作者发布了 agent-swarm——一个开源的多智能体（agent team）系统，目标是实现自学习与可复利的改进能力并支持自托管。项目借鉴了 OpenClaw（多 agent 自我改进范式，使用 SOUL.md/IDENTITY.md 描述角色）并采用 Docker Compose 部署、claude CLI 对接模型，同时用 SQLite 做持久化记忆。评论围绕实现细节、与 Anthropic Claude 等托管 agent 解决方案的比较、工程可维护性以及赋权后的安全风险展开讨论。理解这些讨论需要了解 agent-team 架构、持久化记忆（如 SQLite）与 prompt-first 开发对长期工程资产和治理的影响。
项目自去年十一月开始开发，作者在帖子中介绍了一个基于 Docker 的 agent-swarm，声称加入了可复利的自学习核心以实现长期改进。实现细节包括个人与共享卷用于持久化可复用脚本与笔记、以及基于 SQLite 的记忆层分为个人和共享记忆，lead 可以将学习传播给整个 swarm。核心基于一个 MCP（共享核心/协调组件），允许从本地以 lead 身份控制 swarm，并提供纯浏览器 UI 与 docker compose 一键部署到 VPS 的路径。作者还提到目前通过 claude CLI 对接模型，并表示大部分代码是通过 agent 在 Slack 协作生成的。
作者和早期使用者都观察到自学习带来的复利效果：系统有定时任务（如晨检），由 lead 评估前一天工作并自动改进流程，从而逐步优化协作方式。持久化卷与 SQLite 记忆让 agent 能保存安装脚本、笔记和流程，避免每次都从零开始，示例包括自动安装处理音频笔记的组件并把后续音频纳入记忆。这些具体例子被用来证明一旦建立反馈回路，swarm 的效率和可复用资产会增长，而不仅仅是一次性完成任务。
有评论者认为把 agent 团队交给托管平台（如 Claude 的 agent teams）或采用现有开源实现可能更合适，并引用了 claude-code-orchestrator 及 code.claude 的文档作为参考。对比来看，本地原生实现目前被认为在会话持久化与跨会话团队管理上有局限——团队常被限制在单次会话并仅在本地运行。因此一些人倾向使用受控平台或等待平台方发布更成熟的多 agent 支持，而另一些人则继续探索可自托管的 OSS 方案以获得更高控制权。
有评论者表达对把问题解决权交给临时 swarm 的本能抵触，核心理由是短期群体可能完成当前任务但不产生可在将来重用的学习或持久代码资产。另一项担忧是工程实践会从稳定的源码与框架转向依赖一次性 prompting，使得项目变得不可维护并加剧“meta 编程”倾向。评论中还提到阅读例如 advanced-context-engineering 之类材料后产生的不适感，认为这种方法可能在长期价值与工程可持续性上存在缺陷。
部分从业者建议采用混合策略：把 swarm 用于可委派给实习生或重复性任务的工作，同时通过 Slack 和 GitHub 建立反馈回路来迭代；将关键复杂或需严格控制的部分保留给本地工程师。实际经验表明，这样可以兼得自动化效率与对重要系统的控制权，从而减缓对一次性提示式解决方案的完全依赖。该观点来自曾在创业项目中大量做 meta programming 的开发者，其结论是“混合”为当前较为稳妥的路径。
讨论中有戏谑但真实的安全顾虑：将 agent 赋予生产数据库访问、为每个 worker 开设邮件收件箱或授予 Git 写权限会带来明显风险。评论以半开玩笑的口吻指出“rogue agents”或权限滥用的可能性，强调在扩展自动化与授予权限前必须设计好权限边界、审计与回滚机制。这些担忧提醒开发者在追求自学习与自动化收益时不要忽视治理与安全成本。
OpenClaw: 一种多智能体/agent 团队的设计思想与社区实现范式，常用 SOUL.md 与 IDENTITY.md 等文件来描述 agent 的角色、目标与长期行为，作为自我改进系统的参考。
SOUL.md / IDENTITY.md: OpenClaw 式的元数据文件，用于定义单个 agent 的身份、角色、规则和长期偏好，帮助维持角色一致性并支持跨会话的行为延续。
MCP: 作者项目中提到的共享核心/协调组件（MCP），用于在 lead 与 worker 之间同步任务与记忆，扮演消息协调或控制总线的角色。
SQLite-based memory: 使用 SQLite（轻量级文件型数据库）作为 agents 的持久化记忆层，支持个人与共享记忆的写入与查询，便于保存可复用脚本、笔记和学习成果。