悬荡与生成:用操作系统思维统一多Agent协作的还原论与整体论
1. 从“悬荡”这个词说起它对应的不是哲学是一线工程创伤几个月前我在调试一套由多个大模型协作的系统时屏幕上的输出忽然让我停下手里的活。左边是严格的还原论任务被切成了上百个子项每个AI Agent都能精准完成自己的那一点点合起来却像一盘散沙。右边是漂亮的整体论如果把所有上下文一次性喂给一个更大的模型让它从头到尾自由发挥结果又经常在第三段开始偏离航向。就是这两种失败模式反复交替让我真正理解了一个原本觉得飘忽的词——悬荡。“悬荡”并不是一个玄幻的说法。它指的是系统在两种倾向之间来回摆动的真实状态一种是企图把一切拆到不能再拆用原子组件拼出世界的还原论另一种是认为整体拥有组件所不具备的涌现属性、必须被整体地把握的整体论。这两种倾向在人类思想史里对抗了几百年而在AI大模型成为基础设施的今天它们不再只是哲学家书桌上的论题而是每个技术人员在跑一次任务时都会遇见的工程现实。我做AI系统这一行有十几年了从早期的规则引擎做到后来的大模型应用。一个让我越来越强烈的感受是我们一直在用某一种“论”去压制另一种“论”却很少同时驾驭它们。规则系统擅长还原但僵死神经网络擅长整体但飘忽。直到“操作系统”这个隐喻浮现在我眼前我才意识到问题可能不在选边站队而在于我们缺少一种可以让两种张力共存、并持续产出结果的运行框架。这篇文章要展开的就是我在这个思考框架下得到的一套东西——我暂时称它为AI元人文。1.1 一次让我停下来改架构的失败实验先讲一个具体的案例。当时团队要做的是一个企业知识问答系统需求很朴素从几百份文档里找到与用户提问最相关的材料生成一份有依据的回答。我们采用的是当时社区里很流行的多Agent方案一个Agent负责检索一个Agent负责摘要一个Agent负责冲突消解最后还有一个Agent负责撰写。架构图画出来非常漂亮每个人看到都觉得很专业。但第一轮联调就出了问题。负责检索的Agent很尽责按语义相似度返回了十段文本。负责摘要的Agent也尽责只保留了与问题重合度最高的三句。负责冲突消解的Agent把两次摘要里的矛盾点标记了出来。负责撰写的Agent最后按模板把这些内容缝起来——结果是一份读起来支离破碎、逻辑时断时续的报告。每个组件都在技术上做对了唯独整体坏了。这个现象在业界有个不太严谨的说法叫“语义缝隙”当任务被拆得足够细链路上的每一步都在局部范围内做最佳决策这个最佳组合在一起就不再是全局最优。它像一支乐队每个乐手都技艺精湛、各自看着小节线演奏但没有人跟着总谱走听起来就是各吹各的。1.2 还原论与整体论分歧不在学术圈早就在生产线上了反思这个失败时我翻了些历史。还原论的代表性信念是复杂系统可以分解为简单部分理解部分就能理解整体——一栋房子无非是砖、梁、瓦的堆叠。整体论则相信整体具有部分没有的属性一地之水氢和氧单独都没有“湿”的性质意识单靠神经元罗列也解释不清。这两种信念在哲学史和科学史上各有胜负但工程行业长期是还原论的大本营。我们修桥、写代码、搭流水线都是先拆后合再验证每块拼图。过去这么做得通是因为工程对象是可预期的——砖不会在砌好之后自行变成玻璃。可AI不一样。神经网络在训练时只是一个巨大的参数空间你无法像检查代码那样逐行证明它会不会出错。你控制的是数据的分布、训练的目标函数、采样的温度而不是某个具体的输出。AI产品天然带有整体论的色彩不可完全拆解只能整体涌现。于是传统工程养育的还原论习惯和神经网络本身的整体论本性在每一个Agent化项目里正面相撞。这不是谁的偏爱问题这是技术史走到今天的必然相遇。1.3 为什么旧答案失效了整体不是部分的简单相加但也不是不可触碰过去几十年工程界应对复杂系统的主流方式是“分层”和“模块化”这本质上是一种温和的还原论把系统拆成高内聚低耦合的模块再通过接口把它们拼接起来。这套方法在软件领域取得了巨大成功但它有一个隐蔽前提——模块之间的接口是稳定且可以精确描述的。传统API的输入输出类型固定语义边界明确调用前和后系统状态可预期。到了大模型时代这个前提崩溃了。一个重要Agent的输出是你无法完全预控的自然语言它可能格式稳定但语义漂移也可能格式混乱但内容精准。模块间的“接口”变成了概率性的语义场不再是确定性的类型签名。你依然可以把系统拆碎但拆碎后无法用传统接口拼回去。你依然可以把系统看作一个整体但整体又不是一个可以一键运行的黑盒。过去那种“要么拆、要么合”的两分法在AI原生系统里产生了根本性的失灵。我们需要第三种姿态允许系统在切碎和收拢之间反复循环让整体目标在局部行动中一次次被纠正、被重新生成而不是一次性定义后再无修正。2. 大模型训练与推理Token切碎与注意力缝合的双进程如果说上面那段还停留在概念那么大模型的全生命周期就是世界上规模最大的一次还原论与整体论的活体示范。我常常对我团队里新来的同学说不要把大模型看成什么魔法的黑盒子把它拆开看你就能看见一对哲学概念是如何在同一个系统里不停悬荡的。2.1 分词与下一个Token预测语义层以下最彻底的还原大模型的第一步是分词。一段话不管多复杂都会被切成一个个token——有可能是半个词有可能是几个字符。对人类来说“悬荡与生成”是一个完整的意思但对模型来说它只是几个token序列。这一步极其还原它把语言这种高度整体的现象碾成了离散的、可统计的、可计算的碎片。没有这一步后面的巨大模型根本无法工作。这就是还原论在AI里最具体的化身。它不关心“这句话是什么意思”只关心“这些token后面最可能接什么”。整个大模型训练的核心目标无非是学会对一个概率分布建模给定前文的token序列预测下一个token的概率。我见过很多人第一次看到训练代码时大失所望觉得“就这”——没有任何灵魂没有任何关于世界的整体知识只有数以亿计的参数在拟合一个极其庞大的条件概率分布。可恰恰是这种极度还原的统计拟合成就了后来几乎无所不能的语义能力。2.2 注意力与深层表征整体性从哪里悄悄回来如果模型只做逐字预测它就永远学不会长程依赖。解决这个问题的关键机制是注意力每个token在表示自己时会与上下文里所有其他token做交互按相关性加权聚合。你问“明天西湖边会不会堵车”模型里的“堵车”会先与“西湖边”建立高权重关联再与“明天”建立时间关联。这个过程实际上是把散落各处的语义碎片重新编织成一个整体图景。这可以类比成一群人围坐读一部手稿——每个人都只分到一个词条的碎片注意力机制让每一个人在读到自己的内容之前先偷看其他所有人手里的残页然后带着全场信息回看自己那句话的意思。浅层网络关注词法和局部搭配深层网络逐渐聚合出主题、意图、代理人关系等整体结构。用一句很粗的话说它先把世界切成渣再在向量空间里把渣吹成一个整体的云。云永远带不走每一粒渣的全部细节但云的形状确实承载了世界的一部分整体性质。认识到这一点会对之后的系统设计有巨大影响——你不能只从“切分”或“整体”单一视角去治理AI。2.3 采样策略与生成循环在局部概率和全局连贯之间反复摆荡到了真正生成文本时悬荡表现得最明显。概率分布已经算好了但具体选哪个token还得过一道采样策略。温度调高分布更随机模型天马行空富于创意却也容易跑偏温度调低模型更保守、更连贯但会变得重复乏味。这哪里只是参数调优这分明是整体论与还原论在实时分岔口上拉扯。每一步的局部选择都可能改变全局语义而全局语义又反过来约束局部选择。人类写作时也会有这种体验你脑子里有一个整体意象但落到句子上又得一字一字地抠某个用词一旦定下后面的整体气质就顺着变了。模型没有“灵气”但它复刻了这种循环——训练阶段从海量文本里学到的宏观规律通过多层表示压入下一个token的预测里再从概率分布里挤出一个微观字词这个字词又回写到上下文刷新全局状态。先悬荡再生成再悬荡再生成。3. 多Agent协作的工程本质从语义缝隙到调度器如果我们承认大模型内部已经演示了微观层面上的“悬荡与生成”那么当我们把多个模型放进同一个任务流水线问题就从模型内部扩展到了系统层面。这个层面离“文明操作系统”的隐喻最近也最容易用工程语言说清楚。3.1 多Agent架构还原论的一次巅峰实践多Agent架构是最自然的还原论实践把复杂任务拆成检索、推理、校验、执行、表达等角色每个Agent拥有自己的工具、记忆和提示词像车间里不同工位的工人。这个思路的吸引力在于每个工位可以单独优化、单独测试、单独换新模型出了问题定位到具体环节效率非常高。今天大家聊AI Agent、聊多AI协作大多数工作流都是这个形态。但我在实际项目里发现了三个高频痛点第一上下文撕裂——多个Agent各自持有上下文信息在传递时不断被摘要细节越传越少最后常常出现“传话游戏”式的失真第二责任漂移——一旦最终结果出错每个环节都觉得自己按指令完成了没有哪个Agent对“整体的对错”负责第三信任缺失——Agent A给Agent B的信息不足以支撑B的后续任务B只能补猜测猜测错了就算全链失败。这些痛点没有一个是“只要让某个Agent更聪明”就能解决的因为它们都是整体性的系统问题。3.2 调度器为何必须从“更聪明的提示词”走向“操作系统”最初我们试图用更好的提示词解决上述痛点结果收效甚微。后来我们把视角换了一下不再把多Agent看成一个团队而是看成一个需要调度的计算系统。任何一个操作系统内核的职责都不是替每个程序完成运算而是管理资源、调度任务、处理中断、维护进程间的通信。多Agent系统真正的内核应该是一个中介者它不参与具体问答但决定哪个Agent在什么时候获得哪个上下文、可以调用多少上下文窗口、哪些中间结果需要被持久化、出现冲突时由谁做主。这个概念转换非常有用。上下文窗口就是内存Agent的工具调用就是设备IO任务之间的依赖就是进程调度回滚到之前的某轮结果就是事务回滚。一旦用操作系统的视角重新审视多Agent协作很多原本模糊的决策就有了明确标准。这也是我后来向团队反复强调的一点——AI大模型基础理论不能只停留在模型层系统层才是决定上限的地方。架构主导倾向优势典型问题单一大模型整体生成整体论语义连贯、现场感强长任务易跑偏、内部不可控、难以局部修正多Agent强拆分还原论可定位、可复用、可并行语义缝隙、上下文撕裂、责任漂移悬荡-生成式编排统一保留涌现、提供回路、可治理编排复杂度高对设计者全局观要求高3.3 编排器的三个最小能力记忆总线、评价回路、可回滚决策要做出第三种架构不需要一开始就上很重的系统。以我的经验先实现三个最小能力就够了。第一是记忆总线。不要只让Agent之间通过对齐文本传递信息而是把重要的中间结果、引用来源、冲突记录写进一个结构化存储任何Agent都能按需读取。这相当于在进程间共享了一段可靠的内存而不是靠管道传两次摘要。第二是评价回路。每个阶段输出后插入一个独立的“检查者”环节对照最初目标和当前进展给出评分和修订指令。它不是又一个生成者而是系统内部的裁判。评价代表的是整体目标对局部过程的一次有效回写。第三是可回滚决策。每个Agent的关键决策都要保留快照发现问题时可以回到某个分叉点重新生成。这个能力直接决定系统敢不敢让整体性自由展开——如果每一步都不能回退系统自然倾向于保守也就是过度还原如果每一步都能回退系统才敢放权给整体性的涌现。提示这三点的难度不在某个单独环节而在于它们彼此咬合。记忆总线让评价回路有依据评价回路让可回滚决策有意义可回滚决策又反过来让记忆总线里的旧快照有价值。4. “文明操作系统”不是比喻而是一个可操作的分析框架标题里的“文明操作系统建构”最容易被人误读成比喻啊就是把社会比作电脑系统。我最初也觉得这是个修辞的方便说法但在这个思考框架里做了几年之后我逐渐意识到它更接近一个工程图景——先别急着把它政治化或宏大叙事化它在知识生产层面相当具体。4.1 内核、调度器、接口、应用生态五大构件如何落到文明上一个操作系统有内核有调度器有系统调用接口有用户态应用有存储文件系统。在人机协同成为常态的知识文明里这几个构件都可以找到对应物内核是对“什么可以推断、什么值得信任”的基本判定逻辑它很大程度由大模型的训练目标和对齐机制决定调度器是我们每天面对的信息流、任务流、多智能体协作时决定“现在该做什么、把注意力给谁”的机制系统调用接口则是人与AI交互的协议层包括提示词、工具调用、权限约束用户态应用是无数具体的内容生产、搜索引擎、编程助手、教育软件文件系统则是整个社会的知识存储结构从论文、代码库到个人笔记都在等待被某种标准化方式连接起来。这个映射的价值在于它把“文明”这个过于宏大的词拆成了一批可以被设计、被测试、被追踪的工程对象。过去我们谈文明容易滑入空谈现在你有了内核就可以问这套文明的内核判定逻辑是什么它作出“哪些内容值得生成”的判断时依赖的标准透明吗调度器把注意力倾向于流量还是真知这些问题只要一提出来“文明操作系统”就不只是一个漂亮的类比而是一组待建的模块。4.2 元人文的定位不写内容只写内容生成的元规则“AI元人文”这个词我的理解是在AI大规模生产内容的时代人文精神不再只是内容本身的属性还需要出现在内容生成之前的元规则里。过去一个作家通过语言表达人文关怀现在一个系统设计者通过决定“AI在什么约束下生成、在什么冲突下止损、在什么边界内发挥想象力”来体现同一件事。后者就是元人文对AI生成行为本身的规范、评价、调节。它不是另一个学科而是夹在技术与人文之间的一层运行时协议。举个例子。同一个写作Agent给它同一堆素材它可以写出讨好流量、夸大事实的爆款文也可以写出克制精确、保留不确定性的分析文。两种输出的差别不在素材而在生成时的奖励信号、系统提示词里对“事实不确定性”的容忍度、以及评价回路中偏好哪一种表达方式。这些层面就是元人文实际发生作用的地方。我们如果只关注AI写出的文本等于只看应用程序不看操作系统永远无法从根本上评价这个文明的质量。4.3 评价函数即伦理宏观目标用整体论微观执行用还原论把还原论和整体论统一起来落到文明操作系统里我的具体操作建议是宏观目标用整体论——先用一句话定义“这套系统应该让什么样的人受益、产出什么样的长期效果”微观执行用还原论——把目标拆成可评估、可追踪的指标和管线。宏观不拆就会沦为口号微观不统就会走向失控。换句话说统一不是把两者混合成一种糊状物而是它们分别在两个层面上工作再由同一个评价函数把它们接起来。评价函数是伦理的工程化身它不直接写出内容但它决定什么样的知识生产会被放大、什么样的创造会被保留什么样的错误会被及时抢救。这个评价函数是文明操作系统的“总纲”。我在自己的项目里会花比写Agent本身多出一倍的时间去定义这个函数因为它才是真正决定系统价值中枢的地方。5. 落地三步悬荡层、生成协议与留白原则前面写了这么多“为什么”最后说点“怎么做”。毕竟如果不给出可操作的路一个再好的哲学框架也只是念经。这套观点最终要在真实的AI应用里变成代码、提示词和流程才算落地。5.1 设计“悬荡层”任务切分与语义收口的交替节奏很多团队把任务切分直接用干巴巴的流水线写死先搜索再摘要后成文。这其实只实现了还原没有留出悬荡空间。我现在的做法是引入“双拍节奏”第一拍把目标切给多个Agent各自独立产出局部结果第二拍把局部结果全部收回交给一个“综合者”去通读指出整体上的矛盾、缺口和跑偏再生成新一轮的修订指令。这个循环不是一次性的而是两到三轮直到综合者给出的修订指令越来越少。这个设计和“写初稿—自我修改—评阅—再改”的写作模型同构本质上是让还原产生的碎片在整体语义的引力场里被重新抛过一次。很多人担心这种方式太慢实测下来两三轮循环确实会增加一些token消耗和延迟但正确率提升常常是数量级的。尤其在内容生成、知识整理这类偏开放的场景里多花的三分钟远比返工三天划算。5.2 为“生成协议”立三条军规我的项目里立过几条经验型规则都是踩坑之后沉淀下来的现在我在每个新系统里都会先写上这版约定第一军规任何Agent都不允许修改共同记忆总线的原始记录只能追加自己的理解。这个规则防止了传话游戏里“信息被悄悄改写”的失控现象。第二军规全局目标必须写进每个Agent的系统提示词不能只放在顶层调度器里。局部Agent看不清全局就会做局部最优看到全局才有机会做对全局有利的让步。第三军规所有“不确定”不得被静默吞掉。任何一个Agent在信息不足时必须把不确定性显式写进输出而不是假装确定、编造细节。这件事在某次合规审查里救过我们也是元人文在数据层的直接体现。这三条军规的核心都是同一件事还原后的局部单元依然有机会感知整体、敬畏整体。否则切分得越细系统离真实世界越远。5.3 宁可留白不要过度编码文明最后一条经验听起来有点反直觉去掉那些试图把一切价值都写进代码的冲动。我曾见过很有才华的团队试图做一个“完美驱动AI”的系统把审美、道德、风格、立场全做成规则结果系统越来越像一台僵硬的官僚机器输出绝不出错但也绝无生趣。原因很简单整体性价值里相当大的一部分根本没被我们显式理解过硬要编码只能把整体压成还原的碎片堆。所以在我的项目里明显属于“规定动作”的流程我们尽量自动化明显属于“自选动作”的创造性表达我们尽量给Agent留出采样空间留给人类的评价回路去校正。宁可留白让整体性在空白处自行长出来也不要试图用一个封闭规则集把整体说尽。这也是我在标题里用“生成”而不是“加工”的原因——加工是把原料变成给定的产品生成是从约束里长出未知的形态前者偏还原后者才是统一之后的新状态。5.4 踩坑记录当我真的把“悬荡”做进系统之后最后分享一个真实项目的收尾画面。我们按上述思路重构那套知识问答系统后最初几轮的效果并不理想——综合者经常给出模糊的修订意见Agent也不知道该如何执行。后来我们给综合者加了一个新指令不要回答“怎么改”只回答“哪里和最初目标不一致”。改完之后系统突然变得真实可靠了。因为它把“评判”和“执行”分离了——综合者不需要自己动手生成更好的内容只需要做整体性的诊断更优内容由各个专业Agent在诊断的引导下自行生成。这又一次验证了我前面说的定位整体设目标还原做执行中间架回路。我在实际做这类系统的过程中越来越确信一件事我们缺的不只是更聪明的模型也不只是更复杂的Agent而是一套让“拆解”与“涌现”反复对话的中间层架构。悬荡与生成不是某种文艺修辞而是这套架构每一天都在运行的节奏。谁能先把这种节奏基础设施化谁就为下一阶段的AI协作拿到了最宝贵的时间窗口。

