机器之心修改

Google 的 AI 战争，或正在朝着一个更激进的方向前进：让 AI 开始参与创造下一代 AI。

据路透社最新报道，Google 联合创始人谢尔盖・布林（Sergey Brin）近几个月正在深度介入公司的 AI 研发，虽然已经没有正式的管理职位，他依然借助联合创始人的影响力推动模型训练，并要求关键 AI 员工全力投入 Gemini。

其中一个被 Brin 明确推动资源投入的方向，就是递归式自我改进（Recursive Self-Improvement，RSI）。

这也是当下硅谷最热门、最受关注的方向之一。

5 月，Anthropic 专门发布了一篇题为《When AI builds itself》的文章，来阐述对 RSI 的认知和当前所取得的进展。7 月底，OpenAI 也重新召回旧部 ——Thinking Machines Lab 联创翁荔，让其领导专注于 RSI 的研究团队。

而就在前几天，刚刚出走 Google 的前首席科学家 Jeff Dean，创业目标也直指 RSI—— 让 AI 自己跑实验、评估结果、修正弱点，并持续迭代。

如今，Google 自身也要「重押」RSI 了。

Brin 再次进入「创始人模式」

据路透社报道，一名了解内情的人士曾透露，过去几个月，Brin 一直告诉 Google 的关键 AI 员工：团队必须重新追上最前沿。

这样的剧情是不是有些熟悉？

当年 ChatGPT 发布后，面对汹涌而来的竞争压力，Brin 以「创始人模式」回归，还亲自写代码，并在内部开始大刀阔斧的整合，将 Google Brain 与 DeepMind 合并为 Google DeepMind，之后推出 Gemini 3，一举扬眉吐气，强势回归。

而如今，Google 无疑又有些「落后」了。截至今年 8 月，Google 新一代 Gemini 旗舰模型的发布日期推了又推，足足推迟了约两个月，而内部测试也显示，新模型在编程等关键领域依然落后于竞争对手。

与此同时，Google DeepMind 的权力结构也在发生变化。

8 月 5 日，Google 宣布调整 DeepMind 管理层。长期领导 DeepMind 的 Demis Hassabis 转任董事长，减少日常管理职责；此前担任其副手、同时兼任 Google 首席 AI 架构师的 Koray Kavukcuoglu 则进一步接管 DeepMind 的运营，并继续负责 Gemini。

Kavukcuoglu 其实早已是 Gemini 背后的关键人物。

据路透社报道，在过去一年多里，随着 Hassabis 减少对 Gemini 日常研发的直接参与，Kavukcuoglu 逐渐接手模型开发，并成为技术路线和资源配置的重要决策者之一。一名知情人士称，他同时获得了 Brin 的支持。

这让 Google AI 业务的权力中心进一步向 Mountain View 靠拢。

Kavukcuoglu 去年从伦敦搬到 Google 总部，并出任 Google 首席 AI 架构师，直接向 CEO Sundar Pichai 汇报。在此之前，他已经是 DeepMind 和 Google Cloud 之间的重要联系人。

这段关系很关键，因为 Cloud 不仅是 Google AI 商业化的重要出口，同时也是算力资源争夺最激烈的部门之一。

模型训练需要 TPU，Cloud 业务同样需要 TPU，而 Google 内部的计算资源并不是无限的。路透社援引知情人士称，Google Cloud 的一些高管希望，Kavukcuoglu 新的职位能够减少此前围绕 TPU 分配产生的内部摩擦。Sundar Pichai 此前也表示，Google 将继续扩大 AI 基础设施投入，以缓解 TPU 等计算资源的约束。

某种意义上，这也是 Google 现在面对的问题：模型能力是一回事，组织能不能快速把人、钱和芯片集中到正确的方向，是另一回事。

过去几年，Gemini 的研发就受到过这些结构性问题影响，对此网友的吐槽也从未停止过。

多名知情人士告诉路透社，算力不足、项目负责人之间的分歧以及大型公司的决策流程，都曾拖慢 Gemini 的迭代速度。在编程等后来被证明重要的能力上，资源配置也一度不够集中。

这可能解释了为什么 Google 明明拥有庞大的研究团队、芯片和产品生态，却仍然时常出现「追上 — 被反超 — 再追」的节奏。

现在，Google 显然希望把这个循环压缩得更快一点。

DeepMind 正在「Google 化」

此次重组之后，DeepMind 与 Google 之间的边界也在进一步模糊。

在 8 月 6 日的全员会议上，Hassabis 和 Kavukcuoglu 告诉员工，日常研发工作不会发生太大变化。但据知情人士透露，一些非技术团队将从 DeepMind 转移到 Google 的公司汇报体系中。

2014 年被 Google 收购后，DeepMind 一直需要在两个目标之间寻找平衡：一边是基础研究、科学和长期 AI 问题，另一边是把模型真正做进 Google Search、Google Cloud、Workspace 以及其他产品。

如今，天平正在越来越明显地向 Gemini 和商业落地倾斜。

与此同时，一些资深研究人员的离开，也让内部员工更加关注 DeepMind 未来还会保留多少研究自主权。

路透社称，包括 Gemini 早期技术负责人 Jeff Dean 和 Oriol Vinyals 在内的一些资深研究人员已陆续离开。此前部分团队拥有较大的研究自主权，可以开展与 Gemini 模型训练没有直接关系的项目，但随着管理结构重新调整，这些项目未来如何定位，目前尚不完全清楚。

在这一背景下，Brin 推动递归式自我改进，也体现了 Google 当前 AI 战略的一个变化：公司不仅希望 Gemini 在排行榜或者单项评测中重新取得竞争力，也希望提高研发体系自身的效率。

Google 实际上已经在尝试一些相邻方向。DeepMind 此前推出的 AlphaEvolve 系统，可以借助大模型和自动评估机制寻找更好的算法方案，并用于优化部分计算和工程问题。这类系统距离「无需人类参与、自主升级自身」的完整递归式自我改进还有较大差距，但已经展示出一种可能的研发模式 ——AI 首先成为 AI 研究人员和工程师的工具，然后逐步承担更多实验设计、编程、优化和验证工作。

