技术

前一篇文章我做了 DeepSeek Harness（DSH）的 git 考古，拆解了它 64 天 12293 次提交背后的构建哲学——《用Agent造Agent：DeepSeek Harness的64天考古与自进化路径》。那篇是「DSH 是什么、怎么造的」。这篇是「DSH 的经验怎么用」——把那 64 天里被验证过的工程判断，提炼成普通团队可以落地的 AI 辅助开发实践。 先说清楚为什么值得这么做。DSH 不是又一个「我们用了 AI 写代码所以快」的故事。如果只是这个，Copilot 上市五年了，行业早该被颠覆。DSH 真正反常理的是：一个不到 20 人的团队，用 64 天长出一个 221 包的 agent 运行时，工程严谨度却高得不像 AI 写的——100% 测试覆盖率门、运行时断言强制不变量、设计决策可追溯到每个 commit。这不是「AI 写代码快」，是「harness 思维组织 AI 开发」。 这件事，恰恰是所有正在探索AI辅助研发（甚至是AI主导研发）的工程团队、乃至技术Leader或负责人们日日琢磨的核心命题——如何让AI提速的同时，守住工程严谨的底线；如何把AI从「脱缰的效率工具」驯化为「可控的研发协作者」。正因如此，这套从DSH 64天实战中淬炼出的方法论，绝非空泛的理论，而是值得每一支团队深思、拆解并落地的可行路径。 一、认知转变：从「用 AI 写代码」到「用 harness 组织 AI 开发」 市场上有四个比较成熟的 AI 辅助开发流派，先把它们摆清楚： 流派一：Copilot/Cursor 模式——AI 当打字员。人主导写代码，AI 补全和局部重构。这是目前最普及的模式，门槛低，但天花板也低——AI 只能在人画的圈子里做事，产出节奏受限于人的审查速度。 流派二：Claude Code/Codex 单 agent 模式——AI 当执行者。人给一个任务描述，AI 执行多步任务（改多个文件、跑测试、修 bug）。这是 Cursor Composer、Claude Code 的典型用法。天花板比流派一高，但问题是 agent 会自己跑偏，没有不变量挡着，跑几次就积累一堆边界情况。 流派三：Aider 模式——git commit 驱动。AI pair programmer，每次改动自动 commit，人通过 git history 审查。这个模式把 git 当成 AI 产出的审计层，是个好思路，但它只管「改了什么」，不管「为什么这么改」和「规则有没有被破坏」。 ...

网上已经有不少技术博主在拆 DSH 的架构图，把它和 Claude Code、Codex CLI 并列比较，论证这套「一切皆插件」机制的优雅和影响力——这些分析有它们的道理，我也认同 DSH 的设计水准。但我想看的不是它长什么样，而是另一个更工程化的问题：这样一个被 DeepSeek 视为战略级产品的 agent harness，是怎么在 64 天里被造出来的？ 答案写在仓库的 commit 历史里。从 6 月 10 日第一条提交到 8 月 13 日公开发布，64 天，12293 次提交，日均 192 次。这不是人类节奏，是 AI 辅助开发在版本控制系统里留下的沉积物。我用 git 考古翻了一遍这个仓库，反推一件更底层的事：顶级团队是怎么用 Agent 造出最强 Agent 的。事实上，Anthropic 的 Claude Code 团队和 OpenAI 的 Codex 团队大概率也是这么干的——只是他们的开发过程不公开。这次 DSH 把整个仓库开源，给了我们一个可以近距离观察顶级 AI 团队研发范式的窗口。这是我写这篇文章的起点。 三天前我写林俊旸把 20 亿估值押给 Agent，结论是他选了一条「模型 + 环境」的工程路线。文章里我反复引用 Lilian Weng 的判断：Claude Code、Codex 之所以强，不是因为底模最强，而是 Harness 设计最成熟。那篇文章发出去之后我一直在想一个更具体的问题：harness 到底长什么样？ 8 月 13 日，DeepSeek 给了一个可以拆解的样本。他们把内部那个叫 DeepSeek Harness（dsh）的 agent 运行时开源了，MIT 协议，221 个 npm 包。和它同步发布的还有 DeepSeek-V4-Pro 正式版，以及一篇 80 多页的论文《A Programming Paradigm for Spatiotemporal Composability》。 ...