相关新闻

编译原理实验全解析:从词法分析到中间代码生成的完整前端流水线

编译原理实验全解析:从词法分析到中间代码生成的完整前端流水线

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/10 3:36:20 阅读更多 →
Flutter×OpenHarmony跨端校园勤工俭学App架构实践

Flutter×OpenHarmony跨端校园勤工俭学App架构实践

前一阵接了个活儿:给某高校开发一套校园勤工俭学App。学生端要能浏览兼职岗位、在线提交报名、查看工资单;管理端要能发布岗位、审核报名、结算工时工资。需求听着很常规,但真正动起手来,卡点全在底层——工程需要同时支撑普通移动…

2026/10/10 3:36:20 阅读更多 →
popen pclose阻塞卡死?自定义非阻塞进程管道实现

popen pclose阻塞卡死?自定义非阻塞进程管道实现

简介:针对Linux/Unix环境下popen/pclose组合在只读取部分命令输出后直接调用pclose会阻塞这一常见问题,这份资源提供了一套经过测试的my_popen自定义实现。该实现可有效绕开默认pclose的阻塞行为,适用于C/C开发者在执行外部命令并需要分段读取…

2026/10/10 3:36:20 阅读更多 →

最新新闻

Java异常处理从入门到实战:从JVM传播机制到日志排查心法

