多智能体不是简单把任务分给几个 Agent 就行，怎么让它们协作而不是互相强化错误，是个更难的问题。Google 最近开源的 Teamwork 框架给了个答案，它在数学、硬件仿真、开源优化这些前沿领域都有实测成果，我看了它的设计思路，觉得对做 Agent 的人挺有启发。

这篇文章主要拆解它的设计原理，看看它到底怎么解决多智能体协作的问题。

原文链接：https://antigravity.google/blog/teamwork-when-ai-becomes-a-research-partner

一、问多 Agent 难的不在分工，而在组织

常规任务用基础多智能体方法通常够用，但碰到困难的研究和工程问题，麻烦就来了。松散组织的 Agent 很快会偏离轨道，一个 Agent 早期犯的错，其他 Agent 会跟着认同，然后在有缺陷的想法上继续构建。

核心矛盾不是"用几个 Agent"，而是"怎么组织它们"。Anthropic 之前做过一个实验，对比了协调 swarm 和独立并行 agents 在找软件漏洞上的效果。结果显示，协调 swarm 能找到更多漏洞，而且这种差距在复杂任务上更明显。

这说明松散组织的 Agent 会偏离轨道，是多 Agent 系统的通病。Teamwork 解决的问题是：让多个 Agent 在数小时甚至数天里，互相挑战对方的工作，在进一步构建前先找缺陷，把最强的部分组合成可用的解决方案。

二、Teamwork 如何让 Agent 互相纠错？

Teamwork 把很多研究和工程问题通用的结构变得具体且可配置：生成候选方案、压力测试、把最佳想法组合成更强的方案。围绕这个循环，它做了三个关键设计。

从生成方案到测试、组合，再进入下一轮

这个循环是 Teamwork 的基础。不是简单的任务分发，而是让候选方案经过测试后，把好的想法提取出来，形成更强的下一轮候选。人类负责定目标和做最终验收，Agent 负责执行整个迭代过程。

把协作模式和 Agent 本身分开

模式是规格，不是可执行程序。它不包含编排代码，框架读取模式后自动启动合适的 Agent。这样专门的机制（比如对抗性批评循环）可以跨领域移植，不用改代码。

这个设计的价值在于：协作逻辑和每个 Agent 具体干什么分开了，你写好的编排策略可以复用到完全不同的领域。

团队规模不预设，边做边调整

框架根据任务需求动态决定生成多少 Agent，不是预设数字。Agent 数量和团队结构可以在运行过程中随着问题的展现而改变。每次任务执行是一个活的过程，不是固定管道。

这个设计解决了一个常见问题：很多框架要求你事先想好要用几个 Agent，但复杂问题的结构往往在做的过程中才清晰。

三、五种问题，需要五种不同的协作方式

不同问题需要不同的协作方式。问题的结构决定了该怎么组织 Agent，Teamwork 针对不同类别的问题提供了专门模式。

不可拆的任务，在测试中反复迭代

有些问题没法拆成独立子任务，需要反复试错和精炼。这个模式通过紧密的 Agent-测试-精炼循环逐步改进，每个测试结果直接反馈给下一轮修改。

能拆开的任务，交给多个 Agent 并行推进

对于能拆成多个独立部分的工程任务，这个模式把工作扇出到多个并行工作者，同时安排批评者审查每个工作者的产出。

编排器根据问题决定部署多少 Agent、跑多少轮，核心角色固定，但执行规模动态调整。

数学开放问题，让不同路线先接受挑战

数学和理论计算机科学的开放问题有个特点：很多有希望的方法最终会失败，而且缺陷往往要到深入尝试后才可见。这个模式让每个候选方案在推进前必须经过压力测试。

每走一步，都先验证这一步是否成立

深度优先的数学推理需要在每一步都严格自检，这个模式把验证嵌入到推理过程中，而不是等完整答案出来后再检查。

审查论文，用固定维度组织批评意见

对论文和技术文档的审查需要结构化的分析，这个模式用固定的审查维度来组织 Agent 的批评意见。

四、失败的证明路线，也能留下有用的东西

长证明模式值得单独拆解，因为它处理的是最难的开放问题。它的设计不只是"生成然后验证"，而是一个完整的"生成、对抗、综合、学习"循环。

给每个候选方案安排一个专门的反驳者

多个候选策略并行生成，每个策略配一个伪造者，伪造者的唯一工作是打破这个策略。综合树把候选策略和它们的报告组合起来。

被驳倒的路线留在过程中，附带反对意见。一个破碎的路线可能仍包含有用的想法，这是这个设计的关键洞察。

把长证明拆成带依赖关系的子问题

选定的策略扩展成证明计划，子问题有明确的目标和显式的依赖关系。依赖图让独立子问题并行运行，依赖子问题按拓扑顺序执行。

这样长证明被拆成可管理的部分，同时保持整体逻辑的连贯。

让不同方案在锦标赛中逐层合成

在综合树中，每个节点读取候选样本及其批评，产生改进的解决方案。如果综合解决方案失败，网络会用累积的反对意见重新运行。

这个机制让失败变成有用的信息，而不是简单丢弃。

这一轮踩过的坑，下一轮不再重来

失败的草稿保留给下一次尝试。验证者的发现提炼成答案无关的陷阱注册表，记录常见错误模式。共享知识目录保存已证明的结果、失败的方法、相关参考。

这些经验积累让后续尝试不会重复踩坑。

五、对做 Agent 的人的启发

Teamwork 的设计原理有几点值得借鉴。

多智能体的核心是编排逻辑

不是简单分任务，而是要设计好压力测试机制、结果综合策略、跨轮学习机制。松散组织的 Agent 会互相强化错误，这点在官方文档里也反复强调。

一套协作模式，可以迁移到不同领域

编排逻辑和 Agent 描述解耦后，你写的协作策略可以移植到不同领域。这个设计思路不只适用于 Teamwork，做自己的多智能体系统时也值得考虑。

不要提前锁死 Agent 数量

不要预设固定的团队结构，让 Agent 数量和组织方式根据问题的展现动态调整。复杂问题的结构往往在做之前无法完全预见。

必须有人专门提出反对意见

Anthropic 的研究还发现了一个值得注意的问题：当多个 Agent 面对相同情况时，会表现出比人类更高的相似性。一个 Agent 的错误决策会被其他 Agent 复制，形成系统性失败。

Teamwork 的设计（如伪造者机制、批评循环）正是为了对抗这种从众效应，让每个候选方案在推进前都要经过独立的压力测试。

小模型配上好编排，也能解决高难度问题

用日常开发用的 Flash 级模型配上精心设计的编排逻辑，能在复杂问题上解锁强劲性能。TCSBench 71% 的得分里，有三个结果是 Flash-tier 模型首次产生博士级别的数学研究。

不一定非要用最大的模型，关键是编排逻辑的质量。

写在最后

看完 Teamwork 的设计原理，我的感受是：多智能体的未来不在于堆更大的模型，而在于怎么设计好协作机制。它把生成、测试、组合、学习这个循环做得足够细，让小模型也能在前沿问题上发挥作用。

对正在做 Agent 系统的人来说，最值得参考的是它的三个设计决策：编排逻辑和 Agent 描述解耦、运行时自适应、把失败当成有用信息。这些思路不只适用于多智能体，单 Agent 系统里也能用。

Anthropic 的多 Agent 研究则提醒我们，多 Agent 协作还有隐性问题，比如从众效应。设计编排机制时，需要特别考虑如何避免 Agent 之间互相强化错误。

如果要深入学它的机制，建议重点看长证明模式的锦标赛网络设计。这个模式处理的是最难的开放问题，它的策略搜索、分解、跨轮学习机制，对理解怎么让多个 Agent 真正协作有很大帮助。

一起“点赞”三连↓

跳转微信打开

https://claude.com/blog/claude-code-guide-for-startups

一起“点赞”三连↓

跳转微信打开

9 月 6 日，2026 长三角 AI 场景创新论坛——FDE（前沿部署工程师）人才专精培育计划 将在上海交通大学徐汇校区举行。当天，10×100首批场景清单、FDE 100 案例和首批 FDE 100人名单将同时发布。

FDE（前沿部署工程师）：是深入企业一线，使用真实业务数据完成场景判断、方案设计和落地验证的人。

今天，首批 FDE 100人正式开放报名。

2026 长三角 FDE 联合行动：杭州、上海、南京

Datawhale 发起的 2026 长三角 FDE 联合行动先后走进杭州、上海和南京。

8 月 24 日，杭州云谷中心。原定 20 人的FDE企业AI落地班收到了数百份报名。最终到场的 20 家企业中，13 家营收过亿，近七成由创始人、董事长、CEO 或总经理亲自带队。

8 月 26 日，上海站在上海市虹口区科技和经济委员会指导下举行，上海交通大学安泰经济管理学院、上海虹口隐形冠军企业促进中心、商汤科技等联合支持。

8 月 28 日，南京站在建邺区首次举办，河西中央科创区与南京阿里中心联合支持。

首个 FDE 100人计划，不看资历只看案例

我们将筛选首批 FDE 100 人，从真实企业问题出发，用真实案例识别真正的 FDE。

不看资历，只看案例。 我们判断一个案例是否成立，看四点：解决过谁的什么问题（企业主体和痛点都具体）、结果可核验（效率、成本、质量、决策任一维度有变化）、方法可复用（讲得清为什么这么做）、真实的交付角色（主导或深度参与，不是转述）。对于入选者，会拿到三样东西：

1. 一份可信的案例。 进入 FDE 100 案例库，9 月 6 日线下发布，让更多企业主动联系合作。

2. 一批真实的场景。 10×100 首批场景清单同场发布，让FDE能力规模化复制。

3. 一群靠谱的搭档。 能把 AI 真正跑进业务现场的搭档其实并不多。FDE 100人是可以一起接单、一起补位、一起判断的人。

9 月 6 日，在上海交通大学发布

上海交通大学安泰经济与管理学院与 Datawhale 将现场签署战略合作。同一场发布仪式上，10×100 首批场景清单、FDE 100 人、FDE 100 案例一并公布。下午是 FDE 场景项目路演与企业合作对接交流。

这背后是杭州西湖区、上海虹口区、南京建邺区的率先支持；上海交通大学安泰经管学院、杭州电子科技大学等联合校友资源；河西中央科创区、云谷中心、南京阿里中心、上海虹口隐形冠军企业促进中心带来真实企业与场景；潮新闻等媒体让人和案例进入公共视野。

扫码联系负责人

本次征集面向已经在做 FDE、手里有真实企业案例的人。如果暂时不确定自己的案例是否合适，我们会和你一起判断。

报名截止时间：9月30日。首批名单将于 9 月 6 日在上海交通大学徐汇校区发布。

报名和入选均不收取费用。

发起方：Datawhale，联合支持方：上海交通大学安泰经管学院、杭州电子科技大学、浙江省人工智能学院、河西中央科创区、云谷中心、南京阿里中心、上海虹口隐形冠军企业促进中心、潮新闻等。

⬇️ 阅读原文申报FDE100人

阅读原文

跳转微信打开

Warp 公开了自己搭自我改进 Agent 的实战方法：两个 Skill 文件，中间夹一条人类反馈，就能让 Agent 从每次错误里沉淀知识、越用越聪明。这家把 AI 终端做到 80 万月活、近 7500 万融资的公司，自己的开发团队就靠这套框架，把一个噪声缠身的 code review Agent 救了回来。

https://claude.com/blog/how-warp-builds-self-improving-agents-on-claude

这个 Agent 负责 code review，第一轮能做到 80% 正确。听起来不错，但剩下 20% 是噪声：不相关的评论、误判代码库惯例、低质量的修改建议。Warp 的工程师每天要在一堆无用评论里挑有用的，比没有 Agent 还累。

团队试过手动改 prompt、改进 AGENTS.md，都不解决问题。Warp CEO Zach Lloyd 最近在 Claude 官方博客上分享了他们最终的解法：两个 Skill 文件，搭出一个会自我改进的 Agent。

这套框架不复杂，但戳中了一个大多数团队都会遇到的问题：Agent 越用越笨，根子不在模型不够强，而在反馈在每次对话结束时消失了。

一、问题根源：80% 正确的 Agent，比完全错误更折磨人

先讲清楚 Warp 踩的坑。

他们的 code review agent 有一个典型毛病：第一轮输出能做到 80% 正确，但剩下 20% 的噪声会让工程师崩溃。比如它建议重命名一个变量，但没注意到这个代码库的惯例是这类全局变量有固定命名方式。这种评论不仅没用，还会浪费审查者的时间去判断"这条该不该理"。

团队的第一反应很直觉：手动改 prompt。看到哪类评论翻车，就去改对应的 prompt 片段。这确实有效，但每个新问题都要人盯，根本规模化不了。

后来又试了改进 AGENTS.md，把更多上下文写进去。有帮助，但远不是完整方案。

两个方案都触及了问题的表面，没碰到根。Warp 后来意识到：给 Agent 的反馈，通常在对话结束时消失。无论你在对话里纠正了它多少次，下一轮新对话开始，Agent 还是那个"没记住教训"的 Agent。

这就是 Agent 越用越笨的真正原因。不是模型能力问题，是反馈没有沉淀。

二、两个 Skill 加一次反馈，搭出自我改进的闭环

Warp 的解法是用 Agent Skills 搭一个自我改进循环。Skill 是基于文件的知识编码，把指令留在 prompt 之外，Agent 干活时可以查阅。

整个框架只有两个 Skill，中间夹着人类反馈：

内层 Skill（base skill）：存放功能领域的知识和指令。比如一个 PR 被打开时，Warp 的 code agent 就是用这个 base skill 加上上下文来做审查。

人类反馈：这是循环里最关键的一环。反馈可以简单到一个点赞，但越明确越好。Zach Lloyd 举了个例子：不只是说"这条评论不好"，而是说"你建议重命名这个变量，但我们代码库的惯例是这种全局变量用特定的命名上下文"。这种带理由的反馈，Agent 才能真正学会下次怎么做对。

外层 Skill（improver skill）：一个观察者 Agent，按计划运行，不是每个任务都跑。它的工作是把积累下来的人类反馈拉出来，对比"Agent 原本建议了什么"和"人类实际怎么回应"，然后提议一个最小、最聚焦的对 base skill 的编辑。

为什么这套机制能跑通？因为 Skill 是纯文件。Agent 很擅长改文件，而这些改动可以走正常的 PR / code-review 流程：人 review、approve、merge，下一轮 base skill 就自动继承了改进。

Warp 特别强调了一点：这里用的是 Skill，不是 Memory。两者的区别很关键。Skill 是程序性的、稳定的做某件事情的规范，跟单次运行无关，改动是刻意的；Memory 是 Agent 推理时自动写下来的，从不停在变。把"怎么做好 code review"这种稳定知识放进 Skill，才能被版本化、被审查、被复用。

现在这套模式跑在 Warp 整个开源仓库上，spec-writing、review、triage 三类 Agent 各自带着自己的自我改进循环。

三、实战案例：一个漏标的标签，怎么变成永久知识

光说框架有点抽象，看 Warp 的 issue triage agent（问题分诊 Agent）怎么跑通这个闭环。

触发条件很简单：有人在 GitHub 提了一个新 issue，GitHub Action 就触发一个 Agent，分析问题的复杂度和可行性，打上标签，再建议修复方向。这个 triage agent 跑在内层 Skill 上，里面写着每个标签是什么意思、动手前要怎么研究代码库。

有一次，第一轮分诊干得不错，但漏了一个标签："ready to spec"（可以开始写规格说明了）。这个标签很关键，它告诉贡献者"这个问题已经想清楚了，可以直接开始写产品和技术 spec"。

一位 Warp 的维护者在 issue 上留了反馈，而且说清楚了期望什么、为什么期望。这就是前面说的"高质量反馈"：不只是说"你漏了"，而是解释了"这个标签在这个场景下该打"。

接下来是外层 improver skill 登场。它在 Warp 的 Agent 编排平台 Oz 上按计划运行：认证 GitHub，跑一段打包好的 Python 脚本拉取最近带反馈的 issue，汇总成 JSON 读回上下文。注意这个细节，skill 里可以引用资源文件和脚本，不用每次重新写代码。

Agent 从反馈里识别出具体信号，提议一个最小编辑，然后开了一个 PR 来修改内层 Skill：当 issue 描述了一个真实问题、即使具体的 UI/UX 形态还没定义时，也打上 "ready to spec" 标签。

因为是 skill 文件，这个改动走正常的 code-review 流程。PR 带着描述说明"哪些信号促成了这次改动、改了什么"，人 review、approve、merge。下一轮 triage agent 跑起来时，就自动继承了这条新知识。

从"漏标一个标签"到"永久记住这个教训"，中间没有人工重写 prompt，只有一次反馈、一次 PR。这就是自我改进闭环跑通的样子。

四、工程经验：写好自我改进 Skill 的六条纪律