大模型时代喊的"开源"，99% 不是你以为的那种开源。 当我们说 Linux 开源、Redis 开源的时候，意思很明确：把软件的"设计图纸"——源代码——全部公开，任何人都可以照着图纸把软件重新造一遍。这是软件的开源，公开图纸就等于公开一切。 但大模型的开源是一件根本不同的事。大模型的能力不在图纸里，而在一堆"经验"里——几千亿个数字，是用海量数据和巨额算力"喂"出来的，不是人一行一行写出来的。你可以公开这些数字，但别人拿到了也不知道你是怎么喂出来的。这是AI 的开源，它和软件开源之间的鸿沟，比大多数人意识到的要深得多。 深到什么程度？全球最权威的开源组织 OSI（开源促进会）在 2024 年 10 月专门发布了《开源 AI 定义 1.0》1，试图从头定义"AI 的开源到底应该是什么"——光是需要改写这件事本身，就说明传统软件开源的框架已经装不下大模型了。2026 年全国两会期间，中科院院士、阿里云创始人王坚更是直接呼吁：别再说"开源大模型"了，应该叫"开放权重模型"——因为你开放出去的不是一段代码，而是背后烧掉的电费和算力2。 这篇文章想做一件事：把大模型"开源"这个词拆开，一层一层看清楚里面到底装了什么。 大模型的"源代码"不是代码 软件开源的逻辑很简单：一个程序员写了一段代码，公开了，别人照着代码就能把同样的软件跑起来，还能改。代码就是全部，公开代码就是公开一切。 大模型完全不是这么回事。它的核心不是人写的代码，而是一种叫权重（weights）的东西——你可以把它理解成模型的"肌肉记忆"。就像一个厨师做了十年菜，他的手感、火候判断、调味直觉，全都长在身体里，不是写在菜谱上的。大模型的权重也一样：几十亿到几千亿个数字，是模型在海量数据上反复训练出来的结果。没有人能看懂这些数字具体是什么意思，但把它们加载到程序里，模型就能回答问题、写代码、做翻译。 关键区别在这里：公开厨师做好的菜，不等于公开他十年练出来的手艺。公开权重，不等于公开训练权重的方法。这就是 AI 开源和软件开源的根本区别。 所以，大模型的世界里，“源代码"这个概念被拆成了至少四层： 层 是什么 厨师类比 权重 模型训练出来的"肌肉记忆” 厨师十年练出来的手感和味觉直觉 推理代码 让模型跑起来的程序 把菜端上桌的流程 训练代码 从零训练模型的完整方法 厨师十年来的全部训练方法和食谱 训练数据 喂给模型学习的海量文本、图像等 厨师吃过的所有菜、看过的所有菜谱 传统软件开源，相当于把食谱和做法全部公开。大模型"开源"，大多数时候只是把做好的菜端出来，告诉你怎么加热和摆盘。 三种"开源"，差别巨大 明白了这四层之后，我们就可以看清楚：市面上号称"开源"的大模型，其实分成了截然不同的三种模式。 开放权重：给你成品，不给你生产车间 这是目前最主流的模式。Qwen、Llama 3、Gemma、Mistral——全球下载量最大的开源模型，几乎都属于这一类。 阿里的 Qwen（通义千问）是这个模式的典型代表。 你可以免费下载它全系列的模型——从轻量级的小模型到最新的 Qwen 3.5 旗舰版，附带使用说明和示例代码。你能拿它在自己的电脑或服务器上跑起来，用自己的数据做定制化训练（行话叫"微调"），甚至基于它做出更小的模型拿去商用。Qwen 的下载量已突破 7 亿次，全球开发者基于它做出的衍生模型超过 18 万个3——这个生态的繁荣，完全建立在"开放权重"这个模式之上。 但你拿不到的东西同样重要：Qwen 是怎么从零开始训练出来的？喂了什么数据？数据怎么筛选和清洗的？训练过程中几百个关键参数是怎么调的？模型怎么学会"像人一样说话"的？这些全都没有公开。你拿到了一个训练好的模型，但完全不知道它是怎么炼成的。 值得注意的是，即便同属"开放权重"，“使用条款"之间的差异也不小。Qwen 用的是最宽松的 Apache 2.0 协议——随便用、随便改、随便商用，没有附加限制。Meta 的 Llama 3 则有门槛：如果你的产品月活用户超过 7 亿，需要单独找 Meta 谈授权。Google 的 Gemma 更严格：明确禁止你用它的模型去训练竞品。同样叫"开放权重”，你能拿它做什么，差别可以很大。 ...