这一方向也并非 Google 独有。随着模型代码能力提高，OpenAI、Anthropic 以及多家 AI 实验室都在探索利用模型辅助甚至自动化部分 AI 研究和工程流程。行业内部讨论的重点，也逐渐从「AI 能否写代码」，转向「AI 能够在多大程度上参与下一代 AI 的研发」。

不过，目前将这些进展直接等同于完全意义上的递归式自我改进仍为时尚早。现阶段的大多数系统仍然需要人类设定目标、提供计算资源、选择实验结果并决定是否部署下一版本。所谓完全开放、自主且持续的自我改进机制，目前尚未成为公开可验证的现实。

但和上一次回归相比，这一次 Brin 关注的已经不只是如何追上某一个竞争模型。

Google 正在尝试解决一个更基础的问题：在模型能力迭代越来越快的环境下，能否让 AI 研发本身也变得更快。

而「递归式自我改进」，正在成为 Brin 给出的其中一个方向。

那么你呢，如何看待 Google 的这一重押方向？看好 Brin 的再次「出山」？欢迎在评论区留言、交流！

参考链接：

https://x.com/AndrewCurran_/status/2087604895839064099?s=20

https://www.reuters.com/world/inside-google-executive-moves-that-led-its-big-ai-reshuffle-2026-08-12/

https://x.com/kimmonismus/status/2087623474672021550?s=20

https://x.com/firstadopter/status/2087634147384660090?s=20

© THE END

转载请联系本公众号获得授权

投稿或寻求报道：[email protected]

能说会道，不如做到

一件原本可能要在医院折腾大半天的事，最终足不出户便得到了解决。对一位正在照顾发烧孩子的母亲来说，这是她打开京东健康 AI 医生「大为」（以下简称「大为」）时完全没有想到的。

京东健康医疗 AI 产品总监刘慧至今记得这个故事。此前在广州的一次合作洽谈中，对方主动向她讲起了这段经历。

她和我一样，也是一位母亲，刘慧说。那天孩子发烧后，这位母亲没有像往常那样立刻请假、打车，带着孩子去医院，而是决定先问问「大为」。

这是一个几乎秒回且免费的就医入口。

京东APP直接搜索「AI医生」找到他，或者进入京东APP「 看病买药」频道来使用。响应快，对于需要更强烈的信任背书的用户，「大为」身边就有真人医生的服务入口。

几轮问询后，「大为」建议孩子接受一次核酸检查。接下来发生的事情，与人们熟悉的就医过程不太一样：专业人员上门完成采样，母亲和孩子留在家里等待结果。大约两个小时后，检测报告回传到 App 。

「大为」对报告进行解读，并结合此前了解到的情况，给出了后续用药建议。用户选择在京东平台在线购药，没过多久，药品也送到了家。

这个看似普通的家庭切片，正是医疗 AI 跨越「 聊天搭子」，扎入现实服务深水区的一个缩影。一组最新财报数据，又为这一跨越提供了更为清晰的注脚。

8 月 13 日，京东健康公布 2026 年中期业绩：总收入为人民币 409 亿元，同比增长 15.9% ；非国际财务报告准则指标下（ Non-IFRS ）经营利润 35 亿元，同比增长 40.3% 。

在收入和利润之外，AI 成为这份财报中一个极为醒目的关键词。以「 AI 医生」为核心的一系列 AI 应用正在加速落地，在绩后电话会上，管理层也数次提到了「大为」。

目前「大为」已覆盖超过 1000 种中西医病症。财报数据显示，「618」 期间，「大为」服务用户数同比增长近 4 倍，满意率保持在 98% 以上。

这些数字的背后，某种程度上正是前述就医场景的规模化复制，也折射出医疗 AI 范式变化带来的真实红利。

不少医疗问答产品能够解释疾病、提供知识。但回答结束后，用户的行动成本几乎没有减少，刘慧说。一位母亲问孩子发烧怎么办，她不是来学习儿童发热的医学原理。她真正想知道的是现在危险吗？要不要检查？还能不能观察？该不该吃药？如果吃药，吃什么？

所以，我们希望依托京东现有的供应链和服务能力，把生病这件事尽可能管到底，她说。这也正是「大为」与普通医疗问答产品之间最根本的区别。

财报里的 AI 医生，用起来怎么样？

作为上半年京东健康「 AI 全场景落地」的核心产品，「大为」是怎么工作的？ 又凭什么留住客户？要理解这一点，最直接的办法还是回到具体问诊中。

「 8 岁孩子突然高烧，38 度。」 抛出一个模糊的主诉后，我很快感受到不同。

「大为」没有立即甩出几段「正确的废话」，而是先追问发热持续了多久？有没有咳嗽、流涕、呕吐、腹泻或者头痛？

这些问题并不是一次性出现的。每得到一个回答，「大为」才会决定接下来问什么，就像医生在门诊里逐步收集病史。

一些原本不容易用语言描述的症状，也被做成了可视化选项。我不必准确说出疼痛处于哪个部位、症状发展到了什么程度，只需要在人体图示或分级图片上进行选择。这种设计减少的不只是打字时间，也降低了描述症状的门槛。

经过三四轮对话，「大为」开始基于已经收集到的信息进行推理，将原本笼统的模糊的「孩子发烧」逐渐细化为结构化症状信息，给出可能性最大的「急性上呼吸道感染」提示（见图片黑体部分）。

末了，还附上 14 篇参考医疗文献。

进入治疗建议后，「大为」没有简单列出几种药品，而是区分了对因治疗和对症治疗。这也是一般临床决策逻辑的体现。例如，对乙酰氨基酚被用于缓解发热和头痛症状。

到这里，许多医疗问答产品的工作已经结束。「大为」却继续将治疗建议拆解成满足客户需求的不同流程。

• 对乙酰氨基酚混悬滴剂被匹配到具体药品；

• 进入问诊开方流程；

• 平台根据用户在我的地址，调取附近药房的库存、价格和配送时效，最快可在 24 分钟内送达。

据刘慧介绍，在不少医疗问答产品中，约七成用户完成第一次咨询后，不会再发起第二次问询，最后仍然回到线下医院。问题未必只是答案够不够准确，而在于用户是否获得了足够明确的「解决感」。

