Qwen3.8 无人干预跑了 16 天造出的 oh-my-cli：拆解「循环工程」，把它搬进你的项目

2026 年 8 月 3 日，阿里发布 Qwen3.8（总参数 2.4 万亿）。发布会上最抓人的不是跑分，而是一个案例：用户只给了一句话——「创建一个自进化的智能体 Harness」，模型从一个空文件夹出发，自主运行了 16 天，无人持续监管，最终交付了一个真实可用的开源框架 oh-my-cli。

完整过程保存在 GitHub 仓库里，代码、commit、PR、issue 都可查。这件事的意义不在于「AI 会写代码」——今天很多模型都能写个 CLI、糊个 demo 级 agent wrapper。oh-my-cli 真正值得讨论的是：它不是一次生成出来的，而是在一个无人介入的长程过程中被一点点推进出来的。

🔄 本教程适合：想理解「长程自主开发」到底是怎么运转的技术负责人与架构师。我们不只讲这个项目，更重要的是拆出可复用的方法论——第 4、5 步是全文重点。

Step 1：先搞清楚 Harness 是什么，为什么难

1 它要解决的不是「写代码」，是「组织工程过程」

Harness（驾驭层）是包在模型外面、让模型能真正干活的那层工程。要做一个能用的 Agent runtime，需要处理一整套问题：

oh-my-cli 实际处理的 Agent runtime 组件清单：

  · 命令行交互        · 会话管理
  · 会话恢复          · 上下文压缩
  · 审批机制          · 工具调用
  · MCP 协议接入      · 工作区隔离
  · undo / redo       · headless protocol
  · handoff（交接）

这份清单本身就是干货。如果你正在自研 Agent 框架，可以直接拿它做 checklist 对照——大多数自研项目做到「工具调用 + 会话管理」就停了，而后面那些（上下文压缩、工作区隔离、undo/redo、headless、handoff）才是从 demo 走向可用的分水岭。

Step 2：拆解 Loop Engineering（循环工程）

2 16 天不散架的核心机制

模型没有靠「一次超长对话」硬撑 16 天——那样上下文早就崩了。它自主搭建的是一个循环工程框架，把工程任务变成一个可持续运转的闭环：

需求进入系统
    ↓  规范化为 issue
issue 拆解成任务
    ↓  agent 自动领取
任务变成代码
    ↓  执行 + 测试
测试与反馈
    ↓  失败则修复，继续迭代
反馈变成下一轮行动
    ↓
（回到顶部，持续循环）

外部输入随时可注入：
  用户反馈 / 社区实践 / 模型自测结果
  → 全部规范化为 issue 进入同一个循环

🔑 这套设计的精髓在于：把「无限长的任务」切成「无限多个有限长的任务」。每个 issue 是一个可以在有限上下文里完成的单元，issue 队列则承载长期状态。上下文会满，但队列不会——这就是长程自主的关键。人类工程师期间还能通过钉钉给模型提新要求，需求同样进队列。

Step 3：看懂验收方式的转变

3 传统 benchmark 测不出 16 天

传统评测测单次任务：解一道题、写一段函数，几分钟出结果，对错清楚。但一个持续 16 天的项目没法用单一分数概括——代码能否运行、测试是否完整、过程能否追溯、最终是否可用，都是验收的一部分。

千问团队公布的另外两个案例，用的也是同一种「可外部复核」的思路：

案例	过程	结果
oh-my-cli	16 天自主开发，全程 GitHub 留痕	Hermes Agent 级别的可用框架
天池 WWW2025 竞赛	24 小时自读规则、设计方案、微调多模型、加权投票，45 次提交	准确率 0.60 → 0.853，超过 87% 的 526 支人类队伍
论文复现	连续约 5 天，写约 7600 行代码，33 轮 GPU 训练	复现论文六项主要结论