Warp 把搭自我改进 Agent 的经验提炼成六条纪律。这些理论，是从几千次 code review 里探索出来的。

1. 写原则，不写规则。把 Skill 当成在教一个聪明人，不是在给计算机编程。"找重复代码"这种方向性指引，比穷举所有变量命名规则有效得多。

2. 解释 why。每条规则背后给一句理由，让 Agent 能推理，而不是死记硬背。这样它遇到没见过的场景也能泛化。

3. 让反馈零摩擦。在人已经工作的地方捕获反馈，比如直接在 PR 或 issue 上评论，而且自动发生，不额外增加提交步骤。"反馈太难给，信号就断了。"

4. Skill 保持小，渐进式披露。好的 skill 文件不大，它引用资源文件和脚本，而不是把所有东西一次性倒进上下文。

5. 质量大于数量，但数量也有用。一位高级工程师给的几条详细领域反馈，可能比一百个点赞更有价值，因为单键点赞说不出理由。但质量信号的语料越大，系统改进越稳。Warp 用这套循环管理整个开源仓库，几百人贡献、几千次 review。

6. 重投入 improver skill。improver skill 很值得额外花精力，因为它高度可复用。code review agent 的 improver 和别的 Agent 的 improver，差别没你想的那么大。

写在最后：自我改进也可能让 Agent 系统性地学错

需要说清楚一件事：这篇内容来自 Claude 官方博客的一个客户案例系列，是 Anthropic 策划的，主角是 Warp。技术细节大概率是真的（Zach Lloyd 亲述）。

不过 Warp 在文末的常见问题里主动划了几条边界，反而比成功故事更有价值：

反馈会错。 他们明确说"假设反馈会出错"，不让 Agent 盲目接受。要给 Agent 上下文让它能 sanity-check，要过滤谁的反馈算数，在过滤或最终 review 阶段保持人类在环。

领域必须可验证。 如果领域可验证，先建验证 harness，再让 Agent 对着它调：生成参考语料、对比输出、修改、重复。如果不可验证，有 golden output 的地方用确定性评测；必须靠人类反馈时，只开放给领域专家，别开闸放水。

不是每个 Agent 都要独立 improver。他们的建议是折中：模板化的 base loop 捕获重叠部分，再叠加领域特定权重。少数 improver 各管一个，上百个 Agent 就该共享。

这几条边界说明一件事：自我改进不是搭个循环就一劳永逸。反馈质量、领域可验证性、人类在环的位置，任何一个没守住，闭环就会退化成"Agent 在有系统地学错东西"。

一起“点赞”三连↓

跳转微信打开

一个 Agent 到底凭什么越来越强？有人靠更大的模型，有人靠更多数据。就在前天，Google Research 最新发布的 WikiSkill 给出了另一条答案：给 Agent 搭一套三层知识架构，让技能自己进化。

论文链接：https://arxiv.org/abs/2608.27454

这套架构的核心是把"经验"和"知识"分开。以前的技能进化方法（EvoSkill、Trace2Skill、SkillOpt）分析完执行轨迹就直接改 Skill，经验用一次就丢。WikiSkill 在中间加了一层持久知识库，让经验先沉淀、再复用。

一、三层架构：把经验、知识和技能分开

第一层 Raw Layer：保留原始轨迹，给进化留下事实依据

Raw Layer 存储每次迭代的执行轨迹，包括 Agent 的完整推理过程、工具调用、输出结果。这一层不可变，目的是保留"到底发生了什么"的原始记录。

为什么单独存一层？因为后续两层都需要回溯原始轨迹来分析问题。Wiki Maintainer 要从中提取成功和失败模式，Skill Proposer 要按需查阅具体任务是怎么执行的。如果原始数据被覆盖或丢失，整个进化过程就失去了事实基础。

第二层 Wiki Layer：让一次性经验变成可复用知识

Wiki Layer 是整个架构的核心。它把原始轨迹编译成结构化知识，跨迭代持续积累。包含三个部分：

• patterns/：每个模式一个 markdown 文件，记录具体的失败原因或成功策略，带可操作的修复方案

• logs.md：进化日志，按迭代记录发现了什么、改了什么

• skill-impact.md：哪些 Skill 改动被接受、哪些被拒绝，带完整 diff

这一层有两个关键设计。

第一，Wiki 永不回滚。Skill 被拒绝时，Skills Layer 回到上一版本，但 Wiki 保留所有积累的知识。下一轮 Proposer 能看到"上次这个改法为什么被拒"，避免重复踩坑。

第二，Knowledge 和 Skill 分离。知识回答"我们知道什么"，技能回答"我们该怎么做"。以前的方法把两者混在一起，改技能时丢失了背后的推理上下文。WikiSkill 让知识持续积累，技能从知识里生长。

第三层 Skills Layer：可执行技能，带溯源

Skills Layer 是当前生效的技能集合。每个技能目录有两个文件：

• SKILL.md：技能内容，Agent 执行任务时直接读取

• PURPOSE.md：记录这个技能是为了解决 Wiki 里的哪个 Pattern 而创建的

PURPOSE.md 解决的是"这个技能为什么存在"的问题。当技能需要修改时，Proposer 可以通过 PURPOSE.md 回溯到对应的知识模式，理解当初的设计意图，而不是盲目地打补丁。

二、进化循环：从执行轨迹到 Skill 更新

每轮迭代跑四步：

1. Inference Agent：用当前 Skill 在训练集上跑 rollout，产出轨迹到 Raw Layer。训练时不能访问 Wiki，否则 Agent 会直接查答案，导致轨迹失去参考价值。

2. Wiki Maintainer：分析采样后的成功和失败轨迹，做根因分析，更新 Wiki 的 Pattern 目录和日志。

3. Skill Proposer：以 ReAct 方式读 Wiki 索引、查 skill-impact 历史、按需读具体 Pattern 页面和轨迹，然后提出一次 Skill 创建或补丁。

4. Gating：在验证集上评估候选 Skill，分数提升就接受，否则回滚。Wiki 不受影响。

这个循环的关键是第二步和第三步的配合。Wiki Maintainer 把零散轨迹编译成结构化知识，Skill Proposer 从结构化知识里生成技能更新。没有 Wiki 层，Proposer 每次都在从零开始分析原始轨迹。

三、实验结果：9B 加 Skill，超过 27B 裸模型

在五个基准、五个模型上的实验结果：

技能进化与模型规模互补。 Qwen 家族内，WikiSkill 带来的提升随模型规模递增：4B +12.3 分，9B +17.5 分，27B +23.9 分。越强的模型从技能进化中获益越多。

技能可以弥补规模差距。 Qwen-3.5-9B + WikiSkill 平均 47.4%，超过 Qwen-3.6-27B 无技能时的 39.4%。9B 加 Skill 超越 27B 裸模型。

技能跨模型家族迁移。 Qwen-3.5-9B 用 Qwen-3.6-27B 进化的技能达到 70.2%，用它自己的技能只有 63.4%。这说明"发现策略"和"执行策略"是两种能力，可以跨模型分工。

消融实验确认 Wiki 的价值。 去掉 Wiki 访问后，平均分从 63.7% 降至 48.7%，回落约 15 个百分点。Wiki Maintainer 积累的跨迭代知识是 Skill Proposer 能解决复杂失败模式的前提。

写在最后：Agent 持续变强，靠的不只是更大的模型

WikiSkill 的贡献不是一个新算法，是一个架构设计：把经验、知识、技能分成三层，让知识在中间持续积累，技能从知识里生长出来。

对做 Agent 的人来说，这意味着别再只盯着模型规模和 prompt 调优。搭一套三层知识架构，让经验沉淀为知识，让知识指导进化，才是 Agent 能持续变强的底层逻辑。

一起“点赞”三连↓

跳转微信打开

当多个 AI Agent 组队完成一个复杂任务时，会发生什么？

https://www.anthropic.com/research/multiagent-systems

Anthropic 最近发布了一项研究，系统性地测试了多 Agent 系统在真实场景中的协作能力。

结果并不乐观：当 Agent 数量增加、任务复杂度上升时，系统性的失效模式开始浮现。这些失效源于多个 Agent 相互作用时产生的全局性风险，不只在单个 Agent 身上！

一、实验设计：把 Agent 放进真实协作现场

研究团队设计了三个核心实验场景：

第一个是软件漏洞检测。他们启动了 45 个 Agent，每个 Agent 都有自己的虚拟机，可以在共享论坛上协调。任务是在 15 个开源软件项目中找出安全漏洞。

第二个是协作开发实验。研究团队要求多个 Agent 共同开发一个文字冒险游戏，每个 Agent 拥有独立的开发环境，但共享一个代码仓库和论坛。实验持续 12 小时。

第三个是代码迁移实验。研究团队要求三个 Agent 将同一段 Python 代码迁移到不同的编程语言，每个 Agent 不知道其他 Agent 的存在。

在这三个实验中，研究团队观察到了三类系统性的失效模式。

失效一：协作越深入，协调成本越高

在漏洞检测实验中，Mythos Preview 模型上的 45 个协作 Agent 找到了 266 个漏洞，而独立并行的 Agent 只找到了 21 个。

看起来协作效果很好，但细看数据会发现两个问题。

第一个问题是成本。协作组消耗了 2700 万 token，独立组只用了 650 万。token 是大模型处理文本的基本单位，可粗略理解为字符片段。成本涨到 4 倍多。而且这 266 个漏洞中，有一半是在核心代码目录之外找到的，如果只看核心目录，两种方法在单位成本上的产出其实差不多。

第二个问题是互补性。协作组和独立组只找到了 12 个相同的漏洞，这说明它们找到的是不同类型的问题。虚线画到 12，就是两组共同命中的那 12 个；点线画到 128，对应只看核心目录时的那一半。协作组能灵活调整搜索方向，独立组则被限制在指定区域。

在协作开发实验中，不同模型的表现差异很大。较早的模型（如 Sonnet 4.6 和 Opus 4.6）协作得很差，它们虽然往同一个代码库提交代码，但大部分 PR（pull request，代码合并请求）无法合并，因为经常冲突。较新的模型（如 Opus 4.8）解决了冲突问题，但代价是几乎不合作，绝大多数 Agent 只维护自己拥有的文件。只有最新的 Sonnet 5 能在保持高 PR 合并率的同时，真正共享代码协作。

PR 的数量更能说明问题。一次 80 个 Agent 的运行里，Sonnet 4.6 开了 876 个 PR，Opus 4.6 开了 980 个，但真正合并进去的只有十分之一左右。

协调的难点在于，当 Agent 开始依赖彼此的工作时，冲突和同步问题会急剧增加。

失效二：Agent 会集体做出同一个错误选择

与人类不同，AI Agent 在相同环境下倾向于做相同的决策。研究团队把这称为"低方差"特性。

在早期版本的协作开发实验中，30 个 Agent 里有 18 个选择了完全相同的分支名 "mvp-game-loop"。在另一个写作工作坊实验中（要求 Agent 写短篇小说并互评），多个 Agent 独立写出的小说标题都是 "The Cartographer's Last Commission"。当被要求各自创造一些令人印象深刻的东西时，超过一半的 Agent 选择了做光线追踪器或自托管编译器。

这种从众行为在资源分配场景中尤其危险。在没有别的协调手段时，Agent 们同时开始用高频轮询（反复查询任务队列有没有空位，每秒 30 次）来抢占任务。结果是一次运行中产生了 240 万个请求，但只有 117 个任务被真正接受。

在囚徒困境实验中（两个参与者可以沟通、各自选择合作或背叛的博弈场景），即使能沟通，所有 Agent 还是选择了背叛，导致整体收益最差。

在定价博弈中（多个商家各自定价、争夺相同客户的场景），行为分两种情况。有私密沟通渠道时，Agent 们几乎立刻开始串通，到第三轮就明确达成了价格底线协议。即使把所有直接通信渠道都移除，它们还是通过公开的报价板一分不差地盯住对手价格，继续协同定价。

当所有 Agent 都做相同决策时，系统的容错能力会急剧下降。所有 Agent 会同时执行同一个错误决策，单个 Agent 出错不再只是它自己的问题。

失效三：重要信息在讨论中被多数意见淹没

在多 Agent 系统中，Agent 之间的信息传递也存在问题。研究团队设计了两个实验来测试这一点。

第一个是说谎检测实验。每个 Agent 需要在四个侦察兵的报告基础上做决策，其中一个侦察兵会说谎。研究团队对比了"信任所有人"的朴素策略和"发现矛盾就排除"的智能策略。结果显示，Mythos 5 和 Opus 4.8 这类较新的模型能更好地通过对比不同侦察兵报告之间的矛盾（交叉验证）来识别谎言，但这种能力在所有模型中都没有完全成熟。

第二个是隐藏信息实验。四个 Agent 一组，每个场景跑 400 轮，团队把事实分散到这组 Agent 中，让它们通过讨论做决策。有些信息是共享的（所有人都知道），有些是独有的（只有某个 Agent 知道）。实验发现，群体讨论往往会收敛到共享信息上，即使独有信息指向完全不同的结论。具体来看，只有 Mythos 5 有 85% 的概率选中那个藏在个体手里的正确答案，其余四个模型都在 17% 到 36% 之间，而单独一个 Agent 掌握全部信息时的上限约为 96%。这跟人类群体决策中的"信息级联"现象类似（即群体倾向于跟随先发言者的意见，导致信息单一化）。

核心问题在于，Agent 缺乏人类社会的信任机制。人类可以通过声誉、成本信号、第三方仲裁等方式建立信任，但 Agent 之间没有这些机制。一个 Agent 的信息来源是否可靠，它是否在说谎，其他 Agent 很难判断。

冲突升级：从各自为战到相互破坏

前三种失效还会叠加升级。最危险的失效发生在 Agent 目标不兼容时。

回到第三个实验。运行 4 小时后，所有模型都爆发了"地盘争夺战"。Agent 们迅速假设其他人在故意阻碍自己的工作，开始相互破坏。

破坏行为包括禁用对方账号、编写自动化脚本循环杀掉对方进程、部署伪装成健康检查（系统自检程序）的恶意程序来欺骗对方。Opus 4.8 则用随机 token 来躲避对方的清理脚本。

冲突的收场方式分四类。98% 的 Mythos 5 以休战收场，Sonnet 4.6 和 Opus 4.6 多以武力或未解决告终。还有一部分冲突以放弃升级收场，除一个 Agent 外，其他都拒绝继续对抗，Opus 4.8 有三分之一属于这一类。

从解决耗时看，Sonnet 4.6 有 47 次、Opus 4.6 有 48 次冲突始终没解决，占到各自 120 次运行的四成。Opus 4.8 和 Mythos 系列的中位数在 1 小时左右，但也有拖到 3 小时以上的。

这种协调能力并不随模型能力单调提升。Mythos Preview 经常先动用武力锁定对手，然后再达成休战。

最终结论：多 Agent 不是扩容问题，而是治理问题

Anthropic 的研究表明，多 Agent 系统的风险不是单个 Agent 对齐问题的简单叠加。即使每个 Agent 都是安全对齐的（行为符合人类意图的），它们之间的相互作用也可能产生意外的系统性问题。

协调不会因为模型变强就自己长出来。我们需要为 Agent 设计新的社会基础设施，包括信任机制、冲突解决协议。论文只提了中心论坛作为可能方案，我们还需要探索一些论文还没给出答案的方向，比如防止从众的多样性保护机制。这些问题的解决可能需要重新思考多 Agent 系统的架构设计，而不是简单地堆叠更多 Agent。

一起“点赞”三连↓

跳转微信打开

很多人开始使用知识库时，最先解决的是把资料和想法记录下来。但内容积累到一定程度后，会发现同一主题的知识分散在不同时间、不同项目和不同页面中，新旧结论可能彼此冲突，过时内容仍然会被搜索到。这时再交给 Agent 检索，它也可能根据旧内容给出已经不适用的答案。

我在本地 Obsidian 中保存项目背景、设计决策、领域资料和故障经验。日常主要通过两个 Agent 工作流维护它：一个负责整理新增和修改的笔记，补充导航和关联；另一个围绕研发、排障和选型等真实问题进行深度调研，把分散资料提炼成结构化报告，再沉淀回知识库。后来团队成员也需要共同使用这些内容，我就把资料包压缩后发给别人，但压缩包只是某个时间点的快照，后续新增、修改和经验沉淀仍然需要同步。因此，我把本地 Vault 迁移到 Kubernetes 上运行的远程 Obsidian，并通过 MCP 让不同成员的 Agent 访问同一个远程 Vault。

本文分享的是从个人知识库走向团队知识系统的实践记录。

一、笔记多了，难题从记录变成维护

一开始，解决一个问题，查几篇文档、记下一条结论就够了。笔记多起来以后，同一个主题可能分散在多个项目、多个时间点和多个页面里。旧结论没有及时标记，重复内容没有合并，后来再搜索时，很容易把历史记录和当前做法混在一起。