「要让用户用过一次以后能够记住：这个问题在这里确实得到了解决。下一次再遇到健康问题时，他才会回来。」她说。

不过，在医疗场景中，「管到底」并不意味着大包大揽。很多时候，AI 是否可靠恰恰取决于它是否知道应该在哪里停下来。

这两个真实问诊案例，恰好呈现了这种边界感。

一位用户最初只是询问左腿肿胀，究竟是腰椎问题，还是腿部血管出了问题？随着问询深入，更多风险信号逐渐出现：肿胀加重，伴有麻木、刺痛、明显乏力，同时还有腰痛、行走不稳和腿软无力。用户还患有高血压。

「大为」没有继续在线上给出确定诊断，而是提示，既要考虑腰椎神经受压，也需要排查下肢静脉血栓，并建议尽快前往骨科、血管外科或神经内科面诊。如果出现胸痛、呼吸急促或意识异常，应立即前往急诊。

面对风险较低的日常不适，「大为」的决策又会不同。

一名身处偏远地区的用户，因为脚趾出现硬块、按压疼痛并影响走路，向「大为」发起咨询。结合用户上传的照片和几轮问询，它判断，这更可能是长期运动和鞋袜摩擦造成的角质增厚。

于是，「大为」先给出可以在家完成的处理方式：调整鞋型、减少摩擦、温水浸泡，必要时使用软化角质的外用药。只有在疼痛加重、出现破损感染，或长期不缓解时，才需要前往皮肤科。

炼成「大为」，需要多少慢功夫？

「大为」能追问、能判断、知道什么时候该停，也能把一个医学建议继续向现实服务推进。如果把这些能力拆开来看，恰好对应了京东健康在此次中期业绩中反复强调的几个关键词：数据、场景和履约。

听起来并不新鲜。当它们被放进一个 AI 医生里，分别意味着什么呢？

刘慧说，立项之初，「大为」就被定位为一名全科医生。因为只有全科才能真正「接住」互联网医疗中最常见的需求，如常见病咨询、日常症状判断、用药疑问和检查报告解读。

只不过，支撑这一定位底气的，大多是藏在对话框之外的「笨功夫」。它们严谨、琐碎，难以速成，也很难复制。

要培养这样一名全科医生，首先遇到的挑战就是让它听懂用户在说什么，并知道下一句话该怎么问。

患者从来不会按照教科书描述自己的病情。「我刚才晕倒了」，可能只是头晕腿软，但意识一直清醒；也可能经历了短暂意识丧失，也就是医学意义上的晕厥；还可能与低血糖、癫痫、心律失常等问题相关。

对「大为」来说，这并不是从一句话里识别出「晕倒」几个关键词就结束了。它需要完成一次「医学语义落地」：把口语化、模糊，甚至矛盾的表达，转化为可以用于临床判断的信息。

听懂的同时，它还要知道接下来该问什么。

医生问诊，不是问得越多越好。每一轮对话，都要寻找当下最关键的未知信息，比如哪一个问题最有可能缩小疾病范围，或者尽早发现危险。

这本质上是一个序贯决策过程。等可能性逐渐收敛到一定方向后，才会进入更具体的诊疗路径。

「大为」学习这种问询方式的基础，来自京东健康长期积累的互联网医疗场景数据。据京东健康披露，高质量医患对话数据已达到千万级。

通常，传统医院病历记录的是诊疗链条的终点：患者的主诉、医生的诊断、最终的治疗方案。但医生如何从一句含糊的描述中发现关键线索，如何通过连续追问排除风险，并不会被完整记录下来。

而这些中间过程，恰恰是「 大为」学习临床思维最需要的部分。

真实的线上问诊，会记录医生一轮一轮问了什么、患者怎么回答、医生如何把一个模糊症状逐步澄清并收敛到具体判断。不过，真实对话并不会自动变成可供机器学习的临床逻辑。京东健康还要和全职医生团队、合作专家一起，把「为什么要这样问、为什么要这样判断」的专业逻辑整理出来，用于模型训练。

这些都是数据层面「最大的壁垒，用钱也买不来」。刘慧说。

仅仅学会听懂和追问，还不足以成为一名可靠的AI医生。在医疗场景中，「听起来合理」远远不够。「大为」的每一次推理判断，都必须被放进一条相对明确的临床轨道中。

除了在问诊过程中调用医学指南、文献和诊疗路径进行校验，团队还建立了 300 多条标准诊疗路径，覆盖线上超过九成的高频疾病。

所谓诊疗路径，是将医生脑海中相对隐性的决策经验，拆成一条条能够执行、检查和复盘的链条：应该先问什么，容易与哪些疾病混淆，依据什么作出判断，是否需要检查，什么时候可以继续在线处理，什么时候必须转交真人医生或建议前往医院，以及治疗后如何复诊和随访。

这些路径，是由京东健康的全职医生团队联合行业专家，参考权威指南和临床资料，并结合互联网问诊、医药电商和平台服务的特点共同建设。

其中也包括一些互联网医疗特有的步骤。比如遇到皮肤问题时，系统需要引导用户从合适的角度拍照；医学指南更新、新药上线，或者平台新增一种检测服务，相关路径也要随之调整。

如果说诊疗路径规定了一次问诊应该如何向前推进，那么，结构化或半结构化的医学规则，更像是在关键节点上设立的「护栏」。

在诊断、风险识别和用药等核心环节，「大为」会借助这些规则降低大模型幻觉带来的风险。

比如，当系统判断用户可能存在心肌梗死、脑卒中或严重出血时，它不会继续沿用普通问诊流程，而会切换到危重症路径：提示风险，解释原因，并明确建议尽快前往医院。

一旦用户的年龄、病史、过敏情况或正在服用的药物触发禁忌条件，相应药品就不应继续被推荐。

为了确保「大为」始终在既定的临床轨道和安全护栏内运行，团队为整个服务流程设置了 109 项质检标准。模型上线前，需要在典型病例上接受离线评测。上线后，专门的质检模型会持续筛查真实问诊，并将发现的问题交由全职医生复核，形成一套不间断运转的巡检机制。

完成医学判断后，「大为」还要面对最后一道、也更现实的难题：如何让这些决策在京东健康现有的服务体系中真正发生。

