Raven：可组合 Agent Harness、Host 调度与自演化架构

Agent 系统正在从“一个模型配一套工具”走向更复杂的组合：研究任务交给搜索型 Agent，代码交给熟悉仓库的 Agent，设计和长期运行又由另外的执行器负责。Raven 把这种组合关系推进了一步——它不把模型单独视为能力单位，而是把模型与 Harness 的组合作为可调度的执行单元。

2026 年 9 月 27 日提交的论文 Raven: The Harness of Harnesses for Composable Agentic Intelligence 给出了一套完整架构：Host Agent 负责拆解目标、选择专业 Agent、建立依赖关系和整合结果；每个执行节点保留自己的工具、上下文策略与运行规则。系统同时引入持久记忆、Skill Forge 和 Harness 自演化机制，让一次任务中的经验能够进入后续任务。

为什么组合单位是“模型 × Harness”

同一个模型放进不同 Harness，最终能力并不相同。文件读写、Shell 超时、上下文压缩、工具错误反馈、记忆和完成判断都会改变模型能否把任务做完。

Raven 因此把一个 Agent 表示为模型与 Harness 共同形成的执行策略。它的 Registry 记录每个 Agent 擅长的任务和可用接口，既能注册 Raven-Research、Raven-Code、Raven-Design、Raven-Oncall，也能通过 Adapter 接入 Claude Code、Codex、OpenCode、Hermes Agent 和 OpenClaw。

这和“所有 Sub-agent 共用同一套 Prompt，只给不同角色名”有本质区别。Raven 组合的是不同的执行环境和控制策略，而不只是不同的人设。

Host Agent 如何组织工作

Host Agent 不直接把一段总任务同时广播给多个 Agent，而是把工作编译成有向无环图（DAG）：

1. 将目标拆成可交付的节点；
2. 根据 Registry 为每个节点选择执行者；
3. 用边描述先后关系和产物依赖；
4. 校验图是否合法，再调度依赖已经满足的节点；
5. 保存文件、运行记录和交付物，供后续节点直接引用；
6. 处理异常、补充问题，并完成最终整合。

例如开发一款游戏时，需求研究可以先运行；玩法开发和视觉设计随后并行；两条分支完成后再进入集成、测试与部署。图中传递的是明确的 Artifact，而不是让上游 Agent 在聊天消息里重新讲一遍结果。

这一点很重要：多 Agent 系统的难点通常不是“能不能多开几个 Agent”，而是交接是否完整、依赖是否正确，以及失败后由谁决定重试、改派或终止。

DeepSeek V4 Flash 下的调度结果

论文用 Multi-Agent Orchestration Benchmark 单独评估规划，不实际执行 Worker。Raven、Claude Code 和 Hermes Agent 接收相同任务文本与调度说明，分别使用 Qwen3.8-27B 和 DeepSeek-V4-Flash-0731 作为 Backbone，在同一组 140 个任务上生成执行图。

在 DeepSeek-V4-Flash-0731 组中：

Node F1 衡量专业 Agent 是否选对，Edge F1 衡量依赖关系是否正确，Exact Match 要求专业 Agent 集合和先后关系都与接受的参考图一致。结果表明，Raven 的优势不仅来自选择了哪些 Agent，也来自更准确地组织它们之间的交接。

Raven-Research 与 DeepSeek Harness 的同模型对照

论文还把 Raven-Research、DeepSeek Harness 和 MiroFlow 接入相同 Backbone，并使用相同搜索与页面读取工具。在 DeepSeek-V4-Flash 组的 DeepResearch Mixed 测试中，论文报告：

这个对照的价值在于固定了模型和工具，让 Harness 的搜索策略、上下文组织和完成方式成为主要变量。Raven-Research 以略高于 DSH 的估算成本取得更高的合并准确率，同时使用更少的输入 Token。

但这组实验保留了各 Harness 自己的轮数、时间限制和上下文策略，评测问题也参与过研究流程开发。它适合说明整套工作流的差异，不适合把分数直接解释成某个单一组件的净增益。

Harness 如何自己演化

Raven 没有让运行中的 Agent 随意改写自身全部逻辑，而是把可变范围做成模块化 Harness：

• 从失败轨迹中定位工具、上下文或控制策略的问题；
• 生成候选修改；
• 在冻结 Backbone 的前提下进行配对测试；
• 只有通过有效性与提升门槛的候选才能进入可用集合；
• 将有效策略保存到 Harness Gene Bank，供后续重组。

论文引用的 HarnessBank 实验在七组基准上比较初始与演化后的 Harness。冻结同一个 Qwen3.6-27B Backbone 后，报告的 Pass@1 提升范围为 5.1 到 15.4 个百分点。

这种设计比“让 Agent 修改自己的 Prompt，然后继续运行”更接近工程系统：改动有边界，候选需要筛选，历史版本能够比较，也可以回退。

Memory 与 Skill Forge 解决不同问题

Raven 将长期复用拆成两条路径：

• Memory 保存事件、事实、用户上下文和跨会话经验，回答“以前发生过什么”；
• Skill Forge 将可重复的执行方法整理成 Skill，回答“下次遇到类似任务应该怎么做”。

Skill 不只是从外部目录检索。系统可以结合执行案例聚类任务意图，生成明确的更新操作，经过验证后保存新的版本与来源关系。这样，记忆不会全部挤进 Prompt，稳定的方法也不必每次从对话记录里重新推导。

对 DeepSeek Harness 的启示

Raven 展示的不是“再做一个更大的万能 Agent”，而是一种更清晰的系统边界：

1. Profile 或 Preset 应描述一套可执行能力，而不只是模型和 Prompt 的别名；
2. Agent Team 需要显式 Artifact、依赖和完成条件，不能只靠自由对话串联；
3. Trajectory 应服务于失败诊断、回归测试与 Harness 版本演化；
4. 模型评测必须连同 Harness 版本、工具和上下文策略一起记录；
5. 多 Agent 的资源预算应覆盖 Host 规划、Worker 执行、重试和最终整合，而不只统计主会话。

对普通用户而言，最直接的变化是：未来选择 Agent 时，不会只问“它用了哪个模型”，还要问它带着什么 Harness、能否把任务交给更合适的执行器，以及结果如何可靠地交回来。

相关阅读

• 模型与 Harness 的匹配效应：66 种配置的跨任务评测
• HarnessDev：模型能否创建并演化自己的 Agent Harness
• MemoHarness：Agent Harness 如何从执行经验中学习
• DSH、Deepagents 与 Pi 的 Agent Harness 架构趋同

参考资料

• Raven: The Harness of Harnesses for Composable Agentic Intelligence
• Raven 论文 HTML 全文
• Raven 源代码