宝玉 (@dotey)

做一个下dsh和pi的对比 Pi 的目标是“最小核心 + 用户自己拼”，DSH 的目标是“几乎所有能力都插件化，官方先给你几套完整组合”。 DSH 的骨架是Cordis。 Cordis 不是普通插件加载器，它强调两件事： 1. 可逆副作用（temporal composability）：插件卸载时，注册的服务、事件、工具 schema、prompt section 全部自动撤销。 2. 依赖声明与空间组合（spatial composability）：插件通过 `inject` 声明需要什么服务，运行时按依赖挂载。 所以在 DSH 里： - 模型适配器是插件 - 工具注册表是插件 - session log 是插件 - agent loop 本身也是插件 - 甚至 UI 也是插件 没有“神圣不可动的核心”。你想换 loop、换工具策略、换上下文压缩，挂一个新插件 + 改配置就行。 启动时是 Profile + Bundle叠出来的： 空根 → dsh-base（模型、工具、沙箱、凭证…） → dsh-web-app 或 dsh-headless → 用户自己的 cordis.patch.yml → 命令行 --patch `dsh --profile web --dump-config` 能直接把当前实际挂载的树打出来。 Session 设计是硬核部分 Session 是 append-only 的事件流 模型最终看到的上下文，必须能从这条 log 完整重建出来。官方写得很死： > Model-visible means logged. 任何会进模型请求的内容，都要先变成 session event。 所以 fork、resume、回放、UI 渲染、telemetry，全部从同一条流投影。这点比大多数 coding agent 做得更彻底。 Turn / Step 有claudecode的影子，流程如下： turn/start → claim input → agent/pre-step（可拦截、可改写） → step/start → llm/stream → tool/call → tools/pre-execute → execute → post-execute → step/end → 继续 or turn/end `agent/pre-step`、`tools/*` 这些是 waterfall，监听者必须显式 `next()` 才能往下传。扩展点设计得很规整。 Pi 的实际交集 DSH 仓库里有一个包： `@deepseek-ai/dsh-llm-pi-ai` 它就是把 pi-ai当成 LLM 适配器的后端。 多 provider、协议兼容、reasoning effort 映射、catalog 覆盖，都走 pi-ai 的能力，再包一层 Cordis 插件契约。 所以： - LLM 调用层：吃了 Pi 的基础设施 - Agent 编排、工具、session、UI、沙箱：完全自己的 Cordis 体系 “LLM 适配层直接用了 pi-ai，上层重做了一套更重的可组合 Runtime”。 模式上的对应 DSH 的 Minimal 模式才最接近 Pi 的默认体验：只留 shell + 文件编辑器，专门给 benchmark 用。 官方之前在 V4 的 agent 评测里就用过这个模式。 Standard 模式和 Code（PTC）模式则是完整工具集 + 程序化工具编排，已经远超 Pi 默认的 4 工具。 如果你喜欢 Pi 那种“核心极瘦、自己动手加东西”的感觉，DSH 会显得重，配置和概念也更多。 如果你要的是可替换的 agent loop、完整事件回放、多模式预设、以及官方已经搭好的 Web 界面，DSH 的插件树和 seam 设计更系统。 一句话： Pi 是极简可扩展的 coding harness；DSH 是基于 Cordis 的完整 Agent Runtime，LLM 层复用了 pi-ai，但整体不是同一套代码。

又小型做了一个工具类Web应用站的实验，几乎隔一天就是一个订单。 复盘总结一下，分享一种工具类快速赚小钱的打法： 找一个正在赚钱的行业，自己冲上去做。不过不是真做，而是“假装做这个行业”，然后把整个流程走一遍（我用computer skill直接让AI跑，然后AI会有很多blocker或gate），这个时候 1/3👇

这篇 Pi 压缩的文章，太过于朴实无华，就真的只是写个 prompt 让 LLM 把上下文总结一下，然后保留前面的system prompt 和工具调用，在摘要后可能还会保留最近几次对话。 这种压缩是有损的，不知道是不是有机制会去历史会话检索上下文？ 当然这确实是压缩上下文的最简单有效方案。