Java异常处理从入门到实战:从JVM传播机制到日志排查心法

有一次帮同事排查线上问题,翻了一上午日志,终于找到那一行:NullPointerException。再往下翻,没了。没有堆栈、没有调用方、没有请求ID。异常被某个 catch 接住之后,只打了一行e.getMessage(),而 getMessage…

2026/10/10 4:17:41 阅读更多 →
AVL树的实现与避坑指南:旋转与平衡因子详解

AVL树的实现与避坑指南:旋转与平衡因子详解

AVL树这个东西,只要搞过一段时间的二叉搜索树,基本都会碰到。它本质上就是一棵“严格要求自己”的自平衡二叉搜索树,靠平衡因子把左右子树的高度差锁在可接受范围内,从而让查找、插入、删除的时间稳定在 O(logn) 级别。标题叫“AV…

2026/10/10 4:17:41 阅读更多 →
给大模型装上长期记忆:claude-mem对话记忆增强实战

给大模型装上长期记忆:claude-mem对话记忆增强实战

说起来你可能不信,我第一次试完这个“claude-mem”之后,最大的感受不是“AI变聪明了”,而是“原来它终于愿意记住我说的话了”。用过Claude这类大模型的人基本都有过类似的体验:同一个问题,你昨天问它,它给…

2026/10/10 4:17:41 阅读更多 →
轻量级恶意URL检测:传统机器学习在产线的实战落地