📊 共同点：仓库、竞赛排行榜、训练日志都能被外部复核，比厂商自己公布的单项跑分更有说服力。你在评估任何 Agent 能力时，也该优先看这类「有过程留痕」的证据。

Step 4：把循环工程复刻到你的项目（核心实操）

4 五个组件，缺一不可

你不需要 2.4 万亿参数的模型才能用这套方法。用现有的编程 Agent（Claude Code、Codex、goose 等）＋一个 issue 系统就能搭，关键是把这五件事配齐：

① 需求入口：一切都变成 issue
   无论来自用户、测试失败还是模型自省，
   统一规范化为结构化 issue（标题/验收标准/优先级）。
   → 用 GitHub Issues 或本地 issues.json 都行

② 任务队列：agent 自动领取
   每轮只从队列取一个未完成 issue，
   在干净上下文里执行，避免历史污染。

③ 执行 + 强制测试
   每个 issue 完成必须跑测试。
   没有测试的「完成」不算完成——
   这是长程自主唯一的刹车。

④ 反馈回灌
   测试失败 → 自动生成新 issue（含失败日志）
   而不是在原地反复重试烧 token。

⑤ 过程留痕
   每轮 commit，message 里带 issue 编号。
   出问题能回溯到具体哪一轮、哪个决策。

最容易漏的是第 ④ 条。大多数人的做法是让 Agent 在同一个上下文里反复重试，结果上下文越滚越脏、成本飙升、还越试越错。正确做法是失败即生成新 issue、清空上下文重来——把失败信息结构化传递，而不是靠上下文携带。

Step 5：成本才是真正的门槛

5 长程任务是「过程成本」，不是「一次调用成本」

很多时候不是模型做不到，而是人出于成本考量不敢放手。算这笔账要换个口径：

Qwen3.8 API 定价（千问 AI 平台，国内）：
  输入      12 元 / 百万 Tokens
  输出      36 元 / 百万 Tokens
  隐式缓存命中  1.5 元 / 百万 Tokens ← 长程任务的关键

国际价格约为 Opus 5 的：
  输入 40%   输出 24%

💰 隐式缓存命中价（1.5 元）是长程任务能否跑通的经济学基础。循环工程里大量上下文是重复的（项目结构、规范、历史决策），缓存命中率高，实际均价远低于标称输出价。设计你的循环时，刻意把稳定内容放在提示词前部以提高缓存命中——这一条能直接决定项目跑不跑得起。

Step 6：放手之前必须回答的两个问题

6 责任边界与任务定义

把模型当员工验收，逻辑上成立，但进真实企业环境还有两道关：

关卡	要回答的问题	落地做法
责任边界	持续 16 天的自主项目出了错，谁承担？	明确人工复核节点、过程审计、风险承担机制
任务定义	目标是否清楚？边界是否明确？验收标准能否量化？	写清 issue 模板：输入/输出/验收条件三段式

一个反直觉的结论：模型执行能力提高后，困难会更多地出现在任务定义上。能把目标说清楚、把边界划明白、把验收标准量化的人，价值反而上升。这是 Agent 时代真正的稀缺技能——不是会写提示词，是会定义工作。

动手清单

动作	投入	预期收获
去 GitHub 翻 oh-my-cli 的 issue 和 PR	1 小时	看清模型如何自我修正
拿 Step 1 的组件清单对照自研框架	30 分钟	找出你的 demo/生产差距
用现有 Agent 搭一个最小循环工程	半天	验证第 4 步五组件是否跑得通
重写 issue 模板为三段式	1 小时	直接提升 Agent 交付质量
优化提示词顺序提高缓存命中	1 小时	长程任务成本可降数倍

🎯 一句话总结：oh-my-cli 的价值不是「又一个 Agent 框架」，而是它把模型能力从「会写代码」推到了「会组织工程过程」。而组织工程过程的方法论——循环工程——是你今天就能用现有工具复刻的。

📚 更多教程 📰 智能体资讯

← 返回教程中心