人工智能AI Agent多智能体MCP 服务工具调用浏览器控制【免费下载链接】hiveMulti-Agent Harness for Production AI项目地址https://gitcode.com/gh_mirrors/hive48/hive点击查看免费下载导读在 Hive 的 Colony蜂群模型中Worker Agent 是 Queen 以单个工具调用批量派生的一次性执行克隆体——与 Queen 共享同一个 AgentLoop 原语、同一套工具与模型却刻意被裁剪掉记忆、个性、升级通道与委派能力。本文以 docs/key_concepts/worker_agent.md 为骨架结合worker_definition.py、colony_runtime.py、run_worker工具及其单元测试的源码实现完整拆解 Worker 的定义、预算配置、系统提示词契约、report_to_parent回报链路、tracker 结果共享机制与 headless 运行方式帮助你理解如何像管理团队一样运行 Agent这一 Hive 核心命题并为自行编写或调试 Colony 应用提供可直接落地的参数与调用参考。一、Worker 是什么Queen 的一次性克隆体在 Hive 中worker是 Queen 在 colony 内部派生、用于完成一个工作单元的单一 Agent。它是 Colony 实现并行的方式当 Queen 有 50 个潜在客户需要调研时她不会逐个处理而是把任务扇出给多个 worker每个 worker 各领一份。最关键的一点是worker 并不是与 Queen 不同的程序。它是 agent loop 的克隆——同一套工具、同一个模型——只是预算更紧并注入了一个明确的任务。正如 docs/architecture/README.md 中引用core/framework/host/colony_runtime.py的注释所言Each worker is an exact copy of the queens AgentLoop — same tools, same prompt, same LLM… The ColonyRuntime replaces both AgentHost and ExecutionManager. There are no graphs, no edges, no nodes, no data buffers. Just: spawn N independent clones, let them run, collect results.因此一个 worker 之所以是 worker取决于它刻意缺少什么而不是它多拥有什么。1.1 Worker 的五项核心特征特征含义源码佐证Focused聚焦只领一个任务严格保持在职责范围内发现范围外的工作只在报告中一句话提及绝不追查WORKER_SYSTEM_PROMPT 规则 4/5/6Stay strictly within your assigned scopeEphemeral短暂没有先前运行的记忆没有 persona每次全新开始干完即终止worker_definition.py的worker_goal描述 No memory of prior runs, no reflectionNo escalation无升级通道没有实时观众运行中途无法向 Queen 或用户提问因此永远不会阻塞等待答案规则 2You have no live audience and no escalation channelCant delegate不能委派worker 不能派生自己的 worker扇出权只属于 Queen嵌套被阻止规则 1You cannot spawn workers or delegate — do the work yourselfFail-fast快速失败工具调用失败时先分类错误瞬时 → 重试一次结构性 → 修复后重试一次不可修复 → 停止不陷入 workaround 死循环错误分类协议见下文 4.31.2 Queen 与 Worker同一个循环不同的预算Worker 与 Queen 共享LoopConfig机制见 core/framework/agent_loop/internals/types.py差异完全由配置体现维度QueenWorker 克隆角色持久、面向客户端的负责人短暂、单任务执行体迭代次数近乎无上限默认 999_9993 个工作迭代 1 个 grace 迭代工具预算宽松budget 30 × hard_multiple 5 150紧凑30 × 3 90 硬停另有 lifetime 上限升级通道可升级到人类Sentinel无——fail-fast 并报告记忆有范围、可演进Queen Memory v2无每次全新开始Persona13 个 YAML 角色之一无identity_prompt、memory_prompt二、Worker 的运行时预算DEFAULT_LOOP_CONFIG 逐字段拆解Worker 的全部预算旋钮定义在 core/framework/agents/queen/worker_definition.py 的DEFAULT_LOOP_CONFIG中被注释明确标注为 worker 工具调用画像的single source of truth单一事实来源DEFAULT_LOOP_CONFIG: dict[str, int] { max_iterations: 3, # 3 个工作迭代 grace_iterations: 1, # 1 个兜底收尾迭代 tool_call_budget: 30, # 单轮工具调用软检查点 tool_call_hard_multiple: 3, # 硬停倍数30 × 3 90 tool_call_lifetime_budget: 200, # 整个生命周期累计工具调用上限 max_context_tokens: 180_000, # 上下文窗口 }colony_runtime._build_worker_loop_configcore/framework/host/colony_runtime.py在每次 spawn 时直接从该常量读取保证实时派生路径与定义不漂移。各字段在LoopConfig层面的语义如下2.1 max_iterations 与 grace_iterations预算内的迭代节奏max_iterations 3worker 有 3 个工作迭代reason → act → observe → judge 的完整回合。每个迭代内部可能包含多个模型↔工具的内层往返。grace_iterations 1这是 worker 独有的兜底旋钮Queen 默认为 0因为她不调用report_to_parent。当 worker 耗尽max_iterations后框架额外授予一个收尾迭代期间工具分派被限制在终结工具白名单{report_to_parent, tracker_upsert, task_update}并在首个 grace 迭代开始时注入一条system-reminder解释该限制。没有 grace 迭代一个耗尽了预算的 worker 会静默死亡——不产生任何SUBAGENT_REPORT有了它Queen 永远能收到回音。这是worker 永不无声消失这一契约的机制保证。2.2 tool_call_budget 与 tool_call_hard_multiple软检查点与硬停止tool_call_budget 30单次 turn-loop 内工具调用计数的软检查点。每达到一个 budget 倍数框架注入一条升级式软提醒重新评估一下但从不强制停止。tool_call_hard_multiple 3运行计数一旦超过budget × multiple即 90 次turn-loop 硬停止并延后任何剩余工具调用。Queen 默认是 530 × 5 150worker 收紧为 3tool_call_hard_multiple不在 Queen 的按批覆盖白名单内框架锁定不可调见colony_runtime.py注释。2.3 tool_call_lifetime_budget跨轮次的累计上限与每轮重置的tool_call_budget不同tool_call_lifetime_budget是整个 worker 生命周期、跨所有轮次的累计工具调用上限types.py第 122-131 行。默认 200 对正常 worker 而言几乎不会触发它通常在自己寥寥几个工作轮次内就完成了但若 Queen 把某个 worker 的max_iterations调得很高该 worker 也无法无限扇出工具调用——一旦累计达到 200 次执行循环会提前进入 grace 收尾注入停止提醒、分派收窄到终结白名单、执行 grace 收尾轮次后退出。2.4 覆盖机制Queen 按批调整的旋钮Queen 可以在每次run_worker调用时按批覆盖部分旋钮colony_runtime.py的覆盖白名单允许覆盖max_iterations、grace_iterations、tool_call_budget、tool_call_lifetime_budget、max_context_tokens覆盖值必须是整数且落在各自边界内如grace_iterations范围(0, 3)tool_call_hard_multiple不在白名单中始终保持框架锁定的紧凑 3x。三、Worker 的身份文件worker.json 与无 persona 设计3.1 worker.json 序列化在 Colony fork 时routes_execution.fork_session_into_colony见 core/framework/server/routes_execution.pybuild_metaworker_definition.py把 worker 的运行时身份序列化为磁盘上的worker.jsonagent_loader读取它来 spawn worker AgentLoop。build_meta的注释点明磁盘格式即运行时身份——identity_prompt与memory_prompt按构造为空identity_prompt: , # 不是 Queen 的 persona memory_prompt: , # 无记忆 goal: {description: task or Continue the work from the queens current session., success_criteria: [], constraints: []}, tools: list(tool_names), loop_config: build_loop_config_dict(queen_loop_config), spawned_from: source_session_id,build_loop_config_dict会蒸馏 Queen 的LoopConfig到 worker 兼容字典但刻意不复制tool_call_hard_multipleworker 保持 3x 硬停且保留 worker 自身的grace_iterations默认值Queen 没有 grace 概念该值由 worker 侧定义。3.2 系统提示词模板build_system_prompt(task)将任务字符串追加到WORKER_SYSTEM_PROMPT之后生成 worker 的 system prompt。注意头部的关键设计身份无关——worker 不继承 Queen 的 personaidentity_prompt为空否则它会以第一人称与用户打招呼而它对所分配的工作一无所知。四、Worker 的行为契约WORKER_SYSTEM_PROMPTWORKER_SYSTEM_PROMPTworker_definition.py定义了 worker 的 9 条不可谈判规则是理解 worker 行为的第一手资料用你自己的工具直接执行分配的任务——不能派生 worker 或委派不要对话、提问或建议下一步——你没有实时观众运行中 Queen 和用户都无法回答你不要加编辑性评论或元评论——捕捉上下文剪裁后仍需的价值属于工作记忆是允许的流水账评论不允许严格停留在分配范围内——不要顺手修一下或顺手查一下邻近的东西发现范围外的重要工作在报告中用一句话提及不要追查——其他 worker 覆盖那些区域范围有歧义时取最窄的合理解读并在报告中说明你选了哪个解读——扩大范围正是并行 worker 互相碰撞的原因若 Queen 附带了 skillskill 是操作真理任务字符串只是该 worker 的参数在上下文被剪裁前保存值——工具结果里的 URL、ID、文件路径、具体数值要立即通过tracker_upsert或引用进下一条助手消息捕获通过report_to_parent只报告一次然后停止——报告后循环即结束不要调用其他工具总结开头先用一句话说明你负责的范围。此外提示词还包含输出效率指导最简方案优先、避免绕圈子、以行动/结果开头而非推理以及起草对外消息的写作风格要求面向人类收件人的消息正文需读起来像人写的如不用破折号、长短句交错、以具体观察开头等。4.1 任务分解与进度追踪WORKER_SYSTEM_PROMPT要求 worker 对每个多步骤任务使用任务工具task_create/task_update/task_list/task_get把任务分解为原子步骤并追踪进度。关键说明Queen不会轮询worker 的任务列表——它用于 worker 自己的纪律和在上下文剪裁中存活列表持久化而旧的工具结果不会。标准节奏是task_update(statusin_progress)→ 执行 →task_update(statuscompleted)。4.2 共享状态优先使用 tracker如果 Colony 有 trackertracker.db以工具集中存在 tracker 写工具为信号worker 被要求优先用tracker_upsert记录结构化发现——Queen 直接读行并通过 SQL 验证进度。不要在散文式总结里重复 tracker 状态说清楚你做了什么行就是数据。worker 只能写本 Colony 的tracker超出本 Colony 的共享存储需求记录在案并上报由 Queen 处理。4.3 Fail-fast 错误分类协议这是 worker 与普通 Agent 最本质的差异——没有升级通道因此失败处理必须预先定义好错误类别判定处置Transient瞬时网络抖动、限流、短暂超时重试一次仍失败则按结构性处理Structural and fixable结构性可修复选择器错误、输入格式错误、缺参数修复输入后重试一次Structural and unfixable结构性不可修复权限拒绝、资源消失、无法修复的 schema 不匹配不重试跳到下一项或报告失败无法完成任务时先持久化值得保留的部分状态已填的行、已收集的证据、尝试过什么、为何失败——全部通过tracker_upsert然后调用report_to_parent(statusfailed, summary一段原因, data可选结构化细节)并停止。绝不静默丢弃失败项——tracker 行 失败报告让 Queen 能精确重新派发或亲自接管。同时明确不要超过 2-3 次尝试去绕 workaround干净地浮出失败。五、回报链路report_to_parent 与 [WORKER_REPORT]5.1 工具签名worker 的终结动作是report_to_parent(status, summary, data)其 Tool 定义构建于 core/framework/agent_loop/internals/synthetic_tools.py 的build_report_to_parent_toolstatus枚举[success, partial, failed]success— 任务完成结果在 summary/data 中partial— 取得了一些进展但未能完成在 summary 中解释failed— 未能取得有意义的进展。summary给 Queen 的一段叙述——你做了什么、发现了什么、有无值得注意的问题必填。data可选的结构化负载抓取的行数、处理的 ID、写出的文件等Queen 可合并进最终总结。当传入report_schema时data参数就是该 schema而非通用自由对象要求必填字段齐全、枚举值精确以便解码时引导模型产出符合预期形状的回执。handle_report_to_parent同文件第 443-469 行负责规范化status 非白名单值回落到success空 summary 生成占位文案data 非 dict 时包装为{value: data}随后返回给模型可见的确认文本Report delivered to overseer (status…). This worker will terminate now.而真正的副作用记录到 Worker、发出SUBAGENT_REPORT、终止循环由AgentLoop在辅助函数返回后执行。5.2 回报如何回到 Queen 的对话worker 的报告经由事件总线以SUBAGENT_REPORT事件core/framework/host/event_bus.py送达Queen 在自己的对话中将其视为一条[WORKER_REPORT]用户轮次——包含状态、一段总结、可选的结构化负载。event_bus.py第 551-554 行注释指出关键保证SUBAGENT_REPORT fires exactly once per worker (synthesized if the worker never reported, and still emitted on crash/cancel)即每个 worker 恰好发出一次报告——即使 worker 从未主动报告超时、崩溃、取消框架也会合成一条报告从而保证 Queen 永远不会漏掉任何一个 worker 的去向。worker 循环在报告后即结束。5.3 测试验证core/tests/test_run_worker_tool.py 的test_run_worker_tool_returns_immediately_and_emits_reports精确验证了这条链路3 个任务fetch-A/B/Cspawn 3 个 worker工具立即返回statusstarted、worker_count3、无聚合报告fire-and-forget 语义随后事件总线上异步到达 3 条SUBAGENT_REPORT状态恰为[failed, success, success]每个 worker 的落地目录位于{storage}/workers/{worker_id}/。六、结果共享tracker 与任务列表worker 之间互相看不见、也不能互发消息它们的协调完全通过 Colony 的共享基质6.1 tracker.dbColony 的共享账本每个 Colony 有唯一一个tracker.dbSQLite位于~/.hive/colonies/{name}/data/core/framework/host/tracker_db.pyQueen通过execute_sql含 denylist 的完整 SQL设计 schema并通过tracker_register_writable声明 worker 允许写入的列Worker通过更窄的tracker_upsert工具填行——一行一个工作单元而不是散文Queen通过tracker_query只读 SELECT用 SQL 验证进度——完成了什么、还剩什么永远是一次新鲜查询而不是可能因崩溃丢失的内存态。引导 schema 中的_tracker_registry表是tracker_upsert的门控没有在该表中注册的表对 worker 不可见防御纵深tracker_db.py第 684 行附近注释确认 worker 的tracker_upsert独立拒绝未注册表。工程细节还包括开箱即用的 WAL 模式、每次调用新建连接、任何多语句变更脚本使用BEGIN IMMEDIATE。6.2 ColonyBinding不可变的绑定每个 Colony 的 tracker 由一个不可变的ColonyBinding {name, dir, tracker_db}core/framework/host/colony_binding.py限定作用域。该绑定贯穿 Queen 的工具执行上下文并通过input_databuild_input_data见 worker_definition.py注入到每个 worker 的第一条用户消息使双方始终解析到同一个数据库。没有绑定的工具会拒绝运行而不是猜测路径——这正是防止两个 Colony或一个 Colony 与一个游离会话写错账本的关键。6.3 worker 自己的任务列表worker 可以把任务分解为步骤并用task_create/task_update追踪这在上下文剪裁时保护工作记忆列表持久化在磁盘上旧工具结果不会。注意tracker 持有结果结构化行任务列表持有意图worker 打算做什么——两者职责不同不要互相镜像。七、如何派生 workerrun_worker 实战7.1 工具签名与参数Queen 通过run_worker工具core/framework/tools/queen_lifecycle_tools.py批量派生 worker该工具立即返回、不阻塞 Queenrun_worker( tasks[{task: ..., data: {...}}, ...], # spawn 模式任务列表 timeout600, # 软截止秒 max_iterationsNone, # 可选覆盖迭代上限 tool_call_lifetime_budgetNone, # 可选覆盖生命周期预算 resume_worker_idsNone, # resume 模式恢复指定 worker guidanceNone, # 恢复时注入一条引导消息 )参数类型说明taskslist[dict]spawn 模式必填每个元素{task: str, data: dict \| None}timeoutfloat软截止默认 600s到期时每个仍在运行的 worker 收到 SOFT TIMEOUT 注入要求立即report_to_parentmax_iterationsint \| None覆盖迭代上限接近上限被停的 worker 恢复时需要余量tool_call_lifetime_budgetint \| None覆盖生命周期工具调用预算resume_worker_idslist[str]resume 模式必填与tasks互斥guidancestr \| None恢复时注入到每个被恢复 worker 的一条引导消息7.2 Fire-and-forget返回即开始调用后工具返回类似如下的 JSON 负载测试断言确认{ status: started, worker_count: 3, worker_ids: [...], soft_timeout_seconds: 30.0, hard_timeout_seconds: 630.0, message: … [WORKER_REPORT] … }注意没有聚合报告——worker 在后台运行报告通过SUBAGENT_REPORT事件异步回家Queen 保持不阻塞可以继续与用户对话或派发更多工作。7.3 超时软超时 硬截止软截止timeout默认 600s到期时每个仍活跃且未显式报告的 worker 被注入一条 SOFT TIMEOUT 提醒要求现在就用部分结果调用 report_to_parent硬截止由软超时推导max(timeout × 4, timeout 600)封顶 3600s——该推导式对 Agent 不可调。忽略软提醒的 worker 会被强制停止恢复被强制停止或超时的 worker 可从其保存的对话恢复resume_worker_ids可选guidance从离开的位置继续。7.4 并发调度有计划的并行而非手动管理Colony 一次性接收全部 N 个任务最多max_concurrent_workers默认 4可通过环境变量HIVE_MAX_CONCURRENT_WORKERS覆盖见 colony_runtime.py同时运行其余排队随着对等 worker 终止逐个启动。Queen 通过立即返回中的running_now/queued以及每条[WORKER_REPORT]上的batch_remaining同时统计排队与运行中看到批次拆分。并发上限在 Colony 调度器内部强制而非在工具层。此外Colony 还带自适应工具预算HIVE_ADAPTIVE_TOOL_BUDGET默认开启成功 worker 的实际消耗定义 Colony 的常态名义 lifetime 预算向成功消耗收敛让大概率失败的 worker 提前通过预算-grace 机制收尾而不是烧满固定上限colony_runtime.py第 151-180 行。7.5 安全保障工具裁剪与凭据预检run_worker在 spawn 前会剥离 Queen 生命周期工具run_worker、switch_to_*防止派生出的 worker 递归调用run_worker或翻转父 Queen 的阶段严格界定工具范围worker 只能看到派生它的 Queen 当前阶段拥有的工具防止 Queen 委派自己不拥有的能力凭据预检与单 Agent 路径一致缺失的凭据如过期的GITHUB_TOKEN在 spawn 前一次性捕获并过滤出工具列表而不是让 N 个 worker 各自失败产生 N 份重复错误报告。八、会话、headless 执行与恢复8.1 会话Session一个会话是 Agent 针对特定输入的一次运行。会话相互隔离——各自拥有独立的状态与历史——并且崩溃安全状态持久化到磁盘因此进程崩溃、部署或重启都能精确恢复到离开的位置而不是从头再来。这得益于单一AgentLoop原语内置的 park/resume 机制docs/architecture/README.md循环把游标持久化到磁盘需要等待某事物时ASK_USER、CREDENTIAL_FORM、AWAITING_QUEEN等就 park磁盘是事实来源。8.2 Headless无人值守 ≠ 无人监督大量 Colony 工作以headless方式运行——没有 UI、没有终端前的人类——全天候监控收件箱、处理线索、监视事件。headless 不等于无人监督当 Colony 遇到应由人类决策的问题时Queen 通过 Sentinel绑定账户的Slack / Telegram渠道带外升级循环park状态持久化到磁盘人类回复后答案被注入、循环从磁盘精确恢复。原则是自动化常规升级异常。一个 Colony 可以暂停几分钟、几小时甚至几天而不丢失位置。九、全景worker 模型在 Colony 中的位置Worker 模型是 Hive 对如何像管理团队一样运行 Agent的答案Queen 是领队——接需求、自己先做第一单pilot、然后把边界清晰的任务分发给所需数量的 worker——每个 worker 各尽其责、把结果写进共享账本、然后让位。整个生命周期遵循先执行、后系统化execute-first-then-systematizeQueen 先自己端到端完成一个工作单元并在 tracker 记录结果路径验证后把已验证的协议沉淀为可复用的skill playbook再用run_playbook跨 worker 克隆收敛批次见 docs/architecture/README.md。因为 tracker 永远知道什么做完了、什么还没做重跑 playbook 天然就是从上次停下的地方继续。当流程需要改进时你不必逐行调试 worker——Colony 通过 reflexion、记忆与系统化 整体进化。因为 Queen 与 worker 是同一个原语所有可靠性特性崩溃安全恢复、上下文压缩、成本计量、停滞检测、judge 门控终止都只构建一次Colony 中的每个 Agent 自动继承。进一步阅读The Colony — worker 所属的整体The Queen — 派生并协调 worker 的角色The Loop — worker 所克隆的原语Coordination — tracker、任务计划与事件总线Architecture Overview — 完整代码级参考赞分享人工智能AI Agent多智能体MCP 服务工具调用浏览器控制【免费下载链接】hiveMulti-Agent Harness for Production AI项目地址https://gitcode.com/gh_mirrors/hive48/hive点击查看免费下载相关推荐Hive Worker并行实战run_worker工具如何大规模扇出任务并收敛结果Hive Worker并行实战run_worker工具如何大规模扇出任务并收敛结果 Hive 是一个面向生产环境的 多智能体框架 Multi Agent H人工智能AI Agent多智能体MCP 服务工具调用浏览器控制LiteFlow并行执行多组件并行处理与结果聚合LiteFlow并行执行多组件并行处理与结果聚合 概述 在现代分布式系统和高并发场景中串行处理往往成为性能瓶颈。LiteFlow作为一款强大的国产规则引擎框后端流程编排工作流自动化人工智能AI AgentRedux-Saga并发模式并行任务执行与结果聚合策略Redux Saga并发模式并行任务执行与结果聚合策略 你是否在处理复杂异步逻辑时遇到过以下困境多个API请求串行执行导致页面加载缓慢重复点击按钮触发冗余前端上一篇猫抓插件终极教程如何轻松下载网页视频和音频资源下一篇浏览器视频资源智能捕获工具猫抓扩展深度解析与实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