轻量级恶意URL检测:传统机器学习在产线的实战落地

简介:本资源是一个面向网络安全初学者与机器学习实践者的恶意URL检测项目改进版,聚焦于利用机器学习提升对钓鱼、挂马、恶意跳转等高危URL的识别能力,适用于CTF练习、安全课程设计及AI安全方向入门实验。压缩包共15个文件,涵盖3个…

2026/10/10 4:17:41 阅读更多 →
PS5全攻略:型号辨别、存储扩容与系统维护实战指南

PS5全攻略:型号辨别、存储扩容与系统维护实战指南

不管你是刚拆箱第一台主机的新玩家,还是已经折腾了好几年的老油条,只要看到“AnyPS5”这几个字母,想聊的其实都是同一件事:手上这台PS5,怎么才能玩得顺、用得久、不花冤枉钱。这个标题最吸引我的地方就在于那个“Any”…

2026/10/10 4:17:40 阅读更多 →
AI编程新范式:用AGENTS.md构建项目记忆体系,告别无状态困境

AI编程新范式:用AGENTS.md构建项目记忆体系,告别无状态困境

作为一个从 AI 编程助手刚出现就开始用、到现在几乎每天离不开的人,我最近半年最明显的感受是:AI 编程的重心,正在从"怎么把一句话问得更好"转向"怎么把项目的记忆交给 AI"。这两者听起来差别不大,但实际开发…

