[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"consumer-news-detail-863":3,"consumer-news-interaction-863":41,"consumer-news-related-863":44},{"detail":4,"item":36},{"card":5,"schemaVersion":23,"fields":24,"content":30},{"id":6,"kind":7,"targetType":8,"targetId":9,"subtype":7,"typeLabel":10,"title":11,"subtitle":12,"summary":13,"coverUrl":14,"badgeText":15,"href":16,"sourceName":12,"meta":17,"metrics":20,"tags":21,"resolved":22},"NEWS_ARTICLE:863","news","NEWS_ARTICLE",863,"资讯","弱模型不能裸奔：Agent Harness 凭什么真实有效","博客园","Harness 不是给弱模型贴的创可贴。它是把工程纪律——验证、门禁、不变量、路由——变成架构里一等公民的方式。模型每半年换一代，今天省钱的 Flash 明天可能就过时了，但那套'默认怀疑、机器校验、按决策密度调度'的流程会留下来，并且越跑越值钱。\n弱模型不能裸奔。给它穿上 harness，便宜才真","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F510\u002F202608\u002F510-20260830181633785-1171146572.jpg","","\u002Fnews\u002F863",[18,19],"2026","综合技术",{},[19],true,"consumer-content-detail-v1",{"sourceName":12,"authorName":25,"categoryName":19,"summary":13,"description":13,"publishTime":26,"updateTime":27,"sourceUrl":28,"language":29},"张善友","2026-09-01T20:35","2026-09-02T20:37:50","https:\u002F\u002Fwww.cnblogs.com\u002Fshanyou\u002Fp\u002F22763545","中文",{"format":31,"policy":32,"normalized":22,"html":33,"text":34,"wordCount":35,"hasBody":22},"HTML","NEWS_CONTENT_V1","\u003Cp>\u003Cimg src=\"https:\u002F\u002Fi1.wp.com\u002Fimg2024.cnblogs.com\u002Fblog\u002F510\u002F202608\u002F510-20260830181633785-1171146572.jpg?w=720&quality=65&strip=all\" alt=\"75329688-E342-4567-8DE4-26C4DC182179\">\u003C\u002Fp>\n\u003Ch2>一个越来越常见的念头\u003C\u002Fh2>\n\u003Cp>模型分层定价之后，很多人动过同一个心思：既然 Flash 级模型这么便宜，干脆全用它跑 Agent 得了。\u003C\u002Fp>\n\u003Cp>算账确实诱人。但裸用弱模型干活，出来的东西隐患巨大——这不是体感，是结构性的问题。而那张流传很广的 Harness 工作环图，恰好把解法画清楚了：\u003Cstrong>commodity 模型扛起整条弧，frontier 模型只在它值回票价的地方出手，全程大约能省下 75% 的 frontier 用量\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cp>关键在于，这个\"省\"字背后站着一整套防护和验证机制。没有它们，省钱就是省出了事故。\u003C\u002Fp>\n\u003Ch2>隐患不在\"错\"，在\"错得自信且连贯\"\u003C\u002Fh2>\n\u003Cp>弱模型真正可怕的地方，不是它会犯错——强模型也会——而是它的错误分布\u003Cstrong>不可预测\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cp>它不会在你预期的地方犯错，而是以一种流畅、完整、看起来非常合理的方式犯错。代码能跑但逻辑是歪的，文档通顺但结论是假的。裸用它，等于把全部验证成本推给下游、推给用户、推给生产环境。\u003C\u002Fp>\n\u003Cp>Harness 的本质，就是把这个成本内化：critique 阶段、commit 门禁，都是在把\"默认信任\"改成\u003Cstrong>\"默认怀疑\"\u003C\u002Fstrong>。模型可以犯错，但错误过不了门禁。\u003C\u002Fp>\n\u003Ch2>Critique 的有效性，取决于校验器，而不是另一个模型\u003C\u002Fh2>\n\u003Cp>这是那张图最容易被误读的地方。\u003C\u002Fp>\n\u003Cp>让同一个 Flash 模型既当 worker 又当 critic，收益很有限——\u003Cstrong>同源错误很难自我检出\u003C\u002Fstrong>。一个觉得某种写法没问题的模型，换个身份再看一遍，大概率还是觉得没问题。\u003C\u002Fp>\n\u003Cp>真正有效的 critique，锚点是非模型的东西：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cstrong>可执行的验证\u003C\u002Fstrong>：测试、类型检查、编译、lint——跑不过就是跑不过，没有辩论空间；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>结构约束\u003C\u002Fstrong>：schema 校验、JSON-LD 的 framing \u002F slicing 这种形状约束——输出的\"形状\"先被框死；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>领域不变量\u003C\u002Fstrong>：这是 DDD 能进场的地方。聚合的不变条件、领域事件的合法性，都可以形式化成机器可检查的契约。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>换句话说：\u003Cstrong>领域建模做得越硬，harness 的 critique 阶段就越便宜、越可靠。\u003C\u002Fstrong> 模型负责生成候选，本体和不变量负责枪毙候选。生成的归模型，审判的归工程。\u003C\u002Fp>\n\u003Ch2>\"-75% frontier usage\" 的真正含义\u003C\u002Fh2>\n\u003Cp>这个数字不是\"省了 75% 的钱\"这么简单，它承认了一个很多人不愿承认的事实：\u003Cstrong>Agent 工作流里的大多数 token 消耗，是平庸劳动。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>真正决策密度高的，只有几个点：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cstrong>规划与拆解\u003C\u002Fstrong>——方向错了，后面全是白干；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>首个任务的冷启动\u003C\u002Fstrong>——没有上下文时最考验判断力；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>最终 promote 的交接\u003C\u002Fstrong>——这一步决定东西能不能出门。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>这些值得 frontier 模型。而中间大段的执行、填充、格式化，是 commodity 劳动——用便宜模型加一道门禁，完全够格。\u003C\u002Fp>\n\u003Cp>这不就是那条弧的含义：commodity floor 承担维护和简单任务，frontier 只覆盖规划期、首个任务和交接瞬间。\u003C\u002Fp>\n\u003Ch2>一个不能回避的边界\u003C\u002Fh2>\n\u003Cp>但也要泼一盆冷水：\u003Cstrong>harness 有补偿极限。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>如果底层模型连\"被约束后的输出空间\"都够不到——比如需要长链推理的任务，弱模型在中间步骤就漂移了——那么再多 critique 也只是反复枪毙、反复重来。延迟和 token 成本反而爆炸，还不如一开始就用强模型。\u003C\u002Fp>\n\u003Cp>所以 harness 里最难、也最值得精细设计的，是 \u003Cstrong>routing 逻辑本身\u003C\u002Fstrong>：什么任务升级、什么任务留在 commodity floor。\u003C\u002Fp>\n\u003Cp>这件事同样可以建模：把工作流画成一张技能 DAG，每个节点声明自己的能力需求，路由按标注调度。DAG 就是那条弧，调度策略就是 frontier 的使用纪律。\u003C\u002Fp>\n\u003Ch2>结语：模型可以换，纪律沉淀下来\u003C\u002Fh2>\n\u003Cp>Harness 不是给弱模型贴的创可贴。\u003C\u002Fp>\n\u003Cp>它是把工程纪律——验证、门禁、不变量、路由——变成架构里一等公民的方式。模型每半年换一代，今天省钱的 Flash 明天可能就过时了，但那套\"默认怀疑、机器校验、按决策密度调度\"的流程会留下来，并且越跑越值钱。\u003C\u002Fp>\n\u003Cp>弱模型不能裸奔。给它穿上 harness，便宜才真正是便宜。\u003C\u002Fp>","一个越来越常见的念头 模型分层定价之后，很多人动过同一个心思：既然 Flash 级模型这么便宜，干脆全用它跑 Agent 得了。 算账确实诱人。但裸用弱模型干活，出来的东西隐患巨大——这不是体感，是结构性的问题。而那张流传很广的 Harness 工作环图，恰好把解法画清楚了：commodity 模型扛起整条弧，frontier 模型只在它值回票价的地方出手，全程大约能省下 75% 的 frontier 用量。 关键在于，这个\"省\"字背后站着一整套防护和验证机制。没有它们，省钱就是省出了事故。 隐患不在\"错\"，在\"错得自信且连贯\" 弱模型真正可怕的地方，不是它会犯错——强模型也会——而是它的错误分布不可预测。 它不会在你预期的地方犯错，而是以一种流畅、完整、看起来非常合理的方式犯错。代码能跑但逻辑是歪的，文档通顺但结论是假的。裸用它，等于把全部验证成本推给下游、推给用户、推给生产环境。 Harness 的本质，就是把这个成本内化：critique 阶段、commit 门禁，都是在把\"默认信任\"改成\"默认怀疑\"。模型可以犯错，但错误过不了门禁。 Critique 的有效性，取决于校验器，而不是另一个模型 这是那张图最容易被误读的地方。 让同一个 Flash 模型既当 worker 又当 critic，收益很有限——同源错误很难自我检出。一个觉得某种写法没问题的模型，换个身份再看一遍，大概率还是觉得没问题。 真正有效的 critique，锚点是非模型的东西： 可执行的验证：测试、类型检查、编译、lint——跑不过就是跑不过，没有辩论空间； 结构约束：schema 校验、JSON-LD 的 framing \u002F slicing 这种形状约束——输出的\"形状\"先被框死； 领域不变量：这是 DDD 能进场的地方。聚合的不变条件、领域事件的合法性，都可以形式化成机器可检查的契约。 换句话说：领域建模做得越硬，harness 的 critique 阶段就越便宜、越可靠。 模型负责生成候选，本体和不变量负责枪毙候选。生成的归模型，审判的归工程。 \"-75% frontier usage\" 的真正含义 这个数字不是\"省了 75% 的钱\"这么简单，它承认了一个很多人不愿承认的事实：Agent 工作流里的大多数 token 消耗，是平庸劳动。 真正决策密度高的，只有几个点： 规划与拆解——方向错了，后面全是白干； 首个任务的冷启动——没有上下文时最考验判断力； 最终 promote 的交接——这一步决定东西能不能出门。 这些值得 frontier 模型。而中间大段的执行、填充、格式化，是 commodity 劳动——用便宜模型加一道门禁，完全够格。 这不就是那条弧的含义：commodity floor 承担维护和简单任务，frontier 只覆盖规划期、首个任务和交接瞬间。 一个不能回避的边界 但也要泼一盆冷水：harness 有补偿极限。 如果底层模型连\"被约束后的输出空间\"都够不到——比如需要长链推理的任务，弱模型在中间步骤就漂移了——那么再多 critique 也只是反复枪毙、反复重来。延迟和 token 成本反而爆炸，还不如一开始就用强模型。 所以 harness 里最难、也最值得精细设计的，是 routing 逻辑本身：什么任务升级、什么任务留在 commodity floor。 这件事同样可以建模：把工作流画成一张技能 DAG，每个节点声明自己的能力需求，路由按标注调度。DAG 就是那条弧，调度策略就是 frontier 的使用纪律。 结语：模型可以换，纪律沉淀下来 Harness 不是给弱模型贴的创可贴。 它是把工程纪律——验证、门禁、不变量、路由——变成架构里一等公民的方式。模型每半年换一代，今天省钱的 Flash 明天可能就过时了，但那套\"默认怀疑、机器校验、按决策密度调度\"的流程会留下来，并且越跑越值钱。 弱模型不能裸奔。给它穿上 harness，便宜才真正是便宜。",1558,{"id":6,"kind":7,"title":11,"summary":13,"image":14,"href":16,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":40},"2026 · 综合技术","#2563eb","16 \u002F 10",[19],{"targetType":8,"targetId":9,"likedByMe":42,"likeCount":43,"commentCount":43,"contentLikeCount":43,"contentCommentCount":43,"sourceLikeCount":43,"sourceCommentCount":43},false,0,[45,52,58,64,71,78,85,91],{"id":46,"kind":7,"title":47,"summary":48,"image":49,"href":50,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":51},"NEWS_ARTICLE:962","基于增强QUIC协议优化弱网下的直播观看体验","如今，直播已成为电商、教育、娱乐等各领域信息传递与线上消费的重要载体，而网络质量则是决定直播体验的核心命脉。然而，当用户一旦置身于地铁、户外等弱网环境中，画面卡顿、画质模糊、音画错位等问题便接踵而至，原本精彩的直播瞬间变得支离破碎，用户观看体验随之直线下降。 基于此，HarmonyOS SDK远场通","https:\u002F\u002Foscimg.oschina.net\u002F\u002FAiCreationDetail\u002Fup-d5a5690fbed726571a684c85eec1789e.png","\u002Fnews\u002F962",[19],{"id":53,"kind":7,"title":54,"summary":55,"image":15,"href":56,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":57},"NEWS_ARTICLE:1011","上周热点回顾（8.31-9.6）","热点随笔： · 被罚了500后，整个人都变老实了 (欢醉) · 2016已经是十年前了 (三范式) · 都是 AI 写代码，为什么 C# 比 Java 快半拍 (张善友) · OpenClaw 2.0 发布：史上最大更新，8 大新功能 + 2 个破坏性变更必看","\u002Fnews\u002F1011",[19],{"id":59,"kind":7,"title":60,"summary":61,"image":15,"href":62,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":63},"NEWS_ARTICLE:1023","数位 DP 进阶","数位 DP 进阶 日期：2026-07-14 关键词：动态规划、数位 DP、记忆化搜索 涉及题目：P2602 [ZJOI2010] 数字计数 | P4124 [CQOI2016] 手机号码 | P3286 [SCOI2014] 方伯伯的商场之旅 数位 DP 梳理一下数位 DP 的核心思想。 数位 D","\u002Fnews\u002F1023",[19],{"id":65,"kind":7,"title":66,"summary":67,"image":68,"href":69,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":70},"NEWS_ARTICLE:1025","Ninja 使用笔记","title: Ninja 使用笔记 author: 凌杰 date: 2026-08-10 tags: 自动化构建 categories: 软件使用经验 [!NOTE] 笔记说明 这篇笔记是《[[Makefile 使用笔记]]》的姊妹篇，将用于记录本人在使用 Ninja 这款项目构建工具过程中所记录","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F691082\u002F202609\u002F691082-20260906155027127-1498408465.png","\u002Fnews\u002F1025",[19],{"id":72,"kind":7,"title":73,"summary":74,"image":75,"href":76,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":77},"NEWS_ARTICLE:838","AI 学习笔记：LLM 的微调实验","title: LLM 的微调实验 author: 凌杰 date: 2026-08-21 tags: LoRA, LLaMA-Factory, Qwen categories: 人工智能 [!NOTE] 笔记说明 这篇笔记对应的是《[[关于 AI 的学习路线图]]》一文中所规划的第三个学习阶段。其中","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F691082\u002F202609\u002F691082-20260902122904258-1285666483.png","\u002Fnews\u002F838",[19],{"id":79,"kind":7,"title":80,"summary":81,"image":82,"href":83,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":84},"NEWS_ARTICLE:843","介绍一下常用的Token鉴权方案","本文梳理 Session‑Cookie、JWT、OAuth2.0、SSO 主流 Token 鉴权方案，对比各方案适用场景。重点讲解生产级 JWT 双 Token 架构，给出 RS256 非对称加密、Redis 黑名单、网关统一鉴权等 Java 实战代码。剖析 JWT 注销、并发刷新、令牌泄露等落地痛","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F739056\u002F202609\u002F739056-20260902114155245-1924311389.png","\u002Fnews\u002F843",[19],{"id":86,"kind":7,"title":87,"summary":88,"image":15,"href":89,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":90},"NEWS_ARTICLE:854","分治：序列分治（CDQ）与点分治","分治：序列分治（CDQ）与点分治 一、分治思想概述 分治（Divide and Conquer）是算法设计中最核心的思想之一。它的基本策略是： 分（Divide）：将原问题划分为规模更小的子问题。 治（Conquer）：递归地求解子问题（若子问题足够小则直接求解）。 合（Combine）：将子问题的","\u002Fnews\u002F854",[19],{"id":92,"kind":7,"title":93,"summary":94,"image":95,"href":96,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":97},"NEWS_ARTICLE:865","焕新鸿蒙应用权限管理方案，应用授权体验再升级","作为用户或应用开发者，或许经历过类似的体验场景：使用应用的过程中，触发应用某些功能会需要访问你的位置、麦克风、相机等常用权限，若为了保护隐私拒绝授权后，想要使用功能时，再次打开却找不到设置入口；或开启流程繁琐，需要经过频繁跳转和设置。这一问题不仅影响用户体验，还可能造成应用功能不可用、用户流失，也制","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2396482\u002F202609\u002F2396482-20260901170248450-744043562.png","\u002Fnews\u002F865",[19]]