企业官网建设流程全解析

• 人工智能
• AI Agent
• 多智能体
• MCP 服务
• 工具调用
• 浏览器控制

导读：Hive 的 Colony（蜂群）不是一次性编排的静态流程图，而是会随运行不断变好的生产系统。本文基于 How a Colony Improves 的核心脉络，系统拆解 Hive 改进一个 Colony 的四种带内（in-band）机制——会话内的 Reflexion 自纠错、跨会话的作用域记忆、工具门控的技能学习，以及把试点固化为可重跑 Playbook 的系统化——并结合 judge_pipeline.py、reflection_agent.py、tool_gating.py 与 playbook/runner.py 等源码给出底层原理。读完后你将理解 Hive 在“不手改工作流、不重训模型”的前提下，如何让一个 Colony 在反复运行中变得更可靠、更可复用。

改进的前提：Agent 会失败，流程会过时

真实世界中的变量——一个私密资料页、一次上游 API 的 schema 变更、一次模型幻觉——无法在真空里被预判。任何流程的第一个版本都只是“happy path 草稿”。因此，一个 Colony 的价值不在于首次运行是否顺利，而在于它能否随运行持续变好。

Hive 通过四种带内（in-band）机制实现改进——它们全部属于运行中的系统本身，无需手工编辑工作流，也无需重训模型。其中两种作用于单个会话内部（within a session），两种把改进跨越会话（across sessions）沉淀下来：

术语澄清：Hive 早期版本曾把改进描述为“进化（evolution）”——即由一个编码 Agent 在代际之间重写 Agent 的 graph。今天 Hive没有 graph，也没有跨代代码重写，改进只通过上述四种机制发生。这一点在 improvement.md 中以 Note 形式明确说明。

会话内改进：Reflexion 自纠错

法官裁决：Accept / Retry / Escalate

Hive 只有一个执行原语——Agent Loop。每一轮 turn 结束后，法官（judge）会对本轮的产出做评估，给出三种裁决：

• Accept：达标，继续推进；
• Retry：还差一些，但可恢复——法官的反馈会被作为一条消息注入回对话，下一轮 Agent 会同时看到自己上一次的尝试和批评意见，据此调整；
• Escalate：根本性卡住，交给上层（Queen 或通过 Sentinel 交给人类）。

这就是reflexion pattern（反思模式）：尝试 → 评估 → 从结果中学习 → 再尝试，完全在上下文内完成，不需要重训模型。一个花三次尝试才能做对的 Agent，远比一个失败一次就放弃的 Agent 有用得多。

源码证据：judge_pipeline 的三级评估

在 core/framework/agent_loop/internals/judge_pipeline.py 中，judge_turn明确实现了分级评估（docstring 中标注了 Evaluation levels）：

• Level 0 短路：mark_complete直接 Accept；skip_judge跳过评估；
• Level 1 自定义法官：当配置了实现JudgeProtocol的自定义 judge 时，它拥有完全裁决权——context中会携带assistant_text、tool_calls、output_accumulator、iteration、conversation_summary、missing_keys等信息，由judge.evaluate(context)返回JudgeVerdict；
• Level 2 隐式法官：无自定义 judge 时，先做输出键检查——若missing_keys非空则 Retry，并把缺失项写进反馈（例如"Task incomplete. Required outputs not yet produced: ..."）；输出键齐全后，若配置了success_criteria，还会进入基于 LLM 的对话感知质量门（evaluate_phase_completion）做二次把关。

同文件中的SubagentJudge还展示了一个带紧迫度语气的 Retry 反馈构造方式：剩余迭代不足时，反馈会升级为URGENT: Only N iterations left. Stop all other work and call set_output NOW for: ...。这说明Retry 不是简单重放，而是把“还缺什么、还剩几次机会”精确地塞回上下文，让下一次尝试有的放矢。

与成功标准的关系

Retry 反馈的质量直接取决于目标定义。在 Goals & Outcome-Driven Development 中，Goal是结构化对象：带权重的SuccessCriterion（llm_judge、output_contains、output_equals、custom等 metric）、硬/软Constraint以及注入每次 LLM 调用的Context。当 Agent 某轮产出不达标时，法官知道具体是哪条标准没满足——这个精确信号正是会话内自纠错（judge 注入的反馈）、跨会话记忆（Queen 反思写入的笔记）和 tracker 中 worker 结果的一致驱动力。因此可以说：好的改进起点，是定义好的成功标准。

跨会话改进一：作用域化的演进记忆

Queen 的反思式记忆

当 Queen 工作时，一个**带冷却门控的反思步骤（cooldown-gated reflection）会把持久化的笔记写入作用域化的 Markdown 记忆——按global（全局）、colony（蜂群）、queen（女王）三个作用域划分。之后的会话中，一个召回选择器（recall selector）**会把相关的旧笔记重新呈现在上下文中。久而久之，Queen 积累了关于你、你的业务以及“以前什么有效”的真实上下文，并把它带入新的工作。

