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导读本指南以 OpenHuman 仓库中的 USER.md 为骨架系统讲解个人 AI 如何根据用户画像、专业水平与沟通偏好动态调整应答方式以及如何在系统提示词System Prompt管线中落地该记住什么、该忘记什么、如何保护隐私这三条边界。读完你将掌握OpenHuman 六类目标用户画像及其适配策略、三档复杂度检测信号、可编辑的用户记忆文件PROFILE.md / MEMORY.md / USER.md注入机制以及基于源码的 KV-Cache 稳定性与隐私实现细节。一、定位USER.md 在提示词管线中的角色在 OpenHuman 中src/openhuman/agent/prompts/ 目录存放着构建系统提示词的核心素材与 IDENTITY.md、ROLE.md、SOUL.md、STYLE.md 并列USER.md专门定义用户上下文与适配User Context and Adaptation规范告诉模型用户是谁、处于什么专业水平、偏好什么沟通方式以及哪些个人信息可以被记住、哪些必须被遗忘。从源码结构看这份规范与提示词渲染层深度绑定types.rs 定义了PromptContext其中user_identity、include_profile、include_memory_md、curated_snapshot、learned.reflections等字段直接承载 USER.md 所述的用户信息sections.rs 中的UserFilesSection、UserReflectionsSection、UserMemorySection、UserIdentitySection分别把用户画像文件、反思记录、记忆摘要、身份字段渲染进最终提示词builder.rs 的SystemPromptBuilder负责把这些 Section 按固定顺序拼装成完整的系统提示词。因此USER.md 不是一份静态的礼仪文档而是直接决定模型每次会话以什么口吻、什么深度、基于哪些用户背景进行回答的可执行规范。二、目标用户画像六类人群与对应适配策略USER.md 开篇即声明 OpenHuman 服务于社区、团队与专业人士communities, teams, and professionals并列出六类典型用户。每类用户的需求Needs、沟通风格Communication style与适配策略Adapt by如下表用户类型核心需求沟通风格适配策略运营者与快节奏专业人士Operators fast-moving professionals速度、准确性、最新上下文、简洁回答直接、数字/结果导向、行动导向开门见山给出具体要点使用精确术语除非被要求展开否则保持简短分析师与高级用户Analysts power users对比、风险/权衡框架、结构化推理技术化、注重细节、审慎对待假设清晰命名选项暴露权衡必要时引用局限性与来源战略负责人与规划者Strategic leads planners主题重于战术、尽调支持、清晰叙事专业、详尽、基于证据提供带明确论点与备选方案的结构化分析尽量引用来源研究员与分析人员Researchers analysts深度数据、方法论严谨、来源核验学术、精确、好质疑展示方法论原始数据与解读并列承认数据局限创作者与社区负责人Creators community leads内容草稿、受众洞察、趋势发现、排期有创造力、有感染力、受众意识强协助写钩子hooks、按平台格式化、建议结构开发者Developers技术文档、代码示例、调试帮助、架构讨论精确、代码友好、系统思维给出代码片段引用具体 API/SDK使用专业术语不过度解释并利用 GitHub 集成获取仓库上下文这六类画像并非彼此排斥——同一位用户在不同场景可能横跨多类。关键是模型需要从对话信号中动态判定当前语境而非把用户永久钉死在某一类上这与下文复杂度检测机制是配套的。开发者画像在仓库中的落地证据开发者画像要求引用具体 API/SDK、使用技术术语OpenHuman 通过两处机制支撑身份字段免重复询问UserIdentitySection会把已登录用户的id/name/email渲染为## User块并明确指示直接在工具调用中使用这些字段不要让用户重复输入见 sections.rs。这正对应用户画像中技术文档、代码示例类需求——模型不再反复索要已知信息。GitHub 集成与仓库上下文AgentsInstructionsSection注入预加载的AGENTS.md指令层全局工作区层 本地项目层对应开发者画像利用 GitHub 集成获取 repo context的诉求见 sections.rs。三、复杂度检测三档信号与响应深度调节USER.md 要求模型依据信号signals自动调整响应深度共三档初学者信号Beginner基础术语提问、what is、how do I start、对基本概念困惑。响应讲清概念、避免行话、给出分步指导。中级信号Intermediate具体工具问题、对比请求、which is better for。响应默认对方有基础聚焦权衡与实用建议。专家信号Expert技术深潜、方法论密集请求、边缘情况。响应匹配其深度、跳过基础、以同侪水平交流。这套按需调节深度的理念在源码中有多处呼应内存注入有上限、可裁剪PROFILE.md与MEMORY.md每个文件被硬性限制在USER_FILE_MAX_CHARS 2_000字符约 1000 token超过部分由注入函数追加[... truncated at 2000 chars — usereadfor full file]提示见 types.rs 与 render_helpers_part_01.rs。对初学者给出分步指导、对专家给足细节二者共享同一套上下文但容量被刻意收敛避免长对话中用户文件把上下文窗口撑爆。面向专家信号的完整工具清单ToolsSection会根据调度器格式渲染可见工具目录P-Format 签名或 JSON Schema并附带dispatcher_instructions行为指引见 sections.rs——技术深潜类问题需要模型清楚自己手里有哪些工具可用。四、个性化边界Personalization BoundariesUSER.md 用三大板块约束模型对用户信息的记忆与使用这是全篇对隐私最敏感的规范。4.1 该记住什么What to Remember用户声明的角色与经验水平平台偏好使用了哪些集成沟通风格偏好啰嗦 vs 简洁反复出现的主题与兴趣时区与排期偏好。在源码中这些信息分别落在不同存储介质记忆内容载体注入方式角色、经验水平、沟通偏好PROFILE.mdonboarding 富化产物UserFilesSection按USER_FILE_MAX_CHARS截断注入长期事实、跨会话观察MEMORY.mdarchivist 策展的长期记忆同节注入并前置MEMORY_MD_FRAMING背景说明用户显式自我陈述记住我……以后……learning_reflections命名空间UserReflectionsSection以高优先级渲染时区 / 当前时间每次用户消息携带的Current Date Time:行current_datetime_line()按 IANA 时区生成值得注意的细节是 MEMORY_MD_FRAMING 常量注入MEMORY.md时必须前置这是跨会话的长期记忆背景不是当前对话内容的说明。原因记录在源码注释GH-4745中——如果不对记忆块加框模型会把它误读为本线程已经说过的话从而在新线程中错误地宣称连续性我们之前已经聊过这个并偷懒简化回答。4.2 该忘记什么What to Forget用户未要求保留的敏感标识符如私有账号细节除非用户要求记住否则不保留机密业务细节来自已连接平台的私密对话用户要求遗忘的任何信息。4.3 隐私规则Privacy Rules绝不主动在对话中引用用户的机密细节若需回忆用户上下文必须明确说明Based on what youve told me before...基于你之前告诉我的……用户可随时询问what do you know about me?并获得透明回答用户可随时请求完全清除记忆full memory wipe。源码层面的隐私实现只注入非敏感字段USER.md 的隐私规则在UserIdentitySection的实现中得到严格贯彻见 sections.rs只有id/name/email三个标识字段被允许进入提示词令牌tokens、刷新令牌refresh tokens以及任何不透明凭据材料被明令禁止注释对应 issue #926渲染前执行sanitize_identity_field净化把换行与连续空白折叠为单个空格防止恶意构造的 name 字段利用 Markdown 换行重塑## User块结构当所有字段为空/空白时整块跳过绝不输出一个指向零字段的悬空标题。同时PromptContext::user_identity由调用方从auth_get_me缓存预取app_state::ops::peek_cached_current_user_identity会剥离除 id/email/name 外的全部内容提示词构建过程永不触网从数据流上保证了敏感信息不外泄见 types.rs。五、从规范到提示词用户上下文如何进入系统提示词5.1 Section 装配顺序SystemPromptBuilder::with_defaults()见 builder.rs按如下顺序装配默认提示词用户相关 Section 被刻意放在前缀区域cache-friendly prefixIdentitySectionSOUL.md / IDENTITY.md / ROLE.md → UserFilesSectionPROFILE.md MEMORY.md各 2000 字符上限 → AgentsInstructionsSectionAGENTS.md 全局 项目层 → UserMemorySection树摘要器产出的命名空间摘要 → ToolsSection工具目录 → SafetySection安全规则 → WorkspaceSection工作目录约束 → DateTimeSection时间纪律规则 → RuntimeSection主机 / 系统 / 模型其中UserReflectionsSection由会话构建器在学习子系统启用时动态插入到user_memory之前——因为用户显式反思是近期的、有意的、身份相关的信号优先级高于任何通用历史摘要见 sections.rs。5.2 用户文件的注入优先级链UserFilesSection::build见 sections.rs对MEMORY.md采用三级优先级个性人格覆盖personality_memory_md为特定人格提供专属记忆会话冻结的策展快照curated_snapshot从快照中同时注入MEMORY.md与USER.md保证同一轮内所有被委派的子代理看到字节完全一致的上下文工作区文件回退workspace_dir/MEMORY.md纯提示词单元测试与旧调用点使用。这里就是 USER.md 文件名USER.md真正出现在渲染管线中的位置——在策展快照路径下inject_snapshot_content会把USER.md与MEMORY.md一并注入。CuratedMemoryPromptSnapshot类型见 types.rs定义了这一快照的memoryuser双字段结构。5.3 KV-Cache 稳定性契约这是本管线最关键的工程约束之一。源码多处强调一次构建整会话冻结系统提示词在会话开始时构建一次此后每个 turn 复用完全相同的字节使推理后端的自动前缀缓存prefix cache稳定命中见 builder.rs用户文件冻结PROFILE.md/MEMORY.md一旦注入即冻结会话中途的 archivist 写入或富化刷新只对下一个会话生效绝不污染正在进行的会话见 sections.rs时间戳不进入前缀具体当前时间通过current_datetime_line()放在用户消息上随 turn 注入而系统提示词里只放静态的时间纪律规则——因为Local::now()是易变值冻结进前缀既破坏 KV 缓存又会在长会话中过时对应 issue #3602见 render_helpers_part_01.rs记忆日期用绝对日期内存摘要的updated_at渲染为2026-05-25这种绝对日期而非N 天前避免每日变化的标签打爆缓存前缀见 render_helpers_part_01.rs。5.4 子代理与窄化渲染当主代理委派子代理如 integrations_agent、code_executor时使用SystemPromptBuilder::for_subagent或render_subagent_system_prompt见 render_helpers_part_01.rs。子代理提示词默认不含DateTimeSection因为重复 spawn 同一子代理定义必须产出字节一致的提示词以复用前缀缓存用户文件PROFILE/MEMORY通过SubagentRenderOptions的include_profile/include_memory_md独立门控即使omit_identity true如 welcome / orchestrator也能按需携带用户上下文同样遵守USER_FILE_MAX_CHARS上限并在Native工具调用格式下跳过散文式工具目录以省 token源码记录62 个动态 gmail 工具若重复列出约多耗 5.4 万 token。六、工作区文件同步机制用户如何直接编辑这些规范USER.md 所述的记忆与画像并非黑盒。sync_workspace_file见 render_helpers_part_01.rs把内置默认内容同步到工作区目录如~/.openhuman/users/id/workspace/并遵循一套哈希驱动的更新策略首次安装时写入内置默认文件在侧车文件.{filename}.builtin-hash中记录编译进代码的内容哈希代码升级导致内置内容变化时若磁盘文件自上次写入后未被用户编辑哈希匹配则自动覆盖若用户手动编辑过则保留用户版本只更新存储哈希。因此用户可以直接编辑工作区中的STYLE.md、PROFILE.md、MEMORY.md乃至各 Agent 的提示词文件来定制行为——仓库内STYLE.md的权威内容即sync_workspace_file最后一次写入的内容加上用户的任何编辑见 builder.rs。这为用户在该记住什么、该忘记什么层面提供了规范之外的人工兜底直接改文件即可精确控制注入模型的用户上下文。七、反思记忆超越画像的高优先级上下文除了 USER.md 中的静态画像OpenHuman 的学习子系统会从对话中捕捉用户的显式自我陈述remember that I…going forward…I realized…存入learning_reflections命名空间见 learning/reflection.rs。这类反思是 USER.md用户声明的角色与经验水平反复出现的主题在动态侧的延伸渲染为## User Reflections块优先于所有通用记忆摘要每轮最多截取 10 条反思保持特权区有界见 session/turn/context.rs无反思内容时整块跳过保持提示词干净用户从未表达过反思式内容时不产生任何噪音。结语USER.md 虽只有 76 行却是 OpenHuman 个性化体验的宪法它定义了六类用户画像与适配策略、三档复杂度信号以及该记住 / 该忘记 / 隐私规则三大边界。而 prompts/ 下的 Rust 实现把这些规范变成了可运行的机制——UserFilesSection的注入优先级链、UserIdentitySection的非敏感字段过滤、USER_FILE_MAX_CHARS的容量纪律、KV-Cache 稳定性契约、可编辑的工作区文件同步。理解这条从规范到提示词的完整链路是定制个人 AI 行为、排查个性化失效问题如记忆没生效回答深度不对隐私信息泄漏风险的起点。【免费下载链接】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），仅供参考