AI Coding 最危险的阶它写得太快了，快到人开始不知道自己到底写了什么。 最近一次周会上，我们聊到一个很有意思的变化。 以前研发开站会，一个人通常能很具体地说清楚：昨天完成了哪个功能，今天准备实现哪段逻辑，明天要联调什么。 一个需求如果要做五天，也会自然地被拆成五个阶段。每一天都有一个明确的结果，Leader 能听懂进度，开发自己也知道代码正在往哪里走。 但接入 AI Coding 以后，事情开始变得不一样。 有些人拿到需求，第一反应已经不是先把目标拆清楚，而是把整份需求直接丢给 AI。AI 很快就能生成一大堆代码，原本预计五天的开发，可能第一天看起来就“做完了”。 问题来了，接下来的四天并没有因此消失。有时候会远远超过四天。 它们只是换了一种形式出现：不断改 Bug、反复联调、修好一个地方又弄坏另一个地方。 更麻烦的是，开发者自己也很难准确回答： 这次到底改了什么？ 哪些功能真的完成了？ 哪些只是页面看起来能跑？ 这段修改影响了哪些旧逻辑？ 于是出现了一个很反常的现象，代码生成速度越来越快，团队对开发过程的理解反而越来越模糊。 测试也被拖进了这个黑盒。 原本测试应该做的是验收需求是否实现，功能是否符合预期，质量能否达到上线标准。 现在却经常变成陪着开发一起找答案，为什么修完新问题，旧功能又坏了？ 表面看，AI 把“写代码”这一步大幅提速了；但如果需求没有被拆解，阶段结果没有被定义，变更也不可追溯，那么被省掉的开发时间，最后很可能会以 Bug、返工和沟通成本的形式重新付回来。 AI Coding 带来的核心变化让软件工程里原有的反馈机制被打乱了。 过去，代码写得慢，反而逼着人一步步思考：我要做什么、先做什么、怎样验证。 现在，AI 可以一次吐出大量结果，人很容易产生一种“已经完成”的错觉。但生成完成，不等于功能完成；功能能跑，也不等于工程完成。 AI 越快，人越需要主动制造检查点。 下一代研发流程真正要解决的，可能不是如何让 AI 再快 20%，重点应该放在如何让每一步结果都能被人理解、验证和追溯。 AI Coding 的终局也不应该是人把需求扔进去，然后等结果出来。 那不是软件工程自动化，只是把原来的黑盒换成了一个速度更快的黑盒。 真正成熟的 AI 研发体系，应该让 AI 负责加速，让人始终保有理解、判断和验收的权力。 所以 AI Coding 的上半场比的是谁生成代码更快；下半场比的会是谁能在这种速度下，仍然保持工程过程清晰、质量可控。 模型能力最终会逐渐趋同，但谁先建立一套适合 AI 时代的研发机制，谁才真正拿到了 AI Coding 的红利，而不是得到一堆写得更快的 Bug。 以上。