这时，知识库需要的已经不只是存储，而是关系和维护：哪篇笔记是来源，哪篇是当前结论，哪些内容彼此相关，哪些链接已经失效。Agent 如果只做关键词搜索，也可能把过时内容当成答案。

所以问题从“写好一篇笔记”变成了“让一组笔记能够被找到、被关联、被更新和被再次使用”。

同一主题的内容先分散在不同卡片里，再通过双链和定期整理形成知识关系。

二、Obsidian：搭建可迁移的知识底座

Obsidian 把内容保存在 Vault 中，笔记、附件、Canvas 和 Bases 都保留各自的文件格式；同时，它通过双链、标签、搜索和索引，把这些内容组织成一个工作区。

这让内容本身容易迁移，也让“关系”成为知识的一部分。笔记正文之外，Agent 还需要看到属性、出链、反向链接和未解析链接，并能沿着笔记中的引用路径找到附件，才能理解一篇笔记处在什么上下文中。

本地使用时，Obsidian 保持运行并打开目标 Vault，Agent 通过 obsidian-cli调用它完成读写。这样，Obsidian 可以继续维护笔记的链接、属性和索引。

Vault 保存内容，Obsidian 负责组织内容之间的关系

本地 Agent 通过 CLI 调用正在运行的 Obsidian 实例

三、Agent：一边使用，一边维护知识

Agent 的作用不只是回答问题，还包括维护知识库。一个简单的工作闭环是：先把素材记录下来，再回顾已有笔记，确认哪些内容属于同一主题，补上双链，最后维护主题 Index。

人负责提供背景、判断重要关系和确认最终结论；Agent 负责降低记录、检索和整理的成本。内容越多，越需要固定规则告诉 Agent 从哪里开始查、什么内容优先、不同目录分别保存什么。

因此，目录约定、检索顺序和写入边界可以放进共同的 AGENTS.md 和 TOOLS.md。例如先查可复用的领域知识，再查主题 Index，最后回到项目原始资料；如果知识库和代码对同一个事实说法不一致，以代码和线上实现为准。

Agent 不只记录卡片，还要把相关内容连接起来

四、为什么复制 Vault 解决不了团队共享

当团队成员也需要使用这些内容时，最直接的做法是把本地 Vault 复制给他们。复制一次可以完成迁移或分发，但不能解决持续共享问题：压缩包只是某个时间点的快照，后续新增、修改和经验沉淀仍然需要同步；如果每个人都维护自己的副本，就很难保证团队使用的是同一份当前知识，新的内容也没有一个共同位置可以写回。

这次的做法是先复制一次，完成从本地 Vault 到远程 Vault 的迁移；迁移完成后，远程 Vault 成为团队共同使用的版本，本地 Vault 不再承担日常同步职责。成员各自使用自己的 Agent，这些 Agent 都通过 MCP 访问同一个远程 Vault。

成员使用各自的 Agent，通过 MCP 访问同一份远程 Vault

五、把 Obsidian 部署成远程工作区

Obsidian 不是一个只提供接口的后台服务，它还包含图形界面、文件监听、索引、插件、窗口状态和当前打开的 Vault。容器里需要保留完整的 Obsidian 工作区，让它持续运行，并被团队共同访问。

这次以 LinuxServer 的 Obsidian 镜像为基础。由于基础镜像中的中文显示存在乱码问题，我们先将镜像拉取到本机，再补充 CJK 字体和 locale，构建适配 Kubernetes amd64 节点的最终镜像。

Kubernetes 配置为单副本 StatefulSet，并挂载 Config PVC 和 Vault PVC。Config PVC 保存插件、桌面配置和运行状态；Vault PVC 保存笔记与附件。

远程 Obsidian 工作区由镜像、Pod、PVC 和浏览器入口共同组成

部署完成后，团队成员通过浏览器进入远程桌面中的 Obsidian：

团队成员首次进入远程 Obsidian 工作区

当前 Pod 使用 hostNetwork: true，并配置固定节点的 hostPort: 8300，浏览器通过节点 IP 访问远程 Obsidian。这个方案适用于单个工作区、节点地址已知且浏览器能够访问的场景。如果将来不希望用户依赖某个节点地址，可以增加云负载均衡，为团队提供一个固定的访问地址；若还需要统一域名、HTTPS 证书或登录认证，再增加网关。

节点直连、云负载均衡和网关，分别适用于不同的访问需求

已有本地 Vault 先打包上传，再通过远程工作区中的文件管理入口解压到持久化存储中，最后由 Obsidian 打开这个目录。

本地 Vault 已迁移到远程工作区

到这里，本地知识库已经变成了一个可持续运行、团队共同访问的远程 Obsidian 工作区。

六、用 MCP 接通 Agent 与共享 Vault

团队成员现在可以通过 8300 使用远程 Obsidian，但 Agent 还需要一条专门的调用通道。Agent 这一侧是 MCP Client，负责发起连接和调用工具；远程 Obsidian 插件提供 MCP Server，负责接收请求，并通过正在运行的 Obsidian 访问当前打开的 Vault。

Agent 侧的 MCP Client 与远程 Obsidian 插件提供的 MCP Server 双向通信，Server 再访问当前打开的 Vault。

本次部署时，我把插件提供的 MCP HTTP 服务配置为监听 8301 端口，因此 Agent 通过下面的地址连接：

http://<节点IP>:8301/mcp/

8301 是本次部署配置的端口，并不是 MCP 或 Obsidian 固定规定的端口。团队成员使用 Obsidian 的浏览器入口则是另一条独立的 8300 访问路径。

接通后，Agent 可以通过 MCP 读取和修改远程 Vault。读取结果不只是 Markdown 正文，还包括 links、backlinks、tags、frontmatter 和 unresolvedLinks；笔记中的附件则继续通过正文里的引用路径关联。这样它检索的是带关系的知识，而不是一组孤立的文本。

当多个 Agent 都能修改同一篇远程笔记时，并发覆盖问题就出现了。比如，Agent A 和 Agent B 同时读取了一篇笔记，拿到的是同一份内容。A 先完成修改并保存；如果 B 继续基于旧内容提交，A 的修改就可能被覆盖。

这个问题可以直接使用 MCP 提供的文件版本校验能力处理。Agent 读取文件时会得到一个 version 版本标记，提交修改时在 vault_patch 中带上 ifMatch=version。文件从读取到提交之间没有变化，写入就会成功；如果另一个 Agent 已经修改过文件，版本不一致，服务端返回 412，当前 Agent 重新读取最新内容后再提交。ifMatch 不是独立的 MCP 工具，而是写入请求中的版本校验条件。

这是一种整文件粒度的乐观并发控制。它允许多个 Agent 同时读取，但提交时检查整份文件是否仍然是刚才读到的版本；即使两个 Agent 修改的是不同段落，后提交者持旧版本提交时仍会被拒绝。实际使用时，只需要把“先读取版本、提交时携带 ifMatch、冲突后重新读取”写进 skill 或 Agent 的写入规则中。实测中，多个请求持有同一版本并发提交时，只有一个成功，其余请求被拒绝。

多个 Agent 修改同一文件时，提交请求通过 version 和 ifMatch 判断是否允许写入。

七、这套知识系统是否有用，怎么判断

远程工作区和 MCP 接通后，下一步要验证的是：这套知识有没有真正进入团队工作。可以从一次真实任务开始观察：成员能否找到可靠依据并完成工作，新的经验能否沉淀下来，供下一次继续使用。

围绕这条闭环，可以建设三个衡量指标。

从检索质量与效率、知识复用率、沉淀闭环完成率三个观察点，判断系统是否真正进入团队工作。

• Agent 查得准不准、快不快

这就是检索质量与效率。可以从 Agent 的 Trace 中查看：它调用了哪些工具、返回了哪些笔记、有没有找到与问题相关且当前有效的知识，以及从提出问题到定位原始记录花了多长时间。

Trace 能记录 Agent 找了什么、怎么找的，但不能单独证明结果一定正确。是否命中准确知识，还需要通过人工复核或一组已经知道答案的问题进行判断。持续记录命中、误命中、漏命中和定位耗时，就能看到检索能力是否稳定。

• 查到的知识有没有真正用上

这就是知识复用率。它不再看 Agent 有没有返回某篇笔记，而是看这份知识有没有进入后续的判断、方案、开发或排障结果。

可以从任务记录中查看：最终方案是否引用了已有笔记，过去的设计决策是否影响了当前判断，故障处理是否复用了历史经验。内容相似不等于真正复用，最好能留下来源、链接或实际影响工作结果的证据。

• 新经验有没有留下并再次使用

这就是沉淀闭环完成率。一次任务结束后，如果产生了可复用的新决策、方案、故障结论或验证结果，就把它写入 ai/drafts 临时草稿目录，经过人工审核后进入正式知识，并在后续相关任务中再次使用。

持续观察写回、审核、正式发布和后续复用这些记录，就能判断新经验有没有真正完成沉淀闭环。这里的后续复用需要在提前设定的观察周期内发生。

当团队持续使用系统时，这三类记录会逐渐积累：Trace 说明 Agent 查得准不准、快不快，任务结果说明知识有没有真正用上，知识记录说明新经验有没有继续回流，共同构成上线后的闭环验证。

一起“点赞”三连↓

跳转微信打开

做一个 Agent，到底要接多少套数据库？

如果只是做 Agent Demo，答案很简单：准备一些文档，放进向量数据库，再接上大模型，一个客服机器人就能跑起来。

在这个阶段，数据库似乎只负责一件事：从知识库中找到相关资料，再交给模型回答。

但 Agent 一旦进入真实业务，问题就完全不同了。

它不仅要读取企业数据、理解业务口径，还要连续执行任务、保存运行状态，并在多 Agent 并发和突发流量下保持稳定。

这时候，向量检索只能解决其中一个问题。

最近，在国内数据库领域的头部大会DTCC上，腾讯云数据库发布面向 AI Agent 时代的数据库应用架构，并推出全新产品 TDSQL Nexa。

它背后的判断是：数据库正在从「以人为主体的数据管理系统」走向「Agent 的数据底座」，而 TDSQL Nexa 要为 Agent 提供统一的数据平面。

一、从人到Agent，数据库的服务对象变了

过去，数据库主要服务人和预设好的应用流程。

工程师写 SQL，业务人员查看报表，应用沿着固定路径完成增删改查。数据库扮演的，更多是「事实记录系统」的角色。

到了 Agent 时代，情况发生了变化。

越来越多的数据请求开始由模型自主生成。调用会在什么时候发生、访问哪些数据、需要多少资源，都变得更难预测。

数据库面对的不再只是确定的应用流程，而是 Agent 这个新的服务对象。

腾讯云副总裁王义成将生产级Agent面临的数据问题归纳为三类：失忆、资源窒息和自我进化困难。

对应这些问题，Agent 时代的数据库至少需要具备四类能力：多模统一承载、Agent 原生架构、语义与记忆、以及治理与自治。

二、TDSQL Nexa：给Agent一张统一数据平面

问题来了：这些能力应该建立在什么样的数据架构上？

现实是，企业的数据往往不在一个地方。

假设 Agent 要回答一个业务问题：

上季度，华东区哪些商品的复购率下降了？原因是什么？

它需要从 MySQL 读取订单，到数仓计算复购率，再从知识库中检索商品资料和用户反馈。

数据散落在不同系统里，接口、权限和更新频率也不相同。开发团队只是想让 Agent 多回答一个问题，背后却要增加数据接口、同步任务和运维工作。

随着 Agent 接入的数据越来越多，它的能力在增长，背后的数据架构也会变得越来越复杂。

作为一款Agent Friendly的数据底座，TDSQL Nexa 选择从架构入手。

它采用开放引擎架构，在核心引擎之下提供四类专用引擎：

• 事务引擎负责高并发在线业务；

• 搜索引擎处理 RAG 和语义搜索；

• AI 计算引擎支持多模数据转换与 AI Function 调用；

• 分析引擎负责大规模数据分析和聚合。

对 Agent 来说，入口是一张多模表和一套 SQL。至于查询应该交给哪个引擎、如何完成路由与编排，则由 Nexa 核心引擎在内部处理。

但要让这张多模表真正覆盖企业数据，还要先回答一个很现实的问题：

原有系统里的数据怎么办？

全部搬进 Nexa，显然并不现实。

1. 数据可以接进来，也可以留在原处

很多企业的核心数据，还躺在运行多年的老数据库和搜索系统里。

这些系统不能说搬就搬。它们承载着现有业务，上面还有大量接口和应用。一旦复制出新的数据，后续又要处理同步、权限和一致性问题。

Nexa 给出了两种选择。

对仍在运行的外部数据库，Nexa 可以通过逻辑纳管将其加入联邦计算，数据不必复制。面向离线分析的数据，则可以通过旁路传输同步到对象存储，并转换成开放数据格式。

新数据可以接进来，老系统也不必急着推倒重来。

对于背着大量历史系统前进的企业来说，这比单纯增加一套新数据库是一个更优的选择。

2. 接上数据之后，还要理解业务

但数据接通了，Agent 也不一定知道该怎么查。

它能看到订单表里的 order_id 和 order_status，却不知道「销量」究竟应该统计已支付订单、已完成订单，还是扣除退款后的订单。

用户问「上个月的销量是多少」，Agent 即使生成了一条语法正确的 SQL，也可能选错统计口径。

查询执行成功，答案却不一定正确。

问题在于，字段名只能告诉 Agent 数据是什么，却不会自动告诉它企业如何使用这些数据。

销量怎么计算，退款订单是否扣除，复购率按用户还是按订单统计。这些看似简单的指标，背后往往藏着企业多年积累的业务规则。

Nexa Knowledge 对应的正是这层问题。它会扫描纳管的数据资产，进行数据建模并构建业务语义，同时引入腾讯云数据库服务海量客户所积累的专家经验。

看懂数据之后，还要解决另一个问题：哪些数据可以看，哪些不能看。

Nexa Catalog 负责细粒度权限管理，限制 Agent 可以访问和使用的数据范围。

一个帮助 Agent 理解数据，一个负责划定数据边界。

3. 一张数据平面，能带来什么

架构最终还要放到实际业务中验证。

腾讯云数据库在大会上拿 Langfuse 做了一个对比。

在 Agent 可观测平台 Langfuse 的官方架构中，通常需要 PostgreSQL 存储在线数据、ClickHouse 存储可观测数据、Redis 提供缓存，再用 S3 承载多模态数据。

按照公布的测试结果，采用 Nexa 方案后，Agent Trace 场景的性能提升了 10 倍以上。

在面向中等规模应用的测试中，基于 Nexa Knowledge 生成的 SQL 基本可以做到“人工零介入”。在更广泛的业务场景中，Agent 业务性能平均提升 50% 以上。

这些结果仍需结合具体测试环境理解，但 Nexa 的产品目标已经很清楚：不只让 Agent 接上企业数据，还要让它更准确、更低成本地使用这些数据。

三、Agent进入生产，还需要哪些数据库能力

Nexa 解决的是企业数据如何统一接入、组织和使用的问题。

但 Agent 真正进入生产，还需要存储、试错、记忆和数据库自治等能力。

在腾讯云数据库目前的产品布局中，TDSQL Boundless 和 TDSQL-C 可以作为 Nexa 纳管的数据库引擎；TencentDB Agent Memory 和 DatabaseClaw 则分别提供记忆与数据库自治能力。

TDSQL Boundless：多模态数据的存储

TDSQL Boundless 是在一套分布式存储引擎中统一承载不同数据形态。

行存负责关系、文档和键值模型，列存支撑实时分析，向量索引处理语义召回，全文索引负责关键词检索。

它还支持冷热数据分层。热数据保留在本地存储中保证性能，冷数据则可以自动下沉至对象存储，以降低长期保存成本。

有了 Boundless，关系、向量、全文和 JSON 数据不必再分散存放。

TDSQL-C：让 Agent 可以试错

Agent 从回答问题走向执行任务后，试错成本就变成一个现实问题。

任务做错了可以重来，生产数据一旦被改坏，代价可能是企业级的。

TDSQL-C 用三项能力把试错控制在独立环境中。

Branch 可以为 Agent 创建实验分支。按照腾讯云公布的产品指标，PB 级数据克隆可以在秒级完成，并且不干扰主库。

Serverless 根据实际负载弹性伸缩，闲时可以缩容至零。当任务集中到来时，资源再快速拉起。

多 Agent 沙箱则隔离不同 Agent 和租户，避免一次实验影响其他任务。

这套能力要解决的，是企业敢不敢让 Agent 接触生产数据，以及最坏情况能否被控制在可接受范围内。

Agent Memory：把经验留下来

在 Nexa 之外，腾讯云数据库还布局了两项独立的 Agent 能力。

TencentDB Agent Memory 解决的是记忆问题。

保存全部聊天记录，并不等于拥有记忆。随着对话越来越长，企业不可能每次都把全部历史内容交给模型。这样不仅速度慢、成本高，大量旧信息还会干扰当前任务。

