人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址https://gitcode.com/gh_mirrors/oh/oh-my-openagent点击查看免费下载导读ultrawork是 oh-my-openagent 仓库中 omo-senpi 技能体系packages/omo-senpi/skills/里的一个“绑定型模式指令”binding directive它的定位不是教程而是一份Agent 在 ultrawork 模式下必须逐条执行的运行契约。本文以该指令全文为骨架结合仓库中与其配套的mass-ulwDAG 编排、ulw-loop目标循环、ulw-plan规划、ulw-research饱和研究等技能与相关脚本为你逐段解析分层定级Tier如何决定证据强度、四条手工 QA 通道如何落地、引导Bootstrap四步、PIN→RED→GREEN→SURFACE→CLEAN 执行环、等待纪律、验证门Verification gate以及停止规则。读完后你将能够把“说清楚做完了”变成“用可复现证据证明做完了”并理解这套机制在当前仓库中的实现位置。一、这份文档是什么从“提示词”到“运行指令”在仓库中packages/omo-senpi/skills/ultrawork/SKILL.md的 frontmatter 声明自己为name: ultrawork description: The binding ultrawork-mode directive. This file IS the directive; read it only when ultrawork mode is requested and the directive is not already in the conversation.description里的关键词是binding绑定与directive指令这份文件本身就是指令而不是对指令的说明。它在packages/omo-senpi/skills/AGENTS.md中被标注为“Senpi-native ultrawork directive source”其正文由构建脚本 embed-directive.mjs 嵌入到src/components/ultrawork/generated-directive.ts该技能目录由plugin/scripts/sync-skills.mjs以原生注册表方式原样发布。也就是说技能目录中的SKILL.md是源生成的 TypeScript 常量是被注入到 Agent 会话的形态二者必须保持一致。进入模式后Agent 回应的第一行必须是字面量ULTRAWORK MODE ENABLED!# Output discipline一节并遵循[CODE RED] Maximum precision. Outcome-first. Evidence-driven.的基调。指令的核心立场可以用一句话概括“测试通过”永远不等于“做完了”——一套全绿的测试只证明单元级契约成立不能证明用户可见的行为真的工作见# Goal。二、Tier 分层LIGHT 与 HEAVY 决定证据与评审强度指令要求在任何工作开始前对“本次会话自己的变更集”change set做一次且仅一次的分层判定# Tier triage把判定结果连同理由写进 notepad并且“只升不降”ratchet up only。维度LIGHTHEAVY触发条件走已知模式、无开放设计决策单点 bugfix、照既有模式加端点、校验规则、查询微调、常量/文案、启动或指挥另一个会话能指认出的硬事实新模块/层/领域模型/抽象auth、安全、会话或权限代码构建或改动外部集成API、队列、支付、webhook注意“调用已有 API”不算DB schema 或迁移并发、事务边界或缓存失效跨领域重构用户明确要求“仔细/彻底/先设计”或要求评审成功标准1–2 条happy path 最有风险的一个边界3 条以上happy、edge、regression、adversarial risk每条都要有自己的通道场景与两份证据评审方式notepad 中记录 self-review当“验证门”触发时进入 reviewer loop直到无条件通过判定的关键规则“交接给别的会话/线程/被委托循环的工作”属于 payload由对方会话承担过程开销发起它同步、提示、创建、验证属于 control-plane 工作按 LIGHT 计。不确定就取 HEAVY运行中途冒出 HEAVY 事实要立即升级并重做 LIGHT 路径跳过的部分绝不允许中途降级。层级只改变过程的规模不改变诚实度两个层级都要捕获证据、记录清理回执cleanup receipt、遵守 never-suppress 规则。该分层逻辑在配套的 define-goal.md 中有同一标准的镜像LIGHT 1–2 条、HEAVY 3 条覆盖 happy/edge/regression/adversarial可以对照阅读。三、手工 QA 通道真实表面Real Surface的四种证明方式指令用一张通道表# Manual-QA channels规定“证据必须来自真实表面”并把“通过哪条通道、用哪个精确命令”作为每个场景的前置声明。四条通道HTTP call—— 用curl -i或 PlaywrightAPIRequestContext打真实端点捕获状态行 请求头 响应体。Terminal / TUI—— 通过 xterm.js 网页终端驱动真实 pty 并截图证明。仓库内直接提供了现成工具bun script/qa/web-terminal-visual-qa.mjs --title surface --command cmd --input {Enter} --evidence-dir dir脚本位于仓库根目录的 script/qa/web-terminal-visual-qa.mjs其配套测试为 web-terminal-visual-qa.test.ts。注意tmux send-keys只允许做启动冒烟严禁用tmux capture-pane取证——它会劣化 truecolor 与宽字符宽度破坏颜色/布局/CJK 证据。Browser use—— 从 eval JS 内核驱动真实页面Bun ≥ 1.4 上优先new Bun.WebView()Linux/Windows 需本地安装 Chrome/Chromium/Edge需要 Chrome 语义、stealth、trace 或 auth 时编写playwright-core脚本以chromium.launch({ channel: chrome })驱动本地 Chrome。绝对禁止在用户真实主浏览器配置上清除 cookies/cache/site data——需要登录态时先用rsync -a profile/ tmp-clone/克隆一份配置指向它。Computer use—— 面向桌面/GUI 应用时用 OS 级自动化computer-use agent、AppleScript、xdotool 等驱动运行中的应用3D/空间类工作每次改动后从多个角度渲染并与参考对比。指令还强调“辅助表面”CLI stdout、DB 状态 diff、解析后的配置 dump对 CLI 或数据形态的标准是一等公民证据但--dry-run、打印命令、“should respond”“looks correct”一律不算数。每个场景必须写出确切的工具与确切的调用字面命令 / API 调用 / 页面动作 具体输入 一个二元可观测的 PASS/FAIL 判定例如写curl ...而不是“run the endpoint”。四、Bootstrap 四步任何其他工作之前必须完成指令的引导阶段有严格顺序# Bootstrap缺一步都是缺陷0. 调查技能 → 收集上下文 → 定级先遍历已加载的技能列表读每个可能相关技能的 description显式决定本任务使用哪些技能并在 notepad 里写下一行理由——“跳过适用技能就是缺陷”。随后发出第一波发现见下文“Finding things”记录当前问题、带证据的决策点与理想终态再对变更集做 Tier 定级。只有存在未解决的设计决策模块边界不清、多种可行分解、多文件构建依赖顺序不明时才用task派生规划子代理已知流程再长也不需要规划器直接在 notepad 规划。1. 用create_goal注册目标绑定契约目标必须通过create_goal工具注册——不能是散文、notepad 或计划。调用时只传objective不传status。objective 要写全细节每个交付物、每个命名的表面、用户声明的每个约束。标准清单必须在目标中前置列出一行“用户可见交付物” 层级与理由按层级定规模的 success criteria每条命名其精确场景与二元可观测值、以及将捕获的证据工件每条标准的 failing-first 证明实现前捕获 RED、实现后 GREEN一行 WHEN TO STOP“Ill stop right away when 精确可观测状态”。目标没有数量预算上限禁止编造数值预算。等待目标结果属于“合法的回合结束”而非blocked只要有 monitor、待处理子通知或定时续跑通道在值班就结束回合等它触发update_goal标blocked只在真正僵局无任何续跑通道且连续多个目标回合同样阻塞时使用。2. 打开持久 notepad运行NOTE$(mktemp -t ulw-$(date %Y%m%d-%H%M%S).XXXXXX.md)并回显路径。初始化固定章节并只追加、永不重写# Ultrawork Notepad — one-line goal Started: ISO timestamp ## Plan (exhaustively detailed) ## Success criteria QA scenarios ## Now ## Todo ## Findings ## Learnings每次发现、决策、命令、RED/GREEN 捕获与 QA 工件路径都要立即追加。notepad 是“超出上下文窗口仍存活”的持久记忆任何压缩或上下文丢失Context compacted通知等后先完整重读整个 notepad再干别的从## Now恢复绝不从头重规划。3. 先写计划文件再注册 todo 清单多步工作先写计划文件独立计划放.omo/plans/slug.md否则放在 notepad 的## Plan。然后用 senpi 的todo工具把每个原子步骤镜像进清单init分阶段列表start/done/append/drop驱动每次状态迁移。步骤文本编码 WHERE/WHY/HOW/VERIFYGOODfoo.test.ts: Write FAILING case invalid-email→ValidationError for criterion 2 — verify by RED with assertion msgBAD“Implement feature”“Fix bug”“Add tests later”五、Finding things先查证不靠记忆指令明确“绝不凭记忆猜测”——用正确工具定位并在声称或修改前重读# Finding things。发现顺序符号类问题走 LSP定义、引用、重命名影响、工作区符号、诊断用内建lsp_*工具而非文本搜索编辑后跑诊断错误阻塞。结构形状调用/函数/类/导入模式、codemod用捆绑的ast-grep技能sg$VAR/$$$元变量或ast_grepMCP 服务器search/rewrite/scan。ast-grep MCP 的实现位于 packages/ast-grep-mcp。仓库文本/字节/文件名/历史/shell 输出rg、rg --files、git与原生工具。跨文件的架构/流程/爆炸半径并行扇出explore后台代理armed with ast-grep再综合——仓库不存在预计算的符号图结构搜索 LSP 引用 代理综合代替它。仓库外的研究库/API/文档/Web走librarian陌生布局走explore只读、绝对路径两者都放后台跑同时继续干活。六、并行执行eval JS 是默认表面# Parallel execution规定一步中相互独立的部分读、搜、符号查询、git/lsp_*/web 查询、task(...)派生默认用eval且language: js的一个单元格完成而不是一串串的一次性调用。核心要求若 eval 工具报告 Bun 内核bun-1-4技能已列出先读该技能用其内建Bun.$处理单元格内能结束的命令、Bun.Glob、fetch而非 shell 出去。每个独立查询通过Promise.all/parallel(thunks)一次全部触发用真实控制流按情形if/else、遍历所有目标的for、逐项的try/catch喂给后续调用的结果可以在同一单元格内串行。编辑、副作用命令、部署、审批等“输入还没见过”的调用一次只做一个动作每个都观察后再做下一个。单元格运行前先说出它应产出的状态返回后对比证据把失败或缺失的项原样保留——用try/catch把失败变成缺失行会让聚合结果撒谎。内核忙且需要另一个语言时跳到py绝不用bash python3 -c。并行扇出task(...)子代理run_in_background: true各自路由到匹配的category仅在写作用域不相交时安全——没有两个子代理编辑同一批文件重叠单元交给 team每个成员独立 worktree或串行。七、执行环PIN → RED → GREEN → SURFACE → CLEAN核心循环# Execution loop直到每条成功标准 PASS 且证据捕获为止选下一条标准 → 标 in_progress → 更新 notepad## Now。PIN RED重构可能掩盖回归的行为先写特征化测试pin在未改动代码上通过。然后通过“最便宜且忠实”的通道捕获 failing-first 证明有 seam 走单元测试、行为在接线层走集成/e2e、无测试 seam 时用标准自身的真实表面场景捕获失败。失败必须“败得对”不是语法错误、不是缺 import把 RED 输出贴进 notepad此时不写任何生产代码。TEST-ONLY 目标为已正确行为补回归覆盖没有天然 RED 与生产改动是唯一豁免。用变异证明替代临时强制复现每条新断言所指的回归回退修复提交或破坏 seam绝不提交捕获断言失败再还原变异并捕获 GREEN。在变异下仍绿的断言不是覆盖。PROSE 目标prompt、SKILL.md、规则、markdown措辞不是行为——绝不 pin 句子、短语有无或字数。只 pin 机器消费的值解析后的 frontmatter 字段、hook 抓取的中毒 token、经过真实校验器的 JSON 样例或两份发行副本间的toBe相等。纯散文改动没有 seam靠 review QA-by-read 交付不写测试——文本 grep 是伪装覆盖。GREENTEST-ONLY 跳过——还原变异即 GREEN写最小生产改动使 RED→GREEN重跑证明并捕获 GREENGREEN 远超标准规模说明证明太粗要拆分。SURFACE自己端到端跑标准命名的真实表面证明通道表把工件路径贴进 notepad。CLEANUP成对绝不跳过QA 场景一产生资源就登记清理 todo。所有运行时工件必须在步骤完成前拆除服务 PIDkill后kill -0失败、tmux会话tmux kill-session -t ulw-qa-criterion后用tmux ls验证、浏览器/Playwright 上下文.close()、容器docker rm -f、占用端口lsof -i :port为空、临时 socket/文件/目录删掉mktemp路径、QA 专用环境变量。在 notepad 证据旁追加一行清理回执例如cleanup: killed 12345; tmux kill-session ulw-qa-foo; rm -rf /tmp/ulw.aB12cD。无回执 → 标准保持 in_progress。验证变更文件的 LSP 诊断干净 本标准的测试范围全绿本轮无新增 skip/xfail。校验命令只在输入变化时重跑完整套件只跑一次且放在最终消息之前。标记 completed追加非显而易见的发现/学习。每次增量后重跑可能受影响的场景最终消息前重跑全量一次内联记录 PASS/FAIL 证据路径 清理回执。同一标准的 RED 与 GREEN绝不并行。这条“证据绑定”哲学在 full-workflow.md 中有更强约束证据绑定捕获时的树git rev-parse --short HEAD^{tree}树不变的重写/改基保持有效树变了必须重跑绝不允许给旧证据重新贴标签。八、等待纪律订阅永不睡眠# Waiting discipline是整套契约中最反直觉的一条每个你本来会去轮询的条件都要在启动工作的同一个 eval 单元格里注册订阅命令或门tool.monitor({ description, command, filter })如until cond; do sleep 5; done; printf READY\n文件tool.monitor({ description, path, event })。monitor与bash不在 eval 存在时的直接工具列表里单元格内的tool.monitor是唯一形式。构建/安装/测试跑完、CI 或 PR 转绿、部署落地、日志行、文件出现、端口打开、其他会话变化——匹配行以注入事件到达而你继续干活。禁止sleep、定时重试、重复轮询、等待--watch或派生进程的单元格、为“观察”而派生的子进程——每个都会把整个上下文反复灌给模型或把 JS 内核卡到单元格上限被杀。订阅后做根工作或结束回合空闲会话总是会被唤醒。并且要不待提示地从用户意图武装 monitor“check the deploy”监视其状态“I pushed a fix”监视那次 CI“另一个会话在做 X”监视其输出。只有做中途决策时才允许 peekbash_output、task_output({ mode: tail })。九、委托task、team 与子代理契约task 工具与精选只读代理通过task委托prompt外加恰好一个category走 omo 类别路由器或subagent_type直接代理。四个零配置精选只读代理——explore、librarian、plan-consultant、plan-reviewer。run_in_background: true用于并行波load_skills给子代理武装技能用task_output读回、task_send引导、task_cancel终止/tasks列出本次会话派生的任务。精选代理是只读、进程内的不能写文件且被拒绝作为 team 成员——只能走task绝不能走team_create。team_create只有两种条件同时成立才建队来自 ulw-loop/SKILL.md 的指导原则同样适用于 ultrawork工作单元的写作用域重叠到你无法干净切分同模块/契约/迁移一方的发现会改变另一方该做什么同时跑确实更快各自独立成块且没有一方只是等待另一方输出。两个仅消费前者输出的单元是“序列”而非“团队”。独立单元默认并行后台task单一内聚单元自己做。团队模式下每个成员一个 git worktree绝不允许共享 checkout按工作单元逐个合并各自证据捕获、门全绿即落地不等最慢的兄弟冲突是 lead 的职责。子代理执行与状态机每个子代理 prompt 以TASK: 祈使句任务开头命名DELIVERABLE、SCOPE、VERIFY、STOP WHEN并声明“可执行不是上下文交接”只含必要上下文。长任务要求WORKING: task - current phase长时间停顿前与BLOCKED: reason仅当进展不可能。沉默不是终态运行中的子代理还活着其完成会唤醒你所以结束回合而不是轮询它活跃子代理未清空时不得定稿。子代理仍活跃时禁止把 todo 标done也禁止在审计/研究/review 被整合或明确判定无结论前开始依赖工作。DAG 编排mass-ulw的衔接当工作带真实依赖C 需要 A 和 B 先完成时ultrawork 会衔接 mass-ulw/SKILL.md 的workflow原生工具声明式定义key幂等/name/nodes每个节点含id、自包含英文prompt、路由category与可选dependsOndependsOn只是排序绝不替下游注入上游输出因此每个 prompt 必须独立成立。DAG 必须在 eval 单元格内构建运行JS SDK 位于OMO_DAG_SDK_ROOT。生命周期动词start/attach/snapshot/wait/cancel单节点恢复用retry重跑失败/取消节点completed 节点复用缓存、send就地引导运行中或复活常驻的已完成子代理、amend按指纹 diff 只重跑变更节点及其传递依赖。run 被 journal 化会话中途死亡run 暂停而非丢失重启后恢复并复用已完成节点输出。定义图之前必须完整阅读其规划参考 planning.md。十、验证门Verification gate有触发条件的评审评审每次要消耗一整次额外代理运行因此“由书面计划挣得而非由野心触发”# Verification gate。仅当一次ulw-plan运行产出了本工作的计划文件且发生任何 apply 时才触发Tier 为 HEAVY或用户要求严格/严肃/规范评审。没有计划文件就没有评审者再重的裸ulw运行也在 notepad 记录 self-review重读 diff、跑诊断、逐条确认证据、用一行说明 tier 为何成立。plan-reviewer与plan-consultant是计划门控评审者而非通用帮手。触发后的程序NON-NEGOTIABLE用task派生自包含评审任务的评审子代理subagent_type: plan-reviewer只读评审或需要跑代码时用评审形状的category传入目标、成功标准、场景证据、完整 diff、notepad 路径。逐条亲自核实评审关切。只有“点名了某条成功标准而证据未满足”的关切才阻塞未引用标准的关切记为 notes附一行理由由你判定修或拒。修复每条引用标准的阻塞项只重跑受修复影响的场景 QA为增量捕获新证据更新 notepad。最多两次把增量 diff 重新提交给同一个评审者仅剩 notes 的批准计为批准。批准即宣告完成。两次重审后仍有引用标准的阻塞项用 question 工具带着未决阻塞项作为选项询问用户遵守下面的“2 次尝试”规则不再循环。配套的ulw-loop对最终聚合目标还有一道 full-workflow.md 定义的 Final Quality Gate先在冻结的 HEAD 上重跑所有树已变化的 PASS 标准manualQa.by固定为字面量main-session再派生一个门评审者依次尝试category: deep→unspecified-high→unspecified-low最后用agentToolkit.checkpoint({ goalId, status: complete, evidence, qualityGateJson })收口。十一、提交与约束提交纪律频繁提交每个已验证增量RED→GREEN 其证据一个原子提交绝不做“结束时的巨型提交”每个提交自身可构建、测试全绿最终分支无 WIP。撰写消息前先读历史并模仿git log --oneline -20加git log -5 -- touched paths匹配观察到的约定subject 形状、scope 名、消息语言、正文风格、提交粒度。默认 Conventional Commitstype(scope): imperative——feat/fix/refactor/test/docs/chore/build/ci/perf仅当历史没有更强的本地约定时使用。有计划文件时最终提交 footer 写Plan: .omo/plans/slug.md。仅在用户明令禁止提交时跳过——改为 stage 草拟消息。约束清单# Constraints每个行为变更都要在生产改动之前通过最便宜忠实的通道捕获 failing-first 证明先写了生产代码就 STOP、回退、捕获失败、重做。豁免仅限纯格式化、纯注释、无行为差别的依赖升级、纯改名移动——每项都要在## Findings说明理由。无法为其所指回归失败的测试不是证据mock 调用断言、钉死常量、等于默认值的 fixture、从被测输出反推的期望值都不算宁可要无新测试的真实表面证明也不要同义反复的测试。重构先写特征化测试钉住当前可观测行为旧代码上全绿、全程保持全绿。每个单元做最小正确改动但途中遇到的每个缺陷都是本轮的注册工作预存 bug、失败测试、过期文档、错误指引都要用 todo 成功标准注册ulw-loop 下是 subgoalulw-execute 下是计划复选框workflow 内是节点并修到理想状态绝不推迟为 follow-up。被委托单元的作用域要硬worker 报告缺陷orchestrator 注册它。绝不压制 lint/错误/测试失败绝不为刷绿删除、skip、.only、.skip、xfail或注释测试。绝不从推断宣称完成——只能从捕获的证据。十二、输出纪律与停止规则输出纪律第一行字面量ULTRAWORK MODE ENABLED!引导后1–2 段计划摘要 notepad 路径。执行中只呈现状态变化RED 捕获、GREEN 捕获、带证据路径的场景 PASS/FAIL、评审者裁决。最终消息结果 成功标准核对清单带证据引用 notepad 路径 评审者批准若门触发 提交列表sha subject。除非被要求不做逐文件 changelog。停止规则每次结果后自问用户的核心请求现在能否带着可用证据回答能就立刻回答——跳过一切不增加证据的检索、仪式或验证。停止目标每个场景 PASS 且有捕获证据、每条清理回执已记录、notepad 最新、若门触发评审者无条件批准。但高于一切的决定性检验是完成条件是否在根本上满足、用户的问题是否在可观测行为上真正被解决没有就还没做完满足了就交付并停止——不留恋、不加验证轮、不做打磨循环。停止目标之后的工作是范围蔓延不是勤勉。残留 QA 状态存活进程、tmux会话、浏览器上下文、占用端口、临时文件/目录没做完拆除、记录回执、再继续。一步连续 2 次相同失败先用 question 工具把尝试过的东西摆给用户再重试问题超时就按最佳判断继续。2 轮并行探索都没有新有用事实停止探索行动。十三、与相邻技能的协作边界ultrawork 指令在 omo-senpi 技能体系中与其他技能明确分工见 skills/AGENTS.md 的 “WHERE TO LOOK” 表技能与 ultrawork 的关系mass-ulw依赖序 DAG 编排ultrawork 的目标/标准/证据/检查点由它自身契约掌控mass-ulw 只负责定义、驱动、恢复每个 phase 的 runulw-loop目标循环与持久账本.omo/ulw-loop/session-id/ledger.jsonl当它伴随 ultrawork 时其契约取代 ultrawork 引导的第 1–3 节loop SDK 拥有目标状态loop 账本就是 notepadloop CLI 的检查清单就是计划ulw-plan只读规划咨询产出决策完备的计划文件后验证门才可能触发评审者ulw-research饱和研究与 ultrawork 组合时研究本身是交付物把每个研究轴映射为一条成功标准其中一条关键衔接规则“mass-ulw 的 run 一旦 settle其输出的验证指令是 TREAT-AS-FALSE”——节点和 run 的完成声明在对照捕获证据证明之前一律视为假这与 ultrawork 的“测试全绿≠做完了”是同一条哲学的两种表达。结语从“声称完成”到“证明完成”packages/omo-senpi/skills/ultrawork/SKILL.md提供的是一套把编码 Agent 的完成判据从“我做了”迁移到“证据在这里”的可执行协议Tier 决定证据与评审的规模四条通道决定证据的真实表面Bootstrap 四步与 notepad 决定崩溃后可恢复性PIN→RED→GREEN→SURFACE→CLEAN 环决定每次变更的可证明性等待纪律决定长任务不休眠、验证门决定重活不裸奔、停止规则决定何时真正收手。理解这份指令就等于理解了 oh-my-openagent 这套技能体系中所有“ulw”前缀能力的共同地基。赞分享人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址https://gitcode.com/gh_mirrors/oh/oh-my-openagent点击查看免费下载相关推荐oh-my-openagent 中的 Ultrawork 模式一套以证据为锚的编码 Agent 执行协议深度解析oh my openagent 中的 Ultrawork 模式一套以证据为锚的编码 Agent 执行协议深度解析 导读 Ultrawork 模式缩写 ULW人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排oh-my-openagent Ultrawork 模式 GPT 变体提示词解析激活协议、决策框架与证据驱动执行规范oh my openagent Ultrawork 模式 GPT 变体提示词解析激活协议、决策框架与证据驱动执行规范 本文深入剖析 oh my openage人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排oh-my-claudecode 的执行模式怎么选autopilot、team、ralph 与 ultrawork 的决策依据oh my claudecode 的执行模式怎么选autopilot、team、ralph 与 ultrawork 的决策依据 在 oh my claudec人工智能AI Agent多智能体Agent 编排Agent 工作流AI 技能CLI开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oh-my-openagent 的 Ultrawork 模式：一份可执行的“证据驱动编码 Agent”运行指令解析
人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址https://gitcode.com/gh_mirrors/oh/oh-my-openagent点击查看免费下载导读ultrawork是 oh-my-openagent 仓库中 omo-senpi 技能体系packages/omo-senpi/skills/里的一个“绑定型模式指令”binding directive它的定位不是教程而是一份Agent 在 ultrawork 模式下必须逐条执行的运行契约。本文以该指令全文为骨架结合仓库中与其配套的mass-ulwDAG 编排、ulw-loop目标循环、ulw-plan规划、ulw-research饱和研究等技能与相关脚本为你逐段解析分层定级Tier如何决定证据强度、四条手工 QA 通道如何落地、引导Bootstrap四步、PIN→RED→GREEN→SURFACE→CLEAN 执行环、等待纪律、验证门Verification gate以及停止规则。读完后你将能够把“说清楚做完了”变成“用可复现证据证明做完了”并理解这套机制在当前仓库中的实现位置。一、这份文档是什么从“提示词”到“运行指令”在仓库中packages/omo-senpi/skills/ultrawork/SKILL.md的 frontmatter 声明自己为name: ultrawork description: The binding ultrawork-mode directive. This file IS the directive; read it only when ultrawork mode is requested and the directive is not already in the conversation.description里的关键词是binding绑定与directive指令这份文件本身就是指令而不是对指令的说明。它在packages/omo-senpi/skills/AGENTS.md中被标注为“Senpi-native ultrawork directive source”其正文由构建脚本 embed-directive.mjs 嵌入到src/components/ultrawork/generated-directive.ts该技能目录由plugin/scripts/sync-skills.mjs以原生注册表方式原样发布。也就是说技能目录中的SKILL.md是源生成的 TypeScript 常量是被注入到 Agent 会话的形态二者必须保持一致。进入模式后Agent 回应的第一行必须是字面量ULTRAWORK MODE ENABLED!# Output discipline一节并遵循[CODE RED] Maximum precision. Outcome-first. Evidence-driven.的基调。指令的核心立场可以用一句话概括“测试通过”永远不等于“做完了”——一套全绿的测试只证明单元级契约成立不能证明用户可见的行为真的工作见# Goal。二、Tier 分层LIGHT 与 HEAVY 决定证据与评审强度指令要求在任何工作开始前对“本次会话自己的变更集”change set做一次且仅一次的分层判定# Tier triage把判定结果连同理由写进 notepad并且“只升不降”ratchet up only。维度LIGHTHEAVY触发条件走已知模式、无开放设计决策单点 bugfix、照既有模式加端点、校验规则、查询微调、常量/文案、启动或指挥另一个会话能指认出的硬事实新模块/层/领域模型/抽象auth、安全、会话或权限代码构建或改动外部集成API、队列、支付、webhook注意“调用已有 API”不算DB schema 或迁移并发、事务边界或缓存失效跨领域重构用户明确要求“仔细/彻底/先设计”或要求评审成功标准1–2 条happy path 最有风险的一个边界3 条以上happy、edge、regression、adversarial risk每条都要有自己的通道场景与两份证据评审方式notepad 中记录 self-review当“验证门”触发时进入 reviewer loop直到无条件通过判定的关键规则“交接给别的会话/线程/被委托循环的工作”属于 payload由对方会话承担过程开销发起它同步、提示、创建、验证属于 control-plane 工作按 LIGHT 计。不确定就取 HEAVY运行中途冒出 HEAVY 事实要立即升级并重做 LIGHT 路径跳过的部分绝不允许中途降级。层级只改变过程的规模不改变诚实度两个层级都要捕获证据、记录清理回执cleanup receipt、遵守 never-suppress 规则。该分层逻辑在配套的 define-goal.md 中有同一标准的镜像LIGHT 1–2 条、HEAVY 3 条覆盖 happy/edge/regression/adversarial可以对照阅读。三、手工 QA 通道真实表面Real Surface的四种证明方式指令用一张通道表# Manual-QA channels规定“证据必须来自真实表面”并把“通过哪条通道、用哪个精确命令”作为每个场景的前置声明。四条通道HTTP call—— 用curl -i或 PlaywrightAPIRequestContext打真实端点捕获状态行 请求头 响应体。Terminal / TUI—— 通过 xterm.js 网页终端驱动真实 pty 并截图证明。仓库内直接提供了现成工具bun script/qa/web-terminal-visual-qa.mjs --title surface --command cmd --input {Enter} --evidence-dir dir脚本位于仓库根目录的 script/qa/web-terminal-visual-qa.mjs其配套测试为 web-terminal-visual-qa.test.ts。注意tmux send-keys只允许做启动冒烟严禁用tmux capture-pane取证——它会劣化 truecolor 与宽字符宽度破坏颜色/布局/CJK 证据。Browser use—— 从 eval JS 内核驱动真实页面Bun ≥ 1.4 上优先new Bun.WebView()Linux/Windows 需本地安装 Chrome/Chromium/Edge需要 Chrome 语义、stealth、trace 或 auth 时编写playwright-core脚本以chromium.launch({ channel: chrome })驱动本地 Chrome。绝对禁止在用户真实主浏览器配置上清除 cookies/cache/site data——需要登录态时先用rsync -a profile/ tmp-clone/克隆一份配置指向它。Computer use—— 面向桌面/GUI 应用时用 OS 级自动化computer-use agent、AppleScript、xdotool 等驱动运行中的应用3D/空间类工作每次改动后从多个角度渲染并与参考对比。指令还强调“辅助表面”CLI stdout、DB 状态 diff、解析后的配置 dump对 CLI 或数据形态的标准是一等公民证据但--dry-run、打印命令、“should respond”“looks correct”一律不算数。每个场景必须写出确切的工具与确切的调用字面命令 / API 调用 / 页面动作 具体输入 一个二元可观测的 PASS/FAIL 判定例如写curl ...而不是“run the endpoint”。四、Bootstrap 四步任何其他工作之前必须完成指令的引导阶段有严格顺序# Bootstrap缺一步都是缺陷0. 调查技能 → 收集上下文 → 定级先遍历已加载的技能列表读每个可能相关技能的 description显式决定本任务使用哪些技能并在 notepad 里写下一行理由——“跳过适用技能就是缺陷”。随后发出第一波发现见下文“Finding things”记录当前问题、带证据的决策点与理想终态再对变更集做 Tier 定级。只有存在未解决的设计决策模块边界不清、多种可行分解、多文件构建依赖顺序不明时才用task派生规划子代理已知流程再长也不需要规划器直接在 notepad 规划。1. 用create_goal注册目标绑定契约目标必须通过create_goal工具注册——不能是散文、notepad 或计划。调用时只传objective不传status。objective 要写全细节每个交付物、每个命名的表面、用户声明的每个约束。标准清单必须在目标中前置列出一行“用户可见交付物” 层级与理由按层级定规模的 success criteria每条命名其精确场景与二元可观测值、以及将捕获的证据工件每条标准的 failing-first 证明实现前捕获 RED、实现后 GREEN一行 WHEN TO STOP“Ill stop right away when 精确可观测状态”。目标没有数量预算上限禁止编造数值预算。等待目标结果属于“合法的回合结束”而非blocked只要有 monitor、待处理子通知或定时续跑通道在值班就结束回合等它触发update_goal标blocked只在真正僵局无任何续跑通道且连续多个目标回合同样阻塞时使用。2. 打开持久 notepad运行NOTE$(mktemp -t ulw-$(date %Y%m%d-%H%M%S).XXXXXX.md)并回显路径。初始化固定章节并只追加、永不重写# Ultrawork Notepad — one-line goal Started: ISO timestamp ## Plan (exhaustively detailed) ## Success criteria QA scenarios ## Now ## Todo ## Findings ## Learnings每次发现、决策、命令、RED/GREEN 捕获与 QA 工件路径都要立即追加。notepad 是“超出上下文窗口仍存活”的持久记忆任何压缩或上下文丢失Context compacted通知等后先完整重读整个 notepad再干别的从## Now恢复绝不从头重规划。3. 先写计划文件再注册 todo 清单多步工作先写计划文件独立计划放.omo/plans/slug.md否则放在 notepad 的## Plan。然后用 senpi 的todo工具把每个原子步骤镜像进清单init分阶段列表start/done/append/drop驱动每次状态迁移。步骤文本编码 WHERE/WHY/HOW/VERIFYGOODfoo.test.ts: Write FAILING case invalid-email→ValidationError for criterion 2 — verify by RED with assertion msgBAD“Implement feature”“Fix bug”“Add tests later”五、Finding things先查证不靠记忆指令明确“绝不凭记忆猜测”——用正确工具定位并在声称或修改前重读# Finding things。发现顺序符号类问题走 LSP定义、引用、重命名影响、工作区符号、诊断用内建lsp_*工具而非文本搜索编辑后跑诊断错误阻塞。结构形状调用/函数/类/导入模式、codemod用捆绑的ast-grep技能sg$VAR/$$$元变量或ast_grepMCP 服务器search/rewrite/scan。ast-grep MCP 的实现位于 packages/ast-grep-mcp。仓库文本/字节/文件名/历史/shell 输出rg、rg --files、git与原生工具。跨文件的架构/流程/爆炸半径并行扇出explore后台代理armed with ast-grep再综合——仓库不存在预计算的符号图结构搜索 LSP 引用 代理综合代替它。仓库外的研究库/API/文档/Web走librarian陌生布局走explore只读、绝对路径两者都放后台跑同时继续干活。六、并行执行eval JS 是默认表面# Parallel execution规定一步中相互独立的部分读、搜、符号查询、git/lsp_*/web 查询、task(...)派生默认用eval且language: js的一个单元格完成而不是一串串的一次性调用。核心要求若 eval 工具报告 Bun 内核bun-1-4技能已列出先读该技能用其内建Bun.$处理单元格内能结束的命令、Bun.Glob、fetch而非 shell 出去。每个独立查询通过Promise.all/parallel(thunks)一次全部触发用真实控制流按情形if/else、遍历所有目标的for、逐项的try/catch喂给后续调用的结果可以在同一单元格内串行。编辑、副作用命令、部署、审批等“输入还没见过”的调用一次只做一个动作每个都观察后再做下一个。单元格运行前先说出它应产出的状态返回后对比证据把失败或缺失的项原样保留——用try/catch把失败变成缺失行会让聚合结果撒谎。内核忙且需要另一个语言时跳到py绝不用bash python3 -c。并行扇出task(...)子代理run_in_background: true各自路由到匹配的category仅在写作用域不相交时安全——没有两个子代理编辑同一批文件重叠单元交给 team每个成员独立 worktree或串行。七、执行环PIN → RED → GREEN → SURFACE → CLEAN核心循环# Execution loop直到每条成功标准 PASS 且证据捕获为止选下一条标准 → 标 in_progress → 更新 notepad## Now。PIN RED重构可能掩盖回归的行为先写特征化测试pin在未改动代码上通过。然后通过“最便宜且忠实”的通道捕获 failing-first 证明有 seam 走单元测试、行为在接线层走集成/e2e、无测试 seam 时用标准自身的真实表面场景捕获失败。失败必须“败得对”不是语法错误、不是缺 import把 RED 输出贴进 notepad此时不写任何生产代码。TEST-ONLY 目标为已正确行为补回归覆盖没有天然 RED 与生产改动是唯一豁免。用变异证明替代临时强制复现每条新断言所指的回归回退修复提交或破坏 seam绝不提交捕获断言失败再还原变异并捕获 GREEN。在变异下仍绿的断言不是覆盖。PROSE 目标prompt、SKILL.md、规则、markdown措辞不是行为——绝不 pin 句子、短语有无或字数。只 pin 机器消费的值解析后的 frontmatter 字段、hook 抓取的中毒 token、经过真实校验器的 JSON 样例或两份发行副本间的toBe相等。纯散文改动没有 seam靠 review QA-by-read 交付不写测试——文本 grep 是伪装覆盖。GREENTEST-ONLY 跳过——还原变异即 GREEN写最小生产改动使 RED→GREEN重跑证明并捕获 GREENGREEN 远超标准规模说明证明太粗要拆分。SURFACE自己端到端跑标准命名的真实表面证明通道表把工件路径贴进 notepad。CLEANUP成对绝不跳过QA 场景一产生资源就登记清理 todo。所有运行时工件必须在步骤完成前拆除服务 PIDkill后kill -0失败、tmux会话tmux kill-session -t ulw-qa-criterion后用tmux ls验证、浏览器/Playwright 上下文.close()、容器docker rm -f、占用端口lsof -i :port为空、临时 socket/文件/目录删掉mktemp路径、QA 专用环境变量。在 notepad 证据旁追加一行清理回执例如cleanup: killed 12345; tmux kill-session ulw-qa-foo; rm -rf /tmp/ulw.aB12cD。无回执 → 标准保持 in_progress。验证变更文件的 LSP 诊断干净 本标准的测试范围全绿本轮无新增 skip/xfail。校验命令只在输入变化时重跑完整套件只跑一次且放在最终消息之前。标记 completed追加非显而易见的发现/学习。每次增量后重跑可能受影响的场景最终消息前重跑全量一次内联记录 PASS/FAIL 证据路径 清理回执。同一标准的 RED 与 GREEN绝不并行。这条“证据绑定”哲学在 full-workflow.md 中有更强约束证据绑定捕获时的树git rev-parse --short HEAD^{tree}树不变的重写/改基保持有效树变了必须重跑绝不允许给旧证据重新贴标签。八、等待纪律订阅永不睡眠# Waiting discipline是整套契约中最反直觉的一条每个你本来会去轮询的条件都要在启动工作的同一个 eval 单元格里注册订阅命令或门tool.monitor({ description, command, filter })如until cond; do sleep 5; done; printf READY\n文件tool.monitor({ description, path, event })。monitor与bash不在 eval 存在时的直接工具列表里单元格内的tool.monitor是唯一形式。构建/安装/测试跑完、CI 或 PR 转绿、部署落地、日志行、文件出现、端口打开、其他会话变化——匹配行以注入事件到达而你继续干活。禁止sleep、定时重试、重复轮询、等待--watch或派生进程的单元格、为“观察”而派生的子进程——每个都会把整个上下文反复灌给模型或把 JS 内核卡到单元格上限被杀。订阅后做根工作或结束回合空闲会话总是会被唤醒。并且要不待提示地从用户意图武装 monitor“check the deploy”监视其状态“I pushed a fix”监视那次 CI“另一个会话在做 X”监视其输出。只有做中途决策时才允许 peekbash_output、task_output({ mode: tail })。九、委托task、team 与子代理契约task 工具与精选只读代理通过task委托prompt外加恰好一个category走 omo 类别路由器或subagent_type直接代理。四个零配置精选只读代理——explore、librarian、plan-consultant、plan-reviewer。run_in_background: true用于并行波load_skills给子代理武装技能用task_output读回、task_send引导、task_cancel终止/tasks列出本次会话派生的任务。精选代理是只读、进程内的不能写文件且被拒绝作为 team 成员——只能走task绝不能走team_create。team_create只有两种条件同时成立才建队来自 ulw-loop/SKILL.md 的指导原则同样适用于 ultrawork工作单元的写作用域重叠到你无法干净切分同模块/契约/迁移一方的发现会改变另一方该做什么同时跑确实更快各自独立成块且没有一方只是等待另一方输出。两个仅消费前者输出的单元是“序列”而非“团队”。独立单元默认并行后台task单一内聚单元自己做。团队模式下每个成员一个 git worktree绝不允许共享 checkout按工作单元逐个合并各自证据捕获、门全绿即落地不等最慢的兄弟冲突是 lead 的职责。子代理执行与状态机每个子代理 prompt 以TASK: 祈使句任务开头命名DELIVERABLE、SCOPE、VERIFY、STOP WHEN并声明“可执行不是上下文交接”只含必要上下文。长任务要求WORKING: task - current phase长时间停顿前与BLOCKED: reason仅当进展不可能。沉默不是终态运行中的子代理还活着其完成会唤醒你所以结束回合而不是轮询它活跃子代理未清空时不得定稿。子代理仍活跃时禁止把 todo 标done也禁止在审计/研究/review 被整合或明确判定无结论前开始依赖工作。DAG 编排mass-ulw的衔接当工作带真实依赖C 需要 A 和 B 先完成时ultrawork 会衔接 mass-ulw/SKILL.md 的workflow原生工具声明式定义key幂等/name/nodes每个节点含id、自包含英文prompt、路由category与可选dependsOndependsOn只是排序绝不替下游注入上游输出因此每个 prompt 必须独立成立。DAG 必须在 eval 单元格内构建运行JS SDK 位于OMO_DAG_SDK_ROOT。生命周期动词start/attach/snapshot/wait/cancel单节点恢复用retry重跑失败/取消节点completed 节点复用缓存、send就地引导运行中或复活常驻的已完成子代理、amend按指纹 diff 只重跑变更节点及其传递依赖。run 被 journal 化会话中途死亡run 暂停而非丢失重启后恢复并复用已完成节点输出。定义图之前必须完整阅读其规划参考 planning.md。十、验证门Verification gate有触发条件的评审评审每次要消耗一整次额外代理运行因此“由书面计划挣得而非由野心触发”# Verification gate。仅当一次ulw-plan运行产出了本工作的计划文件且发生任何 apply 时才触发Tier 为 HEAVY或用户要求严格/严肃/规范评审。没有计划文件就没有评审者再重的裸ulw运行也在 notepad 记录 self-review重读 diff、跑诊断、逐条确认证据、用一行说明 tier 为何成立。plan-reviewer与plan-consultant是计划门控评审者而非通用帮手。触发后的程序NON-NEGOTIABLE用task派生自包含评审任务的评审子代理subagent_type: plan-reviewer只读评审或需要跑代码时用评审形状的category传入目标、成功标准、场景证据、完整 diff、notepad 路径。逐条亲自核实评审关切。只有“点名了某条成功标准而证据未满足”的关切才阻塞未引用标准的关切记为 notes附一行理由由你判定修或拒。修复每条引用标准的阻塞项只重跑受修复影响的场景 QA为增量捕获新证据更新 notepad。最多两次把增量 diff 重新提交给同一个评审者仅剩 notes 的批准计为批准。批准即宣告完成。两次重审后仍有引用标准的阻塞项用 question 工具带着未决阻塞项作为选项询问用户遵守下面的“2 次尝试”规则不再循环。配套的ulw-loop对最终聚合目标还有一道 full-workflow.md 定义的 Final Quality Gate先在冻结的 HEAD 上重跑所有树已变化的 PASS 标准manualQa.by固定为字面量main-session再派生一个门评审者依次尝试category: deep→unspecified-high→unspecified-low最后用agentToolkit.checkpoint({ goalId, status: complete, evidence, qualityGateJson })收口。十一、提交与约束提交纪律频繁提交每个已验证增量RED→GREEN 其证据一个原子提交绝不做“结束时的巨型提交”每个提交自身可构建、测试全绿最终分支无 WIP。撰写消息前先读历史并模仿git log --oneline -20加git log -5 -- touched paths匹配观察到的约定subject 形状、scope 名、消息语言、正文风格、提交粒度。默认 Conventional Commitstype(scope): imperative——feat/fix/refactor/test/docs/chore/build/ci/perf仅当历史没有更强的本地约定时使用。有计划文件时最终提交 footer 写Plan: .omo/plans/slug.md。仅在用户明令禁止提交时跳过——改为 stage 草拟消息。约束清单# Constraints每个行为变更都要在生产改动之前通过最便宜忠实的通道捕获 failing-first 证明先写了生产代码就 STOP、回退、捕获失败、重做。豁免仅限纯格式化、纯注释、无行为差别的依赖升级、纯改名移动——每项都要在## Findings说明理由。无法为其所指回归失败的测试不是证据mock 调用断言、钉死常量、等于默认值的 fixture、从被测输出反推的期望值都不算宁可要无新测试的真实表面证明也不要同义反复的测试。重构先写特征化测试钉住当前可观测行为旧代码上全绿、全程保持全绿。每个单元做最小正确改动但途中遇到的每个缺陷都是本轮的注册工作预存 bug、失败测试、过期文档、错误指引都要用 todo 成功标准注册ulw-loop 下是 subgoalulw-execute 下是计划复选框workflow 内是节点并修到理想状态绝不推迟为 follow-up。被委托单元的作用域要硬worker 报告缺陷orchestrator 注册它。绝不压制 lint/错误/测试失败绝不为刷绿删除、skip、.only、.skip、xfail或注释测试。绝不从推断宣称完成——只能从捕获的证据。十二、输出纪律与停止规则输出纪律第一行字面量ULTRAWORK MODE ENABLED!引导后1–2 段计划摘要 notepad 路径。执行中只呈现状态变化RED 捕获、GREEN 捕获、带证据路径的场景 PASS/FAIL、评审者裁决。最终消息结果 成功标准核对清单带证据引用 notepad 路径 评审者批准若门触发 提交列表sha subject。除非被要求不做逐文件 changelog。停止规则每次结果后自问用户的核心请求现在能否带着可用证据回答能就立刻回答——跳过一切不增加证据的检索、仪式或验证。停止目标每个场景 PASS 且有捕获证据、每条清理回执已记录、notepad 最新、若门触发评审者无条件批准。但高于一切的决定性检验是完成条件是否在根本上满足、用户的问题是否在可观测行为上真正被解决没有就还没做完满足了就交付并停止——不留恋、不加验证轮、不做打磨循环。停止目标之后的工作是范围蔓延不是勤勉。残留 QA 状态存活进程、tmux会话、浏览器上下文、占用端口、临时文件/目录没做完拆除、记录回执、再继续。一步连续 2 次相同失败先用 question 工具把尝试过的东西摆给用户再重试问题超时就按最佳判断继续。2 轮并行探索都没有新有用事实停止探索行动。十三、与相邻技能的协作边界ultrawork 指令在 omo-senpi 技能体系中与其他技能明确分工见 skills/AGENTS.md 的 “WHERE TO LOOK” 表技能与 ultrawork 的关系mass-ulw依赖序 DAG 编排ultrawork 的目标/标准/证据/检查点由它自身契约掌控mass-ulw 只负责定义、驱动、恢复每个 phase 的 runulw-loop目标循环与持久账本.omo/ulw-loop/session-id/ledger.jsonl当它伴随 ultrawork 时其契约取代 ultrawork 引导的第 1–3 节loop SDK 拥有目标状态loop 账本就是 notepadloop CLI 的检查清单就是计划ulw-plan只读规划咨询产出决策完备的计划文件后验证门才可能触发评审者ulw-research饱和研究与 ultrawork 组合时研究本身是交付物把每个研究轴映射为一条成功标准其中一条关键衔接规则“mass-ulw 的 run 一旦 settle其输出的验证指令是 TREAT-AS-FALSE”——节点和 run 的完成声明在对照捕获证据证明之前一律视为假这与 ultrawork 的“测试全绿≠做完了”是同一条哲学的两种表达。结语从“声称完成”到“证明完成”packages/omo-senpi/skills/ultrawork/SKILL.md提供的是一套把编码 Agent 的完成判据从“我做了”迁移到“证据在这里”的可执行协议Tier 决定证据与评审的规模四条通道决定证据的真实表面Bootstrap 四步与 notepad 决定崩溃后可恢复性PIN→RED→GREEN→SURFACE→CLEAN 环决定每次变更的可证明性等待纪律决定长任务不休眠、验证门决定重活不裸奔、停止规则决定何时真正收手。理解这份指令就等于理解了 oh-my-openagent 这套技能体系中所有“ulw”前缀能力的共同地基。赞分享人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址https://gitcode.com/gh_mirrors/oh/oh-my-openagent点击查看免费下载相关推荐oh-my-openagent 中的 Ultrawork 模式一套以证据为锚的编码 Agent 执行协议深度解析oh my openagent 中的 Ultrawork 模式一套以证据为锚的编码 Agent 执行协议深度解析 导读 Ultrawork 模式缩写 ULW人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排oh-my-openagent Ultrawork 模式 GPT 变体提示词解析激活协议、决策框架与证据驱动执行规范oh my openagent Ultrawork 模式 GPT 变体提示词解析激活协议、决策框架与证据驱动执行规范 本文深入剖析 oh my openage人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排oh-my-claudecode 的执行模式怎么选autopilot、team、ralph 与 ultrawork 的决策依据oh my claudecode 的执行模式怎么选autopilot、team、ralph 与 ultrawork 的决策依据 在 oh my claudec人工智能AI Agent多智能体Agent 编排Agent 工作流AI 技能CLI开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考