一个产品从工程师使用变成大众可用会发生非常多有意思的东西，这里非常推荐大家不要只做给你身边同类人用得上的工具，反而可以试试如何把这个工具变成甚至 70 岁的老爷爷也用得上的易用产品，非常有意思。 Mole 从单纯只能工程师能用的 Cli 变成易用的 Mac 桌面就发生了非常多有意思的事情，想分享给各位 Builder，期待有一些输入，这些内容从我历史和各种用户交流的邮件摘取。 第一位是一个来自英国的快70岁的老爷爷，他说“我犯了一个老年时刻，把 Mole 又买了一遍，它太好用了，第二笔钱就当做送你，谢谢这个出色的工具，帮我省下了比 cleanmymac 多得多的英镑”，然后我非常感激建议退款或者把多的授权送人，他去问了一圈，第二天回我 “我邻居没人用 Mac，我 Bluesky 上的关注者也没有。这一轮算我请你。”，这个过程让我感觉必须要把产品做得更好更友好，才对得起这份信任！ 第二位是一个美国的大哥，很有意思，纠正了我一个产品上对于地区习惯错误的想法，先是温度单位："美国人在所有技术相关的场景都用摄氏度，只有天气和体温例外。我装上 Mole 看到 110，吓了一跳。Apple 给美国人看的规格也是摄氏度，fastfetch、neofetch 在美式系统上默认也是摄氏度。建议保留华氏切换，但所有地区默认摄氏度。" 我之前一直错误以为对方用华氏，原来是我错误的观念，后面给改成默认摄制可选华氏，体验更好。很多时候你的不同地区的用户可以帮你改进你的产品很多地方。 因为他想买多台，我给他生成了一个5台32刀的价格，然后我改完之后他又追了一封谈定价："$32 买 5 台，$32 这个数字在美国人耳朵里很怪。几乎所有软件定价都以 9 或 5 结尾。$32 读起来不像是刻意定的价，像是从别的货币换算过来的，或者根本没经过思考。让一个普通 Mac 用户掏钱买一个要信任它删你文件的软件，本来门槛就比一般软件高。如果同时还让人觉得'外来'、觉得细节没打磨，你等于在给自己加难度。（我说外来不是指反华，而是人们希望感觉到作者理解他们。）我建议你把 $32 提到 $39，然后直接对标 CleanMyMac 一年的订阅费但给 5 个激活位。我不是营销专家，但如果你想听，我还有一些美国视角的想法。"，这个也给我非常不一样的视角的输入，原来，你的价格数字也会影响用户的决策，非常感激他！ 第三位，有一位国外用户的无障碍反馈，也让我对无障碍本身有更深的理解，mole 开始就做了无障碍，支持视觉有障碍的朋友使用，但是其实还有其他的用户可能有特殊场景诉求，他说 "看起来是个很不错的 App。可惜我用不了，它似乎把深色模式写死了。我有轻度视力障碍，深色背景上的白字对我非常难读。我系统设成浅色，也只用浅色模式的 App。如果哪天你把明暗模式做成可配置的（或者更好，跟随系统设置），我会再回来看看 Mole。" ，这个让我有动力以后给Mole 加上浅色兼容了。 第四位，一位德国拜罗伊特大学讲师，申请教育授权，说"不仅是对我个人的支持，也是一种有意义的教育层面的支持”，让我感受到原来还有国外老师用我的产品，我需要以后考虑给到教育一些优惠，相互帮助的感觉。 第五位，一位匈牙利的医生，给了一个最真实的差评，"说实话，这个价格对一个免费应用也能做到的事情来说有点高了。" 这个对我一些不同国家以后产品定价很有有价值，用户不是抱怨，而是抱着帮我定位问题心态讨论。 还有非常多的用户给我反馈，以后再给大伙分享有意思的地方，或者这也是做产品过程中，和用户持续打磨产品，对方由衷想着帮你把他也喜欢的产品打磨到最好的心态，会让你持续有动力把产品做好最深，或许这也是做产品过程中我感觉最有意思的地方，你的用户非常友好、善良、真诚，让你感觉非常温暖！ 一定一定不要放弃和你的用户交流的机会尽情听他们吐槽和建议，可以给你很多帮助，也让你更懂你的用户。

我不喜欢用 grill-me，可能因为我不擅长空想，也不喜欢被拷问。我需要那种看得见摸得着的东西才能进一步得出结论。 我更喜欢用 Claude Design 这种快速出一版原型，做出来一个真实的东西，才能感觉出来哪不对；或者 AI 写一份文档来理解方案，或者干脆 AI 实现一个 PoC 版本出来。 这在以前是很成本很高的事情，现在 AI 生成真的太容易了，所以对我来说不依赖 grill me 也还好。