这并不是在回答末尾简单附上一排服务入口。

处方审核、药品库存、检测能力和配送时效等现实条件，需要直接参与方案的生成。换句话说，系统不仅要知道医学上应该怎么做，还要知道在用户所在的地方，这件事能不能做成。

以用药为例，「大为」在给出建议时，不仅需要判断哪些药物在医学上适用，还要同步了解用户所在地区能否买到，哪些药品可以合规销售，哪些必须由医生开具处方，以及用户是否处于急性发病阶段，需要尽快拿到药物。

假如有三种药物在医学上都适用，但用户附近只有其中两种能够快速配送，系统就不能停留在一个理论最优的答案里。它需要在现实可获得的选项中，继续权衡安全性、时效与成本。

因此，它完成的并不只是一次药物推荐，而是一次规划和调度：把医学判断与处方审核、药品库存和配送能力连接起来，确保一个方案不仅在屏幕上成立，也能够以合规、及时的方式真正抵达用户。

这也是「大为」背后最难被复制的一部分。

模型能力可以在几个月内迅速迭代，但药房网络、医生资源、上门检测和即时配送等现实世界中的基础设施，很难以同样的速度搭建起来。

「这种物理世界里的履约能力，不是三个月、半年就能追上的。」刘慧说。

Always on：从一次问诊走向长期管理

其实，把一次生病「管到底」，并不意味着医疗服务就此结束。

在加入京东健康之前，刘慧曾是北京大学第三医院神经科医生。那段临床经历让她深刻意识到，传统医疗体系很难持续覆盖患者离开医院之后漫长的管理周期。

「特别是脑梗、脑出血患者，往往需要长期服药、坚持康复，并持续控制危险因素。」刘慧回忆，一些患者在住院期间恢复得不错，出院后因为自行停药、中断康复训练，或者没有持续监测血压等指标，在几个月后再次复发。

「医生其实很无奈。」她说。

在中国，像这样的慢病人群已超过五亿。真正决定长期预后的，恰恰是离开医院后的几年甚至几十年。按时服药、定期复查、调整生活习惯、捕捉异常信号——这些看似琐碎的日常，却决定着治疗效果能否延续。

这正是「大为」从「单次问诊」走向「长期健康管理」的现实起点。

目前，「大为」正在探索诊后主动管理服务。如在秋冬流感高发期到来前，对患有慢阻肺的老年用户主动提醒接种疫苗，降低重症风险。还可以进一步延伸至服药提醒、复查提示和异常指标跟踪等场景。

要做到这些，「大为」就要记得住。

刘慧解释说，在获得用户授权的前提下，系统会借助「长期记忆」，将原本分散在不同时间节点上的问诊、用药和检查信息串联起来。「大为」不仅要记住用户提过什么问题，还要记住长期健康状态变化，比如存在哪些潜在风险、使用过哪些药物、指标有何波动，以及接下来需要重点关注什么。

其实，「大为」立项之初，我们就赋予了它一个更长期的定位，成为用户及其家庭成员身边一名「 Always on 」的专业健康指导医生，刘慧回忆说。我们希望先从一次具体的问诊出发，逐步延伸至诊后的用药复查，并最终迈向诊前的风险预防。

如今，从更大的行业坐标来看，这条路早已不孤单。

随着「健康中国」战略强调推动健康管理关口前移与疾病全链条管理，政策红利正加速释放——从北京等地相继出台的 AI+ 医疗健康新政，到明确提出推动二三级医疗机构电子病历与影像全面接入，这一切都为主动式、长程 AI 健康追踪构筑数据底座。

在海外医疗体系中，数字入口也在越来越多地连接预约、处方、检查结果和后续医疗服务。

站在京东健康的 AI 叙事维度，我们应将目光从财报数据中那亮眼的 4 倍增长中抽离出来。

如果「大为」能够将触角从单一的咨询，深度延展至检查、问诊、用药、履约，再到复查、随访与风险预防，那么，京东健康所构建的就不再仅仅是药品交易的货架，而是用户长周期生命健康的「服务资产」。

当竞争的维度从单纯的流量竞争，上升为数据、场景与履约构成的全链路闭环，医疗服务便不再是患者走出医院后的「断片儿」，而是一种持续、主动的守护。

这或许才是重估京东健康 AI 商业价值时，真正值得被看见的底色。

© THE END

转载请联系本公众号获得授权

投稿或寻求报道：[email protected]

AI 写的文章以后真藏不住了。

OpenAI 官方公告，包括 OpenAI、Anthropic、Google、Meta、Microsoft 在内的一大批公司，签署了欧盟《AI 生成内容透明度行为准则》，承诺推进 AI 生成内容的标记与检测。

OpenAI 表示，根据其对欧盟 AI 生成内容透明度准则的承诺，目标是将来源信号扩展至包括文本在内的所有模态。

看起来 AI 内容马上也要有「署名」了。

最近许多前沿公司都在拓展欧洲业务，但欧盟的规矩可谓是相当多，这个《AI 生成内容透明度行为准则》就是其中之一。

从 8 月 2 日起，欧盟法案中关于内容透明度的要求就已经生效：AI 生成或操纵的文本、图像、音频和视频，需要以机器可读的方式进行标记，并且能够被检测出来。

不过签署准则是一回事，真要说因此行动的，Claude 是第一个。

Claude 的「署名」规则

不久前，Anthropic 公布了 Claude 落实这套规则的具体方案。

链接：https://support.claude.com/en/articles/16266773-how-claude-marks-ai-generated-content

重点有几个：

1、从 8 月 2 日起，如果在欧盟推出的新 Claude 模型，「AI 水印」将在上线时就启用；

2、「AI 水印」直接嵌入生成文本中，人眼不可见，但机器可以检测。复制粘贴之后水印会保留，甚至经过一些编辑后水印也不一定消失；

3、对于 svg、png、jpg 等文件，Claude 会附加经过数字签名的来源元数据，采用 C2PA 开放标准。这样的「AI 水印」可以表明文件曾经由 Claude 处理，同时帮助判断文件之后是否遭到篡改。

4、虽然是欧盟的规则，但这套机制不局限于欧盟用户。并且水印从模型层加入，无论从 Claude、API 还是第三方云服务调用，在 Claude 生成的内容都会带上「AI 水印」。