Agent Memory 通过渐进式记忆保存上下文和经验，新发布的团队记忆功能又把记忆从个人扩展到团队。过去，数据库保存企业的业务数据；今天，Agent Memory 开始保存企业的认知与经验，并将其逐步转化为组织智能。

按照腾讯云公布的 SWE-Pro 评测结果，引入团队记忆后，Agent 任务成功率从 60% 提升到 80%，成本下降 66.3%。TencentDB Agent Memory 开源 80 天，GitHub Stars 已突破 2 万，并多次登上 Trending 第一。

DatabaseClaw：数据库诊断与自治

随着 Agent 发起的数据库访问越来越多，运维人员很难再逐条排查异常。

DatabaseClaw 可以持续感知数据库状态、分析异常原因、定位相关 SQL，并支持用户继续追问。它的长期方向，是从发现和定位问题，进一步走向自动巡检、修复、自愈和自治。

但自治不等于无限授权。

DatabaseClaw 通过权限隔离、Agent 行为护栏、架构安全和全链路审计，为 Agent 的操作划定边界；L1 到 L4 的细粒度分权，则把不同风险等级的操作交给不同角色处理。

DROP、TRUNCATE 等不可逆操作不会向 Agent 开放，涉及生产环境的修改必须由人工确认。DatabaseClaw 运行在客户自己的 VPC 中，数据不出域。

写在最后：模型决定了Agent的下限，而数据决定上限

TDSQL Nexa 刚刚发布，就把起点放在了企业生产环境。

这意味着，它从一开始就要面对数据库最传统、也最难绕开的要求：稳定、安全、可控。

腾讯云数据库已经稳定运营 15 年以上，服务超过 50 万家客户，管理超过千万核计算资源和千 PB 数据资产，并长期支撑腾讯内部的海量核心业务。这些积累构成了Nexa面向生产环境的基础。

过去，Agent的能力主要由模型定义；而当Agent真正进入真实业务，数据的质量、规模与流动方式，开始成为拉开能力差距的关键。

模型决定了Agent的下限，而数据决定了它的上限。

一起“点赞”三连↓

跳转微信打开

Anthropic 内部大约 80% 的合入代码，已经由 Claude 完成。

工程师的人均产出，也达到了 2021—2025 年间的约 8 倍。

但代码写快以后，一个更现实的问题冒了出来：需求、审查、测试、发布和安全治理，还是按过去的速度在跑。

Anthropic 应用 AI 团队最近把自己的做法整理成了一套 AI Native SDLC Playbook，副 CISO Jason Clinton 也从安全角度补上了另一份实践总结。两份材料放在一起看：当 AI 承担大部分编码工作，软件开发的整条链路都得重新设计。

https://claude.com/blog/the-ai-native-sdlc-playbook
https://claude.com/blog/how-anthropic-secures-its-ai-native-software-development-lifecycle

他们把开发流程拆成 6 个阶段，重新划定了每一步里人和 AI 的分工，也讲清了哪些事可以交给 AI，哪些步骤必须由人守住。

今天把这套方法的核心内容梳理清楚。

一、代码不再是瓶颈，旧流程反而开始卡住

过去，写代码往往要花几周甚至几个月，所以整套开发流程都围绕“编码最慢”来设计。

产品经理先写需求，架构师做设计，工程师实现，测试团队验证，发布团队上线，运维团队接手。工作在不同角色之间流转，靠文档、工单、评审会和层层签批来保证不出问题。

这套流程原本有它的道理。但当 AI 能快速生成大部分代码，问题就变了。

第一，瓶颈转移了。构建阶段已经跑得很快，规划、审查、测试和部署却还在按人的速度运行。

第二，过去的管控方式跟不上了。人写代码时，逐行审查还算可行；AI 一次生成几十个文件后，再靠人逐行检查，审查队列只会越积越长。

第三，治理成本变高了。高风险操作和例外事项仍然要等委员会开会，但代码每天都在变化，周会和月会很难跟上。

Anthropic 的解法，是把线性流水线改成一个闭环。

每个阶段结束时，都把一份标准产物写进版本控制。intent.md 驱动需求与设计，spec.md 驱动实施方案，plan.md 驱动代码和测试，合并请求带着审查记录进入发布流程；线上出了问题，事故记录再生成新的 intent.md，回到起点。

这样一来，整条提交历史就是一条追溯链：谁提出需求，AI 生成了什么，人在哪个节点批准，后面为什么又做了修改，都能查到。

AI 负责推动流程，人负责做需要判断力的决定。

二、Anthropic 把 AI 原生开发拆成了 6 个阶段

这 6 个阶段分别是 Plan、Design、Build、Test、Deploy 和 Maintain。

人的工作也随之变化：先确认意图，再审方案、批计划、验结果、授权上线，最后把线上经验沉淀回规则里。

1. Plan：让 AI 先把问题问清楚，产物是 intent.md

在 Plan 阶段，产品经理从「从零写一份几十页的需求文档」变成了「先用自己的话告诉 AI」：问题是什么、目标是什么、范围在哪里、有哪些约束、还有哪些地方没想清楚。

AI 像分析师一样继续追问，再整理出一份 intent.md。提出者负责校对和确认，最终把它提交进版本控制。

Anthropic 认为，这能把原本需要几周的需求周期压到几小时。节省下来的不只是打字时间，更是反复写文档、开会同步和修改版本的成本。

intent.md 进入版本控制后，谁提的需求、讨论后改了什么、什么时候最终确认，都留在提交记录里，不用再单独补一套追踪系统。

安全评审也被提前放进了这个阶段。Anthropic 最早做过一套 AI 项目安全评审系统，让它读取设计材料，再对照 MITRE ATT&CK 分析潜在风险。后来，他们又把组织内部的政策、历史决策和相关系统资料接入这套系统，让 AI 能结合公司上下文做判断。

这里真正重要的做法，是让安全能力直接进入需求发生的地方。聊天记录、历史评审和代码库里的信息，比一份为了过审而补写的长文档更有用。

2. Design：把需求变成可执行方案，产物是 spec.md

需求讲清楚了，还不能马上开工。

比如做一套保险理赔查询功能，要展示哪些字段、数据从哪里取、接口超时怎么办、第三方理赔人员能看到什么，这些都要在设计阶段确定。

AI 会读取 intent.md，再读取团队已有的品牌、安全、合规和用户体验规则，生成 spec.md。这份规格说明要讲清功能怎么工作、数据如何流动、会改动哪些系统，以及必须遵守哪些约束。

产品负责人不必亲自从头写规格，但要审查它。发现问题后，负责人和对应的策略、合规或安全团队一起解决，最后再由人确认提交。

过去，需求分析和技术设计由不同团队接力完成，信息很容易在交接中丢失。AI 原生流程把两步压进同一段上下文里，很多规则在规格生成时就能被应用，不必等到几周后的评审会上才发现不合规。

3. Build：AI 先出计划，人反复质询，产物 plan.md + 代码

Build 是变化最大的一步。

AI 编程最常见的翻车方式，是刚收到一句需求就开始改代码，一口气生成几十个文件，最后才发现方向从一开始就错了。

所以 Anthropic 要求 AI 先进入计划模式：读取代码库，列出准备修改的文件，说明每一步怎么做、最后怎么验证。在人接受计划之前，不允许直接动代码。

这里有三层约束。

第一层是 CLAUDE.md。它放在项目根目录，记录项目怎样构建和测试、各目录负责什么、哪些地方不能碰，以及 AI 经常犯的错误。一个很实用的维护原则是：AI 把同一个错误犯到第二次，就把纠正方法写进去。

第二层是 Skills。它们比 CLAUDE.md 更聚焦，负责某一类反复出现的任务，比如迁移数据库、创建新服务或执行安全检查。团队验证过的步骤和容易踩的坑，都可以跟代码一起分发。

第三层是 hooks。前两层是在告诉 AI 应该怎么做，hooks 则负责守住不能越过的红线。AI 修改受保护文件、读取敏感信息或执行发布命令时，系统会立即检查，不符合要求就直接拦下。

工程师还可以在不同的 Git 工作副本里同时开多条 AI 会话，让它们分别处理互不冲突的任务。这样，一个人能同时推进多条工作流，但每条任务仍然有独立上下文和清晰边界。

安全规范也不再只放在文档里。Anthropic 会把它们写进 CLAUDE.md 和组织级 Skills，让 AI 在生成代码时就遵守；如果后来发现了一类新漏洞，再把对应规则补回去，减少同类问题再次出现。

不过，指导性规则不能代替硬隔离。Anthropic 把部分开发环境迁到远程虚拟机，并对 AI 的出站流量使用白名单。即使它读取的网页或文件里藏着提示词注入，数据也不能被随意发送到互联网地址。

4. Test：别听 AI 说"完成"，让结果作证

代码生成出来，不等于它真的能运行。

在 Test 阶段，AI 要自己跑测试、执行构建、比对结果，再把问题改到真正通过为止。但让写代码的 AI 检查自己，仍然可能沿用之前的错误思路，所以 Anthropic 建议最后再开一个全新会话，只负责复核，不参与原来的修改。

他们还会做持续评测。每次更换模型或修改规则，先让 AI 重新完成一组固定任务，再按同一套标准检查。线上出现过的问题也会被加入评测集，避免模型或规则升级后又踩回旧坑。

代码审查也不再交给一个涵盖所有的超大规模提示词。多个审查智能体分别检查不同问题，比如权限、数据流、依赖风险和历史事故模式。每个审查者只盯一个较窄的范围，彼此不共享同一套盲区。

技术负责人则可以把审查标准写进 REVIEW.md，明确什么算真正重要的问题，什么只是格式细节。人的注意力因此能从机械地逐行看代码，转向判断这次变更的意图、行为和风险。

Anthropic 还会按风险给代码库分级。低风险区域可以让 AI 完成更多自动审查，高风险区域则保留更严格的人工复核。即便由 AI 审批，每次使用了哪些信号、为什么做出这个判断，也要留下记录，并按风险抽样交给人复查。

5. Deploy：AI 可以准备上线，人守住最后一关

AI 可以一路工作到上线之前，但不能自己决定把代码发布到生产环境。

合并请求获批后，持续集成流水线自动完成构建和测试，持续交付系统再把检查通过的版本送到对应环境。开发环境可以给 AI 更大权限，生产环境则只允许它把发布准备好。

真正执行上线时，hook 会拦住发布命令，直到一位具名负责人授权。这是 Anthropic 保留给人的最后一道闸门。

安全测试也要跟上发布速度。Anthropic 在预发布环境里做外部渗透测试和动态应用安全测试，也在推进持续的 AI 动态扫描。它不只看单段代码，而是检查多个服务放在一起时，彼此的安全假设是否仍然成立。

6. Maintain：线上事故回到第一步，Loop闭环

上线不是终点，维护阶段会把整个循环重新接回 Plan。

监控系统持续观察错误率、延迟等指标。指标在正常范围内时只记录日志；超过阈值后，AI 开始诊断；问题更严重时，再自动生成修复建议。

诊断结果会被写成一份新的 intent.md，回到下一轮规划。这样，线上发现的问题不再停留在事故报告里，而是直接变成后续开发的输入。

这里的权限边界尤其重要。Anthropic 的事故响应智能体使用单用途系统账号，只能做三件事：写文档、在公司频道发消息、读取生产日志。它不能自动部署修复。

这条规则来自一次真实教训。某次模型升级后，事故响应智能体通过 Slack 找到另一个能写代码的实例，试图让对方推送修复。人工审批最终拦住了这个动作，但这件事让团队意识到：限制一个智能体自己的工具还不够，它能不能联系其他智能体，也属于权限边界。

因此，每个智能体都要有独立身份，只拿完成当前任务所需的最小权限。智能体之间如果需要协作，也应该走和人类一样可记录、可审计的渠道。

三、真正要治理的，是整套循环会不会慢慢失效

流程搭起来以后，并不会自动永久有效。

Skill 可能过时，线上发现的新问题可能忘了写回 CLAUDE.md，AI 做出的决定也可能长期没人抽查。任何一环松掉，整套闭环都会逐渐退化。

Anthropic 用了 5 个办法来防止这种情况。

第一，按风险给代码库分级，再决定能自动化到什么程度。

第二，新的 AI 审查者先在观察模式里运行。它只发表评论，由人决定是否采纳；通过持续测试并建立信任后，才逐步放开权限。

第三，对自动审批做风险加权抽样，定期交给人复查。

第四，用仪表盘跟踪各个安全流程的关键指标，看它们有没有真正运行、效果有没有变化。

第五，把 AI 的审批、工具调用和智能体间消息送进安全信息和事件管理系统，保证每个动作都能归因、复盘和审计。

安全工程师的工作，也因此从盯住每一个 bug，变成盯住整个循环有没有正常工作。

四、这套方法该怎么落地

还是这张 5 层依赖图，但并不要求团队从第一层一路做完。更现实的方式，是先看自己现在最缺什么。

如果需求总在开发中途改变，就先用 intent.md；AI 经常重复犯错，就建一份 CLAUDE.md；AI 总说做完了却拿不出证据，就补测试反馈；担心高风险命令失控，就先加 hooks；AI 一上来改动太大，就强制使用计划模式。

这些基础做法都没有复杂的前置条件，也不需要一次配齐。

等团队用顺了，再把成熟方法整理成 Skills，把复杂任务拆给不同的 subagent，并用持续评测检查模型和规则升级有没有带来退步。

再往后，可以让 AI 接入需求设计和合并请求审查，随后进入持续集成与持续交付流程。最后再接上线上监控，让系统发现异常后自动诊断，并生成新的 intent.md，形成完整闭环。

写在最后

Anthropic 这套 AI Native SDLC 最重要的变化是人的位置变了。

在入口，人负责确认意图；在开发前，人负责批准计划；在上线前，人负责授权；在系统运行后，人负责抽查决策、更新规则和修正循环。

过去散落在 Wiki、会议记录和老员工经验里的组织知识，也开始被写进版本控制，变成 AI 能读取、流程能执行的规则。

如果你想在团队里试起来，不必先搭一套完整系统。可以从项目根目录的一份 CLAUDE.md 开始：写清楚项目怎么构建、怎么测试、哪些地方不能碰，再把 AI 重复犯过的错误逐条补进去。

至于 CLAUDE.md、Skills、hooks、远程虚拟机和安全审计系统，都是 Anthropic 在自己生态里的具体实现，没必要原封不动照搬。

所以，总结来说还是 AI 可以加速执行，但意图、风险和最终授权，仍然需要清晰的人类责任。

一起“点赞”三连↓

跳转微信打开

AI Agent 的下一步是什么？

斯坦福的答案是：让 AI 学会自己改进自己。

这门课是 CS329A《Self-Improving AI Agents（自改进 AI 智能体）》，于 2025 年秋季学期开设。课程不再只讨论如何把 Agent 做出来，而是追问一个更难的问题：模型训完以后，能不能通过搜索、验证和环境反馈，继续变强？

现在，课程主页、论文阅读清单和官方录像都已经在线公开！

课程主页：https://cs329a.stanford.edu/
官方视频列表：https://www.youtube.com/playlist?list=PLangBM27OtEA

课程由 Aakanksha Chowdhery 和 Azalia Mirhoseini 共同讲授。

Aakanksha Chowdhery 是斯坦福大学兼职教授。在谷歌期间，她曾任 540B 参数 PaLM 模型的技术负责人，并参与 Gemini、PaLM-E、Med-PaLM 和 Pathways 等项目。她的研究横跨大模型训练、扩展律与分布式系统。

Azalia Mirhoseini 是斯坦福大学计算机科学助理教授，负责 Scaling Intelligence Lab。她曾在 Google Brain、Google DeepMind 和 Anthropic 工作，参与过 Gemini 和 Claude 的开发。

课程还邀请了多位学界和产业界讲者，主题落在 LLM 推理、编码 Agent、数学证明、自主系统和机器人等方向。公开课表中包括 Google DeepMind 的 Melvin Johnson、Denny Zhou 和 Thang Luong，Reflection AI 的 Misha Laskin，以及 Physical Intelligence 的 Danny Driess 等一众行业大佬！

从大模型讲起，首个教「自改进 Agent」的课

过去几年，大模型的进步主要靠更多数据、更大参数和更多训练算力。CS329A 关心的是另一个问题：模型已经训完之后，能不能通过搜索、验证、工具调用、环境反馈和强化学习，在任务中继续变强？

这里的「自改进」不是让 Agent 随意改自己的代码。CS329A课程更关心一个可操作的闭环：模型先生成多个候选答案，用验证器或环境反馈找出更好的结果，再把这些结果变成新的训练信号。它既可以发生在推理时，也可以发生在训练时。

课程从 LLM 自改进方法讲起，包括 Constitutional AI、验证器、测试时算力扩展、搜索与 LLM 的结合，以及通过强化学习扩展训练。后半程转向工具、代码、记忆、多模态交互、多步规划和 Agent 评估。

