oh-my-pi Magic Keywords 指南用ultrathink、orchestrate、workflowz一句话切换智能体行为【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi本篇技术指南讲解 oh-my-pi⌥ Coding agent with the IDE wired in中的Magic Keywords魔法关键词机制如何在用户提示词中以纯文本关键词为当前回合注入隐藏的、归属用户的指令通知notice从而在不改变消息正文的前提下定向调整模型行为。读完本文你将掌握三个内置关键词ultrathink、orchestrate、workflowz的精确匹配规则、TUI 渐变高亮原理、以及如何通过/settings面板或omp config命令按需开关并深入理解底层源码实现。什么是 Magic KeywordsMagic Keywords 是出现在用户提示词prompt正文中的独立散文单词standalone prose words当它们被识别后系统会为该回合追加一条隐藏的、归属记为用户的指令通知。这相当于一种写在自然语言里的开关你不需要记住斜杠命令或图形界面选项只要在消息里自然写下关键词当前回合的模型行为就会被定向调整而用户消息本身保持原样可见。该功能在 oh-my-pi 中默认启用notice injection is enabled by default。TUI 在编辑输入时会用动画渐变高亮被识别出的关键词发送后的消息气泡中则以静态渐变呈现这一高亮属于纯视觉辅助visual affordance即使在设置中关闭了通知注入高亮也仍然保留。需要特别说明的是关键词只影响包含它的那一回合the instruction applies only to the turn containing the keyword不会改变后续回合的行为也不会污染用户消息的显示内容——隐藏通知是非显示的display: false自定义消息且归属attribution记为用户本人见下文源码分析。三个内置关键词及其效果下表是 oh-my-pi 内置的全部 Magic Keywords 及其效果说明KeywordEffectultrathink追加一条多步推理通知要求模型在响应前仔细思考问题当自动思考automatic thinking开启时还会把当前回合的推理力度直接提升到当前模型支持的最高档。orchestrate追加多智能体编排契约multi-agent orchestration contract界定完整任务范围、并行委派可独立完成的大量子任务、逐阶段验证并持续推进直到请求全部完成。workflowz追加围绕持久化eval内核的agent()、completion()、handle、wait()、workpool()等助手函数构建的确定性多子代理工作流契约适用于广泛调研、评审、迁移与对抗性覆盖。该通知仅在eval与task同时激活时才注入。使用方式把关键词用在提示词散文中的任意位置即可ultrathink about the failure modes before changing this API orchestrate the migration described in docs/plan.md workflowz an adversarial review of the authentication changes关键词不要求出现在句首或特定位置只要是独立的散文单词就会被识别。匹配规则刻意收紧避免误触发Magic Keywords 的匹配规则是刻意设计的目的只有一个防止源码和路径中恰好出现的字符串意外改变智能体行为。核心规则如下必须使用精确的小写拼写。Ultrathink、Orchestrate、Workflowz这类大小写变体都不会触发。关键词必须是独立的散文单词。句末标点和引号可以与关键词紧贴如orchestrate,匹配但字母、数字、下划线、斜杠、反斜杠、连字符、文件扩展名、符号引用和调用语法均不允许紧贴例如orchestrated、orchestrate.ts、foo::orchestrate、orchestrate()都不匹配。围栏代码块反引号或波浪线、行内代码 span、HTML/XML 注释/标签/元素及其内容都会被忽略其中的关键词不会触发任何效果。同一提示词中多个已启用的关键词可以各自追加自己的通知可见的单词仍保留在用户消息中隐藏通知是非显示的自定义消息归属记为用户。指令仅对包含关键词的那一回合生效。匹配规则的源码实现这些规则并非文档承诺而是有明确的代码落地词边界正则magic-keyword-boundary.ts 中的magicKeywordRegex()用左右边界断言构建匹配器——左侧禁止字母/数字/下划线/点/斜杠/反斜杠/连字符及::符号引用(?![\p{L}\p{N}_./\\-])(?!::)右侧禁止紧贴字母/数字/下划线/斜杠/反斜杠/点扩展名及紧随的左括号(?![\p{L}\p{N}_/\\-])(?!\.[\p{L}\p{N}_-])(?!\()并强制u标志。这正是orchestrated、orchestrate.ts、foo::orchestrate、orchestrate()均不匹配的出处。Markdown 感知的散文检测markdown-prose.ts 的maskNonProse()返回一个长度保持不变索引 1:1 映射的文本副本把所有围栏代码块、行内代码 span、HTML/XML 标签及包裹内容替换为空格keywordInProse()先在原文上做一次快速探测再对掩码后的文本做词边界匹配保证检测与高亮只落在用户真正写给模型的散文上同时索引仍指向原文以便着色。检测短路优化magic-keywords.ts 的hasMagicKeyword()先用三次String#indexOf做子串探测命中后再走完整 prose 检查让缓冲区没有关键词这一常见路径只有三次indexOf的开销供编辑器门控 shimmer 定时器使用。通知注入隐藏的、归属用户的自定义消息识别到关键词后oh-my-pi 不会改写用户消息而是注入一条隐藏的自定义消息CustomMessage。以 agent-session.ts 中的#createMagicKeywordNotices()为例开关判定由#magicKeywordEnabled()完成magicKeywords.enabled全局开关与magicKeywords.keyword单项开关同时为真才生效。ultrathink命中时追加customType: ultrathink-notice的消息内容来自 ultrathink-notice.md正文是system-noticeMulti-step reasoning: think carefully through the problem before responding./system-notice。orchestrate命中时只有task工具处于启用状态才会注入否则契约要求的能力不可用通知会被跳过通知内容通过 orchestrate-notice.md 按当前启用的工具列表模板渲染包含 role/rules/workflow/anti-patterns 四段完整契约。workflowz命中时必须同时启用task与eval工具才注入通知由 workflow-notice.md 渲染并按task.batch、scout 是否可用、eval.tools.enabled动态调整内容。所有通知消息均为role: custom、display: false不显示、attribution: user归属用户、带统一时间戳。通知的排队顺序与仅用户回合约束agent-session.ts 表明prompt()中生成关键词通知时传入的是展开后的提示词且仅对用户发起的提示词生效——options?.synthetic合成/智能体发起的回合一律跳过。流式场景下通知会先于用户消息排队注入#queueCustomMessage在前、#queueUserMessage在后保证模型在读到用户消息之前先看到约束指令。测试 agent-session-magic-keywords.test.ts 明确断言了 notice 在 user 消息之前 的排队顺序。queued-messages.ts 中定义了MAGIC_KEYWORD_NOTICE_TYPES { ultrathink-notice: true, orchestrate-notice: true, workflow-notice: true }配合isDisplayableQueuedMessage()、isUserQueuedMessage()等辅助函数隐藏通知不会渲染进队列 UI也不会被误当作普通用户消息恢复进编辑器。ultrathink 与自动思考Automatic Thinking的联动ultrathink的关键词效果不止于追加通知当自动思考开启时它还会旁路难度分类器直接把本回合推理力度设为当前模型支持的最高档。相关实现位于 model-controls.tsif (this.#host.magicKeywordEnabled(ultrathink) containsUltrathink(promptText)) { // 用户显式要求最大思考跳过分类器及 providers.autoThinkingMaxEffort 上限 // 直接跳到该模型支持的最高档 resolved clampAutoThinkingEffort(model, Effort.Max); } else { // 否则走 classifyDifficulty 难度分类器 ... }对应地classifier.ts 的autoEffortCeiling()说明了设计意图auto档默认providers.autoThinkingMaxEffort为xhigh比最高档低一档只有显式的ultrathink才能达到Effort.Max——即 the default keepsautoone tier below the top, so only an explicitultrathinkreachesEffort.Max。与之配套的设置项定义在 settings-schema.tsproviders.autoThinkingMaxEffort取值xhigh默认分类器最高解析到 xhigh或max分类器在模型支持时可能解析到 max。而magicKeywords.ultrathink关闭后即使提示词中包含ultrathink也会退回走分类器——测试 agent-session-magic-keywords.test.ts 验证了这一点。TUI 渐变高亮动画与静态两态Magic Keywords 的视觉反馈由三个各自独立的高亮器协作完成magic-keywords.tsexport function highlightMagicKeywords(text: string, resetTo?: string, phase?: number): string { return highlightWorkflow( highlightOrchestrate(highlightUltrathink(text, resetTo, phase), resetTo, phase), resetTo, phase, ); }三个高亮器链式调用、与顺序无关——较早的 pass 只注入零宽 SGR 转义序列不产生反引号或尖括号不会干扰后续 pass 的 Markdown 掩码。各关键词的渐变配色刻意区分ultrathinkultrathink.ts 采用红→紫全光谱彩虹渐变hue 0..33014 个色标避免绕回红色对应 TUI 提示语 watch it glow rainbow。orchestrateorchestrate.ts 采用青→紫冷色调渐变hue 150..280。workflowzworkflow.ts 采用琥珀→绿暖色调渐变hue 30..150。phase参数取Date.now()推导出的循环值编辑器在输入框聚焦时用它驱动 Claude-Code 风格的动态 shimmer发送后的消息气泡则省略 phase 以呈现静态渐变。高亮的两个挂载点编辑器内custom-editor.ts 的decorateText()先调用hasMagicKeyword()门控 shimmer 定时器#shimmerEnabled()由magicKeywordsEnabled回调决定见 interactive-mode.ts再对文本 span 调用highlightMagicKeywords(span, undefined, phase)完成着色。消息气泡内user-message.ts 同样调用highlightMagicKeywords(value, keywordReset)其中keywordReset是气泡自身前景色的 SGR 序列保证渐变不会渗染到整行其余文字。配置全局开关与单项开关通过 /settings 面板打开会话内的/settings进入Interaction → Magic Keywords分组即可看到四个布尔开关与 settings-schema.ts 的定义一一对应magicKeywords.enabled全局开关门控所有隐藏通知默认true。magicKeywords.ultrathink门控 ultrathink 通知及其最大自动思考覆盖默认true。magicKeywords.orchestrate门控 orchestrate 通知默认true。magicKeywords.workflow门控 workflowz 通知默认true。注意这四个开关目前不会禁用编辑器/消息气泡中的渐变高亮These settings do not currently disable the editor/message gradient。通过命令行 omp config也可以在 shell 中直接配置# 关闭全部 Magic Keywords omp config set magicKeywords.enabled false # 只关闭某一个关键词其余保持启用 omp config set magicKeywords.ultrathink false omp config set magicKeywords.orchestrate false omp config set magicKeywords.workflow false # 查看所有设置及其当前生效值 omp config listomp config set key value会按目标键的 schema 类型解析值字符串并写入全局主 YAML 配置文件omp config list按 tab 分组打印每个设置项及其当前值凭据字段在人类可读输出中掩码为********。关于配置的作用域、优先级与项目级覆盖参见 Settings配置按built-in defaults - global config - project config - CLI overlays - runtime overrides的优先级合并项目级配置位于cwd/.omp/config.yml外加cwd/.omp/settings.json兼容旧格式omp config set的持久化写入只会落在全局文件如需项目级覆盖请直接编辑项目配置文件。工具可用性与通知注入的关系从#createMagicKeywordNotices()可以总结出一条容易被忽略的规则通知是否注入还取决于工具是否启用orchestrate通知只有在task工具启用时才注入编排契约完全围绕task子代理分发展开workflowz通知只有在task与eval同时启用时才注入对应测试 agent-session-magic-keywords.test.ts 分别用空工具列表和仅含mockTaskTool的场景验证了 task 未启用时跳过 orchestrate、task 或 eval 未启用时跳过 workflowz 的行为。实战建议与边界ultrathink用于关键变更前的故障模式分析例如改 API、重构不安全代码之前希望模型先做多步推理在自动思考开启时它还会强制最高推理档适合高风险回合。orchestrate用于跨文件、多阶段的大任务迁移、批量修改等需要先界定范围 → 并行派发子代理 → 逐阶段验证的场景它明确要求子代理不自证、不自检验证与格式化由编排者统一完成。workflowz用于需要持久化 eval 内核的确定性工作流广泛调研、评审、迁移、对抗性覆盖默认以workpool()承载 2 个以上独立工作项仅在依赖耦合或需要 schema 返回时使用单个agent()handle。注意大小写与粘连关键词必须小写且独立成词源码路径、符号引用、调用语法中出现的同名片段不会被识别这是刻意设计避免误触发。隐藏通知不改变可见消息发送后你的消息正文保持原样只是回合上下文里多了一条归属用户的隐藏约束多个关键词可同时生效、各自注入通知。小结Magic Keywords 是 oh-my-pi 在自然语言提示词与确定性行为控制之间架起的一座桥梁三个小写关键词ultrathink、orchestrate、workflowz分别覆盖深度推理、多智能体编排与eval 确定性工作流三类高频诉求配合刻意收紧的散文匹配规则magic-keyword-boundary.ts、markdown-prose.ts、隐藏的用户归属通知注入agent-session.ts以及 TUI 双态渐变高亮magic-keywords.ts把一句话切换行为做得既直观又可靠。无论是想深入理解其实现还是要在日常会话中熟练运用本文给出的源码路径与测试用例agent-session-magic-keywords.test.ts都可以作为进一步探索的起点。【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考