除了这些，根据欧盟给出的过渡期，Claude 的旧模型也应该在 12 月 2 日之前补上「AI 水印」。

也就是说，按目前的节奏，到 12 月 2 日之后，Claude 的「AI 水印」将进一步覆盖全球、全模型、全渠道。

对于其他签署公司，情况也是如此，只不过方法可能有所不同。

水印其实早就有了

关于怎么加「水印」，Anthropic 表示还要等后续技术文档。

不过这种文本水印本身不是什么新鲜概念。

早在 2024 年，DeepMind 就公开过一套「SynthID Text」方案，并且已经用在了 Gemini 和 Gemini Advanced。

论文链接：https://www.nature.com/articles/s41586-024-08025-4

如果因为「水印」这种说法，联想图片里的覆盖性 logo，那可以就错了。

SynthID 会在大模型生成文字的过程中，对 token 的生成概率做非常轻微的调整，让模型一次次选词时留下特定的统计规律。等整段文字生成完成，这些选择累积起来，就形成了水印。

检测时，再反过来检查这些词语选择是否符合带水印文本应有的统计模式。

Google 公开的测试显示，裁掉部分文本、修改少量词语或轻度改写时，仍然可以检测出信号；但如果彻底重写或者翻译成另一种语言，检测置信度就可能大幅下降。

并且 Google 还曾在接近 2000 万条 Gemini 真实响应中测试这套方案，结果显示，加入水印后用户对文本质量的评价基本没有变化。

「署名？这真是你写的吗」

这事一出，网友都在喊「退订」。

「水印」本身的可信度遭到了质疑，连 Anthropic 自己都提到，有「水印」不一定就是 AI，同时，经过大量改写或者混入人工内容，「水印」也会被削弱，甚至检测不出来。

评论区还有一种声音：使用什么工具不重要，重要的是最终质量。

通常来说，读者或者观众担心的是 AI 内容是否真实可靠。那么特意强调「这部分用了 AI」，其实有「提醒读者注意核查事实」的意味。

在这个过程中，原本属于内容生产者或者平台的核查压力，可能在不知不觉中被推向读者和接收者。

另一方面，既然要打「水印」，那这就不得不反问一句：这真的能算是「AI 写的」吗？

你怎么看？

© THE END

转载请联系本公众号获得授权

投稿或寻求报道：[email protected]

今天凌晨，DeepSeek V4 Pro 正式版发布，引发热潮。现在，半天过去，DeepSeek Harness （开发者预览版）也来了！

当然，这并不意外，毕竟该项目之前已经铺垫了很久了，比如 DeepSeek Harness 团队的崔添翼就一直在社交网络上发预热贴以及为该团队招募人才。

我们也在 8 月初获得了 DeepSeek Harness 的内测资格，提前享受到了这个注定又会给 AI 社区带来新变革的智能体框架。

开源地址：https://github.com/deepseek-ai/deepseek-harness

比如这里，我们让配置了官方 DeepSeek-V4-Flash 的 DeepSeek Harness 我们构建了一个第一人称丧尸射击游戏。我们没有中途施加任何干预，就在 30 多分钟得到了一个虽不完美但已经相当可玩的成品：

考虑到近日 Andrej Karpathy 用 AI 生成 3D 世界的思路非常火爆，我们也让 DeepSeek Harness（V4-Flash）挑战了「华强买瓜」基准：基于文本描述将「华强买瓜」经典片段复现成 3D 动画（同样是 one-shot 提示的结果）：

整体来看，虽然离完美距离还很远，但这个动画的故事剧情大体还原，人物关系也大体能看出。相较之下，我们使用同样提示词，用配置了 GPT-5.6 sol-xhigh 的 Codex 制作出来的动画就差多了：

要知道，DeepSeek-V4-Flash 的参数规模远低于 GPT-5.6 sol。可以想见，DeepSeek Harness 应是立了大功。

今天随着 DeepSeek V4 Pro 正式版的发布，我们也将该模型接入了 DeepSeek Harness 再跑了一遍：

效果确实好一些了。

接下来，看看项目结构，非常惊人：仓库已经包含超过 230 个 workspace 成员，代码分布在 packages/、apps/、examples/、python/、native/、vendor/、website/ 等区域。文件系统、终端、子进程、PTY、语言服务器、网页访问、技能、子智能体、工作流、计划模式、会话持久化、设置、凭据、遥测，几乎每一项能力都有自己的包。

如果把普通的 Agent 项目比作一台已经装好的电脑，那么 DeepSeek Harness 更像一块尺寸惊人的洞洞板：模型、工具、界面、存储、安全策略和上下文管理都可以插上去，也都可以拔下来。

它提供了一套默认组装方案，但看得出来，DeepSeek 真正想创造的并非某个固定形态的「DeepSeek 编程助手」，而是一种组装智能体的方式。

DeepSeek Harness 是什么？

先厘清一个容易混淆的问题：DeepSeek Harness 并非新的 DeepSeek 模型，也非一个单纯的 API 客户端。它是一套用来构建、运行和扩展智能体的 SDK 与应用框架，默认可以连接 DeepSeek 模型（也可方便地自定义连接其它模型），让模型读取项目、修改文件、运行命令、管理任务、分配子任务，并通过 Web UI、全屏终端、Headless 命令或自动化协议与用户交互。

DeepSeek Harness 网页端提供了直接配置其它模型服务的便捷入口，无需用户手动编辑配置文件

当今的 AI 社区对 Harness 这个词已经不陌生了。其原本的含义是马具、线束、约束装置等，向上抽象一下，其作用是把力量连接到可以工作的机构上，同时又不让这股力量脱缰。具体到 AI 上，Harness 负责的是把模型接到文件系统、Shell、代码编辑器、网页和其他 Agent 上，同时记录它做了什么、限制它能做什么，并在出错时决定是重试、取消、压缩上下文，还是把问题交还给用户。

这或许也能解释为什么这个项目的代码量和包数量会如此庞大，毕竟这其中涉及的任务和工具选择非常多，包括工具调用是否可并行，取消命令能否真正停止子进程，工具结果是否会污染上下文，用户在模型运行中发来的新消息应该插到哪里，会话恢复后怎样重建当时的模型输入，子智能体拥有哪些工具，文件写入是否越过工作区，界面回放时看到的内容能否和实时运行一致。