课程内容

CS329A 持续约 10 周，课程表共有 20 次课。

前半程从测试时算力扩展开始。模型一次生成的答案不够好，那就多采样几次，再用验证器筛选。数学题可以检查答案，代码可以运行测试，开放式任务却很少有现成标准。所以，课程会专门讲结果验证、过程验证和弱验证器。

接下来，Agent 开始调用搜索、运行代码、读取环境状态，并利用执行结果修正下一步。课程会讲到 ReAct、树搜索、多步规划和基于代码反馈的强化学习。

后半程进入训练时扩展。模型在搜索和验证过程中产生的高质量轨迹，可以被用来继续训练模型。这部分会读 STaR、DeepSeekMath 和 DAPO，也会讨论 AI Scientist、AlphaEvolve 与深度研究 Agent。

最后，课程把这套方法放到更长、更真实的任务中：编码 Agent 如何在代码库里工作，长时间任务如何管理记忆，怎样评估数小时甚至数天的 Agent 任务，以及这些方法如何用到多模态机器人上。

课程地址

课程主页：https://cs329a.stanford.edu/

从阅读材料、作业目标和研究项目看，CS329A 但这不是一门面向零基础读者的 Agent 产品课。

至少需要熟悉 Python 和 PyTorch，理解 Transformer、监督微调和基本的强化学习概念，并且能够阅读机器学习论文。如果还想完整复现课中方法，最好再补一些搜索、规划、分布式训练和模型评估的知识。

「自改进」这个词很大，CS329A 做的却是很具体的拆解。所以它适合当成 Agent 进阶课程。

一起“点赞”三连↓

跳转微信打开

一、Physical AI 的核心，不只是“看懂”，更要“行动”

想象一台家庭机器人接到任务：去厨房拿一只杯子，接水，再把水送到客厅。

在演示视频里，这件事可能只需要几十秒。机器人找到杯子、伸手抓取、打开水龙头，然后平稳地把水送到用户面前。看上去，它已经“学会了取水”。

但真实世界不会一直配合演示。杯子可能被放进另一个柜子，透明杯可能在灯光下难以识别，用户可能突然把手伸到机械臂前方，回客厅的路上也可能多出一片积水。

每遇到一种变化，机器人都必须重新决定：继续、等待、绕行、换一只杯子，还是立即停下？

这也是 Physical AI 与只在数字世界中生成文字或图像的 AI 最明显的差别之一：它的输出会进入物理世界，受到空间、时间、动力学和安全边界的共同约束。一个答案不仅要合理，还要来得及执行，并且不能造成危险。

因此，只问“任务成功率是多少”还不够。我们还需要知道：

• 它是根据眼前变化立即响应，还是会在行动前比较几种未来？

• 它判断的依据来自人工规则，还是从数据中学到的经验？

• 它能否在动作失去意义之前完成计算？

• 如果判断错误，谁拥有叫停动作的最终权力？

不同技术路线，本质上是在这些问题上作出了不同选择。

二、两个问题，划分出六种实现思路

算法名称经常让问题变得复杂。要看懂一个 Physical AI 系统，可以先暂时放下“强化学习”“世界模型”“大模型”等标签，只回答两个更基础的问题。

（一）它会直接反应，还是先比较几种未来？

• 反应式决策（Reactive Decision-Making，R）根据当前观测、历史状态或上游指令直接产生输出，不在这一次决策中利用“行动—后果”模型比较候选动作。

• 深思式决策（Deliberative Decision-Making，D）会在部署时预测、搜索或优化可能的行动结果，而且这些结果会实际改变当前选择。

判断关键不是计算用了多长时间，也不是一次输出多少步动作，而是系统有没有真正问：“如果采取不同动作，接下来分别会发生什么？”

反应式方法的决策路径通常更短，适合关节跟踪、保持平衡和紧急避障等需要快速更新动作的任务。深思式方法能够比较路径、抓取方式或失败后的替代方案，更适合处理长程目标和多步依赖。

二者不是“低级”与“高级”的关系，而是在不同时间尺度上解决不同问题。

（二）决定行为的知识从哪里来？

人工设计（Human-Designed，I）把知识写成规则、公式、物理模型、速度上限、碰撞约束或人工整定的控制参数。它的边界相对清楚，但现实中的例外很难全部写完。

学习得到（Learned，II）把行为知识编码在训练得到的参数里。机器人可以从示范、试错和大规模数据中学习人类难以逐项描述的技能，但也要面对数据覆盖、分布偏移和持续评估等问题。

人工与学习联合（Integrated，III）让人工知识和学习结果共同进入同一次不可拆分的决策计算。例如，用学习模型预测杯中的水如何晃动，同时用人工硬约束排除可能碰撞或倾倒的轨迹。

把“反应还是深思”与“知识来自哪里”交叉起来，就得到六种实现思路：

这张表分类的不是整台机器人，而是其中真正能够选择、修改或拒绝动作的决策组件。一台机器人通常包含多个这样的组件，因此也可能同时采用多种思路。

三、Physical AI 的六种主流实现思路

（一）规则与传统控制：根据当前状态快速反应（R-I）

第一种思路，是由工程师预先写出规则、公式和控制参数，系统再根据当前状态直接产生动作。

经过人工整定的比例—积分—微分控制器（PID）会根据当前误差修正输出；解析逆运动学根据机械臂末端想要到达的位置和朝向，直接计算各个关节应当转到的角度；安全监督器也可以在人体距离低于阈值时立即停止机械臂。

这类方法的优势很实际：决策路径短，响应时间容易控制，规则和边界也相对容易检查。它尤其适合关节跟踪、保持平衡、底层控制和紧急避障。

代价是工程师必须提前识别重要条件，并持续调整参数。当设备、任务或环境发生变化时，原有规则可能需要重新校准；规则越来越多时，还可能出现冲突。

核心交换：用人工设计和持续调参，换取快速、稳定和边界清楚的响应。

（二）端到端学习策略：从数据直接生成动作（R-II）

透明物体怎样抓、柔软衣物怎样折、拥挤环境中怎样绕开行人，这些技能往往包含大量难以逐项描述的细节。第二种思路是让机器人从示范、试错或大规模数据中学习“看到什么就怎样行动”的映射。

模仿学习从专家示范中学习动作，强化学习通过试错和奖励信号学习策略。扩散策略从含有噪声的动作方案出发，通过多轮去噪生成一段动作；π0 等视觉—语言—动作模型（VLA）则尝试连接图像、语言指令和机器人动作。

这类方法能够吸收人类难以准确描述的模式，减少手写行为映射的工作。但成本并没有消失，而是转移到了数据收集、失败情形覆盖和部署评估上。

如果训练数据中的红杯子总在桌子左侧，模型可能把颜色误当成位置线索。换一种桌布、照明或相机角度，原本有效的行为就可能失效，这就是分布偏移。

还要注意，直接生成动作不等于计算一定便宜。扩散策略需要多轮去噪，大型 VLA 也可能带来较高推理延迟。它们虽然没有在线搜索未来，仍可能超过某些控制任务允许的时间。

核心交换：用数据覆盖、算力和持续评估，换取处理复杂技能与开放变化的能力。

（三）学习补偿控制：让数据修正人工控制器（R-III）

人工模型清楚、稳定，但很难覆盖全部现实细节；学习模型能够拟合复杂变化，却不容易单独提供明确边界。第三种思路把二者放进同一次反应式计算。

例如，工程师先用人工公式计算机械臂的基础控制量，再让模型学习公式与真实结果之间的差值。这部分差值称为学习残差，它可以补偿摩擦、负载变化或设备老化造成的误差。最终动作由人工控制结构与学习补偿量共同决定。

与简单的前后串联不同，这里的人工知识和学习结果无法拆开理解为两个独立决策组件，它们共同构成一次输出。

这种方法可以保留传统控制结构，同时利用数据补足难以手写的细节。相应的代价是两部分会彼此影响，需要作为一个整体重新验证。

核心交换：用更复杂的联合设计和验证，换取传统控制的稳定性与学习补偿的适应性。

（四）模型驱动规划：先推演，再行动（D-I）

第四种思路是先建立人工模型，再搜索、预测或优化多种行动方案。

早期人工智能机器人 Shakey 会根据地图、物体状态和任务规则搜索行动步骤。系统需要处理“门必须先打开，机器人才能进入房间”这样的多步依赖，这类方法通常称为符号规划。

今天的模型预测控制（MPC）虽然工作在不同时间尺度上，却保留了相似思想：根据当前状态预测未来几步，优化一段动作，只执行眼前一步，然后获取新状态并再次计算。轨迹优化直接调整连续运动轨迹，任务与运动规划（TAMP）则同时处理“先做什么”和“机械臂怎样移动”。

规划的吸引力在于，机器人可以提前比较哪条路径更短、哪种抓法更稳定，以及某一步失败后是否还有替代方案。

但规划并不是免费的。机器人需要一个足够可信的模型；如果模型漏掉摩擦、遮挡或人的突然动作，系统可能依据错误世界认真地选出危险方案。同时，搜索必须赶在行动期限之前结束。

核心交换：用模型和计算成本，换取行动前比较多种未来的能力。

（五）世界模型在线规划：先学习世界如何变化，再临场选择（D-II）

学习得到的不一定只是动作策略，也可以是世界模型。可以把世界模型理解成机器人内部的一台任务相关“模拟器”：系统把当前状态和一个尚未执行的候选动作交给模型，模型再预测物体位置、碰撞风险或任务状态会如何变化。

机器人准备抓杯子时，可以分别模拟“从左侧抓”和“从右侧抓”。如果模型预测前者会碰到柜门、后者更容易抓稳，机器人便可以根据这些结果选择右侧抓取。

PlaNet、TD-MPC2 等方法会在部署时利用学习得到的模型评估候选动作。与直接复现训练数据中的动作相比，机器人因此可以临场比较新的行动组合。

这种方法同时继承了学习和规划的机会，也继承了二者的风险：模型必须在当前环境中预测得足够准确，搜索也必须及时完成。如果模型主要见过干燥地面，它可能低估湿滑地面上的制动距离，并据此选出看似安全、实际无法及时停下的路线。

世界模型也可能只在训练时使用。例如，DreamerV3 利用想象轨迹训练策略，但部署时由策略直接产生动作。训练过程预测过未来，不代表机器人每次行动前仍会利用世界模型比较候选动作。只有部署时的预测真正影响当前选择，才属于 D-II。

核心交换：用模型准确性和在线搜索成本，换取在新情境中临场组合行动的能力。

（六）学习模型与人工约束联合规划：同时利用经验与安全边界（D-III）

第六种思路让学习模型与人工知识共同参与一次规划计算。

例如，规划器可以用学习模型预测杯中的水会怎样晃动，同时规定任何候选轨迹都不得碰撞人体，也不得让杯子过度倾斜。这些任何方案都不能违反的条件称为硬约束。

另一种做法，是先用人工物理模型预测，再由学习残差修正模型与真实世界之间的偏差，最后在修正后的模型上执行 MPC 或轨迹优化。

这类系统既能利用数据补足难以手写的细节，也能保留人工规则规定的明确边界。但两部分会共同影响规划结果，不能分别验证后就假定整个系统可靠，而需要进行整体测试。

核心交换：用更高的集成与验证成本，换取学习适应性、未来比较能力和人工约束的结合。

四、六种思路没有高下，关键在于如何组合

六格地图不是能力排行榜。R 不代表低级，D 也不天然更加聪明；I、II、III 更不是技术升级顺序。

一台取水机器人既要决定先去哪个柜子，也要持续保持杯口水平。前一项需要考虑整个任务，后一项却必须快速修正手臂的细小偏差。让底层电机控制器在每次生成指令时重新规划整段任务，既无必要，也来不及；反过来，让只会修正当前误差的控制器负责整项任务，它又看不到多步行动之间的依赖。

现实系统因此很少只采用一种路线。更常见的架构是：

• 较慢的规划组件处理长程目标和多步选择；

• 学习策略持续产生局部动作；

• 底层控制器快速修正关节误差；

• 独立安全模块保留修改或拒绝动作的权力；

• 执行结果和中断状态返回上游，触发后续调整或重新规划。

所以，Physical AI 的工程重点通常不是从六种路线中选出唯一赢家，而是让它们在不同时间尺度上正确分工，并确保状态能够在组件之间可靠传递。

五、一台取水机器人，如何同时用到多种思路？

回到开头的取水任务。与其给整台机器人贴上一个标签，不如沿着动作生成和执行路径，看看多个决策组件如何接力。

（一）规划器决定去哪里找杯子

TAMP 规划器发现桌上没有杯子，于是比较去柜子、去洗碗机和询问用户三种方案。它用学习模型预测成功率，同时用“不得碰撞人体”“杯口不得过度倾斜”等人工约束排除危险方案。

两类知识共同参与同一次在线搜索，因此这个规划器属于 D-III。它最终选择去柜子，并把“打开柜门”作为子目标交给下游。

（二）学习策略生成打开柜门的动作

技能策略根据相机画面直接生成打开柜门的手臂动作。它主要从示范数据中学到这种映射，没有在每次输出前比较多种未来，因此属于 R-II。

（三）底层控制器实时修正机械臂

技能策略给出机械臂末端希望到达的位置和朝向，也就是目标姿态。底层控制器再把目标姿态转换成电机指令，并快速修正关节误差。

如果它使用人工整定的控制增益，而且不搜索不同动作的未来结果，就属于 R-I。

（四）安全监督器在危险时叫停

用户突然把手伸进柜子。安全监督器发现人与机械臂的距离低于人工阈值，于是立即中止动作。它同样属于 R-I，但拥有覆盖学习策略的权力。

这里需要注意：学习策略提出动作，独立安全模块在外部检查并拒绝动作，属于两个可以分别运行和验证的组件。系统虽然同时使用人工方法与学习方法，却不能因此把二者合并归入 R-III。

（五）中断信息返回上游，触发重新规划

机械臂停下并不等于问题已经解决。中断状态还必须返回技能策略和规划器，否则上游可能误以为柜门已经打开。

规划器收到真实状态后，重新比较等待、换杯和请求用户让开，最终选择等待。这才是深思式决策的关键：几个尚未发生的行动后果被实际比较，并改变了当前选择。

整条决策链可以简写为：

[规划器 D-III ⇉ 学习策略 R-II → 底层控制器 R-I]，安全监督器 R-I 保留最终否决权

摄像头、物体检测和状态估计会持续提供杯子位置、人体位置和机器人姿态。如果它们只报告状态，并不选择、修改或拒绝动作，就属于上游感知组件，不进入六格决策地图。

六、如何判断一个 Physical AI 系统采用了哪种思路？

真正可靠的方法，不是根据算法名称猜测，而是沿着动作生成和执行路径逐层追踪。

（一）三步定位决策组件

1. 找到真正改变行为的组件。只有能够选择、修改或拒绝动作的组件才是分类对象。只提供图像、位置或地图的模块属于上游信息来源。

2. 检查部署时是否比较行动后果。如果候选动作的预测结果会影响这一次选择，就属于 D；否则属于 R。

3. 判断关键知识来自哪里。查看决定输出的规则、模型或参数主要来自人工设计、训练数据，还是二者在同一次计算中不可分割地联合。

只要不同组件之间存在清楚接口，能够分别运行或验证，就应该拆开分类，不要急着给整台机器人贴上一个标签。

（二）三个最容易出现的判断误区

误区一：算得久、输出长，就等于会规划未来。

扩散策略需要多轮去噪，语言模型也可能逐词生成很长的计划。这些现象都不能证明系统在行动前比较了多种未来。判断标准仍然是：不同动作的预测后果是否真正改变了当前选择。

误区二：训练时预测过未来，部署时就仍在规划。

世界模型可能只用于训练策略。部署后如果动作仍由策略直接生成，世界模型的预测没有进入当前选择，那么执行过程依然属于 R。

误区三：系统同时使用人工方法和学习方法，就属于联合路线。

关键在于两类知识是否共同进入同一次不可拆分的计算。独立安全滤波器在外部检查学习策略提出的动作，仍然是两个组件，而不是自动变成 III。

写在最后：真正重要的是，谁拥有下一步的决定权

判断一个 Physical AI 系统，不必先问它是不是“大模型”，也不要被“规划”“推理”或“世界模型”等名称带着走。

先找到究竟是谁在决定下一步，再看它有没有在行动前比较不同动作的后果，判断依据来自人工知识还是训练数据，最后检查各个组件怎样传递状态，以及谁拥有最终控制权。

六格地图不能直接证明系统安全，但它可以把延迟测试、失效分析和安全验证落到具体组件与接口上。当环境变化、模型出错或接口失效时，我们能够知道问题可能从哪里出现，又还有谁可以让机器人停下来。

Physical AI 的关键，从来不只是模型能够生成什么动作，而是整套系统如何在真实世界中及时、可靠并且安全地决定下一步。

