**这篇文章的 AI 优化版被人投诉灌水， ** 所以我从新找出我的策划原文，一字未改的版本。核心的思想还是在的 ——此文为本人原创心得，与大家共享 如何使用 OMO（oh my openagent）来提升开发速度和质量 首先介绍一下原因 就是有很多朋友想要学习一下我对这个 OM O在项目开发上面的使用 一个一个的解答比较麻烦 所以我就写了一篇这样的 文章来给 大家一起参考学习 第1步是需要搭建一个环境出来 这里可以链接一下我之前写的两篇文章 OpenCode CLI 接入 API-Switch：系列三 API-Switch——OMO的灵魂调度者 告诉大家如何使用正确的方法安装调配好 使用环境嗯 能够继续 下一步 一 首先简单介绍一下 oh my openagent 的一些基础的功能 这个可以在网上去查得到 不用太多 然后说一下 oMO为什么会 成为提升项目的开发速度和质量的原因 多AGENT协作 工作流式开发 避免单AGENT 开发中的一些缺陷 主要是在对话的过程中偏离边界 上下文无限制的增长 二 接下来就说我们怎么 做来达到目的 有以下几个关键点 1必须约束 智能体 对任何对话都要求进行评估和 分析 超过五步以上的 都必须以工作流的方式来执行 2对主脑进行限定 明确他的职责 他只是一个思考者 安排者和审核者 其他的工作必须交给 SUBAGENT 来完成 3复杂任务必须分解为独立的层次，对 不冲突的 开发流程 保持并行三个以上的滚动式开发 （具体并行数量看你手上的资源而定 ） 4要求AGENT a任何修改必须形成闭环：输入 → 执行 → 输出 → 验证 → 反馈， b每个任务 都必须以 目标—约束—执行—校正 分步执行 c输出必须能回流影响输入，形成自调节 d识别不确定性，在设计阶段处理 4点可以简单操作为要求 AGENT 学习“钱学森工程控制论作的核心思想” ，但是在他学习过程中 你要 纠正他的一下想法，避免学到模糊的概念 你也可以通过自己总结的一些成熟的想法 教会 AGENT 来适应你的开发理念 完成这个步骤以后 越是聪明的AGENT 执行的力度越好 那些傻傻的就不用说了 所以我们要求 主脑越强越好 用你手上最好的 具体如何操作 我在 API-Switch——OMO的灵魂调度者 这篇文章中 有比较详细的介绍 三，写一些在项目中的实际的操作 解释一下为什么会提 高开发的速度 越是大的项目越是可以拆分成不冲突的 过程 用并行的方式来提速 为什么会提高项目开发的质量 因为可以使用 多个 AGENT 多角度多方向的对项目进行 审核。不管你的主脑再强 他也会有思考的盲区和上下文的缺陷 通过1~2次的审核 能够很大程度的弥补 开发中出现的问题 提高开发的质量 四，总结 优点 越是大的项目 可以并行的 开发线越多。这就是提速的关键 。从多个角度 对开发进行审核 这是提高开发质量的关键 缺点 因为执行的中间环节很多 对小的项目和 修改 达不到提速的作用 但是能达到提高质量的作用 还有就是越稳定越快的 API资源 和强力的 AI模型 是提高速度和开发质量的 必备条件 9 个帖子 - 2 位参与者 阅读完整话题
如何用 Oh My OpenAgent (OMO) 提升项目开发速度与质量 很多朋友问我 OMO 在项目开发中到底怎么用，一个个解答太费时间，索性写成文章，供大家一起参考、学习。 前言 AI 辅助编程已经不是什么新鲜事了。CLI 作为新一代终端开发环境，正逐渐成为高效开发者的标配。但一个普遍的现实是： 大多数开发者仍然停留在"和一个 AI 聊天"的阶段 ——你问它答、你让它写代码它就写，上下文越聊越长，偏离初衷越来越远。 Oh My OpenAgent（OMO）提供了一条不同的路径： 用工程控制论的思维来组织 AI 开发 。这篇文章将系统性地介绍我是如何用 OMO 搭建开发环境、设计工作流、调度多个 Agent，最终实现开发速度和质量的跃升。 如果你还没有读过我之前的两篇文章，建议先看： OpenCode CLI 接入 API-Switch：系列三 ——环境搭建 API-Switch——OMO的灵魂调度者 ——模型调度的核心 一、OMO 是什么，为什么它能改变开发方式 1.1 基础能力 Oh My OpenAgent（GitHub 56.8k ）是一个基于终端的 TUI 多模型编排工具，它的核心能力包括： 多模型并行调度 ：同时调用多个大模型协同工作 5 层 Hook 机制 ：在 Agent 生命周期的关键节点插入自定义逻辑 Team Mode ：多个 Agent 组队协作，各司其职 TypeScript/Ink 技术栈 ：终端 UI 渲染，交互体验流畅 网上关于 OMO 的基础功能介绍已经很多，这里不过多展开。重点说： 为什么它能让开发速度和质量同时提升 。 1.2 单 Agent 开发的三大缺陷 传统的"一个 Chat 窗口走天下"模式有三个致命问题： 问题 表现 后果 边界漂移 聊着聊着就偏了，忘记最初要做什么 时间浪费在无关方向 上下文膨胀 对话越来越长，模型开始"失忆"或混淆 输出质量断崖式下降 单视角盲区 一个模型的思考路径依赖，无法自检 隐藏 bug 和设计缺陷难以发现 1.3 OMO 的解法：多 Agent 协作 + 工作流式开发 OMO 改变了什么？就是把"一个 AI 陪你聊天"升级为"一个 AI 团队为你工作"： 多 Agent 协作 ：把开发流程拆成独立子任务，分配给不同的 Agent（写代码的、写测试的、做审核的），各干各的，最后汇总 工作流式开发 ：不是无结构地聊天，而是有明确"输入→执行→输出→验证→反馈"闭环的结构化工作流 大项目拆得越细，并行空间越大，提速越明显。 二、实操：四个关键约束 要让 OMO 真正发挥威力，光有工具不行，关键是 约束 Agent 的行为模式 。以下是四个核心原则，你需要把这些原则固化在 AGENT的记忆里 ： 2.1 强制工作流化：超过 5 步必须走流程 对任何对话都要求 Agent 评估任务复杂度。 超过 5 步的操作，必须以工作流的方式执行——拆分子任务、明确依赖关系、定义输出标准。不允许 Agent 凭直觉摸索式推进。 这样做的好处：每一步都有预期产出，偏离边界立即可控。 2.2 限定主脑职责：只思考，不搬砖 主 Agent 的角色必须是：思考者 + 任务安排者 + 最终审核者。 它负责： 分析需求，拆解任务 将子任务分配给 Sub Agent 审核子任务输出，决策是否通过 它 不负责 ：亲自写大段代码、亲自执行批量操作。这些"搬砖活"统统交给 Sub Agent 完成。 这样做能从根本上解决上下文膨胀问题——主脑始终保持在一个高层抽象的视野中，不被细节淹没。 2.3 复杂任务必须分层并行 将复杂任务分解为独立层次。 对于互不冲突的开发流程，保持 3 个以上的滚动式并行开发 （具体数量看你手上的 API 资源和算力）。 举个例子：前端组件开发、后端 API 开发、文档编写——这三者无冲突，就应该同时推进，而不是排队等待。 提速的关键公式：总耗时 = 最长单线耗时，而不是各线耗时之和。 2.4 植入钱学森工程控制论 将"钱学森工程控制论的核心思想"作为 Agent 的行为准则： 闭环必须完整 ：输入 → 执行 → 输出 → 验证 → 反馈，缺一不可 分步执行 ：每个任务按 目标—约束—执行—校正 四步推进 输出回流 ：执行结果必须能反馈影响输入决策，形成自调节 识别不确定性 ：在设计阶段就处理不确定性，而不是在执行中被意外绊倒 注意：让 Agent 学习"钱学森工程控制论"时，需要你主动纠正它可能学到的模糊概念。工程控制论的核心思想可以这样概括： 用系统化的反馈回路来保证执行质量，在不确定性的源头解决问题，而不是在结果上去修补 。 你也可以通过自己总结的成熟开发理念来训练 Agent，让它适应你的方法论。 越聪明的模型，对这些约束的执行力度越好。所以主脑务必用你手上最好的模型。 具体如何配置和调度，在《API-Switch——OMO的灵魂调度者》一文中有详细介绍。 三、为什么这样能提速和提质 3.1 速度：并行就是王道 越是大型项目，可以拆分成的不冲突流程越多。如果能把 10 条线并行推进，理论加速就是 10 倍。虽然实际受限于资源，但只要并行度 > 1，就一定比串行快。 这和现代 CPU 的多核设计是同一种哲学：单核撞墙之后，出路在于并行。 3.2 质量：多视角审核消解盲区 不管你的主脑模型多强，它一定会有思考盲区和上下文缺陷。这是 LLM 的本质决定的，不是换个更好的模型就能解决的。 但如果你用 2~3 个 Agent 从不同角度对同一段代码进行交叉审核： Agent A 看功能完整性 Agent B 看边界条件和异常处理 Agent C 看代码风格和可维护性 每人看一个维度，汇总后能极大程度地弥补单一视角的遗漏。 哪怕只经过 1~2 次这样的多角度审核，代码质量也会有肉眼可见的提升。 四、总结 优点 大项目提速显著 ：可拆分的不冲突开发线越多，并行优势越大。这是提速的核心逻辑 质量多角度保障 ：多 Agent 审核从不同视角交叉验证，消解单模型盲区。这是提质的关键机制 工程化可控 ：工作流化的开发流程让进度透明、偏差可纠正 缺点和前提 小项目/轻量修改不加速 ：中间环节的调度开销在简单任务上反而成为负担。但质量提升仍然存在 依赖资源质量 ： 越稳定、越快速的 API 资源，以及越强的 AI 模型，是速度和质量的双重前提。 如果你的模型连基础代码都写不稳，并行再多也没用 一句话总结 OMO 不是让一个 AI 做得更多，而是让多个 AI 协同做得更好。 这篇文章就发在我的公众号上。如果你对 AI 驱动的开发方法感兴趣，欢迎关注，我会定期分享 AI 与开发相关的实践经验。 1 个帖子 - 1 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 刚刚发不了插件的1.9.0版本，为了实践验证，笔者光速根据钱老的《工程控制论》的思想对本插件进行自迭代出1.10.0版本 下图为上个版本的特性，利用GitHub Issue来追踪子任务 新版本特性 自适应控制层（Adaptive Control Layer） 基于工程控制论（钱学森）原理，为 Spec-Driven Develop 工作流引入闭环反馈控制系统。工作流从"开环前馈"升级为"闭环自适应"——执行过程中实时观测偏差，自动纠偏。 核心机制 设计原则 零侵入：不改变现有 Phase 0-7 的线性流程，自适应逻辑作为正交层嵌入 GitHub 原生：drift_score 存于 Milestone description，telemetry 存于 Issue comment 优雅降级：LOCAL_ONLY 模式使用 MASTER.md 段落替代 GitHub 存储 工程控制论映射：传感器(telemetry) → 数据总线(Milestone/MASTER.md) → 控制器(阈值判定) → 执行器(自动响应) 项目地址 github.com GitHub - zhu1090093659/spec_driven_develop: A cross-platform AI agent skill that turns... A cross-platform AI agent skill that turns "rewrite this in Rust" or "migrate to microservices" into a disciplined, document-driven workflow — analyze, decompose, track, execute. One SKILL.md, no framework, no runtime. Works with Claude Code, Codex, Cursor, or any agent that reads Markdown. 2 个帖子 - 2 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 项目链接 github.com GitHub - OceanEyeFF/vibecoding_autoworkflow: 工程控制论影响下的AIGC流程管理Skills集合。 工程控制论影响下的AIGC流程管理Skills集合。 开发原因 现有的前沿模型已经可以很好的完成各项代码任务（一般），国产大模型的表现也已经基本及格。影响代码生成方向的使用的最大变量已经从模型性能逐步转向使用模型的方法。本项目是基于本人的VibeCoding经验，结合了Harness和控制论的一些idea，让大家能够更简单更轻松的VibeCoding，也希望能够用国产模型发挥出更好的效果。 亮点在哪 几乎不改变VibeCoding的体验 完整的feature-coding-review流程 自动推进MVP原型的开发 丝滑的追加需求、追加任务解决方案 一轮生成20分钟起步放心刷L站 如何安装 在你要安装的项目目录下，使用 npx aw-installer 的TUI安装最新版本。 也可以跟随项目的README文档（Vibe生成的文档佬们轻喷）去做安装。 个人觉得TUI安装比CLI安装体验好很多。 使用 Skills 以 Codex 为例，如果使用ClaudeCode请替换 $ → / 初始化仓库 目标仓库还没有 .aw/ 时，先初始化 Harness 控制面： $harness-skill 初始化当前工作目录的 harness 环境。 （如果没有创建git的话）初始化当前工作目录的 git 环境。 设置仓库 Final State 需要明确或重设仓库最终状态时，给出目标、非目标、验收标准和约束： $set-harness-goal-skill 当前仓库期望最终实现一个 [目标描述]。 或者考虑： $set-harness-goal-skill 从当前仓库的文档、代码等提炼当前仓库的最终目标。 如果是对已有 Goal Charter 做方向变更，走目标变更控制： $repo-change-goal-skill 将当前仓库目标调整为 [新目标]，变更理由是 [原因]。 追加临时任务或者补充需求（常用） 考虑到需求可能每天都在变，特此设计这么一个功能用于临时增加需求任务或者改动项目的部分设计： $repo-append-request-skill 补充一个功能：[要新增或补充的内容]；边界是 [希望包含什么，不包含什么]。 $harness-skill （如果你需要针对上面的分析做调整请做额外说明）上述的内容可以加入到Worktrack工作队列中、如果有goalChanges也可以修改全局目标。 开始工作 请从当前的开发分支基线创建一个新的develop-aw分支，harness-skill将默认在这个分支上进行工作。 请切换到develop-aw分支。 $harness-skill 开始工作。 如果想让AI连续工作 连续推进工作虽然能解放双手，但是请 注意 ： 请记得append多一点任务或者给一个比较清晰有多个分任务点的的项目目标 请时刻记得切回去看一眼是否正在自动推进（Deepseek和KIMI经过实测容易在中间任务审批提交commit处中断，CodeX+GPT5.4/5.5一般可以直接丝滑跳过） 个人建议，在Merge 自动工作流的开发分支 Branch的时候，额外做CodeReview，比如用Claude+CodeX跑两轮CodeReview 请一定要 开启SubAgent 功能，不然上下文肯定出问题 连续工作需要提权获得最佳体验，并且请确认做好安全措施（如：边界提示词对删库删盘做限制） $harness-skill 开始工作，你有xx个连续推进工作的额度。 你现在拥有下列权限： - 开启SubAgent - 连续推进工作，自动审批worktrack的commit - 向Worktrack列表中添加任务 或者 $harness-skill 请逐项完成已经确定的Worktrack列表的任务。 这一轮执行周期中我会给你批准30个连续执行任务的行动额度（Worktrack额度）。 你有下列的权限： 1. 开启SubAgent（AgentTeams） 2. 连续推进工作 3. 低风险的Worktrack commit审批可以自行通过 4. 可以按需增加Worktrack任务清单 --- 你需要额外注意下列的情形需要通知我处理： 1. 大量文件删除、系统配置修改等危险操作 2. 上下文噪声明显，提示词明显遗忘 3. 你觉得有必要由我来做决定的内容 --- 可以开始了！谢谢你 另外，如果使用Claude+Deepseek Pro Max已知的问题有： 经常不新建一个branch直接在工作branch上做commit（这也是为什么建议新开一个独立的develop-aw分支） Dispatch说明 本项目暂时不提供任意的具体环境的工作Skills，各位佬需要根据自己的项目，准备一些适合的具体工作执行Skills。因为项目是会把任务发布给最适合的skills（SubAgent Calling)，如果找不到适合的就会直接启动SubAgent。 也就是说如果能准备合适的任务执行Skills，本仓库能够发挥更好的效果。 项目思想 假设我们的repo有一个最终开发目标状态（当然我们知道这不可能），还有个项目的现状状态，本项目工作流大概工作路径是： 审视现状状态，比较和最终状态的差距 确认状态转移的路径，确认短期路径和长期路径 确定工作计划，把这个短期路径做任务切片 开始实施 当然具体的操作会更复杂一些，而且对LLM的性能表现也是一个很大的挑战，因为需要解决： Repo层级和Worktrack层级的管理切换 具体项目现状的嗅探 项目短期方案长期方案的规划（最关键的需求是什么？主要矛盾是什么？） … 而且在工作流设计的时候也要注意，什么时候更新项目状态，Review和Gate如何设计，等等。 可以看看项目内的 docs/harness/foundations 下的两个文档，这里有更完整的叙述。 写在最后 希望各位佬能够多多试用，用得顺手可以点个 ~也希望各位佬多多提建议，交流一下VibeCoding的心法，一块来改进这个项目。预期在几天后更新MileStone相关机制内容，这个机制会对harness-skill主窗口的上下文管理还有版本号开发有比较好的帮助（不管理版本号，行为预期会在某些模块节点自动停止工作）。 碎碎念 （点击了解更多详细信息） 1 个帖子 - 1 位参与者 阅读完整话题