首页 / 资讯中心 / 文章详情

聪明的头脑,高效的 Worker:HomeRail 多模型路由策略与 per-agent 模型映射配置指南

聪明的头脑,高效的 Worker:HomeRail 多模型路由策略与 per-agent 模型映射配置指南 ★ FEATURED ARTICLE
【免费下载链接】homerailVoice-first local agent orchestration runtime for auditable DAG workflows.项目地址https://gitcode.com/gh_mirrors/ho/homerail点击查看免费下载HomeRail 是一个运行在家庭服务器上的本地 Agent 编排运行时DAG workflow runtime。它的核心卖点之一就是多模型路由策略在同一个 DAG 工作流里不同的 Agent 节点可以使用不同的模型——最聪明的模型负责规划与评审便宜高效的模型承担大量执行工作。本文将从零讲清 HomeRail 的per-agent 模型映射配置方法帮你在不改动工作流 YAML 的前提下完成多模型组合。为什么需要多模型路由很多人使用 Agent 工具时习惯一个模型干所有事这在 DAG 场景下其实非常浪费上下文独立HomeRail 中每个 DAG 节点运行在独立的上下文窗口里只接收它需要的 handoff 内容做完自己的部分再把证据传下去上下文不会被撑爆角色不同需求不同规划Plan和评审Review节点需要更强的推理能力而实现Implement、测试Test、总结Summarize节点更适合用 token 性价比更高的模型成本可控把昂贵的模型只用在刀刃上一次 5 节点开发流程的成本可以明显下降。官方文档里把这叫做 Smart brain, efficient workers聪明的头脑高效的 Worker对应的模板是经典的 5 节点流水线plan → implement → test → review → summarize该模板见 public-dev-5node.yaml.template每个节点通过agent字段引用一个逻辑角色planner、implementer、tester、reviewer、summarizer。模型选择的单一事实来源数据库 LLM 设置HomeRail 有一个重要设计约束DAG 的 YAML 里不允许写 provider / model / api_key模型选择必须来自 Manager 数据库中的 LLM 设置。这是出于安全与可审计的考虑——凭证加密存储工作流文件保持 provider-independent。如果你在 YAML 里写了llm.provider或agents.id.llm.model启动时会被直接拒绝DAG provider/model runtime must be selected from database LLM settings, not YAML.这段校验逻辑在 runtime-selection.ts。配置步骤如下# 1. 从 provider 目录配置一个模型支持多个供不同 agent 使用 hr model configure provider-or-endpoint-alias \ --endpoint-id endpoint-id \ --model-name model-id \ --api-key-stdin # 2. 查看已配置的模型 hr model list # 3. 检查当前活动模型与运行环境是否就绪 hr doctor每个配置项在数据库中都有唯一 ID并带有一个可读的model_alias例如local-qwen、kimi-mainper-agent 映射就是通过这些别名完成的。3 步完成 per-agent 模型映射第 1 步准备一个 Runtime ProfileRuntime Profile 是把逻辑角色 → 模型绑定起来的配置文件并通过workflow_id绑定到某个工作流上。项目自带一个可直接参考的示例example-runtime.profile.yaml.templateprofile_id: example-runtime workflow_id: public-dev-5node-template default: # 兜底默认其余 agent 都走这里 model_alias: local-qwen agent_type: claude-sdk agents: reviewer: # per-agent 覆盖只有评审节点用强模型 model_alias: kimi-main agent_type: kimi_code要点default段是兜底默认值等价于通配符语义未显式指定的 agent 全部走它agents.角色名是per-agent 精确映射优先级高于default每个条目必须二选一model_alias或llm_setting_id不能同时写agent_type决定 harnessclaude-sdk、codex_appserver、kimi_code、deepseek_harness等同一个节点也可以换引擎。第 2 步同步 Profile 到 Managerhr profile sync assets/profiles/example-runtime.profile.yaml.template \ --workflow public-dev-5node-template同步时会校验model_alias在数据库中是否存在、条目是否合法校验实现见 dag-workflows.ts。第 3 步按 Profile 运行 DAGhr run \ --workflow public-dev-5node-template \ --profile example-runtime \ --prompt Draft a short project checklist运行后可以用hr dag supervise run_id观察 handoff 流动再用hr scorecard run_id检查每个节点的表现。通配符 *批量指定所有 Agent除了default段YAML 内联的runtime_profiles还支持*通配符键含义是该 profile 下所有 agent。典型用途是离线/测试场景runtime_profiles: offline-deterministic: agents: *: agent_type: deterministic这个写法出现在 public-two-node.yaml.template不需要任何模型供应商就能完成两节点拓扑检查hr run assets/orchestrations/public-two-node.yaml.template \ --profile offline-deterministic \ --prompt Draft a short checklist for a backend release应用逻辑在 change-orchestrator.ts先应用*通配映射再叠加具体 agent 的精确映射精确映射优先。注意带native_subscription的 agent 不允许被 profile 覆盖。路由如何被解析一次运行的模型决策每个节点被派发前Manager 会调用运行时解析器按以下顺序确定该节点用哪个模型与 harnessagent 级映射profile 的agents.角色或 run 级llm_setting_idprofile 的default段通配符兜底按agent_type选择兼容的数据库设置如kimi_code→ 任一活跃的 Kimi 设置codex_appserver→ 兼容的 Codex 设置。解析实现见 agent-runtime-resolver.ts。如果找不到兼容的活跃设置会得到明确报错例如Active DAG LLM setting not found——排障时先看这里。附加控制Provider 策略与审计禁用名单DAG meta 支持provider_policy.prohibited_providers/prohibited_models任何 agent 命中禁用 provider 或模型会在启动前被拒绝见 provider-policy.ts。适合团队里某些任务不允许用某家模型的合规要求全链路可审计每次运行绑定确切的 workflow revision 与 profile 身份可以用hr replay回放、hr eval-run评估哪次运行用了哪个模型有据可查CLI 驱动调优你完全可以交给一个编程 Agent 反复读模板、改 profile、跑 DAG、看 scorecard形成规划 → 运行 → 评估的调参闭环。常见问题速查现象可能原因处理No active DAG LLM setting found数据库里没有可用的模型配置执行hr model configure ...再hr model list确认Profile entry x must use either llm_setting_id or model_alias, not bothprofile 条目同时写了两项二选一模型名写错但没报错别名解析到了错误的设置用hr doctor核对活动模型想让某节点换引擎只改 model 不够同时覆盖该 agent 的agent_type小结HomeRail 的多模型路由策略可以归纳为三句话模型不进 YAML只进数据库——工作流文件只声明角色保持可移植Runtime Profile 做映射——default/通配符*兜底agents.角色精确覆盖强模型管规划与评审快模型干重活——成本与质量各取所需。更多 DAG 写法与模式库可以参考 workflow-spec-v1-authoring.md 与 dag-patterns.mdCLI 命令实现位于 homerail_cli/src/commands/。配置好之后跑一次hr smoke dag --template assets/orchestrations/public-dev-5node.yaml.template即可完整验证 plan → implement → test → review → summarize 五节点路径。赞分享【免费下载链接】homerailVoice-first local agent orchestration runtime for auditable DAG workflows.项目地址https://gitcode.com/gh_mirrors/ho/homerail点击查看免费下载相关推荐CLIProxyAPI高级配置指南模型映射、配额管理与安全策略CLIProxyAPI是一个强大的服务中间件为开发者提供多种AI模型兼容的API接口支持通过OAuth认证使用本地或多账户的CLI访问。本指南将深入介绍高级后端API网关LLM 网关人工智能FastClaw多模型接入指南OpenAI、Anthropic、Ollama与Per-Agent模型覆盖如何配置FastClaw多模型接入指南OpenAI、Anthropic、Ollama与Per Agent模型覆盖如何配置 FastClaw 是一款用 Go 编写的轻量模型并行策略ESFT PP分割与设备映射配置模型并行策略ESFT PP分割与设备映射配置 你是否在训练大型语言模型时遇到过GPU内存不足的问题是否为如何高效分配模型层到多个设备而烦恼本文将详细介绍E大模型微调人工智能DeepSeek上一篇K3s集群专属gh_mirrors/cl/cluster-monitoring监控平台部署与配置终极指南下一篇Hacker101 iOS Hacking文件系统基础——数据存储痕迹、沙盒结构与数据保护属性分析创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
阅读完成 · 觉得有帮助?
咨询建站