[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"consumer-news-detail-852":3,"consumer-news-interaction-852":38,"consumer-news-related-852":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:852","news","NEWS_ARTICLE",852,"资讯","多智能体编排配置的工程化实践:权限、成本、上下文与可复现交付","博客园","一、权限最小化:两道白名单 第一道:任务工具白名单(编排层)。 主智能体(编排者)通过 permission 声明:Task 工具默认拒绝一切派发,只放行 10 个具名子智能体(planner、deep-worker、oracle、reviewer、consultant、ui-builder、exp","","\u002Fnews\u002F852",[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-02T08:58","2026-09-02T20:37:50","https:\u002F\u002Fwww.cnblogs.com\u002Fznlgis\u002Fp\u002F22801422","中文",{"format":29,"policy":30,"normalized":20,"html":31,"text":32,"wordCount":33,"hasBody":20},"HTML","NEWS_CONTENT_V1","\u003Ch2>一、权限最小化:两道白名单\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>第一道:任务工具白名单(编排层)。\u003C\u002Fstrong> 主智能体(编排者)通过 permission 声明:Task 工具默认拒绝一切派发,只放行 10 个具名子智能体(planner、deep-worker、oracle、reviewer、consultant、ui-builder、explore、librarian、light-orchestrator、vision)。效果有三:\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cstrong>路由闭环\u003C\u002Fstrong>:所有路由决策收敛到一张显式路由表,不存在\"即兴派发\";\u003C\u002Fli>\n \u003Cli>\u003Cstrong>防幻觉派发\u003C\u002Fstrong>:模型无法临时发明一个不存在的子智能体;\u003C\u002Fli>\n \u003Cli>\u003Cstrong>边界即文档\u003C\u002Fstrong>:谁允许被派发、谁不允许,配置本身就是权威文档。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>第二道:技能白名单(每个子智能体)。\u003C\u002Fstrong> 每个 agent 独立声明自己只能加载哪些技能,其余一律拒绝。例如:实现者(deep-worker)只加载 remove-deadcode、git-release、resolving-merge-conflicts 等执行类技能;审查者(reviewer)只加载 code-review、security-review;探索者(explore)只加载 codemap;分析师(oracle)只加载 reflect、simplify。\u003C\u002Fp>\n\u003Cp>动机很关键:在不少框架里,加载一个技能隐含\"自我实现授权\"——读到了实现指南就等于拿到了动手许可。白名单把\"能读什么技能\"与\"能做什么事\"彻底解耦,同时明确了一条纪律:\u003Cstrong>加载技能不等于授权自我实现\u003C\u002Fstrong>,多文件改动仍然必须走 planner → 实现者的路径。\u003C\u002Fp>\n\u003Ch2>二、模型分层与成本核算\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>flash \u002F pro 分层。\u003C\u002Fstrong> flash 负责路由、搜索、查找、规划、常规实现;pro 负责深度推理、根因分析、代码审查、重型多文件实现。边界模糊时先走 flash,不行再升级。对应的推理开关:flash 温度 0、厂商侧 \u003Ccode>thinking: disabled\u003C\u002Fcode>(官方认证的省成本手段);pro 保持思考开启——注意思考是模型级别的开关,不是 agent 前端配置项,温度等参数在 pro 上会被静默忽略。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>按模型声明成本元数据。\u003C\u002Fstrong> 为每个模型显式配置 input \u002F output \u002F cache_read \u002F cache_write 单价。这里踩过一个实坑:DeepSeek 的缓存写入没有单独公布的价目,实际按缓存未命中时的 input 价计费。所以配置里缓存写直接记账为未命中输入价,避免成本被系统性低估。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>提示词缓存字节稳定性纪律。\u003C\u002Fstrong> 缓存命中省钱的前提是前缀稳定,于是立了几条硬规则:\u003C\u002Fp>\n\u003Cul>\n \u003Cli>agent 提示词、全局规则、规则顺序保持字节级一致,早期重排一次 = 全额重付输入成本;\u003C\u002Fli>\n \u003Cli>易变内容(时间戳、随机 ID、动态文件列表)一律追加在载荷\u003Cstrong>末尾\u003C\u002Fstrong>,绝不进头部;\u003C\u002Fli>\n \u003Cli>标题、摘要、压缩这类单次任务走 flash,让易变内容永远不污染 pro 的前缀缓存。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>三、OpenAI 兼容网关的适配层\u003C\u002Fh2>\n\u003Cp>DeepSeek 的 OpenAI 兼容网关与官方 API 有两个不兼容点,直接使用会静默出错:\u003C\u002Fp>\n\u003Col>\n \u003Cli>不支持 \u003Ccode>role: \"developer\"\u003C\u002Fcode> 的系统提示,必须回退为 \u003Ccode>role: \"system\"\u003C\u002Fcode>;\u003C\u002Fli>\n \u003Cli>不支持 \u003Ccode>max_completion_tokens\u003C\u002Fcode> 输出上限,必须回退为 \u003Ccode>max_tokens\u003C\u002Fcode>。\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>做法是在 provider 配置里声明一个 compat 块(\u003Ccode>supportsDeveloperRole: false\u003C\u002Fcode>、\u003Ccode>maxTokensField: \"max_tokens\"\u003C\u002Fcode>),让框架自动完成字段回退。经验:对接任何\"兼容 OpenAI\"的网关,与其靠运行时试错,不如把已知差异显式写进配置,作为一等公民的适配声明。\u003C\u002Fp>\n\u003Ch2>四、上下文管理:从百分比到绝对值\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>阈值必须与模型能力解耦。\u003C\u002Fstrong> 上下文自动压缩的触发阈值最初用百分比(60% \u002F 30%)。当模型上下文窗口从 128K 跳到 1M 后,百分比阈值折算下来高达 600K \u002F 300K,常规会话(20K–200K)永远触发不了压缩,机制形同虚设。修复是改成绝对 token 值(77K \u002F 38K),与窗口大小彻底解耦。教训一句话:\u003Cstrong>凡是依赖模型能力的阈值,一律用绝对值,不要用与模型能力挂钩的比例。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>\u003Cstrong>空结果回退(P0 级规则)。\u003C\u002Fstrong> 子智能体返回空结果且工作区无任何变化 → 缩小任务范围重试一次 → 仍失败就停下,明确报告子智能体基础设施故障。绝不把重型实现内联回编排层自己干——那会把顶层上下文烧穿。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>循环检测。\u003C\u002Fstrong> 连续 3 次以上相同工具调用且零进展 = 空转。立即停下,换策略或升级,绝不重复调用烧 token。这一条被写进了全局反模式清单,和\"禁止空 catch\"、\"禁止注释掉的代码\"并列。\u003C\u002Fp>\n\u003Ch2>五、配置的工程化交付\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>插件版本锁定。\u003C\u002Fstrong> 插件从 \u003Ccode>@latest\u003C\u002Fcode> 改为精确版本号\u002F提交锁定,并关闭自动更新。理由:AI 配置高度依赖提示词内容,插件的一次\"小升级\"可能改变整个 agent 的行为。可复现的构建,优先于永远最新。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>同步脚本 + 过期文件对账。\u003C\u002Fstrong> 写了一个 PowerShell 脚本把仓库配置同步到全局配置目录。值得记录的三个设计点:\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cstrong>独立副本而非符号链接\u003C\u002Fstrong>:仓库切换不会影响全局运行中的配置;\u003C\u002Fli>\n \u003Cli>\u003Cstrong>过期文件对账\u003C\u002Fstrong>:目标目录里\"仓库已不再管理\"的文件要主动删除,判断依据是 \u003Ccode>git ls-files\u003C\u002Fcode> 与 \u003Ccode>git log --diff-filter=D\u003C\u002Fcode> 的并集——当前受管文件 ∪ 历史上被删除的文件,之外的一律不动;\u003C\u002Fli>\n \u003Cli>\u003Cstrong>对账范围限定\u003C\u002Fstrong>:只在 skills \u002F agents \u002F commands 三个目录内对账,用户在全局目录自建的文件永远不会被误删;并支持 \u003Ccode>-WhatIf\u003C\u002Fcode> 干跑预览。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>六、知识的持久化与技能治理\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>\u002Flearn:把隐性经验沉淀为目录级规则。\u003C\u002Fstrong> 新增一条命令,把会话中非显而易见的经验提炼成 1–3 行洞察,写入\u003Cstrong>目录级\u003C\u002Fstrong> AGENTS.md(root、packages\u002Ffoo\u002F、src\u002Fauth\u002F 各有各的)。目录级意味着规则只在相关上下文生效,避免全局规则无限膨胀。这是对\"经验要沉淀、但不要污染全局\"的平衡解。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>技能做减法,并且新技能必须\"接线\"。\u003C\u002Fstrong> 技能库从 24 个精简到 20 个:删掉 6 个低使用率技能,新增 2 个面向 GitHub 工作流的(to-tickets:把规格拆成可跟踪的 issue;triage:基于标签的 issue 分流)。删与增背后还有一条治理规则:技能存在但没有被任何 agent 白名单引用 = 死配置,要么接线,要么删除。\u003C\u002Fp>\n\u003Ch2>结语\u003C\u002Fh2>\n\u003Cp>这轮演进的技术含量不在任何单一改动里,而在整体的方向:\u003Cstrong>把人的纪律编码成机器的约束\u003C\u002Fstrong>。权限白名单防止越权,字节稳定前缀保住缓存命中,绝对阈值防止机制失效,空结果回退防止静默降级,过期文件对账保证交付干净。它们都不炫技,但恰恰是这些东西决定了一套多智能体配置能否长期可维护、成本可控、行为可复现。如果你的多智能体配置已经开始遇到\"改不动、说不清、对不准\"的问题,可以从这六条里挑一条最小的先做起来。\u003C\u002Fp>\n\u003Chr>\n\u003Cp>项目地址:\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fznlgis\u002Fmy-opencode-deepseek-config\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">https:\u002F\u002Fgithub.com\u002Fznlgis\u002Fmy-opencode-deepseek-config\u003C\u002Fa>\u003C\u002Fp>","一、权限最小化:两道白名单 第一道:任务工具白名单(编排层)。 主智能体(编排者)通过 permission 声明:Task 工具默认拒绝一切派发,只放行 10 个具名子智能体(planner、deep-worker、oracle、reviewer、consultant、ui-builder、explore、librarian、light-orchestrator、vision)。效果有三: 路由闭环:所有路由决策收敛到一张显式路由表,不存在\"即兴派发\"; 防幻觉派发:模型无法临时发明一个不存在的子智能体; 边界即文档:谁允许被派发、谁不允许,配置本身就是权威文档。 第二道:技能白名单(每个子智能体)。 每个 agent 独立声明自己只能加载哪些技能,其余一律拒绝。例如:实现者(deep-worker)只加载 remove-deadcode、git-release、resolving-merge-conflicts 等执行类技能;审查者(reviewer)只加载 code-review、security-review;探索者(explore)只加载 codemap;分析师(oracle)只加载 reflect、simplify。 动机很关键:在不少框架里,加载一个技能隐含\"自我实现授权\"——读到了实现指南就等于拿到了动手许可。白名单把\"能读什么技能\"与\"能做什么事\"彻底解耦,同时明确了一条纪律:加载技能不等于授权自我实现,多文件改动仍然必须走 planner → 实现者的路径。 二、模型分层与成本核算 flash \u002F pro 分层。 flash 负责路由、搜索、查找、规划、常规实现;pro 负责深度推理、根因分析、代码审查、重型多文件实现。边界模糊时先走 flash,不行再升级。对应的推理开关:flash 温度 0、厂商侧 thinking: disabled(官方认证的省成本手段);pro 保持思考开启——注意思考是模型级别的开关,不是 agent 前端配置项,温度等参数在 pro 上会被静默忽略。 按模型声明成本元数据。 为每个模型显式配置 input \u002F output \u002F cache_read \u002F cache_write 单价。这里踩过一个实坑:DeepSeek 的缓存写入没有单独公布的价目,实际按缓存未命中时的 input 价计费。所以配置里缓存写直接记账为未命中输入价,避免成本被系统性低估。 提示词缓存字节稳定性纪律。 缓存命中省钱的前提是前缀稳定,于是立了几条硬规则: agent 提示词、全局规则、规则顺序保持字节级一致,早期重排一次 = 全额重付输入成本; 易变内容(时间戳、随机 ID、动态文件列表)一律追加在载荷末尾,绝不进头部; 标题、摘要、压缩这类单次任务走 flash,让易变内容永远不污染 pro 的前缀缓存。 三、OpenAI 兼容网关的适配层 DeepSeek 的 OpenAI 兼容网关与官方 API 有两个不兼容点,直接使用会静默出错: 不支持 role: \"developer\" 的系统提示,必须回退为 role: \"system\"; 不支持 max_completion_tokens 输出上限,必须回退为 max_tokens。 做法是在 provider 配置里声明一个 compat 块(supportsDeveloperRole: false、maxTokensField: \"max_tokens\"),让框架自动完成字段回退。经验:对接任何\"兼容 OpenAI\"的网关,与其靠运行时试错,不如把已知差异显式写进配置,作为一等公民的适配声明。 四、上下文管理:从百分比到绝对值 阈值必须与模型能力解耦。 上下文自动压缩的触发阈值最初用百分比(60% \u002F 30%)。当模型上下文窗口从 128K 跳到 1M 后,百分比阈值折算下来高达 600K \u002F 300K,常规会话(20K–200K)永远触发不了压缩,机制形同虚设。修复是改成绝对 token 值(77K \u002F 38K),与窗口大小彻底解耦。教训一句话:凡是依赖模型能力的阈值,一律用绝对值,不要用与模型能力挂钩的比例。 空结果回退(P0 级规则)。 子智能体返回空结果且工作区无任何变化 → 缩小任务范围重试一次 → 仍失败就停下,明确报告子智能体基础设施故障。绝不把重型实现内联回编排层自己干——那会把顶层上下文烧穿。 循环检测。 连续 3 次以上相同工具调用且零进展 = 空转。立即停下,换策略或升级,绝不重复调用烧 token。这一条被写进了全局反模式清单,和\"禁止空 catch\"、\"禁止注释掉的代码\"并列。 五、配置的工程化交付 插件版本锁定。 插件从 @latest 改为精确版本号\u002F提交锁定,并关闭自动更新。理由:AI 配置高度依赖提示词内容,插件的一次\"小升级\"可能改变整个 agent 的行为。可复现的构建,优先于永远最新。 同步脚本 + 过期文件对账。 写了一个 PowerShell 脚本把仓库配置同步到全局配置目录。值得记录的三个设计点: 独立副本而非符号链接:仓库切换不会影响全局运行中的配置; 过期文件对账:目标目录里\"仓库已不再管理\"的文件要主动删除,判断依据是 git ls-files 与 git log --diff-filter=D 的并集——当前受管文件 ∪ 历史上被删除的文件,之外的一律不动; 对账范围限定:只在 skills \u002F agents \u002F commands 三个目录内对账,用户在全局目录自建的文件永远不会被误删;并支持 -WhatIf 干跑预览。 六、知识的持久化与技能治理 \u002Flearn:把隐性经验沉淀为目录级规则。 新增一条命令,把会话中非显而易见的经验提炼成 1–3 行洞察,写入目录级 AGENTS.md(root、packages\u002Ffoo\u002F、src\u002Fauth\u002F 各有各的)。目录级意味着规则只在相关上下文生效,避免全局规则无限膨胀。这是对\"经验要沉淀、但不要污染全局\"的平衡解。 技能做减法,并且新技能必须\"接线\"。 技能库从 24 个精简到 20 个:删掉 6 个低使用率技能,新增 2 个面向 GitHub 工作流的(to-tickets:把规格拆成可跟踪的 issue;triage:基于标签的 issue 分流)。删与增背后还有一条治理规则:技能存在但没有被任何 agent 白名单引用 = 死配置,要么接线,要么删除。 结语 这轮演进的技术含量不在任何单一改动里,而在整体的方向:把人的纪律编码成机器的约束。权限白名单防止越权,字节稳定前缀保住缓存命中,绝对阈值防止机制失效,空结果回退防止静默降级,过期文件对账保证交付干净。它们都不炫技,但恰恰是这些东西决定了一套多智能体配置能否长期可维护、成本可控、行为可复现。如果你的多智能体配置已经开始遇到\"改不动、说不清、对不准\"的问题,可以从这六条里挑一条最小的先做起来。 项目地址:https:\u002F\u002Fgithub.com\u002Fznlgis\u002Fmy-opencode-deepseek-config",2738,{"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]]