AI时代就是要敢想啊，太励志了——协和的一个神经外科博士生金山木，本科北大地质专业，自学数学，用GPT-5.6解决了矩阵分析领域一个核心且著名的未解难题Crouzeix猜想（2004年提出）！ 已经得到Crouzeix本人在内的多位数学家确认。

把 DeepSeek Harness 的源码翻了一遍，发现一个挺有意思的变化： 它根本没把 Prompt 当成一段 System Prompt。 而是把 Prompt 做成了一个 Runtime。 大概是： Identity + Persona + Tool Guidance + Runtime Context + Tool Schema + Variables + Middleware 最后动态 Assembly 成模型看到的东西。 这意味着一个能力不再只是： Tool + Code 而是： Tool + Schema + Prompt Guidance 谁负责这个能力，谁就负责告诉模型“应该怎么用”。 比如 shell 自己拥有 shell 的 Prompt，filesystem 自己拥有 filesystem 的 Prompt，web 自己拥有 web 的 Prompt。 这其实很像软件工程里的模块化： Capability = Implementation + Interface + Model-facing Instructions 更有意思的是，它还把 Prompt 分成了不同 Scope。 Global Prompt ↓ Agent Scope ↓ Agent-specific Override 所以不同 Agent 可以继承、覆盖或者增加自己的 Prompt。 这就不是传统的： “给所有 Agent 塞一个巨大的 System Prompt” 而更像： Prompt Dependency Injection。 还有一个我觉得特别重要的设计： DeepSeek 把 Runtime Context 和 Prompt 分开了。 比如 cwd、git 状态、当前任务这些动态信息，不需要每次都修改稳定的 System Prompt，而是作为动态 Context 注入。 于是： Instruction = 我应该怎么工作 Context = 我现在处于什么状态 Tools = 我现在能做什么 三者被明确拆开。 甚至 Prompt 里的变量也不是简单的 string.format。 未知变量、malformed variable、重复 section 等情况，会倾向于直接 fail。 换句话说： DeepSeek 把 Prompt 当成了“程序”，而不是文案。 还有一个很容易被忽略的东西： Tool Schema 本身就是 Prompt Engineering。 Tool 的名字、description、参数描述、tool ordering、tool availability，都在影响模型行为。 所以模型最终看到的其实不是： System Prompt + Tools 而是： Instructions + Context + Capabilities 统一组装。 我觉得这才是 DeepSeek Harness 最值得研究的地方。 它真正想解决的可能是 “怎么构建一个可以持续演进的 Prompt Runtime？” 如果这个方向继续发展下去，未来的 Agent Prompt 可能不会再是一份几千行的 system prompt。 而会更像一个软件工程项目： /identity /persona /tools /context /agents /middleware /variables 每个能力自己携带自己的 Prompt。 Prompt 从“文案”变成“基础设施”。 这可能才是 Harness Engineering 真正有意思的地方。