这是**“靠记住来改进（improvement by remembering）”，而不是靠重写代码。需要强调的是：这不是向量数据库，就是结构化文件**——Queen 反思写入、再读回。

源码证据：reflection_agent 的实现细节

core/framework/agents/queen/reflection_agent.py 是这一机制的核心实现，其 docstring 说明了完整设计：

• 两种反思类型：**短反思（short reflection）**在 Queen 每轮对话后运行，把可沉淀的知识提炼进 global 或 queen 作用域的记忆文件；长反思（long reflection）每 5 次短反思触发一次，并且在发生上下文压缩（CONTEXT_COMPACTED）时也会触发，负责对一个记忆目录做整理、去重、裁剪。
• 并发与阻塞：通过asyncio.Lock防止重叠运行；如果触发事件发生时已有反思在跑，该事件被跳过。
• 非阻塞性：所有反思都是 fire-and-forget（经asyncio.create_task派生），绝不阻塞 Queen 的事件循环。
• 门控参数：_SHORT_REFLECT_TURN_INTERVAL = 3（每 3 轮 turn 才考虑短反思）、_SHORT_REFLECT_COOLDOWN_SEC = 300.0（两次短反思之间至少间隔 300 秒）、_LONG_REFLECT_INTERVAL = 5（每 5 次短反思触发一次长反思）——这些常量在 reflection_agent.py 中定义。
• 触发时机：通过事件总线订阅LLM_TURN_COMPLETE和CONTEXT_COMPACTED事件（subscribe_reflection_triggers），只在stream_id == "queen"时生效，并且工具轮次（tool turn）默认被跳过以避免干扰工作流。
• 记忆文件约束：每个文件有大小上限（MAX_FILE_SIZE_BYTES）和数量上限（MAX_FILES），文件名必须是*.md，且不允许路径穿越（_safe_memory_path会校验文件名不包含/、\或..）。
• 作用域语义：从系统提示词可见——global存放“对所有 Queen 都有用的持久用户事实”，queen存放“该 Queen 应如何为此用户推理、排序、沟通和权衡的稳定领域知识”；两者重复时应合并去重。用户画像统一写入global:user-profile.md（保留由设置 UI 管理的## User Identity段）。
• 关闭时兜底：run_shutdown_reflection在会话 teardown 时执行最后一次短反思，确保会话销毁前最近的对话洞察也被持久化。

worker 与 Queen 不同，是无记忆的——每次运行都从空白开始，这正是 The Worker Agent 所强调的“专注、临时、快速失败”设计的一部分。

跨会话改进二：学习型、工具门控的技能

从做事方式到可复用协议

当 Queen 验证了一种做事方式（way of doing something），它可以固化为一个skill（技能）——一个并入 Queen 基线的可复用协议。技能是**工具门控（tool-gated）**的：只有当技能所需工具实际存在时，技能才会激活。这样 Queen 永远不会试图执行一个自己并未配备相应工具的协议。学会的技能意味着：下一次类似任务出现时，Colony 已经知道该怎么做了。

源码证据：tool_gating 的前置激活映射

core/framework/skills/tool_gating.py 展示了默认技能的工具门控实现——按工具名前缀映射到默认技能，当 Agent 可用工具集中出现匹配前缀的工具时，就把对应技能的完整正文注入系统提示词：

_TOOL_GATED_SKILLS: list[tuple[str, str, str]] = [ ("browser_", "browser-automation", "hive.browser-automation"), ("terminal_", "terminal-tools-foundations", "hive.terminal-tools-foundations"), ("chart_", "chart-creation-foundations", "hive.chart-creation-foundations"), ]

其设计动机是“绕过渐进式披露”：对某个工具族而言基础性的技能（如hive.browser-automation），Agent 不应等到第一次选择器调用出错后才反应式地发现它——只要browser_*工具就绪，技能正文直接在场。而站点特定的技能（如hive.x-com-automation、hive.linkedin-*SDK 技能）则留在目录（catalog）中，依靠描述在需要时被按需选中。技能体系更完整的实现散落在 skills/manager.py、skills/models.py 与 skills/trust.py 中，包括技能的注册、解析、安装与信任分级。

跨会话改进三：系统化（Playbook）

这才是“大杀器”

系统化是整个execute-first-then-systematize（先执行、后系统化）弧线的终点，也是 improvement 文档所称的“big one”。流程如下：

1. Queen 先亲自完成一个单元的工作——即试点（pilot），并把结果记入 tracker；
2. 路径被验证后，Queen 把它拆解为一个 skill 加一个 playbook；
3. Playbook 作为确定性运行器（deterministic runner），把剩余的一批工作**收敛（converge）**到 worker 克隆 上执行。

Playbook 不拥有状态：tracker 才是唯一真相源

Playbook不拥有任何自己的持久状态：tracker（每 Colony 一个 SQLitetracker.db）是唯一真相源。它按每个工作单元派发一个 worker，带重试（retry）、退避（backoff），并对无法解决的任务提供死信路径（dead-letter path）。