DeepSeek Harness 试图把这些问题都变成正式的系统能力。

一切皆插件

DeepSeek Harness 最醒目的设计主张是「一切皆插件」，甚至连 Agent Loop 本身也被视为插件。

项目建立在 Cordis 微内核之上，运行中的 Harness 本质上是一个 Cordis Context。不同包向 Context 注册服务、事件和能力，最终由配置文件把它们组合成一套可以运行的智能体。

packages/core/ 是整个系统的核心，其中包含 Session、System Prompt、Tools、Agent 和 Agent Loop。它们解决的是最基本的问题：会话是什么，系统提示词如何组装，工具如何注册和调用，Agent 如何创建，以及一轮对话怎样从用户输入走到模型请求、工具执行和最终回答。

核心之外是大量能力包：

• packages/llm/ 负责模型适配器和流式输出；

• packages/shell/、packages/subprocess/ 与 packages/terminal/ 负责一次性命令、进程树和持续终端；

• packages/fs/ 负责文件读写、编辑、搜索与策略限制；

• packages/lsp/ 连接语言服务器，让 Agent 不只能用文本搜索，也能获得语义级代码导航；

• packages/web/ 负责搜索与网页抓取；

• packages/skill/ 管理可复用技能；

• packages/subagent/ 和 packages/workflow/ 则把单个 Agent 扩展为可以委派和编排的多智能体系统。

再往外看，计划、目标、待办事项、后台任务、上下文压缩、会话查询、会话标题、凭据、用户设置、审批机制和遥测同样被拆成独立能力。这个结构最有意思的地方，是它体现了一种近乎执拗的边界意识：谁拥有接口，谁负责实现，谁把能力呈现给模型，尽量不要混在一起。

项目文档把典型能力拆成三层：接口、实现和消费者。

以 Bash 为例，接口定义「执行命令」是什么，本地实现负责真正创建进程，而面向模型的工具包负责把这项能力变成模型可理解的 schema 和结果。将来如果本地 Shell 要换成远程容器、云端沙箱或企业执行平台，理论上只需替换实现层，而不必重写模型工具和 Agent Loop。

这是一种典型的框架思维。它会让仓库在早期显得庞大，却也说明 DeepSeek Harness 的目标不是做一个只有官方团队能维护的成品，而是让不同部署方能换模型、换存储、换安全策略、加工具，甚至换掉智能体循环。

在这里，我们也看到了 DeepSeek 一直坚持的真・开源！

cordis.yml

一份配置组装出不同的 Agent

插件化架构最终通过 cordis.yml 落到开发者手里。配置文件列出插件名称、稳定 ID 和参数，决定当前 Agent 究竟拥有哪一组能力。

同一套代码可以被组装成完全不同的产品形态。加入 DeepSeek LLM 适配器、文件系统、Bash 和 TUI，就得到终端里的编程智能体；把交互界面换成 Web 插件，就得到浏览器应用；使用 Headless 入口，它会接受一个任务，完成模型与工具轮次，打印答案后退出；换成 ACP 或 JSON-RPC 前门，它又能成为其他程序可以驱动的自动化服务。

配置还支持覆盖层。TUI 和 Web UI 可以共享一份基础配置，再叠加各自的界面插件和参数；个人配置则位于最后一层。这样，部署方不必复制整棵配置树，只需要对指定插件做替换。不过这里也有一个需要留意的细节：配置补丁替换的是目标插件的整个 config，不是深度合并。如果只写一个新字段，原有的 API Key、基础地址或其他参数可能会一起消失。它很明确，但并不一定符合初次使用者的直觉。

项目还允许在 YAML 中通过 !!js 读取环境变量和运行时表达式，例如从 DEEPSEEK_API_KEY 获取密钥。配置只引用凭据名称，密钥在实际调用时解析。Web UI 会把密钥写入 $DSH_HOME/.credentials.yaml，而环境变量和 .env 可作为自动化或本地开发中的回退来源；密钥不应直接写入 cordis.yml 或进入会话日志。

Agent Loop

不是一个循环，而是一套交通规则

许多早期 Agent 项目的核心代码可以简化成几行：把消息发给模型，如果模型返回工具调用，就执行工具，再把结果发回模型，直到模型输出文本。DeepSeek Harness 当然也做这件事，但它把这个过程拆成了严格的生命周期。

一次用户输入会开启一个 Turn，一个 Turn 中可以包含多个 Step；一个 Step 对应一次模型请求及其后续工具执行。请求前，系统会组装稳定的系统提示词、当前运行环境、工具 schema 和会话消息；请求后，模型的流式 chunk、完整消息、工具调用、工具结果和结束原因都会进入事件流。

上述丧尸射击游戏执行了 3 turn，127 setp

工具也不是「拿到函数名就调用」。它会经过前置策略、不可逆的安全守卫、实际执行、后置处理、内容整理和结果通知。允许或拒绝、超时、重试、指标统计、附加上下文，都可以从流水线的不同位置接入。工具可以声明某类参数下的调用是并发安全的，调度器便会让连续的只读任务并行；一旦碰到修改状态或无法确定安全性的调用，就把它当作屏障，等待前面的任务结束后独占执行。

这种设计看起来有些像在一条乡间小路上安装航空管制系统，但当 Agent 开始同时搜索十个文件、运行测试、接受用户追加指令，并且还要允许随时取消时，这些规则很快就会从「过度设计」变成「事故调查报告里最想早点拥有的东西」。

它还认真处理了运行中消息的去向。用户在 Agent 工作时发送的新内容，可能是下一轮任务，也可能是对当前工作的转向指令。系统区分排队消息、注入上下文和 Steering，并通过回执确认某条转向指令是否真正进入了某次模型请求。换句话说，它不只关心「消息收到了」，还关心「模型究竟在哪一步看到了它」。

Session Log

整个系统真正的权威来源

DeepSeek Harness 另一个值得关注的设计是 Session Log。

