Hive 生产多智能体工作流

解决什么问题

生产环境中的长时多智能体工作流，一旦超出简单的 demo 范畴，就会暴露出基础架构的硬伤。

• 状态丢失：智能体链拉长后，上下文窗口装不下完整历史，关键信息在中途被遗忘。
• 故障即重跑：某一步失败后整个工作流从头开始，耗时数小时的任务可能因末尾一个小错误全盘重来。
• 黑盒运行：缺少审计日志，出问题时无法回溯是哪个智能体在什么时刻做了什么决定。
• 成本失控：长任务反复调用 LLM，没有预算上限就会在不知不觉中烧掉大量 token。

这个技能针对的就是这几个痛点——它不是让你从零写状态机和恢复逻辑，而是提供一个已经封装好的运行框架，把生产级多智能体真正跑起来。

它如何工作

该技能以 Hive 作为模型无关的运行时，核心能力分四层：

• 状态管理：每个智能体拥有独立的持久化记忆，长任务的中间结果不会被 LLM 上下文长度限制吃掉。
• 失败恢复：工作流在断点处续跑，不需要从头启动；已完成的步骤直接跳过。
• 可观测性：内置审计追踪，每一步决策和工具调用都有日志，方便排查和合规审查。
• 人工监督：高风险动作（如对外发送邮件、写入数据库）可以挂起等待人工审批，确认后才继续执行。

框架本身不绑定特定 LLM 提供商，你只需要配置好对应的凭证即可。如果需要连接外部业务系统，可以通过 MCP 协议挂载工具——比如 CRM、数据库、内部 API，让智能体真正操作生产数据而不是停留在概念验证。

智能体开发要求 Python 3.11+ 配合 uv workspace 设置。Windows 上推荐安装 ripgrep，能让 search_files 工具的文件搜索速度明显提升；没装也不影响功能，只是回退到 Python 实现，稍慢一些。

适用边界与注意

这不是一个拿来就能用的成品，而是一套需要你在此基础上构建智能体的生产框架。几个需要提前想清楚的事：

• 必须配置成本上限：框架要求设定预算限制，但具体阈值需要你根据实际业务的 token 消耗量来定，不设就等于裸奔。
• 人工介入是强制要求：human-in-the-loop 不是可选项，关键步骤的审批节点不能被绕过，如果你需要全自动无监督执行，这个框架不适合。
• 需要生产意识：官方明确提到计划用于正常运行时间、成本和可审计性重要的生产环境——本地跑个 demo 用这套框架属于杀鸡用牛刀，但如果真有生产需求，这些设计正好对症。