智谱 AI（ GLM-5.3，和 GLM-5.2 共用同一个基座模型，所有提升都来自后训练阶段的强化学习（RL）。 【1】编程：开源阵营里最强，但离闭源前沿还有距离 GLM-5.3 在多个编程基准上拿到了开源模型（开放权重模型）的最高分。比如 Terminal Bench 3.0，GLM-5.2 只有 4.6 分，5.3 跳到了 28.3。DeepSWE v1.1 从 46.2 涨到 66.9，Agents' Last Exam 从 23.8 到 28.5。在智谱自建的 Code Bench 上，GLM-5.3 在 Max 级别用大约 7.5 万 Token 就达到了 34.5% 的完成率，而 GLM-5.2 用了 9.6 万 Token 才拿到 23.4%，能力和效率同时提升。 不过对照闭源模型，差距仍然存在。在 Code Bench 上 Fable 5 达到 39.5%，ExploitBench 上 Fable 5 拿了 78.0 而 GLM-5.3 是 54.4。整体格局是：开源第一，全局第二梯队。 【2】网络安全能力"涌现"：他们自己也没完全预料到 智谱说，他们在后训练中加入了漏洞发现相关的数据和环境，本来预期模型会在识别漏洞方面有所提升。结果超出了预期：模型不只是在找漏洞，还开始自主规划完整的漏洞利用链条。 数字上看，CyberGym（白盒源码审计）GLM-5.3 拿了 84.5%，全场最高，超过 GPT-5.6 Sol 的 83.6% 和 Fable 5 的 83.8%。ExploitBench（要求对真实漏洞进行更深层的利用推理）从 GLM-5.2 的 24.4% 跳到 54.4%，翻了一倍多。ExploitGym（限时完成漏洞利用任务数量）从 29/39 涨到 105/130。规律很明显：越靠近利用链的后端，进步越大。 智谱用了"涌现"（emergent）这个词，意思是这个能力不是他们专门去训练的，而是在扩大 RL 规模的过程中自然冒出来的。这个说法如果属实，对 AI 安全领域是个需要关注的信号。 【3】在 269 个开源项目中发现 2,436 个真实漏洞 跑分只是一面。更引人注意的是，智谱说从 GLM-5.2 开始就和国内安全团队合作，用模型扫描真实代码库。经专家审核和去重后，模型在 269 个开源项目中发现了 2,436 个漏洞，其中 1,097 个是中高危级别。涉及的项目覆盖了操作系统内核、浏览器引擎、网络协议等核心基础设施，有些漏洞在代码里藏了几十年，最老的一个可以追溯到约 40 年前。 目前 53 个漏洞已公开披露，2,383 个仍在保密期。智谱还上线了一个公开的漏洞披露追踪页面（ Security Disclosure Ledger），持续更新进度。 这和今年 4 月 Anthropic 公布 Claude Mythos 发现大量零日漏洞的路径很像，但有一个关键区别：Mythos 被美国政府严格限制了使用范围，只对少数审核过的安全机构开放。而 GLM-5.3 的权重将在两周后公开发布。一个能力接近的漏洞发现引擎，即将以开源形式进入公共领域。 【4】技术栈：用 slime 框架不换底座只加训练 所有这些提升背后的技术逻辑：不换基座模型，靠扩大后训练规模。 具体来说，智谱在 GLM-5.2 时期搭建了三个核心组件：IndexShare（长上下文处理）、SAO（长周期任务的 RL 算法）、以及开源的 slime 框架（大规模异步训练基础设施）。GLM-5.3 的做法就是在这套栈上继续堆：更多环境、更多样的任务、更多训练计算。 训练环境的设计也在变。新的环境不再像编程练习题，而是模拟资深工程师的真实工作场景，有些任务相当于一个有经验的工程师需要干好几天的活，比如在一个完整的 ML 基础设施环境里诊断训练瓶颈、实现优化、跑实验、交付可验证的端到端加速。 为了规模化生产这些训练环境，智谱还搭建了自动合成环境的流水线：研究智能体从真实工作中提取任务模式，生成可执行的长周期环境，评判智能体再验证任务是否可解。这套流水线仍然需要人工参与，但让环境的生产效率提高了很多。 【5】怎么用 API 已经上线，所有 GLM Coding Plan 用户都可以使用，支持 ZCode、Claude Code、OpenCode 等编程智能体工具。GLM-5.3 不再支持关闭思维链（thinking），只能在 low、high、max 三个思考级别之间切换。编程任务推荐用 max。 计费改为积分制，非高峰时段（工作日 14:00-18:00 北京时间以外的所有时段，包括周末）消耗标准积分的 50%。通过 ZCode 使用还能享受 98% 以上的缓存命中率和限时 1.5 倍额度加成，叠加后相当于标准额度的 180%，活动截止到 8 月底。 模型权重两周后公开发布。