项目规定，凡是模型看见的内容，都必须能够从日志中重建。用户消息、运行环境上下文、模型请求信息、流式输出、工具调用和结果、压缩事件、权限切换、取消原因，都会以事件形式进入追加式会话流。界面、持久化、恢复、Fork、遥测和回放，不应该各自维护一份「差不多正确」的状态，而应从同一个事件源派生。

这项原则解决了 Agent 系统里一个非常棘手的问题：当一次任务出错时，我们究竟能不能知道模型当时看到了什么？

如果系统只保存最终聊天文本，许多关键因素会丢失。也许模型请求前刚刚注入了工作区状态，也许工具结果被裁剪过，也许系统自动切换了模型路由，也许用户在流式输出中途改变了方向。DeepSeek Harness 会在请求边界保存足以重建消息的记录，原始流式 chunk 也会保留，以便界面和回放维持一致。

会话持久化本身仍然是插件。项目提供 JSONL 和 SQLite 等后端，查询能力可以优先访问实时会话，也可以通过 SQLite 全文检索历史记录。Resume 会沿用原会话继续工作，Fork 则从一个确定的历史边界派生新会话。对开发者而言，这能为调试、评估、审计和自动化提供了统一基础。

从一个 Agent 到一群 Agent

DeepSeek Harness 已经内置了多种子智能体和工作流能力。

主 Agent 可以把任务委派给子 Agent，子 Agent 可以是全新创建的实例，也可以从已有会话的完成边界 Fork，或者通过 ACP 连接外部子进程。

上述丧尸射击游戏创建了 5 个并行执行的子智能体

这里的作用域设计很重要。每个 Agent 拥有自己的上下文层，可以看到特定的工具、提示词和命令。某个子 Agent 可以被限制为只做搜索和分析，另一个则被允许修改文件。注册在 Agent 作用域里的能力会随 Agent 生命周期自动清理，不必依赖全局名称约定维持隔离。

工作流则更进一步：它允许用脚本驱动多智能体编排，把多个子任务、结构化输出和继续执行连接起来。项目同时提供目标、计划、待办事项和后台任务，它们并不是四个名称相近的 UI 小组件，其实是不同生命周期的协作状态。计划模式记录当前协作阶段，目标可以跨同一会话持续存在，待办事项为模型提供轻量任务清单，后台任务则负责管理仍在运行的实际工作。

这说明 Harness 想覆盖的不只是「一问一答式编程」。它希望支持长任务、并行调查、自动化运行和外部系统协调。至于模型能否稳定驾驭如此多的机制，是另一场测试；至少框架先把方向盘、仪表盘和刹车做了出来。

Web、TUI、Headless 与 SDK

面向普通用户，项目推荐 Web UI，默认监听 http://127.0.0.1:3080。它提供对话、会话侧栏、权限选择、计划模式、工具卡片和工作区交互。

Web UI 还提供了四种 Agent 预设模式。它们并非四套彼此独立的 Agent，也不只是改变提示词风格，而是基于同一套 Harness 宿主，为当前会话装配不同的工具、提示词和运行时能力：

• 标准模式：功能最完整的通用编码 Agent，提供文件编辑、Shell、文件与网页检索、Skills、计划、目标、子 Agent 和工作流，适合绝大多数日常开发任务；

• PTC 模式：保留标准模式的全部能力，同时通过 Code Mode SDK 向模型呈现工具。模型可以编写一段 TypeScript 程序，在一次 run_code 中组合多步操作，减少模型与工具之间反复往返的开销，更适合调用链较长的复杂任务；

• 极简模式：只提供持久 Bash 与 str_replace_editor 两项工具。较小的工具集合减少了选择和上下文负担，适合路径明确、希望 Agent 直接动手的编码任务；

• 创造模式：在标准模式之上加入 Cordis 运行时检查、临时插件实验和 Agent preset 创作指导。Agent 不仅可以使用现有工具，还能探索并重新组合自己的运行时，进而创建新的自定义预设。由于它能够运行模型编写的插件代码，这是一个面向高级用户的高信任模式。

这组预设或许是「一切皆插件」最直观的产品化表达：底层的模型路由、会话持久化、沙箱和审批仍由共享宿主提供，预设只决定一个 Agent Context 中具体装入哪些能力。同一个 Web UI，因此可以从双工具的极简 Agent，切换成能够编排子 Agent 的标准模式，甚至进一步变成可以改装自身的创造模式。

举个例子，这里我们在创造模式下，让接入了 DeepSeek V4 Pro 的 DeepSeek Harness 创建了一个官方 Web UI 没有的「三栏模式」：

Web UI 之外，TUI 则面向喜欢留在终端中的开发者。

Headless 模式适合脚本和 CI：它接受一个任务，等待 Agent 完全停稳，输出最后一条有效回复后退出。如果程序需要结构化事件和持续控制，则应使用 ACP 或 JSON-RPC/Python SDK。

自动化方面，项目提供 ACP 服务和 JSON-RPC 入口。Python SDK 驱动随附的 JSON-RPC 运行时，让 Python 应用可以启动会话、发送任务、接收通知，而不必直接嵌入 Node 内核。仓库还包含 Code Mode、自指 Cordis、MCP 记忆服务等示例。

值得注意的是，这些入口并不是四套各自演化的 Agent。它们共享核心能力模型、会话事件语义和大部分基础插件，但并非简单替换一层 UI，而是通过不同 bundle 组装出 Web、一次性任务和自动化服务等产品形态。这正是「一切皆插件」最直观的成果。

Agent 可以检查甚至改装自己

DeepSeek Harness 还提供了一组自指 Cordis 工具。它们不会进入标准、PTC 或极简模式，而是通过 Web UI 中的「创造模式」作为明确的高级入口提供。选择这一预设后，Agent 可以检查当前运行时的插件树，并动态挂载或卸载临时插件。

这听上去有点像让汽车在高速公路上给自己换发动机，因而项目没有默认打开它。它适合研究或高级自动化场景：模型可以临时编写事件监听器、注册新工具、提供一个服务，再在任务完成后卸载。

自修改式 Agent 很容易沦为概念演示，但 Harness 至少把它放进了已有插件生命周期中。动态插件仍然运行在 Cordis 的 Context 和 Effect 机制下，注册项有明确的清理路径。