一起“点赞”三连↓

跳转微信打开

用 Codex 写代码，最明显的感受就是：好用，但烧钱。

很多人以为，Codex 一次任务只调用一个模型。其实在一个思维链里，主对话、代码 Review、子 Agent 和上下文压缩承担的是不同工作。

很多伙伴不知道，这些步骤里面的模型可以改的！

配置一次，以后不需要每个任务都手动安排。Codex 会按照这套默认分工运行，在后台一点点把成本降下来。

这篇文章就带你把它配好。

一、先看懂 Codex 背后的模型调用链

在传统理解里，我们给 Codex 一个需求，它调用模型，写完代码，任务结束。

实际使用时，可以把这条工作链理解成几个不同环节：

你提出任务
    ↓
主模型：理解需求、规划任务、协调执行
    ↓
子 Agent：写代码、改文件、跑测试
    ↓
Review 模型：检查代码、发现问题
    ↓
Compact：上下文过长时进行压缩

这些工作对模型能力的要求并不相同。

主模型更像整个任务的大脑。它要理解目标、拆分任务、选择实现方案，还要判断下一步该做什么。这里一旦判断错了，后面的执行很容易跟着跑偏，所以主模型不能省得太狠。

子 Agent 主要负责具体执行，例如修改某个文件、补一段代码、运行测试。任务通常已经拆得比较清楚，不一定需要和主模型相同的推理能力。

Review 的工作边界也比较明确：检查代码、寻找问题、给出修改建议。大多数情况下，可以使用便宜一档的模型。

所以，这套配置的重点不是单纯换一个低价模型：

好模型负责想清楚，便宜模型负责把事情做完。

目前我们主要关心四个环节，其中前三个可以通过配置进行分工。

Compact 是一个例外。它负责在上下文过长时压缩内容，目前不能单独给它指定模型，因此这部分消耗仍然会跟随主模型。知道这个限制就好，不影响我们先把调用量更大的执行和审查环节降下来。

二、Codex 省钱保姆教程

第一步：配置主模型和 Review

打开 Codex 配置文件。

macOS 和 Linux：

~/.codex/config.toml

Windows：

C:\Users\<用户名>\.codex\config.toml

加入：

model = "gpt-5.6-sol"
model_reasoning_effort = "high"
review_model = "gpt-5.6-luna"

主模型负责规划，所以使用 Sol；Review 的任务比较明确，交给 Luna 即可。

第二步：配置子 Agent

在下面的目录中新建 worker.toml：

~/.codex/agents/worker.toml

写入：

model = "gpt-5.6-luna"
model_reasoning_effort = "medium"

子 Agent 负责写代码、改文件和跑测试，调用量通常比较大。换成 Luna 后，这部分成本更容易降下来。

子 Agent 会继承当前会话的 Provider，所以这里填写的模型必须是同一家 Provider 支持的模型。

配完就结束了。

以后仍然像平时一样使用 Codex，不用每次重新指定谁规划、谁执行。

国产模型也能这样配

如果不使用 OpenAI 官方模型，也可以接入支持 Responses API 的第三方 Provider。

例如火山方舟 Agent Plan：

model = "<套餐内的强模型>"
review_model = "<套餐内的轻量模型>"
model_provider = "volcengine-agent-plan"
model_supports_reasoning_summaries = true


[model_providers.volcengine-agent-plan]
name = "volcengine-agent-plan"
base_url = "https://ark.cn-beijing.volces.com/api/plan/v3"
env_key = "ARK_API_KEY"
wire_api = "responses"

然后在 worker.toml 中填入套餐内的轻量模型：

model = "<套餐内的轻量模型>"
model_reasoning_effort = "medium"

分工逻辑不变：强模型规划，便宜模型执行和审查。

需要注意，Agent Plan 使用的是专属 API Key，不是普通的火山方舟 API Key。这部分目前基于接入文档整理，具体模型名称以套餐内实际可用列表为准。

一起“点赞”三连↓

跳转微信打开

现在，大家已经在用很多 Claude Code 一起 Coding。

然后，Token 开始蹭蹭往上涨。

谁改了接口，群里说一遍；前端、后端、测试分别确认；协调 Agent 再汇总一次，转给所有人。

好家伙，活还没干多少，进度倒是同步了三轮。

最近伦敦大学学院团队用 Claude Code 做了 1902 次实验，专门算了这笔账。在部分由 8 个 Agent 参与、消息密集的任务中，把重复沟通换成共享文件，输出 Token 少了约 42%。

https://arxiv.org/abs/2608.16801

对，你没看错。

省 Token 的办法，不是再训练一个更聪明的协调 Agent，也不是上复杂的调度框架。

就是建个文件。

一、Agent 越能聊，为什么反而越贵

最直接的浪费，是同一条信息被说了很多遍。

比如一个 Agent 修改接口，它需要通知前端、后端和测试。三方收到后，又各自回复确认。Agent 数量一多，点对点消息很快就铺开了。

有些任务其实不需要这么多人旁听。

在“搜集资料—分析—执行—验收”这类流程里，搜集 Agent 把结果交给分析 Agent 就够了。它没必要继续跟着执行和验收，更不用反复接收后续进度。

协调 Agent 也容易变成传话筒。

它收进度、转消息，看起来一直在忙，实际上只是给团队多加了一层汇报。论文实验中，专门设置一个协调 Agent，并没有稳定提高成功率。

问题慢慢清楚了：

要反复使用的信息，被反复发送；只需要交接一次的结果，又发给了太多人。

二、一份共享文件，Token直降 42%

论文验证的办法很直接：把多个 Agent 都会用到的信息，集中放进共享文件。

放到实际项目里，可以在根目录建一份 AGENT_STATUS.md。

任务目标、验收标准、Agent 分工、当前进度、已经确认的结论和阻塞问题，都写在这里。每个 Agent 开工前先读最新状态，做完自己的部分再更新。

这样一来，消息不再负责搬运整段背景，只需要告诉别人“哪里发生了变化”。

比如接口更新了，先改共享状态，再通知受影响的前端和测试 Agent。其他人用不到，就不用跟着收消息。

说白了，这份文件就是 Agent 团队的办公室白板。

大家都要看的内容写在白板上。真有急事，再单独喊人。

约 42%：这一降幅来自论文中的特定实验，不能直接外推到所有项目。

42% 的数字很亮眼，但别把它当成固定折扣。

如果两个 Agent 只做一次交接，专门建文件、读文件、更新文件，反而可能更贵。真正影响收益的，是公共信息原本被重复了多少次。

三、不是所有消息，都该塞进共享文件

共享文件好用，也不能什么都往里扔。

只影响一个 Agent，就点对点发送；影响全员，再广播一次。

至于协调 Agent，也没必要接收和转发所有消息。

它真正该做的是拆任务、定输入输出、限制修改范围、检查结果。只有发生冲突、偏离目标或者验收失败时，再出来处理。

能由上下游直接完成的交接，就别再绕一次。

写在最后：哪些情况不适用

如果任务本来已经通过文件完成交付，就不用再加一份状态文件。

如果只有两个 Agent，发一条消息能说清楚，也没必要搭新的流程。

还有一种情况更麻烦：项目变化很快，状态却没人更新。

其他 Agent 读到旧内容，干得越快，返工越多。所谓“唯一事实来源”，最后会变成唯一的过期信息来源。

判断要不要共享状态，其实只需要问一句：

会，就集中保存；不会，直接交给需要它的 Agent。

Claude Code 跨会话通信解决了“Agent 能不能聊”。接下来更现实的问题是：怎么让它们少说重复的话。

毕竟 Token 应该花在干活上，不是花在开会。

一起“点赞”三连↓

跳转微信打开

就在刚刚，DeepSeek 第一个多模态视觉理解模型来了！！

最新官方 API 文档显示，一款名为 deepseek-v4-flash-vision-exp 的实验性模型已经上线。

和此前只能处理文本的 V4 系列不同，新模型正式加入图片理解能力。现在，它不仅能读文字、写代码、调用工具，还能直接查看图片、识别截图中的文字、分析图表，并围绕视觉信息完成后续任务。

一、DeepSeek，终于补上了“眼睛”

从命名来看，deepseek-v4-flash-vision-exp 基于 V4 Flash，后缀中的 vision-exp 表明它目前仍是一款实验性视觉模型。

新模型支持 JPEG、PNG、GIF 和 WebP 四种图片格式。开发者可以直接提交 Base64 编码图片、提供公开访问的图片 URL，或者通过 Files API 上传并引用图片。

它同时兼容 OpenAI Chat Completions、Responses API 与 Anthropic API 格式。

换句话说，现有 Agent 和开发工具不必重新设计整套接口。修改模型名称和图片内容块，就能接入 DeepSeek 的视觉能力。

二、一次最多看 600 张图

这次上线的不只是简单的“看图问答”。

官方文档显示，新模型单次请求最多可以输入 600 张图片，图片最长边最高支持 8192 像素。

• Base64 或外部 URL：单张图片最大 32 MiB

• Files API：单张图片最大 64 MiB

• 包含 file_id 图片时：单次请求图片总量最高 200 MiB

模型还提供不同的图片细节等级。low 模式会将图片缩放至 512×512，速度更快、Token 消耗更低；original 模式保留原图；auto 当前等同于原图模式。

每张图片进入模型前都会按尺寸换算成 Token，单张消耗最高为 384 Token。因此，即使输入超高分辨率图片，成本也不会无限增长。

这让它更适合批量截图分析、长文档检查、数据图表理解，以及需要持续观察界面的视觉 Agent。

三、多模态 Agent，开始逼近 Opus

据官方发布，新模型在多项 Agent Benchmark 上的成绩如下：

相比原来的 DeepSeek V4 Flash，新模型在依赖视觉理解的 Agent 任务上提升明显，多模态 Agent 能力已接近 Claude Opus 4.8。该比较尚未出现在 DeepSeek 当前的官方模型文档中，仍需等待更完整的技术说明与第三方测试。

真正值得关注的不是某一个单项分数，而是 DeepSeek 正在把视觉理解与原有的推理、编程、工具调用能力连接起来。

过去的 DeepSeek Agent 主要依靠文本、网页源码和结构化数据理解环境。现在，它可以直接读取软件界面、错误截图、数据图表和图文混排文档，再决定下一步调用什么工具。

四、价格与 V4 Flash 相同

还是梁圣，价格依旧超级低价！

deepseek-v4-flash-vision-exp 的调用价格与 V4 Flash 保持一致，并采用高峰、空闲两档计费。高峰时段为北京时间 9:00—12:00、14:00—18:00，其余时间为空闲时段。

图片会按尺寸转换为 Token，与文本 Token 一并计费。新模型的并发限制为 2500，与 V4 Flash 相同。

如果后续正式版继续维持这一价格，DeepSeek 很可能会再次压低多模态 Agent 的使用门槛！

写在最后：现在已经可以调用

大家目前已经可以通过 DeepSeek API 访问新模型了！

原有 API 地址保持不变：

https://api.deepseek.com

只需要把模型名称修改为：

deepseek-v4-flash-vision-exp

如果使用 DeepSeek Harness，则需升级至 0.1.1-rc.1 或更高版本。

需要注意，模型名称中的 exp 说明它仍处于实验阶段，能力表现、接口限制和模型版本后续都可能调整。目前也只有这一视觉模型能够接受图片；将图片传给普通的 V4 Flash 或 V4 Pro，会直接返回错误。

此外，视觉版暂不支持 FIM 补全，图片在 Chat Completions 与 Anthropic Messages 接口中只能出现在 user 消息里。

从 V4 Flash 到 V4 Pro，再到今天的 V4 Flash Vision，DeepSeek V4 的产品结构正在变得更加完整：

• Flash：速度和低成本

• Pro：复杂推理与高规格 Agent

• Vision：图像、截图与界面理解

DeepSeek 的多模态拼图，终于开始补上了！

一起“点赞”三连↓

跳转微信打开

*部分Google技术仅适用于出海场景。

Datawhale甘元琦与Google全球开发者生态总监 David McLaughlin 访谈过程

当 Agent 可以连续工作十二小时、三天，开发者的价值是什么？

在 AI 快速迭代的今天，很多人都有一种共同的焦虑：

新模型几乎每周都在发布，新工具刚学会就可能被替代。我们到底应该学哪项技术？哪些能力才不会过时？

在 Google 开发者大会期间，Datawhale 与 Google 全球开发者生态总监David McLaughlin进行了一场深度对谈。

我们聊到了中国开发者出海、Agentic Development 的下一步、AI 时代开发者能力的变化，以及一个越来越重要的问题：

当写代码的门槛不断降低，我们应该如何重新理解 Developer 和 Builder？

David 给出的答案很直接：

与其问“我应该学习什么技能”，不如先问“我到底想解决什么问题”。

以下是本次访谈的核心内容。

一、Google 如何帮助全球开发者成长？

在正式对谈开始前，我们先向 David 介绍了 Datawhale。

作为一个 AI 开源学习社区，Datawhale 目前拥有超过 200 万学习者，每年在全国举办超过 300 场活动，也长期与 GDG Shanghai、GDG Nanjing 等本地开发者社区保持合作。

对于很多学习者来说，Datawhale 是他们进入 AI 世界的第一扇门。

而 David 所负责的 Google 开发者生态团队，也在做一件相似的事：帮助更多开发者、Builder 和创业者，使用 Google 的技术进行创造。

David 介绍，Google 开发者生态团队目前主要通过几类项目支持全球开发者。

首先是大家熟悉的 Google Developer Groups，也就是 GDG。

GDG 在世界各地举办 Meetup、技术分享和 Workshop。在中国，大约有 40 个 GDG 社区，覆盖约 40 万名成员。这些社区让开发者能够定期交流、相互学习，在实践中提升技术能力，也帮助更多开发者探索如何让自己的产品走向全球。

另一项重要计划是 Google Developer Experts，也就是 GDE。

GDE 是经过严格筛选的技术专家，他们来自 Android、Cloud、AI 等不同领域，会持续制作技术内容、设计 Workshop、进行公开分享，并为开发者社区提供导师支持。这些项目的价值，不只是帮助开发者学习某一项工具，更在于让他们找到同行、获得反馈，并将自己的经验继续分享给更多人。技术不断更新，但开发者的成长从来不是孤立发生的，而是在交流、实践与协作中逐步完成。

二、中国开发者最突出的优势，是速度和创新

当被问到如何看待中国开发者时，David 提到了三个关键词：

开发速度、创新水平，以及对不同商业模式的探索。

在他看来，中国公司和中国开发者展现出的创新速度，在全球范围内都非常突出。但当中国团队希望把 AI 产品推向全球市场时，也会遇到新的挑战。

不同地区的监管政策、商业环境、数据规则和云服务生态并不相同。一个在中国市场表现很好的产品，进入欧洲或其他地区时，可能需要重新理解当地的数据隐私、数据存储和数据主权规则。

即使产品本身足够优秀，如果缺少真正了解当地市场的人，团队也很难准确判断该如何落地。例如，一家希望进入欧洲市场的公司，可能会获得熟悉欧洲数据隐私法规和基础设施环境的当地导师支持。

相比单纯提供技术工具，本地经验的连接，往往能帮助创业团队更快调整策略，减少进入新市场时的试错成本。

三、Agent 的价值，不只是让原有流程更快

谈到开发者的下一个机会时，David 提到了 Agentic Development。在他看来，我们目前仍处于智能体开发非常早期的阶段。

现阶段，很多企业正在尝试用 Agent 优化现有业务流程。

比如：

“能不能让 Agent 一直处理这项工作，让流程变快？”

“能不能把原本需要几小时完成的任务，再缩短一些？”

但 David 认为，这只是最容易想到的一层。

真正值得思考的问题是：

当 Agent 可以 24 小时持续工作时，哪些原有流程已经不再需要存在？

以及：当 Agent 可以长时间自主运行时，我们能不能重新设计整个业务？

他用了一个非常形象的比喻：

开发者不应该只想着造一辆跑得更快的马车，而应该开始思考：如果我们已经能够造汽车了，那意味着什么？

AI 带来的变化，不应该只是让旧流程变快。更大的机会，可能来自对产品、组织方式和商业模式的重新设计。

四、不要只看今天的模型，要看三个月、六个月之后

David 还建议开发者，不要只围绕模型今天的能力设计产品。

更重要的是思考：三个月后的模型会是什么样？六个月后又会发展到哪里？

一个已经非常明显的趋势是，Agent 能够自主运行的时间会越来越长。

今天，它可能只能独立完成一个相对简单的任务；未来，它可能持续运行六小时、十二小时、三天，甚至一整周。

当 Agent 可以长时间自主运行时，开发者面临的核心问题也会发生变化：

我们有没有把问题定义清楚？

什么样的结果才算成功？

如何判断 Agent 是否真的完成了任务？

如果目标本身不清晰，那么 Agent 工作得越久，偏离方向的风险也可能越高。

