尧图网站建设 
OpenHuman Profile Memory 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/openhumanOpenHuman 将记住用户这件事拆分为多个职责单一的内置代理其中profile_memory_agentProfile Memory Agent专门负责助手的已记忆画像、persona 文件、显式偏好与人物图谱people graph的读写与维护。本文以该代理的系统提示契约prompt.md为主体结合其agent.toml配置、prompt.rs提示组装实现与注册器源码完整拆解这个 worker 级子代理的职责边界、工具白名单、提示词拼装链路以及 Orchestrator 何时会把它委托出去帮助读者理解 OpenHuman 记忆体系中画像管理这一环是如何被约束和执行的。1. Profile Memory Agent 的职责定位profile_memory_agent是 OpenHuman 内置代理集builtin agent set中的一员。在注册器加载器 loader.rs 中它与同目录下的配置一起被登记id: profile_memory_agent, toml: include_str!(profile_memory_agent/agent.toml), prompt_fn: super::profile_memory_agent::prompt::build,prompt_fn指向 prompt.rs 中的build函数——这正是第 3 节要分析的提示组装入口。它的职责定位直接写在配套配置 agent.toml 的when_to_use字段中Profile, persona, preference and people-graph specialist. Use when the user asks to remember or forget something, edit their profile or the assistant persona, inspect memory health, or manage people aliases and contacts.即当用户要求记住/忘记某事、编辑个人档案或助手 persona、检查记忆健康度memory health、或管理人物别名与联系人时应路由给该代理。它通过delegate_name manage_profile_memory暴露为一个名为manage_profile_memory的委托目标。在 OpenHuman 的记忆分工中它与retrieve_memoryagent_memory形成互补从 Orchestrator 配置 orchestrator/agent.toml 的注释可以看出深度记忆树遍历、重叠笔记的协调reconciling、人物图谱与 persona 编辑等复杂记忆操作分别委托给retrieve_memory和manage_profile_memory。2. agent.toml 配置参数逐项解读agent.toml是该代理的行为参数声明完整内容不长逐项含义如下参数取值含义idprofile_memory_agent代理唯一标识注册器与层级校验都以它为准display_nameProfile Memory Agent用户可见的名称delegate_namemanage_profile_memory上级代理如 Orchestrator发起委托时使用的工具名temperature0.2低温度采样画像/记忆写操作要求确定性高、少发散max_iterations8单轮最多 8 次工具迭代限制执行深度sandbox_modenone不启用沙箱——它操作的是记忆存储而非文件系统/Shellagent_tierworkerworker 层级叶子执行器不再拥有开放式 spawn 面omit_identitytrue系统提示中省略 identity 段详见第 3 节组装逻辑omit_memory_context/omit_safety_preamble/omit_profile/omit_memory_mdfalse保留记忆上下文、安全前言、profile 与 MEMORY.md 段trigger_memory_agentalways每次运行都触发记忆代理侧车memory sidecar[model].hintagentic提示模型路由选用 agentic 档位的模型其中agent_tier worker在注册器中不是摆设。loader.rs 的validate_tier_hierarchy在启动期对所有定义做层级校验核心规则是// Worker leaves: no open-ended spawn surface. if def.agent_tier AgentTier::Worker { anyhow::bail!( agent {parent} is a worker tier and must not list {child} in its \ subagents — workers are leaf executors., ... ); }也就是说profile_memory_agent作为 worker 不允许再列出自己的 subagents——它是记忆任务树的叶子节点这从架构上杜绝了画像管理代理再派生子代理的递归失控。[tools]段是这份配置的核心它声明了该代理的工具白名单named列表与prompt.md契约中提到的能力一一对应记忆存储侧memory_store、memory_forget、memory_doctor、memory_tools_list、memory_tools_put偏好侧remember_preference、save_preferencepersona 工作区侧workspace_read_persona、workspace_update_persona、workspace_reset_persona、workspace_init学习/偏好提炼侧learning facetslearning_list_facets、learning_get_facet、learning_cache_stats、learning_update_facet、learning_pin_facet、learning_unpin_facet、learning_forget_facet、learning_rebuild_cache、learning_reset_cache、learning_save_profile、learning_enrich_profile只读的风格画像memory_flavour—— 按 facet 读取编译后的 persona 提炼画像交互侧ask_user_clarification—— 契约中破坏性操作前需确认的落点值得注意的是白名单中没有任何文件写入或 Shell 类工具该代理的写全部指向记忆存储与偏好缓存这与其 worker 定位和sandbox_mode none一致。3. prompt.mdProfile Memory Agent 的系统提示契约prompt.md 是该代理系统提示的原型段archetype内容不长但每条都对应一类真实的记忆变更风险。以下是契约的完整继承与逐条解读。3.1 职责声明You own the assistants remembered profile, persona files, explicit preferences, and people graph.它拥有own四类持久状态助手的已记忆画像、persona 文件、显式偏好、人物图谱。并立即声明总前提Memory and profile changes are persistent. Use this contract:记忆与画像变更是持久的因此后续规则本质上是一份持久化写入守则。3.2 契约规则逐条拆解规则一先读后写。Read current state before writing (memory_recall,workspace_read_persona,learning_list_facets,people_*, ormemory_doctoras appropriate). Usememory_flavourto read the users distilled style/preference profile for a facet (communication, coding_style, stack, workflow, environment, directives, anti_preferences) when a request needs that distilled view rather than a raw facet cache entry.任何写入前必须先用只读工具获取现状并按数据形态选择工具原始记忆用memory_recallpersona 用workspace_read_personafacet 列表用learning_list_facets人物数据用people_*健康检查用memory_doctor。memory_flavour是其中的关键区分点learning 体系把每个 facetcommunication、coding_style、stack、workflow、environment、directives、anti_preferences 七个维度的原始缓存条目编译成一份提炼后的风格/偏好画像。当请求需要的是用户在这个维度上的风格总结agent 视角的 distill 视图而不是原始 facet 缓存条目时应使用memory_flavour。agent.toml 中对它的注释同样明确它是只读的且用于与learning_get_facet互补的场景。规则二只持久化稳定、可验证的信息。Only persist stable user preferences, identity/profile facts, explicit instructions, named contacts, or user-approved corrections. Do not store secrets, transient task details, or unverified guesses.允许持久化的只有五类稳定用户偏好、身份/画像事实、显式指令、具名联系人、用户批准的更正。三类信息被明确禁止入库秘密secrets、临时任务细节、未经核实的猜测。这是画像类代理最重要的数据卫生规则——画像数据库不能变成杂物间。规则三最小化改动保留既有内容。Preserve existing persona/profile content unless the user explicitly asks for a rewrite. Prefer small targeted updates over full replacement.除非用户显式要求重写否则必须保留既有 persona/profile 内容优先做小范围的定向更新而非整体替换。规则四破坏性操作需显式确认。Before destructive changes (memory_forget,learning_forget_facet,learning_reset_cache,workspace_reset_persona), ask for explicit confirmation and name exactly what will be removed.四个具名的破坏性工具——memory_forget、learning_forget_facet、learning_reset_cache、workspace_reset_persona——恰好与第 2 节白名单中的forget/reset类工具一一对应。执行前必须向用户要显式确认并逐一点名将被删除的对象。契约中出现的ask_user_clarification工具正是这一交互的落点。规则五人物记录按需创建。When resolving people, avoid creating new person records unless the user asked to remember a person or alias.解析人物时避免顺带创建新 person 记录只有用户明确要求记住某个人或别名时才建。规则六变更回报带标识。Summarize persisted changes with namespace/key/facet/person/file identifiers.每次持久化变更后总结必须携带 namespace/key/facet/person/file 级别的标识符让变更可追溯、可核对。规则七纯召回请求零副作用。If the request is only to recall context, answer from read tools without mutating state.如果请求只是召回上下文直接用只读工具回答不得产生任何状态变更——读不得顺带写。4. 提示词组装链路prompt.rs 如何拼接最终系统提示prompt.rs 展示了该代理系统提示的完整构建过程build函数按固定顺序拼接五个片段const ARCHETYPE: str include_str!(prompt.md); pub fn build(ctx: PromptContext_) - ResultString { let mut out String::with_capacity(4096); out.push_str(ARCHETYPE.trim_end()); // 1. prompt.md 原型段 // ... let user_files render_user_files(ctx)?; // 2. 用户文件可选 // ... let tools render_tools(ctx)?; // 3. 工具说明可选 // ... let safety render_safety(); // 4. 安全前言 // ... let workspace render_workspace(ctx)?; // 5. 工作区信息可选 // ... Ok(out) }即prompt.md 原型段 user_files 段 tools 段 safety 段 workspace 段。由于agent.toml中omit_safety_preamble false、omit_profile false、omit_memory_md false安全前言与记忆相关段落都会保留而omit_identity true意味着该代理不需要 identity 段——这与它叶子执行器、无对外身份交互的 worker 定位吻合。从PromptContext的渲染器render_safety、render_tools、render_user_files、render_workspace来看各内置代理共享同一套渲染函数提示差异完全由各自的 archetype 文本与omit_*开关驱动——prompt.md就是差异化行为的源头。5. Orchestrator 何时委托给 manage_profile_memory理解这个代理还要看它的上游。Orchestrator 的系统提示 orchestrator/prompt.md 中有一张直接做 vs 委托的决策表WorkDirect toolDelegate only forRecall a fact, store a fact, save a preferencememory_recall,memory_store,save_preferencemulti-hop memory-tree walks, ingest, reconciling overlapping notes →retrieve_memory;people-graph/alias or persona edits →manage_profile_memory即单条事实的召回/存储/偏好保存由 Orchestrator内联完成只有涉及人物图谱、别名管理或 persona 编辑时才委托给manage_profile_memory。orchestrator/agent.toml 的注释进一步解释了这条边界背后的工程原因OKR recall or a remember my Q3 OKR write should not pay a blocking agentic round-trip (over-delegation, #4744) that can hang or — as observed — spawnmanage_profile_memorywhich did 0 tool calls and returned a 0-char result, leaving the writes persistence unconfirmed.历史上曾出现过度委托问题简单写入被交给manage_profile_memory子代理 0 次工具调用、返回空结果导致写入持久化无法确认。因此设计上是store→recall 内联闭环深度记忆树遍历 / 人物图谱 / persona 编辑才委托。这也反过来印证了profile_memory_agent契约的价值它只在确实需要跨 facet、跨 persona 文件、跨人物记录做协调性读写时才被唤起且被契约约束为低温度0.2、有限迭代8 轮、只碰记忆工具的行为模式。6. 小结一个最小权限 持久化守则的画像代理profile_memory_agent的设计可以归纳为三层约束契约层prompt.md先读后写、只存稳定可验证信息、最小化改动、破坏性操作显式确认且点名删除对象、人物记录按需创建、变更回报带标识符、纯召回零副作用配置层agent.tomlworker 层级 temperature 0.2max_iterations 8 纯记忆/偏好工具白名单从参数上固化确定性、有限深度、最小权限结构层loader.rs / prompt.rs启动期层级校验保证 worker 不外挂子代理提示组装链路保证原型段契约始终位于系统提示最前。三层共同保证OpenHuman 中最敏感的一类写入——关于用户本人的持久化画像——始终在可预期、可追溯、可确认的边界内执行。读者若想继续深入可以从 profile_memory_agent 目录、注册器加载器 与 Orchestrator 配置 出发沿记忆工具实现与 learning facets 缓存机制继续阅读源码。【免费下载链接】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 Profile Memory Agent 解析：用户画像与记忆管理的专用子代理契约设计
OpenHuman Profile Memory 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/openhumanOpenHuman 将记住用户这件事拆分为多个职责单一的内置代理其中profile_memory_agentProfile Memory Agent专门负责助手的已记忆画像、persona 文件、显式偏好与人物图谱people graph的读写与维护。本文以该代理的系统提示契约prompt.md为主体结合其agent.toml配置、prompt.rs提示组装实现与注册器源码完整拆解这个 worker 级子代理的职责边界、工具白名单、提示词拼装链路以及 Orchestrator 何时会把它委托出去帮助读者理解 OpenHuman 记忆体系中画像管理这一环是如何被约束和执行的。1. Profile Memory Agent 的职责定位profile_memory_agent是 OpenHuman 内置代理集builtin agent set中的一员。在注册器加载器 loader.rs 中它与同目录下的配置一起被登记id: profile_memory_agent, toml: include_str!(profile_memory_agent/agent.toml), prompt_fn: super::profile_memory_agent::prompt::build,prompt_fn指向 prompt.rs 中的build函数——这正是第 3 节要分析的提示组装入口。它的职责定位直接写在配套配置 agent.toml 的when_to_use字段中Profile, persona, preference and people-graph specialist. Use when the user asks to remember or forget something, edit their profile or the assistant persona, inspect memory health, or manage people aliases and contacts.即当用户要求记住/忘记某事、编辑个人档案或助手 persona、检查记忆健康度memory health、或管理人物别名与联系人时应路由给该代理。它通过delegate_name manage_profile_memory暴露为一个名为manage_profile_memory的委托目标。在 OpenHuman 的记忆分工中它与retrieve_memoryagent_memory形成互补从 Orchestrator 配置 orchestrator/agent.toml 的注释可以看出深度记忆树遍历、重叠笔记的协调reconciling、人物图谱与 persona 编辑等复杂记忆操作分别委托给retrieve_memory和manage_profile_memory。2. agent.toml 配置参数逐项解读agent.toml是该代理的行为参数声明完整内容不长逐项含义如下参数取值含义idprofile_memory_agent代理唯一标识注册器与层级校验都以它为准display_nameProfile Memory Agent用户可见的名称delegate_namemanage_profile_memory上级代理如 Orchestrator发起委托时使用的工具名temperature0.2低温度采样画像/记忆写操作要求确定性高、少发散max_iterations8单轮最多 8 次工具迭代限制执行深度sandbox_modenone不启用沙箱——它操作的是记忆存储而非文件系统/Shellagent_tierworkerworker 层级叶子执行器不再拥有开放式 spawn 面omit_identitytrue系统提示中省略 identity 段详见第 3 节组装逻辑omit_memory_context/omit_safety_preamble/omit_profile/omit_memory_mdfalse保留记忆上下文、安全前言、profile 与 MEMORY.md 段trigger_memory_agentalways每次运行都触发记忆代理侧车memory sidecar[model].hintagentic提示模型路由选用 agentic 档位的模型其中agent_tier worker在注册器中不是摆设。loader.rs 的validate_tier_hierarchy在启动期对所有定义做层级校验核心规则是// Worker leaves: no open-ended spawn surface. if def.agent_tier AgentTier::Worker { anyhow::bail!( agent {parent} is a worker tier and must not list {child} in its \ subagents — workers are leaf executors., ... ); }也就是说profile_memory_agent作为 worker 不允许再列出自己的 subagents——它是记忆任务树的叶子节点这从架构上杜绝了画像管理代理再派生子代理的递归失控。[tools]段是这份配置的核心它声明了该代理的工具白名单named列表与prompt.md契约中提到的能力一一对应记忆存储侧memory_store、memory_forget、memory_doctor、memory_tools_list、memory_tools_put偏好侧remember_preference、save_preferencepersona 工作区侧workspace_read_persona、workspace_update_persona、workspace_reset_persona、workspace_init学习/偏好提炼侧learning facetslearning_list_facets、learning_get_facet、learning_cache_stats、learning_update_facet、learning_pin_facet、learning_unpin_facet、learning_forget_facet、learning_rebuild_cache、learning_reset_cache、learning_save_profile、learning_enrich_profile只读的风格画像memory_flavour—— 按 facet 读取编译后的 persona 提炼画像交互侧ask_user_clarification—— 契约中破坏性操作前需确认的落点值得注意的是白名单中没有任何文件写入或 Shell 类工具该代理的写全部指向记忆存储与偏好缓存这与其 worker 定位和sandbox_mode none一致。3. prompt.mdProfile Memory Agent 的系统提示契约prompt.md 是该代理系统提示的原型段archetype内容不长但每条都对应一类真实的记忆变更风险。以下是契约的完整继承与逐条解读。3.1 职责声明You own the assistants remembered profile, persona files, explicit preferences, and people graph.它拥有own四类持久状态助手的已记忆画像、persona 文件、显式偏好、人物图谱。并立即声明总前提Memory and profile changes are persistent. Use this contract:记忆与画像变更是持久的因此后续规则本质上是一份持久化写入守则。3.2 契约规则逐条拆解规则一先读后写。Read current state before writing (memory_recall,workspace_read_persona,learning_list_facets,people_*, ormemory_doctoras appropriate). Usememory_flavourto read the users distilled style/preference profile for a facet (communication, coding_style, stack, workflow, environment, directives, anti_preferences) when a request needs that distilled view rather than a raw facet cache entry.任何写入前必须先用只读工具获取现状并按数据形态选择工具原始记忆用memory_recallpersona 用workspace_read_personafacet 列表用learning_list_facets人物数据用people_*健康检查用memory_doctor。memory_flavour是其中的关键区分点learning 体系把每个 facetcommunication、coding_style、stack、workflow、environment、directives、anti_preferences 七个维度的原始缓存条目编译成一份提炼后的风格/偏好画像。当请求需要的是用户在这个维度上的风格总结agent 视角的 distill 视图而不是原始 facet 缓存条目时应使用memory_flavour。agent.toml 中对它的注释同样明确它是只读的且用于与learning_get_facet互补的场景。规则二只持久化稳定、可验证的信息。Only persist stable user preferences, identity/profile facts, explicit instructions, named contacts, or user-approved corrections. Do not store secrets, transient task details, or unverified guesses.允许持久化的只有五类稳定用户偏好、身份/画像事实、显式指令、具名联系人、用户批准的更正。三类信息被明确禁止入库秘密secrets、临时任务细节、未经核实的猜测。这是画像类代理最重要的数据卫生规则——画像数据库不能变成杂物间。规则三最小化改动保留既有内容。Preserve existing persona/profile content unless the user explicitly asks for a rewrite. Prefer small targeted updates over full replacement.除非用户显式要求重写否则必须保留既有 persona/profile 内容优先做小范围的定向更新而非整体替换。规则四破坏性操作需显式确认。Before destructive changes (memory_forget,learning_forget_facet,learning_reset_cache,workspace_reset_persona), ask for explicit confirmation and name exactly what will be removed.四个具名的破坏性工具——memory_forget、learning_forget_facet、learning_reset_cache、workspace_reset_persona——恰好与第 2 节白名单中的forget/reset类工具一一对应。执行前必须向用户要显式确认并逐一点名将被删除的对象。契约中出现的ask_user_clarification工具正是这一交互的落点。规则五人物记录按需创建。When resolving people, avoid creating new person records unless the user asked to remember a person or alias.解析人物时避免顺带创建新 person 记录只有用户明确要求记住某个人或别名时才建。规则六变更回报带标识。Summarize persisted changes with namespace/key/facet/person/file identifiers.每次持久化变更后总结必须携带 namespace/key/facet/person/file 级别的标识符让变更可追溯、可核对。规则七纯召回请求零副作用。If the request is only to recall context, answer from read tools without mutating state.如果请求只是召回上下文直接用只读工具回答不得产生任何状态变更——读不得顺带写。4. 提示词组装链路prompt.rs 如何拼接最终系统提示prompt.rs 展示了该代理系统提示的完整构建过程build函数按固定顺序拼接五个片段const ARCHETYPE: str include_str!(prompt.md); pub fn build(ctx: PromptContext_) - ResultString { let mut out String::with_capacity(4096); out.push_str(ARCHETYPE.trim_end()); // 1. prompt.md 原型段 // ... let user_files render_user_files(ctx)?; // 2. 用户文件可选 // ... let tools render_tools(ctx)?; // 3. 工具说明可选 // ... let safety render_safety(); // 4. 安全前言 // ... let workspace render_workspace(ctx)?; // 5. 工作区信息可选 // ... Ok(out) }即prompt.md 原型段 user_files 段 tools 段 safety 段 workspace 段。由于agent.toml中omit_safety_preamble false、omit_profile false、omit_memory_md false安全前言与记忆相关段落都会保留而omit_identity true意味着该代理不需要 identity 段——这与它叶子执行器、无对外身份交互的 worker 定位吻合。从PromptContext的渲染器render_safety、render_tools、render_user_files、render_workspace来看各内置代理共享同一套渲染函数提示差异完全由各自的 archetype 文本与omit_*开关驱动——prompt.md就是差异化行为的源头。5. Orchestrator 何时委托给 manage_profile_memory理解这个代理还要看它的上游。Orchestrator 的系统提示 orchestrator/prompt.md 中有一张直接做 vs 委托的决策表WorkDirect toolDelegate only forRecall a fact, store a fact, save a preferencememory_recall,memory_store,save_preferencemulti-hop memory-tree walks, ingest, reconciling overlapping notes →retrieve_memory;people-graph/alias or persona edits →manage_profile_memory即单条事实的召回/存储/偏好保存由 Orchestrator内联完成只有涉及人物图谱、别名管理或 persona 编辑时才委托给manage_profile_memory。orchestrator/agent.toml 的注释进一步解释了这条边界背后的工程原因OKR recall or a remember my Q3 OKR write should not pay a blocking agentic round-trip (over-delegation, #4744) that can hang or — as observed — spawnmanage_profile_memorywhich did 0 tool calls and returned a 0-char result, leaving the writes persistence unconfirmed.历史上曾出现过度委托问题简单写入被交给manage_profile_memory子代理 0 次工具调用、返回空结果导致写入持久化无法确认。因此设计上是store→recall 内联闭环深度记忆树遍历 / 人物图谱 / persona 编辑才委托。这也反过来印证了profile_memory_agent契约的价值它只在确实需要跨 facet、跨 persona 文件、跨人物记录做协调性读写时才被唤起且被契约约束为低温度0.2、有限迭代8 轮、只碰记忆工具的行为模式。6. 小结一个最小权限 持久化守则的画像代理profile_memory_agent的设计可以归纳为三层约束契约层prompt.md先读后写、只存稳定可验证信息、最小化改动、破坏性操作显式确认且点名删除对象、人物记录按需创建、变更回报带标识符、纯召回零副作用配置层agent.tomlworker 层级 temperature 0.2max_iterations 8 纯记忆/偏好工具白名单从参数上固化确定性、有限深度、最小权限结构层loader.rs / prompt.rs启动期层级校验保证 worker 不外挂子代理提示组装链路保证原型段契约始终位于系统提示最前。三层共同保证OpenHuman 中最敏感的一类写入——关于用户本人的持久化画像——始终在可预期、可追溯、可确认的边界内执行。读者若想继续深入可以从 profile_memory_agent 目录、注册器加载器 与 Orchestrator 配置 出发沿记忆工具实现与 learning facets 缓存机制继续阅读源码。【免费下载链接】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），仅供参考