它还远谈不上安全无忧，却展示了这套架构真正想抵达的地方：智能体不只使用能力，也能在受控边界内重新组合自己的运行时。

Cordis 背后的设计，可以参考官方同步发布的论文《A Programming Paradigm for Spatiotemporal Composability》：

论文地址：https://github.com/cordiverse/paper

安全策略

编程智能体一旦获得文件系统和 Shell 权限，就可以修改代码、安装依赖、启动进程，甚至触碰工作区之外的主机环境。DeepSeek Harness 显然把这件事当作基础架构问题，而不是在界面上增加一个确认弹窗便草草收工。

项目默认采用 workspace-write 模式，将命令执行和文件修改限制在当前工作区及允许的临时目录中，并配合 ask 审批策略处理需要扩大权限的操作。更宽松的 danger-full-access 模式也存在，但必须由部署方明确选择；它不会被包装成一个看似无害的兼容选项。

工具调用还要经过前置策略、单调安全守卫、执行包装和后置处理。被守卫拒绝的操作不能被后续插件重新放行；需要扩大权限的命令必须说明原因，并通过审批机制重试。文件系统、Bash 和子进程共享同一套沙箱策略，避免出现「命令受限制，但文件工具可以绕过去」的割裂边界。

更值得肯定的是，DeepSeek Harness 采用「失败关闭」原则。如果系统无法确认隔离机制真正生效，它会拒绝执行，而不是悄悄退化为无保护运行。权限切换、审批请求、工具参数、执行结果和取消原因也会进入 Session Log，为事后审计和问题复现保留依据。

这套设计并不能消除智能体执行本地操作的全部风险，但它体现了一种难得的工程态度：安全是贯穿配置、执行、审批、日志与恢复机制的系统约束。模型可以提出行动，真正决定行动能否发生的，仍然是 Harness。

DeepSeek 想做的不止是「又一个 Codex」

如果只看 Web UI 或 TUI，很容易把 DeepSeek Harness 理解为 DeepSeek 版本的 Codex、Claude Code 或其他编程助手。但从仓库结构看，它的目标明显更底层。

默认应用当然重要，它让开发者可以直接获得一个能读写项目、运行命令、规划任务和调用子 Agent 的工具。但真正占据项目中心的，是可替换的能力接口、事件驱动的生命周期、权威会话日志和声明式组合。换言之，成品 Agent 更像这套 SDK 的第一位客户。

这也给 DeepSeek 的模型生态补上了一块过去不够显眼的拼图。模型决定智能上限，Harness 决定这些智能如何进入真实环境，如何使用工具，如何保留状态，又如何在权限边界内工作。对于企业开发者而言，后者往往比聊天窗口多几个按钮更重要，因为它决定了系统能否被审计、扩展、替换和长期维护。

DeepSeek Harness 现在还远没有到「安装完成，一切丝滑」的阶段，但它已经展示出一套相当完整的技术判断：Agent 不应该是一段越来越臃肿的循环，而应该是一组可以组合、观察和替换的能力；会话不应该只是聊天记录，而应该是运行事实；工具不应该只是函数，而应该同时拥有策略、日志和呈现协议。

因此，DeepSeek Harness 最值得关注的，并非它今天能否替代你正在使用的编程助手，而是它把 DeepSeek 对 Agent 工程的答案公开到了什么程度。

© THE END

转载请联系本公众号获得授权

投稿或寻求报道：[email protected]

人工智能浪潮席卷全球，研究、工程和产品都在快速迭代，一项创新研究，极有可能成为推动 AI 下一次技术进步的力量；一个创业 idea，也极有可能成为点燃 AI 产业变革的火种。

但从论文、代码，走到产品、场景与公司，技术创业者要跨越的，从来不只是技术本身。从实验室到真实世界，需要完成关键验证，需要找到最早的用户与场景，也需要在正确的时间遇见同行者、产业资源与长期资本。

为此，机器之心联合多个合作伙伴发起「点燃 AI 火种·助力科研到创业」长期计划——旨在寻找最前沿的 AI 研究成果与渴望将研究变成应用的梦想家，并提供多维度支持。

• 正在从事创新性 AI 技术研究

• 有独特的算法、模型或产品方向

• 渴望将科研成果转化为产业影响力

• 有创业的想法，即便还不成熟

200 万元概念验证基金，支持技术跨出关键一步。这笔钱将支持入选项目开展技术可行性、产品原型或场景适配等关键验证，科学价值需要被发现，也需要通过清晰的验证路径走向真实世界。

顶级早期投资机构种子轮风险投资，助力项目走向公司。当原型跑通、方向更清晰，头部早期资本、战略投资将为具备条件的项目提供进一步的种子轮投资机会与专业支持，帮助项目从技术探索迈向公司化发展的下一阶段。

全流程服务，补齐科研转化的第一公里。我们将围绕项目定位、BP 打磨、资本对接、产业资源链接等关键环节，提供持续服务。这不是一场结束即散的活动，而是一段围绕技术转化展开的长期陪伴。

概念验证闭门评审：让技术接受多维检验

每期计划将精选 5 个项目，开展线下闭门诊断与打磨。技术评委看技术壁垒与验证路径，产业评委看问题与场景，投资人评委看产品化与商业化可能。

我们希望用一次高密度、跨视角的讨论，与项目共同探讨一个更具体的问题：这项技术，下一步如何走向真实应用？

项目路演 Tech Show：把产品亮出来

我们不只看 PPT，更希望看见技术在真实场景中的可能性。项目可通过产品演示、场景再现、实物模拟、软硬件交互等形式，直接呈现技术与产品。同时，每位创始人还将讲述自己的成长经历与商业思考。

路演之外，我们还将组织闭门 AI Founder 交流，让技术、资本与产业的对话从台上延续到更深入的连接中。

火种已被点燃

计划启动以来，已有多个AI早期项目获得概念验证资金支持，多个项目获得顶尖早期投资机构种子轮投资，方向覆盖大模型、具身智能、AI for Science等前沿领域。

而这些项目，曾经也只是论文里的一个想法。下一个从论文里走出来、到产业中去的，也许就是你，欢迎加入我们。

扫描下方二维码填写表格，全年滚动征集

合作联系： 阮老师 [email protected]