尧图网站建设 
OpenHuman Master 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导读在 OpenHuman 的多智能体架构中Master Agent即orchestrator编排者是用户每天打交道的默认智能体它直接处理日常任务只有在并行、深度推理或专门能力能实质改善结果时才委派给子智能体。本文以仓库中的角色说明文件 src/openhuman/agent/prompts/ROLE.md 为主线结合 SystemPromptBuilder 的提示词装配机制、orchestrator 配置 与 委托路由指南系统讲解 Master Agent 的定位、动作沙箱工具集、direct-first 委派决策树、多子代理并发管理以及安全/审批/沙箱三层边界。读完你将理解 OpenHuman 是如何在系统提示词层面把何时亲自动手、何时委派、如何追踪子代理、如何守住安全底线编码进 Agent 行为模型的。一、Master Agent 是什么默认面向用户的智能体ROLE.md 开宗明义地定义了 Master Agent 的角色定位You are theMaster Agent, the default user-facing agent in a multi-agent system. Handle ordinary work directly; delegate only when parallelism, deeper reasoning, or a specialised capability materially improves the result.这句话拆解出三层含义它是多智能体系统的默认入口——用户的每一条消息首先到达 Master Agent而不是直接分发给某个专家代理直接优先direct-first——普通工作当场处理委派不是默认动作委派有严格触发条件——只有并行parallelism、更深推理deeper reasoning、专门能力specialised capability三者之一能实质性改善结果时才委派。在仓库中这一角色定义对应 src/openhuman/agent/registry/agents/orchestrator/agent.tomlid 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值得注意的配置细节agent_tier chatMaster Agent 处于chat层级是用户交互的叶子层。它不能向另一个chat层代理委派Never spawn yourself只能走chat → worker快速路径或chat → reasoning → worker深度路径。加载器在启动时就会拒绝同层委派运行时 spawn 关卡也会拒绝违反层级或过深的 spawn层级门限制链条最多 3 跳。sandbox_mode sandboxed所有变更操作都发生在动作沙箱中与安全/审批/沙箱层管理每一次变更和命令的角色约束一一对应。temperature 0.4、max_iterations 15偏保守的采样温度与每轮迭代上限符合其稳定完成日常任务的前线定位。二、ROLE.md 如何进入系统提示词身份注入机制ROLE.md 不是一份游离的文档而是系统提示词IdentitySection身份区块的组成部分。在 src/openhuman/agent/prompts/sections.rs 中构建系统提示词时会同步并注入三个工作区文件let all_files: [str] [SOUL.md, IDENTITY.md, ROLE.md];SOUL.md产品人格所有选择加入的代理共享IDENTITY.mdOpenHuman 的身份与核心价值观隐私优先、准确性优于速度、用户赋能、透明度ROLE.md当前代理自身的角色简报——即orchestrator的# Master Agent定位。注释明确指出ROLE.md 的文本曾经被编译进 orchestrator/prompt.md 的# Master Agent/## Core Responsibilities前言现在迁移到磁盘上的工作区文件用户可以直接编辑这些文件来调整代理身份无需重新编译对应 agent.toml 中omit_identity false的注释说明。关键点ROLE.md 只对orchestratorMaster Agent注入。在IdentitySection::build中is_orchestrator判断依据是!ctx.visible_tool_names.is_empty()非编排者代理其子代理 prompt 走for_subagent路径会跳过 ROLE.md——因为专家子代理有自己的角色提示词绝不能被告诉它自己是 Master Agent。系统提示词的完整装配链SystemPromptBuilder::with_defaults()builder.rs定义了 Master Agent 系统提示词的区块顺序IdentitySection—— 注入 SOUL.md / IDENTITY.md / ROLE.mdUserFilesSection—— 注入用户专属的PROFILE.md与MEMORY.md各按USER_FILE_MAX_CHARS截断AgentsInstructionsSection—— 注入AGENTS.md项目指令全局层 项目层每层按BOOTSTRAP_MAX_CHARS封顶并带[... truncated]标记UserMemorySection—— 树摘要器蒸馏的长期用户记忆ToolsSection—— 工具目录P-Format 紧凑签名或原生 function-calling schemaSafetySection—— 安全规则WorkspaceSection—— 工作目录指引DateTimeSection—— 日期时间纪律RuntimeSection—— 运行时信息主机 / OS / 模型。最后由build()统一追加GROUNDING_BODY接地与反幻觉契约和GLOBAL_STYLE_SUFFIX写作风格来自 STYLE.md。整个提示词在会话开始时构建一次后续轮次复用完全相同的字节以保证推理后端的前缀缓存KV cache稳定命中。三、动作沙箱中的正常编码循环Master Agent 的核心工具集ROLE.md 规定 Master Agent 拥有动作沙箱action sandbox中的正常编码循环用file_read/grep/glob/list检查inspect用apply_patch修改已有文件用file_write创建新文件用shell运行聚焦命令用git_operations处理仓库状态。对应到 agent.toml 的[tools] named白名单Master Agent 直接持有这些工具file_read, grep, glob, list, apply_patch, file_write, shell, git_operations,prompt.md进一步明确了使用范式仓库工作走inspect →apply_patch改已有文件/file_write新建→shell做最小验证的闭环git_operations用于读取仓库状态。特别强调Keep code work end-to-end——被要求改代码时必须在同一轮内完成编辑与验证绝不因为任务碰了仓库就委派。需要注意的边界apply_patch是修改已有文件的唯一编辑机制file_write只能创建新文件策略/审批/沙箱的强制逻辑留在工具层this declaration only makes the tools discoverable to the agent。这正是 ROLE.md 最后一句security, approval, and sandbox layers govern every mutation and command; never work around them的配置层落地。四、Direct-first 委派决策树何时亲自动手何时交给专家orchestrator/prompt.md把 ROLE.md 的委派原则扩展成了一份可执行的决策树核心精神是过度委派琐碎工作是这里最常见的失败模式。决策顺序取第一个命中的分支优先级情形动作1无需工具即可回答直接回复2需要已连接服务的实时数据/动作收件箱、日历、文档、票据、发送/检查delegate_to_integrations_agent按 Connected Integrations 匹配toolkit3可用直接工具解决自己干见下表4需要专家按意图路由见下表5任何委派回复蒸馏后再交给用户——子代理输出是原材料不是答案直接工具 vs 委派的对照表节选自 prompt.md工作类型直接工具仅在以下情况委派记忆事实存取memory_recall/memory_store/save_preference多跳记忆树遍历、ingest、笔记调和 →retrieve_memory单条事实查询web_search_tool/web_fetch/http_request多源爬取、对比、深度摘要 →research仓库工作apply_patch/file_write/shell/git_operations独立评审、长时或并行调查 →run_code专家路由表节选ask_docsOpenHuman 行为/设置/文档、schedule_task提醒/定时任务、make_presentation幻灯片、do_crypto钱包/市场强制 read → simulate → confirm → execute、setup_skills技能安装、run_skill运行已装技能、research多源爬取、plan复杂多步分解、review_code代码评审、archive_session记忆归档。这些delegate_*工具不是硬编码的而是由collect_orchestrator_tools在构建期从 agent.toml 的[subagents] allowlist自动合成——每个条目生成一个delegate_*工具工具的 LLM 可见描述直接取目标代理的when_to_use。这让路由决策发生在函数调用选择层而不是藏在一个巨型工具的参数枚举里。结构化交接信封Structured handoffs每个delegate_*工具都接受同一套可选字段防止子代理凭空脑补上下文prompt必填——任务指令子代理对本次对话没有任何记忆objective—— 一句话命名子代理必须产出的结果evidence—— 只允许实际观察过的事实/路径/URL/ID/工具输出禁止猜测constraints—— 必须遵守的硬性要求must_not_assume—— 子代理不得无证据推断的断言expected_output—— 期望返回的形状findings list / patch summary / cited answercitation_requirement——none·file_paths·urls·retrieval_hits·tool_outputsmodel—— 仅本次委派使用的精确模型 ID非必要不填blocking—— 默认false异步仅当结果必须门控本次回复时传true。五、多子代理并发subagent_session_id 与异步生命周期ROLE.md 特别强调Master Agent 可以同时有多个子代理在飞行several sub-agents in flight at once每个子代理有独立的 transcript 和稳定的subagent_session_id跟踪它们是 Master Agent 自己的工作。仓库中的相关工具与机制spawn_async_subagent实现——启动 worker 的唯一方式且总是异步立即返回 task id结果在子代理完成后自动作为新的一轮交付无需轮询或等待continue_subagent实现——恢复因提问而暂停awaiting_user的子代理必须针对精确的task_id重新 spawn 会丢失其全部进度list_subagents实现——重新枚举所有在飞 workerrunning/awaiting_user/completed/failed以及可复用的持久会话是上下文滚动丢失后的恢复手段每轮前缀的[active_subagents]块是事实来源agent type、subagent_session_id、状态其数据来自同一个running_subagents注册表。关键的并发纪律prompt.md按subagent_session_id或 task_id追踪agentId只是 worker 的类型——同时 spawn 的两个 researcher 共享一个类型但状态绝不能合并绝不重复 spawn——已有合适的 worker 在跑就让它跑完扇出fan-out就是多次spawn_async_subagent调用——N 个独立子任务 N 次并行 spawn各自独立返回不要扇出相互依赖的子任务failed的 worker 永远不会产出结果必须如实上报失败而非编造结果异步只用于当前回复不依赖的工作尽力而为的记忆归档、非紧急清理、后台调查结果门控工作必须同步delegate_*阻塞或spawn_async_subagent带blocking: true。六、安全、审批与沙箱边界不可绕过的三层治理ROLE.md 的收尾句是全篇最硬的一条约束The security, approval, and sandbox layers govern every mutation and command; never work around them.仓库中有多道防线佐证安全区块SafetySectionsections.rs为每个代理注入固定规则——不泄露私有数据、不经询问不执行破坏性命令、不绕过监督/审批机制、优先trash而非rm、对外行动前有疑问先问。接地契约GROUNDING_BODY是全员继承的反幻觉底线单一事实来源防止各代理 prompt 各自复制而漂移工具列表即全部能力、绝不编造工具名/参数/ID/路径/URL/引用、数字证据原样保留、失败就说失败、[SUBAGENT_INCOMPLETE]信封要如实转述成果与阻塞原因。工作区沙箱WorkspaceSection不打印硬编码路径而是让代理用pwd运行时确认工作目录——因为文件工具被沙箱限定在 action 目录内写死 workspace 路径曾导致写入后读不回的错位临时文件只能写入被授权的 scratch 目录或$TMPDIR硬编码/tmp/name被阻止。AGENTS.md 路径加固项目层AGENTS.md位于用户/项目可控目录加载器agents_md.rs做了竞态安全处理——Unix 上用O_NOFOLLOW | O_NONBLOCK打开内核级拒绝最终组件符号链接、fstat 校验必须是常规文件、规范化路径必须落在根目录内、读取字节数封顶BOOTSTRAP_MAX_CHARS * 4 1024防止巨文件拖垮提示词构建或耗尽内存。审批门控request_plan_review在多步交互任务执行前暂停回合用户approved后才创建 todo 卡片并执行do_crypto强制 read → simulate → confirm → executeupdate_apply需要显式用户同意。这与 ROLE.md 的approval layers对应。七、KV 缓存稳定性角色提示词背后的工程约束Master Agent 的角色提示词设计处处服务于一个工程目标——系统提示词字节稳定命中推理后端的前缀缓存ROLE.md / SOUL.md / IDENTITY.md 在会话开始时同步并注入一次UserFilesSection注入的 PROFILE.md / MEMORY.md 同样会话冻结archivist 在会话中期的写入只影响下一个会话DateTimeSection不注入具体时间戳避免每次构建变化破坏缓存实时时间由每轮用户消息上的Current Date Time:行提供子代理提示词刻意不含DateTimeSection——同一定义的重复 spawn 必须产出字节相同的系统提示词否则前缀缓存失效接地契约GROUNDING_BODY刻意保持字节稳定无时间/RNG/主机信息并放在提示词尾部作为收尾契约AgentsInstructionsSection只在构建期读取一次AGENTS.md绝不逐轮重读。正是这些约束让角色文件 动态上下文能在不牺牲体验的前提下保持可缓存的静态前缀——这是 ROLE.md 这类角色定义能够规模化服务于多智能体系统的底层原因。八、小结ROLE.md 以极简篇幅定义了 OpenHuman 多智能体系统的行为主轴Master Agent 默认直接处理、只在收益明确时委派、必须自主追踪所有在飞子代理、绝不允许绕过安全/审批/沙箱三层治理。透过 SystemPromptBuilder、orchestrator 配置 与 委托路由指南 可以看到这些抽象原则最终被编码为可编辑的工作区角色文件、编译期合成的delegate_*工具集、异步子代理生命周期工具spawn / continue / list、结构化交接信封以及全链路字节稳定的 KV 缓存友好提示词。理解了这套机制你就理解了 OpenHuman 前端代理何时动手、何时放手、如何收尾、如何守线的完整决策模型。【免费下载链接】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），仅供参考 OpenHuman Master Agent 角色解析：多智能体系统的默认入口、委派策略与动作沙箱
OpenHuman Master 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导读在 OpenHuman 的多智能体架构中Master Agent即orchestrator编排者是用户每天打交道的默认智能体它直接处理日常任务只有在并行、深度推理或专门能力能实质改善结果时才委派给子智能体。本文以仓库中的角色说明文件 src/openhuman/agent/prompts/ROLE.md 为主线结合 SystemPromptBuilder 的提示词装配机制、orchestrator 配置 与 委托路由指南系统讲解 Master Agent 的定位、动作沙箱工具集、direct-first 委派决策树、多子代理并发管理以及安全/审批/沙箱三层边界。读完你将理解 OpenHuman 是如何在系统提示词层面把何时亲自动手、何时委派、如何追踪子代理、如何守住安全底线编码进 Agent 行为模型的。一、Master Agent 是什么默认面向用户的智能体ROLE.md 开宗明义地定义了 Master Agent 的角色定位You are theMaster Agent, the default user-facing agent in a multi-agent system. Handle ordinary work directly; delegate only when parallelism, deeper reasoning, or a specialised capability materially improves the result.这句话拆解出三层含义它是多智能体系统的默认入口——用户的每一条消息首先到达 Master Agent而不是直接分发给某个专家代理直接优先direct-first——普通工作当场处理委派不是默认动作委派有严格触发条件——只有并行parallelism、更深推理deeper reasoning、专门能力specialised capability三者之一能实质性改善结果时才委派。在仓库中这一角色定义对应 src/openhuman/agent/registry/agents/orchestrator/agent.tomlid 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值得注意的配置细节agent_tier chatMaster Agent 处于chat层级是用户交互的叶子层。它不能向另一个chat层代理委派Never spawn yourself只能走chat → worker快速路径或chat → reasoning → worker深度路径。加载器在启动时就会拒绝同层委派运行时 spawn 关卡也会拒绝违反层级或过深的 spawn层级门限制链条最多 3 跳。sandbox_mode sandboxed所有变更操作都发生在动作沙箱中与安全/审批/沙箱层管理每一次变更和命令的角色约束一一对应。temperature 0.4、max_iterations 15偏保守的采样温度与每轮迭代上限符合其稳定完成日常任务的前线定位。二、ROLE.md 如何进入系统提示词身份注入机制ROLE.md 不是一份游离的文档而是系统提示词IdentitySection身份区块的组成部分。在 src/openhuman/agent/prompts/sections.rs 中构建系统提示词时会同步并注入三个工作区文件let all_files: [str] [SOUL.md, IDENTITY.md, ROLE.md];SOUL.md产品人格所有选择加入的代理共享IDENTITY.mdOpenHuman 的身份与核心价值观隐私优先、准确性优于速度、用户赋能、透明度ROLE.md当前代理自身的角色简报——即orchestrator的# Master Agent定位。注释明确指出ROLE.md 的文本曾经被编译进 orchestrator/prompt.md 的# Master Agent/## Core Responsibilities前言现在迁移到磁盘上的工作区文件用户可以直接编辑这些文件来调整代理身份无需重新编译对应 agent.toml 中omit_identity false的注释说明。关键点ROLE.md 只对orchestratorMaster Agent注入。在IdentitySection::build中is_orchestrator判断依据是!ctx.visible_tool_names.is_empty()非编排者代理其子代理 prompt 走for_subagent路径会跳过 ROLE.md——因为专家子代理有自己的角色提示词绝不能被告诉它自己是 Master Agent。系统提示词的完整装配链SystemPromptBuilder::with_defaults()builder.rs定义了 Master Agent 系统提示词的区块顺序IdentitySection—— 注入 SOUL.md / IDENTITY.md / ROLE.mdUserFilesSection—— 注入用户专属的PROFILE.md与MEMORY.md各按USER_FILE_MAX_CHARS截断AgentsInstructionsSection—— 注入AGENTS.md项目指令全局层 项目层每层按BOOTSTRAP_MAX_CHARS封顶并带[... truncated]标记UserMemorySection—— 树摘要器蒸馏的长期用户记忆ToolsSection—— 工具目录P-Format 紧凑签名或原生 function-calling schemaSafetySection—— 安全规则WorkspaceSection—— 工作目录指引DateTimeSection—— 日期时间纪律RuntimeSection—— 运行时信息主机 / OS / 模型。最后由build()统一追加GROUNDING_BODY接地与反幻觉契约和GLOBAL_STYLE_SUFFIX写作风格来自 STYLE.md。整个提示词在会话开始时构建一次后续轮次复用完全相同的字节以保证推理后端的前缀缓存KV cache稳定命中。三、动作沙箱中的正常编码循环Master Agent 的核心工具集ROLE.md 规定 Master Agent 拥有动作沙箱action sandbox中的正常编码循环用file_read/grep/glob/list检查inspect用apply_patch修改已有文件用file_write创建新文件用shell运行聚焦命令用git_operations处理仓库状态。对应到 agent.toml 的[tools] named白名单Master Agent 直接持有这些工具file_read, grep, glob, list, apply_patch, file_write, shell, git_operations,prompt.md进一步明确了使用范式仓库工作走inspect →apply_patch改已有文件/file_write新建→shell做最小验证的闭环git_operations用于读取仓库状态。特别强调Keep code work end-to-end——被要求改代码时必须在同一轮内完成编辑与验证绝不因为任务碰了仓库就委派。需要注意的边界apply_patch是修改已有文件的唯一编辑机制file_write只能创建新文件策略/审批/沙箱的强制逻辑留在工具层this declaration only makes the tools discoverable to the agent。这正是 ROLE.md 最后一句security, approval, and sandbox layers govern every mutation and command; never work around them的配置层落地。四、Direct-first 委派决策树何时亲自动手何时交给专家orchestrator/prompt.md把 ROLE.md 的委派原则扩展成了一份可执行的决策树核心精神是过度委派琐碎工作是这里最常见的失败模式。决策顺序取第一个命中的分支优先级情形动作1无需工具即可回答直接回复2需要已连接服务的实时数据/动作收件箱、日历、文档、票据、发送/检查delegate_to_integrations_agent按 Connected Integrations 匹配toolkit3可用直接工具解决自己干见下表4需要专家按意图路由见下表5任何委派回复蒸馏后再交给用户——子代理输出是原材料不是答案直接工具 vs 委派的对照表节选自 prompt.md工作类型直接工具仅在以下情况委派记忆事实存取memory_recall/memory_store/save_preference多跳记忆树遍历、ingest、笔记调和 →retrieve_memory单条事实查询web_search_tool/web_fetch/http_request多源爬取、对比、深度摘要 →research仓库工作apply_patch/file_write/shell/git_operations独立评审、长时或并行调查 →run_code专家路由表节选ask_docsOpenHuman 行为/设置/文档、schedule_task提醒/定时任务、make_presentation幻灯片、do_crypto钱包/市场强制 read → simulate → confirm → execute、setup_skills技能安装、run_skill运行已装技能、research多源爬取、plan复杂多步分解、review_code代码评审、archive_session记忆归档。这些delegate_*工具不是硬编码的而是由collect_orchestrator_tools在构建期从 agent.toml 的[subagents] allowlist自动合成——每个条目生成一个delegate_*工具工具的 LLM 可见描述直接取目标代理的when_to_use。这让路由决策发生在函数调用选择层而不是藏在一个巨型工具的参数枚举里。结构化交接信封Structured handoffs每个delegate_*工具都接受同一套可选字段防止子代理凭空脑补上下文prompt必填——任务指令子代理对本次对话没有任何记忆objective—— 一句话命名子代理必须产出的结果evidence—— 只允许实际观察过的事实/路径/URL/ID/工具输出禁止猜测constraints—— 必须遵守的硬性要求must_not_assume—— 子代理不得无证据推断的断言expected_output—— 期望返回的形状findings list / patch summary / cited answercitation_requirement——none·file_paths·urls·retrieval_hits·tool_outputsmodel—— 仅本次委派使用的精确模型 ID非必要不填blocking—— 默认false异步仅当结果必须门控本次回复时传true。五、多子代理并发subagent_session_id 与异步生命周期ROLE.md 特别强调Master Agent 可以同时有多个子代理在飞行several sub-agents in flight at once每个子代理有独立的 transcript 和稳定的subagent_session_id跟踪它们是 Master Agent 自己的工作。仓库中的相关工具与机制spawn_async_subagent实现——启动 worker 的唯一方式且总是异步立即返回 task id结果在子代理完成后自动作为新的一轮交付无需轮询或等待continue_subagent实现——恢复因提问而暂停awaiting_user的子代理必须针对精确的task_id重新 spawn 会丢失其全部进度list_subagents实现——重新枚举所有在飞 workerrunning/awaiting_user/completed/failed以及可复用的持久会话是上下文滚动丢失后的恢复手段每轮前缀的[active_subagents]块是事实来源agent type、subagent_session_id、状态其数据来自同一个running_subagents注册表。关键的并发纪律prompt.md按subagent_session_id或 task_id追踪agentId只是 worker 的类型——同时 spawn 的两个 researcher 共享一个类型但状态绝不能合并绝不重复 spawn——已有合适的 worker 在跑就让它跑完扇出fan-out就是多次spawn_async_subagent调用——N 个独立子任务 N 次并行 spawn各自独立返回不要扇出相互依赖的子任务failed的 worker 永远不会产出结果必须如实上报失败而非编造结果异步只用于当前回复不依赖的工作尽力而为的记忆归档、非紧急清理、后台调查结果门控工作必须同步delegate_*阻塞或spawn_async_subagent带blocking: true。六、安全、审批与沙箱边界不可绕过的三层治理ROLE.md 的收尾句是全篇最硬的一条约束The security, approval, and sandbox layers govern every mutation and command; never work around them.仓库中有多道防线佐证安全区块SafetySectionsections.rs为每个代理注入固定规则——不泄露私有数据、不经询问不执行破坏性命令、不绕过监督/审批机制、优先trash而非rm、对外行动前有疑问先问。接地契约GROUNDING_BODY是全员继承的反幻觉底线单一事实来源防止各代理 prompt 各自复制而漂移工具列表即全部能力、绝不编造工具名/参数/ID/路径/URL/引用、数字证据原样保留、失败就说失败、[SUBAGENT_INCOMPLETE]信封要如实转述成果与阻塞原因。工作区沙箱WorkspaceSection不打印硬编码路径而是让代理用pwd运行时确认工作目录——因为文件工具被沙箱限定在 action 目录内写死 workspace 路径曾导致写入后读不回的错位临时文件只能写入被授权的 scratch 目录或$TMPDIR硬编码/tmp/name被阻止。AGENTS.md 路径加固项目层AGENTS.md位于用户/项目可控目录加载器agents_md.rs做了竞态安全处理——Unix 上用O_NOFOLLOW | O_NONBLOCK打开内核级拒绝最终组件符号链接、fstat 校验必须是常规文件、规范化路径必须落在根目录内、读取字节数封顶BOOTSTRAP_MAX_CHARS * 4 1024防止巨文件拖垮提示词构建或耗尽内存。审批门控request_plan_review在多步交互任务执行前暂停回合用户approved后才创建 todo 卡片并执行do_crypto强制 read → simulate → confirm → executeupdate_apply需要显式用户同意。这与 ROLE.md 的approval layers对应。七、KV 缓存稳定性角色提示词背后的工程约束Master Agent 的角色提示词设计处处服务于一个工程目标——系统提示词字节稳定命中推理后端的前缀缓存ROLE.md / SOUL.md / IDENTITY.md 在会话开始时同步并注入一次UserFilesSection注入的 PROFILE.md / MEMORY.md 同样会话冻结archivist 在会话中期的写入只影响下一个会话DateTimeSection不注入具体时间戳避免每次构建变化破坏缓存实时时间由每轮用户消息上的Current Date Time:行提供子代理提示词刻意不含DateTimeSection——同一定义的重复 spawn 必须产出字节相同的系统提示词否则前缀缓存失效接地契约GROUNDING_BODY刻意保持字节稳定无时间/RNG/主机信息并放在提示词尾部作为收尾契约AgentsInstructionsSection只在构建期读取一次AGENTS.md绝不逐轮重读。正是这些约束让角色文件 动态上下文能在不牺牲体验的前提下保持可缓存的静态前缀——这是 ROLE.md 这类角色定义能够规模化服务于多智能体系统的底层原因。八、小结ROLE.md 以极简篇幅定义了 OpenHuman 多智能体系统的行为主轴Master Agent 默认直接处理、只在收益明确时委派、必须自主追踪所有在飞子代理、绝不允许绕过安全/审批/沙箱三层治理。透过 SystemPromptBuilder、orchestrator 配置 与 委托路由指南 可以看到这些抽象原则最终被编码为可编辑的工作区角色文件、编译期合成的delegate_*工具集、异步子代理生命周期工具spawn / continue / list、结构化交接信封以及全链路字节稳定的 KV 缓存友好提示词。理解了这套机制你就理解了 OpenHuman 前端代理何时动手、何时放手、如何收尾、如何守线的完整决策模型。【免费下载链接】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），仅供参考