我最近在 ~/.claude/CLAUDE.md 里面加了一段提示词，让它多开 SubAgent（Opus）去执行，这样我默认开 Fable 5 High，Token 消耗也不算厉害。 Fable 5 则主要做需求澄清、方案拆解、任务分发和结果验收。 之所以不用 Opus 5 是因为太太太慢了，而且 Token 消耗巨大！ --- 注意你的主要任务是分析、编排和验证，具体任务尽可能交给 subagent（Opus）去执行。当主 agent 是 Fable 5 时尤其如此：自己只做需求澄清、方案拆解、任务分发和结果验收，实现类工作（读大量代码、写代码、跑测试、批量修改）一律用 Agent 工具派给 Opus subagent 执行。

我最近在 ~/.claude/CLAUDE.md 里面加了一段提示词，让它多开 SubAgent（Opus 4.8）去执行，这样我默认开 Fable 5 High，Token 消耗也不算厉害。 Fable 5 则主要做需求澄清、方案拆解、任务分发和结果验收。 之所以不用 Opus 5 是因为太太太慢了，而且 Token 消耗巨大！ --- 注意你的主要任务是分析、编排和验证，具体任务尽可能交给 subagent（Opus 4.8）去执行。当主 agent 是 Fable 5 时尤其如此：自己只做需求澄清、方案拆解、任务分发和结果验收，实现类工作（读大量代码、写代码、跑测试、批量修改）一律用 Agent 工具派给 Opus 4.8 subagent 执行。

DeepSeek 开源的第一个 agent harness DSH，论文里堆满了范畴论符号，很容易让人觉得又是研究员在真空里搞出来的理论产物。但在仔细读完源码并与 Codex 逐行对照后，我的工程判断很明确：对绝大多数日常写代码的开发者来说，它重得毫无必要；但对探索自进化 agent 的工程团队来说，它搭建了一套目前其他方案完全没有的底层骨架。 架构上最本质的差距在于插件模型的选择。 Codex 代表了典型的声明式路线：插件只是磁盘上的文件夹，贡献的是 Markdown 写的 skill 文件、MCP server 配置或 shell 脚本。插件不进 harness 进程，也不在同一进程里跑代码，改完配置重启独立进程只需两三秒。对于搜索、加工具这类绝大多数日常需求，声明式模型简单可靠，门槛接近于零。 DSH 走的是命令式路线：插件带着自己的状态，直接跑在 harness 进程内部，互相注册与调用。一旦要在运行时替换插件，悬空引用清理、后台任务终止、依赖链协同以及崩溃回滚都会变成棘手难题。为此，DSH 引入了一套叫 Cordis 的重型运行时，单是管理 fiber 生命周期的核心模块就有 750 行代码。 如果只是为了替换搜索服务或挂载常用工具，让开发者背上 Cordis 这套复杂度完全是过度设计。但 DeepSeek 包这盘饺子的真实意图，隐藏在控制流结构里。 在 Codex 中，agent loop 的控制流被硬编码在 Rust 核心逻辑里，开发者只能在预设时刻挂载 hook，无法在运行时把单 agent 循环改成多 agent 协作循环。而在 DSH 里，agent loop 本身是放在 packages/core/agent-loop 中的一个普通 TypeScript 插件，向外提供 ctx.agentLoop 服务。只要实现相同的接口，运行中的控制流骨架随时可以整体卸载并替换。 Cordis 打造的那些副作用跟踪、依赖变动通知和事务性 HMR，本质上全是在支撑 agent loop 可替换这个核心目标。它保证了 agent 在运行期如果动态生成了新工具或新 loop，系统能在不中断进程的前提下平滑加载；一旦生成的代码出现错误，又能通过事务性回滚退回上一个稳定状态。 Codex 交付的是结构固定的成品家具，而 DSH 交付的是允许动态改造的生成内核。DSH 不会让你的日常 coding 变得更快，但它让 harness 本身具备了面向自进化进行物理扩展的可能。 深度剖析与两套架构的完整对照：

DeepSeek 作为一个模型厂商，最有价值的肯定还是做 Agent Harness Product 而不是 SDK，因为 SDK 它不容易拿到用户行为数据。 做 Agent Harness Product 那就得追求用户量，追求用户量就要先做好用户体验，其次才是插件可定制化。