OpenHuman Agent 域深度解析多智能体编排、工具调用循环与触发分类管线【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman本文基于 src/openhuman/agent/README.md 展开结合仓库源码、内置智能体定义与测试用例系统讲解 OpenHuman 中多智能体编排域agentcrate的职责边界、会话运行时、工具调用循环、子智能体派发、触发分类triage管线与提示词组装机制。读完你将掌握Agent/AgentBuilder的调用入口、AgentDefinition的完整配置字段、ToolDispatcher三种工具方言的取舍以及外部事件webhook、cron、Composio 触发器如何被分类并升级为子智能体任务。域边界什么归 Agent 管什么不归它管agent域是 OpenHuman 的多智能体编排核心位于 src/openhuman/agent/。它拥有以下四块核心能力LLM 工具调用循环tool-calling loop——模型迭代式调用工具的运行时子智能体派发sub-agent dispatch——从父工具循环中启动分层子智能体会话转录conversation transcripts——对话历史的持久化与回放触发-分类管线trigger-triage pipeline——对进入系统的外部事件进行分类内置提示词资产agent/prompts/目录下的系统提示词模板。而以下内容明确不属于本域这些边界在 README 中被逐条列出是理解模块划分的关键不属于 Agent 域归属位置Provider HTTP 传输层src/openhuman/providers/工具实现src/openhuman/tools/提示词分节组装src/openhuman/agent/context/通过context::prompt从agent::prompts再导出记忆存储src/openhuman/memory/这种划分让agent域可以专注于运行时/编排行为而把传输、工具、记忆等横切能力留给各自领域实现关注点分离。从 harness/session/mod.rs 的模块文档可以看到模型/工具迭代循环本身也已下放到tinyagents::run_turn_via_tinyagents_shared本模块保留的是OpenHuman 产品外壳——转录持久化与旧格式兼容、提示词分节组装与 KV-cache 前缀稳定性、记忆/上下文注入策略、回合后钩子post-turn hooks以及持久化历史结构。依赖关系Calls into 与 Called byagent域处于编排枢纽位置向下调用各能力域向上被各入口域驱动。它调用Calls intosrc/openhuman/providers/ — 通过ChatMessage/ChatResponse与 LLM 收发消息src/openhuman/tools/ — 工具循环中通过Tool/ToolSpec执行工具src/openhuman/memory/ — 情景索引episodic indexing 记忆加载器上下文注入src/openhuman/agent/context/ — 提示词分节与工具调用格式选择src/openhuman/inference/local/ —agent_chat/agent_chat_simple的执行后端src/openhuman/config/ — 通过config::rpc::load_config_with_timeout加载运行时配置src/core/event_bus/ — 发射DomainEvent::Agent(*)与Trigger*事件订阅逻辑位于 agent/bus.rs。谁调用它Called bysrc/openhuman/channels/runtime/dispatch.rs 与web_chat/— 从入站频道消息驱动聊天回合src/openhuman/cron/scheduler.rs — 通过triage::run_triageapply_decision触发定时任务src/openhuman/skills/webhooks/ops.rs — Webhook 摄取经 triage 路由src/openhuman/integrations/composio/bus.rs — Composio 触发器信封走agent::triagesrc/openhuman/desktop/notifications/rpc.rs — 向 UI 呈现 agent 运行状态src/openhuman/agent/learning/reflection/tool_tracker/user_profile— 读取转录与工具执行结果用于学习src/openhuman/agent/orchestration/tools/dispatch/spawn_subagent—spawn_subagent工具委托到这里src/core/all.rs — 控制器注册表通过all_agent_registered_controllers装配。会话运行时Agent 与 AgentBuilder顶层会话运行时由pub struct Agent与pub struct AgentBuilder构成定义于 harness/session/types.rs这是任何聊天回合的入口点。从 harness/session/mod.rs 的文件布局看该模块拆分为四层文件职责typesAgent与AgentBuilder结构定义无逻辑builderAgentBuilder流式 API Agent::from_config工厂turnturn()生命周期、工具派发、上下文管线装配runtime公开访问器、run_single/run_interactive、辅助函数公开模块面还包括pub mod harness::session::{builder, runtime, turn}对应 harness/session/mod.rs提供回合生命周期、流式构建器以及run_single/run_interactive两个执行入口。外部调用方应从crate::openhuman::agent导入Agent与AgentBuilder该处会从本模块再导出子文件属于实现细节。值得一提的实现细节是 builder.rs 中的dedup_visible_tool_specs该函数作为去重工具规格守卫被session::runtime与subagent_runner共享确保所有 provider 调用点使用同一份经过测试的实现避免工具目录重复注入导致提示词膨胀。工具调用循环ToolDispatcher 与三种方言工具调用循环的格式抽象由 dispatcher.rs 提供。核心公开面为pub trait ToolDispatcher、pub struct ParsedToolCall与pub struct ToolExecutionResult见 dispatcher.rs。ParsedToolCall— 从 LLM 响应中解析出的工具调用工具名name、JSON 参数arguments、原生 API 提供的可选tool_call_idToolExecutionResult— 工具执行结果工具名、输出字符串、是否成功、关联的tool_call_idToolDispatcher— 定义 agent 与 LLM 在工具使用上的交互协议六个核心方法方法职责parse_response从ChatResponse解析叙事文本与工具调用format_results将工具执行结果格式化为下一条 LLM 回合消息prompt_instructions生成系统提示词中如何调用工具的说明prompt_instructions_for_specs当 dispatcher 在提示词协议中内嵌工具目录时为已过滤的ToolSpec生成说明默认Noneto_provider_messages将内部对话历史转换为 provider 专用消息should_send_tool_specs判断是否需要在 API 请求中发送工具规格不同的 LLM 有不同的工具方言dialect。dispatcher 抽象了这些差异让 agent 循环对 provider 的特定格式保持无感知。当前实现支持XML / JSON / P-Format三种方言方言本体位于tinyagents_harness::tool_calling::dialect本文件只保留 OpenHuman 词汇层的适配NativeDialect、XmlDialect、PFormatDialect的投影。dispatcher.rs 中大量字段级、无损的转换函数to_dialect_response、to_native_call、from_parsed_calls、to_outcomes等构成OpenHuman 词汇 ↔ crate 词汇的接缝保证线上字节一致。tool_call_format()方法还会告知提示词构建器如何在## Tools一节渲染每个工具条目默认值为ToolCallFormat::Json。子智能体系统AgentDefinition、Registry 与 run_subagent数据驱动的智能体定义子智能体原型archetype由 harness/definition.rs 中的AgentDefinition/AgentDefinitionRegistry/SandboxMode/ToolScope描述。如 definition_part_01.rs 注释所述一个完整指定的子智能体原型它知道什么、能做什么、如何提示它。定义文件刻意零引用agent 运行时的其余部分——纯数据便于独立单测并可直接从磁盘序列化。AgentDefinition的关键字段按功能分组身份identityid— 原型唯一标识如researcher、code_executorwhen_to_use— 人类可读的使用时机说明展示给父模型帮助其决定是否委派display_name— UI 与日志中的可选显示名。提示词promptsystem_prompt— 该专家智能体的核心系统提示词体PromptSourceomit_identity/omit_memory_context/omit_safety_preamble/omit_profile/omit_memory_md— 五个开关决定是否从渲染出的提示词中剥离父会话的身份段、记忆上下文段、安全前言段、用户PROFILE.md与 archivist 精选的MEMORY.md。默认均为true让窄领域专家保持精简仅面向用户的智能体welcome、orchestrator、触发对显式设置false选择注入。模型modelmodel— 该子智能体的模型选择策略ModelSpectemperature— 采样温度默认见defaults::subagent_temperature。工具toolstools— 从父注册表继承哪些工具ToolScopedisallowed_tools— 即使匹配作用域也要显式封禁的工具名列表skill_filter— 仅保留属于特定技能如notion的工具extra_tools— 在ToolScope之外始终可见的具名工具历史上是已移除的category_filter的旁路现作为自定义定义的通用附带包含钩子条目仍受disallowed_tools约束。运行时限制runtime limitsmax_iterations— 最大工具迭代次数默认见defaults::max_iterationsiteration_policy— 迭代上限策略Strict硬失败在max_iterations适合 summarizer/triage 等短运行智能体触及上限即提示循环或Extended用 harness 级常量EXTENDED_MAX_TOOL_ITERATIONS 50替换逐智能体上限让 orchestrator、深度研究等长运行智能体完成真实的多工具工作流重复失败熔断与成本预算仍然生效UI 也会省略分母以免误导性倒计时见 definition_part_01.rsmax_result_chars— 结果在作为工具结果回传给父智能体前的最大字符数None表示不设上限研究/规划/代码智能体建议设置以防上下文淹没max_turn_output_tokens— 单次 LLM 调用的输出 token 上限未设置时使用共享的 agent 回合上限timeout_secs— 墙钟超时秒sandbox_mode— 工具执行的沙箱级别background— 预留的后台异步执行支持trigger_memory_agent— 回合前记忆检索钩子Never默认不自动运行或Always在用户提示词发送给本智能体前运行一次内置agent_memory并前置其结果tokenjuice_compression— 逐智能体的 TokenJuice 工具结果压缩档位auto对普通智能体保持压缩开启但将编码类模型智能体解析为light以免 CCR 支撑的有损压缩替换掉编码 agent 常常需要原文的构建/测试/diff/搜索文本。委派面delegation surface允许本智能体通过合成的delegate_*工具启动哪些子智能体每条目在构建期展开为一个可调用的函数调用 schema 工具。内置原型与自定义覆盖内置原型存放在 src/openhuman/agent/registry/agents/ —— 每个智能体一个子目录内含agent.toml元数据与prompt.md系统提示词。当前内置原型包括archivist、code_executor、context_scout、critic、crypto_agent、flow_memory_agent、goals_agent、help、image_agent、integrations_agent、mcp_agent、mcp_setup、morning_briefing、orchestrator、planner、presentation_agent、profile_memory_agent、researcher、scheduler_agent、settings_agent、skill_creator、summarizer、task_manager_agent、tool_maker、tools_agent、trigger_reactor、trigger_triage、video_agent、vision_agent等。加载逻辑位于 registry/agents/loader.rs 与 harness/builtin_definitions.rs后者还会追加合成的fork定义。用户可以通过工作区自定义 TOML扩展或覆盖这些原型放在$OPENHUMAN_WORKSPACE/agents/*.toml工作区级或~/.openhuman/agents/*.toml用户全局专家在 id 冲突时覆盖内置定义。目录扫描与 TOML 解析契约见 harness/definition_loader.rs。子智能体执行流水线子智能体在运行时由spawn_subagent工具派发该工具按 id 在全局AgentDefinitionRegistry中查找定义交给 harness/subagent_runner/ 的run_subagent执行。公开面包括pub fn run_subagent、pub struct SubagentRunOptions与pub enum SubagentRunError。其执行流程见 harness/subagent_runner/mod.rs读取父Agent::turn通过fork_context::ParentExecutionContext设置的 task-local 父上下文解析子智能体的模型名继承 / 提示 / 精确三种模式按definition.tools、disallowed_tools、skill_filter过滤父工具注册表fork模式下原样继承父工具构建窄化系统提示词剥离定义要求省略的分节omit_identity、omit_memory_context、omit_safety_preamble使用父的Provider在 TinyAgents harnessops::graph→run_turn_via_tinyagents_shared上运行子回合然后镜像子转录/进度向父返回一条紧凑的工具结果。从代码结构看该模块扮演的是 TinyAgents 运行之上的OpenHuman 构建管线定义查找/允许列表、原型提示词组装、工具集过滤、沙箱/动作根目录收窄、检查点/交还、工作线程转录镜像且明确保持 host 所有对应tinyagents_harness::host::HostCapabilities的ContextComposer、DefinitionRegistry、SecurityGate、ModelResolver四个阶段。另外harness/fork_context.rs 提供 task-local 父上下文用于KV-cache 复用——子回合可以复用父回合已经缓存的提示词前缀降低长流程的 token 成本。触发分类管线triagepub mod triage是一个可复用的触发分类辅助模块——被设计为高性能分类管线快速且准确地处理入站外部事件webhook、cron 触发决定事件是应被丢弃的噪音、需要确认的简单通知还是需要 agent 响应的可操作触发。公开面见 triage/mod.rsrun_triage、apply_decision、TriggerEnvelope、TriageDecision、TriageAction。架构分四个阶段见 triage/mod.rs信封Envelope调用方将数据包装进TriggerEnvelope评估Evaluatorrun_triage使用小型本地模型若可用产生TriageDecision并内置失败自动回退远程机制保证鲁棒性路由Routing管理本地 vs 远程决策缓存升级Escalationapply_decision执行副作用可能派生trigger_reactor简单任务或orchestrator复杂任务。官方使用示例use crate::openhuman::agent::triage::{run_triage, apply_decision, TriggerEnvelope}; // 1. Hydrate the envelope let envelope TriggerEnvelope::from_composio(toolkit, trigger, id, uuid, payload); // 2. Classify (LLM call) let decision run_triage(envelope).await?; // 3. Execute side effects (Sub-agent spawn events) apply_decision(decision, envelope).await?;子模块划分decisionparse_triage_decision、TriageAction、TriageDecision、envelopeTriggerEnvelope、TriggerSource、escalationapply_decision、evaluatorrun_triage、TriageOutcome、TriageResolutionPath、TriageRun、events、originlocal_trigger_origin、remote_trigger_origin、routingbuild_local_provider_with_config、resolve_provider、ResolvedProvider。每个子模块都配有同名*_tests.rs其中evaluator因复杂度拆成了evaluator_part_01.rs/evaluator_part_02.rs加两套测试文件。实战示例以 orchestrator 的 agent.toml 看定义落地以真实的内置定义 registry/agents/orchestrator/agent.toml 为例观察上文字段如何落地id orchestrator display_name Master Agent when_to_use Default user-facing agent — handles everyday work directly, including code-repository tasks, and delegates only when parallelism or specialised capability materially helps. You should not normally spawn another orchestrator from inside one. temperature 0.4 max_iterations 15 sandbox_mode sandboxed agent_tier chat omit_identity false omit_memory_context true omit_safety_preamble true # orchestrator 是用户直面的一线智能体——它路由、综合、以用户口吻说话。 # PROFILE.mdonboarding 富化产物锚定这种口吻。 omit_profile false # MEMORY.md —— archivist 精选的长期记忆 —— 以先前对话与提炼的用户偏好为回复提供依据。 # 每个会话冻结一次AgentDefinition::omit_memory_md 上的 KV-cache 契约。 omit_memory_md false该文件中的注释揭示了两个关键设计决策身份从工作区加载而非编译进提示词issue #5701 之后IdentitySection注入SOUL.md产品人格所有选择加入的智能体共享与ROLE.md本智能体角色简报。两者都是工作区下用户可编辑文件调整身份不再需要重新编译——但前提是omit_identity false为true时构建器会整体跳过IdentitySection。记忆检索改为按需而非抢占orchestrator 曾用trigger_memory_agent always在每个回合前急切运行agent_memory每次消息包括琐碎消息都派生一个完整的 ≤15 次迭代的记忆子智能体。改为在[subagents]允许列表中列出agent_memory合成delegate_retrieve_memory工具由模型按需决定何时检索。层级约束loader 强制要求chat级智能体不得在subagents中列出其他chat级智能体——交接只能走reasoning如 planner做长运行深工作或直接走worker专家做快速路径AgentTier定义于 harness/definition.rs。RPC 面与 Schema 稳定性agent 域对外暴露一组 RPC定义于 schemas.rsagent.chat/agent.chat_simple— 执行聊天回合agent.server_status— 服务状态agent.list_definitions/agent.get_definition/agent.reload_definitions— 子智能体定义的枚举、读取与热重载agent.triage_evaluate— 触发分类评估。值得强调的是 schema 回归测试schemas.rs:393-410的controller_schema_inventory_is_stable测试守护 RPC 契约的稳定性防止控制器 schema 目录意外漂移——这是多端桌面、CLI、移动、web共享协议的重要保障。测试体系根据 agent/README.md 的 Tests 一节本域测试分为三层单元测试mod.rs的#[cfg(test)] mod tests;、tests.rs、multimodal_tests.rs、dispatcher_tests.rs以及harness/、harness/session/、triage/下的各*_tests.rs文件部分大文件按*_part_01_tests.rs/*_part_02_tests.rs拆分集成测试tests/agent_builder_public.rs构建器公开面、tests/agent_harness_public.rsharness 公开面、tests/agent_memory_loader_public.rs记忆加载器、tests/agent_multimodal_public.rs多模态Schema 回归schemas.rs:393-410的controller_schema_inventory_is_stable。小结OpenHuman 的agent域是一个职责清晰的编排中枢Agent/AgentBuilder提供会话级运行时与run_single/run_interactive入口ToolDispatcher用 XML/JSON/P-Format 三种方言抽象工具调用协议AgentDefinition 注册表 run_subagent构成可数据驱动的子智能体系统内置 30 原型支持工作区 TOML 覆盖与热重载triage管线把 webhook、cron、Composio 等外部触发分类升级为trigger_reactor/orchestrator任务。若你需要在 OpenHuman 之上开发自定义专家智能体路径非常清晰在$OPENHUMAN_WORKSPACE/agents/下放置一份agent.toml复用或覆盖内置定义通过spawn_subagent与delegate_*工具即可接入这套编排体系。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考