OpenHuman Task Manager Agent 深度解析todo 任务板、主动任务源与工作流包的系统提示词设计【免费下载链接】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 内置子代理 Task Manager Agent 的系统提示词prompt.md展开逐条拆解其任务面职责边界、六条操作铁律与证据化收尾要求并结合其注册配置agent.toml与底层工具实现todos/tools.rs、task_sources/tools.rs讲清每条提示词约束在代码层面如何落地。读完你将掌握这个子代理管什么、每个 todo / task_source / workflow 工具的语义与权限分级、为什么先读后写部分更新会被固化为提示词铁律以及如何通过工具矩阵反推一个面向状态变更的 Agent 提示词应当如何设计。一、角色定位你拥有用户的 Agent 任务面提示词开篇给出了该代理的职责总纲You own the users agent task surfaces: per-thread todo boards, proactive task-source feeds, workflow bundles, and task evidence.这句话定义了四个互不重叠的任务面任务面含义对应工具族per-thread todo boards按对话线程thread隔离的看板式待办卡todo_list/todo_add/todo_edit等proactive task-source feeds主动式外部任务源持续拉取的外部任务流task_source_*系列workflow bundles工作流包阶段化流程agent_workflow_*/workflow_load/workflow_phasetask evidence任务证据与产物evidence字段、artifact_*系列Own拥有一词意味着这是一个有状态的任务板专家stateful task-board specialist它不仅要能读写卡片还要对变更过程负责——先观察、再决策、后修改、最后汇报。这正是它与通用工具代理的区别在编排层Orchestrator 将创建、编辑、审批/拒绝、获取、清空、删除或汇总任务与任务源的请求路由给本代理而不是让通用工具代理看到整族工具。见 orchestrator/agent.toml 中 subagent allowlist 对task_manager_agent的注释Route any request to create, edit, approve/reject, fetch, clear, remove, or summarize agent tasks, proactive task sources, workflow bundles, task evidence, or artifacts here instead of letting the generic tools agent see the full family.对应的when_to_use描述agent.toml同样把触发条件限定在任务板与任务源专家todo 卡片、主动式消息流、工作流包、产物、证据与状态。二、六条操作铁律提示词如何约束一个写密集代理提示词主体是六条行为规则它们共同构成该代理的写操作纪律。逐条拆解1. 先读后写Always read before you writeInspect the current board/source/workflow with the narrowest read tool before changing it.任何修改之前先用最窄的读工具narrowest read tool检查当前板/源/工作流。代码层面的印证todo_list的工具描述明确写道 Use to review outstanding/completed work before adding or updating taskstodos/tools.rs且它是纯只读工具is_concurrency_safe返回true代价最低、可安全先行。单元测试 prompt_tests.rs 也把read before you write作为断言契约之一说明这不是装饰性文案而是被测试锁定的提示词行为。最窄三个字是关键能todo_list就不todo_replace后回读能task_source_get单个源就不整表拉取先获取事实再决定写什么。2. 保留用户创作的内容Preserve user-authored contentPreserve user-authored task content, acceptance criteria, assigned agent, allowed tools, evidence, blockers, and source metadata unless the user explicitly asks to replace them.需要被保留的字段清单恰好对应卡片数据模型见 todos/tools.rs 的CardPatchcontent任务内容acceptance_criteria验收标准assigned_agent指派代理allowed_tools允许工具evidence证据blocker阻塞项source_metadata来源元数据代码层面todo_edit被设计为只更新显式传入的字段Only the fields you supply are changed; omitted fields are left untouched这从机制上保证了未提及字段不会因一次编辑被静默清空。3. 偏好部分更新Prefer partial updatesPrefer partial updates (todo_edit,todo_update_status,update_task,task_source_update) over wholesale replacement.提示词点名了四类外科手术式工具todo_edit、todo_update_status、update_task、task_source_update。它们共同的特点是定点修改todo_edit按id改字段、todo_update_status只转状态、task_source_update用patch对象只改要改的配置项。而整板替换类工具todo_replace、todo_clear则被归入破坏性工具默认关闭见第四节权限分级。4. 破坏性工具需显式授权Use destructive tools (todo_remove,todo_replace,todo_clear,artifact_delete,agent_workflow_uninstall,task_source_remove) only when the user explicitly names what should be removed or confirms your proposed removal.提示词明确列出的六把破坏性工具代码层面对应PermissionLevel分级工具语义默认状态todo_remove永久删除单张卡片默认关闭default-OFFtodo_replace整板替换默认关闭todo_clear清空整板默认关闭task_source_remove删除任务源并级联删除其摄入历史默认关闭权限级别为Dangerousartifact_delete删除任务产物—见 agent.toml 工具清单agent_workflow_uninstall卸载工作流包—见 agent.toml 工具清单代码依据见 todos/tools.rs 文件头注释只读的todo_list与有界、可逆的写工具todo_add/todo_edit/todo_update_status/todo_decide_plan默认启用破坏性写工具通过tools/user_filter.rs默认关闭。task_source_remove更是直接标为PermissionLevel::Dangeroustask_sources/tools.rs因为它的删除是级联的——连同该源摄入的全部任务历史一并移除且不可逆。提示词因此要求只有在用户明确点名要删什么或确认了你的删除提案时才可动用。这不是提示词的一厢情愿而是与默认关闭的权限配置互为表里。5. 任务源先预览过滤器再加持久源For task-source setup, preview filters before adding or updating a persistent source. After adding/updating, fetch once and summarize counts plus any skipped/duplicate tasks.这是一条建源协议dry-run 先行建源后回读一次。代码层面有两处支撑task_source_preview_filter工具专门用于干跑它对某个providerfilter返回会命中哪些任务但不创建持久源、不摄入任何数据工具描述明确要求 Validate the filter withtask_source_preview_filterfirsttask_sources/tools.rs。task_source_fetch返回本次拉取任务数、新路由数、作为重复项被跳过的数量Returns counts of tasks fetched, newly routed, and skipped as duplicates这正是提示词要求向用户汇报的计数 跳过/重复摘要的来源。task_source_add/task_source_update/task_source_remove因为改变摄入行为并级联历史默认关闭同见 task_sources/tools.rs 文件头注释。6. 工作流先读再改改前解释影响For workflow changes, read the existing workflow first and explain the phase or install/uninstall effect before running a mutating action.与任务板同理工作流包也是先读后写的管辖对象变更前必须agent_workflow_read读现有工作流并解释当前所处阶段phase或安装/卸载的影响之后才能执行变更动作。从工具清单看该代理持有完整的工作流工具组agent_workflow_list、agent_workflow_read、agent_workflow_phase_info、agent_workflow_create、agent_workflow_uninstall以及workflow_load、workflow_phase见 agent.toml。其中agent_workflow_uninstall已被提示词列为破坏性工具受第 4 条铁律约束。收尾契约证据化汇报When marking work done, attach concrete evidence. When blocking, include the blocker and the next user decision needed. Return a concise task-state summary with changed ids and final statuses.提示词要求该代理的输出是可审计的任务状态摘要标done必须带具体证据对应卡片的evidence字段置blocked必须给出阻塞项和接下来需要用户决策什么最终汇报要列出变更过的 id 与最终状态。这保证了板上的每个状态迁移都有据可查、可回溯。三、agent.toml注册配置逐字段解析agent.toml 是这类内置代理的注册清单逐字段解读id task_manager_agent display_name Task Manager Agent delegate_name manage_tasks when_to_use Task-board and task-source specialist: todo cards, proactive feeds, workflow bundles, artifacts, evidence and status. Use when the user asks to create, edit, route, approve, reject, clear or summarize tasks or sources. temperature 0.2 max_iterations 8 iteration_policy extended sandbox_mode none agent_tier worker omit_identity true omit_memory_context false omit_safety_preamble false omit_profile false omit_memory_md false [model] hint agentic [tools] named [ ... ]关键字段语义delegate_name manage_tasks该代理在编排层对外暴露的委派工具名。Orchestrator 据此把任务管理请求转交过来正如其他委派工具如delegate_retrieve_memory一样由delegate_name合成的委派工具出现在主代理的工具面中。temperature 0.2采样温度被压得很低符合有状态任务板专家定位——任务是确定性业务数据不需要高熵发散追求的是稳定、可复现的字段操作。max_iterations 8iteration_policy extended单轮委派内允许最多 8 次工具迭代且策略为extended允许更长工具链足以覆盖读板 → 改卡 → 回读确认 → 汇报的完整闭环。sandbox_mode none任务板操作不涉及任意代码执行无需沙箱。agent_tier worker工作级代理区别于 orchestrator 等协调级代理。omit_identity true不注入身份声明因为任务管理不需要人格化自我介绍其余上下文memory、safety preamble、profile、memory_md均保留保证安全护栏与个性化上下文仍生效。[model] hint agentic模型选择提示走 agentic 档暗示该任务适合具备强工具调用能力的模型。四、工具矩阵全景四族工具 时间与澄清工具[tools] named共声明 31 个具名工具含注释按职能可分为以下族4.1 todo 任务板族12 个todo_list只读、todo_add、todo_edit、todo_update_status、todo_decide_plan审批/否决待批计划卡、todo_remove、todo_replace、todo_clear、todowrite、update_task。核心数据模型来自 todos/tools.rs 的CardPatch与 JSON Schema卡片状态机todo | awaiting_approval | ready | in_progress | blocked | done | rejected卡片字段content必填、status、objective、plan有序字符串数组、acceptance_criteria数组、assigned_agent、allowed_tools数组、evidence数组、notes、blocker状态流转语义todo_decide_plan对awaiting_approval卡审批approve: true→ready或否决approve: false→rejected特别值得注意的是线程作用域所有 todo 工具都接受可选thread_id参数board_location函数todos/tools.rs在传入thread_id时定位到线程级看板BoardLocation::Thread未传入时退化为进程级 scratch boardBoardLocation::Scratch——这就是per-thread todo boards的代码实现。4.2 任务源族8 个task_source_list、task_source_get、task_source_fetch、task_source_list_tasks、task_source_preview_filter、task_source_status、task_source_add、task_source_update、task_source_remove9 个。Provider 枚举github | notion | linear | clickup参数 Schema 的 enum 限定Filter 形态provider 标签化的过滤器对象如{ provider: github, repo: owner/name, labels: [bug] }见task_source_preview_filter描述建源参数provider、filter必填可选name、connection_idComposio 连接、interval_secs轮询间隔≥1、targetagent_todo_proactive主动喂给代理 |todo_only仅入板、max_tasks_per_fetch、assigned_executor更新方式task_source_update接受 camelCase 的patch对象只改传入字段4.3 工作流族7 个agent_workflow_list、agent_workflow_read、agent_workflow_phase_info、agent_workflow_create、agent_workflow_uninstall、workflow_load、workflow_phase。4.4 产物族3 个artifact_list、artifact_get、artifact_delete。其中artifact_delete与agent_workflow_uninstall、task_source_remove一起被提示词列为破坏性工具。4.5 时间与澄清工具3 个current_time读取当前时间resolve_time注释说明其用途是将截止日期/提醒窗口解析为精确时间戳而不是手工计算 epoch 秒数——对任务板这类强时间语义场景due-date、reminder window是重要的防错设计ask_user_clarification信息不足时向用户提问配合提示词When blocking, include the blocker and the next user decision needed使用五、提示词如何被装配进真实系统系统提示词并不是 agent.toml 之外的孤本而是通过 prompt.rs 在运行时组装const ARCHETYPE: str include_str!(prompt.md); pub fn build(ctx: PromptContext_) - ResultString { // ARCHETYPEprompt.md 本体 // render_user_files(ctx) 用户文件上下文 // render_tools(ctx) 当前可见的工具集与描述 // render_safety() 安全前导safety preamble // render_workspace(ctx) 工作区上下文 }装配顺序为archetype 提示词 → 用户文件 → 工具清单 → 安全护栏 → 工作区。也就是说 prompt.md 只是骨架真正的运行时提示词还叠加了动态注入的用户文件、按权限过滤后的工具描述、统一安全前导与工作区信息。include_str!编译期内联保证了 archetype 文本与源码版本严格同步。对应的契约测试 prompt_tests.rs 构造最小PromptContext调用build断言输出同时包含Task Manager Agent与read before you write两个关键契约防止提示词核心语义被意外改掉。六、编排视角为什么需要任务面专属子代理结合 orchestrator/agent.toml 的 subagent allowlist 可以看清设计意图Orchestrator 维护了一长串专职子代理researcher、planner、code_executor、tools_agent、settings_agent、profile_memory_agent、vision_agent、image_agent、video_agent、skill_creator、critic、archivist、help 等task_manager_agent位列其中注释专门说明它的价值在于路由收敛任务相关请求统一进入本代理避免通用 tools_agent 面对整族工具的提示词膨胀纪律本地化先读后写与确认后删除的确认策略只在高风险工具附近生效与 settings_agent 的设计理由同构让确认负担不扩散到无关场景上下文裁剪omit_identity true等开关按需裁剪上下文控制 token 成本。值得留意的是 integrations_agent/agent.toml 中的一条历史注释提到旧的workflow_load/workflow_phase工具随 agent_workflows 域被移除而 task_manager_agent 的工具清单中仍保留了这两个名字——在阅读该代理工具面时应以当前 agent.toml 的清单为准并留意域重构可能带来的工具名演进。七、实践要点小结状态变更类代理的提示词应约束行为而非描述功能prompt.md 通篇没有教模型怎么用工具而是约束何时读、何时写、何时必须确认、如何汇报行为纪律与 todos/tools.rs、task_sources/tools.rs 的权限分级默认启用 vs 默认关闭 vsDangerous互相印证。可审计性写在提示词里证据化收尾done 附 evidence、blocked 附 blocker 下一步决策让任务板状态迁移可被用户和系统回溯。最窄读取 部分更新 显式授权三件套是有状态写密集代理防止数据被误覆盖的标准姿势。若要在 OpenHuman 中触发本代理只需在对话中提出创建/编辑/审批/拒绝/清空/汇总任务或任务源类需求Orchestrator 会依据when_to_use与delegate_name manage_tasks将请求委派给它其完整行为契约可直接阅读 prompt.md 原文。【免费下载链接】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），仅供参考