Qwen 的技术报告单篇引用超过 6000 次1，Hugging Face 下载量突破 7 亿次2，衍生模型超过 18 万个2。斯坦福《2025 年人工智能指数报告》把它排在全球第三3。然后，带着这一切走到今天的人，在凌晨 0:11 发了一条推文就走了4。 这两天 AI 圈讨论最多的不是模型，而是人。但我注意到一个有意思的现象：中文互联网上讨论的焦点是"阿里怎么了"“管理出了什么问题"“谁来接班”，而英文社区——从 Hugging Face 到 GitHub 到 X 的评论区——讨论的焦点是一个更本质的问题：开源社区到底需要什么样的人？失去这样的人意味着什么？ 这两种反应之间的落差，可能比林俊旸的离职本身更值得想一想。 全球顶级机构在用行动投票 艾伦人工智能研究院的研究员 Nathan Lambert 在 X 上写了一句话：“如果 Qwen 倒塌，在开放研究生态中留下的巨大空缺将很难填补。那些小模型是不可替代的。”5 Hyperbolic Labs 的 CTO Yuchen Jin 说：“一个时代的结束。“MiniMax、Unsloth、Ollama 都在林俊旸的推文下留言感谢。Hugging Face 亚太区负责人 Tiezhen Wang 说这是 Qwen 的"巨大损失”。智谱 AI 创始人唐杰评论说：“酷，开始新的旅程吧。” 而截至发稿，事情已经从哀悼升级为抢人。Google DeepMind 的 Omar Sanseviero 直接在 X 上向 Qwen 团队公开喊话6： Qwen friends: if any of you want a new home to build great models and contribute to the open models ecosystem, please reach out! ...

今天早上收到加州朋友Mike的邮件，附件是NVIDIA H200的内部评测报告。他在NVIDIA做架构师，每次有新品都会偷偷给我发点料。我盯着性能测试图看了半小时，H200比H100提升了35%，但真正让我倒吸凉气的，不是性能数字，而是CUDA生态的数据。 “全球95%以上的AI训练任务都跑在CUDA上，“Mike在微信里说，“我们刚更新了CUDA 12.5，专门优化了H200。那些想用AMD或其他芯片的公司，光是迁移代码就得花半年。“我回他：“所以NVIDIA已经不是芯片公司了，是AI时代的Windows？“他发了个笑脸：“差不多吧。” 但我心里在想：Windows当年也以为自己无敌，结果被移动互联网时代抛弃了。NVIDIA的CUDA生态，会不会也面临同样的命运？ 从表面看：性能数字背后的生态霸权 表面上看，这是"H200性能提升35%“的技术突破。但真正让NVIDIA无敌的，不是芯片性能，而是CUDA生态。 芯片性能可以追上——AMD的MI300X在某些场景已经接近H100，中国的昇腾910B在推理场景甚至超过H100。但生态壁垒一旦形成，几乎无法突破。全球95%的AI训练任务都跑在CUDA上，这意味着：即使你的芯片性能更强，开发者也不会用，因为迁移成本太高。 NVIDIA已经从一家芯片公司，变成了AI时代的Windows。Windows当年靠操作系统垄断PC市场，NVIDIA靠CUDA生态垄断AI市场。 要害在这里：这不是芯片战争，是生态战争。性能可以追赶，生态难以复制。 从深层看：中国芯片的差异化突围 想起上周去华为上海研究所拜访的场景。负责昇腾910B的李工带我参观实验室，指着一台堆满芯片的服务器说：“我们不跟NVIDIA在训练芯片正面死磕，昇腾910B专门优化推理场景。在智慧城市视频分析上，我们的性能已经超过了H100。” 不仅华为，寒武纪的思元590芯片正在给智能加油站做边缘计算，实时监控油枪状态、预测库存；地平线的征程6芯片在自动驾驶领域也有不错的表现。中国芯片公司选择了一条差异化的突围路径：不拼通用性能，而是深耕垂直场景，把特定领域的AI芯片做到极致。 去年在深圳参加AI峰会，看到一家创业公司用昇腾芯片做工业机器人实时控制，延迟比NVIDIA的方案低40%。美国的技术封锁反而成了中国芯片产业的催化剂——以前大家都觉得买NVIDIA的芯片就行，现在不得不自己搞研发。 翻出三年前的笔记，当时我判断"中国芯片10年内赶不上美国”。现在看来，我错了——不是赶不上，而是走了一条完全不同的路。NVIDIA在通用计算领域狂飙，中国芯片则在垂直场景深耕。 要害在这里：芯片战争的终局，不是谁的性能更强，而是谁能更好地服务用户。NVIDIA赢了通用性能，中国芯片可能赢了垂直场景。 从未来看：生态与场景的终极博弈 晚上刷朋友圈，看到Mike发了张NVIDIA总部的照片，配文：“H200发布，我们赢了。“我给他点了个赞，心里却在想：这场芯片战争，才刚刚开始。 NVIDIA赢了性能战，但可能输了未来。因为未来的AI应用，不是"一个模型跑遍所有场景”，而是"每个场景都有专属芯片”。当自动驾驶、智慧城市、工业机器人这些垂直场景成为主流时，NVIDIA的通用芯片优势还能保持多久？ 2025年，我判断会看到更多融合：NVIDIA会加强垂直场景优化（比如推出专门的自动驾驶芯片），中国芯片会加强生态建设（比如推出自己的开发框架）。 芯片战争的终局，不是谁的性能更强，而是谁能更好地服务用户。NVIDIA赢了性能战，中国芯片却可能赢了未来的场景战。 2025年，我期待看到NVIDIA的场景化，也期待看到中国芯片的生态化。