[{"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,59,65,72,78,85,92],{"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: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":53,"kind":7,"title":54,"summary":55,"image":56,"href":57,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":58},"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":60,"kind":7,"title":61,"summary":62,"image":15,"href":63,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":64},"NEWS_ARTICLE:854","分治：序列分治（CDQ）与点分治","分治：序列分治（CDQ）与点分治 一、分治思想概述 分治（Divide and Conquer）是算法设计中最核心的思想之一。它的基本策略是： 分（Divide）：将原问题划分为规模更小的子问题。 治（Conquer）：递归地求解子问题（若子问题足够小则直接求解）。 合（Combine）：将子问题的","\u002Fnews\u002F854",[19],{"id":66,"kind":7,"title":67,"summary":68,"image":69,"href":70,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":71},"NEWS_ARTICLE:865","焕新鸿蒙应用权限管理方案，应用授权体验再升级","作为用户或应用开发者，或许经历过类似的体验场景：使用应用的过程中，触发应用某些功能会需要访问你的位置、麦克风、相机等常用权限，若为了保护隐私拒绝授权后，想要使用功能时，再次打开却找不到设置入口；或开启流程繁琐，需要经过频繁跳转和设置。这一问题不仅影响用户体验，还可能造成应用功能不可用、用户流失，也制","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2396482\u002F202609\u002F2396482-20260901170248450-744043562.png","\u002Fnews\u002F865",[19],{"id":73,"kind":7,"title":74,"summary":75,"image":15,"href":76,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":77},"NEWS_ARTICLE:875","别急着翻译 SKILL.md：我做了一个专门拆解 Skill 设计的工具","别急着翻译 SKILL.md：我做了一个专门拆解 Skill 设计的工具 第一次打开一份复杂的 SKILL.md，很多人的反应都是从头往下读。 每句话似乎都认识，连在一起却不一定明白：为什么这里用了 MUST？为什么执行前要读取这些文件？状态由谁维护？AI 做到什么程度才算完成？如果两条指令发生冲突","\u002Fnews\u002F875",[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:879","高并发下的抢红包设计：微信红包背后的算法与温情","本文拆解微信拼手气红包高并发实现，详解核心**二倍均值算法**，解决红包分配公平性问题。架构上依靠 Redis+Lua 脚本实现原子抢红包，规避超发与重复抢夺；结合 MQ 异步落库、热点 key 拆分、多层限流、定时对账兜底，支撑百万 QPS。给出 Java、Lua 核心源码，梳理超发、缓存一致性、","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F739056\u002F202609\u002F739056-20260901095345589-1940958188.png","\u002Fnews\u002F879",[19],{"id":86,"kind":7,"title":87,"summary":88,"image":89,"href":90,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":91},"NEWS_ARTICLE:896","如何设计对外API接口","详解生产级对外 API 完整设计方案，围绕易用、安全、健壮黄金三角，覆盖 RESTful 规范、统一响应、签名验签防重放、AOP 注解实现分布式幂等、Redis 令牌桶限流、版本兼容、监控文档。附带可直接复用 Java 核心代码，梳理面试高频技术难点，搭配模拟面试场景，帮你避开线上坑点，快速掌握开放","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F739056\u002F202608\u002F739056-20260831134132446-55355388.png","\u002Fnews\u002F896",[19],{"id":93,"kind":7,"title":94,"summary":95,"image":15,"href":96,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":97},"NEWS_ARTICLE:906","上周热点回顾（8.24-8.30）","热点随笔： · 从 PostgreSQL 到 Kubernetes：开源的护城河，从来不写在代码里 (张善友) · 代码都能让AI写了，我还学个屁？ (佛祖让我来巡山) · Vibe Coding 月提交量 29 亿次之后：GitHub 的危机、Azure 迁移，以及","\u002Fnews\u002F906",[19]]