AI Coding IDE 的核心并不只是一段 system prompt。模型负责判断，Harness 负责把判断变成连续、受控、可恢复的工程过程。本文固定 Codex 与 OpenCode 源码版本，并以 Claude Code 官方行为契约为界，回答三个问题：Goal 是否只是定时任务，推理强度是否只是换 prompt，以及三种工具如何控制子 Agent 的上下文、模型与推理强度。

Codex 的 Fast 模式究竟快多少？Sol 与 Luna 谁输出更快？我在同一台 Mac、同一账号和同一时间窗口内，串行运行了 36 次真实请求：24 次约 10K 用户输入差分，12 次至少 10K 文本 token 的流式输出。结果很明确：Fast 将持续输出吞吐提高到约 1.50–1.53 倍，Sol 的流式速度只比 Luna 高 3.4%–5.6%；但输入处理速度被连接重试与缓存噪声淹没，本轮无法识别。

租房不是在几十分钟里挑一间看起来不错的房，而是在判断：自己能否在这里连续生活几百天。先用安全、权属、噪声、通勤和预算淘汰不合格房源，再比较面积、采光、通风、晾晒和装修；如果是合租，还要把室友、公共资源、服务费和退出机制当成房屋的一部分。

Echo 是一个面向大规模分布式训练的混合性能模拟器：它先在少量真实 NVIDIA GPU 上逐 Rank 执行和计时，再用 NCCL 白盒公式、离散事件时间线以及 XGBoost 重叠减速模型，预测目标集群的单步时间。它模拟的是执行时序，不是张量数值、loss 或收敛过程。

截至本文固定的公开版本，Echo 已公开 workload tracer 与 slowdown predictor，但论文中的集成通信估算器和 timeline composer 尚未在仓库中找到；代码明显绑定 CUDA、NCCL 和 Nsight，没有开箱即用的 Ascend 支持。论文在 NVIDIA 测试域内给出 91.4% 平均预测准确率，以及 GPT-175B、96 张 H800 上约 8% 的单步时间误差，但这些数字不能直接外推到 Ascend。

SimAI 不是把上千张 GPU 在软件里逐晶体管复刻一遍，也不是实际训练一个没有数据的模型。它把训练框架、算子耗时、集合通信和网络拆成不同精度的模型，再用事件依赖重建一次迭代的时间线。本文基于 NSDI 2025 论文与固定版本源码，回答五个问题：它是什么、架构如何组织、是不是仿真、精度证据有多强，以及公开版是否支持 Ascend。

GLM-5/5.2 已公开模型权重、技术报告、slime 大模型 RL 框架和部分昇腾训练/推理能力，但这些材料处在不同层次。论文公开、仓库中有同名函数、存在可运行 recipe、能够复现 GLM-5.2、已经打通 NPU 端到端，是五件不同的事。

本文不重复上一篇《GLM Post-Training Beyond SFT》的公式推导，而是把 Reasoning/Agentic/General RL、IcePop、TITO、DIS、DSA Indexer、Cross-Stage OPD、MOPD、SAO 与 CompactionRL 逐项落到公开仓库，回答三个工程问题：slime 里有什么、昇腾 NPU 到了哪一层、智谱/THUDM 还有哪些相关开源仓。

部门要突破 GLM 模型的 NPU 原生训练，真正困难的不是把一个 GRPO loss 搬到 NPU，而是让 Actor 训练、推理 Rollout、Teacher Prefill、Verifier、权重同步和低精度数值形成闭环。

本文以 GLM-5 技术报告为主线，并补充 GLM-5.2 已公开的 SAO、CompactionRL 和十多个专家的并行 OPD。重点解释非 SFT 后训练中的 RL、OPD/MOPD，同时单独澄清 QAT 与量化：GLM-5 明确把 INT4 QAT 放在 SFT 阶段，它对 NPU 后训练很重要，但不是非 SFT RL 的一个阶段。

AI 相关需求经常采用敏捷方式推进：先完成最小穿刺，遇到问题再解决问题。这种方式可以快速消除技术未知，却容易留下另一类债务：需求散落在聊天和 issue 中，关键取舍没有 ADR，安全与可靠性只在事故后出现，性能结果只有一张截图，最终很难回答“你究竟设计了什么，为什么这样设计，怎样证明它有效”。

任职要求要看的不是文档篇幅，而是从问题到结果的可复核判断链。一份合格的软件设计材料应该同时连接需求/Top 问题、架构视图、质量属性场景、候选方案、设计原则与模式、代码提交、测试/Profiling/运行证据，以及后续架构治理。缺失的环节应如实列为设计或代码工作，不能由 AI 根据最终代码补写成虚构的事前决策。

本文解释 4+1 视图、设计原则、GoF 23 个设计模式（不是 24 个）、安全威胁分析、可靠/可用性、可测试性、功能安全、体验、性能、架构治理和技术决策，并给出一个可复用的本地 Skill：输入需求和穿刺代码 commits，输出软件设计文档、任职举证报告、追踪矩阵与缺口清单。

AI 技术更新很快，日常知道“最近出现了什么”并不难，真正困难的是判断：新技术到底解决了旧方案的哪个瓶颈，会替代什么、保留什么、把成本转移到哪里，以及它是否适合自己的用户、硬件和组织。

技术洞察因此不能止于论文、新闻、功能和融资信息的汇总。它要从一个具体决策出发，建立现有技术基线，读标准和代码，设计最小 Demo 与受控基准，量化瓶颈，评估技术演进、成熟度、全生命周期成本和风险，最后给出带适用边界、证据等级和退出条件的行动建议。

本文把技术全景扫描、竞品与标杆、代码与架构逆向、实验与基准、瓶颈、演进、成熟度、成本收益和风险九类方法组织成一个闭环，并沉淀为可复用的 $technology-insight Skill。

功能分解的目标，是把“提升训练问题定位效率”这类高层目标，逐层转成可以独立实现、独立验证、能够追溯业务价值的子功能。真正困难的不是把一个大框画成很多小框，而是保持三种关系清楚：功能树表达“由什么组成”，依赖图表达“先有谁、后有谁”，验收契约表达“怎样证明做到了”。

本文用同一条训练诊断链路比较五种常用方法：功能树、WBS、FAST 功能分析、能力地图和 Feature Breakdown Structure。核心原则是：先按用户能力和业务价值拆“做什么”，再按架构与代码模块分配“由谁实现”。