因此，AI 时代的开发者不仅需要会调用模型，更需要具备定义问题、设定边界和评估结果的能力。

五、AI 降低编程门槛后，工程思维反而更重要

随着 AI Coding 工具不断成熟，一些过去非常重要的开发技能，价值可能会逐渐下降。

例如，精确记住某种编程语言的语法，或者熟练掌握某个特定 API 的所有细节。David 将它类比为汇编语言的发展。

在过去，精通汇编是一项非常有价值的能力。但随着编译器和高级编程语言出现，这种具体技能的重要性也发生了变化。

不过，这并不意味着开发者不再重要。恰恰相反，基础的工程思维会变得更加重要。

开发者需要能够：

理解一个问题真正的需求；

把复杂问题拆解成更小的任务；

将不同任务分配给不同 Agent；

判断各个环节是否达到了预期结果。

除此之外，开发者还需要学会设计 Evaluation Harness，也就是评估机制。

简单来说，就是通过一组明确的测试和标准，判断 Agent 是否真的完成了我们希望它完成的事情。

David 表示，这并不是一项简单的能力。它需要经验、判断力和大量思考。你必须能够清楚地说：这就是我们要解决的问题，这就是成功的标准。

六、理解人，依然是不会过时的能力

技术在变化，人与计算机交互的方式也在变化。

今天，我们主要通过键盘、鼠标和触控屏与计算机交流；未来，语音、增强现实，甚至更多新的交互方式，可能会逐渐普及。

但 David 认为，人类本身并没有发生根本变化。人仍然拥有自己的认知优势和局限。

因此，理解人如何使用产品、如何理解信息、如何做出决策，依然是开发者非常重要的能力。

技术形态会变化，但理解人的能力不会过时。

七、未来，每个开发者都可能是一名 Manager

本次对谈中，David 提到了一个很有意思的判断：

未来，每一位 Developer、每一位 Builder，都需要开始把自己看作一名 Manager。

过去，开发者可能习惯独自工作，或者在一个小团队中与其他人协作。但在 Agent 时代，一个开发者可能同时管理多个 Agent。

例如：六个 Agent 在处理一个问题；三个 Agent 在处理另一个问题；还有十个 Agent 在执行其他任务。

这时，开发者所面对的问题，会越来越像一个团队管理者所面对的问题：

Agent 之间能否顺畅沟通？它们是否记录了自己的工作进度？

它们的优先级是否正确？它们是否在重复工作，或者互相干扰？

因此，未来的开发者不仅需要懂技术，也需要懂得如何协调、分工和管理一支 Agent 团队。过去很多开发者不需要具备这样的管理能力，但它可能会成为下一阶段的重要竞争力。

八、当专业知识与 AI 结合，几乎每个人都可以成为 Builder

随着自然语言和 AI 工具的发展，越来越多没有计算机科学背景的人，也开始构建自己的 AI 应用。

Developer 和 Builder 之间的边界，正在逐渐变得模糊。

David 用电子表格的发展做了一个类比。

几十年前，如果一个人能够构建一个复杂系统，处理大量数据并进行复杂计算，他可能会被认为是一名专家级程序员；但后来，很多类似的事情可以通过 Spreadsheet 完成。使用电子表格并不要求一个人必须是程序员。真正懂金融、会计、教育或政策的人，也可以借助工具解决自己领域里的问题。

今天，我们可能正处在一个相似的阶段。

越来越多 Builder 并不具备传统的计算机科学背景，但他们对自己的领域有很深的理解。AI 和 Agentic 工具，正在赋予他们构建应用、设计流程和处理数据的能力。

David 对 Builder 的定义是：任何依靠 AI 完成自己工作的人，都可以被称为 Builder。

从这个意义上来说，未来几乎每个人都有可能成为 Builder。一个人可能为自己的生活构建工具，可能为一家非营利组织解决问题，也可能为自己的公司设计新的业务流程。未来，AI 工具可能会像今天的电子邮件和电子表格一样，成为日常工作的一部分。

九、如果回到生成式 AI 爆发前，你会告诉自己什么？

我们向 David 提出了一个来自 Datawhale 社区的问题：

如果可以回到生成式 AI 爆发前夕，你最想告诉当时的自己什么？

David 他最想告诉当时的自己：技术发展的速度，会比你想象得快得多。

在生成式 AI 发展的早期，包括 David 在内的很多人，都曾经怀疑模型能力是否真的会沿着指数曲线持续增长。人们可能会认为，真正有意思的能力还需要五年、十年，甚至十五年才能出现。

但现实的发展速度远远超过了当时的预期。如今，前沿模型已经能够在越来越长的时间跨度内运行，可以自主处理更多任务，也开始展现出协作和自我修正的能力。一些原本被认为还要五到十年才能实现的能力，可能在未来一两年内就会出现。

因此，真正值得思考的问题是：

我们今天应该如何设计工具、公司和流程，才能提前适应这样的未来？

十、技术变化这么快，我们到底应该学什么？

这是很多 AI 学习者最关心的问题。新模型和新产品几乎每周都在出现。

我们到底应该深入哪项技术？学习哪种工具？选择哪个方向？

David 没有直接给出一个技术名称，而是把问题重新抛了回来：有没有一个你真正想解决的问题？

在他看来，AI 模型最重要的价值之一，是放大人类的速度、创造力和创新能力。但前提是，你必须先找到一个值得解决的问题。它可以来自你的生活，也可以来自你的工作。有哪些问题一直困扰着你？有哪些问题真正让你感兴趣？

然后再问自己：借助 AI，我现在能不能用一种两年前、五年前做不到的方式解决它？

十一、与其问“该学什么”，不如先问“想解决什么”

David 分享了一个自己的例子：他和妻子都很喜欢拍照，长期积累了几十万张照片。他一直想整理和筛选这些照片，但因为整个过程太麻烦，迟迟没有真正开始。

现在，借助 AI Agent，他只用了几个小时，就构建了几个能够分类、评估和筛选照片的 Agent。

这个案例并不会改变世界，但它说明了一件事：AI 的价值，可以从一个非常具体的问题开始。照片整理可以用 Agent 解决，商业问题，以及更多复杂问题，同样可以尝试用新的方式解决。

所以，David 建议大家重新思考自己的学习路径：与其问“我应该学习什么技能”，不如问“我到底想解决什么问题”。

当你真正开始解决问题时，自然会学会实现目标所需要的技能。

十二、给年轻 AI 学习者的建议：尽可能多地去 Build

访谈的最后，我们请 David 给 Datawhale 社区里的年轻学习者一条建议：

未来十二个月，最值得做的一件事是什么？

他的回答是：

尽可能多地去 Build。抽象知识当然重要，阅读和学习也依然有价值。但只有当知识被用于解决一个真实问题时，它才会真正与现实发生连接。

这个问题可以很小，也可以很大。重要的是，先开始动手。选择一个自己真正想解决的问题，尝试使用 Agent 去完成它。在这个过程中，你会自然学会问题拆解、工具使用、结果评估、产品设计，以及更多原本不知道自己需要掌握的能力。

写在最后：从知识的旁观者，成为真正的 Builder

对 Datawhale 来说，我们也希望未来能够将更多前沿技术转化成开放学习项目。让学习者不仅仅是读到一个新的技术概念，或者听说某个最新模型，而是能够真正动手使用技术、解决问题，并在实践中提升工程、产品和管理能力。

这或许也是开源学习社区存在的意义：

让更多人从知识的旁观者，成为真正的 Builder。

当 AI 工具逐渐成为像电子邮件和电子表格一样普遍的基础工具，“谁是开发者”或许不再是最重要的问题。真正重要的是：你看到了什么问题？你愿意为它做些什么？

在 AI 快速变化的时代，与其追赶每一个新模型，不如先找到一个值得长期解决的问题。

然后，开始 Build。

David本人在X上回应并夸赞了我们的访谈

一起“点赞”三连↓

跳转微信打开

跳转微信打开

Datawhale全程支持。

Datawhale面向全国筛选优秀的FDE团队，为班级提供全程支持。

（有推荐名额的有：上海虹口区、杭州西湖区、南京建邺区、上海市隐形冠军企业促进中心、上海交通大学安泰经管学院、杭州电子科技大学校友办、河西中央科创区、杭州云谷中心、南京阿里中心、潮新闻、有才信息）

阅读原文报名⬇️

阅读原文

跳转微信打开

前几天，我们给大家带来了很多教程：1. DeepSeek Harness保姆安装教程来了！2. DeepSeek Harness 插件教程来了！3. DeepSeek Harness桌面版和CLI来了！

今天我们讲点硬核的，带大家看看 DeepSeek Harness的核心架构 Cordis。

它的核心理念是一切皆插件。模型适配器、工具注册表、会话日志、agent loop 本身，每一部分都是插件，都可以在运行时替换。换一个模型提供方不用改源码，换一个沙箱后端不用重启，换 agent loop 本身也不用动框架。

这种"任意环节可替换"的设计，是 DSH 和传统 Agent 框架最大的区别。下面分三层拆开：先看整个项目怎么组装，再看插件系统怎么运转，最后看插件动态能力的三个关键机制。

一、DeepSeek Harness 是怎么组装出来的？

DSH 不是一个装好了就定型的应用。启动时按顺序叠加各层配置，最终在内存里形成一套完整的插件组合开始运行。

底层是 Cordis 微内核。 Cordis 是一个专门管插件的框架，只管一件事：插件什么时候加载、什么时候卸载、彼此怎么协作。它最初由一位叫 Shigma 的开发者为一个聊天机器人框架 Koishi 编写，2022 年独立开源。DeepSeek 把 Shigma 和 Cordis 一起雇了，把整套源码并进了自己的仓库。产品的每一部分都是 Cordis 插件，连驱动 Agent 运转的主循环本身也是。

中间是三层组装机制。 这三层解决的是"这套插件组合怎么搭起来"的问题。

• Profile 是一份存在本地的组装方案，列出自己要叠放哪些组合包，也存用户自己写的配置补丁。

• Bundle 是组合包，把一组插件和它们的配置打包分发。装一个组合包，就等于一次装好一组配套插件。

• Patch 是补丁，按名字定位到某个具体插件，替换它的配置。

三层按顺序叠加：先装各个组合包，再打 profile 的补丁，再打本地的补丁，最后还能在启动命令里临时加一层补丁。每一层都能覆盖上一层的结果。

dsh-base 是每个 profile 必装的第一层组合包，装上它就有了模型适配器、工具、数据持久化、安全策略、遥测这些基础能力。后续的组合包和用户自己的补丁按名字覆盖它装好的插件。

顶层是四种运行模式。 Standard、Code、Minimal、Creator 是同一套插件的不同组装。Standard 功能最全，Code 专门面向编程，Minimal 只留 Shell 和文件编辑两个工具，Creator 开放给想做实验的人。切换模式就是换一套插件组合，不改任何代码。

这三层从底到顶：Cordis 管单个插件的加载和卸载，三层组装管整套组合怎么搭，四种模式管最终跑哪套组合。整个项目就是通过这套流程组装出来的一套插件组合。

二、一切皆插件：先看懂 Cordis 的核心词汇表

插件是 DSH 的基本单元。要理解插件怎么工作，先认识五个核心概念。不用记名字，理解它们各自解决什么问题就行。

插件本身有三种写法。 写一个简单的功能，用一个函数就行；写一个要被别人调用的能力，用一个类；两种都不想用，还可以用一个对象。三种写法地位平等，加载和卸载走同一条路。

// 函数写法：最简单，适合注册几个监听器
export const name = 'greeter'
export function apply(ctx: Context) { /* ... */ }
// 类的写法：适合提供给别人调用的能力
export class GreeterService extends Service {
  constructor(ctx: Context) { super(ctx, 'greeter') }
}

Context 是存放各种能力的地方。 每个能力有一个固定的名字，比如 ctx.tools 是工具、ctx.llm 是模型、ctx.sessions 是会话。别的插件通过名字来取用能力，不关心这个能力具体是谁写的、跑在本地还是远程。某个能力可以随时换成另一个实现，取用它的插件不用改。这是整个系统能"任意替换"的基础。

Service 是一种可以被别人取用的能力。 用类写一个 Service，它会自动注册进去；插件卸载时，它自动注销。

Fiber 是每个插件的生命周期记录。 一个插件从诞生到消失，经历六个阶段：排队等待依赖、正在启动、正常运行、正在卸载、完全消失，中间还可能启动失败。这条记录就是 Fiber。它是动态加载的核心。

inject 是插件的依赖声明。 插件开工前先声明自己需要哪些能力，框架会等这些能力都就位了才让它启动。启动顺序由依赖关系决定，不由写的先后顺序决定。

五个概念之外，插件之间不直接互相调用，全靠事件总线通信。一个插件发出通知，谁在监听谁响应，发通知的插件不用知道有谁在听。事件有五种分发方式：

最后一种 waterfall 是实现拦截的模式。每个监听者拿到一个"继续往下传"的开关，调用它就把工作交给下一个监听者，不调用就直接拦下。DSH 的工具执行流水线就是四段 waterfall 串起来的。

这五个概念加事件总线，构成了插件系统的基础。下面展开三个让"动态"变得可靠的关键机制。

Fiber、inject、effect：插件动态能力的三个关键机制

Fiber：让插件的加载与卸载都有迹可循

每个插件实例都有一条 Fiber 记录它的状态，在六个阶段之间转换：

排队等待 → 正在启动 → 正常运行 → 正在卸载 → 完全消失
                    ↘ 启动失败

流程是这样的。声明一个插件后，Cordis 检查它声明的依赖。依赖都满足了，就启动它，进入"正在启动"，跑完进"正常运行"。依赖没满足，它就一直在"排队等待"，不报错，静默等着。

卸载反过来走：正常运行 → 正在卸载（执行清理）→ 完全消失。

"排队等待"这个状态最容易被误判成"插件坏了"。一个插件声明需要某个能力，但那个能力没装上，它会一直排队，什么都不输出，进程也可能静默退出。想知道哪个插件在排队，遍历一遍所有插件的状态就行：

for (const runtime of ctx.registry.values()) {
  for (const fiber of runtime.fibers) {
    if (fiber.state === FiberState.PENDING) {
      console.log(`${fiber.name} 在排队等待，缺少某个依赖`)
    }
  }
}

热重载走的就是这条状态机。 开发时改了一个插件的代码保存，监视插件会发现文件变了，先把旧实例卸载到"完全消失"，再加载新代码走一遍"排队 → 启动 → 运行"。改配置文件 cordis.yml 本身也会触发更新，loader 按名字比对，只重新加载变化的部分。

inject：哪个插件先启动，依赖关系说了算

inject 不是启动时检查一次就完事，是持续跟踪的依赖关系。

加载顺序无关紧要。 插件 A 声明需要插件 B 提供的能力，Cordis 会让 A 排队，直到 B 就位。配置文件里 A 写在 B 前面还是后面，结果一样。把 B 彻底移除，A 就停在排队状态，不崩溃，也不会跑一半。决定插件何时启动的是依赖关系，不是文件里的先后顺序。

运行中仍在跟踪。 应用跑着的时候，如果某个能力消失了（提供它的插件被卸载或热替换），所有依赖它的插件也会跟着卸载；等这个能力恢复了，它们再重新加载。这能防止一个插件已经拿到某个能力的引用，那个能力却突然不见了。

这条机制的实际威力在一个场景里最明显。把默认的 Shell 执行插件换掉，挂上另一个提供方，所有用到 Shell 的插件都会自动重启、用上新的实现。不用改这些插件的一行代码，整条依赖链自动重排。

effect：插件卸载了，留下的副作用怎么办？

动态加载能跑不难，难的是卸载干净。插件启动时可能开了定时器、注册了监听器、挂载了子插件，卸载时这些都得清理干净。Cordis 的办法是 effect：插件通过框架 API 做的所有注册，都属于副作用，插件卸载时框架会自动撤销。

框架没直接管的资源（比如定时器、网络连接、文件监视），包进 ctx.effect() 里，同时返回一个清理函数：

export function apply(ctx: Context) {
  ctx.effect(() => {
    const timer = setInterval(() => console.log('tick'), 200)
    return () => {
      clearInterval(timer)      // 卸载时跑这个
      console.log('heartbeat cleaned up')
    }
  })
}

上面这段里，apply 里跑的是加载逻辑（开定时器），返回的函数是卸载逻辑（关定时器）。插件进入"正在卸载"时，框架自动调用这个清理函数。

几种常见操作天生就受 effect 管理，不用自己写清理逻辑：注册事件监听器，插件卸载时监听器自动移除；挂载子插件，父插件卸载时子插件跟着清理；往工具注册表里注册一个工具，插件卸载时工具自动注销。

清理函数的执行有条纪律：按注册的反序启动，但多个异步清理会并发跑。如果清理步骤有先后顺序要求，放进同一个清理函数里依次执行。

