[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"consumer-news-detail-844":3,"consumer-news-interaction-844":38,"consumer-news-related-844":41},{"detail":4,"item":34},{"card":5,"schemaVersion":21,"fields":22,"content":28},{"id":6,"kind":7,"targetType":8,"targetId":9,"subtype":7,"typeLabel":10,"title":11,"subtitle":12,"summary":13,"coverUrl":14,"badgeText":14,"href":15,"sourceName":12,"meta":16,"metrics":18,"tags":19,"resolved":20},"NEWS_ARTICLE:844","news","NEWS_ARTICLE",844,"资讯","数据库上K8s，运维为什么反而更累了？从StatefulSet到Operator的复盘","博客园","各位，我是老张。今天从一次实战出发，往下拆一层。 上个月陪一个朋友看他们的容器化改造。业务服务全部迁上K8s了，跑得挺顺，唯独数据库卡在原地。那哥们跟我吐槽：老张，代码都能容器化，怎么一到了数据库这儿，运维反而比以前更累了？我上去看了眼环境，果然，数据库还是手工搭的，跟K8s一点关系没有，扩容要半夜","","\u002Fnews\u002F844",[17],"2026",{},[],true,"consumer-content-detail-v1",{"sourceName":12,"authorName":23,"summary":13,"description":13,"publishTime":24,"updateTime":25,"sourceUrl":26,"language":27},"底层玩家老张","2026-09-02T11:16","2026-09-02T20:37:48","https:\u002F\u002Fwww.cnblogs.com\u002Fdicengwanjialaozhang\u002Fp\u002F22804728","中文",{"format":29,"policy":30,"normalized":20,"html":31,"text":32,"wordCount":33,"hasBody":20},"HTML","NEWS_CONTENT_V1","\u003Cp>各位，我是老张。今天从一次实战出发，往下拆一层。\u003C\u002Fp>\n\u003Cp>上个月陪一个朋友看他们的容器化改造。业务服务全部迁上K8s了，跑得挺顺，唯独数据库卡在原地。那哥们跟我吐槽：老张，代码都能容器化，怎么一到了数据库这儿，运维反而比以前更累了？我上去看了眼环境，果然，数据库还是手工搭的，跟K8s一点关系没有，扩容要半夜爬起来改配置。\u003C\u002Fp>\n\u003Cp>他不是一个人遇到这个坎。先给结论：K8s天生为无状态服务设计，数据库是典型的有状态应用。两者之间那道缝，过去靠人肉填，现在得靠一套机制填。今天就把这套机制拆开讲，顺带看看国产数据库在这条路上走到哪了。\u003C\u002Fp>\n\u003Ch2>数据库上K8s，难点到底在哪\u003C\u002Fh2>\n\u003Cp>先把问题说清楚。一个业务服务是无状态的，挂了就重启，请求随便调度到哪个节点都行。K8s管它很省心，无非是副本、滚动更新、弹性伸缩。\u003C\u002Fp>\n\u003Cp>数据库不一样。它有数据，有主从关系，有持久化存储。节点挂了，数据不能丢；主从切换，得保证一致性；扩缩容，不是多拉几个Pod那么简单，得重新分片、重新平衡。这还没算备份、监控、参数配置这些日常运维。说白了，把数据库塞进K8s，不是“能跑起来”就完事，而是“能不能按K8s的方式被管理”。\u003C\u002Fp>\n\u003Ctable>\n \u003Cthead>\n  \u003Ctr>\n   \u003Cth>维度\u003C\u002Fth>\n   \u003Cth>传统运维\u003C\u002Fth>\n   \u003Cth>手工容器化\u003C\u002Fth>\n   \u003Cth>Operator管理\u003C\u002Fth>\n  \u003C\u002Ftr>\n \u003C\u002Fthead>\n \u003Ctbody>\n  \u003Ctr>\n   \u003Ctd>部署\u003C\u002Ftd>\n   \u003Ctd>逐台装，脚本堆\u003C\u002Ftd>\n   \u003Ctd>写一堆init容器\u003C\u002Ftd>\n   \u003Ctd>配置即期望状态\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>状态维护\u003C\u002Ftd>\n   \u003Ctd>巡检+告警\u003C\u002Ftd>\n   \u003Ctd>人盯\u003C\u002Ftd>\n   \u003Ctd>控制器自动协调\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>扩缩容\u003C\u002Ftd>\n   \u003Ctd>手工加机器\u003C\u002Ftd>\n   \u003Ctd>手工改\u003C\u002Ftd>\n   \u003Ctd>改配置即可\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>备份\u003C\u002Ftd>\n   \u003Ctd>定时脚本\u003C\u002Ftd>\n   \u003Ctd>定时脚本\u003C\u002Ftd>\n   \u003Ctd>声明式任务\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>故障恢复\u003C\u002Ftd>\n   \u003Ctd>人肉介入\u003C\u002Ftd>\n   \u003Ctd>人肉介入\u003C\u002Ftd>\n   \u003Ctd>自动对齐期望\u003C\u002Ftd>\n  \u003C\u002Ftr>\n \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>传统方式是“人围着数据库转”，容器化初期是“把脚本搬进镜像”，而Operator要解决的，是“让数据库自己管自己”。\u003C\u002Fp>\n\u003Cp>这里先排掉一个常见误区。很多人以为StatefulSet就能管数据库。StatefulSet确实解决了“有状态”的一部分，比如稳定的网络标识、稳定的存储卷，但它只解决“实例怎么跑”，不解决“数据库集群怎么管”。主库挂了，谁提升为新主？从库怎么追日志位点？StatefulSet一概不知，它只关心Pod数量够不够，不关心集群健康不健康。这就像盖楼只给了脚手架，主体结构还得自己搭。选主、复制、故障转移这些核心逻辑，必须写在Operator里。理解了这一点，才能看懂为什么数据库上K8s，最终都要走到Operator这条路。\u003C\u002Fp>\n\u003Ch2>Operator模式，到底在管什么\u003C\u002Fh2>\n\u003Cp>讲真，很多文章把Operator说得神乎其神。剥开来看，核心就两件事：扩展K8s的资源类型，加上一个不停干活的控制器。\u003C\u002Fp>\n\u003Cp>K8s本身认识Pod、Service、Deployment这些内置资源，可数据库集群这种“高级资源”它不认识。Operator通过自定义资源（CRD）告诉K8s：这是KES集群，它有这些字段。用户写一份YAML，声明“我要一个三节点的KES集群，主从结构，开启备份”。K8s把这个YAML存下来，这就是期望状态。\u003C\u002Fp>\n\u003Cp>控制器盯着它，一趟趟比较“现实”和“期望”差多少，差了就去调Pod、调存储、调网络，直到对齐。这套机制叫协调循环。脚本是一次性的，跑完就结束；协调循环不停歇，状态偏了它就自己拉回来。数据库集群这种常年跑的东西，要的就是这种“盯”的能力。\u003C\u002Fp>\n\u003Cp>展开看一次完整的协调循环，大致四步：从K8s API拉取当前资源列表；逐个比较当前状态和期望状态，找出差异在哪；然后针对差异执行动作，Pod没起来就重建，存储不够就扩容卷；最后更新状态，把处理结果写回，等下一轮循环。这个循环不是跑一次就停，而是在后台一直转。\u003C\u002Fp>\n\u003Cp>讲真，我一开始也不太理解为什么要绕这一圈。我写Java那会儿，喜欢把逻辑都写在代码里，事无巨细。后来做架构才慢慢想明白：系统越复杂，越要少写“过程”，多定义“目标”。K8s的声明式管理，就是这个思路的极致。\u003C\u002Fp>\n\u003Cp>这里补一句背景。金仓的KES是国产数据库里对容器化探索比较早的一批。这次他们推出的KES-Operator，就是把上面这套声明式机制，落到了KES集群管理上。等于把“数据库上K8s”这条路，从“能跑”推进到“好管”。\u003C\u002Fp>\n\u003Ch2>声明式管理，到底省了什么\u003C\u002Fh2>\n\u003Cp>再说声明式这个事。命令式是“你一步步告诉我怎么干”，声明式是“你告诉我最终长啥样，过程我来想办法”。数据库集群最头疼的就是“过程”。创建一套集群，涉及配置文件、数据目录、存储卷、网络策略，人工一步步来，漏一步就起不来。声明式把这些全包了：你要的是“三节点、读写分离、物理备份每天一次”，写清楚就行，剩下的是Operator的事。\u003C\u002Fp>\n\u003Cp>我见过太多团队卡在这。他们把K8s的YAML当脚本用，写一堆init容器，一个步骤一个步骤地编排。这本质上还是命令式思维，只是把命令写进了配置文件。一旦某个步骤失败，整条链就断在那，排查起来比传统运维还痛苦。声明式的做法是，你不再关心“第几步该干什么”，只关心“最终要达成什么状态”。状态不对，控制器负责想办法，你要做的只是定目标，不是盯过程。\u003C\u002Fp>\n\u003Ch2>KES-Operator，四个能力对应四个痛点\u003C\u002Fh2>\n\u003Cp>接下来拆KES-Operator。它给KES集群管了四件事，恰好都是手工干起来最烦的那几件。\u003C\u002Fp>\n\u003Cp>先说部署。以前搭一套KES集群，得一个个点资源对象，配置项能排一页纸，错一个就起不来。现在写一份配置，声明“要三节点、主从、开备份”，剩下的Operator自己去建。新环境拉一套集群，从半天缩到一杯茶的工夫。这个我熟，当年手工建库建到后半夜，第二天还得爬起来盯告警。\u003C\u002Fp>\n\u003Cp>再说状态管理。集群跑起来之后，麻烦在状态会漂。节点挂了、配置被人改了、磁盘不够了，集群就悄悄偏离你想要的样子，以前全靠人盯，盯不盯得住看运气。KES-Operator的控制器一直在比对现实和期望，偏了就把资源拉回来。这套“自动纠偏”看着不起眼，省掉的是最磨人的巡检。\u003C\u002Fp>\n\u003Cp>扩缩容是另一个重灾区。业务有波峰波谷，数据库得跟着调，以前扩个容要规划、要停机窗口，还得留回滚时间，跟做手术一个路数。现在改一下配置，让它按新配置自己调，从手术变成了调参。听着是小事，可真在停机窗口里战战兢兢改过配置的人，都知道这一步值多少。\u003C\u002Fp>\n\u003Cp>最后是备份和监控。备份以前靠定时脚本，脚本坏了没人知道，等真要恢复才发现是空欢喜。KES-Operator把物理备份接进了K8s这套体系，配置好就自己跑；监控组件KMonitor也一起管了，集群状态在K8s里统一看。\u003C\u002Fp>\n\u003Cp>这四件事单拿出来都不新鲜，合在一起才是重点：部署、状态、扩缩容、备份、监控，一套方式管到底，不用在两个体系里来回切。\u003C\u002Fp>\n\u003Ch2>数据库容器化，走到哪一步了\u003C\u002Fh2>\n\u003Cp>数据库容器化，我习惯把它分成三个阶段。第一阶段，把数据库装进镜像，能跑起来，但运维方式还是老的。第二阶段，用StatefulSet管实例，解决了持久化和网络标识，但集群逻辑还得靠外围脚本兜着。第三阶段，用Operator管整个集群，部署、状态、扩缩容、备份、监控，全纳入声明式管理。\u003C\u002Fp>\n\u003Cp>绝大多数团队停在第二阶段。不是不想往前走，是Operator开发门槛确实高。你得懂K8s的扩展机制，还得懂数据库本身的集群逻辑，两样都熟的人不多。这也是为什么很多团队宁可等厂商出方案，自己不动手。金仓把KES-Operator做出来，等于把集群管理的经验封装成了一套能声明式使用的工具，帮你跨过这道门槛。\u003C\u002Fp>\n\u003Ch2>如果让我选，怎么看这种方案\u003C\u002Fh2>\n\u003Cp>说实话，我见过不少“为了容器化而容器化”的项目，把数据库硬塞进K8s，结果运维更复杂。所以别急着上，先看自己的情况。\u003C\u002Fp>\n\u003Cp>先看团队熟不熟K8s。连业务服务都还没迁完，就先别碰数据库，Operator是把双刃剑，用得不好，复杂度比收益大。再看数据库规模，单机小库手工运维成本低，不值得折腾；几十套集群，Operator的收益才明显。还有一层容易忽略：受不受得了“期望状态”这套玩法。它要求你把运维经验沉淀成配置，团队里得有人能把踩过的坑，翻译成“状态定义”。\u003C\u002Fp>\n\u003Cp>不过方向其实很清楚：有状态应用的管理，正在从“人肉”走向“声明式”。数据库是其中最有代表性的一个，迟早要过这一关。国产数据库里，金仓的KES-Operator是把这条路走得比较完整的。\u003C\u002Fp>\n\u003Cp>收益也能算笔账。假设你管二十套KES集群，传统方式下，一个DBA每天一半时间耗在巡检、部署、扩容上。上了声明式管理，这部分重复劳动能砍掉一大半。省下来的时间，可以拿去做真正的性能优化和架构演进。\u003C\u002Fp>\n\u003Ch2>避坑清单\u003C\u002Fh2>\n\u003Cp>再聊几个坑，都是别人真金白银换来的。备份一定要在K8s这套体系里闭环，别部署用了Operator，备份还靠外面的定时脚本，那又回到碎片化了。\u003C\u002Fp>\n\u003Cp>扩缩容要留演练时间。别等业务高峰当天才第一次扩，先在小环境把流程跑顺。Operator不等于免演练，它只是把操作标准化了。\u003C\u002Fp>\n\u003Cp>期望状态也不是写了就不管。配置要纳入版本管理，改动要有评审，不然“自动纠偏”会变成“自动出问题”，比人工还难查。\u003C\u002Fp>\n\u003Ch2>最后说两句\u003C\u002Fh2>\n\u003Cp>数据库上K8s，本质是把运维经验变成代码。这条路不好走，但值得走。金仓这套KES-Operator，没把K8s当噱头，而是把集群管理能力一项项落了进去。如果你正好在规划数据库容器化，可以拿它当个参照。\u003C\u002Fp>\n\u003Cp>你们数据库上K8s碰到过什么坑？评论区聊聊，我挑几个典型的下次拆。\u003C\u002Fp>\n\u003Cp>我是底层玩家老张。咱不聊概念，只聊源码和压测跑出来的东西。\u003C\u002Fp>","各位，我是老张。今天从一次实战出发，往下拆一层。 上个月陪一个朋友看他们的容器化改造。业务服务全部迁上K8s了，跑得挺顺，唯独数据库卡在原地。那哥们跟我吐槽：老张，代码都能容器化，怎么一到了数据库这儿，运维反而比以前更累了？我上去看了眼环境，果然，数据库还是手工搭的，跟K8s一点关系没有，扩容要半夜爬起来改配置。 他不是一个人遇到这个坎。先给结论：K8s天生为无状态服务设计，数据库是典型的有状态应用。两者之间那道缝，过去靠人肉填，现在得靠一套机制填。今天就把这套机制拆开讲，顺带看看国产数据库在这条路上走到哪了。 数据库上K8s，难点到底在哪 先把问题说清楚。一个业务服务是无状态的，挂了就重启，请求随便调度到哪个节点都行。K8s管它很省心，无非是副本、滚动更新、弹性伸缩。 数据库不一样。它有数据，有主从关系，有持久化存储。节点挂了，数据不能丢；主从切换，得保证一致性；扩缩容，不是多拉几个Pod那么简单，得重新分片、重新平衡。这还没算备份、监控、参数配置这些日常运维。说白了，把数据库塞进K8s，不是“能跑起来”就完事，而是“能不能按K8s的方式被管理”。 维度 传统运维 手工容器化 Operator管理 部署 逐台装，脚本堆 写一堆init容器 配置即期望状态 状态维护 巡检+告警 人盯 控制器自动协调 扩缩容 手工加机器 手工改 改配置即可 备份 定时脚本 定时脚本 声明式任务 故障恢复 人肉介入 人肉介入 自动对齐期望 传统方式是“人围着数据库转”，容器化初期是“把脚本搬进镜像”，而Operator要解决的，是“让数据库自己管自己”。 这里先排掉一个常见误区。很多人以为StatefulSet就能管数据库。StatefulSet确实解决了“有状态”的一部分，比如稳定的网络标识、稳定的存储卷，但它只解决“实例怎么跑”，不解决“数据库集群怎么管”。主库挂了，谁提升为新主？从库怎么追日志位点？StatefulSet一概不知，它只关心Pod数量够不够，不关心集群健康不健康。这就像盖楼只给了脚手架，主体结构还得自己搭。选主、复制、故障转移这些核心逻辑，必须写在Operator里。理解了这一点，才能看懂为什么数据库上K8s，最终都要走到Operator这条路。 Operator模式，到底在管什么 讲真，很多文章把Operator说得神乎其神。剥开来看，核心就两件事：扩展K8s的资源类型，加上一个不停干活的控制器。 K8s本身认识Pod、Service、Deployment这些内置资源，可数据库集群这种“高级资源”它不认识。Operator通过自定义资源（CRD）告诉K8s：这是KES集群，它有这些字段。用户写一份YAML，声明“我要一个三节点的KES集群，主从结构，开启备份”。K8s把这个YAML存下来，这就是期望状态。 控制器盯着它，一趟趟比较“现实”和“期望”差多少，差了就去调Pod、调存储、调网络，直到对齐。这套机制叫协调循环。脚本是一次性的，跑完就结束；协调循环不停歇，状态偏了它就自己拉回来。数据库集群这种常年跑的东西，要的就是这种“盯”的能力。 展开看一次完整的协调循环，大致四步：从K8s API拉取当前资源列表；逐个比较当前状态和期望状态，找出差异在哪；然后针对差异执行动作，Pod没起来就重建，存储不够就扩容卷；最后更新状态，把处理结果写回，等下一轮循环。这个循环不是跑一次就停，而是在后台一直转。 讲真，我一开始也不太理解为什么要绕这一圈。我写Java那会儿，喜欢把逻辑都写在代码里，事无巨细。后来做架构才慢慢想明白：系统越复杂，越要少写“过程”，多定义“目标”。K8s的声明式管理，就是这个思路的极致。 这里补一句背景。金仓的KES是国产数据库里对容器化探索比较早的一批。这次他们推出的KES-Operator，就是把上面这套声明式机制，落到了KES集群管理上。等于把“数据库上K8s”这条路，从“能跑”推进到“好管”。 声明式管理，到底省了什么 再说声明式这个事。命令式是“你一步步告诉我怎么干”，声明式是“你告诉我最终长啥样，过程我来想办法”。数据库集群最头疼的就是“过程”。创建一套集群，涉及配置文件、数据目录、存储卷、网络策略，人工一步步来，漏一步就起不来。声明式把这些全包了：你要的是“三节点、读写分离、物理备份每天一次”，写清楚就行，剩下的是Operator的事。 我见过太多团队卡在这。他们把K8s的YAML当脚本用，写一堆init容器，一个步骤一个步骤地编排。这本质上还是命令式思维，只是把命令写进了配置文件。一旦某个步骤失败，整条链就断在那，排查起来比传统运维还痛苦。声明式的做法是，你不再关心“第几步该干什么”，只关心“最终要达成什么状态”。状态不对，控制器负责想办法，你要做的只是定目标，不是盯过程。 KES-Operator，四个能力对应四个痛点 接下来拆KES-Operator。它给KES集群管了四件事，恰好都是手工干起来最烦的那几件。 先说部署。以前搭一套KES集群，得一个个点资源对象，配置项能排一页纸，错一个就起不来。现在写一份配置，声明“要三节点、主从、开备份”，剩下的Operator自己去建。新环境拉一套集群，从半天缩到一杯茶的工夫。这个我熟，当年手工建库建到后半夜，第二天还得爬起来盯告警。 再说状态管理。集群跑起来之后，麻烦在状态会漂。节点挂了、配置被人改了、磁盘不够了，集群就悄悄偏离你想要的样子，以前全靠人盯，盯不盯得住看运气。KES-Operator的控制器一直在比对现实和期望，偏了就把资源拉回来。这套“自动纠偏”看着不起眼，省掉的是最磨人的巡检。 扩缩容是另一个重灾区。业务有波峰波谷，数据库得跟着调，以前扩个容要规划、要停机窗口，还得留回滚时间，跟做手术一个路数。现在改一下配置，让它按新配置自己调，从手术变成了调参。听着是小事，可真在停机窗口里战战兢兢改过配置的人，都知道这一步值多少。 最后是备份和监控。备份以前靠定时脚本，脚本坏了没人知道，等真要恢复才发现是空欢喜。KES-Operator把物理备份接进了K8s这套体系，配置好就自己跑；监控组件KMonitor也一起管了，集群状态在K8s里统一看。 这四件事单拿出来都不新鲜，合在一起才是重点：部署、状态、扩缩容、备份、监控，一套方式管到底，不用在两个体系里来回切。 数据库容器化，走到哪一步了 数据库容器化，我习惯把它分成三个阶段。第一阶段，把数据库装进镜像，能跑起来，但运维方式还是老的。第二阶段，用StatefulSet管实例，解决了持久化和网络标识，但集群逻辑还得靠外围脚本兜着。第三阶段，用Operator管整个集群，部署、状态、扩缩容、备份、监控，全纳入声明式管理。 绝大多数团队停在第二阶段。不是不想往前走，是Operator开发门槛确实高。你得懂K8s的扩展机制，还得懂数据库本身的集群逻辑，两样都熟的人不多。这也是为什么很多团队宁可等厂商出方案，自己不动手。金仓把KES-Operator做出来，等于把集群管理的经验封装成了一套能声明式使用的工具，帮你跨过这道门槛。 如果让我选，怎么看这种方案 说实话，我见过不少“为了容器化而容器化”的项目，把数据库硬塞进K8s，结果运维更复杂。所以别急着上，先看自己的情况。 先看团队熟不熟K8s。连业务服务都还没迁完，就先别碰数据库，Operator是把双刃剑，用得不好，复杂度比收益大。再看数据库规模，单机小库手工运维成本低，不值得折腾；几十套集群，Operator的收益才明显。还有一层容易忽略：受不受得了“期望状态”这套玩法。它要求你把运维经验沉淀成配置，团队里得有人能把踩过的坑，翻译成“状态定义”。 不过方向其实很清楚：有状态应用的管理，正在从“人肉”走向“声明式”。数据库是其中最有代表性的一个，迟早要过这一关。国产数据库里，金仓的KES-Operator是把这条路走得比较完整的。 收益也能算笔账。假设你管二十套KES集群，传统方式下，一个DBA每天一半时间耗在巡检、部署、扩容上。上了声明式管理，这部分重复劳动能砍掉一大半。省下来的时间，可以拿去做真正的性能优化和架构演进。 避坑清单 再聊几个坑，都是别人真金白银换来的。备份一定要在K8s这套体系里闭环，别部署用了Operator，备份还靠外面的定时脚本，那又回到碎片化了。 扩缩容要留演练时间。别等业务高峰当天才第一次扩，先在小环境把流程跑顺。Operator不等于免演练，它只是把操作标准化了。 期望状态也不是写了就不管。配置要纳入版本管理，改动要有评审，不然“自动纠偏”会变成“自动出问题”，比人工还难查。 最后说两句 数据库上K8s，本质是把运维经验变成代码。这条路不好走，但值得走。金仓这套KES-Operator，没把K8s当噱头，而是把集群管理能力一项项落了进去。如果你正好在规划数据库容器化，可以拿它当个参照。 你们数据库上K8s碰到过什么坑？评论区聊聊，我挑几个典型的下次拆。 我是底层玩家老张。咱不聊概念，只聊源码和压测跑出来的东西。",3658,{"id":6,"kind":7,"title":11,"summary":13,"image":14,"href":15,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":37},"#2563eb","16 \u002F 10",[7,8],{"targetType":8,"targetId":9,"likedByMe":39,"likeCount":40,"commentCount":40,"contentLikeCount":40,"contentCommentCount":40,"sourceLikeCount":40,"sourceCommentCount":40},false,0,[42,51,57,64,72,79,85,92],{"id":43,"kind":7,"title":44,"summary":45,"image":46,"href":47,"meta":48,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":49},"NEWS_ARTICLE:827","MHS 三部曲（下）：谁允许 AI 行动？——权力、合规与中国厂商的答卷","我们总在等待一个像 ChatGPT 那样的机器人时刻。但具身智能真正的拐点，也许先发生在更不起眼的地方：一台陌生设备，第一次能把自己的能力、状态和边界完整告诉 AI；一个 Agent，第一次能把试出来的经验固化成可验证、可复用的机器技能。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F510\u002F202608\u002F510-20260830153745229-1536981088.jpg","\u002Fnews\u002F827","2026 · 人工智能",[50],"人工智能",{"id":52,"kind":7,"title":53,"summary":54,"image":14,"href":55,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":56},"NEWS_ARTICLE:829","我不会美工，用 WorkBuddy 1 分钟做出 4 张海报","先说结果：下面这 4 张海报，从我发出指令到拿到图片，大约 1 分钟。 我不会美工，也没有打开 Photoshop。用的工具，是我之前用 WorkBuddy 做的一个海报生成器。这个生成器本身也没花几分钟，具体开发过程我在上一篇文章里写过。 这次我把海报生成器的网址、产品截图和要求一起发给 Work","\u002Fnews\u002F829",[7,8],{"id":58,"kind":7,"title":59,"summary":60,"image":61,"href":62,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":63},"NEWS_ARTICLE:828","一个人抵一个团队的时代，企业级 AI Agent 还需要做什么？","对于企业而言，真正需要的，不是一个“会聊天”的 Agent，而是一套能被多用户、多场景复用，且权限清晰、过程可审计、成本可控制的 Agent 能力体系。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2232255\u002F202609\u002F2232255-20260902173524728-659996478.png","\u002Fnews\u002F828",[7,8],{"id":65,"kind":7,"title":66,"summary":67,"image":14,"href":68,"meta":69,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":70},"NEWS_ARTICLE:832","用 runtime-async 写一个支持 async\u002Fawait 的轻量脚本引擎","起因：一个好奇 事情的开头很简单。 给 .NET 做过动态脚本的人大概都碰到过同一堵墙：表达式树也好、Reflection.Emit 也好，都很难支持 async\u002Fawait。原因不在语法，而在 await 的实现方式——C# 编译器要为每个 async 方法生成一个状态机结构体，把方法体切成若干片","\u002Fnews\u002F832","2026 · 软件开发",[71],"软件开发",{"id":73,"kind":7,"title":74,"summary":75,"image":76,"href":77,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":78},"NEWS_ARTICLE:831","Agent Sandbox 规模化：JuiceFS 探索与实践","过去一段时间，我们在和云厂商以及 Agent 团队推进 Sandbox 落地时，除了要解决数据如何进入 Sandbox，还需要考虑任务所需的数据和执行过程中产生的数据，如何跨任务、跨阶段持续使用。Sandbox 可以随任务快速创建和销毁，但数据往往需要继续保留、共享和流转。 当 Sandbox 并发","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2544292\u002F202609\u002F2544292-20260902171045357-1907499098.png","\u002Fnews\u002F831",[7,8],{"id":80,"kind":7,"title":81,"summary":82,"image":14,"href":83,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":84},"NEWS_ARTICLE:830","百智云长期记忆服务：长期记忆与上下文窗口的区别","很多人在接触 AI 长期记忆时，第一反应是：「这不就是把聊天记录存起来吗？」其实这是一个很常见的误解。今天我们把「长期记忆」和「上下文窗口」这两个概念彻底讲清楚。 一、什么是上下文窗口 上下文窗口（Context Window）是模型在单次推理时能「看到」的文本上限。它像一个临时的工作台：模型只能处","\u002Fnews\u002F830",[7,8],{"id":86,"kind":7,"title":87,"summary":88,"image":89,"href":90,"meta":48,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":91},"NEWS_ARTICLE:835","体验向量数据库 qdrant","作者:张富春(ahfuzhang)，转载时请注明作者和引用链接，谢谢！ cnblogs博客 zhihu Github 公众号:一本正经的瞎扯 背景 为了早点搞懂公司的百万行 C# 的祖传代码，我想在缺乏文档、缺乏帮手的情况下，先建立一个 企业知识库 来快速帮我理清头绪。 一开始，我是打算以 weav","https:\u002F\u002Fimg2022.cnblogs.com\u002Fblog\u002F1457949\u002F202202\u002F1457949-20220216153819145-1193738712.png","\u002Fnews\u002F835",[50],{"id":93,"kind":7,"title":94,"summary":95,"image":14,"href":96,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":97},"NEWS_ARTICLE:833","如何利用AI技术实现漫画翻译","漫画作为图文结合的特色文化载体，承载着各国潮流文化与人文故事，但跨语言的文字壁垒，长期制约着漫画的传播与交流。传统漫画翻译高度依赖人工操作，需要人工框选文字、擦除原图文字、翻译文案、排版适配画风，流程繁琐、耗时费力，且极易出现排版错乱、画风违和、语义偏差等问题。 随着深度学习、计算机视觉与大模型技术","\u002Fnews\u002F833",[7,8]]