因为“还剩什么”永远是一次新鲜的 tracker 查询，所以重跑 Playbook 天然就是续跑（resume by construction）——再运行一次，它会精确捡起所有尚未完成的工作。一次性的成功由此变成了可重复、可自续跑的过程。

源码证据：playbook/runner.py 的确定性收敛脊柱

core/framework/host/playbook/runner.py 的 docstring 明确自述为“deterministic playbook runner — the convergence spine”，并给出了核心解耦设计：runner只依赖两个注入的异步回调：

• dispatch_one(task, *, data, profile, timeout) -> report_dict——派生一个 worker 并等待其终态报告（报告形状即 Colony 的 worker 报告：status/summary/data/error等）；
• query_rows(sql) -> list[dict]——执行 tracker SELECT 并返回行。

其余一切（converge 循环、重试/退避、lane（泳道）限速、死信、schema 校验、exec 命名空间）都是纯逻辑、集中于此文件。两个值得注意的细节：

• _maybe_await允许pending条件写成同步（lambda: [...]）或异步（lambda: tracker_query(...)）两种形态都可用；
• DeadLetter类是终态失败存储，供 Queen 事后审阅——“没有静默丢弃（No silent drops）”。

让 Playbook 可续跑的基础设施

Playbook 之所以“重跑即续跑”，底层依赖 Colony 的协调基板（见 Coordination）：

• tracker（共享账本）：Queen 建 schema 并声明 worker 可写的列；worker 每完成一个单元工作就 upsert 一行；Queen 用 SQL 查询校验进度。状态在真实数据库中而非内存里，崩溃不丢数据，“做到哪了”永远是一次新鲜查询。每个 Colony 的 tracker 还被不可变绑定（binding）（colony 名、目录、数据库路径）约束，没有绑定的工具会拒绝运行而不是猜路径——这保证了两个 Colony 永远不会写错账本。
• worker 报告通道：worker 的终态动作是report_to_parent(status, summary, data)（success/partial/failed），经事件总线以[WORKER_REPORT]回合回到 Queen 的对话。即便 worker 耗尽迭代，还有一次**宽限迭代（grace iteration）**保证它总能报告、绝不静默死亡。

改进 ≠ 通用智能

一个重要的区分：上述机制让 Colony 变得更可靠（reliable），而不是更通用智能（generally intelligent）。Colony 并不是在抽象意义上学会“更好地推理”——它在做三件事：记住什么有效、把有效做法编码为技能、把已验证的试点变成可重复的流程。这是针对 Colony已经遇到过的问题类型的改进，而不是对未知问题的泛化能力。

对于真正全新的情境，这正是human-in-the-loop（Sentinel）的用武之地：需要人（审批、判断、缺失凭证）时，Queen 通过绑定的 Slack/Telegram 频道外带（out-of-band）升级；looppark住并把状态持久化到磁盘，人类回复后从离开的精确位置恢复。并且每一次人类介入的决策，都会成为 Queen 可以记住和复用的上下文——人工判断也汇入记忆回路，形成闭环。

实践建议：如何让 Colony 变得更好

结合上文机制与源码，把改进落到实处时有几点可操作的经验：

1. 把目标定义成可度量的成功标准：法官的 Retry 反馈质量取决于success_criteria与output_keys的精确度——含糊的目标只会产生含糊的反馈（见 goals_outcome.md）。
2. 给 Queen 足够多的运行轮次去“见识”：记忆与技能都来自真实运行。反思有冷却门控（默认 300 秒）与轮次门控（默认每 3 轮），刻意让反思与工作解耦、不干扰主循环——不要期望一次会话就积累出高质量记忆。
3. 让 worker 保持专注与快速失败：worker 无记忆、不可委派、不升级；broadening scope 是并行 worker 互相碰撞的根源。把任务切成严格单主题的单元，Playbook 的收敛效果才会好。
4. 把 Playbook 当作“可重跑的账本作业”：因为 tracker 是唯一真相源，Playbook 脚本只需关心“查询剩余工作 → 派发 worker → 写回结果”，重跑天然续跑。验证一个 Playbook 最直接的方式就是故意跑两遍——第二遍应只处理第一遍未完成的工作。
5. 保留人工介入的通道：Sentinel 的 park/resume 让 Colony 可以暂停几分钟到几天而不丢位置；人类决策被 Queen 记住后，下一次同类问题可能就不再需要人工了——这正是改进回路中“人”的位置。

深入阅读

• The Colony —— 成熟弧线（execute-first-then-systematize）的完整语境；
• The Loop —— 会话内的 reflexion 自纠错与法官管线；
• The Queen —— persona、路由与作用域记忆；
• Coordination —— 让 Playbook 可续跑的 tracker、任务计划与事件总线；
• The Worker Agent —— 系统化目标：worker 克隆的预算、报告与宽限迭代；
• Goals & Outcome-Driven Development —— 驱动改进信号的成功标准与约束；
• 源码级参考：judge_pipeline.py、reflection_agent.py、tool_gating.py、playbook/runner.py、Architecture Overview。

• 人工智能
• AI Agent
• 多智能体
• MCP 服务
• 工具调用
• 浏览器控制