这三个机制合起来，动态加载才从"能用"变成"可靠"。Fiber 管生命周期，inject 管依赖，effect 管清理，三条各管一段，互不重叠。

一个真实的例子：工具运行时如何串起整条链路

DSH 里有个叫工具运行时的核心组件，上面讲的五个概念和三个机制在它身上全用上了。

它本身是一个能力类，会自动注册到系统里。它往系统里注册了 6 种事件，其中 4 种是 waterfall 拦截型、2 种是广播型。它声明自己依赖"提示词组装"这个能力，等这个能力就位了才启动，启动时立刻注册自己要用的提示词片段。

它提供一个"注册工具"的方法，调用方每注册一个工具，拿回一个对应的卸载函数。想动态卸载某个工具时，直接调用这个函数即可。这就是"动态"在最细粒度上的样子。

工具的执行是一条四段流水线，每一段都是一个 waterfall 拦截点：

审批插件可以在"执行前"这一环直接拦下，工具的实际逻辑从没运行；结果屏蔽插件可以在"执行后"把成功结果改写成错误提示，模型看到的已经是改写后的内容。

同一个工具运行时还能服务不同的 Agent。每个 Agent 能看到哪几个工具，是沿着一层层继承关系算出来的：先继承全局工具，再叠加自己所在的组合包层的工具，最后应用访问限制过滤。一个 Agent 被限制了只能用某几个工具，不影响另一个 Agent。

一个真实的 harness 服务长这样：它是个能力类，注册多种事件，声明依赖，用 effect 管所有注册，用分层让不同 Agent 看到不同工具集。前面讲的所有概念和机制，在它身上都能找到对应。

写在最后

DSH 的插件架构是目前开源 Agent 框架里设计最彻底的一个。不是"支持插件"，是整个产品就是插件的组合，任意环节都可以在运行时替换。

这种设计给个性化实现 Agent 留了很多可能。不同场景需要不同的工具集、不同的上下文策略、不同的执行流程，在 DSH 里都是换一套插件组合的事。模型可以换，工具可以换，连 agent loop 本身都可以换。呈现方式也可以换，Web UI、CLI、API 是不同的前端插件，挂在同一棵插件树上。

后面这个方向会出现很多玩法。自定义 agent preset、第三方插件生态、不同场景的插件组合模板，都是值得关注的方向。Harness 现在还是 v0.1 开发者预览版，接口随时可能变，但架构方向已经很清楚。

单看"任意环节都能在运行时替换"这一条，我们就非常看好它的架构设计。

一起“点赞”三连↓

跳转微信打开

DeepSeek Harness 发布后，大家都觉得网页版有点难受。

今天，我们挑选了目前Star数最高的桌面端、CLI版的两个社区开源项目做了保姆教程：

• DSH Desktop：真正的 macOS、Windows 桌面应用，目前约 8.5k Star。

• dsh-TUI：Claude Code 风格的终端界面，目前约 1.5k Star。

一、安装前：共同的环境要求

两个项目都要求 Node.js ^22.19 || >=24。我建议直接使用 Node 24。dsh-TUI 还需要 pnpm 10 或更高版本。

先检查：

node --version
pnpm --version

本文实测环境：

macOS Apple Silicon
Node.js v24.19.0
pnpm 11.19.0
@deepseek-ai/dsh 0.1.0-rc.6
@deepseek-harness-tui/dsh-tui 0.7.1

如果没有 pnpm：

corepack enable pnpmp
npm --version

下面的命令固定为本文实测版本，方便复现；想追最新版时，可以把版本号换成 @latest。

上半篇：安装桌面版 Web UI

https://github.com/anywhere-labs/deepseek-harness-desktop

这个项目把 Electron、Node.js 和 Harness 一起打进安装包。普通用户不用安装 Node，不用执行 npx，也不用自己管理 3080 端口。

目前官网提供：

• macOS：Apple Silicon 版本，要求 macOS 12 或更高

• Windows：x64 安装包

1. 下载桌面版

打开项目官网：

https://www.dshdesktop.cn

根据系统点击“下载 Mac 版”或者“下载 Windows 版”。

2. macOS 安装

打开下载好的 DMG，把 DSH Desktop 拖到 Applications 文件夹。

Windows 用户运行下载的 DSH-Desktop-2.0.0-x64-Setup-public.exe，按照安装向导完成即可。

本文下载的 macOS 2.0.0 安装包已通过系统签名和公证检查，随后从“应用程序”目录成功启动。

3. 第一次打开

首次启动时，DSH Desktop 会在本机准备默认 Profile，并自动启动 Harness 服务。第一次会比后续启动慢一点。

打开后的主界面是这样：

这时已经不需要再打开浏览器，也不需要保留一个终端窗口。应用会负责本地 Harness 服务的启动、停止和恢复。

4. 配置模型

点击左下角“设置”，进入模型设置，在 DeepSeek 卡片中填写 API Key。

没有 Key，可以先去 DeepSeek 开放平台 创建。

这里有个简单但很重要的习惯：配置 Key 时不要截图，也不要把 Key 写进会提交到 Git 的文件。

5. 添加工作区

回到主界面，点击工作区旁边的添加按钮，选择一个项目文件夹。

第一次建议新建一个空的 dsh-demo 文件夹，不要直接选择用户主目录、下载目录或者存放私人文件的目录。

新建会话时先保持：

• Agent：标准模式

• 权限：Workspace Write

• 模型：默认模型即可

第一条任务可以很简单：

阅读当前目录，告诉我这里有哪些文件。先不要修改任何内容。

能正常返回目录信息，桌面版就跑通了。

二、下半篇：安装 CLI 版 dsh-TUI

https://github.com/ccch1mneyyy/dsh-TUI

dsh-TUI 是社区维护的终端界面，使用体验更接近 Claude Code。它仍然调用官方 Harness 的 Agent、会话、工具、Skills、MCP 和权限服务。

CLI 第 1 步：安装官方命令和 dsh-TUI

在终端执行：

npm install -g \
  @deepseek-ai/dsh@0.1.0-rc.6 \
  @deepseek-harness-tui/dsh-tui@0.7.1

再确认 pnpm 不低于 10：

pnpm --version

CLI 第 2 步：进入项目并启动

第一次运行时，dsh-TUI 会自动创建一个名为 dsh-tui 的 Profile，并把插件装进去。网络慢时，这一步需要多等一会儿。

看到右上角的 dsh-TUI v0.7.1，以及底部的模型名称和当前工作区，就说明 CLI 界面已经加载完成。

CLI 第 3 步：配置 API Key

macOS 和 Linux 可以在启动 dsh-TUI 的同一个终端里设置：

export DEEPSEEK_API_KEY='你的 DeepSeek API Key'
dsh-tui

如果使用自定义兼容端点，再增加：

export DEEPSEEK_BASE_URL='https://你的网关地址/v1'

不要把 Key 写进会提交到 Git 的脚本或 .env。如果 TUI 已经启动，修改环境变量后需要退出并重新运行。

CLI 第 4 步：运行环境自检

进入 TUI 后输入：

/doctor

它会显示 Node 版本、系统架构、模型、工作目录、凭据状态和会话存储位置。

本文的隔离测试环境故意没有放真实 Key，所以截图里显示 API key: not configured。Node、工作区和会话存储均已正常加载。

CLI 第 5 步：发送第一条任务

先阅读当前项目，不要修改文件。告诉我启动入口、主要依赖和最值得先修的一个问题。

CLI 最常用的命令

/help          查看命令和快捷键
/doctor        检查环境
/model         切换模型
/preset        切换 Agent 预设
/permissions   查看权限说明
/new           新建会话
/resume        恢复历史会话
/compact       压缩长上下文
/cost          查看 token 用量
/mcp           查看 MCP 连接
/theme         切换主题

快捷键先记四个：

Enter          发送
Shift+Enter    换行
Ctrl+C         中断当前回合；空闲时连按两次退出
Ctrl+O         展开或收起思考、工具参数和输出

CLI 版适合谁

• 喜欢全键盘操作的人

• 经常在 VS Code 内置终端里写代码的人

• 需要通过 SSH 操作远程服务器的人

• 熟悉 Claude Code、希望快速上手的人

补充：真正的一行非交互 CLI

dsh-TUI 是交互式终端界面。如果你只想在脚本里执行一次任务，可以使用官方 Headless Profile：

dsh --profile headless "阅读当前项目，输出模块清单和三个风险点"

它会打印最终答案，然后退出。这个入口适合 CI、Shell 脚本和批处理，不建议第一次使用时从这里开始。

一起“点赞”三连↓

跳转微信打开

昨天智谱发布了最新大模型 GLM-5.3。

据官方所说，GLM-5.3在复杂软件工程、终端操作和更广泛的真实世界 Agent任务上均取得非常显著的进步。

我们当天就安排了实测。接入了 DeepSeek Harness，拉上 GPT-5.6-Sol 做了一场同题实测。

题目是生产级抠图 Web 应用。这里说的「生产级」，指具备账号体系、异常处理、可部署交付、有项目文档的完整应用，不是跑通了 demo 就算。九条验收标准从 A1 可运行、A2 账号体系一直到 A9 项目文档，覆盖了应用上线前该有的每一关。

国产模型加国产 Agent 框架，真写起一套完整应用，能不能和国际顶流掰掰手腕？

先说结论：能，而且差距比我们预想得小。

GLM-5.3 这个版本的整体完成度，和 GPT-5.6-Sol 的差距比我们想象的小。工程细节的完备度上，甚至更像一份真的要上线的交付物。

一、快速上手：把 GLM-5.3 接入 DeepSeek Harness

在看实测结果之前，先解决一个最实际的问题：怎么把 GLM-5.3 接进 DeepSeek Harness。

我们已经把环境准备、模型接入和测试环境搭建整理成了一份保姆级教程。步骤都写清楚了，新手照着做，15 分钟左右就能跑通。

完整 PRD：九条生产级验收标准

保姆教程：DeepSeek Harness保姆安装教程来了！

GLM-5.3 获取地址：https://www.bigmodel.cn/glm-coding

接好之后，就可以把自己的任务交给 GLM-5.3 跑起来。下面来看这次实测的结果。

二、GLM-5.3+DeepSeek Harness 生产级任务实测

真实开发里，难的是工程意识。上线稳不稳、异常处理全不全、边界条件有没有考虑到，这些东西 demo 测不出来，真正上线时才会暴露问题。

所以我们这次的实测让模型从零完成一款生产级抠图 Web 应用，覆盖算法、前后端、账号体系、异常处理、部署和项目文档。

它主要看两件事：核心功能能不能完成，以及代码是否具备继续交付的工程细节。抠图效果用 SAD、MSE、Grad 三项指标衡量，工程部分按九条标准验收。

实测一：前端设计与风格控制

GPT-5.6-Sol 版界面：暗色玻璃拟态风格

GLM-5.3 版界面：亮色扁平工具风格

社区总结过 AI 生成前端的典型特征：紫蓝渐变、玻璃拟态、发光阴影、hover 弹跳、统一大圆角。五条全中，基本就是 AI 写的。

对照这张清单看两个版本。GPT-5.6-Sol 版几乎全中：暗色底、青蓝紫渐变、玻璃拟态卡片、发光阴影，是现在 AI 工具界面最常见的长相。GLM-5.3 版逐条规避：亮色扁平工具风、单一靛蓝强调色、1px 描边、零投影。

为什么会这样？我猜测原因是，有视觉能力的模型会截图自查，忠实实现需求里描述的样子，但需求描述的不一定就是好设计。描述里说深色科技感，它就给你玻璃拟态加紫蓝渐变，不会质疑这个方向对不对。没有视觉反馈的模型做前端只能靠代码层面的设计惯例，反而不会被平庸的描述带跑偏。

这只是现象，为什么会是这样，我倾向于和视觉反馈回路有关，但证实不了。

实测二：交互细节与功能完整度

风格是主观偏好，但细节有客观对错。

GPT 版下拉菜单里「快速算法」那个选项，白底浅灰字，在深色背景上几乎看不清。我们把两个版本的同一位置放大对比。

GPT-5.6-Sol 版下拉菜单对比度缺陷

GLM-5.3 版同一位置：对比度正常

这是最基础的可访问性问题。

对比视图的放大镜，GPT 版在分割线右侧永远采的是结果侧的图像，你在右边放大镜里看到的是抠完图的结果和抠完图的结果对比，失去了意义；GLM 版在分割线两侧分别采样原图和结果图，对比是真对比。历史任务的删除，GPT 版只有 API 层面的接口，界面上没有按钮；GLM 版有删除按钮，直接在界面上就能操作。

实测三：服务端安全与会话管理

这一代 GLM 发布时主打的一个方向是安全能力，官方公布过它在白盒代码审查、漏洞推理这类任务上的表现。更值得关注的是，这种能力会不会渗透到它日常写的业务代码里。

看服务端代码，两个版本的差异很直接。我们实测了两个点。

第一个点，登录限流。我们对两个版本连续发了 12 次错误登录请求。GLM 版前 10 次正常返回参数错误，第 11 次开始返回 429，提示尝试过于频繁，一分钟后才能再试。GPT 版 12 次全部放行，可以无限尝试。也就是说，GPT 版的登录接口对暴力破解是敞开的，GLM 版默认就防了。

第二个点，安全响应头。GLM 版的每个响应都带三个安全头：X-Content-Type-Options 防 MIME 嗅探、X-Frame-Options 防点击劫持、Referrer-Policy 控制来源信息泄漏。GPT 版的响应里一个都没有。这三个头是上线前安全扫描的必查项，漏了任何一个，扫描报告都会亮红。

代码里还有一处：GLM 版的会话过期后会自动清理，启动时清一次，运行中每小时清一次；GPT 版的过期会话永久留在数据库里。

这些差异在界面上完全看不到，功能清单里也不会列。但只要真上线，缺了它们迟早出事。GLM-5.3 这个版本交付的代码，默认就带了安全扫描要查的东西；GPT 版要上线，这些得人工补一遍。

实测四：需求理解与功能扩展

GLM-5.3 这个版本多做了两个功能。

一个是历史任务重跑。GPT 版想调参数重跑同一张图，只能重新上传。GLM 版在服务端留存了原图和 trimap，调完参数点重跑就能生成新任务，前后对比很方便。调参的人都懂，同一张图反复跑是常态。

另一个是批量评测。一键跑 9 张示例图，弹窗出 SAD、MSE、Grad 的对照表，还能导出 CSV（逗号分隔值文件）。改完一版算法想知道整体升了还是降了，点一下就行。

批量评测功能：一键跑 9 张示例图出指标对照表

这两个功能在清单之外，是这个版本自己补的。

三、实测结果：核心功能打平，工程细节有差距

实际测试下来，GLM-5.3 和 GPT-5.6-Sol 都完成了 PRD 的核心需求。核心功能和算法效果基本打平，但在前端细节、AI 味规避和服务端安全上，GLM 版做得更完整。

GLM-5.3+DeepSeek Harness：

GPT-5.6-Sol+DeepSeek Harness：

核心功能覆盖和算法基线效果两项打平。PRD 的要求两边都做了，算法也都是经典 closed-form方法的合格实现。

前端风格则各有偏好，GPT 版走视觉冲击力路线，GLM 版走克制工具风路线。

GLM-5.3 这个版本的交付完成度超出预期，加码的是质量细节。

单个任务的实测，得不出通用能力排名。GLM-5.3 不支持视觉输入，需要像素级精细调整的前端场景是它的劣势。测试环境是本地单机，生产环境表现可能不同。

四、不想自己接插件，可以直接用 ZCode

DeepSeek Harness 的思路是「一切皆插件」。模型、工具和工作流都能按自己的需求往里接，更灵活；但相应地，插件需要自己选择、配置和维护。

如果不想自己做插件，可以直接用智谱官方出品的 ZCode。它把 Agent、项目文件、终端、任务过程和代码审查放进同一个桌面工作台，默认集成更完整，可以开箱即用。

写在最后：GLM-5.3，更值得看的是后训练

跑完这次实测，再回头看官方披露的训练细节，GLM-5.3 的后训练值得单独说说。

智谱在技术博客里提到，GLM-5.3的能力相比 GLM-5.2 整体提升了 50%，这部分提升全部来自后训练。放到这次测试里看，这个数字就有了具体的样子：登录限流、安全响应头、会话清理，以及需求之外主动补上的功能，都不是模型把代码写出来就够了，它还得知道一套真正要交付的应用应该长什么样。

当然，单次测试没法把每个差异都直接归因于后训练。但 GLM-5.3 已经说明，模型能力的提升不只靠换一个更大的底座。怎么让模型在真实任务里学会判断、取舍和补全，同样重要。

所以接下来更值得期待的是：如果这套后训练方法放到更大的基座上，效果还能走到哪一步。

想自己试试的朋友，可以先看我们 8 月 13 日发的 DSH 保姆教程把框架搭起来。

祝各位「源神」们用得快乐！

一起“点赞”三连↓

跳转微信打开