2026/10/10 4:16:40 阅读更多 →

日新闻

卫星轨道分类全解析:从LEO到GEO的选型逻辑与工程实践

卫星轨道分类全解析:从LEO到GEO的选型逻辑与工程实践

1. 从“卫星轨道分类”这个标题说起:为什么值得花时间搞懂第一次接触“卫星轨道分类”这个概念,很多人会觉得它离自己很远——不就是天上的星星怎么转吗?但如果你正在做航天任务规划、遥感数据接收、星座设计,甚至只是准备一场航天…

2026/10/10 0:00:39 阅读更多 →
Spring AOP 核心原理与实战:从概念到日志切面落地

Spring AOP 核心原理与实战:从概念到日志切面落地

1. 从一个真实痛点说起:为什么你的代码里到处都是重复逻辑刚入行那会儿,我写过一个用户管理模块,注册、登录、改密码、注销四个接口。每个接口里都塞了几乎一样的日志打印、参数校验、事务开启和提交。当时觉得没什么,能跑就行。直…

2026/10/10 0:00:40 阅读更多 →
Python招聘数据采集与分析可视化:从采集清洗到薪资技能城市可视化全链路

Python招聘数据采集与分析可视化:从采集清洗到薪资技能城市可视化全链路

简介:这是一套面向计算机相关专业学生与项目实战学习者的Python数据采集与分析可视化完整项目,以Boss直聘岗位数据为对象,适合用作毕业设计、课程设计或期末大作业。资源包共38个文件,约246KB,以13个py源码文件为核心&…

2026/10/10 0:00:40 阅读更多 →

周新闻

KT148A语音芯片外挂8002D功放的工程实践指南

KT148A语音芯片外挂8002D功放的工程实践指南

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/8 15:26:32 阅读更多 →
LLC谐振变换器增益公式推导:从FHA等效到完整归一化表达式

LLC谐振变换器增益公式推导:从FHA等效到完整归一化表达式

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/10 1:36:08 阅读更多 →
ARM架构深度解析:从RISC设计理念到交叉编译实战

ARM架构深度解析:从RISC设计理念到交叉编译实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/9 10:11:06 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/8 21:13:17 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/9 21:32:20 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/9 6:17:20 阅读更多 →